Hi Christian,
Thanks for the detailed answer.
> Le 9 juin 2020 à 15:14, Christian Schoenebeck <schoeneb...@crudebyte.com> 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!
