Re: Enhancement request: enabling Variant in C parsers
> 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 - 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. > >> 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. >> And the location filename gets set to null. > > Not clear enough, but elaborate. The location you initialize in .yy is not the one the .ll uses, so it returns a location with filename set to null, which is then what is reported, that is nothing. I changed: calc++.cc: make global extern calcxx_driver driver; calc++-scanner.ll: calcxx_driver driver; // The location of the current token. static yy::location loc(&driver.file);
Re: Enhancement request: enabling Variant in C parsers
> 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 - 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.
This style with local.mk perhaps comes from an age where Automake was not as
smart. I use a Makefile.am.
In addition, it might benefit from using say a
#define YYSTYPE double
to illustrate how one sets ones own type.
This is the only preprocessor macro that remains in the C++ parser, so perhaps
it should be replaced with a
%semantic-type {...}
or something.
Re: Enhancement request: enabling Variant in C parsers
> 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.
> 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.
> This is the only preprocessor macro that remains in the C++ parser,
There’s no such thing in calc++-parser. Be sure to read from the
build tree, not the source tree.
> so perhaps it should be replaced with a
> %semantic-type {...}
> or something.
‘something’ is '%define api.value.type'.
Re: Problem with new version of bison's code
> Le 20 août 2018 à 19:49, Rici Lake a écrit : > > Update: my patch has been committed to kannel's SVN, and there is at least > one report that it fixes the build problem. Thanks a lot!
Re: Enhancement request: enabling Variant in C parsers
> 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 reused > >Suggested by Rici Lake. >https://lists.gnu.org/archive/html/bug-bison/2018-08/msg00033.html > >* doc/bison.texi: Complete description of the first node in the main >@menu. >(Push Decl): Remove the 'experimental' warnings about push parser. >Clarify that the push parser object can be reused in several parses. Installed.
Re: Enhancement request: enabling Variant in C parsers
> 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. You say the input file is broken: which one, and please show what you have. Or copy-paste from the terminal what goes wrong. >>> And the location filename gets set to null. >> >> Not clear enough, but elaborate. > > The location you initialize in .yy is not the one the .ll uses, so it returns > a location with filename set to null, which is then what is reported, that is > nothing. I changed: > > calc++.cc: make global > extern calcxx_driver driver; > > calc++-scanner.ll: > calcxx_driver driver; > > // The location of the current token. > static yy::location loc(&driver.file); Good catch, thanks!
Re: Enhancement request: enabling Variant in C parsers
> 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.
>> 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.
>> 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.
Re: Enhancement request: enabling Variant in C parsers
> 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 one, say error.txt, and
>> input.txt.
>
> That’s not specific. You say the input file is broken:
> which one, and please show what you have. Or copy-paste from
> the terminal what goes wrong.
The file named "input" in the calc++ example directory. :-)
And the location filename gets set to null.
>>>
>>> Not clear enough, but elaborate.
>>
>> The location you initialize in .yy is not the one the .ll uses, so it
>> returns a location with filename set to null, which is then what is
>> reported, that is nothing. I changed:
>>
>> calc++.cc: make global
>> extern calcxx_driver driver;
>>
>> calc++-scanner.ll:
>> calcxx_driver driver;
>>
>> // The location of the current token.
>> static yy::location loc(&driver.file);
>
> Good catch, thanks!
You'll have to think over if you want it pure. The filename may belongs to the
lexer if the parser needs not know about it.
Also the .yy initialization can be:
%initial-action
{
// Initialize the initial location.
@$.initialize(&driver.file);
};
Re: Enhancement request: enabling Variant in C parsers
> 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: >> 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. You say the input file is broken: >>> which one, and please show what you have. Or copy-paste from >>> the terminal what goes wrong. >> >> The file named « input" in the calc++ example directory. :-) > > Ahhh! There is no such file in the tarball, and therefore it is > not installed either. > > It’s created by the test when it is run, so you are actually > referring to ‘make check'. See the corresponding test > (examples/calc++/calc++.test) to see what `input` is expected > to be. > > The input file is not part of the examples as presented to the > users, it’s part of Bison test suite. And it’s only an artifact. > It should be removed when `make check` is done (I’ll fix that). 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.
Re: Enhancement request: enabling Variant in C parsers
> 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
