On Thu, Jan 15, 2009 at 10:18 PM, Jonathan Cast
<[hidden email]> wrote: > On Thu, 2009-01-15 at 17:06 -0500, Steve Schafer wrote: >> On Thu, 15 Jan 2009 13:21:57 -0800, you wrote: >> >> >Where, in the history of western civilization, has there ever been an >> >engineering discipline whose adherents were permitted to remain ignorant >> >of the basic mathematical terminology and methodology that their >> >enterprise is founded on? >> >> Umm, all of them? > > 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 It feels like this conversation is going in circles. What I'm taking away from the two very different arguments being made is that 1) math terms have their place when they describe the concept very precisely, e.g. monoid 2) the Haskell docs _don't_ do good enough a job at giving intuition for what math terms mean If we fix #2, then #1 is no longer a problem, yes? For you folks who work on GHC, is it acceptable to open tickets for poor documentation of modules in base? I think leaving the documentation to the tragedy of the commons isn't the best move, but if even a few of us could remember to open tickets when new Haskell'ers complain about something being confusing then it could be on _someone's_ docket. Cheers, Creighton _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
On 15 Jan 2009, at 16:34, John Goerzen wrote:
[snip] Sorry, I'm not going to refer to that paragraph, instead, I'm going to point out how depressing it is, that the message we're getting across to new haskellers is that "Monads, and variations on monads and extensions to monads and operations on monads are the primary way Haskell combines code-". We have loads of beautiful ways of combining code (not least ofc, simple application), why is it than Monad is getting singled out as the one that we must use for everything? My personal suspicion on this one is that Monad is the one that makes concessions to imperative programmers, by on of its main combinators (>>=) having the type (>>=) :: (Monad m) => m a -> (a -> m b) -> m b, and not the much nicer type (>>=) :: (Monad m) => (a -> m b) -> (m a -> m b). Bob _______________________________________________ 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, 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. 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. 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. > can we at least write some documentation that doesn't require a PhD > to comprehend? I agree (with everybody) that documentation is lacking. Referring to category theory, logic, or scientific papers is good, but leaving it at that is pure intellectual terrorism. Good documentations should: 1. describe the abstraction and 2. list instances with examples for each. For extra credit also include a section with excercises - and I'm only half joking here. > (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 :-) -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 |
In reply to this post by haskell-2
On Thu, Jan 15, 2009 at 11:54 PM, ChrisK <[hidden email]> wrote:
> > So the original article, which coined 'Appendable', did so without much > thought in the middle of a long post. But it does show the thinking was > about collections and there is one ONE instance of Monoid at > > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html#t%3AMonoid > > that is about a collection (Monoid ([] a)) that has a split operation. The blind man at the back takes firm hold of the tail and says, "But why do we need to call it an *elephant*? No-one knows what that is. Everyone knows what a rope is, so we should just call it a rope." And that is how the elephant came to be labelled a rope in all the guide books. :-) Cheers, D _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Dan Weston
Dan Weston wrote:
> Richard Feinman once said: "if someone says he understands quantum > mechanics, he doesn't understand quantum mechanics". > > But what did he know... Well, I am a physicist and Feynman (with a y, not an i), is not talking about the linear algebra. Of course, linear algebra [1] here is used a vector space [2]. The tricky thing is that humans then "measure" the state. And this is confusing step that causes Feynman to say that no one understands it. But the measurement step and how it interacts with the vector space can be approximated by an algorithm [3] using ExistentialQuantification and Arrows. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/numeric-quest http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hmatrix http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Vec http://hackage.haskell.org/cgi-bin/hackage-scripts/package/blas [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector-space [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/quantum-arrow -- Chris _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
Here is a great "Monoid found in the wild story":
I just implemented a library for binary message serialization that follows Google's protocol buffer format. The documentation of this was very scattered in some respects but I kept reading snippets which I have pasted below. The effect of these snippets is to document that the messages on the wire should mimic an API where they can be combined in various merge operations (right-biased, concatenation, and recursive merging), and that well-formed messages have default values for all fields (which can be set in the spec). So the code below is a well thought out collection of properties that has reinvented the wheel known as "Monoid", so the Haskell API creates Monoid instances. http://code.google.com/apis/protocolbuffers/docs/encoding.html > Normally, an encoded message would never have more than one instance of an > optional or required field. However, parsers are expected to handle the case in > which they do. For numeric types and strings, if the same value appears multiple > times, the parser accepts the last value it sees. For embedded message fields, > the parser merges multiple instances of the same field, as if with the > Message::MergeFrom method â€“ that is, all singular scalar fields in the latter > instance replace those in the former, singular embedded messages are merged, and > repeated fields are concatenated. The effect of these rules is that parsing the > concatenation of two encoded messages produces exactly the same result as if you > had parsed the two messages separately and merged the resulting objects. That > is, this: > >> MyMessage message; >> message.ParseFromString(str1 + str2); > > is equivalent to this: > >> MyMessage message, message2; >> message.ParseFromString(str1); >> message2.ParseFromString(str2); >> message.MergeFrom(message2); > > This property is occasionally useful, as it allows you to merge two messages > even if you do not know their types. And this at http://code.google.com/apis/protocolbuffers/docs/proto.html > As mentioned above, elements in a message description can be labeled > optional. A well-formed message may or may not contain an optional element. > When a message is parsed, if it does not contain an optional element, the > corresponding field in the parsed object is set to the default value for that > field. The default value can be specified as part of the message description. > For example, let's say you want to provide a default value of 10 for a > SearchRequest's result_per_page value. > >> optional int32 result_per_page = 3 [default = 10]; > > If the default value is not specified for an optional element, a > type-specific default value is used instead: for strings, the default value > is the empty string. For bools, the default value is false. For numeric > types, the default value is zero. For enums, the default value is the first > value listed in the enum's type definition. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Dan Piponi-2
Dan Piponi wrote:
>> Several people have suggested this, and I think it would go a long way >> towards solving the problem. > > That sounds like a good plan. Which precise bit of documentation > should I update? Make a new wiki page? Put it in here: > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html I think it would be great if the haddock documentation itself were a wiki, so everyone can edit it right in place. Regards, H. Apfelmus _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Derek Elkins
2009/1/15 Derek Elkins <[hidden email]>:
> On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote: >> On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore <[hidden email]> wrote: >> > >> > Mathematical precision isn't appropriate in all disciplines. >> > >> That's very true. But programming is one where mathematical precision >> is needed, even if you want to call it something else. >> > Actually programming requires -far more- precision than mathematics ever > has. The standards of "formal" and "precise" that mathematicians use > are a joke to computer scientists and programmers. Communication is > also more important or at least more center stage in mathematics than > programming. Mathematical proofs are solely about communicating > understanding and are not required to execute on a machine. Hmm. I could argue that coding *terminology* and words used for human-to-human *discussion* of programs can afford to be far *less* precise, simply because the ultimate precision is always available in terms of actual executable code (which offers no scope for misunderstanding - it's a concrete, executable object, with precise semantics defined by the implementation). Mathematical terminology has to be much stricter, because there's no fallback of "use the source". That's not to say that I disagree entirely, but it's not as black-and-white as this discussion makes it seem. Paul. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Creighton Hogg-4
> 2) the Haskell docs _don't_ do good enough a job at giving intuition
> for what math terms mean > > If we fix #2, then #1 is no longer a problem, yes? > > For you folks who work on GHC, is it acceptable to open tickets for > poor documentation of modules in base? I think leaving the > documentation to the tragedy of the commons isn't the best move, but > if even a few of us could remember to open tickets when new > Haskell'ers complain about something being confusing then it could be > on _someone's_ docket. I can't find the thread at the moment, but this has been discussed before, and my recollection is that wikis were to be used to accumulate documentation comments and updates (there also was some discussion about the best format for comment patches, but getting content was thought to be more important). So, there would be a subset of the Haskell wiki for the base library, and package-specific wiki locations for their documentations. Haddock already seems to provide the necessary support: http://www.haskell.org/haddock/doc/html/invoking.html --comments-base=URL , --comments-module=URL , --comments-entity=URL Include links to pages where readers may comment on the documentation. This feature would typically be used in conjunction with a Wiki system. Use the --comments-base option to add a user comments link in the header bar of the contents and index pages. Use the --comments-module to add a user comments link in the header bar of each module page. Use the --comments-entity option to add a comments link next to the documentation for every value and type in each module. In each case URL is the base URL where the corresponding comments page can be found. For the per-module and per-entity URLs the same substitutions are made as with the --source-module and --source-entity options above. For example, if you want to link the contents page to a wiki page, and every module to subpages, you would say haddock --comments-base=url --comments-module=url/%M So it seems it is only a question of actually using these options with suitably prepared per-package documentation wikis, and improving the documentation or asking for clarifications would be almost as easy as emailing here!-) And if everyone who stumbles over a documentation problem puts the solution on the wiki, documentation should improve quickly (there is still the issue of selecting wiki improvement suggestions for inclusion in the "real" documentation). Does anyone know why these options are not in use already? Claus _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Heinrich Apfelmus
That looks like a freakin' cool idea; however very hard to implement;
so why not write such wikis in predefined places, like, haskell.org/haskellwiki/Data/Monoid/ and allow haddock to automatically put links there from the generated documentation? This would make the documentation (on the wiki) more organized, more 'extensible' and people would know a place where they can surely share their knowledge in a useful and very findable way. Are there any drawbacks to this? 2009/1/16 Apfelmus, Heinrich <[hidden email]>: > Dan Piponi wrote: >>> Several people have suggested this, and I think it would go a long way >>> towards solving the problem. >> >> That sounds like a good plan. Which precise bit of documentation >> should I update? Make a new wiki page? Put it in here: >> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html > > I think it would be great if the haddock documentation itself were a > wiki, so everyone can edit it right in place. > > > Regards, > H. Apfelmus > > _______________________________________________ > 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 |
On Fri, Jan 16, 2009 at 3:46 AM, Eugene Kirpichov <[hidden email]> wrote: That looks like a freakin' cool idea; however very hard to implement;
_______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
It's a criticism already voiced by the great David Bowie:
"My Brain Hurt like a warehouse, it had no room to spare I had to cram so many things to store everything in there" Immanuel On Thu, Jan 15, 2009 at 4:34 PM, John Goerzen <[hidden email]> wrote: Hi folks, _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Thorkil Naur
Thorkil Naur wrote:
> Peter Verswyvelen wrote: >> >> It is rather funny. When we are young kids, we learn weird symbols like >> >> A B C a b c 1 2 3 >> >> which we accept after a while. >> >> But Functor, Monoid or Monad, that we cannot accept anymore. Why, because >> these are not intuitive? Are the symbols above "intuitive"? > > I think there is a simple explanation of this: Consider the amount of time you > spent, as a young kid, to learn to get used to these funny 1, 2, a, b, x, y, > +, - and so on. I haven't got the exact schedules from school, but my > impression is that we are talking about hours and hours of drill and > practice, over weeks, months, years. > > So, to learn to become familiar and effective in using new and complex > concepts, we should just accept that it sometimes may take a while. And > that's it. It is all a matter of practice, exposure, and guidance. That's a highly relevant wisdom! Learning something new needs practice / time and good tutors / books / guidance. It doesn't matter whether the new thing is "alphabet", "summation", "boolean", "programming" or "monoid". Obviously, those who know what a monoid is have already invested years of time practicing mathematics while those that even attack the name "monoid" clearly lack this practice. It's like peano virtuosoes compared to beginning keyboard pressers. Concerning the question whether it is necessary to invest at least some time on mathematical practice to learn Haskell, the answer is yes. There is no shortcut to learning purely functional programming and reasoning. Renaming "monoid" to "appendable" and "monad" to "warm fuzzy thing" are but useless cosmetic changes that don't make anything easier. How to learn? The options are, in order of decreasing effectiveness university course teacher in person book irc mailing list online tutorial haskell wiki haddock documentation Usually, the best thing is to have a teacher, i.e. to go to a good CS course on Haskell. Books and #haskell or the mailing list are a good substitute, but require self-discipline. Both teachers and books cost money, but you get what you pay for, the online tutorial, wiki and haddock worlds are too messy to be effective until very late in the learning process. In particular, monoids are defined and used in Richard Bird. Introduction to Functional Programming using Haskel (2nd edition). http://www.amazon.com/ Introduction-Functional-Programming-using-Haskell/dp/0134843460 I think that this book is a good benchmark for measuring the amount of practice to be invested in learning Haskell. Regards, H. Apfelmus _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
I have to say, I agree with Lennart here. Terms like monoid have had
a precise definition for a very long time. Replacing an ill-defined term by a vaguely defined term only serves to avoid facing ones ignorance - IMHO an unwise move for a technical expert. Learning Haskell has often been described as a perspective changing, deeply enlightening process. I believe this is because the language and the community favours drilling down to the core of a problem and exposing its essence in the bright light of mathematical precision. It would be a mistake to give up on that. We could call lambda abstraction, "name binder", and we could call the lambda calculus, "rule system to manipulate name bindings". That would avoid some scary greek. Would it make functional programming any easier? In contrast, even the planned new C++0x standard uses our terminology: http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions Ok, ok, they do mutilate the whole idea quite brutally, but the point is, we got in their heads. That counts. I am all for helping beginners to learn, but I am strongly against diluting what is being learnt. If some of our terminology is a problem, we need to explain it better. Manuel Lennart Augustsson: > Most people don't understand pure functional programming either. Does > that mean we should introduce unrestricted side effects in Haskell? > > -- Lennart > > On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson > <[hidden email]> wrote: >> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh >> <[hidden email]> wrote: >>> Lennart Augustsson wrote: >>>> I have replied on his blog, but I'll repeat the gist of it here. >>>> Why is there a fear of using existing terminology that is exact? >>>> Why do people want to invent new words when there are already >>>> existing ones with the exact meaning that you want? If I see >>>> Monoid I >>>> know what it is, if I didn't know I could just look on Wikipedia. >>>> If I see Appendable I can guess what it might be, but exactly what >>>> does it mean? >>> >>> I would suggest that having to look things up slows people down >>> and might distract them from learning other, perhaps more useful, >>> things about the language. >> >> Exactly. For example, the entry for monoid on Wikipedia starts: >> "In abstract algebra, a branch of mathematics, a monoid is an >> algebraic structure with a single, associative binary operation and >> an >> identity element." >> >> I've had some set theory, but most programmers I know have not. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Creighton Hogg-4
On Fri, Jan 16, 2009 at 5:39 AM, Creighton Hogg <[hidden email]> wrote:
> For you folks who work on GHC, is it acceptable to open tickets for > poor documentation of modules in base? I think leaving the > documentation to the tragedy of the commons isn't the best move, but > if even a few of us could remember to open tickets when new > Haskell'ers complain about something being confusing then it could be > on _someone's_ docket. I second that. 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. >> Before going further, I click on the link and I'm on citeseer. The abstract talks about the Hindley/Milner type system, but no mention of monoid. I download the pdf, and search for monoid in acrobat reader. No matches. I read further on Data.Monoid... << The monoid class. A minimal complete definition must supply mempty and mappend, and these should satisfy the monoid laws." >> The laws are not mentionned. I learn that there are 3 operations on monoids: mappend which is an associative operation mempty which is an identity of mappend. mconcat which "folds a list using the monoid", which I think I understand this way : mempty will be the seed of the fold, and mappend the fonction called for each item. The module defines the dual of a monoid without explaining much; the "monoid of endomorphisms under composition" (another word to look up) In fact I realise many monoids are defined, and I don't know what are they usefull for. The next few pages google gives me are about monads. Then there's some blog posts by sigfpe, which I'm not going to read because they're often way too complicated for me to understand. Actually I still read it and there I find what I think is a monoid law: << They are traditionally sets equipped with a special element and a binary operator so that the special element acts as an identity for the binary operator, and where the binary operator is associative. We expect type signatures something like one :: m and mult :: m -> m -> m so that, for example, m (m a b) c == m a (m b c). >> I don't get it right away, though, and the rest is code that I skip because I just want info on monoids. Another page : MonadPlus VS Monoids... Still not the basic info that I'd love to find. I am now at the end of the first page of google results, and I don't have any clue about: - what are the laws of a monoid besides it has an associative operation and an identity ? - what is the point of a monoid other than being a generalisation/abstraction ? What kind of uses this particular generalisation brings me ? 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 ? ( if I understood correctly ! ) I don't care about the name, it's ok for me that the name mathematicians defined is used, but there are about two categories of people using haskell and I would love that each concept would be adequately documented for everyone: - real-world oriented programming documentation with usefulness and examples for the non mathematician - the mathematics concepts and research papers for the mathematicians for those who want/need to go further As someone mentionned, the documentation can't really be done by someone that doesn't fully grok the concepts involved. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Cale Gibbard
On Thu, 2009-01-15 at 18:41 -0500, Cale Gibbard wrote:
> 2009/1/15 Andrew Coppin <[hidden email]>: > > OK, well then my next question would be "in what say is defining > > configuration files as a monoid superior to, uh, not defining them as a > > monoid?" What does it allow you to do that you couldn't otherwise? I'm not > > seeing any obvious advantage, but you presumably did this for a reason... > > I can't speak from the perspective of the Cabal developers, but > combining configurations with partial information using a monoid > operation is generally a good way to structure things. Basically, this > would be analogous to the way that the First monoid (or the Last > monoid) works, but across a number of fields. You have an empty or > default configuration which specifies nothing that serves as the > identity, and then a way of layering choices together, which is the > monoid operation. Exactly. Some fields are the Last monoid (we call it Flag) and some are the list monoid. Whole sets of such settings are monoids point-wise. It is indeed great for combining/overriding setting from defaults, config files and the command line. Duncan _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
On Thu, 15 Jan 2009, Lennart Augustsson wrote:
> If I see Monoid I know what it is, if I didn't know I could just look > on Wikipedia. And if you're a typical programmer who is now learning Haskell, this will likely make you want to run screaming and definitely be hard to understand. We at least need a description that's aimed at people who probably don't consider themselves any flavour of mathematician, however amateur. One that, while giving the definition, concentrates significantly on intuition. -- [hidden email] "I think you mean Philippa. I believe Phillipa is the one from an alternate universe, who has a beard and programs in BASIC, using only gotos for control flow." -- Anton van Straaten on Lambda the Ultimate _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Heinrich Apfelmus
2009/1/16 Apfelmus, Heinrich <[hidden email]>:
> How to learn? The options are, in order of decreasing effectiveness > > university course teacher in person > book irc > mailing list > online tutorial > haskell wiki > haddock documentation Reason by analogy from known/similar areas. I think the point here is that for Haskell, this is more possible for mathematicians than for programmers. And that's an imbalance that may need to be addressed (depending on who you want to encourage to learn). But I agree that reasoning by analogy is not a very good way of learning. And I think it's been established that the real issue here is the documentation - complete explanations and better discoverability[1] are needed. Note that for people who don't want to (or can't) invest money, and who don't want to take up too much of others' time, documentation is the most important option. Paul. [1] When I say "discoverability", I mean that no matter how good the documentation of (say) Monoid is, it's useless unless there's something that prompts me, based on the real-world programming problem I have (for example, merging a set of configuration options to use an example mentioned in this thread), to *look* at that documentation. That's where names make a difference. _______________________________________________ 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 don't know about you, but rather than knowing that joinFoo is associative, > I'd be *far* more interested in finding out what it actually _does_. A good many descriptions won't tell you whether it's associative though, and sometimes you need to know - for example, are foldl and foldr (denotationally) equivalent with this function? That is, can you just swap which function you call without any further checking? > As an aside, the integers form two different monoids. Haskell can't [easily] > handle that. Does anybody know of a language that can? > There're many ways of doing it, the question's what you lose in the process. Usually you have to explicitly state which monoid you're using in each and every place, and there has to be a means for types that're based around (say) a monoid to state which monoid it is they're based around (this one's more likely to crop up with orderings). Haskell effectively dodges a limited form of dependent typing by being able to deduce that directly from the types involved. -- [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 Philippa Cowderoy
On Fri, Jan 16, 2009 at 1:23 PM, Philippa Cowderoy <[hidden email]> wrote:
> On Thu, 15 Jan 2009, Lennart Augustsson wrote: > >> If I see Monoid I know what it is, if I didn't know I could just look >> on Wikipedia. > > And if you're a typical programmer who is now learning Haskell, this will > likely make you want to run screaming and definitely be hard to > understand. We at least need a description that's aimed at people who > probably don't consider themselves any flavour of mathematician, however > amateur. One that, while giving the definition, concentrates significantly > on intuition. Wikibooks has a patchy book on Abstract Algebra which seemed quite friendly to me (a non-mathematician and amateur FPer). I take it for granted there will be parts I don't understand but if I just continue to spot instances in the wild where they come up then it slowly becomes obvious. Collecting examples of concrete monoids is fairly easy fi you read some of the popular Haskell projects: Xmonad, Cabal, etc. I honestly don't see what all the fuss is about. No one's arguing that more documentation is a bad thing. But some people seem to think the mere existence of (a) technical terms or (b) technical terms not invented by programmers are an affront. Cheers, D _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |