Sun Dec 16 10:13:47 CET 2007
from interactive.ss :
The end goal of Purrr is to have only 'live' and 'macro'
interactions: the system should be powerful enough so excursions to
the underlying prj: code is not necessary. This gives a separation
between 'tool development' and 'tool usage'.
I've come to believe that this is not a good idea in general. It is OK
to be able to access the most basic host code, such as compilation,
upload and inspection, but for real work you'd want to automate those
and have a 'real' programming language behind it. In other words:
access to prj or scheme code is necessary.
* it's ok to have a small collection of host words in interaction
mode which are hidden using prefix parsing.
* this set of mappings (parsing words) should be extensible: prefix
parsing needs a simpler definition form.
* the functionality behind those words should be extensible
Concretely this requires interactive.ss to be adjusted so it can
accomodate parsing code in a different way. Maybe it can be made
extensible together with the other parsing words.. The problem right
now is that it is a single method, and the way it's defined is
difficult to make dynamic (it's a scheme macro).
Actually, compile mode forth parsers are already registered in the
global namespace tree, so making them extensible can be done
incrementally by adding some more name spaces.