I'm back

[H. S. Teoh]

On Thu, Nov 15, 2012 at 02:14:15PM +0100, eskimo wrote:
> On Wed, 2012-11-14 at 18:31 -0800, Andrei Alexandrescu wrote:
> > > array(map!"a.dup"(stdin.byLine()))
> 
> As it seems there is a good way of handling ranges with transient
> front for algorithms that need a persistent front?
> 
> Why not simply document any transient range to be transient (should be
> anyway) and add the little hint to map. Also note that some algorithms
> might not work as expected with transient fronts. In addition, at
> least the algorithms in phobos should state in their documentation
> whether they rely on non transient front or not.

This is better than nothing, of course, but still, relying purely on
documentation is not desirable if we can do better. Though at this
point, it looks like we can't, so this may be the only option left.


[...]
> On the other hand if an algorithm depends unnecessarily on non
> transient fronts it should be fixed.

Definitely! I have a fix for std.algorithm.joiner already, and there are
a few others that can be fixed without too much effort (I hope).


> If there are many algorithms which can be more efficient with the
> dependency on non transient front, we could simply provide a second
> module, called std.transalgorithm (or something) offering dedicated
> algorithms for transient fronts. (So people don't have to role their
> own)

AFAIK, none of the algorithms will be more or less efficient depending
on whether non-transience can be assumed. It's just a matter of
reordering operations (don't call .popFront until .front is used); a bit
trickier to write the code, but doesn't change the asymptotic
complexity. The algorithms that *are* affected are those that can't work
with transient ranges anyway, so it doesn't really matter.


> I think this is a very clean and straight forward solution. If you
> want something that simply works you just use map!"a.dup" ( or
> whatever you need to copy your elements) and don't care. If you want
> performance then you would have to check what algorithms to use and
> have a look at std.transalgorithm.
[...]

I don't like duplicating a whole bunch of algorithms in transalgorithm.

However, there *may* be something to the idea of splitting up
std.algorithm so that those algorithms that aren't sensitive to
transience are in one module, and the fragile algorithms in another
module. Then one module can be clearly marked as usable with *all*
ranges, and the other as usable only with non-transient ranges.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.