[Haskell-cafe] Re: Functors [Comments from OCaml Hacker Brian Hurt]
Louis Wasserman
wasserman.louis at gmail.com
Sun Jan 18 15:54:00 EST 2009
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
wasserman.louis at gmail.com
On Sat, Jan 17, 2009 at 10:46 AM, <haskell-cafe-request at haskell.org> wrote:
> Send Haskell-Cafe mailing list submissions to
> haskell-cafe at haskell.org
>
> 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
> haskell-cafe-request at haskell.org
>
> You can reach the person managing the list at
> haskell-cafe-owner at haskell.org
>
> 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 <dav.vire+haskell at gmail.com <dav.vire%2Bhaskell at gmail.com>>
> Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
> To: "Jonathan Cast" <jonathanccast at fastmail.fm>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> <4c88418c0901170147u3e0a3d65r2ab72d9bbc8cb1e6 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast
> <jonathanccast at fastmail.fm> wrote:
>
> > On Fri, 2009-01-16 at 14:16 +0100, david48 wrote:
> >> Part of the problem is that something like a monoid is so general that
> >> I can't wrap my head around why going so far in the abstraction.
> >> For example, the writer 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 <dav.vire+haskell at gmail.com <dav.vire%2Bhaskell at gmail.com>>
> Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
> To: "Apfelmus, Heinrich" <apfelmus at quantentunnel.de>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> <4c88418c0901170208i74358328ycaa10359fb639873 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jan 16, 2009 at 10:28 PM, Apfelmus, Heinrich
> <apfelmus at quantentunnel.de> 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 <andrewcoppin at btinternet.com>
> Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
> To: haskell-cafe at haskell.org
> Message-ID: <4971BBD7.504 at btinternet.com>
> 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 <artyom.shalkhakov at gmail.com>
> Subject: Re: [Haskell-cafe] some ideas for Haskell', from Python
> To: Immanuel Litzroth <immanuel203 at gmail.com>,
> haskell-cafe at haskell.org
> Message-ID:
> <2076f2f90901170312y7e6dfa36jf61ab2f67f1c454a at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> 2009/1/16 Immanuel Litzroth <immanuel203 at gmail.com>:
> > 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/<http://www.cse.unsw.edu.au/%7Edons/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 <andrewcoppin at btinternet.com>
> Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
> To: haskell-cafe at haskell.org
> Message-ID: <4971BE38.9060002 at btinternet.com>
> 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" <ekirpichov at gmail.com>
> Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
> To: david48 <dav.vire+haskell at gmail.com <dav.vire%2Bhaskell at gmail.com>>
> Cc: "Apfelmus, Heinrich" <apfelmus at quantentunnel.de>,
> haskell-cafe at haskell.org
> Message-ID:
> <5e0214850901170327t13bd62ds75167a28f68ed39c at mail.gmail.com>
> 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 <dav.vire+haskell at gmail.com<dav.vire%2Bhaskell at gmail.com>
> >:
> > 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" <ekirpichov at gmail.com>
> Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
> To: "Andrew Coppin" <andrewcoppin at btinternet.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> <5e0214850901170334u27f17902nc56d0002f4702f06 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2009/1/17 Andrew Coppin <andrewcoppin at btinternet.com>:
> > Cory Knapp wrote:
> >>
> >> Actually, that was part of my point: When I mention Haskell to people,
> and
> >> when I start describing it, they're generally frightened enough by the
> focus
> >> on pure code and lazy evaluation-- add to this the inherently abstract
> >> 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 <andrewcoppin at btinternet.com>
> Subject: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian
> Hurt]
> To: haskell-cafe at haskell.org
> Message-ID: <4971C931.2070202 at btinternet.com>
> 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" <ekirpichov at gmail.com>
> Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian
> Hurt]
> To: "Andrew Coppin" <andrewcoppin at btinternet.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> <5e0214850901170412j12536846r91f7dc58d8b8f806 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2009/1/17 Andrew Coppin <andrewcoppin at btinternet.com>:
> > 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
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
> ------------------------------
>
> Message: 10
> Date: Sat, 17 Jan 2009 05:16:06 -0700
> From: Luke Palmer <lrpalmer at gmail.com>
> Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian
> Hurt]
> To: Andrew Coppin <andrewcoppin at btinternet.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> <7ca3f0160901170416n28e822c1t5cd693d61f9446a3 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sat, Jan 17, 2009 at 5:04 AM, Andrew Coppin
> <andrewcoppin at btinternet.com>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 <bulat.ziganshin at gmail.com>
> Subject: Re[2]: [Haskell-cafe] Functors [Comments from OCaml Hacker
> Brian Hurt]
> To: Luke Palmer <lrpalmer at gmail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID: <1434901537.20090117162805 at gmail.com>
> 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:Bulat.Ziganshin at gmail.com
>
>
>
> ------------------------------
>
> Message: 12
> Date: Sat, 17 Jan 2009 07:08:33 -0800
> From: David Leimbach <leimy2k at gmail.com>
> Subject: Re: Re[2]: [Haskell-cafe] Comments from OCaml Hacker Brian
> Hurt
> To: david48 <dav.vire+haskell at gmail.com <dav.vire%2Bhaskell at gmail.com>>
> Cc: Bulat Ziganshin <Bulat.Ziganshin at gmail.com>,
> haskell-cafe at haskell.org
> Message-ID:
> <3e1162e60901170708q18621c2ehb062e33fc9bdd4a3 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sat, Jan 17, 2009 at 1:41 AM, david48
> <dav.vire+haskell at gmail.com <dav.vire%2Bhaskell at gmail.com><
> dav.vire%2Bhaskell at gmail.com <dav.vire%252Bhaskell at gmail.com>>
> > wrote:
>
> > On Fri, Jan 16, 2009 at 3:10 PM, Bulat Ziganshin
> > <bulat.ziganshin at gmail.com> 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
> > Haskell-Cafe at haskell.org
> > 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" <jefferson.r.heard at gmail.com>
> Subject: [Haskell-cafe] OS X build failure of Gtk2Hs from MacPorts
> To: gtk2hs-users at lists.sourceforge.net, "Haskell Cafe"
> <haskell-cafe at haskell.org>
> Message-ID:
> <4165d3a70901170718y74cd86d6oafcd0bf95018431f at mail.gmail.com>
> 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" <lennart at augustsson.net>
> Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
> To: "Andrew Coppin" <andrewcoppin at btinternet.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> <f4876cd70901170733o20a36b8bt4c2288c856d161e7 at mail.gmail.com>
> 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
> <andrewcoppin at btinternet.com> wrote:
> > Cory Knapp wrote:
> >>
> >> Actually, that was part of my point: When I mention Haskell to people,
> and
> >> when I start describing it, they're generally frightened enough by the
> focus
> >> on pure code and lazy evaluation-- add to this the inherently abstract
> >> nature, and we can name typeclasses "cuddlyKitten", and the language is
> >> still going to scare J. R. Programmer. By "inherently mathematical
> nature",
> >> I didn't mean names like "monoid" and "functor", I meant *concepts* like
> >> monoid and functor. Not that either of them are actually terribly
> difficult;
> >> the problem is that they are terribly abstract. That draws a lot of
> people
> >> (especially mathematicians), but most people who aren' drawn by that are
> >> hugely put off-- whatever the name is. So, I guess my point is that the
> name
> >> is irrelevant: the language is going to intimidate a lot of people who
> are
> >> intimidated by the vocabulary.
> >
> > Oh, I don't know. I have no idea what the mathematical definition of
> > "functor" is, but as far as I can tell, the Haskell typeclass merely
> allows
> > you to apply a function simultaneously to all elements of a collection.
> > That's pretty concrete - and trivial. If it weren't for the seemingly
> > cryptic name, nobody would think twice about it. (Not sure exactly what
> > you'd call it though...)
> >
> > A monoid is a rather more vague concept. (And I'm still not really sure
> why
> > it's useful on its own. Maybe I just haven't had need of it yet?)
> >
> > I think, as somebody suggested about "monad", the name does tend to
> inspire
> > a feeling of "hey, this must be really complicated" so that even after
> > you've understood it, you end up wondering whether there's still
> something
> > more to it than that.
> >
> > But yes, some people are definitely put off by the whole "abstraction of
> > abstractions of abstraction" thing. I think we probably just need some
> more
> > concrete examples to weight it down and make it seem like something
> > applicable to the real world.
> >
> > (Thus far, I have convinced exactly *one* person to start learning
> Haskell.
> > This person being something of a maths nerd, their main complaint was not
> > about naming or abstraction, but about the "implicitness" of the
> language,
> > and the extreme difficulty of visually parsing it. Perhaps not surprising
> > comming from a professional C++ programmer...)
> >
> >> At the same time, I think everyone is arguing *for* better
> documentation.
> >> And you're probably right: better documentation will bring the abstract
> >> nonsense down to earth somewhat.
> >
> > Amen!
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
> ------------------------------
>
> Message: 15
> Date: Sat, 17 Jan 2009 07:37:30 -0800
> From: David Leimbach <leimy2k at gmail.com>
> Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
> To: Lennart Augustsson <lennart at augustsson.net>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> <3e1162e60901170737j360fad4br492c053277f6f84 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sat, Jan 17, 2009 at 7:33 AM, Lennart Augustsson
> <lennart at augustsson.net>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
> > <andrewcoppin at btinternet.com> wrote:
> > > Cory Knapp wrote:
> > >>
> > >> Actually, that was part of my point: When I mention Haskell to people,
> > and
> > >> when I start describing it, they're generally frightened enough by the
> > focus
> > >> on pure code and lazy evaluation-- add to this the inherently abstract
> > >> nature, and we can name typeclasses "cuddlyKitten", and the language
> is
> > >> still going to scare J. R. Programmer. By "inherently mathematical
> > nature",
> > >> I didn't mean names like "monoid" and "functor", I meant *concepts*
> like
> > >> monoid and functor. Not that either of them are actually terribly
> > difficult;
> > >> the problem is that they are terribly abstract. That draws a lot of
> > people
> > >> (especially mathematicians), but most people who aren' drawn by that
> are
> > >> hugely put off-- whatever the name is. So, I guess my point is that
> the
> > name
> > >> is irrelevant: the language is going to intimidate a lot of people who
> > are
> > >> intimidated by the vocabulary.
> > >
> > > Oh, I don't know. I have no idea what the mathematical definition of
> > > "functor" is, but as far as I can tell, the Haskell typeclass merely
> > allows
> > > you to apply a function simultaneously to all elements of a collection.
> > > That's pretty concrete - and trivial. If it weren't for the seemingly
> > > cryptic name, nobody would think twice about it. (Not sure exactly what
> > > you'd call it though...)
> > >
> > > A monoid is a rather more vague concept. (And I'm still not really sure
> > why
> > > it's useful on its own. Maybe I just haven't had need of it yet?)
> > >
> > > I think, as somebody suggested about "monad", the name does tend to
> > inspire
> > > a feeling of "hey, this must be really complicated" so that even after
> > > you've understood it, you end up wondering whether there's still
> > something
> > > more to it than that.
> > >
> > > But yes, some people are definitely put off by the whole "abstraction
> of
> > > abstractions of abstraction" thing. I think we probably just need some
> > more
> > > concrete examples to weight it down and make it seem like something
> > > applicable to the real world.
> > >
> > > (Thus far, I have convinced exactly *one* person to start learning
> > Haskell.
> > > This person being something of a maths nerd, their main complaint was
> not
> > > about naming or abstraction, but about the "implicitness" of the
> > language,
> > > and the extreme difficulty of visually parsing it. Perhaps not
> surprising
> > > comming from a professional C++ programmer...)
> > >
> > >> At the same time, I think everyone is arguing *for* better
> > documentation.
> > >> And you're probably right: better documentation will bring the
> abstract
> > >> nonsense down to earth somewhat.
> > >
> > > Amen!
> > >
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > Haskell-Cafe at haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > 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 <newsham at lava.net>
> Subject: Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package
> available
> To: Henning Thielemann <schlepptop at henning-thielemann.de>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID: <Pine.BSI.4.64.0901170621100.10489 at malasada.lava.net>
> 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/ <http://www.thenewsh.com/%7Enewsham/>
>
>
> ------------------------------
>
> Message: 17
> Date: Sat, 17 Jan 2009 16:46:12 +0000
> From: Phil <pbeadling at mail2web.com>
> Subject: [Haskell-cafe] Efficient Factoring Out of Constants
> To: Luke Palmer <lrpalmer at gmail.com>, "haskell-cafe at haskell.org"
> <haskell-cafe at haskell.org>
> Message-ID: <C597BBD4.28E0%pbeadling at mail2web.com<C597BBD4.28E0%25pbeadling at mail2web.com>
> >
> 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" <pbeadling at mail2web.com> wrote:
>
> >
> > On 16/01/2009 01:28, "Luke Palmer" <lrpalmer at gmail.com> 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
> > Haskell-Cafe at haskell.org
> > 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 <lrpalmer at gmail.com>
> Subject: [Haskell-cafe] Re: Efficient Factoring Out of Constants
> To: phil at beadling.co.uk
> Cc: "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Message-ID:
> <7ca3f0160901170855n146bb029s5688e2e56411401d at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> On Sat, Jan 17, 2009 at 9:46 AM, Phil <pbeadling at mail2web.com> 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
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> End of Haskell-Cafe Digest, Vol 65, Issue 48
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090118/2ca63042/attachment-0001.htm
More information about the Haskell-Cafe
mailing list