Hi folks I realise I should have been paying more attention last March, and as such have no reason to expect any sympathy, let alone action. I would, however, like to comment on the fact that the Data.Monoid instance for (Maybe x) prioritises monoidal structure from x over monoidal structure from Maybe. This makes it hard to use generic monoidal operations to support choice in the Maybe monad. I don't know if this breaks anybody else's code, but it certainly breaks mine. I guess I'll just have to stop using Data.Monoid and roll my own. That's not a serious hardship, I suppose. I have only myself to blame, and I'm not proposing that the Maybe behaviour is changed. I suppose people are busy enjoying the instance as it now stands, and that it would be damaging to change. What a pity Conor http://www.cs.nott.ac.uk/~ctm This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
ctm:
Hi folks
I realise I should have been paying more attention last March, and as such have no reason to expect any sympathy, let alone action.
I would, however, like to comment on the fact that the Data.Monoid instance for (Maybe x) prioritises monoidal structure from x over monoidal structure from Maybe. This makes it hard to use generic monoidal operations to support choice in the Maybe monad.
I don't know if this breaks anybody else's code, but it certainly breaks mine. I guess I'll just have to stop using Data.Monoid and roll my own. That's not a serious hardship, I suppose.
The Monoid instance is not that widely used -- I think it is not too late to change. You could propose correcting it, with some examples of why it is more flexible -- Don
Hi Don On 29 Nov 2007, at 18:37, Don Stewart wrote:
ctm:
I don't know if this breaks anybody else's code, but it certainly breaks mine. I guess I'll just have to stop using Data.Monoid and roll my own. That's not a serious hardship, I suppose.
The Monoid instance is not that widely used -- I think it is not too late to change. You could propose correcting it, with some examples of why it is more flexible
I've had a little think and this really pulls at a bigger bit of fabric. I'll try to make some sense locally in the next few days, but changing jobs may distract me. I'm heartened. Many thanks Conor
Don Stewart wrote:
The Monoid instance is not that widely used -- I think it is not too late to change.
If this sort of thing is fixable retrospectively then maybe the Monoid instance for Data.Map should be fixed too.. http://hackage.haskell.org/trac/ghc/ticket/1460 ..assuming there's general agreement that the current instance is broken. The latter definition is what's used in the "clone" I wrote BTW, so they're incompatible at the moment as far as this is concerned. Regards -- Adrian Hey
Jeremy Shaw and I had a bunch of conversations about this kind of thing, almost always ending with Jeremy citing this story. I found it at: http://www.oreillynet.com/xml/blog/2002/11/whats_wrong_with_rdf.html <famous-anecdote>Stuart Feldman, the Bell Labs guy who invented "make", woke
up one morning a few weeks after he'd released it, and realized that the syntax basically sucked - all those tabs and colons and weird continuation rules. He started working on something better and was shot down because someone said "Stuart, there are *dozens* of people using this, it's too late to change it."</famous-anecdote>
Please publish your alternative implementation in a blog or in a package on
Haskell. Think of all the children that will be spared in the future.
Cliff
On Nov 29, 2007 10:29 AM, Conor McBride
Hi folks
I realise I should have been paying more attention last March, and as such have no reason to expect any sympathy, let alone action.
I would, however, like to comment on the fact that the Data.Monoid instance for (Maybe x) prioritises monoidal structure from x over monoidal structure from Maybe. This makes it hard to use generic monoidal operations to support choice in the Maybe monad.
I don't know if this breaks anybody else's code, but it certainly breaks mine. I guess I'll just have to stop using Data.Monoid and roll my own. That's not a serious hardship, I suppose.
I have only myself to blame, and I'm not proposing that the Maybe behaviour is changed. I suppose people are busy enjoying the instance as it now stands, and that it would be damaging to change.
What a pity
Conor
http://www.cs.nott.ac.uk/~ctm http://www.cs.nott.ac.uk/%7Ectm
This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On 2007-11-29, Clifford Beshers
Jeremy Shaw and I had a bunch of conversations about this kind of thing, almost always ending with Jeremy citing this story. I found it at: http://www.oreillynet.com/xml/blog/2002/11/whats_wrong_with_rdf.html
<famous-anecdote>Stuart Feldman, the Bell Labs guy who invented "make", woke
up one morning a few weeks after he'd released it, and realized that the syntax basically sucked - all those tabs and colons and weird continuation rules. He started working on something better and was shot down because someone said "Stuart, there are *dozens* of people using this, it's too late to change it."</famous-anecdote>
Please publish your alternative implementation in a blog or in a package on Haskell. Think of all the children that will be spared in the future.
This is also said to be why C's precedence rules for logical operators aren't quite right. We're still at the stage where this is fixable. -- Aaron Denney -><-
participants (5)
-
Aaron Denney -
Adrian Hey -
Clifford Beshers -
Conor McBride -
Don Stewart