On Thu, Jan 15, 2009 at 1:29 PM, Andrew Coppin
<[hidden email]> wrote: > 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. Balance is good, but it's hard to find a balance when people exaggerate so much. Firstly: You don't need monoids to concat two lists. You need monoids when you want to abstract the operation of concatting two lists so that the same code can be reused in other ways. A good example is the writer monad. The author of that monad could have made it work just with strings. But one of the coollest things about Haskell is the way it's so amenable to micro-refactoring. By realising there's a bunch of other things the Writer monad can do using *exactly the same implementation* you get reusability. If you don't want this kind of reusability you may be better off with C or Fortran. Secondly: you don't need an "undergraduate course." to understand monoids. A monoid is just a collection of things with an operation allowing you to combine two things to get another one. And an element that acts like 'nothing' so that when you combine it with other elements it leaves them unchanged (and an additional simple condition). This would be the first 30 seconds of a course on monoids that presupposes nothing more than a naive idea of what a set is. The only thing that's difficult about monoids is that it's a new word. There's little 'theory' involved. Your talk of undergraduate courses to concat two lists isn't grounded in any kind of reality, muddies the waters, and probably scares people away from Haskell by giving the impression that it's much harder than it is. -- Dan _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
On Thu, 15 Jan 2009 13:21:57 -0800, you wrote:
>Where, in the history of western civilization, has there ever been an >engineering discipline whose adherents were permitted to remain ignorant >of the basic mathematical terminology and methodology that their >enterprise is founded on? Umm, all of them? >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? Do you know any actual working structural or chemical engineers? Most engineering disciplines require a basic grasp of the underlying theory, yes, but not much beyond that. Pretty much everything else is covered by rules (either rules of thumb or published standards). Show me an electrical engineer who can explain the physics of a pn junction and how it acts as a rectifier, or a civil engineer who can explain why the stress/strain curve of a steel beam has the shape that it does, or a chemical engineer who can explain molecular orbital theory. Those kinds of engineers do exist, of course, but they are few and far between. If you aim your product only at the kinds of engineers who _can_ do those things, you will be reaching a tiny, tiny fraction of the overall population. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by MigMit
Maybe you can explain that again?
I see how the subset of Kleisli arrows (a -> m a) forms a monoid (a, return . id, >>=), but what to do with (a -> m b)? (>>=) is not closed under this larger set. Dan Miguel Mitrofanov wrote: >> 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 > [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 Bugzilla from jonathanccast@fastmail.fm
On Thu, Jan 15, 2009 at 01:50:11PM -0800, Jonathan Cast wrote:
> On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote: > > 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. > > False. We are failing to meet the un-realistic expectations of advanced > Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as > to the ease with which they should be able to learn Haskell. What part of that are you saying is false? That people have different backgrouns and learn differently? > > jcc > > > _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Thomas DuBuisson
On Thu, 2009-01-15 at 21:59 +0000, Thomas DuBuisson wrote:
> > How does forcing them to learn proposed terminology such as `Appendable' > > help here? Learners of Haskell do still need to learn what the new word > > means. > > The contention is that 'Appendable' is an intuitive naming that people > will already have a rudimentary grasp of. This as opposed to Monoid, > which absolutely requires looking up for the average coder. It reminds me a bit of my school French classes. Our teacher often brought up the subject of "false friends", that is words in the foreign language that sound superficially familiar to one in the native language but are in fact different in subtle but important ways. In this case Appendable has the wrong connotations for what the Monoid class does. Appendable does not sound symmetric to me and it places too much emphasis on monoids that resemble lists. Perhaps there is a more common word that reflects the meaning without being misleading. But if we cannot find one, then picking a name that is unfamiliar to most people may well be better than picking a name that is misleading or is too narrow. Duncan _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Dan Weston
On 16 Jan 2009, at 01:10, Dan Weston wrote: > Maybe you can explain that again? Sure. Consider the following setting: a category C and a bifunctor T : C x C -> C, which is associative and have a (left and right) unit I. This is what is called "monoidal category". A "monoid" is an object X in C with two morphisms: I -> X and T(X, X) - > X, satisfying two relatively simple conditions (I don't want to draw commutative diagrams). If your category is a category of sets, and T is a cartesian product, then you have ordinary monoids (I is a one-element set, first morphism is a unit of a monoid, and second morphism is monoid multiplication). If, however, you category is a category of endofunctors of some category D (that is, functors D -> D), and T is composition, then our "monoids" become monads on D: I is an identity functor, first morphism is "return", and second one is "join". > > > I see how the subset of Kleisli arrows (a -> m a) forms a monoid (a, > return . id, >>=), but what to do with (a -> m b)? (>>=) is not > closed under this larger set. > > Dan > > Miguel Mitrofanov wrote: >>> 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 >> [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 Andrew Coppin
On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote:
> 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 know I'm repeating myself from elsewhere in this thread but this is the better question for the answer :-) ] By making a type an instance of Monoid instead of exporting emptyFoo, joinFoo functions it makes the API clearer because it shows that we are re-using an existing familiar concept rather than inventing a new one. It also means the user already knows that joinFoo must be associative and have unit emptyFoo without having to read the documentation. Perhaps it's what OO programmers would call a design pattern. Identify a pattern, give it a name and then when the pattern crops up again (and again) then the reader of the code will have an easier time because they are already familiar with that named pattern. Of course the fact that we can occasionally use the pattern to parametrise and write more re-usable code is a bonus. Duncan _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Duncan Coutts wrote:
> By making a type an instance of Monoid instead of exporting > emptyFoo, joinFoo functions it makes the API clearer because it shows > that we are re-using an existing familiar concept rather than inventing > a new one. It also means the user already knows that joinFoo must be > associative and have unit emptyFoo without having to read the > documentation. > 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_. Knowing that it's a monoid doesn't really tell me anything useful. A monoid can be almost anything. As an aside, the integers form two different monoids. Haskell can't [easily] handle that. Does anybody know of a language that can? _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
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. IMO the Monoid class is useful since, if you define mempty and mappend, you get mconcat for free. I don't see what the problem is. Most people will accept Functor, as it used a lot. Monoid might be less used, but if you reject it, then by principle you must just as well reject Functor, and any other type classes.
_______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by MigMit
On Thu, Jan 15, 2009 at 2:24 PM, Miguel Mitrofanov
<[hidden email]> wrote: > If, however, you category is a category of endofunctors of some category D > (that is, functors D -> D), and T is composition, then our "monoids" become > monads on D: I is an identity functor, first morphism is "return", and > second one is "join". You can see this more concretely in Haskell code here: http://sigfpe.blogspot.com/2008/11/from-monoids-to-monads.html (This probably ought to be in a separate thread.) -- Dan _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Duncan Coutts
On Thu, Jan 15, 2009 at 5:27 PM, Duncan Coutts
<[hidden email]> wrote: > On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote: > >> 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 know I'm repeating myself from elsewhere in this thread but this is > the better question for the answer :-) ] > > By making a type an instance of Monoid instead of exporting > emptyFoo, joinFoo functions it makes the API clearer because it shows > that we are re-using an existing familiar concept rather than inventing > a new one. It also means the user already knows that joinFoo must be > associative and have unit emptyFoo without having to read the > documentation. I assume these are all documented where the type is defined? One disadvantage of Monoid compared to Monad is that you really need to explain what operation your Monoid instance performs. For example, the documentation for Maybe describes what its Monad instance does, but not its Monoid instance. I don't think any of the instances for [] are documented. (Admittedly, this is difficult, since [] is not actually exported from anywhere.) -- 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 Duncan Coutts
On 15/01/2009, at 23:27, Duncan Coutts wrote: > On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote: > >> 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 know I'm repeating myself from elsewhere in this thread but this > is > the better question for the answer :-) ] > > By making a type an instance of Monoid instead of exporting > emptyFoo, joinFoo functions it makes the API clearer because it shows > that we are re-using an existing familiar concept rather than > inventing > a new one. It also means the user already knows that joinFoo must be > associative and have unit emptyFoo without having to read the > documentation. > > Perhaps it's what OO programmers would call a design pattern. > Identify a > pattern, give it a name and then when the pattern crops up again (and > again) then the reader of the code will have an easier time because > they > are already familiar with that named pattern. Exactly, documenting knowledge was one of the benefits of design patterns. Monoid looks like the Composite pattern, one of the original GoF patterns. Is Composite is a better name for Monoid? I guess that when the GoF folks were writing the book they had to come up with quite a few names, and some came out better than others. If anything, the Haskell approach is more consistent. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
> off the top of their head what the difference between an epimorphism and a
> hylomorphism is? They're not even from the same branch of mathematics. Epimorphisms are defined in category theory, as arrows which can be cancelled when they appear on the right of a composite, that is, if f is an epimorphism, and g . f = h . f, then g = h. Such arrows are somewhat comparable to surjective functions. Hylomorphisms are from recursion theory. They are the composite of an anamorphism (which builds up a recursive structure from an initial seed) with a catamorphism, (which replaces the constructors in that recursive structure with other functions). Terminology has value, in that it allows you to see things in a new way which is clearer than what could otherwise be achieved. Any programmer worth their salt should be comfortable absorbing a new term, the same way they learn a new library function. We should remember that Haskell's beauty is not an accident. It is proportional to the amount of effort which went into building the solid mathematical foundations describing its semantics, and designing a language which reflected those semantics as clearly as possible. Discarding those foundations in an attempt to get more users is a price I would personally never want to see us pay. - Cale _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Sittampalam, Ganesh
2009/1/15 Sittampalam, Ganesh <[hidden email]>:
> 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 Good question. The names of the methods of the Monoid class are inappropriate. My personal preference would be: class Monoid m where zero :: m (++) :: m -> m -> m (in the Prelude of course) - Cale _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Justin Bogner
On Thu, Jan 15, 2009 at 9:04 AM, <[hidden email]> wrote:
_______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
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. On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote: > 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 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
> 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. However, "Appendable" carries baggage with it which is highly misleading. Consider, for instance, the monoid of rational numbers under multiplication (which, by the way, is quite useful with the writer transformed list monad for dealing with probabilities) -- you can claim that multiplication here is a sort of "appending", perhaps, but it's not really appropriate. Modular addition, or multiplication in some group is even farther from it. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by David Fox-7
Yes! The library documentation tree has a way of making everything
seem equally important, when that is not the case. This is why we need well-crafted tutorials and books. 2009/1/15 David Fox <[hidden email]>: > Monoid isn't something I came across and didn't understand, its something I > should have been using for a long time before I discovered it. But it never > jumped out at me when I was browsing the library documentation tree. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
On Thu, 2009-01-15 at 16:16 -0600, John Goerzen wrote:
> On Thu, Jan 15, 2009 at 01:50:11PM -0800, Jonathan Cast wrote: > > On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote: > > > 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. > > > > False. We are failing to meet the un-realistic expectations of advanced > > Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as > > to the ease with which they should be able to learn Haskell. > > What part of that are you saying is false? That people have different > backgrouns and learn differently? Not just differently. Some people learn faster than others. These relative speeds also vary across different subjects. I think the implicit assumption in most complaints about learning Haskell is that the ease with which any given developer learns Haskell (or learns a new Haskell library or concept) should be comparable to the ease with which said developers learns conventional languages, e.g. Perl. This assumption is false. In fact, if someone finds Perl particularly easy to learn (relative to other subjects), I would expect that person to find Haskell particularly hard to learn (relative to other subjects). Of course mathematicians find Haskell easier to learn than Perl programmers do; this is a consequence of the nature of Haskell, the nature of Perl, and the nature of mathematics. We are under no obligation to obtain equivalent outcomes from non-interchangeable people. That people who lack natural aptitude, or relevant prior knowledge, for learning Haskell have more difficulty than those with relevant natural aptitude or prior knowledge is in no way a failure of the Haskell community. jcc _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Derek Elkins
While you're absolutely correct and I agree with you, to be fair,
essentially all mathematicians have a sense of "rigourisability" (whether they recognise it or not), which is a peculiar standard that they apply to everything they hear or read. The level of rigour at which mathematicians communicate is designed not to bore the listener with details that they could easily supply for themselves, being an intelligent mathematician, and not a mechanical abstraction. - Cale 2009/1/15 Derek Elkins <[hidden email]>: > 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. > > On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote: >> 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 > > _______________________________________________ > 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 |
Free forum by Nabble | Edit this page |