Tomek S.:
> You're right. Still, modularity is a valid point.
This is a general and interesting design topic. The short answer is that a real
language is designed taking into account different trade-offs.
Modularity is important, and Andrei surely likes it. Modularity means the
ability to comb
Dnia 25-10-2010 o 21:20:24 Tomek Sowiński napisał(a):
(Map, Filter, Reduce)
reduce is of course not a range ;)
--
Tomek
Dnia 25-10-2010 o 08:42:31 KennyTM~ napisał(a):
On Oct 25, 10 14:04, Andrei Alexandrescu wrote:
This is coming full circle. At a point, map _did_ support multiple
ranges. Some people found that non-modular - if you want multiple
ranges, you should use map with zip...
Except that at "that poi
On 10/25/10 1:42 CDT, KennyTM~ wrote:
On Oct 25, 10 14:04, Andrei Alexandrescu wrote:
This is coming full circle. At a point, map _did_ support multiple
ranges. Some people found that non-modular - if you want multiple
ranges, you should use map with zip...
Except that at "that point"[1], map'
On Oct 25, 10 14:04, Andrei Alexandrescu wrote:
This is coming full circle. At a point, map _did_ support multiple
ranges. Some people found that non-modular - if you want multiple
ranges, you should use map with zip...
Except that at "that point"[1], map's multi-range support is equivalent to
On 10/24/10 14:55 CDT, Simen kjaeraas wrote:
On Sun, 24 Oct 2010 21:39:24 +0200, bearophile
wrote:
Tomek S.:
map!((a) {return myNaryFun(a._0, a._1, ...); })(zip(range1, range2,
...));
Currently the docs of std.algorithm.map say:
Multiple functions can be passed to map. In that case, the
Simen kjaeraas:
> From what I can see, map currently simply doesn't support passing it
> multiple ranges. It would be a trivial change to let it support multiple
> ranges in addition to multiple functions.
If you may have multiple of both then the situation becomes complex. So I think
that sing
Dnia 24-10-2010 o 21:34:54 Philippe Sigaud
napisał(a):
That's what Haskell calls ZipWith. I called it tmap (as in tuple-map)
when I needed it in D.
IMHO, it should be a generalization of std.algorithm.map: let it
accept n ranges and a n-ary function. It can even do a partial check
at compile-
On Sun, 24 Oct 2010 21:39:24 +0200, bearophile
wrote:
Tomek S.:
map!((a) {return myNaryFun(a._0, a._1, ...); })(zip(range1, range2,
...));
Currently the docs of std.algorithm.map say:
Multiple functions can be passed to map. In that case, the element type
of map is a tuple containing
Tomek S.:
> map!((a) {return myNaryFun(a._0, a._1, ...); })(zip(range1, range2, ...));
Currently the docs of std.algorithm.map say:
>Multiple functions can be passed to map. In that case, the element type of map
> is a tuple containing one element for each function.<
But lot of time ago I have
2010/10/24 Tomek Sowiński :
> I have noticed an emerging idiom in my code lately: bring together n ranges,
> transform them to one range using a n-ary function. Currently it's achieved
> with:
>
> map!((a) {return myNaryFun(a._0, a._1, ...); })(zip(range1, range2, ...));
>
> It's a bit of a nuisans
I have noticed an emerging idiom in my code lately: bring together n
ranges, transform them to one range using a n-ary function. Currently it's
achieved with:
map!((a) {return myNaryFun(a._0, a._1, ...); })(zip(range1, range2, ...));
It's a bit of a nuisanse -- rarely do my transforming func
12 matches
Mail list logo
