Eq Type Class: Overloading (==) - Haskell-Cafe - Haskell.org

newer
Dread __DISCARD__

Eq Type Class: Overloading (==)

older
Nofib documentation

Tom Hawkins

16 Sep 2005 16 Sep '05

10:59 p.m.

Hello, Is it possible to overload (==) to a type other than a -> a -> Bool? I have an abstract datatype that somewhat behaves like a C integer: a comparison returns a boolean represented as the same datatype: (==) :: my_type -> my_type -> my_type Thanks for any help! -Tom

Reply

Sign in to reply online Use email software

Show replies by date

ChrisK

17 Sep 17 Sep

12:27 a.m.

You would have to preempt the Standard Prelude. For ghc there is a command line switch I have neer used: -fno-implicit-prelude See section 7.3.5 in the GHC user's guide for more. There are some internal caveats: "However, the standard Prelude Eq class is still used for the equality test necessary for literal patterns." Tom Hawkins wrote:

Hello,

Is it possible to overload (==) to a type other than a -> a -> Bool?

I have an abstract datatype that somewhat behaves like a C integer: a comparison returns a boolean represented as the same datatype:

(==) :: my_type -> my_type -> my_type

Thanks for any help!

-Tom

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply

Sign in to reply online Use email software

Cale Gibbard

1:13 a.m.

On 16/09/05, Tom Hawkins wrote:

Hello,

Is it possible to overload (==) to a type other than a -> a -> Bool?

I have an abstract datatype that somewhat behaves like a C integer: a comparison returns a boolean represented as the same datatype:

(==) :: my_type -> my_type -> my_type

Thanks for any help!

-Tom

You largely wouldn't want to -- the thing that makes the usual type for (==) useful is that lots of functions make use of the Bool result with if/then/else. If you change the Eq typeclass, then a large chunk of the standard library is going to break, and it won't be all that easy to correct, because if-then-else-expressions all expect a Bool. You'd want to add a typeclass for boolean-interpretable values, and fix up ghc to use it with if-expressions. Haskell doesn't use ad-hoc polymorphism, so you're out of luck if you want to keep the usual equality test around and have it overlap with your function of another type. Further, there wouldn't be much point to that kind of polymorphism, since functions requiring (==) to give a Boolean result would simply break, and that would be nearly all of them. You can of course give the new kind of comparison another name though. (===) isn't taken, for instance. You can even develop a similar typeclass around it if you like. (Look how Eq is written in the prelude.) It may also be useful to have a function around which projects one of your values down to a Bool. If you want to do that generically, you may also want a class method which does that. Here's an example of the sort of class you might want. class Equative t where (===) :: t -> t -> t isTrue :: t -> Bool isFalse :: t -> Bool -- Minimal complete definition: (===) and one of isTrue or isFalse. isFalse = not . isTrue isTrue = not . isFalse hope this helps, - Cale

Reply

Sign in to reply online Use email software

Jason Dagit

2:14 a.m.

On Sep 16, 2005, at 10:13 PM, Cale Gibbard wrote:

On 16/09/05, Tom Hawkins wrote:

...
Hello,

Is it possible to overload (==) to a type other than a -> a -> Bool?

I have an abstract datatype that somewhat behaves like a C integer: a comparison returns a boolean represented as the same datatype:

(==) :: my_type -> my_type -> my_type

Thanks for any help!

-Tom

You largely wouldn't want to -- the thing that makes the usual type for (==) useful is that lots of functions make use of the Bool result with if/then/else. If you change the Eq typeclass, then a large chunk of the standard library is going to break, and it won't be all that easy to correct, because if-then-else-expressions all expect a Bool. You'd want to add a typeclass for boolean-interpretable values, and fix up ghc to use it with if-expressions.

This reminds me that several times now I've wished that Bool was some sort of interface instead of a type. Perhaps Bool could be a type class? I also wish that "if" were a function, but that's probably just the lisper in me speaking. Something like: if :: Bool b => b -> a -> a-> a I guess my biggest reason for this is purely convenience, and I wonder if this would just weaken the type system. Say for example, instance Bool Int where true = not false false = 0 -- probably need definitions of and, or, not -- it may also be useful to have things like isTrue and isFalse Then you could do things like: if 1 then x else y And we all know that's not the best thing to have around. Although, I'm not sure if this is a strong argument not have a Bool type class. After all, lists can be turned into Nums and that's odd in subtle ways as far as detecting common typos is concerned. http://haskell.org/hawiki/CodeExamples#head- c926349e876dca4d1324036fe67a6eb1fe7afb3c If you use that code then (0:1) becomes valid even though it would normally be a type error. Just some stuff to think about. Thanks, Jason

Reply

Sign in to reply online Use email software

Bulat Ziganshin

4:43 a.m.

New subject: Re[2]: Eq Type Class: Overloading (==)

Hello Jason, Saturday, September 17, 2005, 10:14:14 AM, you wrote: JD> class? I also wish that "if" were a function, but that's probably JD> just the lisper in me speaking. Something like:

if :: Bool b =>> b -> a -> a-> a

no problem! iif :: Bool -> a -> a -> a iif a b c = if a then b else c anyway, Haskell use lazy evaluation ;) really, i developed a lot of control structures for I/O monad about making Bool a class - it is the same issue as making head/map/... belonging to some Collection class. we need to change standard Prelude or add to Haskell "supertyping" mechanism, proposed by John Meacham, as i remember -- Best regards, Bulat mailto:bulatz@HotPOP.com

Reply

Sign in to reply online Use email software

Jason Dagit

3:36 p.m.

New subject: Re[2]: Eq Type Class: Overloading (==)

On Sep 17, 2005, at 1:43 AM, Bulat Ziganshin wrote:

about making Bool a class - it is the same issue as making head/map/... belonging to some Collection class. we need to change standard Prelude or add to Haskell "supertyping" mechanism, proposed by John Meacham, as i remember

A link to supertyping can be found here: http://repetae.net/john/recent/out/supertyping.html After reading that, I wonder why it's not implemented. It seems like a wonderfully useful idea. I view it as a way to add things back to the language which should have been there to begin with, but which the language designers left out for various reasons (such as lack of time, interest or possibly even oversight). Thanks, Jason

Reply

Sign in to reply online Use email software

Aaron Denney

4:07 p.m.

New subject: Re[2]: Eq Type Class: Overloading (==)

On 2005-09-17, Jason Dagit wrote:

On Sep 17, 2005, at 1:43 AM, Bulat Ziganshin wrote:

...
about making Bool a class - it is the same issue as making head/map/... belonging to some Collection class. we need to change standard Prelude or add to Haskell "supertyping" mechanism, proposed by John Meacham, as i remember

A link to supertyping can be found here: http://repetae.net/john/recent/out/supertyping.html

After reading that, I wonder why it's not implemented.

Not enough people calling for it.

It seems like a wonderfully useful idea.

It is. It would be terribly useful for those trying to prototype a new Prelude, and clean up the mathematical structures. -- Aaron Denney -><-

Reply

Sign in to reply online Use email software

Tom Hawkins

18 Sep 18 Sep

7:59 a.m.

Aaron Denney wrote:

On 2005-09-17, Jason Dagit wrote:

...
A link to supertyping can be found here: http://repetae.net/john/recent/out/supertyping.html

After reading that, I wonder why it's not implemented.

Not enough people calling for it.

...
It seems like a wonderfully useful idea.

It is. It would be terribly useful for those trying to prototype a new Prelude, and clean up the mathematical structures.

I like the idea of supertyping, but wouldn't that only allow you to alter identifiers that were already classified? What about functions in the Prelude that don't belong to a type class? For instance, I have a datatype that needs an append-like operation, yet it appears (++) is reserved only for lists. I recently switched to Haskell from OCaml because I thought type classes may solve one of my problems. I'm building an embedded language, which has a lot of the basic operations. In OCaml I was forced to invent all sort of obscure operator names for the embedded language so as not to collide with the standard library. But with Haskell's Num class, I have been able to reuse (+), (-), and (*). However, (==) and (++) are still sticking points. My general impression of Haskell is good, though it seems you're somewhat locked-in by how the upper levels of the class hierarchy are defined in the Prelude, or when the Prelude does not type class generic operator names such as (++). Again, I just stared programming Haskell. Please let me know if I'm missing something. Thanks! -Tom

Reply

Sign in to reply online Use email software

Robert Dockins

7:15 p.m.

On Sunday 18 September 2005 07:59 am, Tom Hawkins wrote:

Aaron Denney wrote:

...
On 2005-09-17, Jason Dagit wrote:

...
A link to supertyping can be found here: http://repetae.net/john/recent/out/supertyping.html

After reading that, I wonder why it's not implemented.

Not enough people calling for it.

...
It seems like a wonderfully useful idea.

It is. It would be terribly useful for those trying to prototype a new Prelude, and clean up the mathematical structures.

I like the idea of supertyping, but wouldn't that only allow you to alter identifiers that were already classified? What about functions in the Prelude that don't belong to a type class?

For instance, I have a datatype that needs an append-like operation, yet it appears (++) is reserved only for lists.

I recently switched to Haskell from OCaml because I thought type classes may solve one of my problems. I'm building an embedded language, which has a lot of the basic operations. In OCaml I was forced to invent all sort of obscure operator names for the embedded language so as not to collide with the standard library.

But with Haskell's Num class, I have been able to reuse (+), (-), and (*). However, (==) and (++) are still sticking points. My general impression of Haskell is good, though it seems you're somewhat locked-in by how the upper levels of the class hierarchy are defined in the Prelude, or when the Prelude does not type class generic operator names such as (++).

Again, I just stared programming Haskell. Please let me know if I'm missing something.

One possible solution for DSLs is to import the Prelude qualified, or with a hiding clause. That allows you to redefine most of the symbols in the Prelude, but still use the Prelude ones if needed. (==) is still a little special because the Prelude (==) is used for some desugaring steps.

Reply

Sign in to reply online Use email software

Aaron Denney

8:36 p.m.

On 2005-09-18, Tom Hawkins wrote:

I like the idea of supertyping, but wouldn't that only allow you to alter identifiers that were already classified?

Correct.

What about functions in the Prelude that don't belong to a type class?

Nope. -- Aaron Denney -><-

Reply

Sign in to reply online Use email software

John Meacham

8:28 p.m.

New subject: Re[2]: Eq Type Class: Overloading (==)

On Sat, Sep 17, 2005 at 12:36:06PM -0700, Jason Dagit wrote:

On Sep 17, 2005, at 1:43 AM, Bulat Ziganshin wrote:

...
about making Bool a class - it is the same issue as making head/map/... belonging to some Collection class. we need to change standard Prelude or add to Haskell "supertyping" mechanism, proposed by John Meacham, as i remember

A link to supertyping can be found here: http://repetae.net/john/recent/out/supertyping.html

After reading that, I wonder why it's not implemented. It seems like a wonderfully useful idea. I view it as a way to add things back to the language which should have been there to begin with, but which the language designers left out for various reasons (such as lack of time, interest or possibly even oversight).

I actually have some misgivings about the design I stated there and would have some tweaks I would like to do before it was actually implemented, but I definitly think we need more flexible ways to deal with class hierachies (in some form). my main concern is that class Eq a => Ord a where class Ord a <= Eq a where are not fully symmetric. the second lets you just declare things as Ord without worrying about Eq, the first doesn't. I think these issues can be worked out once a concrete implementation is being worked on, which I hope to do for jhc. John -- John Meacham - ⑆repetae.net⑆john⑈

Reply

Sign in to reply online Use email software

David Menendez

17 Sep 17 Sep

2:47 p.m.

Jason Dagit writes:

This reminds me that several times now I've wished that Bool was some sort of interface instead of a type. Perhaps Bool could be a type class? I also wish that "if" were a function, but that's probably just the lisper in me speaking. Something like:

John Meacham has a library that implements a BooleanAlgebra type class. http://repetae.net/john/recent/out/Boolean.html -- David Menendez | "In this house, we obey the laws http://www.eyrie.org/~zednenem | of thermodynamics!"

Reply

Sign in to reply online Use email software

John Meacham

18 Sep 18 Sep

8:22 p.m.

On Fri, Sep 16, 2005 at 11:14:14PM -0700, Jason Dagit wrote:

This reminds me that several times now I've wished that Bool was some sort of interface instead of a type. Perhaps Bool could be a type class? I also wish that "if" were a function, but that's probably just the lisper in me speaking. Something like:

See my Boolean.Algebra module. it lets you declare types to be boolean algebras (or lift an arbitrary type to such an algebra) and provides a lot of useful functions on them. although, it sometimes feels like it should be a general lattice class. http://repetae.net/john/recent/out/Boolean.html darcs repo: http://repetae.net/john/repos/Boolean some examples of where I have used this are. in ginsu you can have filters to choose which messages to see. I just created the basic regex filter and lifted it to a full boolean alegbra on them with Boolean.Boolean. In jhc I accumulate various properties of programs with generic routines that accumulate arbitrary types of class boolean. "fuzzy" booleans implemented as doubles have found their way into some projects. and some other places... John -- John Meacham - ⑆repetae.net⑆john⑈

Reply

Sign in to reply online Use email software

7183

Age (days ago)

7185

Last active (days ago)

Download

12 comments

9 participants

tags

participants (9)

Aaron Denney
Bulat Ziganshin
Cale Gibbard
ChrisK
David Menendez
Jason Dagit
John Meacham
Robert Dockins
Tom Hawkins