Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!strath-cs!nott-cs!piaggio!anw From: anw@maths.nott.ac.uk (Dr A. N. Walker) Newsgroups: comp.lang.misc Subject: Re: Re: Algol68 (and standards diatribe) Message-ID: <1991May15.181833.19502@maths.nott.ac.uk> Date: 15 May 91 18:18:33 GMT References: <1991Mar28.011025.16337@ico.isc.com> <2400047@otter.hpl.hp.com> <1991May10.162820.2662@maths.nott.ac.uk> Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker) Organization: Maths Dept., Nott'm Univ., UK. Lines: 68 In article 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. You don't *have* to throw away the space [and a common optimisation, in suitable cases, is to move the space to an outer range and economise on frames], but you can't rely on the space still being usable. Whether local variables *should* mean this is a proper subject for debate, but not the subject that was being debated. Note that Algol, Pascal, C etc also have ways of allocating space that is *not* local. You can debate whether local or heap should be the default, but not that local space shouldn't be "thrown away". >I had this vague recollection that [globals] wouldn't work in Algol68; you can >give x global scope, but theres some intrinsic local required to refer to it, Right, as I acknowledged in my article yesterday. >Which languages were you thinking of that ``do not have scoped variables''? None in particular [sorry!]. >That's true (but it's still a restriction, not a "restriction"). The restriction was not the "restriction" that Steve thought, hence the quotes. >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. 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. -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk