Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.misc Subject: Re: Re: Mea culpa (was: Re: Re: Algol68 (and standards diatribe)) Message-ID: Date: 17 May 91 08:02:15 GMT References: <1991Mar28.011025.16337@ico.isc.com> <2400047@otter.hpl.hp.com> <1991May10.162820.2662@maths.nott.ac.uk> kers@hplb.hpl.hp.com (Chris Dollin) writes: >Dr A. N. Walker responds to Steve Knight: [much deleted] > If you want your procedure to > work, you mustn't tell the computer to throw away "x" first! But this > seems to be what Steve wants. Or have I misunderstood something? > >This is what Steve wants; he *hasn't* told the computer to throw anything > away. Yes he has! >Just because x would go out of (lexical) scope need not mean that its >store has to be reclaimed. From time immemorial, whatever the equivalent of BEGIN REAL x; ... END is in your favourite Algol-based language has meant something like start a new stack frame, allocate some *local* space for a real variable identified by "x", ..., deallocate the space and close the frame. We have a difference of opinion here. *I'd* say that the (equivalent of) the above code means ``once you hit END, I no longer wish to be able to use the name "x" to refer to ... er ... whatever it did refer to (ie, the variable, or the location, or the value, etc)''. The stuff about stack frames is just an implementation technique which works very well so long as you can't export some sort of reference to (the item named by) x - as was the case in Algol 60, but not in Algol 68. We can argue about what languages are ``Algol-based'', and quite when ``time immemorial'' started and finished, but above description does not apply to ML, or PAL, or SASL (or KRC, or Miranda), or Scheme, or Common Lisp. Dr. Walker continues (quoting me again): >Isn't the latter (weakness of A68 functional composition) just a > consequence of the former (can't export a procedure outside the scope of > one of its free variables)? Arguably, but I don't think so. Composition is a reasonable thing to want, but using a variable out of scope isn't. (Note: "scope" in Algol is a technical term, and differs from "range", which seems to be what some contributors mean by "lexical scope".) Reasonable wants shouldn't be satisfied in unreasonable ways. Yes, it occured to me that there was a terminological problem, and that Algol68 (for some arcane reason) used ``scope'' to mean what was usually called ``extent'' if it was called anything, and then had to introduce a new word to mean what ``scope'' meant. (Clearly, you *cannot* use something that's gone ``out of scope'' in the Algol68 sense - it ain't there. But I think the other contributors mean ``lexical scope'', aka ``range'', by scope. Certainly that's what Steve means [the observant reader will note that we post from the same site, and in fact we regularly discuss issues such as this, so I have a fair idea of what he means!]. It is true if you try to write composition in the obvious way the result has a uselessly narrow scope. The partial parametrisation proposals [see Algol Bulletin #37, p24] get around this without putting unreasonable loads on the implementation, but within the spirit of the scope rules. This possibility shows that composition weaknesses aren't a necessary consequence of tight scope rules. If you can implement partial parameterisation, you can implement full lexcial scope (ie, indefinite scope for locals used in exported procedures) using it. [Proof by example: that's how Poplog Pop11 does lexical closures.] Hence there's no reason not to make (eg) composition have full Algol68-scope if you have partial parameterisation. -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."