More Type Parameters?

[andrewcooke]

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]

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]

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

[simonbyrne]

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]

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

[andrewcooke]

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

[jiahao]

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

[andrewcooke]

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]

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]

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]

How about supporting arbitrary isbits immutable types as parameters?

[quinnj]

Bump. See discussion at 5999f53#commitcomment-7544035

[JeffBezanson]

Yes. Will do.

[vtjnash]

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]

Yes, that's a good idea.

[stevengj]

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