Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
* John Goerzen jgoer...@complete.org [2009-01-15 10:15:36 -0600]: If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid I can immediately figure out what the first one means. I think that's deceptively misleading. Sure, list1 `mappend` list2 is concatenation, of which Appendable is suggestive; but what on earth does it mean to append a number to another number, or append a function to another function? By doing some research, you can find out the answer, but if you start off with a name that means nothing to you, I suspect you'll be less confused than if you start off with a name that seems like it makes sense, but actually doesn't. (Of course, the name of mappend itself doesn't exactly help...) I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. I don't really understand why Appendable is specifically a programmer-friendly name; it doesn't really have any existing meaning elsewhere in programming languages, for example. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
* Andrew Coppin andrewcop...@btinternet.com [2009-01-16 22:20:35 +]: A problem I see a lot of [and other people have mentioned this] is that a lot of documentation presents highly abstracted things, and gives *no hint* of why on earth these might possibly be useful for something. I think this is definitely something that should be addressed by better documentation of some kind. Unfortunately, this is quite possibly the hardest kind of knowledge to put down into words: before you learn the concepts, you don't know them, so you can't write about them, but after you learn them, they seem so obvious that you don't know how to describe them. (At least, this is typically the problem I have; I can answer questions about something easily, maybe even walk someone through understanding it, but I can't draft a document that will describe things adequately to a newbie). This problem is worse in Haskell than other languages, simply because abstractions are used more frequently and pervasively in Haskell. In many other languages, these abstractions are perfectly applicable, but actually encoding them in the language is simply too unwieldy. Thus, while the abstraction may be present as a fuzzy concept at the back of the programmer's mind, or even as a design pattern, the code people actually work with tends to be at a more concrete level, despite the more limited possibilities of code reuse at this level. This ties in with the complaint that Haskell variable / parameter names aren't descriptive enough. You frequently hear things like why call it 'xs' instead of 'applicableItems'?; often, the answer to this is simply that the value in question is something so general that you cannot describe it more specifically than a list of something or other. Haskell code is being written at a higher level of abstraction than the newcomer is used to, and thus the highly abstract names are mistaken for vague or imprecise names. Now, it's all very well to explain the reasons behind this to the newcomer, but they're still left in a position where they can't find the tools they need to solve a particular problem. They're used to looking for the concrete tools they need to do some task or another, which aren't there; instead, there are all these abstract tools which can perform the concrete task at hand, but what is really needed is help finding the abstract tool for the concrete task at hand, or even abstracting the concrete task at hand, thus making the choice of abstract tool(s) an obvious one. Sure, you can pop into #haskell and hopefully find someone to walk you through the processes until you begin to understand the abstractions yourself, but I think we (I almost hesitate to include myself, given my own relatively miniscule Haskell knowledge) can do better than this in terms of helping people unfamiliar with these concepts. Also, more importantly, I'm referring specifically to teaching *programmers* the concepts; I have no problem with *naming* things based on category theory or abstract algebra or quantum mechanics, but I should not be required to learn half a dozen fields of mathematics or physics in order to *use* things. Writing about how Monads in Haskell relate to Monads in category theory is of interest to category theorists, but isn't something programmers should be reading. Hopefully nothing I've said here comes as a surprise to anyone, and I'd be surprised if there were many serious objections to any of it, but perhaps it does need to be highlighted more prominently as an important area to improve if Haskell is to grow as a programming language. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, 15 Jan 2009, John Goerzen wrote: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like Appendable. But no, Haskell calls this pattern a Monoid. I risk to repeat someones point, since I have not read the entire thread ... What I don't like about the Monoid class is, that its members are named mempty and mappend. It may be either (also respecting qualified import) Monoid(identity, op) or Appendable(empty, append) where only the first one seems reasonable, since the Sum monoid and its friends do not append anything. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
John Goerzen schrieb: Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS: APPENDABLE MEANS MONOID in the haddock docs ;-) We already have a problem with this: Haskell 98 uses intuitive names for the numeric type classes. It introduces new names, which do not match the names of common algebraic structures. Why is a type Num (numeric?), whenever it supports number literals, (+) and (*)? Why not just number literals? Why not also division? The numeric type hierarchy of Haskell must be learned anyway, but the user learns terms he cannot use outside the Haskell world. Ring and Field are harder to learn first, but known and precise terms. (And if you don't like to learn the names, just write functions without signatures and let GHCi find out the signatures with the appropriate class constraints.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Tue, 2009-01-20 at 23:41 +0100, Henning Thielemann wrote: On Thu, 15 Jan 2009, John Goerzen wrote: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like Appendable. But no, Haskell calls this pattern a Monoid. I risk to repeat someones point, since I have not read the entire thread ... What I don't like about the Monoid class is, that its members are named mempty and mappend. It may be either (also respecting qualified import) Monoid(identity, op) +1 If we're going to change any names in the standard library at all, this is the change we should make. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, 2009-01-15 at 18:10 -0500, Cale Gibbard wrote: My personal preference would be: class Monoid m where zero :: m (++) :: m - m - m (in the Prelude of course) - Cale I've tried doing this (and making more widespread use of typeclassed operations) by writing my own AltPrelude. Unfortunately there is still a lot of 'unrebindable' syntax (list comprehensions, 'error' forced to exist in Monad, if-then-else not using nearest Bool, etc) which makes this hard to achieve. signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sun, 18 Jan 2009 08:51:10 +0100 david48 dav.vire+hask...@gmail.com wrote: On Sat, Jan 17, 2009 at 11:19 PM, Dan Piponi dpip...@gmail.com wrote: On Sat, Jan 17, 2009 at 1:47 AM, david48 dav.vire+hask...@gmail.com wrote: why would I need to write a running count this way instead of, for example, a non monadic fold, which would probably result in clearer and faster code? Maybe my post here will answer some questions like that: http://sigfpe.blogspot.com/2009/01/haskell-monoids-and-their-uses.html Just wow. Very very nice post. one to keep in the wikis. Thank you *very* much, Dan, for writing this. Seconded. And I hope, Dan, that you will find time at some point to write about those other things you said at the end that you didn't have time to write about! -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sat, Jan 17, 2009 at 09:12:32PM -0500, a...@spamcop.net wrote: And FWIW, I agree with everyone who has commented that the documentation is inadequate. It'd be nice if there was some way to contribute better documentation without needing checkin access to the libraries. There is. The current state of the docs may be viewed at http://www.haskell.org/ghc/dist/current/docs/libraries/ Anyone can check out the darcs repos for the libraries, and post suggested improvements to the documentation to librar...@haskell.org (though you have to subscribe). It doesn't even have to be a patch. Sure, it could be smoother, but there's hardly a flood of contributions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
ross: On Sat, Jan 17, 2009 at 09:12:32PM -0500, a...@spamcop.net wrote: And FWIW, I agree with everyone who has commented that the documentation is inadequate. It'd be nice if there was some way to contribute better documentation without needing checkin access to the libraries. There is. The current state of the docs may be viewed at http://www.haskell.org/ghc/dist/current/docs/libraries/ Anyone can check out the darcs repos for the libraries, and post suggested improvements to the documentation to librar...@haskell.org (though you have to subscribe). It doesn't even have to be a patch. Sure, it could be smoother, but there's hardly a flood of contributions. I imagine if we set up a wiki-like system where the entire hackage docs could be edited, as well as viewed, we would end up with a flood. A modification to haddock perhaps, that sends edits to generated docs to libraries@ ? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
2009/1/18 Don Stewart d...@galois.com: ross: On Sat, Jan 17, 2009 at 09:12:32PM -0500, a...@spamcop.net wrote: And FWIW, I agree with everyone who has commented that the documentation is inadequate. It'd be nice if there was some way to contribute better documentation without needing checkin access to the libraries. There is. The current state of the docs may be viewed at http://www.haskell.org/ghc/dist/current/docs/libraries/ Anyone can check out the darcs repos for the libraries, and post suggested improvements to the documentation to librar...@haskell.org (though you have to subscribe). It doesn't even have to be a patch. Sure, it could be smoother, but there's hardly a flood of contributions. I imagine if we set up a wiki-like system where the entire hackage docs could be edited, as well as viewed, we would end up with a flood. A modification to haddock perhaps, that sends edits to generated docs to libraries@ ? This has come up many times lately. I've created a ticket for it: http://trac.haskell.org/haddock/ticket/72 If anyone has suggestions for design or implementation of a system like this, don't hesitate to post to this ticket! David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
david.waern: 2009/1/18 Don Stewart d...@galois.com: ross: On Sat, Jan 17, 2009 at 09:12:32PM -0500, a...@spamcop.net wrote: And FWIW, I agree with everyone who has commented that the documentation is inadequate. It'd be nice if there was some way to contribute better documentation without needing checkin access to the libraries. There is. The current state of the docs may be viewed at http://www.haskell.org/ghc/dist/current/docs/libraries/ Anyone can check out the darcs repos for the libraries, and post suggested improvements to the documentation to librar...@haskell.org (though you have to subscribe). It doesn't even have to be a patch. Sure, it could be smoother, but there's hardly a flood of contributions. I imagine if we set up a wiki-like system where the entire hackage docs could be edited, as well as viewed, we would end up with a flood. A modification to haddock perhaps, that sends edits to generated docs to libraries@ ? This has come up many times lately. I've created a ticket for it: http://trac.haskell.org/haddock/ticket/72 If anyone has suggestions for design or implementation of a system like this, don't hesitate to post to this ticket! Added to the entry on the proposals tracker, http://www.reddit.com/r/haskell_proposals/ If nothing else, this would make a good SoC project. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast jonathancc...@fastmail.fm wrote: 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 well thank you for the example, if I may ask something: why would I need to write a running count this way instead of, for example, a non monadic fold, which would probably result in clearer and faster code (IMHO) ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Cory Knapp wrote: Actually, that was part of my point: When I mention Haskell to people, and when I start describing it, they're generally frightened enough by the focus on pure code and lazy evaluation-- add to this the inherently abstract nature, and we can name typeclasses cuddlyKitten, and the language is still going to scare J. R. Programmer. By inherently mathematical nature, I didn't mean names like monoid and functor, I meant *concepts* like monoid and functor. Not that either of them are actually terribly difficult; the problem is that they are terribly abstract. That draws a lot of people (especially mathematicians), but most people who aren' drawn by that are hugely put off-- whatever the name is. So, I guess my point is that the name is irrelevant: the language is going to intimidate a lot of people who are intimidated by the vocabulary. Oh, I don't know. I have no idea what the mathematical definition of functor is, but as far as I can tell, the Haskell typeclass merely allows you to apply a function simultaneously to all elements of a collection. That's pretty concrete - and trivial. If it weren't for the seemingly cryptic name, nobody would think twice about it. (Not sure exactly what you'd call it though...) A monoid is a rather more vague concept. (And I'm still not really sure why it's useful on its own. Maybe I just haven't had need of it yet?) I think, as somebody suggested about monad, the name does tend to inspire a feeling of hey, this must be really complicated so that even after you've understood it, you end up wondering whether there's still something more to it than that. But yes, some people are definitely put off by the whole abstraction of abstractions of abstraction thing. I think we probably just need some more concrete examples to weight it down and make it seem like something applicable to the real world. (Thus far, I have convinced exactly *one* person to start learning Haskell. This person being something of a maths nerd, their main complaint was not about naming or abstraction, but about the implicitness of the language, and the extreme difficulty of visually parsing it. Perhaps not surprising comming from a professional C++ programmer...) At the same time, I think everyone is arguing *for* better documentation. And you're probably right: better documentation will bring the abstract nonsense down to earth somewhat. Amen! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
2009/1/17 Andrew Coppin andrewcop...@btinternet.com: Cory Knapp wrote: Actually, that was part of my point: When I mention Haskell to people, and when I start describing it, they're generally frightened enough by the focus on pure code and lazy evaluation-- add to this the inherently abstract nature, and we can name typeclasses cuddlyKitten, and the language is still going to scare J. R. Programmer. By inherently mathematical nature, I didn't mean names like monoid and functor, I meant *concepts* like monoid and functor. Not that either of them are actually terribly difficult; the problem is that they are terribly abstract. That draws a lot of people (especially mathematicians), but most people who aren' drawn by that are hugely put off-- whatever the name is. So, I guess my point is that the name is irrelevant: the language is going to intimidate a lot of people who are intimidated by the vocabulary. Oh, I don't know. I have no idea what the mathematical definition of functor is, but as far as I can tell, the Haskell typeclass merely allows you to apply a function simultaneously to all elements of a collection. That's pretty concrete - and trivial. If it weren't for the seemingly cryptic name, nobody would think twice about it. (Not sure exactly what you'd call it though...) No, a functor is a more wide notion than that, it has nothing to do with collections. An explanation more close to truth would be A structure is a functor if it provides a way to convert a structure over X to a structure over Y, given a function X - Y, while preserving the underlying 'structure', where preserving structure means being compatible with composition and identity. Collections are one particular case. Another case is just functions with fixed domain A: given a structure of type [A-]X and a function of type X - Y, you may build an [A-]Y. Yet another case are monads (actually, the example above is the Reader monad): given a monadic computation of type 'm a' and a function a - b, you may get a computation of type m b: instance (Monad m) = Functor m where fmap f ma = do a - ma; return (f a) There are extremely many other examples of functors; they are as ubiquitous as monoids and monads :) -- Eugene Kirpichov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Thinking that Functor allows you to apply a function to all elements in a collection is a good intuitive understanding. But fmap also allows applying a function on elements of things that can't really be called collections, e.g., the continuation monad. -- Lennart On Sat, Jan 17, 2009 at 11:17 AM, Andrew Coppin andrewcop...@btinternet.com wrote: Cory Knapp wrote: Actually, that was part of my point: When I mention Haskell to people, and when I start describing it, they're generally frightened enough by the focus on pure code and lazy evaluation-- add to this the inherently abstract nature, and we can name typeclasses cuddlyKitten, and the language is still going to scare J. R. Programmer. By inherently mathematical nature, I didn't mean names like monoid and functor, I meant *concepts* like monoid and functor. Not that either of them are actually terribly difficult; the problem is that they are terribly abstract. That draws a lot of people (especially mathematicians), but most people who aren' drawn by that are hugely put off-- whatever the name is. So, I guess my point is that the name is irrelevant: the language is going to intimidate a lot of people who are intimidated by the vocabulary. Oh, I don't know. I have no idea what the mathematical definition of functor is, but as far as I can tell, the Haskell typeclass merely allows you to apply a function simultaneously to all elements of a collection. That's pretty concrete - and trivial. If it weren't for the seemingly cryptic name, nobody would think twice about it. (Not sure exactly what you'd call it though...) A monoid is a rather more vague concept. (And I'm still not really sure why it's useful on its own. Maybe I just haven't had need of it yet?) I think, as somebody suggested about monad, the name does tend to inspire a feeling of hey, this must be really complicated so that even after you've understood it, you end up wondering whether there's still something more to it than that. But yes, some people are definitely put off by the whole abstraction of abstractions of abstraction thing. I think we probably just need some more concrete examples to weight it down and make it seem like something applicable to the real world. (Thus far, I have convinced exactly *one* person to start learning Haskell. This person being something of a maths nerd, their main complaint was not about naming or abstraction, but about the implicitness of the language, and the extreme difficulty of visually parsing it. Perhaps not surprising comming from a professional C++ programmer...) At the same time, I think everyone is arguing *for* better documentation. And you're probably right: better documentation will bring the abstract nonsense down to earth somewhat. Amen! ___ 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] Comments from OCaml Hacker Brian Hurt
On Sat, Jan 17, 2009 at 7:33 AM, Lennart Augustsson lenn...@augustsson.netwrote: Thinking that Functor allows you to apply a function to all elements in a collection is a good intuitive understanding. But fmap also allows applying a function on elements of things that can't really be called collections, e.g., the continuation monad. I hadn't even thought about fmap for continuations... interesting! It falls out of the logic though doesn't it? I'm not one to throw all the cool mathematical and logical thinking out for simpler terms or not covering the full usefulness of certain abstractions. I know Haskell allows for lazy evaluation (as an implementation of non-strictness) but Haskell programmers are NOT allowed to be lazy :-) Try learning the terms that are there... and ask for help if you need help... most of us are pretty helpful! Improving documentation can pretty much *always* be done on any project, and it looks like that's coming out of this long thread that won't die, so kudos to the ones being the gadflies in this instance. It really looked at first like a long troll, but I think something very useful is going to come out of this! Dave -- Lennart On Sat, Jan 17, 2009 at 11:17 AM, Andrew Coppin andrewcop...@btinternet.com wrote: Cory Knapp wrote: Actually, that was part of my point: When I mention Haskell to people, and when I start describing it, they're generally frightened enough by the focus on pure code and lazy evaluation-- add to this the inherently abstract nature, and we can name typeclasses cuddlyKitten, and the language is still going to scare J. R. Programmer. By inherently mathematical nature, I didn't mean names like monoid and functor, I meant *concepts* like monoid and functor. Not that either of them are actually terribly difficult; the problem is that they are terribly abstract. That draws a lot of people (especially mathematicians), but most people who aren' drawn by that are hugely put off-- whatever the name is. So, I guess my point is that the name is irrelevant: the language is going to intimidate a lot of people who are intimidated by the vocabulary. Oh, I don't know. I have no idea what the mathematical definition of functor is, but as far as I can tell, the Haskell typeclass merely allows you to apply a function simultaneously to all elements of a collection. That's pretty concrete - and trivial. If it weren't for the seemingly cryptic name, nobody would think twice about it. (Not sure exactly what you'd call it though...) A monoid is a rather more vague concept. (And I'm still not really sure why it's useful on its own. Maybe I just haven't had need of it yet?) I think, as somebody suggested about monad, the name does tend to inspire a feeling of hey, this must be really complicated so that even after you've understood it, you end up wondering whether there's still something more to it than that. But yes, some people are definitely put off by the whole abstraction of abstractions of abstraction thing. I think we probably just need some more concrete examples to weight it down and make it seem like something applicable to the real world. (Thus far, I have convinced exactly *one* person to start learning Haskell. This person being something of a maths nerd, their main complaint was not about naming or abstraction, but about the implicitness of the language, and the extreme difficulty of visually parsing it. Perhaps not surprising comming from a professional C++ programmer...) At the same time, I think everyone is arguing *for* better documentation. And you're probably right: better documentation will bring the abstract nonsense down to earth somewhat. Amen! ___ 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
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sat, Jan 17, 2009 at 1:47 AM, david48 dav.vire+hask...@gmail.com wrote: why would I need to write a running count this way instead of, for example, a non monadic fold, which would probably result in clearer and faster code? Maybe my post here will answer some questions like that: http://sigfpe.blogspot.com/2009/01/haskell-monoids-and-their-uses.html -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
G'day all. Quoting John Goerzen jgoer...@complete.org: If I see Appendable I can guess what it might be. If I see monoid, I have no clue whatsoever, because I've never heard of a monoid before. Any sufficiently unfamiliar programming language looks like line noise. That's why every new language needs to use curly braces. If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid I can immediately figure out what the first one means. No you can't. It is in no way clear, for example, that Integers with addition are Appendable. I'm not saying that Monoid is the most pragmatically desirable term, merely that Appendable is misleading. And FWIW, I agree with everyone who has commented that the documentation is inadequate. It'd be nice if there was some way to contribute better documentation without needing checkin access to the libraries. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sat, 2009-01-17 at 11:07 +, Andrew Coppin wrote:
Anton van Straaten wrote:
Niklas Broberg wrote:
I still think existential quantification is a step too far though. :-P
Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
on logic. In fact, I would argue that far more people probably know
what existential quantification is than that know what a monoid is.
:-)
Andrew's core objection here seems reasonable to me. It was this:
{-# LANGUAGE ExistentialQuantification #-} is an absurd name and
should be changed to something that, at a minimum, tells you it's
something to do with the type system.
But I suspect I part company from Andrew in thinking that something
like ExistentiallyQuantifiedTypes would be a perfectly fine alternative.
I would suggest that ExistentiallyQuantifiedTypeVariables would be an
improvement on just ExistentialQuantification - but I'd still prefer the
less cryptic HiddenTypeVariables. (Since, after all, that's all this
actually does.)
Consider the expression (I hate this expression)
case error Urk! of
x - error Yak!
When you translate this into System F, you have to come up with a fresh
type variable for the type of x, even though that variable is unused in
the type of the entire expression.
Which is what HiddenTypeVariables brings to my mind every time you use
it.
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sat, 2009-01-17 at 10:47 +0100, david48 wrote: On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast jonathancc...@fastmail.fm wrote: 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 well thank you for the example, if I may ask something: why would I need to write a running count this way instead of, for example, a non monadic fold, which would probably result in clearer and faster code (IMHO) ? I agree with you, for this special case. (Did I remember to post the simpler solution: sum $ map countFunction $ getValues somewhere in this thread?) But, just like the (utterly useless) C++ example translated to Haskell in another thread, the monadic form provides a framework you can fill out with larger code fragments. So if the while loop above was replaced with a larger control structure, maybe recursion over a custom tree type, then standard recusion operators, such as folds, may be inapplicable. In that case, moving to a Writer monad can get you some of the advantage back, so you don't end up passing your accumulator around everywhere by hand. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sat, Jan 17, 2009 at 11:19 PM, Dan Piponi dpip...@gmail.com wrote: On Sat, Jan 17, 2009 at 1:47 AM, david48 dav.vire+hask...@gmail.com wrote: why would I need to write a running count this way instead of, for example, a non monadic fold, which would probably result in clearer and faster code? Maybe my post here will answer some questions like that: http://sigfpe.blogspot.com/2009/01/haskell-monoids-and-their-uses.html Just wow. Very very nice post. one to keep in the wikis. Thank you *very* much, Dan, for writing this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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. 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
2009/1/15 Derek Elkins derek.a.elk...@gmail.com: On Thu, 2009-01-15 at 18:27 +, Lennart Augustsson wrote: On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore p.f.mo...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 jgoer...@complete.org wrote: Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like Appendable. But no, Haskell calls this pattern a Monoid. Yep, that's all a monoid is- something with an empty state and the ability to append things to the end. Well, it's a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them monads instead of warm, fluffy things. Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! He went on to add: If you?re not a category theorists, and you're learning (or thinking of learning) Haskell, don't get scared off by names like monoid or functor. And ignore anyone who starts their explanation with references to category theory- you don't need to know category theory, and I don't think it helps. I'd echo that one too. -- John ___ 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] Comments from OCaml Hacker Brian Hurt
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 thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, 2009-01-15 at 18:41 -0500, Cale Gibbard wrote: 2009/1/15 Andrew Coppin andrewcop...@btinternet.com: 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Fri, Jan 16, 2009 at 5:39 AM, Creighton Hogg wch...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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. -- fli...@flippac.org 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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. -- fli...@flippac.org 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Fri, Jan 16, 2009 at 1:23 PM, Philippa Cowderoy fli...@flippac.org 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 @newt...@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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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! -- fli...@flippac.org 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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. -- fli...@flippac.org 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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! :-) 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. -- fli...@flippac.org '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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 +, 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 @newt...@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 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] Comments from OCaml Hacker Brian Hurt
On Fri, Jan 16, 2009 at 8:39 AM, Duncan Coutts duncan.cou...@worc.ox.ac.uk 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 @newt...@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 d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Fri, Jan 16, 2009 at 12:19 PM, Ross Paterson r...@soi.city.ac.uk 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 d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Steve Schafer st...@fenestra.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Thanks, Bob! I'm with on both counts: Monad is misrepresented as central in code composition; and (Monad m) = (a - m b) - (m a - m b) is a much nicer type (for monadic extension), only in part because it encourages retraining away from sequential thinking. I encountered this nicer formulation only recently, and am glad to finally understand why I've been so uncomfortable with the type of (=). - Conal 2009/1/15 Thomas Davie tom.da...@gmail.com On 15 Jan 2009, at 16:34, John Goerzen wrote: Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: [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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Andrew Coppin wrote: Abstraction is a great thing to have. I'd just prefer it to not look so intimidating; What makes it look intimidating? If the answer is it looks intimidating because the documentation consists of nothing more than a mathematical term, without a definition, and a reference to a paper, then I agree with you, and it seems so does most everyone else. But if the intimidation factor is coming from preconceptions like it's mathy, therefore it's scary; or it's an unfamiliar term, therefore it's scary, then I think that's something that the reader needs to work on, not the designers and documenters of Haskell. Computer programming is full of terms that need to be learned, and if anything terms like monoid are fantastically useful because they're so precisely defined, and are part of a larger well-defined universe. I would have thought that any true programmer (like a true Scotsman) could appreciate the separation of concerns and factoring that's gone into abstract algebra. The idea that it's not relevant to programming (an implication that was made earlier) misses a bigger picture. How could a collection of very general structures associated with general operations *not* be relevant to programming? Given that mathematicians have spent centuries honing these useful structures, and given that plenty of applications for them in programming have been identified, it would virtually be a crime not to use them where they make sense. (A crime against... humanity? I look forward to the trials at The Hague of errant programming language and library designers.) the majority of these abstractions aren't actually complicated in any way, once you learn what they are... Which underscores my question - what's the source of the intimidation, then? If you're going to implement an abstraction for monoids, you might as well call it monoid. On that I agree. Excellent. 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. That's only one side of the story. Quite a few examples of monoid use has been given in this thread. How many of them are actually uses of Appendable, I wonder? There's an equal and opposite risk of under-generalizing here: if you design something to take an Appendable argument, and if Appendable precludes other kinds of non-appendable monoids, you may be precluding certain argument types that would otherwise be perfectly reasonable, and building in restrictions to your code for no good reason - restrictions that don't relate to the actual requirements of the code. Of course, if you're just saying you want Appendable as an alias for Monoid, that's reasonable (I mentioned that possibility in another message), but a similar effect might be achieved by documentation that points out that appendability is one application for monoids. A more suitable friendly synonym for monoid might be combinable, which can more easily be defended: a binary operation combines its arguments by definition, since it turns two arguments into one result. But again, it would make more sense to observe in the documentation that monoids are combinable things, for various reasons that others have already addressed. I like the reasons that Manuel Chakravarty gave - in part, 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. If anyone finds that scary, my advice to them is to wear sunglasses until they get used to it. In practice, what that means is don't fuss over the fact that there's a lot of unfamiliar knowledge that seems important -- yes, it is important, but you can use Haskell quite well without knowing it all. I speak from experience, since I'm not a mathematician, let alone a category theorist. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Andrew Coppin wrote: Duncan Coutts wrote: [Monoids are] used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. OK, well then my next question would be in what way 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... It makes those things generically combinable. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Cory Knapp wrote: As far as I know, one of the draws of Haskell is the inherent mathematical nature of it. It's also simultaneously one of the biggest things that puts people off. Perhaps as we can curb this with sufficient documentation, as others have suggested. But there's a deeper problem here, one that can't be resolved inside the Haskell community. The problem is that the Math?! Scary! Gross! attitude that's so pervasive in our society is hardly less pervasive in the computer subculture. No arguments here! However, that at least *is* completely beyond our power to alter. Unfortunately. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Anton van Straaten wrote: Andrew Coppin wrote: Abstraction is a great thing to have. I'd just prefer it to not look so intimidating; What makes it look intimidating? If the answer is it looks intimidating because the documentation consists of nothing more than a mathematical term, without a definition, and a reference to a paper, then I agree with you, and it seems so does most everyone else. But if the intimidation factor is coming from preconceptions like it's mathy, therefore it's scary; or it's an unfamiliar term, therefore it's scary, then I think that's something that the reader needs to work on, not the designers and documenters of Haskell. I guess you're right. A problem I see a lot of [and other people have mentioned this] is that a lot of documentation presents highly abstracted things, and gives *no hint* of why on earth these might possibly be useful for something. (E.g., coarbitrary. Wuh??) Perhaps fixing this *would* help make Haskell more accessible. (The other problem of course is that what documentation that does exist is scattered all over the place...) I still think existential quantification is a step too far though. :-P ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I still think existential quantification is a step too far though. :-P Seriously, existential quantification is a REALLY simple concept, that you would learn week two (or maybe three) in any introductory course on logic. In fact, I would argue that far more people probably know what existential quantification is than that know what a monoid is. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Niklas Broberg wrote:
I still think existential quantification is a step too far though. :-P
Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
on logic. In fact, I would argue that far more people probably know
what existential quantification is than that know what a monoid is.
:-)
Andrew's core objection here seems reasonable to me. It was this:
{-# LANGUAGE ExistentialQuantification #-} is an absurd name and
should be changed to something that, at a minimum, tells you it's
something to do with the type system.
But I suspect I part company from Andrew in thinking that something like
ExistentiallyQuantifiedTypes would be a perfectly fine alternative.
Anton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Fri, 2009-01-16 at 18:14 -0500, Anton van Straaten wrote:
Niklas Broberg wrote:
I still think existential quantification is a step too far though. :-P
Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
on logic. In fact, I would argue that far more people probably know
what existential quantification is than that know what a monoid is.
:-)
Andrew's core objection here seems reasonable to me. It was this:
{-# LANGUAGE ExistentialQuantification #-} is an absurd name and
should be changed to something that, at a minimum, tells you it's
something to do with the type system.
But I suspect I part company from Andrew in thinking that something like
ExistentiallyQuantifiedTypes would be a perfectly fine alternative.
+1
(Although shouldn't it really be ExistentiallyQuantifiedConstructorTypes
or something? If GHC ever actually adds first-class existentials, what
is Cabal going to call *that* then?)
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sat, Jan 17, 2009 at 12:14 AM, Anton van Straaten
an...@appsolutions.com wrote:
I still think existential quantification is a step too far though. :-P
Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
on logic. In fact, I would argue that far more people probably know
what existential quantification is than that know what a monoid is.
:-)
Andrew's core objection here seems reasonable to me. It was this:
{-# LANGUAGE ExistentialQuantification #-} is an absurd name and
should be changed to something that, at a minimum, tells you it's
something to do with the type system.
But I suspect I part company from Andrew in thinking that something like
ExistentiallyQuantifiedTypes would be a perfectly fine alternative.
Well, I definitely agree to that, but that's not what he wrote in the
post I answered. My point was that existential quantification is
nowhere near scary.
But yes - making the Types part explicit is certainly not a bad idea.
+1 for ExistentiallyQuantifiedTypes.
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Fri, 2009-01-16 at 15:21 -0800, Jonathan Cast wrote:
On Fri, 2009-01-16 at 18:14 -0500, Anton van Straaten wrote:
Niklas Broberg wrote:
I still think existential quantification is a step too far though. :-P
Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
on logic. In fact, I would argue that far more people probably know
what existential quantification is than that know what a monoid is.
:-)
Andrew's core objection here seems reasonable to me. It was this:
{-# LANGUAGE ExistentialQuantification #-} is an absurd name and
should be changed to something that, at a minimum, tells you it's
something to do with the type system.
But I suspect I part company from Andrew in thinking that something like
ExistentiallyQuantifiedTypes would be a perfectly fine alternative.
+1
This focus on names is ridiculous. I agree that good names are
beneficial, but they don't have to encode everything about the referent
into themselves. Haskell is called Haskell not
StaticallyTypedPurelyFunctionalProgrammingLanguage. In this
particular case, it's absurd. In this case the name is only of mnemonic
value, other than that it could be called FraggleRock. Regardless of
the name you are going to have to look up what it refers to (in the
user's guide), or, having already done that earlier, just know what it
means.
(Although shouldn't it really be ExistentiallyQuantifiedConstructorTypes
or something? If GHC ever actually adds first-class existentials, what
is Cabal going to call *that* then?)
FreeExistentials. FirstClassExistentials would also be reasonable.
Though renaming the current LANGUAGE tag to
LocalExistentialQuantification would be better.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Andrew Coppin wrote: Cory Knapp wrote: As far as I know, one of the draws of Haskell is the inherent mathematical nature of it. It's also simultaneously one of the biggest things that puts people off. Perhaps as we can curb this with sufficient documentation, as others have suggested. Actually, that was part of my point: When I mention Haskell to people, and when I start describing it, they're generally frightened enough by the focus on pure code and lazy evaluation-- add to this the inherently abstract nature, and we can name typeclasses cuddlyKitten, and the language is still going to scare J. R. Programmer. By inherently mathematical nature, I didn't mean names like monoid and functor, I meant *concepts* like monoid and functor. Not that either of them are actually terribly difficult; the problem is that they are terribly abstract. That draws a lot of people (especially mathematicians), but most people who aren' drawn by that are hugely put off-- whatever the name is. So, I guess my point is that the name is irrelevant: the language is going to intimidate a lot of people who are intimidated by the vocabulary. At the same time, I think everyone is arguing *for* better documentation. And you're probably right: better documentation will bring the abstract nonsense down to earth somewhat. But there's a deeper problem here, one that can't be resolved inside the Haskell community. The problem is that the Math?! Scary! Gross! attitude that's so pervasive in our society is hardly less pervasive in the computer subculture. No arguments here! However, that at least *is* completely beyond our power to alter. Unfortunately. Indeed. Cheers, Cory ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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? -- Lennart On Thu, Jan 15, 2009 at 3:34 PM, John Goerzen jgoer...@complete.org wrote: Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like Appendable. But no, Haskell calls this pattern a Monoid. Yep, that's all a monoid is- something with an empty state and the ability to append things to the end. Well, it's a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them monads instead of warm, fluffy things. Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! He went on to add: If you?re not a category theorists, and you're learning (or thinking of learning) Haskell, don't get scared off by names like monoid or functor. And ignore anyone who starts their explanation with references to category theory- you don't need to know category theory, and I don't think it helps. I'd echo that one too. -- John ___ 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] Comments from OCaml Hacker Brian Hurt
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. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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? Picture someone that doesn't yet know Haskell. If I see Appendable I can guess what it might be. If I see monoid, I have no clue whatsoever, because I've never heard of a monoid before. Using existing terminology isn't helpful if the people using the language have never heard of it. 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. A lot of communities have the not invented here disease -- they don't like to touch things that other people have developed. We seem to have the not named here disease -- we don't want to give things a sensible name for a programming language that is actually useful. Here's another, less egregious, example: isInfixOf. I would have called that function contains or something. Plenty of other languages have functions that do the same thing, and I can't think of one that names it anything like isInfixOf. If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid I can immediately figure out what the first one means. With the second, I could refer to the GHC documentation, which does not describe what a Monoid does. Or read a wikipedia article about a branch of mathematics and try to figure out how it applies to Haskell. The GHC docs for something called Appendable could very easily state that it's a monoid. (And the docs for Monoid ought to spell out what it is in simple terms, not by linking to a 14-year-old paper.) I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Why do people think that you should be able to understand everything without ever looking things up? I'll get back to my example from the comment on the blog post. If I see 'ghee' in a cook book I'll check what it is (if I don't know). It has a precise meaning and next time I'll know. Inventing a new word for it serves no purpose, but to confuse people. Parts of Computer Science seem to love to invent new words for existing concepts. Again, I think this just confuses people in the long run. Or use existing words in a different way (like 'functor' in C++.) When it comes to 'isInfixOf', I think that is a particularely stupid name. As you point out, there are existing names for this function. I would probably have picked something like isSubstringOf instead of inventing something that is totally non-standard. I'm not saying Haskell always gets naming right, all I want is to reuse words that exist instead of inventing new ones. (And 'monoid' is not category theory, it's very basic (abstract) algebra.) I don't know any category theory, but if someone tells me that blah is an endomorphism I'm happy to call it that, knowing that I have a name that anyone can figure out with just a little effort. -- Lennart On Thu, Jan 15, 2009 at 4:15 PM, John Goerzen jgoer...@complete.org 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? Picture someone that doesn't yet know Haskell. If I see Appendable I can guess what it might be. If I see monoid, I have no clue whatsoever, because I've never heard of a monoid before. Using existing terminology isn't helpful if the people using the language have never heard of it. 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. A lot of communities have the not invented here disease -- they don't like to touch things that other people have developed. We seem to have the not named here disease -- we don't want to give things a sensible name for a programming language that is actually useful. Here's another, less egregious, example: isInfixOf. I would have called that function contains or something. Plenty of other languages have functions that do the same thing, and I can't think of one that names it anything like isInfixOf. If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid I can immediately figure out what the first one means. With the second, I could refer to the GHC documentation, which does not describe what a Monoid does. Or read a wikipedia article about a branch of mathematics and try to figure out how it applies to Haskell. The GHC docs for something called Appendable could very easily state that it's a monoid. (And the docs for Monoid ought to spell out what it is in simple terms, not by linking to a 14-year-old paper.) I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. -- John ___ 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] Comments from OCaml Hacker Brian Hurt
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 thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: a name that anyone can figure out with just a little effort. I think the problem is that all these pieces of little effort soon mount up. It's not just the cost of looking it up, but also of remembering it the next time and so on. It's fine when you only encounter the occasional unfamiliar term, but a barrage of them all at once can be quite disorienting. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. Personally, I don't mind it too much if the generic typeclasses are named using extremely accurate terms like Monoid, but saying that someone should then look up the abstract math concept and try to map this to something very concrete and simple such as a string seems like wasted effort. 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. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. My 2 cents, -Ross On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: 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 thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com 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 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] Comments from OCaml Hacker Brian Hurt
I won't deny that Haskell has a large number of unfamiliar term if you've only seen Java before. But I don't think that giving them all happy fuzzy names will help people in the long run. -- Lennart On Thu, Jan 15, 2009 at 4:40 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: a name that anyone can figure out with just a little effort. I think the problem is that all these pieces of little effort soon mount up. It's not just the cost of looking it up, but also of remembering it the next time and so on. It's fine when you only encounter the occasional unfamiliar term, but a barrage of them all at once can be quite disorienting. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ 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] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: Why do people think that you should be able to understand everything without ever looking things up? I don't. But looking things up has to be helpful. In all to many cases, looking things up means clicking the link to someone's old academic paper or some article about abstract math in Wikipedia. It does not answer the questions: * Why is this in Haskell? * Why would I want to use it? * How does it benefit me? * How do I use it in Haskell? If the docs for things like Monoids were more newbie-friendly, I wouldn't gripe about it as much. Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS: APPENDABLE MEANS MONOID in the haddock docs ;-) Much as I dislike Java's penchant for 200-character names for things, I'm not sure Monoid is more descriptive than SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy :-) -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
At the risk of painting my own bikeshed... If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid Would you call function composition (on endofunctions) appending? The join of a monad? A semi-colon (as in sequencing two imperative statements)? How do you append two numbers? Addition, multiplication, or something else entirely? All these operations are monoidal, i.e., are associative and have both left and right identities. If that's exactly what they have in common, why invent a new name? Appendable may carry some intuition, but it is not precise and sometimes quite misleading. I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. One of my grievances about Haskell is the occasional disregard for existing terminology. Stream Fusion is about lazy lists/co-lists, not streams; type families mean something entirely different to type theorists. This kind of misnomer is even more confusing than a name that doesn't mean anything (at least, until you learn more category theory). Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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. -- Lennart On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote: For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. Personally, I don't mind it too much if the generic typeclasses are named using extremely accurate terms like Monoid, but saying that someone should then look up the abstract math concept and try to map this to something very concrete and simple such as a string seems like wasted effort. 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. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. My 2 cents, -Ross On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: 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 thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com 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 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
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Of course not, the wikipedians would probably have your head for notability guidelines or something ;-) But seriously, I would have saved many hours of my life and probably many future ones if type class instances were documented and showed up in the haddock docs. -Ross On Jan 15, 2009, at 11:53 AM, Lennart Augustsson wrote: 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. -- Lennart On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren rmm- hask...@z.odi.ac wrote: For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. Personally, I don't mind it too much if the generic typeclasses are named using extremely accurate terms like Monoid, but saying that someone should then look up the abstract math concept and try to map this to something very concrete and simple such as a string seems like wasted effort. 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. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. My 2 cents, -Ross On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: 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 thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com 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 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
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 10:46 AM, Ross Mellgren rmm-hask...@z.odi.ac wrote: snip 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. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. I think you have a good point regarding documentation. Usually what I end up doing is just going into ghci testing out the instances with some trivial cases to make sure I have good intuition for how it's going to work. I don't think this a problem with the term 'monoid' though, but just a very generic problem with documentation. I have to do the same thing to understand an instance of Foldable despite how literal the name is. I don't know if it's very practical, but I like the idea of haddock generating either links to the source of the instance or some kind of expandable block that will show you the literal code. Cheers, Creighton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? The key is to introduce concepts to them in terms they can understand. You introduce it one way to experienced abstract mathematicians, and a completely different way to experienced Perl hackers. I wouldn't expect a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok abstract math. People have different backgrounds to draw upon, and we are under-serving one community. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. -- Lennart On Thu, Jan 15, 2009 at 4:51 PM, John Goerzen jgoer...@complete.org wrote: Lennart Augustsson wrote: Why do people think that you should be able to understand everything without ever looking things up? I don't. But looking things up has to be helpful. In all to many cases, looking things up means clicking the link to someone's old academic paper or some article about abstract math in Wikipedia. It does not answer the questions: * Why is this in Haskell? * Why would I want to use it? * How does it benefit me? * How do I use it in Haskell? If the docs for things like Monoids were more newbie-friendly, I wouldn't gripe about it as much. Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS: APPENDABLE MEANS MONOID in the haddock docs ;-) Much as I dislike Java's penchant for 200-character names for things, I'm not sure Monoid is more descriptive than SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy :-) -- John ___ 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] Comments from OCaml Hacker Brian Hurt
I'm totally with you on the instance documentation. I wish haddock allowed it. On Thu, Jan 15, 2009 at 4:56 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote: Of course not, the wikipedians would probably have your head for notability guidelines or something ;-) But seriously, I would have saved many hours of my life and probably many future ones if type class instances were documented and showed up in the haddock docs. -Ross ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 1:44 PM, Wouter Swierstra w...@cs.nott.ac.uk wrote: Would you call function composition (on endofunctions) appending? The join of a monad? A semi-colon (as in sequencing two imperative statements)? How do you append two numbers? Addition, multiplication, or something else entirely? All these operations are monoidal, i.e., are associative and have both left and right identities. If that's exactly what they have in common, why invent a new name? Appendable may carry some intuition, but it is not precise and sometimes quite misleading. I think this highlights an interesting point: Haskell is more abstract than most other languages. While in other languages Appendable might just mean what Brian suggested in his post, something with an empty state and the ability to append things to the end, in Haskell it applies to numbers and everything else that has an associative operator, that is, everything that is a monoid. So Appendable for numbers would be quite wrong; either it would never be used in situations where one wanted to append things to the end (which is limiting), or it would be used in these situations, which would be quite confusing. I think it is much more important to have good documentation about the typeclasses (and everything else in the library). This issue was mentioned recently in a discussion about monads, and the documentation for the Haskell library is quite uninformative. It would be nice if 1) people would not be scared of names like monoid and functor and 2) the documentation clearly stated what these things are, in a programming context, preferably with some examples. I think 2 would mitigate some of the fear mentioned in 1, if newcomers started to experience things like hey, that's one funky-named stuff this monoid thing, but I see here in the documentation that it is quite simple. -- []s, Andrei Formiga ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. Then why does it have a member named 'mappend'? :-) Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
jgoerzen: Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: I'd also recommend yesterday's post http://intoverflow.wordpress.com/2009/01/13/why-haskell-is-beyond-ready-for-prime-time/ Why Haskell is beyond ready for prime time For a few other insights. (Notably, the joy of hoogle/hayoo library search) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? No, just that we should seek to minimise the new stuff they have to get to grips with. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 7:34 AM, John Goerzen jgoer...@complete.org quoted: I'd be inclined to call it something like Appendable. But I don't know what Appendable means. Maybe it means class Appendable a where append :: a x - x - a x ie. a container x's lets you can add an x to the end or maybe it means class Appendable a where append :: a - x - a ie. something that you can append anything to or maybe it means class Appendable a where append :: a - a - a so you can append any two elements of the same type together. Why use words that are so vague when there's already word that unambiguously says what the type class looks like? And even worse, why use duplicate terminology to make it even harder to see when mathematicians and computer scientists are talking about the same thing, so widening the divide between two groups of people who have much to share. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Beats me. As I said, I don't think Haskell gets all the names right. :) On Thu, Jan 15, 2009 at 5:15 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. Then why does it have a member named 'mappend'? :-) Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ 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] Comments from OCaml Hacker Brian Hurt
2009/1/15 Lennart Augustsson lenn...@augustsson.net: Why do people think that you should be able to understand everything without ever looking things up? Understand, no, but have an intuition about, very definitely yes. In mathematics (and I speak as someone with a mathematical degree, so if I caricature anyone, please excuse it as failing memory rather than intent!!!) there's a tendency to invent terminology, rather than use natural names, because new names don't have unwanted connotations - it's the need for precision driving things. In programming, the need is for *communication* and as such, using words with natural - if imprecise, and occasionally even (slightly) wrong - connotations is extremely helpful. I'll get back to my example from the comment on the blog post. If I see 'ghee' in a cook book I'll check what it is (if I don't know). If a significant proportion of words require me to look them up, my flow of understanding is lost and I'll either give up, end up with a muddled impression, or take far longer to understand than the recipe merits (and so, I'll probably not use that cook book again). I'm not saying Haskell always gets naming right, all I want is to reuse words that exist instead of inventing new ones. But you seem to be insisting that mathematical terminology is the place to reuse from - whereas, in fact, computing might be a better basis (although computing doesn't insist on the precision that maths needs, so in any that's not precisely what I mean argument, non-mathematical terminology starts off an a disadvantage, even though absolute precision may not be the key requirement). (And 'monoid' is not category theory, it's very basic (abstract) algebra.) Well, I did a MSc course in mathematics, mostly pure maths including algebra, set theory and similar areas, and I never came across the term. Of course, my degree was 25 years ago, so maybe monoid is a term that wasn't invented then ;-)) I don't know any category theory, but if someone tells me that blah is an endomorphism I'm happy to call it that, knowing that I have a name that anyone can figure out with just a little effort. But unless you invest time researching, you can't draw any conclusions from that. If someone tells you it's a mapping, you can infer that it probably maps some things to one another, which gives you a (minimal, imprecise, and possibly wrong in some corner cases, but nevertheless useful) indication of what's going on. Mathematical precision isn't appropriate in all disciplines. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Sittampalam, Ganesh wrote: Lennart Augustsson wrote: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. Then why does it have a member named 'mappend'? :-) That's a mistake - and in fact, it's a good demonstration of why Monoid should not be named something like Appendable - because it misleads people into thinking that the structure is less general than it really is. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren rmm-hask...@z.odi.ac wrote: 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. The documentation for Monoid is embarrassingly brief. The monoid class. A minimal complete definition must supply mempty and mappend, and these should satisfy the monoid laws. It doesn't even list the monoid laws! Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. Not necessarily. Any instance of MonadPlus (or Alternative) has at least two reasonable Monoid instances: (mplus, mzero) and (liftM2 mappend, return mempty). [] uses the first and Maybe uses the second. I recommend not creating direct instances of Monoid for this reason. If you want to use Monoid with Int, you have to use Sum Int or Product Int. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
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. Then we get to learn more complex symbols like ! ? + - / and that takes some time to get used to, but eventually, that works too. But Functor, Monoid or Monad, that we cannot accept anymore. Why, because these are not intuitive? Are the symbols above intuitive? When I started learning Haskell I also found it insane that strange terminology was used everywhere... But every time I try to find a better name, the name is too specific for the situation at hand. Just like Appendable is a good name for specific instances of Monoid In F# they renamed Monads to Workflows for the same reason. I find this just as confusing since a Monad has nothing to do with work and maybe a little bit with a single threaded flow... I would have hoped that we could all stick to the same terminology that was invented a long time ago... Since Haskell is mainly for computer scientists, changing all of this to make it more accessible to newcomers might lead to the mistake: if you try to please the whole world, you please nobody. I mainly think the problem is not the name, but the lack of many tiny examples demonstrating typical use cases for each concept. On Thu, Jan 15, 2009 at 7:27 PM, Lennart Augustsson lenn...@augustsson.netwrote: That's very true. But programming is one where mathematical precision is needed, even if you want to call it something else. On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore p.f.mo...@gmail.com wrote: Mathematical precision isn't appropriate in all disciplines. ___ 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] Comments from OCaml Hacker Brian Hurt
John Goerzen wrote: Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS: APPENDABLE MEANS MONOID in the haddock docs ;-) This is backwards. The real problem here is that most people coming from other languages aren't used to working with structures as abstract as monoids, and a natural first instinct is to try to un-abstract them, in this case via the suggested renaming. The thought process tends to be something like I didn't have this problem in language X, Haskell must be doing something wrong. This instinct is not appropriate in the Haskell context. (Although as others have noted, the documentation doesn't do much to help guide people through this.) One of the most mind-bogglingly important features of Haskell is that it is actually possible to make effective use of structures such as monoids in real code. In most languages, you wouldn't even try this. But if you're going to create a zoo of abstract structures like monoids, with the aim of being able to use them as very general building blocks, the last thing you should be doing is naming them according to particular applications they have. This goes against the goal of abstracting in the first place, and will ultimately be confusing and misleading. (As I pointed out in another comment, the misleadingly-named 'mappend' is an example of this.) If there's an existing name for the exact structure in question, it makes sense to use that name. If you're unfamiliar with the structure, then you're going to need to learn a name for it anyway - why not learn a name by which it is already known in other contexts? The main counter to the latter question is I want to give it a new name in order to connote an intended use, but unless the connotation in question is as general as the structure being named, this is a mistake. This issue is not unique to structures from abstract algebra category theory. It can arise any time you have a very polymorphic function, for example. It can often make sense to provide a more specifically named and typed alias for a very general function, to make its use more natural and/or constrained in a particular context, e.g.: specificName :: SpecificType1 - SpecificType2 specificName = moreGeneralFunction Similarly, in the case of monoid, we need to be able to do this, at least conceptually: Appendable = Monoid ...possibly with some additional constraints. In other words, HEY PROGRAMMERS: YOU CAN USE MONOID AS AN APPENDABLE THINGY (AMONG OTHER THINGS). This is perhaps an argument for a class alias mechanism, such as the one described at: http://repetae.net/recent/out/classalias.html But in the absence of such a mechanism, we shouldn't succumb to the temptation to confuse abstractions with their applications. Much as I dislike Java's penchant for 200-character names for things, I'm not sure Monoid is more descriptive than SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy :-) Usable descriptive names for very abstract structures are just not possible in general, except by agreeing on names, which can ultimately come to seem descriptive. For example, there's nothing fundamentally descriptive about the word append. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
That's very true. But programming is one where mathematical precision is needed, even if you want to call it something else. On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore p.f.mo...@gmail.com wrote: Mathematical precision isn't appropriate in all disciplines. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Jan 15, 2009, at 1:21 PM, David Menendez wrote: On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren rmm- hask...@z.odi.ac wrote: Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. Not necessarily. Any instance of MonadPlus (or Alternative) has at least two reasonable Monoid instances: (mplus, mzero) and (liftM2 mappend, return mempty). [] uses the first and Maybe uses the second. Sorry my brain apparently misfired writing the original email. What I meant to say is that for the Monoid instance on [a] it's fairly easy (knowing what a Monoid is) to figure out how it's implemented, but that's not true for other classes or instances. That is to say, I agree with you, and intended to up front ;-) -Ross ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
John Goerzen wrote: Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! He went on to add: If you?re not a category theorists, and you're learning (or thinking of learning) Haskell, don't get scared off by names like monoid or functor. And ignore anyone who starts their explanation with references to category theory- you don't need to know category theory, and I don't think it helps. I'd echo that one too. I am constantly shocked and saddened at the Haskell community's attitude here. It seems to boil down to Why should we make it easier to learn Haskell? If people aren't prepaired to learn abstract algebra, category theory, predicate logic and type system theory, why should we bother to help them? So much for the famously helpful Haskell community. I am seriously beginning to wonder if the people using Haskell actually realise what regular programmers do and don't know about. (You may recall my recent straw poll where 80% of the programmer nerds I asked had no clue what a coroutine is or what existential quantification means.) Notice that monoid sounds almost *exactly* like monad. And yet, what you use them for is wildly unrelated. In a similar vein, who here can tell me off the top of their head what the difference between an epimorphism and a hylomorphism is? I've got a brick-thick group theory book sat right next to me and *I* can't even remember! Best of all, if Joe Programmer makes any attempt to look these terms up, the information they get will be almost completely useless for the purposes of writing code or reading somebody else's. 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...) The sad thing is, it's not actually complicated. The documentation just makes it seem like it is! :-( Databases are based on the relational algebra. But that doesn't seem to stop them from coming up with names for things that normal humans can understand without first taking a course in relational algebra. (Does the Oracle user guide state that a relation is simply a subset of the extended Cartesian product of the respective domains of its attributes? No, I don't *think* so! It says Oracle manages tables which are made up of rows... Technically less precise, but vastly easier to comprehend.) Why can't we do the same? If we *must* insist on using the most obscure possible name for everything, can we at least write some documentation that doesn't require a PhD to comprehend?? (Anybody who attempts to argue that monoid is not actually an obscure term has clearly lost contact with the real world.) As somebody else said, it basically comes down to this: Who the hell is Haskell actually for? If it's seriously intended to be used by programmers, things need to change. And if things aren't going to change, then let's all stop pretending that Haskell actually cares about real programmers. Sorry if this sounds like just another clueless rant, but I'm really getting frustrated about all this. Nobody seems to think there's actually a problem here, despite the incontravertible fact that there is... PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Surely saying that something is a monoid is so vague as to be unhelpful. The most you can say about almost everything is practically nothing and all that. All it means is that the type in question has a function that happens to take 2 arguments, and this function happens to have an identity value. How is this information useful? Surely what you'd want to know is what that function *does*?! And since a given type can only be a Monoid instance in one way, wouldn't passing the function and its identity in as parameters be simpler anyway? The integers form at least two different monoids AFAIK... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. One of my friend once said ... and by 'programmer' I mean 'category theory specialist'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 07:46:02PM +, Andrew Coppin wrote: John Goerzen wrote: If we *must* insist on using the most obscure possible name for everything, can we at least write some documentation that doesn't require a PhD to comprehend?? (Anybody who attempts to argue that monoid is not actually an obscure term has clearly lost contact with the real world.) 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 :-) As somebody else said, it basically comes down to this: Who the hell is Haskell actually for? If it's seriously intended to be used by programmers, things need to change. And if things aren't going to change, then let's all stop pretending that Haskell actually cares about real programmers. It might surprise you to see me say this, but I don't see this discussion as necessarily a weakness. I know of no other language community out there that has such a strong participation of both academics and applied users. This is a great strength. And, of course, Haskell's roots are firmly in academia. I think there there is a ton of interest in Haskell from the, ahem, real world programmer types. In fact, it seems to me that's where Haskell's recent growth has been. There are a lot of things showing up on Hackage relating to networking, Unicode encoding, databases, web apps, and the like. The nice thing about Haskell is that you get to put the theory in front of a lot of people that would like to use it to solve immediate programming problems. But they will only use it if you can explain it in terms they understand. There are a number of efforts in that direction: various websites, articles, books, libraries, etc. And I think the efforts are succeeding. But that doesn't mean there is no room for improvement. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin andrewcop...@btinternet.comwrote: The sad thing is, it's not actually complicated. The documentation just makes it seem like it is! :-( This is so true for a heck of a lot of things. Existential quantification being just one of them. Loads of things in Haskell have big powerful (but scary) names which I really think intimidate people, the situation isn't helped when a lot of tutorials use the theoretical basis for the construct as a starting point, rather then actually describing the construct from the perspective of a programmer first (see Monads). Haskell really isn't that difficult compared to other languages, but people still get the impression that you need to be a big brain on a stick to use it, terminology is certainly part of the equation. This doesn't mean that making up new words is always better, but we should certainly strive to exploit any opportunity to clarify the issue and (this means that haddock comments and language books/tutorials shouldn't refer to academic papers first and foremost, but use common English and practical examples to describe what's being used, and academic nerds can consult the footnotes for their fill of papers containing pages of squiggly symbols!). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote: PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Yes. They're used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. It is also used in the Foldable class which is a nice interface for traversing/visiting structures. Binary serialisation is also a monoid. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
duncan.coutts: On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote: PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Yes. They're used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. It is also used in the Foldable class which is a nice interface for traversing/visiting structures. Binary serialisation is also a monoid. Also, xmonad configuration hooks are monoidal. So all those xmonad users gluing together keybindings are using the Monoid class. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I think perhaps the correct question here is not how many instances of Monoid are there?, but how many functions are written that can use an arbitrary Monoid. E.g., the fact that there are a lot of instances of Monad doesn't make it useful. There are a lot of instances of Monad because it's useful to have instances of Monad. Why? Because of http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html ! Look at all the cool stuff you can automagically do with your type just because it's an instance of Monad! I think that's the point. What can you do with arbitrary Monoids? Not much, as evidenced by http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html On Thu, Jan 15, 2009 at 3:51 PM, Don Stewart d...@galois.com wrote: duncan.coutts: On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote: PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Yes. They're used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. It is also used in the Foldable class which is a nice interface for traversing/visiting structures. Binary serialisation is also a monoid. Also, xmonad configuration hooks are monoidal. So all those xmonad users gluing together keybindings are using the Monoid class. -- Don ___ 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] Comments from OCaml Hacker Brian Hurt
Graphic composition using painters algorithm can be seen as a monoid. data Graphic = Empty | Graphic `Over` Graphic | Ellipse Bounds | instance Monoid Graphic where mempty = Empty mappend = Over So all functions that operate on monoids can be used on Graphic as well, like mconcat that converts a [Graphic] into a Graphic On Thu, Jan 15, 2009 at 9:51 PM, Don Stewart d...@galois.com wrote: duncan.coutts: On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote: PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Yes. They're used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. It is also used in the Foldable class which is a nice interface for traversing/visiting structures. Binary serialisation is also a monoid. Also, xmonad configuration hooks are monoidal. So all those xmonad users gluing together keybindings are using the Monoid class. -- Don ___ 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] Comments from OCaml Hacker Brian Hurt
Sebastian Sylvan wrote:
On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin
andrewcop...@btinternet.com mailto:andrewcop...@btinternet.com wrote:
The sad thing is, it's not actually complicated. The documentation
just makes it seem like it is! :-(
This is so true for a heck of a lot of things. Existential
quantification being just one of them. Loads of things in Haskell have
big powerful (but scary) names which I really think intimidate people,
the situation isn't helped when a lot of tutorials use the theoretical
basis for the construct as a starting point, rather then actually
describing the construct from the perspective of a programmer first
(see Monads).
Haskell really isn't that difficult compared to other languages, but
people still get the impression that you need to be a big brain on a
stick to use it, terminology is certainly part of the equation.
This doesn't mean that making up new words is always better, but we
should certainly strive to exploit any opportunity to clarify the
issue and (this means that haddock comments and language
books/tutorials shouldn't refer to academic papers first and foremost,
but use common English and practical examples to describe what's being
used, and academic nerds can consult the footnotes for their fill of
papers containing pages of squiggly symbols!).
I basically agree with most of what you just said.
I'm not sure having a Monoid class is actually useful for anything - but
if we must have it, there seems to be little better possible name for
something so vague.
{-# LANGUAGE ExistentialQuantification #-} is an absurd name and should
be changed to something that, at a minimum, tells you it's something to
do with the type system. (Ideally it would also be pronouncible.) Of
course, nobody will take any notice, since changing this would induce
mass breakage for all the millions of LoC that already use the old name.
I think documenting a package by saying read this academic paper
should be banned. (Most especially if the paper in question isn't even
available online and can only be obtained from a reputable university
library!!) For example, I was looking at one of the monad transformers
(I don't even remember which one now), and the Haddoc contained some
type signatures and a line saying read this paper. The paper in
question mentioned the transformer in passing as a 5-line example of how
to use polymorphism, but *still* without explaining how to actually use
it! (I.e., the paper was about polymorphism, and this transformer was
just a quick example.) What the hell??
I presume I can call more documentation please! without upsetting even
the most ardant category theory millitant... ;-)
Unfortunately, it's not going to write itself, and I have no idea how to
solve the problem. (That is, even if I wrote some better documentation
myself, I don't know how to submit it to get it into the official
package documentation. E.g., Parsec has a great tutorial document, but
the Haddoc pages are barren. It'd be easy to fix, but I don't know how
to submit the updates.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 12:11 PM, John Goerzen jgoer...@complete.org wrote: On Thu, Jan 15, 2009 at 07:46:02PM +, Andrew Coppin wrote: John Goerzen wrote: can we at least write some documentation that doesn't require a PhD to comprehend? 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 -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Duncan Coutts wrote: On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote: PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Yes. They're used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. 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... It is also used in the Foldable class which is a nice interface for traversing/visiting structures. Binary serialisation is also a monoid. Foldable I'm vaguely familiar with. Its utility is more apparent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, 2009-01-15 at 09:34 -0600, John Goerzen wrote: Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like Appendable. But no, Haskell calls this pattern a Monoid. Yep, that's all a monoid is- something with an empty state and the ability to append things to the end. Well, it's a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them monads instead of warm, fluffy things. Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! No. Never. We will fight in the mailing lists. We will fight in the blog posts. We will never surrender. 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? Why should software engineering be the lone exception? No one may be a structural engineer, and remain ignorant of physics. No one may be a chemical engineer, and remain ignorant of chemistry. Why on earth should any one be permitted to be a software engineer, and remain ignorant of computing science? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 12:38 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote: PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Yes. They're used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. It is also used in the Foldable class which is a nice interface for traversing/visiting structures. Binary serialisation is also a monoid. The Writer Monad requires that you give it a Monoid for it to do its work properly. Duncan ___ 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] Comments from OCaml Hacker Brian Hurt
Notice that monoid sounds almost *exactly* like monad. And yet, what you use them for is wildly unrelated. Well, monads are monoids. I remember explaining you that... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Jonathan Cast 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? Why should software engineering be the lone exception? No one may be a structural engineer, and remain ignorant of physics. No one may be a chemical engineer, and remain ignorant of chemistry. Why on earth should any one be permitted to be a software engineer, and remain ignorant of computing science? Indeed. Because abstract alebra is highly relevant to computer programming. Oh, wait... Many people complain that too many database experts don't know the first thing about basic normalisation rules, SQL injection attacks, why you shouldn't use cursors, and so forth. But almost nobody complains that database experts don't know set theory or relational alebra. Why should proramming be any different? Don't get me wrong, there are mathematical concepts that are relevant to computing, and we should encourage people to learn about them. But you really *should not* need to do an undergraduate course in mathematical theory just to work out how to concat two lists. That's absurd. Some kind of balance needs to be found. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
