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

[Luke Palmer]

> From: david nicol <address@hidden>
> Date: 28 Nov 2002 03:32:53 -0600
> 
> 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.

I think we should have a clearer identifier than just "means"
somewhere in the middle of a line.  It would make parsing easier, and
it would certainly be easier to read.  Perhaps:

  macro PAT means PAT

Then uninitialized people :)  will know it's a macro and what it, er,
means. 

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

Will the pattern be like a Prolog unification pattern, or something
simpler than that? 

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

I say this is too specific to specify now.  Design an algorithm that
will handle that inherently  (I've got one cookin' in my brain).

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

And can you possibly expect to parse this?

    my var $var = new type Type

You said you managed to build a heirarchial list of syntax?  How about
something like:

    =[ NAME ; ->[ TYPE ; 'new' ] ]

That has the advantage of matching both:

    my $var = new Foo;

and

    my $var = Foo->new;

which, according to Perl, are the same thing.

It has the disadvantage of being ugly.

> 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


I don't understand this "tag" thing.  What do you mean?  How is
THINGY-isa-Object different from any other identifier?

> 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

This is the main reason I'm actually participating in this project.
There needs to be a Perl compiler.  There I<needs> to be.  (One that
doesn't just copy the interpreter and the bytecode)
 
Luke