On Wed, Feb 18, 2015 at 10:02 AM, Geoffrey Irving <[email protected]> wrote:
> On Wed, Feb 18, 2015 at 9:42 AM, Jonathan S. Shapiro <[email protected]> > wrote: > > > But more generally, I'm not sure this is much different from the > situation > > for, say, integers. Given the definition: > > > > def SomeSortOfInteger = 1 > > > > there are 8 candidate types for SomeSortOfInteger. Unless it's mutable, > we > > simply allow it to be polymorphic. Why isn't it the same for abstract > > function types? > > Presumably the difference would be that there isn't a type that means > AnyKindOfInteger.... Well, no, but there is: IntTypeHolding 'a 1 => 'a Though I really need a sensible name for that constraint. There's a certain way of twisting your head such that 'a -> 'b -> ... -> 'z can be viewed as a similar type constraint. Something like (I'm making this up): Specializes 'fn 'a->'b->...'z => 'fn Incidentally, there probably *is* a type class that means > AnyKindOfInteger (or at least could be), and it's possible arity > genericity could be expressed using the basic type class mechanism. > I'm not saying this is a good idea as such, but it does make me > happier about the theoretical cleanliness. > Me too. I tend to think of this kind of thing as something that wants to be thought of as a constraint, and so fits well into the type class constraint mechanism, but I also think it's a closed "core" type class whose instances are all generated internally by the compiler. This is true in the same sense that "CopyCompat 'a 'b" and "CopyFromTo 'a 'b" are closed core type classes. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
