[Haskell-cafe] Documentation [Comments from OCaml Hacker Brian Hurt]

2009-01-16 Thread Andrew Coppin

Anton van Straaten wrote:
It probably makes sense to do as Jeremy Shaw suggests and explicitly 
list the monoid laws, which would include the associative equality, 
but there really shouldn't be any other text in the definition of 
Monoid devoted to explaining what associativity means.  Instead, 
linking words like "associative" to a definition in a glossary would 
make sense.


I don't know - associativity is almost the only property a monoid has. 
(Obviously the other one is an identity element.)


Either way, wherever the description gets put, just saying 
"associativity means that (x + y) + z = x + (y + z)" is insufficient. 
Sure, that's the *definition* of what it is, but we should point out 
that "associativity means that the ordering of the operations does not 
affect the result" or something. Something that's intuitive. (The tricky 
part, of course, is explaining how associative /= commutative.)


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


Re: [Haskell-cafe] Documentation [Comments from OCaml Hacker Brian Hurt]

2009-01-16 Thread Paul Moore
2009/1/16 Andrew Coppin :
> Either way, wherever the description gets put, just saying "associativity
> means that (x + y) + z = x + (y + z)" is insufficient. Sure, that's the
> *definition* of what it is, but we should point out that "associativity
> means that the ordering of the operations does not affect the result" or
> something. Something that's intuitive. (The tricky part, of course, is
> explaining how associative /= commutative.)

How about "associativity means that how you pair up the operations
does not affect the result"?

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


Re: [Haskell-cafe] Documentation [Comments from OCaml Hacker Brian Hurt]

2009-01-16 Thread Dan Piponi
On Fri, Jan 16, 2009 at 12:09 PM, Paul Moore  wrote:

> How about "associativity means that how you pair up the operations
> does not affect the result"?

I think a better way is this: If you have an element of a monoid, a,
there are two ways to combine it with another element, on the left or
on the right. You get

a `mappend` x
or
x `mappend` a.

Now suppose you're going to combine a with x on the left and y on the
right. Associativity means it doesn't matter which you do first.

You can think of each element of a monoid as having two sides. The
idea is that the left side and right side are independent things that
don't interfere with each other. For example, adding some stuff at the
beginning of a list, and adding some stuff at the end of a list, don't
affect each other, and it doesn't matter which you do first.

That's the idea that associativity captures.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Documentation [Comments from OCaml Hacker Brian Hurt]

2009-01-16 Thread Cory Knapp

Dan Piponi wrote:

On Fri, Jan 16, 2009 at 12:09 PM, Paul Moore  wrote:

  

How about "associativity means that how you pair up the operations
does not affect the result"?



I think a better way is this: If you have an element of a monoid, a,
there are two ways to combine it with another element, on the left or
on the right. You get

a `mappend` x
or
x `mappend` a.

Now suppose you're going to combine a with x on the left and y on the
right. Associativity means it doesn't matter which you do first.

You can think of each element of a monoid as having two sides. The
idea is that the left side and right side are independent things that
don't interfere with each other. For example, adding some stuff at the
beginning of a list, and adding some stuff at the end of a list, don't
affect each other, and it doesn't matter which you do first.

That's the idea that associativity captures.
--
Dan
  
Indeed, that's the idea that associativity captures; but explicitly 
pointing out that the left and the right side are their own bubbles is a 
bit misleading: addition is associative, but there is no "left and 
right." I think a better wording is:


"
If you have an element of a monoid, a, there are two ways to combine it 
with another element, on the left or on the right. You get


a `mappend` x
or
x `mappend` a.

Now suppose you're going to combine a with x on the left and y on the
right. Associativity means it doesn't matter which you do first.

So
x `mappend` (a `mappend` y) = (x `mappend` a) `mappend` y, but as we've 
pointed out,

a `mappend` x
is not necessarily the same as
x `mappend` a
although a specific monoid might have them be equal, for example Int 
(where mappend is *).



Is that better?

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