On 1/23/24 19:47, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 16:27:25 -0800, Keith Thompson wrote:
>
>> I believe the only thing iso646.h demonstrates is the (largely former)
>> need to write C on systems that do not support full ASCII.
>
> It does seem a very late addition for a purpose which would have been a
> lot more relevant decades earlier. By that point, implementations that did
> not support full ASCII would have been museum pieces.

No, <iso646.h> was approved as part of AMD1, in 1995. For the countries
it was targeted at, full ASCII was not a tenable solution - it could not
be used to write their languages. The were still using encodings such as
shift-JIS and ISO/IEC 8859-10. Those did not become museum pieces until
after the widespread adoption of Unicode, which came out in 1996, and
did not become widely supported for many years after that.

>> If you want to use it in your own code, nobody will stop you.
>
> But will I continue to hear complaints from you about it?

If you've misunderstood the comments you've already received as
complaints, I think it's quite likely that you'll continue doing so.

On Tue, 23 Jan 2024 23:56:11 -0500, James Kuyper wrote:

> No, <iso646.h> was approved as part of AMD1, in 1995. For the countries
> it was targeted at, full ASCII was not a tenable solution - it could not
> be used to write their languages. The were still using encodings such as
> shift-JIS and ISO/IEC 8859-10.

But ASCII is a 7-bit code. The ISO 8859 codes are all ASCII supersets. And
also remember what the “shift” in “shift-JIS” stands for. Oh, and the name
of the corporation that created it in the first place is a bit of a
giveaway.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 23 Jan 2024 23:56:11 -0500, James Kuyper wrote:
>> No, <iso646.h> was approved as part of AMD1, in 1995. For the countries
>> it was targeted at, full ASCII was not a tenable solution - it could not
>> be used to write their languages. The were still using encodings such as
>> shift-JIS and ISO/IEC 8859-10.
>
> But ASCII is a 7-bit code.

Yes, we know.

> The ISO 8859 codes are all ASCII supersets.

Right, so ISO 8859-10 might not have been a good example.

> And
> also remember what the “shift” in “shift-JIS” stands for.

Remember? I never knew. Feel free to enlighten us if it's relevant.

> Oh, and the name
> of the corporation that created it in the first place is a bit of a
> giveaway.

Since you don't seem inclined to share that information, it was
developed by a Japanese company called "ASCII Corporation". Perhaps you
could explain whether and how that's relevant.

In the Shift-JIS encoding, character 0x5C, which is the backslash in
ASCII and Unicode, is the Yen sign. That means that if a C source file
contains "Hello, world\n", viewing it as Shift-JIS makes it look like
"Hello, world¥n", but a C compiler that treats its input as ASCII would
see a backslash. C's use of almost all of the printable ASCII
characters caused problems on systems that used certain other character
sets. Trigraphs, digraphs, and <iso646.h> were all attempts to lessen
the impact of those problems. (Of these, only trigraphs are relevant
for the backslash character.)

EBCDIC systems were another problem area; for example at least some
variants of EBCDIC have no '[' and ']' characters.

Unicode and UTF-8 (or, if necessary, UTF-16) have largely reduced the
need for these solutions, but the problems were very real in 1995, and
may still be present in some niche environments today.

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

On Tue, 23 Jan 2024 06:54:56 +0100, Janis Papanagnou wrote:

> ... in my professional contexts there where even [coding] standards
> defined that you had to follow.

What about the open-source code that your company takes without paying? Do
you demand that that code follow your rules as well? Do you send it back
to the developers to demand they rewrite it for you?

On Tue, 23 Jan 2024 21:43:44 -0800, Keith Thompson wrote:

> In the Shift-JIS encoding, character 0x5C, which is the backslash in
> ASCII and Unicode, is the Yen sign. That means that if a C source file
> contains "Hello, world\n", viewing it as Shift-JIS makes it look like
> "Hello, world¥n", but a C compiler that treats its input as ASCII would
> see a backslash.

So what exactly does iso646.h offer to deal with this?

..

..

..

(crickets)

..

..

..

On 23.01.2024 18:21, Lew Pitcher wrote:
> On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:
>> On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:
>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>
>>>> ... I don't use the matching names in C++ either ...
>>>
>>> I do, if/when I do use C++ and C. Don’t you think it improves readability:
>>>
>> It breaks the rule that, in C, variables and functions are alphnumeric,
>> whilst operators are symbols. sizeof is an exception, but a justified
>> one. However it's harder to justify a symbol for "plus" but a word for "or".
>
> Less importantly, it also violates the convention that C macros are named in
> upper case to distinguish them from keywords and "regular" identifiers.

Interestingly the convention had been (AFAICT) to uppercase *all* CPP
items, _mostly_. But in practice we've seen CPP function macros that
were lowercase even in system headers (ISTR some functions in stdio).
It certainly has advantages to uppercase macro functions to be sure
about possible side effects, like in FUNCT(a++). OTOH, for plain CPP
constants literals it's probably unnecessary to capitalize them.

> [...]

Janis

On 23.01.2024 21:32, Kalevi Kolttonen wrote:
>
> The term "conditional and" is probably not so good, but the
> meaning of it here refers to the familiar short-circuiting
> behaviour of C's "&&". The same behaviour exists in, I
> think, all UNIX shells.
>
> If I write this in bash:
>
> rm foo.txt && rm bar.txt
>
> then if the first rm-command fails with a non-zero exit value,
> then the second rm-command is not executed at all.

I don't think shell's behavior is so intuitive (unless also
considering the evaluation semantics)

$ echo a || echo b && echo c
a c

Janis

On 23.01.2024 22:30, Kaz Kylheku wrote:
> On 2024-01-23, David Brown <david.brown@hesbynett.no> wrote:
>> On 22/01/2024 21:34, Lawrence D'Oliveiro wrote:
>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>
>>>> ... I don't use the matching names in C++ either ...
>>>
>>> I do, if/when I do use C++ and C. Don’t you think it improves readability:
>>
>> No. But I fully appreciate that this is personal preference and habit.
>
> I believe that some of the identifiers improves readability for people
> coming from a programming language which uses those English words for
> very similar operators rather than && and ||.

Well, I can only speaking for myself. But as someone originally coming
from such languages I have no problems with these operators. (== vs =
aggravated me more).

> [...]
>
> For that reason, these identifiers should not be used, except for
> machine-encoding of programs into a 6 bit character set.
>
> [...]
>
> Clearly, the purpose of this header is to allow C to be written with the
> ISO 646 character set. The choices of identifiers do not look like
> evidence of readability having been highly prioritized.

I don't quite understand your thought. The "6-bit characters" OSes
that I used had no lowercase letters, as opposed to IA5/ASCII/ISO646.

To be sure I had also re-inspected the ASCII character set and it
seems that all C characters (including these operators) are anyway
in the ASCII domain. It's beyond me why they've used the name
"iso646.h".

Janis

On 23.01.2024 22:50, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 06:47:10 +0100, Janis Papanagnou wrote:
>
>> There's also problems with these names. For example '&&' has not the
>> semantics of 'and' but of 'and_then', 'or' is actually 'or_else'.
>
> Funnily enough, that is how the languages that offer those words interpret
> them. Not just C and C++.

From the languages I know of that support them (Ada and Eiffel) these
languages support both forms.

Janis

On 23.01.2024 22:52, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 17:21:40 -0000 (UTC), Lew Pitcher wrote:
>
>> Less importantly, it also violates the convention that C macros are
>> named in upper case to distinguish them from keywords and "regular"
>> identifiers.
>
> Why does C allow lowercase in macro names, then?

It's the nature of "conventions" to take the place where there's no
rule.

Janis

On 23.01.2024 21:13, Keith Thompson wrote:
> [...] There's no hard rule that operators must be
> punctuation, just a general trend.)

Anyone still writing "MULTIPLY a BY b GIVEN c" ? :-)

(Luckily I've never programmed in COBOL, even after
it allowed "COMPUTE c = a * b" (or some such).)

Janis

On 23.01.2024 23:09, Kaz Kylheku wrote:
> [...]
> whereas in the shell:
>
> (((a && b) || c) && d)
>
> where I'm using "virtual parentheses". If you actually stick in real
> ones, they denote subshell execution in a separate process. (Bash
> allows curly braces for command grouping that doesn't create
> processes.)

Make that "POSIX allows..." (it's standard behavior for POSIX shells).

Janis

On 23.01.2024 23:37, Kalevi Kolttonen wrote:
>
> [...] I am
> pretty sure that not all computer languages
> provide guarantees about the order of evaluation.

What?!

Janis

On 24.01.2024 00:33, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 14:51:52 -0800, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Tue, 23 Jan 2024 17:21:40 -0000 (UTC), Lew Pitcher wrote:
>>>
>>>> Less importantly, it also violates the convention that C macros are
>>>> named in upper case to distinguish them from keywords and "regular"
>>>> identifiers.
>>>
>>> Why does C allow lowercase in macro names, then?
>>
>> Because it's a convention, not a language rule.
>
> So what would one mean by “violate”, other than “I personally don’t like
> it”?

I would interpret it in [professional] project contexts where more
than one person is programming on the same project.

Janis

On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 23.01.2024 18:21, Lew Pitcher wrote:
>> On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:
>>> On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:
>>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>>
>>>>> ... I don't use the matching names in C++ either ...
>>>>
>>>> I do, if/when I do use C++ and C. Don’t you think it improves readability:
>>>>
>>> It breaks the rule that, in C, variables and functions are alphnumeric,
>>> whilst operators are symbols. sizeof is an exception, but a justified
>>> one. However it's harder to justify a symbol for "plus" but a word for "or".
>>
>> Less importantly, it also violates the convention that C macros are named in
>> upper case to distinguish them from keywords and "regular" identifiers.
>
> Interestingly the convention had been (AFAICT) to uppercase *all* CPP
> items, _mostly_. But in practice we've seen CPP function macros that
> were lowercase even in system headers (ISTR some functions in stdio).
> It certainly has advantages to uppercase macro functions to be sure
> about possible side effects, like in FUNCT(a++). OTOH, for plain CPP
> constants literals it's probably unnecessary to capitalize them.

You might think, but due to scoping, they can cause problems, unless
they are namespaced. If you define macro like

#define speed 42.0

anything which includes this cannot use the speed identifier
for any purpose. Not as a structure member name, enumerator, parameter
name, function name, typedef, goto label, nothing.

If we use SPEED instead, and never use such an identifier as a function,
parameter, or any of those roles I mentioned, then we have a kind of
namespace separation.

This is why simple constants are capitalized.

What we don't want to capitalize are function-like macros (those
that take parameters) which are well-behaved and blend nicely into the
language. Making them SHOUT just reduces the nice blending.

A function-like macro is not invoked if it is not followed by an open
parenthesis, which reduces the possibility of a clash.

Macros that do weird things, and/or have severe or bizarre contextual
restrictions on their use probably ought to SHOUT.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 24.01.2024 01:45, James Kuyper wrote:
> On 1/23/24 16:28, Scott Lurndal wrote:
>>
>> The term 'conditional and' has been in common use for decades.
>
> I've never heard of it. When searching Wikipedia, [...]

In the context of Ada I read about "boolean operator" ('and')
and "boolean shortcut operator" ('and then').

In an Eiffel book (which oriented its this operator choice on Ada)
they speak about "non-commutative" operators when the mean the e.g.
'and then' sorts of operators.

In my book the other formulation(s) mentioned in the threads are
clear enough to understand them (I did, at least) and unless one
is on the argument trip we should stop that fruitless discussion.

Janis

On 24.01.2024 07:05, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 06:54:56 +0100, Janis Papanagnou wrote:
>
>> ... in my professional contexts there where even [coding] standards
>> defined that you had to follow.
>
> What about the open-source code that your company takes without paying? Do
> you demand that that code follow your rules as well? Do you send it back
> to the developers to demand they rewrite it for you?

Since you're making up your comfort situations feel free to answer them
yourself.

On 24.01.2024 00:10, Keith Thompson wrote:
>
> The header was introduced to make it easier (or possible) to write C
> code on systems/keyboards that don't support certain characters like '&'
> and '|' -- similar to digraphs and trigraphs.

I think this is the most likely explanation; the restricted _keyboards_
(and not the restricted [ASCII] character set). Matches my experiences
with old keyboards I used decades ago.

Janis

On 23/01/2024 22:30, Kaz Kylheku wrote:
> On 2024-01-23, David Brown <david.brown@hesbynett.no> wrote:
>> On 22/01/2024 21:34, Lawrence D'Oliveiro wrote:
>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>
>>>> ... I don't use the matching names in C++ either ...
>>>
>>> I do, if/when I do use C++ and C. Don’t you think it improves readability:
>>
>> No. But I fully appreciate that this is personal preference and habit.
>
> I believe that some of the identifiers improves readability for people
> coming from a programming language which uses those English words for
> very similar operators rather than && and ||.
>
> In a green field programming language design, it's probably better
> to design that way from the start. It's a nice bonus if a language
> looks readable to newcomers.
>

Agreed.

> Generations of C coders are used to && and || though; that's the normal
> way to write C. Using these aliases is a vanishingly rare practice. An
> important aspect of readability is writing code like everyone else. When
> a language is newly designed so that there isn't anyone else, that
> doesn't have to be considered.
>

Agreed. (Although people coming to your new language probably have
experience with some other languages, and you'll want to avoid being
confusingly different from common existing languages. Choosing "&&" and
"&" for "bitwise and" and "logical and" would be a bad idea for a new
language, even if it arguably makes more sense based on the prevalence
of these operator usages.)

> For that reason, these identifiers should not be used, except for
> machine-encoding of programs into a 6 bit character set.
>
> Additionally certain names in the iso646.h header are poorly considered,
> and obstruct readability. They use the _eq suffix for an operation that
> is assignment.
>
> #define and_eq &=
>
> If the purpose of this header were to optimize readability for those
> unfamiliar with C, this should be called
>
> #define and_set &=
>
> or similar.

Or "bitmask" ?

>
> The assignment operator = should not be read "equals", but "becomes" or
> "takes the value" or "is assigned" or "is set to". This should be taken
> into consideration when coming up with word-like token or token fragment
> to represent it.

Yes.

>
> Also note the following inconsistency:
>
> #define and &&
> #define bitand &
> #define and_eq &= // what happened to "bit"?
>
> This looks like and_eq should correspond to &&=, since and is &&,
> and bitand is &. &= wants to be bitand_eq.
>
> Clearly, the purpose of this header is to allow C to be written with the
> ISO 646 character set. The choices of identifiers do not look like
> evidence of readability having been highly prioritized.
>

They are still better than trigraphs :-)

On 24.01.2024 09:25, Kaz Kylheku wrote:
> On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 23.01.2024 18:21, Lew Pitcher wrote:
>>> On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:
>>>> On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:
>>>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>>>
>>>>>> ... I don't use the matching names in C++ either ...
>>>>>
>>>>> I do, if/when I do use C++ and C. Don’t you think it improves readability:
>>>>>
>>>> It breaks the rule that, in C, variables and functions are alphnumeric,
>>>> whilst operators are symbols. sizeof is an exception, but a justified
>>>> one. However it's harder to justify a symbol for "plus" but a word for "or".
>>>
>>> Less importantly, it also violates the convention that C macros are named in
>>> upper case to distinguish them from keywords and "regular" identifiers.
>>
>> Interestingly the convention had been (AFAICT) to uppercase *all* CPP
>> items, _mostly_. But in practice we've seen CPP function macros that
>> were lowercase even in system headers (ISTR some functions in stdio).
>> It certainly has advantages to uppercase macro functions to be sure
>> about possible side effects, like in FUNCT(a++). OTOH, for plain CPP
>> constants literals it's probably unnecessary to capitalize them.
>
> You might think, but due to scoping, they can cause problems, unless
> they are namespaced. If you define macro like
>
> #define speed 42.0
>
> anything which includes this cannot use the speed identifier
> for any purpose. Not as a structure member name, enumerator, parameter
> name, function name, typedef, goto label, nothing.

Umm.., but that is just a normal name clash situation.

I mean I see where you're coming from but that doesn't seem convincing.
The convention then "disallows" (sort of) use of
char* TLA = "three letter acronym";
because its lexical form is "reserved" (in an artificial name-space)
for CPP entities?

I suppose we just disagree on that point (or have other preferences).

>
> If we use SPEED instead, and never use such an identifier as a function,
> parameter, or any of those roles I mentioned, then we have a kind of
> namespace separation.
>
> This is why simple constants are capitalized.
>
> What we don't want to capitalize are function-like macros (those
> that take parameters) which are well-behaved and blend nicely into the
> language. Making them SHOUT just reduces the nice blending.
>
> A function-like macro is not invoked if it is not followed by an open
> parenthesis, which reduces the possibility of a clash.
>
> Macros that do weird things, and/or have severe or bizarre contextual
> restrictions on their use probably ought to SHOUT.

I'm familiar a design philosophy where it's even unnecessary to write
parenthesis in function calls in case there's no arguments, so I know
what you're aiming at. Only the fact that the CPP is just a poor tool
that does simple replacements may lead to issues, say, FUN(a) a+a
and a call with FUN(b++) . Notwithstanding that we could discuss the
responsibility of the macro designer, such behavior at least may be a
reason to clearly indicate that caution is necessary here.

I think we agree here.

Janis

On 24/01/2024 09:25, Kaz Kylheku wrote:
> On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 23.01.2024 18:21, Lew Pitcher wrote:
>>> On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:
>>>> On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:
>>>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>>>
>>>>>> ... I don't use the matching names in C++ either ...
>>>>>
>>>>> I do, if/when I do use C++ and C. Don’t you think it improves readability:
>>>>>
>>>> It breaks the rule that, in C, variables and functions are alphnumeric,
>>>> whilst operators are symbols. sizeof is an exception, but a justified
>>>> one. However it's harder to justify a symbol for "plus" but a word for "or".
>>>
>>> Less importantly, it also violates the convention that C macros are named in
>>> upper case to distinguish them from keywords and "regular" identifiers.
>>
>> Interestingly the convention had been (AFAICT) to uppercase *all* CPP
>> items, _mostly_. But in practice we've seen CPP function macros that
>> were lowercase even in system headers (ISTR some functions in stdio).
>> It certainly has advantages to uppercase macro functions to be sure
>> about possible side effects, like in FUNCT(a++). OTOH, for plain CPP
>> constants literals it's probably unnecessary to capitalize them.
>
> You might think, but due to scoping, they can cause problems, unless
> they are namespaced. If you define macro like
>
> #define speed 42.0
>
> anything which includes this cannot use the speed identifier
> for any purpose. Not as a structure member name, enumerator, parameter
> name, function name, typedef, goto label, nothing.
>
> If we use SPEED instead, and never use such an identifier as a function,
> parameter, or any of those roles I mentioned, then we have a kind of
> namespace separation.
>
> This is why simple constants are capitalized.

A better choice would be:

static const double speed = 42.0;

That has none of the scoping or identifier issues that you mention.

Alternatively, if I had to use #define for some reason, I'd prefer:

#define maximum_speed 42.0

or some other appropriate name that would not clash with other
identifiers (in that translation unit) because it has a unique name that
will not be re-used. I find that far neater than using all-caps to make
an alternative namespace.

>
> What we don't want to capitalize are function-like macros (those
> that take parameters) which are well-behaved and blend nicely into the
> language. Making them SHOUT just reduces the nice blending.
>
> A function-like macro is not invoked if it is not followed by an open
> parenthesis, which reduces the possibility of a clash.
>
> Macros that do weird things, and/or have severe or bizarre contextual
> restrictions on their use probably ought to SHOUT.
>

Agreed.

I need good reasons to SHOUT an identifier - it needs to be something
that can easily have unexpected effects.

On 24/01/2024 01:06, bart wrote:
> On 23/01/2024 22:47, Kalevi Kolttonen wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Tue, 23 Jan 2024 19:32:26 -0000 (UTC), Kalevi Kolttonen wrote:
>>>
>>>> Dennis Ritchie has said that he regretted the spelling of creat(2)
>>>> function. Presumably the abbreviation was supposed to save one byte of
>>>> storage.
>>>
>>> Given that, in POSIX, all the functions of creat(2) have been subsumed
>>> under open(2) anyway, we can largely ignore that.
>>
>> I know. creat() is now completely redundant because
>> open() suffices. The reason I brought it up was just
>> so that people would realize that at least sometimes
>> it was a matter of saving storage space - even one
>> byte.
>>
>>> There are other worse problems with C. Like its use of “=” (the
>>> mathematical equality operator) for assignment, instead of using the
>>> “:=”
>>> symbol that the Algols had adopted.
>>
>> Well I started with Microsoft BASIC on Commodore 64 39 years ago.
>> So I am well used to "=" and do not consider it a problem.
>
> I've used ":=" with Algol and "=" with Fortran (a bit longer ago).
>
> That is not itself the problem.
>
> The problem is allowing both assignment and equality within the same
> expression, which is what C does. Algol, Fortran and BASIC didn't do that.
>
> If that wasn't the case, then you could use "=" for both assignment, and
> equality, without ambiguity.
>
> Languages that use ":=" and "=" for those operations, fare better than C
> that uses "=" and "==".
>
>>>> But the Python designers botched at least one thing concerning that
>>>> philosophy: private functions are not defined by "private" keyword like
>>>> in Java but instead the designers violated their own basic principle of
>>>> easy readability: the "privateness" is defined by by prefixing the
>>>> function names with an underscore ("_").
>>>
>>> That is merely a convention, a hint that the user might want to stay
>>> away
>>> from such a symbol, not a hard requirement, which is why it was designed
>>> that way. As Guido van Rossum has said: “We are all consenting adults
>>> here”.
>>
>> What?! Are you saying that there is no way to label functions as private
>> in Python? That sounds absolutely horrible. Why would anyone design a
>> language with object-oriented features without support for encapsulation?
>
> Python is 'ultra-dynamic'. That's why it's so hard to make it
> performant. So you can do this:
>
>     import math
>
>     math.pi = "pie"
>     math.sqrt = lambda x:x*x
>
>     print(math.pi*2)
>     print(math.sqrt(10))
>
> Output is:
>
>     piepie
>     100
>

Nothing beats Forth:

: 1 2 ; ok
1 1 + . 4 ok

Redefining "1" to mean "2" is a great way to obfuscate your code :-)

On 24/01/2024 00:16, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Tue, 23 Jan 2024 14:51:52 -0800, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Tue, 23 Jan 2024 17:21:40 -0000 (UTC), Lew Pitcher wrote:
>>>>> Less importantly, it also violates the convention that C macros are
>>>>> named in upper case to distinguish them from keywords and "regular"
>>>>> identifiers.
>>>>
>>>> Why does C allow lowercase in macro names, then?
>>>
>>> Because it's a convention, not a language rule.
>>
>> So what would one mean by “violate”, other than “I personally don’t like
>> it”?
>
> Obviously, it would mean not following the convention.
>
> There clearly is a convention that most macro names should be defined in
> all caps. Equally clearly, the standard library does not uniformly
> follow that convention. I have no problem with that.
>
> I might have some more thoughts on the matter, but I'm not sure where
> you're going with this.
>
I always write clamp() and lerp() in any numerical C code that goes
beyond a certain complexity. They are function-like macros, and should
look like functions. Of course you can pass parameters with side
effects, but unlikely in practice.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 23/01/2024 18:34, bart wrote:
> On 23/01/2024 16:32, Malcolm McLean wrote:
>> On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:
>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>
>>>> ... I don't use the matching names in C++ either ...
>>>
>>> I do, if/when I do use C++ and C. Don’t you think it improves
>>> readability:
>>>
>> It breaks the rule that, in C, variables and functions are
>> alphnumeric, whilst operators are symbols. sizeof is an exception, but
>> a justified one. However it's harder to justify a symbol for "plus"
>> but a word for "or".
>
> But it's OK to justify 'pow' for exponentiation?
>
Mathematically operators are functions, so a mathematican would say that
"add" is just as much of a function as "gamma". But to a computer
programmer an operator compiles to a trivial number of machine code
instructions, whilst a function is a subroutine call. Pow is not usually
supported in hardware. However it's such a basic mathematical function
that it has special notation. So some languages say it should be an
operator. However ASCII won't represent the standard notation. SO there
are good arguments for and against pow as an operators, and different
language take differnet views. But I think the C decision is better, as
C code is for programming computers, not for translating formulae into
machine readable form.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 24/01/2024 12:20, Malcolm McLean wrote:
> On 23/01/2024 18:34, bart wrote:
>> On 23/01/2024 16:32, Malcolm McLean wrote:
>>> On 22/01/2024 20:34, Lawrence D'Oliveiro wrote:
>>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>>
>>>>> ... I don't use the matching names in C++ either ...
>>>>
>>>> I do, if/when I do use C++ and C. Don’t you think it improves
>>>> readability:
>>>>
>>> It breaks the rule that, in C, variables and functions are
>>> alphnumeric, whilst operators are symbols. sizeof is an exception,
>>> but a justified one. However it's harder to justify a symbol for
>>> "plus" but a word for "or".
>>
>> But it's OK to justify 'pow' for exponentiation?
>>
> Mathematically operators are functions, so a mathematican would say that
> "add" is just as much of a function as "gamma". But to a computer
> programmer an operator compiles to a trivial number of machine code
> instructions, whilst a function is a subroutine call. Pow is not usually
> supported in hardware. However it's such a basic mathematical function
> that it has special notation. So some languages say it should be an
> operator. However ASCII won't represent the standard notation.

Which is what? Usually the operator is implied when using mathematical
notation, as is multiply.

Computer languages commonly use '**' or '^' for this operator.

SO there
> are good arguments for and against pow as an operators, and different
> language take differnet views. But I think the C decision is better, as
> C code is for programming computers, not for translating formulae into
> machine readable form.

C's decision is possibly the worst. A proper built-in operator, say
'**', can be overloaded to work on both ints and floats.

If you do 'pow(a,3)' in C when 'a' is an integer, then it will convert
to a float, call the external function, and return a float result, which
is likely to force neighbouring terms and operators to work as floats too.

Using 'a**3', that would probably be a call to an integer power
function, but here it can also easily choose to do a*a*a.