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 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
>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, 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
> 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, 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
> 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 à 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 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.
> 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
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!
> 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
> 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, 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
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,
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 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, 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!
> 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
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 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
>
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
> 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
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
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,
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
> 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,
> 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 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
> 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 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 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
> 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
> 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 à 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 à 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
> 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
> 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: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 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
> 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.
> 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: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
> 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
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 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!
> 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
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.
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
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
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,
> > 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
> 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
else{
>
> $3->expr=ReachExpIf(move($1->expr),move($3->expr),move($5->expr));
> $3->type_c.is_const &=
> $1->type_c.is_const;
>
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
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
61 matches
Mail list logo