Re: Jensen's device

"Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
3 Apr 1998 17:07:18 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: Jensen's device wclodius@aol.com (1998-03-30)
Re: Jensen's device genew@vip.net (1998-03-30)
Re: Jensen's device mslamm@olive.mscc.huji.ac.il (1998-03-30)
Re: Jensen's device u-reddy@cs.uiuc.edu (Uday S. Reddy) (1998-03-30)
Re: Jensen's device Andrew.Walker@nottingham.ac.uk (Dr A. N. Walker) (1998-04-03)
Re: Jensen's device jmccarty@sun1307.spd.dsccc.com (1998-04-03)
Re: Jensen's device ok@atlas.otago.ac.nz (Dr Richard A. O'Keefe) (1998-04-03)
Re: Jensen's device rweaver@ix.netcom.com (1998-04-03)
| List of all articles for this month |

From: "Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Newsgroups: comp.compilers
Date: 3 Apr 1998 17:07:18 -0500
Organization: Department of Computer Science, University of Otago
References: 98-03-193 98-03-259
Keywords: algol60

Uday S. Reddy wrote:
> I don't think this was a mistake in the sense that the committee
> wanted to write one thing and wrote another. Every indication is that
> the committee deliberately chose call-by-name.


The Algol 60 designers have stated in print that when they designed
the "copy rule" (the description of how procedure call worked) they
*thought* they were specifying pass by reference, and that Jensen's
device was an unexpected but welcome consequence. The fact that you
cannot define a 'swap' procedure in Algol 60 was an unexpected and
*un*welcome consequence. Exercise for the reader: just what _is_
wrong with
procedure swap(x, y);
real x, y;
begin real t; t := x; x := y; y := t end;
Hint: consider arrays indexed by procedure calls...


Do bear in mind that as soon as the Algol people got a chance to fix
the mistake (in the design of Algol 68) they took it eagerly (but
stuck enough automatic coercions like 'proceduring' to make the
sensible uses of Jensen's device _look_ pretty much the same).


> On the other hand, this might have been a "mistake" in the sense
> that not all design implications of call-by-name were understood
> when the report was written (especially the implementation hassles,
> efficiency considerations etc.)


Algol 60 implementation work proceeded fairly rapidly. By today's
standards, the implementation hassles of pass by name are extremely
minor. There are some extremely nasty things about the copy rule,
however, such as the interactions with (= sabotage of) static type
checking. Just consider the fact that you can't specify how many
subscripts a formal array parameter wants.


> (Algol 68 tried to do it too, but their descriptions are too
> complicated for mere mortals to understand.)


A canard. The revised Algol 68 report restructured the formal
specification to make it much easier to read, and in any case, you
_could_ learn the language from the report without actually reading
the two-level grammar. As for clean specifications, the Scheme R5RS
is very much in the spirit (even the format!) of the Algol 60 report,
and is smaller and stabler than the ML spec.


> A second issue the committee must have faced is to find a uniform
> mechanism for parameter passing that applies to all kinds of
> parameters. Call-by-reference is something that applies to variable
> parameters. But, what about, say procedure parameters? Is there
> such a thing called a "reference" to a procedure?


According to Algol 68, there is. In any case, I think even the
biggest fan of Algol 60 would agree that procedure parameters are one
of that language's biggest botches.


> P.S. Call by name in functional programming, often called lazy
> evaluation, is very much alive in real languages (such as Miranda and
> Haskell).


Ah, no. Lazy evaluation is call by NEED, not call by NAME.
For example,
      real procedure foo(x) real x; foo := (x+1)/(x-1);
      ... foo(big expensive computation()) ...
will evaluate big expensive computation() TWICE, while
      foo x = (x+1)/(x-1)
      ... foo (big_expensive_computation)
will evaluate big_expensive_computation ONCE.


The statistics programming language S, from AT&T, combines lazy
evaluation with imperative programming. A nightmare.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.