* John Goerzen jgoer...@complete.org [2009-01-15 10:15:36 -0600]:
If you're learning Haskell, which communicates the idea more clearly:
* Appendable
or
* Monoid
I can immediately figure out what the first one means.
I think that's deceptively misleading. Sure, list1 `mappend`
* Andrew Coppin andrewcop...@btinternet.com [2009-01-16 22:20:35 +]:
A problem I see a lot of [and other people have mentioned this] is that
a lot of documentation presents highly abstracted things, and gives *no
hint* of why on earth these might possibly be useful for something.
I
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.
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
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
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
On Sun, 18 Jan 2009 08:51:10 +0100
david48 dav.vire+hask...@gmail.com wrote:
On Sat, Jan 17, 2009 at 11:19 PM, Dan Piponi dpip...@gmail.com
wrote:
On Sat, Jan 17, 2009 at 1:47 AM, david48
dav.vire+hask...@gmail.com wrote:
why would I
need to write a running count this way instead of,
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
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
2009/1/18 Don Stewart d...@galois.com:
ross:
On Sat, Jan 17, 2009 at 09:12:32PM -0500, a...@spamcop.net wrote:
And FWIW, I agree with everyone who has commented that the documentation
is inadequate. It'd be nice if there was some way to contribute better
documentation without needing
david.waern:
2009/1/18 Don Stewart d...@galois.com:
ross:
On Sat, Jan 17, 2009 at 09:12:32PM -0500, a...@spamcop.net wrote:
And FWIW, I agree with everyone who has commented that the documentation
is inadequate. It'd be nice if there was some way to contribute better
documentation
On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
On Fri, 2009-01-16 at 14:16 +0100, david48 wrote:
Part of the problem is that something like a monoid is so general that
I can't wrap my head around why going so far in the abstraction.
For example, the writer
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,
2009/1/17 Andrew Coppin andrewcop...@btinternet.com:
Cory Knapp wrote:
Actually, that was part of my point: When I mention Haskell to people, and
when I start describing it, they're generally frightened enough by the focus
on pure code and lazy evaluation-- add to this the inherently abstract
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
On Sat, Jan 17, 2009 at 7:33 AM, Lennart Augustsson
lenn...@augustsson.netwrote:
Thinking that Functor allows you to apply a function to all elements
in a collection is a good intuitive understanding. But fmap also
allows applying a function on elements of things that can't really
be called
On Sat, Jan 17, 2009 at 1:47 AM, david48 dav.vire+hask...@gmail.com wrote:
why would I
need to write a running count this way instead of, for example, a non
monadic fold, which would probably result in clearer and faster code?
Maybe my post here will answer some questions like that:
G'day all.
Quoting John Goerzen jgoer...@complete.org:
If I see Appendable I can guess what it might be. If I see monoid, I
have no clue whatsoever, because I've never heard of a monoid before.
Any sufficiently unfamiliar programming language looks like line noise.
That's why every new
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)
On Sat, 2009-01-17 at 10:47 +0100, david48 wrote:
On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
On Fri, 2009-01-16 at 14:16 +0100, david48 wrote:
Part of the problem is that something like a monoid is so general that
I can't wrap my head around why going
On Sat, Jan 17, 2009 at 11:19 PM, Dan Piponi dpip...@gmail.com wrote:
On Sat, Jan 17, 2009 at 1:47 AM, david48 dav.vire+hask...@gmail.com wrote:
why would I
need to write a running count this way instead of, for example, a non
monadic fold, which would probably result in clearer and faster
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
2009/1/15 Derek Elkins derek.a.elk...@gmail.com:
On Thu, 2009-01-15 at 18:27 +, Lennart Augustsson wrote:
On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore p.f.mo...@gmail.com wrote:
Mathematical precision isn't appropriate in all disciplines.
That's very true. But programming is one where
It's a criticism already voiced by the great David Bowie:
My Brain Hurt like a warehouse, it had no room to spare
I had to cram so many things to store everything in there
Immanuel
On Thu, Jan 15, 2009 at 4:34 PM, John Goerzen jgoer...@complete.org wrote:
Hi folks,
Don Stewart noticed
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
On Thu, 2009-01-15 at 18:41 -0500, Cale Gibbard wrote:
2009/1/15 Andrew Coppin andrewcop...@btinternet.com:
OK, well then my next question would be in what say is defining
configuration files as a monoid superior to, uh, not defining them as a
monoid? What does it allow you to do that you
On Fri, Jan 16, 2009 at 5:39 AM, Creighton Hogg wch...@gmail.com wrote:
For you folks who work on GHC, is it acceptable to open tickets for
poor documentation of modules in base? I think leaving the
documentation to the tragedy of the commons isn't the best move, but
if even a few of us could
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
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 -
On Fri, Jan 16, 2009 at 1:23 PM, Philippa Cowderoy fli...@flippac.org wrote:
On Thu, 15 Jan 2009, Lennart Augustsson wrote:
If I see Monoid I know what it is, if I didn't know I could just look
on Wikipedia.
And if you're a typical programmer who is now learning Haskell, this will
likely
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
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
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
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
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
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`
On Fri, Jan 16, 2009 at 8:39 AM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
Ross just updated the documentation for the Monoid module. Here is how
it reads now:
The module header now reads simply:
A class for monoids (types with an associative binary operation
that has
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
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
On Fri, Jan 16, 2009 at 12:19 PM, Ross Paterson r...@soi.city.ac.uk wrote:
On Fri, Jan 16, 2009 at 12:00:40PM -0500, David Menendez wrote:
It would be nice to explain what operations have been chosen for the
Monoid instances of Prelude data types. (Maybe this belongs in the
Prelude
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
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
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
Steve Schafer st...@fenestra.com writes:
But if the building is a run-of-the-mill design, then the engineer
checking it is unlikely to use anything beyond simple algebra. It's only
in case of unusual structures and one-offs (skyscrapers, most anything
built in Dubai these days, etc.) that
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
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
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
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
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
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
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
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
On Sat, Jan 17, 2009 at 12:14 AM, Anton van Straaten
an...@appsolutions.com wrote:
I still think existential quantification is a step too far though. :-P
Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
On 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
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.
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
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
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
On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Lennart Augustsson wrote:
I have replied on his blog, but I'll repeat the gist of it here.
Why is there a fear of using existing terminology that is exact?
Why do people want to invent new words
Why do people think that you should be able to understand everything
without ever looking things up?
I'll get back to my example from the comment on the blog post. If I
see 'ghee' in a cook book I'll check what it is (if I don't know). It
has a precise meaning and next time I'll know. Inventing
Most people don't understand pure functional programming either. Does
that mean we should introduce unrestricted side effects in Haskell?
-- Lennart
On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
Lennart Augustsson wrote:
a name that anyone can figure out with just a little effort.
I think the problem is that all these pieces of little effort
soon mount up. It's not just the cost of looking it up, but also
of remembering it the next time and so on. It's fine when you
only encounter the
For what it's worth, many (most/all?) programmers I know in person
don't have the slightest clue about Category Theory and they may have
known about abstract algebra once upon a time but certainly don't
remember any of it now. They usually understand the concepts perfectly
well enough but
I won't deny that Haskell has a large number of unfamiliar term if
you've only seen Java before.
But I don't think that giving them all happy fuzzy names will help
people in the long run.
-- Lennart
On Thu, Jan 15, 2009 at 4:40 PM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com
Lennart Augustsson wrote:
Why do people think that you should be able to understand everything
without ever looking things up?
I don't. But looking things up has to be helpful. In all to many
cases, looking things up means clicking the link to someone's old
academic paper or some article
At the risk of painting my own bikeshed...
If you're learning Haskell, which communicates the idea more clearly:
* Appendable
or
* Monoid
Would you call function composition (on endofunctions) appending?
The join of a monad? A semi-colon (as in sequencing two imperative
statements)?
By no means do I suggest that Wikipedia should replace Haskell library
documentation.
I think the libraries should be documented in a mostly stand-alone way
(i.e., no references to old papers etc.). In the case of Monoid, a
few lines of text is enough to convey the meaning of it and gives an
Of course not, the wikipedians would probably have your head for
notability guidelines or something ;-)
But seriously, I would have saved many hours of my life and probably
many future ones if type class instances were documented and showed up
in the haddock docs.
-Ross
On Jan 15, 2009,
On Thu, Jan 15, 2009 at 10:46 AM, Ross Mellgren rmm-hask...@z.odi.ac wrote:
snip
Usually when encountering something like Monoid (if I didn't already know
it), I'd look it up in the library docs. The problem I've had with this
tactic is twofold:
First, the docs for the typeclass usually don't
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
I think the documentation should be reasonably newbie-friendly too.
But that doesn't mean we should call Monoid Appendable.
Appendable is just misleading, since Monoid is more general than appending.
-- Lennart
On Thu, Jan 15, 2009 at 4:51 PM, John Goerzen jgoer...@complete.org wrote:
Lennart
I'm totally with you on the instance documentation. I wish haddock allowed it.
On Thu, Jan 15, 2009 at 4:56 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote:
Of course not, the wikipedians would probably have your head for notability
guidelines or something ;-)
But seriously, I would have saved
On Thu, Jan 15, 2009 at 1:44 PM, Wouter Swierstra w...@cs.nott.ac.uk wrote:
Would you call function composition (on endofunctions) appending? The join
of a monad? A semi-colon (as in sequencing two imperative statements)? How
do you append two numbers? Addition, multiplication, or something
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
jgoerzen:
Hi folks,
Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml
hacker:
http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/
It's a great post, and I encourage people to read it. I'd like to
highlight one particular paragraph:
I'd also
Lennart Augustsson wrote:
Most people don't understand pure functional programming either.
Does that mean we should introduce unrestricted side effects in
Haskell?
No, just that we should seek to minimise the new stuff they have
to get to grips with.
Ganesh
On Thu, Jan 15, 2009 at 7:34 AM, John Goerzen jgoer...@complete.org quoted:
I'd be inclined to call it something like Appendable.
But I don't know what Appendable means. Maybe it means
class Appendable a where
append :: a x - x - a x
ie. a container x's lets you can add an x to the end
Beats me. As I said, I don't think Haskell gets all the names right. :)
On Thu, Jan 15, 2009 at 5:15 PM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Lennart Augustsson wrote:
I think the documentation should be reasonably newbie-friendly too.
But that doesn't mean we
2009/1/15 Lennart Augustsson lenn...@augustsson.net:
Why do people think that you should be able to understand everything
without ever looking things up?
Understand, no, but have an intuition about, very definitely yes. In
mathematics (and I speak as someone with a mathematical degree, so if
I
Sittampalam, Ganesh wrote:
Lennart Augustsson wrote:
I think the documentation should be reasonably newbie-friendly too.
But that doesn't mean we should call Monoid Appendable.
Appendable is just misleading, since Monoid is more general than
appending.
Then why does it have a member named
On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren rmm-hask...@z.odi.ac wrote:
Usually when encountering something like Monoid (if I didn't already know
it), I'd look it up in the library docs. The problem I've had with this
tactic is twofold:
First, the docs for the typeclass usually don't
It is rather funny. When we are young kids, we learn weird symbols like
A B C a b c 1 2 3
which we accept after a while.
Then we get to learn more complex symbols like
! ? + - /
and that takes some time to get used to, but eventually, that works too.
But Functor, Monoid or Monad, that we
John Goerzen wrote:
Though if all we're talking about is naming, I would still maintain that
newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS:
APPENDABLE MEANS MONOID in the haddock docs ;-)
This is backwards.
The real problem here is that most people coming from other
That's very true. But programming is one where mathematical precision
is needed, even if you want to call it something else.
On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore p.f.mo...@gmail.com wrote:
Mathematical precision isn't appropriate in all disciplines.
On Jan 15, 2009, at 1:21 PM, David Menendez wrote:
On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren rmm-
hask...@z.odi.ac wrote:
Second is that there appears to be no way to document an
_instance_. It
would be really handy if there were even a single line under
Instances
Monoid ([] a) that
John Goerzen wrote:
Haskell
developers, stop letting the category theorists name
things. Please. I beg of you.
I'd like to echo that sentiment!
He went on to add:
If you?re not a category theorists, and you're learning (or thinking
of learning) Haskell, don't get scared off by
For what it's worth, many (most/all?) programmers I know in person
don't have the slightest clue about Category Theory and they may
have known about abstract algebra once upon a time but certainly
don't remember any of it now. They usually understand the concepts
perfectly well enough but
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
On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin
andrewcop...@btinternet.comwrote:
The sad thing is, it's not actually complicated. The documentation just
makes it seem like it is! :-(
This is so true for a heck of a lot of things. Existential quantification
being just one of them. Loads of
On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote:
PS. As a small aside... Is the Monoid class actually used *anywhere* in
all of Haskell?
Yes.
They're used quite a lot in Cabal. Package databases are monoids.
Configuration files are monoids. Command line flags and sets of command
line
duncan.coutts:
On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote:
PS. As a small aside... Is the Monoid class actually used *anywhere* in
all of Haskell?
Yes.
They're used quite a lot in Cabal. Package databases are monoids.
Configuration files are monoids. Command line flags
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
Graphic composition using painters algorithm can be seen as a monoid.
data Graphic = Empty
| Graphic `Over` Graphic
| Ellipse Bounds
|
instance Monoid Graphic where
mempty = Empty
mappend = Over
So all functions that
Sebastian Sylvan wrote:
On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin
andrewcop...@btinternet.com mailto:andrewcop...@btinternet.com wrote:
The sad thing is, it's not actually complicated. The documentation
just makes it seem like it is! :-(
This is so true for a heck of a lot of
On Thu, Jan 15, 2009 at 12:11 PM, John Goerzen jgoer...@complete.org wrote:
On Thu, Jan 15, 2009 at 07:46:02PM +, Andrew Coppin wrote:
John Goerzen wrote:
can we at least write some documentation that doesn't
require a PhD to comprehend?
Several people have suggested this, and I think it
Duncan Coutts wrote:
On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote:
PS. As a small aside... Is the Monoid class actually used *anywhere* in
all of Haskell?
Yes.
They're used quite a lot in Cabal. Package databases are monoids.
Configuration files are monoids. Command line
On Thu, 2009-01-15 at 09:34 -0600, John Goerzen wrote:
Hi folks,
Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml
hacker:
http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/
It's a great post, and I encourage people to read it. I'd like to
On Thu, Jan 15, 2009 at 12:38 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk
wrote:
On Thu, 2009-01-15 at 19:46 +, Andrew Coppin wrote:
PS. As a small aside... Is the Monoid class actually used *anywhere* in
all of Haskell?
Yes.
They're used quite a lot in Cabal. Package databases
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
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
1 - 100 of 147 matches
Mail list logo