|
|
1 ...
3456789
... 12
|
|
On Thu, Jan 15, 2009 at 10:18 PM, Jonathan Cast
< [hidden email]> 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
<snip>
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On 15 Jan 2009, at 16:34, John Goerzen wrote: [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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On Thu, Jan 15, 2009 at 07:46:02PM +0000, 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On Thu, Jan 15, 2009 at 11:54 PM, ChrisK < [hidden email]> wrote:
>
> So the original article, which coined 'Appendable', did so without much
> thought in the middle of a long post. But it does show the thinking was
> about collections and there is one ONE instance of Monoid at
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html#t%3AMonoid>
> that is about a collection (Monoid ([] a)) that has a split operation.
The blind man at the back takes firm hold of the tail and says, "But
why do we need to call it an *elephant*? No-one knows what that is.
Everyone knows what a rope is, so we should just call it a rope."
And that is how the elephant came to be labelled a rope in all the guide books.
:-)
Cheers,
D
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
Here is a great "Monoid found in the wild story":
I just implemented a library for binary message serialization that follows
Google's protocol buffer format.
The documentation of this was very scattered in some respects but I kept reading
snippets which I have pasted below. The effect of these snippets is to document
that the messages on the wire should mimic an API where they can be combined in
various merge operations (right-biased, concatenation, and recursive merging),
and that well-formed messages have default values for all fields (which can be
set in the spec).
So the code below is a well thought out collection of properties that has
reinvented the wheel known as "Monoid", so the Haskell API creates Monoid instances.
http://code.google.com/apis/protocolbuffers/docs/encoding.html
> Normally, an encoded message would never have more than one instance of an
> optional or required field. However, parsers are expected to handle the case in
> which they do. For numeric types and strings, if the same value appears multiple
> times, the parser accepts the last value it sees. For embedded message fields,
> the parser merges multiple instances of the same field, as if with the
> Message::MergeFrom method – that is, all singular scalar fields in the latter
> instance replace those in the former, singular embedded messages are merged, and
> repeated fields are concatenated. The effect of these rules is that parsing the
> concatenation of two encoded messages produces exactly the same result as if you
> had parsed the two messages separately and merged the resulting objects. That
> is, this:
>
>> MyMessage message;
>> message.ParseFromString(str1 + str2);
>
> is equivalent to this:
>
>> MyMessage message, message2;
>> message.ParseFromString(str1);
>> message2.ParseFromString(str2);
>> message.MergeFrom(message2);
>
> This property is occasionally useful, as it allows you to merge two messages
> even if you do not know their types.
And this at http://code.google.com/apis/protocolbuffers/docs/proto.html
> As mentioned above, elements in a message description can be labeled
> optional. A well-formed message may or may not contain an optional element.
> When a message is parsed, if it does not contain an optional element, the
> corresponding field in the parsed object is set to the default value for that
> field. The default value can be specified as part of the message description.
> For example, let's say you want to provide a default value of 10 for a
> SearchRequest's result_per_page value.
>
>> optional int32 result_per_page = 3 [default = 10];
>
> If the default value is not specified for an optional element, a
> type-specific default value is used instead: for strings, the default value
> is the empty string. For bools, the default value is false. For numeric
> types, the default value is zero. For enums, the default value is the first
> value listed in the enum's type definition.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
2009/1/15 Derek Elkins < [hidden email]>:
> On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote:
>> On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore < [hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
> 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.
I can't find the thread at the moment, but this has been discussed
before, and my recollection is that wikis were to be used to accumulate
documentation comments and updates (there also was some discussion
about the best format for comment patches, but getting content was
thought to be more important). So, there would be a subset of the
Haskell wiki for the base library, and package-specific wiki locations
for their documentations.
Haddock already seems to provide the necessary support:
http://www.haskell.org/haddock/doc/html/invoking.html --comments-base=URL , --comments-module=URL , --comments-entity=URL
Include links to pages where readers may comment on the documentation.
This feature would typically be used in conjunction with a Wiki system.
Use the --comments-base option to add a user comments link in the header
bar of the contents and index pages. Use the --comments-module to add a
user comments link in the header bar of each module page. Use the
--comments-entity option to add a comments link next to the documentation
for every value and type in each module.
In each case URL is the base URL where the corresponding comments page
can be found. For the per-module and per-entity URLs the same substitutions
are made as with the --source-module and --source-entity options above.
For example, if you want to link the contents page to a wiki page, and every
module to subpages, you would say haddock --comments-base=url
--comments-module=url/%M
So it seems it is only a question of actually using these options with
suitably prepared per-package documentation wikis, and improving
the documentation or asking for clarifications would be almost as easy
as emailing here!-) And if everyone who stumbles over a documentation
problem puts the solution on the wiki, documentation should improve
quickly (there is still the issue of selecting wiki improvement suggestions
for inclusion in the "real" documentation).
Does anyone know why these options are not in use already?
Claus
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
That looks like a freakin' cool idea; however very hard to implement;
so why not write such wikis in predefined places, like,
haskell.org/haskellwiki/Data/Monoid/ and allow haddock to
automatically put links there from the generated documentation? This
would make the documentation (on the wiki) more organized, more
'extensible' and people would know a place where they can surely share
their knowledge in a useful and very findable way.
Are there any drawbacks to this?
2009/1/16 Apfelmus, Heinrich < [hidden email]>:
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On Fri, Jan 16, 2009 at 3:46 AM, Eugene Kirpichov <[hidden email]> wrote:
That looks like a freakin' cool idea; however very hard to implement;
so why not write such wikis in predefined places, like,
haskell.org/haskellwiki/Data/Monoid/ and allow haddock to
automatically put links there from the generated documentation? This
would make the documentation (on the wiki) more organized, more
'extensible' and people would know a place where they can surely share
their knowledge in a useful and very findable way.
Are there any drawbacks to this?
2009/1/16 Apfelmus, Heinrich <[hidden email]>:
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
Thorkil Naur wrote:
> Peter Verswyvelen wrote:
>>
>> 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.
>>
>> But Functor, Monoid or Monad, that we cannot accept anymore. Why, because
>> these are not intuitive? Are the symbols above "intuitive"?
>
> I think there is a simple explanation of this: Consider the amount of time you
> spent, as a young kid, to learn to get used to these funny 1, 2, a, b, x, y,
> +, - and so on. I haven't got the exact schedules from school, but my
> impression is that we are talking about hours and hours of drill and
> practice, over weeks, months, years.
>
> So, to learn to become familiar and effective in using new and complex
> concepts, we should just accept that it sometimes may take a while. And
> that's it. It is all a matter of practice, exposure, and guidance.
That's a highly relevant wisdom! Learning something new needs practice /
time and good tutors / books / guidance. It doesn't matter whether the
new thing is "alphabet", "summation", "boolean", "programming" or "monoid".
Obviously, those who know what a monoid is have already invested years
of time practicing mathematics while those that even attack the name
"monoid" clearly lack this practice. It's like peano virtuosoes compared
to beginning keyboard pressers.
Concerning the question whether it is necessary to invest at least some
time on mathematical practice to learn Haskell, the answer is yes. There
is no shortcut to learning purely functional programming and reasoning.
Renaming "monoid" to "appendable" and "monad" to "warm fuzzy thing" are
but useless cosmetic changes that don't make anything easier.
How to learn? The options are, in order of decreasing effectiveness
university course teacher in person
book irc
mailing list
online tutorial
haskell wiki
haddock documentation
Usually, the best thing is to have a teacher, i.e. to go to a good CS
course on Haskell. Books and #haskell or the mailing list are a good
substitute, but require self-discipline. Both teachers and books cost
money, but you get what you pay for, the online tutorial, wiki and
haddock worlds are too messy to be effective until very late in the
learning process.
In particular, monoids are defined and used in
Richard Bird.
Introduction to Functional Programming using Haskel (2nd edition).
http://www.amazon.com/ Introduction-Functional-Programming-using-Haskell/dp/0134843460
I think that this book is a good benchmark for measuring the amount of
practice to be invested in learning Haskell.
Regards,
H. Apfelmus
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
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_expressionsOk, 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
> < [hidden email]> wrote:
>> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
>> < [hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On Fri, Jan 16, 2009 at 5:39 AM, Creighton Hogg < [hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On Thu, 2009-01-15 at 18:41 -0500, Cale Gibbard wrote:
> 2009/1/15 Andrew Coppin < [hidden email]>:
> > 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
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.
--
[hidden email]
"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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
2009/1/16 Apfelmus, Heinrich < [hidden email]>:
> How to learn? The options are, in order of decreasing effectiveness
>
> university course teacher in person
> book irc
> mailing list
> online tutorial
> haskell wiki
> haddock documentation
Reason by analogy from known/similar areas. I think the point here is
that for Haskell, this is more possible for mathematicians than for
programmers. And that's an imbalance that may need to be addressed
(depending on who you want to encourage to learn).
But I agree that reasoning by analogy is not a very good way of
learning. And I think it's been established that the real issue here
is the documentation - complete explanations and better
discoverability[1] are needed. Note that for people who don't want to
(or can't) invest money, and who don't want to take up too much of
others' time, documentation is the most important option.
Paul.
[1] When I say "discoverability", I mean that no matter how good the
documentation of (say) Monoid is, it's useless unless there's
something that prompts me, based on the real-world programming problem
I have (for example, merging a set of configuration options to use an
example mentioned in this thread), to *look* at that documentation.
That's where names make a difference.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
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.
--
[hidden email]
"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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On Fri, Jan 16, 2009 at 1:23 PM, Philippa Cowderoy < [hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
1 ...
3456789
... 12
|
Locked
