[bitc-dev] Current thoughts on mixfix
naasking at higherlogics.com
Sat Sep 4 07:15:41 PDT 2010
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  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
More information about the bitc-dev