DeRailed DSL (was Re: compile-time regex redux)

[Bill Baxter]

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
> 
> There is a deeper connection between runtime reflection and compile-time 
> reflection than it might appear.
> 
> In the runtime reflection scenario, the compiler must generate, for each 
> user-defined type, an amount of boilerplate code that allows symbolic 
> inspection from the outside, and code execution from the outside with, 
> say, untyped (or dynamically-typed) arguments.
> 
> The key point is that the code is *boilerplate* and as such its 
> production can be confined to a code generation task, which would keep 
> the compiler simple. The availability of compile-time introspection 
> effectively enables implementation of run-time introspection in a library.
> 
> For example:
> 
> class Widget
> {
>   ... data ...
>   ... methods ...
> }
> 
> mixin Manifest!(Widget);
> 
> If compile-time introspection is available, the Manifest template can 
> generate full-blown run-time introspection code for Widget, with stubs 
> for dynamic invocation, the whole nine yards.
> 
> This is nicer than leaving the task to the compiler because it relieves 
> the compiler writer from being the bottleneck.
> 
> 
> Andrei
> 

Well there you go then.  Sounds a lot like the serialization problem too.

     mixin Serializer!(Widget);

Or the problem of exposing classes to scripting languages.

     mixin ScriptBinding!(Widget);

Speaking of which I'm surprised Kirk hasn't piped in here more about how 
this could make life easier for PyD (or not if that's the case).  Any 
thoughts, Kirk?  You're in one of the best positions to say what's a 
bottleneck with the current state of compile-time reflection.

--bb