Re: how to get left hand side symbol in action

[Christian Schoenebeck]

On Freitag, 10. Mai 2019 19:34:54 CEST Akim Demaille wrote:
> And there was nothing that could be shared?  A lot of what you described
> below looks like what LAC does.  But I am definitely not a LAC expert, nor
> one of your application, obviously :)

Well, you can look at this example:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/network/lscp.y?view=markup
And before you say it: I know that the grammar has conflicts, just ignore the
grammar. The relevant C++ code regarding this topic is below the grammar
definition in that .y file.

And the result of that source looks/behaves like this:
http://doc.linuxsampler.org/LSCP_Shell/

Now that I look at it, I remember this old example had bugs, for instance
the <SP> on the screen shot pretty much looks like a wrong suggestion.
But it is just an example anyway and you can see the source.

> > No, I really mean the non-terminal symbols. Because sometimes [not always
> > ;-)] I don't use the classic approach of separate lexer and parser, but
> > rather let the parser do the lexer job as well, like:
> > 
> > FOO : 'F''O''O' ;
> 
> Ok.  But then we face exactly what I'm saying: you are constrained
> by the syntax of symbols.  If you had say regular expressions in
> your grammar, you would be forced to write
> 
> regular_expresion: ...
> 
> and display "regular_expression" in your messages.  That's ugly.
> Using symbol identifiers is not correct.  It does not fully fit your
> need, it just "mostly works".  I can't bake that into Bison.

Of course I understand your point. The difference in viewing this is just that
you want to see the final solution in Bison to be as clean as possible, whereas
most other people are already fine with the fact that symbol names can act
as unique identifiers which easily can be converted into any other kind of
representation, e.g. by simply doing a table/map lookup in their yyerror()
implementation to solve your example.

> Do you disable the default reductions?  Reading what you do, it seems
> that it would make your computations more accurate.

I was not even aware that I could disable them, so not yet. Might be worth a
try. :) Thanks!

> I guess BisonSymbolInfo is the most significant difference with LAC,
> isn't it?  But the traversal is probably the same.

Well, in the end the algorithm I described is more or less just replicating
what LALR(1) does for the actual purpose of resolving the next possible
symbols. So the root purpose is getting access to grammar details in certain
states which would otherwise not be available with the stock skeleton on its
own.

As far as I can see it LAC would not provide those information required, would
it? I mean how would you e.g. implement auto completion features with LAC?

Plus the docs say LAC might end up in endless recursions.

> > Another problem with my pseudo-terminals (example FOO above): From Bison
> > point of view, everything in my grammar are now non-terminals, and I
> > don't want to manually mark individual grammar rules to be either
> > considered as "real" non- terminals and others to be considered as
> > "terminals", So I automated that by checking whether the same symbol can
> > be resolved in more than one way, then it is a "real" non-terminal, and
> > by checking if the right hand side of the rule only contains characters,
> > then it is considered as "terminal. And that fundamental information is
> > automatically used to provide appropriate error messages and auto
> > completion in a fully automated way.
> 
> It's unclear to me whether you do this at generation time, or at parse time.

At parse time.

> I understand that you want to be able to manipulate the symbols themselves.
> What I am arguing about it that you probably don't need them as strings.
> I tend to think you need them as an enum, just like the tokens, so that
> you can map them to some real string or whatever other treatment.  But
> handing them as strings used as keys in some container would be a useless
> cost compared to an enum.

Enums would be more clean of course (even though string comparisons are cheap
nowadays). But there should still be an easy way IMO to convert that enum into
a string representation. Otherwise developers would always need to write
tables manually for doing these enum -> string conversions.

Best regards,
Christian Schoenebeck