Print(true and true) #=> the parenthesis issue

ruby-talk
1

The parenthesis have been discussed before, but maybe this is another
angle. In a nutshell:

print(true and true) # => throws the following:

SyntaxError: compile error
(irb):14: syntax error, unexpected kAND, expecting ')'
print(true and true)
              ^
  from (irb):14

print (true and true) # => works. (notice the space)

It looks obvious that the only parenthesis around the method args are
containing the expression to be evaluated, so why would this cause
ambiguity? Especially strange that the incorrect way - with the space
- works as expected. Is there any fix in the works? Anything done
about this?

Thanks!

2

hakunin wrote:

The parenthesis have been discussed before, but maybe this is another
angle. In a nutshell:

print(true and true) # => throws the following:

SyntaxError: compile error
(irb):14: syntax error, unexpected kAND, expecting ')'
print(true and true)
              ^
  from (irb):14

print (true and true) # => works. (notice the space)

It looks obvious that the only parenthesis around the method args are
containing the expression to be evaluated, so why would this cause
ambiguity? Especially strange that the incorrect way - with the space
- works as expected. Is there any fix in the works? Anything done
about this?

Thanks!

print (true and true) is not incorrect, it is just using parentheses for a different purpose.

What you are seeing is just a precedence issue, because "and" and "or" have very low precedence.

Compare:

print(true && true)
print(true or true)
print(true || true)
print((true and true))
print((true or true))

Maybe you already knew that, though?

-Justin

3

I've always used "&&" rather than "and". I know the two operators have
different precedences. The "&&" version comes naturally to me, thanks to
a C background.

Can someone give non-contrived examples where "and" works nicely but
"&&" doesn't? I.e. what is the reason for including "and" in the
language, as it seems redundant to me. (The Pickaxe says "just to make
life interesting".)

···

--
Posted via http://www.ruby-forum.com/.

4

That makes sense, and yes, that I realized. In print() parenthesis are
enclosing the args, whereas in print () parenthesis are affecting
precedence of passed-in expression. However, from the usability
perspective, isn't it against some basic nature laws to leave it like
this? I would understand if print(true and return) was to be made
possible, although it looks quite ugly. In this case - Ruby says "i
don't need it, but I won't give it to you either!" - an error occurs,
but no reason provided for this to be restricted. If enclosed
arguments can only either be replaced with args list, or with a high
precedence expression (otherwise error), then why not allow arg-
enclosing parenthesis to behave like precedence modifiers as well, so
that expression inside them plays first? Overall it seems to be only
better for the elegance of code, and wouldn't hurt anyone. Unless I'm
missing the rest of the iceberg.

···

On Jun 16, 10:48 pm, Justin Collins <justincoll...@ucla.edu> wrote:

hakunin wrote:
> The parenthesis have been discussed before, but maybe this is another
> angle. In a nutshell:

> print(true and true) # => throws the following:

> SyntaxError: compile error
> (irb):14: syntax error, unexpected kAND, expecting ')'
> print(true and true)
> ^
> from (irb):14

> print (true and true) # => works. (notice the space)

> It looks obvious that the only parenthesis around the method args are
> containing the expression to be evaluated, so why would this cause
> ambiguity? Especially strange that the incorrect way - with the space
> - works as expected. Is there any fix in the works? Anything done
> about this?

> Thanks!

print (true and true) is not incorrect, it is just using parentheses for
a different purpose.

What you are seeing is just a precedence issue, because "and" and "or"
have very low precedence.

Compare:

print(true && true)
print(true or true)
print(true || true)
print((true and true))
print((true or true))

Maybe you already knew that, though?

-Justin

5

Justin Collins wrote:

hakunin wrote:

The parenthesis have been discussed before, but maybe this is another
angle. In a nutshell:

print(true and true) # => throws the following:

SyntaxError: compile error
(irb):14: syntax error, unexpected kAND, expecting ')'
print(true and true)
              ^
    from (irb):14

print (true and true) # => works. (notice the space)

It looks obvious that the only parenthesis around the method args are
containing the expression to be evaluated, so why would this cause
ambiguity? Especially strange that the incorrect way - with the space
- works as expected. Is there any fix in the works? Anything done
about this?

Thanks!

print (true and true) is not incorrect, it is just using parentheses for a different purpose.

What you are seeing is just a precedence issue, because "and" and "or" have very low precedence.

Compare:

print(true && true)
print(true or true)
print(true || true)
print((true and true))
print((true or true))

Maybe you already knew that, though?

This one really puzzles me. I know of the operator precedence
hierarchy in Ruby, but this doesn't seem to help me figure
out why the parser gets confused here. Could someone give
some insights in the thought process of the parser when it
encounters "print(true and true)" ?

Thanks,

Michael

6

I've always used "&&" rather than "and". I know the two operators have
different precedences. The "&&" version comes naturally to me, thanks to
a C background.

hacker :slight_smile:

Can someone give non-contrived examples where "and" works nicely but
"&&" doesn't? I.e. what is the reason for including "and" in the
language, as it seems redundant to me. (The Pickaxe says "just to make
life interesting".)

1 reads better in english. i also would assume you do not like "or" :wink:
2 handy for control flow

otoh && is handy for value manipulation, eg,

:001:0> x= true and false
=> false
:002:0> x
=> true
:003:0> x= true && false
=> false
:004:0> x
=> false
irb(main):005:0> x= (true and false)
=> false
irb(main):006:0> x
=> false

"and" and "or" comes natural (look i'm already using them :slight_smile: w their
low precedence in ruby, so you do not have to put a lot of parens when
linking compound logical expressions. Sadly, there are special cases
that the opposite (ie parens are mandatory) may be true (bug or not).
Also, "and/or" names suggest their use and i do not even have to dig
the manuals nor think hard just to get their meaning...

kind regards -botp

···

On Tue, Jun 17, 2008 at 10:07 PM, Dave Bass <davebass@musician.org> wrote:

7

I've always used "&&" rather than "and". I know the two operators have
different precedences. The "&&" version comes naturally to me, thanks to
a C background.

I use "&&" in expressions (because of the precedence) and "and" when I
want to combine some "statements".

Can someone give non-contrived examples where "and" works nicely but
"&&" doesn't? I.e. what is the reason for including "and" in the
language, as it seems redundant to me. (The Pickaxe says "just to make
life interesting".)

16:35:55 OPSC_Gold_bas_dev_R1.2.2_prj$ ruby -ce 'x = some_work() &&
puts x'
-e:1: syntax error, unexpected tIDENTIFIER, expecting kDO or '{' or
'('
16:36:09 OPSC_Gold_bas_dev_R1.2.2_prj$ ruby -ce 'x = some_work() and
puts x'
Syntax OK

Does that give a clue?

Kind regards

robert

···

On 17 Jun., 16:07, Dave Bass <daveb...@musician.org> wrote:

8

print(true && true)
print(true or true)
print(true || true)
print((true and true))
print((true or true))

That makes sense, and yes, that I realized. In print() parenthesis are
enclosing the args, whereas in print () parenthesis are affecting
precedence of passed-in expression. However, from the usability
perspective, isn't it against some basic nature laws to leave it like
this?

There are no nature laws in IT.

I would understand if print(true and return) was to be made
possible, although it looks quite ugly. In this case - Ruby says "i
don't need it, but I won't give it to you either!" - an error occurs,
but no reason provided for this to be restricted. If enclosed
arguments can only either be replaced with args list, or with a high
precedence expression (otherwise error), then why not allow arg-
enclosing parenthesis to behave like precedence modifiers as well, so
that expression inside them plays first? Overall it seems to be only
better for the elegance of code, and wouldn't hurt anyone. Unless I'm
missing the rest of the iceberg.

Two remarks:

1. I was surprised of the error as well. But

2. I cannot remember someone complaining about this. So, although my memory may be failing me, for most it does not seem to be an issue.

Maybe it's simply a technical limitation of the parser.

Kind regards

  robert

···

On 17.06.2008 06:08, hakunin wrote:

On Jun 16, 10:48 pm, Justin Collins <justincoll...@ucla.edu> wrote:

9

1. print (true and true)
2. print(true and true)

In the one case the parser first evaluates "true and true" for a
boolean result (true) and
then passes that to print. In the second case the parser seems to be expecting
something like: print(true) and print "hello"

It seems wrong to me too, since I'd expect the brackets to remove
"print" from the
equation until the bracketed section is evaluated. Perhaps someone can show some
obscure syntax that requires this behavior.

Les

···

On Tue, Jun 17, 2008 at 9:44 AM, Michael Ulm <michael.ulm@isis-papyrus.com> wrote:

Justin Collins wrote:

hakunin wrote:

The parenthesis have been discussed before, but maybe this is another
angle. In a nutshell:

print(true and true) # => throws the following:

SyntaxError: compile error
(irb):14: syntax error, unexpected kAND, expecting ')'
print(true and true)
             ^
   from (irb):14

print (true and true) # => works. (notice the space)

It looks obvious that the only parenthesis around the method args are
containing the expression to be evaluated, so why would this cause
ambiguity? Especially strange that the incorrect way - with the space
- works as expected. Is there any fix in the works? Anything done
about this?

Thanks!

print (true and true) is not incorrect, it is just using parentheses for a
different purpose.

What you are seeing is just a precedence issue, because "and" and "or"
have very low precedence.

Compare:

print(true && true)
print(true or true)
print(true || true)
print((true and true))
print((true or true))

Maybe you already knew that, though?

This one really puzzles me. I know of the operator precedence
hierarchy in Ruby, but this doesn't seem to help me figure
out why the parser gets confused here. Could someone give
some insights in the thought process of the parser when it
encounters "print(true and true)" ?

10

The parser doesn't get confused; this is in there totally
deliberately. I don't have Ruby's parser handy here, but I think Ruby
only allows expressions as parameter if they can go on the right hand
side of an assignment. If you want "true and true" on the right hand
side of an assignment, you need parentheses as well, because otherwise
"a = true and true" is interpreted as "(a = true) and true". Other
things that don't go as arguments unless parenthesized: semicolons,
control statements, statement modifiers, etc. Everything that operates
on statements really.

To me, "or" and "and" are not equivalents of "||" and "&&"; the
difference in precedence is a definite hint here. While "||" and "&&"
work on expressions, "or" and "and" work on statements. If you don't
use them as "statement operators", you're bound to run into trouble
and you'll have to put extra parentheses all over.

Peter

···

On Tue, Jun 17, 2008 at 9:44 AM, Michael Ulm <michael.ulm@isis-papyrus.com> wrote:

This one really puzzles me. I know of the operator precedence
hierarchy in Ruby, but this doesn't seem to help me figure
out why the parser gets confused here. Could someone give
some insights in the thought process of the parser when it
encounters "print(true and true)" ?

11

The way 'and' differs from &&, and || differs from 'or' is pretty
clear. Question is - what to do about this special case? It's
completely logical when you follow interpreter logic, as it adheres to
KISS (from interpreter perspective) however, it does not adhere to
POLS from language user's view angle. One would say "you have to learn
your interpreter", but I would argue that language is what we learn
and interpreter is just a tool used by the language. Interpreter is
there to interpret language, language is not there to adhere to the
interpreter. Am I making sense?

···

On Jun 17, 10:37 am, Robert Klemme <shortcut...@googlemail.com> wrote:

On 17 Jun., 16:07, Dave Bass <daveb...@musician.org> wrote:

> I've always used "&&" rather than "and". I know the two operators have
> different precedences. The "&&" version comes naturally to me, thanks to
> a C background.

I use "&&" in expressions (because of the precedence) and "and" when I
want to combine some "statements".

> Can someone give non-contrived examples where "and" works nicely but
> "&&" doesn't? I.e. what is the reason for including "and" in the
> language, as it seems redundant to me. (The Pickaxe says "just to make
> life interesting".)

16:35:55 OPSC_Gold_bas_dev_R1.2.2_prj$ ruby -ce 'x = some_work() &&
puts x'
-e:1: syntax error, unexpected tIDENTIFIER, expecting kDO or '{' or
'('
16:36:09 OPSC_Gold_bas_dev_R1.2.2_prj$ ruby -ce 'x = some_work() and
puts x'
Syntax OK

Does that give a clue?

Kind regards

robert

12

Robert Klemme wrote:

$ ruby -ce 'x = some_work() and puts x'
Does that give a clue?

Isn't that the same as this?

  x = some_work()
  puts x unless x == false

I prefer the two-line version; clarity wins over conciseness every time
for me.

···

--
Posted via http://www.ruby-forum.com/\.

13

Robert Klemme wrote:

[snip]

That makes sense, and yes, that I realized. In print() parenthesis are

enclosing the args, whereas in print () parenthesis are affecting
precedence of passed-in expression. However, from the usability
perspective, isn't it against some basic nature laws to leave it like
this?

There are no nature laws in IT.

Absolute nonsense.

IT is not an entity unto itself. It is an artifact of the human brain. Furthermore, it must be USED by the human brain, else it is the proverbial tree falling in the forest when no one's around, and thus has no consequence. AND the human brain certainly does have laws, if by "laws" we mean something like "statements of pattern possessing a high probability of being true" (my definition). Philosophical idealists will not be satisfied by that, but such children should be ignored. Real men live with probability, as a fact of life. (Are we having fun yet?) So...natural law of IT exist, because all of IT must pass through the filter of the human brain.

From that point reasonable point of view, we could well have the usability problem mentioned. I, for one, find this parenthesis problem obscure in the extreme. What happened to the principal of least surprise? Yikes.

Keep it simple, when at all possible.

t.

···

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

14

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

···

From: Robert Klemme [mailto:shortcutter@googlemail.com]

15

The way 'and' differs from &&, and || differs from 'or' is pretty
clear. Question is - what to do about this special case?

someone to submit a patch and that others may test.

Am I making sense?

yes

···

On Tue, Jun 17, 2008 at 10:58 PM, hakunin <madfancier@gmail.com> wrote:

16

If you're in favour of clarity, why not

x = some_work()
putx x if x

Kind regards

robert

···

2008/6/18 Dave Bass <davebass@musician.org>:

Robert Klemme wrote:

$ ruby -ce 'x = some_work() and puts x'
Does that give a clue?

Isn't that the same as this?

x = some_work()
puts x unless x == false

I prefer the two-line version; clarity wins over conciseness every time
for me.

--
use.inject do |as, often| as.you_can - without end

17

Robert Klemme wrote:

[snip]

That makes sense, and yes, that I realized. In print() parenthesis are

enclosing the args, whereas in print () parenthesis are affecting
precedence of passed-in expression. However, from the usability
perspective, isn't it against some basic nature laws to leave it like
this?

There are no nature laws in IT.

Absolute nonsense.

Thanks for your kind reply.

IT is not an entity unto itself. It is an artifact of the human brain.
Furthermore, it must be USED by the human brain, else it is the proverbial
tree falling in the forest when no one's around, and thus has no
consequence. AND the human brain certainly does have laws, if by "laws" we
mean something like "statements of pattern possessing a high probability of
being true" (my definition). Philosophical idealists will not be satisfied
by that, but such children should be ignored. Real men live with
probability, as a fact of life. (Are we having fun yet?) So...natural law of
IT exist, because all of IT must pass through the filter of the human brain.

With that argument the statement "there are nature laws in X" becomes
a tautology because they influence every aspect of reality. I prefer
to keep the distinction because this allows me to make more
interesting (i.e. non tautological) statements.

The point here is that all formalisms in IT are human invented and
there is certainly nothing like a natural law that will demand that
"f(x and y)" is a valid expression.

From that point reasonable point of view, we could well have the usability
problem mentioned. I, for one, find this parenthesis problem obscure in the
extreme. What happened to the principal of least surprise? Yikes.

Did it every surprise you before this thread? If not, I don't see any
issue with POLS.

Keep it simple, when at all possible.

Exactly. Having a feature that makes the language simple which is not
used by anyone (or only rarely) does not justify complicating the
parser more than necessary.

Regards

robert

···

2008/6/17 Tom Cloyd <tomcloyd@comcast.net>:

--
use.inject do |as, often| as.you_can - without end

18

Dear Tom Cloyd,

"What happened to the principal of least surprise? Yikes.

Keep it simple, when at all possible."

Your suggestive (and false) remarks are irritating at best. There is
only one principle of least surprise, if ever, and this is by the one
who designs the language. There is no GENERAL CONSENSUS applicable to a
"principle of least surprise" because different expectations, patterns,
experience will yield to different perceptions of any given situation.

The KISS strategy is only one more strategy in a pool of different
strategies.

I have seen it used in the game Wesnoth and what this basically means it
that they slavishly reject features that "would make the game too
complicated".
To the extreme that, when one suggests simplification to a game
interface, a similar reasoning is used to reject it ("would make the
code too complicated")

Whether this is intentional or not, it is their decision, but it would
not be the ONLY available strategy to create/solve something.

I'd rather not stick to ANYONE's "keep it simple" mantra, definitely not
when multiple people jump on it and pick it up to shout something is a
bug when it is not what they expect.

If anyone wants to know my principle of leat surprise, then I'd never
have a parser that makes a difference between && and "and" or similar.
But I am no language designer.

···

--
Posted via http://www.ruby-forum.com/.

19

Robert Klemme wrote:

There are no nature laws in IT.

Absolute nonsense.

IT is not an entity unto itself. It is an artifact of the human brain.

<snip/>

From that point reasonable point of view, we could well have the usability
problem mentioned. I, for one, find this parenthesis problem obscure in the
extreme. What happened to the principal of least surprise? Yikes.

Keep it simple, when at all possible.

You should study linguistics. Then, you might have an idea of how
hard it is to KISS.

Todd

···

On Tue, Jun 17, 2008 at 2:09 AM, Tom Cloyd <tomcloyd@comcast.net> wrote:

20

Robert Klemme wrote:

x = some_work()
putx x if x

I carefully set my little trap... and it caught someone! :smiley:

Note that I wrote "Clarity wins over conciseness every time for me." The
more English-like the code is, the easier it is to understand (for me
anyway). The fact that my version is a few characters longer is
unimportant. Hopefully it won't phase Ruby; anyway, I'm the boss and it
can do what I say.

:slight_smile:

Dave

···

--
Posted via http://www.ruby-forum.com/\.