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

[Kirk McDonald]

Walter Bright wrote:
> Kirk McDonald wrote:
>> Never mind what this actually does. The problem at hand is somehow 
>> generating a class like this at compile-time, possibly given only the 
>> class Foo.
> 
> Tell me exactly what you need.

Given a class, I need a way to get a list of all of its member functions 
at compile-time. One might naively think a tuple of aliases to the 
class's member functions would do, except that this does not provide 
enough information in the case of overloaded functions. In other words:

class Foo {
     void foo() {}
     void bar() {}
     void bar(int i) {}
}

The mechanism I suggest would get us this tuple:

methodtuple!(Foo) => Tuple!(Foo.foo, Foo.bar);

(Particularly, I do not think this tuple should include inherited methods.)

However, there is no way to distinguish the two forms of bar at 
compile-time. Currently, this is only enough information to get the 
first form with the empty parameter list, since it is lexically first.

This turns out to be a more general problem, which I will now recast in 
terms of global functions.

void foo() {}
void foo(int i) {}
void foo(char[] s) {}

The second mechanism needed would give us a tuple of the function types 
shared by this symbol:

functiontuple!(foo) => Tuple!(void function(), void function(int), void 
function(char[]))

functiontuple!(Foo.bar) => Tuple!(void function(), void function(int))

The third thing needed is the ability to detect function parameter 
storage classes, as you have discussed on this NG in the past.

Fourth is some way of detecting whether a function has default 
arguments, and how many it has. This can be done with templates (as 
std.bind shows), but direct language support would be a great deal cleaner.

Fifth is actually satisfied in a way by the new mixins. This is the 
ability to call an alias of a member function on an instance of the 
class or struct. This is very much like C++ pointers to member 
functions, with the difference that it happens entirely at compile-time. 
(Meaning that type mismatches, viz. trying to call a method of one class 
on an instance of another, can be detected.) I am not sure what the 
syntax for this should be, however. And, as I said, the new mixins can 
handle it, when combined with Don Clugston's nameof.

The first three are absolutely necessary. The other two can be done with 
templates in current D, and would merely be nice.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org