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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
"Lennart Augustsson" <[hidden email]> writes:
> By no means do I suggest that Wikipedia should replace Haskell library > documentation. > I think the libraries should be documented in a mostly stand-alone way > (i.e., no references to old papers etc.). In the case of Monoid, a > few lines of text is enough to convey the meaning of it and gives an > example. I don't think references to old papers are a bad thing (they might be good papers), but such references should certainly not be a replacement for a brief explanation and helpful example! _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Wouter Swierstra
On Thu, Jan 15, 2009 at 1:44 PM, Wouter Swierstra <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
On Thu, Jan 15, 2009 at 7:34 AM, John Goerzen <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Sittampalam, Ganesh
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 <[hidden email]> 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 > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
2009/1/15 Lennart Augustsson <[hidden email]>:
> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Sittampalam, Ganesh
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Ross Mellgren
On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren <[hidden email]> 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 <[hidden email]> <http://www.eyrie.org/~zednenem/> _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Paul Moore-2
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 <[hidden email]> wrote: > > Mathematical precision isn't appropriate in all disciplines. > _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by David Menendez-2
On Jan 15, 2009, at 1:21 PM, David Menendez wrote:
> On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren <rmm- > [hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
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 <[hidden email]> wrote: That's very true. But programming is one where mathematical precision _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
>>>>> "John" == John Goerzen <[hidden email]> writes:
John> I guess the bottom line question is: who is Haskell for? Category John> theorists, programmers, or both? I'd love it to be for both, but John> I've got to admit that Brian has a point that it is trending to John> the first in some areas. Thank you for so nicely put it together... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe attachment0 (202 bytes) Download Attachment |
In reply to this post by John Goerzen-3
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Ross Mellgren
> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
On Thu, Jan 15, 2009 at 07:46:02PM +0000, 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin <[hidden email]> wrote:
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
On Thu, 2009-01-15 at 19:46 +0000, 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |