More Type Parameters? #6081

Closed
andrewcooke opened this Issue Mar 8, 2014 · 15 comments

Projects

None yet

9 participants

@andrewcooke
Contributor

Continuing from #5102 and prompted by https://groups.google.com/d/msg/julia-users/4dkqhnesnUc/5DY9S1HrARAJ

Currently only integers, symbols and types (and tuples of those) can be type parameters. Maybe it would be nice to extend this?

One example (from the discussion above) is factor rings of polynomials. I am new to this so may have the jargon slightly wrong, but basically they're like arithmetic with integers modulo some value, except that you're using polynomials and calculating the "modulus" relative to a polynomial. When implementing that with integers it is a great help to put the modulus in the type - the rings/fields are of different types depending on "n" and it saves space in the instances. The same is not (easily) possible with general polynomials (you have to either encode the polynomial as a tuple of integers, or us an integer index into a separate, global lookup table).

That's a neat, theoretically convincing case, but it's not very practical (particularly since when you do want this you are usually handling special cases that can be encoded as integers). I don't know if there are better examples.

@MikeInnes
Member

One potential issue with allowing any immutable type is that people aren't forced to be sensible. For example, integers and symbols are sensible type parameters, and perhaps so are polynomials - but what if people start using floating point numbers? I do support this, but that's something to bear in mind.

@ihnorton
Member
ihnorton commented Mar 8, 2014

+1. I actually added Uint32 locally last night and was playing with HRESULTs as a type param.

@simonbyrne
Contributor

This would be very useful for numeric values with units of measure, as it could allow the computation units at compile time, so the actual computation shouldn't be any slower than the unit-free equivalent.

SIUnits.jl gets around this by defining the power of each SI unit as a parameter, but this limits the ability to use any additional units (e.g. currency, non-SI units), and means that any prefixed values (e.g. nanometre) incurs overhead and rounding error by converting to and from the normalised form.

@jiahao
Member
jiahao commented Mar 9, 2014

Last I checked, SIUnits.jl also doesn't support fractional powers of units.

@andrewcooke
Contributor

[TIL - http://physics.stackexchange.com/questions/13245/dimensional-analysis-restricted-to-rational-exponents]

@jiahao
Member
jiahao commented Mar 9, 2014

Computing critical exponents is a cottage industry in certain areas of physics.

@andrewcooke
Contributor

thinking a little more about this, the biggest danger seems to be a lack of referential transparency. what if you allowed any value (including data types) in a type, and then someone mutated the value? it seems like it would be better if julia had a way of marking types "really immutable" which applies not just to the contents, but the contents of pointers.

@vtjnash
Member
vtjnash commented Mar 13, 2014

tl;dr; types should not contain values.

there are isbits types which are truly immutable since they do not contain references to mutable types. the type parameters could probably be expanded to allow them without much work. however, the codegen concerns for this are worth considering: a type should (usually, with exceptions) be computable through analysis such that input type exactly determines output type. otherwise, the JIT starts doing a lot of extra work to predictively optimize functions which are changing constantly.

the distinction between types and contents may be hazy at times, but the restricted set of type parameters is intended to help the user make this distinction. my feeling is that the type parameters should help describe the contents, but that generally the value should be unambiguously unchanged if the type parameters were lost.

@JeffBezanson
Member

Type parameters are going to be compared by ===; that's pretty much a hard requirement. From there, I'd argue that type parameters should then only be things you'd want to compare with ===. This is pretty much a rewording of what @vtjnash said above. You wouldn't want T{[1]} and T{[1]} to be different types due to the arrays inside not being identical.

@stevengj stevengj referenced this issue in Keno/SIUnits.jl Aug 7, 2014
Open

support fractional powers? #32

@stevengj
Member
stevengj commented Aug 7, 2014

How about supporting arbitrary isbits immutable types as parameters?

@stevengj stevengj referenced this issue in JuliaLang/IJulia.jl Aug 7, 2014
Merged

Widget Messaging Protocol (IPEP 21) #190

@quinnj
Member
quinnj commented Aug 27, 2014

Bump. See discussion at 5999f53#commitcomment-7544035

@JeffBezanson JeffBezanson added this to the 0.4 milestone Aug 27, 2014
@JeffBezanson
Member

Yes. Will do.

@vtjnash
Member
vtjnash commented Aug 27, 2014

Just a thought for when this is implemented:

The type merge function in inference should probably aggressively drop type parameters (when merging similar types), similar to the way it aggressively widens to Tuple instead of trying to create successive Union types from specialized Tuples.

@JeffBezanson
Member

Yes, that's a good idea.

@stevengj
Member

A NEWS item would be good. Also a manual update.

@stevengj stevengj added a commit that referenced this issue Aug 30, 2014
@stevengj stevengj NEWS and manual update for #6081 90bf63c
@stevengj stevengj added a commit that referenced this issue Jan 4, 2015
@stevengj @tkelman stevengj + tkelman NEWS and manual update for #6081
(cherry picked from commit 90bf63c)
[av skip]

Conflicts:
	NEWS.md
d9b425b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment