Comments from OCaml Hacker Brian Hurt

classic Classic list List threaded Threaded
237 messages Options
1 ... 89101112
Reply | Threaded
Open this post in threaded view
|

Re: Functors [Comments from OCaml Hacker Brian Hurt]

David Leimbach


On Sun, Jan 18, 2009 at 3:23 AM, Andrew Coppin <[hidden email]> wrote:
Jonathan Cast wrote:
On Sat, 2009-01-17 at 12:04 +0000, Andrew Coppin wrote:
 

instance (Monad m) => Functor m where
 fmap f ma = do a <- ma; return (f a)
       
While that's quite interesting from a mathematical point of view, how is this "useful" for programming purposes?
   

Good Lord.  fmap (as above) is *at least* useful enough to be in the
standard library!  (Control.Monad.liftM).

Given that liftM exists, why is having an identical implementation for fmap useful?

Because liftM works on Monads and fmap works on Functors?

I believe you can make data that are Functors but are not Monads.
 


The example that leaps out at me is that (>>=) is identical to concatMap within the list monad. But using lists as a monad is a generally useful thing to do, and being able to substitute arbitrary monads has obvious utility. I'm not seeing how being able to treat something that isn't a container as if it was a container is useful.


_______________________________________________
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: Improved documentation for Bool (Was: Comments from OCaml Hacker Brian Hurt)

sclv
In reply to this post by Benja Fallenstein
This is a great effort, but the root of the problem isn't just poor  
documentation, but an insistence on some obscure name. How about  
renaming Bool to YesOrNoDataVariable? I think this would help novice  
programmers a great deal.

It would also make the documentation flow much more naturally:

The Bool type is the coproduct of the terminal object with itself.

--huh?

The YesOrNoDataVariable is the coproduct of the terminal object with  
itself.

--Oh! Of course!

--S

On Jan 18, 2009, at 12:17 PM, Benja Fallenstein wrote:

> On Sun, Jan 18, 2009 at 5:48 PM,  <[hidden email]> wrote:
>> I noticed the Bool datatype isn't well documented.  Since Bool is  
>> not a
>> common English word, I figured it could use some haddock to help  
>> clarify it
>> for newcomers.
>>
>> -- |The Bool datatype is named after George Boole (1815-1864).
>> -- The Bool type is the coproduct of the terminal object with itself.
>
> Russell, this does seem like it might be very helpful, but it might be
> useful to include a note about what category you are working in.
> People may sometimes naively assume that one is working in the
> category of Haskell/Hugs/GHC data types and Haskell functions, in
> which there are no terminal -- or initial -- objects ('undefined' and
> 'const undefined' are distinct maps between any two objects X and Y),
> or else in the similar category without lifted bottoms, in which the
> empty type is terminal and the unit type isn't ('undefined' and 'const
> ()' are both maps from any object X to the unit type). These niceties
> will not confuse the advanced reader, but it may help the beginner if
> you are more explicit.
>
> - Benja
>
>
> P.S. :-)
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

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

Re: Functors [Comments from OCaml Hacker Brian Hurt]

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Andrew Coppin
On Sun, 2009-01-18 at 11:23 +0000, Andrew Coppin wrote:

> Jonathan Cast wrote:
> > On Sat, 2009-01-17 at 12:04 +0000, Andrew Coppin wrote:
> >  
> >>
> >>> instance (Monad m) => Functor m where
> >>>   fmap f ma = do a <- ma; return (f a)
> >>>  
> >>>      
> >> While that's quite interesting from a mathematical point of view, how is
> >> this "useful" for programming purposes?
> >>    
> >
> > Good Lord.  fmap (as above) is *at least* useful enough to be in the
> > standard library!  (Control.Monad.liftM).
>
> Given that liftM exists, why is having an identical implementation for
> fmap useful?

What?

jcc


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

Re: Re: Functors [Comments from OCaml Hacker Brian Hurt]

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Andrew Coppin
On Sun, 2009-01-18 at 11:11 +0000, Andrew Coppin wrote:

> Heinrich Apfelmus wrote:
> > Andrew Coppin wrote:
> >  
> >>> instance (Monad m) => Functor m where
> >>>   fmap f ma = do a <- ma; return (f a)
> >>>  
> >>>      
> >> While that's quite interesting from a mathematical point of view, how is
> >> this "useful" for programming purposes?
> >>    
> >
> > Surely, you agree that  liftM  is "useful"? Because that's the same thing.
> >  
>
> Then why not just use liftM? (That way, you know what it does...)

I'd be willing to say *you* don't `know what it does', if you haven't
figured out that it's an acceptable implementation of fmap first.

jcc


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

Re: Improved documentation for Bool (Was: Comments from OCaml Hacker Brian Hurt)

Heinrich Apfelmus
In reply to this post by sclv
Sterling Clover wrote:

> This is a great effort, but the root of the problem isn't just poor
> documentation, but an insistence on some obscure name. How about
> renaming Bool to YesOrNoDataVariable? I think this would help novice
> programmers a great deal.
>
> It would also make the documentation flow much more naturally:
>
> The Bool type is the coproduct of the terminal object with itself.
>
> --huh?
>
> The YesOrNoDataVariable is the coproduct of the terminal object with
> itself.
>
> --Oh! Of course!

I'm sorry, but I don't get neither Bool nor YesOrNoDataVariable, it's
too confusing for newcomers. Can we please name it to

  TerminalObjectCoSquared

that's much more intuitive.


Also, the wikipedia page

  http://en.wikipedia.org/wiki/YesOrNoDataVariable

is extremely unhelpful. Not that the wikipedia page for Bool which links to

  http://en.wikipedia.org/wiki/Boolean_datatype

is any better. The introduction goes to great lengths to note that

  For instance the ISO SQL:1999 standard defined a Boolean data type
  for SQL which could hold three possible values: true, false, unknown
  (SQL null is treated as equivalent to the unknown truth value, but
  only for the Boolean data type)

What is SQL, do they mean the SesQuiLinear forms that I'm familiar with?
But what does it have to do with TerminalObjectCoSquared? I'm confused.


Regards,
apfelmus

--
http://apfelmus.nfshost.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

Don Stewart-2
In reply to this post by Ross Paterson
ross:

> On Sat, Jan 17, 2009 at 09:12:32PM -0500, [hidden email] 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 [hidden email]
> (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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Improved documentation for Bool (Was: Comments from OCaml Hacker Brian Hurt)

Nathan Bloomfield
In reply to this post by sclv
That's a great start, but "coproduct" is still pretty scary. Why not refer to it as OneOrTheOtherButNotBothDataConstructor?

-Nathan Bloomfield

On Sun, Jan 18, 2009 at 11:32 AM, Sterling Clover <[hidden email]> wrote:
This is a great effort, but the root of the problem isn't just poor documentation, but an insistence on some obscure name. How about renaming Bool to YesOrNoDataVariable? I think this would help novice programmers a great deal.

It would also make the documentation flow much more naturally:


The Bool type is the coproduct of the terminal object with itself.

--huh?

The YesOrNoDataVariable is the coproduct of the terminal object with itself.

--Oh! Of course!

--S


On Jan 18, 2009, at 12:17 PM, Benja Fallenstein wrote:

On Sun, Jan 18, 2009 at 5:48 PM,  <[hidden email]> wrote:
I noticed the Bool datatype isn't well documented.  Since Bool is not a
common English word, I figured it could use some haddock to help clarify it
for newcomers.

-- |The Bool datatype is named after George Boole (1815-1864).
-- The Bool type is the coproduct of the terminal object with itself.

Russell, this does seem like it might be very helpful, but it might be
useful to include a note about what category you are working in.
People may sometimes naively assume that one is working in the
category of Haskell/Hugs/GHC data types and Haskell functions, in
which there are no terminal -- or initial -- objects ('undefined' and
'const undefined' are distinct maps between any two objects X and Y),
or else in the similar category without lifted bottoms, in which the
empty type is terminal and the unit type isn't ('undefined' and 'const
()' are both maps from any object X to the unit type). These niceties
will not confuse the advanced reader, but it may help the beginner if
you are more explicit.

- Benja


P.S. :-)
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
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: Improved documentation for Bool (Was: Comments from OCaml Hacker Brian Hurt)

Derek Elkins
In reply to this post by Benja Fallenstein
On Sun, 2009-01-18 at 18:17 +0100, Benja Fallenstein wrote:

> On Sun, Jan 18, 2009 at 5:48 PM,  <[hidden email]> wrote:
> > I noticed the Bool datatype isn't well documented.  Since Bool is not a
> > common English word, I figured it could use some haddock to help clarify it
> > for newcomers.
> >
> > -- |The Bool datatype is named after George Boole (1815-1864).
> > -- The Bool type is the coproduct of the terminal object with itself.
>
> Russell, this does seem like it might be very helpful, but it might be
> useful to include a note about what category you are working in.
> People may sometimes naively assume that one is working in the
> category of Haskell/Hugs/GHC data types and Haskell functions, in
> which there are no terminal -- or initial -- objects

The naive way of making a "Haskell" category doesn't even work.  Taking
objects to be Haskell types, all Haskell functions as arrows, arrow
equality being observational equality, and (.) and id to be the
composition and identity, you fail to even have a category.  Proof of
this is left as an (easy) exercise for the reader.

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

Re: Functors [Comments from OCaml Hacker Brian Hurt]

Louis Wasserman
In reply to this post by Andrew Coppin
The point of concepts like functors, monoids, and monads is not because they provide functionality that wouldn't normally be accessible, but for the following reasons:

1.  The concept encapsulates a huge number of common programming idioms.  Indicating that a concept fits the functor, monad, or monoid paradigm provides the advantages that
a) significant repeated code can be scrapped in favor of general library code.  Writing "mconcat" is much nicer than writing "foldr (++) []", though perhaps lists aren't the best example (due to the presence of just plain "concat").
b) Using fully general, well-known (within the Haskell community) abstractions provides other programmers with easily read hints about the behavior of your code, such as the indication that a Foo can be composed with another Foo in an associative fashion, so parentheses are irrelevant.  (So foldl mappend mzero ls is equivalent to foldr mappend mzero ls, but the latter fuses more powerfully without stream fusion.)
2. Very abstract, very general typeclasses in libraries come with very general combinators and functions in libraries, with the bonus that GHC's optimizer is almost always capable of optimizing code using these general structures into code just as, or very nearly as, good as equivalent code that would take you hours to write and would considerably obfuscate the programmer's actual intention.
3. Writing code in a very general, abstract fashion can considerably improve the developer's thinking about the program.  As an example, this weekend I was playing with (very, very custom-tuned) monads to fill up the contents of an array in several different fashions, and taught myself monad transformers as a very elegant way to encapsulate a shared, universal array, a mutable index state, and successive (associative and commutative) operations on a State; this went through several permutations (and is still in progress).

As an additional observation, using the Sum, Product, Any, and other similar monoids, when done appropriately and mconcat'd, gives no actual overhead due to standard optimizations (in particular, each of them is a newtype).  That's to say that I'm almost positive that mconcat (map Product ls) is equivalent to foldMap


Louis Wasserman
[hidden email]


On Sat, Jan 17, 2009 at 10:46 AM, <[hidden email]> wrote:
Send Haskell-Cafe mailing list submissions to
       [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
       http://www.haskell.org/mailman/listinfo/haskell-cafe
or, via email, send a message with subject or body 'help' to
       [hidden email]

You can reach the person managing the list at
       [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Haskell-Cafe digest..."


Today's Topics:

  1. Re: Comments from OCaml Hacker Brian Hurt (david48)
  2. Re: Re: Comments from OCaml Hacker Brian Hurt (david48)
  3. Re: Comments from OCaml Hacker Brian Hurt (Andrew Coppin)
  4. Re: some ideas for Haskell', from Python (Artyom Shalkhakov)
  5. Re: Comments from OCaml Hacker Brian Hurt (Andrew Coppin)
  6. Re: Re: Comments from OCaml Hacker Brian Hurt (Eugene Kirpichov)
  7. Re: Comments from OCaml Hacker Brian Hurt (Eugene Kirpichov)
  8. Functors [Comments from OCaml Hacker Brian Hurt] (Andrew Coppin)
  9. Re: Functors [Comments from OCaml Hacker Brian Hurt]
     (Eugene Kirpichov)
 10. Re: Functors [Comments from OCaml Hacker Brian Hurt] (Luke Palmer)
 11. Re[2]: [Haskell-cafe] Functors [Comments from OCaml Hacker
     Brian Hurt] (Bulat Ziganshin)
 12. Re: Re[2]: [Haskell-cafe] Comments from OCaml Hacker Brian
     Hurt (David Leimbach)
 13. OS X build failure of Gtk2Hs from MacPorts (Jeff Heard)
 14. Re: Comments from OCaml Hacker Brian Hurt (Lennart Augustsson)
 15. Re: Comments from OCaml Hacker Brian Hurt (David Leimbach)
 16. Re: ANN: HTTPbis / HTTP-4000.x package available (Tim Newsham)
 17. Efficient Factoring Out of Constants (Phil)
 18. Re: Efficient Factoring Out of Constants (Luke Palmer)


----------------------------------------------------------------------

Message: 1
Date: Sat, 17 Jan 2009 10:47:56 +0100
From: david48 <[hidden email]>
Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
To: "Jonathan Cast" <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast
<[hidden email]> 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 (<get a value>) i+= <count of something in value>
>
> 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) ?


------------------------------

Message: 2
Date: Sat, 17 Jan 2009 11:08:25 +0100
From: david48 <[hidden email]>
Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
To: "Apfelmus, Heinrich" <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 16, 2009 at 10:28 PM, Apfelmus, Heinrich
<[hidden email]> wrote:

> david48 wrote:

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

> Good account of the current documentation situation.

> Hm, what about the option of opening Bird's "Introduction on Functional
> Programming using Haskell" in the section about fold? Monoid is on page
> 62 in the translated copy I've got here.

I don't have this book. I have real world haskell and purely
functional data structures though.

> Does Hutton's book mention them? Real World Haskell?

the first time it is mentionned in RWH according to the index is page
266 where we read
"We forgot to test the Monoid instance"
...
"...of Monoid, which is the class of types that support appending and
empty elements:"

Appending.... :)

On the other hand, on page 320 there is a nice explanation of Monoid,
and on page 380, which isn't mentionned in the index, there might be
the first time one can understand why the writer monad works with
monoids instead of lists: to be able to use better suited data types
for appending.

All of this is still lacking the great why : why/how an abstraction so
generic can be useful.
I'm starting to believe that the only reason to make a datatype an
instance of Monoid is... why not ! since it's not hard to find an
associative operation and a neutral element.

> I don't think that I would try to learn a programming language, for
> example Python, without obtaining a paper book on it.

I would, if the online documentation makes it possible, and then I
would buy a paper book later, to go further or for reference.
That's how I learned Haskell, and much later I've bought my first book.


------------------------------

Message: 3
Date: Sat, 17 Jan 2009 11:07:03 +0000
From: Andrew Coppin <[hidden email]>
Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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



------------------------------

Message: 4
Date: Sat, 17 Jan 2009 17:12:14 +0600
From: Artyom Shalkhakov <[hidden email]>
Subject: Re: [Haskell-cafe] some ideas for Haskell', from Python
To: Immanuel Litzroth <[hidden email]>,
       [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=UTF-8

Hello,

2009/1/16 Immanuel Litzroth <[hidden email]>:
> I don't understand your comment.
> 1) If XMonad already uses it the problem is solved, without giving Haskell
> import new semantics?

Right, but there are some restrictions.

> 2) These guys refer to a method to do plugin work in Haskell
> http://www.cse.unsw.edu.au/~dons/hs-plugins/
> So the problem of dynamically loading plugins should already be solved?

Well, mostly yes, but I think that it should be added to the language.

Cheers,
Artyom Shalkhakov.


------------------------------

Message: 5
Date: Sat, 17 Jan 2009 11:17:12 +0000
From: Andrew Coppin <[hidden email]>
Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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!



------------------------------

Message: 6
Date: Sat, 17 Jan 2009 14:27:02 +0300
From: "Eugene Kirpichov" <[hidden email]>
Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
To: david48 <[hidden email]>
Cc: "Apfelmus, Heinrich" <[hidden email]>,
       [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

The great "that's why" is as follows: when you have an abstraction,
then it is sufficient to hold the abstraction in mind instead of the
whole concrete implementation. That's the whole purpose of
abstraction, after all, be it maths or programming.

Let me illustrate this.

Suppose you are developing a library that, for instance, has a notion
of "settings" and is able to combine two "settings" with several
strategies for resolving conflicts between settings with duplicate
keys: take the first setting, the second, none, or make a setting with
multiple values. For example, an alternative GetOpt.

Suppose you don't know what a monoid is and don't even know that such
an abstraction exists.
Now, when you're reasoning about the library, you have to think "If I
combine 3 settings, should the order of combination matter? Hmm, would
be nice if it didn't. Also, what should I return if someone queries
for a non-existent key in the settings? Should I return an empty list,
or a Nothing, or throw an error, or what? Do empty settings make
sense?" etc. If you're smart and lucky, you will most probably get
most things right and inconsciously create a settings monoid.

Now, if you know what a monoid is, you immediately recognize that your
settings should be a monoid by nature, and now you have absolutely no
doubt that you should make the combining operation associative and
provide a unit; and you use this monoid abstraction all the time you
are designing this library. Now, you don't think about whether you
should throw an error or return a Nothing for an empty key; but
instead you think about which result would behave like a unit for the
monoid, being motivated by mathematical principles rather than pure
intuition.

You end up designing a mathematically sound library whose principles
make sence and has no design flaws, at least in the mathematically
sound part, even if you never actually use the word "monoid" in the
documentation.

Also, read this post by sigfpe that motivated me to learn abstract
algebra in depth (I am yet in the beginning, however), and, overall,
this is a breathtaking post:
http://sigfpe.blogspot.com/2008/11/approach-to-algorithm-parallelisation.html
- this is where I started to appreciate the power of mathematical
abstractions even more.

2009/1/17 david48 <[hidden email]>:
> All of this is still lacking the great why : why/how an abstraction so
> generic can be useful.
> I'm starting to believe that the only reason to make a datatype an
> instance of Monoid is... why not ! since it's not hard to find an
> associative operation and a neutral element.
>

--
Eugene Kirpichov


------------------------------

Message: 7
Date: Sat, 17 Jan 2009 14:34:25 +0300
From: "Eugene Kirpichov" <[hidden email]>
Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
To: "Andrew Coppin" <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

2009/1/17 Andrew Coppin <[hidden email]>:
> 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


------------------------------

Message: 8
Date: Sat, 17 Jan 2009 12:04:01 +0000
From: Andrew Coppin <[hidden email]>
Subject: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian
       Hurt]
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Eugene Kirpichov wrote:
> 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.
>

As far as I'm aware, constraints like "while preserving the underlying
structure" are not expressible in Haskell.

> instance (Monad m) => Functor m where
>   fmap f ma = do a <- ma; return (f a)
>

While that's quite interesting from a mathematical point of view, how is
this "useful" for programming purposes?



------------------------------

Message: 9
Date: Sat, 17 Jan 2009 15:12:26 +0300
From: "Eugene Kirpichov" <[hidden email]>
Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian
       Hurt]
To: "Andrew Coppin" <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

2009/1/17 Andrew Coppin <[hidden email]>:
> Eugene Kirpichov wrote:
>>
>> 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.
>>
>
> As far as I'm aware, constraints like "while preserving the underlying
> structure" are not expressible in Haskell.

Yes, but they are expressible in your mind so that you can recognize a
functor and design you program so that it does satisfy this
constraint, thus removing a large faulty piece of the design space.

Also, you can write a QuickCheck test for fmap (f . g) = fmap f . fmap
g and fmap id = id.

>
>> instance (Monad m) => Functor m where
>>  fmap f ma = do a <- ma; return (f a)
>>
>
> While that's quite interesting from a mathematical point of view, how is
> this "useful" for programming purposes?

In the same sense as monoids are, see my previous message.

If you mean the usefulness of a Functor typeclass in Haskell, it's in
the fact that everywhere where you'd like to convert a structure over
X to a structure over Y (for example, the result of a monadic
computation), you simply write 'fmap f structure' and it works the
right way, if the structure has an instance for Functor (many
structures do). I know I'm being a bit abstract, but that's the way I
percept it.

do filename <- toLowerCase `fmap` readLine
   ....

>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>


------------------------------

Message: 10
Date: Sat, 17 Jan 2009 05:16:06 -0700
From: Luke Palmer <[hidden email]>
Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian
       Hurt]
To: Andrew Coppin <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

On Sat, Jan 17, 2009 at 5:04 AM, Andrew Coppin
<[hidden email]>wrote:

> Eugene Kirpichov wrote:
>
>> 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.
>>
>>
>
> As far as I'm aware, constraints like "while preserving the underlying
> structure" are not expressible in Haskell.


Well, they're expressible *about* Haskell.  I.e., for functors we require:

 fmap id = id
 fmap (f . g) = fmap f . fmap g

 The first property is how we write "preserving underlying structure", but
this has a precise, well-defined meaning that we can say a given functor
obeys or it does not (and if it does not, we say that it's a bad instance).
But you are correct that Haskell does not allow us to require proofs of such
properties.

And indeed, some people break those properties in various ways, which some
consider okay if the breakage is not observable from outside a given
abstraction barrier.  I'm on the fence about that...

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090117/b07c6f56/attachment-0001.htm

------------------------------

Message: 11
Date: Sat, 17 Jan 2009 16:28:05 +0300
From: Bulat Ziganshin <[hidden email]>
Subject: Re[2]: [Haskell-cafe] Functors [Comments from OCaml Hacker
       Brian Hurt]
To: Luke Palmer <[hidden email]>
Cc: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=iso-8859-1

Hello Luke,

Saturday, January 17, 2009, 3:16:06 PM, you wrote:

>   fmap id = id
>   fmap (f . g) = fmap f . fmap g

>  The first property is how we write "preserving underlying
> structure", but this has a precise, well-defined meaning that we can
> say a given functor obeys or it does not (and if it does not, we say
> that it's a bad instance).  But you are correct that Haskell does
> not allow us to require proofs of such properties.

not haskell itself, but QuickCheck allows. we may even consider
lifting these properties to the language level

--
Best regards,
 Bulat                            mailto:[hidden email]



------------------------------

Message: 12
Date: Sat, 17 Jan 2009 07:08:33 -0800
From: David Leimbach <[hidden email]>
Subject: Re: Re[2]: [Haskell-cafe] Comments from OCaml Hacker Brian
       Hurt
To: david48 <[hidden email]>
Cc: Bulat Ziganshin <[hidden email]>,
       [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

On Sat, Jan 17, 2009 at 1:41 AM, david48
<[hidden email]<[hidden email]>
> wrote:

> On Fri, Jan 16, 2009 at 3:10 PM, Bulat Ziganshin
> <[hidden email]> wrote:
> > Hello david48,
> >
> > Friday, January 16, 2009, 4:16:51 PM, you wrote:
> >
> >> Upon reading this thread, I asked myself : what's a monoid ? I had no
> >> idea. I read some posts, then google "haskell monoid".
> >
> > it would be interesting to google "C++ class" or "Lisp function" and
> > compare experience :)
>
> The first link for C++ class I find on google is the wikipedia article
> which I find understandable, has examples and explanations that relate
> to programming.
> OTOH, the wikipedia article for monoid is less easy (for me), though
> now I can follow the first paragraphs. But I don't find on the page
> how/why/where it relates to programming.


So you're saying it should be better documented in Haskell what a Monoid is.
 Did you say you searched for "C++ class" why not "Haskell Monoid" then?
 The first correct google hit that didn't think I meant Monads, takes you
straight to the GHC documentation for Data.Monoid.





>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090117/44862fd0/attachment-0001.htm

------------------------------

Message: 13
Date: Sat, 17 Jan 2009 10:18:10 -0500
From: "Jeff Heard" <[hidden email]>
Subject: [Haskell-cafe] OS X build failure of Gtk2Hs from MacPorts
To: [hidden email], "Haskell Cafe"
       <[hidden email]>
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

/opt/local/bin/ghc +RTS -RTS -c tools/hierarchyGen/TypeGen.hs -o
tools/hierarchyGen/TypeGen.o -O -itools/hierarchyGen -package-conf
package.conf.inplace -hide-all-packages -package base
package.conf.inplace: openBinaryFile: does not exist (No such file or directory)
/opt/local/bin/ghc +RTS -RTS -c tools/callbackGen/HookGenerator.hs -o
tools/callbackGen/HookGenerator.o -O -I. -itools/callbackGen
-package-conf package.conf.inplace -hide-all-packages -package base
package.conf.inplace: openBinaryFile: does not exist (No such file or directory)
rm -rf glib/System/Glib.o glib/System/Glib_split/; mkdir -p
glib/System/Glib_split
/opt/local/bin/ghc +RTS -RTS -split-objs -c glib/System/Glib.hs -o
glib/System/Glib.o -O -fffi -iglib -package-conf package.conf.inplace
-hide-all-packages -ignore-package glib -package base -package-name
glib-0.9.13 '-#include<glib-object.h>' -I/opt/local/include/glib-2.0
-I/opt/local/lib/glib-2.0/include -I/opt/local/include

on the commandline:
   Warning: -fffi is deprecated: use -XForeignFunctionInterface or
pragma {-# LANGUAGE ForeignFunctionInterface#-} instead
package.conf.inplace: openBinaryFile: does not exist (No such file or directory)
make[1]: *** [glib/System/Glib.o] Error 1
make: *** [all] Error 2


------------------------------

Message: 14
Date: Sat, 17 Jan 2009 15:33:07 +0000
From: "Lennart Augustsson" <[hidden email]>
Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
To: "Andrew Coppin" <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

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
<[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>


------------------------------

Message: 15
Date: Sat, 17 Jan 2009 07:37:30 -0800
From: David Leimbach <[hidden email]>
Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
To: Lennart Augustsson <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

On Sat, Jan 17, 2009 at 7:33 AM, Lennart Augustsson
<[hidden email]>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
> <[hidden email]> 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
> > [hidden email]
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090117/e8634f33/attachment-0001.htm

------------------------------

Message: 16
Date: Sat, 17 Jan 2009 06:21:36 -1000 (HST)
From: Tim Newsham <[hidden email]>
Subject: Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package
       available
To: Henning Thielemann <[hidden email]>
Cc: Haskell Cafe <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

> There's however still no framework which supports both HTTP client and
> server functions using the same Request and Response data type, right? I
> don't know whether I am the only one who needs this (e.g. for the Real
> Monad Transformer). E.g. a proxy would need this, too.

I've wanted this for a while now.  "Me Too."

Tim Newsham
http://www.thenewsh.com/~newsham/


------------------------------

Message: 17
Date: Sat, 17 Jan 2009 16:46:12 +0000
From: Phil <[hidden email]>
Subject: [Haskell-cafe] Efficient Factoring Out of Constants
To: Luke Palmer <[hidden email]>,   "[hidden email]"
       <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I¹ve been thinking about factoring constants out of iterations and have
spotted another place in my code where I can make use of this.

See the two examples below ­ the first example iterates over the mcSimulate
function ­ this has changed a little bit but essentially still recurses
around passing in
two constants, and two variables that are changed each time it is called ­
it has the following form:

mcSimulate (startStock, endTime, seedForSeed, runningSum) = ( startStock,
endTime, newSeedForSeed, newRunningSum )

I figured I¹m passing around the constants startStock and endTime so looked
factor these out producing the second example below.

My concern is that although iterate function now only handles two variables,
it¹s still passing around 1 tuple, which under the bonnet is likely to be
represented in machine code as a pointer?  Humor me here a little ­ I know
I¹m thinking of this in terms of C++, but I¹m guessing the final byte code
will adhere to this:

Thus each time mcSimulate is called  a machine code subroutine will be
passed a memory address to the input data.  Now, the crux of this is, will
it make a COPY of the old input data, BUT with the newSeedForSeed and
newRunningSum, to pass to the next iteration?  If this is the case each
iteration does two useless copies of startStock and endTime?  Here the
second example should produce better code because nothing constant is copied
from 1 iteration to the next.  However if the compiler is smarter and simply
REPLACES the modified data the second example buys us nothing.

However, again, depending very much on the compiler, the second example may
actually be less efficient.  Let¹s say the compiler is super smart and
doesn¹t copy around the startStock and endTime on each iteration in the
first example.  Then we¹ve gained nothing.  However the second example Will
call 3 functions each iteration:

mcWrapper -> mcSimulate -> getStateInfo

In the second example we probably have something like 6 ŒJMP¹ statements in
machine code ­ 3 to jump in to each function, and 3 to jump back out.  In
the first we have 2 ­ one to jump us into mcSimulate and one to return.  So
each iteration executes 4 more JMPs in the second example.  All others
things being equal this will produce slightly less efficient code.

Now I know I¹m speculating like crazy, and perhaps I¹m drunk with efficiency
here, but it would seem to me that whatever way it works there will be a
certain critical mass of constant data that you can carry around that once
breached (i.e. When the copy operations exceed the CPU time taken for the 4
extra JMPs) you will be better off factoring the constant data out..... That
is assuming any of my analysis is correct :-)

If anyone has any insight into how this might looked once compiled down to
machine code, or has an opinion one which example below makes for better
Haskell, I¹d be grateful for any comments, advice or discussion.

Cheers,

Phil.

Note:  I recognize the use of getSum and getStateInfo could be polished
using data structures instead, and the use of !! will not produce strict
evaluation.
-------------

getSum :: (Double, Double, Word64, Double) -> Double
getSum (startStock, endTime, seedForSeed, runningSum) = runningSum

getAveragePayoff :: Double -> Double -> Int -> Word64 -> Double
getAveragePayoff startStock endTime iterations seedForSeed = average
 where
   average = (getSum $ (iterate mcSimulate (startStock, endTime,
seedForSeed, 0)) !! iterations ) / fromIntegral iterations

---------------

getStateInfo :: (Double, Double, Word64, Double) -> (Word64,Double)
getStateInfo (startStock, endTime, seedForSeed, runningSum) = (seedForSeed,
runningSum)

getAveragePayoff :: Double -> Double -> Int -> Word64 -> Double
getAveragePayoff startStock endTime iterations seedForSeed = average
 where
   average =  (snd $ (iterate mcWrapper (seedForSeed,0)) !! iterations ) /
fromIntegral iterations
     where
       mcWrapper = \(seed,runningSum) -> getStateInfo $ mcSimulate (
startStock, endTime, seed, runningSum )


On 16/01/2009 01:41, "Phil" <[hidden email]> wrote:

>
> On 16/01/2009 01:28, "Luke Palmer" <[hidden email]> wrote:
>
>>> Compile-time constants could be handled by simple top-level bindings.  This
>>> technique is specifically for the case you are after:
>>>
>>> mcSimulate :: Double -> Double -> Word64 -> [Double]
>>> mcSimulate startStock endTime seedForSeed = go seedForSeed
>>>   where
>>>     go = fst expiryStock : go newSeedForSeed
>>>       where
>>>       expiryStock = iterate evolveUnderlying (startStock, ranq1Init
>>> seedForSeed)
>>>                         !! truncate (endTime/timeStep)
>>>       newSeedForSeed = seedForSeed + 246524
>>>
>>> See what's going on there?
>>>
>>> I don't know about that nested where.  In Real Life I would probably use a
>>> let instead for expiryStock and newSeedForSeed.
>>>
>>> Luke
>>>
>>> Ahh, I get it now, that¹s pretty neat - Œgo¹ is only updating the
>>> seedForSeed and the expiryStock, the inner Œwhere¹ clause keeps everything
>>> else constant each time it is called.
>
> Thanks again!
>
> Phil.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090117/0b7a57ea/attachment-0001.htm

------------------------------

Message: 18
Date: Sat, 17 Jan 2009 09:55:27 -0700
From: Luke Palmer <[hidden email]>
Subject: [Haskell-cafe] Re: Efficient Factoring Out of Constants
To: [hidden email]
Cc: "[hidden email]" <[hidden email]>
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset="windows-1252"

On Sat, Jan 17, 2009 at 9:46 AM, Phil <[hidden email]> wrote:

>  In the second example we probably have something like 6 'JMP' statements
> in machine code – 3 to jump in to each function, and 3 to jump back out.  In
> the first we have 2 – one to jump us into mcSimulate and one to return.  So
> each iteration executes 4 more JMPs in the second example.  All others
> things being equal this will produce slightly less efficient code.
>

Wow.  I strongly suggest you forget about efficiency completely and become a
proficient high-level haskeller, and then dive back in.  Laziness changes
many runtime properties, and renders your old ways of thinking about
efficiency almost useless.

If you are interested, though, you can use the ghc-core tool on hackage to
look at the core (lowish-level intermediate language) and even the generated
assembly for minimal cases.  It's dense, but interesting if you have the
time to study it.

Others will know more about this specific speculation than I.

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090117/798c4336/attachment.htm

------------------------------

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


End of Haskell-Cafe Digest, Vol 65, Issue 48
********************************************


_______________________________________________
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 Waern-2
In reply to this post by Don Stewart-2
2009/1/18 Don Stewart <[hidden email]>:

> ross:
>> On Sat, Jan 17, 2009 at 09:12:32PM -0500, [hidden email] 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 [hidden email]
>> (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
[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

Don Stewart-2
david.waern:

> 2009/1/18 Don Stewart <[hidden email]>:
> > ross:
> >> On Sat, Jan 17, 2009 at 09:12:32PM -0500, [hidden email] 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 [hidden email]
> >> (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
[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

Heinrich Apfelmus
In reply to this post by David Virebayre
david48 wrote:

> Apfelmus, Heinrich wrote:
>
>> Hm, what about the option of opening Bird's "Introduction on Functional
>> Programming using Haskell" in the section about fold? Monoid is on page
>> 62 in the translated copy I've got here.
>
>> I don't think that I would try to learn a programming language, for
>> example Python, without obtaining a paper book on it.
>
> I would, if the online documentation makes it possible, and then I
> would buy a paper book later, to go further or for reference.
> That's how I learned Haskell, and much later I've bought my first book.

Interesting, I wouldn't want to miss actual paper when learning
difficult topics. Also, some great resources like the contents of Bird's
book just aren't available online ;). I'd recommend to borrow it from a
library, though, the current amazon price is quite outrageous.


Regards,
apfelmus

--
http://apfelmus.nfshost.com

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

Re: Improved documentation for Bool

Andrew Coppin
In reply to this post by roconnor
[hidden email] wrote:
> I noticed the Bool datatype isn't well documented.  Since Bool is not
> a common English word, I figured it could use some haddock to help
> clarify it for newcomers.

My only problem with it is that it's called Bool, while every other
programming language on Earth calls it Boolean. (Or at least, the
languages that *have* a name for it...)

But I'm far more perturbed by names like Eq, Ord, Num, Ix (??), and so
on. The worst thing about C is the unecessary abbriviations; let's not
copy them, eh?

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

Re: Re: Improved documentation for Bool

Bugzilla from jonathanccast@fastmail.fm
On Mon, 2009-01-19 at 19:33 +0000, Andrew Coppin wrote:
> [hidden email] wrote:
> > I noticed the Bool datatype isn't well documented.  Since Bool is not
> > a common English word, I figured it could use some haddock to help
> > clarify it for newcomers.
>
> My only problem with it is that it's called Bool, while every other
> programming language on Earth calls it Boolean. (Or at least, the
> languages that *have* a name for it...)

Except C++?  But then again:

> But I'm far more perturbed by names like Eq, Ord, Num, Ix (??), and so
> on. The worst thing about C is the unecessary abbriviations; [sic] let's not
> copy them, eh?

I agree.  I've always felt that

class EqualsClass randomTypeSelectedByTheUser => TotalOrderClass
randomTypeSelectedByTheUser where
  compareXToY :: randomTypeSelectedByTheUser ->
randomTypeSelectedByTheUser -> OrderingValue
  lessThanOrEqualTo :: randomTypeSelectedByTheUser ->
randomTypeSelectedByTheUser -> Boolean
  lessThan :: randomTypeSelectedByTheUser -> randomTypeSelectedByTheUser
-> Boolean

was both more understandable to the reader, and easier to remember and
reproduce for the writer.

Or, in other words, leave well enough alone; we should always err in the
direction of being like C, to avoid erring in the direction of being
like Java.

jcc


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

Re: Re: Improved documentation for Bool

Dan Piponi-2
In reply to this post by Andrew Coppin
On Mon, Jan 19, 2009 at 11:33 AM, Andrew Coppin
<[hidden email]> wrote:

> My only problem with it is that it's called Bool, while every other
> programming language on Earth calls it Boolean. (Or at least, the languages
> that *have* a name for it...)

Python: bool
ocaml: bool
C++: bool
C99: bool
C#: bool

> But I'm far more perturbed by names like Eq, Ord, Num, Ix (??), and so on.
> The worst thing about C is the unecessary abbriviations; let's not copy
> them, eh?

They're short so they're quick to parse (for a human) and read.
They're easy to type. If you have a constraint like (Eq a,Num a,Ord
a,Show a,Ix a) you can see all five type classes at a single glance
without having to scan your eye across the line. They're highly
mnemonic in the sense that once I'd learnt what they meant it became
hard to forget them again. What exactly is wrong with them?
--
Dan
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Improved documentation for Bool

Andrew Coppin
Dan Piponi wrote:

> On Mon, Jan 19, 2009 at 11:33 AM, Andrew Coppin
> <[hidden email]> wrote:
>
>  
>> My only problem with it is that it's called Bool, while every other
>> programming language on Earth calls it Boolean. (Or at least, the languages
>> that *have* a name for it...)
>>    
>
> Python: bool
> ocaml: bool
> C++: bool
> C99: bool
> C#: bool
>  

Versus Java, Pascal, Smalltalk and Eiffel who all call it Boolean. Oh
well. At least it's pretty obvious what it means.

>> But I'm far more perturbed by names like Eq, Ord, Num, Ix (??), and so on.
>> The worst thing about C is the unecessary abbriviations; let's not copy
>> them, eh?
>>    
>
> They're short so they're quick to parse (for a human) and read.
> They're easy to type. If you have a constraint like (Eq a,Num a,Ord
> a,Show a,Ix a) you can see all five type classes at a single glance
> without having to scan your eye across the line. They're highly
> mnemonic in the sense that once I'd learnt what they meant it became
> hard to forget them again. What exactly is wrong with them?
>  

Would it really hurt to type a few more keystrokes and say "Equal"?
"Ordered"? "Index"? I don't think so.

Sure, we don't especially want to end up with classes like
StrictlyOrderedAssociativeSet or something, but a few more characters
wouldn't exactly kill you.

But, again, this is too difficult to change now, so we're stuck with it.

PS. Ord implies Eq, so you don't need both in the same constraint. Num
implies Show, so you don't need that either. So actually, (Ord a, Num a,
Ix a) - or rather, (Ordered a, Number a, Index a) - would do just fine.

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

Re: Re: Improved documentation for Bool

Bugzilla from jonathanccast@fastmail.fm
On Mon, 2009-01-19 at 20:55 +0000, Andrew Coppin wrote:

> Dan Piponi wrote:
> > On Mon, Jan 19, 2009 at 11:33 AM, Andrew Coppin
> > <[hidden email]> wrote:
> >
> >  
> >> My only problem with it is that it's called Bool, while every other
> >> programming language on Earth calls it Boolean. (Or at least, the languages
> >> that *have* a name for it...)
> >>    
> >
> > Python: bool
> > ocaml: bool
> > C++: bool
> > C99: bool
> > C#: bool
> >  
>
> Versus Java, Pascal,

Again, we don't want to imitate these two!

> Smalltalk and Eiffel who all call it Boolean. Oh
> well. At least it's pretty obvious what it means.

> >> But I'm far more perturbed by names like Eq, Ord, Num, Ix (??), and so on.
> >> The worst thing about C is the unecessary abbriviations; let's not copy
> >> them, eh?
> >>    
> >
> > They're short so they're quick to parse (for a human) and read.
> > They're easy to type. If you have a constraint like (Eq a,Num a,Ord
> > a,Show a,Ix a) you can see all five type classes at a single glance
> > without having to scan your eye across the line. They're highly
> > mnemonic in the sense that once I'd learnt what they meant it became
> > hard to forget them again. What exactly is wrong with them?
> >  
>
> Would it really hurt to type a few more keystrokes and say "Equal"?
> "Ordered"? "Index"? I don't think so.

Constantly?  Yeah.  Commonly used names should be short, or abbreviated.
You can't abbreviate type classes.

> Sure, we don't especially want to end up with classes like
> StrictlyOrderedAssociativeSet or something, but a few more characters
> wouldn't exactly kill you.
>
> But, again, this is too difficult to change now, so we're stuck with it.
>
> PS. Ord implies Eq, so you don't need both in the same constraint. Num
> implies Show, so you don't need that either. So actually, (Ord a, Num a,
> Ix a) - or rather, (Ordered a, Number a, Index a) - would do just fine.

newtype MyFoo = MyWrapsWhatever
  deriving (Eq, Ord, Read, Show, Num, Ix, Data, Typeable)

vs.

newtype MyFoo = MyWrapsWhatever
  deriving (Equality, Order, Read, Show, Number, Index, Data, Typeable)

Yeah.  Count me out.

jcc


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

Re: Re: Improved documentation for Bool

ajb@spamcop.net
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
G'day all.

On Mon, 2009-01-19 at 19:33 +0000, Andrew Coppin wrote:

>> My only problem with it is that it's called Bool, while every other
>> programming language on Earth calls it Boolean. (Or at least, the
>> languages that *have* a name for it...)

Jonathan Cast commented:

> Except C++?

And perhaps more to the point, "Boolean" is an adjective, not a noun.
Therefore, it would be better reserved for a typeclass.

class (PartialOrder a) => JoinSemilattice a where
     (||) :: a -> a -> a

class (MeetSemilattice a) => BoundedJoinSemilattice a where
     bottom :: a

class (PartialOrder a) => MeetSemilattice a where
     (&&) :: a -> a -> a

class (MeetSemilattice a) => BoundedMeetSemilattice a where
     top :: a

class (BoundedJoinSemilattice a, BoundedMeetSemilattice a) => Heyting a where
     implies :: a -> a -> a

     not :: a -> a
     not x = x `implies` bottom

class (Heyting a) => Boolean a where
     {- the additional axiom that x || not x == top -}

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

Re: Re: Improved documentation for Bool

David Menendez-2
On Mon, Jan 19, 2009 at 7:22 PM,  <[hidden email]> wrote:
>
> And perhaps more to the point, "Boolean" is an adjective, not a noun.
> Therefore, it would be better reserved for a typeclass.

There's also John Meacham's Boolean package.

<http://repetae.net/recent/out/Boolean.html>

> class (Heyting a) => Boolean a where
>    {- the additional axiom that x || not x == top -}

Are there any instances of Boolean that aren't isomorphic to Bool?

(I'm assuming that (||) and (&&) are intended to be idempotent,
commutative, and associative.)

--
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: Re: Improved documentation for Bool

Dan Piponi-2
On Mon, Jan 19, 2009 at 6:25 PM, David Menendez <[hidden email]> wrote:

> Are there any instances of Boolean that aren't isomorphic to Bool?

a->Bool for any a. I think.

Though I think it should be called GeorgeBoolean otherwise we might
confuse it for something his father might have invented.
--
Dan
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
1 ... 89101112