On 2010-09-02 2:23 PM, Jonathan S. Shapiro wrote: > *First-Class Syntax* > > The evident /problem/ with my view is that you sometimes (lexically) > inherit operator bindings or precedence choices that don't work for your > specialized embedded language, and there isn't really a way to get rid > of them. It seems to me that the right solution here is to introduce a > notion of a "syntax table", so that you can write something like: > > with syntax /mySyntax/ > /sequence of forms/ > > The interpretation of a mixfix introduction is that it modifies the > current, lexically-prevailing syntax.
The Katahdin language [1] has fully customizable runtime syntax and semantics. IIRC, the Master's thesis deals with proper scoping and such to tame this powerful feature. If any language has addressed this problem, it's Katahdin. Regarding FEXPR, there have been a number of good debates on LtU [2,3,4], with the Kernel language being a modern FEXPR incarnation that does not suffer from the traditional FEXPR problems. Thomas Lord in particular has been championing the idea that Scheme do away with the distinction between macros and lambdas by simply using a restricted form of FEXPR which effectively unifies both. As for the implicit thunks for deriving control forms, I used to think it was a great idea, but now I'm sort of ambivalent to it, probably because it hasn't really materialized in any form that I'd use, and programming without it is fine. I'm sure it would be nice to simplify the language by requiring fewer primitives, but it might require some more powerful analysis to ensure all such applied thunks are properly inlined to achieve the optimal code you'd want. With the right set of guarantees, I could see it being a great feature. Sandro [1] http://lambda-the-ultimate.org/node/2303 [2] http://lambda-the-ultimate.org/node/3845#comment-57329 [3] http://lambda-the-ultimate.org/node/3640 [4] http://lambda-the-ultimate.org/node/3861 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
