Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch 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: <871q42qy33.fsf@bsb.me.uk> <87ed82p28y.fsf@bsb.me.uk> <87r0c1nzjj.fsf@bsb.me.uk> <87ikxconq4.fsf@bsb.me.uk> <20240711115418.00001cdf@yahoo.com> <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 writes: > Tim Rentsch writes: > >> Michael S writes: >> >>> On Fri, 12 Jul 2024 13:12:53 +0200 >>> Janis Papanagnou 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.