June 2009 - Haskell-Cafe

Cabal/primes
by michael rice 02 Jun '09

02 Jun '09

Finally got adventurous enough to get Cabal working, downloaded the primes package, and got the following error message when trying isPrime. Am I missing something here? Michael ================== [michael@localhost ~]$ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> import Data.Numbers.Primes Prelude Data.Numbers.Primes> take 10 primes Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package primes-0.1.1 ... linking ... done. [2,3,5,7,11,13,17,19,23,29] Prelude Data.Numbers.Primes> isPrime 7 <interactive>:1:0: Not in scope: `isPrime' Prelude Data.Numbers.Primes>

2 1

Success and one last issue with Data.Binary
by David Leimbach 02 Jun '09

02 Jun '09

I've got the following "printHex" string as a response from a 9P server running on the Inferno Operating System. (thanks to a friendly mailing list contributor who sent a nice example of using Data.Binary) 1300000065ffff000400000600395032303030 This is a little endian encoded ByteString with the following fields in it: Rversion {size :: Word32, mtype :: Word8, tag :: Word16, msize :: Word32, ssize :: Word16, version :: ByteString} But when I try to use the following implementation of "get" to decode this stream, I'm getting the following error: "too few bytes. Failed reading at byte position 20" Unfortunately, I'm only expecting 19 bytes, and in fact never asked for byte 20. (I am just asking for everything up to ssize, and then "getRemainingLazyByteString"). Is this a bug? Is it mine or in Data.Binary? :-) Here's my "get" function: get = do s <- getWord32le mtype <- getWord8 getSpecific s mtype where getSpecific s mt | mt == mtRversion = do t <- getWord16le ms <- getWord32le ss <- getWord16le v <- getRemainingLazyByteString return $ MessageClient $ Rversion {size=s, mtype=mt, tag=t, msize=ms, ssize=ss, version=v} The good news is I'm talking 9P otherwise, correctly, just having some decoding issues. I hope to have a hackage package eventually for this. Dave

3 17

Compiling a windows app - embedding a manifest
by Günther Schmidt 02 Jun '09

02 Jun '09

Hi all, is it possible to make ghc embedd a particular manifest in the .exe during the compilation process? Günther

2 1

code reviewers wanted for hashed-storage (darcs)
by Eric Kow 02 Jun '09

02 Jun '09

Dear Haskellers, Will you have a few spare hours this summer? The Darcs team needs your help! Summary ------- We need two volunteers to help us review the standalone hashed-storage module, which will be used by Darcs in the future. Background ---------- Darcs supports 'hashed' repositories in which each file in the pristine cache is associated with a cryptographic hash. Hashed repositories help Darcs to resist some forms of corruption and also allow for nice features such as a global patch cache and lazy patch fetching. Unfortunately, our implementation can be rather slow. Petr has some nice ideas for making these repositories work a lot faster. He will be producing a library he calls 'hashed-storage' which generalises the idea of storing files associating them with a cryptographic hash and furthermore improves on the current implementation used by Darcs. The hashed-storage library is general purpose and may find a use in other applications that need to manage a large number of files. I'm excited about this project because if it succeeds, we can finally start hammering home the point that yes, Darcs *can* be a fast revision control system. It may not fix all our problems -- we'll still need a Darcs 3 -- but it should alleviate at least some of the practical day to day issues. I want to ensure that Petr's project is a success. One thing in particular is that I would like him to get regular code review from the Haskell community, perhaps from folks who aren't already on the Darcs team. Do you think you can help? Two volunteers needed --------------------- I'm looking for just two volunteers this summer: 1. Do you have one hour per week this summer? We need somebody to track and make comments on changes to hashed-storage over this summer. The current library has only 8 modules, with less than 1400 lines of code, so it should be relatively easy to get started :-) 2. Do you have a spare weekend in August? Towards the end of the summer, it would be nice to have somebody examine the "final" version of hashed-storage and give us their thoughts. Again, no Darcs experience is needed, as this is a standalone module. In fact, a fresh perspective would be very helpful. More information ---------------- You can download hashed-storage from hackage from his darcs repository: darcs get http://repos.mornfall.net/hashed-storage For more information about his project, see http://web.mornfall.net/blog/summer_of_code.html Please get in touch with me if you can help. Thanks! Eric -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

1 0

Possible Haskell Project
by Tom Hawkins 02 Jun '09

02 Jun '09

My family and I are moving in the coming months. My wife will be attending a new school in the fall. Among the many hassles of moving are locating and transferring medical records to new doctors and clinics. During our time in Minnesota, we've visited several clinics and hospitals, so our medical data is spread across a dozen different networks. Collecting this data is a chore. And reciting it to every new medical provider is frustrating, especially knowing someone else has already typed this stuff into the computer. For obvious reasons, there are many software companies competing in the Electronic Health Record (EHR) industry. I haven't spent much time researching the field, but I have to imagine there is no shortage of bloated standards and next to nil interoperability. With President Obama pushing for electronic health records, this could be an opportunity for the Haskell community to deliver a common framework that the US, and maybe the rest of the world, could build upon -- a longshot I realize. At the core, the fundamental problem is not that complicated. It's just storing and retrieving a person's various health events: checkups, prescriptions, procedures, test results, etc. The main technical challenges are database distribution and patient security. Both are fun problems, and our friends at Galios continue to show how effective Haskell is at building secure systems. Any thoughts? Ideas? -Tom BTW, Anyone looking to rent a house in Eden Prairie, MN? A Haskell employer is just 4 miles down the road (Eaton).

4 4

Compiling a windows app - embedding application icon
by Günther Schmidt 02 Jun '09

02 Jun '09

Hi all, is it possible to make ghc embedd an application icon in the .exe during the compilation process? Günther

2 1

Spam apology
by Daniel Cook 02 Jun '09

02 Jun '09

Sorry for all the repeated messages, my e-mail client exploded.

1 0

HaL4: Haskell-Meeting in Germany, 12th June 2009
by Janis Voigtlaender 02 Jun '09

02 Jun '09

Hi all, If you are anyway near Halle/Saale in June, be sure not to miss out on: http://iba-cg.de/hal4.html We have already close to 50 registered participants, so expect a very lively meeting. See you there? (Late registration still possible.) Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 1

Trouble with types
by Vladimir Reshetnikov 02 Jun '09

02 Jun '09

Hi, I tried this code: ----------------------- f, g :: a -> a (f, g) = (id, id) ----------------------- Hugs: OK GHC: Couldn't match expected type `forall a. a -> a' against inferred type `a -> a' In the expression: id In the expression: (id, id) In a pattern binding: (f, g) = (id, id) What does mean this error message? And what of them (Hugs, GHC) is correct? Thanks Vladimir

3 3

RE: Haskell-Cafe Digest, Vol 70, Issue 2
by R J 01 Jun '09

01 Jun '09

Sorry -- the vocabulary template is attached. > From: haskell-cafe-request(a)haskell.org > Subject: Haskell-Cafe Digest, Vol 70, Issue 2 > To: haskell-cafe(a)haskell.org > Date: Mon, 1 Jun 2009 21:47:16 -0400 > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: Missing a "Deriving"? (Daniel Fischer) > 2. Re: Bool as type class to serve EDSLs. (Claus Reinke) > 3. Re: ANN: new version of uu-parsinglib (S. Doaitse Swierstra) > 4. Re: Re: Error message reform (Claus Reinke) > 5. Re: Re: Error message reform (was: Strange type errorwith > associated type synonyms) (Claus Reinke) > 6. Re: Missing a "Deriving"? (michael rice) > 7. Re: Bool as type class to serve EDSLs. (Sebastian Fischer) > 8. Checking a value against a passed-in constructor? (Dan Cook) > 9. Re: Checking a value against a passed-in constructor? > (Jason Dagit) > 10. Re: Missing a "Deriving"? (michael rice) > 11. Re: Missing a "Deriving"? (Ross Mellgren) > 12. Re: Missing a "Deriving"? (michael rice) > 13. Re: Missing a "Deriving"? (Ross Mellgren) > 14. Re: Missing a "Deriving"? (michael rice) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Jun 2009 19:51:35 +0200 > From: Daniel Fischer <daniel.is.fischer(a)web.de> > Subject: Re: [Haskell-cafe] Missing a "Deriving"? > To: haskell-cafe(a)haskell.org > Message-ID: <200906011951.35775.daniel.is.fischer(a)web.de> > Content-Type: text/plain; charset="iso-8859-15" > > Am Montag 01 Juni 2009 19:02:36 schrieb michael rice: > > > All good so far, but then tried to convert Failable from Computation to > > Monad > > > > > > instance Monad Failable where > > return = Success > > fail = Fail > > >>= (Success x) f = f x > > >>= (Fail s) _ = Fail s > > mplus (Fail _) y = y > > mplus x _ = x > > > > > > and got the following error. > > > > > > Prelude> :l graph5 > > [1 of 1] Compiling Main ( graph5.hs, interpreted ) > > > > graph5.hs:34:4: parse error on input `>>=' > > Failed, modules loaded: none. > > Prelude> > > > > When you use an operator in prefix position, you must enclose it in parentheses, like you > must enclose a function in backticks if you use it infix. > > So the definition of (>>=) should read > > > (>>=) (Success x) f = f x > (>>=) (Fail s) _ = Fail s > > or, defining it in infix position, > (Success x) >>= f = f x > (Fail s) >>= _ = Fail s > > > > > Complete code follows. > > > > Michael > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 1 Jun 2009 19:22:10 +0100 > From: "Claus Reinke" <claus.reinke(a)talk21.com> > Subject: Re: [Haskell-cafe] Bool as type class to serve EDSLs. > To: "haskell Cafe" <haskell-cafe(a)haskell.org> > Message-ID: <76CE077128014A86A2D61E5918F8BFE8@cr3lt> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > >> Do you argue that overloading logical operations like this in Haskell > >> sacrifices type safety? Could programs "go wrong" [1] that use such > >> abstractions? > > > > If I understand your point correctly, you are suggesting that such programs > > are still type safe. I agree with the claim that such features are > > detrimental in practice though. Instead of lumping it with type safety, > > then what do we call it? I think I've heard of languages that do such > > conversions as "weakly" typed. Really the issue is with implicit > > conversions, right? > > Isn't it merely a matter of balance? In order for typed programs not > to go "wrong", one has to define "right" and "wrong", and devise a type > system that rules out anything that might go "wrong", usually at the > expense of some programs that might go "right". > > Advanced type system features like overloading take that unused space > and devise ways to redirect code that would go "wrong" (in simpler > systems) to go "right" in useful new ways (eg: adding two functions or > matrices or .. does not have to be "wrong", there are interpretations in > which all of these make perfect sense, and Haskell can express many > of them). > > What is happening then is that more and more of the previously "wrong" > space is filled up with meaningful ways of going "right", until nearly every > syntactically valid program goes somewhere. That can make for an > extremely expressive and powerful language, but it renders the naive > notion of going "wrong" or "right" rather meaningless: "wrong" just > means we haven't figured out a meaningful way to interpret it, and > going "right" can easily be a far cry from where you wanted it to go. > > Claus > > PS. this problem can be made worse if the implicit conversions > aren't consistent, if small "twitches" in source code can lead to > grossly different behaviour. There is a fine line between advanced > and uncontrollable, and opinions on what side of the line any given > definition is on can differ. > > > > > ------------------------------ > > Message: 3 > Date: Mon, 1 Jun 2009 20:27:05 +0200 > From: "S. Doaitse Swierstra" <doaitse(a)swierstra.net> > Subject: Re: [Haskell-cafe] ANN: new version of uu-parsinglib > To: Ross Paterson <ross(a)soi.city.ac.uk> > Cc: haskell-cafe(a)haskell.org > Message-ID: <8F2D399B-451A-45F4-9FE1-B7F5145C3B91(a)swierstra.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > And rename "empty" to "fail"? You managed to confuse me since I always > use pSucceed to recognise the empty string. > > Doaitse > > > On 1 jun 2009, at 01:21, Ross Paterson wrote: > > > On Sun, May 31, 2009 at 09:40:38PM +0200, S. Doaitse Swierstra wrote: > >> A new version of the uu-parsinglib has been uploaded to hackage. It > >> is > >> now based on Control.Applicative where possible. > >> > >> Be warned that functions like some and many will be redefined in the > >> future. > > > > Perhaps we should make some and many methods of Alternative, <* and *> > > methods of Applicative and <$ a method of Functor, all with the > > current > > definitions as defaults. (John Meacham was also asking for the first > > of these.) > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > ------------------------------ > > Message: 4 > Date: Mon, 1 Jun 2009 19:49:44 +0100 > From: "Claus Reinke" <claus.reinke(a)talk21.com> > Subject: Re: [Haskell-cafe] Re: Error message reform > To: <haskell-cafe(a)haskell.org> > Message-ID: <E0BDCB9EE5F84BEA9126D498C0F98621@cr3lt> > Content-Type: text/plain; format=flowed; charset="UTF-8"; > reply-type=response > > > It's too wordy, but it's a start. This is also prime ground for wanting > > to have configurable levels of error reports, since some users will find > > it helpful to see both types but others will find it confusing. > > Indeed. For this simple example, I find Hugs' message nearly optimal, > but as one could just as well construct examples where GHC's message > was nearly optimal, I've tried instead to extend the example, until neither > Hugs nor GHC gives an optimal message. Even so, it is worth comparing > the two, and their complementary approaches to the problem: > > t = (let q=0 in(\y->(\x->(\z->let r=1 in x z))) ()) :: (a->b)->(a->a) > > D:\home\Haskell\tmp\desktop\errormessages.hs:2:41: > Couldn't match expected type `a' against inferred type `b' > `a' is a rigid type variable bound by > an expression type signature > at D:\home\Haskell\tmp\desktop\errormessages.hs:2:56 > `b' is a rigid type variable bound by > an expression type signature > at D:\home\Haskell\tmp\desktop\errormessages.hs:2:59 > In the expression: x z > In the expression: let r = 1 in x z > In the expression: (\ z -> let r = 1 in x z) > > ERROR file:.\errormessages.hs:2 - Inferred type is not general enough > *** Expression : let {...} in (\y -> \x -> \z -> let {...} in x z) () > *** Expected type : (a -> b) -> a -> a > *** Inferred type : (a -> a) -> a -> a > > GHC delivers its messages from in-the-middle of its typing process, > which one hopes might give as little information as neccessary to > identify the issue, without irrelevant context. It then tries to explain > that information nicely, followed by some value-level context. > > Hugs delivers its messages from on-the-outside-looking-in, which one > hopes might give the maximum potentially relevant information. It makes > no attempt to cushion the blow. > > In practice, neither approach works all the time, and even for this > tiny contrived example, one would have to engage in some "type > debugging" (inserting type signatures, to trigger type-level printfs; > commenting out large parts of code to see whether they contribute > to the issue; ..) to figure it out. > > Note that both approaches are fairly precise in locating the error > at the type level - it is the cross-reference from type to value level > that runs into trouble, especially if the former is only implicit in the > latter (which is why type debugging by adding signatures helps). > > > For really intricate type hacking, even this isn't enough because the > > programming errors often happen far from where the type errors are > > finally caught. In an ideal world, ghc could dump the entire proof > > forest generated by inference, so an external tool[1] could be used to > > browse through it and track the complete history of where inferred types > > came from. This gives a partial view of the inferred types for a > > compilation unit, something I've often wanted (rather than the manual > > comment/reload/uncomment routine). The proof forest could even be used > > as an interlingua over which people can write filters to generate > > messages they find most helpful. > > Yes, most research papers on this ended up suggesting visual representations > and separation between generating and presenting/querying error information. > > > Ah the joys of ideal worlds... ;) > > "if you don't have a dream, how you gonna have a dream come true?" (Bloody Mary) > > Claus > > > > > ------------------------------ > > Message: 5 > Date: Mon, 1 Jun 2009 20:00:09 +0100 > From: "Claus Reinke" <claus.reinke(a)talk21.com> > Subject: Re: [Haskell-cafe] Re: Error message reform (was: Strange > type errorwith associated type synonyms) > To: <haskell-cafe(a)haskell.org> > Message-ID: <8C39CAA7170D479D88613F7F77920916@cr3lt> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=response > > > I once thought, that error messages must be configurable by libraries, > > too. This would be perfect for EDSLs that shall be used by non-Haskellers. > > Yes, that is a problem. > > > But I have no idea how to design that. > > There was some work in that direction in the context of the Helium > project. See the publication lists of Bastiaan Heeren and Jurriaan Hage: > > http://people.cs.uu.nl/bastiaan/#Publications > http://www.cs.uu.nl/research/techreps/aut/jur.html > > Claus > > > > > ------------------------------ > > Message: 6 > Date: Mon, 1 Jun 2009 14:30:00 -0700 (PDT) > From: michael rice <nowgate(a)yahoo.com> > Subject: Re: [Haskell-cafe] Missing a "Deriving"? > To: haskell-cafe(a)haskell.org, Daniel Fischer > <daniel.is.fischer(a)web.de> > Message-ID: <789959.35516.qm(a)web31103.mail.mud.yahoo.com> > Content-Type: text/plain; charset="iso-8859-1" > > Got it. > > Thanks! > > Michael > > --- On Mon, 6/1/09, Daniel Fischer <daniel.is.fischer(a)web.de> wrote: > > From: Daniel Fischer <daniel.is.fischer(a)web.de> > Subject: Re: [Haskell-cafe] Missing a "Deriving"? > To: haskell-cafe(a)haskell.org > Date: Monday, June 1, 2009, 1:51 PM > > Am Montag 01 Juni 2009 19:02:36 schrieb michael rice: > > > All good so far, but then tried to convert Failable from Computation to > > Monad > > > > > > instance Monad Failable where > > return = Success > > fail = Fail > > >>= (Success x) f = f x > > >>= (Fail s) _ = Fail s > > mplus (Fail _) y = y > > mplus x _ = x > > > > > > and got the following error. > > > > > > Prelude> :l graph5 > > [1 of 1] Compiling Main ( graph5.hs, interpreted ) > > > > graph5.hs:34:4: parse error on input `>>=' > > Failed, modules loaded: none. > > Prelude> > > > > When you use an operator in prefix position, you must enclose it in parentheses, like you > must enclose a function in backticks if you use it infix. > > So the definition of (>>=) should read > > > (>>=) (Success x) f = f x > (>>=) (Fail s) _ = Fail s > > or, defining it in infix position, > (Success x) >>= f = f x > (Fail s) >>= _ = Fail s > > > > > Complete code follows. > > > > Michael > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

1 0