- Haskell would need to be a lot more specific about exactly where
context reduction takes place. Consider
f xs x = xs == [x]
Do we infer the type (Eq a) => [a] -> a -> Bool? Thereby committing to
a particular choice of instance? Or do we (as GHC does) infer the type
(Eq [a]) => [a] -> a -> Boo
there were a couple of issues Simon raised that I hadn't responded to in
my earlier reply. since no-one else has taken them on so far, either, ..
- Haskell would need to be a lot more specific about exactly where
context reduction takes place. Consider
f xs x = xs == [x]
Do we infer the type (
Ben Rudiak-Gould wrote:
I think all of these problems would go away if overlap was permitted
within a module but forbidden across modules. Are there uses of
overlapping instances for which this isn't flexible enough?
I dislike this on principle. I like the idea that modules can be
refactored
Hello Ben,
Wednesday, March 1, 2006, 6:23:00 PM, you wrote:
>> instance (Show a) => IsXML a where
>> toXML = toXML . show
>>
>> The intention of the latter is to be a default instance unless another
>> instance is specified.
BRG> I can see how this is useful, but I'm surprised that it's robust
Niklas Broberg wrote:
Ben Rudiak-Gould wrote:
Are there uses of overlapping
instances for which this isn't flexible enough?
Certainly!
Hmm... well, what about at least permitting intra-module overlap in Haskell'
(and in GHC without -foverlapping-instances)? It's good enough for many
things
Claus Reinke wrote:
> most of us would be happy if instance contexts
> would be required to uniquely determine the instance to be
> chosen, a rather conservative extension of current practice.
I'm not so sure about the "most of us", as you note yourself the
defaulting pattern is quite popular (and
On 2/28/06, Ben Rudiak-Gould <[EMAIL PROTECTED]> wrote:
> Simon Peyton-Jones wrote:
> > - A program that type checks can have its meaning changed by adding an
> > instance declaration
> >
> > - Similarly adding "import M()" can change the meaning of a program (by
> > changing which instances are vi
Claus Reinke wrote:
most of us would be happy if instance contexts
would be required to uniquely determine the instance to be
chosen, a rather conservative extension of current practice.
How would that work? There's no way to prove that
instance (Num a) => Foo a where ...
instance Foo
Simon Peyton-Jones wrote:
- A program that type checks can have its meaning changed by adding an
instance declaration
- Similarly adding "import M()" can change the meaning of a program (by
changing which instances are visible
- Haskell would need to be a lot more specific about exactly where
c
both hugs and ghc clearly specify that the more specific instance
declaration is chosen when overlapping instance declarations are
permitted.
I have trouble with this "more specific" term. It's not well-defined,
i.e. not a total order on possible instance declarations.
The point I was trying t
On 2/28/06, Claus Reinke <[EMAIL PROTECTED]> wrote:
> I'm not sure what you're talking about? both hugs and ghc clearly
> specify that the more specific instance declaration is chosen when
> overlapping instance declarations are permitted.
I have trouble with this "more specific" term. It's not we
Tuesday, February 28, 2006, 1:54:25 PM, you wrote:
CR> class NEq a b
CR> instance Fail a => NEq a a
CR> instance NEq a b
i think that this definition just use ad-hoc overlapping instances
resolution mechanism that we want to avoid :)))
I don't want to avoid it completely, I want to
On 2/28/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> Tuesday, February 28, 2006, 1:54:25 PM, you wrote:
> CR> class NEq a b
> CR> instance Fail a => NEq a a
> CR> instance NEq a b
>
> i think that this definition just use ad-hoc overlapping instances
> resolution mechanism that we w
Hello Claus,
Tuesday, February 28, 2006, 1:54:25 PM, you wrote:
CR> class NEq a b
CR> instance Fail a => NEq a a
CR> instance NEq a b
i think that this definition just use ad-hoc overlapping instances
resolution mechanism that we want to avoid :)))
--
Best regards,
Bulat
instance C2 a b | a/=b
I was thinking it would be all kinds of useful if we had two predefined
classes
class Eq a b
class NEq a b
where Eq has instances exactly when its two types are equal and NEq has
instances exactly when its two types are not equal.
class Eq a b
instance Eq a a
Hello John,
Tuesday, February 28, 2006, 4:23:24 AM, you wrote:
>> i had plans to propose the same and even more:
>>
>> instance C2 a b | a/=b
JM> I was thinking it would be all kinds of useful if we had two predefined
JM> classes
JM> class Eq a b
JM> class NEq a b
JM> where Eq has instances e
Check out Section 8.1. in
P. J. Stuckey and M. Sulzmann. A theory of overloading. ACM Transactions on
Programming Languages and Systems (TOPLAS), 27(6):1-54, 2005.
for how to use disequality constraints to "resolve" overlapping
instances.
BTW, the translation scheme in the above paper employs
On Mon, Feb 27, 2006 at 05:09:30PM +0300, Bulat Ziganshin wrote:
> i had plans to propose the same and even more:
>
> instance C2 a b | a/=b
I was thinking it would be all kinds of useful if we had two predefined
classes
class Eq a b
class NEq a b
where Eq has instances exactly when its two typ
Hello Claus,
Monday, February 27, 2006, 4:10:00 PM, you wrote:
CR> class C a where c :: a -> String
CR> instance C [a] | a/=Char where c as = .. -- dealing with most lists
CR> instance C Stringwhere c s = .. -- special case for
strings
i had plans to propose t
[
I'll only address some of your issues in this message, as they fall nicely
under the use of a feature I'd like to see anyway:
type disequality constraints
]
- A program that type checks can have its meaning changed by adding an
instance declaration
- Similarly adding "import M()" can ch
- it really helps in
debugging the dark corners.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Claus Reinke
| Sent: 26 February 2006 16:28
| To: haskell-prime@haskell.org
| Subject: overlapping instances and constraints
|
|
| the point ab
the point about overlapping instances is that they shouldn't,
so we are looking for ways to resolve what looks like overlaps
unambiguously, so that there are no overlapping instances left.
we don't want overlapping instances in the language definition,
but we do want more expressive means of d
22 matches
Mail list logo
