phipps@garth.UUCP (Clay Phipps) (12/01/88)
In article <3688@hubcap.UUCP> steve@ragman writes: >From article <406@ubbpc.UUCP>, by wgh@ubbpc.UUCP (William G. Hutchison): >> Algol-60 success-1 failure-2 small group >The impact of Algol-60 on the follow[ing] designs is considerable. Indeed it is, and on its own merits. However, ... >The fact that call by name is still considered a valid question >on the advanced CS part of the GRE is some evidence. 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. I was "brought up" to believe that programming languages should be designed to simplify and assist construction of correct programs. I suspect that there are few features that effectively confuse students on tests that contribute to the goal of constructing correct programs. 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. I don't recall the subject algorithm being terribly difficult without call-by-name in FORTRAN. Funny thing about how call-by-name hasn't shown up in any other mainstream language, including [not being supported in] Algol-68. Is it possible that the hassles of implementing call-by-name and teaching what it does have led language designers to conclude that "'t'ain't worth it" ? >Clemson University, Clemson, SC 29634-1906 At the U. of Maryland, call-by-name tended to be the basis for a test question in the Survey Of Programming Languages course (CMSC 330?), typically a junior-year course for undergraduate Computer Science majors. There was no GRE at the time. -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps
ok@quintus.uucp (Richard A. O'Keefe) (12/02/88)
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 (:-) >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. You may be thinking of a neat hack called "Jensen's device" which in effect gave you lambda-expressions: real procedure sum(l, u, i, x); value l, u; integer l, u, i; real x; begin real s; s := 0.0; for i := l step 1 until u do s := s + x; sum := s end; ... real array a[1:N], b[1:N]; integer k; ... dot product := sum(1, N, k, a[k]*b[k]); Nope. The origin of pass-by-name semantics is explained very clearly in the Algol-60 report. It follows very naturally indeed from the "substitution" method used to explain procedure calls, which was meant to be like lambda calculus: first rename all the variables in the body of the procedure, then substitute the actual parameters for the formal parameters. Value parameters are hard to explain this way. In this case, what you get is begin integer I1, I2; real R1, R2; I1 := 1; I2 := N; R1 := 0.0; for k := I1 step 1 until I2 do R1 := R1 + a[k]*b[k]; R2 := R1; dot_product := R2 end; After a few examples like this, pass-by-name becomes very simple to grasp. The *consequences* of pass-by-name are another matter, but precisely the same objections can be raised against aliasing.
markv@uoregon.uoregon.edu (Mark VandeWettering) (12/04/88)
In article <2070@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >In article <3688@hubcap.UUCP> steve@ragman writes: >>From article <406@ubbpc.UUCP>, by wgh@ubbpc.UUCP (William G. Hutchison): >>The fact that call by name is still considered a valid question >>on the advanced CS part of the GRE is some evidence. Regardless of whether or not the use of call by name is desireable, examination of the problems inherent in call by name leads to a better understanding of how programming languages are implemented. >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. >I don't recall the subject algorithm being terribly difficult >without call-by-name in FORTRAN. Call by name can be elegant, but it interacts with side effects in odd ways. For instance, there is no way to swap two values in pass by name using assignment, to assure yourself try i and A[i].... >Funny thing about how call-by-name hasn't shown up in any other >mainstream language, including [not being supported in] Algol-68. >Is it possible that the hassles of implementing call-by-name and >teaching what it does have led language designers to conclude >that "'t'ain't worth it" ? Call by name is very difficult to implement *in languages with side effects* In functional languages, call by name can be effectively and efficiently implemented. Call by name is very popular, and has been refined into "lazy evaluation".... It is important to study all programming languages which has in some way molded the evolution of the field. Algol 68 certainly has done that, and I would think that it was worth examining as an intellectual exercise. Mark VandeWettering
phipps@garth.UUCP (Clay Phipps) (12/06/88)
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
ok@quintus.uucp (Richard A. O'Keefe) (12/07/88)
In article <2130@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >In article <796@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>In article <2070@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >>>My recollection is that call-by-name was included in Algol 60 >>>to simplify implementation of some numerical analysis algorithm >>Completely bogus. >Call by name *is* the default parameter mechanism. So it is. But it was not introduced to "simplify...some numerical analysis algorithm". That is the claim which I identified as bogus. >>You may be thinking of a neat hack called >>"Jensen's device" which in effect gave you lambda-expressions: ... >I will leave it to O'Keefe to argue the point with Bauer (if living). >I'm not an expert on lambda-anything. lambda-expression = anonymous procedure. That's all you need to understand. I didn't say that call-by-name _is_ lambda expressions, but that Jensen's device (if you would have called p(..., lambda(x,y,z)expr, ...) do instead p(..., x, y, z, expr, ...) ) gave you the _effect_ of lambda-expressions. >>Nope. The origin of pass-by-name semantics is explained very clearly >> in the Algol-60 report. By "origin" I meant not "rationale" (the rationale for pass-by-name is that Fortran provided pass-by-reference, and the Algol 60 designers -- some of the minutes of the Algol 60 committee were published years before the HOPL conference -- wanted Algol 60 procedures to be at least as powerful as Fortran ones, so something was needed in addition to value parameters) but "ground"/"cause"/&c. Pass-by-name comes *very* naturally out of the "copy rule", which is described in the Algol 60 report. (Pass by reference would not.) My recollection (which is doubtless as inaccurate as Phipps') is that the "copy rule" came first, and that the semantics of pass-by-name were a consequence of it. So the origin of pass-by-name, namely the copy rule for explaining how procedures work, is indeed described in the Algol 60 report. >>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. That is beside the point: the claim I was refuting was not "Phipps does not understand call-by-name" but "call-by-name is hard to understand". >>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. No-one is disputing that.
phipps@garth.UUCP (Clay Phipps) (12/08/88)
In article <820@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <2130@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >>In article <796@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>>In article <2070@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: [Text has been rearranged, but I have tried to avoid changing its meaning.] >>>The origin of pass-by-name semantics is explained very clearly >>> in the Algol-60 report. >By "origin" I meant not "rationale" ... but "ground"/"cause"/&c. >Pass-by-name comes *very* naturally out of the "copy rule", >which is described in the Algol 60 report. >So the origin of pass-by-name, namely the copy rule for explaining >how procedures work, is indeed described in the Algol 60 report. I wouldn't have chosen "origin", but I now see what you intended. I didn't point out that I certainly agreed that the Report contains the description of "call by name" because [1]: I was disagreeing about rationale, 2: it was late, 3: I forgot to make a clarification, 4: failure to respond to a point often is interpreted as agreement (in this case, about the presence of a definition of "call by name"), which would have been just fine under the circumstances. Incidentally, the term used by the Revised Report [1962] that I have is "call by name"[italicized]; was it called "pass-by-name" in the Algol 60 Report [1960] that you cite, or is it U.K. regional terminology ? I have been treating them as synonymous for this discussion. >>>>My recollection is that call-by-name was included in Algol 60 >>>>to simplify implementation of some numerical analysis algorithm >... the rationale for pass-by-name is that Fortran provided >pass-by-reference, and the Algol 60 designers wanted >Algol 60 procedures to be at least as powerful as Fortran ones, >so something was needed in addition to value parameters ... >My recollection (which is doubtless as inaccurate as Phipps') >is that the "copy rule" came first, >and that the semantics of pass-by-name were a consequence of it. >... [Pass-by-name] was not introduced >to "simplify...some numerical analysis algorithm". ... There is an interesting remark by Naur [HOPL] about the background that he brought to the development of Algol: "my work with the Edsac, Cambridge, England, in 1951 and 1953... had given me a strong impression of the importance of closed subroutines, including the use of what in retrospect may be described as parameters called by name". Naur cites a paper that he wrote in 1977; it is called "A vector handling subroutine using call by name written for EDSAC in 1951". Naturally, it was never published. There is also a summary by Naur of the "procedure statement" as defined by the Z:urich Report [1959]: "during the activation of the procedure, the formal parameters are replaced by the corresponding actual parameters, replacement being understood as symbol substitution". The former paragraph supports my "inaccurate" recollection, sort of; the latter supports yours, sort of. I *would* like to know whether there was a specific requirement for a solution to a particular problem, or if the committee just agreed upon a definition (the "copy rule") that they liked, satisfied that it was more "powerful" than FORTRAN. The definition could well have seemed at the time to be the same as for assembly language macro processing substitution. >-- some of the minutes of the Algol 60 committee were published years >before the HOPL conference ... The Perlis and Naur papers in the HOPL Conference preprints identified the 7 1959 issues of the _ALGOL Bulletin_ and CACM as containing discussions of proposals for developing Algol. I have not been in this field so long that I would have any of those in my possession :-), and I do not have easy access to them. Maybe I'll try to infiltrate a local but prominent university's computer science library (most likely, I'll never take the time to do so). Those efforts might not produce the evidence that I'm seeking, anyhow; the HOPL papers make it clear that much of the communication was informal. So -- which came first, the chicken or the egg ? Anyone out on the net have useful information, by virtue of being at Algol development meetings, from extensive contacts with people who were (be prepared to name names), or from written materials ? Feel free to start rumors that it will be a new question on the Computer Science GRE :-). -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps
ok@quintus.uucp (Richard A. O'Keefe) (12/09/88)
In article <2147@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >Incidentally, the term used by the Revised Report [1962] that I have >is "call by name"[italicized]; was it called "pass-by-name" in the >Algol 60 Report [1960] that you cite, or is it U.K. regional terminology ? >I have been treating them as synonymous for this discussion. I have no idea what the proper term is, take pass-by-name as idiolect. Looking in Michael Gordon's "The denotational description of programming languages", we find For us, _procedure calling_ is the processing of the actual parameter expressions to yield some (partially or fully) evaluated value, whereas _parameter passing_ is the further processing of this value to yield whatever is eventually bound to the formal parameter. ... It would, perhaps, have been better to have given the various parameter passing methods names such as "pass by value" or "pass by reference" and so have been able to use :call by" exclusively for calling methods -- however we defer to convention. and the next section is 8.5.1 Call by closure (Algol 60 call by name) which would suggest that the UK convention is "call by name". It is embarrassing to be caught out like this, and I beg the net's indulgence. (The BCPL manual speaks of "pass by value". What to do?)
jeff@aipna.ed.ac.uk (Jeff Dalton) (12/10/88)
In article <3289@uoregon.uoregon.edu> markv@drizzle.UUCP (Mark VandeWettering) writes: >In article <2070@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: > Call by name is very difficult to implement *in languages with > side effects* It's pretty easy in some languages with side effects. Scheme for example. And the Algol-60 "thunks" technique could be applied in other languages. (The idea is that each name parameter is represented by procedures called "thunks". There's one to get the value, and another to set it.) -- Jeff