Transience of .front in input vs. forward ranges

[H. S. Teoh]

On Thu, Nov 01, 2012 at 03:18:13PM +0100, deadalnix wrote:
> Le 01/11/2012 05:30, H. S. Teoh a écrit :
> >On Thu, Nov 01, 2012 at 12:05:18AM +0100, deadalnix wrote:
> >>Le 31/10/2012 18:19, H. S. Teoh a écrit :
> >[...]
> >>>Actually, there is another problem: many algorithms' output will be
> >>>transient or not depending on the input range. For example, we
> >>>could write map to use the transient version of byLine, say, but
> >>>then the range that map returns will also be transient (no longer
> >>>safe).
> >>>
> >>>IOW, transience of .front is transitive in some cases. This again
> >>>makes things complicated: as soon as you use a single transient
> >>>range, it makes downstream ranges transient as well. So we're back
> >>>to the problem of how to mark the range as transient in a
> >>>transparent way. :-(
> >>>
> >>
> >>No it isn't always transitive. But that is true that it is in some
> >>cases.
> >>
> >>This is why the code should default to the safe behavior. It is up
> >>to the programmer to ensure correctness when opting for an alternate
> >>behavior.
> >
> >But then can the alternate behaviour be used at all? For example,
> >joiner will return a range which will be transient if the original
> >range is transient. But since this is "unsafe" behaviour, joiner's
> >implementation can't take advantage of the faster behaviour at all,
> >since otherwise the user, not knowing that it is switching to, say,
> >byLine.fast instead of the safe version of byLine, may assume that
> >the resulting range is non-transient, but it is actually transient.
> >
> >So this nullifies the usefulness of having .fast, since many Phobos
> >algorithms that would have been able to take advantage of .fast
> >can't, because their result will be unsafe. In which case, is it even
> >worth the bother to implement such a thing?
> >
> >I think we still haven't addressed the fundamental issue, that is, we
> >need a way to differentiate between transient and non-transient
> >.front values. Being able to work with transient values is the best,
> >because it automatically also works for non-transient values, but
> >some algos need to be able to assume non-transience. This core
> >problem is still unsolved.
> >
> >
> 
> Would joiner be able to take advantage of this if it was known or not ?

I have a working version of joiner that doesn't assume the persistence
of .front. The thing is, if the range you hand it is transient, then the
resulting joined range is also transient. This shows up in one of my
unittests: I can't use writeln() because it assumes persistence of
.front, and I can't use array() either for the same reason. I have to
explicit write a foreach to .dup the elements of the range into an array
before it can be safely used in writeln(), etc..

This makes it impossible for joiner to transparently switch to a fast
implementation (call .fast on the original range), because in this case
the transience is transitive -- the user will have to explicitly call
joiner with .fast. I don't like that, because then how would you know
which algos are safe to call with .fast? It's only by documentation,
i.e., by convention, and is bound to be a hiding place for bugs later
on.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.