Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!purdue!decwrl!labrea!sri-unix!garth!phipps
From: phipps@garth.UUCP (Clay Phipps)
Newsgroups: comp.lang.misc
Subject: Re: aGREeable features (was Re: Algol-68 down for the count)
Keywords: Algol-60,call-by-name
Message-ID: <2130@garth.UUCP>
Date: 6 Dec 88 08:41:12 GMT
References: <406@ubbpc.UUCP> <3688@hubcap.UUCP> <2070@garth.UUCP> <796@quintus.UUCP>
Reply-To: phipps@garth.UUCP (Clay Phipps)
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 116

In article <796@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <2070@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes:
>>The fact that a language feature is enough of a challenge to understanding
>>that it can be used as the basis of a test question is "evidence" to me
>>that the feature may be more of a liability than an asset.
                   ^^^
>Yeah!  Let's get rid of assignment statements!
>Better not forget procedures, too.		1/2 (:-)

The word "may" was carefully selected to express *possibility*,
*not certainty*.  The original posting gave me the impression 
that its contributor believed that the basing of test questions
on a particular language feature identified that feature as an asset.
[If my impression is incorrect, I'm certain that the contributor will
tell me.]  I believe that such a conclusion is not only unwarranted, 
but *may* be wrong.  It does not necessarily mean that the feature
is a liability, but the feature might indeed be a liability.

Under a heading: "Design Weaknesses", Naur [78] identified
"the call by name concept" as one of 5 "areas of difficulty
... identified, but left for resolution at a later stage".
The others: side effects of functions, _own_ as static or dynamic, 
_for_ statement as static or dynamic, and
the conflict between specification and declaration.
Some, I think, are problems with imprecision in their definition, 
not necessarily questions of their merit as features.
These were not resolved in the Algol 60 Revised Report in 1962.

>>My recollection is that call-by-name was included in Algol 60
>>to simplify implementation of some numerical analysis algorithm
>>like the Runge-Kutta[sp?] or Newton-Raphson (these are *not* my field),
>>yet it was made the default parameter transmission method.
>Completely bogus.  
 ^^^^^^^^^^
Call by name *is* the default parameter mechanism.
It is interesting that the Algol 60 Committee, in the final hour
of the final day of the final Algol 60 conference, in Paris,
voted that the "treatment of each parameter in the call 
is controlled by a name-part in the heading that lists those
parameters whose names should be substituted.  For all other
parameters, the value of the actual parameter is used as an
initialization" [Naur 78].  In other words, the Committee voted to 
make call by value the default.  Acting as editor of the report, 
Naur later wrote to the Committee: "a few matters of detail have been 
filled in and changed.  Thus, ... the listing of name in the procedure 
heading has been replaced by ... the complimentary set, value".
Naur "did arbitrarily change the outcome of the Conference:" [but] 
"it was to be swallowed for the sake of loyalty", wrote Bauer [78].

A Runge-Kutta program is presented as the final example
in the "Revised report on the algorithmic language ALGOL 60",
which acknowledges that "this RK-program contains some new ideas
which are frelated to ideas of S. Gill ... and C.E. Fr:oberg.
This may be the reason that Runge-Kutta came so readily to mind.
I could find nothing to support or refute my claim about its influence.

>You may be thinking of a neat hack called
>"Jensen's device" which in effect gave you lambda-expressions: ...

Bauer contends that "straightforward introduction of procedure
parameters (and of the Lambda-Calculus), as it was advocated
by the minority" [hence, voted down] "would have outflanked some 
of the ambiguities that made the Rome "[1962" revision necessary".
I will leave it to O'Keefe to argue the point with Bauer (if living).
I'm not an expert on lambda-anything.

>Nope.  The origin of pass-by-name semantics is explained very clearly
>                  in the Algol-60 report.                                  
            ^^^^^^                                             ^^^^^^^
Nope to you.  In many ways, the Algol 60 Report and its Revision are 
models of elegance and *clarity*, but nowhere does the Revised Report
(and, I would bet, the 1960 Report) explain the *origins* of anything.
I take "origin" to be synonymous with "rationale" (for Ada fans).

>After a few examples ..., pass-by-name becomes very simple to grasp.  

Indeed it does, but I had grasped call by name years before your tutorial.

>The *consequences* of pass-by-name are another matter, ...

The *consequences* are among the things that must be considered
in judging the merit of a feature like call by name.

>...but precisely the same objections can be raised against aliasing.

The point is that it is a matter of making the right engineering
trade-offs.  Or, at least, good enough ones (if you're Wirth, 
you can just do whatever you want).  The trade-offs must consider
the people who will be doing the programming, and their expected tasks.
E.g., for certain programming tasks undertaken by certain programmers, 
especially down near the machine level, the benefits from 
explicit pointers and implicit pointers 
(e.g., parameter passing by reference) outweigh the risks.
I don't doubt that there are some tasks and some programmers
for whom call by name is appropriate, but it ain't for everybody,
especially as a default.

Wirth, for what it's w*rth (-:, retained call by name in Algol-W 
[1966], but eliminated call by value for arrays.

See Peter Naur: "The European side of the last phase of the 
development of Algol 60", _Preprints: ACM SIGPLan History of 
Programming Languages Conference_, _SIGPLan Notices_, v. 13 n. 8,
August 1978.  Comments by F.L. Bauer, J.H. Wegstein, M. Woodger,
appear as appendices.  See esp. p. 29, 30, 41.  A. Perlis also
contributed a paper.  Available, further elaborated, in book form.

There is a paper by R.W. Bemer: "A Politico-Social History of Algol",
_Annual Review in Automatic Programming 5_, p. 151..238,
Pergamon Press, 1969, that is supposed to be fascinating.
I haven't seen it, but Perlis [78] recommends it.

-- 
[The foregoing may or may not represent the position, if any, of my employer]
 
Clay Phipps                       {ingr,pyramid,sri-unix!hplabs}!garth!phipps