Richard,
Thanks for your answers.
2013/6/24 Richard Eisenberg e...@cis.upenn.edu:
The nub of the difference is that type families can pattern-match on kinds,
whereas term-level functions cannot pattern-match on types. So, while the @a
is repeated in the pattern as written above, GHC does
Sure. Say you want a default type at any given kind. You could write something
like this:
type family Default (a :: k) :: k
type instance Default (a :: *) = ()
type instance Default (a :: * - *) = []
type instance Default (a :: * - * - *) = (,)
type instance Default (a :: * - * - * - *) =
Richard,
I'm interested by your argument at the bottom of the wiki page about
the alternative (non-)solution of disallowing non-linear patterns
altogether. I'll quote it for reference:
One way we (Simon, Dimitrios, and Richard) considered proceeding was
to prohibit nonlinear unbranched
family
with closed family helpers.
-Original Message-
From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
users-boun...@haskell.org] On Behalf Of AntC
Sent: 24 June 2013 03:59
To: glasgow-haskell-users@haskell.org
Subject: Re: Repeated variables in type family
Interesting points you make here. See my comments below:
-Original Message-
From: dominique.devri...@gmail.com
[mailto:dominique.devri...@gmail.com] On Behalf Of Dominique Devriese
[snip]
Wouldn't you get the same problem if you try to check a
value-level pattern's linearity after
Richard Eisenberg eir at cis.upenn.edu writes:
... The plan of action is to use the check labeled (B)
on the wiki page. This check does *not* ban all nonlinear type families.
Thanks Richard, great! Then the focus of attention moves to infinite types.
I don't think anybody intentionally
Richard Eisenberg eir at cis.upenn.edu writes:
And, in response to your closing paragraph, having type-level equality
is the prime motivator for a lot of
this work, so we will indeed have it!
Thank you Richard, I'll take comfort in that.
I'd beware this though: the Nonlinearity wikipage
Ah -- I think the waters have been muddied somewhat as our thoughts have
evolved. The plan of action (of history, at this point -- I merged into HEAD
yesterday) is to use the check labeled (B) on the wiki page. This check does
*not* ban all nonlinear type families. It just makes certain
Richard Eisenberg eir at cis.upenn.edu writes:
Hi Richard, I was hoping one of the type/class/family luminaries would
pick this up, but I'll make a crack at moving it along.
It’s come to my attention that there is a tiny lurking potential hole in
GHC’s type safety around type families in
On Jun 20, 2013, at 11:47 AM, AntC wrote:
Hmm. Several things seem 'fishy' in your examples. I'll take the second
one first:
type family G
type family G = [G]
Your criticisms of this example (that it is nullary and unusable) are valid.
But, it would be easy to change the example to
(Sorry for the re-send - got the wrong subject line last time.)
Hello all,
It's come to my attention that there is a tiny lurking potential hole in
GHC's type safety around type families in the presence of
UndecidableInstances. Consider the following:
type family F a b
type instance
11 matches
Mail list logo
