Claus Reinke wrote:
You might find this interesting:
@inproceedings{ fokker95explaining,
author = "Jeroen Fokker",
title = "Explaining Algebraic Theory with Functional Programs",
booktitle = "Functional Programming Languages in Education",
pages = "139-158",
year = "1995",
url = "citeseer.ist.psu.edu/fokker95explaining.html" }
Extremely interesting, thank you. It also contains a very interesting
remark (on p. 2), noting that one should have
class Eq a => Monoid a where
(<+>) :: a -> a -> a
zero ::a
And states "Because in the laws the notion of equality is used, we
have made Monoid a subclass of Eq". In hindsight, this is obvious, but
is naively tempting to define a monoid without this constraint. And,
indeed, Data.Monoid defines a Monoid class without an Eq constraint!
So, what are monoids without equality in Haskell? There are rather
interesting beasts: they are monoids for which we have a computable 0
(mempty) and a computable addition (mappend), but for which we cannot
*witness* equality of the underlying carrier 'set'. This, for example,
is the only way one can legitimately get an instance such as
instance Monoid b => Monoid (a->b)
While Haskell is used quite a lot for doing computable (or
'extensional') mathematics, intensionality sneaks in here and there --
and this is just one such example.
I must admit, I actually don't yet know whether I prefer classical
monoids or these generalized monoids where the laws are _purely_
intensional. Opinions?
Jacques
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
