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

Ruby
#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:

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

On Jun 16, 10:48 pm, Justin C. [email protected] wrote:

from (irb):14

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

Maybe you already knew that, though?

-Justin

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.

#4

On 17.06.2008 06:08, hakunin wrote:

On Jun 16, 10:48 pm, Justin C. [email protected] wrote:

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

#5

Robert K. 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 C., MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
#6

Justin C. wrote:

from (irb):14

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

#7

On Tue, Jun 17, 2008 at 9:44 AM, Michael U.
[email protected] wrote:

(irb):14: syntax error, unexpected kAND, expecting ‘)’
about this?

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)” ?

  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

#8

Robert K. wrote:

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.

I was, of course, referring to your proposition, and not to you. My
evaluation is supported (I would hope) by the rest of my statement -
again referring to ideas, not person. The “Absolute” is, of course,
hyperbole, and also an attempt at humorous irony, since the argument
which followed I then made was an appeal to the relative world of real
probability, in which absolutes (“laws”) are not likely to exist.

With that argument the statement “there are nature laws in X” becomes
a tautology because they influence every aspect of reality.
Law of IT need not have relevance outside of that domain. There IS no
necessary “influence”.
I prefer
to keep the distinction because this allows me to make more
interesting (i.e. non tautological) statements.

Clever, but…um…unfortunately wrong, if you reread my stipulated
definition of “law”. It’s critical.

To put it differently: the brain behaves in patterned ways, which are
describable by stochastic statements, the strongest of which approximate
what in philosophically (and scientifically) simpler times were referred
to as “laws”. If this non-chaotic behavior be granted, and if you grant
that IT must work in the context of this same brain, else it be
irrelevant, then IT must also be non-chaotic, which is to say ‘something
akin to law-like’ - not inherently but functionally. Chaotic IT
certainly could (and in some quarters likely does) exist. But USEFUL IT
cannot be structured this way, because, as I said, it must pass through
the filter of the brain.

I think you are having trouble abandoning the idealist view of law. I
certainly grasp that concept, but it seems useful to me only in study of
the history of philosophy. Two words: quatum mechanics (which I believe
IS supposed to “influence” all of nature). I rest my case.

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

So, the falling tree in the forest makes no noise until I hear it? OK.
But, pragmatically, if this sort of syntactic nonsense (the parenthesis
thing - not the tree) exists in this case in Ruby, I become fearful
about where else it might exist. Simply a practical concern. Otherwise,
it is, as you point out, likely to be of so little import as to deserve
no further attention.

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.

A pragmatic question, and you may well be right.

Let’s hope so. Of course, the next time my Ruby program fails (and I’m
good at that), I WILL have to wonder if I’m hearing a distant tree
falling.

t.

–

Tom C., MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
#9

On Tue, Jun 17, 2008 at 9:44 AM, Michael U.
[email protected] 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)” ?

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

#10

2008/6/17 Tom C. [email protected]:

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

#11

From: Robert K. [mailto:[email protected]]
#…

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

#12

Dear Tom C.,

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

#13

On Tue, Jun 17, 2008 at 2:09 AM, Tom C. [email protected] wrote:

Robert K. 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.

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

#14

Marc H. wrote:

Dear Tom C.,

"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.
Interest assertions…or rather they might be if there were an argument
accompanying them. Name calling is easy. My argument(s) may be false,
but at least I made an effort. If you find them false, point out the
error. As for the “irritating” part - I’m supposing that that might have
to do with a perception that to attempt this might take time and effort.
But…I’m speculating.
There is
only one principle of least surprise, if ever, and this is by the one
who designs the language.
My questions stands. You do not address it. And…I believe there is
more than one hand stirring Ruby’s pot, and that is common knowledge.
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.

Certainly. No issue here.

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

Obviously, but what’s your point? The “principle of parsimony” (often
attributed to William of Occam) is well established and accepted in
philosophy, the law, and in argumentation in general. It’s NOT simply
one among many, to paraphrase you. It’s fundamental - to good reason
and, one could assert (and I do) to good design in general. And to
aesthetics.

The point of parsimony, aside from the avoidance or the error which tend
to propagate as a function of complexity, would seem to have to do with
the issue of usability which the original poster brought up. That which
is simple is generally more understandable and thus more useful. Seems
like a truly key idea, to me.

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

A good tool, poorly applied, is none the worse for it.

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

Who made THAT silly assertion? Not me.

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.

To repeat (and I do so in part because you did not address these
matters) - I agreed that the particular syntactic issue at hand appears
to be trivial to most of us most of the time, and also that its
surprising nature leads me, at least, to wonder about other sorts of
subtle, hidden issues which may be causing trouble in Ruby. (And give me
credit for suggesting that such trouble as I encounter is far more
likely to be self-caused than language caused.). It’s reasonable to
suppose such hidden issues
exist, though probably not reasonable to worry too much about them.
They can be fun to talk about however.

t.

–

Tom C., MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
#15

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.

I wouldn’t say that this is unused. I came across this issue when
trying to write an ACL method, looking something like this:
only( a :guest and not the @user ) do end # => ‘a’ and ‘the’ are both
methods returning boolean based on supplied arg

Am I unable to have methods which rely on the result of a boolean
expression, without having to resort to double parenthesis, or
remembering to put the subtle extra space? That surprises me very
much, and definitely prevents me from using it. It’s a source of hard-
to-find bugs.

#16

On 17 Jun., 14:42, hakunin [email protected] wrote:

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.

I wouldn’t say that this is unused. I came across this issue when
trying to write an ACL method, looking something like this:
only( a :guest and not the @user ) do end # => ‘a’ and ‘the’ are both
methods returning boolean based on supplied arg

Not sure how this can work since obviously you want to evaluate the
ACL on access time and not when you define it. Why don’t you use a
block?

only { a :guest and not the @user }

Cheers

robert

#17

Todd B. wrote:

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

Todd

Actually, I have, at the graduate level…and I do. It’s a principle
(got the spelling right this time, I hope). One aims at it, and hope to
get close. I suggest that in this case Ruby may not have gotten close
enough. That’s all.

t.

–

Tom C., MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
#18

On Jun 17, 8:42 am, hakunin [email protected] wrote:

expression, without having to resort to double parenthesis, or
remembering to put the subtle extra space? That surprises me very
much, and definitely prevents me from using it. It’s a source of hard-
to-find bugs.

Certainly I could do only( a(:guest) && !the(@user) ) but you can see
what this does to a nice convenient acl method.

#19

On Jun 17, 8:52 am, Robert K. [email protected] wrote:

Not sure how this can work since obviously you want to evaluate the
ACL on access time and not when you define it. Why don’t you use a
block?

only { a :guest and not the @user }

Cheers

robert

I don’t want to go too off-topic, as I just wanted to show a usage
example. To be quick - I’m doing web dev, and in my case the role
“guest” and the object @user are stored in current_user session
object. The method is supposed to be like this: only(who){ #do
something for this particular “who” }-- the block passed to “only”
will run only if the boolean returns true.

#20

On Jun 17, 9:11 am, hakunin [email protected] wrote:

I wouldn’t say that this is unused. I came across this issue when
Cheers

robert

I don’t want to go too off-topic, as I just wanted to show a usage
example. To be quick - I’m doing web dev, and in my case the role
“guest” and the object @user are stored in current_user session
object. The method is supposed to be like this: only(who){ #do
something for this particular “who” }-- the block passed to “only”
will run only if the boolean returns true.

It will make more sense if I mentioned this is used by designer in
html templates to output or omit certain parts. : ) But that’s beyond
the subject, once again.