On Jun 13, 2015, at 8:18 AM, Hendrik Boom <hend...@topoi.pooq.com> wrote: > On Fri, Jun 12, 2015 at 06:06:05PM -0700, 'John Clements' via users-redirect > wrote: >> On Jun 12, 2015, at 5:52 PM, Alexander D. Knauth <alexan...@knauth.org> >> wrote: >>> On Jun 12, 2015, at 8:30 PM, 'John Clements' via users-redirect >>> <us...@plt-scheme.org> wrote: >>> >>>> (define-type (HuffJsexpr T) >>>> (U T (HashTable Symbol HuffJsexpr))) >>> >>> Do you mean this? >>> (define-type (HuffJsexpr T) >>> (U T (HashTable Symbol (HuffJsexpr T))))
>> Actually, I also can’t believe that TR allowed me to use a type constructor >> without an argument like that. > > Maybe the type definitions need to be type-checked, too? > > -- hendrik I was thinking about this and I was coming up with an explanation of why it wouldn’t work (the way TR is currently set up), but then I realized there could be a way of doing this that makes sense without restructuring TR, so … First, the reason I thought it might not work: In TR a type constructor and a polymorphic type are the same thing. And that makes sense because it makes sense to instantiate polymorphic types as if they were type constructors. But that means that when it comes across a type constructor, it sees it as a polymorphic type, so it doesn’t raise a type error. But type constructors like this don’t always make sense as polymorphic types, because polymorphic types only really make sense when there is something in the value with that type that can take some kind of input, like a function, some data structure containing a function, an object, or even something that could be mutable, I guess? I’m not sure. Anyway that could be something that TR could check for in this kind of thing, but it seems like it could be complicated? Again I’m not sure. Or would it be simpler to just separate type constructors from polymorphic types completely, but allow polymorphic types to be used as type constructors as well for backwards compatibility? But that could involve … Actually, I was I about to say that would probably involve restructuring a lot of the type checker, but then I thought maybe type constructors could be a container type that contains a “polymorphic” type, and when it is “applied" the type-checker would just ignore this and look at the “polymorphic” type inside, but in a situation that requires an actual “non-constructor” type, it would raise a type error? But then what if you wanted to define a type constructor that accepts type constructors as arguments (a higher-order type-constructor)? Again, it seems like this could also be complicated? I’m not sure what the best thing to do is. Would bounded polymorphism help to solve this? Or would it require another whole type system for types and type constructors? Sorry if this doesn’t make much sense. I’m sending it anyway. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
