On 15 September 2011 20:38, Stéphane Ducasse <[email protected]> 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 >> > > >
