Reia PEG Issue 2 : unary '-' precedence above **

[Graeme Defty]

This is one of a series of questions which have arisen from work in developing a PEG for Reia:

-- Symbols involved:
Unary -, **

-- Issue:
Currently there is a group of unary symbols ( + - not ! ~ ) sitting right above **. The arithmetic unary '-' (at least) should be below **

-- Rationale:
Simple explanation: -2**2 should be -4, not 4
Complicateder explanation:
A little tricky this but here goes...one way of looking at an expression such as 1+2-3+4 (and the reason we left-associate these with even precedence) is 1 + 2 + (-3) + 4

Now if we look at 1 - 2**2 it is clear (to me anyway) that we mean 1 - 4
... THEREFORE 1 + (-2**2) should be 1 - 4
... THEREFORE -2**2 = (-4)  
       QED
Well you are either totally convinced or you think I am talking complete rubbish, so let me put it another way.

Ruby does it like that ;-)

In fact Ruby also makes the unary operators right-associative. I do not think that makes any difference, but it makes sense that  --2 parses as -(-2) and right-associative is better for PEGs so looks worth changing.

Reia has
     unary + - ~ I not followed by **

-- My Suggestion:
Since it does not matter whether +3**2 is parsed as +(3**2) or (+3)**2, I suggest moving both unary - AND unary + to a position on their own below ** and make them right-assoc.

Regards,

g

[Tony Arcieri]

There's a bit of a clash between the Erlang and Ruby grammars here, it seems, which makes sense, because the ** operator isn't present in Erlang.

I can certainly switch the precedence, but due to how the lexer presently works the behavior how how unary - is processed is inconsistent between the lexer and grammar, due to the processing of the '-' token vs the '<-' token. This is the kind of problem that's a lot easier to solve in a PEG. (the '<-' token is reserved for asynchronous method calls)

So at the very least, I can fix the grammar, but the lexer will still be inconsistent. Hopefully the PEG can honor the grammar, but not the lexer.

--
You received this message because you are subscribed to the Google Groups "Reia" group.
To post to this group, send email to re...@googlegroups.com.
To unsubscribe from this group, send email to reia+uns...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/reia?hl=en.

--
Tony Arcieri
Medioh! A Kudelski Brand

[Tony Arcieri]

This has now been fixed in the Reia grammar

[graeme defty]

Tony,

I am still not quite sure how <- is involved. Can you give an example
of what you mean, please?

g
___________________________--

On Aug 19, 11:28 am, Tony Arcieri <tony.arci...@medioh.com> wrote:
> This has now been fixed in the Reia grammar
>

> On Wed, Aug 18, 2010 at 10:13 PM, Tony Arcieri <tony.arci...@medioh.com>wrote:
>
>
>
> > There's a bit of a clash between the Erlang and Ruby grammars here, it
> > seems, which makes sense, because the ** operator isn't present in Erlang.
>
> > I can certainly switch the precedence, but due to how the lexer presently
> > works the behavior how how unary - is processed is inconsistent between the
> > lexer and grammar, due to the processing of the '-' token vs the '<-' token.
> > This is the kind of problem that's a lot easier to solve in a PEG. (the '<-'
> > token is reserved for asynchronous method calls)
>
> > So at the very least, I can fix the grammar, but the lexer will still be
> > inconsistent. Hopefully the PEG can honor the grammar, but not the lexer.
>

> >> reia+uns...@googlegroups.com <reia%2Bunsu...@googlegroups.com>.

[Tony Arcieri]

Thanks for the question, and upon reflection, it's something I should be able to handle in the grammar and not the lexer.

I will try to correct this.

To unsubscribe from this group, send email to reia+uns...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/reia?hl=en.

[Tony Arcieri]

I have removed all handling of unary '-' in Reia's lexer, as well as specific processing of the <- token. This should be handled in the grammar (and should be especially easy with a PEG) and won't be a concern until "Reia 2.0" anyway, as the <- operator was part of the concurrent object system.

Unary '-' is now exclusively handled by Reia's grammar, and the other issues you cited with precedence of unaries should now be addressed.

[candlerb]

On Aug 19, 1:43 am, Graeme Defty <graeme.de...@gmail.com> wrote:
> Simple explanation: -2**2 should be -4, not 4

...

> Ruby does it like that ;-)

bc disagrees with you though:

brian@x100:~$ echo "-2^2" | bc
4
brian@x100:~$ echo "-(2^2)" | bc
-4

That's what I would have expected - and ruby surprises me. In C, all
unary operators bind more tightly than any binary operator. (Not that
C has a binary exponentiation operator though)

But if reia is modelled on ruby, I guess it's reasonable to follow
ruby. Probably ruby just follows perl.

> In fact Ruby also makes the unary operators right-associative. I do not
> think that makes any difference, but it makes sense that  --2 parses as
> -(-2) and right-associative is better for PEGs so looks worth changing.

Yes, same in C: closest operators apply first. And all right-unaries
before left-unaries, e.g. *x++ is *(x++)

[Tony Arcieri]

On Thu, Aug 19, 2010 at 1:56 AM, candlerb <b.ca...@pobox.com> wrote:

On Aug 19, 1:43 am, Graeme Defty <graeme.de...@gmail.com> wrote:
> Simple explanation: -2**2 should be -4, not 4

...

> Ruby does it like that ;-)

bc disagrees with you though:

brian@x100:~$ echo "-2^2" | bc
4
brian@x100:~$ echo "-(2^2)" | bc
-4

That's what I would have expected - and ruby surprises me.

I have to say... Ruby surprises me here as well. I would have expected 4. This is a tough call regarding "just do what Ruby does" vs "do what makes sense to me personally"

I'm mulling reverting the commit where I changed the precedence.

[Tony Arcieri]

Someone pointed this out to me:

http://www.google.com/search?q=-2^2

Google says:

-(2^2) = -4

If Google does it, it must be the Right Way! Also, Python honors this behavior too. It seems bc is the only detractor, at least that I've seen so far.

So I think I'll keep it as-is for now (i.e. same as Ruby/Python/Google) for reasons of POLS. Still seems broken to me though *shrug*

[Tony Arcieri]

On Thu, Sep 9, 2010 at 9:06 PM, Graeme Defty <graeme...@gmail.com> wrote:

however, it seems to me there could be two cases of number 2)

2a) where the newlines are allowed, but optional
2b) where at least one newline is needed

Is this the case?

Yes, precisely, and I don't think I ever captured case 2a properly in a nonterminal and instead the cases I do handle are repeated throughout the grammar :(

Something like:

pargs -> '(' ')'     : #pargs{}.

pargs -> '(' eol ')' : #pargs{}.

Would be better handled as something like:

pargs -> '(' opteol ')' : #pargs{}.




opteol -> '$empty' : void.


opteol -> eol      : void.



It's something I can fix retroactively (ugh) but there are all sorts of places in the grammar that optional eols are needed (unless a lexer trick like implicit line joining can be employed).

As for PEG land, well... I leave that to you :)

Should I shut up and take my silly ideas elsewhere?

The Reia google group would be a fitting place... CC'd :)

[Graeme Defty]

Happy days!

I will distinguish 3 cases

1) blanks (spaces only)
2a) whitespace (optional line end)
2b) eol (mandatory line end)

(don't you love it when a plan comes together?)

(Kim, Hopefully this ties in with what you have)

g
____________________________________