Path: ...!news.mixmin.net!eternal-september.org!feeder3.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: technology discussion =?utf-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Wed, 17 Jul 2024 01:09:48 -0700
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <86le205tir.fsf@linuxsc.com>
References: <v66eci$2qeee$1@dont-email.me> <v6joi4$1epoj$1@dont-email.me> <871q42qy33.fsf@bsb.me.uk> <v6k6i0$1h4d3$1@dont-email.me> <87ed82p28y.fsf@bsb.me.uk> <v6m03l$1tf05$1@dont-email.me> <87r0c1nzjj.fsf@bsb.me.uk> <v6m716$1urj4$1@dont-email.me> <87ikxconq4.fsf@bsb.me.uk> <v6n8iu$24af0$1@dont-email.me> <20240711115418.00001cdf@yahoo.com> <v6oamt$2d8nn$1@dont-email.me> <v6oct4$2djgq$2@dont-email.me> <v6of96$2ekb0$1@dont-email.me> <v6ovfc$2hcpf$1@dont-email.me> <v6p4hf$2icph$1@dont-email.me> <v6qgpu$2t6p7$3@dont-email.me> <v6r33m$30grj$1@dont-email.me> <20240712154252.00005c2f@yahoo.com> <86o7717jj1.fsf@linuxsc.com> <87msmljwqx.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 17 Jul 2024 10:09:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3670327c1da6279f75fc57abea437cce";
	logging-data="1851327"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18HXBOjG2sv/mG/3xw5eUokx8zQmywG1wk="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:FYYdZFJFJ3GRezSquM/mhJAOztw=
	sha1:oqNCPBcQvEQyXfUHB4/u6UhTLoE=
Bytes: 6955

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Fri, 12 Jul 2024 13:12:53 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>
>>>> But maybe he has looked up some things, since lately he's squirming
>>>> by introducing terms like "_true_ pass-by-reference" [emphasis by me]
>>>> obviously trying to bend the semantics of the established technical
>>>> "pass-by-reference" term to fit his argument.  (Introducing new terms
>>>> for existing mechanisms or bending semantics of existing terms with
>>>> well established meaning is certainly not helpful in any way.)
>>>>
>>>> But, yes, that person is a phenomenon.
>>>
>>> I don't share your optimistic belief that the term "pass by reference"
>>> is really established.  Very few terms in computer science (science?
>>> really?) are established firmly.  Except, may be, in more theoretical
>>> branches of it.
>>
>> The terms
>>
>>    call by name
>>    call by value
>>    call by reference
>>    call by value-result
>>
>> are all well-defined and firmly established, going back more than
>> 60 years.  I learned all of these in standard early course in
>> computer science sometime in the early 1970s.  Of course I can't
>> be sure about the source after all these years, but I expect
>> they were defined in the textbook we were using in the class.
>>
>> Much later, probably under the influence of people learning
>> by reading blogs rather than books, some of these terms were
>> expressed as, eg, "pass by value" or "pass by reference".
>
> I think it's reasonable to assume that this change of term was partly
> motivated simply by the meaning of the words.  Call by value (to pick
> one) is an odd term to use about a parameter and/or argument.  The
> function or procedure is called, but the arguments are passed and
> subsequently accessed.  Nowadays, sentences like "Specifications of
> parameters called by value must be supplied" just feel a bit strange, at
> least to me.

I partly agree with you, but only partly.

It seems likely that terms such as "pass by value" were introduced
by someone, or someones, who thought those terms were more
descriptive than the original terms such as "call by value".

But I think it's wrong to conclude that "pass by value" is a better
choice than call by value, etc, because it focuses on what is going
on in the implementation rather than what is meant in the abstract
semantics.

Under call by reference, for example, there are implications not
just for what information is conveyed but also how the variable is
used within the body of the function in question.  Looking at an
assignment 'x := 3;' has a very different meaning if the variable x
is a call-by-value parameter than if x is a call-by-name parameter
(and different again if x is a call-by-reference parameter).  And I
think it's worth remembering that when the term "call by name" was
introduced it wasn't really understood how to implement it.

Also consider the evaluation mode call-by-value-result.  Here there
is a difference in what information is conveyed to the function, and
also a difference in the meaning of a use of the variable within the
function body, but also a difference in what happens when a function
return is done.  It's more important to understand the semantics of
the parameter mode than it is to know the details of how the
semantics are accomplished.

Of course I agree that the example sentence "Specifications of
parameters called by value must be supplied" sounds a bit off, but
that's because it is misusing language, treating the word "call" as
a verb rather than as an inseparable part of a compound adjective.
Written more grammatically as "Specifications of call-by-value
parameters must be supplied", the sentence sounds just fine.  Or
maybe better, "Any call-by-value parameters must be identified as
such."  But either way, choosing a compound adjective form of
expression appropriately ties the evaluation mode to the function
parameter, and not to unimportant details of an implementation.

> Had I been CS King, I would have promulgated the terms "accessed by
> value", "accessed by name" and so on since it's the access method that
> really what matters to my mind.

I have two objections.  One is that it's too local.  Two is that
it's too specific.  (Also I don't like that there is an implied verb
phrasing rather than a compound adjective phrasing.)  Too local:
there is a tacit assumption that all accesses are the same, whereas
they may not be.  Example: a lazy parameter that is evaluated on
first use, then simply copies the previously computed value on
subsequent uses.  Moreover the half-lazy argument might already have
been evaluated before the function is called.  Too specific: access
suggests an imperative environment, but there are other kinds of
environments.  In logic programming a typical parameter mode is call
by unification;  if instead it were referred to as "accessed by
unification" that would sound odd.  Ideally we would have a phrasing
that makes sense for all different sorts of parameter evaluation
methods, and not just a few that have been used historically in
imperative languages.