On Wednesday, January 8, 2025 2:20:37 PM CET r0ller wrote:
> Hi All,I'm trying to make use of custom error reporting and define the
> function yyreport_syntax_error() in the epilogue based on the documentation
> at https://www.gnu.org/software/bison/manual/html_node/Syntax-Error->
> Reporting-Func
On Tuesday, November 14, 2023 6:16:56 PM CET James K. Lowden wrote:
> On Wed, 15 Nov 2023 12:35:31 +0100
> Christian Schoenebeck wrote:
[...]
> Bison has seen a lot of technical improvement over the years. There is
> a C++ interface, a push interface, and a choice of generated pars
On Monday, November 13, 2023 12:13:55 AM CET James K. Lowden wrote:
> On Mon, 13 Nov 2023 20:15:44 +0100
> Christian Schoenebeck wrote:
>
> > > You tell me: what is a "Bison token code"?
> >
> > Look, I am not judging how well Bison is documented or wha
On Sunday, November 12, 2023 6:18:30 PM CET James K. Lowden wrote:
> On Mon, 13 Nov 2023 12:33:57 +0100
> Christian Schoenebeck wrote:
>
> > > When I look up #899, NOT, I get "NOT". But when I look up #900,
> > > NE, I get "'<'"
On Friday, November 10, 2023 1:57:59 AM CET James K. Lowden wrote:
> I can't seem to look up token names in yytname correctly using enum
> yytokentype.
>
> At the end of enum yytokentype, I have
>
> END_UNSTRING = 893,/* END_UNSTRING */
> END_WRITE = 894, /* END
erns.
For instance right now, whenever you have some input, the lexer must always
assume that any of the patterns may match. Whereas a tied grammar/lexer would
have the knowledge that for a certain parser state, only a small set of
patterns may match, which in turn would allow much more compact and faster
lexer branches for those states to be generated.
Best regards,
Christian Schoenebeck
On Freitag, 1. Oktober 2021 09:37:52 CEST Hans Åberg wrote:
> > On 28 Sep 2021, at 14:10, Christian Schoenebeck
> > wrote:>
> > On Montag, 27. September 2021 22:07:33 CEST Hans Åberg wrote:
> >>>> In order to generate better syntax error messages writing out
vel column & line span, and sometimes you
rather need low level raw byte position & byte length in the input data
stream.
Best regards,
Christian Schoenebeck
flicts. But if you
are going to add actions for handling math formulas then you probably want the
order in which the actions are executed to be correct, otherwise it would
yield in wrong results when evaluating expressions.
Best regards,
Christian Schoenebeck
g/archive/html/help-bison/2019-01/msg00013.html
I mean it is probably just a theoretical issue. The intention of that
definition was presumably not prohibiting commercial meta compilers, but in
the end it would be a gray zone to be considered as part of your
responsibility.
Best regards,
Christian Schoenebeck
;
> vardeclaration:
> type_ptr identifierlist ;
> example: int *b
>
> identifierlist :
> identifierwithdefault |
> identifierlist ',' identifierwithdefault
>
> identifierwithdefault:
> identifier |
> identifier '=' expression |
> identifier '[' INTNUM ']'
>
>
> type_ptr :
> type_ptr '*' |
> type ;
> example: int
Best regards,
Christian Schoenebeck
; Le 19 janv. 2021 à 13:36, Christian Schoenebeck
a écrit :
> >> diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4
> >> index cfd4e6ed7..3496450e2 100644
> >> --- a/data/skeletons/c++.m4
> >> +++ b/data/skeletons/c++.m4
> >> @@ -309,7 +309,9 @@ m4
me you are still
always using std::move() below though.
Despite the compiler crash, which shouldn't happen of course, that should be
either noexcept & std::move() otherwise no std::move() at all, at least with
recent compilers. Not sure what your intention was to leave std::move()
unconditionally there, I guess for pre-C++11 compilers?
Best regards,
Christian Schoenebeck
stedlab;
> #endif
You would be dealing with internals, but AFAICS that internal label already
exists for decades, so it'll be okay as pragmatic solution I guess.
> > }
> > memset(p, 0, n);
>
> What about using calloc() rather than the combination of malloc() and
> memset()?
Yes, calloc() would be an appropriate replacement.
Best regards,
Christian Schoenebeck
file side and then determine
whether there is already a macro or symbol "FOO" defined in any source or
included header file?
Best regards,
Christian Schoenebeck
fprintf(stderr, "Parser: malloc(%s) with size %zu failed.
Aborting.\n",
expr, n);
abort();
}
memset(p, 0, n);
return p;
}
...
variable_assignment: VARIABLE '[' expr ']' ASSIGNMENT expr {
const char* varName = $1;
const size_t varSize = $3;
Foo* foo = PARSER_ALLOC(varSize * sizeof(Foo));
...
}
Best regards,
Christian Schoenebeck
jects
that are typically built in rather conservative environments, as it is the
case with Bison. Right now you typically need a bleeding edge Meson version
for being able to build more complex projects with Meson.
Qemu just switched to Meson; they pull a specific Meson version in-tree as git
submodule in the Qemu git repository. But really, that's an effort on its own.
Best regards,
Christian Schoenebeck
assume this is not an uncommon issue, what's the canonical solution?
What's your intention with comments, do you really need them on grammar side
for something? If yes, example purpose? Usually comments are just dropped on
lexer side, in which case you don't "return" anything on lexer side, and that
would probably alrady fix the problem you have, without adjusting anything on
grammar side that is.
Best regards,
Christian Schoenebeck
s (KDevelop, Kate, Kwrite, ...) also share the same syntax
highlighting backend and also do Flex highlighting correctly.
Some proprietary IDEs do not. For instance Xcode (12.2) displays these
incorrectly as comments on column 0. I just filed a bug report with Apple.
Best regards,
Christian Schoenebeck
eport end was a bit uncaring and
> hostile imo. I wasted too much time with it.
Please do us all a favour and use quote characters when you are quoting
somebody in your emails. It's unnecessary to let people decipher who wrote
what, as any email client can do that for you automatically, including the one
you are using there.
Best regards,
Christian Schoenebeck
point. Of course you can also create a structure in the very
same way by just adjusting the scanner actions. My point was you don't need a
parser (e.g. Bison) for such simple tasks, as preprocessor tasks are usually
and entirely covered by the scanner.
Best regards,
Christian Schoenebeck
\"[^"]*\" {
yyextra->token = StringLiteralToken(yytext);
return STRING_LITERAL_TYPE;
}
/* Number literal */
{DIGIT}+("."{DIGIT}+)? {
yyextra->token = NumberLiteralToken(yytext);
return NUMBER_LITERAL_TYPE;
}
/* Other tokens */
<*>. {
yyextra->token = OtherToken(yytext);
return OTHER_TOKEN_TYPE;
}
%%
Best regards,
Christian Schoenebeck
ive should check my use of
> >> French expressions, I'm not I'm using it properly :-).
> >>
> >> I can add *more* options, provide better alternatives, but Bison cannot
> >> afford to drop features just like that.
> >
> > Please do, I would appreciate if you share ideas!
>
> You mean, ideas of new features? I have cited a bunch of them already,
> and others are in the TODO file, but currently those that are close to my
> heart include:
>
> - support for multiple start symbols
Hmm... I don't see a big advantage of that in practice. It just saves you one
non-terminal.
> - integration of the scanner
Definitely, and that context-aware! ;-)
> - scoped precedence/associativity directives
Like in which way did you imagine that?
> - grammar modules
Probably nice to have, but I think not a big game changer in practice either.
> - rewritten glr.cc
Ok, I don't know the implementation details there that made you thinking that.
> - elimination of chain rules
Elimination by transformation to what?
Best regards,
Christian Schoenebeck
On Samstag, 18. Juli 2020 08:47:07 CEST Akim Demaille wrote:
> > Le 14 juil. 2020 à 13:31, Christian Schoenebeck
> > a écrit :
> >
> > On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote:
> >
> > For the 'married' parser, in the form imagine
On Dienstag, 14. Juli 2020 07:02:36 CEST Akim Demaille wrote:
> > Le 13 juil. 2020 à 07:56, Akim Demaille a écrit :
> >> Le 12 juil. 2020 à 19:47, Christian Schoenebeck
> >> a écrit :>>
> >> And BTW:
> >>> The GLR parsers require a compiler
On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote:
> > Le 12 juil. 2020 à 19:47, Christian Schoenebeck
a écrit :
> >> Additionally,the programmer must fully understand how
> >> and when the parser handles tokens, otherwise subtle bugsmay be
> >> intr
is rarely happens, and for many grammars it is
> possible to prove that it cannot happen.
... why isn't it O(n^3)? Or more specifically, which common GLR fork
optimization(s) are yet missing?
And BTW:
> The GLR parsers require a compiler for ISO C89 or later.
Tough requirement! ;-)
Best regards,
Christian Schoenebeck
anguages. And on the other side it would
eventually allow to design languages in a much more user friendly and flexible
way as well, as it would be straight-forward e.g. to restrict keywords (or
other patterns) to certain grammar contexts only.
Best regards,
Christian Schoenebeck
BASIC examples could
much easier (less complex) and elegantly be solved with a monolithicly
combined parser-scanner, as the parser could then out of the box detect
keywords depending on the grammar context.
Best regards,
Christian Schoenebeck
On Montag, 6. Juli 2020 21:48:19 CEST Maury Markowitz wrote:
> > On Jul 6, 2020, at 1:30 PM, Christian Schoenebeck
> > wrote: Which would resolve that ambiguity of
> > your example, if it actually exists, as I have never seen "FOREX" as
> > valid BASIC loop defin
I
> hope you don't all mind the duplicate.
> > On Jul 6, 2020, at 9:04 AM, Christian Schoenebeck
> > wrote:
> > You would simply add a RegEx pattern & rule like this:
> Consider two snippets in home-computer-era BASIC:
>
> FOREX=10
>
> and:
>
&g
On Montag, 6. Juli 2020 14:00:17 CEST Maury Markowitz wrote:
> > On Jul 4, 2020, at 6:46 AM, Christian Schoenebeck
> > wrote: The only thing that people are missing
> > once in a while on scanner side is unicode support
>
> I am missing the capability to support gramm
having the scanner functionality
directly in Bison instead, and saying goodbye to all those scanner state stack
hacks which often end up in a huge mess that people can hardly read, and often
lead to severe misbehaviours on edge cases of certain inputs.
Akim, was there any progress in the IP discussion for that to become possible
one day or is that previously discussed merge off the table?
Best regards,
Christian Schoenebeck
ich case regenerating with a more recent Bison would
> probably address the issue.
>
> But I sense you are referring to something different.
I really meant compiler errors, not warnings. I could not tell you the details
of these issues right now, as I often don't get detailed information about the
precise circumstances that lead to these compilation errors (e.g. precise
versions of compiler, flex, bison, ... probably any source changes who knows).
I usually also don't ask though, because the fix is so easy: regenerate it.
Best regards,
Christian Schoenebeck
On Dienstag, 9. Juni 2020 07:58:56 CEST Akim Demaille wrote:
> Hi Christian,
>
> > Le 8 juin 2020 à 13:32, Christian Schoenebeck
> > a écrit :>
> > On Montag, 8. Juni 2020 07:46:27 CEST Akim Demaille wrote:
> >> YYTERROR was not a documented feature. I'
On Montag, 8. Juni 2020 07:46:27 CEST Akim Demaille wrote:
> Hi Christian,
>
> CC'd to help-bison FTR.
>
> > Le 7 juin 2020 à 18:17, Christian Schoenebeck
> > a écrit :
> >
> > Hi Akim,
> >
> > I just realized that you removed YYTERROR f
accessing yytname[] directly with custom code on top of skeletons is
currently the only way to achieve the features we discussed in this thread.
> Cheers, and best wishes for 2020!
Yep, all the best and see you in 2020!
Best regards,
Christian Schoenebeck
Because character literal
sequences are indeed commonly used to handle scanner tasks on parser side and
I haven't seen issues with the latter in years.
Best regards,
Christian Schoenebeck
ons always as spans
(first_line, first_column, last_line, last_column).
Best regards,
Christian Schoenebeck
you find it an appropriate time. Thanks
Akim!
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
On Freitag, 10. Mai 2019 19:43:03 CEST Akim Demaille wrote:
> > Le 10 mai 2019 à 16:28, Christian Schoenebeck
> > a écrit :>
> > On Freitag, 10. Mai 2019 06:57:00 CEST Derek Clegg wrote:
> >> In fact, I do not think error messages in the generated parser should be
eatment. 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
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
se being honest, probably everybody
has a completely different opinion about how an appropriate representation of
an error message in a final software release should look like exactly.
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https:
> | ^
>
> looks stupid; "char", "identifier" and "" should be translated.
Well, my point was that translation is trivial. An average developer is
certainly able to solve required translation tasks very easily by custom code
if required. The other aspects though, looking ahead on a parser states with
custom code is not trivial. So my point was: on doubt it might make sense to
concentrate on the mandatory aspect of providing access to the raw symbol
names and ignoring the translation aspects for now.
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
scussed here is that it is currently not trivial to achieve them
with own, custom code. You do need to have a profound knowledge of how the
internal skeleton algorithm works to be able to extra polate the missing
information by custom code on top of it.
Best regards,
Christian Schoenebeck
__
On Montag, 18. Februar 2019 12:22:27 CET Christian Schoenebeck wrote:
> On Sonntag, 17. Februar 2019 21:37:26 CET Peng Yu wrote:
> > Because I want to use the previously allocated memory, I don't want to
> > call "rs_init(&yylval->str)" in any action. So YYST
ce between struct or union is handled by the C/C++ compiler, not by
Bison.
Any reason that you don't want to use C++ and e.g. std::string instead of your
pure C and garbage collector solution?
Best regards,
Christian Schoenebeck
___
help-bison@g
string "error", and for 257 the string "$undefined".
Likewise you can do the same for your own tokens.
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
ilt-in terminals YYEOF and YYEMPTY.
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
. In such a scenario, if you were limited to only resolve the very next
token, you would only be able to show the user a list of single character(s)
expected next, like "expected either 'a', 'g', 'c'" instead of showing the
user e.g. "expected either
GPLv3 Bison version ... well you get the idea.
And this issue is not just limited to meta compilers. There are many other non
obvious use cases where you might theoretically get into the same situation.
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
is is not a parser generator. Well, it was obviously not your intention. But
now consider somebody uses that conversion tool for converting a parser
originally written in programming language A to language B.
Right, your Bison generated conversion tool
no, in that case the GPL automatically applies to your generated parser file as
well. Note that the pure potential of your generated parser to be capable of
generating another parser would be sufficient for the GPL to apply!
Best regards,
Christian Schoenebeck
_
ur choice, so long as that work isn't itself a
parser generator using the skeleton ..."
Considering the amount of tools Apple has which in turn create new
intermediate source files, I can imagine why they fear ending up with GPL3
issues was too dangerous.
Best regards,
Chr
how to design and implement it, and
you think you can already identify negative consequences? I think you are
probably too focused at Bison's current design if you really think that your
negative expectations above would be true.
> I hope Bison cont
On Friday 27 June 2014 18:12:34 Hans Aberg wrote:
> On 27 Jun 2014, at 14:40, Christian Schoenebeck
wrote:
> > 1. Strong separation between "lexer" and "parser" has its historical
> >
> >reasons, but it makes things often quite problemati
of tables), instead of providing
convenient and detailed access to the higher level informations of
the
parse states, i.e. for the tasks you described. Being able to access
those informations conveniently at runtime, is far more important
today than s
he original process had when it called fork(). So that's probably
easier than what you were trying to achieve by dealing with environment
variables.
That's a very basic programming question though, not really related to Bison.
Best regards,
Christian Schoenebeck
_
On Thursday 30 January 2014 19:11:11 Hans Aberg wrote:
> On 30 Jan 2014, at 17:55, Christian Schoenebeck
wrote:
> > On Thursday 30 January 2014 18:03:28 Hans Aberg wrote:
> >> I recall some others in the past that have written on interactive
> >> parsers showing c
(i.e. all actions and all
custom lexer/parser code you might have in place)?
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
On Friday 07 February 2014 16:43:00 Christian Schoenebeck wrote:
> I noticed that tables yyprhs[] and yyrhs[] are not generated by default
> anymore since Bison 3. I tried adding "%debug" and also tried "%define
> parse.trace", but that did not bring them ba
Hi!
I noticed that tables yyprhs[] and yyrhs[] are not generated by default
anymore since Bison 3. I tried adding "%debug" and also tried "%define
parse.trace", but that did not bring them back. How can those 2 tables be
generated by Bison 3 now?
Best regards,
C
-) So I am estimating this risk to be low in the
mid or even long term. And of course minor things change, like defines etc.,
but that's trivial to maintain when new Bison versions are released.
Best regards,
Christian Schoenebeck
___
help-b
generated
yyfoo tables) to break with future Bison versions that soon.
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
m trying to get at. ;-)
Is there already some kind of solution for that in Bison? Or does anybody know
a work around to achieve something like that?
Best regards,
Christian Schoenebeck
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Es geschah am Thursday, 21. June 2007 20:18 als Hans Aberg schrieb:
> How should %atomic be implemented?
How it "should" be implemented is the wrong question, or at least addressed to
the wrong person, since I'm not familiar enough with the bison implementation
yet. That was actually my main rea
Es geschah am Thursday, 21. June 2007 22:15 als Hans Aberg schrieb:
> > How it "should" be implemented is the wrong question, or at least
> > addressed to
> > the wrong person, since I'm not familiar enough with the bison
> > implementation
> > yet. That was actually my main reason to write to this
Es geschah am Thursday, 21. June 2007 20:18 als Hans Aberg schrieb:
> How should %atomic be implemented?
How it "should" be implemented is the wrong question, or at least addressed to
the wrong person, since I'm not familiar enough with the bison implementation
yet. That was actually my main rea
Es geschah am Thursday, 21. June 2007 16:08 als Hans Aberg schrieb:
> No, in this model, the lexer matches patterns as usual, only when the
> match has been made, returns the multibyte character byte by byte.
Doesn't make a difference. The problem for the UTF-8 part is still the same,
no matter i
Es geschah am Thursday, 21. June 2007 13:12 als Hans Aberg schrieb:
> On the one hand, you try to use Bison for something it wasn't
> designed for, so unless to can come up with good motivations, getting
> the change is unlikely to happen.
Depends on which motivation you mean. A motivation for doi
Hi!
I would like to improve the quality of error messages produced by
yysyntax_error(). I know the theory behind LALR(1) parsers, but unfortunately
I'm not very used to the bison skeleton parser implementation yet, so I hope
you can help me a bit.
First the reason: I'm strictly opposed to havi
71 matches
Mail list logo
