Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove eltype parameter from AbstractArray and use IteratorEltype instead #39626

Open
bramtayl opened this issue Feb 11, 2021 · 1 comment
Open
Labels
arrays [a, r, r, a, y, s] breaking This change will break code design Design of APIs or of the language itself needs decision A decision on this change is needed speculative Whether the change will be implemented is speculative traits Traits, sometimes called Tim Holy Traits

Comments

@bramtayl
Copy link
Contributor

bramtayl commented Feb 11, 2021

Background:

There seems to be a preponderance of theoretical AbstractArrays (roughly, a bunch of things arranged in a hypercube) without eltypes:

The reason these things don't have an eltype is fundamentally because Julia is a dynamic language and return types aren't really supposed to exist. That is, you can't really know the type of the result of applying a function (like the mapping function, or view for array slices) until you actual do it.

The problem is, none of the the theoretical AbstractArrays can inherit any of the methods defined for AbstractArrays, which means they either have to duplicate a whole bunch of machinery (like the broadcasted objects) or just not have the same super powers (like the Iterator.maps). I've been thinking about this for a while; see #34196 and #35095 for context.

I really like @andyferris 's idea in #32310 (comment) as a simple solution. The idea if I understand correctly is to remove the eltype type parameter from AbstractArray, and instead, unless you already know it exists, access the eltype only after having checked the IteratorEltype trait first.

The advantages I see are:

  • Doesn't require really dramatic changes to the language; after all, we already have and use IteratorEltype, this would just make it more consistent.
  • Will either remove the need for duplicate code or add new powers to existing things
  • Could facilitate laziness (like, instead of allocating a broadcast, return a fully featured lazy broadcast instead)

The disadvantages I see are:

  • Will require some new types. We would need at least a MappedArray object, a SlicedArray object, and maybe a BroadcastedArray object. In comparison, a more thoroughly trait-based solution might not need as many new types.
  • Maybe a bit more inconvenient; to write generic methods for AbstractArrays, you might have to check IteratorEltype first.

I had a crack at messing around with the code in src to make a PR and realized pretty quickly I was out of my depth because I don't know much C (and obtuse abbreviated names don't help much). If someone figures that out though, I could do the Julia parts (updating Julia code and tests). I suppose this is likely too big of a change for 1.0?

Sorry if I wrote too much...I figure too much is better than too little though.

@andyferris andyferris added arrays [a, r, r, a, y, s] breaking This change will break code needs decision A decision on this change is needed design Design of APIs or of the language itself speculative Whether the change will be implemented is speculative traits Traits, sometimes called Tim Holy Traits labels Feb 11, 2021
@JeffBezanson
Copy link
Member

I suppose this is likely too big of a change for 1.0?

Ummm...yes??

This is really too big a topic, and I think it will be an important part of the discussion around traits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrays [a, r, r, a, y, s] breaking This change will break code design Design of APIs or of the language itself needs decision A decision on this change is needed speculative Whether the change will be implemented is speculative traits Traits, sometimes called Tim Holy Traits
Projects
None yet
Development

No branches or pull requests

3 participants