Ben: This is a very useful pointer, and I'll read what LippMeier has to say, but in general terms I don't think that adding implicit thunkification changes anything from an effects standpoint.
The reason is simple: At any point where the language introduces implicit thunkification, we could have written the same program explicitly using lambda forms, and we know how to do type-and-effect for that. At the moment, it appears to me that all of the thunk injection can be done cleanly, using purely syntactic transforms, before the type checker even runs. So I think it's just sugar. You also wrote: On Fri, Sep 3, 2010 at 10:29 PM, Ben Karel <[email protected]> wrote: > On the other hand, for a language that's supposed to have a transparent > mapping to the machine level, it's not immediately clear that giving > indistinguishable syntax to such semantically different operations is a good > idea. Mark Miller was making the same point, and went further to observe that lightweight lambdas (which go back to Smalltalk) make explicit syntax much more palatable. He also noted that if the only use cases are AND/OR/IF-THEN-ELSE, then this isn't sufficient to justify new mechanism in the language. And I agreed. But then I read Pitman's paper, and it reminded me of the many other uses for thunkification that people have found useful in LISP. And I started digging in to mixfix, and that brought my attention to the fact that FEXPRs like these are right smack in the middle of the expression hierarchy, and play a more central rule than people want to admit. And there is certainly something attractive about reducing the core language... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
