Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 Fluke 8/7/84; site fluke.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!ssc-vax!fluke!kurt From: kurt@fluke.UUCP (Kurt Guntheroth) Newsgroups: net.micro Subject: C INTERPRETER Message-ID: <1243@vax2.fluke.UUCP> Date: Mon, 13-Aug-84 18:46:50 EDT Article-I.D.: vax2.1243 Posted: Mon Aug 13 18:46:50 1984 Date-Received: Wed, 15-Aug-84 01:38:50 EDT Distribution: net Organization: John Fluke Mfg. Co., Everett, WA Lines: 41 People have begun to ask me why I don't think C could be interpreted. Specifically, why not preprocess first and then interpret. Well..., it kind of defeats the purpose of an interpreter, which is to allow you to make easy alteration of the source lines. Imagine a program which makes reasonable use of the preprocessor. Constants are symbolic, some parts of the program are conditionally included, files are included. In short, the source program changes by a significant amount when preprocessed. Now, you could just not write programs that need preprocessing and what you wrote would be what you saw in the interpreter buffer. That would be ok but you would never be able to run normal C code which relies on the pre- processor. You could preprocess first. But then the code you interpreted wouldn't much resemble the code you wrote. Sure it executes fine (albeit slowly), but if you want to change something (interpreters are supposed to make debugging easy), the line of the error may not look much like anything you wrote. The lines of text the interpreter works on will not be referenced to the lines of your source, the text will look different (and often very strange...look at preprocessed code containing calls to the stdio 'functions' if you want to see just how wierd things look.) Files will be included... Not a good choice. OK, so don't debug the code with the interpreter, or make the debugging facilities resemble sdb or dbx. That's no good either. PCC is pretty fast and so is ld. The time it took to (1) preprocess, (2) load the interpreter and (3) run your program would probably more than equal the time to compile the affected module over again and relink things. So why bother. That leaves expanding macros each time by the line or keeping two versions of the program around with a data structure relating one to the other. This works I suppose, but it would be slow if not carefully done, and even if carefully done, would be memory-wasteful and fiendishly complex. Maybe the developers of this interpreter have a way to do this, I don't know? -- Kurt Guntheroth John Fluke Mfg. Co., Inc. {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt