Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!markf From: markf@zurich.ai.mit.edu (Mark Friedman) Newsgroups: comp.lang.misc Subject: Re: Algol68 (and standards diatribe) Message-ID: Date: 3 May 91 15:03:54 GMT References: <1991Mar28.011025.16337@ico.isc.com> <2400046@otter.hpl.hp.com> Sender: news@ai.mit.edu Reply-To: markf@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 40 In-reply-to: sfk@otter.hpl.hp.com's message of 1 May 91 10:16:07 GMT In article <2400046@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes: I wrote in an earlier message (amongst other topics) about the omission of full lexical binding from Algol 68, comparing the Algol68 policy with that of languages such as Lisp and Standard ML. Charles comments: Yes, but all these languages pay a high run-time > overhead for the facility. I'd like to understand this claim. From my perspective, as a programmer in 1991, the implementation of lexical binding only involves a cost in two circumstances. ... The second situation is relevant. In the case where a procedure is not returned as a result but the compiler is unable to deduce this (without inter-procedural reasoning) there is an associated cost. What's the associated cost? An example would typically be uses of "maplist" which maps a procedure of type A -> B across a list of type list(A) to produce a result of type list(B). When "maplist" is used, the compiler may not know enough about maplist to 'realise' that the lexical variables captured by the procedure can be implemented cheaply. How would it matter if the compiler could figure out that "maplist" doesn't return a procedure? I don't see anything about "maplist" that would allow lexical variables captured by its procedure argument to be implemented cheaply. -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu