Allow usage of specific immutable types as parameters

[timholy]

The proximal motivation behind this is to be able to support stuff like sqrt(2Meter), where Meter is from SIUnits. This doesn't easily work now because SIUnits encodes the units as integer type parameters, and currently Rationals cannot be used as type parameters. One could do it now using a "cheat" like this:

immutable RationalP{Num,Denom}; end

and then using RationalP{1,2} as a parameter. However, I wondered if it would be better just to use plain Rationals.

Consequently, this implements a framework for "registering" specific types as being acceptable type parameters. I would be pretty surprised if there weren't some serious problems with this, but there's no better way to find out than by submitting it.

[JeffBezanson]

It would make more sense just to allow every value as long as it's clear that === is the operative equality relation.

[StefanKarpinski]

Is it too finicky to limit it to immutable values?

[timholy]

I started out by just redefining valid_type_param as

static int valid_type_param(jl_value_t *v)
{
    return 1;
}

but got worried there would be something horrible about that. Currently there's a test in core.jl that throws an error if one tries using a string.

Should I rework this to use the above definition?

[JeffBezanson]

Limiting it to immutable values would be better. The ideal type parameters are those for which == and === are identical. Next best are immutable values, where at least === examines their contents, though it may be pickier than you'd prefer.

Immutable values have the advantage that you can always externally construct a matching value, e.g. T{1//2} in one place will match T{1//2} written in another place. However, for mutable values you'd have to arrange to supply the exact same value as a type parameter, which doesn't really make sense for the way types are usually used.