When is a closure a real one? [was: Real closures]

Philippe Marschall philippe.marschall at gmail.com
Sun Oct 8 15:30:03 UTC 2006


The problem is not non-local returns but block arguments/temps. Squeak
just makes method temps out of them.

Philippe

2006/10/8, J J <azreal1977 at hotmail.com>:
> I am not familiar enough with those calls to say 100%, but when I say "real
> closures", what I mean are closures that can be returned from a function and
> used without fear.  In other words, what other languages that have closures
> do.
>
> Now I relize the "return to home context" (i.e. ^) is not compatible with
> this, but that's ok.  This ability is unique to smalltalk as far as I know
> and treating it different would be fine (e.g. if a ^ is seen then turn the
> block into the cheaper BlockContext since it can't be returned from a method
> anyway).
>
> Or for that matter if the speed problem is too hard to fix right now, then
> maybe a simple change in the compiler to make a block into a BlockClosure if
> it gets returned?  Obviously most of you know a lot more about this then me.
>   Just throwing some things out there.
>
>
> >From: "Klaus D. Witzel" <klaus.witzel at cobss.com>
> >Reply-To: The general-purpose Squeak developers
> >list<squeak-dev at lists.squeakfoundation.org>
> >To: squeak-dev at lists.squeakfoundation.org
> >Subject: When is a closure a real one? [was: Real closures]
> >Date: Sun, 08 Oct 2006 10:51:25 +0200
> >
> >Thank you Mathieu and Phillipe for you pointers and example.
> >
> >Just out of curiosity (and as input for writing accurate yes/no test cases
> >:) let me ask what is expected by the community (apologies if this sounds
> >like a silly question ;-) when is a closure a real one:
> >
> >1] after #fixTemps (or equivalent)
> >
> >2] after #blockCopy: (is this equivalent to 1?)
> >
> >3] after #createBlock: (is this equivalent to 1? to 2?)
> >
> >4] <put: your requirements: or thoughts: here>
> >
> >Thank you for your time!
> >
> >/Klaus
> >
> >
>
>
>
>



More information about the Squeak-dev mailing list