[Haskell-cafe] Mild confusion around type family

[Richard Eisenberg]

"type" does exactly mean a synonym. "type family" means something else. Exactly what that "something else" is is actually puzzling me too these days. I think some Hard Thought here is called for, to be honest. A close approximation is that type families do introduce new types, with equality dictated by a (confluent) rewrite system. The troublesome aspect of declaring a new type at a closed kind is mitigated by the fact that we can never pattern match on a type family. (That is, we can't use a type family on the left of the = in a type family instance.) So we can't ever observe the new types. But it is still a bit odd.

As for the trick of getting early errors through infinite recursion: be careful. GHC makes no guarantees at all that an infinite loop in a type will cause an error. For example, if you have

type Const a b = a

and the infinite loop is the second parameter to Const, GHC will chug on happily. Perhaps this is intended, but perhaps not. Note that there is no type-level `Seq` that you might need to "force" a type to expose this sort of error.

Richard

On Jun 22, 2015, at 3:52 AM, "Nicholls, Mark" <nicholls.mark at vimn.com> wrote:

> So this works, what i find surprising is that type families do this at all...in my head "type" means some sort of synonym, so to allow unmapped synonyms and not flag them as an error seems very odd.
> 
> With datakind its doubly troubling as the unmatched family expression is of the same kind as the intended types in the domain of the "function"...so its unmatched and ive extended what seemed to be a closed expression defining some types of kind N.
> 
> Excuse the spelling, sent from a phone with itty bitty keys, it like trying to sow a button on a shirt with a sausage.
> 
> 
> On 21 Jun 2015, at 13:07, Nicholls, Mark <nicholls.mark at vimn.com> wrote:
> 
>> ugly...but effective.
>>  
>> thanks
>>  
>>  
>> From: adam vogt [vogt.adam at gmail.com]
>> Sent: 20 June 2015 16:34
>> To: Richard Eisenberg
>> Cc: haskell-cafe; Nicholls, Mark
>> Subject: Re: [Haskell-cafe] Mild confusion around type family
>> 
>> 
>> On Jun 19, 2015 2:29 PM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:
>> > With a closed family, you could always do something like this:
>> >
>> > > type family Error (msg :: Symbol)     -- no instances!
>> > > type family Sub a b where
>> > >   -- real work
>> > >   Sub a b = Error "Sub is undefined here"
>> >
>> > Would that help? It still doesn't immediately error (there's no way to do that currently), but it's perhaps more telling to have an error string.
>> Ghc does error out right away if you give it an infinite loop:
>> type family Fail (x::k) (a :: *) where
>>   Fail x a = Fail x (Fail "don't raise the context stack please" a)
>> -- defining f leads to compile failure, and the message includes the "msg"
>> f :: Fail "msg" ()
>> f = undefined
>> But it would be nice to have a less hacky solution, especially as this one gives error messages that suggest giving the type checker more resources.
>> Regards,
>> Adam
>> 
>> 
>> 
>> CONFIDENTIALITY NOTICE
>> 
>> This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.
>> 
>> While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.
>> 
>> Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.
>> 
>> MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
> 
> 
> CONFIDENTIALITY NOTICE
> 
> This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.
> 
> While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.
> 
> Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.
> 
> MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150622/fd4bead2/attachment.html>