05:10 pm, 10 Mar 06
C REPL
I've often wondered if you could construct a read-eval-print loop for C (or a language atop C that wanted to use C libraries). I think the hard part would be handling error conditions. One way of looking at it (as Dan put it) is that the C language spec allows you to crash whenever something unexpected occurs, while most languages have defined semantics for all inputs. (This isn't a slam on C -- leaving lots of things unspecified allows for a faster implementation. For example, array indexing can be done without bounds checking because indexing off the bounds of an array is one of those undefined conditions.)
It just occurred to me, though, that you could
[Edit: I later got around to implementing this. See the C REPL tag.]
It just occurred to me, though, that you could
fork() before running each line of code. Then if that code caused a crash, you'd still have the old process state around, while if it didn't crash you could kill the old process. The only problem is for code that involved I/O, you wouldn't get a second chance... hmm. I suppose the same is true for a "normal" REPL anyway.[Edit: I later got around to implementing this. See the C REPL tag.]
Furthermore, in regards to your fork idea, there are capabilities based operating systems that implement memory checkpointing in such a way that you can revert to a saved snapshot. It's not on line of code granularity but by some timeslice.
I understand (but never saw) that there was an ANSI C implementation (interp. and compiled) that ran on Symbolics and took good advantage of the tagging hardware (and GC of course). It definitely caught bounds violations, but I'm not sure what kind of sanity checking it did for casts.
I wrote a C parser in Common Lisp once, primarily using the programmable read-table (so you'd do (let ((*readtable* *c-readtable*)) (read)) and it'd give you a sexpr representing the next C statement.) This was so that Lucid CL could parse C header files and auto-construct Lisp stubs to call C libraries from its foreign function interface.
(I don't think that programming the read table was an especially good way to go about it, in hindsight, but it was a pretty sweet hack anyway.)
I'm still waiting for a version of gdb that has a "step backward" command.
But if I was doing it today, I guess I'd read that as 3 tokens: if, (x), (y z). I guess it depends on whether you think it's more useful to have ";" be handled in the tokenizer or the parser. Technically you should just give it its own token, but it seems to me that it'd more useful (and lispy) to tokenize "a b c;" as a list of 3 elements, but putting parser-level semantics like "how many tokens are swallowed by `if'" down in the tokenizer seems like it's going too far. But do you want "static const char * const *" to read as a single object? Probably... It's cases like this -- where you just want to grab and play around with the language's parse tree -- that the insanity of C's syntax really jumps up and beats you on the head. C's special forms (to use lisp terminology) are so irregular that maybe you really do want to handle all of them down in the tokenizer. Gaah. Madness.
The programmable readtable is pretty cool, but really easy to abuse (exactly like operator overloading: it's neat, but if you're using it, you really probably shouldn't be.)
Some of the standard reader macros were really handy. #+ and #- were the read-time equivalent of #ifdef/#ifndef; #. meant "evaluate following sexpr at read-time and return result as token". And on the LispMs, #, meant the same, but if running in the compiler, evaluate at load-time instead. That was pretty cool: in most contexts, #, acted like #., except when the compiler was writing the fasl file (executable object files were just serialized/flattened objects, most of which happen to be compiled-function objects) it'd emit a chunk that ran a compiled version of the #, sexpr at load time. (And of course you can evaluate code in the third remaining context, the compiler, with defmacro; I think there was a "*compiling*" variable or something that would let you emit different code for the interpreter and the compiler.)
Cint
http://root.cern.ch/root/Cint.htmlI'm not quite sure whether CINT has a REPL, but I seem to remember that it does. However, I'm very afraid of any software developed by physicists! (-:
Cint REPL
http://root.cern.ch/root/CintInterpreter.htmlhttp://people.csail.mit.edu/jrb/goo/manual.46/goomanual.html