From: "Peña, Botp" <botp@...>
Date: 2008-06-17T19:15:26+09:00
Subject: Re: print(true and true) #=> the parenthesis issue

From: Robert Klemme [mailto:shortcutter@googlemail.com] 
#..
# Maybe it's simply a technical limitation of the parser.

that is my hunch too.

since ruby 1.8.6, i have made it a point to put the parens close to the method name since i always dislike the msg "warning: don't put space before argument parentheses". But yet this "and/or" behaviour seems very counter to ruby, for me.

i encountered something similar like this when i tried creating my own partition/grouping method. the issue was on accessing/debugging a hash, or something like,

h={}
#=> {}

h[true] = true
#=> true

h[false] = false
#=> false

h[true]
#=> true

h[true and false]
SyntaxError: compile error
(irb):37: syntax error, unexpected kAND, expecting ']'
h[true and false]
          ^

h [true or false]
SyntaxError: compile error
(irb):41: syntax error, unexpected kOR, expecting ']'
h [true or false]
          ^


h [true if 1==1]
SyntaxError: compile error
(irb):56: syntax error, unexpected kIF_MOD, expecting ']'
h [true if 1==1]
          ^

i got the hint when i used a var just to make sure

x = (true and false)
#=> false

x = (false and true)
#=> false

h[x]
#=> false

so,

h [(true and false)]
#=> false

h [(true or false)]
#=> true

h [(true if 1==1)]
#=> true

note that the ff does not err though

h [if 1==1 and 2==2 then true else false end]
#=> true

h [if 1==1 or 2==2 then true else false end]
#=> true


generally, i personally think this is a parser bug (but who am i to say that, and i haven't even read the whole ruby manual yet :-(.. sad since ruby1.9 behaviour is same.

nonetheless, i made my own C/LISP-like motto just to avoid this type of nasty errors/msgs, and that is: "when in doubt, ENCLOSE expressions in parens" --wc emphasize the use of parens more. Rubyish or not, POLS or not (C/LISP-like or not ;), it always works, --for me. 

kind regards -botp