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

Groups > comp.lang.c > #388527

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

Show all headers | View raw

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

> 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:

[...]

>>>>>> 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.
>
> How?  All I see is that you've used the word "call" rather than
> "pass" in each instance -- and in each instance, I find "pass"
> clearer (except perhaps in the case of "call by name", for reasons
> I won't go into for the moment).
>
>> 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.
>
> I honestly do not understand the argument you're making in favor of
> "call by" over "pass by".  ("Hoi polloi"?  Seriously?)
>
> Procedures and functions are "called", yes?  They're not "passed",
> except perhaps as an argument to another procedure or function.
>
> Arguments to procedures and functions are "passed", yes?  Would it
> make sense to say that an argument is "called"?  (I note that the
> Algol 60 report never refers to parameters being "called" other than
> in the phrases "call by value" and "call by name".)
>
> If you think that "calling an argument" or "calling a parameter"
> makes sense, perhaps that's the root of the disagreement.  Do you?
>
> In most languages that supports by both by-value and by-reference
> mechanisms, a single call can have one by-value argument and one
> by-reference argument, or any other combination.  Using C++ as a
> convenient example:
>
>     void func(int by_value, int& by_reference) { /* ... */ }
>     int x, y;
>     func(x, y);
>
> In the third line, there is just one call, but two arguments,
> corresponding to two parameters.  It's not the call that's by-value
> or by-reference, it's each argument that's *passed* (using the
> mechanism specified on the parameter).
>
> Other than historical precedent from Algol and friends, why do you
> think it's better to use "call by value" and "call by reference"
> rather than "pass by value" and "pass by reference", when the
> mechanism applies individually to each argument, not to the call as
> a whole?
>
> Do you object to using the word "pass" (without "by ...") to refer
> to the arguments to a function?  If not, why do you object to "pass
> by ..."  to refer to the mechanism?

After reading your message I spent several hours thinking about how
to answer before starting to write a reply.  I ask that you take a
commensurate amount of time considering my comments before composing
any followup.

I think it's fair to say we are looking at this question from
different perspectives.  I see where you're coming from;  I get
why you're saying what you say.  For the other direction my guess
is that my perspective either isn't apparent or isn't one that
makes sense to you.  Let me see if I can shed some light on that.

The "call by" in Algol 60 is used to characterize /parameters/ of
a function definition.  It's important that "call" is used in the
active voice;  parameters are not "called".  The word "call" has
changed in meaning since its use in the Algol 60 report, so let's
consider some plausible alternatives (always in the active voice):

   associate by
   elaborate by
   expand by
   instantiate by
   substitute by

For an example, let's suppose we have a by-name parameter (and for
now let's use the "associate by" phrasing).  Writing in a made-up
C-like language that allows different parameter modalities, we
could write

   void
   by_name_example( unsigned by_name i, double by_name v ){
      for(  i = 0;  i < 100;  i++  )  v = 1. / ((i+1)*(i+1));
   }

and a call

   unsigned foo;
   double terms[100];

   by_name_example( foo, terms[foo] );

In calling by_name_example(), we associate argument 'foo' with
parameter 'i', and associate argument 'terms[foo]' with 'v'.
The associations are done by-name of course, because of how
the two parameters are declared.

Some history could be helpful here.  In the Algol 60 report,
function calls were explained, or defined, as a kind of textual
substitution.  In effect the body of a function definition would
be substituted for the call.  (The original description uses a
different phrasing but the effect is the same.)  Because of that
the phrasing "call by" makes sense:  arguments for different kinds
of parameters are expanded or substituted differently.  The
meanings of the different parameter modes were explained in terms
of the abstract semantics, and not in terms of how they might be
implemented.  Indeed, when the Algol 60 report was first published
it wasn't yet understood how to implement call by name.  (Or
perhaps it was discovered just slightly before publication, I'm
not sure of the exact timing.)

Here is an example function with a call by reference parameter:

   void
   accumulate( unsigned v, unsigned by_reference total ){
      total += v;
   }

Now let's consider some calls:

   unsigned long foo = 0;
   accumulate( 3, 0 );
   accumulate( 5, foo );

Are these calls legal or not legal?  (Either answer is possible.)
This illustrates the point that it isn't so important /what/ is
conveyed as it is /how/ the call is done.  Saying these are "pass
by reference" emphasizes /what kind of information/ is conveyed
but downplays the more important aspect of /how an argument is
associated with the parameter/.

A different example, with a FORTRAN-style parameter mode (which is
call by value-result, aka call by copy in/copy out):

   int
   exchange( unsigned by_in_out x, unsigned by_in_out y ){
      unsigned a = x, b = y;
      x = b, y = a;
      /* ... some other stuff ... */
   }

This function exchanges its arguments, and also does some other
stuff.  However, it's important that updating of the arguments
happens only when the function returns;  if "other stuff" makes
use of the arguments (not by way of the parameters x and y but via
some other path), it will see the original values of those
arguments, not the values assigned on the second line of the
function.  Any call by value-result parameters changes not only
what happens at the call but also what happens at the return;
using "pass by" is not evocative of that meaning.

Suppose we modify the exchange function slightly:

   int
   exchange_two( unsigned by_in_out x, unsigned by_in_out y ){
      unsigned a = x, b = y;
      x = b, y = a;
      if(  something  )  longjmp( some_jmp_buff, 23 );
   }

If the longjmp() is done, are the arguments corresponding to the
parameters x and y updated or not?  (Either answer is possible.)
Here again "pass by" emphasizes what kind of information is
conveyed, now how the call (and return, and possibly the longjump)
is done.  A by value-result parameter affects the semantics of
/calling/ a function, and so "call by value-result" is more
suggestive of what is going on than "pass by value-result".

Not all programming languages are procedural.  "Pass by" tacitly
assumes a procedural semantics for function calls:  it's passive
rather than active, and suggests only conveying of data (and not
doing anything else).  Programs written in Prolog do something
very different when they call a "function" (Prolog calls them
something else but operationally it resembles a function call).
In Prolog the semantics of how arguments are associated with
parameters is referred to as "call by unification";  how arguments
interact with the function definition is deeply intertwined with
how "function" calls work in Prolog.  "Pass by" doesn't begin to
capture what is going on with how arguments interact with the
bodies of "functions" in Prolog;  among other things, parameters
are not necessarily independent, and arguments can't always be
considered only individually (which is not the case for call by
value, call by reference, and call by name).

Saying "pass by" sort of works okay for parameters that are
by-value or by-reference.  It doesn't work as well for "by name"
parameters (certainly it is not a name that is being passed), and
really falls down for call by value-result, let alone what happens
with call by unification.  Parameters are call-by because they can
affect how the function is called, both going in and going out.
Call-by shows an abstract semantics perspective rather than an
implementation perspective, and because of that applies more
universally than pass-by, which doesn't make sense outside of
a certain limited procedural context.

I guess I'll stop here.  I've made a fairly substantial effort to
convey my perspective, but I'm not sure the effort will succeed.
So let me ask this:  how would you describe my perspective, and
how would you say it's different from yours?  Or has reading my
explanation allowed you to view the question from a different
perspective?

Back to comp.lang.c | Previous | Next — Previous in thread | Next 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