You don't say what you are trying to achieve. However it looks as if
you mean "If you want PO T, for some type T, first try (Bounded T, Enum
T, SemiRing T) and if that fails try CSemiRing T. Or maybe the other
way round.
In any case, GHC simply does not implement this kind of backtracking
search
| > class PO a where
| >(|=3D) :: a -> a -> Bool
| >
| > class Num a =3D> SemiRing a
| >
| > class SemiRing a =3D> CSemiRing a
| >
| > instance (Bounded a, Enum a, SemiRing a) =3D> PO a where
| >a |=3D b
| > =3D or [ a + c =3D=3D b | c <- boundedEnumFrom minBound ]
| >
| > instance C
Simon Peyton-Jones wrote:
As a trivial example, try
f a = a |= a
What type shall we infer for f?
f :: (Bounded a, Enum a, SemiRing a) => a -> a
or
f :: (CSemiRing a) => a -> a
This has always confused me - GHC always seems to use the strongest
possible conditions when inferring types (
On Thu, May 20, 2004 at 08:52:45AM +0100, Simon Peyton-Jones wrote:
| You don't say what you are trying to achieve. However it looks as if
| you mean "If you want PO T, for some type T, first try (Bounded T, Enum
| T, SemiRing T) and if that fails try CSemiRing T. Or maybe the other
| way round.
I don't know whether this was apparent, but only the instance
pattern is used in determining which instance to use, so
"PO a" is the same as "PO a" ... you need to make them different
otherwise they don;t just overlap they are identical.
the left-hand-side of the "=>" play no part in instance sel
On Thu, May 20, 2004 at 03:52:49PM +0100, MR K P SCHUPKE wrote:
> I don't know whether this was apparent, but only the instance
> pattern is used in determining which instance to use, so
> "PO a" is the same as "PO a" ... you need to make them different
> otherwise they don;t just overlap they are
>That's not the notion of priority I was referring to.
Any type of priority would not help. As I said then the instance heads
are identical (PO a) and (PO a) - no kind of priority will help
differenciate the,
Keean.
___
Glasgow-haskell-users mai
On Thu, May 20, 2004 at 05:16:45PM +0100, MR K P SCHUPKE wrote:
> >That's not the notion of priority I was referring to.
>
> Any type of priority would not help. As I said then the instance heads
> are identical (PO a) and (PO a) - no kind of priority will help
> differenciate the,
I wasn't talki
>I wasn't talking about _any_ notion of ordering of instance heads; I
>said that prioritising instance _declarations_ themselves, explicitly,
>by 'name' would suffice.
How does that help... if you name the instances differently are they
not just ordinary functions, as they would no longer be over
On Thu, May 20, 2004 at 05:27:43PM +0100, MR K P SCHUPKE wrote:
> >I wasn't talking about _any_ notion of ordering of instance heads; I
> >said that prioritising instance _declarations_ themselves, explicitly,
> >by 'name' would suffice.
>
> How does that help... if you name the instances differe
PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Stefan Reich
| Sent: 20 May 2004 13:48
| Cc: [EMAIL PROTECTED]
| Subject: Re: Overlapping, undecidable, incoherent -- or worse?
|
| Simon Peyton-Jones wrote:
| > As a trivial example, try
| >
| > f a = a |= a
| &g
I don't think you get it... naming does not help, the problem is the
compiler cannot distinguish between the instances.
The alternative to the current situation is to take into account the
dependancies of instances when selecting. The problem here is that
the compiler may select an instance, evalu
On Thu, May 20, 2004 at 05:58:53PM +0100, MR K P SCHUPKE wrote:
> The alternative to the current situation is to take into account the
> dependancies of instances when selecting. The problem here is that
> the compiler may select an instance, evaluate its dependencies, only
> to discover somewhere
that is not the case with "-fallow-undecidable-instances" ... as far as
I understand it , ghc never considers the dependancies when selecting an
instance. If you don't think so you will need to show me an example where
it clearly does... as I haven't seen one yet (but just because I haven't
seen it
On Thu, May 20, 2004 at 07:34:18PM +0100, MR K P SCHUPKE wrote:
> that is not the case with "-fallow-undecidable-instances" ... as far as
> I understand it , ghc never considers the dependancies when selecting an
> instance. If you don't think so you will need to show me an example where
> it clear
I think you should read the GHC manual (assuming it is up to date
and undecidable instances means what it says it does, the difference
is...
Without undecidable instances at least one type in the instance
must not be a type variable.
With undecidable instances you can have a default-instance (al
On Thu, May 20, 2004 at 09:25:20PM +0100, MR K P SCHUPKE wrote:
> Thats it... Neither GHC nor Hugs pay any attention to the
> dependancies when choosing which instance to use. The
> dependancies are only considered after the decision has
> been irrevocably made. If the dependancies don't hold, the
>I pointed out that the type system _may already_ not terminate
I agree, I have made it not terminate myself with undecidable-instances,
I also think prolog style backtacking would be a good idea... I think I said
that you either want full backtracking or you want to leave it how it is
(with depe
On 21/05/2004, at 8:06 AM, MR K P SCHUPKE wrote:
I pointed out that the type system _may already_ not terminate
I agree, I have made it not terminate myself with
undecidable-instances,
I also think prolog style backtacking would be a good idea...
For what it's worth, I'll AOL this ("me too"). I k
| > I agree, I have made it not terminate myself with
| > undecidable-instances,
| > I also think prolog style backtacking would be a good idea...
|
| For what it's worth, I'll AOL this ("me too"). I know that for the
| area of Haskell I'm exploring (integrating it with OO languages),
| putting b
I have seen very compact Prolog implementations in Haskell, and I
also know that constraints, modelled by CHRs can be evaluated directly
in Prolog. Why not just bolt one of these compact Prologs onto the
compiler, and just feed it the facts and rules...
Keean.
On Thu, May 20, 2004 at 11:06:44PM +0100, MR K P SCHUPKE wrote:
> I agree, I have made it not terminate myself with undecidable-instances,
Congratulations. ;-)
> I also think prolog style backtacking would be a good idea... I think I said
> that you either want full backtracking or you want to
On Fri, May 21, 2004 at 11:04:53AM +0100, Simon Peyton-Jones wrote:
> Nothing difficult in principle, but the constraint solver is one of
> the more delicate parts of GHC because GHC's constraint language has
> become so complex.
Well, as my day job is working for a constraints lab, I feel it's my
23 matches
Mail list logo
