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

[Dave Bass]

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

 

[botp]

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

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

 

[Robert Klemme]

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

 

[hakunin]

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


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

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?

 

[botp]

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

 

[Dave Bass]

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

 

[Robert Klemme]

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.

If you're in favour of clarity, why not

x = some_work()
putx x if x

Kind regards

robert

 

[Dave Bass]

x = some_work()
putx x if x

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

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.



Dave

 

[David A. Black]

Hi --

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

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.

Your version only tests for false, not both false and nil, so it's not
equivalent to the 'and' one or to Robert's last one. The abstraction
of the nil and false objects into the category of boolean falsehood,
which will fail an 'if' test, isn't *that* hard to get And then
you get to have code that's both short and clear


David

 

[Robert Klemme]

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

Yes, I can see you struggling in it.

Note that I wrote "Clarity wins over conciseness every time for me."

So then why did you care to go through multiple negations?

The
more English-like the code is, the easier it is to understand (for me
anyway).

Exactly. That's why I offered a variant that not only has the same
semantics as my version with "and" but also reads much better than
your double negation.

Kind regards

robert

 

[Dave Bass]

Exactly. That's why I offered a variant that not only has the same
semantics as my version with "and" but also reads much better than
your double negation.

But my double negation is completely and absolutely clear! The whole
point of putting "unless x == false" is that it WON'T respond to nil,
only to false.

The x variable is presumably supposed to be Boolean, i.e. true/false. If
there's a possibility that some_work() could return nil and assign it to
x, it's likely to be because something went wrong within some_work().
That can and should be picked up by a separate test such as "if x.nil?".

It's shortcuts like writing "if x" instead of "unless x == false" that
conceal the potential for bugs. If one means "unless x == false" then
one should write it. If on the other hand one means "unless (x == false
|| x == nil)" then one should write that instead.

Clarity is more important than conciseness.

Dave