[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

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

hakunin

6/17/2008 2:37:00 AM

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!
30 Answers

Justin Collins

6/17/2008 2:49:00 AM

0

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

hakunin

6/17/2008 4:09:00 AM

0

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

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.

Robert Klemme

6/17/2008 6:14:00 AM

0

On 17.06.2008 06:08, hakunin wrote:
> On Jun 16, 10:48 pm, Justin Collins <justincoll...@ucla.edu> 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

Tom Cloyd

6/17/2008 7:10:00 AM

0

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

Robert Klemme

6/17/2008 7:40:00 AM

0

2008/6/17 Tom Cloyd <tomcloyd@comcast.net>:
> 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

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

Michael Ulm

6/17/2008 7:45:00 AM

0

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

Leslie Viljoen

6/17/2008 8:02:00 AM

0

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

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

Tom Cloyd

6/17/2008 8:33:00 AM

0

Robert Klemme wrote:
> 2008/6/17 Tom Cloyd <tomcloyd@comcast.net>:
>
>> 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.
>
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.
>
>> 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.
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.
> 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.
>
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 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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Calamitas

6/17/2008 8:59:00 AM

0

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

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

Peña, Botp

6/17/2008 10:15:00 AM

0

From: Robert Klemme [mailto:shortcutter@googlemail.com]=20
#..
# 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=3D{}
#=3D> {}

h[true] =3D true
#=3D> true

h[false] =3D false
#=3D> false

h[true]
#=3D> 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=3D=3D1]
SyntaxError: compile error
(irb):56: syntax error, unexpected kIF_MOD, expecting ']'
h [true if 1=3D=3D1]
^

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

x =3D (true and false)
#=3D> false

x =3D (false and true)
#=3D> false

h[x]
#=3D> false

so,

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

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

h [(true if 1=3D=3D1)]
#=3D> true

note that the ff does not err though

h [if 1=3D=3D1 and 2=3D=3D2 then true else false end]
#=3D> true

h [if 1=3D=3D1 or 2=3D=3D2 then true else false end]
#=3D> 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.=20

kind regards -botp