From ganesh at earth.li Mon Sep 1 01:33:25 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 1 01:31:42 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B8A239.4030904@iee.org> <48B920BE.30507@iee.org> <48B93FB2.3060505@iee.org> <3D45FFCB-6BED-4282-80C0-5717480384B1@ece.cmu.edu> <73AFB0A3-353D-49D5-A9D9-11DCA8084C03@ece.cmu.edu> <3F76B9CD-3F90-431B-8B62-B20B45BC4116@ece.cmu.edu> Message-ID: On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote: >> >> I'm afraid I don't see how this generalises to sharing something across an >> entire process where the things that want to do the sharing are not in or >> controlled by the same shared library. In particular the filehandle >> structures required for buffered I/O need to be common to every single >> piece of code in the process that might want to use them, no matter what >> language or language implementation that code uses. > > > For that you probably want to look at how ld.so.1 and libc interact to > share the malloc pool and the stdin/stdout/stderr, among others. If buffered IO is handled by libc rather than by specific language runtimes, then the same mechanism of using global variables inside libc would work fine; but this technique doesn't extend to providing process-scope shared state for library code that might be loaded multiple times with no knowledge of the other instances. Ganesh From allbery at ece.cmu.edu Mon Sep 1 02:16:39 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Sep 1 02:15:07 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B8A239.4030904@iee.org> <48B920BE.30507@iee.org> <48B93FB2.3060505@iee.org> <3D45FFCB-6BED-4282-80C0-5717480384B1@ece.cmu.edu> <73AFB0A3-353D-49D5-A9D9-11DCA8084C03@ece.cmu.edu> <3F76B9CD-3F90-431B-8B62-B20B45BC4116@ece.cmu.edu> Message-ID: On 2008 Sep 1, at 1:33, Ganesh Sittampalam wrote: > On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote: >> On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote: >>> I'm afraid I don't see how this generalises to sharing something >>> across an entire process where the things that want to do the >>> sharing are not in or controlled by the same shared library. In >>> particular the filehandle structures required for buffered I/O >>> need to be common to every single piece of code in the process >>> that might want to use them, no matter what language or language >>> implementation that code uses. >> >> >> For that you probably want to look at how ld.so.1 and libc interact >> to share the malloc pool and the stdin/stdout/stderr, among others. > > If buffered IO is handled by libc rather than by specific language > runtimes, then the same mechanism of using global variables inside > libc would work fine; but this technique doesn't extend to providing > process-scope shared state for library code that might be loaded > multiple times with no knowledge of the other instances. True. If you want to allow for that, you must do it yourself. (I've been bitten by this; older ssh built against older heimdal would load two different versions of the crypto libraries, ssh would initialize one, heimdal would use the other (the initialized flag being global, but the buffers different sizes) and presto, core dump.) This is in large part what the discussion is about: making it possible to write such properly without having to delegate it across the FFI as C code. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From haskell at brecknell.org Mon Sep 1 03:40:49 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Mon Sep 1 03:39:05 2008 Subject: [Haskell-cafe] Re: [Haskell] The initial view on typed sprintf and sscanf In-Reply-To: <20080901024041.07B71AE54@Adric.metnet.fnmoc.navy.mil> References: <20080901024041.07B71AE54@Adric.metnet.fnmoc.navy.mil> Message-ID: <1220254849.17108.1271490755@webmail.messagingengine.com> oleg [1]: > We demonstrate typed sprintf and typed sscanf sharing the same > formatting specification. [1]http://www.haskell.org/pipermail/haskell/2008-August/020605.html Reading Oleg's post, I noticed that it is quite straightforward to generalise printing to arbitrary output types. > class Monoid p => Printf p where > printChar :: Char -> p > --etc > > intp :: Printf p => F a b -> (p -> a) -> b > intp FChr k = \c -> k (printChar c) > intp (a :^ b) k = intp a (\sa -> intp b (\sb -> k (mappend sa sb))) > --etc > > printf :: Printf p => F p b -> b > printf fmt = intp fmt id The Printf instances for String, ShowS, ByteStrings, and IO () are all trivial. Printing directly to a file (without building an intermediate string) is slightly more interesting: > instance Monad m => Monoid (ReaderT r m ()) where > mempty = return () > mappend = (>>) > > instance Printf (ReaderT Handle IO ()) where > printChar c = ask >>= \h -> liftIO (hPutChar h c) > --etc > > (<<) :: Handle -> ReaderT Handle IO () -> IO () > (<<) = flip runReaderT > > test_fprintf h = h << printf (lit "Hello " ^ lit "World" ^ chr) '!' Unfortunately, I don't seem to be able to make the expected fprintf function, because printf's format-dependent parameter list makes it impossible to find a place to pass the handle. Hence the C++-like (<<) ugliness. From dons at galois.com Mon Sep 1 04:00:25 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 1 03:58:44 2008 Subject: [Haskell-cafe] Re: [Haskell] The initial view on typed sprintf and sscanf In-Reply-To: <1220254849.17108.1271490755@webmail.messagingengine.com> References: <20080901024041.07B71AE54@Adric.metnet.fnmoc.navy.mil> <1220254849.17108.1271490755@webmail.messagingengine.com> Message-ID: <20080901080025.GA27060@scytale.galois.com> haskell: > oleg [1]: > > We demonstrate typed sprintf and typed sscanf sharing the same > > formatting specification. > > [1]http://www.haskell.org/pipermail/haskell/2008-August/020605.html > > Reading Oleg's post, I noticed that it is quite straightforward to > generalise printing to arbitrary output types. > > > class Monoid p => Printf p where > > printChar :: Char -> p > > --etc > > > > intp :: Printf p => F a b -> (p -> a) -> b > > intp FChr k = \c -> k (printChar c) > > intp (a :^ b) k = intp a (\sa -> intp b (\sb -> k (mappend sa sb))) > > --etc > > > > printf :: Printf p => F p b -> b > > printf fmt = intp fmt id > > The Printf instances for String, ShowS, ByteStrings, and IO () are all > trivial. > > Printing directly to a file (without building an intermediate string) is > slightly more interesting: > > > instance Monad m => Monoid (ReaderT r m ()) where > > mempty = return () > > mappend = (>>) > > > > instance Printf (ReaderT Handle IO ()) where > > printChar c = ask >>= \h -> liftIO (hPutChar h c) > > --etc > > > > (<<) :: Handle -> ReaderT Handle IO () -> IO () > > (<<) = flip runReaderT > > > > test_fprintf h = h << printf (lit "Hello " ^ lit "World" ^ chr) '!' > > Unfortunately, I don't seem to be able to make the expected fprintf > function, because printf's format-dependent parameter list makes it > impossible to find a place to pass the handle. Hence the C++-like (<<) > ugliness. > I also wonder if we could give a String syntax to the formatting language, using -XOverloadedStrings and the IsString class. -- Don From gracjanpolak at gmail.com Mon Sep 1 04:03:12 2008 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Mon Sep 1 04:01:45 2008 Subject: [Haskell-cafe] Re: language proposal: ad-hoc overloading References: <2f9b2d30808311121r1c0a4155gd7f55a6d135be8a7@mail.gmail.com> <1220228832.8458.20.camel@flippa-eee> <1220229676.8458.23.camel@flippa-eee> Message-ID: Philippa Cowderoy flippac.org> writes: > > > Haskell already has one method of overloading: type classes. What you > > > propose is a seemingly innocent extension that I now doubt has > > > extremely far-reaching consequences into the language. Such a feature > > > should be properly researched before it is added to the language. http://homepages.dcc.ufmg.br/~camarao/CT/ -- Gracjan From ryani.spam at gmail.com Mon Sep 1 04:07:28 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Sep 1 04:05:47 2008 Subject: [Haskell-cafe] Research language vs. professional language Message-ID: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> Jonathan, I think we are going to end up just disagreeing on this subject, but I'd like to point out the reasons why we disagree. On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast wrote: > This concept of `day-to-day work' is a curious one. Haskell is not a > mature language, and probably shouldn't ever be one. I see where you are coming from here, but I think that train has already started and can't be stopped. I find Haskell interesting as a professional programmer for these four reasons: it's pure, it's functional, it's lazy, and it's got a great compiler. I don't know of any other "mature" language that can fill these shoes; Haskell is the most mature of them. If I'm missing another language that fits my requirements and would be better for day-to-day programming, let me know! The serious competitors I can see are Clean (Hackage blows away anything I've seen from that community) and O'CaML, which is neither pure nor lazy. Meanwhile, Haskell is getting more suitable for regular "professional" use every day. Look at the success of Hackage and the soon-to-be-published "Real World Haskell" book for evidence. Haskell solves many of the problems I have with existing languages today, and makes me a better programmer at the same time. > There will always be new discoveries in purely functional programming, > and as the art advances, features like this ad-hoc overloading hack > (and ACIO) will become obsolete and have to be thrown over-board. This is a good point. However, it seems to me that the pure programming language research is moving towards dependently typed languages, and that progress in Haskell has been more application-side; transactional memory and data-parallel, along with research on various fusion techniques, for example. I also think ACIO is a good theoretical starting point for research on what initialization means, and has potential for work to influence the commutative monads problem in general which could improve the syntax and number of lines of code devoted to working around the verbosity of effectful computations in Haskell. > I'd rather (much rather!) people concerned with day-to-day programming > for writing programs people actually use incorporate Haskell's features > into other, more practical, languages (as those who *actually* care about > such things are) rather than incorporating features from day-to-day > production languages into Haskell. This is already happening, of course; I think ML is going to become pure soon, although I don't think it will ever be non-strict. And I predict that within the next few years, lots of languages will be leaning heavily on the concurrency research that is going on in Haskell right now. But Haskell's community is also growing and becoming more results-oriented. If you want to blame someone for this, Don Stewart is probably your guy :) I'm just one of the johnny-come-latelies who is realizing what a great tool Simon and the rest of the ghc team has built. So, my question for you is: if Haskell is a research language, what direction should it be taking? What changes should be happening at the language (not the library) level that are in the interests of improving the state-of-the-art in functional programming? My goal is to make it not be a joke when I go to work and suggest that we use Haskell for part of our next project. What is yours? -- ryan From ryani.spam at gmail.com Mon Sep 1 04:16:46 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Sep 1 04:15:03 2008 Subject: [Haskell-cafe] Re: [Haskell] The initial view on typed sprintf and sscanf In-Reply-To: <20080901080025.GA27060@scytale.galois.com> References: <20080901024041.07B71AE54@Adric.metnet.fnmoc.navy.mil> <1220254849.17108.1271490755@webmail.messagingengine.com> <20080901080025.GA27060@scytale.galois.com> Message-ID: <2f9b2d30809010116t484eadd7obe6f08474731808a@mail.gmail.com> On Mon, Sep 1, 2008 at 1:00 AM, Don Stewart wrote: > I also wonder if we could give a String syntax to the formatting > language, using -XOverloadedStrings and the IsString class. Probably easier with Template Haskell: > ghci -fth Sprintf.hs *Sprintf> :t $(sprintf "Hello %s, showing %S and %S") $(sprintf "Hello %s, showing %S and %S") :: (Show a1, Show a) => [Char] -> a -> a1 -> [Char] *Sprintf> $(sprintf "Hello %s, showing %S and %S") "Don" 1 (5,6) "Hello Don, showing 1 and (5,6)" Code follows, which could be ported to use the printf/scanf language Oleg defined. -- ryan {-# LANGUAGE TemplateHaskell #-} module Sprintf where import Language.Haskell.TH data SprintfState = SprintfState String (ExpQ -> ExpQ) flush :: SprintfState -> (ExpQ -> ExpQ) flush (SprintfState "" k) = k flush (SprintfState s k) = (\e -> k [| $(litE $ StringL $ reverse s) ++ $e |]) finish :: SprintfState -> ExpQ finish (SprintfState s k) = k (litE $ StringL $ reverse s) addChar :: Char -> SprintfState -> SprintfState addChar c (SprintfState s e) = SprintfState (c:s) e addCode :: ExpQ -> SprintfState -> SprintfState addCode k s = SprintfState "" (\e -> flush s $ [| $k ++ $e |]) sprintf' :: SprintfState -> String -> ExpQ sprintf' k ('%':'S':cs) = [| \x -> $(sprintf' (addCode [| show x |] k) cs) |] sprintf' k ('%':'s':cs) = [| \s -> $(sprintf' (addCode [| s |] k) cs) |] sprintf' k ('%':'%':cs) = sprintf' (addChar '%' k) cs sprintf' k (c:cs) = sprintf' (addChar c k) cs sprintf' k [] = finish k sprintf :: String -> ExpQ sprintf = sprintf' (SprintfState "" id) From dons at galois.com Mon Sep 1 04:20:20 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 1 04:18:44 2008 Subject: [Haskell-cafe] Research language vs. professional language In-Reply-To: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> Message-ID: <20080901082020.GB27060@scytale.galois.com> ryani.spam: > On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast > wrote: > > This concept of `day-to-day work' is a curious one. Haskell is not a > > mature language, and probably shouldn't ever be one. > > I see where you are coming from here, but I think that train has > already started and can't be stopped. Yeah, it's too late. Too many people have their pay checks riding on GHC, the Hackage library set (now up to 740 libraries and tools!), and the continued development of the language in general. If Haskell's not "mature" yet, then perhaps it has reached its early twenties, with an reliable heavy duty optimizing compiler, fast runtime, large library set, standard documentation, testing, debugging and packaging tools, and large community. And a community with a lot of energy. We're serious about this thing. -- Don From bulat.ziganshin at gmail.com Mon Sep 1 04:30:22 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Sep 1 04:30:48 2008 Subject: [Haskell-cafe] Re: [Haskell] The initial view on typed sprintf and sscanf In-Reply-To: <2f9b2d30809010116t484eadd7obe6f08474731808a@mail.gmail.com> References: <20080901024041.07B71AE54@Adric.metnet.fnmoc.navy.mil> <1220254849.17108.1271490755@webmail.messagingengine.com> <20080901080025.GA27060@scytale.galois.com> <2f9b2d30809010116t484eadd7obe6f08474731808a@mail.gmail.com> Message-ID: <1661013535.20080901123022@gmail.com> Hello Ryan, Monday, September 1, 2008, 12:16:46 PM, you wrote: of course this may be done with code generation tools (such as TH). point of this research is to do this using type abilities of Haskell Don, i think this should be impossible with IsString since the point is that Haskell compiler should know types at compile time. IsString can't convert "%d" into (X int) while converting "%s" into (X String) > On Mon, Sep 1, 2008 at 1:00 AM, Don Stewart wrote: >> I also wonder if we could give a String syntax to the formatting >> language, using -XOverloadedStrings and the IsString class. > Probably easier with Template Haskell: >> ghci -fth Sprintf.hs *Sprintf>> :t $(sprintf "Hello %s, showing %S and %S") > $(sprintf "Hello %s, showing %S and %S") :: (Show a1, Show a) => > [Char] -> a -> a1 -> [Char] *Sprintf>> $(sprintf "Hello %s, showing %S and %S") "Don" 1 (5,6) > "Hello Don, showing 1 and (5,6)" > Code follows, which could be ported to use the printf/scanf language > Oleg defined. > -- ryan > {-# LANGUAGE TemplateHaskell #-} > module Sprintf where > import Language.Haskell.TH > data SprintfState = > SprintfState String (ExpQ -> ExpQ) > flush :: SprintfState -> (ExpQ -> ExpQ) > flush (SprintfState "" k) = k > flush (SprintfState s k) = (\e -> k [| $(litE $ StringL $ reverse s) ++ $e |]) > finish :: SprintfState -> ExpQ > finish (SprintfState s k) = k (litE $ StringL $ reverse s) addChar :: Char ->> SprintfState -> SprintfState > addChar c (SprintfState s e) = SprintfState (c:s) e addCode :: ExpQ ->> SprintfState -> SprintfState > addCode k s = SprintfState "" (\e -> flush s $ [| $k ++ $e |]) > sprintf' :: SprintfState -> String -> ExpQ > sprintf' k ('%':'S':cs) = [| \x -> $(sprintf' (addCode [| show x |] k) cs) |] > sprintf' k ('%':'s':cs) = [| \s -> $(sprintf' (addCode [| s |] k) cs) |] > sprintf' k ('%':'%':cs) = sprintf' (addChar '%' k) cs > sprintf' k (c:cs) = sprintf' (addChar c k) cs > sprintf' k [] = finish k sprintf :: String ->> ExpQ > sprintf = sprintf' (SprintfState "" id) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ryani.spam at gmail.com Mon Sep 1 05:08:42 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Sep 1 05:07:00 2008 Subject: [Haskell-cafe] Re: [Haskell] The initial view on typed sprintf and sscanf In-Reply-To: <1661013535.20080901123022@gmail.com> References: <20080901024041.07B71AE54@Adric.metnet.fnmoc.navy.mil> <1220254849.17108.1271490755@webmail.messagingengine.com> <20080901080025.GA27060@scytale.galois.com> <2f9b2d30809010116t484eadd7obe6f08474731808a@mail.gmail.com> <1661013535.20080901123022@gmail.com> Message-ID: <2f9b2d30809010208h5f741587jb7aa2c810a8cc0bb@mail.gmail.com> On Mon, Sep 1, 2008 at 1:30 AM, Bulat Ziganshin wrote: > of course this may be done with code generation tools (such as TH). > point of this research is to do this using type abilities of Haskell Yes, I know. My point was that TH could be used as a minimal "String -> ExpQ" wrapper, where the ExpQ is the code used by this library, to save keystrokes. I'm all about writing 100 lines of code to save 10 keystrokes per use of a function. :) > Don, i think this should be impossible with IsString since the point > is that Haskell compiler should know types at compile time. IsString > can't convert "%d" into (X int) while converting "%s" into (X String) Although of course you could use IsString to convert raw strings into 'lit "string"'; this would make the syntax slightly more palatable: > printf ("hello" ^ char ^ "world" ^ char) ' ' '!' -- ryan From Brettschneider at hs-albsig.de Mon Sep 1 05:45:12 2008 From: Brettschneider at hs-albsig.de (Brettschneider, Matthias) Date: Mon Sep 1 05:43:32 2008 Subject: [Haskell-cafe] Types in bounds Message-ID: <46E28C090A923641BFCC8D6C9CCD10B923F3BA3C23@izcexchange.ad.fh-albsig.de> Hey there, i was just thinking about types in Haskell and I asked myself, Is there a mechanism, that allows me to define a new type out of an existing one with some restrictions? So that the new type is a subset of the existing one. Lets imagine I want a type for a point like: type Point = (Int, Int) But what, if I can predict that the X and Y values are in a range between 0 and 100? If someone defines a new point like: p :: Point p = (200, 400) that is totally fine with the type definition above, but not correct in my context. Is it possible, to put this information into the type? So that the compiler is able to recognize my mistake? -- Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080901/6e3a0044/attachment.htm From waldmann at imn.htwk-leipzig.de Mon Sep 1 05:47:41 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Sep 1 05:48:01 2008 Subject: [Haskell-cafe] Types in bounds In-Reply-To: <46E28C090A923641BFCC8D6C9CCD10B923F3BA3C23@izcexchange.ad.fh-albsig.de> References: <46E28C090A923641BFCC8D6C9CCD10B923F3BA3C23@izcexchange.ad.fh-albsig.de> Message-ID: <48BBBA3D.3080208@imn.htwk-leipzig.de> > Lets imagine I want a type for a point like: > type Point = (Int, Int) > But what, if I can predict that the X and Y values are in a range between 0 and 100? 1. this only works with "dependent types", which Haskell does not have - by design (type inference/checking would be undecidable). It works in Coq, PVS etc. but there the programmer has to help the type checker (i.e. attach a proof that the type is correct) 2. using "type" (instead of "data") is generally a bad idea. J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080901/7d452515/signature.bin From waldmann at imn.htwk-leipzig.de Mon Sep 1 05:49:59 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Sep 1 05:50:20 2008 Subject: [Haskell-cafe] Types in bounds In-Reply-To: <48BBBA3D.3080208@imn.htwk-leipzig.de> References: <46E28C090A923641BFCC8D6C9CCD10B923F3BA3C23@izcexchange.ad.fh-albsig.de> <48BBBA3D.3080208@imn.htwk-leipzig.de> Message-ID: <48BBBAC7.8020307@imn.htwk-leipzig.de> >> type Point = (Int, Int) > 2. using "type" (instead of "data") is generally a bad idea. and in this case, using "data Point ..." would allow to define a "smart constructor" that can at least check at run-time whether the bounds are met. - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080901/0414ae2c/signature.bin From noteed at gmail.com Mon Sep 1 06:01:49 2008 From: noteed at gmail.com (minh thu) Date: Mon Sep 1 06:00:06 2008 Subject: [Haskell-cafe] cabal update : getHostByName Message-ID: <40a414c20809010301u2b9f4e2byc54824c54458e6de@mail.gmail.com> Hi, I've followed the instruction from the upcoming book Real World Haskell to install cabal. Now, when I enter "cabal update", it answers this: Downloading package list from server 'http://hackage.haskell.org/packages/archive' cabal: getHostByName: does not exist (no such host entry) What's the problem ? Thanks a lot, Thu From wnoise at ofb.net Mon Sep 1 06:07:42 2008 From: wnoise at ofb.net (Aaron Denney) Date: Mon Sep 1 06:06:07 2008 Subject: [Haskell-cafe] Re: Research language vs. professional language References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> <20080901082020.GB27060@scytale.galois.com> Message-ID: On 2008-09-01, Don Stewart wrote: > ryani.spam: >> On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast >> wrote: >> > This concept of `day-to-day work' is a curious one. Haskell is not a >> > mature language, and probably shouldn't ever be one. >> >> I see where you are coming from here, but I think that train has >> already started and can't be stopped. > > Yeah, it's too late. Too many people have their pay checks riding on > GHC, the Hackage library set (now up to 740 libraries and tools!), and > the continued development of the language in general. > > If Haskell's not "mature" yet, then perhaps it has reached its early > twenties, with an reliable heavy duty optimizing compiler, fast runtime, > large library set, standard documentation, testing, debugging and > packaging tools, and large community. > > And a community with a lot of energy. > > We're serious about this thing. So, what fills its shoes as a great research language with great tools? -- Aaron Denney -><- From leather at cs.uu.nl Mon Sep 1 07:51:12 2008 From: leather at cs.uu.nl (Sean Leather) Date: Mon Sep 1 07:49:29 2008 Subject: [Haskell-cafe] Re: Research language vs. professional language In-Reply-To: <3c6288ab0809010449q6cf09d03i5d018541dfa576d7@mail.gmail.com> References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> <20080901082020.GB27060@scytale.galois.com> <3c6288ab0809010449q6cf09d03i5d018541dfa576d7@mail.gmail.com> Message-ID: <3c6288ab0809010451t5aa9d5f1j421f72d8753ae5d9@mail.gmail.com> > >> > This concept of `day-to-day work' is a curious one. Haskell is not a > >> > mature language, and probably shouldn't ever be one. > >> > >> I see where you are coming from here, but I think that train has > >> already started and can't be stopped. > > > > Yeah, it's too late. Too many people have their pay checks riding on > > GHC, the Hackage library set (now up to 740 libraries and tools!), and > > the continued development of the language in general. > > > > If Haskell's not "mature" yet, then perhaps it has reached its early > > twenties, with an reliable heavy duty optimizing compiler, fast runtime, > > large library set, standard documentation, testing, debugging and > > packaging tools, and large community. > > > > We're serious about this thing. > > So, what fills its shoes as a great research language with great tools? > I think the great thing about Haskell is that it works so well now and yet there's room for growth as well. That means that not only is research with the language more efficient, but also that the research tends to be more applicative to people using it. Consider, for example, the fact that the Haskell Workshop has grown into a symposium [1] and that there are so many relevant workshops affiliated with ICFP [2]. [1] http://www.haskell.org/haskell-symposium/ [2] http://www.icfpconference.org/#Affiliated Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080901/aeed1ad4/attachment.htm From ahey at iee.org Mon Sep 1 09:02:33 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Sep 1 09:01:00 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> Message-ID: <48BBE7E9.9080306@iee.org> Ganesh Sittampalam wrote: > On Sun, 31 Aug 2008, Adrian Hey wrote: >> Eh? Please illustrate your point with Data.Unique. What requirements >> does it place on it's context? (whatever that might mean :-) > > It requires that its context initialises it precisely once. It's context being main? If so this is true, but I don't see why this is a problem. It's a happy accident with the unsafePerformIO hack as it is, and part of the defined semantics for *all* hypothetical top level <- bindings. Though to be more precise, the requirement is that it may be initialised at any time prior to first use, but never again (there's no requirement to initialise it at all if it isn't used). Also ACIO monad properties guarantee that it's always initialised to the same value regardless of when this occurs. So I don't see the problem. > Data.Unique is actually a poor example, as it is actually fine to > initialise it multiple times as long as the resulting Unique values > aren't treated as coming from the same datatype. I just don't see what you're getting at. There's no problem here and Data.Unique is not special. We don't even have to consider whether or not it's OK to reinitialise these things unless the programmer explicitly allows this in the API (which Data.Unique doesn't). This is true for all top level <- bindings. myCount :: MVar Int myCount <- newMVar 0 In a hypothetical second initialisation, do you mean.. 1 - myCount somehow gets rebound to a different/new MVar 2 - The binding stays the same but MVar gets reset to 0 without this being explicitly done in the code. I assume you mean the latter (2). But either case seems like an absurdity to me. No top level bindings randomly change halfway through a program and MVars (I hope) are not prone to random corruption (no need to suppose things are any different if they occur at the top level). > But equally it can be > implemented with IORefs, Actually it couldn't as IORefs are not an Ord instance. > so it's not a good advert for the need for > global variables. Oh please! We have to have something concrete to discuss and this is the simplest. Like I said there are a dozen or so other examples in the base package last time I counted and plenty of people have found that other libs/ffi bindings need them for safety reasons. Or at least they need something that has "global" main/process scope and so far the unsafePerformIO hack is the only known way to get that and still keep APIs stable,sane and modular. Also, AFAICS going the way that seems to be suggested of having all this stuff reflected in the arguments/types of API is going to make it practically impossible to have platform independent APIs if all platform specific implementation detail has to be accounted for in this way. >> The real irony of your remark is that making APIs this robust is >> practically impossible *without* using global variables, and you're >> now saying that because they've done this work to eliminate these >> constraints they now have to be held to account for this with >> an absurd API. > > I think there are two cases to consider here. > > A Data.Unique style library, which requires genuinely *internal* state, > and which is agnostic to having multiple copies of itself loaded > simultaneously. In that case, there is no requirement for a > process-level scope for <-, just that each instance of the library is > only initialised once - the RTS can do this, as can any dynamic loader. > > The other is some library that really cannot be safely loaded multiple > times, because it depends on some lower-level shared resource. Such a > library simply cannot be made safe without cooperation from the thing > that controls that shared resource, because you cannot prevent a second > copy of it being loaded by something you have no control over. > > If the <- proposal were only about supporting the first of these > applications, I would have far fewer objections to it. But it would have > nothing to do with process-level scope, then. The <- proposal introduces no new problems that aren't already with us. It solves 1 problem in that at least there's no room for the compiler to get it wrong or for people do use "dangerous things" when using the unsafePerformIO hack. I think that is really the only problem that can be solved at the level of Haskell language definition. I also think we need to be careful about the use of the term "process". IMO when we say the "process" defined by main, we are talking about an abstract process that is essentially defined by Haskell and may have nothing in common with a "process" as defined by various OS's (assuming there's an OS involved at all). Perhaps we should try be more clear and say "Haskell process" or "OS process" as appropriate. In particular when we say an MVar or IORef has "global" process scope (whether or not it occurs at top level) we are talking about a Haskell process, not an OS process. The issues you raise seem to me to be more to do with correct implementaton on various platforms using various tools of varying degrees of brokeness. So I don't really know what problems might be encountered in practice. But whatever these problems might be I don't think they can be fixed at the level of Haskell language definition as the solutions are likley to be platform specific "hacks". But this problem is going to be with us whether or not top level <- bindings are implemented (If they're not implemented people will still be doing the same thing with the unsafePerformIO hack). Regards -- Adrian Hey From marco-oweber at gmx.de Mon Sep 1 09:08:55 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Sep 1 09:07:14 2008 Subject: [Haskell-cafe] Types in bounds In-Reply-To: <46E28C090A923641BFCC8D6C9CCD10B923F3BA3C23@izcexchange.ad.fh-albsig.de> References: <46E28C090A923641BFCC8D6C9CCD10B923F3BA3C23@izcexchange.ad.fh-albsig.de> Message-ID: <20080901130855.GA21637@gmx.de> On Mon, Sep 01, 2008 at 11:45:12AM +0200, Brettschneider, Matthias wrote: > Hey there, > > > > i was just thinking about types in Haskell and I asked myself, > > Is there a mechanism, that allows me to define a new type out of an > existing one with some restrictions? > > So that the new type is a subset of the existing one. > > > > Lets imagine I want a type for a point like: > > type Point = (Int, Int) > > But what, if I can predict that the X and Y values are in a range between > 0 and 100? > > If someone defines a new point like: > > p :: Point > > p = (200, 400) > > that is totally fine with the type definition above, but not correct in my > context. > > > > Is it possible, to put this information into the type? So that the > compiler is able to recognize my mistake? Sure, have look at the database library haskelldb (1) It contains one module doing exactly this for Strings and it's length. There are at least two packages on hackage dealing with type level integers (eg the type-level library letting you use D1 :* D2 = 12) This way you can statically check some things, however you won't be able to statically assure that say strangeNewPoint (a,b) (c,d) = (a*c,b-d) will be within the given range as well without doing all the calculations in type level programming.. (But then you no longer need te program..) (1) http://hackage.haskell.org/packages/archive/haskelldb/0.10/doc/html/Database-HaskellDB-BoundedString.html But depending on your usage it may be the easiest apporach to live with some runtime checks (see assert in the ghc manual).. Sincerly Marc Weber From marco-oweber at gmx.de Mon Sep 1 09:14:32 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Sep 1 09:12:50 2008 Subject: [Haskell-cafe] cabal update : getHostByName In-Reply-To: <40a414c20809010301u2b9f4e2byc54824c54458e6de@mail.gmail.com> References: <40a414c20809010301u2b9f4e2byc54824c54458e6de@mail.gmail.com> Message-ID: <20080901131432.GB21637@gmx.de> On Mon, Sep 01, 2008 at 12:01:49PM +0200, minh thu wrote: > Hi, > > I've followed the instruction from the upcoming book Real World > Haskell to install cabal. > > Now, when I enter "cabal update", it answers this: > > Downloading package list from server > 'http://hackage.haskell.org/packages/archive' > cabal: getHostByName: does not exist (no such host entry) Not sure which libraries you (cabal) is using here. On some debian System there has been a dns issue. You should check wether the tool is using the curl bindings http library and look for this problem in forums of your distro. Maybe try curl That gives That gives: ... The document has moved to http://hackage.haskell.org/packages/archive/ (note the last slash) for me. Maybe also try adding the ip of hackage.haskell.org to /etc/hosts for a temporary workaround ? You should also tell us which operating system you are using. Sincerly Marc Weber From ahey at iee.org Mon Sep 1 09:17:37 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Sep 1 09:16:00 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BBE7E9.9080306@iee.org> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> Message-ID: <48BBEB71.7030705@iee.org> Adrian Hey wrote: > We have to have something concrete to discuss and this is the simplest. > Like I said there are a dozen or so other examples in the base package > last time I counted and plenty of people have found that other libs/ffi > bindings need them for safety reasons. Or at least they need something > that has "global" main/process scope and so far the unsafePerformIO hack > is the only known way to get that and still keep APIs stable,sane and > modular. Actually all this use of the tainted and derogatory term "global variable" is causing me to be imprecise. All MVars/IORefs have "global" main/process scope whether or not they're bound to something at the top level. The purpose of the top level static binding is to prevent accidental or malicious "state spoofing" if it's important that the *same* IORef/MVar is always used for some purpose. Regards -- Adrian Hey From noteed at gmail.com Mon Sep 1 09:30:21 2008 From: noteed at gmail.com (minh thu) Date: Mon Sep 1 09:28:37 2008 Subject: [Haskell-cafe] cabal update : getHostByName In-Reply-To: <20080901131432.GB21637@gmx.de> References: <40a414c20809010301u2b9f4e2byc54824c54458e6de@mail.gmail.com> <20080901131432.GB21637@gmx.de> Message-ID: <40a414c20809010630l58131ac6ke83f987c19cac17d@mail.gmail.com> 2008/9/1 Marc Weber : > On Mon, Sep 01, 2008 at 12:01:49PM +0200, minh thu wrote: >> Hi, >> >> I've followed the instruction from the upcoming book Real World >> Haskell to install cabal. >> >> Now, when I enter "cabal update", it answers this: >> >> Downloading package list from server >> 'http://hackage.haskell.org/packages/archive' >> cabal: getHostByName: does not exist (no such host entry) > > Not sure which libraries you (cabal) is using here. > On some debian System there has been a dns issue. > You should check wether the tool is using the curl bindings http library > and look for this problem in forums of your distro. > Maybe try curl That gives > That gives: ... The document has moved > to http://hackage.haskell.org/packages/archive/ (note the last slash) > for me. > > Maybe also try adding the ip of hackage.haskell.org to /etc/hosts for a > temporary workaround ? > > You should also tell us which operating system you are using. Hi, $ curl hackage.haskell.org gives me the 301 Moved Permanently too. adding 69.30.63.197 hackage.haskell.org to /etc/hosts doesn't change anything. Some info : $ cabal --version cabal-install version 0.5.2 using version 1.4.0.2 of the Cabal library I'm using Kubuntu Gutsy. Thanks, Thu From divip at aszt.inf.elte.hu Mon Sep 1 10:03:40 2008 From: divip at aszt.inf.elte.hu (=?utf-8?b?UMOpdGVy?= =?utf-8?b?RGl2acOhbnN6a3k=?=) Date: Mon Sep 1 10:08:26 2008 Subject: [Haskell-cafe] Re: cabal update : getHostByName References: <40a414c20809010301u2b9f4e2byc54824c54458e6de@mail.gmail.com> Message-ID: Hi, > Now, when I enter "cabal update", it answers this: > > Downloading package list from server > 'http://hackage.haskell.org/packages/archive' > cabal: getHostByName: does not exist (no such host entry) I received the same error message. After a month I realized that my proxy settings were wrong. (I don't need proxy but the 'http_proxy' variable was present in the shell environment.) Peter From noteed at gmail.com Mon Sep 1 10:49:55 2008 From: noteed at gmail.com (minh thu) Date: Mon Sep 1 10:48:14 2008 Subject: [Haskell-cafe] Re: cabal update : getHostByName In-Reply-To: References: <40a414c20809010301u2b9f4e2byc54824c54458e6de@mail.gmail.com> Message-ID: <40a414c20809010749q3deca576h4317737c6fac4cc6@mail.gmail.com> 2008/9/1 P?terDivi?nszky : > Hi, > >> Now, when I enter "cabal update", it answers this: >> >> Downloading package list from server >> 'http://hackage.haskell.org/packages/archive' >> cabal: getHostByName: does not exist (no such host entry) > > I received the same error message. > After a month I realized that my proxy settings were wrong. > (I don't need proxy but the 'http_proxy' variable was present in the shell > environment.) Thank you, that was that (and I've also removed https and uppercase versions). Thu From rendel at daimi.au.dk Mon Sep 1 13:06:59 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Mon Sep 1 13:05:28 2008 Subject: [Haskell-cafe] language proposal: ad-hoc overloading In-Reply-To: <2f9b2d30808311608r6e5665cdt5b6c5360d21ec1b4@mail.gmail.com> References: <2f9b2d30808311121r1c0a4155gd7f55a6d135be8a7@mail.gmail.com> <2F6A6EEF340F43F99BFAA89069EFB631@cr3lt> <2f9b2d30808311608r6e5665cdt5b6c5360d21ec1b4@mail.gmail.com> Message-ID: <48BC2133.50902@daimi.au.dk> Ryan Ingram wrote: > I maintain that in Haskell, trying to get this same generality often > leads to abuse of the typeclass system for things where the types > should trivially be determined at compile time. I don't see how that is abuse. The type class system is there for types which can be (more or less) trivially determined at compile time. Tillmann From jonathanccast at fastmail.fm Mon Sep 1 13:20:25 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Sep 1 13:18:42 2008 Subject: [Haskell-cafe] Research language vs. professional language In-Reply-To: <20080901082020.GB27060@scytale.galois.com> References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> <20080901082020.GB27060@scytale.galois.com> Message-ID: <1220289625.6369.10.camel@jonathans-macbook> On Mon, 2008-09-01 at 01:20 -0700, Don Stewart wrote: > ryani.spam: > > On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast > > wrote: > > > This concept of `day-to-day work' is a curious one. Haskell is not a > > > mature language, and probably shouldn't ever be one. > > > > I see where you are coming from here, but I think that train has > > already started and can't be stopped. > > Yeah, it's too late. Too many people have their pay checks riding on > GHC, the Hackage library set (now up to 740 libraries and tools!), and > the continued development of the language in general. > > If Haskell's not "mature" yet, then perhaps it has reached its early > twenties, with an reliable heavy duty optimizing compiler, fast runtime, > large library set, standard documentation, testing, debugging and > packaging tools, and large community. > > And a community with a lot of energy. > > We're serious about this thing. I think it's great y'all have a nice language for software development. For that matter, I think it's great *I* have a nice language for software development. ACIO, say, wouldn't really change that. But I think (and expect) Haskell should fork sometime soon, with one branch picking up ACIO and other pragmatic lets-do-this-now stuff, and another branch eschewing them in favor of concentration of research into getting around the need for such features. And, on the other hand, I can help thinking your description fits Unix from c. 1980 pretty well, about the time of the transition from V7 to BSD. Sure, the BSD developers made Unix a lot easier to use and wrote a lot of tools (with a *ton* of options, natch.), but in the process, a certain ability to hold the community to account to its highest ideals was lost. I'd like to see Haskell (including its `practical' branch) not go that route, but I think standardizing the little compromises made along the way is a terrible way to go. Haskell's highest ideals should remain pure. jcc From derek.a.elkins at gmail.com Mon Sep 1 13:40:28 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Sep 1 13:38:47 2008 Subject: [Haskell-cafe] Research language vs. professional language In-Reply-To: <20080901082020.GB27060@scytale.galois.com> References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> <20080901082020.GB27060@scytale.galois.com> Message-ID: <1220290828.5888.1.camel@derek-laptop> On Mon, 2008-09-01 at 01:20 -0700, Don Stewart wrote: > ryani.spam: > > On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast > > wrote: > > > This concept of `day-to-day work' is a curious one. Haskell is not a > > > mature language, and probably shouldn't ever be one. > > > > I see where you are coming from here, but I think that train has > > already started and can't be stopped. > > Yeah, it's too late. Too many people have their pay checks riding on > GHC, the Hackage library set (now up to 740 libraries and tools!), and > the continued development of the language in general. > > If Haskell's not "mature" yet, then perhaps it has reached its early > twenties, [..] Depending on when you count from, Haskell -is- in its early twenties or soon will be. From jonathanccast at fastmail.fm Mon Sep 1 14:04:22 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Sep 1 14:02:38 2008 Subject: [Haskell-cafe] Re: Research language vs. professional language In-Reply-To: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> Message-ID: <1220292262.6369.51.camel@jonathans-macbook> On Mon, 2008-09-01 at 01:07 -0700, Ryan Ingram wrote: > Jonathan, I think we are going to end up just disagreeing on this > subject, but I'd like to point out the reasons why we disagree. > > On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast > wrote: > > This concept of `day-to-day work' is a curious one. Haskell is not a > > mature language, and probably shouldn't ever be one. > > I see where you are coming from here, but I think that train has > already started and can't be stopped. I find Haskell interesting as a > professional programmer for these four reasons: it's pure, it's > functional, it's lazy, and it's got a great compiler. > > I don't know of any other "mature" language that can fill these shoes; > Haskell is the most mature of them. I hope not. When I used the word 'mature', I used it in the most negative possible sense: subject to industrial backwards-compatibility requirements that ensure that no feature is ever removed. Backward-compatibility is necessary for real-world languages, but it also seems to be the source of most of the really ugly interfaces in the computer industry. I think Haskell has to have the freedom to discard features --- even at the expense of backward compatibility --- if it is to continue producing neat ideas for making programming better. That's a deeply-held conviction, it's not a pragmatic `we need to discard foo now to get bar in'. By the time you reach that conversation, the decision for or against backward-compatibility has already been made. I want it made correctly (and both choices are correct, which is why I think we need two languages *both* of which take Haskell' as their starting point). > If I'm missing another language > that fits my requirements and would be better for day-to-day > programming, let me know! The serious competitors I can see are Clean > (Hackage blows away anything I've seen from that community) and > O'CaML, which is neither pure nor lazy. > > Meanwhile, Haskell is getting more suitable for regular "professional" > use every day. Look at the success of Hackage and the > soon-to-be-published "Real World Haskell" book for evidence. Haskell > solves many of the problems I have with existing languages today, and > makes me a better programmer at the same time. > > > There will always be new discoveries in purely functional programming, > > and as the art advances, features like this ad-hoc overloading hack > > (and ACIO) will become obsolete and have to be thrown over-board. > > This is a good point. However, it seems to me that the pure > programming language research is moving towards dependently typed > languages, But it's not there yet. In particular, I haven't seen a self-hosting dependently typed language; the tools seem to all be written in Haskell. So I think Research Haskell will still be needed, for a while. > and that progress in Haskell has been more > application-side; transactional memory and data-parallel, along with > research on various fusion techniques, for example. Of course, it could also be argued that language-design issues are being neglected, and hacks are being adopted without due consideration for good design. > I also think ACIO is a good theoretical starting point for research on > what initialization means, and has potential for work to influence the > commutative monads problem in general which could improve the syntax > and number of lines of code devoted to working around the verbosity of > effectful computations in Haskell. > > > I'd rather (much rather!) people concerned with day-to-day programming > > for writing programs people actually use incorporate Haskell's features > > into other, more practical, languages (as those who *actually* care about > > such things are) rather than incorporating features from day-to-day > > production languages into Haskell. > > This is already happening, of course; I think ML is going to become > pure soon, although I don't think it will ever be non-strict. And I > predict that within the next few years, lots of languages will be > leaning heavily on the concurrency research that is going on in > Haskell right now. > > But Haskell's community is also growing This is good! > and becoming more > results-oriented. This is not; see my other post. I think it's great that Haskellers are starting to accomplish useful things, but if in the process I think elders like Lennart Augustsson and Paul Hudak are starting to be ignored. Hair-shirt wearers need to have someplace to live. Up until recently, that's been Haskell. I can't help seeing putting things like ad-hoc overloading or ACIO into Haskell as theft of that territory from them, and I think it's incumbent upon those who would do such a thing to propose where the hair-shirt wearers are going to receive asylum now that they're being expelled from Haskell. (Sorry if that paragraph comes across overly strong, but I really do care strongly about this. I think keeping Augustsson, say, happy with the design of the language and libraries he uses is one of the most practical things we can do for the programmers who come after us, and I'm passionate about it.) > If you want to blame someone for this, Don Stewart > is probably your guy :) I'm just one of the johnny-come-latelies who > is realizing what a great tool Simon and the rest of the ghc team has > built. > > So, my question for you is: if Haskell is a research language, what > direction should it be taking? What changes should be happening at > the language (not the library) level that are in the interests of > improving the state-of-the-art in functional programming? As for language changes, I can think of only two semantic changes made to Haskell at the language level (in its existence) that are, even in Haskell', mature enough to standardize: (single-parameter) classes and constructor type variables. There have been a few bits of syntax sugar that represented significant break-throughs, as well (especially do-notation), but those were concomitant with library changes (everything about monads, except the do-notation syntax sugar, is a library feature, not a language feature). So I'm not going to accept that distinction. What I think are the most important research areas in Haskell: * First-class existentials. We think we know how to do this, but I'm sure somebody could get published putting it into a mature Haskell compiler. * Extensible records. See above. This exists at the library level in HList, but it could use more compiler support. * Mutable variables. (These aren't in either Haskell 98 or, IIUC, Haskell', btw.). I haven't really seen a good denotational semantics for these yet, and SPJ's operational semantics leads to bizarre language restrictions like not generalizing the type of a variable introduced by <- (as was proposed in Wadler's very first monad paper). I really don't think we understand from first principles how these work in a purely-functional language that's committed to Hindley-Milner typing and parametric polymorphism yet. * Non-parametric polymorpism. This is needed not just for Typeable (which really, really, really doesn't belong as a pure library), but some language modification is needed for IORefs, as well. I don't think we've heard the last word on any of these, as well. * Dynamic typing/dynamic loading. hsplugins seems to work in practice, although I'm a little suspicious of it (I'd investigate it further, if I hadn't discovered that running ghc -e from a perl script was as easy to use and guaranteed correct, to boot), but I'd like to see more follow-up on some of the original dynamic typing ideas. Again, we're treating dynamic typing as a library feature, when it's really a language feature. * The first-class type classes from SYB III. * Bytestrings make me uncomfortable: why isn't GHC's list implementation good enough? In general, I don't think in 20 years programmers will still be picking data structures at that level. > My goal is > to make it not be a joke when I go to work and suggest that we use > Haskell for part of our next project. What is yours? My goal is to ensure there's an even better language to propose using 10 years from now. jcc From andrewcoppin at btinternet.com Mon Sep 1 14:44:44 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Sep 1 14:43:01 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <14d615330808311433v211e24e0m2a596dba1f2c2962@mail.gmail.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <1220040768.908.67.camel@jcchost> <48BA4C58.3000807@btinternet.com> <2f9b2d30808310252h1a3be45fva1fa8b51b4ebe352@mail.gmail.com> <48BAC702.7070603@btinternet.com> <2f9b2d30808311110n1053ba4x60ec358916408b06@mail.gmail.com> <48BAED86.9060809@btinternet.com> <14d615330808311433v211e24e0m2a596dba1f2c2962@mail.gmail.com> Message-ID: <48BC381C.4000600@btinternet.com> Jeremy Apthorp wrote: > 2008/9/1 Andrew Coppin : > >> Trouble is, as soon as you allow let-bindings, some clever person is going >> to start writing recursive ones. And actually, that's a useful thing to be >> able to do, but it makes figuring out the technical details... rather >> nontrivial. (Seriously, I had no idea I was going to get into this much >> trouble!) >> > > I'm confused -- why is this different to having recursive top-level bindings? > It isn't different - and if my interpretter ever has top-level bindings, it'll introduce all the same problems. :-S From andrewcoppin at btinternet.com Mon Sep 1 14:47:00 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Sep 1 14:45:18 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48B85460.2070109@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> Message-ID: <48BC38A4.9030407@btinternet.com> Here is a *much* bigger problem: How do you check that an interpretter is correct?? You can't very easily write a QuickCheck property that will generate every possible valid expression and then check that the output of the interpretter is formally equivilent. The QuickCheck property would be a second copy of the interpretter, which proves nothing! Any hints? Just how *do* you check something large like this? I wonder - how do the GHC developers check that GHC works properly? (I guess by compiling stuff and running it... It's a bit harder to check that a lambda interpretter is working right.) From allbery at ece.cmu.edu Mon Sep 1 15:38:56 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Sep 1 15:37:19 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48BC38A4.9030407@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> Message-ID: <49928B37-F196-42BB-8D13-BE39E6A27581@ece.cmu.edu> On 2008 Sep 1, at 14:47, Andrew Coppin wrote: > I wonder - how do the GHC developers check that GHC works properly? > (I guess by compiling stuff and running it... It's a bit harder to > check that a lambda interpretter is working right.) GHC has a comprehensive test suite (not included in the source tarball or the default checkout but easily checked out atop GHC). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From nielsadb at gmail.com Mon Sep 1 16:04:49 2008 From: nielsadb at gmail.com (Niels Aan de Brugh) Date: Mon Sep 1 16:03:05 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <3e7525f0809011303l68240efrd84cda3fcfa860e6@mail.gmail.com> References: <48B09D4E.1080609@gmail.com> <22f6a8f70808231643j44b50b27j7ea20eb139229755@mail.gmail.com> <48B0A9D9.3040406@gmail.com> <1219549465.3996.12.camel@myhost> <3e7525f0809011303l68240efrd84cda3fcfa860e6@mail.gmail.com> Message-ID: <3e7525f0809011304l39426e8ap1af8fb361f5ccd6b@mail.gmail.com> On Sun, Aug 24, 2008 at 5:44 AM, Thomas M. DuBuisson < thomas.dubuisson@gmail.com> wrote: > wrt head [], Niels said: > > So now what? Action plan = [] > > Oh come now. Between ghci, hpc, and manual analysis I've never hit a > Haskell error and thrown my hands up, "I can't go any further, I'm at a > complete loss!" Also it helps that I run into this extremely rarely - I > have a larger habit of hidding black holes :-( I've never used Haskell in an engineering environment, but I have encountered problems that would've been easier to analyze with a step function (almost without exception in a stateful computation, e.g. functions using recursion or some state monad). For example, a graphical frond-end to the GHCi debugger would've been really helpful, especially for new users. C/C++ programmers on Linux have gdb but I know nobody that uses the tool directly on the bare command line. Niels said: > > Thank you for the URL, but I'm aware of the work in GHC(i). > > It might interest you to know some people actually use hpc for debugging > with reasonble success - it colors the unevaluated sections and this can > be very helpful in determining where a program stopped and threw an > exception. I haven't used HPC myself (I use -fwarn-incomplete-patterns but that's about it for "coverage" analysis) but it looks like a powerful tool. Statement and branch coverage are very imporant metrics e.g. to measure test coverage. However, I feel that using a profiler to do a debuggers job is really a poor man's solution. Just like the trace function (tracing/logging itself is useful, but not as a debugger tool). > If you have your eyes on the future you should see Dana Xu's work on > static contract checking (check out her Cambridge page). Thanks for the suggestion, I'll be sure to check that out. I use design by contract on a daily basis, but in a language like C++ it's never more than a couple of glorified asserts. My opinion is that if you want to do contracts good (i.e. not with some macro kludge) it needs to be embedded into the language. I've been looking at Spec#, that looks like a very powerful extension to C#. I think contracts could fit even better in a pure functional language. Checking contracts statically would be awesome, but doing dynamic DbC well is already harder than it seems (e.g. in concurrent code that uses locks). Regards, Niels -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080901/d93467d5/attachment.htm From g9ks157k at acme.softbase.org Mon Sep 1 16:34:07 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Sep 1 16:32:30 2008 Subject: [Haskell-cafe] getting Quickcheck 2.0 Message-ID: <200809012234.07933.g9ks157k@acme.softbase.org> Hello, is there a reason why Quickcheck 2.0 isn?t released via Hackage? Does anybody know where to get it? The darcs repository already has 2.1 as the version number in the Cabal file but Hackage still only has 1.1.0.0. Best wishes, Wolfgang From dons at galois.com Mon Sep 1 16:41:02 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 1 16:39:49 2008 Subject: [Haskell-cafe] getting Quickcheck 2.0 In-Reply-To: <200809012234.07933.g9ks157k@acme.softbase.org> References: <200809012234.07933.g9ks157k@acme.softbase.org> Message-ID: <20080901204102.GD28747@scytale.galois.com> g9ks157k: > Hello, > > is there a reason why Quickcheck 2.0 isn?t released via Hackage? Does anybody > know where to get it? The darcs repository already has 2.1 as the version > number in the Cabal file but Hackage still only has 1.1.0.0. > Andy Gill and Koen Claessen are preparing a release, to conincide with the upcoming DEFUN developer tutorial, A4 (Tutorial): Using QuickCheck and HPC - Obtaining Quality Assurance for Haskell Code http://www.deinprogramm.de/defun-2008/ Hope to see everyone there! -- Don From ganesh at earth.li Mon Sep 1 17:45:05 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 1 17:43:21 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BBEB71.7030705@iee.org> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> <48BBEB71.7030705@iee.org> Message-ID: On Mon, 1 Sep 2008, Adrian Hey wrote: > Actually all this use of the tainted and derogatory term "global > variable" is causing me to be imprecise. All MVars/IORefs have "global" > main/process scope whether or not they're bound to something at the > top level. "Global variable" is exactly the right term to use, if we are following the terminology of other languages. We don't call the result of malloc/new etc a "global variable", unless it is assigned to something with top-level scope. Ganesh From ganesh at earth.li Mon Sep 1 17:51:33 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 1 17:49:48 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BB0EC5.4080201@semantic.org> References: <534781822.20080826190130@gmail.com> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> Message-ID: On Sun, 31 Aug 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> >> That sounds more feasible - though it does constrain a plugin architecture >> (in which Haskell code can dynamically load other Haskell code) to >> cooperate with the loading RTS and not load multiple copies of modules; >> this might make linking tricky. > > This is a good idea anyway. It's up to the dynamic loading architecture > to get this right. Well, the question of whether multiple copies of a module are ok is still open, I guess - as you say later, it seems perfectly reasonable for two different versions of Data.Unique to exist, each with their own types and global variables - so why not two copies of the same version, as long as the types aren't convertible? My feeling is that the the execution of <- needs to follow the Data.Typeable instances - if the two types are the same according to Data.Typeable, then there must only be one <- executed. So another question following on from that is what happens if there isn't any datatype that is an essential part of the module - with Unique, it's fine for there to be two <-s, as long as the Uniques aren't compared. Does this kind of safety property apply elsewhere? It feels to me that this is something ACIO (or whatever it would be called after being changed) needs to explain. >> What applications does this leave beyond Data.Unique and Random? > > So far we've just looked at declaring top-level IORefs and MVars. > > By declaring top-level values of type IOWitness, you can generate open > witnesses to any type, and thus solve the expression problem. See my open > witness library and paper: > > I'd rather use Data.Typeable for this, and make sure (by whatever mechanism, e.g. compiler-enforced, or just an implicit contract) that the user doesn't break things with dodgy Typeable instances. Cheers, Ganesh From john at repetae.net Mon Sep 1 17:55:41 2008 From: john at repetae.net (John Meacham) Date: Mon Sep 1 17:53:56 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <4A3C15C3-4ACB-4375-8BA5-589EB8E772F9@ece.cmu.edu> References: <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <20080828210120.GA15616@sliver.repetae.net> <4A3C15C3-4ACB-4375-8BA5-589EB8E772F9@ece.cmu.edu> Message-ID: <20080901215541.GE30189@sliver.repetae.net> On Thu, Aug 28, 2008 at 07:21:48PM -0400, Brandon S. Allbery KF8NH wrote: >> OS provided one? What if you have an exokernel, where it is expected >> these things _will_ be implemented in the userspace code. why >> shouldn't >> that part of the exokernel be written in haskell? > > What's stopping it? Just wrap it in a state-carrying monad representing > a context. That way you can also keep multiple contexts if necessary > (and I think it is often necessary, or at least desirable, with most > exokernel clients). That is exactly what I want to do, with the 'IO' monad. but I would like the IO primitives to be implementable in haskell _or_ C transparently and efficiently. It should not matter how the primitives are implemented. John -- John Meacham - ?repetae.net?john? From john at repetae.net Mon Sep 1 18:03:29 2008 From: john at repetae.net (John Meacham) Date: Mon Sep 1 18:01:44 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> <48BBEB71.7030705@iee.org> Message-ID: <20080901220329.GF30189@sliver.repetae.net> On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote: >> Actually all this use of the tainted and derogatory term "global >> variable" is causing me to be imprecise. All MVars/IORefs have "global" >> main/process scope whether or not they're bound to something at the >> top level. > > "Global variable" is exactly the right term to use, if we are following > the terminology of other languages. We don't call the result of > malloc/new etc a "global variable", unless it is assigned to something > with top-level scope. global variable is not a very precise term in other languages for various platforms too a lot of times. for instance, windows dll's have the ability to share individual variables across all loadings of said dll. (for better or worse.) Haskell certainly has more advanced scoping capabilities than other languages so we need a more refined terminology. I think 'IO scope' is the more precise term, as it implys the scope is that of the IO monad state. which may or may not correspond to some external 'process scope'. John -- John Meacham - ?repetae.net?john? From john at repetae.net Mon Sep 1 18:07:53 2008 From: john at repetae.net (John Meacham) Date: Mon Sep 1 18:06:09 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B8875E.5080406@imageworks.com> References: <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> Message-ID: <20080901220752.GG30189@sliver.repetae.net> On Fri, Aug 29, 2008 at 04:33:50PM -0700, Dan Weston wrote: > C++ faced this very issue by saying that with global data, uniqueness of > initialization is guaranteed but order of evaluation is not. Assuming > that the global data are merely thunk wrappers over some common data > source, this means that at minimum, there can be no data dependencies > between plugins where the order of evaluation matters. Fortunately, we can do a whole lot better with haskell, the type system guarentees that order of evaluation is irrelevant :) no need to specify anything about implementations. John -- John Meacham - ?repetae.net?john? From ganesh at earth.li Mon Sep 1 18:08:45 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 1 18:07:00 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080901220329.GF30189@sliver.repetae.net> References: <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> <48BBEB71.7030705@iee.org> <20080901220329.GF30189@sliver.repetae.net> Message-ID: On Mon, 1 Sep 2008, John Meacham wrote: > On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote: >>> Actually all this use of the tainted and derogatory term "global >>> variable" is causing me to be imprecise. All MVars/IORefs have "global" >>> main/process scope whether or not they're bound to something at the >>> top level. >> >> "Global variable" is exactly the right term to use, if we are following >> the terminology of other languages. We don't call the result of >> malloc/new etc a "global variable", unless it is assigned to something >> with top-level scope. > > global variable is not a very precise term in other languages for > various platforms too a lot of times. for instance, windows dll's have > the ability to share individual variables across all loadings of said > dll. (for better or worse.) Interesting, is this just within a single process? > Haskell certainly has more advanced scoping capabilities than other > languages so we need a more refined terminology. I think 'IO scope' is > the more precise term, as it implys the scope is that of the IO monad > state. which may or may not correspond to some external 'process scope'. Hmm, to me that implies that if the IO monad stops and restarts, e.g. when a Haskell library is being called from an external library, then the scope stops and starts again (which I presume is not the intention of <- ?) But I don't really care that much about the name, if there is consensus on what to call it that doesn't cause ambiguities with OS processes etc. Cheers, Ganesh From allbery at ece.cmu.edu Mon Sep 1 18:15:22 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Sep 1 18:14:05 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> <48BBEB71.7030705@iee.org> <20080901220329.GF30189@sliver.repetae.net> Message-ID: <0352E508-CF81-4597-AE7C-8830909FA18E@ece.cmu.edu> On 2008 Sep 1, at 18:08, Ganesh Sittampalam wrote: > On Mon, 1 Sep 2008, John Meacham wrote: >> On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote: >>>> Actually all this use of the tainted and derogatory term "global >>>> variable" is causing me to be imprecise. All MVars/IORefs have >>>> "global" >>>> main/process scope whether or not they're bound to something at the >>>> top level. >>> >>> "Global variable" is exactly the right term to use, if we are >>> following >>> the terminology of other languages. We don't call the result of >>> malloc/new etc a "global variable", unless it is assigned to >>> something >>> with top-level scope. >> >> global variable is not a very precise term in other languages for >> various platforms too a lot of times. for instance, windows dll's >> have >> the ability to share individual variables across all loadings of said >> dll. (for better or worse.) > > Interesting, is this just within a single process? Last I checked, it was across processes; that is, every DLL has its own (optional) data segment which is private to the DLL but shared across all system-wide loaded instances of the DLL. This actually goes back to pre-NT Windows. >> Haskell certainly has more advanced scoping capabilities than other >> languages so we need a more refined terminology. I think 'IO scope' >> is the more precise term, as it implys the scope is that of the IO >> monad state. which may or may not correspond to some external >> 'process scope'. > > Hmm, to me that implies that if the IO monad stops and restarts, > e.g. when a Haskell library is being called from an external > library, then the scope stops and starts again (which I presume is > not the intention of <- ?) It tells me the flow of execution has temporarily exited the scope of the IO monad, but can return to it. The state is suspended, not exited. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dons at galois.com Mon Sep 1 18:18:13 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 1 18:16:24 2008 Subject: [Haskell-cafe] Fast parallel binary-trees for the shootout: Control.Parallel.Strategies FTW! Message-ID: <20080901221813.GE28747@scytale.galois.com> The Computer Language Benchmarks Game recently got a quad core 64 bit machine. Initial results just porting the single-threaded Haskell benchmarks to 64 bit look rather pleasing, http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all Note that C++, D, Clean et al aren't ported to the 64 bit machine yet (and perhaps some implementations won't survive the 64 bit switch). Now, none of the Haskell programs are annotated for parallelism yet, despite that quad core sitting there ready to go. I've a conjecture that fast, smp capable, concise code, of the kind GHC produces, could dominate the shootout for a while to come, if we can effectively utilise those cores. This is a chance to make an impression! So, the first parallel benchmark has been submitted by Tom Davies and me, a parallel implementation of the binary-trees benchmark, using the Control.Parallel.Strategies lib to set up some top level parallel tasks. Initial results look promising, with the old entry: * Single core, no heap hints: 26.9s $ ghc -O2 -fasm Original.hs --make $ time ./Original 20 ./Original 20 26.79s user 0.16s system 100% cpu 26.933 total Looking at the GC stats (-sstderr) we see its spending too much time doing GC, 57.8%, so we can improve that by setting a default heap size: * Single core, with heap hints: 13.7s $ time ./Original 20 -A350M ... ./Original 20 +RTS -A350M 13.54s user 0.27s system 100% cpu 13.791 total Halves runtime in comparison to the current entry, and reduces GC to 3.8%. * Now, the parallel version, changing one line to use a parMap strategy, and using the N+1 capabilities rule, $ ghc -O2 -fasm Parallel2.hs --make -threaded $ time ./Parallel2 20 +RTS -N5 -A350M ... ./Parallel2 20 +RTS -N5 -A350M 15.38s user 1.57s system 305% cpu 5.684 total So 305% productive (not too bad for this memory-heavy program), and a good speedup. Observations: * check GC stats with -sstderr, then use -AxxxM to set a default heap size * parallelise the top level control using speculative strategies * Use -N+1 capabilities. -- Don -------------- next part -------------- {-# OPTIONS -fbang-patterns -funbox-strict-fields #-} -- -- The Computer Language Shootout -- http://shootout.alioth.debian.org/ -- -- Contributed by Don Stewart -- import System import Data.Bits import Text.Printf -- -- an artificially strict tree. -- -- normally you would ensure the branches are lazy, but this benchmark -- requires strict allocation. -- data Tree = Nil | Node !Int !Tree !Tree minN = 4 io s n t = printf "%s of depth %d\t check: %d\n" s n t main = do n <- getArgs >>= readIO . head let maxN = max (minN + 2) n stretchN = maxN + 1 -- stretch memory tree let c = check (make 0 stretchN) io "stretch tree" stretchN c -- allocate a long lived tree let !long = make 0 maxN -- allocate, walk, and deallocate many bottom-up binary trees let vs = depth minN maxN mapM_ (\((m,d,i)) -> io (show m ++ "\t trees") d i) vs -- confirm the the long-lived binary tree still exists io "long lived tree" maxN (check long) -- generate many trees depth :: Int -> Int -> [(Int,Int,Int)] depth d m | d <= m = (2*n,d,sumT d n 0) : depth (d+2) m | otherwise = [] where n = 1 `shiftL` (m - d + minN) -- allocate and check lots of trees sumT :: Int -> Int -> Int -> Int sumT d 0 t = t sumT d i t = sumT d (i-1) (t + a + b) where a = check (make i d) b = check (make (-i) d) -- traverse the tree, counting up the nodes check :: Tree -> Int check Nil = 0 check (Node i l r) = i + check l - check r -- build a tree make :: Int -> Int -> Tree make i 0 = Node i Nil Nil make i d = Node i (make (i2-1) d2) (make i2 d2) where i2 = 2*i; d2 = d-1 -------------- next part -------------- {-# OPTIONS -fbang-patterns -funbox-strict-fields #-} -- -- The Computer Language Shootout -- http://shootout.alioth.debian.org/ -- -- Contributed by Don Stewart and Thomas Davie -- -- This implementation uses a parallel strategy to exploit the quad core machine. -- For more information about Haskell parallel strategies, see, -- -- http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html -- import System import Data.Bits import Text.Printf import Control.Parallel.Strategies import Control.Parallel -- -- an artificially strict tree. -- -- normally you would ensure the branches are lazy, but this benchmark -- requires strict allocation. -- data Tree = Nil | Node !Int !Tree !Tree minN = 4 io s n t = printf "%s of depth %d\t check: %d\n" s n t main = do n <- getArgs >>= readIO . head let maxN = max (minN + 2) n stretchN = maxN + 1 -- stretch memory tree let c = check (make 0 stretchN) io "stretch tree" stretchN c -- allocate a long lived tree let !long = make 0 maxN -- allocate, walk, and deallocate many bottom-up binary trees let vs = (parMap rnf) (depth' maxN) [minN,minN+2..maxN] mapM_ (\((m,d,i)) -> io (show m ++ "\t trees") d i) vs -- confirm the the long-lived binary tree still exists io "long lived tree" maxN (check long) -- generate many trees depth' :: Int -> Int -> (Int,Int,Int) depth' m d = (2*n,d,sumT d n 0) where n = 1 `shiftL` (m - d + minN) -- allocate and check lots of trees sumT :: Int -> Int -> Int -> Int sumT d 0 t = t sumT d i t = sumT d (i-1) (t + a + b) where a = check (make i d) b = check (make (-i) d) -- traverse the tree, counting up the nodes check :: Tree -> Int check Nil = 0 check (Node i l r) = i + check l - check r -- build a tree make :: Int -> Int -> Tree make i 0 = Node i Nil Nil make i d = Node i (make (i2-1) d2) (make i2 d2) where i2 = 2*i; d2 = d-1 From ganesh at earth.li Mon Sep 1 18:20:37 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 1 18:18:52 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <0352E508-CF81-4597-AE7C-8830909FA18E@ece.cmu.edu> References: <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> <48BBEB71.7030705@iee.org> <20080901220329.GF30189@sliver.repetae.net> <0352E508-CF81-4597-AE7C-8830909FA18E@ece.cmu.edu> Message-ID: On Mon, 1 Sep 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 1, at 18:08, Ganesh Sittampalam wrote: >> On Mon, 1 Sep 2008, John Meacham wrote: >>> for instance, windows dll's have >>> the ability to share individual variables across all loadings of said >>> dll. (for better or worse.) >> >> Interesting, is this just within a single process? > > Last I checked, it was across processes; that is, every DLL has its own > (optional) data segment which is private to the DLL but shared across > all system-wide loaded instances of the DLL. This actually goes back to > pre-NT Windows. Sounds like a recipe for fun :-) >>> Haskell certainly has more advanced scoping capabilities than other >>> languages so we need a more refined terminology. I think 'IO scope' is the >>> more precise term, as it implys the scope is that of the IO monad state. >>> which may or may not correspond to some external 'process scope'. >> >> Hmm, to me that implies that if the IO monad stops and restarts, e.g. when >> a Haskell library is being called from an external library, then the scope >> stops and starts again (which I presume is not the intention of <- ?) > > It tells me the flow of execution has temporarily exited the scope of the IO > monad, but can return to it. The state is suspended, not exited. In that case we could equally call the things "library scope", as that's the only scope they're visible in unless exported. Anyway, as long as we're clear on what it means, the name doesn't really matter. Ganesh From ganesh at earth.li Mon Sep 1 18:21:03 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 1 18:19:23 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BBE7E9.9080306@iee.org> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> Message-ID: On Mon, 1 Sep 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> On Sun, 31 Aug 2008, Adrian Hey wrote: >>> Eh? Please illustrate your point with Data.Unique. What requirements >>> does it place on it's context? (whatever that might mean :-) >> >> It requires that its context initialises it precisely once. > > It's context being main? If so this is true, but I don't see why this > is a problem. [...] Also ACIO monad properties guarantee that it's > always initialised to the same value regardless of when this occurs. > So I don't see the problem. You see this as a requirement that can be discharged by adding the ACIO concept; I see it as a requirement that should be communicated in the type. Another way of looking at it is that Data.Unique has associated with it some context in which Unique values are safely comparable. You want that context to always be the top-level/RTS scope, I would like the defining that context to be part of the API. >> Data.Unique is actually a poor example, as it is actually fine to >> initialise it multiple times as long as the resulting Unique values >> aren't treated as coming from the same datatype. > > I just don't see what you're getting at. There's no problem here > and Data.Unique is not special. See the conversation with Ashley - you can have multiple copies of Data.Unique loaded without problem, as long as the resulting Unique datatypes aren't comparable with each other. > myCount :: MVar Int > myCount <- newMVar 0 > > In a hypothetical second initialisation, do you mean.. > 1 - myCount somehow gets rebound to a different/new MVar I mean this. Or, more precisely, that a *different* myCount gets bound to a different MVar. >> But equally it can be implemented with IORefs, > > Actually it couldn't as IORefs are not an Ord instance. Well, perhaps one could be added (along with hashing). Or perhaps it's not really needed; I don't know as I've never used Data.Unique, and I doubt I ever would as when I need a name supply I also want human readable names, and I can't think of any other uses for it, though no doubt some exist. >> so it's not a good advert for the need for global variables. > > Oh please! > > We have to have something concrete to discuss and this is the simplest. > Like I said there are a dozen or so other examples in the base package > last time I counted Would you mind listing them? It might help provide some clarity to the discussion. > and plenty of people have found that other libs/ffi bindings need them > for safety reasons. Or at least they need something that has "global" > main/process scope and so far the unsafePerformIO hack is the only known > way to get that and still keep APIs stable,sane and modular. Again, some specific examples would help. > Also, AFAICS going the way that seems to be suggested of having all this > stuff reflected in the arguments/types of API is going to make it > practically impossible to have platform independent APIs if all platform > specific implementation detail has to be accounted for in this way. It can all be wrapped up in a single abstract context argument; the only platform "bleed" would be if one platform needed a context argument but others didn't. >> I think there are two cases to consider here. >> >> A Data.Unique style library, which requires genuinely *internal* state, and >> which is agnostic to having multiple copies of itself loaded >> simultaneously. In that case, there is no requirement for a process-level >> scope for <-, just that each instance of the library is only initialised >> once - the RTS can do this, as can any dynamic loader. >> >> The other is some library that really cannot be safely loaded multiple >> times, because it depends on some lower-level shared resource. Such a >> library simply cannot be made safe without cooperation from the thing that >> controls that shared resource, because you cannot prevent a second copy of >> it being loaded by something you have no control over. >> >> If the <- proposal were only about supporting the first of these >> applications, I would have far fewer objections to it. But it would have >> nothing to do with process-level scope, then. > > The <- proposal introduces no new problems that aren't already with us. > It solves 1 problem in that at least there's no room for the compiler to > get it wrong or for people do use "dangerous things" when using the > unsafePerformIO hack. I think that is really the only problem that can > be solved at the level of Haskell language definition. I just want to be clear that the second of the two categories above cannot be used to justify the proposal, as it does not make them safe. > I also think we need to be careful about the use of the term "process". > > IMO when we say the "process" defined by main, we are talking about an > abstract process that is essentially defined by Haskell and may have > nothing in common with a "process" as defined by various OS's (assuming > there's an OS involved at all). Perhaps we should try be more clear and > say "Haskell process" or "OS process" as appropriate. In particular > when we say an MVar or IORef has "global" process scope (whether or > not it occurs at top level) we are talking about a Haskell process, > not an OS process. We could call it "Haskell RTS scope" if you like; the term "Haskell process" is meaningless to me. Top-level scope, as defined in the emails between Ashley and myself, is also ok. > The issues you raise seem to me to be more to do with correct > implementaton on various platforms using various tools of varying > degrees of brokeness. No, it's about correct implementation with different models of dynamic loading. None of the possibilities I am envisaging are broken, per se, though they might well break the <- proposal. > But this problem is going to be with us whether or not top level <- > bindings are implemented (If they're not implemented people will > still be doing the same thing with the unsafePerformIO hack). But then it will be easier to point to their libraries as being at fault when something goes wrong. Ganesh From dons at galois.com Mon Sep 1 18:25:39 2008 From: dons at galois.com (Don Stewart) Date: Mon Sep 1 18:23:51 2008 Subject: [Haskell-cafe] Fast parallel binary-trees for the shootout: Control.Parallel.Strategies FTW! In-Reply-To: <20080901221813.GE28747@scytale.galois.com> References: <20080901221813.GE28747@scytale.galois.com> Message-ID: <20080901222539.GF28747@scytale.galois.com> dons: > The Computer Language Benchmarks Game recently got a quad core 64 bit > machine. Initial results just porting the single-threaded Haskell > benchmarks to 64 bit look rather pleasing, > > http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all > > Note that C++, D, Clean et al aren't ported to the 64 bit machine yet > (and perhaps some implementations won't survive the 64 bit switch). I've started a wiki page for parallel benchmark submissions, http://haskell.org/haskellwiki/Shootout/Parallel If you submit parallel versions, please add them here so we can collect ideas and hints. -- Don From ashley at semantic.org Mon Sep 1 18:38:28 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Sep 1 18:36:44 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> Message-ID: <48BC6EE4.5000109@semantic.org> Ganesh Sittampalam wrote: > Well, the question of whether multiple copies of a module are ok is > still open, I guess - as you say later, it seems perfectly reasonable > for two different versions of Data.Unique to exist, each with their own > types and global variables - so why not two copies of the same version, > as long as the types aren't convertible? My feeling is that the the > execution of <- needs to follow the Data.Typeable instances - if the two > types are the same according to Data.Typeable, then there must only be > one <- executed. They will be different types if they are in different package versions. Thus they could have different instances of Typeable. But why do we care about Typeable? > So another question following on from that is what happens if there > isn't any datatype that is an essential part of the module - with > Unique, it's fine for there to be two <-s, as long as the Uniques aren't > compared. Does this kind of safety property apply elsewhere? It feels to > me that this is something ACIO (or whatever it would be called after > being changed) needs to explain. In the internal implementation of Unique, there must be only one MVar constructed with <- per Unique type, i.e. per package version. This will work correctly, since values of Unique types from different package versions have different types, and thus cannot be compared. Unique values constructed at top level by <- will also be unique and will work correctly. ua <- newUnique ub <- newUnique Here ua == ub will evaluate to False. > I'd rather use Data.Typeable for this, and make sure (by whatever > mechanism, e.g. compiler-enforced, or just an implicit contract) that > the user doesn't break things with dodgy Typeable instances. You don't think that's rather ugly: a class that needs special "deriving" behaviour? I'd actually like to get rid of all special-case "deriving": it should be for newtypes only. Implicit contract is worse. I really shouldn't be able to write coerce without referring to something marked "unsafe" or "foreign". Have we stopped caring about soundness? In addition, one can only have one Typeable instance per type. By contrast, one can create multiple IOWitness values for the same type. For example, one can very easily create a system of open exceptions for IO, with an IOWitness value for each exception type, witnessing to the data that the exception carries. -- Ashley Yakeley From ganesh at earth.li Mon Sep 1 18:49:38 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 1 18:47:54 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BC6EE4.5000109@semantic.org> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> Message-ID: On Mon, 1 Sep 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> Well, the question of whether multiple copies of a module are ok is still >> open, I guess - as you say later, it seems perfectly reasonable for two >> different versions of Data.Unique to exist, each with their own types and >> global variables - so why not two copies of the same version, as long as >> the types aren't convertible? My feeling is that the the execution of <- >> needs to follow the Data.Typeable instances - if the two types are the same >> according to Data.Typeable, then there must only be one <- executed. > > They will be different types if they are in different package versions. Right, but they might be the same package version, if one is a dynamically loaded bit of code and the other isn't. > Thus they could have different instances of Typeable. But why do we care > about Typeable? Because of the coercion operation that follows from it. >> So another question following on from that is what happens if there isn't >> any datatype that is an essential part of the module - with Unique, it's >> fine for there to be two <-s, as long as the Uniques aren't compared. Does >> this kind of safety property apply elsewhere? It feels to me that this is >> something ACIO (or whatever it would be called after being changed) needs >> to explain. > > In the internal implementation of Unique, there must be only one MVar > constructed with <- per Unique type, i.e. per package version. This will > work correctly, since values of Unique types from different package > versions have different types, and thus cannot be compared. > > Unique values constructed at top level by <- will also be unique and will > work correctly. My question was actually about what happens with some different library that needs <-; how do we know whether having two <-s is safe or not? >> I'd rather use Data.Typeable for this, and make sure (by whatever >> mechanism, e.g. compiler-enforced, or just an implicit contract) that the >> user doesn't break things with dodgy Typeable instances. > > You don't think that's rather ugly: a class that needs special "deriving" > behaviour? I'd actually like to get rid of all special-case "deriving": it > should be for newtypes only. No, it seems like the right way to do introspection to me, rather than adding some new mechanism for describing a datatype as your paper suggests. > Implicit contract is worse. I really shouldn't be able to write coerce > without referring to something marked "unsafe" or "foreign". Have we > stopped caring about soundness? We could arrange for the class member of Typeable to be called "unsafe...". > In addition, one can only have one Typeable instance per type. By > contrast, one can create multiple IOWitness values for the same type. > For example, one can very easily create a system of open exceptions for > IO, with an IOWitness value for each exception type, witnessing to the > data that the exception carries. I don't see what the point of multiple values is, I'm afraid. A single instance of Typeable is fine for doing type equality tests. Cheers, Ganesh From ashley at semantic.org Mon Sep 1 20:02:12 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Sep 1 20:00:28 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> Message-ID: <48BC8284.9030305@semantic.org> Ganesh Sittampalam wrote: > Right, but they might be the same package version, if one is a > dynamically loaded bit of code and the other isn't. OK. It's up to the dynamic loader to deal with this, and make sure that initialisers are not run more than once when it loads the package into the RTS. The scopes and names are all well-defined. How hard is this? > My question was actually about what happens with some different library > that needs <-; how do we know whether having two <-s is safe or not? I don't understand. When is it not safe? > No, it seems like the right way to do introspection to me, rather than > adding some new mechanism for describing a datatype as your paper > suggests. Aesthetic arguments are always difficult. The best I can say is, why are some classes blessed with a special language-specified behaviour? It looks like an ugly hack to me. We have a class with a member that may be safely exposed to call, but not safely exposed to define. How is this the right way? By contrast, top-level <- is straightforward to understand. Even the scope issues are not hard. It's safe, it doesn't privilege a class with special and hidden functionality, it doesn't introspect into types, and it allows individual unique values rather than just unique instances per type. And it also allows top-level IORefs and MVars. > We could arrange for the class member of Typeable to be called "unsafe...". We could, but it's not actually unsafe to call as such. It's only unsafe to implement. And if we're going the implicit contract route, we have to resort to unsafe functions to do type representation. It's not necessary, and seems rather against the spirit of Haskell. Time was when people would insist that unsafePerformIO wasn't Haskell, though perhaps useful for debugging. Now we have all these little unsafe things because people think they're necessary, and there's an implicit contract forced on the user not to be unsafe. But it turns out that they're not necessary. > I don't see what the point of multiple values is, I'm afraid. A single > instance of Typeable is fine for doing type equality tests. Sometimes you want to do witness equality tests rather than type equality tests. For instance, I might have a "foo" exception and a "bar" exception, both of which carry an Int. Rather than create new Foo and Bar types, I can just create a new witness for each. Or if I want, I can create a dictionary of heterogeneous items, with IOWitness values as keys. Then I can do a top-level <- to declare keys in this dictionary. Now I've got OOP objects. -- Ashley Yakeley From rendel at daimi.au.dk Mon Sep 1 20:06:21 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Mon Sep 1 20:04:52 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48BC38A4.9030407@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> Message-ID: <48BC837D.8020706@daimi.au.dk> Andrew Coppin wrote: > Here is a *much* bigger problem: How do you check that an interpretter > is correct?? Before checking for correctness, you have to define correctness. What is the specification of your interpreter? > You can't very easily write a QuickCheck property that will generate > every possible valid expression and then check that the output of the > interpretter is formally equivilent. The QuickCheck property would be a > second copy of the interpretter, which proves nothing! Well, if you have two *different* interpreters, that would at least reassure you somewhat. Consider a naive substituation-based interpreter and a clever environment-based interpreter. The former is often easier to write and easier to get correct, and the latter is often what you want in the end. Since you seem to be implementing a standard language, you could use an existing implementation to check against. many lambda calculus style languages can easily be transformed into scheme, for example. > Any hints? Just how *do* you check something large like this? You could write a lot of test cases, calculating the correct answers by hand. You could check that during evaluation, you have always wellformed terms (e.g. evaluation does not introduce new free variables). You could even check that after evaluation stops, you have indeed a normal form. You could try to check the components of your interpreter (e.g. environment lookup, term substituation, simplification) independently. Tillmann From allbery at ece.cmu.edu Mon Sep 1 23:18:14 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Sep 1 23:16:36 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48BC837D.8020706@daimi.au.dk> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> Message-ID: <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> On 2008 Sep 1, at 20:06, Tillmann Rendel wrote: > Andrew Coppin wrote: >> Any hints? Just how *do* you check something large like this? > > You could write a lot of test cases, calculating the correct answers > by hand. > > You could check that during evaluation, you have always wellformed > terms (e.g. evaluation does not introduce new free variables). You > could even check that after evaluation stops, you have indeed a > normal form. > > You could try to check the components of your interpreter (e.g. > environment lookup, term substituation, simplification) independently. You can define a set of valid transformations, have the interpreter log each transformation, and verify that all are correct (that is, that both the transformation and the logged result are correct. This assumes the interpreter can be resolved down to a sufficiently simple set of transformations; if not, you're right back at having the tester being the interpreter itself. Note that you don't check if the transformation plan for the program matches a specified list, just that all transformations are correct. (Just remember that "logic is an organized way of going wrong with confidence.") -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From marco-oweber at gmx.de Tue Sep 2 00:12:56 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Sep 2 00:11:13 2008 Subject: [Haskell-cafe] It's not a monad - what is it? looking for nice syntactic sugar, customizable do notation? In-Reply-To: <20080901031024.GC9353@gmx.de> References: <20080830015846.GB7458@gmx.de> <20080831215054.GA9353@gmx.de> <20080901031024.GC9353@gmx.de> Message-ID: <20080902041256.GC8956@gmx.de> Context: Basic xml validation of vxml does work now. So I'm looking for a convinient way to use it. (1) My first approach: putStrLn $ xml $ ((html_T << ( head_T << (title_T <<< "hw") << (link_T `rel_A` "stylesheet" `type_A` "text/css" `href_A` "style.css") )) << ( body_T << ((script_T `type_A` "text/javascript") <<< "document.writeln('hi');" ) << (div_T `onclick_A` "alert('clicked');" `style_A` "color:#F79" <<< "text within the div" ) ) ) comment: That's straight forward: >> : add subelement >>> : add text However having to use many parenthesis to get nesting is awkward. (2) My second idea: (#) = flip (.) putStrLn $ xml $ ( headC ( (titleC (<<< "hw")) # (linkC (rel_AF "stylesheet" # type_AF "text/css" # href_AF "style.css" ) ) ) # bodyC ( scriptC ( type_AF "text/javascript" # text "document.writeln('hi');" ) # divC ( onclick_AF "alert('clicked')" # style_AF "color:#F79" # text "text within the div" ) ) ) html_T comment: headC a b = head with context where a is a function adding subelements then adding itself to the elemnt passed by b Thus headC id parent would add headC to parent I don't feel much luckier this way (3) Third idea: xmlWithInnerIO <- execXmlT $ do xmlns "http://www.w3.org/1999/xhtml" >> lang "en-US" >> xml:lang "en-US" head $ title $ text "minimal" body $ do args <- lift $ getArgs h1 $ text "minimal" div $ text $ "args passed to this program: " ++ (show args) comment: WASH is using do notation which is really convinient. elements beeing at the same level can be concatenated by new lines, subelemnts can be added really nice as well. However: This can't work. (>>) :: m a -> m b -> m b but I need this (>>) :: m a -> m' b -> m'' b or (>>) :: m st a -> m st' b -> m st'' b along with functional dependencies that st' can be deduced from st and st'' from st'.. There are some happy cases eg when having a DTD such as (a | b)* because the state will "loop" and not change.. But this is no solution. (4) Another way would be defining << : (add subelement <|> : concatenate same level (+++) of xhtml lib html << head << title <<< "title" <|> meta .. <|> body << div <|> div However you already see the trouble.. ghc will read this as (html << (head << (title <<< "title"))) <|> meta .. <|> (body << div) -- body should be added to html, not to head! <|> div There would be a solution using different fixities html <<1 head <<2 title <<< "title" <|2> meta <|1> body <<2 div <|2> div <<3 div <<4 div so that <<4 binds stronger than <<3 etc.. But I think thats awkward as well. (5) But ghc is rich, I can think of another way: Quasi Quoting.. [$makeAFun| html do head do meta $1 link $2 body do div $3 div $4 |] (Dollar1 "bar") (Dollar2 "foo") (Dollar3 "foo3") (Dollar4 "foo4") the wrapper type sDollar{1,2,3,4} aren't necessary, but they will help eg if you remove the $2 line. They also enable you using a substitute more than once. (6) Another solution would be writing a preprocesor reusing alreday exsting code (HSP or WASH ?) or the haskell-src packages? Is there yet another solution which I've missed? I still think that (3) would be superiour.. Is there a way to define my own >>= and >> functions such as: {-# define custom do doX; (>>=) : mybind , >> : "my>>" #-} body $ doX args <- lift $ getArgs This would be terrific. Sincerly Marc Weber From marco-oweber at gmx.de Tue Sep 2 00:39:44 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Sep 2 00:38:00 2008 Subject: [Haskell-cafe] It's not a monad - what is it? looking for nice syntactic sugar, customizable do notation? In-Reply-To: <20080902041256.GC8956@gmx.de> References: <20080830015846.GB7458@gmx.de> <20080831215054.GA9353@gmx.de> <20080901031024.GC9353@gmx.de> <20080902041256.GC8956@gmx.de> Message-ID: <20080902043944.GD8956@gmx.de> > I still think that (3) would be superiour.. > Is there a way to define my own >>= and >> functions such as: > > {-# define custom do doX; > (>>=) : mybind , >> : "my>>" #-} > body $ doX > args <- lift $ getArgs > This would be terrific. > > Sincerly > Marc Weber dons has told me about 06:27 < dons> http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax 06:27 < lambdabot> Title: 8.3.?Syntactic extensions, example : module Main where import Prelude import Debug.Trace import System.IO main = do let (>>=) a b = trace (show "woah") $ (Prelude.>>=) a b getLine >>= print so actually this can be done? I'll try it. Marc Weber From ganesh at earth.li Tue Sep 2 01:00:48 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue Sep 2 00:59:02 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BC8284.9030305@semantic.org> References: <534781822.20080826190130@gmail.com> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> Message-ID: On Mon, 1 Sep 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> Right, but they might be the same package version, if one is a dynamically >> loaded bit of code and the other isn't. > > OK. It's up to the dynamic loader to deal with this, and make sure that > initialisers are not run more than once when it loads the package into the > RTS. The scopes and names are all well-defined. How hard is this? I have a feeling it might be non-trivial; the dynamically loaded bit of code will need a separate copy of the module in question, since it might be loaded into something where the module is not already present. So it'll have a separate copy of the global variable in a separate location, and the dynamic loader needs to arrange to do something weird, like copying the value of the first run <- to the second one instead of running it again. > >> My question was actually about what happens with some different library >> that needs <-; how do we know whether having two <-s is safe or not? > > I don't understand. When is it not safe? Well, the safety of <- being run twice in the Data.Unique case is based around the two different Data.Unique types not being compatible. Let's suppose some other module uses a <-, but returns things based on that <- that are some standard type, rather than a type it defines itself. Is module duplication still safe? >> No, it seems like the right way to do introspection to me, rather than >> adding some new mechanism for describing a datatype as your paper >> suggests. > > Aesthetic arguments are always difficult. The best I can say is, why are > some classes blessed with a special language-specified behaviour? Well, let me put it this way; since I don't like <-, and I don't particularly mind Typeable, I wouldn't accept IOWitness as an example of something that requires <- to implement correctly, because I don't see any compelling feature that you can only implement with <-. >> We could arrange for the class member of Typeable to be called "unsafe...". > > We could, but it's not actually unsafe to call as such. It's only unsafe to > implement. That's fine, it can export a non-class member without the unsafe prefix. > And if we're going the implicit contract route, we have to resort to > unsafe functions to do type representation. It's not necessary, and > seems rather against the spirit of Haskell. > > Time was when people would insist that unsafePerformIO wasn't Haskell, > though perhaps useful for debugging. Now we have all these little unsafe > things because people think they're necessary, and there's an implicit > contract forced on the user not to be unsafe. But it turns out that > they're not necessary. There's some unsafety somewhere in both Typeable and IOWitnesses, and in both cases it can be completely hidden from the user - with Typeable, just don't let the user define the typeOf function at all themselves. I'm not actually sure why it is exposed; is it necessary for some use pattern? > >> I don't see what the point of multiple values is, I'm afraid. A single >> instance of Typeable is fine for doing type equality tests. > > Sometimes you want to do witness equality tests rather than type equality > tests. For instance, I might have a "foo" exception and a "bar" exception, > both of which carry an Int. Rather than create new Foo and Bar types, I can > just create a new witness for each. This is precisely what newtype is designed for, IMO. We don't need another mechanism to handle it. Cheers, Ganesh From jason.dusek at gmail.com Tue Sep 2 01:16:55 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Sep 2 01:15:10 2008 Subject: [Haskell-cafe] language proposal: ad-hoc overloading In-Reply-To: <48BB0105.8090802@btinternet.com> References: <2f9b2d30808311121r1c0a4155gd7f55a6d135be8a7@mail.gmail.com> <48BB0105.8090802@btinternet.com> Message-ID: <42784f260809012216w5e9112d7u305a7546f620efd1@mail.gmail.com> Andrew Coppin wrote: > This quickly boils down to an argument along the lines of > "Haskell doesn't support container neutrality very well", > which as I understand it is already a known problem. In all fairness, this complaint boils down to "there is no container typeclass" -- a nuisance but not a failure of the language per se. Likewise, there is no typeclass which gathers together the more useful similarities of ByteString and String. -- _jsn From chak at cse.unsw.edu.au Tue Sep 2 03:10:28 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Sep 2 03:08:49 2008 Subject: [Haskell-cafe] Research language vs. professional language In-Reply-To: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> Message-ID: <2E1A5819-25E2-459A-92BC-834E47E888EE@cse.unsw.edu.au> Ryan Ingram: > On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast > wrote: >> This concept of `day-to-day work' is a curious one. Haskell is not a >> mature language, and probably shouldn't ever be one. > > I see where you are coming from here, but I think that train has > already started and can't be stopped. I find Haskell interesting as a > professional programmer for these four reasons: it's pure, it's > functional, it's lazy, and it's got a great compiler. [..] >> There will always be new discoveries in purely functional >> programming, >> and as the art advances, features like this ad-hoc overloading hack >> (and ACIO) will become obsolete and have to be thrown over-board. > > This is a good point. However, it seems to me that the pure > programming language research is moving towards dependently typed > languages, and that progress in Haskell has been more > application-side; transactional memory and data-parallel, along with > research on various fusion techniques, for example. Let me quote from the Preface of the Haskell report: > It was decided that a committee should be formed to design such a > language, providing faster communication of new ideas, a stable > foundation for real applications development, and a vehicle through > which others would be encouraged to use functional languages. and > It should be suitable for teaching, research, and applications, > including building large systems. From the outset, the Haskell vision included being a "stable foundation for real applications development" (I read this as aiming at industrial use) and "research". This leads to tension, but, for better or worse, I believe that the Haskell community -in its current form- is pretty much committed to meet both goals. You can see it in GHC. It implements the static Haskell 98 and at the same time many experimental, researchy features (which you use at your own risk). More generally, I think that this is one of the killer features of functional languages, they provide a fast path from innovative, even highly theoretical research to practical applications. This may not work forever -maybe all interesting research that can be done in Haskell without radical changes will have been done at some point- but for the moment, I think we are in pretty good shape. Manuel From ahey at iee.org Tue Sep 2 03:15:04 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Sep 2 03:13:19 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> Message-ID: <48BCE7F8.4030208@iee.org> Ganesh Sittampalam wrote: > You see this as a requirement that can be discharged by adding the ACIO > concept; I see it as a requirement that should be communicated in the type. > > Another way of looking at it is that Data.Unique has associated with it > some context in which Unique values are safely comparable. You want that > context to always be the top-level/RTS scope, I would like the defining > that context to be part of the API. But why pick on Data.Unique as special? Because I just happened to have pointed out it uses a "global variable"? If you didn't know this I suspect this issue just wouldn't be an issue at all. Why haven't you raised a ticket complaining about it's API having the "wrong" type sigs? :-) There's shed loads of information and semantic subtleties about pretty much any operation you care to think of in the IO monad that isn't communicated by it's type. All you know for sure is that it's weird, because if it wasn't it wouldn't be in the IO monad. So I think you're applying double standards. >> We have to have something concrete to discuss and this is the simplest. >> Like I said there are a dozen or so other examples in the base package >> last time I counted > > Would you mind listing them? It might help provide some clarity to the > discussion. Here's what you can't find in the libs distributed with ghc. Note this does not include all uses of unsafePerformIO. It only includes uses to make a "global variable". Control.Concurrent 1 Control.OldException 1 Data.HashTable 1 Data.Typeable 1 Data.Unique 1 GHC.Conc 8 GHC.Handle 3 System.Random 1 Language.Haskell.Syntax 1 System.Posix.Signals 2 System.Win32.Types 1 Network.BSD 1 System.Posix.User 1 Total: 23 In the ghc source you can find 16 uses of the GLOBAL_VAR macro (can't imagine what that does :-). I didn't even attempt to figure out how global variables might be the rts source. Anyone care to hazard a guess? You can find a few more in the extra libs.. Graphics.UI.GLUT.Menu 1 Graphics.UI.GLUT.Callbacks.Registration 3 Graphics.Rendering.OpenGL.GLU.ErrorsInternal 1 Total: 5 A few more: wxHaskell 6 c2hs 1 GTK2HS 1 SDL 0 !! However, I happen to know that SDL suffers from the initialisation issue and IIRC it needs at least 1 global to stop user using an unsafe (possibly segfault inducing) calling sequence. Anyway, that's all from me because I'm bored with this thread now. Regards -- Adrian hey From ganesh.sittampalam at credit-suisse.com Tue Sep 2 04:09:10 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Sep 2 04:07:38 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: <20080901220752.GG30189@sliver.repetae.net> References: <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> <20080901220752.GG30189@sliver.repetae.net> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B83E@ELON17P32002A.csfb.cs-group.com> John Meacham wrote: On Fri, Aug 29, 2008 at 04:33:50PM -0700, Dan Weston wrote: >> C++ faced this very issue by saying that with global data, >> uniqueness of initialization is guaranteed but order of >> evaluation is not. Assuming that the global data are >> merely thunk wrappers over some common data source, this >> means that at minimum, there can be no data dependencies >> between plugins where the order of evaluation matters. > Fortunately, we can do a whole lot better with haskell, the > type system guarentees that order of evaluation is irrelevant > :) no need to specify anything about implementations. Can't you write two recursive modules with <- that depend on each other, so that there's no valid initialisation order? Contrived example follows: module Module1 where glob1 :: IORef Int glob1 <- mod2 >>= newIORef mod1 :: IO Int mod1 = readIORef glob1 module Module2 where glob2 :: IORef Int glob2 <- mod1 >>= newIORef mod2 :: IO Int mod2 = readIORef glob2 It might need some strictness annotations to actually cause non-termination at initialisation rather than just make the results of mod1 and mod2 be _|_. I think those initialisers do satisfy ACIO, though I'm not certain - from the point of view of dataflow, you can certainly remove them both together if the rest of the code doesn't use mod1 or mod2, and likewise they commute with any other IO operations. But on the other hand there's no way to actually put them in an order that doesn't cause non-termination. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ahey at iee.org Tue Sep 2 04:30:37 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Sep 2 04:28:52 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B83E@ELON17P32002A.csfb.cs-group.com> References: <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> <20080901220752.GG30189@sliver.repetae.net> <78A3C5650E28124399107F21A1FA419401D3B83E@ELON17P32002A.csfb.cs-group.com> Message-ID: <48BCF9AD.9070408@iee.org> Sittampalam, Ganesh wrote: > Can't you write two recursive modules with <- that depend on > each other, so that there's no valid initialisation order? > > Contrived example follows: > > module Module1 where > > glob1 :: IORef Int > glob1 <- mod2 >>= newIORef > > mod1 :: IO Int > mod1 = readIORef glob1 > > module Module2 where > > glob2 :: IORef Int > glob2 <- mod1 >>= newIORef > > mod2 :: IO Int > mod2 = readIORef glob2 Immediatly breaking my promise to shut up.. This is illegal because you're only allowed to use ACIO in top level <- bindings and readIORef isn't (and clearly could not be) ACIO. Regards -- Adrian Hey From ganesh.sittampalam at credit-suisse.com Tue Sep 2 05:10:31 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Sep 2 05:11:39 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: <48BCF9AD.9070408@iee.org> References: <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> <20080901220752.GG30189@sliver.repetae.net> <78A3C5650E28124399107F21A1FA419401D3B83E@ELON17P32002A.csfb.cs-group.com> <48BCF9AD.9070408@iee.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B841@ELON17P32002A.csfb.cs-group.com> > > Contrived example follows: > > > module Module1 (mod1) where > > import Module2 > > > > glob1 :: IORef Int > > glob1 <- mod2 >>= newIORef > > > mod1 :: IO Int > > mod1 = readIORef glob1 > > > module Module2 (mod2) where > > import Module1 > > glob2 :: IORef Int > > glob2 <- mod1 >>= newIORef > > > mod2 :: IO Int > > mod2 = readIORef glob2 > This is illegal because you're only allowed to use ACIO > in top level <- bindings and readIORef isn't (and clearly > could not be) ACIO. (made a couple of changes to quoted example; added import statements and explicit export lists) Even though I never call writeIORef on glob1 or glob2, and can change the example as above so we don't export them, so it's impossible to ever do so? As an alternative, consider module Module1 (mod1) where import Module2 glob1 :: Int glob1 <- return $! mod2 mod1 :: Int mod1 = glob1 module Module2 (mod2) where import Module1 glob2 :: Int glob2 <- return $! mod1 mod2 :: Int mod2 = glob2 Even more artificial, of course. Arguably both of these cases are not ACIO simply because of the non-termination effects, but it's not obvious to me how you tell just by looking at either one's code together with the declared API of the other. Is anything strict automatically forbidden by ACIO? Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ashley at semantic.org Tue Sep 2 05:33:14 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Sep 2 05:31:28 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> Message-ID: <48BD085A.9090309@semantic.org> Ganesh Sittampalam wrote: > I have a feeling it might be non-trivial; the dynamically loaded bit of > code will need a separate copy of the module in question, since it might > be loaded into something where the module is not already present. Already the dynamic loader must load the module into the same address space and GC, i.e. the same runtime. So it should be able to make sure only one copy gets loaded. What is the status of dynamic loading in Haskell? What does hs-plugins do currently? > Well, the safety of <- being run twice in the Data.Unique case is based > around the two different Data.Unique types not being compatible. Right. The only code that can construct Unique values is internal to Data.Unique. > Let's > suppose some other module uses a <-, but returns things based on that <- > that are some standard type, rather than a type it defines itself. Is > module duplication still safe? In this case, duplicate modules of different versions is as safe as different modules. In other words, this situation: mypackage-1.0 that uses <- mypackage-2.0 that uses <- is just as safe as this situation: mypackage-1.0 that uses <- otherpackage-1.0 that uses <- The multiple versions issue doesn't add any problems. > Well, let me put it this way; since I don't like <-, and I don't > particularly mind Typeable, I wouldn't accept IOWitness as an example of > something that requires <- to implement correctly, because I don't see > any compelling feature that you can only implement with <-. Why don't you like <-? Surely I've addressed all the issues you raise? Multiple package versions does not actually cause any problems. Capabilities would be really nice, but the right approach for that is to create a new execution monad. There is an obligation regarding dynamic loading, but it looks like dynamic loading might need work anyway. Since this is a matter of aesthetics, I imagine it will end with a list of pros and cons. > There's some unsafety somewhere in both Typeable and IOWitnesses, and in > both cases it can be completely hidden from the user - with Typeable, > just don't let the user define the typeOf function at all themselves. It's worse than that. If you derive an instance of Typeable for your type, it means everyone else can peer into your constructor functions and other internals. Sure, it's not unsafe, but it sure is ugly. >> Sometimes you want to do witness equality tests rather than type >> equality tests. For instance, I might have a "foo" exception and a >> "bar" exception, both of which carry an Int. Rather than create new >> Foo and Bar types, I can just create a new witness for each. > > This is precisely what newtype is designed for, IMO. We don't need > another mechanism to handle it. It's not what newtype is designed for. Newtype is designed to create usefully new types. Here, we're only creating different dummy types so that we can have different TypeRep values, which act as witnesses. It's the TypeReps that actually do the work. It would be much cleaner to declare the witnesses directly. -- Ashley Yakeley From haskell at list.mightyreason.com Tue Sep 2 06:13:56 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Sep 2 06:12:19 2008 Subject: [Haskell-cafe] Re: [Haskell] The initial view on typed sprintf and sscanf In-Reply-To: <1220254849.17108.1271490755@webmail.messagingengine.com> References: <20080901024041.07B71AE54@Adric.metnet.fnmoc.navy.mil> <1220254849.17108.1271490755@webmail.messagingengine.com> Message-ID: <48BD11E4.6090200@list.mightyreason.com> Matthew Brecknell wrote: > Unfortunately, I don't seem to be able to make the expected fprintf > function, because printf's format-dependent parameter list makes it > impossible to find a place to pass the handle. Hence the C++-like (<<) > ugliness. How about this: > fprintf :: Handle -> F (IO ()) b -> > fprintf h fmt = write fmt id where > write :: F a b -> (IO () -> a) -> b > write (FLit str) k = k (hPutStr h str) > write FInt k = \i -> k (hPutStr h (show i)) > write FChr k = \c -> k (hPutChar h c) > write (FPP (PrinterParser pr _)) k = \x -> k (hPutStr h (pr x)) > write (a :^ b) k = write a (\sa -> write b (\sb -> k (sa >> sb))) *PrintScan> fprintf stdout fmt5 15 1.3 '!' abc15cde1.3!*PrintScan> The first thing I did last night was change String to type ShowS = String -> String : > intps :: F a b -> (ShowS -> a) -> b > intps (FLit str) k = k (str++) > intps FInt k = \x -> k (shows x) > intps FChr k = \x -> k (x:) > intps (FPP (PrinterParser pr _)) k = \x -> k (pr x ++) > intps (a :^ b) k = intps a (\sa -> intps b (\sb -> k (sa . sb))) > sprintfs :: F ShowS b -> b > sprintfs fmt = intps fmt id Ideally PrinterParser would display using "ShowS" as well: > data PrinterParser a > = PrinterParser (a -> ShowS) (String -> Maybe (a, String)) Or one could use instance witnesses via GADTs to wrap up Show: > data F a b where > FSR :: (Show b,Read b) => F a (b -> a) But I think changing PrinterParser would result in simpler code. Cheers, Chris From duncan.coutts at worc.ox.ac.uk Tue Sep 2 08:27:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 2 08:24:49 2008 Subject: [Haskell-cafe] REMINDER: OpenSPARC project application deadline this Friday Message-ID: <1220358461.24846.341.camel@localhost> http://haskell.org/opensparc/ The deadline for applications for the Haskell OpenSPARC project is rapidly approaching. Applications have to be sent to: opensparc@community.haskell.org by the end of this week, Friday the 5th September. If you want any comments on your application before you submit it then contact me directly. ?Duncan (project coordinator) In other news, the server that Sun Microsystems donated to the community has just gone online at Chalmers: http://blog.well-typed.com/2008/09/the-new-haskellorg-community-sparc-server-is-online/ From gale at sefer.org Tue Sep 2 09:25:56 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Sep 2 09:24:11 2008 Subject: [Haskell-cafe] It's not a monad - what is it? looking for nice syntactic sugar, customizable do notation? In-Reply-To: <20080902041256.GC8956@gmx.de> References: <20080830015846.GB7458@gmx.de> <20080831215054.GA9353@gmx.de> <20080901031024.GC9353@gmx.de> <20080902041256.GC8956@gmx.de> Message-ID: <2608b8a80809020625vbd6fefey4929afc71cb30381@mail.gmail.com> Marc Weber wrote: > (3) Third idea: > xmlWithInnerIO <- execXmlT $ do > xmlns "http://www.w3.org/1999/xhtml" >> lang "en-US" >> xml:lang "en-US" > head $ title $ text "minimal" > body $ do > args <- lift $ getArgs > h1 $ text "minimal" > div $ text $ "args passed to this program: " ++ (show args) > I still think that (3) would be superiour.. > Is there a way to define my own >>= and >> functions such as: There is also the combinator approach of Text.Html, which gives you a syntax similar to (3) but without abusing "do": (rootElt ! [xmlns "http://www.w3.org/1999/xhtml", lang "en-US" >> xml:lang "en-US"]) $ concatXml [head $ title $ text "minimal" ,body $ concatXml [h1 $ text "minimal" ,div $ text $ "args passed to this program: " ++ (show args) ] ] You use concatXml (it's concatHtml in the library) followed by a list, instead of do, for nesting. (Also, it's stringToHtml instead of text in the library.) A few more brackets, but still pretty clean. Also, you'll have pass in your args from somewhere else, in the IO monad - which is probably a better design anyway. Regards, Yitz From gale at sefer.org Tue Sep 2 09:29:11 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Sep 2 09:27:24 2008 Subject: [Haskell-cafe] It's not a monad - what is it? looking for nice syntactic sugar, customizable do notation? In-Reply-To: <2608b8a80809020625vbd6fefey4929afc71cb30381@mail.gmail.com> References: <20080830015846.GB7458@gmx.de> <20080831215054.GA9353@gmx.de> <20080901031024.GC9353@gmx.de> <20080902041256.GC8956@gmx.de> <2608b8a80809020625vbd6fefey4929afc71cb30381@mail.gmail.com> Message-ID: <2608b8a80809020629o147a57e6h84e3219fc07cbf29@mail.gmail.com> Oops, needed to convert one more >> into a comma: (rootElt ! [xmlns "http://www.w3.org/1999/xhtml" ,lang "en-US" ,xml_lang "en-US" ]) $ concatXml etc. -Yitz From ramin.honary at gmail.com Tue Sep 2 09:34:41 2008 From: ramin.honary at gmail.com (Ramin) Date: Tue Sep 2 09:32:39 2008 Subject: [haskell-cafe] Monad and kinds Message-ID: <48BD40F1.6050905@gmail.com> Hello, I'm new here, but in the short time I have known Haskell, I can already say it's my favorite computer language. Except for monads, and no matter how many tutorials I read, I find the only kind of monad I can write is the monad that I copied and pasted from the tutorial, i.e. I still don't get it even though I thought I understood the tutorial, and I'm stuck using monads others have already written. My project is this: I am writing a mini-database of sorts. I thought I would make a query a monad, so I could chain multiple queries together using the "do" notation, and run more complex queries on the list in one shot. The query itself is stateful because it contains information that changes as the database is traversed. The query may also make updates to the records. I got the program to work perfectly using purely functional techniques, but complex queries resulted in that stair-step looking code. So I thought this would be the perfect opportunity to try my hand at monads. The query monad I wrote looks something like this (much simplified): data Query state rec = Query !(state, rec) Where "state" is the type of state, so a query can contain any information relevant to the search and can be updated as the search progresses. Then, "rec" is the type of records in the database, which isn't determined inside the database module, so I can't just declare "rec" to be of any type I choose. But I just cannot write the instance declaration for my Query data type no matter what I try. If I write: instance Monad Query where return (initState, someRecord) = Query (initState, someRecord) {- code for (>>=) -} GHC gives an error, "Expected kind `* -> *', but `Scanlist_ctrl' has kind `* -> * -> *' ". If I try this: instance Monad (Query state) where return (initState, someRecord) = Query (initState, someRecord) {- code for (>>=) -} GHC give an error, "Occurs check: cannot construct the infinite type: a = (s, a) when trying to generalise the type inferred for `return' ". I get the sense I am trying to shove a square peg into a round hole. I was thinking of trying some other things, like implementing the monad in a higher-level module where I knew the type of the records I would be using, but I don't like being told where to implement things. I also thought of trying to re-write my query algorithm to somehow use "Control.Monad.State.Strict" instead of my own query type, but then I wouldn't get to write my own monad! Though the information given in this e-mail is limited, is there anyone who can clearly see there is something about monads that I just don't get and tell me what it is? Anyone who took the time to read this, I am very appreciative. Ramin Honary From jake.mcarthur at gmail.com Tue Sep 2 09:46:56 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Tue Sep 2 09:45:13 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <48BD40F1.6050905@gmail.com> References: <48BD40F1.6050905@gmail.com> Message-ID: <39455A7D-CDE0-4347-8EC1-31087CFED8F0@gmail.com> On Sep 2, 2008, at 8:34 AM, Ramin wrote: > instance Monad Query where > return (initState, someRecord) = Query (initState, someRecord) > {- code for (>>=) -} > GHC gives an error, "Expected kind `* -> *', but `Scanlist_ctrl' has > kind `* -> * -> *' ". I believe you understand the problem with the above code, judging from your attempt to fix it below. > If I try this: > instance Monad (Query state) where > return (initState, someRecord) = Query (initState, someRecord) > {- code for (>>=) -} > GHC give an error, "Occurs check: cannot construct the infinite > type: a = (s, a) when trying to generalise the type inferred for > `return' ". The problem is your type for the return function. The way you have written it, it would be `return :: (state, rec) -> Query state rec`. Perhaps it would be easier to see the problem if we defined `type M = Query MyState`. Then you have `return :: (MyState, rec) -> M rec`. Compare this to the type it must be unified with: `return :: a -> m a`. The two 'a's don't match! The type you are after is actually `return :: rec -> M rec` or `return :: rec -> Query state rec`. I hope this helps lead you in the right direction. I'm not giving you the solution because it sounds like you want to solve this for yourself and learn from it. - Jake McArthur From icfp.publicity at googlemail.com Tue Sep 2 10:06:42 2008 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Tue Sep 2 10:04:57 2008 Subject: [Haskell-cafe] ICFP09 Announcement Message-ID: <53ff55480809020706o574ba463i20bc34ff6d0b8a5d@mail.gmail.com> +--------------------------------------------------------------------+ ANNOUNCEMENT The 14th ACM SIGPLAN International Conference on Functional Programming ICFP 2009 31st August - 2nd September 2009 Edinburgh, United Kingdom ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. ICFP 2009 will be held in Scotland's historic capital city of Edinburgh, during the final week of the Edinburgh International Festival. Further information is available from: http://www.cs.nott.ac.uk/~gmh/icfp09.html Graham Hutton General Chair, ICFP 2009 +--------------------------------------------------------------------+ | Dr Graham Hutton Email : gmh@cs.nott.ac.uk | | Functional Programming Lab | | School of Computer Science Web : www.cs.nott.ac.uk/~gmh | | University of Nottingham | | Jubilee Campus, Wollaton Road Phone : +44 (0)115 951 4220 | | Nottingham NG8 1BB, UK | +--------------------------------------------------------------------+ From daniel.is.fischer at web.de Tue Sep 2 10:35:57 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Sep 2 10:32:09 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <48BD40F1.6050905@gmail.com> References: <48BD40F1.6050905@gmail.com> Message-ID: <200809021635.57723.daniel.is.fischer@web.de> Am Dienstag, 2. September 2008 15:34 schrieb Ramin: > Hello, I'm new here, but in the short time I have known Haskell, I can > already say it's my favorite computer language. > > Except for monads, and no matter how many tutorials I read, I find the > only kind of monad I can write is the monad that I copied and pasted > from the tutorial, i.e. I still don't get it even though I thought I > understood the tutorial, and I'm stuck using monads others have already > written. Considering some pretty brilliant people have a few years advantage over you, don't expect to find a situation where you need a monad not yet written for a while :) > > My project is this: I am writing a mini-database of sorts. I thought I > would make a query a monad, so I could chain multiple queries together > using the "do" notation, and run more complex queries on the list in one > shot. The query itself is stateful because it contains information that > changes as the database is traversed. The query may also make updates to > the records. I got the program to work perfectly using purely functional > techniques, but complex queries resulted in that stair-step looking > code. So I thought this would be the perfect opportunity to try my hand > at monads. > > The query monad I wrote looks something like this (much simplified): > data Query state rec = Query !(state, rec) > > Where "state" is the type of state, so a query can contain any > information relevant to the search and can be updated as the search > progresses. > Then, "rec" is the type of records in the database, which isn't > determined inside the database module, so I can't just declare "rec" to > be of any type I choose. > > But I just cannot write the instance declaration for my Query data type > no matter what I try. If I write: > instance Monad Query where > return (initState, someRecord) = Query (initState, someRecord) > {- code for (>>=) -} > GHC gives an error, "Expected kind `* -> *', but `Scanlist_ctrl' has > kind `* -> * -> *' ". If I try this: > instance Monad (Query state) where > return (initState, someRecord) = Query (initState, someRecord) > {- code for (>>=) -} > GHC give an error, "Occurs check: cannot construct the infinite type: a > = (s, a) when trying to generalise the type inferred for `return' ". The type of return is (Monad m => a -> m a). If m = (Query state), the type of return becomes (rec -> Query state rec) and (return a) must be Query (something of type state, a). Now, if you try return (initState, someRecord) = Query (initState, someRecord), the (initState, someRecord) on the left has type a, and the someRecord on the right has the same type. From the left hand side follows a = (state, rec), hence someRecord has type rec. But from the right hand side, someRecord must have type a = (state, rec), so we find rec = (state, rec). That of course is impossible. > > I get the sense I am trying to shove a square peg into a round hole. I > was thinking of trying some other things, like implementing the monad in > a higher-level module where I knew the type of the records I would be > using, but I don't like being told where to implement things. I also > thought of trying to re-write my query algorithm to somehow use > "Control.Monad.State.Strict" instead of my own query type, but then I > wouldn't get to write my own monad! But this looks very much like an application well suited for the State monad (or a StateT). So why not use that? Or you could write your own specialised version without looking at the existing code, so you could at least familiarise yourself a little more with monads. > > Though the information given in this e-mail is limited, is there anyone > who can clearly see there is something about monads that I just don't > get and tell me what it is? > > Anyone who took the time to read this, I am very appreciative. > Ramin Honary A monad is a type constructor of kind (* -> *), that is, it takes one type as argument and returns some other type. Your Query takes two types as argument and makes one new type from that, so Query has kind (* -> * -> *) and cannot possibly be a monad. What could be a monad is (Query a) which has kind (* -> *). However, the only halfway meaningful return you can define then is return someRecord = Query (undefined, someRecord), which doesn't look particularly useful. And (>>=) then can't make use of the state either, it would have to be one of Query (s,r) >>= f = f r or Query (s,r) >>= f = let Query (_,r1) = f r in Query (s,r1) or something completely meaningless. HTH, Daniel From droundy at darcs.net Tue Sep 2 11:02:40 2008 From: droundy at darcs.net (David Roundy) Date: Tue Sep 2 11:00:55 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B841@ELON17P32002A.csfb.cs-group.com> References: <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> <20080901220752.GG30189@sliver.repetae.net> <78A3C5650E28124399107F21A1FA419401D3B83E@ELON17P32002A.csfb.cs-group.com> <48BCF9AD.9070408@iee.org> <78A3C5650E28124399107F21A1FA419401D3B841@ELON17P32002A.csfb.cs-group.com> Message-ID: <20080902150237.GF32360@darcs.net> On Tue, Sep 02, 2008 at 10:10:31AM +0100, Sittampalam, Ganesh wrote: > > > Contrived example follows: > > > > > module Module1 (mod1) where > > > import Module2 > > > > > > glob1 :: IORef Int > > > glob1 <- mod2 >>= newIORef > > > > > mod1 :: IO Int > > > mod1 = readIORef glob1 > > > > > module Module2 (mod2) where > > > > import Module1 > > > > glob2 :: IORef Int > > > glob2 <- mod1 >>= newIORef > > > > > mod2 :: IO Int > > > mod2 = readIORef glob2 > > > This is illegal because you're only allowed to use ACIO > > in top level <- bindings and readIORef isn't (and clearly > > could not be) ACIO. > > (made a couple of changes to quoted example; added import > statements and explicit export lists) > > Even though I never call writeIORef on glob1 or glob2, and > can change the example as above so we don't export them, so > it's impossible to ever do so? > > As an alternative, consider > > module Module1 (mod1) where > import Module2 > > glob1 :: Int > glob1 <- return $! mod2 > > mod1 :: Int > mod1 = glob1 > > module Module2 (mod2) where > > import Module1 > > glob2 :: Int > glob2 <- return $! mod1 > > mod2 :: Int > mod2 = glob2 > > Even more artificial, of course. > > Arguably both of these cases are not ACIO simply because > of the non-termination effects, but it's not obvious to > me how you tell just by looking at either one's code together > with the declared API of the other. Is anything strict > automatically forbidden by ACIO? Isn't this just a pure infinite loop? Why is it a problem that ACIO allows you the flexibility that's present in any pure code? David From ganesh.sittampalam at credit-suisse.com Tue Sep 2 11:34:28 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Sep 2 11:36:10 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: <20080902150237.GF32360@darcs.net> References: <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> <20080901220752.GG30189@sliver.repetae.net> <78A3C5650E28124399107F21A1FA419401D3B83E@ELON17P32002A.csfb.cs-group.com> <48BCF9AD.9070408@iee.org> <78A3C5650E28124399107F21A1FA419401D3B841@ELON17P32002A.csfb.cs-group.com> <20080902150237.GF32360@darcs.net> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B84E@ELON17P32002A.csfb.cs-group.com> David Roundy wrote: > On Tue, Sep 02, 2008 at 10:10:31AM +0100, Sittampalam, Ganesh wrote: >> Arguably both of these cases are not ACIO simply because of the >> non-termination effects, but it's not obvious to me how you tell just >> by looking at either one's code together with the declared API of the >> other. Is anything strict automatically forbidden by ACIO? > Isn't this just a pure infinite loop? Why is it a problem that ACIO > allows you the flexibility that's present in any pure code? ACIO promises that you can remove anything unused without changing the behaviour. The same problem doesn't arise in pure code because you can't write top-level strict bindings. The GHC extension to have strict bindings (bang patterns) is explicitly disallowed at top-level: http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.ht ml Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ganesh at earth.li Tue Sep 2 16:19:32 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue Sep 2 16:17:44 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BD085A.9090309@semantic.org> References: <534781822.20080826190130@gmail.com> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> Message-ID: On Tue, 2 Sep 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> I have a feeling it might be non-trivial; the dynamically loaded bit of >> code will need a separate copy of the module in question, since it might be >> loaded into something where the module is not already present. > > Already the dynamic loader must load the module into the same address > space and GC, i.e. the same runtime. So it should be able to make sure > only one copy gets loaded. I don't think it's that easy, modules aren't compiled independently of each other, and there are lots of cross-module optimisations and so on. > What is the status of dynamic loading in Haskell? What does hs-plugins > do currently? I don't know for sure, but I think it would load it twice. In any case, what I'm trying to establish below is that it should be a safety property of <- that the entire module (or perhaps mutually recursive groups of them?) can be duplicated safely - with a new name, or as if with a new name - and references to it randomly rewritten to the duplicate, as long as the result still type checks. If that's the case, then it doesn't matter whether hs-plugins loads it twice or not. >> Let's suppose some other module uses a <-, but returns things based on that >> <- that are some standard type, rather than a type it defines itself. Is >> module duplication still safe? > > In this case, duplicate modules of different versions is as safe as > different modules. In other words, this situation: > > mypackage-1.0 that uses <- > mypackage-2.0 that uses <- > > is just as safe as this situation: > > mypackage-1.0 that uses <- > otherpackage-1.0 that uses <- > > The multiple versions issue doesn't add any problems. Agreed - and I further claim that duplicating the entire module itself can't cause any problems. >> Well, let me put it this way; since I don't like <-, and I don't >> particularly mind Typeable, I wouldn't accept IOWitness as an example of >> something that requires <- to implement correctly, because I don't see any >> compelling feature that you can only implement with <-. > > Why don't you like <-? Surely I've addressed all the issues you raise? I'm still not happy that the current specification is good enough, although I think this thread is getting closer to something that might work. Even with a good specification for <-, I would rather see the need for "once-only" state reflected in the type of things that have such a need. > There is an obligation regarding dynamic loading, but it looks like > dynamic loading might need work anyway. I think the obligation should be on <-, and the obligation is the duplication rule I proposed above. > Since this is a matter of aesthetics, I imagine it will end with a list of > pros and cons. Agreed. >> There's some unsafety somewhere in both Typeable and IOWitnesses, and in >> both cases it can be completely hidden from the user - with Typeable, just >> don't let the user define the typeOf function at all themselves. > > It's worse than that. If you derive an instance of Typeable for your > type, it means everyone else can peer into your constructor functions > and other internals. Sure, it's not unsafe, but it sure is ugly. True. I would argue that this is better solved with a better typeclass hierarchy (e.g. one class to supply a witness-style representation that only supports equality, then the typereps on top of that if you want introspection too). >>> Sometimes you want to do witness equality tests rather than type equality >>> tests. For instance, I might have a "foo" exception and a "bar" exception, >>> both of which carry an Int. Rather than create new Foo and Bar types, I >>> can just create a new witness for each. >> >> This is precisely what newtype is designed for, IMO. We don't need another >> mechanism to handle it. > > It's not what newtype is designed for. Newtype is designed to create > usefully new types. Here, we're only creating different dummy types so > that we can have different TypeRep values, which act as witnesses. It's > the TypeReps that actually do the work. newtype is frequently used to create something that you can make a separate set of typeclass instances for. This is no different. You can argue that this use of newtype is wrong, but there's no point in just providing an alternative in one specific case. Ganesh From ganesh at earth.li Tue Sep 2 16:26:58 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue Sep 2 16:25:10 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BCE7F8.4030208@iee.org> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> <48BCE7F8.4030208@iee.org> Message-ID: On Tue, 2 Sep 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> You see this as a requirement that can be discharged by adding the ACIO >> concept; I see it as a requirement that should be communicated in the type. >> >> Another way of looking at it is that Data.Unique has associated with it >> some context in which Unique values are safely comparable. You want that >> context to always be the top-level/RTS scope, I would like the defining >> that context to be part of the API. > > But why pick on Data.Unique as special? Because I just happened to have > pointed out it uses a "global variable"? Only because I thought it was the running example. > If you didn't know this I suspect this issue just wouldn't be an issue > at all. Why haven't you raised a ticket complaining about it's API > having the "wrong" type sigs? :-) Because I don't use it, and even if I did use it I would just live with the API it has. > There's shed loads of information and semantic subtleties about pretty > much any operation you care to think of in the IO monad that isn't > communicated by it's type. All you know for sure is that it's weird, > because if it wasn't it wouldn't be in the IO monad. It does actually claim a specification, namely that no two calls to newUnique return values that compare equal. >>> We have to have something concrete to discuss and this is the simplest. >>> Like I said there are a dozen or so other examples in the base package >>> last time I counted >> >> Would you mind listing them? It might help provide some clarity to the >> discussion. > > Here's what you can't find in the libs distributed with ghc. Note this > does not include all uses of unsafePerformIO. It only includes uses > to make a "global variable". Thanks. It'd probably be a good addition to the wiki page on this topic for these to be catalogued in terms of why they are needed, though I'm (probably) not volunteering to do it :-) Ganesh From dave at zednenem.com Tue Sep 2 16:37:01 2008 From: dave at zednenem.com (David Menendez) Date: Tue Sep 2 16:35:13 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> Message-ID: <49a77b7a0809021337k6e72466cs3ea167dcfeefcc8a@mail.gmail.com> On Tue, Sep 2, 2008 at 4:19 PM, Ganesh Sittampalam wrote: > On Tue, 2 Sep 2008, Ashley Yakeley wrote: >> >> It's worse than that. If you derive an instance of Typeable for your type, >> it means everyone else can peer into your constructor functions and other >> internals. Sure, it's not unsafe, but it sure is ugly. > > True. I would argue that this is better solved with a better typeclass > hierarchy (e.g. one class to supply a witness-style representation that only > supports equality, then the typereps on top of that if you want > introspection too). Isn't that what we have right now? Typeable gives you a TypeRep, which can be compared for equality. All the introspection stuff is in Data. -- Dave Menendez From nadine.and.henry at pobox.com Tue Sep 2 16:25:16 2008 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Tue Sep 2 19:43:14 2008 Subject: [Haskell-cafe] What monad am I in? Message-ID: Dear Group, When I fire up ghci and define: increment x = return (x+1) I can say: Main> increment 1 and ghci dutifully replies 2. Also as expected, the type signature of increment is: (Num a, Monad m) => a -> m a However, if I say: Main> let a = increment 1 I get: :1:8: Ambiguous type variable `m' in the constraint: `Monad m' arising from a use of `increment' at :1:8-18 Probable fix: add a type signature that fixes these type variable(s) Have I, like Monsier Jourdain, been running in the IO monad all my life, and didn't even know it? Thanks, Henry Laxen From jonathanccast at fastmail.fm Tue Sep 2 19:50:17 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Sep 2 19:52:41 2008 Subject: [Haskell-cafe] What monad am I in? In-Reply-To: References: Message-ID: <1220399417.12473.45.camel@jcchost> On Tue, 2008-09-02 at 20:25 +0000, Henry Laxen wrote: > Dear Group, > > When I fire up ghci and define: > > increment x = return (x+1) > > I can say: > Main> increment 1 > > and ghci dutifully replies 2. Also as expected, the type signature of > increment is: (Num a, Monad m) => a -> m a > > However, if I say: > > Main> let a = increment 1 > > I get: > > :1:8: > Ambiguous type variable `m' in the constraint: > `Monad m' arising from a use of `increment' at :1:8-18 > Probable fix: add a type signature that fixes these type variable(s) > > > Have I, like Monsier Jourdain, been running in the IO monad all my > life, and didn't even know it? Yes. This is a peculiarity of GHCi (and ghc -e) --- IO actions at top-level are executed by default, while non-IO values are simply printed out. jcc From marco-oweber at gmx.de Tue Sep 2 20:00:34 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Sep 2 19:58:48 2008 Subject: [Haskell-cafe] What monad am I in? In-Reply-To: References: Message-ID: <20080903000034.GH8956@gmx.de> > Have I, like Monsier Jourdain, been running in the IO monad all my > life, and didn't even know it? Sure, just try readFile "doesnotexist" within ghci :-) That's an IO action. on the other side ghci > (3+7) 10 is no IO action. So I think ghci has two default behaviours differing. Either its a monad, than use IO, else evaluate the result. In both cases show it. The ghc manual sould tell you all about this (too lazy to look it up) But the ghci error message is another one: Try this: :set -XNoMonomorphismRestriction let increment x = return (x+1) let a = increment 1 the line let a = requires to find out about the type of m (Maybe any Monad such as Maybe, list etc) without XNoMonomorphismRestriction. With XNoMonomorphismRestriction you can tell ghc that you don't care yet about this and it should try to resolve m later. That's why ghci shows this: ghci> :t a a :: (Num t, Monad m) => m t The second way to get rid of the ghci error message is telling ghci which monad you want: increment 1 -- this works because it's run within IO print $ increment 1 -- won't, because ghc does'n know about the m type print $ fromJust $ increment 1 -- works again, because you tell ghc that m is Maybe here print $ (increment 1 :: [Int]) -- works as well, using list monad ... Sincerly Marc Weber From ryani.spam at gmail.com Tue Sep 2 20:33:02 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Sep 2 20:31:13 2008 Subject: [Haskell-cafe] What monad am I in? In-Reply-To: References: Message-ID: <2f9b2d30809021733m79f1850ej85887abc0763f0cc@mail.gmail.com> ghci has some crazy defaulting rules for expressions at the top level. In particular, it tries to unify those expressions with a few different types, including IO. On the other hand, the let-expression is typed like regular Haskell and you run into the monomorphism restriction. -- ryan On Tue, Sep 2, 2008 at 1:25 PM, Henry Laxen wrote: > Dear Group, > > When I fire up ghci and define: > > increment x = return (x+1) > > I can say: > Main> increment 1 > > and ghci dutifully replies 2. Also as expected, the type signature of > increment is: (Num a, Monad m) => a -> m a > > However, if I say: > > Main> let a = increment 1 > > I get: > > :1:8: > Ambiguous type variable `m' in the constraint: > `Monad m' arising from a use of `increment' at :1:8-18 > Probable fix: add a type signature that fixes these type variable(s) > > > Have I, like Monsier Jourdain, been running in the IO monad all my > life, and didn't even know it? > > Thanks, > Henry Laxen > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jason.dusek at gmail.com Tue Sep 2 20:34:28 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Sep 2 20:32:39 2008 Subject: [Haskell-cafe] joyent, solaris and ghc Message-ID: <42784f260809021734l64d91de7y9527191e0e417597@mail.gmail.com> Is anyone on the list using GHC on Joyent's Solaris (x86_64) setup? If so, I would love to know whether it was easy/hard and what the process is. -- _jsn From philip.weaver at gmail.com Tue Sep 2 21:49:44 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Tue Sep 2 21:47:55 2008 Subject: [Haskell-cafe] What monad am I in? In-Reply-To: <2f9b2d30809021733m79f1850ej85887abc0763f0cc@mail.gmail.com> References: <2f9b2d30809021733m79f1850ej85887abc0763f0cc@mail.gmail.com> Message-ID: On Tue, Sep 2, 2008 at 5:33 PM, Ryan Ingram wrote: > ghci has some crazy defaulting rules for expressions at the top level. > > In particular, it tries to unify those expressions with a few > different types, including IO. > > On the other hand, the let-expression is typed like regular Haskell > and you run into the monomorphism restriction. Right. Just to make it clear for the original poster, this monomorphism restriction is not about GHCi specifically, just GHC in general. With the -fno-monomorphism-restriction, you will not get this error. > > -- ryan > > On Tue, Sep 2, 2008 at 1:25 PM, Henry Laxen > wrote: > > Dear Group, > > > > When I fire up ghci and define: > > > > increment x = return (x+1) > > > > I can say: > > Main> increment 1 > > > > and ghci dutifully replies 2. Also as expected, the type signature of > > increment is: (Num a, Monad m) => a -> m a > > > > However, if I say: > > > > Main> let a = increment 1 > > > > I get: > > > > :1:8: > > Ambiguous type variable `m' in the constraint: > > `Monad m' arising from a use of `increment' at :1:8-18 > > Probable fix: add a type signature that fixes these type variable(s) > > > > > > Have I, like Monsier Jourdain, been running in the IO monad all my > > life, and didn't even know it? > > > > Thanks, > > Henry Laxen > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080902/188bc6ee/attachment.htm From jgm at berkeley.edu Wed Sep 3 00:10:02 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Wed Sep 3 00:07:39 2008 Subject: [Haskell-cafe] Re: ANN: zip-archive 0.1 In-Reply-To: <1219782971.24846.77.camel@localhost> References: <20080826062256.GB551@berkeley.edu> <1219782971.24846.77.camel@localhost> Message-ID: <20080903041002.GA8584@berkeley.edu> Thanks again for the feedback! I've modified the zip-archive library along the lines you suggested. Version 0.1 is now available on HackageDB. John +++ Duncan Coutts [Aug 26 08 21:36 ]: > > Generally it looks good, that the operations on the archive are mostly > separated from IO of writing out archives or creating entries from disk > files etc. > > Looking at the API there feels to be slightly too much exposed. Eg does > the MSDOSDateTime need to be exposed, or the (de)compressData functions. > > My personal inclination is to leave off the Zip prefix in the names and > use qualified imports. I'd also leave out trivial compositions like > > readZipArchive f = ?toZipArchive <$> B.readFile f > writeZipArchive f = B.writeFile f . fromZipArchive > > but reasonable people disagree. > > For both the pack in my tar lib and your addFilesToZipArchive, there's a > getDirectoryContentsRecursive function asking to get out. This function > seems to come up often. Ideally pack/unpack and > addFilesToZipArchive/extractFilesFromZipArchive would just be mapM_ > extract or create for an individual entry over the contents of the > archive or the result of a recursive traversal. > > So yeah, I feel these operations ought to be simpler compositions of > other things, in your lib and mine, since this bit is often the part > where different use cases need slight variations, eg in how they write > files, or deal with os-specific permissions/security stuff. So if these > are compositions of simpler stuff it should be easier to add in extra > stuff or replace bits. > > Duncan > From pgavin at gmail.com Wed Sep 3 00:09:28 2008 From: pgavin at gmail.com (Peter Gavin) Date: Wed Sep 3 00:07:46 2008 Subject: [Haskell-cafe] Re: Arrow without `>>>' In-Reply-To: References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> Message-ID: <48BE0DF8.9010108@gmail.com> Valery V. Vorotyntsev wrote: > On 1/23/08, David Menendez wrote: >> On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: >>> I've built GHC from darcs, and... >>> Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' >>> method? >> It's derived from the Category superclass. > > Yes, it is. > > The right question: how to build `arrows' in such circumstances? > > Here go 2 changes I made to `CoState.hs' accompanied by the > error messages. :) Unfortunately, I'm not arrow-capable enough to > make _proper_ changes to the code and satisfy GHC... Any help? > Well, without looking at your code, generally all you have to do is 1) move the definition of (>>>) to Category and rename it to (.) after flipping the arguments. 2) define the id method of Category which is just (arr id) or returnA. So essentially instance Arrow (Foo a) where a >>> b = compose a b pure f = ... first a = ... becomes instance Arrow (Foo a) where pure f = ... first a = ... instance Category (Foo a) where id = arr id a . b = compose b a That's it. It's too bad there's no way to do this automatically in the libraries, but it could be noted in the API docs. Pete > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Change #1: > > $ darcs w Control/Arrow/Transformer/CoState.hs > What's new in "Control/Arrow/Transformer/CoState.hs": > > { > hunk ./Control/Arrow/Transformer/CoState.hs 23 > +import Control.Category ((>>>)) > } > > -------------------------------------------------- > Error #1: > > Control/Arrow/Transformer/CoState.hs:29:7: > `>>>' is not a (visible) method of class `Arrow' > Failed, modules loaded: Control.Arrow.Operations. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Change #2: > > $ darcs diff -u Control/Arrow/Transformer/CoState.hs > --- old-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 > 14:54:29.852296559 +0200 > +++ new-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 > 14:54:29.852296559 +0200 > @@ -20,12 +20,13 @@ > > import Control.Arrow > import Control.Arrow.Operations > +import Control.Category ((>>>)) > > newtype CoStateArrow s a b c = CST (a (s -> b) (s -> c)) > > instance Arrow a => Arrow (CoStateArrow s a) where > arr f = CST (arr (f .)) > - CST f >>> CST g = CST (f >>> g) > +-- CST f >>> CST g = CST (f >>> g) > first (CST f) = CST (arr unzipMap >>> first f >>> arr zipMap) > > zipMap :: (s -> a, s -> b) -> (s -> (a,b)) > > -------------------------------------------------- > Error#2: > > Control/Arrow/Transformer/CoState.hs:27:0: > Could not deduce (Control.Category.Category (CoStateArrow s a)) > from the context (Arrow a) > arising from the superclasses of an instance declaration > at Control/Arrow/Transformer/CoState.hs:27:0 > Possible fix: > add (Control.Category.Category > (CoStateArrow s a)) to the context of > the instance declaration > or add an instance declaration for > (Control.Category.Category (CoStateArrow s a)) > In the instance declaration for `Arrow (CoStateArrow s a)' > Failed, modules loaded: Control.Arrow.Operations. > > Thank you. > From dons at galois.com Wed Sep 3 00:29:33 2008 From: dons at galois.com (Don Stewart) Date: Wed Sep 3 00:27:40 2008 Subject: [Haskell-cafe] Re: ANN: zip-archive 0.1 In-Reply-To: <20080903041002.GA8584@berkeley.edu> References: <20080826062256.GB551@berkeley.edu> <1219782971.24846.77.camel@localhost> <20080903041002.GA8584@berkeley.edu> Message-ID: <20080903042933.GA843@scytale.galois.com> jgm: > Thanks again for the feedback! I've modified the zip-archive library > along the lines you suggested. Version 0.1 is now available on > HackageDB. And, of course, natively packaged for Arch, http://aur.archlinux.org/packages.php?ID=19555 Go, packagers, go! :) -- Don From ashley at semantic.org Wed Sep 3 02:53:34 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Sep 3 02:51:46 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> Message-ID: <48BE346E.2000503@semantic.org> Ganesh Sittampalam wrote: > In any case, what I'm trying to establish below is that it should be a > safety property of <- that the entire module (or perhaps mutually > recursive groups of them?) can be duplicated safely - with a new name, > or as if with a new name - and references to it randomly rewritten to > the duplicate, as long as the result still type checks. That's not acceptable. This would cause Unique to break, as its MVar would be created twice. It would also mean that individual Unique and IOWitness values created by <- would have different values depending on which bit of code was referencing them. It would render the extension useless as far as I can see. It also introduces odd execution scopes again. In order for <- to work, it must be understood that a given <- initialiser in a given module in a given version of a given package will execute at most once per RTS. But your restriction breaks that. It's worth mentioning that the current Data.Unique is part of the standard base library, while hs-plugins is rather experimental. Currently Data.Unique uses the "NOINLINE unsafePerformIO" hack to create its MVar. If hs-plugins duplicates that MVar, that's a bug in hs-plugins. It's up to a dynamic loader to get initialisation code correct. -- Ashley Yakeley From ganesh.sittampalam at credit-suisse.com Wed Sep 3 03:05:58 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 03:04:39 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BE346E.2000503@semantic.org> References: <534781822.20080826190130@gmail.com> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: >Ganesh Sittampalam wrote: >> In any case, what I'm trying to establish below is that it should be a >> safety property of <- that the entire module (or perhaps mutually >> recursive groups of them?) can be duplicated safely - with a new name, >> or as if with a new name - and references to it randomly rewritten to >> the duplicate, as long as the result still type checks. > That's not acceptable. This would cause Unique to break, > as its MVar would be created twice. It would also mean > that individual Unique and IOWitness values created by > <- would have different values depending on which bit > of code was referencing them. It would render the extension > useless as far as I can see. The result wouldn't typecheck if two Unique values that now pointed to the two different modules were compared. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ashley at semantic.org Wed Sep 3 03:12:18 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Sep 3 03:10:29 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <49a77b7a0809021337k6e72466cs3ea167dcfeefcc8a@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <49a77b7a0809021337k6e72466cs3ea167dcfeefcc8a@mail.gmail.com> Message-ID: <48BE38D2.8010403@semantic.org> David Menendez wrote: > Isn't that what we have right now? Typeable gives you a TypeRep, which > can be compared for equality. All the introspection stuff is in Data. Oh, yes, you're right. -- Ashley Yakeley From dave at zednenem.com Wed Sep 3 03:18:08 2008 From: dave at zednenem.com (David Menendez) Date: Wed Sep 3 03:16:19 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BE346E.2000503@semantic.org> References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> Message-ID: <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> On Wed, Sep 3, 2008 at 2:53 AM, Ashley Yakeley wrote: > > It's worth mentioning that the current Data.Unique is part of the standard > base library, while hs-plugins is rather experimental. Currently Data.Unique > uses the "NOINLINE unsafePerformIO" hack to create its MVar. If hs-plugins > duplicates that MVar, that's a bug in hs-plugins. It's up to a dynamic > loader to get initialisation code correct. Data.Unique describes itself as "experimental" and "non-portable". The Haskell 98 report includes NOINLINE, but also states that environments are not required to respect it. So hs-plugins wouldn't necessarily be at fault if it didn't support Data.Unique. -- Dave Menendez From ganesh.sittampalam at credit-suisse.com Wed Sep 3 03:25:22 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 03:23:43 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> Dave Menendez wrote: > The Haskell 98 report includes NOINLINE, but > also states that environments are not required > to respect it. So hs-plugins wouldn't necessarily > be at fault if it didn't support Data.Unique. Also, the definition of NOINLINE in the report doesn't preclude copying both the MVar *and* its use sites, which is what I am proposing should be considered generally safe. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ashley at semantic.org Wed Sep 3 03:41:09 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Sep 3 03:39:20 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> Message-ID: <48BE3F95.9020503@semantic.org> Sittampalam, Ganesh wrote: >> That's not acceptable. This would cause Unique to break, >> as its MVar would be created twice. It would also mean >> that individual Unique and IOWitness values created by >> <- would have different values depending on which bit >> of code was referencing them. It would render the extension >> useless as far as I can see. > > The result wouldn't typecheck if two Unique values that now pointed to > the two different modules were compared. I don't understand. If the dynamic loader were to load the same package name and version, and it duplicated the MVar, then Unique values would have the same type and could be compared. -- Ashley Yakeley From ashley at semantic.org Wed Sep 3 03:47:31 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Sep 3 03:45:42 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> Message-ID: <48BE4113.6050204@semantic.org> David Menendez wrote: > On Wed, Sep 3, 2008 at 2:53 AM, Ashley Yakeley wrote: >> It's worth mentioning that the current Data.Unique is part of the standard >> base library, while hs-plugins is rather experimental. Currently Data.Unique >> uses the "NOINLINE unsafePerformIO" hack to create its MVar. If hs-plugins >> duplicates that MVar, that's a bug in hs-plugins. It's up to a dynamic >> loader to get initialisation code correct. > > Data.Unique describes itself as "experimental" and "non-portable". The > Haskell 98 report includes NOINLINE, but also states that environments > are not required to respect it. So hs-plugins wouldn't necessarily be > at fault if it didn't support Data.Unique. I found this: "To solve this the hs-plugins dynamic loader maintains state storing a list of what modules and packages have been loaded already. If load is called on a module that is already loaded, or dependencies are attempted to load, that have already been loaded, the dynamic loader ignores these extra dependencies. This makes it quite easy to write an application that will allows an arbitrary number of plugins to be loaded." -- Ashley Yakeley From ganesh.sittampalam at credit-suisse.com Wed Sep 3 03:45:31 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 03:54:59 2008 Subject: [Haskell-cafe] RE: [Haskell] Top Level <- In-Reply-To: <48BE3F95.9020503@semantic.org> References: <534781822.20080826190130@gmail.com> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > I don't understand. If the dynamic loader were to load the same package > name and version, and it duplicated the MVar, then Unique values would > have the same type and could be compared. I am suggesting that this duplication process, whether conducted by the dynamic loader or something else, should behave as if they did not have the same package name or version. This is certainly a valid transformation for Data.Unique, I am simply saying that it should be a valid transformation on any module. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ganesh.sittampalam at credit-suisse.com Wed Sep 3 04:13:35 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 04:14:23 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48BE4113.6050204@semantic.org> References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <48BE4113.6050204@semantic.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B854@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > "To solve this the hs-plugins dynamic loader maintains > state storing a list of what modules and packages have > been loaded already. If load is called on a module that > is already loaded, or dependencies are attempted to load, > that have already been loaded, the dynamic loader ignores > these extra dependencies. This makes it quite easy to > write an application that will allows an arbitrary number > of plugins to be loaded." > My recollection from using it a while ago is that if a module is used in the main program it will still be loaded once more in the plugin loader. This is because the plugin loader is basically an embedded copy of ghci without much knowledge of the host program's RTS. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ashley at semantic.org Wed Sep 3 04:28:03 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Sep 3 04:26:14 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> Message-ID: <48BE4A93.4080900@semantic.org> Sittampalam, Ganesh wrote: > I am suggesting that this duplication process, whether conducted by the > dynamic loader or something else, should behave as if they did not have > the same package name or version. > > This is certainly a valid transformation for Data.Unique, I am simply > saying that it should be a valid transformation on any module. So if I dynamically load module M that uses base, I will in fact get a completely new and incompatible version of Maybe, IO, [], Bool, Char etc. in all the type-signatures of M? -- Ashley Yakeley From gale at sefer.org Wed Sep 3 04:31:35 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Sep 3 04:29:46 2008 Subject: [Haskell-cafe] What monad am I in? In-Reply-To: <20080903000034.GH8956@gmx.de> References: <20080903000034.GH8956@gmx.de> Message-ID: <2608b8a80809030131i240b5767mdf9b05d983ff8059@mail.gmail.com> Henry Laxen wrote: >> Have I, like Monsier Jourdain, been running in the IO monad all my >> life, and didn't even know it? Marc Weber wrote: > Sure... > But the ghci error message is another one: > Try this: > :set -XNoMonomorphismRestriction And I highly recommend putting that line in your .ghci file. There is controversy about whether MR is helpful in general. It is on by default, so I just leave it that way, and it seems to be fine. But at the GHCi prompt, MR is definitely a nuisance. Get rid of it there by using :set in your .ghci file. Regards, Yitz From ganesh.sittampalam at credit-suisse.com Wed Sep 3 04:45:31 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 04:47:51 2008 Subject: [Haskell-cafe] RE: [Haskell] Top Level <- In-Reply-To: <48BE4A93.4080900@semantic.org> References: <534781822.20080826190130@gmail.com> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > Sittampalam, Ganesh wrote: > > I am suggesting that this duplication process, whether conducted by > > the dynamic loader or something else, should behave as if they did not > > have the same package name or version. > > > This is certainly a valid transformation for Data.Unique, I am simply > > saying that it should be a valid transformation on any module. > So if I dynamically load module M that uses base, I will in fact > get a completely new and incompatible version of Maybe, IO, [], > Bool, Char etc. in all the type-signatures of M? I think it treats them as compatible, using the fact that Data.Typeable returns the same type reps (which was why I initially mentioned Data.Typeable in this thread). This is fine for "normal" modules. There's a bit of description in the "Dynamic Typing" section of http://www.cse.unsw.edu.au/~dons/hs-plugins/hs-plugins-Z-H-5.html#node_s ec_9 It's clearly the wrong thing to do for Data.Unique and any anything else that might use <-; but if there are no such types in the interface of the plugin, then it won't matter. I can't see how to make it safe to pass Data.Unique etc across a plugin interface without severely restricting the possible implementation strategies for a plugin library and its host. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From gale at sefer.org Wed Sep 3 05:19:36 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Sep 3 05:17:47 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <200809021635.57723.daniel.is.fischer@web.de> References: <48BD40F1.6050905@gmail.com> <200809021635.57723.daniel.is.fischer@web.de> Message-ID: <2608b8a80809030219g28f446e0j79b5da8d50cce438@mail.gmail.com> Ramin wrote: > ...no matter how many tutorials I read, I find the only > kind of monad I can write is the monad that I copied > and pasted from the tutorial... > I am writing a mini-database... > The query itself is stateful... > The query may also make updates to the records. > I also > thought of trying to re-write my query algorithm to somehow use > "Control.Monad.State.Strict" instead of my own query type, but then I > wouldn't get to write my own monad! Just Control.Monad.State should work fine. Daniel Fischer wrote: > But this looks very much like an application well suited for the State monad > (or a StateT). So why not use that? I agree with Daniel. If you want to learn about the deeper theory of the inner workings of monads, that's great - go ahead, and have fun! But to solve your problem in practice, you don't need that level of knowledge. All you need to know about is get, put, modify, and liftIO. The StateT monad is really simple to use. In general, practical software is higher quality when it uses existing standard libraries. There is no more reason to re-invent the StateT monad than there is to re-invent anything else in the libraries. Among the multitude of monad tutorials out there, I wonder how many of them draw a clear line between what you need to understand to design monads, and what you need to understand just to use them. There's a huge difference in complexity. Like most things, it is best to use monads for a while and get comfortable with them before trying to learn how to design them and build them. Regards, Yitz From ashley at semantic.org Wed Sep 3 05:20:07 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Sep 3 05:18:19 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> Message-ID: <48BE56C7.10907@semantic.org> Sittampalam, Ganesh wrote: > I think it treats them as compatible, using the fact that > Data.Typeable returns the same type reps (which was why I initially > mentioned Data.Typeable in this thread). This is fine for "normal" > modules. There's a bit of description in the "Dynamic Typing" section of > http://www.cse.unsw.edu.au/~dons/hs-plugins/hs-plugins-Z-H-5.html#node_s > ec_9 > > It's clearly the wrong thing to do for Data.Unique and any anything > else that might use <-; but if there are no such types in the interface > of the plugin, then it won't matter. I can't see how to make it > safe to pass Data.Unique etc across a plugin interface without > severely restricting the possible implementation strategies for > a plugin library and its host. I think it's bad design for a dynamic loader to load a module more than once anyway. It's a waste of memory, for a start. We already know that hs-plugins won't for modules it already loaded itself (apparently it crashes the RTS), and I suspect it doesn't at all. -- Ashley Yakeley From ganesh.sittampalam at credit-suisse.com Wed Sep 3 05:46:03 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 05:44:55 2008 Subject: [Haskell-cafe] RE: [Haskell] Top Level <- In-Reply-To: <48BE56C7.10907@semantic.org> References: <534781822.20080826190130@gmail.com> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > I think it's bad design for a dynamic loader to load a module more > than once anyway. In compiled code module boundaries don't necessarily exist. So how do you relink the loaded code so that it points to the unique copy of the module? > It's a waste of memory, for a start. We already > know that hs-plugins won't for modules it already loaded itself > (apparently it crashes the RTS), and I suspect it doesn't at all. It crashes the RTS of the plugins loader, which is based on ghci, which is built around loading modules independently. I believe there's a separate RTS running at the top level of the program which has no knowledge of the plugin loader. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From noteed at gmail.com Wed Sep 3 06:09:38 2008 From: noteed at gmail.com (minh thu) Date: Wed Sep 3 06:07:48 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? Message-ID: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> Hi, I'd like to write a data structure to be used inside the IO monad. The structure has some handles of type Maybe (IORef a), i.e. IORef are pointers and the Maybe is like null pointers. So I came up with the following functions : readHandle :: Maybe (IORef a) -> IO (Maybe a) readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) readHandle Nothing = do return Nothing readHandle (Just r) = do v <- readIORef r return $ Just v readField f h = do m <- readHandle h return $ fmap f m Is it something usual ? Are there any related functions in the standard libraries ? Thanks, Thu From gale at sefer.org Wed Sep 3 07:12:39 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Sep 3 07:10:50 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> Message-ID: <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> Ashley Yakeley wrote: > Currently Data.Unique uses the "NOINLINE unsafePerformIO" > hack to create its MVar. If hs-plugins duplicates that MVar, > that's a bug in hs-plugins. Sittampalam, Ganesh wrote: > Also, the definition of NOINLINE in the report doesn't > preclude copying both the MVar *and* its use sites, Right. It would not be a bug in hs-plugins. That is the most urgent problem right now. It is nice to discuss various proposed new language features. That is the way to solve the problem in the long term. But right now - there is no way to do this in Haskell at all. The NOINLINE unsafePerformIO hack doesn't really work. This is currently a major hole in Haskell in my opinion. For the short term - can we *please* get an ONLYONCE pragma that has the correct semantics? Thanks, Yitz From ganesh.sittampalam at credit-suisse.com Wed Sep 3 07:16:52 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 07:16:45 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> Yitzhak Gale wrote: > Right. It would not be a bug in hs-plugins. That is > the most urgent problem right now. [...] > For the short term - can we *please* get an ONLYONCE > pragma that has the correct semantics? So the purpose of this pragma would solely be so that you can declare hs-plugins buggy for not respecting it? Or do you have some way to "fix" hs-plugins so that it does do so? (Assuming that my belief about how hs-plugins works is correct, of course) Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From bulat.ziganshin at gmail.com Wed Sep 3 07:58:45 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Sep 3 08:04:19 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> Message-ID: <141527000.20080903155845@gmail.com> Hello minh, Wednesday, September 3, 2008, 2:09:38 PM, you wrote: > I'd like to write a data structure to be used inside the IO monad. > The structure has some handles of type Maybe (IORef a), > i.e. IORef are pointers and the Maybe is like null pointers. i've not used this but overall it seems like a correct way to emulate NULL. the whole question is that you probably still think C if you need NULL pointers at all :) > readHandle :: Maybe (IORef a) -> IO (Maybe a) > Are there any related functions in the standard libraries ? readHandle = maybe (return Nothing) (fmap Just . readIORef) or you can add your own primitive: liftNULL op = maybe (return Nothing) (fmap Just . op) readHandle = liftNULL readIORef -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mjm2002 at gmail.com Wed Sep 3 08:06:48 2008 From: mjm2002 at gmail.com (Matt Morrow) Date: Wed Sep 3 08:04:58 2008 Subject: [Haskell-cafe] Types and Trees Message-ID: <1638d5210809030506g54935c3ia8959de2a85a0c18@mail.gmail.com> I really learned a lot from writing the below code, and thought I'd share it with the group. I'm slightly at a loss for words, having just spent the last two hours on this when I most certainly should have been doing other work, but these are two hours I won't regret. I'm very interested in hearing others' thoughts on "this", where "this" is "whatever comes to mind". Regards, Matt {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} module TT where import Data.Tree import Data.Typeable (Typeable(..),TypeRep(..),TyCon(..) ,typeRepTyCon,typeRepArgs,tyConString) import Language.Haskell.TH(Type(..),mkName) -------------------------------------------------------- class ToType a where toType :: a -> Type class ToTree a b where toTree :: a -> Tree b {- Typeable a | typeOf | (0) | v toType TypeRep - - - - - - - - > Type | (4) | toTree | (1) (2) | toTree | | v (3) v Tree TyCon ---------------> Tree Type toTree -} -- (0) typeableToTypeRep :: (Typeable a) => a -> TypeRep typeableToTypeRep = typeOf -- (1) instance ToTree TypeRep TyCon where toTree ty = Node (typeRepTyCon ty) (fmap toTree . typeRepArgs $ ty) -- (2) instance ToTree Type Type where toTree (AppT t1 t2) = let (Node x xs) = toTree t1 in Node x (xs ++ [toTree t2]) toTree t = Node t [] -- (3.a) instance ToType TyCon where toType tyC = let tyS = tyConString tyC in case tyS of "->" -> ArrowT "[]" -> ListT "()" -> TupleT 0 ('(':',':rest) -> let n = length (takeWhile (==',') rest) in TupleT (n+2) _ -> ConT . mkName $ tyS -- (3.b) instance ToType (Tree TyCon) where toType (Node x xs) = foldl AppT (toType x) (fmap toType xs) -- (3) instance ToTree (Tree TyCon) Type where toTree = toTree . toType -- (4) instance ToType TypeRep where toType = toType . (toTree::TypeRep->Tree TyCon) -- (0) typeOf -- (1) toTree -- (2) toTree -- (3) toTree -- (4) toType -- (0) -> (1) tyConTree :: (Typeable a) => a -> Tree TyCon tyConTree = toTree . typeOf -- (0) -> (1) -> (3) typeTree_a :: (Typeable a) => a -> Tree Type typeTree_a = (toTree::Tree TyCon->Tree Type) . (toTree::TypeRep->Tree TyCon) . typeOf -- (0) -> (4) -> (2) typeTree_b :: (Typeable a) => a -> Tree Type typeTree_b = (toTree::Type->Tree Type) . (toType::TypeRep->Type) . typeOf diagram_commutes :: (Typeable a) => a -> Bool diagram_commutes a = typeTree_a a == typeTree_b a -- ghci> diagram_commutes x0 -- True x0 :: (Num a) => ((a,(a,((a,a),a))),(a,(a,a))) x0 = ((0,(0,((0,0),0))),(0,(0,0))) -------------------------------------------------------- printTree :: (Show a) => Tree a -> IO () printTree = putStr . drawTree . fmap show printForest :: (Show a) => Forest a -> IO () printForest = putStr . drawForest . (fmap . fmap) show -------------------------------------------------------- {- ghci> printTree $ tyConTree x0 (,) | +- (,) | | | +- Integer | | | `- (,) | | | +- Integer | | | `- (,) | | | +- (,) | | | | | +- Integer | | | | | `- Integer | | | `- Integer | `- (,) | +- Integer | `- (,) | +- Integer | `- Integer ghci> printTree $ typeTree_a x0 TupleT 2 | +- TupleT 2 | | | +- ConT Integer | | | `- TupleT 2 | | | +- ConT Integer | | | `- TupleT 2 | | | +- TupleT 2 | | | | | +- ConT Integer | | | | | `- ConT Integer | | | `- ConT Integer | `- TupleT 2 | +- ConT Integer | `- TupleT 2 | +- ConT Integer | `- ConT Integer ghci> printTree $ typeTree_b x0 TupleT 2 | +- TupleT 2 | | | +- ConT Integer | | | `- TupleT 2 | | | +- ConT Integer | | | `- TupleT 2 | | | +- TupleT 2 | | | | | +- ConT Integer | | | | | `- ConT Integer | | | `- ConT Integer | `- TupleT 2 | +- ConT Integer | `- TupleT 2 | +- ConT Integer | `- ConT Integer -} -------------------------------------------------------- From ryani.spam at gmail.com Wed Sep 3 08:07:06 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Sep 3 08:05:17 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> Message-ID: <2f9b2d30809030507m11688db4t8a232c6a949b6df0@mail.gmail.com> Looks like MaybeT? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MaybeT-0.1.1 > readHandle x = runMaybeT $ do > ref <- MaybeT (return x) > liftIO (readIORef ref) > readField f h = runMaybeT $ do > a <- MaybeT (readHandle h) > return (f a) (or, the short version) > readHandle x = runMaybeT (liftIO . readIORef =<< MaybeT (return x)) > readField f = runMaybeT . liftM f . MaybeT . readHandle As a bonus, readHandle and readField work in any MonadIO due to the use of liftIO (as opposed to just lift). -- ryan On Wed, Sep 3, 2008 at 3:09 AM, minh thu wrote: > Hi, > > I'd like to write a data structure to be used inside the IO monad. > The structure has some handles of type Maybe (IORef a), > i.e. IORef are pointers and the Maybe is like null pointers. > > So I came up with the following functions : > > readHandle :: Maybe (IORef a) -> IO (Maybe a) > readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) > > readHandle Nothing = do > return Nothing > readHandle (Just r) = do > v <- readIORef r > return $ Just v > > readField f h = do > m <- readHandle h > return $ fmap f m > > Is it something usual ? > Are there any related functions in the standard libraries ? > > Thanks, > Thu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From gale at sefer.org Wed Sep 3 08:19:07 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Sep 3 08:17:17 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> Message-ID: <2608b8a80809030519x9ef3678nadcd5ec535bf9ba5@mail.gmail.com> I wrote: >> For the short term - can we *please* get an ONLYONCE >> pragma that has the correct semantics? Sittampalam, Ganesh wrote: > So the purpose of this pragma would solely be so that > you can declare hs-plugins buggy for not respecting it? No, the hs-plugins problem - whether hypothetical or real - is only a symptom. There is no way to define global variables in Haskell right now. The NOINLINE hack is used, and most often works. But really it's broken and there are no guarantees, because NOINLINE does not have the right semantics. This is demonstrated by your hs-plugins example, but it's a general problem. Until a permanent solution is implemented and deployed in the compilers (if ever), can we please have a pragma that allows the current hack to really work? Thanks, Yitz From ganesh.sittampalam at credit-suisse.com Wed Sep 3 08:22:34 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 08:24:29 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <2608b8a80809030519x9ef3678nadcd5ec535bf9ba5@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030519x9ef3678nadcd5ec535bf9ba5@mail.gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B85F@ELON17P32002A.csfb.cs-group.com> (apologies for misspelling your name when quoting you last time) Yitzchak Gale wrote: >>> For the short term - can we *please* get an ONLYONCE pragma that has >>> the correct semantics? > Until a permanent solution is implemented and deployed in the > compilers (if ever), can we please have a pragma that allows > the current hack to really work? How do you propose that this pragma would be implemented? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From noteed at gmail.com Wed Sep 3 08:37:58 2008 From: noteed at gmail.com (minh thu) Date: Wed Sep 3 08:36:08 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <141527000.20080903155845@gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <141527000.20080903155845@gmail.com> Message-ID: <40a414c20809030537p183caa47i659a1c6b6ae968cd@mail.gmail.com> 2008/9/3 Bulat Ziganshin : > Hello minh, > > Wednesday, September 3, 2008, 2:09:38 PM, you wrote: > >> I'd like to write a data structure to be used inside the IO monad. >> The structure has some handles of type Maybe (IORef a), >> i.e. IORef are pointers and the Maybe is like null pointers. > > i've not used this but overall it seems like a correct way to emulate > NULL. the whole question is that you probably still think C if you > need NULL pointers at all :) Maybe, I'm adapting some C++ code... Do you suggest I use data Thing = Thing | None and IORef Thing instead of data Thing = Thing and Maybe (IORef Thing) ? I'm writing a data structure that can hold Things (and that can be mutated) or nothing (there is a hole in the wrapping data). Thanks, Thu From gale at sefer.org Wed Sep 3 08:42:18 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Sep 3 08:40:28 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B85F@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030519x9ef3678nadcd5ec535bf9ba5@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85F@ELON17P32002A.csfb.cs-group.com> Message-ID: <2608b8a80809030542k5caf3d4bo6d2a698e09fb5810@mail.gmail.com> >>>> For the short term - can we *please* get an ONLYONCE pragma that has >>>> the correct semantics? Sittampalam, Ganesh wrote: > How do you propose that this pragma would be implemented? As far as I know now, in GHC it could currently just be an alias for NOINLINE, but the GHC gurus could say for sure. Except it should require a monomorphic constant - otherwise the guarantee doesn't make sense. And it would have clear comments and documentation that state that it guarantees that the value will be computed at most once. That way, bugs could be filed against it if that ever turns out not to be true. Other applications and libraries that support the pragma - such as other compilers, and hs-plugins - would be required to respect the guarantee, and bugs could be filed against them if they don't. Thanks, Yitz From ganesh.sittampalam at credit-suisse.com Wed Sep 3 09:00:16 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Sep 3 08:59:00 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <2608b8a80809030542k5caf3d4bo6d2a698e09fb5810@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030519x9ef3678nadcd5ec535bf9ba5@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85F@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030542k5caf3d4bo6d2a698e09fb5810@mail.gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B861@ELON17P32002A.csfb.cs-group.com> Yitzchak Gale wrote > Other applications and libraries that support the pragma - such as other > compilers, and hs-plugins - would be required to respect the guarantee, and > bugs could be filed against them if they don't. If hs-plugins were loading object code, how would it even know of the existence of the pragma? Given such knowledge, how would it implement it? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From gale at sefer.org Wed Sep 3 09:30:21 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Sep 3 09:28:32 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B861@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BE346E.2000503@semantic.org> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030519x9ef3678nadcd5ec535bf9ba5@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85F@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030542k5caf3d4bo6d2a698e09fb5810@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B861@ELON17P32002A.csfb.cs-group.com> Message-ID: <2608b8a80809030630m7ef845aanf6467f666fc0aa32@mail.gmail.com> I wrote >> Other applications and libraries that support the pragma - >> such as other compilers, and hs-plugins - would be >> required to respect the guarantee, and bugs could be >> filed against them if they don't. Sittampalam, Ganesh wrote: > If hs-plugins were loading object code, how would it even > know of the existence of the pragma? Given such > knowledge, how would it implement it? Good point. A compiler pragma is only that, in the end. This is just a hack, we can only do the best we can with it. Regards, Yitz From noteed at gmail.com Wed Sep 3 09:40:19 2008 From: noteed at gmail.com (minh thu) Date: Wed Sep 3 09:38:30 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <141527000.20080903155845@gmail.com> <40a414c20809030537p183caa47i659a1c6b6ae968cd@mail.gmail.com> Message-ID: <40a414c20809030640p2f10ca08xf930794cd2861a5d@mail.gmail.com> 2008/9/3 Lennart Augustsson : > I think you should think about why your application needs IORef at all. Do > you really need mutation? And why isn't STRef good enough. Using IORef is > really the last resort. This is for an interactive application (3D mesh editing, the data structure is the half edge structure). So the user can add points, edges, faces, delete them, ... Thu From Christian.Maeder at dfki.de Wed Sep 3 12:35:56 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 3 12:34:04 2008 Subject: [Haskell-cafe] Re: joyent, solaris and ghc In-Reply-To: <42784f260809021734l64d91de7y9527191e0e417597@mail.gmail.com> References: <42784f260809021734l64d91de7y9527191e0e417597@mail.gmail.com> Message-ID: <48BEBCEC.8000605@dfki.de> Jason Dusek wrote: > Is anyone on the list using GHC on Joyent's Solaris (x86_64) > setup? If so, I would love to know whether it was easy/hard > and what the process is. Sorry, I don't know a thing about "Joyent". On x86-Solaris there seems to exist only a 32bit distribution that should run on 64bit archs, too. http://www.haskell.org/ghc/download_ghc_683.html#x86solaris Could you try that out? Cheers Christian From dave at zednenem.com Wed Sep 3 13:32:27 2008 From: dave at zednenem.com (David Menendez) Date: Wed Sep 3 13:30:36 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <2608b8a80809030630m7ef845aanf6467f666fc0aa32@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <49a77b7a0809030018k3b408483lc42dfb4e7b4a3607@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B851@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030412q57fa644idd62d92e94930783@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85D@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030519x9ef3678nadcd5ec535bf9ba5@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B85F@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030542k5caf3d4bo6d2a698e09fb5810@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B861@ELON17P32002A.csfb.cs-group.com> <2608b8a80809030630m7ef845aanf6467f666fc0aa32@mail.gmail.com> Message-ID: <49a77b7a0809031032h786bc313o6d725f409a834616@mail.gmail.com> On Wed, Sep 3, 2008 at 9:30 AM, Yitzchak Gale wrote: > I wrote >>> Other applications and libraries that support the pragma - >>> such as other compilers, and hs-plugins - would be >>> required to respect the guarantee, and bugs could be >>> filed against them if they don't. > > Sittampalam, Ganesh wrote: >> If hs-plugins were loading object code, how would it even >> know of the existence of the pragma? Given such >> knowledge, how would it implement it? > > Good point. A compiler pragma is only that, in the end. > This is just a hack, we can only do the best we can > with it. How does the FFI handle initialization? Presumably, we can link to libraries that have internal state. Could someone, in principle, use the FFI to create a global variable? -- Dave Menendez From andrewcoppin at btinternet.com Wed Sep 3 14:34:29 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Sep 3 14:32:39 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> Message-ID: <48BED8B5.5060905@btinternet.com> Brandon S. Allbery KF8NH wrote: > You can define a set of valid transformations, have the interpreter > log each transformation, and verify that all are correct (that is, > that both the transformation and the logged result are correct. > > This assumes the interpreter can be resolved down to a sufficiently > simple set of transformations; if not, you're right back at having the > tester being the interpreter itself. Note that you don't check if the > transformation plan for the program matches a specified list, just > that all transformations are correct. (Just remember that "logic is > an organized way of going wrong with confidence.") The amusing (?) part is that the interpretter itself is essentially quite simple. I've implemented it several times before now. But what I'm trying to do it make it print out elaborately formatted execution traces so that a human user can observe how execution proceeds. This transforms an essentially simple algorithm into something quite nausiatingly complex, with many subtle bugs and issues. Still, I guess it's not news to anybody that proof-of-concept programs are much easier that real-world implementations. One thing I could do is have QuickCheck build arbitrary expressions, run those through the pretty printer, and then run the result back through the parser and check that I get the same expression. Can anybody tell me how to get QuickCheck to build arbitrary expressions though? Let's say I had data Expression = Var String | Apply Expression Expression | Lambda String Expression How would you go about building random expression trees? From andrewcoppin at btinternet.com Wed Sep 3 14:36:54 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Sep 3 14:35:02 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <49928B37-F196-42BB-8D13-BE39E6A27581@ece.cmu.edu> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <49928B37-F196-42BB-8D13-BE39E6A27581@ece.cmu.edu> Message-ID: <48BED946.6020801@btinternet.com> Brandon S. Allbery KF8NH wrote: > On 2008 Sep 1, at 14:47, Andrew Coppin wrote: >> I wonder - how do the GHC developers check that GHC works properly? >> (I guess by compiling stuff and running it... It's a bit harder to >> check that a lambda interpretter is working right.) > > GHC has a comprehensive test suite (not included in the source tarball > or the default checkout but easily checked out atop GHC). I'm sure a large, complex product like GHC would have a large test suite. I was asking how it works. ;-) Since GHC actually transforms Haskell to machine code in several stages, I presume each one can be checked independently, which probably makes things easier. But I bet the GHC developers don't have any way to just automatically build 1,000 random test cases and check that the compiler "works" for those... From holgersiegel74 at yahoo.de Wed Sep 3 14:51:20 2008 From: holgersiegel74 at yahoo.de (hs) Date: Wed Sep 3 14:56:19 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> Message-ID: <200809032051.20178.holgersiegel74@yahoo.de> On Wednesday 03 September 2008 12:09:38 minh thu wrote: > Hi, > > I'd like to write a data structure to be used inside the IO monad. > The structure has some handles of type Maybe (IORef a), > i.e. IORef are pointers and the Maybe is like null pointers. > > So I came up with the following functions : > > readHandle :: Maybe (IORef a) -> IO (Maybe a) > readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) > > readHandle Nothing = do > return Nothing > readHandle (Just r) = do > v <- readIORef r > return $ Just v > > readField f h = do > m <- readHandle h > return $ fmap f m > > Is it something usual ? > Are there any related functions in the standard libraries ? A value of type Maybe (IORef a) is an optional pointer that must point to an object. If you want a pointer that points to either Nothing (aka null) or to a value, you should use IORef (Maybe a). Then readHandle :: IORef (Maybe a) -> IO (Maybe a) readHandle = readIORef readfield :: (a -> b) -> IORef (Maybe a) -> IO (Maybe b) readfield f p = (fmap . fmap) f (readIORef p) From ashley at semantic.org Wed Sep 3 15:08:44 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Sep 3 15:06:55 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> Message-ID: <48BEE0BC.8040706@semantic.org> Sittampalam, Ganesh wrote: > In compiled code module boundaries don't necessarily exist. So how > do you relink the loaded code so that it points to the unique copy > of the module? hs-plugins loads modules as single .o files, I believe. > It crashes the RTS of the plugins loader, which is based on ghci, which > is built around loading modules independently. I believe there's a > separate RTS running at the top level of the program which has no > knowledge of the plugin loader. Two RTSs? Are you quite sure? How would GC work? "The loader is a binding to the GHC runtime system's dynamic linker, which does single object loading. GHC also performs the necessary linking of new objects into the running process." -- Ashley Yakeley From jgm at berkeley.edu Wed Sep 3 16:14:49 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Wed Sep 3 16:12:21 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? Message-ID: <20080903201449.GA20567@berkeley.edu> It would be great if there were an automated or semi-automated way of generating a MacPorts Portfile from a HackageDB package, along the lines of dons' cabal2arch. Has anyone been working on such a thing? And, are any haskell-cafe readers MacPorts committers? John From j.m.m.joosten at hccnet.nl Wed Sep 3 16:22:56 2008 From: j.m.m.joosten at hccnet.nl (Han Joosten) Date: Wed Sep 3 16:21:07 2008 Subject: [Haskell-cafe] analyzing modules import/export Message-ID: <19297359.post@talk.nabble.com> I am currently involved with a Haskell project to create a toolset for a formal language. The toolset contains a parser, a typechecker and s range of other features. The Haskell code currently consists of about 20 modules. I am new in the project, and my impression is that a lot of code does not reside in the proper module. I would like to be able to get a good feeling in how the modules are structured, and how they are consumed by other modules. This would enable me to clean up a little bit. I use eclipsefp. Do you know of any way to get insight of the structure of modules? is any tooling available? Any suggestions would help a lot! Thanx for reading. Han Joosten -- View this message in context: http://www.nabble.com/analyzing-modules-import-export-tp19297359p19297359.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From duncan.coutts at worc.ox.ac.uk Wed Sep 3 16:41:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 3 16:38:49 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <20080903201449.GA20567@berkeley.edu> References: <20080903201449.GA20567@berkeley.edu> Message-ID: <1220474509.24846.486.camel@localhost> On Wed, 2008-09-03 at 13:14 -0700, John MacFarlane wrote: > It would be great if there were an automated or semi-automated way > of generating a MacPorts Portfile from a HackageDB package, along > the lines of dons' cabal2arch. Has anyone been working on such a thing? > And, are any haskell-cafe readers MacPorts committers? Whoever starts on this should not start from scratch. We now have several of these tools so there's lots of code to look at but ideally we should be sharing more code. One possible plan I have is for cabal-install to be a lib and a tool because there's a lot of useful code in there that these tools could re-use and share. Duncan From dons at galois.com Wed Sep 3 16:49:38 2008 From: dons at galois.com (Don Stewart) Date: Wed Sep 3 16:47:43 2008 Subject: [Haskell-cafe] analyzing modules import/export In-Reply-To: <19297359.post@talk.nabble.com> References: <19297359.post@talk.nabble.com> Message-ID: <20080903204938.GD3076@scytale.galois.com> j.m.m.joosten: > > I am currently involved with a Haskell project to create a toolset for a > formal language. The toolset contains a parser, a typechecker and s range of > other features. > > The Haskell code currently consists of about 20 modules. I am new in > the project, and my impression is that a lot of code does not reside > in the proper module. I would like to be able to get a good feeling in > how the modules are structured, and how they are consumed by other > modules. This would enable me to clean up a little bit. > > I use eclipsefp. Do you know of any way to get insight of the > structure of modules? is any tooling available? Any suggestions would > help a lot! Thanx for reading. There's been a few projects at Galois for this kind of high level structural analysis. We're trying to polish them up into a release. For now, there's one tool you can get started with: graphmod. This tool was written by Andy Gill (the dotgen part) and Iavor Diatchki (the graphmod part), and you can use it like so: $ git clone http://code.haskell.org/graphmod.git $ cd graphmod -- build dotgen $ cd dotgen .. edit the .cabal file to add the line: Build-type: Simple after the Exposed-modules line $ cabal install -- build graphmod $ cd .. $ cabal install ... Installing: /home/dons/.cabal/bin Now you have 'graphmod' a tool for drawing the module structure. So go find a project, and analyze it: $ cd ~/xmonad -- generate module graph $ graphmod XMonad XMonad.hs Main.hs > /tmp/xmonad.dot -- generate svg of graph $ dot -Tsvg /tmp/xmonad.dot > xmonad.svg Which gives this result: http://galois.com/~dons/images/xmonad.svg Enjoy! -- Don From dons at galois.com Wed Sep 3 16:57:53 2008 From: dons at galois.com (Don Stewart) Date: Wed Sep 3 16:56:03 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <1220474509.24846.486.camel@localhost> References: <20080903201449.GA20567@berkeley.edu> <1220474509.24846.486.camel@localhost> Message-ID: <20080903205753.GE3076@scytale.galois.com> duncan.coutts: > On Wed, 2008-09-03 at 13:14 -0700, John MacFarlane wrote: > > It would be great if there were an automated or semi-automated way > > of generating a MacPorts Portfile from a HackageDB package, along > > the lines of dons' cabal2arch. Has anyone been working on such a thing? > > And, are any haskell-cafe readers MacPorts committers? > > Whoever starts on this should not start from scratch. We now have > several of these tools so there's lots of code to look at but ideally we > should be sharing more code. It seems the front end of cabal2arch -- general parsing and processing of .cabal files, would be reusable in any tool. foo.cabal url | v Parsed cabal file | v Resolved dependencies/flags | v Normalised for Arch | v Translated into ArchPkg ADT | v instance Pretty ArchPkg | v foo.tar.gz native Arch package. You just have to define a data structure for the target output, and a pretty printer instance, and any platform specific dep differences. -- Don From gwern0 at gmail.com Wed Sep 3 17:17:34 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Sep 3 17:17:35 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> Message-ID: <20080903211734.GA5637@craft> On 2008.08.24 11:41:04 -0400, Eric Kidd scribbled 3.7K characters: > Greetings, Haskell folks! > > I'm working on a toy program for drum synthesis. This has lead me to > explore the various sound-related libraries in Hackage. Along the way, > I've learned several things: > > 1. There's a lot of Haskell sound libraries, but no agreement on how > to represent buffers of audio data. > 2. Some of the most useful sound libraries aren't listed in Hackage's > "Sound" section, including HCodecs, SDL-mixer and hogg. Have you contacted the authors to ask they add the Sound categorization? I already sent a hogg patch, but couldn't find any darcs repositories for SDL-mixer or HCodecs. ... > No public sound-buffer API: > hbeat: The relevant source files are missing! The cabal file was missing the Other-modules field. I've sent the author a patch. -- gwern Surveillance Defcon S511 anarchy REP NSIRL grenades dort UT/RUS W -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080903/743a3f8d/attachment-0001.bin From dave at zednenem.com Wed Sep 3 17:54:28 2008 From: dave at zednenem.com (David Menendez) Date: Wed Sep 3 17:52:36 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <20080903201449.GA20567@berkeley.edu> References: <20080903201449.GA20567@berkeley.edu> Message-ID: <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> On Wed, Sep 3, 2008 at 4:14 PM, John MacFarlane wrote: > It would be great if there were an automated or semi-automated way > of generating a MacPorts Portfile from a HackageDB package, along > the lines of dons' cabal2arch. Has anyone been working on such a thing? > And, are any haskell-cafe readers MacPorts committers? Gregory Wright handles the ports of GHC, alex, happy, haddock, and others. In my experience thus far, MacPorts feels like a poor match for Cabal. As far as I can tell, you get at most one active installation of a given port, which means you can't use MacPorts to manage packages for multiple Haskell environments (GHC and Hugs, stable GHC and development GHC, etc.), and after a GHC upgrade, any installed Haskell packages will still be installed, even though the new GHC can't see or use them. -- Dave Menendez From ryani.spam at gmail.com Wed Sep 3 17:54:46 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Sep 3 17:52:55 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48BED8B5.5060905@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> <48BED8B5.5060905@btinternet.com> Message-ID: <2f9b2d30809031454y6274c2f4g4e2ef0d70e8990f7@mail.gmail.com> On Wed, Sep 3, 2008 at 11:34 AM, Andrew Coppin wrote: > data Expression = Var String | Apply Expression Expression | Lambda String > Expression > > How would you go about building random expression trees? It's pretty simple, I think. Keep an environment of variable names that are in enclosing lambdas, then randomly choose Apply/Lambda/Var, ignoring Var if the environment is empty, and with Lambda adding to the environment of its subexpression. I suggest type ExpGen = ReaderT [String] Gen arbExp :: ExpGen Expression -- exercise for the reader instance Arbitrary Expression where arbitrary = runReaderT arbExp [] coarbitrary = coarbExp coarbExp (Var s) = variant 0 . coarbitrary s coarbExp (Apply a b) = variant 1 . coarbitrary a . coarbitrary b coarbExp (Lambda s e) = variant 2 . coarbitrary s . coarbitrary e -- Also, apparently there is no default Arbitrary instance for strings, so... instance Arbitrary Char where arbitrary = elements "abcdefghijklmnopqrstuvwxyz_" coarbitrary = coarbitrary . fromEnum Here's some examples I got with a quick and dirty implementation for arbExp: Lambda "" (Lambda "" (Var "")) Lambda "jae" (Lambda "iq" (Var "jae")) Lambda "sj" (Lambda "" (Var "")) Lambda "n" (Var "n") Lambda "lxy" (Lambda "md_fy" (Lambda "b" (Var "b"))) Lambda "" (Apply (Lambda "" (Var "")) (Lambda "" (Lambda "" (Var "")))) Lambda "vve" (Lambda "mvy" (Var "vve")) Lambda "" (Apply (Apply (Var "") (Lambda "km" (Var "km"))) (Var "")) Lambda "" (Lambda "_" (Var "")) Lambda "aeq" (Var "aeq") Lambda "l_" (Apply (Var "l_") (Lambda "" (Var "l_"))) My implementation doesn't choose Apply nearly enough, but I was worried about exponential blowup; the solution is to use the "sized" combinator from QuickCheck and have the size determine the number of Apply you are allowed to have. It's also probably a good idea to not allow empty strings for variable names :) -- ryan From allbery at ece.cmu.edu Wed Sep 3 18:25:10 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Sep 3 18:23:26 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48BED8B5.5060905@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> <48BED8B5.5060905@btinternet.com> Message-ID: On 2008 Sep 3, at 14:34, Andrew Coppin wrote: > Brandon S. Allbery KF8NH wrote: >> You can define a set of valid transformations, have the interpreter >> log each transformation, and verify that all are correct (that is, >> that both the transformation and the logged result are correct. >> >> This assumes the interpreter can be resolved down to a sufficiently >> simple set of transformations; if not, you're right back at having >> the tester being the interpreter itself. Note that you don't check >> if the transformation plan for the program matches a specified >> list, just that all transformations are correct. (Just remember >> that "logic is an organized way of going wrong with confidence.") > > The amusing (?) part is that the interpretter itself is essentially > quite simple. I've implemented it several times before now. But what > I'm trying to do it make it print out elaborately formatted > execution traces so that a human user can observe how execution > proceeds. This transforms an essentially simple algorithm into > something quite nausiatingly complex, with many subtle bugs and > issues. This seems odd to me: I would expect to wrap a WriterT around it, log unformatted actions there, and dump it to a file at the end to be read by an analyzer tool which can optionally reformat the log to be human- readable. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From wren at freegeek.org Wed Sep 3 23:03:39 2008 From: wren at freegeek.org (wren ng thornton) Date: Wed Sep 3 23:01:51 2008 Subject: [Haskell-cafe] Re: Research language vs. professional language In-Reply-To: <1220292262.6369.51.camel@jonathans-macbook> References: <2f9b2d30809010107m264416b6o65f269eccedcbb55@mail.gmail.com> <1220292262.6369.51.camel@jonathans-macbook> Message-ID: <48BF500B.9090800@freegeek.org> Jonathan Cast wrote: > > But Haskell's community is also growing > > This is good! > > > and becoming more > > results-oriented. > > This is not; see my other post. I think it's great that Haskellers are > starting to accomplish useful things, but if in the process I think > elders like Lennart Augustsson and Paul Hudak are starting to be > ignored. Hair-shirt wearers need to have someplace to live. Up until > recently, that's been Haskell. I can't help seeing putting things like > ad-hoc overloading or ACIO into Haskell as theft of that territory from > them, and I think it's incumbent upon those who would do such a thing to > propose where the hair-shirt wearers are going to receive asylum now > that they're being expelled from Haskell. I can't express how strongly I agree with this. For me, the most fundamental and radical idea of Haskell is the idea of purity. For a long time functional languages have claimed the moral high ground, but they've all made concessions against purity. In a world dominated by impure procedural languages, it is imperative to have a language which is unwilling to make concessions for the sake of expediency. Moreover, it is imperative to have a language which is just as vehement about finding the correct answer as it is unwilling to concede. I'm eternally grateful that Haskell has had that vehemence, because it means I can use it in day-to-day programming and at work. But sacrificing that purity for daily expediency defeats the whole exercise. If it can't be done purely then we're doing it wrong. I chose to don the hair shirt. > > So, my question for you is: if Haskell is a research language, what > > direction should it be taking? What changes should be happening at > > the language (not the library) level that are in the interests of > > improving the state-of-the-art in functional programming? * Extensible records, seconding Jonathan Cast. * Extensible unions. Something combining Datatypes a la Carte with the work on Bit-C to allow construction of ad-hoc unions as well as specifying how the unions are tagged, all while ensuring safety. DTalC is nice but it would be nicer if we could use, say, a Huffman encoding of the coproduct tag rather than just a linear encoding. * Inference with type-classes (and fundeps). How exactly we determine the correct instance to choose has some irksome limitations at present. It would be nice to explore how much of logic programming we could lift into this decision without ruining performance. Many of the proposals for haskell' to deal with MPTC are in a similar vein. * Refinement types. Doing this purely would help capture a wide genre of OO-like ad-hoc polymorphism, and it would let us totalize partial functions like `head` and `div`. * Top-level mutable variables, dynamic linking. This is also seconding Cast, but I mention it more in the vein of capability systems and component-based programming. Having a coherent story for how programs are constructed from components/modules including all the gritty bits about duplicating components and wiring them together efficiently; that is, can we take the compositional and applicative features of functional programming and apply them to the module layer? * Distributed processes. This is more in the vein of Erlang, but an exploration of the problem space seems to be in order. This feels very similar to the previous point, though one of the key focuses here would be on the memory model and GC. * Effect systems, in particular the composition of effects. Monads are nice and fun, but they do sort of paint one into a corner language-design-wise: once you use them to encapsulate effects, that forces your hand when it comes to combining effects etc. Also, this essentially gives us two orders of evaluation: by-need for pure values, and sequentially for effectful values. What about other orders for effectful values? What about breaking up the sin bin of IO? Studying this in depth would most likely fork the language, but there is still research to be done. > > My goal is > > to make it not be a joke when I go to work and suggest that we use > > Haskell for part of our next project. What is yours? > > My goal is to ensure there's an even better language to propose using 10 > years from now. Again, ditto Cast. In ten years I want a language that's as far ahead of Haskell as Haskell is ahead of the other languages out there today. -- Live well, ~wren From wren at freegeek.org Wed Sep 3 23:29:48 2008 From: wren at freegeek.org (wren ng thornton) Date: Wed Sep 3 23:27:59 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <48BD40F1.6050905@gmail.com> References: <48BD40F1.6050905@gmail.com> Message-ID: <48BF562C.2020408@freegeek.org> Ramin wrote: > Hello, I'm new here, but in the short time I have known Haskell, I can > already say it's my favorite computer language. > > Except for monads, and no matter how many tutorials I read, I find the > only kind of monad I can write is the monad that I copied and pasted > from the tutorial, i.e. I still don't get it even though I thought I > understood the tutorial, and I'm stuck using monads others have already > written. > > My project is this: I am writing a mini-database of sorts. I thought I > would make a query a monad, so I could chain multiple queries together > using the "do" notation, and run more complex queries on the list in one > shot. The query itself is stateful because it contains information that > changes as the database is traversed. The query may also make updates to > the records. I got the program to work perfectly using purely functional > techniques, but complex queries resulted in that stair-step looking > code. So I thought this would be the perfect opportunity to try my hand > at monads. > > The query monad I wrote looks something like this (much simplified): > data Query state rec = Query !(state, rec) A minor point but, that strictness annotation doesn't help you very much since tuples are lazy in their arguments. That declaration has the same strictness properties as: data Query state rec = Query state rec The only difference is that your version gives you the "free" ability to convert from a (Query s r) to a (s,r). The "free" is in quotes because either there's a cost in indirection to access the state and rec fields, or you've told GHC to optimize the tuple away in which case there's a cost in reconstructing the tuple when demanded.[1] Sometimes there's a reason to use a type like this, but generally it's not what was intended. If you want the datatype to be strict in state and rec, then you should add strictness annotations to those fields directly: data Query state rec = Query !state !rec [1] That is, when a tuple _really_ is demanded. GHC does a good job of replacing tuples with unboxed-tuples when optimizations are turned on. In these cases the code isn't really asking for a tuple so one needn't be reconstructed. -- Live well, ~wren From gour at mail.inet.hr Thu Sep 4 00:53:47 2008 From: gour at mail.inet.hr (Gour) Date: Thu Sep 4 00:52:07 2008 Subject: [Haskell-cafe] Haskell and i18n (aka gettext) support Message-ID: <87k5dsmrz8.fsf@gaura-nitai.no-ip.org> Dear Haskellers, Some time ago the question was asked on gtk2hs mailing list about how to work with *.po files, i.e. how to make Haskell program i18n-aware. (see http://thread.gmane.org/gmane.comp.lang.haskell.gtk2hs/592) The answer was that Gtk2hs does not have gettext support (http://article.gmane.org/gmane.comp.lang.haskell.gtk2hs/593), but that it is something which is needed (http://article.gmane.org/gmane.comp.lang.haskell.gtk2hs/598) but it's not clear how to do it. As potential 'solution the 'i18n' package was mentioned (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/i18n) with the remark that its API is not the most beautiful. Moreover, by looking at i18n's *.cabal file one can see it is labelled as 'experimental'. Moreover, if one inspects GNU gettext manual one can see the list of languages with the explanations how to make the program i18n-ready. The list is, unfortunately, without Haskell: * C: C, C++, Objective C * sh: sh - Shell Script * bash: bash - Bourne-Again Shell Script * Python: Python * Common Lisp: GNU clisp - Common Lisp * clisp C: GNU clisp C sources * Emacs Lisp: Emacs Lisp * librep: librep * Scheme: GNU guile - Scheme * Smalltalk: GNU Smalltalk * Java: Java * C#: C# * gawk: GNU awk * Pascal: Pascal - Free Pascal Compiler * wxWidgets: wxWidgets library * YCP: YCP - YaST2 scripting language * Tcl: Tcl - Tk's scripting language * Perl: Perl * PHP: PHP Hypertext Preprocessor * Pike: Pike * GCC-source: GNU Compiler Collection sources Real World Haskell book is at the door and it will bring army of new Haskell programmers to find out that Haskell misses one of the important items in its "battery set". :-( So, we think that i18n issue or proper gettext support should have a stable and well documented implementation and has to be part of "batteries included" or Haskell Platform (http://www.haskell.org/haskellwiki/Haskell_Platform) However, don't ask me 'how' :-D We got some hints on the IRC yesterday, but considering it is important issue for the whole Haskell community, we are bringing it here so that smarter and more skillful (than ourselves) souls can discuss it. I hope you are not seeing it as critique of the Haskell, but rather as attempt to improve our beloved language with the feature necessary to be included in the arsenal of every general programming language. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080904/2edcede3/attachment.bin From tim at goddard.net.nz Thu Sep 4 02:33:22 2008 From: tim at goddard.net.nz (Timothy Goddard) Date: Thu Sep 4 02:31:34 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> Message-ID: <200809041833.23130.tim@goddard.net.nz> It looks like this code isn't really in fitting with normal Haskell idioms. Emulating C in Haskell will only give you a harder way of writing C. Don't think about emulating a potentially null pointer with Maybe (IORef a) and passing this to a function to read content unless you also want to implement the function "segfault :: IO ()". You really need to ask yourself whether it makes sense to read a NULL / Nothing field. In C this would cause a segfault. The idea in Haskell is that you don't allow invalid values to be passed in to a function at all. Each function should be pure and accept only sensible inputs, allowing you to analyse what each function does in isolation from the rest of the program. In Haskell, functions should use the type system to only accept arguments which make sense. The caller should handle the possibility that a function it calls returns nothing, not expect every other callee to do so. The Maybe monad helps with this for many cases: lookupEmployee :: Integer -> Maybe Employee lookupPassportNo :: Employee -> PassportNo lookupMarriageCertificate :: PassportNo -> Maybe MarriageCert getPassportNumbers :: MarriageCert -> (PassportNo, PassportNo) getNameFromPassport :: PassportNo -> Maybe String lookupSpouse :: Integer -> Maybe String lookupSpouse employee_no = do employee <- lookupEmployee employee_no let passport = lookupPassportNo employee cert <- lookupMarriageCertificate let (p1, p2) = getPassportNumbers cert let partner = if p1 == passport then p2 else p1 getNameFromPassport partner In this example, if any lookup which can fail does, the result is Nothing. Each lookup function can assume that a valid argument is present, though some types of lookup may still give no result. The caller chooses how to account for this inability to find a match, in this case by itself having no result. The thing I'm more concerned about here is the use of IORefs inside data structures at all. A data structure containing IORefs is mutable and can only be manipulated in the IO monad, which defeats the point of Haskell. There is a use case for using mutable structures for some resource-intensive operations, but even then it's often trading short-term speed for long term difficulties. If you think immutable structures imply poor performance, take a look at projects such as uvector and Data Parallel Haskell - immutable data structures which beat the hell out traditional, C-like techniques. If you must use IORefs, consider only using them to hold the whole structure, which is modified by normal, pure functions. If you don't think you can make do with this, you're probably still thinking about the program in an imperative manner. You will probably be better off either rethinking how you're doing things or, if you cannot translate the concepts to a functional form, using an imperative language. Good luck, Tim On Wed, 03 Sep 2008 22:09:38 minh thu wrote: > Hi, > > I'd like to write a data structure to be used inside the IO monad. > The structure has some handles of type Maybe (IORef a), > i.e. IORef are pointers and the Maybe is like null pointers. > > So I came up with the following functions : > > readHandle :: Maybe (IORef a) -> IO (Maybe a) > readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) > > readHandle Nothing = do > return Nothing > readHandle (Just r) = do > v <- readIORef r > return $ Just v > > readField f h = do > m <- readHandle h > return $ fmap f m > > Is it something usual ? > Are there any related functions in the standard libraries ? > > Thanks, > Thu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From waldmann at imn.htwk-leipzig.de Thu Sep 4 02:36:46 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Sep 4 02:37:15 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <200809041833.23130.tim@goddard.net.nz> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <200809041833.23130.tim@goddard.net.nz> Message-ID: <48BF81FE.30206@imn.htwk-leipzig.de> Timothy Goddard wrote: > It looks like this code isn't really in fitting with normal Haskell idioms [...] this is all very much true. Still I understand the application area (for this example) is interactive graph editing and there the "in-place update" perhaps is the right model for what the user of the program does (remove/insert node/edge). So at least the model of the GUI needs some notion of "state"? Of course from the GUI state one should compute the underlying and *immutable* data object for further processing. J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080904/5727085e/signature.bin From noteed at gmail.com Thu Sep 4 03:53:35 2008 From: noteed at gmail.com (minh thu) Date: Thu Sep 4 03:51:43 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <200809041833.23130.tim@goddard.net.nz> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <200809041833.23130.tim@goddard.net.nz> Message-ID: <40a414c20809040053y3378aabfsd9b2ec55c71a8990@mail.gmail.com> 2008/9/4 Timothy Goddard : > It looks like this code isn't really in fitting with normal Haskell idioms. I guess you mean by Haskell idiom : "pure". But Haskell allows you to do IO, etc. > Emulating C in Haskell will only give you a harder way of writing C. Don't > think about emulating a potentially null pointer with Maybe (IORef a) and > passing this to a function to read content unless you also want to implement > the function "segfault :: IO ()". > You really need to ask yourself whether it makes sense to read a NULL / > Nothing field. In C this would cause a segfault. The idea in Haskell is that > you don't allow invalid values to be passed in to a function at all. Each > function should be pure and accept only sensible inputs, allowing you to > analyse what each function does in isolation from the rest of the program. > > In Haskell, functions should use the type system to only accept arguments > which make sense. The caller should handle the possibility that a function it > calls returns nothing, not expect every other callee to do so. The Maybe > monad helps with this for many cases: > > lookupEmployee :: Integer -> Maybe Employee > lookupPassportNo :: Employee -> PassportNo > lookupMarriageCertificate :: PassportNo -> Maybe MarriageCert > getPassportNumbers :: MarriageCert -> (PassportNo, PassportNo) > getNameFromPassport :: PassportNo -> Maybe String > > lookupSpouse :: Integer -> Maybe String > lookupSpouse employee_no = do > employee <- lookupEmployee employee_no > let passport = lookupPassportNo employee > cert <- lookupMarriageCertificate > let (p1, p2) = getPassportNumbers cert > let partner = if p1 == passport then p2 else p1 > getNameFromPassport partner > > In this example, if any lookup which can fail does, the result is Nothing. > Each lookup function can assume that a valid argument is present, though some > types of lookup may still give no result. The caller chooses how to account > for this inability to find a match, in this case by itself having no result. Thanks for the exemple, but I'm aware of monads (even if I can't still use them easily when many of them are mixed). Here my problem is more about interactively editable data structure (at least from the point of view of the user). I would be very happy to do it with pure functions. > The thing I'm more concerned about here is the use of IORefs inside data > structures at all. A data structure containing IORefs is mutable and can only > be manipulated in the IO monad, which defeats the point of Haskell. There is > a use case for using mutable structures for some resource-intensive > operations, but even then it's often trading short-term speed for long term > difficulties. If you think immutable structures imply poor performance, take > a look at projects such as uvector and Data Parallel Haskell - immutable data > structures which beat the hell out traditional, C-like techniques. I'm looking at the FGL package, it seems very intersting. I don't think immutable data structures imply poor perfromance, but I think designing the examples you give is quite complicated and done by really experienced Haskell programmers. Please, don't answer to my problem (even if I haven't really explain it) by exposing state-of-the-art Haskell goodness. > If you must use IORefs, consider only using them to hold the whole structure, > which is modified by normal, pure functions. If you don't think you can make > do with this, you're probably still thinking about the program in an > imperative manner. You will probably be better off either rethinking how > you're doing things or, if you cannot translate the concepts to a functional > form, using an imperative language. Overall, I agree I have to look for a more pure approach. Although, I think something like FGL required a lot of work. But raising, say, uvector, in face of my use of IORef seems a bit quick. > Good luck, Thank you, Thu > > Tim > > On Wed, 03 Sep 2008 22:09:38 minh thu wrote: >> Hi, >> >> I'd like to write a data structure to be used inside the IO monad. >> The structure has some handles of type Maybe (IORef a), >> i.e. IORef are pointers and the Maybe is like null pointers. >> >> So I came up with the following functions : >> >> readHandle :: Maybe (IORef a) -> IO (Maybe a) >> readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) >> >> readHandle Nothing = do >> return Nothing >> readHandle (Just r) = do >> v <- readIORef r >> return $ Just v >> >> readField f h = do >> m <- readHandle h >> return $ fmap f m >> >> Is it something usual ? >> Are there any related functions in the standard libraries ? >> >> Thanks, >> Thu >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ganesh.sittampalam at credit-suisse.com Thu Sep 4 04:43:51 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Sep 4 04:42:38 2008 Subject: [Haskell-cafe] RE: [Haskell] Top Level <- In-Reply-To: <48BEE0BC.8040706@semantic.org> References: <534781822.20080826190130@gmail.com> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > Sittampalam, Ganesh wrote: > > In compiled code module boundaries don't necessarily exist. So how do > > you relink the loaded code so that it points to the unique copy of the > > module? > hs-plugins loads modules as single .o files, I believe. Yes, but (a) the loading program doesn't and (b) that's an implementation choice, not a necessity. > Two RTSs? Are you quite sure? How would GC work? I talked to Don about this and you're right, that doesn't happen. However he also confirmed that it does load modules a second time if they are in the main program as well as the plugin, and it would be difficult to merge the static and dynamic versions of the module. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From lennart at augustsson.net Thu Sep 4 04:44:49 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Sep 4 04:42:57 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809040053y3378aabfsd9b2ec55c71a8990@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <200809041833.23130.tim@goddard.net.nz> <40a414c20809040053y3378aabfsd9b2ec55c71a8990@mail.gmail.com> Message-ID: I would represent the data structure in a pure way, and restrict the IO monad to the operations that actually do IO. If you need some kind of mutable graph, I suggest representing that graph as a map (Data.Map) from node names to neighbors. The "mutation" is then just updating the map. An extra benefit from this is that you get really simple undo in your editor. -- Lennart On Thu, Sep 4, 2008 at 8:53 AM, minh thu wrote: > 2008/9/4 Timothy Goddard : >> It looks like this code isn't really in fitting with normal Haskell idioms. > > I guess you mean by Haskell idiom : "pure". But Haskell allows you to > do IO, etc. > >> Emulating C in Haskell will only give you a harder way of writing C. Don't >> think about emulating a potentially null pointer with Maybe (IORef a) and >> passing this to a function to read content unless you also want to implement >> the function "segfault :: IO ()". > >> You really need to ask yourself whether it makes sense to read a NULL / >> Nothing field. In C this would cause a segfault. The idea in Haskell is that >> you don't allow invalid values to be passed in to a function at all. Each >> function should be pure and accept only sensible inputs, allowing you to >> analyse what each function does in isolation from the rest of the program. >> >> In Haskell, functions should use the type system to only accept arguments >> which make sense. The caller should handle the possibility that a function it >> calls returns nothing, not expect every other callee to do so. The Maybe >> monad helps with this for many cases: >> >> lookupEmployee :: Integer -> Maybe Employee >> lookupPassportNo :: Employee -> PassportNo >> lookupMarriageCertificate :: PassportNo -> Maybe MarriageCert >> getPassportNumbers :: MarriageCert -> (PassportNo, PassportNo) >> getNameFromPassport :: PassportNo -> Maybe String >> >> lookupSpouse :: Integer -> Maybe String >> lookupSpouse employee_no = do >> employee <- lookupEmployee employee_no >> let passport = lookupPassportNo employee >> cert <- lookupMarriageCertificate >> let (p1, p2) = getPassportNumbers cert >> let partner = if p1 == passport then p2 else p1 >> getNameFromPassport partner >> >> In this example, if any lookup which can fail does, the result is Nothing. >> Each lookup function can assume that a valid argument is present, though some >> types of lookup may still give no result. The caller chooses how to account >> for this inability to find a match, in this case by itself having no result. > > Thanks for the exemple, but I'm aware of monads (even if I can't still > use them easily when > many of them are mixed). > Here my problem is more about interactively editable data structure > (at least from the > point of view of the user). I would be very happy to do it with pure functions. > >> The thing I'm more concerned about here is the use of IORefs inside data >> structures at all. A data structure containing IORefs is mutable and can only >> be manipulated in the IO monad, which defeats the point of Haskell. There is >> a use case for using mutable structures for some resource-intensive >> operations, but even then it's often trading short-term speed for long term >> difficulties. If you think immutable structures imply poor performance, take >> a look at projects such as uvector and Data Parallel Haskell - immutable data >> structures which beat the hell out traditional, C-like techniques. > > I'm looking at the FGL package, it seems very intersting. I don't > think immutable data > structures imply poor perfromance, but I think designing the examples you give > is quite complicated and done by really experienced Haskell programmers. > Please, don't answer to my problem (even if I haven't really explain > it) by exposing > state-of-the-art Haskell goodness. > >> If you must use IORefs, consider only using them to hold the whole structure, >> which is modified by normal, pure functions. If you don't think you can make >> do with this, you're probably still thinking about the program in an >> imperative manner. You will probably be better off either rethinking how >> you're doing things or, if you cannot translate the concepts to a functional >> form, using an imperative language. > > Overall, I agree I have to look for a more pure approach. Although, I > think something like > FGL required a lot of work. But raising, say, uvector, in face of my > use of IORef seems a bit > quick. > >> Good luck, > > Thank you, > Thu > >> >> Tim >> >> On Wed, 03 Sep 2008 22:09:38 minh thu wrote: >>> Hi, >>> >>> I'd like to write a data structure to be used inside the IO monad. >>> The structure has some handles of type Maybe (IORef a), >>> i.e. IORef are pointers and the Maybe is like null pointers. >>> >>> So I came up with the following functions : >>> >>> readHandle :: Maybe (IORef a) -> IO (Maybe a) >>> readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) >>> >>> readHandle Nothing = do >>> return Nothing >>> readHandle (Just r) = do >>> v <- readIORef r >>> return $ Just v >>> >>> readField f h = do >>> m <- readHandle h >>> return $ fmap f m >>> >>> Is it something usual ? >>> Are there any related functions in the standard libraries ? >>> >>> Thanks, >>> Thu >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From noteed at gmail.com Thu Sep 4 05:03:53 2008 From: noteed at gmail.com (minh thu) Date: Thu Sep 4 05:02:01 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <200809041833.23130.tim@goddard.net.nz> <40a414c20809040053y3378aabfsd9b2ec55c71a8990@mail.gmail.com> Message-ID: <40a414c20809040203n766bcadfw86f25fa34d05fe84@mail.gmail.com> 2008/9/4 Lennart Augustsson : > I would represent the data structure in a pure way, and restrict the > IO monad to the operations that actually do IO. > If you need some kind of mutable graph, I suggest representing that > graph as a map (Data.Map) from node names to neighbors. > The "mutation" is then just updating the map. An extra benefit from > this is that you get really simple undo in your editor. This is what I was looking yesterday and right now,probably using Data.IntMap. Data.FiniteMap on hackage says it's deprecated. Do you know in favor of what ? FGL uses its own Data.Graph.Inductive.Internal.FiniteMap, saying Data.FiniteMap is not enough. Should it use Data.Map ? Thanks for the suggestion, Thu > -- Lennart > > On Thu, Sep 4, 2008 at 8:53 AM, minh thu wrote: >> 2008/9/4 Timothy Goddard : >>> It looks like this code isn't really in fitting with normal Haskell idioms. >> >> I guess you mean by Haskell idiom : "pure". But Haskell allows you to >> do IO, etc. >> >>> Emulating C in Haskell will only give you a harder way of writing C. Don't >>> think about emulating a potentially null pointer with Maybe (IORef a) and >>> passing this to a function to read content unless you also want to implement >>> the function "segfault :: IO ()". >> >>> You really need to ask yourself whether it makes sense to read a NULL / >>> Nothing field. In C this would cause a segfault. The idea in Haskell is that >>> you don't allow invalid values to be passed in to a function at all. Each >>> function should be pure and accept only sensible inputs, allowing you to >>> analyse what each function does in isolation from the rest of the program. >>> >>> In Haskell, functions should use the type system to only accept arguments >>> which make sense. The caller should handle the possibility that a function it >>> calls returns nothing, not expect every other callee to do so. The Maybe >>> monad helps with this for many cases: >>> >>> lookupEmployee :: Integer -> Maybe Employee >>> lookupPassportNo :: Employee -> PassportNo >>> lookupMarriageCertificate :: PassportNo -> Maybe MarriageCert >>> getPassportNumbers :: MarriageCert -> (PassportNo, PassportNo) >>> getNameFromPassport :: PassportNo -> Maybe String >>> >>> lookupSpouse :: Integer -> Maybe String >>> lookupSpouse employee_no = do >>> employee <- lookupEmployee employee_no >>> let passport = lookupPassportNo employee >>> cert <- lookupMarriageCertificate >>> let (p1, p2) = getPassportNumbers cert >>> let partner = if p1 == passport then p2 else p1 >>> getNameFromPassport partner >>> >>> In this example, if any lookup which can fail does, the result is Nothing. >>> Each lookup function can assume that a valid argument is present, though some >>> types of lookup may still give no result. The caller chooses how to account >>> for this inability to find a match, in this case by itself having no result. >> >> Thanks for the exemple, but I'm aware of monads (even if I can't still >> use them easily when >> many of them are mixed). >> Here my problem is more about interactively editable data structure >> (at least from the >> point of view of the user). I would be very happy to do it with pure functions. >> >>> The thing I'm more concerned about here is the use of IORefs inside data >>> structures at all. A data structure containing IORefs is mutable and can only >>> be manipulated in the IO monad, which defeats the point of Haskell. There is >>> a use case for using mutable structures for some resource-intensive >>> operations, but even then it's often trading short-term speed for long term >>> difficulties. If you think immutable structures imply poor performance, take >>> a look at projects such as uvector and Data Parallel Haskell - immutable data >>> structures which beat the hell out traditional, C-like techniques. >> >> I'm looking at the FGL package, it seems very intersting. I don't >> think immutable data >> structures imply poor perfromance, but I think designing the examples you give >> is quite complicated and done by really experienced Haskell programmers. >> Please, don't answer to my problem (even if I haven't really explain >> it) by exposing >> state-of-the-art Haskell goodness. >> >>> If you must use IORefs, consider only using them to hold the whole structure, >>> which is modified by normal, pure functions. If you don't think you can make >>> do with this, you're probably still thinking about the program in an >>> imperative manner. You will probably be better off either rethinking how >>> you're doing things or, if you cannot translate the concepts to a functional >>> form, using an imperative language. >> >> Overall, I agree I have to look for a more pure approach. Although, I >> think something like >> FGL required a lot of work. But raising, say, uvector, in face of my >> use of IORef seems a bit >> quick. >> >>> Good luck, >> >> Thank you, >> Thu >> >>> >>> Tim >>> >>> On Wed, 03 Sep 2008 22:09:38 minh thu wrote: >>>> Hi, >>>> >>>> I'd like to write a data structure to be used inside the IO monad. >>>> The structure has some handles of type Maybe (IORef a), >>>> i.e. IORef are pointers and the Maybe is like null pointers. >>>> >>>> So I came up with the following functions : >>>> >>>> readHandle :: Maybe (IORef a) -> IO (Maybe a) >>>> readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) >>>> >>>> readHandle Nothing = do >>>> return Nothing >>>> readHandle (Just r) = do >>>> v <- readIORef r >>>> return $ Just v >>>> >>>> readField f h = do >>>> m <- readHandle h >>>> return $ fmap f m >>>> >>>> Is it something usual ? >>>> Are there any related functions in the standard libraries ? >>>> >>>> Thanks, >>>> Thu >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From duncan.coutts at worc.ox.ac.uk Thu Sep 4 05:19:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 4 05:16:31 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> Message-ID: <1220519979.24846.513.camel@localhost> On Wed, 2008-09-03 at 17:54 -0400, David Menendez wrote: > On Wed, Sep 3, 2008 at 4:14 PM, John MacFarlane wrote: > > It would be great if there were an automated or semi-automated way > > of generating a MacPorts Portfile from a HackageDB package, along > > the lines of dons' cabal2arch. Has anyone been working on such a thing? > > And, are any haskell-cafe readers MacPorts committers? > > Gregory Wright handles the ports of GHC, alex, happy, haddock, and others. > > In my experience thus far, MacPorts feels like a poor match for Cabal. > As far as I can tell, you get at most one active installation of a > given port, which means you can't use MacPorts to manage packages for > multiple Haskell environments (GHC and Hugs, stable GHC and > development GHC, etc.), and after a GHC upgrade, any installed Haskell > packages will still be installed, even though the new GHC can't see or > use them. That's exactly the same situation as with Gentoo. We provide a ghc-updater program that re-installs all the existing libs for the new ghc. Gentoo also only provides libs for ghc. Duncan From duncan.coutts at worc.ox.ac.uk Thu Sep 4 05:22:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 4 05:18:54 2008 Subject: [Haskell-cafe] Haskell and i18n (aka gettext) support In-Reply-To: <87k5dsmrz8.fsf@gaura-nitai.no-ip.org> References: <87k5dsmrz8.fsf@gaura-nitai.no-ip.org> Message-ID: <1220520124.24846.515.camel@localhost> On Thu, 2008-09-04 at 06:53 +0200, Gour wrote: > As potential 'solution the 'i18n' package was mentioned > (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/i18n) with > the remark that its API is not the most beautiful. Seems to me that this is a good use case for implicit parameters, rather than a reader monad. Duncan From ashley at semantic.org Thu Sep 4 06:23:18 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Sep 4 06:21:27 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> Message-ID: <48BFB716.4060401@semantic.org> Sittampalam, Ganesh wrote: > I talked to Don about this and you're right, that doesn't happen. > However > he also confirmed that it does load modules a second time if they are > in the main program as well as the plugin, and it would be difficult to > merge the static and dynamic versions of the module. Oh dear. To fix this, I suppose the RTS would have to be able to keep track of all static initialisers. But it shouldn't otherwise affect program optimisation. -- Ashley Yakeley From ganesh.sittampalam at credit-suisse.com Thu Sep 4 08:01:46 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Sep 4 08:00:23 2008 Subject: [Haskell-cafe] RE: [Haskell] Top Level <- In-Reply-To: <48BFB716.4060401@semantic.org> References: <534781822.20080826190130@gmail.com> <48BB0EC5.4080201@semantic.org> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > Sittampalam, Ganesh wrote: > > I talked to Don about this and you're right, that doesn't happen. > > However > > he also confirmed that it does load modules a second time if they are > > in the main program as well as the plugin, and it would be difficult > > to merge the static and dynamic versions of the module. > Oh dear. To fix this, I suppose the RTS would have to be able to > keep track of all static initialisers. But it shouldn't otherwise > affect program optimisation. What would the RTS actually do? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From catamorphism at gmail.com Thu Sep 4 11:19:40 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Sep 4 11:17:48 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <48BF562C.2020408@freegeek.org> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> Message-ID: <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> On 9/3/08, wren ng thornton wrote: > If you want the datatype to be strict in state and rec, then you should add > strictness annotations to those fields directly: > > data Query state rec = Query !state !rec The novice programmer scatters strictness annotations to and fro like dust in the wind. The average programmer understands that annotating a field's strictness injudiciously is like discarding the finger pointing at the moon when you might still need it to scratch yourself. The master programmer does not add strictness annotations, for she has not yet run the profiler. Cheers, TIm -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Science fiction is not predictive; it is descriptive." --Ursula K. Le Guin From briqueabraque at yahoo.com Thu Sep 4 11:54:34 2008 From: briqueabraque at yahoo.com (=?windows-1252?Q?Maur=ED=ADcio?=) Date: Thu Sep 4 11:52:53 2008 Subject: [Haskell-cafe] Categorical language Message-ID: Hi, I?ve been thinking about this and would like your opinion: what could be a ?categorical language?? Something like a language where categories and functors are first class; does that makes sense at all? (Sorry if this is insane, I'm a begginer in categories, I've read just the first chapter of Mac Lane's book.) Thanks, Maur?cio From dave at zednenem.com Thu Sep 4 12:09:33 2008 From: dave at zednenem.com (David Menendez) Date: Thu Sep 4 12:07:39 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <1220519979.24846.513.camel@localhost> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> Message-ID: <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> On Thu, Sep 4, 2008 at 5:19 AM, Duncan Coutts wrote: > On Wed, 2008-09-03 at 17:54 -0400, David Menendez wrote: >> In my experience thus far, MacPorts feels like a poor match for Cabal. >> As far as I can tell, you get at most one active installation of a >> given port, which means you can't use MacPorts to manage packages for >> multiple Haskell environments (GHC and Hugs, stable GHC and >> development GHC, etc.), and after a GHC upgrade, any installed Haskell >> packages will still be installed, even though the new GHC can't see or >> use them. > > That's exactly the same situation as with Gentoo. We provide a > ghc-updater program that re-installs all the existing libs for the new > ghc. Gentoo also only provides libs for ghc. That's more convenient than re-installing all the libs by hand. I guess that's good enough for non-developer use; someone who just wants to install a program doesn't need to have more than one version of GHC installed, for example. It pains me to see the assumption that Haskell = GHC built in to our distribution methods, though. RPM apparently handles this by having the library packages install themselves under new names that include the environment name and version. I assume Nix can handle multiple Haskell environments. Does anyone know whether arch linux and debian can handle multiple Haskell environments? -- Dave Menendez From igloo at earth.li Thu Sep 4 12:33:25 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 4 12:31:32 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> Message-ID: <20080904163325.GA6997@matrix.chaos.earth.li> On Thu, Sep 04, 2008 at 12:09:33PM -0400, David Menendez wrote: > > Does anyone know whether arch linux and debian can handle multiple > Haskell environments? Debian currently only handles one version of GHC (but package dependencies mean that you can't end up with libraries compiled for the wrong version installed). There wouldn't be any technical problems embedding the ghc version in the package names, and /usr/bin/ghc would work fine with the alternatives system. I don't think that having multiple versions in Debian itself is feasible, but you could certainly do it in another repository. (technically, it's one version of ghc 6.*, as the package names use "ghc6" rather than just "ghc"). Having libraries for other implementations is fine in Debian, although most of the libraries are ghc6-only at the moment, I believe. Thanks Ian From dons at galois.com Thu Sep 4 13:32:53 2008 From: dons at galois.com (Don Stewart) Date: Thu Sep 4 13:30:55 2008 Subject: [Haskell-cafe] [POPL logo design contest] Message-ID: <20080904173253.GA6644@scytale.galois.com> This sounds relevant to our interests... ----- Forwarded message from Swarat Chaudhuri ----- Date: Thu, 04 Sep 2008 09:13:55 -0400 From: Swarat Chaudhuri To: types-list@lists.seas.upenn.edu Subject: [TYPES] POPL logo design contest [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ] Dear POPL community members: We know that you are all holding your breath for POPL 2009; here's some diversion to take your mind off the wait. We are planning to select a logo for POPL---after all, if the Olympics can have one, why not us? Accordingly, we announce the first-ever Contest on POPL Logo Design and Implementation (not to be confused with the other, gentler PLDI). Participants should send submissions in jpg, gif or png formats to Swarat Chaudhuri (swarat at cse.psu.edu) by November 20, 2008. The submission should contain: 1) A logo that doesn't mention the year (e.g., 2010) of the conference. 2) Logos mentioning the years 2010, 2011, and 2012. The contest will be judged by: * Luca Cardelli (Microsoft Cambridge) * Benjamin Pierce (Penn) * Shriram Krishnamurthi (Brown) We do not currently need high-resolution images, but will request them from the winner(s). From 2010 on, the logo will appear on POPL's webpage---in addition to the winning logo, the POPL 2010 webpage will also link to any other logo the judges find noteworthy. The winner(s) and runners-up will be presented t-shirts and cookies during the PC Chair's presentation at POPL 2009. So here's to citius, altius, etc. Get your design juices flowing! Best, Swarat Chaudhuri (Penn State) Publicity chair POPL 2010-2012 ----- End forwarded message ----- From andrewcoppin at btinternet.com Thu Sep 4 13:37:51 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Sep 4 13:35:55 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> <48BED8B5.5060905@btinternet.com> Message-ID: <48C01CEF.5020705@btinternet.com> Brandon S. Allbery KF8NH wrote: > On 2008 Sep 3, at 14:34, Andrew Coppin wrote: >> The amusing (?) part is that the interpretter itself is essentially >> quite simple. I've implemented it several times before now. But what >> I'm trying to do it make it print out elaborately formatted execution >> traces so that a human user can observe how execution proceeds. This >> transforms an essentially simple algorithm into something quite >> nausiatingly complex, with many subtle bugs and issues. > > This seems odd to me: I would expect to wrap a WriterT around it, log > unformatted actions there, and dump it to a file at the end to be read > by an analyzer tool which can optionally reformat the log to be > human-readable. Well actually, the interpretter itself takes an expression and returns a large, complex data structure representing the reduction sequence. Then a second function takes the reduction sequence and transforms it into a target-neutral markup structure. Finally, one of several rendering backends transforms this into something displayable - text, HTML, LaTeX, whatever. There are no monads involved. Anywhere. Actually, that's not completely true. The interpretter takes a set of transformation rules as an argument, and attempts to apply each rule in sequence, and then recursively over all subexpressions. The logic for this makes extensive use of the Maybe monad. (I spent ages looking for a function Maybe x -> Maybe x -> Maybe x that would keep Just and throw away Nothing, rather than (>>=) which does the opposite. Eventually I discovered that this is actually mplus. It wasn't easy...) The basic interpretter is just one function, that does a little pattern matching. It's one module of a few dozen lines. But as soon as you want to *record* the transformations applied, suddenly everything gets very much more complicated. And when you start wanting to have many possibly rules to apply, and turning individual rules on and off, and applying rules only to certain parts of the expression... it all starts to get very complicated. I've spent about 3 hours this afternoon trying to get my renamer to work. I *had* a working renamer, but then I discovered that locally-unique names are insufficient. You must have _globally_ unique names. This is much harder; you cannot now rename each subexpression independently. You must put the whole algorithm into a state monad. The algorithm is maddeningly subtle to get right. It's still not working properly. It *almost* works, but not quite. I think I know how to fix it - we'll see tomorrow - but isn't it just typical that an "uninteresting" part of the program turns out to be harder than the interesting bits? My head hurts... From paul at cogito.org.uk Thu Sep 4 13:39:09 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Thu Sep 4 13:37:22 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809030537p183caa47i659a1c6b6ae968cd@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <141527000.20080903155845@gmail.com> <40a414c20809030537p183caa47i659a1c6b6ae968cd@mail.gmail.com> Message-ID: <48C01D3D.3010100@cogito.org.uk> minh thu wrote: > Do you suggest I use > > data Thing = Thing | None > > and IORef Thing instead of > > data Thing = Thing > > and Maybe (IORef Thing) ? > > I'm writing a data structure that can hold Things (and that can be mutated) or > nothing (there is a hole in the wrapping data). > > > I'd have thought you wanted "IORef (Maybe Thing)", which says that the pointer always exists, but may not point to anything. On the other hand "Maybe (IORef Thing)" says that the pointer may or may not exist. Paul. From andrewcoppin at btinternet.com Thu Sep 4 13:41:56 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Sep 4 13:40:00 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <2f9b2d30809031454y6274c2f4g4e2ef0d70e8990f7@mail.gmail.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> <48BED8B5.5060905@btinternet.com> <2f9b2d30809031454y6274c2f4g4e2ef0d70e8990f7@mail.gmail.com> Message-ID: <48C01DE4.3040106@btinternet.com> Ryan Ingram wrote: > It's pretty simple, I think. > > type ExpGen = ReaderT [String] Gen > > arbExp :: ExpGen Expression > -- exercise for the reader > > instance Arbitrary Expression where > arbitrary = runReaderT arbExp [] > coarbitrary = coarbExp > > coarbExp (Var s) = variant 0 . coarbitrary s > coarbExp (Apply a b) = variant 1 . coarbitrary a . coarbitrary b > coarbExp (Lambda s e) = variant 2 . coarbitrary s . coarbitrary e > > instance Arbitrary Char where > arbitrary = elements "abcdefghijklmnopqrstuvwxyz_" > coarbitrary = coarbitrary . fromEnum > o_O I love the way other people have wildly different ideas of "simple" than me. I'm staring at this and completely failing to comprehend it. (But then, anything with "co" in the name generally makes little sense to me...) Why on earth would you need a reader monad? Surely if you want to add bound variables and then later query what variables are bound, you'd want a state monad? Hmm, I'm completely lost here. From vanenkj at gmail.com Thu Sep 4 13:44:34 2008 From: vanenkj at gmail.com (John Van Enk) Date: Thu Sep 4 13:42:40 2008 Subject: [Haskell-cafe] Parsec 3 Description Message-ID: I'm looking for a document describing the differences between Parsec 3 and Parsec 2. My google-foo must be off because I can't seem to find one. Does any one know where to find that information? -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080904/83f453bf/attachment.htm From noteed at gmail.com Thu Sep 4 13:50:20 2008 From: noteed at gmail.com (minh thu) Date: Thu Sep 4 13:48:26 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <48C01D3D.3010100@cogito.org.uk> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <141527000.20080903155845@gmail.com> <40a414c20809030537p183caa47i659a1c6b6ae968cd@mail.gmail.com> <48C01D3D.3010100@cogito.org.uk> Message-ID: <40a414c20809041050i7dc5855cm2bde19f328076407@mail.gmail.com> 2008/9/4 Paul Johnson : > minh thu wrote: >> >> Do you suggest I use >> >> data Thing = Thing | None >> >> and IORef Thing instead of >> >> data Thing = Thing >> >> and Maybe (IORef Thing) ? >> >> I'm writing a data structure that can hold Things (and that can be >> mutated) or >> nothing (there is a hole in the wrapping data). >> >> >> > > I'd have thought you wanted "IORef (Maybe Thing)", which says that the > pointer always exists, but may not point to anything. On the other hand > "Maybe (IORef Thing)" says that the pointer may or may not exist. Yes, someone else said it too. But you saiy that regarding the pointer. If you look at the thing the pointer (if any) points at, what's the difference ? Either there is none : Nothing or IORef Nothing, or there is one : Just (IORef 5) or IORef (Just 5). The difference is you have to allocate a new IORef whenever you want to make the thing pointed at appear in the first case. I'm more concerned by the hole the user can create/fill than by emulating C null pointers. Anyway, as Lennart suggested, I will try with Data.Map or Data.IntMap. Thanks thu From jonathanccast at fastmail.fm Thu Sep 4 13:50:24 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Sep 4 13:52:52 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48C01DE4.3040106@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> <48BED8B5.5060905@btinternet.com> <2f9b2d30809031454y6274c2f4g4e2ef0d70e8990f7@mail.gmail.com> <48C01DE4.3040106@btinternet.com> Message-ID: <1220550624.12473.84.camel@jcchost> On Thu, 2008-09-04 at 18:41 +0100, Andrew Coppin wrote: > Ryan Ingram wrote: > > It's pretty simple, I think. > > > > type ExpGen = ReaderT [String] Gen > > > > arbExp :: ExpGen Expression > > -- exercise for the reader > > > > instance Arbitrary Expression where > > arbitrary = runReaderT arbExp [] > > coarbitrary = coarbExp > > > > coarbExp (Var s) = variant 0 . coarbitrary s > > coarbExp (Apply a b) = variant 1 . coarbitrary a . coarbitrary b > > coarbExp (Lambda s e) = variant 2 . coarbitrary s . coarbitrary e > > > > instance Arbitrary Char where > > arbitrary = elements "abcdefghijklmnopqrstuvwxyz_" > > coarbitrary = coarbitrary . fromEnum > > > > o_O > > I love the way other people have wildly different ideas of "simple" than > me. I'm staring at this and completely failing to comprehend it. (But > then, anything with "co" in the name generally makes little sense to > me...) Why on earth would you need a reader monad? Surely if you want to > add bound variables and then later query what variables are bound, you'd > want a state monad? Hmm, I'm completely lost here. Motto (off-the-cuff): State monads are for APIs with function names like `set'; reader monads are for APIs with function names like `with'. In this case, you definitely do not want to bring names into scope with bringNameIntoScope :: Name -> ExpGen () because then you'd just have to implement bringNameOutofScope :: Name -> ExpGen () and remember to call it after you've generated the body of the lambda, except that you have to check before bringing the name into scope whether it's already in scope and if so make sure it's still in scope afterwards. A simpler alternative is to pull out the entire scope, using get, save it off, modify the state, and then put it back later: withNameInScope :: Name -> ExpGen alpha -> ExpGen alpha withNameInScope name a = do scope <- get modify (name:) x <- a set scope return x But by adopting that API, you're suggesting the use of a reader monad to implement scoping, since withNameInScope would then be just withNameInScope name = local (name:) jcc http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad-Reader-Class.html#v%3Alocal From allbery at ece.cmu.edu Thu Sep 4 14:27:24 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Sep 4 14:25:33 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48C01DE4.3040106@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> <48BED8B5.5060905@btinternet.com> <2f9b2d30809031454y6274c2f4g4e2ef0d70e8990f7@mail.gmail.com> <48C01DE4.3040106@btinternet.com> Message-ID: <459190C1-BC00-4478-9F72-B7B90B7C04BA@ece.cmu.edu> On Sep 4, 2008, at 13:41 , Andrew Coppin wrote: > Ryan Ingram wrote: >> It's pretty simple, I think. >> >> type ExpGen = ReaderT [String] Gen >> >> arbExp :: ExpGen Expression >> -- exercise for the reader >> >> instance Arbitrary Expression where >> arbitrary = runReaderT arbExp [] >> coarbitrary = coarbExp >> >> coarbExp (Var s) = variant 0 . coarbitrary s >> coarbExp (Apply a b) = variant 1 . coarbitrary a . coarbitrary b >> coarbExp (Lambda s e) = variant 2 . coarbitrary s . coarbitrary e >> >> instance Arbitrary Char where >> arbitrary = elements "abcdefghijklmnopqrstuvwxyz_" >> coarbitrary = coarbitrary . fromEnum >> > > o_O > > I love the way other people have wildly different ideas of "simple" > than me. I'm staring at this and completely failing to comprehend > it. (But then, anything with "co" in the name generally makes little > sense to me...) Why on earth would you need a reader monad? Surely > if you want to add bound variables and then later query what > variables are bound, you'd want a state monad? Hmm, I'm completely > lost here. Reader, in this case, is a State monad with the addition of scopes: to create a new nested scope r' given a scope r, "let r' = local r". The [String] is a list of variable names, if this is doing what I think it is. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From flippa at flippac.org Thu Sep 4 14:41:49 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Thu Sep 4 14:42:12 2008 Subject: [Haskell-cafe] Parsec 3 Description In-Reply-To: References: Message-ID: On Thu, 4 Sep 2008, John Van Enk wrote: > I'm looking for a document describing the differences between Parsec 3 and > Parsec 2. My google-foo must be off because I can't seem to find one. Does > any one know where to find that information? > Unfortunately there isn't currently a good one - in fact, it raises an issue with HackageDB, which is that there isn't a good way to handle both stable and working releases. The biggest differences are the addition of streams and rewriting as a monad transformer, but I imagine you need an incompatibility list? -- flippa@flippac.org "I think you mean Philippa. I believe Phillipa is the one from an alternate universe, who has a beard and programs in BASIC, using only gotos for control flow." -- Anton van Straaten on Lambda the Ultimate From pedagand at gmail.com Thu Sep 4 14:46:47 2008 From: pedagand at gmail.com (Pierre-Evariste Dagand) Date: Thu Sep 4 14:44:54 2008 Subject: [Haskell-cafe] Categorical language In-Reply-To: References: Message-ID: <6cb897b30809041146j1cc7f2feg964ee51c2a503d5e@mail.gmail.com> > what could be a "categorical language"? Something we would call Charity, for example :-) http://en.wikipedia.org/wiki/Charity_(programming_language) http://pll.cpsc.ucalgary.ca/charity1/www/home.html Also, there has been/is some work on Squiggol and the Algebra of Programming that relies on categories : http://en.wikipedia.org/wiki/Bird-Meertens_Formalism http://lambda-the-ultimate.org/node/1117 > does that makes sense at all? I wish it does, these stuffs are quite exciting. However, most of these projects are more than 10 years old. But maybe I'm missing the latest development of this field. Regards, -- Pierre-Evariste DAGAND http://perso.eleves.bretagne.ens-cachan.fr/~dagand/ From vanenkj at gmail.com Thu Sep 4 14:49:23 2008 From: vanenkj at gmail.com (John Van Enk) Date: Thu Sep 4 14:47:30 2008 Subject: [Haskell-cafe] Parsec 3 Description In-Reply-To: References: Message-ID: While an incompatibility list would be good, a descriptive change-log with new feature examples would be nice. On Thu, Sep 4, 2008 at 2:41 PM, Philippa Cowderoy wrote: > On Thu, 4 Sep 2008, John Van Enk wrote: > > > I'm looking for a document describing the differences between Parsec 3 > and > > Parsec 2. My google-foo must be off because I can't seem to find one. > Does > > any one know where to find that information? > > > > Unfortunately there isn't currently a good one - in fact, it raises an > issue with HackageDB, which is that there isn't a good way to handle both > stable and working releases. > > The biggest differences are the addition of streams and rewriting as a > monad transformer, but I imagine you need an incompatibility list? > > -- > flippa@flippac.org > > "I think you mean Philippa. I believe Phillipa is the one from an > alternate universe, who has a beard and programs in BASIC, using only > gotos for control flow." -- Anton van Straaten on Lambda the Ultimate > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080904/fbecda45/attachment.htm From william.wood3 at comcast.net Thu Sep 4 15:36:27 2008 From: william.wood3 at comcast.net (Bill) Date: Thu Sep 4 15:42:36 2008 Subject: [Haskell-cafe] Categorical language In-Reply-To: <6cb897b30809041146j1cc7f2feg964ee51c2a503d5e@mail.gmail.com> References: <6cb897b30809041146j1cc7f2feg964ee51c2a503d5e@mail.gmail.com> Message-ID: <1220556987.5334.6.camel@localhost> On Thu, 2008-09-04 at 20:46 +0200, Pierre-Evariste Dagand wrote: > > what could be a "categorical language"? > > Something we would call Charity, for example :-) > > http://en.wikipedia.org/wiki/Charity_(programming_language) > http://pll.cpsc.ucalgary.ca/charity1/www/home.html > > Also, there has been/is some work on Squiggol and the Algebra of > Programming that relies on categories : > > http://en.wikipedia.org/wiki/Bird-Meertens_Formalism > http://lambda-the-ultimate.org/node/1117 > > > does that makes sense at all? > > I wish it does, these stuffs are quite exciting. However, most of > these projects are more than 10 years old. But maybe I'm missing the > latest development of this field. I've heard similar questions among the aldor community. IIUC aldor is a second cut at a mathematical programming language. Its original use was to provide the underpinning to the Axiom family of CAS. They are exploring the use of aldor outside of CAS support, however. The language is strongly typed, and the "domains" include things like Ring and Field. From ryani.spam at gmail.com Thu Sep 4 15:57:25 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Sep 4 15:55:33 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48C01DE4.3040106@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <48BC38A4.9030407@btinternet.com> <48BC837D.8020706@daimi.au.dk> <672EB9A1-7715-4D53-B0AB-C3B4310D0BBA@ece.cmu.edu> <48BED8B5.5060905@btinternet.com> <2f9b2d30809031454y6274c2f4g4e2ef0d70e8990f7@mail.gmail.com> <48C01DE4.3040106@btinternet.com> Message-ID: <2f9b2d30809041257w92127e0ka0f42418cf4384c5@mail.gmail.com> On Thu, Sep 4, 2008 at 10:41 AM, Andrew Coppin wrote: > I love the way other people have wildly different ideas of "simple" than me. > I'm staring at this and completely failing to comprehend it. (But then, > anything with "co" in the name generally makes little sense to me...) Why on > earth would you need a reader monad? Surely if you want to add bound > variables and then later query what variables are bound, you'd want a state > monad? Hmm, I'm completely lost here. Other people have already covered the reader vs. state issue; but to sum up, this is a state monad, but the state can only be mutated in sub-expressions, not in future expressions. In my quick implementation, the branch of arbExp that makes a lambda-expression looks something like this: > do > -- get a new variable name > v <- lift arbitrary > -- construct a new expression that may use v as a variable > e <- local (v:) arbExp > -- return the new expression > return (Lambda v e) As to all the crazy "co" stuff, it's just an implementation detail for QuickCheck. It took me a while figure out what was actually going on, but the implementation is basically just boilerplate at this point. A simpler implementation is > coarbitrary _ = id A full explanation: > coarbitrary :: Arbitrary a => a -> Gen b -> Gen b Gen is a simple state monad that holds the random number generator state and some additional QuickCheck data. What "coarbitrary" is supposed to do is to modify the state of the random number generator based on the input data. This allows quickCheck to create automatic arbitrary instances for functions that output your type a; that is, if you had a property > prop_compose_assoc h g f x = (f . (g . h)) x == ((f . g) . h) x ghci> quickCheck (prop_compose_assoc :: (Int -> Expression) -> (Expression -> Expression) -> (Expression -> Int) -> Int -> Bool) ... OK, passed 100 tests. In order to do this, it needs to be able to generate a function of type (Expression -> Expression), but at the time that function is constructed you have just the random number generator state at that point. In order to do this, it creates a function that uses coarbitrary on the input Expression to modify that fixed random number generator state to get a new state which is then used to generate the output expression. Using the "simple" implementation of coarbitrary above, QuickCheck will only generate constant functions; that is, functions which generate the same (random) expression each time they are called. The internals of doing so are kind of ugly, but thankfully you are free to ignore that and build your coarbitrary out of a couple of simple building blocks: > variant :: Int -> Gen b -> Gen b > coarbitrary :: Arbitrary a => a -> Gen b -> Gen b But wait, aren't you supposed to be defining coarbitrary? Well, as long as you use coarbitrary on smaller data structures, you're fine. The strategy for finite data structures is really simple: - Each constructor uses "variant" with a number representing that constructor. - Each data inside a constructor uses coarbitrary recursively. The reason I included the 'coarbitrary' code in my post is that it is the more complicated part of the instance to understand and write before you "get it"; understanding how to write "arbitrary" is the important part. -- ryan > Ryan Ingram wrote: >> >> It's pretty simple, I think. >> >> type ExpGen = ReaderT [String] Gen >> >> arbExp :: ExpGen Expression >> -- exercise for the reader >> >> instance Arbitrary Expression where >> arbitrary = runReaderT arbExp [] >> coarbitrary = coarbExp >> >> coarbExp (Var s) = variant 0 . coarbitrary s >> coarbExp (Apply a b) = variant 1 . coarbitrary a . coarbitrary b >> coarbExp (Lambda s e) = variant 2 . coarbitrary s . coarbitrary e >> >> instance Arbitrary Char where >> arbitrary = elements "abcdefghijklmnopqrstuvwxyz_" >> coarbitrary = coarbitrary . fromEnum >> From duncan.coutts at worc.ox.ac.uk Thu Sep 4 16:07:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 4 16:04:01 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> Message-ID: <1220558832.24846.550.camel@localhost> On Thu, 2008-09-04 at 12:09 -0400, David Menendez wrote: > On Thu, Sep 4, 2008 at 5:19 AM, Duncan Coutts > wrote: > > That's exactly the same situation as with Gentoo. We provide a > > ghc-updater program that re-installs all the existing libs for the new > > ghc. Gentoo also only provides libs for ghc. > > That's more convenient than re-installing all the libs by hand. I > guess that's good enough for non-developer use; someone who just wants > to install a program doesn't need to have more than one version of GHC > installed, for example. It pains me to see the assumption that Haskell > = GHC built in to our distribution methods, though. Yeah, I know. It's really a limitation of systems like Gentoo. Gentoo's position is that you should not encode things like this into the package name and provides a 'slotting' mechanism to allow multiple versions, however it's not quite expressive enough to slot on the haskell implementation and still get all the lib deps right. > RPM apparently handles this by having the library packages install > themselves under new names that include the environment name and > version. I assume Nix can handle multiple Haskell environments. Right. And yes, Nix can do everything because it's jolly cunning and takes the functional/persistent approach. > Does anyone know whether arch linux and debian can handle multiple > Haskell environments? Debian does, again by encoding the haskell implementation name into the package name. I think arch only provides libraries for ghc. Ducan From dons at galois.com Thu Sep 4 16:14:29 2008 From: dons at galois.com (Don Stewart) Date: Thu Sep 4 16:12:31 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <1220558832.24846.550.camel@localhost> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> <1220558832.24846.550.camel@localhost> Message-ID: <20080904201429.GC7216@scytale.galois.com> duncan.coutts: > On Thu, 2008-09-04 at 12:09 -0400, David Menendez wrote: > > On Thu, Sep 4, 2008 at 5:19 AM, Duncan Coutts > > wrote: > > > That's exactly the same situation as with Gentoo. We provide a > > > ghc-updater program that re-installs all the existing libs for the new > > > ghc. Gentoo also only provides libs for ghc. > > > > That's more convenient than re-installing all the libs by hand. I > > guess that's good enough for non-developer use; someone who just wants > > to install a program doesn't need to have more than one version of GHC > > installed, for example. It pains me to see the assumption that Haskell > > = GHC built in to our distribution methods, though. > > Yeah, I know. It's really a limitation of systems like Gentoo. Gentoo's > position is that you should not encode things like this into the package > name and provides a 'slotting' mechanism to allow multiple versions, > however it's not quite expressive enough to slot on the haskell > implementation and still get all the lib deps right. > > > RPM apparently handles this by having the library packages install > > themselves under new names that include the environment name and > > version. I assume Nix can handle multiple Haskell environments. > > Right. And yes, Nix can do everything because it's jolly cunning and > takes the functional/persistent approach. > > > Does anyone know whether arch linux and debian can handle multiple > > Haskell environments? > > Debian does, again by encoding the haskell implementation name into the > package name. I think arch only provides libraries for ghc. > That's right, on Arch we just go for what people actually need, i.e.: 1) 1 compiler, GHC 2) GHC comes with the core+extra set, so they're implicitly available 3) all other libs are "haskell-(map toLower packagename)" The complication to support multiple implementations et al isn't done by any other language group (i.e. libs aren't bundled for multiple python impls, or different C compilers), so I don't see why we should waste time on that either. Pragmatic, I know. -- Don From duncan.coutts at worc.ox.ac.uk Thu Sep 4 16:38:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 4 16:35:31 2008 Subject: [Haskell-cafe] Parsec 3 Description In-Reply-To: References: Message-ID: <1220560722.24846.582.camel@localhost> On Thu, 2008-09-04 at 19:41 +0100, Philippa Cowderoy wrote: > On Thu, 4 Sep 2008, John Van Enk wrote: > > > I'm looking for a document describing the differences between Parsec 3 and > > Parsec 2. My google-foo must be off because I can't seem to find one. Does > > any one know where to find that information? > > > > Unfortunately there isn't currently a good one - in fact, it raises an > issue with HackageDB, which is that there isn't a good way to handle both > stable and working releases. The simple solution to this (which I may get round to implementing) is that for each package on hackage we have a suggested constraint (that the maintainer could set). For example for parsec we might use '< 3'. Then tools like cabal-install or distro package converters could take this into account when someone asks to install that package. This would not prevent packages explicitly requiring the later version as it'd only come into play when there are no other constraints and where the search algorithms just pick the highest version. Duncan From acm at muc.de Thu Sep 4 17:14:35 2008 From: acm at muc.de (Alan Mackenzie) Date: Thu Sep 4 17:08:13 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". Message-ID: <20080904211435.GA4119@muc.de> Hi, Haskell! I've downloaded the ghc-6.8.3-i386-unknown-linux.tar.bz2 tarball, which I expected to work on my GNU/Linux box (1.2 GHz Athlon, Debian Sarge). I'm new at this game, though I'm thoroughly experienced with (and bear deep battle scars from) GNU software in general. ./configure fails with "checking for path to top of build tree... configure: error: cannot determine current directory". This has been reported before in this list, but I don't think anybody ever explained the fault. Further delving finds that the following statement in the configure script triggers it: hardtop=`utils/pwd/pwd forwardslash` . utils/pwd/pwd, no matter how I call it, always crashes with "Floating point exception". Surely real numbers aren't involved in determining a configuration - probably some floating point library or other is missing from my system. What is utils/pwd/pwd? What's its purpose? It's 460kB large (compared with 14kb for /bin/pwd). Is it a haskell implementation of Unix's pwd, primarily intented for non-unixy OSs? configure is supposed to ascertain my machine's config, so it's particularly disappointing that it crashes because my config isn't what it expects. Should I report this as a bug? ######################################################################### Anyhow, I hacked the configure script by replacing the above line by a hard-coded value, thusly: hardtop=/home/acm/haskell/ghc-6.8.3 , and the configure script finished. ;-) So I did "make install", and the turgid messages rolled up my screen until it crashed, the last few lines being: nstall/lib/ghc-6.8.3"' -DPKG_DATADIR='"/home/acm/haskell/ghc-install/share/ghc-6.8.3"' package.conf.in \ | grep -v '^#pragma GCC' \ | sed -e 's/""//g' -e 's/:[ ]*,/: /g' \ | /home/acm/haskell/ghc-6.8.3/utils/ghc-pkg/ghc-pkg.bin --global-conf /home/acm/haskell/ghc-install/lib/ghc-6.8.3/package.conf update - --force make[1]: *** [install] Error 136 make[1]: Leaving directory `/home/acm/haskell/ghc-6.8.3/rts' make: *** [install] Error 2 Ah yes! Error 136. ;-) Don't we just love GNU bread and butter software? It's not documented on the install man page either - or the info page. Neither is Error 8. Hey, you've all been through this too: enthusiasm -> 0 as t -> infinity. :-( ######################################################################### So, I thought, who needs to install? It's a binary package, so somewhere there's going to be a top-level callable program, probably called something like "ghc". Hey, yes, compile/Stage3/ghc-6.8.3. Guess what: "Floating point exception". :-( I hate binary packages - I utterly loathe them. They never work. At least they never work for me. Or the distro package manager stuffs your cron config with resource hoggers you really don't want, and forgets to ask you first. I suppose they might work if your OS has been installed or updated within the last few months; otherwise, forget it. Source distributions are so much faster and easier to install because the cranial clutter you have to cope with is that much less. Trouble is, to build haskell from source, you need a working haskell to build it with. Presumably, sometime in the recent past (as measured on archaeological time scales), ghc was bootstrapped from C (or some other lowest common denomiator language). Is this route still available? Some proto-proto haskell written in C, sufficiently powerful to build a proto-haskell, sufficiently powerful to build the compiler? ######################################################################### I'd really love to play with haskell. But the time I've wasted so far, trying to get it working, is almost at the stage where I just can't be bothered any more. I've been here before, and I can see that I've got 1 - 3 days x 8 hours of grinding drudgery before I finally get ghc-6.8.3 working. I suppose that's just the way GNU systems are. If anybody could give me some tips as to getting a decent haskell running on my system in a reasonable, predictable amount of time, in a way which doesn't involve diagnosing and fixing problems, I'd be very grateful indeed. Thanks! -- Alan Mackenzie (Nuremberg, Germany). From waldmann at imn.htwk-leipzig.de Thu Sep 4 17:20:35 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Sep 4 17:18:41 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". In-Reply-To: <20080904211435.GA4119@muc.de> References: <20080904211435.GA4119@muc.de> Message-ID: <48C05123.7050706@imn.htwk-leipzig.de> Hi, Alan - > ./configure fails with "checking for path to top of build tree... > configure: error: cannot determine current directory". Yeah, I got the exact same error yesterday when trying to install a ghc-6.8.3 binary dist on some older machine. Well, since I had 6.8.2 working there, I just used it to compile 6.8.3 from sources, which worked without any problems. I guess the 6.8.3 binary does not work because it expects a newer version of libc or whatever. I can provide the binaries I built if you need them. Best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080904/bc70ff85/signature.bin From dons at galois.com Thu Sep 4 17:24:20 2008 From: dons at galois.com (Don Stewart) Date: Thu Sep 4 17:22:22 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". In-Reply-To: <20080904211435.GA4119@muc.de> References: <20080904211435.GA4119@muc.de> Message-ID: <20080904212420.GI7216@scytale.galois.com> acm: > Hi, Haskell! > > I've downloaded the ghc-6.8.3-i386-unknown-linux.tar.bz2 tarball, which > I expected to work on my GNU/Linux box (1.2 GHz Athlon, Debian Sarge). Was there a problem installing GHC from the Debian package system with apt? -- Don From igloo at earth.li Thu Sep 4 17:26:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 4 17:24:59 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". In-Reply-To: <48C05123.7050706@imn.htwk-leipzig.de> References: <20080904211435.GA4119@muc.de> <48C05123.7050706@imn.htwk-leipzig.de> Message-ID: <20080904212641.GA3272@matrix.chaos.earth.li> On Thu, Sep 04, 2008 at 11:20:35PM +0200, Johannes Waldmann wrote: > > >./configure fails with "checking for path to top of build tree... > >configure: error: cannot determine current directory". > > I guess the 6.8.3 binary does not work because it expects a newer > version of libc or whatever. That's right. Thanks Ian From waldmann at imn.htwk-leipzig.de Thu Sep 4 17:27:45 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Sep 4 17:25:53 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". In-Reply-To: <20080904212420.GI7216@scytale.galois.com> References: <20080904211435.GA4119@muc.de> <20080904212420.GI7216@scytale.galois.com> Message-ID: <48C052D1.7010902@imn.htwk-leipzig.de> > Was there a problem installing GHC from the Debian package system with apt? He said Sarge. I guess the current ghc packages are for Etch only? - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080904/061e2feb/signature.bin From jgbailey at gmail.com Thu Sep 4 17:28:21 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Thu Sep 4 17:26:26 2008 Subject: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption? Message-ID: I am thinking of writing a simple library in Haskell which would be useful in a number of different scenarios, and not always with programs written in Haskell. That makes me think the library should be C-compatible and able to link with C programs. Reading over chapter 9 of the GHC manual ("Foreign function interface"), it seems simple to do. However, what are the consequences of such an implementation? Would any program using my library need to link the entire GHC runtime? The library will not expose any higher-order functions or other business. It would be straightforward but tedious to write in C, which is why I'd rather use Haskell. Thanks in advance for any thoughts. Justin From flippa at flippac.org Thu Sep 4 17:29:40 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Thu Sep 4 17:27:40 2008 Subject: [Haskell-cafe] Parsec 3 Description In-Reply-To: <1220560722.24846.582.camel@localhost> References: <1220560722.24846.582.camel@localhost> Message-ID: <1220563780.13526.5.camel@flippa-eee> On Thu, 2008-09-04 at 20:38 +0000, Duncan Coutts wrote: > On Thu, 2008-09-04 at 19:41 +0100, Philippa Cowderoy wrote: > > On Thu, 4 Sep 2008, John Van Enk wrote: > > > > > I'm looking for a document describing the differences between Parsec 3 and > > > Parsec 2. My google-foo must be off because I can't seem to find one. Does > > > any one know where to find that information? > > > > > > > Unfortunately there isn't currently a good one - in fact, it raises an > > issue with HackageDB, which is that there isn't a good way to handle both > > stable and working releases. > > The simple solution to this (which I may get round to implementing) is > that for each package on hackage we have a suggested constraint (that > the maintainer could set). For example for parsec we might use '< 3'. > Then tools like cabal-install or distro package converters could take > this into account when someone asks to install that package. This would > not prevent packages explicitly requiring the later version as it'd only > come into play when there are no other constraints and where the search > algorithms just pick the highest version. > Cool. I imagine you've already got a reasonably capable constraint system that'll handle long-running stable/unstable schemes along the lines of GHC's? Hmm, that also suggests package aliases ala GHC-stable, GHC-unstable might be useful too, though. The current situation with Parsec is both odd and easy. -- Philippa Cowderoy From dons at galois.com Thu Sep 4 17:32:42 2008 From: dons at galois.com (Don Stewart) Date: Thu Sep 4 17:30:43 2008 Subject: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption? In-Reply-To: References: Message-ID: <20080904213242.GK7216@scytale.galois.com> jgbailey: > I am thinking of writing a simple library in Haskell which would be > useful in a number of different scenarios, and not always with > programs written in Haskell. That makes me think the library should be > C-compatible and able to link with C programs. Reading over chapter 9 > of the GHC manual ("Foreign function interface"), it seems simple to > do. > > However, what are the consequences of such an implementation? Would > any program using my library need to link the entire GHC runtime? The Yes. > library will not expose any higher-order functions or other business. You still need the GHC runtime support for the Haskell code (GC, scheduler et al). > It would be straightforward but tedious to write in C, which is why > I'd rather use Haskell. Easy enough to do, http://haskell.org/haskellwiki/Calling_Haskell_from_C Would be great to hear how you find the experience. -- Don From acm at muc.de Thu Sep 4 17:57:21 2008 From: acm at muc.de (Alan Mackenzie) Date: Thu Sep 4 17:50:57 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". In-Reply-To: <48C05123.7050706@imn.htwk-leipzig.de> References: <20080904211435.GA4119@muc.de> <48C05123.7050706@imn.htwk-leipzig.de> Message-ID: <20080904215721.GE1108@muc.de> HI THERE, JOHANNES, what a surprise, how are you doing? Remember teaching me the 7-ring 1-count? Might've been at Erlangen, possibly Augsburg, even Berlin, but it was quite a while ago. :-) On Thu, Sep 04, 2008 at 11:20:35PM +0200, Johannes Waldmann wrote: > Hi, Alan - > >./configure fails with "checking for path to top of build tree... > >configure: error: cannot determine current directory". > Yeah, I got the exact same error yesterday when trying to install > a ghc-6.8.3 binary dist on some older machine. Ah, so it's not just me. > Well, since I had 6.8.2 working there, I just used it to compile 6.8.3 > from sources, which worked without any problems. > I guess the 6.8.3 binary does not work because it expects a newer > version of libc or whatever. I can provide the binaries I built if you > need them. Hey, thanks, yes please! Whether by email, or you giving me an ftp address, whatever is most convenient. That would be most appreciated. > Best regards, J.W. -- Alan Mackenzie (Nuremberg, Germany). From jgbailey at gmail.com Thu Sep 4 18:00:58 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Thu Sep 4 17:59:04 2008 Subject: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption? In-Reply-To: <1220565162.13526.7.camel@flippa-eee> References: <1220565162.13526.7.camel@flippa-eee> Message-ID: On Thu, Sep 4, 2008 at 2:52 PM, Philippa Cowderoy wrote: > Would writing Haskell to generate the C via Language.C be an option? > Effectively you'd be using Haskell as a typeful macro system. Interesting idea, and I've done similar things with haskelldb (generating SQL queries). Looking at the package, I think would be pretty painful though. It seems I'd have to build the AST by hand, and it doesn't seem to incorporate any type information in the AST items. In haskelldb, every expression carries its type around in a phantom type, which protects you from trying to compare a bool and a string, for intstance. I don't see anything similar in Language.C. I may be mistaken though! Justin From allbery at ece.cmu.edu Thu Sep 4 18:03:48 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Sep 4 18:01:58 2008 Subject: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption? In-Reply-To: References: <1220565162.13526.7.camel@flippa-eee> Message-ID: <0395DDAF-43F6-4647-BF34-5784AADF743D@ece.cmu.edu> On 2008 Sep 4, at 18:00, Justin Bailey wrote: > On Thu, Sep 4, 2008 at 2:52 PM, Philippa Cowderoy > wrote: >> Would writing Haskell to generate the C via Language.C be an option? >> Effectively you'd be using Haskell as a typeful macro system. > > Interesting idea, and I've done similar things with haskelldb > (generating SQL queries). Looking at the package, I think would be > pretty painful though. It seems I'd have to build the AST by hand, and > it doesn't seem to incorporate any type information in the AST items. Compared to Haskell (or HaskellDB), C barely has type information and is very non-strict about what types are compatible with what types. (And I'd wonder how Language.C deals with typedef, which is to C parsing what fixity declarations are to Haskell parsing [which is to say, painful].) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From acm at muc.de Thu Sep 4 18:22:46 2008 From: acm at muc.de (Alan Mackenzie) Date: Thu Sep 4 18:16:22 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". In-Reply-To: <20080904212420.GI7216@scytale.galois.com> References: <20080904211435.GA4119@muc.de> <20080904212420.GI7216@scytale.galois.com> Message-ID: <20080904222246.GF1108@muc.de> Hi, Don! On Thu, Sep 04, 2008 at 02:24:20PM -0700, Don Stewart wrote: > acm: > > Hi, Haskell! > > I've downloaded the ghc-6.8.3-i386-unknown-linux.tar.bz2 tarball, > > which I expected to work on my GNU/Linux box (1.2 GHz Athlon, Debian > > Sarge). > Was there a problem installing GHC from the Debian package system with > apt? Yes, my apt setup is broken. Because of a (now fixed) configuration error I made, aptitude (a frontend to apt) has decided it needs to delete ~400 packages from my system, some of them vital. It's an "intelligent", "helpful" system, and maintaining consistency between packages is of utmost importance to it, more important, by far, than leaving my system in a working state. I haven't found a convenient, safe, way of resetting this "deletion cache" (which has been hanging around for ~1 year). Sadly its only "go button" is "do everything pending", so I've effectively blocked myself from using it. Sorting the mess out, or even discovering whether I could safely use apt directly, is just too much drudgery; I'll be installing a new system sometime soon anyway. I hate package managers almost as much as binary packages. There are quite a lot of things I don't hate, though. ;-) That's kind of drifting off topic, though. > -- Don -- Alan Mackenzie (Nuremberg, Germany). From wnoise at ofb.net Thu Sep 4 18:28:26 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Sep 4 18:26:46 2008 Subject: [Haskell-cafe] Re: Hackage -> MacPorts? References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> <1220558832.24846.550.camel@localhost> <20080904201429.GC7216@scytale.galois.com> Message-ID: On 2008-09-04, Don Stewart wrote: > The complication to support multiple implementations et al isn't done by > any other language group (i.e. libs aren't bundled for multiple python > impls, or different C compilers), so I don't see why we should waste > time on that either. Pragmatic, I know. It's indeed not done for C libraries, because that, unlike Haskell, has a stable ABI, even between compilers. Python is in a fairly similar situation, with on-demand compilation and caching being cheap enough that distributing source is good enough. This of course requires a small bit of care in making the source work with multiple revisions of the standard C implementation. -- Aaron Denney -><- From newsham at lava.net Thu Sep 4 19:51:02 2008 From: newsham at lava.net (Tim Newsham) Date: Thu Sep 4 19:49:17 2008 Subject: [Haskell-cafe] Functional references Message-ID: I'm playing with functional references and looking for some feedback on a small FRec library I put together: http://www.thenewsh.com/~newsham/FRef.hs Novel (I think) is that the library is applied to some data accesses that are not normally covered by functional references -- ie. extracting words or replacing words in a string or values in an association list. I'm hoping it will provides a useful framework for editing complex values such as data embedded in Base64 cookies in an HTTP header. Tim Newsham http://www.thenewsh.com/~newsham/ From dave at zednenem.com Thu Sep 4 20:08:49 2008 From: dave at zednenem.com (David Menendez) Date: Thu Sep 4 20:06:54 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <20080904201429.GC7216@scytale.galois.com> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> <1220558832.24846.550.camel@localhost> <20080904201429.GC7216@scytale.galois.com> Message-ID: <49a77b7a0809041708p700d874fi13ab922cf3956a06@mail.gmail.com> On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart wrote: > That's right, on Arch we just go for what people actually need, i.e.: > > 1) 1 compiler, GHC > 2) GHC comes with the core+extra set, so they're implicitly available > 3) all other libs are "haskell-(map toLower packagename)" > > The complication to support multiple implementations et al isn't done by > any other language group (i.e. libs aren't bundled for multiple python > impls, or different C compilers), so I don't see why we should waste > time on that either. Pragmatic, I know. So Haskell developers still have to manage everything themselves. That's probably reasonable. What happens when you upgrade GHC? The problem MacPorts has is that the libraries are still listed as installed, even though they are no longer registered or useable. -- Dave Menendez From dons at galois.com Thu Sep 4 20:29:17 2008 From: dons at galois.com (Don Stewart) Date: Thu Sep 4 20:27:21 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <49a77b7a0809041708p700d874fi13ab922cf3956a06@mail.gmail.com> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> <1220558832.24846.550.camel@localhost> <20080904201429.GC7216@scytale.galois.com> <49a77b7a0809041708p700d874fi13ab922cf3956a06@mail.gmail.com> Message-ID: <20080905002917.GQ7216@scytale.galois.com> dave: > On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart wrote: > > That's right, on Arch we just go for what people actually need, i.e.: > > > > 1) 1 compiler, GHC > > 2) GHC comes with the core+extra set, so they're implicitly available > > 3) all other libs are "haskell-(map toLower packagename)" > > > > The complication to support multiple implementations et al isn't done by > > any other language group (i.e. libs aren't bundled for multiple python > > impls, or different C compilers), so I don't see why we should waste > > time on that either. Pragmatic, I know. > > So Haskell developers still have to manage everything themselves. > That's probably reasonable. Well, if you develop with GHC, then you can just use the native packages. > What happens when you upgrade GHC? The problem MacPorts has is that > the libraries are still listed as installed, even though they are no > longer registered or useable. We unregister the old packages, and you need to reinstall them. -- Don From duncan.coutts at worc.ox.ac.uk Thu Sep 4 20:55:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 4 20:52:28 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <49a77b7a0809041708p700d874fi13ab922cf3956a06@mail.gmail.com> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> <1220558832.24846.550.camel@localhost> <20080904201429.GC7216@scytale.galois.com> <49a77b7a0809041708p700d874fi13ab922cf3956a06@mail.gmail.com> Message-ID: <1220576132.6076.34.camel@localhost> On Thu, 2008-09-04 at 20:08 -0400, David Menendez wrote: > On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart wrote: > > That's right, on Arch we just go for what people actually need, i.e.: > > > > 1) 1 compiler, GHC > > 2) GHC comes with the core+extra set, so they're implicitly available > > 3) all other libs are "haskell-(map toLower packagename)" > > > > The complication to support multiple implementations et al isn't done by > > any other language group (i.e. libs aren't bundled for multiple python > > impls, or different C compilers), so I don't see why we should waste > > time on that either. Pragmatic, I know. > > So Haskell developers still have to manage everything themselves. > That's probably reasonable. > > What happens when you upgrade GHC? The problem MacPorts has is that > the libraries are still listed as installed, even though they are no > longer registered or useable. Gentoo provides a ghc-updater program that re-installs all the registered libraries for the new ghc. It's based off of a similar system used in Gentoo for managing major version upgrades in Python so perhaps MacPorts has something similar you could adapt. Basically it searches through the installed haskell packages to find the ones registered with the older compiler and then works out what order to re-install them in and then does it. So it's not fully automatic as users have to run this program manually after upgrading ghc, but it's not too painful. Duncan From mad.one at gmail.com Thu Sep 4 21:04:25 2008 From: mad.one at gmail.com (Austin Seipp) Date: Thu Sep 4 21:02:33 2008 Subject: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption? In-Reply-To: References: <1220565162.13526.7.camel@flippa-eee> Message-ID: <1220576196-sup-4259@existential.local> Excerpts from Justin Bailey's message of Thu Sep 04 17:00:58 -0500 2008: > Looking at the package, I think would be pretty painful though. It > seems I'd have to build the AST by hand, The AST Language.C defines for C is actually fairly regular once you wrap your head around it - I got it to generate working programs that I could compile in approximately an hour after looking through nothing but the documentation, essentially. The AST is very 'raw' though: I found that defining some simple functions for things like just creating a global variable, creating declarations and the like cut down on overall AST size tremendously (although hints of the AST types/constructors were still around, naturally.) Here's the example I put on HPaste a few days ago: http://hpaste.org/10059#a1 You'll notice that the actual shim you're looking at - with the help of the defined functions - is actually fairly small, and those functions help out with those *a lot.* That was the first thing I wrote with it though, so the functions could probably be further generalized and abstracted. On that note (although a little OT,) does anybody think it would be nice to have a higher level library designed specifically around emitting C that uses Language.C? A lot of repetetive stuff can be cut down considerably, I think. Austin From bos at serpentine.com Thu Sep 4 21:22:20 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Sep 4 21:20:24 2008 Subject: [Haskell-cafe] Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception". In-Reply-To: <20080904212420.GI7216@scytale.galois.com> References: <20080904211435.GA4119@muc.de> <20080904212420.GI7216@scytale.galois.com> Message-ID: On Thu, Sep 4, 2008 at 2:24 PM, Don Stewart wrote: >> I've downloaded the ghc-6.8.3-i386-unknown-linux.tar.bz2 tarball, which >> I expected to work on my GNU/Linux box (1.2 GHz Athlon, Debian Sarge). > > Was there a problem installing GHC from the Debian package system with apt? Sarge is extremely old in Linux years, and support for it was EOLed earlier this year. It ships with a particularly buggy version of glibc. I would recommend upgrading. From jake.mcarthur at gmail.com Thu Sep 4 21:48:49 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Thu Sep 4 21:46:59 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> Message-ID: <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> On Sep 4, 2008, at 10:19 AM, Tim Chevalier wrote: > The master programmer does not add strictness annotations, for she has > not yet run the profiler. My guess would be that a master usually adds strictness annotations as documentation rather than as optimizations. - Jake McArthur From matt at immute.net Thu Sep 4 22:04:31 2008 From: matt at immute.net (Matt Hellige) Date: Thu Sep 4 22:02:36 2008 Subject: [Haskell-cafe] Categorical language In-Reply-To: <6cb897b30809041146j1cc7f2feg964ee51c2a503d5e@mail.gmail.com> References: <6cb897b30809041146j1cc7f2feg964ee51c2a503d5e@mail.gmail.com> Message-ID: <5959041b0809041904x578afe24g960fdeba136f35e2@mail.gmail.com> On Thu, Sep 4, 2008 at 1:46 PM, Pierre-Evariste Dagand wrote: >> what could be a "categorical language"? > > Something we would call Charity, for example :-) > Also check out Tatsuya Hagino's PhD thesis, available here: http://www.tom.sfc.keio.ac.jp/~hagino/index.html.en It's a precursor to the Charity work, and a very nice presentation of the ideas. Take care... Matt From allbery at ece.cmu.edu Thu Sep 4 22:36:33 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Sep 4 22:34:42 2008 Subject: [Haskell-cafe] Hackage -> MacPorts? In-Reply-To: <49a77b7a0809041708p700d874fi13ab922cf3956a06@mail.gmail.com> References: <20080903201449.GA20567@berkeley.edu> <49a77b7a0809031454w2d5bb49fm3ab328876af6dc40@mail.gmail.com> <1220519979.24846.513.camel@localhost> <49a77b7a0809040909h689ffea1uf4488ddcc221a220@mail.gmail.com> <1220558832.24846.550.camel@localhost> <20080904201429.GC7216@scytale.galois.com> <49a77b7a0809041708p700d874fi13ab922cf3956a06@mail.gmail.com> Message-ID: <4ACFE841-50FB-4AAC-8AA9-98D750E9A7EB@ece.cmu.edu> On 2008 Sep 4, at 20:08, David Menendez wrote: > What happens when you upgrade GHC? The problem MacPorts has is that > the libraries are still listed as installed, even though they are no > longer registered or useable. MacPorts has the same problem with Perl (XS code is dependent on the exact version), and they don't seem to have put nay effort into fixing it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ryani.spam at gmail.com Thu Sep 4 22:36:55 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Sep 4 22:35:01 2008 Subject: [Haskell-cafe] Functional references In-Reply-To: References: Message-ID: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> Nice. I've written similar stuff a couple of times before, but the formulation using Maybe and modify definitely solves some problems I started to notice as I used it on bigger structures. However, it might be better to separate a class of "never failing" references, where the reader is guaranteed to succeed, from "potentially failing" references which give a Maybe value. I'd also not use the names "get" and "modify" because they are already used by MonadState. I always used "frGet", "frSet", and "frModify", and then tended to not use them directly as I was generally working in a state monad. Here's a few more primitives that I found quite useful: > fetch :: MonadState s m => FRef s a -> m (Maybe a) > fetch ref = liftM (frGet ref) get > (=:) :: MonadState s m => FRef s a -> a -> m () > r =: v = modify (frSet r v) > ($=) :: MonadState s m => FRef s a -> (a -> a) -> m () > r $= f = modify (frModify r f) You should package this up and put it on hackage. -- ryan On Thu, Sep 4, 2008 at 4:51 PM, Tim Newsham wrote: > I'm playing with functional references and looking for some feedback on a > small FRec library I put together: > > http://www.thenewsh.com/~newsham/FRef.hs > > Novel (I think) is that the library is applied to some data accesses that > are not normally covered by functional references -- ie. extracting words or > replacing words in a string or values in an association list. I'm hoping it > will provides a useful framework for editing complex values such as data > embedded in Base64 cookies in an HTTP header. > > Tim Newsham > http://www.thenewsh.com/~newsham/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From catamorphism at gmail.com Thu Sep 4 22:52:55 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Sep 4 22:51:00 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> Message-ID: <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> On 9/4/08, Jake Mcarthur wrote: > My guess would be that a master usually adds strictness annotations as > documentation rather than as optimizations. > I'm no master, but I've never encountered a situation where strictness annotations would be useful as documentation, nor can I imagine one. That's because optimization *is* the only reason why programmers should care about strictness information. IMO, arguing that programmers should care at all amounts to conceding that default laziness is treacherous. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Stupidity combined with arrogance and a huge ego will get you a long way." -- Chris Lowe From jake.mcarthur at gmail.com Fri Sep 5 00:23:39 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Fri Sep 5 00:21:51 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> Message-ID: <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> On Sep 4, 2008, at 9:52 PM, Tim Chevalier wrote: > I'm no master, but I've never encountered a situation where strictness > annotations would be useful as documentation, nor can I imagine one. I'm no master either, but how about these simple examples? data Stream a = Cons !a (Stream a) data Vector3 a = Vector3 !a !a !a The compiler will certainly be able to infer the strictness itself in most uses, so obviously the purpose for these annotations is not for optimization, but I still would find these annotations useful. This is much like explicitly giving the type for a function. It guides the reader of the program, and just happens to also assist the compiler a little bit. > That's because optimization *is* the only reason why programmers > should care about strictness information. IMO, arguing that > programmers should care at all amounts to conceding that default > laziness is treacherous. If optimization is the only reason to worry about strictness, then default laziness really _is_ treacherous. Luckily this is not the case. Laziness is not useful without strictness, otherwise there would never be any evaluation. Understanding how to apply laziness and strictness in different situations is critical to writing efficient but meaningful code in Haskell. To quote a blog article[1] I wrote in June, "It is simple and idiomatic to use strictness where your program calls for it. In other words, contrary to many complaints, strictness is not a low-level optimization technique. Strictness is a strategy for algorithms. As is always the case, if you change an algorithm, its time and space requirements will change, but it?s a high-level change. A strictness annotation or data structure redesign is not like dropping to C or assembly." The article explains laziness and strictness as I understand it. I could be wrong, but my understanding seems to have served me well so far. - Jake McArthur From jake.mcarthur at gmail.com Fri Sep 5 00:25:00 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Fri Sep 5 00:23:11 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> Message-ID: On Sep 4, 2008, at 11:23 PM, Jake Mcarthur wrote: > To quote a blog article[1] I wrote in June, And of course I would forget to link the article. My bad. [1] http://geekrant.wordpress.com/2008/06/23/misconceptions/ - Jake McArthur From wren at freegeek.org Fri Sep 5 00:30:47 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Sep 5 00:28:58 2008 Subject: The IO sin bin [was: Re: [Haskell-cafe] Re: [Haskell] Top Level <-] In-Reply-To: <48BCE7F8.4030208@iee.org> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> <48BA8FE6.4090904@iee.org> <48BAB969.3020004@gotadsl.co.uk> <48BBE7E9.9080306@iee.org> <48BCE7F8.4030208@iee.org> Message-ID: <48C0B5F7.8010104@freegeek.org> Adrian Hey wrote: > There's shed loads of information and semantic subtleties about pretty > much any operation you care to think of in the IO monad that isn't > communicated by it's type. All you know for sure is that it's weird, > because if it wasn't it wouldn't be in the IO monad. > > So I think you're applying double standards. Not to throw any more fuel on the fire (if at all possible), but the reason behind this is that IO has become a sin bin for all the things that people either don't know how to deal with, or don't care enough to tease apart. There are many people who would like to break IO apart into separate segments for all the different fragments of the RealWorld that actually matter for a given purpose. To date it has not been entirely clear how best to do this and retain a workable language. The fact that this discussion is going on at all is, IMO, precisely because of the sin-bin nature of IO. People have things they want to have "global" or otherwise arbitrarily large scope, but the only notion of a globe in Haskell is the RealWorld. Hence they throw things into IO and then unsafePerformIO it to get it back out. There are three problems to this approach: (1) It's a hack and not guaranteed to work, nuff said. (2) The RealWorld is insufficiently described to ensure any semantics regarding *how* it holds onto the state requested of it. This problem manifests itself in the discussion of loading the same library multiple times, having multiple RTSes in a single OS process, etc. In those scenarios what exactly the "RealWorld" is and how the baton is passed among the different libraries/threads/processes/RTSes is not clearly specified. (3) The API language is insufficiently detailed to make demands on what the RealWorld holds. This problem manifests itself in the argument about whether libraries should be allowed to implicitly modify portions of the RealWorld, or whether this requirement should be made clear in the type signatures of the library. As I said in the thread on [Research language vs. professional language], I think coming up with a solution to this issue is still an open research problem, and one I think Haskell should be exploring. The ACIO monad has a number of nice properties and I think it should be broken out from IO even if top-level <- aren't added to the language. The ability to declare certain FFI calls as ACIO rather than IO is, I think, reason enough to pursue ACIO on its own. But, ACIO does not solve the dilemmas raised in #2 and #3. Top-level mutable state is only a symptom of the real problem that IO and the RealWorld are insufficiently described. Another example where unsafePerformIO is used often is when doing RTS introspection. Frequently, interrogating the RTS has ACIO-like properties in that we are only interested in the RTS if a particular thunk happens to get pulled on, and we're only interested at the time that the pulling occurs rather than in sequence to any other actions. The use of unsafePerformIO here seems fraught with all the same problems as top-level mutable state. It would be nice to break out an RTS monad (or an UnsafeGhcRTS monad, or what have you) in order to be more clear about the exact requirements of what's going on. But even if we break ACIO and UnsafeGhcRTS out from IO, the dilemmas remain. To a certain extent, the dilemmas will always remain because there will always be a frontier beyond which we don't know what's happening: the real world exists, afterall. However, there is still room to hope for a general approach to the problem. One potential is to follow on the coattails of _Data Types a la Carte_. Consider, for example, if the language provided a mechanism for users to generate RealWorld-like non-existent tokens. Now consider removing IO[1] and only using BS, where the thread-state parameter could be any (co)product of RealWorld-like tokens. We could then have an overloaded function to lift any (BS a) into a BS (a :+: b). There are some complications with DTalC's coproducts in practice. For example, (a :+: b) and (b :+: a) aren't considered the same type, as naturally they can't be due to the Inl/Inr tagging. A similar approach should be able to work however, since these tokens don't really exist at all. Of course, once we take things to that level we're already skirting around capability systems. Rather than using an ad-hoc approach like this, I think it would be better to work out a theory connecting capability systems to monad combinators, and then use that theory to smash the sin bin of IO. [1] Or leaving it in as a type alias for BS RealWorld. -- Live well, ~wren From catamorphism at gmail.com Fri Sep 5 00:40:09 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Sep 5 00:38:14 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> Message-ID: <4683d9370809042140m4b90dd57geb14e118612669f5@mail.gmail.com> On 9/4/08, Jake Mcarthur wrote: > I'm no master either, but how about these simple examples? > > data Stream a = Cons !a (Stream a) > data Vector3 a = Vector3 !a !a !a > > The compiler will certainly be able to infer the strictness itself in > most uses, so obviously the purpose for these annotations is not for > optimization, but I still would find these annotations useful. This is > much like explicitly giving the type for a function. It guides the > reader of the program, and just happens to also assist the compiler a > little bit. > But why not write your types like: data Stream a = Cons a data Vector3 a = Vector3 a a a in a hypothetical call-by-value language where the <> annotation denotes a lazily evaluated data structure? Does it matter? If it does, then why? If it doesn't, then what would you conclude about whether a language should encourage laziness or strictness? > If optimization is the only reason to worry about strictness, then > default laziness really _is_ treacherous. Luckily this is not the > case. Laziness is not useful without strictness, otherwise there would > never be any evaluation. Understanding how to apply laziness and > strictness in different situations is critical to writing efficient > but meaningful code in Haskell. True, but both laziness and strictness exist in strict languages, as well. What if, as a thought experiment, you tried substituting "laziness" for "strictness" in that paragraph of your essay? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The Internet wasn't created for mockery, it was created to help researchers at different universities share data sets." -- Homer Simpson From jake.mcarthur at gmail.com Fri Sep 5 00:40:16 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Fri Sep 5 00:38:30 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809041050i7dc5855cm2bde19f328076407@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <141527000.20080903155845@gmail.com> <40a414c20809030537p183caa47i659a1c6b6ae968cd@mail.gmail.com> <48C01D3D.3010100@cogito.org.uk> <40a414c20809041050i7dc5855cm2bde19f328076407@mail.gmail.com> Message-ID: <27FB6160-9C3D-4E59-8D8B-24FCEB0DAA70@gmail.com> On Sep 4, 2008, at 12:50 PM, minh thu wrote: >> I'd have thought you wanted "IORef (Maybe Thing)", which says that >> the >> pointer always exists, but may not point to anything. On the other >> hand >> "Maybe (IORef Thing)" says that the pointer may or may not exist. > > Yes, someone else said it too. But you saiy that regarding the > pointer. If you > look at the thing the pointer (if any) points at, what's the > difference ? > Either there is none : Nothing or IORef Nothing, or there is one : > Just (IORef 5) > or IORef (Just 5). There is still a difference. With Maybe (IORef a), the nothingness is expressed only locally, but with IORef (Maybe a), the nothingness can be shared and mutated by any other IORefs that point to it as well. - Jake McArthur -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080904/b9aa713c/attachment.htm From wren at freegeek.org Fri Sep 5 01:01:56 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Sep 5 01:00:03 2008 Subject: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ? In-Reply-To: <40a414c20809041050i7dc5855cm2bde19f328076407@mail.gmail.com> References: <40a414c20809030309j2d880a24o24ebf80d8f431ecf@mail.gmail.com> <141527000.20080903155845@gmail.com> <40a414c20809030537p183caa47i659a1c6b6ae968cd@mail.gmail.com> <48C01D3D.3010100@cogito.org.uk> <40a414c20809041050i7dc5855cm2bde19f328076407@mail.gmail.com> Message-ID: <48C0BD44.3060305@freegeek.org> minh thu wrote: > 2008/9/4 Paul Johnson : >> I'd have thought you wanted "IORef (Maybe Thing)", which says that the >> pointer always exists, but may not point to anything. On the other hand >> "Maybe (IORef Thing)" says that the pointer may or may not exist. > > Yes, someone else said it too. But you saiy that regarding the pointer. If you > look at the thing the pointer (if any) points at, what's the difference ? > Either there is none : Nothing or IORef Nothing, or there is one : > Just (IORef 5) > or IORef (Just 5). > > The difference is you have to allocate a new IORef whenever you want to make > the thing pointed at appear in the first case. The difference is that IORef(Maybe a) lets someone in IO modify the pointer in place. So if the IORef is pointing to Nothing, someone can come and fix that so it's pointing to Just thing, without needing to alter any of the data structure or context above the IORef. They can also use this same ability to change an IORef pointing to something into one pointing to Nothing, either for good or ill. With Maybe(IORef a) the pointer either exists or does not, and that fact can never be changed without rebuilding the datastructure/context above the Maybe. Provided that the pointer exists, it can be freely modified by anyone in IO to point to different things throughout its life (but it's always pointing to something). Depending on the exact semantics you're trying to model, either approach can be correct. The way C and similar languages typically deal with variables holding pointers is like IORef(Maybe a). A "const" pointer ---pointing to a fixed destination, where the memory at that destination can be altered--- is similar to Maybe(IORef a). Good luck with Data.IntMap, hopefully it'll simplify things. -- Live well, ~wren From jake.mcarthur at gmail.com Fri Sep 5 01:06:48 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Fri Sep 5 01:04:59 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809042140m4b90dd57geb14e118612669f5@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> <4683d9370809042140m4b90dd57geb14e118612669f5@mail.gmail.com> Message-ID: On Sep 4, 2008, at 11:40 PM, Tim Chevalier wrote: > But why not write your types like: > data Stream a = Cons a > data Vector3 a = Vector3 a a a > in a hypothetical call-by-value language where the <> annotation > denotes a lazily evaluated data structure? Does it matter? If it does, > then why? If it doesn't, then what would you conclude about whether a > language should encourage laziness or strictness? It doesn't matter, and I don't think it says anything about whether we should encourage lazy-by-default or strict-by-default. Two lazy algorithms tend to compose well and result in a lazy algorithm. A lazy algorithm can compose with a strict algorithm in two different ways. One way is for the lazy algorithm to control the strict algorithm, in which case the strict algorithm is either invoked or not invoked, resulting in a lazy algorithm. The other way is for the strict algorithm to control the lazy algorithm, in which case the strict algorithm requests the data it needs from the lazy algorithm as it needs it, resulting in a strict algorithm. Finally, two strict algorithms may also compose, which results in a strict algorithm. No matter how you slice it, none of the above scenarios are necessarily bad. Each of the four permutations of laziness and strictness for two composed algorithms are necessary for different situations. Laziness and strictness work in tandem with each other to construct whole programs. We Haskellers like laziness by default because we find that it encourages us to consider laziness to solve our problems more often than in call-by-need languages, not because it is somehow "superior" to strictness. That is the strongest argument I can think of to be made in favor of lazy-by-default. > both laziness and strictness exist in strict languages, as > well. What if, as a thought experiment, you tried substituting > "laziness" for "strictness" in that paragraph of your essay? I think the same points would apply, honestly. Do you believe they would change in some way? - Jake McArthur From haskell at colquitt.org Fri Sep 5 01:37:21 2008 From: haskell at colquitt.org (John Dorsey) Date: Fri Sep 5 01:35:26 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> Message-ID: <20080905053721.GA3932@colquitt.org> Tim Chevalier wrote: > I'm no master, but I've never encountered a situation where strictness > annotations would be useful as documentation, nor can I imagine one. > That's because optimization *is* the only reason why programmers > should care about strictness information. IMO, arguing that > programmers should care at all amounts to conceding that default > laziness is treacherous. I'm no master either, but I'd argue that if we promise new programmers that they don't need to care about strictness, we thereby ensure that default laziness is treacherous. A year or two ago, ISTR that *most* of the newbie-generated traffic in the cafe was about atrocious performance of naive programs due to strict/lazy concerns. I think it was scaring people away. Adding strictness can improve asymptotic space performance, as an example. Is there a reason to think this won't always be true? Honest question, since I don't know nearly enough about strictness analysis to guess how good it'll be some day. Regards, John From ashley at semantic.org Fri Sep 5 01:37:56 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Sep 5 01:36:02 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-group.com> Message-ID: <48C0C5B4.2000909@semantic.org> Sittampalam, Ganesh wrote: >> Oh dear. To fix this, I suppose the RTS would have to be able to >> keep track of all static initialisers. But it shouldn't otherwise >> affect program optimisation. > > What would the RTS actually do? I don't know enough about the RTS to say. I imagine initialisers would have to be marked in object files, so the RTS could link them separately when dynamically loading. The RTS would also keep a list of initialisers in the main program. -- Ashley Yakeley From catamorphism at gmail.com Fri Sep 5 01:45:45 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Sep 5 01:43:49 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> <4683d9370809042140m4b90dd57geb14e118612669f5@mail.gmail.com> Message-ID: <4683d9370809042245r6bb42238s53d1d5ee9fd4a67a@mail.gmail.com> On 9/4/08, Jake Mcarthur wrote: > Two lazy algorithms tend to compose well and result in a lazy > algorithm. A lazy algorithm can compose with a strict algorithm in two > different ways. One way is for the lazy algorithm to control the > strict algorithm, in which case the strict algorithm is either invoked > or not invoked, resulting in a lazy algorithm. The other way is for > the strict algorithm to control the lazy algorithm, in which case the > strict algorithm requests the data it needs from the lazy algorithm as > it needs it, resulting in a strict algorithm. Finally, two strict > algorithms may also compose, which results in a strict algorithm. > > No matter how you slice it, none of the above scenarios are > necessarily bad. Each of the four permutations of laziness and > strictness for two composed algorithms are necessary for different > situations. Laziness and strictness work in tandem with each other to > construct whole programs. > You say lazy algorithms are good because they compose well. In Haskell, does an algorithm that operates on data structures that have strict components have that property? > We Haskellers like laziness by default because we find that it > encourages us to consider laziness to solve our problems more often > than in call-by-need languages, not because it is somehow "superior" > to strictness. That is the strongest argument I can think of to be > made in favor of lazy-by-default. > So you don't believe that laziness is superior to strictness, or versa; I don't, either. But you do say it's good to be encouraged to use laziness more often. Why? You mention compositionality above as a possible reason, in reply to which, see above. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The future is not google-able." -- William Gibson From jake.mcarthur at gmail.com Fri Sep 5 01:55:51 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Fri Sep 5 01:54:01 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809042245r6bb42238s53d1d5ee9fd4a67a@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> <4683d9370809042140m4b90dd57geb14e118612669f5@mail.gmail.com> <4683d9370809042245r6bb42238s53d1d5ee9fd4a67a@mail.gmail.com> Message-ID: <42D8DEA1-9E49-4DA9-B175-D92637B140E6@gmail.com> On Sep 5, 2008, at 12:45 AM, Tim Chevalier wrote: > On 9/4/08, Jake Mcarthur wrote: >> Two lazy algorithms tend to compose well and result in a lazy >> algorithm. A lazy algorithm can compose with a strict algorithm in >> two >> different ways. One way is for the lazy algorithm to control the >> strict algorithm, in which case the strict algorithm is either >> invoked >> or not invoked, resulting in a lazy algorithm. The other way is for >> the strict algorithm to control the lazy algorithm, in which case the >> strict algorithm requests the data it needs from the lazy algorithm >> as >> it needs it, resulting in a strict algorithm. Finally, two strict >> algorithms may also compose, which results in a strict algorithm. >> >> No matter how you slice it, none of the above scenarios are >> necessarily bad. Each of the four permutations of laziness and >> strictness for two composed algorithms are necessary for different >> situations. Laziness and strictness work in tandem with each other to >> construct whole programs. >> > > You say lazy algorithms are good because they compose well. In > Haskell, does an algorithm that operates on data structures that have > strict components have that property? The algorithm itself can still be lazy in that it might not evaluate the strict data structures at all, and thus can still have that property. However, I did not mean to necessarily emphasize the composability of lazy functions over the composability of strict functions. Both, theoretically, can compose equally well. Composition for laziness and strictness just mean slightly different things as they pertain to control flow and data flow. >> We Haskellers like laziness by default because we find that it >> encourages us to consider laziness to solve our problems more often >> than in call-by-need languages, not because it is somehow "superior" >> to strictness. That is the strongest argument I can think of to be >> made in favor of lazy-by-default. >> > > So you don't believe that laziness is superior to strictness, or > versa; I don't, either. But you do say it's good to be encouraged to > use laziness more often. Why? You mention compositionality above as a > possible reason, in reply to which, see above. Mostly because, at least in this part of history, it is easy in many languages to forget about lazy evaluation altogether. I don't think it's a matter of encouraging laziness _over_ strictness, as they are both beneficial, just a matter encouraging the programmer to _think_ in terms of laziness and strictness more often. - Jake McArthur From catamorphism at gmail.com Fri Sep 5 02:17:42 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Sep 5 02:15:47 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <20080905053721.GA3932@colquitt.org> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <20080905053721.GA3932@colquitt.org> Message-ID: <4683d9370809042317o6ec66d69u8f05d8e1bc007705@mail.gmail.com> On 9/4/08, John Dorsey wrote: > I'm no master either, but I'd argue that if we promise new programmers > that they don't need to care about strictness, we thereby ensure that > default laziness is treacherous. > > A year or two ago, ISTR that *most* of the newbie-generated traffic in > the cafe was about atrocious performance of naive programs due to > strict/lazy concerns. I think it was scaring people away. > I think it's debatable what the various causality relationships might be here. > Adding strictness can improve asymptotic space performance, as an example. > Is there a reason to think this won't always be true? Honest question, > since I don't know nearly enough about strictness analysis to guess > how good it'll be some day. Adding strictness can also worsen asymptotic space (and time) performance. That's one reason why we use a lazy language at all. Strictness analysis is an approximation to the problem of determining what parts of a program can be evaluated strictly without changing their meaning, because if we had a perfect solution to that problem, we could solve the halting problem. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "There are no difficult problems, just unfortunate notations." -- Alfonso Gracia-Saz From haskell at colquitt.org Fri Sep 5 02:58:58 2008 From: haskell at colquitt.org (John Dorsey) Date: Fri Sep 5 02:57:02 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809042317o6ec66d69u8f05d8e1bc007705@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <20080905053721.GA3932@colquitt.org> <4683d9370809042317o6ec66d69u8f05d8e1bc007705@mail.gmail.com> Message-ID: <20080905065857.GB3932@colquitt.org> Tim, > > A year or two ago, ISTR that *most* of the newbie-generated traffic in > > the cafe was about atrocious performance of naive programs due to > > strict/lazy concerns. I think it was scaring people away. > > I think it's debatable what the various causality relationships might be here. Certainly... > > Adding strictness can improve asymptotic space performance, as an example. > > Is there a reason to think this won't always be true? Honest question, > > since I don't know nearly enough about strictness analysis to guess > > how good it'll be some day. > > Adding strictness can also worsen asymptotic space (and time) > performance. That's one reason why we use a lazy language at all. > Strictness analysis is an approximation to the problem of determining > what parts of a program can be evaluated strictly without changing > their meaning, because if we had a perfect solution to that problem, > we could solve the halting problem. No argument. I was responding to your comment that ... "IMO, arguing that programmers should care at all amounts to conceding that default laziness is treacherous." ... which sounds like you're arguing against programmers giving due attention to lazy/strict choices. I was suggesting that there is good reason to think that we should pay attention to it; that it's a necessary part of learning Haskell; and that it will likely remain so. Newbies should be encouraged to think and experiment more with laziness and strictness. Regards, John (pondering an IDE mode for visualizing strictness properties) From ganesh.sittampalam at credit-suisse.com Fri Sep 5 03:39:51 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Sep 5 03:38:07 2008 Subject: [Haskell-cafe] RE: [Haskell] Top Level <- In-Reply-To: <48C0C5B4.2000909@semantic.org> References: <534781822.20080826190130@gmail.com> <48BC6EE4.5000109@semantic.org> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > Sittampalam, Ganesh wrote: >>> Oh dear. To fix this, I suppose the RTS would have to be able to keep >>> track of all static initialisers. But it shouldn't otherwise affect >>> program optimisation. >> >> What would the RTS actually do? > I don't know enough about the RTS to say. I imagine initialisers would > have to be marked in object files, so the RTS could link them separately > when dynamically loading. The RTS would also keep a list of initialisers > in the main program. Sounds plausible, although dynamic relocations do slow down linking. Unloading is another interesting problem. Are we allowed to re-run <- if the module that contained it is unloaded and then reloaded? I'm not quite sure what the conditions for allowing a module to be unloaded in general should be, though. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From jules at jellybean.co.uk Fri Sep 5 04:34:35 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Sep 5 04:32:42 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> Message-ID: <48C0EF1B.30903@jellybean.co.uk> Jake Mcarthur wrote: > On Sep 4, 2008, at 9:52 PM, Tim Chevalier wrote: > >> I'm no master, but I've never encountered a situation where strictness > >> annotations would be useful as documentation, nor can I imagine one. > > > I'm no master either, but how about these simple examples? > > data Stream a = Cons !a (Stream a) > data Vector3 a = Vector3 !a !a !a > > The compiler will certainly be able to infer the strictness itself in > most uses, so obviously the purpose for these annotations is not for > optimization, but I still would find these annotations useful. As far as I am aware this statement is false. I do not believe the compiler infers strictness in common uses of either of these cases, and I have seen space blowups / stack blowups because of it. I use the rule of thumb : simple 'scalar' field components should be strict. Scalar is an ill-defined term but typically means non-recursive data types, like Int and Bool. The most natural exception to this rule is the 'memoizing constructor' idiom. Jules From ketil at malde.org Fri Sep 5 04:49:00 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Sep 5 04:45:22 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <48C0EF1B.30903@jellybean.co.uk> (Jules Bean's message of "Fri\, 05 Sep 2008 09\:34\:35 +0100") References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <9207C0EA-8DA9-478B-9076-F27D507810ED@gmail.com> <4683d9370809041952w4fcbd0dek82e1d843de13f582@mail.gmail.com> <886BCBCE-50F3-48DD-A1D2-E24447EC5635@gmail.com> <48C0EF1B.30903@jellybean.co.uk> Message-ID: <87abendlkz.fsf@malde.org> Jules Bean writes: >>>> On Sep 4, 2008, at 10:19 AM, Tim Chevalier wrote: >>>>> The master programmer does not add strictness annotations, for she has >>>>> not yet run the profiler. >> The compiler will certainly be able to infer the strictness itself > As far as I am aware this statement is false. The master programmer does not add strictness annotations, she improves the strictness analyser. -k -- If I haven't seen further, it is by standing in the footprints of giants From jules at jellybean.co.uk Fri Sep 5 05:06:39 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Sep 5 05:04:45 2008 Subject: [Haskell-cafe] Functional references In-Reply-To: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> Message-ID: <48C0F69F.5010903@jellybean.co.uk> > You should package this up and put it on hackage. > It is nice, but there is already another FRef package on hackage (Data.Accessor) and I have a home-grown one of my own, which uses different notation / combinators to either the hackage one or Tim's. There are also fragments of FRef-like things in some of the big libraries like OpenGL and GTK. I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. Jules From ashley at semantic.org Fri Sep 5 05:07:52 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Sep 5 05:06:01 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> Message-ID: <48C0F6E8.6000603@semantic.org> Sittampalam, Ganesh wrote: > Sounds plausible, although dynamic relocations do slow down linking. > > Unloading is another interesting problem. Are we allowed to re-run <- > if the module that contained it is unloaded and then reloaded? I'm not > quite sure what the conditions for allowing a module to be unloaded > in general should be, though. Interesting question. I suppose it's allowable if the guarantees attached to the ACIO type imply that it would not be possible to tell the difference. I think this means that all values of types, including newtypes, belonging to the module must be unreachable before unloading. Consider Data.Unique as a separate loadable module. It's loaded, and various Unique values are obtained. But Unique is just a newtype of Integer, and comparison between Uniques doesn't use code from Data.Unique. This might be difficult to track as once the newtype is boiled away, the code is basically dealing with Integers, not Uniques. I really don't know enough about the RTS to know. The alternative would be to keep all initialised values when the module is unloaded. I'm guessing this is more feasible. -- Ashley Yakeley From ganesh.sittampalam at credit-suisse.com Fri Sep 5 06:44:33 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Sep 5 06:43:06 2008 Subject: [Haskell-cafe] RE: [Haskell] Top Level <- In-Reply-To: <48C0F6E8.6000603@semantic.org> References: <534781822.20080826190130@gmail.com> <48BC8284.9030305@semantic.org> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> Ashley Yakeley wrote: > I really don't know enough about the RTS to know. The > alternative would be to keep all initialised values > when the module is unloaded. I'm guessing this is more > feasible. Easier, but a guaranteed memory leak. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From dav.vire+haskell at gmail.com Fri Sep 5 06:45:01 2008 From: dav.vire+haskell at gmail.com (david48) Date: Fri Sep 5 06:43:11 2008 Subject: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters Message-ID: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> In the online version of Real world Haskell, there's a problem with examples in ghci when the module Database.HDBC.Sqlite3 is imported. It goes on like this for all of chapter 21 and 22. Example : ( note: this is not me trying to reproduce the examples, it's an actual copy & paste from the site url http://book.realworldhaskell.org/read/using-databases.html ) ghci> :module Database.HDBC Database.HDBC.Sqlite3 Could not find module `Database.HDBC.Sqlite3': Use -v to see a list of the files searched for. ghci> conn <- connectSqlite3 "test1.db" :1:8: Not in scope: `connectSqlite3' ghci> :type conn :1:0: Not in scope: `conn' ghci> disconnect conn :1:0: Not in scope: `disconnect' :1:11: Not in scope: `conn' From voigt at tcs.inf.tu-dresden.de Fri Sep 5 07:05:46 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Fri Sep 5 06:52:48 2008 Subject: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters In-Reply-To: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> Message-ID: <48C1128A.2040804@tcs.inf.tu-dresden.de> See John's comment, right there in the online version: "The system that generated this webpage didn't have HDBC installed at the time. We'll get that fixed and re-post this chapter. In the meantime, unfortunately, all of the examples on this page will look that way." david48 wrote: > In the online version of Real world Haskell, there's a problem with > examples in ghci when the module Database.HDBC.Sqlite3 is imported. > It goes on like this for all of chapter 21 and 22. > > Example : ( note: this is not me trying to reproduce the examples, > it's an actual copy & paste from the site url > http://book.realworldhaskell.org/read/using-databases.html ) > > ghci> :module Database.HDBC Database.HDBC.Sqlite3 > Could not find module `Database.HDBC.Sqlite3': > Use -v to see a list of the files searched for. > ghci> conn <- connectSqlite3 "test1.db" > > :1:8: Not in scope: `connectSqlite3' > ghci> :type conn > > :1:0: Not in scope: `conn' > ghci> disconnect conn > > :1:0: Not in scope: `disconnect' > > :1:11: Not in scope: `conn' > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From claus.reinke at talk21.com Fri Sep 5 08:04:03 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 5 08:02:22 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters) References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> Message-ID: <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Now that is "real world" - problems even before release!-) Seriously, though, what is the RWH authors' plan for tackling the eternal frustration of Haskell book authors, a moving target? There used to be a time when one could guess the poster's Haskell book from their question topics: - 'HGL' doesn't work: Hudak's book - 'fromInt' issues: Thompson's book The problem arises because the books survive far longer than the version of the code base they refer to. The only way to reduce this friction has been to avoid fast-changing details, eg, focussing on programming, problem solving, reasoning (Hutton, Thompson, Bird), and even that isn't safe ('n+k', 'fromInt',..). Neither is keeping a separate library - 'SOEGraphics' has been revived several times, on different GUI/graphic libs, even different Haskell implementations, but has always fallen prey to bitrot again. I've only scanned RWH briefly, but it seems to be on the other end of the spectrum, focussing precisely on the details of stuff that is likely to evolve much faster than the book. Is the plan to keep someone employed over the years to keep the online version updated? Claus From duncan.coutts at worc.ox.ac.uk Fri Sep 5 08:16:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 5 08:12:51 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters) In-Reply-To: <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: <1220616969.6076.47.camel@localhost> On Fri, 2008-09-05 at 13:04 +0100, Claus Reinke wrote: > Now that is "real world" - problems even before release!-) > > Seriously, though, what is the RWH authors' plan for tackling > the eternal frustration of Haskell book authors, a moving target? > > There used to be a time when one could guess the poster's > Haskell book from their question topics: > > - 'HGL' doesn't work: Hudak's book > - 'fromInt' issues: Thompson's book > > The problem arises because the books survive far longer than > the version of the code base they refer to. The only way to reduce > this friction has been to avoid fast-changing details, eg, focussing > on programming, problem solving, reasoning (Hutton, Thompson, > Bird), and even that isn't safe ('n+k', 'fromInt',..). Neither is > keeping a separate library - 'SOEGraphics' has been revived > several times, on different GUI/graphic libs, even different Haskell > implementations, but has always fallen prey to bitrot again. There are currently two independent working implementations of ?SOEGraphics on GUI libs that are maintained. I think it'll probably be ok. Duncan From ross at soi.city.ac.uk Fri Sep 5 08:24:35 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Sep 5 08:22:43 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters) In-Reply-To: <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: <20080905122435.GA23059@soi.city.ac.uk> On Fri, Sep 05, 2008 at 01:04:03PM +0100, Claus Reinke wrote: > Seriously, though, what is the RWH authors' plan for tackling > the eternal frustration of Haskell book authors, a moving target? > > There used to be a time when one could guess the poster's > Haskell book from their question topics: > > - 'HGL' doesn't work: Hudak's book > - 'fromInt' issues: Thompson's book > > The problem arises because the books survive far longer than > the version of the code base they refer to. The only way to reduce this > friction has been to avoid fast-changing details, eg, focussing on > programming, problem solving, reasoning (Hutton, Thompson, > Bird), and even that isn't safe ('n+k', 'fromInt',..). One of the specific aims of Haskell 98 was to provide a stable base for authors. It did not include fromInt, which was an internal quirk of the Hugs implementation, and nor did any other Haskell implementation. From jgoerzen at complete.org Fri Sep 5 09:37:40 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Sep 5 09:35:51 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters) In-Reply-To: <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: <20080905133740.GA17494@hustlerturf.com> On Fri, Sep 05, 2008 at 01:04:03PM +0100, Claus Reinke wrote: > Now that is "real world" - problems even before release!-) > > Seriously, though, what is the RWH authors' plan for tackling > the eternal frustration of Haskell book authors, a moving target? Hope that enough copies are sold that O'Reilly lets us make a 2nd edition when things change? :-) More seriously, you do the best you can. We tried to mostly write about things that are in the libraries that ship with GHC. There are some exceptions, such as HDBC and gtk2hs. But these things happen in any language, and you publish errata, or a new edition. We've already been bitten by this, and we're not even in production yet. The regex library included with GHC 6.8.3 can be used in a [String] context, but the newer regex library on Hackage (which is shipped by Debian) can't. Doh. > I've only scanned RWH briefly, but it seems to be on the other > end of the spectrum, focussing precisely on the details of stuff > that is likely to evolve much faster than the book. Is the plan to > keep someone employed over the years to keep the online > version updated? We haven't specifically discussed that, but in general, doing a book is a *lot* of work, and I suspect all three of us will be wanting to take a break from book-writing or -maintaining activities for a bit after O'Reilly starts cutting down trees on our behalf. That said, we're still maintaining all the infrastructure for the project, so we could go and update things at any time. -- John From leather at cs.uu.nl Fri Sep 5 10:11:57 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Sep 5 10:10:05 2008 Subject: [Haskell-cafe] Reducing code for efficient ShowS Message-ID: <3c6288ab0809050711x70ae0003h28fdb7817003d9db@mail.gmail.com> It happens very often that I want to convert a number of values to strings and concatenate those strings into one. No surprise there, of course. Well, I'd prefer to do it efficiently and with as little code as necessary. > {-# LANGUAGE TypeSynonymInstances #-} > module ShowsDemo where Let's say I want to generate the string "(42 abc)" starting with a number and a string stored in variables. > n = 42 :: Int > s = "abc" What are my options? There's the obvious approach that's described in every tutorial, book, and research paper (for didactic purposes, of course). > ex1 = "(" ++ show n ++ " " ++ s ++ ")" It's pretty concise, but it's horribly inefficient due to the use of (++). Then, there's the ShowS approach. > ex2 = showChar '(' . shows n . showChar ' ' . showString s . showChar ')' $ "" This is more efficient, but now the code has bloated up a lot. Why can't I have my cake and eat it, too? I want to write with as little code as |ex1| (or less if possible), and I want it to be as efficient as |ex2|. I propose this example as an improvement. > ex3 = '(' .+. n .+. ' ' .+. s .$. ')' It uses a class I'm calling |Shows|. The class has one method that simply converts a value to the type |ShowS|, where |ShowS| is a type synonym for |String -> String| and is defined in the Prelude. > class Shows a where > toShows :: a -> ShowS Notice the lack of context involving the |Show| class. That's important, because it allows us to create more instances than we could if we were restricted by |(Show a) => ...|, esp. the |ShowS| instance below. The instances for types are all very simple. Most will appear like the instance for |Int|. > instance Shows Int where > toShows = shows Since we don't have |Show| in the class context above, we can't make this a default method. We need a few special instances for |Char| and |String| to make these types convenient to use in the expected way. > instance Shows Char where > toShows = showChar > instance Shows String where > toShows = showString We also need an instance for |ShowS| in order to facilitate concatenation. > instance Shows ShowS where > toShows = id Now, we define a few operators that use |toShows| and make our lives easier and our code more concise. The |(.+.)| replaces list appending, |(++)|, in |ex1| and function composition, |.|, in |ex2|. > infixl 5 .+. > (.+.) :: (Shows a, Shows b) => a -> b -> ShowS > a .+. b = toShows a . toShows b The |(.$.)| replaces the need for |($)| in |ex2|. > infixl 4 .$. > (.$.) :: (Shows a, Shows b) => a -> b -> String > a .$. b = (a .+. b) "" I would find something like this very useful. I'm guessing the idea can be applied to |ByteString| as well. Does it exist in some other form? Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080905/f6f79311/attachment.htm From droundy at darcs.net Fri Sep 5 11:14:44 2008 From: droundy at darcs.net (David Roundy) Date: Fri Sep 5 11:12:42 2008 Subject: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption? In-Reply-To: <1220576196-sup-4259@existential.local> References: <1220565162.13526.7.camel@flippa-eee> <1220576196-sup-4259@existential.local> Message-ID: <20080905151442.GJ31936@darcs.net> On Thu, Sep 04, 2008 at 08:04:25PM -0500, Austin Seipp wrote: > Excerpts from Justin Bailey's message of Thu Sep 04 17:00:58 -0500 2008: > > > Looking at the package, I think would be pretty painful though. It > > seems I'd have to build the AST by hand, > > The AST Language.C defines for C is actually fairly regular once you > wrap your head around it - I got it to generate working programs that > I could compile in approximately an hour after looking through nothing > but the documentation, essentially. > > The AST is very 'raw' though: I found that defining some simple > functions for things like just creating a global variable, creating > declarations and the like cut down on overall AST size tremendously > (although hints of the AST types/constructors were still around, naturally.) > > Here's the example I put on HPaste a few days ago: > > http://hpaste.org/10059#a1 > > You'll notice that the actual shim you're looking at - with the help > of the defined functions - is actually fairly small, and those > functions help out with those *a lot.* That was the first thing I > wrote with it though, so the functions could probably be further > generalized and abstracted. Nice. > On that note (although a little OT,) does anybody think it would be > nice to have a higher level library designed specifically around > emitting C that uses Language.C? A lot of repetetive stuff can be cut > down considerably, I think. That sounds great to me. I'd love to see something like this with some handy classes, so that I could write my haskell code using Int and/or Integer rather than CInt. e.g. change mkConst (ConInt i) = CConst $ CIntConst (cInteger i) undef mkConst (ConChar c) = CConst $ CCharConst (cChar c) undef mkConst (ConFloat f) = CConst $ CFloatConst (readCFloat f) undef mkConst (ConStr s) = CConst $ CStrConst (cString s) undef to class CConst i where mkConst i :: ??? instance CConst Int instance CConst Double etc. David From bos at serpentine.com Fri Sep 5 12:45:47 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Sep 5 12:43:52 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters) In-Reply-To: <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: On Fri, Sep 5, 2008 at 5:04 AM, Claus Reinke wrote: > Seriously, though, what is the RWH authors' plan for tackling > the eternal frustration of Haskell book authors, a moving target? Other tech books face the same problem, which, if they sell successfully and the authors haven't moved into caves afterwards to recover, they address with subsequent editions. If readers find that specific pieces of information have bitrotted, I'm sure we'll hear about it. In that case, we'll create a wiki page with errata, and link to it from the book site. From bos at serpentine.com Fri Sep 5 13:07:27 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Sep 5 13:05:33 2008 Subject: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters In-Reply-To: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> Message-ID: On Fri, Sep 5, 2008 at 3:45 AM, david48 wrote: > In the online version of Real world Haskell, there's a problem with > examples in ghci when the module Database.HDBC.Sqlite3 is imported. Oops, should be fixed now. From jeanphilippe.bernardy at gmail.com Fri Sep 5 14:15:28 2008 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Fri Sep 5 14:13:46 2008 Subject: [Haskell-cafe] Re: Functional references References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> <48C0F69F.5010903@jellybean.co.uk> Message-ID: > I think it would be worth spending some time (on this mailing list, > perhaps, or in another forum) trying to hash out a decent API which > meets most people's requirements, rather than ending up with 4 or 5 > slightly different ones. Indeed. I have my own version here: http://code.haskell.org/yi/Yi/Accessor.hs I'd rather use a standard package, but I could not contact the author of the data-accessor package to join efforts. Cheers -- JP From ganesh at earth.li Fri Sep 5 14:51:57 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Fri Sep 5 14:49:59 2008 Subject: [Haskell-cafe] Functional references In-Reply-To: <48C0F69F.5010903@jellybean.co.uk> References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> <48C0F69F.5010903@jellybean.co.uk> Message-ID: On Fri, 5 Sep 2008, Jules Bean wrote: > I think it would be worth spending some time (on this mailing list, > perhaps, or in another forum) trying to hash out a decent API which > meets most people's requirements, rather than ending up with 4 or 5 > slightly different ones. This sounds like a good plan, but please make sure the result is as free as GHC, rather than GPL like data-accessor is. It's so simple that it being GPL just drives people for whom licencing is an issue to write an alternative rather than consider complying. Ganesh From wren at freegeek.org Fri Sep 5 15:05:11 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Sep 5 15:03:16 2008 Subject: [Haskell-cafe] Re: Functional references In-Reply-To: References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> <48C0F69F.5010903@jellybean.co.uk> Message-ID: <49541.69.250.26.104.1220641511.squirrel@mail.freegeek.org> Jean-Philippe Bernardy wrote: >> I think it would be worth spending some time (on this mailing list, >> perhaps, or in another forum) trying to hash out a decent API which >> meets most people's requirements, rather than ending up with 4 or 5 >> slightly different ones. > > Indeed. I have my own version here: > > http://code.haskell.org/yi/Yi/Accessor.hs > > I'd rather use a standard package, but I could not contact the author of the > data-accessor package to join efforts. I too have a home-rolled version nearly identical to this one. The only real difference is using a (whole -> part -> whole) modifier instead of ((part -> part) -> whole -> whole) in the dictionary type. That decision was salient for my particular uses, but on the whole I like the Yi.Accessor approach better. For an official API, I think a (setter = modifier . const) function would be helpful for brevity and clarity. The other difference, in terms of API, is I was using names "theX" and "resetX" rather than "getter" and "modifier" (I also have a "setX" which requires a class declaring an emptyX value for the whole type). I'm not too invested in my particular names, but I think having something short which isn't too evocative of the StateMonad is important. The reason I think it shouldn't be too evocative of State is that the functions are pure and keeping their names distinct gives a good mnemonic to remember which ones are State-ful and which ones are pure. Tim Newsham's approach with invertible functions is interesting, though it feels like it's another layer wrapped on top of the primitive idea of functional references. My code also had an extra layer lifting the explicit dictionaries into type class dictionaries. This was helpful for writing functions which are polymorphic over the state type, though it suffers from the limitation that you can only have a single accessor for each part type in a given whole type. -- Live well, ~wren From ashley at semantic.org Fri Sep 5 15:18:25 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Sep 5 15:16:29 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> References: <534781822.20080826190130@gmail.com> <48BD085A.9090309@semantic.org> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> Message-ID: <48C18601.4050801@semantic.org> Sittampalam, Ganesh wrote: > Ashley Yakeley wrote: > >> I really don't know enough about the RTS to know. The >> alternative would be to keep all initialised values >> when the module is unloaded. I'm guessing this is more >> feasible. > > Easier, but a guaranteed memory leak. But it's limited to the initialisers. An IORef holding an Integer isn't much memory, and it only ever gets leaked once. -- Ashley Yakeley From wren at freegeek.org Fri Sep 5 15:32:12 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Sep 5 15:30:16 2008 Subject: [Haskell-cafe] Reducing code for efficient ShowS In-Reply-To: <3c6288ab0809050711x70ae0003h28fdb7817003d9db@mail.gmail.com> References: <3c6288ab0809050711x70ae0003h28fdb7817003d9db@mail.gmail.com> Message-ID: <49656.69.250.26.104.1220643132.squirrel@mail.freegeek.org> Sean Leather wrote: > There's the obvious approach that's described in every tutorial, book, and > research paper (for didactic purposes, of course). > >> ex1 = "(" ++ show n ++ " " ++ s ++ ")" > > It's pretty concise, but it's horribly inefficient due to the use of (++). > > Then, there's the ShowS approach. > >> ex2 = showChar '(' . shows n . showChar ' ' . showString s . showChar ')' > $ "" > > This is more efficient, but now the code has bloated up a lot. > > Why can't I have my cake and eat it, too? I want to write with as little > code as > |ex1| (or less if possible), and I want it to be as efficient as |ex2|. > > I propose this example as an improvement. > >> ex3 = '(' .+. n .+. ' ' .+. s .$. ')' Why not use the dlist library: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist With something like (untested code): > xs +++ ys = shows xs `append` shows ys > x .++ ys = showChar x `cons` shows ys > xs ++. y = shows xs `snoc` showChar y > > ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')' -- Live well, ~wren From ganesh at earth.li Fri Sep 5 15:34:17 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Fri Sep 5 15:32:20 2008 Subject: [Haskell-cafe] Top Level <- In-Reply-To: <48C18601.4050801@semantic.org> References: <534781822.20080826190130@gmail.com> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> Message-ID: On Fri, 5 Sep 2008, Ashley Yakeley wrote: > Sittampalam, Ganesh wrote: >> Ashley Yakeley wrote: >> >>> I really don't know enough about the RTS to know. The alternative >>> would be to keep all initialised values when the module is unloaded. >>> I'm guessing this is more feasible. >> >> Easier, but a guaranteed memory leak. > > But it's limited to the initialisers. An IORef holding an Integer isn't > much memory, and it only ever gets leaked once. It happens every time you load and unload, surely? Also I thought this was a general discussion with Data.Unique as a concrete example; something else might leak substantially more memory. Your witnesses stuff would leak one Integer per module, wouldn't it? Finally, any memory leak at all can be unacceptable in some contexts. It's certainly not something we should just dismiss as "oh, it's only small". Cheers, Ganesh From claus.reinke at talk21.com Fri Sep 5 15:55:51 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 5 15:54:00 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online RealWorld Haskell, problem with Sqlite3 chapters) References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com><48C1128A.2040804@tcs.inf.tu-dresden.de><8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: >> Seriously, though, what is the RWH authors' plan for tackling >> the eternal frustration of Haskell book authors, a moving target? > > Other tech books face the same problem, which, if they sell > successfully and the authors haven't moved into caves afterwards to > recover, they address with subsequent editions. If readers find that > specific pieces of information have bitrotted, I'm sure we'll hear > about it. In that case, we'll create a wiki page with errata, and link > to it from the book site. Just saying, it is worth planning for, especially if the book is going to be successful. I understand if creating that book at breakneck speed has left you looking forward to a break (not of the neck;-), but laying out a strategy for this, and putting it in the preface, might avoid sorrows later. You do have the online version and commenting system in place which you could keep around, you could even keep copies of the precise code versions you use, although adapting the text is more appropriate for this style of book. Thompson and Hudak both have had home pages for their books, but that didn't prevent their readers coming to the mailing lists instead, often frustrated at the beginning of their threads, sometimes disappointed at the end (in spite of a succession of strong Haskell hackers reviving SOE support again and again, there were gaps in between). And your book looks like it is going to suffer more, being completed before, but published after several changes (more base breakup, last time that extralibs come with ghc, haskell platform, extensible exceptions, ..) as well as being detailed and concrete about the use of several real-world libraries/tools subject to normal evolution. Anyway, good luck!-) Claus From lemming at henning-thielemann.de Fri Sep 5 16:39:52 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Sep 5 16:37:58 2008 Subject: [Haskell-cafe] Functional references In-Reply-To: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> Message-ID: On Thu, 4 Sep 2008, Ryan Ingram wrote: > Nice. I've written similar stuff a couple of times before, but the > formulation using Maybe and modify definitely solves some problems I > started to notice as I used it on bigger structures. However, it > might be better to separate a class of "never failing" references, > where the reader is guaranteed to succeed, from "potentially failing" > references which give a Maybe value. > > I'd also not use the names "get" and "modify" because they are already > used by MonadState. I always used "frGet", "frSet", and "frModify", > and then tended to not use them directly as I was generally working in > a state monad. Haskell already supports qualification, why manual prefixing? From lemming at henning-thielemann.de Fri Sep 5 16:42:46 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Sep 5 16:40:50 2008 Subject: [Haskell-cafe] Re: Functional references In-Reply-To: References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> <48C0F69F.5010903@jellybean.co.uk> Message-ID: On Fri, 5 Sep 2008, Jean-Philippe Bernardy wrote: > >> I think it would be worth spending some time (on this mailing list, >> perhaps, or in another forum) trying to hash out a decent API which >> meets most people's requirements, rather than ending up with 4 or 5 >> slightly different ones. > > Indeed. I have my own version here: > > http://code.haskell.org/yi/Yi/Accessor.hs > > I'd rather use a standard package, but I could not contact the author of the > data-accessor package to join efforts. I had no problem contacting Luke Palmer and I have recently added my stuff to the package. See also http://www.haskell.org/haskellwiki/Record_access You may add the other existing packages for reference. From allbery at ece.cmu.edu Fri Sep 5 17:46:44 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Sep 5 17:45:00 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters) In-Reply-To: References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: <21ED0677-155B-42AE-A2BC-B9853AAAE7BD@ece.cmu.edu> On 2008 Sep 5, at 12:45, Bryan O'Sullivan wrote: > On Fri, Sep 5, 2008 at 5:04 AM, Claus Reinke > wrote: >> Seriously, though, what is the RWH authors' plan for tackling >> the eternal frustration of Haskell book authors, a moving target? > > Other tech books face the same problem, which, if they sell > successfully and the authors haven't moved into caves afterwards to > recover, they address with subsequent editions. If readers find that Errata pages are common; as authors become more aware of the Internet, they often put updates in the same place. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dons at galois.com Fri Sep 5 17:49:52 2008 From: dons at galois.com (Don Stewart) Date: Fri Sep 5 17:47:55 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters) In-Reply-To: <21ED0677-155B-42AE-A2BC-B9853AAAE7BD@ece.cmu.edu> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> <21ED0677-155B-42AE-A2BC-B9853AAAE7BD@ece.cmu.edu> Message-ID: <20080905214952.GB11110@scytale.galois.com> allbery: > On 2008 Sep 5, at 12:45, Bryan O'Sullivan wrote: > >On Fri, Sep 5, 2008 at 5:04 AM, Claus Reinke > > wrote: > >>Seriously, though, what is the RWH authors' plan for tackling > >>the eternal frustration of Haskell book authors, a moving target? > > > >Other tech books face the same problem, which, if they sell > >successfully and the authors haven't moved into caves afterwards to > >recover, they address with subsequent editions. If readers find that > > Errata pages are common; as authors become more aware of the Internet, > they often put updates in the same place. And our book is online already, and accepts comments :-) -- Don From leather at cs.uu.nl Fri Sep 5 18:28:14 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Sep 5 18:26:16 2008 Subject: [Haskell-cafe] Reducing code for efficient ShowS In-Reply-To: <3c6288ab0809051526m6b80bde3q61b12f30f13af42e@mail.gmail.com> References: <3c6288ab0809050711x70ae0003h28fdb7817003d9db@mail.gmail.com> <49656.69.250.26.104.1220643132.squirrel@mail.freegeek.org> <3c6288ab0809051526m6b80bde3q61b12f30f13af42e@mail.gmail.com> Message-ID: <3c6288ab0809051528w5fe22422xb5d3b5cd60f1d5c1@mail.gmail.com> > Why not use the dlist library: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist > > With something like (untested code): > > > xs +++ ys = shows xs `append` shows ys > > x .++ ys = showChar x `cons` shows ys > > xs ++. y = shows xs `snoc` showChar y > > > > ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')' > I think you're missing the fromList parts among other things. That's an interesting idea. It appears to use the same idea as ShowS, but more generally with lists and not just strings. I think there's an added benefit to not having to remember the the type of the value being appended. It's one of the more convenient things about many dynamically typed languages. So, I would still vote for the class-based method, so that I can use (.+.) for both Char and everything else. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080906/bd39278e/attachment.htm From wren at freegeek.org Fri Sep 5 18:47:07 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Sep 5 18:45:10 2008 Subject: [Haskell-cafe] Reducing code for efficient ShowS In-Reply-To: <3c6288ab0809051526m6b80bde3q61b12f30f13af42e@mail.gmail.com> References: <3c6288ab0809050711x70ae0003h28fdb7817003d9db@mail.gmail.com> <49656.69.250.26.104.1220643132.squirrel@mail.freegeek.org> <3c6288ab0809051526m6b80bde3q61b12f30f13af42e@mail.gmail.com> Message-ID: <50961.69.250.26.104.1220654827.squirrel@mail.freegeek.org> Sean Leather wrote: >> Why not use the dlist library: >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist >> >> With something like (untested code): >> >> > xs +++ ys = shows xs `append` shows ys >> > x .++ ys = showChar x `cons` shows ys >> > xs ++. y = shows xs `snoc` showChar y >> > >> > ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')' >> > > I think you're missing the fromList parts among other things. Ah yes, dlist uses a newtype instead of an alias so `shows` isn't enough. There's also the question of where exactly to hide the (Show a => a -> DList Char) conversions if you want to be more succinct than the (++) route. > That's an interesting idea. It appears to use the same idea as ShowS, but > more generally with lists and not just strings. The difference-list approach to solving the appending problem is classic. There's a variant for unification-based logic languages as well. Both are functional takes on the imperative approach of keeping a tail pointer. Dons just took the time to package it up for us all :) > I think there's an added benefit to not having to remember the the type of > the value being appended. It's one of the more convenient things about many > dynamically typed languages. So, I would still vote for the class-based > method, so that I can use (.+.) for both Char and everything else. Sure. If you're planning on releasing the code, I'd suggest a different spelling of (.+.) though. The (.X.) pattern for a family of operators is pretty common, so it's good to avoid it for modules that want to be used in combination with many others. YMMV and all that. -- Live well, ~wren From leather at cs.uu.nl Fri Sep 5 19:09:55 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Sep 5 19:07:58 2008 Subject: [Haskell-cafe] Reducing code for efficient ShowS In-Reply-To: <50961.69.250.26.104.1220654827.squirrel@mail.freegeek.org> References: <3c6288ab0809050711x70ae0003h28fdb7817003d9db@mail.gmail.com> <49656.69.250.26.104.1220643132.squirrel@mail.freegeek.org> <3c6288ab0809051526m6b80bde3q61b12f30f13af42e@mail.gmail.com> <50961.69.250.26.104.1220654827.squirrel@mail.freegeek.org> Message-ID: <3c6288ab0809051609q2b73e80cj9ebdbbcbf26881dc@mail.gmail.com> > > That's an interesting idea. It appears to use the same idea as ShowS, but > > more generally with lists and not just strings. > > The difference-list approach to solving the appending problem is classic. > There's a variant for unification-based logic languages as well. Both are > functional takes on the imperative approach of keeping a tail pointer. > Dons just took the time to package it up for us all :) > Yes, I've seen it before in UU.DData.Seq. Though, where it was that I originally found it, I don't remember, but it wasn't the uulib. I didn't know what a "difference list" was, so I didn't pay much attention when Don released it. http://hackage.haskell.org/packages/archive/uulib/0.9.5/doc/html/UU-DData-Seq.html If you're planning on releasing the code, I'd suggest a different spelling > of (.+.) though. The (.X.) pattern for a family of operators is pretty > common, so it's good to avoid it for modules that want to be used in > combination with many others. YMMV and all that. > That sounds reasonable. My only motivations were to keep the operators short, sweet, and somewhat representative. Any suggestions are welcome. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080906/8530e5c1/attachment.htm From ryani.spam at gmail.com Fri Sep 5 19:21:29 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Sep 5 19:19:32 2008 Subject: [Haskell-cafe] Functional references In-Reply-To: References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> Message-ID: <2f9b2d30809051621k61736c2eme380224b9f1baa1d@mail.gmail.com> On Fri, Sep 5, 2008 at 1:39 PM, Henning Thielemann wrote: > Haskell already supports qualification, why manual prefixing? This is just a stylistic opinion, but I absolutely hate "required" qualifications; it is a waste of typing and, in my opinion, it makes the resulting code look more cluttered and harder to read. It's especially bad when modules are extremely likely to be used together, like Control.Monad.State & FRef, or Data.Map & the Prelude. You end up being required to import one or the other qualified. I direct you to my proposal for ad-hoc overloading, recently discussed on this list, as a way to solve this problem. In my experience, the code is almost always unambiguous without the qualification because using the "wrong" operator would fail to typecheck. In this case, I agree that manual prefixing isn't really better, but using ugly names encourages people to find better ones. I couldn't think of any off the top of my head, but I wasn't trying very hard. -- ryan From wnoise at ofb.net Fri Sep 5 19:36:16 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Sep 5 19:34:27 2008 Subject: [Haskell-cafe] Re: 2 modules in one file References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> <48B575DF.8000300@cs.nott.ac.uk> <9A31DE7E-0C6A-4BCB-B528-07C267574D5C@ece.cmu.edu> Message-ID: On 2008-08-30, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 30, at 4:22, Aaron Denney wrote: >> On 2008-08-27, Henrik Nilsson wrote: >>> And there are also potential issues with not every legal module name >>> being a legal file name across all possible file systems. >> >> I find this unconvincing. Broken file systems need to be fixed. > > Language people trying to impose constraints on filesystems is the > tail wagging the dog. I'd say it's just the opposite. The purpose of a filesystem is to hold user data, in ways convenient to the user, which means dictating a usable interface. Dictating the implementation would be closer to tail wagging the dog, though even that's not quite the right metaphor -- it's just a layering violation. The user is in this case GHC or other compiler adopting the suggestion in the Hierarchical modules extension. Just as non-hierarchical file systems have long been considered broken, I think it's safe to now declare that one that doesn't support unicode in some fashion, even if only a userland convention of using UTF-8, is indeed less usable, and hence broken. -- Aaron Denney -><- From allbery at ece.cmu.edu Fri Sep 5 19:53:33 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Sep 5 19:51:40 2008 Subject: [Haskell-cafe] Re: 2 modules in one file In-Reply-To: References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> <48B575DF.8000300@cs.nott.ac.uk> <9A31DE7E-0C6A-4BCB-B528-07C267574D5C@ece.cmu.edu> Message-ID: <744DF7A2-5478-4119-8C5A-A2CEBF42FFEE@ece.cmu.edu> On 2008 Sep 5, at 19:36, Aaron Denney wrote: > On 2008-08-30, Brandon S. Allbery KF8NH wrote: >> On 2008 Aug 30, at 4:22, Aaron Denney wrote: >>> On 2008-08-27, Henrik Nilsson wrote: >>>> And there are also potential issues with not every legal module >>>> name >>>> being a legal file name across all possible file systems. >>> >>> I find this unconvincing. Broken file systems need to be fixed. >> >> Language people trying to impose constraints on filesystems is the >> tail wagging the dog. > > I think it's safe to now declare that one that doesn't support unicode > in some fashion, even if only a userland convention of using UTF-8, is > indeed less usable, and hence broken. It's not just UTF-8; Windows filesystems restrict a number of special characters (I don't think any are significant for module naming, but I can't swear to it either off the top of my head). Is this broken? If so, what do you think the chances are of getting it fixed? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From newsham at lava.net Fri Sep 5 20:24:39 2008 From: newsham at lava.net (Tim Newsham) Date: Fri Sep 5 20:22:44 2008 Subject: [Haskell-cafe] Functional references In-Reply-To: <2f9b2d30809051621k61736c2eme380224b9f1baa1d@mail.gmail.com> References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> <2f9b2d30809051621k61736c2eme380224b9f1baa1d@mail.gmail.com> Message-ID: > It's especially bad when modules are extremely likely to be used > together, like Control.Monad.State & FRef, or Data.Map & the Prelude. > You end up being required to import one or the other qualified. I think in the case of State vs. FRef a simple solution is to make two modules: FRef, which uses "get" and "set" and "modify" naturally, and FRef.State which defines State equivalents without polluting the namespace. Then if you're working with pure functions you can import FRef and use the natural names, and when you're using the State monad you can import FRef.State and get the State definitions that dont interfere with the standard "get" and "modify" names. In the rare case (I think, am I wrong?) where you use both State and FRef "modify" and "get" definitions in the same file, you can import the one you use less off qualified... > -- ryan Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Fri Sep 5 21:38:28 2008 From: dons at galois.com (Don Stewart) Date: Fri Sep 5 21:36:26 2008 Subject: [Haskell-cafe] ANNOUNCE: xmonad 0.8 released! Message-ID: <20080906013828.GB11490@scytale.galois.com> http://xmonad.org The xmonad dev team is pleased to announce xmonad 0.8! The headlines: * A general purpose replacement for "gaps" has been adopted. * Floating windows pop up on the current screen by default * Locale support * Rock solid code: No new crash-inducing bugs reported in this release cycle * Many new extensions, including the ability to write your own configuration parsers. * The 1000th commit was made to the project Change logs: http://haskell.org/haskellwiki/Xmonad/Notable_changes_since_0.7 About: 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, tabbing and decorated windows * Full support for Gnome and KDE utilities * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Compositing support * Powerful, stable customisation and reconfiguration * Large extension library * Excellent, extensive documentation * Large, active development team, support and community Get it! Information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.8 release, and its dependencies, are available from hackage.haskell.org: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad xmonad packages are available in the package systems of at least: Debian, Gentoo, Arch, Ubuntu, OpenBSD, NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware and 0.8 packages will appear in coming days (some are already available). On the fly updating to xmonad 0.8 is supported. You can even use cabal-install: $ cabal update $ cabal install xmonad-0.8 $ cabal install xmonad-contrib-0.8 $ xmonad --recompile mod-q Extensions: xmonad comes with a huge library of extensions (now around 9 times the size of xmonad itself), 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 David Roundy Brent Yorgey Devin Mullins Braden Shepherdson Roman Cheplyaka Lukas Mai Featuring code contributions from over 60 developers: Aaron Denney Adam Vogt Alec Berryman Alex Tarkovsky Alexandre Buisse Andrea Rossato Austin Seipp Bas van Dijk Ben Voui Brandon Allbery Chris Mears Christian Thiemann Clemens Fruhwirth Daniel Neri Daniel Wagner Dave Harrison David Glasser David Lazar Dmitry Kurochkin Dominik Bruhn Dougal Stanton Eric Mertens Ferenc Wagner Gwern Branwen Hans Philipp Annen Ivan Tarasov Ivan Veselov Jamie Webb Jeremy Apthorp Malebria Joachim Breitner Joachim Fasting Joe Thornber Joel Suovaniemi Juraj Hercek Justin Bogner Kai Grossjohann Karsten Schoelzel Klaus Weidner Mathias Stearn Mats Jansborg Matsuyama Tomohiro Michael Fellinger Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Nicolas Pouillard Nils Anders Danielsson Peter De Wachter Robert Marlow Sam Hughes Shachaf Ben-Kiki Shae Erisson Simon Peyton Jones Stefan O'Rear Tom Rauchenwald Valery V. Vorotyntsev Will Farrington Yaakov Nemoy timthelion Rickard Gustafson Trevor Elliott Ian Zerny Ivan Miljenovic Marco e Silva Michal Janeczek 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! From derek.a.elkins at gmail.com Fri Sep 5 22:23:14 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Sep 5 22:21:21 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> Message-ID: <1220667794.5774.23.camel@derek-laptop> On Thu, 2008-09-04 at 08:19 -0700, Tim Chevalier wrote: > On 9/3/08, wren ng thornton wrote: > > If you want the datatype to be strict in state and rec, then you should add > > strictness annotations to those fields directly: > > > > data Query state rec = Query !state !rec > > The novice programmer scatters strictness annotations to and fro like > dust in the wind. The average programmer understands that annotating a > field's strictness injudiciously is like discarding the finger > pointing at the moon when you might still need it to scratch yourself. > The master programmer does not add strictness annotations, for she has > not yet run the profiler. This attitude is wrong. Many potentially significant performance problems can easily be spotted and solved during construction without affecting the readability of the code, problems that would be much harder to diagnose at the end running a profiler. This is especially crucial for library code. The users of the library may be the ones that find the easily resolved space leak your profiling didn't reveal and now they can't do anything about it until a new version is released e.g. Data.Map.insertWith. A performance problem that renders your code unusable is a bug and catching it early or not making it in the first place is much better than catching it late. A (highly related) analogy would be telling Scheme programmers (or Haskell programmers for that matter) not to use to tail recursive code until a profiler tells them to and transforming to a tail recursive style is much more intrusive than adding a strictness annotation. Highly competent Haskell programmers add strictness annotations relatively systematically. The details of mixing eager and lazy code is one of the significant contributions to the pragmatics of programming lazy functional languages have made. At another extreme, things like Chris Okasaki's data structures rely on a specific balance of eagerness and laziness. Also, it is easier (as in not impossible) to turn a strict in the elements data structure into a lazy one than the other way around. Eager by default or lazy by default are both have (actually dual) pitfalls that are best solved by a laziness or strictness annotation respectively. There is no need to walk into those pitfalls with your eyes wide open. From derek.a.elkins at gmail.com Fri Sep 5 22:50:28 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Sep 5 22:48:34 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online RealWorld Haskell, problem with Sqlite3 chapters) In-Reply-To: References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: <1220669429.5774.32.camel@derek-laptop> On Fri, 2008-09-05 at 20:55 +0100, Claus Reinke wrote: > >> Seriously, though, what is the RWH authors' plan for tackling > >> the eternal frustration of Haskell book authors, a moving target? > > > > Other tech books face the same problem, which, if they sell > > successfully and the authors haven't moved into caves afterwards to > > recover, they address with subsequent editions. If readers find that > > specific pieces of information have bitrotted, I'm sure we'll hear > > about it. In that case, we'll create a wiki page with errata, and link > > to it from the book site. > > Just saying, it is worth planning for, especially if the book is > going to be successful. I understand if creating that book at > breakneck speed has left you looking forward to a break (not > of the neck;-), but laying out a strategy for this, and putting it in > the preface, might avoid sorrows later. You do have the online > version and commenting system in place which you could keep > around, you could even keep copies of the precise code versions > you use, although adapting the text is more appropriate for this > style of book. To make what (I believe) Claus is saying more explicit and direct, add a note to the beginning of the book (or somewhere reasonably prominent) that states something along the lines: "As time progresses parts of this book are going to become out-of-date, in particular code examples will. See for errata or read the comments for that section on the online version of the book for details resolving these issues. Alternatively, send an email to ." I would recommend having a mailing list or some such as then you can potentially leverage the community to resolve such issues leading to less pressure on you three and likely faster responses. From catamorphism at gmail.com Fri Sep 5 23:11:37 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Sep 5 23:09:41 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <1220667794.5774.23.camel@derek-laptop> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <1220667794.5774.23.camel@derek-laptop> Message-ID: <4683d9370809052011v794847e0p6f50e8ce324ff220@mail.gmail.com> On Fri, Sep 5, 2008 at 7:23 PM, Derek Elkins wrote: > > This attitude is wrong. Many potentially significant performance > problems can easily be spotted and solved during construction without > affecting the readability of the code, problems that would be much > harder to diagnose at the end running a profiler. This is especially > crucial for library code. The users of the library may be the ones that > find the easily resolved space leak your profiling didn't reveal and now > they can't do anything about it until a new version is released e.g. > Data.Map.insertWith. A performance problem that renders your code > unusable is a bug and catching it early or not making it in the first > place is much better than catching it late. > Library writers don't write applications that use their code as part of the testing process? > A (highly related) analogy would be telling Scheme programmers (or > Haskell programmers for that matter) not to use to tail recursive code > until a profiler tells them to and transforming to a tail recursive > style is much more intrusive than adding a strictness annotation. > Tail recursion isn't always a win in Haskell. I'm not much in touch with the Scheme world, so can't speak to that. > Highly competent Haskell programmers add strictness annotations > relatively systematically. The details of mixing eager and lazy code is > one of the significant contributions to the pragmatics of programming > lazy functional languages have made. At another extreme, things like > Chris Okasaki's data structures rely on a specific balance of eagerness > and laziness. > > Also, it is easier (as in not impossible) to turn a strict in the > elements data structure into a lazy one than the other way around. > > Eager by default or lazy by default are both have (actually dual) > pitfalls that are best solved by a laziness or strictness annotation > respectively. There is no need to walk into those pitfalls with your > eyes wide open. That may be, but are the holes that one falls into due to unexpected laziness and the ones that one falls into due to unexpected strictness equally numerous? Are they equally deep? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. From derek.a.elkins at gmail.com Sat Sep 6 00:32:41 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Sep 6 00:30:46 2008 Subject: [haskell-cafe] Monad and kinds In-Reply-To: <4683d9370809052011v794847e0p6f50e8ce324ff220@mail.gmail.com> References: <48BD40F1.6050905@gmail.com> <48BF562C.2020408@freegeek.org> <4683d9370809040819u2e2e2e6ega849bb31f39e7b99@mail.gmail.com> <1220667794.5774.23.camel@derek-laptop> <4683d9370809052011v794847e0p6f50e8ce324ff220@mail.gmail.com> Message-ID: <1220675561.5774.64.camel@derek-laptop> On Fri, 2008-09-05 at 20:11 -0700, Tim Chevalier wrote: > On Fri, Sep 5, 2008 at 7:23 PM, Derek Elkins wrote: > > > > This attitude is wrong. Many potentially significant performance > > problems can easily be spotted and solved during construction without > > affecting the readability of the code, problems that would be much > > harder to diagnose at the end running a profiler. This is especially > > crucial for library code. The users of the library may be the ones that > > find the easily resolved space leak your profiling didn't reveal and now > > they can't do anything about it until a new version is released e.g. > > Data.Map.insertWith. A performance problem that renders your code > > unusable is a bug and catching it early or not making it in the first > > place is much better than catching it late. > > > > Library writers don't write applications that use their code as part > of the testing process? They don't use their libraries in every conceivable way. > > > A (highly related) analogy would be telling Scheme programmers (or > > Haskell programmers for that matter) not to use to tail recursive code > > until a profiler tells them to and transforming to a tail recursive > > style is much more intrusive than adding a strictness annotation. > > > > Tail recursion isn't always a win in Haskell. I'm very well aware of that. Due to the extremely close relationship with when to tail recursion and when to use laziness, your original statement almost obligates you to also believe that "masters" don't write tail recursive code until after profiling. > I'm not much in touch > with the Scheme world, so can't speak to that. Stick in any strict functional language or any other strict language (preferably higher order, but that isn't really important) that also supports tail call optimization. > > > Highly competent Haskell programmers add strictness annotations > > relatively systematically. The details of mixing eager and lazy code is > > one of the significant contributions to the pragmatics of programming > > lazy functional languages have made. At another extreme, things like > > Chris Okasaki's data structures rely on a specific balance of eagerness > > and laziness. > > > > Also, it is easier (as in not impossible) to turn a strict in the > > elements data structure into a lazy one than the other way around. > > > > Eager by default or lazy by default are both have (actually dual) > > pitfalls that are best solved by a laziness or strictness annotation > > respectively. There is no need to walk into those pitfalls with your > > eyes wide open. > > That may be, but are the holes that one falls into due to unexpected > laziness and the ones that one falls into due to unexpected strictness > equally numerous? Are they equally deep? As I said, this particular issue is a duality. For at least a certain class of problems, the ones most relevant here, the holes are equally deep and equally numerous. What is correct in one language is a problem in the other. For examples and more discussion see: http://lambda-the-ultimate.org/node/2273#comment-40156 These last questions, though, are both flawed and irrelevant. They are flawed because the issue isn't which is the default: having both available -at all- makes you vulnerable to the pitfalls of both. Here's a good example: compose = foldr (.) id or should it be compose = foldl' (.) id maybe something else? The fact that Haskell has both strict and non-strict functions makes neither of these implementations correct. It is irrelevant because all that needs to be shown is that there exist -any- problem that can easily be identified and fixed with a strictness annotation. The Haskell implementation of factorial in the above has such a bug, it can be fixed with the addition of two characters, $!, I don't need a profiler to tell me this, and for every standard numeric type there will be no change in semantics (where "semantics" here does not include "performance" aspects.) From bos at serpentine.com Sat Sep 6 00:38:04 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Sep 6 00:36:06 2008 Subject: the real world of Haskell books (Re: [Haskell-cafe] Online RealWorld Haskell, problem with Sqlite3 chapters) In-Reply-To: <1220669429.5774.32.camel@derek-laptop> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> <1220669429.5774.32.camel@derek-laptop> Message-ID: On Fri, Sep 5, 2008 at 7:50 PM, Derek Elkins wrote: > To make what (I believe) Claus is saying more explicit and direct, add a > note to the beginning of the book (or somewhere reasonably prominent) > that states something along the lines [...] We will add a link to an errata site in the final version. Thanks for the suggestion; it's an obvious thing to do in retrospect. From gour at mail.inet.hr Sat Sep 6 02:36:35 2008 From: gour at mail.inet.hr (Gour) Date: Sat Sep 6 02:34:46 2008 Subject: [Haskell-cafe] Re: the real world of Haskell books (Re: Online Real World Haskell, problem with Sqlite3 chapters) References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> <8D26BDBFF0F24D638F04E7A64132F451@cr3lt> Message-ID: <878wu54w7g.fsf@gaura-nitai.no-ip.org> >>>>> "Bryan" == Bryan O'Sullivan writes: Bryan> Other tech books face the same problem, which, if they sell Bryan> successfully and the authors haven't moved into caves afterwards Bryan> to recover, they address with subsequent editions. If readers Bryan> find that specific pieces of information have bitrotted, I'm sure Bryan> we'll hear about it. In that case, we'll create a wiki page with Bryan> errata, and link to it from the book site. I think we should be happy that RWH book is done and considering it is for 'real-world' users I'm sure they will find a way to cope for upgrading libs, non-working packages etc. "A blind uncle is better than no uncle" :-D Congrats to RWH's 'Gang od Three' ;) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080906/371f6b11/attachment.bin From kowey at darcs.net Sat Sep 6 03:12:04 2008 From: kowey at darcs.net (Eric Y. Kow) Date: Sat Sep 6 03:10:09 2008 Subject: [Haskell-cafe] darcs hacking sprint, venues confirmed! (25-26 October) Message-ID: <20080906071204.GI23865@Macintosh.local> Dear darcs users and Haskell hackers, Earlier I wrote an announcement for the darcs hacking sprint on 25-26 October. Tonight, I am delighted to announce that we have two venues confirmed for the sprint and one serious offer. Venues ------ We plan to host the sprint across three sites: * CONFIRMED: Brighton, UK (University of Brighton) * CONFIRMED: Portland, USA (Galois Connections) * likely: Paris, France (Universit? Paris Diderot) So if you were waiting to book tickets, this is the time! For more details, please see http://wiki.darcs.net/index.html/Sprints Agenda ------ During this first sprint, we shall be focusing our attention on the day to day performance issues that darcs users commonly face. This is what we are reaching for: 1. Fast network operations. We want to make it very pleasant for users to darcs get a repository and pull some patches to it over http and ssh. Git does this very well, and we plan to learn from them. 2. Cutting memory consumption. We want to profile the heck out of operations like darcs record, darcs convert and darcs whatsnew. What's eating up all the memory? And how can we can cut it down to size? 3. Responsiveness. Sometimes basic darcs commands can take long enough for programmers to lose their train of thought. We want to track down these lost seconds and kill that dreaded context switch. Of course, if you are interested in other areas, then you can work on those instead. Note that if you are new to the darcs code or to Haskell, there will also be a lot interesting jobs for you to get started with. Everyone will have something to hack on, so come join us! Thanks very much to the University of Brighton, Galois connections and University of Paris VII for their generous offers. Hope to see you there, everyone! :-) -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080906/01ea9721/attachment.bin From ashley at semantic.org Sat Sep 6 04:08:03 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Sep 6 04:06:09 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BE346E.2000503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B850@ELON17P32002A.csfb.cs-group.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> Message-ID: <48C23A63.7070806@semantic.org> Ganesh Sittampalam wrote: >> But it's limited to the initialisers. An IORef holding an Integer >> isn't much memory, and it only ever gets leaked once. > It happens every time you load and unload, surely? No. An initialiser is only ever run once per run of the RTS. > Also I thought this was a general discussion with Data.Unique as a > concrete example; something else might leak substantially more memory. > Your witnesses stuff would leak one Integer per module, wouldn't it? It would leak one Integer per IOWitness initialiser for the run of the RTS. > Finally, any memory leak at all can be unacceptable in some contexts. > It's certainly not something we should just dismiss as "oh, it's only > small". Since it's of the order of the number of uniquely identified initialisers, it's arguably not a memory leak so much as a static overhead. The only way to get a continuous leak is to load and unload an endless stream of _different_ modules, each with their own initialisers. -- Ashley Yakeley From ganesh at earth.li Sat Sep 6 04:15:52 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Sep 6 04:13:53 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <48C23A63.7070806@semantic.org> References: <534781822.20080826190130@gmail.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> Message-ID: On Sat, 6 Sep 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >>> But it's limited to the initialisers. An IORef holding an Integer isn't >>> much memory, and it only ever gets leaked once. > >> It happens every time you load and unload, surely? > > No. An initialiser is only ever run once per run of the RTS. Oh, I see. Yes, sorry. > Since it's of the order of the number of uniquely identified > initialisers, it's arguably not a memory leak so much as a static > overhead. The only way to get a continuous leak is to load and unload an > endless stream of _different_ modules, each with their own initialisers. I would call it a leak if something that is no longer being used cannot be reclaimed. The endless stream of different modules is possible in long-running systems where the code being run evolves or changes over time (e.g. something like lambdabot, which runs user-provided code). Cheers, Ganesh From ashley at semantic.org Sat Sep 6 06:10:17 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Sep 6 06:08:18 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> Message-ID: <48C25709.7040903@semantic.org> Ganesh Sittampalam wrote: > I would call it a leak if something that is no longer being used cannot > be reclaimed. The endless stream of different modules is possible in > long-running systems where the code being run evolves or changes over > time (e.g. something like lambdabot, which runs user-provided code). This might be fixable with an option to the dynamic load function. Let us say a module M has a number of top-level <- of the form val <- exp The set of ACIO expressions exp is the "static initialisers" of M. The RTS must note when each static initialiser is run, and cache its result val. Let's call this cache of vals the "static results cache" of M. When M is loaded, and a static results cache for M already exists, then it will be used for the vals of M. It is the static results cache that might leak. Let us have an flag to the dynamic load function, to mark the static results cache of M as "freeable". If the static results cache is freeable, then it will be deleted when M is unloaded (and M is not part of the main program). If you pass True for this flag, your code is unsafe if all of the following: * M has static initialisers * M will be loaded again after unloading * Values from M will be stored elsewhere in the program. If you pass False for this flag, your code will continuously leak memory if you continuously load modules * that are all different * that contain static initialisers There may also have to be some way to specify how to apply the flag to dependencies as well. In general I'm way beyond my knowledge of the RTS, so I may have something Very Wrong here. I don't think hs-plugins implements unloading at all currently. -- Ashley Yakeley From dons at galois.com Sat Sep 6 06:13:11 2008 From: dons at galois.com (Don Stewart) Date: Sat Sep 6 06:11:17 2008 Subject: [Haskell-cafe] Re: [xmonad] ANNOUNCE: xmonad 0.8 released! In-Reply-To: <1220695906.3365.4.camel@otto.ehbuehl.net> References: <20080906013828.GB11490@scytale.galois.com> <1220695906.3365.4.camel@otto.ehbuehl.net> Message-ID: <20080906101311.GB12228@scytale.galois.com> nomeata: > Hi, > > Am Freitag, den 05.09.2008, 18:38 -0700 schrieb Don Stewart: > > xmonad packages are available in the package systems of at least: > > > > Debian, Gentoo, Arch, Ubuntu, OpenBSD, > > NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware > > > > and 0.8 packages will appear in coming days (some are already available). > > Debian xmonad and xmonad-contrib package uploaded (although > xmonad-contrib is in the two-day delayed queue, to give autobuilders a > chance to build xmonad first). Great work, Joachim! Thanks for being so responsive on this. Go Debian! -- Don From d at vidplace.com Sat Sep 6 07:30:46 2008 From: d at vidplace.com (David F. Place) Date: Sat Sep 6 07:28:55 2008 Subject: [Haskell-cafe] What's the best way to give up? Message-ID: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> Hi, all. Say I have a function solve which is a constraint solver. It reconfigures its input to be a solution. If there is no solution, it returns the input. solve :: a -> Either a a solve input output = maybe (Left input) Right $ solve' input If there is a solution, it finds it in a few seconds. If there is no solution, it goes away for days proving that. So, I'd like to give up on it if it doesn't return in a few seconds. I can think of several ways of doing that. I could keep a tally of the number of variable assignments and give up when it reaches an impossibly huge number. I could change the type to a -> IO (Either a a ) and use getCPUTime. Is there a standard way to do this? Can you think of another way to do it? Cheers, David From tonyhannan2 at gmail.com Sat Sep 6 08:43:52 2008 From: tonyhannan2 at gmail.com (Tony Hannan) Date: Sat Sep 6 08:41:53 2008 Subject: [Haskell-cafe] GADTs and instances Message-ID: Hello haskellers, Anyone know the trick for making a Binary instance of a GADT. See sample code below followed by the type error reported by ghc version 6.8.3 Thanks, Tony ---- {-# LANGUAGE GADTs #-} module GADTTest where import Data.Binary import Control.Monad (liftM) data Query a where Lookup :: String -> Query (Maybe Int) Fetch :: [String] -> Query [Int] instance (Binary a) => Binary (Query a) where put (Lookup x) = putWord8 0 >> put x put (Fetch x) = putWord8 1 >> put x get = getWord8 >>= \tag -> case tag of 0 -> liftM Lookup get 1 -> liftM Fetch get ----- GADTTest.hs:12:0: Couldn't match expected type `Maybe Int' against inferred type `[Int]' When trying to generalise the type inferred for `get' Signature type: forall a. (Binary a) => Get (Query a) Type to generalise: Get (Query a) In the instance declaration for `Binary (Query a)' -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080906/e6c2ac63/attachment.htm From arnarbi at gmail.com Sat Sep 6 09:05:59 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Sat Sep 6 09:04:00 2008 Subject: [Haskell-cafe] What's the best way to give up? In-Reply-To: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> References: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> Message-ID: <28012bc60809060605o5fc85376l2377fd448267934@mail.gmail.com> Hi there, On Sat, Sep 6, 2008 at 13:30, David F. Place wrote: > If there is a solution, it finds it in a few seconds. If there is no > solution, it goes away for days proving that. So, I'd like to give up on it > if it doesn't return in a few seconds. I can think of several ways of > doing that. I could keep a tally of the number of variable assignments and > give up when it reaches an impossibly huge number. I could change the type > to > a -> IO (Either a a ) and use getCPUTime. > > Is there a standard way to do this? Can you think of another way to do it? I don't know, but this seems relevant: http://www.haskell.org/pipermail/haskell-cafe/2005-October/011946.html I'd make a generic (i.e. higher-order) function that handles the timeout for any computation. i.e. timeout :: (a -> b) -> Int -> a -> IO (Maybe b) or similar. Arnar From lane at downstairspeople.org Sat Sep 6 10:16:43 2008 From: lane at downstairspeople.org (Christopher Lane Hinson) Date: Sat Sep 6 10:14:45 2008 Subject: [Haskell-cafe] What's the best way to give up? In-Reply-To: <28012bc60809060605o5fc85376l2377fd448267934@mail.gmail.com> References: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> <28012bc60809060605o5fc85376l2377fd448267934@mail.gmail.com> Message-ID: >> a -> IO (Either a a ) and use getCPUTime. >> >> Is there a standard way to do this? Can you think of another way to do it? > > I don't know, but this seems relevant: > http://www.haskell.org/pipermail/haskell-cafe/2005-October/011946.html > > I'd make a generic (i.e. higher-order) function that handles the > timeout for any computation. i.e. > > timeout :: (a -> b) -> Int -> a -> IO (Maybe b) http://haskell.org/ghc/docs/latest/html/libraries/base/System-Timeout Perhaps this is for not so much for pure computations as hanging when connecting to nonresponsive servers, although I also use it in a case where buggy long-running code could frustrate the responsiveness of unrelated processes.. --Lane From allbery at ece.cmu.edu Sat Sep 6 11:05:47 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Sep 6 11:03:52 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <48C25709.7040903@semantic.org> References: <534781822.20080826190130@gmail.com> <48BE3F 95.9020503@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B852@ELON17P32002A.csfb.cs-group.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> Message-ID: On 2008 Sep 6, at 6:10, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> I would call it a leak if something that is no longer being used >> cannot be reclaimed. The endless stream of different modules is >> possible in long-running systems where the code being run evolves >> or changes over time (e.g. something like lambdabot, which runs >> user-provided code). > > This might be fixable with an option to the dynamic load function. > > Let us say a module M has a number of top-level <- of the form > > val <- exp > > The set of ACIO expressions exp is the "static initialisers" of M. > The RTS must note when each static initialiser is run, and cache its > result val. Let's call this cache of vals the "static results cache" > of M. > > When M is loaded, and a static results cache for M already exists, > then it will be used for the vals of M. This sounds "reachable" to me, and therefore static overhead and not a leak. Your proposed "freeable" flag is still useful, but I think this is not a problem. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Sat Sep 6 11:10:34 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Sep 6 11:08:38 2008 Subject: [Haskell-cafe] What's the best way to give up? In-Reply-To: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> References: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> Message-ID: On 2008 Sep 6, at 7:30, David F. Place wrote: > Say I have a function solve which is a constraint solver. It > reconfigures its input to be a solution. If there is no solution, > it returns the input. > > solve :: a -> Either a a > solve input output = maybe (Left input) Right $ solve' input > > If there is a solution, it finds it in a few seconds. If there is > no solution, it goes away for days proving that. So, I'd like to > give up on it if it doesn't return in a few seconds. http://www.haskell.org/haskellwiki/Timing_out_computations -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ganesh at earth.li Sat Sep 6 11:22:32 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Sep 6 11:20:32 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> Message-ID: On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 6, at 6:10, Ashley Yakeley wrote: >> The set of ACIO expressions exp is the "static initialisers" of M. The RTS >> must note when each static initialiser is run, and cache its result val. >> Let's call this cache of vals the "static results cache" of M. >> >> When M is loaded, and a static results cache for M already exists, then it >> will be used for the vals of M. > > This sounds "reachable" to me, and therefore static overhead and not a > leak. You can call it what you like, but it's still unacceptable behaviour, particularly since clients of M will have no way of telling from its API that it will happen. Ganesh From allbery at ece.cmu.edu Sat Sep 6 11:25:23 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Sep 6 11:23:29 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BE4A93. 4080900@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> Message-ID: On 2008 Sep 6, at 11:22, Ganesh Sittampalam wrote: > On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote: >> On 2008 Sep 6, at 6:10, Ashley Yakeley wrote: >>> The set of ACIO expressions exp is the "static initialisers" of M. >>> The RTS must note when each static initialiser is run, and cache >>> its result val. Let's call this cache of vals the "static results >>> cache" of M. >>> When M is loaded, and a static results cache for M already exists, >>> then it will be used for the vals of M. >> >> This sounds "reachable" to me, and therefore static overhead and >> not a leak. > > You can call it what you like, but it's still unacceptable > behaviour, particularly since clients of M will have no way of > telling from its API that it will happen. You want run-once behavior without giving the runtime the ability to tell that it's already been run? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ganesh at earth.li Sat Sep 6 12:16:10 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Sep 6 12:14:11 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> Message-ID: On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 6, at 11:22, Ganesh Sittampalam wrote: >> On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote: >>> On 2008 Sep 6, at 6:10, Ashley Yakeley wrote: >>>> The set of ACIO expressions exp is the "static initialisers" of M. The >>>> RTS must note when each static initialiser is run, and cache its result >>>> val. Let's call this cache of vals the "static results cache" of M. >>>> When M is loaded, and a static results cache for M already exists, then >>>> it will be used for the vals of M. >>> >>> This sounds "reachable" to me, and therefore static overhead and not a >>> leak. >> >> You can call it what you like, but it's still unacceptable behaviour, >> particularly since clients of M will have no way of telling from its >> API that it will happen. > > You want run-once behavior without giving the runtime the ability to > tell that it's already been run? I don't want run-once behaviour, other people do. I'm just trying to pin down what it would mean. Ganesh From d at vidplace.com Sat Sep 6 12:17:42 2008 From: d at vidplace.com (David F. Place) Date: Sat Sep 6 12:15:39 2008 Subject: [Haskell-cafe] What's the best way to give up? In-Reply-To: References: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> Message-ID: <1220717862.10857.16.camel@Congo> On Sat, 2008-09-06 at 11:10 -0400, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 6, at 7:30, David F. Place wrote: > > Say I have a function solve which is a constraint solver. It > > reconfigures its input to be a solution. If there is no solution, > > it returns the input. > > > > solve :: a -> Either a a > > solve input output = maybe (Left input) Right $ solve' input > > > > If there is a solution, it finds it in a few seconds. If there is > > no solution, it goes away for days proving that. So, I'd like to > > give up on it if it doesn't return in a few seconds. > > http://www.haskell.org/haskellwiki/Timing_out_computations > Thanks, Arnar, Christopher and Brandon. I looked into all your suggestions. I came up with this: import Control.Exception import System.Timeout apt :: Int -> (a -> a) -> a -> IO (Either a a) apt time f x = do { ans <- timeout time $ evaluate (f x) ; return $ maybe (Left x) Right ans } test x = sum [1..x] test2 x = length $ repeat x Which seems to do what I want for test: *Main> apt 100 test 100 Right 5050 *Main> apt 100 test 1000 Right 500500 *Main> apt 100 test 10000 Right 50005000 *Main> apt 100 test 100000 Left 100000 *Main> apt 100 test 1000000 Left 1000000 *Main> apt 100 test 10000000 Left 10000000 But, the following sets the cpu spinning and can't be interrupted. *Main> apt 100 test2 100 From derek.a.elkins at gmail.com Sat Sep 6 12:44:26 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Sep 6 12:42:29 2008 Subject: [Haskell-cafe] What's the best way to give up? In-Reply-To: <1220717862.10857.16.camel@Congo> References: <78C333B4-3A16-4869-8783-0511A0F0E135@vidplace.com> <1220717862.10857.16.camel@Congo> Message-ID: <1220719466.5774.66.camel@derek-laptop> On Sat, 2008-09-06 at 12:17 -0400, David F. Place wrote: > On Sat, 2008-09-06 at 11:10 -0400, Brandon S. Allbery KF8NH wrote: > > On 2008 Sep 6, at 7:30, David F. Place wrote: > > > Say I have a function solve which is a constraint solver. It > > > reconfigures its input to be a solution. If there is no solution, > > > it returns the input. > > > > > > solve :: a -> Either a a > > > solve input output = maybe (Left input) Right $ solve' input > > > > > > If there is a solution, it finds it in a few seconds. If there is > > > no solution, it goes away for days proving that. So, I'd like to > > > give up on it if it doesn't return in a few seconds. > > > > http://www.haskell.org/haskellwiki/Timing_out_computations > > > > Thanks, Arnar, Christopher and Brandon. I looked into all your > suggestions. > > I came up with this: > > import Control.Exception > import System.Timeout > > apt :: Int -> (a -> a) -> a -> IO (Either a a) > apt time f x = > do { ans <- timeout time $ evaluate (f x) > ; return $ maybe (Left x) Right ans > } > > test x = sum [1..x] > test2 x = length $ repeat x > > Which seems to do what I want for test: > > *Main> apt 100 test 100 > Right 5050 > *Main> apt 100 test 1000 > Right 500500 > *Main> apt 100 test 10000 > Right 50005000 > *Main> apt 100 test 100000 > Left 100000 > *Main> apt 100 test 1000000 > Left 1000000 > *Main> apt 100 test 10000000 > Left 10000000 > > > But, the following sets the cpu spinning and can't be interrupted. > *Main> apt 100 test2 100 length (repeat x) doesn't require allocating any memory. GHC only performs a context switch at heap checks. If there are no allocations, there are no heap checks and therefore no context switches. From newsham at lava.net Sat Sep 6 12:45:37 2008 From: newsham at lava.net (Tim Newsham) Date: Sat Sep 6 12:43:47 2008 Subject: [Haskell-cafe] Re: Functional references In-Reply-To: <49541.69.250.26.104.1220641511.squirrel@mail.freegeek.org> References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com> <48C0F69F.5010903@jellybean.co.uk> <49541.69.250.26.104.1220641511.squirrel@mail.freegeek.org> Message-ID: > Tim Newsham's approach with invertible functions is interesting, though it > feels like it's another layer wrapped on top of the primitive idea of > functional references. Not all of the refs are using invertible functions.. however, the ones that are invertible are more flexible.. you can use them to make functional references that are mapped over lists, for example. I've reformulated my code a few times since initially posting it.. In the latest incarnation, FRefGen (generic FRefs with arbitrary get/modify) and Inv (invertible functions) are both instances of an FRef class. In earlier versions I had a function for converting an invertible into an FRef. > ~wren Tim Newsham http://www.thenewsh.com/~newsham/ From nfjinjing at gmail.com Sat Sep 6 15:28:49 2008 From: nfjinjing at gmail.com (jinjing) Date: Sat Sep 6 15:26:52 2008 Subject: [Haskell-cafe] experimental static blog engine in Haskell (file based, markdown syntax) Message-ID: <81ea7d400809061228m29f046e1jf15ae496652a63bc@mail.gmail.com> Hia, It's called Panda. It's pretty young, no theme, no tags, no comments, around 360 lines of code and uses Kibro to bootstrap. hosted on GitHub: http://github.com/nfjinjing/panda/ a quick demo at: http://jinjing.blog.easymic.com/ cheers, - jinjing From dons at galois.com Sat Sep 6 16:26:18 2008 From: dons at galois.com (Don Stewart) Date: Sat Sep 6 16:24:15 2008 Subject: [Haskell-cafe] experimental static blog engine in Haskell (file based, markdown syntax) In-Reply-To: <81ea7d400809061228m29f046e1jf15ae496652a63bc@mail.gmail.com> References: <81ea7d400809061228m29f046e1jf15ae496652a63bc@mail.gmail.com> Message-ID: <20080906202618.GF16708@scytale.galois.com> nfjinjing: > Hia, > > It's called Panda. It's pretty young, no theme, no tags, no comments, > around 360 lines of code and uses Kibro to bootstrap. > > hosted on GitHub: > http://github.com/nfjinjing/panda/ > > a quick demo at: > http://jinjing.blog.easymic.com/ Awesome! Kibro seems to be taking off. Will you release it on hackage.haskell.org? -- Don From byorgey at seas.upenn.edu Sat Sep 6 16:29:27 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Sep 6 16:27:26 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 84 - September 6, 2008 Message-ID: <20080906202927.GA31530@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20080906 Issue 84 - September 06, 2008 --------------------------------------------------------------------------- Welcome to issue 84 of HWN, a newsletter covering developments in the [1]Haskell community. This is the "This issue is not late since the HWN will henceforth be published on Saturday now that I have real work to do" edition. Featured this week: darcs hacking sprint plans solidify, xmonad 0.8 released, typed sprintf and sscanf, and tons of discussion about everything from functional references to splitting up the base library to the future direction of Haskell. Announcements unicode-properties 3.2.0.0, unicode-names 3.2.0.0. Ashley Yakeley [2]announced the release of the [3]unicode-properties 3.2.0.0 and [4]unicode-names 3.2.0.0 packages, which are representations in Haskell of various data in the Unicode 3.2.0 Character Database. experimental static blog engine in Haskell. jinjing [5]announced the initial release of [6]Panda, an experimental static blog engine written in Haskell. darcs hacking sprint, venues confirmed! (25-26 October). Eric Y. Kow [7]announced that two venues (Brighton, UK and Portland, Oregon, USA) have been confirmed for the [8]darcs hacking sprint on 25-26 October. darcs weekly news #2. Eric Y. Kow The second weekly issue of the [9]darcs weekly news has been published. xmonad 0.8 released!. Don Stewart [10]announced the release of [11]xmonad 0.8, featuring a general purpose "gaps" replacement, locale support, the ability to create your own configuration parsers, and various other [12]enhancements and fixes. POPL logo design contest. Don Stewart [13]forwarded a message announcing a logo design contest for POPL 2009. Dust off your magic markers/photoshop skills and get designing! ICFP09 Announcement. Matthew Fluet [14]announced [15]ICFP 2009, to be held 31st August to 2nd September 2009 in Edinburgh. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Fast parallel binary-trees for the shootout: Control.Parallel.Strategies FTW!. Don Stewart [16]announced that the Computer Language Shootout recently got a quad core 64 bit machine, and outlined a plan and some initial results for porting the Haskell entries to take advantage of the available parallelism. The initial view on typed sprintf and sscanf. oleg [17]announced an implementation of typed sprintf and sscanf functions sharing the same formatting specifications, which also led to some interesting discussion and alternative proposals. Discussion Generalize groupBy in a useful way?. Bart Massey [18]proposed changing the implementation of groupBy to extend its usefulness for predicates which are not equivalence relations. Splitting SYB from the base package in GHC 6.10. Jos?? Pedro Magalh??es [19]initiated a discussion regarding splitting the SYB libraries out of the base package for GHC 6.10. The base library and GHC 6.10. Ian Lynagh initiated a [20]discussion on further splitting up the base package for GHC 6.10. Functional references. Tim Newsham began a [21]discussion on functional references and the possibility of merging the existing four or five implementations into something more standard. Types and Trees. Matt Morrow [22]wrote something about types and type representations, involving some commutative diagrams and some code. I haven't read it yet but it looks neat! Research language vs. professional language. Ryan Ingram started an interesting [23]discussion on the future direction(s) of the Haskell language. language proposal: ad-hoc overloading. Ryan Ingram [24]proposed adding ad-hoc name overloading to Haskell, prompting quite a bit of discussion. Top Level <-. Ashley Yakeley originally [25]asked whether there is any interest in implementing a top level "<-" to run monadic code. This set off a cascade of discussion the likes of which have been rarely seen on the Cafe. I would tell you what the discussion has been about but I must confess that I haven't read it. Blog noise [26]Haskell news from the [27]blogosphere. * Eric Kow (kowey): [28]darcs hacking sprint (25-26 October 2008). * Magnus Therning: [29]Confusion with HaskellDB. * Xmonad: [30]xmonad 0.8 released!. * Real-World Haskell: [31]Speaking in Silicon Valley next week. * Luke Palmer: [32]Composable Input for Fruit. * Luke Palmer: [33]Slicing open the belly of the IO monad in an alternate universe. * "FP Lunch": [34]Modular Monad Transformers. * Douglas M. Auclair (geophf): [35]Fuzzy unification parser in Haskell. * Bjoern Edstroem: [36]Speeding up Haskell with C -- a very short introduction. * Eric Kow (kowey): [37]darcs weekly news #2. * Roman Cheplyaka: [38]Physics and polyhedra. * Well-Typed.Com: [39]The new haskell.org community SPARC server is online. * Douglas M. Auclair (geophf): [40]A stream of primes as Comonad. * Eric Kidd: [41]Ubiquitous Hoogle. Eric shows how to integrate a [42]Hoogle search command into [43]Ubiquity. * Dan Piponi (sigfpe): [44]Untangling with Continued Fractions: Part 3. The vector space monad and rational tangles. Quotes of the Week * dons: maybe we should do a "recommend RWH to a java programmer" campaign :) * gwern: we fill fight them in the registers, we will fight them in the caches; we shall fight them in the core, and even in the backing store. And we shall never surrender! About the Haskell Weekly News New editions are posted to [45]the Haskell mailing list as well as to [46]the Haskell Sequence and [47]Planet Haskell. [48]RSS is also available, and headlines appear on [49]haskell.org. To help create new editions of this newsletter, please see the information on [50]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [51]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.libraries/9973 3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unicode-properties 4. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unicode-names 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44181 6. http://jinjing.blog.easymic.com/ 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44164 8. http://wiki.darcs.net/index.html/Sprints 9. http://code.haskell.org/darcs/darcs-news 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44157 11. http://xmonad.org/ 12. http://haskell.org/haskellwiki/Xmonad/Notable_changes_since_0.7 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44069 14. http://article.gmane.org/gmane.comp.lang.haskell.general/16413 15. http://www.cs.nott.ac.uk/~gmh/icfp09.html 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43968 17. http://article.gmane.org/gmane.comp.lang.haskell.general/16405 18. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/10016 19. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9962 20. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929 21. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44098 22. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44028 23. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/43933 24. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/43897 25. http://thread.gmane.org/gmane.comp.lang.haskell.general/16393 26. http://planet.haskell.org/ 27. http://haskell.org/haskellwiki/Blog_articles 28. http://koweycode.blogspot.com/2008/09/darcs-hacking-sprint-25-26-october-2008.html 29. http://therning.org/magnus/archives/375 30. http://xmonad.wordpress.com/2008/09/05/xmonad-08-released/ 31. http://www.realworldhaskell.org/blog/2008/09/05/speaking-in-silicon-valley-next-week/ 32. http://luqui.org/blog/archives/2008/08/09/composable-input-for-fruit/ 33. http://luqui.org/blog/archives/2008/08/14/slicing-open-the-belly-of-the-io-monad-in-an-alternate-universe/ 34. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=111 35. http://logicaltypes.blogspot.com/2008/09/fuzzy-unification-parser-in-haskell.html 36. http://blog.bjrn.se/2008/09/speeding-up-haskell-with-c-very-short.html 37. http://koweycode.blogspot.com/2008/09/darcs-weekly-news-2.html 38. http://physics-dph.blogspot.com/2008/08/physics-and-polyhedra.html 39. http://blog.well-typed.com/2008/09/the-new-haskellorg-community-sparc-server-is-online/ 40. http://logicaltypes.blogspot.com/2008/09/stream-of-primes-as-comonad.html 41. http://www.randomhacks.net/articles/2008/09/01/ubiquitous-hoogle 42. http://www.haskell.org/hoogle/ 43. https://wiki.mozilla.org/Labs/Ubiquity 44. http://sigfpe.blogspot.com/2008/08/untangling-with-continued-fractions_31.html 45. http://www.haskell.org/mailman/listinfo/haskell 46. http://sequence.complete.org/ 47. http://planet.haskell.org/ 48. http://sequence.complete.org/node/feed 49. http://haskell.org/ 50. http://haskell.org/haskellwiki/HWN 51. http://code.haskell.org/~byorgey/code/hwn/ From ryani.spam at gmail.com Sat Sep 6 16:33:42 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Sep 6 16:31:43 2008 Subject: [Haskell-cafe] GADTs and instances In-Reply-To: References: Message-ID: <2f9b2d30809061333o17573cf4q1e25e97567c804ed@mail.gmail.com> The problem is that the caller of "get" is allowed to say what type of Query they want with this instance, for example: ] get :: Get (Query Int) because Int is an instance of Binary, and you claim ] instance Binary a => Binary (Query a) In fact, since the type of each query is unique, the tagging in "put" doesn't help you. So there is no way to write a generic Binary instance for Query a. But don't give up! Here's a solution in literate haskell... > {-# LANGUAGE ExistentialQuantification, FlexibleInstances, GADTs #-} > module Query where > import Data.Binary > import Control.Monad (liftM) > > data Query a where > Lookup :: String -> Query (Maybe Int) > Fetch :: [String] -> Query [Int] One obvious strategy is to use existential types: > data SomeQuery = forall a. SomeQuery (Query a) You can then make SomeQuery an instance of Binary using very similar code to your implementation. Now, the code that calls "get" needs to be able to deal with any Query type it gets back inside the SomeQuery. Another possibility is to drop the tagging altogether and use a helper class: > class BinaryQuery a where > putQ :: Query a -> Put > getQ :: Get (Query a) > instance BinaryQuery a => Binary (Query a) where > put = putQ > get = getQ > instance BinaryQuery (Maybe Int) where > putQ (Lookup x) = put x > getQ = liftM Lookup get > instance BinaryQuery [Int] where > putQ (Fetch xs) = put xs > getQ = liftM Fetch get You can also combine the strategies and use SomeQuery when the stored value needs a tag: > instance Binary SomeQuery where > put (SomeQuery x@(Lookup _)) = putWord8 0 >> put x > put (SomeQuery x@(Fetch _)) = putWord8 1 >> put x > get = getWord8 >>= \tag -> case tag of > 0 -> liftM SomeQuery (get :: Get (Query (Maybe Int))) > 1 -> liftM SomeQuery (get :: Get (Query [Int])) The pattern matching in "put" specializes the type of x, allowing the query-level put to find the correct implementation. Similarily, in "get" we choose the correct get based on the input type. -- ryan From kolmodin at dtek.chalmers.se Sat Sep 6 17:18:19 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Sat Sep 6 17:04:51 2008 Subject: [Haskell-cafe] Re: [xmonad] ANNOUNCE: xmonad 0.8 released! In-Reply-To: <20080906101311.GB12228@scytale.galois.com> References: <20080906013828.GB11490@scytale.galois.com> <1220695906.3365.4.camel@otto.ehbuehl.net> <20080906101311.GB12228@scytale.galois.com> Message-ID: <48C2F39B.7050707@dtek.chalmers.se> Don Stewart wrote: > nomeata: >> Hi, >> >> Am Freitag, den 05.09.2008, 18:38 -0700 schrieb Don Stewart: >>> xmonad packages are available in the package systems of at least: >>> >>> Debian, Gentoo, Arch, Ubuntu, OpenBSD, >>> NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware >>> >>> and 0.8 packages will appear in coming days (some are already available). >> Debian xmonad and xmonad-contrib package uploaded (although >> xmonad-contrib is in the two-day delayed queue, to give autobuilders a >> chance to build xmonad first). > > Great work, Joachim! > > Thanks for being so responsive on this. Go Debian! Committed to Gentoo Linux earlier this evening. http://packages.gentoo.org/package/x11-wm/xmonad http://packages.gentoo.org/package/x11-wm/xmonad-contrib Cheers, Lennart K From dons at galois.com Sat Sep 6 17:13:32 2008 From: dons at galois.com (Don Stewart) Date: Sat Sep 6 17:11:29 2008 Subject: [Haskell-cafe] Re: [xmonad] ANNOUNCE: xmonad 0.8 released! In-Reply-To: <48C2F39B.7050707@dtek.chalmers.se> References: <20080906013828.GB11490@scytale.galois.com> <1220695906.3365.4.camel@otto.ehbuehl.net> <20080906101311.GB12228@scytale.galois.com> <48C2F39B.7050707@dtek.chalmers.se> Message-ID: <20080906211332.GB16970@scytale.galois.com> kolmodin: > Don Stewart wrote: > >nomeata: > >>Hi, > >> > >>Am Freitag, den 05.09.2008, 18:38 -0700 schrieb Don Stewart: > >>> xmonad packages are available in the package systems of at least: > >>> > >>> Debian, Gentoo, Arch, Ubuntu, OpenBSD, > >>> NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware > >>> > >>> and 0.8 packages will appear in coming days (some are already > >>> available). > >>Debian xmonad and xmonad-contrib package uploaded (although > >>xmonad-contrib is in the two-day delayed queue, to give autobuilders a > >>chance to build xmonad first). > > > >Great work, Joachim! > > > >Thanks for being so responsive on this. Go Debian! > > Committed to Gentoo Linux earlier this evening. > > http://packages.gentoo.org/package/x11-wm/xmonad > http://packages.gentoo.org/package/x11-wm/xmonad-contrib Gentoo steps up! Excellent work guys. And if I read those graphs correctly, that's xmonad on hppa and sparc too? -- Don From kolmodin at dtek.chalmers.se Sat Sep 6 18:13:00 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Sat Sep 6 17:59:30 2008 Subject: [Haskell-cafe] Re: [xmonad] ANNOUNCE: xmonad 0.8 released! In-Reply-To: <20080906211332.GB16970@scytale.galois.com> References: <20080906013828.GB11490@scytale.galois.com> <1220695906.3365.4.camel@otto.ehbuehl.net> <20080906101311.GB12228@scytale.galois.com> <48C2F39B.7050707@dtek.chalmers.se> <20080906211332.GB16970@scytale.galois.com> Message-ID: <48C3006C.1020209@dtek.chalmers.se> Don Stewart wrote: > kolmodin: >> Don Stewart wrote: >>> nomeata: >>>> Hi, >>>> Debian xmonad and xmonad-contrib package uploaded (although >>>> xmonad-contrib is in the two-day delayed queue, to give autobuilders a >>>> chance to build xmonad first). >>> Great work, Joachim! >>> >>> Thanks for being so responsive on this. Go Debian! >> Committed to Gentoo Linux earlier this evening. >> >> http://packages.gentoo.org/package/x11-wm/xmonad >> http://packages.gentoo.org/package/x11-wm/xmonad-contrib > > Gentoo steps up! Excellent work guys. > And if I read those graphs correctly, that's xmonad on hppa and sparc too? > Yep, that's right. Our arch teams has tested an earlier version, thus it's available for this version too since it doesn't introduce any major changes in dependencies or build procedure. Although probably no one has yet build it using our ebuild for this version, we're confident it'll work ;) I'm pleased with upgrading and switching to avoidStruts without even having to log out, well done :) Cheers, Lennart K From ashley at semantic.org Sat Sep 6 18:06:17 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Sep 6 18:04:19 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> Message-ID: <48C2FED9.1060107@semantic.org> Ganesh Sittampalam wrote: >>> The set of ACIO expressions exp is the "static initialisers" of M. >>> The RTS must note when each static initialiser is run, and cache its >>> result val. Let's call this cache of vals the "static results cache" >>> of M. >>> >>> When M is loaded, and a static results cache for M already exists, >>> then it will be used for the vals of M. >> >> This sounds "reachable" to me, and therefore static overhead and not a >> leak. > > You can call it what you like, but it's still unacceptable behaviour, > particularly since clients of M will have no way of telling from its API > that it will happen. That what will happen? -- Ashley Yakeley From allbery at ece.cmu.edu Sat Sep 6 18:16:15 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Sep 6 18:14:32 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <48C2FED9.1060107@semantic.org> References: <534781822.20080826190130@gmail.com> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semant ic.org> Message-ID: On 2008 Sep 6, at 18:06, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >>>> The set of ACIO expressions exp is the "static initialisers" of >>>> M. The RTS must note when each static initialiser is run, and >>>> cache its result val. Let's call this cache of vals the "static >>>> results cache" of M. >>>> >>>> When M is loaded, and a static results cache for M already >>>> exists, then it will be used for the vals of M. >>> >>> This sounds "reachable" to me, and therefore static overhead and >>> not a leak. >> You can call it what you like, but it's still unacceptable >> behaviour, particularly since clients of M will have no way of >> telling from its API that it will happen. > > That what will happen? I have no idea what Ganesh is complaining about, but if the point of ACIO is one-time initialization, it is pretty much required that something will be allocated to record the fact that a given item has been initialized (otherwise it can't guarantee the initializer runs exactly once, after all), and therefore that is part of the base ACIO API. So what exactly is the issue here? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ashley at semantic.org Sat Sep 6 18:25:44 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Sep 6 18:23:45 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semant ic.org> Message-ID: <1220739944.12064.7.camel@glastonbury> On Sat, 2008-09-06 at 18:16 -0400, Brandon S. Allbery KF8NH wrote: > I have no idea what Ganesh is complaining about, but if the point of > ACIO is one-time initialization, it is pretty much required that > something will be allocated to record the fact that a given item has > been initialized (otherwise it can't guarantee the initializer runs > exactly once, after all), and therefore that is part of the base ACIO > API. So what exactly is the issue here? The issue is this: 1. Results from initialisers cannot be GC'd even if they become otherwise unreachable, because the dynamic loader might re-load the module (and then we'd need those original results). 2. If the dynamic loader loads an endless stream of different modules containing initialisers, memory will thus leak. It's tempting to say "don't do that" to point #2. -- Ashley Yakeley From allbery at ece.cmu.edu Sat Sep 6 18:31:03 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Sep 6 18:29:04 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <1220739944.12064.7.camel@glastonbury> References: <534781822.20080826190130@gmail.com> <78A3C5650E28124399107F21A1FA419401D3B855@ELON17P32002A.csfb.cs-group.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semant ic.org> <1220739944.12064.7.camel@glastonbury> Message-ID: On 2008 Sep 6, at 18:25, Ashley Yakeley wrote: > 1. Results from initialisers cannot be GC'd even if they become > otherwise unreachable, because the dynamic loader might re-load the > module (and then we'd need those original results). > > 2. If the dynamic loader loads an endless stream of different modules > containing initialisers, memory will thus leak. I think if the issue is this vs. not being able to guarantee any once- only semantics, i consider the former necessary overhead for proper program behavior. And that, given that there exists extra-program global state that one might want to access, once-only initialization is a necessity. (Whoever it was who jumped off this point to say Haskell should exit the real world misses the point: it's not even all that useful from a theoretical standpoint if it's not allowed to interact with anything outside itself, and stdin/stdout tend to require once-only initialization. You can't really hide from it.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From mblazevic at stilo.com Sat Sep 6 20:22:00 2008 From: mblazevic at stilo.com (=?utf-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=) Date: Sat Sep 6 20:19:59 2008 Subject: [Haskell-cafe] (no subject) Message-ID: <.1220746920@magma.ca> Hello. I'm trying to apply the nested regions (as in Lightweight Monadic Regions by Oleg Kiselyov and Chung-chieh Shan) design pattern, if that's the proper term. I was hoping to gain a bit more type safety in this little library I'm working on -- Streaming Component Combinators, available on Hackage. I guess the problem is that I'm getting too much type safety now, because I can't get the thing to compile. Most of the existing code works, the only exceptions seem to be various higher-order functions. I've reduced the problem to several lines of Literate Haskell code below, can anybody think of a solution or a reason there can't be one? > {-# LANGUAGE MultiParamTypeClasses, EmptyDataDecls, Rank2Types #-} > {-# LANGUAGE FunctionalDependencies, FlexibleInstances, IncoherentInstances #-} > module Main where > main = undefined I'll call the main type, originally a monad transformer, simply Region. I'm leaving out the Monad and MonadTransformer instances, because they don't contribute to the problem. The parameter r is the phantom region type. > newtype Region r a = Region a The Ancestor class is used to denote relationship between two regions where one is nested in another. > data Child r > class Ancestor r r' > instance Ancestor r (Child r) > instance Ancestor r1 r2 => Ancestor r1 (Child r2) Handle is a simple wrapper around a value. It carries information about the region that originates the value. > data Handle r x = Handle x A typical calculation in the Region monad will take a bunch of Handles inherited from an Ancestor region and do something with them. The Ancestor constraint is there to ensure that the handles are not fake but genuinely inherited. > type SingleHandler x y = forall r1s rs. Ancestor r1s rs => > Handle r1s x -> Region rs y > type DoubleHandler x y z = forall r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) => > Handle r1d x -> Handle r2d y -> Region rd z And now I'm getting to the problem. The following higher-order function doesn't type-check: > mapD :: (SingleHandler x z -> SingleHandler y z) > -> DoubleHandler x w z -> DoubleHandler y w z > mapD f d = \y w-> f (\x-> d x w) y I get the same error from GHC 6.8.2 and 6.8.2: Test.lhs:36:28: Could not deduce (Ancestor r2d rs) from the context (Ancestor r1s rs) arising from a use of `d' at Test.lhs:36:28-32 Possible fix: add (Ancestor r2d rs) to the context of the polymorphic type `forall r1s rs. (Ancestor r1s rs) => Handle r1s x -> Region rs z' In the expression: d x w In the first argument of `f', namely `(\ x -> d x w)' In the expression: f (\ x -> d x w) y The same code compiles just fine if all the Ancestor constraints are removed. I don't see any place to add the extra (Ancestor r2d rs) constraint, as GHC recommends. I think it ought to be able to figure things out based on the exisisting constraints, but I may be wrong: perhaps higher-order functions pose an insurmountable problem for type-level programming in Haskell. Can anybody shed any light on this? From mblazevic at stilo.com Sat Sep 6 20:24:30 2008 From: mblazevic at stilo.com (=?utf-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=) Date: Sat Sep 6 20:22:29 2008 Subject: [Haskell-cafe] A problem with nested regions and higher-order functions Message-ID: <.1220747070@magma.ca> I forgot the subject, sorry for reposting... I'm trying to apply the nested regions (as in Lightweight Monadic Regions by Oleg Kiselyov and Chung-chieh Shan) design pattern, if that's the proper term, in hope to gain a bit more type safety in this little library I'm working on (Streaming Component Combinators, available on Hackage). I guess the problem is that I'm getting too much type safety now, because I can't get the thing to compile. Most of the existing code works, the only exceptions seem to be various higher-order functions. I've reduced the problem to several lines of Literate Haskell code below, can anybody find a solution or confirm there isn't one? > {-# LANGUAGE EmptyDataDecls, Rank2Types #-} > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, IncoherentInstances #-} > module Main where > main = undefined I'll call the main type, originally a monad transformer, simply Region. I'm leaving out the Monad and MonadTransformer instances, because they don't contribute to the problem. The parameter r is the phantom region type. > newtype Region r a = Region a The Ancestor class is used to denote relationship between two regions where one is nested in another. > data Child r > class Ancestor r r' > instance Ancestor r (Child r) > instance Ancestor r1 r2 => Ancestor r1 (Child r2) Handle is a simple wrapper around a value. It carries information about the region that originates the value. > data Handle r x = Handle x A typical calculation in the Region monad will take a bunch of Handles inherited from an Ancestor region and do something with them. The Ancestor constraint is there to ensure that the handles are not fake but genuinely inherited. > type SingleHandler x y = forall r1s rs. Ancestor r1s rs => > Handle r1s x -> Region rs y > type DoubleHandler x y z = forall r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) => > Handle r1d x -> Handle r2d y -> Region rd z And now I get to the problem. The following higher-order function doesn't type-check: > mapD :: (SingleHandler x z -> SingleHandler y z) > -> DoubleHandler x w z -> DoubleHandler y w z > mapD f d = \y w-> f (\x-> d x w) y I get the same error from GHC 6.8.2 and 6.8.2: Test.lhs:36:28: Could not deduce (Ancestor r2d rs) from the context (Ancestor r1s rs) arising from a use of `d' at Test.lhs:36:28-32 Possible fix: add (Ancestor r2d rs) to the context of the polymorphic type `forall r1s rs. (Ancestor r1s rs) => Handle r1s x -> Region rs z' In the expression: d x w In the first argument of `f', namely `(\ x -> d x w)' In the expression: f (\ x -> d x w) y The same code compiles just fine if all the Ancestor constraints are removed. I don't see any place to add the extra (Ancestor r2d rs) constraint, as GHC recommends. I think it ought to be able to figure things out based on the exisisting constraints, but I may be wrong: perhaps higher-order functions pose a fundamental problem for type-level programming. Can anybody shed any light on this? From ganesh at earth.li Sun Sep 7 06:14:16 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Sep 7 06:12:15 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semant ic.org> <1220739944.12064.7.camel@glastonbury> Message-ID: On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 6, at 18:25, Ashley Yakeley wrote: >> >> 2. If the dynamic loader loads an endless stream of different modules >> containing initialisers, memory will thus leak. > > I think if the issue is this vs. not being able to guarantee any > once-only semantics, i consider the former necessary overhead for proper > program behavior. Not leaking memory is an important part of proper program behaviour. > And that, given that there exists extra-program global state that > one might want to access, once-only initialization is a necessity. In what cases? In the case of buffered I/O there's no reason (in theory) you couldn't unload libc, do unbuffered I/O for a while, then reload libc and start again. Ganesh From ganesh at earth.li Sun Sep 7 06:23:18 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Sep 7 06:21:15 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <48C2FED9.1060107@semantic.org> References: <534781822.20080826190130@gmail.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semantic.org> Message-ID: On Sat, 6 Sep 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >>>> The set of ACIO expressions exp is the "static initialisers" of M. The >>>> RTS must note when each static initialiser is run, and cache its result >>>> val. Let's call this cache of vals the "static results cache" of M. >>>> >>>> When M is loaded, and a static results cache for M already exists, then >>>> it will be used for the vals of M. >>> >>> This sounds "reachable" to me, and therefore static overhead and not a >>> leak. >> >> You can call it what you like, but it's still unacceptable behaviour, >> particularly since clients of M will have no way of telling from its >> API that it will happen. > > That what will happen? That memory will be used and not ever be reclaimable. Suppose I am writing something that I intend to be used as part of a plug-in that is reloaded in different forms again and again. And I see module K which does something I want, so I use it. It so happens that K uses M, which has a <-. If I knew that using K in my plug-in would cause a memory leak, I would avoid doing so; but since the whole point of <- is to avoid making the need for some state visible in the API. Ganesh From dav.vire+haskell at gmail.com Sun Sep 7 07:17:23 2008 From: dav.vire+haskell at gmail.com (david48) Date: Sun Sep 7 07:15:20 2008 Subject: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters In-Reply-To: <48C1128A.2040804@tcs.inf.tu-dresden.de> References: <4c88418c0809050345t38f32b2blcf59857c1637ab10@mail.gmail.com> <48C1128A.2040804@tcs.inf.tu-dresden.de> Message-ID: <4c88418c0809070417o3a59f212r3daec8cae1c39ea8@mail.gmail.com> On Fri, Sep 5, 2008 at 1:05 PM, Janis Voigtlaender wrote: > See John's comment, right there in the online version: > > "The system that generated this webpage didn't have HDBC installed at > the time. We'll get that fixed and re-post this chapter. In the > meantime, unfortunately, all of the examples on this page will look that > way." Oops. Though, by the time I wrote the message, I didn't have access to the comments. I see now it's corrected. Kudos to the authors for an excellent book ! David. From pierre-edouard.portier at insa-lyon.fr Sun Sep 7 09:35:40 2008 From: pierre-edouard.portier at insa-lyon.fr (Pierre-Edouard Portier) Date: Sun Sep 7 09:33:42 2008 Subject: [Haskell-cafe] HXT from schema to data model Message-ID: <20080907133540.GA26545@gmail.com> Hi! Is there a way to generate a data model and a set of picklers from an XML (or RelaxNG) Schema using the HXT tool box? Thank You, Pierre-Edouard From allbery at ece.cmu.edu Sun Sep 7 12:00:46 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Sep 7 11:58:54 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semantic.org> Message-ID: <2F8C5AB4-6790-4DA4-AE31-EF5C5E0ACB56@ece.cmu.edu> On 2008 Sep 7, at 6:23, Ganesh Sittampalam wrote: > On Sat, 6 Sep 2008, Ashley Yakeley wrote: >> Ganesh Sittampalam wrote: >>>>> The set of ACIO expressions exp is the "static initialisers" of >>>>> M. The RTS must note when each static initialiser is run, and >>>>> cache its result val. Let's call this cache of vals the "static >>>>> results cache" of M. >>>>> When M is loaded, and a static results cache for M already >>>>> exists, then it will be used for the vals of M. >>>> This sounds "reachable" to me, and therefore static overhead and >>>> not a leak. >>> You can call it what you like, but it's still unacceptable >>> behaviour, particularly since clients of M will have no way of >>> telling from its API that it will happen. >> >> That what will happen? > > That memory will be used and not ever be reclaimable. > > Suppose I am writing something that I intend to be used as part of a > plug-in that is reloaded in different forms again and again. And I > see module K which does something I want, so I use it. It so happens > that K uses M, which has a <-. If I knew that using K in my plug-in > would cause a memory leak, I would avoid doing so; but since the > whole point of <- is to avoid making the need for some state visible > in the API. False, as it's in ACIO and therefore advertises that it will "leak memory" in the name of correct behavior. Since you consider memory leaks to be worse than correct behavior, you can avoid anything that uses ACIO. (But you might want to go look at that list of modules which do global variable initialization and therefore aren't entirely trustworthy unless something like ACIO exists.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ganesh at earth.li Sun Sep 7 12:10:40 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Sep 7 12:08:37 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <2F8C5AB4-6790-4DA4-AE31-EF5C5E0ACB56@ece.cmu.edu> References: <534781822.20080826190130@gmail.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semantic.org> <2F8C5AB4-6790-4DA4-AE31-EF5C5E0ACB56@ece.cmu.edu> Message-ID: On Sun, 7 Sep 2008, Brandon S. Allbery KF8NH wrote: >> plug-in that is reloaded in different forms again and again. And I see >> module K which does something I want, so I use it. It so happens that K >> uses M, which has a <-. If I knew that using K in my plug-in would cause a >> memory leak, I would avoid doing so; but since the whole point of <- is to >> avoid making the need for some state visible in the API. > > False, as it's in ACIO and therefore advertises that it will "leak > memory" in the name of correct behavior. I thought ACIO was a restriction on the thing on the right hand side of the <-? How does the module itself advertise its use of this (transitively) to users? > Since you consider memory leaks to be worse than correct behavior, Not leaking memory is *part* of correct behaviour. If <- is to be created at all, it should be created with restrictions that make it capable of guaranteeing correct behaviour. > (But you might want to go look at that list of modules which do global > variable initialization and therefore aren't entirely trustworthy unless > something like ACIO exists.) We should fix them (and their interface) so this doesn't happen, rather than standardising something broken. Ganesh From mailing_list at istitutocolli.org Sun Sep 7 12:31:00 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Sun Sep 7 12:29:08 2008 Subject: [Haskell-cafe] HXT from schema to data model In-Reply-To: <20080907133540.GA26545@gmail.com> References: <20080907133540.GA26545@gmail.com> Message-ID: <20080907163100.GJ2861@Andrea.Nowhere.net> On Sun, Sep 07, 2008 at 03:35:40PM +0200, Pierre-Edouard Portier wrote: > Hi! > Is there a way to generate a data model and a set of picklers from an XML (or > RelaxNG) Schema using the HXT tool box? not that I'm aware of. There's something for generating a data type and an access interface from DTD. See, in hxt source code: examples/arrows/dtd2hxt/DTDtoHXT.hs nothing for picklers. and nothing from RelaxNG (even the validator is not complete). in HaXml there could be something worth having a look to (that depends on what you are actually search for). I had a similar problem some time ago and was looking for something like that to implement CSL (and XML macro language for citation formatting), but I handed up writing all the needed boilerplate code, for the data type and the pickler deserializer. Anyway, drop a line if you find (or write) something. Cheers, Andrea From allbery at ece.cmu.edu Sun Sep 7 12:34:20 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Sep 7 12:32:19 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semantic.org> <2F8C5AB4-6790-4DA4-AE31-EF5C5E0ACB56@ece.cmu.edu> Message-ID: <191D1F78-4753-4E6F-972E-02EDC0E8FFE2@ece.cmu.edu> On 2008 Sep 7, at 12:10, Ganesh Sittampalam wrote: > On Sun, 7 Sep 2008, Brandon S. Allbery KF8NH wrote: >>> Since you consider memory leaks to be worse than correct behavior, > > Not leaking memory is *part* of correct behaviour. If <- is to be > created at all, it should be created with restrictions that make it > capable of guaranteeing correct behaviour. > >> (But you might want to go look at that list of modules which do >> global variable initialization and therefore aren't entirely >> trustworthy unless something like ACIO exists.) > > We should fix them (and their interface) so this doesn't happen, > rather than standardising something broken. And we're right back to "so how do we do this when we aren't allowed to record that it has already been run?" You seem to think we must never insure that something will only be run once, that any program that does require this is broken. As such, the standard Haskell libraries (including some whose interfaces are H98) are unfixably broken and you'd better start looking elsewhere for your "correct behavior". -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ganesh at earth.li Sun Sep 7 12:55:59 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Sep 7 12:53:57 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <191D1F78-4753-4E6F-972E-02EDC0E8FFE2@ece.cmu.edu> References: <534781822.20080826190130@gmail.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semantic.org> <2F8C5AB4-6790-4DA4-AE31-EF5C5E0ACB56@ece.cmu.edu> <191D1F78-4753-4E6F-972E-02EDC0E8FFE2@ece.cmu.edu> Message-ID: On Sun, 7 Sep 2008, Brandon S. Allbery KF8NH wrote: > You seem to think we must never insure that something will only be run > once, that any program that does require this is broken. As such, the > standard Haskell libraries (including some whose interfaces are H98) are > unfixably broken and you'd better start looking elsewhere for your > "correct behavior". Data.Unique might be unfixably broken, though perhaps some requirement that it not be unloaded while any values of type Unique are still around could solve the problem - though it's hard to see how this could be implemented sanely. But Data.Unique could (a) probably be replaced with something in terms of IORefs and (b) is pretty ugly anyway, since it forces you into IO. I'm sure that for many other examples, re-initialisation would be fine. For example Data.HashTable just uses a global for instrumentation for performance tuning, which could happily be reset if it got unloaded and then reloaded. System.Random could get a new StdGen. I haven't yet had time to go through the entire list that Adrian Hey posted to understand why they are being used, though. I'd also point out that if you unload and load libraries in C, global state will be lost and re-initialised. Ganesh From voldermort at icmail.net Sat Sep 6 19:09:23 2008 From: voldermort at icmail.net (John Smith) Date: Sun Sep 7 16:38:03 2008 Subject: [Haskell-cafe] Re: language proposal: ad-hoc overloading In-Reply-To: <2f9b2d30808311121r1c0a4155gd7f55a6d135be8a7@mail.gmail.com> References: <2f9b2d30808311121r1c0a4155gd7f55a6d135be8a7@mail.gmail.com> Message-ID: Ryan Ingram wrote: > module Prob where > import qualified Data.Map as M > .... > > newtype Prob p a = Prob { runProb :: [(a,p)] } > > combine :: (Num p, Ord a) => Prob p a -> Prob p a > combine m = Prob $ > M.assocs $ > foldl' (flip $ uncurry $ M.insertWith (+)) M.empty $ > runProb m > > Do you see it? All those "M." just seem dirty to me, especially > because the compiler should be able to deduce them from the types of > the arguments. May I humbly suggest a much simpler solution to your problem: if an identifier is ambiguous, the compiler will use the last import. So, in your example, the compiler will assume that any instance of empty is Data.Map.empty Some means of using an imported module as the default namespace, and requiring the Prelude to be qualified, may also help. From allbery at ece.cmu.edu Sun Sep 7 16:56:07 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Sep 7 16:54:06 2008 Subject: [Haskell-cafe] Re: language proposal: ad-hoc overloading In-Reply-To: References: <2f9b2d30808311121r1c0a4155gd7f55a6d135be8a7@mail.gmail.com> Message-ID: <43B4873F-0A31-470D-8A29-F10892C5FAD8@ece.cmu.edu> On 2008 Sep 6, at 19:09, John Smith wrote: > Ryan Ingram wrote: >> module Prob where >> import qualified Data.Map as M >> .... >> newtype Prob p a = Prob { runProb :: [(a,p)] } >> combine :: (Num p, Ord a) => Prob p a -> Prob p a >> combine m = Prob $ >> M.assocs $ >> foldl' (flip $ uncurry $ M.insertWith (+)) M.empty $ >> runProb m >> Do you see it? All those "M." just seem dirty to me, especially >> because the compiler should be able to deduce them from the types of >> the arguments. > > May I humbly suggest a much simpler solution to your problem: if an > identifier is ambiguous, the compiler will use the last import. So, > in your example, the compiler will assume that any instance of empty > is Data.Map.empty I don't like that idea very much; if I reorder my imports the program semantics suddenly change? > Some means of using an imported module as the default namespace, and > requiring the Prelude to be qualified, may also help. You can already do this by importing Prelude explicitly, possibly with the NoImplicitPrelude language option. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ashley at semantic.org Sun Sep 7 18:11:04 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Sep 7 18:09:02 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48BE56C7.10907@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B859@ELON17P32002A.csfb.cs-group.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semantic.org> Message-ID: <48C45178.3040003@semantic.org> Ganesh Sittampalam wrote: > Suppose I am writing something that I intend to be used as part of a > plug-in that is reloaded in different forms again and again. And I see > module K which does something I want, so I use it. It so happens that K > uses M, which has a <-. If I knew that using K in my plug-in would cause > a memory leak, I would avoid doing so; but since the whole point of <- > is to avoid making the need for some state visible in the API. The results from the <- in M will only be stored once for the life of the RTS, no matter how many times your plug-ins are reloaded. -- Ashley Yakeley From cjs at starling-software.com Sun Sep 7 21:02:21 2008 From: cjs at starling-software.com (Curt Sampson) Date: Sun Sep 7 21:00:19 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219959914.908.55.camel@jcchost> References: <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <1219952474.908.26.camel@jcchost> <48B71788.2050708@iee.org> <1219959914.908.55.camel@jcchost> Message-ID: <20080908010221.GB24318@lucky.cynic.net> On 2008-08-28 14:45 -0700 (Thu), Jonathan Cast wrote: > Now, I happen to know that the only top-level handles that can be > established without issuing an open system call are > > stdin > stdout > stderr > > (unless you're happy to have your global nonStdErr start its life > attached to an unopened FD). I've not thought through exactly how this might relate to your argument, but certainly, though there might or might not be Haskell Handles for other file descriptors, they can start out open without calling open. Compile this simple program: #import int main() { int n; n = write(5, "foobar\n", 7); printf("write returned %d\n", n); return 0; } and run it with "./a.out 5>&1" and have a look at the result you get. cjs -- Curt Sampson +81 90 7737 2974 Mobile sites and software consulting: http://www.starling-software.com From ganesh at earth.li Mon Sep 8 00:54:44 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Sep 8 00:52:40 2008 Subject: [Haskell-cafe] Re: Top Level <- In-Reply-To: <48C45178.3040003@semantic.org> References: <534781822.20080826190130@gmail.com> <48BEE0BC.8040706 @semantic.org> <78A3C5650E28124399107F21A1FA419401D3B869@ELON17P32002A.csfb.cs-group.com> <48BFB716.4060401@semanti c.org> <78A3C5650E28124399107F21A1FA419401D3B86C@ELON17P32002A.csfb.cs-gro! up.com> <48C0C5B4.2000909@semantic.org> <78A3C5650E28124399107F21A1FA419401D3B877@ELON17P32002A.csfb.cs-group.com> <48C0F6E8.6000603@semantic.o rg> <78A3C5650E28124399107F21A1FA419401D3B87E@ELON17P32002A.csfb.cs-group.com> <48C18601.4050801@semantic.org> <48C23A63.7070806@semantic.org> <48C25709.7040903@s emantic.org> <48C2FED9.1060107@semantic.org> <48C45178.3040003@semantic.org> Message-ID: On Sun, 7 Sep 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> Suppose I am writing something that I intend to be used as part of a >> plug-in that is reloaded in different forms again and again. And I see >> module K which does something I want, so I use it. It so happens that K >> uses M, which has a <-. If I knew that using K in my plug-in would cause a >> memory leak, I would avoid doing so; but since the whole point of <- is to >> avoid making the need for some state visible in the API. > > The results from the <- in M will only be stored once for the life of the > RTS, no matter how many times your plug-ins are reloaded. Sorry, I keep forgetting that. OK, so you can't get an endless stream of leaks unless you use <- yourself, or modules on your system keep getting upgraded to new versions. Ganesh From gwern0 at gmail.com Mon Sep 8 01:31:05 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon Sep 8 01:30:28 2008 Subject: [Haskell-cafe] Munging wiki articles with tagsoup Message-ID: <20080908053105.GB15405@craft> Hiya Neil. So recently I've been trying to come up with some automated system to turn The Monad Reader articles like those in into wiki-formatted articles for putting on Haskell.org. Thus far, I've had the most success with SVN Pandoc. Pandoc does a good job - you can see an example conversion at . Modulo the errors which are largely due to haskell.org problems and a few limitations in Pandoc (no comments, no real support for references), it's fine. But Pandoc's author will not support tags inasmuch as they are an extension to MediaWiki and not universal; he prefers 
 or 
 tags. He suggested I use TagSoup to convert them into  tags. Well, alright. They're tags, TagSoup does tags - seems natural.

After an hour, I came up with a nice clean little script:

----

import Text.HTML.TagSoup.Render
import Text.HTML.TagSoup

main :: IO ()
main = interact convertPre

convertPre :: String -> String
convertPre = renderTags . map convertToHaskell . canonicalizeTags . parseTags

convertToHaskell :: Tag -> Tag
convertToHaskell x
               | isTagOpenName  "pre" x = TagOpen  "haskell" (extractAttribs x)
               | isTagCloseName "pre" x = TagClose "haskell"
               | otherwise              = x
                             where
                               extractAttribs :: Tag -> [Attribute]
                               extractAttribs (TagOpen _ y) = y
                               extractAttribs _             = error "The impossible happened."

----

On an aside, may I note that TagSoup doesn't seem to support transformations particularly well? Or if it does, I didn't notice any examples. I spent most of my time just figuring out how to convert the 'x' from a 
stuff to stuff. Also, it might be nice to define an 'interact' alike, which is (String -> String), and defined, I supposed, as 'interact f = renderTags . f . canonicalizeTags . parseTags'. Extraction functions would be good as well - you'd only need 3 groups, I think; 1 for the 2 items in TagOpen, 1 for TagPosition's 2 positions, and 1 which extracts the String from the rest.

Anyway, so my script seems to work. I ran the wiki output through it and this is the diff: .

Ok, good, it replaces all the tags... But wait, what's all this other stuff? It is replacing all my apostrophes with '! No doubt this has something to do with XML/HTML/SGML or whatever, but it's not ideal. Even if it doesn't break the formatting (as I think it does), it's still cluttering up the source.

So, how can I fix this? Am I just barking up the wrong tree and should be writing a simple-minded search-and-replace sed script which replaces 
 with , 
 with ...?

--
gwern
USS Enforcers SORO Morwenstow MOD Albright MI5 AOL 701 GCHQ
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/408562e9/attachment-0001.bin
From jeanchristophe.mincke at gmail.com  Mon Sep  8 03:06:09 2008
From: jeanchristophe.mincke at gmail.com (jean-christophe mincke)
Date: Mon Sep  8 03:04:05 2008
Subject: [Haskell-cafe] building unix package on windows
Message-ID: 

Hello,

I have installed GHC and cygwin on windows XP and I am trying to build the
unix package (required to install HApps)

** When I use .../ghc/gcc as c compiler I receive the following error during
the configure*

D:\temp\haskell\unix-2.3.0.0>runhaskell Setup configure --ghc
--prefix=D:\apps\h-lib
Configuring unix-2.3.0.0...
checking for gcc... gcc
checking for C compiler default output file name...
*configure: error: C compiler cannot create executables*
See `config.log' for more details.

and config.log says that :

  *  ld: crt2.o: No such file: No such file or directory*


** When I use the gcc in cygwin : /usr/bin/gcc, the configure phase is ok
but the build stop on the following error:*

D:\temp\haskell\unix-2.3.0.0>runhaskell Setup build
Preprocessing library unix-2.3.0.0...

*In file included from System\Posix\DynamicLinker\Module.hsc:57:0:

include/HsUnix.h:32:23:  sys/times.h: No such file or directory*

include/HsUnix.h:38:26:  sys/resource.h: No such file or directory

include/HsUnix.h:41:22:  sys/wait.h: No such file or directory

include/HsUnix.h:62:21:  termios.h: No such file or directory

include/HsUnix.h:65:25:  sys/utsname.h: No such file or directory

include/HsUnix.h:68:17:  pwd.h: No such file or directory

include/HsUnix.h:71:17:  grp.h: No such file or directory

include/HsUnix.h:81:17:  pty.h: No such file or directory

include/HsUnix.h:84:18:  utmp.h: No such file or directory

include/HsUnix.h:87:19:  dlfcn.h: No such file or directory

In file included from System\Posix\DynamicLinker\Module.hsc:57:0:
include/HsUnix.h: In function `__hsunix_wifexited':

include/HsUnix.h:103:0:
     warning: implicit declaration of function `WIFEXITED'
include/HsUnix.h: In function `__hsunix_wexitstatus':

include/HsUnix.h:104:0:
     warning: implicit declaration of function `WEXITSTATUS'
include/HsUnix.h: In function `__hsunix_wifsignaled':

include/HsUnix.h:105:0:
     warning: implicit declaration of function `WIFSIGNALED'
include/HsUnix.h: In function `__hsunix_wtermsig':

include/HsUnix.h:106:0:
     warning: implicit declaration of function `WTERMSIG'
include/HsUnix.h: In function `__hsunix_wifstopped':

include/HsUnix.h:107:0:
     warning: implicit declaration of function `WIFSTOPPED'
include/HsUnix.h: In function `__hsunix_wstopsig':

include/HsUnix.h:108:0:
     warning: implicit declaration of function `WSTOPSIG'
include/HsUnix.h: In function `__hsunix_rtldDefault':

include/HsUnix.h:115:0:
     error: `RTLD_DEFAULT' undeclared (first use in this function)

include/HsUnix.h:115:0:
     error: (Each undeclared identifier is reported only once

include/HsUnix.h:115:0:  error: for each function it appears in.)
include/HsUnix.h: In function `__hsunix_lstat':

include/HsUnix.h:134:0:
     warning: implicit declaration of function `lstat'
include/HsUnix.h: In function `__hsunix_mknod':

include/HsUnix.h:140:0:
     warning: implicit declaration of function `mknod'
compiling dist\build\System\Posix\DynamicLinker\Module_hsc_make.c failed
*command was: d:\apps\ghc\bin\ghc.exe -c -package base-3.0.2.0 -package
directory-1.0.0.1 -Iinclude dist\build\System\Pos
ix\DynamicLinker\Module_hsc_make.c -o
dist\build\System\Posix\DynamicLinker\Module_hsc_make.o*

Could someone help me.

Thank you

J-C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/a79cbdf1/attachment.htm
From nornagon at gmail.com  Mon Sep  8 03:19:18 2008
From: nornagon at gmail.com (Jeremy Apthorp)
Date: Mon Sep  8 03:17:33 2008
Subject: [Haskell-cafe] building unix package on windows
In-Reply-To: 
References: 
Message-ID: <346A3889-FE4A-4D11-8DF9-4C6605E61F88@gmail.com>

Those headers simply do not exist under windows. There's a reason it's  
called 'Unix' :P

Perhaps mingw32 or cygwin could help, as those packages make an  
attempt at emulating (so to speak) the unix environment.

On 08/09/2008, at 17:06, "jean-christophe mincke"  wrote:

> Hello,
>
> I have installed GHC and cygwin on windows XP and I am trying to  
> build the unix package (required to install HApps)
>
> * When I use .../ghc/gcc as c compiler I receive the following error  
> during the configure
>
> D:\temp\haskell\unix-2.3.0.0>runhaskell Setup configure --ghc -- 
> prefix=D:\apps\h-lib
> Configuring unix-2.3.0.0...
> checking for gcc... gcc
> checking for C compiler default output file name...
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
>
> and config.log says that :
>
>     ld: crt2.o: No such file: No such file or directory
>
>
> * When I use the gcc in cygwin : /usr/bin/gcc, the configure phase  
> is ok but the build stop on the following error:
>
> D:\temp\haskell\unix-2.3.0.0>runhaskell Setup build
> Preprocessing library unix-2.3.0.0...
>
> In file included from System\Posix\DynamicLinker\Module.hsc:57:0:
>
> include/HsUnix.h:32:23:  sys/times.h: No such file or directory
>
> include/HsUnix.h:38:26:  sys/resource.h: No such file or directory
>
> include/HsUnix.h:41:22:  sys/wait.h: No such file or directory
>
> include/HsUnix.h:62:21:  termios.h: No such file or directory
>
> include/HsUnix.h:65:25:  sys/utsname.h: No such file or directory
>
> include/HsUnix.h:68:17:  pwd.h: No such file or directory
>
> include/HsUnix.h:71:17:  grp.h: No such file or directory
>
> include/HsUnix.h:81:17:  pty.h: No such file or directory
>
> include/HsUnix.h:84:18:  utmp.h: No such file or directory
>
> include/HsUnix.h:87:19:  dlfcn.h: No such file or directory
>
> In file included from System\Posix\DynamicLinker\Module.hsc:57:0:
> include/HsUnix.h: In function `__hsunix_wifexited':
>
> include/HsUnix.h:103:0:
>      warning: implicit declaration of function `WIFEXITED'
> include/HsUnix.h: In function `__hsunix_wexitstatus':
>
> include/HsUnix.h:104:0:
>      warning: implicit declaration of function `WEXITSTATUS'
> include/HsUnix.h: In function `__hsunix_wifsignaled':
>
> include/HsUnix.h:105:0:
>      warning: implicit declaration of function `WIFSIGNALED'
> include/HsUnix.h: In function `__hsunix_wtermsig':
>
> include/HsUnix.h:106:0:
>      warning: implicit declaration of function `WTERMSIG'
> include/HsUnix.h: In function `__hsunix_wifstopped':
>
> include/HsUnix.h:107:0:
>      warning: implicit declaration of function `WIFSTOPPED'
> include/HsUnix.h: In function `__hsunix_wstopsig':
>
> include/HsUnix.h:108:0:
>      warning: implicit declaration of function `WSTOPSIG'
> include/HsUnix.h: In function `__hsunix_rtldDefault':
>
> include/HsUnix.h:115:0:
>      error: `RTLD_DEFAULT' undeclared (first use in this function)
>
> include/HsUnix.h:115:0:
>      error: (Each undeclared identifier is reported only once
>
> include/HsUnix.h:115:0:  error: for each function it appears in.)
> include/HsUnix.h: In function `__hsunix_lstat':
>
> include/HsUnix.h:134:0:
>      warning: implicit declaration of function `lstat'
> include/HsUnix.h: In function `__hsunix_mknod':
>
> include/HsUnix.h:140:0:
>      warning: implicit declaration of function `mknod'
> compiling dist\build\System\Posix\DynamicLinker\Module_hsc_make.c  
> failed
> command was: d:\apps\ghc\bin\ghc.exe -c -package base-3.0.2.0 - 
> package directory-1.0.0.1 -Iinclude dist\build\System\Pos
> ix\DynamicLinker\Module_hsc_make.c -o dist\build\System\Posix 
> \DynamicLinker\Module_hsc_make.o
>
> Could someone help me.
>
> Thank you
>
> J-C
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/8f4cfeb3/attachment.htm
From lionel at gamr7.com  Mon Sep  8 05:06:36 2008
From: lionel at gamr7.com (Lionel Barret De Nazaris)
Date: Mon Sep  8 04:57:12 2008
Subject: [Haskell-cafe] haskell job offer.
Message-ID: <48C4EB1C.3060408@gamr7.com>


We (Gamr7, see at the bottom) are looking from a senior dev/Technical 
director.
We don't really care about the title but we want someone good (who 
doesn't ?).
We need someone able to model *and* code well (No architect who never 
codes).
The ability to communicate well with a team is also a big plus.
You don't need to speak French (we are in France) but a reasonably good 
English is mandatory.

If You :
? like coding 4+ hours straight.
? like to solve a coding problem elegantly (and are bothered if can't)
? like and read *real* CS books (SICP, EGB, TAOCP, etc...)
? code in Haskell, python and c++.
? are a gamer (this one is optional)
? are interested in computer graphics (optional too)

You fit the bill. We would like to talk to you. Contact us (contact at 
gamr7 dot com).


What we offer:
? interesting problems and creative freedom
? quality of life (no overtime, sunny countryside, French food and low rent)
? a pay in Euros
? comfortable workplace, etc...
? coding in Haskell, python.

The boss *really * codes . He likes Haskell, Python, Reddit, and wants 
the team to be there for the long run (i.e happy).
He also modestly wrote and posted this jobs offer.

About :
Gamr7 is a startup focused on procedural city generation for the game 
and simulation market.
We are located in France, near Lyon.

-- 
Best Regards,
lionel Barret de Nazaris,
Gamr7 Founder & CTO
=========================
Gamr7 : Cities for Games
http://www.gamr7.com




From nfjinjing at gmail.com  Mon Sep  8 05:18:33 2008
From: nfjinjing at gmail.com (jinjing)
Date: Mon Sep  8 05:16:29 2008
Subject: [Haskell-cafe] experimental static blog engine in Haskell (file
	based, markdown syntax)
In-Reply-To: <20080906202618.GF16708@scytale.galois.com>
References: <81ea7d400809061228m29f046e1jf15ae496652a63bc@mail.gmail.com>
	<20080906202618.GF16708@scytale.galois.com>
Message-ID: <81ea7d400809080218l953efe6uc0063f6b500ee58d@mail.gmail.com>

It's up ( I think, since it's my first cabal ).

    cabal install panda

    kibro new ttmyblog
    cd myblog

    rm -r db; rm -r public
    git clone git://github.com/nfjinjing/panda-template.git db
    sh db/scripts/bootstrap.sh

    kibro start



On Sun, Sep 7, 2008 at 4:26 AM, Don Stewart  wrote:
> nfjinjing:
>> Hia,
>>
>> It's called Panda. It's pretty young, no theme, no tags, no comments,
>> around 360 lines of code and uses Kibro to bootstrap.
>>
>> hosted on GitHub:
>> http://github.com/nfjinjing/panda/
>>
>> a quick demo at:
>> http://jinjing.blog.easymic.com/
>
> Awesome! Kibro seems to be taking off.
>
> Will you release it on hackage.haskell.org?
>
> -- Don
>
From conal at conal.net  Mon Sep  8 06:33:47 2008
From: conal at conal.net (Conal Elliott)
Date: Mon Sep  8 06:31:42 2008
Subject: [Haskell-cafe] mailing list choices?
Message-ID: 

I want to set up some kind of mailing list for reactive (which I plan to
release soon).  The most obvious thing is to set up a mailman-based list on
haskell.org, but I wonder -- do people really want to keep using mailman
technology?  Or something more modern like Yahoo or Google groups.

I use my email reader also with Yahoo & Google groups, so my day-to-day
experience is the same as with mailman-based lists.  For less regular
operations like searching archives, I prefer the experience on Yahoo &
Google group.  And I like some of the other modern features, like personal
profiles and polls.

I've been wondering if haskellers really like mailman or are just used to
it.  Maybe people make new mailman lists simply because others did it before
them.

Any thoughts/preferences?  Thanks,

  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/53830b48/attachment.htm
From al at beshenov.ru  Mon Sep  8 06:42:16 2008
From: al at beshenov.ru (Alexey Beshenov)
Date: Mon Sep  8 06:40:56 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: 
References: 
Message-ID: <200809081442.17458.al@beshenov.ru>

On Monday 08 September 2008 14:33:47 Conal Elliott wrote:
> I want to set up some kind of mailing list for reactive (which I
> plan to release soon). ?The most obvious thing is to set up a
> mailman-based list on haskell.org, but I wonder -- do people really
> want to keep using mailman technology? ?Or something more modern
> like Yahoo or Google groups.

Mailman is nice. You can register your list at the http://gmane.org/

(see http://dir.gmane.org/index.php?prefix=gmane.comp.lang.haskell)

-- 
Sweetmorn, Bureaucracy 32, 3174 YOLD
Alexey Beshenov http://beshenov.ru/
From ganesh.sittampalam at credit-suisse.com  Mon Sep  8 06:37:07 2008
From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh)
Date: Mon Sep  8 06:48:49 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: 
References: 
Message-ID: <78A3C5650E28124399107F21A1FA419401D3B88E@ELON17P32002A.csfb.cs-group.com>

I would call Yahoo and Google groups a major step backwards from mailman.

________________________________

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Conal Elliott
Sent: 08 September 2008 11:34
To: Haskell Caf?
Subject: [Haskell-cafe] mailing list choices?


I want to set up some kind of mailing list for reactive (which I plan to release soon).  The most obvious thing is to set up a mailman-based list on haskell.org, but I wonder -- do people really want to keep using mailman technology?  Or something more modern like Yahoo or Google groups.  

I use my email reader also with Yahoo & Google groups, so my day-to-day experience is the same as with mailman-based lists.  For less regular operations like searching archives, I prefer the experience on Yahoo & Google group.  And I like some of the other modern features, like personal profiles and polls.

I've been wondering if haskellers really like mailman or are just used to it.  Maybe people make new mailman lists simply because others did it before them.

Any thoughts/preferences?  Thanks,

  - Conal


==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/f9669bdc/attachment.htm
From conal at conal.net  Mon Sep  8 07:52:04 2008
From: conal at conal.net (Conal Elliott)
Date: Mon Sep  8 07:49:59 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B88E@ELON17P32002A.csfb.cs-group.com>
References: 
	<78A3C5650E28124399107F21A1FA419401D3B88E@ELON17P32002A.csfb.cs-group.com>
Message-ID: 

In what ways?

2008/9/8 Sittampalam, Ganesh 

>  I would call Yahoo and Google groups a major step backwards from mailman.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/d2debf3b/attachment.htm
From conal at conal.net  Mon Sep  8 07:56:39 2008
From: conal at conal.net (Conal Elliott)
Date: Mon Sep  8 07:54:33 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: <200809081442.17458.al@beshenov.ru>
References: 
	<200809081442.17458.al@beshenov.ru>
Message-ID: 

gmane is indeed a nifty complement to mailman, making mailman more appealing
to me. I especially like the variety of interfaces. Thanks, Alexey.  - Conal

On Mon, Sep 8, 2008 at 12:42 PM, Alexey Beshenov  wrote:

> On Monday 08 September 2008 14:33:47 Conal Elliott wrote:
> > I want to set up some kind of mailing list for reactive (which I
> > plan to release soon).  The most obvious thing is to set up a
> > mailman-based list on haskell.org, but I wonder -- do people really
> > want to keep using mailman technology?  Or something more modern
> > like Yahoo or Google groups.
>
> Mailman is nice. You can register your list at the http://gmane.org/
>
> (see http://dir.gmane.org/index.php?prefix=gmane.comp.lang.haskell)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/fc466846/attachment.htm
From ganesh.sittampalam at credit-suisse.com  Mon Sep  8 08:07:50 2008
From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh)
Date: Mon Sep  8 08:06:33 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: 
References: 
	<78A3C5650E28124399107F21A1FA419401D3B88E@ELON17P32002A.csfb.cs-group.com>
	
Message-ID: <78A3C5650E28124399107F21A1FA419401D3B892@ELON17P32002A.csfb.cs-group.com>

The Yahoo mailing list server is notoriously unreliable and randomly
drops mails and/or drops people from lists because their email server
was temporarily refusing mails (4xx SMTP responses not 5xx). I also find
the Yahoo groups web interface absolutely awful; mailman's list archives
aren't great, but are ok for casual browsing, and you can download the
entire archives and load them up locally if you need to.
 
A quick look around Google groups suggests that my initial assumption
that it'd be as bad as Yahoo groups is probably unfounded. But if I
hadn't already given in and created a Google account for other things,
I'd be unhappy about doing so just for your list, given the way it
tracks your web browsing in ways that I don't entirely understand while
you are logged into it.

________________________________

From: conal.elliott@gmail.com [mailto:conal.elliott@gmail.com] On Behalf
Of Conal Elliott
Sent: 08 September 2008 12:52
To: Sittampalam, Ganesh
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] mailing list choices?


In what ways?


2008/9/8 Sittampalam, Ganesh 


	I would call Yahoo and Google groups a major step backwards from
mailman.



==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/0dfd9cf5/attachment.htm
From leather at cs.uu.nl  Mon Sep  8 08:12:12 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Mon Sep  8 08:10:06 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B892@ELON17P32002A.csfb.cs-group.com>
References: 
	<78A3C5650E28124399107F21A1FA419401D3B88E@ELON17P32002A.csfb.cs-group.com>
	
	<78A3C5650E28124399107F21A1FA419401D3B892@ELON17P32002A.csfb.cs-group.com>
Message-ID: <3c6288ab0809080512l58d22c3bke297f1414a3ca92@mail.gmail.com>

> The Yahoo mailing list server is notoriously unreliable and randomly drops
> mails and/or drops people from lists because their email server was
> temporarily refusing mails (4xx SMTP responses not 5xx). I also find the
> Yahoo groups web interface absolutely awful; mailman's list archives aren't
> great, but are ok for casual browsing, and you can download the entire
> archives and load them up locally if you need to.
>
> A quick look around Google groups suggests that my initial assumption that
> it'd be as bad as Yahoo groups is probably unfounded. But if I hadn't
> already given in and created a Google account for other things, I'd be
> unhappy about doing so just for your list, given the way it tracks your web
> browsing in ways that I don't entirely understand while you are logged into
> it.
>

>From "http://groups.google.com/support/bin/answer.py?answer=46438&topic=9244
":

*Activities that don't require a Google Account: *

   - Reading posts in public groups
   - Searching for groups, posts, or authors
   - Posting to groups via email if they are unrestricted or you're already
   a member
   - Joining a public Google Group via email

*Activities that require a Google Account: *

   - Creating and managing your own Google Group
   - Posting to groups via our web interface
   - Creating pages and uploading files
   - Subscribing to a Usenet newsgroup and receiving posts via email
   - Joining a Google Group via our web interface
   - Changing your subscription type (No Email, Abridged Email...)
   - Reading a restricted group's posts online


Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/7767d1cf/attachment.htm
From ccshan at post.harvard.edu  Mon Sep  8 09:30:16 2008
From: ccshan at post.harvard.edu (Chung-chieh Shan)
Date: Mon Sep  8 09:58:20 2008
Subject: [Haskell-cafe] Re: A problem with nested regions and
	higher-order?functions
References: <23051.1216949255$1220747147@news.gmane.org>
Message-ID: <80mfp5-46s.ln1@mantle.rutgers.edu>

Mario Bla??evi??  wrote in article <23051.1216949255$1220747147@news.gmane.org> in gmane.comp.lang.haskell.cafe:
> I'm trying to apply the nested regions (as in Lightweight Monadic
> Regions by Oleg Kiselyov and Chung-chieh Shan) design pattern, if
> that's the proper term, in hope to gain a bit more type safety in
> this little library I'm working on (Streaming Component Combinators,
> available on Hackage). I guess the problem is that I'm getting too
> much type safety now, because I can't get the thing to compile. ...

Hi!  Thanks for your interest.  It sounds like a promising application
of region checking.  I actually side with the type checker on this
problem:

> > type SingleHandler x y = forall r1s rs. Ancestor r1s rs =>
> >                          Handle r1s x -> Region rs y
> > type DoubleHandler x y z = forall r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) =>
> >                            Handle r1d x -> Handle r2d y -> Region rd z

Here a SingleHandler is defined as an operation, in an arbitrary region
on an arbitrary handle, that is valid as long as the region of the
operation descends from the region of the handle.  For example, reading
a string from an arbitrary open file is a "SingleHandler File String".
However, copying a string from an arbitrary open file to another fixed
file is not a SingleHandler, because such an operation is valid only
in a region that descends from the destination file handle's region!
That's what GHC complained about as it checks your mapD:

> > mapD :: (SingleHandler x z -> SingleHandler y z)
> >         -> DoubleHandler x w z -> DoubleHandler y w z
> > mapD f d = \y w-> f (\x-> d x w) y

So we really need to change the type of mapD if we want it to be
accepted by a sound type system.  The simplest way is to not require
that mapD return a DoubleHandler (a binary operation that works in an
arbitrary region):

    mapD :: ((Handle r1 x -> Region r z) ->
             (Handle r1 x -> Region r z))
         -> ((Handle r1 x -> Handle r2 w -> Region r z) ->
             (Handle r1 x -> Handle r2 w -> Region r z))
    mapD f d = \y w-> f (\x-> d x w) y

This type is a special case of the type automatically inferred for mapD
by Haskell if you omit the type signature.  Haskell doesn't have any
trouble type-checking higher-order functions, such as this mapD, but
higher-rank types can call for manual annotations, as illustrated below.

Another way to get mapD to type-check is to pass it (as its first
argument) not a SingleHandler transformer but a transformer of
operations that may work only in descendents of a given region r2.  We
want to write

    type H r2 x y = forall r1 r. (Ancestor r1 r, Ancestor r2 r) =>
                    Handle r1 x -> Region r y
    mapD :: (forall r2. H r2 x z -> H r2 y z)
            -> DoubleHandler x w z -> DoubleHandler y w z
    mapD f d = \y w-> f (\x-> d x w) y

("forall r2" takes scope over both "H r2 x z" and "H r2 y z" above) but
GHC doesn't see that we intend to unify the "r2d" in the expansion of
"DoubleHandler y w z" with the "r2" in this type signature of "mapD".
So, we need to put an explicit type annotation on the use of "f" in the
body of "mapD".  To do so, we add {-# LANGUAGE ScopedTypeVariables #-}
and expand the type synonym "DoubleHandler y w z" in the type signature
of "mapD":

    mapD :: forall x y z w r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) =>
               (forall r2. H r2 x z -> H r2 y z)
            -> DoubleHandler x w z
            -> Handle r1d y -> Handle r2d w -> Region rd z
    mapD f d = \y w-> (f :: H r2d x z -> H r2d y z) (\x-> d x w) y

Not so pretty anymore, but it does pass the type checker (GHC 6.8.2).

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
-----
Ken Shan

From si at fh-wedel.de  Mon Sep  8 11:27:11 2008
From: si at fh-wedel.de (Uwe Schmidt)
Date: Mon Sep  8 11:23:39 2008
Subject: [Haskell-cafe] HXT from schema to data model
Message-ID: <200809081727.11520.si@fh-wedel.de>

Hello Pierre-Edouard,

> Is there a way to generate a data model and a set of picklers from an XML (or
> RelaxNG) Schema using the HXT tool box?

the generation of a DTD out of the picklers is in an experimental stage.
The generation of a RelaxNG Schema is technically possible, but it's an
open project. It's on our TODO list for HXT.

Validation with RelaxNG within HXT is complete. What is missinig is a complete
datatype library for XML Schema Datatypes. The still missing part of the
W3C XML Schema datatype library are the datatypes for date and time,
all others are implemented.

Cheers,

 Uwe
-- 

Uwe Schmidt
FH Wedel
http://www.fh-wedel.de/~si/
From noteed at gmail.com  Mon Sep  8 14:11:41 2008
From: noteed at gmail.com (minh thu)
Date: Mon Sep  8 14:09:35 2008
Subject: [Haskell-cafe] monadic map on a Data.IntMap
Message-ID: <40a414c20809081111g3745f62dt6db33c2945f5bb4a@mail.gmail.com>

Hi,

Is there something like a fmapM_ ?
In particular, I'd like to mapM_ a Data.IntMap instead of a List

Thank you,
Thu
From jefferson.r.heard at gmail.com  Mon Sep  8 14:15:04 2008
From: jefferson.r.heard at gmail.com (Jefferson Heard)
Date: Mon Sep  8 14:13:00 2008
Subject: [Haskell-cafe] monadic map on a Data.IntMap
In-Reply-To: <40a414c20809081111g3745f62dt6db33c2945f5bb4a@mail.gmail.com>
References: <40a414c20809081111g3745f62dt6db33c2945f5bb4a@mail.gmail.com>
Message-ID: <4165d3a70809081115w271a5b2dte3b0bef621c1b07a@mail.gmail.com>

I suppose a

mapM_ monadicFunction . Data.IntMap.toList $ m

doesn't work for you?

On Mon, Sep 8, 2008 at 2:11 PM, minh thu  wrote:
> Hi,
>
> Is there something like a fmapM_ ?
> In particular, I'd like to mapM_ a Data.IntMap instead of a List
>
> Thank you,
> Thu
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards
From chaddai.fouche at gmail.com  Mon Sep  8 14:56:26 2008
From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=)
Date: Mon Sep  8 14:54:20 2008
Subject: [Haskell-cafe] monadic map on a Data.IntMap
In-Reply-To: <40a414c20809081111g3745f62dt6db33c2945f5bb4a@mail.gmail.com>
References: <40a414c20809081111g3745f62dt6db33c2945f5bb4a@mail.gmail.com>
Message-ID: 

2008/9/8 minh thu :
> Hi,
>
> Is there something like a fmapM_ ?
> In particular, I'd like to mapM_ a Data.IntMap instead of a List
>

The Traversable class (from Data.Traversable) includes a mapM function.
Unfortunately Data.IntMap don't provide an instance for IntMap (though
Data.Map does for Map).

-- 
Jeda?
From bruceteckel at gmail.com  Mon Sep  8 15:33:24 2008
From: bruceteckel at gmail.com (Bruce Eckel)
Date: Mon Sep  8 15:31:18 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
Message-ID: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>

As some of you on this list may know, I have struggled to understand
concurrency, on and off for many years, but primarily in the C++ and
Java domains. As time has passed and experience has stacked up, I have
become more convinced that while the world runs in parallel, we think
sequentially and so shared-memory concurrency is impossible for
programmers to get right -- not only are we unable to think in such a
way to solve the problem, the unnatural domain-cutting that happens in
shared-memory concurrency always trips you up, especially when the
scale increases.

I think that the inclusion of threads and locks in Java was just a
knee-jerk response to solving the concurrency problem. Indeed, there
were subtle threading bugs in the system until Java 5. I personally
find the Actor model to be most attractive when talking about
threading and objects, but I don't yet know where the limitations of
Actors are.

However, I keep running across comments where people claim they "must"
have shared memory concurrency. It's very hard for me to tell whether
this is just because the person knows threads or if there is truth to
it. The only semi-specific comment I've heard refers to data
parallelism, which I assumed was something like matrix inversion, but
when I checked this with an expert, he replied that matrix inversion
decomposes very nicely to separate processes without shared memory, so
now I'm not clear on what the "data parallelism requires threads"
issue refers to.

I know that both Haskell and Erlang only allow separated memory spaces
with message passing between processes, and they seem to be able to
solve a large range of problems -- but are there problems that they
cannot solve? I recently listened to an interview with Simon
Peyton-Jones where he seemed to suggest that this newsgroup might be a
helpful place to answer such questions. Thanks for any insights -- it
would be especially useful if I can point to some kind of proof one
way or another.

-- 
Bruce Eckel
From arnarbi at gmail.com  Mon Sep  8 15:53:58 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Mon Sep  8 15:51:53 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
Message-ID: <28012bc60809081253p12d644ccl53055328e4d38246@mail.gmail.com>

Hi Bruce,

On Mon, Sep 8, 2008 at 21:33, Bruce Eckel  wrote:
> I know that both Haskell and Erlang only allow separated memory spaces
> with message passing between processes, and they seem to be able to
> solve a large range of problems -- but are there problems that they
> cannot solve?

Modern Haskell has shared memory variables, so that statement
"[Haskell] only allows seperated memory spaces..." is not true in
practice. In fact, Haskell probably has the (semantically) cleanest
and best implementation of STM (Software Transactional Memory) there
is imho, which removes most of the headaches of shared memory based
concurrency without sacrificing shared memory itself.

As for the question "Is there something that the Actor model cannot do
but you can with shared memory?", I'd say the answer is probably no.
After all, you could just simulate shared memory by having one actor
manage all "shared" state.

> I recently listened to an interview with Simon
> Peyton-Jones where he seemed to suggest that this newsgroup might be a
> helpful place to answer such questions. Thanks for any insights -- it
> would be especially useful if I can point to some kind of proof one
> way or another.

I may be completely missing your point, and if so I apologize, but
does the simulation argument above suffice as a proof?

cheers,
Arnar
From noteed at gmail.com  Mon Sep  8 15:58:07 2008
From: noteed at gmail.com (minh thu)
Date: Mon Sep  8 15:56:03 2008
Subject: [Haskell-cafe] monadic map on a Data.IntMap
In-Reply-To: <4165d3a70809081115w271a5b2dte3b0bef621c1b07a@mail.gmail.com>
References: <40a414c20809081111g3745f62dt6db33c2945f5bb4a@mail.gmail.com>
	<4165d3a70809081115w271a5b2dte3b0bef621c1b07a@mail.gmail.com>
Message-ID: <40a414c20809081258m37f2671ewb36ee5ac628ba06f@mail.gmail.com>

2008/9/8 Jefferson Heard :
> I suppose a
>
> mapM_ monadicFunction . Data.IntMap.toList $ m
>
> doesn't work for you?

Well, that's what I use (IntMap.elems in fact), but isn't there some
perfromance lost ?

Thu

>
> On Mon, Sep 8, 2008 at 2:11 PM, minh thu  wrote:
>> Hi,
>>
>> Is there something like a fmapM_ ?
>> In particular, I'd like to mapM_ a Data.IntMap instead of a List
>>
>> Thank you,
>> Thu
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> I try to take things like a crow; war and chaos don't always ruin a
> picnic, they just mean you have to be careful what you swallow.
>
> -- Jessica Edwards
>
From consalus at gmail.com  Mon Sep  8 16:15:11 2008
From: consalus at gmail.com (Kyle Consalus)
Date: Mon Sep  8 16:13:07 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
Message-ID: <9cc3782b0809081315y4512aa38jdf45e185d19fcf39@mail.gmail.com>

Depending on definitions and how much we want to be concerned with
distributed systems,
I believe either model can be used to emulate the other (though it is
harder to emulate the possible
pitfalls of shared memory with CSP).

To me, it seems somewhat similar to garbage collection vs manually
memory management.
You can choose the potential to be more clever than the computer at
the risk of finding
the problem is more clever than you are.

Anyway, for the time being I believe there are operations that can be
done with shared memory
that can't be done with message passing if we make "good performance"
a requirement.

On Mon, Sep 8, 2008 at 12:33 PM, Bruce Eckel  wrote:
> As some of you on this list may know, I have struggled to understand
> concurrency, on and off for many years, but primarily in the C++ and
> Java domains. As time has passed and experience has stacked up, I have
> become more convinced that while the world runs in parallel, we think
> sequentially and so shared-memory concurrency is impossible for
> programmers to get right -- not only are we unable to think in such a
> way to solve the problem, the unnatural domain-cutting that happens in
> shared-memory concurrency always trips you up, especially when the
> scale increases.
>
> I think that the inclusion of threads and locks in Java was just a
> knee-jerk response to solving the concurrency problem. Indeed, there
> were subtle threading bugs in the system until Java 5. I personally
> find the Actor model to be most attractive when talking about
> threading and objects, but I don't yet know where the limitations of
> Actors are.
>
> However, I keep running across comments where people claim they "must"
> have shared memory concurrency. It's very hard for me to tell whether
> this is just because the person knows threads or if there is truth to
> it. The only semi-specific comment I've heard refers to data
> parallelism, which I assumed was something like matrix inversion, but
> when I checked this with an expert, he replied that matrix inversion
> decomposes very nicely to separate processes without shared memory, so
> now I'm not clear on what the "data parallelism requires threads"
> issue refers to.
>
> I know that both Haskell and Erlang only allow separated memory spaces
> with message passing between processes, and they seem to be able to
> solve a large range of problems -- but are there problems that they
> cannot solve? I recently listened to an interview with Simon
> Peyton-Jones where he seemed to suggest that this newsgroup might be a
> helpful place to answer such questions. Thanks for any insights -- it
> would be especially useful if I can point to some kind of proof one
> way or another.
>
> --
> Bruce Eckel
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From briqueabraque at yahoo.com  Mon Sep  8 17:56:44 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Mon Sep  8 17:54:55 2008
Subject: [Haskell-cafe] STM and FFI
Message-ID: 

Hi,

Is it possible to use foreign function
interface with STMs? If so, where can I
find examples?

Thanks,
Maur?cio

From ross at soi.city.ac.uk  Mon Sep  8 18:02:40 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Mon Sep  8 18:00:37 2008
Subject: [Haskell-cafe] monadic map on a Data.IntMap
In-Reply-To: 
References: <40a414c20809081111g3745f62dt6db33c2945f5bb4a@mail.gmail.com>
	
Message-ID: <20080908220240.GA10927@soi.city.ac.uk>

On Mon, Sep 08, 2008 at 08:56:26PM +0200, Chadda? Fouch? wrote:
> Unfortunately Data.IntMap don't provide an instance for IntMap (though
> Data.Map does for Map).

It was an oversight.  The instance is straightforward:

instance Traversable IntMap where
    traverse _ Nil = pure Nil
    traverse f (Tip k v) = Tip k <$> f v
    traverse f (Bin p m l r) = Bin p m <$> traverse f l <*> traverse f r
From david.hotham at blueyonder.co.uk  Mon Sep  8 18:13:00 2008
From: david.hotham at blueyonder.co.uk (David Hotham)
Date: Mon Sep  8 18:10:57 2008
Subject: [Haskell-cafe] Re: building unix package on windows
Message-ID: <48C5A36C.7060701@blueyonder.co.uk>

But the unix package isn't actually required to build HAppS on Windows.  
If you remove the dependency from the .cabal file (and also remove the 
-DUNIX build option) then you'll be fine.

From iavor.diatchki at gmail.com  Mon Sep  8 19:26:37 2008
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon Sep  8 19:24:31 2008
Subject: [Haskell-cafe] Hackage policy question
Message-ID: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>

Hi,
I just noticed that hackage has introduced a new policy to disallow
changes to a package without bumping the version.  I understand that
this is probably a good idea for changes to the source code, but it
really would be nice to have a backdoor that allows for other changes.
 For example, I just uploaded a package, and realized that I forgot to
add a home-page entry in the cabal file.  I do not plan to increase
the version number of my application, only so that I can upload a new
version (the source code has not changed after all!).  I can imagine
similar problems related to fixing typos in the description, and other
fixes to the meta-data.

So, could we please revert to the old policy? (if we really want to be
fancy, the hackage upload script could check that the source code, and
other fields, such as LICENSE have not changed, as these should really
bump the version... in the mean time though, I think just being
responsible members of the community would work just as well!).

-Iavor
From vss at 73rus.com  Mon Sep  8 19:57:20 2008
From: vss at 73rus.com (Vlad Skvortsov)
Date: Mon Sep  8 19:55:24 2008
Subject: [Haskell-cafe] [Fwd: profiling in haskell]
Message-ID: <48C5BBE0.6060509@73rus.com>

Posting to cafe since I got just one reply on beginner@. I was suggested 
to include more SCC annotations, but that didn't help. The 'serialize' 
function is still reported to consume about 32% of running time, 29% 
inherited. However, functions called from it only account for about 3% 
of time.

How do I get more insight into that?

Thanks.

-- 
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com

-------------- next part --------------
An embedded message was scrubbed...
From: Vlad Skvortsov 
Subject: profiling in haskell
Date: Thu, 28 Aug 2008 15:37:56 -0700
Size: 1521
Url: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/19f2329b/profilinginhaskell.eml
From vss at 73rus.com  Mon Sep  8 20:24:59 2008
From: vss at 73rus.com (Vlad Skvortsov)
Date: Mon Sep  8 20:22:55 2008
Subject: [Haskell-cafe] haskell core definition
Message-ID: <48C5C25B.3010204@73rus.com>

Hi,

I'm trying to profile my haskell code (see thread "profiling in 
haskell") and to get more insight I made GHC produce the haskell Core 
code. However, I'm not quite sure how to interpret it, is there a 
definition (quick search didn't reveal one)?

Also, how do I demangle the names? It seems that, for example,  
'base:GHC.Base.ZC' is a (:) function on strings, but where how am I 
supposed to figure that out?

Thanks!

-- 
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com

From ashley at semantic.org  Mon Sep  8 20:49:58 2008
From: ashley at semantic.org (Ashley Yakeley)
Date: Mon Sep  8 20:47:52 2008
Subject: [Haskell-cafe] Re: haskell core definition
In-Reply-To: <48C5C25B.3010204@73rus.com>
References: <48C5C25B.3010204@73rus.com>
Message-ID: <48C5C836.8080904@semantic.org>

Vlad Skvortsov wrote:
> Also, how do I demangle the names? It seems that, for example,  
> 'base:GHC.Base.ZC' is a (:) function on strings, but where how am I 
> supposed to figure that out?
-------------- next part --------------
#!/usr/bin/perl
# Written by Ashley Yakeley 2003
# All rights to the public

while (<>)
	{
	s/_/ /g;
	s/\w+/decode($&)/eg;
	print;
	}

sub commas
	{
	local($i) = @_;
	if ($i == 0)
		{
		return "";
		}
	elsif ($i == 1)
		{
		return " ";
		}
	else
		{
		return "," x ($i - 1);
		}
	}

sub decode
	{
	local($s) = @_;
	my $a="";
	while ($s =~/([^zZ]*)([zZ].*)/)
		{
		$a.=$1;
		if ($2 =~/([zZ][A-Za-z])(.*)/)
			{
				{
				$a.="(",last if $1 =~/ZL/;
				$a.=")",last if $1 =~/ZR/;
				$a.="[",last if $1 =~/ZM/;
				$a.="]",last if $1 =~/ZN/;
				$a.=":",last if $1 =~/ZC/;
				$a.="Z",last if $1 =~/ZZ/;

				$a.="z",last if $1 =~/zz/;
				$a.="&",last if $1 =~/za/;
				$a.="|",last if $1 =~/zb/;
				$a.="^",last if $1 =~/zc/;
				$a.='$',last if $1 =~/zd/;
				$a.="=",last if $1 =~/ze/;
				$a.=">",last if $1 =~/zg/;
				$a.="#",last if $1 =~/zh/;
				$a.=".",last if $1 =~/zi/;
				$a.="<",last if $1 =~/zl/;
				$a.="-",last if $1 =~/zm/;
				$a.="!",last if $1 =~/zn/;
				$a.="+",last if $1 =~/zp/;
				$a.="'",last if $1 =~/zq/;
				$a.="\\",last if $1 =~/zr/;
				$a.="/",last if $1 =~/zs/;
				$a.="*",last if $1 =~/zt/;
				$a.="_",last if $1 =~/zu/;
				$a.="%",last if $1 =~/zv/;
				$a.="???";
				}
			$s = $2;
			}
		elsif ($2 =~/Z([0-9]+)T(.*)/)
			{
			$a.="(".commas($1).")";
			$s = $2;
			}
		elsif ($2 =~/Z([0-9]+)H(.*)/)
			{
			$a.="(#".commas($1)."#)";
			$s = $2;
			}
		elsif ($2 =~/Z([0-9]+)U(.*)/)
			{
			$a.=chr($1);
			$s = $2;
			}
		else
			{
			$a.="???".$2;
			$s = "";
			}
		};
	return $a.$s;
	};
From tim at goddard.net.nz  Mon Sep  8 21:00:33 2008
From: tim at goddard.net.nz (Timothy Goddard)
Date: Mon Sep  8 20:58:29 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
Message-ID: <200809091300.33794.tim@goddard.net.nz>

On Tue, 09 Sep 2008 07:33:24 Bruce Eckel wrote:
> I know that both Haskell and Erlang only allow separated memory spaces
> with message passing between processes, and they seem to be able to
> solve a large range of problems -- but are there problems that they
> cannot solve? I recently listened to an interview with Simon
> Peyton-Jones where he seemed to suggest that this newsgroup might be a
> helpful place to answer such questions. Thanks for any insights -- it
> would be especially useful if I can point to some kind of proof one
> way or another.

In Haskell it is  simply irrelevant whether parts of the structures being 
passed between threads are shared or not because the structures are 
immutable. We keep our code side-effect free and as a result it is incredibly 
easy to make parallel. This is so solid that we can also add implicit 
threading to the code with simple annotations such as 'par' and 'seq'.

Having said this, it is possible to generate structures which are mutable and 
only accessible in the IO monad. As a general rule, IO code using shared 
memory has the same threading issues as in any other language while pure code 
is guaranteed safe. Haskell is capable of working with both models, but 
mutable data structures are deliberately restricted in their use and are rare 
in practice.

A great deal of parallelism can be added to pure code without any risk. I 
can't assist with mathematical proofs, but can't think of any reason why 
shared, manipulable memory would be absolutely necessary. In the worst case, 
all operations on the data structure can be converted to messages to a 
central thread which manages that structure and serialises access. Any 
procedure call can become an asynchronous pair of request, response messages. 

I am not a mathematician, I can't prove it, but I can't think of circumstances 
where I would need to put mutable references in a data structure except where 
the language and compiler can't handle immutable structures efficiently.

Tim
From allbery at ece.cmu.edu  Mon Sep  8 21:11:18 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Mon Sep  8 21:09:15 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <200809091300.33794.tim@goddard.net.nz>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<200809091300.33794.tim@goddard.net.nz>
Message-ID: <8D724932-2B4A-41DF-8DBA-BA63BFC9BCC9@ece.cmu.edu>

On 2008 Sep 8, at 21:00, Timothy Goddard wrote:
> I am not a mathematician, I can't prove it, but I can't think of  
> circumstances
> where I would need to put mutable references in a data structure  
> except where
> the language and compiler can't handle immutable structures  
> efficiently.


The status registers of memory-mapped devices come to mind.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From dmehrtash at gmail.com  Mon Sep  8 21:13:27 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Mon Sep  8 21:11:20 2008
Subject: [Haskell-cafe] Field names
Message-ID: 

In type section of the Gentle Introduction to Haskell
http://www.cs.sfu.ca/CC/SW/Haskell/hugs/tutorial-1.4-html/moretypes.htmlthere
is this example:


> data Point = Pt {pointx, pointy :: Float}



> abs (Pt {pointx = x, pointy = y}) = sqrt (x*x + y+y)


Why is it pointx=x and not x=pointx?

-- 
Daryoush

Weblog: http://perlustration.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/76a68f0b/attachment.htm
From briqueabraque at yahoo.com  Mon Sep  8 21:37:17 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Mon Sep  8 21:35:20 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: 
References: 
Message-ID: 


>     abs (Pt {pointx = x, pointy = y}) = sqrt (x*x + y+y) 
> 
> 
> Why is it pointx=x and not x=pointx?
> 

Your intuition is probably telling you that this
is something like:

abs (point) = sqrt (x*x+y*y)
   where {x=pointx point ; y=pointy point}

Actually, it's an example of pattern matching:

abs (Pt {pointx=3 , pointy=4}) = 5
abs (Pt {pointx=3 , pointy=y}) = sqrt (9+y*y)
abs (Pt {pointx=z , pointy=z}) = (sqrt 2)*z

etc.

Best,
Maur?cio

From ok at cs.otago.ac.nz  Mon Sep  8 22:21:10 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon Sep  8 22:19:09 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <19648_1220924124_m891ZMma001662_200809091300.33794.tim@goddard.net.nz>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<19648_1220924124_m891ZMma001662_200809091300.33794.tim@goddard.net.nz>
Message-ID: <148124DB-E81A-4622-8100-F56E0C7C1941@cs.otago.ac.nz>

I think the demonstration is in Hoare's book on co-operating
sequential processes, but if you have pure processes and
message passing, you can simulate conventional variables.
Here's an Erlang version:

     variable_loop(State) ->
         receive
             {ask,Sender} -> Sender!{self(),State}, variable_loop(State)
           ; {tell,New_State} -> variable_loop(New_State)
         end.

     new_variable(Initial_State) ->
         spawn(fun () -> variable_loop(Initial_State) end).

     fetch(Variable) ->
         Variable!{ask,self()},
         receive {Variable,State} -> State end.

     store(Variable, New_State) ->
         Variable!{tell,New_State}.

     new_array(Size, Initial_State) ->
         list_to_tuple([new_variable(Initial_State)
                       || Dummy <- lists:seq(1, Size)]).

     fetch(Array, Index) ->
         fetch(element(Index, Array)).

     store(Array, Index, New_State) ->
         store(element(Index, Array), New_State).

The simulation of (shared) mutable variables and arrays in pure
CSP is very similar.  This pretty much _has_ to be possible in
any language that has concurrent processes that can communicate
in some fashion.  There are also quite elementary ways to
simulate locking.  So we can solve any concurrent problem that,
say, C++ with Intel's TBB library, or Java with java.util.concurrent,
or any other such language can solve.  We can even get ourselves
just as far into extremely serious trouble as we can using those
languages, it's just that we don't _have_ to.

--
If stupidity were a crime, who'd 'scape hanging?







From ok at cs.otago.ac.nz  Mon Sep  8 22:34:03 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon Sep  8 22:32:01 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <29565_1220904929_m88KFRK7002382_9cc3782b0809081315y4512aa38jdf45e185d19fcf39@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<29565_1220904929_m88KFRK7002382_9cc3782b0809081315y4512aa38jdf45e185d19fcf39@mail.gmail.com>
Message-ID: <66B2D1EC-691C-45F0-8576-472E71BE4618@cs.otago.ac.nz>


On 9 Sep 2008, at 8:15 am, Kyle Consalus wrote:

> Anyway, for the time being I believe there are operations that can be
> done with shared memory
> that can't be done with message passing if we make "good performance"
> a requirement.

One of our people here has been working on Distributed Shared Memory
for some years.  It's a programming model where you write AS IF you
had shared memory, but you really don't.  He actually uses plain C
with a library, but I've got a student project to wrap some syntax
around that.

	typedef struct Foo { ... variables ... } Foo;
	typedef struct Bar { ... variables ... } Bar;
	shared Foo foo;
	shared Bar bar;

	shared (const *f = &foo) {
	    ... here we have read access to f->variables ...
	}
	shared (*b = &bar) {
	    ... here we have read-write access to b->variables ...
	}

Underneath, it's message passing.  When you get a view on a
shared region, a copy is fetched from the cheapest source that has
a current copy.  When you release a write view, you become the
holder of the only current copy.  Compressed differences are
sent around the local net.  Zhiyi Huang's library is called VODCA.
There's a plug-compatible version developed by his colleagues in
China called Maotai, so the _same_ code can be run on a multicore
system or on a network of workstations.  The trick is to choose the
chunk size of your problem so that computation and communication
costs are in the right balance.  This certainly seems to be adequate
for numerical software, raytracing, game playing, ...

One issue is that real shared memory comes at a price that most
people don't know they are paying.  We wouldn't need MOESI
protocols or the related bus traffic if there were known to be
no sharing, and one of the things that gets in the way of
massive multicore is keeping caches coherent.  No shared memory
=> no coherence problem => no extra bus traffic => faster.

--
If stupidity were a crime, who'd 'scape hanging?







From dons at galois.com  Mon Sep  8 22:36:57 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep  8 22:34:46 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: 
References: 
Message-ID: <20080909023657.GB25455@scytale.galois.com>

briqueabraque:
> Hi,
> 
> Is it possible to use foreign function
> interface with STMs? If so, where can I
> find examples?
> 

Defintely possible. FFI functions are imported as normal functions, so
use them wherever the types fit.
From dons at galois.com  Tue Sep  9 00:25:25 2008
From: dons at galois.com (Don Stewart)
Date: Tue Sep  9 00:24:02 2008
Subject: [Haskell-cafe] haskell job offer.
In-Reply-To: <48C4EB1C.3060408@gamr7.com>
References: <48C4EB1C.3060408@gamr7.com>
Message-ID: <20080909042525.GM25455@scytale.galois.com>


Welcome to the community!

I've added details about Gamr7 to the industry page,

    http://haskell.org/haskellwiki/Haskell_in_industry

-- Don

lionel:
> 
> We (Gamr7, see at the bottom) are looking from a senior dev/Technical 
> director.
> We don't really care about the title but we want someone good (who 
> doesn't ?).
> We need someone able to model *and* code well (No architect who never 
> codes).
> The ability to communicate well with a team is also a big plus.
> You don't need to speak French (we are in France) but a reasonably good 
> English is mandatory.
> 
> If You :
> ? like coding 4+ hours straight.
> ? like to solve a coding problem elegantly (and are bothered if can't)
> ? like and read *real* CS books (SICP, EGB, TAOCP, etc...)
> ? code in Haskell, python and c++.
> ? are a gamer (this one is optional)
> ? are interested in computer graphics (optional too)
> 
> You fit the bill. We would like to talk to you. Contact us (contact at 
> gamr7 dot com).
> 
> 
> What we offer:
> ? interesting problems and creative freedom
> ? quality of life (no overtime, sunny countryside, French food and low 
> rent)
> ? a pay in Euros
> ? comfortable workplace, etc...
> ? coding in Haskell, python.
> 
> The boss *really * codes . He likes Haskell, Python, Reddit, and wants 
> the team to be there for the long run (i.e happy).
> He also modestly wrote and posted this jobs offer.
> 
> About :
> Gamr7 is a startup focused on procedural city generation for the game 
> and simulation market.
> We are located in France, near Lyon.
> 
> -- 
> Best Regards,
> lionel Barret de Nazaris,
> Gamr7 Founder & CTO
> =========================
> Gamr7 : Cities for Games
> http://www.gamr7.com
> 
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From dons at galois.com  Tue Sep  9 00:32:32 2008
From: dons at galois.com (Don Stewart)
Date: Tue Sep  9 00:30:23 2008
Subject: [Haskell-cafe] haskell job offer.
In-Reply-To: <20080909042525.GM25455@scytale.galois.com>
References: <48C4EB1C.3060408@gamr7.com>
	<20080909042525.GM25455@scytale.galois.com>
Message-ID: <20080909043232.GN25455@scytale.galois.com>

And for those who didn't see the original release announcement, check
out their website..

    http://gamr7.com/

That's kind of awesome. Could you say more about what you're using
Haskell for, Lionel?

-- Don

dons:
> 
> Welcome to the community!
> 
> I've added details about Gamr7 to the industry page,
> 
>     http://haskell.org/haskellwiki/Haskell_in_industry
> 
> -- Don
> 
> lionel:
> > 
> > We (Gamr7, see at the bottom) are looking from a senior dev/Technical 
> > director.
> > We don't really care about the title but we want someone good (who 
> > doesn't ?).
> > We need someone able to model *and* code well (No architect who never 
> > codes).
> > The ability to communicate well with a team is also a big plus.
> > You don't need to speak French (we are in France) but a reasonably good 
> > English is mandatory.
> > 
> > If You :
> > ? like coding 4+ hours straight.
> > ? like to solve a coding problem elegantly (and are bothered if can't)
> > ? like and read *real* CS books (SICP, EGB, TAOCP, etc...)
> > ? code in Haskell, python and c++.
> > ? are a gamer (this one is optional)
> > ? are interested in computer graphics (optional too)
> > 
> > You fit the bill. We would like to talk to you. Contact us (contact at 
> > gamr7 dot com).
> > 
> > 
> > What we offer:
> > ? interesting problems and creative freedom
> > ? quality of life (no overtime, sunny countryside, French food and low 
> > rent)
> > ? a pay in Euros
> > ? comfortable workplace, etc...
> > ? coding in Haskell, python.
> > 
> > The boss *really * codes . He likes Haskell, Python, Reddit, and wants 
> > the team to be there for the long run (i.e happy).
> > He also modestly wrote and posted this jobs offer.
> > 
> > About :
> > Gamr7 is a startup focused on procedural city generation for the game 
> > and simulation market.
> > We are located in France, near Lyon.
> > 
> > -- 
> > Best Regards,
> > lionel Barret de Nazaris,
> > Gamr7 Founder & CTO
> > =========================
> > Gamr7 : Cities for Games
> > http://www.gamr7.com
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From dmehrtash at gmail.com  Tue Sep  9 01:28:45 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Tue Sep  9 01:26:36 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: 
References: 
	
Message-ID: 

Thanks.

Pattern matching and memory management in Haskell (or may be GHC
implementation of it) is somewhat of a mystery to me.  Are there any
references that explains the underlying implementation?

Daryoush

On Mon, Sep 8, 2008 at 6:37 PM, Mauricio  wrote:

>
>     abs (Pt {pointx = x, pointy = y}) = sqrt (x*x + y+y)
>>
>> Why is it pointx=x and not x=pointx?
>>
>>
> Your intuition is probably telling you that this
> is something like:
>
> abs (point) = sqrt (x*x+y*y)
>  where {x=pointx point ; y=pointy point}
>
> Actually, it's an example of pattern matching:
>
> abs (Pt {pointx=3 , pointy=4}) = 5
> abs (Pt {pointx=3 , pointy=y}) = sqrt (9+y*y)
> abs (Pt {pointx=z , pointy=z}) = (sqrt 2)*z
>
> etc.
>
> Best,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Daryoush

Weblog: http://perlustration.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/ab6e770c/attachment.htm
From dmehrtash at gmail.com  Tue Sep  9 02:39:45 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Tue Sep  9 02:37:37 2008
Subject: [Haskell-cafe] trying to understand monad transformers....
Message-ID: 

The MaybeT transformer is defined as:

newtype MaybeT m a = MaybeT {runMaybeT :: m (Maybe

a)}

instance Functor

m => Functor 
(MaybeT m) where
  fmap 
f x = MaybeT $ 
fmap 
(fmap 
f) $ 
runMaybeT x

....


Question:  What does "runMaybeT x" mean?


Thanks,

Daryoush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080908/fce08296/attachment.htm
From magnus at therning.org  Tue Sep  9 03:05:16 2008
From: magnus at therning.org (Magnus Therning)
Date: Tue Sep  9 03:03:08 2008
Subject: [Haskell-cafe] trying to understand monad transformers....
In-Reply-To: 
References: 
Message-ID: 

2008/9/9 Daryoush Mehrtash :
> The MaybeT transformer is defined as:
>
> newtype MaybeT m a = MaybeT {runMaybeT :: m (Maybe a)}
>
>
> instance Functor m => Functor (MaybeT m) where
>
>   fmap f x = MaybeT $ fmap (fmap f) $ runMaybeT x
>
>
> ....
>
> Question:  What does "runMaybeT x" mean?

If you mean "what does it do?" then the answer is that it unwraps the
MaybeT so that you can get to the inner value.  If you mean "how does
it do it?" then I believe the best thing is to read some of the
chapters in RWH because I think I recognise a rather common
Haskell-pattern here.  I don't remember which ones, but I'm sure
others on this list have better memory than I do ;-)

If this isn't what you were looking for, then I haven't understood the
question :-)

/M
From lionel at gamr7.com  Tue Sep  9 04:46:07 2008
From: lionel at gamr7.com (Lionel Barret De Nazaris)
Date: Tue Sep  9 04:36:35 2008
Subject: [Haskell-cafe] haskell job offer.
In-Reply-To: <20080909043232.GN25455@scytale.galois.com>
References: <48C4EB1C.3060408@gamr7.com>
	<20080909042525.GM25455@scytale.galois.com>
	<20080909043232.GN25455@scytale.galois.com>
Message-ID: <48C637CF.7080206@gamr7.com>

Thank you for the warm welcome.

About the use of Haskell, it will be for our (urban) rule-based 
generation engines (there is a recursive stack of them).
Think about a declarative geographic compiler and you're on the right track.

This engines are not in Haskell right now but it *should* be because for 
it we have reproduced many Haskell features (monads, lazy evaluation and 
so on).
Greenspun's Tenth Rule (for Haskell) is really at work there.

The first task on the job will be to port one of the engine. But this is 
only the tip of the iceberg...

The final goal is to generate in real time an infinite city with as much 
detail as the current top games.
And, obviously, to able to create that in an afternoon :).

So you see, there is many interesting things to do.

-- Lionel

-- 
Best Regards,
lionel Barret de Nazaris,
Gamr7 Founder & CTO
=========================
Gamr7 : Cities for Games
http://www.gamr7.com




Don Stewart wrote:
> And for those who didn't see the original release announcement, check
> out their website..
>
>     http://gamr7.com/
>
> That's kind of awesome. Could you say more about what you're using
> Haskell for, Lionel?
>
> -- Don
>
> dons:
>   
>> Welcome to the community!
>>
>> I've added details about Gamr7 to the industry page,
>>
>>     http://haskell.org/haskellwiki/Haskell_in_industry
>>
>> -- Don
>>
>> lionel:
>>     
>>> We (Gamr7, see at the bottom) are looking from a senior dev/Technical 
>>> director.
>>> We don't really care about the title but we want someone good (who 
>>> doesn't ?).
>>> We need someone able to model *and* code well (No architect who never 
>>> codes).
>>> The ability to communicate well with a team is also a big plus.
>>> You don't need to speak French (we are in France) but a reasonably good 
>>> English is mandatory.
>>>
>>> If You :
>>> ? like coding 4+ hours straight.
>>> ? like to solve a coding problem elegantly (and are bothered if can't)
>>> ? like and read *real* CS books (SICP, EGB, TAOCP, etc...)
>>> ? code in Haskell, python and c++.
>>> ? are a gamer (this one is optional)
>>> ? are interested in computer graphics (optional too)
>>>
>>> You fit the bill. We would like to talk to you. Contact us (contact at 
>>> gamr7 dot com).
>>>
>>>
>>> What we offer:
>>> ? interesting problems and creative freedom
>>> ? quality of life (no overtime, sunny countryside, French food and low 
>>> rent)
>>> ? a pay in Euros
>>> ? comfortable workplace, etc...
>>> ? coding in Haskell, python.
>>>
>>> The boss *really * codes . He likes Haskell, Python, Reddit, and wants 
>>> the team to be there for the long run (i.e happy).
>>> He also modestly wrote and posted this jobs offer.
>>>
>>> About :
>>> Gamr7 is a startup focused on procedural city generation for the game 
>>> and simulation market.
>>> We are located in France, near Lyon.
>>>
>>> -- 
>>> Best Regards,
>>> lionel Barret de Nazaris,
>>> Gamr7 Founder & CTO
>>> =========================
>>> Gamr7 : Cities for Games
>>> http://www.gamr7.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>       
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>     
>
>   


From ryani.spam at gmail.com  Tue Sep  9 04:51:45 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Tue Sep  9 04:49:37 2008
Subject: [Haskell-cafe] trying to understand monad transformers....
In-Reply-To: 
References: 
Message-ID: <2f9b2d30809090151u15ef95c7g163b5201d8c3b9ae@mail.gmail.com>

2008/9/8 Daryoush Mehrtash :
> The MaybeT transformer is defined as:
>
> > newtype MaybeT m a = MaybeT {runMaybeT :: m (Maybe a)}
>
> Question:  What does "runMaybeT x" mean?

This is just shorthand for the following:

> newtype MaybeT m a = MaybeT (m (Maybe a))
> runMaybeT :: MaybeT m a -> m (Maybe a)
> runMaybeT (MaybeT x) = x

(with some minor differences to automated deriving of Show instances)

At runtime, runMaybeT and MaybeT are just really fast identity
functions (they should get optimized out of existence, even!)

So, if you have "x :: MaybeT m a" at runtime, you really just have
"runMaybeT x :: m (Maybe a)"

> instance Functor m => Functor (MaybeT m) where
>   fmap f x = MaybeT $ fmap (fmap f) $ runMaybeT x

This code is a bit confusing at first because each fmap is at a different type.

The first (in the function declaration) is
> fmap :: Functor m => (a -> b) -> MaybeT m a -> MaybeT m b

The second (*fmap* (fmap f)) is
> fmap :: Functor m => (Maybe a -> Maybe b) -> m (Maybe a) -> m (Maybe b)

The third (fmap (*fmap* f)) is
> fmap :: (a -> b) -> Maybe a -> Maybe b

When you work with functors a lot you start to be able to read this
stuff more easily.

   -- ryan
From ryani.spam at gmail.com  Tue Sep  9 05:05:56 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Tue Sep  9 05:03:47 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: 
References: 
Message-ID: <2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>

What are you trying to do?

(1) Call a foreign function from inside an STM transaction?

If the function is pure, this is trivial, just declare it as a pure
function in the foreign import statement.  You do need to be a bit
careful, however, as it is possible the function will get called with
invalid arguments, and I believe that GHC won't interrupt a thread
inside of a foreign function call.  So you need to make sure that the
function never fails to terminate, even when given bad input.
(There's an example code being called with improper arguments in
Simon's STM paper).

If the function isn't pure, you need to do a lot more proofs to assure
that this is safe.  In particular, the function must be able to be
called with invalid input.  If you are confident that this is the
case, you can use unsafeIOToSTM to convert a call to that function
into an STM primitive.

(2) Have a foreign function use transactional memory primitives?

I'm not sure that this is possible.

(3) something else?

  -- ryan

On Mon, Sep 8, 2008 at 2:56 PM, Mauricio  wrote:
> Hi,
>
> Is it possible to use foreign function
> interface with STMs? If so, where can I
> find examples?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From jules at jellybean.co.uk  Tue Sep  9 05:36:03 2008
From: jules at jellybean.co.uk (Jules Bean)
Date: Tue Sep  9 05:33:59 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: <2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>
References: 
	<2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>
Message-ID: <48C64383.20801@jellybean.co.uk>

Ryan Ingram wrote:
> If the function isn't pure, you need to do a lot more proofs to assure
> that this is safe.  In particular, the function must be able to be
> called with invalid input.  If you are confident that this is the
> case, you can use unsafeIOToSTM to convert a call to that function
> into an STM primitive.

...not only must it be safe to be called with invalid inputs, but it 
most not have any long-term effects, whether the input is valid or 
invalid, since I do not believe that there is any way for the function 
to 'undo' its effect at 'retry' time.

Jules
From briqueabraque at yahoo.com  Tue Sep  9 05:36:09 2008
From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=)
Date: Tue Sep  9 05:34:17 2008
Subject: [Haskell-cafe] Haskell and Java
Message-ID: 

Hi,

I use Haskell, and my friends at
work use Java. Do you think it
could be a good idea to use Haskell
with Java, so I could understand
and cooperate with them? Is there a
a Haskell to Java compiler that's
already ready to use?

Thanks,
Maur?cio

From arnarbi at gmail.com  Tue Sep  9 05:55:56 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Tue Sep  9 05:53:48 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: <48C64383.20801@jellybean.co.uk>
References: 
	<2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>
	<48C64383.20801@jellybean.co.uk>
Message-ID: <28012bc60809090255w1500e6e5y507eebfd1fb11614@mail.gmail.com>

On Tue, Sep 9, 2008 at 11:36, Jules Bean  wrote:
> ...not only must it be safe to be called with invalid inputs, but it most
> not have any long-term effects, whether the input is valid or invalid, since
> I do not believe that there is any way for the function to 'undo' its effect
> at 'retry' time.

Maybe this is an idea for an extension to the STM system, adding
something like unsafeIOToSTM, except that in addition to the main IO
action, it also takes two more IO actions that are invoked on rollback
and commit, respectively.

This might allow for integration with transactional systems (e.g. a
remote transaction on an rdbms), although to support two-phased commit
we'd need a third action for the "prepare" step.

cheers,
Arnar
From jules at jellybean.co.uk  Tue Sep  9 05:58:57 2008
From: jules at jellybean.co.uk (Jules Bean)
Date: Tue Sep  9 05:56:52 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: <28012bc60809090255w1500e6e5y507eebfd1fb11614@mail.gmail.com>
References: 	
	<2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>	
	<48C64383.20801@jellybean.co.uk>
	<28012bc60809090255w1500e6e5y507eebfd1fb11614@mail.gmail.com>
Message-ID: <48C648E1.2000706@jellybean.co.uk>

Arnar Birgisson wrote:
> On Tue, Sep 9, 2008 at 11:36, Jules Bean  wrote:
>> ...not only must it be safe to be called with invalid inputs, but it most
>> not have any long-term effects, whether the input is valid or invalid, since
>> I do not believe that there is any way for the function to 'undo' its effect
>> at 'retry' time.
> 
> Maybe this is an idea for an extension to the STM system, adding
> something like unsafeIOToSTM, except that in addition to the main IO
> action, it also takes two more IO actions that are invoked on rollback
> and commit, respectively.
> 
> This might allow for integration with transactional systems (e.g. a
> remote transaction on an rdbms), although to support two-phased commit
> we'd need a third action for the "prepare" step.

That would be an absolutely killer feature.

A common problem in large systems is that the underlying RDBMS supports 
transactionality, but then the software layer has to handle its own 
rollbacks. I've seen some nasty bugs when the DB rolled back and the 
software didn't.

If we could have a transactional RDBMS linked into STM with matching 
semantics, that would be a very nice thing.

Jules
From sebastian.sylvan at gmail.com  Tue Sep  9 06:03:10 2008
From: sebastian.sylvan at gmail.com (Sebastian Sylvan)
Date: Tue Sep  9 06:01:02 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
Message-ID: <3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>

On Mon, Sep 8, 2008 at 8:33 PM, Bruce Eckel  wrote:

> As some of you on this list may know, I have struggled to understand
> concurrency, on and off for many years, but primarily in the C++ and
> Java domains. As time has passed and experience has stacked up, I have
> become more convinced that while the world runs in parallel, we think
> sequentially and so shared-memory concurrency is impossible for
> programmers to get right -- not only are we unable to think in such a
> way to solve the problem, the unnatural domain-cutting that happens in
> shared-memory concurrency always trips you up, especially when the
> scale increases.
>
> I think that the inclusion of threads and locks in Java was just a
> knee-jerk response to solving the concurrency problem. Indeed, there
> were subtle threading bugs in the system until Java 5. I personally
> find the Actor model to be most attractive when talking about
> threading and objects, but I don't yet know where the limitations of
> Actors are.
>
> However, I keep running across comments where people claim they "must"
> have shared memory concurrency. It's very hard for me to tell whether
> this is just because the person knows threads or if there is truth to
> it.


For correctness, maybe not, for efficiency, yes definitely!

Imagine a program where you have a huge set of data that needs to be
modified (in some sense) over time by thousands of agents. E.g. a game
simulation.
Now, also imagine that every agent could *potentially* modify every single
piece of data, but that every agent *typically* only touches two or three
varibles here and there. I.e. the collisions between the potential
read/write sets is 100%, while the collisions for the actual read/write sets
is very very low.

How would you do this with threads and message passing? Well you could have
one big thread owning all of your data that takes "update" messages, and
then "updates" the world for you (immutably if you wish, by just replacing
its "world" variable with a new one containing your update), but now you've
effectively serialized all your interactions with the "world", so you're not
really concurrent anymore!

So you could decompose the world into multiple threads using some
application-specific logical sudivision, but then you're effectively just
treating each thread as a mutable variable with an implicit lock (with the
risks of deadlock that comes with it - remember we don't know the read/write
set in advance - it could be the entire world - so we can't just order our
updates in some global way here), so you're really just doing shared mutable
state again, and gain little from having threads "simulate" your mutable
cells...

What you really need for this is some way for each agent to update this
shared state *in parallel*, without having to block all other agents
pessimistically, but instead only block other agents if there was an
*actual* conflict. STM seems to be the only real hope for that sort of thing
right now.
IMO my list of preferred methods goes like this:
1. Purely functional data parallelism
2. Purely functional task parallelism (using e.g. strategies)
3. Message passing with no (or very minimal) shared state (simulated using
threads as "data servers" or otherwise)
(3.5. Join patterns? Don't have enough experience with this, but seems sort
of nice?)
4. Shared state concurrency using STM
5. Shared state concurrency using locks
6. Lockless programming.

So while I wouldn't resort to any shared state concurrency unless there are
good reasons for why the other methods don't work well (performance is a
good reason!), there are still situations where you need it, and a general
purpose language had better supply a way of accessing those kinds of
facilities.

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/5939d48d/attachment.htm
From arnarbi at gmail.com  Tue Sep  9 06:08:07 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Tue Sep  9 06:06:00 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: <48C648E1.2000706@jellybean.co.uk>
References: 
	<2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>
	<48C64383.20801@jellybean.co.uk>
	<28012bc60809090255w1500e6e5y507eebfd1fb11614@mail.gmail.com>
	<48C648E1.2000706@jellybean.co.uk>
Message-ID: <28012bc60809090308x5946de3bn3b71d3bbe80fa003@mail.gmail.com>

On Tue, Sep 9, 2008 at 11:58, Jules Bean  wrote:
>> Maybe this is an idea for an extension to the STM system, adding
>> something like unsafeIOToSTM, except that in addition to the main IO
>> action, it also takes two more IO actions that are invoked on rollback
>> and commit, respectively.
>>
>> This might allow for integration with transactional systems (e.g. a
>> remote transaction on an rdbms), although to support two-phased commit
>> we'd need a third action for the "prepare" step.
>
> That would be an absolutely killer feature.
>
> A common problem in large systems is that the underlying RDBMS supports
> transactionality, but then the software layer has to handle its own
> rollbacks. I've seen some nasty bugs when the DB rolled back and the
> software didn't.
>
> If we could have a transactional RDBMS linked into STM with matching
> semantics, that would be a very nice thing.

I think this is entirely doable. For comparison we already have done
this with another STM framework, the DSTM2 library for Java. I.e. we
hooked into prepare, commit and rollback and integrated with both
MySQL transactions and a transactional file system library from Apache
Commons.

I'm not yet involved enough with the GHC library code, but I guess
this would require the addition of a "prepare" phase to the STM code.

There's also the question of what to do when the remote TX system
indicates failure, should the transaction be retried or aborted? In
the DSTM2 case we make it abort and throws an exception encapsulating
the remote error to the code that initiated the TX (in Haskell's case,
the caller of atomically).

On a related note, we do have a paper on utilizing the STM system for
authorization and policy enforcement in general. The paper is to be
presented at CCS'08, and has an implementation on top of DSTM2, but we
have a technical report in the works that implements this on top of
the Haskell STM and gives operational semantics for the whole thing.

You can find the conference paper on my website:
http://www.hvergi.net/arnar/publications

cheers,
Arnar
From cmb21 at kent.ac.uk  Tue Sep  9 06:08:14 2008
From: cmb21 at kent.ac.uk (C.M.Brown)
Date: Tue Sep  9 06:06:10 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: 
References: 
Message-ID: 

Hi,

The only thing I can think of is GCJNI:

http://www.haskell.org/gcjni/

This makes use of the FFI and a Greencarded Java JNI interface. It does
allow you to call Java programs from Haskell. However, I'm not sure if it
is still supported.

hth,
Chris.


On Tue, 9 Sep 2008, [ISO-8859-1] Maur??cio wrote:

> Hi,
>
> I use Haskell, and my friends at
> work use Java. Do you think it
> could be a good idea to use Haskell
> with Java, so I could understand
> and cooperate with them? Is there a
> a Haskell to Java compiler that's
> already ready to use?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From s.clover at gmail.com  Tue Sep  9 07:58:40 2008
From: s.clover at gmail.com (Sterling Clover)
Date: Tue Sep  9 07:56:03 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: <28012bc60809090308x5946de3bn3b71d3bbe80fa003@mail.gmail.com>
References: 
	<2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>
	<48C64383.20801@jellybean.co.uk>
	<28012bc60809090255w1500e6e5y507eebfd1fb11614@mail.gmail.com>
	<48C648E1.2000706@jellybean.co.uk>
	<28012bc60809090308x5946de3bn3b71d3bbe80fa003@mail.gmail.com>
Message-ID: <8FC37ED1-011A-4565-8DE0-949910F28739@gmail.com>

I've been playing with this, and on top of STM as it exists, managed  
to neatly interleave it with sqite3 and postgres. To do so with  
postgres, however, required setting the locking mode to be a bit more  
restrictive than it is out-of-the-box. Clever use of encapsulation  
and monad transformers gets you 90% of the way there quite easily.  
Note, however, that unsafeIOToSTM is *much* more unsafe at the moment  
than you would expect -- in fact there is no "safe" way to use it at  
all, due to the interaction of exceptions and rollbacks at the  
moment. The thread about this on glasgow-haskell-users[1], along with  
my initial note, has a very useful reply by Simon Marlow where he  
both explains some things about the STM implementation and logic  
behind it that I didn't understand, and also describes how the GHC  
team intends to fix this at some point in the future.

Regards,
Sterl.

[1] http://www.nabble.com/Where-STM-is-unstable-at-the-moment%2C-and- 
how-we-can-fix-it-tc19236082.html#a19236082


On Sep 9, 2008, at 6:08 AM, Arnar Birgisson wrote:

> On Tue, Sep 9, 2008 at 11:58, Jules Bean   
> wrote:
>>> Maybe this is an idea for an extension to the STM system, adding
>>> something like unsafeIOToSTM, except that in addition to the main IO
>>> action, it also takes two more IO actions that are invoked on  
>>> rollback
>>> and commit, respectively.
>>>
>>> This might allow for integration with transactional systems (e.g. a
>>> remote transaction on an rdbms), although to support two-phased  
>>> commit
>>> we'd need a third action for the "prepare" step.
>>
>> That would be an absolutely killer feature.
>>
>> A common problem in large systems is that the underlying RDBMS  
>> supports
>> transactionality, but then the software layer has to handle its own
>> rollbacks. I've seen some nasty bugs when the DB rolled back and the
>> software didn't.
>>
>> If we could have a transactional RDBMS linked into STM with matching
>> semantics, that would be a very nice thing.
>
> I think this is entirely doable. For comparison we already have done
> this with another STM framework, the DSTM2 library for Java. I.e. we
> hooked into prepare, commit and rollback and integrated with both
> MySQL transactions and a transactional file system library from Apache
> Commons.
>
> I'm not yet involved enough with the GHC library code, but I guess
> this would require the addition of a "prepare" phase to the STM code.
>
> There's also the question of what to do when the remote TX system
> indicates failure, should the transaction be retried or aborted? In
> the DSTM2 case we make it abort and throws an exception encapsulating
> the remote error to the code that initiated the TX (in Haskell's case,
> the caller of atomically).
>
> On a related note, we do have a paper on utilizing the STM system for
> authorization and policy enforcement in general. The paper is to be
> presented at CCS'08, and has an implementation on top of DSTM2, but we
> have a technical report in the works that implements this on top of
> the Haskell STM and gives operational semantics for the whole thing.
>
> You can find the conference paper on my website:
> http://www.hvergi.net/arnar/publications
>
> cheers,
> Arnar
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From conal at conal.net  Tue Sep  9 08:00:09 2008
From: conal at conal.net (Conal Elliott)
Date: Tue Sep  9 07:58:02 2008
Subject: [Haskell-cafe] packages and QuickCheck
Message-ID: 

How do folks like to package up QuickCheck tests for their libraries?  In
the main library?  As a separate repo & package?  Same repo & separate
package?  Keeping tests with the tested code allows testing of non-exported
functionality, but can add quite a lot of clutter.

My current leaning is to split a package "foo" into packages "foo" and
"foo-test", but first I'd like to hear about others' experiences, insights,
and preferences.

Thanks,  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/8f25b248/attachment.htm
From arnarbi at gmail.com  Tue Sep  9 09:02:04 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Tue Sep  9 08:59:56 2008
Subject: [Haskell-cafe] STM and FFI
In-Reply-To: <8FC37ED1-011A-4565-8DE0-949910F28739@gmail.com>
References: 
	<2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>
	<48C64383.20801@jellybean.co.uk>
	<28012bc60809090255w1500e6e5y507eebfd1fb11614@mail.gmail.com>
	<48C648E1.2000706@jellybean.co.uk>
	<28012bc60809090308x5946de3bn3b71d3bbe80fa003@mail.gmail.com>
	<8FC37ED1-011A-4565-8DE0-949910F28739@gmail.com>
Message-ID: <28012bc60809090602k4b249d1ds8192fb697fede25b@mail.gmail.com>

On Tue, Sep 9, 2008 at 13:58, Sterling Clover  wrote:
> I've been playing with this, and on top of STM as it exists, managed to
> neatly interleave it with sqite3 and postgres. To do so with postgres,
> however, required setting the locking mode to be a bit more restrictive than
> it is out-of-the-box. Clever use of encapsulation and monad transformers
> gets you 90% of the way there quite easily. Note, however, that
> unsafeIOToSTM is *much* more unsafe at the moment than you would expect --
> in fact there is no "safe" way to use it at all, due to the interaction of
> exceptions and rollbacks at the moment. The thread about this on
> glasgow-haskell-users[1], along with my initial note, has a very useful
> reply by Simon Marlow where he both explains some things about the STM
> implementation and logic behind it that I didn't understand, and also
> describes how the GHC team intends to fix this at some point in the future.

This is very interesting, do you have any code to release?

Thanks for the ghu link, registering for that ML now :)

cheers,
Arnar
From donnchadh at gmail.com  Tue Sep  9 09:03:25 2008
From: donnchadh at gmail.com (=?UTF-8?Q?Donnchadh_=C3=93_Donnabh=C3=A1in?=)
Date: Tue Sep  9 09:01:16 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: 
References: 
Message-ID: <409751260809090603k7c01537j6d9dcadf873c047b@mail.gmail.com>

It's not haskell to java compiler but you might find cohatoe and
eclipsefp interesting:

http://cohatoe.blogspot.com/
http://eclipsefp.sourceforge.net/

  Donnchadh

2008/9/9 Maur??cio :
> Hi,
>
> I use Haskell, and my friends at
> work use Java. Do you think it
> could be a good idea to use Haskell
> with Java, so I could understand
> and cooperate with them? Is there a
> a Haskell to Java compiler that's
> already ready to use?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From dougal at dougalstanton.net  Tue Sep  9 09:05:55 2008
From: dougal at dougalstanton.net (Dougal Stanton)
Date: Tue Sep  9 09:03:47 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
References: 
Message-ID: <2d3641330809090605m55717969jfea5f72f525a0053@mail.gmail.com>

2008/9/9 Conal Elliott :
> How do folks like to package up QuickCheck tests for their libraries?  In
> the main library?  As a separate repo & package?  Same repo & separate
> package?  Keeping tests with the tested code allows testing of non-exported
> functionality, but can add quite a lot of clutter.

If they're in a separate package it's less easy to wire quickcheck
tests into the commit procedure.


Cheers,


D
From dougal at dougalstanton.net  Tue Sep  9 09:06:45 2008
From: dougal at dougalstanton.net (Dougal Stanton)
Date: Tue Sep  9 09:04:38 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <2d3641330809090605m55717969jfea5f72f525a0053@mail.gmail.com>
References: 
	<2d3641330809090605m55717969jfea5f72f525a0053@mail.gmail.com>
Message-ID: <2d3641330809090606m779e0bdcrcf647fc621e2c18a@mail.gmail.com>

On Tue, Sep 9, 2008 at 2:05 PM, Dougal Stanton  wrote:

> If they're in a separate package it's less easy to wire quickcheck
> tests into the commit procedure.

And by package there, I mean repo. Obviously ;-)

D
From leather at cs.uu.nl  Tue Sep  9 09:46:38 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Tue Sep  9 09:44:32 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
Message-ID: <3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>

> How do folks like to package up QuickCheck tests for their libraries?  In
> the main library?  As a separate repo & package?  Same repo & separate
> package?  Keeping tests with the tested code allows testing of non-exported
> functionality, but can add quite a lot of clutter.
>

I have QuickCheck properties plus HUnit tests, but I think the question is
the same. For me, it's in the same repository and shipped with the package
source. I think that if you ship source (even via Hackage), you should also
ship tests. So, if somebody wants to modify the source, they can run the
tests. And making it convenient to test is very important, so I have "cabal
test" (or "runhaskell Setup.hs test" without cabal-install) configured to
run the tests. I don't think tests should (in general) be part of the
user-visible API, so I have them external to the module hierarchy.

Testing non-exported functionality without exporting the test interface
seems difficult in general. Is there a way to hide part of a module
interface with Cabal? Then, you could have a 'test' function exported from
each module for testing but hidden for release.

My current leaning is to split a package "foo" into packages "foo" and
> "foo-test"
>

What benefit does this provide?

Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/dd2fee85/attachment.htm
From conal at conal.net  Tue Sep  9 10:05:24 2008
From: conal at conal.net (Conal Elliott)
Date: Tue Sep  9 10:03:16 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
Message-ID: 

Thanks, Sean.

On Tue, Sep 9, 2008 at 3:46 PM, Sean Leather  wrote:

>
> How do folks like to package up QuickCheck tests for their libraries?  In
>> the main library?  As a separate repo & package?  Same repo & separate
>> package?  Keeping tests with the tested code allows testing of non-exported
>> functionality, but can add quite a lot of clutter.
>>
>
> I have QuickCheck properties plus HUnit tests, but I think the question is
> the same. For me, it's in the same repository and shipped with the package
> source. I think that if you ship source (even via Hackage), you should also
> ship tests. So, if somebody wants to modify the source, they can run the
> tests. And making it convenient to test is very important, so I have "cabal
> test" (or "runhaskell Setup.hs test" without cabal-install) configured to
> run the tests. I don't think tests should (in general) be part of the
> user-visible API, so I have them external to the module hierarchy.
>

How do you set up cabal to do these tests?

Do your libraries depend on HUnit?

Where do you like to place your tests?  In the functionality modules?  A
parallel structure?  A single Test.hs file somewhere?

Testing non-exported functionality without exporting the test interface
> seems difficult in general. Is there a way to hide part of a module
> interface with Cabal? Then, you could have a 'test' function exported from
> each module for testing but hidden for release.
>

My current leaning is to split a package "foo" into packages "foo" and
>> "foo-test"
>>
>
> What benefit does this provide?
>

It keeps the library and its dependencies small.  Probably some of the
alternatives do as well.  For testing, I'm using
checkersin addition to
QuickCheck, and I'd prefer not to make casual library users
have to pull in those libraries as well.

  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/62673e91/attachment.htm
From leather at cs.uu.nl  Tue Sep  9 10:32:35 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Tue Sep  9 10:30:28 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
Message-ID: <3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>

> How do folks like to package up QuickCheck tests for their libraries?  In
>>> the main library?  As a separate repo & package?  Same repo & separate
>>> package?  Keeping tests with the tested code allows testing of non-exported
>>> functionality, but can add quite a lot of clutter.
>>>
>>
>> I have QuickCheck properties plus HUnit tests, but I think the question is
>> the same. For me, it's in the same repository and shipped with the package
>> source. I think that if you ship source (even via Hackage), you should also
>> ship tests. So, if somebody wants to modify the source, they can run the
>> tests. And making it convenient to test is very important, so I have "cabal
>> test" (or "runhaskell Setup.hs test" without cabal-install) configured to
>> run the tests. I don't think tests should (in general) be part of the
>> user-visible API, so I have them external to the module hierarchy.
>>
>
> How do you set up cabal to do these tests?
>

I use the "runTests" hook in Distribution.Simple. The code below works on
Windows and Mac, because that's what we use.

\begin{code}
module Main (main) where

import Distribution.Simple
import System.Cmd (system)
import System.FilePath (())

main :: IO ()
main = defaultMainWithHooks hooks where
  hooks = simpleUserHooks { runTests = runTests' }

runTests' _ _ _ _ = system cmd >> return ()
  where testdir = "dist"  "build"  "test"
        testcmd = "."  "test"
        cmd = "cd " ++ testdir ++ " && " ++ testcmd
\end{code}

Do your libraries depend on HUnit?
>

No, because I use an ultra-secret trick. ;) I have a Library in my .cabal
file and an Executable for testing. Part of the test description follows.

\begin{cabal}
Executable test
  hs-source-dirs:       src, tests, examples
  main-is:              Main.hs

  -- Only enable the build-depends here if configured with "-ftest". This
  -- keeps users from having to install QuickCheck 2 in order to use EMGM.
  if flag(test)
    build-depends:      QuickCheck >= 2.0, HUnit >= 1.2
  else
    buildable:          False
\end{cabal}

With that last flag-based if/else, I hide the dependencies for normal
building ('test' by default is False). If 'test' is False, then the
executable also cannot be built.

Where do you like to place your tests?  In the functionality modules?  A
> parallel structure?  A single Test.hs file somewhere?
>

In a separate "tests" directory at the same level as the "src" directory
containing the module hierarchy. It has a number of files, mostly one per
module tested.


> Testing non-exported functionality without exporting the test interface
>> seems difficult in general. Is there a way to hide part of a module
>> interface with Cabal? Then, you could have a 'test' function exported from
>> each module for testing but hidden for release.
>>
>
> My current leaning is to split a package "foo" into packages "foo" and
>>> "foo-test"
>>>
>>
>> What benefit does this provide?
>>
>
> It keeps the library and its dependencies small.  Probably some of the
> alternatives do as well.  For testing, I'm using checkersin addition to QuickCheck, and I'd prefer not to make casual library users
> have to pull in those libraries as well.
>

Ah, so you're handling the same problem we are in a different way. Nice!

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/560c634e/attachment.htm
From bjorn at bringert.net  Tue Sep  9 10:40:34 2008
From: bjorn at bringert.net (Bjorn Bringert)
Date: Tue Sep  9 10:38:25 2008
Subject: [Haskell-cafe] Hackage -> MacPorts?
In-Reply-To: <20080903201449.GA20567@berkeley.edu>
References: <20080903201449.GA20567@berkeley.edu>
Message-ID: 

On Wed, Sep 3, 2008 at 10:14 PM, John MacFarlane  wrote:
> It would be great if there were an automated or semi-automated way
> of generating a MacPorts Portfile from a HackageDB package, along
> the lines of dons' cabal2arch. Has anyone been working on such a thing?
> And, are any haskell-cafe readers MacPorts committers?

I seem to remember that Eric Kidd started working on something like
this at the Hackathon in Freiburg.

/Bj?rn
From jgbailey at gmail.com  Tue Sep  9 11:32:03 2008
From: jgbailey at gmail.com (Justin Bailey)
Date: Tue Sep  9 11:29:56 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: 
References: 
	
	
Message-ID: 

2008/9/8 Daryoush Mehrtash 
>
> Thanks.
>
> Pattern matching and memory management in Haskell (or may be GHC implementation of it) is somewhat of a mystery to me.  Are there any references that explains the underlying implementation?
>
> Daryoush

Be careful what you ask for. This paper is 16 years old but fairly
relevant. Click the "view or download" link at the bottom:

  "Implementing Lazy Functional Languages on Stock Hardware: The
Spineless Tagless G-Machine"
  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729

Justin
From jgbailey at gmail.com  Tue Sep  9 11:34:18 2008
From: jgbailey at gmail.com (Justin Bailey)
Date: Tue Sep  9 11:32:10 2008
Subject: [Haskell-cafe] haskell core definition
In-Reply-To: <48C5C25B.3010204@73rus.com>
References: <48C5C25B.3010204@73rus.com>
Message-ID: 

This paper is a bit old but still very relevant:

   An External Representation for the GHC Core Language
   http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.1755

Click "view or download" at the bottom to see the paper. Also, I
haven't used this utility myself yet but it pages and colorizes GHC
core for you:

  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-core

Justin
From conal at conal.net  Tue Sep  9 11:55:49 2008
From: conal at conal.net (Conal Elliott)
Date: Tue Sep  9 11:53:41 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>
Message-ID: 

Hi Sean.

Thanks a bunch for these tips.  I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right.  I have:

Flag test
  Description: Enable testing
  Default:     False

And I get "Warning: unamb.cabal: Unknown section type: flag ignoring...".
If I indent, I instead get "These flags are used without having been
defined: test".  Any idea what I'm doing wrong here?

  - Conal


On Tue, Sep 9, 2008 at 4:32 PM, Sean Leather  wrote:

>
>  How do folks like to package up QuickCheck tests for their libraries?  In
>>>> the main library?  As a separate repo & package?  Same repo & separate
>>>> package?  Keeping tests with the tested code allows testing of non-exported
>>>> functionality, but can add quite a lot of clutter.
>>>>
>>>
>>> I have QuickCheck properties plus HUnit tests, but I think the question
>>> is the same. For me, it's in the same repository and shipped with the
>>> package source. I think that if you ship source (even via Hackage), you
>>> should also ship tests. So, if somebody wants to modify the source, they can
>>> run the tests. And making it convenient to test is very important, so I have
>>> "cabal test" (or "runhaskell Setup.hs test" without cabal-install)
>>> configured to run the tests. I don't think tests should (in general) be part
>>> of the user-visible API, so I have them external to the module hierarchy.
>>>
>>
>> How do you set up cabal to do these tests?
>>
>
> I use the "runTests" hook in Distribution.Simple. The code below works on
> Windows and Mac, because that's what we use.
>
> \begin{code}
> module Main (main) where
>
> import Distribution.Simple
> import System.Cmd (system)
> import System.FilePath (())
>
> main :: IO ()
> main = defaultMainWithHooks hooks where
>   hooks = simpleUserHooks { runTests = runTests' }
>
> runTests' _ _ _ _ = system cmd >> return ()
>   where testdir = "dist"  "build"  "test"
>         testcmd = "."  "test"
>         cmd = "cd " ++ testdir ++ " && " ++ testcmd
> \end{code}
>
> Do your libraries depend on HUnit?
>>
>
> No, because I use an ultra-secret trick. ;) I have a Library in my .cabal
> file and an Executable for testing. Part of the test description follows.
>
> \begin{cabal}
> Executable test
>   hs-source-dirs:       src, tests, examples
>   main-is:              Main.hs
>
>   -- Only enable the build-depends here if configured with "-ftest". This
>   -- keeps users from having to install QuickCheck 2 in order to use EMGM.
>   if flag(test)
>     build-depends:      QuickCheck >= 2.0, HUnit >= 1.2
>   else
>     buildable:          False
> \end{cabal}
>
> With that last flag-based if/else, I hide the dependencies for normal
> building ('test' by default is False). If 'test' is False, then the
> executable also cannot be built.
>
> Where do you like to place your tests?  In the functionality modules?  A
>> parallel structure?  A single Test.hs file somewhere?
>>
>
> In a separate "tests" directory at the same level as the "src" directory
> containing the module hierarchy. It has a number of files, mostly one per
> module tested.
>
>
>> Testing non-exported functionality without exporting the test interface
>>> seems difficult in general. Is there a way to hide part of a module
>>> interface with Cabal? Then, you could have a 'test' function exported from
>>> each module for testing but hidden for release.
>>>
>>
>> My current leaning is to split a package "foo" into packages "foo" and
>>>> "foo-test"
>>>>
>>>
>>> What benefit does this provide?
>>>
>>
>> It keeps the library and its dependencies small.  Probably some of the
>> alternatives do as well.  For testing, I'm using checkersin addition to QuickCheck, and I'd prefer not to make casual library users
>> have to pull in those libraries as well.
>>
>
> Ah, so you're handling the same problem we are in a different way. Nice!
>
> Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/359d6e33/attachment.htm
From ketil at malde.org  Tue Sep  9 12:26:15 2008
From: ketil at malde.org (Ketil Malde)
Date: Tue Sep  9 12:22:10 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
	(Conal Elliott's message of "Tue\, 9 Sep 2008 17\:55\:49 +0200")
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>
	
Message-ID: <8763p5z3o8.fsf@malde.org>

"Conal Elliott"  writes:

> Thanks a bunch for these tips.  I haven't used the flags feature of cabal
> before, and i don't seem to be able to get it right. 

Another option might be to have the test command build via 'ghc
--make' instead of Cabal - this way, you can avoid mentioning testing
libraries altogether in the cabal file.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From batterseapower at hotmail.com  Tue Sep  9 12:35:46 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Tue Sep  9 12:33:41 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>
	
Message-ID: <9d4d38820809090935s1f8f165dpc5f7dce1d7589dfc@mail.gmail.com>

2008/9/9 Conal Elliott :
> Hi Sean.
>
> Thanks a bunch for these tips.  I haven't used the flags feature of cabal
> before, and i don't seem to be able to get it right.  I have:
>
> Flag test
>   Description: Enable testing
>   Default:     False
>
> And I get "Warning: unamb.cabal: Unknown section type: flag ignoring...".
> If I indent, I instead get "These flags are used without having been
> defined: test".  Any idea what I'm doing wrong here?

I don't know exactly what your problem is, but perhaps you have not
specified Cabal-Version: >= 1.2?

For another example .cabal file that uses something like the technique
Sean describes you can look at my edit-distance library on GitHub:
http://github.com/batterseapower/edit-distance/tree/master/edit-distance.cabal.
It exports a library with the edit distance algorithms and a test
executable which is only buildable when configured with -ftests. I
haven't made use of the Cabal test hook, but you can run the tests
just by running that single executable: the procedure is described in
my README: http://github.com/batterseapower/edit-distance/tree/master/README.textile

My tests are making use of a nice console test runner I wrote that
supports both HUnit and QuickCheck (and is extensible to other test
providers by the user):
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.

Cheers,
Max
From andrewcoppin at btinternet.com  Tue Sep  9 13:08:34 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Tue Sep  9 13:06:32 2008
Subject: [Haskell-cafe] haskell core definition
In-Reply-To: 
References: <48C5C25B.3010204@73rus.com>
	
Message-ID: <48C6AD92.1060406@btinternet.com>

Justin Bailey wrote:
> This paper is a bit old but still very relevant:
>
>    An External Representation for the GHC Core Language
>    http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.1755
>
> Click "view or download" at the bottom to see the paper. Also, I
> haven't used this utility myself yet but it pages and colorizes GHC
> core for you:
>
>   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-core
>   

IIRC, wasn't there a plan a while back to make GHC compile *from* Core 
as well as just outputting it? Did this ever go anywhere?

From andrewcoppin at btinternet.com  Tue Sep  9 13:13:50 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Tue Sep  9 13:11:46 2008
Subject: [Haskell-cafe] Windows details
Message-ID: <48C6AECE.3020905@btinternet.com>

I rather doubt anybody will know the answer to this, but I'll ask anyway...

Under MS Windows, if you right-click on an executable file and select 
"properties", sometimes there's a "Version" tab that tells you the 
version number of the program. And sometimes there isn't. (Most 
especially, GHC-compiled programs do not have this tab.) Anybody know 
how to go about adding this?

Also, anybody know how to give a GHC-compiled program a custom icon?

If it's going to be really difficult then I won't bother, but it'd be 
interesting to know.

(In other news, today I discovered that applying UPX to my 2.8 MB 
GHC-compiled executable shrinks it down to 800 KB and it still 
functions. And WinZip shrinks it down to just 300 KB. 2.8 MB for a 
program that just does a little text parsing does seem a touch excessive 
to me...)

From steve at fenestra.com  Tue Sep  9 13:57:33 2008
From: steve at fenestra.com (Steve Schafer)
Date: Tue Sep  9 13:55:19 2008
Subject: [Haskell-cafe] Windows details
In-Reply-To: <48C6AECE.3020905@btinternet.com>
References: <48C6AECE.3020905@btinternet.com>
Message-ID: <68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>

On Tue, 09 Sep 2008 18:13:50 +0100, you wrote:

>Under MS Windows, if you right-click on an executable file and select 
>"properties", sometimes there's a "Version" tab that tells you the 
>version number of the program. And sometimes there isn't. (Most 
>especially, GHC-compiled programs do not have this tab.) Anybody know 
>how to go about adding this?
>
>Also, anybody know how to give a GHC-compiled program a custom icon?

Version information and application icons are both stored in data
structures called "resources"; these are appended to the executable
portion of the application, inside the EXE file. There are a number of
predefined resource types, such as the aforementioned version info and
icon, which follow specific data formats, and you can also define custom
resources to store just about anything you want. (For example, in an
application I wrote recently, I used custom resources to embed a set of
TrueType fonts into the EXE.)

There are a gazillion resource editors available for modifying the
resources linked into an EXE; go to the Wikipedia page for a reasonable
starting point:

 http://en.wikipedia.org/wiki/Resource_(Windows)

Steve Schafer
Fenestra Technologies Corp
http://www.fenestra.com/
From paul at cogito.org.uk  Tue Sep  9 14:15:48 2008
From: paul at cogito.org.uk (Paul Johnson)
Date: Tue Sep  9 14:13:40 2008
Subject: [Haskell-cafe] trying to understand monad transformers....
In-Reply-To: 
References: 
Message-ID: <48C6BD54.2080700@cogito.org.uk>

Daryoush Mehrtash wrote:
> The MaybeT transformer is defined as:
> newtype MaybeT m a = MaybeT {runMaybeT :: m (Maybe  a)}
>
>  
> instance Functor  m => Functor  (MaybeT m) where
>
>   fmap  f x = MaybeT $  fmap  (fmap  f) $  runMaybeT x
>
>
> ....
>   
>
> Question:  What does "runMaybeT x" mean?
>
All monads (except IO) have a "run" function.  E.g. "runST" for the ST 
monad, "runState" for the state function, and so on.  A monadic action 
is actually a function that (typically) takes extra arguments and 
returns extra results.  In the monadic action form these extra data are 
hidden, and its up to the monad "bind" function to thread them from one 
action to the next.  The "runX" function for some monad X converts a 
monadic action into the underlying function with that data exposed.  In 
most cases the monad is defined as a "newtype" wrapper around the 
function, so the "run" function is just the inverse of the constructor.

In the case of a monad transformer the result of the function is not a 
value, its an action in another monad.  Thats what you see in the case 
of MaybeT.  A MaybeT action is actually a monadic action that itself 
returns a Maybe value.  So you use "runMaybeT to turn your MaybeT action 
into an action in the inner monad, and then run that action using its 
"run" function to finally get a Maybe result.

Make sense?

Paul.
From bruceteckel at gmail.com  Tue Sep  9 14:30:11 2008
From: bruceteckel at gmail.com (Bruce Eckel)
Date: Tue Sep  9 14:28:03 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
Message-ID: <14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>

So this is the kind of problem I keep running into. There will seem to be
consensus that you can do everything with isolated processes message passing
(and note here that I include Actors in this scenario even if their
mechanism is more complex). And then someone will pipe up and say "well, of
course, you have to have threads" and the argument is usually "for
efficiency."
I make two observations here which I'd like comments on:

1) What good is more efficiency if the majority of programmers can never get
it right? My position: if a programmer has to explicitly synchronize
anywhere in the program, they'll get it wrong. This of course is a point of
contention; I've met a number of people who say "well, I know you don't
believe it, but *I* can write successful threaded programs." I used to think
that, too. But now I think it's just a learning phase, and you aren't a
reliable thread programmer until you say "it's impossible to get right"
(yes, a conundrum).

2) What if you have lots of processors? Does that change the picture any?
That is, if you use isolated processes with message passing and you have as
many processors as you want, do you still think you need shared-memory
threading?

A comment on the issue of serialization -- note that any time you need to
protect shared memory, you use some form of serialization. Even optimistic
methods guarantee serialization, even if it happens after the memory is
corrupted, by backing up to the uncorrupted state. The effect is the same;
only one thread can access the shared state at a time.

On Tue, Sep 9, 2008 at 4:03 AM, Sebastian Sylvan  wrote:

>
>
> On Mon, Sep 8, 2008 at 8:33 PM, Bruce Eckel  wrote:
>
>> As some of you on this list may know, I have struggled to understand
>> concurrency, on and off for many years, but primarily in the C++ and
>> Java domains. As time has passed and experience has stacked up, I have
>> become more convinced that while the world runs in parallel, we think
>> sequentially and so shared-memory concurrency is impossible for
>> programmers to get right -- not only are we unable to think in such a
>> way to solve the problem, the unnatural domain-cutting that happens in
>> shared-memory concurrency always trips you up, especially when the
>> scale increases.
>>
>> I think that the inclusion of threads and locks in Java was just a
>> knee-jerk response to solving the concurrency problem. Indeed, there
>> were subtle threading bugs in the system until Java 5. I personally
>> find the Actor model to be most attractive when talking about
>> threading and objects, but I don't yet know where the limitations of
>> Actors are.
>>
>> However, I keep running across comments where people claim they "must"
>> have shared memory concurrency. It's very hard for me to tell whether
>> this is just because the person knows threads or if there is truth to
>> it.
>
>
> For correctness, maybe not, for efficiency, yes definitely!
>
> Imagine a program where you have a huge set of data that needs to be
> modified (in some sense) over time by thousands of agents. E.g. a game
> simulation.
> Now, also imagine that every agent could *potentially* modify every single
> piece of data, but that every agent *typically* only touches two or three
> varibles here and there. I.e. the collisions between the potential
> read/write sets is 100%, while the collisions for the actual read/write sets
> is very very low.
>
> How would you do this with threads and message passing? Well you could have
> one big thread owning all of your data that takes "update" messages, and
> then "updates" the world for you (immutably if you wish, by just replacing
> its "world" variable with a new one containing your update), but now you've
> effectively serialized all your interactions with the "world", so you're not
> really concurrent anymore!
>
> So you could decompose the world into multiple threads using some
> application-specific logical sudivision, but then you're effectively just
> treating each thread as a mutable variable with an implicit lock (with the
> risks of deadlock that comes with it - remember we don't know the read/write
> set in advance - it could be the entire world - so we can't just order our
> updates in some global way here), so you're really just doing shared mutable
> state again, and gain little from having threads "simulate" your mutable
> cells...
>
> What you really need for this is some way for each agent to update this
> shared state *in parallel*, without having to block all other agents
> pessimistically, but instead only block other agents if there was an
> *actual* conflict. STM seems to be the only real hope for that sort of thing
> right now.
>  IMO my list of preferred methods goes like this:
> 1. Purely functional data parallelism
> 2. Purely functional task parallelism (using e.g. strategies)
> 3. Message passing with no (or very minimal) shared state (simulated using
> threads as "data servers" or otherwise)
> (3.5. Join patterns? Don't have enough experience with this, but seems sort
> of nice?)
> 4. Shared state concurrency using STM
> 5. Shared state concurrency using locks
> 6. Lockless programming.
>
> So while I wouldn't resort to any shared state concurrency unless there are
> good reasons for why the other methods don't work well (performance is a
> good reason!), there are still situations where you need it, and a general
> purpose language had better supply a way of accessing those kinds of
> facilities.
>
> --
> Sebastian Sylvan
> +44(0)7857-300802
> UIN: 44640862
>



-- 
Bruce Eckel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/133cc207/attachment-0001.htm
From andrewcoppin at btinternet.com  Tue Sep  9 14:33:32 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Tue Sep  9 14:31:22 2008
Subject: [Haskell-cafe] Windows details
In-Reply-To: <68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
Message-ID: <48C6C17C.1040000@btinternet.com>

Steve Schafer wrote:
> Version information and application icons are both stored in data
> structures called "resources"; these are appended to the executable
> portion of the application, inside the EXE file. There are a number of
> predefined resource types, such as the aforementioned version info and
> icon, which follow specific data formats, and you can also define custom
> resources to store just about anything you want. (For example, in an
> application I wrote recently, I used custom resources to embed a set of
> TrueType fonts into the EXE.)
>
> There are a gazillion resource editors available for modifying the
> resources linked into an EXE; go to the Wikipedia page for a reasonable
> starting point:
>
>  http://en.wikipedia.org/wiki/Resource_(Windows)
>   

Thanks for your input. I'm now playing with XN Resource Editor. Getting 
the version information to work correctly appears to be tricky, but 
everything else seems quite straight forward...

From ndmitchell at gmail.com  Tue Sep  9 14:49:49 2008
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Tue Sep  9 14:47:40 2008
Subject: [Haskell-cafe] Re: Munging wiki articles with tagsoup
In-Reply-To: <20080908053105.GB15405@craft>
References: <20080908053105.GB15405@craft>
Message-ID: <404396ef0809091149o10237ebfhc76cb8d7c57bd634@mail.gmail.com>

Hi Gwern,

Sorry for not noticing this sooner, my haskell-cafe@ reading is
somewhat behind right now!


>  After an hour, I came up with a nice clean little script:
>
>  ----
>
>  import Text.HTML.TagSoup.Render
>  import Text.HTML.TagSoup
>
>  main :: IO ()
>  main = interact convertPre
>
>  convertPre :: String -> String
>  convertPre = renderTags . map convertToHaskell . canonicalizeTags . parseTags
>
>  convertToHaskell :: Tag -> Tag
>  convertToHaskell x
>                | isTagOpenName  "pre" x = TagOpen  "haskell" (extractAttribs x)
>                | isTagCloseName "pre" x = TagClose "haskell"
>                | otherwise              = x
>                              where
>                                extractAttribs :: Tag -> [Attribute]
>                                extractAttribs (TagOpen _ y) = y
>                                extractAttribs _             = error "The impossible happened."


convertToHaskell (TagOpen "pre" atts) = TagOpen "haskell" atts
convertToHaskell (TagClose "pre") = TagClose "haskell"
convertToHaskell x = x

Direct pattern matching is much easier and simpler.

>  Anyway, so my script seems to work. I ran the wiki output through it and this is the diff: .
>
>  Ok, good, it replaces all the tags... But wait, what's all this other stuff? It is replacing all my apostrophes with '! No doubt this has something to do with XML/HTML/SGML or whatever, but it's not ideal. Even if it doesn't break the formatting (as I think it does), it's still cluttering up the source.

The escaping of ' is caused by renderTags, so instead call:


renderTagsOptions (renderOptions{optEscape = (:[])})

For no escaping of any characters, or more likely do something like <,
> and & conversions. See the docs:
http://hackage.haskell.org/packages/archive/tagsoup/0.6/doc/html/Text-HTML-TagSoup-Render.html

> Am I just barking up the wrong tree and should be writing a simple-minded search-and-replace sed script which replaces 
 with , 
 with ...?

Not necessarily. If you literally just want to replace ""
with "
" then sed is probably the easy choice. However, its quite
likely you'll want to make more fixes, and tagsoup gives you the
flexibility to extend in that direction.

Thanks

Neil
From andrewcoppin at btinternet.com  Tue Sep  9 15:15:08 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Tue Sep  9 15:12:58 2008
Subject: [Haskell-cafe] Windows console
Message-ID: <48C6CB3C.8020006@btinternet.com>

When coding in a POSIX-compliant environment, you can usually write 
special escape codes to the console to change the text colour and so 
forth. However, this does not work on Windows.

(Ignore all references you see to enabling ANSI.SYS in your config.sys 
file; this applies only to 16-bit MS-DOS programs, *not* to 32-bit 
Windows programs.)

However - to my surprise - apparently the Win32 API provides a set of 
function calls that do in fact allow 32-bit applications to change the 
colours of the console on a character-by-character basis. However - wait 
for it - those *particular* functions aren't in Haskell's 
System.Win32.Console module. :-(

Obviously, I know nothing about C. However, after much hunting around, 
it turns out that for some reason, GHC appears to ship with a complete 
set of C header files for the Win32 API. (In other words, the necessary 
header file for accessing the functions I want is there.) After 
staggering through the (very unhelpful) FFI language specification, I 
was able to make it so that I can apparently call these functions from 
Haskell. I was not, however, able to find any way at all to import the 
symbolic constants necessary, so I was forced to reading through the 
source code of the raw C header files to find out what the numeric 
values of these are (!!!)

The long and short of it is, I now have a small Haskell library that 
enables me to print things in trippy colours on the screen from a normal 
Haskell CLI program. Yay for me! (Actually, you can also change the 
title on the window - so you can make your program say "My Fantastic 
Tool" instead of "C:\Documents and 
Settings\foo\Haskell\MyTool\MyTool.exe" in the titlebar. Again, this is 
for a normal Haskell console application with nothing done to it.)

Would anybody else be interested in having this code? (Obviously, it's 
pretty tiny.) For that matter, would the maintainer of 
System.Win32.Console be interested in adding the necessary dozen lines 
of code to that module?

Actually, now that I think about it, it would be kind of nice to have a 
magic package that writes out escape codes or calls the Win32 API 
depending on which platform your program is compiled on - in the style 
of System.FilePath. I don't know how to do that though... A nice idea, guys?

From catamorphism at gmail.com  Tue Sep  9 15:21:17 2008
From: catamorphism at gmail.com (Tim Chevalier)
Date: Tue Sep  9 15:19:07 2008
Subject: [Haskell-cafe] haskell core definition
In-Reply-To: 
References: <48C5C25B.3010204@73rus.com>
	
Message-ID: <4683d9370809091221p1449f258hecf5ba10e62dbbd4@mail.gmail.com>

On Tue, Sep 9, 2008 at 8:34 AM, Justin Bailey  wrote:
> This paper is a bit old but still very relevant:
>
>   An External Representation for the GHC Core Language
>   http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.1755
>

Or: http://www.haskell.org/ghc/docs/papers/core.ps.gz
Note that External Core, as specified in this paper, is similar to but
not entirely the same as the version of Core that GHC prints out for
debugging purposes.

GHC 6.10 will be able to produce External Core with a flag again, and
at that point Section 5.15 of the users' guide will point to a new
version of the documentation -- so if you upgrade to 6.10 when it is
released and are still poring over Core code then, be sure to get the
new documentation.

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.
From jed at 59A2.org  Tue Sep  9 15:23:20 2008
From: jed at 59A2.org (Jed Brown)
Date: Tue Sep  9 15:21:14 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
Message-ID: <20080909192320.GG3126@brakk.ethz.ch>

On Tue 2008-09-09 12:30, Bruce Eckel wrote:
> So this is the kind of problem I keep running into. There will seem to be
> consensus that you can do everything with isolated processes message passing
> (and note here that I include Actors in this scenario even if their mechanism
> is more complex). And then someone will pipe up and say "well, of course, you
> have to have threads" and the argument is usually "for efficiency."

Some pipe up and say ``you can't do global shared memory because it's
inefficient''.  Ensuring cache coherency with many processors operating
on shared memory is a nightmare and inevitably leads to poor
performance.  Perhaps some optimizations could be done if the programs
were guaranteed to have no mutable state, but that's not realistic.
Almost all high performance machines (think top500) are distributed
memory with very few cores per node.  Parallel programs are normally
written using MPI for communication and they can achieve nearly linear
scaling to 10^5 processors BlueGene/L for scientific problems with
strong global coupling.

I encourage you to browse these slides for some perspective on very
large scale coupled computation.  Most problems commercial/industrial
tasks are much easier since the global coupling is much looser.

http://www.xergi.no/upload/IKT/9011/SimOslo/eVITA/2008/PetaflopsGeilo.pdf

Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/90fc3cdf/attachment.bin
From catamorphism at gmail.com  Tue Sep  9 15:25:09 2008
From: catamorphism at gmail.com (Tim Chevalier)
Date: Tue Sep  9 15:23:00 2008
Subject: [Haskell-cafe] [Fwd: profiling in haskell]
In-Reply-To: <48C5BBE0.6060509@73rus.com>
References: <48C5BBE0.6060509@73rus.com>
Message-ID: <4683d9370809091225h62d585c6x463f56c956d25add@mail.gmail.com>

2008/9/8 Vlad Skvortsov :
> Posting to cafe since I got just one reply on beginner@. I was suggested to
> include more SCC annotations, but that didn't help. The 'serialize' function
> is still reported to consume about 32% of running time, 29% inherited.
> However, functions called from it only account for about 3% of time.
>

If "serialize" calls standard library functions, this is probably
because the profiling libraries weren't built with -auto-all -- so the
profiling report won't tell you how much time standard library
functions consume.

You can rebuild the libraries with -auto-all, but probably much easier
would be to add SCC annotations to each call site. For example, you
could annotate your locally defined dumpWith function like so:

dumpWith f = {-# SCC "foldWithKey" #-} Data.Map.foldWithKey f []
    docToStr k (Doc { docName=n, docVectorLength=vl}) =
    (:) ("d " ++ show k ++ " " ++ n ++ " " ++ (show vl))

Then your profiling report will tell you how much time/memory that
particular call to foldWithKey uses.

By the way, using foldl rather than foldl' or foldr is almost always a
performance bug.

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.
From jonathanccast at fastmail.fm  Tue Sep  9 15:20:50 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Tue Sep  9 15:23:29 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <48C6CB3C.8020006@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
Message-ID: <1220988050.24987.2.camel@jcchost>

On Tue, 2008-09-09 at 20:15 +0100, Andrew Coppin wrote:
> When coding in a POSIX-compliant environment, you can usually write 
> special escape codes to the console to change the text colour and so 
> forth. However, this does not work on Windows.
> 
> (Ignore all references you see to enabling ANSI.SYS in your config.sys 
> file; this applies only to 16-bit MS-DOS programs, *not* to 32-bit 
> Windows programs.)
> 
> However - to my surprise - apparently the Win32 API provides a set of 
> function calls that do in fact allow 32-bit applications to change the 
> colours of the console on a character-by-character basis. However - wait 
> for it - those *particular* functions aren't in Haskell's 
> System.Win32.Console module. :-(
> 
> Obviously, I know nothing about C. However, after much hunting around, 
> it turns out that for some reason, GHC appears to ship with a complete 
> set of C header files for the Win32 API. (In other words, the necessary 
> header file for accessing the functions I want is there.) After 
> staggering through the (very unhelpful) FFI language specification, I 
> was able to make it so that I can apparently call these functions from 
> Haskell. I was not, however, able to find any way at all to import the 
> symbolic constants necessary, so I was forced to reading through the 
> source code of the raw C header files to find out what the numeric 
> values of these are (!!!)

c2hs can do this; check out #const CONSTANT_NAME

jcc


From batterseapower at hotmail.com  Tue Sep  9 15:41:48 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Tue Sep  9 15:39:40 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <48C6CB3C.8020006@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
Message-ID: <9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>

2008/9/9 Andrew Coppin :
> Actually, now that I think about it, it would be kind of nice to have a
> magic package that writes out escape codes or calls the Win32 API depending
> on which platform your program is compiled on - in the style of
> System.FilePath. I don't know how to do that though... A nice idea, guys?

I wrote this package a few weeks ago: check out
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ansi-terminal
and it's companion
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ansi-wl-pprint

Cheers,
Max
From bulat.ziganshin at gmail.com  Tue Sep  9 16:11:59 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Tue Sep  9 16:11:43 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <48C6CB3C.8020006@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
Message-ID: <327242261.20080910001159@gmail.com>

Hello Andrew,

Tuesday, September 9, 2008, 11:15:08 PM, you wrote:

> Haskell. I was not, however, able to find any way at all to import the
> symbolic constants necessary, so I was forced to reading through the 
> source code of the raw C header files to find out what the numeric 
> values of these are (!!!)

look into Win32 package sources, small example is:

#{enum LoadLibraryFlags,
 , lOAD_LIBRARY_AS_DATAFILE      = LOAD_LIBRARY_AS_DATAFILE
 , lOAD_WITH_ALTERED_SEARCH_PATH = LOAD_WITH_ALTERED_SEARCH_PATH
 }

(in File.hsc)

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From bulat.ziganshin at gmail.com  Tue Sep  9 16:17:14 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Tue Sep  9 16:21:52 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: 
References: 
Message-ID: <1927421099.20080910001714@gmail.com>

Hello Mauri?cio,

Tuesday, September 9, 2008, 1:36:09 PM, you wrote:

> I use Haskell, and my friends at
> work use Java. Do you think it
> could be a good idea to use Haskell
> with Java, so I could understand
> and cooperate with them?

http://haskell.org/haskellwiki/Applications_and_libraries/Interfacing_other_languages

in particular, GreenCard doesn't work with ghc >= 6.2


> Is there a
> a Haskell to Java compiler that's
> already ready to use?

CAL

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From pieter at laeremans.org  Tue Sep  9 16:30:26 2008
From: pieter at laeremans.org (Pieter Laeremans)
Date: Tue Sep  9 16:28:16 2008
Subject: [Haskell-cafe] Haskell stacktrace
Message-ID: 

Hello,
I've written a cgi script in haskell, it crashes sometimes  with the error
message Prelude . tail  : empty list

In Java we would use this approach to log the erro

try {

} catch (Exception e) {


}


-- 
Pieter Laeremans 

"The future is here. It's just not evenly distributed yet." W. Gibson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/0ca66e52/attachment.htm
From pieter at laeremans.org  Tue Sep  9 16:35:20 2008
From: pieter at laeremans.org (Pieter Laeremans)
Date: Tue Sep  9 16:33:11 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 
Message-ID: 

Woops , I hit the  "send" button to early.
The java approach to locate the error would be

try {   ... }catch(Exception e ){
// log error
throw new RuntimeException(e);
}

...

What 's the best equivalent haskell approach ?

thanks in advance,

Pieter


On Tue, Sep 9, 2008 at 10:30 PM, Pieter Laeremans wrote:

> Hello,
> I've written a cgi script in haskell, it crashes sometimes  with the error
> message Prelude . tail  : empty list
>
> In Java we would use this approach to log the erro
>
> try {
>
> } catch (Exception e) {
>
>
> }
>
>
> --
> Pieter Laeremans 
>
> "The future is here. It's just not evenly distributed yet." W. Gibson
>



-- 
Pieter Laeremans 

"The future is here. It's just not evenly distributed yet." W. Gibson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/2fa71525/attachment.htm
From pieter at laeremans.org  Tue Sep  9 17:06:43 2008
From: pieter at laeremans.org (Pieter Laeremans)
Date: Tue Sep  9 17:04:34 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 
	
Message-ID: 

This :
Prelude> let f = (\x -> return "something went wrong")  ::   IOError -> IO
String
Prelude> let t = return $ show $ "too short list" !! 100 :: IO String
Prelude> catch t f
"*** Exception: Prelude.(!!): index too large

doesn't work.

kind regards,

Pieter



On Tue, Sep 9, 2008 at 10:35 PM, Pieter Laeremans wrote:

> Woops , I hit the  "send" button to early.
> The java approach to locate the error would be
>
> try {   ... }catch(Exception e ){
> // log error
> throw new RuntimeException(e);
> }
>
> ...
>
> What 's the best equivalent haskell approach ?
>
> thanks in advance,
>
> Pieter
>
>
> On Tue, Sep 9, 2008 at 10:30 PM, Pieter Laeremans wrote:
>
>> Hello,
>> I've written a cgi script in haskell, it crashes sometimes  with the error
>> message Prelude . tail  : empty list
>>
>> In Java we would use this approach to log the erro
>>
>> try {
>>
>> } catch (Exception e) {
>>
>>
>> }
>>
>>
>> --
>> Pieter Laeremans 
>>
>> "The future is here. It's just not evenly distributed yet." W. Gibson
>>
>
>
>
> --
> Pieter Laeremans 
>
> "The future is here. It's just not evenly distributed yet." W. Gibson
>



-- 
Pieter Laeremans 

"The future is here. It's just not evenly distributed yet." W. Gibson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/dc6d7fc0/attachment.htm
From jgbailey at gmail.com  Tue Sep  9 17:12:38 2008
From: jgbailey at gmail.com (Justin Bailey)
Date: Tue Sep  9 17:10:29 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 
	
Message-ID: 

2008/9/9 Pieter Laeremans :
> What 's the best equivalent haskell approach ?
> thanks in advance,
> Pieter

The preferred approach is to look at your code, figure out where you
are using tail (or could be calling something that uses tail) and use
the "trace" function to output logging info. Don't forget that output
is buffered with trace so you might get some strange ordering. A quick
search of the API docs should show you where trace lives.

Techniques that worked for Java don't work very well when debugging
haskell. Others will tell you about flags and possibly using the
debugger but I would count on eyeballing and printing as the least
painful method.

Justin
From ketil at malde.org  Tue Sep  9 17:18:18 2008
From: ketil at malde.org (Ketil Malde)
Date: Tue Sep  9 17:14:11 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
	(Justin Bailey's message of "Tue\, 9 Sep 2008 14\:12\:38 -0700")
References: 
	
	
Message-ID: <87bpyxuig5.fsf@malde.org>

"Justin Bailey"  writes:

> are using tail (or could be calling something that uses tail) and use
> the "trace" function to output logging info.

Another cheap trick is to use CPP with something like:

#define head (\xs -> case xs of { (x:_) -> x ; _ -> error("head failed at line"++__FILE__++show __LINE__)})

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From cmb21 at kent.ac.uk  Tue Sep  9 17:21:24 2008
From: cmb21 at kent.ac.uk (C.M.Brown)
Date: Tue Sep  9 17:19:16 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: <87bpyxuig5.fsf@malde.org>
References: 
	
	
	<87bpyxuig5.fsf@malde.org>
Message-ID: 

Or define your own ghead and gtail:

ghead msg [] = error "ghead " ++ msg ++ "[]"
ghead _ (x:xs)  = x


gtail msg [] = error "gtail" ++ msg ++ "[]"
gtail msg (x:xs) = xs

and you can call them with a name of a function to give you an idea where
the error is occurring:

myHead = ghead "myHead" []

Chris.


On Tue, 9 Sep 2008, Ketil Malde wrote:

> "Justin Bailey"  writes:
>
> > are using tail (or could be calling something that uses tail) and use
> > the "trace" function to output logging info.
>
> Another cheap trick is to use CPP with something like:
>
> #define head (\xs -> case xs of { (x:_) -> x ; _ -> error("head failed at line"++__FILE__++show __LINE__)})
>
> -k
>
From k.kosciuszkiewicz at gmail.com  Tue Sep  9 17:51:56 2008
From: k.kosciuszkiewicz at gmail.com (Krzysztof =?utf-8?Q?Ko=C5=9Bciuszkiewicz?=)
Date: Tue Sep  9 17:49:53 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 
	
	
Message-ID: <20080909215156.GA5632@localdomain>

On Tue, Sep 09, 2008 at 11:06:43PM +0200, Pieter Laeremans wrote:
> This :
> Prelude> let f = (\x -> return "something went wrong")  ::   IOError -> IO
> String
> Prelude> let t = return $ show $ "too short list" !! 100 :: IO String
> Prelude> catch t f
> "*** Exception: Prelude.(!!): index too large

How about:

> module Main where
>
> import Control.Exception
> import Prelude hiding (catch)
>
> f :: Exception -> IO String
> f = const $ return "sthg went wrong"
>
> g :: String
> g = show $ "too short list" !! 100
>
> h :: IO String
> h = do
>   print $ head [0 .. -1]
>   return "huh?"
>
> main = do
>   mapM_ print =<< sequence
>       [ h `catch` f
>       , evaluate g `catch` f
>       , (return $! g) `catch` f
>       , (return g) `catch` f
>       ]

Output:

kokr@copper:/tmp$ runhaskell test.lhs
"sthg went wrong"
"sthg went wrong"
"sthg went wrong"
"test.lhs: Prelude.(!!): index too large

Check documentation of catch and evaluate functions in Control.Exception.

Regards,
-- 
Krzysztof Ko?ciuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: kokr@jabster.pl
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci
From leather at cs.uu.nl  Tue Sep  9 17:59:22 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Tue Sep  9 17:57:12 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>
	
Message-ID: <3c6288ab0809091459p43a1c9b5r6ee85d72ab7d8ed1@mail.gmail.com>

> Thanks a bunch for these tips.  I haven't used the flags feature of cabal
> before, and i don't seem to be able to get it right.
>

This is also my first time, so I'm not sure exactly what I'm doing right. ;)

I have:
>
> Flag test
>   Description: Enable testing
>   Default:     False
>
> And I get "Warning: unamb.cabal: Unknown section type: flag ignoring...".
> If I indent, I instead get "These flags are used without having been
> defined: test".  Any idea what I'm doing wrong here?
>

No, but you can take a look at my .cabal file to see if you can figure out
what's different. The code's not yet released, but I'm fairly confident the
.cabal file does everything we need.

https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/emgm.cabal?view=markup

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/d74e14e3/attachment.htm
From moonlite at dtek.chalmers.se  Tue Sep  9 18:01:31 2008
From: moonlite at dtek.chalmers.se (Mattias Bengtsson)
Date: Tue Sep  9 17:59:23 2008
Subject: [Haskell-cafe] Unicode and Haskell
Message-ID: <1220997691.31134.12.camel@localhost.localdomain>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/302d0631/attachment.bin
From moonlite at dtek.chalmers.se  Tue Sep  9 18:06:12 2008
From: moonlite at dtek.chalmers.se (Mattias Bengtsson)
Date: Tue Sep  9 18:04:02 2008
Subject: [Haskell-cafe] Unicode and Haskell
In-Reply-To: <1220997691.31134.12.camel@localhost.localdomain>
References: <1220997691.31134.12.camel@localhost.localdomain>
Message-ID: <1220997972.31134.15.camel@localhost.localdomain>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/dd695205/attachment.bin
From leather at cs.uu.nl  Tue Sep  9 18:07:52 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Tue Sep  9 18:05:42 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <9d4d38820809090935s1f8f165dpc5f7dce1d7589dfc@mail.gmail.com>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>
	
	<9d4d38820809090935s1f8f165dpc5f7dce1d7589dfc@mail.gmail.com>
Message-ID: <3c6288ab0809091507t2f8a7f11p3e7df3199db283bf@mail.gmail.com>

> My tests are making use of a nice console test runner I wrote that
> supports both HUnit and QuickCheck (and is extensible to other test
> providers by the user):
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
>

The description looks great! I might have to try it out.

I used HUnit with QuickCheck 2, so that I could run QC properties as HUnit
tests. QC2 has the added ability (over QC1) to run a property and return a
Bool instead of just exiting with an error, and that works nicely within
HUnit. Does test-framework do something else to support QC running
side-by-side with HUnit?

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/96419d4f/attachment.htm
From tom.davie at gmail.com  Tue Sep  9 18:07:56 2008
From: tom.davie at gmail.com (Thomas Davie)
Date: Tue Sep  9 18:05:53 2008
Subject: [Haskell-cafe] Unicode and Haskell
In-Reply-To: <1220997691.31134.12.camel@localhost.localdomain>
References: <1220997691.31134.12.camel@localhost.localdomain>
Message-ID: <91BB50BD-9148-488A-B61E-A0C2D5BCA956@gmail.com>


On 10 Sep 2008, at 00:01, Mattias Bengtsson wrote:

> Today i wrote some sample code after a Logic lecture at my university.
> The idea is to represent the AST of propositional logic as an ADT with
> some convenience functions (like read-/show instances) and then later
> perhaps try to make some automatic transformations on the AST.
> After construction of the Show instances i found the output a bit  
> boring
> and thought that some Unicode math symbols would spice things up. What
> happens can be seen in the attached picture (only 3k, that's ok  
> right?).
> My terminal supports UTF-8 (when i do cat Logic.hs i can see the  
> unicode
> symbols properly).
> What might be the problem?

import Prelude hiding (print)
import System.IO.UTF8

main = print "lots of UTF8"

Bob
From moonlite at dtek.chalmers.se  Tue Sep  9 18:12:55 2008
From: moonlite at dtek.chalmers.se (Mattias Bengtsson)
Date: Tue Sep  9 18:10:45 2008
Subject: [Haskell-cafe] Unicode and Haskell
In-Reply-To: <91BB50BD-9148-488A-B61E-A0C2D5BCA956@gmail.com>
References: <1220997691.31134.12.camel@localhost.localdomain>
	<91BB50BD-9148-488A-B61E-A0C2D5BCA956@gmail.com>
Message-ID: <1220998375.31134.17.camel@localhost.localdomain>

On Wed, 2008-09-10 at 00:07 +0200, Thomas Davie wrote:
> import Prelude hiding (print)
> import System.IO.UTF8
> 
> main = print "lots of UTF8"
> 

Thanks a lot!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/f988fe91/attachment.bin
From phercek at gmail.com  Tue Sep  9 18:13:08 2008
From: phercek at gmail.com (Peter Hercek)
Date: Tue Sep  9 18:14:21 2008
Subject: [Haskell-cafe] Re: Windows console
In-Reply-To: <48C6CB3C.8020006@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
Message-ID: 

Andrew Coppin wrote:
> (Ignore all references you see to enabling ANSI.SYS in your config.sys 
> file; this applies only to 16-bit MS-DOS programs, *not* to 32-bit 
> Windows programs.)
> 

You can add interpretation of ansi escape sequences to any win32
  program by launching the application through ansicon:

http://www.geocities.com/jadoxa/ansicon/index.html

Works on 32 bit windows. Works on 64 bit windows when running a
  32 bit application. Does not work for 64 bit application (since
  64 bit windows does not allow hooking of win64 api calls IIRC).
  For support of 32 bit programs on win64 you may need to apply
  a patch I sent to Jason. He probably did not apply it (he did
  not respond to my email). Check with me if you want it.

Peter.

From alec at thened.net  Tue Sep  9 18:20:49 2008
From: alec at thened.net (Alec Berryman)
Date: Tue Sep  9 18:18:42 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 
	
	
Message-ID: <20080909222049.GA19044@thened.net>

Justin Bailey on 2008-09-09 14:12:38 -0700:

> 2008/9/9 Pieter Laeremans :
> > What 's the best equivalent haskell approach ?
> > thanks in advance,
> > Pieter
>
> The preferred approach is to look at your code, figure out where you
> are using tail (or could be calling something that uses tail) and use
> the "trace" function to output logging info.

A nice way to automate that is using LocH from Hackage.  The original
announcement:

http://www.haskell.org/pipermail/haskell/2006-November/018729.html
From phercek at gmail.com  Tue Sep  9 18:22:49 2008
From: phercek at gmail.com (Peter Hercek)
Date: Tue Sep  9 18:23:55 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 	
	
Message-ID: 

Justin Bailey wrote:
> 2008/9/9 Pieter Laeremans :
>> What 's the best equivalent haskell approach ?
>> thanks in advance,
>> Pieter
> 
> The preferred approach is to look at your code, figure out where you
> are using tail (or could be calling something that uses tail) and use
> the "trace" function to output logging info. 

To find the specific tail call:
http://haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-options-debugging

check the description for option -xc

Btw, is there any chance ghci debugger would ever print stack.
  It would be fine to see it in the same way as it exists
  when executing code ... I'm not interested in the stack as
  it would look if the program would not be lazy.

Peter.

From donn at avvanta.com  Tue Sep  9 19:11:48 2008
From: donn at avvanta.com (Donn Cave)
Date: Tue Sep  9 19:09:38 2008
Subject: [Haskell-cafe] Haskell stacktrace
References: 
Message-ID: <20080909231148.D613A93C6A@mail.avvanta.com>

> This :
> Prelude> let f = (\x -> return "something went wrong")  ::   IOError -> IO String
> Prelude> let t = return $ show $ "too short list" !! 100 :: IO String
> Prelude> catch t f
> "*** Exception: Prelude.(!!): index too large
>
> doesn't work.

You might be interested in the difference between Prelude.catch and
Control.Exception.catch

Though in an example like that, you'll need to force evaluation to
actually catch the exception.

  f _ = return "something went wrong"
  t = return $! show $ "too short list" !! 100
  ... Control.Exception.catch t f

(note $! instead of $ in "t".)

	Donn Cave, donn@avvanta.com
From timd at macquarie.com.au  Tue Sep  9 19:36:42 2008
From: timd at macquarie.com.au (Tim Docker)
Date: Tue Sep  9 19:34:35 2008
Subject: [Haskell-cafe] Functional references
In-Reply-To: 
References: <2f9b2d30809041936u3a276145r7f91af324e0fb245@mail.gmail.com><48C0F69F.5010903@jellybean.co.uk>
	
Message-ID: <9A015D433594EA478964C5B34AF3179B01A38644@ntsydexm06.pc.internal.macquarie.com>

I've discussed the license of data-accessor with it's authors (Luke
Palmer & Henning Thieleman). They are ok with changing it to BSD3. So I
don't think the license will be a reason not to use it.

Tim

-----Original Message-----
From: haskell-cafe-bounces@haskell.org
[mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ganesh
Sittampalam
Sent: Saturday, 6 September 2008 4:52 AM
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Functional references

On Fri, 5 Sep 2008, Jules Bean wrote:

> I think it would be worth spending some time (on this mailing list, 
> perhaps, or in another forum) trying to hash out a decent API which 
> meets most people's requirements, rather than ending up with 4 or 5 
> slightly different ones.

This sounds like a good plan, but please make sure the result is as free
as GHC, rather than GPL like data-accessor is. It's so simple that it
being GPL just drives people for whom licencing is an issue to write an
alternative rather than consider complying.

Ganesh
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
From dagit at codersbase.com  Tue Sep  9 20:08:58 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Tue Sep  9 20:06:53 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
Message-ID: 

2008/9/9 Conal Elliott :

> Where do you like to place your tests?  In the functionality modules?  A
> parallel structure?  A single Test.hs file somewhere?

The last time I had a chance to experiment with how to do this I used
a single Test.hs for the whole project and I think that is a bad idea
now.

I agree that you don't want to clutter your code with the test cases.
While it's good to have the tests accessible and near to the actual
code it can be distracting too.

The approach I used is here:
http://blog.codersbase.com/2006/09/01/simple-unit-testing-in-haskell/

Basically, I used the H98 parser plus TH to collect all the test cases
together and generate the test harness at compile time.  This meant
that any module that had a test case had to be plain H98 (but again,
only Test.hs had test cases).  On the other hand, specifying tests was
as simple as starting a function name with "prop_".  You could also
modify my technique to look through all modules, or modules with
specific names.

Another approach is to use conditional compilation with something like
CPP.  This could allow you to export everything from modules only
while testing and then you could have Foo.hs and FooTests.hs for every
module.  The latter one would import everything from Foo.hs and define
the tests.

If you don't like conditional compilation, another approach I think is
decent is to have FooPrivate.hs (or FooInternal.hs), which is imported
into Foo.hs and FooTests.hs.  You could set things up so that only
Foo.hs and FooTests.hs are allowed to import FooPrivate.hs.  You could
of course write a script to enforce this, but something that tends to
be simpler and equally effective is just to politely ask that people
do not import FooPrivate.hs except in FooTests.hs and Foo.hs.

I hope that helps,
Jason
From jason.dusek at gmail.com  Tue Sep  9 20:21:00 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Tue Sep  9 20:18:51 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
Message-ID: <42784f260809091721n45c5b4aan73efcf371ab1db07@mail.gmail.com>

Bruce Eckel  wrote:
> ...shared-memory concurrency is impossible for programmers to
> get right...

  Explicit locking is impractical to get right. Transactional
  interfaces take much of the pain out of that -- even web
  monkeys can get shared memory right with SQL!

  When two instances of a web app interact with the database,
  they are sharing the database's memory. So you have locking,
  mutual corruption and all that jazz -- yet you seem to be
  message passing! More generally, applications backed by
  network services -- which are presented through a message
  passing interface -- are shared memory applications much of
  the time (though a bright service can tell when modifications
  are unrelated and run them in parallel).

  Message passing certainly makes it easier to write parallel
  applications, but does it provide any help to manage shared
  state? No. None whatsoever. If you have a bunch of programs
  that never share state with one another, they are a single
  application in name only.

  Using locking as your default mode of IPC is harrowing, but
  you can do anything with it. Using message passing is simpler
  in most cases, but you'll have to implement locking yourself
  once in awhile. Language level, transactional interfaces to
  memory are going to cover all your bases, but are rare indeed
  -- as far as I'm aware, only Haskell's STM offers one.

> ...the unnatural domain-cutting that happens in shared-memory
> concurrency always trips you up, especially when the scale
> increases.

  This is true even with transactional interfaces. Message
  passing is _like the network_ and makes you think about the
  network -- so when it's time to get two servers and hook them
  together, you are already ready for it already. Transactional
  shared memory is not at all like the network. Why not? In a
  transactional system, a transaction can not both be approved
  and unwritten. On the network, though, these are separate
  messages, going in different directions -- they can fail
  independently.

--
_jsn
From dmehrtash at gmail.com  Tue Sep  9 20:47:29 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Tue Sep  9 20:45:19 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: 
References: 
Message-ID: 

Why do you want to mix haskall and Java in one VM?  If there are
functionality within your code that is better implemented in haskell, then
why not  make that into a service (run it as haskell) with some api that
Java code can use.

Daryoush

On Tue, Sep 9, 2008 at 2:36 AM, Maur??cio  wrote:

> Hi,
>
> I use Haskell, and my friends at
> work use Java. Do you think it
> could be a good idea to use Haskell
> with Java, so I could understand
> and cooperate with them? Is there a
> a Haskell to Java compiler that's
> already ready to use?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Daryoush

Weblog: http://perlustration.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080909/56d70743/attachment.htm
From duncan.coutts at worc.ox.ac.uk  Tue Sep  9 18:59:17 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Sep  9 20:49:37 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
Message-ID: <1221001157.6076.208.camel@localhost>

On Mon, 2008-09-08 at 16:26 -0700, Iavor Diatchki wrote:
> Hi,
> I just noticed that hackage has introduced a new policy to disallow
> changes to a package without bumping the version.  I understand that
> this is probably a good idea for changes to the source code, but it
> really would be nice to have a backdoor that allows for other changes.
>  For example, I just uploaded a package, and realized that I forgot to
> add a home-page entry in the cabal file.  I do not plan to increase
> the version number of my application, only so that I can upload a new
> version (the source code has not changed after all!).  I can imagine
> similar problems related to fixing typos in the description, and other
> fixes to the meta-data.

Yes. We've thought about this a bit. I'll tell you how I think it should
be managed, though I accept not everyone agrees with me.

The .tar.gz packages are pristine and must not change, however
the .cabal file that is kept in the hackage index could change and that
information will be reflected both in the hackage website and just as
importantly for tools like cabal-install. So not only could the
maintainer fix urls or whatever but also adjust dependencies in the
light of test results. Consider the analogy to pristine tarballs and
debian or gentoo meta-data files. The former never changes for a
particular version, but the meta-data can be adjusted as the
distributors see fit.

The difference here is that those two would be in the same format,
the .cabal file inside the tarball that never changes and the one in the
index which may do. This is also the objection that some people have,
that it would be confusing to have the two versions, especially that
unpacking the tarball gives the old unmodified version.

> So, could we please revert to the old policy?

No :-) But I hope with the above system that will not be necessary. I
hope to implement this feature in the new hackage server implementation
that I'll be announcing shortly.

Really it's essential that the md5sums of tarballs never change. Untold
chaos results if they are allowed to change. For one thing our urls
become unusable for distro systems like gentoo, fedora etc and they
would have to take snapshots and keep their own pristine mirrors rather
than using our url as the canonical reference (obviously they do their
own mirroring too but they usually refer back to a canonical source).
That would be a huge pain for them and a barrier to our acceptance into
distros.

> (if we really want to be fancy, the hackage upload script could check
> that the source code, and other fields, such as LICENSE have not
> changed, as these should really bump the version... in the mean time
> though, I think just being responsible members of the community would
> work just as well!).

Indeed we'll also have to check things carefully if we allow package or
distribution maintainers to adjust the .cabal files in the index. For
example changing exposed modules or the name or version number is right
out. We'll err on the restrictive side and gradually loosen as we decide
it's safe and acceptable.

Duncan

From batterseapower at hotmail.com  Tue Sep  9 22:49:27 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Tue Sep  9 22:47:16 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <3c6288ab0809091507t2f8a7f11p3e7df3199db283bf@mail.gmail.com>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>
	
	<9d4d38820809090935s1f8f165dpc5f7dce1d7589dfc@mail.gmail.com>
	<3c6288ab0809091507t2f8a7f11p3e7df3199db283bf@mail.gmail.com>
Message-ID: <9d4d38820809091949k1b2f7b15j13afa6e5223b750f@mail.gmail.com>

2008/9/9 Sean Leather :
>
>> My tests are making use of a nice console test runner I wrote that
>> supports both HUnit and QuickCheck (and is extensible to other test
>> providers by the user):
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
>
> The description looks great! I might have to try it out.

Great!

> I used HUnit with QuickCheck 2, so that I could run QC properties as HUnit
> tests. QC2 has the added ability (over QC1) to run a property and return a
> Bool instead of just exiting with an error, and that works nicely within
> HUnit. Does test-framework do something else to support QC running
> side-by-side with HUnit?

You can see the approach I've taken in the QuickCheck test provider
source code: http://github.com/batterseapower/test-framework/tree/master/Test/Framework/Providers/QuickCheck.hs.
Basically, I just copy-pasted the relevant part of the QuickCheck
source code so I could customise it to my whim :-). I'm not familiar
with the QC2 API, but it's possible I would have had to do this anyway
in order to get progress reporting for QuickCheck tests without them
writing directly to the console (which is _bad_ when there are several
property running at once!) and to obtain the random seed.

Cheers,
Max
From wren at freegeek.org  Tue Sep  9 23:53:19 2008
From: wren at freegeek.org (wren ng thornton)
Date: Tue Sep  9 23:51:09 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: 
References: 		
	
Message-ID: <48C744AF.7020208@freegeek.org>

Justin Bailey wrote:
> 2008/9/8 Daryoush Mehrtash 
> > Thanks.
> >
> > Pattern matching and memory management in Haskell (or may be GHC
> > implementation of it) is somewhat of a mystery to me.  Are there
> > any references that explains the underlying implementation?
> 
> Be careful what you ask for. This paper is 16 years old but fairly
> relevant. Click the "view or download" link at the bottom:
> 
>   "Implementing Lazy Functional Languages on Stock Hardware: The
> Spineless Tagless G-Machine"
>   http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729


That's an excellent paper for getting down to the gritty details of 
what's going on under the covers. However, I think it's not clear that 
that's what you're really looking for; you needn't know anything about 
the STG in order to know how pattern matching works enough to use it.


In short, a pattern is a (free) variable, or a data constructor applied 
to patterns. So if we have:

  > data MyList = Nil | Cons Int MyList

Then we can have the patterns: Nil, (Cons x xs), (Cons 0 xs),..., (Cons 
x Nil), (Cons 0 Nil),..., (Cons x (Cons x2 xs)), etc.

Other notes:

* As demonstrated above, numeric literals count as "data constructors".

* Since a data constructor can be an infix operator (either spelled with 
backticks or a symbolic name beginning with ':' ) we can also write our 
patterns with infix notation.

* Even though there is an intentional homoiconicity between patterns and 
an expression of data constructors, you can't use arbitrary expressions. 
  This falls out from only allowing data constructors in patterns, 
rather than any arbitrary function.

** In particular, you can't use partial application. You also can't use 
anything like (.), ($), flip,...

** (While n+k patterns exist for legacy reasons, they are an 
abomination. They should not be used and are slated for removal in 
haskell prime.)

** For record syntax this homoiconicity means that you get Foo{xpart=x} 
as a pattern binding the variable x. This follows because that's what 
the expression would look like to construct a Foo setting the xpart to a 
variable x. Perhaps confusingly, the '=' involved here is the one from 
record syntax, not the one from let bindings.


The homoiconicity generally makes code easier to read, though it can be 
somewhat confusing when discussing theoretical concerns. The reason is 
that a single lexeme, e.g. 'Cons', is being used both as a data 
constructor (in expressions) and as a data *de*structor (in patterns). 
Identically, a field name in a record is used both as an injector and as 
a projector. This conceptual overloading is perfectly valid, but it 
sometimes leads to people conflating the ideas which is invalid.

There are sometimes reasons to want to throw a wrench into the works, 
breaking up the homoiconicity. One particular example (which I believe 
will be available in 6.10 though it's not approved for haskell prime) is 
to allow "view patterns". The idea behind view patterns is to allow 
functions to be called behind the scenes in order to convert the 
in-memory representation into a view type, and then do pattern matching 
on that view of the value rather than on the value itself. There are two 
primary uses of this: (1) improving legibility of pattern matching for 
complex datastructures, (2) allowing multiple types to all be pattern 
matched interchangeably, e.g. association lists, Maps, HashMaps,...

There are drawbacks to views (and anything else that breaks 
homoiconicity). First off is that it greatly complicates the story of 
what's going on during pattern matching. More importantly, however, is 
that it means that pattern matches are no longer in correspondence with 
the in-memory representations of values. This means that there is a 
hidden performance cost which can get quite high for deep patterns.

-- 
Live well,
~wren
From wren at freegeek.org  Wed Sep 10 00:54:33 2008
From: wren at freegeek.org (wren ng thornton)
Date: Wed Sep 10 00:52:23 2008
Subject: [Haskell-cafe] trying to understand monad transformers....
In-Reply-To: 
References: 
Message-ID: <48C75309.6030804@freegeek.org>

Daryoush Mehrtash wrote:
> The MaybeT transformer is defined as:
> 
> newtype MaybeT m a = MaybeT {runMaybeT :: m (Maybe a)}
> 
> ....
> 
> 
> Question:  What does "runMaybeT x" mean?

As for "what does it do", I think everyone else has handled that pretty 
well. As far as "what does it mean", it may help to think categorically.

For every monad |m| we have another monad |MaybeT m|. If we ignore some 
details, we can think of the transformed monad as |Maybe| composed with 
|m|, sic: |Maybe . m|. With this perspective, runMaybeT is inverting 
|MaybeT m| into |m . Maybe| by pushing the Maybe down over/through the 
monad m. Hence we can envision the function as:

  | runMaybeT           :: (MaybeT m) a -> (m . Maybe) a
  | runMaybeT NothingT   = return Nothing
  | runMaybeT (JustT ma) = fmap Just ma

The reason this is useful at all is that Maybe is not just any monad, 
but is also a primitive value in the system. That is, once we have a 
Maybe value we can treat it as a normal pure value that we can pattern 
match on etc. For other monads like Set, [ ], and LogicMonad this means 
that we can iterate over their elements rather than just treating them 
as functors. Whereas a |MaybeT m| value can't be accessed directly.

This explanation is leaving out details about transformers in general. 
The Maybe/MaybeT type is defined by Maybe(a)=a+1, which is to say it's 
the same as the type |a| plus one additional value. Given this 
definition it's easy to define runMaybeT like above. For other monads 
and monad transformers this conversion might not be so trivial because 
we'll need to thread state through the computation.

This is also the reason why the ordering of your transformer stack is 
important. When converting from the transformer to the composition, how 
to thread the state is non-trivial. This is just the same as saying that 
we can't reorder function compositions and still have the same results. 
A large class of functions do have reorderable compositions[1] just like 
a large class of monads have trivial state, but in general that's not 
the case for either of them.


[1] 
http://haskell.org/haskellwiki/The_Monad.Reader/Issue4/Why_Attribute_Grammars_Matter

-- 
Live well,
~wren
From wren at freegeek.org  Wed Sep 10 01:01:58 2008
From: wren at freegeek.org (wren ng thornton)
Date: Wed Sep 10 00:59:47 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: 
References: 
Message-ID: <48C754C6.8020603@freegeek.org>

Maur??cio wrote:
> Hi,
> 
> I use Haskell, and my friends at
> work use Java. Do you think it
> could be a good idea to use Haskell
> with Java, so I could understand
> and cooperate with them? Is there a
> a Haskell to Java compiler that's
> already ready to use?

Generally speaking, not really. There was a lot of work around the turn 
of the century, but all of it seems to have dried up and been replaced 
by Scala. I can give you some links on various projects, but so far as I 
know there's nothing that's still being maintained/developed so I 
wouldn't suggest any of them for work.

I don't know much about Scala, though there are a few folks on Planet 
Haskell who do. If you're looking for a Haskell-like functional language 
for the JVM, it may be for you.

-- 
Live well,
~wren
From wren at freegeek.org  Wed Sep 10 01:37:08 2008
From: wren at freegeek.org (wren ng thornton)
Date: Wed Sep 10 01:34:57 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 	
	
Message-ID: <48C75D04.4050905@freegeek.org>

Pieter Laeremans wrote:
> This :
> Prelude> let f = (\x -> return "something went wrong")  ::   IOError -> IO
> String
> Prelude> let t = return $ show $ "too short list" !! 100 :: IO String
> Prelude> catch t f
> "*** Exception: Prelude.(!!): index too large
> 
> doesn't work.


As others've said, the right answer is to correct the bug rather than 
doing exception handling, but in as far as knowing how to do exception 
handling for "pure" functions, consider:

   http://code.haskell.org/~wren/wren-extras/Control/Exception/Extras.hs

The trickiest thing to watch out for is that you must strictly evaluate 
the expression or else the return/evaluate function will just lazily 
thunk up the expression. Which means that when you finally run the IO, 
you'll have already stripped off the IO wrapper that can catch the 
exception prior to evaluating the expression (which then throws an 
exception out past the catcher).

Another thing to watch out for is that Prelude.catch doesn't do what you 
want because the H98 spec declares these exceptions to be uncatchable. 
The Control.Exception.catch function does what you want and is portable 
even though it's not H98.

If you're doing the unsafePerformIO trick to purify your exception 
handling be sure to give a NOINLINE pragma to prevent potentially buggy 
inlining. You should also be sure that the handler is something which is 
actually safe to unsafePerformIO.

Finally, to ensure that other optimizations or evaluation orders don't 
accidentally mess you up, you should take the higher-order approach of 
`safely` to ensure that you don't accidentally apply the function prior 
to wrapping it up in a catcher.

-- 
Live well,
~wren
From waldmann at imn.htwk-leipzig.de  Wed Sep 10 01:39:15 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Wed Sep 10 01:37:08 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
References: 	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>	
	
Message-ID: <48C75D83.5020409@imn.htwk-leipzig.de>

Jason Dagit wrote:

>   On the other hand, specifying tests was
> as simple as starting a function name with "prop_" [...]

which of course reminds us of JUnit of the dark ages (up to 3.8),
before they finally used annotations to declare test cases.

Has there ever been a discussion of typed, user-definable,
user-processable source code annotations for Haskell?

J.W.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/b17fcf42/signature.bin
From bulat.ziganshin at gmail.com  Wed Sep 10 02:20:53 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Wed Sep 10 02:21:13 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <48C75D83.5020409@imn.htwk-leipzig.de>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	
	<48C75D83.5020409@imn.htwk-leipzig.de>
Message-ID: <1114796266.20080910102053@gmail.com>

Hello Johannes,

Wednesday, September 10, 2008, 9:39:15 AM, you wrote:

> Has there ever been a discussion of typed, user-definable,
> user-processable source code annotations for Haskell?

afair it was on haskell-prime list

btw, Template Haskell may be used for this purpose (although not in
portable way, of course)



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From wren at freegeek.org  Wed Sep 10 02:40:17 2008
From: wren at freegeek.org (wren ng thornton)
Date: Wed Sep 10 02:38:07 2008
Subject: [Haskell-cafe] trying to understand monad transformers....
In-Reply-To: <48C75309.6030804@freegeek.org>
References: 
	<48C75309.6030804@freegeek.org>
Message-ID: <48C76BD1.2000608@freegeek.org>

wren ng thornton wrote:
> Daryoush Mehrtash wrote:
>> The MaybeT transformer is defined as:
>>
>> newtype MaybeT m a = MaybeT {runMaybeT :: m (Maybe a)}
>>
>> ....
>>
>>
>> Question:  What does "runMaybeT x" mean?
> 
> As for "what does it do", I think everyone else has handled that pretty 
> well. As far as "what does it mean", it may help to think categorically.
> 
> For every monad |m| we have another monad |MaybeT m|. If we ignore some 
> details, we can think of the transformed monad as |Maybe| composed with 
> |m|, sic: |Maybe . m|. With this perspective, runMaybeT is inverting 
> |MaybeT m| into |m . Maybe| by pushing the Maybe down over/through the 
> monad m. Hence we can envision the function as:
> 
>  | runMaybeT           :: (MaybeT m) a -> (m . Maybe) a
>  | runMaybeT NothingT   = return Nothing
>  | runMaybeT (JustT ma) = fmap Just ma


Erh, whoops, I said that backwards. |MaybeT m| is like |m . Maybe| and 
runMaybeT breaks apart the implicit composition into an explicit one. 
The MaybeT monad just gives the additional possibility of a Nothing 
value at *each* object in |m a|.

To see why this is different than the above, consider where |m| is a 
list or Logic. |MaybeT []| says that each element of the list 
independently could be Nothing, whereas |ListT Maybe| says that we have 
either Nothing or Just xs. The pseudocode above gives the latter case 
since it assumes a top level Nothing means Nothing everywhere, which is 
wrong for |MaybeT m|.

-- 
Live well,
~wren
From andy.haskell at zambezi.org.uk  Wed Sep 10 02:47:45 2008
From: andy.haskell at zambezi.org.uk (Andy Smith)
Date: Wed Sep 10 02:45:34 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: 
References: 
Message-ID: <5540a5470809092347r19bcc865r9ea8ebae1cb6ddd6@mail.gmail.com>

2008/9/9 Maur??cio :
> I use Haskell, and my friends at
> work use Java. Do you think it
> could be a good idea to use Haskell
> with Java, so I could understand
> and cooperate with them? Is there a
> a Haskell to Java compiler that's
> already ready to use?

Besides the other approaches people have suggested, maybe you could
use a combination of the Haskell FFI and JNI (Java Native Interface)
or JNA (Java Native Access). I have no idea how practical this would
be, and it would only work on platforms where you can compile Haskell
to native code rather than on any JVM, but if that's OK it might be
worth exploring.

If you want to call Haskell functions from Java, it seems to me it
should be possible to write FFI export declarations for the Haskell
functions you want to use from Java, and write a C wrapper to package
the exported functions for JNI as if they were native C functions.
With JNA you might be able to avoid writing a C wrapper, although I
know even less about JNA than I do about JNI. It should also be
possible to go the other way if you want to call Java code from
Haskell, at least with JNI but possibly not with JNA.

Andy
From waldmann at imn.htwk-leipzig.de  Wed Sep 10 03:00:29 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Wed Sep 10 02:58:18 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <1114796266.20080910102053@gmail.com>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	
	<48C75D83.5020409@imn.htwk-leipzig.de>
	<1114796266.20080910102053@gmail.com>
Message-ID: <48C7708D.8040403@imn.htwk-leipzig.de>


>> Has there ever been a discussion of typed, user-definable,
>> user-processable source code annotations for Haskell?
> 
> afair it was on haskell-prime list

http://hackage.haskell.org/trac/haskell-prime/ticket/88

if you can call that a discussion :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/d0c3997b/signature.bin
From voigt at tcs.inf.tu-dresden.de  Wed Sep 10 03:50:56 2008
From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender)
Date: Wed Sep 10 03:37:21 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: <1927421099.20080910001714@gmail.com>
References:  <1927421099.20080910001714@gmail.com>
Message-ID: <48C77C60.1050508@tcs.inf.tu-dresden.de>

Bulat Ziganshin wrote:
>>Is there a
>>a Haskell to Java compiler that's
>>already ready to use?
> 
> 
> CAL
> 

Just in case this answer was a bit cryptic for the original poster...

What Bulat means is the following:

http://labs.businessobjects.com/cal/

-- 
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:voigt@tcs.inf.tu-dresden.de



From g9ks157k at acme.softbase.org  Wed Sep 10 04:11:39 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Wed Sep 10 04:09:30 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <1221001157.6076.208.camel@localhost>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<1221001157.6076.208.camel@localhost>
Message-ID: <200809101011.39330.g9ks157k@acme.softbase.org>

Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:
> [?]

> The .tar.gz packages are pristine and must not change, however
> the .cabal file that is kept in the hackage index could change and that
> information will be reflected both in the hackage website and just as
> importantly for tools like cabal-install.

I don?t think this is a good idea.  The package description, list of exposed 
modules, etc. belongs to the software, in my opinion.  So changing it means 
changing the software which should be reflected by a version number increase.

Why can?t package maintainers double-check that they got everything in the 
Cabal file right before the package is uploaded to Hackage?  And if one has 
forgotten a URL or something like that, it is still possible to release a new 
version where just the 4th component of the version number was changed which 
means precisely that the interface didn?t change.

> [?]

> The difference here is that those two would be in the same format,
> the .cabal file inside the tarball that never changes and the one in the
> index which may do. This is also the objection that some people have,
> that it would be confusing to have the two versions, especially that
> unpacking the tarball gives the old unmodified version.

Yes, it *is* confusing.

> [?]

> I hope to implement this feature in the new hackage server implementation
> that I'll be announcing shortly.

May I kindly ask you to *not* implement this feature?

> [?]

Best wishes,
Wolfgang
From g9ks157k at acme.softbase.org  Wed Sep 10 04:20:37 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Wed Sep 10 04:18:27 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
References: 
	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
Message-ID: <200809101020.37847.g9ks157k@acme.softbase.org>

Am Dienstag, 9. September 2008 15:46 schrieb Sean Leather:
> [?]

> Testing non-exported functionality without exporting the test interface
> seems difficult in general. Is there a way to hide part of a module
> interface with Cabal? Then, you could have a 'test' function exported from
> each module for testing but hidden for release.

You can have modules not included in the Exposed-Modules section which contain 
the actual implementation and export also some internals used for testing.  
Then you can let the exposed modules import these internal modules and 
reexport the stuff intended for the public.

> [?]

Best wishes,
Wolfgang
From g9ks157k at acme.softbase.org  Wed Sep 10 04:24:25 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Wed Sep 10 04:22:14 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: 
References: 
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
Message-ID: <200809101024.25601.g9ks157k@acme.softbase.org>

Am Dienstag, 9. September 2008 16:05 schrieb Conal Elliott:
> [?]

> > > My current leaning is to split a package "foo" into packages "foo"
> > > and "foo-test" 
> >
> > What benefit does this provide?
>
> It keeps the library and its dependencies small.

Do you publish foo-test on Hackage?  If yes than the HackageDB gets cluttered 
with test packages.  If not, there is no easy way for users to run your 
tests.

> [?]

Best wishes,
Wolfgang
From ross at soi.city.ac.uk  Wed Sep 10 05:26:06 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Wed Sep 10 05:23:56 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <1221001157.6076.208.camel@localhost>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<1221001157.6076.208.camel@localhost>
Message-ID: <20080910092605.GA3329@soi.city.ac.uk>

On Tue, Sep 09, 2008 at 10:59:17PM +0000, Duncan Coutts wrote:
> The .tar.gz packages are pristine and must not change, however
> the .cabal file that is kept in the hackage index could change and that
> information will be reflected both in the hackage website and just as
> importantly for tools like cabal-install. So not only could the
> maintainer fix urls or whatever but also adjust dependencies in the
> light of test results. Consider the analogy to pristine tarballs and
> debian or gentoo meta-data files. The former never changes for a
> particular version, but the meta-data can be adjusted as the
> distributors see fit.

So if Debian or Gentoo etc repackage one of these packages in their
distributions, what is the pristine tarball that they use?
From maarten.hazewinkel at gmail.com  Wed Sep 10 05:55:04 2008
From: maarten.hazewinkel at gmail.com (Maarten Hazewinkel)
Date: Wed Sep 10 05:52:57 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
Message-ID: <84B2C9FF-06E9-41B3-9146-34B174A9D6DC@mac.com>

Hi Bruce,

Some comments from an 11 year Java professional and occasional Haskell  
hobbyist.


On 9 Sep 2008, at 20:30, Bruce Eckel wrote:

> So this is the kind of problem I keep running into. There will seem  
> to be consensus that you can do everything with isolated processes  
> message passing (and note here that I include Actors in this  
> scenario even if their mechanism is more complex). And then someone  
> will pipe up and say "well, of course, you have to have threads" and  
> the argument is usually "for efficiency."

One important distinction to make, which can make a lot of difference  
in performance, is that shared memory itself is not a problem. It's  
when multiple threads/processes can update a single shared area that  
you get into trouble. A single updating thread is OK as long as other  
threads don't depend on instant propagation of the update or on an  
update being visible to all other threads at the exact same time.


> I make two observations here which I'd like comments on:
>
> 1) What good is more efficiency if the majority of programmers can  
> never get it right? My position: if a programmer has to explicitly  
> synchronize anywhere in the program, they'll get it wrong. This of  
> course is a point of contention; I've met a number of people who say  
> "well, I know you don't believe it, but *I* can write successful  
> threaded programs." I used to think that, too. But now I think it's  
> just a learning phase, and you aren't a reliable thread programmer  
> until you say "it's impossible to get right" (yes, a conundrum).

In general I agree. I'm (in all modesty) the best multi-thread  
programmer I've ever met, and even if you were to get it right, the  
next requirements change tends to hit your house of cards with a large  
bucket of water.
And never mind trying to explain the design to other developers. I  
currently maintain a critical multi-threaded component (inherited from  
another developer who left), and my comment on the design is "I cannot  
even properly explain it to myself, let alone someone else". Which is  
why I have a new design based on java.util.concurrent queues on the  
table.

> 2) What if you have lots of processors? Does that change the picture  
> any? That is, if you use isolated processes with message passing and  
> you have as many processors as you want, do you still think you need  
> shared-memory threading?

In such a setup I think you usually don't have directly shared memory  
at the hardware level, so the processors themselves have to use  
message passing to access shared data structures. Which IMHO means  
that you might as well design your software that way too.


> A comment on the issue of serialization -- note that any time you  
> need to protect shared memory, you use some form of serialization.  
> Even optimistic methods guarantee serialization, even if it happens  
> after the memory is corrupted, by backing up to the uncorrupted  
> state. The effect is the same; only one thread can access the shared  
> state at a time.

And a further note on sharing memory via a transactional resource (be  
it STM, a database or a single controlling thread).
This situation always introduces the possibility that your update  
fails, and a lot of client code is not designed to deal with that. The  
most common pattern I see in database access code is to log the  
exception and continue as if nothing happened. The proper error  
handling only gets added in after a major screwup in production  
happens, and the usually only the the particular part of the code  
where it went wrong this time.


Kind regards,

Maarten Hazewinkel
From duncan.coutts at worc.ox.ac.uk  Wed Sep 10 05:47:20 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Sep 10 05:59:55 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <200809101011.39330.g9ks157k@acme.softbase.org>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<1221001157.6076.208.camel@localhost>
	<200809101011.39330.g9ks157k@acme.softbase.org>
Message-ID: <1221040040.6076.286.camel@localhost>

On Wed, 2008-09-10 at 10:11 +0200, Wolfgang Jeltsch wrote:
> Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:
> > [?]
> 
> > The .tar.gz packages are pristine and must not change, however
> > the .cabal file that is kept in the hackage index could change and that
> > information will be reflected both in the hackage website and just as
> > importantly for tools like cabal-install.
> 
> I don?t think this is a good idea.  The package description, list of exposed 
> modules, etc. belongs to the software, in my opinion.  So changing it means 
> changing the software which should be reflected by a version number increase.

Remember that all the distributors are doing this all the time and it
doesn't cause (many) problems. They change the meta-data from what the
upstream authors give and they add patches etc etc.

Granted, they do use a revision number to track this normally. For
example a package foo-1.0 on hackage would become
dev-haskell/foo-1.0.ebuild in gentoo and if it needs to be updated for
some reason it becomes ?dev-haskell/foo-1.0-r1.ebuild and the number is
increased by one for every subsequent revision. Distros like debian have
similar systems.

> Why can?t package maintainers double-check that they got everything in the 
> Cabal file right before the package is uploaded to Hackage?  And if one has 
> forgotten a URL or something like that, it is still possible to release a new 
> version where just the 4th component of the version number was changed which 
> means precisely that the interface didn?t change.

Note that the distros are actually making code changes (applying bug fix
patches) and not bumping the upstream version number, though they do
bump their additional revision number. I'm not suggesting anything so
radical. I'm just suggesting that you could change the category tags, or
improve the description. The most radical thing is tightening or
relaxing the version constraints on dependencies. For example if your
package depends on foo >= 1.0 && < 1.1 but then foo-1.1 comes out and
although it does contain api changes and had the potential to break your
package (which is why you put the conservative upper bound) it turns out
that you were not using the bits of the api that changed and it does in
fact work with 1.1 so you can adjust the dependencies to ?foo >= 1.0 &&
< 1.2.  Again, this is just the sort of thing that distros do.

> > [?]
> 
> > The difference here is that those two would be in the same format,
> > the .cabal file inside the tarball that never changes and the one in the
> > index which may do. This is also the objection that some people have,
> > that it would be confusing to have the two versions, especially that
> > unpacking the tarball gives the old unmodified version.
> 
> Yes, it *is* confusing.
> 
> > [?]
> 
> > I hope to implement this feature in the new hackage server implementation
> > that I'll be announcing shortly.
> 
> May I kindly ask you to *not* implement this feature?

Well we need something like it I think. At least if we want to be able
to install things direct from hackage and have some level of reliance on
stated dependencies reflecting reality. It also allows us to share some
QA between all the distros which have to do this work anyway.

If we consider hackage as a raw upstream package collection that gets
picked over and QA'd by the distros then it's not necessary. But I think
we want to use it for both, for pristine upstream tarball releases but
also I think we expect to be able to use it directly with things like
cabal-install and so adding some distro-like management features is
useful.

So we should think about how to make it less confusing. Perhaps like
distributors use an extra revision number we should do the same. I had
hoped that would not be necessary but that's probably not realistic.

Duncan

From ketil at malde.org  Wed Sep 10 06:09:07 2008
From: ketil at malde.org (Ketil Malde)
Date: Wed Sep 10 06:04:57 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <1221040040.6076.286.camel@localhost> (Duncan Coutts's message of
	"Wed\, 10 Sep 2008 09\:47\:20 +0000")
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<1221001157.6076.208.camel@localhost>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
Message-ID: <87myig2tz0.fsf@malde.org>

Duncan Coutts  writes:

> So we should think about how to make it less confusing. Perhaps like
> distributors use an extra revision number we should do the same. I had
> hoped that would not be necessary but that's probably not realistic.

If we go this route, it'd be nice to have a distinguishable syntax,
like Gentoo's .rN, so that we don't have to remember whether it's
digit four or five that signifies "administrative" changes.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From conal at conal.net  Wed Sep 10 06:12:17 2008
From: conal at conal.net (Conal Elliott)
Date: Wed Sep 10 06:10:06 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <200809101024.25601.g9ks157k@acme.softbase.org>
References: 
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
	
	<200809101024.25601.g9ks157k@acme.softbase.org>
Message-ID: 

If I do foo and foo-test, then I would probably place foo-test on Hackage.
Alternatively, just give foo a pointer to the location of the foo-test darcs
repo location.  But then it might not be easy for users to keep the versions
in sync.

On Wed, Sep 10, 2008 at 10:24 AM, Wolfgang Jeltsch <
g9ks157k@acme.softbase.org> wrote:

> Am Dienstag, 9. September 2008 16:05 schrieb Conal Elliott:
> > [?]
>
> > > > My current leaning is to split a package "foo" into packages "foo"
> > > > and "foo-test"
> > >
> > > What benefit does this provide?
> >
> > It keeps the library and its dependencies small.
>
> Do you publish foo-test on Hackage?  If yes than the HackageDB gets
> cluttered
> with test packages.  If not, there is no easy way for users to run your
> tests.
>
> > [?]
>
> Best wishes,
> Wolfgang
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/7a829995/attachment.htm
From duncan.coutts at worc.ox.ac.uk  Wed Sep 10 06:07:54 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Sep 10 06:33:45 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <20080910092605.GA3329@soi.city.ac.uk>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<1221001157.6076.208.camel@localhost>
	<20080910092605.GA3329@soi.city.ac.uk>
Message-ID: <1221041274.6076.290.camel@localhost>

On Wed, 2008-09-10 at 10:26 +0100, Ross Paterson wrote:
> On Tue, Sep 09, 2008 at 10:59:17PM +0000, Duncan Coutts wrote:
> > The .tar.gz packages are pristine and must not change, however
> > the .cabal file that is kept in the hackage index could change and that
> > information will be reflected both in the hackage website and just as
> > importantly for tools like cabal-install. So not only could the
> > maintainer fix urls or whatever but also adjust dependencies in the
> > light of test results. Consider the analogy to pristine tarballs and
> > debian or gentoo meta-data files. The former never changes for a
> > particular version, but the meta-data can be adjusted as the
> > distributors see fit.
> 
> So if Debian or Gentoo etc repackage one of these packages in their
> distributions, what is the pristine tarball that they use?

They use the one and only ?pristine tarball. As for what meta-data they
choose, that's up to them, they have the choice of using the
original .cabal file in the .tar.gz or taking advantage of the updated
version.

Duncan

From g9ks157k at acme.softbase.org  Wed Sep 10 06:48:35 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Wed Sep 10 06:46:24 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <1221040040.6076.286.camel@localhost>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
Message-ID: <200809101248.35698.g9ks157k@acme.softbase.org>

Am Mittwoch, 10. September 2008 11:47 schrieben Sie:
> On Wed, 2008-09-10 at 10:11 +0200, Wolfgang Jeltsch wrote:
> > Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:
> > > [?]
> > >
> > > The .tar.gz packages are pristine and must not change, however
> > > the .cabal file that is kept in the hackage index could change and that
> > > information will be reflected both in the hackage website and just as
> > > importantly for tools like cabal-install.
> >
> > I don?t think this is a good idea.  The package description, list of
> > exposed modules, etc. belongs to the software, in my opinion.  So
> > changing it means changing the software which should be reflected by a
> > version number increase.
>
> Remember that all the distributors are doing this all the time and it
> doesn't cause (many) problems. They change the meta-data from what the
> upstream authors give and they add patches etc etc.
>
> Granted, they do use a revision number to track this normally.

And this is an important difference, in my opinion.  Changing meta-data is 
probably okay if a revision number is changed.

> [?]

> The most radical thing is tightening or relaxing the version constraints on
> dependencies. For example if your package depends on foo >= 1.0 && < 1.1 but
> then foo-1.1 comes out and although it does contain api changes and had the
> potential to break your package (which is why you put the conservative upper
> bound) it turns out that you were not using the bits of the api that changed
> and it does in fact work with 1.1 so you can adjust the dependencies to ?foo
> >= 1.0 && < 1.2.

But what happens if you need the loose dependencies.  cabal-install checks the 
updated Cabal file and might see that you?ve already installed the correct 
dependencies.  It downloads and unpacks the package and then Cabal uses the 
Cabal file included in the package and complains about unmet dependencies.  
Or shall there be a mechanism to overwrite the package?s Cabal file with the 
updated Cabal file?

> [?]

> So we should think about how to make it less confusing. Perhaps like
> distributors use an extra revision number we should do the same.

Yes, maybe this is the way to go.

> [?]

Best wishes,
Wolfgang
From sebastian.sylvan at gmail.com  Wed Sep 10 07:23:03 2008
From: sebastian.sylvan at gmail.com (Sebastian Sylvan)
Date: Wed Sep 10 07:20:52 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
Message-ID: <3d96ac180809100423q564b8088t7ecd19c99f19d1cd@mail.gmail.com>

2008/9/9 Bruce Eckel 

> So this is the kind of problem I keep running into. There will seem to be
> consensus that you can do everything with isolated processes message passing
> (and note here that I include Actors in this scenario even if their
> mechanism is more complex). And then someone will pipe up and say "well, of
> course, you have to have threads" and the argument is usually "for
> efficiency."
> I make two observations here which I'd like comments on:
>
> 1) What good is more efficiency if the majority of programmers can never
> get it right? My position: if a programmer has to explicitly synchronize
> anywhere in the program, they'll get it wrong. This of course is a point of
> contention; I've met a number of people who say "well, I know you don't
> believe it, but *I* can write successful threaded programs." I used to think
> that, too. But now I think it's just a learning phase, and you aren't a
> reliable thread programmer until you say "it's impossible to get right"
> (yes, a conundrum).
>


I don't see why this needs to be a religious either-or issue? As I said,
*when* isolated threads maps well to your problem, they are more attractive
than shared memory solutions (for correctness reasons), but preferring
isolated threads does not mean you should ignore the reality that they do
not fit every scenario well. There's no single superior
concurrency/parallelism paradigm (at least not yet), so the best we can do
for general purpose languages is to recognize the relative
strengths/weaknesses of each and provide all of them.


>
> 2) What if you have lots of processors? Does that change the picture any?
> That is, if you use isolated processes with message passing and you have as
> many processors as you want, do you still think you need shared-memory
> threading?
>

Not really. There are still situations where you have large pools of
*potential* data with no way of figuring out ahead of time what pieces
you'll need to modify . So for explicit synchronisation, e.g. using isolated
threads to "own" the data, or with locks, you'll need to be conservative and
lock the whole world, which means you might as well run everything
sequentially. Note here that implementing this scenario using isolated
threads with message passing effectively boils down to simulating locks and
shared memory - so if you're using shared memory and locks anyway, why not
have native (efficient) support for them?

As I said earlier, though, I believe the best way to synchronize shared
memory is currently STM, not using manual locks (simulated with threads or
otherwise).


>
> A comment on the issue of serialization -- note that any time you need to
> protect shared memory, you use some form of serialization. Even optimistic
> methods guarantee serialization, even if it happens after the memory is
> corrupted, by backing up to the uncorrupted state. The effect is the same;
> only one thread can access the shared state at a time.
>


Yes, the difference is that with isolated threads, or with manual locking,
the programmer has to somehow figure out which pieces lock ahead of time, or
write manual transaction protocols with rollbacks etc. The ideal case is
that you have a runtime (possibly with hardware support) to let you off the
hook and automatically do a very fine-grained locking with optimistic
concurrency.

Isolated threads and locks are on the same side of this argument - they both
require the user to ahead of time partition the data up and decide how to
serialize operations on the data (which is not always possible statically,
leading to very very complicated code, or very low concurrency).

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/54054fd7/attachment.htm
From briqueabraque at yahoo.com  Wed Sep 10 08:01:42 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 10 07:59:43 2008
Subject: [Haskell-cafe] Re: Haskell and Java
In-Reply-To: 
References: 
	
Message-ID: 

At this time It's not really a question
of better implementation, but cooperation.
I know Haskell, they know Java, and it
would be nice if we could share code and
work. The idea of the api, or maybe dbus,
seems OK. It just would be easier if we
could join everything in a single piece,
but it is no big deal.

Maur?cio

Daryoush Mehrtash a ?crit :
> Why do you want to mix haskall and Java in one VM?  If there are 
> functionality within your code that is better implemented in haskell, 
> then why not  make that into a service (run it as haskell) with some api 
> that Java code can use.
> 
> Daryoush
> 
> On Tue, Sep 9, 2008 at 2:36 AM, Maur??cio  > wrote:
> 
>     Hi,
> 
>     I use Haskell, and my friends at
>     work use Java. Do you think it
>     could be a good idea to use Haskell
>     with Java, so I could understand
>     and cooperate with them? Is there a
>     a Haskell to Java compiler that's
>     already ready to use?
> 
>     Thanks,
>     Maur?cio
> 
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe@haskell.org 
>     http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> 
> 
> -- 
> Daryoush
> 
> Weblog: http://perlustration.blogspot.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From briqueabraque at yahoo.com  Wed Sep 10 08:07:41 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 10 08:06:10 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: <48C744AF.7020208@freegeek.org>
References: 			
	<48C744AF.7020208@freegeek.org>
Message-ID: 


> (...)
> * Since a data constructor can be an infix operator (either spelled with 
> backticks or a symbolic name beginning with ':' ) we can also write our 
> patterns with infix notation.
> (...)

(Slightly off-topic?)

Do you have any reference for that use of infixing
constructors by start their name with ':'? That's
interesting, and I didn't know about it.

Thanks,
Maur?cio

From marco-oweber at gmx.de  Wed Sep 10 08:12:00 2008
From: marco-oweber at gmx.de (Marc Weber)
Date: Wed Sep 10 08:09:50 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: 
References: 
Message-ID: <20080910121200.GA6861@gmx.de>

There used to be.
http://www.cs.rit.edu/~bja8464/lambdavm/
(Last darcs change log entry:
Sun Oct 21 03:05:20 CEST 2007  Brian Alliet 
  * fix build for hsjava change
)
However it didn't compile for me or I had some other problems.
The last bits from the Java backend have been removed 4 month ago.
Someone has just said: Fine, so they are finally just gone after a long
while of just laying around (or something similar)

Eclipsefp itself is nice, but It's lacking all functionality you'd
expect from an Eclipse plugin today except compiling.
(So no outline, jump to definitions etc.. :( (AFAIK))

So if you want to revive a Haskell -> JVM project you'll need to dive
into some internals and spend quite a lot time on that project I'd guess.

Sincerly
Marc Weber
From bulat.ziganshin at gmail.com  Wed Sep 10 08:53:17 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Wed Sep 10 08:52:51 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: 
References: 
	
	
	
	<48C744AF.7020208@freegeek.org> 
Message-ID: <782365738.20080910165317@gmail.com>

Hello Mauricio,

Wednesday, September 10, 2008, 4:07:41 PM, you wrote:

> Do you have any reference for that use of infixing
> constructors by start their name with ':'? That's
> interesting, and I didn't know about it.

really? ;)

sum (x:xs) = x + sum xs
sum []     = 0


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From batterseapower at hotmail.com  Wed Sep 10 08:56:54 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Wed Sep 10 08:54:43 2008
Subject: User defined annotations for Haskell (Was: [Haskell-cafe] packages
	and QuickCheck)
Message-ID: <9d4d38820809100556v2729f2c8r7948bfdeda126fd9@mail.gmail.com>

2008/9/10 Johannes Waldmann :
>
>>> Has there ever been a discussion of typed, user-definable,
>>> user-processable source code annotations for Haskell?
>>
>> afair it was on haskell-prime list
>
> http://hackage.haskell.org/trac/haskell-prime/ticket/88
>
> if you can call that a discussion :-)

I had to implement a kind of annotation system for GHC as part of my
Summer of Code project for compiler plugins. You can see a discussion
at http://hackage.haskell.org/trac/ghc/wiki/Plugins/Annotations,
though I was not aware of that Haskell' ticket.

The system as I have implemented is quite basic: the absolute minimum
I needed for plugins. The syntax is essentially:

{-# ANN foo "I am an annotation!" #-}

Where "I am an annotation" may be replaced with any Typeable value,
and is subject to staging requirements analgous to Template Haskell
(e.g. you may not refer to things in the module being compiled other
than by Template Haskell Name).

As well as values you can annotate types and modules, and annotations
are accessible via the GHC API. See that wiki page for full details.

This system has not yet been merged into GHC (or even code reviewed by
GHC HQ), so if/when it becomes available to end users the design may
have changed drastically.

Cheres,
Max
From daveroundy at gmail.com  Wed Sep 10 09:05:12 2008
From: daveroundy at gmail.com (David Roundy)
Date: Wed Sep 10 09:03:00 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <20080909192320.GG3126@brakk.ethz.ch>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<20080909192320.GG3126@brakk.ethz.ch>
Message-ID: <117f2cc80809100605l54ea9b7fse5019b05853b11c@mail.gmail.com>

2008/9/9 Jed Brown :
> On Tue 2008-09-09 12:30, Bruce Eckel wrote:
>> So this is the kind of problem I keep running into. There will seem to be
>> consensus that you can do everything with isolated processes message passing
>> (and note here that I include Actors in this scenario even if their mechanism
>> is more complex). And then someone will pipe up and say "well, of course, you
>> have to have threads" and the argument is usually "for efficiency."
>
> Some pipe up and say ``you can't do global shared memory because it's
> inefficient''.  Ensuring cache coherency with many processors operating
> on shared memory is a nightmare and inevitably leads to poor
> performance.  Perhaps some optimizations could be done if the programs
> were guaranteed to have no mutable state, but that's not realistic.
> Almost all high performance machines (think top500) are distributed
> memory with very few cores per node.  Parallel programs are normally
> written using MPI for communication and they can achieve nearly linear
> scaling to 10^5 processors BlueGene/L for scientific problems with
> strong global coupling.

I should point out, however, that in my experience MPI programming
involves deadlocks and synchronization handling that are at least as
nasty as any I've run into doing shared-memory threading.  This isn't
an issue, of course, as long as you're letting lapack do all the
message passing, but once you've got to deal with message passing
between nodes, you've got bugs possible that are strikingly similar to
the sorts of nasty bugs present in shared memory threaded code using
locks.

David
From nfjinjing at gmail.com  Wed Sep 10 09:14:28 2008
From: nfjinjing at gmail.com (jinjing)
Date: Wed Sep 10 09:12:18 2008
Subject: [Haskell-cafe] message passing style in Monad
Message-ID: <81ea7d400809100614y3a518d65o318b3e2f966e1340@mail.gmail.com>

I found that as I can do

  xs.map(+1).sort

by redefine . to be

  a . f = f a
  infixl 9 .

I can also do

  readFile "readme.markdown" <.> lines <.> length

by making

  a <.> b = a .liftM b
  infixl 9 <.>

Kinda annoying, but the option is there.

- jinjing
From nfjinjing at gmail.com  Wed Sep 10 09:22:27 2008
From: nfjinjing at gmail.com (jinjing)
Date: Wed Sep 10 09:20:15 2008
Subject: [Haskell-cafe] Re: message passing style in Monad
In-Reply-To: <81ea7d400809100614y3a518d65o318b3e2f966e1340@mail.gmail.com>
References: <81ea7d400809100614y3a518d65o318b3e2f966e1340@mail.gmail.com>
Message-ID: <81ea7d400809100622n788a4e72q98340ff8ec686527@mail.gmail.com>

sorry about the confusion, too much drinks.
I used the redefined . in the difination of <.>. it should really just be

  flip liftM

On Wed, Sep 10, 2008 at 9:14 PM, jinjing  wrote:
> I found that as I can do
>
>  xs.map(+1).sort
>
> by redefine . to be
>
>  a . f = f a
>  infixl 9 .
>
> I can also do
>
>  readFile "readme.markdown" <.> lines <.> length
>
> by making
>
>  a <.> b = a .liftM b
>  infixl 9 <.>
>
> Kinda annoying, but the option is there.
>
> - jinjing
>
From jed at 59A2.org  Wed Sep 10 09:30:50 2008
From: jed at 59A2.org (Jed Brown)
Date: Wed Sep 10 09:28:41 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <117f2cc80809100605l54ea9b7fse5019b05853b11c@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<20080909192320.GG3126@brakk.ethz.ch>
	<117f2cc80809100605l54ea9b7fse5019b05853b11c@mail.gmail.com>
Message-ID: <20080910133050.GN3126@brakk.ethz.ch>

On Wed 2008-09-10 09:05, David Roundy wrote:
> 2008/9/9 Jed Brown :
> > On Tue 2008-09-09 12:30, Bruce Eckel wrote:
> >> So this is the kind of problem I keep running into. There will seem to be
> >> consensus that you can do everything with isolated processes message passing
> >> (and note here that I include Actors in this scenario even if their mechanism
> >> is more complex). And then someone will pipe up and say "well, of course, you
> >> have to have threads" and the argument is usually "for efficiency."
> >
> > Some pipe up and say ``you can't do global shared memory because it's
> > inefficient''.  Ensuring cache coherency with many processors operating
> > on shared memory is a nightmare and inevitably leads to poor
> > performance.  Perhaps some optimizations could be done if the programs
> > were guaranteed to have no mutable state, but that's not realistic.
> > Almost all high performance machines (think top500) are distributed
> > memory with very few cores per node.  Parallel programs are normally
> > written using MPI for communication and they can achieve nearly linear
> > scaling to 10^5 processors BlueGene/L for scientific problems with
> > strong global coupling.
> 
> I should point out, however, that in my experience MPI programming
> involves deadlocks and synchronization handling that are at least as
> nasty as any I've run into doing shared-memory threading.

Absolutely, avoiding deadlock is the first priority (before error
handling).  If you use the non-blocking interface, you have to be very
conscious of whether a buffer is being used or the call has completed.
Regardless, the API requires the programmer to maintain a very clear
distinction between locally owned and remote memory.

> This isn't an issue, of course, as long as you're letting lapack do
> all the message passing, but once you've got to deal with message
> passing between nodes, you've got bugs possible that are strikingly
> similar to the sorts of nasty bugs present in shared memory threaded
> code using locks.

Lapack per-se does not do message passing.  I assume you mean whatever
parallel library you are working with, for instance, PETSc.  Having the
right abstractions goes a long way.

I'm happy to trade the issues with shared mutable state for distributed
synchronization issues, but that is likely due to it's suitability for
the problems I'm interested in.  If the data model maps cleanly to
distributed memory, I think it is easier than coarse-grained shared
parallelism.  (OpenMP is fine-grained; there is little or no shared
mutable state and it is very easy.)

Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/19228017/attachment.bin
From michal.palka at poczta.fm  Wed Sep 10 09:47:09 2008
From: michal.palka at poczta.fm (=?UTF-8?Q?Micha=C5=82_Pa=C5=82ka?=)
Date: Wed Sep 10 09:45:16 2008
Subject: [Haskell-cafe] Re: Haskell stacktrace
In-Reply-To: 
References: 
	
Message-ID: <1221054429.6207.76.camel@localhost>

I was going to suggest using the -xc option of the GHC runtime (if you
are using GHC), but it seems that it doesn't always give meaningful
results as indicated here:
http://osdir.com/ml/lang.haskell.glasgow.bugs/2006-09/msg00008.html
and here:
http://www.haskell.org/pipermail/glasgow-haskell-users/2006-November/011549.html

You might want to try it anyway. It's documented in the GHC manual:
http://haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html

Other than that, there are also haskell debuggers like hat, but I
haven't used them myself so I can't really tell if they could help here.

Best,
Micha?

On Tue, 2008-09-09 at 22:35 +0200, Pieter Laeremans wrote:
> Woops , I hit the  "send" button to early.
> 
> 
> The java approach to locate the error would be
> 
> 
> try {   ... }catch(Exception e ){ 
> // log error 
> throw new RuntimeException(e);
> }
> 
> 
> ...
> 
> 
> What 's the best equivalent haskell approach ?
> 
> 
> thanks in advance,
> 
> 
> Pieter
> 
> 
> On Tue, Sep 9, 2008 at 10:30 PM, Pieter Laeremans
>  wrote:
>         Hello,
>         
>         
>         I've written a cgi script in haskell, it crashes sometimes
>          with the error message Prelude . tail  : empty list
>         
>         
>         In Java we would use this approach to log the erro 
>         
>         
>         try {
>         
>         
>         } catch (Exception e) {
>         
>         
>         
>         
>         }
>         
>         
>         
>         -- 
>         Pieter Laeremans 
>         
>         "The future is here. It's just not evenly distributed yet." W.
>         Gibson
>         
> 
> 
> 
> -- 
> Pieter Laeremans 
> 
> "The future is here. It's just not evenly distributed yet." W. Gibson
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From droundy at darcs.net  Wed Sep 10 10:08:02 2008
From: droundy at darcs.net (David Roundy)
Date: Wed Sep 10 10:05:29 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <20080910133050.GN3126@brakk.ethz.ch>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<20080909192320.GG3126@brakk.ethz.ch>
	<117f2cc80809100605l54ea9b7fse5019b05853b11c@mail.gmail.com>
	<20080910133050.GN3126@brakk.ethz.ch>
Message-ID: <20080910140801.GP25426@darcs.net>

On Wed, Sep 10, 2008 at 03:30:50PM +0200, Jed Brown wrote:
> On Wed 2008-09-10 09:05, David Roundy wrote:
> > 2008/9/9 Jed Brown :
> > > On Tue 2008-09-09 12:30, Bruce Eckel wrote:
> > >> So this is the kind of problem I keep running into. There will seem to be
> > >> consensus that you can do everything with isolated processes message passing
> > >> (and note here that I include Actors in this scenario even if their mechanism
> > >> is more complex). And then someone will pipe up and say "well, of course, you
> > >> have to have threads" and the argument is usually "for efficiency."
> > >
> > > Some pipe up and say ``you can't do global shared memory because it's
> > > inefficient''.  Ensuring cache coherency with many processors operating
> > > on shared memory is a nightmare and inevitably leads to poor
> > > performance.  Perhaps some optimizations could be done if the programs
> > > were guaranteed to have no mutable state, but that's not realistic.
> > > Almost all high performance machines (think top500) are distributed
> > > memory with very few cores per node.  Parallel programs are normally
> > > written using MPI for communication and they can achieve nearly linear
> > > scaling to 10^5 processors BlueGene/L for scientific problems with
> > > strong global coupling.
> >
> > I should point out, however, that in my experience MPI programming
> > involves deadlocks and synchronization handling that are at least as
> > nasty as any I've run into doing shared-memory threading.
>
> Absolutely, avoiding deadlock is the first priority (before error
> handling).  If you use the non-blocking interface, you have to be very
> conscious of whether a buffer is being used or the call has completed.
> Regardless, the API requires the programmer to maintain a very clear
> distinction between locally owned and remote memory.

Even with the blocking interface, you had subtle bugs that I found
pretty tricky to deal with.  e.g. the reduce functions in lam3 (or was
it lam4) at one point didn't actually manage to result in the same
values on all nodes (with differences caused by roundoff error), which
led to rare deadlocks, when it so happened that two nodes disagreed as
to when a loop was completed.  Perhaps someone made the mistake of
assuming that addition was associative, or maybe it was something
triggered by the non-IEEE floating point we were using.  But in any
case, it was pretty nasty.  And it was precisely the kind of bug that
won't show up except when you're doing something like MPI where you
are pretty much forced to assume that the same (pure!) computation has
the same effect on each node.

> > This isn't an issue, of course, as long as you're letting lapack do
> > all the message passing, but once you've got to deal with message
> > passing between nodes, you've got bugs possible that are strikingly
> > similar to the sorts of nasty bugs present in shared memory threaded
> > code using locks.
>
> Lapack per-se does not do message passing.  I assume you mean whatever
> parallel library you are working with, for instance, PETSc.  Having the
> right abstractions goes a long way.

Right, I meant to say scalapack.  If you've got nice simple
abstractions (which isn't always possible), it doesn't matter if
you're using message passing or shared-memory threading.

> I'm happy to trade the issues with shared mutable state for distributed
> synchronization issues, but that is likely due to it's suitability for
> the problems I'm interested in.  If the data model maps cleanly to
> distributed memory, I think it is easier than coarse-grained shared
> parallelism.  (OpenMP is fine-grained; there is little or no shared
> mutable state and it is very easy.)

Indeed, data-parallel programming is nice and it's easy, but I'm not
sure that it maps well to most problems.  We're fortunate that it does
map well to most scientific problems, but as "normal" programmers are
thinking about parallelizing their code, I don't think data-parallel
is the paradigm that we need to lead them towards.

David
From allbery at ece.cmu.edu  Wed Sep 10 11:49:13 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 10 11:47:12 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <200809101248.35698.g9ks157k@acme.softbase.org>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
	<200809101248.35698.g9ks157k@acme.softbase.org>
Message-ID: <0EDB1F86-FA3E-48C5-A889-FA2928709EA8@ece.cmu.edu>

On 2008 Sep 10, at 6:48, Wolfgang Jeltsch wrote:
> Am Mittwoch, 10. September 2008 11:47 schrieben Sie:
>> So we should think about how to make it less confusing. Perhaps like
>> distributors use an extra revision number we should do the same.
>
> Yes, maybe this is the way to go.


Everyone who manages packages runs into this, and all of them use  
revision numbers like this.  (.rN for gentoo was already mentioned;  
BSD ports and MacPorts use _, RPM uses -.  Depot collections at CMU  
also use -.)

And while we're on that topic, most of them also have an "epoch" which  
overrides the version number.  If for some reason an updated package  
*doesn't* change the version, or goes backwards (because of a major  
bug leading to backing off the new release), you increase the epoch so  
dependent packages don't get confused when it's re-released.  If we're  
considering modifying hackage's versioning, we should probably decide  
if we want/need this now instead of having to add it in later when  
something major goes *boom*.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From allbery at ece.cmu.edu  Wed Sep 10 11:54:43 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 10 11:52:34 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: <782365738.20080910165317@gmail.com>
References: 
	
	
	
	<48C744AF.7020208@freegeek.org> 
	<782365738.20080910165317@gmail.com>
Message-ID: <2F37357B-20DF-4BC9-919F-3414788590C4@ece.cmu.edu>

On 2008 Sep 10, at 8:53, Bulat Ziganshin wrote:
> Wednesday, September 10, 2008, 4:07:41 PM, you wrote:
>> Do you have any reference for that use of infixing
>> constructors by start their name with ':'? That's
>> interesting, and I didn't know about it.
>
> really? ;)
>
> sum (x:xs) = x + sum xs
> sum []     = 0


I think that only counts as the origin of the idea; isn't :-prefixed  
infix constructors a ghc-ism?

http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#infix-tycons

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From jonathanccast at fastmail.fm  Wed Sep 10 11:57:27 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Wed Sep 10 12:00:08 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: <2F37357B-20DF-4BC9-919F-3414788590C4@ece.cmu.edu>
References: 
	
	
	
	<48C744AF.7020208@freegeek.org> 
	<782365738.20080910165317@gmail.com>
	<2F37357B-20DF-4BC9-919F-3414788590C4@ece.cmu.edu>
Message-ID: <1221062247.28475.3.camel@jcchost>

On Wed, 2008-09-10 at 11:54 -0400, Brandon S. Allbery KF8NH wrote:
> On 2008 Sep 10, at 8:53, Bulat Ziganshin wrote:
> > Wednesday, September 10, 2008, 4:07:41 PM, you wrote:
> >> Do you have any reference for that use of infixing
> >> constructors by start their name with ':'? That's
> >> interesting, and I didn't know about it.
> >
> > really? ;)
> >
> > sum (x:xs) = x + sum xs
> > sum []     = 0
> 
> 
> I think that only counts as the origin of the idea; isn't :-prefixed  
> infix constructors a ghc-ism?
> 
> http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#infix-tycons

That link is for type constructors, not data constructors; for data
constructors, go to 

http://haskell.org/onlinereport/lexemes.html

and search for `Operator symbols'.  (The Haskell 98 Report seems to not
have internal anchor tags for hot-linking, unfortunately).

jcc


From dmehrtash at gmail.com  Wed Sep 10 13:26:02 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Wed Sep 10 13:23:50 2008
Subject: [Haskell-cafe] Re: Haskell and Java
In-Reply-To: 
References: 
	
	
Message-ID: 

As people have suggested on this list, in order to write a haskell program
you need to develop a mathematical model which requires some serious up
front thinking.  Writing java code on the other hand is more about "coding"
and then "re-factoring".  'Thinking" is discouraged (agile), as the design
is more about how you organize your objects for the illusive "reuse" and
"future requirements" than anything else.  The approach make sense  if you
consider design as an excersize in object organization as you would have
better idea on the object organization (aka design) as you plow through the
code.

On the other hand if you have a mathematical idea, then a language like java
doesn't give you the abstraction tools necessary to implement it as well as
a language like Haskell.  But if you don't have a model, then java's
approach may be more natural (as is evenident by its popularity)

It seems to me that the two can work side by side if you model your
application in  Service Oriented Architecture.   I think the boundries of
the services should be thought of as langauges rather than api (function
calls).  Two different examples that comes to mind are the SQL and Google
Chart.  A Java programmer doesn't care about the SQL Server implementation,
but it depends on its query langauge to create the tables, populate them,
and issue rather complicated queries on them.     Google Chart is
interesting in that it porvideds a language in a URL to implement a service
that has been traditionally considered as library.  I would think if you can
defines such services in your application then you can define a langaugage
and mathematical model around it to implement the service in Haskell.

Daryoush

On Wed, Sep 10, 2008 at 5:01 AM, Mauricio  wrote:

> At this time It's not really a question
> of better implementation, but cooperation.
> I know Haskell, they know Java, and it
> would be nice if we could share code and
> work. The idea of the api, or maybe dbus,
> seems OK. It just would be easier if we
> could join everything in a single piece,
> but it is no big deal.
>
> Maur?cio
>
> Daryoush Mehrtash a ?crit :
>
>> Why do you want to mix haskall and Java in one VM?  If there are
>> functionality within your code that is better implemented in haskell, then
>> why not  make that into a service (run it as haskell) with some api that
>> Java code can use.
>>
>> Daryoush
>>
>> On Tue, Sep 9, 2008 at 2:36 AM, Maur??cio > briqueabraque@yahoo.com>> wrote:
>>
>>    Hi,
>>
>>    I use Haskell, and my friends at
>>    work use Java. Do you think it
>>    could be a good idea to use Haskell
>>    with Java, so I could understand
>>    and cooperate with them? Is there a
>>    a Haskell to Java compiler that's
>>    already ready to use?
>>
>>    Thanks,
>>    Maur?cio
>>
>>    _______________________________________________
>>    Haskell-Cafe mailing list
>>    Haskell-Cafe@haskell.org 
>>    http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>>
>> --
>> Daryoush
>>
>> Weblog: http://perlustration.blogspot.com/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Daryoush

Weblog: http://perlustration.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/765ac29c/attachment.htm
From duncan.coutts at worc.ox.ac.uk  Wed Sep 10 06:40:20 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Sep 10 14:10:30 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <87myig2tz0.fsf@malde.org>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<1221001157.6076.208.camel@localhost>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>  <87myig2tz0.fsf@malde.org>
Message-ID: <1221043220.5395.1.camel@localhost>

On Wed, 2008-09-10 at 12:09 +0200, Ketil Malde wrote:
> Duncan Coutts  writes:
> 
> > So we should think about how to make it less confusing. Perhaps like
> > distributors use an extra revision number we should do the same. I had
> > hoped that would not be necessary but that's probably not realistic.
> 
> If we go this route, it'd be nice to have a distinguishable syntax,
> like Gentoo's .rN, so that we don't have to remember whether it's
> digit four or five that signifies "administrative" changes.

Yes, it must be distinguished because we cannot constrain the upstream
maintainers version policy. We do not know and should not care how many
version places they use.

Duncan

From ryani.spam at gmail.com  Wed Sep 10 14:28:43 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Wed Sep 10 14:26:31 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <84B2C9FF-06E9-41B3-9146-34B174A9D6DC@mac.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<84B2C9FF-06E9-41B3-9146-34B174A9D6DC@mac.com>
Message-ID: <2f9b2d30809101128v15941fcs2d77fd67f46bca01@mail.gmail.com>

On Wed, Sep 10, 2008 at 2:55 AM, Maarten Hazewinkel
 wrote:
> And a further note on sharing memory via a transactional resource (be it
> STM, a database or a single controlling thread).
> This situation always introduces the possibility that your update fails, and
> a lot of client code is not designed to deal with that. The most common
> pattern I see in database access code is to log the exception and continue
> as if nothing happened. The proper error handling only gets added in after a
> major screwup in production happens, and the usually only the the particular
> part of the code where it went wrong this time.

This seems to be a bit too much F.U.D. for STM.  As long as you avoid
unsafeIOToSTM (which you really should; that function is far more evil
than unsafePerformIO), the only failure case for current Haskell STM
is starvation; some thread will always be making progress and you do
not have to explicitly handle failure.

This is absolutely guaranteed by the semantics of STM: no effects are
visible from a retrying transaction--it just runs again from the
start.  You don't have to write "proper error handling" code for
transactional updates failing.

The only reason why this isn't possible in most database code is that
access to the database is happening concurrently with side effects to
the local program state based on what is read from the database.
Removing the ability to have side effects at that point is what makes
STM great.  It's easy to make side effects happen on commit, though,
just return an IO action that you execute after the atomically block:

> atomicallyWithCommitAction :: STM (IO a) -> IO a
> atomicallyWithCommitAction stm = join (atomically stm)

  -- ryan
From paul at cogito.org.uk  Wed Sep 10 14:59:47 2008
From: paul at cogito.org.uk (Paul Johnson)
Date: Wed Sep 10 14:57:38 2008
Subject: [Haskell-cafe] Haskell stacktrace
In-Reply-To: 
References: 
Message-ID: <48C81923.30409@cogito.org.uk>

Pieter Laeremans wrote:
> Hello,
>
> I've written a cgi script in haskell, it crashes sometimes  with the 
> error message Prelude . tail  : empty list
Yup, been there, done that.

First, look for all the uses of "tail" in your program and think hard 
about all of them.  Wrap them in "assert" or "trace" functions to see if 
there are any clues to be had.

Then take a look at the GHC debugger documentation.  Debuggers for lazy 
languages (or indeed any language with closures) is difficult because 
execution order isn't related to where the faulty data came from.  So if 
I say somewhere

   x = tail ys

and then later on

   print x

the "print" will trigger the error, but the faulty data "ys" may no 
longer be in scope, so you can't see it.
From vss at 73rus.com  Wed Sep 10 15:31:27 2008
From: vss at 73rus.com (Vlad Skvortsov)
Date: Wed Sep 10 15:29:23 2008
Subject: [Haskell-cafe] [Fwd: profiling in haskell]
In-Reply-To: <4683d9370809091225h62d585c6x463f56c956d25add@mail.gmail.com>
References: <48C5BBE0.6060509@73rus.com>
	<4683d9370809091225h62d585c6x463f56c956d25add@mail.gmail.com>
Message-ID: <48C8208F.1030305@73rus.com>

Tim Chevalier wrote:
> 2008/9/8 Vlad Skvortsov :
>   
>> Posting to cafe since I got just one reply on beginner@. I was suggested to
>> include more SCC annotations, but that didn't help. The 'serialize' function
>> is still reported to consume about 32% of running time, 29% inherited.
>> However, functions called from it only account for about 3% of time.
>>
>>     
>
> If "serialize" calls standard library functions, this is probably
> because the profiling libraries weren't built with -auto-all -- so the
> profiling report won't tell you how much time standard library
> functions consume.
>   

Hmm, that's a good point! I didn't think about it. Though how do I make 
GHC link in profiling versions of standard libraries? My own libraries 
are built with profiling support and I run Setup.hs with 
--enable-library-profiling and --enable-executable-profiling options.

> You can rebuild the libraries with -auto-all, but probably much easier
> would be to add SCC annotations to each call site. For example, you
> could annotate your locally defined dumpWith function like so:
>
> dumpWith f = {-# SCC "foldWithKey" #-} Data.Map.foldWithKey f []
>     docToStr k (Doc { docName=n, docVectorLength=vl}) =
>     (:) ("d " ++ show k ++ " " ++ n ++ " " ++ (show vl))
>   

Here is how my current version of the function looks like:

serialize :: Database -> [[String]]
serialize db =
  {-# SCC "XXXCons" #-}
  [
    [dbFormatTag],
    ({-# SCC "dwDoc" #-} dumpWith docToStr dmap),
    ({-# SCC "dwTerm" #-} dumpWith termToStr tmap)
  ]
  where
    (dmap, tmap) = {-# SCC "XXX" #-} db

    dumpWith f =  {-# SCC "dumpWith" #-} Data.Map.foldWithKey f []
        docToStr :: DocId -> Doc -> [String] -> [String]

    docToStr k (Doc { docName=n, docVectorLength=vl}) =
       {-# SCC "docToStr" #-} ((:) ("d " ++ show k ++ " " ++ n ++ " " ++ 
(show vl)))

    termToStr t il =
      {-# SCC "termToStr" #-} ((:) ("t " ++ t ++ " " ++ (foldl 
ilItemToStr "" il)))

    ilItemToStr acc (docid, weight) =
       {-# SCC "ilItemToStr" #-} (show docid ++ ":" ++ show weight ++ " 
" ++ acc)


...and still I don't see these cost centers to take a lot of time (they 
add up to about 3%, as I said before).

> Then your profiling report will tell you how much time/memory that
> particular call to foldWithKey uses.
>
> By the way, using foldl rather than foldl' or foldr is almost always a
> performance bug

Data.Map.foldWith key is implemented with foldr[1], however I'm not sure 
I'm getting how foldr is superior to foldl here (foldl' I understand). 
Could you shed some light on that for me please?

Thanks!

[1]: 
http://www.haskell.org/ghc/docs/latest/html/libraries/containers/src/Data-Map.html

-- 
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com

From catamorphism at gmail.com  Wed Sep 10 15:42:12 2008
From: catamorphism at gmail.com (Tim Chevalier)
Date: Wed Sep 10 15:40:00 2008
Subject: [Haskell-cafe] [Fwd: profiling in haskell]
In-Reply-To: <48C8208F.1030305@73rus.com>
References: <48C5BBE0.6060509@73rus.com>
	<4683d9370809091225h62d585c6x463f56c956d25add@mail.gmail.com>
	<48C8208F.1030305@73rus.com>
Message-ID: <4683d9370809101242o2cec6143i4ea9eae35229d203@mail.gmail.com>

On Wed, Sep 10, 2008 at 12:31 PM, Vlad Skvortsov  wrote:
> Hmm, that's a good point! I didn't think about it. Though how do I make GHC
> link in profiling versions of standard libraries? My own libraries are built
> with profiling support and I run Setup.hs with --enable-library-profiling
> and --enable-executable-profiling options.

When you build your own code with -prof, GHC automatically links in
profiling versions of the standard libraries. However, its profiling
libraries were not built with -auto-all (the reason is that adding
cost centres interferes with optimization). To build the libraries
with -auto-all, you would need to build GHC from sources, which is not
for the faint of heart. However, the results of doing that aren't
usually very enlightening anyway -- for example, foldr might be called
from many different places, but you might only care about a single
call site (and then you can annotate that call site).

Just from looking, I would guess this is the culprit:

>   termToStr t il =
>     {-# SCC "termToStr" #-} ((:) ("t " ++ t ++ " " ++ (foldl ilItemToStr ""
> il)))
>

If you want to be really sure, you can rewrite this as:

 termToStr t il =
     {-# SCC "termToStr" #-} ((:) ("t " ++ t ++ " " ++ ({-# SCC
"termToStr_foldl" #-} foldl ilItemToStr ""
 il)))

and that will give you a cost centre measuring the specific cost of
the invocation of foldl.

> Data.Map.foldWith key is implemented with foldr[1], however I'm not sure I'm
> getting how foldr is superior to foldl here (foldl' I understand). Could you
> shed some light on that for me please?
>

I meant the call to foldl in termToStr. There's a good explanation of this at:
http://en.wikibooks.org/wiki/Haskell/Performance_Introduction
(look for "foldl").

Cheers,
Tim


-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.
From jgoerzen at complete.org  Wed Sep 10 16:09:14 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Wed Sep 10 16:07:14 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
References: 	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>
	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>
Message-ID: <48C8296A.1090501@complete.org>

Sean Leather wrote:
> 
>     How do folks like to package up QuickCheck tests for their
>     libraries?  In the main library?  As a separate repo & package? 
>     Same repo & separate package?  Keeping tests with the tested code
>     allows testing of non-exported functionality, but can add quite a
>     lot of clutter.
> 
> 
> I have QuickCheck properties plus HUnit tests, but I think the question
> is the same. For me, it's in the same repository and shipped with the
> package source. I think that if you ship source (even via Hackage), you
> should also ship tests. So, if somebody wants to modify the source, they
> can run the tests. And making it convenient to test is very important,
> so I have "cabal test" (or "runhaskell Setup.hs test" without
> cabal-install) configured to run the tests. I don't think tests should
> (in general) be part of the user-visible API, so I have them external to
> the module hierarchy.

Do you have a quick-and-easy recipe you could post for making this stuff
work well?  In particular, it would be helpful to have it not install
the test program as well.

I'm not as fluent in the intracacies of Cabal as I ought to be, I'm afraid.

-- John
From jgoerzen at complete.org  Wed Sep 10 16:11:38 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Wed Sep 10 16:09:27 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <8763p5z3o8.fsf@malde.org>
References: 	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>		<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>	
	<8763p5z3o8.fsf@malde.org>
Message-ID: <48C829FA.4090809@complete.org>

Ketil Malde wrote:
> "Conal Elliott"  writes:
> 
>> Thanks a bunch for these tips.  I haven't used the flags feature of cabal
>> before, and i don't seem to be able to get it right. 
> 
> Another option might be to have the test command build via 'ghc
> --make' instead of Cabal - this way, you can avoid mentioning testing
> libraries altogether in the cabal file.

This is the approach I have often taken in the past, but it imposes
somewhat of a maintenance burden because you mus tthen make sure that
the ghc command line flags are kept in-sync what what you're doing in
the cabal file -- -X options, packages used, etc.  This becomes even
more difficult if your cabal file is doing any sort of dynamic
configuration.
From jgoerzen at complete.org  Wed Sep 10 16:15:48 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Wed Sep 10 16:13:37 2008
Subject: [Haskell-cafe] packages and QuickCheck
In-Reply-To: <3c6288ab0809091507t2f8a7f11p3e7df3199db283bf@mail.gmail.com>
References: 	<3c6288ab0809090634w28b0c23cg5d78bd69c255a3fe@mail.gmail.com>	<3c6288ab0809090646l570b2846qfb80cb77d111fa0@mail.gmail.com>		<3c6288ab0809090732h3bea2354x10711f58963169f4@mail.gmail.com>		<9d4d38820809090935s1f8f165dpc5f7dce1d7589dfc@mail.gmail.com>
	<3c6288ab0809091507t2f8a7f11p3e7df3199db283bf@mail.gmail.com>
Message-ID: <48C82AF4.4000007@complete.org>

Sean Leather wrote:
> 
>     My tests are making use of a nice console test runner I wrote that
>     supports both HUnit and QuickCheck (and is extensible to other test
>     providers by the user):
>     http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
> 
> 
> The description looks great! I might have to try it out.
> 
> I used HUnit with QuickCheck 2, so that I could run QC properties as
> HUnit tests. QC2 has the added ability (over QC1) to run a property and
> return a Bool instead of just exiting with an error, and that works
> nicely within HUnit. Does test-framework do something else to support QC
> running side-by-side with HUnit?

See:

http://software.complete.org/static/missingh/doc/MissingH/Test-HUnit-Utils.html

Also some examples at

http://git.complete.org/offlineimap?a=tree;f=testsrc;h=217ee16404384ba2ae3ad01bcdb5696fe495bbdf;hb=refs/heads/v7

see runtests.hs and TestInfrastructure.hs

From simonmarhaskell at gmail.com  Wed Sep 10 17:01:22 2008
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Wed Sep 10 16:59:14 2008
Subject: [Haskell-cafe] Re: Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
Message-ID: <48C835A2.6060104@gmail.com>

Bruce Eckel wrote:
> So this is the kind of problem I keep running into. There will seem to 
> be consensus that you can do everything with isolated processes message 
> passing (and note here that I include Actors in this scenario even if 
> their mechanism is more complex). And then someone will pipe up and say 
> "well, of course, you have to have threads" and the argument is usually 
> "for efficiency."
> 
> I make two observations here which I'd like comments on:
> 
> 1) What good is more efficiency if the majority of programmers can never 
> get it right? My position: if a programmer has to explicitly synchronize 
> anywhere in the program, they'll get it wrong. This of course is a point 
> of contention; I've met a number of people who say "well, I know you 
> don't believe it, but *I* can write successful threaded programs." I 
> used to think that, too. But now I think it's just a learning phase, and 
> you aren't a reliable thread programmer until you say "it's impossible 
> to get right" (yes, a conundrum).

(welcome Bruce!)

Let's back up a bit.  If the goal is just to make something go faster, 
then threads are definitely not the first tool the programmer should be 
looking at, and neither is message passing or STM.  The reason is that 
threads and mutable state inherently introduce non-determinism, and when 
you're just trying to make something go faster non-determinism is almost 
certainly unnecessary (there are problems where non-determinism helps, 
but usually not).

In Haskell, for example, we have par/seq and Strategies which are 
completely determinstic, don't require threads or mutable state, and are 
trivial to use correctly.  Now, getting good speedup is still far from 
trivial, but that's something we're actively working on.  Still, people 
are often able to get a speedup just by using a parMap or something. 
Soon we'll have Data Parallel Haskell too, which also targets the need 
for deterministic parallelism.

We make a clean distinction between Concurrency and Parallelism. 
Concurrency is a _programming paradigm_, wherein threads are used 
typically for dealing with multiple asynchronous events fromm the 
environment, or for structuring your program as a collection of 
interacting agents.  Parallelism, on the other hand, is just about 
making your programs go faster.  You shouldn't need threads to do 
parallelism, because there are no asynchronous stimuli to respond to. 
It just so happens that it's possible to run a concurrent program in 
parallel on a multiprocessor, but that's just a bonus.  I guess the main 
point I'm making is that to make your program go faster, you shouldn't 
have to make it concurrent.  Concurrent programs are hard to get right, 
parallel programs needn't be.

Cheers,
	Simon

> 2) What if you have lots of processors? Does that change the picture 
> any? That is, if you use isolated processes with message passing and you 
> have as many processors as you want, do you still think you need 
> shared-memory threading?
> 
> A comment on the issue of serialization -- note that any time you need 
> to protect shared memory, you use some form of serialization. Even 
> optimistic methods guarantee serialization, even if it happens after the 
> memory is corrupted, by backing up to the uncorrupted state. The effect 
> is the same; only one thread can access the shared state at a time.
> 
> On Tue, Sep 9, 2008 at 4:03 AM, Sebastian Sylvan 
> > wrote:
> 
> 
> 
>     On Mon, Sep 8, 2008 at 8:33 PM, Bruce Eckel      > wrote:
> 
>         As some of you on this list may know, I have struggled to understand
>         concurrency, on and off for many years, but primarily in the C++ and
>         Java domains. As time has passed and experience has stacked up,
>         I have
>         become more convinced that while the world runs in parallel, we
>         think
>         sequentially and so shared-memory concurrency is impossible for
>         programmers to get right -- not only are we unable to think in
>         such a
>         way to solve the problem, the unnatural domain-cutting that
>         happens in
>         shared-memory concurrency always trips you up, especially when the
>         scale increases.
> 
>         I think that the inclusion of threads and locks in Java was just a
>         knee-jerk response to solving the concurrency problem. Indeed, there
>         were subtle threading bugs in the system until Java 5. I personally
>         find the Actor model to be most attractive when talking about
>         threading and objects, but I don't yet know where the limitations of
>         Actors are.
> 
>         However, I keep running across comments where people claim they
>         "must"
>         have shared memory concurrency. It's very hard for me to tell
>         whether
>         this is just because the person knows threads or if there is
>         truth to
>         it. 
> 
>      
>     For correctness, maybe not, for efficiency, yes definitely!
>      
>     Imagine a program where you have a huge set of data that needs to be
>     modified (in some sense) over time by thousands of agents. E.g. a
>     game simulation.
>     Now, also imagine that every agent could *potentially* modify every
>     single piece of data, but that every agent *typically* only touches
>     two or three varibles here and there. I.e. the collisions between
>     the potential read/write sets is 100%, while the collisions for the
>     actual read/write sets is very very low.
>      
>     How would you do this with threads and message passing? Well you
>     could have one big thread owning all of your data that takes
>     "update" messages, and then "updates" the world for you (immutably
>     if you wish, by just replacing its "world" variable with a new one
>     containing your update), but now you've effectively serialized all
>     your interactions with the "world", so you're not really concurrent
>     anymore!
>      
>     So you could decompose the world into multiple threads using some
>     application-specific logical sudivision, but then you're effectively
>     just treating each thread as a mutable variable with an implicit
>     lock (with the risks of deadlock that comes with it - remember we
>     don't know the read/write set in advance - it could be the entire
>     world - so we can't just order our updates in some global way here),
>     so you're really just doing shared mutable state again, and gain
>     little from having threads "simulate" your mutable cells...
>      
>     What you really need for this is some way for each agent to update
>     this shared state *in parallel*, without having to block all other
>     agents pessimistically, but instead only block other agents if there
>     was an *actual* conflict. STM seems to be the only real hope for
>     that sort of thing right now.
>     IMO my list of preferred methods goes like this:
>     1. Purely functional data parallelism
>     2. Purely functional task parallelism (using e.g. strategies)
>     3. Message passing with no (or very minimal) shared state (simulated
>     using threads as "data servers" or otherwise)
>     (3.5. Join patterns? Don't have enough experience with this, but
>     seems sort of nice?)
>     4. Shared state concurrency using STM
>     5. Shared state concurrency using locks
>     6. Lockless programming.
>      
>     So while I wouldn't resort to any shared state concurrency unless
>     there are good reasons for why the other methods don't work well
>     (performance is a good reason!), there are still situations where
>     you need it, and a general purpose language had better supply a way
>     of accessing those kinds of facilities.
>      
>     -- 
>     Sebastian Sylvan
>     +44(0)7857-300802
>     UIN: 44640862
> 
> 
> 
> 
> -- 
> Bruce Eckel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From maarten.hazewinkel at gmail.com  Wed Sep 10 17:06:50 2008
From: maarten.hazewinkel at gmail.com (Maarten Hazewinkel)
Date: Wed Sep 10 17:04:41 2008
Subject: [Haskell-cafe] Can you do everything without shared-memory
	concurrency?
In-Reply-To: <2f9b2d30809101128v15941fcs2d77fd67f46bca01@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<84B2C9FF-06E9-41B3-9146-34B174A9D6DC@mac.com>
	<2f9b2d30809101128v15941fcs2d77fd67f46bca01@mail.gmail.com>
Message-ID: 


On 10 Sep 2008, at 20:28, Ryan Ingram wrote:

> On Wed, Sep 10, 2008 at 2:55 AM, Maarten Hazewinkel
>  wrote:
>> [on transaction failures in databases and STM]
>
> This seems to be a bit too much F.U.D. for STM.  As long as you avoid
> unsafeIOToSTM (which you really should; that function is far more evil
> than unsafePerformIO), the only failure case for current Haskell STM
> is starvation; some thread will always be making progress and you do
> not have to explicitly handle failure.
>
> This is absolutely guaranteed by the semantics of STM: no effects are
> visible from a retrying transaction--it just runs again from the
> start.  You don't have to write "proper error handling" code for
> transactional updates failing.

Thanks for the clarification Ryan.

As a hobbyist I haven't actually used STM, so I was grouping it
with databases as the only transactional system I am directly familiar
with.

I suppose I could have guessed that the Haskell community would come
up with something that's a class better than a normal shared database.


Regards,

Maarten Hazewinkel
From d at vidplace.com  Wed Sep 10 17:20:54 2008
From: d at vidplace.com (David F. Place)
Date: Wed Sep 10 17:19:19 2008
Subject: [Haskell-cafe] Haskell as a scripting language.
Message-ID: <1221081654.9377.14.camel@Congo>

Hi, All.

I needed to make a batch of edits to some input files after a big change
in my program.  Normally, one would choose some scripting language, but
I can't bear to program in them.   The nasty thing about using Haskell
is that giving regexes as string constants sometime requires two levels
of quoting.  For instance. (mkRegex "\\\\\\\\") matches \\.

To get around that, I put the regexes in the head of a literate program
and let the program gobble itself up.  Works great!  I think I'll always
turn to Haskell for my scripting needs now.  

I put the file in the Haskell Pastebin, if you would like to see it.

http://hpaste.org/10249

Cheers, David




From hoknamahn at gmail.com  Wed Sep 10 17:30:28 2008
From: hoknamahn at gmail.com (Olex P)
Date: Wed Sep 10 17:28:17 2008
Subject: [Haskell-cafe] Haskell as a scripting language.
In-Reply-To: <1221081654.9377.14.camel@Congo>
References: <1221081654.9377.14.camel@Congo>
Message-ID: 

Hi guys,

Any ideas how to integrate Haskell into other software as scripting engine?
Similarly to Python in Blender or GIMP or to JavaScript in the products from
Adobe. Which possibilities we have?

Cheers,
Alex.

On Wed, Sep 10, 2008 at 10:20 PM, David F. Place  wrote:

> Hi, All.
>
> I needed to make a batch of edits to some input files after a big change
> in my program.  Normally, one would choose some scripting language, but
> I can't bear to program in them.   The nasty thing about using Haskell
> is that giving regexes as string constants sometime requires two levels
> of quoting.  For instance. (mkRegex "\\\\\\\\") matches \\.
>
> To get around that, I put the regexes in the head of a literate program
> and let the program gobble itself up.  Works great!  I think I'll always
> turn to Haskell for my scripting needs now.
>
> I put the file in the Haskell Pastebin, if you would like to see it.
>
> http://hpaste.org/10249
>
> Cheers, David
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080910/f37878f6/attachment.htm
From brian at brianweb.net  Wed Sep 10 17:35:20 2008
From: brian at brianweb.net (Brian Alliet)
Date: Wed Sep 10 17:33:07 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: <20080910121200.GA6861@gmx.de>
References:  <20080910121200.GA6861@gmx.de>
Message-ID: <20080910213520.GA29811@charger.brianweb.net>

On Wed, Sep 10, 2008 at 02:12:00PM +0200, Marc Weber wrote:
> There used to be.
> http://www.cs.rit.edu/~bja8464/lambdavm/
> (Last darcs change log entry:
> Sun Oct 21 03:05:20 CEST 2007  Brian Alliet 
>   * fix build for hsjava change
> )

Sorry about this. I hit a critical mass of darcs conflicts (I look
forward to giving git a try) around the same time I got really busy at
work. I've been meaning to get back into it (and update it to GHC HEAD)
but I haven't received sufficient nagging yet. Please yell if you're
interested in LambdaVM. At the very least I should be able to help get
whatever is in darcs compiling.

-Brian
From jgoerzen at complete.org  Wed Sep 10 17:57:00 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Wed Sep 10 17:54:49 2008
Subject: [Haskell-cafe] Haskell as a scripting language.
In-Reply-To: <1221081654.9377.14.camel@Congo>
References: <1221081654.9377.14.camel@Congo>
Message-ID: <20080910215700.GA3379@hustlerturf.com>

On Wed, Sep 10, 2008 at 05:20:54PM -0400, David F. Place wrote:
> Hi, All.
> 
> I needed to make a batch of edits to some input files after a big change
> in my program.  Normally, one would choose some scripting language, but
> I can't bear to program in them.   The nasty thing about using Haskell
> is that giving regexes as string constants sometime requires two levels
> of quoting.  For instance. (mkRegex "\\\\\\\\") matches \\.

I've been tempted to write a preprocessor that would accept
Python-like strings, such as r'foo'  (raw, with no backslash
interpolation).  And while we're at it, transform things like

  "Hi there, ${name}!"

into

  "Hi there, " ++ name ++ "!"

A dumb preprocessor should not be all that hard to write, I should
think.

Oh, also the """here docs""" would also be lovely.

> To get around that, I put the regexes in the head of a literate program
> and let the program gobble itself up.  Works great!  I think I'll always
> turn to Haskell for my scripting needs now.  

Whoa, that is sneaky and clever.  But it will fail the minute you try
to run this on a compiled program, because then getProgName will give
you the binary executable.

-- John

From dagit at codersbase.com  Wed Sep 10 17:58:18 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Wed Sep 10 17:56:10 2008
Subject: [Haskell-cafe] Haskell as a scripting language.
In-Reply-To: 
References: <1221081654.9377.14.camel@Congo>
	
Message-ID: 

2008/9/10 Olex P :
> Hi guys,
>
> Any ideas how to integrate Haskell into other software as scripting engine?
> Similarly to Python in Blender or GIMP or to JavaScript in the products from
> Adobe. Which possibilities we have?

This is also very interesting to me.  At my day job we use embedded
python and COM access as the extension languages to a very large
application we produce.  I would love to augment with the embedded
python with an option for haskell "scripts".  I doubt I'd get the go
head with such a change, but it's fun to dream about and propose
regardless.

Jason
From d at vidplace.com  Wed Sep 10 18:07:46 2008
From: d at vidplace.com (David F. Place)
Date: Wed Sep 10 18:06:08 2008
Subject: [Haskell-cafe] Haskell as a scripting language.
In-Reply-To: <20080910215700.GA3379@hustlerturf.com>
References: <1221081654.9377.14.camel@Congo>
	<20080910215700.GA3379@hustlerturf.com>
Message-ID: <1221084466.9377.17.camel@Congo>

On Wed, 2008-09-10 at 16:57 -0500, John Goerzen wrote:
> Whoa, that is sneaky and clever.  But it will fail the minute you try
> to run this on a compiled program, because then getProgName will give
> you the binary executable.

Sooooo, I won't do that.  In addition to getProgName getting the binary,
the compiler would have thrown away the comments.  The point is that
this is a convenient way to write simple scripts.

From duncan.coutts at worc.ox.ac.uk  Wed Sep 10 17:51:29 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Sep 10 18:13:31 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <0EDB1F86-FA3E-48C5-A889-FA2928709EA8@ece.cmu.edu>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
	<200809101248.35698.g9ks157k@acme.softbase.org>
	<0EDB1F86-FA3E-48C5-A889-FA2928709EA8@ece.cmu.edu>
Message-ID: <1221083489.5395.27.camel@localhost>

On Wed, 2008-09-10 at 11:49 -0400, Brandon S. Allbery KF8NH wrote:
> On 2008 Sep 10, at 6:48, Wolfgang Jeltsch wrote:
> > Am Mittwoch, 10. September 2008 11:47 schrieben Sie:
> >> So we should think about how to make it less confusing. Perhaps like
> >> distributors use an extra revision number we should do the same.
> >
> > Yes, maybe this is the way to go.
> 
> 
> Everyone who manages packages runs into this, and all of them use  
> revision numbers like this.  (.rN for gentoo was already mentioned;  
> BSD ports and MacPorts use _, RPM uses -.  Depot collections at CMU  
> also use -.)
> 
> And while we're on that topic, most of them also have an "epoch" which  
> overrides the version number.  If for some reason an updated package  
> *doesn't* change the version, or goes backwards (because of a major  
> bug leading to backing off the new release), you increase the epoch so  
> dependent packages don't get confused when it's re-released.  If we're  
> considering modifying hackage's versioning, we should probably decide  
> if we want/need this now instead of having to add it in later when  
> something major goes *boom*.

We've thought about this and we think we do not need epoch numbers since
we're in the lucky position of doing the upstream versioning.

http://hackage.haskell.org/trac/hackage/ticket/135

Hmm, I think the discussion on that ticket must have been in an email
thread in cabal-devel.

Duncan

From duncan.coutts at worc.ox.ac.uk  Wed Sep 10 18:17:00 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Sep 10 18:13:36 2008
Subject: [Haskell-cafe] Heads Up: code.haskell.org is upgrading to darcs 2
In-Reply-To: 
References: 
	<1218367895.7661.252.camel@localhost>
	
Message-ID: <1221085020.5395.35.camel@localhost>

This email is for darcs users in general and in particular for people
who host a project on code.haskell.org.

What we are doing
=================

We are upgrading /usr/bin/darcs to version 2 on the machine that hosts
code.haskell.org.

That means it will be used by everyone who uses ssh to push or pull from
a darcs repository on code.haskell.org. Pulling via http is completely
unaffected.

Do I have to do anything?
=========================

No. You do not have to change anything.

darcs v2 can talk to darcs v1 clients perfectly well so you do not need
to upgrade your local version of darcs.

You do not need to change the format of your local or server-side
repositories. Darcs v2 works fine with darcs v1 format repositories.

Should I change anything?
=========================

We recommend that you upgrade your local darcs to version 2.

This will allow you to take advantage of substantially faster push/pull
operations over ssh (darcs 2 makes far fewer ssh connections).

As noted above however it is not necessary for you to upgrade or for you
to synchronise your upgrading with anyone else who uses the same
repository.

It is also possible to use a darcs "v1.5" hashed format locally
and continue to use darcs v1 format on the server side. This has some
performance and reliability advantages. Again this is something you can
decide yourself without coordinating with other users of the repository.

If your development style means that you bump into the infamous merging
problems with darcs v1 format then you may consider converting your
repository to the darcs v2 format. Remember that using darcs 2 with
darcs v1 format repositories does not eliminate the merging issue. To
banish the merging problems you have to use the darcs v2 format. This is
however a more substantial change and has to be synchronised between
users of the repository because it involves converting the server side
repository to v2 format and all users getting the repository again. So
if merging is an issue for you then you should discuss it with other
users of your repository.

Is this change safe?
====================

Yes. 

Darcs 2 has a substantial test suite. It has unit tests covering the
core patch operations and also over 100 scripts doing functional
testing, including network tests. The darcs build-bots run all these
tests on all the popular platforms.

Additionally, the code in darcs 2 for handling the v1 format is mostly
the same as in darcs 1, so there are no big risks in using darcs 2 while
continuing to use darcs v1 format repositories. The main change in the
v1 format code is bug fixes, instrumentation code for
debugging/introspection and more cunning types in the patch handling
code that enforces some of the patch invariants.

Furthermore, we have done real world tests using copies of all the 153
repositories on code.haskell.org which comes to around 2GB.

We wanted to verify a couple things:
     1. that using darcs 1 on the client and darcs 2 on the server works
        fine to pull and push patches. This corresponds to a project
        where all the users are still using darcs 1.
     2. that using a mixture of darcs 1 and darcs 2 clients works when
        pushing and pulling patches between the clients via the server.
        This corresponds to a project where some users have upgraded but
        others have not yet.

We tested with darcs 1.0.9 and 2.0.2 in three combinations:
  client darcs 1, server darcs 1
  client darcs 1, server darcs 2
  client darcs 2, server darcs 2

The test consisted of obliterating a significant number of patches from
each repository and pushing them back. In a separate experiment each
repository was converted to darcs v2 format which worked without problem
in every case.

What if I have problems?
========================

Contact support@community.haskell.org. We have made backups of all the
repositories in case there are any critical problems.


Thanks to the darcs hackers Eric Kow and Jason Dagit for doing all the
hard testing work.

Duncan, Ian and Malcolm
(part of the community server admin team)

From allbery at ece.cmu.edu  Wed Sep 10 18:35:03 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 10 18:32:51 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <1221083489.5395.27.camel@localhost>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
	<200809101248.35698.g9ks157k@acme.softbase.org>
	<0EDB1F86-FA3E-48C5-A889-FA2928709EA8@ece.cmu.edu>
	<1221083489.5395.27.camel@localhost>
Message-ID: 

On 2008 Sep 10, at 17:51, Duncan Coutts wrote:
>> dependent packages don't get confused when it's re-released.  If  
>> we're
>> considering modifying hackage's versioning, we should probably decide
>> if we want/need this now instead of having to add it in later when
>> something major goes *boom*.
>
> We've thought about this and we think we do not need epoch numbers  
> since
> we're in the lucky position of doing the upstream versioning.

Are we?  I think the package author has final say if a package needs  
to be backed off, and any packages released between the rollback and  
the next release with dependencies on the backed-off package will be  
problematic, no matter how draconian hackage's version checking is.   
(This is a different situation from datecode versions as in the trac  
ticket.)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From duncan.coutts at worc.ox.ac.uk  Wed Sep 10 18:43:50 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Sep 10 18:39:50 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: 
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
	<200809101248.35698.g9ks157k@acme.softbase.org>
	<0EDB1F86-FA3E-48C5-A889-FA2928709EA8@ece.cmu.edu>
	<1221083489.5395.27.camel@localhost>
	
Message-ID: <1221086630.5395.41.camel@localhost>

On Wed, 2008-09-10 at 18:35 -0400, Brandon S. Allbery KF8NH wrote:
> On 2008 Sep 10, at 17:51, Duncan Coutts wrote:
> >> dependent packages don't get confused when it's re-released.  If  
> >> we're
> >> considering modifying hackage's versioning, we should probably decide
> >> if we want/need this now instead of having to add it in later when
> >> something major goes *boom*.
> >
> > We've thought about this and we think we do not need epoch numbers  
> > since
> > we're in the lucky position of doing the upstream versioning.
> 
> Are we?  I think the package author has final say if a package needs  
> to be backed off, and any packages released between the rollback and  
> the next release with dependencies on the backed-off package will be  
> problematic, no matter how draconian hackage's version checking is.   
> (This is a different situation from datecode versions as in the trac  
> ticket.)

I'm not quite sure I follow. Certainly it's the author/maintainer who
decides the version number. It's up to them to pick it, but they know
the ordering of version numbers.

As I understand it, epochs were mainly introduced to cope with
un-cooperative upstream maintainers whereas here maintainers already
have to specify a version number in the Cabal/Hackage scheme and there's
no way for them to pretend or unilaterally declare that 3 < 2 or any
other such silliness.

To account for having experimental versions available at the same time
as stable versions we're planning to let maintainers add a
suggested/soft version constraint. Is that related to what you mean by
"backing off" and "rollback"?

Duncan

From allbery at ece.cmu.edu  Wed Sep 10 18:53:13 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 10 18:51:02 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <1221086630.5395.41.camel@localhost>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
	<200809101248.35698.g9ks157k@acme.softbase.org>
	<0EDB1F86-FA3E-48C5-A889-FA2928709EA8@ece.cmu.edu>
	<1221083489.5395.27.camel@localhost>
	
	<1221086630.5395.41.camel@localhost>
Message-ID: <655DCA1B-7C0F-4B5F-B800-E04A8C516241@ece.cmu.edu>

On 2008 Sep 10, at 18:43, Duncan Coutts wrote:
> On Wed, 2008-09-10 at 18:35 -0400, Brandon S. Allbery KF8NH wrote:
>> On 2008 Sep 10, at 17:51, Duncan Coutts wrote:
>>>> dependent packages don't get confused when it's re-released.  If
>>>> we're
>>>> considering modifying hackage's versioning, we should probably  
>>>> decide
>>>> if we want/need this now instead of having to add it in later when
>>>> something major goes *boom*.
>>>
>>> We've thought about this and we think we do not need epoch numbers
>>> since
>>> we're in the lucky position of doing the upstream versioning.
>>
>> Are we?  I think the package author has final say if a package needs
>> to be backed off, and any packages released between the rollback and
>> the next release with dependencies on the backed-off package will be
>> problematic, no matter how draconian hackage's version checking is.
>> (This is a different situation from datecode versions as in the trac
>> ticket.)
>
> I'm not quite sure I follow. Certainly it's the author/maintainer who
> decides the version number. It's up to them to pick it, but they know
> the ordering of version numbers.
>
> As I understand it, epochs were mainly introduced to cope with
> un-cooperative upstream maintainers whereas here maintainers already
> have to specify a version number in the Cabal/Hackage scheme and  
> there's

That is one use.  The far more common use, at least in FreeBSD ports,  
is when a version of a port has to be backed off; if any subsequently  
released packages depend on the backed-off version, things get nasty  
when the port is re-updated later.  This may not involve the port  
author; it could be an unexpected interaction with an updated  
dependency under certain circumstances.

"Backed off", in the FreebSD context, means an older version of the  
port is restored from CVS; in the context of Hackage it means removing  
the broken version and making the previous version the current version.

Basically, you *do* have control over this... but it's possible for  
the effects to propagate rather widely before such an interaction is  
discovered, resulting in needing to revise either many packages to  
reflect the corrected dependency... or updating one epoch.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH

From duncan.coutts at worc.ox.ac.uk  Wed Sep 10 19:24:59 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Sep 10 19:20:58 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <655DCA1B-7C0F-4B5F-B800-E04A8C516241@ece.cmu.edu>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<200809101011.39330.g9ks157k@acme.softbase.org>
	<1221040040.6076.286.camel@localhost>
	<200809101248.35698.g9ks157k@acme.softbase.org>
	<0EDB1F86-FA3E-48C5-A889-FA2928709EA8@ece.cmu.edu>
	<1221083489.5395.27.camel@localhost>
	
	<1221086630.5395.41.camel@localhost>
	<655DCA1B-7C0F-4B5F-B800-E04A8C516241@ece.cmu.edu>
Message-ID: <1221089099.5395.44.camel@localhost>

On Wed, 2008-09-10 at 18:53 -0400, Brandon S. Allbery KF8NH wrote:

> > As I understand it, epochs were mainly introduced to cope with
> > un-cooperative upstream maintainers whereas here maintainers already
> > have to specify a version number in the Cabal/Hackage scheme and  
> > there's
> 
> That is one use.  The far more common use, at least in FreeBSD ports,  
> is when a version of a port has to be backed off; if any subsequently  
> released packages depend on the backed-off version, things get nasty  
> when the port is re-updated later.  This may not involve the port  
> author; it could be an unexpected interaction with an updated  
> dependency under certain circumstances.
> 
> "Backed off", in the FreebSD context, means an older version of the  
> port is restored from CVS; in the context of Hackage it means removing  
> the broken version and making the previous version the current version.

Ok, so we never remove packages. So that's ok. You could fix the above
problem in two ways, adjust the suggested version constraint (which is
of course still vapourware) or upload a new version.

(Well, we sometimes remove packages that were uploaded without the
consent of the author. But that does not apply here.)

Duncan

From haskell at list.mightyreason.com  Wed Sep 10 19:37:33 2008
From: haskell at list.mightyreason.com (ChrisK)
Date: Wed Sep 10 19:35:27 2008
Subject: [Haskell-cafe] Re: STM and FFI
In-Reply-To: <8FC37ED1-011A-4565-8DE0-949910F28739@gmail.com>
References: 	<2f9b2d30809090205w28b6252bu337635dabc8c9df@mail.gmail.com>	<48C64383.20801@jellybean.co.uk>	<28012bc60809090255w1500e6e5y507eebfd1fb11614@mail.gmail.com>	<48C648E1.2000706@jellybean.co.uk>	<28012bc60809090308x5946de3bn3b71d3bbe80fa003@mail.gmail.com>
	<8FC37ED1-011A-4565-8DE0-949910F28739@gmail.com>
Message-ID: 

There are some examples of adding IO actions to commit and rollback events at

http://www.haskell.org/haskellwiki/New_monads/MonadAdvSTM

Disclaimer: I wrote this instance of the code, but have not used it much.

Cheers,
   Chris

From ross at soi.city.ac.uk  Wed Sep 10 19:42:11 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Wed Sep 10 19:40:01 2008
Subject: [Haskell-cafe] Hackage policy question
In-Reply-To: <1221041274.6076.290.camel@localhost>
References: <5ab17e790809081626g7e7a5e15lac5fd766087684f2@mail.gmail.com>
	<1221001157.6076.208.camel@localhost>
	<20080910092605.GA3329@soi.city.ac.uk>
	<1221041274.6076.290.camel@localhost>
Message-ID: <20080910234211.GA6560@soi.city.ac.uk>

On Wed, Sep 10, 2008 at 10:07:54AM +0000, Duncan Coutts wrote:
> On Wed, 2008-09-10 at 10:26 +0100, Ross Paterson wrote:
> > So if Debian or Gentoo etc repackage one of these packages in their
> > distributions, what is the pristine tarball that they use?
> 
> They use the one and only pristine tarball. As for what meta-data they
> choose, that's up to them, they have the choice of using the
> original .cabal file in the .tar.gz or taking advantage of the updated
> version.

Since the modified version may contain essential fixes, they'll almost
certainly want that.  And they'll want to keep their mods separate, so
the updated .cabal file becomes another part of the upstream source, with
secondary versioning.  To which they add a third level of versioning for
their distro packaging.  And all this versioning is real; it's keeping
track of significant changes at each stage.

And then there's the psychological effect.  Make it easier to clean up
broken releases afterwards, and you'll have more of them.
From briqueabraque at yahoo.com  Wed Sep 10 20:32:27 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 10 20:30:28 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: <1221062247.28475.3.camel@jcchost>
References: 				<48C744AF.7020208@freegeek.org>
		<782365738.20080910165317@gmail.com>	<2F37357B-20DF-4BC9-919F-3414788590C4@ece.cmu.edu>
	<1221062247.28475.3.camel@jcchost>
Message-ID: 

 >>>> Do you have any reference for that use of infixing
 >>>> constructors by start their name with ':'?
 >>>> (...)

 > (...) for data constructors, go to
 >
 > http://haskell.org/onlinereport/lexemes.html
 >
 > and search for `Operator symbols'. (...)

Here it is:

   ?Operator symbols are formed from one or more
   symbol characters, as defined above, and are
   lexically distinguished into two namespaces
   (Section 1.4):

     * An operator symbol starting with a colon is
       a constructor.(...)?

Cool! What is the syntax for using that in 'data'?
Is it something like ?data X = Y | Int :?& Double??

Maur?cio

From briqueabraque at yahoo.com  Wed Sep 10 20:50:36 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 10 20:48:38 2008
Subject: [Haskell-cafe] Re: Haskell and Java
In-Reply-To: <20080910213520.GA29811@charger.brianweb.net>
References:  <20080910121200.GA6861@gmx.de>
	<20080910213520.GA29811@charger.brianweb.net>
Message-ID: 

>> There used to be.
>> http://www.cs.rit.edu/~bja8464/lambdavm/
>> (Last darcs change log entry:
>> Sun Oct 21 03:05:20 CEST 2007  Brian Alliet 
>>   * fix build for hsjava change
>> )
> 
> Sorry about this. I hit a critical mass of darcs conflicts (I look
> forward to giving git a try) around the same time I got really busy at
> work. I've been meaning to get back into it (and update it to GHC HEAD)
> but I haven't received sufficient nagging yet. Please yell if you're
> interested in LambdaVM. At the very least I should be able to help get
> whatever is in darcs compiling.

Would it allow allow Haskell to also call Java code,
besides running in JVM?

I think I'm not enough to nag you alone. However,
anybody who allows a Haskell programmer to avoid
using other languages can be sure to have brought a
lot of happiness to this sad world. If you can do it,
I don't know how you can resist :)

Best,
Maur?cio

From wren at freegeek.org  Wed Sep 10 21:19:27 2008
From: wren at freegeek.org (wren ng thornton)
Date: Wed Sep 10 21:17:13 2008
Subject: [Haskell-cafe] Re: Haskell and Java
In-Reply-To: 
References: 
	<20080910121200.GA6861@gmx.de>	<20080910213520.GA29811@charger.brianweb.net>
	
Message-ID: <48C8721F.6080706@freegeek.org>

Mauricio wrote:
> > Sorry about this. I hit a critical mass of darcs conflicts (I look
> > forward to giving git a try) around the same time I got really busy at
> > work. I've been meaning to get back into it (and update it to GHC HEAD)
> > but I haven't received sufficient nagging yet. Please yell if you're
> > interested in LambdaVM. At the very least I should be able to help get
> > whatever is in darcs compiling.
> 
> Would it allow allow Haskell to also call Java code,
> besides running in JVM?
> 
> I think I'm not enough to nag you alone.


If you're looking for more people to nag you... I'm working on a 
compiler for a new declarative language. Right now we're using Haskell 
for a proof-of-concept interpreter, though one of the near-term goals 
for the compiler itself is a Java FFI/backend. Since much of the 
language is in the runtime engine, it'd be a shame to have to rewrite it 
all in Java or deal with the horror of JNI.

-- 
Live well,
~wren
From ok at cs.otago.ac.nz  Wed Sep 10 23:24:35 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Wed Sep 10 23:22:29 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: <25758_1221062101_m8AFsxRL028269_2F37357B-20DF-4BC9-919F-3414788590C4@ece.cmu.edu>
References: 
	
	
	
	<48C744AF.7020208@freegeek.org> 
	<782365738.20080910165317@gmail.com>
	<25758_1221062101_m8AFsxRL028269_2F37357B-20DF-4BC9-919F-3414788590C4@ece.cmu.edu>
Message-ID: 


On 11 Sep 2008, at 3:54 am, Brandon S. Allbery KF8NH wrote:
> I think that only counts as the origin of the idea; isn't :-prefixed  
> infix constructors a ghc-ism?

Haskell 98 report, page 10:
"An operator symbol starting with a colon is a constructor".

(I seem to have four copies of the report on my Mac...)




From jonathanccast at fastmail.fm  Wed Sep 10 23:31:42 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Wed Sep 10 23:29:29 2008
Subject: [Haskell-cafe] Re: Field names
In-Reply-To: 
References: 
	
	
	
	<48C744AF.7020208@freegeek.org> 
	<782365738.20080910165317@gmail.com>
	<2F37357B-20DF-4BC9-919F-3414788590C4@ece.cmu.edu>
	<1221062247.28475.3.camel@jcchost>  
Message-ID: <1221103902.6372.0.camel@jonathans-macbook>

On Wed, 2008-09-10 at 21:32 -0300, Mauricio wrote:
> >>>> Do you have any reference for that use of infixing
>  >>>> constructors by start their name with ':'?
>  >>>> (...)
> 
>  > (...) for data constructors, go to
>  >
>  > http://haskell.org/onlinereport/lexemes.html
>  >
>  > and search for `Operator symbols'. (...)
> 
> Here it is:
> 
>    ?Operator symbols are formed from one or more
>    symbol characters, as defined above, and are
>    lexically distinguished into two namespaces
>    (Section 1.4):
> 
>      * An operator symbol starting with a colon is
>        a constructor.(...)?
> 
> Cool! What is the syntax for using that in 'data'?
> Is it something like ?data X = Y | Int :?& Double??

Right.  So then

(:?&) :: Int -> Double -> X

jcc


From lemming at henning-thielemann.de  Thu Sep 11 02:11:08 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu Sep 11 02:09:17 2008
Subject: [Haskell-cafe] Heads Up: code.haskell.org is upgrading to darcs 2
In-Reply-To: <1221085020.5395.35.camel@localhost>
References: 
	<1218367895.7661.252.camel@localhost>
	
	<1221085020.5395.35.camel@localhost>
Message-ID: 


On Wed, 10 Sep 2008, Duncan Coutts wrote:

> Furthermore, we have done real world tests using copies of all the 153
> repositories on code.haskell.org which comes to around 2GB.
>
> We wanted to verify a couple things:
>     1. that using darcs 1 on the client and darcs 2 on the server works
>        fine to pull and push patches. This corresponds to a project
>        where all the users are still using darcs 1.
>     2. that using a mixture of darcs 1 and darcs 2 clients works when
>        pushing and pulling patches between the clients via the server.
>        This corresponds to a project where some users have upgraded but
>        others have not yet.
>
> We tested with darcs 1.0.9 and 2.0.2 in three combinations:
>  client darcs 1, server darcs 1
>  client darcs 1, server darcs 2
>  client darcs 2, server darcs 2
>
> The test consisted of obliterating a significant number of patches from
> each repository and pushing them back. In a separate experiment each
> repository was converted to darcs v2 format which worked without problem
> in every case.

Many thanks for the extensive testing! It's crucial to do that before 
facing code.haskell.org users with this major change.
From eric.kow at gmail.com  Thu Sep 11 03:59:18 2008
From: eric.kow at gmail.com (Eric Y. Kow)
Date: Thu Sep 11 03:57:11 2008
Subject: [Haskell-cafe] Re: [Haskell] Heads Up: code.haskell.org is
	upgrading to darcs 2
In-Reply-To: <1221085020.5395.35.camel@localhost>
References: 
	<1218367895.7661.252.camel@localhost>
	
	<1221085020.5395.35.camel@localhost>
Message-ID: <20080911075918.GH22720@Macintosh.local>

> We are upgrading /usr/bin/darcs to version 2 on the machine that hosts
> code.haskell.org.
> 
> That means it will be used by everyone who uses ssh to push or pull from
> a darcs repository on code.haskell.org. Pulling via http is completely
> unaffected.

Thanks Duncan!  Now my hope is that we can encourage the good folk at
Galois to make a similar upgrade for darcs.haskell.org

-- 
Eric Kow 
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080911/e570f916/attachment.bin
From twd2 at dockerz.net  Thu Sep 11 06:18:30 2008
From: twd2 at dockerz.net (Tim Docker)
Date: Thu Sep 11 06:16:15 2008
Subject: [Haskell-cafe] typeclass question
Message-ID: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>

I have a typeclass related question that I have been puzzling over.

In a library I am working on, I have a series of functions for
converting values to Renderables:

| labelToRenderable :: Label -> Renderable
| legendToRenderable :: Legend -> Renderable
| axisToRenderable :: Axis v -> Renderable
| layoutToRenderable :: Layout x y -> Renderable

These names are overloaded for convenience via a typeclass:

| class ToRenderable a where
|   toRenderable :: a -> Renderable
|
| instance ToRenderable Label where
|   toRenderable = labelToRenderable
| ...

But some recent changes mean that Renderable needs to become a type
constructor, and the functions now product different types:

| labelToRenderable :: Label -> Renderable ()
| legendToRenderable :: Legend -> Renderable String
| axisToRenderable :: Axis v -> Renderable ()
| layoutToRenderable :: Layout x y a -> Renderable a

Is there a nice way to overload a "toRenderable" function for these?
Something like this is possible:

| class ToRenderable a b where
|   toRenderable :: a -> Renderable b

But the above is, I think, too general for my needs. I don't want
to be able to generate Renderables of different type b for a single input
type a.

Also, MPTC take me out of the world of haskell 98, which I was trying
to avoid. Am I missing something simple?

Any pointers would be much appreciated.

Tim


From waldmann at imn.htwk-leipzig.de  Thu Sep 11 06:24:32 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Thu Sep 11 06:24:33 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
Message-ID: <48C8F1E0.2070808@imn.htwk-leipzig.de>


> | class ToRenderable a b where
> |   toRenderable :: a -> Renderable b
> 
> But the above is, I think, too general for my needs. I don't want
> to be able to generate Renderables of different type b for a single input
> type a.

Sounds like a functional dependency (class ToReadable a b | a -> b )

> Also, MPTC take me out of the world of haskell 98, which I was trying
> to avoid. 

Why. "Everyone does it",
and MPTC will be in Haskell-Prime  (but FD may be not)
http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma

J.W.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080911/57b3d245/signature.bin
From lemming at henning-thielemann.de  Thu Sep 11 06:33:36 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu Sep 11 06:31:26 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
Message-ID: 


On Thu, 11 Sep 2008, Tim Docker wrote:

> I have a typeclass related question that I have been puzzling over.
>
> In a library I am working on, I have a series of functions for
> converting values to Renderables:
>
> | labelToRenderable :: Label -> Renderable
> | legendToRenderable :: Legend -> Renderable
> | axisToRenderable :: Axis v -> Renderable
> | layoutToRenderable :: Layout x y -> Renderable
>
> These names are overloaded for convenience via a typeclass:

I think that type classes are not for keystroke reduction, but for writing 
generic algorithms. If there is no algorithm that becomes more generic by 
the use of a type class, I would not use a type class, but stick to 
labelToRenderable and friends.
From twd2 at dockerz.net  Thu Sep 11 06:36:27 2008
From: twd2 at dockerz.net (Tim Docker)
Date: Thu Sep 11 06:34:23 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <48C8F1E0.2070808@imn.htwk-leipzig.de>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
	<48C8F1E0.2070808@imn.htwk-leipzig.de>
Message-ID: <53889.203.185.215.144.1221129387.squirrel@dockerz.net>

>> Also, MPTC take me out of the world of haskell 98, which I was trying
>> to avoid.
>
> Why. "Everyone does it",

Well, it's a library that others might use, so I would prefer to avoid
using language extensions, especially functional deps which I don't
understand, and which seem to have an uncertain future.

Tim

From waldmann at imn.htwk-leipzig.de  Thu Sep 11 06:37:48 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Thu Sep 11 06:37:52 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: 
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
	
Message-ID: <48C8F4FC.1040205@imn.htwk-leipzig.de>

(Henning:)

> If there is no algorithm that becomes more generic by the use of a type
class,
> I would not use a type class, but stick to labelToRenderable [...]

The problem with function names as "labelToRenderable"
is that they have type information as part of the name.

Consistency of that information cannot be enforced by the language,
which makes it dangerous.

If you want type information
(e.g. to resolve overloading, for the compiler - and for the reader!)
use the language, and write a type annotation.

J.W.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080911/e848a480/signature.bin
From waldmann at imn.htwk-leipzig.de  Thu Sep 11 07:23:50 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Thu Sep 11 07:23:50 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <53889.203.185.215.144.1221129387.squirrel@dockerz.net>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
	<48C8F1E0.2070808@imn.htwk-leipzig.de>
	<53889.203.185.215.144.1221129387.squirrel@dockerz.net>
Message-ID: <48C8FFC6.4090106@imn.htwk-leipzig.de>


> Well, it's a library that others might use, so I would prefer to avoid
> using language extensions, especially functional deps which I don't
> understand, and which seem to have an uncertain future.

I think there will be a storm of protest
if support for this simple shape of dependencies ( ... | a -> b )
would be dropped from the major Haskell implementations.

(There used to be some status page on what compiler
supports what extension, anyone know the current location for that?)

J.W.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080911/cd437a37/signature.bin
From briqueabraque at yahoo.com  Thu Sep 11 09:30:20 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Thu Sep 11 09:28:23 2008
Subject: [Haskell-cafe] Re: Haskell and Java
In-Reply-To: <48C8721F.6080706@freegeek.org>
References: 	<20080910121200.GA6861@gmx.de>	<20080910213520.GA29811@charger.brianweb.net>	
	<48C8721F.6080706@freegeek.org>
Message-ID: 

>> > Sorry about this. I hit a critical mass of darcs conflicts (I look
>> > forward to giving git a try) around the same time I got really busy at
>> > work. I've been meaning to get back into it (and update it to GHC HEAD)
>> > but I haven't received sufficient nagging yet. Please yell if you're
>> > interested in LambdaVM. At the very least I should be able to help get
>> > whatever is in darcs compiling.
>>
>> Would it allow allow Haskell to also call Java code,
>> besides running in JVM?
>>
>> I think I'm not enough to nag you alone.
> 
> 
> If you're looking for more people to nag you... I'm working on a 
> compiler for a new declarative language. Right now we're using Haskell 
> for a proof-of-concept interpreter, though one of the near-term goals 
> for the compiler itself is a Java FFI/backend. Since much of the 
> language is in the runtime engine, it'd be a shame to have to rewrite it 
> all in Java or deal with the horror of JNI.
> 

We can use this page, already pointed
on this thread:

http://haskell.org/haskellwiki/Applications_and_libraries/Interfacing_other_languages#Java

We could add something like "if you want something
working regarding the interaction between Haskell
and Java, please nag Brian Alliet at brian@..."

Best,
Maur?cio

From chaddai.fouche at gmail.com  Thu Sep 11 09:36:07 2008
From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=)
Date: Thu Sep 11 09:33:52 2008
Subject: [Haskell-cafe] Haskell as a scripting language.
In-Reply-To: <1221081654.9377.14.camel@Congo>
References: <1221081654.9377.14.camel@Congo>
Message-ID: 

2008/9/10 David F. Place :
> Hi, All.
>
> I needed to make a batch of edits to some input files after a big change
> in my program.  Normally, one would choose some scripting language, but
> I can't bear to program in them.   The nasty thing about using Haskell
> is that giving regexes as string constants sometime requires two levels
> of quoting.  For instance. (mkRegex "\\\\\\\\") matches \\.
>

Since some times in the HEAD and in the future 6.10 release, you can
use quasiquoting to get nice regex syntax as in Perl or Ruby.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexqq

(quasiquoting basically allows you to embed a DSL with significantly
different syntax in your Haskell and still get typechecking and other
advantages at compile-time (though I imagine the errors won't be very
nice).

-- 
Jeda?
From jonathanccast at fastmail.fm  Thu Sep 11 12:03:33 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Thu Sep 11 12:06:19 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <48C8FFC6.4090106@imn.htwk-leipzig.de>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
	<48C8F1E0.2070808@imn.htwk-leipzig.de>
	<53889.203.185.215.144.1221129387.squirrel@dockerz.net>
	<48C8FFC6.4090106@imn.htwk-leipzig.de>
Message-ID: <1221149013.2871.8.camel@jcchost>

On Thu, 2008-09-11 at 13:23 +0200, Johannes Waldmann wrote:
> > Well, it's a library that others might use, so I would prefer to avoid
> > using language extensions, especially functional deps which I don't
> > understand, and which seem to have an uncertain future.
> 
> I think there will be a storm of protest
> if support for this simple shape of dependencies ( ... | a -> b )
> would be dropped from the major Haskell implementations.

For backwards-compatibility reasons, or because you think they're better
than type families?

Personally, I am quite enthusiastic about type families, although that
is influenced by a (somewhat abandoned) project of mine that ended up
with a 3 parameter type class (5 for the sub-class created for
quickCheck support) with one-to-one relations every way.  And multiple
`global' variables implemented with dynamic parameters (they would have
needed to be thread-local, eventually, anyway) with types parameterized
on the afore-mentioned 3 parameters plus two more to allow the choice
between ST and STM.  When you get types like this:

 -- | Wait for another thread to change the buffer contents.
 displayWaitRedisplay :: (Buffer b d mk,
                           ?currentBuffer :: BufferState b d mk STM
TVar,
                           ?currentWindow :: Window b d mk c STM TVar)
                      => b TVar -> STM ()

types like this:

 -- | Wait for another thread to change the buffer contents.
 displayWaitRedisplay :: (Buffer b, ?currentBuffer :: BufferState b STM,
                          ?currentWindow :: Window b c STM)
                      => b TVar -> STM ()
 
look like heaven.

jcc


From waldmann at imn.htwk-leipzig.de  Thu Sep 11 12:34:06 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Thu Sep 11 12:31:58 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <1221149013.2871.8.camel@jcchost>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>	
	<48C8F1E0.2070808@imn.htwk-leipzig.de>	
	<53889.203.185.215.144.1221129387.squirrel@dockerz.net>	
	<48C8FFC6.4090106@imn.htwk-leipzig.de>
	<1221149013.2871.8.camel@jcchost>
Message-ID: <48C9487E.1040007@imn.htwk-leipzig.de>


>> if support for this simple shape of dependencies ( ... | a -> b )  ...

> For backwards-compatibility reasons, 

Yes.

> or because you think they're better than type families?

Don't know (haven't used them).

Concrete example: I have  this "class Partial p i b | p i -> b"
http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/tool/src/Challenger/Partial.hs?rev=1.28

What would type families buy me here?

In my code, this class has tons of instances (I count 80).
How much would I need to change them? Could this be automated?

Thanks - J.W.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080911/3c55c1f7/signature.bin
From jonathanccast at fastmail.fm  Thu Sep 11 12:39:14 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Thu Sep 11 12:41:58 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <48C9487E.1040007@imn.htwk-leipzig.de>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
	<48C8F1E0.2070808@imn.htwk-leipzig.de>
	<53889.203.185.215.144.1221129387.squirrel@dockerz.net>
	<48C8FFC6.4090106@imn.htwk-leipzig.de>
	<1221149013.2871.8.camel@jcchost>
	<48C9487E.1040007@imn.htwk-leipzig.de>
Message-ID: <1221151154.2871.14.camel@jcchost>

On Thu, 2008-09-11 at 18:34 +0200, Johannes Waldmann wrote:
> >> if support for this simple shape of dependencies ( ... | a -> b )  ...
> 
> > For backwards-compatibility reasons, 
> 
> Yes.

This gives point, then, to my concerns about letting Haskell become a
practical language.  At some point, production systems always seem to be
end-of-lifed by backwards compatibility.

> > or because you think they're better than type families?
> 
> Don't know (haven't used them).
> 
> Concrete example: I have  this "class Partial p i b | p i -> b"
> http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/tool/src/Challenger/Partial.hs?rev=1.28
> 
> What would type families buy me here?

I can't figure out what b is.  I could, of course, argue that it would
force you to come up with a name for `b', so people reading the code
could understand what it does.

> In my code, this class has tons of instances (I count 80).
> How much would I need to change them?

   instance Partial p i b where
=> instance Partial p i
     type B p i = b

And type signatures involving Partial would have to change.

>  Could this be automated?

To a certain extent.  Finding the places that need to change could be
automated, which is always the first step :)

jcc


From iavor.diatchki at gmail.com  Thu Sep 11 13:01:50 2008
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu Sep 11 12:59:35 2008
Subject: [Haskell-cafe] typeclass question
In-Reply-To: <53889.203.185.215.144.1221129387.squirrel@dockerz.net>
References: <31751.203.185.215.144.1221128310.squirrel@dockerz.net>
	<48C8F1E0.2070808@imn.htwk-leipzig.de>
	<53889.203.185.215.144.1221129387.squirrel@dockerz.net>
Message-ID: <5ab17e790809111001s3a35c184o67eda7f77b53749@mail.gmail.com>

Hi Tim,
Your example seems like a perfect fit for functional dependencies.

On Thu, Sep 11, 2008 at 3:36 AM, Tim Docker  wrote:
> Well, it's a library that others might use, so I would prefer to avoid
> using language extensions, especially functional deps which I don't
> understand, and which seem to have an uncertain future.

I completely agree with you that it is a good idea to stick to
Haskell'98 when you can, especially in library code, so you'll have to
decide if you really want to use the class.  As for not understanding
functional dependencies, it sounds like you are not giving yourself
enough credit.  Your previous comment basically contains the
definition of a functional dependency:

| But the above is, I think, too general for my needs. I don't want
| to be able to generate Renderables of different type b for a single input
| type a.

This is all there is to a fun. dep., from a programmer's
perspective---it adds a constraint on the instances one can declare
for a given multi-parameter type class.

Hope this helps,
-Iavor
From jeffzaroyko at gmail.com  Thu Sep 11 14:59:44 2008
From: jeffzaroyko at gmail.com (Jeff Zaroyko)
Date: Thu Sep 11 15:02:51 2008
Subject: [Haskell-cafe] Re: Windows details
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
	<48C6C17C.1040000@btinternet.com>
Message-ID: 

Andrew Coppin  btinternet.com> writes:

> 
> Steve Schafer wrote:
> > Version information and application icons are both stored in data
> > structures called "resources"; these are appended to the executable
> > portion of the application, inside the EXE file. 
> >   
> 
> Thanks for your input. I'm now playing with XN Resource Editor. Getting 
> the version information to work correctly appears to be tricky, but 
> everything else seems quite straight forward...
> 

In theory, you should be able to use mingw's windres tool to produce an object
file from the resource definition which you'd link with the rest of your program.

http://www.mingw.org/MinGWiki/index.php/MS resource compiler

From andrewcoppin at btinternet.com  Thu Sep 11 15:24:24 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Thu Sep 11 15:24:15 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: 
References: <48C6AECE.3020905@btinternet.com>	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>	<48C6C17C.1040000@btinternet.com>
	
Message-ID: <48C97068.7010201@btinternet.com>

Jeff Zaroyko wrote:
> In theory, you should be able to use mingw's windres tool to produce an object
> file from the resource definition which you'd link with the rest of your program.
>
> http://www.mingw.org/MinGWiki/index.php/MS resource compiler
>   

Yes, there's a cryptic comment burried away in the GHC manual that says 
GHC itself already uses windres to embed the manifest file into the 
compiled binary file. (And sure enough, if you crawl through with a hex 
editor you'll find the raw XML in there.) There's an option to tell GHC 
to not do this - however, I don't see any option anywhere to tell it to 
embed a *different* resource file instead. And frankly, the linker 
command looks frightening. (For starters, it's 6 pages long. I'm not 
kidding!)

XN Resource Editor makes adding an icon child's play. (Interestingly, 
this also becomes the default window icon without any further action, 
which is nice.) However, either XN nor Resource Hack are able to embedd 
correct version info. And both of them crash quite a lot. (Even more 
interestingly, XN seems to make GHC-compiled binary files dramatically 
*smaller*... huh??)

From brian at brianweb.net  Thu Sep 11 16:04:09 2008
From: brian at brianweb.net (Brian Alliet)
Date: Thu Sep 11 16:01:53 2008
Subject: [Haskell-cafe] Re: Haskell and Java
In-Reply-To: 
References:  <20080910121200.GA6861@gmx.de>
	<20080910213520.GA29811@charger.brianweb.net>
	
Message-ID: <20080911200408.GA59529@charger.brianweb.net>

On Wed, Sep 10, 2008 at 09:50:36PM -0300, Mauricio wrote:
> Would it allow allow Haskell to also call Java code,
> besides running in JVM?

Yep. LambdaVM can fully access existing Java code. The base library
heavily uses FFI to access java.io.* to implement Handle, etc. 'foreign
export' even works so you can call back into Haskell from Java. For
more information see:

http://wiki.brianweb.net/LambdaVM/FFI

-Brian
From andrewcoppin at btinternet.com  Thu Sep 11 16:52:14 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Thu Sep 11 16:49:54 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: <20080910121200.GA6861@gmx.de>
References:  <20080910121200.GA6861@gmx.de>
Message-ID: <48C984FE.9060700@btinternet.com>

Marc Weber wrote:
> There used to be.
> http://www.cs.rit.edu/~bja8464/lambdavm/
>   

My God... so it exists already?

Heh, and to think I was going to try to implement this... ;-)

From jeffzaroyko at gmail.com  Thu Sep 11 17:30:15 2008
From: jeffzaroyko at gmail.com (Jeff Zaroyko)
Date: Thu Sep 11 17:28:05 2008
Subject: [Haskell-cafe] Re: Windows details
References: <48C6AECE.3020905@btinternet.com>	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>	<48C6C17C.1040000@btinternet.com>
	
	<48C97068.7010201@btinternet.com>
Message-ID: 

Andrew Coppin  btinternet.com> writes:

> 
> Jeff Zaroyko wrote:
> > In theory, you should be able to use mingw's windres tool to produce
> > an object file from the resource definition which you'd link with 
> > the rest of your program.
> >
> 
> Yes, there's a cryptic comment burried away in the GHC manual that says 
> GHC itself already uses windres to embed the manifest file into the 
> compiled binary file. (And sure enough, if you crawl through with a hex 
> editor you'll find the raw XML in there.) There's an option to tell GHC 
> to not do this - however, I don't see any option anywhere to tell it to 
> embed a *different* resource file instead. 

All I meant by linking is including the object file when you invoke ghc.

windres foo.rc -o foores.o
ghc bar.hs foo.o

-Jeff

From phercek at gmail.com  Thu Sep 11 17:43:52 2008
From: phercek at gmail.com (Peter Hercek)
Date: Thu Sep 11 17:45:03 2008
Subject: [Haskell-cafe] Re: mailing list choices?
In-Reply-To: 
References: 
Message-ID: 

Did Yahoo & Google groups add support for NNTP yet?
In past this did not work.
If it still does not work then this would be one reason
  to prefer something which works with gmane.

Peter.

From org.haskell.haskell-cafe at pooryorick.com  Thu Sep 11 18:06:22 2008
From: org.haskell.haskell-cafe at pooryorick.com (=?utf-8?Q?Poor=20Yorick?=)
Date: Thu Sep 11 18:04:06 2008
Subject: [Haskell-cafe] compiling ghc-6.8.3: unrecognized command line
	option "-fconfigure-option=" (SOLVED)
Message-ID: <20080911220622.4205.qmail@s461.sureserver.com>

For anyone who might experience the same problem...

Intalling ghc-6.8.3, the following error occurred:

    make -C libraries all
    make[1]: Entering directory `/path/to/src/gh
    c-6.8.3/ghc-6.8.3/libraries'                                                    
    rm -f -f stamp/configure.library.*.base base/unbuildable
    ( cd base && setup/Setup configure \
                        --enable-library-profiling --enable-split-objs \
                       --prefix=/NONEXISTANT \
                       --bindir=/NONEXISTANT \
                       --libdir=/NONEXISTANT \
                       --libsubdir='$pkgid' \
                       --libexecdir=/NONEXISTANT \
                       --datadir=/NONEXISTANT \
                       --docdir=/NONEXISTANT \
                       --htmldir=/NONEXISTANT \
                       --interfacedir=/NONEXISTANT \
                       --with-compiler=../../compiler/stage1/ghc-inplace \
                       --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \
                       --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \
                       --with-ld=/path/to/bin/ld \                                                                              
                       --haddock-options="--use-contents=../index.html \
                                       --use-index=../doc-index.html" \
                          --configure-option='--prefix=/path/to/ghc-6.8.3'
                          --configure-option='CC=gcc -m32'
                          --configure-option='LDFLAGS=-Wl,-rpath,/path/to/lib
                          -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags
                          -L/path/to/lib -L/path/to/lib64
                          --configure-option='
                          --configure-option='CPPFLAGS=-I/path/to/include
                          --configure-option=' \         
                   --configure-option=--with-cc=gcc ) \
              && touch stamp/configure.library.build-profiling-splitting.base
              || touch base/unbuildable                                                         
    Configuring base-3.0.2.0...
    configure: WARNING: Unrecognized options: --with-hc, --with-hc-pkg
    checking for gcc... gcc
    checking for C compiler default output file name... 
    configure: error: C compiler cannot create executables
    See `config.log' for more details.


config.log showed this:


    configure:2171: checking for C compiler default output file name
    configure:2193: gcc  -I/path/to/include  --configure-option= -Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64    --configure-option= conftest.c  >&5
    cc1: error: unrecognized command line option "-fconfigure-option="
    cc1: error: unrecognized command line option "-fconfigure-option="
    configure:2197: $? = 1
    configure:2235: result: 
    configure: failed program was:
    | /* confdefs.h.  */
    | #define PACKAGE_NAME "Haskell base package"
    | #define PACKAGE_TARNAME "base"
    | #define PACKAGE_VERSION "1.0"
    | #define PACKAGE_STRING "Haskell base package 1.0"
    | #define PACKAGE_BUGREPORT "libraries@haskell.org"
    | /* end confdefs.h.  */
    | 
    | int
    | main ()
    | {
    | 
    |   ;
    |   return 0;
    | }
    configure:2242: error: C compiler cannot create executables
    See `config.log' for more details.

    ## ---------------- ##
    ## Cache variables. ##
    ## ---------------- ##

    ac_cv_env_CC_set=set
    ac_cv_env_CC_value='gcc -m32'
    ac_cv_env_CFLAGS_set=
    ac_cv_env_CFLAGS_value=
    ac_cv_env_CPPFLAGS_set=set
    ac_cv_env_CPPFLAGS_value='-I/path/to/include  --configure-option='
    ac_cv_env_CPP_set=
    ac_cv_env_CPP_value=
    ac_cv_env_LDFLAGS_set=set
    ac_cv_env_LDFLAGS_value='-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64    --configure-option='
    ac_cv_env_LIBS_set=
    ac_cv_env_LIBS_value=
    ac_cv_env_build_alias_set=
    ac_cv_env_build_alias_value=
    ac_cv_env_host_alias_set=
    ac_cv_env_host_alias_value=
    ac_cv_env_target_alias_set=
    ac_cv_env_target_alias_value=
    ac_cv_prog_ac_ct_CC=gcc

    ## ----------------- ##
    ## Output variables. ##
    ## ----------------- ##

    CC='gcc'
    CFLAGS=''
    CPP=''
    CPPFLAGS='-I/path/to/include  --configure-option='
    DEFS=''
    ECHO_C=''
    ECHO_N='-n'
    ECHO_T=''
    EGREP=''
    EXEEXT=''
    GREP=''
    LDFLAGS='-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64    --configure-option='
    LIBOBJS=''
    LIBS=''
    LTLIBOBJS=''
    OBJEXT=''
    PACKAGE_BUGREPORT='libraries@haskell.org'
    PACKAGE_NAME='Haskell base package'
    PACKAGE_STRING='Haskell base package 1.0'
    PACKAGE_TARNAME='base'
    PACKAGE_VERSION='1.0'
    PATH_SEPARATOR=':'
    SHELL='/bin/sh'
    ac_ct_CC='gcc'
    bindir='/NONEXISTANT'
    build_alias=''
    datadir='/NONEXISTANT'
    datarootdir='${prefix}/share'
    docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
    dvidir='${docdir}'
    exec_prefix='NONE'
    host_alias=''
    htmldir='${docdir}'
    includedir='${prefix}/include'
    infodir='${datarootdir}/info'
    libdir='/NONEXISTANT'
    libexecdir='/NONEXISTANT'
    localedir='${datarootdir}/locale'
    localstatedir='${prefix}/var'
    mandir='${datarootdir}/man'
    oldincludedir='/usr/include'
    pdfdir='${docdir}'
    prefix='/path/to/ghc-6.8.3'
    program_transform_name='s,x,x,'
    psdir='${docdir}'
    sbindir='${exec_prefix}/sbin'
    sharedstatedir='${prefix}/com'
    sysconfdir='${prefix}/etc'
    target_alias=''

It turned out that trailing whitespace in the LDFLAGS and CPPFLAGS environment variables were causing these problems.  see libraries/Makfile:

    # We rely on all the CONFIGURE_ARGS being quoted with '...', and there
    # being no 's inside the values.
    FLAGGED_CONFIGURE_ARGS = $(subst $(space)',\
                                     $(space)--configure-option=',\
                                     $(space)$(CONFIGURE_ARGS))


--
Yorick
From steve at fenestra.com  Thu Sep 11 18:30:45 2008
From: steve at fenestra.com (Steve Schafer)
Date: Thu Sep 11 18:28:21 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <48C97068.7010201@btinternet.com>
References: <48C6AECE.3020905@btinternet.com>	<68edc4h8f4nh30n7br2gfure7vkh5
	hkfbt@4ax.com>	<48C6C17C.1040000@btinternet.com> 
	<48C97068.7010201@btinternet.com>
Message-ID: 

On Thu, 11 Sep 2008 20:24:24 +0100, you wrote:

>XN Resource Editor makes adding an icon child's play. (Interestingly, 
>this also becomes the default window icon without any further action, 
>which is nice.)

That's how Windows works: If an EXE contains at least one icon, then the
first icon is used by default.

>However, either XN nor Resource Hack are able to embedd correct version
>info.

The VERSIONINFO resource is actually rather complicated internally. In
particular, the value that we think of as the version number (e.g.,
1.2.3.456) is stored in two different formats (binary integer and
string) in at least four different places, depending on how many
languages are supported in the resource (file version as integer,
product version as integer, and one each of file version as string and
product version as string for each language). I don't recall offhand
which one of these is what you see reported in the Properties dialog,
but it's quite possible that you're setting the value of the "wrong"
one, and that's why you're not seeing what you expect.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
From marcot at riseup.net  Thu Sep 11 16:35:04 2008
From: marcot at riseup.net (Marco =?iso-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Thu Sep 11 19:33:23 2008
Subject: [Haskell-cafe] Connecting to wireless network
Message-ID: <20080911203504.GA14831@quindinho.domain.invalid>

Hello,

I've made a small program[0] to connect to a wireless network.  Comments are
welcome.

Greetings.

0: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/n-m

-- 
Marco T?lio Gontijo e Silva
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil
From wnoise at ofb.net  Thu Sep 11 22:17:35 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Thu Sep 11 22:15:36 2008
Subject: [Haskell-cafe] Re: Can you do everything without shared-memory
	concurrency?
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<20080909192320.GG3126@brakk.ethz.ch>
	<117f2cc80809100605l54ea9b7fse5019b05853b11c@mail.gmail.com>
	<20080910133050.GN3126@brakk.ethz.ch>
	<20080910140801.GP25426@darcs.net>
Message-ID: 

On 2008-09-10, David Roundy  wrote:
> On Wed, Sep 10, 2008 at 03:30:50PM +0200, Jed Brown wrote:
>> On Wed 2008-09-10 09:05, David Roundy wrote:
>> > I should point out, however, that in my experience MPI programming
>> > involves deadlocks and synchronization handling that are at least as
>> > nasty as any I've run into doing shared-memory threading.
>>
>> Absolutely, avoiding deadlock is the first priority (before error
>> handling).  If you use the non-blocking interface, you have to be very
>> conscious of whether a buffer is being used or the call has completed.
>> Regardless, the API requires the programmer to maintain a very clear
>> distinction between locally owned and remote memory.
>
> Even with the blocking interface, you had subtle bugs that I found
> pretty tricky to deal with.  e.g. the reduce functions in lam3 (or was
> it lam4) at one point didn't actually manage to result in the same
> values on all nodes (with differences caused by roundoff error), which
> led to rare deadlocks, when it so happened that two nodes disagreed as
> to when a loop was completed.  Perhaps someone made the mistake of
> assuming that addition was associative, or maybe it was something
> triggered by the non-IEEE floating point we were using.  But in any
> case, it was pretty nasty.  And it was precisely the kind of bug that
> won't show up except when you're doing something like MPI where you
> are pretty much forced to assume that the same (pure!) computation has
> the same effect on each node.

Ah, okay.  I think that's a real edge case, and probably not how most
use MPI.  I've used both threads and MPI; MPI, while cumbersome, never
gave me any hard-to-debug deadlock problems.

-- 
Aaron Denney
-><-

From donnie at darthik.com  Fri Sep 12 00:24:00 2008
From: donnie at darthik.com (Donnie Jones)
Date: Fri Sep 12 00:21:46 2008
Subject: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World'
	Program.
Message-ID: 

Hello,

I am trying to test do some OpenGL / GLUT programming in Haskell, but I had
linker issues testing the 'Hello World' OpenGL Haskell program.  I believe
the linker issues were caused because the Haskell GLUT package couldn't find
the GLUT C libraries that were installed with Debian packages.  I have
tested that my OpenGL install does work with 'glxgears'.  Below I have
included the output from building Hello.hs with the linker errors, my Cabal
install of GLUT and OpenGL (which seemed to install fine and the 'configure'
stage of the package installs seem to find the OpenGL and GLUT C-libraries),
and the Debian packages I have installed which provide the C-libraries for
OpenGL and GLUT.

Sorry for the long post, but I wanted to include all relevant information.
Any help would be greatly appreciated.  :)
Thank you.
__
Donnie


### Hello.hs ###
import Graphics.Rendering.OpenGL
import Graphics.UI.GLUT
main = do
  (progname, _) <- getArgsAndInitialize
  createWindow "Hello World"
  mainLoop
###########

### Build of Haskell OpenGL / GLUT "Hello World" program, linking fails ###
ghc --make Hello1.hs
[1 of 1] Compiling Main             ( Hello1.hs, Hello1.o )
Linking Hello1 ...
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Begin.o):
In function `sAlI_info':
(.text+0x1d3): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Begin.o):
In function `sAxK_info':
(.text+0x84f): undefined reference to `glutMainLoop'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Global.o):
In function `szMM_info':
(.text+0xd): undefined reference to `glutMenuStatusFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Global.o):
In function `szNf_info':
(.text+0x4d): undefined reference to `glutIdleFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Global.o):
In function `szUK_info':
(.text+0x6ac): undefined reference to `glutTimerFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `sshz_info':
(.text+0x549): undefined reference to `glutEntryFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ssi2_info':
(.text+0x589): undefined reference to `glutVisibilityFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ssiv_info':
(.text+0x5c9): undefined reference to `glutPassiveMotionFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ssiY_info':
(.text+0x609): undefined reference to `glutMotionFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ssjr_info':
(.text+0x649): undefined reference to `glutReshapeFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ssjU_info':
(.text+0x689): undefined reference to `glutOverlayDisplayFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `sskn_info':
(.text+0x6c9): undefined reference to `glutDisplayFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stBW_info':
(.text+0x4f95): undefined reference to `glutKeyboardFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stCp_info':
(.text+0x4fd5): undefined reference to `glutKeyboardUpFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stGi_info':
(.text+0x52e1): undefined reference to `glutSpecialFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stGL_info':
(.text+0x5321): undefined reference to `glutSpecialUpFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stJk_info':
(.text+0x5515): undefined reference to `glutMouseFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stQq_info':
(.text+0x5a91): undefined reference to `glutSpaceballMotionFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stRv_info':
(.text+0x5b31): undefined reference to `glutSpaceballRotateFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stTt_info':
(.text+0x5cad): undefined reference to `glutSpaceballButtonFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stYd_info':
(.text+0x6121): undefined reference to `glutButtonBoxFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `stZi_info':
(.text+0x61c5): undefined reference to `glutDialsFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `su3u_info':
(.text+0x6589): undefined reference to `glutTabletMotionFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `su6w_info':
(.text+0x680d): undefined reference to `glutTabletButtonFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `sudL_info':
(.text+0x6ea1): undefined reference to `glutJoystickFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ss3L_info':
(.text+0xfca5): undefined reference to `glutGetModifiers'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ss4i_info':
(.text+0xfda5): undefined reference to `glutGetModifiers'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ss4Q_info':
(.text+0xfea5): undefined reference to `glutGetModifiers'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ss5o_info':
(.text+0xffa5): undefined reference to `glutGetModifiers'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `ss5Y_info':
(.text+0x100a5): undefined reference to `glutGetModifiers'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Colormap.o):
In function `snyp_info':
(.text+0x50): undefined reference to `glutSetColor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Colormap.o):
In function `snyr_info':
(.text+0x1ac): undefined reference to `glutGetColor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Colormap.o):
In function `snyr_info':
(.text+0x1d6): undefined reference to `glutGetColor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Colormap.o):
In function `snyr_info':
(.text+0x200): undefined reference to `glutGetColor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Colormap.o):
In function `snwY_info':
(.text+0x313): undefined reference to `glutLayerGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Colormap.o):
In function `snwY_info':
(.text+0x353): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Colormap.o):
In function `snCI_info':
(.text+0x41d): undefined reference to `glutCopyColormap'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smEq_info':
(.text+0x19): undefined reference to `glutIgnoreKeyRepeat'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smEq_info':
(.text+0x2f): undefined reference to `glutIgnoreKeyRepeat'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smF1_info':
(.text+0x7a): undefined reference to `glutSetKeyRepeat'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smF1_info':
(.text+0x93): undefined reference to `glutSetKeyRepeat'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smF1_info':
(.text+0xb1): undefined reference to `glutSetKeyRepeat'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smzT_info':
(.text+0x1fb): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smA6_info':
(.text+0x27b): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(DeviceControl.o):
In function `smA6_info':
(.text+0x479): undefined reference to `glutForceJoystickFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Fonts.o):
In function `slEn_info':
(.text+0x519): undefined reference to `glutStrokeCharacter'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Fonts.o):
In function `slFU_info':
(.text+0x609): undefined reference to `glutStrokeLength'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Fonts.o):
In function `slIT_info':
(.text+0x8fc): undefined reference to `glutBitmapCharacter'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Fonts.o):
In function `slL0_info':
(.text+0xa25): undefined reference to `glutBitmapLength'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siGD_info':
(.text+0x278): undefined reference to `glutGameModeGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siGD_info':
(.text+0x2bb): undefined reference to `glutGameModeGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siGD_info':
(.text+0x2e7): undefined reference to `glutGameModeGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siGD_info':
(.text+0x2f9): undefined reference to `glutGameModeGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siGD_info':
(.text+0x30b): undefined reference to `glutGameModeGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):(.text+0x31d):
more undefined references to `glutGameModeGet' follow
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siHQ_info':
(.text+0x3ed): undefined reference to `glutEnterGameMode'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siHQ_info':
(.text+0x3fc): undefined reference to `glutGameModeGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `sjqd_info':
(.text+0x13c5): undefined reference to `glutGameModeString'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(GameMode.o):
In function `siNC_info':
(.text+0x2131): undefined reference to `glutLeaveGameMode'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):(.text+0x15):
undefined reference to `glutInitWindowSize'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):(.text+0x3d):
undefined reference to `glutInitWindowPosition'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sfcH_info':
(.text+0x24f): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sfdf_info':
(.text+0x45b): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sfdf_info':
(.text+0x49b): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sfdf_info':
(.text+0x4ad): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sfdf_info':
(.text+0x50f): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):(.text+0x521):
more undefined references to `glutGet' follow
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sfiu_info':
(.text+0x2f40): undefined reference to `glutInitDisplayMode'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sgtU_info':
(.text+0x2fc1): undefined reference to `glutInitDisplayString'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Initialization.o):
In function `sfwB_info':
(.text+0x63e1): undefined reference to `glutInit'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syIX_info':
(.text+0xdf): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `ryuS_info':
(.text+0x173): undefined reference to `glutRemoveMenuItem'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syRu_info':
(.text+0x6e1): undefined reference to `glutAddMenuEntry'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syRj_info':
(.text+0x7b9): undefined reference to `glutAddSubMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syzf_info':
(.text+0x83b): undefined reference to `glutRemoveMenuItem'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syRh_info':
(.text+0x951): undefined reference to `glutSetMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syRf_info':
(.text+0x9b2): undefined reference to `glutGetMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syRQ_info':
(.text+0xd7d): undefined reference to `glutDestroyMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syRN_info':
(.text+0xe49): undefined reference to `glutCreateMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `szk6_info':
(.text+0x1a86): undefined reference to `glutAttachMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `szk6_info':
(.text+0x1a9f): undefined reference to `glutAttachMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `szk6_info':
(.text+0x1ab8): undefined reference to `glutAttachMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `szk6_info':
(.text+0x1ad1): undefined reference to `glutAttachMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `szk6_info':
(.text+0x1aea): undefined reference to `glutAttachMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `syHN_info':
(.text+0x1d54): undefined reference to `glutDetachMenu'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Menu.o):
In function `szjX_info':
(.text+0x1e79): undefined reference to `glutGetWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiR_info':
(.text+0xe39): undefined reference to `glutSolidDodecahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiP_info':
(.text+0xe55): undefined reference to `glutWireDodecahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiN_info':
(.text+0xe71): undefined reference to `glutWireIcosahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiL_info':
(.text+0xe8d): undefined reference to `glutSolidIcosahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiJ_info':
(.text+0xea9): undefined reference to `glutSolidOctahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiH_info':
(.text+0xec5): undefined reference to `glutWireOctahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiF_info':
(.text+0xee1): undefined reference to `glutWireTetrahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `raiD_info':
(.text+0xefd): undefined reference to `glutSolidTetrahedron'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdiu_info':
(.text+0x5026): undefined reference to `glutSolidCube'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdir_info':
(.text+0x50c6): undefined reference to `glutSolidSphere'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdim_info':
(.text+0x51e7): undefined reference to `glutSolidCone'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdi9_info':
(.text+0x54cf): undefined reference to `glutSolidTorus'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdi3_info':
(.text+0x5622): undefined reference to `glutSolidTeapot'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdhV_info':
(.text+0x58fe): undefined reference to `glutWireCube'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdhS_info':
(.text+0x599e): undefined reference to `glutWireSphere'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdhN_info':
(.text+0x5abf): undefined reference to `glutWireCone'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdhA_info':
(.text+0x5da7): undefined reference to `glutWireTorus'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Objects.o):
In function `sdhu_info':
(.text+0x5efa): undefined reference to `glutWireTeapot'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8A7_info':
(.text+0x61): undefined reference to `glutUseLayer'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8A7_info':
(.text+0xcf): undefined reference to `glutUseLayer'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8ws_info':
(.text+0x227): undefined reference to `glutLayerGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8D9_info':
(.text+0x2ac): undefined reference to `glutPostWindowOverlayRedisplay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8D8_info':
(.text+0x326): undefined reference to `glutPostOverlayRedisplay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8x0_info':
(.text+0x3ff): undefined reference to `glutLayerGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8FF_info':
(.text+0x482): undefined reference to `glutRemoveOverlay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8FF_info':
(.text+0x4e7): undefined reference to `glutEstablishOverlay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8xt_info':
(.text+0x5a7): undefined reference to `glutLayerGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8HX_info':
(.text+0x62a): undefined reference to `glutHideOverlay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Overlay.o):
In function `s8HX_info':
(.text+0x68f): undefined reference to `glutShowOverlay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9EB_info':
(.text+0x49): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9EB_info':
(.text+0x8f): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9EB_info':
(.text+0xa1): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9EB_info':
(.text+0xb3): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9EB_info':
(.text+0x12b): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):(.text+0x16b):
more undefined references to `glutDeviceGet' follow
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9EB_info':
(.text+0x363): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9EB_info':
(.text+0x3a3): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9L1_info':
(.text+0xb93): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9yO_info':
(.text+0xcbb): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9z1_info':
(.text+0xd3b): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9ze_info':
(.text+0xdbb): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9zr_info':
(.text+0xe3b): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9zr_info':
(.text+0xe7b): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9zr_info':
(.text+0xe8d): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):(.text+0xeef):
more undefined references to `glutGet' follow
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(State.o):
In function `s9CY_info':
(.text+0x12b8): undefined reference to `glutLayerGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):(.text+0x15):
undefined reference to `glutWarpPointer'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):(.text+0x3d):
undefined reference to `glutReshapeWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):(.text+0x65):
undefined reference to `glutPositionWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):(.text+0xc5):
undefined reference to `glutCreateSubWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5kf_info':
(.text+0x10a): undefined reference to `glutSetCursor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5kf_info':
(.text+0x123): undefined reference to `glutSetCursor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5kf_info':
(.text+0x13c): undefined reference to `glutSetCursor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5kf_info':
(.text+0x155): undefined reference to `glutSetCursor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5kf_info':
(.text+0x16e): undefined reference to `glutSetCursor'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):(.text+0x187):
more undefined references to `glutSetCursor' follow
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s56X_info':
(.text+0x6eb): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s56X_info':
(.text+0x72b): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s56X_info':
(.text+0x73d): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s56X_info':
(.text+0x79f): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s56X_info':
(.text+0x7b1): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5p7_info':
(.text+0x805): undefined reference to `glutSetWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s58d_info':
(.text+0x8e5): undefined reference to `glutGetWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5qr_info':
(.text+0x915): undefined reference to `glutPostWindowRedisplay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5qq_info':
(.text+0x93b): undefined reference to `glutPostRedisplay'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s59A_info':
(.text+0xbc7): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s59A_info':
(.text+0xc07): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5vb_info':
(.text+0xc3f): undefined reference to `glutShowWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5vb_info':
(.text+0xc4f): undefined reference to `glutIconifyWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5vb_info':
(.text+0xc64): undefined reference to `glutHideWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5Lh_info':
(.text+0x190d): undefined reference to `glutCreateWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5Mh_info':
(.text+0x19a5): undefined reference to `glutDestroyWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5Mh_info':
(.text+0x19e5): undefined reference to `glutSwapBuffers'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5Mh_info':
(.text+0x1a01): undefined reference to `glutFullScreen'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5Mh_info':
(.text+0x1a1d): undefined reference to `glutPushWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5Mh_info':
(.text+0x1a39): undefined reference to `glutPopWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5NA_info':
(.text+0x1a55): undefined reference to `glutSetWindowTitle'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Window.o):
In function `s5Oy_info':
(.text+0x1add): undefined reference to `glutSetIconTitle'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Registration.o):
In function `s7aX_info':
(.text+0x2dd): undefined reference to `glutGetWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Registration.o):
In function `s7xG_info':
(.text+0x7c3): undefined reference to `glutTimerFunc'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(Registration.o):
In function `s7lI_info':
(.text+0x1ec0): undefined reference to `glutGetWindow'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(QueryUtils.o):
In function `s1cg_info':
(.text+0x61): undefined reference to `glutDeviceGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(QueryUtils.o):
In function `s1d7_info':
(.text+0x121): undefined reference to `glutLayerGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(QueryUtils.o):
In function `s1dY_info':
(.text+0x1e1): undefined reference to `glutGet'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(HsGLUT.o):
In function `hs_GLUT_marshalBitmapFont':
HsGLUT.c:(.text+0x15): undefined reference to `glutBitmap8By13'
HsGLUT.c:(.text+0x24): undefined reference to `glutBitmapHelvetica18'
HsGLUT.c:(.text+0x2b): undefined reference to `glutBitmap9By15'
HsGLUT.c:(.text+0x32): undefined reference to `glutBitmapTimesRoman10'
HsGLUT.c:(.text+0x39): undefined reference to `glutBitmapTimesRoman24'
HsGLUT.c:(.text+0x40): undefined reference to `glutBitmapHelvetica10'
HsGLUT.c:(.text+0x47): undefined reference to `glutBitmapHelvetica12'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(HsGLUT.o):
In function `hs_GLUT_marshalStrokeFont':
HsGLUT.c:(.text+0x52): undefined reference to `glutStrokeRoman'
HsGLUT.c:(.text+0x6b): undefined reference to `glutStrokeMonoRoman'
/home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2/libHSGLUT-2.1.1.2.a(HsGLUT.o):
In function `hs_GLUT_getProcAddress':
HsGLUT.c:(.text+0x85): undefined reference to `glutGetProcAddress'
collect2: ld returned 1 exit status
### Build of Haskell OpenGL / GLUT "Hello World" program, linking fails ###

### ghc-pkg list ###
ghc-pkg list
/usr/lib/ghc-6.8.2/package.conf:
    Cabal-1.3.12, HTTP-3001.0.4, array-0.1.0.0, base-3.0.1.0,
    bytestring-0.9.0.1, containers-0.1.0.1, directory-1.0.0.0,
    filepath-1.1.0.0, {ghc-6.8.2}, haskell98-1.0.1.0, hpc-0.5.0.0,
    mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0,
    packedstring-0.1.0.0, parsec-3.0.0, pretty-1.0.0.0,
    process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, rts-1.0,
    template-haskell-2.2.0.0, unix-2.3.0.0, zlib-0.4.0.4
/home/donnie/.ghc/i386-linux-6.8.2/package.conf:
    GLUT-2.1.1.2, OpenGL-2.2.1.1, bytestring-0.9.1.2, cgi-3001.1.5.2,
    cgi-3001.1.6.0, hpc-0.5.0.1, mtl-1.1.0.1, network-2.2.0.0,
    parsec-3.0.0, regex-base-0.93.1, regex-posix-0.93.1,
    regex-posix-0.93.2, xhtml-3000.1.0.0, xhtml-3000.2.0.0, xml-1.2.6,
    xml-1.3.1
#############

### Cabal install of GLUT ###
cabal install glut
Resolving dependencies...
Downloading OpenGL-2.2.1.1...
Configuring OpenGL-2.2.1.1...
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for Windows environment... no
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for atan... no
checking for atan in -lm... yes
checking for GL library... -lGL -lm
checking for GLU library... -lGLU -lGL -lm
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking OpenGL/gl.h usability... no
checking OpenGL/gl.h presence... no
checking for OpenGL/gl.h... no
checking GL/glu.h usability... yes
checking GL/glu.h presence... yes
checking for GL/glu.h... yes
checking OpenGL/glu.h usability... no
checking OpenGL/glu.h presence... no
checking for OpenGL/glu.h... no
checking Haskell type for GLboolean... Word8
checking Haskell type for GLbyte... Int8
checking Haskell type for GLubyte... Word8
checking Haskell type for GLshort... Int16
checking Haskell type for GLushort... Word16
checking Haskell type for GLint... Int32
checking Haskell type for GLuint... Word32
checking Haskell type for GLsizei... Int32
checking Haskell type for GLenum... Word32
checking Haskell type for GLbitfield... Word32
checking Haskell type for GLfloat... Float
checking Haskell type for GLclampf... Float
checking Haskell type for GLdouble... Double
checking Haskell type for GLclampd... Double
checking Haskell type for GLchar... Int8
checking Haskell type for GLintptr... Int32
checking Haskell type for GLsizeiptr... Int32
configure: creating ./config.status
config.status: creating config.mk
config.status: creating OpenGL.buildinfo
config.status: creating include/HsOpenGLConfig.h
config.status: creating include/HsOpenGL.h
config.status: include/HsOpenGL.h is unchanged
Preprocessing library OpenGL-2.2.1.1...
Building OpenGL-2.2.1.1...
[ 1 of 84] Compiling Graphics.Rendering.OpenGL.GL.PeekPoke (
Graphics/Rendering/OpenGL/GL/PeekPoke.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PeekPoke.o )
[ 2 of 84] Compiling Graphics.Rendering.OpenGL.GL.IOState (
Graphics/Rendering/OpenGL/GL/IOState.hs,
dist/build/Graphics/Rendering/OpenGL/GL/IOState.o )
[ 3 of 84] Compiling Graphics.Rendering.OpenGL.GL.GLboolean (
Graphics/Rendering/OpenGL/GL/GLboolean.hs,
dist/build/Graphics/Rendering/OpenGL/GL/GLboolean.o )
[ 4 of 84] Compiling Graphics.Rendering.OpenGL.GL.Extensions (
Graphics/Rendering/OpenGL/GL/Extensions.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Extensions.o )
[ 5 of 84] Compiling Graphics.Rendering.OpenGL.GL.Exception (
Graphics/Rendering/OpenGL/GL/Exception.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Exception.o )
[ 6 of 84] Compiling Graphics.Rendering.OpenGL.GL.StateVar (
Graphics/Rendering/OpenGL/GL/StateVar.hs,
dist/build/Graphics/Rendering/OpenGL/GL/StateVar.o )
[ 7 of 84] Compiling Graphics.Rendering.OpenGL.GL.FlushFinish (
Graphics/Rendering/OpenGL/GL/FlushFinish.hs,
dist/build/Graphics/Rendering/OpenGL/GL/FlushFinish.o )
[ 8 of 84] Compiling Graphics.Rendering.OpenGL.GL.BasicTypes (
Graphics/Rendering/OpenGL/GL/BasicTypes.hs,
dist/build/Graphics/Rendering/OpenGL/GL/BasicTypes.o )
[ 9 of 84] Compiling Graphics.Rendering.OpenGL.GL.SavingState (
Graphics/Rendering/OpenGL/GL/SavingState.hs,
dist/build/Graphics/Rendering/OpenGL/GL/SavingState.o )
[10 of 84] Compiling Graphics.Rendering.OpenGL.GL.StringQueries (
Graphics/Rendering/OpenGL/GL/StringQueries.hs,
dist/build/Graphics/Rendering/OpenGL/GL/StringQueries.o )
[11 of 84] Compiling Graphics.Rendering.OpenGL.GLU.Initialization (
Graphics/Rendering/OpenGL/GLU/Initialization.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/Initialization.o )
[12 of 84] Compiling Graphics.Rendering.OpenGL.GL.BlendingFactor (
Graphics/Rendering/OpenGL/GL/BlendingFactor.hs,
dist/build/Graphics/Rendering/OpenGL/GL/BlendingFactor.o )
[13 of 84] Compiling Graphics.Rendering.OpenGL.GL.BufferMode (
Graphics/Rendering/OpenGL/GL/BufferMode.hs,
dist/build/Graphics/Rendering/OpenGL/GL/BufferMode.o )
[14 of 84] Compiling Graphics.Rendering.OpenGL.GL.ComparisonFunction (
Graphics/Rendering/OpenGL/GL/ComparisonFunction.hs,
dist/build/Graphics/Rendering/OpenGL/GL/ComparisonFunction.o )
[15 of 84] Compiling Graphics.Rendering.OpenGL.GL.DataType (
Graphics/Rendering/OpenGL/GL/DataType.hs,
dist/build/Graphics/Rendering/OpenGL/GL/DataType.o )
[16 of 84] Compiling Graphics.Rendering.OpenGL.GL.EdgeFlag (
Graphics/Rendering/OpenGL/GL/EdgeFlag.hs,
dist/build/Graphics/Rendering/OpenGL/GL/EdgeFlag.o )
[17 of 84] Compiling Graphics.Rendering.OpenGL.GL.Face (
Graphics/Rendering/OpenGL/GL/Face.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Face.o )
[18 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelFormat (
Graphics/Rendering/OpenGL/GL/PixelFormat.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelFormat.o )
[19 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelData (
Graphics/Rendering/OpenGL/GL/PixelData.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelData.o )
[20 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles.Reset (
Graphics/Rendering/OpenGL/GL/PixelRectangles/Reset.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/Reset.o )
[21 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles.Sink (
Graphics/Rendering/OpenGL/GL/PixelRectangles/Sink.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/Sink.o )
[22 of 84] Compiling Graphics.Rendering.OpenGL.GL.PointParameter (
Graphics/Rendering/OpenGL/GL/PointParameter.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PointParameter.o )
[23 of 84] Compiling Graphics.Rendering.OpenGL.GL.PolygonMode (
Graphics/Rendering/OpenGL/GL/PolygonMode.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PolygonMode.o )
[24 of 84] Compiling Graphics.Rendering.OpenGL.GL.PrimitiveMode (
Graphics/Rendering/OpenGL/GL/PrimitiveMode.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PrimitiveMode.o )
[25 of 84] Compiling
Graphics.Rendering.OpenGL.GL.Texturing.PixelInternalFormat (
Graphics/Rendering/OpenGL/GL/Texturing/PixelInternalFormat.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/PixelInternalFormat.o )
[26 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.TextureUnit (
Graphics/Rendering/OpenGL/GL/Texturing/TextureUnit.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/TextureUnit.o )
[27 of 84] Compiling Graphics.Rendering.OpenGL.GLU.ErrorsInternal (
Graphics/Rendering/OpenGL/GLU/ErrorsInternal.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/ErrorsInternal.o )
[28 of 84] Compiling Graphics.Rendering.OpenGL.GLU.Errors (
Graphics/Rendering/OpenGL/GLU/Errors.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/Errors.o )
[29 of 84] Compiling Graphics.Rendering.OpenGL.GL.QueryUtils (
Graphics/Rendering/OpenGL/GL/QueryUtils.hs,
dist/build/Graphics/Rendering/OpenGL/GL/QueryUtils.o )
[30 of 84] Compiling Graphics.Rendering.OpenGL.GL.BeginEnd (
Graphics/Rendering/OpenGL/GL/BeginEnd.hs,
dist/build/Graphics/Rendering/OpenGL/GL/BeginEnd.o )
[31 of 84] Compiling Graphics.Rendering.OpenGL.GL.Hints (
Graphics/Rendering/OpenGL/GL/Hints.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Hints.o )
[32 of 84] Compiling
Graphics.Rendering.OpenGL.GL.PixelRectangles.PixelStorage (
Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelStorage.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelStorage.o )
[33 of 84] Compiling Graphics.Rendering.OpenGL.GL.VertexSpec (
Graphics/Rendering/OpenGL/GL/VertexSpec.hs,
dist/build/Graphics/Rendering/OpenGL/GL/VertexSpec.o )
[34 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles.PixelMap (
Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelMap.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelMap.o )
[35 of 84] Compiling Graphics.Rendering.OpenGL.GL.Rectangles (
Graphics/Rendering/OpenGL/GL/Rectangles.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Rectangles.o )
[36 of 84] Compiling Graphics.Rendering.OpenGL.GLU.Tessellation (
Graphics/Rendering/OpenGL/GLU/Tessellation.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/Tessellation.o )
[37 of 84] Compiling Graphics.Rendering.OpenGL.GL.Capability (
Graphics/Rendering/OpenGL/GL/Capability.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Capability.o )
[38 of 84] Compiling Graphics.Rendering.OpenGL.GL.Colors (
Graphics/Rendering/OpenGL/GL/Colors.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Colors.o )
[39 of 84] Compiling Graphics.Rendering.OpenGL.GLU.Quadrics (
Graphics/Rendering/OpenGL/GLU/Quadrics.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/Quadrics.o )
[40 of 84] Compiling Graphics.Rendering.OpenGL.GL.ColorSum (
Graphics/Rendering/OpenGL/GL/ColorSum.hs,
dist/build/Graphics/Rendering/OpenGL/GL/ColorSum.o )
[41 of 84] Compiling Graphics.Rendering.OpenGL.GL.CoordTrans (
Graphics/Rendering/OpenGL/GL/CoordTrans.hs,
dist/build/Graphics/Rendering/OpenGL/GL/CoordTrans.o )
[42 of 84] Compiling Graphics.Rendering.OpenGL.GL.Bitmaps (
Graphics/Rendering/OpenGL/GL/Bitmaps.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Bitmaps.o )
[43 of 84] Compiling Graphics.Rendering.OpenGL.GL.Clipping (
Graphics/Rendering/OpenGL/GL/Clipping.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Clipping.o )
[44 of 84] Compiling
Graphics.Rendering.OpenGL.GL.PixelRectangles.Rasterization (
Graphics/Rendering/OpenGL/GL/PixelRectangles/Rasterization.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/Rasterization.o )
[45 of 84] Compiling Graphics.Rendering.OpenGL.GLU.Matrix (
Graphics/Rendering/OpenGL/GLU/Matrix.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/Matrix.o )
[46 of 84] Compiling Graphics.Rendering.OpenGL.GL.Fog (
Graphics/Rendering/OpenGL/GL/Fog.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Fog.o )
[47 of 84] Compiling Graphics.Rendering.OpenGL.GL.Framebuffer (
Graphics/Rendering/OpenGL/GL/Framebuffer.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Framebuffer.o )
[48 of 84] Compiling Graphics.Rendering.OpenGL.GL.LineSegments (
Graphics/Rendering/OpenGL/GL/LineSegments.hs,
dist/build/Graphics/Rendering/OpenGL/GL/LineSegments.o )
[49 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles.ColorTable
( Graphics/Rendering/OpenGL/GL/PixelRectangles/ColorTable.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/ColorTable.o )
[50 of 84] Compiling
Graphics.Rendering.OpenGL.GL.PixelRectangles.Convolution (
Graphics/Rendering/OpenGL/GL/PixelRectangles/Convolution.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/Convolution.o )
[51 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles.Histogram
( Graphics/Rendering/OpenGL/GL/PixelRectangles/Histogram.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/Histogram.o )
[52 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles.Minmax (
Graphics/Rendering/OpenGL/GL/PixelRectangles/Minmax.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/Minmax.o )
[53 of 84] Compiling
Graphics.Rendering.OpenGL.GL.PixelRectangles.PixelTransfer (
Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelTransfer.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelTransfer.o )
[54 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles (
Graphics/Rendering/OpenGL/GL/PixelRectangles.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles.o )
[55 of 84] Compiling Graphics.Rendering.OpenGL.GL.ReadCopyPixels (
Graphics/Rendering/OpenGL/GL/ReadCopyPixels.hs,
dist/build/Graphics/Rendering/OpenGL/GL/ReadCopyPixels.o )
[56 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.TextureTarget (
Graphics/Rendering/OpenGL/GL/Texturing/TextureTarget.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/TextureTarget.o )
[57 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.Specification (
Graphics/Rendering/OpenGL/GL/Texturing/Specification.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/Specification.o )
[58 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.Queries (
Graphics/Rendering/OpenGL/GL/Texturing/Queries.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/Queries.o )
[59 of 84] Compiling Graphics.Rendering.OpenGL.GLU.Mipmapping (
Graphics/Rendering/OpenGL/GLU/Mipmapping.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/Mipmapping.o )
[60 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.TexParameter (
Graphics/Rendering/OpenGL/GL/Texturing/TexParameter.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/TexParameter.o )
[61 of 84] Compiling Graphics.Rendering.OpenGL.GL.Points (
Graphics/Rendering/OpenGL/GL/Points.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Points.o )
[62 of 84] Compiling Graphics.Rendering.OpenGL.GL.Polygons (
Graphics/Rendering/OpenGL/GL/Polygons.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Polygons.o )
[63 of 84] Compiling Graphics.Rendering.OpenGL.GL.RasterPos (
Graphics/Rendering/OpenGL/GL/RasterPos.hs,
dist/build/Graphics/Rendering/OpenGL/GL/RasterPos.o )
[64 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.Application (
Graphics/Rendering/OpenGL/GL/Texturing/Application.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/Application.o )
[65 of 84] Compiling Graphics.Rendering.OpenGL.GL.VertexArrays (
Graphics/Rendering/OpenGL/GL/VertexArrays.hs,
dist/build/Graphics/Rendering/OpenGL/GL/VertexArrays.o )
[66 of 84] Compiling Graphics.Rendering.OpenGL.GL.BufferObjects (
Graphics/Rendering/OpenGL/GL/BufferObjects.hs,
dist/build/Graphics/Rendering/OpenGL/GL/BufferObjects.o )
[67 of 84] Compiling Graphics.Rendering.OpenGL.GL.PerFragment (
Graphics/Rendering/OpenGL/GL/PerFragment.hs,
dist/build/Graphics/Rendering/OpenGL/GL/PerFragment.o )
[68 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.Parameters (
Graphics/Rendering/OpenGL/GL/Texturing/Parameters.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/Parameters.o )
[69 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.Environments (
Graphics/Rendering/OpenGL/GL/Texturing/Environments.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/Environments.o )
[70 of 84] Compiling Graphics.Rendering.OpenGL.GL.Shaders (
Graphics/Rendering/OpenGL/GL/Shaders.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Shaders.o )
[71 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing.Objects (
Graphics/Rendering/OpenGL/GL/Texturing/Objects.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing/Objects.o )
[72 of 84] Compiling Graphics.Rendering.OpenGL.GL.Texturing (
Graphics/Rendering/OpenGL/GL/Texturing.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Texturing.o )
[73 of 84] Compiling Graphics.Rendering.OpenGL.GL.DisplayLists (
Graphics/Rendering/OpenGL/GL/DisplayLists.hs,
dist/build/Graphics/Rendering/OpenGL/GL/DisplayLists.o )
[74 of 84] Compiling Graphics.Rendering.OpenGL.GL.Domain (
Graphics/Rendering/OpenGL/GL/Domain.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Domain.o )
[75 of 84] Compiling Graphics.Rendering.OpenGL.GL.ControlPoint (
Graphics/Rendering/OpenGL/GL/ControlPoint.hs,
dist/build/Graphics/Rendering/OpenGL/GL/ControlPoint.o )
[76 of 84] Compiling Graphics.Rendering.OpenGL.GL.Evaluators (
Graphics/Rendering/OpenGL/GL/Evaluators.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Evaluators.o )
[77 of 84] Compiling Graphics.Rendering.OpenGL.GLU.NURBS (
Graphics/Rendering/OpenGL/GLU/NURBS.hs,
dist/build/Graphics/Rendering/OpenGL/GLU/NURBS.o )
[78 of 84] Compiling Graphics.Rendering.OpenGL.GLU (
Graphics/Rendering/OpenGL/GLU.hs, dist/build/Graphics/Rendering/OpenGL/GLU.o
)
[79 of 84] Compiling Graphics.Rendering.OpenGL.GL.RenderMode (
Graphics/Rendering/OpenGL/GL/RenderMode.hs,
dist/build/Graphics/Rendering/OpenGL/GL/RenderMode.o )
[80 of 84] Compiling Graphics.Rendering.OpenGL.GL.Selection (
Graphics/Rendering/OpenGL/GL/Selection.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Selection.o )
[81 of 84] Compiling Graphics.Rendering.OpenGL.GL.Feedback (
Graphics/Rendering/OpenGL/GL/Feedback.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Feedback.o )
[82 of 84] Compiling Graphics.Rendering.OpenGL.GL.Antialiasing (
Graphics/Rendering/OpenGL/GL/Antialiasing.hs,
dist/build/Graphics/Rendering/OpenGL/GL/Antialiasing.o )
[83 of 84] Compiling Graphics.Rendering.OpenGL.GL (
Graphics/Rendering/OpenGL/GL.hs, dist/build/Graphics/Rendering/OpenGL/GL.o )
[84 of 84] Compiling Graphics.Rendering.OpenGL (
Graphics/Rendering/OpenGL.hs, dist/build/Graphics/Rendering/OpenGL.o )
/usr/bin/ar: creating dist/build/libHSOpenGL-2.2.1.1.a
Installing: /home/donnie/.cabal/lib/OpenGL-2.2.1.1/ghc-6.8.2
Registering OpenGL-2.2.1.1...
Reading package info from "dist/installed-pkg-config" ... done.
Saving old package config file... done.
Writing new package config file... done.
Downloading GLUT-2.1.1.2...
Configuring GLUT-2.1.1.2...
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for Windows environment... no
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for atan... no
checking for atan in -lm... yes
checking for GL library... -lGL -lm
checking for GLU library... -lGLU -lGL -lm
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking GL/glut.h usability... yes
checking GL/glut.h presence... yes
checking for GL/glut.h... yes
checking for GLUT library... no
checking for GL/glut.h... (cached) yes
checking GLUT/glut.h usability... yes
checking GLUT/glut.h presence... yes
checking for GLUT/glut.h... yes
checking for windows.h... (cached) no
configure: creating ./config.status
config.status: creating config.mk
config.status: creating GLUT.buildinfo
config.status: creating include/HsGLUTConfig.h
config.status: creating include/HsGLUT.h
Preprocessing library GLUT-2.1.1.2...
Building GLUT-2.1.1.2...
[ 1 of 21] Compiling Graphics.UI.GLUT.Extensions (
Graphics/UI/GLUT/Extensions.hs, dist/build/Graphics/UI/GLUT/Extensions.o )
[ 2 of 21] Compiling Graphics.UI.GLUT.QueryUtils (
Graphics/UI/GLUT/QueryUtils.hs, dist/build/Graphics/UI/GLUT/QueryUtils.o )
[ 3 of 21] Compiling Graphics.UI.GLUT.Constants (
Graphics/UI/GLUT/Constants.hs, dist/build/Graphics/UI/GLUT/Constants.o )
[ 4 of 21] Compiling Graphics.UI.GLUT.Types ( Graphics/UI/GLUT/Types.hs,
dist/build/Graphics/UI/GLUT/Types.o )
[ 5 of 21] Compiling Graphics.UI.GLUT.Window ( Graphics/UI/GLUT/Window.hs,
dist/build/Graphics/UI/GLUT/Window.o )
[ 6 of 21] Compiling Graphics.UI.GLUT.Callbacks.Registration (
Graphics/UI/GLUT/Callbacks/Registration.hs,
dist/build/Graphics/UI/GLUT/Callbacks/Registration.o )
[ 7 of 21] Compiling Graphics.UI.GLUT.Overlay ( Graphics/UI/GLUT/Overlay.hs,
dist/build/Graphics/UI/GLUT/Overlay.o )
[ 8 of 21] Compiling Graphics.UI.GLUT.State ( Graphics/UI/GLUT/State.hs,
dist/build/Graphics/UI/GLUT/State.o )
[ 9 of 21] Compiling Graphics.UI.GLUT.Objects ( Graphics/UI/GLUT/Objects.hs,
dist/build/Graphics/UI/GLUT/Objects.o )
[10 of 21] Compiling Graphics.UI.GLUT.Initialization (
Graphics/UI/GLUT/Initialization.hs,
dist/build/Graphics/UI/GLUT/Initialization.o )
[11 of 21] Compiling Graphics.UI.GLUT.GameMode (
Graphics/UI/GLUT/GameMode.hs, dist/build/Graphics/UI/GLUT/GameMode.o )
[12 of 21] Compiling Graphics.UI.GLUT.Fonts ( Graphics/UI/GLUT/Fonts.hs,
dist/build/Graphics/UI/GLUT/Fonts.o )
[13 of 21] Compiling Graphics.UI.GLUT.DeviceControl (
Graphics/UI/GLUT/DeviceControl.hs,
dist/build/Graphics/UI/GLUT/DeviceControl.o )
[14 of 21] Compiling Graphics.UI.GLUT.Debugging (
Graphics/UI/GLUT/Debugging.hs, dist/build/Graphics/UI/GLUT/Debugging.o )
[15 of 21] Compiling Graphics.UI.GLUT.Colormap (
Graphics/UI/GLUT/Colormap.hs, dist/build/Graphics/UI/GLUT/Colormap.o )
[16 of 21] Compiling Graphics.UI.GLUT.Callbacks.Window (
Graphics/UI/GLUT/Callbacks/Window.hs,
dist/build/Graphics/UI/GLUT/Callbacks/Window.o )
[17 of 21] Compiling Graphics.UI.GLUT.Menu ( Graphics/UI/GLUT/Menu.hs,
dist/build/Graphics/UI/GLUT/Menu.o )
[18 of 21] Compiling Graphics.UI.GLUT.Callbacks.Global (
Graphics/UI/GLUT/Callbacks/Global.hs,
dist/build/Graphics/UI/GLUT/Callbacks/Global.o )
[19 of 21] Compiling Graphics.UI.GLUT.Callbacks (
Graphics/UI/GLUT/Callbacks.hs, dist/build/Graphics/UI/GLUT/Callbacks.o )
[20 of 21] Compiling Graphics.UI.GLUT.Begin ( Graphics/UI/GLUT/Begin.hs,
dist/build/Graphics/UI/GLUT/Begin.o )
[21 of 21] Compiling Graphics.UI.GLUT ( Graphics/UI/GLUT.hs,
dist/build/Graphics/UI/GLUT.o )
/usr/bin/ar: creating dist/build/libHSGLUT-2.1.1.2.a
Installing: /home/donnie/.cabal/lib/GLUT-2.1.1.2/ghc-6.8.2
Registering GLUT-2.1.1.2...
Reading package info from "dist/installed-pkg-config" ... done.
Saving old package config file... done.
Writing new package config file... done.
####################

### Installed Debian packages ###
  dpkg -l | grep OpenGL
  ii  freeglut3
2.4.0-5                              OpenGL Utility Toolkit
  ii  freeglut3-dev
2.4.0-5                              OpenGL Utility Toolkit development
files
  ii  libgl1-mesa-dev
7.0.3-5                              A free implementation of the OpenGL API
-- G
  ii  libgl1-mesa-dri
7.0.3-5                              A free implementation of the OpenGL API
-- D
  ii  libgl1-mesa-glx
7.0.3-5                              A free implementation of the OpenGL API
-- G
  ii  libglu1-mesa
7.0.3-5                              The OpenGL utility library (GLU)
  ii  libglu1-mesa-dev
7.0.3-5                              The OpenGL utility library --
development fi
  ii  libglw1-mesa
7.0.3-5                              A free implementation of the OpenGL API
-- r
  ii  libglw1-mesa-dev
7.0.3-5                              A free implementation of the OpenGL API
-- d
######################
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080912/5236cba0/attachment-0001.htm
From allbery at ece.cmu.edu  Fri Sep 12 00:48:01 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Fri Sep 12 00:45:49 2008
Subject: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World'
	Program.
In-Reply-To: 
References: 
Message-ID: 

On 2008 Sep 12, at 0:24, Donnie Jones wrote:
> I am trying to test do some OpenGL / GLUT programming in Haskell,  
> but I had linker issues testing the 'Hello World' OpenGL Haskell  
> program.  I believe the linker issues were caused because the  
> Haskell GLUT package couldn't find the GLUT C libraries that were  
> installed with Debian packages.  I have tested that my OpenGL  
> install does work with
(...)
> checking for GLUT library... no

You need to check config.log from the Haskell GLUT build to see why it  
couldn't find (or possibly couldn't link with) the GLUT library.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080912/b831188c/attachment.htm
From bulat.ziganshin at gmail.com  Fri Sep 12 04:13:52 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Fri Sep 12 04:12:04 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <48C97068.7010201@btinternet.com>
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
	<48C6C17C.1040000@btinternet.com>
	
	<48C97068.7010201@btinternet.com>
Message-ID: <441813375.20080912121352@gmail.com>

Hello Andrew,

Thursday, September 11, 2008, 11:24:24 PM, you wrote:

> interestingly, XN seems to make GHC-compiled binary files dramatically
> *smaller*... huh??)

probably it does `strip` on executable. -optl-s option does the same
trick


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From dougal at dougalstanton.net  Fri Sep 12 07:21:59 2008
From: dougal at dougalstanton.net (Dougal Stanton)
Date: Fri Sep 12 07:19:42 2008
Subject: [Haskell-cafe] Erroneous package listings in hackage?
Message-ID: <2d3641330809120421l2731f07bqf14799165ef43b56@mail.gmail.com>

$ cabal update
...
$ cabal list | less
 ...
 * cairo
      Latest version installed: 0.9.13
      Homepage: http://haskell.org/gtk2hs/
      License:  BSD3
 ...
$ cabal install cairo
cabal: There is no package named cairo

I must admit I was surprised to see a gtk2hs module on Hackage, but
not half as surprised when I found it wasn't there after all...

D
From hjgtuyl at chello.nl  Fri Sep 12 08:18:41 2008
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Fri Sep 12 08:16:22 2008
Subject: [Haskell-cafe] Erroneous package listings in hackage?
In-Reply-To: <2d3641330809120421l2731f07bqf14799165ef43b56@mail.gmail.com>
References: <2d3641330809120421l2731f07bqf14799165ef43b56@mail.gmail.com>
Message-ID: 

On Fri, 12 Sep 2008 13:21:59 +0200, Dougal Stanton  
 wrote:

> $ cabal update
> ...
> $ cabal list | less
>  ...
>  * cairo
>       Latest version installed: 0.9.13
>       Homepage: http://haskell.org/gtk2hs/
>       License:  BSD3
>  ...
> $ cabal install cairo
> cabal: There is no package named cairo
>
> I must admit I was surprised to see a gtk2hs module on Hackage, but
> not half as surprised when I found it wasn't there after all...
>
> D

There is clearly something wrong here; there is also a package named gtk  
that is listed with "cabal list" but cannot be downloaded.

If you need Cairo, it is included in the Gtk2Hs package (  
http://haskell.org/gtk2hs/download/ ).


-- 
Met vriendelijke groet,
Henk-Jan van Tuyl


--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--

From kowey at darcs.net  Fri Sep 12 10:07:13 2008
From: kowey at darcs.net (Eric Kow)
Date: Fri Sep 12 10:04:56 2008
Subject: [Haskell-cafe] Re: darcs hacking sprint,
	venues confirmed! (25-26 October)
In-Reply-To: <20080906071204.GI23865@Macintosh.local>
References: <20080906071204.GI23865@Macintosh.local>
Message-ID: <20080912140712.GA32138@brighton.ac.uk>

On Sat, Sep 06, 2008 at 08:12:04 +0100, Eric Y. Kow wrote:
> Earlier I wrote an announcement for the darcs hacking sprint on 25-26
> October.  Tonight, I am delighted to announce that we have two venues
> confirmed for the sprint and one serious offer.

Just to add to that: the Paris venue is now confirmed as well!

  * CONFIRMED: Brighton, UK     (University of Brighton)
  * CONFIRMED: Portland, USA    (Galois Connections)
  * CONFIRMED: Paris,    France (Universit? Paris Diderot)

This is for the weekend of 25-26 October.

http://wiki.darcs.net/index.html/Sprints

Thanks!

P.S. If you wish to participate at the Paris venue, please
     notify Nicolas Pouillard at least one week in advance.

-- 
Eric Kow 
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080912/d7635771/attachment.bin
From icfp.publicity at googlemail.com  Fri Sep 12 10:18:23 2008
From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair))
Date: Fri Sep 12 10:16:05 2008
Subject: [Haskell-cafe] Workshop on Generic Programming: Call for
	Participation (co-located w/ ICFP08)
Message-ID: <53ff55480809120718l3af310b0j75cfe366da48e8c2@mail.gmail.com>

Dear all,

the Workshop on Generic Programming is only a few days away: 20th
September 2008 (http://www.regmaster.com/conf/icfp2008.html).

==> Invited talk: The Generic Paradigm
==> Lambert Meertens (Utrecht University)

==> We have reserved 20 minutes for *lightning talks*. If you plan to
==> attend and if you would like to give a short talk (about half-baked,
==> exciting, new stuff) please drop me a short note. Slots will be
==> reserved on a first-come-first-serve basis.

Looking forward to seeing you in Victoria, Ralf Hinze

============================================================================

                           CALL FOR PARTICIPATION

                     Workshop on Generic Programming 2008

                    Victoria, Canada, 20th September 2008

     http://www.comlab.ox.ac.uk/ralf.hinze/wgp2008/cfp.{html,pdf,ps,txt}

     The Workshop on Generic Programming is sponsored by ACM SIGPLAN
     and forms part of ICFP 2008.  Previous Workshops on Generic
     Programming have been held in Marstrand (affiliated with MPC),
     Ponte de Lima (affiliated with MPC), Nottingham (informal
     workshop), Dagstuhl (IFIP WG2.1 Working Conference), Oxford
     (informal workshop), Utrecht (informal workshop), and Portland
     (affiliated with ICFP).

============================================================================

Preliminary program
-------------------

9:00 - 10:00, Session Chair: Ralf Hinze (University of Oxford)

    Welcome

    Invited talk: The Generic Paradigm
    Lambert Meertens (Utrecht University)

10:30 - 12:00, Session Chair: Jeremy Gibbons (University of Oxford)

    A Functional Model-View-Controller Software Architecture for
    Command-oriented Programs
    Alley Stoughton (Kansas State University)

    A Lightweight Approach to Datatype-Generic Rewriting
    Thomas van Noort (Radboud University Nijmegen), Alexey Rodriguez,
    Stefan Holdermans (Utrecht University), Johan Jeuring (Utrecht
    University and Open University of the Netherlands), Bastiaan
    Heeren (Open University of the Netherlands)

    Lightning talks

13:30 - 15:00, Session Chair: Ralf Hinze (University of Oxford)

    Report from the program chair
    Ralf Hinze (University of Oxford)

    Scala for Generic Programmers
    Bruno C. d. S. Oliveira, Jeremy Gibbons (University of Oxford)

    A Comparison of C++ Concepts and Haskell Type Classes
    Jean-Philippe Bernardy, Patrik Jansson, Marcin Zalewski, Sibylle
    Schupp, Andreas Priesnitz (Chalmers University of Technology and
    University of Gothenburg)

    Lightning talks

15:30 - 17:30, Session Chair: Patrik Jansson (Chalmers University of
    Technology and University of Gothenburg)

    Polytypic Programming in Coq
    Wendy Verbruggen, Edsko de Vries, Arthur Hughes (Trinity College
    Dublin)

    Bialgebra Views: A Way for Polytypic Programming to Cohabit with
    Data Abstraction
    Pablo Nogueira, Juan Jose Moreno-Navarro (Universidad Politecnica
    de Madrid)

    Discussion

============================================================================
From ntupel at googlemail.com  Fri Sep 12 10:31:26 2008
From: ntupel at googlemail.com (ntupel@googlemail.com)
Date: Fri Sep 12 10:29:08 2008
Subject: [Haskell-cafe] JSON serialization/deserialization
Message-ID: 

Dear list members,

I try to use Text.JSON
(http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json) to
serialize and deserialize record types. As I understand it, the data
types need to be instances of class JSON. However I have difficulties
to come up with a nice implementation of showJSON and readJSON. For
example:


module Test where

import Text.JSON

data Record =
    One {
        field1 :: String,
        field2 :: String }
  | Two {
        field :: String } deriving (Eq, Ord, Show, Read)

showJSON (One x y) = toJSObject [("field1", x), ("field2", y)]
showJSON (Two x)   = toJSObject [("field", x)]

readJSON x = -- ???

This lacks the instance declaration itself but my problem is more
fundamental. How can I write the readJSON method? In general how would
one approach the problem of serialization/deserialization? I am
puzzled that the type classes Show and Read can be derived
automatically. I can not think of any way to do this.

Thanks for your help!
From tphyahoo at gmail.com  Fri Sep 12 11:07:23 2008
From: tphyahoo at gmail.com (Thomas Hartman)
Date: Fri Sep 12 11:05:07 2008
Subject: [Haskell-cafe] Real World HAppS: Cabalized,
	Self-Demoing HAppS Tutorial (Version 3)
Message-ID: <910ddf450809120807j6d1379b3uc8a23c8dc8720b55@mail.gmail.com>

I pushed a new version of happs-tutorial to the online demo at

http://happstutorial.com:5001 This is also on hackage: cabal install
happs-tutorial. (now version 3.)

or darcs get http://code.haskell.org/happs-tutorial for the latest

The demo/tutorial has the same basic functionality as the last release
-- just a login form essentially -- but a lot more bling now. Like
menu link items that change colors when the page is clicked. Also the
login form that gives sane error messages.

The focus for this release was on explaining how I used StringTemplate
with HAppS.

Hopefully in version 4 I'll finally get to State and Macid! And
hopefully some functionality that actually does something beyond just
showing what users have created logins :)

Thomas
From bruceteckel at gmail.com  Fri Sep 12 11:07:53 2008
From: bruceteckel at gmail.com (Bruce Eckel)
Date: Fri Sep 12 11:05:37 2008
Subject: [Haskell-cafe] Re: Can you do everything without shared-memory
	concurrency?
In-Reply-To: 
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<20080909192320.GG3126@brakk.ethz.ch>
	<117f2cc80809100605l54ea9b7fse5019b05853b11c@mail.gmail.com>
	<20080910133050.GN3126@brakk.ethz.ch>
	<20080910140801.GP25426@darcs.net> 
Message-ID: <14e7a2380809120807k23c59db5mafde9e93657c83a4@mail.gmail.com>

OK, let me throw another idea out here. When Allen Holub first
explained Actors to me, he made the statement that Actors prevent
deadlocks. In my subsequent understanding of them, I haven't seen
anything that would disagree with that -- as long as you only use
Actors and nothing else for parallelism.

If someone were to create a programming system where you were only
able to use Actors and nothing else for parallelism, could you do
everything using Actors? Is there anything you couldn't do?

I'm assuming again that we can throw lots of processors at a problem.

On Thu, Sep 11, 2008 at 8:17 PM, Aaron Denney  wrote:
> On 2008-09-10, David Roundy  wrote:
>> On Wed, Sep 10, 2008 at 03:30:50PM +0200, Jed Brown wrote:
>>> On Wed 2008-09-10 09:05, David Roundy wrote:
>>> > I should point out, however, that in my experience MPI programming
>>> > involves deadlocks and synchronization handling that are at least as
>>> > nasty as any I've run into doing shared-memory threading.
>>>
>>> Absolutely, avoiding deadlock is the first priority (before error
>>> handling).  If you use the non-blocking interface, you have to be very
>>> conscious of whether a buffer is being used or the call has completed.
>>> Regardless, the API requires the programmer to maintain a very clear
>>> distinction between locally owned and remote memory.
>>
>> Even with the blocking interface, you had subtle bugs that I found
>> pretty tricky to deal with.  e.g. the reduce functions in lam3 (or was
>> it lam4) at one point didn't actually manage to result in the same
>> values on all nodes (with differences caused by roundoff error), which
>> led to rare deadlocks, when it so happened that two nodes disagreed as
>> to when a loop was completed.  Perhaps someone made the mistake of
>> assuming that addition was associative, or maybe it was something
>> triggered by the non-IEEE floating point we were using.  But in any
>> case, it was pretty nasty.  And it was precisely the kind of bug that
>> won't show up except when you're doing something like MPI where you
>> are pretty much forced to assume that the same (pure!) computation has
>> the same effect on each node.
>
> Ah, okay.  I think that's a real edge case, and probably not how most
> use MPI.  I've used both threads and MPI; MPI, while cumbersome, never
> gave me any hard-to-debug deadlock problems.
>
> --
> Aaron Denney
> -><-
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Bruce Eckel
From robgreayer at yahoo.com  Fri Sep 12 11:34:01 2008
From: robgreayer at yahoo.com (Robert Greayer)
Date: Fri Sep 12 11:31:44 2008
Subject: [Haskell-cafe] Re: Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809120807k23c59db5mafde9e93657c83a4@mail.gmail.com>
Message-ID: <480682.94399.qm@web65701.mail.ac4.yahoo.com>

--- On Fri, 9/12/08, Bruce Eckel  wrote:

> OK, let me throw another idea out here. When Allen Holub
> first
> explained Actors to me, he made the statement that Actors
> prevent
> deadlocks. In my subsequent understanding of them, I
> haven't seen
> anything that would disagree with that -- as long as you
> only use
> Actors and nothing else for parallelism.
> 

As I believe it is the case that you can emulate shared resources, and locks to control concurrent access to them, using the actor model, I can't see how this can be true.

rcg



      
From conal at conal.net  Fri Sep 12 11:37:26 2008
From: conal at conal.net (Conal Elliott)
Date: Fri Sep 12 11:35:06 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: <200809081442.17458.al@beshenov.ru>
References: 
	<200809081442.17458.al@beshenov.ru>
Message-ID: 

I think I'll go the route of @haskell.org and gmane.  Does anyone have
advice about spam protection or other helpful matters?  - Conal

On Mon, Sep 8, 2008 at 12:42 PM, Alexey Beshenov  wrote:

> On Monday 08 September 2008 14:33:47 Conal Elliott wrote:
> > I want to set up some kind of mailing list for reactive (which I
> > plan to release soon).  The most obvious thing is to set up a
> > mailman-based list on haskell.org, but I wonder -- do people really
> > want to keep using mailman technology?  Or something more modern
> > like Yahoo or Google groups.
>
> Mailman is nice. You can register your list at the http://gmane.org/
>
> (see http://dir.gmane.org/index.php?prefix=gmane.comp.lang.haskell)
>
> --
> Sweetmorn, Bureaucracy 32, 3174 YOLD
> Alexey Beshenov http://beshenov.ru/
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080912/c0b1318d/attachment.htm
From trebla at vex.net  Fri Sep 12 11:41:16 2008
From: trebla at vex.net (Albert Y. C. Lai)
Date: Fri Sep 12 11:38:59 2008
Subject: [Haskell-cafe] Can you do everything without
	shared-memory	concurrency?
In-Reply-To: <3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
Message-ID: <48CA8D9C.2080709@vex.net>

Sebastian Sylvan wrote:
> For correctness, maybe not, for efficiency, yes definitely!

In theory, decades of research and engineering went into shared memory 
on common hardware, so it should be faster.

In practice, you give shared memory to spoiled kids (and seldom 
encourage them to use other paradigms), and they have no incentive to 
decompose their problems. They just gratuitously share all variables and 
therefore need to lock everything. So it becomes slower.

If you think hard to decompose a problem, several possibilities occur:

- Some problems need shared memory badly.
- Most other problems need sharing so little that the way you use shared 
memory ends up simulating message passing.

I encourage you to re-think how often your problems land in the second 
case. Because we are all spoiled by shared memory, it may be hard to notice.

From al at beshenov.ru  Fri Sep 12 11:49:50 2008
From: al at beshenov.ru (Alexey Beshenov)
Date: Fri Sep 12 11:47:57 2008
Subject: [Haskell-cafe] mailing list choices?
In-Reply-To: 
References: 
	<200809081442.17458.al@beshenov.ru>
	
Message-ID: <200809121949.50854.al@beshenov.ru>

On Friday 12 September 2008 19:37:26 Conal Elliott wrote:

> I think I'll go the route of @haskell.org and gmane. Does anyone
> have advice about spam protection or other helpful matters?  -
> Conal

For filtering the junk e-mail manually, I recommend listadmin:

  http://heim.ifi.uio.no/kjetilho/hacks/#listadmin

-- 
Setting Orange, Bureaucracy 36, 3174 YOLD
Alexey Beshenov http://beshenov.ru/
From sebastian.sylvan at gmail.com  Fri Sep 12 12:31:47 2008
From: sebastian.sylvan at gmail.com (Sebastian Sylvan)
Date: Fri Sep 12 12:29:29 2008
Subject: [Haskell-cafe] Re: Can you do everything without shared-memory
	concurrency?
In-Reply-To: <14e7a2380809120807k23c59db5mafde9e93657c83a4@mail.gmail.com>
References: <14e7a2380809081233ldead123ia0d52f1b9d8dbc7a@mail.gmail.com>
	<3d96ac180809090303t65e6d41anfc67e90301aea623@mail.gmail.com>
	<14e7a2380809091130q52d2c75dp59e622b5c284a49a@mail.gmail.com>
	<20080909192320.GG3126@brakk.ethz.ch>
	<117f2cc80809100605l54ea9b7fse5019b05853b11c@mail.gmail.com>
	<20080910133050.GN3126@brakk.ethz.ch>
	<20080910140801.GP25426@darcs.net> 
	<14e7a2380809120807k23c59db5mafde9e93657c83a4@mail.gmail.com>
Message-ID: <3d96ac180809120931m5a43b218id8578b36429d8468@mail.gmail.com>

On Fri, Sep 12, 2008 at 4:07 PM, Bruce Eckel  wrote:

> OK, let me throw another idea out here. When Allen Holub first
> explained Actors to me, he made the statement that Actors prevent
> deadlocks. In my subsequent understanding of them, I haven't seen
> anything that would disagree with that -- as long as you only use
> Actors and nothing else for parallelism.


I think you need to specify what you mean by actors, because I can't see how
they would eliminate deadlocks as I understand them. Could you not write an
actor that holds a single cell mailbox (both reads and writes are blocking),
then set up two classes that shuffles values from the same two mailboxes in
the opposite direction?

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080912/8442702c/attachment.htm
From marco-oweber at gmx.de  Fri Sep 12 12:34:36 2008
From: marco-oweber at gmx.de (Marc Weber)
Date: Fri Sep 12 12:32:20 2008
Subject: [Haskell-cafe] JSON serialization/deserialization
In-Reply-To: 
References: 
Message-ID: <20080912163436.GA32684@gmx.de>

The trouble:
module A
data ABC = A { a :: String }
         | B { a :: String }
         | C { a :: String }

module B
data ABC = A { a :: String }
         | B { a :: String }
         | C { a :: String }

is valid haskell.
so how should you know having the serialized String { a : "abc" }
wether to use the constructor A,B,C ? or wether to use ABC from module A
or from B?
There are many ways to solve this:
One is to serialize it this way: { "datatype": "A.ABC", constructor : "C"
                                 , a :"text" }
or such..
Maybe also read about Data.Typable, have a look at derive or DrIft (or
the lib itself, I'm not sure wethere there is one which has choosen one
way to do this)..

Basically JavaScript doesn't have real typing (such as classes). But
there exist some libraries to emulate it such as mootools or
scriptaculous..

I hope you'll find a solution which works for you.

Sincerly
Marc Weber
From jgoerzen at complete.org  Fri Sep 12 03:44:44 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Fri Sep 12 12:50:33 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: <20080910213520.GA29811@charger.brianweb.net>
References:  <20080910121200.GA6861@gmx.de>
	<20080910213520.GA29811@charger.brianweb.net>
Message-ID: <20080912074444.GA3157@hustlerturf.com>

On Wed, Sep 10, 2008 at 05:35:20PM -0400, Brian Alliet wrote:
> On Wed, Sep 10, 2008 at 02:12:00PM +0200, Marc Weber wrote:
> > There used to be.
> > http://www.cs.rit.edu/~bja8464/lambdavm/
> > (Last darcs change log entry:
> > Sun Oct 21 03:05:20 CEST 2007  Brian Alliet 
> >   * fix build for hsjava change
> > )
> 
> Sorry about this. I hit a critical mass of darcs conflicts (I look
> forward to giving git a try) around the same time I got really busy at
> work. I've been meaning to get back into it (and update it to GHC HEAD)
> but I haven't received sufficient nagging yet. Please yell if you're
> interested in LambdaVM. At the very least I should be able to help get
> whatever is in darcs compiling.

I for one would welcome the ability to compile Haskell programs into
Java bytecode.  One issue I have right now is the ability to get my
code into the hands of a wide audience, since the Haskell toolchain is
not widely installed by default.  That and I tend to use a ton of
Haskell modules, and there isn't a "just install all the deps" in ghc
yet ;-)

-- John
From andrewcoppin at btinternet.com  Fri Sep 12 13:07:28 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Fri Sep 12 13:10:19 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <441813375.20080912121352@gmail.com>
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
	<48C6C17C.1040000@btinternet.com>
	
	<48C97068.7010201@btinternet.com>
	<441813375.20080912121352@gmail.com>
Message-ID: <48CAA1D0.2040006@btinternet.com>

Bulat Ziganshin wrote:
> Hello Andrew,
>
> Thursday, September 11, 2008, 11:24:24 PM, you wrote:
>
>   
>> interestingly, XN seems to make GHC-compiled binary files dramatically
>> *smaller*... huh??)
>>     
>
> probably it does `strip` on executable. -optl-s option does the same
> trick
>   

And what exactly does a "strip" mean, then?

From andrewcoppin at btinternet.com  Fri Sep 12 13:11:58 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Fri Sep 12 13:14:28 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: 
References: <48C6AECE.3020905@btinternet.com>	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>	<48C6C17C.1040000@btinternet.com>		<48C97068.7010201@btinternet.com>
	
Message-ID: <48CAA2DE.3080701@btinternet.com>

Jeff Zaroyko wrote:
> Andrew Coppin  btinternet.com> writes:
>
>   
>> Jeff Zaroyko wrote:
>>     
>>> In theory, you should be able to use mingw's windres tool to produce
>>> an object file from the resource definition which you'd link with 
>>> the rest of your program.
>>>
>>>       
>> Yes, there's a cryptic comment burried away in the GHC manual that says 
>> GHC itself already uses windres to embed the manifest file into the 
>> compiled binary file. (And sure enough, if you crawl through with a hex 
>> editor you'll find the raw XML in there.) There's an option to tell GHC 
>> to not do this - however, I don't see any option anywhere to tell it to 
>> embed a *different* resource file instead. 
>>     
>
> All I meant by linking is including the object file when you invoke ghc.
>
> windres foo.rc -o foores.o
> ghc bar.hs foo.o
>   

Not sure if that works when using ghc --make, but we'll see.

Actually no, we won't. Because I have just spent about 2 hours trying to 
get that first command to work. I am now exasperated beyond my powers of 
description. I made GHC print out all the commands it executes. I cut 
and pasted the windres command and changed the filenames. windres 
stubbornly *refuses* to work for me. It complains endlessly about 
"invalid arguments". (E.g., it claims that "-B" isn't a valid option.) 
And yet, this is the EXACT command that GHC executed, and it didn't 
complain for GHC. GRRR!!! >_< I even tried removing the arguments it 
doesn't like - but then it can't find any of the include files. 
Basically no matter what I do, I cannot make windres compile anything.

I literally cannot *believe* how hard it is to put a few little words 
into that version tab... Every other kind of resource seems to be 
completely trivial, but this just won't work for toffee!

From njbartlett at gmail.com  Fri Sep 12 13:18:49 2008
From: njbartlett at gmail.com (Neil Bartlett)
Date: Fri Sep 12 13:16:30 2008
Subject: [Haskell-cafe] Haskell and Java
In-Reply-To: <20080912074444.GA3157@hustlerturf.com>
References:  <20080910121200.GA6861@gmx.de>
	<20080910213520.GA29811@charger.brianweb.net>
	<20080912074444.GA3157@hustlerturf.com>
Message-ID: 

+1

Due to the commercial environment I work in, there's really no chance
of me using Haskell at work unless it runs under JVM or CLR. Brian,
consider yourself nagged! And if there's anywhere you need some help,
please yell.

Neil


On Fri, Sep 12, 2008 at 8:44 AM, John Goerzen  wrote:
> On Wed, Sep 10, 2008 at 05:35:20PM -0400, Brian Alliet wrote:
>> On Wed, Sep 10, 2008 at 02:12:00PM +0200, Marc Weber wrote:
>> > There used to be.
>> > http://www.cs.rit.edu/~bja8464/lambdavm/
>> > (Last darcs change log entry:
>> > Sun Oct 21 03:05:20 CEST 2007  Brian Alliet 
>> >   * fix build for hsjava change
>> > )
>>
>> Sorry about this. I hit a critical mass of darcs conflicts (I look
>> forward to giving git a try) around the same time I got really busy at
>> work. I've been meaning to get back into it (and update it to GHC HEAD)
>> but I haven't received sufficient nagging yet. Please yell if you're
>> interested in LambdaVM. At the very least I should be able to help get
>> whatever is in darcs compiling.
>
> I for one would welcome the ability to compile Haskell programs into
> Java bytecode.  One issue I have right now is the ability to get my
> code into the hands of a wide audience, since the Haskell toolchain is
> not widely installed by default.  That and I tend to use a ton of
> Haskell modules, and there isn't a "just install all the deps" in ghc
> yet ;-)
>
> -- John
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From jonathanccast at fastmail.fm  Fri Sep 12 13:17:39 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Fri Sep 12 13:20:25 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <48CAA1D0.2040006@btinternet.com>
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
	<48C6C17C.1040000@btinternet.com>
	
	<48C97068.7010201@btinternet.com> <441813375.20080912121352@gmail.com>
	<48CAA1D0.2040006@btinternet.com>
Message-ID: <1221239859.7111.26.camel@jcchost>

On Fri, 2008-09-12 at 18:07 +0100, Andrew Coppin wrote:
> Bulat Ziganshin wrote:
> > Hello Andrew,
> >
> > Thursday, September 11, 2008, 11:24:24 PM, you wrote:
> >
> >   
> >> interestingly, XN seems to make GHC-compiled binary files dramatically
> >> *smaller*... huh??)
> >>     
> >
> > probably it does `strip` on executable. -optl-s option does the same
> > trick
> >   
> 
> And what exactly does a "strip" mean, then?

Remove the symbol table.  And, for C, other debugging information.

Historically, I believe, on Unix the distinction between an executable
and an object file was weaker than it is now (so, for example, a.out was
originally the default name of an object file, back when you didn't
always need to link in a library).  So (and this is still sometimes true
on linux) the linker's output could be used as input to the linker.
Unix linkers still include the combined symbol table in the executables
they generate, to allow this.  But if your executable is complete, you
don't need a symbol table, so Unix includes a program `strip' that
removes it from an executable (or object file, if you do something
stupid).

GHC's Windows port, of course, uses a port of the Unix toolchain, so the
above discussion (almost) completely applies.  (Although I don't think
any (static) linker actually accepts Windows PE executables as input).

jcc


From bulat.ziganshin at gmail.com  Fri Sep 12 13:27:26 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Fri Sep 12 13:25:28 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <48CAA1D0.2040006@btinternet.com>
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
	<48C6C17C.1040000@btinternet.com>
	
	<48C97068.7010201@btinternet.com>
	<441813375.20080912121352@gmail.com>
	<48CAA1D0.2040006@btinternet.com>
Message-ID: <1894509383.20080912212726@gmail.com>

Hello Andrew,

Friday, September 12, 2008, 9:07:28 PM, you wrote:

>> probably it does `strip` on executable. -optl-s option does the same
>> trick
>>   

> And what exactly does a "strip" mean, then?

stripping C debugging info, which is useless anyway

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From andrewcoppin at btinternet.com  Fri Sep 12 13:35:45 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Fri Sep 12 13:33:20 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <1221239859.7111.26.camel@jcchost>
References: <48C6AECE.3020905@btinternet.com>	
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>	
	<48C6C17C.1040000@btinternet.com>
		
	<48C97068.7010201@btinternet.com>
	<441813375.20080912121352@gmail.com>	
	<48CAA1D0.2040006@btinternet.com>
	<1221239859.7111.26.camel@jcchost>
Message-ID: <48CAA871.5010206@btinternet.com>

Jonathan Cast wrote:
> On Fri, 2008-09-12 at 18:07 +0100, Andrew Coppin wrote:
>   
>> And what exactly does a "strip" mean, then?
>>     
>
> Remove the symbol table.  And, for C, other debugging information.
>
> Historically, I believe, on Unix the distinction between an executable
> and an object file was weaker than it is now (so, for example, a.out was
> originally the default name of an object file, back when you didn't
> always need to link in a library).  So (and this is still sometimes true
> on linux) the linker's output could be used as input to the linker.
> Unix linkers still include the combined symbol table in the executables
> they generate, to allow this.  But if your executable is complete, you
> don't need a symbol table, so Unix includes a program `strip' that
> removes it from an executable (or object file, if you do something
> stupid).
>
> GHC's Windows port, of course, uses a port of the Unix toolchain, so the
> above discussion (almost) completely applies.  (Although I don't think
> any (static) linker actually accepts Windows PE executables as input).
>   

That would certainly explain why the end of my compiled binary contains 
several miles of ASCII that looks like function names then... ;-)

So if I give GHC the right options, it'll do that for me?

From jonathanccast at fastmail.fm  Fri Sep 12 13:50:32 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Fri Sep 12 13:53:17 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <48CAA871.5010206@btinternet.com>
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
	<48C6C17C.1040000@btinternet.com>
	
	<48C97068.7010201@btinternet.com> <441813375.20080912121352@gmail.com>
	<48CAA1D0.2040006@btinternet.com> <1221239859.7111.26.camel@jcchost>
	<48CAA871.5010206@btinternet.com>
Message-ID: <1221241832.7111.38.camel@jcchost>

On Fri, 2008-09-12 at 18:35 +0100, Andrew Coppin wrote:
> Jonathan Cast wrote:
> > On Fri, 2008-09-12 at 18:07 +0100, Andrew Coppin wrote:
> >   
> >> And what exactly does a "strip" mean, then?
> >>     
> >
> > Remove the symbol table.  And, for C, other debugging information.
> >
> > Historically, I believe, on Unix the distinction between an executable
> > and an object file was weaker than it is now (so, for example, a.out was
> > originally the default name of an object file, back when you didn't
> > always need to link in a library).  So (and this is still sometimes true
> > on linux) the linker's output could be used as input to the linker.
> > Unix linkers still include the combined symbol table in the executables
> > they generate, to allow this.  But if your executable is complete, you
> > don't need a symbol table, so Unix includes a program `strip' that
> > removes it from an executable (or object file, if you do something
> > stupid).
> >
> > GHC's Windows port, of course, uses a port of the Unix toolchain, so the
> > above discussion (almost) completely applies.  (Although I don't think
> > any (static) linker actually accepts Windows PE executables as input).
> >   
> 
> That would certainly explain why the end of my compiled binary contains 
> several miles of ASCII that looks like function names then... ;-)
> 
> So if I give GHC the right options, it'll do that for me?

Correct.  Finding the right option is left as a Google-enabled exercise
for the reader.

jcc


From andrewcoppin at btinternet.com  Fri Sep 12 15:29:13 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Fri Sep 12 15:26:47 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
Message-ID: <48CAC309.9040708@btinternet.com>

Max Bolingbroke wrote:
> 2008/9/9 Andrew Coppin :
>   
>> Actually, now that I think about it, it would be kind of nice to have a
>> magic package that writes out escape codes or calls the Win32 API depending
>> on which platform your program is compiled on - in the style of
>> System.FilePath. I don't know how to do that though... A nice idea, guys?
>>     
>
> I wrote this package a few weeks ago: check out
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ansi-terminal
> and it's companion
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ansi-wl-pprint
>   

Ah, so somebody has already beaten me to it, eh? Looks like the only 
thing it doesn't do is let you change the title on the console window. 
(Because, obviously, that's only possible on Windows.) And what do you 
know, it installed out of the box without issue on my Windows system. 
Now that's pretty rare...

Any ideas about the build log error that's preventing Hackage from 
autogenerating the documentation?

From jason.dusek at gmail.com  Fri Sep 12 15:47:44 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Fri Sep 12 15:46:09 2008
Subject: [Haskell-cafe] template haskell -- include a file?
Message-ID: <42784f260809121247t1b6f931fma0e0986053cb70a9@mail.gmail.com>

  I'd like to use template Haskell to include as a string in a
  Haskell file. How do I do it?

  Is there any lengthy documentation with examples for Template
  Haskell? The pages linked to from `haskell.org` are a little
  sparse.

--
_jsn
From bulat.ziganshin at gmail.com  Fri Sep 12 16:21:13 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Fri Sep 12 16:20:22 2008
Subject: [Haskell-cafe] template haskell -- include a file?
In-Reply-To: <42784f260809121247t1b6f931fma0e0986053cb70a9@mail.gmail.com>
References: <42784f260809121247t1b6f931fma0e0986053cb70a9@mail.gmail.com>
Message-ID: <982805969.20080913002113@gmail.com>

Hello Jason,

Friday, September 12, 2008, 11:47:44 PM, you wrote:

>   I'd like to use template Haskell to include as a string in a
>   Haskell file. How do I do it?

TH is a typed macrosystem - you generate special datastructure
representing haskell code rather than untyped strings

>   Is there any lengthy documentation with examples for Template
>   Haskell? The pages linked to from `haskell.org` are a little
>   sparse.

look for "Bulat's tutorials" at http://haskell.org/haskellwiki/Template_Haskell
although they both are unfinished

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From alfonso.acosta at gmail.com  Fri Sep 12 16:33:54 2008
From: alfonso.acosta at gmail.com (Alfonso Acosta)
Date: Fri Sep 12 16:31:37 2008
Subject: [Haskell-cafe] template haskell -- include a file?
In-Reply-To: <42784f260809121247t1b6f931fma0e0986053cb70a9@mail.gmail.com>
References: <42784f260809121247t1b6f931fma0e0986053cb70a9@mail.gmail.com>
Message-ID: <6a7c66fc0809121333t2da61e4dra7255943f11f8e7f@mail.gmail.com>

On Fri, Sep 12, 2008 at 9:47 PM, Jason Dusek  wrote:
>  I'd like to use template Haskell to include as a string in a
>  Haskell file. How do I do it?

I presume you mean Include a string from the outside world with a IO
action (a file, keyborad, etc ...)

--
module EmbedStr (embedStr) where

import Language.Haskell.TH
import Language.Haskell.TH.Syntax (lift)

embedStr :: IO String -> ExpQ
embedStr readStr = lift =<< runIO readStr
--

For example, to get asked about the string you want to embed during
compilation ...

$ ghci -XTemplateHaskell EmbedStr.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling EmbedStr         ( EmbedStr.hs, interpreted )
Ok, modules loaded: EmbedStr.
*EmbedStr> let myStr = $(embedStr ((putStrLn "What string?") >> getLine))
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 pretty-1.0.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
What String?
Foo
*EmbedStr> myStr
"Foo"
*EmbedStr>



>  Is there any lengthy documentation with examples for Template
>  Haskell? The pages linked to from `haskell.org` are a little
>  sparse.

Uhm, I only know about

http://www.haskell.org/haskellwiki/Template_Haskell#Template_Haskell_tutorials_and_papers

I particularly like Mark Snyder's Template Haskell chapter on the
Software Generation and Configuration Report , but the link is broken
:(
From jason.dusek at gmail.com  Fri Sep 12 16:35:11 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Fri Sep 12 16:32:51 2008
Subject: [Haskell-cafe] template haskell -- include a file?
In-Reply-To: <6a7c66fc0809121333t2da61e4dra7255943f11f8e7f@mail.gmail.com>
References: <42784f260809121247t1b6f931fma0e0986053cb70a9@mail.gmail.com>
	<6a7c66fc0809121333t2da61e4dra7255943f11f8e7f@mail.gmail.com>
Message-ID: <42784f260809121335y28d42013gdefdff49c48059dc@mail.gmail.com>

  Thank you!

--
_jsn
From jason.dusek at gmail.com  Fri Sep 12 16:42:57 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Fri Sep 12 16:40:37 2008
Subject: [Haskell-cafe] template haskell -- include a file?
In-Reply-To: <6a7c66fc0809121333t2da61e4dra7255943f11f8e7f@mail.gmail.com>
References: <42784f260809121247t1b6f931fma0e0986053cb70a9@mail.gmail.com>
	<6a7c66fc0809121333t2da61e4dra7255943f11f8e7f@mail.gmail.com>
Message-ID: <42784f260809121342j42968f48gc9835781819f6a08@mail.gmail.com>

Alfonso Acosta  wrote:
> Uhm, I only know about
>
> http://www.haskell.org/haskellwiki/Template_Haskell#Template_Haskell_tutorials_and_papers

  Oh, I guess I missed the wiki.

--
_jsn
From vss at 73rus.com  Fri Sep 12 17:30:16 2008
From: vss at 73rus.com (Vlad Skvortsov)
Date: Fri Sep 12 17:28:07 2008
Subject: [Haskell-cafe] [Fwd: profiling in haskell]
In-Reply-To: <4683d9370809101242o2cec6143i4ea9eae35229d203@mail.gmail.com>
References: <48C5BBE0.6060509@73rus.com>	
	<4683d9370809091225h62d585c6x463f56c956d25add@mail.gmail.com>	
	<48C8208F.1030305@73rus.com>
	<4683d9370809101242o2cec6143i4ea9eae35229d203@mail.gmail.com>
Message-ID: <48CADF68.5000108@73rus.com>

Tim Chevalier wrote:
> When you build your own code with -prof, GHC automatically links in
> profiling versions of the standard libraries. However, its profiling
> libraries were not built with -auto-all (the reason is that adding
> cost centres interferes with optimization). To build the libraries
> with -auto-all, you would need to build GHC from sources, which is not
> for the faint of heart. However, the results of doing that aren't
> usually very enlightening anyway -- for example, foldr might be called
> from many different places, but you might only care about a single
> call site (and then you can annotate that call site).
>   

Hmm, okay -- that makes some sense.

> Just from looking, I would guess this is the culprit:
>
>   
>>   termToStr t il =
>>     {-# SCC "termToStr" #-} ((:) ("t " ++ t ++ " " ++ (foldl ilItemToStr ""
>> il)))
>>
>>     
>
> If you want to be really sure, you can rewrite this as:
>
>  termToStr t il =
>      {-# SCC "termToStr" #-} ((:) ("t " ++ t ++ " " ++ ({-# SCC
> "termToStr_foldl" #-} foldl ilItemToStr ""
>  il)))
>
> and that will give you a cost centre measuring the specific cost of
> the invocation of foldl.
>   

I did that and found out that it accounts for only about 0.6 percent of 
the running time. Changing fold to fold' does improve it, though overall 
it's not that significant (again, since it's not the bottleneck).

I just realized that most of the time is spent inside 'serialize' and 
not inherited as I originally claimed. Here is how my current code and 
profiling output look like:

http://hpaste.org/10329

How do I figure out what exactly in 'serialize' takes so much time?

-- 
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com

From ntupel at googlemail.com  Fri Sep 12 18:24:54 2008
From: ntupel at googlemail.com (ntupel)
Date: Fri Sep 12 18:22:38 2008
Subject: [Haskell-cafe] Text.JSON idiomatic use
Message-ID: <1221258294.15842.6.camel@localhost>

As a follow up to my previous JSON serialization post I came up with a
first draft of some simple record type serialization/deserialization. 

What I would like to know is, whether this is the right approach or what
better ways there are to make a custom data type an instance of class
JSON. Any chance to reduce the amount of boilerplate required to do
this? I would be grateful for any feedback (also general style comments
are much appreciated).

Many thanks!




module Test where

import Text.JSON

data Message =
    Error {
        event   :: String,
        channel :: String,
        id      :: String,
        cause   :: String,
        message :: String}
  | Join {
        event   :: String,
        channel :: String,
        id      :: String,
        name    :: String}
  | Leave {
        event   :: String,
        channel :: String,
        id      :: String,
        really  :: Bool}
  deriving (Eq, Show, Read)

asJSString :: String -> JSValue
asJSString = JSString . toJSString

asString :: JSValue -> String
asString (JSString s) = fromJSString s

asBool :: JSValue -> Bool
asBool (JSBool b) = b


showErrorJSON, showJoinJSON, showLeaveJSON :: Message -> JSValue

showErrorJSON (Test.Error evt cha id cau msg) =
    showJSON $ toJSObject [("event", evt), ("channel", cha), ("id", id), ("cause", cau), ("message", msg)]

showJoinJSON (Join evt cha id nme) =
    showJSON $ toJSObject [("event", evt), ("channel", cha), ("id", id), ("name", nme)]

showLeaveJSON (Leave evt cha id rly) =
    showJSON $ toJSObject [("event", asJSString evt), ("channel", asJSString cha), ("id", asJSString id), ("really", JSBool rly)]


createMessage, readErrorJSON, readJoinJSON, readLeaveJSON :: [(String, JSValue)] -> Maybe Message

readErrorJSON xs = do
    evt <- lookup "event" xs
    cha <- lookup "channel" xs
    id  <- lookup "id" xs
    cau <- lookup "cause" xs
    msg <- lookup "message" xs
    Just (Test.Error (asString evt) (asString cha) (asString id) (asString cau) (asString msg))

readJoinJSON xs = do
    evt <- lookup "event" xs
    cha <- lookup "channel" xs
    id  <- lookup "id" xs
    nme <- lookup "name" xs
    Just (Join (asString evt) (asString cha) (asString id) (asString nme))

readLeaveJSON xs = do
    evt <- lookup "event" xs
    cha <- lookup "channel" xs
    id  <- lookup "id" xs
    rly <- lookup "really" xs
    Just (Leave (asString evt) (asString cha) (asString id) (asBool rly))

createMessage obj = do
    evt <- lookup "event" obj
    case asString evt of
        "/error"  -> readErrorJSON obj
        "/me/add" -> readJoinJSON obj
        "/me/remove" -> readLeaveJSON obj
        _ -> Nothing

instance JSON Message where
    showJSON x@(Test.Join    _ _ _ _) = showJoinJSON x
    showJSON x@(Test.Leave   _ _ _ _) = showLeaveJSON x
    showJSON x@(Test.Error _ _ _ _ _) = showErrorJSON x

    readJSON (JSObject o) = 
        case createMessage . fromJSObject $ o of
            Just m  -> Ok m
            Nothing -> Text.JSON.Error "Parsing failed."

    readJSON _ = Text.JSON.Error "Records must be JSObjects"


From marco-oweber at gmx.de  Fri Sep 12 18:51:34 2008
From: marco-oweber at gmx.de (Marc Weber)
Date: Fri Sep 12 18:49:18 2008
Subject: [Haskell-cafe] do like notation works fine when using ghc head
In-Reply-To: <2608b8a80809020625vbd6fefey4929afc71cb30381@mail.gmail.com>
References: <20080830015846.GB7458@gmx.de> <20080831215054.GA9353@gmx.de>
	<20080901031024.GC9353@gmx.de> <20080902041256.GC8956@gmx.de>
	<2608b8a80809020625vbd6fefey4929afc71cb30381@mail.gmail.com>
Message-ID: <20080912225134.GA27403@gmx.de>

> There is also the combinator approach of Text.Html, which
> gives you a syntax similar to (3) but without abusing "do":
> 
> (rootElt ! [xmlns "http://www.w3.org/1999/xhtml",
>            lang "en-US" >> xml:lang "en-US"]) $ concatXml
>   [head $ title $ text "minimal"
>   ,body $ concatXml
>     [h1 $ text "minimal"
>     ,div $ text $ "args passed to this program: " ++ (show args)
>     ]
>   ]

Keep in mind that my library tries to do real DTD type checking.
This means that 
  body, h1, div
all have different types. So they can't easily be put into a list.
And yes: I care about each character I have to type less :-)
About IO (). IO was just a poor man example to show that you can nest
arbitrary monads. Have a look at the WASH library to see in which
wonderful ways this can be used..

One working snippet from the testXHTML.hs sample file provided by the
lib:

        #include "vxmldos.h"
          tDo $ runHtmlDoc $ vdo
            head $ title $ text "text"
            body $ vdo
              script $ X.type "text/javascript" >> text "document.writeln('hi');"
              h2 $ text "That's a headline, hello and how do you do?"
              -- br e   eg a 
 is not allowed here
              div $ vdo
                onclick "alert('clicked');"
                styleA "color:#F79"
                text "text within the div"
              div e
              return "That's nice, isn't it?"

vxmldos.h defines a vdo cpp macro which expands to
let .... ; in $ do
where ... rebinds >>=, >>, lift to make this work (in with ghc head)

The library can now cope with fancy dts such as (a*)* etc as well
If you still find bugs let me know.

The more interesting part starts now: figuring out how do build a nice
HTML library on top of this all.

Sincerly
Marc Weber
From dbueno at gmail.com  Fri Sep 12 19:05:50 2008
From: dbueno at gmail.com (Denis Bueno)
Date: Fri Sep 12 19:03:31 2008
Subject: [Haskell-cafe] Tons of retainers when inserting 611,
	756 elements into a Trie
Message-ID: <6dbd4d000809121605l4cbc0bb7nb0b76acc0639c92a@mail.gmail.com>

Dear haskell-cafe,

I've got an anagram-finder ("puzzler") that uses a "dictionary" datatype, which
in turn uses a trie.  In src/hs/Main.hs, I create a new dictionary from a word
list (a file containing one word per line) and perform a query on it in order to
force it to actually load something from disk.  By problem is that though my
word list is just shy of 7MB, puzzler occupies nearly 1GB of resident memory as
soon as the dictionary is loaded.  I'm using GHC 6.8.3 and Gtk2hs 0.9.13 on OS X
10.4.11.

To see for yourself, check out the code with git and run it:

    $ git clone git://github.com/dbueno/puzzler.git
    $ git checkout -b origin/bsbench
    $ cabal configure              # needs gtk2hs
    $ cabal build
    $ ./dist/build/puzzler/puzzler # look at the resident memory

Retainer profiling (attachment "puzzler-hr.pdf") shows that `insertWith' on my
trie is responsible for most of the memory.  As you will see, in
`makeDictionary' I try to strictly apply the combining function to combat these
retainers.  But the problem doesn't go away.

More strangely: puzzler has a second executable, puzzler-test, which runs unit
tests, including loading the exact same anagram query. However, puzzler-test
never uses more than 250MB or so.

The dictionary (in module Puzzler.Anagram) is an array of bytestrings paired
with a Trie mapping bytestrings to sets of indices in the array.

> data Dictionary = Dictionary
>     { dictWords :: Words
>     , sortWords :: Trie IntSet }
> type Words = Array Int ByteString

The Trie is a custom bytestring trie datatype.  Each level is mapped to by the
character it represents.  If that character is a terminal character for some
word (Right (t,x)), then that word maps to x.  Otherwise no word ends at that
character, but there may be longer words, so the trie continues with (Left t).

> newtype Trie a = Trie { unTrie :: IntMap (Either (Trie a) (Trie a, a)) }
>     deriving (Eq, Ord, Show)

The following is where _I think_ the error lies (src/hs/Puzzler/Anagram.hs):

> -- | Creates an anagram dictionary from a file of words, one per line.  The
> -- words may be compound, as long as there is one per line.
> createDictionary :: FilePath -> IO Dictionary
> createDictionary path = (makeDictionary . lines) `liftM` readFile path
>
> -- | Makes an anagram dictionary from a list of words.
> makeDictionary :: [ByteString] -> Dictionary
> makeDictionary ws = Dictionary
>     { dictWords = dw
>     , sortWords = go end Trie.empty }
>   where
>     dw = listArray (0, length ws - 1) ws ; (begin, end) = bounds dw
>     go i t | seq t $ False = undefined
>            | i < begin = t
>            | otherwise = go (i-1)
>                          -- $ Trie.insertWith Set.union (BS.sort (dw!i)) (Set.singleton i) t
>                          $ insertWith' Set.union (BS.sort (dw!i)) (Set.singleton i) t
>
>     insertWith' f k v m | seq k $ False = undefined
>     insertWith' f k v m = case Trie.lookup k m of
>           Nothing -> Trie.insert k v m
>           Just s  -> (Trie.insert k $! f v s) m

I've been scouring haskell-cafe for similar issues, and all seem to have been
solved by a function similar to my `insertWith''.  Uncommenting
`Trie.insertWith'
and commenting out the rest doesn't appear to differ noticeably in memory
consumption.  The implementation of `Trie.insertWith' is:

> insertWith :: (a -> a -> a) -> ByteString -> a -> Trie a -> Trie a
> insertWith f bs x t@(Trie m) = case uncons bs of
>       Nothing      -> t
>       Just (c, cs) -> Trie (Map.alter myAlter (ord c) m)
>         where
>           myAlter Nothing               = Just $ cons (insertWith f cs x empty, x)
>           myAlter (Just (Left  t))      = Just $ cons (insertWith f cs x t, x)
>           myAlter (Just (Right (t,x'))) =
>               Just $ Right (insertWith f cs x t, if isLast then f x x' else x')
>
>           -- If `cs' is empty then `c' is the last char of the word to insert;
>           -- that is, we're done.
>           cons (t, x) = if isLast then Right (t, x) else Left t
>           isLast = BS.null cs

Any ideas?

                              Denis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: puzzler-hr.pdf
Type: application/pdf
Size: 17099 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080912/3869b8a8/puzzler-hr.pdf
From jason.dusek at gmail.com  Fri Sep 12 19:35:36 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Fri Sep 12 19:33:16 2008
Subject: [Haskell-cafe] uuid package on OS X
Message-ID: <42784f260809121635h3df9d8fep1dfb599625e5cff0@mail.gmail.com>

  The UUID package builds and runs fine on OS X without any need
  for `e2fsprog` -- just remove the `extra-libs` line from the
  Cabal file. (Apple put the UUID stuff in `libc`.) Has anyone
  tried to build it on Windows?

--
_jsn

 |...UUID package...|
  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uuid
From catamorphism at gmail.com  Fri Sep 12 20:38:05 2008
From: catamorphism at gmail.com (Tim Chevalier)
Date: Fri Sep 12 20:35:46 2008
Subject: [Haskell-cafe] [Fwd: profiling in haskell]
In-Reply-To: <48CADF68.5000108@73rus.com>
References: <48C5BBE0.6060509@73rus.com>
	<4683d9370809091225h62d585c6x463f56c956d25add@mail.gmail.com>
	<48C8208F.1030305@73rus.com>
	<4683d9370809101242o2cec6143i4ea9eae35229d203@mail.gmail.com>
	<48CADF68.5000108@73rus.com>
Message-ID: <4683d9370809121738n11cb5f93o7d9269d630f557ae@mail.gmail.com>

On Fri, Sep 12, 2008 at 2:30 PM, Vlad Skvortsov  wrote:
> How do I figure out what exactly in 'serialize' takes so much time?
>

At this point, I don't know any more -- I can't see what inherited
costs serialize could have that don't come from one of the cost
centres you've inserted, either. Perhaps you could try the
glasgow-haskell-users mailing list, where people interested in this
are more likely to be reading carefully...

Cheers,
Tim

--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.
From duncan.coutts at worc.ox.ac.uk  Fri Sep 12 20:51:12 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Sep 12 20:47:24 2008
Subject: [Haskell-cafe] Erroneous package listings in hackage?
In-Reply-To: 
References: <2d3641330809120421l2731f07bqf14799165ef43b56@mail.gmail.com>
	
Message-ID: <1221267072.5395.100.camel@localhost>

On Fri, 2008-09-12 at 14:18 +0200, Henk-Jan van Tuyl wrote:
> On Fri, 12 Sep 2008 13:21:59 +0200, Dougal Stanton  

> > $ cabal list | less
> >  ...
> >  * cairo
> >       Latest version installed: 0.9.13
> >       Homepage: http://haskell.org/gtk2hs/
> >       License:  BSD3
> >  ...
> > $ cabal install cairo
> > cabal: There is no package named cairo
> >
> > I must admit I was surprised to see a gtk2hs module on Hackage, but
> > not half as surprised when I found it wasn't there after all...

> There is clearly something wrong here; there is also a package named gtk  
> that is listed with "cabal list" but cannot be downloaded.

There is nothing wrong, but perhaps the output is not very clear. Here's
what it says about packages are are installed *and* available on
hackage:

 * zlib
      Latest version available: 0.4.0.4
      Latest version installed: 0.4.0.4
      Synopsis: Compression and decompression in the gzip and zlib formats
      License:  BSD3

Where as for cairo and gtk you'll notice that it does not list any
available version.

Perhaps for packages that are installed but not re-installable via Cabal
(like cairo, base, ghc etc) it should say something. Do you have any
specific suggestions?

Duncan

From cetin.sert at gmail.com  Fri Sep 12 21:55:02 2008
From: cetin.sert at gmail.com (Cetin Sert)
Date: Fri Sep 12 21:52:42 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
Message-ID: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>

Hi,

The following piece of code runs just fine, if I say:

instance Random RGB where
  random  = color
  randomR = colorR

instead of:

instance Random RGB where
  random  = color2
  randomR = colorR

When I use random  = color2 I encounter a stack space overflow:

cetin@linux-d312:~/lab/test/colors> ./var2 +RTS -K30000000
Stack space overflow: current size 30000000 bytes.
Use `+RTS -Ksize' to increase it.

I think I'm doing something wrong with the definition of colorR.

Can anyone explain me what's wrong?

import GHC.Word
import Data.Word
import System.Random
import System.Random.Mersenne.Pure64

type RGB = (Int,Int,Int)

instance Bounded RGB where
  minBound = minRGB
  maxBound = maxRGB

minRGB = (0  ,0  ,0  )
maxRGB = (255,255,255)

instance Random RGB where
  random  = color2
  randomR = colorR

color2 :: RandomGen g ? g ? (RGB,g)
color2 = colorR (minRGB,maxRGB)

color :: RandomGen g ? g ? (RGB,g)
color s0 = ((r,g,b),s3)
  where
    (r,s1) = q s0
    (g,s2) = q s1
    (b,s3) = q s2
    q = randomR (0,255)

colorR :: RandomGen g ? (RGB,RGB) ? g ? (RGB,g)
colorR ((a,b,c),(x,y,z)) s0 = ((r,g,b),s3)
  where
    (r,s1) = q (a,x) s0
    (g,s2) = q (b,y) s1
    (b,s3) = q (c,z) s2
    q = randomR

main :: IO ()
main = do
  mt ? newPureMT
  let cs = randoms mt :: [RGB]
  print cs

------------------------------------------

This one also just works fine:

import Data.Word
import System.Random.Mersenne

type RGB = (Word8,Word8,Word8)

instance MTRandom RGB where
  random m = do
    r ? random m :: IO Word8
    g ? random m :: IO Word8
    b ? random m :: IO Word8
    return (r,g,b)

main :: IO ()
main = do
  g  ? newMTGen Nothing
  cs ? randoms g :: IO [RGB]
  print cs

but I really need the range constraints colorR might provide me and would
greatly appreciate any help to understand/solve the issue.

Best Regards,
Cetin

P/s:
uname -a
Linux linux-d312 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200
x86_64 x86_64 x86_64 GNU/Linux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/b6271a65/attachment.htm
From dons at galois.com  Fri Sep 12 21:57:37 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 12 21:55:12 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
Message-ID: <20080913015737.GB18949@scytale.galois.com>

cetin.sert:
>      random  = color2
>      randomR = colorR
> 
>    color2 :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>    color2 = colorR (minRGB,maxRGB)
> 
>    color :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>    color s0 = ((r,g,b),s3)
>      where

^^^^^^^^^^

There's some corruption in this text. Could you post the file somewhere?

-- Don
From cetin.sert at gmail.com  Fri Sep 12 22:05:34 2008
From: cetin.sert at gmail.com (Cetin Sert)
Date: Fri Sep 12 22:03:15 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <20080913015737.GB18949@scytale.galois.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913015737.GB18949@scytale.galois.com>
Message-ID: <1ff5dedc0809121905q502aa964j5f9cc7516c88796b@mail.gmail.com>

Oh, hi *^o^*

mersenne.pure64
http://sert.homedns.org/lab/colors/var2.hs

mersenne
http://sert.homedns.org/lab/colors/var.hs

the problem seems to be with the definition of colorR in var2.hs

CS

2008/9/13 Don Stewart 

> cetin.sert:
> >      random  = color2
> >      randomR = colorR
> >
> >    color2 :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
> >    color2 = colorR (minRGB,maxRGB)
> >
> >    color :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
> >    color s0 = ((r,g,b),s3)
> >      where
>
> ^^^^^^^^^^
>
> There's some corruption in this text. Could you post the file somewhere?
>
> -- Don
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/2cb98e6f/attachment.htm
From dons at galois.com  Fri Sep 12 22:06:48 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 12 22:04:21 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <1ff5dedc0809121905q502aa964j5f9cc7516c88796b@mail.gmail.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913015737.GB18949@scytale.galois.com>
	<1ff5dedc0809121905q502aa964j5f9cc7516c88796b@mail.gmail.com>
Message-ID: <20080913020648.GC18949@scytale.galois.com>

Oh, you've got unicode source. What's the flag to get this to actually
compile? (Note to readers, using extensions , you should always include
the LANGUAGE pragmas required to build the file when asking for help :)

How are you compiling this?

-- Don

cetin.sert:
>    Oh, hi *^o^*
> 
>    mersenne.pure64
>    [1]http://sert.homedns.org/lab/colors/var2.hs
> 
>    mersenne
>    [2]http://sert.homedns.org/lab/colors/var.hs
> 
>    the problem seems to be with the definition of colorR in var2.hs
> 
>    CS
> 
>    2008/9/13 Don Stewart <[3]dons@galois.com>
> 
>      cetin.sert:
>      >      random  = color2
>      >      randomR = colorR
>      >
>      >    color2 :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>      >    color2 = colorR (minRGB,maxRGB)
>      >
>      >    color :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>      >    color s0 = ((r,g,b),s3)
>      >      where
> 
>      ^^^^^^^^^^
> 
>      There's some corruption in this text. Could you post the file somewhere?
>      -- Don
> 
> References
> 
>    Visible links
>    1. http://sert.homedns.org/lab/colors/var2.hs
>    2. http://sert.homedns.org/lab/colors/var.hs
>    3. mailto:dons@galois.com
From bertram.felgenhauer at googlemail.com  Fri Sep 12 22:14:24 2008
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Fri Sep 12 22:12:10 2008
Subject: [Haskell-cafe] random colors, stack space overflow, mersenne
	and mersenne.pure64
In-Reply-To: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
Message-ID: <20080913021424.GB4976@zombie.inf.tu-dresden.de>

Cetin Sert wrote:
[snip]
> colorR :: RandomGen g ? (RGB,RGB) ? g ? (RGB,g)
> colorR ((a,b,c),(x,y,z)) s0 = ((r,g,b),s3)
>   where
>     (r,s1) = q (a,x) s0
>     (g,s2) = q (b,y) s1
>     (b,s3) = q (c,z) s2
>     q = randomR

Look closely at how you use the variable 'b'.

HTH,

Bertram
From cetin.sert at gmail.com  Fri Sep 12 22:15:16 2008
From: cetin.sert at gmail.com (Cetin Sert)
Date: Fri Sep 12 22:12:55 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <20080913020648.GC18949@scytale.galois.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913015737.GB18949@scytale.galois.com>
	<1ff5dedc0809121905q502aa964j5f9cc7516c88796b@mail.gmail.com>
	<20080913020648.GC18949@scytale.galois.com>
Message-ID: <1ff5dedc0809121915r4bfd2be4tdd2295621d11e29e@mail.gmail.com>

Oh, sorry... ^__^"

ghc -fglasgow-exts -O2 --make var
ghc -fglasgow-exts -O2 --make var2

I've not used pragmas in any source file o_O so far... should go fix that
sometime. Thanks for reminding...

Using ghc 6.8.3, mersenne-random-0.1.3 and mersenne-random-pure64-0.2.0.2.
(Cause I could not find out how to check things out with darcs from hackage
o__O google was not very helpful there so I used the latest tar packages.)

@don: sorry I sent my reply twice only to you and then to the list and
you... it's because of gmail... I'll be very careful not to repeat my
mistake.


2008/9/13 Don Stewart 

> Oh, you've got unicode source. What's the flag to get this to actually
> compile? (Note to readers, using extensions , you should always include
> the LANGUAGE pragmas required to build the file when asking for help :)
>
> How are you compiling this?
>
> -- Don
>
> cetin.sert:
> >    Oh, hi *^o^*
> >
> >    mersenne.pure64
> >    [1]http://sert.homedns.org/lab/colors/var2.hs
> >
> >    mersenne
> >    [2]http://sert.homedns.org/lab/colors/var.hs
> >
> >    the problem seems to be with the definition of colorR in var2.hs
> >
> >    CS
> >
> >    2008/9/13 Don Stewart <[3]dons@galois.com>
> >
> >      cetin.sert:
> >      >      random  = color2
> >      >      randomR = colorR
> >      >
> >      >    color2 :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
> >      >    color2 = colorR (minRGB,maxRGB)
> >      >
> >      >    color :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
> >      >    color s0 = ((r,g,b),s3)
> >      >      where
> >
> >      ^^^^^^^^^^
> >
> >      There's some corruption in this text. Could you post the file
> somewhere?
> >      -- Don
> >
> > References
> >
> >    Visible links
> >    1. http://sert.homedns.org/lab/colors/var2.hs
> >    2. http://sert.homedns.org/lab/colors/var.hs
> >    3. mailto:dons@galois.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/dab75938/attachment.htm
From dons at galois.com  Fri Sep 12 22:16:58 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 12 22:14:32 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <20080913021424.GB4976@zombie.inf.tu-dresden.de>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913021424.GB4976@zombie.inf.tu-dresden.de>
Message-ID: <20080913021658.GD18949@scytale.galois.com>

bertram.felgenhauer:
> Cetin Sert wrote:
> [snip]
> > colorR :: RandomGen g ? (RGB,RGB) ? g ? (RGB,g)
> > colorR ((a,b,c),(x,y,z)) s0 = ((r,g,b),s3)
> >   where
> >     (r,s1) = q (a,x) s0
> >     (g,s2) = q (b,y) s1
> >     (b,s3) = q (c,z) s2
> >     q = randomR
> 
> Look closely at how you use the variable 'b'.

:-) fast eyes.

Btw, Cetin, this is good practice, along with -funbox-strict-fields:

    data RGB = RGB !Int !Int !Int
        deriving Show

Much better code than using a lazy triple.
From cetin.sert at gmail.com  Fri Sep 12 22:23:58 2008
From: cetin.sert at gmail.com (Cetin Sert)
Date: Fri Sep 12 22:21:37 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <20080913021658.GD18949@scytale.galois.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913021424.GB4976@zombie.inf.tu-dresden.de>
	<20080913021658.GD18949@scytale.galois.com>
Message-ID: <1ff5dedc0809121923k11d62f5fxe36830d82c18b963@mail.gmail.com>

Oh thank you both *^o^*... now works like a charm again.

Btw, Cetin, this is good practice, along with -funbox-strict-fields:

   data RGB = RGB !Int !Int !Int
       deriving Show

Much better code than using a lazy triple.

Where can I read more of such good practice? Looking forward to Real World
Haskell to read lots of code, hope it'll help lots of people interested in
learning haskell. (Will be released around Christmas here in Germany, I
think.)

CS

2008/9/13 Don Stewart 

> bertram.felgenhauer:
> > Cetin Sert wrote:
> > [snip]
> > > colorR :: RandomGen g ? (RGB,RGB) ? g ? (RGB,g)
> > > colorR ((a,b,c),(x,y,z)) s0 = ((r,g,b),s3)
> > >   where
> > >     (r,s1) = q (a,x) s0
> > >     (g,s2) = q (b,y) s1
> > >     (b,s3) = q (c,z) s2
> > >     q = randomR
> >
> > Look closely at how you use the variable 'b'.
>
> :-) fast eyes.
>
> Btw, Cetin, this is good practice, along with -funbox-strict-fields:
>
>    data RGB = RGB !Int !Int !Int
>        deriving Show
>
> Much better code than using a lazy triple.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/5aeb9bfb/attachment.htm
From dons at galois.com  Fri Sep 12 22:27:21 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 12 22:24:56 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <1ff5dedc0809121923k11d62f5fxe36830d82c18b963@mail.gmail.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913021424.GB4976@zombie.inf.tu-dresden.de>
	<20080913021658.GD18949@scytale.galois.com>
	<1ff5dedc0809121923k11d62f5fxe36830d82c18b963@mail.gmail.com>
Message-ID: <20080913022721.GE18949@scytale.galois.com>

cetin.sert:
>    Where can I read more of such good practice? Looking forward to Real World
>    Haskell to read lots of code, hope it'll help lots of people interested in
>    learning haskell. (Will be released around Christmas here in Germany, I
>    think.)

Yeah, that's right. November some time.

There's a chapter that talks about performance and data structures,

    http://book.realworldhaskell.org/read/profiling-and-optimization.html
From allbery at ece.cmu.edu  Fri Sep 12 22:28:38 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Fri Sep 12 22:26:27 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <20080913015737.GB18949@scytale.galois.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913015737.GB18949@scytale.galois.com>
Message-ID: <047E24EF-F9AA-4A06-9D93-8B0FF395E399@ece.cmu.edu>

On 2008 Sep 12, at 21:57, Don Stewart wrote:
> cetin.sert:
>>     random  = color2
>>     randomR = colorR
>>
>>   color2 :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>>   color2 = colorR (minRGB,maxRGB)
>>
>>   color :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>>   color s0 = ((r,g,b),s3)
>>     where
>
> There's some corruption in this text. Could you post the file  
> somewhere?

It's not corrupt; he used UTF-8 symbols.  It shows up properly in  
Mail.app but doesn't quote right (admittedly I force plaintext).

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From cjs at starling-software.com  Fri Sep 12 22:29:10 2008
From: cjs at starling-software.com (Curt Sampson)
Date: Fri Sep 12 22:26:50 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <48CAC309.9040708@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
	<48CAC309.9040708@btinternet.com>
Message-ID: <20080913022909.GA9703@lucky.cynic.net>

On 2008-09-12 20:29 +0100 (Fri), Andrew Coppin wrote:

> Looks like the only thing it doesn't do is let you change the title
> on the console window. (Because, obviously, that's only possible on
> Windows.)

Right. Unless you send an ^[^H]0;foo^G sequence (^[ being ESC) to your
xterm. You'll find that the title changes to "foo".

cjs
-- 
Curt Sampson               +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com
From cetin.sert at gmail.com  Fri Sep 12 23:34:45 2008
From: cetin.sert at gmail.com (Cetin Sert)
Date: Fri Sep 12 23:32:24 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <047E24EF-F9AA-4A06-9D93-8B0FF395E399@ece.cmu.edu>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913015737.GB18949@scytale.galois.com>
	<047E24EF-F9AA-4A06-9D93-8B0FF395E399@ece.cmu.edu>
Message-ID: <1ff5dedc0809122034i340a3b94y48fbde2ce6f3effa@mail.gmail.com>

main :: IO ()
main = do
  as <- getArgs
  mt <- newPureMT
  let colors = randomRs (lo,hi) mt :: [RGB]
  print $ zip tx cs
  where
    lo = read $ as !! 0
    hi = read $ as !! 1
    tx =        as !! 2

Why is as not visible in the where block?

2008/9/13 Brandon S. Allbery KF8NH 

> On 2008 Sep 12, at 21:57, Don Stewart wrote:
>
>> cetin.sert:
>>
>>>    random  = color2
>>>    randomR = colorR
>>>
>>>  color2 :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>>>  color2 = colorR (minRGB,maxRGB)
>>>
>>>  color :: RandomGen g .$B"M.(B g .$B"*.(B (RGB,g)
>>>  color s0 = ((r,g,b),s3)
>>>    where
>>>
>>
>> There's some corruption in this text. Could you post the file somewhere?
>>
>
> It's not corrupt; he used UTF-8 symbols.  It shows up properly in Mail.app
> but doesn't quote right (admittedly I force plaintext).
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
> electrical and computer engineering, carnegie mellon university    KF8NH
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/b59a8448/attachment.htm
From dagit at codersbase.com  Fri Sep 12 23:35:32 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Fri Sep 12 23:33:10 2008
Subject: [Haskell-cafe] Hackage needs a theme song!
Message-ID: 

I realized tonight that Hackage needs a theme song.  Here is my
attempt at it, apologies to Jefferson Starship:

We built this hackage,
We built this hackage on lambda and types

Say you don't know me, or the parameters I pass
Say you don't care who instances this type class
Knee deep in the thunk, value infinitely big
Too many constraints eating up the type sig

Main runs the Monad,
Listen to the Reader
Don't you remember?
We built this hackage
We built this hackage on lambda and types!
We built this hackage, we built this hackage on lambda and types
Built this hackage, we built this hackage on lambda and types

Someone always playing package games
Who cares they're always changing package names
We just want to compile here, someone stole the type hack
They call us lazy, evaluate us off the stack

Main runs the Monad,
Listen to the Reader
Don't you remember?
We built this hackage
We built this hackage on lambda and types!
We built this hackage, we built this hackage on lambda and types
Built this hackage, we built this hackage on lambda and types

It's just another version in our release style
Cabal has got the build deps, and we upload the file

Who counts the downloads underneath package node
Who writes the type errors into our source code
Don't tell us you need us, 'cause we're the db of tools
Looking for pragmas, crawling through your RULES

Don't you remember ...

Main runs the Monad,
Listen to the Reader -
Don't you remember?
We built this hackage,
We built this hackage on lambda and types
We built this hackage, we built this hackage on lambda and types
Built this hackage, we built this hackage on lambda and types
Built this hackage, we built this hackage on lambda and types
Built this hackage, we built this hackage on lambda and types

We built, we built this hackage yeah
We built this hackage
We built, we built this hackage
(Repeat - fade)
From dons at galois.com  Fri Sep 12 23:53:18 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 12 23:50:51 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <1ff5dedc0809122034i340a3b94y48fbde2ce6f3effa@mail.gmail.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913015737.GB18949@scytale.galois.com>
	<047E24EF-F9AA-4A06-9D93-8B0FF395E399@ece.cmu.edu>
	<1ff5dedc0809122034i340a3b94y48fbde2ce6f3effa@mail.gmail.com>
Message-ID: <20080913035318.GF18949@scytale.galois.com>

cetin.sert:

>    main :: IO ()
>    main = do
>      as <- getArgs
>      mt <- newPureMT
>      let colors = randomRs (lo,hi) mt :: [RGB]
>      print $ zip tx cs
>      where
>        lo = read $ as !! 0
>        hi = read $ as !! 1
>        tx =        as !! 2
>    Why is as not visible in the where block?

Same as:

     main =
       let
         lo = read $ as !! 0
         hi = read $ as !! 1
         tx =        as !! 2
       in do
         as <- getArgs
         mt <- newPureMT
         let colors = randomRs (lo,hi) mt :: [RGB]
         print $ zip tx cs

If that helps think about when things are bound.

-- Don
From dagit at codersbase.com  Sat Sep 13 00:01:30 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Fri Sep 12 23:59:11 2008
Subject: [Haskell-cafe] random colors, stack space overflow,
	mersenne and mersenne.pure64
In-Reply-To: <20080913035318.GF18949@scytale.galois.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>
	<20080913015737.GB18949@scytale.galois.com>
	<047E24EF-F9AA-4A06-9D93-8B0FF395E399@ece.cmu.edu>
	<1ff5dedc0809122034i340a3b94y48fbde2ce6f3effa@mail.gmail.com>
	<20080913035318.GF18949@scytale.galois.com>
Message-ID: 

On Fri, Sep 12, 2008 at 8:53 PM, Don Stewart  wrote:
> cetin.sert:
>
>>    main :: IO ()
>>    main = do
>>      as <- getArgs
>>      mt <- newPureMT
>>      let colors = randomRs (lo,hi) mt :: [RGB]
>>      print $ zip tx cs
>>      where
>>        lo = read $ as !! 0
>>        hi = read $ as !! 1
>>        tx =        as !! 2
>>    Why is as not visible in the where block?
>
> Same as:
>
>     main =
>       let
>         lo = read $ as !! 0
>         hi = read $ as !! 1
>         tx =        as !! 2
>       in do
>         as <- getArgs
>         mt <- newPureMT
>         let colors = randomRs (lo,hi) mt :: [RGB]
>         print $ zip tx cs
>
> If that helps think about when things are bound.

And you probably want this rewrite (untested):
    main :: IO ()
    main = do
      as <- getArgs
      let lo = read $ as !! 0
           hi = read $ as !! 1
           tx = as !! 2
      mt <- newPureMT
      let colors = randomRs (lo,hi) mt :: [RGB]
      print $ zip tx cs

My indentation may be a bit off as I didn't use a fixed width font to type it.

Jason
From jgoerzen at complete.org  Sat Sep 13 00:39:27 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Sat Sep 13 00:37:14 2008
Subject: [Haskell-cafe] ANN: Twidge
Message-ID: <20080913043927.GA15452@complete.org>

Hi folks,

I've released Twidge, a command-line Twitter and Identi.ca client,
written -- of course -- in Haskell.  I'm pretty excited about it, but
then hey, I'm biased.

Anyhow, it's available from Hackage or from the homepage at:

 http://software.complete.org/twidge

I've also got links to its (11-page!) manual as well as some HOWTOs
and FAQs on the wiki at the above URL.

Comments, patches welcome.  Feel free to reply here or send them to
@jgoerzen.

-- John
From allbery at ece.cmu.edu  Sat Sep 13 01:02:04 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sat Sep 13 00:59:50 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <20080913022909.GA9703@lucky.cynic.net>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
	<48CAC309.9040708@btinternet.com>
	<20080913022909.GA9703@lucky.cynic.net>
Message-ID: <27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>

On 2008 Sep 12, at 22:29, Curt Sampson wrote:
> On 2008-09-12 20:29 +0100 (Fri), Andrew Coppin wrote:
>
>> Looks like the only thing it doesn't do is let you change the title
>> on the console window. (Because, obviously, that's only possible on
>> Windows.)
>
> Right. Unless you send an ^[^H]0;foo^G sequence (^[ being ESC) to your
> xterm. You'll find that the title changes to "foo".


0 = both title and icon
1 = icon name
2 = titlebar text

Most X11 terminal emulators use the same protocol.  (ISTR that dtterm  
doesn't, but I don't think most people care any more.)  One other  
gotcha is that Terminal.app on Leopard (dunno about Tiger) treats 0,  
1, 2 the same way so if you set the icon name after the title you end  
up with the icon name in the titlebar.  (OSX uses the titlebar text as  
the icon name when minimized.)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From jeffzaroyko at gmail.com  Sat Sep 13 03:03:03 2008
From: jeffzaroyko at gmail.com (Jeff Zaroyko)
Date: Sat Sep 13 03:00:52 2008
Subject: [Haskell-cafe] Re: Windows details
References: <48C6AECE.3020905@btinternet.com>	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>	<48C6C17C.1040000@btinternet.com>		<48C97068.7010201@btinternet.com>
	
	<48CAA2DE.3080701@btinternet.com>
Message-ID: 

Andrew Coppin  btinternet.com> writes:

> 
> Jeff Zaroyko wrote:
> > Andrew Coppin  btinternet.com> writes:
> >
> >   
> >> Jeff Zaroyko wrote:
> >>     
> >>> In theory, you should be able to use mingw's windres tool to produce
> >>> an object file from the resource definition which you'd link with 
> >>> the rest of your program.
> >>>
> I literally cannot *believe* how hard it is to put a few little words 
> into that version tab... Every other kind of resource seems to be 
> completely trivial, but this just won't work for toffee!
> 

I'm sure you'll work something out, my test worked, I used a .res file I had
lying around from Wine's ddraw.dll, used windres ddraw.res -o version.o to make
an object file then using ghc hello.hs version.o linked it against hello world.

From batterseapower at hotmail.com  Sat Sep 13 05:56:52 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Sat Sep 13 05:54:31 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <48CAC309.9040708@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
	<48CAC309.9040708@btinternet.com>
Message-ID: <9d4d38820809130256u598c81adla21e7eaa1b71227a@mail.gmail.com>

2008/9/12 Andrew Coppin :
> Any ideas about the build log error that's preventing Hackage from
> autogenerating the documentation?

That is a Cabal problem: Duncan Coutts tells me that it is fixed in
HEAD, so documentation will be available on Hackage when they update
the version of Cabal they are using.

Cheers,
Max
From batterseapower at hotmail.com  Sat Sep 13 05:57:32 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Sat Sep 13 05:55:10 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
	<48CAC309.9040708@btinternet.com>
	<20080913022909.GA9703@lucky.cynic.net>
	<27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>
Message-ID: <9d4d38820809130257x4ff17f74wc91598efd5d182bc@mail.gmail.com>

2008/9/13 Brandon S. Allbery KF8NH :
>> Right. Unless you send an ^[^H]0;foo^G sequence (^[ being ESC) to your
>> xterm. You'll find that the title changes to "foo".
>
>
> 0 = both title and icon
> 1 = icon name
> 2 = titlebar text
>
> Most X11 terminal emulators use the same protocol.  (ISTR that dtterm
> doesn't, but I don't think most people care any more.)  One other gotcha is
> that Terminal.app on Leopard (dunno about Tiger) treats 0, 1, 2 the same way
> so if you set the icon name after the title you end up with the icon name in
> the titlebar.  (OSX uses the titlebar text as the icon name when minimized.)

Interesting information. I'll look into adding this to my package then: cheers!

Max
From batterseapower at hotmail.com  Sat Sep 13 06:59:01 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Sat Sep 13 06:56:40 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <9d4d38820809130257x4ff17f74wc91598efd5d182bc@mail.gmail.com>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
	<48CAC309.9040708@btinternet.com>
	<20080913022909.GA9703@lucky.cynic.net>
	<27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>
	<9d4d38820809130257x4ff17f74wc91598efd5d182bc@mail.gmail.com>
Message-ID: <9d4d38820809130359n351905ebx11848448eca63c4@mail.gmail.com>

2008/9/13 Max Bolingbroke :
> Interesting information. I'll look into adding this to my package then: cheers!

Just FYI, I have now implemented and tested this feature. The new
version, 0.5.0, is available on Hackage.

Cheers,
Max
From andrewcoppin at btinternet.com  Sat Sep 13 07:05:07 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sat Sep 13 07:02:41 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <9d4d38820809130359n351905ebx11848448eca63c4@mail.gmail.com>
References: <48C6CB3C.8020006@btinternet.com>	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>	<48CAC309.9040708@btinternet.com>	<20080913022909.GA9703@lucky.cynic.net>	<27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>	<9d4d38820809130257x4ff17f74wc91598efd5d182bc@mail.gmail.com>
	<9d4d38820809130359n351905ebx11848448eca63c4@mail.gmail.com>
Message-ID: <48CB9E63.1060109@btinternet.com>

Max Bolingbroke wrote:
> 2008/9/13 Max Bolingbroke :
>   
>> Interesting information. I'll look into adding this to my package then: cheers!
>>     
>
> Just FYI, I have now implemented and tested this feature. The new
> version, 0.5.0, is available on Hackage.
>   

For both platforms?

Out of interest, how do you get the correct package built on each platform?

From dougal at dougalstanton.net  Sat Sep 13 07:06:19 2008
From: dougal at dougalstanton.net (Dougal Stanton)
Date: Sat Sep 13 07:03:57 2008
Subject: [Haskell-cafe] Erroneous package listings in hackage?
In-Reply-To: <1221267072.5395.100.camel@localhost>
References: <2d3641330809120421l2731f07bqf14799165ef43b56@mail.gmail.com>
	
	<1221267072.5395.100.camel@localhost>
Message-ID: <2d3641330809130406l1c3a08a2n98ccd5edbfe6970c@mail.gmail.com>

On Sat, Sep 13, 2008 at 1:51 AM, Duncan Coutts
 wrote:
> Perhaps for packages that are installed but not re-installable via Cabal
> (like cairo, base, ghc etc) it should say something. Do you have any
> specific suggestions?

Well that explains it then! I had no idea it listed stuff not
available from Hackage. I've been using `cabal list | grep foo` to
search for packages but that's obviously not optimal, it seems.

I don't know what would clarify the matter. An "available from
Hackage: (yes/no)" field? Or a flag to pass to `cabal list` to show
Hackage stuff only?

D

-- 
Dougal Stanton
dougal@dougalstanton.net // http://www.dougalstanton.net
From batterseapower at hotmail.com  Sat Sep 13 08:03:39 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Sat Sep 13 08:01:19 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <48CB9E63.1060109@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
	<48CAC309.9040708@btinternet.com>
	<20080913022909.GA9703@lucky.cynic.net>
	<27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>
	<9d4d38820809130257x4ff17f74wc91598efd5d182bc@mail.gmail.com>
	<9d4d38820809130359n351905ebx11848448eca63c4@mail.gmail.com>
	<48CB9E63.1060109@btinternet.com>
Message-ID: <9d4d38820809130503i7c9bd020o62646eb11aaa4ad1@mail.gmail.com>

2008/9/13 Andrew Coppin :
>> Just FYI, I have now implemented and tested this feature. The new
>> version, 0.5.0, is available on Hackage.
>
> For both platforms?

Of course! My package promises to work cross-platform, after all.

> Out of interest, how do you get the correct package built on each platform?

If you mean "how do I compile the ANSI emulator on Windows but the
actual ANSI stuff on Unix", most of the magic is in the .cabal file:
http://github.com/batterseapower/ansi-terminal/tree/master/ansi-terminal.cabal.
I simply turn on the C-preprocessor (CPP) and then supply -DWINDOWS on
Windows and -DUNIX on anything else. The actual use of CPP in my
source is then confined to a single module
(http://github.com/batterseapower/ansi-terminal/tree/master/System/Console/ANSI.hs)
which either imports System.Console.ANSI.Windows or
System.Console.ANSI.Unix depending on which of those two have been
defined.

Nothing to it, really. However, this is the stuff that is making the
Hackage documentation generation choke currently because until
recently Cabal forgot to supply the CPP flags to a Haddock 2 (but not
Haddock 0.x) run.

All the best,
Max
From andrewcoppin at btinternet.com  Sat Sep 13 08:41:17 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sat Sep 13 08:38:49 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <9d4d38820809130503i7c9bd020o62646eb11aaa4ad1@mail.gmail.com>
References: <48C6CB3C.8020006@btinternet.com>	
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>	
	<48CAC309.9040708@btinternet.com>	
	<20080913022909.GA9703@lucky.cynic.net>	
	<27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>	
	<9d4d38820809130257x4ff17f74wc91598efd5d182bc@mail.gmail.com>	
	<9d4d38820809130359n351905ebx11848448eca63c4@mail.gmail.com>	
	<48CB9E63.1060109@btinternet.com>
	<9d4d38820809130503i7c9bd020o62646eb11aaa4ad1@mail.gmail.com>
Message-ID: <48CBB4ED.3090207@btinternet.com>

Max Bolingbroke wrote:
> 2008/9/13 Andrew Coppin :
>   
>>> Just FYI, I have now implemented and tested this feature. The new
>>> version, 0.5.0, is available on Hackage.
>>>       
>> For both platforms?
>>     
>
> Of course! My package promises to work cross-platform, after all.
>   

[rejoyce!]

>> Out of interest, how do you get the correct package built on each platform?
>>     
>
> If you mean "how do I compile the ANSI emulator on Windows but the
> actual ANSI stuff on Unix", most of the magic is in the .cabal file:

> I simply turn on the C-preprocessor (CPP) and then supply -DWINDOWS on
> Windows and -DUNIX on anything else. The actual use of CPP in my
> source is then confined to a single module
> which either imports System.Console.ANSI.Windows or
> System.Console.ANSI.Unix depending on which of those two have been
> defined.
>
> Nothing to it, really. However, this is the stuff that is making the
> Hackage documentation generation choke currently because until
> recently Cabal forgot to supply the CPP flags to a Haddock 2 (but not
> Haddock 0.x) run.
>   

Hmm, I wasn't aware you could use the C preprocessor on Haskell source 
code. That could be rather useful, e.g., for adding or removing debug code.

Anyway, that still leaves one question: how do you figure out which 
platform you're on so you can set the right options?

From duncan.coutts at worc.ox.ac.uk  Sat Sep 13 09:01:56 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Sep 13 08:57:40 2008
Subject: [Haskell-cafe] Windows console
In-Reply-To: <48CBB4ED.3090207@btinternet.com>
References: <48C6CB3C.8020006@btinternet.com>
	<9d4d38820809091241q1847c35m3f14fec0490a45ea@mail.gmail.com>
	<48CAC309.9040708@btinternet.com>	
	<20080913022909.GA9703@lucky.cynic.net>
	<27FEEBED-3E43-4919-BEBE-B334FB0260A8@ece.cmu.edu>
	<9d4d38820809130257x4ff17f74wc91598efd5d182bc@mail.gmail.com>
	<9d4d38820809130359n351905ebx11848448eca63c4@mail.gmail.com>
	<48CB9E63.1060109@btinternet.com>
	<9d4d38820809130503i7c9bd020o62646eb11aaa4ad1@mail.gmail.com>
	<48CBB4ED.3090207@btinternet.com>
Message-ID: <1221310916.5395.106.camel@localhost>

On Sat, 2008-09-13 at 13:41 +0100, Andrew Coppin wrote:

> > If you mean "how do I compile the ANSI emulator on Windows but the
> > actual ANSI stuff on Unix", most of the magic is in the .cabal file:
> 
> > I simply turn on the C-preprocessor (CPP) and then supply -DWINDOWS on
> > Windows and -DUNIX on anything else.


> Anyway, that still leaves one question: how do you figure out which 
> platform you're on so you can set the right options?

As Max suggested, look in the .cabal file. You'll find this snippet:

  if os(windows)
    Build-Depends:          Win32 >= 2.0
    Cpp-Options:            -DWINDOWS
    [... other stuff ...]
  else
    -- We assume any non-Windows platform is Unix
    Build-Depends:          unix >= 2.3.0.0
    Cpp-Options:            -DUNIX
    [... other stuff ...]

  Extensions:             CPP


Duncan

From duncan.coutts at worc.ox.ac.uk  Sat Sep 13 09:06:36 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Sep 13 09:02:14 2008
Subject: [Haskell-cafe] Erroneous package listings in hackage?
In-Reply-To: <2d3641330809130406l1c3a08a2n98ccd5edbfe6970c@mail.gmail.com>
References: <2d3641330809120421l2731f07bqf14799165ef43b56@mail.gmail.com>
	
	<1221267072.5395.100.camel@localhost>
	<2d3641330809130406l1c3a08a2n98ccd5edbfe6970c@mail.gmail.com>
Message-ID: <1221311196.5395.111.camel@localhost>

On Sat, 2008-09-13 at 12:06 +0100, Dougal Stanton wrote:
> On Sat, Sep 13, 2008 at 1:51 AM, Duncan Coutts
>  wrote:
> > Perhaps for packages that are installed but not re-installable via Cabal
> > (like cairo, base, ghc etc) it should say something. Do you have any
> > specific suggestions?
> 
> Well that explains it then! I had no idea it listed stuff not
> available from Hackage. I've been using `cabal list | grep foo` to
> search for packages but that's obviously not optimal, it seems.

I guess you're searching through the package description too. The reason
cabal list currently only searches though the name (though it does do
substring matching) is that parsing every .cabal file in the index is
rather slow. At some point we'll probably have to make a cache of the
info which we generate when the index is downloaded.

> I don't know what would clarify the matter. An "available from
> Hackage: (yes/no)" field? Or a flag to pass to `cabal list` to show
> Hackage stuff only?

We've got an --installed flag to list only installed stuff, we could add
one for the opposite case. You can file a feature request ticket here:

http://hackage.haskell.org/trac/hackage/

Or send us a patch! :-) I don't expect it'd be hard to add.

Duncan

From andrewcoppin at btinternet.com  Sat Sep 13 09:13:21 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sat Sep 13 09:10:52 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: 
References: <48C6AECE.3020905@btinternet.com>	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>	<48C6C17C.1040000@btinternet.com>		<48C97068.7010201@btinternet.com>		<48CAA2DE.3080701@btinternet.com>
	
Message-ID: <48CBBC71.8010601@btinternet.com>

Jeff Zaroyko wrote:
> Andrew Coppin  btinternet.com> writes:
>
>   
>> I literally cannot *believe* how hard it is to put a few little words
>> into that version tab... Every other kind of resource seems to be 
>> completely trivial, but this just won't work for toffee!
>>     
>
> I'm sure you'll work something out, my test worked, I used a .res file I had
> lying around from Wine's ddraw.dll, used windres ddraw.res -o version.o to make
> an object file then using ghc hello.hs version.o linked it against hello world.
>   

Well, you must either be running under a different OS or have Cygwin 
installed, because when I try it, it just complains constantly. ("Can't 
find gcc", "can't find cc1", "can't find crt.o", and so forth.) At this 
point, I'm giving up. I only wanted this for the shininess value. It's 
not worth this much trouble...

From bulat.ziganshin at gmail.com  Sat Sep 13 09:20:50 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Sat Sep 13 09:19:57 2008
Subject: [Haskell-cafe] Re: Windows details
In-Reply-To: <48CBBC71.8010601@btinternet.com>
References: <48C6AECE.3020905@btinternet.com>
	<68edc4h8f4nh30n7br2gfure7vkh5hkfbt@4ax.com>
	<48C6C17C.1040000@btinternet.com>
	
	<48C97068.7010201@btinternet.com>
	
	<48CAA2DE.3080701@btinternet.com>
	
	<48CBBC71.8010601@btinternet.com>
Message-ID: <612691024.20080913172050@gmail.com>

Hello Andrew,

Saturday, September 13, 2008, 5:13:21 PM, you wrote:

> Well, you must either be running under a different OS or have Cygwin
> installed, because when I try it, it just complains constantly. ("Can't
> find gcc", "can't find cc1", "can't find crt.o", and so forth.) At this
> point, I'm giving up. I only wanted this for the shininess value. It's
> not worth this much trouble...

yes, you should add path to gcc to your path. that's what i have in my
makefile - hope it can help:

GHCDIR  = C:\Base\Compiler\ghc
LIBDIR  = $(GHCDIR)\gcc-lib
INCDIR  = $(GHCDIR)\include\mingw
GCC     = $(GHCDIR)\gcc.exe -B$(LIBDIR) -I$(INCDIR)


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From j.m.m.joosten at hccnet.nl  Sat Sep 13 09:49:31 2008
From: j.m.m.joosten at hccnet.nl (Han Joosten)
Date: Sat Sep 13 09:47:09 2008
Subject: [Haskell-cafe] nooby question on typing
Message-ID: <19470727.post@talk.nabble.com>


Hi,

I have a question about types in Haskell. I feel that I am overlooking some
obvious solution, but I do not manage to get it right. Here is the plot:

I have got 4 different types of 'rules', each with it's own constructor.  So
i defined:

>  type Rules = [Rule]
>  data Rule = RuRule
>            | SgRule
>            | GcRule
>            | FrRule
>                deriving (Eq,Show)
>  data RuRule
>     = Ru { rrsrt :: Char
>          , rrant :: Expression
>          , rrfps :: FilePos
>          } deriving (Eq,Show)
>  data SgRule
>     = Sg { srfps :: FilePos
>          , srsig :: Rule
>          , srxpl :: String
>          , srtyp :: (Concept,Concept)
>          } deriving (Eq,Show)
>  data GcRule
>     = Gc { grfps :: FilePos
>          , grspe :: Morphism
>          , grgen :: Expression
>          } deriving (Eq,Show)
>  data FrRule
>     = Fr { fraut :: AutType
>          , frdec :: Declaration
>          , frcmp :: Expression
>          , frpat :: String
>          } deriving (Eq,Show)

Now I would like to be able to use these rules without knowing what kind
they are, in lists, however i get errors like 
Couldn't match expected type `Rule' against inferred type `SgRule'. 
Is there any other (even trivial?) way to get this done? I know Haskell well
enough to know that it is possible, but I don not know Haskell well enough
to know how to do it :teeth:

Any help is kindly appreciated!

Han Joosten
-- 
View this message in context: http://www.nabble.com/nooby-question-on-typing-tp19470727p19470727.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

From sebastian.sylvan at gmail.com  Sat Sep 13 10:01:41 2008
From: sebastian.sylvan at gmail.com (Sebastian Sylvan)
Date: Sat Sep 13 09:59:20 2008
Subject: [Haskell-cafe] nooby question on typing
In-Reply-To: <19470727.post@talk.nabble.com>
References: <19470727.post@talk.nabble.com>
Message-ID: <3d96ac180809130701vdc0aa2q576c91be4d768987@mail.gmail.com>

On Sat, Sep 13, 2008 at 2:49 PM, Han Joosten wrote:

>
> Hi,
>
> I have a question about types in Haskell. I feel that I am overlooking some
> obvious solution, but I do not manage to get it right. Here is the plot:
>
> I have got 4 different types of 'rules', each with it's own constructor.
>  So
> i defined:
>
> >  type Rules = [Rule]
> >  data Rule = RuRule
> >            | SgRule
> >            | GcRule
> >            | FrRule
> >                deriving (Eq,Show)


This effectively creates an enum type. I.e. each case here doesn't contain
any data other than the "tag". I think you're getting confused because the
constructor is named the same as the type you're expecting to store. Try
something like:

>  type Rules = [Rule]
>  data Rule = RuRule
>            | MkSgRule SgRule
>            | MkGcRule GcRule
>            | MkFrRule FrRule
>                deriving (Eq,Show)

So MkSgRule is a "tag" or a "label" deciding which version of Rule you're
building, and it also has a value of type SgRule.

Now you can create a list or Rule like so:

>mylist :: [Rule]
>mylist = [ MkSgRule mysgrule, MkGcRule mygcrule ]

where mysgrule :: SgRule and mygcrule :: GcRule.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/68609bb9/attachment.htm
From gwern0 at gmail.com  Sat Sep 13 10:26:32 2008
From: gwern0 at gmail.com (Gwern Branwen)
Date: Sat Sep 13 10:24:49 2008
Subject: [Haskell-cafe] Hackage needs a theme song!
In-Reply-To: 
References: 
Message-ID: <20080913142632.GA12296@craft>

On 2008.09.12 20:35:32 -0700, Jason Dagit  scribbled 1.7K characters:
> I realized tonight that Hackage needs a theme song.  Here is my
> attempt at it, apologies to Jefferson Starship:
>
> We built this hackage,
> We built this hackage on lambda and types
...

Pretty good. Any plans to stick it in ?

--
gwern
SUSLO Freespire INFOSEC M-x Templar Uzbekistan FID Tokyo NTT infowar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/a7240bfa/attachment.bin
From dons at galois.com  Sat Sep 13 12:47:35 2008
From: dons at galois.com (Don Stewart)
Date: Sat Sep 13 12:45:08 2008
Subject: [Haskell-cafe] Fwd: Computer Language Benchmarks Game: [Which
	parallel problem would you add and why?]
Message-ID: <20080913164735.GA21028@scytale.galois.com>

The Computer Language Benchmarks Game has a quad core (as you probably
know). But they're looking for new benchmarks. Ones that can actually
exploit parallelism. If you've got suggestions on good parallelism
benchmarks, and why they're good, add them to the alioth or reddit
threads.



----- Forwarded message from Isaac Gouy -----


"Which parallel problem would you add and why?"

http://alioth.debian.org/forum/forum.php?thread_id=14502&forum_id=2840


"Ask Proggit: Which parallel problem would you add now The Computer
Language Benchmarks Game is measured on quad-core hardware, and why?"

http://www.reddit.com/r/programming/comments/718qf/ask_proggit_which_parallel_problem_would_you_add/


----- End forwarded message -----
From mailing_list at istitutocolli.org  Sat Sep 13 13:33:05 2008
From: mailing_list at istitutocolli.org (Andrea Rossato)
Date: Sat Sep 13 13:30:49 2008
Subject: [Haskell-cafe] ANNOUNCE: citeproc-hs,
	a Haskell implementation of the Citation
	Style Language designed for Pandoc
Message-ID: <20080913173305.GB23265@Andrea.Nowhere.net>

Hello,

I'm happy to announce the first release of citeproc-hs, a Haskell
implementation of the Citation Style Language.

citeproc-hs adds to Pandoc, the famous Haskell text processing tool, a
Bibtex like citation and bibliographic formatting and generation
facility.

ABOUT
The Citation Style Language (CSL) is an XML language for specifying
citation and bibliographic formatting, similar in principle to BibTeX
.bst files or the binary style files in commercial products like
Endnote or Reference Manager.

CSL is used by Zotero for bibliographic style formatting, and a huge
number of CSL styles have been developed by the Zotero community.

There are plans to use CSL in the future release of OpenOffice:
http://bibliographic.openoffice.org/

citeproc-hs is a library that exports functions to parse CSL styles
and MODS collections, to process lists of citation groups and to
format the processed output. The output is a Haskell data type that
can be further processed for conversion to any kind of formats (at the
present time plain ASCII and the Pandoc native format)

citeproc-hs was developed in order to add to Pandoc Bibtex like
citations and automatic reference and bibliography generation.

More information, with installation instructions, can be found here:
http://code.haskell.org/citeproc-hs/

DOWNLOADS
citeproc-hs can be downloaded from Hackage:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/citeproc-hs

To get the darcs source run:

    darcs get http://code.haskell.org/citeproc-hs/


KNOWN ISSUES
citeproc-hs is in an early stage of development and the CSL is not
complete yet.

Specifically, citation collapsing is not implemented, and some
formatting options are not working neither.

The MODS parser needs some refinement too.

BUG REPORTS
To submit bug reports you can you the Google code bug tracking system
available at the following address:
http://code.google.com/p/citeproc-hs/issues


CREDITS
Bruce D'Arcus, the author of CSL, has been very kind and patient
with me when I was trying to understand the CSL schema, and provided
me with ideas, comments and suggestions that made it possible to come
to something usable.

John MacFarlane, the author of Pandoc, has been very supportive of the
project and provided a lot of useful feed back, comments and
suggestions.

Hope you'll enjoy,
Andrea Rossato
From gsan at stillpsycho.net  Sat Sep 13 13:45:46 2008
From: gsan at stillpsycho.net (=?utf-8?q?G=C3=B6khan_San?=)
Date: Sat Sep 13 13:43:29 2008
Subject: [Haskell-cafe] nooby question on typing
In-Reply-To: <19470727.post@talk.nabble.com>
References: <19470727.post@talk.nabble.com>
Message-ID: <200809131945.46388.gsan@stillpsycho.net>

On Saturday September 13 2008, Han Joosten wrote:
> > ?data Rule = RuRule
> > ? ? ? ? ? ?| SgRule
> > ? ? ? ? ? ?| GcRule
> > ? ? ? ? ? ?| FrRule
> > ? ? ? ? ? ? ? ?deriving (Eq,Show)

Here, Rule is a type constructor, whereas RuRule and others are data 
constructors. Just like:

> data Bool = False | True

The type of RuRule is Rule and is not related to the RuRule type you are 
defining afterwards. What you want to do is probably this:

>  type Rules = [Rule]
>  data Rule = Ru RuRule
>            | Sg SgRule
>            | Gc GcRule
>            | Fr FrRule
>              deriving (Eq,Show)

>  data RuRule
>     = RuRule { rrsrt :: Char
>              , rrant :: Expression
>              , rrfps :: FilePos
>              } deriving (Eq,Show)

>  data SgRule
>     = SgRule { srfps :: FilePos
>              , srsig :: Rule
>              , srxpl :: String
>              , srtyp :: (Concept,Concept)
>              } deriving (Eq,Show)

...

You can now form a Rules list and use pattern matching on its members.

-- Gokhan
From deduktionstheorem at web.de  Sat Sep 13 14:19:46 2008
From: deduktionstheorem at web.de (Stephan Friedrichs)
Date: Sat Sep 13 14:17:26 2008
Subject: [Haskell-cafe] Views
Message-ID: <48CC0442.8030905@web.de>

Hello!

List-like data structures should IMHO provide safe versions of 'head'
and 'tail' (with safe I mean 'not partial', i. e. functions that don't
provoke an 'error' when called with an empty collection). As far as I
know, this is usually called 'view' and and has a type signature like

view :: SomeDataStructure a -> View a

with

data View
  = Empty
  | Cons a (SomeDataStructure a)

A good example for this is Data.Sequence. My question is: Why is this
not expressed in terms of Maybe?

view :: SomeDataStructure a -> Maybe (a, SomeDataStructure a)

This would be easier to use, as there's no need for a new View type and
because Maybe already provides instance declarations for a lot of useful
classes (Functor, Monad, etc.) and handy helper functions (e. g.
'maybe'). Then you could, for instance, say:

head xs = maybe undefined fst (view xs)
tail xs = maybe undefined snd (view xs)

You can of course argue that you want viewl and viewr to have different
types in the case of Data.Sequence, but this is not the case for other,
rather one-ended, data types, is it?

Long story short, my problem is the following: I want to provide a
'view' function for Data.Heap in my heap [1] package and I don't know
whether...

a) ... to use Maybe
b) ... to provide my own Data.Heap.View type
c) ... a Data.View package with a View type should be included in
   the containers- or even base-package. This would prevent lots of
   small projects from creating totally equivalent View types.

Maybe there even exists a Data.View package that I didn't find?

Regards,
Stephan

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.3.1

-- 

Fr?her hie? es ja: Ich denke, also bin ich.
Heute wei? man: Es geht auch so.

 - Dieter Nuhr
From mailing_list at istitutocolli.org  Sat Sep 13 14:36:47 2008
From: mailing_list at istitutocolli.org (Andrea Rossato)
Date: Sat Sep 13 14:34:36 2008
Subject: [Haskell-cafe] Hackage checks
Message-ID: <20080913183647.GF23265@Andrea.Nowhere.net>

Hi,

the Hackage upload script performs some checks on the packages being
uploaded. In my case, a library, I need to use the cabal generated
Paths_package file to access some locale data stored in a data file
directory.

This requires to include in "hs-source-dirs" "dist/build/autogen",
which doesn't exist in the source tree, since it's generated by cabal
in the build process (the inclusion is made necessary by a bug in
Cabal-1.2 which doesn't automatically search dist/build/autogen, see
[1]).

And so Hackage complains: I needed to manually include such an empty
directory in the source code archive.

Any way out?

TIA
Andrea


[1] http://www.haskell.org/pipermail/libraries/2008-July/010078.html
From ryani.spam at gmail.com  Sat Sep 13 14:40:11 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Sat Sep 13 14:37:48 2008
Subject: [Haskell-cafe] nooby question on typing
In-Reply-To: <19470727.post@talk.nabble.com>
References: <19470727.post@talk.nabble.com>
Message-ID: <2f9b2d30809131140x10265f1fh1f8855a72804d015@mail.gmail.com>

So it sounds like what you want to do is this:

rulesList =
    [ Ru 'a' someExpr someFilePos
    , Sg someFilePos (Gc someOtherFilePos someMorphism someExpr) "hello" (a,b)
    ]
(This won't compile because Ru and Sg construct different types.)

You have a few options to do this:

1) Move the constructors into the "Rule" type.  This means you don't
get functions that only apply to "RuRule", or any of the other types
without them being partial and subject to runtime error, so this may
not be safe enough for you.  But it is the simplest answer.

> data Rule = Ru { rrst :: Char, other stuff... } | Sg { ... } | ...

2) Smart constructors!

> data Rule = MkRu RuRule | MkSg SgRule | ...
> ru a b c = MkRu (Ru a b c)
> ...

Now just use the lowercase "ru" instead of "Ru" to construct a "Rule"
(instead of the specific rule type).

rulesList =
    [ ru 'a' someExpr someFilePos
    , sg someFilePos (Gc someOtherFilePos someMorphism someExpr) "hello" (a,b)
    ]

This will work!  You will still need the "MkRu (Ru a b c)" if you
pattern match on Rule, though.

3) dynamic typing and/or existential types, with smart constructors

> {-# LANGUAGE ExistentialQuantification, DeriveDataTypeable, PatternGuards #-}
> import Data.Typeable

> data RuRule = Ru { ... } deriving (Eq, Show, Typeable)
> ...

> class Typeable a => IsRule a
> instance IsRule RuRule
> instance IsRule GcRule
> ...

> data Rule = forall a. IsRule a => Rule a

> ru a b c = Rule (Ru a b c)

> unRu :: Rule -> Maybe RuRule
> unRu (Rule x) = cast x
> ...

> -- example of pattern matching using pattern guards as "views"
> test :: Rule -> Bool
> test x
>   | Just (Ru _ _ _) <- unRu x = True
>   | Just (Sg _ x2 _ _) <- unSg x,
>     Just (Ru a _ _) <- unRu x2 = a == 'h'
>   | otherwise = False

Hopefully one of these will suit your needs!

  -- ryan

On Sat, Sep 13, 2008 at 6:49 AM, Han Joosten  wrote:
>
> Hi,
>
> I have a question about types in Haskell. I feel that I am overlooking some
> obvious solution, but I do not manage to get it right. Here is the plot:
>
> I have got 4 different types of 'rules', each with it's own constructor.  So
> i defined:
>
>>  type Rules = [Rule]
>>  data Rule = RuRule
>>            | SgRule
>>            | GcRule
>>            | FrRule
>>                deriving (Eq,Show)
>>  data RuRule
>>     = Ru { rrsrt :: Char
>>          , rrant :: Expression
>>          , rrfps :: FilePos
>>          } deriving (Eq,Show)
>>  data SgRule
>>     = Sg { srfps :: FilePos
>>          , srsig :: Rule
>>          , srxpl :: String
>>          , srtyp :: (Concept,Concept)
>>          } deriving (Eq,Show)
>>  data GcRule
>>     = Gc { grfps :: FilePos
>>          , grspe :: Morphism
>>          , grgen :: Expression
>>          } deriving (Eq,Show)
>>  data FrRule
>>     = Fr { fraut :: AutType
>>          , frdec :: Declaration
>>          , frcmp :: Expression
>>          , frpat :: String
>>          } deriving (Eq,Show)
>
> Now I would like to be able to use these rules without knowing what kind
> they are, in lists, however i get errors like
> Couldn't match expected type `Rule' against inferred type `SgRule'.
> Is there any other (even trivial?) way to get this done? I know Haskell well
> enough to know that it is possible, but I don not know Haskell well enough
> to know how to do it :teeth:
>
> Any help is kindly appreciated!
>
> Han Joosten
> --
> View this message in context: http://www.nabble.com/nooby-question-on-typing-tp19470727p19470727.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From waldmann at imn.htwk-leipzig.de  Sat Sep 13 14:42:35 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Sat Sep 13 14:40:18 2008
Subject: [Haskell-cafe] Views
In-Reply-To: <48CC0442.8030905@web.de>
References: <48CC0442.8030905@web.de>
Message-ID: <48CC099B.2090201@imn.htwk-leipzig.de>


> a) ... to use Maybe
> b) ... to provide my own Data.Heap.View type

leave the choice up to the programmer,
and provide a generic interface,
accepting any MonadZero (*) instance.

cf. Data.Set.maxView

http://www.haskell.org/hoogle/?hoogle=maxView

(*) ah - I forgot, MonadZero didn't quite make it,
instead we have "fail" in Monad, and "mzero" in MonadPlus.
Sure there must have been a reason for this...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/af3192f6/signature.bin
From ryani.spam at gmail.com  Sat Sep 13 14:47:46 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Sat Sep 13 14:45:23 2008
Subject: [Haskell-cafe] Views
In-Reply-To: <48CC0442.8030905@web.de>
References: <48CC0442.8030905@web.de>
Message-ID: <2f9b2d30809131147i647bf5eak33422f1498483f39@mail.gmail.com>

On Sat, Sep 13, 2008 at 11:19 AM, Stephan Friedrichs
 wrote:
> data View
>  = Empty
>  | Cons a (SomeDataStructure a)
>
> A good example for this is Data.Sequence. My question is: Why is this
> not expressed in terms of Maybe?
>
> view :: SomeDataStructure a -> Maybe (a, SomeDataStructure a)

I think the usual reason this is done is because it is clearer to
read.  Since Maybe is so generally useful, when you read code that
uses it, you have to figure out what use it is being put towards.
"What does Nothing mean?  What does Just (a,b) mean?" are the kinds of
questions that go through your head, and they distract you from the
problem at hand.

On the other hand, reading code that uses the View type, it is
immediately clear what Empty and Cons mean.  But you're right, Maybe
has a lot of useful helper functions and instances.

  -- ryan
From duncan.coutts at worc.ox.ac.uk  Sat Sep 13 15:12:07 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Sep 13 15:07:47 2008
Subject: [Haskell-cafe] Hackage checks
In-Reply-To: <20080913183647.GF23265@Andrea.Nowhere.net>
References: <20080913183647.GF23265@Andrea.Nowhere.net>
Message-ID: <1221333127.5395.121.camel@localhost>

On Sat, 2008-09-13 at 20:36 +0200, Andrea Rossato wrote:
> Hi,
> 
> the Hackage upload script performs some checks on the packages being
> uploaded. In my case, a library, I need to use the cabal generated
> Paths_package file to access some locale data stored in a data file
> directory.
> 
> This requires to include in "hs-source-dirs" "dist/build/autogen",
> which doesn't exist in the source tree, since it's generated by cabal
> in the build process (the inclusion is made necessary by a bug in
> Cabal-1.2 which doesn't automatically search dist/build/autogen, see
> [1]).

Any path in your .cabal file that uses dist/ is wrong. Sorry. The dist
path can be changed by the user (--builddir) and its internal layout is
not fixed.

> And so Hackage complains: I needed to manually include such an empty
> directory in the source code archive.
> 
> Any way out?

?I can't think of any other workaround for 1.2 so I think you'll have to
require Cabal-1.4 for your package.

Duncan

From mailing_list at istitutocolli.org  Sat Sep 13 15:27:22 2008
From: mailing_list at istitutocolli.org (Andrea Rossato)
Date: Sat Sep 13 15:25:03 2008
Subject: [Haskell-cafe] Hackage checks
In-Reply-To: <1221333127.5395.121.camel@localhost>
References: <20080913183647.GF23265@Andrea.Nowhere.net>
	<1221333127.5395.121.camel@localhost>
Message-ID: <20080913192722.GH23265@Andrea.Nowhere.net>

On Sat, Sep 13, 2008 at 08:12:07PM +0100, Duncan Coutts wrote:
> Any path in your .cabal file that uses dist/ is wrong.
[...]
> ?I can't think of any other workaround for 1.2 so I think you'll have to
> require Cabal-1.4 for your package.

Well, since ghc-6.8.3 comes with Cabal-1.2.4, having a package that
works for the great majority of ghc users may be "less wrong" then
having a correct cabal package that requires you to upgrade Cabal, in
order to get rid of strange and incomprehensible error such as
"Unknown symbol" linker complains.

Or at least this is what I thought. I believe I can cope with users
complaining for unexpected results when --builddir is used. They
should be hopefully less, even though I'm not so sure.

Correctness seems a minor problem, here.

Andrea
From byorgey at seas.upenn.edu  Sat Sep 13 19:07:27 2008
From: byorgey at seas.upenn.edu (Brent Yorgey)
Date: Sat Sep 13 19:05:06 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
Message-ID: <20080913230727.GA31569@seas.upenn.edu>

---------------------------------------------------------------------------
Haskell Weekly News
http://sequence.complete.org/hwn/20080913
Issue 85 - September 13, 2008
---------------------------------------------------------------------------

   Welcome to issue 85 of HWN, a newsletter covering developments in the
   [1]Haskell community.

Announcements

   citeproc-hs. Andrea Rossato [2]announced the first release of
   [3]citeproc-hs, a Haskell implementation of the [4]Citation Style
   Language. citeproc-hs adds a Bibtex-like citation and bibliographic
   formatting and generation facility to [5]Pandoc.

   Twidge. John Goerzen [6]announced the release of [7]Twidge, a
   command-line Twitter and Identi.ca client.

   Real World HAppS: Cabalized, Self-Demoing HAppS Tutorial (Version 3).
   Thomas Hartman [8]announced a new version of [9]happs-tutorial, with a
   correspondingly updated [10]online demo.

   generic list functions fixed. Jim Apple reported that genericTake,
   genericDrop, and genericSplitAt have [11]been fixed so they are now
   total functions (they used to fail on negative integer inputs, unlike
   their ungeneric counterparts).

   The Monad.Reader (13) - Call for copy. Wouter Swierstra [12]announced a
   call for copy for Issue 13 of the [13]Monad.Reader. The deadline for
   submitting articles is February 13, 2009.

   Heads Up: code.haskell.org is upgrading to darcs 2. Duncan Coutts
   [14]announced that /usr/bin/darcs on code.haskell.org will soon be
   upgraded to version 2. Most users should be unaffected as darcs 2 works
   just fine with repositories in darcs 1 format, and has been extensively
   tested for correctness.

Discussion

   packages and QuickCheck. Conal Elliott [15]asked what methods of
   organization people use to package up QuickCheck tests for their
   libraries.

   Hackage needs a theme song!. Jason Dagit wrote a [16]theme song for
   Hackage!

Jobs

   Gamr7. Lionel Barret De Nazaris [17]announced that [18]Gamr7, a startup
   in France focused on procedural city generation for the game and
   simulation market, is looking for a senior developer/technical
   director.

   senior role at Credit Suisse. Ganesh Sittampalam [19]announced that
   [20]Credit Suisse is seeking to recruit an expert in functional
   programming for a senior role in the Global Modelling and Analytics
   Group (GMAG) in the Securities Division.

Blog noise

   [21]Haskell news from the [22]blogosphere.
     * Douglas M. Auclair (geophf): [23]What is declarative programming?.
     * John Goerzen (CosmicRay): [24]New Twitter Client: Twidge.
     * Mark Jason Dominus: [25]Return return. Mark's mind is blown by the
       code "return return" appearing in a paper by Mark Jones.
     * Eric Kow (kowey): [26]darcs weekly news #3.
     * Ketil Malde: [27]The FastQ file format for sequences.
     * >>> Nathan Sanders: [28]Real World Haskell. Nathan experiments with
       porting some of his Python code to Haskell.
     * Andrea Vezzosi (Saizan): [29]Results from GSoC. Andrea's GSoC work
       on a high-level dependency framework for Cabal is going to be
       released in a separate package for now, [30]hbuild.
     * >>> Ricky Clarkson: [31]An IRC Bot in Haskell, 20% code, 80% GRR.
       Ricky shares his experiences, frustrations, and eventual success
       writing a simple IRC bot in Haskell.
     * >>> Yaakov Nemoy: [32]Xmonad 0.8 released.
     * Luke Palmer: [33]The problem with Coq. ...is, according to Luke,
       that it doesn't have a nice graphical interface.
     * >>> James Cowie: [34]Haskell! yes no?. James dives into learning
       some Haskell. Verdict so far: a "very nice language".

Quotes of the Week

     * EvilTerran: this is hard to express in this type system. i'm going
       to make my own type system instead!

About the Haskell Weekly News

   New editions are posted to [35]the Haskell mailing list as well as to
   [36]the Haskell Sequence and [37]Planet Haskell. [38]RSS is also
   available, and headlines appear on [39]haskell.org.

   To help create new editions of this newsletter, please see the
   information on [40]how to contribute. Send stories to byorgey at cis
   dot upenn dot edu. The darcs repository is available at darcs get
   [41]http://code.haskell.org/~byorgey/code/hwn/ .

References

   1. http://haskell.org/
   2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44471
   3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/citeproc%2Dhs
   4. http://xbiblio.sourceforge.net/csl/
   5. http://johnmacfarlane.net/pandoc/
   6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44453
   7. http://software.complete.org/twidge
   8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44410
   9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-tutorial
  10. http://happstutorial.com:5001/
  11. http://hackage.haskell.org/trac/ghc/ticket/2533
  12. http://article.gmane.org/gmane.comp.lang.haskell.general/16420
  13. http://www.haskell.org/haskellwiki/The_Monad.Reader
  14. http://article.gmane.org/gmane.comp.lang.haskell.general/16419
  15. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44259
  16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44450
  17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44211
  18. http://www.gamr7.com/
  19. http://article.gmane.org/gmane.comp.lang.haskell.general/16422
  20. http://www.credit-suisse.com/
  21. http://planet.haskell.org/
  22. http://haskell.org/haskellwiki/Blog_articles
  23. http://logicaltypes.blogspot.com/2008/09/what-is-declarative-programming.html
  24. http://changelog.complete.org/posts/752-New-Twitter-Client-Twidge.html
  25. http://blog.plover.com/prog/springschool95.html
  26. http://koweycode.blogspot.com/2008/09/darcs-weekly-news-3.html
  27. http://blog.malde.org/index.php/2008/09/09/the-fastq-file-format-for-sequences/
  28. http://sandersn.com/blog/index.php?title=real_world_haskell
  29. http://vezzosi.blogspot.com/2008/09/even-if-this-blog-has-been-silent-since.html
  30. http://hackage.haskell.org/trac/hackage/wiki/HBuild
  31. http://rickyclarkson.blogspot.com/2008/09/irc-bot-in-haskell-20-code-80-grr.html
  32. http://loupgaroublond.blogspot.com/2008/09/xmonad-08-released.html
  33. http://luqui.org/blog/archives/2008/09/07/the-problem-with-coq/
  34. http://www.jcowie.co.uk/2008/09/haskell-yes-no/
  35. http://www.haskell.org/mailman/listinfo/haskell
  36. http://sequence.complete.org/
  37. http://planet.haskell.org/
  38. http://sequence.complete.org/node/feed
  39. http://haskell.org/
  40. http://haskell.org/haskellwiki/HWN
  41. http://code.haskell.org/~byorgey/code/hwn/
From jgm at berkeley.edu  Sat Sep 13 21:29:10 2008
From: jgm at berkeley.edu (John MacFarlane)
Date: Sat Sep 13 21:26:49 2008
Subject: [Haskell-cafe] ANN: pandoc 1.0.0.1
Message-ID: <20080914012909.GA16164@berkeley.edu>

I'm pleased to announce the release of pandoc version 1.0.0.1.

Pandoc aspires to be the swiss army knife of text markup formats: it
can read markdown and (with some limitations) HTML, LaTeX, and
reStructuredText, and it can write markdown, reStructuredText, HTML,
DocBook XML, OpenDocument XML, ODT, RTF, groff man, MediaWiki markup,
GNU Texinfo, LaTeX, ConTeXt, and S5.  Pandoc's markdown syntax includes
extensions for LaTeX math, tables, definition lists, footnotes, and more.

HackageDB:        http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pandoc
User's guide:     http://johnmacfarlane.net/pandoc/README.html
Examples:         http://johnmacfarlane.net/pandoc/examples.html
Interactive demo: http://johnmacfarlane.net/pandoc/trypandoc/
Haddock docs:     http://johnmacfarlane.net/pandoc/doc/pandoc/
Repository:       http://pandoc.googlecode.com/
Bug tracker:      http://code.google.com/p/pandoc/issues/list
Mailing list:     http://groups.google.com/group/pandoc-discuss

Some highlights of this release:

+ New GNU Texinfo writer (contributed by Peter Wang)
+ New OpenDocument XML writer (contributed by Andrea Rossato)
+ New ODT (OpenOffice document) writer
+ New MediaWiki markup writer
+ New delimited code block syntax
+ Handy generic functions for querying and transforming documents without
  lots of boilerplate (thanks to Andrea Rossato)
+ Cleaner build system:  pandoc can now be built as a regular Cabal package
+ New dependencies:  utf8-string and zip-archive
+ Code is -Wall clean
+ New Windows installer
+ Better support for math, including display math
+ Better HTML sanitizing for use in web applications
+ Many minor improvements and bug fixes (see changelog for details)

Pandoc can optionally be compiled with support for

+ syntax highlighting of delimited code blocks, using the
  highlighting-kate library (over 50 languages are supported)
  (specify -fhighlighting)
+ automatically generated citations and bibliography, using
  Andrea Rossato's hs-citeproc library (specify -fciteproc)

I am particularly excited about Rossato's experimental citation support.
It's basically a BibTeX-like system that one can use in any of pandoc's
output formats. So you can have automatically generated citations in a
blog post, a wiki page, or even a man page! It's not yet complete, but
it's far enough along for those with an adventurous spirit to use.

I am very grateful to everyone who contributed bug reports and code,
and especially to Andrea Rossato and Peter Wang for their major
contributions.

From dons at galois.com  Sat Sep 13 21:31:35 2008
From: dons at galois.com (Don Stewart)
Date: Sat Sep 13 21:29:05 2008
Subject: [Haskell-cafe] ANN: pandoc 1.0.0.1
In-Reply-To: <20080914012909.GA16164@berkeley.edu>
References: <20080914012909.GA16164@berkeley.edu>
Message-ID: <20080914013135.GN21028@scytale.galois.com>

jgm:
> I'm pleased to announce the release of pandoc version 1.0.0.1.
> 
> Pandoc aspires to be the swiss army knife of text markup formats: it
> can read markdown and (with some limitations) HTML, LaTeX, and
> reStructuredText, and it can write markdown, reStructuredText, HTML,
> DocBook XML, OpenDocument XML, ODT, RTF, groff man, MediaWiki markup,
> GNU Texinfo, LaTeX, ConTeXt, and S5.  Pandoc's markdown syntax includes
> extensions for LaTeX math, tables, definition lists, footnotes, and more.
> 
> HackageDB:        http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pandoc
> User's guide:     http://johnmacfarlane.net/pandoc/README.html
> Examples:         http://johnmacfarlane.net/pandoc/examples.html
> Interactive demo: http://johnmacfarlane.net/pandoc/trypandoc/
> Haddock docs:     http://johnmacfarlane.net/pandoc/doc/pandoc/
> Repository:       http://pandoc.googlecode.com/
> Bug tracker:      http://code.google.com/p/pandoc/issues/list
> Mailing list:     http://groups.google.com/group/pandoc-discuss
> 

And natively packaged for Arch Linux,

    http://aur.archlinux.org/packages.php?ID=19804
From brianchina60221 at gmail.com  Sat Sep 13 22:31:50 2008
From: brianchina60221 at gmail.com (brian)
Date: Sat Sep 13 22:29:27 2008
Subject: [Haskell-cafe] ANN: pandoc 1.0.0.1
In-Reply-To: <20080914012909.GA16164@berkeley.edu>
References: <20080914012909.GA16164@berkeley.edu>
Message-ID: <22f6a8f70809131931m2f8804a8na16f544ae81478c9@mail.gmail.com>

On Sat, Sep 13, 2008 at 8:29 PM, John MacFarlane  wrote:
> + Code is -Wall clean

Thanks, I appreciate it. I wish more people paid attention to this.
From dmehrtash at gmail.com  Sun Sep 14 00:06:21 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Sun Sep 14 00:03:58 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <20080913230727.GA31569@seas.upenn.edu>
References: <20080913230727.GA31569@seas.upenn.edu>
Message-ID: 

I have a newbie question....  Does theorem proofs have a use for an
application?  Take for example the IRC bot example (
http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot)  listed below.  Is
there any insight to be gained by theorem proofs (as in COQ) into the app?

Thanks,

Daryoush

On Sat, Sep 13, 2008 at 4:07 PM, Brent Yorgey wrote:

> ---------------------------------------------------------------------------
> Haskell Weekly News
> http://sequence.complete.org/hwn/20080913
> Issue 85 - September 13, 2008
> ---------------------------------------------------------------------------
>
>   Welcome to issue 85 of HWN, a newsletter covering developments in the
>   [1]Haskell community.
>
> Announcements
>
>   citeproc-hs. Andrea Rossato [2]announced the first release of
>   [3]citeproc-hs, a Haskell implementation of the [4]Citation Style
>   Language. citeproc-hs adds a Bibtex-like citation and bibliographic
>   formatting and generation facility to [5]Pandoc.
>
>   Twidge. John Goerzen [6]announced the release of [7]Twidge, a
>   command-line Twitter and Identi.ca client.
>
>   Real World HAppS: Cabalized, Self-Demoing HAppS Tutorial (Version 3).
>   Thomas Hartman [8]announced a new version of [9]happs-tutorial, with a
>   correspondingly updated [10]online demo.
>
>   generic list functions fixed. Jim Apple reported that genericTake,
>   genericDrop, and genericSplitAt have [11]been fixed so they are now
>   total functions (they used to fail on negative integer inputs, unlike
>   their ungeneric counterparts).
>
>   The Monad.Reader (13) - Call for copy. Wouter Swierstra [12]announced a
>   call for copy for Issue 13 of the [13]Monad.Reader. The deadline for
>   submitting articles is February 13, 2009.
>
>   Heads Up: code.haskell.org is upgrading to darcs 2. Duncan Coutts
>   [14]announced that /usr/bin/darcs on code.haskell.org will soon be
>   upgraded to version 2. Most users should be unaffected as darcs 2 works
>   just fine with repositories in darcs 1 format, and has been extensively
>   tested for correctness.
>
> Discussion
>
>   packages and QuickCheck. Conal Elliott [15]asked what methods of
>   organization people use to package up QuickCheck tests for their
>   libraries.
>
>   Hackage needs a theme song!. Jason Dagit wrote a [16]theme song for
>   Hackage!
>
> Jobs
>
>   Gamr7. Lionel Barret De Nazaris [17]announced that [18]Gamr7, a startup
>   in France focused on procedural city generation for the game and
>   simulation market, is looking for a senior developer/technical
>   director.
>
>   senior role at Credit Suisse. Ganesh Sittampalam [19]announced that
>   [20]Credit Suisse is seeking to recruit an expert in functional
>   programming for a senior role in the Global Modelling and Analytics
>   Group (GMAG) in the Securities Division.
>
> Blog noise
>
>   [21]Haskell news from the [22]blogosphere.
>     * Douglas M. Auclair (geophf): [23]What is declarative programming?.
>     * John Goerzen (CosmicRay): [24]New Twitter Client: Twidge.
>     * Mark Jason Dominus: [25]Return return. Mark's mind is blown by the
>       code "return return" appearing in a paper by Mark Jones.
>     * Eric Kow (kowey): [26]darcs weekly news #3.
>     * Ketil Malde: [27]The FastQ file format for sequences.
>     * >>> Nathan Sanders: [28]Real World Haskell. Nathan experiments with
>       porting some of his Python code to Haskell.
>     * Andrea Vezzosi (Saizan): [29]Results from GSoC. Andrea's GSoC work
>       on a high-level dependency framework for Cabal is going to be
>       released in a separate package for now, [30]hbuild.
>     * >>> Ricky Clarkson: [31]An IRC Bot in Haskell, 20% code, 80% GRR.
>       Ricky shares his experiences, frustrations, and eventual success
>       writing a simple IRC bot in Haskell.
>     * >>> Yaakov Nemoy: [32]Xmonad 0.8 released.
>     * Luke Palmer: [33]The problem with Coq. ...is, according to Luke,
>       that it doesn't have a nice graphical interface.
>     * >>> James Cowie: [34]Haskell! yes no?. James dives into learning
>       some Haskell. Verdict so far: a "very nice language".
>
> Quotes of the Week
>
>     * EvilTerran: this is hard to express in this type system. i'm going
>       to make my own type system instead!
>
> About the Haskell Weekly News
>
>   New editions are posted to [35]the Haskell mailing list as well as to
>   [36]the Haskell Sequence and [37]Planet Haskell. [38]RSS is also
>   available, and headlines appear on [39]haskell.org.
>
>   To help create new editions of this newsletter, please see the
>   information on [40]how to contribute. Send stories to byorgey at cis
>   dot upenn dot edu. The darcs repository is available at darcs get
>   [41]http://code.haskell.org/~byorgey/code/hwn/.
>
> References
>
>   1. http://haskell.org/
>   2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44471
>   3.
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/citeproc%2Dhs
>   4. http://xbiblio.sourceforge.net/csl/
>   5. http://johnmacfarlane.net/pandoc/
>   6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44453
>   7. http://software.complete.org/twidge
>   8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44410
>   9.
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-tutorial
>  10. http://happstutorial.com:5001/
>  11. http://hackage.haskell.org/trac/ghc/ticket/2533
>  12. http://article.gmane.org/gmane.comp.lang.haskell.general/16420
>  13. http://www.haskell.org/haskellwiki/The_Monad.Reader
>  14. http://article.gmane.org/gmane.comp.lang.haskell.general/16419
>  15. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44259
>  16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44450
>  17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44211
>  18. http://www.gamr7.com/
>  19. http://article.gmane.org/gmane.comp.lang.haskell.general/16422
>  20. http://www.credit-suisse.com/
>  21. http://planet.haskell.org/
>  22. http://haskell.org/haskellwiki/Blog_articles
>  23.
> http://logicaltypes.blogspot.com/2008/09/what-is-declarative-programming.html
>  24.
> http://changelog.complete.org/posts/752-New-Twitter-Client-Twidge.html
>  25. http://blog.plover.com/prog/springschool95.html
>  26. http://koweycode.blogspot.com/2008/09/darcs-weekly-news-3.html
>  27.
> http://blog.malde.org/index.php/2008/09/09/the-fastq-file-format-for-sequences/
>  28. http://sandersn.com/blog/index.php?title=real_world_haskell
>  29.
> http://vezzosi.blogspot.com/2008/09/even-if-this-blog-has-been-silent-since.html
>  30. http://hackage.haskell.org/trac/hackage/wiki/HBuild
>  31.
> http://rickyclarkson.blogspot.com/2008/09/irc-bot-in-haskell-20-code-80-grr.html
>  32. http://loupgaroublond.blogspot.com/2008/09/xmonad-08-released.html
>  33. http://luqui.org/blog/archives/2008/09/07/the-problem-with-coq/
>  34. http://www.jcowie.co.uk/2008/09/haskell-yes-no/
>  35. http://www.haskell.org/mailman/listinfo/haskell
>  36. http://sequence.complete.org/
>  37. http://planet.haskell.org/
>  38. http://sequence.complete.org/node/feed
>  39. http://haskell.org/
>  40. http://haskell.org/haskellwiki/HWN
>  41. http://code.haskell.org/~byorgey/code/hwn/
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/faa86498/attachment.htm
From dons at galois.com  Sun Sep 14 00:29:20 2008
From: dons at galois.com (Don Stewart)
Date: Sun Sep 14 00:26:51 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: 
References: <20080913230727.GA31569@seas.upenn.edu>
	
Message-ID: <20080914042920.GB22084@scytale.galois.com>

dmehrtash:
>    I have a newbie question....  Does theorem proofs have a use for an
>    application?  Take for example the IRC bot example
>    ([1]http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot)  listed
>    below.  Is there any insight to be gained by theorem proofs (as in COQ)
>    into the app? 

Some customers require very high level of assurance that there are no
bugs in the code you ship to them. Theorem proving is one great way to
make those assurances.

-- Don

P.S.



In fact, it's the subject of a talk on Tuesday,

    http://www.galois.com/blog/2008/09/11/theorem-proving-for-verification/



From jgoerzen at complete.org  Sun Sep 14 00:37:43 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Sun Sep 14 00:35:26 2008
Subject: [Haskell-cafe] ANN: pandoc 1.0.0.1
In-Reply-To: <22f6a8f70809131931m2f8804a8na16f544ae81478c9@mail.gmail.com>
References: <20080914012909.GA16164@berkeley.edu>
	<22f6a8f70809131931m2f8804a8na16f544ae81478c9@mail.gmail.com>
Message-ID: <20080914043743.GA12242@complete.org>

On Sat, Sep 13, 2008 at 09:31:50PM -0500, brian wrote:
> On Sat, Sep 13, 2008 at 8:29 PM, John MacFarlane  wrote:
> > + Code is -Wall clean
> 
> Thanks, I appreciate it. I wish more people paid attention to this.

Well.  I often pay attention to it.  That doesn't mean I always heed
it ;-)

Like all -Wall stuff, sometimes warnings are great and sometimes
warnings are noise.

There are two warnings that I am prone to ignore:

1) No type definition for top-level declarations

Whether or not I ignore this depends on what sort of code I'm working
on.  If I'm using Haskell as, essentially, a script language, or
writing a quick and small Parsec parser, adding a bunch of type
declarations can serve to make the code less readable and certainly
more difficult to update and maintain.  That said, for larger projects
or computation algorithms, I'd usually add declarations.

When I'm leaving off the declarations, my code sometimes winds up
looking like something vaguely resembling Python.  Sometimes time
declarations just get in the way.  Cue type inference.  One of my
favorite things about Haskell: it can be as compact as Python (or
moreso), yet detect type errors at compile time.

2) Variable x defined but not used

I most often ignore this when it occurs in a function definition.
Sometimes I may have a function that could be written

foo _ (x, _) _ = bar (x + 5)

But for clarity's sake on what all the unused args are, which really
helps for future maintainability, I'll usually use a descriptive --
but unused -- variable name.

Some of my libraries, on the other hand, are periodically validated
against -Wall -Werror.

-- John
From dmehrtash at gmail.com  Sun Sep 14 01:24:50 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Sun Sep 14 01:22:27 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <20080914042920.GB22084@scytale.galois.com>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
Message-ID: 

What I am trying to figure out is that say on the code for the IRC bot that
is show here

http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot/Source

What would theorem proofs do for me?

Daryoush

On Sat, Sep 13, 2008 at 9:29 PM, Don Stewart  wrote:

> dmehrtash:
> >    I have a newbie question....  Does theorem proofs have a use for an
> >    application?  Take for example the IRC bot example
> >    ([1]http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot)  listed
> >    below.  Is there any insight to be gained by theorem proofs (as in
> COQ)
> >    into the app?
>
> Some customers require very high level of assurance that there are no
> bugs in the code you ship to them. Theorem proving is one great way to
> make those assurances.
>
> -- Don
>
> P.S.
>
> 
>
> In fact, it's the subject of a talk on Tuesday,
>
>    http://www.galois.com/blog/2008/09/11/theorem-proving-for-verification/
>
> 
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080913/7ceab048/attachment.htm
From thomas.dubuisson at gmail.com  Sun Sep 14 04:56:07 2008
From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson)
Date: Sun Sep 14 01:53:53 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: 
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
Message-ID: <1221382567.3668.30.camel@myhost>


> What would theorem proofs do for me?   
Imagine if you used SmallCheck to exhastively test the ENTIRE problem
space for a given property.  Now imagine you used your brain to show the
programs correctness before the heat death of the universe...

Proofs are not features, nor are they code.  What you prove is entirely
up to you and might not be what you think.  Take, for example, the issue
of proving a sort function works correctly [1].

I'm not saying this to discourage complete proofs, but just cautioning
you that proving something as unimportant and IO laden as an IRC bot
probably isn't the best example.  Do see the linked PDF, and [2] as
well.

Oh, and for examples where people should have used FM, search for
'ariane 1996'  or the gulf war patriot missle failure

TomMD

[1]
http://www.cl.cam.ac.uk/~mjcg/Teaching/SpecVer1/Lectures/pslides07x4.pdf
[2] http://users.lava.net/~newsham/formal/reverse/

From allbery at ece.cmu.edu  Sun Sep 14 01:59:53 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sun Sep 14 01:57:37 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: 
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
Message-ID: <07670839-8885-412D-9C01-008FA1F4D4A1@ece.cmu.edu>

On 2008 Sep 14, at 1:24, Daryoush Mehrtash wrote:
> What I am trying to figure out is that say on the code for the IRC  
> bot that is show here
>
> http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot/Source
>
> What would theorem proofs do for me?


Assurance of correct operation; for example, a mathematically provable  
lack of security holes, assuming you can describe its proper operation  
in terms of suitable theorems (which, for a simple bot like that, is  
not so difficult).

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080914/6cc2d240/attachment.htm
From jason.dusek at gmail.com  Sun Sep 14 03:22:22 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Sun Sep 14 03:19:58 2008
Subject: [Haskell-cafe] static linking failure -- can't find crt0
Message-ID: <42784f260809140022h5ca85bf7v29302fd475cf3c26@mail.gmail.com>

  I'm building a "really static" executable on OS X with options
  `-optl-static -static` and, while the libraries seem to link
  fine, the executable itself does not -- it can't find the C
  runtime.

  This is actually by design -- Apple "does not support" static
  binaries. There is a work around -- just symlink stuff till
  the errors go away -- but it might be better if I could
  statically link only those C libraries that I knew were not on
  stock Macs. Are there GHC options for that?

  I assume this all works fine on Linux and Windows, but I'll
  know soon enough...

--
_jsn


 |...can't find the C runtime.|
  ld_classic: can't locate file for: -lcrt0.o
  collect2: ld returned 1 exit status

 |"does not support"|
  http://developer.apple.com/qa/qa2001/qa1118.html
From argaldo.haskell at gmail.com  Sun Sep 14 06:17:52 2008
From: argaldo.haskell at gmail.com (Alberto R. Galdo)
Date: Sun Sep 14 06:15:52 2008
Subject: [Haskell-cafe] Hugs on the iphone
Message-ID: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>

Hi, is there any chance of having hugs  compile for the iPhone?

Cross-compiling? Compiling directly on the iPhone?

Greets,
Alberto
From almeidaraf at gmail.com  Sun Sep 14 06:59:06 2008
From: almeidaraf at gmail.com (Rafael Almeida)
Date: Sun Sep 14 06:56:43 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <1221382567.3668.30.camel@myhost>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
	<1221382567.3668.30.camel@myhost>
Message-ID: <6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>

On Sun, Sep 14, 2008 at 5:56 AM, Thomas M. DuBuisson
 wrote:
>
>> What would theorem proofs do for me?
> Imagine if you used SmallCheck to exhastively test the ENTIRE problem
> space for a given property.  Now imagine you used your brain to show the
> programs correctness before the heat death of the universe...
>
> Proofs are not features, nor are they code.  What you prove is entirely
> up to you and might not be what you think.  Take, for example, the issue
> of proving a sort function works correctly [1].
>
> I'm not saying this to discourage complete proofs, but just cautioning
> you that proving something as unimportant and IO laden as an IRC bot
> probably isn't the best example.  Do see the linked PDF, and [2] as
> well.
>
> Oh, and for examples where people should have used FM, search for
> 'ariane 1996'  or the gulf war patriot missle failure
>
> TomMD
>
> [1]
> http://www.cl.cam.ac.uk/~mjcg/Teaching/SpecVer1/Lectures/pslides07x4.pdf
> [2] http://users.lava.net/~newsham/formal/reverse/
>

One thing have always bugged me: how do you prove that you have
correctly proven something? I mean, when I write a code I'm formaly
stating what I want to happen and bugs happen. If I try to prove some
part of the code I write more formal text (which generally isn't even
checked by a compiler); how can I be sure that my proof doesn't
contain bugs? Why would it make my program less error-prone? Is there
any article that tries to compare heavy testing with FM?
From batterseapower at hotmail.com  Sun Sep 14 07:07:30 2008
From: batterseapower at hotmail.com (Max Bolingbroke)
Date: Sun Sep 14 07:05:06 2008
Subject: [Haskell-cafe] ANN: pandoc 1.0.0.1
In-Reply-To: <20080914043743.GA12242@complete.org>
References: <20080914012909.GA16164@berkeley.edu>
	<22f6a8f70809131931m2f8804a8na16f544ae81478c9@mail.gmail.com>
	<20080914043743.GA12242@complete.org>
Message-ID: <9d4d38820809140407l4a40e4daq36ada9defafefac0@mail.gmail.com>

2008/9/14 John Goerzen :
> 2) Variable x defined but not used
>
> I most often ignore this when it occurs in a function definition.
> Sometimes I may have a function that could be written
>
> foo _ (x, _) _ = bar (x + 5)
>
> But for clarity's sake on what all the unused args are, which really
> helps for future maintainability, I'll usually use a descriptive --
> but unused -- variable name.

This doesn't appear to be commonly known, but actually any identifier
that /starts/ with an _ will not trigger the unused-arg warning. So if
you wrote your example like this:

foo _stuff (x, _y) _more = bar (x + 5)

It would satisfy both the compiler and your desire for descriptive
variable names.

Cheers,
Max
From chaddai.fouche at gmail.com  Sun Sep 14 07:30:18 2008
From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=)
Date: Sun Sep 14 07:27:54 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
	<1221382567.3668.30.camel@myhost>
	<6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
Message-ID: 

2008/9/14 Rafael Almeida :
>
> One thing have always bugged me: how do you prove that you have
> correctly proven something? I mean, when I write a code I'm formaly
> stating what I want to happen and bugs happen. If I try to prove some
> part of the code I write more formal text (which generally isn't even
> checked by a compiler); how can I be sure that my proof doesn't
> contain bugs? Why would it make my program less error-prone? Is there
> any article that tries to compare heavy testing with FM?

Well, that's where formal prover enter the picture : when you prove
something with Coq, you can be reasonably sure that your proof is
correct. And FM brings absolute certitude a propriety is verified by
your program whereas testing however heavy can only check this
property on a finite set of inputs (using randomly generated input
help alleviate the risk of blind spot but is still limited).

-- 
Jeda?
From deduktionstheorem at web.de  Sun Sep 14 07:42:44 2008
From: deduktionstheorem at web.de (Stephan Friedrichs)
Date: Sun Sep 14 07:40:22 2008
Subject: [Haskell-cafe] Views
In-Reply-To: <48CC099B.2090201@imn.htwk-leipzig.de>
References: <48CC0442.8030905@web.de> <48CC099B.2090201@imn.htwk-leipzig.de>
Message-ID: <48CCF8B4.10508@web.de>

Johannes Waldmann wrote:
>> a) ... to use Maybe
>> b) ... to provide my own Data.Heap.View type
> 
> leave the choice up to the programmer,
> and provide a generic interface,
> accepting any MonadZero (*) instance.
> 
> cf. Data.Set.maxView

AFAIK there has been a vivid discussion about that. I think the crux of
the matter was that a monad is too general. Either there is a result or
there is not. That's precisely the intended use of a Maybe.

Besides, I just learned that Data.Map.{lookup,minView,maxView} and the
like have been modified to return a Maybe in the current GHC head
branch, see [1]. This suggests using Maybe in my case as well.

> 
> [...]
> 

[1]
http://www.haskell.org/ghc/dist/current/docs/libraries/containers/Data-Map.html

-- 

Fr?her hie? es ja: Ich denke, also bin ich.
Heute wei? man: Es geht auch so.

 - Dieter Nuhr
From waldmann at imn.htwk-leipzig.de  Sun Sep 14 08:08:37 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Sun Sep 14 08:06:17 2008
Subject: [Haskell-cafe] Views
In-Reply-To: <48CCF8B4.10508@web.de>
References: <48CC0442.8030905@web.de> <48CC099B.2090201@imn.htwk-leipzig.de>
	<48CCF8B4.10508@web.de>
Message-ID: <48CCFEC5.9010606@imn.htwk-leipzig.de>


> I think the crux of
> the matter was that a monad is too general. Either there is a result or
> there is not. That's precisely the intended use of a Maybe.

Indeed "Monad m =>" is dangerous here
because not every Monad has a reasonable definition of "fail".

But that seems to be a problem in the (current) definition of "Monad",
and its solution was "MonadZero", no?

J.W.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080914/9b2c4100/signature.bin
From ndmitchell at gmail.com  Sun Sep 14 09:40:12 2008
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sun Sep 14 09:37:47 2008
Subject: [Haskell-cafe] Re: [Haskell] Heads Up: code.haskell.org is
	upgrading to darcs 2
In-Reply-To: <20080911075918.GH22720@Macintosh.local>
References: 
	<1218367895.7661.252.camel@localhost>
	
	<1221085020.5395.35.camel@localhost>
	<20080911075918.GH22720@Macintosh.local>
Message-ID: <404396ef0809140640i78b3c776i17a049b7a23007e4@mail.gmail.com>

Hi

I'm currently unable to push to ndm@code.haskell.org:/srv/code/hoogle
using darcs 1.0.9 on Windows Vista, and wasn't able to yesterday
either.  Is code.haskell.org just being slow, or is there a chance
that Hoogle suffered as a result of the upgrade?

Thanks

Neil

On 9/11/08, Eric Y. Kow  wrote:
> > We are upgrading /usr/bin/darcs to version 2 on the machine that hosts
>  > code.haskell.org.
>  >
>  > That means it will be used by everyone who uses ssh to push or pull from
>  > a darcs repository on code.haskell.org. Pulling via http is completely
>  > unaffected.
>
>
> Thanks Duncan!  Now my hope is that we can encourage the good folk at
>  Galois to make a similar upgrade for darcs.haskell.org
>
>
>  --
>  Eric Kow 
>  PGP Key ID: 08AC04F9
>
> _______________________________________________
>  Haskell-Cafe mailing list
>  Haskell-Cafe@haskell.org
>  http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
From ndmitchell at gmail.com  Sun Sep 14 09:41:41 2008
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sun Sep 14 09:39:16 2008
Subject: [Haskell-cafe] Re: [Haskell] Heads Up: code.haskell.org is
	upgrading to darcs 2
In-Reply-To: <404396ef0809140640i78b3c776i17a049b7a23007e4@mail.gmail.com>
References: 
	<1218367895.7661.252.camel@localhost>
	
	<1221085020.5395.35.camel@localhost>
	<20080911075918.GH22720@Macintosh.local>
	<404396ef0809140640i78b3c776i17a049b7a23007e4@mail.gmail.com>
Message-ID: <404396ef0809140641g286d6213p5b655dd3a294e9ad@mail.gmail.com>

Hi

Ignore the previous email message, as soon as I sent the email it
started working - I guess it was just code.haskell.org server issues.

Thanks

Neil

On 9/14/08, Neil Mitchell  wrote:
> Hi
>
>  I'm currently unable to push to ndm@code.haskell.org:/srv/code/hoogle
>  using darcs 1.0.9 on Windows Vista, and wasn't able to yesterday
>  either.  Is code.haskell.org just being slow, or is there a chance
>  that Hoogle suffered as a result of the upgrade?
>
>  Thanks
>
>
>  Neil
>
>
>  On 9/11/08, Eric Y. Kow  wrote:
>  > > We are upgrading /usr/bin/darcs to version 2 on the machine that hosts
>  >  > code.haskell.org.
>  >  >
>  >  > That means it will be used by everyone who uses ssh to push or pull from
>  >  > a darcs repository on code.haskell.org. Pulling via http is completely
>  >  > unaffected.
>  >
>  >
>  > Thanks Duncan!  Now my hope is that we can encourage the good folk at
>  >  Galois to make a similar upgrade for darcs.haskell.org
>  >
>  >
>  >  --
>  >  Eric Kow 
>  >  PGP Key ID: 08AC04F9
>  >
>
> > _______________________________________________
>  >  Haskell-Cafe mailing list
>  >  Haskell-Cafe@haskell.org
>  >  http://www.haskell.org/mailman/listinfo/haskell-cafe
>  >
>  >
>  >
>
From deduktionstheorem at web.de  Sun Sep 14 10:01:48 2008
From: deduktionstheorem at web.de (Stephan Friedrichs)
Date: Sun Sep 14 09:59:25 2008
Subject: [Haskell-cafe] Views
In-Reply-To: <48CCFEC5.9010606@imn.htwk-leipzig.de>
References: <48CC0442.8030905@web.de> <48CC099B.2090201@imn.htwk-leipzig.de>
	<48CCF8B4.10508@web.de> <48CCFEC5.9010606@imn.htwk-leipzig.de>
Message-ID: <48CD194C.50407@web.de>

Johannes Waldmann wrote:
>> I think the crux of
>> the matter was that a monad is too general. Either there is a result or
>> there is not. That's precisely the intended use of a Maybe.
> 
> Indeed "Monad m =>" is dangerous here
> because not every Monad has a reasonable definition of "fail".
> 
> But that seems to be a problem in the (current) definition of "Monad",
> and its solution was "MonadZero", no?

I agree that the MonadZero class with a useful 'zero' :: m a would be
the right abstraction for views. But MonadZero is not part of base, mtl
or any other common package, or am I missing something? Changing this is
beyond a simple heap package ;)

-- 

Fr?her hie? es ja: Ich denke, also bin ich.
Heute wei? man: Es geht auch so.

 - Dieter Nuhr
From Braden.Shepherdson at gmail.com  Sun Sep 14 10:50:42 2008
From: Braden.Shepherdson at gmail.com (Braden Shepherdson)
Date: Sun Sep 14 10:50:35 2008
Subject: [Haskell-cafe] Re: Hugs on the iphone
In-Reply-To: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
Message-ID: 

Alberto R. Galdo wrote:
> Hi, is there any chance of having hugs  compile for the iPhone?
> 
> Cross-compiling? Compiling directly on the iPhone?
> 
> Greets,
> Alberto

The iPhone, like most modern mobile devices, is based on the ARM 
processor, for which there is currently no GHC port.

However, jhc outputs portable C code which can be (cross) compiled for 
ARM. I have succeeded in building Haskell code with jhc on my desktop 
(x86 Linux), then cross-compiling the resulting C code in a scratchbox 
environment for my Nokia N810.

In short, if you can compile C code for the iPhone (cross-compiled or 
native), you can probably use jhc to turn Haskell into suitable C.

jhc is not self-hosting, and it requires gcc as a back-end, so it isn't 
suitable for running on the device.

See also the GHC-on-ARM project[1], an attempt to port GHC to ARM Linux 
devices.


Braden Shepherdson
shepheb

[1] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc

From Braden.Shepherdson at gmail.com  Sun Sep 14 10:56:39 2008
From: Braden.Shepherdson at gmail.com (Braden Shepherdson)
Date: Sun Sep 14 10:56:28 2008
Subject: [Haskell-cafe] Re: Hugs on the iphone
In-Reply-To: 
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
Message-ID: 

Braden Shepherdson wrote:
> Alberto R. Galdo wrote:
>> Hi, is there any chance of having hugs  compile for the iPhone?
>>
>> Cross-compiling? Compiling directly on the iPhone?
>>
>> Greets,
>> Alberto
> 
> The iPhone, like most modern mobile devices, is based on the ARM 
> processor, for which there is currently no GHC port.
> 
> However, jhc outputs portable C code which can be (cross) compiled for 
> ARM. I have succeeded in building Haskell code with jhc on my desktop 
> (x86 Linux), then cross-compiling the resulting C code in a scratchbox 
> environment for my Nokia N810.
> 
> In short, if you can compile C code for the iPhone (cross-compiled or 
> native), you can probably use jhc to turn Haskell into suitable C.
> 
> jhc is not self-hosting, and it requires gcc as a back-end, so it isn't 
> suitable for running on the device.
> 
> See also the GHC-on-ARM project[1], an attempt to port GHC to ARM Linux 
> devices.
> 
> 
> Braden Shepherdson
> shepheb
> 
> [1] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc


I failed completely to mention Hugs: I don't think it exists, but I 
think someone managed to port it to the Nintendo DS a while back, so it 
should be possible.


Braden Shepherdson
shepheb

From duncan.coutts at worc.ox.ac.uk  Sun Sep 14 11:15:57 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Sep 14 11:11:36 2008
Subject: [Haskell-cafe] Re: [Haskell] Heads Up: code.haskell.org is
	upgrading to darcs 2
In-Reply-To: <404396ef0809140641g286d6213p5b655dd3a294e9ad@mail.gmail.com>
References: 
	<1218367895.7661.252.camel@localhost>
	
	<1221085020.5395.35.camel@localhost>
	<20080911075918.GH22720@Macintosh.local>
	<404396ef0809140640i78b3c776i17a049b7a23007e4@mail.gmail.com>
	<404396ef0809140641g286d6213p5b655dd3a294e9ad@mail.gmail.com>
Message-ID: <1221405357.5395.163.camel@localhost>

On Sun, 2008-09-14 at 14:41 +0100, Neil Mitchell wrote:
> Hi
> 
> Ignore the previous email message, as soon as I sent the email it
> started working - I guess it was just code.haskell.org server issues.

Yes it was unavailable for a short time yesterday. It got rebooted by
the hosting company, we're not exactly sure why.

Duncan

From argaldo.haskell at gmail.com  Sun Sep 14 11:17:45 2008
From: argaldo.haskell at gmail.com (Alberto R. Galdo)
Date: Sun Sep 14 11:15:20 2008
Subject: [Haskell-cafe] Re: Hugs on the iphone
In-Reply-To: 
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	 
Message-ID: <51562ec30809140817v4ad214edkfbd2ac813f3c0f8f@mail.gmail.com>

Seems that someone in this list got hugs working on the iPhone...
http://www.nabble.com/Re%3A-xmonad-on-the-openmoko-mobile-phone-p18914746.html

Miguel, are you out there?


On Sun, Sep 14, 2008 at 4:56 PM, Braden Shepherdson <
Braden.Shepherdson@gmail.com> wrote:

> Braden Shepherdson wrote:
>
>> Alberto R. Galdo wrote:
>>
>>> Hi, is there any chance of having hugs  compile for the iPhone?
>>>
>>> Cross-compiling? Compiling directly on the iPhone?
>>>
>>> Greets,
>>> Alberto
>>>
>>
>> The iPhone, like most modern mobile devices, is based on the ARM
>> processor, for which there is currently no GHC port.
>>
>> However, jhc outputs portable C code which can be (cross) compiled for
>> ARM. I have succeeded in building Haskell code with jhc on my desktop (x86
>> Linux), then cross-compiling the resulting C code in a scratchbox
>> environment for my Nokia N810.
>>
>> In short, if you can compile C code for the iPhone (cross-compiled or
>> native), you can probably use jhc to turn Haskell into suitable C.
>>
>> jhc is not self-hosting, and it requires gcc as a back-end, so it isn't
>> suitable for running on the device.
>>
>> See also the GHC-on-ARM project[1], an attempt to port GHC to ARM Linux
>> devices.
>>
>>
>> Braden Shepherdson
>> shepheb
>>
>> [1] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc
>>
>
>
> I failed completely to mention Hugs: I don't think it exists, but I think
> someone managed to port it to the Nintendo DS a while back, so it should be
> possible.
>
>
> Braden Shepherdson
> shepheb
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080914/c72f4fa0/attachment.htm
From dan.doel at gmail.com  Sun Sep 14 11:35:37 2008
From: dan.doel at gmail.com (Dan Doel)
Date: Sun Sep 14 11:26:35 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
References: <20080913230727.GA31569@seas.upenn.edu>
	<1221382567.3668.30.camel@myhost>
	<6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
Message-ID: <200809141135.38719.dan.doel@gmail.com>

On Sunday 14 September 2008 6:59:06 am Rafael Almeida wrote:
> One thing have always bugged me: how do you prove that you have
> correctly proven something? I mean, when I write a code I'm formaly
> stating what I want to happen and bugs happen. If I try to prove some
> part of the code I write more formal text (which generally isn't even
> checked by a compiler); how can I be sure that my proof doesn't
> contain bugs? Why would it make my program less error-prone? Is there
> any article that tries to compare heavy testing with FM?

This isn't really a problem if you're programming in a language in which the 
proofs of program correctness are checked by the compiler/what have you, as 
Chadda? has already said. In that case, it's similar to asking, "how do I know 
my Haskell programs are actually type correct?" Barring bugs in the tools 
(which, in the ideal case, are built on a simple enough foundation to be 
confidently proven correct by hand), it's not so much a concern.

A more difficult question is: how do I know that the formal specification I've 
written for my program is the right one? Tools can fairly easily check that 
your programs conform to a given specification, but they cannot (to my 
knowledge) check that your specification says exactly what you want it to say.

Of course, this is no worse than the case with test suites, since one can 
similarly ask, "how can I be sure the tests check for the properties/behavior 
that I actually want?"

-- Dan
From allbery at ece.cmu.edu  Sun Sep 14 11:30:56 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sun Sep 14 11:28:40 2008
Subject: [Haskell-cafe] Views
In-Reply-To: <48CD194C.50407@web.de>
References: <48CC0442.8030905@web.de> <48CC099B.2090201@imn.htwk-leipzig.de>
	<48CCF8B4.10508@web.de> <48CCFEC5.9010606@imn.htwk-leipzig.de>
	<48CD194C.50407@web.de>
Message-ID: <6713889E-2315-4984-BDDC-C13D71343B60@ece.cmu.edu>

On 2008 Sep 14, at 10:01, Stephan Friedrichs wrote:
> Johannes Waldmann wrote:
>>> I think the crux of
>>> the matter was that a monad is too general. Either there is a  
>>> result or
>>> there is not. That's precisely the intended use of a Maybe.
>>
>> Indeed "Monad m =>" is dangerous here
>> because not every Monad has a reasonable definition of "fail".
>>
>> But that seems to be a problem in the (current) definition of  
>> "Monad",
>> and its solution was "MonadZero", no?
>
> I agree that the MonadZero class with a useful 'zero' :: m a would be
> the right abstraction for views. But MonadZero is not part of base,  
> mtl
> or any other common package, or am I missing something? Changing  
> this is
> beyond a simple heap package ;)


MonadZero is what "fail" replaced in Haskell98.  Many people consider  
this a serious mistake.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From trebla at vex.net  Sun Sep 14 13:24:18 2008
From: trebla at vex.net (Albert Y. C. Lai)
Date: Sun Sep 14 13:21:54 2008
Subject: [Haskell-cafe] random colors, stack space overflow,	mersenne
	and mersenne.pure64
In-Reply-To: <1ff5dedc0809122034i340a3b94y48fbde2ce6f3effa@mail.gmail.com>
References: <1ff5dedc0809121855w5d531f20xe7d77a975aaa5a82@mail.gmail.com>	<20080913015737.GB18949@scytale.galois.com>	<047E24EF-F9AA-4A06-9D93-8B0FF395E399@ece.cmu.edu>
	<1ff5dedc0809122034i340a3b94y48fbde2ce6f3effa@mail.gmail.com>
Message-ID: <48CD48C2.3000407@vex.net>

Cetin Sert wrote:
> main = do
>   as <- getArgs
[...]
>   where
>     lo = read $ as !! 0
>     hi = read $ as !! 1
>     tx =        as !! 2
> 
> Why is as not visible in the where block?

The where-block is outside the do-block. (Indentation cannot change that 
fact.)

From marcot at riseup.net  Sun Sep 14 13:24:23 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Sun Sep 14 13:22:15 2008
Subject: [Haskell-cafe] system in forkIO
Message-ID: <1221413063.12151.3.camel@quindinho.domain.invalid>

Hello.

> import System.Cmd
> import GHC.Conc
> 
> main :: IO ()
> main
>   = forkIO
>     ( do
>         putStrLn "fork"
>         system "ls"
>         return ())
>     >> getChar
>     >> return ()

When I run this code, I get

fork

and the result of ls only after I press a key.  Does getChar blocks the
other threads?

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From mailing_list at istitutocolli.org  Sun Sep 14 13:51:17 2008
From: mailing_list at istitutocolli.org (Andrea Rossato)
Date: Sun Sep 14 13:48:56 2008
Subject: [Haskell-cafe] system in forkIO
In-Reply-To: <1221413063.12151.3.camel@quindinho.domain.invalid>
References: <1221413063.12151.3.camel@quindinho.domain.invalid>
Message-ID: <20080914175117.GM23265@Andrea.Nowhere.net>

On Sun, Sep 14, 2008 at 02:24:23PM -0300, Marco T?lio Gontijo e Silva wrote:
> and the result of ls only after I press a key.  Does getChar blocks the
> other threads?

yes, but you can use forkOS from Control.Concurrent and compile with
-threaded.

See the relevant documentation for the details.

Hope this helps,
Andrea
From judah.jacobson at gmail.com  Sun Sep 14 14:08:12 2008
From: judah.jacobson at gmail.com (Judah Jacobson)
Date: Sun Sep 14 14:05:46 2008
Subject: [Haskell-cafe] system in forkIO
In-Reply-To: <1221413063.12151.3.camel@quindinho.domain.invalid>
References: <1221413063.12151.3.camel@quindinho.domain.invalid>
Message-ID: <6d74b0d20809141108m59f1f8f4p32fc6e5e8986c334@mail.gmail.com>

On Sun, Sep 14, 2008 at 10:24 AM, Marco T?lio Gontijo e Silva
 wrote:
<
> When I run this code, I get
>
> fork
>
> and the result of ls only after I press a key.  Does getChar blocks the
> other threads?
>

I think this behavior is caused by (or at least related to) the
following GHC bug:

http://hackage.haskell.org/trac/ghc/ticket/2363

That bug has been fixed for the 6.10 release; my testing indicated
that your program behaves correctly in that version.  See the above
bug report for some suggestions on how to work around the 6.8 getChar
blocking.

Hope that helps,
-Judah
From jeremy at n-heptane.com  Sun Sep 14 14:18:49 2008
From: jeremy at n-heptane.com (Jeremy Shaw)
Date: Sun Sep 14 14:10:22 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
Message-ID: <87ljxu1th2.wl%jeremy@n-heptane.com>

At Sun, 14 Sep 2008 12:17:52 +0200,
Alberto R. Galdo wrote:
> 
> Hi, is there any chance of having hugs  compile for the iPhone?
> 
> Cross-compiling? Compiling directly on the iPhone?

I have successfully compiled hugs for the Nokia 770 which is ARM
based. I don't remember having to do anything special. I think it just
built out of the box, since hugs is just a C application and does not
have many build dependencies.

j.
From simon.clarkstone at gmail.com  Sun Sep 14 14:21:19 2008
From: simon.clarkstone at gmail.com (Simon Richard Clarkstone)
Date: Sun Sep 14 14:18:46 2008
Subject: [Haskell-cafe] message passing style in Monad
In-Reply-To: <81ea7d400809100614y3a518d65o318b3e2f966e1340@mail.gmail.com>
References: <81ea7d400809100614y3a518d65o318b3e2f966e1340@mail.gmail.com>
Message-ID: <48CD561F.8080006@gmail.com>

jinjing wrote:
> I found that as I can do
> 
>   xs.map(+1).sort
> 
> by redefine . to be
> 
>   a . f = f a
>   infixl 9 .

This looks rather like ($), but backwards.  I believe the F# name for 
this operator is (|>), which is also a legal name for it in Haskell. 
Odd, since (|) alone isn't legal.  Calling it (.) will confuse the heck 
out of anyone who maintains your code though, and make any transfer of 
code between your projects and other people's liable to introduce bugs.

> I can also do
> 
>   readFile "readme.markdown" <.> lines <.> length
> 
> by making
> 
>   a <.> b = a .liftM b
>   infixl 9 <.>
> 
> Kinda annoying, but the option is there.

Now that looks more interesting.  Another name for it is (>>=^), since 
it is like (>>=) but lifts its right argument.  I know the Fudgets 
library uses "^" in operators for a similar "lifting" meaning.

-- 
src/
From dmehrtash at gmail.com  Sun Sep 14 14:31:09 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Sun Sep 14 14:28:44 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
Message-ID: 

I have been told that for a Haskell/Functional programmer the process
of design starts with defining Semantic Domain, Function, and
denotational model of the problem.  I have done some googling on the
topic but haven't found a good reference on it.    I would appreciate
any good references on the topic.

thanks,

daryoush

ps.  I have found referneces like
http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
which doesn't do any good for me.    I need something with a more real
examples.
From jeanphilippe.bernardy at gmail.com  Sun Sep 14 14:41:33 2008
From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy)
Date: Sun Sep 14 14:39:16 2008
Subject: [Haskell-cafe] Re: Semantic Domain, Function,	and
	denotational model.....
References: 
Message-ID: 

Daryoush Mehrtash  gmail.com> writes:

> 
> I have been told that for a Haskell/Functional programmer the process
> of design starts with defining Semantic Domain, Function, and
> denotational model of the problem.  I have done some googling on the
> topic but haven't found a good reference on it.    I would appreciate
> any good references on the topic.

http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/lectures.html

The whole course is interesting but lectures 2&3 are more specifically about
your concern.

-- JP



From iavor.diatchki at gmail.com  Sun Sep 14 14:57:37 2008
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun Sep 14 14:55:12 2008
Subject: [Haskell-cafe] Views
In-Reply-To: <48CD194C.50407@web.de>
References: <48CC0442.8030905@web.de> <48CC099B.2090201@imn.htwk-leipzig.de>
	<48CCF8B4.10508@web.de> <48CCFEC5.9010606@imn.htwk-leipzig.de>
	<48CD194C.50407@web.de>
Message-ID: <5ab17e790809141157iebd902eg5187dd1c8f04509a@mail.gmail.com>

Hi,

On Sun, Sep 14, 2008 at 7:01 AM, Stephan Friedrichs
 wrote:
> I agree that the MonadZero class with a useful 'zero' :: m a would be
> the right abstraction for views. But MonadZero is not part of base, mtl
> or any other common package, or am I missing something? Changing this is
> beyond a simple heap package ;)

The class "ExceptionM" from monadLib captures this functionality.
However, for this simple case 'Maybe' seems quite enough because it is
what you need most of the time.   Furthermore, it does not loose any
generality because you can use a function of type :: MonadZero m =>
Maybe a -> m a, to convert to other monads, if it is necessary.
-Iavor
From marcot at riseup.net  Sun Sep 14 15:07:31 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Sun Sep 14 15:05:09 2008
Subject: [Haskell-cafe] system in forkIO
In-Reply-To: <6d74b0d20809141108m59f1f8f4p32fc6e5e8986c334@mail.gmail.com>
References: <1221413063.12151.3.camel@quindinho.domain.invalid>
	<6d74b0d20809141108m59f1f8f4p32fc6e5e8986c334@mail.gmail.com>
Message-ID: <1221419251.13048.9.camel@quindinho.domain.invalid>

Em Dom, 2008-09-14 ?s 11:08 -0700, Judah Jacobson escreveu:
> On Sun, Sep 14, 2008 at 10:24 AM, Marco T?lio Gontijo e Silva
>  wrote:
> <
> > When I run this code, I get
> >
> > fork
> >
> > and the result of ls only after I press a key.  Does getChar blocks the
> > other threads?
> >
> 
> I think this behavior is caused by (or at least related to) the
> following GHC bug:
> 
> http://hackage.haskell.org/trac/ghc/ticket/2363

Thanks, I got it to work running 

threadWaitRead stdInput

before getChar.  Only changing forkIO for forkOS gave me the same
result.

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From jules at jellybean.co.uk  Sun Sep 14 15:10:09 2008
From: jules at jellybean.co.uk (Jules Bean)
Date: Sun Sep 14 15:07:42 2008
Subject: [Haskell-cafe] system in forkIO
In-Reply-To: <20080914175117.GM23265@Andrea.Nowhere.net>
References: <1221413063.12151.3.camel@quindinho.domain.invalid>
	<20080914175117.GM23265@Andrea.Nowhere.net>
Message-ID: <48CD6191.4080602@jellybean.co.uk>

Andrea Rossato wrote:
> On Sun, Sep 14, 2008 at 02:24:23PM -0300, Marco T?lio Gontijo e Silva wrote:
>> and the result of ls only after I press a key.  Does getChar blocks the
>> other threads?
> 
> yes, but you can use forkOS from Control.Concurrent and compile with
> -threaded.
> 
> See the relevant documentation for the details.

forkOS not relevant here.

-threaded is necessary to allow haskell code to run whilst FFI calls are 
blocked. getChar doesn't count as an FFI call (the RTS does its own IO 
multiplexing) but system does.

forkOS is to do with bound threads, that's something else.

Jules
From ketil at malde.org  Sun Sep 14 15:32:16 2008
From: ketil at malde.org (Ketil Malde)
Date: Sun Sep 14 15:27:28 2008
Subject: [Haskell-cafe] message passing style in Monad
In-Reply-To: <48CD561F.8080006@gmail.com> (Simon Richard Clarkstone's message
	of "Sun\, 14 Sep 2008 19\:21\:19 +0100")
References: <81ea7d400809100614y3a518d65o318b3e2f966e1340@mail.gmail.com>
	<48CD561F.8080006@gmail.com>
Message-ID: <871vzmbk1r.fsf@malde.org>

Simon Richard Clarkstone  writes:

>> I can also do
>>
>>   readFile "readme.markdown" <.> lines <.> length
>>
>> by making

(<.>) = flip fmap

?

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From lgreg.meredith at biosimilarity.com  Sun Sep 14 17:39:38 2008
From: lgreg.meredith at biosimilarity.com (Greg Meredith)
Date: Sun Sep 14 17:37:13 2008
Subject: [Haskell-cafe] Re: Proofs and commercial code -- was Haskell Weekly
	News: Issue 85 - September 13, 2008
Message-ID: <5de3f5ca0809141439y43e34762h32c0233f72c6788d@mail.gmail.com>

Daryoush,

One of the subtle points about computation is that -- via Curry-Howard --
well-typed programs are *already* proofs. They may not be the proof you were
seeking (there are a lot of programs from Int -> Int), or prove the theorem
you were seeking to prove (Ord a => [a] -> [a] is a lot weaker than 'this
program sorts lists of ordered types'), but they are witnesses of any type
they type-check against. In a system that has principal types, they are
proofs of their principal type. In this sense, the utility of proofs is
widespread: they are programs.

There is a really subtle dance between types that are rich enough to express
the theorems you would have your programs be proofs of and the termination
of type-checking for that type system. That's why people often do proofs by
hand -- because the theorems they need to prove require a greater degree of
expressiveness than is available in the type system supported by the
language in which the programs are expressed. Research has really been
pushing the envelope of what's expressible in types -- from region and
resource analysis to deadlock-freedom. Again, in that setting the program is
a witness of a property like

   - won't leak URLs to unsavory agents
   - won't hold on to handles past their garbage-collect-by date
   - won't get caught in a 'deadly embrace' (A is waiting for B, B is
   waiting for A)

Sometimes, however, and often in mission critical code, you need stronger
assurances, like

   - this code really does implement a FIFO queue, or
   - this code really does implement sliding window protocol, or
   - this code really does implement two-phase-commit-presumed-abort

It's harder -- in fact i think it's impossible for bullet item 2 above -- to
squeeze these into terminating type-checks. In those cases, you have to
escape out to a richer relationship between 'theorem' (aka type) and 'proof'
(aka program). Proof assistants, like Coq, or Hol or... can be very helpful
for automating some of the tasks, leaving the inventive bits to the humans.

In my experience, a proof of a theorem about some commercial code is pursued
when the cost of developing the proof is less than some multiple of the cost
of errors in the program in the life-cycle of that program. Intel, and other
hardware vendors, for example, can lose a lot of business when the
implementation of floating point operations is buggy; and, there is a
breaking point where the complexity/difficulty/cost of proving the
implementation correct is sufficiently less than that of business lost that
it is to their advantage to obtain the kind of quality assurance that can be
had from a proof of correctness.

One other place where proofs of correctness will be pursued is in
mathematical proofs, themselves. To the best of my knowledge, nothing
mission-critical is currently riding on the proof of the 4-color theorem.
The proof -- last i checked -- required programmatic checking of many cases.
Proving the program -- that implements the tedious parts of the proof --
correct is pursued because of the culture and standard of mathematical
proof.

Best wishes,

--greg

Date: Sat, 13 Sep 2008 22:24:50 -0700
From: "Daryoush Mehrtash" 
Subject: Re: [Haskell-cafe] Haskell Weekly News: Issue 85 - September
       13, 2008
To: "Don Stewart" 
Cc: Haskell Cafe 
Message-ID:
       
Content-Type: text/plain; charset="iso-8859-1"

What I am trying to figure out is that say on the code for the IRC bot that
is show here

http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot/Source

What would theorem proofs do for me?

Daryoush

-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080914/2323ae38/attachment.htm
From marcot at riseup.net  Sun Sep 14 17:50:06 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Sun Sep 14 17:47:44 2008
Subject: [Haskell-cafe] system in forkIO
In-Reply-To: <1221419251.13048.9.camel@quindinho.domain.invalid>
References: <1221413063.12151.3.camel@quindinho.domain.invalid>
	<6d74b0d20809141108m59f1f8f4p32fc6e5e8986c334@mail.gmail.com>
	<1221419251.13048.9.camel@quindinho.domain.invalid>
Message-ID: <1221429006.3879.8.camel@quindinho.domain.invalid>

Em Dom, 2008-09-14 ?s 16:07 -0300, Marco T?lio Gontijo e Silva escreveu:
> Thanks, I got it to work running 
> 
> threadWaitRead stdInput
> 
> before getChar.

Now I've got another problem:

> import Control.Concurrent
> import System.IO
> import System.Process

> main :: IO ()
> main
>   = do
>     process <- runCommand "wget
http://ftp.br.debian.org/debian/pool/main/g/ghc6/ghc6_6.8.2-6_amd64.deb"
>     forkIO
>       $ putStrLn "fork"
>       >> getChar >>= putChar
>       >> terminateProcess process
>     waitForProcess process
>     return ()

Not even fork is shown.  Any hints?

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From dons at galois.com  Sun Sep 14 17:52:28 2008
From: dons at galois.com (Don Stewart)
Date: Sun Sep 14 17:49:55 2008
Subject: [Haskell-cafe] system in forkIO
In-Reply-To: <1221429006.3879.8.camel@quindinho.domain.invalid>
References: <1221413063.12151.3.camel@quindinho.domain.invalid>
	<6d74b0d20809141108m59f1f8f4p32fc6e5e8986c334@mail.gmail.com>
	<1221419251.13048.9.camel@quindinho.domain.invalid>
	<1221429006.3879.8.camel@quindinho.domain.invalid>
Message-ID: <20080914215228.GA26077@scytale.galois.com>

marcot:
> Em Dom, 2008-09-14 ?s 16:07 -0300, Marco T?lio Gontijo e Silva escreveu:
> > Thanks, I got it to work running 
> > 
> > threadWaitRead stdInput
> > 
> > before getChar.
> 
> Now I've got another problem:
> 
> > import Control.Concurrent
> > import System.IO
> > import System.Process
> 
> > main :: IO ()
> > main
> >   = do
> >     process <- runCommand "wget
> http://ftp.br.debian.org/debian/pool/main/g/ghc6/ghc6_6.8.2-6_amd64.deb"
> >     forkIO
> >       $ putStrLn "fork"
> >       >> getChar >>= putChar
> >       >> terminateProcess process
> >     waitForProcess process
> >     return ()
> 
> Not even fork is shown.  Any hints?

Daemonic threads. When the main thread exits, everything exits. Check
the docs for Control.Concurrent.

You better use an MVar to ensure the main thread waits on its child.

-- Don
From marcot at riseup.net  Sun Sep 14 18:19:04 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Sun Sep 14 18:18:30 2008
Subject: [Haskell-cafe] system in forkIO
In-Reply-To: <20080914215228.GA26077@scytale.galois.com>
References: <1221413063.12151.3.camel@quindinho.domain.invalid>
	<6d74b0d20809141108m59f1f8f4p32fc6e5e8986c334@mail.gmail.com>
	<1221419251.13048.9.camel@quindinho.domain.invalid>
	<1221429006.3879.8.camel@quindinho.domain.invalid>
	<20080914215228.GA26077@scytale.galois.com>
Message-ID: <1221430744.3879.22.camel@quindinho.domain.invalid>

Em Dom, 2008-09-14 ?s 14:52 -0700, Don Stewart escreveu:
> marcot:
> > Em Dom, 2008-09-14 ?s 16:07 -0300, Marco T?lio Gontijo e Silva escreveu:
> > > Thanks, I got it to work running 
> > > 
> > > threadWaitRead stdInput
> > > 
> > > before getChar.
> > 
> > Now I've got another problem:
> > 
> > > import Control.Concurrent
> > > import System.IO
> > > import System.Process
> > 
> > > main :: IO ()
> > > main
> > >   = do
> > >     process <- runCommand "wget
> > http://ftp.br.debian.org/debian/pool/main/g/ghc6/ghc6_6.8.2-6_amd64.deb"
> > >     forkIO
> > >       $ putStrLn "fork"
> > >       >> getChar >>= putChar
> > >       >> terminateProcess process
> > >     waitForProcess process
> > >     return ()
> > 
> > Not even fork is shown.  Any hints?
> 
> Daemonic threads. When the main thread exits, everything exits. Check
> the docs for Control.Concurrent.
> 
> You better use an MVar to ensure the main thread waits on its child.

I don't think this is the problem because the mais thread is not
exiting.  wget takes a lot of time to end, and I never really wait it to
finish.  I wanted to enable the user to interrupt it, but if it's
finished, I don't want to wait for the user input anymore, so the child
thread can exit with the main one.

I just noticed that if I add a putStrLn "wait" before waitForProcess,
it'll print wait and then fork.  I couldn't understand why this
happened, but I can't still pass through getChar to get to
terminateProcess.

Is it right to call getChar inside a forkIO?

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From cetin.sert at gmail.com  Sun Sep 14 20:24:14 2008
From: cetin.sert at gmail.com (Cetin Sert)
Date: Sun Sep 14 20:21:48 2008
Subject: [Haskell-cafe] ask
Message-ID: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>

Hi why do I get?

cetin@linux-d312:~/lab/exp/1> ./eq
23
23
3
a = b = c = n1-0.8457820374040622n2-0.1542179625959377

when I run

import System.IO

main :: IO ()
main = do
  a ? ask "a"
  b ? ask "b"
  c ? ask "c"
  eval a b c

ask v = do
  putStr (v ++ " = ")
  readLn

eval a b c = do
  case delta < 0 of
    True  ? putStr "neg"
    False ? putStr ("n1" ++ show n1 ++ "n2" ++ show n2)
  where
    delta = b*b - 4*c*a
    n  o  = (-b `o` sqrt(delta))/(2*a)
    n1    = n (+)
    n2    = n (-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080915/5bd86f4d/attachment.htm
From allbery at ece.cmu.edu  Sun Sep 14 20:47:15 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sun Sep 14 20:44:55 2008
Subject: [Haskell-cafe] ask
In-Reply-To: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
References: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
Message-ID: <01FF0B42-1624-4B6E-8C8E-A36E750755EC@ece.cmu.edu>

On 2008 Sep 14, at 20:24, Cetin Sert wrote:
> Hi why do I get?
>
> cetin@linux-d312:~/lab/exp/1> ./eq
> 23
> 23
> 3
> a = b = c = n1-0.8457820374040622n2-0.1542179625959377

As is typical for Unix, filehandles including standard input and  
standard output are line buffered.  See hSetBuffering ( http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AhSetBuffering 
  ).

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080914/d735bb97/attachment-0001.htm
From jeremy at n-heptane.com  Sun Sep 14 20:54:52 2008
From: jeremy at n-heptane.com (Jeremy Shaw)
Date: Sun Sep 14 20:46:23 2008
Subject: [Haskell-cafe] ask
In-Reply-To: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
References: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
Message-ID: <87k5de1b4z.wl%jeremy@n-heptane.com>

Hello,

If we look at these two examples, it appears that the results are reversed:

Prelude> let n o = (-1 `o` 1) in n (-)
0
Prelude> let n o = (-1 `o` 1) in n (+)
-2
Prelude> 

we expect (-1 - 1) = -2 and (-1 + 1) = 0, but we get the opposite.

Due to operator precedence, the equations are being interpreted as:

Prelude> let n o = (-(1 `o` 1)) in n (-)
0
Prelude> let n o = (-(1 `o` 1)) in n (+)
-2

The fix is to use parens around a negative term:

Prelude> let n o = ((-1) `o` 1) in n (-)
-2
Prelude> let n o = ((-1) `o` 1) in n (+)
0
Prelude> 

I have heard complaints about the negation sign in Haskell before, I
suppose this is why. Hopefully someone else can provide more details.

j.

ps. You could probably also fix it by changing the precedence of the
`o` operator. I believe that is possible. But parens around (-b) is
the more standard solution.

At Mon, 15 Sep 2008 02:24:14 +0200,
Cetin Sert wrote:
> 
> Hi why do I get?
> 
> cetin@linux-d312:~/lab/exp/1> ./eq
> 23
> 23
> 3
> a = b = c = n1-0.8457820374040622n2-0.1542179625959377
> 
> when I run
> 
> import System.IO
> 
> main :: IO ()
> main = do
>   a ? ask "a"
>   b ? ask "b"
>   c ? ask "c"
>   eval a b c
> 
> ask v = do
>   putStr (v ++ " = ")
>   readLn
> 
> eval a b c = do
>   case delta < 0 of
>     True  ? putStr "neg"
>     False ? putStr ("n1" ++ show n1 ++ "n2" ++ show n2)
>   where
>     delta = b*b - 4*c*a
>     n  o  = (-b `o` sqrt(delta))/(2*a)
>     n1    = n (+)
>     n2    = n (-)
From daniel.is.fischer at web.de  Sun Sep 14 20:51:37 2008
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Sun Sep 14 20:47:06 2008
Subject: [Haskell-cafe] ask
In-Reply-To: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
References: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
Message-ID: <200809150251.37805.daniel.is.fischer@web.de>

Am Montag, 15. September 2008 02:24 schrieb Cetin Sert:
> Hi why do I get?

Buffering. For compiled programmes, stdin and stdout are line-buffered by 
default, so the output doesn't appear until the program finishes.
Either put
hSetBuffering stdout NoBuffering
at the top of main or, better IMO,
insert a 
hFlush stdout
into ask before the readLn.
And in eval, putStrLn would be better, I think.

HTH,
Daniel
>
> cetin@linux-d312:~/lab/exp/1> ./eq
> 23
> 23
> 3
> a = b = c = n1-0.8457820374040622n2-0.1542179625959377
>
> when I run
>
> import System.IO
>
> main :: IO ()
> main = do
>   a ? ask "a"
>   b ? ask "b"
>   c ? ask "c"
>   eval a b c
>
> ask v = do
>   putStr (v ++ " = ")
>   readLn
>
> eval a b c = do
>   case delta < 0 of
>     True  ? putStr "neg"
>     False ? putStr ("n1" ++ show n1 ++ "n2" ++ show n2)
>   where
>     delta = b*b - 4*c*a
>     n  o  = (-b `o` sqrt(delta))/(2*a)
>     n1    = n (+)
>     n2    = n (-)

From allbery at ece.cmu.edu  Sun Sep 14 20:50:14 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sun Sep 14 20:47:52 2008
Subject: [Haskell-cafe] ask
In-Reply-To: <01FF0B42-1624-4B6E-8C8E-A36E750755EC@ece.cmu.edu>
References: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
	<01FF0B42-1624-4B6E-8C8E-A36E750755EC@ece.cmu.edu>
Message-ID: 

On 2008 Sep 14, at 20:47, Brandon S. Allbery KF8NH wrote:
> On 2008 Sep 14, at 20:24, Cetin Sert wrote:
>> Hi why do I get?
>>
>> cetin@linux-d312:~/lab/exp/1> ./eq
>> 23
>> 23
>> 3
>> a = b = c = n1-0.8457820374040622n2-0.1542179625959377
>
> As is typical for Unix, filehandles including standard input and  
> standard output are line buffered.  See hSetBuffering ( http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AhSetBuffering 
>  ).

Also, looking at that path, I'm tempted to point you to http://www.haskell.org/haskellwiki/Homework_help 
  .

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080914/805ebb9d/attachment.htm
From ok at cs.otago.ac.nz  Mon Sep 15 00:12:39 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon Sep 15 00:10:18 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <2693_1221389962_m8EAxKTw015628_6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
	<1221382567.3668.30.camel@myhost>
	<2693_1221389962_m8EAxKTw015628_6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
Message-ID: <9F0C7A1A-9B3E-430D-B65F-B386CFD4EC72@cs.otago.ac.nz>


On 14 Sep 2008, at 10:59 pm, Rafael Almeida wrote:
> One thing have always bugged me: how do you prove that you have
> correctly proven something?

This really misses the point of trying to formally verify something.
That point is that you almost certainly have NOT.  By the time you
get a theorem prover to accept your specification, you have
(a) gone through a couple of rounds of redesign (before writing the
     code!) and now have something really clear (because the prover
     is too dumb to understand subtle stuff)
(b) just done a lot of "testing" on the design that was finally
     accepted.

> I mean, when I write a code I'm formaly
> stating what I want to happen and bugs happen. If I try to prove some
> part of the code I write more formal text (which generally isn't even
> checked by a compiler);

I'm sorry?
What kind of half-arsed "formal" specification is NOT "checked"?
None of the specification tools I've played with (I really wish there
were a PVS course I could attend in NZ) can truthfully be described as
"not checked".

Symbolic model checking tools effectivley _are_ testing tools; what you
normally get from them is not a cheery "that's fine boss" but a snarky
"you forgot about this possible input didn't you, idiot!"

> how can I be sure that my proof doesn't
> contain bugs?

You can't.  What you CAN be sure of is that your previous proof
attempts DID contain bugs.  Lots of them.  At least *those* ones
are gone.  Let's face it, you can't be *sure* that you aren't a brain
in a jar being systematically deceived by a demon.  (Read Descartes.)

In fact, you can usually be CERTAIN that you haven't proved the
validity of your whole system, because you usually haven't tried.
Formal methods are a risk reduction tool.  You pick some part of the
system which has a special need for reliability, isolate it, model it,
check the model for consistency, specify operations on it, prove
something about them, and you learn a heck of a lot by doing so.
What you can't eliminate is the possibility that something nasty is
lurking in the BIOS of your computer specifically watching out for
your code so it can sabotage it.  Several times in my programming
career I have encountered perfectly correct code that malfunctioned
because of a broken compiler (well ok, in one case it was a broken
assembler).

> Why would it make my program less error-prone? Is there
> any article that tries to compare heavy testing with FM?

Lots of them.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.2475
might make a good start.
The idea that the FORTEST researchers share is that formal
methods can *help* testing.
Indeed, QuickCheck basically _is_ an 'automatic tests from
specifications' tool, one of many that have been built over the
years.

If you stop thinking of formal methods as "verifying finished
written programs" and more as some mix of "design for
checkability" (so that bugs are less likely to be written into
the code in the first place) or as "testing for specifications"
it may make more sense to you.

From ok at cs.otago.ac.nz  Mon Sep 15 00:21:14 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon Sep 15 00:20:26 2008
Subject: [Haskell-cafe] ask
In-Reply-To: <8123_1221439784_m8F0nhZc018637_200809150251.37805.daniel.is.fischer@web.de>
References: <1ff5dedc0809141724w2dfaf10djab065e568de9fe30@mail.gmail.com>
	<8123_1221439784_m8F0nhZc018637_200809150251.37805.daniel.is.fischer@web.de>
Message-ID: <0604C48F-338A-402A-810F-38501DCAE103@cs.otago.ac.nz>


On 15 Sep 2008, at 12:51 pm, Daniel Fischer wrote:

> Am Montag, 15. September 2008 02:24 schrieb Cetin Sert:
>> Hi why do I get?
>
> Buffering. For compiled programmes, stdin and stdout are line- 
> buffered by
> default, so the output doesn't appear until the program finishes.
> Either put
> hSetBuffering stdout NoBuffering
> at the top of main or, better IMO,
> insert a
> hFlush stdout
> into ask before the readLn.
> And in eval, putStrLn would be better, I think.

Is this the problem we've had before, where the example in the
Haskell 98 Report could not possibly work unless Haskell followed
the same rule as C (read from stdin *automatically* flushes stdout),
and the example works in several other Haskell systems, but not in
GHC?  Or is this a different problem?

From miguelimo38 at yandex.ru  Mon Sep 15 01:24:06 2008
From: miguelimo38 at yandex.ru (Miguel Mitrofanov)
Date: Mon Sep 15 01:21:46 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
Message-ID: 

Did that. http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html

On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:

> Hi, is there any chance of having hugs  compile for the iPhone?
>
> Cross-compiling? Compiling directly on the iPhone?
>
> Greets,
> Alberto
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From dons at galois.com  Mon Sep 15 01:25:51 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 15 01:23:19 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: 
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
Message-ID: <20080915052551.GE26666@scytale.galois.com>

Very nice. Easy?

miguelimo38:

> Did that. 
> http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html
> 
> On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:
> 
> >Hi, is there any chance of having hugs  compile for the iPhone?
> >
> >Cross-compiling? Compiling directly on the iPhone?
From argaldo.haskell at gmail.com  Mon Sep 15 01:47:16 2008
From: argaldo.haskell at gmail.com (Alberto R. Galdo)
Date: Mon Sep 15 01:47:48 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: 
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
Message-ID: 

Cool! That's such a proof that it can be done...

I had lots of problems trying to cross compile hugs from my mac to arm  
architecture ( seems that hugs codebase is not capable of cross  
compiling )

And when compiling directly  on the iPhone, first there where problems  
with code signing, now with the configure script and C preprocessor  
sanity check...

Any light on the topic from your experience?

On 15/09/2008, at 7:24, Miguel Mitrofanov  wrote:

> Did that. http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html
>
> On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:
>
>> Hi, is there any chance of having hugs  compile for the iPhone?
>>
>> Cross-compiling? Compiling directly on the iPhone?
>>
>> Greets,
>> Alberto
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From miguelimo38 at yandex.ru  Mon Sep 15 01:52:05 2008
From: miguelimo38 at yandex.ru (Miguel Mitrofanov)
Date: Mon Sep 15 01:49:52 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: <20080915052551.GE26666@scytale.galois.com>
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
	<20080915052551.GE26666@scytale.galois.com>
Message-ID: <9C68DA3B-ADC1-4E31-8455-49E0C44B9F0C@yandex.ru>

As pie. Just downloaded the source and compiled it on iPhone itself  
(no cross-compiling).

On 15 Sep 2008, at 09:25, Don Stewart wrote:

> Very nice. Easy?
>
> miguelimo38:
>
>> Did that.
>> http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html
>>
>> On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:
>>
>>> Hi, is there any chance of having hugs  compile for the iPhone?
>>>
>>> Cross-compiling? Compiling directly on the iPhone?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From dmehrtash at gmail.com  Mon Sep 15 02:52:46 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Mon Sep 15 02:50:19 2008
Subject: [Haskell-cafe] Re: Proofs and commercial code -- was Haskell
	Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <5de3f5ca0809141439y43e34762h32c0233f72c6788d@mail.gmail.com>
References: <5de3f5ca0809141439y43e34762h32c0233f72c6788d@mail.gmail.com>
Message-ID: 

Does it make sense to use proof to validate that a given monad
implementation obeys its laws?

daryoush

2008/9/14 Greg Meredith :
> Daryoush,
>
> One of the subtle points about computation is that -- via Curry-Howard --
> well-typed programs are already proofs. They may not be the proof you were
> seeking (there are a lot of programs from Int -> Int), or prove the theorem
> you were seeking to prove (Ord a => [a] -> [a] is a lot weaker than 'this
> program sorts lists of ordered types'), but they are witnesses of any type
> they type-check against. In a system that has principal types, they are
> proofs of their principal type. In this sense, the utility of proofs is
> widespread: they are programs.
>
> There is a really subtle dance between types that are rich enough to express
> the theorems you would have your programs be proofs of and the termination
> of type-checking for that type system. That's why people often do proofs by
> hand -- because the theorems they need to prove require a greater degree of
> expressiveness than is available in the type system supported by the
> language in which the programs are expressed. Research has really been
> pushing the envelope of what's expressible in types -- from region and
> resource analysis to deadlock-freedom. Again, in that setting the program is
> a witness of a property like
>
> won't leak URLs to unsavory agents
> won't hold on to handles past their garbage-collect-by date
> won't get caught in a 'deadly embrace' (A is waiting for B, B is waiting for
> A)
>
> Sometimes, however, and often in mission critical code, you need stronger
> assurances, like
>
> this code really does implement a FIFO queue, or
> this code really does implement sliding window protocol, or
> this code really does implement two-phase-commit-presumed-abort
>
> It's harder -- in fact i think it's impossible for bullet item 2 above -- to
> squeeze these into terminating type-checks. In those cases, you have to
> escape out to a richer relationship between 'theorem' (aka type) and 'proof'
> (aka program). Proof assistants, like Coq, or Hol or... can be very helpful
> for automating some of the tasks, leaving the inventive bits to the humans.
>
> In my experience, a proof of a theorem about some commercial code is pursued
> when the cost of developing the proof is less than some multiple of the cost
> of errors in the program in the life-cycle of that program. Intel, and other
> hardware vendors, for example, can lose a lot of business when the
> implementation of floating point operations is buggy; and, there is a
> breaking point where the complexity/difficulty/cost of proving the
> implementation correct is sufficiently less than that of business lost that
> it is to their advantage to obtain the kind of quality assurance that can be
> had from a proof of correctness.
>
> One other place where proofs of correctness will be pursued is in
> mathematical proofs, themselves. To the best of my knowledge, nothing
> mission-critical is currently riding on the proof of the 4-color theorem.
> The proof -- last i checked -- required programmatic checking of many cases.
> Proving the program -- that implements the tedious parts of the proof --
> correct is pursued because of the culture and standard of mathematical
> proof.
>
> Best wishes,
>
> --greg
>
> Date: Sat, 13 Sep 2008 22:24:50 -0700
> From: "Daryoush Mehrtash" 
> Subject: Re: [Haskell-cafe] Haskell Weekly News: Issue 85 - September
>        13, 2008
> To: "Don Stewart" 
> Cc: Haskell Cafe 
> Message-ID:
>        >
> Content-Type: text/plain; charset="iso-8859-1"
>
> What I am trying to figure out is that say on the code for the IRC bot that
> is show here
>
> http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot/Source
>
> What would theorem proofs do for me?
>
> Daryoush
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 806 55th St NE
> Seattle, WA 98105
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
From lennart at augustsson.net  Mon Sep 15 03:04:47 2008
From: lennart at augustsson.net (Lennart Augustsson)
Date: Mon Sep 15 03:02:20 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: 
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
	
Message-ID: 

I have the same problems.  Looks like the configure script needs some
updating to run on the iPhone.

On Mon, Sep 15, 2008 at 6:47 AM, Alberto R. Galdo
 wrote:
> Cool! That's such a proof that it can be done...
>
> I had lots of problems trying to cross compile hugs from my mac to arm
> architecture ( seems that hugs codebase is not capable of cross compiling )
>
> And when compiling directly  on the iPhone, first there where problems with
> code signing, now with the configure script and C preprocessor sanity
> check...
>
> Any light on the topic from your experience?
>
> On 15/09/2008, at 7:24, Miguel Mitrofanov  wrote:
>
>> Did that.
>> http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html
>>
>> On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:
>>
>>> Hi, is there any chance of having hugs  compile for the iPhone?
>>>
>>> Cross-compiling? Compiling directly on the iPhone?
>>>
>>> Greets,
>>> Alberto
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From ryani.spam at gmail.com  Mon Sep 15 04:33:39 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Mon Sep 15 04:31:12 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: 
References: 
Message-ID: <2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>

I recommend reading Conal Elliott's "Efficient Functional Reactivity"
paper for an in-depth real-world example.

http://www.conal.net/papers/simply-reactive

  -- ryan

On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash  wrote:
> I have been told that for a Haskell/Functional programmer the process
> of design starts with defining Semantic Domain, Function, and
> denotational model of the problem.  I have done some googling on the
> topic but haven't found a good reference on it.    I would appreciate
> any good references on the topic.
>
> thanks,
>
> daryoush
>
> ps.  I have found referneces like
> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
> which doesn't do any good for me.    I need something with a more real
> examples.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From apfelmus at quantentunnel.de  Mon Sep 15 05:32:41 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Mon Sep 15 05:30:23 2008
Subject: [Haskell-cafe] Re: Proofs and commercial code -- was Haskell Weekly
 News: Issue 85 - September 13, 2008
In-Reply-To: 
References: <5de3f5ca0809141439y43e34762h32c0233f72c6788d@mail.gmail.com>
	
Message-ID: 

Daryoush Mehrtash wrote:
> Does it make sense to use proof to validate that a given monad
> implementation obeys its laws?

Absolutely, and this is usually done by hand.

Take for instance the state monad.

  newtype State s a = State { runState :: s -> (a,s) }

  instance Monad (State s) where
    return x        = State $ \s -> (x,s)
    (State m) >>= f = State $ \s -> let (x,s') = m s in runState (f x) s'

The first monad law is

    return a >>= f = f a

And here is proof:

    return a >>= f
  = { definition of return }
    State (\s -> (a,s)) >>= f
  = { definition of >>= }
    State $ \s -> let (x,s') = (\s -> (a,s)) s in runState (f x) s'
  = { apply lambda abstraction }
    State $ \s -> let (x,s') = (a,s) in runState (f x) s'
  = { pattern binding }
    State $ \s -> runState (f a) s
  = { eta reduction }
    State $ runState (f a)
  = { State . runState = id }
    f a

Exercise: Prove the other monad laws, i.e.

     m >>= return = m
  (m >>= g) >>= h = m >>= (\x -> g x >>= h)


Regards,
apfelmus

From monnier at iro.umontreal.ca  Mon Sep 15 10:32:44 2008
From: monnier at iro.umontreal.ca (Stefan Monnier)
Date: Mon Sep 15 10:30:26 2008
Subject: [Haskell-cafe] Re: Haskell Weekly News: Issue 85 - September 13,
	2008
References: <20080913230727.GA31569@seas.upenn.edu>
	<1221382567.3668.30.camel@myhost>
	<6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
	<200809141135.38719.dan.doel@gmail.com>
Message-ID: 

> A more difficult question is: how do I know that the formal
> specification I've  written for my program is the right one? Tools can
> fairly easily check that  your programs conform to a given
> specification, but they cannot (to my  knowledge) check that your
> specification says exactly what you want it to say.

The key is *redundancy*: as long as your property is sufficiently
different (in structure, in authorship, etc...) you can hope that if the
spec has a bug, the code will not have a corresponding bug and
vice versa.  It's only a hope, tho.


        Stefan

From greenrd at greenrd.org  Mon Sep 15 12:08:59 2008
From: greenrd at greenrd.org (Robin Green)
Date: Mon Sep 15 11:06:52 2008
Subject: [Haskell-cafe] Re: Haskell Weekly News: Issue 85 - September
	13, 2008
In-Reply-To: 
References: <20080913230727.GA31569@seas.upenn.edu>
	<1221382567.3668.30.camel@myhost>
	<6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
	<200809141135.38719.dan.doel@gmail.com>
	
Message-ID: <20080915170859.55af0e8d@greenrd.org>

On Mon, 15 Sep 2008 10:32:44 -0400
Stefan Monnier  wrote:

> > A more difficult question is: how do I know that the formal
> > specification I've  written for my program is the right one? Tools
> > can fairly easily check that  your programs conform to a given
> > specification, but they cannot (to my  knowledge) check that your
> > specification says exactly what you want it to say.
> 
> The key is *redundancy*: as long as your property is sufficiently
> different (in structure, in authorship, etc...) you can hope that if
> the spec has a bug, the code will not have a corresponding bug and
> vice versa.  It's only a hope, tho.

There are other meta-level properties one might desire in a
specification, too, such as:

* Simplicity - if a specification is too long-winded, you might not
spot a bug in it because it's too hard to read.

* Definite description - if a specification is a definite description,
it is satisfied by one and only one value (up to functional
equivalence). For example, if I say that a list sorting function must
preserve the length of its input, that's not a definite description,
because it is satisfied by the identity function, as well as a correct
sorting function. However, if I say (in a suitably formal way) that a
sorting function must output a list where every element in the input
occurs the same number of times in the output as it occurs in the
input, and vice-versa, and the output is ordered according to the
specified order - then that *is* a definite description, because any
two functions that follow that specification must be equivalent.

* Reusable (and perhaps reused!) - As in ordinary programming, reuse of
specifications can help avoid errors.

-- 
Robin
From miguelimo38 at yandex.ru  Mon Sep 15 12:01:45 2008
From: miguelimo38 at yandex.ru (Miguel Mitrofanov)
Date: Mon Sep 15 11:59:25 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: 
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
	
Message-ID: 

My iPhone (iPod Touch, actually) have 1.1.4 firmware, so there isn't  
any code signing involved. I've just "configure"d and "make"d.

On 15 Sep 2008, at 09:47, Alberto R. Galdo wrote:

> Cool! That's such a proof that it can be done...
>
> I had lots of problems trying to cross compile hugs from my mac to  
> arm architecture ( seems that hugs codebase is not capable of cross  
> compiling )
>
> And when compiling directly  on the iPhone, first there where  
> problems with code signing, now with the configure script and C  
> preprocessor sanity check...
>
> Any light on the topic from your experience?
>
> On 15/09/2008, at 7:24, Miguel Mitrofanov   
> wrote:
>
>> Did that. http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html
>>
>> On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:
>>
>>> Hi, is there any chance of having hugs  compile for the iPhone?
>>>
>>> Cross-compiling? Compiling directly on the iPhone?
>>>
>>> Greets,
>>> Alberto
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>

From almeidaraf at gmail.com  Mon Sep 15 12:05:11 2008
From: almeidaraf at gmail.com (Rafael C. de Almeida)
Date: Mon Sep 15 12:02:48 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <9F0C7A1A-9B3E-430D-B65F-B386CFD4EC72@cs.otago.ac.nz>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
	<1221382567.3668.30.camel@myhost>
	<2693_1221389962_m8EAxKTw015628_6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
	<9F0C7A1A-9B3E-430D-B65F-B386CFD4EC72@cs.otago.ac.nz>
Message-ID: <48CE87B7.8060706@gmail.com>

Richard A. O'Keefe wrote:
> 
> On 14 Sep 2008, at 10:59 pm, Rafael Almeida wrote:
>> One thing have always bugged me: how do you prove that you have
>> correctly proven something?
> 
> This really misses the point of trying to formally verify something.
> That point is that you almost certainly have NOT.  By the time you
> get a theorem prover to accept your specification, you have
> (a) gone through a couple of rounds of redesign (before writing the
>     code!) and now have something really clear (because the prover
>     is too dumb to understand subtle stuff)
> (b) just done a lot of "testing" on the design that was finally
>     accepted.
> 
>> I mean, when I write a code I'm formaly
>> stating what I want to happen and bugs happen. If I try to prove some
>> part of the code I write more formal text (which generally isn't even
>> checked by a compiler);
> 
> I'm sorry?
> What kind of half-arsed "formal" specification is NOT "checked"?
> None of the specification tools I've played with (I really wish there
> were a PVS course I could attend in NZ) can truthfully be described as
> "not checked".

I do not know. I'm not experienced on the field and I was under the
impression you'd write your code then get a pen and a paper and try to
prove some property of it.

Someone mentioned coq, I read a bit about it, but it looked really
foreign to me. The idea is to somehow prove somethings based only on the
specification and, after that, you write your code, based on your proof?
If so, what's the difference of that and writing the same program twice
in two different languages? Isn't that kind of what's going on anyways?

> Symbolic model checking tools effectivley _are_ testing tools; what you
> normally get from them is not a cheery "that's fine boss" but a snarky
> "you forgot about this possible input didn't you, idiot!"

Do they operate with Haskell functions directly? I mean, can I somehow
import the functions I wrote in Haskell and try to prove properties on
it using those tools you talk about?

>> how can I be sure that my proof doesn't
>> contain bugs?
> 
> You can't.  What you CAN be sure of is that your previous proof
> attempts DID contain bugs.  Lots of them.  At least *those* ones
> are gone.  Let's face it, you can't be *sure* that you aren't a brain
> in a jar being systematically deceived by a demon.  (Read Descartes.)
> 
> In fact, you can usually be CERTAIN that you haven't proved the
> validity of your whole system, because you usually haven't tried.
> Formal methods are a risk reduction tool.  You pick some part of the
> system which has a special need for reliability, isolate it, model it,
> check the model for consistency, specify operations on it, prove
> something about them, and you learn a heck of a lot by doing so.
> What you can't eliminate is the possibility that something nasty is
> lurking in the BIOS of your computer specifically watching out for
> your code so it can sabotage it.  Several times in my programming
> career I have encountered perfectly correct code that malfunctioned
> because of a broken compiler (well ok, in one case it was a broken
> assembler).
> 
>> Why would it make my program less error-prone? Is there
>> any article that tries to compare heavy testing with FM?
> 
> Lots of them.
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.2475
> might make a good start.
> The idea that the FORTEST researchers share is that formal
> methods can *help* testing.
> Indeed, QuickCheck basically _is_ an 'automatic tests from
> specifications' tool, one of many that have been built over the
> years.
> 
> If you stop thinking of formal methods as "verifying finished
> written programs" and more as some mix of "design for
> checkability" (so that bugs are less likely to be written into
> the code in the first place) or as "testing for specifications"
> it may make more sense to you.
> 

Hm. I've used quickcheck, I find it really nice. It was definetely the
tool I had in mind when I was arguing about tests being enough to
'proof' things. Anyhow, I'll take a look on that article, maybe it
already answers lots of the questions I've raised here :-).
From greenrd at greenrd.org  Mon Sep 15 13:43:01 2008
From: greenrd at greenrd.org (Robin Green)
Date: Mon Sep 15 12:42:01 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <48CE87B7.8060706@gmail.com>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
	<1221382567.3668.30.camel@myhost>
	<2693_1221389962_m8EAxKTw015628_6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
	<9F0C7A1A-9B3E-430D-B65F-B386CFD4EC72@cs.otago.ac.nz>
	<48CE87B7.8060706@gmail.com>
Message-ID: <20080915184301.30e29fb0@greenrd.org>

On Mon, 15 Sep 2008 13:05:11 -0300
"Rafael C. de Almeida"  wrote:
> I do not know. I'm not experienced on the field and I was under the
> impression you'd write your code then get a pen and a paper and try to
> prove some property of it.

In fairness, that's how it's often done in universities (where
correctness doesn't really matter to most people - no offense
intended). But once you start using software to write formal proofs, it
is quite easy in principle to get a computer to check your proof for
you. Many academics do not use formal proof tools because (a) they are
not aware of them, or (b) they see them as too hard to learn, or (c)
they see them as too time-consuming to use, or (d) they don't see the
point. Hopefully this situation will gradually change.

> Someone mentioned coq, I read a bit about it, but it looked really
> foreign to me. The idea is to somehow prove somethings based only on
> the specification and, after that, you write your code, based on your
> proof?

No. There are 3 main ways of using Coq:

1. Code extraction. You write your code in Coq itself, prove that it
meets your specification, and then use the Extraction commands to
convert the Coq code into Haskell (throwing away all the proof bits,
which aren't relevant at runtime).

2. Verification condition generation (VCGen) - you write your code in
some "ordinary" language, say Haskell, and annotate it with
specifications. Then you run a VCGen tool over it and it tries to prove
the trivial things, and spits out the rest as "verification conditions"
in the language of Coq, ready to be proved in Coq.

3. A combination of both of the above approaches - you write your code
in Coq, ignoring the proof at first, and then verification conditions
(called "obligations" in Coq) are generated. This is experimental. The
commands that begin with "Program" in Coq are used for this.

None of these involve writing the same code twice in different
languages.

-- 
Robin
From dmehrtash at gmail.com  Mon Sep 15 13:13:53 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Mon Sep 15 13:11:24 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: <2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
Message-ID: 

Interestingly, I was trying to read his paper when I realized that I
needed to figure out the meaning of denotational model, semantic
domain, semantic functions.  Other Haskell books didn't talk about
design in those terms, but obviously for him this is how he is driving
his design.   I am looking for a simpler tutorial, text book like
reference on the topic.

Daryoush

On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram  wrote:
> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
> paper for an in-depth real-world example.
>
> http://www.conal.net/papers/simply-reactive
>
>  -- ryan
>
> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash  wrote:
>> I have been told that for a Haskell/Functional programmer the process
>> of design starts with defining Semantic Domain, Function, and
>> denotational model of the problem.  I have done some googling on the
>> topic but haven't found a good reference on it.    I would appreciate
>> any good references on the topic.
>>
>> thanks,
>>
>> daryoush
>>
>> ps.  I have found referneces like
>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>> which doesn't do any good for me.    I need something with a more real
>> examples.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
From atomb at galois.com  Mon Sep 15 13:20:12 2008
From: atomb at galois.com (Aaron Tomb)
Date: Mon Sep 15 13:17:51 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <20080915184301.30e29fb0@greenrd.org>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
	<1221382567.3668.30.camel@myhost>
	<2693_1221389962_m8EAxKTw015628_6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
	<9F0C7A1A-9B3E-430D-B65F-B386CFD4EC72@cs.otago.ac.nz>
	<48CE87B7.8060706@gmail.com> <20080915184301.30e29fb0@greenrd.org>
Message-ID: 


On Sep 15, 2008, at 10:43 AM, Robin Green wrote:
> In fairness, that's how it's often done in universities (where
> correctness doesn't really matter to most people - no offense
> intended). But once you start using software to write formal proofs,  
> it
> is quite easy in principle to get a computer to check your proof for
> you. Many academics do not use formal proof tools because (a) they are
> not aware of them, or (b) they see them as too hard to learn, or (c)
> they see them as too time-consuming to use, or (d) they don't see the
> point. Hopefully this situation will gradually change.

Fortunately, I think it has been changing rather rapidly lately. In  
the last year or so, tools like Coq and Isabelle have become  
increasingly popular. Several universities now have classes:

http://www.cs.colorado.edu/~siek/7000/spring07/
http://web.cecs.pdx.edu/~apt/cs510coq/ad
http://www.cs.cmu.edu/~emc/15-820A/
http://www.cs.harvard.edu/~adamc/cpdt/
http://adam.chlipala.net/itp/
http://cl.cse.wustl.edu/classes/cse545/

There's a competition to solve various programming-languge-related  
problems using automated proof checkers:

http://alliance.seas.upenn.edu/~plclub/cgi-bin/poplmark/index.php?title=The_POPLmark_Challenge

A tutorial at the last POPL conference:

http://www.cis.upenn.edu/~plclub/popl08-tutorial/

And a number of projects with mechanical proofs:

http://www.chargueraud.org/arthur/research/index.php
http://compcert.inria.fr/doc/index.html
http://ece-www.colorado.edu/~siek/segt_typesafe.pdf
http://ece-www.colorado.edu/~siek/pubs/pubs/2005/siek05:_cpp_isar.pdf
http://ece-www.colorado.edu/~siek/gradual-obj.pdf
http://adam.chlipala.net/papers/
http://pauillac.inria.fr/~xleroy/proofs.html
http://www.kennknowles.com/research/knowles-flanagan.draft.07.explicit.pdf

I'm sure I've left out many of the most relevant examples, but this is  
a bit of the flavor of the recent work in the area.

Aaron
From ryani.spam at gmail.com  Mon Sep 15 13:46:16 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Mon Sep 15 13:43:50 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: 
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
	
Message-ID: <2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>

Here's a quick overview that might help you.

For a reactive behavior, we have two types to think about:

type B a = Time -> a
    (the semantic domain)

data Behavior a = ?
    (the library's implementation).
at :: Behavior a -> B a
    (observation function)

This is really just classic "information hiding" as you would do with
any abstract data type.  Consider a simple "stack" data structure that
supports push and pop.

> data S a = S
>     { popS :: Maybe (a, S a)
>     , pushS :: a -> S a
>     }

> data Stack a = ?
> observeStack :: Stack a -> S a

As a library user, you don't really care about the implementation of
Stack, just as a user of Conal's library doesn't really care about the
implementation of Behavior.  What you *do* care about is that you can
think about it in the simpler terms of "Time -> a" which is the model
he has chosen.

The rest of the library design comes from taking that model and
thinking about what typeclasses and operations "Time -> a" should
support, and creating typeclass morphisms between Behavior a and B a
where necessary.  For example:

> -- This makes (r -> a) into a functor over a; it is a generalization of Time -> a
> instance Functor ((->) r) where
>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
>    fmap f x = \r -> f (x r)
>    -- or, "fmap = (.)", if you're golfing :)

In order for the morphism between B and Behavior to make sense, you
want this law to hold:
   fmap f (at behavior) = at (fmap f behavior)
for all behavior :: Behavior a.

The fmap on the left applies to B which is (Time ->); the fmap on the
right applies to Behavior.

Conal writes this law more elegantly like this:
> instance(semantic) Functor Behavior where
>    fmap f . at = at . fmap f

As long as you as the user can think about behaviors generally as
functions of Time, you can ignore the implementation details, and
things that you expect to work should work.  This drives the design of
the entire library, with similar morphisms over many typeclasses
between Event and E, Reactive and B, etc.

  -- ryan

On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash  wrote:
> Interestingly, I was trying to read his paper when I realized that I
> needed to figure out the meaning of denotational model, semantic
> domain, semantic functions.  Other Haskell books didn't talk about
> design in those terms, but obviously for him this is how he is driving
> his design.   I am looking for a simpler tutorial, text book like
> reference on the topic.
>
> Daryoush
>
> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram  wrote:
>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
>> paper for an in-depth real-world example.
>>
>> http://www.conal.net/papers/simply-reactive
>>
>>  -- ryan
>>
>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash  wrote:
>>> I have been told that for a Haskell/Functional programmer the process
>>> of design starts with defining Semantic Domain, Function, and
>>> denotational model of the problem.  I have done some googling on the
>>> topic but haven't found a good reference on it.    I would appreciate
>>> any good references on the topic.
>>>
>>> thanks,
>>>
>>> daryoush
>>>
>>> ps.  I have found referneces like
>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>>> which doesn't do any good for me.    I need something with a more real
>>> examples.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>
From tomahawkins at gmail.com  Mon Sep 15 14:01:40 2008
From: tomahawkins at gmail.com (Tom Hawkins)
Date: Mon Sep 15 13:59:10 2008
Subject: [Haskell-cafe] Comparing GADTs for Eq and Ord
Message-ID: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>

Hi,

How do I compare a GADT type if a particular constructor returns a
concrete type parameter?

For example:

data Expr :: * -> * where
 Const :: Expr a
 Equal :: Expr a -> Expr a -> Expr Bool      -- If this read Expr a,
the compiler has no problem.

instance Eq (Expr a) where
  Const == Const = True
  (Equal a b) (Equal x y) = a == x && b == y
  _ == _ = False

GHC throws:

    Couldn't match expected type `a1' against inferred type `a2'
      `a1' is a rigid type variable bound by
           the constructor `Equal' at Test.hs:9:3
      `a2' is a rigid type variable bound by
           the constructor `Equal' at Test.hs:9:18
      Expected type: Expr a1
      Inferred type: Expr a2
    In the second argument of `(==)', namely `x'
    In the first argument of `(&&)', namely `a == x'

I believe I understand the reason for the problem; even though Equal
has a type Expr Bool, two Equal expressions could have parameters of
different types.  But I'm not sure how to get around the problem.  Any
suggestions?

Thanks,

Tom
From dagit at codersbase.com  Mon Sep 15 14:42:35 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Mon Sep 15 14:40:06 2008
Subject: [Haskell-cafe] Comparing GADTs for Eq and Ord
In-Reply-To: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
Message-ID: 

On Mon, Sep 15, 2008 at 11:01 AM, Tom Hawkins  wrote:
> Hi,
>
> How do I compare a GADT type if a particular constructor returns a
> concrete type parameter?
>
> For example:
>
> data Expr :: * -> * where
>  Const :: Expr a
>  Equal :: Expr a -> Expr a -> Expr Bool      -- If this read Expr a,
> the compiler has no problem.
>
> instance Eq (Expr a) where
>  Const == Const = True
>  (Equal a b) (Equal x y) = a == x && b == y
>  _ == _ = False
>
> GHC throws:
>
>    Couldn't match expected type `a1' against inferred type `a2'
>      `a1' is a rigid type variable bound by
>           the constructor `Equal' at Test.hs:9:3
>      `a2' is a rigid type variable bound by
>           the constructor `Equal' at Test.hs:9:18
>      Expected type: Expr a1
>      Inferred type: Expr a2
>    In the second argument of `(==)', namely `x'
>    In the first argument of `(&&)', namely `a == x'
>
> I believe I understand the reason for the problem; even though Equal
> has a type Expr Bool, two Equal expressions could have parameters of
> different types.  But I'm not sure how to get around the problem.  Any
> suggestions?

The reason this doesn't work is rather hard to see.  You correctly
noticed that changing the above definition to "Expr a" fixes the
problem.  The reason this fixes the problem is because:
Equal :: Expr a -> Expr a -> Expr Bool

Makes the type parameter 'a' an existential type.  You can think of it
like this:
data Expr a = Equal (forall a. Expr a Expr a)

I think that forall is in the right place.  This means that when you
use the (Equal a b) pattern the 'a' has to be instantiated to some
distinct rigid type, and similarly (Equal x y) instantiates 'a' again
to some distinct rigid type.  This is where your a1 and a2 in the
error message come from.

But, your proposed fix:
Equal :: Expr a -> Expr a -> Expr a

Means that the 'a' is no longer existential and so everything works
the way you expect.  Except that your equal constructor really should
return Expr Bool.

I'm not sure what the best way to fix this is.  It will be interesting
to see what others suggest.

Jason
From almeidaraf at gmail.com  Mon Sep 15 15:25:41 2008
From: almeidaraf at gmail.com (Rafael Almeida)
Date: Mon Sep 15 15:23:17 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
In-Reply-To: <20080915184301.30e29fb0@greenrd.org>
References: <20080913230727.GA31569@seas.upenn.edu>
	
	<20080914042920.GB22084@scytale.galois.com>
	
	<1221382567.3668.30.camel@myhost>
	<2693_1221389962_m8EAxKTw015628_6de6b1650809140359l68ffa57ds5c12e714d645dacd@mail.gmail.com>
	<9F0C7A1A-9B3E-430D-B65F-B386CFD4EC72@cs.otago.ac.nz>
	<48CE87B7.8060706@gmail.com> <20080915184301.30e29fb0@greenrd.org>
Message-ID: <6de6b1650809151225p311a9052g84b167fcbd9abb0b@mail.gmail.com>

On Mon, Sep 15, 2008 at 2:43 PM, Robin Green  wrote:
> On Mon, 15 Sep 2008 13:05:11 -0300
> "Rafael C. de Almeida"  wrote:
>> Someone mentioned coq, I read a bit about it, but it looked really
>> foreign to me. The idea is to somehow prove somethings based only on
>> the specification and, after that, you write your code, based on your
>> proof?
>
> No. There are 3 main ways of using Coq:
>
> 1. Code extraction. You write your code in Coq itself, prove that it
> meets your specification, and then use the Extraction commands to
> convert the Coq code into Haskell (throwing away all the proof bits,
> which aren't relevant at runtime).
>
> 2. Verification condition generation (VCGen) - you write your code in
> some "ordinary" language, say Haskell, and annotate it with
> specifications. Then you run a VCGen tool over it and it tries to prove
> the trivial things, and spits out the rest as "verification conditions"
> in the language of Coq, ready to be proved in Coq.

That seemed to me the most interesting way of using it. After all, I
already like writing my programs in Haskell, not sure if I'd like Coq
better for programming. Also, that could work with code I've already
written. Do you know of a VCGen tool that works well with Haskell and
some other language such as Coq (doesn't need to be coq)? A quick
search on google didn't give me much.

> 3. A combination of both of the above approaches - you write your code
> in Coq, ignoring the proof at first, and then verification conditions
> (called "obligations" in Coq) are generated. This is experimental. The
> commands that begin with "Program" in Coq are used for this.
>
> None of these involve writing the same code twice in different
> languages.
From briqueabraque at yahoo.com  Mon Sep 15 15:26:50 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Mon Sep 15 15:24:43 2008
Subject: [Haskell-cafe] Import qualified, inverse of hiding
Message-ID: 

Hi,

'import' allows one to say 'hiding' to
a list of names. Is it possible to do the
opposite, i.e., list the names I want to
import? Something like "import Module showing x"?

Thanks,
Maur?cio

From tanimoto at arizona.edu  Mon Sep 15 15:35:50 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Mon Sep 15 15:33:25 2008
Subject: [Haskell-cafe] Import qualified, inverse of hiding
In-Reply-To: 
References: 
Message-ID: 

You mean like this?

import Data.List (foldl', nub)

Or am I misunderstanding your question?

Paulo

On Mon, Sep 15, 2008 at 2:26 PM, Mauricio  wrote:
> Hi,
>
> 'import' allows one to say 'hiding' to
> a list of names. Is it possible to do the
> opposite, i.e., list the names I want to
> import? Something like "import Module showing x"?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From ryani.spam at gmail.com  Mon Sep 15 15:37:22 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Mon Sep 15 15:34:54 2008
Subject: [Haskell-cafe] Import qualified, inverse of hiding
In-Reply-To: 
References: 
Message-ID: <2f9b2d30809151237i2c1a9dc9lbf215fe31162cb8e@mail.gmail.com>

Yes, just leave out the keyword "hiding".

> import Data.Map (Map, insert, lookup)

This is the "safest" way to do imports as you're guaranteed that
changes to the export list that do not affect those qualifiers won't
cause code to stop compiling or become ambiguous.

  -- ryan

On Mon, Sep 15, 2008 at 12:26 PM, Mauricio  wrote:
> Hi,
>
> 'import' allows one to say 'hiding' to
> a list of names. Is it possible to do the
> opposite, i.e., list the names I want to
> import? Something like "import Module showing x"?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From briqueabraque at yahoo.com  Mon Sep 15 15:41:04 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Mon Sep 15 15:38:51 2008
Subject: [Haskell-cafe] Re: Import qualified, inverse of hiding
In-Reply-To: 
References: 
	
Message-ID: 

Exactly! Thanks.

Maur?cio

Paulo Tanimoto a ?crit :
> You mean like this?
> 
> import Data.List (foldl', nub)
> 
> Or am I misunderstanding your question?
> 
> Paulo
> 
> On Mon, Sep 15, 2008 at 2:26 PM, Mauricio  wrote:
>> Hi,
>>
>> 'import' allows one to say 'hiding' to
>> a list of names. Is it possible to do the
>> opposite, i.e., list the names I want to
>> import? Something like "import Module showing x"?
>>
>> Thanks,
>> Maur?cio
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>

From tanimoto at arizona.edu  Mon Sep 15 15:48:15 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Mon Sep 15 15:45:47 2008
Subject: [Haskell-cafe] Re: Import qualified, inverse of hiding
In-Reply-To: 
References: 
	
	
Message-ID: 

You're welcome.  By the way, this page seems pretty comprehensive.

http://www.haskell.org/haskellwiki/Import

Also, if my memory serves me, Neil Mitchel raised a question about
extending the import system not long ago.

Paulo

On Mon, Sep 15, 2008 at 2:41 PM, Mauricio  wrote:
> Exactly! Thanks.
>
> Maur?cio
>
> Paulo Tanimoto a ?crit :
>>
>> You mean like this?
>>
>> import Data.List (foldl', nub)
>>
>> Or am I misunderstanding your question?
>>
>> Paulo
>>
>> On Mon, Sep 15, 2008 at 2:26 PM, Mauricio  wrote:
>>>
>>> Hi,
>>>
>>> 'import' allows one to say 'hiding' to
>>> a list of names. Is it possible to do the
>>> opposite, i.e., list the names I want to
>>> import? Something like "import Module showing x"?
>>>
>>> Thanks,
>>> Maur?cio
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From vanenkj at gmail.com  Mon Sep 15 16:04:37 2008
From: vanenkj at gmail.com (John Van Enk)
Date: Mon Sep 15 16:02:08 2008
Subject: [Haskell-cafe] Re: Import qualified, inverse of hiding
In-Reply-To: 
References: 
	
	
	
Message-ID: 

Would it make sense to add multiple imports to that wiki page? I'm not sure
if this is supported outside of GHC, but I've found it useful.
 1 module Main where
 2
 3 import qualified Prelude as P
 4 import Prelude ((++),show,($))
 5
 6 main = P.putStrLn (show $ P.length $ show $ [1] ++ [2,3])


On Mon, Sep 15, 2008 at 3:48 PM, Paulo Tanimoto wrote:

> You're welcome.  By the way, this page seems pretty comprehensive.
>
> http://www.haskell.org/haskellwiki/Import


[snip]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080915/b331eaad/attachment.htm
From apfelmus at quantentunnel.de  Mon Sep 15 16:11:22 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Mon Sep 15 16:09:04 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: 
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
	
Message-ID: 

Jason Dagit wrote:
> Tom Hawkins wrote:
>>
>> How do I compare a GADT type if a particular constructor returns a
>> concrete type parameter?
>>
>> For example:
>>
>> data Expr :: * -> * where
>>  Const :: Expr a
>>  Equal :: Expr a -> Expr a -> Expr Bool      -- If this read Expr a,
>> the compiler has no problem.
>>
>> instance Eq (Expr a) where
>>  Const == Const = True
>>  (Equal a b) (Equal x y) = a == x && b == y
>>  _ == _ = False
>>
>> GHC throws:
>>
>>    Couldn't match expected type `a1' against inferred type `a2'
>>      `a1' is a rigid type variable bound by
>>           the constructor `Equal' at Test.hs:9:3
>>      `a2' is a rigid type variable bound by
>>           the constructor `Equal' at Test.hs:9:18
>>      Expected type: Expr a1
>>      Inferred type: Expr a2
>>    In the second argument of `(==)', namely `x'
>>    In the first argument of `(&&)', namely `a == x'
>>
>> I believe I understand the reason for the problem; even though Equal
>> has a type Expr Bool, two Equal expressions could have parameters of
>> different types.  But I'm not sure how to get around the problem.  Any
>> suggestions?
> 
> Equal :: Expr a -> Expr a -> Expr Bool
> 
> Makes the type parameter 'a' an existential type.  You can think of it
> like this:
> data Expr a = Equal (forall a. Expr a Expr a)
> 
> I think that forall is in the right place.

You mean

  data ExprBool = forall a. Equal (Expr a) (Expr a)

> This means that when you
> use the (Equal a b) pattern the 'a' has to be instantiated to some
> distinct rigid type, and similarly (Equal x y) instantiates 'a' again
> to some distinct rigid type.  This is where your a1 and a2 in the
> error message come from.

So, in other words, in order to test whether terms constructed with  Equal  are
equal, you have to compare two terms of different type for equality. Well,
nothing easier than that:

    (===) :: Expr a -> Expr b -> Bool
    Const       === Const         = True
    (Equal a b) === (Equal a' b') = a === a' && b === b'
    _           === _             = False

    instance Eq (Expr a) where
        (==) = (===)

Chances are that the equality test with different types is more useful in the
rest of your program as well.


Regards,
apfelmus

From tanimoto at arizona.edu  Mon Sep 15 16:36:22 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Mon Sep 15 16:33:52 2008
Subject: [Haskell-cafe] Re: Import qualified, inverse of hiding
In-Reply-To: 
References: 
	
	
	
	
Message-ID: 

On Mon, Sep 15, 2008 at 3:04 PM, John Van Enk  wrote:
> Would it make sense to add multiple imports to that wiki page? I'm not sure
> if this is supported outside of GHC, but I've found it useful.
>  1 module Main where
>  2
>  3 import qualified Prelude as P
>  4 import Prelude ((++),show,($))
>  5
>  6 main = P.putStrLn (show $ P.length $ show $ [1] ++ [2,3])
>

I don't know if that's exclusive to GHC, but I think it would be nice
to have your example on the Wiki -- perhaps at the bottom.  We could
put it under discussion, if we're not sure.

Thanks,

Paulo
From tomahawkins at gmail.com  Mon Sep 15 17:25:17 2008
From: tomahawkins at gmail.com (Tom Hawkins)
Date: Mon Sep 15 17:22:48 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: 
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
	
	
Message-ID: <594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>

On Mon, Sep 15, 2008 at 3:11 PM, apfelmus  wrote:
>
> So, in other words, in order to test whether terms constructed with  Equal  are
> equal, you have to compare two terms of different type for equality. Well,
> nothing easier than that:
>
>    (===) :: Expr a -> Expr b -> Bool
>    Const       === Const         = True
>    (Equal a b) === (Equal a' b') = a === a' && b === b'
>    _           === _             = False
>
>    instance Eq (Expr a) where
>        (==) = (===)

OK.  But let's modify Expr so that Const carries values of different types:

data Expr :: * -> * where
  Const :: a -> Term a
  Equal :: Term a -> Term a -> Term Bool

How would you then define:

Const a === Const b  = ...


-Tom
From westondan at imageworks.com  Mon Sep 15 17:33:12 2008
From: westondan at imageworks.com (Dan Weston)
Date: Mon Sep 15 17:30:48 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: <594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>		
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
Message-ID: <48CED498.2040401@imageworks.com>

Take a look at

http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap

Tom Hawkins wrote:
> On Mon, Sep 15, 2008 at 3:11 PM, apfelmus  wrote:
>> So, in other words, in order to test whether terms constructed with  Equal  are
>> equal, you have to compare two terms of different type for equality. Well,
>> nothing easier than that:
>>
>>    (===) :: Expr a -> Expr b -> Bool
>>    Const       === Const         = True
>>    (Equal a b) === (Equal a' b') = a === a' && b === b'
>>    _           === _             = False
>>
>>    instance Eq (Expr a) where
>>        (==) = (===)
> 
> OK.  But let's modify Expr so that Const carries values of different types:
> 
> data Expr :: * -> * where
>   Const :: a -> Term a
>   Equal :: Term a -> Term a -> Term Bool
> 
> How would you then define:
> 
> Const a === Const b  = ...
> 
> 
> -Tom
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 


From briqueabraque at yahoo.com  Mon Sep 15 17:42:58 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Mon Sep 15 17:40:40 2008
Subject: [Haskell-cafe] Should `(flip (^^))` work?
Message-ID: 

Hi,

I tested the expression below
and it doesn't work. Is there
some way to achieve that (i.e.,
turning an expression inside
parenthesis into an operator)?

2 `(flip (^^))` (3%4)

Thanks,
Maur?cio

From ryani.spam at gmail.com  Mon Sep 15 17:50:30 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Mon Sep 15 17:48:02 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: <594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
	
	
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
Message-ID: <2f9b2d30809151450t6d57b312pcf83f8b9d9a4d0fb@mail.gmail.com>

On Mon, Sep 15, 2008 at 2:25 PM, Tom Hawkins  wrote:
> OK.  But let's modify Expr so that Const carries values of different types:
>
> data Expr :: * -> * where
>  Const :: a -> Term a
>  Equal :: Term a -> Term a -> Term Bool
>
> How would you then define:
>
> Const a === Const b  = ...

You can't.

But you can do so slightly differently:

> import Data.Typeable
>
> data Expr :: * -> * where
>     Const :: (Eq a, Typeable a) => a -> Term a
>     Equal :: Term a -> Term a -> Term Bool
>
> (===) :: Expr a -> Expr b -> Bool
> Const a === Const b =
>     case cast a of
>         Nothing -> False
>         Just a' -> a' == b
> Equal l1 r1 === Equal l2 r2 = l1 === l2 && r1 === r2
> _ === _ = False

You can also represent Const as follows:
>    Const :: TypeRep a -> a -> Term a

There are many papers that talk about using GADTs to reify types in
this fashion to allow safe typecasting.  They generally all rely on
the "base" GADT, "TEq"; every other GADT can be defined in terms of
TEq and existential types.

> data TEq :: * -> * -> * where Refl :: TEq a a

As an example, here is Expr defined in this fashion:

> data Expr a =
>     (Eq a, Typeable a) => Const a
>     | forall b. Equal (TEq a Bool) (Expr b) (Expr b)
> equal :: Expr a -> Expr a -> Expr Bool
> equal = Equal Refl

  -- ryan
From ganesh at earth.li  Mon Sep 15 17:53:57 2008
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Mon Sep 15 17:51:29 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: <594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
	
	
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
Message-ID: 

On Mon, 15 Sep 2008, Tom Hawkins wrote:

> OK.  But let's modify Expr so that Const carries values of different types:
>
> data Expr :: * -> * where
>  Const :: a -> Term a
>  Equal :: Term a -> Term a -> Term Bool
>
> How would you then define:
>
> Const a === Const b  = ...

Apart from the suggestions about Data.Typeable etc, one possibility is to 
enumerate the different possible types that will be used as parameters to 
Const in different constructors, either in Expr or in a new type.

So IntConst :: Int -> Expr Int, etc

Or Const :: Const a -> Expr a and IntConst :: Int -> Const Int etc

Not very pleasant though.

Ganesh
From derek.a.elkins at gmail.com  Mon Sep 15 17:58:22 2008
From: derek.a.elkins at gmail.com (Derek Elkins)
Date: Mon Sep 15 17:55:56 2008
Subject: [Haskell-cafe] Should `(flip (^^))` work?
In-Reply-To: 
References: 
Message-ID: <1221515902.9916.3.camel@derek-laptop>

On Mon, 2008-09-15 at 18:42 -0300, Mauricio wrote:
> Hi,
> 
> I tested the expression below
> and it doesn't work. Is there
> some way to achieve that (i.e.,
> turning an expression inside
> parenthesis into an operator)?
> 
> 2 `(flip (^^))` (3%4)

No it shouldn't work.  The fact that the opening and closing marks are the same suggests that it shouldn't.  You can fake it though.

x -| f = f x
f |- x = f x

2 -| flip (^^) |- (3%4)

From dagit at codersbase.com  Mon Sep 15 18:30:09 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Mon Sep 15 18:27:40 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: <2f9b2d30809151450t6d57b312pcf83f8b9d9a4d0fb@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
	
	
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
	<2f9b2d30809151450t6d57b312pcf83f8b9d9a4d0fb@mail.gmail.com>
Message-ID: 

On Mon, Sep 15, 2008 at 2:50 PM, Ryan Ingram  wrote:

> There are many papers that talk about using GADTs to reify types in
> this fashion to allow safe typecasting.  They generally all rely on
> the "base" GADT, "TEq"; every other GADT can be defined in terms of
> TEq and existential types.

I just found that Tim Sheard has collected a nice list of papers on
this subject:
http://web.cecs.pdx.edu/~sheard/

Jason
From almeidaraf at gmail.com  Mon Sep 15 18:52:58 2008
From: almeidaraf at gmail.com (Rafael C. de Almeida)
Date: Mon Sep 15 18:50:34 2008
Subject: [Haskell-cafe] Should `(flip (^^))` work?
In-Reply-To: <1221515902.9916.3.camel@derek-laptop>
References:  <1221515902.9916.3.camel@derek-laptop>
Message-ID: <48CEE74A.90101@gmail.com>

Derek Elkins wrote:
> On Mon, 2008-09-15 at 18:42 -0300, Mauricio wrote:
>> Hi,
>>
>> I tested the expression below
>> and it doesn't work. Is there
>> some way to achieve that (i.e.,
>> turning an expression inside
>> parenthesis into an operator)?
>>
>> 2 `(flip (^^))` (3%4)
> 
> No it shouldn't work.  The fact that the opening and closing marks are the same suggests that it shouldn't.  You can fake it though.
> 
> x -| f = f x
> f |- x = f x
> 
> 2 -| flip (^^) |- (3%4)
> 

Isn't naming the expression 'flip (^^)' much clearer?
From briqueabraque at yahoo.com  Mon Sep 15 19:09:45 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Mon Sep 15 19:07:31 2008
Subject: [Haskell-cafe] Re: Should `(flip (^^))` work?
In-Reply-To: <48CEE74A.90101@gmail.com>
References:  <1221515902.9916.3.camel@derek-laptop>
	<48CEE74A.90101@gmail.com>
Message-ID: 



Rafael C. de Almeida a ?crit :
> Derek Elkins wrote:
>> On Mon, 2008-09-15 at 18:42 -0300, Mauricio wrote:
>>> Hi,
>>>
>>> I tested the expression below
>>> and it doesn't work. Is there
>>> some way to achieve that (i.e.,
>>> turning an expression inside
>>> parenthesis into an operator)?
>>>
>>> 2 `(flip (^^))` (3%4)
>> No it shouldn't work.  The fact that the opening and closing marks are the same suggests that it shouldn't.  You can fake it though.
>>
>> x -| f = f x
>> f |- x = f x
>>
>> 2 -| flip (^^) |- (3%4)
>>
> 
> Isn't naming the expression 'flip (^^)' much clearer?

I think that is an interesting question
about programming style. In practical
code I think we should have a balance
between the complexity of big expressions
and the complexity of too many names.

Best,
Maur?cio

From almeidaraf at gmail.com  Mon Sep 15 19:51:56 2008
From: almeidaraf at gmail.com (Rafael Almeida)
Date: Mon Sep 15 19:49:26 2008
Subject: [Haskell-cafe] Re: Should `(flip (^^))` work?
In-Reply-To: 
References:  <1221515902.9916.3.camel@derek-laptop>
	<48CEE74A.90101@gmail.com> 
Message-ID: <6de6b1650809151651y1b8c53dcgff9fb09ae5f829df@mail.gmail.com>

On Mon, Sep 15, 2008 at 8:09 PM, Mauricio  wrote:
>
>
> Rafael C. de Almeida a ?crit :
>>
>> Derek Elkins wrote:
>>>
>>> On Mon, 2008-09-15 at 18:42 -0300, Mauricio wrote:
>>>>
>>>> Hi,
>>>>
>>>> I tested the expression below
>>>> and it doesn't work. Is there
>>>> some way to achieve that (i.e.,
>>>> turning an expression inside
>>>> parenthesis into an operator)?
>>>>
>>>> 2 `(flip (^^))` (3%4)
>>>
>>> No it shouldn't work.  The fact that the opening and closing marks are
>>> the same suggests that it shouldn't.  You can fake it though.
>>>
>>> x -| f = f x
>>> f |- x = f x
>>>
>>> 2 -| flip (^^) |- (3%4)
>>>
>>
>> Isn't naming the expression 'flip (^^)' much clearer?
>
> I think that is an interesting question
> about programming style. In practical
> code I think we should have a balance
> between the complexity of big expressions
> and the complexity of too many names.
>
Hm, I was suggesting a local name in a where or let clause. In my
experience, if there are too many local names it's evidence that you
should break up the function into other functions.

But what I'm saying is that I'd rather read something like: 2
`flippedPow` (3%4) then just check what flippedPow is on the where
clause than reading 2 -| flip (^^) |- (3%4) and having to figure out
what -| and |- do.
From ryani.spam at gmail.com  Mon Sep 15 20:30:11 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Mon Sep 15 20:27:42 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: 
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
	
	
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
	
Message-ID: <2f9b2d30809151730w4ec1345exd8a03b8447eed5ab@mail.gmail.com>

On Mon, Sep 15, 2008 at 2:53 PM, Ganesh Sittampalam  wrote:
> Apart from the suggestions about Data.Typeable etc, one possibility is to
> enumerate the different possible types that will be used as parameters to
> Const in different constructors, either in Expr or in a new type.
>
> So IntConst :: Int -> Expr Int, etc
>
> Or Const :: Const a -> Expr a and IntConst :: Int -> Const Int etc
>
> Not very pleasant though.

You can actually generalize this quite a bit, as I touched on slightly
in my last post:

> data Expr a where
>    Const :: TypeRep a -> a -> Expr a
>    ...

> data TEq a b where Refl :: TEq a a

> data TypeRep a where
>    TInt :: TypeRep Int
>    TBool :: TypeRep Bool
>    TList :: TypeRep a -> TypeRep [a]
>    TArrow :: TypeRep a -> TypeRep b -> TypeRep (a -> b)
>    -- etc.

You can then implement the "cast" used in === in the following way:

> typeEq :: TypeRep a -> TypeRep b -> Maybe (TEq a b)
> typeEq TInt TInt = return Refl
> typeEq TBool TBool = return Refl
> typeEq (TList a) (TList b) = do
>    Refl <- typeEq a b
>    return Refl
> typeEq (TArrow a1 a2) (TArrow b1 b2) = do
>    Refl <- typeEq a1 b1
>    Refl <- typeEq a2 b2
>    return Refl
> -- etc.
> typeEq _ _ = fail "Types do not match"

You can use these to write "cast"

> cast :: TypeRep a -> TypeRep b -> a -> Maybe b
> cast ta tb =
>    case typeEq ta tb of
>        Just Refl -> \a -> Just a
>        _            -> \_ -> Nothing

You need a little more work to support equality; the easiest way is to
have an Eq constraint on Const, but you can also write a function
similar to typeEq that puts an Eq constraint into scope if possible.

Pay special attention to the cases in "typeEq" for TList and TArrow;
they make particular use of the desugaring of patterns in do.  A
desugared version of TList:

> typeEq a0@(TList a) b0@(TList b) =
>    typeEq a b >>= \x ->
>    case x of Refl -> return Refl
>                  _     -> fail "pattern match error"

In the Maybe monad, inlining (>>=), return, and fail, this reduces to
the following:

> case typeEq a b of
>    Nothing -> Nothing
>    Just x -> case x of
>      Refl -> Just Refl
>      _     -> Nothing

When we call typeEq, we have a0 :: TypeRep a0, and b0 :: TypeRep b0,
for some unknown types a0 and b0.

Then the pattern match on TList unifies both of these types with [a1]
and [b1] for some unknown types a1 and b1.  We then call typeEq on a
:: TypeRep a1, and b :: TypeRep b1.

Now, on the right hand side of the "Just x" case, TEq a b has only one
possible value, "Refl", so the failure case won't ever be executed.
However, the pattern match on Refl is important, because it unifies a1
and b1, which allows us to unify [a1] and [b1] and construct Refl ::
TEq [a1] [b1] (which is the same as TEq a0 b0).

    -- ryan
From ashley at semantic.org  Mon Sep 15 22:04:40 2008
From: ashley at semantic.org (Ashley Yakeley)
Date: Mon Sep 15 22:02:10 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: <594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>		
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
Message-ID: <48CF1438.8060709@semantic.org>

Tom Hawkins wrote:

> data Expr :: * -> * where
>   Const :: a -> Term a
>   Equal :: Term a -> Term a -> Term Bool

Your basic problem is this:

   p1 :: Term Bool
   p1 = Equal (Const 3) (Const 4)

   p2 :: Term Bool
   p2 = Equal (Const "yes") (Const "no")

p1 and p2 have the same type, but you're not going to be able to compare 
them unless you can compare an Int and a String. What do you want p1 == 
p2 to do?

If you want to just say that different types are always non-equal, the 
simplest way is to create a witness type for your type-system. For instance:

   data MyType a where
     IntType :: MyType Int
     StringType :: MyType String

Now you'll want to declare MyType as a simple witness:

   instance SimpleWitness MyType where
     matchWitness IntType IntType = Just MkEqualType
     matchWitness StringType StringType = Just MkEqualType
     matchWitness _ _ = Nothing

You'll need to include a witness wherever parameter types cannot be 
inferred from the type of the object, as well as an Eq dictionary:

   data Term :: * -> * where
     Const :: a -> Term a
     Equal :: Eq a => MyType a -> Term a -> Term a -> Term Bool

Now you can do:

   instance Eq a => Eq (Term a) where
     (Const p1) == (Const p2) = p1 == p2
     (Equal w1 p1 q1) (Equal w2 p2 q2) = case matchWitness w1 w2 of
        MkEqualType -> (p1 == p2) && (q1 == q2)
        _ -> False -- because the types are different
     _ == _ = False

Note: I haven't actually checked this. Use "cabal install witness" to 
get SimpleWitness and EqualType.

-- 
Ashley Yakeley



From ashley at semantic.org  Mon Sep 15 22:09:13 2008
From: ashley at semantic.org (Ashley Yakeley)
Date: Mon Sep 15 22:06:44 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: <2f9b2d30809151450t6d57b312pcf83f8b9d9a4d0fb@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>			<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
	<2f9b2d30809151450t6d57b312pcf83f8b9d9a4d0fb@mail.gmail.com>
Message-ID: <48CF1549.2010208@semantic.org>

Ryan Ingram wrote:

> There are many papers that talk about using GADTs to reify types in
> this fashion to allow safe typecasting.  They generally all rely on
> the "base" GADT, "TEq"; every other GADT can be defined in terms of
> TEq and existential types.

Ah, yes. See my paper "Witnesses and Open Witnesses"


-- 
Ashley Yakeley
From wren at freegeek.org  Mon Sep 15 23:27:35 2008
From: wren at freegeek.org (wren ng thornton)
Date: Mon Sep 15 23:25:06 2008
Subject: [Haskell-cafe] Should `(flip (^^))` work?
In-Reply-To: 
References: 
Message-ID: <48CF27A7.4070000@freegeek.org>

Mauricio wrote:
> Hi,
> 
> I tested the expression below
> and it doesn't work. Is there
> some way to achieve that (i.e.,
> turning an expression inside
> parenthesis into an operator)?
> 
> 2 `(flip (^^))` (3%4)

Another solution if you don't like defining extra (-|) and (|-) 
operators is:

   > ($2) (flip (^^)) (3%4)

The right section of function application is type lifting. The general 
form of this construction is:

   > ($x) (f a b c...) y z...

Which is equal to (f a b c... x y z...). That is, the construction lets 
you raise any argument out to before the function, thus making the 
partially applied function into an infix between |x| and |y x...|.

-- 
Live well,
~wren
From apfelmus at quantentunnel.de  Tue Sep 16 03:55:40 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Tue Sep 16 03:53:22 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: <594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>		
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
Message-ID: 

Tom Hawkins wrote:
> apfelmus wrote:
>> So, in other words, in order to test whether terms constructed with  Equal  are
>> equal, you have to compare two terms of different type for equality. Well,
>> nothing easier than that:
>>
>>    (===) :: Expr a -> Expr b -> Bool
>>    Const       === Const         = True
>>    (Equal a b) === (Equal a' b') = a === a' && b === b'
>>    _           === _             = False
>>
>>    instance Eq (Expr a) where
>>        (==) = (===)
> 
> OK.  But let's modify Expr so that Const carries values of different types:
> 
> data Expr :: * -> * where
>   Const :: a -> Term a
>   Equal :: Term a -> Term a -> Term Bool
> 
> How would you then define:
> 
> Const a === Const b  = ...
> 

Well,

    Const :: a -> Term a

is too general anyway, you do need some information on  a  to be able to compare
different  Const  terms. An  Eq  constraint on  a  is the minimum:

    Const :: Eq a => a -> Term a

But that's not enough for  (===)  of course, additional information as suggested
by others is needed.


Regards,
apfelmus

From dmehrtash at gmail.com  Tue Sep 16 03:58:44 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Tue Sep 16 03:56:17 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: <2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
	
	<2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>
Message-ID: 

? I don't follow the "at" and  "type B a".  "Behavior a" itself is a
time function.   At least in the version of the code that was
developed in Pual Hudak's Haskell School of Expression it was defined
as:

> newtype Behavior a
>   = Behavior (([Maybe UserAction],[Time]) -> [a])

In a function like time you can see that the "at" function makes things simpler.

In the original version  time was defined as:

> time :: Behavior Time
> time = Behavior (\(_,ts) -> ts)

In Conal's paper

time :: Behavior Time
at time = id

Comparing the two implementation of the time, it seems to me that "at"
and "type B a" has put the design on a more solid ground.  But I don't
quite understand the thought process, or the principal behind what is
happening.

daryoush


On Mon, Sep 15, 2008 at 10:46 AM, Ryan Ingram  wrote:
> Here's a quick overview that might help you.
>
> For a reactive behavior, we have two types to think about:
>
> type B a = Time -> a
>    (the semantic domain)
>
> data Behavior a = ?
>    (the library's implementation).
> at :: Behavior a -> B a
>    (observation function)
>
> This is really just classic "information hiding" as you would do with
> any abstract data type.  Consider a simple "stack" data structure that
> supports push and pop.
>
>> data S a = S
>>     { popS :: Maybe (a, S a)
>>     , pushS :: a -> S a
>>     }
>
>> data Stack a = ?
>> observeStack :: Stack a -> S a
>
> As a library user, you don't really care about the implementation of
> Stack, just as a user of Conal's library doesn't really care about the
> implementation of Behavior.  What you *do* care about is that you can
> think about it in the simpler terms of "Time -> a" which is the model
> he has chosen.
>
> The rest of the library design comes from taking that model and
> thinking about what typeclasses and operations "Time -> a" should
> support, and creating typeclass morphisms between Behavior a and B a
> where necessary.  For example:
>
>> -- This makes (r -> a) into a functor over a; it is a generalization of Time -> a
>> instance Functor ((->) r) where
>>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
>>    fmap f x = \r -> f (x r)
>>    -- or, "fmap = (.)", if you're golfing :)
>
> In order for the morphism between B and Behavior to make sense, you
> want this law to hold:
>   fmap f (at behavior) = at (fmap f behavior)
> for all behavior :: Behavior a.
>
> The fmap on the left applies to B which is (Time ->); the fmap on the
> right applies to Behavior.
>
> Conal writes this law more elegantly like this:
>> instance(semantic) Functor Behavior where
>>    fmap f . at = at . fmap f
>
> As long as you as the user can think about behaviors generally as
> functions of Time, you can ignore the implementation details, and
> things that you expect to work should work.  This drives the design of
> the entire library, with similar morphisms over many typeclasses
> between Event and E, Reactive and B, etc.
>
>  -- ryan
>
> On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash  wrote:
>> Interestingly, I was trying to read his paper when I realized that I
>> needed to figure out the meaning of denotational model, semantic
>> domain, semantic functions.  Other Haskell books didn't talk about
>> design in those terms, but obviously for him this is how he is driving
>> his design.   I am looking for a simpler tutorial, text book like
>> reference on the topic.
>>
>> Daryoush
>>
>> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram  wrote:
>>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
>>> paper for an in-depth real-world example.
>>>
>>> http://www.conal.net/papers/simply-reactive
>>>
>>>  -- ryan
>>>
>>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash  wrote:
>>>> I have been told that for a Haskell/Functional programmer the process
>>>> of design starts with defining Semantic Domain, Function, and
>>>> denotational model of the problem.  I have done some googling on the
>>>> topic but haven't found a good reference on it.    I would appreciate
>>>> any good references on the topic.
>>>>
>>>> thanks,
>>>>
>>>> daryoush
>>>>
>>>> ps.  I have found referneces like
>>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>>>> which doesn't do any good for me.    I need something with a more real
>>>> examples.
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe@haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>
>>
>
From ryani.spam at gmail.com  Tue Sep 16 04:47:13 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Tue Sep 16 04:44:49 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: 
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
	
	<2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>
	
Message-ID: <2f9b2d30809160147t15889c9bxc7cd33fff229729e@mail.gmail.com>

The key insight is that Behavior a is not necessarily a time function;
it's abstract.  But you can treat it as if it was one by observing it
with "at".

In Conal's paper, the internal type of behavior is:

> -- composition of types; like (.) at the type level
> newtype O h g a = O (h (g a))

> -- function type that can directly observe some constant functions
> data Fun t a = K a | Fun (t -> a)

> -- Behavior a ~~ Reactive (Fun Time a)
> type Behavior = Reactive `O` Fun Time

> -- Reactive has a current value and an event stream of values to switch to at particular times
> -- Then an event is just a reactive that might not have a current value until some time in the future.
> data Reactive a = Stepper a (Event a)
> newtype Event a = Ev (Future (Reactive a))

Now, at the internal level, you can write the primitive "time" as

> time :: Behavior Time
> time = O (pure (Fun id))

with "pure" from the Applicative instance for Reactive:

> pure x = Stepper x never

"never" is a future that never occurs, so the reactive value never changes.

From a users' point of view, all this is invisible--you only get a few
observation functions (including "at").  Internally, however, constant
behaviors, or behaviors that contain "steps" that are constant, can be
evaluated extremely quickly; once the behavior returns K x, you know
that the result can't change until the next event in the reactive
stream.  You only need to continuously evaluate the behavior if you
get a "Fun" result.  See sinkB on page 9 of the paper to understand
how this is used to improve performance.

The semantic function "at" drives the model; it allows you to describe
the laws for the library to fulfill very succinctly:

at (fmap f x) = fmap f (at x)
at (pure x) = pure x
at (f <*> x) = at f <*> at x
at (return x) = return x
at (m >>= f) = at m >>= at . f
etc.

Similarily, for Futures, we have "force :: Future a -> (Time, a)"

force (fmap f z) = (t, f x) where (t,x) = force z
force (pure x) = (minBound, x)
force (ff <*> fx) = (max tf tx, f x) where (tf, f) = force ff ; (tx,
x) = force fx
force (return x) = (minBound, x)
force (m >>= f) = (max tm tx, x) where (tm, v) = force m; (tx, x) = force (f v)
etc.

This gives the library user solid ground to stand on when reasoning
about their code; it should do what they expect.  And it gives the
library author a very strong goal to shoot for: just fulfill these
laws, and the code is correct!  This allows radical redesigns of the
internals of the system while maintaining a consistent and intuitive
interface that reuses several classes that the user is hopefully
already familiar with: monoids, functors, applicative functors, and
monads.

  -- ryan

2008/9/16 Daryoush Mehrtash :
> ? I don't follow the "at" and  "type B a".  "Behavior a" itself is a
> time function.   At least in the version of the code that was
> developed in Pual Hudak's Haskell School of Expression it was defined
> as:
>
>> newtype Behavior a
>>   = Behavior (([Maybe UserAction],[Time]) -> [a])
>
> In a function like time you can see that the "at" function makes things simpler.
>
> In the original version  time was defined as:
>
>> time :: Behavior Time
>> time = Behavior (\(_,ts) -> ts)
>
> In Conal's paper
>
> time :: Behavior Time
> at time = id
>
> Comparing the two implementation of the time, it seems to me that "at"
> and "type B a" has put the design on a more solid ground.  But I don't
> quite understand the thought process, or the principal behind what is
> happening.
>
> daryoush
>
>
> On Mon, Sep 15, 2008 at 10:46 AM, Ryan Ingram  wrote:
>> Here's a quick overview that might help you.
>>
>> For a reactive behavior, we have two types to think about:
>>
>> type B a = Time -> a
>>    (the semantic domain)
>>
>> data Behavior a = ?
>>    (the library's implementation).
>> at :: Behavior a -> B a
>>    (observation function)
>>
>> This is really just classic "information hiding" as you would do with
>> any abstract data type.  Consider a simple "stack" data structure that
>> supports push and pop.
>>
>>> data S a = S
>>>     { popS :: Maybe (a, S a)
>>>     , pushS :: a -> S a
>>>     }
>>
>>> data Stack a = ?
>>> observeStack :: Stack a -> S a
>>
>> As a library user, you don't really care about the implementation of
>> Stack, just as a user of Conal's library doesn't really care about the
>> implementation of Behavior.  What you *do* care about is that you can
>> think about it in the simpler terms of "Time -> a" which is the model
>> he has chosen.
>>
>> The rest of the library design comes from taking that model and
>> thinking about what typeclasses and operations "Time -> a" should
>> support, and creating typeclass morphisms between Behavior a and B a
>> where necessary.  For example:
>>
>>> -- This makes (r -> a) into a functor over a; it is a generalization of Time -> a
>>> instance Functor ((->) r) where
>>>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
>>>    fmap f x = \r -> f (x r)
>>>    -- or, "fmap = (.)", if you're golfing :)
>>
>> In order for the morphism between B and Behavior to make sense, you
>> want this law to hold:
>>   fmap f (at behavior) = at (fmap f behavior)
>> for all behavior :: Behavior a.
>>
>> The fmap on the left applies to B which is (Time ->); the fmap on the
>> right applies to Behavior.
>>
>> Conal writes this law more elegantly like this:
>>> instance(semantic) Functor Behavior where
>>>    fmap f . at = at . fmap f
>>
>> As long as you as the user can think about behaviors generally as
>> functions of Time, you can ignore the implementation details, and
>> things that you expect to work should work.  This drives the design of
>> the entire library, with similar morphisms over many typeclasses
>> between Event and E, Reactive and B, etc.
>>
>>  -- ryan
>>
>> On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash  wrote:
>>> Interestingly, I was trying to read his paper when I realized that I
>>> needed to figure out the meaning of denotational model, semantic
>>> domain, semantic functions.  Other Haskell books didn't talk about
>>> design in those terms, but obviously for him this is how he is driving
>>> his design.   I am looking for a simpler tutorial, text book like
>>> reference on the topic.
>>>
>>> Daryoush
>>>
>>> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram  wrote:
>>>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
>>>> paper for an in-depth real-world example.
>>>>
>>>> http://www.conal.net/papers/simply-reactive
>>>>
>>>>  -- ryan
>>>>
>>>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash  wrote:
>>>>> I have been told that for a Haskell/Functional programmer the process
>>>>> of design starts with defining Semantic Domain, Function, and
>>>>> denotational model of the problem.  I have done some googling on the
>>>>> topic but haven't found a good reference on it.    I would appreciate
>>>>> any good references on the topic.
>>>>>
>>>>> thanks,
>>>>>
>>>>> daryoush
>>>>>
>>>>> ps.  I have found referneces like
>>>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>>>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>>>>> which doesn't do any good for me.    I need something with a more real
>>>>> examples.
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> Haskell-Cafe@haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>>
>>>>
>>>
>>
>
From briqueabraque at yahoo.com  Tue Sep 16 08:29:54 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Tue Sep 16 08:27:35 2008
Subject: [Haskell-cafe] Float instance of 'read'
Message-ID: 

Hi,

A small annoyance some users outside
english speaking countries usually
experiment when learning programming
languages is that real numbers use
a '.' instead of ','. Of course, that
is not such a problem except for the
inconsistence between computer and
free hand notation.

Do you think 'read' (actually,
'readsPrec'?) could be made to also
read the international convention
(ie., read "1,5" would also work
besides read "1.5")? I'm happy to
finaly use a language where I can
use words of my language to name
variables, so I wonder if we could
also make that step.

Thanks,
Maur?cio

From vanenkj at gmail.com  Tue Sep 16 09:41:05 2008
From: vanenkj at gmail.com (John Van Enk)
Date: Tue Sep 16 09:38:41 2008
Subject: [Haskell-cafe] Re: Import qualified, inverse of hiding
In-Reply-To: 
References: 
	
	
	
	
	
Message-ID: 

I've dropped it on the discuss page:
http://www.haskell.org/haskellwiki/Talk:Import
Perhaps others have some input before I stick it on the page.

On Mon, Sep 15, 2008 at 4:36 PM, Paulo Tanimoto wrote:

> On Mon, Sep 15, 2008 at 3:04 PM, John Van Enk  wrote:
> > Would it make sense to add multiple imports to that wiki page? I'm not
> sure
> > if this is supported outside of GHC, but I've found it useful.
> >  1 module Main where
> >  2
> >  3 import qualified Prelude as P
> >  4 import Prelude ((++),show,($))
> >  5
> >  6 main = P.putStrLn (show $ P.length $ show $ [1] ++ [2,3])
> >
>
> I don't know if that's exclusive to GHC, but I think it would be nice
> to have your example on the Wiki -- perhaps at the bottom.  We could
> put it under discussion, if we're not sure.
>
> Thanks,
>
> Paulo
>



-- 
/jve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/52d8e218/attachment-0001.htm
From jeanphilippe.bernardy at gmail.com  Tue Sep 16 09:46:02 2008
From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy)
Date: Tue Sep 16 09:43:49 2008
Subject: [Haskell-cafe] Re: Hackage checks
References: <20080913183647.GF23265@Andrea.Nowhere.net>
	<1221333127.5395.121.camel@localhost>
Message-ID: 

Duncan Coutts  worc.ox.ac.uk> writes:

> ?I can't think of any other workaround for 1.2 so I think you'll have to
> require Cabal-1.4 for your package.

Even with 1.4, if I don't give any extra source directory, I get: 

dhcp-192-157:yi-stable bernardy$ cabal sdist
Building source dist for yi-0.4.6.2...
Preprocessing library yi-0.4.6.2...
cabal: can't find source for Paths_yi in .,
dist/src/yi-0.4.6.2/dist/build/autogen

Is there something I'm missing?
Thanks,
-- JP

From conal at conal.net  Tue Sep 16 09:47:31 2008
From: conal at conal.net (Conal Elliott)
Date: Tue Sep 16 09:45:05 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: <2f9b2d30809160147t15889c9bxc7cd33fff229729e@mail.gmail.com>
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
	
	<2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>
	
	<2f9b2d30809160147t15889c9bxc7cd33fff229729e@mail.gmail.com>
Message-ID: 

Hi Ryan,

Thanks very much for these explanations.  Clear and right on!

Best regards,  - Conal

P.S. I'll be at ICFP and am looking forward to seeing folks there.

2008/9/16 Ryan Ingram 

> The key insight is that Behavior a is not necessarily a time function;
> it's abstract.  But you can treat it as if it was one by observing it
> with "at".
>
> In Conal's paper, the internal type of behavior is:
>
> > -- composition of types; like (.) at the type level
> > newtype O h g a = O (h (g a))
>
> > -- function type that can directly observe some constant functions
> > data Fun t a = K a | Fun (t -> a)
>
> > -- Behavior a ~~ Reactive (Fun Time a)
> > type Behavior = Reactive `O` Fun Time
>
> > -- Reactive has a current value and an event stream of values to switch
> to at particular times
> > -- Then an event is just a reactive that might not have a current value
> until some time in the future.
> > data Reactive a = Stepper a (Event a)
> > newtype Event a = Ev (Future (Reactive a))
>
> Now, at the internal level, you can write the primitive "time" as
>
> > time :: Behavior Time
> > time = O (pure (Fun id))
>
> with "pure" from the Applicative instance for Reactive:
>
> > pure x = Stepper x never
>
> "never" is a future that never occurs, so the reactive value never changes.
>
> From a users' point of view, all this is invisible--you only get a few
> observation functions (including "at").  Internally, however, constant
> behaviors, or behaviors that contain "steps" that are constant, can be
> evaluated extremely quickly; once the behavior returns K x, you know
> that the result can't change until the next event in the reactive
> stream.  You only need to continuously evaluate the behavior if you
> get a "Fun" result.  See sinkB on page 9 of the paper to understand
> how this is used to improve performance.
>
> The semantic function "at" drives the model; it allows you to describe
> the laws for the library to fulfill very succinctly:
>
> at (fmap f x) = fmap f (at x)
> at (pure x) = pure x
> at (f <*> x) = at f <*> at x
> at (return x) = return x
> at (m >>= f) = at m >>= at . f
> etc.
>
> Similarily, for Futures, we have "force :: Future a -> (Time, a)"
>
> force (fmap f z) = (t, f x) where (t,x) = force z
> force (pure x) = (minBound, x)
> force (ff <*> fx) = (max tf tx, f x) where (tf, f) = force ff ; (tx,
> x) = force fx
> force (return x) = (minBound, x)
> force (m >>= f) = (max tm tx, x) where (tm, v) = force m; (tx, x) = force
> (f v)
> etc.
>
> This gives the library user solid ground to stand on when reasoning
> about their code; it should do what they expect.  And it gives the
> library author a very strong goal to shoot for: just fulfill these
> laws, and the code is correct!  This allows radical redesigns of the
> internals of the system while maintaining a consistent and intuitive
> interface that reuses several classes that the user is hopefully
> already familiar with: monoids, functors, applicative functors, and
> monads.
>
>  -- ryan
>
> 2008/9/16 Daryoush Mehrtash :
> > ? I don't follow the "at" and  "type B a".  "Behavior a" itself is a
> > time function.   At least in the version of the code that was
> > developed in Pual Hudak's Haskell School of Expression it was defined
> > as:
> >
> >> newtype Behavior a
> >>   = Behavior (([Maybe UserAction],[Time]) -> [a])
> >
> > In a function like time you can see that the "at" function makes things
> simpler.
> >
> > In the original version  time was defined as:
> >
> >> time :: Behavior Time
> >> time = Behavior (\(_,ts) -> ts)
> >
> > In Conal's paper
> >
> > time :: Behavior Time
> > at time = id
> >
> > Comparing the two implementation of the time, it seems to me that "at"
> > and "type B a" has put the design on a more solid ground.  But I don't
> > quite understand the thought process, or the principal behind what is
> > happening.
> >
> > daryoush
> >
> >
> > On Mon, Sep 15, 2008 at 10:46 AM, Ryan Ingram 
> wrote:
> >> Here's a quick overview that might help you.
> >>
> >> For a reactive behavior, we have two types to think about:
> >>
> >> type B a = Time -> a
> >>    (the semantic domain)
> >>
> >> data Behavior a = ?
> >>    (the library's implementation).
> >> at :: Behavior a -> B a
> >>    (observation function)
> >>
> >> This is really just classic "information hiding" as you would do with
> >> any abstract data type.  Consider a simple "stack" data structure that
> >> supports push and pop.
> >>
> >>> data S a = S
> >>>     { popS :: Maybe (a, S a)
> >>>     , pushS :: a -> S a
> >>>     }
> >>
> >>> data Stack a = ?
> >>> observeStack :: Stack a -> S a
> >>
> >> As a library user, you don't really care about the implementation of
> >> Stack, just as a user of Conal's library doesn't really care about the
> >> implementation of Behavior.  What you *do* care about is that you can
> >> think about it in the simpler terms of "Time -> a" which is the model
> >> he has chosen.
> >>
> >> The rest of the library design comes from taking that model and
> >> thinking about what typeclasses and operations "Time -> a" should
> >> support, and creating typeclass morphisms between Behavior a and B a
> >> where necessary.  For example:
> >>
> >>> -- This makes (r -> a) into a functor over a; it is a generalization of
> Time -> a
> >>> instance Functor ((->) r) where
> >>>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
> >>>    fmap f x = \r -> f (x r)
> >>>    -- or, "fmap = (.)", if you're golfing :)
> >>
> >> In order for the morphism between B and Behavior to make sense, you
> >> want this law to hold:
> >>   fmap f (at behavior) = at (fmap f behavior)
> >> for all behavior :: Behavior a.
> >>
> >> The fmap on the left applies to B which is (Time ->); the fmap on the
> >> right applies to Behavior.
> >>
> >> Conal writes this law more elegantly like this:
> >>> instance(semantic) Functor Behavior where
> >>>    fmap f . at = at . fmap f
> >>
> >> As long as you as the user can think about behaviors generally as
> >> functions of Time, you can ignore the implementation details, and
> >> things that you expect to work should work.  This drives the design of
> >> the entire library, with similar morphisms over many typeclasses
> >> between Event and E, Reactive and B, etc.
> >>
> >>  -- ryan
> >>
> >> On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash <
> dmehrtash@gmail.com> wrote:
> >>> Interestingly, I was trying to read his paper when I realized that I
> >>> needed to figure out the meaning of denotational model, semantic
> >>> domain, semantic functions.  Other Haskell books didn't talk about
> >>> design in those terms, but obviously for him this is how he is driving
> >>> his design.   I am looking for a simpler tutorial, text book like
> >>> reference on the topic.
> >>>
> >>> Daryoush
> >>>
> >>> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram 
> wrote:
> >>>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
> >>>> paper for an in-depth real-world example.
> >>>>
> >>>> http://www.conal.net/papers/simply-reactive
> >>>>
> >>>>  -- ryan
> >>>>
> >>>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash <
> dmehrtash@gmail.com> wrote:
> >>>>> I have been told that for a Haskell/Functional programmer the process
> >>>>> of design starts with defining Semantic Domain, Function, and
> >>>>> denotational model of the problem.  I have done some googling on the
> >>>>> topic but haven't found a good reference on it.    I would appreciate
> >>>>> any good references on the topic.
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> daryoush
> >>>>>
> >>>>> ps.  I have found referneces like
> >>>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
> >>>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
> >>>>> which doesn't do any good for me.    I need something with a more
> real
> >>>>> examples.
> >>>>> _______________________________________________
> >>>>> Haskell-Cafe mailing list
> >>>>> Haskell-Cafe@haskell.org
> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>>>
> >>>>
> >>>
> >>
> >
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/b00abb5a/attachment.htm
From briqueabraque at yahoo.com  Tue Sep 16 10:30:08 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Tue Sep 16 10:27:55 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
Message-ID: 

Hi,

I would like to write a Haskell pretty-printer,
using standard libraries for that. How can I
check if the original and the pretty-printed
versions are the same? For instance, is there
a file generated by GHC at the compilation
pipe that is always guaranteed to have the
same MD5 hash when it comes from equivalent
source?

Thanks,
Maur?cio

From dav.vire+haskell at gmail.com  Tue Sep 16 11:31:56 2008
From: dav.vire+haskell at gmail.com (david48)
Date: Tue Sep 16 11:29:51 2008
Subject: [Haskell-cafe] Problem with hscurses
Message-ID: <4c88418c0809160831p67b01045k78eac3c30ea6e780@mail.gmail.com>

the getCh funtion is supposed to return an interpreted Key with values
like KeyChar c, KeyReturn, KeyBackspace, etc.

but in fact, it only ever returns KeyChar c values !

am I doing anything wrong ?

Here's an example program :

module Main where

import UI.HSCurses.Curses
import Text.Printf
import System.IO

main = do
  hSetBuffering stdout NoBuffering
  withCurses test1

withCurses f = do
  initScr
  echo False
  cBreak True
  res <- f
  endWin
  return res

test1 = do
  c <- getCh
  printf "Touche : %s\r\n" (show c)
  test1
From simonpj at microsoft.com  Tue Sep 16 12:27:20 2008
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue Sep 16 12:25:02 2008
Subject: [Haskell-cafe] SYB with class: Bug in Derive.hs module
In-Reply-To: 
References: 
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D7657AC12@EA-EXMSG-C334.europe.corp.microsoft.com>

The message below is a rather old thread but, as Ian says, it's related to

http://hackage.haskell.org/trac/ghc/ticket/1470
http://hackage.haskell.org/trac/ghc/ticket/1735

which I have been looking it in preparation for 6.10.

The good news is that I think I have fixed #1470.  I think #1735 is deeply dodgy code which is rendered unnecessary by #1470.

The key part is this (the full message is below):

| The Data instance that Derive generates is as follows:
|
|  > instance (Data ctx a,
|  >                   Data ctx (BinTree a),
|  >                   Sat (ctx (BinTree a))) =>
|  >                   Data ctx (BinTree a) where
|
| Note the recursive |Data ctx (BinTree a)| in the context. If I get
| rid of it (a correct manual instance is also included in the
| attachment) the example works.

This is indeed a Bad Instance. It says "if you supply me with a (Data ctx (BinTree a)) dictionary, I will construct a (Data ctx (BinTree a)) dictionary".  It's akin to saying
        instance Eq [a] => Eq [a]

Admittedly,
 a) #1470 meant that leaving off this constraint stopped the program compiling
 b) under very special conditions (I'm not quite sure what) you could
        just about make such a program work (see #1735) with the Bad Instance

But the right thing is
  a) to fix #1470 (which I have done) and
  b) to omit the bad constraint from the instance declaration
        (which needs a change to some library)

OK?  I'll commit the fix tomorrow.

Simon


| -----Original Message-----
| From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of
| Alexey Rodriguez Yakushev
| Sent: 31 March 2008 14:47
| To: haskell-cafe
| Cc: AlexJacobson@HAppS.org; Ralf Laemmel
| Subject: [Haskell-cafe] SYB with class: Bug in Derive.hs module
|
| Hi people (and Ralf and Alex),
|
| I found a bug in the SYB with class library when trying to implement
| generic equality. I am hoping that someone in the Cafe (maybe Ralf)
| can confirm it is a bug, or maybe show me that I am doing something
| wrong.
|
| I am using the "Scrap your boilerplate with class" library (http://
| homepages.cwi.nl/~ralf/syb3/). More precisely, I am using the library
| distributed by the HAppS project, because it works with GHC 6.8 . You
| can get the repository as follows:
|
| darcs get http://happs.org/HAppS/syb-with-class
|
| However, the offending module (Derive.hs) produces broken instances
| in both distributions.
|
| The bug:
| ----------
|
| Generic equality needs type safe casting when implemented in SYB3, I
| have tried both the gzipwith variant and using Pack datatypes
| (geq*.hs in the first distribution). However, both functions loop
| when applied to a tree value.
|
| This loop occurs when the functions try to cast one of the arguments.
| I have managed to reduce the error to a smaller source file that I
| send attached. It does the following:
|
|  > main = print typeReps
|  >
|  > tree = (Bin (Leaf 1) (Leaf 2))::BinTree Int
|  >
|  > data Pack = forall x. Typeable x => Pack x
|  >
|  > packedChildren = gmapQ geqCtx Pack tree
|  >
|  > typeOfPack (Pack x) = typeOf x
|  >
|  > typeReps = map typeOfPack packedChildren
|
| Basically the tree is transformed into a list of Pack-ed values and
| then to a list of type representations. This program loops at
| "typeOf" when you call "main".
|
| The Data instance that Derive generates is as follows:
|
|  > instance (Data ctx a,
|  >                   Data ctx (BinTree a),
|  >                   Sat (ctx (BinTree a))) =>
|  >                   Data ctx (BinTree a) where
|
| Note the recursive |Data ctx (BinTree a)| in the context. If I get
| rid of it (a correct manual instance is also included in the
| attachment) the example works.
|
| I thought of removing this from the context in the Derive source. But
| maybe I might break some other use cases. So I am asking for help!
| Should Derive be fixed? How?
|
| Cheers,
|
| Alexey

From jmvilaca at di.uminho.pt  Tue Sep 16 12:42:40 2008
From: jmvilaca at di.uminho.pt (Miguel Vilaca)
Date: Tue Sep 16 12:40:24 2008
Subject: [Haskell-cafe] GHC trouble on Leopard
Message-ID: 

Hi,

I tried to compile some code on Mac Os X (Intel) Leopard.
I have GHC 6.8.3 installed - the installer from GHC webpage (GHC-6.8.3- 
i386.pkg).

But when I run make I get this error

ghc-6.8.3: could not execute: /Library/Frameworks/GHC.framework/ 
Versions/608/usr/lib/ghc-6.8.3/ghc-asm

The work-around of removing the option -fvia-C pointed somewhere on  
the web is not an option here due to library dependecies.

Any hints on how to solve this?

Thanks in advance

Miguel Vila?a

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/fb4cfbd8/attachment.htm
From donnie at darthik.com  Tue Sep 16 14:15:20 2008
From: donnie at darthik.com (Donnie Jones)
Date: Tue Sep 16 14:12:51 2008
Subject: Hyena Status? Re: [Haskell-cafe] Starting Haskell with a web
	application
Message-ID: 

Hello Johan Tibell,

Hyena looks very interesting.  From the github tracking, you've been
working...  Maybe a release soon?

Also, I saw your slides from the 'Left-fold enumerators' presentation at
Galois.  Maybe include the slides in the docs/ for a release?

Thank you.
__
Donnie

On Thu, Mar 6, 2008 at 7:40 AM, Johan Tibell  wrote:

> >  Do you (both) have repos that I could download from? I quite interested
> >  in both projects, esp. the WSGI clone.
>
> Yes and no. The code [1] is in my darcs repository but is in an
> unusable state until I've fixed my incremental parser (in
> Hyena/Parser.hs) which I plan to do next week. I would like the first
> release to be nice and polished so I'm trying to not release anything
> prematurely.
>
> 1. http://darcs.johantibell.com/hyena/
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/f93f2e11/attachment.htm
From dmehrtash at gmail.com  Tue Sep 16 15:39:43 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Tue Sep 16 15:37:14 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: 
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
	
	<2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>
	
	<2f9b2d30809160147t15889c9bxc7cd33fff229729e@mail.gmail.com>
	
Message-ID: 

I can sort of see what is happening in "time = O (pure (Fun id))".
But I am not sure I understand this:

    time :: Behavior Time
    at time = id

as I understand it "at" is a function that take Behaviour and returns
a function that is Time -> a.    How can you have a function on the
left side of the equation?

thanks,

Daryoush


2008/9/16 Conal Elliott :
> Hi Ryan,
>
> Thanks very much for these explanations.  Clear and right on!
>
> Best regards,  - Conal
>
> P.S. I'll be at ICFP and am looking forward to seeing folks there.
>
> 2008/9/16 Ryan Ingram 
>>
>> The key insight is that Behavior a is not necessarily a time function;
>> it's abstract.  But you can treat it as if it was one by observing it
>> with "at".
>>
>> In Conal's paper, the internal type of behavior is:
>>
>> > -- composition of types; like (.) at the type level
>> > newtype O h g a = O (h (g a))
>>
>> > -- function type that can directly observe some constant functions
>> > data Fun t a = K a | Fun (t -> a)
>>
>> > -- Behavior a ~~ Reactive (Fun Time a)
>> > type Behavior = Reactive `O` Fun Time
>>
>> > -- Reactive has a current value and an event stream of values to switch
>> > to at particular times
>> > -- Then an event is just a reactive that might not have a current value
>> > until some time in the future.
>> > data Reactive a = Stepper a (Event a)
>> > newtype Event a = Ev (Future (Reactive a))
>>
>> Now, at the internal level, you can write the primitive "time" as
>>
>> > time :: Behavior Time
>> > time = O (pure (Fun id))
>>
>> with "pure" from the Applicative instance for Reactive:
>>
>> > pure x = Stepper x never
>>
>> "never" is a future that never occurs, so the reactive value never
>> changes.
>>
>> From a users' point of view, all this is invisible--you only get a few
>> observation functions (including "at").  Internally, however, constant
>> behaviors, or behaviors that contain "steps" that are constant, can be
>> evaluated extremely quickly; once the behavior returns K x, you know
>> that the result can't change until the next event in the reactive
>> stream.  You only need to continuously evaluate the behavior if you
>> get a "Fun" result.  See sinkB on page 9 of the paper to understand
>> how this is used to improve performance.
>>
>> The semantic function "at" drives the model; it allows you to describe
>> the laws for the library to fulfill very succinctly:
>>
>> at (fmap f x) = fmap f (at x)
>> at (pure x) = pure x
>> at (f <*> x) = at f <*> at x
>> at (return x) = return x
>> at (m >>= f) = at m >>= at . f
>> etc.
>>
>> Similarily, for Futures, we have "force :: Future a -> (Time, a)"
>>
>> force (fmap f z) = (t, f x) where (t,x) = force z
>> force (pure x) = (minBound, x)
>> force (ff <*> fx) = (max tf tx, f x) where (tf, f) = force ff ; (tx,
>> x) = force fx
>> force (return x) = (minBound, x)
>> force (m >>= f) = (max tm tx, x) where (tm, v) = force m; (tx, x) = force
>> (f v)
>> etc.
>>
>> This gives the library user solid ground to stand on when reasoning
>> about their code; it should do what they expect.  And it gives the
>> library author a very strong goal to shoot for: just fulfill these
>> laws, and the code is correct!  This allows radical redesigns of the
>> internals of the system while maintaining a consistent and intuitive
>> interface that reuses several classes that the user is hopefully
>> already familiar with: monoids, functors, applicative functors, and
>> monads.
>>
>>  -- ryan
>>
>> 2008/9/16 Daryoush Mehrtash :
>> > ? I don't follow the "at" and  "type B a".  "Behavior a" itself is a
>> > time function.   At least in the version of the code that was
>> > developed in Pual Hudak's Haskell School of Expression it was defined
>> > as:
>> >
>> >> newtype Behavior a
>> >>   = Behavior (([Maybe UserAction],[Time]) -> [a])
>> >
>> > In a function like time you can see that the "at" function makes things
>> > simpler.
>> >
>> > In the original version  time was defined as:
>> >
>> >> time :: Behavior Time
>> >> time = Behavior (\(_,ts) -> ts)
>> >
>> > In Conal's paper
>> >
>> > time :: Behavior Time
>> > at time = id
>> >
>> > Comparing the two implementation of the time, it seems to me that "at"
>> > and "type B a" has put the design on a more solid ground.  But I don't
>> > quite understand the thought process, or the principal behind what is
>> > happening.
>> >
>> > daryoush
>> >
>> >
>> > On Mon, Sep 15, 2008 at 10:46 AM, Ryan Ingram 
>> > wrote:
>> >> Here's a quick overview that might help you.
>> >>
>> >> For a reactive behavior, we have two types to think about:
>> >>
>> >> type B a = Time -> a
>> >>    (the semantic domain)
>> >>
>> >> data Behavior a = ?
>> >>    (the library's implementation).
>> >> at :: Behavior a -> B a
>> >>    (observation function)
>> >>
>> >> This is really just classic "information hiding" as you would do with
>> >> any abstract data type.  Consider a simple "stack" data structure that
>> >> supports push and pop.
>> >>
>> >>> data S a = S
>> >>>     { popS :: Maybe (a, S a)
>> >>>     , pushS :: a -> S a
>> >>>     }
>> >>
>> >>> data Stack a = ?
>> >>> observeStack :: Stack a -> S a
>> >>
>> >> As a library user, you don't really care about the implementation of
>> >> Stack, just as a user of Conal's library doesn't really care about the
>> >> implementation of Behavior.  What you *do* care about is that you can
>> >> think about it in the simpler terms of "Time -> a" which is the model
>> >> he has chosen.
>> >>
>> >> The rest of the library design comes from taking that model and
>> >> thinking about what typeclasses and operations "Time -> a" should
>> >> support, and creating typeclass morphisms between Behavior a and B a
>> >> where necessary.  For example:
>> >>
>> >>> -- This makes (r -> a) into a functor over a; it is a generalization
>> >>> of Time -> a
>> >>> instance Functor ((->) r) where
>> >>>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
>> >>>    fmap f x = \r -> f (x r)
>> >>>    -- or, "fmap = (.)", if you're golfing :)
>> >>
>> >> In order for the morphism between B and Behavior to make sense, you
>> >> want this law to hold:
>> >>   fmap f (at behavior) = at (fmap f behavior)
>> >> for all behavior :: Behavior a.
>> >>
>> >> The fmap on the left applies to B which is (Time ->); the fmap on the
>> >> right applies to Behavior.
>> >>
>> >> Conal writes this law more elegantly like this:
>> >>> instance(semantic) Functor Behavior where
>> >>>    fmap f . at = at . fmap f
>> >>
>> >> As long as you as the user can think about behaviors generally as
>> >> functions of Time, you can ignore the implementation details, and
>> >> things that you expect to work should work.  This drives the design of
>> >> the entire library, with similar morphisms over many typeclasses
>> >> between Event and E, Reactive and B, etc.
>> >>
>> >>  -- ryan
>> >>
>> >> On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash
>> >>  wrote:
>> >>> Interestingly, I was trying to read his paper when I realized that I
>> >>> needed to figure out the meaning of denotational model, semantic
>> >>> domain, semantic functions.  Other Haskell books didn't talk about
>> >>> design in those terms, but obviously for him this is how he is driving
>> >>> his design.   I am looking for a simpler tutorial, text book like
>> >>> reference on the topic.
>> >>>
>> >>> Daryoush
>> >>>
>> >>> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram 
>> >>> wrote:
>> >>>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
>> >>>> paper for an in-depth real-world example.
>> >>>>
>> >>>> http://www.conal.net/papers/simply-reactive
>> >>>>
>> >>>>  -- ryan
>> >>>>
>> >>>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash
>> >>>>  wrote:
>> >>>>> I have been told that for a Haskell/Functional programmer the
>> >>>>> process
>> >>>>> of design starts with defining Semantic Domain, Function, and
>> >>>>> denotational model of the problem.  I have done some googling on the
>> >>>>> topic but haven't found a good reference on it.    I would
>> >>>>> appreciate
>> >>>>> any good references on the topic.
>> >>>>>
>> >>>>> thanks,
>> >>>>>
>> >>>>> daryoush
>> >>>>>
>> >>>>> ps.  I have found referneces like
>> >>>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>> >>>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>> >>>>> which doesn't do any good for me.    I need something with a more
>> >>>>> real
>> >>>>> examples.
>> >>>>> _______________________________________________
>> >>>>> Haskell-Cafe mailing list
>> >>>>> Haskell-Cafe@haskell.org
>> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>



-- 
Daryoush

Weblog: http://perlustration.blogspot.com/
From almeidaraf at gmail.com  Tue Sep 16 16:10:09 2008
From: almeidaraf at gmail.com (Rafael C. de Almeida)
Date: Tue Sep 16 16:07:42 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: <48D012A1.7040708@gmail.com>

Mauricio wrote:
> Hi,
> 
> A small annoyance some users outside
> english speaking countries usually
> experiment when learning programming
> languages is that real numbers use
> a '.' instead of ','. Of course, that
> is not such a problem except for the
> inconsistence between computer and
> free hand notation.
> 
> Do you think 'read' (actually,
> 'readsPrec'?) could be made to also
> read the international convention
> (ie., read "1,5" would also work
> besides read "1.5")? I'm happy to
> finaly use a language where I can
> use words of my language to name
> variables, so I wonder if we could
> also make that step.
> 

Isn't it locale dependent? If it isn't, it should be. Try setting your
locale right and see if things work. At least awk work fine that way.

Although I don't like too much that kinda stuff, I usually set the
locale to C so I keep all my programs behaving consistently. I have
problems with that stuff before (a file generated by an awk script had ,
instead of . and that would confuse other computers with a different
locale).
From noteventime at gmail.com  Tue Sep 16 16:19:31 2008
From: noteventime at gmail.com (Tilo Wiklund)
Date: Tue Sep 16 16:17:12 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: <1221596371.7852.7.camel@tilo-laptop>

Wouldn't that make it hard to parse lists of floats?

On Tue, 2008-09-16 at 09:29 -0300, Mauricio wrote:
> Hi,
> 
> A small annoyance some users outside
> english speaking countries usually
> experiment when learning programming
> languages is that real numbers use
> a '.' instead of ','. Of course, that
> is not such a problem except for the
> inconsistence between computer and
> free hand notation.
> 
> Do you think 'read' (actually,
> 'readsPrec'?) could be made to also
> read the international convention
> (ie., read "1,5" would also work
> besides read "1.5")? I'm happy to
> finaly use a language where I can
> use words of my language to name
> variables, so I wonder if we could
> also make that step.
> 
> Thanks,
> Maur?cio
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/8e7301da/attachment.bin
From miguelimo38 at yandex.ru  Tue Sep 16 16:23:04 2008
From: miguelimo38 at yandex.ru (Miguel Mitrofanov)
Date: Tue Sep 16 16:20:41 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: <3DBC4412-7C83-4615-805F-1BB4F161A8A7@yandex.ru>


On 16 Sep 2008, at 16:29, Mauricio wrote:

> I'm happy to
> finaly use a language where I can
> use words of my language to name
> variables, so I wonder if we could
> also make that step.

Really?

There is a bunch of languages (like "Glagol") that use words of  
Russian language as keywords; AFAIK there aren't any Russian  
programmer who uses them. I've always felt sorry for English-speaking  
programmers: they HAVE to use the same words as keywords and as usual  
talking words at the same time.
From twanvl at gmail.com  Tue Sep 16 16:28:30 2008
From: twanvl at gmail.com (Twan van Laarhoven)
Date: Tue Sep 16 16:26:00 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: <48D016EE.4060605@gmail.com>

Mauricio wrote:
> Do you think 'read' (actually,
> 'readsPrec'?) could be made to also
> read the international convention
> (ie., read "1,5" would also work
> besides read "1.5")? I'm happy to
> finaly use a language where I can
> use words of my language to name
> variables, so I wonder if we could
> also make that step.

That would be quite problematic in combination with lists, is

   read "[1,2,3,4]" == [1,2,3,4]

or

   read "[1,2,3,4]" == [1.2, 3.4]

Or something else?


Localized reading should be somewhere else, perhaps related to Locales.

As an aside, this is one of the (many) places where Haskell has made the right 
choice. In other languages such as Java input functions suddenly break when the 
user has a different locale setting. While for user input this might be desired, 
in my experience much of the i/o a program does is with well defined file 
formats where changing '.' to ',' just shouldn't happen.


Twan
From dpiponi at gmail.com  Tue Sep 16 16:45:41 2008
From: dpiponi at gmail.com (Dan Piponi)
Date: Tue Sep 16 16:43:11 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: <625b74080809161345y6b3cb518hbc3f9221109bc188@mail.gmail.com>

Mauricio asked:

> Do you think 'read' (actually,
> 'readsPrec'?) could be made to also
> read the international convention
> (ie., read "1,5" would also work
> besides read "1.5")?

What would you hope the value of

> read "(1,2,3)"::(Float,Float)

would be?
--
Dan
From trebla at vex.net  Tue Sep 16 17:08:53 2008
From: trebla at vex.net (Albert Y. C. Lai)
Date: Tue Sep 16 17:06:24 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: <48D02065.4030508@vex.net>

Mauricio wrote:
> Do you think 'read' (actually,
> 'readsPrec'?) could be made to also
> read the international convention

No. read and show are meant to be KISS, suitable for toy programs and 
casual debugging messages. Real applications should use or invent a 
sophisticated, general library.

(The same way real user interfaces do not use getLine.)
From huschi at gmx.org  Tue Sep 16 17:32:04 2008
From: huschi at gmx.org (Martin Huschenbett)
Date: Tue Sep 16 17:29:35 2008
Subject: [Haskell-cafe] Real World HAppS: Cabalized,	Self-Demoing HAppS
	Tutorial (Version 3)
In-Reply-To: <910ddf450809120807j6d1379b3uc8a23c8dc8720b55@mail.gmail.com>
References: <910ddf450809120807j6d1379b3uc8a23c8dc8720b55@mail.gmail.com>
Message-ID: <48D025D4.8020102@gmx.org>

Hi all,

taking a look at this tutorial under Windows Vista I ran into a problem:

happs-tutorial depends on HAppS-state which again depends on the unix 
package which doesn't work under windows.

So my question is: is there another way to compile HAppS-State and 
happs-tutorial on windows?

Regards,

Martin.

Thomas Hartman schrieb:
> I pushed a new version of happs-tutorial to the online demo at
> 
> http://happstutorial.com:5001 This is also on hackage: cabal install
> happs-tutorial. (now version 3.)
> 
> or darcs get http://code.haskell.org/happs-tutorial for the latest
> 
> The demo/tutorial has the same basic functionality as the last release
> -- just a login form essentially -- but a lot more bling now. Like
> menu link items that change colors when the page is clicked. Also the
> login form that gives sane error messages.
> 
> The focus for this release was on explaining how I used StringTemplate
> with HAppS.
> 
> Hopefully in version 4 I'll finally get to State and Macid! And
> hopefully some functionality that actually does something beyond just
> showing what users have created logins :)
> 
> Thomas
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From jules at jellybean.co.uk  Tue Sep 16 17:38:34 2008
From: jules at jellybean.co.uk (Jules Bean)
Date: Tue Sep 16 17:36:04 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: <48D0275A.703@jellybean.co.uk>

Mauricio wrote:
> Do you think 'read' (actually,
> 'readsPrec'?) could be made to also
> read the international convention
> (ie., read "1,5" would also work
> besides read "1.5")? I'm happy to
> finaly use a language where I can
> use words of my language to name
> variables, so I wonder if we could
> also make that step.

The purpose of 'read' is to read haskell notation, not to read 
locally-sensitive notation.

So the right question to ask is "should we change haskell's lexical 
syntax to support locally-sensitive number notation".

IMO, the answer is no.

(1,3) would start to mean (13/10) and we'd need another notational rule 
(whitespace around commas) for numeric tuples. Feels like a painful 
special case to me.

Jules
From ryani.spam at gmail.com  Tue Sep 16 17:55:06 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Tue Sep 16 17:52:38 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: 
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
	
	<2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>
	
	<2f9b2d30809160147t15889c9bxc7cd33fff229729e@mail.gmail.com>
	
	
Message-ID: <2f9b2d30809161455v54e2ea10k6083ef1181c9ded5@mail.gmail.com>

"at time = id" is not valid Haskell.  It's expositional, describing a
law that "at" and "time" fulfill.

It's like saying "m >>= return = m" when describing the Monad laws.
You can't write that directly, but it better be true!

  -- ryan

2008/9/16 Daryoush Mehrtash :
> I can sort of see what is happening in "time = O (pure (Fun id))".
> But I am not sure I understand this:
>
>    time :: Behavior Time
>    at time = id
>
> as I understand it "at" is a function that take Behaviour and returns
> a function that is Time -> a.    How can you have a function on the
> left side of the equation?
>
> thanks,
>
> Daryoush
>
>
> 2008/9/16 Conal Elliott :
>> Hi Ryan,
>>
>> Thanks very much for these explanations.  Clear and right on!
>>
>> Best regards,  - Conal
>>
>> P.S. I'll be at ICFP and am looking forward to seeing folks there.
>>
>> 2008/9/16 Ryan Ingram 
>>>
>>> The key insight is that Behavior a is not necessarily a time function;
>>> it's abstract.  But you can treat it as if it was one by observing it
>>> with "at".
>>>
>>> In Conal's paper, the internal type of behavior is:
>>>
>>> > -- composition of types; like (.) at the type level
>>> > newtype O h g a = O (h (g a))
>>>
>>> > -- function type that can directly observe some constant functions
>>> > data Fun t a = K a | Fun (t -> a)
>>>
>>> > -- Behavior a ~~ Reactive (Fun Time a)
>>> > type Behavior = Reactive `O` Fun Time
>>>
>>> > -- Reactive has a current value and an event stream of values to switch
>>> > to at particular times
>>> > -- Then an event is just a reactive that might not have a current value
>>> > until some time in the future.
>>> > data Reactive a = Stepper a (Event a)
>>> > newtype Event a = Ev (Future (Reactive a))
>>>
>>> Now, at the internal level, you can write the primitive "time" as
>>>
>>> > time :: Behavior Time
>>> > time = O (pure (Fun id))
>>>
>>> with "pure" from the Applicative instance for Reactive:
>>>
>>> > pure x = Stepper x never
>>>
>>> "never" is a future that never occurs, so the reactive value never
>>> changes.
>>>
>>> From a users' point of view, all this is invisible--you only get a few
>>> observation functions (including "at").  Internally, however, constant
>>> behaviors, or behaviors that contain "steps" that are constant, can be
>>> evaluated extremely quickly; once the behavior returns K x, you know
>>> that the result can't change until the next event in the reactive
>>> stream.  You only need to continuously evaluate the behavior if you
>>> get a "Fun" result.  See sinkB on page 9 of the paper to understand
>>> how this is used to improve performance.
>>>
>>> The semantic function "at" drives the model; it allows you to describe
>>> the laws for the library to fulfill very succinctly:
>>>
>>> at (fmap f x) = fmap f (at x)
>>> at (pure x) = pure x
>>> at (f <*> x) = at f <*> at x
>>> at (return x) = return x
>>> at (m >>= f) = at m >>= at . f
>>> etc.
>>>
>>> Similarily, for Futures, we have "force :: Future a -> (Time, a)"
>>>
>>> force (fmap f z) = (t, f x) where (t,x) = force z
>>> force (pure x) = (minBound, x)
>>> force (ff <*> fx) = (max tf tx, f x) where (tf, f) = force ff ; (tx,
>>> x) = force fx
>>> force (return x) = (minBound, x)
>>> force (m >>= f) = (max tm tx, x) where (tm, v) = force m; (tx, x) = force
>>> (f v)
>>> etc.
>>>
>>> This gives the library user solid ground to stand on when reasoning
>>> about their code; it should do what they expect.  And it gives the
>>> library author a very strong goal to shoot for: just fulfill these
>>> laws, and the code is correct!  This allows radical redesigns of the
>>> internals of the system while maintaining a consistent and intuitive
>>> interface that reuses several classes that the user is hopefully
>>> already familiar with: monoids, functors, applicative functors, and
>>> monads.
>>>
>>>  -- ryan
>>>
>>> 2008/9/16 Daryoush Mehrtash :
>>> > ? I don't follow the "at" and  "type B a".  "Behavior a" itself is a
>>> > time function.   At least in the version of the code that was
>>> > developed in Pual Hudak's Haskell School of Expression it was defined
>>> > as:
>>> >
>>> >> newtype Behavior a
>>> >>   = Behavior (([Maybe UserAction],[Time]) -> [a])
>>> >
>>> > In a function like time you can see that the "at" function makes things
>>> > simpler.
>>> >
>>> > In the original version  time was defined as:
>>> >
>>> >> time :: Behavior Time
>>> >> time = Behavior (\(_,ts) -> ts)
>>> >
>>> > In Conal's paper
>>> >
>>> > time :: Behavior Time
>>> > at time = id
>>> >
>>> > Comparing the two implementation of the time, it seems to me that "at"
>>> > and "type B a" has put the design on a more solid ground.  But I don't
>>> > quite understand the thought process, or the principal behind what is
>>> > happening.
>>> >
>>> > daryoush
>>> >
>>> >
>>> > On Mon, Sep 15, 2008 at 10:46 AM, Ryan Ingram 
>>> > wrote:
>>> >> Here's a quick overview that might help you.
>>> >>
>>> >> For a reactive behavior, we have two types to think about:
>>> >>
>>> >> type B a = Time -> a
>>> >>    (the semantic domain)
>>> >>
>>> >> data Behavior a = ?
>>> >>    (the library's implementation).
>>> >> at :: Behavior a -> B a
>>> >>    (observation function)
>>> >>
>>> >> This is really just classic "information hiding" as you would do with
>>> >> any abstract data type.  Consider a simple "stack" data structure that
>>> >> supports push and pop.
>>> >>
>>> >>> data S a = S
>>> >>>     { popS :: Maybe (a, S a)
>>> >>>     , pushS :: a -> S a
>>> >>>     }
>>> >>
>>> >>> data Stack a = ?
>>> >>> observeStack :: Stack a -> S a
>>> >>
>>> >> As a library user, you don't really care about the implementation of
>>> >> Stack, just as a user of Conal's library doesn't really care about the
>>> >> implementation of Behavior.  What you *do* care about is that you can
>>> >> think about it in the simpler terms of "Time -> a" which is the model
>>> >> he has chosen.
>>> >>
>>> >> The rest of the library design comes from taking that model and
>>> >> thinking about what typeclasses and operations "Time -> a" should
>>> >> support, and creating typeclass morphisms between Behavior a and B a
>>> >> where necessary.  For example:
>>> >>
>>> >>> -- This makes (r -> a) into a functor over a; it is a generalization
>>> >>> of Time -> a
>>> >>> instance Functor ((->) r) where
>>> >>>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
>>> >>>    fmap f x = \r -> f (x r)
>>> >>>    -- or, "fmap = (.)", if you're golfing :)
>>> >>
>>> >> In order for the morphism between B and Behavior to make sense, you
>>> >> want this law to hold:
>>> >>   fmap f (at behavior) = at (fmap f behavior)
>>> >> for all behavior :: Behavior a.
>>> >>
>>> >> The fmap on the left applies to B which is (Time ->); the fmap on the
>>> >> right applies to Behavior.
>>> >>
>>> >> Conal writes this law more elegantly like this:
>>> >>> instance(semantic) Functor Behavior where
>>> >>>    fmap f . at = at . fmap f
>>> >>
>>> >> As long as you as the user can think about behaviors generally as
>>> >> functions of Time, you can ignore the implementation details, and
>>> >> things that you expect to work should work.  This drives the design of
>>> >> the entire library, with similar morphisms over many typeclasses
>>> >> between Event and E, Reactive and B, etc.
>>> >>
>>> >>  -- ryan
>>> >>
>>> >> On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash
>>> >>  wrote:
>>> >>> Interestingly, I was trying to read his paper when I realized that I
>>> >>> needed to figure out the meaning of denotational model, semantic
>>> >>> domain, semantic functions.  Other Haskell books didn't talk about
>>> >>> design in those terms, but obviously for him this is how he is driving
>>> >>> his design.   I am looking for a simpler tutorial, text book like
>>> >>> reference on the topic.
>>> >>>
>>> >>> Daryoush
>>> >>>
>>> >>> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram 
>>> >>> wrote:
>>> >>>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
>>> >>>> paper for an in-depth real-world example.
>>> >>>>
>>> >>>> http://www.conal.net/papers/simply-reactive
>>> >>>>
>>> >>>>  -- ryan
>>> >>>>
>>> >>>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash
>>> >>>>  wrote:
>>> >>>>> I have been told that for a Haskell/Functional programmer the
>>> >>>>> process
>>> >>>>> of design starts with defining Semantic Domain, Function, and
>>> >>>>> denotational model of the problem.  I have done some googling on the
>>> >>>>> topic but haven't found a good reference on it.    I would
>>> >>>>> appreciate
>>> >>>>> any good references on the topic.
>>> >>>>>
>>> >>>>> thanks,
>>> >>>>>
>>> >>>>> daryoush
>>> >>>>>
>>> >>>>> ps.  I have found referneces like
>>> >>>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>>> >>>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>>> >>>>> which doesn't do any good for me.    I need something with a more
>>> >>>>> real
>>> >>>>> examples.
>>> >>>>> _______________________________________________
>>> >>>>> Haskell-Cafe mailing list
>>> >>>>> Haskell-Cafe@haskell.org
>>> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>
>
>
> --
> Daryoush
>
> Weblog: http://perlustration.blogspot.com/
>
From conal at conal.net  Tue Sep 16 18:23:57 2008
From: conal at conal.net (Conal Elliott)
Date: Tue Sep 16 18:21:26 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: <2f9b2d30809161455v54e2ea10k6083ef1181c9ded5@mail.gmail.com>
References: 
	<2f9b2d30809150133q5a77fdb7xe2f896641af488fc@mail.gmail.com>
	
	<2f9b2d30809151046v35b5304fw29db586ce4ec60e2@mail.gmail.com>
	
	<2f9b2d30809160147t15889c9bxc7cd33fff229729e@mail.gmail.com>
	
	
	<2f9b2d30809161455v54e2ea10k6083ef1181c9ded5@mail.gmail.com>
Message-ID: 

exactly.  it's a specification of the denotational semantics of "time".  any
valid implementation must satisfy such properties.

2008/9/16 Ryan Ingram 

> "at time = id" is not valid Haskell.  It's expositional, describing a
> law that "at" and "time" fulfill.
>
> It's like saying "m >>= return = m" when describing the Monad laws.
> You can't write that directly, but it better be true!
>
>  -- ryan
>
> 2008/9/16 Daryoush Mehrtash :
> > I can sort of see what is happening in "time = O (pure (Fun id))".
> > But I am not sure I understand this:
> >
> >    time :: Behavior Time
> >    at time = id
> >
> > as I understand it "at" is a function that take Behaviour and returns
> > a function that is Time -> a.    How can you have a function on the
> > left side of the equation?
> >
> > thanks,
> >
> > Daryoush
> >
> >
> > 2008/9/16 Conal Elliott :
> >> Hi Ryan,
> >>
> >> Thanks very much for these explanations.  Clear and right on!
> >>
> >> Best regards,  - Conal
> >>
> >> P.S. I'll be at ICFP and am looking forward to seeing folks there.
> >>
> >> 2008/9/16 Ryan Ingram 
> >>>
> >>> The key insight is that Behavior a is not necessarily a time function;
> >>> it's abstract.  But you can treat it as if it was one by observing it
> >>> with "at".
> >>>
> >>> In Conal's paper, the internal type of behavior is:
> >>>
> >>> > -- composition of types; like (.) at the type level
> >>> > newtype O h g a = O (h (g a))
> >>>
> >>> > -- function type that can directly observe some constant functions
> >>> > data Fun t a = K a | Fun (t -> a)
> >>>
> >>> > -- Behavior a ~~ Reactive (Fun Time a)
> >>> > type Behavior = Reactive `O` Fun Time
> >>>
> >>> > -- Reactive has a current value and an event stream of values to
> switch
> >>> > to at particular times
> >>> > -- Then an event is just a reactive that might not have a current
> value
> >>> > until some time in the future.
> >>> > data Reactive a = Stepper a (Event a)
> >>> > newtype Event a = Ev (Future (Reactive a))
> >>>
> >>> Now, at the internal level, you can write the primitive "time" as
> >>>
> >>> > time :: Behavior Time
> >>> > time = O (pure (Fun id))
> >>>
> >>> with "pure" from the Applicative instance for Reactive:
> >>>
> >>> > pure x = Stepper x never
> >>>
> >>> "never" is a future that never occurs, so the reactive value never
> >>> changes.
> >>>
> >>> From a users' point of view, all this is invisible--you only get a few
> >>> observation functions (including "at").  Internally, however, constant
> >>> behaviors, or behaviors that contain "steps" that are constant, can be
> >>> evaluated extremely quickly; once the behavior returns K x, you know
> >>> that the result can't change until the next event in the reactive
> >>> stream.  You only need to continuously evaluate the behavior if you
> >>> get a "Fun" result.  See sinkB on page 9 of the paper to understand
> >>> how this is used to improve performance.
> >>>
> >>> The semantic function "at" drives the model; it allows you to describe
> >>> the laws for the library to fulfill very succinctly:
> >>>
> >>> at (fmap f x) = fmap f (at x)
> >>> at (pure x) = pure x
> >>> at (f <*> x) = at f <*> at x
> >>> at (return x) = return x
> >>> at (m >>= f) = at m >>= at . f
> >>> etc.
> >>>
> >>> Similarily, for Futures, we have "force :: Future a -> (Time, a)"
> >>>
> >>> force (fmap f z) = (t, f x) where (t,x) = force z
> >>> force (pure x) = (minBound, x)
> >>> force (ff <*> fx) = (max tf tx, f x) where (tf, f) = force ff ; (tx,
> >>> x) = force fx
> >>> force (return x) = (minBound, x)
> >>> force (m >>= f) = (max tm tx, x) where (tm, v) = force m; (tx, x) =
> force
> >>> (f v)
> >>> etc.
> >>>
> >>> This gives the library user solid ground to stand on when reasoning
> >>> about their code; it should do what they expect.  And it gives the
> >>> library author a very strong goal to shoot for: just fulfill these
> >>> laws, and the code is correct!  This allows radical redesigns of the
> >>> internals of the system while maintaining a consistent and intuitive
> >>> interface that reuses several classes that the user is hopefully
> >>> already familiar with: monoids, functors, applicative functors, and
> >>> monads.
> >>>
> >>>  -- ryan
> >>>
> >>> 2008/9/16 Daryoush Mehrtash :
> >>> > ? I don't follow the "at" and  "type B a".  "Behavior a" itself is a
> >>> > time function.   At least in the version of the code that was
> >>> > developed in Pual Hudak's Haskell School of Expression it was defined
> >>> > as:
> >>> >
> >>> >> newtype Behavior a
> >>> >>   = Behavior (([Maybe UserAction],[Time]) -> [a])
> >>> >
> >>> > In a function like time you can see that the "at" function makes
> things
> >>> > simpler.
> >>> >
> >>> > In the original version  time was defined as:
> >>> >
> >>> >> time :: Behavior Time
> >>> >> time = Behavior (\(_,ts) -> ts)
> >>> >
> >>> > In Conal's paper
> >>> >
> >>> > time :: Behavior Time
> >>> > at time = id
> >>> >
> >>> > Comparing the two implementation of the time, it seems to me that
> "at"
> >>> > and "type B a" has put the design on a more solid ground.  But I
> don't
> >>> > quite understand the thought process, or the principal behind what is
> >>> > happening.
> >>> >
> >>> > daryoush
> >>> >
> >>> >
> >>> > On Mon, Sep 15, 2008 at 10:46 AM, Ryan Ingram 
> >>> > wrote:
> >>> >> Here's a quick overview that might help you.
> >>> >>
> >>> >> For a reactive behavior, we have two types to think about:
> >>> >>
> >>> >> type B a = Time -> a
> >>> >>    (the semantic domain)
> >>> >>
> >>> >> data Behavior a = ?
> >>> >>    (the library's implementation).
> >>> >> at :: Behavior a -> B a
> >>> >>    (observation function)
> >>> >>
> >>> >> This is really just classic "information hiding" as you would do
> with
> >>> >> any abstract data type.  Consider a simple "stack" data structure
> that
> >>> >> supports push and pop.
> >>> >>
> >>> >>> data S a = S
> >>> >>>     { popS :: Maybe (a, S a)
> >>> >>>     , pushS :: a -> S a
> >>> >>>     }
> >>> >>
> >>> >>> data Stack a = ?
> >>> >>> observeStack :: Stack a -> S a
> >>> >>
> >>> >> As a library user, you don't really care about the implementation of
> >>> >> Stack, just as a user of Conal's library doesn't really care about
> the
> >>> >> implementation of Behavior.  What you *do* care about is that you
> can
> >>> >> think about it in the simpler terms of "Time -> a" which is the
> model
> >>> >> he has chosen.
> >>> >>
> >>> >> The rest of the library design comes from taking that model and
> >>> >> thinking about what typeclasses and operations "Time -> a" should
> >>> >> support, and creating typeclass morphisms between Behavior a and B a
> >>> >> where necessary.  For example:
> >>> >>
> >>> >>> -- This makes (r -> a) into a functor over a; it is a
> generalization
> >>> >>> of Time -> a
> >>> >>> instance Functor ((->) r) where
> >>> >>>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
> >>> >>>    fmap f x = \r -> f (x r)
> >>> >>>    -- or, "fmap = (.)", if you're golfing :)
> >>> >>
> >>> >> In order for the morphism between B and Behavior to make sense, you
> >>> >> want this law to hold:
> >>> >>   fmap f (at behavior) = at (fmap f behavior)
> >>> >> for all behavior :: Behavior a.
> >>> >>
> >>> >> The fmap on the left applies to B which is (Time ->); the fmap on
> the
> >>> >> right applies to Behavior.
> >>> >>
> >>> >> Conal writes this law more elegantly like this:
> >>> >>> instance(semantic) Functor Behavior where
> >>> >>>    fmap f . at = at . fmap f
> >>> >>
> >>> >> As long as you as the user can think about behaviors generally as
> >>> >> functions of Time, you can ignore the implementation details, and
> >>> >> things that you expect to work should work.  This drives the design
> of
> >>> >> the entire library, with similar morphisms over many typeclasses
> >>> >> between Event and E, Reactive and B, etc.
> >>> >>
> >>> >>  -- ryan
> >>> >>
> >>> >> On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash
> >>> >>  wrote:
> >>> >>> Interestingly, I was trying to read his paper when I realized that
> I
> >>> >>> needed to figure out the meaning of denotational model, semantic
> >>> >>> domain, semantic functions.  Other Haskell books didn't talk about
> >>> >>> design in those terms, but obviously for him this is how he is
> driving
> >>> >>> his design.   I am looking for a simpler tutorial, text book like
> >>> >>> reference on the topic.
> >>> >>>
> >>> >>> Daryoush
> >>> >>>
> >>> >>> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram  >
> >>> >>> wrote:
> >>> >>>> I recommend reading Conal Elliott's "Efficient Functional
> Reactivity"
> >>> >>>> paper for an in-depth real-world example.
> >>> >>>>
> >>> >>>> http://www.conal.net/papers/simply-reactive
> >>> >>>>
> >>> >>>>  -- ryan
> >>> >>>>
> >>> >>>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash
> >>> >>>>  wrote:
> >>> >>>>> I have been told that for a Haskell/Functional programmer the
> >>> >>>>> process
> >>> >>>>> of design starts with defining Semantic Domain, Function, and
> >>> >>>>> denotational model of the problem.  I have done some googling on
> the
> >>> >>>>> topic but haven't found a good reference on it.    I would
> >>> >>>>> appreciate
> >>> >>>>> any good references on the topic.
> >>> >>>>>
> >>> >>>>> thanks,
> >>> >>>>>
> >>> >>>>> daryoush
> >>> >>>>>
> >>> >>>>> ps.  I have found referneces like
> >>> >>>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics which
> >>> >>>>> talks about semantic domain for "the Haskell programs 10, 9+1,
> 2*5"
> >>> >>>>> which doesn't do any good for me.    I need something with a more
> >>> >>>>> real
> >>> >>>>> examples.
> >>> >>>>> _______________________________________________
> >>> >>>>> Haskell-Cafe mailing list
> >>> >>>>> Haskell-Cafe@haskell.org
> >>> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>> >>>>>
> >>> >>>>
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe@haskell.org
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>
> >>
> >>
> >
> >
> >
> > --
> > Daryoush
> >
> > Weblog: http://perlustration.blogspot.com/
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080917/c102bd43/attachment.htm
From bos at serpentine.com  Tue Sep 16 18:33:24 2008
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Sep 16 18:30:54 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: 

On Tue, Sep 16, 2008 at 5:29 AM, Mauricio  wrote:

>
> Do you think 'read' (actually,
> 'readsPrec'?) could be made to also
> read the international convention
> (ie., read "1,5" would also work
> besides read "1.5")?


No, as read is really intended to be a language-level tool, not something
that you should expose to end users. For locale-aware number input and
formatting, you'd want to do something else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/8f390aa6/attachment.htm
From lgreg.meredith at biosimilarity.com  Tue Sep 16 18:37:21 2008
From: lgreg.meredith at biosimilarity.com (Greg Meredith)
Date: Tue Sep 16 18:34:51 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
Message-ID: <5de3f5ca0809161537v6f501d3bh9ac4763454eb3493@mail.gmail.com>

Daryoush,

Hopefully, the other replies about proving the monad laws already answered
your previous question: yes!

As for notions of semantic domain and denotational model, these ideas go
back quite a ways; but, were given solid footing by Dana
Scott.
In a nutshell, we have essentially three views of a computation

   - Operational  --
   computation is captured in a program and rules for executing it
   - Logical  --
   computation is captured in a proof and rules for normalizing it
   - Denotational  --
   computation is captured as a (completely unfolded) mathematical structure

In the latter view we think of computations/programs as denoting some
(usually infinitary) mathematical object. Our
aimis to completely define
the meaning of programs in terms of maps between
their syntactic representation and the mathematical objects their syntax is
intended to denote. (Notationally, one often writes such maps as [| - |] :
Program -> Denotation.) For example, we model terms in the lambda calculus
as elements in a D-infinity domain or Bohm trees or ... . Or, in more modern
parlance, we model terms in the lambda calculus as morphisms in some
Cartesian closed category, and the types of those terms as objects in said
category. The gold standard of quality of such a model is full
abstraction--
when the denotational notion of equivalence exactly coincides with an
intended operational notion of equivalence. In symbols,


   - P ~ Q <=> [| P |] = [| Q |], where ~ and = are the operational and
   denotational notions of equivalence, respectively


The techniques of denotational semantics have been very fruitful, but
greatly improved by having to rub elbows with operational characterizations.
The original proposals for denotational models of the lambda calculus were
much too arms length from the intensional structure implicit in the notion
of computation and thus failed to achieve full abstraction even for toy
models of lambda enriched with naturals and booleans (cf the so-called full
abstraction for PCF
problem).
On the flip side, providing a better syntactic exposure of the use of
resources -- ala linear logic -- aided the denotational programme.

More generally, operational models fit neatly into two ready-made notions of
equivalence

   - contextual
equivalence--
behaves the same in all contexts
   - bisimulation  -- behaves the
   same under all observations

Moreover, these can be seen to coincide with ready-made notions of
equivalence under the logical view of programs. Except for syntactically
derived initial/final denotational models -- the current theory usually
finds a more "home-grown" denotational notion of equivalence. In fact, i
submit that it is this very distance from the syntactic presentation that
has weakened the more popular understanding of "denotational" models to just
this -- whenever you have some compositionally defined map from one
representation to another that respects some form of equivalence, the target
is viewed as the denotation.

Best wishes,

--greg

Date: Mon, 15 Sep 2008 10:13:53 -0700
From: "Daryoush Mehrtash" 
Subject: Re: [Haskell-cafe] Semantic Domain, Function,  and
       denotational model.....
To: "Ryan Ingram" 
Cc: Haskell Cafe 
Message-ID:
       
Content-Type: text/plain; charset=ISO-8859-1

Interestingly, I was trying to read his paper when I realized that I
needed to figure out the meaning of denotational model, semantic
domain, semantic functions.  Other Haskell books didn't talk about
design in those terms, but obviously for him this is how he is driving
his design.   I am looking for a simpler tutorial, text book like
reference on the topic.

Daryoush

On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram  wrote:
> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
> paper for an in-depth real-world example.
>
> http://www.conal.net/papers/simply-reactive
>
>  -- ryan
>
> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash 
wrote:
>> I have been told that for a Haskell/Functional programmer the process
>> of design starts with defining Semantic Domain, Function, and
>> denotational model of the problem.  I have done some googling on the
>> topic but haven't found a good reference on it.    I would appreciate
>> any good references on the topic.
>>
>> thanks,
>>
>> daryoush
>>
>> ps.  I have found referneces like
>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>> which doesn't do any good for me.    I need something with a more real
>> examples.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>



-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/b15a6461/attachment.htm
From aslatter at gmail.com  Tue Sep 16 18:59:57 2008
From: aslatter at gmail.com (Antoine Latter)
Date: Tue Sep 16 18:57:27 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
In-Reply-To: 
References: 
Message-ID: <694519c50809161559x1092505jbd038ad82593d797@mail.gmail.com>

On Tue, Sep 16, 2008 at 9:30 AM, Mauricio  wrote:
> Hi,
>
> I would like to write a Haskell pretty-printer,
> using standard libraries for that. How can I
> check if the original and the pretty-printed
> versions are the same? For instance, is there
> a file generated by GHC at the compilation
> pipe that is always guaranteed to have the
> same MD5 hash when it comes from equivalent
> source?

I don't know the answers to your question, but if you're looking for
inspiration on your project you should check out the following two
packages:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts

-Antoine
From allbery at ece.cmu.edu  Tue Sep 16 19:03:53 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Tue Sep 16 19:01:30 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
In-Reply-To: 
References: 
Message-ID: 

On 2008 Sep 16, at 10:30, Mauricio wrote:
> I would like to write a Haskell pretty-printer,
> using standard libraries for that. How can I
> check if the original and the pretty-printed
> versions are the same? For instance, is there
> a file generated by GHC at the compilation
> pipe that is always guaranteed to have the
> same MD5 hash when it comes from equivalent
> source?

Compare .hi files?

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From philip.weaver at gmail.com  Tue Sep 16 19:21:12 2008
From: philip.weaver at gmail.com (Philip Weaver)
Date: Tue Sep 16 19:18:40 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
In-Reply-To: 
References: 
Message-ID: 

On Tue, Sep 16, 2008 at 7:30 AM, Mauricio  wrote:

> Hi,
>
> I would like to write a Haskell pretty-printer,
> using standard libraries for that. How can I
> check if the original and the pretty-printed
> versions are the same? For instance, is there
> a file generated by GHC at the compilation
> pipe that is always guaranteed to have the
> same MD5 hash when it comes from equivalent
> source?
>

I don't know, but you can parse the resulting concrete syntax and compare
the original abstract syntax to the new abstract syntax.


>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/1eab4ce9/attachment.htm
From jgm at berkeley.edu  Tue Sep 16 19:49:28 2008
From: jgm at berkeley.edu (John MacFarlane)
Date: Tue Sep 16 19:46:47 2008
Subject: [Haskell-cafe] Mac OS X dylib woes
Message-ID: <20080916234928.GA19133@berkeley.edu>

I'm hoping some Haskell developers who use Macs can help me with this
one. I can install pcre-light just fine using cabal install. But when I
try to use it, I get this error:

GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
:Loading package base ... linking ... done.
Prelude> :m Text.Regex.PCRE.Light.Char8
Prelude Text.Regex.PCRE.Light.Char8> compile "h." []
Loading package array-0.1.0.0 ... linking ... done.
Loading package bytestring-0.9.0.1 ... linking ... done.
Loading package pcre-light-0.3.1 ... can't load .so/.DLL for: pcre (dlopen(libpcre.dylib, 10): image not found)

OK, so it can't find the pcre library (which is in /opt/local/lib).
I can fix that:

export DYLD_LIBRARY_PATH=/opt/local/lib

Now it works. But other things are broken! For example, I can't run vim,
which looks for a library called libJPEG.dylib and now finds libjpeg.dylib
in /opt/local/lib (case-insensitive file system!).

The apple website recommends against setting DYLD_LIBRARY_PATH.
Instead, they say, the paths to the libraries should be hard-coded into
the binary:
http://discussions.apple.com/thread.jspa?threadID=1670523&tstart=0

I'm sure others have had the same problem.  What's the solution?

John
From vanenkj at gmail.com  Tue Sep 16 20:32:55 2008
From: vanenkj at gmail.com (John Van Enk)
Date: Tue Sep 16 20:30:23 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
In-Reply-To: 
References: 
Message-ID: 

Before you reinvent the wheel, have you looked at Language.Haskell.Pretty?

http://haskell.org/ghc/docs/latest/html/libraries/haskell-src/Language-Haskell-Pretty.html

On Tue, Sep 16, 2008 at 10:30 AM, Mauricio  wrote:

> Hi,
>
> I would like to write a Haskell pretty-printer,
> using standard libraries for that. How can I
> check if the original and the pretty-printed
> versions are the same? For instance, is there
> a file generated by GHC at the compilation
> pipe that is always guaranteed to have the
> same MD5 hash when it comes from equivalent
> source?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
/jve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080916/d6c408b1/attachment.htm
From aeyakovenko at gmail.com  Tue Sep 16 20:46:02 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Tue Sep 16 20:43:33 2008
Subject: [Haskell-cafe] haskell blas bindings: does iomatrix gemv
	transposing of matrix a?
Message-ID: 

Hey Patric,

Thanks for your great work on the blas bidnings.  I have a question on
gemv.  I thought its possible for blas to transpose the input matrix
before doing the multiplication.  Is it possible to do that with the
haskell bindings?  Or am I mistaken in how gemv is used

Thanks,
Anatoly
From jason.dusek at gmail.com  Tue Sep 16 21:36:30 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Tue Sep 16 21:34:00 2008
Subject: [Haskell-cafe] GHC trouble on Leopard
In-Reply-To: 
References: 
Message-ID: <42784f260809161836o125c1c51u2303b1fb20d98378@mail.gmail.com>

  Could you provide us with the command line you were using?

--
_jsn
From tomahawkins at gmail.com  Wed Sep 17 00:12:29 2008
From: tomahawkins at gmail.com (Tom Hawkins)
Date: Wed Sep 17 00:10:08 2008
Subject: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord
In-Reply-To: 
References: <594c1e830809151101j3a2dc572g21ffda0710520950@mail.gmail.com>
	
	
	<594c1e830809151425j5ffd8cfep7159a1e5e3110de9@mail.gmail.com>
	
Message-ID: <594c1e830809162112j82f44b5oa1ad77c26f677ceb@mail.gmail.com>

Thanks for all the input.  It helped me arrive at the following
solution.  I took the strategy of converting the parameterized type
into an unparameterized type which can be easily compared for Eq and
Ord.  The unparameterized type enumerates the possible Const types
with help from an auxiliary type class.

-- The primary Expr type.
data Expr a where
  Const :: ExprConst a => a -> Expr a
  Equal :: Expr a -> Expr a -> Expr Bool

-- An "untyped" Expr used to compute Eq and Ord of the former.
-- Note each type of constant is enumerated.
data UExpr
  = UConstBool   Bool
  | UConstInt    Int
  | UConstFloat  Float
  | UEqual UExpr UExpr
  deriving (Eq, Ord)

-- A type class to assist in converting Expr to UExpr.
class    ExprConst a     where uexprConst :: a -> UExpr
instance ExprConst Bool  where uexprConst = UConstBool
instance ExprConst Int   where uexprConst = UConstInt
instance ExprConst Float where uexprConst = UConstFloat

-- The conversion function.
uexpr :: Expr a -> UExpr
uexpr (Const a) = uexprConst a
uexpr (Equal a b) = UEqual (uexpr a) (uexpr b)

-- Finally the implementation of Eq and Ord for Expr.
instance Eq  (Expr a) where a == b = uexpr a == uexpr b
instance Ord (Expr a) where compare a b = compare (uexpr a) (uexpr b)
From chak at cse.unsw.edu.au  Wed Sep 17 00:51:24 2008
From: chak at cse.unsw.edu.au (Manuel M T Chakravarty)
Date: Wed Sep 17 00:48:55 2008
Subject: [Haskell-cafe] GHC trouble on Leopard
In-Reply-To: 
References: 
Message-ID: <2D1EB554-4261-4C2F-85AE-9349055718B2@cse.unsw.edu.au>

Miguel,

> I tried to compile some code on Mac Os X (Intel) Leopard.
> I have GHC 6.8.3 installed - the installer from GHC webpage  
> (GHC-6.8.3-i386.pkg).
>
> But when I run make I get this error
>
> ghc-6.8.3: could not execute: /Library/Frameworks/GHC.framework/ 
> Versions/608/usr/lib/ghc-6.8.3/ghc-asm

This is not a common problem.  I suspect that either your installation  
somehow got corrupt or you somehow changed your Perl installation.   
(The file in question is a Perl script.)

Manuel
From weihu at cs.virginia.edu  Wed Sep 17 01:05:58 2008
From: weihu at cs.virginia.edu (Wei Hu)
Date: Wed Sep 17 01:03:39 2008
Subject: [Haskell-cafe] Predicativity?
Message-ID: 

Hello,

I only have a vague understanding of predicativity/impredicativity, but cannot 
map this concept to practice.

We know the type of id is forall a. a -> a. I thought id could not be applied 
to itself under predicative polymorphism. But Haksell and OCaml both type check 
(id id) with no problem. Is my understanding wrong? Can you show an example 
that doesn't type check under predicative polymorphism, but would type check 
under impredicative polymorphism?

Thanks!

From johan.tibell at gmail.com  Wed Sep 17 01:12:29 2008
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed Sep 17 01:09:58 2008
Subject: Hyena Status? Re: [Haskell-cafe] Starting Haskell with a web
	application
In-Reply-To: 
References: 
Message-ID: <90889fe70809162212j14cb5e1eh2eff0b3583125f6@mail.gmail.com>

On Tue, Sep 16, 2008 at 11:15 AM, Donnie Jones  wrote:
> Hello Johan Tibell,
>
> Hyena looks very interesting.  From the github tracking, you've been
> working...  Maybe a release soon?

I'm working towards it. I've been very busy at work lately but it's
getting there. I need to do some more optimization work. The holy
grail is 10k requests per second.

> Also, I saw your slides from the 'Left-fold enumerators' presentation at
> Galois.  Maybe include the slides in the docs/ for a release?

I make sure the project is documented in the best way I can come up with. :)
From dons at galois.com  Wed Sep 17 01:33:00 2008
From: dons at galois.com (Don Stewart)
Date: Wed Sep 17 01:30:25 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages? 
Message-ID: <20080917053300.GC2213@scytale.galois.com>


http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534

"cloud computing, transactional memory and future multicore processors"

Get writing that multicore, STM, web app code!

-- Don
From mad.one at gmail.com  Wed Sep 17 02:12:24 2008
From: mad.one at gmail.com (Austin Seipp)
Date: Wed Sep 17 02:11:03 2008
Subject: [Haskell-cafe] Mac OS X dylib woes
In-Reply-To: <20080916234928.GA19133@berkeley.edu>
References: <20080916234928.GA19133@berkeley.edu>
Message-ID: <1221631764-sup-180@existential.local>

I'm not getting this issue, but to fix it, given whatever you shell
you use with your terminal (Terminal.app, iTerm, etc) program, just
stick this into the rc file for it:

> export DYLD_LIBRARY_PATH=/opt/local/lib:$DYLD_LIBRARY_PATH

For example, in this case it would exist in my ~/.zshrc - it should
solve the problem for the most part.

Austin
From ryani.spam at gmail.com  Wed Sep 17 02:26:54 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Wed Sep 17 02:24:26 2008
Subject: [Haskell-cafe] Predicativity?
In-Reply-To: 
References: 
Message-ID: <2f9b2d30809162326s3d801399q44b1ad13ff3f6a88@mail.gmail.com>

Maybe this example is more enlightening?

> -- doesn't compile
> -- f x = x x

> -- does compile under GHC at least
> g :: (forall a. a -> a) -> (forall a. a -> a)
> g x = x x

> h = g id

(although I don't know if it really answers your question)

One big motivation for impredicativity, as I understand it, is typing
things that use runST properly:

-- runST :: (forall s. ST s a) -> a

-- ($) :: forall a b. (a -> b) -> a -> b
-- f $ x = f x

> z = runST $ return "hello"

How do you typecheck z?  From what I understand, it is quite difficult
without impredicativity.

  -- ryan

On Tue, Sep 16, 2008 at 10:05 PM, Wei Hu  wrote:
> Hello,
>
> I only have a vague understanding of predicativity/impredicativity, but cannot
> map this concept to practice.
>
> We know the type of id is forall a. a -> a. I thought id could not be applied
> to itself under predicative polymorphism. But Haksell and OCaml both type check
> (id id) with no problem. Is my understanding wrong? Can you show an example
> that doesn't type check under predicative polymorphism, but would type check
> under impredicative polymorphism?
>
> Thanks!
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From ryani.spam at gmail.com  Wed Sep 17 02:34:05 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Wed Sep 17 02:31:58 2008
Subject: [Haskell-cafe] Predicativity?
In-Reply-To: <2f9b2d30809162326s3d801399q44b1ad13ff3f6a88@mail.gmail.com>
References: 
	<2f9b2d30809162326s3d801399q44b1ad13ff3f6a88@mail.gmail.com>
Message-ID: <2f9b2d30809162334i2e226149pba052f4ac270d9b3@mail.gmail.com>

Here is another example that doesn't compile under current GHC directly:

> f = (runST .)

ghci reports the type of f as
   (a1 -> forall s. ST s a) -> a1 -> a

But (f return) doesn't typecheck, even though the type of return is

> return :: forall a s. a -> ST s a

Oddly, this does typecheck if we eta-expand return:

ghci> :t f (\x -> return x)
f (\x -> return x) :: forall a1. a1 -> a1

Perhaps the typechecker doesn't realize that since s is not free on
the lhs of the -> in return, that the two types are equivalent?

  -- ryan


On Tue, Sep 16, 2008 at 11:26 PM, Ryan Ingram  wrote:
> Maybe this example is more enlightening?
>
>> -- doesn't compile
>> -- f x = x x
>
>> -- does compile under GHC at least
>> g :: (forall a. a -> a) -> (forall a. a -> a)
>> g x = x x
>
>> h = g id
>
> (although I don't know if it really answers your question)
>
> One big motivation for impredicativity, as I understand it, is typing
> things that use runST properly:
>
> -- runST :: (forall s. ST s a) -> a
>
> -- ($) :: forall a b. (a -> b) -> a -> b
> -- f $ x = f x
>
>> z = runST $ return "hello"
>
> How do you typecheck z?  From what I understand, it is quite difficult
> without impredicativity.
>
>  -- ryan
>
> On Tue, Sep 16, 2008 at 10:05 PM, Wei Hu  wrote:
>> Hello,
>>
>> I only have a vague understanding of predicativity/impredicativity, but cannot
>> map this concept to practice.
>>
>> We know the type of id is forall a. a -> a. I thought id could not be applied
>> to itself under predicative polymorphism. But Haksell and OCaml both type check
>> (id id) with no problem. Is my understanding wrong? Can you show an example
>> that doesn't type check under predicative polymorphism, but would type check
>> under impredicative polymorphism?
>>
>> Thanks!
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
From judah.jacobson at gmail.com  Wed Sep 17 02:39:05 2008
From: judah.jacobson at gmail.com (Judah Jacobson)
Date: Wed Sep 17 02:37:23 2008
Subject: [Haskell-cafe] Mac OS X dylib woes
In-Reply-To: <20080916234928.GA19133@berkeley.edu>
References: <20080916234928.GA19133@berkeley.edu>
Message-ID: <6d74b0d20809162339r6af616bbl9dd56af5dfa15359@mail.gmail.com>

On Tue, Sep 16, 2008 at 4:49 PM, John MacFarlane  wrote:
> I'm hoping some Haskell developers who use Macs can help me with this
> one. I can install pcre-light just fine using cabal install. But when I
> try to use it, I get this error:
> [snip]
> OK, so it can't find the pcre library (which is in /opt/local/lib).
> I can fix that:
>
> export DYLD_LIBRARY_PATH=/opt/local/lib
>
> Now it works. But other things are broken! For example, I can't run vim,
> which looks for a library called libJPEG.dylib and now finds libjpeg.dylib
> in /opt/local/lib (case-insensitive file system!).
>

I can't reproduce this, although I'm running ghc-6.8.3.  It's possible
something wonky happened when you previously installed pcre-light.

If you type "ghc-pkg describe pcre-light", does it list
"/opt/local/lib" under the "library-dirs:" field?  If not, that's most
likely your problem.  Try unregistering the library and reinstalling
with:

cabal install pcre-light --extra-include-dirs=/opt/local/include
--extra-lib-dirs=/opt/local/lib

If that doesn't work, I think you can work around your problem with
libjpeg/libJPEG by setting

DYLD_FALLBACK_LIBRARY_PATH=$HOME/lib:/usr/local/lib:/lib:/usr/lib:/opt/local/lib

Which should cause the linker to favor system libraries over macports'
libraries.

Hope that helps,
-Judah
From tom.davie at gmail.com  Wed Sep 17 02:42:06 2008
From: tom.davie at gmail.com (Thomas Davie)
Date: Wed Sep 17 02:41:17 2008
Subject: [Haskell-cafe] Predicativity?
In-Reply-To: 
References: 
Message-ID: <564033F0-7E2F-4B3D-8E92-B8C563BFE8DB@gmail.com>


On 17 Sep 2008, at 07:05, Wei Hu wrote:

> Hello,
>
> I only have a vague understanding of predicativity/impredicativity,  
> but cannot
> map this concept to practice.
>
> We know the type of id is forall a. a -> a. I thought id could not  
> be applied
> to itself under predicative polymorphism. But Haksell and OCaml both  
> type check
> (id id) with no problem. Is my understanding wrong? Can you show an  
> example
> that doesn't type check under predicative polymorphism, but would  
> type check
> under impredicative polymorphism?

In your application (id id) you create two instances of id, each of  
which has type forall a. a -> a, and each of which can be applied to a  
different type.  In this case, the left one gets applied to the type  
(a -> a) and the right one a, giving them types (a -> a) -> (a -> a)  
and (a -> a) respectively.

What will not type check on the other hand is:

main = g id

g h = h h 4

which needs something along the lines of rank-2 polymorphism.

Bob
From 666wman at gmail.com  Wed Sep 17 02:44:50 2008
From: 666wman at gmail.com (wman)
Date: Wed Sep 17 02:42:18 2008
Subject: [Haskell-cafe] hircules resurrected (partially ;-)
Message-ID: 

I stumbled upon hircules-0.3 IRC client and decided to take it for a test
drive.

I managed to get it to compile under ghc-6.8.3/win32, converted it to use
Text.Codec.Iconv (the old version of included Iconv.hs should also work),
but it seems it doesn't work. It only gives an empty form and according to
wireshark doesn't even attempt a connection.

If somebody knew hircules in it's days of glory and/or wants to go
bug-hunting, i'll gladly provide the modified version, as I probably won't
spend more time on it in near future (at least until i get to know gtk2hs
better).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080917/88bb15f1/attachment.htm
From dav.vire+haskell at gmail.com  Wed Sep 17 06:25:48 2008
From: dav.vire+haskell at gmail.com (david48)
Date: Wed Sep 17 06:27:09 2008
Subject: [Haskell-cafe] Re: Problem with hscurses
In-Reply-To: <4c88418c0809160831p67b01045k78eac3c30ea6e780@mail.gmail.com>
References: <4c88418c0809160831p67b01045k78eac3c30ea6e780@mail.gmail.com>
Message-ID: <4c88418c0809170325n74ba9af8gd19807962a85c3be@mail.gmail.com>

On Tue, Sep 16, 2008 at 5:31 PM, david48  wrote:

> the getCh funtion is supposed to return an interpreted Key with values
> like KeyChar c, KeyReturn, KeyBackspace, etc.
> but in fact, it only ever returns KeyChar c values !

Nevermind, issue solved.
From lemming at henning-thielemann.de  Wed Sep 17 07:31:26 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed Sep 17 07:29:37 2008
Subject: [Haskell-cafe] readFile and closing a file
Message-ID: 


Say I acquire a text by readFile, feed it to a lazy parser and the parser 
stops reading because of a parse error. After the parser error I won't 
fetch more characters from the text file, but readFile does not get to 
know that and cannot close the file. Actually, when encountering a parser 
error I could read the remaining characters from the file in order to let 
readFile close the file eventually, but this sounds rather inefficient. 
So, what is the right way to go, or do I have to stay away from readFile 
(and maybe unsafeInterleaveIO at all)?
From lemming at henning-thielemann.de  Wed Sep 17 07:42:17 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed Sep 17 07:39:55 2008
Subject: [Haskell-cafe] Float instance of 'read'
In-Reply-To: 
References: 
Message-ID: 


On Tue, 16 Sep 2008, Mauricio wrote:

> Hi,
>
> A small annoyance some users outside
> english speaking countries usually
> experiment when learning programming
> languages is that real numbers use
> a '.' instead of ','. Of course, that
> is not such a problem except for the
> inconsistence between computer and
> free hand notation.

Read/Show is intended for parsing and formatting of Haskell expressions. 
Anything different should use different functions.
From marco-oweber at gmx.de  Wed Sep 17 08:04:36 2008
From: marco-oweber at gmx.de (Marc Weber)
Date: Wed Sep 17 08:03:05 2008
Subject: [Haskell-cafe] Real World HAppS: Cabalized, Self-Demoing HAppS
	Tutorial (Version 3)
In-Reply-To: <48D025D4.8020102@gmx.org>
References: <910ddf450809120807j6d1379b3uc8a23c8dc8720b55@mail.gmail.com>
	<48D025D4.8020102@gmx.org>
Message-ID: <20080917120436.GB25870@gmx.de>

On Tue, Sep 16, 2008 at 11:32:04PM +0200, Martin Huschenbett wrote:
>  Hi all,
> 
>  taking a look at this tutorial under Windows Vista I ran into a problem:

You should get the latest darcs version which contains the conditional
cabal flag:
  if !os(windows)
     Build-Depends:    unix
     cpp-options:      -DUNIX

Marc
From neil.mitchell.2 at credit-suisse.com  Wed Sep 17 08:06:25 2008
From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil)
Date: Wed Sep 17 08:04:13 2008
Subject: [Haskell-cafe] readFile and closing a file
In-Reply-To: 
References: 
Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3A06@ELON17P32001A.csfb.cs-group.com>

Hi Henning,

I tend to use openFile, hGetContents, hClose - your initial readFile
like call should be openFile/hGetContents, which gives you a lazy
stream, and on a parse error call hClose.

Thanks

Neil

> -----Original Message-----
> From: haskell-cafe-bounces@haskell.org 
> [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of 
> Henning Thielemann
> Sent: 17 September 2008 12:31 pm
> To: Haskell Cafe
> Subject: [Haskell-cafe] readFile and closing a file
> 
> 
> Say I acquire a text by readFile, feed it to a lazy parser 
> and the parser stops reading because of a parse error. After 
> the parser error I won't fetch more characters from the text 
> file, but readFile does not get to know that and cannot close 
> the file. Actually, when encountering a parser error I could 
> read the remaining characters from the file in order to let 
> readFile close the file eventually, but this sounds rather 
> inefficient. 
> So, what is the right way to go, or do I have to stay away 
> from readFile (and maybe unsafeInterleaveIO at all)?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

From donnie at darthik.com  Wed Sep 17 08:15:50 2008
From: donnie at darthik.com (Donnie Jones)
Date: Wed Sep 17 08:14:00 2008
Subject: Hyena Status? Re: [Haskell-cafe] Starting Haskell with a web
	application
In-Reply-To: <90889fe70809162212j14cb5e1eh2eff0b3583125f6@mail.gmail.com>
References: 
	<90889fe70809162212j14cb5e1eh2eff0b3583125f6@mail.gmail.com>
Message-ID: 

Hello Johan,

On Wed, Sep 17, 2008 at 1:12 AM, Johan Tibell wrote:

> On Tue, Sep 16, 2008 at 11:15 AM, Donnie Jones  wrote:
> > Hello Johan Tibell,
> >
> > Hyena looks very interesting.  From the github tracking, you've been
> > working...  Maybe a release soon?
>
> I'm working towards it. I've been very busy at work lately but it's
> getting there. I need to do some more optimization work. The holy
> grail is 10k requests per second.
>

Excellent!


>
> > Also, I saw your slides from the 'Left-fold enumerators' presentation at
> > Galois.  Maybe include the slides in the docs/ for a release?
>
> I make sure the project is documented in the best way I can come up with.
> :)
>

Yes, I saw your code is commented extensively.
I wish I had time to contribute... maybe after this semester.  ;)

Thanks!
__
Donnie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080917/d711e7fe/attachment.htm
From manlio_perillo at libero.it  Wed Sep 17 08:17:30 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 08:14:59 2008
Subject: [Haskell-cafe] about openTempFile
Message-ID: <48D0F55A.8000801@libero.it>

Hi.

After reading the chapter about IO in the "Real Word Haskell" book, I 
have noted that there is no support for opening a temporary file that 
will be automatically removed at program termination.

The Python tempfile module, as an example, implements a wrapper around 
mkstemp function that does exactly this, and the code is portable; on 
Windows it uses O_TEMPORARY_FILE flag, on POSIX systems the file is 
unlink-ed as soon as it is created (but note that the code is not signal 
safe - well, many functions in the Python standard library are not 
signal safe).

There are reasons why GHC library does not implement this?


The Python version also set the FD_CLOEXEC, O_NOINHERIT and O_NOFOLLOW 
flags (where available).
The GHC version, instead, set the O_NOCTTY flag.



Manlio Perillo
From jmvilaca at di.uminho.pt  Wed Sep 17 08:36:55 2008
From: jmvilaca at di.uminho.pt (Miguel Vilaca)
Date: Wed Sep 17 08:38:44 2008
Subject: [Haskell-cafe] Re: GHC trouble on Leopard
In-Reply-To: <2D1EB554-4261-4C2F-85AE-9349055718B2@cse.unsw.edu.au>
References: 
	<2D1EB554-4261-4C2F-85AE-9349055718B2@cse.unsw.edu.au>
Message-ID: <0618646C-7E52-4C10-9EAB-B5A7143DF44F@di.uminho.pt>

Hi Manuel,

After your tip, I check the file, it permissions and it content, and  
find that this specific file looks for perl in an existing place; this  
is a fresh Leopard and I just installed a few things using binaries.

It seems GHC expects perl to be installed through macPorts or Fink and  
i have neither of them.

Just changing the first line of the file
/Library/Frameworks/GHC.framework/Versions/608/usr/lib/ghc-6.8.3/ghc-asm
from
#!/opt/local/bin/perl
to
#!/usr/bin/perl
solves the problem.

Thanks for the help.

Miguel Vila?a

Em 2008/09/17, ?s 05:51, Manuel M T Chakravarty escreveu:

> Miguel,
>
>> I tried to compile some code on Mac Os X (Intel) Leopard.
>> I have GHC 6.8.3 installed - the installer from GHC webpage  
>> (GHC-6.8.3-i386.pkg).
>>
>> But when I run make I get this error
>>
>> ghc-6.8.3: could not execute: /Library/Frameworks/GHC.framework/ 
>> Versions/608/usr/lib/ghc-6.8.3/ghc-asm
>
> This is not a common problem.  I suspect that either your  
> installation somehow got corrupt or you somehow changed your Perl  
> installation.  (The file in question is a Perl script.)
>
> Manuel

From lionel at gamr7.com  Wed Sep 17 08:47:53 2008
From: lionel at gamr7.com (Lionel Barret De Nazaris)
Date: Wed Sep 17 08:39:35 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <20080917053300.GC2213@scytale.galois.com>
References: <20080917053300.GC2213@scytale.galois.com>
Message-ID: <48D0FC79.1050506@gamr7.com>

Amen,
Those are the hard question that the python community needs to answer (I 
am not sure they want to answer, tho).
They are also part of the reasons we are switching to Haskell.

L.


Don Stewart wrote:
> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
>
> "cloud computing, transactional memory and future multicore processors"
>
> Get writing that multicore, STM, web app code!
>
> -- Don
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>   

-- 
Best Regards,
lionel Barret de Nazaris,
Gamr7 Founder & CTO
=========================
Gamr7 : Cities for Games
http://www.gamr7.com




From manlio_perillo at libero.it  Wed Sep 17 08:58:29 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 08:57:05 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <20080917053300.GC2213@scytale.galois.com>
References: <20080917053300.GC2213@scytale.galois.com>
Message-ID: <48D0FEF5.5080707@libero.it>

Don Stewart ha scritto:
> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
> 
> "cloud computing, transactional memory and future multicore processors"
> 

Multicore support is already "supported" in Python, if you use 
multiprocessing, instead of multithreading.

And scalability is not a "real" problem, if you write RESTful web 
applications.

> Get writing that multicore, STM, web app code!
> 


Manlio Perillo
From bruceteckel at gmail.com  Wed Sep 17 09:03:51 2008
From: bruceteckel at gmail.com (Bruce Eckel)
Date: Wed Sep 17 09:01:21 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <48D0FEF5.5080707@libero.it>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
Message-ID: <14e7a2380809170603j7f1c57f6vcdda2f44e8827930@mail.gmail.com>

> Multicore support is already "supported" in Python, if you use
> multiprocessing, instead of multithreading.

This is one of the reasons for my other question on this list, about
whether you can solve all problems using multiple isolated processes
with message passing.


-- 
Bruce Eckel
From arnarbi at gmail.com  Wed Sep 17 09:09:44 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Wed Sep 17 09:07:24 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <48D0FEF5.5080707@libero.it>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
Message-ID: <28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>

Hi Manlio and others,

On Wed, Sep 17, 2008 at 14:58, Manlio Perillo  wrote:
>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
>>
>> "cloud computing, transactional memory and future multicore processors"
>>
>
> Multicore support is already "supported" in Python, if you use
> multiprocessing, instead of multithreading.

Well, I'm a huge Python fan myself, but multiprocessing is not really
a solution as much as it is a workaround. Python as a language has no
problem with multithreading and multicore support and has all
primitives to do conventional shared-state parallelism. However, the
most popular /implementation/ of Python sacrifies this for
performance, it has nothing to do with the language itself.

Stackless Python is an interesting implementation of the CSP+channels
paradigm though. It has been quite successfully used for a few large
projects.

> And scalability is not a "real" problem, if you write RESTful web
> applications.

Of course scalability is a "real" problem, ask anyone who runs a big
website. I don't see how RESTful design simply removes that problem.

cheers,
Arnar
From dougal at dougalstanton.net  Wed Sep 17 09:10:56 2008
From: dougal at dougalstanton.net (Dougal Stanton)
Date: Wed Sep 17 09:08:25 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <48D0F55A.8000801@libero.it>
References: <48D0F55A.8000801@libero.it>
Message-ID: <2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>

On Wed, Sep 17, 2008 at 1:17 PM, Manlio Perillo
 wrote:
> The Python tempfile module, as an example, implements a wrapper around
> mkstemp function that does exactly this, and the code is portable; on
> Windows it uses O_TEMPORARY_FILE flag, on POSIX systems the file is
> unlink-ed as soon as it is created (but note that the code is not signal
> safe - well, many functions in the Python standard library are not signal
> safe).

Something like:

> withTempFile :: String -> ((FilePath, Handle) -> IO b) -> IO b
> withTempFile name action = do
>     tmpdir <- getTemporaryDirectory
>     bracket
>         (openTempFile tmpdir name)
>         (\(fp,h) -> hClose h >> removeFile fp)
>         action

I don't know if this has the safety requirements you mean?


-- 
Dougal Stanton
dougal@dougalstanton.net // http://www.dougalstanton.net
From jefferson.r.heard at gmail.com  Wed Sep 17 09:12:43 2008
From: jefferson.r.heard at gmail.com (Jefferson Heard)
Date: Wed Sep 17 09:10:14 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <48D0FEF5.5080707@libero.it>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
Message-ID: <4165d3a70809170612u68159c8aj7d317cbb0a0ecb01@mail.gmail.com>

Multiprocessing is hardly a solution...  I realize the Python
interpreter's fairly lightweight on its own, but the weight of a full
unix process plus the weight of the python interpreter in terms of
memory, context switching times, and finally the clunkiness of the
fork() model (which is HOW many years old now?).  They need a model
programmers are familiar with, e.g. threads-allocate-to-cores a la
Java or C, or they need a model that is entirely new or is based on
source-code annotation (like Strategies and Control.Parallel).



On Wed, Sep 17, 2008 at 8:58 AM, Manlio Perillo
 wrote:
> Don Stewart ha scritto:
>>
>>
>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
>>
>> "cloud computing, transactional memory and future multicore processors"
>>
>
> Multicore support is already "supported" in Python, if you use
> multiprocessing, instead of multithreading.
>
> And scalability is not a "real" problem, if you write RESTful web
> applications.
>
>> Get writing that multicore, STM, web app code!
>>
>
>
> Manlio Perillo
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards
From arnarbi at gmail.com  Wed Sep 17 09:13:34 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Wed Sep 17 09:11:08 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <14e7a2380809170603j7f1c57f6vcdda2f44e8827930@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<14e7a2380809170603j7f1c57f6vcdda2f44e8827930@mail.gmail.com>
Message-ID: <28012bc60809170613w1f0db62dj10be1d2dbb2545dd@mail.gmail.com>

Hi Bruce,

On Wed, Sep 17, 2008 at 15:03, Bruce Eckel  wrote:
>> Multicore support is already "supported" in Python, if you use
>> multiprocessing, instead of multithreading.
>
> This is one of the reasons for my other question on this list, about
> whether you can solve all problems using multiple isolated processes
> with message passing.

Well, processing (the Python module) serves as a good example how
shared memory can be emulated through message passing. Of course,
performance takes a hit but since it is out there and being used by
people it should tell us that is really af feasible solution.

I guess the gist of the answers people posted to your question still
remains, the answer depends on if you consider performance as part of
the "power" of each approach.

Arnar
From bruceteckel at gmail.com  Wed Sep 17 09:13:49 2008
From: bruceteckel at gmail.com (Bruce Eckel)
Date: Wed Sep 17 09:11:27 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
Message-ID: <14e7a2380809170613y3ce5793ew3a5a93a74ef077ca@mail.gmail.com>

> Well, I'm a huge Python fan myself, but multiprocessing is not really
> a solution as much as it is a workaround. Python as a language has no
> problem with multithreading and multicore support and has all
> primitives to do conventional shared-state parallelism. However, the
> most popular /implementation/ of Python sacrifies this for
> performance, it has nothing to do with the language itself.

Actually, no. Neither Python nor Ruby can utilize more than a single
processor using threads. The only way to use more than one processor
is with processes.

-- 
Bruce Eckel
From arnarbi at gmail.com  Wed Sep 17 09:18:00 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Wed Sep 17 09:15:33 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <14e7a2380809170613y3ce5793ew3a5a93a74ef077ca@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	<14e7a2380809170613y3ce5793ew3a5a93a74ef077ca@mail.gmail.com>
Message-ID: <28012bc60809170618g2333b24ds5f5a15c3bc08d56c@mail.gmail.com>

Hi again,

On Wed, Sep 17, 2008 at 15:13, Bruce Eckel  wrote:
>> Well, I'm a huge Python fan myself, but multiprocessing is not really
>> a solution as much as it is a workaround. Python as a language has no
>> problem with multithreading and multicore support and has all
>> primitives to do conventional shared-state parallelism. However, the
>> most popular /implementation/ of Python sacrifies this for
>> performance, it has nothing to do with the language itself.
>
> Actually, no. Neither Python nor Ruby can utilize more than a single
> processor using threads. The only way to use more than one processor
> is with processes.

I wanted to make a distinction between the language and its
implementation. I think you are conflating the two.

If you read the Python specification there is nothing preventing you
from running on two cores in parallel. The standard library does
indeed have semaphores, monitors, locks etc. In fact, I'm pretty sure
the Jython implementation can use multiple cores. It is just CPython
that can't, as is very well known and advertised.

cheers,
Arnar
From droundy at darcs.net  Wed Sep 17 09:21:18 2008
From: droundy at darcs.net (David Roundy)
Date: Wed Sep 17 09:18:43 2008
Subject: [Haskell-cafe] readFile and closing a file
In-Reply-To: 
References: 
Message-ID: <20080917132117.GB19238@darcs.net>

On Wed, Sep 17, 2008 at 01:31:26PM +0200, Henning Thielemann wrote:
> Say I acquire a text by readFile, feed it to a lazy parser and the parser 
> stops reading because of a parse error. After the parser error I won't  
> fetch more characters from the text file, but readFile does not get to  
> know that and cannot close the file. Actually, when encountering a parser 
> error I could read the remaining characters from the file in order to let 
> readFile close the file eventually, but this sounds rather inefficient.  
> So, what is the right way to go, or do I have to stay away from readFile  
> (and maybe unsafeInterleaveIO at all)?

Eventually the garbage collector should close the file, I believe.

David
From manlio_perillo at libero.it  Wed Sep 17 09:22:54 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 09:20:43 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>	
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
Message-ID: <48D104AE.5010501@libero.it>

Arnar Birgisson ha scritto:
> Hi Manlio and others,
> 
> On Wed, Sep 17, 2008 at 14:58, Manlio Perillo  wrote:
>>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
>>>
>>> "cloud computing, transactional memory and future multicore processors"
>>>
>> Multicore support is already "supported" in Python, if you use
>> multiprocessing, instead of multithreading.
> 
> Well, I'm a huge Python fan myself, but multiprocessing is not really
> a solution as much as it is a workaround. 

The real workaround is probably (and IMHO) multithreading (at least 
preemptive).

> Python as a language has no
> problem with multithreading and multicore support and has all
> primitives to do conventional shared-state parallelism. However, the
> most popular /implementation/ of Python sacrifies this for
> performance, it has nothing to do with the language itself.
> 
> Stackless Python is an interesting implementation of the CSP+channels
> paradigm though. It has been quite successfully used for a few large
> projects.
> 

There is also greenlets for cooperative multithreading (but without the 
scheduler and channels, so you can integrate it in your event loop like 
Twisted).

>> And scalability is not a "real" problem, if you write RESTful web
>> applications.
> 
> Of course scalability is a "real" problem, ask anyone who runs a big
> website. I don't see how RESTful design simply removes that problem.
> 

If you use asynchronous programming and multiprocessing, you *do* solve 
most of the problems.

This is what I do in the wsgi module for Nginx.

> cheers,
> Arnar
> 


Manlio Perillo
From jefferson.r.heard at gmail.com  Wed Sep 17 09:23:24 2008
From: jefferson.r.heard at gmail.com (Jefferson Heard)
Date: Wed Sep 17 09:20:56 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <28012bc60809170618g2333b24ds5f5a15c3bc08d56c@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	<14e7a2380809170613y3ce5793ew3a5a93a74ef077ca@mail.gmail.com>
	<28012bc60809170618g2333b24ds5f5a15c3bc08d56c@mail.gmail.com>
Message-ID: <4165d3a70809170623o6ffe554dn374408354aa574ad@mail.gmail.com>

Both Jython and JRuby can use multicore parallelism.  Which, of
course, you need desperately when running in Jython and JRuby, because
they're slow as christmas for most tasks.  In addition, Jython is not
a predictably complete version of Python and its internals are not
well documented in the least, and the documentation for what CPython
code will work in Jython and what won't is sadly lacking.

In my experience, it doesn't make it an unusable tool, but the tasks
it is suited for fall more along the lines of traditional scripting of
a large working Java application.  I wouldn't want to see a large app
written in Jython or JRuby.

-- Jeff

On Wed, Sep 17, 2008 at 9:18 AM, Arnar Birgisson  wrote:
> Hi again,
>
> On Wed, Sep 17, 2008 at 15:13, Bruce Eckel  wrote:
>>> Well, I'm a huge Python fan myself, but multiprocessing is not really
>>> a solution as much as it is a workaround. Python as a language has no
>>> problem with multithreading and multicore support and has all
>>> primitives to do conventional shared-state parallelism. However, the
>>> most popular /implementation/ of Python sacrifies this for
>>> performance, it has nothing to do with the language itself.
>>
>> Actually, no. Neither Python nor Ruby can utilize more than a single
>> processor using threads. The only way to use more than one processor
>> is with processes.
>
> I wanted to make a distinction between the language and its
> implementation. I think you are conflating the two.
>
> If you read the Python specification there is nothing preventing you
> from running on two cores in parallel. The standard library does
> indeed have semaphores, monitors, locks etc. In fact, I'm pretty sure
> the Jython implementation can use multiple cores. It is just CPython
> that can't, as is very well known and advertised.
>
> cheers,
> Arnar
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards
From droundy at darcs.net  Wed Sep 17 09:23:47 2008
From: droundy at darcs.net (David Roundy)
Date: Wed Sep 17 09:21:17 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
References: <48D0F55A.8000801@libero.it>
	<2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
Message-ID: <20080917132346.GC19238@darcs.net>

On Wed, Sep 17, 2008 at 02:10:56PM +0100, Dougal Stanton wrote:
> On Wed, Sep 17, 2008 at 1:17 PM, Manlio Perillo
>  wrote:
> > The Python tempfile module, as an example, implements a wrapper around
> > mkstemp function that does exactly this, and the code is portable; on
> > Windows it uses O_TEMPORARY_FILE flag, on POSIX systems the file is
> > unlink-ed as soon as it is created (but note that the code is not signal
> > safe - well, many functions in the Python standard library are not signal
> > safe).
> 
> Something like:
> 
> > withTempFile :: String -> ((FilePath, Handle) -> IO b) -> IO b
> > withTempFile name action = do
> >     tmpdir <- getTemporaryDirectory
> >     bracket
> >         (openTempFile tmpdir name)
> >         (\(fp,h) -> hClose h >> removeFile fp)
> >         action
> 
> I don't know if this has the safety requirements you mean?

You need to be sure to use the bracket from Control.Exception, not the
one from System.IO or IO (which won't work).  And you also need
special work to make the code safe from signals.  But basically, this
is the right idea.

David
From manlio_perillo at libero.it  Wed Sep 17 09:29:32 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 09:27:03 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <4165d3a70809170612u68159c8aj7d317cbb0a0ecb01@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>	
	<48D0FEF5.5080707@libero.it>
	<4165d3a70809170612u68159c8aj7d317cbb0a0ecb01@mail.gmail.com>
Message-ID: <48D1063C.7060401@libero.it>

Jefferson Heard ha scritto:
> Multiprocessing is hardly a solution...  I realize the Python
> interpreter's fairly lightweight on its own, but the weight of a full
> unix process plus the weight of the python interpreter in terms of
> memory, 

With copy on write some memory can be saved (if you preload all the 
required modules in the master process).

> context switching times, 

That's probabily the same as thread switching time.
And if you use asynchronous programming in each of the worker processes, 
you can keep the number of required processes at a minimum.

> and finally the clunkiness of the
> fork() model (which is HOW many years old now?).  

Old does not means bad, IMHO.

 > [...]


Manlio Perillo
From manlio_perillo at libero.it  Wed Sep 17 09:42:12 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 09:39:39 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
References: <48D0F55A.8000801@libero.it>
	<2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
Message-ID: <48D10934.20801@libero.it>

Dougal Stanton ha scritto:
> On Wed, Sep 17, 2008 at 1:17 PM, Manlio Perillo
>  wrote:
>> The Python tempfile module, as an example, implements a wrapper around
>> mkstemp function that does exactly this, and the code is portable; on
>> Windows it uses O_TEMPORARY_FILE flag, on POSIX systems the file is
>> unlink-ed as soon as it is created (but note that the code is not signal
>> safe - well, many functions in the Python standard library are not signal
>> safe).
> 
> Something like:
> 
>> withTempFile :: String -> ((FilePath, Handle) -> IO b) -> IO b
>> withTempFile name action = do
>>     tmpdir <- getTemporaryDirectory
>>     bracket
>>         (openTempFile tmpdir name)
>>         (\(fp,h) -> hClose h >> removeFile fp)
>>         action
> 
> I don't know if this has the safety requirements you mean?
> 

Yes, this is the ideal solution for Haskell.

But since GHC does not implement such a function, I was curious to know 
why it don't even implement a function that make sure the temporary file 
is removed.

> 


Thanks  Manlio Perillo
From briqueabraque at yahoo.com  Wed Sep 17 10:24:39 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 10:22:25 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <48D012A1.7040708@gmail.com>
References:  <48D012A1.7040708@gmail.com>
Message-ID: 

No, it is not. Strings created by show are
always supposed to be readable by read, no
matter which system used 'show' and which
system is using 'read'.

Maur?cio

Rafael C. de Almeida a ?crit :
> Mauricio wrote:
>> Hi,
>>
>> A small annoyance some users outside
>> english speaking countries usually
>> experiment when learning programming
>> languages is that real numbers use
>> a '.' instead of ','. Of course, that
>> is not such a problem except for the
>> inconsistence between computer and
>> free hand notation.
>>
>> Do you think 'read' (actually,
>> 'readsPrec'?) could be made to also
>> read the international convention
>> (ie., read "1,5" would also work
>> besides read "1.5")? I'm happy to
>> finaly use a language where I can
>> use words of my language to name
>> variables, so I wonder if we could
>> also make that step.
>>
> 
> Isn't it locale dependent? If it isn't, it should be. Try setting your
> locale right and see if things work. At least awk work fine that way.
> 
> Although I don't like too much that kinda stuff, I usually set the
> locale to C so I keep all my programs behaving consistently. I have
> problems with that stuff before (a file generated by an awk script had ,
> instead of . and that would confuse other computers with a different
> locale).

From jwlato at gmail.com  Wed Sep 17 10:28:35 2008
From: jwlato at gmail.com (John Lato)
Date: Wed Sep 17 10:26:01 2008
Subject: [Haskell-cafe] FRP (was: Semantic Domain, Function,
	and denotational model)
Message-ID: <9979e72e0809170728waab3519xaa53a8a3599bed96@mail.gmail.com>

I just noticed that the "Simply Efficient Functional Reactivity" paper
has been updated since I last looked; I'll have to read it again now.

Is the library/code mentioned in the paper released or available
anywhere at this time?  Conal has left tantalizing hints scattered in
various places...

Thanks,
John Lato
From bruceteckel at gmail.com  Wed Sep 17 10:30:27 2008
From: bruceteckel at gmail.com (Bruce Eckel)
Date: Wed Sep 17 10:27:58 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <4165d3a70809170623o6ffe554dn374408354aa574ad@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	<14e7a2380809170613y3ce5793ew3a5a93a74ef077ca@mail.gmail.com>
	<28012bc60809170618g2333b24ds5f5a15c3bc08d56c@mail.gmail.com>
	<4165d3a70809170623o6ffe554dn374408354aa574ad@mail.gmail.com>
Message-ID: <14e7a2380809170730y7815084fj7272a0e010241b32@mail.gmail.com>

Jython 2.5 is very close to release and its goal is to be a very
complete implementation, including such improbable things as ctypes.

You can indeed use the underlying threads of the JVM with Jython and
JRuby, but the native Python threads are prevented from running on
more than one processor by the GIL.

On Wed, Sep 17, 2008 at 10:23 AM, Jefferson Heard
 wrote:
> Both Jython and JRuby can use multicore parallelism.  Which, of
> course, you need desperately when running in Jython and JRuby, because
> they're slow as christmas for most tasks.  In addition, Jython is not
> a predictably complete version of Python and its internals are not
> well documented in the least, and the documentation for what CPython
> code will work in Jython and what won't is sadly lacking.
>
> In my experience, it doesn't make it an unusable tool, but the tasks
> it is suited for fall more along the lines of traditional scripting of
> a large working Java application.  I wouldn't want to see a large app
> written in Jython or JRuby.
>
> -- Jeff
>
> On Wed, Sep 17, 2008 at 9:18 AM, Arnar Birgisson  wrote:
>> Hi again,
>>
>> On Wed, Sep 17, 2008 at 15:13, Bruce Eckel  wrote:
>>>> Well, I'm a huge Python fan myself, but multiprocessing is not really
>>>> a solution as much as it is a workaround. Python as a language has no
>>>> problem with multithreading and multicore support and has all
>>>> primitives to do conventional shared-state parallelism. However, the
>>>> most popular /implementation/ of Python sacrifies this for
>>>> performance, it has nothing to do with the language itself.
>>>
>>> Actually, no. Neither Python nor Ruby can utilize more than a single
>>> processor using threads. The only way to use more than one processor
>>> is with processes.
>>
>> I wanted to make a distinction between the language and its
>> implementation. I think you are conflating the two.
>>
>> If you read the Python specification there is nothing preventing you
>> from running on two cores in parallel. The standard library does
>> indeed have semaphores, monitors, locks etc. In fact, I'm pretty sure
>> the Jython implementation can use multiple cores. It is just CPython
>> that can't, as is very well known and advertised.
>>
>> cheers,
>> Arnar
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> I try to take things like a crow; war and chaos don't always ruin a
> picnic, they just mean you have to be careful what you swallow.
>
> -- Jessica Edwards
>



-- 
Bruce Eckel
From briqueabraque at yahoo.com  Wed Sep 17 10:34:36 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 10:32:13 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <1221596371.7852.7.camel@tilo-laptop>
References:  <1221596371.7852.7.camel@tilo-laptop>
Message-ID: 

Maybe. Doubles 'show' function always print something
after the decimal separator, so 'show [doubles]' is
easy to parse but difficult for human reading. It
would be nice to have a space between elements of a
shown list, though. It's an annoyance, but
internationalization is really great, I think it
deserves the effort.

Best,
Maur?cio

Tilo Wiklund a ?crit :
> Wouldn't that make it hard to parse lists of floats?
> 
> On Tue, 2008-09-16 at 09:29 -0300, Mauricio wrote:
>> Hi,
>>
>> A small annoyance some users outside
>> english speaking countries usually
>> experiment when learning programming
>> languages is that real numbers use
>> a '.' instead of ','. Of course, that
>> is not such a problem except for the
>> inconsistence between computer and
>> free hand notation.
>>
>> Do you think 'read' (actually,
>> 'readsPrec'?) could be made to also
>> read the international convention
>> (ie., read "1,5" would also work
>> besides read "1.5")? I'm happy to
>> finaly use a language where I can
>> use words of my language to name
>> variables, so I wonder if we could
>> also make that step.
>>
>> Thanks,
>> Maur?cio
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

From briqueabraque at yahoo.com  Wed Sep 17 10:43:04 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 10:40:41 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <3DBC4412-7C83-4615-805F-1BB4F161A8A7@yandex.ru>
References: 
	<3DBC4412-7C83-4615-805F-1BB4F161A8A7@yandex.ru>
Message-ID: 

>> I'm happy to
>> finaly use a language where I can
>> use words of my language to name
>> variables, so I wonder if we could
>> also make that step.
> 
> Really?
> 
> There is a bunch of languages (like "Glagol") that use words of Russian 
> language as keywords; AFAIK there aren't any Russian programmer who uses 
> them. I've always felt sorry for English-speaking programmers: they HAVE 
> to use the same words as keywords and as usual talking words at the same 
> time.

Here I totally aggree with you. It's great
that I can use words in my language for
variables, but the same would be really
annoying if the same was true for keywords.

Best,
Maur?cio

From greenrd at greenrd.org  Wed Sep 17 11:45:05 2008
From: greenrd at greenrd.org (Robin Green)
Date: Wed Sep 17 10:42:46 2008
Subject: [Haskell-cafe] FRP (was: Semantic Domain, Function, and
	denotational model)
In-Reply-To: <9979e72e0809170728waab3519xaa53a8a3599bed96@mail.gmail.com>
References: <9979e72e0809170728waab3519xaa53a8a3599bed96@mail.gmail.com>
Message-ID: <20080917164505.1d757153@greenrd.org>

On Wed, 17 Sep 2008 15:28:35 +0100
"John Lato"  wrote:

> I just noticed that the "Simply Efficient Functional Reactivity" paper
> has been updated since I last looked; I'll have to read it again now.
> 
> Is the library/code mentioned in the paper released or available
> anywhere at this time?  Conal has left tantalizing hints scattered in
> various places...

To get the latest code, which might not correspond to the code in the
paper:

darcs get http://code.haskell.org/reactive/

-- 
Robin
From patperry at stanford.edu  Wed Sep 17 10:50:40 2008
From: patperry at stanford.edu (Patrick O'Regan Perry)
Date: Wed Sep 17 10:48:07 2008
Subject: [Haskell-cafe] Re: haskell blas bindings: does iomatrix gemv
 transposing of matrix a?
In-Reply-To: <563348269.727211221663038691.JavaMail.root@zm01.stanford.edu>
Message-ID: <344831234.727231221663040995.JavaMail.root@zm01.stanford.edu>

Hi Anatoly,

I made the decision to make "herm" an O(1) operation.  This means you don't have to pass transpose arguments to the multiplication routines.  When you do, for example:

> let a = listMatrix (2,3) [1..6]
>     x = listVector 2 [1, -1]
> in herm a <*> x

this gets implemented as a call to gemv with transa set to "ConjTrans".

BLAS actually supports "NoTrans", "Trans", and "ConjTrans".  For real data types, "Trans" is the same as "ConjTrans".  For complex data types, they are different.  Unfortunately, it is impossible to call a routine with "Trans" in the blas bindings.  I explicitly did not want people to have to pass extra parameters to indicate transpose/conjugacy information, and I wanted "conjugate transpose" to be an O(1) operation.  Ideally, "transpose" would be O(1), as well.  However, since BLAS doesn't have an option to conjugate the input matrix but not transpose it, only one of "herm" and "trans" can be O(1).

I think in hmatrix, "trans" is O(1), but not "herm".


Patrick

p.s. I've been busy with other work lately, and I probably won't make a release soon, but I did a pretty big overhaul of the library to support operations in the ST monad.  For impure operations, the functions of all the operations are mostly the same, but the types are all different.  (For pure operations, there are only minor changes.)  If you want the development version, you can get the darcs repo at http://stat.stanford.edu/~patperry/code/blas .  

The new version is pretty typeclass-heavy, since that's the only way I know how to support both ST and IO.  Consequently, there have been some performance regressions.  I have some optimization ideas (in the "TODO") file, but I do not have time to implement them right now.  If you or anyone else would like to help with this or anything else, I would be glad to have you aboard the development "team".



----- Original Message -----
From: "Anatoly Yakovenko" 
To: patperry@stanford.edu
Cc: "haskell" 
Sent: Tuesday, September 16, 2008 8:46:02 PM GMT -05:00 US/Canada Eastern
Subject: haskell blas bindings: does iomatrix gemv transposing of matrix a?

Hey Patric,

Thanks for your great work on the blas bidnings.  I have a question on
gemv.  I thought its possible for blas to transpose the input matrix
before doing the multiplication.  Is it possible to do that with the
haskell bindings?  Or am I mistaken in how gemv is used

Thanks,
Anatoly
From briqueabraque at yahoo.com  Wed Sep 17 10:52:14 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 10:49:54 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <48D016EE.4060605@gmail.com>
References:  <48D016EE.4060605@gmail.com>
Message-ID: 

>> Do you think 'read' (actually,
>> 'readsPrec'?) could be made to also
>> read the international convention
>> (ie., read "1,5" would also work
>> besides read "1.5")? I'm happy to
>> finaly use a language where I can
>> use words of my language to name
>> variables, so I wonder if we could
>> also make that step.
> 
> That would be quite problematic in combination with lists, is
> 
>   read "[1,2,3,4]" == [1,2,3,4]
> 
> or
> 
>   read "[1,2,3,4]" == [1.2, 3.4]
> 
> Or something else?

As of today, at least in ghc, show ([1,2,3]::[Double])
will always produce "[1.0,2.0,3.0]". Since the requirement
for read is to read what is produced by show, that
would not be a problem.

> 
> 
> Localized reading should be somewhere else, perhaps related to Locales.

No! If we had that, string from a program would not
be readable by some program running in other machine,
or other locale. As, actually, you describe below.
Show and Read are for programs reading, not for
user reading. That's a work for Pango :)

> 
> As an aside, this is one of the (many) places where Haskell has made the 
> right choice. In other languages such as Java input functions suddenly 
> break when the user has a different locale setting. While for user input 
> this might be desired, in my experience much of the i/o a program does 
> is with well defined file formats where changing '.' to ',' just 
> shouldn't happen.

Best,
Maur?cio

From briqueabraque at yahoo.com  Wed Sep 17 10:54:12 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 10:52:30 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <625b74080809161345y6b3cb518hbc3f9221109bc188@mail.gmail.com>
References: 
	<625b74080809161345y6b3cb518hbc3f9221109bc188@mail.gmail.com>
Message-ID: 

As of today, show ((1,2)::(Float,Float))
would not produce that kind of output.

Dan Piponi a ?crit :
> Mauricio asked:
> 
>> Do you think 'read' (actually,
>> 'readsPrec'?) could be made to also
>> read the international convention
>> (ie., read "1,5" would also work
>> besides read "1.5")?
> 
> What would you hope the value of
> 
>> read "(1,2,3)"::(Float,Float)
> 
> would be?
> --
> Dan

From conal at conal.net  Wed Sep 17 11:05:57 2008
From: conal at conal.net (Conal Elliott)
Date: Wed Sep 17 11:03:26 2008
Subject: [Haskell-cafe] FRP (was: Semantic Domain, Function,
	and denotational model)
In-Reply-To: <20080917164505.1d757153@greenrd.org>
References: <9979e72e0809170728waab3519xaa53a8a3599bed96@mail.gmail.com>
	<20080917164505.1d757153@greenrd.org>
Message-ID: 

Hi John,

We're working toward a library release.  This summer has been more chaotic
for me than I expected.  Meanwhile the current is as Robin mentioned below.
Not in a terribly usable form.  You'll need ghc-6.9 for the vector-space
dependency (vector spaces, linear maps, and derivatives), since associated
types work much better in 6.9 than before.

  - Conal

On Wed, Sep 17, 2008 at 5:45 PM, Robin Green  wrote:

> On Wed, 17 Sep 2008 15:28:35 +0100
> "John Lato"  wrote:
>
> > I just noticed that the "Simply Efficient Functional Reactivity" paper
> > has been updated since I last looked; I'll have to read it again now.
> >
> > Is the library/code mentioned in the paper released or available
> > anywhere at this time?  Conal has left tantalizing hints scattered in
> > various places...
>
> To get the latest code, which might not correspond to the code in the
> paper:
>
> darcs get http://code.haskell.org/reactive/
>
> --
> Robin
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080917/6ebfc728/attachment.htm
From briqueabraque at yahoo.com  Wed Sep 17 11:20:04 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 11:17:42 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <48D0275A.703@jellybean.co.uk>
References:  <48D0275A.703@jellybean.co.uk>
Message-ID: 

>> Do you think 'read' (actually,
>> 'readsPrec'?) could be made to also
>> read the international convention
>> (ie., read "1,5" would also work
>> besides read "1.5")? I'm happy to
>> finaly use a language where I can
>> use words of my language to name
>> variables, so I wonder if we could
>> also make that step.
> 
> The purpose of 'read' is to read haskell notation, not to read 
> locally-sensitive notation.
> 
> So the right question to ask is "should we change haskell's lexical 
> syntax to support locally-sensitive number notation".
> 
> IMO, the answer is no. (...)

Agree about the answer, not about the question. The
correct one would be "is it possible to change haskell
syntax to support the international notation (not any
locally sensitive one) for decimal real numbers? Would
a change in 'read' be a good first step?"

I know this looks difficult, but I'm sure it deserves at
least some thinking. We have previous examples for
less important issues: ghc does accept Windows end
of line conventions, the minus and sign needs special
syntax, and '.' can be used as decimal separator even
if it's use as function notation.

Best,
Maur?cio

From dons at galois.com  Wed Sep 17 11:28:07 2008
From: dons at galois.com (Don Stewart)
Date: Wed Sep 17 11:25:29 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <48D0F55A.8000801@libero.it>
References: <48D0F55A.8000801@libero.it>
Message-ID: <20080917152807.GA4286@scytale.galois.com>

manlio_perillo:
> Hi.
> 
> After reading the chapter about IO in the "Real Word Haskell" book, I 
> have noted that there is no support for opening a temporary file that 
> will be automatically removed at program termination.
> 
> The Python tempfile module, as an example, implements a wrapper around 
> mkstemp function that does exactly this, and the code is portable; on 
> Windows it uses O_TEMPORARY_FILE flag, on POSIX systems the file is 
> unlink-ed as soon as it is created (but note that the code is not signal 
> safe - well, many functions in the Python standard library are not 
> signal safe).
> 
> There are reasons why GHC library does not implement this?
> 
> 
> The Python version also set the FD_CLOEXEC, O_NOINHERIT and O_NOFOLLOW 
> flags (where available).
> The GHC version, instead, set the O_NOCTTY flag.

It would be something like:

    withTempFile :: FilePath -> String -> ((FilePath,Handle) -> IO r) -> IO r
    withTempFile name tmp = bracket (openTempFile name tmp)
                                    (\(f,h) -> hClose h >> removeFile f) 

-- Don
From dons at galois.com  Wed Sep 17 11:28:57 2008
From: dons at galois.com (Don Stewart)
Date: Wed Sep 17 11:26:19 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <48D10934.20801@libero.it>
References: <48D0F55A.8000801@libero.it>
	<2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
	<48D10934.20801@libero.it>
Message-ID: <20080917152857.GB4286@scytale.galois.com>

manlio_perillo:
> Dougal Stanton ha scritto:
> >On Wed, Sep 17, 2008 at 1:17 PM, Manlio Perillo
> > wrote:
> >>The Python tempfile module, as an example, implements a wrapper around
> >>mkstemp function that does exactly this, and the code is portable; on
> >>Windows it uses O_TEMPORARY_FILE flag, on POSIX systems the file is
> >>unlink-ed as soon as it is created (but note that the code is not signal
> >>safe - well, many functions in the Python standard library are not signal
> >>safe).
> >
> >Something like:
> >
> >>withTempFile :: String -> ((FilePath, Handle) -> IO b) -> IO b
> >>withTempFile name action = do
> >>    tmpdir <- getTemporaryDirectory
> >>    bracket
> >>        (openTempFile tmpdir name)
> >>        (\(fp,h) -> hClose h >> removeFile fp)
> >>        action
> >
> >I don't know if this has the safety requirements you mean?
> >
> 
> Yes, this is the ideal solution for Haskell.
> 
> But since GHC does not implement such a function, I was curious to know 
> why it don't even implement a function that make sure the temporary file 
> is removed.
> 

Because it is two lines to write, so no one has yet proposed it for the
base library. 

-- Don
From lennart at augustsson.net  Wed Sep 17 11:33:31 2008
From: lennart at augustsson.net (Lennart Augustsson)
Date: Wed Sep 17 11:30:57 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: 
References:  <48D0275A.703@jellybean.co.uk>
	
Message-ID: 

Given examples like (1,2,3) I don't see how comma could ever be used
instead of  dot, unless you insist on whitespace around all commas.
And that doesn't look like the right way forward.

  -- Lennart

On Wed, Sep 17, 2008 at 4:20 PM, Mauricio  wrote:
>>> Do you think 'read' (actually,
>>> 'readsPrec'?) could be made to also
>>> read the international convention
>>> (ie., read "1,5" would also work
>>> besides read "1.5")? I'm happy to
>>> finaly use a language where I can
>>> use words of my language to name
>>> variables, so I wonder if we could
>>> also make that step.
>>
>> The purpose of 'read' is to read haskell notation, not to read
>> locally-sensitive notation.
>>
>> So the right question to ask is "should we change haskell's lexical syntax
>> to support locally-sensitive number notation".
>>
>> IMO, the answer is no. (...)
>
> Agree about the answer, not about the question. The
> correct one would be "is it possible to change haskell
> syntax to support the international notation (not any
> locally sensitive one) for decimal real numbers? Would
> a change in 'read' be a good first step?"
>
> I know this looks difficult, but I'm sure it deserves at
> least some thinking. We have previous examples for
> less important issues: ghc does accept Windows end
> of line conventions, the minus and sign needs special
> syntax, and '.' can be used as decimal separator even
> if it's use as function notation.
>
> Best,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From jgm at berkeley.edu  Wed Sep 17 11:48:19 2008
From: jgm at berkeley.edu (John MacFarlane)
Date: Wed Sep 17 11:45:30 2008
Subject: [Haskell-cafe] Re: Mac OS X dylib woes
In-Reply-To: <6d74b0d20809162339r6af616bbl9dd56af5dfa15359@mail.gmail.com>
References: <20080916234928.GA19133@berkeley.edu>
	<6d74b0d20809162339r6af616bbl9dd56af5dfa15359@mail.gmail.com>
Message-ID: <20080917154819.GB3251@berkeley.edu>

> If you type "ghc-pkg describe pcre-light", does it list
> "/opt/local/lib" under the "library-dirs:" field?  If not, that's most
> likely your problem.  Try unregistering the library and reinstalling
> with:
> 
> cabal install pcre-light --extra-include-dirs=/opt/local/include
> --extra-lib-dirs=/opt/local/lib

That worked!  Thanks.
John
From neil.mitchell.2 at credit-suisse.com  Wed Sep 17 11:51:07 2008
From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil)
Date: Wed Sep 17 11:49:31 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <20080917152857.GB4286@scytale.galois.com>
References: <48D0F55A.8000801@libero.it>
	<2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
	<48D10934.20801@libero.it> <20080917152857.GB4286@scytale.galois.com>
Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3A0D@ELON17P32001A.csfb.cs-group.com>

> > But since GHC does not implement such a function, I was curious to 
> > know why it don't even implement a function that make sure the 
> > temporary file is removed.
> > 
> 
> Because it is two lines to write, so no one has yet proposed 
> it for the base library. 

Map is 2 lines, but we have that as a library (1 line in Hugs).
Otherwise is a whole one lexeme long, but we still provide a library
function.

This one is tricky and has lots of edge cases! If its useful, it should
be in the libraries.

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

From lchangying at gmail.com  Wed Sep 17 11:58:37 2008
From: lchangying at gmail.com (Changying Li)
Date: Wed Sep 17 11:57:40 2008
Subject: [Haskell-cafe] a question about Database.HDBC.ODBC
Message-ID: <87bpympxw2.fsf@gmail.com>

I want to use hdbc to connect my mysql test db. so I set up my
/etc/odbcinst.ini :
[MySQL]
Description     = ODBC Driver for MySQL
Driver          = /usr/lib/libmyodbc.so
Setup           = /usr/lib/libodbcmyS.so
FileUsage       = 1

and /etc/odbc.ini:
[test]
Description     = MySQL database test
Driver          = MySQL
Server          = localhost
Database        = test
Port            = 3306
User            = root
Socket          = /tmp/mysql.sock
Option          =
Stmt            =

user chylli@localhost must use password to connect mysql. other users needn't.
I connect db like this:
Prelude Database.HDBC.ODBC Database.HDBC> handleSqlError (connectODBC "DSN=test")
*** Exception: user error (SQL error: SqlError {seState = "[\"HY000\"]", seNativeError = -1, seErrorMsg = "connectODBC/sqlDriverConnect: [\"1045: [unixODBC][MySQL][ODBC 3.51 Driver]Access denied for user 'chylli'@'localhost' (using password: NO)\"]"})
Prelude Database.HDBC.ODBC Database.HDBC> handleSqlError (connectODBC "DSN=test;UID=chylli")
Prelude Database.HDBC.ODBC Database.HDBC> 

in another term:
mysql> show processlist;
+----+-------------+-----------+------+---------+------+-------+------------------+
| Id | User        | Host      | db   | Command | Time | State | Info             |
+----+-------------+-----------+------+---------+------+-------+------------------+
| 31 | chylli?? | localhost | test | Sleep   | 1483 |       | NULL             | 
| 43 | root        | localhost | test | Sleep   |  116 |       | NULL             | 

my question is:
1. why not HDBC.ODBC use configuration in /etc/odbc.ini ? if is use,
then connectODBC "DSN=test" should use root as user without password and
it should succeed.

2. when using UID=chylli, why the user in 'show processlist' is not
chylli but 'chylli??' ?  if it use account 'chylli', that connection
should fail. but in fact it succeed !!!



-- 

Thanks & Regards

Changying Li

From briqueabraque at yahoo.com  Wed Sep 17 12:59:18 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 12:56:58 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: 
References: 
	
Message-ID: 

>     Do you think 'read' (actually,
>     'readsPrec'?) could be made to also
>     read the international convention
>     (ie., read "1,5" would also work
>     besides read "1.5")?
> 
> 
> No, as read is really intended to be a language-level tool, not 
> something that you should expose to end users. For locale-aware number 
> input and formatting, you'd want to do something else.


Sure. What I think would be great if possible
would be a language-level tool. The same way
'.' can be used as decimal separator even if
it's the function composition operator. If
it's not possible to change the syntax,
changing 'read' could be a good step (since,
sometimes, 'read' is a good way to inialize
some variables if proper care is taken.

I know this sound weird, but it is an issue,
for instance, when teaching programming.
Students who face programming classes usually
start writing numbers the wrong way, and
sometimes this leads to confusion. A similar
problem we had in the days when zeros were
cut so they would be different of O, and
now we have a lot of grown up people still
writing 0 as if it were a greek phi. (As
my father used to complain, when his students
had to write something like phi=0.)

Read and Show are, IMHO, a great way to
initialize variables. a = read "123" is
an alternative to a = 123, and maybe even
a replacement. If, for instance, both
show and read used some kind of delimiter,
it would be easy to use reasonable ways
to write constants of any kind. A big effort,
but not less than is needed for unicode
support in strings, and almost as usefull.

Thanks,
Maur?cio

From briqueabraque at yahoo.com  Wed Sep 17 13:04:00 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 13:02:33 2008
Subject: [Haskell-cafe] Re: How to check if two Haskell files are the same?
In-Reply-To: 
References: 
	
Message-ID: 

>> I would like to write a Haskell pretty-printer,
>> using standard libraries for that. How can I
>> check if the original and the pretty-printed
>> versions are the same? For instance, is there
>> a file generated by GHC at the compilation
>> pipe that is always guaranteed to have the
>> same MD5 hash when it comes from equivalent
>> source?
> 
> Compare .hi files?
> 

That was my first thought, but can I be sure
.hi files are going to be exactly the same,
i.e., isn't there some kind of information
(timestamps?) that can change without changes
in the code?

Maur?cio

From droundy at darcs.net  Wed Sep 17 13:17:38 2008
From: droundy at darcs.net (David Roundy)
Date: Wed Sep 17 13:15:03 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3A0D@ELON17P32001A.csfb.cs-group.com>
References: <48D0F55A.8000801@libero.it>
	<2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
	<48D10934.20801@libero.it>
	<20080917152857.GB4286@scytale.galois.com>
	<33A3F585590A6F4E81E3D45AA4A111C902CD3A0D@ELON17P32001A.csfb.cs-group.com>
Message-ID: <20080917171737.GB3507@darcs.net>

On Wed, Sep 17, 2008 at 04:51:07PM +0100, Mitchell, Neil wrote:
> > > But since GHC does not implement such a function, I was curious to 
> > > know why it don't even implement a function that make sure the 
> > > temporary file is removed.
> > > 
> > 
> > Because it is two lines to write, so no one has yet proposed 
> > it for the base library. 
> 
> Map is 2 lines, but we have that as a library (1 line in Hugs).
> Otherwise is a whole one lexeme long, but we still provide a library
> function.
> 
> This one is tricky and has lots of edge cases! If its useful, it should
> be in the libraries.

In particular, the code Don quoted is incorrect depending on which
import statements are used.  If we assume that the default is the
bracket available in Haskell 98, then it is definitely incorrect.

It also doesn't behave properly in the presence of signals or keyboard
interrupts (i.e. posix or windows systems).  Of course, a larger
change in the standard libraries is needed in order to solve this
particular problem, so I'd want to agree on a solution for that
problem first.  Which is perhaps a better reason why it's not yet in
the standard libraries: it's perhaps not a good idea to put a function
with such serious issues into the standard libraries.

David
From dot at dotat.at  Wed Sep 17 13:47:46 2008
From: dot at dotat.at (Tony Finch)
Date: Wed Sep 17 13:45:12 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <48D1063C.7060401@libero.it>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<4165d3a70809170612u68159c8aj7d317cbb0a0ecb01@mail.gmail.com>
	<48D1063C.7060401@libero.it>
Message-ID: 

On Wed, 17 Sep 2008, Manlio Perillo wrote:
> Jefferson Heard ha scritto:
> >
> > the weight of a full unix process plus the weight of the python
> > interpreter in terms of memory,
>
> With copy on write some memory can be saved (if you preload all the required
> modules in the master process).

The kernel data structures and writable pages supporting an OS-level
process add up to dozens of KB whereas a language-level concurrent
context should require about 1KB.

> > context switching times,
>
> That's probabily the same as thread switching time.

Competent language-level concurrency support (as in Haskell and Erlang)
makes a context switch about as expensive as a function call, thousands of
times faster than an OS-level process switch.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH: EAST 3 OR 4, INCREASING 5 AT
TIMES. SLIGHT. SHOWERS. GOOD.
From dmehrtash at gmail.com  Wed Sep 17 14:03:01 2008
From: dmehrtash at gmail.com (Daryoush Mehrtash)
Date: Wed Sep 17 14:00:26 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: <5de3f5ca0809161537v6f501d3bh9ac4763454eb3493@mail.gmail.com>
References: <5de3f5ca0809161537v6f501d3bh9ac4763454eb3493@mail.gmail.com>
Message-ID: 

I noticed that Wikipedia has listed a few text books on the topic:

http://en.wikipedia.org/wiki/Denotational_semantics#Textbooks

Any recommendations on which one might be a "better" read?

Thanks,

Daryoush

2008/9/16 Greg Meredith :
> Daryoush,
>
> Hopefully, the other replies about proving the monad laws already answered
> your previous question: yes!
>
> As for notions of semantic domain and denotational model, these ideas go
> back quite a ways; but, were given solid footing by Dana Scott. In a
> nutshell, we have essentially three views of a computation
>
> Operational -- computation is captured in a program and rules for executing
> it
> Logical -- computation is captured in a proof and rules for normalizing it
> Denotational -- computation is captured as a (completely unfolded)
> mathematical structure
>
> In the latter view we think of computations/programs as denoting some
> (usually infinitary) mathematical object. Our aim is to completely define
> the meaning of programs in terms of maps between their syntactic
> representation and the mathematical objects their syntax is intended to
> denote. (Notationally, one often writes such maps as [| - |] : Program ->
> Denotation.) For example, we model terms in the lambda calculus as elements
> in a D-infinity domain or Bohm trees or ... . Or, in more modern parlance,
> we model terms in the lambda calculus as morphisms in some Cartesian closed
> category, and the types of those terms as objects in said category. The gold
> standard of quality of such a model is full abstraction -- when the
> denotational notion of equivalence exactly coincides with an intended
> operational notion of equivalence. In symbols,
>
> P ~ Q <=> [| P |] = [| Q |], where ~ and = are the operational and
> denotational notions of equivalence, respectively
>
> The techniques of denotational semantics have been very fruitful, but
> greatly improved by having to rub elbows with operational characterizations.
> The original proposals for denotational models of the lambda calculus were
> much too arms length from the intensional structure implicit in the notion
> of computation and thus failed to achieve full abstraction even for toy
> models of lambda enriched with naturals and booleans (cf the so-called full
> abstraction for PCF problem). On the flip side, providing a better syntactic
> exposure of the use of resources -- ala linear logic -- aided the
> denotational programme.
>
> More generally, operational models fit neatly into two ready-made notions of
> equivalence
>
> contextual equivalence -- behaves the same in all contexts
> bisimulation -- behaves the same under all observations
>
> Moreover, these can be seen to coincide with ready-made notions of
> equivalence under the logical view of programs. Except for syntactically
> derived initial/final denotational models -- the current theory usually
> finds a more "home-grown" denotational notion of equivalence. In fact, i
> submit that it is this very distance from the syntactic presentation that
> has weakened the more popular understanding of "denotational" models to just
> this -- whenever you have some compositionally defined map from one
> representation to another that respects some form of equivalence, the target
> is viewed as the denotation.
>
> Best wishes,
>
> --greg
>
> Date: Mon, 15 Sep 2008 10:13:53 -0700
> From: "Daryoush Mehrtash" 
> Subject: Re: [Haskell-cafe] Semantic Domain, Function,  and
>        denotational model.....
> To: "Ryan Ingram" 
> Cc: Haskell Cafe 
> Message-ID:
>        >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Interestingly, I was trying to read his paper when I realized that I
> needed to figure out the meaning of denotational model, semantic
> domain, semantic functions.  Other Haskell books didn't talk about
> design in those terms, but obviously for him this is how he is driving
> his design.   I am looking for a simpler tutorial, text book like
> reference on the topic.
>
> Daryoush
>
> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram  wrote:
>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
>> paper for an in-depth real-world example.
>>
>> http://www.conal.net/papers/simply-reactive
>>
>>  -- ryan
>>
>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash 
>> wrote:
>>> I have been told that for a Haskell/Functional programmer the process
>>> of design starts with defining Semantic Domain, Function, and
>>> denotational model of the problem.  I have done some googling on the
>>> topic but haven't found a good reference on it.    I would appreciate
>>> any good references on the topic.
>>>
>>> thanks,
>>>
>>> daryoush
>>>
>>> ps.  I have found referneces like
>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>>> which doesn't do any good for me.    I need something with a more real
>>> examples.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 806 55th St NE
> Seattle, WA 98105
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
From aeyakovenko at gmail.com  Wed Sep 17 14:03:02 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Wed Sep 17 14:00:37 2008
Subject: [Haskell-cafe] Re: haskell blas bindings: does iomatrix gemv
	transposing of matrix a?
In-Reply-To: <344831234.727231221663040995.JavaMail.root@zm01.stanford.edu>
References: <563348269.727211221663038691.JavaMail.root@zm01.stanford.edu>
	<344831234.727231221663040995.JavaMail.root@zm01.stanford.edu>
Message-ID: 

> I made the decision to make "herm" an O(1) operation.  This means you don't have to pass transpose arguments to the multiplication routines.  When you do, for example:
>
>> let a = listMatrix (2,3) [1..6]
>>     x = listVector 2 [1, -1]
>> in herm a <*> x
>
> this gets implemented as a call to gemv with transa set to "ConjTrans".

Ah, i see, i didn't see that function.  That's pretty slick actually.


> The new version is pretty typeclass-heavy, since that's the only way I know how to support both ST and IO.  Consequently, there have been some performance regressions.  I have some optimization ideas (in the "TODO") file, but I do not have time to implement them right now.  If you or anyone else would like to help with this or anything else, I would be glad to have you aboard the development "team".

I would be glad to help.  Its probably about time i learned the type
system anyways.

Anatoly
From svein.ove at aas.no  Wed Sep 17 14:08:52 2008
From: svein.ove at aas.no (Svein Ove Aas)
Date: Wed Sep 17 14:06:17 2008
Subject: [Haskell-cafe] Re: How to check if two Haskell files are the same?
In-Reply-To: 
References: 
	
	
Message-ID: <221b53ab0809171108n243aecfftc336554074e716f@mail.gmail.com>

On Wed, Sep 17, 2008 at 7:04 PM, Mauricio  wrote:
>>> I would like to write a Haskell pretty-printer,
>>> using standard libraries for that. How can I
>>> check if the original and the pretty-printed
>>> versions are the same? For instance, is there
>>> a file generated by GHC at the compilation
>>> pipe that is always guaranteed to have the
>>> same MD5 hash when it comes from equivalent
>>> source?
>>
>> Compare .hi files?
>>
>
> That was my first thought, but can I be sure
> .hi files are going to be exactly the same,
> i.e., isn't there some kind of information
> (timestamps?) that can change without changes
> in the code?
>
For that matter, the code can change without the .hi file doing so,
eg. if a pragma noinline'd function is altered without changing its
type/strictness - or a function the optimizer decides is just
pointless to try inlining, for all I know.
From alfonso.acosta at gmail.com  Wed Sep 17 14:17:35 2008
From: alfonso.acosta at gmail.com (Alfonso Acosta)
Date: Wed Sep 17 14:15:00 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
In-Reply-To: 
References: 
	
Message-ID: <6a7c66fc0809171117t7a9e0ecdjbef65566d0ae04a4@mail.gmail.com>

On Wed, Sep 17, 2008 at 1:03 AM, Brandon S. Allbery KF8NH
 wrote:
> On 2008 Sep 16, at 10:30, Mauricio wrote:
>>
>> I would like to write a Haskell pretty-printer,
>> using standard libraries for that. How can I
>> check if the original and the pretty-printed
>> versions are the same? For instance, is there
>> a file generated by GHC at the compilation
>> pipe that is always guaranteed to have the
>> same MD5 hash when it comes from equivalent
>> source?
>
> Compare .hi files?

You an also compare the resulting object files
From wnoise at ofb.net  Wed Sep 17 14:38:10 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Wed Sep 17 14:35:43 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
References:  <48D016EE.4060605@gmail.com>
	
Message-ID: 

On 2008-09-17, Mauricio  wrote:
>> 
>> Localized reading should be somewhere else, perhaps related to Locales.
>
> No! If we had that, string from a program would not
> be readable by some program running in other machine,
> or other locale. As, actually, you describe below.
> Show and Read are for programs reading, not for
> user reading. That's a work for Pango :)

UI can be done with text, and in any case includes text and there
should be some nice way to localize that.  The locale system is the
standard way to do that on Unix.  These strings are not meant for
program-to-program communication, whereas read and show are.

IMAO, it's bloody well stupid to use commas for either the decimal
separator or the thousands separator, as it has a well established
role in separating the items in a list that conflicts with this.
While a thousands separator can improve readability, it's not strictly
necessary.  OTOH, a decimal separator is necessary.  As the comma's not
usable, that leaves us with the decimal point, and no thousands separator.
Lo and behold, that's exactly what Haskell uses.

-- 
Aaron Denney
-><-

From wnoise at ofb.net  Wed Sep 17 14:40:56 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Wed Sep 17 14:42:28 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
Message-ID: 

On 2008-09-17, Arnar Birgisson  wrote:
> Hi Manlio and others,
>
> On Wed, Sep 17, 2008 at 14:58, Manlio Perillo  wrote:
>>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
>>>
>>> "cloud computing, transactional memory and future multicore processors"
>>>
>>
>> Multicore support is already "supported" in Python, if you use
>> multiprocessing, instead of multithreading.
>
> Well, I'm a huge Python fan myself, but multiprocessing is not really
> a solution as much as it is a workaround. Python as a language has no
> problem with multithreading and multicore support and has all
> primitives to do conventional shared-state parallelism. However, the
> most popular /implementation/ of Python sacrifies this for
> performance, it has nothing to do with the language itself.

Huh.  I see multi-threading as a workaround for expensive processes,
which can explicitly use shared memory when that makes sense.

-- 
Aaron Denney
-><-

From allbery at ece.cmu.edu  Wed Sep 17 14:53:24 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 17 14:50:52 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <48D0F55A.8000801@libero.it>
References: <48D0F55A.8000801@libero.it>
Message-ID: <37039AB0-F48C-43F3-A10F-60087814B88A@ece.cmu.edu>

On 2008 Sep 17, at 8:17, Manlio Perillo wrote:
> The Python tempfile module, as an example, implements a wrapper  
> around mkstemp function that does exactly this, and the code is  
> portable; on Windows it uses O_TEMPORARY_FILE flag, on POSIX systems  
> the file is unlink-ed as soon as it is created (but note that the  
> code is not signal safe - well, many functions in the Python  
> standard library are not signal safe).
>
> There are reasons why GHC library does not implement this?

POSIX doesn't guaranteed that open-and-unlink works; HP-UX is a  
"POSIX" platform on which it doesn't.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From jonathanccast at fastmail.fm  Wed Sep 17 15:03:21 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Wed Sep 17 15:06:19 2008
Subject: [Haskell-cafe] Re: Python's big challenges, Haskell's big
	advantages?
In-Reply-To: 
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	
Message-ID: <1221678201.18670.12.camel@jcchost>

On Wed, 2008-09-17 at 18:40 +0000, Aaron Denney wrote:
> On 2008-09-17, Arnar Birgisson  wrote:
> > Hi Manlio and others,
> >
> > On Wed, Sep 17, 2008 at 14:58, Manlio Perillo  wrote:
> >>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
> >>>
> >>> "cloud computing, transactional memory and future multicore processors"
> >>>
> >>
> >> Multicore support is already "supported" in Python, if you use
> >> multiprocessing, instead of multithreading.
> >
> > Well, I'm a huge Python fan myself, but multiprocessing is not really
> > a solution as much as it is a workaround. Python as a language has no
> > problem with multithreading and multicore support and has all
> > primitives to do conventional shared-state parallelism. However, the
> > most popular /implementation/ of Python sacrifies this for
> > performance, it has nothing to do with the language itself.
> 
> Huh.  I see multi-threading as a workaround for expensive processes,
> which can explicitly use shared memory when that makes sense.

That breaks down when you want 1000s of threads.  I'm not aware of any
program, on any system, that spawns a new process on each event it wants
to handle concurrently; systems that don't use an existing user-space
thread library (such as Concurrent Haskell or libthread [1]) emulate
user-space threads by keeping a pool of processors and re-using them
(e.g., IIUC Apache does this).

Any counter-examples?

jcc

[1] http://swtch.com/plan9port/man/man3/thread.html


From lgreg.meredith at biosimilarity.com  Wed Sep 17 15:22:54 2008
From: lgreg.meredith at biosimilarity.com (Greg Meredith)
Date: Wed Sep 17 15:20:26 2008
Subject: [Haskell-cafe] Semantic Domain, Function,
	and denotational model.....
In-Reply-To: 
References: <5de3f5ca0809161537v6f501d3bh9ac4763454eb3493@mail.gmail.com>
	
Message-ID: <5de3f5ca0809171222o6add5f67tf676c838b28621ab@mail.gmail.com>

Daryoush,

The two chapters in the Handbook of Logic in Computer Science -- especially
the one  by Abramsky
and Jung -- are good.  i noticed that Lloyd Allison wrote a book on
practical denotational semantics. i've never read it, but i was intrigued by
his work using minimal message length as the basis for a generic framework
in Haskell for machine-learning models. He might have something useful to
say.

It is difficult to judge what would be a good book for you, however, because
i don't know if you what your aim is. Do you want context, history and
mathematical foundations or a quick way to understanding enough FP-speak to
write better commercial code? As i said, a lot of people loosely speak of
the *target* of some compositionally defined function (usually based on some
structural recursion) that preserves some operational notion of equality as
the denotation. This is almost certainly what is going on in the references
you cited early. You can kind of leave it at that.

On the other hand, if you wish to go deeper, the study of the meaning of
programs is highly rewarding and will change the way you think. One
particularly fruitful place is games semantics. Guy McCusker's PhD thesis
might be a way in. Abramsky and Jagadeesan's papers might be a way in. As i
said before, the places where denotational and operational semantics have
had to rub elbows has been useful to both approaches. One of the hands down
best characterizations of the relationship of the logical and operational
view of computation is Abramsky's Computational Interpretations of Linear
Logic . In
this paper Samson repeats the same process 3 times --

   1. specifies a logic by giving syntax for formulae and proof rules
   2. derives a term language (syntax of programs) and operational semantics
   that is sound w.r.t a type system given by the logical formulae
   3. derives a virtual machine for the term language
   4. refines the logic by an analysis of where the logic fails to capture
   our intuitions about resources -- looping back to step 1

The starting point is Intuitionistic Logic which yields the core of a
standard functional language. The next iteration is Intuitionistic Linear
Logic, which yields a linear FPL. The next iteration is Classical Linear
Logic which yields a concurrent language. Following the development of this
process will clarify the relationships between the logical and operational
view -- which ultimately bear on reasonable interpretations of denotational
interpretations.

If you make the step to say that the denotation must be the completely
unfolded structure -- the tree of reductions, the collection of possible
plays, etc -- then there are ways to see how these views logical,
operational and denotational are all calculable from one another -- and why
you might want to have all of them in any complete account of computation.

Best wishes,

--greg

On Wed, Sep 17, 2008 at 11:03 AM, Daryoush Mehrtash wrote:

> I noticed that Wikipedia has listed a few text books on the topic:
>
> http://en.wikipedia.org/wiki/Denotational_semantics#Textbooks
>
> Any recommendations on which one might be a "better" read?
>
> Thanks,
>
> Daryoush
>
> 2008/9/16 Greg Meredith :
> > Daryoush,
> >
> > Hopefully, the other replies about proving the monad laws already
> answered
> > your previous question: yes!
> >
> > As for notions of semantic domain and denotational model, these ideas go
> > back quite a ways; but, were given solid footing by Dana Scott. In a
> > nutshell, we have essentially three views of a computation
> >
> > Operational -- computation is captured in a program and rules for
> executing
> > it
> > Logical -- computation is captured in a proof and rules for normalizing
> it
> > Denotational -- computation is captured as a (completely unfolded)
> > mathematical structure
> >
> > In the latter view we think of computations/programs as denoting some
> > (usually infinitary) mathematical object. Our aim is to completely define
> > the meaning of programs in terms of maps between their syntactic
> > representation and the mathematical objects their syntax is intended to
> > denote. (Notationally, one often writes such maps as [| - |] : Program ->
> > Denotation.) For example, we model terms in the lambda calculus as
> elements
> > in a D-infinity domain or Bohm trees or ... . Or, in more modern
> parlance,
> > we model terms in the lambda calculus as morphisms in some Cartesian
> closed
> > category, and the types of those terms as objects in said category. The
> gold
> > standard of quality of such a model is full abstraction -- when the
> > denotational notion of equivalence exactly coincides with an intended
> > operational notion of equivalence. In symbols,
> >
> > P ~ Q <=> [| P |] = [| Q |], where ~ and = are the operational and
> > denotational notions of equivalence, respectively
> >
> > The techniques of denotational semantics have been very fruitful, but
> > greatly improved by having to rub elbows with operational
> characterizations.
> > The original proposals for denotational models of the lambda calculus
> were
> > much too arms length from the intensional structure implicit in the
> notion
> > of computation and thus failed to achieve full abstraction even for toy
> > models of lambda enriched with naturals and booleans (cf the so-called
> full
> > abstraction for PCF problem). On the flip side, providing a better
> syntactic
> > exposure of the use of resources -- ala linear logic -- aided the
> > denotational programme.
> >
> > More generally, operational models fit neatly into two ready-made notions
> of
> > equivalence
> >
> > contextual equivalence -- behaves the same in all contexts
> > bisimulation -- behaves the same under all observations
> >
> > Moreover, these can be seen to coincide with ready-made notions of
> > equivalence under the logical view of programs. Except for syntactically
> > derived initial/final denotational models -- the current theory usually
> > finds a more "home-grown" denotational notion of equivalence. In fact, i
> > submit that it is this very distance from the syntactic presentation that
> > has weakened the more popular understanding of "denotational" models to
> just
> > this -- whenever you have some compositionally defined map from one
> > representation to another that respects some form of equivalence, the
> target
> > is viewed as the denotation.
> >
> > Best wishes,
> >
> > --greg
> >
> > Date: Mon, 15 Sep 2008 10:13:53 -0700
> > From: "Daryoush Mehrtash" 
> > Subject: Re: [Haskell-cafe] Semantic Domain, Function,  and
> >        denotational model.....
> > To: "Ryan Ingram" 
> > Cc: Haskell Cafe 
> > Message-ID:
> >         >>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Interestingly, I was trying to read his paper when I realized that I
> > needed to figure out the meaning of denotational model, semantic
> > domain, semantic functions.  Other Haskell books didn't talk about
> > design in those terms, but obviously for him this is how he is driving
> > his design.   I am looking for a simpler tutorial, text book like
> > reference on the topic.
> >
> > Daryoush
> >
> > On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram 
> wrote:
> >> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
> >> paper for an in-depth real-world example.
> >>
> >> http://www.conal.net/papers/simply-reactive
> >>
> >>  -- ryan
> >>
> >> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash <
> dmehrtash@gmail.com>
> >> wrote:
> >>> I have been told that for a Haskell/Functional programmer the process
> >>> of design starts with defining Semantic Domain, Function, and
> >>> denotational model of the problem.  I have done some googling on the
> >>> topic but haven't found a good reference on it.    I would appreciate
> >>> any good references on the topic.
> >>>
> >>> thanks,
> >>>
> >>> daryoush
> >>>
> >>> ps.  I have found referneces like
> >>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
> >>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
> >>> which doesn't do any good for me.    I need something with a more real
> >>> examples.
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe@haskell.org
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>
> >>
> >
> >
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 806 55th St NE
> > Seattle, WA 98105
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>



-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080917/c42e2f3a/attachment-0001.htm
From mads_lindstroem at yahoo.dk  Wed Sep 17 15:17:38 2008
From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=)
Date: Wed Sep 17 15:25:14 2008
Subject: [Haskell-cafe] a question about Database.HDBC.ODBC
In-Reply-To: <87bpympxw2.fsf@gmail.com>
References: <87bpympxw2.fsf@gmail.com>
Message-ID: <1221679058.4489.9.camel@localhost.localdomain>

Hi,

Changying Li wrote:
> I want to use hdbc to connect my mysql test db. so I set up my
> /etc/odbcinst.ini :
> [MySQL]
> Description     = ODBC Driver for MySQL
> Driver          = /usr/lib/libmyodbc.so
> Setup           = /usr/lib/libodbcmyS.so
> FileUsage       = 1
> 
> and /etc/odbc.ini:
> [test]
> Description     = MySQL database test
> Driver          = MySQL
> Server          = localhost
> Database        = test
> Port            = 3306
> User            = root
> Socket          = /tmp/mysql.sock
> Option          =
> Stmt            =
> 
> user chylli@localhost must use password to connect mysql. other users needn't.
> I connect db like this:
> Prelude Database.HDBC.ODBC Database.HDBC> handleSqlError (connectODBC "DSN=test")
> *** Exception: user error (SQL error: SqlError {seState = "[\"HY000\"]", seNativeError = -1, seErrorMsg = "connectODBC/sqlDriverConnect: [\"1045: [unixODBC][MySQL][ODBC 3.51 Driver]Access denied for user 'chylli'@'localhost' (using password: NO)\"]"})
> Prelude Database.HDBC.ODBC Database.HDBC> handleSqlError (connectODBC "DSN=test;UID=chylli")
> Prelude Database.HDBC.ODBC Database.HDBC> 
> 
> in another term:
> mysql> show processlist;
> +----+-------------+-----------+------+---------+------+-------+------------------+
> | Id | User        | Host      | db   | Command | Time | State | Info             |
> +----+-------------+-----------+------+---------+------+-------+------------------+
> | 31 | chylli?? | localhost | test | Sleep   | 1483 |       | NULL             | 
> | 43 | root        | localhost | test | Sleep   |  116 |       | NULL             | 
> 
> my question is:
> 1. why not HDBC.ODBC use configuration in /etc/odbc.ini ? if is use,
> then connectODBC "DSN=test" should use root as user without password and
> it should succeed.

Are you sure it is a HDBC and not a ODBC-library problem? It seems that
you use unixODBC and can then try the command:

  isql test

which will connect though unixODBC without involving HDBC. If you still
have the same problems, then it must be unrelated to HDBC.

> 
> 2. when using UID=chylli, why the user in 'show processlist' is not
> chylli but 'chylli??' ?  if it use account 'chylli', that connection
> should fail. but in fact it succeed !!!
> 
> 
> 

Greetings,

Mads Lindstr?m



From allbery at ece.cmu.edu  Wed Sep 17 15:29:19 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 17 15:26:48 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
In-Reply-To: <6a7c66fc0809171117t7a9e0ecdjbef65566d0ae04a4@mail.gmail.com>
References: 
	
	<6a7c66fc0809171117t7a9e0ecdjbef65566d0ae04a4@mail.gmail.com>
Message-ID: <4538FCBE-7DBA-4F1D-90D5-5A12972FDFF6@ece.cmu.edu>

On 2008 Sep 17, at 14:17, Alfonso Acosta wrote:
> On Wed, Sep 17, 2008 at 1:03 AM, Brandon S. Allbery KF8NH
>  wrote:
>> On 2008 Sep 16, at 10:30, Mauricio wrote:
>>>
>>> I would like to write a Haskell pretty-printer,
>>> using standard libraries for that. How can I
>>> check if the original and the pretty-printed
>>> versions are the same? For instance, is there
>>> a file generated by GHC at the compilation
>>> pipe that is always guaranteed to have the
>>> same MD5 hash when it comes from equivalent
>>> source?
>>
>> Compare .hi files?
>
> You an also compare the resulting object files


On ELF systems (the majority) you have to watch out for the timestamp  
in the ELF header.  I know there is code in the gcc source that does  
object comparisons to verify that stage3 builds match stage2, omitting  
the header.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From allbery at ece.cmu.edu  Wed Sep 17 15:44:12 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 17 15:41:49 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: 
References:  <48D016EE.4060605@gmail.com>
	 
Message-ID: 

On 2008 Sep 17, at 14:38, Aaron Denney wrote:
> On 2008-09-17, Mauricio  wrote:
>>> Localized reading should be somewhere else, perhaps related to  
>>> Locales.
>>
>> No! If we had that, string from a program would not
>> be readable by some program running in other machine,
>> or other locale. As, actually, you describe below.
>> Show and Read are for programs reading, not for
>> user reading. That's a work for Pango :)
>
> While a thousands separator can improve readability, it's not strictly
> necessary.  OTOH, a decimal separator is necessary.  As the comma's  
> not
> usable, that leaves us with the decimal point, and no thousands  
> separator.
> Lo and behold, that's exactly what Haskell uses.


There are languages which ignore _ in numbers, allowing it to be used  
as a thousands separator if desired.  ghc currently parses "1_234" as  
<1:number> <_234:symbol> and I'm tempted to wonder if anything depends  
on it.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From huschi at gmx.org  Wed Sep 17 16:10:31 2008
From: huschi at gmx.org (Martin Huschenbett)
Date: Wed Sep 17 16:07:57 2008
Subject: [Haskell-cafe] Real World HAppS: Cabalized,	Self-Demoing HAppS
	Tutorial (Version 3)
In-Reply-To: <910ddf450809120807j6d1379b3uc8a23c8dc8720b55@mail.gmail.com>
References: <910ddf450809120807j6d1379b3uc8a23c8dc8720b55@mail.gmail.com>
Message-ID: <48D16437.5040200@gmx.org>

Hi,

I got your tutorial working. But when running it from ghci an exception 
raises:

*** Exception: _local/_state\current-0000000000: 
openBinaryFile: invalid argument (Invalid argument)

But I found a way to fix this: replace

   runserver 5001

by

   withProgName "happs-tutorial" $ runserver 5001

Regards,

Martin.

Thomas Hartman schrieb:
> I pushed a new version of happs-tutorial to the online demo at
> 
> http://happstutorial.com:5001 This is also on hackage: cabal install
> happs-tutorial. (now version 3.)
> 
> or darcs get http://code.haskell.org/happs-tutorial for the latest
> 
> The demo/tutorial has the same basic functionality as the last release
> -- just a login form essentially -- but a lot more bling now. Like
> menu link items that change colors when the page is clicked. Also the
> login form that gives sane error messages.
> 
> The focus for this release was on explaining how I used StringTemplate
> with HAppS.
> 
> Hopefully in version 4 I'll finally get to State and Macid! And
> hopefully some functionality that actually does something beyond just
> showing what users have created logins :)
> 
> Thomas
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From manlio_perillo at libero.it  Wed Sep 17 16:11:28 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 16:08:59 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <20080917171737.GB3507@darcs.net>
References: <48D0F55A.8000801@libero.it>	<2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>	<48D10934.20801@libero.it>	<20080917152857.GB4286@scytale.galois.com>	<33A3F585590A6F4E81E3D45AA4A111C902CD3A0D@ELON17P32001A.csfb.cs-group.com>
	<20080917171737.GB3507@darcs.net>
Message-ID: <48D16470.30002@libero.it>

David Roundy ha scritto:
> [...]
> In particular, the code Don quoted is incorrect depending on which
> import statements are used.  If we assume that the default is the
> bracket available in Haskell 98, then it is definitely incorrect.
> 
> It also doesn't behave properly in the presence of signals or keyboard
> interrupts (i.e. posix or windows systems).  

Maybe a withSignalsMasked function, at least on Posix systems (it is not 
defined in System.Posix.Signals)?

I have no idea how signals works under Windows.

 > [...]


Manlio Perillo
From wnoise at ofb.net  Wed Sep 17 16:29:30 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Wed Sep 17 16:27:07 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
Message-ID: 

On 2008-09-17, Jonathan Cast  wrote:
> On Wed, 2008-09-17 at 18:40 +0000, Aaron Denney wrote:
>> On 2008-09-17, Arnar Birgisson  wrote:
>> > Hi Manlio and others,
>> >
>> > On Wed, Sep 17, 2008 at 14:58, Manlio Perillo  wrote:
>> >>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
>> >>>
>> >>> "cloud computing, transactional memory and future multicore processors"
>> >>>
>> >>
>> >> Multicore support is already "supported" in Python, if you use
>> >> multiprocessing, instead of multithreading.
>> >
>> > Well, I'm a huge Python fan myself, but multiprocessing is not really
>> > a solution as much as it is a workaround. Python as a language has no
>> > problem with multithreading and multicore support and has all
>> > primitives to do conventional shared-state parallelism. However, the
>> > most popular /implementation/ of Python sacrifies this for
>> > performance, it has nothing to do with the language itself.
>> 
>> Huh.  I see multi-threading as a workaround for expensive processes,
>> which can explicitly use shared memory when that makes sense.
>
> That breaks down when you want 1000s of threads.

This really misses the point I was going for.  I don't want 1000s of
threads.  I don't want *any* threads.  Processes are nice because you
don't have other threads of execution stomping on your memory-space
(except when explicitly invited to by arranged shared-memory areas).
It's an easier model to control side-effects in.  If this is too
expensive, and threads in the same situation will work faster, than I
might reluctantly use them instead.

> I'm not aware of any program, on any system, that spawns a new process
> on each event it wants to handle concurrently;

inetd

> systems that don't use an existing user-space thread library (such as
> Concurrent Haskell or libthread [1]) emulate user-space threads by
> keeping a pool of processors and re-using them (e.g., IIUC Apache does
> this).

Your response seems to be yet another argument that processes are too
expensive to be used the same way as threads.  In my mind pooling vs
new-creation is only relevant to process vs thread in the performance
aspects.  The fact that people use thread-pools means that they think
that even thread-creation is too expensive.  The central aspect in my
mind is a default share-everything, or default share-nothing.  One is
much easier to reason about and encourages writing systems that have
less shared-memory contention.

-- 
Aaron Denney
-><-

From qdunkan at gmail.com  Wed Sep 17 16:44:32 2008
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed Sep 17 16:41:58 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
In-Reply-To: 
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	
Message-ID: <2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>

>> systems that don't use an existing user-space thread library (such as
>> Concurrent Haskell or libthread [1]) emulate user-space threads by
>> keeping a pool of processors and re-using them (e.g., IIUC Apache does
>> this).
>
> Your response seems to be yet another argument that processes are too
> expensive to be used the same way as threads.  In my mind pooling vs
> new-creation is only relevant to process vs thread in the performance
> aspects.  The fact that people use thread-pools means that they think
> that even thread-creation is too expensive.  The central aspect in my
> mind is a default share-everything, or default share-nothing.  One is
> much easier to reason about and encourages writing systems that have
> less shared-memory contention.

This is similar to the plan9 conception of processes.  You have a
generic rfork() call that takes flags that say what to share with your
parent: namespace, environment, heap, etc.  Thus the only difference
between a thread and a process is different flags to rfork().

Under the covers, I believe linux is similar, with its clone() call.

The fast context switching part seems orthogonal to me.  Why is it
that getting the OS involved for context switches kills the
performance?  Is it that the ghc RTS can switch faster because it
knows more about the code it's running (i.e. the OS obviously couldn't
switch on memory allocations like that)?  Or is jumping up to kernel
space somehow expensive by nature?  And why does the OS need so many
more K to keep track of a thread than the RTS?  I don't really know
much about either OSes or language runtimes so this is interesting to
me.
From jonathanccast at fastmail.fm  Wed Sep 17 16:42:00 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Wed Sep 17 16:44:57 2008
Subject: [Haskell-cafe] Re: Python's big challenges, Haskell's big
	advantages?
In-Reply-To: 
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	
Message-ID: <1221684120.18670.29.camel@jcchost>

On Wed, 2008-09-17 at 20:29 +0000, Aaron Denney wrote:
> On 2008-09-17, Jonathan Cast  wrote:
> > On Wed, 2008-09-17 at 18:40 +0000, Aaron Denney wrote:
> >> On 2008-09-17, Arnar Birgisson  wrote:
> >> > Hi Manlio and others,
> >> >
> >> > On Wed, Sep 17, 2008 at 14:58, Manlio Perillo  wrote:
> >> >>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
> >> >>>
> >> >>> "cloud computing, transactional memory and future multicore processors"
> >> >>>
> >> >>
> >> >> Multicore support is already "supported" in Python, if you use
> >> >> multiprocessing, instead of multithreading.
> >> >
> >> > Well, I'm a huge Python fan myself, but multiprocessing is not really
> >> > a solution as much as it is a workaround. Python as a language has no
> >> > problem with multithreading and multicore support and has all
> >> > primitives to do conventional shared-state parallelism. However, the
> >> > most popular /implementation/ of Python sacrifies this for
> >> > performance, it has nothing to do with the language itself.
> >> 
> >> Huh.  I see multi-threading as a workaround for expensive processes,
> >> which can explicitly use shared memory when that makes sense.
> >
> > That breaks down when you want 1000s of threads.
> 
> This really misses the point I was going for.  I don't want 1000s of
> threads.  I don't want *any* threads.  Processes are nice because you
> don't have other threads of execution stomping on your memory-space
> (except when explicitly invited to by arranged shared-memory areas).
> It's an easier model to control side-effects in.  If this is too
> expensive, and threads in the same situation will work faster, than I
> might reluctantly use them instead.
> 
> > I'm not aware of any program, on any system, that spawns a new process
> > on each event it wants to handle concurrently;
> 
> inetd

OK.  But inetd calls exec on each event, too, so I think it's somewhat
orthogonal to this issue.  (Multi-processing is great if you want to
compose programs; the question is how you parallelize concurrent
instances of the same program).

> > systems that don't use an existing user-space thread library (such as
> > Concurrent Haskell or libthread [1]) emulate user-space threads by
> > keeping a pool of processors and re-using them (e.g., IIUC Apache does
> > this).
> 
> Your response seems to be yet another argument that processes are too
> expensive to be used the same way as threads.

You mean `is'.  And they are.  Would you write a web server run out of
inetd?  (Would its multi-processor support make it out-perform a
single-threaded web server in the same language?  I doubt it.)  HWS, on
the other hand, spawns a new Concurrent Haskell thread on every request.

> In my mind pooling vs
> new-creation is only relevant to process vs thread in the performance
> aspects.

Say what?  This discussion is entirely about performance --- does
CPython actually have the ability to scale concurrent programs to
multiple processors?  The only reason you would ever want to do that is
for performance.

> The fact that people use thread-pools

I don't think people use thread-pools with Concurrent Haskell, or with
libthread.

> means that they think
> that even thread-creation is too expensive.

Kernel threads /are/ expensive.  Which is why all the cool kids use
user-space threads.

> The central aspect in my
> mind is a default share-everything, or default share-nothing.

I really don't think you understand Concurrent Haskell, then.  (Or
Concurrent ML, or stackless Python, or libthread, or any other CSP-based
set-up).

jcc


From allbery at ece.cmu.edu  Wed Sep 17 16:50:20 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 17 16:47:48 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
In-Reply-To: <2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	
	<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>
Message-ID: <37153D36-52B5-4D00-B7E8-103A722756D0@ece.cmu.edu>

On 2008 Sep 17, at 16:44, Evan Laforge wrote:
>>> The fast context switching part seems orthogonal to me.  Why is it
> that getting the OS involved for context switches kills the
> performance?  Is it that the ghc RTS can switch faster because it
> knows more about the code it's running (i.e. the OS obviously couldn't
> switch on memory allocations like that)?  Or is jumping up to kernel
> space somehow expensive by nature?  And why does the OS need so many

A context switch involving the OS is actually a double (at least)  
context switch:  one to switch to kernel context, another to switch  
back to user context, and (because kernel context switches are  
scheduler entry points) optionally switches to other processes which  
have a higher immediate priority.  These context switches also switch  
considerably more state than a user-mode context switch between green  
threads, which doesn't switch the full process context including the  
set of process page tables, processor access controls, etc.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From droundy at darcs.net  Wed Sep 17 16:58:13 2008
From: droundy at darcs.net (David Roundy)
Date: Wed Sep 17 16:55:38 2008
Subject: [Haskell-cafe] about openTempFile
In-Reply-To: <48D16470.30002@libero.it>
References: <48D0F55A.8000801@libero.it>
	<2d3641330809170610x1f4a9dfcl4f4d30ed25d4815d@mail.gmail.com>
	<48D10934.20801@libero.it>
	<20080917152857.GB4286@scytale.galois.com>
	<33A3F585590A6F4E81E3D45AA4A111C902CD3A0D@ELON17P32001A.csfb.cs-group.com>
	<20080917171737.GB3507@darcs.net> <48D16470.30002@libero.it>
Message-ID: <20080917205813.GH3507@darcs.net>

On Wed, Sep 17, 2008 at 10:11:28PM +0200, Manlio Perillo wrote:
> David Roundy ha scritto:
>> [...]
>> In particular, the code Don quoted is incorrect depending on which
>> import statements are used.  If we assume that the default is the
>> bracket available in Haskell 98, then it is definitely incorrect.
>>
>> It also doesn't behave properly in the presence of signals or keyboard
>> interrupts (i.e. posix or windows systems).  
>
> Maybe a withSignalsMasked function, at least on Posix systems (it is not  
> defined in System.Posix.Signals)?

Darcs does something like this, and I obviously think it should be
moved into the standard libraries.  In my opinion signals ought to
throw asynchronous exceptions by default, then we'd have unified
handling of exceptional cases.

> I have no idea how signals works under Windows.

Windows doesn't have signals per se, but does have something similar
for keyboard interrupts, which in darcs we also convert into an
asynchronous exception.  I'm not clear as to how well it works.  Under
cygwin shells, ctrl-C does something other than send a windows
keyboard interrupt, so darcs doesn't work so well in that
environment.

David
From jonathanccast at fastmail.fm  Wed Sep 17 16:55:51 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Wed Sep 17 16:58:49 2008
Subject: [Haskell-cafe] Re: Python's big challenges, Haskell's big
	advantages?
In-Reply-To: <2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	
	<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>
Message-ID: <1221684951.18670.41.camel@jcchost>

On Wed, 2008-09-17 at 13:44 -0700, Evan Laforge wrote:
> >> systems that don't use an existing user-space thread library (such as
> >> Concurrent Haskell or libthread [1]) emulate user-space threads by
> >> keeping a pool of processors and re-using them (e.g., IIUC Apache does
> >> this).
> >
> > Your response seems to be yet another argument that processes are too
> > expensive to be used the same way as threads.  In my mind pooling vs
> > new-creation is only relevant to process vs thread in the performance
> > aspects.  The fact that people use thread-pools means that they think
> > that even thread-creation is too expensive.  The central aspect in my
> > mind is a default share-everything, or default share-nothing.  One is
> > much easier to reason about and encourages writing systems that have
> > less shared-memory contention.
> 
> This is similar to the plan9 conception of processes.  You have a
> generic rfork() call that takes flags that say what to share with your
> parent: namespace, environment, heap, etc.  Thus the only difference
> between a thread and a process is different flags to rfork().

As I mentioned, Plan 9 also has a user-space thread library, similar to
Concurrent Haskell.

> Under the covers, I believe linux is similar, with its clone() call.
> 
> The fast context switching part seems orthogonal to me.  Why is it
> that getting the OS involved for context switches kills the
> performance?

Read about CPU architecture.

> Is it that the ghc RTS can switch faster because it
> knows more about the code it's running (i.e. the OS obviously couldn't
> switch on memory allocations like that)?  Or is jumping up to kernel
> space somehow expensive by nature?

Yes.  Kernel code is very different on the bare metal from userspace
code; RTS code of course is not at all different.  Switching processes
in the kernel requires an interrupt or a system call.  Both of those
require the processor to dump the running process's state so it can be
restored later (userspace thread-switching does the same thing, but it
doesn't dump as much state because it doesn't need to be as conservative
about what it saves).

> And why does the OS need so many
> more K to keep track of a thread than the RTS?

An OS thread (Linux/Plan 9) stores:

* Stack (definitely a stack pointer and stored registers (> 40 bytes on
i686) and includes a special set of page tables on Plan 9)
* FD set (even if it's the same as the parent thread, you need to keep a
pointer to it
* uid/euid/gid/egid (Plan 9 I think omits euid and egid)
* Namespace (Plan 9 only; again, you need at least a pointer even if
it's the same as the parent process)
* Priority
* Possibly other things I can't think of right now

A Concurrent Haskell thread stores:

* Stack
* Allocation area (4KB)

The kernel offers more to a process (and offers a wider separation
between processes) than Concurrent Haskell offers to a thread.

jcc


From weihu at cs.virginia.edu  Wed Sep 17 17:03:26 2008
From: weihu at cs.virginia.edu (Wei Hu)
Date: Wed Sep 17 17:01:00 2008
Subject: [Haskell-cafe] Re: Predicativity?
References: 
	<564033F0-7E2F-4B3D-8E92-B8C563BFE8DB@gmail.com>
Message-ID: 

Thomas Davie  gmail.com> writes:

> In your application (id id) you create two instances of id, each of  
> which has type forall a. a -> a, and each of which can be applied to a  
> different type.  In this case, the left one gets applied to the type  
> (a -> a) and the right one a, giving them types (a -> a) -> (a -> a)  
> and (a -> a) respectively.

Ah, I didn't realize it's because I created two instances of id, but it became 
clear immediately after you pointed this out. Thank you, Ryan and Thomas, for 
clarifying my confusion.

Wei




From briqueabraque at yahoo.com  Wed Sep 17 17:16:46 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 17:14:21 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: 
References: 
	<48D016EE.4060605@gmail.com>	
	
Message-ID: 

 >>> Do you think 'read' (actually, 'readsPrec'?)
 >>> could be made to also read the international
 >>> convention (ie., read "1,5" would also work
 >>> besides read "1.5")?

(...)

 > IMAO, it's bloody well stupid to use commas for
 > either the decimal separator or the thousands
 > separator, as it has a well established role in
 > separating the items in a list that conflicts
 > with this. (...)

After 10 years of professional experience, I'm
getting used to the fact that almost every time
someone says my idea is stupid I'm going in the
right direction.  Linux, firefox? And know
everybody in the office uses nothing else. "It's
stupid to use anything but Java, that's what the
whole world is using", and here I am writing
software in Haskell.

Really, no troll intended. This is an open source
world, I'll try my own Read and Show classes. If
others like it, great, if not, I was wrong in the
first place :)

Best! Thanks for your attention,
Maur?cio

From wnoise at ofb.net  Wed Sep 17 17:20:29 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Wed Sep 17 17:18:01 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	 <1221684120.18670.29.camel@jcchost>
Message-ID: 

On 2008-09-17, Jonathan Cast  wrote:
>> In my mind pooling vs new-creation is only relevant to process vs
>> thread in the performance aspects.
>
> Say what?  This discussion is entirely about performance --- does
> CPython actually have the ability to scale concurrent programs to
> multiple processors?  The only reason you would ever want to do that is
> for performance.

I entered the discussion as which model is a workaround for the other --
someone said processes were a workaround for the lack of good threading
in e.g. standard CPython.  I replied that most languages thread support can be
seen as a workaround for the poor performance of communicating processes.
(creation in particular is usually cited, but that cost can often be reduced
by process pools, context switching costs, alas, is harder.)

> Kernel threads /are/ expensive.  Which is why all the cool kids use
> user-space threads.

Often muxed on top of kernel threads, because user-threads can't use
multiple CPUs at once.

>> The central aspect in my mind is a default share-everything, or
>> default share-nothing.
>
> I really don't think you understand Concurrent Haskell, then.  (Or
> Concurrent ML, or stackless Python, or libthread, or any other CSP-based
> set-up).

Or Erlang, Occam, or heck, even jcsp.  Because I'm coming at this from a
slightly different perspective and place a different emphasis on things
you think I don't understand?  No, trust me, I do understand them[1],
and think CSP and actor models (the differences in nondeterminism is a
minor detail that doesn't much matter here) are extremely nice ways of
implementing parallel systems.

These are, in fact, process models.  They are implemented on top of thread models,
but that's a performance hack.  And while putting this model on top
restores much of the programming sanity, in languages with mutable
variables and references that can be passed, you still need a fair
bit of discipline to keep that sanity.  There, the implementation detail
of thread, rather than process allows and even encourages shortcuts that
violate the process model.  In languages that are immutable, taking
advantage of the shared memory space really can gain efficiency without
any noticeably downside.

[1] I used to work for a company designing and modeling CSP-based
hardware designs.  In my spare time I started writing a compiler from
our HDL to Concurrent Haskell, but abandoned it when I left for
grad school.

-- 
Aaron Denney
-><-

From chaddai.fouche at gmail.com  Wed Sep 17 17:23:21 2008
From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=)
Date: Wed Sep 17 17:20:46 2008
Subject: [Haskell-cafe] How to check if two Haskell files are the same?
In-Reply-To: 
References: 
Message-ID: 

2008/9/16 Mauricio :
> Hi,
>
> I would like to write a Haskell pretty-printer,
> using standard libraries for that. How can I
> check if the original and the pretty-printed
> versions are the same? For instance, is there
> a file generated by GHC at the compilation
> pipe that is always guaranteed to have the
> same MD5 hash when it comes from equivalent
> source?

There is not, though I have a suggestion :
Am I correct in assuming that you mean "equivalent source" in the
sense that only the formatting (and eventually {;} as a layout format
consequence) differs ?

Then the sequence of tokens from the source ought to do the trick as
long as you delete location information (map unLoc) and transform
ITvocurly ("virtual" braces for layout induced blocks) into ITocurly
(real braces for no-layout blocks) (and same for ITvccurly) (it's just
another map). If only the formatting differs, those two should be
identical.

Now the current GHC don't give you direct access to the Token stream
but the next release should contain the functions I wrote to support
this (for HaRe).

In fact you could do this with the AST but it would be more
complicated to do the necessary extractions and comparisons...

-- 
Jeda?
From arnarbi at gmail.com  Wed Sep 17 17:42:22 2008
From: arnarbi at gmail.com (Arnar Birgisson)
Date: Wed Sep 17 17:39:46 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
In-Reply-To: 
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	 <1221684120.18670.29.camel@jcchost>
	
Message-ID: <28012bc60809171442r500ef533u294f74092581e17b@mail.gmail.com>

Hi Aaron,

On Wed, Sep 17, 2008 at 23:20, Aaron Denney  wrote:
> I entered the discussion as which model is a workaround for the other --
> someone said processes were a workaround for the lack of good threading
> in e.g. standard CPython.  I replied that most languages thread support can be
> seen as a workaround for the poor performance of communicating processes.
> (creation in particular is usually cited, but that cost can often be reduced
> by process pools, context switching costs, alas, is harder.)

That someone was probably me, but this is not what I meant. I meant
that the "processing" [1] Python module is a workaround for CPython's
performance problems with threads. For those who don't know it, the
processing module exposes a nearly identical interface to the standard
threading module in Python, but runs each "thread" in a seperate OS
process. The processing module emulates shared memory between these
"threads" as well as locking primitives and blocking. That is what I
meant when I said "processing" (the module) was a workaround for
CPython's threading issues.

[1] http://www.python.org/dev/peps/pep-0371/

The processes vs. threads depends on definitions. There seem to be two
sets floating around here. One is that processes and threads are
essentially the same, the only difference being that processes don't
share memory but threads do. With this view it doesn't really matter
if "processes" are implemented as proper OS processes or OS threads.
Discussion based on this definition can be interesting and one model
fits some problems better than the other and vice versa.

The other one is the systems view of OS processes vs. OS threads.
Discussion about the difference between these two is only mildly
interesting imo, as I think most people agree on things here and they
are well covered in textbooks that are old as dirt.

>>> The central aspect in my mind is a default share-everything, or
>>> default share-nothing.
>>
[..snip...]
> These are, in fact, process models.  They are implemented on top of thread models,
> but that's a performance hack.  And while putting this model on top
> restores much of the programming sanity, in languages with mutable
> variables and references that can be passed, you still need a fair
> bit of discipline to keep that sanity.  There, the implementation detail
> of thread, rather than process allows and even encourages shortcuts that
> violate the process model.

Well, this is a viewpoint I don't totally agree with. Correct me if
I'm not understanding you, but you seem to be making the point that OS
processes are often preferred because with threads, you *can* get
yourself in trouble by using shared memory.

The thing I don't agree with is "let's use A because B has dangerous
features". This is sort of like the design mantra of languages like
Java. Now, you may say that indeed Java has been wildly successful,
but I think (or hope) that is because we don't give people
(programmers) enough credit. Literature, culture and training in the
current practice of programming could do well IMO with making fewer
_good_ programmers rather than a lot of mediocre ones. And _good_
programmers don't need to be handcuffed just because otherwise they
*could* poke themselves in the eye.

I.e. if you need to sacrifice the efficiency of threads for full-blown
OS processes because people can't stay away from shared memory, then
something is fundamentally wrong.

I'll stop here, this is starting to sound like a very OT rant.

cheers,
Arnar
From dons at galois.com  Wed Sep 17 17:44:22 2008
From: dons at galois.com (Don Stewart)
Date: Wed Sep 17 17:41:42 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
In-Reply-To: <1221684120.18670.29.camel@jcchost>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	 <1221684120.18670.29.camel@jcchost>
Message-ID: <20080917214422.GA5249@scytale.galois.com>

jonathanccast:
> 
> > The fact that people use thread-pools
> 
> I don't think people use thread-pools with Concurrent Haskell, or with
> libthread.
> 

Sure. A Chan with N worker forkIO threads taking jobs from a queue is a
useful idiom I've employed on occasion.

-- Don
From jonathanccast at fastmail.fm  Wed Sep 17 17:40:43 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Wed Sep 17 17:43:40 2008
Subject: [Haskell-cafe] Re: Python's big challenges, Haskell's big
	advantages?
In-Reply-To: <28012bc60809171442r500ef533u294f74092581e17b@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	 <1221684120.18670.29.camel@jcchost>
	
	<28012bc60809171442r500ef533u294f74092581e17b@mail.gmail.com>
Message-ID: <1221687643.18670.58.camel@jcchost>

On Wed, 2008-09-17 at 23:42 +0200, Arnar Birgisson wrote:
> On Wed, Sep 17, 2008 at 23:20, Aaron Denney  wrote:
> >>> The central aspect in my mind is a default share-everything, or
> >>> default share-nothing.
> >>
> [..snip...]
> > These are, in fact, process models.  They are implemented on top of thread models,
> > but that's a performance hack.  And while putting this model on top
> > restores much of the programming sanity, in languages with mutable
> > variables and references that can be passed, you still need a fair
> > bit of discipline to keep that sanity.  There, the implementation detail
> > of thread, rather than process allows and even encourages shortcuts that
> > violate the process model.
> 
> Well, this is a viewpoint I don't totally agree with. Correct me if
> I'm not understanding you, but you seem to be making the point that OS
> processes are often preferred because with threads, you *can* get
> yourself in trouble by using shared memory.
> 
> The thing I don't agree with is "let's use A because B has dangerous
> features". This is sort of like the design mantra of languages like
> Java. 

Or Haskell.

jcc


From lgreg.meredith at biosimilarity.com  Wed Sep 17 17:46:57 2008
From: lgreg.meredith at biosimilarity.com (Greg Meredith)
Date: Wed Sep 17 17:44:22 2008
Subject: [Haskell-cafe] Ajax-Haskell framework?
Message-ID: <5de3f5ca0809171446mea592ebxad922add0e41935b@mail.gmail.com>

Haskellians,

Is there an Ajax-Haskell framework? In case there are many, is there a
preferred one? Experiences people would like to share?

Best wishes,

--greg

-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080917/81709b45/attachment.htm
From jonathanccast at fastmail.fm  Wed Sep 17 17:50:55 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Wed Sep 17 17:53:52 2008
Subject: Threads vs. processes [Was: Re: [Haskell-cafe] Re: Python's big
	challenges, Haskell's big advantages?]
In-Reply-To: 
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	 <1221684120.18670.29.camel@jcchost>
	
Message-ID: <1221688255.18670.70.camel@jcchost>

On Wed, 2008-09-17 at 21:20 +0000, Aaron Denney wrote:
> On 2008-09-17, Jonathan Cast  wrote:
> >> In my mind pooling vs new-creation is only relevant to process vs
> >> thread in the performance aspects.
> >
> > Say what?  This discussion is entirely about performance --- does
> > CPython actually have the ability to scale concurrent programs to
> > multiple processors?  The only reason you would ever want to do that is
> > for performance.
> 
> I entered the discussion as which model is a workaround for the other --

Well, I thought the discussion was about implementations, not models.  I
also assumed remarks would be made in the context of the entire thread.
I shall have to remember that in the future.

> someone said processes were a workaround for the lack of good threading
> in e.g. standard CPython.

> I replied that most languages thread support

Using a definition of `thread' which, apparantly, excludes Concurrent
Haskell.

> can be
> seen as a workaround for the poor performance of communicating processes.

Meaning kernel-switched processes.

> (creation in particular is usually cited, but that cost can often be reduced
> by process pools, context switching costs, alas, is harder.)
> 
> > Kernel threads /are/ expensive.  Which is why all the cool kids use
> > user-space threads.
> 
> Often muxed on top of kernel threads, because user-threads can't use
> multiple CPUs at once.

Well, a single kernel thread can't use multiple CPUs at once.  (So you
need more than one).

> >> The central aspect in my mind is a default share-everything, or
> >> default share-nothing.
> >
> > I really don't think you understand Concurrent Haskell, then.  (Or
> > Concurrent ML, or stackless Python, or libthread, or any other CSP-based
> > set-up).
> 
> Or Erlang, Occam, or heck, even jcsp.  Because I'm coming at this from a
> slightly different perspective

Different enough we're talking past each other.  The idea that the thing
you make with forkIO doesn't count as a thread never crossed my mind,
sorry.

> and place a different emphasis on things

and use completely different definitions for key terms and make
statements which, substituting in the definitions I was using, are (as I
hope you grant) non-sensical

> you think I don't understand?

Not any more.  I just think your definition of `thread' is unexpected in
this context (without rather more elaboration).

> No, trust me, I do understand them[1],
> and think CSP and actor models (the differences in nondeterminism is a
> minor detail that doesn't much matter here) are extremely nice ways of
> implementing parallel systems.

I'm glad to hear that...

> These are, in fact, process models.

OK.  I think that perspective is rather unique, but OK.

> They are implemented on top of thread models,
> but that's a performance hack.

Maybe.  It's done for performance, but I don't see why you call it a
hack.  Does it sacrifice some important advantage I'm missing?  (Vs.
kernel-scheduled threads).

> And while putting this model on top
> restores much of the programming sanity, in languages with mutable
> variables and references that can be passed, you still need a fair
> bit of discipline to keep that sanity.  There, the implementation detail
> of thread, rather than process allows and even encourages shortcuts that
> violate the process model.  In languages that are immutable, taking
> advantage of the shared memory space really can gain efficiency without
> any noticeably downside.

Nice clarification.[1]  Thanks.

jcc

[1] I am, btw., painfully aware that Haskell has mutable references that
can be passed between threads.  Just as I am painfully aware of Unix's,
um, interesting ideas on maintaining file system consistency in the
presence of concurrent access to *that* shared resource...


From briqueabraque at yahoo.com  Wed Sep 17 18:17:19 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Wed Sep 17 18:15:04 2008
Subject: [Haskell-cafe] Re: How to check if two Haskell files are the same?
In-Reply-To: 
References: 
	
Message-ID: 



Chadda? Fouch? a ?crit :
> 2008/9/16 Mauricio :
>> Hi,
>>
>> I would like to write a Haskell pretty-printer,
>> using standard libraries for that. How can I
>> check if the original and the pretty-printed
>> versions are the same? For instance, is there
>> a file generated by GHC at the compilation
>> pipe that is always guaranteed to have the
>> same MD5 hash when it comes from equivalent
>> source?
> 
> There is not, though I have a suggestion :
> Am I correct in assuming that you mean "equivalent source" in the
> sense that only the formatting (and eventually {;} as a layout format
> consequence) differs ?

Exactly! And with comments removed, since the last
time I checked Language.Haskell.* used not to preserve
that.

> 
> Then the sequence of tokens from the source ought to do the trick as
> long as you delete location information (map unLoc) and transform
> ITvocurly ("virtual" braces for layout induced blocks) into ITocurly
> (real braces for no-layout blocks) (and same for ITvccurly) (it's just
> another map). If only the formatting differs, those two should be
> identical.

Good idea. I think that's all that I need. I can write a
hash function that filters and transforms like that.

Thanks,
Maur?cio

From wnoise at ofb.net  Wed Sep 17 18:20:13 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Wed Sep 17 18:17:51 2008
Subject: [Haskell-cafe] Re: about openTempFile
References: <48D0F55A.8000801@libero.it>
	<37039AB0-F48C-43F3-A10F-60087814B88A@ece.cmu.edu>
Message-ID: 

On 2008-09-17, Brandon S. Allbery KF8NH  wrote:
> On 2008 Sep 17, at 8:17, Manlio Perillo wrote:
>> The Python tempfile module, as an example, implements a wrapper  
>> around mkstemp function that does exactly this, and the code is  
>> portable; on Windows it uses O_TEMPORARY_FILE flag, on POSIX systems  
>> the file is unlink-ed as soon as it is created (but note that the  
>> code is not signal safe - well, many functions in the Python  
>> standard library are not signal safe).
>>
>> There are reasons why GHC library does not implement this?
>
> POSIX doesn't guaranteed that open-and-unlink works; HP-UX is a  
> "POSIX" platform on which it doesn't.

Huh.  SuS does indeed allow EBUSY for "The file named by the path
argument cannot be unlinked because it is being used by the system or
another process and the implementation considers this an error."

Did HPUX's behavior change at some point?  This is a standard idiom,
and I don't remember having any trouble with it, but I haven't used
anything earlier than 9.  The manpages for 11 only document being a
mount point as cause for EBUSY.

-- 
Aaron Denney
-><-

From wnoise at ofb.net  Wed Sep 17 18:34:22 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Wed Sep 17 18:32:03 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	 <1221684120.18670.29.camel@jcchost>
	
	<28012bc60809171442r500ef533u294f74092581e17b@mail.gmail.com>
Message-ID: 

On 2008-09-17, Arnar Birgisson  wrote:
> Hi Aaron,
>
> On Wed, Sep 17, 2008 at 23:20, Aaron Denney  wrote:
>> I entered the discussion as which model is a workaround for the other
>> -- someone said processes were a workaround for the lack of good
>> threading in e.g. standard CPython.  I replied that most languages
>> thread support can be seen as a workaround for the poor performance
>> of communicating processes. (creation in particular is usually
>> cited, but that cost can often be reduced by process pools, context
>> switching costs, alas, is harder.)
>
> That someone was probably me, but this is not what I meant. I meant
> that the "processing" [1] Python module is a workaround for CPython's
> performance problems with threads.

Ah, on rereading that's much clearer.  Thank you for the clarification.

> The processes vs. threads depends on definitions. There seem to be two
> sets floating around here. One is that processes and threads are
> essentially the same, the only difference being that processes don't
> share memory but threads do. With this view it doesn't really matter
> if "processes" are implemented as proper OS processes or OS threads.
> Discussion based on this definition can be interesting and one model
> fits some problems better than the other and vice versa.
>
> The other one is the systems view of OS processes vs. OS threads.
> Discussion about the difference between these two is only mildly
> interesting imo, as I think most people agree on things here and they
> are well covered in textbooks that are old as dirt.

I think from the OS point of view, these two distinctions are nearly
equivalent.  There is only a difference when you start talking about
non-OS threads, such as those provided by various language runtimes.

>> There, the implementation detail of thread, rather than process
>> allows and even encourages shortcuts that violate the process model.
>
> Well, this is a viewpoint I don't totally agree with. Correct me if
> I'm not understanding you, but you seem to be making the point that
> OS processes are often preferred because with threads, you *can* get
> yourself in trouble by using shared memory.

That's exactly it.  Or rather, you can get in exactly as much trouble
with processes, but because accessing a variable in another memory space
is more cumbersome, you have to actually think when you do so.  Looking
at all uses of "a = b" to see what invariants might be broken is unfeasible.
Looking at all requests for updating a remote variable might be
manageable.

-- 
Aaron Denney
-><-

From manlio_perillo at libero.it  Wed Sep 17 18:37:06 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 18:34:35 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big	advantages?
In-Reply-To: <1221678201.18670.12.camel@jcchost>
References: <20080917053300.GC2213@scytale.galois.com>	<48D0FEF5.5080707@libero.it>	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>	
	<1221678201.18670.12.camel@jcchost>
Message-ID: <48D18692.6010002@libero.it>

Jonathan Cast ha scritto:
> [...]
>> Huh.  I see multi-threading as a workaround for expensive processes,
>> which can explicitly use shared memory when that makes sense.
> 
> That breaks down when you want 1000s of threads.  I'm not aware of any
> program, on any system, that spawns a new process on each event it wants
> to handle concurrently; 

thttpd spawn a new process for every CGI request or directory listing.
Many "old" server don't use a prefork model.

Another interesting example for bad threads usage is Azureus (a 
BitTorrent client written in Java): it creates about 70 threads for who 
know what reasons (and it also allocate about one half of available 
virtual memory).

 > [...]


Manlio Perillo
From donn at avvanta.com  Wed Sep 17 18:42:25 2008
From: donn at avvanta.com (Donn Cave)
Date: Wed Sep 17 18:39:51 2008
Subject: [Haskell-cafe] Re: Python's big challenges, Haskell's big
	advantages?
Message-ID: <20080917224225.D8CB7F3940@mail.avvanta.com>

Quoth Jonathan Cast :
...
| Say what?  This discussion is entirely about performance --- does
| CPython actually have the ability to scale concurrent programs to
| multiple processors?

Well, ostensibly the discussion also has something to do with Haskell.
On that premise, may I say I hope we're not inspired by Python's example
to treat concurrency as a religious matter.

The C Python community is forced to take the position that interpreter-
level threading is not worth the price, because they don't have it and
can't conveniently get it.  I doubt we'll ever know for sure whether
they're right or wrong, since Python comes with other issues that could
also take blame or credit for its success at large scale applications.

The Haskell community seems to be convinced as a whole that user-level
threads are the way to go, but at most that's just a majority, not a
consensus.  Who cares!?  Given the ability to take either path, Haskell
programmers will solve our religious argument - we'll know who gets to
heaven with working, high performance, reliable applications.

That is, assuming that programmers of each persuasion can find Haskell
suited to their model.  As far as I know, though, that isn't a really
sure thing.  I've read things like "thread RTS can't/shouldn't support fork"
and "would like to be able to get rid of the non-threaded RTS", with
respect to GHC.

At least until there is more empirical evidence that it's a waste of time,
Haskell implementations should leave this to the programmer - support
processes, OS threads, or user threads without undue work-around burdens.
Otherwise we'll be stuck like the Python community is, defending this
approach as a religious argument.  We have enough of those already.

	Donn Cave, donn@avvanta.com
From manlio_perillo at libero.it  Wed Sep 17 18:42:43 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed Sep 17 18:40:20 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: 
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<4165d3a70809170612u68159c8aj7d317cbb0a0ecb01@mail.gmail.com>
	<48D1063C.7060401@libero.it>
	
Message-ID: <48D187E3.4060206@libero.it>

Tony Finch ha scritto:
> [...]
>>> context switching times,
>> That's probabily the same as thread switching time.
> 
> Competent language-level concurrency support (as in Haskell and Erlang)
> makes a context switch about as expensive as a function call, thousands of
> times faster than an OS-level process switch.
> 

I know.
But when using the term "thread" one usually assume kernel thread.

Of course if we talk about user threads it's a whole new story.

> Tony.


Manlio Perillo
From ok at cs.otago.ac.nz  Wed Sep 17 19:02:17 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Wed Sep 17 18:59:45 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <13905_1221664844_m8HFKf4q019306_gar775$2ng$1@ger.gmane.org>
References:  <48D0275A.703@jellybean.co.uk>
	<13905_1221664844_m8HFKf4q019306_gar775$2ng$1@ger.gmane.org>
Message-ID: <06F34CAF-8D94-435E-A49F-6ED23D1B8587@cs.otago.ac.nz>


On 18 Sep 2008, at 3:20 am, Mauricio wrote:
> Agree about the answer, not about the question. The
> correct one would be "is it possible to change haskell
> syntax to support the international notation (not any
> locally sensitive one) for decimal real numbers? Would
> a change in 'read' be a good first step?"

For some sense of "possible", the answer is clearly yes.
However, it is perhaps misleading to call commas
"THE international notation".  The plain fact of the
matter is that whatever any standards body may say,
there are MANY notations for numbers.  You might as
well ask "is it possible to change Haskell syntax to
support only the *real* Arabic digits ... for ...
numbers".  The Arabic script is used in many countries,
so it's international.  I don't read Arabic letters at
all, but to me numbers written in Arabic script are no
weirder than numbers using commas instead of dots.

I would draw readers' attention to
http://engineers.ihs.com/news/2006/nist-decimal-international.htm
which says that
(1) China, India, and Japan use decimal points, not commas.
(2) There was a resolution of the CGPM in 2003
     "endorsing the use of the point on the line as a decimal sign".
(3) In June 2006, ISO agreed to allow the use of dots as decimal
     points in international standards.

As it happens, the decimal point character I greatly prefer is
the traditional British raised dot, but I can live with a low dot.

I am 100% behind internationalised input and output,
but allowing commas in numbers inside programming languages
that already use commas for other purposes is, let's be polite,
not a terribly good idea.  You could probably get away with it
in Lisp, but how many numbers are there in (1,2,3)?

One thing that definitely is missing from Haskell numbers, and
which I greatly miss, is a "thousands separator".  Ada got around
the dot/comma/apostrophe/whatever issue for thousands separators
by using the underscore.  For an unsigned decimal integer,
this means allowing [0-9](_?[0-9])* instead of [0-9]+.  It works
really well, despite not being ANYBODY's cultural convention.

>
>
> I know this looks difficult, but I'm sure it deserves at
> least some thinking. We have previous examples for
> less important issues: ghc does accept Windows end
> of line conventions, the minus and sign needs special
> syntax, and '.' can be used as decimal separator even
> if it's use as function notation.
>
> Best,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> ====================================================================
>                    Auto Generated Mail  
> Footer                         If this email is requesting your  
> password then it is a HOAX.
>                    DO NOT reply to the email.
>                   Validate this footer at the
> Otago University web site keyword search: information security phish
> ====================================================================
>
>
>

--
If stupidity were a crime, who'd 'scape hanging?







From allbery at ece.cmu.edu  Wed Sep 17 19:05:37 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Wed Sep 17 19:03:03 2008
Subject: [Haskell-cafe] Re: about openTempFile
In-Reply-To: 
References: <48D0F55A.8000801@libero.it>
	<37039AB0-F48C-43F3-A10F-60087814B88A@ece.cmu.edu>
	
Message-ID: 

On 2008 Sep 17, at 18:20, Aaron Denney wrote:
> On 2008-09-17, Brandon S. Allbery KF8NH  wrote:
>> On 2008 Sep 17, at 8:17, Manlio Perillo wrote:
>>> The Python tempfile module, as an example, implements a wrapper
>>> around mkstemp function that does exactly this, and the code is
>>> portable; on Windows it uses O_TEMPORARY_FILE flag, on POSIX systems
>>> the file is unlink-ed as soon as it is created (but note that the
>>> code is not signal safe - well, many functions in the Python
>>> standard library are not signal safe).
>>>
>>> There are reasons why GHC library does not implement this?
>>
>> POSIX doesn't guaranteed that open-and-unlink works; HP-UX is a
>> "POSIX" platform on which it doesn't.
>
> Did HPUX's behavior change at some point?  This is a standard idiom,
> and I don't remember having any trouble with it, but I haven't used
> anything earlier than 9.  The manpages for 11 only document being a
> mount point as cause for EBUSY.

It may have but I recall it being cited as an issue with HP/UX 9 and 10.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From wnoise at ofb.net  Wed Sep 17 19:08:46 2008
From: wnoise at ofb.net (Aaron Denney)
Date: Wed Sep 17 19:06:27 2008
Subject: [Haskell-cafe] Re: Threads vs. processes [Was: Re: Re: Python's big
 challenges, Haskell's big advantages?]
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	 <1221684120.18670.29.camel@jcchost>
	 <1221688255.18670.70.camel@jcchost>
Message-ID: 

On 2008-09-17, Jonathan Cast  wrote:
> On Wed, 2008-09-17 at 21:20 +0000, Aaron Denney wrote:
>> On 2008-09-17, Jonathan Cast  wrote:
>> >> In my mind pooling vs new-creation is only relevant to process vs
>> >> thread in the performance aspects.
>> >
>> > Say what?  This discussion is entirely about performance --- does
>> > CPython actually have the ability to scale concurrent programs to
>> > multiple processors?  The only reason you would ever want to do that is
>> > for performance.
>> 
>> I entered the discussion as which model is a workaround for the other --
>
> Well, I thought the discussion was about implementations, not models.  I
> also assumed remarks would be made in the context of the entire thread.
> I shall have to remember that in the future.
>
>> someone said processes were a workaround for the lack of good threading
>> in e.g. standard CPython.
>
>> I replied that most languages thread support
>
> Using a definition of `thread' which, apparantly, excludes Concurrent
> Haskell.

Can't I exclude it based on "most languages'".  CSP models are still the
minority.

> Different enough we're talking past each other.  The idea that the thing
> you make with forkIO doesn't count as a thread never crossed my mind,
> sorry.

I think it's fair to consider it a thread interface, because there's
still a huge amount of shared state.  Mostly immutable, but not
completely as you later point out, even discounting updates of
lazy-evaluation thunks.  It is a lot less pure CSP than Erlang and
Occam, which both call them processes (though I see "thread" being
used more and more these days for Erlang).  Then there's apparently a
tradition in mainstream languages of calling language-level parallelism
"threads".  Of course most are thread models.

> and use completely different definitions for key terms and make
> statements which, substituting in the definitions I was using, are (as
> I hope you grant) non-sensical

Yes, I can see how my rants sounded bizarre, even though I think we're
mostly in agreement.

> Not any more.  I just think your definition of `thread' is unexpected in
> this context (without rather more elaboration).

>> These are, in fact, process models.
>
> OK.  I think that perspective is rather unique, but OK.

Well, what's the P in CSP stand for?

>> They are implemented on top of thread models,
>> but that's a performance hack.
>
> Maybe.  It's done for performance, but I don't see why you call it a
> hack.  Does it sacrifice some important advantage I'm missing?  (Vs.
> kernel-scheduled threads).

Vs kernel threads, not much -- just parallelism on SMP systems, which is
often regained by muxing on top of kernel threads.

Vs kernel processes, yes, I think some is lost.  Privilege separation,
isolation in the event of crashes, larger memory spaces, the ability
to span multiple machines (necessary for true fault tolerance).  How
important are these vs raw speed?  Well, it depends on the domain
and problem.  Take postfix for instance -- different parts of postfix are
implemented in different processes, with different OS privileges.
Subverting one doesn't give you carte blanche with the others, as it
would if these were all threads in one process.

-- 
Aaron Denney
-><-

From jason.dusek at gmail.com  Wed Sep 17 20:17:31 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Wed Sep 17 20:14:57 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <20080917053300.GC2213@scytale.galois.com>
References: <20080917053300.GC2213@scytale.galois.com>
Message-ID: <42784f260809171717q418edc00ob2e4c82c5e67b2e5@mail.gmail.com>

  What does Haskell have to say about cloud computing?

--
_jsn
From jason.dusek at gmail.com  Wed Sep 17 20:17:46 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Wed Sep 17 20:15:12 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <14e7a2380809170603j7f1c57f6vcdda2f44e8827930@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<14e7a2380809170603j7f1c57f6vcdda2f44e8827930@mail.gmail.com>
Message-ID: <42784f260809171717n5e3f0410j683063f956179864@mail.gmail.com>

Bruce Eckel  wrote:
> Manlio Perillo  wrote:
> > Multicore support is already "supported" in Python, if you
> > use multiprocessing, instead of multithreading.
>
> This is one of the reasons for my other question on this list,
> about whether you can solve all problems using multiple
> isolated processes with message passing.

  What did you get out of that, by the way?

--
_jsn
From dons at galois.com  Wed Sep 17 20:24:48 2008
From: dons at galois.com (Don Stewart)
Date: Wed Sep 17 20:22:05 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <42784f260809171717q418edc00ob2e4c82c5e67b2e5@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<42784f260809171717q418edc00ob2e4c82c5e67b2e5@mail.gmail.com>
Message-ID: <20080918002448.GH5645@scytale.galois.com>

jason.dusek:
>   What does Haskell have to say about cloud computing?

I'm not sure cloud computing is well-enough defined to say anything yet.

    "paradigm in which information is permanently stored in servers on
    the Internet and cached temporarily on clients that include
    desktops, entertainment centers, table computers, notebooks, wall
    computers, handhelds, etc."

So we're talking about JSON, online db services like Amazon bindings,
HAppS nodes, et al. For which Haskell's perfectly able. Now, maybe
there's some nice abstractions waiting to be found though..

-- Don
From marco-oweber at gmx.de  Wed Sep 17 20:51:48 2008
From: marco-oweber at gmx.de (Marc Weber)
Date: Wed Sep 17 20:49:15 2008
Subject: [Haskell-cafe] Exceptions
In-Reply-To: <674EFCEB-35A8-4DFF-88DC-A9E42FA6FADC@inf.fu-berlin.de>
References: <674EFCEB-35A8-4DFF-88DC-A9E42FA6FADC@inf.fu-berlin.de>
Message-ID: <20080918005148.GD25870@gmx.de>

On Sun, Jul 27, 2008 at 07:23:14PM +0200, Adrian Neumann wrote:
>  Hello,
> 
>  I think it'd be nice if the compiler could warn me if there are any 
>  exceptions which I'm not catching, similar to checked exceptions in Java. 
>  Does anyone know of a possibility to do that in Haskell?

He, I have found a use case for your request:
from network

inet_addr :: String -> IO HostAddress
inet_addr ipstr = do
   withCString ipstr $ \str -> do
   had <- c_inet_addr str
   if had == -1
    then ioError (userError ("inet_addr: Malformed address: " ++ ipstr))
    else return had  -- network byte order


from HAppS-Server:

host <- Exception.catch (inet_addr uri)    -- handles ascii IP numbers
       (\_ -> getHostByName uri >>= \host ->
            case hostAddresses host of
                [] -> return (error "no addresses in host entry")
                (h:_) -> return h)

Very bad because this catches Exceptions thrown by trowTo as well,
doesn't it?

On the other hand just catching the UserError can be useless if the
maintainers decide to throw a custom Exception in the future (which can
and should be done in the future when extensible exceptions are standard?)

In this case I would miss this update and miss to update the code. If we
could only catch exceptions.
Using Either would be another choice here. But it would lead to much
more code.

Anyway It think using Either is better because it can't lead to code as
shown above.

Another nice use case for Exceptions are timouts as implemented by HAppS
as well.
However I must conclude that a function call including the code above
can just absorb my exception and rethrow another one (or in a worse case
continue?) So maybe I have to change the TimOut code to do a
forever (throwTo threadId TimOutException) to make sure it quits as fast
as possible? This could lead to different trouble.

So I think using Either is the best option although there is some more
code to write.

Marc Weber
From thomas.dubuisson at gmail.com  Thu Sep 18 00:33:09 2008
From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson)
Date: Wed Sep 17 21:30:42 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <42784f260809171717q418edc00ob2e4c82c5e67b2e5@mail.gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<42784f260809171717q418edc00ob2e4c82c5e67b2e5@mail.gmail.com>
Message-ID: <1221712389.3497.22.camel@myhost>

jason.dusek:
>   What does Haskell have to say about cloud computing?

If by 'cloud computing' you wish to discuss mapReduce then:
http://www.cs.vu.nl/~ralf/MapReduce/paper.pdf

Map reduce in Haskell, enjoy!

Tom

From ok at cs.otago.ac.nz  Wed Sep 17 22:00:10 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Wed Sep 17 21:58:01 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big advantages?
In-Reply-To: <5951_1221693246_m8HNE48v006818_20080917224225.D8CB7F3940@mail.avvanta.com>
References: <5951_1221693246_m8HNE48v006818_20080917224225.D8CB7F3940@mail.avvanta.com>
Message-ID: <82D1FB8A-C348-4EE9-AC2C-DF9331C6441F@cs.otago.ac.nz>

It may be of interest that although Erlang has been doing
lightweight concurrency for >20 years,
  - you can choose whether you want to use an SMP version that
    has as many schedulers as there are cores (plus internal
    locking as needed) or a non-SMP version with one scheduler
    (and no internal locking); both versions are standard and
    it's only a performance issue, not a semantics issue
  - performance sometimes goes one way, sometimes the other
  - there was a "one UNIX process per Erlang process"
    implementation; I have a copy.  The community interest in
    it was, shall we say, massively underwhelming.

It might also be interesting to note that the experimental
operating system K42 from IBM does _all_ user-visible
threading in user-land.  This includes thread switching and
even I/O blocking and unblocking; all done in user-land.

I don't think we've begun to explore all the options yet.

From lchangying at gmail.com  Wed Sep 17 22:00:37 2008
From: lchangying at gmail.com (Changying Li)
Date: Wed Sep 17 22:02:42 2008
Subject: [Haskell-cafe] Re: a question about Database.HDBC.ODBC
References: <87bpympxw2.fsf@gmail.com>
	<1221679058.4489.9.camel@localhost.localdomain>
Message-ID: <873ajyp60q.fsf@gmail.com>

thanks for your reply.
I'm sure isql is ok for me:

[chylli@arch tapl-haskell] isql test
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL>  show processlist;
+---------------------+------+----------------------+----------------------+--------+------------+-----------+----------------------------------+
| Id                  | User | Host                 | db                   | Command| Time       | State     | Info                             |
+---------------------+------+----------------------+----------------------+--------+------------+-----------+----------------------------------+
| 1                   | root | localhost            | test                 | Query  | 0          |           | show processlist                 |
+---------------------+------+----------------------+----------------------+--------+------------+-----------+----------------------------------+
SQLRowCount returns 1
1 rows fetched



I'm not sure where is the problem.
another problem is, the isql is not read configuration in ~/.dbic



Mads Lindstr?m  writes:

> Hi,
>
> Changying Li wrote:
>> I want to use hdbc to connect my mysql test db. so I set up my
>> /etc/odbcinst.ini :
>> [MySQL]
>> Description     = ODBC Driver for MySQL
>> Driver          = /usr/lib/libmyodbc.so
>> Setup           = /usr/lib/libodbcmyS.so
>> FileUsage       = 1
>> 
>> and /etc/odbc.ini:
>> [test]
>> Description     = MySQL database test
>> Driver          = MySQL
>> Server          = localhost
>> Database        = test
>> Port            = 3306
>> User            = root
>> Socket          = /tmp/mysql.sock
>> Option          =
>> Stmt            =
>> 
>> user chylli@localhost must use password to connect mysql. other users needn't.
>> I connect db like this:
>> Prelude Database.HDBC.ODBC Database.HDBC> handleSqlError (connectODBC "DSN=test")
>> *** Exception: user error (SQL error: SqlError {seState = "[\"HY000\"]", seNativeError = -1, seErrorMsg = "connectODBC/sqlDriverConnect: [\"1045: [unixODBC][MySQL][ODBC 3.51 Driver]Access denied for user 'chylli'@'localhost' (using password: NO)\"]"})
>> Prelude Database.HDBC.ODBC Database.HDBC> handleSqlError (connectODBC "DSN=test;UID=chylli")
>> Prelude Database.HDBC.ODBC Database.HDBC> 
>> 
>> in another term:
>> mysql> show processlist;
>> +----+-------------+-----------+------+---------+------+-------+------------------+
>> | Id | User        | Host      | db   | Command | Time | State | Info             |
>> +----+-------------+-----------+------+---------+------+-------+------------------+
>> | 31 | chylli?? | localhost | test | Sleep   | 1483 |       | NULL             | 
>> | 43 | root        | localhost | test | Sleep   |  116 |       | NULL             | 
>> 
>> my question is:
>> 1. why not HDBC.ODBC use configuration in /etc/odbc.ini ? if is use,
>> then connectODBC "DSN=test" should use root as user without password and
>> it should succeed.
>
> Are you sure it is a HDBC and not a ODBC-library problem? It seems that
> you use unixODBC and can then try the command:
>
>   isql test
>
> which will connect though unixODBC without involving HDBC. If you still
> have the same problems, then it must be unrelated to HDBC.
>
>> 
>> 2. when using UID=chylli, why the user in 'show processlist' is not
>> chylli but 'chylli??' ?  if it use account 'chylli', that connection
>> should fail. but in fact it succeed !!!
>> 
>> 
>> 
>
> Greetings,
>
> Mads Lindstr?m

-- 

Thanks & Regards

Changying Li

From jason.dusek at gmail.com  Wed Sep 17 23:14:09 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Wed Sep 17 23:11:34 2008
Subject: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
In-Reply-To: <20080918002448.GH5645@scytale.galois.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<42784f260809171717q418edc00ob2e4c82c5e67b2e5@mail.gmail.com>
	<20080918002448.GH5645@scytale.galois.com>
Message-ID: <42784f260809172014s23ba0d29h816072b11f377782@mail.gmail.com>

Don Stewart  wrote:
> jason.dusek:
> > What does Haskell have to say about cloud computing?
>
> I'm not sure cloud computing is well-enough defined to say
> anything yet.

  That is fair -- having something to say about cloud computing
  is essentially having a grand vision. I only ask because it
  was touched on in the original message.

> ...we're talking about JSON, online db services like Amazon
> bindings, HAppS nodes, et al. For which Haskell's perfectly
> able.

  Do HAppS nodes really function as nodes in a larger system?
  Does HAppS function as a "cluster application server"?

> Now, maybe there's some nice abstractions waiting to be
> found though...

  Conventionally, it is argued that the abstraction of choice is
  message passing; but that isn't going to take you anywhere
  near having a web page that people can see twice without some
  more abstraction.

  I would like to say that distributed version control is that
  abstraction -- that branches with a main trunk are a model for
  resources that is compatible with dirty-write as well as
  consistent read. However, as systems become more desirable
  from a maintenance point of view -- self-healing, easily
  expandable, fault tolerant -- it becomes ever more difficult
  to get the transactionality you need to have a main trunk.

--
_jsn
From alfonso.acosta at gmail.com  Wed Sep 17 23:18:44 2008
From: alfonso.acosta at gmail.com (Alfonso Acosta)
Date: Wed Sep 17 23:16:08 2008
Subject: [Haskell-cafe] ANN: pandoc 1.0.0.1
In-Reply-To: <20080914012909.GA16164@berkeley.edu>
References: <20080914012909.GA16164@berkeley.edu>
Message-ID: <6a7c66fc0809172018j7100c7d4oe4edd79daf8c7006@mail.gmail.com>

On Sun, Sep 14, 2008 at 3:29 AM, John MacFarlane  wrote:
> Some highlights of this release:
>
> + New GNU Texinfo writer (contributed by Peter Wang)
> + New OpenDocument XML writer (contributed by Andrea Rossato)
> + New ODT (OpenOffice document) writer
> + New MediaWiki markup writer

I can't wait for a:

+ New Docbook markup reader

The reason being, I would kill for a good Docbook-to-LaTeX translator
(or a good set of Docbook-to-TeXML XSLT stylesheets):

 * Most of the opensource XSL-FO tools out there (fop, xmlroff et all)
are immature or do a poor typesetting job [1].

 * The other LaTeX-based solutions seem to be broken and/or
unmaintained (http://db2latex.sourceforge.net,
http://dblatex.sourceforge.net/ ...)

A good post on the topic:

http://uucode.com/blog/2007/02/23/general-questions-about-docbook-latex/


[1] I wanted to show how bad the PDF version of the GHC manual looks
(at least the one generated by fop), but all the PDF links from GHC's
page seem to be broken at the moment.
From DekuDekuplex at Yahoo.com  Thu Sep 18 00:32:42 2008
From: DekuDekuplex at Yahoo.com (Benjamin L.Russell)
Date: Thu Sep 18 00:30:29 2008
Subject: [Haskell-cafe] Re: Haskell Weekly News: Issue 85 - September 13,
	2008
References: <20080913230727.GA31569@seas.upenn.edu>
	
Message-ID: <2bl3d45ef13i0t4ji0m7lbfbg81q113gka@4ax.com>

On Sat, 13 Sep 2008 21:06:21 -0700, "Daryoush Mehrtash"
 wrote:

>I have a newbie question....  Does theorem proofs have a use for an
>application?  Take for example the IRC bot example (
>http://www.haskell.org/haskellwiki/Roll_your_own_IRC_bot)  listed below.  Is
>there any insight to be gained by theorem proofs (as in COQ) into the app?

Yes.

Basically, if you can prove that the program is correct, then you
don't need to test it.  While proofs can become very tedious for huge
programs with many different kinds of control flow involving very
complicated logic, if the program size can be shortened to a
reasonable size, then proofs can help shorten development time.

This was actually part of the motivation for developing Haskell as a
pure functional programming language (i.e., one that prohibits side
effects -- see
http://www.haskell.org/haskellwiki/Functional_programming).  It is
generally easier to write proofs for pure functional programming
languages than for impure ones.

Theorem provers help to automate the process of writing proofs for
programs.

Djinn (see http://lambda-the-ultimate.org/node/1178) is an example of
a theorem prover for Haskell.  Given a (Haskell function), it returns
a function of that type if one exists.  Here is a sample Djinn session
(courtesy of http://lambda-the-ultimate.org/node/1178):

>   calvin% djinn
>   Welcome to Djinn version 2005-12-11.
>   Type :h to get help.
># Djinn is interactive if not given any arguments.
># Let's see if it can find the identity function.
>   Djinn> f ? a->a
>   f :: a -> a
>   f x1 = x1
># Yes, that was easy.  Let's try some tuple munging.
>   Djinn> sel ? ((a,b),(c,d)) -> (b,c)
>   sel :: ((a, b), (c, d)) -> (b, c)
>   sel ((_, v5), (v6, _)) = (v5, v6)
>
># We can ask for the impossible, but then we get what we
># deserve.
>   Djinn> cast ? a->b
>   -- cast cannot be realized.
>
># OK, let's be bold and try some functions that are tricky to write:
># return, bind, and callCC in the continuation monad
>   Djinn> type C a = (a -> r) -> r
>   Djinn> returnC ? a -> C a
>   returnC :: a -> C a
>   returnC x1 x2 = x2 x1
>
>   Djinn> bindC ? C a -> (a -> C b) -> C b
>   bindC :: C a -> (a -> C b) -> C b
>   bindC x1 x2 x3 = x1 (\ c15 -> x2 c15 (\ c17 -> x3 c17))
>
>   Djinn> callCC ? ((a -> C b) -> C a) -> C a
>   callCC :: ((a -> C b) -> C a) -> C a
>   callCC x1 x2 = x1 (\ c15 _ -> x2 c15) (\ c11 -> x2 c11)
># Well, poor Djinn has a sweaty brow after deducing the code
># for callCC so we had better quit.
>   Djinn> :q
>   Bye.

Other theorem provers include COQ (see http://coq.inria.fr/) and
Sparkle (see http://www.cs.ru.nl/Sparkle/) (a theorem prover for the
alternative non-strict, purely function programming language Clean
(see http://clean.cs.ru.nl/)).

-- Benjamin L. Russell

From ryani.spam at gmail.com  Thu Sep 18 00:54:13 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Thu Sep 18 00:51:36 2008
Subject: [Haskell-cafe] Exceptions
In-Reply-To: <20080918005148.GD25870@gmx.de>
References: <674EFCEB-35A8-4DFF-88DC-A9E42FA6FADC@inf.fu-berlin.de>
	<20080918005148.GD25870@gmx.de>
Message-ID: <2f9b2d30809172154o65a9156ahae92571ffbbb3c40@mail.gmail.com>

Better is this:

data MalformedAddressException = MalformedAddressException String
deriving (Show, Typeable)

throwDynIO x = throwIO (DynException $ toDyn x)

-- in inet_error
... throwDynIO (MalformedAddressException "blah blah") ...

-- in HAppS-Server
... Exception.catchDyn (inet_addr uri) (\(MalformedAddressException s) -> ...)

  -- ryan

On Wed, Sep 17, 2008 at 5:51 PM, Marc Weber  wrote:
> On Sun, Jul 27, 2008 at 07:23:14PM +0200, Adrian Neumann wrote:
>>  Hello,
>>
>>  I think it'd be nice if the compiler could warn me if there are any
>>  exceptions which I'm not catching, similar to checked exceptions in Java.
>>  Does anyone know of a possibility to do that in Haskell?
>
> He, I have found a use case for your request:
> from network
>
> inet_addr :: String -> IO HostAddress
> inet_addr ipstr = do
>   withCString ipstr $ \str -> do
>   had <- c_inet_addr str
>   if had == -1
>    then ioError (userError ("inet_addr: Malformed address: " ++ ipstr))
>    else return had  -- network byte order
>
>
> from HAppS-Server:
>
> host <- Exception.catch (inet_addr uri)    -- handles ascii IP numbers
>       (\_ -> getHostByName uri >>= \host ->
>            case hostAddresses host of
>                [] -> return (error "no addresses in host entry")
>                (h:_) -> return h)
>
> Very bad because this catches Exceptions thrown by trowTo as well,
> doesn't it?
>
> On the other hand just catching the UserError can be useless if the
> maintainers decide to throw a custom Exception in the future (which can
> and should be done in the future when extensible exceptions are standard?)
>
> In this case I would miss this update and miss to update the code. If we
> could only catch exceptions.
> Using Either would be another choice here. But it would lead to much
> more code.
>
> Anyway It think using Either is better because it can't lead to code as
> shown above.
>
> Another nice use case for Exceptions are timouts as implemented by HAppS
> as well.
> However I must conclude that a function call including the code above
> can just absorb my exception and rethrow another one (or in a worse case
> continue?) So maybe I have to change the TimOut code to do a
> forever (throwTo threadId TimOutException) to make sure it quits as fast
> as possible? This could lead to different trouble.
>
> So I think using Either is the best option although there is some more
> code to write.
>
> Marc Weber
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From titto at quicquid.org  Thu Sep 18 02:05:25 2008
From: titto at quicquid.org (Titto Assini)
Date: Thu Sep 18 02:02:48 2008
Subject: [Haskell-cafe] Ajax-Haskell framework?
In-Reply-To: <5de3f5ca0809171446mea592ebxad922add0e41935b@mail.gmail.com>
References: <5de3f5ca0809171446mea592ebxad922add0e41935b@mail.gmail.com>
Message-ID: <2d34474e0809172305y234a901fv876fd54a012b4e75@mail.gmail.com>

Hi Greg,

have a look at: http://www.haskell.org/haskellwiki/Hajax

Best,

     titto

2008/9/17 Greg Meredith :
> Haskellians,
>
> Is there an Ajax-Haskell framework? In case there are many, is there a
> preferred one? Experiences people would like to share?
>
> Best wishes,
>
> --greg
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 806 55th St NE
> Seattle, WA 98105
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>



-- 
Pasqualino "Titto" Assini, Ph.D.
25 Heath Road - CO79PT
Wivenhoe - Colchester - U.K.
From dons at galois.com  Thu Sep 18 02:11:17 2008
From: dons at galois.com (Don Stewart)
Date: Thu Sep 18 02:08:36 2008
Subject: [Haskell-cafe] Ajax-Haskell framework?
In-Reply-To: <2d34474e0809172305y234a901fv876fd54a012b4e75@mail.gmail.com>
References: <5de3f5ca0809171446mea592ebxad922add0e41935b@mail.gmail.com>
	<2d34474e0809172305y234a901fv876fd54a012b4e75@mail.gmail.com>
Message-ID: <20080918061117.GA6769@scytale.galois.com>

Something like what Hayoo uses?

    http://holumbus.fh-wedel.de/hayoo/hayoo.html

Lots of async stuff, JS and server chatter?

-- Don


titto:
> Hi Greg,
> 
> have a look at: http://www.haskell.org/haskellwiki/Hajax
> 
> Best,
> 
>      titto
> 
> 2008/9/17 Greg Meredith :
> > Haskellians,
> >
> > Is there an Ajax-Haskell framework? In case there are many, is there a
> > preferred one? Experiences people would like to share?
> >
> > Best wishes,
> >
> > --greg
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 806 55th St NE
> > Seattle, WA 98105
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> 
> 
> 
> -- 
> Pasqualino "Titto" Assini, Ph.D.
> 25 Heath Road - CO79PT
> Wivenhoe - Colchester - U.K.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From kowey at darcs.net  Thu Sep 18 02:15:58 2008
From: kowey at darcs.net (Eric Kow)
Date: Thu Sep 18 02:13:26 2008
Subject: [Haskell-cafe] announcing darcs 2.0.3pre1
Message-ID: <20080918061558.GZ41629@Macintosh.local>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/6314b446/attachment.bin
From vlm at lionet.info  Thu Sep 18 02:23:24 2008
From: vlm at lionet.info (Lev Walkin)
Date: Thu Sep 18 02:20:59 2008
Subject: [Haskell-cafe] XML (HXML) parsing :: GHC 6.8.3 space leak from 2000
Message-ID: <48D1F3DC.9040903@lionet.info>


Recently I had to process some multi-megabyte XML files. Tried a few
Haskell XML parsers (HaXML, HXT, HXML) but all of them were exhibiting
very pronounced space leaks, and all but HXML were too strict for my
input. Judging by the code and stated objectives, Joe English's HXML
(0.2, circa 2003) looked more promising for hacking around so I tried
to figure out the space leak problem.

It wasn't too long to find out the source of a problem, the buildTree
function in TreeBuild.hs. In fact, the very annotation to that function
reads as follows:

-- %%% There is apparently a space leak here, but I can't find it.
-- %%% Update 28 Feb 2000: There is a leak, but it's fixed
-- %%% by a well-known GC implementation technique.  Hugs 98 happens
-- %%% not to implement this technique, but STG Hugs (and most other
-- %%% Haskell systems) do implement it.
-- %%% Thanks to Simon Peyton-Jones, Malcolm Wallace, Colin Runcinman
-- %%% Mark Jones, and others for investigating this.

And there's some more in the accompanying documentation:

     + Under Hugs 98 only, suffers a serious space fault.

I wondered why would a contemporary GHC 6.8.3 exhibit such a leak?
After all, the technique was known in 2000 (and afir by Wadler in '87)
and one would assume Joe English's reference to "most other Haskell
systems" ought to mean GHC.

But here we are, in 2008 I still can't get HXML to not to leak like
a hose while lazily parsing my file. In fact, I can't get my 45-megabyte
file parsed on my 1GB RAM system without swapping.

So I went ahead and extracted the code and stripped all XML related
junk to reproduce the problem with a minimal test case. Attached please
find a single tree.hs module which is just sufficient to demonstrate a
memory leak. Here's a culprit function:

	data TreeEvent =
		Start String	-- Branch off a new subtree
		| Stop		-- Stop branching and return 1 level
		| Leaf String	-- A simple leaf without children
		deriving Show

	-- Lazily build a tree out of a sequence of tree-building events
	build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String])
	build (Start str : es) =
	        let (es', subnodes) = build es
	            (spill, siblings) = build es'
	        in (spill, (Tree str subnodes : siblings))
	build (Leaf str : es) =
	        let (spill, siblings) = build es
	        in (spill, Tree str [] : siblings)
	build (Stop : es) = (es, [])
	build [] = ([], [])

In fact, the attached module implements almost verbatim the code from
an old Joe's request (circa 2000):
	http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg06086.html
but my version is a bit more self-sufficient for the new folks who'd
like to quickly test it on their system.

Am I really ignorant of some important GHC optimization options
(tried -O2/-O3), or is this indeed a serious problem to tackle?

-- 
Lev Walkin
vlm@lionet.info
-------------- next part --------------
module Main where

-- A simple tree to hold hierarchial XML-like data structure

data Tree a = Tree a [Tree a] deriving Show

-- A member of the event sequence which attempts to build a tree.
-- For example, the following sequence
--     [Start "top", Leaf "leaf", Start "sub", Stop, Stop]
-- should correspond to the following tree:
--     Tree "top" [Tree "leaf" [], Tree "sub" []]

data TreeEvent = Start String	-- Branch off a new subtree
		| Stop		-- Stop branching and return 1 level
		| Leaf String	-- A simple leaf without children
		deriving Show

-- Lazy printing of an infinite tree building process

main = print . snd . build $ Start "top" : cycle [Leaf "sub"]

-- Convert a stream of tree building events
-- into a list of unconsumed events and a constructed tree body.

type UnconsumedEvent = TreeEvent	-- Alias for program documentation

build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String])
build (Start str : es) =
	let (es', subnodes) = build es
	    (spill, siblings) = build es'
        in (spill, (Tree str subnodes : siblings))
build (Leaf str : es) =
        let (spill, siblings) = build es
        in (spill, Tree str [] : siblings)
build (Stop : es) = (es, [])
build [] = ([], [])

-- Stricter version of build, never terminates on infinite input,
-- but exhibits no space leaks whatsoever.
build' f (Start str : es) =
	let (es', subnodes) = build' id es
	in build' ((Tree str subnodes) :) es'
build' f (Leaf str : es) = build' ((Tree str []) :) es
build' f (Stop : es) = (es, f [])
build' f [] = ([], f [])
From gour at mail.inet.hr  Thu Sep 18 02:47:10 2008
From: gour at mail.inet.hr (Gour)
Date: Thu Sep 18 02:44:49 2008
Subject: [Haskell-cafe] Re: ANN: pandoc 1.0.0.1
References: <20080914012909.GA16164@berkeley.edu>
	<6a7c66fc0809172018j7100c7d4oe4edd79daf8c7006@mail.gmail.com>
Message-ID: <871vzi9ci9.fsf@gaura-nitai.no-ip.org>

>>>>> "Alfonso" == Alfonso Acosta  writes:

Alfonso> I can't wait for a:

Alfonso> + New Docbook markup reader

Alfonso> The reason being, I would kill for a good Docbook-to-LaTeX
Alfonso> translator (or a good set of Docbook-to-TeXML XSLT
Alfonso> stylesheets):

Alfonso>  * Most of the opensource XSL-FO tools out there (fop, xmlroff
Alfonso> et all) are immature or do a poor typesetting job [1].

+ Complete reST markup reader.


Restructured text is more complete markup for serious writing, but less
complex to write in than DocBook and Pandoc's ability to generate LaTeX
& ConTeXt can generate high-quality output.


btw, I also like how Sphinx (http://sphinx.pocoo.org/) generates docs
From *.rst files.


Sincerely,
Gour


-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/f60d5182/attachment.bin
From ketil at malde.org  Thu Sep 18 04:15:18 2008
From: ketil at malde.org (Ketil Malde)
Date: Thu Sep 18 04:10:06 2008
Subject: [Haskell-cafe] XML (HXML) parsing :: GHC 6.8.3 space leak from
	2000
In-Reply-To: <48D1F3DC.9040903@lionet.info> (Lev Walkin's message of "Wed\,
	17 Sep 2008 23\:23\:24 -0700")
References: <48D1F3DC.9040903@lionet.info>
Message-ID: <87od2lamzt.fsf@malde.org>

Lev Walkin  writes:

> Recently I had to process some multi-megabyte XML files.

Join the club!  FWIW, I ended up using tagsoup.

> -- %%% There is apparently a space leak here, but I can't find it.
> -- %%% Update 28 Feb 2000: There is a leak, but it's fixed
> -- %%% by a well-known GC implementation technique.

I couldn't get this to work either.  In particular, I think the GC
trick should allow this without leakage:

   breaks p = groupBy (const (not.p))

But instead I implemented it as:

   breaks :: (a -> Bool) -> [a] -> [[a]]
   breaks p (x:xs) = let first = x : takeWhile (not.p) xs
                         rest  = dropWhile (not.p) xs
                     in  rest `par` first : if null rest then [] else breaks p rest
   breaks _ []     = []

With -smp, this doesn't leak.  It's kind of annoying to have to rely
on -smp in a library as the library cannot control how the
applications get linked, but I've found no other solution.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From marlowsd at gmail.com  Thu Sep 18 05:11:13 2008
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu Sep 18 05:08:40 2008
Subject: [Haskell-cafe] Re: XML (HXML) parsing :: GHC 6.8.3 space leak from
	2000
In-Reply-To: <48D1F3DC.9040903@lionet.info>
References: <48D1F3DC.9040903@lionet.info>
Message-ID: <48D21B31.8000908@gmail.com>

Lev Walkin wrote:

> I wondered why would a contemporary GHC 6.8.3 exhibit such a leak?
> After all, the technique was known in 2000 (and afir by Wadler in '87)
> and one would assume Joe English's reference to "most other Haskell
> systems" ought to mean GHC.

Thanks for this nice example - Don Stewart pointed me to it, and  Simon PJ 
and I just spent some time this morning diagnosing it.

Incedentally, with GHC 6.8 you can just run the program with "+RTS -hT" to 
get a basic space profile, there's no need to compile it for profiling - 
this is tremendously useful for quick profiling jobs.  And in this case we 
see the the heap is filling up with (:) and Tree constructors, no thunks.

Here's the short story:  GHC does have the space leak optimisation you 
refer to, and it is working correctly, but it doesn't cover all the cases 
you might want it to cover.  In particular, optimisations sometimes 
interact badly with the space leak avoidance, and that's what is happening 
here.  We've known about the problem for some time, but this is the first 
time I've seen a nice small example that demonstrates it.

>     -- Lazily build a tree out of a sequence of tree-building events
>     build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String])
>     build (Start str : es) =
>             let (es', subnodes) = build es
>                 (spill, siblings) = build es'
>             in (spill, (Tree str subnodes : siblings))
>     build (Leaf str : es) =
>             let (spill, siblings) = build es
>             in (spill, Tree str [] : siblings)
>     build (Stop : es) = (es, [])
>     build [] = ([], [])

So here's the long story.  Look at the first equation for build:

 >     build (Start str : es) =
 >             let (es', subnodes) = build es
 >                 (spill, siblings) = build es'
 >             in (spill, (Tree str subnodes : siblings))

this turns into

       x = build es
       es' = fst x
       subnodes = snd x

       y = build es'
       spill = fst y
       siblings = snd y

now, it's the "siblings" binding we're interested in, because this one is 
never demanded - in this example, "subnodes" ends up being an infinite list 
of trees, and we never get to evaluate "siblings".  So anything referred to 
by siblings will remain in the heap.

The space-leak avoidance optimisation works on all those "fst" and "snd" 
bindings: in a binding like "siblings = snd y", when y is evaluated to a 
pair, the GC will automatically reduce "snd y", so releasing the first 
component of the pair.  This all works fine.

But the optimiser sees the above code and spots that es' only occurs once, 
in the right hand side of the binding for y, and so it inlines it.  Now we have

       x = build es
       subnodes = snd x

       y = build (fst x)
       spill = fst y
       siblings = snd y

Now, usually this is a good idea, but in this case we lost the special 
space-leak avoidance on the "fst x" expression, because it is now embedded 
in an expression.  In fact in this case the thunk goes away entirely, 
because build is strict.

But now, when the program runs, the thunk for siblings retains y, which 
retains x, which evaluates to a pair, the second component of which 
evaluates to an infintely growing list of Trees (the first components is a 
chain of "fst y" expressions that constantly get reduced by the GC and 
don't take up any space).

We don't know of a good way to fix this problem.  I'm going to record this 
example in a ticket for future reference, though.

Cheers,
	Simon
From marlowsd at gmail.com  Thu Sep 18 05:33:22 2008
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu Sep 18 05:30:49 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big   advantages?
In-Reply-To: <1221684951.18670.41.camel@jcchost>
References: <20080917053300.GC2213@scytale.galois.com>	<48D0FEF5.5080707@libero.it>	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>	
	<1221678201.18670.12.camel@jcchost>		<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>
	<1221684951.18670.41.camel@jcchost>
Message-ID: <48D22062.6030109@gmail.com>

Jonathan Cast wrote:
> On Wed, 2008-09-17 at 13:44 -0700, Evan Laforge wrote:
>>>> systems that don't use an existing user-space thread library (such as
>>>> Concurrent Haskell or libthread [1]) emulate user-space threads by
>>>> keeping a pool of processors and re-using them (e.g., IIUC Apache does
>>>> this).
>>> Your response seems to be yet another argument that processes are too
>>> expensive to be used the same way as threads.  In my mind pooling vs
>>> new-creation is only relevant to process vs thread in the performance
>>> aspects.  The fact that people use thread-pools means that they think
>>> that even thread-creation is too expensive.  The central aspect in my
>>> mind is a default share-everything, or default share-nothing.  One is
>>> much easier to reason about and encourages writing systems that have
>>> less shared-memory contention.
>> This is similar to the plan9 conception of processes.  You have a
>> generic rfork() call that takes flags that say what to share with your
>> parent: namespace, environment, heap, etc.  Thus the only difference
>> between a thread and a process is different flags to rfork().
> 
> As I mentioned, Plan 9 also has a user-space thread library, similar to
> Concurrent Haskell.
> 
>> Under the covers, I believe linux is similar, with its clone() call.
>>
>> The fast context switching part seems orthogonal to me.  Why is it
>> that getting the OS involved for context switches kills the
>> performance?
> 
> Read about CPU architecture.
> 
>> Is it that the ghc RTS can switch faster because it
>> knows more about the code it's running (i.e. the OS obviously couldn't
>> switch on memory allocations like that)?  Or is jumping up to kernel
>> space somehow expensive by nature?
> 
> Yes.  Kernel code is very different on the bare metal from userspace
> code; RTS code of course is not at all different.  Switching processes
> in the kernel requires an interrupt or a system call.  Both of those
> require the processor to dump the running process's state so it can be
> restored later (userspace thread-switching does the same thing, but it
> doesn't dump as much state because it doesn't need to be as conservative
> about what it saves).
> 
>> And why does the OS need so many
>> more K to keep track of a thread than the RTS?
> 
> An OS thread (Linux/Plan 9) stores:
> 
> * Stack (definitely a stack pointer and stored registers (> 40 bytes on
> i686) and includes a special set of page tables on Plan 9)
> * FD set (even if it's the same as the parent thread, you need to keep a
> pointer to it
> * uid/euid/gid/egid (Plan 9 I think omits euid and egid)
> * Namespace (Plan 9 only; again, you need at least a pointer even if
> it's the same as the parent process)
> * Priority
> * Possibly other things I can't think of right now
> 
> A Concurrent Haskell thread stores:
> 
> * Stack
> * Allocation area (4KB)

Allocation areas are per-CPU, not per-thread.  A Concurrent Haskell thread 
consists of a TSO (thread state object, currently 11 machine words), and a 
stack, which we currently start with 1KB and grow on demand.

Cheers,
	Simon
From mads_lindstroem at yahoo.dk  Thu Sep 18 06:38:00 2008
From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=)
Date: Thu Sep 18 06:52:18 2008
Subject: [Haskell-cafe] MetaHDBC paper
Message-ID: <1221734280.4466.1.camel@localhost.localdomain>

Hi all,


In May I started a Haskell-cafe discussions[1], where I proposed using
Template Haskell to do type-safe database access. The idea got well
received and turned into the MetaHDBC library[2].

Concurrently with development I also wrote a paper describing
MetaHDBC. I have never writing a paper before, and I therefore tried
to imitate the best by following Simon PJ's slides and video about
writing papers in [3].

A draft of the paper can be found here [4]. Your opportunity to
influence the paper is large, as my limited paper-writing experience
means I have little preconception about what a good paper looks
like. I would especially like comments about the overall quality of
the paper, can it be called scientific and comments about anything I
could do to improve the paper. And remember, if commenting, honest is
better than polite.


Greetings,

Mads Lindstr?m



[1]
http://www.nabble.com/Using-Template-Haskell-to-make-type-safe-database-access-td17027286.html

[2] http://www.haskell.org/haskellwiki/MetaHDBC

[3]
http://research.microsoft.com/~simonpj/papers/giving-a-talk/giving-a-talk.htm

[4] http://lindstroem.files.wordpress.com/2008/09/metahdbc.pdf



From briqueabraque at yahoo.com  Thu Sep 18 08:13:48 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Thu Sep 18 08:11:23 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: <06F34CAF-8D94-435E-A49F-6ED23D1B8587@cs.otago.ac.nz>
References: 
	<48D0275A.703@jellybean.co.uk>	<13905_1221664844_m8HFKf4q019306_gar775$2ng$1@ger.gmane.org>
	<06F34CAF-8D94-435E-A49F-6ED23D1B8587@cs.otago.ac.nz>
Message-ID: 

>> Agree about the answer, not about the question. The
>> correct one would be "is it possible to change haskell
>> syntax to support the international notation (...)
> 
> For some sense of "possible", the answer is clearly yes.
> However, it is perhaps misleading to call commas
> "THE international notation".  (...)   You might as
> well ask "is it possible to change Haskell syntax to
> support only the *real* Arabic digits ... for ...
> numbers".  (... + evindences that there isn't one
 > single standard)

Well, utf-8 strings seemed to me a good way to initialize
variables, and we could, for instance use something
like "[1,2,3,4]" to initialize other kinds of lists
besides the standard one. One example I got from gtk2hs
are marked-up text on labels. So, I actually thought
we could add support for arabic and japanese digits,
and any other ways we get without ambiguities (continued
fractions, I would like, and I also liked the idea of
the raised dot).

Well, after all the comments, I'm convinced changing
the Show and Read classes are not the way to go. But
I'll think of something like a InitializableByUFT8String
class, and I'll advertize it here if I ever get
something usable and interesting.

Thanks for your comments,
Maur?cio

From marco-oweber at gmx.de  Thu Sep 18 08:31:14 2008
From: marco-oweber at gmx.de (Marc Weber)
Date: Thu Sep 18 08:28:40 2008
Subject: [Haskell-cafe] Exceptions
In-Reply-To: <2f9b2d30809172154o65a9156ahae92571ffbbb3c40@mail.gmail.com>
References: <674EFCEB-35A8-4DFF-88DC-A9E42FA6FADC@inf.fu-berlin.de>
	<20080918005148.GD25870@gmx.de>
	<2f9b2d30809172154o65a9156ahae92571ffbbb3c40@mail.gmail.com>
Message-ID: <20080918123114.GA18894@gmx.de>

On Wed, Sep 17, 2008 at 09:54:13PM -0700, Ryan Ingram wrote:
> Better is this:
> 
> data MalformedAddressException = MalformedAddressException String
> deriving (Show, Typeable)
> 
> throwDynIO x = throwIO (DynException $ toDyn x)
You are right.
Anyway the DynException will not be needed in the future because you can
throw arbitrary types directly.. But if you change the code the type
checker won't fail, you'll keep catching the old user error while the
new dyn type is beeing thrown. That's the mess.

The only thing to do is whenever you start using inet_addr implement an
HUnit test to ensure it still throws a user exception.. That's the only
reliable way to get notified if the behaviour changes..
But the strength of haskell is that we don't have to write tests for
everything because the type checker will do most work for us..

Another solution would be telling the compiler that the exception beeing
caught must be thrown within this thread... But that's not possible with
the new SomeException either.
So my result is that Exceptions should not be used here (?) or there
should be an alternative function..

Is that feasable to have to functions so that you can choose?

inet_addr_ThrowEx ?
inet_addr_Maybe ?

Java would have recignized if the exception type changes from user error
to dyn type. Haskell can't :-(

Marc Weber
From vanenkj at gmail.com  Thu Sep 18 09:25:13 2008
From: vanenkj at gmail.com (John Van Enk)
Date: Thu Sep 18 09:22:35 2008
Subject: [Haskell-cafe] Strongly Typed Memory Areas
Message-ID: 

Was Iavor/Mark's paper ever implemented as a GHC extension?

"Strongly Typed Memory Areas"
http://galois.com/down/2006_ID_Strongly.pdf

-- 
/jve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/d76c9db0/attachment.htm
From tanimoto at arizona.edu  Thu Sep 18 11:24:39 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Thu Sep 18 11:22:02 2008
Subject: [Haskell-cafe] Re: Float instance of 'read'
In-Reply-To: 
References:  <48D0275A.703@jellybean.co.uk>
	<13905_1221664844_m8HFKf4q019306_gar775$2ng$1@ger.gmane.org>
	<06F34CAF-8D94-435E-A49F-6ED23D1B8587@cs.otago.ac.nz>
	
Message-ID: 

Hi,

Mauricio, sorry for hijacking your thread.  : )

I have one question about handling or parsing decimal places.  I
noticed that Haskell doesn't accept values starting with just the
point, e.g., .50 or .01.  I suppose that's abuse of notation in the
first place (and I'm guilty of it), but I often receive datasets that
have numbers written that way.

Do we have this behavior to avoid ambiguity with the dot operator?

For example:

> .1
:1:0: parse error on input `.'

> read ".1" :: Float
*** Exception: Prelude.read: no parse

And then:

> let (.) = (+)
> 1 .1
2

I often end up writing a function that will add a leading zero when
it's missing for decimal places, before feeding a string to read.  Is
there a better way of handling this?

Thanks,

Paulo


On Thu, Sep 18, 2008 at 7:13 AM, Mauricio  wrote:
>>> Agree about the answer, not about the question. The
>>> correct one would be "is it possible to change haskell
>>> syntax to support the international notation (...)
>>
>> For some sense of "possible", the answer is clearly yes.
>> However, it is perhaps misleading to call commas
>> "THE international notation".  (...)   You might as
>> well ask "is it possible to change Haskell syntax to
>> support only the *real* Arabic digits ... for ...
>> numbers".  (... + evindences that there isn't one
>
>> single standard)
>
> Well, utf-8 strings seemed to me a good way to initialize
> variables, and we could, for instance use something
> like "[1,2,3,4]" to initialize other kinds of lists
> besides the standard one. One example I got from gtk2hs
> are marked-up text on labels. So, I actually thought
> we could add support for arabic and japanese digits,
> and any other ways we get without ambiguities (continued
> fractions, I would like, and I also liked the idea of
> the raised dot).
>
> Well, after all the comments, I'm convinced changing
> the Show and Read classes are not the way to go. But
> I'll think of something like a InitializableByUFT8String
> class, and I'll advertize it here if I ever get
> something usable and interesting.
>
> Thanks for your comments,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From lemming at henning-thielemann.de  Thu Sep 18 11:38:51 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu Sep 18 11:36:15 2008
Subject: [Haskell-cafe] readFile and closing a file
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3A06@ELON17P32001A.csfb.cs-group.com>
References: 
	<33A3F585590A6F4E81E3D45AA4A111C902CD3A06@ELON17P32001A.csfb.cs-group.com>
Message-ID: 


On Wed, 17 Sep 2008, Mitchell, Neil wrote:

> Hi Henning,
>
> I tend to use openFile, hGetContents, hClose - your initial readFile
> like call should be openFile/hGetContents, which gives you a lazy
> stream, and on a parse error call hClose.

Yes, this seems to be the right way. This weakness should be mentioned in 
the docs of readFile. In production code, you cannot rely on a garbage 
collector to close the file, because you might want to open a file for 
writing after you have processed it with readFile, and there is warranty 
that the file is already closed then.

From tphyahoo at gmail.com  Thu Sep 18 11:51:57 2008
From: tphyahoo at gmail.com (Thomas Hartman)
Date: Thu Sep 18 11:49:19 2008
Subject: [Haskell-cafe] Real World HAppS: Cabalized,
	Self-Demoing HAppS Tutorial (Version 3)
In-Reply-To: <20080917120436.GB25870@gmx.de>
References: <910ddf450809120807j6d1379b3uc8a23c8dc8720b55@mail.gmail.com>
	<48D025D4.8020102@gmx.org> <20080917120436.GB25870@gmx.de>
Message-ID: <910ddf450809180851p63cda2fcs2c6d1ffa188da30b@mail.gmail.com>

The latest darcs version of what? I don't remember putting that into
my tutorial...

t.

2008/9/17 Marc Weber :
> On Tue, Sep 16, 2008 at 11:32:04PM +0200, Martin Huschenbett wrote:
>>  Hi all,
>>
>>  taking a look at this tutorial under Windows Vista I ran into a problem:
>
> You should get the latest darcs version which contains the conditional
> cabal flag:
>  if !os(windows)
>     Build-Depends:    unix
>     cpp-options:      -DUNIX
>
> Marc
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From jonathanccast at fastmail.fm  Thu Sep 18 11:49:33 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Thu Sep 18 11:52:32 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big   advantages?
In-Reply-To: <48D22062.6030109@gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>
	<48D0FEF5.5080707@libero.it>
	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>
	 <1221678201.18670.12.camel@jcchost>
	
	<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>
	<1221684951.18670.41.camel@jcchost>  <48D22062.6030109@gmail.com>
Message-ID: <1221752973.18670.74.camel@jcchost>

On Thu, 2008-09-18 at 10:33 +0100, Simon Marlow wrote:
> Jonathan Cast wrote:
> > An OS thread (Linux/Plan 9) stores:
> > 
> > * Stack (definitely a stack pointer and stored registers (> 40 bytes on
> > i686) and includes a special set of page tables on Plan 9)
> > * FD set (even if it's the same as the parent thread, you need to keep a
> > pointer to it
> > * uid/euid/gid/egid (Plan 9 I think omits euid and egid)
> > * Namespace (Plan 9 only; again, you need at least a pointer even if
> > it's the same as the parent process)
> > * Priority
> > * Possibly other things I can't think of right now
> > 
> > A Concurrent Haskell thread stores:
> > 
> > * Stack
> > * Allocation area (4KB)
> 
> Allocation areas are per-CPU, not per-thread.

Didn't know/didn't think through that.  Thanks!

jcc


From tphyahoo at gmail.com  Thu Sep 18 12:10:19 2008
From: tphyahoo at gmail.com (Thomas Hartman)
Date: Thu Sep 18 12:07:41 2008
Subject: [Haskell-cafe] HStringTemplate to generate html tables
Message-ID: <910ddf450809180910wfaddd4s982492d53c2f02cf@mail.gmail.com>

I am trying to use HStringTemplate for generating html tables, for use
in http://happstutorial.com:5001

The best I could do is below. Seems awfully kludgy.

Can someone suggest a better way, which keeps me inside the
StringTemplate way of doing things? (Eg, no suggestions to use HTML.*
libraries, which are nice for some things but are a higher barrier to
entry than just jumping in and writing html.)

Some kind of map structure... for each... ?

Thanks for any help!

thomas.

{-# LANGUAGE NoMonomorphismRestriction #-}
import Text.StringTemplate
import Control.Applicative
import qualified Text.PrettyPrint as PP

main = putStrLn . PP.render . toPPDoc $ tableFromCells cells
cells = [["mee","mah","moh"],["fee","fah","foh"]]

-- This does generate an html table, but seems horribly obfuscated.
-- is there machinery for doing things like html table generation
-- in some better way than this hack where 
-- tags are used as a separator?
-- I would imagine something like
-- newSTMP "$cells:{$it$}:{$it}:{$it
}"
-- which works a bit like a list comprehension
tableFromCells cells = setAttribute "cells" cells . optInsertTmpl
[("separator","")]
  $ newSTMP "$cells:\
              \{$it$}:\
                \{$it$
}$"
From vlm at lionet.info  Thu Sep 18 12:46:09 2008
From: vlm at lionet.info (Lev Walkin)
Date: Thu Sep 18 12:43:44 2008
Subject: [Haskell-cafe] Re: XML (HXML) parsing :: GHC 6.8.3 space leak from
	2000
In-Reply-To: <48D21B31.8000908@gmail.com>
References: <48D1F3DC.9040903@lionet.info> <48D21B31.8000908@gmail.com>
Message-ID: <48D285D1.7000104@lionet.info>

Simon Marlow wrote:
> Lev Walkin wrote:
> 
>> I wondered why would a contemporary GHC 6.8.3 exhibit such a leak?
>> After all, the technique was known in 2000 (and afir by Wadler in '87)
>> and one would assume Joe English's reference to "most other Haskell
>> systems" ought to mean GHC.
> 
> Thanks for this nice example - Don Stewart pointed me to it, and  Simon 
> PJ and I just spent some time this morning diagnosing it.
> 
> Incedentally, with GHC 6.8 you can just run the program with "+RTS -hT" 
> to get a basic space profile, there's no need to compile it for 
> profiling - this is tremendously useful for quick profiling jobs.  And 
> in this case we see the the heap is filling up with (:) and Tree 
> constructors, no thunks.
> 
> Here's the short story:  GHC does have the space leak optimisation you 
> refer to, and it is working correctly, but it doesn't cover all the 
> cases you might want it to cover.  In particular, optimisations 
> sometimes interact badly with the space leak avoidance, and that's what 
> is happening here.  We've known about the problem for some time, but 
> this is the first time I've seen a nice small example that demonstrates it.
> 
>>     -- Lazily build a tree out of a sequence of tree-building events
>>     build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String])
>>     build (Start str : es) =
>>             let (es', subnodes) = build es
>>                 (spill, siblings) = build es'
>>             in (spill, (Tree str subnodes : siblings))
>>     build (Leaf str : es) =
>>             let (spill, siblings) = build es
>>             in (spill, Tree str [] : siblings)
>>     build (Stop : es) = (es, [])
>>     build [] = ([], [])

[skip]

> We don't know of a good way to fix this problem.  I'm going to record 
> this example in a ticket for future reference, though.

Simon,

is there a way, perhaps, to rewrite this expression to avoid leaks?
An ad-hoc will do, perhaps split in two modules to avoid intramodular
optimizations?

-- 
Lev Walkin
vlm@lionet.info
From marcot at riseup.net  Thu Sep 18 12:46:35 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Thu Sep 18 12:44:41 2008
Subject: [Haskell-cafe] control-timeout with gtk
Message-ID: <1221756395.4567.29.camel@quindinho.domain.invalid>

Hello,

I've written a simple sequencer[0] using gtk2hs and control-timeout[1].
In GHCi it works fine, but when I compile it, the timeouts generated by
control-timeout are not executed.  Actually, when I use the keyboard a
lot, at some time they got executed.  I thought it could be that these
two packages are incompatible, but the I wondered why they work in GHCi.

Any ideas?

Greetings.

0: http://marcot.iaaeee.org/capoeira
1:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-timeout
-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From wchogg at gmail.com  Thu Sep 18 13:02:43 2008
From: wchogg at gmail.com (Creighton Hogg)
Date: Thu Sep 18 13:00:05 2008
Subject: [Haskell-cafe] A round of golf
Message-ID: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>

Hey Haskell,
So for a fairly inane reason, I ended up taking a couple of minutes
and writing a program that would spit out, to the console, the number
of lines in a file.  Off the top of my head, I came up with this which
worked fine with files that had 100k lines:

main = do
 path <- liftM head $ getArgs
 h <- openFile path ReadMode
 n <- execStateT (countLines h) 0
 print n

untilM :: Monad m => (a -> m Bool) -> (a -> m ()) -> a -> m ()
untilM cond action val = do
 truthy <- cond val
 if truthy then return () else action val >> (untilM cond action val)

countLines :: Handle -> StateT Int IO ()
countLines = untilM (\h -> lift $ hIsEOF h) (\h -> do
                                                lift $ hGetLine h
                                                modify (+1))

If this makes anyone cringe or cry "you're doing it wrong", I'd
actually like to hear it.  I never really share my projects, so I
don't know how idiosyncratic my style is.
From judah.jacobson at gmail.com  Thu Sep 18 13:05:14 2008
From: judah.jacobson at gmail.com (Judah Jacobson)
Date: Thu Sep 18 13:02:36 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <1221756395.4567.29.camel@quindinho.domain.invalid>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
Message-ID: <6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>

On Thu, Sep 18, 2008 at 9:46 AM, Marco T?lio Gontijo e Silva
 wrote:
> Hello,
>
> I've written a simple sequencer[0] using gtk2hs and control-timeout[1].
> In GHCi it works fine, but when I compile it, the timeouts generated by
> control-timeout are not executed.  Actually, when I use the keyboard a
> lot, at some time they got executed.  I thought it could be that these
> two packages are incompatible, but the I wondered why they work in GHCi.
>
> Any ideas?
>

Just a guess, but this might be a problem with control-timeout's use
of the unsafePerformIO global variables hack.  It's missing the
standard NOINLINE annotations which prevent multiple copies of the
global variable from being created.  See the haddock docs for
System.IO.Unsafe.unsafePerformIO for more information.

-Judah
From bos at serpentine.com  Thu Sep 18 13:09:44 2008
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Thu Sep 18 13:07:08 2008
Subject: [Haskell-cafe] readFile and closing a file
In-Reply-To: <20080917132117.GB19238@darcs.net>
References: 
	<20080917132117.GB19238@darcs.net>
Message-ID: 

On Wed, Sep 17, 2008 at 6:21 AM, David Roundy  wrote:

>
> Eventually the garbage collector should close the file, I believe.
>

That's true, but "eventually" could be long enough to mean "never" in
practice. It's safest to assume that finalizers will not run at all, never
mind in a timely fashion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/72a4bec0/attachment.htm
From kelanslists at gmail.com  Thu Sep 18 13:25:27 2008
From: kelanslists at gmail.com (Kurt Hutchinson)
Date: Thu Sep 18 13:22:50 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
Message-ID: 

On Thu, Sep 18, 2008 at 1:02 PM, Creighton Hogg  wrote:
> Hey Haskell,
> So for a fairly inane reason, I ended up taking a couple of minutes
> and writing a program that would spit out, to the console, the number
> of lines in a file.  Off the top of my head, I came up with this which

Yay, golf! I love playing golf from my Perl days. How about this:

  main = print . length . lines =<< readFile . head =<< getArgs

Salt with Bytestring for extra flavor (and speed).

Kurt
From bos at serpentine.com  Thu Sep 18 13:25:35 2008
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Thu Sep 18 13:23:02 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
Message-ID: 

On Thu, Sep 18, 2008 at 10:02 AM, Creighton Hogg  wrote:

>
> If this makes anyone cringe or cry "you're doing it wrong", I'd
> actually like to hear it.


Yes, that made me cry :-)  Your code seems very convoluted, and quite
successfully hides what it's really trying to do. Here's a version that is
rather more concise, and which will be far faster besides.

import qualified Data.ByteString.Lazy.Char8 as B
import System.Environment

main = mapM_ ((print =<<) . fmap (B.count '\n') . B.readFile) =<< getArgs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/fb685d41/attachment.htm
From dons at galois.com  Thu Sep 18 14:29:11 2008
From: dons at galois.com (Don Stewart)
Date: Thu Sep 18 14:26:27 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
Message-ID: <20080918182911.GB8398@scytale.galois.com>

wchogg:
> Hey Haskell,
> So for a fairly inane reason, I ended up taking a couple of minutes
> and writing a program that would spit out, to the console, the number
> of lines in a file.  Off the top of my head, I came up with this which
> worked fine with files that had 100k lines:
> 
> main = do
>  path <- liftM head $ getArgs
>  h <- openFile path ReadMode
>  n <- execStateT (countLines h) 0
>  print n
> 
> untilM :: Monad m => (a -> m Bool) -> (a -> m ()) -> a -> m ()
> untilM cond action val = do
>  truthy <- cond val
>  if truthy then return () else action val >> (untilM cond action val)
> 
> countLines :: Handle -> StateT Int IO ()
> countLines = untilM (\h -> lift $ hIsEOF h) (\h -> do
>                                                 lift $ hGetLine h
>                                                 modify (+1))
> 
> If this makes anyone cringe or cry "you're doing it wrong", I'd
> actually like to hear it.  I never really share my projects, so I
> don't know how idiosyncratic my style is.

This makes me cry.

    import System.Environment
    import qualified Data.ByteString.Lazy.Char8 as B

    main = do
        [f] <- getArgs
        s   <- B.readFile f
        print (B.count '\n' s)

Compile it.

    $ ghc -O2 --make A.hs

    $ time ./A /usr/share/dict/words
    52848
    ./A /usr/share/dict/words 0.00s user 0.00s system 93% cpu 0.007 total

Against standard tools:

    $ time wc -l /usr/share/dict/words
    52848 /usr/share/dict/words
    wc -l /usr/share/dict/words 0.01s user 0.00s system 88% cpu 0.008 total

-- Don
From agl at imperialviolet.org  Thu Sep 18 14:30:05 2008
From: agl at imperialviolet.org (Adam Langley)
Date: Thu Sep 18 14:27:28 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
Message-ID: <396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>

On Thu, Sep 18, 2008 at 10:05 AM, Judah Jacobson
 wrote:
> Just a guess, but this might be a problem with control-timeout's use
> of the unsafePerformIO global variables hack.  It's missing the
> standard NOINLINE annotations which prevent multiple copies of the
> global variable from being created.  See the haddock docs for
> System.IO.Unsafe.unsafePerformIO for more information.

That might well be it, should be an easy fix to try.

I'm afraid that I don't have enough time to do justice to my packages
on Hackage these days so I've just sent an email requesting that they
be removed. Anyone who wants to maintain any of them should grab it
now. The repos are all at http://darcs.imperialviolet.org

On the chopping block:

binary-strict
codec-libevent
control-timeout
ctemplate
LRU
network-connection
network-dns
network-minihttp
network-rpca
system-inotify


Cheers

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
From marcot at riseup.net  Thu Sep 18 14:38:49 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Thu Sep 18 14:36:16 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
	<396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
Message-ID: <1221763129.4567.42.camel@quindinho.domain.invalid>

Em Qui, 2008-09-18 ?s 11:30 -0700, Adam Langley escreveu:
> I'm afraid that I don't have enough time to do justice to my packages
> on Hackage these days so I've just sent an email requesting that they
> be removed.

Maybe it's better that they stay there, even with nobody maintaining
them.

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From droundy at darcs.net  Thu Sep 18 14:42:05 2008
From: droundy at darcs.net (David Roundy)
Date: Thu Sep 18 14:39:28 2008
Subject: [Haskell-cafe] readFile and closing a file
In-Reply-To: 
References: 
	<33A3F585590A6F4E81E3D45AA4A111C902CD3A06@ELON17P32001A.csfb.cs-group.com>
	
Message-ID: <20080918184204.GC16346@darcs.net>

On Thu, Sep 18, 2008 at 05:38:51PM +0200, Henning Thielemann wrote:
> On Wed, 17 Sep 2008, Mitchell, Neil wrote:
>> I tend to use openFile, hGetContents, hClose - your initial readFile
>> like call should be openFile/hGetContents, which gives you a lazy
>> stream, and on a parse error call hClose.
>
> Yes, this seems to be the right way. This weakness should be mentioned in
> the docs of readFile. In production code, you cannot rely on a garbage
> collector to close the file, because you might want to open a file for
> writing after you have processed it with readFile, and there is warranty
> that the file is already closed then.

Ah, so you must be concerned about windows systems? Yes, on windows
systems it's definitely best to never to lazy IO.  On non-windows file
systems, unless you're planning on opening thousands of files, relying
on the garbage collector is fine.

David
From andre at digirati.com.br  Thu Sep 18 14:43:39 2008
From: andre at digirati.com.br (Andre Nathan)
Date: Thu Sep 18 14:40:48 2008
Subject: [Haskell-cafe] Library design question
Message-ID: <1221763419.29666.50.camel@andre.mz.digirati.com.br>

Hello

I'm trying to write a simple graph library for a project of mine
(actually, I'm porting it from OCaml) but I've got a design question
right in the beginning.

My Graph type is the following.

  data Graph a b = Graph
    { adjacencies :: Map Int (a, (Map Int b))
    , numVertices :: Int
    , numEdges    :: Int
    }

Types "a" and "b" refer to vertex and edge labels (I know it's kind of
weird to use a Map of Maps to represent a graph, but it helps me
removing vertices later, which is something I'll need to do.)

Creating an empty graph is trivial:

  empty :: Graph a b
  empty = Graph Map.empty 0 0

The issue I hit was when writing the function to add a vertex to the
graph. Since I need to update the vertex counter, I've used the state
monad:

  addVertex :: Int -> a -> State (Graph a b) ()
  addVertex vertex label = do
    g <- get
    let adj = Map.insert vertex (label, Map.empty) (adjacencies g)
    put $ g { adjacencies = adj, numVertices = numVertices g + 1 }

That works fine, but from the point of view of a user of the library,
the addVertex function should take a "Graph a b" as its first argument,
as one would expect to be able to say which graph is going to be
modified.

So I'm confused right now about how I should proceed. Any hints
regarding that?

Best regards,
Andre

From wchogg at gmail.com  Thu Sep 18 14:49:50 2008
From: wchogg at gmail.com (Creighton Hogg)
Date: Thu Sep 18 14:47:11 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <20080918182911.GB8398@scytale.galois.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
Message-ID: <814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>

On Thu, Sep 18, 2008 at 1:29 PM, Don Stewart  wrote:
> wchogg:
>> Hey Haskell,
>> So for a fairly inane reason, I ended up taking a couple of minutes
>> and writing a program that would spit out, to the console, the number
>> of lines in a file.  Off the top of my head, I came up with this which
>> worked fine with files that had 100k lines:
>>
>> main = do
>>  path <- liftM head $ getArgs
>>  h <- openFile path ReadMode
>>  n <- execStateT (countLines h) 0
>>  print n
>>
>> untilM :: Monad m => (a -> m Bool) -> (a -> m ()) -> a -> m ()
>> untilM cond action val = do
>>  truthy <- cond val
>>  if truthy then return () else action val >> (untilM cond action val)
>>
>> countLines :: Handle -> StateT Int IO ()
>> countLines = untilM (\h -> lift $ hIsEOF h) (\h -> do
>>                                                 lift $ hGetLine h
>>                                                 modify (+1))
>>
>> If this makes anyone cringe or cry "you're doing it wrong", I'd
>> actually like to hear it.  I never really share my projects, so I
>> don't know how idiosyncratic my style is.
>
> This makes me cry.
>
>    import System.Environment
>    import qualified Data.ByteString.Lazy.Char8 as B
>
>    main = do
>        [f] <- getArgs
>        s   <- B.readFile f
>        print (B.count '\n' s)
>
> Compile it.
>
>    $ ghc -O2 --make A.hs
>
>    $ time ./A /usr/share/dict/words
>    52848
>    ./A /usr/share/dict/words 0.00s user 0.00s system 93% cpu 0.007 total
>
> Against standard tools:
>
>    $ time wc -l /usr/share/dict/words
>    52848 /usr/share/dict/words
>    wc -l /usr/share/dict/words 0.01s user 0.00s system 88% cpu 0.008 total

So both you & Bryan do essentially the same thing and of course both
versions are far better than mine.  So the purpose of using the Lazy
version of ByteString was so that the file is only incrementally
loaded by readFile as count is processing?
From agl at imperialviolet.org  Thu Sep 18 14:51:08 2008
From: agl at imperialviolet.org (Adam Langley)
Date: Thu Sep 18 14:48:31 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <1221763129.4567.42.camel@quindinho.domain.invalid>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
	<396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
	<1221763129.4567.42.camel@quindinho.domain.invalid>
Message-ID: <396556a20809181151j3973ebb8p3afc3669ffacfa69@mail.gmail.com>

On Thu, Sep 18, 2008 at 11:38 AM, Marco T?lio Gontijo e Silva
 wrote:
> Maybe it's better that they stay there, even with nobody maintaining
> them.

Except that I feel shitty everytime someone someone emails me with
questions or problems that I don't have the time to deal with. It's a
constant cost for my name to be associated with them and, if nobody
cares enough to take the maintainership, they should probably die -
Hackage has a lot of packages these days. Do you want control-timeout?
:)

AGL


-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
From dons at galois.com  Thu Sep 18 14:55:10 2008
From: dons at galois.com (Don Stewart)
Date: Thu Sep 18 14:52:27 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
Message-ID: <20080918185510.GE8398@scytale.galois.com>

wchogg:
> On Thu, Sep 18, 2008 at 1:29 PM, Don Stewart  wrote:
> > wchogg:
> >> Hey Haskell,
> >> So for a fairly inane reason, I ended up taking a couple of minutes
> >> and writing a program that would spit out, to the console, the number
> >> of lines in a file.  Off the top of my head, I came up with this which
> >> worked fine with files that had 100k lines:
> >>
> >> main = do
> >>  path <- liftM head $ getArgs
> >>  h <- openFile path ReadMode
> >>  n <- execStateT (countLines h) 0
> >>  print n
> >>
> >> untilM :: Monad m => (a -> m Bool) -> (a -> m ()) -> a -> m ()
> >> untilM cond action val = do
> >>  truthy <- cond val
> >>  if truthy then return () else action val >> (untilM cond action val)
> >>
> >> countLines :: Handle -> StateT Int IO ()
> >> countLines = untilM (\h -> lift $ hIsEOF h) (\h -> do
> >>                                                 lift $ hGetLine h
> >>                                                 modify (+1))
> >>
> >> If this makes anyone cringe or cry "you're doing it wrong", I'd
> >> actually like to hear it.  I never really share my projects, so I
> >> don't know how idiosyncratic my style is.
> >
> > This makes me cry.
> >
> >    import System.Environment
> >    import qualified Data.ByteString.Lazy.Char8 as B
> >
> >    main = do
> >        [f] <- getArgs
> >        s   <- B.readFile f
> >        print (B.count '\n' s)
> >
> > Compile it.
> >
> >    $ ghc -O2 --make A.hs
> >
> >    $ time ./A /usr/share/dict/words
> >    52848
> >    ./A /usr/share/dict/words 0.00s user 0.00s system 93% cpu 0.007 total
> >
> > Against standard tools:
> >
> >    $ time wc -l /usr/share/dict/words
> >    52848 /usr/share/dict/words
> >    wc -l /usr/share/dict/words 0.01s user 0.00s system 88% cpu 0.008 total
> 
> So both you & Bryan do essentially the same thing and of course both
> versions are far better than mine.  So the purpose of using the Lazy
> version of ByteString was so that the file is only incrementally
> loaded by readFile as count is processing?

Yep, that's right

The streaming nature is implicit in the lazy bytestring. It's kind of
the dual of explicit chunkwise control -- chunk processing reified into
the data structure.

-- Don 
From andrewcoppin at btinternet.com  Thu Sep 18 14:59:51 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Thu Sep 18 14:57:11 2008
Subject: [Haskell-cafe] An interesting curiosity
Message-ID: <48D2A527.2040708@btinternet.com>

I'm currently reading a C++ tutorial. (Don't ask!)

Of course, C++ is that crazy language where *assignment* is actually an 
*operator*. Sick, sick people...

The tutorial pointed out that "x = 4" is a legal assignment, but "4 = x" 
is not. "Obviously that would be silly."

Now it occurs to me... in Haskell, "4 = x" is actually a perfectly legal 
thing to say. (!) It's pretty pointless, but it's legal. For example:

  foo x = let 4 = x in 2*x

which, as best as I can tell, does exactly the same thing as (2*).

In a similar vein, one might write

  foo x = do
    let 4 = x
    return (2*x)

which also does more or less the same as (return).

However, consider the following:

  foo :: Int -> Maybe Int
  foo x = do
    4 <- return x
    return (2*x)

This, it turns out, is an extremely odd way of checking whether x == 4.

All of this works of course because in Haskell, "=" is not an 
assignment, it's a definition, and the RHS is not a variable, it's a 
pattern. And "4" is a perfectly legitimate pattern. Now, if only I could 
find a use for all this that borders on "useful"...! ;-)

From manlio_perillo at libero.it  Thu Sep 18 15:01:10 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Thu Sep 18 14:58:33 2008
Subject: [Haskell-cafe] a question about concurrent haskell
Message-ID: <48D2A576.4010100@libero.it>

Hi.

I have a question about concurrent Haskell in GHC.

Suppose I want to write a native pure Haskell PostgreSQL client.
I have done this for Python (using Twisted):
http://hg.mperillo.ath.cx/twisted/pglib/

and I would like to do this in Haskell, as an exercise.

The main problem is with multiple concurrent queries to the same 
connection, from multiple threads.

PostgreSQL supports multiple requests but it's better to execute only 
one request at a time:
http://www.postgresql.org/docs/8.3/interactive/protocol-flow.html#AEN73647


In the Twisted version I queue all the requests, and every time a 
request completes I call the callback associated with the request and 
execute the next available request.

But how do I solve this problem with concurrent Haskell?

Suppose thread A execute a query, and while this query is still active, 
a thread B execute another query.

I should suspend thread B (calling yield), but how do I resume it when 
the query executed by thread A completes?

The GHC concurrent Haskell does not have a function to resume a given 
thread (as found, as an example, in Lua).



P.S.: another question.
Why, in ghci, every time I call myThreadId, I get a different value?

Prelude Control.Concurrent> myThreadId
ThreadId 40
Prelude Control.Concurrent> myThreadId
ThreadId 41





Thanks   Manlio Perillo
From andrewcoppin at btinternet.com  Thu Sep 18 15:04:41 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Thu Sep 18 15:02:00 2008
Subject: [Haskell-cafe] a question about concurrent haskell
In-Reply-To: <48D2A576.4010100@libero.it>
References: <48D2A576.4010100@libero.it>
Message-ID: <48D2A649.8090301@btinternet.com>

Manlio Perillo wrote:
> The GHC concurrent Haskell does not have a function to resume a given 
> thread (as found, as an example, in Lua).

It does, however, provide the MVar, which can be used to make a thread 
block until some data is inserted into the MVar by another thread.

From manlio_perillo at libero.it  Thu Sep 18 15:10:07 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Thu Sep 18 15:07:37 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big   advantages?
In-Reply-To: <48D22062.6030109@gmail.com>
References: <20080917053300.GC2213@scytale.galois.com>	<48D0FEF5.5080707@libero.it>	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>		<1221678201.18670.12.camel@jcchost>		<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>	<1221684951.18670.41.camel@jcchost>
	<48D22062.6030109@gmail.com>
Message-ID: <48D2A78F.7090907@libero.it>

Simon Marlow ha scritto:
> Jonathan Cast wrote:
>> On Wed, 2008-09-17 at 13:44 -0700, Evan Laforge wrote:
>>>>> systems that don't use an existing user-space thread library (such as
>>>>> Concurrent Haskell or libthread [1]) emulate user-space threads by
>>>>> keeping a pool of processors and re-using them (e.g., IIUC Apache does
>>>>> this).
>>>> Your response seems to be yet another argument that processes are too
>>>> expensive to be used the same way as threads.  In my mind pooling vs
>>>> new-creation is only relevant to process vs thread in the performance
>>>> aspects.  The fact that people use thread-pools means that they think
>>>> that even thread-creation is too expensive.  The central aspect in my
>>>> mind is a default share-everything, or default share-nothing.  One is
>>>> much easier to reason about and encourages writing systems that have
>>>> less shared-memory contention.
>>> This is similar to the plan9 conception of processes.  You have a
>>> generic rfork() call that takes flags that say what to share with your
>>> parent: namespace, environment, heap, etc.  Thus the only difference
>>> between a thread and a process is different flags to rfork().
>>
>> As I mentioned, Plan 9 also has a user-space thread library, similar to
>> Concurrent Haskell.
>>
>>> Under the covers, I believe linux is similar, with its clone() call.
>>>
>>> The fast context switching part seems orthogonal to me.  Why is it
>>> that getting the OS involved for context switches kills the
>>> performance?
>>
>> Read about CPU architecture.
>>
>>> Is it that the ghc RTS can switch faster because it
>>> knows more about the code it's running (i.e. the OS obviously couldn't
>>> switch on memory allocations like that)?  Or is jumping up to kernel
>>> space somehow expensive by nature?
>>
>> Yes.  Kernel code is very different on the bare metal from userspace
>> code; RTS code of course is not at all different.  Switching processes
>> in the kernel requires an interrupt or a system call.  Both of those
>> require the processor to dump the running process's state so it can be
>> restored later (userspace thread-switching does the same thing, but it
>> doesn't dump as much state because it doesn't need to be as conservative
>> about what it saves).
>>
>>> And why does the OS need so many
>>> more K to keep track of a thread than the RTS?
>>
>> An OS thread (Linux/Plan 9) stores:
>>
>> * Stack (definitely a stack pointer and stored registers (> 40 bytes on
>> i686) and includes a special set of page tables on Plan 9)
>> * FD set (even if it's the same as the parent thread, you need to keep a
>> pointer to it
>> * uid/euid/gid/egid (Plan 9 I think omits euid and egid)
>> * Namespace (Plan 9 only; again, you need at least a pointer even if
>> it's the same as the parent process)
>> * Priority
>> * Possibly other things I can't think of right now
>>
>> A Concurrent Haskell thread stores:
>>
>> * Stack
>> * Allocation area (4KB)
> 
> Allocation areas are per-CPU, not per-thread.  A Concurrent Haskell 
> thread consists of a TSO (thread state object, currently 11 machine 
> words), and a stack, which we currently start with 1KB and grow on demand.
> 

How is this implemented?

I have seen some coroutine implementations in C, using functions from 
ucontext.h (or direct asm code), but all have the problem that the 
allocated stack is fixed.



Thanks  Manlio Perillo
From manlio_perillo at libero.it  Thu Sep 18 15:11:29 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Thu Sep 18 15:08:52 2008
Subject: [Haskell-cafe] a question about concurrent haskell
In-Reply-To: <48D2A649.8090301@btinternet.com>
References: <48D2A576.4010100@libero.it> <48D2A649.8090301@btinternet.com>
Message-ID: <48D2A7E1.7030105@libero.it>

Andrew Coppin ha scritto:
> Manlio Perillo wrote:
>> The GHC concurrent Haskell does not have a function to resume a given 
>> thread (as found, as an example, in Lua).
> 
> It does, however, provide the MVar, which can be used to make a thread 
> block until some data is inserted into the MVar by another thread.
> 

Ah, right, thanks.


Manlio Perillo
From noteed at gmail.com  Thu Sep 18 15:13:55 2008
From: noteed at gmail.com (minh thu)
Date: Thu Sep 18 15:11:17 2008
Subject: [Haskell-cafe] Library design question
In-Reply-To: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
Message-ID: <40a414c20809181213n2a02ffc5pd0b59c68ba23d236@mail.gmail.com>

2008/9/18 Andre Nathan :
> Hello
>
> I'm trying to write a simple graph library for a project of mine
> (actually, I'm porting it from OCaml) but I've got a design question
> right in the beginning.
>
> My Graph type is the following.
>
>  data Graph a b = Graph
>    { adjacencies :: Map Int (a, (Map Int b))
>    , numVertices :: Int
>    , numEdges    :: Int
>    }
>
> Types "a" and "b" refer to vertex and edge labels (I know it's kind of
> weird to use a Map of Maps to represent a graph, but it helps me
> removing vertices later, which is something I'll need to do.)
>
> Creating an empty graph is trivial:
>
>  empty :: Graph a b
>  empty = Graph Map.empty 0 0
>
> The issue I hit was when writing the function to add a vertex to the
> graph. Since I need to update the vertex counter, I've used the state
> monad:
>
>  addVertex :: Int -> a -> State (Graph a b) ()
>  addVertex vertex label = do
>    g <- get
>    let adj = Map.insert vertex (label, Map.empty) (adjacencies g)
>    put $ g { adjacencies = adj, numVertices = numVertices g + 1 }
>
> That works fine, but from the point of view of a user of the library,
> the addVertex function should take a "Graph a b" as its first argument,
> as one would expect to be able to say which graph is going to be
> modified.
>
> So I'm confused right now about how I should proceed. Any hints
> regarding that?

Hi,

Why not simply

addVertex (Graph adj nv ne) vertex label = Graph (Map.insert ...) (nv+1) ne

?

If you don't want to pattern match because you expect you Graph data type to
change later, you can instead use

addVertex g vertex label = Graph (Map.insert ...) (nv+1) ne
 where adj = adjacencies g
           nv = numVertices g
           ne = numEdges g

If you need the one inside the State monad, you can reuse the new
version of addVertex.

Or, why do you want the user of your library give the graph as an argument
if that argument is implicit (because it is inside the State monad) ?

Hope this helps,
Thu
From marcot at riseup.net  Thu Sep 18 15:14:16 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Thu Sep 18 15:11:46 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <396556a20809181151j3973ebb8p3afc3669ffacfa69@mail.gmail.com>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
	<396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
	<1221763129.4567.42.camel@quindinho.domain.invalid>
	<396556a20809181151j3973ebb8p3afc3669ffacfa69@mail.gmail.com>
Message-ID: <1221765256.4567.51.camel@quindinho.domain.invalid>

Em Qui, 2008-09-18 ?s 11:51 -0700, Adam Langley escreveu:
> Do you want control-timeout?

I think control-timeout is very useful.  I'll try to fix it, and if I
could, I'll upload it to hackage then.

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From lemming at henning-thielemann.de  Thu Sep 18 15:15:07 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu Sep 18 15:12:30 2008
Subject: [Haskell-cafe] Library design question
In-Reply-To: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
Message-ID: 


On Thu, 18 Sep 2008, Andre Nathan wrote:

> The issue I hit was when writing the function to add a vertex to the
> graph. Since I need to update the vertex counter, I've used the state
> monad:
>
>  addVertex :: Int -> a -> State (Graph a b) ()
>  addVertex vertex label = do
>    g <- get
>    let adj = Map.insert vertex (label, Map.empty) (adjacencies g)
>    put $ g { adjacencies = adj, numVertices = numVertices g + 1 }
>
> That works fine, but from the point of view of a user of the library,
> the addVertex function should take a "Graph a b" as its first argument,
> as one would expect to be able to say which graph is going to be
> modified.

Think of the state monad as processing a graph in-place. Which graph is 
addressed is declared when running the State monad using runState or 
evalState.
From qdunkan at gmail.com  Thu Sep 18 15:18:55 2008
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu Sep 18 15:16:16 2008
Subject: [Haskell-cafe] An interesting curiosity
In-Reply-To: <48D2A527.2040708@btinternet.com>
References: <48D2A527.2040708@btinternet.com>
Message-ID: <2518b95d0809181218i4f20c85alc9c9a5e2cb9eb70e@mail.gmail.com>

> All of this works of course because in Haskell, "=" is not an assignment,
> it's a definition, and the RHS is not a variable, it's a pattern. And "4" is
> a perfectly legitimate pattern. Now, if only I could find a use for all this
> that borders on "useful"...! ;-)

I like this one:

let {1 + 1 = 3; 3 + 1 = 3} in 1 + 1 + 1

Right answer, for the wrong reasons.  Useful?  Well... does confusing
people count as useful?
From noteed at gmail.com  Thu Sep 18 15:21:47 2008
From: noteed at gmail.com (minh thu)
Date: Thu Sep 18 15:19:10 2008
Subject: [Haskell-cafe] An interesting curiosity
In-Reply-To: <2518b95d0809181218i4f20c85alc9c9a5e2cb9eb70e@mail.gmail.com>
References: <48D2A527.2040708@btinternet.com>
	<2518b95d0809181218i4f20c85alc9c9a5e2cb9eb70e@mail.gmail.com>
Message-ID: <40a414c20809181221u2734e64bo424696ecb10c2957@mail.gmail.com>

2008/9/18 Evan Laforge :
>> All of this works of course because in Haskell, "=" is not an assignment,
>> it's a definition, and the RHS is not a variable, it's a pattern. And "4" is
>> a perfectly legitimate pattern. Now, if only I could find a use for all this
>> that borders on "useful"...! ;-)
>
> I like this one:
>
> let {1 + 1 = 3; 3 + 1 = 3} in 1 + 1 + 1
>
> Right answer, for the wrong reasons.  Useful?  Well... does confusing
> people count as useful?

Well, Andrew says it himself : it's practical because you can pattern
match against specific value :

f [] = ...
f (4:xs) = ...
f (x:xs) = ...

Thu
From wchogg at gmail.com  Thu Sep 18 15:31:00 2008
From: wchogg at gmail.com (Creighton Hogg)
Date: Thu Sep 18 15:28:22 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <20080918185510.GE8398@scytale.galois.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
Message-ID: <814617240809181231s503b221chf23919983d80355c@mail.gmail.com>

On Thu, Sep 18, 2008 at 1:55 PM, Don Stewart  wrote:
> wchogg:
>> On Thu, Sep 18, 2008 at 1:29 PM, Don Stewart  wrote:

>> > This makes me cry.
>> >
>> >    import System.Environment
>> >    import qualified Data.ByteString.Lazy.Char8 as B
>> >
>> >    main = do
>> >        [f] <- getArgs
>> >        s   <- B.readFile f
>> >        print (B.count '\n' s)
>> >
>> > Compile it.
>> >
>> >    $ ghc -O2 --make A.hs
>> >
>> >    $ time ./A /usr/share/dict/words
>> >    52848
>> >    ./A /usr/share/dict/words 0.00s user 0.00s system 93% cpu 0.007 total
>> >
>> > Against standard tools:
>> >
>> >    $ time wc -l /usr/share/dict/words
>> >    52848 /usr/share/dict/words
>> >    wc -l /usr/share/dict/words 0.01s user 0.00s system 88% cpu 0.008 total
>>
>> So both you & Bryan do essentially the same thing and of course both
>> versions are far better than mine.  So the purpose of using the Lazy
>> version of ByteString was so that the file is only incrementally
>> loaded by readFile as count is processing?
>
> Yep, that's right
>
> The streaming nature is implicit in the lazy bytestring. It's kind of
> the dual of explicit chunkwise control -- chunk processing reified into
> the data structure.

To ask an overly general question, if lazy bytestring makes a nice
provider for incremental processing are there reasons to _not_ reach
for that as my default when processing large files?
From dons at galois.com  Thu Sep 18 15:34:42 2008
From: dons at galois.com (Don Stewart)
Date: Thu Sep 18 15:31:56 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181231s503b221chf23919983d80355c@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
	<814617240809181231s503b221chf23919983d80355c@mail.gmail.com>
Message-ID: <20080918193442.GF8398@scytale.galois.com>

wchogg:
> To ask an overly general question, if lazy bytestring makes a nice
> provider for incremental processing are there reasons to _not_ reach
> for that as my default when processing large files?

At the moment, it would always be my first choice. Consider,

    http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all

-- Don
From dons at galois.com  Thu Sep 18 15:35:47 2008
From: dons at galois.com (Don Stewart)
Date: Thu Sep 18 15:33:02 2008
Subject: [Haskell-cafe] a question about concurrent haskell
In-Reply-To: <48D2A576.4010100@libero.it>
References: <48D2A576.4010100@libero.it>
Message-ID: <20080918193547.GG8398@scytale.galois.com>

manlio_perillo:
> Hi.
> 
> I have a question about concurrent Haskell in GHC.
> 
> Suppose I want to write a native pure Haskell PostgreSQL client.
> I have done this for Python (using Twisted):
> http://hg.mperillo.ath.cx/twisted/pglib/
> 
> and I would like to do this in Haskell, as an exercise.
> 
> The main problem is with multiple concurrent queries to the same 
> connection, from multiple threads.
> 
> PostgreSQL supports multiple requests but it's better to execute only 
> one request at a time:
> http://www.postgresql.org/docs/8.3/interactive/protocol-flow.html#AEN73647
> 
> In the Twisted version I queue all the requests, and every time a 
> request completes I call the callback associated with the request and 
> execute the next available request.

I'd queue  or sychronise all threads requesting the underlying
non-thread safe resource by using either STM transactions, or an MVar.

-- Don
From bulat.ziganshin at gmail.com  Thu Sep 18 15:37:22 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Thu Sep 18 15:38:02 2008
Subject: [Haskell-cafe] a question about concurrent haskell
In-Reply-To: <48D2A576.4010100@libero.it>
References: <48D2A576.4010100@libero.it>
Message-ID: <1812911140.20080918233722@gmail.com>

Hello Manlio,

Thursday, September 18, 2008, 11:01:10 PM, you wrote:

you just need to handle it in a message-passing way. this type of
problem (serializing access to unique resource) is rather common, for
example it's used in GUI libs. std way is to create thread that will
do actual work in sequential way and provide channel for sending tasks
to this thread:

main = do
  chan <- newChan
  forkIO (forever$ getChan chan >>= id)
  ...

now you can put actions to chan and they will be executed sequentially


> Hi.

> I have a question about concurrent Haskell in GHC.

> Suppose I want to write a native pure Haskell PostgreSQL client.
> I have done this for Python (using Twisted):
> http://hg.mperillo.ath.cx/twisted/pglib/

> and I would like to do this in Haskell, as an exercise.

> The main problem is with multiple concurrent queries to the same 
> connection, from multiple threads.

> PostgreSQL supports multiple requests but it's better to execute only 
> one request at a time:
> http://www.postgresql.org/docs/8.3/interactive/protocol-flow.html#AEN73647


> In the Twisted version I queue all the requests, and every time a 
> request completes I call the callback associated with the request and 
> execute the next available request.

> But how do I solve this problem with concurrent Haskell?

> Suppose thread A execute a query, and while this query is still active,
> a thread B execute another query.

> I should suspend thread B (calling yield), but how do I resume it when
> the query executed by thread A completes?

> The GHC concurrent Haskell does not have a function to resume a given 
> thread (as found, as an example, in Lua).



> P.S.: another question.
> Why, in ghci, every time I call myThreadId, I get a different value?

> Prelude Control.Concurrent> myThreadId
> ThreadId 40
> Prelude Control.Concurrent> myThreadId
> ThreadId 41





> Thanks   Manlio Perillo
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From allbery at ece.cmu.edu  Thu Sep 18 15:51:36 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Thu Sep 18 15:49:01 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big   advantages?
In-Reply-To: <48D2A78F.7090907@libero.it>
References: <20080917053300.GC2213@scytale.galois.com>	<48D0FEF5.5080707@libero.it>	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>		<1221678201.18670.12.camel@jcchost>		<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>	<1221684951.18670.41.camel@jcchost>
	<48D22062.6030109@gmail.com> <48D2A78F.7090907@libero.it>
Message-ID: 

On Sep 18, 2008, at 15:10 , Manlio Perillo wrote:
>> Allocation areas are per-CPU, not per-thread.  A Concurrent Haskell  
>> thread consists of a TSO (thread state object, currently 11 machine  
>> words), and a stack, which we currently start with 1KB and grow on  
>> demand.
>
> How is this implemented?
>
> I have seen some coroutine implementations in C, using functions  
> from ucontext.h (or direct asm code), but all have the problem that  
> the allocated stack is fixed.


That's because it's much easier to use a fixed stack.

There are two ways to handle a growable stack; both start with  
allocating each stack in a separate part of the address space with  
room to grow it downward.  The simpler way uses stack probes on  
function entry to detect impending stack overflow.  The harder (and  
less portable) one involves trapping page faults ("segmentation  
violation" on POSIX), enlarging the stack, and restarting the  
instruction that caused the trap; this requires fairly detailed  
knowledge of the CPU and the way signals or page faults are handled by  
the OS.  (There's also a hybrid which many POSIXish systems use,  
trapping the page fault specifically when running the stack probe; the  
probe is designed to be safe to either restart or ignore, so it can be  
handled more portably.)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From dagit at codersbase.com  Thu Sep 18 16:07:29 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Thu Sep 18 16:04:51 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
	<396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
Message-ID: 

On Thu, Sep 18, 2008 at 11:30 AM, Adam Langley  wrote:
> On Thu, Sep 18, 2008 at 10:05 AM, Judah Jacobson
>  wrote:
>> Just a guess, but this might be a problem with control-timeout's use
>> of the unsafePerformIO global variables hack.  It's missing the
>> standard NOINLINE annotations which prevent multiple copies of the
>> global variable from being created.  See the haddock docs for
>> System.IO.Unsafe.unsafePerformIO for more information.
>
> That might well be it, should be an easy fix to try.
>
> I'm afraid that I don't have enough time to do justice to my packages
> on Hackage these days so I've just sent an email requesting that they
> be removed. Anyone who wants to maintain any of them should grab it
> now. The repos are all at http://darcs.imperialviolet.org

Could you please send a separate message, and hence a new thread, to
Haskell-Cafe asking for new maintainers to these libraries?  If you're
ready to hand over the role, that's the action which is most fair to
the community at large.

Thanks for your hard work and good luck in your other projects!

Jason
PS If you sent that email already and I missed it, then please disregard this.
From dominic.steinitz at blueyonder.co.uk  Thu Sep 18 16:25:16 2008
From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz)
Date: Thu Sep 18 16:22:49 2008
Subject: [Haskell-cafe] Re: control-timeout with gtk
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
	<396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
Message-ID: 

Adam Langley  imperialviolet.org> writes:

> be removed. Anyone who wants to maintain any of them should grab it
> now. The repos are all at http://darcs.imperialviolet.org
> 
> On the chopping block:
> 
> binary-strict

Adam,

I don't particularly want to maintain this as I have negative amounts of free 
time but I'll look after it as best I can if no-one else is in a position to 
pick it up.

Dominic

From jgoerzen at complete.org  Thu Sep 18 16:32:31 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Thu Sep 18 16:29:55 2008
Subject: [Haskell-cafe] Hackage and HaXml situation
Message-ID: <48D2BADF.5080009@complete.org>

Hi everyone,

We've got a bit of a problem in the community regarding HaXml.  This has
been brought up before, but never definitively resolved, and it's
causing more and more trouble.

Over at the HaXml homepage [1], it is stated that 1.13.3 is the most
recent stable version of HaXml.  I believe that Malcolm Wallace, HaXml
maintainer, has confirmed this.

Over at the HaXml hackage page [2], it would appear as if 1.19.4 is the
most recent stable version of HaXml.  There is no provision made to mark
some versions as unstable, and to make 1.13.3 the default version
downloaded from Hackage.

There are API incompatibilities between 1.13.3 and 1.19.4 that make it
impossible for my programs to support both.

This is becoming a larger and more fragmenting problem.  Arch Linux
looked at the Hackage package and bundled up 1.19.4.  Debian looked at
the HaXml website and bundles 1.13.3.  So we have a situation where I
can write software that builds easily with one or the other, but not both.

We really need a fix for this.  Some things we could do would be:

1) Make a policy that Hackage is for the "most stable branch" of
software only, and remove the 1.19.x series of HaXml.

2) Malcolm could decide to bless 1.19.x as stable, fixing the instant
problem, but this would still leave the problem open for the future.

3) Add support to Hackage for labeling branches, and present the stable
versions by default.

Thoughts?

[1] http://www.cs.york.ac.uk/fp/HaXml/
[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml
From dagit at codersbase.com  Thu Sep 18 16:33:37 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Thu Sep 18 16:31:04 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181231s503b221chf23919983d80355c@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
	<814617240809181231s503b221chf23919983d80355c@mail.gmail.com>
Message-ID: 

On Thu, Sep 18, 2008 at 12:31 PM, Creighton Hogg  wrote:
> On Thu, Sep 18, 2008 at 1:55 PM, Don Stewart  wrote:
>> wchogg:
>>> On Thu, Sep 18, 2008 at 1:29 PM, Don Stewart  wrote:
> 
>>> > This makes me cry.
>>> >
>>> >    import System.Environment
>>> >    import qualified Data.ByteString.Lazy.Char8 as B
>>> >
>>> >    main = do
>>> >        [f] <- getArgs
>>> >        s   <- B.readFile f
>>> >        print (B.count '\n' s)
>>> >
>>> > Compile it.
>>> >
>>> >    $ ghc -O2 --make A.hs
>>> >
>>> >    $ time ./A /usr/share/dict/words
>>> >    52848
>>> >    ./A /usr/share/dict/words 0.00s user 0.00s system 93% cpu 0.007 total
>>> >
>>> > Against standard tools:
>>> >
>>> >    $ time wc -l /usr/share/dict/words
>>> >    52848 /usr/share/dict/words
>>> >    wc -l /usr/share/dict/words 0.01s user 0.00s system 88% cpu 0.008 total
>>>
>>> So both you & Bryan do essentially the same thing and of course both
>>> versions are far better than mine.  So the purpose of using the Lazy
>>> version of ByteString was so that the file is only incrementally
>>> loaded by readFile as count is processing?
>>
>> Yep, that's right
>>
>> The streaming nature is implicit in the lazy bytestring. It's kind of
>> the dual of explicit chunkwise control -- chunk processing reified into
>> the data structure.
>
> To ask an overly general question, if lazy bytestring makes a nice
> provider for incremental processing are there reasons to _not_ reach
> for that as my default when processing large files?

Yes.  The main time is when you "accidentally" force the whole file
(or at least large parts of it) into memory at the same time.
Profiling and careful programming seem to be the workarounds, but in a
large application the "careful programming" part can become
prohibitively expensive.  This is due to the sometimes subtle nature
of how strictness composes with laziness.  This is a the result of a
more general issue that it is non-obvious how your program is
evaluated at run-time thanks to lazy evaluation, thus making lazy
evaluation act as a double edged sword at times.  I'm not saying get
rid of lazy eval, but occasionally it presents problems for efficiency
and diagnosing efficiency problems.

The rule seems to be:  Write correct code first, fix the problems
(usually just inefficiencies) later.

Using lazy bytestrings makes it easier to write concise code that is
more easily inspected for correctness.  Perhaps it is even easier to
test such code, but I'm skeptical of that.  Thus, I think most people
here would agree that reaching first for lazy byte string is preferred
over other techniques.  Plus, the one of the most common fixes to
inefficient haskell programs is to make them lazy in the right places
and strict in key places and using lazy bytestring will get you part
of the way to that refactoring usually.

Jason
From dons at galois.com  Thu Sep 18 16:38:42 2008
From: dons at galois.com (Don Stewart)
Date: Thu Sep 18 16:36:31 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: 
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
	<814617240809181231s503b221chf23919983d80355c@mail.gmail.com>
	
Message-ID: <20080918203842.GL8398@scytale.galois.com>

dagit:
> On Thu, Sep 18, 2008 at 12:31 PM, Creighton Hogg  wrote:
> > On Thu, Sep 18, 2008 at 1:55 PM, Don Stewart  wrote:
> >> wchogg:
> >>> On Thu, Sep 18, 2008 at 1:29 PM, Don Stewart  wrote:
> > 
> >>> > This makes me cry.
> >>> >
> >>> >    import System.Environment
> >>> >    import qualified Data.ByteString.Lazy.Char8 as B
> >>> >
> >>> >    main = do
> >>> >        [f] <- getArgs
> >>> >        s   <- B.readFile f
> >>> >        print (B.count '\n' s)
> >>> >
> >>> > Compile it.
> >>> >
> >>> >    $ ghc -O2 --make A.hs
> >>> >
> >>> >    $ time ./A /usr/share/dict/words
> >>> >    52848
> >>> >    ./A /usr/share/dict/words 0.00s user 0.00s system 93% cpu 0.007 total
> >>> >
> >>> > Against standard tools:
> >>> >
> >>> >    $ time wc -l /usr/share/dict/words
> >>> >    52848 /usr/share/dict/words
> >>> >    wc -l /usr/share/dict/words 0.01s user 0.00s system 88% cpu 0.008 total
> >>>
> >>> So both you & Bryan do essentially the same thing and of course both
> >>> versions are far better than mine.  So the purpose of using the Lazy
> >>> version of ByteString was so that the file is only incrementally
> >>> loaded by readFile as count is processing?
> >>
> >> Yep, that's right
> >>
> >> The streaming nature is implicit in the lazy bytestring. It's kind of
> >> the dual of explicit chunkwise control -- chunk processing reified into
> >> the data structure.
> >
> > To ask an overly general question, if lazy bytestring makes a nice
> > provider for incremental processing are there reasons to _not_ reach
> > for that as my default when processing large files?
> 
> Yes.  The main time is when you "accidentally" force the whole file
> (or at least large parts of it) into memory at the same time.
> Profiling and careful programming seem to be the workarounds, but in a
> large application the "careful programming" part can become
> prohibitively expensive.  This is due to the sometimes subtle nature
> of how strictness composes with laziness.  This is a the result of a
> more general issue that it is non-obvious how your program is
> evaluated at run-time thanks to lazy evaluation, thus making lazy
> evaluation act as a double edged sword at times.  I'm not saying get
> rid of lazy eval, but occasionally it presents problems for efficiency
> and diagnosing efficiency problems.
> 
> The rule seems to be:  Write correct code first, fix the problems
> (usually just inefficiencies) later.
> 
> Using lazy bytestrings makes it easier to write concise code that is
> more easily inspected for correctness.  Perhaps it is even easier to
> test such code, but I'm skeptical of that.  Thus, I think most people
> here would agree that reaching first for lazy byte string is preferred
> over other techniques.  Plus, the one of the most common fixes to
> inefficient haskell programs is to make them lazy in the right places
> and strict in key places and using lazy bytestring will get you part
> of the way to that refactoring usually.

Work on the "dual" of lazy bytestrings -- chunked enumerators -- may
lead to more options in this area. 

The question of compositionality of left-fold enumerators remains
(afaik), but we'll see. 

-- Don
From dpiponi at gmail.com  Thu Sep 18 17:07:05 2008
From: dpiponi at gmail.com (Dan Piponi)
Date: Thu Sep 18 17:04:26 2008
Subject: [Haskell-cafe] An interesting curiosity
In-Reply-To: <48D2A527.2040708@btinternet.com>
References: <48D2A527.2040708@btinternet.com>
Message-ID: <625b74080809181407w7a66c4a8j8d856328c170cbdb@mail.gmail.com>

On Thu, Sep 18, 2008 at 11:59 AM, Andrew Coppin
 wrote:
>  foo :: Int -> Maybe Int
>  foo x = do
>   4 <- return x
>   return (2*x)
>
> Now, if only I could find a use for all this
> that borders on "useful"...! ;-)

It seems a lot less weird when you write something like:

[x | (x,0) <- map (`divMod` n) [1..20]]

which picks out 1/nth of each of the elements of [1..20] that are
divisible by n.
--
Dan
From andre at digirati.com.br  Thu Sep 18 17:06:00 2008
From: andre at digirati.com.br (Andre Nathan)
Date: Thu Sep 18 17:04:48 2008
Subject: [Haskell-cafe] Library design question
In-Reply-To: 
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	
Message-ID: <1221771960.5910.1.camel@homesick>

On Thu, 2008-09-18 at 21:15 +0200, Henning Thielemann wrote:
> Think of the state monad as processing a graph in-place. Which graph is 
> addressed is declared when running the State monad using runState or 
> evalState.

Interesting. Is it good practice then to do something like

  type GraphM a b = State (Graph a b)

to hide from the user that I'm using the State monad underneath?

Best,
Andre

From andre at digirati.com.br  Thu Sep 18 17:10:52 2008
From: andre at digirati.com.br (Andre Nathan)
Date: Thu Sep 18 17:09:40 2008
Subject: [Haskell-cafe] Library design question
In-Reply-To: <40a414c20809181213n2a02ffc5pd0b59c68ba23d236@mail.gmail.com>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<40a414c20809181213n2a02ffc5pd0b59c68ba23d236@mail.gmail.com>
Message-ID: <1221772252.5910.7.camel@homesick>

On Thu, 2008-09-18 at 21:13 +0200, minh thu wrote:
> If you need the one inside the State monad, you can reuse the new
> version of addVertex.

You mean making the graph creation functions (which will call
addVertex/Edge) use the State monad instead? Interesting idea... what I
really wanted was to hide from the user how the graph library is
implemented, so he wouldn't need to know about the state monad to use
the library, but maybe I should keep these basic functions pure and let
the user decide. I'll think about it :)

Best,
Andre

From lemming at henning-thielemann.de  Thu Sep 18 18:01:14 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu Sep 18 17:58:37 2008
Subject: [Haskell-cafe] Library design question
In-Reply-To: <1221771960.5910.1.camel@homesick>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	
	<1221771960.5910.1.camel@homesick>
Message-ID: 


On Thu, 18 Sep 2008, Andre Nathan wrote:

> On Thu, 2008-09-18 at 21:15 +0200, Henning Thielemann wrote:
>> Think of the state monad as processing a graph in-place. Which graph is
>> addressed is declared when running the State monad using runState or
>> evalState.
>
> Interesting. Is it good practice then to do something like
>
>  type GraphM a b = State (Graph a b)
>
> to hide from the user that I'm using the State monad underneath?

'type' won't hide anything but reduces writing. With 'newtype' you could 
hide the State monad. You could do this, if you plan to change the 
representation of a Graph to something based on mutable structures. On the 
other hand with 'newtype GraphM' the user could not easily work on several 
states of the graph simultaneously.
From wchogg at gmail.com  Thu Sep 18 18:09:18 2008
From: wchogg at gmail.com (Creighton Hogg)
Date: Thu Sep 18 18:06:38 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <20080918185510.GE8398@scytale.galois.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
Message-ID: <814617240809181509wb745e40sf7df955252cd5cb8@mail.gmail.com>

On Thu, Sep 18, 2008 at 1:55 PM, Don Stewart  wrote:
> wchogg:
>> On Thu, Sep 18, 2008 at 1:29 PM, Don Stewart  wrote:
>> > wchogg:
>> >> Hey Haskell,
>> >> So for a fairly inane reason, I ended up taking a couple of minutes
>> >> and writing a program that would spit out, to the console, the number
>> >> of lines in a file.  Off the top of my head, I came up with this which
>> >> worked fine with files that had 100k lines:
>> >>
>> >> main = do
>> >>  path <- liftM head $ getArgs
>> >>  h <- openFile path ReadMode
>> >>  n <- execStateT (countLines h) 0
>> >>  print n
>> >>
>> >> untilM :: Monad m => (a -> m Bool) -> (a -> m ()) -> a -> m ()
>> >> untilM cond action val = do
>> >>  truthy <- cond val
>> >>  if truthy then return () else action val >> (untilM cond action val)
>> >>
>> >> countLines :: Handle -> StateT Int IO ()
>> >> countLines = untilM (\h -> lift $ hIsEOF h) (\h -> do
>> >>                                                 lift $ hGetLine h
>> >>                                                 modify (+1))
>> >>
>> >> If this makes anyone cringe or cry "you're doing it wrong", I'd
>> >> actually like to hear it.  I never really share my projects, so I
>> >> don't know how idiosyncratic my style is.
>> >
>> > This makes me cry.
>> >
>> >    import System.Environment
>> >    import qualified Data.ByteString.Lazy.Char8 as B
>> >
>> >    main = do
>> >        [f] <- getArgs
>> >        s   <- B.readFile f
>> >        print (B.count '\n' s)
>> >
>> > Compile it.
>> >
>> >    $ ghc -O2 --make A.hs
>> >
>> >    $ time ./A /usr/share/dict/words
>> >    52848
>> >    ./A /usr/share/dict/words 0.00s user 0.00s system 93% cpu 0.007 total
>> >
>> > Against standard tools:
>> >
>> >    $ time wc -l /usr/share/dict/words
>> >    52848 /usr/share/dict/words
>> >    wc -l /usr/share/dict/words 0.01s user 0.00s system 88% cpu 0.008 total
>>
>> So both you & Bryan do essentially the same thing and of course both
>> versions are far better than mine.  So the purpose of using the Lazy
>> version of ByteString was so that the file is only incrementally
>> loaded by readFile as count is processing?
>
> Yep, that's right
>
> The streaming nature is implicit in the lazy bytestring. It's kind of
> the dual of explicit chunkwise control -- chunk processing reified into
> the data structure.

Hi Don,
I have a bit more of a followup, actually.  You make use of the built
in bytestring consumer count, which itself is built upon the
foldlChunks function which is only exported in the
ByteString.Lazy.Internal.  If I want to make my own efficient
bytestring consumer, is that what I need to use in order to preserve
the inherent laziness of the datastructure?

Also, I feel a little at a loss for how to make a good bytestring
producer for efficiently _writing_ large swaths of data via writeFile.
 Would it be possible to whip up a small example?

Oh, and lastly, I apologize to both you & Bryan for making you cry.  I
hope you can forgive my cruelty.

Thanks,
Creighton
From dons at galois.com  Thu Sep 18 18:11:47 2008
From: dons at galois.com (Don Stewart)
Date: Thu Sep 18 18:09:02 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181509wb745e40sf7df955252cd5cb8@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
	<814617240809181509wb745e40sf7df955252cd5cb8@mail.gmail.com>
Message-ID: <20080918221147.GF9005@scytale.galois.com>

wchogg:
> 
> Hi Don,
> I have a bit more of a followup, actually.  You make use of the built
> in bytestring consumer count, which itself is built upon the
> foldlChunks function which is only exported in the
> ByteString.Lazy.Internal.  If I want to make my own efficient
> bytestring consumer, is that what I need to use in order to preserve
> the inherent laziness of the datastructure?

you can get foldChunks from Data.ByteString.Lazy.Internal,
or write your own chunk folder.
  
> Also, I feel a little at a loss for how to make a good bytestring
> producer for efficiently _writing_ large swaths of data via writeFile.
>  Would it be possible to whip up a small example?

Using unfoldr? Or Data.Binary?
  
> Oh, and lastly, I apologize to both you & Bryan for making you cry.  I
> hope you can forgive my cruelty.

:)
From s.clover at gmail.com  Thu Sep 18 18:30:12 2008
From: s.clover at gmail.com (Sterling Clover)
Date: Thu Sep 18 18:27:39 2008
Subject: [Haskell-cafe] Re: HStringTemplate to generate html tables
In-Reply-To: <9a0b86ed0809180516x2c494819w75a0091a97c927e4@mail.gmail.com>
References: <9a0b86ed0809180516x2c494819w75a0091a97c927e4@mail.gmail.com>
Message-ID: 

Hmm...  an untested suggestion...

$cells:{ row | $row:{ cell | }$}$

$cell$


(i.e. nested iteration)

or to encompass the table call inside,
$cells:{ row | $row:{ cell |
$cell$}$}:{$it$
}$

Regards,
Sterl.

On Thu, Sep 18, 2008 at 8:16 AM, Thomas Hartman <
thomashartman1@googlemail.com> wrote:

> I am trying to use HStringTemplate for generating html tables, for use
> in http://happstutorial.com:5001
>
> The best I could do is below. Seems awfully kludgy.
>
> Can someone suggest a better way, which keeps me inside the
> StringTemplate way of doing things? (Eg, no suggestions to use HTML.*
> libraries, which are nice for some things but are a higher barrier to
> entry than just jumping in and writing html.)
>
> Some kind of map structure... for each... ?
>
> Thanks for any help!
>
> thomas.
>
> {-# LANGUAGE NoMonomorphismRestriction #-}
> import Text.StringTemplate
> import Control.Applicative
> import qualified Text.PrettyPrint as PP
>
> main = putStrLn . PP.render . toPPDoc $ tableFromCells cells
> cells = [["mee","mah","moh"],["fee","fah","foh"]]
>
> -- This does generate an html table, but seems horribly obfuscated.
> -- is there machinery for doing things like html table generation
> -- in some better way than this hack where 
> -- tags are used as a separator?
> -- I would imagine something like
> -- newSTMP "$cells:{$it$}:{$it}:{$it
}"
> -- which works a bit like a list comprehension
> tableFromCells cells = setAttribute "cells" cells . optInsertTmpl
> [("separator","")]
>  $ newSTMP "$cells:\
>              \{$it$}:\
>                \{$it$
}$"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/171a729a/attachment.htm
From haskell at drk934h.yepmail.net  Thu Sep 18 18:33:54 2008
From: haskell at drk934h.yepmail.net (Rob deFriesse)
Date: Thu Sep 18 18:31:16 2008
Subject: [Haskell-cafe] Specifying a function type in a where clause.
Message-ID: <48D2D752.70502@drk934h.yepmail.net>

I would like to know why I'm getting a particular compile time error 
message.

In this program, I am specifying a function type on /combs'/ in the 
where clause:

--------
module Main where

import List (delete)

combs :: Eq a => [a] -> Int -> [[a]]
combs l 1 = map (\x -> [x]) l
combs l n = foldl combs' [] l
    where combs' :: Eq a => [[a]] -> a -> [[a]]
          combs' acc x = let sl = delete x l in (map (\i -> x:i) $ combs 
sl (n-1)) ++ acc

main = do
  print $ combs ["a","b","c","d"] 3
--------

I get this error message from GHC 6.8.3:

cafe1.hs:9:43:
    Couldn't match expected type `a1' against inferred type `a'
      `a1' is a rigid type variable bound by
           the type signature for `combs'' at cafe1.hs:8:23
      `a' is a rigid type variable bound by
          the type signature for `combs' at cafe1.hs:5:12
      Expected type: [a1]
      Inferred type: [a]
    In the second argument of `delete', namely `l'
    In the expression: delete x l

I don't understand why I'm seeing this.  The type /a/ is the same type 
in /combs/ and /combs'/.  I realize I can remove the type specification 
from /combs'/, and the code will compile.  However, I'd like to get a 
better understanding of why GHC objects to this.

Thank you,
Rob.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/5d984576/attachment.htm
From marco-oweber at gmx.de  Thu Sep 18 18:40:42 2008
From: marco-oweber at gmx.de (Marc Weber)
Date: Thu Sep 18 18:38:05 2008
Subject: [Haskell-cafe] Hackage and HaXml situation
In-Reply-To: <48D2BADF.5080009@complete.org>
References: <48D2BADF.5080009@complete.org>
Message-ID: <20080918224042.GB8848@gmx.de>

In your particular problem there is another way:
Ask the distributors to ship both HaXmL versions..
(Most systems will install one only by default (an update supersedes the
older one :-( ) But most distributions do let you install two or more
versions (?)

I think the way to go is beeing able to represent all the work you've
done.
I'd like to add a pointer to vxml on hackage. But it's still way to
unstable for a release.
How would branches look like?
We no longer have

0.1
0.2
0.5
...

But each version has a set of children and a set of parents (merges) ?

So hackage would no longer show

other versions: ... ... ...
but
childs:  branchX-0.3 branchY-0.4 branchZ-0.8
parents: .... ?

On the other hand the more packages / branches are on hackage the more
work packagers have to do..

Marc
From daniel.is.fischer at web.de  Thu Sep 18 18:55:09 2008
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Thu Sep 18 18:50:25 2008
Subject: [Haskell-cafe] Specifying a function type in a where clause.
In-Reply-To: <48D2D752.70502@drk934h.yepmail.net>
References: <48D2D752.70502@drk934h.yepmail.net>
Message-ID: <200809190055.09765.daniel.is.fischer@web.de>

Am Freitag, 19. September 2008 00:33 schrieb Rob deFriesse:
> I would like to know why I'm getting a particular compile time error
> message.
>
> In this program, I am specifying a function type on /combs'/ in the
> where clause:
>
> --------
> module Main where
>
> import List (delete)
>
> combs :: Eq a => [a] -> Int -> [[a]]
> combs l 1 = map (\x -> [x]) l
> combs l n = foldl combs' [] l
>     where combs' :: Eq a => [[a]] -> a -> [[a]]
>           combs' acc x = let sl = delete x l in (map (\i -> x:i) $ combs
> sl (n-1)) ++ acc
>
> main = do
>   print $ combs ["a","b","c","d"] 3
> --------
>
> I get this error message from GHC 6.8.3:
>
> cafe1.hs:9:43:
>     Couldn't match expected type `a1' against inferred type `a'
>       `a1' is a rigid type variable bound by
>            the type signature for `combs'' at cafe1.hs:8:23
>       `a' is a rigid type variable bound by
>           the type signature for `combs' at cafe1.hs:5:12
>       Expected type: [a1]
>       Inferred type: [a]
>     In the second argument of `delete', namely `l'
>     In the expression: delete x l
>
> I don't understand why I'm seeing this.  The type /a/ is the same type
> in /combs/ and /combs'/.

Not quite. As it is, the type signature of combs' promises that for all types 
b which belong to Eq, combs' has type [[b]] -> b -> [[b]], because the a from 
the top level type signature is not in scope. Therefore, ghc complains about 
the use of l in the definition of combs', since l has a specific type.
You can either remove the signature for combs' or bring the type variable a 
into scope by the pragma {-# LANGUAGE ScopedTypeVariables #-} at the top of 
your file or the flag -XScopedTypeVariables on the command line and changing 
the signature of combs to
combs :: forall a. (Eq a) => [a] -> Int -> [[a]],
I think then you must leave off the (Eq a) from the signature of combs'.

>  I realize I can remove the type specification
> from /combs'/, and the code will compile.  However, I'd like to get a
> better understanding of why GHC objects to this.
>
> Thank you,
> Rob.

From duncan.coutts at worc.ox.ac.uk  Thu Sep 18 18:20:20 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Sep 18 19:00:19 2008
Subject: [Haskell-cafe] Hackage and HaXml situation
In-Reply-To: <48D2BADF.5080009@complete.org>
References: <48D2BADF.5080009@complete.org>
Message-ID: <1221776420.5395.513.camel@localhost>

On Thu, 2008-09-18 at 15:32 -0500, John Goerzen wrote:
> Hi everyone,
> 
> We've got a bit of a problem in the community regarding HaXml.  This has
> been brought up before, but never definitively resolved, and it's
> causing more and more trouble.
> 
> Over at the HaXml homepage [1], it is stated that 1.13.3 is the most
> recent stable version of HaXml.  I believe that Malcolm Wallace, HaXml
> maintainer, has confirmed this.
> 
> Over at the HaXml hackage page [2], it would appear as if 1.19.4 is the
> most recent stable version of HaXml.  There is no provision made to mark
> some versions as unstable, and to make 1.13.3 the default version
> downloaded from Hackage.

But there should be. I have a plan and I intend to implement it.

Basically for each package we have an optional suggested version
constraint. This would be used in the hackage website to direct people
to the 'current' version but most importantly it'd be used by
cabal-install and other cabal -> native package conversion tools. It
wold be editable on the hackage website by the package author/maintainer
and probably other ?people with the role of managing the hackage
collection.

Cases like HaXml-1.13 -> 1.19 (or a future stable version) or old-time
-> time are also things that the platform might be able to help with in
future by managing the transition in a more coherent way rather than
what we have now where the transition is rather hap-hazard with half
using one and half the other.

Duncan

From duncan.coutts at worc.ox.ac.uk  Thu Sep 18 18:25:16 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Sep 18 19:00:26 2008
Subject: [Haskell-cafe] Library design question
In-Reply-To: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
Message-ID: <1221776716.5395.518.camel@localhost>

On Thu, 2008-09-18 at 15:43 -0300, Andre Nathan wrote:

> My Graph type is the following.
> 
>   data Graph a b = Graph
>     { adjacencies :: Map Int (a, (Map Int b))
>     , numVertices :: Int
>     , numEdges    :: Int
>     }

>   addVertex :: Int -> a -> State (Graph a b) ()
>   addVertex vertex label = do
>     g <- get
>     let adj = Map.insert vertex (label, Map.empty) (adjacencies g)
>     put $ g { adjacencies = adj, numVertices = numVertices g + 1 }

> So I'm confused right now about how I should proceed. Any hints
> regarding that?

To be honest I would not bother with the state monad and just make them
pure operations returning new graphs:

?addVertex :: Int -> a -> Graph a b -> ?Graph a b

?It's very common to have this style, ie returning a new/updated
structure explicitly rather than implicitly in a state monad. Just look
at the Data.Map api for example. If you later want to stick it in a
state monad then that would be straightforward but also easy to use
directly.

Duncan

From ryani.spam at gmail.com  Thu Sep 18 19:09:14 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Thu Sep 18 19:06:37 2008
Subject: [Haskell-cafe] Specifying a function type in a where clause.
In-Reply-To: <200809190055.09765.daniel.is.fischer@web.de>
References: <48D2D752.70502@drk934h.yepmail.net>
	<200809190055.09765.daniel.is.fischer@web.de>
Message-ID: <2f9b2d30809181609u777fb704i84e31ba302f17565@mail.gmail.com>

The Haskell98 solution is to use "asTypeOf" to document types in
helper functions

combs' acc x = let sl = delete (x `asTypeOf` head l) l in ...

Using ScopedTypeVariables is much nicer, though.

  -- ryan

On Thu, Sep 18, 2008 at 3:55 PM, Daniel Fischer
 wrote:
> Am Freitag, 19. September 2008 00:33 schrieb Rob deFriesse:
>> I would like to know why I'm getting a particular compile time error
>> message.
>>
>> In this program, I am specifying a function type on /combs'/ in the
>> where clause:
>>
>> --------
>> module Main where
>>
>> import List (delete)
>>
>> combs :: Eq a => [a] -> Int -> [[a]]
>> combs l 1 = map (\x -> [x]) l
>> combs l n = foldl combs' [] l
>>     where combs' :: Eq a => [[a]] -> a -> [[a]]
>>           combs' acc x = let sl = delete x l in (map (\i -> x:i) $ combs
>> sl (n-1)) ++ acc
>>
>> main = do
>>   print $ combs ["a","b","c","d"] 3
>> --------
>>
>> I get this error message from GHC 6.8.3:
>>
>> cafe1.hs:9:43:
>>     Couldn't match expected type `a1' against inferred type `a'
>>       `a1' is a rigid type variable bound by
>>            the type signature for `combs'' at cafe1.hs:8:23
>>       `a' is a rigid type variable bound by
>>           the type signature for `combs' at cafe1.hs:5:12
>>       Expected type: [a1]
>>       Inferred type: [a]
>>     In the second argument of `delete', namely `l'
>>     In the expression: delete x l
>>
>> I don't understand why I'm seeing this.  The type /a/ is the same type
>> in /combs/ and /combs'/.
>
> Not quite. As it is, the type signature of combs' promises that for all types
> b which belong to Eq, combs' has type [[b]] -> b -> [[b]], because the a from
> the top level type signature is not in scope. Therefore, ghc complains about
> the use of l in the definition of combs', since l has a specific type.
> You can either remove the signature for combs' or bring the type variable a
> into scope by the pragma {-# LANGUAGE ScopedTypeVariables #-} at the top of
> your file or the flag -XScopedTypeVariables on the command line and changing
> the signature of combs to
> combs :: forall a. (Eq a) => [a] -> Int -> [[a]],
> I think then you must leave off the (Eq a) from the signature of combs'.
>
>>  I realize I can remove the type specification
>> from /combs'/, and the code will compile.  However, I'd like to get a
>> better understanding of why GHC objects to this.
>>
>> Thank you,
>> Rob.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From jgoerzen at complete.org  Thu Sep 18 19:12:00 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Thu Sep 18 19:09:27 2008
Subject: [Haskell-cafe] Hackage and HaXml situation
In-Reply-To: <20080918224042.GB8848@gmx.de>
References: <48D2BADF.5080009@complete.org> <20080918224042.GB8848@gmx.de>
Message-ID: <48D2E040.9010603@complete.org>

Marc Weber wrote:
> In your particular problem there is another way:
> Ask the distributors to ship both HaXmL versions..
> (Most systems will install one only by default (an update supersedes the
> older one :-( ) But most distributions do let you install two or more
> versions (?)

Yes, most distributions package only one at a time, and yes most could
package more than one.  Perhaps that would even work with HaXml.

BUT:

1) There is still significant end-user confusion

2) This approach doesn't scale once we start thinking of more packages

> I think the way to go is beeing able to represent all the work you've
> done.
> I'd like to add a pointer to vxml on hackage. But it's still way to
> unstable for a release.

See, I don't think that Hackage should discourage posting unstable code
-- just discourage posting code that is less stable than the previous
release.

I think there is very little code too unstable for release!  Release
early, release often.  I wrote my first ever Xlib client in C the other
day.  It's up at git://git.complete.org/ledmon.  My first ever patches
to xmobar are up at http://darcs.complete.org/xmobar.  Don't let
unstable scare you off from releasing.

> How would branches look like?
> We no longer have
> 
> 0.1
> 0.2
> 0.5
> ...
> 
> But each version has a set of children and a set of parents (merges) ?

Simplest way to do this would be to define a boolean flag: "stable" or
"unstable".  Similarities to Debian here.

More complex, you could let authors define branches.  The default branch
is presented, well, by default.  Others are visible.  Similarities to
Freshmeat here.

I don't know that this has to be terribly complex.  Just something to
get us out of the current situation and prevent it from happening again.

-- John
From ryani.spam at gmail.com  Thu Sep 18 19:14:08 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Thu Sep 18 19:11:30 2008
Subject: [Haskell-cafe] Specifying a function type in a where clause.
In-Reply-To: <2f9b2d30809181609u777fb704i84e31ba302f17565@mail.gmail.com>
References: <48D2D752.70502@drk934h.yepmail.net>
	<200809190055.09765.daniel.is.fischer@web.de>
	<2f9b2d30809181609u777fb704i84e31ba302f17565@mail.gmail.com>
Message-ID: <2f9b2d30809181614n398b071bw1c74d38b48feac6c@mail.gmail.com>

Also, in Haskell98 you can also use this hack to document & coerce the
typechecker:

combs' acc x | const False (acc `asTypeOf` [l]) = undefined `asTypeOf` [l]
combs' acc x | const False (x `asTypeOf` head l) = undefined
combs' acc x = ... definition as before

The compiler should remove the "const False" branches so they don't
use up performance.

  -- ryan

On Thu, Sep 18, 2008 at 4:09 PM, Ryan Ingram  wrote:
> The Haskell98 solution is to use "asTypeOf" to document types in
> helper functions
>
> combs' acc x = let sl = delete (x `asTypeOf` head l) l in ...
>
> Using ScopedTypeVariables is much nicer, though.
>
>  -- ryan
>
> On Thu, Sep 18, 2008 at 3:55 PM, Daniel Fischer
>  wrote:
>> Am Freitag, 19. September 2008 00:33 schrieb Rob deFriesse:
>>> I would like to know why I'm getting a particular compile time error
>>> message.
>>>
>>> In this program, I am specifying a function type on /combs'/ in the
>>> where clause:
>>>
>>> --------
>>> module Main where
>>>
>>> import List (delete)
>>>
>>> combs :: Eq a => [a] -> Int -> [[a]]
>>> combs l 1 = map (\x -> [x]) l
>>> combs l n = foldl combs' [] l
>>>     where combs' :: Eq a => [[a]] -> a -> [[a]]
>>>           combs' acc x = let sl = delete x l in (map (\i -> x:i) $ combs
>>> sl (n-1)) ++ acc
>>>
>>> main = do
>>>   print $ combs ["a","b","c","d"] 3
>>> --------
>>>
>>> I get this error message from GHC 6.8.3:
>>>
>>> cafe1.hs:9:43:
>>>     Couldn't match expected type `a1' against inferred type `a'
>>>       `a1' is a rigid type variable bound by
>>>            the type signature for `combs'' at cafe1.hs:8:23
>>>       `a' is a rigid type variable bound by
>>>           the type signature for `combs' at cafe1.hs:5:12
>>>       Expected type: [a1]
>>>       Inferred type: [a]
>>>     In the second argument of `delete', namely `l'
>>>     In the expression: delete x l
>>>
>>> I don't understand why I'm seeing this.  The type /a/ is the same type
>>> in /combs/ and /combs'/.
>>
>> Not quite. As it is, the type signature of combs' promises that for all types
>> b which belong to Eq, combs' has type [[b]] -> b -> [[b]], because the a from
>> the top level type signature is not in scope. Therefore, ghc complains about
>> the use of l in the definition of combs', since l has a specific type.
>> You can either remove the signature for combs' or bring the type variable a
>> into scope by the pragma {-# LANGUAGE ScopedTypeVariables #-} at the top of
>> your file or the flag -XScopedTypeVariables on the command line and changing
>> the signature of combs to
>> combs :: forall a. (Eq a) => [a] -> Int -> [[a]],
>> I think then you must leave off the (Eq a) from the signature of combs'.
>>
>>>  I realize I can remove the type specification
>>> from /combs'/, and the code will compile.  However, I'd like to get a
>>> better understanding of why GHC objects to this.
>>>
>>> Thank you,
>>> Rob.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
From lennart at augustsson.net  Thu Sep 18 20:29:45 2008
From: lennart at augustsson.net (Lennart Augustsson)
Date: Thu Sep 18 20:27:06 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
Message-ID: 

Without any fancy byte strings:

main = do
   name:_ <- getArgs
   file <- readFile name
   print $ length $ lines file


On Thu, Sep 18, 2008 at 6:02 PM, Creighton Hogg  wrote:
> Hey Haskell,
> So for a fairly inane reason, I ended up taking a couple of minutes
> and writing a program that would spit out, to the console, the number
> of lines in a file.  Off the top of my head, I came up with this which
> worked fine with files that had 100k lines:
>
> main = do
>  path <- liftM head $ getArgs
>  h <- openFile path ReadMode
>  n <- execStateT (countLines h) 0
>  print n
>
> untilM :: Monad m => (a -> m Bool) -> (a -> m ()) -> a -> m ()
> untilM cond action val = do
>  truthy <- cond val
>  if truthy then return () else action val >> (untilM cond action val)
>
> countLines :: Handle -> StateT Int IO ()
> countLines = untilM (\h -> lift $ hIsEOF h) (\h -> do
>                                                lift $ hGetLine h
>                                                modify (+1))
>
> If this makes anyone cringe or cry "you're doing it wrong", I'd
> actually like to hear it.  I never really share my projects, so I
> don't know how idiosyncratic my style is.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From robgreayer at yahoo.com  Thu Sep 18 21:14:41 2008
From: robgreayer at yahoo.com (Robert Greayer)
Date: Thu Sep 18 21:12:03 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
Message-ID: <458857.56773.qm@web65712.mail.ac4.yahoo.com>

--- On Thu, 9/18/08, Creighton Hogg  wrote:
> If this makes anyone cringe or cry
> "you're doing it wrong", I'd
> actually like to hear it.

Just to make everyone cry:

main = getArgs >>= \(x:_) -> system ("wc -l " ++ x)





      
From steve at fenestra.com  Thu Sep 18 21:53:56 2008
From: steve at fenestra.com (Steve Schafer)
Date: Thu Sep 18 21:51:05 2008
Subject: [Haskell-cafe] An interesting curiosity
In-Reply-To: <48D2A527.2040708@btinternet.com>
References: <48D2A527.2040708@btinternet.com>
Message-ID: <2b16d45bohqrofiibs71gi7afqbjhp5a6e@4ax.com>

On Thu, 18 Sep 2008 19:59:51 +0100, you wrote:

>Of course, C++ is that crazy language where *assignment* is actually an 
>*operator*. Sick, sick people...

That's really not all that strange. An (infix) operator is just a
function with funny syntax, and assignment is a function (the identity
function, in fact) that also has a side effect.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
From oleg at okmij.org  Thu Sep 18 22:57:02 2008
From: oleg at okmij.org (oleg@okmij.org)
Date: Thu Sep 18 22:55:58 2008
Subject: [Haskell-cafe] Re: Strongly Typed Memory Areas
Message-ID: <20080919025702.2DDA0AF09@Adric.metnet.fnmoc.navy.mil>


John Van Enk wrote:
> Was Iavor/Mark's paper ever implemented as a GHC extension?
> "Strongly Typed Memory Areas"

It turns out most of the functionality is already available in
Haskell:

	Lightweight static resources, for safe embedded and systems
	programming
	http://okmij.org/ftp/Haskell/types.html#ls-resources

Chung-chieh Shan's TFP2007 talk specifically contrasted code from
Iavor/Mark's paper with Haskell code. Strongly typed memory areas are
possible in Haskell today.

 
From steshaw at gmail.com  Thu Sep 18 23:01:48 2008
From: steshaw at gmail.com (Steven Shaw)
Date: Thu Sep 18 22:59:09 2008
Subject: [Haskell-cafe] An interesting curiosity
In-Reply-To: <2518b95d0809181218i4f20c85alc9c9a5e2cb9eb70e@mail.gmail.com>
References: <48D2A527.2040708@btinternet.com>
	<2518b95d0809181218i4f20c85alc9c9a5e2cb9eb70e@mail.gmail.com>
Message-ID: <1ba9d4a00809182001i5b6e59a5v7661c1f8e5a5cc87@mail.gmail.com>

2008/9/19 Evan Laforge 
> let {1 + 1 = 3; 3 + 1 = 3} in 1 + 1 + 1

Which gives 3.

Perhaps even more confusing is:

let {1 + 1 = 3; 3 + 1 = 3} in 3 + 1 + 1

which gives 3
From donnie at darthik.com  Thu Sep 18 23:16:38 2008
From: donnie at darthik.com (Donnie Jones)
Date: Thu Sep 18 23:13:59 2008
Subject: [Haskell-cafe] An interesting curiosity
In-Reply-To: <1ba9d4a00809182001i5b6e59a5v7661c1f8e5a5cc87@mail.gmail.com>
References: <48D2A527.2040708@btinternet.com>
	<2518b95d0809181218i4f20c85alc9c9a5e2cb9eb70e@mail.gmail.com>
	<1ba9d4a00809182001i5b6e59a5v7661c1f8e5a5cc87@mail.gmail.com>
Message-ID: 

Hello,

More fun for all of us to enjoy:
http://www.haskell.org/haskellwiki/Obfuscation
__
Donnie

On Thu, Sep 18, 2008 at 11:01 PM, Steven Shaw  wrote:

> 2008/9/19 Evan Laforge 
> > let {1 + 1 = 3; 3 + 1 = 3} in 1 + 1 + 1
>
> Which gives 3.
>
> Perhaps even more confusing is:
>
> let {1 + 1 = 3; 3 + 1 = 3} in 3 + 1 + 1
>
> which gives 3
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080918/159aa2dc/attachment.htm
From skynare at gmail.com  Thu Sep 18 23:20:27 2008
From: skynare at gmail.com (sam lee)
Date: Thu Sep 18 23:17:47 2008
Subject: [Haskell-cafe] An interesting curiosity
In-Reply-To: <1ba9d4a00809182001i5b6e59a5v7661c1f8e5a5cc87@mail.gmail.com>
References: <48D2A527.2040708@btinternet.com>
	<2518b95d0809181218i4f20c85alc9c9a5e2cb9eb70e@mail.gmail.com>
	<1ba9d4a00809182001i5b6e59a5v7661c1f8e5a5cc87@mail.gmail.com>
Message-ID: <4e7aa0f80809182020q7e3aacd5yfb93e3568dd1fa10@mail.gmail.com>

I think it's because + is left associative. and pattern matching is
top to bottom.
1 + 1 + 1 => (1 + 1) + 1 => found match: 1 + 1 = 3 => 3 + 1 => found
match: 3 + 1 = 3 => 3

On Thu, Sep 18, 2008 at 11:01 PM, Steven Shaw  wrote:
> 2008/9/19 Evan Laforge 
>> let {1 + 1 = 3; 3 + 1 = 3} in 1 + 1 + 1
>
> Which gives 3.
>
> Perhaps even more confusing is:
>
> let {1 + 1 = 3; 3 + 1 = 3} in 3 + 1 + 1
>
> which gives 3
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From daniel.is.fischer at web.de  Fri Sep 19 00:38:28 2008
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Fri Sep 19 00:34:10 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <458857.56773.qm@web65712.mail.ac4.yahoo.com>
References: <458857.56773.qm@web65712.mail.ac4.yahoo.com>
Message-ID: <200809190638.28972.daniel.is.fischer@web.de>

Am Freitag, 19. September 2008 03:14 schrieb Robert Greayer:
> --- On Thu, 9/18/08, Creighton Hogg  wrote:
> > If this makes anyone cringe or cry
> > "you're doing it wrong", I'd
> > actually like to hear it.
>
> Just to make everyone cry:
>
> main = getArgs >>= \(x:_) -> system ("wc -l " ++ x)
>

Ouch!
From derek.a.elkins at gmail.com  Fri Sep 19 00:45:26 2008
From: derek.a.elkins at gmail.com (Derek Elkins)
Date: Fri Sep 19 00:43:08 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <200809190638.28972.daniel.is.fischer@web.de>
References: <458857.56773.qm@web65712.mail.ac4.yahoo.com>
	<200809190638.28972.daniel.is.fischer@web.de>
Message-ID: <1221799526.5979.4.camel@derek-laptop>

On Fri, 2008-09-19 at 06:38 +0200, Daniel Fischer wrote:
> Am Freitag, 19. September 2008 03:14 schrieb Robert Greayer:
> > --- On Thu, 9/18/08, Creighton Hogg  wrote:
> > > If this makes anyone cringe or cry
> > > "you're doing it wrong", I'd
> > > actually like to hear it.
> >
> > Just to make everyone cry:
> >
> > main = getArgs >>= \(x:_) -> system ("wc -l " ++ x)
> >
> 
> Ouch!

Indeed.

main = getArgs >>= system . ("wc -l "++) . head

From oleg at okmij.org  Fri Sep 19 02:51:59 2008
From: oleg at okmij.org (oleg@okmij.org)
Date: Fri Sep 19 02:50:56 2008
Subject: [Haskell-cafe] Lazy vs correct IO [Was: A round of golf]
Message-ID: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>


Lennart Augustsson wrote

> main = do
>    name:_ <- getArgs
>    file <- readFile name
>    print $ length $ lines file

Given the stance against top-level mutable variables, I have not
expected to see this Lazy IO code. After all, what could be more against
the spirit of Haskell than a `pure' function with observable side
effects. With Lazy IO, one indeed has to choose between correctness
and performance. The appearance of such code is especially strange
after the evidence of deadlocks with Lazy IO, presented on this list
less than a month ago. Let alone unpredictable resource usage and
reliance on finalizers to close files (forgetting that GHC does not
guarantee that finalizers will be run at all).

Is there an alternative?

-- Counting the lines in a file
import IterateeM

count_nl = liftI $ IE_cont (step 0)
 where
 step acc (Chunk str)  = liftI $ IE_cont (step $! acc + count str)
 step acc stream       = liftI $ IE_done acc stream
 count [] = 0
 count ('\n':str) = succ $! count str
 count (_:str) = count str

main = do
   name:_ <- getArgs
   IE_done counter _ <- unIM $ enum_file name >. enum_eof ==<< count_nl
   print counter


The function count_nl could have been in the library, but I'm a
minimalist. It is written in a declarative rather than imperative
style, and one easily sees what it does. The above code as well as the
IterateeM library is Haskell98. It does not use any unsafe Haskell
functions whatsoever.

time wc -l /usr/share/dict/words 
  235882 /usr/share/dict/words

real    0m0.024s
user    0m0.022s
sys     0m0.000s

time ~/Docs/papers/DEFUN08/Wc /usr/share/dict/words 
235882

real    0m0.141s
user    0m0.126s
sys     0m0.008s

To compare with lazy IO, the code using readFile gives

time ~/Docs/papers/DEFUN08/Wc /usr/share/dict/words 
235882

real    0m0.297s
user    0m0.262s
sys     0m0.023s

So, choosing correctness does not mean losing in performance; in fact,
one may even gain.

Can enumerators compose? Well, we already seen the example above
	(enum_file name >. enum_eof)
where the operation (>.) 
	e1 >. e2 = (==<<) e2 . e1
is a flipped composition if monadic bind were considered a flipped
application.


Here is a more interesting example: count words in all the files whose
names are given on the command line. There may be many files given,
thousands of them.

-- Count the stream. Again, could have been in the library
stream_count :: Monad m => IterateeGM el m Int
stream_count = liftI $ IE_cont (step 0)
 where
 step acc (Chunk [])  = liftI $ IE_cont (step acc)
 step acc (Chunk [_]) = liftI $ IE_cont (step $! succ acc)
 step acc (Chunk ls)  = liftI $ IE_cont (step $! acc + length ls)
 step acc stream      = liftI $ IE_done acc stream


main = do
   names <- getArgs
   let enumerators = foldr (\name -> (enum_file name >.)) enum_eof names
   IE_done (IE_done counter _) _ <- unIM $ enumerators ==<<
		                             enum_words stream_count
   print counter

We notice that the composition of enumerators corresponds to the
`concatenation' of their sources. Declaratively, the meaning of the
above code is:
	-- all the given files are concatenated
	-- the resulting stream of characters is converted to a stream
of words
	-- the stream of words is counted.

Operationally, the code does not open more than one file at a
time. More importantly, the code *never* reads more than 4096
characters at a time. A block of the file is read, split into words,
counted, and only then another chunk is read. After one file is done,
it is closed, and another file is processed. One can see that only one
file is being opened at a time by enabling traces. The processing is
fully incremental.


/usr/local/share/doc/ghc6> find . -name \*.html -print | time xargs ~/Docs/papers/DEFUN08/Wc
3043421
       16.99 real        15.83 user         0.71 sys

BTW, the program has counted words in 1169 files.

It is interesting to compare the above main function with the
corresponding lazy IO:

main'' = do
   names <- getArgs
   files <- mapM readFile names
   print $ length $ words (concat files)

The number of lines is comparable. The execution is not. If we try to
run the lazy IO code, we get:

/usr/local/share/doc/ghc6> find . -name \*.html -print | time xargs ~/Docs/papers/DEFUN08/Wc
Wc: ./libraries/Win32/Graphics-Win32-GDI-Path.html: 
   openFile: resource exhausted (Too many open files)

From dons at galois.com  Fri Sep 19 03:13:40 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 19 03:10:56 2008
Subject: [Haskell-cafe] Lazy vs correct IO [Was: A round of golf]
In-Reply-To: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
References: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
Message-ID: <20080919071340.GE9942@scytale.galois.com>

oleg:
> Given the stance against top-level mutable variables, I have not
> expected to see this Lazy IO code. After all, what could be more against
> the spirit of Haskell than a `pure' function with observable side
> effects. With Lazy IO, one indeed has to choose between correctness
> and performance. The appearance of such code is especially strange
> after the evidence of deadlocks with Lazy IO, presented on this list
> less than a month ago. Let alone unpredictable resource usage and
> reliance on finalizers to close files (forgetting that GHC does not
> guarantee that finalizers will be run at all).
> 
> Is there an alternative?

Hi Oleg!

I'm glad you joined the thread at this point.

Some background: our best solutions for this problem using lazy IO, are
based on chunk-wise lazy data structures, typically lazy bytestrings.
Often we'll write programs like:

    import qualified Data.ByteString.Lazy.Char8 as B
    import System.Environment

    main = do
        [f] <- getArgs
        s   <- B.readFile f
        print (B.count '\n' s)

Which are nicely efficient

    $ ghc -O2 A.hs --make
    $ du -hs data
    100M data

    $ time ./A data 
    11078540
    ./A data  0.17s user 0.04s system 100% cpu 0.210 total

And we know from elsewhere the performance is highlycompetitive:

    http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all

Now, enumerators are very promising, and there's a lot of interest at
the moment, (e.g. just this week, Johan Tibell gave an inspiring talk at
Galois about this approach to IO, http://www.galois.com/blog/2008/09/12/left-fold-enumerators-a-safe-expressive-and-efficient-io-interface-for-haskell/
and we spent the day sketching out an enumerator bytestring design, 

But there are some open questions. Perhaps you have some answers?

    * Can we write a Data.ByteString.Enumerator that has matching or
      better performance than its "dual", the existing chunk-wise lazy
      stream type?

    * Is there a translation from 

        data ByteString = Empty | Chunk {-# UNPACK #-} !S.ByteString ByteString

      and functions on this type,

        foldlChunks :: (a -> S.ByteString -> a) -> a -> ByteString -> a
        foldlChunks f z = go z
          where
                go !a Empty        = a
                go !a (Chunk c cs) = go (f a c) cs

      to an enumerator implementation?

    * Can we compose enumerators as we can stream functions?

    * Can we do fusion on enumerators? Does that make composition easier?
        (Indeed, is there an encoding of enumerators analogous to stream
        fusion control?)

Any thoughts?

-- Don
From apfelmus at quantentunnel.de  Fri Sep 19 03:51:30 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Fri Sep 19 03:49:00 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
Message-ID: 

Andre Nathan wrote:
> I'm trying to write a simple graph library for a project of mine

There's also Martin Erwig's functional graph library in  Data.Graph.Inductive  (
fgl  on hackage).


Regards,
apfelmus

From Christian.Maeder at dfki.de  Fri Sep 19 04:35:03 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Sep 19 04:32:21 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <1221776716.5395.518.camel@localhost>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<1221776716.5395.518.camel@localhost>
Message-ID: <48D36437.9010209@dfki.de>

Duncan Coutts wrote:
> On Thu, 2008-09-18 at 15:43 -0300, Andre Nathan wrote:
> 
>> My Graph type is the following.
>>
>>   data Graph a b = Graph
>>     { adjacencies :: Map Int (a, (Map Int b))
>>     , numVertices :: Int
>>     , numEdges    :: Int
>>     }
> 
>>   addVertex :: Int -> a -> State (Graph a b) ()
>>   addVertex vertex label = do
>>     g <- get
>>     let adj = Map.insert vertex (label, Map.empty) (adjacencies g)
>>     put $ g { adjacencies = adj, numVertices = numVertices g + 1 }
> 
>> So I'm confused right now about how I should proceed. Any hints
>> regarding that?
> 
> To be honest I would not bother with the state monad and just make them
> pure operations returning new graphs:
> 
> ?addVertex :: Int -> a -> Graph a b -> ?Graph a b
> 
> ?It's very common to have this style, ie returning a new/updated
> structure explicitly rather than implicitly in a state monad. Just look
> at the Data.Map api for example. If you later want to stick it in a
> state monad then that would be straightforward but also easy to use
> directly.

I agree. Duncan's version also looks more atomic to me, because Andre's
version (that's renamed to addVertexM below) could be easily derived by:

  addVertexM v l = modify (addVertex v l)

The opposite derivation is also possible but does additional wrapping
into and out of a state:

  addVertex v l = execState (addVertexM v l)

(Furthermore the module Control.Monad.State is "non-portable", because
get, put, modify and gets come in via the MonadState class, but separate
not overloaded versions for these function would make sense in the same
way we have "map" despite "fmap".)

Cheers Christian

From ketil at malde.org  Fri Sep 19 06:37:12 2008
From: ketil at malde.org (Ketil Malde)
Date: Fri Sep 19 06:31:52 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <814617240809181231s503b221chf23919983d80355c@mail.gmail.com>
	(Creighton Hogg's message of "Thu\, 18 Sep 2008 14\:31\:00 -0500")
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
	<814617240809181231s503b221chf23919983d80355c@mail.gmail.com>
Message-ID: <874p4cfmlj.fsf@malde.org>

"Creighton Hogg"  writes:

> To ask an overly general question, if lazy bytestring makes a nice
> provider for incremental processing are there reasons to _not_ reach
> for that as my default when processing large files?

I think it is a nice default.  

I'd reach for strict bytestrings if I know the file will be processed
in a strict manner (not single-pass stream-through), and I just have
to have the last few percent speedup.  I'll use [String] only for
small examples, where the extra imports cost more than the performance
loss. 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From ketil at malde.org  Fri Sep 19 06:40:03 2008
From: ketil at malde.org (Ketil Malde)
Date: Fri Sep 19 06:34:42 2008
Subject: [Haskell-cafe] A round of golf
In-Reply-To: <20080918221147.GF9005@scytale.galois.com> (Don Stewart's message
	of "Thu\, 18 Sep 2008 15\:11\:47 -0700")
References: <814617240809181002v786af26dq60e0bbf7959e0206@mail.gmail.com>
	<20080918182911.GB8398@scytale.galois.com>
	<814617240809181149x44f882c8u2468e6949a27bb90@mail.gmail.com>
	<20080918185510.GE8398@scytale.galois.com>
	<814617240809181509wb745e40sf7df955252cd5cb8@mail.gmail.com>
	<20080918221147.GF9005@scytale.galois.com>
Message-ID: <87zlm4e7wc.fsf@malde.org>

Don Stewart  writes:

>> If I want to make my own efficient bytestring consumer, is that
>> what I need to use in order to preserve the inherent laziness of
>> the datastructure? 

> you can get foldChunks from Data.ByteString.Lazy.Internal,
> or write your own chunk folder.

IME you can also get nicely by using the standard list-alikes:
uncons, head, tail, take, drop... 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From huschi at gmx.org  Fri Sep 19 07:14:19 2008
From: huschi at gmx.org (Martin Huschenbett)
Date: Fri Sep 19 07:11:40 2008
Subject: [Haskell-cafe] Updated formlets sample?
Message-ID: <48D3898B.5070904@gmx.org>

Hi all,

I found a blog post concerning formlets [1] in the web. Since looks very 
interesting I tried to compile the sample code with recent versions of 
HAppS and formlets from hackage. But this didn't work as the API of 
formlets has changed since this post.

I tried to adopt the code to the new API but I was unable to finish this 
since there is a new monadic context I don't know to handle in the right 
way.

So my question is, is there an updated version of this sample code in 
the web or has anybody tried to adopt it and can send me the results?

Thanks in advance,

Martin.

[1] http://blog.tupil.com/formlets-in-haskell/
From ketil at malde.org  Fri Sep 19 07:43:37 2008
From: ketil at malde.org (Ketil Malde)
Date: Fri Sep 19 07:38:15 2008
Subject: [Haskell-cafe] Lazy vs correct IO
In-Reply-To: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
	(oleg@okmij.org's message of "Thu\,
	18 Sep 2008 23\:51\:59 -0700 \(PDT\)")
References: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
Message-ID: <87ljxoe4ye.fsf@malde.org>

oleg@okmij.org writes:

> It is interesting to compare the above main function with the
> corresponding lazy IO:

Minor point I know, but aren't you really comparing it with the
corresponding *strict* IO?

> main'' = do
>    names <- getArgs
>    files <- mapM readFile names
              ^^^^

>    print $ length $ words (concat files)

This works nicely if you replace the middle line with a lazy version, e.g.:

   files <- mapM (unsafeInterleaveIO . B.readFile) names

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From marcot at riseup.net  Fri Sep 19 08:00:00 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Fri Sep 19 07:57:26 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <1221765256.4567.51.camel@quindinho.domain.invalid>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
	<396556a20809181130v67cbb760wa745046e3fe7960f@mail.gmail.com>
	<1221763129.4567.42.camel@quindinho.domain.invalid>
	<396556a20809181151j3973ebb8p3afc3669ffacfa69@mail.gmail.com>
	<1221765256.4567.51.camel@quindinho.domain.invalid>
Message-ID: <1221825600.4567.63.camel@quindinho.domain.invalid>

Em Qui, 2008-09-18 ?s 16:14 -0300, Marco T?lio Gontijo e Silva escreveu:
> Em Qui, 2008-09-18 ?s 11:51 -0700, Adam Langley escreveu:
> > Do you want control-timeout?
> 
> I think control-timeout is very useful.  I'll try to fix it, and if I
> could, I'll upload it to hackage then.

I couldn't, and I found a solution to what I want in
System.Glib.MainLoop.  So, if someone else is interested in maintaining
this package, feel free to do it.

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From marcot at riseup.net  Fri Sep 19 08:09:53 2008
From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva)
Date: Fri Sep 19 08:07:17 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
Message-ID: <1221826193.4567.67.camel@quindinho.domain.invalid>

Hello,

Em Qui, 2008-09-18 ?s 10:05 -0700, Judah Jacobson escreveu:
> Just a guess, but this might be a problem with control-timeout's use
> of the unsafePerformIO global variables hack.  It's missing the
> standard NOINLINE annotations which prevent multiple copies of the
> global variable from being created.

I added the NOINLINE annotations and even tried building with -fno-cse,
but the result was the same.  Do you have any other suggestions?

Greetings.

-- 
marcot
P?gina: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: marcot@riseup.net
XMPP: marcot@jabber.org
IRC: marcot@irc.freenode.net
Telefone: 25151920
Celular: 98116720
Endere?o:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil


From a.biurvOir4 at asuhan.com  Fri Sep 19 10:31:40 2008
From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh)
Date: Fri Sep 19 10:29:01 2008
Subject: [Haskell-cafe] Lazy vs correct IO [Was: A round of golf]
In-Reply-To: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
References: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
Message-ID: <19573538.post@talk.nabble.com>



oleg-30 wrote:
> 
> I have not expected to see this Lazy IO code. After all, what could be
> more against
> the spirit of Haskell than a `pure' function with observable side effects.
> 

What could even be more against the spirit of Haskell than 
the original theme of this thread, i.e. code that makes us cry?

Lennart's piece fudges purity, agreed, but it reads nicely as
idiomatic Haskell, swift on the eyes if not on the machine.

Consider if readFile's semantics were modified, i.e. not lazy,
at least not always.

In the ideal world, a smart enough compiler would just do 
the right thing, i.e. the IO String returned would be strict, or better 
yet, it would automatically chunkify the read to obtain constant 
space usage.

"Lazy IO" is indeed a nasty can of worms, not unrelated to the issue
of monadic IO as a gigantic sin bin. We could avoid it entirely, or we 
could sort out and algebraize the different interactions into a happier 
marriage of the pair.

-- 
View this message in context: http://www.nabble.com/Lazy-vs-correct-IO--Was%3A-A-round-of-golf--tp19567128p19573538.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

From lennart at augustsson.net  Fri Sep 19 11:30:34 2008
From: lennart at augustsson.net (Lennart Augustsson)
Date: Fri Sep 19 11:27:53 2008
Subject: [Haskell-cafe] Lazy vs correct IO [Was: A round of golf]
In-Reply-To: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
References: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
Message-ID: 

I agree that lazy IO is a can with some worms in it.  But it's not that strange.
The readFile operation is in the IO monad, so it has an effect on the world.
This effect is not finished when readFile returns, and from the world
point of view
it's not entirely deterministic.

On Fri, Sep 19, 2008 at 7:51 AM,   wrote:
>
> Lennart Augustsson wrote
>
>> main = do
>>    name:_ <- getArgs
>>    file <- readFile name
>>    print $ length $ lines file
>
> Given the stance against top-level mutable variables, I have not
> expected to see this Lazy IO code. After all, what could be more against
> the spirit of Haskell than a `pure' function with observable side
> effects. With Lazy IO, one indeed has to choose between correctness
> and performance. The appearance of such code is especially strange
> after the evidence of deadlocks with Lazy IO, presented on this list
> less than a month ago. Let alone unpredictable resource usage and
> reliance on finalizers to close files (forgetting that GHC does not
> guarantee that finalizers will be run at all).
>
> Is there an alternative?
>
> -- Counting the lines in a file
> import IterateeM
>
> count_nl = liftI $ IE_cont (step 0)
>  where
>  step acc (Chunk str)  = liftI $ IE_cont (step $! acc + count str)
>  step acc stream       = liftI $ IE_done acc stream
>  count [] = 0
>  count ('\n':str) = succ $! count str
>  count (_:str) = count str
>
> main = do
>   name:_ <- getArgs
>   IE_done counter _ <- unIM $ enum_file name >. enum_eof ==<< count_nl
>   print counter
>
>
> The function count_nl could have been in the library, but I'm a
> minimalist. It is written in a declarative rather than imperative
> style, and one easily sees what it does. The above code as well as the
> IterateeM library is Haskell98. It does not use any unsafe Haskell
> functions whatsoever.
>
> time wc -l /usr/share/dict/words
>  235882 /usr/share/dict/words
>
> real    0m0.024s
> user    0m0.022s
> sys     0m0.000s
>
> time ~/Docs/papers/DEFUN08/Wc /usr/share/dict/words
> 235882
>
> real    0m0.141s
> user    0m0.126s
> sys     0m0.008s
>
> To compare with lazy IO, the code using readFile gives
>
> time ~/Docs/papers/DEFUN08/Wc /usr/share/dict/words
> 235882
>
> real    0m0.297s
> user    0m0.262s
> sys     0m0.023s
>
> So, choosing correctness does not mean losing in performance; in fact,
> one may even gain.
>
> Can enumerators compose? Well, we already seen the example above
>        (enum_file name >. enum_eof)
> where the operation (>.)
>        e1 >. e2 = (==<<) e2 . e1
> is a flipped composition if monadic bind were considered a flipped
> application.
>
>
> Here is a more interesting example: count words in all the files whose
> names are given on the command line. There may be many files given,
> thousands of them.
>
> -- Count the stream. Again, could have been in the library
> stream_count :: Monad m => IterateeGM el m Int
> stream_count = liftI $ IE_cont (step 0)
>  where
>  step acc (Chunk [])  = liftI $ IE_cont (step acc)
>  step acc (Chunk [_]) = liftI $ IE_cont (step $! succ acc)
>  step acc (Chunk ls)  = liftI $ IE_cont (step $! acc + length ls)
>  step acc stream      = liftI $ IE_done acc stream
>
>
> main = do
>   names <- getArgs
>   let enumerators = foldr (\name -> (enum_file name >.)) enum_eof names
>   IE_done (IE_done counter _) _ <- unIM $ enumerators ==<<
>                                             enum_words stream_count
>   print counter
>
> We notice that the composition of enumerators corresponds to the
> `concatenation' of their sources. Declaratively, the meaning of the
> above code is:
>        -- all the given files are concatenated
>        -- the resulting stream of characters is converted to a stream
> of words
>        -- the stream of words is counted.
>
> Operationally, the code does not open more than one file at a
> time. More importantly, the code *never* reads more than 4096
> characters at a time. A block of the file is read, split into words,
> counted, and only then another chunk is read. After one file is done,
> it is closed, and another file is processed. One can see that only one
> file is being opened at a time by enabling traces. The processing is
> fully incremental.
>
>
> /usr/local/share/doc/ghc6> find . -name \*.html -print | time xargs ~/Docs/papers/DEFUN08/Wc
> 3043421
>       16.99 real        15.83 user         0.71 sys
>
> BTW, the program has counted words in 1169 files.
>
> It is interesting to compare the above main function with the
> corresponding lazy IO:
>
> main'' = do
>   names <- getArgs
>   files <- mapM readFile names
>   print $ length $ words (concat files)
>
> The number of lines is comparable. The execution is not. If we try to
> run the lazy IO code, we get:
>
> /usr/local/share/doc/ghc6> find . -name \*.html -print | time xargs ~/Docs/papers/DEFUN08/Wc
> Wc: ./libraries/Win32/Graphics-Win32-GDI-Path.html:
>   openFile: resource exhausted (Too many open files)
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From manlio_perillo at libero.it  Fri Sep 19 12:02:27 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 11:59:47 2008
Subject: [Haskell-cafe] lazy strings and parallel read
Message-ID: <48D3CD13.1030205@libero.it>

Hi.

After having read
http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390

I have a doubt about Data.ByteString.Lazy.

Why getContents function don't use pread (or an emulation, if not 
available)?


Thanks  Manlio Perillo
From leather at cs.uu.nl  Fri Sep 19 12:05:06 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Fri Sep 19 12:02:26 2008
Subject: [Haskell-cafe] ANNOUNCE: Extensible and Modular Generics for the
	Masses (EMGM) 0.1
Message-ID: <3c6288ab0809190905h171fe0a6i3aac97454ba700e@mail.gmail.com>

Extensible and Modular Generics for the Masses
==============================================

Extensible and Modular Generics for the Masses (EMGM) is a library for
generic programming in Haskell using type classes.

This is the initial release of a maintained library for EMGM. Other versions
have previously existed in various states from various sources. We plan to
continue updating and maintaining this version.

Visit the home page:

  http://www.cs.uu.nl/wiki/GenericProgramming/EMGM

Features
--------

The primary features of EMGM include:

*  Datatype-generic programming using sum-of-product views
*  Large collection of ready-to-use generic functions
*  Included support for standard datatypes: lists, Maybe, tuples
*  Easy to add support for new datatypes
*  Type classes make writing new functions straightforward in a structurally
inductive style
*  Generic functions are extensible with ad-hoc cases for arbitrary
datatypes
*  Good performance of generic functions

The features of this distribution include:

*  The API is thoroughly documented with Haddock
*  Fully tested with QuickCheck and HUnit
*  Program coverage ensures that all useful code has been touched by tests
*  Tested on both Mac and Windows systems

Requirements
------------

EMGM has the following requirements:

*  GHC 6.8.1 - It has been tested with versions 6.8.3 and 6.9.20080916.
*  Cabal library 1.2.1 - It has been tested with versions 1.2.3 and 1.4.0.1.

Download & Source
-----------------

Use caball-install:

  cabal install emgm

Get the package:

  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm

Get the source:

  svn checkout https://svn.cs.uu.nl:12443/repos/dgp-haskell/EMGM

Examples
--------

Check out the examples:

  https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/examples/

Bugs & Support
--------------

Report issues or request features:

  http://code.google.com/p/emgm/

Discuss EMGM with the authors, maintainers, and other interested persons:

  http://www.haskell.org/mailman/listinfo/generics

Credits
-------

The research for EMGM originated with Ralf Hinze. It was extended with work
by Bruno Oliveira and Andres L?h. More details of the library functionality
were explored by Alexey Rodriguez. We are very grateful to all of these
people for the foundation on which this library was built.

The current authors and maintainers of EMGM are:

*  Sean Leather
*  Jos? Pedro Magalh?es
*  Alexey Rodriguez
*  Andres L?h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080919/98272ec1/attachment.htm
From dons at galois.com  Fri Sep 19 12:14:35 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 19 12:11:49 2008
Subject: [Haskell-cafe] lazy strings and parallel read
In-Reply-To: <48D3CD13.1030205@libero.it>
References: <48D3CD13.1030205@libero.it>
Message-ID: <20080919161435.GA11506@scytale.galois.com>

manlio_perillo:
> Hi.
> 
> After having read
> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390
> 
> I have a doubt about Data.ByteString.Lazy.
> 
> Why getContents function don't use pread (or an emulation, if not 
> available)?

Why would it?

-- Don
From manlio_perillo at libero.it  Fri Sep 19 12:41:52 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 12:39:17 2008
Subject: [Haskell-cafe] performance of map reduce
Message-ID: <48D3D650.1050805@libero.it>

Hi again.

In 
http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390
there is a map reduce based log parser.

I have written an alternative version:
http://paste.pocoo.org/show/85699/

but, with a file of 315 MB, I have [1]:

1) map reduce implementation, non parallel
real	0m6.643s
user	0m6.252s
sys	0m0.212s

2) map reduce implementation, parallel with 2 cores
real	0m3.840s
user	0m6.384s
sys	0m0.652s

3) my implementation
real	0m8.121s
user	0m7.804s
sys	0m0.216s



What is the reason of the map reduce implementation being faster, even 
if not parallelized?

It is possible to implement a map reduce version that can handle gzipped 
log files?


[1] These tests does not consider the "first run".
For the first run (no data in OS cache), I have (not verified):

1) map reduce implementation, parallel with 2 cores
real	0m3.735s
user	0m6.328s
sys	0m0.604s

2) my implementation
real	0m13.659s
user	0m7.712s
sys	0m0.360s




Thanks   Manlio Perillo
From manlio_perillo at libero.it  Fri Sep 19 12:46:13 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 12:43:36 2008
Subject: [Haskell-cafe] lazy strings and parallel read
In-Reply-To: <20080919161435.GA11506@scytale.galois.com>
References: <48D3CD13.1030205@libero.it>
	<20080919161435.GA11506@scytale.galois.com>
Message-ID: <48D3D755.3040602@libero.it>

Don Stewart ha scritto:
> manlio_perillo:
>> Hi.
>>
>> After having read
>> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390
>>
>> I have a doubt about Data.ByteString.Lazy.
>>
>> Why getContents function don't use pread (or an emulation, if not 
>> available)?
> 
> Why would it?
> 

So that you don't need to open the same file multiple time:
http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id677193



> -- Don
> 



Thanks   Manlio Perillo
From manlio_perillo at libero.it  Fri Sep 19 12:56:04 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 12:53:28 2008
Subject: [Haskell-cafe] lazy strings and parallel read
In-Reply-To: <48D3CD13.1030205@libero.it>
References: <48D3CD13.1030205@libero.it>
Message-ID: <48D3D9A4.8050806@libero.it>

Manlio Perillo ha scritto:
> Hi.
> 
> After having read
> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390 
> 
> 
> I have a doubt about Data.ByteString.Lazy.
> 
> Why getContents function don't use pread (or an emulation, if not 
> available)?
> 

A correction.
getContents should not use pread, so the question is:
why there is not a
   hParGetContents Handle -> Integer -> IO ByteString
function, where Integer is the absolute file offset where start to read?


Thanks  Manlio Perillo
From duncan.coutts at worc.ox.ac.uk  Fri Sep 19 13:01:37 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Sep 19 12:58:37 2008
Subject: [Haskell-cafe] lazy strings and parallel read
In-Reply-To: <48D3D755.3040602@libero.it>
References: <48D3CD13.1030205@libero.it>
	<20080919161435.GA11506@scytale.galois.com>
	<48D3D755.3040602@libero.it>
Message-ID: <1221843697.5395.570.camel@localhost>

On Fri, 2008-09-19 at 18:46 +0200, Manlio Perillo wrote:
> Don Stewart ha scritto:
> > manlio_perillo:
> >> Hi.
> >>
> >> After having read
> >> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390
> >>
> >> I have a doubt about Data.ByteString.Lazy.
> >>
> >> Why getContents function don't use pread (or an emulation, if not 
> >> available)?
> > 
> > Why would it?
> > 
> 
> So that you don't need to open the same file multiple time:
> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id677193

We are constrained here by the semantics of Handle which requires
that ?getContents semi-close the Handle (which in turn is to make it
harder to shoot yourself in the foot while doing lazy IO).

Duncan

From dons at galois.com  Fri Sep 19 13:12:43 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 19 13:09:56 2008
Subject: [Haskell-cafe] performance of map reduce
In-Reply-To: <48D3D650.1050805@libero.it>
References: <48D3D650.1050805@libero.it>
Message-ID: <20080919171243.GB11802@scytale.galois.com>

manlio_perillo:
> Hi again.
> 
> In 
> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390
> there is a map reduce based log parser.
> 
> I have written an alternative version:
> http://paste.pocoo.org/show/85699/
> 
> but, with a file of 315 MB, I have [1]:
> 
> 1) map reduce implementation, non parallel
> real	0m6.643s
> user	0m6.252s
> sys	0m0.212s
> 
> 2) map reduce implementation, parallel with 2 cores
> real	0m3.840s
> user	0m6.384s
> sys	0m0.652s
> 
> 3) my implementation
> real	0m8.121s
> user	0m7.804s
> sys	0m0.216s
> 
> 
> 
> What is the reason of the map reduce implementation being faster, even 
> if not parallelized?

Changes in how GC is utilised, or how optimisation works?
  
> It is possible to implement a map reduce version that can handle gzipped 
> log files?

Using the zlib binding on hackage.haskell.org, you can stream multiple
zlib decompression threads with lazy bytestrings, and combine the
results.

-- Don
From manlio_perillo at libero.it  Fri Sep 19 13:50:11 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 13:47:36 2008
Subject: [Haskell-cafe] lazy strings and parallel read
In-Reply-To: <1221843697.5395.570.camel@localhost>
References: <48D3CD13.1030205@libero.it>	
	<20080919161435.GA11506@scytale.galois.com>
	<48D3D755.3040602@libero.it> <1221843697.5395.570.camel@localhost>
Message-ID: <48D3E653.3090403@libero.it>

Duncan Coutts ha scritto:
> On Fri, 2008-09-19 at 18:46 +0200, Manlio Perillo wrote:
>> Don Stewart ha scritto:
>>> manlio_perillo:
>>>> Hi.
>>>>
>>>> After having read
>>>> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id676390
>>>>
>>>> I have a doubt about Data.ByteString.Lazy.
>>>>
>>>> Why getContents function don't use pread (or an emulation, if not 
>>>> available)?
>>> Why would it?
>>>
>> So that you don't need to open the same file multiple time:
>> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id677193
> 
> We are constrained here by the semantics of Handle which requires
> that ?getContents semi-close the Handle (which in turn is to make it
> harder to shoot yourself in the foot while doing lazy IO).
> 

But if every function that reads the data uses pread, then this should 
no more be a problem.

Or I'm missing some other thing?


> Duncan



Manlio Perillo
From jonathanccast at fastmail.fm  Fri Sep 19 13:59:18 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Fri Sep 19 14:02:19 2008
Subject: [Haskell-cafe] Lazy vs correct IO [Was: A round of golf]
In-Reply-To: 
References: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
	
Message-ID: <1221847158.32733.0.camel@jcchost>

On Fri, 2008-09-19 at 16:30 +0100, Lennart Augustsson wrote:
> I agree that lazy IO is a can with some worms in it.  But it's not that strange.
> The readFile operation is in the IO monad, so it has an effect on the world.
> This effect is not finished when readFile returns, and from the world
> point of view
> it's not entirely deterministic.

On operating systems that fail to maintain file system consistency.

Blaming an effect of an *operating system* misfeature on a *language*
feature is somewhat perverse.

jcc


From duncan.coutts at worc.ox.ac.uk  Fri Sep 19 14:15:26 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Sep 19 14:22:55 2008
Subject: [Haskell-cafe] lazy strings and parallel read
In-Reply-To: <48D3E653.3090403@libero.it>
References: <48D3CD13.1030205@libero.it>
	<20080919161435.GA11506@scytale.galois.com>
	<48D3D755.3040602@libero.it>
	<1221843697.5395.570.camel@localhost>  <48D3E653.3090403@libero.it>
Message-ID: <1221848126.5395.613.camel@localhost>

On Fri, 2008-09-19 at 19:50 +0200, Manlio Perillo wrote:

> But if every function that reads the data uses pread, then this should 
> no more be a problem.
> 
> Or I'm missing some other thing?

If you used something like pread instead of hGetContents then yes that
would not involve semi-closing a handle or doing lazy IO. Of course
pread only works for seekable Handles like files, not terminals, pipes,
sockets etc etc.

Duncan

From bulat.ziganshin at gmail.com  Fri Sep 19 15:17:14 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Fri Sep 19 15:16:18 2008
Subject: [Haskell-cafe] performance of map reduce
In-Reply-To: <20080919171243.GB11802@scytale.galois.com>
References: <48D3D650.1050805@libero.it>
	<20080919171243.GB11802@scytale.galois.com>
Message-ID: <1502342047.20080919231714@gmail.com>

Hello Don,

Friday, September 19, 2008, 9:12:43 PM, you wrote:

>> It is possible to implement a map reduce version that can handle gzipped
>> log files?

> Using the zlib binding on hackage.haskell.org, you can stream multiple
> zlib decompression threads with lazy bytestrings, and combine the
> results.

for gzip decompression you need to decompress all the previous data,
so decompression of single file cannot be multithreaded


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From dave at zednenem.com  Fri Sep 19 15:36:44 2008
From: dave at zednenem.com (David Menendez)
Date: Fri Sep 19 15:34:03 2008
Subject: [Haskell-cafe] Lazy vs correct IO [Was: A round of golf]
In-Reply-To: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
References: <20080919065159.616A5AF09@Adric.metnet.fnmoc.navy.mil>
Message-ID: <49a77b7a0809191236r53081477r5996baa53251798@mail.gmail.com>

On Fri, Sep 19, 2008 at 2:51 AM,   wrote:
>
> Lennart Augustsson wrote
>
>> main = do
>>    name:_ <- getArgs
>>    file <- readFile name
>>    print $ length $ lines file
>
> Given the stance against top-level mutable variables, I have not
> expected to see this Lazy IO code. After all, what could be more against
> the spirit of Haskell than a `pure' function with observable side
> effects. With Lazy IO, one indeed has to choose between correctness
> and performance. The appearance of such code is especially strange
> after the evidence of deadlocks with Lazy IO, presented on this list
> less than a month ago. Let alone unpredictable resource usage and
> reliance on finalizers to close files (forgetting that GHC does not
> guarantee that finalizers will be run at all).
>
> Is there an alternative?
>
> -- Counting the lines in a file
> import IterateeM
>
> count_nl = liftI $ IE_cont (step 0)
>  where
>  step acc (Chunk str)  = liftI $ IE_cont (step $! acc + count str)
>  step acc stream       = liftI $ IE_done acc stream
>  count [] = 0
>  count ('\n':str) = succ $! count str
>  count (_:str) = count str
>
> main = do
>   name:_ <- getArgs
>   IE_done counter _ <- unIM $ enum_file name >. enum_eof ==<< count_nl
>   print counter
>
>
> The function count_nl could have been in the library, but I'm a
> minimalist. It is written in a declarative rather than imperative
> style, and one easily sees what it does. The above code as well as the
> IterateeM library is Haskell98. It does not use any unsafe Haskell
> functions whatsoever.

Is the IterateeM library available on-line anywhere? I'm familiar
enough with your earlier work on enumerators that I can guess what
most of what that code is doing, but I'd like a better idea of what
==<< does.

-- 
Dave Menendez 

From jgoerzen at complete.org  Fri Sep 19 15:59:49 2008
From: jgoerzen at complete.org (John Goerzen)
Date: Fri Sep 19 15:57:12 2008
Subject: [Haskell-cafe] Hackage and HaXml situation
In-Reply-To: <1221776420.5395.513.camel@localhost>
References: <48D2BADF.5080009@complete.org>
	<1221776420.5395.513.camel@localhost>
Message-ID: <48D404B5.40804@complete.org>

Duncan Coutts wrote:
> On Thu, 2008-09-18 at 15:32 -0500, John Goerzen wrote:
> Basically for each package we have an optional suggested version
> constraint. This would be used in the hackage website to direct people

That would solve the problem nicely, I think.  Do you have an ETA for
this feature?


> to the 'current' version but most importantly it'd be used by
> cabal-install and other cabal -> native package conversion tools. It
> wold be editable on the hackage website by the package author/maintainer
> and probably other ?people with the role of managing the hackage
> collection.
> 
> Cases like HaXml-1.13 -> 1.19 (or a future stable version) or old-time
> -> time are also things that the platform might be able to help with in
> future by managing the transition in a more coherent way rather than
> what we have now where the transition is rather hap-hazard with half
> using one and half the other.
> 
> Duncan
> 
> 

From thomas.dubuisson at gmail.com  Fri Sep 19 19:34:12 2008
From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson)
Date: Fri Sep 19 16:31:41 2008
Subject: [Haskell-cafe] control-timeout with gtk
In-Reply-To: <1221826193.4567.67.camel@quindinho.domain.invalid>
References: <1221756395.4567.29.camel@quindinho.domain.invalid>
	<6d74b0d20809181005u608db6a8gf178052cf3575a63@mail.gmail.com>
	<1221826193.4567.67.camel@quindinho.domain.invalid>
Message-ID: <1221867252.3497.34.camel@myhost>

On Fri, 2008-09-19 at 09:09 -0300, Marco T?lio Gontijo e Silva wrote:
> I added the NOINLINE annotations and even tried building with -fno-cse,
> but the result was the same.  Do you have any other suggestions?

A while ago I made a shim using control-event to provide the
control-timeout api in Control.Event.Timeout.  It performs worse than
control-timeout because it computes absolute times on each addTimeout
call, but might be fine for your needs.

If this is a problem with unsafePeformIO it won't be fixed by this
change - control-event uses the same hack to provide the control-timeout
API.  Alternatively, you could pass the timeout data structure as an
argument as expected by the Control.Event module.

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-event

Tom

From andre at digirati.com.br  Fri Sep 19 16:55:19 2008
From: andre at digirati.com.br (Andre Nathan)
Date: Fri Sep 19 16:54:03 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <48D36437.9010209@dfki.de>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<1221776716.5395.518.camel@localhost>  <48D36437.9010209@dfki.de>
Message-ID: <1221857719.5955.18.camel@homesick>

On Fri, 2008-09-19 at 10:35 +0200, Christian Maeder wrote:
> I agree. Duncan's version also looks more atomic to me,
[...]

OK, so what I have now is

  addVertex :: Int -> a -> Graph a b -> Graph a b
  addVertex v l g = Graph adj (numVertices g + 1) (numEdges g)
    where adj = Map.insert v (l, Map.empty) (adjacencies g)

  addEdge :: Int -> Int -> b -> Graph a b -> Graph a b
  addEdge v w l g = Graph adj (numVertices g) (numEdges g + 1)
    where adj = Map.insert v (vl, ns') (adjacencies g)
          ns' = Map.insert w l ns
          (vl, ns) = fromJust $ Map.lookup v (adjacencies g)

Creating a random graph [G(n,p) model] the naive way:

  type RandomGraph a b = StateT (Graph a b) IO ()

  randomGraph :: Int -> Double -> IO (Graph Int Int)
  randomGraph n p = execStateT create Graph.empty
    where create = mapM_ (uncurry $ createVertex p) vls
          vls    = zip [1..n] (repeat 1)

  createVertex :: Double -> Int -> a -> RandomGraph a Int
  createVertex p v l = do
    modify (Graph.addVertex v l)
    createEdges v p

  createEdges :: Int -> Double -> RandomGraph a Int
  createEdges n p = mapM_ (maybeAddEdges n) [1..n-1]
    where maybeAddEdges v w = do
            maybeAddEdge v w
            maybeAddEdge w v
          maybeAddEdge v w = do
            r <- lift randomDouble
            when (r < p) $ modify (addEdge v w 1)

  randomDouble :: IO Double
  randomDouble = randomIO

So, to reference another thread, does this make anyone cry? :)

Thanks a lot for the suggestions,
Andre

From andre at digirati.com.br  Fri Sep 19 16:57:51 2008
From: andre at digirati.com.br (Andre Nathan)
Date: Fri Sep 19 16:56:34 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: 
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	
Message-ID: <1221857871.5955.20.camel@homesick>

On Fri, 2008-09-19 at 09:51 +0200, apfelmus wrote:
> There's also Martin Erwig's functional graph library in  Data.Graph.Inductive  (
> fgl  on hackage).

I tried it some time ago, but for large graphs it has a very high memory
usage.

Best,
Andre

From manlio_perillo at libero.it  Fri Sep 19 17:14:04 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 17:11:29 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big   advantages?
In-Reply-To: 
References: <20080917053300.GC2213@scytale.galois.com>	<48D0FEF5.5080707@libero.it>	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>		<1221678201.18670.12.camel@jcchost>		<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>	<1221684951.18670.41.camel@jcchost>
	<48D22062.6030109@gmail.com> <48D2A78F.7090907@libero.it>
	
Message-ID: <48D4161C.5070609@libero.it>

Brandon S. Allbery KF8NH ha scritto:
> On Sep 18, 2008, at 15:10 , Manlio Perillo wrote:
>>> Allocation areas are per-CPU, not per-thread.  A Concurrent Haskell 
>>> thread consists of a TSO (thread state object, currently 11 machine 
>>> words), and a stack, which we currently start with 1KB and grow on 
>>> demand.
>>
>> How is this implemented?
>>
>> I have seen some coroutine implementations in C, using functions from 
>> ucontext.h (or direct asm code), but all have the problem that the 
>> allocated stack is fixed.
> 
> 
> That's because it's much easier to use a fixed stack.
> 
> There are two ways to handle a growable stack; both start with 
> allocating each stack in a separate part of the address space with room 
> to grow it downward.  The simpler way uses stack probes on function 
> entry to detect impending stack overflow.  The harder (and less 
> portable) one involves trapping page faults ("segmentation violation" on 
> POSIX), enlarging the stack, and restarting the instruction that caused 
> the trap; this requires fairly detailed knowledge of the CPU and the way 
> signals or page faults are handled by the OS.  (There's also a hybrid 
> which many POSIXish systems use, trapping the page fault specifically 
> when running the stack probe; the probe is designed to be safe to either 
> restart or ignore, so it can be handled more portably.)
> 

What implementation is used in GHC?

Is this more easy to implement with a pure functional language like 
Haskell, or the same implementation can be used with a procedural 
language like C?



Thanks   Manlio
From daniel.is.fischer at web.de  Fri Sep 19 17:16:47 2008
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Fri Sep 19 17:11:59 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <1221857719.5955.18.camel@homesick>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<48D36437.9010209@dfki.de> <1221857719.5955.18.camel@homesick>
Message-ID: <200809192316.47285.daniel.is.fischer@web.de>

Am Freitag, 19. September 2008 22:55 schrieb Andre Nathan:
> On Fri, 2008-09-19 at 10:35 +0200, Christian Maeder wrote:
> > I agree. Duncan's version also looks more atomic to me,
>
> [...]
>
> OK, so what I have now is
>
>   addVertex :: Int -> a -> Graph a b -> Graph a b
>   addVertex v l g = Graph adj (numVertices g + 1) (numEdges g)
>     where adj = Map.insert v (l, Map.empty) (adjacencies g)
>
>   addEdge :: Int -> Int -> b -> Graph a b -> Graph a b
>   addEdge v w l g = Graph adj (numVertices g) (numEdges g + 1)
>     where adj = Map.insert v (vl, ns') (adjacencies g)
>           ns' = Map.insert w l ns
>           (vl, ns) = fromJust $ Map.lookup v (adjacencies g)
>
> Creating a random graph [G(n,p) model] the naive way:
>
>   type RandomGraph a b = StateT (Graph a b) IO ()
>
>   randomGraph :: Int -> Double -> IO (Graph Int Int)
>   randomGraph n p = execStateT create Graph.empty
>     where create = mapM_ (uncurry $ createVertex p) vls
>           vls    = zip [1..n] (repeat 1)
>
>   createVertex :: Double -> Int -> a -> RandomGraph a Int
>   createVertex p v l = do
>     modify (Graph.addVertex v l)
>     createEdges v p
>
>   createEdges :: Int -> Double -> RandomGraph a Int
>   createEdges n p = mapM_ (maybeAddEdges n) [1..n-1]
>     where maybeAddEdges v w = do
>             maybeAddEdge v w
>             maybeAddEdge w v
>           maybeAddEdge v w = do
>             r <- lift randomDouble
>             when (r < p) $ modify (addEdge v w 1)
>
>   randomDouble :: IO Double
>   randomDouble = randomIO
>
> So, to reference another thread, does this make anyone cry? :)

Yes. What's IO gotta do with it?
It's much cleaner to pass the PRNG as an explicit argument (or what about
StateT (Graph a b) (State StdGen) ?).

And in addVertex/addEdge, it might be good to check whether the vertex/edge is 
already present.
>
> Thanks a lot for the suggestions,
> Andre
>

From manlio_perillo at libero.it  Fri Sep 19 17:31:46 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 17:29:10 2008
Subject: [Haskell-cafe] performance of map reduce
In-Reply-To: <20080919171243.GB11802@scytale.galois.com>
References: <48D3D650.1050805@libero.it>
	<20080919171243.GB11802@scytale.galois.com>
Message-ID: <48D41A42.8000807@libero.it>

Don Stewart ha scritto:
> manlio_perillo:
> [...]
>> It is possible to implement a map reduce version that can handle gzipped 
>> log files?
> 
> Using the zlib binding on hackage.haskell.org, you can stream multiple
> zlib decompression threads with lazy bytestrings, and combine the
> results.
> 

This is a bit hard.
A deflate encoded stream contains multiple blocks, so you need to find 
the offset of each block and decompress it in parallel.
But then you need also to make sure each final block terminates with a '\n'.

And the zlib Haskell binding does not support this usage (I'm not even 
sure zlib support this).



By the way, this phrase:
"We allow multiple threads to read different chunks at once by supplying 
each one with a distinct file handle, all reading the same file"
here:
http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id677193

IMHO is not correct, or at least misleading.
Each block is read in the main thread, or at least myThreadId return 
always the same value.

This is also the reason why I don't understand why my version is slower 
then the book version.
The only difference is that the book version reads 4 chunks and my 
version only 1 big chunk.


> -- Don
> 


Thanks   Manlio
From bos at serpentine.com  Fri Sep 19 17:48:15 2008
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Fri Sep 19 17:45:35 2008
Subject: [Haskell-cafe] performance of map reduce
In-Reply-To: <48D41A42.8000807@libero.it>
References: <48D3D650.1050805@libero.it>
	<20080919171243.GB11802@scytale.galois.com>
	<48D41A42.8000807@libero.it>
Message-ID: 

On Fri, Sep 19, 2008 at 2:31 PM, Manlio Perillo wrote:

>
> By the way, this phrase:
> "We allow multiple threads to read different chunks at once by supplying
> each one with a distinct file handle, all reading the same file"
> here:
>
> http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id677193
>
> IMHO is not correct, or at least misleading.
>

It's both correct and, er, leading. The files are opened in a single thread,
and then the file handles are read by multiple threads.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080919/3c3e1f5b/attachment.htm
From allbery at ece.cmu.edu  Fri Sep 19 17:53:48 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Fri Sep 19 17:51:09 2008
Subject: [Haskell-cafe] Re: Python's big challenges,
	Haskell's big   advantages?
In-Reply-To: <48D4161C.5070609@libero.it>
References: <20080917053300.GC2213@scytale.galois.com>	<48D0FEF5.5080707@libero.it>	<28012bc60809170609k2b4748bbw25fd13faf84477bf@mail.gmail.com>		<1221678201.18670.12.camel@jcchost>		<2518b95d0809171344t58e5b4c6rb2023928a9e5f17f@mail.gmail.com>	<1221684951.18670.41.camel@jcchost>
	<48D22062.6030109@gmail.com> <48D2A78F.7090907@libero.it>
	
	<48D4161C.5070609@libero.it>
Message-ID: 

On 2008 Sep 19, at 17:14, Manlio Perillo wrote:
> Brandon S. Allbery KF8NH ha scritto:
>> There are two ways to handle a growable stack; both start with  
>> allocating each stack in a separate part of the address space with  
>> room to grow it downward.  The simpler way uses stack probes on  
>> function entry to detect impending stack overflow.  The harder (and  
>> less portable) one involves trapping page faults ("segmentation  
>> violation" on POSIX), enlarging the stack, and restarting the  
>> instruction that caused the trap; this requires fairly detailed  
>> knowledge of the CPU and the way signals or page faults are handled  
>> by the OS.  (There's also a hybrid which many POSIXish systems use,  
>> trapping the page fault specifically when running the stack probe;  
>> the probe is designed to be safe to either restart or ignore, so it  
>> can be handled more portably.)
>
> What implementation is used in GHC?

I haven't looked at the GHC implementation.

> Is this more easy to implement with a pure functional language like  
> Haskell, or the same implementation can be used with a procedural  
> language like C?


You can use it with pretty much any language, as long as you can limit  
the size of stack frames.  (If a stack frame is larger than the stack  
probe distance you might just get an unhandled page fault.)  The main  
question is whether you ant to absorb the additional complexity; it's  
a bit harder to debug memory issues when you have to deal with page  
faults yourself.  (A *real* segmentation violation might be hidden by  
the stack grow code.)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From manlio_perillo at libero.it  Fri Sep 19 17:59:22 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Fri Sep 19 17:56:46 2008
Subject: [Haskell-cafe] performance of map reduce
In-Reply-To: 
References: <48D3D650.1050805@libero.it>	
	<20080919171243.GB11802@scytale.galois.com>	
	<48D41A42.8000807@libero.it>
	
Message-ID: <48D420BA.4060204@libero.it>

Bryan O'Sullivan ha scritto:
> On Fri, Sep 19, 2008 at 2:31 PM, Manlio Perillo 
> > wrote:
> 
> 
>     By the way, this phrase:
>     "We allow multiple threads to read different chunks at once by
>     supplying each one with a distinct file handle, all reading the same
>     file"
>     here:
>     http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html#id677193
> 
>     IMHO is not correct, or at least misleading.
> 
> 
> It's both correct and, er, leading. The files are opened in a single 
> thread, and then the file handles are read by multiple threads.

Ah, right, thanks.
They are read with ByteString.Lazy.



Manlio Perillo
From magnus at therning.org  Fri Sep 19 18:24:19 2008
From: magnus at therning.org (Magnus Therning)
Date: Fri Sep 19 18:21:47 2008
Subject: [Haskell-cafe] Parsing arguments and reading configuration
Message-ID: <48D42693.8040507@therning.org>

Hi all,

I'm looking for some inspiration for an elegant solution to a silly
little problem I have.  This might have a general well-known solution,
or maybe there's something particularly elegant possible in Haskell.  I
just thought I'd ask.

When writing a command line tool I want to use a configuration file and
then have the ability to override the configuration using command line
arguments.  When I've worked with command line arguments before I've
used the trick of folding (>>=) over a list of functions that modify the
"members" of a type, using the default values as the starting point.  I
like that, it's cute.

First I thought I'd treat the configuration in a similar way, but then I
noticed a slight ordering problem.  The command line arguments should
take priority over the contents of the configuration file, but the
location of the configuration can be given as an argument.  I could read
the arguments twice, first to get the correct location of the config
file, then load the config, and then read the arguments again to make
sure they take priority.  But that feels a little silly.  Are there any
more elegant solutions people are using?

/M

-- 
Magnus Therning                             (OpenPGP: 0xAB4DFBA4)
magnus?therning?org             Jabber: magnus?therning?org
http://therning.org/magnus

Haskell is an even 'redder' pill than Lisp or Scheme.
     -- PaulPotts


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080919/7d14ae61/signature.bin
From dons at galois.com  Fri Sep 19 18:43:29 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 19 18:40:45 2008
Subject: [Haskell-cafe] ANNOUNCE: Extensible and Modular Generics for the
	Masses (EMGM) 0.1
In-Reply-To: <3c6288ab0809190905h171fe0a6i3aac97454ba700e@mail.gmail.com>
References: <3c6288ab0809190905h171fe0a6i3aac97454ba700e@mail.gmail.com>
Message-ID: <20080919224329.GL11802@scytale.galois.com>

leather:
>    Extensible and Modular Generics for the Masses
>    ==============================================
> 
>    Extensible and Modular Generics for the Masses (EMGM) is a library for
>    generic programming in Haskell using type classes.
> 
>    This is the initial release of a maintained library for EMGM. Other
>    versions have previously existed in various states from various sources.
>    We plan to continue updating and maintaining this version.
> 
>    Visit the home page:
> 
>      [1]http://www.cs.uu.nl/wiki/GenericProgramming/EMGM
> 

Now in Arch Linux,

    http://aur.archlinux.org/packages.php?ID=20070

Come on Debian!

-- Don
From andre at digirati.com.br  Fri Sep 19 19:02:40 2008
From: andre at digirati.com.br (Andre Nathan)
Date: Fri Sep 19 19:01:24 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <200809192316.47285.daniel.is.fischer@web.de>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<48D36437.9010209@dfki.de> <1221857719.5955.18.camel@homesick>
	<200809192316.47285.daniel.is.fischer@web.de>
Message-ID: <1221865360.5955.30.camel@homesick>

On Fri, 2008-09-19 at 23:16 +0200, Daniel Fischer wrote:
> Yes. What's IO gotta do with it?

I did it because of randomIO :(

> (or what about StateT (Graph a b) (State StdGen) ?).

Now there's something I wouldn't have thought of... I changed the
RandomGraph type to

  type RandomGraph a b = StateT (Graph a b) (State StdGen) ()

and randomFloat to

  randomDouble :: State StdGen Double
  randomDouble = State random

and randomGraph to

  randomGraph :: StdGen -> Int -> Double -> Graph Int Int
  randomGraph gen n p = evalState (execStateT create Graph.empty) gen
    where create = mapM_ (uncurry $ createVertex p) vls
          vls    = zip [1..n] (repeat 42)

However, when I try to create a graph with 1000 vertices I get a stack
overflow, which didn't happen in the IO version. Any idea why that happens?

Thanks,
Andre

From derek.a.elkins at gmail.com  Fri Sep 19 19:29:51 2008
From: derek.a.elkins at gmail.com (Derek Elkins)
Date: Fri Sep 19 19:27:13 2008
Subject: [Haskell-cafe] Parsing arguments and reading configuration
In-Reply-To: <48D42693.8040507@therning.org>
References: <48D42693.8040507@therning.org>
Message-ID: <1221866991.13718.3.camel@derek-laptop>

On Fri, 2008-09-19 at 23:24 +0100, Magnus Therning wrote:
> Hi all,
> 
> I'm looking for some inspiration for an elegant solution to a silly
> little problem I have.  This might have a general well-known solution,
> or maybe there's something particularly elegant possible in Haskell.  I
> just thought I'd ask.
> 
> When writing a command line tool I want to use a configuration file and
> then have the ability to override the configuration using command line
> arguments.  When I've worked with command line arguments before I've
> used the trick of folding (>>=) over a list of functions that modify the
> "members" of a type, using the default values as the starting point.  I
> like that, it's cute.
> 
> First I thought I'd treat the configuration in a similar way, but then I
> noticed a slight ordering problem.  The command line arguments should
> take priority over the contents of the configuration file, but the
> location of the configuration can be given as an argument.  I could read
> the arguments twice, first to get the correct location of the config
> file, then load the config, and then read the arguments again to make
> sure they take priority.  But that feels a little silly.  Are there any
> more elegant solutions people are using?

You could build a monoid,
data Option a = Unspecified | Default a | Config a | CommandLine a

With Unspecified being the identity and the multiplication being
Default a * Config b = Config b
Default a * CommandLine b = CommandLine b
Config a * CommandLine b = CommandLine b
and symmetrically and break ties to the right e.g.
CommandLine a * CommandLine b = CommandLine b


From aslatter at gmail.com  Fri Sep 19 20:35:33 2008
From: aslatter at gmail.com (Antoine Latter)
Date: Fri Sep 19 20:32:50 2008
Subject: [Haskell-cafe] Parsing arguments and reading configuration
In-Reply-To: <48D42693.8040507@therning.org>
References: <48D42693.8040507@therning.org>
Message-ID: <694519c50809191735w178e66c2j101484d989a1da1a@mail.gmail.com>

2008/9/19 Magnus Therning :
>
> First I thought I'd treat the configuration in a similar way, but then I
> noticed a slight ordering problem.  The command line arguments should
> take priority over the contents of the configuration file, but the
> location of the configuration can be given as an argument.  I could read
> the arguments twice, first to get the correct location of the config
> file, then load the config, and then read the arguments again to make
> sure they take priority.  But that feels a little silly.  Are there any
> more elegant solutions people are using?

I'm not sure how well it would hold up under maintenance, but you coud
have a config sum-type which is itself a monoid, and then create two
of them:

> data UserConfig = UserConfig
>   { item1 :: Maybe Type1
>   , item2 :: Maybe Type2
>   , configFileLocation :: Maybe FilePath
>   }

> instance Monoid UserConfig where
>  {- not shown -}

> buildConfig :: IO UserConfig
> buildConfig = do
>   cmdLineCfg <- buildConfigFromCmdLine
>   fileCfg <- maybe (return mempty) buildConfigFromFile (configFileLocation cmdLineCfg)
>
>   return $ fileCfg `mappend` cmdLineCfg

> -- mappend is assumed to be left-biased

> buildConfigFromCmdLine :: IO UserConfig
> buildConfigFromFile :: FilePath -> IO UserConfig

Does that make sense?  or is it too complicated?

-Antoine
From aslatter at gmail.com  Fri Sep 19 20:39:32 2008
From: aslatter at gmail.com (Antoine Latter)
Date: Fri Sep 19 20:36:51 2008
Subject: [Haskell-cafe] Parsing arguments and reading configuration
In-Reply-To: <694519c50809191735w178e66c2j101484d989a1da1a@mail.gmail.com>
References: <48D42693.8040507@therning.org>
	<694519c50809191735w178e66c2j101484d989a1da1a@mail.gmail.com>
Message-ID: <694519c50809191739i3a931c21k26f7249bf879d8a7@mail.gmail.com>

On Fri, Sep 19, 2008 at 7:35 PM, Antoine Latter  wrote:
> I'm not sure how well it would hold up under maintenance, but you coud
> have a config sum-type which is itself a monoid, and then create two
> of them:
>

And by sum-type I mean product type.  Sheesh.

Although having your config options in a sum-type packed into a Set,
which is itself a Monoid is another option.  Then you get 'mempty' and
'mappend' for free.

I think I saw a blog-post or something detailing this, but I don't
have a book-mark.

-Antoine
From RafaelGCPP.Linux at gmail.com  Fri Sep 19 20:50:52 2008
From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto)
Date: Fri Sep 19 20:48:12 2008
Subject: [Haskell-cafe] Ropes
In-Reply-To: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
Message-ID: <351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>

Hi all,

Is there any implementation of the rope data structure in Haskell?

I couldn't find any on Hackage, and I am intending to implement it.

Regards,

Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080919/fd4c482e/attachment.htm
From gwern0 at gmail.com  Fri Sep 19 21:01:46 2008
From: gwern0 at gmail.com (Gwern Branwen)
Date: Fri Sep 19 20:59:06 2008
Subject: [Haskell-cafe] ANNOUNCE: citeproc-hs,
	a Haskell implementation of the Citation Style Language designed for
	Pandoc
In-Reply-To: <20080913173305.GB23265@Andrea.Nowhere.net>
References: <20080913173305.GB23265@Andrea.Nowhere.net>
Message-ID: 

On Sat, Sep 13, 2008 at 1:33 PM, Andrea Rossato
 wrote:
> Hello,
>
> I'm happy to announce the first release of citeproc-hs, a Haskell
> implementation of the Citation Style Language.
>
> citeproc-hs adds to Pandoc, the famous Haskell text processing tool, a
> Bibtex like citation and bibliographic formatting and generation
> facility.
...
> John MacFarlane, the author of Pandoc, has been very supportive of the
> project and provided a lot of useful feed back, comments and
> suggestions.
>
> Hope you'll enjoy,
> Andrea Rossato

Hi Andrea. So I was looking at the README. Does citeproc-hs only
support adding refs from a .xml file when one's written in Pandoc
markdown? That is, I don't see how I could take a .lhs file and a .bib
file and produce one of the Pandoc-supported outputs. In particular,
I'd really like to be able to go .lhs -> .wiki, with refs; this would
let me convert The Monad Reader articles for haskell.org.

--
gwern
From vlm at lionet.info  Fri Sep 19 21:24:22 2008
From: vlm at lionet.info (Lev Walkin)
Date: Fri Sep 19 21:21:48 2008
Subject: [Haskell-cafe] Re: XML (HXML) parsing :: GHC 6.8.3 space leak
	from	2000
In-Reply-To: <48D285D1.7000104@lionet.info>
References: <48D1F3DC.9040903@lionet.info> <48D21B31.8000908@gmail.com>
	<48D285D1.7000104@lionet.info>
Message-ID: <48D450C6.4080306@lionet.info>

Lev Walkin wrote:
> Simon Marlow wrote:
>> Lev Walkin wrote:
>>
>>> I wondered why would a contemporary GHC 6.8.3 exhibit such a leak?
>>> After all, the technique was known in 2000 (and afir by Wadler in '87)
>>> and one would assume Joe English's reference to "most other Haskell
>>> systems" ought to mean GHC.
>>
>> Thanks for this nice example - Don Stewart pointed me to it, and  
>> Simon PJ and I just spent some time this morning diagnosing it.
>>
>> Incedentally, with GHC 6.8 you can just run the program with "+RTS 
>> -hT" to get a basic space profile, there's no need to compile it for 
>> profiling - this is tremendously useful for quick profiling jobs.  And 
>> in this case we see the the heap is filling up with (:) and Tree 
>> constructors, no thunks.
>>
>> Here's the short story:  GHC does have the space leak optimisation you 
>> refer to, and it is working correctly, but it doesn't cover all the 
>> cases you might want it to cover.  In particular, optimisations 
>> sometimes interact badly with the space leak avoidance, and that's 
>> what is happening here.  We've known about the problem for some time, 
>> but this is the first time I've seen a nice small example that 
>> demonstrates it.
>>
>>>     -- Lazily build a tree out of a sequence of tree-building events
>>>     build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String])
>>>     build (Start str : es) =
>>>             let (es', subnodes) = build es
>>>                 (spill, siblings) = build es'
>>>             in (spill, (Tree str subnodes : siblings))
>>>     build (Leaf str : es) =
>>>             let (spill, siblings) = build es
>>>             in (spill, Tree str [] : siblings)
>>>     build (Stop : es) = (es, [])
>>>     build [] = ([], [])
> 
> [skip]
> 
>> We don't know of a good way to fix this problem.  I'm going to record 
>> this example in a ticket for future reference, though.
> 
> Simon,
> 
> is there a way, perhaps, to rewrite this expression to avoid leaks?
> An ad-hoc will do, perhaps split in two modules to avoid intramodular
> optimizations?

Tried to avoid this misoptimization by using explicit fst, and
it worked on my synthesized input (probably benefiting of CSE):

build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String])
build (Start str : es) =
         let (_, subnodes) = build es
             (spill, siblings) = build . fst . build $ es
         in (spill, (Tree str subnodes : siblings))
build (Leaf str : es) =
         let (spill, siblings) = build es
         in (spill, Tree str [] : siblings)
build (Stop : es) = (es, [])
build [] = ([], [])

However, while this solution works on a synthesized input (cycle [...]),
it still has memory leak when taken into HXML environment which
operates on files (why?).

Only when I also added Ketil Malde's `par` based hack I finally
was able to parse the big XML file without a space leak. Here's
the diff to HXML 0.2:

======================================================================
--- TreeBuild.hs.old	2008-09-19 17:01:30.000000000 -0700
+++ TreeBuild.hs	2008-09-19 17:04:15.000000000 -0700
@@ -20,6 +20,7 @@
  import XMLParse
  import XML
  import Tree
+import Control.Parallel

  --
  -- TODO: add basic error-checks: matching end-tags, ensure input exhausted
@@ -43,8 +44,9 @@
  	addTree t es		= let (s,es') = build es in pair (cons t s) es'
  	build [] 		= pair nil []
  	build (e:es) = case e of
-	    StartEvent gi atts	-> let (c,es') = build es
-	    			   in addNode (ELNode gi atts) c es'
+	    StartEvent gi atts  -> let (c, es') = build es
+				       sbl = build . snd . build $ es
+				   in sbl `par` (cons (tree (ELNode gi atts) c) (fst sbl), snd sbl)
  	    EndEvent _		-> pair nil es
  	    EmptyEvent gi atts	-> addLeaf (ELNode gi atts) es
  	    TextEvent s		-> addLeaf (TXNode s) es
=======================================================================

With that, a 45 mb XML is parsed in constant space in

G4 1.5GHz: 1 minute 48 seconds, taking 16 mb RAM
Pentium D 2x3.0GHz: 12 seconds, taking 9 mb RAM

Compared to 0.2s `wc -l`.

If you
   * remove `par` from there or
   * replace (build . snd . build $ es) with just (es') or
   * forget to specify -threaded (-smp) during ghc compilation
then the space leak will exhibit itself again.

However, removing -threaded will still make this code run without leak
on synthesized input (StartEvent "" [] : cycle [TextEvent ""]).

I believe there's a way to get rid of `par`, perhaps by wrapping
this tree building thing into a optimization-unfriendly monad?
But I don't know how to approach this. Any help?

-- 
Lev Walkin
vlm@lionet.info
From ryani.spam at gmail.com  Fri Sep 19 22:15:13 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Fri Sep 19 22:12:31 2008
Subject: [Haskell-cafe] Ropes
In-Reply-To: <351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
Message-ID: <2f9b2d30809191915m2cdd8963yded4fb1c14c40c43@mail.gmail.com>

I think Data.Sequence uses fingertrees which are pretty fast.

I used a handgrown rope-like structure for ICFPC07 but I wish I had
known about Sequence; it would have likely just been better.

  -- ryan

2008/9/19 Rafael Gustavo da Cunha Pereira Pinto :
> Hi all,
>
> Is there any implementation of the rope data structure in Haskell?
>
> I couldn't find any on Hackage, and I am intending to implement it.
>
> Regards,
>
> Rafael Gustavo da Cunha Pereira Pinto
> Electronic Engineer, MSc.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
From dons at galois.com  Fri Sep 19 22:18:28 2008
From: dons at galois.com (Don Stewart)
Date: Fri Sep 19 22:20:42 2008
Subject: [Haskell-cafe] Ropes
In-Reply-To: <351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
Message-ID: <20080920021828.GB13378@scytale.galois.com>

RafaelGCPP.Linux:
>    Hi all,
> 
>    Is there any implementation of the rope data structure in Haskell?
> 
>    I couldn't find any on Hackage, and I am intending to implement it.

There's no mature rope implementation. Can you write a bytestring-rope
that outperforms lazy bytestrings please :)
From dave at zednenem.com  Sat Sep 20 02:53:01 2008
From: dave at zednenem.com (David Menendez)
Date: Sat Sep 20 02:50:18 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <1221865360.5955.30.camel@homesick>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<48D36437.9010209@dfki.de> <1221857719.5955.18.camel@homesick>
	<200809192316.47285.daniel.is.fischer@web.de>
	<1221865360.5955.30.camel@homesick>
Message-ID: <49a77b7a0809192353g65afb729td0d8f0597d4e40e7@mail.gmail.com>

On Fri, Sep 19, 2008 at 7:02 PM, Andre Nathan  wrote:
> On Fri, 2008-09-19 at 23:16 +0200, Daniel Fischer wrote:
>> Yes. What's IO gotta do with it?
>
> I did it because of randomIO :(
>
>> (or what about StateT (Graph a b) (State StdGen) ?).
>
> Now there's something I wouldn't have thought of... I changed the
> RandomGraph type to
>
>  type RandomGraph a b = StateT (Graph a b) (State StdGen) ()
>
> and randomFloat to
>
>  randomDouble :: State StdGen Double
>  randomDouble = State random
>
> and randomGraph to
>
>  randomGraph :: StdGen -> Int -> Double -> Graph Int Int
>  randomGraph gen n p = evalState (execStateT create Graph.empty) gen
>    where create = mapM_ (uncurry $ createVertex p) vls
>          vls    = zip [1..n] (repeat 42)
>
> However, when I try to create a graph with 1000 vertices I get a stack
> overflow, which didn't happen in the IO version. Any idea why that happens?

I believe modify is lazy. Try replacing it with a stricter version,

modify' f = do
    s <- get
    put $! f s

-- 
Dave Menendez 

From oleg at okmij.org  Sat Sep 20 03:42:36 2008
From: oleg at okmij.org (oleg@okmij.org)
Date: Sat Sep 20 03:41:33 2008
Subject: [Haskell-cafe] Iteratee-based IO
Message-ID: <20080920074236.8C9F4AF09@Adric.metnet.fnmoc.navy.mil>


brian wrote:
> I want to use Parsec to parse NNTP data coming to me from a handle I
> get from connectTo.
> One unworkable approach I tried is to get a lazy String from the
> handle with hGetContents.

It seems there is another approach, which is neither unsafe nor
imperative. It relies neither on lazy IO nor on Handles. The input
data can come from a file or from an embedded (e.g., chunk-encoded or
encrypted) stream; the depth of embedding is arbitrary. The approach
is naturally incremental. It permits IO interleaving without any
unsafe operations. The approach is algebraic and declarative. The
approach is the topic of the DEFUN08 talk in the morning of
September 27. The code is already available 

	http://okmij.org/ftp/Haskell/Iteratee/
The file
	http://okmij.org/ftp/Haskell/Iteratee/README.dr 
describes the other files in that directory. The running example is
reading lines (terminated by CR, LF or CRLF) from a file descriptor
and then from the chunk-encoded body. The main example illustrates
multiplexing across two file descriptors and the full IO
interleaving. The same line parser is used to process data from the
file descriptor stream and from the embedded chunk-encoded stream,
which is incrementally decoded.

The whole code is Haskell98. It is not optimized at all and has no
GHC-specific pragmas and options. The code has been used for the Wc
program demonstrated yesterday.
	
Perhaps the code answers the questions posed yesterday by
Don. Hopefully one can see several composition modes for the iteratees
and enumerators; enumerators are just iteratee transformers and
compose as such.


Incidentally, the operator ==<< is flipped >>==. Just like =<< (which
is flipped >>=), it is like a `call-by-value application'. When a 
call-by-value language evaluates the application (f e), the argument e
and all of its effects are executed first. Because of this analogy,
I'm tempted to rename <<== into something like $. or .$ (or
perhaps <$>, although the latter is taken). 

From aeyakovenko at gmail.com  Sat Sep 20 05:46:53 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Sat Sep 20 05:44:11 2008
Subject: [Haskell-cafe] having fun with GADT's
Message-ID: 

I dont remember where i saw it, but i think someone had an example of
a list whose type is the maximum element in the list.  I've been
trying to reproduce that with GADT's.

data One = One
data Two = Two
data Three = Three

data MaxList t where
   Elem1 :: MaxList One
   Elem2 :: MaxList Two
   ML1Cons1 :: MaxList One -> MaxList One -> MaxList One
   ML1Cons2 :: MaxList One -> MaxList Two -> MaxList Two
   ML2Cons1 :: MaxList Two -> MaxList One -> MaxList Two
   ML2Cons2 :: MaxList Two -> MaxList Two -> MaxList Two

a = ML2Cons2 Elem2 $ ML2Cons1 Elem2 $ ML1Cons1 Elem1 $ Elem1

so one problem is the tedium of defining a cons for each possible
combination.  The other problem is that i cant define a usefull tail
that makes any sense.

mlTail :: MaxList Two -> MaxList t
mlTail (ML2Cons2 a b) = b
mlTail (ML2Cons1 a b) = b

this one doesn't work, and probably because there is nothing that i
could do with the return value.

mlTail :: MaxList Two -> MaxList Two
mlTail (ML2Cons2 a b) = b
mlTail (ML2Cons1 a b) = b  --wont compile because b is a MaxList One

will only work for lists that only contain Two's, which is not what i
want either.  So is this somehow possible?

Thanks
From RafaelGCPP.Linux at gmail.com  Sat Sep 20 06:50:12 2008
From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto)
Date: Sat Sep 20 06:47:30 2008
Subject: [Haskell-cafe] Ropes
In-Reply-To: <351ff25e0809200349n2bae33cco5b327a85a4df7fa6@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
	<20080920021828.GB13378@scytale.galois.com>
	<351ff25e0809200349n2bae33cco5b327a85a4df7fa6@mail.gmail.com>
Message-ID: <351ff25e0809200350g312d89adidbdd048be69599c7@mail.gmail.com>

On Fri, Sep 19, 2008 at 23:18, Don Stewart  wrote:

> RafaelGCPP.Linux:
> >    Hi all,
> >
> >    Is there any implementation of the rope data structure in Haskell?
> >
> >    I couldn't find any on Hackage, and I am intending to implement it.
>
> There's no mature rope implementation. Can you write a bytestring-rope
> that outperforms lazy bytestrings please :)
>

I'll give it a try, but cannot promise anything on the "outperform" part!
:-)

-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/4683d671/attachment.htm
From RafaelGCPP.Linux at gmail.com  Sat Sep 20 06:54:26 2008
From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto)
Date: Sat Sep 20 06:51:42 2008
Subject: [Haskell-cafe] Ropes
In-Reply-To: <2f9b2d30809191915m2cdd8963yded4fb1c14c40c43@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
	<2f9b2d30809191915m2cdd8963yded4fb1c14c40c43@mail.gmail.com>
Message-ID: <351ff25e0809200354m6dc90c0apc723c26a1e4e53f@mail.gmail.com>

I am doing the ICFPC07 task right now, to learn Haskell and tried to use the
Sequence, but the final code is too damn slow (a few iterations per
minute!).

The DNA needs only 2 operations: head (or take) and concat.

I am thinking in using ropes for the DNA and sequences for all the rest
(patterns, templates and RNA).



On Fri, Sep 19, 2008 at 23:15, Ryan Ingram  wrote:

> I think Data.Sequence uses fingertrees which are pretty fast.
>
> I used a handgrown rope-like structure for ICFPC07 but I wish I had
> known about Sequence; it would have likely just been better.
>
>  -- ryan
>
> 2008/9/19 Rafael Gustavo da Cunha Pereira Pinto <
> RafaelGCPP.Linux@gmail.com>:
> > Hi all,
> >
> > Is there any implementation of the rope data structure in Haskell?
> >
> > I couldn't find any on Hackage, and I am intending to implement it.
> >
> > Regards,
> >
> > Rafael Gustavo da Cunha Pereira Pinto
> > Electronic Engineer, MSc.
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>



-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/8874ea95/attachment.htm
From apfelmus at quantentunnel.de  Sat Sep 20 07:38:24 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Sat Sep 20 07:35:54 2008
Subject: [Haskell-cafe] Re: Ropes
In-Reply-To: <351ff25e0809200354m6dc90c0apc723c26a1e4e53f@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>	<2f9b2d30809191915m2cdd8963yded4fb1c14c40c43@mail.gmail.com>
	<351ff25e0809200354m6dc90c0apc723c26a1e4e53f@mail.gmail.com>
Message-ID: 

Rafael Gustavo da Cunha Pereira Pinto wrote:
> I am doing the ICFPC07 task right now, to learn Haskell and tried to use the
> Sequence, but the final code is too damn slow (a few iterations per
> minute!).
> 
> The DNA needs only 2 operations: head (or take) and concat.
> 
> I am thinking in using ropes for the DNA and sequences for all the rest
> (patterns, templates and RNA).

I have been told that you could pretty much literally implement the algorithms
from the problem specification with  Seq  from  Data.Sequence  and achieve
acceptable speed (IIRC ~ one minute for generating a whole picture).

Are you sure that there is no unintentional bug in your implementation that
slows things down?


Regards,
apfelmus

From daniel.is.fischer at web.de  Sat Sep 20 08:56:52 2008
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Sat Sep 20 08:52:05 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <49a77b7a0809192353g65afb729td0d8f0597d4e40e7@mail.gmail.com>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<1221865360.5955.30.camel@homesick>
	<49a77b7a0809192353g65afb729td0d8f0597d4e40e7@mail.gmail.com>
Message-ID: <200809201456.53293.daniel.is.fischer@web.de>

Am Samstag, 20. September 2008 08:53 schrieb David Menendez:
> On Fri, Sep 19, 2008 at 7:02 PM, Andre Nathan  wrote:
> > On Fri, 2008-09-19 at 23:16 +0200, Daniel Fischer wrote:
> >> Yes. What's IO gotta do with it?
> >
> > I did it because of randomIO :(
> >
> >> (or what about StateT (Graph a b) (State StdGen) ?).
> >
> > Now there's something I wouldn't have thought of... I changed the
> > RandomGraph type to
> >
> >  type RandomGraph a b = StateT (Graph a b) (State StdGen) ()
> >
> > and randomFloat to
> >
> >  randomDouble :: State StdGen Double
> >  randomDouble = State random
> >
> > and randomGraph to
> >
> >  randomGraph :: StdGen -> Int -> Double -> Graph Int Int
> >  randomGraph gen n p = evalState (execStateT create Graph.empty) gen
> >    where create = mapM_ (uncurry $ createVertex p) vls
> >          vls    = zip [1..n] (repeat 42)
> >
> > However, when I try to create a graph with 1000 vertices I get a stack
> > overflow, which didn't happen in the IO version. Any idea why that
> > happens?
>
> I believe modify is lazy. Try replacing it with a stricter version,
>
> modify' f = do
>     s <- get
>     put $! f s

Or try Control.Monad.State.Strict.
From reiner.pope at gmail.com  Sat Sep 20 09:34:01 2008
From: reiner.pope at gmail.com (Reiner Pope)
Date: Sat Sep 20 09:37:23 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
References: 
Message-ID: 

Anatoly Yakovenko  gmail.com> writes:

> 
> I dont remember where i saw it, but i think someone had an example of
> a list whose type is the maximum element in the list.  I've been
> trying to reproduce that with GADT's.
> 
> data One = One
> data Two = Two
> data Three = Three
> 
> data MaxList t where
>    Elem1 :: MaxList One
>    Elem2 :: MaxList Two
>    ML1Cons1 :: MaxList One -> MaxList One -> MaxList One
>    ML1Cons2 :: MaxList One -> MaxList Two -> MaxList Two
>    ML2Cons1 :: MaxList Two -> MaxList One -> MaxList Two
>    ML2Cons2 :: MaxList Two -> MaxList Two -> MaxList Two
> 
> a = ML2Cons2 Elem2 $ ML2Cons1 Elem2 $ ML1Cons1 Elem1 $ Elem1
> 
> so one problem is the tedium of defining a cons for each possible
> combination.  The other problem is that i cant define a usefull tail
> that makes any sense.
> 
> mlTail :: MaxList Two -> MaxList t
> mlTail (ML2Cons2 a b) = b
> mlTail (ML2Cons1 a b) = b
> 
> this one doesn't work, and probably because there is nothing that i
> could do with the return value.

Your problem in this example is that the t in "MaxList t" is universally
quantified when it needs to be existentially quantified. The following
definition encodes the existential quantification as a rank-2 type:

mlTail :: MaxList n -> (forall t. MaxList t -> a) -> a
mlTail (ML1Cons1 h t) f = f t
mlTail (ML1Cons2 h t) f = f t
mlTail (ML2Cons1 h t) f = f t
mlTail (ML2Cons2 h t) f = f t

It works with the rest of your code unmodified.

> 
> mlTail :: MaxList Two -> MaxList Two
> mlTail (ML2Cons2 a b) = b
> mlTail (ML2Cons1 a b) = b  --wont compile because b is a MaxList One
> 
> will only work for lists that only contain Two's, which is not what i
> want either.  So is this somehow possible?

This example here suggests that you are happy merely with a (not necessarily
tight) upper bound on the list elements. The following code solves your problem
in this case, using only type unification and not fundeps or TFs:

data Nat a where
    Z :: Nat a
    S :: Nat a -> Nat (S a)

data Z
data S a

n00 = Z
n01 = S n00
n02 = S n01
n03 = S n02
n04 = S n03

data MaxList t where
   Nil :: MaxList a
   Cons :: Nat a -> MaxList a -> MaxList a

a = Cons n02 $ Cons n02 $ Cons n01 $ Nil
--- ":t a" gives "forall a. MaxList (S (S a))" which tells you exactly 
--- what you want: elements are at least 2.

mlTail :: forall t. MaxList t -> MaxList t
mlTail (Cons h t) = t
--- unfortunately, you lose information here if the first
--- element is larger than the rest.

Reiner

From byorgey at seas.upenn.edu  Sat Sep 20 11:25:54 2008
From: byorgey at seas.upenn.edu (Brent Yorgey)
Date: Sat Sep 20 11:23:11 2008
Subject: [Haskell-cafe] Haskell Weekly News: Issue 86 - September 20, 2008
Message-ID: <20080920152554.GA2459@seas.upenn.edu>

---------------------------------------------------------------------------
Haskell Weekly News
http://sequence.complete.org/hwn/20080920
Issue 86 - September 20, 2008
---------------------------------------------------------------------------

   Welcome to issue 86 of HWN, a newsletter covering developments in the
   [1]Haskell community.

   Lots of NEW stuff this week! A new generics library, new versions of
   Pandoc and darcs, a new website for xmonad, a new GADT/type family
   inference engine for GHC, a Haskell binding for Qt, and some new,
   astonishingly elegant ideas from Oleg. Also, here's hoping that
   everyone has a lot of fun at ICFP!

Announcements

   GHC version control. Simon Peyton-Jones [2]sent out a revised proposal
   for GHC version control.

   darcs 2.0.3pre1. Eric Kow [3]announced the first pre-release of
   [4]darcs 2.0.3, featuring a few major bug fixes and a handful of
   interesting features.

   EMGM. Sean Leather [5]announced a release of [6]Extensible and Modular
   Generics for the Masses (EMGM), a library for generic programming in
   Haskell using type classes.

   Pandoc 1.0.0.1. John MacFarlane [7]announced the release of [8]pandoc
   1.0.0.1, the swiss army knife of text markup formats.

   Iteratee-based IO. oleg [9]described a [10]safe, declarative approach
   to input processing which will be the subject of a talk at DEFUN08 on
   September 27.

   MetaHDBC paper. Mads Lindstroem [11]announced a [12]draft version of a
   paper about the [13]MetaHDBC library, which uses Template Haskell to do
   type-safe database access. Comments are welcomed, especially about the
   overall quality of the paper, whether it can be called scientific, and
   anything Mads could do to improve the paper.

   qtHaskell 1.1.2. David Harley [14]announced a second preview release of
   [15]qtHaskell, a set of Haskell bindings for Trolltech's Qt.

Discussion

   Library design question. Andre Nathan [16]asked for advice on designing
   a simple graph library. The resulting discussion included an analysis
   of using the State monad versus a more functional approach.

   A round of golf. Creighton Hogg [17]learns about laziness by [18]making
   grown men cry.

   XML (HXML) parsing :: GHC 6.8.3 space leak from 2000. Lev Walkin
   [19]discovers a nice example of an obscure class of space leaks while
   writing some XML-processing code, prompting an in-depth analysis by
   Simon Marlow.

   Proofs and commercial code. Daryoush Mehrtash [20]asked about automated
   proof tools and techniques, and their uses in the real world.

Blog noise

   [21]Haskell news from the [22]blogosphere.
     * Creighton Hogg: [23]Haskell Cafe or: How I learned to stop worrying
       & love laziness.
     * Douglas M. Auclair (geophf): [24]Animal as RDR, part II. Doug
       continues his posts on RDR expert systems.
     * Ivan Lazar Miljenovic: [25]Getting Real World Haskell Down Under.
     * Douglas M. Auclair (geophf): [26]Animal: an RDR implementation
       study. Doug describes "ripple-down rules" expert systems, and
       illustrates the types needed to encode one in Haskell.
     * Mark Jason Dominus: [27]data Mu f = In (f (Mu f)). Mark writes
       about fixpoints of type constructors.
     * John Goerzen (CosmicRay): [28]Switched from KDE to xmonad. John has
       taken the plunge to xmonad and seems to like it so far!
     * Eric Kow (kowey): [29]darcs weekly news #4. Pre-release of darcs
       2.0.3; darcs hacking sprint next month; code.haskell.org upgrades
       to darcs 2; and other news.
     * Mads Lindstroem: [30]MetaHDBC paper (draft). Mads's first paper
       ever, on using Template Haskell for type-safe database access.
       Comments welcome!
     * Braden Shepherdson: [31]xmonad-light 0.8 Released.
     * Manuel M T Chakravarty: [32]GHC HEAD just got a new inference
       engine for GADTs and type families..
     * Magnus Therning: [33]Haskell and Time. Magnus describes the
       solution to a problem with Data.Time.
     * Dan Piponi (sigfpe): [34]Two Papers and a Presentation.
     * Xmonad: [35]New xmonad website launched. xmonad has a shiny new
       website!

Quotes of the Week

     * Botje: GHC 11 will have shootout entries as primitives.
     * wjt: oh, i see what you're doing. ...no, i don't. *splode*
     * Benjamin Pierce: [on existential types] I have a term, and it has a
       type. So there.
     * bos: come on, real programmers use "(((,) <$>) .) . (<*>)"
     * quicksilver: #haskell : Sometimes we answer your question,
       sometimes we lay hideous traps which will devour your soul. It's a
       risk you take.
     * harrison: [on computing 1000000!] it is the same as factorial
       999999 * 1000000, big deal

About the Haskell Weekly News

   New editions are posted to [36]the Haskell mailing list as well as to
   [37]the Haskell Sequence and [38]Planet Haskell. [39]RSS is also
   available, and headlines appear on [40]haskell.org.

   To help create new editions of this newsletter, please see the
   information on [41]how to contribute. Send stories to byorgey at cis
   dot upenn dot edu. The darcs repository is available at darcs get
   [42]http://code.haskell.org/~byorgey/code/hwn/ .

References

   1. http://haskell.org/
   2. http://www.haskell.org//pipermail/libraries/2008-September/010661.html
   3. http://www.haskell.org//pipermail/haskell-cafe/2008-September/047664.html
   4. http://www.darcs.net/darcs-2.0.3pre1.tar.gz
   5. http://www.haskell.org//pipermail/haskell-cafe/2008-September/047751.html
   6. http://www.cs.uu.nl/wiki/GenericProgramming/EMGM
   7. http://www.haskell.org//pipermail/haskell-cafe/2008-September/047437.html
   8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pandoc
   9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44828
  10. http://okmij.org/ftp/Haskell/Iteratee/
  11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/44713
  12. http://lindstroem.files.wordpress.com/2008/09/metahdbc.pdf
  13. http://www.haskell.org/haskellwiki/MetaHDBC
  14. http://article.gmane.org/gmane.comp.lang.haskell.general/16425
  15. http://qthaskell.berlios.de/
  16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44733
  17. http://abstractabsurd.blogspot.com/2008/09/haskell-cafe-or-how-i-learned-to-stop.html
  18. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44724
  19. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/44708
  20. http://www.haskell.org//pipermail/haskell-cafe/2008-September/047440.html
  21. http://planet.haskell.org/
  22. http://haskell.org/haskellwiki/Blog_articles
  23. http://abstractabsurd.blogspot.com/2008/09/haskell-cafe-or-how-i-learned-to-stop.html
  24. http://logicaltypes.blogspot.com/2008/09/animal-as-rdr-part-ii.html
  25. http://ivanmiljenovic.wordpress.com/2008/09/19/getting-real-world-haskell-down-under/
  26. http://logicaltypes.blogspot.com/2008/09/animal-rdr-implementation-study.html
  27. http://blog.plover.com/prog/springschool95-2.html
  28. http://changelog.complete.org/posts/756-Switched-from-KDE-to-xmonad.html
  29. http://koweycode.blogspot.com/2008/09/darcs-weekly-news-4.html
  30. http://lindstroem.wordpress.com/2008/09/18/metahdbc-paper-draft/
  31. http://braincrater.wordpress.com/2008/09/17/xmonad-light-08-released/
  32. http://justtesting.org/post/50500880
  33. http://therning.org/magnus/archives/389
  34. http://sigfpe.blogspot.com/2008/09/two-papers-and-presentation.html
  35. http://xmonad.wordpress.com/2008/09/14/new-xmonad-website-launched/
  36. http://www.haskell.org/mailman/listinfo/haskell
  37. http://sequence.complete.org/
  38. http://planet.haskell.org/
  39. http://sequence.complete.org/node/feed
  40. http://haskell.org/
  41. http://haskell.org/haskellwiki/HWN
  42. http://code.haskell.org/~byorgey/code/hwn/
From duncan.coutts at worc.ox.ac.uk  Sat Sep 20 11:37:08 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Sep 20 11:32:07 2008
Subject: [Haskell-cafe] OpenSPARC project applicant chosen
Message-ID: <1221925028.5395.674.camel@localhost>

I am very pleased to announce that we have chosen Ben Lippmeier for the
OpenSPARC project. ?Congratulations Ben!

Ben will spend three months hacking on GHC to make it perform well on
the latest multi-core OpenSPARC chips.

I would also like to thank the other people who applied. The reviewers
were very impressed by the number of strong applications.

About the project
-----------------

http://haskell.org/opensparc/

It is a joint project between Sun Microsystems and the Haskell.org
community. Sun has provided the funding for Ben to work on this full
time for three months and has donated a powerful SPARC server for him
and the rest of us to use.

Ben will be working with Roman Leshchinskiy as a mentor and Darryl Gove
as an adviser. ?Roman works on Data Parallel Haskell at UNSW and ?Darryl
is a senior staff engineer in the SPARC compiler team at Sun.

If you want to follow the progress we will be using the existing ghc
development mailing list:
http://www.haskell.org/mailman/listinfo/cvs-ghc

and a corner of the ghc development wiki:
http://hackage.haskell.org/trac/ghc/wiki/OpenSPARC


Duncan
(project coordinator)

From andre at digirati.com.br  Sat Sep 20 11:46:48 2008
From: andre at digirati.com.br (Andre Nathan)
Date: Sat Sep 20 11:45:30 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <200809201456.53293.daniel.is.fischer@web.de>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<1221865360.5955.30.camel@homesick>
	<49a77b7a0809192353g65afb729td0d8f0597d4e40e7@mail.gmail.com>
	<200809201456.53293.daniel.is.fischer@web.de>
Message-ID: <1221925608.5929.5.camel@homesick>

On Sat, 2008-09-20 at 14:56 +0200, Daniel Fischer wrote:
> > modify' f = do
> >     s <- get
> >     put $! f s
> 
> Or try Control.Monad.State.Strict.

Control.Monad.State.Strict did it for me, but the strict modify didn't.
I tried using modify' and also

  randomDouble = do
    g <- get
    let (r, g') = random g
    put $! g'
    return r

instead of

  randomDouble = State random

Any hints on how I could find where else the program is being too lazy?

Thanks,
Andre

From argaldo.haskell at gmail.com  Sat Sep 20 12:03:25 2008
From: argaldo.haskell at gmail.com (Alberto R. Galdo)
Date: Sat Sep 20 12:00:41 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: 
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
	
	
Message-ID: <51562ec30809200903l4aa285ceg930859cb63397993@mail.gmail.com>

Hi,

   I finally got hugs to compile for the iPhone 2.x firmware (
pwnaged,obviously ).

   It was a matter of using the gcc compiler version distributed by apple in
their iPhone SDK ( wich generates ARM code and suitable for cross-compiling
C code in a mac ), autoconf 'configure' script tweaking and some system
variables hacking here and there.

   So, now you ( and I ), people will be able to run your Haskell code
directly on the iPhone using hugs ( hoping not to be the only one... ;-))

   I'm in the process of submitting the package to one of those "public"
repositories of iphone apps... you'll have notices soon.

   If someone can resist, and like to have cydia compatible packages, just
drop me a note and I'll send them to you by mail.

Greets,

Alberto

On Mon, Sep 15, 2008 at 6:01 PM, Miguel Mitrofanov wrote:

> My iPhone (iPod Touch, actually) have 1.1.4 firmware, so there isn't any
> code signing involved. I've just "configure"d and "make"d.
>
>
> On 15 Sep 2008, at 09:47, Alberto R. Galdo wrote:
>
>  Cool! That's such a proof that it can be done...
>>
>> I had lots of problems trying to cross compile hugs from my mac to arm
>> architecture ( seems that hugs codebase is not capable of cross compiling )
>>
>> And when compiling directly  on the iPhone, first there where problems
>> with code signing, now with the configure script and C preprocessor sanity
>> check...
>>
>> Any light on the topic from your experience?
>>
>> On 15/09/2008, at 7:24, Miguel Mitrofanov  wrote:
>>
>>  Did that.
>>> http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html
>>>
>>> On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:
>>>
>>>  Hi, is there any chance of having hugs  compile for the iPhone?
>>>>
>>>> Cross-compiling? Compiling directly on the iPhone?
>>>>
>>>> Greets,
>>>> Alberto
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe@haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/3e686b67/attachment.htm
From daniel.is.fischer at web.de  Sat Sep 20 12:17:09 2008
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Sat Sep 20 12:12:20 2008
Subject: [Haskell-cafe] Re: Library design question
In-Reply-To: <1221925608.5929.5.camel@homesick>
References: <1221763419.29666.50.camel@andre.mz.digirati.com.br>
	<200809201456.53293.daniel.is.fischer@web.de>
	<1221925608.5929.5.camel@homesick>
Message-ID: <200809201817.09307.daniel.is.fischer@web.de>

Am Samstag, 20. September 2008 17:46 schrieb Andre Nathan:
> On Sat, 2008-09-20 at 14:56 +0200, Daniel Fischer wrote:
> > > modify' f = do
> > >     s <- get
> > >     put $! f s
> >
> > Or try Control.Monad.State.Strict.
>
> Control.Monad.State.Strict did it for me, but the strict modify didn't.
> I tried using modify' and also
>
>   randomDouble = do
>     g <- get
>     let (r, g') = random g
>     put $! g'
>     return r
>
> instead of
>
>   randomDouble = State random
>
> Any hints on how I could find where else the program is being too lazy?
>

Profiling. Find out where your programme spends its time and what uses the 
memory. Add lots of {-# SCC #-} pragmas to get a more detailed picture.

> Thanks,
> Andre

From nfjinjing at gmail.com  Sat Sep 20 12:39:00 2008
From: nfjinjing at gmail.com (Jinjing Wang)
Date: Sat Sep 20 12:36:17 2008
Subject: [Haskell-cafe] [ANN] panda blog engine
Message-ID: <81ea7d400809200939u18d0d788w924d231b43b7a14c@mail.gmail.com>

For some time, I wanted a blog engine that I can

* use plain text
* never lose my data
* configurable at ease
* write in any format I want
* never care about database schema
* them-able without caring about programming logic


panda doesn't do all of it, and is worse at these:

* no web interface, except for comments
* requires a virtual host, or at least be able to start a lighttpd instance
* need to : troubleshoot fcgi processes ( kill them ); use SCM to
manage resources; don't hate OOP (for hacking, sorry about that)

those being said,

* demo: http://jinjing.blog.easymic.com
* code: http://github.com/nfjinjing/panda/tree/master

Cheers,

- jinjing
From donnie at darthik.com  Sat Sep 20 12:57:16 2008
From: donnie at darthik.com (Donnie Jones)
Date: Sat Sep 20 12:54:32 2008
Subject: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World'
	Program.
In-Reply-To: 
References: 
	
Message-ID: 

Hello Brandon and Haskell-cafe,

(Sorry for the delayed reply...)
These seem to be the relevant lines from "configure" of OpenGL package.

checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking OpenGL/gl.h usability... no
checking OpenGL/gl.h presence... no
checking for OpenGL/gl.h... no
checking GL/glu.h usability... yes
checking GL/glu.h presence... yes
checking for GL/glu.h... yes
checking OpenGL/glu.h usability... no
checking OpenGL/glu.h presence... no
checking for OpenGL/glu.h... no

That looks like to me that the gl.h and glu.h header files were found and
are usable (in some cases).  I am able to build and install OpenGL and GLUT
packages for Haskell, but many errors occur as seen below during linking.  I
still can't seem to figure out what is causing these linker errors...
Any other ideas?  :/

Thank you.
__
Donnie

On Fri, Sep 12, 2008 at 12:48 AM, Brandon S. Allbery KF8NH <
allbery@ece.cmu.edu> wrote:

> On 2008 Sep 12, at 0:24, Donnie Jones wrote:
>
> I am trying to test do some OpenGL / GLUT programming in Haskell, but I had
> linker issues testing the 'Hello World' OpenGL Haskell program.  I believe
> the linker issues were caused because the Haskell GLUT package couldn't find
> the GLUT C libraries that were installed with Debian packages.  I have
> tested that my OpenGL install does work with
>
> (...)
>
> checking for GLUT library... no
>
>
> You need to check config.log from the Haskell GLUT build to see why it
> couldn't find (or possibly couldn't link with) the GLUT library.
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
> electrical and computer engineering, carnegie mellon university    KF8NH
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/d55411f0/attachment.htm
From allbery at ece.cmu.edu  Sat Sep 20 13:02:28 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sat Sep 20 12:59:47 2008
Subject: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World'
	Program.
In-Reply-To: 
References: 
	
	
Message-ID: 

On 2008 Sep 20, at 12:57, Donnie Jones wrote:
> checking GL/gl.h usability... yes
> checking GL/gl.h presence... yes
> checking for GL/gl.h... yes
> checking OpenGL/gl.h usability... no
> checking OpenGL/gl.h presence... no
> checking for OpenGL/gl.h... no
> checking GL/glu.h usability... yes
> checking GL/glu.h presence... yes
> checking for GL/glu.h... yes
> checking OpenGL/glu.h usability... no
> checking OpenGL/glu.h presence... no
> checking for OpenGL/glu.h... no
>
> That looks like to me that the gl.h and glu.h header files were  
> found and are usable (in some cases).  I am able to build

Yes, you have the header.  But it says nothing about whether -lGLU was  
found, and that's where your problems are.
Also, that's configure output, not config.log output (which has a  
transcript of the tests, not just the summary).

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/ede9b472/attachment.htm
From aeyakovenko at gmail.com  Sat Sep 20 13:12:51 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Sat Sep 20 13:10:07 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
Message-ID: 

>> data One = One
>> data Two = Two
>> data Three = Three
>>
>> data MaxList t where
>>    Elem1 :: MaxList One
>>    Elem2 :: MaxList Two
>>    ML1Cons1 :: MaxList One -> MaxList One -> MaxList One
>>    ML1Cons2 :: MaxList One -> MaxList Two -> MaxList Two
>>    ML2Cons1 :: MaxList Two -> MaxList One -> MaxList Two
>>    ML2Cons2 :: MaxList Two -> MaxList Two -> MaxList Two
>>
>> a = ML2Cons2 Elem2 $ ML2Cons1 Elem2 $ ML1Cons1 Elem1 $ Elem1
>>
>> so one problem is the tedium of defining a cons for each possible
>> combination.  The other problem is that i cant define a usefull tail
>> that makes any sense.
>>
>> mlTail :: MaxList Two -> MaxList t
>> mlTail (ML2Cons2 a b) = b
>> mlTail (ML2Cons1 a b) = b
>>
>> this one doesn't work, and probably because there is nothing that i
>> could do with the return value.
>
> Your problem in this example is that the t in "MaxList t" is universally
> quantified when it needs to be existentially quantified. The following
> definition encodes the existential quantification as a rank-2 type:
>
> mlTail :: MaxList n -> (forall t. MaxList t -> a) -> a
> mlTail (ML1Cons1 h t) f = f t
> mlTail (ML1Cons2 h t) f = f t
> mlTail (ML2Cons1 h t) f = f t
> mlTail (ML2Cons2 h t) f = f t
>
> It works with the rest of your code unmodified.

how do i define (forall t. MaxList t -> a)?  It seems like i just
pushed the problem somewhere else.

>> mlTail :: MaxList Two -> MaxList Two
>> mlTail (ML2Cons2 a b) = b
>> mlTail (ML2Cons1 a b) = b  --wont compile because b is a MaxList One
>>
>> will only work for lists that only contain Two's, which is not what i
>> want either.  So is this somehow possible?
>
> This example here suggests that you are happy merely with a (not necessarily
> tight) upper bound on the list elements. The following code solves your problem
> in this case, using only type unification and not fundeps or TFs:
>
> data Nat a where
>    Z :: Nat a
>    S :: Nat a -> Nat (S a)
>
> data Z
> data S a
>
> n00 = Z
> n01 = S n00
> n02 = S n01
> n03 = S n02
> n04 = S n03
>
> data MaxList t where
>   Nil :: MaxList a
>   Cons :: Nat a -> MaxList a -> MaxList a
>
> a = Cons n02 $ Cons n02 $ Cons n01 $ Nil
> --- ":t a" gives "forall a. MaxList (S (S a))" which tells you exactly
> --- what you want: elements are at least 2.
>
> mlTail :: forall t. MaxList t -> MaxList t
> mlTail (Cons h t) = t
> --- unfortunately, you lose information here if the first
> --- element is larger than the rest.

Thanks, that's really cool.  Is there a way to keep  a tight upper
bound on the list using this method?
From donnie at darthik.com  Sat Sep 20 13:13:43 2008
From: donnie at darthik.com (Donnie Jones)
Date: Sat Sep 20 13:10:59 2008
Subject: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World'
	Program.
In-Reply-To: 
References: 
	
	
	
Message-ID: 

Hello Brandon,

On Sat, Sep 20, 2008 at 1:02 PM, Brandon S. Allbery KF8NH <
allbery@ece.cmu.edu> wrote:

> On 2008 Sep 20, at 12:57, Donnie Jones wrote:
>
> checking GL/gl.h usability... yes
> checking GL/gl.h presence... yes
> checking for GL/gl.h... yes
> checking OpenGL/gl.h usability... no
> checking OpenGL/gl.h presence... no
> checking for OpenGL/gl.h... no
> checking GL/glu.h usability... yes
> checking GL/glu.h presence... yes
> checking for GL/glu.h... yes
> checking OpenGL/glu.h usability... no
> checking OpenGL/glu.h presence... no
> checking for OpenGL/glu.h... no
>
> That looks like to me that the gl.h and glu.h header files were found and
> are usable (in some cases).  I am able to build
>
>
> Yes, you have the header.  But it says nothing about whether -lGLU was
> found, and that's where your problems are.
> Also, that's configure output, not config.log output (which has a
> transcript of the tests, not just the summary).
>
>
### Relevant lines that include "-lGL" or "-lGLU" in config.log ###
configure:4634: checking for GL library
configure:4670: gcc -o conftest -g -O2    conftest.c -lGL -lm   >&5
configure:4676: $? = 0
configure:4696: result: -lGL -lm
configure:4773: checking for GLU library
configure:4809: gcc -o conftest -g -O2    conftest.c -lglu32 -lGL -lm   >&5
/usr/bin/ld: cannot find -lglu32
collect2: ld returned 1 exit status
configure:4815: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "Haskell OpenGL package"
| #define PACKAGE_TARNAME "OpenGL"
| #define PACKAGE_VERSION "2.2.1"
| #define PACKAGE_STRING "Haskell OpenGL package 2.2.1"
| #define PACKAGE_BUGREPORT "sven.panne@aedion.de"
| /* end confdefs.h.  */
| #include 
| int
| main ()
| {
| gluNewQuadric()
|   ;
|   return 0;
| }
configure:4809: gcc -o conftest -g -O2    conftest.c -lGLU -lGL -lm   >&5
configure:4815: $? = 0
configure:4835: result: -lGLU -lGL -lm
...
fp_cv_check_GLU_lib='-lGLU -lGL -lm '
fp_cv_check_GL_lib='-lGL -lm '
...
GLU_LIBS=' -lGLU -lGL -lm '
...
GL_LIBS=' -lGL -lm '
...
#define GLU_LIBS "-lGLU" ,"-lGL" ,"-lm"
########################################

It seems like the OpenGL and GLUT libraries are found (after -lglu32 fails,
I am using Debian Linux).  I am not sure what to try now.

Thank you for the help.  :)
__
Donnie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/21a3f945/attachment.htm
From haskell at list.mightyreason.com  Sat Sep 20 14:06:50 2008
From: haskell at list.mightyreason.com (ChrisK)
Date: Sat Sep 20 14:04:20 2008
Subject: [Haskell-cafe] ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready
Message-ID: <48D53BBA.10101@list.mightyreason.com>

Hello one and all,

Amid much rejoicing, my Haskell version of protocol-buffer is now
released (version 0.2.9).

What is this for?  What does it do?  Why?

   Shorter answer: It generates Haskell data types that can be converted back 
and forth to lazy ByteStrings that interoperate with Google's generated code in 
C++/Java/python.

   It is a pure Haskell re-implementation of the Google code at
http://code.Google.com/apis/protocolbuffers/docs/overview.html
   which is "...a language-neutral, platform-neutral, extensible way of 
serializing structured data for use in communications protocols, data storage, 
and more."
   Google's project produces C++, Java, and Python code.  This one produces 
Haskell code.

The release tarball (with 3 Haskell packages inside, see README in source) is at
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers

The darcs repository has moved to 
http://darcs.haskell.org/packages/protocol-buffers2/

You will also need a recent ghc compiler, the "binary" package and the
"utf8-string" package from hackage.haskell.org (same site as mentioned
above).

The source compiles to 3 things:
   1) the package "protocol-buffers" with the library API
   2) the package "protocol-buffers-descriptor" with the
descriptor.proto code
   3) The 'hprotoc' executable which is a command line program similar
to 'protoc'.

The "examples" sub-directory in the code has the Haskell version of
the "addressbook.proto" example and is compatible with Google's
similar example code.

The code generated from unittest.proto (and unittest_import.proto)
includes messages TestAllTypes and TestAllExtensions which have been
extensively tested by QuickCheck to ensure they can be wire encoded
and decoded (see the "tests" sub-directory in the code).

The user API, as exported by Text.ProtocolBuffers, allows for
converting messages back and forth to the lazy ByteString type.  And
such messages can be merged, and the defaults accessed via the
MessageAPI type class.

The messages in Haskell as just regular data types and are thus
immutable.  Required types are simple record fields, optional types
are Maybe, and repeated types are Seq (from Data.Sequence).

Extensions are supported via Key data that allows access to the
extension fields.  Extensible messages contain an opaque ext'field
entry of type ExtField that contains the map data structure to contain
the extension field values.

The User API allows for serializing messages as the usual series of
fields.  It also provides for a length prefix to be written to create
delimited messages.  It also provides to write a wire tag with any
field number before the length and message data.  This last form looks
like a field on the wire, and there is a special api call to read back
just the one message and its field number.  This last API is similar
to the one that is part of the C# API.

No benchmarks have been run yet.  Any suggestions?

Unsupported for the moment is loading and storing "unknown" fields.
It can be added sooner if someone has a use for this.

Unsupported indefinitely is code generation for Services and Methods.
I have yet to look into how this is presented in the other languages.

The API to read a single message field, as mentioned above, might be
extended to read any type instead of just messages.

optional clever_quote {
 Perl: "Easy things are easy, hard things are possible"
 Haskell: "Hard things are easy, the impossible just
happened"
}

Cheers!

   Chris Kuklewicz

From dave at zednenem.com  Sat Sep 20 15:40:08 2008
From: dave at zednenem.com (David Menendez)
Date: Sat Sep 20 15:37:24 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
	
Message-ID: <49a77b7a0809201240o7ef3743fk94eb26563427c05b@mail.gmail.com>

On Sat, Sep 20, 2008 at 1:12 PM, Anatoly Yakovenko
 wrote:
>
>> Your problem in this example is that the t in "MaxList t" is universally
>> quantified when it needs to be existentially quantified. The following
>> definition encodes the existential quantification as a rank-2 type:
>>
>> mlTail :: MaxList n -> (forall t. MaxList t -> a) -> a
>> mlTail (ML1Cons1 h t) f = f t
>> mlTail (ML1Cons2 h t) f = f t
>> mlTail (ML2Cons1 h t) f = f t
>> mlTail (ML2Cons2 h t) f = f t
>>
>> It works with the rest of your code unmodified.
>
> how do i define (forall t. MaxList t -> a)?  It seems like i just
> pushed the problem somewhere else.

Since MaxList is a GADT, you can always look inside to specialize the
parameter. In fact, with this particular definition, you just have to
look at the outermost constructor.

findMax :: MaxList n -> Either (MaxList One) (MaxList Two)
findMax l@Elem1 = Left l
findMax l@Elem2 = Right l
findMax l@(ML1Cons1 _ _) = Left l
findMax l@(ML1Cons2 _ _) = Right l
findMax l@(ML2Cons1 _ _) = Right l
findMax l@(ML2Cons2 _ _) = Right l

>> This example here suggests that you are happy merely with a (not necessarily
>> tight) upper bound on the list elements. The following code solves your problem
>> in this case, using only type unification and not fundeps or TFs:
[...]
> Thanks, that's really cool.  Is there a way to keep  a tight upper
> bound on the list using this method?

One way is to use a witnesses to prove that the head of the list is
either the maximum element, or less than (or equal) to the maximum
element.


data MaxList n where
    Nil  :: MaxList Z
    ConsMax :: LE n a -> Nat a -> MaxList n -> MaxList a
    ConsLE  :: LE a n -> Nat a -> MaxList n -> MaxList n

cons :: Nat a -> MaxList b -> (forall n. MaxList n -> ans) -> ans
cons a as f = case cmp a (maximum as) of
    Left le -> f (ConsLE le a as)
    Right le -> f (ConsMax le a as)

mlTail :: MaxList a -> (forall b. MaxList b -> ans) -> ans
mlTail (ConsMax _ _ as) f = f as
mlTail (ConsLE _ _ as)  f = f as

There are at least three ways to define LE, which have different
trade-offs in terms of usability and space efficiency. One way is to
encode both numbers,

data LE a b where
    ZLE :: Nat b -> LE Z b
    SLE :: LE a b -> LE (S a) (S b)

cmp :: Nat a -> Nat b -> Either (LE a b) (LE b a)
cmp Z b = Left (ZLE b)
cmp a Z = Right (ZLE a)
cmp (S a) (S b) = either (Left . SLE) (Right . SLE) (cmp a b)

maximum :: MaxList n -> Nat n
maximum Nil = Z
maximum (ConsMax _ n _) = n
maximum (ConsLE le _ _) = greater le

greater :: LE a b -> Nat b
greater (ZLE b) = b
greater (SLE l) = S (greater l)

lesser :: LE a b -> Nat a
lesser (ZLE b) = Z
lesser (SLE l) = S (lesser l)


Alternatively, you can encode the difference between a and b,

data LE a b where
    Eq :: LE a a
    Lt :: LE a b -> LE a (S b)

cmp :: Nat a -> Nat b -> Either (LE a b) (LE b a)
cmp Z Z     = Left Eq
cmp Z (S b) = Left (Lt (zle b))
cmp (S a) Z = Right (Lt (zle a))
cmp (S a) (S b) = either (Left . sle) (Right . sle) (cmp a b)

zle :: Nat a -> LE Z a
zle Z = Eq
zle (S n) = Lt (zle n)

sle :: LE a b -> LE (S a) (S b)
sle Eq = Eq
sle (Lt l) = Lt (sle l)
-- Since only the types change, it should be safe to
-- replace sle with unsafeCoerce. In that case, the
-- final equation for cmp can just be
--    cmp (S a) (S b) = unsafeCoerce (cmp a b)

maximum :: MaxList n -> Nat n
maximum Nil = Z
maximum (ConsMax _ n _) = n
maximum (ConsLE le a _) = greater le a

greater :: LE a b -> Nat a -> Nat b
greater Eq     n = n
greater (Lt l) n = S (greater l n)

lesser :: LE a b -> Nat b -> Nat a
lesser Eq     n     = n
lesser (Lt l) (S n) = lesser l n

-- 
Dave Menendez 

From newsham at lava.net  Sat Sep 20 15:52:35 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat Sep 20 15:50:04 2008
Subject: [Haskell-cafe] haskell shootout -- mandelbrot 
Message-ID: 

Since this one's trivially parallizable, I took a crack at the
mandelbrot test case.  It was fairly easy to thread it on a
per-line basis in Haskell without changing the original too much.
It might be more efficient to break the work into larger chunks,
but that would require some slightly more complicated changes so
I didn't try that yet.

Anyway, the code and the results are here.  See README for details:
    http://www.thenewsh.com/~newsham/shootout/

Tim Newsham
http://www.thenewsh.com/~newsham/
From RafaelGCPP.Linux at gmail.com  Sat Sep 20 16:08:13 2008
From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto)
Date: Sat Sep 20 16:05:29 2008
Subject: [Haskell-cafe] Re: Ropes
In-Reply-To: <351ff25e0809201245t1a67ad3cxa6df99f4fe50598f@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
	<2f9b2d30809191915m2cdd8963yded4fb1c14c40c43@mail.gmail.com>
	<351ff25e0809200354m6dc90c0apc723c26a1e4e53f@mail.gmail.com>
	
	<351ff25e0809201245t1a67ad3cxa6df99f4fe50598f@mail.gmail.com>
Message-ID: <351ff25e0809201308g6e20ee22i85a67f09913effc9@mail.gmail.com>

I have been told that you could pretty much literally implement the
> algorithms
> from the problem specification with  Seq  from  Data.Sequence  and achieve
> acceptable speed (IIRC ~ one minute for generating a whole picture).
>

Yes, it is straightforward to implement the algorithm when using sequences.



>
> Are you sure that there is no unintentional bug in your implementation that
> slows things down?
>

The test cases on the problem definition all worked, but they touch very
little of the code.

I added some "trace" calls, but could not see any trouble. I also did some
runs "by hand" and it  seemed ok.

If only G?del was wrong... :-)


-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.



-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/90d4ba02/attachment.htm
From dons at galois.com  Sat Sep 20 16:26:48 2008
From: dons at galois.com (Don Stewart)
Date: Sat Sep 20 16:24:00 2008
Subject: [Haskell-cafe] haskell shootout -- mandelbrot
In-Reply-To: 
References: 
Message-ID: <20080920202648.GD18629@scytale.galois.com>

newsham:
> Since this one's trivially parallizable, I took a crack at the
> mandelbrot test case.  It was fairly easy to thread it on a
> per-line basis in Haskell without changing the original too much.
> It might be more efficient to break the work into larger chunks,
> but that would require some slightly more complicated changes so
> I didn't try that yet.
> 
> Anyway, the code and the results are here.  See README for details:
>    http://www.thenewsh.com/~newsham/shootout/

a) have you submitted it to the shootout.
b) is it faster
c) can you put it on the parallel shootout wiki,
    http://haskell.org/haskellwiki/Shootout/Parallel

BTW, I just added parallel spectral-norm,
    http://haskell.org/haskellwiki/Shootout/Parallel/SpectralNorm
From newsham at lava.net  Sat Sep 20 16:48:00 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat Sep 20 16:45:15 2008
Subject: [Haskell-cafe] haskell shootout -- mandelbrot
In-Reply-To: <20080920202648.GD18629@scytale.galois.com>
References: 
	<20080920202648.GD18629@scytale.galois.com>
Message-ID: 

> a) have you submitted it to the shootout.

no

> b) is it faster

yes

> c) can you put it on the parallel shootout wiki,
>    http://haskell.org/haskellwiki/Shootout/Parallel

http://haskell.org/haskellwiki/Shootout/Parallel/Mandelbrot

Tim Newsham
http://www.thenewsh.com/~newsham/
From roma at ro-che.info  Sat Sep 20 16:50:04 2008
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat Sep 20 16:47:49 2008
Subject: [Haskell-cafe] OpenSPARC project applicant chosen
In-Reply-To: <1221925028.5395.674.camel@localhost>
References: <1221925028.5395.674.camel@localhost>
Message-ID: <20080920205004.GA5068@flit>

* Duncan Coutts  [2008-09-20 16:37:08+0100]
> If you want to follow the progress we will be using the existing ghc
> development mailing list:
> http://www.haskell.org/mailman/listinfo/cvs-ghc
> 
> and a corner of the ghc development wiki:
> http://hackage.haskell.org/trac/ghc/wiki/OpenSPARC

I hope Brent also will be publishing the news of the project in HWN.

-- 
Roman I. Cheplyaka :: http://ro-che.info/
kzm: My program contains a bug. How ungrateful, after all I've done for it.
From dons at galois.com  Sat Sep 20 16:57:41 2008
From: dons at galois.com (Don Stewart)
Date: Sat Sep 20 16:54:48 2008
Subject: [Haskell-cafe] haskell shootout -- mandelbrot
In-Reply-To: 
References: 
	<20080920202648.GD18629@scytale.galois.com>
	
Message-ID: <20080920205741.GE18629@scytale.galois.com>

newsham:
> >a) have you submitted it to the shootout.
> 
> no
> 
> >b) is it faster
> 
> yes
> 
> >c) can you put it on the parallel shootout wiki,
> >   http://haskell.org/haskellwiki/Shootout/Parallel
> 
> http://haskell.org/haskellwiki/Shootout/Parallel/Mandelbrot

Nice, on quad core, the old entry,

    $ time ./Old 6400 > /dev/null                                    
    ./Old 6400 > /dev/null  6.99s user 0.01s system 99% cpu 7.015 total

And Tim's parallel entry,

    $ time ./A 6400 +RTS -N6 > /dev/null
    ./A 6400 +RTS -N6 > /dev/null  6.89s user 0.03s system 346% cpu 1.995 total

Noice!

-- Don

From duncan.coutts at worc.ox.ac.uk  Sat Sep 20 18:03:41 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sat Sep 20 17:58:37 2008
Subject: [Haskell-cafe] OpenSPARC project applicant chosen
In-Reply-To: <20080920205004.GA5068@flit>
References: <1221925028.5395.674.camel@localhost> <20080920205004.GA5068@flit>
Message-ID: <1221948221.5395.683.camel@localhost>

On Sat, 2008-09-20 at 23:50 +0300, Roman Cheplyaka wrote:
> * Duncan Coutts  [2008-09-20 16:37:08+0100]
> > If you want to follow the progress we will be using the existing ghc
> > development mailing list:
> > http://www.haskell.org/mailman/listinfo/cvs-ghc
> > 
> > and a corner of the ghc development wiki:
> > http://hackage.haskell.org/trac/ghc/wiki/OpenSPARC
> 
> I hope Brent also will be publishing the news of the project in HWN.

I'm also hoping Ben might post updates to a blog, but I've not asked him
yet.

Duncan

From gwern0 at gmail.com  Sat Sep 20 18:11:57 2008
From: gwern0 at gmail.com (Gwern Branwen)
Date: Sat Sep 20 18:09:57 2008
Subject: [Haskell-cafe] Re: Munging wiki articles with tagsoup
In-Reply-To: <404396ef0809091149o10237ebfhc76cb8d7c57bd634@mail.gmail.com>
References: <20080908053105.GB15405@craft>
	<404396ef0809091149o10237ebfhc76cb8d7c57bd634@mail.gmail.com>
Message-ID: <20080920221157.GD1431@craft>

On 2008.09.09 19:49:49 +0100, Neil Mitchell  scribbled 2.3K characters:
> Hi Gwern,
>
> Sorry for not noticing this sooner, my haskell-cafe@ reading is
> somewhat behind right now!

NP. I'm in no hurry; this TMR thing is an side project of mine, and I still haven't figured out how to get references/pandoc/citeproc-hs to work together, and I want to get them to work before I actually start uploading any converted articles.


> convertToHaskell (TagOpen "pre" atts) = TagOpen "haskell" atts
> convertToHaskell (TagClose "pre") = TagClose "haskell"
> convertToHaskell x = x
>
> Direct pattern matching is much easier and simpler.

That is very nice! Now the whole thing is like 5 lines of actual code. Once again, TagSoup wins.

> The escaping of ' is caused by renderTags, so instead call:
>
> renderTagsOptions (renderOptions{optEscape = (:[])})

Thanks.

> For no escaping of any characters, or more likely do something like <,
> > and & conversions. See the docs:
> http://hackage.haskell.org/packages/archive/tagsoup/0.6/doc/html/Text-HTML-TagSoup-Render.html

Well, I did look at that Haddock page, as well as the others. But honestly, just a bare line like 'renderTagsOptions :: RenderOptions -> [Tag] -> String' doesn't help me - it doesn't tell me that 'that's default behavior, but you can override it thusly'.

> > Am I just barking up the wrong tree and should be writing a simple-minded search-and-replace sed script which replaces 
 with , 
 with ...?
>
> Not necessarily. If you literally just want to replace ""
> with "
" then sed is probably the easy choice. However, its quite
> likely you'll want to make more fixes, and tagsoup gives you the
> flexibility to extend in that direction.
>
> Thanks
>
> Neil

Hm hm. I see; the TagSoup way is more powerful in the long run.

--
gwern
blackjack NAVSVS Koancho Counter Merlin JICS 510 fuses JICC y
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/468ef2e2/attachment.bin
From briqueabraque at yahoo.com  Sat Sep 20 19:14:49 2008
From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=)
Date: Sat Sep 20 19:12:16 2008
Subject: [Haskell-cafe] Language.Haskell and strings
Message-ID: 

Hi,

I'm using Language.Haskell.* and would
like to know if it's possible to
pretty-print big strings like this:

"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

into something like this:

"aaaaaaaa\
\aaaaaaaa\
\aaaaaaaa\
\aaaaaaaa\
\aaaaaaaa\
\aaaaaaaa\
\aaaaaaaa"

to respect the limit on number of
columns. Can you help me? Is it
possible to do that?

Thanks,
Maur?cio

From chris at eidhof.nl  Sat Sep 20 19:43:57 2008
From: chris at eidhof.nl (Chris Eidhof)
Date: Sat Sep 20 19:41:18 2008
Subject: [Haskell-cafe] Updated formlets sample?
In-Reply-To: <48D3898B.5070904@gmx.org>
References: <48D3898B.5070904@gmx.org>
Message-ID: <20898DDF-5BF7-4FA1-8BAF-881D57C57CB8@eidhof.nl>

Hey Martin,

On 19 sep 2008, at 04:14, Martin Huschenbett wrote:

> I found a blog post concerning formlets [1] in the web. Since looks  
> very interesting I tried to compile the sample code with recent  
> versions of HAppS and formlets from hackage. But this didn't work as  
> the API of formlets has changed since this post.
>
> I tried to adopt the code to the new API but I was unable to finish  
> this since there is a new monadic context I don't know to handle in  
> the right way.
>
> So my question is, is there an updated version of this sample code  
> in the web or has anybody tried to adopt it and can send me the  
> results?


Yes, I'm sorry for that. The API is still very immature and due to  
changes, that's also why it hasn't been officially announced yet. I've  
just put an updated example at http://hpaste.org/10568, hope that'll  
work for you. I guess we should build a small homepage / wikipage that  
always has an up-to-date example.

-chris
From donnie at darthik.com  Sat Sep 20 21:47:35 2008
From: donnie at darthik.com (Donnie Jones)
Date: Sat Sep 20 21:44:50 2008
Subject: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World'
	Program.
In-Reply-To: 
References: 
	
	
	
	
Message-ID: 

Hello Clifford,

Thank you for the quick reply.
I was able to get a test C program that draws a triangle with GLUT to work:
gcc -lglut triangle.o -o triangle.exe

However, when building the Haskell GLUT 'Hello World' it uses, -lGLU to link
GLUT, but that does not work; however, from the config.log output configure
seems to think that -lGL should work.  Is there a way I can change the build
to use -lglut?  Maybe with configure I can specify that -lglut is the
correct way to link the GLUT libraries?

Thank you!
__
Donnie

On Sat, Sep 20, 2008 at 3:42 PM, Clifford Beshers <
clifford.beshers@gmail.com> wrote:
It works for me.  I'm running Ubuntu Hardy with some packages built by us at
SeeReason (see debs.seereason.com).

It looks like ghc can't find your glut libraries (not the Haskell wrappers,
but the real GLUT libs). Try 'ghc -v --make ' and look at the linking lines
and see what GHC is specifying (mine shows a -lglut).  Try compiling an
example C program against GLUT and see if that works.

My package list looks like this:
beshers@blue:~/haskell$ dpkg -l \*glut\*
Desired=Unknown/Install/

Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
un  freeglut-dev            (no description available)
ii  freeglut3      2.4.0-6        OpenGL Utility Toolkit
ii  freeglut3-dev  2.4.0-6        OpenGL Utility Toolkit development files
un  glut-doc                (no description available)
un  glutg3                  (no description available)
un  glutg3-dev              (no description available)
ii  libghc6-glut-d 2.1.1.1-2+3see Haskell GLUT binding for GHC
un  libghc6-glut-d          (no description available)
un  libghc6-glut-p          (no description available)
un  libglut                 (no description available)
un  libglut-dev             (no description available)
pn  libglut3                (no description available)
un  libglut3-dev            (no description available)



On Sat, Sep 20, 2008 at 1:13 PM, Donnie Jones  wrote:

> Hello Brandon,
>
> On Sat, Sep 20, 2008 at 1:02 PM, Brandon S. Allbery KF8NH <
> allbery@ece.cmu.edu> wrote:
>
>> On 2008 Sep 20, at 12:57, Donnie Jones wrote:
>>
>> checking GL/gl.h usability... yes
>> checking GL/gl.h presence... yes
>> checking for GL/gl.h... yes
>> checking OpenGL/gl.h usability... no
>> checking OpenGL/gl.h presence... no
>> checking for OpenGL/gl.h... no
>> checking GL/glu.h usability... yes
>> checking GL/glu.h presence... yes
>> checking for GL/glu.h... yes
>> checking OpenGL/glu.h usability... no
>> checking OpenGL/glu.h presence... no
>> checking for OpenGL/glu.h... no
>>
>> That looks like to me that the gl.h and glu.h header files were found and
>> are usable (in some cases).  I am able to build
>>
>>
>> Yes, you have the header.  But it says nothing about whether -lGLU was
>> found, and that's where your problems are.
>> Also, that's configure output, not config.log output (which has a
>> transcript of the tests, not just the summary).
>>
>>
> ### Relevant lines that include "-lGL" or "-lGLU" in config.log ###
> configure:4634: checking for GL library
> configure:4670: gcc -o conftest -g -O2    conftest.c -lGL -lm   >&5
> configure:4676: $? = 0
> configure:4696: result: -lGL -lm
> configure:4773: checking for GLU library
> configure:4809: gcc -o conftest -g -O2    conftest.c -lglu32 -lGL -lm   >&5
> /usr/bin/ld: cannot find -lglu32
> collect2: ld returned 1 exit status
> configure:4815: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME "Haskell OpenGL package"
> | #define PACKAGE_TARNAME "OpenGL"
> | #define PACKAGE_VERSION "2.2.1"
> | #define PACKAGE_STRING "Haskell OpenGL package 2.2.1"
> | #define PACKAGE_BUGREPORT "sven.panne@aedion.de"
> | /* end confdefs.h.  */
> | #include 
> | int
> | main ()
> | {
> | gluNewQuadric()
> |   ;
> |   return 0;
> | }
> configure:4809: gcc -o conftest -g -O2    conftest.c -lGLU -lGL -lm   >&5
> configure:4815: $? = 0
> configure:4835: result: -lGLU -lGL -lm
> ...
> fp_cv_check_GLU_lib='-lGLU -lGL -lm '
> fp_cv_check_GL_lib='-lGL -lm '
> ...
> GLU_LIBS=' -lGLU -lGL -lm '
> ...
> GL_LIBS=' -lGL -lm '
> ...
> #define GLU_LIBS "-lGLU" ,"-lGL" ,"-lm"
> ########################################
>
> It seems like the OpenGL and GLUT libraries are found (after -lglu32 fails,
> I am using Debian Linux).  I am not sure what to try now.
>
> Thank you for the help.  :)
> __
> Donnie
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/dff6f143/attachment.htm
From donnie at darthik.com  Sat Sep 20 22:10:56 2008
From: donnie at darthik.com (Donnie Jones)
Date: Sat Sep 20 22:08:11 2008
Subject: SOLVED. Re: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello
	World' Program.
Message-ID: 

Hello,

ghc -package GLUT -lglut Hello1.hs -o Hello1 --- works!  :)

I'm not sure why I must specify "-package GLUT" and "-lglut" but that
prevents the linker errors.  Also, shouldn't configure correctly figure out
how to link the GLUT libraries?  Can someone explain?

Thank you.
__
Donnie

On Sat, Sep 20, 2008 at 9:47 PM, Donnie Jones  wrote:

> Hello Clifford,
>
> Thank you for the quick reply.
> I was able to get a test C program that draws a triangle with GLUT to work:
> gcc -lglut triangle.o -o triangle.exe
>
> However, when building the Haskell GLUT 'Hello World' it uses, -lGLU to
> link GLUT, but that does not work; however, from the config.log output
> configure seems to think that -lGL should work.  Is there a way I can change
> the build to use -lglut?  Maybe with configure I can specify that -lglut is
> the correct way to link the GLUT libraries?
>
> Thank you!
> __
> Donnie
>
> On Sat, Sep 20, 2008 at 3:42 PM, Clifford Beshers <
> clifford.beshers@gmail.com> wrote:
> It works for me.  I'm running Ubuntu Hardy with some packages built by us
> at SeeReason (see debs.seereason.com).
>
> It looks like ghc can't find your glut libraries (not the Haskell wrappers,
> but the real GLUT libs). Try 'ghc -v --make ' and look at the linking lines
> and see what GHC is specifying (mine shows a -lglut).  Try compiling an
> example C program against GLUT and see if that works.
>
> My package list looks like this:
> beshers@blue:~/haskell$ dpkg -l \*glut\*
> Desired=Unknown/Install/
>
> Remove/Purge/Hold
> |
> Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
> uppercase=bad)
> ||/ Name           Version        Description
>
> +++-==============-==============-============================================
> un  freeglut-dev            (no description available)
> ii  freeglut3      2.4.0-6        OpenGL Utility Toolkit
> ii  freeglut3-dev  2.4.0-6        OpenGL Utility Toolkit development files
> un  glut-doc                (no description available)
> un  glutg3                  (no description available)
> un  glutg3-dev              (no description available)
> ii  libghc6-glut-d 2.1.1.1-2+3see Haskell GLUT binding for GHC
> un  libghc6-glut-d          (no description available)
> un  libghc6-glut-p          (no description available)
> un  libglut                 (no description available)
> un  libglut-dev             (no description available)
> pn  libglut3                (no description available)
> un  libglut3-dev            (no description available)
>
>
>
> On Sat, Sep 20, 2008 at 1:13 PM, Donnie Jones  wrote:
>
>> Hello Brandon,
>>
>> On Sat, Sep 20, 2008 at 1:02 PM, Brandon S. Allbery KF8NH <
>> allbery@ece.cmu.edu> wrote:
>>
>>> On 2008 Sep 20, at 12:57, Donnie Jones wrote:
>>>
>>> checking GL/gl.h usability... yes
>>> checking GL/gl.h presence... yes
>>> checking for GL/gl.h... yes
>>> checking OpenGL/gl.h usability... no
>>> checking OpenGL/gl.h presence... no
>>> checking for OpenGL/gl.h... no
>>> checking GL/glu.h usability... yes
>>> checking GL/glu.h presence... yes
>>> checking for GL/glu.h... yes
>>> checking OpenGL/glu.h usability... no
>>> checking OpenGL/glu.h presence... no
>>> checking for OpenGL/glu.h... no
>>>
>>> That looks like to me that the gl.h and glu.h header files were found and
>>> are usable (in some cases).  I am able to build
>>>
>>>
>>> Yes, you have the header.  But it says nothing about whether -lGLU was
>>> found, and that's where your problems are.
>>> Also, that's configure output, not config.log output (which has a
>>> transcript of the tests, not just the summary).
>>>
>>>
>> ### Relevant lines that include "-lGL" or "-lGLU" in config.log ###
>> configure:4634: checking for GL library
>> configure:4670: gcc -o conftest -g -O2    conftest.c -lGL -lm   >&5
>> configure:4676: $? = 0
>> configure:4696: result: -lGL -lm
>> configure:4773: checking for GLU library
>> configure:4809: gcc -o conftest -g -O2    conftest.c -lglu32 -lGL -lm
>> >&5
>> /usr/bin/ld: cannot find -lglu32
>> collect2: ld returned 1 exit status
>> configure:4815: $? = 1
>> configure: failed program was:
>> | /* confdefs.h.  */
>> | #define PACKAGE_NAME "Haskell OpenGL package"
>> | #define PACKAGE_TARNAME "OpenGL"
>> | #define PACKAGE_VERSION "2.2.1"
>> | #define PACKAGE_STRING "Haskell OpenGL package 2.2.1"
>> | #define PACKAGE_BUGREPORT "sven.panne@aedion.de"
>> | /* end confdefs.h.  */
>> | #include 
>> | int
>> | main ()
>> | {
>> | gluNewQuadric()
>> |   ;
>> |   return 0;
>> | }
>> configure:4809: gcc -o conftest -g -O2    conftest.c -lGLU -lGL -lm   >&5
>> configure:4815: $? = 0
>> configure:4835: result: -lGLU -lGL -lm
>> ...
>> fp_cv_check_GLU_lib='-lGLU -lGL -lm '
>> fp_cv_check_GL_lib='-lGL -lm '
>> ...
>> GLU_LIBS=' -lGLU -lGL -lm '
>> ...
>> GL_LIBS=' -lGL -lm '
>> ...
>> #define GLU_LIBS "-lGLU" ,"-lGL" ,"-lm"
>> ########################################
>>
>> It seems like the OpenGL and GLUT libraries are found (after -lglu32
>> fails, I am using Debian Linux).  I am not sure what to try now.
>>
>> Thank you for the help.  :)
>> __
>> Donnie
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/b717e7fb/attachment.htm
From allbery at ece.cmu.edu  Sat Sep 20 22:11:47 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sat Sep 20 22:09:07 2008
Subject: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World'
	Program.
In-Reply-To: 
References: 
	
	
	
	
	
Message-ID: <3DCC9EC3-3102-4592-9CFC-ACA5CDC92694@ece.cmu.edu>

On 2008 Sep 20, at 21:47, Donnie Jones wrote:
> However, when building the Haskell GLUT 'Hello World' it uses, -lGLU  
> to link GLUT, but that does not work; however, from the config.log  
> output configure seems to think that -lGL should work.  Is there a  
> way I can change the build to use -lglut?  Maybe with configure I  
> can specify that -lglut is the correct way to link the GLUT libraries?

Actually config.log said -lGLU worked.  If it's not present, maybe the  
simplest solution is to make a symlink.  (It would only need to be  
present for compilation; ld will use the SONAME entry in the library  
to find the runtime name, so it'll correctly use libglut.so.)

Fixing it at the level of the configure script is less than simple;  
you would need to modify configure.in and run autoreconf on it to  
produce a fixed configure (and you're in trouble if you have an older  
autotools than was used to create it originally).

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/843eacec/attachment.htm
From allbery at ece.cmu.edu  Sat Sep 20 22:13:34 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Sat Sep 20 22:10:53 2008
Subject: SOLVED. Re: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello
	World' Program.
In-Reply-To: 
References: 
Message-ID: <889B9F28-4029-47AE-BB29-BFE8F592400B@ece.cmu.edu>

On 2008 Sep 20, at 22:10, Donnie Jones wrote:
> ghc -package GLUT -lglut Hello1.hs -o Hello1 --- works!  :)
>
> I'm not sure why I must specify "-package GLUT" and "-lglut" but  
> that prevents the linker errors.  Also, shouldn't configure  
> correctly figure out how to link the GLUT libraries?  Can someone  
> explain?

You're overriding the information recorded by ghc-pkg (which is used  
if you use ghc --make).

As for why configure doesn't work, I think you'd have to let someone  
who knows the HOpenGL build stuff look at your system.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/25af66a9/attachment.htm
From donnie at darthik.com  Sat Sep 20 22:24:46 2008
From: donnie at darthik.com (Donnie Jones)
Date: Sat Sep 20 22:22:02 2008
Subject: Configure bug? Re: SOLVED. Re: [Haskell-cafe] Linker Errors For
	OpenGL / GLUT 'Hello World' Program.
Message-ID: 

Hello Brandon,

Maybe this is a bug in the configure script of Haskell OpenGL or GLUT
packages?  Any suggestion from the package maintainers (or someone more
familiar with these packages)?

Thanks!  :)
__
Donnie

On Sat, Sep 20, 2008 at 10:13 PM, Brandon S. Allbery KF8NH <
allbery@ece.cmu.edu> wrote:

> On 2008 Sep 20, at 22:10, Donnie Jones wrote:
>
> ghc -package GLUT -lglut Hello1.hs -o Hello1 --- works!  :)
>
> I'm not sure why I must specify "-package GLUT" and "-lglut" but that
> prevents the linker errors.  Also, shouldn't configure correctly figure out
> how to link the GLUT libraries?  Can someone explain?
>
>
> You're overriding the information recorded by ghc-pkg (which is used if you
> use ghc --make).
>
> As for why configure doesn't work, I think you'd have to let someone who
> knows the HOpenGL build stuff look at your system.
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
> electrical and computer engineering, carnegie mellon university    KF8NH
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080920/ac0a5a0a/attachment.htm
From dons at galois.com  Sat Sep 20 23:17:31 2008
From: dons at galois.com (Don Stewart)
Date: Sat Sep 20 23:14:39 2008
Subject: [Haskell-cafe] Re: Iteratee-based IO
In-Reply-To: <20080920074236.8C9F4AF09@Adric.metnet.fnmoc.navy.mil>
References: <20080920074236.8C9F4AF09@Adric.metnet.fnmoc.navy.mil>
Message-ID: <20080921031731.GE19306@scytale.galois.com>

oleg:
> It seems there is another approach, which is neither unsafe nor
> imperative. It relies neither on lazy IO nor on Handles. The input
> data can come from a file or from an embedded (e.g., chunk-encoded or
> encrypted) stream; the depth of embedding is arbitrary. The approach
> is naturally incremental. It permits IO interleaving without any
> unsafe operations. The approach is algebraic and declarative. The
> approach is the topic of the DEFUN08 talk in the morning of
> September 27. The code is already available 
> 
> 	http://okmij.org/ftp/Haskell/Iteratee/
> The file
> 	http://okmij.org/ftp/Haskell/Iteratee/README.dr 
>
> describes the other files in that directory. The running example is
> reading lines (terminated by CR, LF or CRLF) from a file descriptor
> and then from the chunk-encoded body. The main example illustrates
> multiplexing across two file descriptors and the full IO
> interleaving. The same line parser is used to process data from the
> file descriptor stream and from the embedded chunk-encoded stream,
> which is incrementally decoded.
> 
> The whole code is Haskell98. It is not optimized at all and has no
> GHC-specific pragmas and options. The code has been used for the Wc
> program demonstrated yesterday.
> 	
> Perhaps the code answers the questions posed yesterday by
> Don. Hopefully one can see several composition modes for the iteratees
> and enumerators; enumerators are just iteratee transformers and
> compose as such.

Wonderful. Thanks Oleg, I'll be studying these on the trip up to
Victoria. See you there!


-- Don
From ivan.miljenovic at gmail.com  Sun Sep 21 02:10:32 2008
From: ivan.miljenovic at gmail.com (Ivan Miljenovic)
Date: Sun Sep 21 02:07:46 2008
Subject: [Haskell-cafe] ANNOUNCE: graphviz-2008.9.20
Message-ID: 

The latest version of Matthew Sackman's Haskell bindings to Graphviz
[1] are now available on Hackage [2].  The reason there's a new
release only two weeks after the previous one is that I've made some
extensions to it (hence why I'm writing the announcement) that Matthew
has kindly included.

Since Matthew doesn't recall writing an announcement for graphviz
before, here is a brief synopsis of what it does.  The Graphviz
program is probably _the_ way of drawing graphs (note: this is
graph-theory graphs, not function plotting).  As it stands, there are
currently at least four different Haskell bindings available for
Graphviz that I've managed:
* The inbuilt Graphviz module in FGL [3]
* graphviz (which this announcement is for)
* dotgen [4]
* A really simple generator by Duncan Coutts [5]
In addition to this, the following utilities on Hackage output graphs
in Graphviz's .dot format (either using one of the above libraries or
their own parser):
* prof2dot : converts profiling information to .dot [custom, I think] [6]
* flow2Dot : convert textual descriptions to .dot [also custom, I think] [7]
* graphmod : draw the dependencies between Haskell modules [uses dotgen] [8]

As it can be seen, there's a plethora of possible ways of creating
.dot graphs in Haskell.  What seperates the graphviz package from the
others is:
* It uses FGL graphs, rather than passing through lists of nodes and
edges manually (of course, if you're not doing any other graph-related
activity you might not want to use an FGL graph), whilst providing
more control than the default FGL module.
* A large list of attributes that can be used are available:
http://hackage.haskell.org/packages/archive/graphviz/2008.9.20/doc/html/Data-GraphViz-Attributes.html
* A "sane" interface that provides a large degree of customizability
(don't specify the attributes manually for each node/edge/etc., just
pass through a function that will create the attribute you want).
* Limited parsing of .dot format (note that as yet it can't convert a
parsed DotGraph into an FGL graph).
* The graphToGraph function allows you to pass a graph through
Graphviz and then extract out positional information and combine it
with the original graph.

There are some things things that graphviz can't do, such as drawing
undirected graphs and clusters (which dotgen can)... at least until
now.

The changes that I have made provide the additional functionality to graphviz:
* Differentiate between undirected and directed graphs.  Whilst FGL
represents undirected graphs with a directed graph by duplicating all
edges (an undirected edge {1,2} is represented by the two edges (1,2)
and (2,1)), you don't really want to draw a graph this way.
Furthermore, many reports say that graphviz's "neato" command is
better at drawing undirected graphs than the normal "dot" command is.
Thus, graphviz will now draw only one edge out of every directed pair.
 To do so, however, requires that the edge labels are an instance of
Ord: if this is a problem for you, please contact either Matthew or
myself and we'll see what else we can do (this is required because
it's assumed that if two edges (1,2) and (2,1) are meant to represent
the undirected edge {1,2}, then their labels must be the same).
* Add clustering support.  Graphs can be drawn (but as yet not parsed)
to provide nested clustering support to arbitrary depth.  To do so,
you need to provide a function (LNode a -> NodeCluster c a), where
NodeCluster is the following recursive data type that indicates in
which subcluster a node in the graph belongs:
     data NodeCluster c a = N (LNode a) | C c (NodeCluster c a)
The c type represents the cluster label, and is the parameter by which
cluster attributes are assigned.  Note that c has to be an instance of
Ord.  Clusters are not parseable, because there's no clear way of how
to convert a cluster to an FGL graph.

The interface for graphviz remains unchanged, so you can safely
upgrade to this version.

Here is an example function of how the library can be used to draw an
FGL graph to a (very plain) Graphviz graph (well, it will convert it
to the DotGraph datatype, which when shown produces the .dot graph
code):

graphviz         :: (Graph g, Show a, Ord b, Show b) => String -> g a
b -> DotGraph
graphviz title g = graphToDot g attrs nattrs eattrs
    where
      attrs = [Label title]
      nattrs (_,a)   = [Label (show a)]
      eattrs (_,_,b) = [Label (show b)]

Enjoy!


[1] http://graphviz.org/
[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphviz
[3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl
[4] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dotgen
[5] http://haskell.org/~duncan/WriteDotGraph.hs
[6] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/prof2dot
[7] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/flow2dot
[8] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphmod

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
From dons at galois.com  Sun Sep 21 02:38:16 2008
From: dons at galois.com (Don Stewart)
Date: Sun Sep 21 02:35:25 2008
Subject: [Haskell-cafe] ANNOUNCE: graphviz-2008.9.20
In-Reply-To: 
References: 
Message-ID: <20080921063816.GB20287@scytale.galois.com>

ivan.miljenovic:
> The latest version of Matthew Sackman's Haskell bindings to Graphviz
> [1] are now available on Hackage [2].  The reason there's a new
> release only two weeks after the previous one is that I've made some
> extensions to it (hence why I'm writing the announcement) that Matthew
> has kindly included.

And by now you know where which distro has it:
    
    http://aur.archlinux.org/packages.php?ID=18343

See also, 

    http://archhaskell.wordpress.com/2008/09/20/arch-haskell-news-sep-20-2008/

:)

-- Don
From ivan.miljenovic at gmail.com  Sun Sep 21 02:45:50 2008
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun Sep 21 02:43:12 2008
Subject: [Haskell-cafe] ANNOUNCE: graphviz-2008.9.20
In-Reply-To: <20080921063816.GB20287@scytale.galois.com>
References: 
	<20080921063816.GB20287@scytale.galois.com>
Message-ID: <20080921164550.70ecccf7@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 20 Sep 2008 23:38:16 -0700
Don Stewart  wrote:

> 
> And by now you know where which distro has it:
>     
>     http://aur.archlinux.org/packages.php?ID=18343

I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew
told me he uploaded it to Hackage)! ;-)


- -- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjV7aAACgkQfEfFJ9Jhvyjj1gCfakJfsQX6g8FTc4kY2jDBogVl
v/EAn31XYRa98GVY7Nz1G+cfOZ8tegJz
=iDT/
-----END PGP SIGNATURE-----
From dons at galois.com  Sun Sep 21 02:47:09 2008
From: dons at galois.com (Don Stewart)
Date: Sun Sep 21 02:44:16 2008
Subject: [Haskell-cafe] ANNOUNCE: graphviz-2008.9.20
In-Reply-To: <20080921164550.70ecccf7@gmail.com>
References: 
	<20080921063816.GB20287@scytale.galois.com>
	<20080921164550.70ecccf7@gmail.com>
Message-ID: <20080921064709.GC20287@scytale.galois.com>

ivan.miljenovic:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, 20 Sep 2008 23:38:16 -0700
> Don Stewart  wrote:
> 
> > 
> > And by now you know where which distro has it:
> >     
> >     http://aur.archlinux.org/packages.php?ID=18343
> 
> I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew
> told me he uploaded it to Hackage)! ;-)

Mwhaha. Game on!

-- Don
From andrewcoppin at btinternet.com  Sun Sep 21 03:44:10 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sun Sep 21 03:41:19 2008
Subject: [Haskell-cafe] Packages
In-Reply-To: <20080921164550.70ecccf7@gmail.com>
References: 	<20080921063816.GB20287@scytale.galois.com>
	<20080921164550.70ecccf7@gmail.com>
Message-ID: <48D5FB4A.1010700@btinternet.com>

Ivan Lazar Miljenovic wrote:
> On Sat, 20 Sep 2008 23:38:16 -0700
> Don Stewart  wrote:
>
>   
>> And by now you know where which distro has it:
>>     
>>     http://aur.archlinux.org/packages.php?ID=18343
>>     
>
> I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew
> told me he uploaded it to Hackage)! ;-)
>   

I'm sorry, I'm confused...

1. How is putting something into a Cabal package different from just 
handing somebody the source code and telling them to run ghc --make?

2. If we already have a Cabal package, why do we also need seperate 
packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?

3. Why isn't any of this explained in print anywhere?

From mad.one at gmail.com  Sun Sep 21 04:03:31 2008
From: mad.one at gmail.com (Austin Seipp)
Date: Sun Sep 21 04:00:47 2008
Subject: [Haskell-cafe] Packages
In-Reply-To: <48D5FB4A.1010700@btinternet.com>
References: 
	<20080921063816.GB20287@scytale.galois.com>
	<20080921164550.70ecccf7@gmail.com>
	<48D5FB4A.1010700@btinternet.com>
Message-ID: <1221983336-sup-3643@existential.local>

Excerpts from Andrew Coppin's message of Sun Sep 21 02:44:10 -0500 2008:
> 1. How is putting something into a Cabal package different from just 
> handing somebody the source code and telling them to run ghc --make?

Cabal can handle things for you like when your package depends on
external data files; when cabal compiles the code it autogenerates a
module which you import that will give you the path name to where-ever
it is installed, which is nifty in case you for example are uploading
a language for an interpreter and want to store the languages' prelude
somewhere.

It also allows for more tight constraints on dependent package versions
i.e. with it you can specify the exact package and version you need to
build (for example, parsec < 2.1 && > 3.0 which a few packages do.)
With --make you would have to include a lot of -hide-package flags and
a lot of other things, too.

It is also naturally the easiest way to actually install libraries
since it will register that library with ghc-pkg for you.

> 2. If we already have a Cabal package, why do we also need seperate 
> packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?

Having these packages available as native packages for a package
manager lets you distribute applications easier for example; if
someone just wants to install  from say, the archlinux user
repository (which is source-based, mind you - the official repo is
binary based,) it may also depend on parsec, haskell98, HTTP,
etc.. Having these packages available natively to the manager means it
can track the dependencies and install the application by itself -
this is useful for example if someone just wants to use a haskell
application but they don't code haskell (example: darcs or pandoc.)

Of course, if you are doing haskell development, the best possible way
to go (IMO) full-blown cabal install since you will always get the
most up-to-date code - plus mixing and matching native package
managers and e.g. cabal install doesn't really work well IME; for
example if you want to install alex from macports, it will
automatically install ghc too, even if you actually have it installed,
but you didn't install it through macports (I just used the .dmg file
that Manual Chak. made.) Likewise you may want to get something and it
might depend on the HTTP library - it could very well already be
installed via cabal-install, but the native manager won't dig into GHC
to find out and will instead just work based on what it knows is
installed in its package database.

Austin
From dons at galois.com  Sun Sep 21 04:10:29 2008
From: dons at galois.com (Don Stewart)
Date: Sun Sep 21 04:07:47 2008
Subject: [Haskell-cafe] Packages
In-Reply-To: <48D5FB4A.1010700@btinternet.com>
References: 
	<20080921063816.GB20287@scytale.galois.com>
	<20080921164550.70ecccf7@gmail.com>
	<48D5FB4A.1010700@btinternet.com>
Message-ID: <20080921081029.GA20525@scytale.galois.com>

andrewcoppin:
> Ivan Lazar Miljenovic wrote:
> >On Sat, 20 Sep 2008 23:38:16 -0700
> >Don Stewart  wrote:
> >
> >  
> >>And by now you know where which distro has it:
> >>    
> >>    http://aur.archlinux.org/packages.php?ID=18343
> >>    
> >
> >I'm sorry, Don, but you're late... Gentoo had it last night (as soon as 
> >Matthew
> >told me he uploaded it to Hackage)! ;-)
> >  
> 
> I'm sorry, I'm confused...
> 
> 1. How is putting something into a Cabal package different from just 
> handing somebody the source code and telling them to run ghc --make?
> 
> 2. If we already have a Cabal package, why do we also need seperate 
> packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
> 
> 3. Why isn't any of this explained in print anywhere?

It's all about users.  To see more of the philosophy here, check out,

    Haskell: Batteries Included
    http://www.cse.unsw.edu.au/~dons/papers/CPJS08.html

Ubiquitous, easy, complete Haskell.

-- Don
From bulat.ziganshin at gmail.com  Sun Sep 21 04:40:54 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Sun Sep 21 04:42:40 2008
Subject: [Haskell-cafe] OpenSPARC project applicant chosen
In-Reply-To: <1221925028.5395.674.camel@localhost>
References: <1221925028.5395.674.camel@localhost>
Message-ID: <1814448613.20080921124054@gmail.com>

Hello Duncan,

Saturday, September 20, 2008, 7:37:08 PM, you wrote:

> http://haskell.org/opensparc/

the page says that you still search for a student

how community server may be used to measure performance? i'm
interested in doing some benchmarks but afaiu this needs exclusive
access for some time?


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From xs at xaph.net  Sun Sep 21 08:28:37 2008
From: xs at xaph.net (Rafal Kolanski)
Date: Sun Sep 21 08:25:55 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
Message-ID: <48D63DF5.6070108@xaph.net>

Hi,

I'm trying to, in addition to all the other things on my cairo surface,
pull some images in from .png files. I've googled, I've looked in the
docs, but there isn't any way I can see to load a .png file into a
surface. The best I can find is withImageSurfaceFromPNG, but I can't
make it work.

The C guys can do:
  image = cairo_image_surface_create_from_png("blah.png");
and then:
  cairo_set_source_surface(cr, image, 10, 10);
  cairo_paint(cr)

I tried playing around with unsafePerformIO but that just gets me into:
/build/buildd/cairo-1.6.0/src/cairo-surface.c:382:
cairo_surface_reference: Assertion
`((*&(&surface->ref_count)->ref_count) > 0)' failed.

Are any gtk2hs people around who can throw me in the right direction?

Sincerely,

Rafal Kolanski.

From mad.one at gmail.com  Sun Sep 21 08:39:53 2008
From: mad.one at gmail.com (Austin Seipp)
Date: Sun Sep 21 08:37:09 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
In-Reply-To: <48D63DF5.6070108@xaph.net>
References: <48D63DF5.6070108@xaph.net>
Message-ID: <1222000565-sup-844@existential.local>

Excerpts from Rafal Kolanski's message of Sun Sep 21 07:28:37 -0500 2008:
> The best I can find is withImageSurfaceFromPNG, but I can't
> make it work.

Why not? Seems to me all you need to do is:

 withImageSurfaceFromPNG "blah.png" $ \surface -> do
    ...

Lots of code is written this way (create a resource, pass it to a
function and then release it after the function is over.)

> I tried playing around with unsafePerformIO but that just gets me into:

Without further context as to what you are doing, I really see no
reason why you would have to use unsafePerformIO at all.

Austin
From xs at xaph.net  Sun Sep 21 09:01:00 2008
From: xs at xaph.net (Rafal Kolanski)
Date: Sun Sep 21 08:58:16 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
In-Reply-To: <1222000565-sup-844@existential.local>
References: <48D63DF5.6070108@xaph.net> <1222000565-sup-844@existential.local>
Message-ID: <48D6458C.3020407@xaph.net>



Austin Seipp wrote:
> Excerpts from Rafal Kolanski's message of Sun Sep 21 07:28:37 -0500 2008:
>> The best I can find is withImageSurfaceFromPNG, but I can't
>> make it work.
> 
> Why not? Seems to me all you need to do is:
> 
>  withImageSurfaceFromPNG "blah.png" $ \surface -> do
>     ...
> 
> Lots of code is written this way (create a resource, pass it to a
> function and then release it after the function is over.)

Well, but withImageSurfaceFromPNG only lets you work within that scope
and wipes out the surface straight afterwards ...

>> I tried playing around with unsafePerformIO but that just gets me into:
> 
> Without further context as to what you are doing, I really see no
> reason why you would have to use unsafePerformIO at all.

The context is, I want to render a multi-page PDF with a variety of
things on it, so I have something like (very simplified):

main :: IO ()
main = do
     withPDFSurface outputFile pdfWidth pdfHeight renderer

renderer s = renderWith s renderPresentation

renderPresentation = do
     myDraw1
     showPage
     myDraw2
     showPage

myDraw1 = do
     setSourceRGB 1 0 0
     setLineWidth 1
     moveTo 0 0
     lineTo 100 100
     stroke

so renderPresentation will have type Render ()

Now lets say I want to draw an image on page 2, that will only appear on
page 2 ... with one image, your technique makes sense to me, but with
multiple images on multiple pages, I don't understand how to make it scale.

Perhaps this code is very naive, but I'm kinda new to the pure world of
Haskell.

Sincerely,

Rafal Kolanski.

From xs at xaph.net  Sun Sep 21 09:43:14 2008
From: xs at xaph.net (Rafal Kolanski)
Date: Sun Sep 21 09:40:52 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
In-Reply-To: <48D6458C.3020407@xaph.net>
References: <48D63DF5.6070108@xaph.net> <1222000565-sup-844@existential.local>
	<48D6458C.3020407@xaph.net>
Message-ID: <48D64F72.2030703@xaph.net>

I finally came up with a solution that suits my context. For those 
interested, I'm supplying it here.

Safely get a surface containing your .png image (note that the surface 
has to be freed when you're done with it using surfaceFinish)

imageSurfaceCreateFromPNG :: FilePath -> IO Surface
imageSurfaceCreateFromPNG file =
     withImageSurfaceFromPNG file $ \png -> do
         w <- renderWith png $ imageSurfaceGetWidth png
         h <- renderWith png $ imageSurfaceGetHeight png
         surf <- createImageSurface FormatRGB24 w h
         renderWith surf $ do
             setSourceSurface png 0 0
             paint
         return surf

Now the unsafe part (hack until I have an associative list storing my 
images to pull into relevant pages for rendering):

unsafeLoadPNG file = unsafePerformIO $ imageSurfaceCreateFromPNG file

This allows drawing an image directly in a Render () context:

paintImage :: FilePath -> Double -> Double -> Render ()
paintImage file x y = do
     surf <- return $ unsafeLoadPNG file
     setSourceSurface surf x y
     paint

Looking at this irc log from 2005:
   http://www.cse.unsw.edu.au/~dons/code/irc-logs/05.11.20
someone's had this problem before, and although they did not show their 
solution, I think it might've been similar to mine.

Hope this helps the next person to get stuck.

Sincerely,

Rafal Kolanski.
From andrewcoppin at btinternet.com  Sun Sep 21 09:52:51 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sun Sep 21 09:49:58 2008
Subject: [Haskell-cafe] Packages
In-Reply-To: <1221983336-sup-3643@existential.local>
References: 	<20080921063816.GB20287@scytale.galois.com>	<20080921164550.70ecccf7@gmail.com>	<48D5FB4A.1010700@btinternet.com>
	<1221983336-sup-3643@existential.local>
Message-ID: <48D651B3.4050902@btinternet.com>

Austin Seipp wrote:
> Cabal can handle things for you like when your package depends on
> external data files; when cabal compiles the code it autogenerates a
> module which you import that will give you the path name to where-ever
> it is installed, which is nifty in case you for example are uploading
> a language for an interpreter and want to store the languages' prelude
> somewhere.
>   

OK, fair enough. I'm unlikely to ever need this personally, but it has 
utility.

> It also allows for more tight constraints on dependent package versions
> i.e. with it you can specify the exact package and version you need to
> build (for example, parsec < 2.1 && > 3.0 which a few packages do.)
> With --make you would have to include a lot of -hide-package flags and
> a lot of other things, too.
>   

So you're saying that using Cabal allows you to check that all your 
build dependencies are already installed?

(Certainly just building something with GHC means that if some package 
isn't installed, you're going to have a hard time figuring out what's 
missing.)

> It is also naturally the easiest way to actually install libraries
> since it will register that library with ghc-pkg for you.
>   

Mmm, OK.

>> 2. If we already have a Cabal package, why do we also need seperate 
>> packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
>>     
>
> Having these packages available as native packages for a package
> manager lets you distribute applications easier for example; if
> someone just wants to install  from say, the archlinux user
> repository (which is source-based, mind you - the official repo is
> binary based,) it may also depend on parsec, haskell98, HTTP,
> etc.. Having these packages available natively to the manager means it
> can track the dependencies and install the application by itself -
> this is useful for example if someone just wants to use a haskell
> application but they don't code haskell (example: darcs or pandoc.)
>
> Of course, if you are doing haskell development, the best possible way
> to go (IMO) full-blown cabal install.

Having native packages for stand-alone applications such as Darcs makes 
sense to me - after all, you don't need to install GCC just to use (say) 
KEdit, so why would you need to install GHC and build Darcs from source 
just to use it? However, managing individual Haskell libraries via the 
local package management system seems slightly redundant to me.
 
From bulat.ziganshin at gmail.com  Sun Sep 21 09:55:20 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Sun Sep 21 09:52:49 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
In-Reply-To: <48D64F72.2030703@xaph.net>
References: <48D63DF5.6070108@xaph.net> <1222000565-sup-844@existential.local>
	<48D6458C.3020407@xaph.net> <48D64F72.2030703@xaph.net>
Message-ID: <188898053.20080921175520@gmail.com>

Hello Rafal,

Sunday, September 21, 2008, 5:43:14 PM, you wrote:

>      withImageSurfaceFromPNG file $ \png -> do
>          w <- renderWith png $ imageSurfaceGetWidth png
>          h <- renderWith png $ imageSurfaceGetHeight png

this is very idiomatic Haskell, consider it as a sort of RAII. you may
even omit additional tab here:

>      withImageSurfaceFromPNG file $ \png -> do
>      w <- renderWith png $ imageSurfaceGetWidth png
>      h <- renderWith png $ imageSurfaceGetHeight png
>      ...

afair, Render is a super-IO monad so you can just lift any IO
operation to Render:

x <- liftIO$ imageSurfaceCreateFromPNG file



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From xs at xaph.net  Sun Sep 21 10:09:47 2008
From: xs at xaph.net (Rafal Kolanski)
Date: Sun Sep 21 10:07:05 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
In-Reply-To: <188898053.20080921175520@gmail.com>
References: <48D63DF5.6070108@xaph.net> <1222000565-sup-844@existential.local>
	<48D6458C.3020407@xaph.net> <48D64F72.2030703@xaph.net>
	<188898053.20080921175520@gmail.com>
Message-ID: <48D655AB.8040407@xaph.net>


Bulat Ziganshin wrote:
> afair, Render is a super-IO monad so you can just lift any IO
> operation to Render:
> 
> x <- liftIO$ imageSurfaceCreateFromPNG file

You are indeed correct.

I feel really silly now, using unsafePerformIO in the IO monad. D'oh!

Thank you very much!

Rafal Kolanski.
From nicolas.pouillard at gmail.com  Sun Sep 21 10:10:34 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Sun Sep 21 10:08:36 2008
Subject: [Haskell-cafe] Ropes
In-Reply-To: <351ff25e0809200354m6dc90c0apc723c26a1e4e53f@mail.gmail.com>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
	<2f9b2d30809191915m2cdd8963yded4fb1c14c40c43@mail.gmail.com>
	<351ff25e0809200354m6dc90c0apc723c26a1e4e53f@mail.gmail.com>
Message-ID: <1222006230-sup-1742@ausone.local>

Excerpts from Rafael Gustavo da Cunha Pereira Pinto's message of Sat Sep 20 12:54:26 +0200 2008:
> I am doing the ICFPC07 task right now, to learn Haskell and tried to use the
> Sequence, but the final code is too damn slow (a few iterations per
> minute!).

Is your structure a sequence of *Char*s, if so you should consider to use a
sequence of strict bytestrings of a given size (chunks).

> The DNA needs only 2 operations: head (or take) and concat.
> 
> I am thinking in using ropes for the DNA and sequences for all the rest
> (patterns, templates and RNA).
> 
> On Fri, Sep 19, 2008 at 23:15, Ryan Ingram  wrote:
> 
> > I think Data.Sequence uses fingertrees which are pretty fast.
> >
> > I used a handgrown rope-like structure for ICFPC07 but I wish I had
> > known about Sequence; it would have likely just been better.
> >
> >  -- ryan
> >
> > 2008/9/19 Rafael Gustavo da Cunha Pereira Pinto <
> > RafaelGCPP.Linux@gmail.com>:
> > > Hi all,
> > >
> > > Is there any implementation of the rope data structure in Haskell?
> > >
> > > I couldn't find any on Hackage, and I am intending to implement it.
> > >
> > > Regards,
> > >
> > > Rafael Gustavo da Cunha Pereira Pinto
> > > Electronic Engineer, MSc.
> > >
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > Haskell-Cafe@haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> > >
> >
> 

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080921/ff19e5cd/signature.bin
From agl at imperialviolet.org  Sun Sep 21 10:31:19 2008
From: agl at imperialviolet.org (Adam Langley)
Date: Sun Sep 21 10:28:34 2008
Subject: [Haskell-cafe] Re: Iteratee-based IO
In-Reply-To: <20080921031731.GE19306@scytale.galois.com>
References: <20080920074236.8C9F4AF09@Adric.metnet.fnmoc.navy.mil>
	<20080921031731.GE19306@scytale.galois.com>
Message-ID: <396556a20809210731w417df158j706cccac2f3a8e62@mail.gmail.com>

On Sat, Sep 20, 2008 at 8:17 PM, Don Stewart  wrote:
> Wonderful. Thanks Oleg, I'll be studying these on the trip up to
> Victoria. See you there!

Something similar is available in binary-strict[1], although there I
have (versions of) IE_Done, IE_Cont and (additionally) IE_Fail, for
indicating a parse failure.

The actual implementation is unpleasant, although functional.


[1]  http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/src/Data/Binary/Strict/IncrementalGet.hs


-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
From s.clover at gmail.com  Sun Sep 21 11:02:06 2008
From: s.clover at gmail.com (Sterling Clover)
Date: Sun Sep 21 10:57:44 2008
Subject: [Haskell-cafe] Parsing arguments and reading configuration
In-Reply-To: <694519c50809191739i3a931c21k26f7249bf879d8a7@mail.gmail.com>
References: <48D42693.8040507@therning.org>
	<694519c50809191735w178e66c2j101484d989a1da1a@mail.gmail.com>
	<694519c50809191739i3a931c21k26f7249bf879d8a7@mail.gmail.com>
Message-ID: <86E2F023-C91D-4957-8960-E6521BA8467D@gmail.com>

Alternately, just go with a map initially with default values. Then  
parse the command line args into a second map (especially if they're  
all of a format like -argname argvalue). Then lookup your args file  
with the command line map, and failing that the default map. Then  
read the args file and finally merge all three maps in the proper  
order. No need for monoid instances, special data types or any of  
that, so at a little cost in elegance a much more succinct way to get  
what you want. As a final step, you can always project the map values  
into a record type, to get some safety for the rest of your program.  
The entire process, aside from creating the record, should probably  
be no more than four or so lines.

--Sterl.

On Sep 19, 2008, at 8:39 PM, Antoine Latter wrote:

> On Fri, Sep 19, 2008 at 7:35 PM, Antoine Latter  
>  wrote:
>> I'm not sure how well it would hold up under maintenance, but you  
>> coud
>> have a config sum-type which is itself a monoid, and then create two
>> of them:
>>
>
> And by sum-type I mean product type.  Sheesh.
>
> Although having your config options in a sum-type packed into a Set,
> which is itself a Monoid is another option.  Then you get 'mempty' and
> 'mappend' for free.
>
> I think I saw a blog-post or something detailing this, but I don't
> have a book-mark.
>
> -Antoine
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From argaldo.haskell at gmail.com  Sun Sep 21 11:59:43 2008
From: argaldo.haskell at gmail.com (Alberto R. Galdo)
Date: Sun Sep 21 11:56:56 2008
Subject: [Haskell-cafe] Hugs on the iphone
In-Reply-To: <51562ec30809200903l4aa285ceg930859cb63397993@mail.gmail.com>
References: <3E6BE6FE-FA31-429B-84E5-798CA88BEED1@gmail.com>
	
	
	
	<51562ec30809200903l4aa285ceg930859cb63397993@mail.gmail.com>
Message-ID: <51562ec30809210859l3d79bd5bi194a5232245d9cec@mail.gmail.com>

And there it is!

Hugs98 is now available for installation on the iphone/ipod touch.

It is being served through the community sources at cydia, one the most
"official" unofficial installers for pwnaged iphone/ipods. That means that
if you have cydia already installed, if you look for hugs98 in the search
tab, it will be there waiting for you.

Just install hugs98 and/or hugs98-packages (for full library support), open
a terminal console and run 'hugs', everything should be familiar from now
on...

If not, just install cydia, and hugs98 is included in the default source
list.

And, for those brave of you, here are the packages for own/custom
installation:

com.wordpress.argaldo.hugs98 (interpreter and minimal packages) ->
http://iphone.sleepers.net/onepackage.php?bundleid=com.wordpress.argaldo.hugs98&db=

com.wordpress.argaldo.hugs98-packages (full library support) ->
http://iphone.sleepers.net/onepackage.php?bundleid=com.wordpress.argaldo.hugs98-packages&db=


Greets


On Sat, Sep 20, 2008 at 6:03 PM, Alberto R. Galdo  wrote:

> Hi,
>
>    I finally got hugs to compile for the iPhone 2.x firmware (
> pwnaged,obviously ).
>
>    It was a matter of using the gcc compiler version distributed by apple
> in their iPhone SDK ( wich generates ARM code and suitable for
> cross-compiling C code in a mac ), autoconf 'configure' script tweaking and
> some system variables hacking here and there.
>
>    So, now you ( and I ), people will be able to run your Haskell code
> directly on the iPhone using hugs ( hoping not to be the only one... ;-))
>
>    I'm in the process of submitting the package to one of those "public"
> repositories of iphone apps... you'll have notices soon.
>
>    If someone can resist, and like to have cydia compatible packages, just
> drop me a note and I'll send them to you by mail.
>
> Greets,
>
> Alberto
>
> On Mon, Sep 15, 2008 at 6:01 PM, Miguel Mitrofanov wrote:
>
>> My iPhone (iPod Touch, actually) have 1.1.4 firmware, so there isn't any
>> code signing involved. I've just "configure"d and "make"d.
>>
>>
>> On 15 Sep 2008, at 09:47, Alberto R. Galdo wrote:
>>
>>  Cool! That's such a proof that it can be done...
>>>
>>> I had lots of problems trying to cross compile hugs from my mac to arm
>>> architecture ( seems that hugs codebase is not capable of cross compiling )
>>>
>>> And when compiling directly  on the iPhone, first there where problems
>>> with code signing, now with the configure script and C preprocessor sanity
>>> check...
>>>
>>> Any light on the topic from your experience?
>>>
>>> On 15/09/2008, at 7:24, Miguel Mitrofanov  wrote:
>>>
>>>  Did that.
>>>> http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html
>>>>
>>>> On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:
>>>>
>>>>  Hi, is there any chance of having hugs  compile for the iPhone?
>>>>>
>>>>> Cross-compiling? Compiling directly on the iPhone?
>>>>>
>>>>> Greets,
>>>>> Alberto
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> Haskell-Cafe@haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>>
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080921/61f58d44/attachment.htm
From jefferson.r.heard at gmail.com  Sun Sep 21 12:31:34 2008
From: jefferson.r.heard at gmail.com (Jefferson Heard)
Date: Sun Sep 21 12:28:47 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
In-Reply-To: <48D655AB.8040407@xaph.net>
References: <48D63DF5.6070108@xaph.net> <1222000565-sup-844@existential.local>
	<48D6458C.3020407@xaph.net> <48D64F72.2030703@xaph.net>
	<188898053.20080921175520@gmail.com> <48D655AB.8040407@xaph.net>
Message-ID: <4165d3a70809210931w55831859m1687872071407a15@mail.gmail.com>

Sorry.  In a hurry, and I don't have a lot of time to read the
message, so if I'm offering a lot of info you already have, I
apologize.  The best thing to do is to allocate either a pixmap or
Gtk.DrawingArea -- you can then use widgetGetDrawable to get the
drawing context from it and newGC to take drawing context and get a
graphics context.  After you have a drawing and graphics context, you
can use drawPixbuf to draw or update any image you want, then use the
same DrawngArea for Cairo after you've drawing the image.

If you need more help with it, let me know, and I can send some code
that will do it later today.

-- Jeff

On Sun, Sep 21, 2008 at 10:09 AM, Rafal Kolanski  wrote:
>
> Bulat Ziganshin wrote:
>>
>> afair, Render is a super-IO monad so you can just lift any IO
>> operation to Render:
>>
>> x <- liftIO$ imageSurfaceCreateFromPNG file
>
> You are indeed correct.
>
> I feel really silly now, using unsafePerformIO in the IO monad. D'oh!
>
> Thank you very much!
>
> Rafal Kolanski.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards
From byorgey at seas.upenn.edu  Sun Sep 21 12:56:51 2008
From: byorgey at seas.upenn.edu (Brent Yorgey)
Date: Sun Sep 21 12:54:03 2008
Subject: [Haskell-cafe] OpenSPARC project applicant chosen
In-Reply-To: <1221948221.5395.683.camel@localhost>
References: <1221925028.5395.674.camel@localhost> <20080920205004.GA5068@flit>
	<1221948221.5395.683.camel@localhost>
Message-ID: <20080921165651.GA5647@seas.upenn.edu>

On Sat, Sep 20, 2008 at 11:03:41PM +0100, Duncan Coutts wrote:
> On Sat, 2008-09-20 at 23:50 +0300, Roman Cheplyaka wrote:
> > * Duncan Coutts  [2008-09-20 16:37:08+0100]
> > > If you want to follow the progress we will be using the existing ghc
> > > development mailing list:
> > > http://www.haskell.org/mailman/listinfo/cvs-ghc
> > > 
> > > and a corner of the ghc development wiki:
> > > http://hackage.haskell.org/trac/ghc/wiki/OpenSPARC
> > 
> > I hope Brent also will be publishing the news of the project in HWN.
> 
> I'm also hoping Ben might post updates to a blog, but I've not asked him
> yet.

If Ben does so, I would be happy to feature them prominently in the HWN!

-Brent
From andrewcoppin at btinternet.com  Sun Sep 21 13:34:21 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sun Sep 21 13:31:28 2008
Subject: [Haskell-cafe] The ultimate insult?
Message-ID: <48D6859D.3060609@btinternet.com>

"Delphi is usable. If you're a single hobbiest programmer, use whatever 
gets the job done. But as far as a career goes, I'd say even Haskell has 
better prospects than Delphi."

So "even Haskell" is better? Ouch!

Still, in a bank-handed kind of way, I guess that means Haskell isn't as 
dead as Delphi yet, so it's also kind of a complement... of sorts...

From newsham at lava.net  Sun Sep 21 14:13:13 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun Sep 21 14:10:40 2008
Subject: [Haskell-cafe] haskell shootout -- mandelbrot
In-Reply-To: <20080920202648.GD18629@scytale.galois.com>
References: 
	<20080920202648.GD18629@scytale.galois.com>
Message-ID: 

Here's a whack at regex-dna:
   http://haskell.org/haskellwiki/Shootout/Parallel/RegexDNA

only modest speedup (memory bw bound?).  A regex engine that could
run several machines concurrently in one pass would prob be a big win.

Tim Newsham
http://www.thenewsh.com/~newsham/
From andrewcoppin at btinternet.com  Sun Sep 21 14:14:58 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sun Sep 21 14:12:06 2008
Subject: [Haskell-cafe] Line noise
Message-ID: <48D68F22.1090808@btinternet.com>

I hang out on another forum that is populated by various kinds of 
computer geeks. There's a fair few programmers in there, as well as 
nerds of every degree. And yet, every time I post anything written in 
Haskell, everybody complains that it "looks like line noise".

What do "normal" programmers find so puzzling about Haskell? You might 
guess some of the following:
- High-order functions.
- Lambda functions.
- Algebraic data types.
- Lazy evaluation.
- Recursion.
- Monads.

Actually, none of these things were mentioned. The things people have 
*actually* complained to me about are:
- Haskell expressions are difficult to parse.
- Several standard library elements have unhelpful names such as "elem", 
"Eq" and "fst". (My favourite has to be "Ix". I mean, WTH?)
- Several standard library functions have names which clash badly with 
the usual meanings of those names - e.g., "break", "return", "id".
- Variable names such as "x" and "f" aren't fabulously helpful to lost 
programmers trying to find their way.

If you take a "typical" lump of C or Java code, there's so much 
redundancy and noise in it that you can *usually* figure out vaguely 
what's going on, even if it doesn't completely make sense. When 
presented with a typical Haskell fragment... uh... well, good luck with 
that. Let's take Haskell's most celebrated example:

  qsort [] = []
  qsort (x:xs) = qsort (filter (x <) xs) ++ [x] ++ qsort (filter (x >=) xs)

To a novice, it's not actually real clear what the arguments to qsort 
are. You and I know that function application binds much more tightly 
than (++), but a novice isn't going to know that. You might also not 
immediately realise that "xs" is also an argument to filter, not just (x 
<) or whatever. The people I spoke to also seemed pretty confused about 
the usage of (.) and ($), even after I explained it a few times. Several 
people also voiced being puzzled about Haskell's layout rules.

I'm not sure what we *do* with all this data, but I found it interesting 
so I thought I'd share. ;-) I've spent the last few years trying to 
convert a few people to The Haskell Way(tm), but so far I haven't 
succeeded in the slightest. I just get yelled at for pointing white 
noise. Heh. Oh well!

From micah at cowan.name  Sun Sep 21 14:48:39 2008
From: micah at cowan.name (Micah Cowan)
Date: Sun Sep 21 14:45:37 2008
Subject: [Haskell-cafe] The ultimate insult?
In-Reply-To: <48D6859D.3060609@btinternet.com>
References: <48D6859D.3060609@btinternet.com>
Message-ID: <48D69707.5020509@cowan.name>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Coppin wrote:
> "Delphi is usable. If you're a single hobbiest programmer, use whatever
> gets the job done. But as far as a career goes, I'd say even Haskell has
> better prospects than Delphi."
> 
> So "even Haskell" is better? Ouch!

Oh come on... has anyone here actually pursued learning Haskell because
they thought it would help them rake in the jobs? :)

...I did once have a manager who habitually listed Lisp as a requirement
for software positions, even though it wasn't actually going to be used
(it was all C, C++ and Perl). He just wanted prospective employees to
have had experience understanding a different paradigm (functional-ish
programming). I wonder whether he's updated that to "Lisp, Scheme or
Haskell"? XSLT would do as well, I suppose...

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI1pcH7M8hyUobTrERAoaDAJ4g+Eom8k52MlidTASj8JhtJDubhACdEhjN
MGXfz3V3/5HHwpMkTuKZ7Cw=
=5Q8x
-----END PGP SIGNATURE-----
From flippa at flippac.org  Sun Sep 21 14:52:19 2008
From: flippa at flippac.org (Philippa Cowderoy)
Date: Sun Sep 21 14:51:48 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D68F22.1090808@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
Message-ID: 

On Sun, 21 Sep 2008, Andrew Coppin wrote:

> Actually, none of these things were mentioned. The things people have
> *actually* complained to me about are:
> - Haskell expressions are difficult to parse.

This is partly an "it's not braces, semicolons and function(application)" 
complaint, though not entirely.

> - Several standard library elements have unhelpful names such as "elem", "Eq"
> and "fst". (My favourite has to be "Ix". I mean, WTH?)



> - Several standard library functions have names which clash badly with the
> usual meanings of those names - e.g., "break", "return", "id".

For this one, I'm inclined to say "welcome to a new paradigm". Though 
having to tell my dad briefly that do isn't a loop construct was odd for a 
moment.

> - Variable names such as "x" and "f" aren't fabulously helpful to lost
> programmers trying to find their way.
> 

So don't use them? Though I think f in particular has its place in higher 
order functions.

> The people I
> spoke to also seemed pretty confused about the usage of (.) and ($), even
> after I explained it a few times. Several people also voiced being puzzled
> about Haskell's layout rules.
> 

Pointless style is definitely newbie-unfriendly. I can understand being 
puzzled by layout: ultimately I had to go read the description in the 
Report to be happy.

> I'm not sure what we *do* with all this data, but I found it interesting so I
> thought I'd share. ;-) I've spent the last few years trying to convert a few
> people to The Haskell Way(tm), but so far I haven't succeeded in the
> slightest. I just get yelled at for pointing white noise. Heh. Oh well!
> 

Have you tried showing people code that's been syntax highlighted? It's 
likely to help, especially with things like "does function application 
bind tighter?" where the highlighting is something of a cue. So is marking 
out = as important!

Btw, (> x) reads much more easily as a predicate to most people than (x 
<=).

-- 
flippa@flippac.org

Sometimes you gotta fight fire with fire. Most
of the time you just get burnt worse though.
From manlio_perillo at libero.it  Sun Sep 21 14:58:19 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Sun Sep 21 14:55:43 2008
Subject: [Haskell-cafe] broken link in documentation
Message-ID: <48D6994B.3030102@libero.it>

Hi.

Sorry if I use the mailing list for this, but in the documentation of 
Control.Monad.RWS (and the other Control.Monad.* modules), the link
http://www.cse.ogi.edu/~mpj/ is broken.


Manlio Perillo
From xs at xaph.net  Sun Sep 21 15:06:52 2008
From: xs at xaph.net (Rafal Kolanski)
Date: Sun Sep 21 15:04:27 2008
Subject: [Haskell-cafe] Drawing an existing image into a cairo surface?
In-Reply-To: <4165d3a70809210931w55831859m1687872071407a15@mail.gmail.com>
References: <48D63DF5.6070108@xaph.net> <1222000565-sup-844@existential.local>	
	<48D6458C.3020407@xaph.net> <48D64F72.2030703@xaph.net>	
	<188898053.20080921175520@gmail.com> <48D655AB.8040407@xaph.net>
	<4165d3a70809210931w55831859m1687872071407a15@mail.gmail.com>
Message-ID: <48D69B4C.4000304@xaph.net>



Jefferson Heard wrote:
> Sorry.  In a hurry, and I don't have a lot of time to read the
> message, so if I'm offering a lot of info you already have, I
> apologize.  The best thing to do is to allocate either a pixmap or
> Gtk.DrawingArea -- you can then use widgetGetDrawable to get the
> drawing context from it and newGC to take drawing context and get a
> graphics context.  After you have a drawing and graphics context, you
> can use drawPixbuf to draw or update any image you want, then use the
> same DrawngArea for Cairo after you've drawing the image.
> 
> If you need more help with it, let me know, and I can send some code
> that will do it later today.

I'd be very much interested, as I also want to load SVG files and my 
version of Gtk2Hs (Ubuntu Hardy) doesn't have 
Graphics.Rendering.Cairo.SVG ...

Your method can get around this problem I think.

Sincerely,

Rafal Kolanski.

From tanimoto at arizona.edu  Sun Sep 21 15:08:09 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Sun Sep 21 15:05:21 2008
Subject: [Haskell-cafe] Bird-style and blank lines
Message-ID: 

Hi,

I'm a big fan of literate haskell, especially Bird-style, but there's
one behavior that I find rather annoying: the requirement that code be
preceded and followed by a blank line.

Quoth the Report:
"To capture some cases where one omits an ">" by mistake, it is an
error for a program line to appear adjacent to a non-blank comment
line, where a line is taken as blank if it consists only of
whitespace."

While that is something I do anyway, since it looks better, there are
some cases where it would be nice to relax that.  For example:

1. I see a blog post in literate style, but the author did not provide
a .lhs file, sometimes copying and pasting the text will result in
code being adjacent to the text.  Then I have to fix that manually.

2. It would be nice for prototyping if you could quickly comment out
code just by removing a ">" character, instead of inserting "--".

3. Pandoc, via markdown, is a very interesting alternative to latex.
Right now you can write a block of code like this:

~~~
> fact :: Integer -> Integer
> fact 0 = 1
> fact n = n * fact (n-1)
~~~

except that that won't work, precisely because you must have a blank
line before and after the code.  Unfortunately, when you go and add
the blank lines, the output will show them.  You may tell me to change
what Pandoc does, but my point is that getting any markup to work with
Bird-style will have this issue.


The only argument I can see for keeping the requirement is what the
report says, but feel free to provide others [1].  However, isn't that
a bit like saying "we will require two semicolons because forgetting a
semicolon is the number one source of mistake for our programmers"?
Besides, I suspect most of us uses an editor with syntax highlighting
(vi, emacs, yi, etc), and then it's immediately obvious you forgot
something.

Would it be hard to change this behavior in GHC?  Is this open for
discussion for Haskell Prime?

Thanks,

Paulo

[1] I don't think it's that common to add a ">" by accident.
From andrewcoppin at btinternet.com  Sun Sep 21 15:10:33 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Sun Sep 21 15:07:39 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: 
References: <48D68F22.1090808@btinternet.com>
	
Message-ID: <48D69C29.3040902@btinternet.com>

Philippa Cowderoy wrote:
> On Sun, 21 Sep 2008, Andrew Coppin wrote:
>
>   
>> Actually, none of these things were mentioned. The things people have
>> *actually* complained to me about are:
>> - Haskell expressions are difficult to parse.
>>     
>
> This is partly an "it's not braces, semicolons and function(application)" 
> complaint, though not entirely.
>   

One person complained that "case compare guess target of" was unclear. 
Of course, you and I know that "case" and "of" are actually language 
keywords, and hence this is really "case (compare guess target) of", 
which makes far more sense. (Your suggestion about syntax hilighting is 
relevant here!)

>> - Several standard library functions have names which clash badly with the
>> usual meanings of those names - e.g., "break", "return", "id".
>>     
>
> For this one, I'm inclined to say "welcome to a new paradigm". Though 
> having to tell my dad briefly that do isn't a loop construct was odd for a 
> moment.
>   

Haha! Nice...

I think "return" is a rather bad choice of name. But on the other hand, 
I can't think of a better one. And let's face it, anything has to be 
better than (>>=). (Most cryptic name ever?)

>> - Variable names such as "x" and "f" aren't fabulously helpful to lost
>> programmers trying to find their way.
>>     
>
> So don't use them? Though I think f in particular has its place in higher 
> order functions.
>   

Idiomatic Haskell seems to consist *only* of single-letter variable 
names. When did you last see a pattern like (customer:customers)? No, 
it'd be (c:cs), which isn't very self-documenting. Ditto for type 
variables by the way. (Map k v, anyone?) It also seems to be Haskell 
convention to use "a" as a type variable; personally I always use "x". I 
guess that's the algebra in my blood or something...

>> The people I
>> spoke to also seemed pretty confused about the usage of (.) and ($), even
>> after I explained it a few times. Several people also voiced being puzzled
>> about Haskell's layout rules
>
> Pointless style is definitely newbie-unfriendly. I can understand being 
> puzzled by layout: ultimately I had to go read the description in the 
> Report to be happy.
>   

I posted a snippet of code which included the phrase

  mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip 
[0..] vs)

To somebody familiar with Haskell, that is as clear as day. But to a 
newbie... well *you* try explaining that you start at the left end, take 
the thing in brackets, process it from left to right, then take the 
other thing in brackets, process the right side of it, then pass that to 
putStrLn, oh, but that thing right at the left edge is the argument 
list, and then pass the whole lot to mapM_, which is... are you still 
with me??

As one experienced C++ programmer put it, "there is no clear flow from 
left to right or right to left". Personally I found that a little ironic 
comming from the language that gave us

  while (*x++ = *y++) { }

which is every bit as non-linear! ;-)

> Have you tried showing people code that's been syntax highlighted? It's 
> likely to help, especially with things like "does function application 
> bind tighter?" where the highlighting is something of a cue. So is marking 
> out = as important!
>   

I'd just like to mention that HPaste is invaluable here! ;-)

Oddly, nobody seemed to take much notice when I did this though. (I 
guess most people had seen "oh look, another Haskell thread" and hit the 
thread-kill button by that point...)

> Btw, (> x) reads much more easily as a predicate to most people than (x <=).
>   

Er, yeah, you're probably right. IIRC, (> x) is actually implemented as 
(flip (>) x), whereas (x <) isn't. I doubt there's any efficiency 
difference though. (Surely GHC would inline such a trivial function...)

From huschi at gmx.org  Sun Sep 21 15:11:22 2008
From: huschi at gmx.org (Martin Huschenbett)
Date: Sun Sep 21 15:08:34 2008
Subject: [Haskell-cafe] Updated formlets sample?
In-Reply-To: <20898DDF-5BF7-4FA1-8BAF-881D57C57CB8@eidhof.nl>
References: <48D3898B.5070904@gmx.org>
	<20898DDF-5BF7-4FA1-8BAF-881D57C57CB8@eidhof.nl>
Message-ID: <48D69C5A.2040505@gmx.org>

Hi Chris,

thanks for the updated example. Compiling works now. But when I try to 
run it I alway get error messages like

  ["input0 is not in the data","input1 is not in the data"]

Regards,

Martin.

Chris Eidhof schrieb:
> Hey Martin,
> 
> On 19 sep 2008, at 04:14, Martin Huschenbett wrote:
> 
>> I found a blog post concerning formlets [1] in the web. Since looks 
>> very interesting I tried to compile the sample code with recent 
>> versions of HAppS and formlets from hackage. But this didn't work as 
>> the API of formlets has changed since this post.
>>
>> I tried to adopt the code to the new API but I was unable to finish 
>> this since there is a new monadic context I don't know to handle in 
>> the right way.
>>
>> So my question is, is there an updated version of this sample code in 
>> the web or has anybody tried to adopt it and can send me the results?
> 
> 
> Yes, I'm sorry for that. The API is still very immature and due to 
> changes, that's also why it hasn't been officially announced yet. I've 
> just put an updated example at http://hpaste.org/10568, hope that'll 
> work for you. I guess we should build a small homepage / wikipage that 
> always has an up-to-date example.
> 
> -chris
From leather at cs.uu.nl  Sun Sep 21 15:21:58 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Sun Sep 21 15:19:13 2008
Subject: [Haskell-cafe] broken link in documentation
In-Reply-To: <48D6994B.3030102@libero.it>
References: <48D6994B.3030102@libero.it>
Message-ID: <3c6288ab0809211221r600fc5c1y1183ac0fa5a4dba8@mail.gmail.com>

> Sorry if I use the mailing list for this, but in the documentation of
> Control.Monad.RWS (and the other Control.Monad.* modules), the link
> http://www.cse.ogi.edu/~mpj/  is broken.
>

If you're trying to find the correct link, perhaps it's this:
http://web.cecs.pdx.edu/~mpj/

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080921/f0636184/attachment-0001.htm
From manlio_perillo at libero.it  Sun Sep 21 15:50:14 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Sun Sep 21 15:47:28 2008
Subject: [Haskell-cafe] broken link in documentation
In-Reply-To: <3c6288ab0809211221r600fc5c1y1183ac0fa5a4dba8@mail.gmail.com>
References: <48D6994B.3030102@libero.it>
	<3c6288ab0809211221r600fc5c1y1183ac0fa5a4dba8@mail.gmail.com>
Message-ID: <48D6A576.101@libero.it>

Sean Leather ha scritto:
> 
>     Sorry if I use the mailing list for this, but in the documentation
>     of Control.Monad.RWS (and the other Control.Monad.* modules), the link
>     http://www.cse.ogi.edu/~mpj/  is broken.
> 
> 
> If you're trying to find the correct link, perhaps it's this: 
> http://web.cecs.pdx.edu/~mpj/
>

Already found with Google, thanks.

By the way, there is another problem with the generated documentation.
Links like
http://haskell.org/ghc/docs/latest/html/libraries/base/GHC-Conc.html#v%3Aatomically

don't seems to work with Opera (I'm using version 9.52, on Linux).

With all other browsers I have used, it works.
But Opera have problems with the ':' character in the fragment.


> Sean


Manlio Perillo
From claus.reinke at talk21.com  Sun Sep 21 16:04:03 2008
From: claus.reinke at talk21.com (Claus Reinke)
Date: Sun Sep 21 16:01:22 2008
Subject: [Haskell-cafe] Line noise
References: <48D68F22.1090808@btinternet.com>
	<48D69C29.3040902@btinternet.com>
Message-ID: 

> I posted a snippet of code which included the phrase
> 
>  mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs)

"Don't do that, then"?-) 

 mapM_ putStrLn $
    map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) 
        (zip [0..] vs)
->
 mapM_ putStrLn $
    map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) 
        (addIndices vs)
    where addIndices vs = zip [0..] vs
->
 mapM_ putStrLn (map formatPair (addIndices vs))
    where { addIndices vs = zip [0..] vs;
                 formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v }
-> ...
 printList (map formatPair (addIndices vs))
    where { foreach :: [i] -> (i->IO ()) -> IO ();
                 foreach list action = mapM_ action list;

                 printList :: [String] -> IO ();
                 printList strings = foreach strings (\string->putStrLn string);

                 addIndices :: [x] -> [(Integer,x)];
                 addIndices vs = zip [0..] vs;

                 formatPair :: Show x => (Integer,x) -> String
                 formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v }

Add comments (or replace types with comments, if you don't
want to explain type classes), perhaps use an explicit loop instead 
of mapM_, add salt and pepper (or some more parens), check 
for correctness, etc.

Not as cute as the one-liner, but quite possibly easier to read
and explain. Haskell isn't APL - boldly break the line barrier,
if you want to be understood by non-Haskellers. Breaking 
stuff up into digestible pieces, and going more slowly than
necessary, might also help. Once your readers understand
your code, you can add the one-liner and ask for applause
(or show how to derive the one-liner from the long-hand
version if you want to motivate people to read about Haskell).

Just another opinion,
Claus

"Dr., it hurts when I do that."


From jgm at berkeley.edu  Sun Sep 21 16:33:05 2008
From: jgm at berkeley.edu (John MacFarlane)
Date: Sun Sep 21 16:30:11 2008
Subject: [Haskell-cafe] Re: Bird-style and blank lines
In-Reply-To: 
References: 
Message-ID: <20080921203305.GA3200@berkeley.edu>

> 3. Pandoc, via markdown, is a very interesting alternative to latex.
> Right now you can write a block of code like this:
> 
> ~~~
> > fact :: Integer -> Integer
> > fact 0 = 1
> > fact n = n * fact (n-1)
> ~~~
> 
> except that that won't work, precisely because you must have a blank
> line before and after the code.  Unfortunately, when you go and add
> the blank lines, the output will show them.

Note: I've changed pandoc in the repository so that it no longer
shows these blank lines. The next point release will incorporate this
change, making it easier to use pandoc for literate haskell. Note also
that if you begin the code block with

~~~ {.haskell}

the HTML output will be syntax-highlighted (assuming you compiled
pandoc with the -fhighlighting flag).

John

From mads_lindstroem at yahoo.dk  Sun Sep 21 16:30:08 2008
From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=)
Date: Sun Sep 21 16:37:55 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D69C29.3040902@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
	
	<48D69C29.3040902@btinternet.com>
Message-ID: <1222029008.4457.64.camel@localhost.localdomain>

Andrew Coppin wrote:

> Idiomatic Haskell seems to consist *only* of single-letter variable 
> names. When did you last see a pattern like (customer:customers)? No, 
> it'd be (c:cs), which isn't very self-documenting. Ditto for type 
> variables by the way. (Map k v, anyone?) It also seems to be Haskell 
> convention to use "a" as a type variable; personally I always use "x". I 
> guess that's the algebra in my blood or something...
> 

The more abstract (generic) thing gets, the less likely you will be able
to find a telling name. And if you cannot find a telling name, you can
just as well make it short. And as Haskell is more abstract, we get more
short identifiers. E.g. in your earlier sorting function:

  qsort (x:xs) = ...

what would you propose to call the elements? Yes, if it sorted
customers, you call 'em (customer:customers). But you have made a very
abstract sorting function, which sorts a lot besides customers. And then
you are bound to end up with a non-telling name.

However, I will grant you that Map k v, could have used longer type
variables. But we are not alone with using one letter type variable
names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And
frankly, in this specific case, I think most programmers (Haskell or
non-Haskell) will be able to guess what k and v means, when they are
standing right after Map.


Greetings,

Mads



From trebla at vex.net  Sun Sep 21 17:19:47 2008
From: trebla at vex.net (Albert Y. C. Lai)
Date: Sun Sep 21 17:17:00 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D68F22.1090808@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
Message-ID: <48D6BA73.8020008@vex.net>

I read from many reviews and shootouts that cell phones sold in Japan 
are more diverse, advanced, and user-friendly than cell phones sold in 
the US.

So I bought one, but to my dismay, both the offline manual and the 
on-screen menu are line noise.

Then I found a web dictionary to translate them word-for-word. The 
result is still unparsible, like "water submerge in don't ever". Are we 
supposed to be human beings or are we supposed to be all Master Yoda's?

Why and how the whole Japanese population put up with this epic fail is 
beyond me.

Everyone should use exclusively ancient Egyptian iconography. It is the 
only universally readable language.
From magnus at therning.org  Sun Sep 21 17:21:21 2008
From: magnus at therning.org (Magnus Therning)
Date: Sun Sep 21 17:18:33 2008
Subject: [Haskell-cafe] Parsing arguments and reading configuration
In-Reply-To: <86E2F023-C91D-4957-8960-E6521BA8467D@gmail.com>
References: <48D42693.8040507@therning.org>
	<694519c50809191735w178e66c2j101484d989a1da1a@mail.gmail.com>
	<694519c50809191739i3a931c21k26f7249bf879d8a7@mail.gmail.com>
	<86E2F023-C91D-4957-8960-E6521BA8467D@gmail.com>
Message-ID: 

On Sun, Sep 21, 2008 at 4:02 PM, Sterling Clover  wrote:
> Alternately, just go with a map initially with default values. Then parse
> the command line args into a second map (especially if they're all of a
> format like -argname argvalue). Then lookup your args file with the command
> line map, and failing that the default map. Then read the args file and
> finally merge all three maps in the proper order. No need for monoid
> instances, special data types or any of that, so at a little cost in
> elegance a much more succinct way to get what you want. As a final step, you
> can always project the map values into a record type, to get some safety for
> the rest of your program. The entire process, aside from creating the
> record, should probably be no more than four or so lines.

Yes, that's the direction I'll end up going in, I think.  The idea
with the monoid was nice, but I couldn't really turn it into a usable
idea in my head, since the whole idea with an entity turns out to be
somewhat strange.  At least in the way I look at arguments.  However,
the idea of using a product to "merge" to configurations is
interesting and I think I might explore it more when I find the time.
(So far I've only identified that I probably will have use for
template haskell once I decide to play more with it.)

Thanks for the help and suggestions offered on the list.

/M

-- 
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus?therning?org Jabber: magnus?therning?org
http://therning.org/magnus identi.ca|twitter: magthe
From tretriluxana.s at gmail.com  Sun Sep 21 17:37:49 2008
From: tretriluxana.s at gmail.com (Sukit Tretriluxana)
Date: Sun Sep 21 17:35:01 2008
Subject: [Haskell-cafe] Language.Haskell and strings
In-Reply-To: 
References: 
Message-ID: <8252533f0809211437s1d1b2ff4h3ae41f8527cc299b@mail.gmail.com>

I'm not a Haskell expert but here the solution to your problem that I can
think of.

import Data.List

prettyStr :: Int -> String -> IO ()
prettyStr maxlen str = do
   putStr ("\"" ++ head brokenStr)
   mapM_ (\str -> putStr ("\\\n\\" ++ str)) (tail brokenStr)
   putStr "\"\n"
   where brokenStr = map (snd.unzip) $ groupBy (\_ (i,_) -> i `mod` maxlen
/= 0) $ zip [0..] str

Ed

On Sat, Sep 20, 2008 at 4:14 PM, Maur??cio  wrote:

> Hi,
>
> I'm using Language.Haskell.* and would
> like to know if it's possible to
> pretty-print big strings like this:
>
> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
>
> into something like this:
>
> "aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa"
>
> to respect the limit on number of
> columns. Can you help me? Is it
> possible to do that?
>
> Thanks,
> Maur?cio
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080921/8a7f7a1d/attachment.htm
From ok at cs.otago.ac.nz  Sun Sep 21 20:31:02 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Sun Sep 21 20:28:16 2008
Subject: [Haskell-cafe] [m..n] question
Message-ID: 

Erlang's equivalent of [m..n] is lists:seq(M, N),
which is currently defined to raise an exception when N < M.
In particular, lists:seq(1, N) returns a list of length N
when N > 0, but not when N = 0.
I'm currently arguing that lists:seq(1, 0) should be [],
not an exception.  Oddly enough, I'm being beaten over the
head with Haskell, of all things.

In Haskell,
"The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3].
  The list is empty if e1 > e3."

It is being claimed that the reason for this is that "exceptions
are problematic" in Hasell, so the Haskell designers went out of
their way to make this function total whether it made sense or not.

I am currently suggesting that it's to keep the specification
(for integers) simple:
"[m..n] is the set of integers x such that m<=x<=n,
  listed in ascending order".
There's also the nice equivalence between
[m..n] and takeWhile (<= n) [m..].
Unfortunately, no such "abstract" characterisation of [m..n] is
mentioned in the report, and the takeWhile connection is
inferred from numericEnumFromTo.

Does anyone remember why the definition of enumFromTo is the way it is?

--
If stupidity were a crime, who'd 'scape hanging?







From ajb at spamcop.net  Sun Sep 21 21:00:24 2008
From: ajb at spamcop.net (ajb@spamcop.net)
Date: Sun Sep 21 20:57:37 2008
Subject: [Haskell-cafe] [m..n] question
In-Reply-To: 
References: 
Message-ID: <20080921210024.iwfqen3n4ock4o08-nwo@webmail.spamcop.net>

G'day all.

Quoting "Richard A. O'Keefe" :

> I'm currently arguing that lists:seq(1, 0) should be [],
> not an exception.  Oddly enough, I'm being beaten over the
> head with Haskell, of all things.
[...]
> Does anyone remember why the definition of enumFromTo is the way it is?

I don't know if this is the reason, but there's another nice property
that enumerations have, namely:

     [p..q-1] ++ [q..r-1] == [p..r-1]  -- if p <= q <= r

If you think of the abstract semantics of ranges, this makes perfect
sense.  There needs to be a notation for empty ranges.

Having said that, I don't know of a good reason why [5,5..5] is an
infinte list of 5's.

Cheers,
Andrew Bromage
From briqueabraque at yahoo.com  Sun Sep 21 21:06:17 2008
From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=)
Date: Sun Sep 21 21:03:43 2008
Subject: [Haskell-cafe] Re: Language.Haskell and strings
In-Reply-To: <8252533f0809211437s1d1b2ff4h3ae41f8527cc299b@mail.gmail.com>
References: 
	<8252533f0809211437s1d1b2ff4h3ae41f8527cc299b@mail.gmail.com>
Message-ID: 

Ed, thanks for your code. However,
I need to use something that fits
inside the whole pretty-print engine.
I would like to call parseModule
in some string of Haskell code and
get it nicely typed, with those big
strings inside.

Best,
Maur?cio

> I'm not a Haskell expert but here the solution to your problem that I 
> can think of.
> 
> import Data.List
> 
> prettyStr :: Int -> String -> IO ()
> prettyStr maxlen str = do
>    putStr ("\"" ++ head brokenStr)
>    mapM_ (\str -> putStr ("\\\n\\" ++ str)) (tail brokenStr)
>    putStr "\"\n"
>    where brokenStr = map (snd.unzip) $ groupBy (\_ (i,_) -> i `mod` 
> maxlen /= 0) $ zip [0..] str
> 
> Ed
> 
> On Sat, Sep 20, 2008 at 4:14 PM, Maur??cio  > wrote:
> 
>     Hi,
> 
>     I'm using Language.Haskell.* and would
>     like to know if it's possible to
>     pretty-print big strings like this:
> 
>     "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
> 
>     into something like this:
> 
>     "aaaaaaaa\
>     \aaaaaaaa\
>     \aaaaaaaa\
>     \aaaaaaaa\
>     \aaaaaaaa\
>     \aaaaaaaa\
>     \aaaaaaaa"
> 
>     to respect the limit on number of
>     columns. Can you help me? Is it
>     possible to do that?
> 
>     Thanks,
>     Maur?cio
> 
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe@haskell.org 
>     http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From s.clover at gmail.com  Sun Sep 21 21:46:04 2008
From: s.clover at gmail.com (Sterling Clover)
Date: Sun Sep 21 21:41:17 2008
Subject: [Haskell-cafe] Language.Haskell and strings
In-Reply-To: <8252533f0809211437s1d1b2ff4h3ae41f8527cc299b@mail.gmail.com>
References: 
	<8252533f0809211437s1d1b2ff4h3ae41f8527cc299b@mail.gmail.com>
Message-ID: <19C9F585-7A27-450F-BD1F-09EFAFC428C7@gmail.com>

A quick glance at the code reveals that there's an instance of Pretty  
like such:

instance Pretty HsLiteral where
	pretty (HsInt i)        = integer i
	pretty (HsChar c)       = text (show c)
	pretty (HsString s)     = text (show s)
	pretty (HsFrac r)       = double (fromRational r)

That HsString instance is wrong for what you want, but there doesn't  
seem any way to simply override it. It should, however, be easy  
enough to add a further postprocessing layer to your already pretty- 
printed text, looking line by line for those lines that are a) too  
long and b) contain a very large quoted string. This layer could  
fairly easily do something reasonable to break the string up.  
Alternately, you could write a preprocessing layer that walked the  
source tree directly and chunked all HsStrings over a certain length  
into "aaaa" ++ "aaaa" ++ "aaaa", etc. At which point, the pretty  
printer could then decide how to distribute them properly across  
lines. Neither would be as perfect a solution as integrating with the  
pretty printer directly, but both would be helpful, and the latter  
could probably even be a one or two liner with an appropriate use of  
SYB.

--Sterl


On Sep 21, 2008, at 5:37 PM, Sukit Tretriluxana wrote:

> Data.List
>
> prettyStr :: Int -> String -> IO ()
> prettyStr maxlen str = do
>    putStr ("\"" ++ head brokenStr)
>    mapM_ (\str -> putStr ("\\\n\\" ++ str)) (tail brokenStr)
>    putStr "\"\n"
>    where brokenStr = map (snd.unzip) $ groupBy (\_ (i,_) -> i `mod`  
> maxlen /= 0) $ zip [0..] str
>
> Ed
>
> On Sat, Sep 20, 2008 at 4:14 PM, Maur? cio  
>  wrote:
> Hi,
>
> I'm using Language.Haskell.* and would
> like to know if it's possible to
> pretty-print big strings like this:
>
> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
>
> into something like this:
>
> "aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\
> \aaaaaaaa\

From qdunkan at gmail.com  Sun Sep 21 21:51:24 2008
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun Sep 21 21:48:36 2008
Subject: [Haskell-cafe] [m..n] question
In-Reply-To: 
References: 
Message-ID: <2518b95d0809211851t8a8c03arfedaa4717dfcb0b7@mail.gmail.com>

> In Haskell,
> "The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3].
>  The list is empty if e1 > e3."

I like it, since it means that things like [n .. n + length m - 1]
work as expected when m is [].  Or say 'map (array!) [bsearch x ..
bsearch y - 1]'.

Tangent:  Of course, I would prefer the range be half-open, which is a
pretty consistent standard in the rest of the world.  I've had a
number of off by one errors from this, and from Array.bounds.  I guess
it's too late to fix those, though, even if there were agreement that
they need to be fixed.

This is similar to the way python considers that xs[4:2] is valid, and
is [].  Of course python uses half-open ranges so xs[4:4] is still [].
From wren at freegeek.org  Sun Sep 21 22:49:19 2008
From: wren at freegeek.org (wren ng thornton)
Date: Sun Sep 21 22:46:31 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D68F22.1090808@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
Message-ID: <48D707AF.100@freegeek.org>

Andrew Coppin wrote:
> I hang out on another forum that is populated by various kinds of 
> computer geeks. There's a fair few programmers in there, as well as 
> nerds of every degree. And yet, every time I post anything written in 
> Haskell, everybody complains that it "looks like line noise".
> 
> Actually, none of these things were mentioned. The things people have 
> *actually* complained to me about are:
> - Haskell expressions are difficult to parse.

To anyone who doesn't know the language, this seems quite true. Haskell 
was designed with a hyper-minimalist syntax, whereas C/C++/Java are very 
heavy with syntactic boilerplate. I am a devout fan of the minimalism, 
but it is something of a barrier to entry for those unwilling to 
consider anything that doesn't look familiar.

We inherited our use of spaces for function application from Lisp and 
friends, so "foo bar baz" looks perfectly natural to functionalists. But 
to those used to seeing "foo(bar, baz)" the meaning attached to the 
spaces is alien. The 'difference' in meaning for the two spaces only 
drives the alienness home, since (ubiquitous) currying is not well known 
or practiced outside of Haskell. Even with functionalists ---of the 
OCaml and SML ilk--- this use of spaces can be confusing if noone 
explains that function application binds tighter than all operators.

Similarly, we use linebreaks to denote various things whereas the 
syntax-heavy languages require a semicolon or similar delimiter. We are 
in fortuitous arms here since we can use the redundant {;} notation to 
sell new folks. Though it is wise to use the notation with the semicolon 
trailing on the previous line:

     do {
         foo;
         bar;
         baz;
     }

rather than the more idiomatic leading version:

     do { foo
        ; bar
        ; baz
        }

Again, the minimalist version that omits the {;} which lends a meaning 
to whitespace that syntax-heavy users are not familiar with. Here I 
think is largely a question of knowing your audience; the explicit 
version is better for any audience with many non-Haskell folks, even if 
it's a functional audience.

We also allow for omitting parentheses in many places required by other 
languages. In particular, the case...of construct mentioned previously. 
The if...then...else construct can have similar problems, though they 
are more easily overlooked by foreigners. Again this is easy to correct 
for when talking with outsiders: just add redundant parentheses.

The meaning of = and how it differs from -> are also quite subtle. 
Pattern matching and guards, like currying, are concepts that are quite 
alien to users of most other languages. The simplicity of their syntax 
in Haskell probably serves to further confuse questions of the syntax 
associated with =. I know from experience that these simple ideas can be 
a tough sale. Few languages have the notion that defining a function is 
the same as any other 'assignment' and so most languages have radically 
different syntaxes for the two. This trait of treating functions as 
first-class citizens tends to have large brain-breaking capabilities-- 
moreso than passing functions as arguments, it seems.


All of these are just basic things about Haskell's syntax and have 
nothing to do with all the interesting higher-order stuff which is 
really novel. It is unfortunate that there are so many people, 
intelligent people even, who are so hidebound as to be unwilling to 
gloss over syntax, but sadly it is the way of things. To be fair to 
them, the meanings assigned to whitespaces are not the sort of thing 
which is trivial to intuit. Perhaps we need a _Guide to Reading Haskell 
(for non-Haskell Programmers)_?

-- 
Live well,
~wren
From dpiponi at gmail.com  Sun Sep 21 23:00:39 2008
From: dpiponi at gmail.com (Dan Piponi)
Date: Sun Sep 21 22:57:49 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D707AF.100@freegeek.org>
References: <48D68F22.1090808@btinternet.com> <48D707AF.100@freegeek.org>
Message-ID: <625b74080809212000u5b77f82fwc7f777b364f23907@mail.gmail.com>

On Sun, Sep 21, 2008 at 7:49 PM, wren ng thornton  wrote:
> We inherited our use of spaces for function application from Lisp and
> friends, so "foo bar baz" looks perfectly natural to functionalists. But to
> those used to seeing "foo(bar, baz)" the meaning attached to the spaces is
> alien.

I have to admit, it took me a long time to be able to parse the
ML-style function notation in Haskell. I found it the biggest "barrier
to entry". I suspect that most of the complaints about line noise stem
from this - to beginners Haskell expressions just look like sequences
of identifiers with no apparent grammar to "bind" them together.
--
Dan
From wren at freegeek.org  Sun Sep 21 23:02:41 2008
From: wren at freegeek.org (wren ng thornton)
Date: Sun Sep 21 22:59:53 2008
Subject: [Haskell-cafe] Bird-style and blank lines
In-Reply-To: 
References: 
Message-ID: <48D70AD1.8030403@freegeek.org>

Paulo Tanimoto wrote:
> [1] I don't think it's that common to add a ">" by accident.

By intention, probably. But by accident it is a lot more common than you 
might think. Accidents like corrupting the linebreaks or line wrapping 
in a file are quite prevalent when exchanging files across different 
platforms or medium formats. Consider also file type misdetection with 
other languages like HTML; or more convincingly, consider language 
interleaving. And there're always garden variety typos like dropping a 
bird track or adding a space before it.

Usually such corruption is easily captured by code not compiling, but I 
think the big thing to consider when suggesting changes to the .lhs 
format is how it affects the robustness of detecting file corruption, 
typos, etc. The whitespace restriction captures a goodly number of typos 
mentioned above, though it may not be so helpful for the other corruptions.

-- 
Live well,
~wren
From wren at freegeek.org  Sun Sep 21 23:17:05 2008
From: wren at freegeek.org (wren ng thornton)
Date: Sun Sep 21 23:14:16 2008
Subject: [Haskell-cafe] [m..n] question
In-Reply-To: <20080921210024.iwfqen3n4ock4o08-nwo@webmail.spamcop.net>
References: 
	<20080921210024.iwfqen3n4ock4o08-nwo@webmail.spamcop.net>
Message-ID: <48D70E31.7090201@freegeek.org>

ajb@spamcop.net wrote:
> Having said that, I don't know of a good reason why [5,5..5] is an
> infinte list of 5's.

I'm sure you know *why* it's an infinite list[1], but as for why that's 
useful I can't say. It has the feel of a bug in implementation, though 
it is ...consistent.

As for the OP, like Python, Perl also takes [m..n] to be [] when n < m. 
They may not be as principled as Haskell or Erlang, but it does seem to 
be the consensus view.


[1] Because the "5,5.." yields an (unfoldr (Just . (\x -> (x,x)) . (+0)) 
5) stream but the "..5" only causes termination just as soon as the 
stream is surpassing 5, which it never will.

-- 
Live well,
~wren
From ajb at spamcop.net  Sun Sep 21 23:35:44 2008
From: ajb at spamcop.net (ajb@spamcop.net)
Date: Sun Sep 21 23:32:56 2008
Subject: [Haskell-cafe] [m..n] question
In-Reply-To: <48D70E31.7090201@freegeek.org>
References: 
	<20080921210024.iwfqen3n4ock4o08-nwo@webmail.spamcop.net>
	<48D70E31.7090201@freegeek.org>
Message-ID: <20080921233544.yz386wcsgw4wc4sg-nwo@webmail.spamcop.net>

G'day.

Quoting wren ng thornton :

> I'm sure you know *why* it's an infinite list[1], but as for why that's
> useful I can't say. It has the feel of a bug in implementation, though
> it is ...consistent.

Right.  I have no problem with [5,5..5] being logically an anamorphism,
but thinking abstractly about what I'd want it to mean, I'm pretty sure
I don't want it to mean an infinite list of 5's.

I asked a class of about a dozen bright undergrads about 10 years ago
what they thought it should mean, and IIRC the consensus seemed to be
split between [5] and [5,5].  Nobody correctly guessed what it actually
did.  So whether the behaviour is technically right or wrong, it violates
the Principle of Least Surprise.

Cheers,
Andrew Bromage
From tanimoto at arizona.edu  Mon Sep 22 00:07:01 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Mon Sep 22 00:04:14 2008
Subject: [Haskell-cafe] Re: Bird-style and blank lines
In-Reply-To: <20080921203305.GA3200@berkeley.edu>
References: 
	<20080921203305.GA3200@berkeley.edu>
Message-ID: 

Hi John,

On Sun, Sep 21, 2008 at 3:33 PM, John MacFarlane  wrote:
> Note: I've changed pandoc in the repository so that it no longer
> shows these blank lines. The next point release will incorporate this
> change, making it easier to use pandoc for literate haskell. Note also
> that if you begin the code block with
>
> ~~~ {.haskell}
>
> the HTML output will be syntax-highlighted (assuming you compiled
> pandoc with the -fhighlighting flag).

Thank you for taking care of that for us.  I can check this in the
code, but does this apply only to (leading and trailing) blank lines
for haskell?  I like the idea of automatically highlighting if it's
available, it's working very well here.

Paulo
From tanimoto at arizona.edu  Mon Sep 22 00:27:53 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Mon Sep 22 00:25:06 2008
Subject: [Haskell-cafe] Bird-style and blank lines
In-Reply-To: <48D70AD1.8030403@freegeek.org>
References: 
	<48D70AD1.8030403@freegeek.org>
Message-ID: 

Hello Wren,

On Sun, Sep 21, 2008 at 10:02 PM, wren ng thornton  wrote:
> By intention, probably. But by accident it is a lot more common than you
> might think. Accidents like corrupting the linebreaks or line wrapping in a
> file are quite prevalent when exchanging files across different platforms or
> medium formats. Consider also file type misdetection with other languages
> like HTML; or more convincingly, consider language interleaving. And
> there're always garden variety typos like dropping a bird track or adding a
> space before it.
>
> Usually such corruption is easily captured by code not compiling, but I
> think the big thing to consider when suggesting changes to the .lhs format
> is how it affects the robustness of detecting file corruption, typos, etc.
> The whitespace restriction captures a goodly number of typos mentioned
> above, though it may not be so helpful for the other corruptions.

Thanks for your thoughts.  I see your point and I agree it's an
important one.  For example, as you well know, if you produce HTML
with our Haskell libraries, there's some good chance you'll end up
with a ">" mark in the beginning of the line, because of the way the
tags are written.

However, that's HTML.  If you decide to interleave with other
languages, I don't think the probability of having a ">" unexpectedly
showing up in the beginning of the line is enough to justify making
this a rule.

In most languages it would be like writing a condition very close to
the end of the line and having it break in the middle:

                                             if (x
> y)

I think the restriction made sense when the report was written, but
what I'm arguing is that given new developments we have made, the
benefits of lifting the restriction are greater than keeping it.  At
least for me!  : )  To be sure, I'm weighting the chances that the
mandatory blank lines will save you versus the possibility of writing
in Bird-style more freely.

Again, please do point out other flaws in my argument.

Thanks,

Paulo
From donn at avvanta.com  Mon Sep 22 01:05:24 2008
From: donn at avvanta.com (donn cave)
Date: Mon Sep 22 01:02:12 2008
Subject: [Haskell-cafe] Line noise
References: <48D68F22.1090808@btinternet.com>
	
	<48D69C29.3040902@btinternet.com>
Message-ID: <20080922050524.AE664276C42@mail.avvanta.com>

Quoth Andrew Coppin :
...
| As one experienced C++ programmer put it, "there is no clear flow from 
| left to right or right to left". Personally I found that a little ironic 
| comming from the language that gave us
|
|   while (*x++ = *y++) { }
|
| which is every bit as non-linear! ;-)

Well, to be precise, C++ got that from C.  What C++ adds to it:

   fy(a.fx(b), c)  (in Haskell,  fy (fx a b) c)

I wouldn't worry too much about one letter identifiers and so forth.
Many programmers will secretly be rather attracted to this kind of thing.

	Donn Cave, donn@avvanta.com
From ok at cs.otago.ac.nz  Mon Sep 22 01:05:19 2008
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon Sep 22 01:02:39 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <22700_1222032006_m8LLK44s003388_48D6BA73.8020008@vex.net>
References: <48D68F22.1090808@btinternet.com>
	<22700_1222032006_m8LLK44s003388_48D6BA73.8020008@vex.net>
Message-ID: 


On 22 Sep 2008, at 9:19 am, Albert Y. C. Lai wrote:
> Everyone should use exclusively ancient Egyptian iconography. It is  
> the only universally readable language.

I know this was full of (:-) (:-),
but it seems like the perfect chance to mention Blissymbols.
http://unicode.org/roadmaps/smp/smp-4-14.html (the Unicode SMP road map)
has a link to a proposal for adding them to Unicode,
and they _are_ in active use...

(A Haskell program in Blissymbols would be, well, bigger.)

From dons at galois.com  Mon Sep 22 01:27:12 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 01:24:17 2008
Subject: [Haskell-cafe] Climbing up the shootout...
Message-ID: <20080922052712.GB24712@scytale.galois.com>

Thanks to those guys who've submitted parallel programs to the language
benchmarks game, we're climbing up the rankings, now in 3rd, and ahead
of C :)

    http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all

Just one or two more parallel programs required...

Submit them here, and we can test on quad core,

    http://haskell.org/haskellwiki/Shootout/Parallel

-- Don
From andrewcoppin at btinternet.com  Mon Sep 22 02:27:54 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Mon Sep 22 02:25:01 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <625b74080809212000u5b77f82fwc7f777b364f23907@mail.gmail.com>
References: <48D68F22.1090808@btinternet.com> <48D707AF.100@freegeek.org>
	<625b74080809212000u5b77f82fwc7f777b364f23907@mail.gmail.com>
Message-ID: <48D73AEA.4010701@btinternet.com>

Dan Piponi wrote:
> I suspect that most of the complaints about line noise stem
> from this - to beginners Haskell expressions just look like sequences
> of identifiers with no apparent grammar to "bind" them together.
>   

This was the exact complaint that some people voiced, yes. (The (.) and 
($) operators just compound the problem.)

Somebody else then came to my rescue and pointed out that "everybody 
says Lisp is unreadable because it has too many brackets - despite the 
fact that those brackets theoretically make parsing utterly trivial". ;-)

From andrewcoppin at btinternet.com  Mon Sep 22 02:32:57 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Mon Sep 22 02:30:01 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <1222029008.4457.64.camel@localhost.localdomain>
References: <48D68F22.1090808@btinternet.com>		<48D69C29.3040902@btinternet.com>
	<1222029008.4457.64.camel@localhost.localdomain>
Message-ID: <48D73C19.6010801@btinternet.com>

Mads Lindstr?m wrote:
> Andrew Coppin wrote:
>
>   
>> Idiomatic Haskell seems to consist *only* of single-letter variable 
>> names.
>>     
>
> The more abstract (generic) thing gets, the less likely you will be able
> to find a telling name. And if you cannot find a telling name, you can
> just as well make it short. And as Haskell is more abstract, we get more
> short identifiers. E.g. in your earlier sorting function:
>
>   qsort (x:xs) = ...
>
> what would you propose to call the elements?

Well, qsort (element : list) would be maximally intuitive, but who's 
going to implement it like that? ;-)

Now of course in C, you'd be forced to write something like

  list qsort(int x, list xs)

which makes it completely unambiguous what these things are - what their 
type is. But in Haskell, even if you add a type signature:

  qsort:: (Ord x) => [x] -> [x]

Nobody is going to realise that "[x]" means a list. And it's still not 
clear where ":" comes from, or... well you can see why people are 
getting lost! ;-)

> However, I will grant you that Map k v, could have used longer type
> variables. But we are not alone with using one letter type variable
> names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And
> frankly, in this specific case, I think most programmers (Haskell or
> non-Haskell) will be able to guess what k and v means, when they are
> standing right after Map.
>   

Only if you can figure out that "Map" means what every other programming 
language on the face of the Earth calls a "dictionary". (This took me a 
while!)

From andrewcoppin at btinternet.com  Mon Sep 22 02:34:43 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Mon Sep 22 02:31:48 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080922052712.GB24712@scytale.galois.com>
References: <20080922052712.GB24712@scytale.galois.com>
Message-ID: <48D73C83.10704@btinternet.com>

Don Stewart wrote:
> Thanks to those guys who've submitted parallel programs to the language
> benchmarks game, we're climbing up the rankings, now in 3rd, and ahead
> of C :)
>
>     http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all
>   

Yay! This makes me very happy. ;-)

From mailing_list at istitutocolli.org  Mon Sep 22 02:49:03 2008
From: mailing_list at istitutocolli.org (Andrea Rossato)
Date: Mon Sep 22 02:46:27 2008
Subject: [Haskell-cafe] ANNOUNCE: citeproc-hs, a Haskell implementation
	of the Citation Style Language designed for Pandoc
In-Reply-To: 
References: <20080913173305.GB23265@Andrea.Nowhere.net>
	
Message-ID: <20080922064903.GA26358@Andrea.Nowhere.net>

Hi Gwern,

On Fri, Sep 19, 2008 at 09:01:46PM -0400, Gwern Branwen wrote:
> Hi Andrea. So I was looking at the README. Does citeproc-hs only
> support adding refs from a .xml file when one's written in Pandoc
> markdown? That is, I don't see how I could take a .lhs file and a .bib
> file and produce one of the Pandoc-supported outputs. In particular,
> I'd really like to be able to go .lhs -> .wiki, with refs; this would
> let me convert The Monad Reader articles for haskell.org.

as far as I remember Pandoc can deal with literate Haskell. Check here:
http://groups.google.com/group/pandoc-discuss/t/aaaf768ab730192

for bibtex databases, you can use Bibutils (check the citeproc-hs
homepage for a link): bibutils is a set of utilities for converting
from/to MODS to/from many different bibliographic databases.

As you know, Pandoc has a mediawiki writer, so, you should be able to
use extended markdown with referecnes to produce articles for the
wiki.

Keep in mind that pandoc latex reader doesn't use citeproc-hs (yet,
I'd like to add).

Andrea
From deduktionstheorem at web.de  Mon Sep 22 04:46:11 2008
From: deduktionstheorem at web.de (Stephan Friedrichs)
Date: Mon Sep 22 04:43:26 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D68F22.1090808@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
Message-ID: <48D75B53.2030308@web.de>

Andrew Coppin wrote:
> [...]
> - Variable names such as "x" and "f" aren't fabulously helpful to lost
> programmers trying to find their way.

I'm not a fan of cryptic variable names, either, and I try to use
descriptive names wherever I can. But in Haskell...

 - ... you often have variables, which have a scope of far less than a
   line such as in "map (\(x, (_, y)) -> (x, y) ..." (cleaning
   intermediate results from a list).

 - ... things often get very abstract, so that it just feels wrong
   matching on, say, (socket:sockets) instead of (x:xs).

> 
> [...]
> 

//Stephan

-- 

Fr?her hie? es ja: Ich denke, also bin ich.
Heute wei? man: Es geht auch so.

 - Dieter Nuhr
From lemming at henning-thielemann.de  Mon Sep 22 05:24:20 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon Sep 22 05:22:03 2008
Subject: [Haskell-cafe] readFile and closing a file
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3A06@ELON17P32001A.csfb.cs-group.com>
References: 
	<33A3F585590A6F4E81E3D45AA4A111C902CD3A06@ELON17P32001A.csfb.cs-group.com>
Message-ID: 


On Wed, 17 Sep 2008, Mitchell, Neil wrote:

> I tend to use openFile, hGetContents, hClose - your initial readFile
> like call should be openFile/hGetContents, which gives you a lazy
> stream, and on a parse error call hClose.

I could use a function like
   withReadFile :: FilePath -> (Handle -> IO a) -> IO a
   withReadFile name action = bracket openFile hClose ...

Then, if 'action' fails, the file can be properly closed. However, there 
is still a problem: Say, 'action' is a parser which produces a data 
structure lazily. Then further processing of that data structure of type 
'a' may again stop before completing the whole structure, which would also 
leave the file open. We have to force users to do all processing within 
'action' and to only return strict values. But how to do this?
From jon.fairbairn at cl.cam.ac.uk  Mon Sep 22 05:46:40 2008
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Mon Sep 22 05:44:08 2008
Subject: [Haskell-cafe] Re: [m..n] question
References: 
Message-ID: 

"Richard A. O'Keefe"  writes:

> Erlang's equivalent of [m..n] is lists:seq(M, N),
> which is currently defined to raise an exception when N < M.
> In particular, lists:seq(1, N) returns a list of length N
> when N > 0, but not when N = 0.
> I'm currently arguing that lists:seq(1, 0) should be [],
> not an exception.  Oddly enough, I'm being beaten over the
> head with Haskell, of all things.
>
> In Haskell,
> "The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3].
>  The list is empty if e1 > e3."
>
> It is being claimed that the reason for this is that "exceptions
> are problematic" in Hasell, so the Haskell designers went out of
> their way to make this function total whether it made sense or not.

I'm pretty sure that's not true.  I'd like to be able to say
"I know, I was there", but although I was there it was so
long ago that my memory isn't clear.  But it's clearly the
case that [5 .. 6] is [5, 6] (length 2) and [5 .. 5] has to
be [5] (length 1), so it's not unreasonable to expect that
[5, 4] be [] (length 0) -- having the induction extend down
to there makes most sense.  I'm fairly certain it was
arguments about induction and what constituted sensible
behaviour rather than our admitted dislike for exceptions
that carried the argument.



-- 
J?n Fairbairn                                 Jon.Fairbairn@cl.cam.ac.uk


From manlio_perillo at libero.it  Mon Sep 22 05:46:55 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Mon Sep 22 05:44:19 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080922052712.GB24712@scytale.galois.com>
References: <20080922052712.GB24712@scytale.galois.com>
Message-ID: <48D7698F.8040902@libero.it>

Don Stewart ha scritto:
> Thanks to those guys who've submitted parallel programs to the language
> benchmarks game, we're climbing up the rankings, now in 3rd, and ahead
> of C :)
> 

This is cheating, IMHO.
Some test comparisons are unfair.

The first problem is with the thread-ring benchmark.
Haskell uses the "concurrent Haskell" extension, but all other programs 
(with some exceptions) uses OS threads.
This is unfair, as an example a C program can make use of the GNU 
threads library, for user space threads), but there is no such program.

If I remove the thread-ring bench, then Haskell goes sixth, after Java 
and OCaml.


With parallel programs it is the same: other languages does not have a 
parallel version.

 > [...]


Manlio Perillo
From tom.davie at gmail.com  Mon Sep 22 05:55:36 2008
From: tom.davie at gmail.com (Thomas Davie)
Date: Mon Sep 22 05:52:50 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <48D7698F.8040902@libero.it>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it>
Message-ID: 


On 22 Sep 2008, at 11:46, Manlio Perillo wrote:

> Don Stewart ha scritto:
>> Thanks to those guys who've submitted parallel programs to the  
>> language
>> benchmarks game, we're climbing up the rankings, now in 3rd, and  
>> ahead
>> of C :)
>
> This is cheating, IMHO.
> Some test comparisons are unfair.
>
> The first problem is with the thread-ring benchmark.
> Haskell uses the "concurrent Haskell" extension, but all other  
> programs (with some exceptions) uses OS threads.
> This is unfair, as an example a C program can make use of the GNU  
> threads library, for user space threads), but there is no such  
> program.

Who said that C *had* to use OS threads?  The point of the shootout is  
to show the relative strengths of the various languages, one of the  
strengths of Haskell is some excellent lightweight thread support,  
this is not present in C, so C does badly on the tests that check how  
well you can deal with small threads.

> With parallel programs it is the same: other languages does not have  
> a parallel version.

Yes, and the new benchmarks are *specifically* designed to test how  
fast programs are on more recent multi-core hardware, so again, the  
other languages are welcome to submit parallel versions... It just  
turns out that Haskell is pretty damn good at doing parallelism.

Bob
From ketil at malde.org  Mon Sep 22 06:46:20 2008
From: ketil at malde.org (Ketil Malde)
Date: Mon Sep 22 06:40:41 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D73C19.6010801@btinternet.com> (Andrew Coppin's message of
	"Mon\, 22 Sep 2008 07\:32\:57 +0100")
References: <48D68F22.1090808@btinternet.com>
	
	<48D69C29.3040902@btinternet.com>
	<1222029008.4457.64.camel@localhost.localdomain>
	<48D73C19.6010801@btinternet.com>
Message-ID: <87od2gfog3.fsf@malde.org>

Andrew Coppin  writes:

>>> Idiomatic Haskell seems to consist *only* of single-letter variable
>>> names.

Good thing, too.

> Well, qsort (element : list) would be maximally intuitive, but who's
> going to implement it like that? ;-)

Why not listElement : restOfList ?

The rationale for having long names is that you have too many names,
and too large a scope to keep track of them all in your head.  Needing
long names is a symptom that your code is too complex, and that you
should refactor it.

The other problem with "descriptive" names is that it is not
automatically checked by the compiler, and thus it often ends up being
misleading.  Incorrect documentation is worse than no documentation.

>  qsort:: (Ord x) => [x] -> [x]
>
> Nobody is going to realise that "[x]" means a list.

And C is utterly incomprehensible, since from my Pascal background, I
just *know* that curly braces denote comments.  Come on, expecting
somebody to understand a language without an extremely basic
understanding of fundamental syntactical constructs is futile.

> well you can see why people are getting lost! ;-)

Yes, by refusing to adapt to any syntax but the single one they know.

> Only if you can figure out that "Map" means what every other
> programming language on the face of the Earth calls a
> "dictionary". (This took me a while!)

Except for where it is called an "associative array" or "hash table"?
Terminology is inconsistent, Haskell happens to draw more of it from
math than from other programming languages.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
From haskell at list.mightyreason.com  Mon Sep 22 06:48:16 2008
From: haskell at list.mightyreason.com (Chris Kuklewicz)
Date: Mon Sep 22 06:45:47 2008
Subject: [Haskell-cafe] Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is
	ready
In-Reply-To: <20080921165752.GA19677@matrix.chaos.earth.li>
References: <48D53BBA.10101@list.mightyreason.com>
	<20080920180915.GB18629@scytale.galois.com>
	<48D64DE8.90602@dtek.chalmers.se>
	<48D650A9.2080507@dtek.chalmers.se>
	<48D6784D.7070101@list.mightyreason.com>
	<20080921165752.GA19677@matrix.chaos.earth.li>
Message-ID: <48D777F0.7060907@list.mightyreason.com>

I am cross-posting this message to several lists.

I had learned the trick before the documentation was updated.  It seems I have 
used a very unreliable trick.  And the "use castToSTUArray" suggested 
alternative is a really poor one since I am not using arrays at all.

Who can suggest a way to cast from Float to Word32 and Double to Word64 using 
ghc?  The actual task is that I need to write out the Float as a little endian 
sequence of four bytes and also be able to read it back in.  The writing and 
reading are done in Put and Get monads to ByteString (from the "binary" package).

The alloca/poke/peek work around I have looks like
castWord32ToFloat :: Word32 -> Float
castWord32ToFloat x = unsafePerformIO $
   alloca $ \p -> poke p x >> peek (castPtr p)

castFloatToWord32 :: Float -> Word32
castFloatToWord32 x = unsafePerformIO $
   alloca $ \p -> poke p x >> peek (castPtr p)

The unsafeCoerce trick that is no longer working looks like:
castWord64ToDouble :: Word64 -> Double
castWord64ToDouble (W64# w) = D# (unsafeCoerce# w)

castDoubleToWord64 :: Double -> Word64
castDoubleToWord64 (D# d) = W64# (unsafeCoerce# d)

Any ideas? Or is the alloca trick the only way to do this?

   Chris


Ian Lynagh wrote:
> Hi Chris,
> 
> On Sun, Sep 21, 2008 at 05:37:33PM +0100, Chris Kuklewicz wrote:
>> Also, I tried two tricks:
>> (D# x) <-> (W64# x) which works fine
>> (F# x) <-> (W32# x) which produced garbage, so I had to replace it with 
>> alloca/poke/peek.
> 
> This isn't supported, and I suspect is the cause of the -fasm problems.
> 
> Please see
>     http://hackage.haskell.org/trac/ghc/ticket/2209
> for more details and suggested alternative.
> 
> 
> Thanks
> Ian
> 

From jwlato at gmail.com  Mon Sep 22 06:48:41 2008
From: jwlato at gmail.com (John Lato)
Date: Mon Sep 22 06:46:05 2008
Subject: [Haskell-cafe] RE: readFile and closing a file
Message-ID: <9979e72e0809220348j689e6e68m69b286f961e4c023@mail.gmail.com>

> On Wed, 17 Sep 2008, Mitchell, Neil wrote:
>
>> I tend to use openFile, hGetContents, hClose - your initial readFile
>> like call should be openFile/hGetContents, which gives you a lazy
>> stream, and on a parse error call hClose.
>
> I could use a function like
>   withReadFile :: FilePath -> (Handle -> IO a) -> IO a
>   withReadFile name action = bracket openFile hClose ...
>
> Then, if 'action' fails, the file can be properly closed. However, there
> is still a problem: Say, 'action' is a parser which produces a data
> structure lazily. Then further processing of that data structure of type
> 'a' may again stop before completing the whole structure, which would also
> leave the file open. We have to force users to do all processing within
> 'action' and to only return strict values. But how to do this?

I used rnf from Control.Parallel.Strategies when dealing with a
similar problem.  Would it work in your case?

To merge discussion from a related thread:

IMO, the question is how much should a language/library prevent the
user from shooting himself in the foot?  The biggest problem with lazy
IO, IMO, is that it presents several opportunities to do so.  The
three biggest causes I've dealt with are handle leaks, insufficiently
evaluated data structures, and problems with garbage collection as in
the naive 'mean xs = sum xs / length xs' implementation.

There are some idioms that can help with the first two cases, namely
the 'with*' paradigm and 'rnf', but the third problem requires that
the programmer know how stuff works to avoid poor implementations.
While that's not bad per se, in some cases I think it's far too easy
for the unwitting, or even the slightly distracted, to get caught in
traps.

I'm facing a design decision ATM related to this.  I can use something
like lazy bytestrings, in which the chunkiness and laziness is reified
into the datastructure, or an Iterator-style fold for consuming data.
The advantage of the former approach is that it's well understood by
most users and has proven good performance, while on the downside I
could see it easily leading to memory exhaustion.  I think the problem
with lazy bytestrings, in particular, is that the foldChunks is so
well hidden from most consumers that it's easy to hold references that
prevent consumed chunks from being reclaimed by the GC.  When dealing
with data in the hundreds of MBs, or GB range, this is a problem.

An Enumerator, on the other hand, makes the fold explicit, so users
are required to think about the best way to consume data.  It's much
harder to unintentionally hold references.  This is quite appealing.
Based on my own tests so far performance is certainly competitive.
Assuming a good implementation, handle leaks can also be prevented.
On the downside, it's a very poor model if random access is required,
and users aren't as familiar with it, in addition to some of the
questions Don raises.

Back onto the topic at hand - 'action' could be a parser passed into
an enumerator.  Since it would read strictly, the action could end the
read when it has enough data.  That's another approach that I think
would work with your problem.

Well, that's my 2cents.

John Lato
From gale at sefer.org  Mon Sep 22 07:12:57 2008
From: gale at sefer.org (Yitzchak Gale)
Date: Mon Sep 22 07:10:07 2008
Subject: [Haskell-cafe] Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell
	is ready
In-Reply-To: <48D777F0.7060907@list.mightyreason.com>
References: <48D53BBA.10101@list.mightyreason.com>
	<20080920180915.GB18629@scytale.galois.com>
	<48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se>
	<48D6784D.7070101@list.mightyreason.com>
	<20080921165752.GA19677@matrix.chaos.earth.li>
	<48D777F0.7060907@list.mightyreason.com>
Message-ID: <2608b8a80809220412i64a77870ufb58cf2a1f734f0e@mail.gmail.com>

Chris Kuklewicz wrote:
> Who can suggest a way to cast from Float to Word32 and Double to Word64
> using ghc?  The actual task is that I need to write out the Float as a
> little endian sequence of four bytes and also be able to read it back in.
>  The writing and reading are done in Put and Get monads to ByteString (from
> the "binary" package).

I think alloca-like hacks is really the wrong direction and asking
for trouble.

You are trying to translate between platform-dependent native floats,
and IEEE floats in a specified platform-independent binary format
for Google. So use encodeFloat/decodeFloat - fast primitives in
GHC - on the native side, and a hand-written Binary instance for
the exact format you need on the Google side.

My opinion, YMMV.

Regards,
Yitz
From haskell at list.mightyreason.com  Mon Sep 22 07:18:26 2008
From: haskell at list.mightyreason.com (ChrisK)
Date: Mon Sep 22 07:15:51 2008
Subject: [Haskell-cafe] Re: Climbing up the shootout...
In-Reply-To: <20080922052712.GB24712@scytale.galois.com>
References: <20080922052712.GB24712@scytale.galois.com>
Message-ID: 

And, though I had never seen it before, the current winner for speed is "ATS" ( 
http://www.ats-lang.org/ ) which is dependently-typed functional language.


From bulat.ziganshin at gmail.com  Mon Sep 22 08:07:59 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 08:05:59 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <48D7698F.8040902@libero.it>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it>
Message-ID: <64475980.20080922160759@gmail.com>

Hello Manlio,

Monday, September 22, 2008, 1:46:55 PM, you wrote:

> This is cheating, IMHO.
> Some test comparisons are unfair.

this overall test is uselles for speed comparison. afair, there are
only 2-3 programs whose speed isn't heavily depend on libraries. in
DNA test, for example, Tcl (or PHP?) was leader just because it has
better regexp library

to make things even funnier, this test allows to use libs bundled to
compiler, but not 3rd-arty ones. so ghc (not Haskell!) what includes
more built-in libs than gcc looks like a leader. of course, noone uses
bare ghc or gcc in real world

even benchamrks that test pure speed of compiled code are useless
because

1) they are imited by RAM speed, not speed of code itself
2) there uis a fashion in Haskell world to write for shootout in the
very low-level style, which isn't actually used in real programming
and actually understood only by a few "wizards" developing
high-performance haskell code

so actually that this shootout shows is that
1) in real world, program speed more depends on libs that on
compilers. if you go to compare weak language plus lot of libs with a
strong language with a few libs first variant will win (unless you go
to reimplement all these libs at your own)

2) highly-optimized Haskell code is only 2-3 times slower than real C
code produces by average C programmer. taken into account that such
Haskell code is written many times slower than C one and need much
more knowledge, Haskell hardly can be compared to C

3) if you need to compare real-world Haskell code with C one, you may
look at these papers:

An approach to fast arrays in Haskell
http://www.cse.unsw.edu.au/~chak/papers/afp-arrays.ps.gz

Rewriting Haskell Strings
http://www.cse.unsw.edu.au/~dons/papers/fusion.pdf

that they call "naive approach" is real Haskell programs not speeded
up by special libs


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From bulat.ziganshin at gmail.com  Mon Sep 22 08:15:50 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 08:16:14 2008
Subject: [Haskell-cafe] Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell
	is ready
In-Reply-To: <48D777F0.7060907@list.mightyreason.com>
References: <48D53BBA.10101@list.mightyreason.com>
	<20080920180915.GB18629@scytale.galois.com>
	<48D64DE8.90602@dtek.chalmers.se>
	<48D650A9.2080507@dtek.chalmers.se>
	<48D6784D.7070101@list.mightyreason.com>
	<20080921165752.GA19677@matrix.chaos.earth.li>
	<48D777F0.7060907@list.mightyreason.com>
Message-ID: <152289621.20080922161550@gmail.com>

Hello Chris,

Monday, September 22, 2008, 2:48:16 PM, you wrote:

> used a very unreliable trick.  And the "use castToSTUArray" suggested
> alternative is a really poor one since I am not using arrays at all.

castToSTUArray does the same as your code, only in ST monad so you can
skip unsafePerformIO trick

if you dn't know, ST is a subset of IO monad with a limited set of
operations guaranteed to not have side-effects. so,

cvt x = unsafePerformIO $
        do alloca $ \place -> do
           poke place x
           peek place

and

cvt x = runST $
        do place <- newArray (0,1)
           writeArray place 0 x
           readArray place 0

generates almost the same code (the only difference is kind of memory
allocated)

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From daniel.is.fischer at web.de  Mon Sep 22 08:50:01 2008
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Mon Sep 22 08:45:10 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D73C19.6010801@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
	<1222029008.4457.64.camel@localhost.localdomain>
	<48D73C19.6010801@btinternet.com>
Message-ID: <200809221450.01896.daniel.is.fischer@web.de>

Am Montag, 22. September 2008 08:32 schrieb Andrew Coppin:
> > However, I will grant you that Map k v, could have used longer type
> > variables. But we are not alone with using one letter type variable
> > names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And
> > frankly, in this specific case, I think most programmers (Haskell or
> > non-Haskell) will be able to guess what k and v means, when they are
> > standing right after Map.
>
> Only if you can figure out that "Map" means what every other programming
> language on the face of the Earth calls a "dictionary". (This took me a
> while!)

So, when did Java leave the face of the earth?
Seriously, I find Map a far clearer term than dictionary and would've had 
problems grokking the latter. I guess you've just been exposed to the wrong 
languages for too long.
From briqueabraque at yahoo.com  Mon Sep 22 09:07:40 2008
From: briqueabraque at yahoo.com (Mauricio)
Date: Mon Sep 22 09:05:01 2008
Subject: [Haskell-cafe] Re: Line noise
In-Reply-To: <48D68F22.1090808@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
Message-ID: 

 > I hang out on another forum that is populated by
 > various kinds of computer geeks. There's a fair
 > few programmers in there, as well as nerds of
 > every degree. And yet, every time I post
 > anything written in Haskell, everybody complains
 > that it "looks like line noise".  (...)

I have to say we haskellers are guilt of that
too. Many messages in this list says C looks line
noise.

There are many arguments we can use to say Haskell
is better than other languages. The only one I
take seriously is: it fits our way of
thinking. Other people like to think in other
ways. I'm an engineer, and the only way I can deal
with engineering is through abstract math. Many
engineers better than me refuse to use math at
all.

I see so many people advocating Haskell and
functional programming. I would like to sugest:
why don't we advocate against "monocultures"? An
environment where anyone can use whatever language
they like is so easy to get this days, and would
have far better results.

IMHO. Best,
Maur?cio

From simonmarhaskell at gmail.com  Mon Sep 22 09:50:51 2008
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Mon Sep 22 09:48:10 2008
Subject: [Haskell-cafe] Re: a question about concurrent haskell
In-Reply-To: <48D2A576.4010100@libero.it>
References: <48D2A576.4010100@libero.it>
Message-ID: <48D7A2BB.5030109@gmail.com>

Manlio Perillo wrote:
>
> P.S.: another question.
> Why, in ghci, every time I call myThreadId, I get a different value?
> 
> Prelude Control.Concurrent> myThreadId
> ThreadId 40
> Prelude Control.Concurrent> myThreadId
> ThreadId 41

GHCi runs each expression in a new thread.

Cheers,
	Simon

From ndmitchell at gmail.com  Mon Sep 22 10:03:33 2008
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Sep 22 10:00:44 2008
Subject: [Haskell-cafe] Re: Munging wiki articles with tagsoup
In-Reply-To: <20080920221157.GD1431@craft>
References: <20080908053105.GB15405@craft>
	<404396ef0809091149o10237ebfhc76cb8d7c57bd634@mail.gmail.com>
	<20080920221157.GD1431@craft>
Message-ID: <404396ef0809220703t11878a2du3e5fdf3d5caac30c@mail.gmail.com>

Hi

>> For no escaping of any characters, or more likely do something like <,
>> > and & conversions. See the docs:
>> http://hackage.haskell.org/packages/archive/tagsoup/0.6/doc/html/Text-HTML-TagSoup-Render.html
>
> Well, I did look at that Haddock page, as well as the others. But honestly, just a bare line like 'renderTagsOptions :: RenderOptions -> [Tag] -> String' doesn't help me - it doesn't tell me that 'that's default behavior, but you can override it thusly'.

The lack of sufficient documentation is a bug. I've filed it at:

http://code.google.com/p/ndmitchell/issues/detail?id=91

If someone wants to write the documentation and submit a patch, that
would be great. Otherwise, I'll fix it at some unknown point in the
future.

Thanks

Neil
From dav.vire+haskell at gmail.com  Mon Sep 22 11:36:44 2008
From: dav.vire+haskell at gmail.com (david48)
Date: Mon Sep 22 11:33:55 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: 
References: <48D68F22.1090808@btinternet.com>
	
	<48D69C29.3040902@btinternet.com>
	
Message-ID: <4c88418c0809220836i5729a39fs448974220befff4f@mail.gmail.com>

On Sun, Sep 21, 2008 at 10:04 PM, Claus Reinke  wrote:
> Once your readers understand
> your code, you can add the one-liner and ask for applause

This should make it HWN's quotes of the week !
From RafaelGCPP.Linux at gmail.com  Mon Sep 22 11:54:27 2008
From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto)
Date: Mon Sep 22 11:51:38 2008
Subject: [Haskell-cafe] Ropes
In-Reply-To: <1222006230-sup-1742@ausone.local>
References: <351ff25e0809191748h7e3885e8g516e0370358f7309@mail.gmail.com>
	<351ff25e0809191750m368069efq29a783b8ce0b8838@mail.gmail.com>
	<2f9b2d30809191915m2cdd8963yded4fb1c14c40c43@mail.gmail.com>
	<351ff25e0809200354m6dc90c0apc723c26a1e4e53f@mail.gmail.com>
	<1222006230-sup-1742@ausone.local>
Message-ID: <351ff25e0809220854q21b00c4h99500ddafc5580b6@mail.gmail.com>

That is a good idea!

If I implement head, tail, take drop operations, I can use my KMP
implementation out of the box...



On Sun, Sep 21, 2008 at 11:10, Nicolas Pouillard <
nicolas.pouillard@gmail.com> wrote:

> Excerpts from Rafael Gustavo da Cunha Pereira Pinto's message of Sat Sep 20
> 12:54:26 +0200 2008:
> > I am doing the ICFPC07 task right now, to learn Haskell and tried to use
> the
> > Sequence, but the final code is too damn slow (a few iterations per
> > minute!).
>
> Is your structure a sequence of *Char*s, if so you should consider to use a
> sequence of strict bytestrings of a given size (chunks).
>
> > The DNA needs only 2 operations: head (or take) and concat.
> >
> > I am thinking in using ropes for the DNA and sequences for all the rest
> > (patterns, templates and RNA).
> >
> > On Fri, Sep 19, 2008 at 23:15, Ryan Ingram  wrote:
> >
> > > I think Data.Sequence uses fingertrees which are pretty fast.
> > >
> > > I used a handgrown rope-like structure for ICFPC07 but I wish I had
> > > known about Sequence; it would have likely just been better.
> > >
> > >  -- ryan
> > >
> > > 2008/9/19 Rafael Gustavo da Cunha Pereira Pinto <
> > > RafaelGCPP.Linux@gmail.com>:
> > > > Hi all,
> > > >
> > > > Is there any implementation of the rope data structure in Haskell?
> > > >
> > > > I couldn't find any on Hackage, and I am intending to implement it.
> > > >
> > > > Regards,
> > > >
> > > > Rafael Gustavo da Cunha Pereira Pinto
> > > > Electronic Engineer, MSc.
> > > >
> > > > _______________________________________________
> > > > Haskell-Cafe mailing list
> > > > Haskell-Cafe@haskell.org
> > > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > > >
> > > >
> > >
> >
>
> --
> Nicolas Pouillard aka Ertai
>



-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/92a5e62d/attachment.htm
From dons at galois.com  Mon Sep 22 12:39:21 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 12:36:23 2008
Subject: [Haskell-cafe] RE: readFile and closing a file
In-Reply-To: <9979e72e0809220348j689e6e68m69b286f961e4c023@mail.gmail.com>
References: <9979e72e0809220348j689e6e68m69b286f961e4c023@mail.gmail.com>
Message-ID: <20080922163921.GC26315@scytale.galois.com>

jwlato:
> > On Wed, 17 Sep 2008, Mitchell, Neil wrote:
> >
> >> I tend to use openFile, hGetContents, hClose - your initial readFile
> >> like call should be openFile/hGetContents, which gives you a lazy
> >> stream, and on a parse error call hClose.
> >
> > I could use a function like
> >   withReadFile :: FilePath -> (Handle -> IO a) -> IO a
> >   withReadFile name action = bracket openFile hClose ...
> >
> > Then, if 'action' fails, the file can be properly closed. However, there
> > is still a problem: Say, 'action' is a parser which produces a data
> > structure lazily. Then further processing of that data structure of type
> > 'a' may again stop before completing the whole structure, which would also
> > leave the file open. We have to force users to do all processing within
> > 'action' and to only return strict values. But how to do this?
> 
> I used rnf from Control.Parallel.Strategies when dealing with a
> similar problem.  Would it work in your case?
> 
> To merge discussion from a related thread:
> 
> IMO, the question is how much should a language/library prevent the
> user from shooting himself in the foot?  The biggest problem with lazy
> IO, IMO, is that it presents several opportunities to do so.  The
> three biggest causes I've dealt with are handle leaks, insufficiently
> evaluated data structures, and problems with garbage collection as in
> the naive 'mean xs = sum xs / length xs' implementation.
> 
> There are some idioms that can help with the first two cases, namely
> the 'with*' paradigm and 'rnf', but the third problem requires that
> the programmer know how stuff works to avoid poor implementations.
> While that's not bad per se, in some cases I think it's far too easy
> for the unwitting, or even the slightly distracted, to get caught in
> traps.
> 
> I'm facing a design decision ATM related to this.  I can use something
> like lazy bytestrings, in which the chunkiness and laziness is reified
> into the datastructure, or an Iterator-style fold for consuming data.
> The advantage of the former approach is that it's well understood by
> most users and has proven good performance, while on the downside I
> could see it easily leading to memory exhaustion.  I think the problem
> with lazy bytestrings, in particular, is that the foldChunks is so
> well hidden from most consumers that it's easy to hold references that
> prevent consumed chunks from being reclaimed by the GC.  When dealing
> with data in the hundreds of MBs, or GB range, this is a problem.
> 
> An Enumerator, on the other hand, makes the fold explicit, so users
> are required to think about the best way to consume data.  It's much
> harder to unintentionally hold references.  This is quite appealing.
> Based on my own tests so far performance is certainly competitive.
> Assuming a good implementation, handle leaks can also be prevented.
> On the downside, it's a very poor model if random access is required,
> and users aren't as familiar with it, in addition to some of the
> questions Don raises.

Yes, I'm certain we can reach the performance of, or outperform, lazy
(cache-sized chunk) bytestrings using enumerators on chunks, but the
model is somewhat unfamiliar. Structuring the api such that people can
write programs in this style will be the challenge.

-- Don
From huschi at gmx.org  Mon Sep 22 12:47:52 2008
From: huschi at gmx.org (Martin Huschenbett)
Date: Mon Sep 22 12:45:03 2008
Subject: [Haskell-cafe] Updated formlets sample?
In-Reply-To: <33E9F827-BE88-4916-B30D-DFDD56FC4868@eidhof.nl>
References: <48D3898B.5070904@gmx.org>
	<20898DDF-5BF7-4FA1-8BAF-881D57C57CB8@eidhof.nl>
	<48D69C5A.2040505@gmx.org>
	<33E9F827-BE88-4916-B30D-DFDD56FC4868@eidhof.nl>
Message-ID: <48D7CC38.6010205@gmx.org>

Hi Chris,

you're absolutely right. The mistake was in the where-part of withForm. 
The function handleOk' gets an environment d as argument but uses an 
extractor that was created without passing d to runFormState. I've put a 
corrected version on hpaste [1] and also posted it to the wiki on 
haskell.org [2]. Hope this is ok for you?

Regards,

Martin.

[1] http://hpaste.org/10568#a1
[2] http://haskell.org/haskellwiki/Formlets

Chris Eidhof schrieb:
> That means that you don't have input0 in your environment, maybe you're 
> passing in an empty environment?
> 
> -chris
> 
> On 21 sep 2008, at 12:11, Martin Huschenbett wrote:
> 
>> Hi Chris,
>>
>> thanks for the updated example. Compiling works now. But when I try to 
>> run it I alway get error messages like
>>
>> ["input0 is not in the data","input1 is not in the data"]
>>
>> Regards,
>>
>> Martin.
>>
>> Chris Eidhof schrieb:
>>> Hey Martin,
>>> On 19 sep 2008, at 04:14, Martin Huschenbett wrote:
>>>> I found a blog post concerning formlets [1] in the web. Since looks 
>>>> very interesting I tried to compile the sample code with recent 
>>>> versions of HAppS and formlets from hackage. But this didn't work as 
>>>> the API of formlets has changed since this post.
>>>>
>>>> I tried to adopt the code to the new API but I was unable to finish 
>>>> this since there is a new monadic context I don't know to handle in 
>>>> the right way.
>>>>
>>>> So my question is, is there an updated version of this sample code 
>>>> in the web or has anybody tried to adopt it and can send me the 
>>>> results?
>>> Yes, I'm sorry for that. The API is still very immature and due to 
>>> changes, that's also why it hasn't been officially announced yet. 
>>> I've just put an updated example at http://hpaste.org/10568, hope 
>>> that'll work for you. I guess we should build a small homepage / 
>>> wikipage that always has an up-to-date example.
>>> -chris
From sebastian.sylvan at gmail.com  Mon Sep 22 12:53:58 2008
From: sebastian.sylvan at gmail.com (Sebastian Sylvan)
Date: Mon Sep 22 12:51:08 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <200809221450.01896.daniel.is.fischer@web.de>
References: <48D68F22.1090808@btinternet.com>
	<1222029008.4457.64.camel@localhost.localdomain>
	<48D73C19.6010801@btinternet.com>
	<200809221450.01896.daniel.is.fischer@web.de>
Message-ID: <3d96ac180809220953m1da64573i2db000d6229da611@mail.gmail.com>

On Mon, Sep 22, 2008 at 1:50 PM, Daniel Fischer wrote:

> Am Montag, 22. September 2008 08:32 schrieb Andrew Coppin:
> > > However, I will grant you that Map k v, could have used longer type
> > > variables. But we are not alone with using one letter type variable
> > > names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html .
> And
> > > frankly, in this specific case, I think most programmers (Haskell or
> > > non-Haskell) will be able to guess what k and v means, when they are
> > > standing right after Map.
> >
> > Only if you can figure out that "Map" means what every other programming
> > language on the face of the Earth calls a "dictionary". (This took me a
> > while!)
>
> So, when did Java leave the face of the earth?


At the same time as C++ presumably. I hadn't really noticed, but I'll be the
first to say: Good riddance!


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/087e0541/attachment.htm
From olsner at gmail.com  Mon Sep 22 13:03:52 2008
From: olsner at gmail.com (Simon Brenner)
Date: Mon Sep 22 13:01:03 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <64475980.20080922160759@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
Message-ID: 

On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin
 wrote:
> this overall test is uselles for speed comparison. afair, there are
> only 2-3 programs whose speed isn't heavily depend on libraries. in
> DNA test, for example, Tcl (or PHP?) was leader just because it has
> better regexp library

On the regex-dna benchmark, I'll have to agree. It's unfortunate to
have a benchmark so dependent on the set of libraries included in the
distribution, and e.g. Text.Regex.PCRE kicks Text.Regex.Posix's behind
in this benchmark - but we probably can't use it only because one's
bundled and the other isn't. Maybe we could roll our own regexp engine
for this specific benchmark though (for example, Text.Regex.TDFA is
within 10% or something of PCRE and AFAIK pure Haskell - a customized
and downsized version of that could probably be made quite
competitive).

> to make things even funnier, this test allows to use libs bundled to
> compiler, but not 3rd-arty ones. so ghc (not Haskell!) what includes
> more built-in libs than gcc looks like a leader. of course, noone uses
> bare ghc or gcc in real world

I don't think it's ever claimed that the shootout is a fair benchmark
of real-world problems :D

> 2) there uis a fashion in Haskell world to write for shootout in the
> very low-level style, which isn't actually used in real programming
> and actually understood only by a few "wizards" developing
> high-performance haskell code

That is certainly the case with a few of the benchmark
implementations, and in the past it was required to get the
performance. In some cases it's also due simply to the haskell
implementation being a straight-from-C port - which necessitates using
pointers and putting everything in IO etc... Some of that haskell code
is among the least readable code I've ever read (see e.g. the fannkuch
benchmark at http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuch&lang=ghc).
But that's what you get when porting pointer-rich C code directly into
Haskell :)

With bytestrings, unboxed arrays, light-weight threads and other
tricks, we can usually replace all those ugly low-level programs with
nice high-level haskell ones - it's all about allowing the compiler to
do good stuff with naive (or at least naive-looking) code, and
teaching it how to cut through the abstractions. (As well as using the
right abstractions, of course...)

// Simon
From bulat.ziganshin at gmail.com  Mon Sep 22 13:12:06 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 13:10:02 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: 
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
Message-ID: <534345625.20080922211206@gmail.com>

Hello Simon,

Monday, September 22, 2008, 9:03:52 PM, you wrote:

> With bytestrings, unboxed arrays, light-weight threads and other
> tricks, we can usually replace all those ugly low-level programs with
> nice high-level haskell ones

i don't think that these 3 libs allows to write high-level
high-performance code in *most* cases. just for example, try to write wc
without using "words"

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From max.vasin at gmail.com  Mon Sep 22 13:52:32 2008
From: max.vasin at gmail.com (Max Vasin)
Date: Mon Sep 22 13:49:58 2008
Subject: [Haskell-cafe] hGetContents and lazyness
Message-ID: <87od2g2hlr.fsf@gmail.com>

Hello, haskellers!

Suppose we have function (it filters package filenames from apt Packages file):

> getPackageList :: FilePath -> IO [FilePath]
> getPackageList packageFile = withFile packageFile ReadMode $
>                              \h -> do c <- hGetContents h
>                                       return $ map (drop 10) $ filter (startsWith "Filename:") $ lines c -- (1)
>     where startsWith [] _ = True
>           startsWith _ [] = False
>           startsWith (x:xs) (y:ys) | x == y    = startsWith xs ys
>                                    | otherwise = False

When, I apply it to a Packages file I (surely) get an empty list. This is an expected result due to
lazyness of hGetContents. I tried changing line (1) to

> return $ map (drop 10) $ filter (startsWith "Filename:") $! lines c

or 

> return $ map (drop 10) $! filter (startsWith "Filename:") $! lines c

with no success.

Chaning it to

> return $! map (drop 10) $ filter (startsWith "Filename:") $ lines c

makes getPackageList function return several (but not all) filenames.

What I'm missing? And how can I fix my code?

--
WBR,
Max Vasin.

From igouy2 at yahoo.com  Mon Sep 22 14:27:03 2008
From: igouy2 at yahoo.com (Isaac Gouy)
Date: Mon Sep 22 14:24:12 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: 
Message-ID: <167607.78461.qm@web65401.mail.ac4.yahoo.com>


--- Simon Brenner  wrote:

> On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin
>  wrote:
> > this overall test is uselles for speed comparison. afair, there are
> > only 2-3 programs whose speed isn't heavily depend on libraries. in
> > DNA test, for example, Tcl (or PHP?) was leader just because it has
> > better regexp library
> 
> On the regex-dna benchmark, I'll have to agree. It's unfortunate to
> have a benchmark so dependent on the set of libraries included in the
> distribution, and e.g. Text.Regex.PCRE kicks Text.Regex.Posix's
> behind
> in this benchmark - but we probably can't use it only because one's
> bundled and the other isn't. Maybe we could roll our own regexp
> engine
> for this specific benchmark though (for example, Text.Regex.TDFA is
> within 10% or something of PCRE and AFAIK pure Haskell - a customized
> and downsized version of that could probably be made quite
> competitive).

You could always suggest use of Text.Regex.PCRE, provide a program and
instructions on how to install Text.Regex.PCRE on Ubuntu.


-snip-
> With bytestrings, unboxed arrays, light-weight threads and other
> tricks, we can usually replace all those ugly low-level programs with
> nice high-level haskell ones ...

Go do!


      
From dons at galois.com  Mon Sep 22 14:32:05 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 14:29:06 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <167607.78461.qm@web65401.mail.ac4.yahoo.com>
References: 
	<167607.78461.qm@web65401.mail.ac4.yahoo.com>
Message-ID: <20080922183205.GC26542@scytale.galois.com>

igouy2:
> 
> --- Simon Brenner  wrote:
> 
> > On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin
> >  wrote:
> > > this overall test is uselles for speed comparison. afair, there are
> > > only 2-3 programs whose speed isn't heavily depend on libraries. in
> > > DNA test, for example, Tcl (or PHP?) was leader just because it has
> > > better regexp library
> > 
> > On the regex-dna benchmark, I'll have to agree. It's unfortunate to
> > have a benchmark so dependent on the set of libraries included in the
> > distribution, and e.g. Text.Regex.PCRE kicks Text.Regex.Posix's
> > behind
> > in this benchmark - but we probably can't use it only because one's
> > bundled and the other isn't. Maybe we could roll our own regexp
> > engine
> > for this specific benchmark though (for example, Text.Regex.TDFA is
> > within 10% or something of PCRE and AFAIK pure Haskell - a customized
> > and downsized version of that could probably be made quite
> > competitive).
> 
> You could always suggest use of Text.Regex.PCRE, provide a program and
> instructions on how to install Text.Regex.PCRE on Ubuntu.
> 
> -snip-
> > With bytestrings, unboxed arrays, light-weight threads and other
> > tricks, we can usually replace all those ugly low-level programs with
> > nice high-level haskell ones ...
> 
> Go do!
> 

All is in hand. Tim Newsham's uploaded a regex-pcre and regex-posix
entry to the wiki, and I'm testing now on quad core. If it survives
testing, we'll submit it to Isaac.

-- Don
From RafaelGCPP.Linux at gmail.com  Mon Sep 22 14:46:24 2008
From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto)
Date: Mon Sep 22 14:43:35 2008
Subject: Fwd: [Haskell-cafe] hGetContents and lazyness
In-Reply-To: <351ff25e0809221146r46a834f4pf4943311328f3746@mail.gmail.com>
References: <87od2g2hlr.fsf@gmail.com>
	<351ff25e0809221146r46a834f4pf4943311328f3746@mail.gmail.com>
Message-ID: <351ff25e0809221146w57bdadfet1f15ca045ef92831@mail.gmail.com>

---------- Forwarded message ----------
From: Rafael Gustavo da Cunha Pereira Pinto 
Date: Mon, Sep 22, 2008 at 15:46
Subject: Re: [Haskell-cafe] hGetContents and lazyness
To: Max Vasin 


Why don't you use OpenFile?

> getPackageList packageFile = do
>                              h <- OpenFile packageFile ReadMode
>                              c <- hGetContents h
>                              return $ map (drop 10) $ filter (startsWith
"Filename:") $ lines c

I am not at home so I don't have GHC around here, but this usually works for
me!

Anyway, it also depends on who is consuming the IO [FilePath] data returned.
It will not be evaluated unless asked for!


On Mon, Sep 22, 2008 at 14:52, Max Vasin  wrote:

> Hello, haskellers!
>
> Suppose we have function (it filters package filenames from apt Packages
> file):
>
> > getPackageList :: FilePath -> IO [FilePath]
> > getPackageList packageFile = withFile packageFile ReadMode $
> >                              \h -> do c <- hGetContents h
> >                                       return $ map (drop 10) $ filter
> (startsWith "Filename:") $ lines c -- (1)
> >     where startsWith [] _ = True
> >           startsWith _ [] = False
> >           startsWith (x:xs) (y:ys) | x == y    = startsWith xs ys
> >                                    | otherwise = False
>
> When, I apply it to a Packages file I (surely) get an empty list. This is
> an expected result due to
> lazyness of hGetContents. I tried changing line (1) to
>
> > return $ map (drop 10) $ filter (startsWith "Filename:") $! lines c
>
> or
>
> > return $ map (drop 10) $! filter (startsWith "Filename:") $! lines c
>
> with no success.
>
> Chaning it to
>
> > return $! map (drop 10) $ filter (startsWith "Filename:") $ lines c
>
> makes getPackageList function return several (but not all) filenames.
>
> What I'm missing? And how can I fix my code?
>
> --
> WBR,
> Max Vasin.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.



-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/ecbf4a0f/attachment.htm
From lrpalmer at gmail.com  Mon Sep 22 15:00:12 2008
From: lrpalmer at gmail.com (Luke Palmer)
Date: Mon Sep 22 14:57:21 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D69C29.3040902@btinternet.com>
References: <48D68F22.1090808@btinternet.com>
	
	<48D69C29.3040902@btinternet.com>
Message-ID: <7ca3f0160809221200p63a2a710v40c03a99d3a20dfe@mail.gmail.com>

On Sun, Sep 21, 2008 at 1:10 PM, Andrew Coppin
 wrote:
> I posted a snippet of code which included the phrase
>
>  mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..]
> vs)
>
> To somebody familiar with Haskell, that is as clear as day. But to a
> newbie... well *you* try explaining that you start at the left end, take the
> thing in brackets, process it from left to right, then take the other thing
> in brackets, process the right side of it, then pass that to putStrLn, oh,
> but that thing right at the left edge is the argument list, and then pass
> the whole lot to mapM_, which is... are you still with me??
>
> As one experienced C++ programmer put it, "there is no clear flow from left
> to right or right to left".

This is actually one of the two main metrics I use when I'm writing
code -- I try to keep the information content in my code local, so you
don't have to scan across the screen to see what n corresponds to.
This is equivalent to maintaining a left-to-right or right-to-left
flow (and really which direction it is depends more on reading style
than writing style).

The other one I picked up from Perl of all places, and that is end
weight.  In English we tend to put the important parts (the "essence")
of the sentence at the front, and leave the details for the end.  So I
like to emulate that in Haskell when I can.  There is little I loathe
more than the style:

   map (\x -> ...
         ...
         ...
         ...
         ...) xs

As such, the probability that I would have written the mapM_ line
above is very low, since it violates both of these.  In this case,
switching to forM_ brings it much closer to my style:

  forM_  (zip [0..] vs) $ \(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v

That is because the details of this sentence are in the function, so I
put it at the end.  Also the corresponding [0..] and n are close
together, as are the corresponding vs and v.

Luke
From graham.fawcett at gmail.com  Mon Sep 22 15:01:43 2008
From: graham.fawcett at gmail.com (Graham Fawcett)
Date: Mon Sep 22 14:58:52 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <534345625.20080922211206@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
Message-ID: 

On Mon, Sep 22, 2008 at 1:12 PM, Bulat Ziganshin
 wrote:
> Hello Simon,
>
> Monday, September 22, 2008, 9:03:52 PM, you wrote:
>
>> With bytestrings, unboxed arrays, light-weight threads and other
>> tricks, we can usually replace all those ugly low-level programs with
>> nice high-level haskell ones
>
> i don't think that these 3 libs allows to write high-level
> high-performance code in *most* cases. just for example, try to write wc
> without using "words".

To a newbie, that's a cryptic statement. Are you saying that these
libs aren't needed to make a high-performance "wc", and that the
Prelude functions are sufficient? (I note too that there is
Data.ByteString.Char8.words, but I assume you are talking about the
Prelude function.)

Graham
From bulat.ziganshin at gmail.com  Mon Sep 22 15:09:25 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 15:07:16 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: 
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
Message-ID: <61951769.20080922230925@gmail.com>

Hello Graham,

>> i don't think that these 3 libs allows to write high-level
>> high-performance code in *most* cases. just for example, try to write wc
>> without using "words".

> To a newbie, that's a cryptic statement. Are you saying that these
> libs aren't needed to make a high-performance "wc", and that the
> Prelude functions are sufficient? (I note too that there is
> Data.ByteString.Char8.words, but I assume you are talking about the
> Prelude function.)

i mean that naive haskell code is very slow and 3 or 5 or twelve libs
can't solve the problem of ghc generating slow code


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From bulat.ziganshin at gmail.com  Mon Sep 22 15:12:43 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 15:10:28 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <7ca3f0160809221200p63a2a710v40c03a99d3a20dfe@mail.gmail.com>
References: <48D68F22.1090808@btinternet.com>
	
	<48D69C29.3040902@btinternet.com>
	<7ca3f0160809221200p63a2a710v40c03a99d3a20dfe@mail.gmail.com>
Message-ID: <1372204073.20080922231243@gmail.com>

Hello Luke,

Monday, September 22, 2008, 11:00:12 PM, you wrote:

>>  mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..]
>> vs)

>   forM_  (zip [0..] vs) $ \(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v

for  (zip [0..] vs) $ \(n,v) -> do
  putStrLn $ "[" ++ show n ++ "] = " ++ show v
  ...

it's rather close to C/Pascal/... loops although it will be great to
have more sugar here



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From micah at cowan.name  Mon Sep 22 15:20:51 2008
From: micah at cowan.name (Micah Cowan)
Date: Mon Sep 22 15:18:02 2008
Subject: [Haskell-cafe] hGetContents and lazyness
In-Reply-To: <87od2g2hlr.fsf@gmail.com>
References: <87od2g2hlr.fsf@gmail.com>
Message-ID: <48D7F013.6090005@cowan.name>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max Vasin wrote:
> Hello, haskellers!
> 
> Suppose we have function (it filters package filenames from apt Packages file):
> 
>> getPackageList :: FilePath -> IO [FilePath]
>> getPackageList packageFile = withFile packageFile ReadMode $
>>                              \h -> do c <- hGetContents h
>>                                       return $ map (drop 10) $ filter (startsWith "Filename:") $ lines c -- (1)
>>     where startsWith [] _ = True
>>           startsWith _ [] = False
>>           startsWith (x:xs) (y:ys) | x == y    = startsWith xs ys
>>                                    | otherwise = False
> 
> When, I apply it to a Packages file I (surely) get an empty list. This is an expected result due to
> lazyness of hGetContents.

Combined with the fact that you're not evaluating its non-strict result
until after the file handle has been closed, yes.

Your current set of IO actions is probably similar to:
  . open file
  . process file
  . close file
  . use results from processing the file.
where the first three steps are all handled by your getPackageList. To
avoid either getting incomplete (or empty) results, or having to
strictify everything with $!, it'd be better for you to use a process
more like:
  . open file
  . process file
  . use results from processing the file.
  . close file
probably by moving the withFile outside of getPackageList, to wrap a
function that prints the results after they've been obtained. The
function passed to withFile should generally include all the processing
related to the file and its results, I believe.

> I tried changing line (1) to
> 
>> return $ map (drop 10) $ filter (startsWith "Filename:") $! lines c

The $! forces strictness, but since it's deep in the result, it isn't
evaluated until it's too late.

> Chaning it to
> 
>> return $! map (drop 10) $ filter (startsWith "Filename:") $ lines c
> 
> makes getPackageList function return several (but not all) filenames.

I think we'd need to see the actual input and expected output, to
understand what's going wrong here. It worked fine for me, for small tests.

By the way, it's good policy to always post complete, runnable examples.
Requiring anyone who wants to help you to write additional code just to
get it to run decreases the chances that someone will bother to do so.

(Disclaimer: I'm quite new to Haskell myself, so take what I say with
more than a pinch of salt.)

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI1/AT7M8hyUobTrERAo5qAJ9PKLbQv09UGffmxy6/eRuGS1eYbQCgj3gH
8zvxMrGk5pvCMCOQ6LVz0Yo=
=GAvg
-----END PGP SIGNATURE-----
From aeyakovenko at gmail.com  Mon Sep 22 15:35:31 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Mon Sep 22 15:32:40 2008
Subject: [Haskell-cafe] how do i use quickcheck in the IO monad?
Message-ID: 

If i have functions in the IO monad, is there a way to use quickcheck
to test them?  I have a bunch of C bindings that unfortunately are not
"safe".  But i would like to be able to use QuickCheck to test them.

Thanks,
Anatoly
From dons at galois.com  Mon Sep 22 15:43:57 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 15:41:00 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <167607.78461.qm@web65401.mail.ac4.yahoo.com>
References: 
	<167607.78461.qm@web65401.mail.ac4.yahoo.com>
Message-ID: <20080922194357.GA27150@scytale.galois.com>

igouy2:
> 
> --- Simon Brenner  wrote:
> 
> > On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin
> >  wrote:
> > > this overall test is uselles for speed comparison. afair, there are
> > > only 2-3 programs whose speed isn't heavily depend on libraries. in
> > > DNA test, for example, Tcl (or PHP?) was leader just because it has
> > > better regexp library
> > 
> > On the regex-dna benchmark, I'll have to agree. It's unfortunate to
> > have a benchmark so dependent on the set of libraries included in the
> > distribution, and e.g. Text.Regex.PCRE kicks Text.Regex.Posix's
> > behind
> > in this benchmark - but we probably can't use it only because one's
> > bundled and the other isn't. Maybe we could roll our own regexp
> > engine
> > for this specific benchmark though (for example, Text.Regex.TDFA is
> > within 10% or something of PCRE and AFAIK pure Haskell - a customized
> > and downsized version of that could probably be made quite
> > competitive).
> 
> You could always suggest use of Text.Regex.PCRE, provide a program and
> instructions on how to install Text.Regex.PCRE on Ubuntu.

I've now submitted a Text.Regex.PCRE parallelised entry written by Tim
Newsham. It is by far the fastest haskell regex entry so far (down to 9s
on quad core, from 100+ seconds on single core for the old entry),

    http://alioth.debian.org/tracker/index.php?func=detail&aid=311132&group_id=30402&atid=411646

It does require the regex-pcre library, which if it isn't in your
package system on Ubuntu, you can certainly build,

    $ wget http://hackage.haskell.org/packages/archive/regex-pcre-builtin/0.94.2.0.7.7/regex-pcre-builtin-0.94.2.0.7.7.t
ar.gz
    $ tar xzf regex-pcre-builtin-0.94.2.0.7.7.tar.gz
    $ cd regex-pcre-builtin-0.94.2.0.7.7
    $ runhaskell Setup.hs configure --prefix=$HOME
    $ runhaskell Setup.hs build
    $ sudo runhaskell Setup.hs install

I also included these details on the ticket.

It uses a simple parMap strategy.

Cheers,
  Don
From igouy2 at yahoo.com  Mon Sep 22 15:49:30 2008
From: igouy2 at yahoo.com (Isaac Gouy)
Date: Mon Sep 22 15:46:40 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <61951769.20080922230925@gmail.com>
Message-ID: <509435.34302.qm@web65416.mail.ac4.yahoo.com>


--- Bulat Ziganshin  wrote:

> Hello Graham,
> 
> >> i don't think that these 3 libs allows to write high-level
> >> high-performance code in *most* cases. just for example, try to
> write wc
> >> without using "words".
> 
> > To a newbie, that's a cryptic statement. Are you saying that these
> > libs aren't needed to make a high-performance "wc", and that the
> > Prelude functions are sufficient? (I note too that there is
> > Data.ByteString.Char8.words, but I assume you are talking about the
> > Prelude function.)
> 
> i mean that naive haskell code is very slow and 3 or 5 or twelve libs
> can't solve the problem of ghc generating slow code

Is there something particularly fascinating about naive code written in
any language? 


      
From manlio_perillo at libero.it  Mon Sep 22 15:58:53 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Mon Sep 22 15:56:10 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080922194357.GA27150@scytale.galois.com>
References: 	<167607.78461.qm@web65401.mail.ac4.yahoo.com>
	<20080922194357.GA27150@scytale.galois.com>
Message-ID: <48D7F8FD.8040800@libero.it>

Don Stewart ha scritto:
> [...]
> I've now submitted a Text.Regex.PCRE parallelised entry written by Tim
> Newsham. It is by far the fastest haskell regex entry so far (down to 9s
> on quad core, from 100+ seconds on single core for the old entry),
> 
>     http://alioth.debian.org/tracker/index.php?func=detail&aid=311132&group_id=30402&atid=411646
> 
> It does require the regex-pcre library, which if it isn't in your
> package system on Ubuntu, you can certainly build,
> 

What performance gain do you obtain using regex-pcre-builtin against a 
native Haskell regex library?

 > [...]


Thanks  Manlio Perillo
From bulat.ziganshin at gmail.com  Mon Sep 22 16:20:38 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 16:18:41 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <509435.34302.qm@web65416.mail.ac4.yahoo.com>
References: <61951769.20080922230925@gmail.com>
	<509435.34302.qm@web65416.mail.ac4.yahoo.com>
Message-ID: <661592105.20080923002038@gmail.com>

Hello Isaac,

Monday, September 22, 2008, 11:49:30 PM, you wrote:

>> i mean that naive haskell code is very slow and 3 or 5 or twelve libs
>> can't solve the problem of ghc generating slow code

> Is there something particularly fascinating about naive code written in
> any language? 

yes, in asm number of instructions executed more or less define
number of CPU cycles used. C known as portable asm. Haskell was
developed with goal to hide implementation details from egg-headed
scientists and this obviously should have some drawbacks


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From jonathanccast at fastmail.fm  Mon Sep 22 16:30:19 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Mon Sep 22 16:33:26 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <661592105.20080923002038@gmail.com>
References: <61951769.20080922230925@gmail.com>
	<509435.34302.qm@web65416.mail.ac4.yahoo.com>
	<661592105.20080923002038@gmail.com>
Message-ID: <1222115419.8501.20.camel@jcchost>

On Tue, 2008-09-23 at 00:20 +0400, Bulat Ziganshin wrote:
> Hello Isaac,
> 
> Monday, September 22, 2008, 11:49:30 PM, you wrote:
> 
> >> i mean that naive haskell code is very slow and 3 or 5 or twelve libs
> >> can't solve the problem of ghc generating slow code
> 
> > Is there something particularly fascinating about naive code written in
> > any language? 
> 
> yes, in asm number of instructions executed more or less define
> number of CPU cycles used.

On modern processors (RISC design), naive asm is likely to be
extraordinarily slow, because memory usage and cache considerations and
register scheduling dominate processor cycles.

> C known as portable asm.

Known as != is.  And naive C is also extraordinarily slow, especially if
written at a high level.  It is not the least bit difficult to write
memory hogs in C.  (I should know; I've done it.  And so has every major
software house (including open source projects) to release in C, for
that matter.)

> Haskell was
> developed with goal to hide implementation details from egg-headed
> scientists and this obviously should have some drawbacks

Should != is.  Not all shoot-out entries look like C with Haskell syntax
(although some do).  Naive Haskell can be 100s of times slower than
well-tuned C; naive C can be 100s of times slower than well-tuned
Haskell (where well-tuned Haskell can just mean using good data
structures.  It's quite naive indeed to dismiss better data structures
and better algorithms (especially where `better algorithms) as
`libraries.)

jcc


From aeyakovenko at gmail.com  Mon Sep 22 16:42:53 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Mon Sep 22 16:40:02 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
Message-ID: 

> data Nat a where
>    Z :: Nat a
>    S :: Nat a -> Nat (S a)
>
> data Z
> data S a

I thought I was getting this, but this part is confusing.  What
exactly does declaring "data Z" do?
From bulat.ziganshin at gmail.com  Mon Sep 22 16:46:58 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 16:46:03 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1222115419.8501.20.camel@jcchost>
References: <61951769.20080922230925@gmail.com>
	<509435.34302.qm@web65416.mail.ac4.yahoo.com>
	<661592105.20080923002038@gmail.com>
	<1222115419.8501.20.camel@jcchost>
Message-ID: <215121440.20080923004658@gmail.com>

Hello Jonathan,

Tuesday, September 23, 2008, 12:30:19 AM, you wrote:

>> yes, in asm number of instructions executed more or less define
>> number of CPU cycles used.

....

well, i more or less know all this stuff. but are you really compare
to Haskell??? does Haskell programs typically written in account of
cache misses and CPU ticks? i suggest you to look into two papers i
mentioned - they state hundreds times slower naive Haskell vs naive C.
it's a reality, against all your arguments


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From andrewcoppin at btinternet.com  Mon Sep 22 16:50:08 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Mon Sep 22 16:47:18 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D75B53.2030308@web.de>
References: <48D68F22.1090808@btinternet.com> <48D75B53.2030308@web.de>
Message-ID: <48D80500.8040805@btinternet.com>

Stephan Friedrichs wrote:
> Andrew Coppin wrote:
>   
>> [...]
>> - Variable names such as "x" and "f" aren't fabulously helpful to lost
>> programmers trying to find their way.
>>     
>
> I'm not a fan of cryptic variable names, either, and I try to use
> descriptive names wherever I can. But in Haskell...
>
>  - ... you often have variables, which have a scope of far less than a
>    line such as in "map (\(x, (_, y)) -> (x, y) ..." (cleaning
>    intermediate results from a list).
>
>  - ... things often get very abstract, so that it just feels wrong
>    matching on, say, (socket:sockets) instead of (x:xs).
>
>   

...so, more or less the reason why mathematical formulas usually end up 
with non-descriptive variable names then. ;-)

From andrewcoppin at btinternet.com  Mon Sep 22 16:53:50 2008
From: andrewcoppin at btinternet.com (Andrew Coppin)
Date: Mon Sep 22 16:51:00 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <87od2gfog3.fsf@malde.org>
References: <48D68F22.1090808@btinternet.com>		<48D69C29.3040902@btinternet.com>	<1222029008.4457.64.camel@localhost.localdomain>	<48D73C19.6010801@btinternet.com>
	<87od2gfog3.fsf@malde.org>
Message-ID: <48D805DE.50109@btinternet.com>

Ketil Malde wrote:
> The rationale for having long names is that you have too many names,
> and too large a scope to keep track of them all in your head.  Needing
> long names is a symptom that your code is too complex, and that you
> should refactor it.
>   

Well, yeah. In Haskell, functions tend to be rather shorter than in 
procedural languages, so there's less call for dissambiguation because 
there are fewer variables in scope.

> The other problem with "descriptive" names is that it is not
> automatically checked by the compiler, and thus it often ends up being
> misleading.  Incorrect documentation is worse than no documentation.
>   

That's true enough.

>> Nobody is going to realise that "[x]" means a list.
>>     
>
> And C is utterly incomprehensible, since from my Pascal background, I
> just *know* that curly braces denote comments.  Come on, expecting
> somebody to understand a language without an extremely basic
> understanding of fundamental syntactical constructs is futile.
>   

Point taken. I still think "List x" would have been clearer, but nobody 
is going to change the Haskell Report now...

>> well you can see why people are getting lost! ;-)
>>     
>
> Yes, by refusing to adapt to any syntax but the single one they know.
>   

Some people will glance at Haskell and think "hey, that doesn't look 
like source code, I can't read that". But given the number of times I've 
explained all this stuff, you'd think one or two people would have got 
it by now...

>> Only if you can figure out that "Map" means what every other
>> programming language on the face of the Earth calls a
>> "dictionary". (This took me a while!)
>>     
>
> Except for where it is called an "associative array" or "hash table"?
> Terminology is inconsistent, Haskell happens to draw more of it from
> math than from other programming languages.
>   

Heh, let's not argue over technical terms... ;-)

Most people seem far more confused by what a "fold" might be.

From frank at thefixedpoint.me.uk  Mon Sep 22 17:01:53 2008
From: frank at thefixedpoint.me.uk (Frank Wilson)
Date: Mon Sep 22 16:59:18 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
	
Message-ID: 

Someone could probably give a better explanation but I'll give this a  
shot! :)

What you are actually doing is defining a "family" of types. Every  
value in the
type "Nat a" has it's own type. For instance "Z" has type "Nat Z", "(S  
Z)" or "one"
has type "Nat (S Z)",  "(S (S Z))" has type "Nat (S (S Z))" and so on.

In effect types "Z" and "(S a)" defined in those data declarations are  
"marker" types.

It might help you understand if you change the names of the types in  
the data
declarations to something else. It helps not to get confused between
types and constructors ;) .

I hope this was helpful,

Frank

On 22 Sep 2008, at 21:42, Anatoly Yakovenko wrote:

>> data Nat a where
>>   Z :: Nat a
>>   S :: Nat a -> Nat (S a)
>>
>> data Z
>> data S a
>
> I thought I was getting this, but this part is confusing.  What
> exactly does declaring "data Z" do?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From jonathanccast at fastmail.fm  Mon Sep 22 16:58:07 2008
From: jonathanccast at fastmail.fm (Jonathan Cast)
Date: Mon Sep 22 17:01:15 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <215121440.20080923004658@gmail.com>
References: <61951769.20080922230925@gmail.com>
	<509435.34302.qm@web65416.mail.ac4.yahoo.com>
	<661592105.20080923002038@gmail.com> <1222115419.8501.20.camel@jcchost>
	<215121440.20080923004658@gmail.com>
Message-ID: <1222117087.8501.28.camel@jcchost>

On Tue, 2008-09-23 at 00:46 +0400, Bulat Ziganshin wrote:
> Hello Jonathan,
> 
> Tuesday, September 23, 2008, 12:30:19 AM, you wrote:
> 
> >> yes, in asm number of instructions executed more or less define
> >> number of CPU cycles used.
> 
> ....
> 
> well, i more or less know all this stuff. but are you really compare
> to Haskell???

You were tasked with finding a language where `naive' code is fast.
Assembler doesn't count; you have to think about 

>  does Haskell programs typically written in account of
> cache misses and CPU ticks?

No.  At that level, you write assembler (or C).  But assembler and C are
usually not written in a naive fashion (not as naive as naive Haskell).
And when they do, they suck, performance-wise.

> i suggest you to look into two papers i
> mentioned

I don't remember the exact citation, but I'm sure I've read them.
Probably several times over.  Most papers I've seen I think the authors
looked for a large contrast; they aren't comparing Haskell and C on
truly level ground.

> - they state hundreds times slower naive Haskell

With slow datastructures

>  vs naive C.

Not so naive; just better datastructures.  Which are then replicated in
the relevant papers.  And the result is neither extremely low-level code
nor 100s of times slower than C.  The term `naive' gets thrown around in
the introduction to these papers for effect, but the Haskell code under
discussion by the time you reach the conclusion isn't much less `naive'
than the C code in the introduction.

> it's a reality, against all your arguments

Bang harder!!  I don't think the next list over can hear you yet!

jcc


From dons at galois.com  Mon Sep 22 17:10:39 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 17:07:41 2008
Subject: [Haskell-cafe] how do i use quickcheck in the IO monad?
In-Reply-To: 
References: 
Message-ID: <20080922211039.GA27335@scytale.galois.com>

aeyakovenko:
> If i have functions in the IO monad, is there a way to use quickcheck
> to test them?  I have a bunch of C bindings that unfortunately are not
> "safe".  But i would like to be able to use QuickCheck to test them.
> 

Typically, via unsafePerformIO, and check the invariants that need to
hold for that to be safe by hand.

E.g.

prop_foo x = unsafePerformIO $ do
                writeFile "f" x
                y <- readFile "f"
                return (x == y)

-- Don
From lrpalmer at gmail.com  Mon Sep 22 17:40:25 2008
From: lrpalmer at gmail.com (Luke Palmer)
Date: Mon Sep 22 17:37:44 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
	
Message-ID: <7ca3f0160809221440j239612cdlbf2a7585b51f99c6@mail.gmail.com>

On Mon, Sep 22, 2008 at 2:42 PM, Anatoly Yakovenko
 wrote:
>> data Nat a where
>>    Z :: Nat a
>>    S :: Nat a -> Nat (S a)
>>
>> data Z
>> data S a
>
> I thought I was getting this, but this part is confusing.  What
> exactly does declaring "data Z" do?

Well, in Haskell without closed type families, it's not doing all that
much.  You could use Int or IO Elephant if you wanted to, as long as
its head is not S.  But it's documentation, because we're really
declaring the dependent type (in pseudohaskell):

data Nat
  = Z
  | S Nat

data Bounded :: Nat -> * where
  BZ :: Bounded n
  BS :: Bounded n -> Bounded (S n)

So Z and S are the data constructors for Nat, and Bounded *should*
only be able to take Nats as arguments.  But we cannot express that in
Haskell, we just have to be disciplined and never give anything else
to Bounded.

Luke
From jake.mcarthur at gmail.com  Mon Sep 22 17:52:57 2008
From: jake.mcarthur at gmail.com (Jake Mcarthur)
Date: Mon Sep 22 17:50:12 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D805DE.50109@btinternet.com>
References: <48D68F22.1090808@btinternet.com>		<48D69C29.3040902@btinternet.com>	<1222029008.4457.64.camel@localhost.localdomain>	<48D73C19.6010801@btinternet.com>
	<87od2gfog3.fsf@malde.org> <48D805DE.50109@btinternet.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Most people seem far more confused by what a "fold" might be.

A fold by any other name would smell as sweet. ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjYE7kACgkQTkPEVFd3yxh7HwCfVzopoOCgg49YI0Y88g9rjXqI
DvcAn3Buv4FmqcYrK5pDLr1iUc7XRpO5
=CKiH
-----END PGP SIGNATURE-----
From donnie at darthik.com  Mon Sep 22 18:53:17 2008
From: donnie at darthik.com (Donnie Jones)
Date: Mon Sep 22 18:50:26 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <61951769.20080922230925@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
Message-ID: 

Hello Bulat,

On Mon, Sep 22, 2008 at 3:09 PM, Bulat Ziganshin
wrote:

> Hello Graham,
>
> >> i don't think that these 3 libs allows to write high-level
> >> high-performance code in *most* cases. just for example, try to write wc
> >> without using "words".
>
> > To a newbie, that's a cryptic statement. Are you saying that these
> > libs aren't needed to make a high-performance "wc", and that the
> > Prelude functions are sufficient? (I note too that there is
> > Data.ByteString.Char8.words, but I assume you are talking about the
> > Prelude function.)
>
> i mean that naive haskell code is very slow and 3 or 5 or twelve libs
> can't solve the problem of ghc generating slow code
>

I'm fairly new to Haskell and the Haskell community, but I can say from my
experience of hacking on GHC, the GHC team of developers are very interested
in performance improvements, e.g. this thread is about performance!  So
Bulat, why don't you hack on GHC yourself and help improve the compiler?  Or
suggest detailed improvements since you seem capable of citing specific
examples?

Thank you.
__
Donnie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/35e699a2/attachment.htm
From bulat.ziganshin at gmail.com  Mon Sep 22 19:00:28 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 18:58:27 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: 
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
Message-ID: <1797097834.20080923030028@gmail.com>

Hello Donnie,

Tuesday, September 23, 2008, 2:53:17 AM, you wrote:

> i mean that naive haskell code is very slow and 3 or 5 or twelve libs
>  can't solve the problem of ghc generating slow code

> I'm fairly new to Haskell and the Haskell community, but I can say
> from my experience of hacking on GHC, the GHC team of developers are
> very interested in performance improvements, e.g. this thread is
> about performance!? So Bulat, why don't you hack on GHC yourself and
> help improve the compiler?? Or suggest detailed improvements since
> you seem capable of citing specific examples?

for the same reason i don't feed 5000 men with 7 breads - it's not my
business ;)


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From dons at galois.com  Mon Sep 22 19:02:49 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 18:59:53 2008
Subject: [Haskell-cafe] Live twittering from ICFP
Message-ID: <20080922230249.GA27786@scytale.galois.com>

ICFP is on now, for those wondering why the list is a bit quiet :)

    http://www.icfpconference.org/icfp2008/schedule.html

I'm doing live updates of events at ICFP/Haskell Symposium here in Canada.

    http://twitter.com/galoisinc

So you can follow events remotely.

Cheers,
  Don
From dons at galois.com  Mon Sep 22 19:12:37 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 19:09:41 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1797097834.20080923030028@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
Message-ID: <20080922231237.GB27786@scytale.galois.com>

bulat.ziganshin:
> Hello Donnie,
> 
> Tuesday, September 23, 2008, 2:53:17 AM, you wrote:
> 
> > i mean that naive haskell code is very slow and 3 or 5 or twelve libs
> >  can't solve the problem of ghc generating slow code
> 
> > I'm fairly new to Haskell and the Haskell community, but I can say
> > from my experience of hacking on GHC, the GHC team of developers are
> > very interested in performance improvements, e.g. this thread is
> > about performance!? So Bulat, why don't you hack on GHC yourself and
> > help improve the compiler?? Or suggest detailed improvements since
> > you seem capable of citing specific examples?
> 
> for the same reason i don't feed 5000 men with 7 breads - it's not my
> business ;)

Ok. So I'll just say: high level, efficient code is an overriding theme
of many individuals working on Haskell. Things are better and better
each year. We do not stand still.

For example, Bulat cites a paper talking about naive list code from
2002, however, by 2008 we know how to do fusion on lists, so it runs in
the same time as low level loops, the technique is implemented and you
can download it from hackage,

    http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion

Simon Marlow is busy adding more efficient GC and parallelism to GHC,
and there's a summer project to rewrite the native code generator. 
GHC gained pointer tagging in the last release cycle, dramatically
reducing the cost of algebraic data types.

At the same time, we're writing books about how to program "naively" in
Haskell, such that your code doesn't suck. That is: training. Teaching
people how to write Haskell.

We can see it paying off, where naive code performs very very well,

    http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all

And lots and lots more people able to write good code for Hackage.

I find Bulat's outlook rather bleak, and I think it is time to update
expectations.

Progress is beautiful.

-- Don
From gwern0 at gmail.com  Mon Sep 22 19:33:02 2008
From: gwern0 at gmail.com (Gwern Branwen)
Date: Mon Sep 22 19:30:51 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <534345625.20080922211206@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
Message-ID: <20080922233302.GA21973@craft>

On 2008.09.22 21:12:06 +0400, Bulat Ziganshin  scribbled 0.5K characters:
> Hello Simon,
>
> Monday, September 22, 2008, 9:03:52 PM, you wrote:
>
> > With bytestrings, unboxed arrays, light-weight threads and other
> > tricks, we can usually replace all those ugly low-level programs with
> > nice high-level haskell ones
>
> i don't think that these 3 libs allows to write high-level
> high-performance code in *most* cases. just for example, try to write wc
> without using "words"
>
> --
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin@gmail.com

 seems to do fine; you'll notice it drops "lines" after the first version.

--
gwern
class ASPIC Duress BNC WWSV of intelligence retrieval Al PRF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/8df138fe/attachment.bin
From bulat.ziganshin at gmail.com  Mon Sep 22 19:58:31 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 19:59:13 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080922233302.GA21973@craft>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com> <20080922233302.GA21973@craft>
Message-ID: <1367863449.20080923035831@gmail.com>

Hello Gwern,

Tuesday, September 23, 2008, 3:33:02 AM, you wrote:

>> high-performance code in *most* cases. just for example, try to write wc
>> without using "words"

>  seems to do fine; you'll notice
> it drops "lines" after the first version.

actually it counts lines using built-in function. you may find that
naive C is 6x fatser than naive Haskell and difference is so small
only because C version is bound by memory speed


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From bulat.ziganshin at gmail.com  Mon Sep 22 20:16:52 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 20:15:36 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080922231237.GB27786@scytale.galois.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
Message-ID: <1712911408.20080923041652@gmail.com>

Hello Don,

Tuesday, September 23, 2008, 3:12:37 AM, you wrote:

>> for the same reason i don't feed 5000 men with 7 breads - it's not my
>> business ;)

> Ok. So I'll just say: high level, efficient code is an overriding theme
> of many individuals working on Haskell. Things are better and better
> each year. We do not stand still.

yes. when we say that things are greatly improving each year, this
means that they was bad previously ;)

> For example, Bulat cites a paper talking about naive list code from
> 2002, however, by 2008 we know how to do fusion on lists, so it runs in
> the same time as low level loops, the technique is implemented and you
> can download it from hackage,

> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion

someone can ask why this great code isn't used in ghc by default.
probably it is just work in progress which isn't yet ready to replace
old slow code. then we can see tha fusion isn't magic wand which
improves speed of every haskell code that's slower than C one. it just
makes C-speed code sometimes

> Simon Marlow is busy adding more efficient GC and parallelism to GHC,
> and there's a summer project to rewrite the native code generator.

well, i'm sais about *current* real situation. if you consider this as
attack against Haskell developers, it's your mistake. the problem is
that i many years wrote about slowness of ghc code, every time you
cosider this as attack and write that in future Haskell will become
much faster. we still wait for this future, however

> GHC gained pointer tagging in the last release cycle, dramatically
> reducing the cost of algebraic data types.

10-20% speed improvement, on average. it's the only real improvement
(for my own program) i know. i think that ByteString-related libs
gived more improvements but their use isn't automatic and they doesn't
help in any situation. they just provide fast library code for solving
some concrete (although very frequent) situations, such as counting
lines

> At the same time, we're writing books about how to program "naively" in
> Haskell, such that your code doesn't suck. That is: training. Teaching
> people how to write Haskell.

it is what i say - if naive code was effective and automagically
optimized by ghc, we don't need all those tutorials. anyone looked
into your tutorial on writing efficient Haskell code, will never say
that it's easier than in C. so we can conclude that optimized haskell
programs are several times slower than C ones and need several times
more to write

> We can see it paying off, where naive code performs very very well,

> http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all

yes! it's my beloved example of "elegant" haskell code entirely based
on the readInt function added to ghc libs specifically to win in this
test. it's implementation is really simple and naive:

-- ---------------------------------------------------------------------
-- Reading from ByteStrings

-- | readInt reads an Int from the beginning of the ByteString.  If there is no
-- integer at the beginning of the string, it returns Nothing, otherwise
-- it just returns the int read, and the rest of the string.
readInt :: ByteString -> Maybe (Int, ByteString)
readInt as
    | null as   = Nothing
    | otherwise =
        case unsafeHead as of
            '-' -> loop True  0 0 (unsafeTail as)
            '+' -> loop False 0 0 (unsafeTail as)
            _   -> loop False 0 0 as

    where loop :: Bool -> Int -> Int -> ByteString -> Maybe (Int, ByteString)
          STRICT4(loop)
          loop neg i n ps
              | null ps   = end neg i n ps
              | otherwise =
                  case B.unsafeHead ps of
                    w | w >= 0x30
                     && w <= 0x39 -> loop neg (i+1)
                                          (n * 10 + (fromIntegral w - 0x30))
                                          (unsafeTail ps)
                      | otherwise -> end neg i n ps

          end _    0 _ _  = Nothing
          end True _ n ps = Just (negate n, ps)
          end _    _ n ps = Just (n, ps)



when gcc developers will start to add to C libraries functions
performing shootout benchmarks we will continue this discussion :D

> And lots and lots more people able to write good code for Hackage.

> I find Bulat's outlook rather bleak, and I think it is time to update
> expectations.

> Progress is beautiful.

:)

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From chaddai.fouche at gmail.com  Mon Sep 22 20:21:05 2008
From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=)
Date: Mon Sep 22 20:18:14 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1367863449.20080923035831@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com> <20080922233302.GA21973@craft>
	<1367863449.20080923035831@gmail.com>
Message-ID: 

2008/9/23 Bulat Ziganshin :
>>  seems to do fine; you'll notice
>> it drops "lines" after the first version.
>
> actually it counts lines using built-in function. you may find that
> naive C is 6x fatser than naive Haskell and difference is so small
> only because C version is bound by memory speed

So what ? Strings represented as lists of character are slow ? What an
incredible discovery !

The ByteString versions are fast, ByteString was invented especially
for IO intensive situation, it's a library you can use pretty naively
and mostly get excellent performances, what exactly isn't Haskelly
enough for you in this solution ? The guts of ByteString aren't
idiomatic Haskell ? And ? The guts of the JVM aren't written in Java
either... At least ByteString was built over GHC which means it can be
done.

Besides a part of the performances of ByteString comes from stream
fusion and that's specifically something that is hard to achieve
outside of Haskell...


What exactly is your point ?
- Haskell is slow, we can't make it faster ? That's obviously false as
demonstrated by the progress in the latest years.
- Haskell is slower than C ? Well that's probably true, because C can
touch the hardware directly and can always optimize every single
aspects of a computation... On the other hand that kind of uber
optimization has a cost that I am unwilling to pay, I would rather
write high level Haskell and pay a little hit on execution time.
- We shouldn't center ourselves around performance to promote Haskell
(or should we even promote Haskell) ? Well there you may have a point,
but maybe it would be better to just make it and avoid denying other
peoples efforts to make Haskell faster ?

-- 
Jeda?
From dons at galois.com  Mon Sep 22 20:22:19 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 20:19:21 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1712911408.20080923041652@gmail.com>
References: <48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
Message-ID: <20080923002219.GA28014@scytale.galois.com>

bulat.ziganshin:
> when gcc developers will start to add to C libraries functions
> performing shootout benchmarks we will continue this discussion :D

atoi(3).

-- Don
From bulat.ziganshin at gmail.com  Mon Sep 22 20:31:52 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 20:30:36 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080923002219.GA28014@scytale.galois.com>
References: <48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
	<20080923002219.GA28014@scytale.galois.com>
Message-ID: <1881496506.20080923043152@gmail.com>

Hello Don,

Tuesday, September 23, 2008, 4:22:19 AM, you wrote:

> bulat.ziganshin:
>> when gcc developers will start to add to C libraries functions
>> performing shootout benchmarks we will continue this discussion :D

> atoi(3).

it isn't the same as readInt which was added specifically for this
test. it doesn't support arbitrary-size streams and doesn't return
rest of stream


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From dons at galois.com  Mon Sep 22 20:36:55 2008
From: dons at galois.com (Don Stewart)
Date: Mon Sep 22 20:33:56 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1881496506.20080923043152@gmail.com>
References: 
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
	<20080923002219.GA28014@scytale.galois.com>
	<1881496506.20080923043152@gmail.com>
Message-ID: <20080923003655.GC28014@scytale.galois.com>

bulat.ziganshin:
> Hello Don,
> 
> Tuesday, September 23, 2008, 4:22:19 AM, you wrote:
> 
> > bulat.ziganshin:
> >> when gcc developers will start to add to C libraries functions
> >> performing shootout benchmarks we will continue this discussion :D
> 
> > atoi(3).
> 
> it isn't the same as readInt which was added specifically for this
> test. it doesn't support arbitrary-size streams and doesn't return
> rest of stream
> 

Hmm? That is wrong. These functions explicitly work on arbitrarily long
lazy bytestrings, and return the rest of the stream in a pair:

    readInt :: ByteString -> Maybe (Int, ByteString)
    readInteger :: ByteString -> Maybe (Integer, ByteString)

These are the initial parts of a bytestring lexing library, more of
which is appareing in the bytestring-lex package on Hackage.

-- Don
From chaddai.fouche at gmail.com  Mon Sep 22 20:39:18 2008
From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=)
Date: Mon Sep 22 20:36:26 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1881496506.20080923043152@gmail.com>
References: <48D7698F.8040902@libero.it> <534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
	<20080923002219.GA28014@scytale.galois.com>
	<1881496506.20080923043152@gmail.com>
Message-ID: 

2008/9/23 Bulat Ziganshin :
> Hello Don,
>
> Tuesday, September 23, 2008, 4:22:19 AM, you wrote:
>
>> bulat.ziganshin:
>>> when gcc developers will start to add to C libraries functions
>>> performing shootout benchmarks we will continue this discussion :D
>
>> atoi(3).
>
> it isn't the same as readInt which was added specifically for this
> test. it doesn't support arbitrary-size streams and doesn't return
> rest of stream

Yeah, readInt has a more useful type than atoi() in most circumstances
so obviously it's a default which somehow disqualify this function...
(I wasn't aware that this function was only useful in the shoutout
context, I should probably scrap it from my other programs now)

I think we should write all the entries in Haskell98 and disable any
optimisation in GHC too, that would gives us a much fairer vision of
Haskell current performances.

-- 
Jeda?
From bhurt at spnz.org  Mon Sep 22 21:27:17 2008
From: bhurt at spnz.org (Brian Hurt)
Date: Mon Sep 22 20:45:51 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: <48D707AF.100@freegeek.org>
References: <48D68F22.1090808@btinternet.com> <48D707AF.100@freegeek.org>
Message-ID: 



On Sun, 21 Sep 2008, wren ng thornton wrote:

> Even with functionalists ---of the OCaml and SML ilk--- 
> this use of spaces can be confusing if noone explains that function 
> application binds tighter than all operators.

Bwuh?  Ocaml programmers certainly know that application binds tighter 
than operators.  And as:

 	let f x y = ... in
 	f a b

is more efficient (in Ocaml) than:

 	let f (x, y) = ... in
 	f (a, b)

(Ocaml doesn't optimize away the tuple allocation), the former 
(Haskell-like) is generally preferred by Ocaml programmers.

SML programmers do use the second form, I'll grant you.

Brian

From bulat.ziganshin at gmail.com  Mon Sep 22 20:47:26 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 20:46:37 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080923003655.GC28014@scytale.galois.com>
References: 
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
	<20080923002219.GA28014@scytale.galois.com>
	<1881496506.20080923043152@gmail.com>
	<20080923003655.GC28014@scytale.galois.com>
Message-ID: <335305122.20080923044726@gmail.com>

Hello Don,

Tuesday, September 23, 2008, 4:36:55 AM, you wrote:

>> it isn't the same as readInt which was added specifically for this
>> test. it doesn't support arbitrary-size streams and doesn't return
>> rest of stream
>> 

> Hmm? That is wrong. These functions explicitly work on arbitrarily long
> lazy bytestrings, and return the rest of the stream in a pair:

lazy bytestring which is read from file on demand is the same as
arbitrary-sized stream. equivalent C code would be much faster (and
probably limited by memory speed)

>     readInt :: ByteString -> Maybe (Int, ByteString)
>     readInteger :: ByteString -> Maybe (Integer, ByteString)

> These are the initial parts of a bytestring lexing library, more of
> which is appareing in the bytestring-lex package on Hackage.

readInt was added to FPS library by you and immediately used to
improve speed of this benchmark two years ago. there was no
readInteger since shootout doesn't contain such benchmarks :)


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From bulat.ziganshin at gmail.com  Mon Sep 22 20:51:44 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Sep 22 20:50:26 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: 
References: <48D7698F.8040902@libero.it> <534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
	<20080923002219.GA28014@scytale.galois.com>
	<1881496506.20080923043152@gmail.com>
	
Message-ID: <309637767.20080923045144@gmail.com>

Hello Chadda?,

Tuesday, September 23, 2008, 4:39:18 AM, you wrote:

>> it isn't the same as readInt which was added specifically for this
>> test. it doesn't support arbitrary-size streams and doesn't return
>> rest of stream

> I think we should write all the entries in Haskell98 and disable any
> optimisation in GHC too, that would gives us a much fairer vision of
> Haskell current performances.

well, it's what C developers does. just look at full list of C and
Haskell entries for this benchmark - all qualified C programs used std
C/C++ libs, several really optimized entries was disqualified. and
then Don found genious solution to the problem - add this function to
GHC libs. or shootout wasn't first usage of this function?


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From s.clover at gmail.com  Mon Sep 22 21:13:57 2008
From: s.clover at gmail.com (Sterling Clover)
Date: Mon Sep 22 21:11:06 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1712911408.20080923041652@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>
	<64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
Message-ID: 

At the risk of getting sucked into a silly discussion, I'd like to point out
that the c code uses the following "really simple and naive" function:

http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/strtol.c?rev=1.42.2.2&content-type=text/x-cvsweb-markup&cvsroot=glibc


http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/strtol_l.c?rev=1.4.2.3&content-type=text/x-cvsweb-markup&cvsroot=glibc

Oh, and it "simply and naively" loops with the following:

    while (fgets_unlocked (line, MAXLINELEN, stdin))

If Bulat's point is that the shootout has inspired work on Haskell
performance, and in the stdlibs no less, then lovely, and that's all to the
good. Below every high level interface is lots of low level pain.

If his point is anything else, this is getting absurd.

--S

On Mon, Sep 22, 2008 at 8:16 PM, Bulat Ziganshin
wrote:

> Hello Don,
>
> Tuesday, September 23, 2008, 3:12:37 AM, you wrote:
>
> >> for the same reason i don't feed 5000 men with 7 breads - it's not my
> >> business ;)
>
> > Ok. So I'll just say: high level, efficient code is an overriding theme
> > of many individuals working on Haskell. Things are better and better
> > each year. We do not stand still.
>
> yes. when we say that things are greatly improving each year, this
> means that they was bad previously ;)
>
> > For example, Bulat cites a paper talking about naive list code from
> > 2002, however, by 2008 we know how to do fusion on lists, so it runs in
> > the same time as low level loops, the technique is implemented and you
> > can download it from hackage,
>
> > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion
>
> someone can ask why this great code isn't used in ghc by default.
> probably it is just work in progress which isn't yet ready to replace
> old slow code. then we can see tha fusion isn't magic wand which
> improves speed of every haskell code that's slower than C one. it just
> makes C-speed code sometimes
>
> > Simon Marlow is busy adding more efficient GC and parallelism to GHC,
> > and there's a summer project to rewrite the native code generator.
>
> well, i'm sais about *current* real situation. if you consider this as
> attack against Haskell developers, it's your mistake. the problem is
> that i many years wrote about slowness of ghc code, every time you
> cosider this as attack and write that in future Haskell will become
> much faster. we still wait for this future, however
>
> > GHC gained pointer tagging in the last release cycle, dramatically
> > reducing the cost of algebraic data types.
>
> 10-20% speed improvement, on average. it's the only real improvement
> (for my own program) i know. i think that ByteString-related libs
> gived more improvements but their use isn't automatic and they doesn't
> help in any situation. they just provide fast library code for solving
> some concrete (although very frequent) situations, such as counting
> lines
>
> > At the same time, we're writing books about how to program "naively" in
> > Haskell, such that your code doesn't suck. That is: training. Teaching
> > people how to write Haskell.
>
> it is what i say - if naive code was effective and automagically
> optimized by ghc, we don't need all those tutorials. anyone looked
> into your tutorial on writing efficient Haskell code, will never say
> that it's easier than in C. so we can conclude that optimized haskell
> programs are several times slower than C ones and need several times
> more to write
>
> > We can see it paying off, where naive code performs very very well,
>
> > http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all
>
> yes! it's my beloved example of "elegant" haskell code entirely based
> on the readInt function added to ghc libs specifically to win in this
> test. it's implementation is really simple and naive:
>
> -- ---------------------------------------------------------------------
> -- Reading from ByteStrings
>
> -- | readInt reads an Int from the beginning of the ByteString.  If there
> is no
> -- integer at the beginning of the string, it returns Nothing, otherwise
> -- it just returns the int read, and the rest of the string.
> readInt :: ByteString -> Maybe (Int, ByteString)
> readInt as
>    | null as   = Nothing
>    | otherwise =
>        case unsafeHead as of
>            '-' -> loop True  0 0 (unsafeTail as)
>            '+' -> loop False 0 0 (unsafeTail as)
>            _   -> loop False 0 0 as
>
>    where loop :: Bool -> Int -> Int -> ByteString -> Maybe (Int,
> ByteString)
>          STRICT4(loop)
>          loop neg i n ps
>              | null ps   = end neg i n ps
>              | otherwise =
>                  case B.unsafeHead ps of
>                    w | w >= 0x30
>                     && w <= 0x39 -> loop neg (i+1)
>                                          (n * 10 + (fromIntegral w - 0x30))
>                                          (unsafeTail ps)
>                      | otherwise -> end neg i n ps
>
>          end _    0 _ _  = Nothing
>          end True _ n ps = Just (negate n, ps)
>          end _    _ n ps = Just (n, ps)
>
>
>
> when gcc developers will start to add to C libraries functions
> performing shootout benchmarks we will continue this discussion :D
>
> > And lots and lots more people able to write good code for Hackage.
>
> > I find Bulat's outlook rather bleak, and I think it is time to update
> > expectations.
>
> > Progress is beautiful.
>
> :)
>
> --
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin@gmail.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/a461ca92/attachment.htm
From dagit at codersbase.com  Mon Sep 22 21:24:32 2008
From: dagit at codersbase.com (Jason Dagit)
Date: Mon Sep 22 21:21:40 2008
Subject: [Haskell-cafe] Line noise
In-Reply-To: 
References: <48D68F22.1090808@btinternet.com> <48D707AF.100@freegeek.org>
	
Message-ID: 

On Mon, Sep 22, 2008 at 6:27 PM, Brian Hurt  wrote:
>
>
> On Sun, 21 Sep 2008, wren ng thornton wrote:
>
>> Even with functionalists ---of the OCaml and SML ilk--- this use of spaces
>> can be confusing if noone explains that function application binds tighter
>> than all operators.
>
> Bwuh?  Ocaml programmers certainly know that application binds tighter than
> operators.  And as:
>
>        let f x y = ... in
>        f a b
>
> is more efficient (in Ocaml) than:
>
>        let f (x, y) = ... in
>        f (a, b)
>
> (Ocaml doesn't optimize away the tuple allocation), the former
> (Haskell-like) is generally preferred by Ocaml programmers.

That's odd.  My experience from trying to learn ocaml at one point was
that the tuple notation is preferable because you can do pattern
matching on every value in the tuple whereas with the other one you
can match on either the first or second parameter but not both without
nesting ocaml's version of 'case ... of' (match ... with?).  One of
the things I really like about Haskell syntax is that you can pattern
match on any number of parameters without having to nest 'case ... of'
expressions.

Jason
From jeremy at n-heptane.com  Mon Sep 22 21:46:22 2008
From: jeremy at n-heptane.com (Jeremy Shaw)
Date: Mon Sep 22 21:37:06 2008
Subject: [Haskell-cafe] Is there already an abstraction for this?
Message-ID: <87tzc7ocr5.wl%jeremy@n-heptane.com>

Hello,

I am trying to figure out if there is an existing abstraction I am
missing here.

I have an expression data-type:

> data Expr 
>    = Quotient Expr Expr
>    | Product Expr Expr
>    | Sum Expr Expr
>    | Difference Expr Expr
>    | Lit Double
>    | Var Char
>      deriving (Eq, Ord, Data, Typeable, Read, Show)
>

And I want to write a function that will take an expression and
automatically apply the identity laws to simplify the expression.

The basic identity laws are:

 a + 0 = a
 a * 1 = a

I can implement these with some 'sugar' as:

> identity (Sum (Lit 0) a)        = a
> identity (Sum a (Lit 0))        = a
> identity (Difference a (Lit 0)) = a
> identity (Product a (Lit 1))    = a
> identity (Product (Lit 1) a)    = a
> identity (Quotient a (Lit 1))   = a
> identity a                      = a

This works fine when the identity only needs to be applied to the root
of the expression tree:

*Main> ppExpr $ identity (expr "1 + 0")
1

But for more complicated trees it does not fully apply the identity laws:

*Main> ppExpr $ identity (expr "0 + (0 + 0) + (0 + 0)")
((0 + 0) + (0 + 0))

What we need to do is first apply the identity function to the
children, and then apply them to the parent of the updated children. A
first attempt would be to extend the identity function like this:

> identity (Sum a b)              = identity (Sum (identity a) (identity b))

However, that will not terminate because that same case will keep
matching over and over. Another approach is to have two mutually
recursive functions like:

> identity' (Sum (Lit 0) a)        = identityRec a
> identity' (Sum a (Lit 0))        = identityRec a
> identity' a = a

> identityRec (Sum a b) = identity' (Sum (identity' a) (identity' b))

This prevents non-termination, but you have to be careful about
calling identity' vs identityRec or you will either re-introduce
non-termination, or you may not fully apply the identity laws.

Another option to create a helper function like:

> -- |Deep map of an expression.
> eMap :: (Expr -> Expr) -> Expr -> Expr
> eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b))
> eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b))
> eMap f (Product a b) = f (Product (eMap f a) (eMap f b))
> eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b))
> eMap f (Var v) = f (Var v)
> eMap f (Lit i) = f (Lit i)

Now we can easily apply the identity law recursively like:

> deepIdentity :: Expr -> Expr
> deepIdentity = eMap identity

*Main> ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)"))
0

Sweet!

But, having to write eMap out by hand like that somehow feels wrong --
as if I am missing some additional abstraction. In some respects eMap
is like a Functor, but not quite. I expect there is a way to implement
eMap using Data.Generics, which is perhaps better, but I still feel
like that is missing something?

Anyway, I just thought I would ask in case someone recognized this
pattern and could point me in the right direction. I have attached a
working example program you can play with.

I would also be interested in alternative approaches besides the ones
I outlined.

thanks!
j.
-------------- next part --------------
>{-# LANGUAGE DeriveDataTypeable #-}
>
> import Control.Applicative (Applicative((<*>), pure), (*>), (<*))
> import Control.Monad (ap)
> import Data.Generics (Typeable, Data)
> import Data.List (isSuffixOf)
> import           Text.ParserCombinators.Parsec  ((<|>))
> import qualified Text.ParserCombinators.Parsec as P
> import qualified Text.ParserCombinators.Parsec.Expr as P
> import           Text.PrettyPrint.HughesPJ ((<+>))
> import qualified Text.PrettyPrint.HughesPJ as H
> import Prelude hiding (sum, product)
>
> data Expr 
>    = Quotient Expr Expr
>    | Product Expr Expr
>    | Sum Expr Expr
>    | Difference Expr Expr
>    | Lit Double
>    | Var Char
>      deriving (Eq, Ord, Data, Typeable, Read, Show)
>
> instance Applicative (P.GenParser token state) where
>     pure = return
>     (<*>) = ap
>
> parseExpr :: P.GenParser Char st Expr
> parseExpr = P.buildExpressionParser optable (lit <|> var <|> parenExpr)
>     where
>       parenExpr = 
>           (P.char '(' >> P.skipMany P.space) *> parseExpr <* (P.char ')' >> P.skipMany P.space)
>       optable = 
>           [ [ P.Infix (P.char '/' >> P.skipMany P.space >> return Quotient)  P.AssocLeft  ]
>           , [ P.Infix (P.char '*' >> P.skipMany P.space >> return Product)    P.AssocRight ]
>           , [ P.Infix (P.char '+' >> P.skipMany P.space >> return Sum)        P.AssocRight ]
>           , [ P.Infix (P.char '-' >> P.skipMany P.space >> return Difference) P.AssocLeft  ]
>           ]
>       lit = 
>           do d <- P.try (P.many1 $ P.oneOf ('-' : '.' : ['0'..'9']))
>              P.skipMany P.space
>              return (Lit (read d))
>       var =
>           do sign <- (P.char '-' >> return (\x -> (Product (Lit (-1)) x))) <|> (return id)
>              v <- (P.upper <|> P.lower)
>              P.skipMany P.space
>              return (sign (Var v))
>
> expr :: String -> Expr
> expr str = either (error .show) id (P.parse parseExpr str str)
>
> ppExpr :: Expr -> H.Doc
> ppExpr (Lit i)          = H.text (let f s = if isSuffixOf ".0" s then init(init s) else s in f $ show i)
> ppExpr (Var v)          = H.char v
> ppExpr (Quotient x y)   = H.parens (ppExpr x <+> H.char '/' <+> ppExpr y)
> ppExpr (Product x y)    = H.parens (ppExpr x <+> H.char '*' <+> ppExpr y)
> ppExpr (Sum x y)        = H.parens (ppExpr x <+> H.char '+' <+> ppExpr y)
> ppExpr (Difference x y) = H.parens (ppExpr x <+> H.char '-' <+> ppExpr y)

> -- |Deep map of an expression.
> eMap :: (Expr -> Expr) -> Expr -> Expr
> eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b))
> eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b))
> eMap f (Product a b) = f (Product (eMap f a) (eMap f b))
> eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b))
> eMap f (Var v) = f (Var v)
> eMap f (Lit i) = f (Lit i)

> identity (Sum (Lit 0) a)        = a
> identity (Sum a (Lit 0))        = a
> identity (Difference a (Lit 0)) = a
> identity (Product a (Lit 1))    = a
> identity (Product (Lit 1) a)    = a
> identity (Quotient a (Lit 1))   = a
> identity a                      = a

> deepIdentity :: Expr -> Expr
> deepIdentity = eMap identity

> test :: IO ()
> test =
>     do print (ppExpr (deepIdentity (expr "1 + 2")))
>        print (ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)")))
From westondan at imageworks.com  Mon Sep 22 21:54:04 2008
From: westondan at imageworks.com (Dan Weston)
Date: Mon Sep 22 21:51:16 2008
Subject: [Haskell-cafe] Is there already an abstraction for this?
In-Reply-To: <87tzc7ocr5.wl%jeremy@n-heptane.com>
References: <87tzc7ocr5.wl%jeremy@n-heptane.com>
Message-ID: <48D84C3C.40205@imageworks.com>

 > I can implement these with some 'sugar' as:
 >
 >> identity (Sum (Lit 0) a)        = a
 >> identity (Sum a (Lit 0))        = a
 >> identity (Difference a (Lit 0)) = a
 >> identity (Product a (Lit 1))    = a
 >> identity (Product (Lit 1) a)    = a
 >> identity (Quotient a (Lit 1))   = a
 >> identity a                      = a

Why do you need mutual recursion? What's wrong with:

  identity (Sum (Lit 0) a)        = identity a
   ...
  identity (Quotient a (Lit 1))   = identity a
  identity a                      = a

Structural recursion ensures that this always terminates.

Dan

Jeremy Shaw wrote:
> Hello,
> 
> I am trying to figure out if there is an existing abstraction I am
> missing here.
> 
> I have an expression data-type:
> 
>> data Expr 
>>    = Quotient Expr Expr
>>    | Product Expr Expr
>>    | Sum Expr Expr
>>    | Difference Expr Expr
>>    | Lit Double
>>    | Var Char
>>      deriving (Eq, Ord, Data, Typeable, Read, Show)
>>
> 
> And I want to write a function that will take an expression and
> automatically apply the identity laws to simplify the expression.
> 
> The basic identity laws are:
> 
>  a + 0 = a
>  a * 1 = a
> 
> I can implement these with some 'sugar' as:
> 
>> identity (Sum (Lit 0) a)        = a
>> identity (Sum a (Lit 0))        = a
>> identity (Difference a (Lit 0)) = a
>> identity (Product a (Lit 1))    = a
>> identity (Product (Lit 1) a)    = a
>> identity (Quotient a (Lit 1))   = a
>> identity a                      = a
> 
> This works fine when the identity only needs to be applied to the root
> of the expression tree:
> 
> *Main> ppExpr $ identity (expr "1 + 0")
> 1
> 
> But for more complicated trees it does not fully apply the identity laws:
> 
> *Main> ppExpr $ identity (expr "0 + (0 + 0) + (0 + 0)")
> ((0 + 0) + (0 + 0))
> 
> What we need to do is first apply the identity function to the
> children, and then apply them to the parent of the updated children. A
> first attempt would be to extend the identity function like this:
> 
>> identity (Sum a b)              = identity (Sum (identity a) (identity b))
> 
> However, that will not terminate because that same case will keep
> matching over and over. Another approach is to have two mutually
> recursive functions like:
> 
>> identity' (Sum (Lit 0) a)        = identityRec a
>> identity' (Sum a (Lit 0))        = identityRec a
>> identity' a = a
> 
>> identityRec (Sum a b) = identity' (Sum (identity' a) (identity' b))
> 
> This prevents non-termination, but you have to be careful about
> calling identity' vs identityRec or you will either re-introduce
> non-termination, or you may not fully apply the identity laws.
> 
> Another option to create a helper function like:
> 
>> -- |Deep map of an expression.
>> eMap :: (Expr -> Expr) -> Expr -> Expr
>> eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b))
>> eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b))
>> eMap f (Product a b) = f (Product (eMap f a) (eMap f b))
>> eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b))
>> eMap f (Var v) = f (Var v)
>> eMap f (Lit i) = f (Lit i)
> 
> Now we can easily apply the identity law recursively like:
> 
>> deepIdentity :: Expr -> Expr
>> deepIdentity = eMap identity
> 
> *Main> ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)"))
> 0
> 
> Sweet!
> 
> But, having to write eMap out by hand like that somehow feels wrong --
> as if I am missing some additional abstraction. In some respects eMap
> is like a Functor, but not quite. I expect there is a way to implement
> eMap using Data.Generics, which is perhaps better, but I still feel
> like that is missing something?
> 
> Anyway, I just thought I would ask in case someone recognized this
> pattern and could point me in the right direction. I have attached a
> working example program you can play with.
> 
> I would also be interested in alternative approaches besides the ones
> I outlined.
> 
> thanks!
> j.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


From westondan at imageworks.com  Mon Sep 22 21:55:26 2008
From: westondan at imageworks.com (Dan Weston)
Date: Mon Sep 22 21:53:08 2008
Subject: [Haskell-cafe] Is there already an abstraction for this?
In-Reply-To: <48D84C3C.40205@imageworks.com>
References: <87tzc7ocr5.wl%jeremy@n-heptane.com>
	<48D84C3C.40205@imageworks.com>
Message-ID: <48D84C8E.2010300@imageworks.com>

Oops, never mind. This is just the shallow application you referred to. 
Too fast with that send button!

Dan Weston wrote:
> 
>  > I can implement these with some 'sugar' as:
>  >
>  >> identity (Sum (Lit 0) a)        = a
>  >> identity (Sum a (Lit 0))        = a
>  >> identity (Difference a (Lit 0)) = a
>  >> identity (Product a (Lit 1))    = a
>  >> identity (Product (Lit 1) a)    = a
>  >> identity (Quotient a (Lit 1))   = a
>  >> identity a                      = a
> 
> Why do you need mutual recursion? What's wrong with:
> 
>  identity (Sum (Lit 0) a)        = identity a
>   ...
>  identity (Quotient a (Lit 1))   = identity a
>  identity a                      = a
> 
> Structural recursion ensures that this always terminates.
> 
> Dan
> 
> Jeremy Shaw wrote:
>> Hello,
>>
>> I am trying to figure out if there is an existing abstraction I am
>> missing here.
>>
>> I have an expression data-type:
>>
>>> data Expr    = Quotient Expr Expr
>>>    | Product Expr Expr
>>>    | Sum Expr Expr
>>>    | Difference Expr Expr
>>>    | Lit Double
>>>    | Var Char
>>>      deriving (Eq, Ord, Data, Typeable, Read, Show)
>>>
>>
>> And I want to write a function that will take an expression and
>> automatically apply the identity laws to simplify the expression.
>>
>> The basic identity laws are:
>>
>>  a + 0 = a
>>  a * 1 = a
>>
>> I can implement these with some 'sugar' as:
>>
>>> identity (Sum (Lit 0) a)        = a
>>> identity (Sum a (Lit 0))        = a
>>> identity (Difference a (Lit 0)) = a
>>> identity (Product a (Lit 1))    = a
>>> identity (Product (Lit 1) a)    = a
>>> identity (Quotient a (Lit 1))   = a
>>> identity a                      = a
>>
>> This works fine when the identity only needs to be applied to the root
>> of the expression tree:
>>
>> *Main> ppExpr $ identity (expr "1 + 0")
>> 1
>>
>> But for more complicated trees it does not fully apply the identity laws:
>>
>> *Main> ppExpr $ identity (expr "0 + (0 + 0) + (0 + 0)")
>> ((0 + 0) + (0 + 0))
>>
>> What we need to do is first apply the identity function to the
>> children, and then apply them to the parent of the updated children. A
>> first attempt would be to extend the identity function like this:
>>
>>> identity (Sum a b)              = identity (Sum (identity a) 
>>> (identity b))
>>
>> However, that will not terminate because that same case will keep
>> matching over and over. Another approach is to have two mutually
>> recursive functions like:
>>
>>> identity' (Sum (Lit 0) a)        = identityRec a
>>> identity' (Sum a (Lit 0))        = identityRec a
>>> identity' a = a
>>
>>> identityRec (Sum a b) = identity' (Sum (identity' a) (identity' b))
>>
>> This prevents non-termination, but you have to be careful about
>> calling identity' vs identityRec or you will either re-introduce
>> non-termination, or you may not fully apply the identity laws.
>>
>> Another option to create a helper function like:
>>
>>> -- |Deep map of an expression.
>>> eMap :: (Expr -> Expr) -> Expr -> Expr
>>> eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b))
>>> eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b))
>>> eMap f (Product a b) = f (Product (eMap f a) (eMap f b))
>>> eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b))
>>> eMap f (Var v) = f (Var v)
>>> eMap f (Lit i) = f (Lit i)
>>
>> Now we can easily apply the identity law recursively like:
>>
>>> deepIdentity :: Expr -> Expr
>>> deepIdentity = eMap identity
>>
>> *Main> ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)"))
>> 0
>>
>> Sweet!
>>
>> But, having to write eMap out by hand like that somehow feels wrong --
>> as if I am missing some additional abstraction. In some respects eMap
>> is like a Functor, but not quite. I expect there is a way to implement
>> eMap using Data.Generics, which is perhaps better, but I still feel
>> like that is missing something?
>>
>> Anyway, I just thought I would ask in case someone recognized this
>> pattern and could point me in the right direction. I have attached a
>> working example program you can play with.
>>
>> I would also be interested in alternative approaches besides the ones
>> I outlined.
>>
>> thanks!
>> j.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 


From aeyakovenko at gmail.com  Mon Sep 22 22:20:59 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Mon Sep 22 22:18:07 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
Message-ID: 

> data Nat a where
>    Z :: Nat a
>    S :: Nat a -> Nat (S a)
>
> data Z
> data S a
>
> n00 = Z
> n01 = S n00
> n02 = S n01
> n03 = S n02
> n04 = S n03
>
> data MaxList t where
>   Nil :: MaxList a
>   Cons :: Nat a -> MaxList a -> MaxList a
>
> a = Cons n02 $ Cons n02 $ Cons n01 $ Nil
> --- ":t a" gives "forall a. MaxList (S (S a))" which tells you exactly
> --- what you want: elements are at least 2.
>
> mlTail :: forall t. MaxList t -> MaxList t
> mlTail (Cons h t) = t

Is there a way to define a function that only takes a list with a max
of 1?  Because

only1 :: MaxList (S a) -> String
only1 _ = "only1"

will work over
> a = Cons n02 $ Cons n02 $ Cons n01 $ Nil
without any problems
From sebf at informatik.uni-kiel.de  Mon Sep 22 22:39:30 2008
From: sebf at informatik.uni-kiel.de (Sebastian Fischer)
Date: Mon Sep 22 22:37:31 2008
Subject: [Haskell-cafe] Is there already an abstraction for this?
In-Reply-To: <87tzc7ocr5.wl%jeremy@n-heptane.com>
References: <87tzc7ocr5.wl%jeremy@n-heptane.com>
Message-ID: <66B334E0-B636-4EDC-90A9-753578875D11@informatik.uni-kiel.de>

Hi Jeremy,

There are some approaches that support such generic transformations.  
The simplest is probably Uniplate by Neil Mitchell:

   http://www-users.cs.york.ac.uk/~ndm/uniplate/

The function 'rewrite' is what you are looking for. If you change the  
definition of 'identity' to:

> identity (Sum (Lit 0) a)        = Just a
> identity (Sum a (Lit 0))        = Just a
> identity (Difference a (Lit 0)) = Just a
> identity (Product a (Lit 1))    = Just a
> identity (Product (Lit 1) a)    = Just a
> identity (Quotient a (Lit 1))   = Just a
> identity _                      = Nothing

then the function 'rewrite identity :: Expr -> Expr' does what you want.

Cheers,
Sebastian
From dave at zednenem.com  Mon Sep 22 23:03:18 2008
From: dave at zednenem.com (David Menendez)
Date: Mon Sep 22 23:00:25 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
	
Message-ID: <49a77b7a0809222003v3ff6fe3bhd25afc4a1f62f73c@mail.gmail.com>

On Mon, Sep 22, 2008 at 10:20 PM, Anatoly Yakovenko
 wrote:
>
> Is there a way to define a function that only takes a list with a max
> of 1?  Because
>
> only1 :: MaxList (S a) -> String
> only1 _ = "only1"
>
> will work over
>> a = Cons n02 $ Cons n02 $ Cons n01 $ Nil
> without any problems

only1 :: MaxList (S Z) -> String

If you like, you may declare

type One = S Z
type Two = S One
etc.

-- 
Dave Menendez 

From aeyakovenko at gmail.com  Mon Sep 22 23:10:44 2008
From: aeyakovenko at gmail.com (Anatoly Yakovenko)
Date: Mon Sep 22 23:07:52 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: <49a77b7a0809222003v3ff6fe3bhd25afc4a1f62f73c@mail.gmail.com>
References: 
	
	
	<49a77b7a0809222003v3ff6fe3bhd25afc4a1f62f73c@mail.gmail.com>
Message-ID: 

> type One = S Z
> type Two = S One
> etc.

why does:

data Nat a where
   Z :: Nat a
   S :: Nat a -> Nat (S a)

data Z
data S a

type One = S Z
n00 = Z
n01::One = S n00

give me:

test.hs:10:11:
    Couldn't match expected type `One'
           against inferred type `Nat (S a)'
    In the expression: S n00
    In a pattern binding: n01 :: One = S n00
Failed, modules loaded: none.


or better yet, how is type S Z different from, n01 :: forall a. Nat (S a)
From ryani.spam at gmail.com  Tue Sep 23 00:27:35 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Tue Sep 23 00:24:45 2008
Subject: [Haskell-cafe] Bird-style and blank lines
In-Reply-To: <2f9b2d30809212213yc0691amc7b8e33431984149@mail.gmail.com>
References: 
	<2f9b2d30809212213yc0691amc7b8e33431984149@mail.gmail.com>
Message-ID: <2f9b2d30809222127p44c3c301ye6fb17bf39e032a7@mail.gmail.com>

Oops, meant to send this to the whole list.

> You can add "-optL -q" to your ghc command line to disable that
> behavior; blank lines will no longer be required.

  -- ryan
From ryani.spam at gmail.com  Tue Sep 23 00:31:17 2008
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Tue Sep 23 00:28:28 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
	
	<49a77b7a0809222003v3ff6fe3bhd25afc4a1f62f73c@mail.gmail.com>
	
Message-ID: <2f9b2d30809222131i61db1bdcg2e362ee020a6da3b@mail.gmail.com>

Try

n01 :: Nat One

  -- ryan

On Mon, Sep 22, 2008 at 8:10 PM, Anatoly Yakovenko
 wrote:
>> type One = S Z
>> type Two = S One
>> etc.
>
> why does:
>
> data Nat a where
>   Z :: Nat a
>   S :: Nat a -> Nat (S a)
>
> data Z
> data S a
>
> type One = S Z
> n00 = Z
> n01::One = S n00
>
> give me:
>
> test.hs:10:11:
>    Couldn't match expected type `One'
>           against inferred type `Nat (S a)'
>    In the expression: S n00
>    In a pattern binding: n01 :: One = S n00
> Failed, modules loaded: none.
>
>
> or better yet, how is type S Z different from, n01 :: forall a. Nat (S a)
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From tanimoto at arizona.edu  Tue Sep 23 00:40:46 2008
From: tanimoto at arizona.edu (Paulo Tanimoto)
Date: Tue Sep 23 00:37:54 2008
Subject: [Haskell-cafe] Bird-style and blank lines
In-Reply-To: <2f9b2d30809222127p44c3c301ye6fb17bf39e032a7@mail.gmail.com>
References: 
	<2f9b2d30809212213yc0691amc7b8e33431984149@mail.gmail.com>
	<2f9b2d30809222127p44c3c301ye6fb17bf39e032a7@mail.gmail.com>
Message-ID: 

On Mon, Sep 22, 2008 at 11:27 PM, Ryan Ingram  wrote:
> Oops, meant to send this to the whole list.
>
>> You can add "-optL -q" to your ghc command line to disable that
>> behavior; blank lines will no longer be required.

This little gem that Ryan found was exactly what I was looking for,
thank you again, Ryan.  So this is already possible in GHC, which is
what I use.  The question now is whether this is relevant enough to be
brought to the attention of people discussing Haskell Prime.  If you
think it is, let me know, I'll see what I have to do about it.

I'll update the Wiki with this information.

Thanks everybody,

Paulo
From chris at eidhof.nl  Tue Sep 23 00:45:49 2008
From: chris at eidhof.nl (Chris Eidhof)
Date: Tue Sep 23 00:43:14 2008
Subject: [Haskell-cafe] Updated formlets sample?
In-Reply-To: <48D7CC38.6010205@gmx.org>
References: <48D3898B.5070904@gmx.org>
	<20898DDF-5BF7-4FA1-8BAF-881D57C57CB8@eidhof.nl>
	<48D69C5A.2040505@gmx.org>
	<33E9F827-BE88-4916-B30D-DFDD56FC4868@eidhof.nl>
	<48D7CC38.6010205@gmx.org>
Message-ID: <36A3811B-6B4C-44B7-B2B6-F38B09CA1A49@eidhof.nl>

Ah yes, I just adjusted the code until it compiled, I must confess I  
didn't check whether it actually worked ;). Thanks for the wiki-update!

-chris

On 22 sep 2008, at 09:47, Martin Huschenbett wrote:

> Hi Chris,
>
> you're absolutely right. The mistake was in the where-part of  
> withForm. The function handleOk' gets an environment d as argument  
> but uses an extractor that was created without passing d to  
> runFormState. I've put a corrected version on hpaste [1] and also  
> posted it to the wiki on haskell.org [2]. Hope this is ok for you?
>
> Regards,
>
> Martin.
>
> [1] http://hpaste.org/10568#a1
> [2] http://haskell.org/haskellwiki/Formlets
>
> Chris Eidhof schrieb:
>> That means that you don't have input0 in your environment, maybe  
>> you're passing in an empty environment?
>> -chris
>> On 21 sep 2008, at 12:11, Martin Huschenbett wrote:
>>> Hi Chris,
>>>
>>> thanks for the updated example. Compiling works now. But when I  
>>> try to run it I alway get error messages like
>>>
>>> ["input0 is not in the data","input1 is not in the data"]
>>>
>>> Regards,
>>>
>>> Martin.
>>>
>>> Chris Eidhof schrieb:
>>>> Hey Martin,
>>>> On 19 sep 2008, at 04:14, Martin Huschenbett wrote:
>>>>> I found a blog post concerning formlets [1] in the web. Since  
>>>>> looks very interesting I tried to compile the sample code with  
>>>>> recent versions of HAppS and formlets from hackage. But this  
>>>>> didn't work as the API of formlets has changed since this post.
>>>>>
>>>>> I tried to adopt the code to the new API but I was unable to  
>>>>> finish this since there is a new monadic context I don't know to  
>>>>> handle in the right way.
>>>>>
>>>>> So my question is, is there an updated version of this sample  
>>>>> code in the web or has anybody tried to adopt it and can send me  
>>>>> the results?
>>>> Yes, I'm sorry for that. The API is still very immature and due  
>>>> to changes, that's also why it hasn't been officially announced  
>>>> yet. I've just put an updated example at http://hpaste.org/10568,  
>>>> hope that'll work for you. I guess we should build a small  
>>>> homepage / wikipage that always has an up-to-date example.
>>>> -chris

From nicolas.pouillard at gmail.com  Tue Sep 23 00:47:44 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Tue Sep 23 00:45:40 2008
Subject: [Haskell-cafe] Is there already an abstraction for this?
In-Reply-To: <87tzc7ocr5.wl%jeremy@n-heptane.com>
References: <87tzc7ocr5.wl%jeremy@n-heptane.com>
Message-ID: <1222145100-sup-7323@ausone.local>

Excerpts from Jeremy Shaw's message of Mon Sep 22 18:46:22 -0700 2008:
> Hello,
> 
> I am trying to figure out if there is an existing abstraction I am
> missing here.

You can try to pick some information in the mocac [1] project, that is for
OCaml.

 <<
  Moca is a general construction functions generator for Caml data types with
  invariants.

  Moca supports two kinds of relations:

  * algebraic relations (such as associativity or commutativity of a
    binary constructor),
  * general rewrite rules that map some pattern of constructors and
    variables to some arbitrary user's define expression.
 >>

[1]: http://moca.inria.fr/eng.htm

Best regards,

> I have an expression data-type:
> 
> > data Expr 
> >    = Quotient Expr Expr
> >    | Product Expr Expr
> >    | Sum Expr Expr
> >    | Difference Expr Expr
> >    | Lit Double
> >    | Var Char
> >      deriving (Eq, Ord, Data, Typeable, Read, Show)
> >
> 
> And I want to write a function that will take an expression and
> automatically apply the identity laws to simplify the expression.
> 
> The basic identity laws are:
> 
>  a + 0 = a
>  a * 1 = a
> 
> I can implement these with some 'sugar' as:
> 
> > identity (Sum (Lit 0) a)        = a
> > identity (Sum a (Lit 0))        = a
> > identity (Difference a (Lit 0)) = a
> > identity (Product a (Lit 1))    = a
> > identity (Product (Lit 1) a)    = a
> > identity (Quotient a (Lit 1))   = a
> > identity a                      = a
> 
> This works fine when the identity only needs to be applied to the root
> of the expression tree:
> 
> *Main> ppExpr $ identity (expr "1 + 0")
> 1
> 
> But for more complicated trees it does not fully apply the identity laws:
> 
> *Main> ppExpr $ identity (expr "0 + (0 + 0) + (0 + 0)")
> ((0 + 0) + (0 + 0))
> 
> What we need to do is first apply the identity function to the
> children, and then apply them to the parent of the updated children. A
> first attempt would be to extend the identity function like this:
> 
> > identity (Sum a b)              = identity (Sum (identity a) (identity b))
> 
> However, that will not terminate because that same case will keep
> matching over and over. Another approach is to have two mutually
> recursive functions like:
> 
> > identity' (Sum (Lit 0) a)        = identityRec a
> > identity' (Sum a (Lit 0))        = identityRec a
> > identity' a = a
> 
> > identityRec (Sum a b) = identity' (Sum (identity' a) (identity' b))
> 
> This prevents non-termination, but you have to be careful about
> calling identity' vs identityRec or you will either re-introduce
> non-termination, or you may not fully apply the identity laws.
> 
> Another option to create a helper function like:
> 
> > -- |Deep map of an expression.
> > eMap :: (Expr -> Expr) -> Expr -> Expr
> > eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b))
> > eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b))
> > eMap f (Product a b) = f (Product (eMap f a) (eMap f b))
> > eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b))
> > eMap f (Var v) = f (Var v)
> > eMap f (Lit i) = f (Lit i)
> 
> Now we can easily apply the identity law recursively like:
> 
> > deepIdentity :: Expr -> Expr
> > deepIdentity = eMap identity
> 
> *Main> ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)"))
> 0
> 
> Sweet!
> 
> But, having to write eMap out by hand like that somehow feels wrong --
> as if I am missing some additional abstraction. In some respects eMap
> is like a Functor, but not quite. I expect there is a way to implement
> eMap using Data.Generics, which is perhaps better, but I still feel
> like that is missing something?
> 
> Anyway, I just thought I would ask in case someone recognized this
> pattern and could point me in the right direction. I have attached a
> working example program you can play with.
> 
> I would also be interested in alternative approaches besides the ones
> I outlined.
> 
> thanks!
> j.
> >{-# LANGUAGE DeriveDataTypeable #-}
> >
> > import Control.Applicative (Applicative((<*>), pure), (*>), (<*))
> > import Control.Monad (ap)
> > import Data.Generics (Typeable, Data)
> > import Data.List (isSuffixOf)
> > import           Text.ParserCombinators.Parsec  ((<|>))
> > import qualified Text.ParserCombinators.Parsec as P
> > import qualified Text.ParserCombinators.Parsec.Expr as P
> > import           Text.PrettyPrint.HughesPJ ((<+>))
> > import qualified Text.PrettyPrint.HughesPJ as H
> > import Prelude hiding (sum, product)
> >
> > data Expr 
> >    = Quotient Expr Expr
> >    | Product Expr Expr
> >    | Sum Expr Expr
> >    | Difference Expr Expr
> >    | Lit Double
> >    | Var Char
> >      deriving (Eq, Ord, Data, Typeable, Read, Show)
> >
> > instance Applicative (P.GenParser token state) where
> >     pure = return
> >     (<*>) = ap
> >
> > parseExpr :: P.GenParser Char st Expr
> > parseExpr = P.buildExpressionParser optable (lit <|> var <|> parenExpr)
> >     where
> >       parenExpr = 
> >           (P.char '(' >> P.skipMany P.space) *> parseExpr <* (P.char ')' >> P.skipMany P.space)
> >       optable = 
> >           [ [ P.Infix (P.char '/' >> P.skipMany P.space >> return Quotient)  P.AssocLeft  ]
> >           , [ P.Infix (P.char '*' >> P.skipMany P.space >> return Product)    P.AssocRight ]
> >           , [ P.Infix (P.char '+' >> P.skipMany P.space >> return Sum)        P.AssocRight ]
> >           , [ P.Infix (P.char '-' >> P.skipMany P.space >> return Difference) P.AssocLeft  ]
> >           ]
> >       lit = 
> >           do d <- P.try (P.many1 $ P.oneOf ('-' : '.' : ['0'..'9']))
> >              P.skipMany P.space
> >              return (Lit (read d))
> >       var =
> >           do sign <- (P.char '-' >> return (\x -> (Product (Lit (-1)) x))) <|> (return id)
> >              v <- (P.upper <|> P.lower)
> >              P.skipMany P.space
> >              return (sign (Var v))
> >
> > expr :: String -> Expr
> > expr str = either (error .show) id (P.parse parseExpr str str)
> >
> > ppExpr :: Expr -> H.Doc
> > ppExpr (Lit i)          = H.text (let f s = if isSuffixOf ".0" s then init(init s) else s in f $ show i)
> > ppExpr (Var v)          = H.char v
> > ppExpr (Quotient x y)   = H.parens (ppExpr x <+> H.char '/' <+> ppExpr y)
> > ppExpr (Product x y)    = H.parens (ppExpr x <+> H.char '*' <+> ppExpr y)
> > ppExpr (Sum x y)        = H.parens (ppExpr x <+> H.char '+' <+> ppExpr y)
> > ppExpr (Difference x y) = H.parens (ppExpr x <+> H.char '-' <+> ppExpr y)
> 
> > -- |Deep map of an expression.
> > eMap :: (Expr -> Expr) -> Expr -> Expr
> > eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b))
> > eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b))
> > eMap f (Product a b) = f (Product (eMap f a) (eMap f b))
> > eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b))
> > eMap f (Var v) = f (Var v)
> > eMap f (Lit i) = f (Lit i)
> 
> > identity (Sum (Lit 0) a)        = a
> > identity (Sum a (Lit 0))        = a
> > identity (Difference a (Lit 0)) = a
> > identity (Product a (Lit 1))    = a
> > identity (Product (Lit 1) a)    = a
> > identity (Quotient a (Lit 1))   = a
> > identity a                      = a
> 
> > deepIdentity :: Expr -> Expr
> > deepIdentity = eMap identity
> 
> > test :: IO ()
> > test =
> >     do print (ppExpr (deepIdentity (expr "1 + 2")))
> >        print (ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)")))

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/c21b294a/signature.bin
From jason.dusek at gmail.com  Tue Sep 23 00:58:48 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Tue Sep 23 00:55:56 2008
Subject: [Haskell-cafe] what is the magic hash?
Message-ID: <42784f260809222158m11d718b4sbbd7809f7735e757@mail.gmail.com>

  It is not much covered in the docs. It has something to do
  with magic triggered by a postfix octothorpe?

--
_jsn

 |...docs.|
  http://haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html
From derek.a.elkins at gmail.com  Tue Sep 23 01:08:40 2008
From: derek.a.elkins at gmail.com (Derek Elkins)
Date: Tue Sep 23 01:05:51 2008
Subject: [Haskell-cafe] what is the magic hash?
In-Reply-To: <42784f260809222158m11d718b4sbbd7809f7735e757@mail.gmail.com>
References: <42784f260809222158m11d718b4sbbd7809f7735e757@mail.gmail.com>
Message-ID: <1222146520.13564.0.camel@derek-laptop>

On Mon, 2008-09-22 at 21:58 -0700, Jason Dusek wrote:
> It is not much covered in the docs. It has something to do
>   with magic triggered by a postfix octothorpe?

All it does is allow them in identifiers.

From jason.dusek at gmail.com  Tue Sep 23 01:21:29 2008
From: jason.dusek at gmail.com (Jason Dusek)
Date: Tue Sep 23 01:18:37 2008
Subject: [Haskell-cafe] what is the magic hash?
In-Reply-To: <1222146520.13564.0.camel@derek-laptop>
References: <42784f260809222158m11d718b4sbbd7809f7735e757@mail.gmail.com>
	<1222146520.13564.0.camel@derek-laptop>
Message-ID: <42784f260809222221p2f33b76eq2211027df3934754@mail.gmail.com>

Derek Elkins  wrote:
> Jason Dusek wrote:
>> It is not much covered in the docs. It has something to do
>>   with magic triggered by a postfix octothorpe?
>
> All it does is allow them in identifiers.

  That's it? So it's for use in conjunction with primitive
  types, I guess (those seem to be denoted like 'Int#')?

  With the fancy name and the absence of documentation, I
  assumed it must be really special.

--
_jsn
From dave at zednenem.com  Tue Sep 23 01:23:39 2008
From: dave at zednenem.com (David Menendez)
Date: Tue Sep 23 01:20:46 2008
Subject: [Haskell-cafe] Re: having fun with GADT's
In-Reply-To: 
References: 
	
	
	<49a77b7a0809222003v3ff6fe3bhd25afc4a1f62f73c@mail.gmail.com>
	
Message-ID: <49a77b7a0809222223w5ae08182w4a11fdf1c5e0ccd0@mail.gmail.com>

On Mon, Sep 22, 2008 at 11:10 PM, Anatoly Yakovenko
 wrote:
>> type One = S Z
>> type Two = S One
>> etc.
>
> why does:
>
> data Nat a where
>   Z :: Nat a
>   S :: Nat a -> Nat (S a)
>
> data Z
> data S a
>
> type One = S Z
> n00 = Z
> n01::One = S n00
>
> give me:
>
> test.hs:10:11:
>    Couldn't match expected type `One'
>           against inferred type `Nat (S a)'
>    In the expression: S n00
>    In a pattern binding: n01 :: One = S n00
> Failed, modules loaded: none.
>
>
> or better yet, how is type S Z different from, n01 :: forall a. Nat (S a)
>

In short, S Z is a type and n01 is a value.

One point that's important to keep in mind is that types and data
constructors have disjoint namespaces, so you can have a type Z and a
data constructor Z which do not need to have any connection.

It may be clearer if we rename the data constructors for Nat.

data Z
data S n

type One = S Z

data Nat :: * -> * where
    Zero :: Nat Z
    Succ :: Nat n -> Nat (S n)

one :: Nat One
one = Succ Zero

Similarly, One is a type (One :: *) and one is a value (one :: Nat One
and Nat One :: *).

Note also that Z and S are declared here as empty types, using a
common extension. That means there are no (non-bottom) values that
have type Z or S a. This means that Z and S are only used as arguments
to other type constructors or in class contexts.

As long as we're discussing type-level naturals, you may find this old
post of mine interesting.



-- 
Dave Menendez 

From jake at pikewerks.com  Tue Sep 23 02:01:32 2008
From: jake at pikewerks.com (Jake Mcarthur)
Date: Tue Sep 23 01:58:41 2008
Subject: [Haskell-cafe] Is there already an abstraction for this?
In-Reply-To: <87tzc7ocr5.wl%jeremy@n-heptane.com>
References: <87tzc7ocr5.wl%jeremy@n-heptane.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The first thing I thought of was to try to apply one of the recursion  
schemes
in the category-extras package. Here is what I managed using  
catamorphism.

- - Jake

- --------------------------------------------------------------------------------

data Expr' a
   = Quotient a a
   | Product a a
   | Sum a a
   | Difference a a
   | Lit Double
   | Var Char

type Expr = FixF Expr'

instance Functor Expr' where
     fmap f (a `Quotient` b) = f a `Quotient` f b
     fmap f (a `Product` b) = f a `Product` f b
     fmap f (a `Sum` b) = f a `Sum` f b
     fmap f (a `Difference` b) = f a `Difference` f b
     fmap _ (Lit x) = Lit x
     fmap _ (Var x) = Var x

identity = cata ident
     where ident (a `Quotient` InF (Lit 1)) = a
           ident (a `Product` InF (Lit 1)) = a
           ident (InF (Lit 1) `Product` b) = b
           ident (a `Sum` InF (Lit 0)) = a
           ident (InF (Lit 0) `Sum` b) = b
           ident (a `Difference` InF (Lit 0)) = a
           ident (Lit x) = InF $ Lit x
           ident (Var x) = InF $ Var x
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjYhjwACgkQye5hVyvIUKnwhgCgypz0ppFgqn2dMhoJPUzO4+J1
BMUAni277vm9d2e5wTFt2Qrx+DDVjs6z
=0SHe
-----END PGP SIGNATURE-----
From nicolas.pouillard at gmail.com  Tue Sep 23 02:15:36 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Tue Sep 23 02:13:33 2008
Subject: [Haskell-cafe] ANN: A Functional Implementation of the Garsia-Wachs
	Algorithm
Message-ID: <1222150409-sup-3142@ausone.local>

Hi All,

Here is an Haskell implementation of an algorithm that builds a binary tree with
minimum weighted path length from weighted leaf nodes given in symmetric order.

This can be used to build optimum search tables, to balance a
'ropes' data structure in an optimal way.

This module a direct translation from OCaml of a functional pearl
by Jean-Christophe Filli?tre yesterday on ML Workshop 2008.

There was an interesting point to porting it to Haskell, indeed there is a
crucial use of first-class references used only locally. A good reason to
show the power of the ST monad and it's runST function!

Here is the hackage URL:
  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/garsia-wachs

And the darcs 2 URL:
  http://darcs.feydakins.org/garsia-wachs

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/f36af8a2/signature.bin
From dons at galois.com  Tue Sep 23 02:19:19 2008
From: dons at galois.com (Don Stewart)
Date: Tue Sep 23 02:16:24 2008
Subject: [Haskell-cafe] ANN: A Functional Implementation of the
	Garsia-Wachs Algorithm
In-Reply-To: <1222150409-sup-3142@ausone.local>
References: <1222150409-sup-3142@ausone.local>
Message-ID: <20080923061919.GC28514@scytale.galois.com>

nicolas.pouillard:
> Hi All,
> 
> Here is an Haskell implementation of an algorithm that builds a binary tree with
> minimum weighted path length from weighted leaf nodes given in symmetric order.
> 
> This can be used to build optimum search tables, to balance a
> 'ropes' data structure in an optimal way.
> 
> This module a direct translation from OCaml of a functional pearl
> by Jean-Christophe Filli?tre yesterday on ML Workshop 2008.
> 
> There was an interesting point to porting it to Haskell, indeed there is a
> crucial use of first-class references used only locally. A good reason to
> show the power of the ST monad and it's runST function!
> 
> Here is the hackage URL:
>   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/garsia-wachs
> 
> And the darcs 2 URL:
>   http://darcs.feydakins.org/garsia-wachs
> 

And packaged for Arch,

    http://aur.archlinux.org/packages.php?ID=20149

-- Don
From g9ks157k at acme.softbase.org  Tue Sep 23 03:35:28 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Tue Sep 23 03:32:38 2008
Subject: [Haskell-cafe] Re: [Haskell] Haskell Weekly News: Issue 86 -
	September 20, 2008
In-Reply-To: <20080920152554.GA2459@seas.upenn.edu>
References: <20080920152554.GA2459@seas.upenn.edu>
Message-ID: <200809230935.29034.g9ks157k@acme.softbase.org>

Am Samstag, 20. September 2008 17:25 schrieb Brent Yorgey:
> [?]

>    darcs 2.0.3pre1. Eric Kow [3]announced the first pre-release of
>    [4]darcs 2.0.3, featuring a few major bug fixes and a handful of
>    interesting features.

> 3.?http://www.haskell.org//pipermail/haskell-cafe/2008-September/047664.html

> [?]

Although I?m subscribed to haskell-cafe, it seems that I haven?t received this 
announcement.  And the page behind the above link doesn?t contain the 
announcement but tells me: ?Skipped content of type multipart/mixed?.

Best wishes,
Wolfgang
From sfvisser at cs.uu.nl  Tue Sep 23 04:09:02 2008
From: sfvisser at cs.uu.nl (Sebastiaan Visser)
Date: Tue Sep 23 04:06:12 2008
Subject: [Haskell-cafe] Is there already an abstraction for this?
In-Reply-To: <87tzc7ocr5.wl%jeremy@n-heptane.com>
References: <87tzc7ocr5.wl%jeremy@n-heptane.com>
Message-ID: 

This (recent) paper describes a very interesting way to perform  
generic term rewriting:
http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-020.pdf

On Sep 23, 2008, at 3:46 AM, Jeremy Shaw wrote:
> Hello,
>
> I am trying to figure out if there is an existing abstraction I am
> missing here.
>
> I have an expression data-type:
>
>> data Expr
>>   = Quotient Expr Expr
>>   | Product Expr Expr
>>   | Sum Expr Expr
>>   | Difference Expr Expr
>>   | Lit Double
>>   | Var Char
>>     deriving (Eq, Ord, Data, Typeable, Read, Show)
>>
>
> And I want to write a function that will take an expression and
> automatically apply the identity laws to simplify the expression.
>
> The basic identity laws are:
>
> a + 0 = a
> a * 1 = a
>
> I can implement these with some 'sugar' as:
>
>> identity (Sum (Lit 0) a)        = a
>> identity (Sum a (Lit 0))        = a
>> identity (Difference a (Lit 0)) = a
>> identity (Product a (Lit 1))    = a
>> identity (Product (Lit 1) a)    = a
>> identity (Quotient a (Lit 1))   = a
>> identity a                      = a
>
> This works fine when the identity only needs to be applied to the root
> of the expression tree:
>
> *Main> ppExpr $ identity (expr "1 + 0")
> 1
>
> But for more complicated trees it does not fully apply the identity  
> laws:
>
> *Main> ppExpr $ identity (expr "0 + (0 + 0) + (0 + 0)")
> ((0 + 0) + (0 + 0))
>
> What we need to do is first apply the identity function to the
> children, and then apply them to the parent of the updated children. A
> first attempt would be to extend the identity function like this:
>
>> identity (Sum a b)              = identity (Sum (identity a)  
>> (identity b))
>
> However, that will not terminate because that same case will keep
> matching over and over. Another approach is to have two mutually
> recursive functions like:
>
>> identity' (Sum (Lit 0) a)        = identityRec a
>> identity' (Sum a (Lit 0))        = identityRec a
>> identity' a = a
>
>> identityRec (Sum a b) = identity' (Sum (identity' a) (identity' b))
>
> This prevents non-termination, but you have to be careful about
> calling identity' vs identityRec or you will either re-introduce
> non-termination, or you may not fully apply the identity laws.
>
> Another option to create a helper function like:
>
>> -- |Deep map of an expression.
>> eMap :: (Expr -> Expr) -> Expr -> Expr
>> eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b))
>> eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b))
>> eMap f (Product a b) = f (Product (eMap f a) (eMap f b))
>> eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b))
>> eMap f (Var v) = f (Var v)
>> eMap f (Lit i) = f (Lit i)
>
> Now we can easily apply the identity law recursively like:
>
>> deepIdentity :: Expr -> Expr
>> deepIdentity = eMap identity
>
> *Main> ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)"))
> 0
>
> Sweet!
>
> But, having to write eMap out by hand like that somehow feels wrong --
> as if I am missing some additional abstraction. In some respects eMap
> is like a Functor, but not quite. I expect there is a way to implement
> eMap using Data.Generics, which is perhaps better, but I still feel
> like that is missing something?
>
> Anyway, I just thought I would ask in case someone recognized this
> pattern and could point me in the right direction. I have attached a
> working example program you can play with.
>
> I would also be interested in alternative approaches besides the ones
> I outlined.
>
> thanks!
> j.
>> ...
From g9ks157k at acme.softbase.org  Tue Sep 23 04:34:25 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Tue Sep 23 04:46:05 2008
Subject: [Haskell-cafe] Re: [Haskell] Haskell Weekly News: Issue 86 -
	September 20, 2008
In-Reply-To: <200809230935.29034.g9ks157k@acme.softbase.org>
References: <20080920152554.GA2459@seas.upenn.edu>
	<200809230935.29034.g9ks157k@acme.softbase.org>
Message-ID: <200809231034.25882.g9ks157k@acme.softbase.org>

Am Dienstag, 23. September 2008 09:35 schrieb Wolfgang Jeltsch:
> Am Samstag, 20. September 2008 17:25 schrieb Brent Yorgey:
> > [?]
> >
> >    darcs 2.0.3pre1. Eric Kow [3]announced the first pre-release of
> >    [4]darcs 2.0.3, featuring a few major bug fixes and a handful of
> >    interesting features.
> >
> > 3.?http://www.haskell.org//pipermail/haskell-cafe/2008-September/047664.h
> >tml
> >
> > [?]
>
> Although I?m subscribed to haskell-cafe, it seems that I haven?t received
> this announcement.  And the page behind the above link doesn?t contain the
> announcement but tells me: ?Skipped content of type multipart/mixed?.
>
> Best wishes,
> Wolfgang

Okay, I was reading the wrong list (haskell instead of haskell-cafe) so the 
announcement is there in my mail folder.  But why doesn?t Mailman contain the 
message properly in its archive?

Best wishes,
Wolfgang
From g9ks157k at acme.softbase.org  Tue Sep 23 04:42:09 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Tue Sep 23 04:46:34 2008
Subject: [Haskell-cafe] Packages
In-Reply-To: <48D5FB4A.1010700@btinternet.com>
References: 
	<20080921164550.70ecccf7@gmail.com>
	<48D5FB4A.1010700@btinternet.com>
Message-ID: <200809231042.09132.g9ks157k@acme.softbase.org>

Am Sonntag, 21. September 2008 09:44 schrieb Andrew Coppin:
> [?]

> 2. If we already have a Cabal package, why do we also need seperate
> packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?

If I want to install gtk2hs on Debian, I?d like gtk (the C library) to be 
automatically installed.  And I want Debian?s gtk package because this is the 
one, other Debian-packaged software uses.

And a Debian user installing an application written in Haskell wants to use 
the Debian package manager.

> [?]

Best wishes,
Wolfgang
From manlio_perillo at libero.it  Tue Sep 23 05:36:16 2008
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Tue Sep 23 05:33:28 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <20080922231237.GB27786@scytale.galois.com>
References: <20080922052712.GB24712@scytale.galois.com>	<48D7698F.8040902@libero.it>
	<64475980.20080922160759@gmail.com>		<534345625.20080922211206@gmail.com>		<61951769.20080922230925@gmail.com>		<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
Message-ID: <48D8B890.5030405@libero.it>

Don Stewart ha scritto:
> [...]
> Ok. So I'll just say: high level, efficient code is an overriding theme
> of many individuals working on Haskell. Things are better and better
> each year. We do not stand still.
> 

Any roadmap for improve support in intensive IO multiplexing?
Or, at least, some papers about how this is implemented in GHC?

Af far as I understand, select is used in two separate places.
How much effort it takes to implement a pluggable "reactor" (select, 
poll, epoll, kqueue, /dev/poll, and so)?


 > [...]


Thanks  Manlio Perillo
From bulat.ziganshin at gmail.com  Tue Sep 23 05:32:10 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Tue Sep 23 05:33:43 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: 
References: <20080922052712.GB24712@scytale.galois.com>
	<64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
	
Message-ID: <1426243534.20080923133210@gmail.com>

Hello Sterling,

Tuesday, September 23, 2008, 5:13:57 AM, you wrote:

> Oh, and it "simply and naively" loops with the following:
>  while (fgets_unlocked (line, MAXLINELEN, stdin))
> If Bulat's point is that the shootout has inspired work on Haskell
> performance, and in the stdlibs no less, then lovely, and that's all
> to the good. Below every high level interface is lots of low level pain.

functions used to make C code faster is obviously worse than those
used for Haskell code. just look - Clean gets 2x better performance
than C

> If his point is anything else, this is getting absurd.

my point is very simple - these tests says nothing about real
performance since these tests was hardly optimized including adding
special functions to ghc libs. amount of work required to do this is
much much more than amount of work required to write optimal C/asm
code

and this work obviously doesn't speed up every Haskell program. so
that we have in Haskell world now is heroic efforts to speed up
shootout test which doesn't say anything about real Haskell
performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and
several libs which may improve speed in some usages


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From bulat.ziganshin at gmail.com  Tue Sep 23 05:47:06 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Tue Sep 23 05:49:43 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <48D8B890.5030405@libero.it>
References: <20080922052712.GB24712@scytale.galois.com>
	<48D7698F.8040902@libero.it> <64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<48D8B890.5030405@libero.it>
Message-ID: <971326133.20080923134706@gmail.com>

Hello Manlio,

Tuesday, September 23, 2008, 1:36:16 PM, you wrote:

> Any roadmap for improve support in intensive IO multiplexing?
> Or, at least, some papers about how this is implemented in GHC?

> Af far as I understand, select is used in two separate places.
> How much effort it takes to implement a pluggable "reactor" (select, 
> poll, epoll, kqueue, /dev/poll, and so)?

look at alt-network package

improving existing ghc i/o library may be a bad idea since it is a
large monolithic code which is aklready hard to maintain. there was
several efforts to provide new i/o library. of those, my Streams
library was the largest. unfortunately, all who done those libs
stopped their work. so the most probable scenario now is what we
eventually will get ByteString-based modular I/O library from
FPS/Binary developers


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From michal.palka at poczta.fm  Tue Sep 23 06:16:56 2008
From: michal.palka at poczta.fm (=?UTF-8?Q?Micha=C5=82_Pa=C5=82ka?=)
Date: Tue Sep 23 06:14:27 2008
Subject: [Haskell-cafe] how do i use quickcheck in the IO monad?
In-Reply-To: 
References: 
Message-ID: <1222165016.18333.29.camel@localhost>

On Mon, 2008-09-22 at 12:35 -0700, Anatoly Yakovenko wrote:
> If i have functions in the IO monad, is there a way to use quickcheck
> to test them?  I have a bunch of C bindings that unfortunately are not
> "safe".  But i would like to be able to use QuickCheck to test them.

Hi Anatoly,

If you want to test some sequential properties then you might use
QuickCheck to generate sequences of actions that the library will
perform and check if the outcomes are correct. If there is no easy way
to verify the results then you may create a model of your library and
compare the results.

This approach is demonstrated in this talk:
http://ulf.wiger.net/weblog/2008/02/29/john-hughes-testing-with-quickcheck/
where John Hughes tests fread()/fwrite()/fseek() unix functions. He uses
the Erlang version of QuickCheck, but using a Haskell one should allow
you to do the same thing in the IO monad.

There are probably some papers that deal with what you want to do as
well, like this one:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.9275
(I haven't read it though).

Best,
Micha?

From jules at jellybean.co.uk  Tue Sep 23 06:21:34 2008
From: jules at jellybean.co.uk (Jules Bean)
Date: Tue Sep 23 06:18:41 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <1426243534.20080923133210@gmail.com>
References: <20080922052712.GB24712@scytale.galois.com>	<64475980.20080922160759@gmail.com>		<534345625.20080922211206@gmail.com>		<61951769.20080922230925@gmail.com>		<1797097834.20080923030028@gmail.com>	<20080922231237.GB27786@scytale.galois.com>	<1712911408.20080923041652@gmail.com>	
	<1426243534.20080923133210@gmail.com>
Message-ID: <48D8C32E.9010005@jellybean.co.uk>

Bulat Ziganshin wrote:
> and this work obviously doesn't speed up every Haskell program. so
> that we have in Haskell world now is heroic efforts to speed up
> shootout test which doesn't say anything about real Haskell
> performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and
> several libs which may improve speed in some usages

If you understand performance as well as you claim to - and from your 
previous postings, I believe you *do* understand performance well - then 
you will know that "10-20% speedup" is almost entirely meaningless in 
isolation.

Any given particular program has a bottleneck; this bottleneck may be 
different depending on the OS/hardware configuration, although normally 
it won't be. Improvements which touch that bottleneck can have 
staggering benefits in the 40-500% range; improvements which are 
elsewhere have tiny <5% or non-measurale effects.

In fact, various improvements made to GHC in the 6.4-6.10 timeline have 
had enormous, order-of-magnitude improvements to particular code 
patterns which had particular bottlenecks. Meanwhile they may well have 
had no effect at all on other code patterns which had different bottlenecks.

You may ask, what are the common code patterns? What are the common 
bottlenecks? I'm not aware of good studies to answer these questions 
although they probably exist; I don't read widely the research in this 
area. [Naive C programs tend to IO bottleneck or Memory bottleneck; I 
strongly suspect naive haskell programs tend to GC bottleneck; but I 
don't think either of these observations is particularly profound or useful]

What matters to a particular programmer of course it not actually common 
patterns and common bottlenecks. It is the bottleneck in his particular 
program.

However: The Shootout is a *game*.

It even says that in its name.

It's a game which many of us enjoy playing; if you don't enjoy, please 
feel free not to play. Many of us find that, by playing the game, we 
learn a lot of interesting things about the low-level performance of GHC 
in interesting edge-cases. The quad-core machine recently added to the 
benchmark has enabled us to learn interesting things about `par` and 
Control.Parallel. Learning these things, and sharing them, may help us 
write better programs, help us teach other people to write better 
programs, and help the GHC team write a better compiler.

Jules

From bulat.ziganshin at gmail.com  Tue Sep 23 06:26:40 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Tue Sep 23 06:25:31 2008
Subject: [Haskell-cafe] Climbing up the shootout...
In-Reply-To: <48D8C32E.9010005@jellybean.co.uk>
References: <20080922052712.GB24712@scytale.galois.com>
	<64475980.20080922160759@gmail.com>
	
	<534345625.20080922211206@gmail.com>
	
	<61951769.20080922230925@gmail.com>
	
	<1797097834.20080923030028@gmail.com>
	<20080922231237.GB27786@scytale.galois.com>
	<1712911408.20080923041652@gmail.com>
	
	<1426243534.20080923133210@gmail.com>
	<48D8C32E.9010005@jellybean.co.uk>
Message-ID: <1613138574.20080923142640@gmail.com>

Hello Jules,

Tuesday, September 23, 2008, 2:21:34 PM, you wrote:

>> performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and
>> several libs which may improve speed in some usages

> If you understand performance as well as you claim to - and from your 
> previous postings, I believe you *do* understand performance well - then
> you will know that "10-20% speedup" is almost entirely meaningless in 
> isolation.

> Any given particular program has a bottleneck; this bottleneck may be

that's good when we consider optimization of specific program, in my
own one bottlenecks are studied and rewritten either in C or low-level
Haskell

but when we say about compiler speed, we are forced to sau about some
average values. these numbers are given by GHC developers, i seen the
same on one test of my own, several bottlenecks fixed can't say too