On Fri, 2009-01-16 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 general-purpose instances. > > Inspired by the paper /Functional Programming with Overloading and > Higher-Order 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 general-purpose 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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
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 Curry-Howard 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. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Ketil Malde-5
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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
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 #haskell-docs 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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Duncan Coutts
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 Ankh-Morpork even the shit have a street to itself... Truly this is a land of opportunity.' - Detritus, Men at Arms _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by David Virebayre
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] _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by David Virebayre
On Fri, 2009-01-16 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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Duncan Coutts
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, 2009-01-16 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 general-purpose instances. > > > > Inspired by the paper /Functional Programming with Overloading and > > Higher-Order 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 general-purpose 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 > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Duncan Coutts
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 general-purpose 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/> _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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, real-world engineering, and will only read >books on engineering that replace the other scary technical term >`vector' with point-direction-value-thingy? 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 multi-unit housing, and almost always not the case for single-unit housing. But if the building is a run-of-the-mill design, then the engineer checking it is unlikely to use anything beyond simple algebra. It's only in case of unusual structures and one-offs (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/ _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by David Menendez-2
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. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
> 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. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Ross Paterson
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/> _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Lato-2
On Fri, 2009-01-16 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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Creighton Hogg-4
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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Philippa Cowderoy
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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Ketil Malde-5
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. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Anton van Straaten
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Steve Schafer
Steve Schafer <[hidden email]> writes:
> But if the building is a run-of-the-mill design, then the engineer > checking it is unlikely to use anything beyond simple algebra. It's only > in case of unusual structures and one-offs (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 math-happy Haskell programmers will be happy to embrace. (Who wants to churn out run-of-the-mill mass-market stuff from the assembly line anyway?) -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |