Sun Apr 26 03:01:08 CEST 2009

Forth parsing

The trouble is that instead of a list with a hole in it (the
dictionary's compile point = cursor), it would be nice to be able to
put holes in nested applications.

This is exactly what the previous implementation did.  Instead of
being able to process the whole locals expression at once, it
incrementally bulds an inside-out structure, where the outside is
represented by a (stack of) wrapping procedures.

So, there are 2 options:
    * create a zipper-like dictionary for incremental compilation
    * do multi-pass parsing using delimiters

Some trick needs to be used..

The thing is this:

: test | ; : | ;

What is this supposed to mean?  Introducing the local variables then
kills all hope of using either ; or : as delimiter, since they should
be redefined.

Ha, Looks like the Factor syntax changed too :)

Let's go look at Forth for inspiration.
I found Gforths's syntax:

   { l1 l2 ... -- comment }

The problem is that I'm using non-local exits.  I like them, and they
are used for both macros and Forth words.  The only real solution is
to keep it like it is:

   * new definition terminates old

   * locals installs a wrapper around the remainder of the code.

   * parsing words cannot be used as argument names,

the last one because they are not recognized as lexically bound during
parsing, only when the parsed source is expanded after passing it to
the dictionary compiler.  this is also a good thing since it would
otherwise allow redefinition of words like : as a local variable,
messing up the code structure.

it's probably best to have a separate 'locals tag that is recognized
by the -> scheme compiler.  actually, this doesn't look all that bad.

: foo | a b | b a 1 - -

-> ((name foo) (locals (a b)) (fn a) (fn b) (im 1) (fn -) (fn -))

    1. tag source and execute parsing words
    2. compile tagged source to scheme (including some special forms)

now, can 'locals be implemented as a simple "cons" macro?