
1 ...
45678910
... 12

On Fri, 20090116 at 14:16 +0100, david48 wrote:
> Upon reading this thread, I asked myself : what's a monoid ? I had no
> idea. I read some posts, then google "haskell monoid".
>
> The first link leads me to Data.Monoid which starts with
>
> <<
> Description
> The Monoid class with various generalpurpose instances.
>
> Inspired by the paper /Functional Programming with Overloading and
> HigherOrder Polymorphism/, Mark P Jones
> ( http://citeseer.ist.psu.edu/jones95functional.html) Advanced School
> of Functional Programming, 1995.
> >>
Ross just updated the documentation for the Monoid module. Here is how
it reads now:
The module header now reads simply:
A class for monoids (types with an associative binary operation
that has an identity) with various generalpurpose instances.
Note, no links to papers.
And the Monoid class has:
The class of monoids (types with an associative binary operation
that has an identity). The method names refer to the monoid of
lists, but there are many other instances.
Minimal complete definition: 'mempty' and 'mappend'.
Some types can be viewed as a monoid in more than one way, e.g.
both addition and multiplication on numbers. In such cases we
often define @newtype@s and make those instances of 'Monoid',
e.g. 'Sum' and 'Product'.
If you or anyone else has further concrete suggestions / improvements
then post them here now! :)
Duncan
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Thu, 15 Jan 2009, Andrew Coppin wrote:
> I was especially amused by the assertion that "existential quantification" is
> a more precise term than "type variable hiding". (The former doesn't even tell
> you that the feature in question is related to the type system! Even the few
> people in my poll who knew of the term couldn't figure out how it might be
> related to Haskell. And one guy argued that "forall" should denote universal
> rather than existential quantification...)
This one's a particularly awkward special case. The original syntax for
writing existential quantifications had looking like existing datatype
declarations as a major goal, and this turned out to be just the wrong
thing  GADTs made this rather more clear, and with the new syntax it
should be much easier to explain why the forall keyword ends up meaning
that. The first word that comes to mind for the old syntax... well, starts
with an F. These things happen when you use research concepts though, and
I can't see how at the time anyone could have been expected to do any
better.
As for "what's it got to do with types?"  well, that's a CurryHoward
thing. If I ever find myself in the situation of documenting a typed FPL
for ordinary programmers, briefly explaining the relationship between type
systems and logics is going to happen very early on indeed!

[hidden email]
There is no magic bullet. There are, however, plenty of bullets that
magically home in on feet when not used in exactly the right circumstances.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


Ketil Malde <ketil <at> malde.org> writes:
>
> On Thu, Jan 15, 2009 at 07:46:02PM +0000, Andrew Coppin wrote:
>
> > If we *must* insist on using the most obscure possible name for
> > everything,
>
> I don't think anybody even suggests using obscure names. Some people
> insist on precise names.
>
Ketil, to second your here: "Appendable" *is* an obscure name! Even more
than Monoid.
I remember my early CS algebra courses. I met cool animals there: Group,
Ring, Vector Space. Those beasts were very strong, but also very calm at
the same time. Although I was a bit shy at first, after some work we
became friends.
When I first saw Monad, Monoid, Functor and others, I wasn't scared.
They must be from the same zoo as my old friends! Some work is needed
to establish a connection, but it is doable. And it is very rewarding,
because then you get very powerful, dependable friends that give you
strong guaranties!
Now compare ICollecion, IAppendable or the alike. These are warm, and
fuzzy, and "don't hurt me please", so the guaranties they give depend
on mood or something as "intuitive" as phase of the moon. And don't
feed corner cases to them, because they may scratch you!
So:
Warm, fuzzy: under defined, intuitive, sloppy...
Cool, strong: well defined, dependable, concrete...
There are plenty of warm, fuzzy languages out there, if you want Java,
you know where to find it. And *real programmers* seem to look for
something more these days.
I need to sleep well knowing my programs work. I need powerful, strong
abstraction. I use Haskell wherever possible because it is based on
the strongest thing we have: MATHS! Keep it that way!
Monads aren't warm, they are COOL!

Gracjan
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Thu, 15 Jan 2009, John Goerzen wrote:
> Several people have suggested this, and I think it would go a long way
> towards solving the problem. The problem is: this documentation can
> really only be written by those that understand the concepts,
> understand how they are used practically, and have the time and
> inclination to submit patches. Experience suggests there may be no
> such people out there :)
>
I'd probably be willing to have a crack given people to report back to (so
someone else can comment on whether the docs're any good) and a clear
process to follow. How much I'd actually get done's another matter of
course, and is also likely to depend on who's willing to talk about docs
on IRC! I'm thinking we probably need a #haskelldocs for coordination,
there's too much traffic to do it in #haskell itself these days.

[hidden email]
"The reason for this is simple yet profound. Equations of the form
x = x are completely useless. All interesting equations are of the
form x = y."  John C. Baez
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Fri, 16 Jan 2009, Duncan Coutts wrote:
> If you or anyone else has further concrete suggestions / improvements
> then post them here now! :)
>
Spell out what associativity means and what it means for that operation to
have an identity. List a few examples (stating that they're not all
instances), including the * and + ones for arithmetic (use this to explain
the issue with multiple monoids existing on one type, possibly use it to
mention newtypes and newtype deriving as a workaround). Mention the
intuition of monoids as abstract 'sequences', in which the sequence itself
may be hidden after evaluation or be irrelevant because the operation
commutes  the two arithmetic monoids are a good example in both cases.
Bonus points for explaining the relationship between monoids and folds
somewhere.

[hidden email]
'In AnkhMorpork even the shit have a street to itself...
Truly this is a land of opportunity.'  Detritus, Men at Arms
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


Hello david48,
Friday, January 16, 2009, 4:16:51 PM, you wrote:
> Upon reading this thread, I asked myself : what's a monoid ? I had no
> idea. I read some posts, then google "haskell monoid".
it would be interesting to google "C++ class" or "Lisp function" and
compare experience :)

Best regards,
Bulat mailto: [hidden email]
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Fri, 20090116 at 14:16 +0100, david48 wrote:
> Part of the problem is that something like a monoid is so general that
> I can't wrap my head around why going so far in the abstraction.
> For example, the writer monad works with a monoid; using the writer
> monad with strings makes sense because the mappend operation for lists
> is (++), now why should I care that I can use the writer monad with
> numbers
> which it will sum ?
To accumulate a running count, maybe? A fairly common pattern for
counting in imperative languages is
int i = 0;
while (<get a value>) i+= <count of something in value>
Using the writer monad, this turns into
execWriter $ mapM_ (write . countFunction) $ getValues
jcc
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


Hello,
Personally, I would like to see the laws more explicitly listed. Some
like:
 The Monoid Laws:

 1. Associative:

 x `mappend` (y `mappend` z) == (x `mappend` y) `mappend` z

 2. Left Identity:

 mempty `mappend` y == y

 3. Right identity:

 x `mappend` mempty == x
(Actually, what I'd really like to see is the laws provided as
QuickCheck properties. I know there is a project doing this already.)
j.
At Fri, 16 Jan 2009 13:39:10 +0000,
Duncan Coutts wrote:
>
> On Fri, 20090116 at 14:16 +0100, david48 wrote:
>
> > Upon reading this thread, I asked myself : what's a monoid ? I had no
> > idea. I read some posts, then google "haskell monoid".
> >
> > The first link leads me to Data.Monoid which starts with
> >
> > <<
> > Description
> > The Monoid class with various generalpurpose instances.
> >
> > Inspired by the paper /Functional Programming with Overloading and
> > HigherOrder Polymorphism/, Mark P Jones
> > ( http://citeseer.ist.psu.edu/jones95functional.html) Advanced School
> > of Functional Programming, 1995.
> > >>
>
> Ross just updated the documentation for the Monoid module. Here is how
> it reads now:
>
> The module header now reads simply:
>
> A class for monoids (types with an associative binary operation
> that has an identity) with various generalpurpose instances.
>
> Note, no links to papers.
>
> And the Monoid class has:
>
> The class of monoids (types with an associative binary operation
> that has an identity). The method names refer to the monoid of
> lists, but there are many other instances.
>
> Minimal complete definition: 'mempty' and 'mappend'.
>
> Some types can be viewed as a monoid in more than one way, e.g.
> both addition and multiplication on numbers. In such cases we
> often define @newtype@s and make those instances of 'Monoid',
> e.g. 'Sum' and 'Product'.
>
> If you or anyone else has further concrete suggestions / improvements
> then post them here now! :)
>
>
> Duncan
>
> _______________________________________________
> HaskellCafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskellcafe_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Fri, Jan 16, 2009 at 8:39 AM, Duncan Coutts
< [hidden email]> wrote:
> Ross just updated the documentation for the Monoid module. Here is how
> it reads now:
>
> The module header now reads simply:
>
> A class for monoids (types with an associative binary operation
> that has an identity) with various generalpurpose instances.
>
> Note, no links to papers.
>
> And the Monoid class has:
>
> The class of monoids (types with an associative binary operation
> that has an identity). The method names refer to the monoid of
> lists, but there are many other instances.
>
> Minimal complete definition: 'mempty' and 'mappend'.
>
> Some types can be viewed as a monoid in more than one way, e.g.
> both addition and multiplication on numbers. In such cases we
> often define @newtype@s and make those instances of 'Monoid',
> e.g. 'Sum' and 'Product'.
>
> If you or anyone else has further concrete suggestions / improvements
> then post them here now! :)
A reference to the writer monad and to Data.Foldable might be helpful.
So far as I know they are the only uses of the Monoid abstraction in
the standard libraries.
It's probably a good idea to explicitly state the three monoid laws.
It would be nice to explain what operations have been chosen for the
Monoid instances of Prelude data types. (Maybe this belongs in the
Prelude documentation.)
I'd add a reminder that if you're defining a type with a Monoid
instance, your documentation should explain what the instance does.

Dave Menendez < [hidden email]>
< http://www.eyrie.org/~zednenem/>
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


In reply to this post by Bugzilla from jonathanccast@fastmail.fm
On Thu, 15 Jan 2009 20:18:50 0800, you wrote:
>Really. So the engineer who designed the apartment building I'm in at
>the moment didn't know any physics, thought `tensor' was a scary math
>term irrelevant to practical, realworld engineering, and will only read
>books on engineering that replace the other scary technical term
>`vector' with pointdirectionvaluethingy? I think I'm going to sleep
>under the stars tonight...
As a rule, buildings are designed by architects, whose main job is to
ensure that they follow the requirements set by the relevant building
code (e.g., the International Building Code, used in most of the United
States and a few other places). Of course, an experienced architect has
most of that stuff in his/her brain already, and doesn't need to
constantly refer to the code books.
A jurisdiction may require that the architect's design be signed off by
one or more engineers. This is almost always the case for public
buildings and multiunit housing, and almost always not the case for
singleunit housing.
But if the building is a runofthemill design, then the engineer
checking it is unlikely to use anything beyond simple algebra. It's only
in case of unusual structures and oneoffs (skyscrapers, most anything
built in Dubai these days, etc.) that engineers will really get down and
dirty with the math. And yes, most professional engineers would not be
able to do that kind of work without some kind of refresher, not so much
because they never learned it, but because they haven't used it in so
long.
>Um, no. I try to avoid people as much as possible; computers at least
>make sense. Also anything else to do with the real world :)
Well, that it explains it then...
>Again, do engineers know *what* stress is? Do they understand terms
>like `tensor'? Those things are the rough equivalents of terms like
>`monoid'.
Stress, probably, at least in basic terms. Tensor, probably not.
Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Fri, Jan 16, 2009 at 12:00:40PM 0500, David Menendez wrote:
> A reference to the writer monad and to Data.Foldable might be helpful.
> So far as I know they are the only uses of the Monoid abstraction in
> the standard libraries.
>
> It's probably a good idea to explicitly state the three monoid laws.
I've added the laws.
> It would be nice to explain what operations have been chosen for the
> Monoid instances of Prelude data types. (Maybe this belongs in the
> Prelude documentation.)
The right place for that is the instances, as soon as Haddock starts
showing instance comments ( http://trac.haskell.org/haddock/ticket/29).
Then this information will be listed under both the type and the class.
> I'd add a reminder that if you're defining a type with a Monoid
> instance, your documentation should explain what the instance does.
When that Haddock enhancement is done, this will be general advice for
instances of all classes.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


> On Fri, 16 Jan 2009, Duncan Coutts wrote:
>
>> If you or anyone else has further concrete suggestions / improvements
>> then post them here now! :)
Show various examples of how monoids apply to programming
concepts/problems, e.g. monoids to combine configuration
parameters/flags, monoids in writers, etc. Show how using the
abstract monoid class is an advantage over a less abstract class/type
with concrete examples.
> Jonathan Cast wrote:
>
>
> To accumulate a running count, maybe? A fairly common pattern for
counting in imperative languages is
> int i = 0;
> while (<get a value>) i+= <count of something in value>
> Using the writer monad, this turns into
>
> execWriter $ mapM_ (write . countFunction) $ getValues
>
This should be in the documentation for Writer. It shows how a writer
can usefully and simply perform a specific function, and that function
is different from what most users would consider using a Writer for.
Hence, it's a specific example of both the advantages that generality
provides* and a programming use for a monoid.
John Lato
*) just being more general isn't always an advantage. As abstractions
progress, iIt becomes increasingly difficult to apply abstract
concepts to the task at hand. This essay,
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12, has a
pretty good description of taking this too far.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Fri, Jan 16, 2009 at 12:19 PM, Ross Paterson < [hidden email]> wrote:
> On Fri, Jan 16, 2009 at 12:00:40PM 0500, David Menendez wrote:
>> It would be nice to explain what operations have been chosen for the
>> Monoid instances of Prelude data types. (Maybe this belongs in the
>> Prelude documentation.)
>
> The right place for that is the instances, as soon as Haddock starts
> showing instance comments ( http://trac.haskell.org/haddock/ticket/29).
> Then this information will be listed under both the type and the class.
In the case of Monoid, I think it would be best to have the
documentation now, and then attach them to the instances later, once
Haddock supports that.
>> I'd add a reminder that if you're defining a type with a Monoid
>> instance, your documentation should explain what the instance does.
>
> When that Haddock enhancement is done, this will be general advice for
> instances of all classes.
Sure, but it's especially important for Monoid.

Dave Menendez < [hidden email]>
< http://www.eyrie.org/~zednenem/>
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Fri, 20090116 at 17:58 +0000, John Lato wrote:
> > On Fri, 16 Jan 2009, Duncan Coutts wrote:
> >
> >> If you or anyone else has further concrete suggestions / improvements
> >> then post them here now! :)
>
> Show various examples of how monoids apply to programming
> concepts/problems, e.g. monoids to combine configuration
> parameters/flags, monoids in writers, etc. Show how using the
> abstract monoid class is an advantage over a less abstract class/type
> with concrete examples.
>
> > Jonathan Cast wrote:
> >
> >
> > To accumulate a running count, maybe? A fairly common pattern for
> counting in imperative languages is
>
> > int i = 0;
> > while (<get a value>) i+= <count of something in value>
>
> > Using the writer monad, this turns into
> >
> > execWriter $ mapM_ (write . countFunction) $ getValues
> >
>
> This should be in the documentation for Writer.
Agreed. (Suitably elaborated to show why we didn't just say
sum $ map countFunction $ getValues
of course!)
Also, the monoid documentation should probably point at
Control.Monad.Writer and Data.Traversable, as well.
> It shows how a writer
> can usefully and simply perform a specific function, and that function
> is different from what most users would consider using a Writer for.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think this point is somehow relevant to the discussion at hand...
jcc
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On Thu, Jan 15, 2009 at 10:39:18PM 0600, Creighton Hogg wrote:
>
> For you folks who work on GHC, is it acceptable to open tickets for
> poor documentation of modules in base?
Personally, I don't think that doing so would make it more likely that
someone would actually write the documentation; it would just be another
ticket lost in the noise.
The best way to get better docs would be to create a wiki page with
proposed docs, and send a URL to the libraries list and solicit
improvements, in my opinion.
While you may say that people asking for docs for X don't know enough to
write them, I would claim that they normally manage to use X in their
program shortly afterwards, and could thus at least put together a tiny
example of what X can be used for (in English) and how to use it (in
Haskell).
These initial drafts don't have to be perfect, or even correct, as the
libraries list can refine them, but someone does need to put the effort
into picking a good, small example, getting the phrasing nice, etc.
Once the list has settled on good docs, then filing a ticket with the
docs attached is definitely useful.
Thanks
Ian
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


Philippa Cowderoy wrote:
> On Fri, 16 Jan 2009, Duncan Coutts wrote:
>
>> If you or anyone else has further concrete suggestions / improvements
>> then post them here now! :)
>>
>
> Spell out what associativity means
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.
Anton
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


Ketil Malde wrote:
> The problem is that many Haskell constructs are so abstract and so
> general that precise names will be obscure to anybody with no
> background in logic (existential quantification), algebra (monoid) or
> category theory (monad). This level of abstraction is a great
> benefit, since it allows reuse of code and concepts, but the problem
> is internalizing the abstraction and learning to recognize how it
> works for different concrete data types.
>
Abstraction is a great thing to have. I'd just prefer it to not look so
intimidating; the majority of these abstractions aren't actually
"complicated" in any way, once you learn what they are...
> As pointed out numerouos times, calling Monoids "Appendable" would be
> wildly misleading. But I think the real problem here is learning and
> understandig very abstract concepts, not the names.
>
If you're going to implement an abstraction for monoids, you might as
well call it "monoid". On that I agree.
I still think "appendable" (where it really *is* used only for
appendable collections) is a more useful abstraction to have, since it's
more specific. Generalising things is nice, but if you generalise things
too far you end up with something too vague to be of practical use.
> I agree (with everybody) that documentation is lacking.
If there is one single thing to come out of this giant flamewar, I hope
it's better documentation. (I'll even lend a hand myself if I can figure
out how...) Clearer documentation can't possibly be a bad thing!
>> (Anybody who attempts to argue that "monoid" is not actually an
>> obscure term has clearly lost contact with the real world.)
>>
>
> Anybody who calls Monoids "Appendable" has clearly lost contact with
> their programming language :)
>
Calling something "appendable" if it really is a general monoid would be
slightly silly, yes.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


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.)
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


2009/1/16 Andrew Coppin < [hidden email]>:
> 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.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


Steve Schafer < [hidden email]> writes:
> But if the building is a runofthemill design, then the engineer
> checking it is unlikely to use anything beyond simple algebra. It's only
> in case of unusual structures and oneoffs (skyscrapers, most anything
> built in Dubai these days, etc.) that engineers will really get down and
> dirty with the math.
Heh, nice analogy which I suspect many mathhappy Haskell programmers
will be happy to embrace. (Who wants to churn out runofthemill
massmarket stuff from the assembly line anyway?)
k

If I haven't seen further, it is by standing in the footprints of giants
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe

1 ...
45678910
... 12
