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

[Andrei Alexandrescu (See Website For Email)]

Bill Baxter wrote:
> 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);

Yes, that is being discussed a little in the announce group. One nice 
thing (barring potential balkanization) is that you can invent various 
serialization engines supporting different formats. The point is that 
it's the programmer, not the compiler writer, deciding that.

One difference between serialization and run-time reflection is that you 
may decide to serialize only the subset of an object, so you may want to 
provide specific indications to the Serializer template (a la "don't 
serialize this guy", or "only serialize these guys" etc):

mixin Serializer!(Widget, "exclude(x, y, foo, bar)");

> Or the problem of exposing classes to scripting languages.
> 
>     mixin ScriptBinding!(Widget);

And probably the first scripting engine to be supported would be 
DMDScript...

> 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.

...or PyD. :o)


Andrei