[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tern] more notes -- call this RFC two?
From: |
Luke Palmer |
Subject: |
Re: [tern] more notes -- call this RFC two? |
Date: |
Thu, 28 Nov 2002 03:24:51 -0700 (MST) |
> 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