1.0 ?? [templates and currying]

[Kirk McDonald]

Walter Bright wrote:
> Tom S wrote:
>> Interesting ! :) Can it handle partial currying ?
> 
> I don't know.
> 
>> My Bind lib is also about function/delegate currying, with arbitrary 
>> partial currying, parameter swizzling and function composition. The 
>> only thing that it's currently lacking is support of 'out', 'inout' 
>> and 'lazy' parameters. But this cannot be done without more info from 
>> the compiler. Would it be hard on your side to add more meta-info for 
>> functions and delegates ? I'm sure many people would appreciate the 
>> ability to extract parameter types, their count and a return value 
>> type for functions and delegates. The current approach to obtain this 
>> kind of meta-info is well demonstrated in the 'meta' package of Pyd: 
>> http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/meta
> 
> You are way, way ahead of me with this stuff. Wow!
> 
> BTW, I am considering changing the ==function and ==delegate is 
> expressions, which you use, to the following:
> 
> 
> ==return gets the return type:
> 
>> template Return(dg)
>> {
>>     static if (is(dg R == return))
>>     alias R Return;
>>     else
>>     static assert(0, "argument has no return type");
>> }
> 
> ==function or ==delegate gets the parameter types as a tuple:
> 
>> template Parameters(dg)
>> {
>>     static if (is(dg P == function))
>>     alias P Parameters;
>>     else static if (is(dg P == delegate))
>>     alias P Parameters;
>>     else static if (is(dg P == P*))
>>     alias Parameters!(P) Parameters;
>>     else
>>     static assert(0, "argument has no parameters");
>> }
> 
> This will require some adjustment in your code. I didn't think anyone 
> was using that stuff. Will it be an issue for you? Or should I find 
> another way to do it?

This would be great! The one thing we lose is the ability to get the 
underlying function type of a delegate. If you were to also add some 
mechanism to freely convert a function type to a delegate type and vice 
versa, that would be perfect.

The other thing that would be nice is the ability to derive the storage 
classes of a function's arguments (in/out/inout/lazy). That linked-to 
code only works with functions that only have 'in' arguments. (With some 
limited inout support I added to deal with opApply.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org