- Haskell-Cafe - Haskell.org

fun with 6.12
by Johannes Waldmann 15 Dec '09

15 Dec '09

download binary distribution for ghc-6.12.1, configure, sudo make install - fine try to build some packages: cabal configure ...: cabal: This version of the cabal program is too old to work with ghc-6.12+. You will need to install the 'cabal-install' package version 0.8 or higher. If you still have an older ghc installed (eg 6.10.4), run: $ cabal install -w ghc-6.10.4 'cabal-install >= 0.8' Right - looks like a very useful error message! Then let's do it: cabal install -w ghc-6.10.4 'cabal-install >= 0.8' Resolving dependencies... cabal: There is no available version of cabal-install that satisfies >=0.8 Indeed, a package with that version does not seem to exist. darcs get --partial http://darcs.haskell.org/cabal-install/ It says 0.7.5, but let's try anyway: sudo ./bootstrap.sh --global ... Error during cabal-install bootstrap: The Haskell package 'network' is required but it is not installed. Aha. Then let's get network from hackage, as in the olden days. And parsec. And mtl. And bytesting. And syb. Well, let's try to use "cabal fetch" to avoid at least some typing. But no, cabal ist too old for 6.12 - and "cabal fetch" does not understand "-w ghc-6.10.4" Manually download HTTP and zlib, and then cabal-install really builds. Great. Try to use it to build some packages, which finally breaks at derive-2.0.1 - but it seems this page is going to be helpful (thanks, guys): http://www.haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 anyway I'm stopped now because somewhere along the way this happened: waldmann@octopus:~/software/haskell/ghc-syb$ ghc-pkg check There are problems in package ghc-binary-0.5.0.2: dependency "bytestring-0.9.1.5-01c5fa5da70289596d73fa2e44360d8a" doesn't exist best - J.W.

3 3

Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player
by M Xyz 14 Dec '09

14 Dec '09

--- On Mon, 12/14/09, M Xyz <functionallyharmonious(a)yahoo.com> wrote: From: M Xyz <functionallyharmonious(a)yahoo.com> Subject: Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player To: "Patai Gergely" <patai_gergely(a)fastmail.fm> Date: Monday, December 14, 2009, 5:50 PM --- On Mon, 12/14/09, Patai Gergely <patai_gergely(a)fastmail.fm> wrote: Also, the actual mixing (limited to the mixChunk function) is embarrassingly slow, and I wonder how much it could be improved without leaving the pure world. The program uses Portaudio for playback... Patai, I asked a similar question about a week ago, inquiring about efficient buffers for audio. I got a good response: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67258/focus=67293 Working with immutable trees instead of arrays still freaks me out, but page 289 of RWH actually made me feel a little better about it. :)

1 0

Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player
by Patai Gergely 14 Dec '09

14 Dec '09

> The more of these I see, the more guilt I feel over the condition of the > portaudio module. There's a good chance that the performance issue you're > seeing is a bad implementation of the portaudio library. Do you have any > specific problems you ran into with portaudio? I'd love to revisit at > some point... Well, when I tried to push whole blocks instead of individual samples, it seemed to miss some of these writes. It might do the same even now, but it wouldn't be noticeable with a sample missing here and there anyway. The interface for writeStream is not very fortunate. It forces me to pack samples into lists no matter what, even if the interleaved list is actually easier to produce. So it should probably provide alternative interfaces for interleaved lists (which would actually be possible right away if writeStream didn't ignore its third argument altogether), and maybe an array interface as well. I don't know if the callback interface works better, maybe that's also worth a shot. Ultimately, it would be probably best if it gave the programmer a higher abstraction, where it is passed a potentially infinite list of samples, and takes care of all the buffering duties. Also, this could be made to play nice with stream fusion in order to get the maximum performance out of it. Gergely -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html

2 1

Fwd: Re[4]: [Haskell-cafe] Re: How Can Haskell Be Saved?
by Alberto G. Corona 14 Dec '09

14 Dec '09

> > POSIX subsystem was implemented by MS (and other major players) only > to meet some bureaucratic reqs from DoD/UsGov, and i don't know any > program really using it. just don't mix C library emulation of POSIX > calls on top of Win32 with POSIX subsystem (btw, both are implemented > on top of native Windows API) > > True. I tested the posix subsystem in the early days of NT and I found that fork actually forked nothing:. Exec after fork simply substituted the old process with the new without creation of any new process.. Then I concluded that the Posix sybsystem was there simply to pass the government requirements for public contracts. Probably, some standard executable test. Arguably, the bugs where intentionally there just to make sure that it was useless, for reasons that anyone may guess...

1 0

Why?
by John D. Earle 14 Dec '09

14 Dec '09

This is a matter that I genuinely at the present time do not grasp and I am hoping that some of you who are more familiar with the Haskell language may be able to help enlighten me. I feel the question to be an important one. What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction. The following is what I believe to be true at the present time. It seems to be that the decision was made because it was a matter of taste under the belief that computer scientists can and often are superstitious and their superstitions can and often do materially interfere with progress. What I am saying is that at the present time perhaps due to my ignorance I am unfamiliar with how this benefits the language in a material sense. It appears to be a philosophical matter, a matter of identity, what Haskell stands for. The sort of decision that Apple computer and Microsoft made not to go down the POSIX road seems relevant. Historically, Apple did not embrace POSIX. Windows continues to stand for Windows, that is the graphical user interface.

23 41

Re: How Can Haskell Be Saved?
by Erik de Castro Lopo 14 Dec '09

14 Dec '09

All replies to the list please. John D. Earle wrote: > When I came to the Haskell mailing list I intended to advance a thought > which I never got around to and since we are on the topic. I ran into > problems building Haskell from source and I reasoned that since the build > system has a POSIX flavor it might be better to officially build Haskell on > Windows using SUA. The keyword here is "officially". There is a MinGW Linux > cross compiler that allows you to compile a program on Linux that will run > on Windows. > > A problem with using a cross compiler is you won't get to run the test > suite. The windows API reimplementation Wine is not godd for must things but should be more than adequate to run test suites. For libsndfile I release pre-compiled windows binaries that have been cross compiler from Linux to windows. I run the rather comprehensive libsndfile test suite under Wine and it works very well indeed. Unfortunately Wine currently only supports 32 bit windows. For 64 bit windows I still cross compile from Linux, but I then generate a testsuite tarball that contains all the binaries required to run the test suite. This can then be transferred to the target machine and run in a MinGW or Cygwin shell. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

platform configure fails to find freeglut
by J. Greg Davidson 14 Dec '09

14 Dec '09

I'm trying to install haskell-platform-2009.2.0.2 on OpenSuse 11.2 Gnu/Linux 2.6.27.39-0.2-default #1 SMP x86_64 My currently installed packages include ghc-6.10.4-5.7 freeglut-080721-20.2.1 ghc-GLUT-doc-2.1.2.0-1.13 ghc-GLUT-devel-2.1.2.0-1.13 ghc-GLUT-prof-2.1.2.0-1.13 When I try to ./configure I get checking GL/glut.h usability... no checking GL/glut.h presence... no checking for GL/glut.h... no configure: error: The GLUT C library is required One would think that with all of this good glut stuff I have installed the configure script would be satisfied, but it's not. Searching for answers only turned up other people with the same problem. Can someone assist me in fixing the problem? BTW - is there an official bug repository for the Haskell Platoform? I couldn't find that either, and I think it's very important! Thanks, _Greg P.S. In case it matters, here are most of my installed haskell packages: ghc-6.10.4-5.7 ghc-binary-devel-0.5.0.1-1.12 ghc-binary-doc-0.5.0.1-1.12 ghc-cairo-devel-0.10.1-1.4 ghc-data-accessor-devel-0.2.0.2-1.7 ghc-data-accessor-doc-0.2.0.2-1.7 ghc-data-accessor-monads-fd-devel-0.2-1.7 ghc-data-accessor-monads-fd-doc-0.2-1.7 ghc-data-accessor-template-devel-0.2.1.1-1.7 ghc-data-accessor-template-doc-0.2.1.1-1.7 ghc-derive-devel-0.1.4-2.55 ghc-derive-doc-0.1.4-2.55 ghc-Diff-devel-0.1.2-1.13 ghc-Diff-doc-0.1.2-1.13 ghc-doc-6.10.4-5.7 ghc-fingertree-devel-0.0-1.12 ghc-fingertree-doc-0.0-1.12 ghc-glib-devel-0.10.1-1.4 ghc-GLUT-devel-2.1.2.0-1.13 ghc-GLUT-doc-2.1.2.0-1.13 ghc-GLUT-prof-2.1.2.0-1.13 ghc-gtk2hs-common-0.10.1-1.4 ghc-gtk2hs-doc-0.10.1-1.4 ghc-gtk-devel-0.10.1-1.4 ghc-monads-fd-devel-0.0.0.1-1.9 ghc-monads-fd-doc-0.0.0.1-1.9 ghc-OpenGL-devel-2.2.2.0-1.15 ghc-OpenGL-doc-2.2.2.0-1.15 ghc-OpenGL-prof-2.2.2.0-1.15 ghc-paths-devel-0.1.0.5-19.14 ghc-paths-doc-0.1.0.5-19.14 ghc-pointedlist-devel-0.3.1-2.6 ghc-pointedlist-doc-0.3.1-2.6 ghc-prof-6.10.4-5.7 ghc-pureMD5-devel-0.2.4-1.7 ghc-pureMD5-doc-0.2.4-1.7 ghc-regex-tdfa-devel-1.1.1-1.10 ghc-regex-tdfa-doc-1.1.1-1.10 ghc-rosezipper-devel-0.1-1.7 ghc-rosezipper-doc-0.1-1.7 ghc-split-devel-0.1.1-1.12 ghc-split-doc-0.1.1-1.12 ghc-terminfo-devel-0.3.0.2-1.14 ghc-terminfo-doc-0.3.0.2-1.14 ghc-transformers-devel-0.1.4.0-1.12 ghc-transformers-doc-0.1.4.0-1.12 ghc-uniplate-devel-1.2.0.3-1.7 ghc-uniplate-doc-1.2.0.3-1.7 ghc-unix-compat-devel-0.1.2.1-1.14 ghc-unix-compat-doc-0.1.2.1-1.14 ghc-utf8-string-devel-0.3.4-1.14 ghc-utf8-string-doc-0.3.4-1.14 ghc-utility-ht-devel-0.0.4-1.7 ghc-utility-ht-doc-0.0.4-1.7 ghc-vty-devel-3.1.8.4-1.11 ghc-vty-doc-3.1.8.4-1.11 ghc-X11-devel-1.4.5-5.16 ghc-X11-doc-1.4.5-5.16 ghc-xmonad-contrib-devel-0.8.1-1.8 ghc-xmonad-contrib-doc-0.8.1-1.8 ghc-xmonad-devel-0.8.1-8.9 ghc-xmonad-doc-0.8.1-8.9 ghc-yi-devel-0.6.0-4.7 ghc-yi-doc-0.6.0-4.7

3 2

GHC 6.12 status and features
by Rafael Gustavo da Cunha Pereira Pinto 14 Dec '09

14 Dec '09

Hi folks, and specially Simon Marlow, I know I should probably be asking to the GHC list, but is there any update on 6.12 since October? Any probable release date? BTW, is there any feature list for the release? Thank all of you involved in bringing this new version to life. GHC rocks! Rafael Gustavo da Cunha Pereira Pinto

5 6

Hint causes GHCi linker error under Windows
by Martin Hofmann 14 Dec '09

14 Dec '09

The following hint code causes GHCi to crash under Windows: > runInterpreter $ loadModules ["SomeModule.hs"] The error message is: GHCi runtime linker: fatal error: I found a duplicate definition for symbol _hs_gtWord64 whilst processing object file C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0 HSghc-prim-0.1.0.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. The problem does not occur under Unix or with a compiled program. IMHO hint tries to start a second instance of GHCi which is not allowed/possible under Windows. If this is the case a more telling error message would be helpful. I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My package.conf is: C:/Programme/Haskell Platform/2009.2.0.2\package.conf: Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6, HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0, ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1, containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0, ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2, haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4, haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4, utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0 Thanks, Martin

2 3

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 14 Dec '09

14 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 14 Dec '09

14 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

"--" comments
by michael rice 12 Dec '09

12 Dec '09

I'm just noticing that "--" comments don't seem to work properly when the first character following them is a '*'. Michael --*I like asterisks --*I like asterisks --*I like asterisks --*I like asterisks double x = x+x Prelude> :l double [1 of 1] Compiling Main ( double.hs, interpreted ) double.hs:1:0: parse error on input `--*' Failed, modules loaded: none. Prelude>

4 5

wiki in hackage
by Andrew U. Frank 12 Dec '09

12 Dec '09

i think to add a wiki to each package is a great idea. as a default, it could be started automatically by uploading to hackage and filled with the readme.txt file (if availble) in the tar uploaded. if it is empty and exist, it is a point to check for when a package does not install immediately. alternatively, one has to search the web to see if there is some place with notices about this package. i would have loved to see wiki's for packages to post my result of work- arounds for problems with dependencies, small changes in source code etc. that could be posted there till the maintainer finds time to produce a new version. great idea! andrew frank

1 0

hledger 0.7 released
by Simon Michael 12 Dec '09

12 Dec '09

I'm pleased to announce hledger 0.7. Thanks to Marko Kocić who contributed many fixes for hlint warnings. To install/upgrade: cabal update && cabal install hledger [-fweb] [- fvty] Documentation: http://hledger.org Release notes: * price history support (first cut): P directives now work, though differently from c++ ledger. Each posting amount takes its fixed unit price from the price history (or @) when available. This is simple and useful for things like foreign currency expenses (but not investment tracking). Like ledger, balance and register don't show amount prices any more, and don't separate differently-priced amounts. Unlike ledger, print shows all amount prices, and supports -B. * --effective option, will use transactions' effective dates if any * convert: new rules file format, find/create rules file automatically, more robust parsing, more useful --debug output * print: always sort by date, fix long account name truncation, align amounts, show end of line comments, show all amounts for clarity (don't elide the final balancing amount) * ui: use vty 4, fixes non-ascii and gnome terminal problems (issues #3, #4) * web: allow data entry, react to data file changes, better layout, help links, remove histogram command and filter fields for now, fix bad localhost redirect, filter form did not work in eg firefox (issue #7), reset link did not work in all browsers * parsing: require whitespace between date and status code, allow (and ignore) a time in price records, better error messages, non-zero exit code on parse failure * display non-ascii error messages properly (issue #5) * fix an arithmetic bug that occasionally rejected valid transactions * fix a regex bug in showtree * don't break if HOME is undefined * --debug now implies --verbose * add functional tests like ledger's, use test-framework for speedy running, release shelltestrunner as a separate package * many hlint cleanups (Marko Kocić) * many site and documentation updates Stats: 2 contributors, 175 days since release, 182 commits, 3320 non-test code lines, 97 tests, 53% test coverage, performance: similar (http://hledger.org/profs/200912111852.bench) Best, -Simon

1 0

Re: [Haskell-cafe] Why?
by Janis Voigtländer 12 Dec '09

12 Dec '09

Andrew Coppin wrote: > On the other hand, turn up the optimisation settings on a C compiler > high enough and the program breaks. Somewhere the compiler elides a > second call to a function which actually happens to have some > side-effect that the compiler isn't aware of, and your stream is now one > byte out of alignment, or whatever. Fiddling with optimisation settings > in GHC may make your program slow to a crawl rather than go faster, but > it *never* makes it segfault on startup. Note, though, that "slow to crawl" may go as far as "not terminate". GHC's optimizer can make a terminating program nonterminating. For some discussion, see: http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#Discussi… In fact, one can also make up examples where turning on optimization lets GHC transform a "good" program into one halting with an arbitrary error (division by zero, say). The recipe for (artificial) such examples can be found in footnote 2 of: http://www.iai.uni-bonn.de/~jv/TUD-FI09-06.pdf The error "in the wild" that is mentioned on the wiki page occurred in the context of the stream fusion library development. Best regards, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de

1 0

Using Atom's task scheduler for existing C code.
by Tom Hawkins 12 Dec '09

12 Dec '09

Today we were working on integrating Atom code with some hand-written C, and one of my colleagues posed the question: Is it possible to use Atom just for its task scheduler for existing C code? This turns out to be very simple. It just requires a few combinators built on top of 'action'. -- Call a C function with type 'void f(void)'. call :: Name -> Atom () call n = action (\ _ -> n ++ "()") [] -- Call a C function in its own rule, atomically. callAtomic :: Name -> Atom () callAtomic n = atom n $ call n -- Call a C function atomically with a guard condition. callGuardedAtomic :: E Bool -> Name -> Atom () callGuardedAtomic g n = atom n (cond g >> call n) Then scheduling a collection of tasks becomes easy: -- 20 millisecond tasks. period 20 $ do callAtomic "task1" callAtomic "task2" -- 5 millisecond tasks. period 5 $ do callAtomic "task3" callAtomic "task4" -- 1 millisecond tasks. period 1 $ do callGuardedAtomic task5Ready "task5" callGuardedAtomic task6Ready "task6" I'll added these 'call' combinators in the next release of Atom.

1 0

ANNOUNCE: PCLT-0.1 and PCLT-DB-0.1
by Andrey Sisoyev 12 Dec '09

12 Dec '09

Hello, cafe! It's an honor for me to announce my first two packages, I developed in Haskell: ** http://hackage.haskell.org/package/PCLT ** http://hackage.haskell.org/package/PCLT-DB "PCLT" is an abbreviation for "Parametric Composable Localizable Templates" - in fact it should also hold Detalizable. Term "Detailizable content (message)" in this package has a following meaning: some content, representing which it is possible to regulate, in how much details it is represented. "Localizable" means "localizable in languages", which is "a message is available in multiple languages". "Composable" - it is possible to compose multiple templates into one. Conceptually, this package is a powerful extension to the well known Show class. Whenever you feel, that common Show is not enough for your needs, please consider using my PCLT. The extension is thought to be embedded in any Haskell program, which requires multilingual support, and/or where messages should be detailizable. PCLT-DB is an addon to PCLT, which enhances catalog with PostgreSQL powers. ER diagram: http://i1.fastpic.ru/big/2009/1212/f0/5b9845716e5a6984e9bc9d62a61928f0.png Both packages are well documented, has "Hello World" examples, and are selfexamples - the PCLT errors representations are available in two languages: English and Russian. Used license: LGPL. Regards, Andrey Sisoyev -- View this message in context: http://old.nabble.com/ANNOUNCE%3A-PCLT-0.1-and-PCLT-DB-0.1-tp26754004p26754… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 0

Will GHC finally support epoll in 2009?
by Levi Greenspan 11 Dec '09

11 Dec '09

Ticket #635 "Replace use of select() in the I/O manager with epoll/kqueue/etc." (http://hackage.haskell.org/trac/ghc/ticket/635) dates back from 2005. Now its 2009 and GHC can handle hundreds of thousands of threads, yet having more than 1024 file descriptors open is still impossible. This limitation is a real bottle neck and prevents some cool developments on server side, like scalable comet servers. Instead others (e.g. Erlang guys) post stories about how they achived 1 million comet users (cf. http://www.metabrew.com/article/a-million-user-comet-application-with-mochi… ). Hence my question - is it likely that GHC will support epoll in 2009? Cheers and happy new year! - Levi

6 11

Re: Type system speculation
by oleg＠okmij.org 11 Dec '09

11 Dec '09

Andrew Coppin wrote: > What we're really trying to do here is attach additional information to a > value - information which exists only in the type checker's head, but has no > effect on runtime behaviour (other than determining whether we *get* to > runtime). As far as I can tell, Haskell does not provide any way to take an > existing type and attach additional information to it in such a way that > code which cares about the new information can make use of it, but existing > code which doesn't care continues to work. Any comments on this one? Haskell has had the ability to attach arbitrary many pieces of (type-level) data to arbitrary types for a long time -- ever since multi-parameter type classes and functional dependencies have been introduced. Nowadays, type families accomplish the same with fewer keystrokes. One merely needs to define a type family type family Attrib n index :: * which maps the existing type n and the index to an arbitrary type. Chung-chieh Shan and I have explored the technique to annotate data types with attributes describing alignment of the corresponding data, location in ROM or RAM, etc. http://okmij.org/ftp/Haskell/types.html#ls-resources Here is a sample annotation, from http://okmij.org/ftp/Computation/resource-aware-prog/VideoRAM.hs -- A Screen on old PC type ScreenCharT = Pair AWord8 AWord8 -- attribute and char proper scrchar_attr r = afst r scrchar_char r = asnd r type ScreenT = Array N25 (Array N80 ScreenCharT) data Screen = Screen instance Property Screen APInHeap HTrue instance Property Screen APARef (ARef N8 ScreenT) instance Property Screen APReadOnly HFalse instance Property Screen APOverlayOK HTrue -- many more can be added, perhaps in other modules type SmallScreenT = Array N5 (Array N80 ScreenCharT) -- we can place the Screen area at a fixed absolute address data ScreenAbs = ScreenAbs instance Property ScreenAbs APInHeap HFalse instance Property ScreenAbs APARef (ARef N8 ScreenT) instance Property ScreenAbs APReadOnly HFalse instance Property ScreenAbs APFixedAddr HTrue If we forget to assign property APReadOnly=HFalse, an operation write_area that uses a pointer in the area raises a type error.

4 3

SmallCheck design question
by Johannes Waldmann 11 Dec '09

11 Dec '09

referring to the Serial instances in http://hackage.haskell.org/package/smallcheck : the idea is that series d gives all objects of depth <= d. depth of a term from an algebraic data type is the standard "depth" concept for trees (maximum nesting of constructors = longest path from root to node) 1. why are the tuple constructors treated differently? I'd expect depth (x,y) = succ $ max (depth x) (depth y) but the succ is missing. 2. why depth and not size (= total number of constructors)? it seems that the number of objects (trees) of given depth rises much more drastically than number of trees of given size. just wondering - J.W.

2 2

Fwd: [Haskell-cafe] Re: Why?
by Alberto G. Corona 11 Dec '09

11 Dec '09

What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Here is my list of benefits of purity (some of them are enhanced by other features like the type system). Purity means referential transparency. that means that the programmer has no way to modify pure data. That cut the tree of possible programmer errors.In particular, since there are no variables, every state change must be in the form o a call to a function with new parameters. each function has no state change (except when needed and then the type system labels the stateful code as such)( This enforcement goes in the righ direction for clarity and readability, maintainability, modularity xxxxxbility. Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors. Purity permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed. Lazy evaluation eases mathematical reasoning,because mathematics has no notion of eager evaluation, but to make use of mathematical equations when the calculation is needed. . Mathematical reasoning permits the full use of a long tradition of mathematical knowledge. This makes code more simple, understandable, general, proof guarantted and elegant (for those that know the mathematical domain). This also permits high level optimization of code, both by the programmer and the compiler. for sure there are a few more We are superstitious and guided by "nonrational" ideas such is beauty. but: bauauty -> (simplicity -> (less effort to master, less errors) , utility ->, solve more problems, solve greater problems )

5 6

lhs2tex + pretty print
by rodrigo.bonifacio 10 Dec '09

10 Dec '09

2 1

Finding substantial examples of Cabal Setup files
by Jon Strait 10 Dec '09

10 Dec '09

Hi all, I was looking through some of the Hackage packages to find examples of how developers are extending UserHooks in their Setup files, but it wasn't easy, since the great majority of Cabal Setup files in Hackage simply require only the standard line of 'main = defaultMain' or 'defaultMainWithHooks' with a standard UserHooks value. So, I started hacking together a little Emacs Lisp script to walk through all the packages in the Hackage archive and report on the Setup files that looked interesting enough to serve as non-trivial examples. Here is the latest result: http://www.moonloop.net/haskell/docs/cbs-custom.html Jon

1 0

ANNOUNCE: unicode-symbols-0.1.1
by Roel van Dijk 10 Dec '09

10 Dec '09

Hello, I would like the announce the release of my package unicode-symbols: http://hackage.haskell.org/package/unicode-symbols It offers alternative symbols for a number of common functions and operators from the base and containers packages. When used in combination with the language extension UnicodeSyntax you can write really nice code. The only thing missing is a nice λ symbol. The documentation on hackage should be pretty self explanatory. For each symbol the documentation gives its exact definition. The source code however, probably due to a bug in hscolour, is totally unreadable. To view the sources simply download the package and use a text editor. I tried to be conservative with the choice of unicode symbols. I have defined the division sign (÷) to be (/). But it could just as well be defined as 'div'. I do not know what would be the logical choice. Another choice that could lead to some discussion is the definition of (⊂) to be 'Data.Set.isProperSubsetOf' and (⊆) to be 'Data.Set.isSubsetOf'. An alternative choice would be to have (⊊) for 'isProperSubsetOf' and (⊂) for 'isSubsetOf'. I choose the former because it is more symmetrical with (<) and (≤). This package was inspired by unicode-prelude from Péter Diviánszky: http://hackage.haskell.org/package/unicode-prelude Regards, Roel van Dijk

3 3

Re: Why?
by Casey Hawthorne 10 Dec '09

10 Dec '09

I have not read all/most of the replies. >What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction. A pure functional lanugage allows lazy evaluation, which adds another tool to your modularity toolbox, since it separates control from computation. In a pure functional language state is very carefully isolated from the rest of your program. This makes all sorts of optimizations trivial that are very hard to do in other languages. Optimizations are done in "code algebra", which is very easy to do in Haskell (for pure functions), for example optimizations are harder to do in the "code algebra" of Java. For a better discussion of "code algbra" please see the following book: "Practical Formal Software Engineering: Wanting the Software You Get" Bruce Mills, 2009 -- Regards, Casey

1 0

Re: [Haskell-cafe] Re: Why?
by David Leimbach 10 Dec '09

10 Dec '09

On Thu, Dec 10, 2009 at 6:31 AM, Alberto G. Corona <agocorona(a)gmail.com>wrote: > My understanding is that a pointer to the lazy expression tree for the > calcualtion of the parameter is put it the corresponding location of the > function expression tree. But at any time you can force the evauation before > the call. or the compiler itself. Optimization is possible depending on the > knowledge. What happens if the parameter is an infinite list and the > function handles a few items of it?. > > All of these consideration pales when a programmer has to call a procdure > in a library made by others with no documentation, and no clue about what > the procedure does inside. The purity and the type system removes many > concerns. > That's not a "safe" way to think of 3rd party libraries. It is a convenient claim for promoting the language, and is probably more often than not the case though it does not quite capture the whole truth. unsafePerformIO can exist in any library you import, and while you may think it's pure, you still have to implicitly trust the library writers (unless you bother to look at the source). Take Debug.Trace.trace for example, it's a pure computation, yet causes side effects. Yes, it's a controlled side effect, but a polluted version of the same function signature could "launch the missles" while looking like the function is synonymous with "id". In short unsafePerformIO, while it's "supposed to be" avoided, may not be avoided as much as the advice given to do so :-). Might be interesting to see how many occurrences of unsafePerformIO exist in hackage. I fully realize that someone will probably claim I'm taking this position to the extreme, but I think we're tempted to pretend that all functions with pure signatures are always safe which is another kind of extreme when you consider the existence of backdoors to the Monads that provide the guarantees we're clinging to to talk about how great Haskell is. I think the existence of unsafePerformIO is a bit of an admission that there's some things yet to be figured out to make this system 100% consistent with where we want pure functional programming to be. Dave > > 2009/12/10 David Leimbach <leimy2k(a)gmail.com> > > And that would be true if everything were strict and not partially >> evaluated sometimes :-) >> >> My understanding is the following... (and I could be way off) >> >> Remember that a function of arity N is really N functions of arity 1 with >> their arguments bound one at a time to create a new function along the way. >> At least you *can* write your code that way if you really want to, but the >> laziness might make it such that all the parameters are not bound, due to >> not being "needed" at that moment. Instead a thunk or what some other >> languages might call a "Future" is put in the argument's place, to be >> evaluated when needed. >> >> If Haskell were strict by default, I think your claim of passing >> references around could be true, but my experience with Haskell has been >> that sometimes it's too lazy for me to write the code that I first thought >> would be efficient without a lot f study and refactoring of that code. >> >> I'm sure this gets easier with practice, but it's not something I was >> expecting to be as difficult as it all was. >> >> Dave >> >> On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona <agocorona(a)gmail.com>wrote: >> >>> One more advantage that is not frequently cited >>> >>> Purity permits to pass every parameter of a procedure by reference >>> (giving the pointer) rather that by value giving a copy, and still be sure >>> that the data has not been modified. Besides the safety. this is great >>> language optimization itself. >>> >>> 2009/12/10 Alberto G. Corona <agocorona(a)gmail.com> >>> >>> >>>> >>>> >>>> What material benefit does Haskell derive from being a "pure" >>>> functional language as opposed to an impure one? >>>> >>>> >>>> >>>> Here is my list of benefits of purity (some of them are enhanced by >>>> other features like the type system). >>>> >>>> Purity means referential transparency. that means that the programmer >>>> has no way to modify pure data. That cut the tree of possible programmer >>>> errors.In particular, since there are no variables, every state change must >>>> be in the form o a call to a function with new parameters. each function has >>>> no state change (except when needed and then the type system labels the >>>> stateful code as such)( This enforcement goes in the righ direction for >>>> clarity and readability, maintainability, modularity xxxxxbility. >>>> >>>> Purity also eases paralel processing, since no data is modified, each >>>> process is isolated better. Less opportunities for errors. >>>> >>>> Purity permits lazines because since the execution tree of >>>> an expression has pure, data, can be evaluated later, since it will not be >>>> changed. >>>> >>>> Lazy evaluation eases mathematical reasoning,because mathematics has no >>>> notion of eager evaluation, but to make use of mathematical equations when >>>> the calculation is needed. . >>>> >>>> Mathematical reasoning permits the full use of a long tradition of >>>> mathematical knowledge. This makes code more simple, understandable, >>>> general, proof guarantted and elegant (for those that know the mathematical >>>> domain). This also permits high level optimization of code, both by the >>>> programmer and the compiler. >>>> >>>> for sure there are a few more >>>> >>>> We are superstitious and guided by "nonrational" ideas such is beauty. >>>> but: >>>> >>>> bauauty -> (simplicity -> (less effort to master, less errors) >>>> , utility ->, solve more problems, solve greater >>>> problems >>>> ) >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >

2 3

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

My intuition says that laziness and purity are distinct whereas yours says that purity is a necessary condition. This is what needs to be reconciled. I believe that everyone is thinking that lazy evaluation and strict evaluation are similar activities whereas they are profoundly different.

8 9

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

I'm going to try to respond to your letters later on when I have more time. This break may also be useful in that it may help the conversation from becoming overheated. I stopped in the middle of a letter and put it in the draft folder so that I could give it greater attention. I was writing it out too quickly. I was responding to Job Vranish. I was responding to his "Though I'm curious as to how a language could be effect free in a practical sense, but not a strict one? could you give an example?" query. My response is already fleshed out. I just have to polish it. Cheers

1 0

Re: Nano-Languages
by John D. Earle 10 Dec '09

10 Dec '09

Earlier in this thread I wrote "... but like so what." In this letter I hope to address what I wrote more fully. The command line option that was found that allows for Haskell source code to be preprocessed accepts a Haskell source code file as an argument. This file defines a preprocessor. It seems to me that such a preprocessor would be undisciplined and capable of wrong doing because the Haskell language does not have all the facilities that a utility such as Happy possesses. Care is needed. It also lacks those facilities that are particular to preprocessors. The paper at http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf may provide a means to introduce this needed discipline. I do not see how the runtime verses compile time distinction is important, however. You can't really hand craft a preprocessor on the fly that is going to work. I do not believe the paper is explaining itself all that well. What they are referring to as syntax macros given a superficial examination of the paper seem to be the functional language equivalent of a definite clause grammar found in Prolog. So it seems that an effort to bring that goodness that Prolog programmers have enjoyed for years over to Haskell and perhaps to do one or two better. Their emphasis on runtime verses compile time seems like a distraction in that it is merely a necessary condition for inclusion into the Haskell language since Haskell is both compiled and interpreted. It is a problem that would need to be solved. They may have lost sight of what they were doing after having spent so much time working on just this one aspect. Haskell at the present time need external tools. The benefits of bringing in that sort of functionality into the language I would regard as self-evident. It is still a bottom up approach, but a bottom up approach would be easier to implement and it would be desirable for the two worlds to meet, the bottom up and the top down. An important question will be, Will syntax macros work out better than an existing tool such as Happy?

2 5

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

To elaborate there is another language that is also a functional language. I won't mention the name so as not to offend anyone. It too is effect free, that is what makes it functional and it is a functional language in the true sense of the term, but it is not effect free in the sense that Haskell is effect free. This other language is effect free in every practical sense whereas Haskell is effect free in a strict sense.

5 4

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

What I think might be confusing the situation partially is that there is a difference between the language and its implementation. Any side effect would have been accounted for even though there is a means to side step it and its inclusion may have been perceived as a undesirable and perhaps unnecessary complication. To put it bluntly, it is like how division by zero can be inconvenient.

1 0

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

So my question is, Did the leap from effect free for all practical purposes to effect free in a strict sense yield any material benefits?

1 0

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

Laziness is on the logic front end and purity is on the execution back end.

2 1

Re: Why
by John D. Earle 10 Dec '09

10 Dec '09

Laziness is on the logic front end and purity is on the execution back end.

1 0

Natural Language Processing
by John D. Earle 10 Dec '09

10 Dec '09

Is Parsec capable of parsing a mildly context sensitive language? In particular does it parse a combinatory categorial grammar? Does Haskell have such tools in its shed? What sort of facilities does Haskell have for natural language processing?

5 5

Fwd: [Haskell-cafe] Re: Why?
by Alberto G. Corona 10 Dec '09

10 Dec '09

My understanding is that a pointer to the lazy expression tree for the calcualtion of the parameter is put it the corresponding location of the function expression tree. But at any time you can force the evauation before the call. or the compiler itself. Optimization is possible depending on the knowledge. What happens if the parameter is a large list and the function handles a few elements?. All of these consideration pales when a programmer has to call a procedure in a library made by others with no documentation, and no clue about what the procedure does inside. The purity and the type system removes many concerns. 2009/12/10 David Leimbach <leimy2k(a)gmail.com> And that would be true if everything were strict and not partially evaluated > sometimes :-) > > My understanding is the following... (and I could be way off) > > Remember that a function of arity N is really N functions of arity 1 with > their arguments bound one at a time to create a new function along the way. > At least you *can* write your code that way if you really want to, but the > laziness might make it such that all the parameters are not bound, due to > not being "needed" at that moment. Instead a thunk or what some other > languages might call a "Future" is put in the argument's place, to be > evaluated when needed. > > If Haskell were strict by default, I think your claim of passing references > around could be true, but my experience with Haskell has been that sometimes > it's too lazy for me to write the code that I first thought would be > efficient without a lot f study and refactoring of that code. > > I'm sure this gets easier with practice, but it's not something I was > expecting to be as difficult as it all was. > > Dave > > On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona <agocorona(a)gmail.com>wrote: > >> One more advantage that is not frequently cited >> >> Purity permits to pass every parameter of a procedure by reference >> (giving the pointer) rather that by value giving a copy, and still be sure >> that the data has not been modified. Besides the safety. this is great >> language optimization itself. >> >> 2009/12/10 Alberto G. Corona <agocorona(a)gmail.com> >> >> >>> >>> >>> What material benefit does Haskell derive from being a "pure" functional >>> language as opposed to an impure one? >>> >>> >>> >>> Here is my list of benefits of purity (some of them are enhanced by other >>> features like the type system). >>> >>> Purity means referential transparency. that means that the programmer >>> has no way to modify pure data. That cut the tree of possible programmer >>> errors.In particular, since there are no variables, every state change must >>> be in the form o a call to a function with new parameters. each function has >>> no state change (except when needed and then the type system labels the >>> stateful code as such)( This enforcement goes in the righ direction for >>> clarity and readability, maintainability, modularity xxxxxbility. >>> >>> Purity also eases paralel processing, since no data is modified, each >>> process is isolated better. Less opportunities for errors. >>> >>> Purity permits lazines because since the execution tree of >>> an expression has pure, data, can be evaluated later, since it will not be >>> changed. >>> >>> Lazy evaluation eases mathematical reasoning,because mathematics has no >>> notion of eager evaluation, but to make use of mathematical equations when >>> the calculation is needed. . >>> >>> Mathematical reasoning permits the full use of a long tradition of >>> mathematical knowledge. This makes code more simple, understandable, >>> general, proof guarantted and elegant (for those that know the mathematical >>> domain). This also permits high level optimization of code, both by the >>> programmer and the compiler. >>> >>> for sure there are a few more >>> >>> We are superstitious and guided by "nonrational" ideas such is beauty. >>> but: >>> >>> bauauty -> (simplicity -> (less effort to master, less errors) >>> , utility ->, solve more problems, solve greater >>> problems >>> ) >>> >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >

1 0

Parsec-like parser combinator that handles left recursion?
by oleg＠okmij.org 10 Dec '09

10 Dec '09

There are at least two parser combinator libraries that can deal with *any* left-recursive grammars. That said, Prof. Swierstra's advice to try to get rid of left recursion is still well worth to follow. The first library is described in Frost, Richard, Hafiz, Rahmatullah, and Callaghan, Paul. Parser Combinators for Ambiguous Left-Recursive Grammars. PADL2008. http://cs.uwindsor.ca/~richard/PUBLICATIONS/PADL_08.pdf It handles arbitrary left-recursive grammars, including eps-cycles. It copes with highly ambiguous grammars. It can produce all parses of the input sequence. It parses the input in O(n^4) time with respect to the size of the input. I have tried dealing with left-recursive grammars and too wrote a parser combinator library: http://okmij.org/ftp/Haskell/LeftRecursion.hs It can handle eps-cycles, ambiguity and other pathology. Here is a sample bad grammar: S -> S A C | C A -> B | aCa B -> B C -> b | C A The library is pure and uses no state (monad). Strictly speaking, the library produces a recognizer rather than a parser, or a recognizer that yields a list of fired productions. There are standard ways however to `lift' a recognizer to produce a parse tree. The library is far simpler than than of Frost et al, and does not require explicit labeling of productions. Although the library can be faster than Frost's et al when a parse exists, it currently can be far slower when no parse exists. (It still assuredly terminates.) Both libraries require that the whole input be known in advance: neither library does on-line parsing. The reason has to do with memoization and with the cut-off for the recursion (a productive left-recursive rule shouldn't be applied more times than there are characters in the input). That is quite a disappointment. Therefore, it is well worth to convert the left recursion away, as was described in Doaitse Swierstra's earlier message.

2 1

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

While going through the Haskell literature I uncovered a passage that said that, I'm paraphrasing: Complexity was at a premium. The task was very complex and what was needed to get Haskell to achieve its goals was extraordinary. This might explain how laziness kept Haskell pure. Everything was at a premium and this developed a discipline to keep everything streamlined. This suggests that purity had a material benefit, but the problem is it is conceivable that its material benefit was merely psychological. I do not have enough time to study what Stephen wrote at the moment so I will need to revisit it. He cited some references.

1 0

Haskell and sockets
by Johann Höchtl 10 Dec '09

10 Dec '09

Hello, How does Haskell handle sockets? Is it using select or epoll? I ask especially in regard to http://groups.google.com/group/erlang-programming/browse_frm/thread/a73efeb… Regards, Johann

2 2

Re: Allowing hyphens in identifiers
by John D. Earle 10 Dec '09

10 Dec '09

To Underscore or Not to Underscore Richard O'Keefe and I were privately discussing the relative merits of his and my approach. We have come to an agreement. It concerns whether or not hyphens should be replaced with underscores. The following is my response to his most recent letter: I do not believe your approach given what you wrote here will create the sort of ambiguity I feared could be introduced. If an ambiguity results, it could be fixed. As I would put it, you hope to harmonize the word breaking styles by a process similar to though slightly more involved than what is done to remove case sensitivity in some languages. As layout is concerned only leading white space needs to be preserved. Anything else could be regarded as a superstition (not to say that computer scientists are superstitious). What you hope to do is kill two birds with one stone. If the only goal is to run everything through a preprocessor my approach seems to make the greatest sense, but if you also hope to harmonize the representation of word breaking styles, then what you are advocating seems to make greater sense. Your approach seems more consistent with Haskell traditions than mine. Therefore, I concede. You have successfully argued your point.

1 0

Handles with their IOMode in their type
by Bas van Dijk 10 Dec '09

10 Dec '09

Could not get to sleep tonight so I got up and hacked this together: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 Does something like this already exist on hackage: If not, I may turn this into a package and upload it tomorrow. Comments, criticism and patches are welcome. regards, Bas

4 4

Type system speculation
by Andrew Coppin 10 Dec '09

10 Dec '09

People in the Haskell community get awfully excited about Haskell's type system. When I was first learning Haskell, I found this rather odd. After all, a "type" is just a flat name that tells the compiler how many bits to allocate and which operations to allow, right? As I read further, I quickly discovered that in Haskell, the type system is something much more powerful. In a normal language, the type system prevents you from accidentally trying to multiply a string by a binary tree of integers, or pass a function an signed integer when it's expecting an unsigned integer. But in Haskell, the combination of parametric polymorphism, typeclasses and automatic type inference combine to form a potent mixture. Even without any exotic language extensions, in Haskell you can use the type system to *prove stuff about your programs*! And not necessary stuff that's anything to do with the usual notion of a "data type". You can prove that lists are non-empty or even of a specific size. You can prove that optional values get checked before they are used. And you can prove that user input is sanitised before being passed to sensitive functions. (Or rather, you can make your program simply not compile if the required properties are not guaranteed.) Let's take an example. Suppose you have some functions that obtain input from a user, and you have some other functions that do something with this data. What you can do is something like this: newtype Data x y = Data x data Checked data Unchecked check_string :: Data String Unchecked -> Data String Checked Now make it so that everything that obtains data from the user returns Data String Unchecked, and everything that uses a string to do something potentially hazardous demands Data String Checked. (And any functions that don't care whether the string is checked or not can just use Data String x.) Only one problem: Any functions that expect a plain String now won't work. Particularly, the entirity of Data.List will refuse to accept this stuff. Which is kind of galling, considering that a Data String Checked *is* a String! What we're really trying to do here is attach additional information to a value - information which exists only in the type checker's head, but has no effect on runtime behaviour (other than determining whether we *get* to runtime). As far as I can tell, Haskell does not provide any way to take an existing type and attach additional information to it in such a way that code which cares about the new information can make use of it, but existing code which doesn't care continues to work. Any comments on this one? On a rather unrelated note, I found myself thinking about the Type Families extension (or whatever the hell it's called). I found that I can do this: class Collection c where type Element c :: * empty :: c first :: c -> Maybe (Element c) ... This works for collections that can contain *anything*: instance Collection [x] where type Element [x] = x ... It works for collections that can only contain *one* type: instance Collection ByteString where type Element ByteString = Word8 ... And it works for collections that can handle more than one type, but less than *every* type: instance Ord x => Collection (Set x) where type Element (Set x) = x ... Something quite interesting is happening here: this "Element" thing is almost like a *function* which takes one type and returns another. A function that operates on types themselves. Now suppose I want to write a function that converts one kind of collection into another: convert :: (Collection c1, Collection c2) => c1 -> c2 Erm, no. That doesn't work AT ALL. What we want to say is that the element types are constrained (specifically, they're identical). I searched for quite some time looking for a way to say this. In the end, I gave up and let the compiler deduce the type signature automatically. Apparently the correct signature is convert :: (Collection c1, Collection c2, Element c1 ~ Element c2) => c1 -> c2 Apparently the bizare syntax "Element c1 ~ Element c2" means that these two types are supposed to be equal. (Why not just an equals sign?) This got me thinking... Maybe what we'd really like to say is something like convert :: (Collection c1 {Element = x}, Collection c2 {Element = x}) => c1 -> c2 In other words, make the assosiated type like a named field of the class, using syntax similar to the named fields that values can have. And then, if we can do it to classes, why not types? data Map {keys :: *, values :: *} = ... insert :: (Ord k) => k -> v -> Map {keys = k, values = v} -> Map {keys = k, values = v} Now, it seems reasonable that if one of the type fields is unconstrained, you do not need to mention it: keys :: (Ord k) => Map {keys = k} -> [k] values :: Map {values = v} -> [v] If we can have some mechanism for adding new type fields to an existing type, we are one step away from the problem at the beginning. You could take the existing String type, and add (by whatever the mechanism is) a new "safety" field to it. All of Data.List ignores this field, but any new code you write can choose to use it if required. At least, that's my vague idea. Anybody like it? (My first thought is that "Map {keys = k, values = v}" is going to start getting tedious to type very, very quickly. Perhaps we should do something like values :: (m :: Map {values = v}) => m -> [v], or even allow values :: (m :: Map {}) => m -> [values m] as an alternative? IDK.) So there you have it. Multiple paragraphs of semi-directed rambling about type systems. All written by somebody who doesn't even know what a Skolem variable is. :-}

3 2