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

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** 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.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** 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> Internetworking, Powered by BBN, Burlington, MA *** DON'T
    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
        in C because I had asked one of them about it about 20 years ago
        (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  
 
 [ 53 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software