Hi,
Am Montag, den 19.08.2013, 08:27 + schrieb Simon Peyton-Jones:
> Yes that makes sense to me. Please do document the reasoning of this thread
> (and the example you give) in a "Note [Incoherent instances]" somewhere
> though!
done, patches ready for review and merge at
https://github.co
Of Joachim Breitner
| Sent: 19 August 2013 09:07
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Liberalising IncoherentInstances
|
| Good morning,
|
| Am Samstag, den 27.07.2013, 20:16 + schrieb Simon Peyton-Jones:
| > So the change I propose to make IncoherentInstances to pick
|
Good morning,
Am Samstag, den 27.07.2013, 20:16 + schrieb Simon Peyton-Jones:
> So the change I propose to make IncoherentInstances to pick
> arbitrarily among instances that match. More precisely, when trying
> to find an instance matching a target constraint (C tys),
>
> a) Find all instan
> Axel Simon in.tum.de> writes:
> ...
>
> In recent years I acquired the view that
> type inferences should have some sort of semantic completeness property
> ...
If you want 'semantic completeness', don't use IncoherentInstances.
(As several have said, it's not a popular extension;
more of
Hi,
Am Montag, den 29.07.2013, 16:19 +0100 schrieb John Lato:
> +1 to the original proposal and Edward's suggestion of emitting a
> warning. I've occasionally wanted this behavior from
> IncoherentInstances as well.
+1 for the proposal, -1 for the warning: It is a feature, not a bug, at
least th
+1 to the original proposal and Edward's suggestion of emitting a warning.
I've occasionally wanted this behavior from IncoherentInstances as well.
On Mon, Jul 29, 2013 at 3:01 PM, Edward Kmett wrote:
> I'll probably never use it, but I can't see any real problems with the
> proposal. In many w
I'll probably never use it, but I can't see any real problems with the
proposal. In many ways it is what I always expected IncoherentInstances to
be.
One thing you might consider is that if you have to make an arbitrary
instance selection at the end during compile time, making that emit a
warning
> Incidentally, I think it'd be an improvement to localise the
> Overlapping/Incoherent flags to particular instance declarations, via
> pragmas, something like
> instance C [a] where
> {-# ALLOW_OVERLAP #-}
> op x =
>
> Similarly {-# ALLOW_INCOHERENT #-}. Havin
> AntC clear.net.nz> writes:
Uh-oh, quoted the wrong example. I mean:
Starting with:
class C a b | a -> b where foo :: a -> b
instance C [a] [a] where foo = id
t11 = \x -> foo [x] -- t11 :: t -> [t]
I then added:
instance C [Char] [Char] where foo = id
> Simon Peyton-Jones microsoft.com> writes:
>
> I've realised that GHC's -XIncoherentInstances flag is,
> I think, over-conservative.
Hi Simon, by coincidence I've just come across a very similar issue with
overlapping instances and FunDeps (following-up some discussion with Oleg,
MartinS, Ed
Friends
I've realised that GHC's -XIncoherentInstances flag is, I think,
over-conservative. I propose to liberalise it a bit. This email describes the
issue. Please yell if you think this is a bad idea.
Simon
Suppose we have
class C a where { op :: a -> String }
instance C [
11 matches
Mail list logo
