[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
david48 wrote: On the other hand, on page 320 there is a nice explanation of Monoid, and on page 380, which isn't mentionned in the index, there might be the first time one can understand why the writer monad works with monoids instead of lists: to be able to use better suited data types for appending. (I too usually use the monoid instance mainly for difference lists.) All of this is still lacking the great why : why/how an abstraction so generic can be useful. I'm starting to believe that the only reason to make a datatype an instance of Monoid is... why not ! since it's not hard to find an associative operation and a neutral element. As Bertram Felgenhauer has already mentioned, a very powerful application of monoids are 2-3 finger trees Ralf Hinze and Ross Patterson. Finger trees: a simple general-purpose data structure. http://www.soi.city.ac.uk/~ross/papers/FingerTree.html Basically, they allow you write to fast implementations for pretty much every abstract data type mentioned in Okasaki's book Purely Functional Data Structures. For example, you can do sequences, priority queues, search trees and priority search queues. Moreover, any fancy and custom data structures like interval trees or something for stock trading are likely to be implementable in this framework as well. How can one tree be useful for so many different data structures? The answer: *monoids*! Namely, the finger tree works with elements that are related to a monoid, and all the different data structures mentioned above arise by different choices for this monoid. Let me explain this monoid magic, albeit not in this message which would become far too long, but at http://apfelmus.nfshost.com/monoid-fingertree.html Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
A very nice writeup about the use of monoid with finger tree. But please, use the names of the monoid operations that the rest of the Haskell libraries use. By using different names you are just confusing readers (even if you don't like the standard names). Also, you can replace Infinity by maxBound. -- Lennart On Tue, Jan 20, 2009 at 3:42 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: david48 wrote: On the other hand, on page 320 there is a nice explanation of Monoid, and on page 380, which isn't mentionned in the index, there might be the first time one can understand why the writer monad works with monoids instead of lists: to be able to use better suited data types for appending. (I too usually use the monoid instance mainly for difference lists.) All of this is still lacking the great why : why/how an abstraction so generic can be useful. I'm starting to believe that the only reason to make a datatype an instance of Monoid is... why not ! since it's not hard to find an associative operation and a neutral element. As Bertram Felgenhauer has already mentioned, a very powerful application of monoids are 2-3 finger trees Ralf Hinze and Ross Patterson. Finger trees: a simple general-purpose data structure. http://www.soi.city.ac.uk/~ross/papers/FingerTree.html Basically, they allow you write to fast implementations for pretty much every abstract data type mentioned in Okasaki's book Purely Functional Data Structures. For example, you can do sequences, priority queues, search trees and priority search queues. Moreover, any fancy and custom data structures like interval trees or something for stock trading are likely to be implementable in this framework as well. How can one tree be useful for so many different data structures? The answer: *monoids*! Namely, the finger tree works with elements that are related to a monoid, and all the different data structures mentioned above arise by different choices for this monoid. Let me explain this monoid magic, albeit not in this message which would become far too long, but at http://apfelmus.nfshost.com/monoid-fingertree.html Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
On Tue, Jan 20, 2009 at 3:42 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Let me explain this monoid magic, albeit not in this message which would become far too long, but at http://apfelmus.nfshost.com/monoid-fingertree.html That is a very nice summary! I did my own investigation of fingertrees recently [1] and also came to the conclusion that the function names for Monoid really are the ugliest, impractical things for such a beautiful, simple concept. Ah, if only we could go back in time :-) [1]: http://www.dougalstanton.net/blog/index.php/2008/12/12/a-brief-look-at-fingertrees/ Cheers, D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: A very nice writeup about the use of monoid with finger tree. Thanks :) But please, use the names of the monoid operations that the rest of the Haskell libraries use. By using different names you are just confusing readers (even if you don't like the standard names). True. Unfortunately, mappend is no option because it's way too long, I barely got away with writing out measure . There is ++ but it's already taken. Alternatively, I could opt for unicode ⊕ and at least match the paper. Thoughts? Also, you can replace Infinity by maxBound. Good idea, thanks. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Apfelmus, Heinrich schrieb: 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. Aren't all Haskellers some kind of Peano virtuosos? :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
david48 wrote: Apfelmus, Heinrich wrote: Hm, what about the option of opening Bird's Introduction on Functional Programming using Haskell in the section about fold? Monoid is on page 62 in the translated copy I've got here. I don't think that I would try to learn a programming language, for example Python, without obtaining a paper book on it. I would, if the online documentation makes it possible, and then I would buy a paper book later, to go further or for reference. That's how I learned Haskell, and much later I've bought my first book. Interesting, I wouldn't want to miss actual paper when learning difficult topics. Also, some great resources like the contents of Bird's book just aren't available online ;). I'd recommend to borrow it from a library, though, the current amazon price is quite outrageous. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
John Lato wrote: Here is the current complete documentation for Data.Monoid 'mappend', which happens to be a good example of which I speak: An associative operation That could mean anything. There are lots of associative operations. Yes. In combination with the definition of mempty (the identity for mappend) that's exactly what a monoid is. I'm not (just) being flippant. This particular example actually highlights the limitations of type classes. There are, in fact, too many monoids. Too many to be able to define it based only on the carrier, i.e. the type that mempty belongs to and that mappend operates over. For example every (semi-)ring has at least two of them[1]. For more complicated mathematical structures there can be even more than that. This isn't to say that we should get rid of Monoid, just that using it can be... troublesome. But this has been mentioned already on a few other recent threads. The notion of appending only really applies to the free monoid on a set A, aka strings of elements drawn from A. It bears highlighting that I said strings (in the mathematical sense) and not (linked) lists. The concatenation involved is mathematical juxtaposition, and the empty element is the empty string (which is subtly different than the empty list which is also used to terminate the datatype's recursion). These monoids are called free because they make no requirements on the underlying set, no requirements other than the monoid laws. All other monoids use some sort of structure in the underlying set in order to simplify expressions (e.g. 1+1 == 2, whereas a+a == aa). Because the free monoid doesn't simplify anything, all it does is append. [1] For example, Natural numbers: (Nat,+,0) (Nat,*,1) Boolean algebra: (Bool,or,False) (Bool,and,True) Bit-vector algebra: (Bits,bitOr,0) (Bits,bitAnd,-1) Any lattice L: (L,join,Bottom) (L,meet,Top) Any total ordering O: (O,max,NegativeInfinity) (O,min,Infinity) Any set universe U: (Power(U),union,EmptySet) (Power(U),intersection,U) ...let alone getting into fun things like the log-semiring, polynomials with natural coefficients, and so on. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Paul Moore wrote: Apfelmus, Heinrich wrote: 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. Yes, agreed. However, I would say that the word documentation does not apply anymore, it's more subject of study. What I want to say is that to some extend, Haskell is not only similar to mathematics, it /is/ mathematics, so programmers have to learn mathematics. Traditionally, this is done in university courses or with books, I'm not sure whether learning mathematics via internet tutorials on the computer screen works. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Ertugrul Soeylemez wrote: Andrew Coppin andrewcop...@btinternet.com wrote: I would suggest that ExistentiallyQuantifiedTypeVariables would be an improvement [...] That must be a joke. Typing the long extension names in LANGUAGE pragmas over and over again is tiring and annoying enough already. We really don't need even longer names, and your improvement fills up almost half of the width of an 80 characters terminal. Which is why I personally prefer HiddenTypeVariables. (This has the advantage of using only pronouncible English words, which means you can use it when speaking out loud.) But, as I say, nobody is going to rename anything, so it's moot. I can't await the next Haskell standard, where at last all those extensions are builtin. This frightens me. At the moment, I understand how Haskell 98 works. There are lots of extensions out there, but I don't have to care about that because I don't use them. If I read somebody else's code and it contains a LANGUAGE pragma, I can immediately tell that the code won't be comprehendable, so I don't need to waste time trying to read it. But once Haskell' becomes standard, none of this holds any more. Haskell' code will use obscure lanuage features without warning, and unless I somehow learn every extension in the set, I'll never be able to read Haskell again! (One presumes that they won't add any extensions which actually *break* backwards compatibility, so hopefully I can still pretend these troublesome extensions don't exist when writing my own code...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Andrew Coppin wrote: I can't await the next Haskell standard, where at last all those extensions are builtin. This frightens me. The example he had had the uses keyword, so I assume it's built in in the same way Perl pragma are built in. So you can happily ignore code when you see uses at the top of the file. ;) Although I could be wrong. Cheers, Cory ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
- Original Message From: Andrew Coppin andrewcop...@btinternet.com Which is why I personally prefer HiddenTypeVariables. (This has the advantage of using only pronouncible English words, which means you can use it when speaking out loud.) Existential - English, easy to pronounce Quantify - English, easy to pronounce I know I've been seeing those backwards E's and upside down A's in not-so-advanced Maths courses for a long time (since high school, I'm sure) and I certainly encountered them before 'Boolean'. If you could do a geometry proof in high school, you have the Maths background need to understand the ideas. (How they apply to types is another story, but the words shouldn't be scary.) I can't await the next Haskell standard, where at last all those extensions are builtin. This frightens me. At the moment, I understand how Haskell 98 works. There are lots of extensions out there, but I don't have to care about that because I don't use them. If I read somebody else's code and it contains a LANGUAGE pragma, I can immediately tell that the code won't be comprehendable, so I don't need to waste time trying to read it. But once Haskell' becomes standard, none of this holds any more. Haskell' code will use obscure lanuage features without warning, and unless I somehow learn every extension in the set, I'll never be able to read Haskell again! (One presumes that they won't add any extensions which actually *break* backwards compatibility, so hopefully I can still pretend these troublesome extensions don't exist when writing my own code...) Some of the most useful libraries (e.g. parsec, generics) use these type system extensions (higher rank polymorphism, existentials). It would be great if these could be considered 'standard Haskell'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Andrew Coppin andrewcop...@btinternet.com wrote: Ertugrul Soeylemez wrote: Andrew Coppin andrewcop...@btinternet.com wrote: I would suggest that ExistentiallyQuantifiedTypeVariables would be an improvement [...] That must be a joke. Typing the long extension names in LANGUAGE pragmas over and over again is tiring and annoying enough already. We really don't need even longer names, and your improvement fills up almost half of the width of an 80 characters terminal. Which is why I personally prefer HiddenTypeVariables. (This has the advantage of using only pronouncible English words, which means you can use it when speaking out loud.) But, as I say, nobody is going to rename anything, so it's moot. Well, yes, unfortunately, unless someone proposes extension renamings together with a long paper about the psychological implications and advantages of using shorter names. I can't await the next Haskell standard, where at last all those extensions are builtin. This frightens me. At the moment, I understand how Haskell 98 works. There are lots of extensions out there, but I don't have to care about that because I don't use them. If I read somebody else's code and it contains a LANGUAGE pragma, I can immediately tell that the code won't be comprehendable, so I don't need to waste time trying to read it. But once Haskell' becomes standard, none of this holds any more. Haskell' code will use obscure lanuage features without warning, and unless I somehow learn every extension in the set, I'll never be able to read Haskell again! (One presumes that they won't add any extensions which actually *break* backwards compatibility, so hopefully I can still pretend these troublesome extensions don't exist when writing my own code...) I think, the list of accepted extensions is well chosen. And don't worry, the extensions I'm talking about mainly, are easy to comprehend and very useful, for example multi-parameter type classes and rank-n types. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife = sex) http://blog.ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
The great that's why is as follows: when you have an abstraction, then it is sufficient to hold the abstraction in mind instead of the whole concrete implementation. That's the whole purpose of abstraction, after all, be it maths or programming. Let me illustrate this. Suppose you are developing a library that, for instance, has a notion of settings and is able to combine two settings with several strategies for resolving conflicts between settings with duplicate keys: take the first setting, the second, none, or make a setting with multiple values. For example, an alternative GetOpt. Suppose you don't know what a monoid is and don't even know that such an abstraction exists. Now, when you're reasoning about the library, you have to think If I combine 3 settings, should the order of combination matter? Hmm, would be nice if it didn't. Also, what should I return if someone queries for a non-existent key in the settings? Should I return an empty list, or a Nothing, or throw an error, or what? Do empty settings make sense? etc. If you're smart and lucky, you will most probably get most things right and inconsciously create a settings monoid. Now, if you know what a monoid is, you immediately recognize that your settings should be a monoid by nature, and now you have absolutely no doubt that you should make the combining operation associative and provide a unit; and you use this monoid abstraction all the time you are designing this library. Now, you don't think about whether you should throw an error or return a Nothing for an empty key; but instead you think about which result would behave like a unit for the monoid, being motivated by mathematical principles rather than pure intuition. You end up designing a mathematically sound library whose principles make sence and has no design flaws, at least in the mathematically sound part, even if you never actually use the word monoid in the documentation. Also, read this post by sigfpe that motivated me to learn abstract algebra in depth (I am yet in the beginning, however), and, overall, this is a breathtaking post: http://sigfpe.blogspot.com/2008/11/approach-to-algorithm-parallelisation.html - this is where I started to appreciate the power of mathematical abstractions even more. 2009/1/17 david48 dav.vire+hask...@gmail.com: All of this is still lacking the great why : why/how an abstraction so generic can be useful. I'm starting to believe that the only reason to make a datatype an instance of Monoid is... why not ! since it's not hard to find an associative operation and a neutral element. -- Eugene Kirpichov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
G'day all. Quoting Gracjan Polak gracjanpo...@gmail.com: 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. I don't know about you, bu the word module threw me. That is probably the one name from algebra that clashes with computer science too much. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
G'day all. 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... Presumably not quantum mechanics. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Andrew Coppin andrewcop...@btinternet.com wrote:
I would suggest that ExistentiallyQuantifiedTypeVariables would be an
improvement [...]
That must be a joke. Typing the long extension names in LANGUAGE
pragmas over and over again is tiring and annoying enough already. We
really don't need even longer names, and your improvement fills up
almost half of the width of an 80 characters terminal.
I can't await the next Haskell standard, where at last all those
extensions are builtin. For the remaining extensions, I strongly
suggest abbreviations and a more convenient way to specify them. For
example an import-like statement:
uses MPTC
uses FlexInst
instead of:
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife = sex)
http://blog.ertes.de/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 11:54 PM, ChrisK hask...@list.mightyreason.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
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 apfel...@quantentunnel.de: 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
On Fri, Jan 16, 2009 at 3:46 AM, Eugene Kirpichov ekirpic...@gmail.comwrote: 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. See annocpan http://annocpan.org for prior art. Are there any drawbacks to this? 2009/1/16 Apfelmus, Heinrich apfel...@quantentunnel.de: 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
2009/1/16 Apfelmus, Heinrich apfel...@quantentunnel.de: 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Ketil Malde ketil at malde.org writes: On Thu, Jan 15, 2009 at 07:46:02PM +, 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
On Fri, 2009-01-16 at 17:58 +, 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Well-put. Thanks! - Conal On Fri, Jan 16, 2009 at 1:52 AM, Dougal Stanton ith...@gmail.com wrote: On Thu, Jan 15, 2009 at 11:54 PM, ChrisK hask...@list.mightyreason.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
david48 wrote: 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. Good account of the current documentation situation. Hm, what about the option of opening Bird's Introduction on Functional Programming using Haskell in the section about fold? Monoid is on page 62 in the translated copy I've got here. Does Hutton's book mention them? Real World Haskell? I don't think that I would try to learn a programming language, for example Python, without obtaining a paper book on it. Regards, H. Apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
John Goerzen jgoer...@complete.org writes: Wikipedia's first sentence about monoids is: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. Which is *not* intuitive to someone that comes from a background in any other programming language. Instead of Wikipedia, why not try a dictionary? Looking up monoid using dictionary.com: An operator * and a value x form a monoid if * is associative and x is its left and right identity. On the other hand, appendable doesn't seem to be a word, and while you can infer that it means something that can be appended to, that's only half of the story... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Ross Mellgren rmm-hask...@z.odi.ac writes: Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. I second this, many of the docs are sorely lacking examples (and there are of course docs that simply reference a paper, which is usually too long to be helpful in the short term...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Lennart Augustsson lenn...@augustsson.net writes: By no means do I suggest that Wikipedia should replace Haskell library documentation. I think the libraries should be documented in a mostly stand-alone way (i.e., no references to old papers etc.). In the case of Monoid, a few lines of text is enough to convey the meaning of it and gives an example. I don't think references to old papers are a bad thing (they might be good papers), but such references should certainly not be a replacement for a brief explanation and helpful example! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
John == John Goerzen jgoer...@complete.org writes: John I guess the bottom line question is: who is Haskell for? Category John theorists, programmers, or both? I'd love it to be for both, but John I've got to admit that Brian has a point that it is trending to John the first in some areas. Thank you for so nicely put it together... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpvadDX8GCob.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Andrew == Andrew Coppin andrewcop...@btinternet.com writes: Andrew If we *must* insist on using the most obscure possible name for Andrew everything, can we at least write some documentation that Andrew doesn't require a PhD to comprehend?? (Anybody who attempts to Andrew argue that monoid is not actually an obscure term has clearly Andrew lost contact with the real world.) *thumb up* Let the elitists enjoy in obscure terminology, but pls. write docs for programmers (with examples included). Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpfDNuxLEyfJ.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 9:04 AM, m...@justinbogner.com wrote: John Goerzen jgoer...@complete.org writes: Wikipedia's first sentence about monoids is: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. Which is *not* intuitive to someone that comes from a background in any other programming language. Instead of Wikipedia, why not try a dictionary? Looking up monoid using dictionary.com: An operator * and a value x form a monoid if * is associative and x is its left and right identity. On the other hand, appendable doesn't seem to be a word, and while you can infer that it means something that can be appended to, that's only half of the story... Monoid isn't something I came across and didn't understand, its something I should have been using for a long time before I discovered it. But it never jumped out at me when I was browsing the library documentation tree. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Yes! The library documentation tree has a way of making everything seem equally important, when that is not the case. This is why we need well-crafted tutorials and books. 2009/1/15 David Fox dds...@gmail.com: Monoid isn't something I came across and didn't understand, its something I should have been using for a long time before I discovered it. But it never jumped out at me when I was browsing the library documentation tree. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Thomas DuBuisson wrote: How does forcing them to learn proposed terminology such as `Appendable' help here? Learners of Haskell do still need to learn what the new word means. The contention is that 'Appendable' is an intuitive naming that people will already have a rudimentary grasp of. This as opposed to Monoid, which absolutely requires looking up for the average coder. Intuition tells me: * 'Appendable' add an element to the back of a (finite) linear collection. * There is a 'Prependable' somewhere that add the element to the front. * There is an inverse 'pop' or 'deque' operation nearby. Absolutely none of those things are true. Let's try for 'Mergeable' * mconcat joins two collections, not a collection and an element. * Is should be a split operation. The above is true for the list instance, but false in general. Look at the instances already given that violate the collection idea: Monoid Any Monoid All Monoid (Last a) Monoid (First a) Num a = Monoid (Product a) Num a = Monoid (Sum a) And I don't even see an (Ord a)=(Max a) or a Min instance. 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. ONE. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Manlio Perillo wrote: I'm fine with current names. However I would like to see better documentation, and examples. You can't just have in the documentation: this is xxx from yyy branch of mathematics, see this paper. You should explain how (and why) to use xxx. Absolutely this! I would rather have to look up Monoid than see Appendable used for operations that don't fit my notion of appending. I don't care much what things are called as long as it's accurate. Even so, I typically find Haskell's documentation to be not very helpful, because it's aimed towards category theorists. That is, Haskell documentation often seems to take the approach The reader is familiar with [branch of abstract mathematics], so knows all these concepts. The job of the documentation is to show how standard terminology from [branch of abstract math] is written in Haskell. The problem with this is that most people aren't familiar with general abstract nonsense, and this documentation is useless for those, i.e. most, people. In fact, most people don't care about how abstract nonsense is written in Haskell. They care about solving their particular problems, and are only interested in abstract nonsense to the sense that it can be useful in solving those problems. Overwhelmingly the documentation does not show how particular concepts apply to actual programming problems, or any concrete problems at all. Here is the current complete documentation for Data.Monoid 'mappend', which happens to be a good example of which I speak: An associative operation That could mean anything. There are lots of associative operations. Should I believe the name that somehow this operation is append-like? If so, and I'm using a list instance, where are items appended to? Is it an append onto the tail of the list, or is it really a cons? I would expect the documentation to cover this, but it doesn't. Far too often the documentation fails to provide this sort of useful, practical information. This is the problem faced by an abstract-nonsense unaware user: I want to accomplish [some task]. Some blogger wrote that [monoids, functors, arrows, etc.] provide a good solution. But when I look up [monoids, functors, etc.] in [some academic paper], it doesn't show how these concepts apply to the problem at hand, or indeed any programming problem at all. In fact, I can't even understand what the doc says without first learning about [even more abstract stuff]. So now the user needs to develop a strong background in [some abstract topic] he/she doesn't care about just to figure out *if* that abstract topic could possibly be useful. At this point most users will give up. If instead they had access to documentation that says [Monoids] are useful programming abstractions because they can solve problems A, B, and C in these manners, and incidentally they can do all this other stuff too, the same users would not only stick with Haskell longer, they would increase their theoretical awareness at the same time. I think even the most elitist Haskell users would think this is a good outcome. Of course this better documentation would need to be written. Somebody upthread (Duncan?) suggested that suitable individuals may not exist, and I agree with that. Of people who understand the material well enough to document it, many are busy doing other work, and many have no interest or are ideologically opposed to writing documentation of this type. This situation reminds me very much of a particularly well-known article by Milton Babbitt, Who Cares If You Listen. I expect that many Haskellers would find it interesting at the least. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
