[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 <[e-mail]> 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.