Re: Feature request for gobo yacc

Nicholas Allen wrote:
> Hi Eric,
> 
> Thanks for your fast responce!
> 
> For what the implementation
> 
>>of geyacc is concerned, it would be easier to have it generate a
>>different class for each entry point. For example:
>>
>>   geyacc --start=program -o program_parser.e parser.y
>>   geyacc --start=expression -o expression_parser.e parser.y
>>
>>The problem is that even though they are generated in different
>>files, these parser classes will have the same name (the one
>>specified in the file parser.y).
>>Your suggestion of having a single 
>>parser class but several parse routines seems attractive. The
>>problem that would need to be addressed in the implementation of
>>geyacc is that everything would need to have to be duplicated
>>(with different names) in the class: not only the generated tables
>>as you pointed out, but also the features (either inherited from
>>the skeleton classes or generated in the parser class itself) that
>>use these tables. I will have to have a closer look at the code
>>in order to see if this is feasible and at what price.
> 
> 
> If it is at all possible to have multiple parse routines in the one yacc 
> parser object that really would be cool I think! I hope that it is not too 
> dificult to name all the shared variables. Perhaps prepending the name of 
> each of the top level rules to each variable could work. The problem would be 
> finding all the locations where all variables are referenced and making sure 
> they get updated. I haven't looked at the source code so not sure how 
> difficult it is in practice. I hope this can be done in a future version 
> though.

My biggest concern is to make sure that the generated code will not
be bigger or slower than now when there will be only one entry point
specified.

>>In the meantime, here is a trick that I recently sent to the
>>
>>Gobo developer mailing list and that might work for you:
>> >> On a related issue, I did not even consider using geyacc for the
>> >> parser, as XSLT needs three different entry points - one for the full
>> >> XPath expression language, and two sub-languages. It is my
>> >> understanding that this is not possible with geyacc and it's ilk. Am
>> >> I right?
>> >
>> > Yes, although there are some tricks to simulate several entry points,
>> > with one start rule or-ing the entry points, and then setting some
>> > boolean attributes to remember which of the entry points we wanted to
>> > use. If it is the semantic action of the corresponding entry point
>> > which is executed then everything is fine, otherwise there is a
>> > syntax error.
>> >
>> > %start global_entry_point
>> > %%
>> > global_entry_point: entry_point1
>> >       {
>> >          if not entry_point1_chosen then
>> >              -- report syntax error
>> >          else
>> >              ...
>> >          end
>> >       }
>> >
>> >   | entry_point2
>> >
>> >       {
>> >          if not entry_point2_chosen then
>> >              -- report syntax error
>> >          else
>> >              ...
>> >          end
>> >       }
>> >
>> >   | ...
>> >
>> >   ;
>> >
>> > With this technique there is the risk of intruducing ambiguities
>> > in the grammar though.
> 
> 
> In my situation this will not work as I must have the grammar as being 
> unambiguous.
> 
> Also, I had one other idea for another feature request. This one would be 
> harder to implement than the last one! It would be nice of one could inherit 
> grammars and modify them in subclasses of the parser. eg if expression is 
> defined:
> 
> Expression: Integer
> 	;
> 
> In a subclass of the parser it could be redefined:
> 	Expression: Float
> 	;
> 
> In the subclass expression could be either Integer or Float then. In effect 
> there would be an or between the two.

For the part between the two %% I don't think that it is a
problem because it's as if we were concatenating the two
files and then feeding geyacc with the result. It would be
more of a problem with what appears before the first %% and
after the second %%.

> It would be really handy when writing a language which is a superset of 
> another language (eg if you are adding your own custom higher level features 
> to a language).
> 
> For me anyway, the combination of these two features would make geyacc the 
> best parser around (I hope you agree and have the time to implement them 
> sometime!).
> 
> Thanks again,
> 
> Nick



-- 
Eric Bezault
mailto:ericb-D6Qt/9opevxWk0Htik3J/[email protected]
http://www.gobosoft.com



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/saFolB/TM
---------------------------------------------------------------------~->

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/gobo-eiffel/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/