Re: how to get left hand side symbol in action

Hi Christian,

Thanks for the detailed answer.

> Le 9 juin 2020 à 15:14, Christian Schoenebeck <[email protected]> a écrit :
> 
> On Dienstag, 9. Juni 2020 07:58:56 CEST Akim Demaille wrote:
> 
> For instance in that linked example I was not using a scanner at all, but 
> instead pseudo non-terminals actually being terminals e.g.:
> 
> CREATE  :  'C''R''E''A''T''E'
>        ;
> 
> So in that use case the next expected token should be returned as "CREATE", 
> not just "C".

Yes, indeed.

> So my code looks at the individual grammar rules to decide 
> whether the corresponding symbol should be interpreted as terminal or non-
> terminal accordingly.
> 
> Then the other thing is that my auto completion code actually auto completes 
> as much as possible, not just the very next token. So if you have a highly 
> redundant language (like it is often the case with human readable protocols), 
> then it would auto complete several tokens up to the point where an actual 
> input decision would have to be made. For instance, say you were writing an 
> SQL parser and the user typed ('^' illustrating the cursor position):
> 
> 	CREATE TABLE foo (id bigint UNIQUE U^
> 
> then it would auto complete it to:
> 
> 	CREATE TABLE foo (id bigint UNIQUE USING INDEX TABLESPACE ^

Ain't the two features the same one?  I mean, the completion of U as USING
could be a repeated concatenation of S I N G.

> So it would have added 3 tokens (not just one), spaces between them and space 
> past the last one, where it finally would need to stop as the next token would 
> be a user specified name (i.e. a user decision has to be made).

That's very nice!


> And BTW this was also the 1st compilation issue with a recent Bison version in 
> more than 6 years. That's quite good I would say, so also thanks for taking 
> care of not breaking things! :)

Nothing *public* is expected to break :)


>> I'm curious: why don't you require a modern Bison, *and ship the generated
>> files*?  Waiting for the end users to have installed recent versions of the
>> generators does not buy you a lot of freedom, and forces you to uglify your
>> parser.
> 
> Reason for still supporting Bison 2: the license. Remember I also use this for 
> commercial projects.

Given that the GPL does not apply to the generated parser, I don't see what
worries you hear.


> About shipping pregenerated parsers: I already do, for release tarballs that 
> is (not for development versions though, which these reports were about).
> 
> Actually most reports about parser related compilation errors were always 
> about users compiling a pregenerated one (i.e. release tarballs),

I don't understand this.  If you released a pregenerated parser, it obviously
works, you wouldn't have released otherwise.  So what kind of failure can
users find that would be fixed by regenerating?

I can see one scenario: the tarball is old and newer compilers generate
new warnings.  In which case regenerating with a more recent Bison would
probably address the issue.

But I sense you are referring to something different.

> in which 
> case regenerating the parser with Bison always fixed the issue for them.



Again, thanks for the answer!