- Haskell-Cafe - Haskell.org

Re: Case-insensitive lexing with Alex
by Joel Reymont 28 Jan '08

28 Jan '08

On Jan 28, 2008, at 2:44 PM, Geoffrey Mainland wrote: > map toLower onto your input before you pass it to your lexer? Or do > you > only want keywords to be case-insensitive? Just keywords. You can have "Array" or "array" or "aRrAy". -- http://wagerlabs.com

2 1

Fusion of lists and chunky sequences
by Henning Thielemann 28 Jan '08

28 Jan '08

On the one hand I like to use lists in my code because element types can be freely chosen and maximum laziness allows feedback and other tricks. On the other hand there are ByteString.Lazy and one could build chunky sequences from other fast array implementations. They have constraints on the element types like Storable in http://code.haskell.org/~sjanssen/storablevector and IArray multi-parameter type class for UArray. I like to continue writing code for lists, and let the optimizer replace it by operations on chunky sequences whereever possible. E.g. Chunky.fromList (List.map f (List.unfoldr g x)) might be transformed to Chunky.unfoldr (f ... g) x Chunky.fromList serves two purposes: 1. I obtain the result in a data structure that can be quickly accessed by further operations. 2. It tells the optimizer that element granularity for laziness is not needed and that the element type fulfills the constraint of the fast array type, and thus fusion can go on safely. (As far as I can see.) Is there some framework which fuses lists and chunky sequences? When writing fusion rules like the above one by myself, then they interfer with Prelude's fusion rules (and they would probably also interfer with those of an alternative list fusion framework). The 'map' and 'unfoldr' is certainly already fused to the internal 'build' or to another auxiliary function. As far as I know, I cannot disable the Prelude rules and give the List-Chunk rules priority higher than Prelude's ones. I hoped to be able to apply application specific fusion rules by defining a newtype wrapper around the chunky sequence type, while keeping the rest of the list code unchanged. You might argue, that code cannot be application specific if it still relies on the generic list type. Maybe it's the best to wrap the list type in a newtype and lift all of the application relevant list functions to this type and then define fusion rules on the lifted functions.

4 14

Why functional programming matters
by Simon Peyton-Jones 28 Jan '08

28 Jan '08

Friends Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important. If you like, it's the same general goal as John Hughes's famous paper "Why functional programming matters". Audience: some are technical managers, some are professional programmers; but my base assumption is that none already know anything much about functional programming. Now, I can easily rant on about the glories of functional programming, but I'm a biased witness -- I've been doing this stuff too long. So this message is ask your help, especially if you are someone who has a somewhat-recent recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc". I'm going to say some general things, of course, about purity and effects, modularity, types, testing, reasoning, parallelism and so on. But I hate general waffle, so I want to give concrete evidence, and that is what I particularly want your help with. I'm thinking of two sorts of "evidence": 1. Small examples of actual code. The goal here is (a) to convey a visceral idea of what functional programming *is*, rather than just assume the audience knows (they don't), and (b) to convey an idea of why it might be good. One of my favourite examples is quicksort, for reasons explained here: http://haskell.org/haskellwiki/Introduction#What.27s_good_about_functional_… But I'm sure that you each have a personal favourite or two. Would you like to send them to me, along with a paragraph or two about why you found it compelling? For this purpose, a dozen lines of code or so is probably a maximum. 2. War stories from real life. eg "In company X in 2004 they rewrote their application in Haskell/Caml with result Y". Again, for my purpose I can't tell very long stories; but your message can give a bit more detail than one might actually give in a presentation. The more concrete and specific, the better. E.g. what, exactly, about using a functional language made it a win for you? If you just reply to me, with evidence of either kind, I'll glue it together (regardless of whether I find I can use it in my talks), and put the result on a Wiki page somewhere. In both cases pointers to blog entries are fine. Quite a lot of this is FP-ish rather than Haskell-ish, but I'm consulting the Haskell mailing lists first because I think you'll give me plenty to go on; and because at least one of the talks *is* Haskell-specific. However, feel free to reply in F# or Caml if that's easier for you. Thanks! Simon

41 69

Case-insensitive lexing with Alex
by Joel Reymont 28 Jan '08

28 Jan '08

Any suggestions on how to implement case-insensitive lexing with Alex? Thanks, Joel -- http://wagerlabs.com

1 0

Upgrading ByteString causes (seemingly) impossible RTS linker errs
by Austin Seipp 27 Jan '08

27 Jan '08

Recently I've been developing my IRC bot a little further, and in the midst of it I have come across a very problematic issue that revolves around GHC-dependencies vs. application-dependencies. The central issue is ByteString. Currently, the ghc package depends on bytestring-0.9.0.1. However, the current version of ByteString I have installed is 0.9.0.4. To keep compatability with bytestring-dependent libraries that were built against 0.9.0.1, you have to recompile of all these libs against 0.9.0.4. For example, I had to build a newer version of zlib against 0.9.0.4, because the older version was built for 0.9.0.1, which mean that it was not possible to build cabal-install because of the incompatabilities (it needed bytestring and zlib.) The problem is that if you have a package that depends on ghc as a library, but also depends on bytestring > 0.9.0.1 or any library built against it, you'll get pretty much unstoppable linker errs, since all the symbol names in the ghc package are hardwired for 0.9.0.1 (meaning you can't do 'ghc-pkg update' for it) forcing it to be loaded. The example in my bot is this: it depends on binary which is built against bytestring-0.9.0.4 for serializing the state of plugins. If you configure it with the flag '-fdynamic' and you have hs-plugins for ghc 6.8 installed (http://code.haskell.org/~dons/code/hs-plugins/) then the bot can do in-situ code reloading. However, hs-plugins depends on ghc as a library, which depends on bytestring 0.9.0.1... I think you can see where this is going (actually I can't quite pinpoint it to being hs-plugins importing ghc since, but essentially it could be *any* lib my bot uses which depends on ghc as a library, hs-plugins is just the most obvious one): [austin@continuum 0.4]$ ghci Setup.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. ... *Main> :main configure Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package unix-2.3.0.0 ... linking ... done. Loading package process-1.0.0.0 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package hpc-0.5.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0.1.0 ... linking ... done. Loading package Cabal-1.2.3.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package parsec-2.1.0.0 ... linking ... done. Loading package haskell-src-1.0.1.1 ... linking ... done. Loading package network-2.1.0.0 ... linking ... done. Loading package mtl-1.1.0.0 ... linking ... done. Loading package stm-2.1.1.0 ... linking ... done. Loading package irc-0.4 ... linking ... done. Loading package QuickCheck-2.0 ... linking ... done. Loading package bytestring-0.9.0.4 ... linking ... done. <-- needed for binary Loading package binary-0.4.1 ... linking ... done. Loading package bytestring-0.9.0.1 ... <-- needed for ghc GHCi runtime linker: fatal error: I found a duplicate definition for symbol fps_maximum whilst processing object file /usr/local/lib/ghc-6.8.2/lib/bytestring-0.9.0.1/HSbytestring-0.9.0.1.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. [austin@continuum 0.4]$ >From speculation, I would think that any package that uses ghc as a library but also uses bytestring > 0.9.0.1, directly or indirectly, would hit this error. Is there any easy way to resolve this? From the looks of it, the *only* way would really be to just unregister 0.9.0.4, and rebuild everything against 0.9.0.1... Either that or factor out the use of ByteString in the ghc-frontend. Neither seems optimal, though. But I've been working on this too long to just stop, so if it requires recompiling everything against an older version of bytestring, then so be it, I suppose... Thanks for whoever helps. - Austin -- "It was in the days of the rains that their prayers went up, not from the fingering of knotted prayer cords or the spinning of prayer wheels, but from the great pray-machine in the monastery of Ratri, goddess of the Night." Roger Zelazny

4 3

ANNOUNCE: xmonad 0.6 released
by Don Stewart 27 Jan '08

27 Jan '08

The xmonad dev team is pleased to announce the 0.6 release of xmonad! http://xmonad.org xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is extensible in Haskell, allowing for powerful customisation. Custom layout algorithms, key bindings and other extensions may be written by the user in config files. Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several physical screens. Features: * Very stable, fast, small and simple. * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating windows * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Easy, powerful customisation and reconfiguration in Haskell * Large extension library * Extensive documentation and support for hacking Get it! Information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.6 release, and its dependencies, are available from hackage.haskell.org, here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad Headlines: This is an incremental release of xmonad, with some new features, and important bug fixes. * Make focus-follows-mouse configurable * Better support for X11 cloned screens * xmonad config dirs can now be shared across architectures * New flags: --version: print xmonad's version --recompile: recompile xmonad.hs if it is out of date --force-recompile: recompile xmonad.hs unconditionally * Improved ManageDocks extension used for docking programs * Improved documentation * Update to Haskell X11-1.4.1, fixes bug with XGetWindowProperty * Close bug #96 relating to window unmapping (fixes gnucash bugs) * 'Testing' mode for developers * Various other fixes and clean ups. Along with many improvements to the extension library. Here are some of the noticeable changes to the extension library: * New: XMonad.Hooks.ManageHelpers : support for hooks * New: XMonad.Util.Search : support for web searching * New: XMonad.Util.Timer : set up timers and to handle them * New: XMonad.Layout.Reflect : reflect layouts horizontally/vertically * New: XMonad.Actions.NoBorders * Improved EDSL for performing actions on windows * Improved window tabbing * ResizableTile works with floating windows * Faster prompts * More EWHM support * Add support for cycling through screens to CycleWS * UrgencyHook support to status bar * Custom zoom levels for magnifier layout * Bug fixes to ManageDocks * Support for _NET_WM_STRUT_PARTIAL * Improved docs for writing new extensions Full changelogs against xmonad 0.5 for the core and extensions here: http://xmonad.org/changelog-0.6.txt http://xmonad.org/changelog-xmc-0.6.txt Extensions: xmonad comes with a huge library of extensions (now more than 5 times the size of xmonad), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. For more information on using and writing extensions see the webpage. The library of extensions is available from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-contrib Full documentation for using and writing your own extensions: http://xmonad.org/contrib.html This release brought to you by the xmonad dev team: Spencer Janssen Don Stewart Jason Creighton Andrea Rossato David Roundy Brent Yorgey Featuring code contributions from: Aaron Denney Adam Vogt Alec Berryman Alex Tarkovsky Alexandre Buisse Austin Seipp Brandon Allbery Chris Mears Christian Thiemann Clemens Fruhwirth Daniel Neri Daniel Wagner Dave Harrison David Glasser David Lazar Devin Mullins Dmitry Kurochkin Dougal Stanton Eric Mertens Ferenc Wagner Gwern Branwen Hans Philipp Annen Ivan Tarasov Jamie Webb Jeremy Apthorp Joachim Breitner Joachim Fasting Joe Thornber Joel Suovaniemi Juraj Hercek Kai Grossjohann Karsten Schoelzel Klaus Weidner Lucas Mai Mats Jansborg Matsuyama Tomohiro Michael Fellinger Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Nicolas Pouillard Peter De Wachter Robert Marlow Roman Cheplyaka Sam Hughes Shachaf Ben-Kiki Shae Erisson Simon Peyton Jones Stefan O'Rear Valery V. Vorotyntsev timthelion "intrigeri" As well as the support of many others on the #xmonad and #haskell IRC channels, and the wider Haskell and window manager communities. Thanks to everyone for their support!

1 0

ANN: RPCA and fec
by Adam Langley 27 Jan '08

27 Jan '08

Doubling up an announcement email again to reduce the traffic on the list. First: RPCA is an RPC system. This first release is pretty lacking, simple client-server interactions work but there's no lame-duck handling, load balancing, security etc. RPCA uses codec-libevent's tagged data structures for serialisation. Tagged structures allow you to grow you RPCs incrementally, which is very important in large programs. Very simple tests should that 1000's of RPCs a second isn't a problem. There's also the start of a C library for the protocol, written on libevent and glib. To give a taste, here's what you need to write on the server side: addNumbers :: TestRPC.Addnumbersrequest -> ((Maybe TestRPC.Addnumbersreply) -> STM ()) -> IO () addNumbers (TestRPC.Addnumbersrequest { TestRPC.addnumbersrequest_a = a , TestRPC.addnumbersrequest_b = b }) cb = do atomically $ cb $ Just $ TestRPC.addnumbersreplyEmpty { TestRPC.addnumbersreply_c = a + b } and on the client side... rpc chan "add" (TestRPC.Addnumbersrequest 400 300) 0.1 That's a synchronous call with a timeout. You can, of course, call them asynchronously as well (and from multiple threads etc) It's highly experimental and can be found in Hackage and at http://darcs.imperialviolet.org/darcsweb.cgi?r=network-rpca;a=summary FEC is an erasure coding library, based on zfec by Zooko, based on code by Luigi Rizzo. The most widely known example of an erasure code is the RAID-5 algorithm which makes it so that in the event of the loss of any one hard drive, the stored data can be completely recovered. The algorithm in the fec package has a similar effect, but instead of recovering from the loss of only a single element, it can be parameterized to choose in advance the number of elements whose loss it can tolerate. Hackage: http://hackage.haskell.org/packages/archive/fec/0.1.1/doc/html/Codec-FEC.ht… It's new code, but the library that it's based on is well tested so should be sound. AGL -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org 650-283-9641

1 0

C# parser written in Haskell
by Joel Reymont 27 Jan '08

27 Jan '08

Does anyone have a C# parser written in Haskell? Thanks, Joel -- http://wagerlabs.com

1 0

Testing one's .ghci
by gwern0＠gmail.com 27 Jan '08

27 Jan '08

So I was recently going over my config files (which are version-controlled in Darcs, of course), and I was adding tests for recording patches. For some of the files, it was easy enough - the application generally provided some mean of loading in the rc file and then it would error or not based on whether the file was at least syntactically correct. For example, to test my .emacs, I have 'emacs -batch -f batch-byte-compile ~/.emacs'. If the .emacs won't byte-compile, it probably won't run! My question is, how many I do the same thing with GHCi? No options specifically for this seem to be listed, and the normal trick doesn't work - I tried: > ghci -read-dot-ghci -e 'let main = return() in main' && echo foo And regardless of whether the .ghci had hideous crippling errors in it, at the end "foo" was still merrily being printed out. Does haskell-cafe have any ideas or should I just go file a feature request? -- gwern chameleon Vale RSA Recon 1080H beanpole advisors Harvard Texas PARKHILL

1 0

ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell
by Sterling Clover 27 Jan '08

27 Jan '08

HStringTemplate is a port of Terrence Parr’s lovely StringTemplate (http://www.stringtemplate.org) engine to Haskell. It is available, cabalized, at: darcs get http://code.haskell.org/HStringTemplate/ As interest has grown in using Haskell for web applications, there has been an increasing buzz about the need for a good templating engine in Haskell. Why might we need this? After all, Haskell has lovely combinator libraries for generating HTML programmatically, enforcing good form through its type system. But sometimes, we don’t want well-formed HTML. We want the ugly stuff that floats around to deal with eight varieties of browser incompatibilities and the latest silly ajax trick. Or sometimes we’re working with a team of graphic designers, and they want to work in almost-HTML. Or sometimes we just want to be able to change the design of a web application on the fly, completely independent of our program logic, and of, heavens forbid, recompiling and possibly messing with a live application. So template engines are popular, and indeed, considered a key part of most web frameworks out there. One problem — they’re mainly awful, imperatively-conceived behemoths that capriciously mix program logic with display and, consequently, entail a great deal of overhead. Enter StringTemplate, a nifty and fairly-well developed template format that’s both pure and functional, and therefore pretty much the only one of its kind. Indeed, it also seems to be getting heavy use in code generation because its paradigm maps neatly to traversing parse-trees. HStringTemplate is not feature-complete, and indeed is only at version 0.1. But it should implement pretty much everything in the standard StringTemplate 3.0 grammar, only nicer, because it’s in Haskell. There are scads of different recursive constructs and ways to handle inclusion and inheritance. Furthermore, HStringTemplate handles conditionals, and sports also a very Haskellish implementation of custom rendering. Templates can be constructed that return strings, ShowSs, bytestrings, or even pretty printer Docs that handle wrapping, indentation, and fill elegantly. Even better, these templates are parsed and compiled only once, after which point there isn't a syntax tree anymore, just a function that operates on the environment of attributes that have been passed to it. Where I take it from here depends in part on what sort of response I get, so patches, gripes, API comments and feature requests are all more than welcome. Please note that I'm still working in 6.6.1. Everything should be in place to compile properly with the base split, but if it isn't, again, patches more than welcome. Full announcement at: http://fmapfixreturn.wordpress.com/ --SC

6 8