> On 10 Nov 2018, at 13:51, Uxio Prego wrote:
>
> Alright, but
OK, let's hear!
>> On 8 Nov 2018, at 23:37, Hans Åberg wrote:
>>
>>> On 8 Nov 2018, at 22:34, Uxio Prego wrote:
>>>
[...]
>>>
>>> The example and explanation are worth a thousand words,
>>> thank you very much. So I use a
Alright, but
> On 8 Nov 2018, at 23:37, Hans Åberg wrote:
>
>> On 8 Nov 2018, at 22:34, Uxio Prego wrote:
>>
>>> [...]
>>
>> The example and explanation are worth a thousand words,
>> thank you very much. So I use a simple grammar like that, and
>> the stack data structures, and if necessary
> 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
> 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
> 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
> 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
> 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
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
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
> 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
d doc, and executing it in a later stage after
some semantic analysis out of Bison.
However, if Bison could react to some rule reconfiguring the way it sorts
precedences, I would find that rather interesting.
Thank you very much,
> Begin forwarded message:
>
> From: Uxio Prego
> S
Hi,
if there is anything new to comment in this question:
https://stackoverflow.com/questions/31503059/custom-operators-in-bison-yacc
I would love to read it.
Thank you very much,
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
12 matches
Mail list logo
