Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #388421
| 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> |
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 | Next — Previous in thread | Find similar
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