On Jun 19, 2015, at 10:14 AM, "Nicholls, Mark" wrote:

...

type family Sub a b where -- a - 0 == a Sub a Z = a -- (a + 1) - (b + 1) == a - b Sub (S a) (S b) = Sub a b

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. Richard

Let me have a go with both of these 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 20 Jun 2015, at 16:35, adam vogt mailto:vogt.adam@gmail.com> wrote: On Jun 19, 2015 2:29 PM, "Richard Eisenberg" mailto:eir@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.

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 mailto:nicholls.mark@vimn.com> wrote: ugly...but effective. thanks ________________________________ From: adam vogt [vogt.adam@gmail.commailto:vogt.adam@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" mailto:eir@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@haskell.orgmailto:Haskell-Cafe@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.

I mostly understand (a confluent rewrite system doesn't register). I did something it mathematically couldn't do. I did 0 - n = (0 - (0 - (0 - n))) On N...that can't be done... It all feels a bit odd....introducing new types through data families seems reasonable, introducing them through type families...not.....but that's to my untrained eye. From: Richard Eisenberg [mailto:eir@cis.upenn.edu] Sent: 22 June 2015 5:20 PM To: Nicholls, Mark Cc: adam vogt; haskell-cafe Subject: Re: [Haskell-cafe] Mild confusion around type family "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" mailto:nicholls.mark@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 mailto:nicholls.mark@vimn.com> wrote: ugly...but effective. thanks ________________________________ From: adam vogt [vogt.adam@gmail.commailto:vogt.adam@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" mailto:eir@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@haskell.orgmailto:Haskell-Cafe@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. 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.