Given that Bison has the ability to (and does) generate a parser for
itself, is there any possibility of removing all %code tags in future
releases.
The mechanics of this removal is to construct a dependency graph,
determine whether there are cycles in the graph and what to do about
them, and
On 2022-06-17 10:58, slipbits wrote:
> Given that Bison has the ability to (and does) generate a parser for
> itself, is there any possibility of removing all %code tags in future
> releases.
This is not clear; remove what from where? For what purpose?
How does Bison being partially self-hosted
Hello Kaz !
As I said before here in the list, I also have that need for other
purposes (compare, reuse, convert, ... grammars) and did that first with
byacc and then lemon and bison here
https://github.com/mingodad/lalr-parser-test
For example here is what I call naked grammar from bison 3.
Hi Kaz;
Sorry about taking so long to respond.
Before I say anything, let me state that all comments are due to my
understanding of Bison. This understanding is a result of reading the
User's Manual exclusively. That being said, you have more knowledge than
I because you know the decision pro
Hi,
> Le 20 juin 2022 à 22:02, slipbits a écrit :
>
> Hi Kaz;
>
> Sorry about taking so long to respond.
Compared to my speed, you are almost relativistic.
> > By tag, do you want to remove the %code feature?
> > From where?
>
> It looks like it is possible to remove all s from all %code b
Hi Akim;
After a while I decided, why not. I might just as well answer you.
Thanks for your response. This will be a summary and not a
point-to-point answer. It is clear that Bison does not want to, and
will not, proceed forwards, and so, take this as me just grumbling in
my cave.
I do thi
Arthur Schwarz wrote:
> After a while I decided, why not. I might just as well answer you.
So let me take the freedom to reply to your answer instead of Akim. ;)
> "... fragile magic ..." Ahem. No sense going into hyperbole. This one is
> out-of-line and unnecessary. The idea proposed is to co
On 2022-09-06 13:54, Arthur Schwarz wrote:
> Hi Akim;
>
> After a while I decided, why not. I might just as well answer you. Thanks for
> your response. This will be a summary and not a point-to-point answer. It is
> clear that Bison does not want to, and will not, proceed forwards, and so,
>
Hi,
Frank and Kaz developed very good points. Let me add a few more.
> Le 10 sept. 2022 à 07:40, Kaz Kylheku a écrit :
>
> When you think about it, a tool like Yacc should have a simple specification:
> most of the code snippets in the second language should appear in the output
> in the sam
Hi Kaz (and the Gang);
Sorry about the delay. Life intrudes. I am answering the 'mail' from
latest to earliest, so, most likely I am answering things already
addressed. Let's just say I'm addlepated and leave it at that (translate
that - I dare you).
You're reading too much into what needs t
Arthur Schwarz wrote:
> You're reading too much into what needs to be done.
> [...] but I don't think it will take considerable code.
I know you're not a troll, but honestly, you're starting to sound
like one. Akim, Kaz and I have given several specific arguments.
You do not address them at all a
Hi
I am using Bison for a grammar that brings conflicting names like the
following use case:
%token IDENTIFIER "IDENTIFIER" // the keyword IDENTIFIER
%token identifier // the terminal identifier
for lower case name
Bison generates then
#ifndef YYTOKENTYPE
# d
Hi Francis,
> Le 30 août 2015 à 12:21, Francis ANDRE a
> écrit :
>
> Hi
>
> I am using Bison for a grammar that brings conflicting names like the
> following use case:
>
> %token IDENTIFIER "IDENTIFIER" // the keyword IDENTIFIER
> %token identifier // the termin
Dear developers,
It would be nice to enable Variant in C parsers - these obviously have to be
compiled with a C++ compiler.
Motivation:
* I (and probably some other people) find some aspects of C++ parsers
unwieldy, so prefer the good old C parsers in my C++ programs.
* Maintaining/refactorin
Hi!
> Le 12 juil. 2016 à 23:12, Victor Khomenko a
> écrit :
>
> Dear developers,
>
> It would be nice to enable Variant in C parsers - these obviously have to be
> compiled with a C++ compiler.
>
> Motivation:
> * I (and probably some other people) find some aspects of C++ parsers
> unwield
else{
>
> $3->expr=ReachExpIf(move($1->expr),move($3->expr),move($5->expr));
> $3->type_c.is_const &=
> $1->type_c.is_const;
>
> Le 18 août 2018 à 17:32, Victor Khomenko a
> écrit :
>
> Hi Akim,
Hey!
>> I don’t understand what you mean here, by monolithic. The parser needs a
>> single type to store all the possible types, so, yes, it is monolithic.
>
> Well, I meant that bison looks inside the union and knows its
Hi Akim,
> > My main concern is memory management. With Variant the destructors are
> called automatically, but in C parsers I currently have to use %union with
> pointers and explicit "delete". This is not exception-safe and results in ugly
> code littered with "delete" statements. (Using api.val
Hi Victor,
Please, keep the CC to bug-bison.
> Le 18 août 2018 à 22:52, Victor Khomenko a
> écrit :
>
>>> %code requires
>>> {
>>> struct my_value {
>>> enum{...} kind;
>>> union{...} u;
>>> };
>>> }
>>> %define api.value.type {struct my_value}
>>> %token INT "
Hi Akim,
> Bison’s variants are for C++, I don’t think porting this to C would be
> trivial.
> They are made to live in a C++ container, not a C array. Existing variants
> show
> a path though, granted.
If a c++ compiler is to be used, having a c++ container is ok. Generally, the c
vs c++ dic
Hey!
> Le 19 août 2018 à 14:24, Victor Khomenko a
> écrit :
>
> Hi Akim,
>
>> Bison’s variants are for C++, I don’t think porting this to C would be
>> trivial.
>> They are made to live in a C++ container, not a C array. Existing variants
>> show
>> a path though, granted.
>
> If a c++ com
Vaguely on this topic, since you seem to be working on a new release:
On Sun, Aug 19, 2018, 10:23 Akim Demaille wrote:
>
> Note that you don’t have anything to do to reset the parser, all the
> problem is actually the scanner. The parser object holds no state,
> everything is local to yyparse.
Hi!
> Le 19 août 2018 à 18:21, Rici Lake a écrit :
>
> Vaguely on this topic, since you seem to be working on a new release:
Yup.
> On Sun, Aug 19, 2018, 10:23 Akim Demaille wrote:
>
>>
>> Note that you don’t have anything to do to reset the parser, all the
>> problem is actually the scanne
> On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>
>>> I would strongly suggest that you look at the examples/ in Bison, the C++
>>> calculator
>>
>> I did look at it - this example scared me off c++ parsers :-(
>
> Really??? Then I failed. Can you be more specific?
I noticed: It does not
Hi Victor,
Thanks for your answer. Please, keep all this public, keep the CC.
I don’t have time right time to answer in details, I’ll do that
during the weekend. I also want to wrap 3.1 with what we have
now.
Thanks!
> Le 19 août 2018 à 22:11, Victor Khomenko a
> écrit :
>
> Hi Akim,
>
>>
> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>
>
>> On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>>
I would strongly suggest that you look at the examples/ in Bison, the C++
calculator
>>>
>>> I did look at it - this example scared me off c++ parsers :-(
>>
>> Really??? Th
> On 23 Aug 2018, at 07:34, Akim Demaille wrote:
>
>> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>>
>>
>>> On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>>>
> I would strongly suggest that you look at the examples/ in Bison, the C++
> calculator
I did look at it - th
> On 23 Aug 2018, at 07:34, Akim Demaille wrote:
>
>> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>>
>>
>>> On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>>>
> I would strongly suggest that you look at the examples/ in Bison, the C++
> calculator
I did look at it - th
> Le 23 août 2018 à 10:34, Hans Åberg a écrit :
>
> This style with local.mk perhaps comes from an age where Automake was not as
> smart. I use a Makefile.am.
Totally unrelated. I use local.mk (should be local.am) because it’s
included from the top-level Makefile.am. There’s a single Makef
> Le 19 août 2018 à 21:02, Akim Demaille a écrit :
>
> Too good to be left in the mailing list archive. WDYT?
>
>
> commit 7ff6b7bbcab88ce667d97ae37171a9cfc9ec8d66
> Author: Akim Demaille
> Date: Sun Aug 19 20:53:59 2018 +0200
>
>doc: clarify that the push parser object can be reuse
> Le 23 août 2018 à 10:18, Hans Åberg a écrit :
>
>>
>> On 23 Aug 2018, at 07:34, Akim Demaille wrote:
>>> The input file is broken.
>>
>> You’ll have to be more specific, WFM.
>
> It generates an error. You might have more than one, say error.txt, and
> input.txt.
That’s not specific.
> On 23 Aug 2018, at 13:14, Akim Demaille wrote:
>
>> Le 23 août 2018 à 10:34, Hans Åberg a écrit :
>>
>> This style with local.mk perhaps comes from an age where Automake was not as
>> smart. I use a Makefile.am.
>
> Totally unrelated. I use local.mk (should be local.am) because it’s
> in
> On 23 Aug 2018, at 13:17, Akim Demaille wrote:
>
>> Le 23 août 2018 à 10:18, Hans Åberg a écrit :
>>
>>>
>>> On 23 Aug 2018, at 07:34, Akim Demaille wrote:
The input file is broken.
>>>
>>> You’ll have to be more specific, WFM.
>>
>> It generates an error. You might have more than
> On 23 Aug 2018, at 14:18, Akim Demaille wrote:
>
>
>> Le 23 août 2018 à 14:13, Hans Åberg a écrit :
>>
>>
>>> On 23 Aug 2018, at 13:17, Akim Demaille wrote:
>>>
Le 23 août 2018 à 10:18, Hans Åberg a écrit :
>
> On 23 Aug 2018, at 07:34, Akim Demaille wrote:
>>
> On 23 Aug 2018, at 13:14, Akim Demaille wrote:
>
> ‘something’ is '%define api.value.type'.
When used, the macro still overrides it, which might cause confusion if one
happens to use both (like the old definition happens to linger). That is,
%define api.value.type {a_type}
produces in .hh
> Le 23 août 2018 à 18:23, Hans Åberg a écrit :
>
>
>> On 23 Aug 2018, at 13:14, Akim Demaille wrote:
>>
>> ‘something’ is '%define api.value.type'.
>
> When used, the macro still overrides it, which might cause confusion if one
> happens to use both (like the old definition happens to li
> Le 23 août 2018 à 14:24, Hans Åberg a écrit :
>
>
> [The examples]
> It might be good with a self-contained calc++ directory, with some input
> files, so that one can copy it, and start experimenting. An idea might be to
> add comments to the lexer, so that they can be added to the input f
> Le 23 août 2018 à 14:09, Hans Åberg a écrit :
>
>
>> On 23 Aug 2018, at 13:14, Akim Demaille wrote:
>>
>>> Le 23 août 2018 à 10:34, Hans Åberg a écrit :
>>>
>>> This style with local.mk perhaps comes from an age where Automake was not
>>> as smart. I use a Makefile.am.
>>
>> Totally u
> Le 23 août 2018 à 07:34, Akim Demaille a écrit :
>
>
>
>> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>>
>>
>>> On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>>>
> I would strongly suggest that you look at the examples/ in Bison, the C++
> calculator
I did look a
> On 25 Aug 2018, at 07:54, Akim Demaille wrote:
>
>> Le 23 août 2018 à 14:24, Hans Åberg a écrit :
>>
>> [The examples]
>> It might be good with a self-contained calc++ directory, with some input
>> files, so that one can copy it, and start experimenting. An idea might be to
>> add comment
> On 25 Aug 2018, at 07:50, Akim Demaille wrote:
>
>> Le 23 août 2018 à 18:23, Hans Åberg a écrit :
>>
>>
>>> On 23 Aug 2018, at 13:14, Akim Demaille wrote:
>>>
>>> ‘something’ is '%define api.value.type'.
>>
>> When used, the macro still overrides it, which might cause confusion if one
> On 25 Aug 2018, at 08:10, Akim Demaille wrote:
>
>> Le 23 août 2018 à 14:09, Hans Åberg a écrit :
>>
>>
>>> On 23 Aug 2018, at 13:14, Akim Demaille wrote:
>>>
Le 23 août 2018 à 10:34, Hans Åberg a écrit :
This style with local.mk perhaps comes from an age where Automake
> On 25 Aug 2018, at 08:51, Akim Demaille wrote:
>
>> Le 23 août 2018 à 07:34, Akim Demaille a écrit :
>>
>>> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>>>
>>>
On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>> I would strongly suggest that you look at the examples/ in B
> On 25 Aug 2018, at 08:51, Akim Demaille wrote:
>
>> Le 23 août 2018 à 07:34, Akim Demaille a écrit :
>>
>>> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>>>
>>>
On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>> I would strongly suggest that you look at the examples/ in B
> On 25 Aug 2018, at 08:51, Akim Demaille wrote:
>
>> Le 23 août 2018 à 07:34, Akim Demaille a écrit :
>>
>>> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>>>
>>>
On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>> I would strongly suggest that you look at the examples/ in B
> On 25 Aug 2018, at 08:51, Akim Demaille wrote:
>
>> Le 23 août 2018 à 07:34, Akim Demaille a écrit :
>>
>>> Le 21 août 2018 à 10:46, Hans Åberg a écrit :
>>>
>>>
On 19 Aug 2018, at 17:23, Akim Demaille wrote:
>> I would strongly suggest that you look at the examples/ in B
> Le 25 août 2018 à 14:56, Hans Åberg a écrit :
>
> I was thinking of adding something like
> "#".*\n{ yylloc.lines(1); yylloc.step(); }
Ah, ok.
> Then the example file could have comments like:
> # Run calc++
> # Causes a deliberate error. Should report ...
>
> The idea is that
> On 26 Aug 2018, at 07:22, Akim Demaille wrote:
>
>> Le 25 août 2018 à 14:56, Hans Åberg a écrit :
>>
>> Then the example file could have comments like:
>> # Run calc++
>> # Causes a deliberate error. Should report ...
>>
>> The idea is that coming new to bison copies the calc++ directory,
Hi Victor,
We’ve made some progress in the last couple of months.
Bison 3.2 is not released yet, but it should happen within
a couple of weeks.
> Le 19 août 2018 à 22:11, Victor Khomenko a
> écrit :
>
> Hi Akim,
>
>>> I did look at it - this example scared me off c++ parsers :-(
>>
>> Really
Hi Akim,
Nice to hear that there has been a lot of progress! I'm a bit overwhelmed with
teaching and other stuff, but will try to read this carefully in the next few
days.
Some quick reactions:
* My 8 parsers are in the same codebase, which comprises several static
libraries and several exe
Hi Victor!
> Le 24 oct. 2018 à 18:14, Victor Khomenko a
> écrit :
>
>** You could use
> std::copy(v.begin(), v.end(),
> std::ostream_iterator(std::cout, ", "));
> to print out a vector of strings.
I’m an adept of ’no raw loops’, but I always dislike this idiom. It’s
Hi Akim,
> That’s a matter of style, and I disagree. Sure, it’s _needed_ for decltype on
> incoming arguments, but it’s also just the right thing.
> C was wrong, and is still wrong about arrays, pointers, and functions.
> Even Go people, who are clearly the real heirs of C, have departed from C
>
El jue., 25 oct. 2018 a las 3:21, Victor Khomenko (<
victor.khome...@newcastle.ac.uk>) escribió:
>
> Well, when in Rome do as Romans do... This chapter is for C/C++
> programmers, not Go. Some of them are not even familiar with the new
> syntax. If you check cppreference website, they don't use tr
Hi!
> Le 25 oct. 2018 à 10:09, Victor Khomenko a
> écrit :
>
> Hi Akim,
> Well, when in Rome do as Romans do... This chapter is for C/C++ programmers,
> not Go. Some of them are not even familiar with the new syntax.
Well, my point is that C++ has started to fix things.
You can you auto to le
Hi Akim, Rici,
Re trailing return types: It’s a minor issue (in the context of bison manual),
let’s agree to disagree to avoid starting a full-blown religious warfare.
Re flex: The whole flex/bison interface is clunky, so no surprise people invent
tricks. Some parser generators (ANTLR, JavaCC)
Hi all!
> Le 26 oct. 2018 à 11:09, Victor Khomenko a
> écrit :
>
> Hi Akim, Rici,
>
> Re trailing return types: It’s a minor issue (in the context of bison
> manual), let’s agree to disagree to avoid starting a full-blown religious
> warfare.
There was no risk. We’re too old for this, we a
Hi Akim,
Re flex/bison, ANTLR, and racing cars:
I think bison has a number of cool features, in particular nice error handling,
support for full LR(1), and glr. They definitely give it an edge over other
parser generators.
Where it fails: Mundane things like clunky interface with a scanner, to
Hi Victor,
I agree with Akim, that currently we need to maintain bison’s current design to
support all the use cases it support.
There was an attempt I created a while ago to generate AST representation in
XML out of bison parsing.
If what you are looking for is to simplify the way the ASTs ar
Hi, Akim.
> I did look at it - this example scared me off c++ parsers :-(
I completely agree.
I will talk about Bison 3.2.2 manual.
If the user looks in manual and tries to find some C++ example, then he finds
either too simple example ("10.1.1 A Simple C++ Example", which doesn't use
Flex), eit
> Le 6 déc. 2018 à 23:07, Askar Safin a écrit :
>
> Hi, Akim.
Hi Askar!
>> I did look at it - this example scared me off c++ parsers :-(
> I completely agree.
> I will talk about Bison 3.2.2 manual.
> If the user looks in manual and tries to find some C++ example, then he finds
> either too
Hi!
> Le 7 déc. 2018 à 20:30, Uxio Prego a écrit :
>
> I don't know of this division of parsers in pure and impure.
>
> Are pure approaches like GLR while LALR(k) are impure?
No, it's unrelated to the parsing technology, it's only a question
of API: whether you exchange information with the sc
> On 8 Dec 2018, at 07:19, Akim Demaille wrote:
>
> Hi!
>
>> Le 7 déc. 2018 à 20:30, Uxio Prego a écrit :
>>
>> I don't know of this division of parsers in pure and impure.
>>
>> Are pure approaches like GLR while LALR(k) are impure?
>
> No, it's unrelated to the parsing technology, it's
> Le 8 déc. 2018 à 17:06, Askar Safin a écrit :
>
> Hi, Akim.
Hi Askar!
>> This is the Bison manual, and we don't try to compete with the "flex &
>> bison" book.
> I tried to websearch this book and found it in Google Books. Google Books
> showed me preview and suggested to buy full copy.
> Le 9 déc. 2018 à 06:53, Akim Demaille a écrit :
>
>> * I give exact command lines to run my example, you don't
>
> It's an ongoing effort. If you look the history of the examples you'll see
> that they are getting Makefiles and READMEs. In particular calc++ has its
> Makefile, so your c
> Le 9 déc. 2018 à 06:53, Akim Demaille a écrit :
>
>> I still think that the manual should give at least one C+Flex+Bison example
>> without locations and at least one "C++"+Flex+Bison example without
>> locations.
>
> I will not agree for two, but if you keep on insisting, then I guess th
> Le 9 déc. 2018 à 17:06, Askar Safin a écrit :
>
> Hi, Akim.
>
>> So I still believe the documentation, with rpcalc and mfcalc are the simple
>> examples you are asking for, and then the flex example (in examples/c, not
>> in the documentation) should be good starting points, with location
Hi Askar,
> Le 9 déc. 2018 à 22:12, Askar Safin a écrit :
>
> Hi, Akim. Thanks a lot for your last two patches to /examples/.
Thanks for saying!
> Just a little note: your "!!", say, here: "if (!!getenv ("YYDEBUG"))" is very
> ugly. It is difficult to understand, what is going on.
Well, it's
Hi, judging these docs and multiple changelog entries mentioning
`%define api.pure` as a replacement for `%pure-parser`, and the
latter being turned to wrapper on the former at some point, etc.;
I would expect that tests/input.at recommend, for `%pure_parser`,
`%define api.pure` optionally `%defin
Hi, Akim.
>This is the Bison manual, and we don't try to compete with the "flex & bison"
>book.
I tried to websearch this book and found it in Google Books. Google Books
showed me preview and suggested to buy full copy. Also I found some free online
full copy, but I wonder whether it is legal.
Hi, Akim.
>So I still believe the documentation, with rpcalc and mfcalc are the simple
>examples you are asking for, and then the flex example (in examples/c, not in
>the documentation) should be good starting points, with locations.
What examples/c you are talking about? I don't see "c" directo
Hi, Akim. Thanks a lot for your last two patches to /examples/.
Just a little note: your "!!", say, here: "if (!!getenv ("YYDEBUG"))" is very
ugly. It is difficult to understand, what is going on. Please, remove "!!" in
whole source tree.
==
Askar Safin
http://vk.com/safinaskar
>Please report this to them! The Makefiles are to be installed together with
>the READMEs. Here is what I have currently when I run make install:
I reported. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916084
==
Askar Safin
http://vk.com/safinaskar
Hi Victor!
> Le 24 oct. 2018 à 18:14, Victor Khomenko a
> écrit :
>
>** No need to implement to_string() in the simple example, better use
> https://en.cppreference.com/w/cpp/string/basic_string/to_string
Gee… Of course. It’s there because it started in C++98, and I
forgot to get rid of
> Le 24 oct. 2018 à 18:14, Victor Khomenko a
> écrit :
>
> * In Sect 10.1.2 it would be good to mention that location.hh can be
> suppressed (it's explained only later in the text).
I installed this:
commit 73a822e63610daa613174de19fce25a1304d0f35
Author: Akim Demaille
Date: Wed Oct 24
74 matches
Mail list logo
