- Haskell-Cafe - Haskell.org

Don't miss CUFP
by Simon Peyton-Jones 24 Jul '09

24 Jul '09

Hey, guys, This list has zillions of people who use Haskell for day-to-day work. So you might want to come to the now-annual workshop for Commercial Users of Functional Programming (CUFP) http://cufp.galois.com 4 Sept 2009, Edinburgh Speakers from companies including Facebook, Barclays Capital, and EDF Trading, using Haskell, Scala, F#, among others. Better still, CUFP is preceded and followed by a day of developer-focused tutorials: Developer Tracks on Functional Programming http://www.defun2009.info/blog/ 3 and 5 Sept, Edinburgh Tutorials covering tools and libraries in Erlang, OCaml, Scala, PLT Scheme, and more. And if that isn't enough, all this is co-located with International Conference on Functional Programming (ICFP) Haskell Symposium ML Workshop Generic Programming Workshop Erlang Workshop Haskell Implementors Workshop Such a cornucopia of delights. It'll be fun. But you do have to register: http://www.cs.nott.ac.uk/~gmh/icfp09.html Simon

1 0

FFI to double constants, printf
by Maurício 24 Jul '09

24 Jul '09

When we printf doubles from C (like when using hsc2hs to bind to a constant) we can get something that's not valid Haskell. See these 2 examples: 3.40282347e+38F inf Do you know some way to printf a double using printf (or any other standard function) that's always going to give me valid Haskell text, even in special cases? Thanks, Maurício

4 4

Leksah works!
by Eugene Kirpichov 23 Jul '09

23 Jul '09

Hi. Quite a while ago I launched Leksah and couldn't get anything done at all; so I thought it is probably never be completed and abandoned attempts to find an IDE for Haskell. However, 3 days ago I launched the new version and it works fantastic! It has an IntelliSense popup with type annotations, a module browser, build-on-the-fly and other things, even though I used it only for 15 minutes (then the ICFP contest began, where I wrote in Python and Java). Main point: It seems a vastly more convenient IDE for Haskell than vim (don't know about emacs-mode). So, I'd like to encourage haskellers to install it and give it a try :) -- Eugene Kirpichov Web IR developer, market.yandex.ru

7 8

Generalizing takeWhile
by Matthias Görgens 23 Jul '09

23 Jul '09

I need to take some elements from the front of a list. However the criteria are somewhat complex. > walk f [] = [] > walk f (x:xs) = case f x > of Just g -> x : walk g xs > Nothing -> [] For each item the `predicate' f either returns Nothing, when it thinks we should not take any more elements, or return Just another `predicate' to apply to the next element. However the type system does not like my function. How can I mollify it?

7 9

is closing a class this easy?
by Conor McBride 23 Jul '09

23 Jul '09

Friends Is closing a class this easy? -------------------------------------- module Moo ( Public(..) ) where class Private x => Public x where blah :: ... class Private x where instance Private A where instance Public A where blah = ... instance Private B where instance Public B where blah = ... -------------------------------------- Modules importing Moo get Public and its instances, but cannot add new ones: any such instances must be accompanied by Private instances, and Private is out of scope. Does this work? If not, why not? If so, is this well known? It seems to be just what I need for a job I have in mind. I want a class with nothing but hypothetical instances. It seems like I could write -------------------------------------- module Noo ( Public(..) , public ) where class Private x => Public x where blah :: ... blah = ... class Private x where public :: (forall x. Public x => x -> y) -> y public f = f Pike data Pike = Pike instance Private Pike instance Public Pike -------------------------------------- But if I don't tell 'em Pike, I've ensured that blah can only be used in the argument to public. Or is there a hole? Cures youriously Conor

7 13

Mixing C and Haskell code in the same file
by Maurício 23 Jul '09

23 Jul '09

Is it possible to insert C code directly to, say, .hsc files? I see this construct in ghc user docs: #def ... which should insert definitions, but I could not find examples of usage in Hackage. My goal is to write some cpp macros that build both a C function and its 'foreign import ccall' wrapper in the same file. Thanks for your help, Maurício

4 5

ANN: Semantic Web
by Vasili I. Galchin 23 Jul '09

23 Jul '09

I. Swish-0.2.1(Semantic Web Inference uSing Haskell) is a semantic web toolkit designed and implemented by Graham Klyne - GK(a)ninebynine.org: 1) http://www.ninebynine.org/RDFNotes/Swish/Intro.html 2) http://www.ninebynine.org/Software/swish-0.2.1.html I am personally very excited about Graham's work and the role of Haskell in his toolkit! II.) My role I "cabalized" Swish-0.2.1, brought namespace issues up to 6.8.2 standards and fixed many compiler warnings. There are still numerous warnings mostly related to lack of function type signatures. Swish-0.2.1 however does build and the tests that Graham wrote do run ok. Currently Swish-0.2.1 is currently hosted on Hackage but will most likely move to another site in the future. The downloader will find that there are TBDs in the swish.cabal file and other places. Please be patient. Kind regards, Vasili

2 1

Implicit concatenation in list comprehensions
by Max Bolingbroke 22 Jul '09

22 Jul '09

Dear Cafe, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: >>> [k, "=", v, " " | (k, v) <- [("foo", "1"), ("bar", "2")] ["foo", "=", "1", " ", "bar", "=", "2", " "] This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. One situation where I have found this to be useful is when you are writing Haskell programs that call lots of external programs and you need to set the flags based on some tests, like so: rawSystem "myProgram" $ ["foo" | fooing_enabled] ++ ["bar1", "bar2" | baring_enabled] I have submitted a ticket to GHC HQ with the patch (http://hackage.haskell.org/trac/ghc/ticket/3380#comment:5) but as it is just a small convenience it most likely won't make it in unless there is more demand for the feature. So, now is the time to speak up in favour of (or indeed, against) the added syntax! All the best, Max P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: >>> (, True, "Hello", ) 1 "World" (1, True, "Hello", "World")

16 21

Re: cheap in-repo local branches (just needs implementation)
by Petr Rockai 22 Jul '09

22 Jul '09

Grant Husbands <darcsusers(a)grant.x43.net> writes: > The original note that I should have quoted was from Max Battcher: > : Additionally, there would be other useful management tools > : (``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think > : that these four commands could be done with no darcs interaction at all > : (unless the branch being switched to has an incomplete/lazy pristine). Ah, OK. This is mistake on Max's part, since there's no such thing as incomplete/lazy pristine. I.e. this is a non-issue. > Overall, I'd say this just feeds back into my original point, though; > I fully expected that many points could be answered, and I think I can > raise more, given a bit of thought. (I won't unless I'm asked to, > though, as I'm trying to raise a useful point, not trying to wield > pedantry to kill a project.) Well, the problem with that point is that maybe half of your points were trivially untrue, which sort of puts a dent into the argument itself. :) > However, take even just the above into account and things are now more > complicated. We're no longer simply switching a pristine and an > inventory here and there, we're applying and unapplying patches for > the working copy (which is non-trivial if you want to get the contexts > correct), and rolling back on failure (something even Darcs has > historically had trouble with). We're extending the added GC roots to > include the full inventory chain (and whatever else comes up). We're > doing something interesting with a new kind of context to make patch > migration between branches work. I think it will become at least as > much work as it would take to implement the right mechanisms in Darcs > itself. No-one says it is going to be less or more work to do this within or outside of darcs. No doubt, some darcslib usage is quite likely (for patch application and unapplication, eg.). However, it is still relatively manageable, and in a limited form also relatively easy (but that's true of almost anything, the 80/20 rule). > There's also the strong possibility that the system would get mostly > implemented, with a few gotchas here and there and a few incomplete > features, and then there'd less impetus for writing a good, integral > branching system. You are probably overdoing the "integral" part of the equation, given that the only difference is administrative. You can import parts of darcs from outside of darcs just fine, these days. Anyway, the 80/20 problem is equivalently applicable to in-darcs as it is to out-of-darcs implementation. Yours, Petr.

1 0

Re: [darcs-users] cheap in-repo local branches (just needs implementation)
by Eric Kow 22 Jul '09

22 Jul '09

On Wed, Jul 22, 2009 at 16:48:39 +0100, Grant Husbands wrote: > Overall, I'd say this just feeds back into my original point, though; > I fully expected that many points could be answered, and I think I can > raise more, given a bit of thought. (I won't unless I'm asked to, > though, as I'm trying to raise a useful point, not trying to wield > pedantry to kill a project.) I think it's quite useful that you're doing this, thanks. The hope was to solicit discussion, after all! I'd particularly appreciate it if we could summarise any results from this on the bug tracker in the end http://bugs.darcs.net/issue555 > However, take even just the above into account and things are now more > complicated. We're no longer simply switching a pristine and an > inventory here and there, we're applying and unapplying patches for > the working copy (which is non-trivial if you want to get the contexts > correct), and rolling back on failure (something even Darcs has > historically had trouble with). We're extending the added GC roots to > include the full inventory chain (and whatever else comes up). We're > doing something interesting with a new kind of context to make patch > migration between branches work. I think it will become at least as > much work as it would take to implement the right mechanisms in Darcs > itself. Another option to consider: though this may be straying from the idea of implementing a standalone tool, but it seems that darcs-branch could outsource any clever bits to the Darcs library (and that we'd have to think carefully through extensions to the Darcs library and not just hashed-storage to make this work). -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

1 0