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
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