Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Jonathan Cast]

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

[Henning Thielemann]

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

[Henning Thielemann]

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

[Tristan Seligmann]

* Andrew Coppin  [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

[Tristan Seligmann]

* John Goerzen  [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

[George Pollard]

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

[Don Stewart]

david.waern:
> 2009/1/18 Don Stewart :
> > 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

[David Waern]

2009/1/18 Don Stewart :
> 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

[Don Stewart]

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

[Ross Paterson]

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

[Robin Green]

On Sun, 18 Jan 2009 08:51:10 +0100
david48  wrote:

> On Sat, Jan 17, 2009 at 11:19 PM, Dan Piponi 
> wrote:
> > On Sat, Jan 17, 2009 at 1:47 AM, david48
> >  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

[david48]

On Sat, Jan 17, 2009 at 11:19 PM, Dan Piponi  wrote:
> On Sat, Jan 17, 2009 at 1:47 AM, david48  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

[Jonathan Cast]

On Sat, 2009-01-17 at 10:47 +0100, david48 wrote:
> On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast
>  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 () i+= 
> >
> > 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

[Jonathan Cast]

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

[ajb]

G'day all.

Quoting John Goerzen :


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

[Dan Piponi]

On Sat, Jan 17, 2009 at 1:47 AM, david48  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

[David Leimbach]

On Sat, Jan 17, 2009 at 7:33 AM, Lennart Augustsson
wrote:

> 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
>  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

[Lennart Augustsson]

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
 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

[Eugene Kirpichov]

2009/1/17 Andrew Coppin :
> 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

[Andrew Coppin]

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

[Andrew Coppin]

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.)


Either way, nobody is going to change the name, so why worry?



PS. There exist courses on logic? That could be potentially interesting...

___
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

[david48]

On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast
 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 () i+= 
>
> 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]

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

[Derek Elkins]

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

[Niklas Broberg]

On Sat, Jan 17, 2009 at 12:14 AM, Anton van Straaten
 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

[Jonathan Cast]

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

[Anton van Straaten]

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

[Niklas Broberg]

> 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

[Andrew Coppin]

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

[Andrew Coppin]

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]

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

[Anton van Straaten]

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

[Conal Elliott]

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 

>
> 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

[Ketil Malde]

Steve Schafer  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

[Andrew Coppin]

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

[Anton van Straaten]

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

[Ian Lynagh]

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

[David Menendez]

On Fri, Jan 16, 2009 at 12:19 PM, Ross Paterson  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 

___
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 Paterson]

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

[Steve Schafer]

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

[David Menendez]

On Fri, Jan 16, 2009 at 8:39 AM, Duncan Coutts
 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 

___
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

[Jeremy Shaw]

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

[Jonathan Cast]

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 () i+= 

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

[Philippa Cowderoy]

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

[Philippa Cowderoy]

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

[Philippa Cowderoy]

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

[Duncan Coutts]

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

[Dougal Stanton]

On Fri, Jan 16, 2009 at 1:23 PM, Philippa Cowderoy  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

[Philippa Cowderoy]

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

[Philippa Cowderoy]

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

[Duncan Coutts]

On Thu, 2009-01-15 at 18:41 -0500, Cale Gibbard wrote:
> 2009/1/15 Andrew Coppin :
> > 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

[david48]

On Fri, Jan 16, 2009 at 5:39 AM, Creighton Hogg  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

[Manuel M T Chakravarty]

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
 wrote:

On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
 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

[Immanuel Litzroth]

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  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

[Paul Moore]

2009/1/15 Derek Elkins :
> On Thu, 2009-01-15 at 18:27 +, Lennart Augustsson wrote:
>> On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore  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

[Ketil Malde]

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

[Thomas Davie]

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

[Creighton Hogg]

On Thu, Jan 15, 2009 at 10:18 PM, Jonathan Cast
 wrote:
> On Thu, 2009-01-15 at 17:06 -0500, Steve Schafer wrote:
>> On Thu, 15 Jan 2009 13:21:57 -0800, you wrote:
>>
>> >Where, in the history of western civilization, has there ever been an
>> >engineering discipline whose adherents were permitted to remain ignorant
>> >of the basic mathematical terminology and methodology that their
>> >enterprise is founded on?
>>
>> Umm, all of them?
>
> Really.  So the engineer who designed the apartment building I'm in at
> the moment didn't know any physics, thought `tensor' was a scary math
> term irrelevant to practical, real-world engineering, and will only read
> books on engineering that replace the other scary technical term
> `vector' with point-direction-value-thingy?  I think I'm going to sleep

It feels like this conversation is going in circles.  What I'm taking
away from the two very different arguments being made is that

1) math terms have their place when they describe the concept very
precisely, e.g. monoid
2) the Haskell docs _don't_ do good enough a job at giving intuition
for what math terms mean

If we fix #2, then #1 is no longer a problem, yes?

For you folks who work on GHC, is it acceptable to open tickets for
poor documentation of modules in base?  I think leaving the
documentation to the tragedy of the commons isn't the best move, but
if even a few of us could remember to open tickets when new
Haskell'ers complain about something being confusing then it could be
on _someone's_ docket.

Cheers,
Creighton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Jonathan Cast]

On Thu, 2009-01-15 at 17:06 -0500, Steve Schafer wrote:
> On Thu, 15 Jan 2009 13:21:57 -0800, you wrote:
> 
> >Where, in the history of western civilization, has there ever been an
> >engineering discipline whose adherents were permitted to remain ignorant
> >of the basic mathematical terminology and methodology that their
> >enterprise is founded on?
> 
> Umm, all of them?

Really.  So the engineer who designed the apartment building I'm in at
the moment didn't know any physics, thought `tensor' was a scary math
term irrelevant to practical, real-world engineering, and will only read
books on engineering that replace the other scary technical term
`vector' with point-direction-value-thingy?  I think I'm going to sleep
under the stars tonight...

> >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?

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 :)

> Most
> engineering disciplines require a basic grasp of the underlying theory,
> yes, but not much beyond that.

Perhaps I should have said `completely ignorant'?  Or do you think that

  join . join = join . fmap join

is of the same level of theoretical depth as quantum orbital mechanics?

> 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,

Again, do engineers know *what* stress is?  Do they understand terms
like `tensor'?  Those things are the rough equivalents of terms like
`monoid'.

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

[Cory Knapp]

Perhaps as a math/CS major I'm a bit biased here, but as a haskell 
neophyte, I think my opinion is at least somewhat relevant...


The immediate problem is certainly documentation. No one would groan 
more than once after hearing a term from abstract math if there was 
sufficient Haskell-oriented language. I can say that a monad is an 
endo-functor (in this case on Hask) which is the composition of two 
natural transformations; the clever parrot I am, I can even understand 
most of this... but that doesn't mean anything to me in a Haskell 
context; until a new Haskell programmer can find a Hasktionary with 
relevant terms in a Haskell context, everything is meaningless-- even 
though I can understand (i.e. apply meaning to) the definition of a 
monad on Hask, I can't apply the sort of meaning required to program 
with a monad without either figuring it out through experience, or 
seeing it shown to me in a programmer-relevant way (Or rather, both need 
to happen.)


On the other hand, I really, really like getting behind things and 
understanding the theory. In C, well, C is the theory-- if I want to go 
deeper, I need to learn as much as I can about the way a computer 
actually, physically works (why, why, then, even have higher level 
languages?) or I need to take a history lesson so I can figure out the 
math that helped out... With Haskell, the theory is right there, staring 
at me. If the documentation were better, I wouldn't *need* to learn it, 
but if my curiosity is piqued, it's right there. Naming monoid 
"appendable" kills that-- by trying to make things "warm and fuzzy", 
you've weakened one of my strongest motivators for programming 
(especially in Haskell), namely how much of a direct application of cool 
math it is. I know I'm not the only one.


As far as I know, one of the draws of Haskell is the inherent 
mathematical nature of it-- in how many other languages do people write 
proofs of correctness because they don't want to write test-cases? The 
kind of people who are going to be drawn to a language which allows 
[(x,y)| x<-somelist, y<-someotherlist] are overall, a mathy set of 
people, and trying to make our terms fuzzy isn't going to change that. 
So why not embrace it?


This leads to another point: monoids are probably called monoids for the 
same reason monads are monads: they came directly out of higher math. 
Someone did sit down trying to name this cool new Haskell idea he had 
and then say, "Oh, of course, it's just [insert "obscure" math word 
that's used in Haskell]! I'll keep that name." He sat down, and said, 
"Oh! Wait if I use [insert "obscure" math word that's used in Haskell] 
this problem is simpler." It's named for what it is: a monoid, a monad, 
a functor, existential quantification.


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. I shouldn't be more able to discuss abstract 
math with a conservatory dropout theater student than with someone who 
plans, for a living, to put well-formed formulae onto a finite state 
machine. I am.


I don't expect the average programmer to be able to give me a 
well-ordering of the reals (with choice, of course), or to prove that 
category C satisfying property P must also satisfy property Q; but for 
God's sake, they better have a good intuition for basic set theory, 
basic graph theory, and most importantly mathematical abstraction. What 
is "good coding style" if not making the exact same types of 
abstractions that mathematicians make? Again, I don't expect a CS major 
to write a good proof, to explain rings to a 13 year old, or actually 
"do" real math; but I expect one to be able to read "In abstract 
algebra, a branch of mathematics, a monoid is an algebraic structure 
with a single, associative binary operation and an identity element. " 
and be able to get a basic intuitive idea for what a monad is; with some 
thought of course. I would go so far as to say that a programmer should 
be able to intuitively understand "a system of objects and associative 
arrows", even if they can't "do math" with that... Programmers shouldn't 
be allowed to get away with the absolute ignorance of math that at least 
75% of the CS majors at my school pass with.


This doesn't mean there isn't a serious problem with Haskell 
documentation; it also doesn't mean that everyone should have a minor in 
math to be a programmer, but isn't an introductory course in discrete 
math required for most CS programs? Then why are programmers so afraid 
of basic mathematical definitions? And why do so many wear their 
ignorance and fear of math as a badge of honor?


Sorry that this came out as a bit of a rant, but I spend enough time 
trying to convince people that math isn't horrid and disgusting...


Cory Knapp
___
Haskell-Ca

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[John A. De Goes]

+1 to that

Regards,

John

On Jan 15, 2009, at 4:10 PM, Cale Gibbard wrote:


2009/1/15 Sittampalam, Ganesh :

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
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

[Bertram Felgenhauer]

Andrew Wagner wrote:
> 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

One example where Monoids (in full generality) are useful is that of
measurements in the Data.Sequence paper (which is sadly not implemented
in the library, although it is used to maintain the length for efficient
indexing),

   http://www.soi.city.ac.uk/~ross/papers/FingerTree.html

The concept applies to any tree that represents an ordered list.

The basic idea is that given a measurement for single elements,

class Monoid v => Measured a v where
 measure :: a -> v

we can annotate a tree with cached measurements of the corresponding
sequences,

data Tree a v = Empty | Leaf v a | Node v (Tree a v) (Tree a v)

measureTree :: Measured a v => Tree a v -> v
measureTree Empty = mzero
measureTree (Leaf v _) = v
measureTree (Node v _ _) = v

which can be calculated easily by smart constructors:

leaf :: Measured a v => a -> Tree a v
leaf a = Leaf (measure a) a

node :: Measured a v => Tree a v -> Tree a v -> Tree a v
node l r = Node (measureTree l `mappend` measureTree r) l r

Because v is a monoid, the construction satisfies the law

measureTree = mconcat . map measure . toList

where
toList Empty = []
toList (Leaf _ a) = [a]
toList (Node _ l r) = toList l ++ toList r

All usually efficient tree operations, insertion, deletion, splitting,
concatenation, and so on, will continue to work, if the cached values
are ignored on pattern matching and the smart constructors are used
for constructing the new trees. measure or `mappend` will be called
for each smart constructor use - if they take constant time, the
complexity of the tree operations doesn't change.

Applications include:
  - finding and maintaining the sum of any substring of the sequence.
  - maintaining minimum and maximum of the list elements
  - maintaining the maximal sum of any substring of the sequence
(this can be done by measuring four values for each subtree:
1. the sum of all elements of the sequence
2. the maximum sum of any prefix of the sequence
3. the maximum sum of any suffix of the sequence
4. the maximum sum of any substring of the sequence)

I also found the idea useful for
http://projecteuler.net/index.php?section=problems&id=220

starting out with
-- L system basis
class Monoid a => Step a where
l :: a
r :: a
f :: a

and then providing a few instances for Step, one of which was a binary
tree with two measurements.

Bertram
___
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

[Dan Weston]

Richard Feinman once said: "if someone says he understands quantum 
mechanics, he doesn't understand quantum mechanics".


But what did he know...

Luke Palmer wrote:
On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo > wrote:


 >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.

I've been studying Haskell a bit to understand and learn more about
functional programming (I'm using F#). I have to say, the scariest
thing I've faced was exactly what you say. Everything I read built
"monads" up to be this ungraspable thing like quantum mechanics.


Yeah, monad is on the same level as quantum mechanics.  Both are equally 
simple and popularly construed as ungraspable.


(However to grasp monads easily you need a background in FP; to grasp QM 
easily you need a background in linear algebra)


Luke




___
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

[Luke Palmer]

On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo wrote:

> >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.
>
> I've been studying Haskell a bit to understand and learn more about
> functional programming (I'm using F#). I have to say, the scariest thing
> I've faced was exactly what you say. Everything I read built "monads" up to
> be this ungraspable thing like quantum mechanics.


Yeah, monad is on the same level as quantum mechanics.  Both are equally
simple and popularly construed as ungraspable.

(However to grasp monads easily you need a background in FP; to grasp QM
easily you need a background in linear algebra)

Luke
___
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

[Michael Giagnocavo]

>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.

I've been studying Haskell a bit to understand and learn more about functional 
programming (I'm using F#). I have to say, the scariest thing I've faced was 
exactly what you say. Everything I read built "monads" up to be this 
ungraspable thing like quantum mechanics. Even after I actually understood it 
well enough, I kept thinking I must be missing something because there's so 
much fuss about it.

-Michael
___
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

[Luke Palmer]

On Thu, Jan 15, 2009 at 9:15 AM, John Goerzen  wrote:

> If you're learning Haskell, which communicates the idea more clearly:
>
>  * Appendable
>
> or
>
>  * Monoid


But Appendable is wrong.

merge :: Ord a => [a] -> [a] -> [a]
merge [] ys = ys
merge xs [] = xs
merge (x:xs) (y:ys) | x <= y = x : merge xs (y:ys)
  | otherwise = y : merge (x:xs) ys

newtype MergeList a = MergeList [a]

instance (Ord a) => Monoid (MergeList a) where
mempty = MergeList []
mappend (MergeList xs) (MergeList ys) = MergeList (merge xs ys)

This is a perfectly good monoid -- one I have used -- but in no sense would
I call MergeList "appendable".

Also, in what sense is mappend on Endo appending?

I just realized that the name "mappend" sucks :-).  (++) would be great!

In any case, to me being a Monoid is about having an associative operator,
not about "appending".  The only fitting terms I can think of are equally
scary ones such as "semigroup".

Which is worse: naming things with scary category names, as in "monad" and
"monoid", or naming things with approachable popular names that are wrong
(wrt. to their popular usage), as in "class" and "instance".

In the former case, the opinion becomes "Haskell is hard -- what the hell is
a monad?"; in the latter it becomes "Haskell sucks -- it's class system is
totally stupid" because we are *violating* people's intuitions, rather than
providing them with none whatsoever.

In a lot of cases there is a nice middle ground.  Cases where (1) we can
find an intuitive word that does not have a popular CS meaning, or (2) where
the popular CS meaning is actually correct ("integer"?).  But eg.
programming with monads *changes the way you think*; we cannot rewire
people's brains just-in-time with a word.

I like the word Monad.  It makes people know they have to work hard to
understand them.  **

Luke
___
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]

Derek Elkins wrote:

> No one doubts that there is room for improvement.  However, the
> direction is better documentation, not different names.  Better names is
> fine, but I have not heard any remotely convincing alternative for any
> of the above terms.

After thinking about it, I think you are right.  But, there is a problem
-- nobody is stepping up to write that documentation.  If we can't get
it, then perhaps we ought to fall back on better names.

If we *can* get it, all the better, because these things need good docs,
regardless of what they're called.

I can see it now: a monoid by any other name would smell as sweet...

-- 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

[Derek Elkins]

On Thu, 2009-01-15 at 18:21 -0500, Cale Gibbard wrote:
> 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.

Indeed.  One way to describe "rigorizable" is that it is (ideally) just
enough precision to be unambiguous.  Programmers don't have that luxury
and thus clarity and hence communication suffer, which was exactly my
point.

___
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

[Derek Elkins]

On Thu, 2009-01-15 at 21:59 +, 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.

In programming, -every- name requires looking up or some other way of
checking meaning.  Other than perhaps arithmetic operators (and I have
had that bite me), I have -never- in any language written code using a
name without having some assurance that it actually meant what I thought
it meant.  Usually you have to "look something up" to even know a name
exists no matter how "intuitive" it turns out to be.

___
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

[Derek Elkins]

On Thu, 2009-01-15 at 14:11 -0600, John Goerzen wrote:
> 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 plenty of "real world" programmer types who are using these
scarily named things, Monoid, Monad, Functor, Existential
Quantification.  Programmers such as you*.  Despite poor documentation,
which everyone agrees could be improved, they've somehow managed to
understand these things anyway.  My impression is that to most of them
Monoids, Functors, and Monads are Just Another Interface and Existential
Quantification is Just Another Language Feature.  There are poorly
documented interfaces in every language**.  Any "real world" programmer
has some (plenty...) of experience dealing with this issue.  These
programmers do what they need to do to get stuff done.  Again, somehow
they learn how to use these things without waiting for "us" to provide
an "explanation" in "terms they can understand;" too busy trying to get
stuff done.

> 
> 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.

No one doubts that there is room for improvement.  However, the
direction is better documentation, not different names.  Better names is
fine, but I have not heard any remotely convincing alternative for any
of the above terms.

* Or me for that matter.  I'm not an academic now and certainly wasn't
when I started learning Haskell.  I didn't know what a monoid was, had
never heard of category theory or monads or functors.  I was using
monads and functors and monoids in less than a month after I started
using Haskell.

** Heck, papers and decades worth of mathematical texts at almost every
level is a heck of a lot more documentation than most "poorly
documented" interfaces have.

___
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

[Cale Gibbard]

2009/1/15 Andrew Coppin :
> 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.

 - Cale
___
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

[Dan Doel]

On Thursday 15 January 2009 6:21:28 pm David Menendez wrote:
> On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin
>
>  wrote:
> > As an aside, the integers form two different monoids. Haskell can't
> > [easily] handle that. Does anybody know of a language that can?
>
> Some of the ML-derived languages can do that. Essentially, your code
> takes another module which implements a monoid as an argument.
>
> The catch is that you have to explicitly provide the monoid
> implementation in order to use your code.

You can do that in Haskell, as well, although it will end up uglier than ML. 
You can write your own dictionary type:

  data Monoid a = Monoid { unit :: a , bin :: m -> m -> m }

And pass that around:

  twice :: Monoid m -> m -> m
  twice mon m = bin mon m m

And even manually simulate locally opening the dictionary with a where clause

  twice mon m = m ++ m
   where (++) = bin mon

This is, after all, what GHC translates type classes into behind the scenes 
(although that isn't necessarily how they must be implemented).

Some folks even argue that type classes are overused and this style should be 
significantly more common.

-- 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

[Jonathan Cast]

On Thu, 2009-01-15 at 15:25 -0800, Max Rabkin wrote:
> On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard  wrote:
> > 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.
> 
> It's rather funny that there's a mathematical sense in which all
> monoid operations *are* appending. The free monoid on a set has
> appending as its operation, and the free monoid is initial in the
> category of monoids on that set (by definition), so all monoid
> operations are appending, modulo some equivalence relation.

Right.  So we start explaining that to new Haskellers.  We already have
participants in this discussion who can never quite remember where the
term Monad comes from; and now we need them to remember some complicated
argument about quotients of free monoids justifying the term `Append'?

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

[Max Rabkin]

On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard  wrote:
> 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.

It's rather funny that there's a mathematical sense in which all
monoid operations *are* appending. The free monoid on a set has
appending as its operation, and the free monoid is initial in the
category of monoids on that set (by definition), so all monoid
operations are appending, modulo some equivalence relation.

:)

--Max
___
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

[Manlio Perillo]

John Goerzen ha scritto:

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. 


I'm fine with current names.

However I would like to see better documentation, and examples.

You can't just have in the documentation:
this is xxx from yyy branch of mathematics, see this paper.

You should explain how (and why) to use xxx.

> [...]


Regards Manlio Perillo
___
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]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[David Menendez]

On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin
 wrote:
>
> As an aside, the integers form two different monoids. Haskell can't [easily]
> handle that. Does anybody know of a language that can?

Some of the ML-derived languages can do that. Essentially, your code
takes another module which implements a monoid as an argument.

The catch is that you have to explicitly provide the monoid
implementation in order to use your code.

-- 
Dave Menendez 

___
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

[Cale Gibbard]

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 :
> 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 +, 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  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
>
___
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

[Cale Gibbard]

> 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Derek Elkins]

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 +, 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  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

[Cale Gibbard]

2009/1/15 Sittampalam, Ganesh :
> 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Cale Gibbard]

> 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[pepe]

On 15/01/2009, at 23:27, Duncan Coutts wrote:


On Thu, 2009-01-15 at 21:21 +, 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[David Menendez]

On Thu, Jan 15, 2009 at 5:27 PM, Duncan Coutts
 wrote:
> On Thu, 2009-01-15 at 21:21 +, 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 

___
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

[Dan Piponi]

On Thu, Jan 15, 2009 at 2:24 PM, Miguel Mitrofanov
 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Peter Verswyvelen]

>
> 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Andrew Coppin]

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
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 21:21 +, 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Miguel Mitrofanov]

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
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

[Duncan Coutts]

On Thu, 2009-01-15 at 21:59 +, 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[John Goerzen]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Dan Weston]

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
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

[Steve Schafer]

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Dan Piponi]

On Thu, Jan 15, 2009 at 1:29 PM, Andrew Coppin
 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
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 16:03 -0500, Andrew Wagner wrote:
> 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

Data.Foldable has several functions that use an arbitrary monoid.

A new API I've been working on for manipulating cabal files uses a tree
of values of any monoid type.

Sets of installation paths is a monoid and is parametrised by another
monoid type (so we can have both sets of file paths and path templates).
A similar point applies for package indexes.

Most of the utility functions for handling command line arguments in
Cabal are parameterised by the monoid, because different command line
flags are different kinds of monoid. Some are list monoids, others are
first / last style monoids.


But it's not just the ability to write generic functions that is
relevant. 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.

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

[Jonathan Cast]

On Thu, 2009-01-15 at 21:59 +, 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.

But this contention is false.

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

[Jonathan Cast]

On Thu, 2009-01-15 at 21:29 +, Andrew Coppin wrote:
> 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...

Beg pardon?  That was an argument?  I'm sorry, but I can't infer your
middle term.

> 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.

I didn't know this.  I intend to start.  But, in any case, you picked
your counter-example *from within software engineering*, at least as
broadly understood.  My claim is that the computer industry as a whole
is *sick*, that we are simply going about this enterprise of dealing
with these (memory-limited) universal Turing machines (= implementations
of lambda calculus = universal recursive functions) *wrong*.  More cases
of this, within the computer industry, re-enforces my claim, rather than
weakening it.

> Don't get me wrong, there are mathematical concepts that are relevant to 
> computing,

You mean like monads?  

>  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.

Look, if you want (++), you know where to find it.  Or are you
complaining that you shouldn't have to study mathematics to understand
what (++) and, say, the choice operation on events, have in common?

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

[Thomas DuBuisson]

> 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.
___
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]

On Thu, 2009-01-15 at 21:17 +, Andrew Coppin wrote:
> Sebastian Sylvan wrote:
> >
> >
> > On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin 
> > 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... ;-)

But you don't seem to be capable of separating your valid complaints
from your invalid ones.  Everyone wants the Haddock documentation to be
maximally useful.  But the should never be a confusion between
*defining* a term used in a library and *choosing* that term.  They are
simply different activities, and neither can be a substitute for the
other.

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

[Jonathan Cast]

On Thu, 2009-01-15 at 17:13 +, Sittampalam, Ganesh wrote:
> 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.

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.

(Or are you suggesting we should aim for programmers to be able to use
Haskell (or just certain libraries?) without learning it first?)

jcc


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe