On 15 September 2011 20:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
As Lukas says, not if one has exceptions. Â But Smalltalk-80 V2 didn't have exceptions, and so needed ^-return.
Yes this is really what I was thinking too.
Personally I find ^-return elegant and a vital part of the language's simplicity.
I agree but I wanted to really understand it because lars is not a fool.
 If ^-return is not allowed in blocks then blocks are special-cases, must be explained, and avoided in certain cases, etc.  Getting rid of it pushes the language in a more traditional convenient-for-the-language-implementor direction that I think is a serious mistake.  Language should serve the author/reader, *not* the implementor.
In my question came when I realized stupidly that "home" or the stuff to jump (to a context) was a context and not a compiled method. Because we need to jump to an activation and not just a bytecode holder. So I tried to understand the jumping behavior implication.
In fact my real question was would not having ^-return in [] change the closure implementation and in particular implementation of home. Would home be required to return a context and if needed. I guess not. I should look at home senders.
When I coded a simple (probably too simple) scheme/lisp interpreter, closures were trivial (got an alist chained to nested environment) and it was it. Now I was trying to understand (this is why I'm looking at the block implementation) is the next question: if removing ^- was leading to a  if removing ^- was like removing upward funargs.
Now I implemented call/cc in a probably bad ways (CSP) so fast versions probably introduces context too. since this is just copying the activation stack and jumping to it.
Do you mean CPS/continuation passing style? I've been thinking about how to do CPS on Smalltalk, these past few weeks, precisely for (delimited) continuations. I'd like to contrast the technique with my current implementation, using exceptions. How are you finding it? Delimited continuations are superior to call/cc at any rate: it's trivial to express call/cc in terms of delimited continuations (wrap your entire process in a prompt and you're done), but the converse isn't true. You can fake delimited continuations a la call/cc + mutable cell, but it's messier. Also, undelimited continuations can't be treated like functions, and can't compose. Oleg Kiselyov's written a fair about the issue, and continuations in general: * http://lambda-the-ultimate.org/node/4313 * http://okmij.org/ftp/continuations/undelimited.html * http://lambda-the-ultimate.org/node/86 * http://okmij.org/ftp/continuations/index.html frank
Q1 When are they absolutely required? Q2 What replacing mechanisms would be needed? Q3 What would we gain from an implementation stand point?
Some simplicity, certainly. Â But (IMO) ^-return isn't as complex as method lookup and message cacheing so you're not reducing complexity overall.
It seems that in resilience lars removed them and more.
Yes, IIRC he got rid of first-class blocks. Â They can only be downward funargs (passed as parameters), not upward funargs (stored in inst vars, returned as results and hence used after their enclosing activation has returned).
Yes exactly. So I wanted to know if removing ^- was like removing upward funargs.
Stef
for Q1 I see
foo     x isZero ifTrue: [^ 33].     self continue
-- best, Eliot