January 2009 - Haskell-Cafe

Re: Functors [Comments from OCaml Hacker Brian Hurt]
by Louis Wasserman 18 Jan '09

18 Jan '09

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(a)gmail.com On Sat, Jan 17, 2009 at 10:46 AM, <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)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(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)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(a)gmail.com <dav.vire%2Bhaskell(a)gmail.com>> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: "Jonathan Cast" <jonathanccast(a)fastmail.fm> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <4c88418c0901170147u3e0a3d65r2ab72d9bbc8cb1e6(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast > <jonathanccast(a)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(a)gmail.com <dav.vire%2Bhaskell(a)gmail.com>> > Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt > To: "Apfelmus, Heinrich" <apfelmus(a)quantentunnel.de> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <4c88418c0901170208i74358328ycaa10359fb639873(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jan 16, 2009 at 10:28 PM, Apfelmus, Heinrich > <apfelmus(a)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(a)btinternet.com> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: haskell-cafe(a)haskell.org > Message-ID: <4971BBD7.504(a)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(a)gmail.com> > Subject: Re: [Haskell-cafe] some ideas for Haskell', from Python > To: Immanuel Litzroth <immanuel203(a)gmail.com>, > haskell-cafe(a)haskell.org > Message-ID: > <2076f2f90901170312y7e6dfa36jf61ab2f67f1c454a(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello, > > 2009/1/16 Immanuel Litzroth <immanuel203(a)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(a)btinternet.com> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: haskell-cafe(a)haskell.org > Message-ID: <4971BE38.9060002(a)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(a)gmail.com> > Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt > To: david48 <dav.vire+haskell(a)gmail.com <dav.vire%2Bhaskell(a)gmail.com>> > Cc: "Apfelmus, Heinrich" <apfelmus(a)quantentunnel.de>, > haskell-cafe(a)haskell.org > Message-ID: > <5e0214850901170327t13bd62ds75167a28f68ed39c(a)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.ht… > - this is where I started to appreciate the power of mathematical > abstractions even more. > > 2009/1/17 david48 <dav.vire+haskell(a)gmail.com<dav.vire%2Bhaskell(a)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(a)gmail.com> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: "Andrew Coppin" <andrewcoppin(a)btinternet.com> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <5e0214850901170334u27f17902nc56d0002f4702f06(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2009/1/17 Andrew Coppin <andrewcoppin(a)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(a)btinternet.com> > Subject: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian > Hurt] > To: haskell-cafe(a)haskell.org > Message-ID: <4971C931.2070202(a)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(a)gmail.com> > Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian > Hurt] > To: "Andrew Coppin" <andrewcoppin(a)btinternet.com> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <5e0214850901170412j12536846r91f7dc58d8b8f806(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2009/1/17 Andrew Coppin <andrewcoppin(a)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(a)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(a)gmail.com> > Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian > Hurt] > To: Andrew Coppin <andrewcoppin(a)btinternet.com> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <7ca3f0160901170416n28e822c1t5cd693d61f9446a3(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Sat, Jan 17, 2009 at 5:04 AM, Andrew Coppin > <andrewcoppin(a)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 >

1 0

runghc Setup.hs doitall
by Alberto G. Corona 18 Jan '09

18 Jan '09

Hi guys: I don´t know how difficult really is, but it seens that it could be done because all the necessary elements are there (except perhaps the mapping package name-hackage url): Why hasn´t been done yet Is unknown to me. It would be very useful and a big save of time to have a cabal commad "chech-dependencies-and-install-them-by-downloading-them-from-hackage-then-configure-build-and-install-this-package?. The unix installers do is t from binaries and are obsolete, so I have to do it manually with cabal everytime when i download a new compiler version from haskell.org. Cheers Alberto.

8 15

Optimistic evaluation
by Andrew Coppin 18 Jan '09

18 Jan '09

Hi folks. I just read a rather interesting paper about a fork of GHC that performs "optimistic evaluation". This shows big wins in some cases. The authors claim to have implemented this in a fork of GHC and promised that it would be integrated into the production compiler "in the near future". Curios, I investigated the GHC wiki... Well, let's see now. The front page has links to "out release plans for 6.8.3" and "what will be in 6.10". The latter page, http://hackage.haskell.org/trac/ghc/wiki/Status/Releases mentions that a beta has just been released... and seems oblivious to the fact that 6.10.1 is production now. Clearly, any hopes I might have had of getting a handle on the current status of GHC from this wiki were dashed somewhat. ;-) Does anybody have any suggestions for a more reliable way of figuring out what the current activities and plans for GHC are?

2 1

ANN: leapseconds-announced-2009
by Bjorn Buckwalter 18 Jan '09

18 Jan '09

Dear all, I'm pleased to announce the upload of the leapseconds-announced package[1] to Hackage. leapseconds-announced contains a single module and a single function implementing the Data.Time.Clock.TAI.LeapSecondTable interface (type). The documentation[2] for Data.Time.Clock.TAI.LeapSecondTable says "No table is provided, as any program compiled with it would become out of date in six months" and with that I have no objections. However, I frequently find myself needing a LeapSecondTable for a quick-and-dirty one-off analysis or simulation of the present or past. In these cases I've lazily used "(const 33)" (or more recently: "(const 34)") as my LeapSecondTable. leapseconds-announced is a pragmatic, if imperfect, improvement over my past practices. It provides a LeapSecondTable with all leap seconds announced to date (hence the name). Once the IERS announces[3] another leap second the package will need an update and all code using it a recompile. While this precludes its use in long-running production applications it is eminently adequate for my one-off uses or for applications that can afford to recompile infrequently. While, in the words of the Data.Time.Clock.TAI documentation, "most people won't need this module" I hope it can be of utility to someone. Thanks, Bjorn Buckwalter [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/leapseconds-anno… [2] http://www.haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Clock-… [3] http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat

2 4

Slow Text.JSON parser
by Levi Greenspan 18 Jan '09

18 Jan '09

Dear list members, I tried Text.JSON from hackage and did an initial test to see how well it performs. I created a single JSON file of roughly 6 MB containing a single JSON array with 30906 JSON objects and used the following code to parse it: module Main where import System.IO import Data.Time.Clock import System.Environment import Text.Printf import Text.JSON parse s = do start <- getCurrentTime let !len = decode s end <- getCurrentTime print len printf "Elapsed time = %s\n" (show $ diffUTCTime end start) where decode s = case decodeStrict s of Ok (JSArray a) -> length a _ -> -1 main = do file <- getArgs >>= return . head withFile file ReadMode (\h -> hGetContents h >>= parse) The outcome was something like: 30906 Elapsed time = 2.902755s on my 2GHz core 2 duo. Another Java-based JSON parser (Jackson: http://www.cowtowncoder.com/hatchery/jackson/index.html) gives me: 30906 Elapsed time = 480 ms Now I wonder why Text.JSON is so slow in comparison and what can be done about it. Any ideas? Or is the test case invalid? Thanks, Levi ----------------------------------- The Java code for the Jackson test is: import org.codehaus.jackson.JsonParser; import org.codehaus.jackson.JsonFactory; import org.codehaus.jackson.map.JsonTypeMapper; import org.codehaus.jackson.map.JsonNode; import java.io.File; class Test { public static void main(String[] args) throws Exception { final long start = System.currentTimeMillis(); final JsonTypeMapper mapper = new JsonTypeMapper(); final JsonParser parser = new JsonFactory().createJsonParser(new File(args[0])); final JsonNode root = mapper.read(parser); final long end = System.currentTimeMillis(); System.out.println(root.size()); System.out.println(String.format("Elapsed time = %d ms", end - start)); } }

8 15

Re: Comments from OCaml Hacker Brian Hurt
by John Lato 18 Jan '09

18 Jan '09

Manlio Perillo wrote: > > I'm fine with current names. > > However I would like to see better documentation, and examples. > > You can't just have in the documentation: > this is xxx from yyy branch of mathematics, see this paper. > > You should explain how (and why) to use xxx. > Absolutely this! I would rather have to look up Monoid than see Appendable used for operations that don't fit my notion of appending. I don't care much what things are called as long as it's accurate. Even so, I typically find Haskell's documentation to be not very helpful, because it's aimed towards category theorists. That is, Haskell documentation often seems to take the approach "The reader is familiar with [branch of abstract mathematics], so knows all these concepts. The job of the documentation is to show how standard terminology from [branch of abstract math] is written in Haskell". The problem with this is that most people aren't familiar with general abstract nonsense, and this documentation is useless for those, i.e. most, people. In fact, most people don't care about how abstract nonsense is written in Haskell. They care about solving their particular problems, and are only interested in abstract nonsense to the sense that it can be useful in solving those problems. Overwhelmingly the documentation does not show how particular concepts apply to actual programming problems, or any concrete problems at all. Here is the current complete documentation for Data.Monoid 'mappend', which happens to be a good example of which I speak: An associative operation That could mean anything. There are lots of associative operations. Should I believe the name that somehow this operation is append-like? If so, and I'm using a list instance, where are items appended to? Is it an append onto the tail of the list, or is it really a cons? I would expect the documentation to cover this, but it doesn't. Far too often the documentation fails to provide this sort of useful, practical information. This is the problem faced by an abstract-nonsense unaware user: I want to accomplish [some task]. Some blogger wrote that [monoids, functors, arrows, etc.] provide a good solution. But when I look up [monoids, functors, etc.] in [some academic paper], it doesn't show how these concepts apply to the problem at hand, or indeed any programming problem at all. In fact, I can't even understand what the doc says without first learning about [even more abstract stuff]. So now the user needs to develop a strong background in [some abstract topic] he/she doesn't care about just to figure out *if* that abstract topic could possibly be useful. At this point most users will give up. If instead they had access to documentation that says "[Monoids] are useful programming abstractions because they can solve problems A, B, and C in these manners, and incidentally they can do all this other stuff too", the same users would not only stick with Haskell longer, they would increase their theoretical awareness at the same time. I think even the most elitist Haskell users would think this is a good outcome. Of course this better documentation would need to be written. Somebody upthread (Duncan?) suggested that suitable individuals may not exist, and I agree with that. Of people who understand the material well enough to document it, many are busy doing other work, and many have no interest or are ideologically opposed to writing documentation of this type. This situation reminds me very much of a particularly well-known article by Milton Babbitt, "Who Cares If You Listen." I expect that many Haskellers would find it interesting at the least. John Lato

2 1

walking a directory tree efficiently
by Manlio Perillo 18 Jan '09

18 Jan '09

Hi. During a tentative (quite unsuccessfull) to convert a simple Python script that prints on stdout a directory and all its subdirectory [1] in a good Haskell (mostly to start to do real practice with the language), I came across this blog post: http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-hask… Since recently I read about alternatives to lazy IO (like iteratee), I'm curious to know if a flexible, efficient and safe alternative exists, for the task of display a directory tree. [1] http://paste.pocoo.org/show/99523/ Thanks Manlio perillo

6 6

ANN: language-sh-0.0.3.1
by Stephen Hicks 17 Jan '09

17 Jan '09

Hi everyone, I'm pleased to announce a new package I've just uploaded to hackage: language-sh. It's a set of modules for parsing, manipulating, and printing sh-style shell scripts. It's being developed alongside shsh, the Simple Hakell Shell (available at http://code.haskell.org/shsh/, but it's still missing a few features before I'm ready to release it). I have two goals with this project (shsh, that is - I don't actually have plans for Language.Sh by itself, except that some people suggested it could be useful on its own). First, making possible portable test suits that run on Windows as well as on Unix. The second is a bit more difficult, but ultimately I hope shsh can become a viable command-line shell for Windows. I would love any comments, suggestions, criticisms, and especially patches! Please let me know what you think! http://hackage.haskell.org/cgi-bin/hackage-scripts/package/language-sh-0.0.… Cheers, steve hicks

1 0

Hackage about to reach 1000 releases
by Don Stewart 17 Jan '09

17 Jan '09

Hackage is about to reach the 1000 release mark, 2 years after it went live. That's right: in 2 years we've gone from having only a handful of released projects, to one thousand! Well done everyone! I did some quick visualisation of the rate of new releses, diversity of packages, and community growth over the period: http://archhaskell.wordpress.com/2009/01/18/open-source-haskell-releases-an… I'm very happy about the diversity of hackage apps, and the pleasing rate of growth of new releases. None of this would have been possible with out thousands of hours of work from the Cabal and Hackage hackers, the compiler teams, and the developers themselves. Keep churning out new and intresting code everyone! -- Don P.S. cabal install

1 0

OS X build failure of Gtk2Hs from MacPorts
by Jeff Heard 17 Jan '09

17 Jan '09

/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

3 3