# unusual OR syntax - Page 5

•  Subject
• Author
• Posted on

## Re: unusual OR syntax

Jerry Stuckle writes:

Section 2, last paragraphs of point d. Top of page 5 in the PDF.

He defines the propositions p /\ q and p \/ q as (p -> q, T -> F) and
(p -> T, T -> q) where (E1 -> E2, T -> E3) is read as "if E1 then E2,
else if T then E3"; the truth value T as the condition of the second
clause has the effect of 'else'.

He states that p /\ q is false if p is false and q undefined, while in
the same situation q /\ p is undefined. This is the short-circuiting
behaviour.

For (and E1 ...) and (or E1 ...), left to right, cut short at the
first expression that determines the value, and the value is the value
of that expression. With no sub-expressions, (or) is false and (and)
is true. There is only one value that acts as false, written #f in
Scheme and nil or () in Common Lisp; all other values are true.

## Re: unusual OR syntax

ah, which is why
\$a = 0;
function b(){return 'bee';}

\$a=3D(\$a>1 OR b());
echo \$a;// echos 1

so \$a is going to be boolean only when used like this.

## Re: unusual OR syntax

J. Frank Parnell wrote:

\$a will be a boolean when used like this.  But that may not be the only
reason it's a boolean.  For instance:

\$a = 3 > 2;

\$a would also be a boolean true.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

## Re: unusual OR syntax

Jerry Stuckle schreef:

Hi Jerry,

Of course I don't hold a grudge against a programming construct because
of a (hypothetical) nasty personal experience. That would be extremely
stupid.
Now I reread my posting I see why you interpreted it otherwise.
It could be read in (at least) two ways.
(Allthough you still shouldn't think I am that stupid.)

The guy I am talking about (senior programmer) is actually good and old
friend of me, and I don't hold a grudge against him at all.
The 'remember that' part wasn't to bully me around, it was to to tell me
I could and should expect more of that kind of programming (which I
disliked) in/with Perl.
As it turned out: I could expect that kind of programming everywhere,
not only Perl.

Yes. Once you know it and you checked the specs of the programming
language under investigation.
Before that it is uncertain because it has 'side effect' written all
over it. (See all the valid questions that popped into my head I
described above.)

You don't have to check the specs of a programming language when you
choose for the traditional if/then approach.
This whole short circuit evaluation instead is based on expecting an
optimalization occuring for evaluating boolean expressions. And yes, it
IS documented: no discussion there. But even though it is documented I
still consider it a side effect and thus ugly.
It also absolutely *feels* like a side effect.
We simply got used to it.

You can say it is 100% certain to work OK (which is right), but that
doesn't make it is a clear way of programming.

True.
I know this short circuit construct since 1995 or so (So my
understanding is just fine), but still dislike it and consider it
I know I am not the majority, since I see it everywhere.

I simply *never* saw an example of short circuit evaluation I can call
really useful (unless less code is useful in itself).

But lets drop this now.
It isn't really an important issue, and I said what I had to say about
the subject.
It guess it irritates me a little so many people consider this normal
programming, while I think it is very ugly, so I wanted to voice to that
opinion. :-)

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

## Re: unusual OR syntax

Erwin Moller

You mean like one checks the "case" template or how "for" loops are done or
how scoping works or .....

What you see as "written all over it" is simply wrong. There is no side
affect. Once more : there is no side affect.

It is 100% clear. But you are actually wrong. Some languages do not
allow short cuts like leaving off the "else". Some? Well Haskell is one.

Once again : it is not a side affect. In any shape or form.

Possibly because of your limited exposure to other languages I assume?
It is perfectly natural : or things together left to right until one
returns true. It could not be simpler.

Yes it does. 100% predictable in every way. left to right evaluation
until the first True.

You are wrong. It is a clean and well understood technique. And why it
is desigend into this and other languages. breaking a single or line
into a convoluted if/then/else over multiple lines is amateurish and
cosumes far more screen real estate than it should need.

In pseudo code

a = A() or B() or C()

really could not be simpler to read.

absolutely needed.

Worse than that : you are a tiny minority I am afraid.

I see it all the time. It is clean, concise and makes it very clear what
is being done. but you did add that "i can call" which gets you off the
hook since you are clearly anti it and NO use of it would be clear to
you.

Would you disagree with using "." in php since it doesn't work in C?
Would you write your own strcat/strcpy combo perhaps?

I must admit if I were you I would take a step back and re-evaluate
because nothing you have said support your views in any way. All you
have to say about it is that YOU think its a "side affect". It is NOT a
side affect. It is a designed, documented and well used feature of this
and other languages.

--

## Re: unusual OR syntax

Erwin Moller wrote:

Which is true of every construct in any language you're using.

Ah, but you do.  FORTRAN, for instance, uses an entirely different
syntax than PHP.  So does COBOL.

It does once you understand it - and has many advantages.  For instance:

if (isset(\$_POST['x']) && \$_POST['x'] = 'Hello') {
// do something
} else {
// do something else
}

will never give an error because the second clause is never executed if
the variable isn't defined.  And much more compact and readable than:

if (isset(\$_POST['x'])) {
if (\$_POST['x'] == 'Hello') {
// do something
} else {
// do something else
}
} else {
// do something else (again)
}

See above.

Because it is normal programming.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

## Re: unusual OR syntax

On 29 Nov 2009, Erwin Moller
wrote:

(I'm sure Erwin no longer has these questions, but I'm just
providing my gut reactions.)

Yes, in Perl and most other languages.  Java lets you use the
bitwise OR and AND operators as non-short-circuit boolean
operators.  IMO, this is far more confusing than supporting only
short-circuit operators.

Other interpreters?  "Only perl can parse Perl."  :-)

<http://en.wikipedia.org/wiki/Short-circuit_evaluation

Extremely unlikely.

No.  Internal optimization has nothing to do with this language
feature.  Internal optimizations that directly change a program's
behavior when using valid, documented constructs goes completely
against common sense.

<snip>

Huh?  If you plan to write programs in a language even semi-
seriously, you're going to have to RTFM eventually.  Presumably,
you'll want to know what the language's boolean operators are.
While you're there, you might as well take the extra three seconds
to check for short-circuit evaluation.

It seems like you're using the computer programming definition of
"side effects," not the English.  If so, I don't think it applies
here.  Short-circuit evaluation does not *cause* side effects to
take place.  Actually, a programmer unaware of short-circuit
evaluation is more likely to be confused by a *lack* of side
effects taking place.

The keywords used for constructing if-statements varies quite a
bit from language to language, and sometimes even within the same
language.  In new languages, I always check the manual for basic
syntactical constructs like this.  Relying on reading others'
source code isn't always a reliable way to learn, so the manual
should be an essential read, regardless of whether or not you like
short-circuit evaluation.

Short-circuit evaluation can actually sometimes slow down
optimization.  (Worrying about whether it actually does is
probably a futile exercise in premature optimization, however.)

make sense.  Perhaps I'm just misunderstanding; I do know that you
know your stuff when it comes to programming.

Many of the cases in which short-circuit evaluation are seemingly
unclear are just as unclear without short-circuit evaluation.
Sometimes, it just makes more sense to take something out of a
conditional statement (an initialization of some kind, for
example).

<snip>

Less code can be more useful, given that it is still concise and
clear.

echo "Deleted \$file\n";
}
else {
echo "Failed to delete \$file\n";
}

The author's intent that `unlink()' is not to be evaluated unless
write permissions are available on `\$file' seems obvious.

Indeed; I suppose I couldn't resist. :-)

--
Curtis Dyer
<? \$x='<? \$x=%c%s%c;printf(\$x,39,\$x,39);?>';printf(\$x,39,\$x,39);?>