[tern] more notes -- call this RFC two?

[david nicol]

TERN gets implemented as a source filter module that takes
an argument identifying which set of rules to apply.  So it is
a shortcut for writing complex source filters. Invocation of it
looks like

        use TERN  extensions => [qw{ ifdefined it coroutines } ];
                  
and this sets up the TERN parse-and-rewrite environment and
loads the listed set of rewrite rules.

The TERN parse and rewrite environment, by itself, causes
all subsequent code to get pre-parsed by TERN, including any
appearances of "means" working as rewrite rules on subsequent
code in the block in which the "means" rewrite definition appears.

The reserved words in TERN rewrite language is something I'm
hoping we can discuss here on this list.  I like "means" as the
definitional reserved word but that too is open to replacement if
anyone has a better idea.

in "means language" the text to the left of the "means" is the
pattern and the text to the right is the replacement text.

An example of a rewrite is converting for(expr;expr;expr)block
to a while expression, or converting a while expression to
a more primitive form composed of if and goto and labels.

Each expression is run through all available pattern matches in the
order they have been defined, repeatedly, until nothing matches any
more.  The set of patterns to try is generated intelligently by
listing patterns by their triggering keywords, that's a sensible
optimization -- checking the while pattern against an expression that
does not contain the keyword "while" is a waste of time.



What I would like to do is brainstorm what has to bein means language by
informally proposing rewrite rules and seeing what we can come up
with.  

For instance, in order to implement early-bound polymorphism through
rewrite rules, we need a way to tag variable names with types, and
a way to specify types in means language.  For instance, a tern-enhanced
perl program in the idiom of polygon drawing might have the following in
it to implement early-bound polymorphism:

        CIRCLE  means OBJECT-isa-Circle  ; # define type CIRCLE 

        BOX  means OBJECT-isa-Box  ; # define type BOX

        draw(CIRCLE c) means draw_circle(c) ; # early dispatch for &draw

        draw(BOX b) means draw_box(b) ; # early dispatch for &draw

I'm following a convention of shouting names of types of things that the
rewrite rules will look for, to follow the convention of BLOCK, EXPR,
and so on.  I think that's a convention and not a syntax element.

I think its pretty clear that we need to name types explicitly to
prevent confusion between what is supposed to be TERN rewrite syntax and
what is supposed to get matched.  So variable elements on the left
hand side are (type, name) pairs, instead of having their types implied.

Using dashes to append qualifiers to type names will work to chain
qualifications -- if things of type "OBJECT" turn out to be imeplemtned
as 

        OBJECT means THINGY-isa-Object ;

or if OBJECT is the fundamental type in our OO universe, we don't care.

        BOX would become THINGY-isa-Object-isa-Box and some later
code that would trigger this rule might look like

        my $button = new Box $x1,$y1,$x2,$y2;

        draw $button;

The parsing pass identifies the

                my VARIABLE = new TYPE_NAME


convention and tags $button with TYPE_NAME Box.  How does it do this?
The appearance of keyword "new" triggers the appearance of rules
involving "new" on their pattern sides.  We need a way to associate the
typename -- also a way to recognize that it's a typename (such
as "TYPE_NAME means BAREWORD") -- with the variable. How about we
use dashes again, and declare that if the rewrite contains only
TERN expressions involving named pieces, no rewriting is done, just
an immediate and one-time execution of the expression.  We don't want
to expand the invasiveness of TERN beyond the single keyword. 

        my VARIABLE v = new TYPE_NAME t means v-isa-t ;


if we have only one keyword, we could change it with a pragma invocation
parameter, perhaps

        use TERN MEANS => 'causes';

in case we're working on a problem domain involving averages and we want
to keep "means" for use in the program.
 

...


Since we're breaking down the program this far, restoring it to Perl
seems silly when we could just as easily write it out as C or as NASM,
if we succeed in interpreting Perl code into a flat space with named
entry points and fully expanded code


-- 
David Nicol, independent consultant and contractor
                       Howard Zinn quotes Thomas Paine.  Who do you quote?