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


Groups > comp.lang.c > #388421

Re: technology discussion → does the world need a "new" C ?

From Ben Bacarisse <ben@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: technology discussion → does the world need a "new" C ?
Date 2024-09-16 22:41 +0100
Organization A noiseless patient Spider
Message-ID <877cbbgttl.fsf@bsb.me.uk> (permalink)
References (16 earlier) <87sewesg89.fsf@nosuchdomain.example.com> <865xresvxz.fsf@linuxsc.com> <87h6ay3jaz.fsf@nosuchdomain.example.com> <87mskqtip3.fsf@bsb.me.uk> <8634m0ccjc.fsf@linuxsc.com>

Show all headers | View raw


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

> Ben Bacarisse <ben@bsb.me.uk> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>>>
>>>>>> On 2024-07-12, bart <bc@freeuk.com> wrote:
>>>>>>
>>>>>>> It's clearly not by value.  It's apparently not by reference.  You
>>>>>>> can't get away with saying they are not passed, as clearly
>>>>>>> functions *can* access array data via parameters.
>>>>>>
>>>>>> Actually, you probably can get away with saying that it is "passed
>>>>>> by reference".
>>>>>>
>>>>>> The formal term that doesn't apply is "call by reference";  that's
>>>>>> what C doesn't have.
>>>>>>
>>>>>> "call by reference" emphasizes that the function call mechanism
>>>>>> provides the reference semantics for a formal parameter, not that
>>>>>> some arbitrary means of passage of the data has reference
>>>>>> semantics.
>>>>>
>>>>> [...]
>>>>>
>>>>> I know that "call by reference" is the usual formal term, but I
>>>>> personally prefer "pass by reference".
>>>>>
>>>>> The terms "call by reference" and "call by value" emphasize the
>>>>> call, implying that all arguments in a given call are passed with
>>>>> the same mechanism.  In some languages that's true (C argument
>>>>> passing is purely by value, and Fortran, as I understand it, is
>>>>> purely by reference), but in others (C++, Pascal, Ada) you can
>>>>> select by-value or by-reference for each parameter.  "Pass by
>>>>> (reference|value)" feels more precise.
>>>>>
>>>>> I haven't checked, but I suspect the terms "call by (reference|value)"
>>>>> predate languages that allowed the mechanism to be specified for each
>>>>> parameter.
>>>>
>>>> I suspect that your guess here is influenced more by what you would
>>>> like to be true than what is likely to be true.
>>>
>>> I was influenced by what I thought made the most sense.
>>>
>>>> What is likely to be true is that these terms entered the language
>>>> at essentially the same time as the original Algol.  Algol 60 has
>>>> both call by name and call by value, referred to by those names in
>>>> the Algol 60 Report, and selectable on a per-parameter basis.
>>>>
>>>> By contrast the precursor to Algol 60, the International Algebraic
>>>> Language or IAL for short (and referred to after the fact as Algol
>>>> 58) did not use either term, and described the coupling between
>>>> arguments and parameters only in somewhat vague English prose that
>>>> left unclear exactly what the binding mechanism(s) were to be.
>>>> (There was a description for functions and a separate description
>>>> for procedures, not quite the same, and both not completely clear
>>>> exactly what the mechanism was meant to be.)
>>>>
>>>> Thus it seems likely that the terms call by name, call by value,
>>>> and perhaps other similar terms, first arose during the discussions
>>>> of the Algol 60 working group in the late 1950s, and entered the
>>>> general lexicon with or perhaps slightly before the publication of
>>>> the Algol 60 Report, which describes and allows both call by name
>>>> and call by value, selectable on a per-parameter base, and referred
>>>> to by those names in the published Algol 60 Report.
>>>
>>> Yes, that does seem likely.
>>>
>>> I'm mildly disappointed.  Since arguments are *passed* and
>>> functions/procedures are *called*, surely it would have made more sense
>>> to use "pass by value" rather than "call by value", especially in a
>>> language where the mechanism can vary per parameter.
>>
>> All that is, I think, due to subsequent changes in (English) language
>> use.  In Algol 60, procedures were invoked and /parameters/ were called
>> by value or name.  Maybe the term was intended to reflect the idea that
>> the code in the body "called for the value" of the parameter.
>>
>> The word "call" now refers, almost universally, to invoking a function
>> or procedure.  As a result, the idea of "calling a parameter" reads
>> oddly, but at the time I'm sure it seemed perfectly reasonable.
>
> This view simply doesn't match the language and phrasing used
> during the time Algol was being developed.  Both the Algol 60
> report and the preliminary IAL report (aka Algol 58) routinely
> use the word call in connection with outside use of a procedure.
> Algol 60 uses the word "invoke" exactly twice:  once in relation
> to procedures (where "call" is also used), and once in relation
> to functions.  Algol 58 uses the word call pretty much the same
> way that Algol 60 does, but doesn't use the word "invoke" at all;
> the verb "initiate" a procedure in Algol 58 turned into "invoke"
> a procedure in Algol 60.  Clearly using "call" was already well
> established in the late 1950s, and "invoke" came later.
>
> Algol 58 (loosely) defined the semantics of procedure call by
> textual expansion of the procedure body at the call site,
> substituting the text of actual parameters for each occurrence of
> the corresponding formal parameter in the procedure body.  The
> actual rules are more complicated, due to there being different
> "styles" (my word) of parameters, and because there were output
> parameters as well as input parameters.  Basically though the
> meaning was what would later be termed "call by name", with some
> restrictions on what forms of actual parameters were allowed.
>
> Algol 60 simplified the rules by reducing the number of cases to
> just two:  either the actual parameter was textually substituted
> for the formal parameter in the expansion (call by name), or the
> value of the actual parameter expression was in effect assigned
> to a local variable corresponding to the formal parameter (call
> by value), which did not have a corresponding case in Algol 58.
> The "call by" in "call by name" and "call by value" refers to how
> the expansion is done in elaborating the procedure call.  The
> "call by" is not what sort of thing is passed, but what action is
> taken in doing the substitution/expansion.
>
>>> (Yes, this is my opinion.)
>>>
>>> If there's some reason why "call by value" actually made more sense
>>> than "pass by value", I'm not aware of it.
>>>
>>> Since the phrase "pass by value" is now in common use, I'll
>>> continue to use that term in preference to "call by value"
>>> (likewise "by reference").
>>
>> I use those terms too.  It would be confusing these days to talk
>> about calling a parameter, and the phrase "call by value" suggests
>> (as it never did at the time) something so do with the function
>> calling mechanism in general.
>
> Yes it did.  It is only now that we have a different idea about
> how functions and procedures are called that it seems like it
> doesn't.  But in Algol 60 it certainly did have something to do
> with how a function reference was elaborated (aka called).
>
>> This is compounded by the fact that modern programming languages
>> has almost universally settled on calling all parameters by value
>> (to the use the old phrase) so, usually, the terms can, in fact,
>> be used to talk about the function calling mechanism.
>
> The rationale here seems circular to me, and also not an accurate
> picture of the programming language landscape.
>
> Passing a pointer by value is not the same as a call be reference.
>
> Passing a lambda by value is not the same as a call by name.
>
> Shortly after Algol 60, FORTRAN adopted call by value/result,
> also called call by copy in/copy out.  Ada has INOUT, does
> it not?
>
> Logic programming languages have call by unification.
>
> All of these cases show why "pass by" is not a good universal
> fit.
>
> At their lowest level, computers are simply slinging bits around.
> In some sense everything is done in terms of "values".  Thinking
> in terms of what "value" is "passed" serves to reinforce an
> imperative mind set, and there is already too much of that.  For
> these reasons and more I disdain the hoi polloi phrasing of "pass
> by" for distinguishing different parameter modalities.

Your disdain is noted, so I see no point in my making any technical
points.

-- 
Ben.

Back to comp.lang.c | Previous | NextPrevious in thread | Find similar


Thread

Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 18:09 -0700
  Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-01 19:01 -0700
    Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-09-02 12:10 +0100
      Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-02 15:18 -0700
        Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 06:04 +0200
      Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-15 23:56 -0700
        Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-16 03:37 -0700
          Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-16 18:15 +0200
            Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 06:15 -0700
              Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-17 19:07 +0200
                Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 12:52 -0700
          Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-26 09:37 -0700
            Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-26 21:28 -0700
              Wording discussion (was Re: technology discussion) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-27 14:21 +0200
                Re: Wording discussion (was Re: technology discussion) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-27 14:09 -0700
              Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-27 14:03 -0700
                Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-28 00:26 +0200
                Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-28 06:43 +0200
              Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-29 08:07 -0700
        Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-09-16 22:41 +0100

csiph-web