Comments from OCaml Hacker Brian Hurt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
237 messages Options
1234567 ... 12
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Dan Piponi-2
On Thu, Jan 15, 2009 at 1:29 PM, Andrew Coppin
<[hidden email]> wrote:
> But you
> really *should not* need to do an undergraduate course in mathematical
> theory just to work out how to concat two lists. That's absurd. Some kind of
> balance needs to be found.

Balance is good, but it's hard to find a balance when people exaggerate so much.

Firstly: You don't need monoids to concat two lists. You need monoids
when you want to abstract the operation of concatting two lists so
that the same code can be reused in other ways. A good example is the
writer monad. The author of that monad could have made it work just
with strings. But one of the coollest things about Haskell is the way
it's so amenable to micro-refactoring. By realising there's a bunch of
other things the Writer monad can do using *exactly the same
implementation* you get reusability. If you don't want this kind of
reusability you may be better off with C or Fortran.

Secondly: you don't need an "undergraduate course." to understand
monoids. A monoid is just a collection of things with an operation
allowing you to combine two things to get another one. And an element
that acts like 'nothing' so that when you combine it with other
elements it leaves them unchanged (and an additional simple
condition). This would be the first 30 seconds of a course on monoids
that presupposes nothing more than a naive idea of what a set is. The
only thing that's difficult about monoids is that it's a new word.
There's little 'theory' involved.

Your talk of undergraduate courses to concat two lists isn't grounded
in any kind of reality, muddies the waters, and probably scares people
away from Haskell by giving the impression that it's much harder than
it is.
--
Dan
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Steve Schafer
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
On Thu, 15 Jan 2009 13:21:57 -0800, you wrote:

>Where, in the history of western civilization, has there ever been an
>engineering discipline whose adherents were permitted to remain ignorant
>of the basic mathematical terminology and methodology that their
>enterprise is founded on?

Umm, all of them?

>No one may be a structural engineer, and remain ignorant of physics.  No
>one may be a chemical engineer, and remain ignorant of chemistry.  Why
>on earth should any one be permitted to be a software engineer, and
>remain ignorant of computing science?

Do you know any actual working structural or chemical engineers? Most
engineering disciplines require a basic grasp of the underlying theory,
yes, but not much beyond that. Pretty much everything else is covered by
rules (either rules of thumb or published standards).

Show me an electrical engineer who can explain the physics of a pn
junction and how it acts as a rectifier, or a civil engineer who can
explain why the stress/strain curve of a steel beam has the shape that
it does, or a chemical engineer who can explain molecular orbital
theory. Those kinds of engineers do exist, of course, but they are few
and far between. If you aim your product only at the kinds of engineers
who _can_ do those things, you will be reaching a tiny, tiny fraction of
the overall population.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Dan Weston
In reply to this post by MigMit
Maybe you can explain that again?

I see how the subset of Kleisli arrows (a -> m a) forms a monoid (a,
return . id, >>=), but what to do with (a -> m b)? (>>=) is not closed
under this larger set.

Dan

Miguel Mitrofanov wrote:

>> Notice that "monoid" sounds almost *exactly* like "monad". And yet,  
>> what you use them for is wildly unrelated.
>
> Well, monads are monoids. I remember explaining you that...
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

John Goerzen-3
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
On Thu, Jan 15, 2009 at 01:50:11PM -0800, Jonathan Cast wrote:

> On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote:
> > Lennart Augustsson wrote:
> > > Most people don't understand pure functional programming either.  Does
> > > that mean we should introduce unrestricted side effects in Haskell?
> >
> > The key is to introduce concepts to them in terms they can understand.
> >
> > You introduce it one way to experienced abstract mathematicians, and a
> > completely different way to experienced Perl hackers.  I wouldn't expect
> > a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok
> > abstract math.  People have different backgrounds to draw upon, and we
> > are under-serving one community.
>
> False.  We are failing to meet the un-realistic expectations of advanced
> Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as
> to the ease with which they should be able to learn Haskell.

What part of that are you saying is false?  That people have different
backgrouns and learn differently?

>
> jcc
>
>
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Duncan Coutts
In reply to this post by Thomas DuBuisson
On Thu, 2009-01-15 at 21:59 +0000, Thomas DuBuisson wrote:
> > How does forcing them to learn proposed terminology such as `Appendable'
> > help here?  Learners of Haskell do still need to learn what the new word
> > means.
>
> The contention is that 'Appendable' is an intuitive naming that people
> will already have a rudimentary grasp of.  This as opposed to Monoid,
> which absolutely requires looking up for the average coder.

It reminds me a bit of my school French classes. Our teacher often
brought up the subject of "false friends", that is words in the foreign
language that sound superficially familiar to one in the native language
but are in fact different in subtle but important ways.

In this case Appendable has the wrong connotations for what the Monoid
class does. Appendable does not sound symmetric to me and it places too
much emphasis on monoids that resemble lists.

Perhaps there is a more common word that reflects the meaning without
being misleading. But if we cannot find one, then picking a name that is
unfamiliar to most people may well be better than picking a name that is
misleading or is too narrow.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

MigMit
In reply to this post by Dan Weston

On 16 Jan 2009, at 01:10, Dan Weston wrote:

> Maybe you can explain that again?

Sure.

Consider the following setting: a category C and a bifunctor T : C x C  
-> C, which is associative and have a (left and right) unit I. This is  
what is called "monoidal category".

A "monoid" is an object X in C with two morphisms: I -> X and T(X, X) -
 > X, satisfying two relatively simple conditions (I don't want to  
draw commutative diagrams).

If your category is a category of sets, and T is a cartesian product,  
then you have ordinary monoids (I is a one-element set, first morphism  
is a unit of a monoid, and second morphism is monoid multiplication).

If, however, you category is a category of endofunctors of some  
category D (that is, functors D -> D), and T is composition, then our  
"monoids" become monads on D: I is an identity functor, first morphism  
is "return", and second one is "join".

>
>
> I see how the subset of Kleisli arrows (a -> m a) forms a monoid (a,  
> return . id, >>=), but what to do with (a -> m b)? (>>=) is not  
> closed under this larger set.
>
> Dan
>
> Miguel Mitrofanov wrote:
>>> Notice that "monoid" sounds almost *exactly* like "monad". And  
>>> yet,  what you use them for is wildly unrelated.
>> Well, monads are monoids. I remember explaining you that...
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Duncan Coutts
In reply to this post by Andrew Coppin
On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote:

> OK, well then my next question would be "in what say is defining
> configuration files as a monoid superior to, uh, not defining them as a
> monoid?" What does it allow you to do that you couldn't otherwise? I'm
> not seeing any obvious advantage, but you presumably did this for a
> reason...

[ I know I'm repeating myself from elsewhere in this thread but this is
the better question for the answer :-) ]

By making a type an instance of Monoid instead of exporting
emptyFoo, joinFoo functions it makes the API clearer because it shows
that we are re-using an existing familiar concept rather than inventing
a new one. It also means the user already knows that joinFoo must be
associative and have unit emptyFoo without having to read the
documentation.

Perhaps it's what OO programmers would call a design pattern. Identify a
pattern, give it a name and then when the pattern crops up again (and
again) then the reader of the code will have an easier time because they
are already familiar with that named pattern.

Of course the fact that we can occasionally use the pattern to
parametrise and write more re-usable code is a bonus.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Peter Verswyvelen-2
In reply to this post by Andrew Coppin
I'm not sure having a Monoid class is actually useful for anything - but if we must have it, there seems to be little better possible name for something so vague.

IMO the Monoid class is useful since, if you define mempty and mappend, you get mconcat for free. I don't see what the problem is. Most people will accept Functor, as it used a lot. Monoid might be less used, but if you reject it, then by principle you must just as well reject Functor, and any other type classes. 




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Dan Piponi-2
In reply to this post by MigMit
On Thu, Jan 15, 2009 at 2:24 PM, Miguel Mitrofanov
<[hidden email]> wrote:

> If, however, you category is a category of endofunctors of some category D
> (that is, functors D -> D), and T is composition, then our "monoids" become
> monads on D: I is an identity functor, first morphism is "return", and
> second one is "join".

You can see this more concretely in Haskell code here:
http://sigfpe.blogspot.com/2008/11/from-monoids-to-monads.html

(This probably ought to be in a separate thread.)
--
Dan
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

David Menendez-2
In reply to this post by Duncan Coutts
On Thu, Jan 15, 2009 at 5:27 PM, Duncan Coutts
<[hidden email]> wrote:

> On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote:
>
>> OK, well then my next question would be "in what say is defining
>> configuration files as a monoid superior to, uh, not defining them as a
>> monoid?" What does it allow you to do that you couldn't otherwise? I'm
>> not seeing any obvious advantage, but you presumably did this for a
>> reason...
>
> [ I know I'm repeating myself from elsewhere in this thread but this is
> the better question for the answer :-) ]
>
> By making a type an instance of Monoid instead of exporting
> emptyFoo, joinFoo functions it makes the API clearer because it shows
> that we are re-using an existing familiar concept rather than inventing
> a new one. It also means the user already knows that joinFoo must be
> associative and have unit emptyFoo without having to read the
> documentation.

I assume these are all documented where the type is defined? One
disadvantage of Monoid compared to Monad is that you really need to
explain what operation your Monoid instance performs.

For example, the documentation for Maybe describes what its Monad
instance does, but not its Monoid instance.

I don't think any of the instances for [] are documented. (Admittedly,
this is difficult, since [] is not actually exported from anywhere.)

--
Dave Menendez <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Pepe Iborra-3
In reply to this post by Duncan Coutts

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

> On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote:
>
>> OK, well then my next question would be "in what say is defining
>> configuration files as a monoid superior to, uh, not defining them  
>> as a
>> monoid?" What does it allow you to do that you couldn't otherwise?  
>> I'm
>> not seeing any obvious advantage, but you presumably did this for a
>> reason...
>
> [ I know I'm repeating myself from elsewhere in this thread but this  
> is
> the better question for the answer :-) ]
>
> By making a type an instance of Monoid instead of exporting
> emptyFoo, joinFoo functions it makes the API clearer because it shows
> that we are re-using an existing familiar concept rather than  
> inventing
> a new one. It also means the user already knows that joinFoo must be
> associative and have unit emptyFoo without having to read the
> documentation.
>
> Perhaps it's what OO programmers would call a design pattern.  
> Identify a
> pattern, give it a name and then when the pattern crops up again (and
> again) then the reader of the code will have an easier time because  
> they
> are already familiar with that named pattern.

Exactly, documenting knowledge was one of the benefits of design  
patterns.
Monoid looks like the Composite pattern, one of the original GoF  
patterns.

Is Composite is a better name for Monoid?
I guess that when the GoF folks were writing the book they had to come  
up
with quite a few names, and some came out better than others.

If anything, the Haskell approach is more consistent.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Cale Gibbard
In reply to this post by Andrew Coppin
> off the top of their head what the difference between an epimorphism and a
> hylomorphism is?

They're not even from the same branch of mathematics.

Epimorphisms are defined in category theory, as arrows which can be
cancelled when they appear on the right of a composite, that is, if f
is an epimorphism, and g . f = h . f, then g = h. Such arrows are
somewhat comparable to surjective functions.

Hylomorphisms are from recursion theory. They are the composite of an
anamorphism (which builds up a recursive structure from an initial
seed) with a catamorphism, (which replaces the constructors in that
recursive structure with other functions).

Terminology has value, in that it allows you to see things in a new
way which is clearer than what could otherwise be achieved. Any
programmer worth their salt should be comfortable absorbing a new
term, the same way they learn a new library function.

We should remember that Haskell's beauty is not an accident. It is
proportional to the amount of effort which went into building the
solid mathematical foundations describing its semantics, and designing
a language which reflected those semantics as clearly as possible.

Discarding those foundations in an attempt to get more users is a
price I would personally never want to see us pay.

 - Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Cale Gibbard
In reply to this post by Sittampalam, Ganesh
2009/1/15 Sittampalam, Ganesh <[hidden email]>:
> Lennart Augustsson wrote:
>> I think the documentation should be reasonably newbie-friendly too.
>> But that doesn't mean we should call Monoid Appendable.
>> Appendable is just misleading, since Monoid is more general than
>> appending.
>
> Then why does it have a member named 'mappend'? :-)
>
> Ganesh

Good question. The names of the methods of the Monoid class are inappropriate.

My personal preference would be:

class Monoid m where
   zero :: m
   (++) :: m -> m -> m

(in the Prelude of course)

 - Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Comments from OCaml Hacker Brian Hurt

David Fox-7
In reply to this post by Justin Bogner
On Thu, Jan 15, 2009 at 9:04 AM, <[hidden email]> wrote:
John Goerzen <[hidden email]> writes:
> Wikipedia's first sentence about monoids is:
>
>   In abstract algebra, a branch of mathematics, a monoid is an algebraic
>   structure with a single, associative binary operation and an identity
>   element.
>
> Which is *not* intuitive to someone that comes from a background in....
>  any other programming language.
>

Instead of Wikipedia, why not try a dictionary? Looking up monoid using
dictionary.com:

 An operator * and a value x form a monoid if * is
 associative and x is its left and right identity.

On the other hand, appendable doesn't seem to be a word, and while you
can infer that it means "something that can be appended to", that's only
half of the story...


Monoid isn't something I came across and didn't understand, its something I should have been using for a long time before I discovered it.  But it never jumped out at me when I was browsing the library documentation tree.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Derek Elkins
In reply to this post by Lennart Augustsson
Actually programming requires -far more- precision than mathematics ever
has.  The standards of "formal" and "precise" that mathematicians use
are a joke to computer scientists and programmers.  Communication is
also more important or at least more center stage in mathematics than
programming.  Mathematical proofs are solely about communicating
understanding and are not required to execute on a machine.

On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote:

> That's very true.  But programming is one where mathematical precision
> is needed, even if you want to call it something else.
>
> On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore <[hidden email]> wrote:
> >
> > Mathematical precision isn't appropriate in all disciplines.
> >
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Cale Gibbard
In reply to this post by John Goerzen-3
> If you're learning Haskell, which communicates the idea more clearly:
>
>  * Appendable
>
> or
>
>  * Monoid
>
> I can immediately figure out what the first one means.  With the second,
> I could refer to the GHC documentation, which does not describe what a
> Monoid does.  Or read a wikipedia article about a branch of mathematics
> and try to figure out how it applies to Haskell.

However, "Appendable" carries baggage with it which is highly
misleading. Consider, for instance, the monoid of rational numbers
under multiplication (which, by the way, is quite useful with the
writer transformed list monad for dealing with probabilities) -- you
can claim that multiplication here is a sort of "appending", perhaps,
but it's not really appropriate. Modular addition, or multiplication
in some group is even farther from it.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Comments from OCaml Hacker Brian Hurt

Cale Gibbard
In reply to this post by David Fox-7
Yes! The library documentation tree has a way of making everything
seem equally important, when that is not the case. This is why we need
well-crafted tutorials and books.

2009/1/15 David Fox <[hidden email]>:
> Monoid isn't something I came across and didn't understand, its something I
> should have been using for a long time before I discovered it.  But it never
> jumped out at me when I was browsing the library documentation tree.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by John Goerzen-3
On Thu, 2009-01-15 at 16:16 -0600, John Goerzen wrote:

> On Thu, Jan 15, 2009 at 01:50:11PM -0800, Jonathan Cast wrote:
> > On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote:
> > > Lennart Augustsson wrote:
> > > > Most people don't understand pure functional programming either.  Does
> > > > that mean we should introduce unrestricted side effects in Haskell?
> > >
> > > The key is to introduce concepts to them in terms they can understand.
> > >
> > > You introduce it one way to experienced abstract mathematicians, and a
> > > completely different way to experienced Perl hackers.  I wouldn't expect
> > > a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok
> > > abstract math.  People have different backgrounds to draw upon, and we
> > > are under-serving one community.
> >
> > False.  We are failing to meet the un-realistic expectations of advanced
> > Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as
> > to the ease with which they should be able to learn Haskell.
>
> What part of that are you saying is false?  That people have different
> backgrouns and learn differently?

Not just differently.  Some people learn faster than others.  These
relative speeds also vary across different subjects.  I think the
implicit assumption in most complaints about learning Haskell is that
the ease with which any given developer learns Haskell (or learns a new
Haskell library or concept) should be comparable to the ease with which
said developers learns conventional languages, e.g. Perl.  This
assumption is false.  In fact, if someone finds Perl particularly easy
to learn (relative to other subjects), I would expect that person to
find Haskell particularly hard to learn (relative to other subjects).
Of course mathematicians find Haskell easier to learn than Perl
programmers do; this is a consequence of the nature of Haskell, the
nature of Perl, and the nature of mathematics.  We are under no
obligation to obtain equivalent outcomes from non-interchangeable
people.  That people who lack natural aptitude, or relevant prior
knowledge, for learning Haskell have more difficulty than those with
relevant natural aptitude or prior knowledge is in no way a failure of
the Haskell community.

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Cale Gibbard
In reply to this post by Derek Elkins
While you're absolutely correct and I agree with you, to be fair,
essentially all mathematicians have a sense of "rigourisability"
(whether they recognise it or not), which is a peculiar standard that
they apply to everything they hear or read. The level of rigour at
which mathematicians communicate is designed not to bore the listener
with details that they could easily supply for themselves, being an
intelligent mathematician, and not a mechanical abstraction.

 - Cale

2009/1/15 Derek Elkins <[hidden email]>:

> Actually programming requires -far more- precision than mathematics ever
> has.  The standards of "formal" and "precise" that mathematicians use
> are a joke to computer scientists and programmers.  Communication is
> also more important or at least more center stage in mathematics than
> programming.  Mathematical proofs are solely about communicating
> understanding and are not required to execute on a machine.
>
> On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote:
>> That's very true.  But programming is one where mathematical precision
>> is needed, even if you want to call it something else.
>>
>> On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore <[hidden email]> wrote:
>> >
>> > Mathematical precision isn't appropriate in all disciplines.
>> >
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
1234567 ... 12