Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!Mike_Spreitzer.PARC@xerox.com
From: Mike_Spreitzer.PARC@xerox.com
Newsgroups: comp.lang.modula3
Subject: Re: Closures in m3
Message-ID: <91Feb21.152416pst.16910@alpha.xerox.com>
Date: 21 Feb 91 23:23:27 GMT
Lines: 21
In-Reply-To: "<9102191802.AA29918@cs.Princeton.EDU>"
To: nr@princeton.edu
X-Ns-Transport-Id: 0000AA005D3913BF2B6C
Cc: Mike_Spreitzer.PARC@xerox.com, m3

[A mailer claimed this didn't make it to M3 the first try...]

You are right about the first point: local procedures can't escape (given M3 as
it is).  So the closure scheme is more convenient in some cases.  It's less
convenient in others (where the local procedure would work, making the local
procedure involves less overhead than making a whole closure object).  Wouldn't
the local procedure scheme suffice in the vast majority of actual uses?  Note
that if there
were a syntax for objection creation that allowed method literals, the closure
scheme can also approach the elegance of CLU iterators.

In clarification of my comment about assigning local procedures, I meant that I
don't see why it isn't equally as possible as dereferencing UNTRACED references
--- that is, something that you can do in an unsafe module when you know the
referenced locations (whether on the stack or in the heap) are still being used
as you expect.  I was not proposing this as a way to change the fact that local
procedures can't escape.  To do that would require changes that I expect the
language designers will say are too pervasive, expensive, difficult to
implement, or some combination thereof.

Mike