> On 7 Nov 2018, at 10:09, r0ller wrote:
>
> Numbering tokens was introduced in the very beginning and has been questioned
> by myself quite a many times if it's still needed. I didn't give a hard try
> to get rid of it mainly due to one reason: I want to have an error handling
> that tells i
> On 2 Nov 2018, at 17:53, Uxio Prego wrote:
>
> More specifically, I'm curious to know if Bison can modify precedences
> at parsing time according user sentences, now referring as user not the
> programmer who wrote the *.y doc but the programmer writing a program
> parsed by the parser genera
Hey, thank you very much! I had lost all faith.
> You can write general rules say for prefix, infix, and postfix operators,
> [...]
For simplicity I would be happy to consider only infix operators.
> [...] the actions put them onto to a stack with precedences and another for
> values. Then, whe
Hi Hans,
Sorry, I don't really get it:( What do you mean by replacing tokens by strings?
How can that be done?
Best regards,
r0ller
Eredeti levél
Feladó: Hans Åberg < haber...@telia.com (Link -> mailto:haber...@telia.com) >
Dátum: 2018 november 8 14:28:03
Tárgy: Re: bison for
Hi Uxio, hi Hans,
You cannot use Bison to resolve dynamically your precedence if
you have a free set of levels. But if you have a fixed number
of level, say 10, then you could define ten tokens for each level,
and give them the precedence you want. Then, in the scanner,
map each operator to the
> On 8 Nov 2018, at 20:48, r0ller wrote:
>
> Sorry, I don't really get it:( What do you mean by replacing tokens by
> strings? How can that be done?
Write
%token t_ENG_Adv "English adverb"
Then, in error message, the Bison parser will write "English adverb", and you
can also use it in the
> On 8 Nov 2018, at 20:21, Uxio Prego wrote:
>
>> You can write general rules say for prefix, infix, and postfix operators,
>> [...]
>
> For simplicity I would be happy to consider only infix operators.
For fixity overloads (same name but different fixity), one can have the
overloads used in
> On 8 Nov 2018, at 21:19, Akim Demaille wrote:
>
> Hi Uxio, hi Hans,
Hi Akim,
> You cannot use Bison to resolve dynamically your precedence if
> you have a free set of levels. But if you have a fixed number
> of level, say 10, then you could define ten tokens for each level,
> and give them
> You cannot use Bison to resolve dynamically your precedence if
> you have a free set of levels. But if you have a fixed number
> of level, say 10, [...]
Fixed number seems perfectly enough to me.
> you could define ten tokens for each level,
> map each operator to the corresponding level, stori
> For fixity overloads (same name but different fixity), one can have the
> overloads used in C/C++: prefix and postfix (as in ++), or prefix and infix
> (as in -), but not infix and postfix. This requires extra processing, keeping
> track of the token that was before; Bison cannot do that, so t
Hi Hans,
Wow, I did not know that feature. Is such a string only used when creating an
error message? Will the token still have an integer assigned that can be used
in the actions or do I get there the string as well instead of an integer? By
the way, I'll still get the error message as a stri
> On 8 Nov 2018, at 22:34, Uxio Prego wrote:
>
>> Take a simple example, a + b*c #, where # is the end marker. First put the a
>> on the value stack, and the + on the operator stack, and then the b on the
>> value stack. When the * comes by, it has higher precedence than the + on top
>> of t
> Le 8 nov. 2018 à 22:35, r0ller a écrit :
>
> Hi Hans,
>
> Wow, I did not know that feature. Is such a string only used when creating
> an error message?
It also becomes an alias in the grammar file itself. For instance with
%token PLUS "+"
in addition to
exp: exp PLUS exp
you can als
Hi!
> Le 7 nov. 2018 à 10:09, r0ller a écrit :
>
> Hi Akim,
>
> The file hi_nongen.y is just left there as the last version that I wrote
> manually:) If you check out any other hi.y files in the platform specific
> directories (e.g. the one for the online demo is
> https://github.com/r0ller/
We would have been happy not to have to announce the release of Bison 3.2.1,
which fixes portability issues of Bison 3.2.
Bison 3.2 brought massive improvements to the deterministic C++ skeleton,
lalr1.cc. When variants are enabled and the compiler supports C++11 or
better, move-only types can no
15 matches
Mail list logo
