On Wed, Nov 20, 2013 at 9:43 AM, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > I also used to use a BASIC system that allowed you to stop a program > (or the program stopped itself), change statements (fix bugs) and > continue on from where it stopped. Not all can do that, but pretty > much compilers never do.
Ditto, both in GW-BASIC and Q-BASIC, but in each case there were some fairly strict rules about what could be edited. Changing anything to do with control flow quickly got you a "Can't continue" error. And of course, assembly language with DEBUG.EXE lets you do basically anything... rewrite memory (code or data, there's no difference), change the instruction pointer (so execution resumes somewhere else), change other registers, etc, etc. Most languages don't give you quite that much flexibility, because it's really REALLY easy to mess things up and confuse yourself completely. Python kinda will, though; all you have to do is fiddle with sys.modules so it won't be cached, or rename the file to something unique before reimporting it. You can then patch in functions from the new module and start using them. Pike makes this sort of thing much more convenient; it's not hard to write code that smoothly slides to a new version of itself, without losing any sort of state. But the granularity never gets down below the function, meaning the Python and Pike compilers/interpreters are free to fiddle around inside a function (note, for instance, how Python locals basically just become indices into an array; it'd be a bit awkward to tweak a running Python function and add a 'global' declaration). ChrisA (See? I'm posting on topic!) -- https://mail.python.org/mailman/listinfo/python-list