From: Marko Schulz Date: 2001-04-28T20:49:09+09:00 Subject: [ruby-talk:14375] Re: || .. or Question On Fri, Apr 27, 2001 at 11:26:35PM +0900, Yukihiro Matsumoto wrote: > Hi, > > In message "[ruby-talk:14299] Re: || .. or Question" > on 01/04/27, Marko Schulz writes: > > |> Simply precedence reason. In Ruby, statements are expressions that > |> can't be fit in argument list. > | > |Does this mean, that Ruby has an 'list operator' similar to perl with > |precedence between '||' and 'or'? Otherwise I still don't understand > |how precedence comes in here. > > No, no "list operator". But it's little bit too complicated for me to > explain in English (sorry). Would somebody explain for him? I didn't meant that there actually is a list operator. I just cannot understand how precedence within an expression determines whether something is an expression or not. More conrete it looks odd to me that 'puts (n==3 or n==5)' seems to be interpreted as 'puts ((n==3 or) n==5)' while 'puts (n==3 || n==5)' seems to be interpreted as 'puts ((n==3 || n==5))' Because of that I look at the precedence table of operators, but found nothing between '||' and 'or' that might cause the problem. But I remembered, that there is an issue with this in perl too, so I grabbed my Camel Book and found 'list operator' between them. So I wondered wether there is some similar mechanism in ruby, even though it is not an explicit operator. On the other hand perl does its job here as 'expected' (Though I shiver when looking back at perl): #!/usr/bin/perl -w foreach $n (2..6) { print "$n:\n"; print "(or): -"; print ($n==3 or $n==5); print "-\n"; print " or : -"; print $n==3 or $n==5; print "-\n"; print "(||): -"; print ($n==3 || $n==5); print "-\n"; print " || : -"; print $n==3 || $n==5; print "-\n"; } prints: Useless use of numeric eq in void context at ./perl-or.pl line 11. 2: (or): -- or : -- (||): -- || : -- 3: (or): -1- or : -1- (||): -1- || : -1- 4: (or): -- or : -- (||): -- || : -- 5: (or): -1- or : -- (||): -1- || : -1- 6: (or): -- or : -- (||): -- || : -- The only case precedence comes in is when 'or' is used without parenthesis around the parameters (and luckily there is issued a warning because this results in questionable code). > |The trouble strikes with parenthesis around the 'a or/|| b'. Looks > |like other languages do an implicit expression grouping for method > |arguments with parenthesis around them. I find this to be the expected > |behaviour too. > | > |Does anybody see incompatibilities if this was done in ruby too? Other > |objections? > > I don't think I understand what you mean by "implicit expression > grouping for method arguments with parenthesis around them". But I > suspect changing this behavior in any way causes incompatibility. > I may be wrong, as always. I try to explain this a little bit more, but I am not speaking English nativly either, so I hope not too much gets lost during this. In a previous mail you wrote something similar to this: | Parenthesises in 's = (n == 3 or n == 5)' are for expression | grouping, whereas those in 'puts (n == 3 or n == 5)' and 'puts (n == | 3 || n == 5)' are for method arguments (a left parenthesis just | after an identifier denotes beginning of method argument list). : | "puts ((n == 3 or n == 5))" will be OK. Why can the parenthesis in a list of method arguments not also group the expression within it? I find it very surprising, that there is a difference between puts (n == 3 or n == 5) and puts ((n == 3 or n == 5)) What I meant with 'implicit expression grouping for method arguments with parenthesis around them' is simply this: If ruby encounters a method call with parenthesis around its argument like this following one, (there is a catch for more than one argument, see below) foo.bar(this or that) it should handle the argument just like it was a grouped together with an additional parenthesis: foo.bar((this or that)) If you want different behaviour, you still can use explicit groupings: (foo.bar (this)) or that OK, now on to more that one argument. Ruby cannot interpret foo.bar (other, this or that) the way it interprets foo.bar((other, this or that)) now. So the 'implicit' grouping has to be around every argument, not around the whole list of arguments: foo.bar((other), (this or that)) While this looks more complicated than it is, I find this to be the expected behaviour, which is also found in most other languages. Is everything unclear by now? ;-) -- marko schulz Dieser Satz beinhalten drei Fehller.