Magnus Lie Hetland <magnus@hetland.org> wrote:

> Sort of related (though perhaps only remotely) is the following, which won't compile (Error: static assert "Bad unary function: f(a) for type int"):

Not related. unaryFun and binaryFun are simply glorified string mixins,
and thus can only access functions that are available in the modules
where they are mixed in. That would be std.functional. Because of that,
local functions may not be used as string arguments for *naryFun.

-- 
Simen

On 2011-02-01 16:00:16 +0100, Magnus Lie Hetland said:

>   import std.functional, std.stdio;
>   int f(int x) {return x;}
>   void main() {
>       alias unaryFun!("f(a)") g;
>       writeln(g(3));
>   }

Just to be clear -- I realize I could just have used unaryFun!f here (or just f, for that matter). The usage case was actually currying. I used "f(x,a)" as a compile-time argument to the kind of template that we discussed earlier. And the reason I tried that was that this didn't work either:

 import std.functional, std.stdio;
 int f(int x, int y) {return x;}
 void main() {
     alias unaryFun!(curry(f, 2)) g;
     writeln(g(3));
 }

At that point, the only thing that worked was using a lambda. And, as I pointed out, with the nested templates, that didn't work either.

Seems like the language (or the stdlib) is resisting my efforts at every turn here. Perhaps I should just write out those for-loops redundantly, rather than using templates ;)

-- 
Magnus Lie Hetland
http://hetland.org

On 2011-02-01 16:09:22 +0100, Simen kjaeraas said:

> Magnus Lie Hetland <magnus@hetland.org> wrote:
> 
>> Sort of related (though perhaps only remotely) is the following, which won't compile (Error: static assert "Bad unary function: f(a) for type int"):
> 
> Not related. unaryFun and binaryFun are simply glorified string mixins,
> and thus can only access functions that are available in the modules
> where they are mixed in. That would be std.functional. Because of that,
> local functions may not be used as string arguments for *naryFun.

That certainly makes sense. I just got thrown off by the example in std.algorithm:

 uint hashFun(string) { ... expensive computation ... }
 string[] array = ...;
 // Sort strings by hash, slow
 sort!("hashFun(a) < hashFun(b)")(array);

The only way this could work would be if hashFun was available to the sort template, I guess...?

-- 
Magnus Lie Hetland
http://hetland.org

Magnus Lie Hetland <magnus@hetland.org> wrote:

> On 2011-02-01 16:09:22 +0100, Simen kjaeraas said:
>
>> Magnus Lie Hetland <magnus@hetland.org> wrote:
>>
>>> Sort of related (though perhaps only remotely) is the following, which won't compile (Error: static assert "Bad unary function: f(a) for type int"):
>>  Not related. unaryFun and binaryFun are simply glorified string mixins,
>> and thus can only access functions that are available in the modules
>> where they are mixed in. That would be std.functional. Because of that,
>> local functions may not be used as string arguments for *naryFun.
>
> That certainly makes sense. I just got thrown off by the example in std.algorithm:
>
>   uint hashFun(string) { ... expensive computation ... }
>   string[] array = ...;
>   // Sort strings by hash, slow
>   sort!("hashFun(a) < hashFun(b)")(array);
>
> The only way this could work would be if hashFun was available to the sort template, I guess...?

Nope, still std.functional. That's where the string is mixin'ed.

But thanks for noting that, I've filed it as issue #5513.


-- 
Simen

On 2011-02-01 16:41:33 +0100, Simen kjaeraas said:

>> That certainly makes sense. I just got thrown off by the example in std.algorithm:
>> 
>> uint hashFun(string) { ... expensive computation ... }
>> string[] array = ...;
>> // Sort strings by hash, slow
>> sort!("hashFun(a) < hashFun(b)")(array);
>> 
>> The only way this could work would be if hashFun was available to the sort template, I guess...?
> 
> Nope, still std.functional. That's where the string is mixin'ed.

Right. Given the example, there's no way to tell that sort is implemented using std.functional, so really meant whichever function is actually using the string ;) But, yeah, I understand how it works. Thanks.

> But thanks for noting that, I've filed it as issue #5513.

Good.

-- 
Magnus Lie Hetland
http://hetland.org