Several Topics - Nov. 19, 2013

[Chris Angelico]

On Wed, Nov 20, 2013 at 9:43 AM, glen herrmannsfeldt
<gah at 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!)