scott@slp53.sl.home (Scott Lurndal) writes:
> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>Ben Bacarisse wrote:
>>> Haskell does not always get it right (particularly some of the older
>>> APIs) but the trend is to provide return type rich enough to include
>>> either a correct result or an explanation of the fault.
>>
>>Things like that are pretty much what i was referring to earlier when i
>>referred to making the return type more complex to handle more complex
>>situations. Obviously, it would have to be done differently in C, since C
>>doesn't support tagged unions (at least not natively—i know of a couple
>>libraries that use macro magic to implement them).
>
> In C++, a std::pair<bool, return-type> is used in that context. If the sizeof
> the return type is 64-bits or less, most modern ABI's will return it in a pair
> of registers.

<OT>
A std::pair<bool, return-type> gives you either a true value and a value
of the return type or a false value and a value of the return type.
There's no indication in the type itself that the second member is
meaningless if the first is false.

std::optional<return-type> is a better fit -- but it isn't available if
you have to deal with pre-C++17 compilers.
</OT>

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>
>> On 9/28/2023 6:52 AM, Blue-Maned_Hawk wrote:
>>
>>> Personally, i think that, at least for a library, an error
>>> should _only_ be communicated by return value. If more complex
>>> information is required, then the return value can be made more
>>> complex.
>
> ...
>
>> Error handling in libraries is a thorny subject, and I could go
>> on a long rant on it. The short summary is simply this: error
>> handling is rife with incompetence, and incompetent designs.
>> Even in languages that ostensibly provide better mechanisms than
>> C, the details are usually poorly documented and under-specified
>> [1].
>
> If it's done well, the result is not even "error handling" -- it's
> just what the function returns. For example, a lookup in a table
> of integers in Haskell returns a type that is, in effect "maybe an
> integer" The return will be either "Nothing" or something like
> "Just 42".

In languages that support it this approach is a good way to deal
with cases like this, I agree. But to me it falls in a different
category than error handling. An error condition is something
like an allocation (eg malloc()) failure, or a broken pipe. Not
finding something in a table means whoever was responsible for
adding things to the table didn't add it - in other words it was
entirely a consequence of events that are under the program's
control. The issue is how to deal with an unpredictable, and
usually very rare, event that is not something the program has
control over. Typically these kinds of situations need a
different sort of mechanism than loading up the return value
of every function call.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
>>
>>> Ben Bacarisse to Anton Shepelev:
>>>
>>>> To nit-pick a bit, in C, there is no need to declare
>>>> anything if you want to ignore an "output parameter".
>>>> Taking strtod as a (poor) example:
>>>>
>>>> double d = strtod(str, &(char *){0});
>>>
>>> Ah, but this is one of the strangest and craziest
>>> innovations of post-modern C -- the ability to pass a
>>> pointer (as it were) to a literal, rather than to a proper
>>> variable.
>>
>> Two things:
>>
>> Firstly, it's not a true literal because it is a mutable object in
>> automatic storage.
>
> It most definitely is a literal, both in the original meaning
> of the word, and also as used in the ISO C standard.

C doesn't not define what the word "literal" means. It has no syntactic
category called "literal". It has distinct constructs "string literal"
and "compound literal".

You've asserted in the past that there's a logical reason behind using
the term "literal" for these two constructs and not for others, such as
integer constants. I'm not particularly interested in debating that
point again, but I see no support in the standard for that assertion.
(The standard also uses the word "literal" as an adjective; see for
example N1570 6.1p1 where it refers to terminals in the grammar.)

My point is that any discussion of what is or is not a "true literal" is
unlikely to yield any meaningful result.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>
>>> On 9/28/2023 6:52 AM, Blue-Maned_Hawk wrote:
>>>
>>>> Personally, i think that, at least for a library, an error
>>>> should _only_ be communicated by return value. If more complex
>>>> information is required, then the return value can be made more
>>>> complex.
>>
>> ...
>>
>>> Error handling in libraries is a thorny subject, and I could go
>>> on a long rant on it. The short summary is simply this: error
>>> handling is rife with incompetence, and incompetent designs.
>>> Even in languages that ostensibly provide better mechanisms than
>>> C, the details are usually poorly documented and under-specified
>>> [1].
>>
>> If it's done well, the result is not even "error handling" -- it's
>> just what the function returns. For example, a lookup in a table
>> of integers in Haskell returns a type that is, in effect "maybe an
>> integer" The return will be either "Nothing" or something like
>> "Just 42".
>
> In languages that support it this approach is a good way to deal
> with cases like this, I agree. But to me it falls in a different
> category than error handling. An error condition is something
> like an allocation (eg malloc()) failure, or a broken pipe. Not
> finding something in a table means whoever was responsible for
> adding things to the table didn't add it - in other words it was
> entirely a consequence of events that are under the program's
> control. The issue is how to deal with an unpredictable, and
> usually very rare, event that is not something the program has
> control over. Typically these kinds of situations need a
> different sort of mechanism than loading up the return value
> of every function call.

I agree that table lookup is not a compelling example, but I don't agree
that anything different is needed. I intended the idea to be
generalised to have return values used for all error conditions. There
may be situations where something different is /better/, but I remain
sceptical of even this claim. Note I am not talking about situations
where asynchronous errors need to be reported.

C uses null pointers for this all the time. Returning a null pointer is
just a way to signal an error through the return value. In a language
like C without null pointers I would want malloc to return a 'Maybe'
type. And for when more information is wanted (like your example of a
broken pipe) the type returned from write should be a number of bytes or
an error value of some sort.

Obviously it's hard to recommend this in C since the language can't
really express the patterns needed to make it convenient, but I think we
are talking more generally here.

How would you prefer these sorts of thing to be signalled?

BTW, have you come across Icon? It takes an intriguing approach where
every operation succeeds or fails as well as having a value. This idea
is heavily built upon to produce a very comfortable scripting language.

--
Ben.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
>>>
>>>> Ben Bacarisse to Anton Shepelev:
>>>>
>>>>> To nit-pick a bit, in C, there is no need to declare
>>>>> anything if you want to ignore an "output parameter".
>>>>> Taking strtod as a (poor) example:
>>>>>
>>>>> double d = strtod(str, &(char *){0});
>>>>
>>>> Ah, but this is one of the strangest and craziest
>>>> innovations of post-modern C -- the ability to pass a
>>>> pointer (as it were) to a literal, rather than to a proper
>>>> variable.
>>>
>>> Two things:
>>>
>>> Firstly, it's not a true literal because it is a mutable object in
>>> automatic storage.
>>
>> It most definitely is a literal, both in the original meaning
>> of the word, and also as used in the ISO C standard.
>
> C doesn't not define what the word "literal" means. It has no syntactic
> category called "literal". It has distinct constructs "string literal"
> and "compound literal".
>
> You've asserted in the past that there's a logical reason behind using
> the term "literal" for these two constructs and not for others, such as
> integer constants. I'm not particularly interested in debating that
> point again, but I see no support in the standard for that assertion.
> (The standard also uses the word "literal" as an adjective; see for
> example N1570 6.1p1 where it refers to terminals in the grammar.)
>
> My point is that any discussion of what is or is not a "true literal" is
> unlikely to yield any meaningful result.

I agree, though it might be interesting to see if

ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1:
Fundamental terms.

sheds any light on the usage. This document is one of the standard's
"Normative References". I don't have this document, nor do I have access
to the right sort of library any more, so I can't help.

--
Ben.

On 2023-09-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> My point is that any discussion of what is or is not a "true literal" is
>> unlikely to yield any meaningful result.
>
> I agree, though it might be interesting to see if
>
> ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1:
> Fundamental terms.
>
> sheds any light on the usage. This document is one of the standard's
> "Normative References". I don't have this document, nor do I have access
> to the right sort of library any more, so I can't help.

FYI, I looked at this quite long ago. At that time I hunted down a
leaked version which is under a different number:
IS 14692-1 (1999). IS == Indian Standard.

I see that this can still be found.

The document does not mention "literal".

You will likely agree with my observation that the document is rather
short, and lacks substance.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
>>>
>>>> Ben Bacarisse to Anton Shepelev:
>>>>
>>>>> To nit-pick a bit, in C, there is no need to declare
>>>>> anything if you want to ignore an "output parameter".
>>>>> Taking strtod as a (poor) example:
>>>>>
>>>>> double d = strtod(str, &(char *){0});
>>>>
>>>> Ah, but this is one of the strangest and craziest
>>>> innovations of post-modern C -- the ability to pass a
>>>> pointer (as it were) to a literal, rather than to a proper
>>>> variable.
>>>
>>> Two things:
>>>
>>> Firstly, it's not a true literal because it is a mutable object in
>>> automatic storage.
>>
>> It most definitely is a literal, both in the original meaning
>> of the word, and also as used in the ISO C standard.
>
> C doesn't not define what the word "literal" means. It has no
> syntactic category called "literal". It has distinct constructs
> "string literal" and "compound literal".

I didn't say the C standard defines the term literal, only that
the standard uses the word literal in the same sense as the
original meaning. (To be clear, the uses I'm talking about are
as part of compound terms "string literal" and "compound literal",
but the sense of common meaning is the same in both.)

It's true that string literals and compound literals are
different constructs, but they are obviously related, and they
are referred to together in a few places in the C standard.

> You've asserted in the past that there's a logical reason behind
> using the term "literal" for these two constructs and not for
> others, such as integer constants. I'm not particularly interested
> in debating that point again, but I see no support in the standard
> for that assertion. (The standard also uses the word "literal" as
> an adjective; see for example N1570 6.1p1 where it refers to
> terminals in the grammar.)

I don't have my previous posting in front of me, but what I think
I said is that string literals and compound literals are both
consistent with the original meaning (in the programming world)
of the word literal, and that other constructs such as integer
constants do not share that aspect of semantic sameness. Also
IIRC I stated my view that the semantic distinction is more
valuable than a possible syntactic distinction, and so that is
worth preserving, i.e., that string literals and compound
literals deserve to be associated with the term "literal", but
constants should not.

> My point is that any discussion of what is or is not a "true
> literal" is unlikely to yield any meaningful result.

I'm not saying anything about whether something is a "true
literal", whatever that might be. What I am saying is that
a compound literal is a literal in the same sense that the
term was originally used, and that sense is consistent with
both string literals and compound literals (but not with
constants such as integer constants or floating constants).

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-28, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
>>>
>>>> Ben Bacarisse to Anton Shepelev:
>>>>
>>>>> To nit-pick a bit, in C, there is no need to declare
>>>>> anything if you want to ignore an "output parameter".
>>>>> Taking strtod as a (poor) example:
>>>>>
>>>>> double d = strtod(str, &(char *){0});
>>>>
>>>> Ah, but this is one of the strangest and craziest
>>>> innovations of post-modern C -- the ability to pass a
>>>> pointer (as it were) to a literal, rather than to a proper
>>>> variable.
>>>
>>> Two things:
>>>
>>> Firstly, it's not a true literal because it is a mutable object in
>>> automatic storage.
>>
>> It most definitely is a literal, both in the original meaning
>
> Let's examine our use of the article "a".
>
> #include <stdio.h>
>
> void fun(int c)
> {
> char x;
>
> if (c > 0) {
> printf("%p\n", (void *) &(char *){&x});
> fun(c - 1);
> }
> }
>
> [...]

> What is literal about it?

It refers an anonymous object whose initial value is determined
by the tokens making up the literal. That meaning of the term
"literal" is about 60 years old. (That meaning didn't use the
word "object" but did refer to memory that in the context of
the C standard would be called an object.)

> C99 said that a compound literal "is an expression that
> provides access to an anonymous object".
>
> Why can't we call that expression "anonymous object designator"
> or something? If we have "char *p = 0", p is a primary
> expression which designates an object, and not a literal.

You could call it a rhinoceros if you wanted to, but that
wouldn't change what the C standard calls it, or what the
original meaning of the word literal is, or that both the
term compound literal and the orginal meaning of literal
share the key property of referring to an anonymous object.

> If we then have (char *){p} we get an anonymous object that is
> initialized with a copy of p, and that expression designates it
> in much the same way as p designates its object.

They differ in one key respect: in the case of a variable, we
have to give the variable a name, and refer to the object by its
name, but in the case of a compound literal, there is no name,
and we refer to the object "by what it is". That's why it's
called a literal.

On Thu, 28 Sep 2023 22:45:24 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> > You've asserted in the past that there's a logical reason behind
> > using the term "literal" for these two constructs and not for
> > others, such as integer constants. I'm not particularly interested
> > in debating that point again, but I see no support in the standard
> > for that assertion. (The standard also uses the word "literal" as
> > an adjective; see for example N1570 6.1p1 where it refers to
> > terminals in the grammar.)
>
> I don't have my previous posting in front of me,

<86r0o887op.fsf@linuxsc.com> and <86fs4k6pgq.fsf@linuxsc.com> .

Kaz Kylheku to Ben Bacarisse:

> > OK, I see the point -- the ptr member in the returned
> > value is sort of an anonymous object -- but in my
> > opinion it's a stretch.
>
> I think the point is that Anton should find the existence
> of all anoymous temporary objects repugnant, not just the
> more recently introduced ones.

In that case, I see it as more or less a named object, its
name being the `ptr' field qualified by the function
invocation. Otherwise, I should find repugnant even simple
expressions, like:

res = sqr(x) + sqr(y);

where the return value of sqr() is techically some sort of
anonymous object, right? Well, I do not object to functions
invocations in exprssions, for the reason stated above, and
because the are similar to the universally understood
mathematical notation.

> That's why I put this under the "strange and crazy
> innovations in post-modern C" remarks.

Right. Many of you will tell me that I have to bend my
mental model to reflect the workings of C rather than trying
to bend C (e.g. by avoiding some techniques) to comply with
my mental model.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>

[..how should errors be handled..]

>>> If it's done well, the result is not even "error handling" -- it's
>>> just what the function returns. For example, a lookup in a table
>>> of integers in Haskell returns a type that is, in effect "maybe an
>>> integer" The return will be either "Nothing" or something like
>>> "Just 42".
>>
>> In languages that support it this approach is a good way to deal
>> with cases like this, I agree. But to me it falls in a different
>> category than error handling. An error condition is something
>> like an allocation (eg malloc()) failure, or a broken pipe. Not
>> finding something in a table means whoever was responsible for
>> adding things to the table didn't add it - in other words it was
>> entirely a consequence of events that are under the program's
>> control. The issue is how to deal with an unpredictable, and
>> usually very rare, event that is not something the program has
>> control over. Typically these kinds of situations need a
>> different sort of mechanism than loading up the return value
>> of every function call.
>
> I agree that table lookup is not a compelling example, but I don't
> agree that anything different is needed. I intended the idea to
> be generalised to have return values used for all error
> conditions. There may be situations where something different is
> /better/, but I remain sceptical of even this claim. Note I am
> not talking about situations where asynchronous errors need to be
> reported.
>
> C uses null pointers for this all the time. Returning a null
> pointer is just a way to signal an error through the return value.
> In a language like C without null pointers I would want malloc to
> return a 'Maybe' type. And for when more information is wanted
> (like your example of a broken pipe) the type returned from write
> should be a number of bytes or an error value of some sort.
>
> Obviously it's hard to recommend this in C since the language
> can't really express the patterns needed to make it convenient,
> but I think we are talking more generally here.

I acknowledge your statement about not considering asynchronous
errors. My own comments are likewise.

I agree that all unusual result circumstances (which might be
labeled "error conditions", without meaning to prejudice the term)
can be handled locally via either compound return values or multiple
return values (eg, by using pointer parameters), or a combination of
the two. In languages that provide good support for compound return
values, which I would say C does not, probably a single return value
(which is perhaps a compound value) always suffices, but I haven't
thought very carefully about that. But I think we are in general
agreement that it's always possible to handle error conditions via
local return values.

Where we might not agree is whether using direct return values is
always a good choice. In my view, sometimes it is, sometimes it
isn't - it depends on the particular situation. That is definitely
the case for C, but I think also for other programming languages
that have better support for multiple return values or compound
return values, or both. And certainly if needing other mechanisms
is true for languages in general then it we would expect it is true
for C.

> How would you prefer these sorts of thing to be signalled?

Let me give just one example.

kI wrote some code not long ago to add a value to a set of values,
where the set is represented using a recursive binary tree structure
(like red-black trees, but a little different). Usually we may
expect that a request to add a value would offer a value not already
included in the set, but certainly it can happen that there is a
call to add a value that is already included, in which case the top
level return value should be the original tree structure.

I thought it would be easier to write a simple recursive routine
that assumes the to-be-added value is not yet included in the set,
and if that assumption is violated raise an exception that is caught
at the outermost level and simply returns the original argument tree
value. Certainly the code could have been written to handle the
already-present situation at each level of the recursion, but it was
much easier and much cleaner to handle it by raising an exception.

That example doesn't translate to C in any obvious way, because C
code to add items to a set would very likely be written rather
differently. I think it's harder to make use of non-local returns
in C than in many other languages, because C requires more thought
and discipline to set that up. At the same time, when I look at C
code that tries to handle all exceptional conditions locally, I
can't help but think the code would be simplified overall if code
for dealing with exceptional conditions could be removed in the code
generally and instead used a different mechanism, in fewer places,
and perhaps similar to raising an exception, to handle such cases.

> BTW, have you come across Icon?

I have, and it's a fascinating language.

> It takes an intriguing approach
> where every operation succeeds or fails as well as having a value.

I have heard Icon characterized as saying "it tries to succeed",
and I think that's a fair description. The idea of integrating
a backtracking engine into the language semantics deserves more
attention than I think it has been given, which is unfortunate.

> This idea is heavily built upon to produce a very comfortable
> scripting language.

My experience with Icon is purely academic, which is to say I have
read about it but never used it. I have more experience with
Prolog, which is similar in some ways (notably backtracking) but of
course very different in other ways.

I'm intrigued by your comment that Icon makes a good scripting
language. Maybe I don't understand what you think makes a good
scripting language, or even what "scripting language" means.
That subject is not topical in comp.lang.c, but I also peruse
comp.lang.misc and comp.programming if you wouldn't mind
continuing there. Also you are welcome to send me an email
at this address if you would rather do that.

On 29/09/2023 02:35, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>> Ben Bacarisse wrote:
>>>> Haskell does not always get it right (particularly some of the older
>>>> APIs) but the trend is to provide return type rich enough to include
>>>> either a correct result or an explanation of the fault.
>>>
>>> Things like that are pretty much what i was referring to earlier when i
>>> referred to making the return type more complex to handle more complex
>>> situations. Obviously, it would have to be done differently in C, since C
>>> doesn't support tagged unions (at least not natively—i know of a couple
>>> libraries that use macro magic to implement them).
>>
>> In C++, a std::pair<bool, return-type> is used in that context. If the sizeof
>> the return type is 64-bits or less, most modern ABI's will return it in a pair
>> of registers.
>
> <OT>
> A std::pair<bool, return-type> gives you either a true value and a value
> of the return type or a false value and a value of the return type.
> There's no indication in the type itself that the second member is
> meaningless if the first is false.
>
> std::optional<return-type> is a better fit -- but it isn't available if
> you have to deal with pre-C++17 compilers.
> </OT>
>

<OT>

std::optional<> is a standard library template that is based around a
struct containing a bool and a return type, just like a std::pair<bool,
return-type> would be. I don't think it needs C++17 to implement it - I
think you could make a reasonable bash at making an "optional" template
even in pre-C++11 C++. (I believe boost::optional works with C++03.)

But there are probably a number of nuances that make it better in modern
C++, and of course it is far more convenient when it is already in the
library. And certainly if you are using C++17, it's a better choice
here than a bare pair.

</OT>

Spiros Bousbouras <spibou@gmail.com> writes:

> On Thu, 28 Sep 2023 22:45:24 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> You've asserted in the past that there's a logical reason behind
>>> using the term "literal" for these two constructs and not for
>>> others, such as integer constants. I'm not particularly interested
>>> in debating that point again, but I see no support in the standard
>>> for that assertion. (The standard also uses the word "literal" as
>>> an adjective; see for example N1570 6.1p1 where it refers to
>>> terminals in the grammar.)
>>
>> I don't have my previous posting in front of me,
>
> <86r0o887op.fsf@linuxsc.com> and <86fs4k6pgq.fsf@linuxsc.com> .

I know references like that are helpful for some people,
however they are not for me.[*] Thank you though for
trying to help.

[*] And I have no desire to change that, at least not any time
soon.

Spiros Bousbouras to Tim Rentsch:

> > I don't have my previous posting in front of me,
>
> <86r0o887op.fsf@linuxsc.com> and
> <86fs4k6pgq.fsf@linuxsc.com> .

What fine Message-Id:s! Does FSF stand for the Free
Software Fondation? Tim might appreciate working URLs to
archived messages:

http://al.howardknight.net/?ID=169556843200
http://al.howardknight.net/?ID=169556849300

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@gmail.moc> writes:

> Kaz Kylheku to Ben Bacarisse:
>
>>> OK, I see the point -- the ptr member in the returned
>>> value is sort of an anonymous object -- but in my
>>> opinion it's a stretch.
>>
>> I think the point is that Anton should find the existence
>> of all anoymous temporary objects repugnant, not just the
>> more recently introduced ones.
>
> In that case, I see it as more or less a named object, its
> name being the `ptr' field qualified by the function
> invocation. Otherwise, I should find repugnant even simple
> expressions, like:
>
> res = sqr(x) + sqr(y);
>
> where the return value of sqr() is techically some sort of
> anonymous object, right? [...]

No, it isn't. The result of calling sqr(x) is a value, not
an object. All objects have an address; the result of sqr(x)
does not. In an expression like 3+4, the 3 and the 4 are
values, not objects. That is one reason why the distinction
between constants, which are values and not objects, and
literals, which are anonymous objects, is important.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> On Thu, 28 Sep 2023 22:45:24 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> You've asserted in the past that there's a logical reason behind
>>>> using the term "literal" for these two constructs and not for
>>>> others, such as integer constants. I'm not particularly interested
>>>> in debating that point again, but I see no support in the standard
>>>> for that assertion. (The standard also uses the word "literal" as
>>>> an adjective; see for example N1570 6.1p1 where it refers to
>>>> terminals in the grammar.)
>>>
>>> I don't have my previous posting in front of me,
>>
>> <86r0o887op.fsf@linuxsc.com> and <86fs4k6pgq.fsf@linuxsc.com> .
>
> I know references like that are helpful for some people,
> however they are not for me.[*] Thank you though for
> trying to help.

I can't help wondering what you mean. You seem to use GNUS, as I do,
and I find such reference the most useful of all as just one click and
I'm, reading the referenced article in the same window.

> [*] And I have no desire to change that, at least not any time
> soon.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Spiros Bousbouras <spibou@gmail.com> writes:

[access to previous articles]

>>> <86r0o887op.fsf@linuxsc.com> and <86fs4k6pgq.fsf@linuxsc.com> .
>>
>> I know references like that are helpful for some people,
>> however they are not for me.[*] Thank you though for
>> trying to help.
>
> I can't help wondering what you mean. You seem to use GNUS, as I
> do, and I find such reference the most useful of all as just one
> click and I'm, reading the referenced article in the same window.

I expect you are simply underestimating the depth of my ignorance.
Even though I have been using emacs for more than 40 years (and the
emacs session into which I am typing this message has been up for
more than two and half years), my knowledge of emacs commands (and
including gnus commands) is very selective. My typical working
mode is to learn just enough to get by, and accumulate new
awareness only when there is some kind of nudge to do so. So far I
haven't gotten such a nudge in the direction of this capability
(and it is not at all clear how big a nudge it would take to cause
any change).

In article <87jzs9arwe.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>
>>> On Thu, 28 Sep 2023 22:45:24 -0700
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> You've asserted in the past that there's a logical reason behind
>>>>> using the term "literal" for these two constructs and not for
>>>>> others, such as integer constants. I'm not particularly interested
>>>>> in debating that point again, but I see no support in the standard
>>>>> for that assertion. (The standard also uses the word "literal" as
>>>>> an adjective; see for example N1570 6.1p1 where it refers to
>>>>> terminals in the grammar.)
>>>>
>>>> I don't have my previous posting in front of me,
>>>
>>> <86r0o887op.fsf@linuxsc.com> and <86fs4k6pgq.fsf@linuxsc.com> .
>>
>> I know references like that are helpful for some people,
>> however they are not for me.[*] Thank you though for
>> trying to help.
>
>I can't help wondering what you mean. You seem to use GNUS, as I do,
>and I find such reference the most useful of all as just one click and
>I'm, reading the referenced article in the same window.
>
>> [*] And I have no desire to change that, at least not any time
>> soon.

Be that as it may, here is (one of) the article(s) to which we are all
referring:

From tr.17687@z991.linuxsc.com Fri Sep 29 11:14:57 MDT 2023
Article: 1091108 of comp.lang.c
Path: nnrp.xmission!xmission!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: you think rust may outthrone c?
Date: Sat, 12 Aug 2023 10:57:42 -0700
Message-ID: <86r0o887op.fsf@linuxsc.com>

....
The word literal, used as a noun when describing programming
languages, came into vogue sometime after it became common to
specify language syntax by using a formal grammar (usually
expressed in some variation of Backus-Naur Form); roughly the
1970s timeframe. A typical usage would be for "literal" to be
synonymous with "terminal symbol", or perhaps with just a subset
of terminal symbols, as used in the rules of grammar. In some
cases the words "constant" and "literal" were used more or less
interchangeably.

A good decade earlier, however, the word literal was used in a
somewhat different programming language context, not as part of
describing a language but as an element of the language. The
assembly language for IBM System/360 had constants, both ordinary
numeric and character constants, and symbolic constants (defined
with EQU). Constants could be used as direct operands for some
instructions, depending on the particulars of the instruction and
for which operand, and represented values encoded directly in the
instruction. Distinct from constants there were also /literals/,
a distinct category of operand that produced the address of an
initialized anonymous region of memory. Here are two example
lines of assembly, to illustrate the difference:

OI VAL+2,X'F0'
C 3,=F'1000'

In the first line, there are two constants, 2 and X'F0'. These
tokens are numerical quantities that are used directly in the
generated instruction. (In the case of the constant 2 the value
is added to the address VAL, and it is the sum that is used to
produce the bytes of the instruction, but the key property is
that the value 2 participates locally, and not remotely.)

The second line has a constant 3 and a literal =F'1000'. Like in
the first line, the value 3 is used directly in the generated
instruction. The literal =F'1000' is not used directly. Instead,
the assembler keeps track of literals used in the program, and
uses them to initialize areas of memory elsewhere in the program.
A use of a literal, such as the =F'1000' here, results in the
address of the memory area reserved for the value of the literal.
(There are some further details about literals, such as literal
pools and the LTORG directive, that I won't explain because those
details are not important to the discussion.)

Note the parallels between how these terms are used in assembly
language and in C. Constants are used to generate code but appear
only implicitly; literals always occupy areas of memory (objects)
and use of a literal causes its address (lvalue) to be part of a
generated instruction. The distinction between constants and
literals is primarily a semantic distinction, not a syntactic one.

Besides being more historically faithful, having two different
terms provides a useful semantic distinction that would disappear
if the term "literal" were used for both concepts.

>> Given a choice between the level of confusion seen in the C++
>> standard and the level of confusion seen in the C standard ("integer
>> constant" and "integer constant expression" is confusing? really?)
>> I'm happy to be on the side of C's choice any day of the week and
>> twice on Sunday. Please cast my vote to continue using the terms
>> "constant" and "literal" as they are used in the C standard.
>
> I use those terms simply because that's how they're used in the C
> standard.

Obviously it's a good idea to use terminology in the C standard
when talking about the C language. My point though is that the
terminology used in the C standard is a better choice both
historically and semantically.

--
I voted for Trump because I thought he'd make pussy grabbing legal.
I honestly don't see any other way America could be made great again.

Anton Shepelev <anton.txt@gmail.moc> writes:

> Spiros Bousbouras to Tim Rentsch:
>
>>> I don't have my previous posting in front of me,
>>
>> <86r0o887op.fsf@linuxsc.com> and
>> <86fs4k6pgq.fsf@linuxsc.com> .
>
> What fine Message-Id:s!

Thank you. I can assure you that I played no conscious role
in selecting them. :)

> Does FSF stand for the Free Software Fondation?

Certainly it might. The colo server here runs ubuntu linux.

> Tim might appreciate working URLs to archived messages:
>
> http://al.howardknight.net/?ID=169556843200
> http://al.howardknight.net/?ID=169556849300

There are cases where I might. In this particular case I
felt confident enough simply relying on my memory, even
though it seems to be more and more in need of ECC as years
go by.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Anton Shepelev <anton.txt@gmail.moc> writes:
>> Spiros Bousbouras to Tim Rentsch:
>>>> I don't have my previous posting in front of me,
>>>
>>> <86r0o887op.fsf@linuxsc.com> and
>>> <86fs4k6pgq.fsf@linuxsc.com> .
>>
>> What fine Message-Id:s!
>
> Thank you. I can assure you that I played no conscious role
> in selecting them. :)
>
>> Does FSF stand for the Free Software Fondation?
>
> Certainly it might. The colo server here runs ubuntu linux.

Not relevant. Gnus includes ".fsf" in the Message-Ids it generates.

It also includes the domain name from which you post. (linuxsc.com in
your case). I prefer not to include that information, so I have

(setq message-user-fqdn "nosuchdomain.example.com")

in my .emacs file.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-09-29, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> I'm not saying anything about whether something is a "true
> literal", whatever that might be. What I am saying is that
> a compound literal is a literal in the same sense that the
> term was originally used, and that sense is consistent with
> both string literals and compound literals (but not with
> constants such as integer constants or floating constants).

Integer constants are not literals according some supposedly widely
understood sixty-year-old meaning of "literal"?

Are you okay?

C neglecting to use "literal" for integer constants is just a mistake.
It's okay to recognize that.

FWIW, the latest C draft does now have "compound literal constant" which
is defined using constexpr storage class. If you make one of these
beasties with int type, and give it a value like 42, then you
finally have a literal constant in C, of type int, with value 42.
That token 42 is, sadly, not called a literal.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-29, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> On Thu, 28 Sep 2023 22:45:24 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> You've asserted in the past that there's a logical reason behind
>>>> using the term "literal" for these two constructs and not for
>>>> others, such as integer constants. I'm not particularly interested
>>>> in debating that point again, but I see no support in the standard
>>>> for that assertion. (The standard also uses the word "literal" as
>>>> an adjective; see for example N1570 6.1p1 where it refers to
>>>> terminals in the grammar.)
>>>
>>> I don't have my previous posting in front of me,
>>
>> <86r0o887op.fsf@linuxsc.com> and <86fs4k6pgq.fsf@linuxsc.com> .
>
> I know references like that are helpful for some people,
> however they are not for me.[*] Thank you though for
> trying to help.
>
> [*] And I have no desire to change that, at least not any time
> soon.

I see you are using Gnus, the Emacs-based newsreader, connected
to the same NTTP server as what I'm using.

The articles referenced above are still held by the server.

In the SLRN newsreader that I'm using, there is a simple ESC-l
command that prompts for the message ID. It finds the article
and brings it into the article display. I was able to find
the articles this way.

It would be astonishing if the equivalent trick couldn't be done with
Gnus.

I quit Emacs in 1994, and have never used Gnus, but the documentation
says:

Article Keymap
--------------

[ ... ]

C-c ^
If point is in the neighborhood of a Message-Id and you press r,
Gnus will try to get that article from the server
(gnus-article-refer-article).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>
> [..how should errors be handled..]
>
>>>> If it's done well, the result is not even "error handling" -- it's
>>>> just what the function returns. For example, a lookup in a table
>>>> of integers in Haskell returns a type that is, in effect "maybe an
>>>> integer" The return will be either "Nothing" or something like
>>>> "Just 42".
>>>
>>> In languages that support it this approach is a good way to deal
>>> with cases like this, I agree. But to me it falls in a different
>>> category than error handling. An error condition is something
>>> like an allocation (eg malloc()) failure, or a broken pipe. Not
>>> finding something in a table means whoever was responsible for
>>> adding things to the table didn't add it - in other words it was
>>> entirely a consequence of events that are under the program's
>>> control. The issue is how to deal with an unpredictable, and
>>> usually very rare, event that is not something the program has
>>> control over. Typically these kinds of situations need a
>>> different sort of mechanism than loading up the return value
>>> of every function call.
>>
>> I agree that table lookup is not a compelling example, but I don't
>> agree that anything different is needed. I intended the idea to
>> be generalised to have return values used for all error
>> conditions. There may be situations where something different is
>> /better/, but I remain sceptical of even this claim. Note I am
>> not talking about situations where asynchronous errors need to be
>> reported.
>>
>> C uses null pointers for this all the time. Returning a null
>> pointer is just a way to signal an error through the return value.
>> In a language like C without null pointers I would want malloc to
>> return a 'Maybe' type. And for when more information is wanted
>> (like your example of a broken pipe) the type returned from write
>> should be a number of bytes or an error value of some sort.
>>
>> Obviously it's hard to recommend this in C since the language
>> can't really express the patterns needed to make it convenient,
>> but I think we are talking more generally here.
>
> I acknowledge your statement about not considering asynchronous
> errors. My own comments are likewise.
>
> I agree that all unusual result circumstances (which might be
> labeled "error conditions", without meaning to prejudice the term)
> can be handled locally via either compound return values or multiple
> return values (eg, by using pointer parameters), or a combination of
> the two. In languages that provide good support for compound return
> values, which I would say C does not, probably a single return value
> (which is perhaps a compound value) always suffices, but I haven't
> thought very carefully about that. But I think we are in general
> agreement that it's always possible to handle error conditions via
> local return values.
>
> Where we might not agree is whether using direct return values is
> always a good choice. In my view, sometimes it is, sometimes it
> isn't - it depends on the particular situation. That is definitely
> the case for C, but I think also for other programming languages
> that have better support for multiple return values or compound
> return values, or both. And certainly if needing other mechanisms
> is true for languages in general then it we would expect it is true
> for C.
>
>> How would you prefer these sorts of thing to be signalled?
>
> Let me give just one example.
>
> kI wrote some code not long ago to add a value to a set of values,
> where the set is represented using a recursive binary tree structure
> (like red-black trees, but a little different). Usually we may
> expect that a request to add a value would offer a value not already
> included in the set, but certainly it can happen that there is a
> call to add a value that is already included, in which case the top
> level return value should be the original tree structure.
>
> I thought it would be easier to write a simple recursive routine
> that assumes the to-be-added value is not yet included in the set,
> and if that assumption is violated raise an exception that is caught
> at the outermost level and simply returns the original argument tree
> value. Certainly the code could have been written to handle the
> already-present situation at each level of the recursion, but it was
> much easier and much cleaner to handle it by raising an exception.

This is one of those cases where I just have to take your word for it,
(and I am happy to do that).

> That example doesn't translate to C in any obvious way, because C
> code to add items to a set would very likely be written rather
> differently. I think it's harder to make use of non-local returns
> in C than in many other languages, because C requires more thought
> and discipline to set that up. At the same time, when I look at C
> code that tries to handle all exceptional conditions locally, I
> can't help but think the code would be simplified overall if code
> for dealing with exceptional conditions could be removed in the code
> generally and instead used a different mechanism, in fewer places,
> and perhaps similar to raising an exception, to handle such cases.

You may be right, but I don't like exceptions. More specifically, I
don't like exceptions that are not handled internally in some API or
other (so your tree example sounds like a sane use for them), but I
worry about their wider use. You either have to wrap every call in a
"try" (in which case why not use the multiple value return method) or
the reasoning about correctness starts to get more and more
complicated.

>> BTW, have you come across Icon?
>
> I have, and it's a fascinating language.
>
>> It takes an intriguing approach
>> where every operation succeeds or fails as well as having a value.
>
> I have heard Icon characterized as saying "it tries to succeed",
> and I think that's a fair description. The idea of integrating
> a backtracking engine into the language semantics deserves more
> attention than I think it has been given, which is unfortunate.
>
>> This idea is heavily built upon to produce a very comfortable
>> scripting language.
>
> My experience with Icon is purely academic, which is to say I have
> read about it but never used it. I have more experience with
> Prolog, which is similar in some ways (notably backtracking) but of
> course very different in other ways.
>
> I'm intrigued by your comment that Icon makes a good scripting
> language. Maybe I don't understand what you think makes a good
> scripting language, or even what "scripting language" means.
> That subject is not topical in comp.lang.c, but I also peruse
> comp.lang.misc and comp.programming if you wouldn't mind
> continuing there. Also you are welcome to send me an email
> at this address if you would rather do that.

It was a careless remark with no significant meaning.

--
Ben.

Tim Rentsch:

> kI wrote some code not long ago to add a value to a set of
> values, where the set is represented using a recursive
> binary tree structure (like red-black trees, but a little
> different). Usually we may expect that a request to add a
> value would offer a value not already included in the set,
> but certainly it can happen that there is a call to add a
> value that is already included, in which case the top
> level return value should be the original tree structure.

Returning an error flag (or code) all the way up the call
stack may seem (and be) slow and cumbersome. If that case,
one can rewrite the recursive function iteratively, with an
explicit stack. I, however, think that an extra `if' in the
recursive function is so much less fuss

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>> [..how should errors be handled..]
>>
>>> How would you prefer these sorts of thing to be signalled?
>>
>> Let me give just one example.
>>
>> I wrote some code not long ago to add a value to a set of values,
>> where the set is represented using a recursive binary tree structure
>> (like red-black trees, but a little different). Usually we may
>> expect that a request to add a value would offer a value not already
>> included in the set, but certainly it can happen that there is a
>> call to add a value that is already included, in which case the top
>> level return value should be the original tree structure.
>>
>> I thought it would be easier to write a simple recursive routine
>> that assumes the to-be-added value is not yet included in the set,
>> and if that assumption is violated raise an exception that is caught
>> at the outermost level and simply returns the original argument tree
>> value. Certainly the code could have been written to handle the
>> already-present situation at each level of the recursion, but it was
>> much easier and much cleaner to handle it by raising an exception.
>
> This is one of those cases where I just have to take your word for it,
> (and I am happy to do that).

Responding here to just this one part.

Here is a simpler version of the code, for an ordinary
binary tree, and without any rebalancing:

module TreeSet = struct
type 'a treeset = Empty | Node of 'a treeset * 'a * 'a treeset
exception Present

let add tree element =
let rec add t e =
match t with
| Empty -> Node( Empty, e, Empty )
| Node( a, v, b ) ->
if e < v then Node( add a e, v, b ) else
if e > v then Node( a, v, add b e ) else
raise Present
in
try add tree element with Present -> tree

end

Transliterating that into C, the central functions might look like
this (I have left out the type definition and the constructor
function used to build a new node value):

static Tree add( jmp_buf, Tree, double );
static Tree raise_present( jmp_buf );
static Tree new_node( Tree, double, Tree );

Tree
add_element( Tree tree, double new_element ){
jmp_buf jb;
if( setjmp( jb ) ) return tree;

return add( jb, tree, new_element );
}

Tree
add( jmp_buf jb, Tree t, double d ){
return
! t ? new_node( 0, d, 0 )
: d < t->v ? new_node( add( jb, t->a, d ), t->v, t->b )
: d > t->v ? new_node( t->a, t->v, add( jb, t->b, d ) )
: /*********/ raise_present( jb );
}

Tree
raise_present( jmp_buf jb ){
longjmp( jb, 1 );
}

Of course it's unlikely that sets would be implemented this way
in C, but that's not the point; the point is that exceptions
can result in code that is cleaner and easier to understand
than an alternate approach where return values would have to
be checked at every level.

(Incidentally, I want to acknowlege you comment about taking my
word for the result. I still thought it would be good to give
a concrete example, even if it is a very simplified one.)