A Case For Other Dependent Types?

101 views
Skip to first unread message

andrew cooke

unread,
Mar 8, 2014, 7:07:32 AM3/8/14
to julia...@googlegroups.com

Why does Julia restrict dependent types to integers (or tuples thereof)?

julia> type Foo{a} end

julia
> Foo{3}()
Foo{3}()                                                                        
                                                                               
julia
> Foo{"hello"}()                                                          
ERROR
: type: apply_type: in Foo, expected Type{T<:Top}, got ASCIIString  

julia
> Foo{(1,2)}()
Foo{(1,2)}()

When I write code for rings over the integers, modulo N, I can stick N in the type.  It's great, because you don't want to mix your fields, so the type keeps things separate, and you don't need extra storage space, repeating N for each instance.

But when I want to do the equivalent for factor rings of polynomials (where a polynomial is the equivalent of N above) then, suddenly, I cannot.  I cannot replace N above with a polynomial, because the type system won't allow it (afaict).  Yet the same arguments apply - I don't want to mix factor rings (different polynomials give different types) and I don't want to repeat the factor in each instance - it's just wasting storage space.

What is the reason for this (apparently arbitrary) restriction?  I think I can work round it by encoding the polynomial as a tuple of integers, but it's going to be painful, and likely inefficient.

And sorry I am asking multiple questions today.  I feel like I am sitting here complaining about everything just because I am ignorant...

Andrew

PS How does the logic of the error above work?  How are integers types?  Is it special cased in the compiler?

Ivar Nesje

unread,
Mar 8, 2014, 7:30:18 AM3/8/14
to julia...@googlegroups.com
The selection of what values you can use as type parameters is defined in https://github.com/JuliaLang/julia/blob/master/src/jltypes.c#L1473-L1488
If you want to live on the dangerous side for experimentation, you can change that function to always return true.

AFAICT the restriction is mainly an attempt to be conservative about what is allowed to be used as type parameters to stop people from using obviously stupid type parameters inadvertently. Stefan said strings are probably not going to be officially supported. The code lists a TODO to maybe add more types, and if you provide a compelling usecase, it might be changed.

Ivar

andrew cooke

unread,
Mar 8, 2014, 8:37:50 AM3/8/14
to julia...@googlegroups.com

OK, thanks.

I'm sympathetic to the idea that the type system should be simple, and in at least my case, when I want most efficiency I will be encoding polynomials over GF2 as bits in an integer anyway, so it will work.  It's only the (less used) general case that will be slow.

One random idea that I guess is impractical - pull valid_type_param into julia and let people over-ride it.  That might be a compromise.  Not sure even I think it's a good idea, though.

Andrew

Mike Innes

unread,
Mar 8, 2014, 8:44:32 AM3/8/14
to julia...@googlegroups.com
I think there's definitely a case for allowing any immutable type as parameters, at least. I would open an issue on github if there isn't one already, that way you can start a discussion.

andrew cooke

unread,
Mar 8, 2014, 9:06:38 AM3/8/14
to julia...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages