http://d.puremagic.com/issues/show_bug.cgi?id=5691


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #10 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-03-04 05:44:27 PST ---
Couldn't walkLength simply be redefined to accept an isIterable argument?  That covers ranges, opApply, and properly formed delegates.

And to answer Jonathan, opApply has very important features that ranges do not.
 First and foremost, it can use the stack for iteration.  This allows things
like indexed iteration, iterating trees, and efficient iterating via a virtual
interface.

Second, ranges do not yet allow more than one item while iterating.  I can't do:

foreach(i, x; r)

on a range.

Not saying opApply is better in all cases, ranges do have just as important features, but opApply is more useful in certain important situations.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5691



--- Comment #11 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-03-04 07:41:35 PST ---
I agree that opApply has advantages over ranges. I'd also argue it lacks the level of control that would make it a useful abstraction. If we allow walkLength to work with isIterable, we really need to review all algorithms to see if they could also work with isIterable, and possibly adjust a number of them to use foreach. It's not impossible there might be some forking on static if (isIterable!...).

Such an effort would be significant and might increase the size and complexity of std.algorithm. At this point in Phobos' design I think it's worth acknowledging that we can't accommodate every design in the book and we need to keep a watchful eye on complexity. (For example I am very seriously thinking of assuming cheap constructors, which would remove all the moveFront etc. functions).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5691



--- Comment #12 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-03-04 08:13:08 PST ---
I agree that we don't want to cater to all styles, at the expense of added complexity.  I think actually, using isIterable, does not increase complexity immensely for walkLength.  It covers the same ground as isInputRange, but with the added bonus of allowing any foreachable structure.

One thing to note is, you cannot convert opApply (or similar) constructs into ranges.  This means that any function/construct in std.algorithm or std.range that yields a range cannot be used on a generic isIterable type.  For example, map yields a range, so it cannot accept opApply type arguments.

In addition, any function which operates on multiple aggregates could not take opApply-based args because you can't iterate them in parallel easily.  This eliminates quite a few functions.

However, any functions that operate on the *whole* set of values from a range should be easily tweaked to also accept isIterable.

For example, reduce, some forms of count, isSorted, etc. should be possible on any foreachable construct.

I think we may find that a) the number of functions which can also accept isIterable types is pretty small and b) adding the ability to support opApply-based aggregates is not complex.

It definitely needs more analysis before judging whether it makes sense.  I agree that if you do walkLength, you should do all the functions that make sense.

BTW, I just noticed that count(r) is identical to walkLength(r).  Any reason
for the duplication?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5691



--- Comment #13 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-03-04 08:35:41 PST ---
walkLength would need forking for opApply, so already for this first example we're looking at an increase in complexity. This is because walkLength against a range doesn't need to invoke front, so it uses a straight for loop.

The difference between walkLength and count is that walkLength accepts a limit.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------