begin quoting Steven E. Harris as of Mon, Jan 08, 2007 at 07:37:50PM -0800: > Andrew Lentvorski <[EMAIL PROTECTED]> writes: > > > And, BTW, most Lisp environments have the same "write to disk" > > problem. The differences is that most of them are using Emacs and > > can write the interactive buffer. The same thing can be done for > > ipython, IIRC. > > But then there's also the image idea in Lisp, lacking in most other > languages. What one might save from an interactive session could be > the code, as in the text, but it could and should also be the image, > or the accreted environment built up out of the evaluation of code, > ready to be restarted later -- and perhaps even delivered for end-user > consumption.
I should dig up my PRIMOS documentation. I was sure the "old" program file format was just an image and a PC offset. Running a program consisted of loading the program into RAM and setting the PC, and there were, I thought, ways to snapshot the running program to disk. Of course, the "image model" means that you need to keep several old images around, in case you screw something up and don't realize it. Keeping track of such files is a PITA. There's a reason modern languages don't muck with images much anymore... > The whole idea of a "program" in Lisp doesn't really make sense, > unless one wanders into implementation-specific "boot functions", but > even then those are just singled-out entry points into the big ball of > mud. Smalltalk has this approach too. It's the most annoying feature of the whole language, so far as I'm concerned. -- Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
