On Wed, 2007-08-01 at 08:33 +0200, Emmanuel Onzon wrote:
> Quoting skaller <[EMAIL PROTECTED]>:

> > Weirdly .. this:
> >
> >  sifgoto := if lpar sexpr rpar statement else statement =>#
> >  sifgoto := if lpar sexpr rpar statement =>#
> >
> > actually works .. or seems to lol!
> 
> If you're only considering the age of the rule used to produce the
> toplevel statement to decide which interpretation to keep, then this
> behavior makes sense.

That's the case: only the age of the toplevel rule counts.

> If you are considering the max of the age of all the rules used, then
> it's weird and it may not be reliable.

I changed to just using the top level age. The motivation is
something like:

        fun f(int x) ...

Now, this is using a new rule 'int x'. However, once any ambiguity
in the 'argument' nonterminal is resolved, the age of the argument
productions shouldn't have any influence.

The 'counter-example' to this is something like this:


        ite := if ( e ) s ep
        ep := else e

Now, we extend:

        ep := elif ( e) ep

In this case one might consider

        if .. then .. elif .. else .. 

an instance of a 'new rule'.

One way to choose between the 'flat' and 'max' rules is to consider
that the flat interpretation supports clobbering, whilst the max
rule doesn't.

The max rule has an invariant result, whereas the flat rule
provides a programmer control:

        st := s1 | s2 | s3 | s4
        s2 := q1 | q2 | q3

Well, now we have a choice adding a new rule to either st or s2.
It makes a difference like:

        st := exec | decl

in C++ is the rule: declarations are always preferred over
executable code .. no matter how new an exec rule is, it
only helps choose among competing executable statements.

To look at this another way: the max rule has an invariant
that is roughly saying it is 'independent of tree structure'.

But the flat rule ALSO has an invariant: that the behaviour
at a given level of a tree is invariant: adding new
subbranches doesn't change the resolution.

The second rule invariant supports the 'open/closed' principle
much better than the first.

To say another way, the 'max' rule is a global property,
the 'flat' rule is a (more) localised property.

To get rid of 'more' in the above claim, we'd need
non-extensible nonterminals.

So .. I think the flat rule turns out to be better than
the max rule. But I'm NOT sure.

In particular -- I have yet to add Dypgen priorities into
the mix. That needs to be done, if only for performance,
but it will also provide extension capabilities not
present in the current system (eg you can insert levels
easily with priorities).


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to