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

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?