Derivation of PL/I (was Usenet group for PL/M language)
Author Message
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

>> I think if you replace "binary" with "arithmetic", you'll find that the
>> rule is consistent.  It doesn't extend to logical operators.

>Why is   A &= B; allowed but A &&= B; is not allowed?

Like I said, assignment expresssions are consistent for arithmetic
operators, but don't extend to logical operators.  `&&' is a logical
operator (that is, it deals with things that are of Boolean type).

Quote:
>Repeat complaint for >> and <<.

`>>' is an arithmetic operator, so the corresponding assignment
operator exists.

`>' is a logical operator, so there is no corresponding assignment
operator.

Tim.
--
Tim Goodwin   | "If you don't know what closures are, you probably don't
Leicester, UK | want to know what closures are." -- Larry Wall

Mon, 05 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)
On Wed, 16 Feb 2000 22:47:52 GMT, Barry Margolin

Quote:

> It's very difficult to come up with a language based on just a few
> syntactic and semantic principles and have it be powerful enough to
> be useful.

Lisp managed.

George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================

Mon, 05 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:
>    ^^, which seems to be missing, is not necessary because
>    both expressions need to be evaluated in all cases.

>    lhs ^^ rhs   ===>  !!(lhs) != !!(rhs)

It's true that a logical XOR would require evaluation of both sides, but
the argument that it should be excluded because its function can be done
with another expression is specious.  *All* logical operators can be
replaced with alternate expressions; that's not a reason to leave one off.

The operators && and || are also not *needed* - they can be easily
replaced as well.

--
#include <standard.disclaimer>
_
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Mon, 05 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

>On Wed, 16 Feb 2000 22:47:52 GMT, Barry Margolin

>> It's very difficult to come up with a language based on just a few
>> syntactic and semantic principles and have it be powerful enough to
>> be useful.

>Lisp managed.

I'm quite familiar with Lisp, and I thought of it when I made that
statement.  I don't think it managed.

I don't think Lisp has anything akin to C's <op>=, which is the context of
that statement.  The closest thing is probably SETF, but it's full of
special cases; there's a fixed list of extraction operators that it works
with.  Common Lisp also has over two dozen special operators and about 150
standard macros, all with ideosyncratic behavior, so I don't think it could
be considered to have "just a few syntactic and semantic principles."

--

*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Mon, 05 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:
>It's true that a logical XOR would require evaluation of both sides, but
>the argument that it should be excluded because its function can be done
>with another expression is specious.  *All* logical operators can be
>replaced with alternate expressions; that's not a reason to leave one off.

>The operators && and || are also not *needed* - they can be easily
>replaced as well.

&& and || were created primarily for their short-circuit behavior.  C was
hardly innovative in this respect -- quite a few languages have analogous
short-circuit logical operators.  The C designers were merely including a
feature that has been popular across a wide variety of languages.

Since ^^ cannot be short-circuited, it does not have a similar raison
d'etre, so it wasn't created.

You're presumably claiming that && and || also serve the purpose of
treating their arguments as logical, rather than arithemtic, values, and
for that purpose ^^ would make sense.  The ommission of ^^ is the evidence
that the designers considered this a lesser feature of && and ||, and not a
reason to create such operators in the first place.

--

*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Mon, 05 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

[note followups!]

Barry> && and || were created primarily for their short-circuit
Barry> behavior.  C was hardly innovative in this respect -- quite
Barry> a few languages have analogous short-circuit logical
Barry> operators.  The C designers were merely including a feature
Barry> that has been popular across a wide variety of languages.

Yes, and by precisely this argument every language is copying machine
code.  The punch card was one of the most flexible programming
'languages' ever to exist.

Barry> Since ^^ cannot be short-circuited, it does not have a
Barry> similar raison d'etre, so it wasn't created.

You could assign semantics to ^^ that give it purpose.  Specifically,
the order of evaluation may not be defined.  This could in theory
allow some optimizations.  The || operator can be dangerous if the
short-circuited code had side-effects.  Many people use the &&
operator for things like,

if(p && *p=thePID)  /* zero is root process. */
...

Some beginners get confused by this.

Barry> You're presumably claiming that && and || also serve the
Barry> purpose of treating their arguments as logical, rather than
Barry> arithemtic, values, and for that purpose ^^ would make
Barry> sense.  The ommission of ^^ is the evidence that the
Barry> designers considered this a lesser feature of && and ||,
Barry> and not a reason to create such operators in the first
Barry> place.

You could also have operators like a logical 'implies'.  Of course
this is just the 'if' statement or a ternary with an empty expression.

I think the balance of language design is not to make it overly complex.
logical OR and AND seem to be in more common use than logical XOR.  XOR
is an excellent operator for GF(2) processing.  It doesn't makes as much
sense in a logical context.  An exchange operator, as well as rotate
operator would seem to be more useful than logical XOR in a language
intended for system coding.

Barry> SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to
Barry> newsgroups.  Please DON'T copy followups to me -- I'll
Barry> assume it wasn't posted to the group.

Please quit cross-posting to so many newsgroups!  I don't think this
belongs in comp.arch.embedded.  I doubt that it is relevant to
comp.realtime either.

Bill

--
Brain surgery is more of a dextrous skill than cerebral.

Mon, 05 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

>>        ^^, which seems to be missing, is not necessary because
>>        both expressions need to be evaluated in all cases.

^^^^ ^^^^^^^^^^^ ^^^^ ^^ ^^ ^^^^^^^^^ ^^ ^^^ ^^^^^^

Quote:

>>        lhs ^^ rhs   ===>  !!(lhs) != !!(rhs)

>It's true that a logical XOR would require evaluation of both sides, but
>the argument that it should be excluded because its function can be done
>with another expression is specious.  *All* logical operators can be
>replaced with alternate expressions; that's not a reason to leave one off.
>The operators && and || are also not *needed* - they can be easily
>replaced as well.

Then, you misunderstood the thrust of my argument.

The equivalent of:

if(f(a) || g(b)) h(c);

is:

if(!f(a)) if(!g(b)) {} else {h(c);}

which is not a single expression.  It has to be written in
such a manner to achieve the ``minimal'' evaluation
characteristic.  It is also not at all ``obvious;'' unlike:

if(f(a) && g(b)) h(c);

whish is

if(f(a)) if(g(b)) h(c);

which still is not a single expression.

v = f(a) ^^ g(b);

could be replaced by:

#define LXOR(lhs,rhs) (!!(lhs) != !!(rhs))

v = LXOR(f(a),g(b))

The operators && and || can not be easily replaced with
their complete semantics.

Quote:
>--
>#include <standard.disclaimer>
> _
>Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
>Per the FCA, this email address may not be added to any commercial mail list

Mail Stop 318, Fermilab, Kirk & Pine Rds., PO Box 500, Batavia, IL 60510-0500,
USA.  (Speaking for myself and not for US, US DOE, FNAL nor URA.)  (Product,
trade, or service marks herein belong to their respective owners.)

Tue, 06 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

>You could assign semantics to ^^ that give it purpose.  Specifically,
>the order of evaluation may not be defined.  This could in theory
>allow some optimizations.  The || operator can be dangerous if the
>short-circuited code had side-effects.  Many people use the &&
>operator for things like,

I quote from the _first_ edition of The C Programming Language
by Brian W. Kernighan and Dennis M. Ritchie (from my 9th printing
copy) on pages 190 and 191:

The && operator groups from left-to-right.  It returns
1 if both of its operands are non-zero, 0 otherwise.
Unlike &, && guarantees left-to-right evaluation;
moreover the second expression is not evaluated if
the first operand is 0.

and:
The || operator groups from left-to-right.  It returns
1 if either of its operands are non-zero, 0 otherwise.
Unlike |, || guarantees left-to-right evaluation;
moreover the second expression is not evaluated if
the first operand is non-zero.

It would be bad language design to provide a ^^ operator without
providing the left-to-right evaluation guarantee just because
the guarantee of ``minimal'' evaluation can not be provided.

I am quite sure of the intent of the && and || logical operators
(unfortunately, presently, I do not remember which one---if I
must guess, then I would guess that it was Dennis Ritchie.)

Quote:

> if(p && *p=thePID)  /* zero is root process. */
>    ...

>Some beginners get confused by this.

By definition, it is the nature of beginners to be confused.

Are you confused by this?

Quote:
>    Barry> You're presumably claiming that && and || also serve the
>    Barry> purpose of treating their arguments as logical, rather than
>    Barry> arithemtic, values, and for that purpose ^^ would make
>    Barry> sense.  The ommission of ^^ is the evidence that the
>    Barry> designers considered this a lesser feature of && and ||,
>    Barry> and not a reason to create such operators in the first
>    Barry> place.

Barry, the && and || operators are logical operators.
Op cit, page 190 lists && as the logical AND operator
and page 191 lists || as the logical OR operator.

The logical operators treat their operand or operands
as true (non-zero) and false (0) and return 1 for a
true result and 0 for a false result.

Quote:
>You could also have operators like a logical 'implies'.  Of course
>this is just the 'if' statement or a ternary with an empty expression.

The if statement does not permit an empty expression as its
test condition nor does the ternary operator permit empty
expressions at all.

Quote:
>Please quit cross-posting to so many newsgroups!  I don't think this
>belongs in comp.arch.embedded.  I doubt that it is relevant to
>comp.realtime either.

In the sense that real-time programming implies a need
for optimal performance, the short circuit evaluation
characters of the && and || logical operators are
relevant to real-time programming.

Quote:
>Bill

Mail Stop 318, Fermilab, Kirk & Pine Rds., PO Box 500, Batavia, IL 60510-0500,
USA.  (Speaking for myself and not for US, US DOE, FNAL nor URA.)  (Product,
trade, or service marks herein belong to their respective owners.)

Tue, 06 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

> >It's true that a logical XOR would require evaluation of both sides, but
> >the argument that it should be excluded because its function can be done
> >with another expression is specious.  *All* logical operators can be
> >replaced with alternate expressions; that's not a reason to leave one off.

> >The operators && and || are also not *needed* - they can be easily
> >replaced as well.

> && and || were created primarily for their short-circuit behavior.  C was
> hardly innovative in this respect -- quite a few languages have analogous
> short-circuit logical operators.  The C designers were merely including a
> feature that has been popular across a wide variety of languages.

> Since ^^ cannot be short-circuited, it does not have a similar raison
> d'etre, so it wasn't created.

You cannot short-circuit ^^, but you *can* give a guarantee of single
evaluation of each argument.  The only way I can think of to do this
without ^^ is to say something like

(!!a + !!b == 1)

which is hardly expressive.

Quote:
> [...]

[followups set to clc,clm]
--

Compugen Ltd.          |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.    |Tel: +972-3-7658514 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555    http://3w.compugen.co.il/~ariels

Wed, 07 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

...

Quote:
>> Since ^^ cannot be short-circuited, it does not have a similar raison
>> d'etre, so it wasn't created.

>You cannot short-circuit ^^,

But you can guarantee left to right evaluation.

Quote:
>but you *can* give a guarantee of single
>evaluation of each argument.  The only way I can think of to do this
>without ^^ is to say something like

>    (!!a + !!b == 1)

>which is hardly expressive.

(!a != !b)

(!a ^ !b)       /* Which is probably most expressive */

Or to guarantee left to right evaluation

(a ? !b : !!b)

Note b gets evaluated exactly once (as of course does a).

--
-----------------------------------------

-----------------------------------------

Wed, 07 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

>>>You cannot short-circuit ^^,

>>But you can guarantee left to right evaluation.

>You could, but why would you want to?  The guaranteed left-to-right
>evaluation in && and || is important because it goes well with short
>circuiting.  This allows you to put a guard expression first, as in idioms
>like:

>        p && p = p->next

>What idioms do you imagine require ^^ with defined ordering?

The problem is that there aren't too many situations where I would imagibe
i being used at all. I just figure that if anybody is going to implement
is they might as well do it at least consistently with && and ||.

--
-----------------------------------------

-----------------------------------------

Thu, 08 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

> Why is   A &= B; allowed but A &&= B; is not allowed?

& is an arithmetic operation.
&& is a logical operation.

Quote:
> Repeat complaint for >> and <<.

A <<= B; is allowed.

--

`-_-'   Ar rug t barrg ar do mhactre inniu?
'U`
"I *am* \$PHB" -- Skud.

Fri, 09 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:
>> Why is   A &= B; allowed but A &&= B; is not allowed?

>& is an arithmetic operation.
>&& is a logical operation.

My reading of the post implies that the poster knows the
difference between & and &&, so I don't think that was the
question.

I know of no reason why  A &&= B wouldn't be allowed other than
the language designer just didn't think it useful enough to
bother.

A &&= B  could be defined to be the same as A = A && B.  It
just isn't.

--
Grant Edwards                   grante             Yow!  Is this BOISE??
at
visi.com

Fri, 09 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:
>> Why is   A &= B; allowed but A &&= B; is not allowed?

Because A &= B is a PDP-11 instruction, and A &&= B isn't.

Fri, 09 Aug 2002 03:00:00 GMT
Derivation of PL/I (was Usenet group for PL/M language)

Quote:

>>> Why is   A &= B; allowed but A &&= B; is not allowed?

>Because A &= B is a PDP-11 instruction, and A &&= B isn't.

That sounds like a good explination.

--
Grant Edwards                   grante             Yow!  I wish I was a
at               sex-starved manicurist
visi.com            found dead in the Bronx!!

Fri, 09 Aug 2002 03:00:00 GMT

 Page 3 of 4 [ 53 post ] Go to page: [1] [2] [3] [4]

Relevant Pages