2009/4/4 john skaller <skal...@users.sourceforge.net>
>
> On 05/04/2009, at 2:10 AM, Emmanuel Onzon wrote:
>
>
>> The problem goes away if non-terminals have unique priorities,
>> in which case the priority name can just be used in lieu of the
>> non-terminal.
>>
>> Interesting idea.
>> For the extensions of the grammar done in the felix code,
>> it is possible to do it without any change to dypgen this way:
>>
>> When the user defines a new rule like:
>>
>> term: <=term "+" <term
>>
>> Felix would add the rule:
>>
>> "expr",
>> [Non_ter ("expr",Priority_Lesseq "term");
>> Ter "Plus";
>> Non_ter ("expr",Priority_Less "term")],
>> "term",
>> []
>>
>> The user only writes the priorities.
>> This means Felix would have to guess which non terminal
>> is implicitly used, which shouldn't be difficult if each priority
>> is used for only one distinct non terminal.
>>
>
> Well computers can't "guess" .. so we need some rules and
> ways to break out.
>
You can do inference with the available information. The same
information that makes you able to know which Obj_*
constructor to use when writing a user action for a new rule.
So if you can generate the associated action to your new
rule, then you know the implicit non terminal of each priority.
>
> I think already you can add new statements: that would be
> quite common, the other common case is expressions.
>
> Of course, other extensions would have to be done long hand,
> and/or provide a way to associate a priority with a non-terminal.
>
> ============
>
> There is also the *inverse* of this problem already.
> Felix has something like:
>
> statement:
> declaration
> definition
> directive
>
> Now this looks harmless and for an LR parser it is. But it is quite
> different
> to just listing all the statements instead of grouping them for a GLR
> parser!
> This is because of the way merging is done: you can only merge for a given
> nonterminal. Felix use some kind of aging concept to chose between
> conflicting
> productions for the same non-terminal. However the resolution is not
> transitive,
> in other words it matters a lot which productions are definitions and which
> are declarations if you make a tree structure like above!
>
> I didn't expect this, but I got caught out by it: with the classification
> scheme
> above GLR first resolves conflicts between all declarations, then all
> definitions, then all directives, and only then does it try to resolve a
> conflict between a single remaining declaration, definition, or directive.
>
> Because Felix uses aging .. in other words, order of writing,
> a definition always beats a declaration, even if the actual declaration
> was parsed by a brand new production.
>
> At one stage, I passed the age up, so this wouldn't happen, but that
> doesn't work either ***
>
> So actually the Felix grammar needs a way to group things with
> "psuedo-non-terminals" which are basically macros (not
> real non-terminals).
>
> *** I can't remember exactly why this failed, but it has something
> to do with recursion. Recursion is evil ;->
>
With Christophe Raffalli, we discussed about implicit
disambiguating rules some times ago and concluded they
make the parser difficult to understand. Maybe the sensible
solution is just to forbid ambiguous programs and force the
user to write unambiguous code using parenthesis when needed.
And allow users to make explicit disambiguating rules.
Aging is problematic because when you import syntaxA
and then syntaxB, you don't have the same behaviour of the
parser than when importing syntaxB and then syntaxA.
------------------------------------------------------------------------------
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
