higher-order funcs for ranges (with usual interface)

2011-02-02 Thread spir
Hello, This bit of code for arrays: Out[] map (In,Out) (In[] input, Out delegate (In) f) { Out[] output = new Out[](input.length); foreach (i,item ; input) output [i] = f(item); return output; } unittest { char character (uint code) {return cast(char)code;} uint[] cod

Re: higher-order funcs for ranges (with usual interface)

2011-02-02 Thread Lars T. Kyllingstad
On Wed, 02 Feb 2011 13:26:39 +0100, spir wrote: > Hello, > > This bit of code for arrays: > > Out[] map (In,Out) (In[] input, Out delegate (In) f) { > Out[] output = new Out[](input.length); foreach (i,item ; input) > output [i] = f(item); > return output; > } > unittest { >

Re: higher-order funcs for ranges (with usual interface)

2011-02-02 Thread Lars T. Kyllingstad
On Wed, 02 Feb 2011 13:18:07 +, Lars T. Kyllingstad wrote: > [...] > > struct Map(Range, In, Out) > if (isInputRange!Range && is(ElementType!Range : In) > { > Range input; > Out delegate(In) f; > > @property bool empty() { return input.empty; } > > // Ineff

Re: higher-order funcs for ranges (with usual interface)

2011-02-02 Thread spir
On 02/02/2011 02:18 PM, Lars T. Kyllingstad wrote: On Wed, 02 Feb 2011 13:26:39 +0100, spir wrote: Hello, This bit of code for arrays: Out[] map (In,Out) (In[] input, Out delegate (In) f) { Out[] output = new Out[](input.length); foreach (i,item ; input) output [i] = f(item);

Re: higher-order funcs for ranges (with usual interface)

2011-02-02 Thread Lars T. Kyllingstad
On Wed, 02 Feb 2011 18:38:02 +0100, spir wrote: > On 02/02/2011 02:18 PM, Lars T. Kyllingstad wrote: >> On Wed, 02 Feb 2011 13:26:39 +0100, spir wrote: >> >>> Hello, >>> >>> This bit of code for arrays: >>> >>> Out[] map (In,Out) (In[] input, Out delegate (In) f) { >>> Out[] output = new Out

Re: higher-order funcs for ranges (with usual interface)

2011-02-03 Thread spir
On 02/03/2011 08:41 AM, Lars T. Kyllingstad wrote: On Wed, 02 Feb 2011 18:38:02 +0100, spir wrote: I guess the only solution would be for the compiler to support a kind of reange type syntax? I'm not sure I understand what you mean here. Perhaps you're looking for something like concepts, w

Re: higher-order funcs for ranges (with usual interface)

2011-02-03 Thread Lars T. Kyllingstad
On Thu, 03 Feb 2011 13:05:00 +0100, spir wrote: > On 02/03/2011 08:41 AM, Lars T. Kyllingstad wrote: >> On Wed, 02 Feb 2011 18:38:02 +0100, spir wrote: > >>> I guess the only solution would be for the compiler to support a kind >>> of reange type syntax? >> >> I'm not sure I understand what you m

Re: higher-order funcs for ranges (with usual interface)

2011-02-03 Thread spir
On 02/03/2011 01:17 PM, Lars T. Kyllingstad wrote: Why the reluctance to use template constraints? They're so flexible! :) I cannot stand the "is()" idiom/syntax ;-) Dunno why. Would happily get rid of it in favor of type-classes (built eg as an extension to current interfaces). For instance

Re: higher-order funcs for ranges (with usual interface)

2011-02-03 Thread Lars T. Kyllingstad
On Thu, 03 Feb 2011 13:53:44 +0100, spir wrote: > On 02/03/2011 01:17 PM, Lars T. Kyllingstad wrote: >> Why the reluctance to use template constraints? They're so flexible! >> :) > > I cannot stand the "is()" idiom/syntax ;-) Dunno why. Would happily get > rid of it in favor of type-classes (bui

Re: higher-order funcs for ranges (with usual interface)

2011-02-03 Thread spir
On 02/03/2011 02:25 PM, Lars T. Kyllingstad wrote: On Thu, 03 Feb 2011 13:53:44 +0100, spir wrote: On 02/03/2011 01:17 PM, Lars T. Kyllingstad wrote: Why the reluctance to use template constraints? They're so flexible! :) I cannot stand the "is()" idiom/syntax ;-) Dunno why. Would happily g

Re: higher-order funcs for ranges (with usual interface)

2011-02-07 Thread Lars T. Kyllingstad
On Thu, 03 Feb 2011 19:11:04 +0100, spir wrote: > On 02/03/2011 02:25 PM, Lars T. Kyllingstad wrote: >> On Thu, 03 Feb 2011 13:53:44 +0100, spir wrote: >> >>> On 02/03/2011 01:17 PM, Lars T. Kyllingstad wrote: Why the reluctance to use template constraints? They're so flexible! :) >>> >

Re: higher-order funcs for ranges (with usual interface)

2011-02-07 Thread spir
On 02/07/2011 09:18 AM, Lars T. Kyllingstad wrote: I cannot stand the "is()" idiom/syntax ;-) Dunno why. Would happily >>> get rid of it in favor of type-classes (built eg as an extension to >>> current interfaces). For instance, instead of: >>> >>> void func (T) (T t) >>> i

Re: higher-order funcs for ranges (with usual interface)

2011-02-07 Thread Torarin
If you want to use an interface as a concept, you can take kenji's adaptTo module and add this: template conformsTo(T, Interfaces...) { enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T; } and use it like this void draw(T)(T shape) if (conformsTo!(T, Shape, Drawable)) This will of cour

Re: higher-order funcs for ranges (with usual interface)

2011-02-07 Thread spir
On 02/07/2011 01:07 PM, Torarin wrote: If you want to use an interface as a concept, you can take kenji's adaptTo module and add this: template conformsTo(T, Interfaces...) { enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T; } and use it like this void draw(T)(T shape) if (conformsT