On Tue, Jun 5, 2012 at 2:25 PM, Gábor Lehel illiss...@gmail.com wrote:
The encoded version would be:
instance (f a b) = FMap f (HJust a) (HJust b)
where type f :$: (HJust a) = HJust b
and I think this actually demonstrates a *different* limitation, namely that
The RHS of an associated
On Tue, Jun 5, 2012 at 4:18 AM, Etienne Laurin etie...@atnnn.com wrote:
Thanks for the idea. Here it is.
http://hackage.haskell.org/trac/ghc/wiki/TFvsFD
I posted my comments on the matter along with many additional comments
and examples that I found.
Thanks!
One part is confusing me.
In
| My take is that we should abandon Fundeps, and concentrate on
| introducing overlaps into type functions in a controlled way (what
| I've called 'dis- overlapped overlaps'.)
|
| Abandoning fundeps would be a sad day for type-level programming.
| There are many things other than overlaps that
Simon Peyton-Jones simonpj at microsoft.com writes:
| My take is that we should abandon Fundeps, and concentrate on
| introducing overlaps into type functions in a controlled way (what
| I've called 'dis- overlapped overlaps'.)
|
| Abandoning fundeps would be a sad day for type-level
| Abandoning fundeps would be a sad day for type-level programming.
| There are many things other than overlaps that you can do with fundeps
| and constraint kinds that you cannot currently do with type families,
| such as:
|
| - Partial application or higher-order programming.
| -
Hello,
There is no problem if an instances uses a type family in it's
assumption---the instances should be accepted only if GHC can see enough of
the definition of the type family to ensure that the functional dependency
holds. This is exactly the same as what it would do to check that a super
Hello,
2012/6/1 Iavor Diatchki iavor.diatc...@gmail.com:
There is no problem if an instances uses a type family in it's
assumption---the instances should be accepted only if GHC can see enough of
the definition of the type family to ensure that the functional dependency
holds. This is
2012/5/31 Iavor Diatchki iavor.diatc...@gmail.com:
Hello,
the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look
at http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
redefine it
Iavor Diatchki iavor.diatchki at gmail.com writes:
Hello,
the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look
at http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
redefine it
Hello,
On Wed, Jul 7, 2010 at 2:14 PM, Simon Peyton-Jones simo...@microsoft.comwrote:
We can’t permit overlap for type families because it is *unsound *to do
so (ie you can break “well typed programs don’t go wrong”). But if it’s
unsound for type families, it would not be surprising if it
Hello,
I disagree with your example.
1. Check that an instance is consistent with itself. For example, this
should be rejected:
instance C a b
because it allows C Int Bool and C Int Char which violate the functional
dependency.
Functional dependencies are not used to pick types, they
Hello,
the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look at
http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
redefine it lightly.
Note that placing a functional dependency
Gábor Lehel illissius at gmail.com writes:
If you're referring to the NewAxioms work Simon linked to ... [snip]
... It seems vaguely similar to a paper on instance chains[2]
I saw once.
Thanks Gábor for the reference, but I don't think they're very comparable.
The instance chains is in
Gábor Lehel illissius at gmail.com writes:
On Fri, May 25, 2012 at 7:06 AM, AntC anthony_clayden at clear.net.nz
wrote:
But it looks like the work SPJ pointed to is using closed style. ...
If you're referring to the NewAxioms work Simon linked to in the other
thread, I don't see it
On Fri, May 25, 2012 at 7:06 AM, AntC anthony_clay...@clear.net.nz wrote:
But it looks like the work SPJ pointed to is using closed style. If all
they're trying to do is support HList and similar, I guess that's good enough.
I tried to explain all this the best part of a year ago. (Admittedly
Simon Peyton-Jones simonpj at microsoft.com writes:
[from 7 Jul 2010. I've woken up this thread at Oleg's instigation
http://www.haskell.org/pipermail/haskell-prime/2011-July/003491.html ]
I'm not going to talk about Fundeps. This is about introducing overlapping
instances into type
On 24/05/12 14:14, AntC wrote:
Simon Peyton-Jonessimonpjat microsoft.com writes:
[from 7 Jul 2010. I've woken up this thread at Oleg's instigation
http://www.haskell.org/pipermail/haskell-prime/2011-July/003491.html ]
I'm not going to talk about Fundeps. This is about introducing
Twan van Laarhoven twanvl at gmail.com writes:
On 24/05/12 14:14, AntC wrote:
Simon Peyton-Jonessimonpjat microsoft.com writes:
Have you considered the alternative notation where multiple guards are
allowed,
as in normal function definitions? Something like:
type instance F
Oleg points out, and Martin also mentions, that functional dependencies appear
to interact OK with overlapping instances, but type families do not. I this
impression is mistaken, and I'll try to explain why in this message, in the
hope of exposing any flaws in my reasoning.
We can't permit
19 matches
Mail list logo
