December 2009 - Haskell-Cafe

Re[6]: [Haskell-cafe] Re: How Can Haskell Be Saved?
by Bulat Ziganshin 14 Dec '09

14 Dec '09

Hello Erik, Monday, December 14, 2009, 1:27:12 PM, you wrote: > It seems the POSIX subsystem was POSIX.1 only and was removed completely > in windows XP. Thats not a solution. yes, i mean the same. just don't mix up fseek() in your C compiler with windows POSIX implementation >> POSIX subsystem was implemented by MS (and other major players) only >> to meet some bureaucratic reqs from DoD/UsGov, > You mean source code compatibility with dozens of UNIX variants from dozens > of UNIX vendors? You see that as a "beurocratic requirement"? i don't rememeber details. something that they buyed only hardware with POSIX-compatible OSes so MS implemented it meet reqs but really this implementation was not intended for real use :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

getting data through foreign layer without marshalling
by Donn Cave 14 Dec '09

14 Dec '09

I'm working with a C++ application library, of the sort where you instantiate a subclass of the library object and it dispatches your functions on receipt of various events. With multiple OS threads, by the way. This works all right so far, with some C++ boilerplate and Haskell FunPtrs created via the foreign "wrapper" option, but I am not crazy about marshalling the application data, to get it to the C++ object and back to my application functions. So, I'm wondering if the way I'm trying to thread application data through the C++ layer is reasonably fool-proof - I mean, empirically it works in a simple test, but are there going to be storage issues, etc.? Is there a better way to do it? Briefly, - my callbacks AppData -> CPlusObjectPtr -> P0 ... -> IO Pn - the FunPtr inserted into C++ object FunPtr (CPlusObjectPtr -> P0 ... -> IO Pn) ... i.e, I apply the AppData parameter first - I rewrite the C++ object's FunPtrs every time I update the application data (freeHaskellFunPtr prior values.) I'm just not sure where AppData lives while it's referenced in a FunPtr via partial application, if there might be multiple copies, etc. thanks! Donn Cave, donn(a)avvanta.com

3 3

Pure extremism (was: Re: Why?)
by Luke Palmer 13 Dec '09

13 Dec '09

On Fri, Dec 11, 2009 at 7:07 PM, Jason Dusek <jason.dusek(a)gmail.com> wrote: > 2009/12/11 Luke Palmer <lrpalmer(a)gmail.com>: >> The idea being that any code that is pure could be evaluated >> anywhere with a very simple interpreter. If you have pure >> code, you can trace it back and evaluate it in a sandbox where >> you don't need a C runtime, a linker, or really anything but >> the simplest substitution engine. *All* effects bubble their >> way up to the top level, so that we know from the type >> signature of a value the machinery we will need to run it. > > This sounds good but there is something puzzling about it. > Where do we draw the line between "machinery" and "packages"? > The types don't tell us what libraries we need. I don't follow this. Do you mean external libraries, such as "the library used to execute an IO type"? That makes sense to me, though in that case the types do tell. Or you might mean what *haskell* libraries does a piece of code depend on? To address that, note that I consider a statement like: import Control.Monad.State As a form of impurity in a sense (it is hard to say what I consider it, actually, but I think it inhibits reasoning and verification). What version are you importing? From where are you importing it ; where is it defined? These things depend on the compiler environment, which means that the meaning of a piece of code depends on who is compiling it. I have brainstormed solutions to this problem while thinking about my (currently on hold or dead) Udon project: http://lukepalmer.wordpress.com/2008/11/19/udon-sketch-2/ . But it is just a brainstorm, nothing I would sign in blood. I'd love it if more people were thinking about these kinds of problems (Any papers you well-read folks know about?) > They don't tell us how much RAM/CPU we need, either. And these! My ideas for these are now firmly beyond Haskell and way out in the ill-defined vaporware space. I discuss in abstract the idea of distinguishing the performance semantics from the denotation of a piece of code here: http://lukepalmer.wordpress.com/2009/06/12/the-role-of-a-core-calculus/ . Brainstorm disclaimer applies, and I want to see more research! (Papers?) > >> Pure functional code as the minimal essence of pure >> computation -- everything else an EDSL. > > Partial or total code? When the state of the art catches up, total for sure. Why reason with DCPOs when you can reason with the mathematical objects themselves? But when you require functions to be total, you end up needing to prove a lot more about them just to convince the compiler that they will terminate. Functional proof assistants are a wonderful area of research, but are still very early and it is frickin' hard to prove stuff about code. My belief is that time is all that is necessary here -- the research will continue and it will become easier and easier to prove properties about code (probably never completely automatic, but someday I hope to "handwave the essence" of a proof and have the computer fill in the bullshit details). But when it's easy enough, then partiality is definitely an "effect" to be modeled as well. It has the advantage, unlike most effects, that given a good model, you can prove your way out of it. I.e. write a function with a partiality effect, then elsewhere prove that it actually is total so you can drop the effect. I seem to recall a proof-of-concept of this idea for Coq. There are many levels to purity, and I think as research progresses we will gradually be able to go to the stricter levels while remaining productive. It gives me comfort to see a long road ahead -- I don't like to see perfect languages, because that's just me seeing my own ignorance :-) Luke

2 1

Haskell Weekly News: Issue 142 - December 13, 2009
by jfredett＠gmail.com 13 Dec '09

13 Dec '09

--------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20091213 Issue 142 - December 13, 2009 --------------------------------------------------------------------------- Welcome to issue 142 of HWN, a newsletter covering developments in the [1]Haskell community. First of all, apologies for the late edition, I've only one set of finals left, and then everything should return to a normal schedule (at least, that's the plan). This week brings lots of development on the various usb utilities, an edition of the Haskell Web News (which covers, in summary, the events of the previous month in the Haskell online community), and some really great discussion about why Haskell is Pure. Until next week, Haskeller's, your Haskell Weekly News! Announcements Next meeting: December 17th at MIT (32-G882). Ravi Nanavati [2]announced the next meeting of the Boston Area Haskell User Group. Ryan Newton will be talking about Intel Concurrent Collections for Haskell. PCLT-0.1 and PCLT-DB-0.1. Andrey Sisoyev [3]announced his first two packages he's developed in Haskell. Both of his new packages relate to localization of packages. Announcing a summer internship for a NASA-sponsored project. Lee Pike [4]announced a new summer internship sponsored by NASA and Galois, Inc. unicode-symbols-0.1.1. Roel van Dijk [5]announced the release of his package 'unicode-symbols'. This packages offers alternative symbols for a number of common function and operators from the base and container packages. ls-usb-0.1.0.2. Roel van Dijk [6]announced a minor update of ls-usb, his package for listing USB devices connected to your system. usb-safe-0.1. Bas van Dijk [7]announced the release of his package usb-safe, which provides an abstract interface to the bindings-libusb library. usb-0.3. Bas van Dijk [8]announced a new release of his 'usb' library for high-level communication with usb devices from Haskell. bindings-libusb-1.4.2. Bas van Dijk [9]announced a new version of bindings-libusb, a DSL based, low level binding to libusb The Haskell Web News: December 2009 Edition. Don Stewart [10]announced the Haskell Web News for December. new installment of failure framework. Michael Snoyman [11]announced the next installment of the Failure Framework. PortAudio Windows Tutorial and Binaries. M Xyz [12]announced a tutorial for setting up PortAudio on Windows readline-statevar-1.0.1.0. Krzysztof Skrzetnicki [13]announced a small wrapper for readline. hakyll-0.1. Jasper van der Jeugt [14]announced Hakyll, a simple static site generator written in Haskell. Discussion Why? John D. Earle [15]asked about what benefits of purity in Haskell. Type system speculation. Andrew Coppin [16]asked about why we Haskeller's (including himself) are so obsessed with the type system. To Hackage or not to Hackage. John Van Enk [17]asked about whether it was worth putting a package on Hackage. Hayoo and Hoogle (beginner question). drostin77 [18]asked our 'Hopefully Helpful Haskell Community' about the differences between Hoogle and Hayoo. Blog noise [19]Haskell news from the [20]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Manuel M T Chakravarty: [21]Using DTrace to track scheduler events of GHC's runtime. * Darcs: [22]darcs weekly news #47. * Brent Yorgey: [23]Mgu's and universal properties. * Philip Wadler: [24]Computer Science Education Week. * Bryan O'Sullivan: [25]The performance of Data.Text. * Neil Brown: [26]Solving the Santa Claus Problem with Conjunction. * Douglas M. Auclair (geophf): [27]Don't know; don't care: Whatever. * Ivan Lazar Miljenovic: [28]Command Input/Output and blocking. * Galois, Inc: [29]Tech Talk: John Launchbury presents Conal Elliottâs âBeautiful Differentiationâ. * Well-Typed.Com: [30]Talk at the Functional Programming eXchange. * Neil Brown: [31]The Problem with Parallel Participants Professing Priority. * Sean Leather: [32]Draft: "Pull-Ups, Push-Downs, and Passing It Around: Exercises in Functional Incrementalization". * Mikael Vejdemo Johansson (Syzygy-): [33]Coordinatization with hom complexes. * Haskell Web News: [34]What's new in Haskell? December 2009. * Dan Piponi (sigfpe): [35]Where do monads come from?. * Michael Snoyman: [36]Two language extensions. Quotes of the Week * sproingie: | {-# LANGUAGE NoTypeChecking #-} * kmc: the usual structure for a Haskell program is a crunchy IO shell with a gooey chocolate pure function center * sproingie: if it makes Cale's brane asplode, i think there's no hope for me understanding it * Wikipedia: In topology, the long line (or Alexandroff line) is a topological space analogous to the real line, but much longer. * ray: a monad tutorial is like a sausage factory * TomTobin: ::facepalm:: I wrote "Foobar" as a placeholder as I was typing [for the author's name], and never replaced it [in my email]. * ski: > (let id :: (forall id. id -> id) -> id -> id; id id = id id in id) id 5 * dmwit: analogies are endofunctors in the category of bad explanations * knobo: I really like this :) I can see that haskell is really cool now. This i a "matrix moment" for me :) About the Haskell Weekly News New editions are posted to [37]the Haskell mailing list as well as to [38]the Haskell Sequence and [39]Planet Haskell. [40]RSS is also available, and headlines appear on [41]haskell.org. To help create new editions of this newsletter, please see the information on [42]how to contribute. Send stories to jfredett . at . gmail . dot . com. The darcs repository is available at darcs get [43]http://patch-tag.com/r/jfredett/HWN2/pullrepo HWN2 . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67829 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67818 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67637 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67628 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67624 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67623 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67622 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67621 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67455 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67417 12. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67407 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67328 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67312 15. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67702 16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67658 17. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67551 18. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67412 19. http://planet.haskell.org/ 20. http://haskell.org/haskellwiki/Blog_articles 21. http://justtesting.org/post/281294210 22. http://blog.darcs.net/2009/12/darcs-weekly-news-47.html 23. http://byorgey.wordpress.com/2009/12/11/mgus-and-universal-properties/ 24. http://wadler.blogspot.com/2009/12/computer-science-education-week.html 25. http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/ 26. http://chplib.wordpress.com/2009/12/10/solving-the-santa-claus-problem-with… 27. http://logicaltypes.blogspot.com/2008/07/dont-know-dont-care-whatever.html 28. http://ivanmiljenovic.wordpress.com/2009/12/10/command-inputoutput-and-bloc… 29. http://www.galois.com/blog/2009/12/09/tech-talk-john-launchbury-presents-co… 30. http://blog.well-typed.com/2009/12/talk-at-the-functional-programming-excha… 31. http://chplib.wordpress.com/2009/12/08/the-problem-with-parallel-participan… 32. http://feedproxy.google.com/~r/splonderzoek/~3/vjibqjB5x04/draft-pull-ups-p… 33. http://blog.mikael.johanssons.org/archive/2009/12/coordinatization-with-hom… 34. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-decembe… 35. http://blog.sigfpe.com/2009/12/where-do-monads-come-from.html 36. http://snoyberg.wordpress.com/2009/12/07/two-language-extensions/ 37. http://www.haskell.org/mailman/listinfo/haskell 38. http://sequence.complete.org/ 39. http://planet.haskell.org/ 40. http://sequence.complete.org/node/feed 41. http://haskell.org/ 42. http://haskell.org/haskellwiki/HWN 43. http://patch-tag.com/r/jfredett/HWN2/pullrepo%20HWN2

3 2

Re: ANNOUNCE: GHC version 6.12.1
by Robin Green 13 Dec '09

13 Dec '09

If you need an update of a package to make it build/run on GHC 6.12.1, or if you have modified someone else's package to do so, please feel free to use this wiki page to coordinate: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 I suggest that those who have patches to contribute add a link to their patches or forks from that page[*], *and* submit their patches to the package maintainer(s). That way, we can avoid duplication of effort, while not having to wait for package maintainers to get around to applying our patches. This may sound trivial, but it can be annoying waiting for a whole chain of packages to "catch up" before you can even build your own package. So you may end up fixing other people's packages - which can easily lead to substantial duplication of effort. [*] or you can email me links/patches and I'll add them for you

1 0

What about adding a wiki for each haskell project?
by Marc Weber 13 Dec '09

13 Dec '09

hackage is success because: a) many (most) people do use it (by uploading packages) b) it is a comprehensive list of availible packages if not the most comprehensive one Duncan, can you write about your concerns briefly why some maintainers may dislike this idea ? Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: "Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the "," in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlu… " Of course I mailed the author. Looking at the package again I noticed that it was uploaded by someone else: GwernBranwen. gwern on #haskell told me that the author is responsive so I'll just wait some days, but others will try and fail as well. If the other person is new to haskell he may not find the fix fast. He just wants to know which of the heads is causing trouble.. Another use case would be users adding "If you're interested in this topic also have a look at XXX" Yet another use case is someone figuring out that function X was removed in version Y. He could than add a note x vanished since v.10 and everybody who wants to update cabal dependency constraints doesn't have to download the darcs repo to figure out that he should use package <= v.10 . Of course contents of wiki pages may be totally wrong because the contents were written by people knowing the package less than the maintainers and authors. But everyone knows this and will take care. This wiki can server as fail over if the maintainer is on holiday. This wiki page will prevent people blogging about packages and benchmark results anywhere on the internet. So it's much more likely that this information is read and maintained. If you use google to look for bug fixes or such you may have success. But very often you end up reading pages dated 3 years ago which are outdated. This wiki page would be I simple effective way letting users annotate packages. Costs: Make hackage add one link. It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg This link should point to the existing haskell wiki on haskell.org: http://haskell.org/haskellwiki/project-name-without-version Even if the maintainer is availible 24/h a day he won't upload a new minor version to hackage for each change. But maybe he'll paste a small note that the darcs repo is more up to date fixing issue x/y. You don't want to upload a new version because you added some documentation. Why don't you want to do that ? It's because hackage will keep every version which was uploaded once by design. Having 50 versions of one package just causes much more work for tools such as cabal install or hack-nix. Figuring out a solution to install all packages is hard enough. Maintainers can create the wiki page and subscribe to change notifications. So I don't think it'll be that much work for them to keep an eye on those wiki pages. How do you think about it? It's about centralizing information and saving your and my time. Many packages aready do have a wiki page. So why not make it easier for all to add one? Thoughts ? Currently my goal is updating some common packages so that they use extensible exceptions and base4. But when working on some patches I'd like to tell people that I'm doing so. I can't in an easy way. That's why I'm starting this thread. Marc Weber

9 15

Are there standard idioms for lazy, pure error handling?
by John Millikin 13 Dec '09

13 Dec '09

I'm working on a library which needs to operate on large data sets, so I'd like to use lazy values. The library consists of pure functions from Text to [Event] and back. Normally, I use Maybe or Either for error handling in pure code, but using these precludes lazy evaluation. Using exceptions requires any errors to be handled in IO, which is annoying. The "idealized" signatures of the functions are: ---------------------------------------- import qualified Data.Text.Lazy as TL data Event = EventA | EventB | EventC parse :: TL.Text -> Either ParseError [Event] serialize :: [Event] -> Either SerializeError TL.Text ---------------------------------------- I've considered two possible error handling modes, both adapted from procedural language style. The first is simply including errors in the event list. ---------------------------------------- import qualified Data.Text as T parse :: TL.Text -> [Either ParseError Event] serialize :: [Event] -> [Either SerializeError T.Text] -- use TL.fromChunks ---------------------------------------- The second uses monadic callbacks, based on side effects: ---------------------------------------- parse :: Monad m => (Event -> m ()) -> (ParseError -> m ()) -> TL.Text -> m () serialize :: Monad m => (T.Text -> m ()) -> (SerializeError -> m ()) -> [Event] -> m () ---------------------------------------- The main problem I see with these is that they don't indicate or enforce that an error terminates the event/text streams. The first allows multiple errors in a row, or events to follow an error. The second just "feels" ugly, because using it in pure code requires clients to build a Writer (possibly wrapped with ErrorT) and deal with the associated plumbing. Is there any sort of standard idiom for handling this problem? It seems that somebody must have run across it before, but the resources I can find on lazy error handling all assume the code is impure (returning IO, etc).

14 24

Preserving data type information
by Andrey Popp 12 Dec '09

12 Dec '09

I am writing URL parsing library which works the following way: - User have a spec of URL, like this: > f :: String > f = "/archive/<int:number> - There is data type and parser for specs: > data Value = IntegerValue Integer | CharValue Char > parseSpec :: Parser (Parser (Map String Value)) - So after parsing spec I have parser for URLs and after parsing them — I have mapping from strings to Value values extracted from URL and then I can process them. Now, I want to others to extend my specs by providing additional types, for example: > spec :: String > spec = "/archive/<year:archiveyear> And store year in: > data Year = Year Integer But for that I need to extend Value data type too: > data Value = Integer Value | CharValue Char | YearValue Year Which is undesirable... So, I decide to use type class instead of Value type: > class Value a > instance Value Integer > instance Value Char > instance Value Year > parseSpec :: (Value a) => Parser (Parser (Map String a)) But after parsing URL I have mapping from string to some values of type (Value a) => a which I can't process, but only by applying functions from Value type class, which is limited. So, is there any way to extract type information from containers like (Value a) => Map String a? Something like this: > getInteger :: (Value a) => Map String a -> Maybe Integer Or maybe, am I doing something wrong from the beginning?

2 2

ANN: hakyll-0.1
by Jasper van der Jeugt 12 Dec '09

12 Dec '09

Hello all, Hakyll is a simple static site generator library, mostly aimed at blogs. It supports markdown, tex and html templates. It is inspired by the ruby Jekyll program. It has a very small codebase because it makes extensive use of the excellent pandoc and Text.Template libraries. More information can be found on: http://hackage.haskell.org/package/hakyll-0.1 http://github.com/jaspervdj/Hakyll Kind regards, Jasper Van der Jeugt

17 46

Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882)
by Ravi Nanavati 12 Dec '09

12 Dec '09

---------- Forwarded message ---------- From: Ravi Nanavati <ravi_n(a)alum.mit.edu> Date: Sat, Dec 12, 2009 at 1:44 AM Subject: Next meeting: December 17th at MIT (32-G882) To: bostonhaskell(a)googlegroups.com I'm pleased to announce the December meeting of the Boston Area Haskell Users' Group. The meeting has been scheduled for Thursday, December 17th from 7pm to 9pm. Like recent meetings, it will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). Based on the responses to my previous message, our featured presenter will be Ryan Newton who will talk about the Intel Concurrent Collections for Haskell. Following his presentation, we will have our traditional break. After the break, we're going to try a joint programming exercise involving the collections. If anyone has a suggestion for an interesting programming exercise that would take advantage of the collections, please speak up (since otherwise Ryan and I will see what we can come up with next week). The December attendance poll is at: http://doodle.com/p2zcnca6k39iptb4 As always, responding to this poll will help with two things: 1. Getting an idea of what fraction of the Boston-area Haskell community can and can't attend this meeting (to help with future scheduling). 2. Giving me an estimated count of attendees, since I have talked my wife into baking some more goodies and bringing drinks again. Helping with BostonHaskell (besides volunteering to speak at future meetings): 1. Sponsorship of refreshments is still being eagerly solicited (especially as, for personal reasons, the Cupcake Fund is running low). 2. Please let me know if you're willing to arrive early (6:30pm) to stand by the door and let people into the 8th floor. I'm guessing 1 or 2 volunteers is enough here. 3. If someone is willing to edit the HaskellWiki page, post to reddit or otherwise publicize the meeting please just go ahead and do that (especially as I'm sending this out on the later side). If you have any questions about the meeting please send them to them BostonHaskell mailing list: bostonhaskell(a)googlegroups.com or contact me directly. I look forward to seeing many Boston-area Haskellers at the December meeting! Thank you, - Ravi Nanavati

3 2