View mode: basic / threaded / horizontal-split · Log in · Help
February 01, 2011
Re: Partially instantiating templates?
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
February 01, 2011
Re: Partially instantiating templates?
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
February 01, 2011
Re: Partially instantiating templates?
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
February 01, 2011
Re: Partially instantiating templates?
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
February 01, 2011
Re: Partially instantiating templates?
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
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home