On Tue, Jun 5, 2012 at 2:25 PM, Gábor Lehel 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 type declar
On Tue, Jun 5, 2012 at 4:18 AM, Etienne Laurin 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 the secti
>> | 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.
>>
Simon Peyton-Jones 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 pr
| > 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 th
Hello,
2012/6/1 Iavor Diatchki :
> 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
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
cl
Iavor Diatchki 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 lightly.
Yes
2012/5/31 Iavor Diatchki :
> 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.
Indeed, GHC's
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 constraint
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, t
Hello,
On Wed, Jul 7, 2010 at 2:14 PM, Simon Peyton-Jones wrote:
> 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 was unsound for
> fun
Gábor Lehel 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 context of
Gábor Lehel gmail.com> writes:
>
> On Fri, May 25, 2012 at 7:06 AM, AntC 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 explicitly stated that all
On Fri, May 25, 2012 at 7:06 AM, AntC 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 my
> explanation was a bi
Twan van Laarhoven gmail.com> writes:
>
> On 24/05/12 14:14, AntC wrote:
> > Simon Peyton-Jones microsoft.com> writes:
> >
>
> Have you considered the alternative notation where multiple guards are
allowed,
> as in normal function definitions? Something like:
>
> type instance F a
>
On 24/05/12 14:14, AntC wrote:
Simon Peyton-Jones 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
insta
Simon Peyton-Jones 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 families. But
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 over
19 matches
Mail list logo
