Re: Specialized input parsing for code/REPL in DrScheme?

[Paul Fernhout <pdfernhout@kurtz-fernhout.com>]

Robert-

Thanks for the reply. 

Robert Bruce Findler wrote:
> 
> Well, for what it's worth, the non-source correlating reader is
> written in C and the source correlating reader is written in Scheme.
> Both are just called as library routines so it will not matter if you
> write your new reader in Scheme or in C.

Great!

> You will find that DrScheme makes a distinction that Smalltalk does
> not between the user's program and the programming environment
> itself. This means that we won't have the same extensibility that
> Smalltalk has, but it also means you cannot shoot yourself in the
> foot by updating some definition -- the execute button always starts
> your program completely afresh.
 
Good point. That certainly is the best approach for most programming
tasks. I have on several occasions taken down a Smalltalk system by
modifying a core bit of code (like for popping up a window). 

One thing emerging as the ideal in Smalltalk (not that it is in
commercial systems) is the notion of a "firewall" (called so in the
VisualWorks prototype abandoned years ago). A related idea that is in
commercial systems is the notion or "remote debugging" (supported well
in VisualAge Smalltalk, which can remotely debug Smalltalk over the
range from a pacemaker to a mainframe). 

IDLE, the Python editor, is starting to wrestle with the remote
debugging issue too. In IDLE's case, one of the motivators is that it
typically runs the debugged code in its own process, and so when your
TCL GUI app locks up, it can take IDLE down too (since IDLE also uses
TCL). 

In the case of Squeak Smalltalk, the core VM is written in a subset of
Smalltalk and translated to C, linking to about 2000 lines of
platform-specific C. By subclassing the VM interpreter in Squeak to make
one where the functionality of these 2000 lines of OS specific code are
implemented in Smalltalk, the system can emulate itself. It was actually
bootstrapped that way, by developing the translatable Interpreter class,
and the related subclass IntepreterSimulator, under a commercial
Smalltalk. For implementation details (might be something in there
useful for DrScheme) see this paper:
  ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html

The intent behind firewalls and remote debugging and VM simulation is to
have useable development tools in one namespace working under a reliable
VM, and to then be using these stable tools to create and interact with
a program through a well defined interface (on the same or a remote VM).
The program you are working on (using stable tools) may also be a
development environment, but the changes in what is being developed are
separate from the system you are actually using to compile and debug it.
So, for DrScheme, this would be like being able to use DrScheme to
remotely modify and debug another running DrScheme system written mostly
in Scheme. 

While normally what I describe is not needed or useful for most
application programmers (although remote debugging can often be useful
for applications too), it would certainly be nice to have for things
like developing specialized parsers tightly integrated in DrScheme, or
other significant tools or extensions.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com