> 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. > 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 >
