On Wed, Oct 21, 2015, at 04:07 PM, Gabriel Gellner wrote:
> That doesn't feel like a reason that they can't be iterators, rather
> that they might be slow ;) a la python. My point is not about speed
> but the consistency of the language. Are there many cases in Julia
> where there is a special type like this because it is
> convenient/elegant to implement? This feels like a recipe for madness,
> my guess is that this would be crazy rare.
>
> People wondered why people might mind that we get a LinSpace object vs
> an Array. For me it is this strange feeling that I am getting a
> special case that doesn't feel well motivated other than there is a
> nice way to implement it (and that people, again, assumed that it
> would largely be used for looping). If not all things can be made
> consistently iterators when they are vector-like then why not have a
> special function that returns this special type (like your
> aforementioned linrange)? The fact that I lose my iterator when I use
> certain functions but not others is a way that this polymorphism that
> everyone is describing doesn't feel as nice to me, since it will not
> compose in cases where it likely should, outside of implementation
> details.
Can you clarify with an example of when you lose the iterator? IMO that
would be an example of breaking the AbstractArray contract and worthy
of fixing.
I see your point that there are other functions that return array-like
objects that could also be implemented without fully constructing the
array, e.g. `zeros(20)` could return a `Zeros{20}` object that acts like
a length-20 array full of zeros. As far as I know there's no compelling
design reason that's a bad idea, it's just that nobody has done it.
The nice thing is that as long as people don't over-specify their type
annotations that change can be done under-the-hood and it shouldn't
break code. From a pedagogical standpoint I see how these sorts of
things can add confusion and cause new folks to question their
understanding, and more consistency reduces that conceptual friction.
-s
