On 21/07/2021 14:20, Ben Bacarisse wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Neither B nor BCPL had short-circuit logical operators, relying instead
>> on bitwise & and |, as did early C.
>
> Minor correction. B didn't have short-circuit & and | as such, but it
> had a weird rule that in conditional contexts like
>
> if (a & b) ...
>
> the operator short-circuited! C rightly ditched this contextual
> interpretation in favour of explicitly short-circuiting operators.
>

That's not so weird. I used to have something similar (not in C) where
'A and B' (ie. logical and, also 'or') short-circuited in conditional
expressions as used in 'if' and 'while' control expressions, which
tended to be implemented with branching.

But in ordinary expressions, they didn't.

I now have and/or operators that always short-circuit, but I did briefly
have versions that never short-circuited. I called these 'andb' and
'orb' (the 'b' meaning evaluate both). However I couldn't think of
enough use-cases for them.

Evaluation of the second term can usually be forced when needed.

On 21/07/2021 16:15, Bart wrote:
> On 21/07/2021 14:20, Ben Bacarisse wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Neither B nor BCPL had short-circuit logical operators, relying instead
>>> on bitwise & and |, as did early C.
>>
>> Minor correction.  B didn't have short-circuit & and | as such, but it
>> had a weird rule that in conditional contexts like
>>
>>    if (a & b) ...
>>
>> the operator short-circuited!  C rightly ditched this contextual
>> interpretation in favour of explicitly short-circuiting operators.
>>
>
> That's not so weird. I used to have something similar (not in C) where
> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
> expressions as used in 'if' and 'while' control expressions, which
> tended to be implemented with branching.
>
> But in ordinary expressions, they didn't.

It is perhaps not /weird/, but it is highly confusing and risky in the
face of side-effects. It is a seriously bad idea.

Borland Pascal (and Delphi) let you choose to make "and" (and "or")
short-circuiting as an optimisation option, controllable locally with
the Pascal equivalent of pragmas. Again, it is a dangerous idea.

If a language allows side-effects in expressions and sub-expressions,
then the programmer needs to know /exactly/ when they will be executed.
It's fine to say "a && b" is /always/ short-circuiting, and fine to say
it is /never/ short-circuiting - you know either way. It is a terrible
idea to say it is /sometimes/ short-circuiting, depending on how the
expression is used.

Of course, if "b" has no side-effects then it might be good for the
compiler to short-circuit it regardless of the language rules - but
that's just optimisation and efficiency, not a matter of language
semantics and program correctness.

>
> I now have and/or operators that always short-circuit, but I did briefly
> have versions that never short-circuited. I called these 'andb' and
> 'orb' (the 'b' meaning evaluate both). However I couldn't think of
> enough use-cases for them.
>
> Evaluation of the second term can usually be forced when needed.

Bart <bc@freeuk.com> writes:

> On 21/07/2021 14:20, Ben Bacarisse wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Neither B nor BCPL had short-circuit logical operators, relying instead
>>> on bitwise & and |, as did early C.
>> Minor correction. B didn't have short-circuit & and | as such, but it
>> had a weird rule that in conditional contexts like
>> if (a & b) ...
>> the operator short-circuited! C rightly ditched this contextual
>> interpretation in favour of explicitly short-circuiting operators.
>
> That's not so weird. I used to have something similar (not in C) where
> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
> expressions as used in 'if' and 'while' control expressions, which
> tended to be implemented with branching.
>
> But in ordinary expressions, they didn't.

I'm don't see how this would persuade someone that it's not weird. A
private language is never going to be used by someone other than the
world authority on its semantics.

In public-facing languages, such context-sensitive semantics seem to me
to be the epitome of "weird".

--
Ben.

Manfred <noname@add.invalid> writes:
>On 7/21/2021 2:02 PM, Ben Bacarisse wrote:
>> John Forkosh <forkosh@panix.com> writes:
>>
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> On 7/20/21 9:48 PM, John Forkosh wrote:
>>>> ...
>>>>> i.e., "What the heck is he doing that for?" But then again, I never
>>>>> much liked relying that (a&&b) always evaluates a first, immediately
>>>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>>>> exactly what the next C standard might mess around with.
>>>>
>>>> That is a pretty fundamental feature of C; it's one of the last features
>>>> of C that I would ever expect to see changed. It would break far too
>>>> much existing code.
>>>
>>> I wouldn't be too complacent about that in the future.
>>
>> There absolutely zero chance that the semantics of && will change like
>> that. It is as deliberate a design choice as any in the language.
>> Neither B nor BCPL had short-circuit logical operators, relying instead
>> on bitwise & and |, as did early C. && and || were deliberately added
>> to simplify many common operations:
>>
>> while (np != 0 && np->data != 0) ...
>>
>>> And even today I wouldn't be so blithely sure.
>>
>> I am not "blithely sure", I'm sure for very good reasons!
>
>Just more explicit for the OP:
>- This behaviour is mandated by the standard.
>- This behaviour has been a key feature of the operator since the
>beginning of time, so if anything is going to change in the C standard,
>it's not going to be this part.

And indeed it is also known as "conditional and", which implies that
a false first term will prevent evaluation of subsequent terms.

Although one can find useless tutorials on the web
that are misleading and incomplete, if not incorrect, e.g.

https://www.tutorialspoint.com/cprogramming/c_logical_operators.htm
https://fresh2refresh.com/c-programming/c-operators-expressions/c-logical-operators/

Note that C++ specifies 'and' as an alternative spelling of '&&',
and C supports it as well if <iso646.h> is included.

On 7/21/2021 3:10 AM, John Forkosh wrote:
>
> I wouldn't be too complacent about that in the future.
> And even today I wouldn't be so blithely sure.
> For example, && is commutative, i.e., a&&b == b&&a.
>

&& is NOT commutative in C as explained previously. && is sequenced and
short-circuited. And it will always be.

> I'd never consider a&&b to mean that a is a guard on b's execution.

Then you won't be able to write (or read) normal programs in C.

--
Best regards,
Andrey Tarasevich

On 21/07/2021 16:20, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 21/07/2021 14:20, Ben Bacarisse wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Neither B nor BCPL had short-circuit logical operators, relying instead
>>>> on bitwise & and |, as did early C.
>>> Minor correction. B didn't have short-circuit & and | as such, but it
>>> had a weird rule that in conditional contexts like
>>> if (a & b) ...
>>> the operator short-circuited! C rightly ditched this contextual
>>> interpretation in favour of explicitly short-circuiting operators.
>>
>> That's not so weird. I used to have something similar (not in C) where
>> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
>> expressions as used in 'if' and 'while' control expressions, which
>> tended to be implemented with branching.
>>
>> But in ordinary expressions, they didn't.
>
> I'm don't see how this would persuade someone that it's not weird. A
> private language is never going to be used by someone other than the
> world authority on its semantics.
>
> In public-facing languages, such context-sensitive semantics seem to me
> to be the epitome of "weird".
>

In BASIC, "=" was used for assignments, and "=" was also used as an
equality operator.

Those two contexts didn't clash, so there wasn't any confusion.

It's similar with the special expression that follows if, while etc; the
language can simply say that is a separate context.

In my case, because control expression were expected to be full of
branching anyway, but expressions had linear execution. Nowadays
branchless code is fashionable.

On 21/07/2021 18:34, Bart wrote:
> On 21/07/2021 16:20, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 21/07/2021 14:20, Ben Bacarisse wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> Neither B nor BCPL had short-circuit logical operators, relying
>>>>> instead
>>>>> on bitwise & and |, as did early C.
>>>> Minor correction.  B didn't have short-circuit & and | as such, but it
>>>> had a weird rule that in conditional contexts like
>>>>     if (a & b) ...
>>>> the operator short-circuited!  C rightly ditched this contextual
>>>> interpretation in favour of explicitly short-circuiting operators.
>>>
>>> That's not so weird. I used to have something similar (not in C) where
>>> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
>>> expressions as used in 'if' and 'while' control expressions, which
>>> tended to be implemented with branching.
>>>
>>> But in ordinary expressions, they didn't.
>>
>> I'm don't see how this would persuade someone that it's not weird.  A
>> private language is never going to be used by someone other than the
>> world authority on its semantics.
>>
>> In public-facing languages, such context-sensitive semantics seem to me
>> to be the epitome of "weird".
>>
>
> In BASIC, "=" was used for assignments, and "=" was also used as an
> equality operator.
>
> Those two contexts didn't clash, so there wasn't any confusion.
>
> It's similar with the special expression that follows if, while etc; the
> language can simply say that is a separate context.
>
> In my case, because control expression were expected to be full of
> branching anyway, but expressions had linear execution. Nowadays
> branchless code is fashionable.

That makes little sense.

In an "if", etc., your controlling expression is an expression. In an
assignment, or other expression, you are using an expression.

Are you suggesting that:

x = a && b;

if (a && b) ...

are clearly different contexts and should have different semantics,
despite "a && b" being an expression in each case?

What about

if a && b (for languages that don't need parenthesis)

and

if (a && b)

?

What about

x = a && b;
if (x) ....

It's fine to have the same symbol used in different contexts - look at
how often commas are used in most languages. Having an operator give
different meanings depending on other code around it (other than the
operands), is asking for trouble.

On 7/21/2021 7:46 PM, David Brown wrote:
> On 21/07/2021 18:34, Bart wrote:
>> On 21/07/2021 16:20, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 21/07/2021 14:20, Ben Bacarisse wrote:
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>
>>>>>> Neither B nor BCPL had short-circuit logical operators, relying
>>>>>> instead
>>>>>> on bitwise & and |, as did early C.
>>>>> Minor correction.  B didn't have short-circuit & and | as such, but it
>>>>> had a weird rule that in conditional contexts like
>>>>>     if (a & b) ...
>>>>> the operator short-circuited!  C rightly ditched this contextual
>>>>> interpretation in favour of explicitly short-circuiting operators.
>>>>
>>>> That's not so weird. I used to have something similar (not in C) where
>>>> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
>>>> expressions as used in 'if' and 'while' control expressions, which
>>>> tended to be implemented with branching.
>>>>
>>>> But in ordinary expressions, they didn't.
>>>
>>> I'm don't see how this would persuade someone that it's not weird.  A
>>> private language is never going to be used by someone other than the
>>> world authority on its semantics.
>>>
>>> In public-facing languages, such context-sensitive semantics seem to me
>>> to be the epitome of "weird".
>>>
>>
>> In BASIC, "=" was used for assignments, and "=" was also used as an
>> equality operator.
>>
>> Those two contexts didn't clash, so there wasn't any confusion.
>>
>> It's similar with the special expression that follows if, while etc; the
>> language can simply say that is a separate context.
>>
>> In my case, because control expression were expected to be full of
>> branching anyway, but expressions had linear execution. Nowadays
>> branchless code is fashionable.
>
> That makes little sense.
>
> In an "if", etc., your controlling expression is an expression. In an
> assignment, or other expression, you are using an expression.
>
> Are you suggesting that:
>
> x = a && b;
>
> if (a && b) ...
>
> are clearly different contexts and should have different semantics,
> despite "a && b" being an expression in each case?
>
> What about
>
> if a && b (for languages that don't need parenthesis)
>
> and
>
> if (a && b)
>
> ?
>
> What about
>
> x = a && b;
> if (x) ....
>
>
> It's fine to have the same symbol used in different contexts - look at
> how often commas are used in most languages. Having an operator give
> different meanings depending on other code around it (other than the
> operands), is asking for trouble.
>

This branch stemmed from the word "weird" used for a context-sensitive rule.

Now, "weird" is a subjective connotation, so I think it is not
surprising that someone does not see something as "weird" as I might do.

In fact, it /is/ obviously possible to define context dependent rules
that are formally correct, and the examples given are of real
programming languages, albeit now obsolete.

However I agree that a modern language should keep away from this
context dependent meanings.
In the context (!) of a programming language, logic consistency and
simplicity trumps semantic expressiveness.

On 21/07/2021 18:46, David Brown wrote:
> On 21/07/2021 18:34, Bart wrote:
>> On 21/07/2021 16:20, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 21/07/2021 14:20, Ben Bacarisse wrote:
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>
>>>>>> Neither B nor BCPL had short-circuit logical operators, relying
>>>>>> instead
>>>>>> on bitwise & and |, as did early C.
>>>>> Minor correction.  B didn't have short-circuit & and | as such, but it
>>>>> had a weird rule that in conditional contexts like
>>>>>     if (a & b) ...
>>>>> the operator short-circuited!  C rightly ditched this contextual
>>>>> interpretation in favour of explicitly short-circuiting operators.
>>>>
>>>> That's not so weird. I used to have something similar (not in C) where
>>>> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
>>>> expressions as used in 'if' and 'while' control expressions, which
>>>> tended to be implemented with branching.
>>>>
>>>> But in ordinary expressions, they didn't.
>>>
>>> I'm don't see how this would persuade someone that it's not weird.  A
>>> private language is never going to be used by someone other than the
>>> world authority on its semantics.
>>>
>>> In public-facing languages, such context-sensitive semantics seem to me
>>> to be the epitome of "weird".
>>>
>>
>> In BASIC, "=" was used for assignments, and "=" was also used as an
>> equality operator.
>>
>> Those two contexts didn't clash, so there wasn't any confusion.
>>
>> It's similar with the special expression that follows if, while etc; the
>> language can simply say that is a separate context.
>>
>> In my case, because control expression were expected to be full of
>> branching anyway, but expressions had linear execution. Nowadays
>> branchless code is fashionable.
>
> That makes little sense.
>
> In an "if", etc., your controlling expression is an expression. In an
> assignment, or other expression, you are using an expression.
>
> Are you suggesting that:
>
> x = a && b;
>
> if (a && b) ...
>
> are clearly different contexts and should have different semantics,
> despite "a && b" being an expression in each case?

These do different things. One results in a concrete 1 or 0 boolean
value. The other determines whether or not you jump to some label.

> What about
>
> if a && b (for languages that don't need parenthesis)
>
> and
>
> if (a && b)
>
> ?
>
> What about
>
> x = a && b;
> if (x) ....
>
>
> It's fine to have the same symbol used in different contexts - look at
> how often commas are used in most languages. Having an operator give
> different meanings depending on other code around it (other than the
> operands), is asking for trouble.

I'm not good at keeping old versions of languages. But one I've just
tried didn't even allow && in a normal expresion. It meant having to write:

x = a && b;

as the equivalent of:

x = (a && b ? 1 : 0);

So here && still has one behaviour.

But now all my languages support short-circuiting logic ops in any
context. One idea for non-short-circuiting versions of && and || was
dropped (I had too many features already), but it would have allowed:

if task1() andb task2() then
println "Both succeeded"
end

Here these are independent and you want to attempt both even if the
other failed.

Bart <bc@freeuk.com> writes:

> On 21/07/2021 16:20, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 21/07/2021 14:20, Ben Bacarisse wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> Neither B nor BCPL had short-circuit logical operators, relying instead
>>>>> on bitwise & and |, as did early C.
>>>> Minor correction. B didn't have short-circuit & and | as such, but it
>>>> had a weird rule that in conditional contexts like
>>>> if (a & b) ...
>>>> the operator short-circuited! C rightly ditched this contextual
>>>> interpretation in favour of explicitly short-circuiting operators.
>>>
>>> That's not so weird. I used to have something similar (not in C) where
>>> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
>>> expressions as used in 'if' and 'while' control expressions, which
>>> tended to be implemented with branching.
>>>
>>> But in ordinary expressions, they didn't.
>> I'm don't see how this would persuade someone that it's not weird. A
>> private language is never going to be used by someone other than the
>> world authority on its semantics.
>> In public-facing languages, such context-sensitive semantics seem to me
>> to be the epitome of "weird".
>
> In BASIC, "=" was used for assignments, and "=" was also used as an
> equality operator.

Not weird.

> Those two contexts didn't clash, so there wasn't any confusion.

That's not an expression having two meaning depending on where it's
written. That one symbol with two meanings, like ',' in C (and, indeed,
'=' in C).

--
Ben.

On 7/21/21 6:10 AM, John Forkosh wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 7/20/21 9:48 PM, John Forkosh wrote:
>> ...
>>> i.e., "What the heck is he doing that for?" But then again, I never
>>> much liked relying that (a&&b) always evaluates a first, immediately
>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>> exactly what the next C standard might mess around with.
>>
>> That is a pretty fundamental feature of C; it's one of the last features
>> of C that I would ever expect to see changed. It would break far too
>> much existing code.
>
> I wouldn't be too complacent about that in the future.

I suspect that reflects a lack of experience with C. If you had a lot of
experience with C, and in particular, a lot of experience reading other
people's C code, you should have noticed that code which relies upon
this feature of the && and || operators is extremely common. The C
committee is reluctant to make any change that would break a significant
amount of existing strictly conforming code - they would certainly not
approve a change that would break as much existing code as this one would.

> And even today I wouldn't be so blithely sure.
> For example, && is commutative, i.e., a&&b == b&&a.

As others have pointed out, that's explicitly not the case in C, and
there's lots of code that relies upon that fact in order to achieve it's
desired effects.

> So suppose you're compiling with -O3 optimization,
> and your program contains something like...
> ( (very_very_complicated_expression) && (++n>3) )
> So maybe the optimizer says to itself, "Hey, I'll
> just execute that very simple right-hand-side first,
> and if it's false then I don't have to bother evaluating
> that very complicated left-hand-side at all. Could save lots
> of time." Now maybe that's not supposed to happen,
> but it's way too subtle for my liking.

No conforming compiler is allowed to do that, and any compiler which did
would quickly break large quantities of existing code. Developers would
abandon any such compiler quite quickly - and that's a more important
issue than the fact that it doesn't conform to the standard.

> I'd never consider a&&b to mean that a is a guard on b's execution.

Which implies that you're not very experienced as a C programmer. Only a
newbie would have any uncertainty on that matter.

> It certainly doesn't look like a guard, and I wouldn't
> trust interpreting it that way. Clearly very bad practice
> and very bad advice, even if it happens to work.
It's guaranteed to work by the standard, deliberately with the intent of
allowing developers to rely upon that fact, and most C programmers have
written code that relies upon that fact for it's successful execution.
Incidentally, the same is true of C++ - and a gratuitous incompatibly
between C and C++ goes against the official policies of both the C
committee and the C++ committee.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 7/21/21 6:10 AM, John Forkosh wrote:
>>I'd never consider a&&b to mean that a is a guard on b's execution.
>Which implies that you're not very experienced as a C programmer. Only a
>newbie would have any uncertainty on that matter.

I can only agree with everything you (James) wrote about "&&".

I remember that at one point I wrote code like

try_to_do_this() &&
try_to_do_that() &&
now_try_to_do_this() &&
now_try_to_do_that() &&
now_try_to_do_this_please();

. The first function that failed would return zero,
and by this this sequence would be aborted. Kind of like

try_to_do_this();
try_to_do_that();
now_try_to_do_this();
now_try_to_do_that();
now_try_to_do_this_please();

in languages with exceptions.

There also is this idiom:

if( p && *p )...

instead of just

if( *p )...

to make sure p is not zero before dereferencing it.

When an optimizing compiler can prove that "p" is
non-zero at this point, it might even remove the guard.

Part of the problem for beginners is that evaluations
can be sequenced and have side effects in C, and so they
effectively can act a bit like executions of statements,
while in mathematics there are no sequence points in
expressions, and in mathematics evaluations do not have
specified side effects. So beginners cannot simply
transfer their knowledge of mathematical expressions
to C expressions.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 7/21/21 6:10 AM, John Forkosh wrote:
[...]
>> And even today I wouldn't be so blithely sure.
>> For example, && is commutative, i.e., a&&b == b&&a.
>
> As others have pointed out, that's explicitly not the case in C, and
> there's lots of code that relies upon that fact in order to achieve it's
> desired effects.
[...]

True -- but to be fair, it is commutative-ish.

For example, if a and be are non-volatile variables, then a&&b is
effectively equivalent to b&&a, because neither operand has side
effects.

But in the general case, of course, it's not commutative.

(ptr != NULL && *ptr == some_value) is a very common idiom, and no
future language that breaks that will be called C.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> John Forkosh wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> John Forkosh wrote:
>>> ...
>>>> i.e., "What the heck is he doing that for?" But then again, I never
>>>> much liked relying that (a&&b) always evaluates a first, immediately
>>>> becoming 0 without evaluating b at all if a is itself 0. You never know
>>>> exactly what the next C standard might mess around with.
>>>
>>> That is a pretty fundamental feature of C; it's one of the last features
>>> of C that I would ever expect to see changed. It would break far too
>>> much existing code.
>>
>> I wouldn't be too complacent about that in the future.
>
> I suspect that reflects a lack of experience with C. If you had a lot of
> experience with C, and in particular, a lot of experience reading other
> people's C code, you should have noticed that code which relies upon
> this feature of the && and || operators is extremely common.

I've been using mostly C (and some Fortran and various assemblers)
since 1984, and before that (first paying job in 1966) Fortran,
various assemblers, PL/1, Cobol, Basic and some other languages
you never heard of like Jovial. And as an independent contractor
since 1986 with contracts between 3months and 2.5years, I've read
tons (maybe megatons) of other people's C code. But can't explicitly
recall ever seeing && used as a guard. While I'm sure it must've been
there in that way somewheres/sometimes, I'm pretty sure I'd have
remembered if that were common practice. And while I've been aware
of that guard-like && semantics since K&R1 (pg19), I don't recall
seeing them ever suggest or illustrate using it as a guard.
That's just (as mentioned above) "weird" -- i.e., whereas anybody
can guess what if(a)b; means, the syntax a&&b doesn't by itself
>>connote<< any guard-like semantics. I'd use it that way if some
goofy syntactic situation warranted it -- like maybe Ben's answer
as a workaround for my original question, but never when if(a)b;
would work just as will, which is pretty much all the time.
Or maybe not: let's see a few snippets besides Ben's where you
feel a&&b as a guard is the better solution...

> The C committee is reluctant to make any change that would break
> a significant amount of existing strictly conforming code - they would
> certainly not approve a change that would break as much existing code
> as this one would.
>
>> And even today I wouldn't be so blithely sure.
>> For example, && is commutative, i.e., a&&b == b&&a.
>
> As others have pointed out, that's explicitly not the case in C,

Yeah, I meant (and thought it was clear) commutative with respect to
the logical result, not with respect to the guard-like side effects.

> and there's lots of code that relies upon that fact in order to
> achieve it's desired effects.

Yeah, I see I was wrong suggesting some future standard (or present
implementation) might behave differently. I still don't like it,
but it's probably safe to assume it'll work as intended for the
forseeable future.

>> So suppose you're compiling with -O3 optimization,
>> and your program contains something like...
>> ( (very_very_complicated_expression) && (++n>3) )
>> So maybe the optimizer says to itself, "Hey, I'll
>> just execute that very simple right-hand-side first,
>> and if it's false then I don't have to bother evaluating
>> that very complicated left-hand-side at all. Could save lots
>> of time." Now maybe that's not supposed to happen,
>> but it's way too subtle for my liking.
>
> No conforming compiler is allowed to do that, and any compiler which did
> would quickly break large quantities of existing code. Developers would
> abandon any such compiler quite quickly - and that's a more important
> issue than the fact that it doesn't conform to the standard.
>
>> I'd never consider a&&b to mean that a is a guard on b's execution.
>
> Which implies that you're not very experienced as a C programmer. Only a
> newbie would have any uncertainty on that matter.
>
>> It certainly doesn't look like a guard, and I wouldn't
>> trust interpreting it that way. Clearly very bad practice
>> and very bad advice, even if it happens to work.
>
> It's guaranteed to work by the standard, deliberately with the intent of
> allowing developers to rely upon that fact, and most C programmers have
> written code that relies upon that fact for it's successful execution.
> Incidentally, the same is true of C++ - and a gratuitous incompatibly
> between C and C++ goes against the official policies of both the C
> committee and the C++ committee.

--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
> (ptr != NULL && *ptr == some_value) is a very common idiom

Okay, thanks, that's a good example where && used as a guard
is a useful construction.

Hmm... and I've got to admit that it's strange I don't recall
running across it. My own stuff usually looks more like, say,
int myfunc ( int *ptr ) {
int status = 0;
if ( ptr == NULL ) goto end_of_job;
do_some_stuff_dereferencing_ptr;
status = 1;
end_of_job: return ( status ); }
i.e., args (or malloc's return, etc) are explicitly checked
to guard a whole block of subsequent code. Your
(ptr != NULL && *ptr == some_value)
only guards that one single ptr dereference statement,
whereas I'd imagine most functionality would involve
further ptr derefernces that would also need to be guarded
against nulls.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 21/07/2021 20:42, Manfred wrote:
> On 7/21/2021 7:46 PM, David Brown wrote:

>> It's fine to have the same symbol used in different contexts - look at
>> how often commas are used in most languages.  Having an operator give
>> different meanings depending on other code around it (other than the
>> operands), is asking for trouble.
>>
>
> This branch stemmed from the word "weird" used for a context-sensitive
> rule.
>
> Now, "weird" is a subjective connotation, so I think it is not
> surprising that someone does not see something as "weird" as I might do.
>

Agreed.

> In fact, it /is/ obviously possible to define context dependent rules
> that are formally correct, and the examples given are of real
> programming languages, albeit now obsolete.
>
> However I agree that a modern language should keep away from this
> context dependent meanings.
> In the context (!) of a programming language, logic consistency and
> simplicity trumps semantic expressiveness.

Agreed. Here, C is the modern language!

On 21/07/2021 21:47, Bart wrote:
> On 21/07/2021 18:46, David Brown wrote:
>> On 21/07/2021 18:34, Bart wrote:
>>> On 21/07/2021 16:20, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 21/07/2021 14:20, Ben Bacarisse wrote:
>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>>
>>>>>>> Neither B nor BCPL had short-circuit logical operators, relying
>>>>>>> instead
>>>>>>> on bitwise & and |, as did early C.
>>>>>> Minor correction.  B didn't have short-circuit & and | as such,
>>>>>> but it
>>>>>> had a weird rule that in conditional contexts like
>>>>>>      if (a & b) ...
>>>>>> the operator short-circuited!  C rightly ditched this contextual
>>>>>> interpretation in favour of explicitly short-circuiting operators.
>>>>>
>>>>> That's not so weird. I used to have something similar (not in C) where
>>>>> 'A and B' (ie. logical and, also 'or') short-circuited in conditional
>>>>> expressions as used in 'if' and 'while' control expressions, which
>>>>> tended to be implemented with branching.
>>>>>
>>>>> But in ordinary expressions, they didn't.
>>>>
>>>> I'm don't see how this would persuade someone that it's not weird.  A
>>>> private language is never going to be used by someone other than the
>>>> world authority on its semantics.
>>>>
>>>> In public-facing languages, such context-sensitive semantics seem to me
>>>> to be the epitome of "weird".
>>>>
>>>
>>> In BASIC, "=" was used for assignments, and "=" was also used as an
>>> equality operator.
>>>
>>> Those two contexts didn't clash, so there wasn't any confusion.
>>>
>>> It's similar with the special expression that follows if, while etc; the
>>> language can simply say that is a separate context.
>>>
>>> In my case, because control expression were expected to be full of
>>> branching anyway, but expressions had linear execution. Nowadays
>>> branchless code is fashionable.
>>
>> That makes little sense.
>>
>> In an "if", etc., your controlling expression is an expression.  In an
>> assignment, or other expression, you are using an expression.
>>
>> Are you suggesting that:
>>
>>     x = a && b;
>>
>>     if (a && b) ...
>>
>> are clearly different contexts and should have different semantics,
>> despite "a && b" being an expression in each case?
>
> These do different things. One results in a concrete 1 or 0 boolean
> value. The other determines whether or not you jump to some label.
>

The expressions are the same in each case. After calculating "a && b",
they do different things with the results - but that comes /later/.

The way expressions are interpreted and evaluated is, in most languages,
independent of what you do with the results. (The number of programming
languages is so vast that there are bound to be exceptions to almost any
rule or generalisation.)

If you write :

int x = 4 / 3;
float y = 4 / 3;

in most languages, you would not expect the first division to be done as
integers and the second to be done as floating point. You would expect
consistency. It might be consistently integer division, or consistently
floating point (and then converted to integer x and floating point y).
But you want consistency.

>
>
>> What about
>>
>>     if a && b     (for languages that don't need parenthesis)
>>
>> and
>>
>>     if (a && b)
>>
>> ?
>>
>> What about
>>
>>     x = a && b;
>>     if (x) ....
>>
>>
>> It's fine to have the same symbol used in different contexts - look at
>> how often commas are used in most languages.  Having an operator give
>> different meanings depending on other code around it (other than the
>> operands), is asking for trouble.
>
> I'm not good at keeping old versions of languages. But one I've just
> tried didn't even allow && in a normal expresion. It meant having to write:
>
>    x = a && b;
>
> as the equivalent of:
>
>    x = (a && b ? 1 : 0);
>
> So here && still has one behaviour.
>

I guess with your personal little languages, you never really have to
think about things like specifications, consistency, documentation,
compatibility, logical design, or any of these other things that concern
real languages. You can just make things up and modify them as you go
along, changing the language tools as often as the programs written in
the language.

> But now all my languages support short-circuiting logic ops in any
> context. One idea for non-short-circuiting versions of && and || was
> dropped (I had too many features already), but it would have allowed:
>
>   if task1() andb task2() then
>       println "Both succeeded"
>   end
>
> Here these are independent and you want to attempt both even if the
> other failed.

Adding rarely used and cryptic operators or syntaxes is always a mistake
in a language, unless there is no other way to achieve the same goals.

On 22/07/2021 07:47, David Brown wrote:
> On 21/07/2021 21:47, Bart wrote:

>> These do different things. One results in a concrete 1 or 0 boolean
>> value. The other determines whether or not you jump to some label.
>>
>
> The expressions are the same in each case. After calculating "a && b",
> they do different things with the results - but that comes /later/.

As I implement it, there is no actual result calculated from 'a && b'
when used in 'if (a && b)'.

Because once it's figured out whether the result will 1 or 0, it will
also have figured out whether to do that jump or not.

> The way expressions are interpreted and evaluated is, in most languages,
> independent of what you do with the results. (The number of programming
> languages is so vast that there are bound to be exceptions to almost any
> rule or generalisation.)
>
> If you write :
>
> int x = 4 / 3;
> float y = 4 / 3;
>
> in most languages, you would not expect the first division to be done as
> integers and the second to be done as floating point. You would expect
> consistency. It might be consistently integer division, or consistently
> floating point (and then converted to integer x and floating point y).
> But you want consistency.

A && B will consistently reqire both operands to be bools [Python and
others are a little different]. The quibble here is whether B should
always be evaluated.

I at one time (iirc) made a decision in /my/ language that B should be
evaluated when the actual result of A&&B is needed. This actually made
it /more/ consistent, not less!

So given A op B, you know that B will always be evaluated (barring A
halting execution in some way), whatever 'op' actually is.

The distinction was that 'and' was considered syntax (between and-less
expressions) when used in a conditional statement, and an operator
otherwise. This is not hard to express in a grammar.

I think that Algol68 works the same way: both operands of AND will
always be evaluated. To get short-circuiting behaviour, you need to write:

if A thef B then ...

Here, it is clear that 'thef' (I believe short for 'then if') is syntax
similar to 'then', but AND is an operator.

>> I'm not good at keeping old versions of languages. But one I've just
>> tried didn't even allow && in a normal expresion. It meant having to write:
>>
>>    x = a && b;
>>
>> as the equivalent of:
>>
>>    x = (a && b ? 1 : 0);
>>
>> So here && still has one behaviour.
>>
>
> I guess with your personal little languages, you never really have to
> think about things like specifications, consistency, documentation,
> compatibility, logical design, or any of these other things that concern
> real languages. You can just make things up and modify them as you go
> along, changing the language tools as often as the programs written in
> the language.

Not quite. Because they are self-hosted, and have been in a chain going
back decades, I have to be careful with breaking changes. If you use C
as an implementation language, then you can do what you like; there are
a million C compilers to choose from, or to reinstall if you somehow
corrupt your copy.

But yes, I still have a lot more freedom than long-established languages.

In the case of expression terms that may involve branching within the
expression, C has these:

* && and ||
* ? :

I now have those plus:

* N-way selection
* Switch
* Case (unrestricted form of Switch)
* Normal, long-form 'if'

(These are on top of the arbitrary statements that can be written inside
expressions, as they can with gnu C. But gnu C I think doesn't allow
statements of if and switch to return a value.)

>> But now all my languages support short-circuiting logic ops in any
>> context. One idea for non-short-circuiting versions of && and || was
>> dropped (I had too many features already), but it would have allowed:
>>
>>   if task1() andb task2() then
>>       println "Both succeeded"
>>   end
>>
>> Here these are independent and you want to attempt both even if the
>> other failed.
>
> Adding rarely used and cryptic operators or syntaxes is always a mistake
> in a language, unless there is no other way to achieve the same goals.
>

You mean like && & || | ! ~ ^ ?

Those are only considered non-cryptic because of familiarity! My
equivalents are:

and iand or ior not inot ixor

On 7/21/2021 11:24 PM, James Kuyper wrote:

Sorry about the grammar nit-picking, but...

>
> As others have pointed out, that's explicitly not the case in C, and
> there's lots of code that relies upon that fact in order to achieve it's
> desired effects.

The expression "it's" is a contraction for "it is", and it doesn't make
sense here. What you mean here is "its", which is the proper possessive
adjective to be used in this sentence. Confusing the two expressions
would be the same as confusing "they're" and "their".

[...]

> It's guaranteed to work by the standard, deliberately with the intent of
You got "it's" right here...

> allowing developers to rely upon that fact, and most C programmers have
> written code that relies upon that fact for it's successful execution.
.... but not here either

> Incidentally, the same is true of C++ - and a gratuitous incompatibly
> between C and C++ goes against the official policies of both the C
> committee and the C++ committee.
>

Sorry for patronizing, but your posts usually read fairly correct, so I
thought this remark might not be like the proverbial drop in an ocean in
your case - besides, I have a kind of allergy to non-compiling sentences
(even if English is not my native language, and I make mistakes myself)

[PS. the argument that this is a very common mistake doesn't work for me]

John Forkosh <forkosh@panix.com> writes:
>James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

>
>I've been using mostly C (and some Fortran and various assemblers)
>since 1984, and before that (first paying job in 1966) Fortran,
>various assemblers, PL/1, Cobol, Basic and some other languages
>you never heard of like Jovial. And as an independent contractor
>since 1986 with contracts between 3months and 2.5years, I've read
>tons (maybe megatons) of other people's C code. But can't explicitly
>recall ever seeing && used as a guard.

I've been programming in C since 1979, and in other languages since
1975.

The use of && as a guard has been frequent and common over
the last forty years. Including in Unix.

grep "&&" /work/reference/usl/unix/v7/usr/src/cmd/*.c

/work/reference/usl/unix/v7/usr/src/cmd/ac.c: while (--argc > 0 && **++argv == '-')
....
/work/reference/usl/unix/v7/usr/src/cmd/ac.c: for (j=0; j<8 && up->uname[j]==ibuf.ut_name[j]; j++);
....
/work/reference/usl/unix/v7/usr/src/cmd/date.c: if (argc>1 && argv[1][0]=='-' && argv[1][1]=='u') {
....
/work/reference/usl/unix/v7/usr/src/cmd/diff.c: if(stat(a1,&stbuf)!=-1 && ((stbuf.st_mode&S_IFMT)==S_IFDIR)) {

and the rather common idiom:

/work/reference/usl/unix/v7/usr/src/cmd/join.c: while (argc > 1 && argv[1][0] == '-') {

where the end of the while loop is:
argc--;
argv++;
}

These prevent a possible NULL pointer dereference, an out
of bounds array access and access to uninitialized
data, and there were 430 other hits on &&
in the command directly alone (not all of which were
explicitly used as a guard, to be sure).

David Brown <david.brown@hesbynett.no> wrote:
>
> The way expressions are interpreted and evaluated is, in most languages,
> independent of what you do with the results. (The number of programming
> languages is so vast that there are bound to be exceptions to almost any
> rule or generalisation.)
>
> If you write :
>
> int x = 4 / 3;
> float y = 4 / 3;
>
> in most languages, you would not expect the first division to be done as
> integers and the second to be done as floating point. You would expect
> consistency. It might be consistently integer division, or consistently
> floating point (and then converted to integer x and floating point y).
> But you want consistency.

There are languages that do overloading resolution based on result
type. In language that I frequently use both are wrong: division
on integers produces rational number and can not give back an integer.
Similarely, division for floats needs floats as arguments while
3 and 4 are not floats. But there are valid expressions in similar
spirit: they will do different things depending on result type.

Probably the most prominent example of language that has overloading
on result type is Ada. However, IIUC in C++ it is possible to
have eqivalent effect. Of course, C++ keeps built-in stuff
reasonably compatible with C, so your examples work as in C.
But there are interesting examples using user-defiend types.

AFAIK the main criterion for "weird" is familiarity: C is widely
used and several languages ape some aspects of C. But for
uninitiated many things in C look weird (including your
division example).

--
Waldek Hebisch

John Forkosh <forkosh@panix.com> writes:

> ... I've read
> tons (maybe megatons) of other people's C code. But can't explicitly
> recall ever seeing && used as a guard. While I'm sure it must've been
> there in that way somewheres/sometimes, I'm pretty sure I'd have
> remembered if that were common practice. And while I've been aware
> of that guard-like && semantics since K&R1 (pg19), I don't recall
> seeing them ever suggest or illustrate using it as a guard.

There are quite a few examples of using && as a guard in K&R.

<cut>
>>> And even today I wouldn't be so blithely sure.
>>> For example, && is commutative, i.e., a&&b == b&&a.
>>
>> As others have pointed out, that's explicitly not the case in C,
>
> Yeah, I meant (and thought it was clear) commutative with respect to
> the logical result, not with respect to the guard-like side effects.

How could that be clear when your example was of the compiler using the
supposed commutativity of && when the operands had explicit side-effects:

| So suppose you're compiling with -O3 optimization,
| and your program contains something like...
| ( (very_very_complicated_expression) && (++n>3) )

Anyway, && is not commutative even in the absence of side effects:

i < SIZE && a[i] == 0

--
Ben.

On 22/07/2021 16:37, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> The way expressions are interpreted and evaluated is, in most languages,
>> independent of what you do with the results. (The number of programming
>> languages is so vast that there are bound to be exceptions to almost any
>> rule or generalisation.)
>>
>> If you write :
>>
>> int x = 4 / 3;
>> float y = 4 / 3;
>>
>> in most languages, you would not expect the first division to be done as
>> integers and the second to be done as floating point. You would expect
>> consistency. It might be consistently integer division, or consistently
>> floating point (and then converted to integer x and floating point y).
>> But you want consistency.
>
> There are languages that do overloading resolution based on result
> type. In language that I frequently use both are wrong: division
> on integers produces rational number and can not give back an integer.
> Similarely, division for floats needs floats as arguments while
> 3 and 4 are not floats. But there are valid expressions in similar
> spirit: they will do different things depending on result type.
>

Overloading on the operand types is normal :

float y = (float) 4 / 3;

There are some languages that overload on result type too, but they are
less common.

> Probably the most prominent example of language that has overloading
> on result type is Ada. However, IIUC in C++ it is possible to
> have eqivalent effect. Of course, C++ keeps built-in stuff
> reasonably compatible with C, so your examples work as in C.
> But there are interesting examples using user-defiend types.

You can certainly do odd things with C++ to get a related effect, for
your own types. You can have a type "num" with a division operator that
returns a "deferred_division" type encapsulating the numerator and
denominator, with conversions to float, integer (and rational if you
like) which do the actual division. There is a name for that pattern,
which I have completely forgotten, and it can be useful in some types of
coding.

>
> AFAIK the main criterion for "weird" is familiarity: C is widely
> used and several languages ape some aspects of C. But for
> uninitiated many things in C look weird (including your
> division example).
>

On 7/22/21 1:49 AM, John Forkosh wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>> (ptr != NULL && *ptr == some_value) is a very common idiom
>
> Okay, thanks, that's a good example where && used as a guard
> is a useful construction.
>
> Hmm... and I've got to admit that it's strange I don't recall
> running across it. ...

I'm glad that you agree that it's strange, because it could be hard to
convince you of that if you can't remember ever noticing it. I suspect
that you have actually seen it, but failed to notice.

> ... My own stuff usually looks more like, say,
> int myfunc ( int *ptr ) {
> int status = 0;
> if ( ptr == NULL ) goto end_of_job;
> do_some_stuff_dereferencing_ptr;
> status = 1;
> end_of_job: return ( status ); }
> i.e., args (or malloc's return, etc) are explicitly checked
> to guard a whole block of subsequent code. Your
> (ptr != NULL && *ptr == some_value)
> only guards that one single ptr dereference statement,
> whereas I'd imagine most functionality would involve
> further ptr derefernces that would also need to be guarded
> against nulls.

In many cases that's not a problem:

if(ptr != NULL && ptr->value == some_value)
{
// All further dereferences will occur here, because
// we're only interested in other dereferences of
// ptr if ptr->value has the specified value.
}

And when that's not the case, this idiom shouldn't (and wouldn't) be used:

if(ptr) {

if(ptr->value == some_value) {
// some dereferences of ptr
}
// other dereferences of ptr
}

Manfred <noname@add.invalid> writes:

> On 7/21/2021 11:24 PM, James Kuyper wrote:
>
> Sorry about the grammar nit-picking, but...
>
>> As others have pointed out, that's explicitly not the case in C,
>> and there's lots of code that relies upon that fact in order to
>> achieve it's desired effects.
>
> The expression "it's" is a contraction for "it is", and it doesn't
> make sense here. What you mean here is "its", which is the proper
> possessive adjective to be used in this sentence. Confusing the
> two expressions would be the same as confusing "they're" and
> "their".
>
> [...]
>
>> It's guaranteed to work by the standard, deliberately with the
>> intent of
>
> You got "it's" right here...
>
>> allowing developers to rely upon that fact, and most C programmers
>> have written code that relies upon that fact for it's successful
>> execution.
>
> ... but not here either
>
>> Incidentally, the same is true of C++ - and a gratuitous
>> incompatibly between C and C++ goes against the official policies
>> of both the C committee and the C++ committee.
>
> Sorry for patronizing, but your posts usually read fairly correct,
> so I thought this remark might not be like the proverbial drop in
> an ocean in your case - besides, I have a kind of allergy to
> non-compiling sentences (even if English is not my native
> language, and I make mistakes myself)

It may help to remember that the same rule applies to all
personal pronouns: an apostrophe always indicates a
contraction with "am", "is" or "are" -

I am, we are - I'm, we're
you are - you're
he is, she is, it is, they are - he's, she's, it's, they're

and there is never an apostrophe in the possessive form of a
personal pronoun -

my, our
your
his, hers, its, their