[<<][staapl][>>][..]
Sat May 24 11:49:11 CEST 2008

More standard forth syntax

Maybe it's a good idea to have an interpret mode anyway, at least
during the parsing phase. This would make it a lot easier to deal with
standard forth syntax like 'constant'.

Looking at what the parser does now, it is already the case. Only
there's just a single mode: compile.

Adding an interpret mode, the language that's active could be plain scat.


Ha, i'me using the [ and ] word for code quotation. Looks like that's
exactly the opposite from how it would be used in Forth.

Questions:
  * is it possible to solve this without interpret mode?
  * using substitutions only, does the hygienic system provide enough
    freedom?

The latter i mean
  (io read write) ==
  (:macro io    1 2 3 make-io-object ;
   :macro read  ` read io ;
   :macro write ` write io ;)

The 'io' name is not visible in code since it's introduced by the
macro.

What can be seen here is that pattern relacement macros need a special
terminator.

parser io read write ==
   m: io     1 2 3 make-io-object ;
   m: read   ` read io ;
   m: write  ` write io ;
parser bla ... ==
  ...
end

Going that route, why wouldn't you write everything as parser
instead of macros?

The problem is, parsers allow you to deal with NAMES, while macros
allow you to deal with CODE. The fact that macros are associated to
names is a practical matter, but they are not allowed to modify or
create names. Parser words are necessary because prefix syntax is the
ONLY way to modify semantics of names, other than to reference the
macro that is bound to it in the current environment.

This might be a bit confusing. There are 3 things that can be bound to
names:

        * parser extensions  -> non-concatenative source code preprocessor
        * compiler macros    -> concatenative (compositional) code generation
        * forth words        -> macro instantiation

It's probably possible to design a language that doesn't need the
first step, but technically even scheme has this: the reader, which
has special features. Having to do it this way is a FUNDAMENTAL
limitation/feature of Forth.

This is DIFFERENT from Forth because it is pure input word stream
substitution. Forth's parsing words operate on the input stream
directly. This is one of the reflective properties of Forth that is
eliminated in Purrr.

EDIT: But, adding this extra level, does it stop there? How to create
parser macro creating parser macros?

The problem is easily solved with s-expressions, but hard to do with
the current implementation: what is necessary is to add semantics
AFTER collecting tree-structured code. This is what s-expressions can
do: parse step follows read step. Is it possible to bring this to
Forth?

TODO: write something intelligent about this problem. it's a deep one,
related to syntax and reflection: the difficulty of unrolling Forth.



[Reply][About]
[<<][staapl][>>][..]