[Issue 4264] Various std.algorithm.map problems
http://d.puremagic.com/issues/show_bug.cgi?id=4264 David Simcha changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #6 from David Simcha 2010-08-21 19:41:25 PDT --- Since everything you mention except the opApply issue is fixed either in 2.048 or in SVN, and the discussion has moved beyond Map to std.algorithm/std.range in general, I've changed the name of this bug. I've thought about supporting opApply in some std.range and std.algorithm types. I think it's useful and conceptually feasible (ignoring implementation minutiae) for at least the following, and probably more: std.algorithm.map std.algorithm.filter std.algorithm.uniq std.algorithm.until std.range.chain std.range.retro (if your object defines opApplyReverse) std.range.stride std.range.cycle It's definitely not feasible for anything that requires random access or manipulating multiple ranges in lockstep. I also don't see how to do it for std.range.splitter -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4264] Various std.algorithm.map problems
http://d.puremagic.com/issues/show_bug.cgi?id=4264 --- Comment #5 from bearophile_h...@eml.cc 2010-07-17 08:40:57 PDT --- yebblies: > Ok, I see your point, but if map is going to work with opApply it will no > longer be able to provide the standard range interface. Yes, that's what I meant with giving as many capabilities as possible. > Either way this is an enhancement request and not a bug. Here there is a blurry line between bug and enhancement request. If map! doesn't work with opApply I have to write new versions of map, filter, etc, different from the standard ones. Missing one crucial functionality can be seen as a kind of bug. > map!func(structWithOpApply) would also no longer work with most of > std.algorithm without extensive (and maybe impossible) modifications. I am not asking for impossible changes. Just to make them work with what can work. Othrwise I have to reinvent the wheel in my code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4264] Various std.algorithm.map problems
http://d.puremagic.com/issues/show_bug.cgi?id=4264
--- Comment #4 from yebblies 2010-07-16 21:17:49 PDT ---
(In reply to comment #3)
>
> But this too doesn't work:
>
> import std.algorithm, std.conv, std.range;
> void main() {
> auto r1 = map!(to!(string, uint))(iota(20));
> }
>
>
> import std.algorithm, std.conv, std.range;
> void main() {
> auto r1 = map!(to!(string, int))(iota(20));
> }
>
You're right. But this is not a problem with map, I think this is bug337.
void t1(U = int)(int a)
{
}
void t1(U = int)()
{
}
void t2(U = int, T = int)(int a)
{
}
void t2(U = int, T = int)()
{
}
void main() {
t1!()(1); // works
t1!()(); // works
t1!(int)(1); // fails
t1!(int)(); // fails
t2!()(1); // works
t2!()(); // works
t2!(int)(1); // works
t2!(int)(); // works
t2!(int,int)(1); // fails
t2!(int,int)(); // fails
}
It can probably be worked around by combining the radix and non-radix form of
to!(string,int).
Maybe a separate bug?
> If you perform a map! on an iterable that has a length, then map! detects it
> at
> compile-time and offers a length attribute, otherwise it's not offered.
>
> So map! and other similar higher order functions can adapt and offer as much
> as
> possible.
>
> If the iterable given to map! has just an opApply, then map! can offer just an
> opApply, for an iteration that can't be resumed.
Ok, I see your point, but if map is going to work with opApply it will no
longer be able to provide the standard range interface.
Either way this is an enhancement request and not a bug.
map!func(structWithOpApply) would also no longer work with most of
std.algorithm without extensive (and maybe impossible) modifications.
> array() can work with anything that can be iterated by foreach.
Agreed.
array() is special in that it always evaluates the entire range immediately.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4264] Various std.algorithm.map problems
http://d.puremagic.com/issues/show_bug.cgi?id=4264
--- Comment #3 from bearophile_h...@eml.cc 2010-07-16 13:19:18 PDT ---
> The problem with the last example seems to be that the
> template arguments to 'to' are in the wrong order.
But this too doesn't work:
import std.algorithm, std.conv, std.range;
void main() {
auto r1 = map!(to!(string, uint))(iota(20));
}
import std.algorithm, std.conv, std.range;
void main() {
auto r1 = map!(to!(string, int))(iota(20));
}
--
> Also, how can the opApply example work with lazy iteration?
> As far as I know opApply does not provide any way to pause and resume
> iteration.
If you perform a map! on an iterable that has a length, then map! detects it at
compile-time and offers a length attribute, otherwise it's not offered.
So map! and other similar higher order functions can adapt and offer as much as
possible.
If the iterable given to map! has just an opApply, then map! can offer just an
opApply, for an iteration that can't be resumed.
--
> It would be possible on the other hand to allow array to work on
> anything that supplies opApply.
array() can work with anything that can be iterated by foreach.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4264] Various std.algorithm.map problems
http://d.puremagic.com/issues/show_bug.cgi?id=4264 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies 2010-07-16 07:49:34 PDT --- The problem with the last example seems to be that the template arguments to 'to' are in the wrong order. Also, how can the opApply example work with lazy iteration? As far as I know opApply does not provide any way to pause and resume iteration. It would be possible on the other hand to allow array to work on anything that supplies opApply. eg. // s defines opApply map!func(array(s)) // no lazy iteration // but not array(map!func(s)) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4264] Various std.algorithm.map problems
http://d.puremagic.com/issues/show_bug.cgi?id=4264
--- Comment #1 from bearophile_h...@eml.cc 2010-07-15 16:24:16 PDT ---
Another case, I don't know the cause of the problem:
import std.algorithm, std.conv, std.range;
void main() {
auto r1 = map!(to!(int, string))(iota(20));
}
dmd v2.047 prints:
...\dmd\src\phobos\std\algorithm.d(115): Error: function
std.conv.to!(int,string).to (string value) is not callable using argument types
(uint)
...\dmd\src\phobos\std\algorithm.d(115): Error: cannot implicitly convert
expression (0u) of type uint to string
If I replace int with uint:
import std.algorithm, std.conv, std.range;
void main() {
auto r1 = map!(to!(uint, string))(iota(20));
}
...\dmd\src\phobos\std\algorithm.d(115): Error: function
std.conv.to!(uint,string).to (string value) is not callable using argument
types (uint)
...\dmd\src\phobos\std\algorithm.d(115): Error: cannot implicitly convert
expression (0u) of type uint to string
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
