Re: bison-2.7 released [stable]

On 29 Dec 2012, at 13:31, Akim Demaille a...@lrde.epita.fr wrote: Le 29 déc. 2012 à 13:26, Hans Aberg haber...@telia.com a écrit : But should not 'configure' check if the STIX Fonts and LuaTex are available and use them - this would bring proper UTF-8 support. No really, this is too rare

Re: Bison C++ mid-rule value lost with variants

> On 29 Jun 2017, at 15:55, Piotr Marcińczyk wrote: > > I supposedly found a bug in lalr1.cc skeleton with variant semantic type. You might check if std::variant, of C++17, can be used instead. Cf. http://en.cppreference.com/w/cpp/utility/variant > When using mid-rule

Re: YYEOF shouldn't be defined with bison -y

> On 5 Dec 2017, at 02:32, Dimitrios Apostolou wrote: > > I am generating a parser as part of a different project, and that project is > configured with AC_PROG_YACC. As such, it invokes Bison with "-y" option, and > I would expect that Bison tries hard to fail when the parser

Re: Compilation error in Mac OS High Sierra

> On 28 Sep 2017, at 02:19, Rodrigo de Oliveira > wrote: > Apparently something changed in the new Mac OS that is breaking the building > process of Bison. Could anyone help me with this issue? It is fixed by [1], but it is currently only in the archive 'maint'

Re: Compilation error in Mac OS High Sierra

> On 28 Sep 2017, at 02:19, Rodrigo de Oliveira > wrote: > Apparently something changed in the new Mac OS that is breaking the building > process of Bison. Could anyone help me with this issue? It is fixed by [1], but it is currently only in the archive 'maint'

Re: Bison fails to run because of vasnprintf() changes in macOS 10.13

> On 9 Dec 2017, at 14:40, Hans Åberg <haber...@telia.com> wrote: > > >> On 17 Sep 2017, at 07:19, Paul Eggert <egg...@cs.ucla.edu> wrote: >> >> I've updated the Bison maint branch to use the latest Gnulib, so this bug >> should be fixe

Re: Bison fails to run because of vasnprintf() changes in macOS 10.13

> On 17 Sep 2017, at 07:19, Paul Eggert wrote: > > I've updated the Bison maint branch to use the latest Gnulib, so this bug > should be fixed there now. Thanks for reporting the problem. There was no version release, but the archive version has several issues, tried on

Re: Bison 3.0.5

> On 20 May 2018, at 10:44, Akim Demaille wrote: > I think Bison 3.0.5 is ready. However, before making it widely > available it would be nice if people could give it a try on their > projects. On MacOS 10.13.4, all tests passed with clang and gcc 7.3.0 (MacPorts),

Re: Any help needed?

> On 20 May 2018, at 10:49, Akim Demaille <a...@lrde.epita.fr> wrote: > >> Le 20 mai 2018 à 10:33, Hans Åberg <haber...@telia.com> a écrit : >> >> >>> On 20 May 2018, at 09:42, Akim Demaille <a...@lrde.epita.fr> wrote: >>> >>

Re: Any help needed?

> On 20 May 2018, at 09:42, Akim Demaille wrote: > >> Le 20 mai 2018 à 00:09, Vlad Vladov a écrit : >> >> What is the oldest gcc we are planning on supporting? > > I would say any version that supports ANSI C. The current version C11?

Re: Bison 3.0.5

> On 22 May 2018, at 08:16, Akim Demaille <a...@lrde.epita.fr> wrote: > >> Le 20 mai 2018 à 13:06, Hans Åberg <haber...@telia.com> a écrit : >> >> >>> On 20 May 2018, at 10:44, Akim Demaille <a...@lrde.epita.fr> wrote: >> >>&g

Re: Bison C++ mid-rule value lost with variants

> On 17 Jun 2018, at 16:02, Akim Demaille wrote: > Or go for a lighter syntax... Indeed. > expr: > NUM > | expr { $$ = 42; } '+' NUM { std::cout << $2 << '\n'; }; > Personally, I prefer the prefix forms, but they don’t blend > nicely with named references: > > expr: > NUM > | expr { $$ =

Re: bison-3.0.5 released [stable]

> On 18 Jun 2018, at 07:14, Akim Demaille wrote: > >> Le 2 juin 2018 à 19:08, Hans Åberg a écrit : >> >>> On 28 May 2018, at 07:33, Akim Demaille wrote: >>> >>> We are happy to announce the release of GNU Bison 3.0.5, a bug fix >>&g

Re: bison-3.0.5 released [stable]

> On 28 May 2018, at 19:28, Akim Demaille wrote: > >> Le 28 mai 2018 à 10:40, Hans Åberg a écrit : >> >> >>> On 28 May 2018, at 07:33, Akim Demaille wrote: >>> >>> We are happy to announce the release of GNU Bison 3.0.5, a bug fix >

Re: bison-3.0.5 released [stable]

> On 28 May 2018, at 07:33, Akim Demaille wrote: > > We are happy to announce the release of GNU Bison 3.0.5, a bug fix > release. There is a bug in 'make install-pdf', because in the directories po/ and runtime-po/, the Makefile does not have it, terminating before reaching the doc/

Re: bison-3.0.5 released [stable]

> On 28 May 2018, at 07:33, Akim Demaille wrote: > > We are happy to announce the release of GNU Bison 3.0.5, a bug fix > release. ... > Here are the compressed sources: > ftp://ftp.gnu.org/gnu/bison/bison-3.0.5.tar.gz (4.1MB) >

Dangling else and LR

An example of where LALR does not work but LR does is the dangling else example in the Bison manual, "Specifying Precedence Only", sec. 5.3.3, if one swaps the precedences. Might be added there.

Re: [PATCH 0/7] RFC: typed midrule actions

> On 5 Aug 2018, at 16:09, Akim Demaille wrote: > > I have been hesitating between 'midrule' and 'mid-rule'; both are used > in user visible places (be it the documentation, error messages, or > even command line options). We should stick to a single spelling. > > Years ago Joel normalized

Re: Enhancement request: enabling Variant in C parsers

> 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

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

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 : >>>> >

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: >>&g

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, t

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 experi

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: >>&g

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: >>&g

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: >>&g

Re: position.hh compile error C4146 (VisualStudio 2017)

> On 18 Aug 2018, at 17:03, Akim Demaille wrote: > > I don’t remember why I wrote it this way, but today I don’t care much about > INT_MIN here. I think the code has become too complex for what it meant to > do. Also, maybe I should have sticked to int instead of trying to unsigned, > but

Re: Bison C++ mid-rule value lost with variants

> On 27 Aug 2018, at 22:10, Akim Demaille wrote: > >> Most of my porting work, apart from writing the new skeletons, was >> general grammar cleanup and conversion of semantic types from raw >> pointers and containers to smart pointers and other RAII classes >> (which was my main goal of the

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/

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/

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.

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 spe

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 : >>

Re: Enhancement request: enabling Variant in C parsers

> 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

Bison lexer

> On 29 Aug 2018, at 00:31, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>> On 27 Aug 2018, at 22:10, Akim Demaille wrote: >>> >>>> Most of my porting work, apart from writing the new skeletons, was >>>> general grammar cleanup a

Re: Bison lexer

> On 31 Aug 2018, at 22:26, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>> For a start, I didn't have very good experience communicating with >>> Flex maintainer(s?) who seemed rather nonchalant WRT gcc warnings >>> etc. in the generated cod

Re: Bison lexer

> On 1 Sep 2018, at 00:12, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>> I haven't used gcc-8 yet, but how is this relevant? If anything, I >>> expect newer gcc versions to produce more warnings (usually useful) >>> which flex might also suffer fr

Re: bison-2.7 and MacOS 10.13

> On 6 Sep 2018, at 12:43, David Barto wrote: > > For some reason I can’t get Bison-2.7 to run on MacOS 10.13. As I’ve posted > in the past, I need the older version of bison (for the time being) for our > older grammar files. > > Anyone understand why this is happening? The same version of

Re: C++11 move semantics

> On 8 Mar 2018, at 00:33, Frank Heckenbach wrote: > >>> Sure, it's not required (nothing about the C++ mode is), but it >>> might be convenient for the user as it avoids a trap. I have a >>> number of such rules in my grammars, and if you hadn't mentioned it, >>> I'd

Re: C++11 move semantics

> On 11 Mar 2018, at 18:29, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >> In old computers, such a limit might have been seen as necessary. > > I don't think so. I think I was due to the implementation in C where > dynamic dat

Re: C++11 move semantics

> On 11 Mar 2018, at 17:01, Frank Heckenbach wrote: > >>> Here's an example which springs to mind: deeply nested right-associative >>> operators. As you will see if you follow the link, the issue showed up in a >>> real application and the problem was not obvious to the

Re: C++11 move semantics

> On 11 Mar 2018, at 19:06, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> I don't think so. I think I was due to the implementation in C where >>> dynamic data structures are much more effort to write. Otherwise >>>

Re: syntax_error constructor is declared inline

> On 12 Mar 2018, at 20:08, Vishal V wrote: > > Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' > when generating a C++ scanner, which results in undefined references when > the exception is thrown from a separate scanner file. Since this is

Re: syntax_error constructor is declared inline

> On 13 Mar 2018, at 23:23, Frank Heckenbach wrote: > >> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline' >> when generating a C++ scanner, which results in undefined references when >> the exception is thrown from a separate scanner file. Since

Re: C++11 move semantics

> On 9 Mar 2018, at 22:59, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> We are speaking about different things here: In Yacc grammar one [can't] >>>> drop the ";". >>> >>> OK, bu

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 04:03, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> On 13 Mar 2018, at 23:23, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >>> >>>> Bison 3.0.4 marks the constructor for the s

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 15:46, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >> It is sort of strange in C++ to not have a header, and having >> inlines not in those. > > Sure, I think it was just a mistake. Bison puts inlines f

Re: syntax_error constructor is declared inline

> On 15 Mar 2018, at 07:41, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> It could be deliberate to avoid them being exported. But C++ now >>>> has namespaces, which cann be used to avoid name conflicts. >>>

Re: C++11 move semantics

> On 9 Mar 2018, at 02:26, Frank Heckenbach wrote: > >> We are speaking about different things here: In Yacc grammar one [can't] >> drop the ";". > > OK, but how is this relevant here? An example of Bison not being Yacc. >>> Since std::stack moves instead of copying

Re: C++11 move semantics

> On 9 Mar 2018, at 02:26, Frank Heckenbach wrote: > >> We are speaking about different things here: In Yacc grammar one [can't] >> drop the ";". > > OK, but how is this relevant here? An example of Bison not being Yacc. >>> Since std::stack moves instead of copying

Re: C++11 move semantics

> On 6 Mar 2018, at 23:48, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >> Otherwise, there is no reason for Bison to be Yacc compatible, >> except for the special Yacc mode, which Paul Eggert worked on >> becoming POSIX compl

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 19:22, Kaz Kylheku wrote: > > Here is a rule from a production Makefile to remove // comments in Lex code > that prevent it from being C90 Flex is a separate project: https://github.com/westes/flex

Re: syntax_error constructor is declared inline

> On 14 Mar 2018, at 23:04, Frank Heckenbach wrote: > >> It could be deliberate to avoid them being exported. But C++ now >> has namespaces, which cann be used to avoid name conflicts. > > It's all in a namespace anyway (yy by default) and we're only > talking about a

Re: C++17 skeleton with move semantics and std::variant

> On 8 Apr 2018, at 23:05, Frank Heckenbach wrote: > - Uses std::variant (C++17) instead of Bison's own variant > implementation. > > If you don't have C++17 support yet, you can use an alternative > variant implementation such as https://github.com/mpark/variant .

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 18:16, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> One can have a preprocessor macro '#if (__cplusplus == 201703L) ...', >>>> would it be of interest. >>> >>> What would it

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 18:16, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> One can have a preprocessor macro '#if (__cplusplus == 201703L) ...', >>>> would it be of interest. >>> >>> What would it

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 16:55, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> But, anyway, GCC7 supports C++17. >>> >>> Yes, and I've also tested it with gcc-6 with mpark's variant. >> >> One can have a

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 18:19, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> On 9 Apr 2018, at 17:04, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >>> >>>> The option >>>> %define extra_

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 16:55, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> Akim Demaille gave two motivations on not using this: avoiding the >>>> external dependency, and the overhead of storing the type. I think >&g

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 17:04, Frank Heckenbach wrote: > >> The option >> %define extra_header_prefix {calc-c++17-} >> does not seem to work: I got both location.hh and position.hh. > > Ah, sorry, I think you need to apply my original patch from > >

Re: C++17 skeleton with move semantics and std::variant

> On 10 Apr 2018, at 17:24, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> Don't forget to copy location.cc back to /usr/local/share/bison/. >>> As I said, this file is the same between the old (C++03) and new >>> (C++1

Re: C++17 skeleton with move semantics and std::variant

> On 10 Apr 2018, at 17:24, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >> Rename, if possible, all these patched files to location-c++17.cc, >> stack-c++17.hh, etc, as they are not in the original distribution. > > I called it

Re: C++17 skeleton with move semantics and std::variant

> On 14 Apr 2018, at 07:33, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> On 10 Apr 2018, at 17:24, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >>> >>> Hans Åberg wrote: >>> >>&g

Re: C++17 skeleton with move semantics and std::variant

> On 14 Apr 2018, at 10:19, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> Before it gets integrated into the Bison distribution, you might >>>> want to put it in the package source directory. >>> >>

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 20:36, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> So, try this: >>>> >>>> cd /usr/share/bison >>>> sudo patch < /path/to/extra-header-prefix.diff >>>>

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 20:25, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> So, try this: >>> >>> cd /usr/share/bison >>> sudo patch < /path/to/extra-header-prefix.diff >>> cd /your/source/dir

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 20:15, Hans Åberg <haber...@telia.com> wrote: > >> On 9 Apr 2018, at 19:19, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >> >> Hans Åberg wrote: >> >> You should apply the patch in /usr/share/bison (or your respec

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 18:17, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> So for C++ we could either go back and disable the static type >>> checking completely, or do full dynamic checking (which std::variant >>> does

Re: C++17 skeleton with move semantics and std::variant

> On 9 Apr 2018, at 00:17, Frank Heckenbach wrote: > >>> On 8 Apr 2018, at 23:05, Frank Heckenbach wrote: >> >>> - Uses std::variant (C++17) instead of Bison's own variant >>> implementation. >>> >>> If you don't have C++17 support yet, you

Re: C++17 skeleton with move semantics and std::variant

> On 8 Apr 2018, at 23:05, Frank Heckenbach wrote: > > Following the discussion starting in > http://lists.gnu.org/archive/html/bug-bison/2018-03/msg2.html > I have implemented a Bison skeleton for C++17 supporting features > such as move semantics and std::variant,

Re: Bison Skeleton: irksome GPL license.

> On 18 Apr 2018, at 15:56, Kaz Kylheku wrote: > > What I'm saying is that Flex 2.5.35 in an Ubuntu installation I'm > using has this behavior: > > /* comment */ > %{ > #include "header.h" > %} > /* ... */ > > The header comment is propagated to the lex.yy.c file. It's

Re: C++17 skeleton with move semantics and std::variant

> On 18 Apr 2018, at 11:19, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >> Indeed. Others, may not want to patch their installations even it >> they can, as it may cause problems for other packages. Say if one >> write

Re: C++17 skeleton with move semantics and std::variant

> On 18 Apr 2018, at 10:03, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> On 14 Apr 2018, at 10:19, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >>> >>> Hans Åberg wrote: >>> >>>

Re: Bison Skeleton: irksome GPL license.

> On 18 Apr 2018, at 02:16, Kaz Kylheku <k...@kylheku.com> wrote: > > On 2018-04-16 13:27, Hans Åberg wrote: >>> On 16 Apr 2018, at 22:01, Kaz Kylheku <k...@kylheku.com> wrote: >>> When Bison turns a .y file into a y.tab.c, it removes any license >>&

Re: Bison Skeleton: irksome GPL license.

> On 16 Apr 2018, at 22:01, Kaz Kylheku wrote: > > When Bison turns a .y file into a y.tab.c, it removes any license > header from the .y file, and asserts its own license over the file > (which comes from the parser skeleton). > *Replacing* the copyright notice to assert

Re: Automatially move from $n (was: C++11 move semantics)

> On 1 Apr 2018, at 16:43, Frank Heckenbach wrote: > > I've now changed my grammars to use my new C++17 skeletons with > std::variant and move semantics. So far, it seems to work fine. > > As expected, they now contain a lot of "std::move ($n)" expressions. > Even

Re: Automatially move from $n (was: C++11 move semantics)

> On 1 Apr 2018, at 16:43, Frank Heckenbach wrote: > > I've now changed my grammars to use my new C++17 skeletons with > std::variant and move semantics. So far, it seems to work fine. > > As expected, they now contain a lot of "std::move ($n)" expressions. > Even

Re: Automatially move from $n (was: C++11 move semantics)

> On 1 Apr 2018, at 19:23, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> On 1 Apr 2018, at 16:43, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >>> >>> As expected, they now contain a lot of "std:

The tname translations and UTF-8

Might it possible to get an option, for use with UTF-8, where the yytname table entries are not translated into C escape strings? - Currently, if one writes say %token mapsto_key "↦" it is written as "\"\\342\\206\\246\"" rather than "↦".

Re: The tname translations and UTF-8

> On 24 Mar 2018, at 22:10, Paul Eggert <egg...@cs.ucla.edu> wrote: > > Hans Åberg wrote: >> Might it possible to get an option > > Sounds like a reasonable option to me, if someone wants to write and document > it. I wrote some C++ code translating it ba

Re: The tname translations and UTF-8

> On 24 Mar 2018, at 22:10, Paul Eggert <egg...@cs.ucla.edu> wrote: > > Hans Åberg wrote: >> Might it possible to get an option > > Sounds like a reasonable option to me, if someone wants to write and document > it. It actually looks like a bug, translati

Re: Automatially move from $n (was: C++11 move semantics)

> On 1 Apr 2018, at 23:13, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >> An advantage with operators names is avoiding parentheses, but a >> problem is that they are hard to search for, but here, since they >> will alwa

Re: Generated headers

> On 17 Mar 2018, at 22:24, Frank Heckenbach wrote: > > To answer my own question, I wrote: > >> So, isn't there some way to rename those files, either based on the >> bison source file name, or by a command-line option or directive, or >> at least, if still hard

Re: Generated headers

> On 3 Mar 2018, at 22:36, Frank Heckenbach wrote: > > when using "%defines" or "--defines", bison generates the normal C++ > file, the header (whose name can be set with "--defines") and 3 more > files, position.hh, location.hh and stack.hh whose names apparently >

Re: C++11 move semantics

> On 4 Mar 2018, at 18:47, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> Later Bison versions work with unique_ptr; add %require to the >>>> grammar to make sure one does not compile with older versions. >>> &

Re: C++11 move semantics

> On 4 Mar 2018, at 16:58, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> On 3 Mar 2018, at 22:36, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >>> >>> So far my C++ parsers use the C templ

Re: C++11 move semantics

> On 3 Mar 2018, at 22:36, Frank Heckenbach wrote: > > So far my C++ parsers use the C template (which works, but with > obvious restrictions). Not recommended, as the compile C as C++ proved too difficult to maintain, and thus is not supported. > Now I'm trying to

Re: C++11 move semantics

> On 3 Mar 2018, at 22:36, Frank Heckenbach wrote: > > So far my C++ parsers use the C template (which works, but with > obvious restrictions). Not recommended, as the compile C as C++ proved too difficult to maintain, and thus is not supported. > Now I'm trying to

Re: C++11 move semantics

> On 4 Mar 2018, at 22:19, Frank Heckenbach wrote: > That version is OK. In the past, there was a C hack where the default rule action was implemented by always doing $$ = $1, which does not work with unique_ptr. >>> >>> I remember it used to do this

Re: C++11 move semantics

> On 5 Mar 2018, at 00:36, Frank Heckenbach wrote: > >>> It would work in C, but users were advised not to rely on it. >> >> No problem in C, as there are no copy constructors, just an overhead. > > I think users were advised against it because it was just an >

Re: C++11 move semantics

> On 5 Mar 2018, at 18:15, Frank Heckenbach wrote: > > Let's see if I can add "$$ = std::move ($1)" as a default action in > my patches. (Not as a pre-action as in C, that would be wrong with > move, only as a default action when no user action is supplied.) That might

Re: C++11 move semantics

> On 5 Mar 2018, at 18:15, Frank Heckenbach wrote: > > Let's see if I can add "$$ = std::move ($1)" as a default action in > my patches. (Not as a pre-action as in C, that would be wrong with > move, only as a default action when no user action is supplied.) That might

Re: C++11 move semantics

> On 6 Mar 2018, at 00:24, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> On 5 Mar 2018, at 18:15, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >>> >>> Let's see if I can add "$$ = std::move ($1)"

Re: Bison 3.1 api.value.type {semantic_type} error in gcc8

> On 16 Oct 2018, at 12:10, Akim Demaille wrote: > > Hi Hans, Hello, >> Le 16 oct. 2018 à 11:20, Hans Åberg a écrit : >> >> In Bison 3.1, >> %define api.value.type {semantic_type} >> produces an error in gcc8, though accepted in clang6, by the parse

Bison 3.1 api.value.type {semantic_type} error in gcc8

In Bison 3.1, %define api.value.type {semantic_type} produces an error in gcc8, though accepted in clang6, by the parser header typedef #ifndef YYSTYPE /// Symbol semantic values. typedef semantic_type semantic_type; #else typedef YYSTYPE semantic_type; #endif

Re: Bison 3.1 api.value.type {semantic_type} error in gcc8

> On 16 Oct 2018, at 18:21, Akim Demaille wrote: > >> Le 16 oct. 2018 à 14:57, Hans Åberg a écrit : >> >> The minimal example below compiles with clang++6, but not with g++8. One >> would think that it should define a qualified name B::A, used as >>

Re: Bison 3.1 api.value.type {semantic_type} error in gcc8

> On 16 Oct 2018, at 18:21, Akim Demaille wrote: > >> Le 16 oct. 2018 à 14:57, Hans Åberg a écrit : >> >> The minimal example below compiles with clang++6, but not with g++8. One >> would think that it should define a qualified name B::A, used as >>

Re: Bison 3.1 api.value.type {semantic_type} error in gcc8

> On 16 Oct 2018, at 13:19, Akim Demaille wrote: > >> Le 16 oct. 2018 à 11:20, Hans Åberg a écrit : >> >> In Bison 3.1, >> %define api.value.type {semantic_type} > > Actually, what are you trying to achieve? semantic_type is the name > of the type

Re: bison-3.2 released [stable]

> On 29 Oct 2018, at 21:33, Akim Demaille wrote: > > We are very happy to announce the release of Bison 3.2! Actually two warnings on make with MacOS inhouse clang, the obstack one same as with 3.1 :-), and one with the bitset. All tests passed though. -- MacOS 10.13.6. $ gcc --version

  1   2   >