Sun Jun 15 11:36:02 CEST 2008

for .. next

The (hypothetical) higher order macro:

   [ ... ] for-next

and the Forth equivalent

   for ... next

do the same thing, but in current RPN representation, 'for-next' does
have access to the macro quotation to perform optimizations.

It would be nice to make the first one primitive. In the current
implementation however, this is difficult to do because the ... in the
2nd form is evaluated before 'next' is evaluated. This approach would
need a change in representation.

It does seem that using quotations directly is a far better approach:
it doesn't need any forensics to recover quotations from flat Forth
syntax. A limited translation of Forth to this form as a syntactic
operation might be feasible, but it's not possible to take it all..

This is at the core of the conflict of 2 forces in Purrr:

  (L) The lowlevel compiler which gives explicit control to the
      programmer about how to use nesting.

  (H) The highlevel approach based on explicit quotations and
      s-expression syntax.

Unifying both is difficult, but they can probably be built on common
ground: providing a macro language with simple (conditional) jump
primitives. This is (virtual) machine design: the Purrr control