On Thu, Sep 15, 2011 at 12:38 PM, 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. > Indeed. Not having ^-return means closures wouldn't need a home. In VisualWorks this is at the heart of the full/non-full block distinction. Full blocks have a home context, non-full (copying & clean) blocks don't have a home. So instantiating copying blocks is quicker since it doesn't involve instantiating the block's enclosing context. You'll see in my closure implementation that I took a short-cut and just ate the cost of instantiating the enclosing context (outerContext) to avoid having a) to implement the analysis in the compiler and b) to keep the number of bytecodes down). In a later image format/bytecode format I could revisit that decision. In particular, BlockClosure needs separate method and receiver inst vars so that it can be activated independently. Right now the value[:value:*] primitives fetch method and receiver from outerContext. But look, once the new object representation/GC is finished everything will be significantly faster anyway. So I wouldn't worry too much about this. Right now things are simple; we have only one kind of block, and performance in some cases is slightly sub-optimal. That's an acceptable price for now, no? 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. > Well, one can't remove upward fiunarg support without removing ^-return. But one can implement downward funargs in a number of ways, so this isn't the only issue. > > > > > > Stef > > > > for Q1 I see > > > > foo > > x isZero ifTrue: [^ 33]. > > self continue > > > > > > > > -- > > best, > > Eliot > > > > > -- best, Eliot
