On 10/17/12 12:53 PM, H. S. Teoh wrote:
> On Wed, Oct 17, 2012 at 12:39:13PM -0400, Andrei Alexandrescu wrote:
>> On 10/16/12 1:28 PM, Jonathan M Davis wrote:
>>> So, it's fine that ByLine is a range as long as we're willing to put
>>> up with it not working with a lot of range-based functions because of
>>> its abnormal behavior. But I don't think that it's at all reasonable
>>> for range-based functions in general to not be able to rely on front
>>> returning the same type every time or on its value disappearing or
>>> becoming invalid in some way after a call to popFront. That's
>>> completely untenable IMHO.
>>
>> Then what is to you the difference between an input range and a
>> forward range?
> [...]
>
> So what you're saying, is that we cannot rely on the value of .front
> after popFront() is called, and that the only way to ensure the validity
> of .front is to use a forward range's .save, and access the saved copy's
> .front?

Affirmative.

> It makes sense to me, but then we'd need to revise quite a lot of code
> in Phobos, as I've seen quite a number of places where .front is cached
> in some local variable or struct field, which would be invalid by your
> definition.

Yes. Only code that ostensibly works with input ranges needs to be reviewed.


Andrei

On Wednesday, October 17, 2012 12:39:13 Andrei Alexandrescu wrote:
> On 10/16/12 1:28 PM, Jonathan M Davis wrote:
> > So, it's fine that ByLine is a range as long as we're willing to put up with it not working with a lot of range-based functions because of its abnormal behavior. But I don't think that it's at all reasonable for range-based functions in general to not be able to rely on front returning the same type every time or on its value disappearing or becoming invalid in some way after a call to popFront. That's completely untenable IMHO.
> 
> Then what is to you the difference between an input range and a forward range?

Whether you can get a copy of the range. If you call save, you can save its current state and have two copies of the range to operate on separately, That's completely different from whether front can be kept around or not. It's perfectly possible to have an input range whose previous front does not get invalidated by a call to popFront. ByLine would be that way if it allocated a new buffer instead of reusing the old one. It just doesn't do that because it's less efficient to do so.

- Jonathan M Davis

Andrei Alexandrescu:

> You closed it.
>
> Also that bug has nothing to do with this topic because you can't compile the buggy code and have it silently do the wrong thing.
>
>
> Andrei

Sorry.

A solution is to introduce a "byLineFast" that is similar to the current "byLine", and make "byLine" copy.

Another solution is to keep only "byLine" and give it a compile-time boolean argument to disable the copy, that is active on default.

Bye,
bearophile

On Wednesday, 17 October 2012 at 19:14:12 UTC, Jonathan M Davis wrote:
> On Wednesday, October 17, 2012 12:39:13 Andrei Alexandrescu wrote:
>> On 10/16/12 1:28 PM, Jonathan M Davis wrote:
>> > So, it's fine that ByLine is a range as long as we're willing to put up
>> > with it not working with a lot of range-based functions because of its
>> > abnormal behavior. But I don't think that it's at all reasonable for
>> > range-based functions in general to not be able to rely on front
>> > returning the same type every time or on its value disappearing or
>> > becoming invalid in some way after a call to popFront. That's completely
>> > untenable IMHO.
>> 
>> Then what is to you the difference between an input range and a forward
>> range?
>
> Whether you can get a copy of the range. If you call save, you can save its
> current state and have two copies of the range to operate on separately,
> That's completely different from whether front can be kept around or not. It's
> perfectly possible to have an input range whose previous front does not get
> invalidated by a call to popFront. ByLine would be that way if it allocated a
> new buffer instead of reusing the old one. It just doesn't do that because it's
> less efficient to do so.
>
> - Jonathan M Davis

This.

When you think about it, byLine *could* be a ForwardRange (it could save its pget position in the file), allowing it to backtrack, but that *still* wouldn't prevent it from overwriting its own internal buffer on calls to front: That is just a detail of its implementation.

A range's "Input-ness" or "Forward-ness" is completely orthogonal from the returned front's transitiveness.

On Wednesday, 17 October 2012 at 19:42:39 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> You closed it.
>>
>> Also that bug has nothing to do with this topic because you can't compile the buggy code and have it silently do the wrong thing.
>>
>>
>> Andrei
>
> Sorry.
>
> A solution is to introduce a "byLineFast" that is similar to the current "byLine", and make "byLine" copy.
>
> Another solution is to keep only "byLine" and give it a compile-time boolean argument to disable the copy, that is active on default.
>
> Bye,
> bearophile

Given that "byLine" already exists, I'm not sure we can change it now. But I wouldn't be against adding a "byLineSlow" or something.

However, if we could start again, I'd *definitely* favor a deep copying "byLine" by default, and have a faster, but harder to use "byLineFast".

On 10/17/2012 07:20 PM, Andrei Alexandrescu wrote:
> On 10/16/12 3:41 PM, H. S. Teoh wrote:
>> I think with D's compile-time introspection capabilities, it _should_ be
>> possible to implement a generic deepCopy template that works for any
>> type.
>>
>> Of course, then one has to address tricky issues such as complex data
>> structures that have interlinking parts; a blind recursive deep-copy may
>> not have the desired effect (e.g., if we're deep-copying a graph and
>> there are multiple paths (via references) to the same node, then we
>> shouldn't end up with multiple copies of that node). Some care will also
>> need to be taken to deal with cyclic structures, etc.. And some
>> optimizations can probably be done to avoid copying immutable objects,
>> since that would be a waste of time&  memory.
>>
>> Probably some kind of graph traversal algorithm can be used to address
>> these issues, I think, perhaps with the help of an AA or two to recreate
>> the original linking structure in the copy.
>
> Yes, deepDup should be implementable as a library and use a temporary
> dictionary of already-duplicated items to avoid infinite recursion.
>
> We should add that to Phobos - could you please add a task to trello.
>
>
> Andrei
>

A deepDup is missing information about what is representation and what
is just a reference kept in order to access external data, so it is
quite useless.

Am Wed, 17 Oct 2012 22:09:08 +0200
schrieb "monarch_dodra" <monarchdodra@gmail.com>:

> Given that "byLine" already exists, I'm not sure we can change it now. But I wouldn't be against adding a "byLineSlow" or something.
> 
> However, if we could start again, I'd *definitely* favor a deep copying "byLine" by default, and have a faster, but harder to use "byLineFast".

I agree. And simple demo programs can just use

byLine => string

and if we talk about a fast "word count" demo, then it probably doesn't hurt when the reader sees, that the library provides ranges for both use cases.

byLineOverwrite => char[]

After all a line is expected to be a string, and D to be safe. But the real issue are the differing views on how .front should work. Unlike other problems, this one has solutions that wont break code, if that is a requirement. So I'll let the Phobos crew argue and see what happens. :)

-- 
Marco