Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #161988 > unrolled thread

How to disambiguate macro?

Back to article view | Back to comp.lang.c

Contents

  How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-20 11:15 +0000
    Re: How to disambiguate macro? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 13:49 +0100
      Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-20 12:56 +0000
        Re: How to disambiguate macro? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 15:36 +0100
          Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-21 01:48 +0000
            Re: How to disambiguate macro? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-20 19:18 -0700
            Re: How to disambiguate macro? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-20 20:27 -0700
              Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-21 04:15 +0000
                Re: How to disambiguate macro? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-21 02:00 -0700
                Re: How to disambiguate macro? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-21 06:02 -0400
            Re: How to disambiguate macro? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-21 06:00 -0400
              Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-21 10:10 +0000
                Re: How to disambiguate macro? Bart <bc@freeuk.com> - 2021-07-21 11:30 +0100
                Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-21 13:31 +0200
                Re: How to disambiguate macro? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 13:02 +0100
                  Re: How to disambiguate macro? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 14:20 +0100
                    Re: How to disambiguate macro? Bart <bc@freeuk.com> - 2021-07-21 15:15 +0100
                      Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-21 16:28 +0200
                      Re: How to disambiguate macro? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 16:20 +0100
                        Re: How to disambiguate macro? Bart <bc@freeuk.com> - 2021-07-21 17:34 +0100
                          Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-21 19:46 +0200
                            Re: How to disambiguate macro? Manfred <noname@add.invalid> - 2021-07-21 20:42 +0200
                              Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-22 08:37 +0200
                            Re: How to disambiguate macro? Bart <bc@freeuk.com> - 2021-07-21 20:47 +0100
                              Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-22 08:47 +0200
                                Re: How to disambiguate macro? Bart <bc@freeuk.com> - 2021-07-22 11:31 +0100
                                Re: How to disambiguate macro? antispam@math.uni.wroc.pl - 2021-07-22 14:37 +0000
                                  Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-22 18:15 +0200
                          Re: How to disambiguate macro? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 21:19 +0100
                  Re: How to disambiguate macro? Manfred <noname@add.invalid> - 2021-07-21 15:42 +0200
                    Re: How to disambiguate macro? scott@slp53.sl.home (Scott Lurndal) - 2021-07-21 15:39 +0000
                Re: How to disambiguate macro? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-21 09:22 -0700
                Re: How to disambiguate macro? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-21 17:24 -0400
                  Re: How to disambiguate macro? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-21 16:42 -0700
                    Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-22 05:49 +0000
                      Re: How to disambiguate macro? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-22 19:11 -0400
                  Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-22 05:30 +0000
                    Re: How to disambiguate macro? scott@slp53.sl.home (Scott Lurndal) - 2021-07-22 14:14 +0000
                    Re: How to disambiguate macro? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 17:06 +0100
                  OT: possessive adjectives (Was: How to disambiguate macro?) Manfred <noname@add.invalid> - 2021-07-22 15:04 +0200
                    Re: OT: possessive adjectives Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 13:37 -0700
            Re: How to disambiguate macro? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 13:58 -0700
    Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-20 14:50 +0200
      Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-20 13:19 +0000
        Re: How to disambiguate macro? Bart <bc@freeuk.com> - 2021-07-20 14:40 +0100
          Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-20 21:02 +0200
        Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-20 21:00 +0200
        Re: How to disambiguate macro? David Brown <david.brown@hesbynett.no> - 2021-07-21 08:15 +0200
        Re: How to disambiguate macro? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 23:17 -0700
    Re: How to disambiguate macro? John Forkosh <forkosh@panix.com> - 2021-07-20 12:51 +0000
    Re: How to disambiguate macro? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-07-20 08:47 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#162025

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.

[toc] | [prev] | [next] | [standalone]

#162026

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.

[toc] | [prev] | [next] | [standalone]

#162035

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!

[toc] | [prev] | [next] | [standalone]

#162027

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.

[toc] | [prev] | [next] | [standalone]

#162036

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.

[toc] | [prev] | [next] | [standalone]

#162037

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

[toc] | [prev] | [next] | [standalone]

#162040

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

[toc] | [prev] | [next] | [standalone]

#162042

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

[toc] | [prev] | [next] | [standalone]

#162028

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.

[toc] | [prev] | [next] | [standalone]

#162018

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.

> 
>> For example, && is commutative, i.e., a&&b == b&&a.
> 
> && is not commutative.

Also for the OP:
The *C operator* && is not commutative.
The logical AND operation is, but that's a difference between the C 
operator and the logical operation.

> 
> <cut>
>> I'd never consider a&&b to mean that a is a guard on b's execution.
> 
> That is your choice, of course, but that's a big part of what the
> operator is for.
> 

[toc] | [prev] | [next] | [standalone]

#162022

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.

[toc] | [prev] | [next] | [standalone]

#162023

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

[toc] | [prev] | [next] | [standalone]

#162029

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.

[toc] | [prev] | [next] | [standalone]

#162031

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 */

[toc] | [prev] | [next] | [standalone]

#162034

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 )

[toc] | [prev] | [next] | [standalone]

#162043

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
    }

[toc] | [prev] | [next] | [standalone]

#162033

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 )

[toc] | [prev] | [next] | [standalone]

#162039

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

[toc] | [prev] | [next] | [standalone]

#162041

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.

[toc] | [prev] | [next] | [standalone]

#162038 — OT: possessive adjectives (Was: How to disambiguate macro?)

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]

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web