Reia PEG Issue 4 : and/or precedence

[Graeme Defty]

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

-- Symbols involved:
'and' and 'or'

-- Issue:
this is a couple of issues mixed into one...
  a) compared to Ruby, these two are at the precedence level of && and || rather than their where namesakes lie
  b) they are at the same precedence level as each other, whereas it is normal for 'and' to be higher than 'or' in most languages I have encountered (though strangely, in Ruby && comes above || but 'and' and 'or' are equal - reason not obvious to me). Even in Erlang for example, 'andalso' comes above 'orelse'.

-- Rationale:
I can not see any good reason other than tradition for 'and' coming above 'or'. I am sure there must be languages where it does not (and I know there are languages where they are equal). However, if one of our goals is to make transition easier for Rubyists, then some change appears to be in order.

-- My Suggestion:

Either:
a) move 'and' and 'or' down the pecking order (and leave them equal? - Don't like that last bit, but it matches Ruby)
b) Leave them where they are, but put 'and' above 'or' (so they better match Ruby's && and ||)
c) do both a) and b) by introducing && and || into Reia at the higher level and moving 'and' and 'or' down. I am kinda uncomfortable with this one as well - I never really liked the fact that Ruby had both and the precedences were different. It just seems like one of those things that seems like a good idea at language design time, but in practice is useless because nobody ever remembers the relative precedences (kind like do/end and {} )

Sorry - not very helpful, but I really can't make up my mind which of these is the best.

Regards,

g

[Tony Arcieri]

There are lots of issues with and/or/&&/||

For starters, let me state: compared to Ruby, I want and/or to be synonymous with their &&/|| counterparts. In fact, that's how they're treated at the lexer level.

Another issue: in Ruby (and Python, and many other languages) "and" and "or" return the last expression evaluated.  In Reia, the lhs and rhs are first cast to a boolean, then the comparison performed (which is more in line with Erlang).  I would like to switch to the Ruby behavior.

For the sake of POLS, I can put "and" above "or", however I absolutely refuse to honor the "poetry mode" precedence of and/or vs &&/||, which Ruby inherited from Perl.  I consider this to be a mistake in Ruby's design.

I definitely want to honor Ruby's behavior and have and/or/||/&& return the last expression evaluated.

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

[candlerb]

On Aug 19, 7:26 am, Tony Arcieri <tony.arci...@medioh.com> wrote:
> I absolutely
> refuse to honor the "poetry mode" precedence of and/or vs &&/||, which Ruby
> inherited from Perl.  I consider this to be a mistake in Ruby's design.

How about removing 'and' and 'or' completely?

Rationale:
* They are redundant if they are just aliases
* it would be confusing to see Reia code which uses 'and' and 'or',
but in a completely different way to Ruby/Perl.

> I definitely want to honor Ruby's behavior and have and/or/||/&& return the
> last expression evaluated.

Definitely: foo = bar || baz

[Tony Arcieri]

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

How about removing 'and' and 'or' completely?

I like "and" and "or", to the point I prefer to use them in Ruby code in simple cases where the precedence won't be confusing. I like code that reads more like English, which is what Perl (and by extension Ruby) were going for with poetry mode. It's just idiomatic Ruby ends up not reading like Perl anymore.

Rationale:
* They are redundant if they are just aliases

I don't think TIMTOWTDI is a bad thing

 

* it would be confusing to see Reia code which uses 'and' and 'or',
but in a completely different way to Ruby/Perl.

People generally avoid using "and" and "or" in Ruby altogether because they find the precedence confusing. I'd like to change that.

> I definitely want to honor Ruby's behavior and have and/or/||/&& return the
> last expression evaluated.

Definitely:  foo = bar || baz

Yep, presently broken in Reia :(

 

[Lucian Branescu]

On 19 August 2010 15:12, Tony Arcieri <tony.a...@medioh.com> wrote:
> On Thu, Aug 19, 2010 at 2:02 AM, candlerb <b.ca...@pobox.com> wrote:
>>
>> How about removing 'and' and 'or' completely?
>
> I like "and" and "or", to the point I prefer to use them in Ruby code in
> simple cases where the precedence won't be confusing. I like code that reads
> more like English, which is what Perl (and by extension Ruby) were going for
> with poetry mode. It's just idiomatic Ruby ends up not reading like Perl
> anymore.

Or even better, how about removing || and && completely?

>>
>> Rationale:
>> * They are redundant if they are just aliases
>
> I don't think TIMTOWTDI is a bad thing

It is a bad thing when it comes to syntax. It's a distinct advantage
if a certain construct can only be expressed idiomatically in one
obvious way, or at least one way for each style chosen.

For example in Python, using an imperative style, there is only one
obvious way to sum up some items. The same holds true if you choose to
use a more functional style.

>
>>
>> * it would be confusing to see Reia code which uses 'and' and 'or',
>> but in a completely different way to Ruby/Perl.
>
> People generally avoid using "and" and "or" in Ruby altogether because they
> find the precedence confusing. I'd like to change that.
>>
>> > I definitely want to honor Ruby's behavior and have and/or/||/&& return
>> > the
>> > last expression evaluated.
>>
>> Definitely:  foo = bar || baz
>
> Yep, presently broken in Reia :(
>
> --
> Tony Arcieri
> Medioh! A Kudelski Brand
>

[Tony Arcieri]

On Thu, Aug 19, 2010 at 8:55 AM, Lucian Branescu <lucian....@gmail.com> wrote:

Or even better, how about removing || and && completely?

That would very much not be in the spirit of POLS

 

> I don't think TIMTOWTDI is a bad thing

It is a bad thing when it comes to syntax. It's a distinct advantage
if a certain construct can only be expressed idiomatically in one
obvious way, or at least one way for each style chosen.

For example in Python, using an imperative style, there is only one
obvious way to sum up some items. The same holds true if you choose to
use a more functional style.

I'm aware "There should be one and preferably only one obvious way to do it" is the conventional Python thinking. Things are a bit different in Ruby land. Parens or no parens? It's your choice. Should blocks be delimited by braces or do..end? They work interchangeably.

I would prefer to give the language users some more options and let them decide what the idiomatic style is, rather than being a benevolent dictator who says "you must do it this way!".  My goal would be to get people using words rather than symbols, but for people who are used to using the symbols I still want them to work.

[graeme defty]

SO, net result is that
- 'and & 'or' are synonyms for && and ||
- the whole lot are at the level in the precedence hierarchy
equivalent to Ruby's && and ||, and
- 'and'/&& will be just above 'or'/||

Sound about right?
___________________________________-

On Aug 19, 11:22 pm, Tony Arcieri <tony.arci...@medioh.com> wrote:
> On Thu, Aug 19, 2010 at 8:55 AM, Lucian Branescu

> <lucian.brane...@gmail.com>wrote:

[Lucian Branescu]

It's helpful to have an official idiomatic style because other
people's code becomes much easier to read. If you don't have to wade
through weird syntax, things are easier. Consistency helps.

[Tony Arcieri]

On Fri, Aug 20, 2010 at 9:18 AM, Lucian Branescu <lucian....@gmail.com> wrote:

It's helpful to have an official idiomatic style

Well then, I hereby declare that the official idiomatic style for Reia is "and" and "or" (this is also how they are stored internally in the parse tree in all cases).  Using && and || should look as odd to a Reia user as using a for loop looks in Ruby.

That said, when I get a chance I will correct the precedence so "and" is higher than "or".

 

[Tony Arcieri]

On Thu, Aug 19, 2010 at 12:20 AM, Graeme Defty <graeme...@gmail.com> wrote:

in Ruby && comes above || 

Really?

>> true && false || true

=> true

>> false || true && false

=> false 

They seem to me to be at the same precedence level

[Graeme Defty]

Yes, I think so - both the examples you give have the same result whether && has higher precedence or not.

Try                                  true || true && false   =>  true

because it parses as        true || (true && false)

and not                           (true || true) && false

or                                   false || false && true  => false

Regards,

g
_______________________________________________

--

[candlerb]

BTW, I'm glad to see Reia has sensible parsing of unary 'not'.

# Perl is fine
perl -e 'print not 4 < 3'

# Ruby is broken
ruby -e 'not 4 < 3' # OK but useless
ruby -e 'a = not 4 < 3' # error
ruby -e 'a = (not 4 < 3)' # works
ruby -e 'puts not 4 < 3' # error
ruby -e 'puts(not 4 < 3)' # error
ruby -e 'puts((not 4 < 3))' # works

[Graeme Defty]

Hmmm. Not quite sure what you expect to see here.

I would have thought (from these examples at least) that the < should bind tighter than the 'not' - i.e.

not 4 < 3      =>     not (4 < 3)

This is not how Reia parses it right now. Currently we have:

not 4 < 3      =>      (not 4) < 3

This parsing would make sense if 4 was replaced with a boolean value, but it would be unlikely that you would want a boolean value as the left operand of <.

Thinking about it, 'not' should be lower precedence than < (et al) since they all take numbers (or maybe strings etc) and produce boolean values while unary 'not' takes a boolean value.

g
________________________________________________