Andrew Coppin wrote:
Seriously, that sounded like gibberish.
Please don't say that.
I think we are too polite to rudeness.
While we shouldn't condemn people to RTFM, we shouldn't tolerate
people calling us gibberish either. I mean unless we say something
objectively gibberish.
On Sat, Sep 27, 2008 at 9:24 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
David Menendez wrote:
I wouldn't say that. It's important to remember that Haskell class
Monad does not, and can not, represent *all* monads, only (strong)
monads built on a functor from the category of Haskell types and
David Menendez wrote:
I wouldn't say that. It's important to remember that Haskell class
Monad does not, and can not, represent *all* monads, only (strong)
monads built on a functor from the category of Haskell types and
functions to itself.
Data.Set is a functor from the category of Haskell
On 2008 Sep 27, at 9:24, Andrew Coppin wrote:
David Menendez wrote:
I wouldn't say that. It's important to remember that Haskell class
Monad does not, and can not, represent *all* monads, only (strong)
monads built on a functor from the category of Haskell types and
functions to itself.
On 2008 Sep 27, at 12:41, Andrew Coppin wrote:
I'm not sure how that qualifies set as not really a true monad
anyway - but then, I don't know what a monad is, originally. I only
know what it means in Haskell.
I think you read him backwards: Map and Set are category-theory
(true) monads,
Brandon S. Allbery KF8NH wrote:
On 2008 Sep 27, at 12:41, Andrew Coppin wrote:
I'm not sure how that qualifies set as not really a true monad
anyway - but then, I don't know what a monad is, originally. I only
know what it means in Haskell.
I think you read him backwards: Map and Set are
Albert Y. C. Lai wrote:
Andrew Coppin wrote:
If I understand this correctly, to solve this problem you need either
Functional Dependencies or Associated Types. Is that correct?
A motivating example in papers on FD is exactly typeclasses for
containers. Okasaki puts this into practice in the
On Sat, Sep 27, 2008 at 12:23 PM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Can anybody actually demonstrate concretely how FDs and/or ATs would solve
this problem? (I.e., enable you to write a class that any container can be a
member of, despite constraints on the element types.)
Sure! Using
Le 27 sept. 08 à 15:24, Andrew Coppin a écrit :
David Menendez wrote:
I wouldn't say that. It's important to remember that Haskell class
Monad does not, and can not, represent *all* monads, only (strong)
monads built on a functor from the category of Haskell types and
functions to itself.
Hello Andrew,
Saturday, September 27, 2008, 9:23:47 PM, you wrote:
Can anybody actually demonstrate concretely how FDs and/or ATs would
solve this problem? (I.e., enable you to write a class that any
container can be a member of, despite constraints on the element types.)
you may find
I'm not actually bothered about every possible monad being representable
as such in Haskell. I'd just like Set to work. ;-)
What would work mean in this case? I see two different meanings:
1. Use monadic operations (mapM, guard) on Sets.
How would you decide which operations are allowed and
Take a look around you. Haskell provides several sorts of container. We
have:
Data.List
Data.Set
Data.Map
Data.Hashtable
Data.ByteString
Data.Sequence
Data.Array
Data.Tree
Data.IntSet
Data.IntMap
...
In other words, we have *a lot* of different data containers. And yet,
each one
Andrew Coppin wrote:
If I understand this correctly, to solve this problem you need either
Functional Dependencies or Associated Types. Is that correct?
A motivating example in papers on FD is exactly typeclasses for
containers. Okasaki puts this into practice in the Edison library.
Despite
On Fri, 2008-09-26 at 19:15 +0100, Andrew Coppin wrote:
Take a look around you. Haskell provides several sorts of container. We
have:
Data.List
Data.Set
Data.Map
Data.Hashtable
Data.ByteString
Data.Sequence
Data.Array
Data.Tree
Data.IntSet
Data.IntMap
...
Derek Elkins wrote:
One aspect of it is a bit of a You Aren't Going To Need It.
Personally, I haven't had a huge problem with this in practice.
What it basically means is that if you write a library function, *you*
have to decide what containers you're going to use. It's not really
On Fri, Sep 26, 2008 at 5:37 PM, Andrew Coppin
[EMAIL PROTECTED] wrote:
As already noted, Data.Set *should* be a Monad, but can't be. The type
system won't allow it. (And I know I'm not the first person to notice
this...)
I wouldn't say that. It's important to remember that Haskell class
Can someone explain, why is it that Set can not be a Monad?
--
_jsn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Fri, 2008-09-26 at 15:25 -0700, Jason Dusek wrote:
Can someone explain, why is it that Set can not be a Monad?
It can't even be a functor (which all monads are). You can't implement
fmap (+) $ Set.fromList [1, 2, 3]
with Data.Set, because you can't order functions of type Integer -
Hello Andrew,
Saturday, September 27, 2008, 1:37:12 AM, you wrote:
answering your questions
1) there is 2 libs providing common Java-like interfaces to
containers: Edison and Collections. almost noone uses it
2) having common type class for various things is most important when
you write
More specifically, although a set is a perfectly good (lowercase)
functor, Set is not a (Haskell) Functor.
Set's map has an Ord constraint, but the Functor type constructor is
parametric over *all* types, not just that proper subset of them that
have a total ordering.
But see attempts to
bulat.ziganshin:
Hello Andrew,
Saturday, September 27, 2008, 1:37:12 AM, you wrote:
answering your questions
1) there is 2 libs providing common Java-like interfaces to
containers: Edison and Collections. almost noone uses it
2) having common type class for various things is most
On Fri, 2008-09-26 at 22:37 +0100, Andrew Coppin wrote:
Derek Elkins wrote:
One aspect of it is a bit of a You Aren't Going To Need It.
Personally, I haven't had a huge problem with this in practice.
I suspected as much. Personally I'd recomend worrying about the
problems you actually
22 matches
Mail list logo
