From bjpop at csse.unimelb.edu.au Thu Nov 1 00:51:44 2007 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Thu Nov 1 00:44:44 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> Message-ID: On 01/11/2007, at 2:37 AM, Neil Mitchell wrote: > > My guess is that the native code generator in Clean beats GHC, which > wouldn't be too surprising as GHC is currently rewriting its CPS and > Register Allocator to produce better native code. I discussed this with Rinus Plasmeijer (chief designer of Clean) a couple of years ago, and if I remember correctly, he said that the native code generator in Clean was very good, and a significant reason why Clean produces (relatively) fast executables. I think he said that they had an assembly programming guru on their team. (Apologies to Rinus if I am mis-remembering the conversation). At the time I was impressed by how fast Clean could recompile itself. Cheers, Bernie. From ajb at spamcop.net Thu Nov 1 01:20:30 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Nov 1 01:17:52 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <1193879977.22009.3.camel@derek-laptop> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <404396ef0710311249nf41f32bt98c3b044b3c45739@mail.gmail.com> <625b74080710311358s2c4a1a4ag61dcbd516d840468@mail.gmail.com> <1193879977.22009.3.camel@derek-laptop> Message-ID: <20071101012030.w8guqnwjvossw400@webmail.spamcop.net> G'day all. Quoting Derek Elkins : > Probably RuntimeCompilation (or something like that and linked from the > Knuth-Morris-Pratt implementation on HaWiki) written by Andrew Bromage. I didn't keep a copy, but if someone wants to retrieve it from the Google cache and put it on the new wiki (under the new licence, of course), please do so. Cheers, Andrew Bromage From ketil+haskell at ii.uib.no Thu Nov 1 03:45:49 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Thu Nov 1 03:43:12 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <20071031181628.GH17689@scytale.galois.com> (Don Stewart's message of "Wed\, 31 Oct 2007 11\:16\:28 -0700") References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> Message-ID: <87lk9ipfwy.fsf@nmd9999.imr.no> Don Stewart writes: > goalieca: >> So in a few years time when GHC has matured we can expect performance to >> be on par with current Clean? So Clean is a good approximation to peak >> performance? If I remember the numbers, Clean is pretty close to C for most benchmarks, so I guess it is fair to say it is a good approximation to practical peak performance. Which proves that it is possible to write efficient low-level code in Clean. > And remember usually Haskell is competing against 'high level' languages > like python for adoption, where we're 5-500x faster anyway... Unfortunately, they replaced line counts with bytes of gzip'ed code -- while the former certainly has its problems, I simply cannot imagine what relevance the latter has (beyond hiding extreme amounts of repetitive boilerplate in certain languages). When we compete against Python and its ilk, we do so for programmer productivity first, and performance second. LOC was a nice measure, and encouraged terser and more idiomatic programs than the current crop of performance-tweaked low-level stuff. BTW, Python isn't so bad, performance wise. Much of what I do consists of reading some files, building up some hashes (associative arrays or finite maps, depending on where you come from :-), and generating some output. Python used to do pretty well here compared to Haskell, with rather efficient hashes and text parsing, although I suspect ByteString IO and other optimizations may have changed that now. -k -- If I haven't seen further, it is by standing in the footprints of giants From bulat.ziganshin at gmail.com Thu Nov 1 04:01:28 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 1 04:00:49 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <404396ef0710311249nf41f32bt98c3b044b3c45739@mail.gmail.com> <625b74080710311358s2c4a1a4ag61dcbd516d840468@mail.gmail.com> Message-ID: <1557573258.20071101110128@gmail.com> Hello Lennart, Thursday, November 1, 2007, 2:45:49 AM, you wrote: > But yeah, a code generator at run time is a very cool idea, and one > that has been studied, but not enough. vm-based languages (java, c#) has runtimes that compile bytecode to the native code at runtime -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From overdrigzed at gmail.com Thu Nov 1 05:09:15 2007 From: overdrigzed at gmail.com (Rodrigo Queiro) Date: Thu Nov 1 05:06:36 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <87lk9ipfwy.fsf@nmd9999.imr.no> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> Message-ID: <2eb8984a0711010209k548b801dje94f50c7d378f17e@mail.gmail.com> I assume the reason the switched away from LOC is to prevent programmers artificially reducing their LOC count, e.g. by using a = 5; b = 6; rather than a = 5; b = 6; in languages where newlines aren't syntactically significant. When gzipped, I guess that the ";\n" string will be represented about as efficiently as just the single semi-colon. On 01/11/2007, Ketil Malde wrote: > Don Stewart writes: > > > goalieca: > > >> So in a few years time when GHC has matured we can expect performance to > >> be on par with current Clean? So Clean is a good approximation to peak > >> performance? > > If I remember the numbers, Clean is pretty close to C for most > benchmarks, so I guess it is fair to say it is a good approximation to > practical peak performance. > > Which proves that it is possible to write efficient low-level code in > Clean. > > > And remember usually Haskell is competing against 'high level' languages > > like python for adoption, where we're 5-500x faster anyway... > > Unfortunately, they replaced line counts with bytes of gzip'ed code -- > while the former certainly has its problems, I simply cannot imagine > what relevance the latter has (beyond hiding extreme amounts of > repetitive boilerplate in certain languages). > > When we compete against Python and its ilk, we do so for programmer > productivity first, and performance second. LOC was a nice measure, > and encouraged terser and more idiomatic programs than the current > crop of performance-tweaked low-level stuff. > > BTW, Python isn't so bad, performance wise. Much of what I do > consists of reading some files, building up some hashes (associative > arrays or finite maps, depending on where you come from :-), and > generating some output. Python used to do pretty well here compared > to Haskell, with rather efficient hashes and text parsing, although I > suspect ByteString IO and other optimizations may have changed that > now. > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From simonpj at microsoft.com Thu Nov 1 05:28:53 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 1 05:26:15 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <404396ef0710311930o1ac0162epc5eac2a424c247ab@mail.gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071101013826.GA3709@localhost.localdomain> <404396ef0710311930o1ac0162epc5eac2a424c247ab@mail.gmail.com> Message-ID: Yes, that's right. We'll be doing a lot more work on the code generator in the rest of this year and 2008. Here "we" includes Norman Ramsey and John Dias, as well as past interns Michael Adams and Ben Lippmeier, so we have real muscle! Simon | > I don't think the register allocater is being rewritten so much as it is | > being written: | | >From talking to Ben, who rewrote the register allocator over the | summer, he said that the new graph based register allocator is pretty | good. The thing that is holding it back is the CPS conversion bit, | which was also being rewritten over the summer, but didn't get | finished. I think these are both things which are likely to be done | for 6.10. | | Thanks | | Neil | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From aruiz at um.es Thu Nov 1 06:59:44 2007 From: aruiz at um.es (Alberto Ruiz) Date: Thu Nov 1 06:57:07 2007 Subject: [Haskell-cafe] Haskell libraries for computer vision In-Reply-To: <4714C67C.4020909@yale.edu> References: <20071015235801.GA29852@scytale.galois.com> <4714C67C.4020909@yale.edu> Message-ID: <200711011159.45156.aruiz@um.es> I have included in the web page a reference to this earlier work, in which all the key ideas were already present. For example, using ordinary Haskell functions to process an infinite list containing the whole image sequence taken by the camera... We can write extremely concise and powerful "camera combinators". Haskell is amazing. Thanks! Alberto On Tuesday 16 October 2007 16:11, Paul Hudak wrote: > Henning Thielemann wrote: > > On Mon, 15 Oct 2007, Don Stewart wrote: > >> http://alberrto.googlepages.com/easyvision > >> "An experimental Haskell system for fast prototyping of computer > >> vision and image processing applications." > >> Looks ridiculously cool. > > > > Image processing with Haskell - really interesting. > > > > I know of an older approach: > > "Prototyping Real-Time Vision Systems: An Experiment in DSL Design" > > by Alastair Reid et.al. > > Yes, see: > > http://haskell.org/yale/papers/padl01-vision/index.html > http://haskell.org/yale/papers/icse99/index.html > > -Paul From aruiz at um.es Thu Nov 1 07:04:16 2007 From: aruiz at um.es (Alberto Ruiz) Date: Thu Nov 1 07:01:35 2007 Subject: [Haskell-cafe] virtual lambda Message-ID: <200711011204.16250.aruiz@um.es> Hi, I think that you may like the following demo of a simple computer vision application powered by Haskell: http://covector.blogspot.com/2007/10/functional-augmented-reality.html Alberto From stefan at cs.uu.nl Thu Nov 1 06:39:57 2007 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Nov 1 08:26:25 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> Message-ID: Bernie wrote: > I discussed this with Rinus Plasmeijer (chief designer of Clean) a > couple of years ago, and if I remember correctly, he said that the > native code generator in Clean was very good, and a significant > reason why Clean produces (relatively) fast executables. I think he > said that they had an assembly programming guru on their team. > (Apologies to Rinus if I am mis-remembering the conversation). That guru would be John van Groningen... If I understood correctly, and I think I did, John is now working on a Haskell front end for the Clean compiler---which is actually quite interesting in the light of the present discussion. Cheers, Stefan From stefan at cs.uu.nl Thu Nov 1 07:04:51 2007 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Nov 1 08:26:26 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> Message-ID: <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> Neil wrote: > The Clean and Haskell languages both reduce to pretty much > the same Core language, with pretty much the same type system, once > you get down to it - so I don't think the difference between the > performance is a language thing, but it is a compiler thing. The > uniqueness type stuff may give Clean a slight benefit, but I'm not > sure how much they use that in their analyses. From what I know from the Nijmegen team, having the uniqueness information available and actually using it for code generation does allow for an impressive speed-up. The thing is: in principle, there is, I think, no reason why we can't do the same thing for Haskell. Of course, the Clean languages exposes uniqueness types at its surface level, but that is in no way essential to the underlying analysis. Exposing uniqueness types is, in that sense, just an alternative to monadic encapsulation of side effects. So, a Haskell compiler could just implement a uniqueness analysis under the hood and use the results for generating code that does in-place updates that are guaranteed to maintain referential transparency. Interestingly---but now I'm shamelessly plugging a paper of Jurriaan Hage, Arie Middelkoop, and myself, presented at this year's ICFP [*]---such an analysis is very similar to sharing analysis, which may be used by compilers for lazy languages to avoid unnecessary thunk updates. Cheers, Stefan [*] Jurriaan Hage, Stefan Holdermans, and Arie Middelkoop. A generic usage analysis with subeffect qualifiers. In Ralf Hinze and Norman Ramsey, editors, Proceedings of the 12th ACM SIGPLAN International Conference on Functional Programming, ICFP 2007, Freiburg, Germany, October 1?-3, pages 235?-246. ACM Press, 2007. http://doi.acm.org/ 10.1145/1291151.1291189. From pocm at soton.ac.uk Thu Nov 1 09:41:40 2007 From: pocm at soton.ac.uk (Paulo J. Matos) Date: Thu Nov 1 09:39:01 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071101013826.GA3709@localhost.localdomain> <404396ef0710311930o1ac0162epc5eac2a424c247ab@mail.gmail.com> Message-ID: <11b141710711010641w6f8ec247hfca05c13a2f460a3@mail.gmail.com> On 01/11/2007, Simon Peyton-Jones wrote: > Yes, that's right. We'll be doing a lot more work on the code generator in the rest of this year and 2008. Here "we" includes Norman Ramsey and John Dias, as well as past interns Michael Adams and Ben Lippmeier, so we have real muscle! > That's very good to know. I wonder where could I read more about current state of the art on Haskell compilation techniques and about the implementation of ghc in general? Is there a book on it or maybe some group of papers that would aid me to understand it? Cheers, Paulo Matos > Simon > > | > I don't think the register allocater is being rewritten so much as it is > | > being written: > | > | >From talking to Ben, who rewrote the register allocator over the > | summer, he said that the new graph based register allocator is pretty > | good. The thing that is holding it back is the CPS conversion bit, > | which was also being rewritten over the summer, but didn't get > | finished. I think these are both things which are likely to be done > | for 6.10. > | > | Thanks > | > | Neil > | _______________________________________________ > | 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 > > > -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK From simonpj at microsoft.com Thu Nov 1 10:03:35 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 1 10:00:57 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <11b141710711010641w6f8ec247hfca05c13a2f460a3@mail.gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071101013826.GA3709@localhost.localdomain> <404396ef0710311930o1ac0162epc5eac2a424c247ab@mail.gmail.com> <11b141710711010641w6f8ec247hfca05c13a2f460a3@mail.gmail.com> Message-ID: http://hackage.haskell.org/trac/ghc/wiki/Commentary | -----Original Message----- | From: pocmatos@gmail.com [mailto:pocmatos@gmail.com] On Behalf Of Paulo J. Matos | Sent: 01 November 2007 13:42 | To: Simon Peyton-Jones | Cc: Neil Mitchell; Stefan O'Rear; Jeff.Harper@handheld.com; haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] Re: Why can't Haskell be faster? | | On 01/11/2007, Simon Peyton-Jones wrote: | > Yes, that's right. We'll be doing a lot more work on the code generator in the rest of this year and 2008. | Here "we" includes Norman Ramsey and John Dias, as well as past interns Michael Adams and Ben Lippmeier, so we | have real muscle! | > | | That's very good to know. I wonder where could I read more about | current state of the art on Haskell compilation techniques and about | the implementation of ghc in general? | Is there a book on it or maybe some group of papers that would aid me | to understand it? | | Cheers, | | Paulo Matos | | > Simon | > | > | > I don't think the register allocater is being rewritten so much as it is | > | > being written: | > | | > | >From talking to Ben, who rewrote the register allocator over the | > | summer, he said that the new graph based register allocator is pretty | > | good. The thing that is holding it back is the CPS conversion bit, | > | which was also being rewritten over the summer, but didn't get | > | finished. I think these are both things which are likely to be done | > | for 6.10. | > | | > | Thanks | > | | > | Neil | > | _______________________________________________ | > | 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 | > | > | > | | | -- | Paulo Jorge Matos - pocm at soton.ac.uk | http://www.personal.soton.ac.uk/pocm | PhD Student @ ECS | University of Southampton, UK From apfelmus at quantentunnel.de Thu Nov 1 10:46:16 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Nov 1 10:43:47 2007 Subject: [Haskell-cafe] Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> Message-ID: Stefan Holdermans wrote: > Exposing uniqueness types is, in that sense, just an alternative > to monadic encapsulation of side effects. While *World -> (a, *World) seems to work in practice, I wonder what its (denotational) semantics are. I mean, the two programs loop, loop' :: *World -> ((),*World) loop w = loop w loop' w = let (_,w') = print "x" w in loop' w' both have denotation _|_ but are clearly different in terms of side effects. (The example is from SPJs awkward-squad tutorial.) Any pointers? Regards, apfelmus From arnarbi at gmail.com Thu Nov 1 10:59:43 2007 From: arnarbi at gmail.com (Arnar Birgisson) Date: Thu Nov 1 10:57:03 2007 Subject: [Haskell-cafe] Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> Message-ID: <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> Hi there, I'm new here, so sorry if I'm stating the obvious. On Nov 1, 2007 2:46 PM, apfelmus wrote: > Stefan Holdermans wrote: > > Exposing uniqueness types is, in that sense, just an alternative > > to monadic encapsulation of side effects. > > While *World -> (a, *World) seems to work in practice, I wonder what > its (denotational) semantics are. I mean, the two programs > > loop, loop' :: *World -> ((),*World) > > loop w = loop w > loop' w = let (_,w') = print "x" w in loop' w' > > both have denotation _|_ but are clearly different in terms of side > effects. (The example is from SPJs awkward-squad tutorial.) Any pointers? For side-effecting program one has to consider bisimilarity. It's common that semantically equivalent (under operational or denotational semantics) behave differently with regard to side-effects (i/o) - i.e. they are not bisimilar. http://en.wikipedia.org/wiki/Bisimulation Arnar From bos at serpentine.com Thu Nov 1 11:19:00 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Nov 1 11:17:58 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <87lk9ipfwy.fsf@nmd9999.imr.no> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> Message-ID: <4729EE64.9050808@serpentine.com> Ketil Malde wrote: > Python used to do pretty well here compared > to Haskell, with rather efficient hashes and text parsing, although I > suspect ByteString IO and other optimizations may have changed that > now. It still does just fine. For typical "munge a file with regexps, lists, and maps" tasks, Python and Perl remain on par with comparably written Haskell. This because the scripting-level code acts as a thin layer of glue around I/O, regexps, lists, and dicts, all of which are written in native code. The Haskell regexp libraries actually give us something of a leg down with respect to Python and Perl. The aggressive use of polymorphism in the return type of (=~) makes it hard to remember which of the possible return types gives me what information. Not only did I write a regexp tutorial to understand the API in the first place, I have to reread it every time I want to match a regexp. A suitable solution would be a return type of RegexpMatch a => Maybe a (to live alongside the existing types, but aiming to become the one that's easy to remember), with appropriate methods on a, but I don't have time to write up a patch. References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <404396ef0710311249nf41f32bt98c3b044b3c45739@mail.gmail.com> <625b74080710311358s2c4a1a4ag61dcbd516d840468@mail.gmail.com> <1193879977.22009.3.camel@derek-laptop> <20071101012030.w8guqnwjvossw400@webmail.spamcop.net> Message-ID: On 10/31/07, ajb@spamcop.net wrote: > I didn't keep a copy, but if someone wants to retrieve it from the Google > cache and put it on the new wiki (under the new licence, of course), please > do so. > > Cheers, > Andrew Bromage Done: http://www.haskell.org/haskellwiki/RuntimeCompilation . Please update it as needed. Justin From dmc at sanger.ac.uk Thu Nov 1 13:47:40 2007 From: dmc at sanger.ac.uk (David Carter) Date: Thu Nov 1 13:45:01 2007 Subject: [Haskell-cafe] do/if/then/else confusion Message-ID: <472A113C.9080401@sanger.ac.uk> Another newbie question, but I can't seem to find any answers on the web... Can someone tell me what's wrong with this? import qualified System.Posix.Directory as PD readdirAll :: PD.DirStream -> IO [String] readdirAll d = do dir <- PD.readDirStream d if dir == "" then return [] else rest <- readdirAll d return (dir:rest) Compiling with GHC 6.6.1 gives me the not-very-useful message "Parse error in pattern", pointing to the "i" of "if". I've tried all kinds of alternative indentations (including indenting the "else" more), bracketings etc, but nothing helps. Thanks David -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From allbery at ece.cmu.edu Thu Nov 1 13:52:08 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Nov 1 13:49:28 2007 Subject: [Haskell-cafe] do/if/then/else confusion In-Reply-To: <472A113C.9080401@sanger.ac.uk> References: <472A113C.9080401@sanger.ac.uk> Message-ID: On Nov 1, 2007, at 13:47 , David Carter wrote: > else rest <- readdirAll d You need another "do" here to use the <- syntax. -- 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 dmc at sanger.ac.uk Thu Nov 1 13:53:06 2007 From: dmc at sanger.ac.uk (David Carter) Date: Thu Nov 1 13:50:27 2007 Subject: [Haskell-cafe] Re: do/if/then/else confusion In-Reply-To: <472A113C.9080401@sanger.ac.uk> References: <472A113C.9080401@sanger.ac.uk> Message-ID: <472A1282.5090202@sanger.ac.uk> David Carter wrote: > Another newbie question, but I can't seem to find any answers on the > web... Just figured it out myself ... I need a "do" after the "else", of course. (But I still think the error message is less than helpful!). Sorry for the bandwidth David > > Can someone tell me what's wrong with this? > > import qualified System.Posix.Directory as PD > > readdirAll :: PD.DirStream -> IO [String] > readdirAll d = > do dir <- PD.readDirStream d > if dir == "" > then return [] > else rest <- readdirAll d > return (dir:rest) > > Compiling with GHC 6.6.1 gives me the not-very-useful message "Parse > error in pattern", pointing to the "i" of "if". I've tried all kinds > of alternative indentations (including indenting the "else" more), > bracketings etc, but nothing helps. > > Thanks > > David > > -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From prstanley at ntlworld.com Thu Nov 1 14:06:47 2007 From: prstanley at ntlworld.com (PR Stanley) Date: Thu Nov 1 14:04:00 2007 Subject: [Haskell-cafe] Slightly off-topic Message-ID: <7.0.1.0.0.20071101180412.020ed3d0@ntlworld.com> Hi folks Apologies for the off-topic post. If anyone knows anything about the rules of proof by deduction and quantifiers I'd be grateful for some assistance. Much obliged, Paul From dons at galois.com Thu Nov 1 14:10:53 2007 From: dons at galois.com (Don Stewart) Date: Thu Nov 1 14:08:18 2007 Subject: [Haskell-cafe] Slightly off-topic In-Reply-To: <7.0.1.0.0.20071101180412.020ed3d0@ntlworld.com> References: <7.0.1.0.0.20071101180412.020ed3d0@ntlworld.com> Message-ID: <20071101181053.GC25269@scytale.galois.com> prstanley: > Hi folks > Apologies for the off-topic post. > If anyone knows anything about the rules of proof by deduction and > quantifiers I'd be grateful for some assistance. > Much obliged, http://www.cs.cmu.edu/~rwh/plbook/ Is an excellent introduction to reasoning about programming languages. -- Don From haskell at list.mightyreason.com Thu Nov 1 14:16:30 2007 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Nov 1 14:14:16 2007 Subject: [Haskell-cafe] Regex API ideas In-Reply-To: <4729EE64.9050808@serpentine.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> <4729EE64.9050808@serpentine.com> Message-ID: <472A17FE.9030305@list.mightyreason.com> Hi Bryan, I wrote the current regex API, so your suggestions are interesting to me. The also goes for anyone else's regex API opinions, of course. Bryan O'Sullivan wrote: > Ketil Malde wrote: > >> Python used to do pretty well here compared >> to Haskell, with rather efficient hashes and text parsing, although I >> suspect ByteString IO and other optimizations may have changed that >> now. > > It still does just fine. For typical "munge a file with regexps, lists, > and maps" tasks, Python and Perl remain on par with comparably written > Haskell. This because the scripting-level code acts as a thin layer of > glue around I/O, regexps, lists, and dicts, all of which are written in > native code. > > The Haskell regexp libraries actually give us something of a leg down > with respect to Python and Perl. True, the pure Haskell library is not as fast as a C library. In particular, the current regex-tdfa handles lazy bytestring in a sub-optimal manner. This may eventually be fixed. But the native code libraries have also been wrapped in the same API, and they are quite fast when combined with strict ByteStrings. > The aggressive use of polymorphism in > the return type of (=~) makes it hard to remember which of the possible > return types gives me what information. Not only did I write a regexp > tutorial to understand the API in the first place, I have to reread it > every time I want to match a regexp. The (=~) operator uses many return types provided by the instances of RegexContext. These are all thin wrappers around the unpolymorphic return types of the RegexLike class. So (=~) could be avoided altogether, or another API created. > > A suitable solution would be a return type of RegexpMatch a => Maybe a > (to live alongside the existing types, but aiming to become the one > that's easy to remember), with appropriate methods on a, but I don't > have time to write up a patch. > > I am trying to rewrite sentences in a logical language into DNF, and wonder if someone would point out where I'm going wrong. My dim understanding of it is that I need to move And and Not inwards and Or out, but the function below fails, for example: > dnf (Or (And A B) (Or (And C D) E)) And (Or A (And (Or C E) (Or D E))) (Or B (And (Or C E) (Or D E))) data LS = Var | Not LS | And LS LS | Or LS LS --convert sentences to DNF dnf :: LS -> LS dnf (And (Or s1 s2) s3) = Or (And (dnf s1) (dnf s3)) (And (dnf s2) (dnf s3)) dnf (And s1 (Or s2 s3)) = Or (And (dnf s1) (dnf s2)) (And (dnf s1) (dnf s3)) dnf (And s1 s2) = And (dnf s1) (dnf s2) dnf (Or s1 s2) = Or (dnf s1) (dnf s2) dnf (Not (Not d)) = dnf d dnf (Not (And s1 s2)) = Or (Not (dnf s1)) (Not (dnf s2)) dnf (Not (Or s1 s2)) = And (Not (dnf s1)) (Not (dnf s2)) dnf s = s Thanks, Jim -- View this message in context: http://www.nabble.com/Disjunctive-Normal-Form-tf4733248.html#a13534567 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From bos at serpentine.com Thu Nov 1 14:34:04 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Nov 1 14:33:03 2007 Subject: [Haskell-cafe] Regex API ideas In-Reply-To: <472A17FE.9030305@list.mightyreason.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> <4729EE64.9050808@serpentine.com> <472A17FE.9030305@list.mightyreason.com> Message-ID: <472A1C1C.2030709@serpentine.com> ChrisK wrote: >> The Haskell regexp libraries actually give us something of a leg down >> with respect to Python and Perl. > > True, the pure Haskell library is not as fast as a C library. Actually, I wasn't referring to the performance of the libraries, merely to the non-stick nature of the API. For my purposes, regex-pcre performs well (though I owe you some patches to make it, and other regex back ends, compile successfully out of the box). > But more interesting to me is learning what API you would like to see. > What would you like the code that uses the API to be? Python's regexp API is pretty easy to use, and also to remember. Here's what it does for match objects. http://docs.python.org/lib/match-objects.html References: <13534567.post@talk.nabble.com> Message-ID: <7ca3f0160711011141q2f115331w5b6d7f2efd08f77e@mail.gmail.com> A good way to approach this is data-structure-driven programming. You want a data structure which represents, and can _only_ represent, propositions in DNF. So: data Term = Pos Var | Neg Var type Conj = [Term] type DNF = [Conj] Then write: dnf :: LS -> DNF The inductive definition of dnf is straightforward given this output type... Luke On 11/1/07, Jim Burton wrote: > > I am trying to rewrite sentences in a logical language into DNF, and wonder > if someone would point out where I'm going wrong. My dim understanding of it > is that I need to move And and Not inwards and Or out, but the function > below fails, for example: > > > dnf (Or (And A B) (Or (And C D) E)) > And (Or A (And (Or C E) (Or D E))) (Or B (And (Or C E) (Or D E))) > > > data LS = Var | Not LS | And LS LS | Or LS LS > --convert sentences to DNF > dnf :: LS -> LS > dnf (And (Or s1 s2) s3) = Or (And (dnf s1) (dnf s3)) (And (dnf s2) (dnf s3)) > dnf (And s1 (Or s2 s3)) = Or (And (dnf s1) (dnf s2)) (And (dnf s1) (dnf s3)) > dnf (And s1 s2) = And (dnf s1) (dnf s2) > dnf (Or s1 s2) = Or (dnf s1) (dnf s2) > dnf (Not (Not d)) = dnf d > dnf (Not (And s1 s2)) = Or (Not (dnf s1)) (Not (dnf s2)) > dnf (Not (Or s1 s2)) = And (Not (dnf s1)) (Not (dnf s2)) > dnf s = s > > Thanks, > > Jim > > -- > View this message in context: http://www.nabble.com/Disjunctive-Normal-Form-tf4733248.html#a13534567 > 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 newsham at lava.net Thu Nov 1 14:46:58 2007 From: newsham at lava.net (Tim Newsham) Date: Thu Nov 1 14:44:17 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <87lk9ipfwy.fsf@nmd9999.imr.no> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> Message-ID: > Unfortunately, they replaced line counts with bytes of gzip'ed code -- > while the former certainly has its problems, I simply cannot imagine > what relevance the latter has (beyond hiding extreme amounts of > repetitive boilerplate in certain languages). Sounds pretty fair to me. Programming is a job of compressing a solution set. Excessive boilerplate might mean that you have to type a lot, but doesn't necessarily mean that you have to think a lot. I think the previous line count was skewed in favor of very terse languages like haskell, especially languages that let you put many ideas onto a single line. At the very least there should be a constant factor applied when comparing haskell line counts to python line counts, for example. (python has very strict rules about putting multiple things on the same line). Obviously no simple measure is going to satisfy everyone, but I think the gzip measure is more even handed across a range of languages. It probably more closely aproximates the amount of mental effort and hence time it requires to construct a program (ie. I can whip out a lot of lines of code in python very quickly, but it takes a lot more of them to do the same work as a single, dense, line of haskell code). > When we compete against Python and its ilk, we do so for programmer > productivity first, and performance second. LOC was a nice measure, > and encouraged terser and more idiomatic programs than the current > crop of performance-tweaked low-level stuff. The haskell entries to the shootout are very obviously written for speed and not elegance. If you want to do better on the LoC measure, you can definitely do so (at the expense of speed). > -k Tim Newsham http://www.thenewsh.com/~newsham/ From felipe.lessa at gmail.com Thu Nov 1 14:57:54 2007 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu Nov 1 14:55:19 2007 Subject: [Haskell-cafe] Re: do/if/then/else confusion In-Reply-To: <472A1282.5090202@sanger.ac.uk> References: <472A113C.9080401@sanger.ac.uk> <472A1282.5090202@sanger.ac.uk> Message-ID: On 11/1/07, David Carter wrote: > (But I still think the error message is less than helpful!). Maybe a bug should be filled? -- Felipe. From sebastian.sylvan at gmail.com Thu Nov 1 14:58:45 2007 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Nov 1 14:56:05 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> Message-ID: <3d96ac180711011158q703dddddxa7e5c6faf27a7c69@mail.gmail.com> On 01/11/2007, Tim Newsham wrote: > > Unfortunately, they replaced line counts with bytes of gzip'ed code -- > > while the former certainly has its problems, I simply cannot imagine > > what relevance the latter has (beyond hiding extreme amounts of > > repetitive boilerplate in certain languages). > > Sounds pretty fair to me. Programming is a job of compressing a solution > set. Excessive boilerplate might mean that you have to type a lot, but > doesn't necessarily mean that you have to think a lot. I think the > previous line count was skewed in favor of very terse languages like > haskell, especially languages that let you put many ideas onto a single > line. At the very least there should be a constant factor applied when > comparing haskell line counts to python line counts, for example. > (python has very strict rules about putting multiple things on the same > line). > > Obviously no simple measure is going to satisfy everyone, but I think the > gzip measure is more even handed across a range of languages. It probably > more closely aproximates the amount of mental effort and hence time it > requires to construct a program (ie. I can whip out a lot of lines of code > in python very quickly, but it takes a lot more of them to do the same > work as a single, dense, line of haskell code). > > > When we compete against Python and its ilk, we do so for programmer > > productivity first, and performance second. LOC was a nice measure, > > and encouraged terser and more idiomatic programs than the current > > crop of performance-tweaked low-level stuff. > > The haskell entries to the shootout are very obviously written for speed > and not elegance. If you want to do better on the LoC measure, you can > definitely do so (at the expense of speed). > Personally I think syntactic noise is highly distracting, and semantic noise is even worse! Gzip'd files don't show you that one language will require you to do 90% book-keeping for 10% algorithm, while the other lets you get on with the job, it may make it look as if both languages are roughly equally good at letting the programmer focus on the important bits. I'm not sure what metric to use, but actively disgusing noisy languages using compression sure doesn't seem like anywhere close to the ideal. Token count would be good, but then we'd need a parser for each language, which is quite a bit of work to do... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 From hughperkins at gmail.com Thu Nov 1 15:08:26 2007 From: hughperkins at gmail.com (Hugh Perkins) Date: Thu Nov 1 15:05:46 2007 Subject: [Haskell-cafe] Why can't Haskell be faster? In-Reply-To: <11b141710710310254l5943b800j1985beacaa745bd@mail.gmail.com> References: <11b141710710310254l5943b800j1985beacaa745bd@mail.gmail.com> Message-ID: <837db430711011208n4a453f2fr41018e1c14dfb926@mail.gmail.com> On 10/31/07, Paulo J. Matos wrote: > Hello all, > > I, along with some friends, have been looking to Haskell lately. I'm > very happy with Haskell as a language, however, a friend sent me the > link: > http://shootout.alioth.debian.org/gp4/ > Careful: it's worse than you think. Many of the solutions to the shootout test are using "imperative" Haskell. "Real" "functional" Haskell performs significantly slower. (Orders of magnitude) From cconway at cs.nyu.edu Thu Nov 1 15:11:58 2007 From: cconway at cs.nyu.edu (Christopher L Conway) Date: Thu Nov 1 15:09:40 2007 Subject: [Haskell-cafe] Disjunctive Normal Form In-Reply-To: <7ca3f0160711011141q2f115331w5b6d7f2efd08f77e@mail.gmail.com> References: <13534567.post@talk.nabble.com> <7ca3f0160711011141q2f115331w5b6d7f2efd08f77e@mail.gmail.com> Message-ID: <4a051d930711011211g6d9e8a16rcf4920c7bc7162dd@mail.gmail.com> Jim, Lukes suggestion is a good one, and should help focus you on the syntactic constraints of DNF. A property that your dnf function should have is that the right-hand side of each case should yield a DNF formula. Take, for example, dnf (And s1 s2) = And (dnf s1) (dnf s2) Does And'ing two DNF formulas together yield a DNF? Regards, Chris On 11/1/07, Luke Palmer wrote: > A good way to approach this is data-structure-driven programming. You > want a data structure which represents, and can _only_ represent, > propositions in DNF. So: > > data Term = Pos Var | Neg Var > type Conj = [Term] > type DNF = [Conj] > > Then write: > > dnf :: LS -> DNF > > The inductive definition of dnf is straightforward given this output type... > > Luke > > On 11/1/07, Jim Burton wrote: > > > > I am trying to rewrite sentences in a logical language into DNF, and wonder > > if someone would point out where I'm going wrong. My dim understanding of it > > is that I need to move And and Not inwards and Or out, but the function > > below fails, for example: > > > > > dnf (Or (And A B) (Or (And C D) E)) > > And (Or A (And (Or C E) (Or D E))) (Or B (And (Or C E) (Or D E))) > > > > > > data LS = Var | Not LS | And LS LS | Or LS LS > > --convert sentences to DNF > > dnf :: LS -> LS > > dnf (And (Or s1 s2) s3) = Or (And (dnf s1) (dnf s3)) (And (dnf s2) (dnf s3)) > > dnf (And s1 (Or s2 s3)) = Or (And (dnf s1) (dnf s2)) (And (dnf s1) (dnf s3)) > > dnf (And s1 s2) = And (dnf s1) (dnf s2) > > dnf (Or s1 s2) = Or (dnf s1) (dnf s2) > > dnf (Not (Not d)) = dnf d > > dnf (Not (And s1 s2)) = Or (Not (dnf s1)) (Not (dnf s2)) > > dnf (Not (Or s1 s2)) = And (Not (dnf s1)) (Not (dnf s2)) > > dnf s = s > > > > Thanks, > > > > Jim > > > > -- > > View this message in context: http://www.nabble.com/Disjunctive-Normal-Form-tf4733248.html#a13534567 > > 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 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From hughperkins at gmail.com Thu Nov 1 15:34:11 2007 From: hughperkins at gmail.com (Hugh Perkins) Date: Thu Nov 1 15:31:31 2007 Subject: [Haskell-cafe] Re: Hiding side effects in a data structure In-Reply-To: <20071025233154.GC28058@momenergy.repetae.net> References: <4718DE02.9090603@jellybean.co.uk> <05469CE9-8284-4988-B745-DE7AE08ABC68@ece.cmu.edu> <20071025233154.GC28058@momenergy.repetae.net> Message-ID: <837db430711011234v315a8a38s5c6ac27214242dac@mail.gmail.com> On 10/26/07, John Meacham wrote: > Heh, the plethora of pdf papers on Haskell is part of what originally > brought me to respect it. Something about that metafont painted cmr > just makes me giddy as a grad student. A beautifully rendered type > inference table is a masterful work of art. > > Did I mention I was a little odd? I am sure I did. > http://xkcd.com/242/ Actually, yeah I kindof agree. It's quite interesting to see a language developed using rigorous, formal mathematical principles. From lennart at augustsson.net Thu Nov 1 15:46:56 2007 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Nov 1 15:44:15 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <1557573258.20071101110128@gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <404396ef0710311249nf41f32bt98c3b044b3c45739@mail.gmail.com> <625b74080710311358s2c4a1a4ag61dcbd516d840468@mail.gmail.com> <1557573258.20071101110128@gmail.com> Message-ID: Yes, of course. But they don't do partial evaluation. On 11/1/07, Bulat Ziganshin wrote: > > Hello Lennart, > > Thursday, November 1, 2007, 2:45:49 AM, you wrote: > > > But yeah, a code generator at run time is a very cool idea, and one > > that has been studied, but not enough. > > vm-based languages (java, c#) has runtimes that compile bytecode to > the native code at runtime > > -- > 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/20071101/e354e879/attachment.htm From paul.hudak at yale.edu Thu Nov 1 15:54:18 2007 From: paul.hudak at yale.edu (Paul Hudak) Date: Thu Nov 1 15:51:39 2007 Subject: [Haskell-cafe] Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> Message-ID: <472A2EEA.1020205@yale.edu> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071101/b2fa0035/attachment-0001.htm From jon.fairbairn at cl.cam.ac.uk Thu Nov 1 17:42:26 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Nov 1 17:40:01 2007 Subject: [Haskell-cafe] Re: Hiding side effects in a data structure References: <4718DE02.9090603@jellybean.co.uk> <05469CE9-8284-4988-B745-DE7AE08ABC68@ece.cmu.edu> <20071025233154.GC28058@momenergy.repetae.net> <837db430711011234v315a8a38s5c6ac27214242dac@mail.gmail.com> Message-ID: "Hugh Perkins" writes: > On 10/26/07, John Meacham wrote: >> Heh, the plethora of pdf papers on Haskell is part of what originally >> brought me to respect it. Something about that metafont painted cmr >> just makes me giddy as a grad student. A beautifully rendered type >> inference table is a masterful work of art. >> >> Did I mention I was a little odd? I am sure I did. >> > > http://xkcd.com/242/ > > Actually, yeah I kindof agree. It's quite interesting to see a > language developed using rigorous, formal mathematical principles. Lest anyone think otherwise, I most thoroughly approve of Haskell relying on rigorous foundations. I just want the foundations to be easy to inspect! -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From jules at jellybean.co.uk Thu Nov 1 17:52:07 2007 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Nov 1 17:49:27 2007 Subject: [Haskell-cafe] do/if/then/else confusion In-Reply-To: <472A113C.9080401@sanger.ac.uk> References: <472A113C.9080401@sanger.ac.uk> Message-ID: <472A4A87.2000801@jellybean.co.uk> David Carter wrote: > readdirAll :: PD.DirStream -> IO [String] > readdirAll d = > do dir <- PD.readDirStream d > if dir == "" > then return [] > else rest <- readdirAll d > return (dir:rest) > > Compiling with GHC 6.6.1 gives me the not-very-useful message "Parse > error in pattern", pointing to the "i" of "if". I've tried all kinds of You've worked out the answer, and that's fine. You also said later in the thread that the error message isn't very good. (Which I agree with) Perhaps it might help to understand why you do, in fact, get that strange message. It might illuminate why it's quite so hard to get good error messages in haskell :-( [*] When you reach the "i" in "if", ghc knows that you are in a "do" expression. A "do" expression is a sequence of statements separated by semicolons (or layout, standing in for semicolons). When we decode the layout, everything indented further is "part of the same statement". So in particular, your code parses as do { dir <- PD.readDirStream d ; if dir == "" then return [] else rest <- readdirAll d return (dir:rest); } The first statement in the do block is fine. The second is the problem. Now statements are of two basic forms. They either have binders, or not. They are either foo <- expr or simply expr Since the second line contains the magic <-, it must be the former. So what you have is 'if dir == "" then return [] else rest' being the 'foo', i.e. the bit before the <-. Now what is *supposed* to come before <- is a pattern (normally a variable name, which is a simple case of a pattern). "if" is a keyword which is not permitted to be a variable name or part of a pattern. Hence "parse error in pattern". Not sure if that is at all edifying, but it was an interesting exercise to write it... Jules * there are two reasons it's really hard to write a haskell compiler with good error messages. (1) the layout rule. (2) the use of exotic type system tricks like type classes to achieve elegant syntax. I don't mean to say that the developers of haskell compilers shouldn't keep trying though! From jules at jellybean.co.uk Thu Nov 1 17:54:50 2007 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Nov 1 17:52:14 2007 Subject: [Haskell-cafe] Disjunctive Normal Form In-Reply-To: <13534567.post@talk.nabble.com> References: <13534567.post@talk.nabble.com> Message-ID: <472A4B2A.6060401@jellybean.co.uk> It's much much easier to work with n-ary than binary. It's also easier to define disjunctive normal form by mutual recursion with conjunctive normal form. Jules From jonathanccast at fastmail.fm Thu Nov 1 18:00:56 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Nov 1 17:58:46 2007 Subject: [Haskell-cafe] Re: Hiding side effects in a data structure In-Reply-To: References: <4718DE02.9090603@jellybean.co.uk> <05469CE9-8284-4988-B745-DE7AE08ABC68@ece.cmu.edu> <20071025233154.GC28058@momenergy.repetae.net> <837db430711011234v315a8a38s5c6ac27214242dac@mail.gmail.com> Message-ID: <1193954456.9500.114.camel@jcchost> On Thu, 2007-11-01 at 21:42 +0000, Jon Fairbairn wrote: > "Hugh Perkins" writes: > > > On 10/26/07, John Meacham wrote: > >> Heh, the plethora of pdf papers on Haskell is part of what originally > >> brought me to respect it. Something about that metafont painted cmr > >> just makes me giddy as a grad student. A beautifully rendered type > >> inference table is a masterful work of art. > >> > >> Did I mention I was a little odd? I am sure I did. > >> > > > > http://xkcd.com/242/ > > > > Actually, yeah I kindof agree. It's quite interesting to see a > > language developed using rigorous, formal mathematical principles. > > Lest anyone think otherwise, I most thoroughly approve of > Haskell relying on rigorous foundations. I just want the > foundations to be easy to inspect! It doesn't strike me that math in HTML is easier to inspect than PDF. jcc From cgibbard at gmail.com Thu Nov 1 18:53:48 2007 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Nov 1 18:51:10 2007 Subject: [Haskell-cafe] Re: Hiding side effects in a data structure In-Reply-To: References: <4718DE02.9090603@jellybean.co.uk> Message-ID: <89ca3d1f0711011553p394fb898mf2afa9528ee33ccd@mail.gmail.com> On 21/10/2007, Jon Fairbairn wrote: > No, they (or at least links to them) typically are that bad! > Mind you, as far as fragment identification is concerned, so > are a lot of html pages. But even if the links do have > fragment ids, pdfs still impose a significant overhead: I > don't want stuff swapped out just so that I can run a pdf > viewer; a web browser uses up enough resources as it is. And > will Hoogle link into pdfs? Swapped out!? What PDF viewer are you running on what machine? Currently, with a 552 page book open (Hatcher's algebraic topology), my PDF viewer (Evince) uses about 36MiB, which is around 3.6% of my available memory, a rather pedestrian 1 GiB. Other documents produce very similar results. The largest I was able to make it with a PDF which wasn't pathologically constructed was about 42MiB, with a PDF that had lots of diagrams. Firefox uses about twice that on an average day. If your PDF viewer uses significantly more than that, I recommend looking for a new one. ;) - Cale From horng_twu_lihn at merck.com Thu Nov 1 19:22:06 2007 From: horng_twu_lihn at merck.com (Lihn, Steve) Date: Thu Nov 1 19:20:10 2007 Subject: [Haskell-cafe] Is there a module for multivariate linear regression? In-Reply-To: <05DFD60A-FFC1-46F7-97CE-C938429B2F62@gmail.com> References: <05DFD60A-FFC1-46F7-97CE-C938429B2F62@gmail.com> Message-ID: <6BD267D89E66B9499514F119920E583C01ECD807@usctmx1110.merck.com> I am looking for a Haskell module that will do multivariate linear regression. Does someone know which module will do it? That is, the equivalent of Perl's Statistics::Regression.pm. http://search.cpan.org/~itub/PerlMol-0.35_00.ppm/lib/Statistics/Regression.pm Thanks, Steve ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------ From arnarbi at gmail.com Thu Nov 1 19:36:51 2007 From: arnarbi at gmail.com (Arnar Birgisson) Date: Thu Nov 1 19:34:16 2007 Subject: [Haskell-cafe] Disjunctive Normal Form In-Reply-To: <7ca3f0160711011141q2f115331w5b6d7f2efd08f77e@mail.gmail.com> References: <13534567.post@talk.nabble.com> <7ca3f0160711011141q2f115331w5b6d7f2efd08f77e@mail.gmail.com> Message-ID: <28012bc60711011636p75e1df6fj1781e7ce045ad368@mail.gmail.com> Hey folks, On Nov 1, 2007 6:41 PM, Luke Palmer wrote: > A good way to approach this is data-structure-driven programming. You > want a data structure which represents, and can _only_ represent, > propositions in DNF. So: > > data Term = Pos Var | Neg Var > type Conj = [Term] > type DNF = [Conj] > > Then write: > > dnf :: LS -> DNF > > The inductive definition of dnf is straightforward given this output type... Jim, if you don't want to see an attempt at a solution, don't read further. I'm learning too and found this an interesting problem. Luke, is this similar to what you meant? data LS = Var String | Not LS | And LS LS | Or LS LS deriving Show data Term = Pos String | Neg String deriving Show type Conj = [Term] type DNF = [Conj] dnf :: LS -> DNF dnf (Var s) = [[Pos s]] dnf (Or l1 l2) = (dnf l1) ++ (dnf l2) dnf (And l1 l2) = [t1 ++ t2 | t1 <- dnf l1, t2 <- dnf l2] dnf (Not (Not d)) = dnf d dnf (Not (And l1 l2)) = (dnf $ Not l1) ++ (dnf $ Not l2) dnf (Not (Or l1 l2)) = [t1 ++ t2 | t1 <- dnf $ Not l1, t2 <- dnf $ Not l2] dnf (Not (Var s)) = [[Neg s]] -- test cases x = (Or (And (Var "A") (Var "B")) (Or (And (Not $ Var "C") (Var "D")) (Var "E"))) y = (Not (And (Var "A") (Var "B"))) z = (Not (And (Not y) y)) Also, is it correct? cheers, Arnar From lrpalmer at gmail.com Thu Nov 1 20:11:20 2007 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Nov 1 20:08:40 2007 Subject: [Haskell-cafe] Disjunctive Normal Form In-Reply-To: <28012bc60711011636p75e1df6fj1781e7ce045ad368@mail.gmail.com> References: <13534567.post@talk.nabble.com> <7ca3f0160711011141q2f115331w5b6d7f2efd08f77e@mail.gmail.com> <28012bc60711011636p75e1df6fj1781e7ce045ad368@mail.gmail.com> Message-ID: <7ca3f0160711011711s5cec9788i768a9e0f942e11e@mail.gmail.com> On 11/1/07, Arnar Birgisson wrote: > I'm learning too and found this an interesting problem. Luke, is this > similar to what you meant? Heh, your program is almost identical to the one I wrote to make sure I wasn't on crack. :-) > data LS = Var String | Not LS | And LS LS | Or LS LS deriving Show > > data Term = Pos String | Neg String deriving Show > type Conj = [Term] > type DNF = [Conj] > > dnf :: LS -> DNF > dnf (Var s) = [[Pos s]] > dnf (Or l1 l2) = (dnf l1) ++ (dnf l2) > dnf (And l1 l2) = [t1 ++ t2 | t1 <- dnf l1, t2 <- dnf l2] > dnf (Not (Not d)) = dnf d > dnf (Not (And l1 l2)) = (dnf $ Not l1) ++ (dnf $ Not l2) > dnf (Not (Or l1 l2)) = [t1 ++ t2 | t1 <- dnf $ Not l1, t2 <- dnf $ Not l2] These two are doing a little extra work: dnf (Not (And l1 l2)) = dnf (Or (Not l1) (Not l2)) dnf (Not (Or l1 l2)) = dnf (And (Not l1) (Not l2)) > dnf (Not (Var s)) = [[Neg s]] > > -- test cases > x = (Or (And (Var "A") (Var "B")) (Or (And (Not $ Var "C") (Var "D")) > (Var "E"))) > y = (Not (And (Var "A") (Var "B"))) > z = (Not (And (Not y) y)) Luke From lrpalmer at gmail.com Thu Nov 1 20:15:18 2007 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Nov 1 20:12:37 2007 Subject: [Haskell-cafe] Disjunctive Normal Form In-Reply-To: <7ca3f0160711011711s5cec9788i768a9e0f942e11e@mail.gmail.com> References: <13534567.post@talk.nabble.com> <7ca3f0160711011141q2f115331w5b6d7f2efd08f77e@mail.gmail.com> <28012bc60711011636p75e1df6fj1781e7ce045ad368@mail.gmail.com> <7ca3f0160711011711s5cec9788i768a9e0f942e11e@mail.gmail.com> Message-ID: <7ca3f0160711011715r3a468151qc8f37ee1b43e54a3@mail.gmail.com> On 11/2/07, Luke Palmer wrote: > On 11/1/07, Arnar Birgisson wrote: > > dnf :: LS -> DNF > > dnf (Var s) = [[Pos s]] > > dnf (Or l1 l2) = (dnf l1) ++ (dnf l2) > > dnf (And l1 l2) = [t1 ++ t2 | t1 <- dnf l1, t2 <- dnf l2] > > dnf (Not (Not d)) = dnf d > > dnf (Not (And l1 l2)) = (dnf $ Not l1) ++ (dnf $ Not l2) > > dnf (Not (Or l1 l2)) = [t1 ++ t2 | t1 <- dnf $ Not l1, t2 <- dnf $ Not l2] > > These two are doing a little extra work: > > dnf (Not (And l1 l2)) = dnf (Or (Not l1) (Not l2)) > dnf (Not (Or l1 l2)) = dnf (And (Not l1) (Not l2)) I should clarify. I meant that *you* were doing a little extra work, by re-implementing that logic for the not cases. I'm a fan of only implementing each "unit" of logic in one place, whatever that means. But to appease the pedantic, my versions are actually doing more computational work: they are doing one extra pattern match when these patterns are encountered. Whoopty-doo. :-) Luke From ajb at spamcop.net Thu Nov 1 21:21:05 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Nov 1 21:18:24 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <404396ef0710311249nf41f32bt98c3b044b3c45739@mail.gmail.com> <625b74080710311358s2c4a1a4ag61dcbd516d840468@mail.gmail.com> <1193879977.22009.3.camel@derek-laptop> <20071101012030.w8guqnwjvossw400@webmail.spamcop.net> Message-ID: <20071101212105.uscj9wff48wg0w4w@webmail.spamcop.net> Quoting Justin Bailey : > Done: http://www.haskell.org/haskellwiki/RuntimeCompilation . Please > update it as needed. Thanks! Cheers, Andrew Bromage From ph_kittichai at yahoo.com Thu Nov 1 22:20:53 2007 From: ph_kittichai at yahoo.com (karle) Date: Thu Nov 1 22:18:10 2007 Subject: [Haskell-cafe] Need help from a newby Message-ID: <13540531.post@talk.nabble.com> My declaration is as followed:- type Address = Int data Port = C | D deriving(Eq,Show) data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) data Pkgtype = RTD | U deriving(Eq,Show) type Pkg = (Pkgtype,Address,Payload) type Table = [(Address,Port)] findport::[Pkg]->[Table]->[([Pkg],[Pkg])] findport [(pt,ad,pa)] [(a,p)] | ( p == C) = ([pt,ad,a],[]) | otherwise = ([],[pt,ad,a]) Error received:- Type error in explicitly typed binding *** Term : [(a,p)] *** Type : [(a,b)] *** Does not match : [Table] Can anyone please help? -- View this message in context: http://www.nabble.com/Need-help-from-a-newby-tf4735009.html#a13540531 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From haskell at list.mightyreason.com Thu Nov 1 22:41:38 2007 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Nov 1 22:39:03 2007 Subject: [Haskell-cafe] Re: Need help from a newby In-Reply-To: <13540531.post@talk.nabble.com> References: <13540531.post@talk.nabble.com> Message-ID: <472A8E62.4030205@list.mightyreason.com> karle wrote: > My declaration is as followed:- > > type Address = Int > data Port = C | D deriving(Eq,Show) > data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) > data Pkgtype = RTD | U deriving(Eq,Show) > type Pkg = (Pkgtype,Address,Payload) > type Table = [(Address,Port)] > > > findport::[Pkg]->[Table]->[([Pkg],[Pkg])] > findport [(pt,ad,pa)] [(a,p)] > | ( p == C) = ([pt,ad,a],[]) > | otherwise = ([],[pt,ad,a]) > > Error received:- > > Type error in explicitly typed binding > *** Term : [(a,p)] > *** Type : [(a,b)] > *** Does not match : [Table] > > Can anyone please help? There seems to be several things that look wrong. Could you explain what findport is supposed to be doing? From ph_kittichai at yahoo.com Thu Nov 1 22:46:24 2007 From: ph_kittichai at yahoo.com (karle) Date: Thu Nov 1 22:43:40 2007 Subject: [Haskell-cafe] Need help from a newby In-Reply-To: <472A8E62.4030205@list.mightyreason.com> References: <13540531.post@talk.nabble.com> <472A8E62.4030205@list.mightyreason.com> Message-ID: <13541442.post@talk.nabble.com> ChrisK-3 wrote: > > karle wrote: >> My declaration is as followed:- >> >> type Address = Int >> data Port = C | D deriving(Eq,Show) >> data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) >> data Pkgtype = RTD | U deriving(Eq,Show) >> type Pkg = (Pkgtype,Address,Payload) >> type Table = [(Address,Port)] >> >> >> findport::[Pkg]->[Table]->[([Pkg],[Pkg])] >> findport [(pt,ad,pa)] [(a,p)] >> | ( p == C) = ([pt,ad,a],[]) >> | otherwise = ([],[pt,ad,a]) >> >> Error received:- >> >> Type error in explicitly typed binding >> *** Term : [(a,p)] >> *** Type : [(a,b)] >> *** Does not match : [Table] >> >> Can anyone please help? > > There seems to be several things that look wrong. > > Could you explain what findport is supposed to be doing? > > findport is just to check if the port in the Table is equal to C then it > will place the packet in the first of the list. Otherwise it will place > the packet in the second of the list. > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- View this message in context: http://www.nabble.com/Need-help-from-a-newby-tf4735009.html#a13541442 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From cconway at cs.nyu.edu Thu Nov 1 23:52:45 2007 From: cconway at cs.nyu.edu (Christopher L Conway) Date: Thu Nov 1 23:50:03 2007 Subject: [Haskell-cafe] Need help from a newby In-Reply-To: <13540531.post@talk.nabble.com> References: <13540531.post@talk.nabble.com> Message-ID: <4a051d930711012052n42b6035aqb859d673a44dc9ef@mail.gmail.com> Substitute the definition of type Table into the error: Type error in explicitly typed binding *** Term : [(a,p)] *** Type : [(a,b)] *** Does not match : [Table] where [Table] = [[(Address,Port)]] Do you see why the expression [ (a,p) ] cannot have type [ [ (Address, Port) ] ] ? Regards, Chris On 11/1/07, karle wrote: > > My declaration is as followed:- > > type Address = Int > data Port = C | D deriving(Eq,Show) > data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) > data Pkgtype = RTD | U deriving(Eq,Show) > type Pkg = (Pkgtype,Address,Payload) > type Table = [(Address,Port)] > > > findport::[Pkg]->[Table]->[([Pkg],[Pkg])] > findport [(pt,ad,pa)] [(a,p)] > | ( p == C) = ([pt,ad,a],[]) > | otherwise = ([],[pt,ad,a]) > > Error received:- > > Type error in explicitly typed binding > *** Term : [(a,p)] > *** Type : [(a,b)] > *** Does not match : [Table] > > Can anyone please help? > -- > View this message in context: http://www.nabble.com/Need-help-from-a-newby-tf4735009.html#a13540531 > 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 haskell at list.mightyreason.com Fri Nov 2 00:19:40 2007 From: haskell at list.mightyreason.com (ChrisK) Date: Fri Nov 2 00:17:16 2007 Subject: [Haskell-cafe] Re: Need help from a newby In-Reply-To: <13541442.post@talk.nabble.com> References: <13540531.post@talk.nabble.com> <472A8E62.4030205@list.mightyreason.com> <13541442.post@talk.nabble.com> Message-ID: <472AA55C.5020106@list.mightyreason.com> karle wrote: > > > ChrisK-3 wrote: >> karle wrote: >>> My declaration is as followed:- >>> >>> type Address = Int >>> data Port = C | D deriving(Eq,Show) >>> data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) >>> data Pkgtype = RTD | U deriving(Eq,Show) >>> type Pkg = (Pkgtype,Address,Payload) >>> type Table = [(Address,Port)] >>> >>> >>> findport::[Pkg]->[Table]->[([Pkg],[Pkg])] >>> findport [(pt,ad,pa)] [(a,p)] >>> | ( p == C) = ([pt,ad,a],[]) >>> | otherwise = ([],[pt,ad,a]) >>> >>> Error received:- >>> >>> Type error in explicitly typed binding >>> *** Term : [(a,p)] >>> *** Type : [(a,b)] >>> *** Does not match : [Table] >>> >>> Can anyone please help? >> There seems to be several things that look wrong. >> >> Could you explain what findport is supposed to be doing? >> >> findport is just to check if the port in the Table is equal to C then it >> will place the packet in the first of the list. Otherwise it will place >> the packet in the second of the list. So for each Pkg in [Pkg] the findport function takes the Address element in the Pkg and looks it up in the Table. If the Address is C or D the original pkg gets places in the first or second output list. The 'partition' function from Data.List could help here: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#v%3Apartition > partition :: (a -> Bool) -> [a] -> ([a], [a]) > > The partition function takes a predicate a list and returns the pair of lists > of elements which do and do not satisfy the predicate, ... But your findport function is fairly broken right now. The output (pt,ad,a) should be (pt,ad,pa). This was likely a typographical error and is caught by the type system. The declared type of the second argument should be Table, not [Table]. This is the simple error that the compiler is reporting. The first argument is matched against the pattern [(pt,ad,pa)] which only matched lists with a single Pkg. This is also true of the second argument getting pattern matched against [(a,p)] since this only matches Tables with a single entry. These are errors in how findport has been written, I'll give you a chance to try fixing each of these. You will need to handle lists with any number of elements (including empty lists). You also do not say what should happen to a Pkg with an Address that is not in the Table. Cheers, Chris From briqueabraque at yahoo.com Fri Nov 2 02:23:59 2007 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Fri Nov 2 02:22:00 2007 Subject: [Haskell-cafe] Re: do/if/then/else confusion In-Reply-To: <472A113C.9080401@sanger.ac.uk> References: <472A113C.9080401@sanger.ac.uk> Message-ID: > (...) > Can someone tell me what's wrong with this? > import qualified System.Posix.Directory as PD > > readdirAll :: PD.DirStream -> IO [String] > readdirAll d = > do dir <- PD.readDirStream d > if dir == "" > then return [] > else rest <- readdirAll d > return (dir:rest) > (...) I don't know if this helps or disturbs, but I wrote a few different versions of your code as an exercise. If you want to try it, just uncomment the versions you want to check. The complete program below lists all files in current directory, using 'readdirAll' to get the full list. Best, Maur?cio module Main (Main.main) where import qualified System.Posix.Directory as PD import Data.List import Control.Monad main :: IO () readdirAll :: PD.DirStream -> IO [String] readdirAll ds = liftM reverse $ read [] where read ("":t) = return t read list = (PD.readDirStream ds) >>= glue where glue f = read (f:list) {- readdirAll ds = read where read = (PD.readDirStream ds) >>= rest rest "" = return [] rest h = liftM (h:) read -} {- readdirAll ds = do f <- PD.readDirStream ds rest f where rest "" = return [] rest h = return (h:) `ap` (readdirAll ds) -} main = (PD.openDirStream ".") >>= readdirAll >>= (putStrLn.show) From v.dijk.bas at gmail.com Fri Nov 2 04:09:17 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Fri Nov 2 04:06:37 2007 Subject: [Haskell-cafe] Slightly off-topic In-Reply-To: <7.0.1.0.0.20071101180412.020ed3d0@ntlworld.com> References: <7.0.1.0.0.20071101180412.020ed3d0@ntlworld.com> Message-ID: On 11/1/07, PR Stanley wrote: > If anyone knows anything about the rules of proof by deduction and > quantifiers I'd be grateful for some assistance. I'm currently doing a course on Type Theory which includes proving by natural deduction. See, among other things, the course notes on: http://www.cs.ru.nl/~freek/courses/tt-2007 regards, Bas van Dijk From spy.hunter at email.cz Fri Nov 2 04:17:23 2007 From: spy.hunter at email.cz (Petr Hoffmann) Date: Fri Nov 2 04:15:15 2007 Subject: [Haskell-cafe] using an external application Message-ID: Hi, I'm solving the following problem - I need to use an external application - give it the input data and receive its output. However, when multiple calls are made, the results are not as expected. The simplified version of the problem is given below: import System.Cmd main = do System.Cmd.system "echo hello >output.txt" -- use the external application to create an output file o1 <- readFile "output.txt" System.Cmd.system "echo bye >output.txt" -- the second call to the external application o2 <- readFile "output.txt" putStr o1 -- "hello" expected, but "bye" printed return 0 Can you please give me some hint to solve this problem? I'm a beginning haskell developer and I'm still a bit confused by the IO monad. Thank you in advance. Petr From jerzy.karczmarczuk at info.unicaen.fr Fri Nov 2 04:27:16 2007 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Fri Nov 2 04:24:28 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: Message-ID: Petr Hoffmann writes: > I'm solving the following problem - I need to use an external > application - give it the input data and receive its output. > However, when multiple calls are made, the results are not > as expected. The simplified version of the problem is given > below: > System.Cmd.system "echo hello >output.txt" -- use the external ... > System.Cmd.system "echo bye >output.txt" -- the second call to > the external application > o2 <- readFile "output.txt" > putStr o1 -- "hello" expected, but "bye" printed > Can you please give me some hint to solve this problem? > I'm a beginning haskell developer and I'm still a bit confused > by the IO monad. I have the impression that your problem has nothing to do do with Haskell, you just rewrite your file, instead of appending to it. But perhaps I didn't look correctly... Jerzy Karczmarczuk From lemming at henning-thielemann.de Fri Nov 2 04:35:24 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 2 04:32:39 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: Message-ID: On Fri, 2 Nov 2007, Petr Hoffmann wrote: > Hi, > > I'm solving the following problem - I need to use an external > application - give it the input data and receive its output. > However, when multiple calls are made, the results are not > as expected. The simplified version of the problem is given > below: > > import System.Cmd > main = do > System.Cmd.system "echo hello >output.txt" -- use the external > application to create an output file > o1 <- readFile "output.txt" > System.Cmd.system "echo bye >output.txt" -- the second call to > the external application > o2 <- readFile "output.txt" > putStr o1 -- "hello" expected, but "bye" printed > return 0 You fell into the trap, that 'readFile' works lazily, that is, data is only read when needed. If o1 is not completely evalutated until the second write to output.txt, it will not be read correctly from the disk. I think it was not a good choice to make the lazy version of 'readFile' the default. I think it would have been better to provide a strict 'readFile' and another 'readFileLazy' with warnings in the documentation. From v.dijk.bas at gmail.com Fri Nov 2 04:36:15 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Fri Nov 2 04:33:33 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: Message-ID: On 11/2/07, Petr Hoffmann wrote: > I'm solving the following problem - I need to use an external > application - give it the input data and receive its output. Check out: The HSH library: "HSH is designed to let you mix and match shell expressions with Haskell programs. With HSH, it is possible to easily run shell commands, capture their output or provide their input, and pipe them to and from other shell commands and arbitrary Haskell functions at will." http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HSH-1.2.4 regards, Bas van Dijk From ketil+haskell at ii.uib.no Fri Nov 2 04:42:22 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Nov 2 04:39:44 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <3d96ac180711011158q703dddddxa7e5c6faf27a7c69@mail.gmail.com> (Sebastian Sylvan's message of "Thu\, 1 Nov 2007 18\:58\:45 +0000") References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> <3d96ac180711011158q703dddddxa7e5c6faf27a7c69@mail.gmail.com> Message-ID: <87r6j9nimp.fsf@nmd9999.imr.no> "Sebastian Sylvan" writes: [LOC vs gz as a program complexity metric] >> Obviously no simple measure is going to satisfy everyone, but I think the >> gzip measure is more even handed across a range of languages. >> It probably more closely aproximates the amount of mental effort [..] I'm not sure I follow that reasoning? At any rate, I think the ICFP contest is much better as a measure of productivity. But, just like for performance, LOC for the shootout can be used as a micro-benchmark. > Personally I think syntactic noise is highly distracting, and semantic > noise is even worse! This is important - productivity doesn't depend so much on the actual typing, but the ease of refactoring, identifying and fixing bugs, i.e *reading* code. Verbosity means noise, and also lower information content in a screenful of code. I think there were some (Erlang?) papers where they showed a correlation between program size (in LOC), time of development, and possibly number of bugs?) - regardless of language. > Token count would be good, but then we'd need a parser for > each language, which is quite a bit of work to do... Whatever you do, it'll be an approximation, so why not 'wc -w'? With 'wc -c' for J etc where programs can be written as spaceless sequences of symbols. Or just average chars, words and lines? -k -- If I haven't seen further, it is by standing in the footprints of giants From scook0 at gmail.com Fri Nov 2 04:47:26 2007 From: scook0 at gmail.com (Stuart Cook) Date: Fri Nov 2 04:44:43 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: Message-ID: <49b351060711020147w52a58e7et46465c5e0fdf5b5f@mail.gmail.com> On 11/2/07, Petr Hoffmann wrote: > import System.Cmd > main = do > System.Cmd.system "echo hello >output.txt" -- use the external > application to create an output file > o1 <- readFile "output.txt" > System.Cmd.system "echo bye >output.txt" -- the second call to > the external application > o2 <- readFile "output.txt" > putStr o1 -- "hello" expected, but "bye" printed > return 0 > > Can you please give me some hint to solve this problem? > I'm a beginning haskell developer and I'm still a bit confused > by the IO monad. This looks like yet another case of the lazy-I/O goblins. The "readFile" function uses evil magic to avoid actually performing any I/O until the contents are actually used. In your case, I suspect that by the time "o1" is used -- i.e. in the "putStr" call -- the file contents have already changed, so the lazy I/O reads the new contents without complaining. The solution would be to use a version of "readFile" that works in a stricter way, by reading the file when it's told to, but I don't have an implementation handy. Stuart From felipe.lessa at gmail.com Fri Nov 2 05:03:25 2007 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri Nov 2 05:00:43 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: <49b351060711020147w52a58e7et46465c5e0fdf5b5f@mail.gmail.com> References: <49b351060711020147w52a58e7et46465c5e0fdf5b5f@mail.gmail.com> Message-ID: On 11/2/07, Stuart Cook wrote: > The solution would be to use a version of "readFile" that works in a > stricter way, by reading the file when it's told to, but I don't have > an implementation handy. I guess this does the job: > readFile' fp = do > contents <- readFile fp > let ret (x:xs) = x `seq` ret xs > ret [] = return contents > ret contents Maybe the "x `seq`" part isn't necessary at all. -- Felipe. From bulat.ziganshin at gmail.com Fri Nov 2 04:34:57 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Nov 2 05:01:34 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <3d96ac180711011158q703dddddxa7e5c6faf27a7c69@mail.gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> <3d96ac180711011158q703dddddxa7e5c6faf27a7c69@mail.gmail.com> Message-ID: <1828188836.20071102113457@gmail.com> Hello Sebastian, Thursday, November 1, 2007, 9:58:45 PM, you wrote: > the ideal. Token count would be good, but then we'd need a parser for > each language, which is quite a bit of work to do... i think that wc (word count) would be good enough approximation -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Fri Nov 2 05:17:41 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 2 05:17:31 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: <49b351060711020147w52a58e7et46465c5e0fdf5b5f@mail.gmail.com> Message-ID: On Fri, 2 Nov 2007, Felipe Lessa wrote: > On 11/2/07, Stuart Cook wrote: > > The solution would be to use a version of "readFile" that works in a > > stricter way, by reading the file when it's told to, but I don't have > > an implementation handy. > > I guess this does the job: > > > readFile' fp = do > > contents <- readFile fp > > let ret (x:xs) = x `seq` ret xs > > ret [] = return contents > > ret contents > > Maybe the "x `seq`" part isn't necessary at all. Awful. It reminds me on MatLab where the developers have implemented many automatisms which do arbitrary clever things in every corner case, but nothing consistent, because they thought programmers want it that way. Then the programmers must write wrappers in order to get functions with consistent behaviour around the fully automated functions. The "unlazying" procedure looks much like the "lazying" one, and I wonder whether it would be a good idea to eventually add "readFileStrict", "getContentStrict" and "hGetContentStrict" to the standard library. From felipe.lessa at gmail.com Fri Nov 2 05:49:13 2007 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri Nov 2 05:46:33 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: <49b351060711020147w52a58e7et46465c5e0fdf5b5f@mail.gmail.com> Message-ID: On 11/2/07, Henning Thielemann wrote: > The "unlazying" procedure looks much like the "lazying" one, and I wonder > whether it would be a good idea to eventually add "readFileStrict", > "getContentStrict" and "hGetContentStrict" to the standard library. As we're talking about getContents and readFile, how about > intercept :: Monad m => m a -> (a -> m b) -> m a > intercept x g = do {r <- x; g r; return r} > > readFileC :: FilePath -> IO String > readFileC fp = intercept (readFile fp) (forkIO . process) > where process xs = last xs `seq` return () Is readFileC useful in practice? I mean, does reading further concurrently makes sense in any useful context? Also, does intercept already exists in a library? Hoogle didn't help me a lot. Thanks, -- Felipe. From mgubi at mac.com Fri Nov 2 06:02:40 2007 From: mgubi at mac.com (Massimiliano Gubinelli) Date: Fri Nov 2 06:07:32 2007 Subject: [Haskell-cafe] space leak? Message-ID: > ( these two lines are just to fool the gmane post algorithm which > complains for top-posting....) Hi, i'm learning Haskell and trying to use the HPDF 1.2 library I've come across some large memory consumption for which I do not understand the origin. I've tried heap profiling but without much success. This is my code > module Main where > import Control.Monad.State > import Graphics.PDF > data Opcodes = Rect | Ship deriving (Show) > doPage (Rect:ops) = do > stroke $! Rectangle 10.0 10.0 10.0 10.0 > doPage ops > doPage l = return l > doOps [] = return () > doOps (Ship:ops) = {-# SCC "OPSHIP" #-} do > p <- addPage Nothing > ops' <- drawWithPage p $! do > strokeColor red > applyMatrix $ (translate 72.0 72.0) > doPage ops > doOps ops' > doOps (op:_) = error ("unexpected " ++ show op) > testpdf = do > let ops = concat $ replicate 100 (Ship : (replicate 1000 Rect )) > pageRect = PDFRect 0 0 > (floor $ 21.0/2.54*72.0) (floor $ 29.7/2.54*72.0) > runPdf "test1.pdf" (standardDocInfo { author=toPDFString "mgubi", > compressed = False}) > pageRect $ doOps ops > testpdf' = do > let pageRect = PDFRect 0 0 > (floor $ 21.0/2.54*72.0) (floor $ 29.7/2.54*72.0) > runPdf "full.pdf" (standardDocInfo { author=toPDFString "mgubi", > compressed = False}) > pageRect $ sequence_ $ foldM f [] $ replicate 100 $ > (\p -> sequence_ $ replicate 1000 $ > drawWithPage p $ stroke $ > Rectangle 0.0 0.0 10.0 10.0) > where f ps acts = do > p <- addPage Nothing > acts p > return $ p:ps > main = testpdf now, if I run testpdf' then memory profile is very low and everything is as expected while if I run testpdf then the profile grows up to 80MB and more. This is the stripped down version of the original program (which is a DVI interpreter) so there I will have also some StateT and more complicated opcodes. I would like to know what is wrong with the above code. Could someone help me? thanks, Massimiliano Gubinelli From nmessenger at gmail.com Fri Nov 2 06:11:53 2007 From: nmessenger at gmail.com (Nicholas Messenger) Date: Fri Nov 2 06:09:10 2007 Subject: [Haskell-cafe] Compile-time evaluation Message-ID: {-# OPTIONS_GHC -fglasgow-exts -fno-monomorphism-restriction #-} -- Many people ask if GHC will evaluate toplevel constants at compile -- time, you know, since Haskell is pure it'd be great if those -- computations could be done once and not use up cycles during -- runtime. Not an entirely bad idea, I think. -- -- So I set about allowing just that: for arbitrary expressions to be -- evaluated, and the expanded expression spliced into client code. -- -- If you had some data in a file just out of convenience, you could say: -- > yourData = $(compileTimeIO $ parseFile $ readFile "data.txt") -- -- Or if you had an expensive computation that you want done at compile: -- > result = $(compileTimeEval $ expensiveComputation) -- -- I would appreciate comments. I wrote this completely blind with just -- the TH and Generics haddocks, so if I'm doing something tremendously -- stupid that can be improved, let me know. :) Especially if you can -- think of a less awkward way to go from Generics' data to TH -- expressions than using 'showConstr'... -- -- I wrote this with 6.6.1, in case there's any incompatibilities. Copy/ -- paste this post into CompileTime.hs, load into ghci, :set -fth, and -- futz around with the splices. -- -- -- Nicholas Messenger (nmessenger at gmail.com, omnId on #haskell) module CompileTime(compileTimeEval, compileTimeIO) where import Data.Generics import Language.Haskell.TH import Control.Monad import Data.Tree import Data.Ratio -- Expands a datum into an expression tree to be spliced into -- client code. compileTimeEval :: Data a => a -> ExpQ compileTimeEval = return . toExp -- Runs the IO action and splices in the evaluated result datum. compileTimeIO :: Data a => IO a -> ExpQ compileTimeIO = liftM toExp . runIO -- Does the work. :) toTree gets us a tree of constructors, so -- we mostly just have to fold the tree with AppE, except for -- TH's bizarre TupE. toExp :: Data d => d -> Exp toExp = applyAll . toTree where applyAll (Node k args) | isTuple k = TupE (map applyAll args) | otherwise = foldl AppE k (map applyAll args) isTuple (ConE n) = all (==',') (nameBase n) isTuple _ = False -- Synonym to shorten the definition of exp below type Ex a = a -> Exp -- Turns some datum into a tree of TH expressions representing -- that datum. The Exp at each node represents the constructor, -- the subtrees are its arguments. toTree :: Data d => d -> Tree Exp toTree x = Node (exp x) (gmapQ toTree x) where -- The various ways to turn a (Data d => d) into an -- Exp representing its constructor. any = ConE . mkName . deparen . showConstr . toConstr char = LitE . CharL int = sigged $ LitE . IntegerL . toInteger rat = sigged $ LitE . RationalL . toRational sigged f x = SigE (f x) (ConT . mkName . show $ typeOf x) -- The above functions combined together for different types. -- This is what gives the constructor Exp at each Node. There -- are definitely more types to cover that 'any' gets wrong... exp = any `extQ` (int::Ex Int) `extQ` (int::Ex Integer) `extQ` char `extQ` (rat::Ex Float) `extQ` (rat::Ex Double) `extQ` (rat::Ex Rational) -- Generics' showConstr puts parens around infix -- constructors. TH's ConE doesn't like 'em. deparen s = (if last s == ')' then init else id) . (if head s == '(' then tail else id) $ s From apfelmus at quantentunnel.de Fri Nov 2 06:35:26 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Nov 2 06:33:19 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: <472A2EEA.1020205@yale.edu> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> <472A2EEA.1020205@yale.edu> Message-ID: Paul Hudak wrote: >> loop, loop' :: *World -> ((),*World) >> >> loop w = loop w >> loop' w = let (_,w') = print "x" w in loop' w' >> >> both have denotation _|_ but are clearly different in terms of side effects. > > One can certainly use an operational semantics such as bisimulation, > but you don't have to abandon denotational semantics. The trick is to > make output part of the "final answer". For a conventional imperative > language one could define, for example, a (lifted, recursive) domain: > > Answer = Terminate + (String x Answer) > > and then define a semantic function "meaning", say, such that: > > meaning loop = _|_ > meaning loop' = <"x", <"x", ... >> > > In other words, loop denotes bottom, whereas loop' denotes the infinite > sequence of "x"s. There would typically also be a symbol to denote > proper termination, perhaps <>. > > A good read on this stuff is Reynolds book "Theories of Programming > Languages", where domain constructions such as the above are called > "resumptions", and can be made to include input as well. > > In the case of Clean, programs take as input a "World" and generate a > "World" as output. One of the components of that World would presumably > be "standard output", and that component's value would be _|_ in the > case of loop, and <"x", <"x", ... >> in the case of loop'. Another part > of the World might be a file system, a printer, a missile firing, and so > on. Presumably loop and loop' would not affect those parts of the World. Ah, so the denotational semantics would be a bit like good old stream-based IO. However, we have to change the semantics of -> , there's no way to put the side effects in *World only. I mean, the problem of both loop and loop' is that they never return any world at all, the side effects occur during function evaluation. Then, we'd need a "purity lemma" that states that any function not involving the type *World as in- and output is indeed pure, which may be a bit tricky to prove in the presence of higher-order functions and polymorphism. I mean, the function arrows are "tagged" for side effects in a strange way, namely by looking like *World -> ... -> (*World, ...). In contrast, we can see IO a as an abstract (co-)data type subject to some straightforward operational semantics, no need to mess with the pure -> . So, in a sense, the Haskell way is cleaner than the Clean way ;) Regards, apfelmus From bulat.ziganshin at gmail.com Fri Nov 2 07:07:30 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Nov 2 07:05:39 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: Message-ID: <19110668848.20071102140730@gmail.com> Hello Petr, Friday, November 2, 2007, 11:17:23 AM, you wrote: > o1 <- readFile "output.txt" add "return $! length o1" here to evaluate whole list > System.Cmd.system "echo bye >output.txt" -- the second call to -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From greenrd at greenrd.org Fri Nov 2 07:09:55 2007 From: greenrd at greenrd.org (Robin Green) Date: Fri Nov 2 07:07:15 2007 Subject: [Haskell-cafe] Compile-time evaluation In-Reply-To: References: Message-ID: <20071102110955.40593ec0@greenrd.ucd.ie> On Fri, 2 Nov 2007 05:11:53 -0500 "Nicholas Messenger" wrote: > -- Many people ask if GHC will evaluate toplevel constants at compile > -- time, you know, since Haskell is pure it'd be great if those > -- computations could be done once and not use up cycles during > -- runtime. Not an entirely bad idea, I think. I implemented the same idea. First a note about nomenclature: since there is a Template Haskell class for the concept of "translating actual values into TH representations of those values" called Lift, I call that "lifting"; I also call evaluating and storing top-level constants at compile time "baking them into the executable". >From glancing at your code, my approach has two main differences (apart from the fact that I didn't implement support for all of the types that you did): 1. A generic lifter using Data.Generics does not work for certain types, like IntSet. So I implemented the Template Haskell class Lift for each of my own data types that I wanted to use in lifting, and where it would work, called my generic lifter function, otherwise lifted it more manually (as shown below). 2. I used synthesise instead of gmapQ, and did not use an intermediate Tree data structure. Here is the module which does most of the work. (You will not be able to compile this as-is, obviously, because I have not published the rest of my code yet.) {-# OPTIONS_GHC -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -XTemplateHaskell #-} module Language.Coq.Syntax.AbstractionBaking where import Data.Generics.Basics (ConstrRep(..), constrRep, Data, toConstr, Typeable) import Data.Generics.Schemes (synthesize) import Data.List (foldl') import Data.IntSet (IntSet) import qualified Data.IntSet as IntSet (fromList, toList) import Data.Set (Set) import qualified Data.Set as Set (fromList, toList) import Language.Haskell.TH.Lib (appE, charL, conE, ExpQ, infixE, integerL, litE) import Language.Haskell.TH.Syntax (Lift(..), mkName) import System.FilePath (()) import Data.DList (DList) import Data.ListLike (fromList, ListLike, toList) import Language.Coq.Parser (CoqParserState(..)) import Language.Coq.Syntax.Abstract (CoqState(..), Sentence, Term) import Language.Coq.Syntax.Concrete (NotationRec(..)) import Language.Coq.Syntax.ParseSpec lifter :: Data d => d -> ExpQ lifter = head . synthesize [] (++) combiner where combiner x args = [case rep of IntConstr i -> litE $ integerL i AlgConstr _ -> algebraic (show constr) args StringConstr (h:_) -> litE $ charL h _ -> fail $ "Unimplemented constrRep: " ++ show rep] where constr = toConstr x rep = constrRep constr algebraic "(:)" = cons algebraic name = foldl' appE $ conE $ mkName name cons [] = [e| (:) |] cons [left] = infixE (Just left) (cons []) Nothing cons [left, right] = infixE (Just left) (cons []) $ Just right instance Lift NotationRec where lift (NotationRec w x y z) = appE (appE (appE (appE [| NotationRec |] $ lift w) $ lift x) $ lift y) $ lift z instance Lift ParseSpecTok where lift = lifter instance Lift Associativity where lift = lifter instance Lift Sentence where lift = lifter instance Lift Term where lift = lifter instance Lift CoqState where lift (CoqState x y) = appE (appE [| CoqState |] $ lift x) $ lift y instance Lift CoqParserState where lift (CoqParserState x y z) = appE (appE (appE [| CoqParserState |] $ lift x) $ lift y) $ lift z instance (Lift a, ListLike full a) => Lift full where lift = appE [| fromList |] . lift . toList instance Lift IntSet where lift = appE [| IntSet.fromList |] . lift . IntSet.toList instance Lift a => Lift (Set a) where lift = appE [| Set.fromList |] . lift . Set.toList -- Robin From Andrew.Butterfield at cs.tcd.ie Fri Nov 2 07:19:38 2007 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Fri Nov 2 07:15:41 2007 Subject: [Haskell-cafe] using an external application Message-ID: <472B07CA.60301@cs.tcd.ie> > On 11/2/07, Petr Hoffmann wrote: > >> import System.Cmd >> main = do >> System.Cmd.system "echo hello >output.txt" -- use the external >> application to create an output file >> o1 <- readFile "output.txt" >> System.Cmd.system "echo bye >output.txt" -- the second call to >> the external application >> o2 <- readFile "output.txt" >> putStr o1 -- "hello" expected, but "bye" printed >> return 0 >> >> Can you please give me some hint to solve this problem? >> I'm a beginning haskell developer and I'm still a bit confused >> by the IO monad. >> > > I'm puzzled - when I run this on GHCi (v6.4, Windows XP) I get the following outcome *Main>main The process cannot access the file because it is being used by another process. hello *Main> This is certainly the behaviour I would expect - seeing "bye" being printed seems to me to be an error and may even constitute a violation of referential transparency. What implementation of GHC are you using ? > This looks like yet another case of the lazy-I/O goblins. > Yes, but not quite what everyone has being addressing.... -- -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. Course Director, B.A. (Mod.) in CS and ICT degrees, Year 4. Department of Computer Science, Room F.13, O'Reilly Institute, Trinity College, University of Dublin, Ireland. http://www.cs.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- From scook0 at gmail.com Fri Nov 2 07:37:05 2007 From: scook0 at gmail.com (Stuart Cook) Date: Fri Nov 2 07:34:21 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: <472B07CA.60301@cs.tcd.ie> References: <472B07CA.60301@cs.tcd.ie> Message-ID: <49b351060711020437h1ad2180fr862fcf10c9cc758@mail.gmail.com> On 11/2/07, Andrew Butterfield wrote: > I'm puzzled - when I run this on GHCi (v6.4, Windows XP) I get the > following outcome > > *Main>main > The process cannot access the file because it is being used by another > process. > hello > *Main> Under GHCi 6.6 I get this: *Main> main bye 0 My guess is that 6.4's readFile always opens the file as soon as it is called, whereas 6.6's readFile delays opening until the list is actually forced. Either way, goblins all round! Stuart From sebastian.sylvan at gmail.com Fri Nov 2 08:03:19 2007 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Nov 2 08:00:37 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? In-Reply-To: <1828188836.20071102113457@gmail.com> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <20071031160139.GA16836@scytale.galois.com> <4c69c1be0710311111j2d16d205p3d141deabf95786@mail.gmail.com> <20071031181628.GH17689@scytale.galois.com> <87lk9ipfwy.fsf@nmd9999.imr.no> <3d96ac180711011158q703dddddxa7e5c6faf27a7c69@mail.gmail.com> <1828188836.20071102113457@gmail.com> Message-ID: <3d96ac180711020503r6493064r25bda1498efbe47d@mail.gmail.com> On 02/11/2007, Bulat Ziganshin wrote: > Hello Sebastian, > > Thursday, November 1, 2007, 9:58:45 PM, you wrote: > > > the ideal. Token count would be good, but then we'd need a parser for > > each language, which is quite a bit of work to do... > > i think that wc (word count) would be good enough approximation > Yes, as long as you police abuse ( eg "if(somevar)somfunccall(foo,bar,baz)"shouldn't be treated as a single word)). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 From allbery at ece.cmu.edu Fri Nov 2 08:35:03 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Nov 2 08:32:32 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> <472A2EEA.1020205@yale.edu> Message-ID: On Nov 2, 2007, at 6:35 , apfelmus wrote: > during function evaluation. Then, we'd need a "purity lemma" that > states that any function not involving the type *World as in- and > output is indeed pure, which may be a bit tricky to prove in the > presence of higher-order functions and polymorphism. I mean, the > function arrows are "tagged" for side effects in a strange way, > namely by looking like *World -> ... -> (*World, ...). I don't quite see that; the Clean way looks rather suspiciously like my "unwrapped I/O in GHC" example from a couple weeks ago, so I have trouble seeing where any difficulty involving functions not using *World / RealWorld# creeps in. I will grant that hiding *World / RealWorld# inside IO is cleaner from a practical standpoint, though. Just not from a semantic one. -- 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 ketil+haskell at ii.uib.no Fri Nov 2 09:15:34 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Nov 2 09:12:53 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: <472B07CA.60301@cs.tcd.ie> (Andrew Butterfield's message of "Fri\, 02 Nov 2007 11\:19\:38 +0000") References: <472B07CA.60301@cs.tcd.ie> Message-ID: <87d4usokjt.fsf@nmd9999.imr.no> Andrew Butterfield writes: > I'm puzzled - when I run this on GHCi (v6.4, Windows XP) I get the > following outcome ^^^^^^^^^^ > The process cannot access the file because it is being used by another > process. Isnt' this a difference between Windows and Unix? Windows typically locks files, Unix typically does not. -k -- If I haven't seen further, it is by standing in the footprints of giants From jules at jellybean.co.uk Fri Nov 2 10:47:24 2007 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Nov 2 10:44:42 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: Message-ID: <472B387C.5010908@jellybean.co.uk> > Can you please give me some hint to solve this problem? > I'm a beginning haskell developer and I'm still a bit confused > by the IO monad. Other people have explained to the OP why unsafe lazy IO is breaking his code. Yet another piece of evidence, in my opinion, that unsafe-lazy-by-default is the wrong basic API. Provide that API as an option, sure. But as a default? Not IMO. Jules From apfelmus at quantentunnel.de Fri Nov 2 11:09:00 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Nov 2 11:06:36 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> <472A2EEA.1020205@yale.edu> Message-ID: Brandon S. Allbery KF8NH wrote: > apfelmus wrote: >> during function evaluation. Then, we'd need a "purity lemma" that >> states that any function not involving the type *World as in- and >> output is indeed pure, which may be a bit tricky to prove in the >> presence of higher-order functions and polymorphism. I mean, the >> function arrows are "tagged" for side effects in a strange way, namely >> by looking like *World -> ... -> (*World, ...). > > I don't quite see that; the Clean way looks rather suspiciously like my > "unwrapped I/O in GHC" example from a couple weeks ago, so I have > trouble seeing where any difficulty involving functions not using *World > / RealWorld# creeps in. > > I will grant that hiding *World / RealWorld# inside IO is cleaner from a > practical standpoint, though. Just not from a semantic one. What do you mean? I mean, in Clean, we may ask the following question: are all functions of type say forall a . Either (a -> *World -> a) String -> [*World] or Either (forall a . a -> *World -> a) String -> Maybe *World pure? In Haskell, the answer to any such question is unconditionally "yes" (unless you're hacking with unsafePerformIO and GHC internals like RealWorld# of course) even with plenty of appearances of the IO type constructor. But in Clean, functions may perform side effects, that's the only way to explain why the examples loop and loop' aren't the same. Regards, apfelmus From jonathanccast at fastmail.fm Fri Nov 2 11:51:32 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Nov 2 11:49:19 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> <472A2EEA.1020205@yale.edu> Message-ID: <1194018693.9500.122.camel@jcchost> On Fri, 2007-11-02 at 08:35 -0400, Brandon S. Allbery KF8NH wrote: > On Nov 2, 2007, at 6:35 , apfelmus wrote: > > > during function evaluation. Then, we'd need a "purity lemma" that > > states that any function not involving the type *World as in- and > > output is indeed pure, which may be a bit tricky to prove in the > > presence of higher-order functions and polymorphism. I mean, the > > function arrows are "tagged" for side effects in a strange way, > > namely by looking like *World -> ... -> (*World, ...). > > I don't quite see that; the Clean way looks rather suspiciously like > my "unwrapped I/O in GHC" example from a couple weeks ago, so I have > trouble seeing where any difficulty involving functions not using > *World / RealWorld# creeps in. > > I will grant that hiding *World / RealWorld# inside IO is cleaner > from a practical standpoint, though. Just not from a semantic one. On the contrary. GHC's IO newtype isn't an implementation of IO in Haskell at all. It's an implementation in a language that has a Haskell-compatible subset, but that also has semantically bad constructs like unsafePerformIO and unsafeInterleaveIO that give side effects to operations of pure, non-RealWorld#-involving types. Clean's type system is specified in a way that eliminates both functions from the language, which recovers purity. But proving that is harder than I'd like to attempt. jcc From allbery at ece.cmu.edu Fri Nov 2 11:56:30 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Nov 2 11:53:44 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: <1194018693.9500.122.camel@jcchost> References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> <472A2EEA.1020205@yale.edu> <1194018693.9500.122.camel@jcchost> Message-ID: On Nov 2, 2007, at 11:51 , Jonathan Cast wrote: >> I will grant that hiding *World / RealWorld# inside IO is cleaner >> from a practical standpoint, though. Just not from a semantic one. > > On the contrary. GHC's IO newtype isn't an implementation of IO in > Haskell at all. It's an implementation in a language that has a > Haskell-compatible subset, but that also has semantically bad > constructs Differing viewpoints, I guess; from my angle, Clean's "uniqueness constraint" looks like a hack hidden in the compiler. -- 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 jgbailey at gmail.com Fri Nov 2 12:56:32 2007 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Nov 2 12:53:49 2007 Subject: [Haskell-cafe] space leak? In-Reply-To: References: Message-ID: Massimiliano, I had to update your code for it to compile (removed "sequence" from testpdf'. However, I don't see any significant difference in the memory profile of either testpdf or testpdf'. Not sure how you are watching the memory usage, but if you didn't know the option "+RTS -sstderr" will print out useful memory statistics when you run your program. E.g.: > pdf_test.exe +RTS -sstderr gives: 2,157,524,764 bytes allocated in the heap 246,516,688 bytes copied during GC (scavenged) 6,086,688 bytes copied during GC (not scavenged) 45,107,704 bytes maximum residency (8 sample(s)) 4086 collections in generation 0 ( 0.61s) 8 collections in generation 1 ( 0.67s) 129 Mb total memory in use INIT time 0.02s ( 0.00s elapsed) MUT time 5.83s ( 7.48s elapsed) GC time 1.28s ( 1.45s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 7.13s ( 8.94s elapsed) %GC time 18.0% (16.3% elapsed) Alloc rate 369,202,098 bytes per MUT second Productivity 81.8% of total user, 65.2% of total elapsed Above you can see 45 MB was the max amount of memory ever in use - and according to the heap profiling I did it's about constant. I saw the same results when using "testpdf'". A few tricks I've learned to reduce space usage: * Use strict returns ( return $! ...) * foldl' over foldr unless you have to use foldr. * Profile, profile, profile - understand who is hanging on to the memory (+RTS -hc) and how it's being used (+RTS -hb). * Use +RTS -p to understand who's doing all the allocations and where your time is being spent. * Approach profiling like a science experiment - make one change, observe if anything is different, rollback and make another change - observer the change. Keep notes! Good luck! Justin From jonathanccast at fastmail.fm Fri Nov 2 13:37:06 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Nov 2 13:34:53 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: References: <404396ef0710310837v613acb1uf7b46f18e4e2d166@mail.gmail.com> <589EC5FC-A496-4E8D-A716-DA0DE6CE8030@cs.uu.nl> <28012bc60711010759v1b0bb734hb77fae9b9a43cc7a@mail.gmail.com> <472A2EEA.1020205@yale.edu> <1194018693.9500.122.camel@jcchost> Message-ID: <1194025026.9500.131.camel@jcchost> On Fri, 2007-11-02 at 11:56 -0400, Brandon S. Allbery KF8NH wrote: > On Nov 2, 2007, at 11:51 , Jonathan Cast wrote: > > >> I will grant that hiding *World / RealWorld# inside IO is cleaner > >> from a practical standpoint, though. Just not from a semantic one. > > > > On the contrary. GHC's IO newtype isn't an implementation of IO in > > Haskell at all. It's an implementation in a language that has a > > Haskell-compatible subset, but that also has semantically bad > > constructs > > Differing viewpoints, I guess; from my angle, Clean's "uniqueness > constraint" looks like a hack hidden in the compiler. Yeah. After all, the "uniqueness constraint" has a theory with an excellent pedigree (IIUC linear logic, whose proof theory Clean uses here, goes back at least to the 60s, and Wadler proposed linear types for IO before anybody had heard of monads). It's not some random hack somebody happened to notice would work, any more than existential types are. jcc From dons at galois.com Fri Nov 2 14:35:42 2007 From: dons at galois.com (Don Stewart) Date: Fri Nov 2 14:33:06 2007 Subject: [Haskell-cafe] using an external application In-Reply-To: References: <49b351060711020147w52a58e7et46465c5e0fdf5b5f@mail.gmail.com> Message-ID: <20071102183542.GE28596@scytale.galois.com> lemming: > > On Fri, 2 Nov 2007, Felipe Lessa wrote: > > > On 11/2/07, Stuart Cook wrote: > > > The solution would be to use a version of "readFile" that works in a > > > stricter way, by reading the file when it's told to, but I don't have > > > an implementation handy. > > > > I guess this does the job: > > > > > readFile' fp = do > > > contents <- readFile fp > > > let ret (x:xs) = x `seq` ret xs > > > ret [] = return contents > > > ret contents > > > > Maybe the "x `seq`" part isn't necessary at all. > > Awful. It reminds me on MatLab where the developers have implemented many > automatisms which do arbitrary clever things in every corner case, but > nothing consistent, because they thought programmers want it that way. > Then the programmers must write wrappers in order to get functions with > consistent behaviour around the fully automated functions. > > The "unlazying" procedure looks much like the "lazying" one, and I wonder > whether it would be a good idea to eventually add "readFileStrict", > "getContentStrict" and "hGetContentStrict" to the standard library. Yes, I have often thought System.IO.Strict should be added to the strict package on hackage, maybe in terms of bytestring.readFile >>= return . unpack, since we're being strict anyway. The above is also a rather odd implementation of readFile', which is usually implemented by forcing the last element of the list instead. -- Don From jeff.polakow at db.com Fri Nov 2 14:41:12 2007 From: jeff.polakow at db.com (Jeff Polakow) Date: Fri Nov 2 14:38:47 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: <1194025026.9500.131.camel@jcchost> Message-ID: Hello, Just a bit of minor academic nitpicking... > Yeah. After all, the "uniqueness constraint" has a theory with an > excellent pedigree (IIUC linear logic, whose proof theory Clean uses > here, goes back at least to the 60s, and Wadler proposed linear types > for IO before anybody had heard of monads). > Linear logic/typing does not quite capture uniqueness types since a term with a unique type can always be copied to become non-unique, but a linear type cannot become unrestricted. As a historical note, the first paper on linear logic was published by Girard in 1987; but the purely linear core of linear logic has (non-commutative) antecedents in a system introduced by Lambek in a 1958 paper titled "The Mathematics of Sentence Structure". -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071102/e11a7ba2/attachment-0001.htm From igouy2 at yahoo.com Fri Nov 2 15:03:10 2007 From: igouy2 at yahoo.com (Isaac Gouy) Date: Fri Nov 2 15:00:25 2007 Subject: [Haskell-cafe] Re: Why can't Haskell be faster? Message-ID: <381476.32317.qm@web60522.mail.yahoo.com> Ketil Malde wrote: > [LOC vs gz as a program complexity metric] Do either of those make sense as a "program /complexity/ metric"? Seems to me that's reading a lot more into those measurements than we should. It's slightly interesting that, while we're happily opining about LOCs and gz, no one has even tried to show that switching from LOCs to gz made a big difference in those "program bulk" rankings, or even provided a specific example that they feel shows how gz is misrepresentative - all opinion, no data. (Incidentally LOC measures source code "shape" as much as anything else - programs in statement heavy languages tend to be longer and thinner, and expression heavy languages tend to be shorter and wider.) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jonathanccast at fastmail.fm Fri Nov 2 15:13:09 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Nov 2 15:10:56 2007 Subject: [Haskell-cafe] Re: Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?) In-Reply-To: Refe