Re: Enhancement request: enabling Variant in C parsers
> 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 coming new to bison copies the calc++ directory, compiles
> it, sees there are some example files to run, and ready to start
> experimenting.
The calculator is dumb: it expects a single expression, so
there would be enough space to demonstrate all this. And
I want to keep it simple.
The README should suffice, shouldn’t it?
Re: Enhancement request: enabling Variant in C parsers
> 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 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 have a Makefile, so one can’t just copy it and >>> compile. >> >> Why not adding one, indeed. > > I installed this. Ignore last message, I didn't make a proper install. It works fine. It is necessary to have a \n before the ^d, though.
Re: Enhancement request: enabling Variant in C parsers
> 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 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 have a Makefile, so one can’t just copy it and >>> compile. >> >> Why not adding one, indeed. > > I installed this. Ignore last message, I ran the calc++ example without ./configure && make. But now I get the following error, with extra quotes in the #line directives. They do not appear if I compile the same example with bison 3.0.5. So it seems to be a bug in the pre-release. $ make ../../src/bison -o parser.cc parser.yy g++ -c -ocalc++.o calc++.cc g++ -c -odriver.o driver.cc g++ -c -oparser.o parser.cc parser.cc:334:10: error: """parser" is not a valid filename #line 42 ""parser.yy"" // lalr1.cc:635 ^~~~ parser.cc:341:10: error: """parser" is not a valid filename #line 42 ""parser.yy"" // lalr1.cc:635 ^~~~ parser.cc:348:10: error: """parser" is not a valid filename #line 42 ""parser.yy"" // lalr1.cc:635 ^~~~ make: *** [parser.o] Error 1
Re: Enhancement request: enabling Variant in C parsers
> 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 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 have a Makefile, so one can’t just copy it and >>> compile. >> >> Why not adding one, indeed. > > I installed this. The calc++ Makefile in the pre-release produces this error: $ make make: *** No rule to make target `parser.hh', needed by `calc++.o'. Stop.
Re: Enhancement request: enabling Variant in C parsers
> 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 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 have a Makefile, so one can’t just copy it and >>> compile. >> >> Why not adding one, indeed. > > I installed this. Which branch is this, if taking it down with git?
Re: Enhancement request: enabling Variant in C parsers
> 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 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 Makefile
>>> in the end, and that’s on purpose. I do not want recursive Makefiles.
>>
>> Why not? I use local.mk, too, in simple cases.
>
> Look for « recursive make considered harmful », there are tons of
> pages about that.
I use it to cut build times by compiling in a subdirectory, then one can move
to the root directory to check that it is consistent. There are also hits for
“non-recursive make considered harmful”. :-)
so perhaps it should be replaced with a
%semantic-type {...}
or something.
>>>
>>> ‘something’ is '%define api.value.type'.
>>
>> So use it in the example, simply for illustration of the feature.
>
> The example uses it, for variants.
Sorry I was confused by the untyped parser and the "define".
But it strikes me that one possibility with std::variant might be to allow
non-terminals to have multiple types, though I do not know whether it is
useful. After the parse, one would then check the possible values one got.
Re: Enhancement request: enabling Variant in C parsers
> 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
>> happens to use both (like the old definition happens to linger). That is,
>> %define api.value.type {a_type}
>> produces in .hh parser class:
>> #ifndef YYSTYPE
>> /// Symbol semantic values.
>> typedef a_type semantic_type;
>> #else
>> typedef YYSTYPE semantic_type;
>> #endif
>
> I don’t think it’s too much of a problem, and it’s going to be
> painful to handle. If you think it is worth it, please submit a patch :)
You are the man. But I just found it confusing when doing the change to the new
API.
Re: Enhancement request: enabling Variant in C parsers
> 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 comments to the lexer, so that they can be added to the input files.
>> Nothing advanced, just a little more than what is now.
>
> I don’t understand what you mean with « add comments to the lexer,
> so that they can be added to the input files ».
>
> I’m not convinced that an input file would be needed, but a README
> in calc++/, with examples, would be useful, indeed.
>
> FTR, the scanner looks like this currently:
>
>
I was thinking of adding something like
"#".*\n{ yylloc.lines(1); yylloc.step(); }
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, compiles it,
sees there are some example files to run, and ready to start experimenting.
Release candidate for Bison 3.1
Hi all!
Please, give a try to the following release candidate. You may
also extract it directly from the master branch of the git repository.
https://www.lrde.epita.fr/~akim/private/bison/bison-3.0.5.100-de641.tar.gz
https://www.lrde.epita.fr/~akim/private/bison/bison-3.0.5.100-de641.tar.xz
It would be extremely helpful if you could run the test suite
and report problems that you might encounter. I am especially
interested in compilers others than GCC and Clang.
_Please_, also use this release candidate on your pet project,
and, possibly, check the diffs on the generated parsers.
Thanks in advance!
* Noteworthy changes in release 3.1
** Backward incompatible changes
Compiling Bison now requires a C99 compiler---as announced during the
release of Bison 3.0, five years ago. Generated parsers do not require a
C99 compiler.
Support for DJGPP, which have been unmaintained and untested for years, is
obsolete. Unless there is activity to revive it, the next release of Bison
will have it removed.
** New features
*** Typed midrule actions
Because their type is unknown to Bison, the values of midrule actions are
not treated like the others: they don't have %printer and %destructor
support. It also prevents C++ (Bison) variants to handle them properly.
Typed midrule actions address these issues. Instead of:
exp: { $$ = 1; } { $$ = 2; } { $$ = $1 + $2; }
write:
exp: { $$ = 1; } { $$ = 2; } { $$ = $1 + $2; }
*** Reports include the type of the symbols
The sections about terminal and nonterminal symbols of the '*.output' file
now specify their declared type. For instance, for:
%token NUM
the report now shows '':
Terminals, with rules where they appear
NUM (258) 5
*** Diagnostics about useless rules
In the following grammar, the 'exp' nonterminal is trivially useless. So,
of course, its rules are useless too.
%%
input: '0' | exp
exp: exp '+' exp | exp '-' exp | '(' exp ')'
Previously all the useless rules were reported, including those whose
left-hand side is the 'exp' nonterminal:
warning: 1 nonterminal useless in grammar [-Wother]
warning: 4 rules useless in grammar [-Wother]
2.14-16: warning: nonterminal useless in grammar: exp [-Wother]
input: '0' | exp
^^^
2.14-16: warning: rule useless in grammar [-Wother]
input: '0' | exp
^^^
3.6-16: warning: rule useless in grammar [-Wother]
exp: exp '+' exp | exp '-' exp | '(' exp ')'
^^^
3.20-30: warning: rule useless in grammar [-Wother]
exp: exp '+' exp | exp '-' exp | '(' exp ')'
^^^
3.34-44: warning: rule useless in grammar [-Wother]
exp: exp '+' exp | exp '-' exp | '(' exp ')'
^^^
Now, rules whose left-hand side symbol is useless are no longer reported
as useless. The locations of the errors have also been adjusted to point
to the first use of the nonterminal as a left-hand side of a rule:
warning: 1 nonterminal useless in grammar [-Wother]
warning: 4 rules useless in grammar [-Wother]
3.1-3: warning: nonterminal useless in grammar: exp [-Wother]
exp: exp '+' exp | exp '-' exp | '(' exp ')'
^^^
2.14-16: warning: rule useless in grammar [-Wother]
input: '0' | exp
^^^
*** C++: Generated parsers can be compiled with -fno-exceptions (lalr1.cc)
When compiled with exceptions disabled, the generated parsers no longer
uses try/catch clauses.
Currently only GCC and Clang are supported.
** Documentation
*** A demonstration of variants
A new example was added (installed in .../share/doc/bison/examples),
'variant.yy', which shows how to use (Bison) variants in C++.
The other examples were made nicer to read.
*** Some features are no longer 'experimental'
The following features, mature enough, are no longer flagged as
experimental in the documentation: push parsers, default %printer and
%destructor (typed: <*> and untyped: <>), %define api.value.type union and
variant, Java parsers, XML output, LR family (lr, ielr, lalr), and
semantic predicates (%?).
** Bug fixes
*** GLR: Predicates support broken by #line directives
Predicates (%?) in GLR such as
widget:
%? {new_syntax} 'w' id new_args
| %?{!new_syntax} 'w' id old_args
were issued with #lines in the middle of C code.
*** Printer and destructor with broken #line directives
The #line directives were not properly escaped when emitting the code for
%printer/%destructor, which resulted in compiler errors if there are
backslashes or double-quotes in the grammar file name.
*** Portability on ICC
The Intel compiler claims compatibility with GCC, yet rejects its _Pragma.
Generated parsers now work around this.
*** Various
There were several small fixes in the test suite and in the build system,
many warnings in bison and in
Re: Enhancement request: enabling Variant in C parsers
> 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 at it - this example scared me off c++ parsers :-(
>>>
>>> Really??? Then I failed. Can you be more specific?
>>
>> I noticed: It does not have a Makefile, so one can’t just copy it and
>> compile.
>
> Why not adding one, indeed.
I installed this.
commit de64159e7f3e0b1b7acd8c23cbd76495fe17c311
Author: Akim Demaille
Date: Sat Aug 25 08:04:37 2018 +0200
examples: calc++: a Makefile and a README
* examples/calc++/Makefile, examples/calc++/README: New.
* examples/calc++/local.mk: Ship and install them.
* doc/bison.texi: Formatting changes.
diff --git a/README b/README
index 5370f335..8689bab8 100644
--- a/README
+++ b/README
@@ -41,6 +41,7 @@ note that the range specifies every single year in that
closed interval.
Local Variables:
mode: outline
+fill-column: 76
End:
Copyright (C) 1992, 1998-1999, 2003-2005, 2008-2015, 2018 Free Software
diff --git a/doc/bison.texi b/doc/bison.texi
index 6cd52917..b7945343 100644
--- a/doc/bison.texi
+++ b/doc/bison.texi
@@ -11066,14 +11066,13 @@ use characters such as @code{':'}, they must be
declared with @code{%token}.
@node A Complete C++ Example
@subsection A Complete C++ Example
-This section demonstrates the use of a C++ parser with a simple but
-complete example. This example should be available on your system,
-ready to compile, in the directory @dfn{.../bison/examples/calc++}. It
-focuses on the use of Bison, therefore the design of the various C++
-classes is very naive: no accessors, no encapsulation of members etc.
-We will use a Lex scanner, and more precisely, a Flex scanner, to
-demonstrate the various interactions. A hand-written scanner is
-actually easier to interface with.
+This section demonstrates the use of a C++ parser with a simple but complete
+example. This example should be available on your system, ready to compile,
+in the directory @dfn{.../share/doc/bison/examples/calc++}. It focuses on
+the use of Bison, therefore the design of the various C++ classes is very
+naive: no accessors, no encapsulation of members etc. We will use a Lex
+scanner, and more precisely, a Flex scanner, to demonstrate the various
+interactions. A hand-written scanner is actually easier to interface with.
@menu
* Calc++ --- C++ Calculator:: The specifications
@@ -11086,11 +11085,10 @@ actually easier to interface with.
@node Calc++ --- C++ Calculator
@subsubsection Calc++ --- C++ Calculator
-Of course the grammar is dedicated to arithmetics, a single
-expression, possibly preceded by variable assignments. An
-environment containing possibly predefined variables such as
-@code{one} and @code{two}, is exchanged with the parser. An example
-of valid input follows.
+Of course the grammar is dedicated to arithmetics, a single expression,
+possibly preceded by variable assignments. An environment containing
+possibly predefined variables such as @code{one} and @code{two}, is
+exchanged with the parser. An example of valid input follows.
@example
three := 3
diff --git a/examples/README b/examples/README
index bfdd8c68..9780d829 100644
--- a/examples/README
+++ b/examples/README
@@ -5,18 +5,19 @@ A C example of a multi-function calculator. Extracted from
the
documentation.
* calc++
-A C++ version of the canonical example for parsers: a calculator.
-Also uses Flex for the scanner. Extracted from the documentation.
+A C++ version of the canonical example for parsers: a calculator. Also uses
+Flex for the scanner. Extracted from the documentation.
* variant.yy
-A C++ example that uses variants (they allow to use any C++ type as
-semantic value type) and symbol constructors (they ensure consistency
-between declared token type and effective semantic value).
+A C++ example that uses variants (they allow to use any C++ type as semantic
+value type) and symbol constructors (they ensure consistency between
+declared token type and effective semantic value).
-
Local Variables:
mode: outline
+fill-column: 76
End:
Copyright (C) 2018 Free Software Foundation, Inc.
diff --git a/examples/calc++/Makefile b/examples/calc++/Makefile
new file mode 100644
index ..6b6c4998
--- /dev/null
+++ b/examples/calc++/Makefile
@@ -0,0 +1,27 @@
+# This Makefile is designed to be simple and readable. It does not
+# aim at portability. It requires GNU Make.
+
+BISON = bison
+CXX = g++
+FLEX = flex
+
+all: calc++
+
+%.cc %.hh: %.yy
+ $(BISON) $(BISONFLAGS) -o $*.cc $<
+
+%.cc: %.ll
+ $(FLEX) $(FLEXFLAGS) -o$@ $<
+
+%.o: %.cc
+ $(CXX) $(CXXFLAGS) -c -o$@ $<
+
+calc++: calc++.o driver.o parser.o scanner.o
+ $(CXX) -o $@ $^
+
+calc++.o: parser.hh
+parser.o: parser.hh
+scanner.o: parser.hh
+
Re: Enhancement request: enabling Variant in C parsers
> 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 unrelated. I use local.mk (should be local.am) because it’s
>> included from the top-level Makefile.am. There’s a single Makefile
>> in the end, and that’s on purpose. I do not want recursive Makefiles.
>
> Why not? I use local.mk, too, in simple cases.
Look for « recursive make considered harmful », there are tons of
pages about that.
>>> In addition, it might benefit from using say a
>>> #define YYSTYPE double
>>> to illustrate how one sets ones own type.
>>
>> What example are you referring to? Also, you may have noticed that
>> I try to avoid using the preprocessor in favor of Bison directives.
>
> For the example, you do not set the type explicitly, so it ends up as a
> default, so those that want to change need to go to the manual for that.
No, the type is explicitly set. Just check it.
>
>>> so perhaps it should be replaced with a
>>> %semantic-type {...}
>>> or something.
>>
>> ‘something’ is '%define api.value.type'.
>
> So use it in the example, simply for illustration of the feature.
The example uses it, for variants.
