From vigalchin at gmail.com Fri Aug 1 01:08:05 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Aug 1 01:08:02 2008 Subject: [Haskell-cafe] an array of pointers in FFI? Message-ID: <5ae4f2ba0807312208n40d5948rdd44ce3b29abdd2c@mail.gmail.com> Hello, Is a (Ptr (Ptr a)) a polymorphic representation of an array of pointers of type "a"? I want to pass an array of pointers to a C function. Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080801/46d3f3f8/attachment.htm From vigalchin at gmail.com Fri Aug 1 01:52:41 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Aug 1 01:52:37 2008 Subject: [Haskell-cafe] category theory tutorial pdfs ..... Message-ID: <5ae4f2ba0807312252y57e4cf88id0aa4cc924abdaed@mail.gmail.com> Hello, Prof. Harold Simmons' tutorial IMO are like a Russian matroshka doll ... first layer is for newbie ... inner layers require more sophistication. IMO a very subtle writer ... I have every book imaginable on cat theory and topos theory so I think can compare a little. 1) http://www.cs.man.ac.uk/~hsimmons/BOOKS/books.html ... an earlier version ... "An Intro to Category Theory in Four Easy Movements" ... this version delves a little into Topos Theory ... pretty subtle .. cool 2) http://www.cs.man.ac.uk/~hsimmons/MAGIC-CATS/magic-cats.html ... newer version which also has its cool merits IMO! Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080801/0778db7e/attachment.htm From bulat.ziganshin at gmail.com Fri Aug 1 01:53:45 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Aug 1 01:56:03 2008 Subject: [Haskell-cafe] an array of pointers in FFI? In-Reply-To: <5ae4f2ba0807312208n40d5948rdd44ce3b29abdd2c@mail.gmail.com> References: <5ae4f2ba0807312208n40d5948rdd44ce3b29abdd2c@mail.gmail.com> Message-ID: <785041483.20080801095345@gmail.com> Hello Vasili, Friday, August 1, 2008, 9:08:05 AM, you wrote: > ???? Is a (Ptr (Ptr a)) a polymorphic representation of an array of > pointers of type "a"? I want to pass an array of pointers to a C function. use Ptr (Ptr ()) Ptr () in haskell is like void* in C, it's used to represent pointer to arbitrary type. you can use castPtr to cast pointers between different types -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From vigalchin at gmail.com Fri Aug 1 01:59:06 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Aug 1 01:59:03 2008 Subject: [Haskell-cafe] an array of pointers in FFI? In-Reply-To: <785041483.20080801095345@gmail.com> References: <5ae4f2ba0807312208n40d5948rdd44ce3b29abdd2c@mail.gmail.com> <785041483.20080801095345@gmail.com> Message-ID: <5ae4f2ba0807312259r140805fcv720f6dfc474786b1@mail.gmail.com> Thanks Bulat! So since we are "talking" ;^) .... is there a function already in Foreign that will allow me to ... [a] -> Ptr (Ptr ()) i.e. map a list of type "a" to an array of ptrs of type "a"? Kind regards, Vasili On Fri, Aug 1, 2008 at 12:53 AM, Bulat Ziganshin wrote: > Hello Vasili, > > Friday, August 1, 2008, 9:08:05 AM, you wrote: > > > Is a (Ptr (Ptr a)) a polymorphic representation of an array of > > pointers of type "a"? I want to pass an array of pointers to a C > function. > > use Ptr (Ptr ()) > > Ptr () in haskell is like void* in C, it's used to represent pointer > to arbitrary type. you can use castPtr to cast pointers between different > types > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080801/07ca5325/attachment.htm From scook0 at gmail.com Fri Aug 1 04:25:06 2008 From: scook0 at gmail.com (Stuart Cook) Date: Fri Aug 1 04:25:03 2008 Subject: [Haskell-cafe] an array of pointers in FFI? In-Reply-To: <5ae4f2ba0807312259r140805fcv720f6dfc474786b1@mail.gmail.com> References: <5ae4f2ba0807312208n40d5948rdd44ce3b29abdd2c@mail.gmail.com> <785041483.20080801095345@gmail.com> <5ae4f2ba0807312259r140805fcv720f6dfc474786b1@mail.gmail.com> Message-ID: <49b351060808010125p63950882l1208c8aeb09100f0@mail.gmail.com> 2008/8/1 Galchin, Vasili : > Thanks Bulat! So since we are "talking" ;^) .... is there a function already > in Foreign that will allow me to ... > > [a] -> Ptr (Ptr ()) i.e. map a list of type "a" to an array of ptrs of type > "a"? I think this is going to be a two-part operation: first you'll need to store those values somewhere, so that you can produce pointers to them. Then, you create a (foreign) array and fill it with the pointers you got from step one. Of course, you'll need to manage memory for the two stages separately, ensuring that the pointers don't outlive the things they point to, and that both memory regions are freed when no longer needed. For example, if you have a list (xs :: [Int]), you can probably achieve the first step using (mapM new xs),* which should give you a list (ps:: [Ptr Int]). Then, you can do (newArray ps), which will allocate an array and store the pointers in it, giving you a pointer of type (Ptr (Ptr Int)). Once you're done, use (free) to clean up the array of pointers, and also each of the individual elements of (ps). If you only need the pointer array in a particular scope, you should be able to make your life a bit easier using the (alloca) or (with) family of functions. * This is probably a bit wasteful, since it makes a separate allocation for each element, but it does make life easier. Hope this helps. Stuart From chaddai.fouche at gmail.com Fri Aug 1 04:48:21 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Fri Aug 1 04:48:18 2008 Subject: [Haskell-cafe] a really dumb posting question ;^( In-Reply-To: <5ae4f2ba0807302145j13a92fc4v18d6c76e9596444a@mail.gmail.com> References: <5ae4f2ba0807302145j13a92fc4v18d6c76e9596444a@mail.gmail.com> Message-ID: 2008/7/31 Galchin, Vasili : > Hello, > > What do I do to do a followup haskell cafe posting? E.g. I want to put a > posting on the category theory thread! You respond to it. Sometimes it is not sufficient (haskell-cafe@haskell.org isn't in the to or cc field), then you probably have a "respond to all" action in your mailer, you should use it. The best way is to use "respond to list" if you have it but "respond to all" should work properly. -- Jeda? From DekuDekuplex at Yahoo.com Fri Aug 1 08:44:08 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Fri Aug 1 08:44:11 2008 Subject: [Haskell-cafe] Re: category theory tutorial pdfs ..... References: <5ae4f2ba0807312252y57e4cf88id0aa4cc924abdaed@mail.gmail.com> Message-ID: On Fri, 1 Aug 2008 00:52:41 -0500, "Galchin, Vasili" wrote: >Hello, > > Prof. Harold Simmons' tutorial IMO are like a Russian matroshka doll ... >first layer is for newbie ... inner layers require more sophistication. IMO >a very subtle writer ... I have every book imaginable on cat theory and >topos theory so I think can compare a little. > > 1) http://www.cs.man.ac.uk/~hsimmons/BOOKS/books.html ... an earlier >version ... "An Intro to Category Theory in Four Easy Movements" ... this >version delves a little into Topos Theory ... pretty subtle .. cool I have started reading _An introduction to category theory in four easy movements_ (see http://www.cs.man.ac.uk/~hsimmons/BOOKS/CatTheory.pdf). The author's style is very strange; in the first section, he states that he highlights "subsidiary notions" to be defined later in small caps, and even uses some of these in his exercises. For example, he highlights and uses "preset" and "monoid" as part of Exercise 1.1 before defining them, so I then need to hunt around in the vicinity for definitions (available several pages later). However, the PDF file is not text-searchable, so I need to hunt manually through the vicinity of pages to find a definition. This makes the book more interesting, at the expense of being harder to use. Do you know of a text-searchable version of this file? He also has a rather peculiar sense of humor. For instance, on page 6, he writes (regarding that in the original examples of categories, "the arrows were morphisms which were then called homomorphism, and it wasn't realized that this family could be very large"), > (Some out and out category theorists still don't realize the significance of this. > On the other hand, some off the wall set theorists don't realize the significance > of category theory.) This reminds me of a lecture by David Gelernter in 1992 in a survey course on cognitive science at Yale in which he said that some weak AI cognitive scientists had said that other strong AI cognitive scientists must have been "out to lunch." Again, if you know of a text-searchable version of this book, please post the reference in this thread. -- Benjamin L. Russell From duncan.coutts at worc.ox.ac.uk Fri Aug 1 09:39:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 1 09:39:52 2008 Subject: [Haskell-cafe] Cabal files on Windows In-Reply-To: <9979e72e0807271901h337738b2iefb751f24ef7a987@mail.gmail.com> References: <9979e72e0807261823h2eb0dcefk82ed2174737ff212@mail.gmail.com> <1217190323.12754.252.camel@localhost> <9979e72e0807271901h337738b2iefb751f24ef7a987@mail.gmail.com> Message-ID: <1217597991.7661.15.camel@localhost> On Sun, 2008-07-27 at 21:01 -0500, John Lato wrote: > > Use Haskell String syntax for paths that contain spaces: > > > > include-dirs: "C:\\Program Files\\program\\include" > > Hi Duncan, > > Thanks, this worked (mostly). Although I had to change the line to > > include-dirs: "\"C:\\Program Files\\program\\include\"" > > so that the path would be passed properly to cpp through c2hs. Thanks for for filing the ticket John. http://hackage.haskell.org/trac/hackage/ticket/316#comment:1 Turns out Cabal is doing it right and it's c2hs that we need to fix. Shouldn't be too hard. Just need to change the way c2hs invokes cpp in Main.hs: let cmd = unwords [cpp, cppOpts, newHeaderFile, ">" ++ preprocFile] tracePreproc cmd exitCode <- liftIO $ system cmd to something like: let args = ?cppOpts ++ [?newHeaderFile] ?tracePreproc (unwords (cmd : args)) ?exitCode <- liftIO $ do ?preprocHnd <- openFile WriteMode? preprocFile ?process <- runProcess cpp args Nothing ?Nothing Nothing ?(Just ?preprocHnd) ?Nothing waitForProcess process Try that, tell me if it works and we can add the patch to the c2hs repo. Duncan From robert.daprile at gmail.com Fri Aug 1 10:01:33 2008 From: robert.daprile at gmail.com (Roberto D'Aprile) Date: Fri Aug 1 10:01:30 2008 Subject: [Haskell-cafe] Analysing Haskell Program Message-ID: Hello to everybody I'm using haskell for some research work and now i need to evaluate the performance of some simple haskell programs in particular information on the like, CPU cycles, bus usage, memory access and so on; so i wish to know if there is a way to compile haskell programms so they can be used with simplescalar or if there is another tool which i can use. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080801/c52e9fba/attachment.htm From tom.davie at gmail.com Fri Aug 1 10:50:49 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Fri Aug 1 10:51:03 2008 Subject: [Haskell-cafe] Analysing Haskell Program In-Reply-To: References: Message-ID: <92B759D5-768C-4307-87DA-CB314D46FBC2@gmail.com> On 1 Aug 2008, at 16:01, Roberto D'Aprile wrote: > Hello to everybody > > I'm using haskell for some research work and now i need to evaluate > the performance of some simple haskell programs in particular > information on the like, CPU cycles, bus usage, memory access and > so on; so i wish to know if there is a way to compile haskell > programms so they can be used with simplescalar or if there is > another tool which i can use. I've been getting some useful information by compiling with -fvia-C and then using dtrace to look at what's going on. Bob From eric.kow at gmail.com Fri Aug 1 11:45:17 2008 From: eric.kow at gmail.com (Eric Kow) Date: Fri Aug 1 11:45:12 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? Message-ID: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Dear Haskellers, I would like to take an informal poll for the purposes of darcs recruitment. Could you please complete this sentence for me? "I would contribute to darcs if only..." The answers I am most interested in hearing go beyond "... I had more time". For instance, if you are contributing to other Haskell/volunteer projects, why are you contributing more to them, rather than darcs? The context: Lately, darcs has suffered a setback: the GHC team has decided that it is now time to switch to a different system, like git or Mercurial. This is probably a good thing for GHC and for us. By the way, good luck to them, and thanks for everything! (better GHC == better darcs) But where is darcs going? For now, we are going to have to focus on what we do best, providing precision merging and a consistent user interface for small-to-medium sized projects. I want more, though! I want to see darcs 2.1 come out next year, performance enhanced out the wazoo, and running great on Windows. And I want to see Future Darcs, the universal revision control system, seamlessly integrating with everybody else. We need to learn to do better so that darcs can achieve this kind of wild success. For example, whereas darcs suffers from the "day job" problem, xmonad has had to turn developers away! As Don mentions, this is partly thanks to their extreme accessibility (better self-documentation). But does anyone have more specific ideas about things we need to change so that you can contribute to darcs? How do we hit critical hacker mass? I have jotted down some other thoughts here regarding recruitment here: http://wiki.darcs.net/index.html/Recruitment In the meantime, if you have been discouraged from hacking on darcs, we want to know why, and how we can change things! Thanks, From a.d.clark at ed.ac.uk Fri Aug 1 11:57:32 2008 From: a.d.clark at ed.ac.uk (allan) Date: Fri Aug 1 11:55:58 2008 Subject: [Haskell-cafe] Re: [darcs-users] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <4893326C.6070202@ed.ac.uk> I would contribute to darcs if only It didn't already do exactly what I want it to. As you've said darcs is really good for small-to-medium sized projects, particularly with few developers. Those are exactly the projects I happen to be working on. For my work I use darcs on a slightly larger project but with (mainly) only one developer (me). So basically because darcs works perfectly for me I have pretty little motivation to dive into the source code and 'fix' something which for me simply isn't broken. regards allan Eric Kow wrote: > Dear Haskellers, > > I would like to take an informal poll for the purposes of darcs > recruitment. Could you please complete this sentence for me? > > "I would contribute to darcs if only..." > > The answers I am most interested in hearing go beyond "... I had more > time". For instance, if you are contributing to other Haskell/volunteer > projects, why are you contributing more to them, rather than darcs? > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From pjdtech2000 at gmail.com Fri Aug 1 14:09:30 2008 From: pjdtech2000 at gmail.com (PJ Durai) Date: Fri Aug 1 14:09:25 2008 Subject: [Haskell-cafe] HDBC-ODBC linking problems in windows. Message-ID: <4f712c6f0808011109p3c6f2358nbb91b1c552d4cf72@mail.gmail.com> Greetings everyone, I am having issues getting hdbc/odbc working on windows. When using GHC, I am not able to compile a simple program. It ends up with linker errors like C:\Program Files\Haskell\HDBC-odbc-1.1.4.3\ghc-6.8.3/libHSHDBC-odbc-1.1.4.3.a(Connection.o)(.text+0x52c):fake: undefined reference to `SQLAllocHandle' C:\Program Files\Haskell\HDBC-odbc-1.1.4.3\ghc-6.8.3/libHSHDBC-odbc-1.1.4.3.a(Connection.o)(.text+0x5b8):fake: undefined reference to `SQLSetEnvAttr' C:\Program Files\Haskell\HDBC-odbc-1.1.4.3\ghc-6.8.3/libHSHDBC-odbc-1.1.4.3.a(Connection.o)(.text+0x62c):fake: undefined reference to `SQLDriverConnect' C:\Program Files\Haskell\HDBC-odbc-1.1.4.3\ghc-6.8.3/libHSHDBC-odbc-1.1.4.3.a(Connection.o)(.text+0x700):fake: undefined reference to `SQLEndTran' C:\Program Files\Haskell\HDBC-odbc-1.1.4.3\ghc-6.8.3/libHSHDBC-odbc-1.1.4.3.a(Connection.o)(.text+0x770):fake: undefined reference to `SQLGetInfo' C:\Program Files\Haskell\HDBC-odbc-1 When I use ghci, it exits silently. It looks like calling convension mix-up in FFI declarations to me. I ran 'dumpbin' on odbc32.lib and all the exported function names are decorated like they are PASCAL calls, not ccall's. But GHC in this case is looking for undecorated names. I assume it works as is on Unix (unixODBC) ? Is there an easy workaround for this? Or am I doing something wrong? MySetup ======= Windows XP SP2 ghc 6.8.3 hdbc 1.1.5.0 hdbc-odbc 1.1.4.3.0 appreciate your time. Thanks pj From dav.vire+haskell at gmail.com Fri Aug 1 15:02:57 2008 From: dav.vire+haskell at gmail.com (david48) Date: Fri Aug 1 15:02:52 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <4c88418c0808011202u56c47b66rb643721e4bf068aa@mail.gmail.com> I'd love to see a git-gui like interface to darcs. From allbery at ece.cmu.edu Fri Aug 1 15:43:42 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Aug 1 15:43:37 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: On 2008 Aug 1, at 11:45, Eric Kow wrote: > Dear Haskellers, > > I would like to take an informal poll for the purposes of darcs > recruitment. Could you please complete this sentence for me? > > "I would contribute to darcs if only..." The darcs2 announcement strongly suggested that darcs would no longer be developed. This was brought up in the #ghc discussion about whether to switch. -- 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 Aug 1 16:44:29 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Aug 1 16:44:24 2008 Subject: [Haskell-cafe] HDBC-ODBC linking problems in windows. In-Reply-To: <4f712c6f0808011109p3c6f2358nbb91b1c552d4cf72@mail.gmail.com> References: <4f712c6f0808011109p3c6f2358nbb91b1c552d4cf72@mail.gmail.com> Message-ID: On Fri, Aug 1, 2008 at 11:09 AM, PJ Durai wrote: > Greetings everyone, > > I am having issues getting hdbc/odbc working on windows. > > When using GHC, I am not able to compile a simple program. It ends up > with linker errors like I had similar issues buidling hdbc-postgres. I wrote up my experiences on their wiki - maybe it will help you. http://software.complete.org/software/wiki/16/WindowsInstall Justin From wren at freegeek.org Fri Aug 1 16:56:02 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Aug 1 16:55:59 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <48937862.5060500@freegeek.org> Eric Kow wrote: > Dear Haskellers, > > I would like to take an informal poll for the purposes of darcs > recruitment. Could you please complete this sentence for me? > > "I would contribute to darcs if only..." > > The answers I am most interested in hearing go beyond "... I had more > time". For instance, if you are contributing to other Haskell/volunteer > projects, why are you contributing more to them, rather than darcs? ...I knew how to help (and had the time). The You Too Can Hack on Darcs blog series is a really good idea. One problem many open-source projects suffer from is it not being apparent how a new hacker would even begin to start working. An overview of how the project is set up along with some notice about how malleable the different parts are goes a long way. It can also be helpful to take some RFI and walk through implementing the change, testing that it hasn't broken anything, and sending the patch (don't forget this step :). A follow on about getting ideas from the bug tracker is also good. Sometimes hands-on documentation is the best kind. Also documenting how a ninja developer could drop in, fix some things, and leave before anyone noticed is a good way to snare the folks who'd like to help a little but don't want to get dragged into being a regular developer (yet). Try-before-you-buy contributing is one of the best ways to get regular developers. ...I knew you needed help (and had the time). This is an image thing, but until the recent announcement of dayjob syndrome I was under the impression that darcs was rumbling along just fine. The wiki has a developers' FAQ and all, but the overall image is that darcs is stable and doing fine (and in my experience it is). Part of the reason I haven't contributed was that I've never thought about it-- and that's the problem. Silly as it sounds, even people who work on open-source code all the time don't always think about whether a project they use every day could use their support. And if it works just fine, they don't even have the impetus of wanting to fix it. I think it'd be good if the YTCHoD blog were more long lived than just something to gain developers now. A community blog for everyone hacking on darcs might help to demonstrate: (a) that there's a community of humans behind the software, [This is another thing that, silly as it sounds, people often forget about. For a humorous but all too true discussion of why, cf .] (b) that they're nice folks who'd welcome new developers, [In the corporate world people will take a job for the money, but they stay (or leave) for the people. In open-source they may come for the code, but it's the community that keeps them around (or scares them off).] (c) and that there are specific tractable problems they have that non-developers could help with. [Bug trackers are an excellent source of tasks for active developers to use so things don't get lost, but they're awful for new developers. For someone just joining the project it's rarely clear how important a task is, how hard, or how far reaching its consequences (or whether someone's already working on it). Good trackers have fields to note these things, but the notes are engineered for active developers; the extent to which those notes are even used or accurate varies wildly from project to project. Hence, having a clear discussion about what things really are important and how much they interact with everything else is a great boon.] -- Live well, ~wren From ndmitchell at gmail.com Fri Aug 1 18:54:27 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Aug 1 18:54:24 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> Hi >> "I would contribute to darcs if only..." > The darcs2 announcement strongly suggested that darcs would no longer be > developed. This was brought up in the #ghc discussion about whether to > switch. I agree strongly with this. I would be much more likely to contribute if the project seemed active and alive. The darcs 2.0 announcement read like an obituary, and that put me off. The impression I came away with (accurate or not), was that the entire program had been rewritten, I was going to gain incompatibilities, and be using an untried/tested version which was not going to get any support. The message also seemed to be threatening me that if I didn't upgrade you would break into my house and wipe my data - instead of the usual enticement with cool new features :-) [Of course, a few emails/blog comments/interactions with Eric has shown me there is some life in the project - but I think a lot of people get jumpy when it comes to version control software] One thing that might help is splitting bits of darcs into libraries. There have been various things in darcs which are now separate libraries - ByteString and FilePath both have/had parallels in darcs. By making a separate library you get a better documented interface, a cleaner separation of concerns, and people can contribute small patches to self-contained elements, rather than a big application. You also provide additional benefits to the general community :-) Thanks Neil From ttuegel at gmail.com Fri Aug 1 18:52:57 2008 From: ttuegel at gmail.com (Thomas Tuegel) Date: Fri Aug 1 18:54:59 2008 Subject: [Haskell-cafe] Re: Analysing Haskell Program References: <92B759D5-768C-4307-87DA-CB314D46FBC2@gmail.com> Message-ID: Thomas Davie gmail.com> writes: > On 1 Aug 2008, at 16:01, Roberto D'Aprile wrote: > > > Hello to everybody > > > > I'm using haskell for some research work and now i need to evaluate > > the performance of some simple haskell programs in particular > > information on the like, CPU cycles, bus usage, memory access and > > so on; so i wish to know if there is a way to compile haskell > > programms so they can be used with simplescalar or if there is > > another tool which i can use. > > I've been getting some useful information by compiling with -fvia-C > and then using dtrace to look at what's going on. I've been using the basic profiling features built into GHC for profiling. There are more details in the documentation, but basically you can build a binary with profiling support with the options "-prof -auto-all" to GHC. Then, there are some RTS options at runtime that control the profiling output. I often use "+RTS -p -hc -sstderr". These options produce, respectively, a 1) a profile of time spent in and memory used by each function call, 2) a graph of when in time memory was allocated and 3) basic garbage collecting statistics, including how much time was "wasted" on garbage collection overall. I realize these options don't produce very detailed output, but I find they give a pretty good overview of what's going on. I believe there are also more detailed output options documented in the GHC user manual. From jwlato at gmail.com Fri Aug 1 18:59:31 2008 From: jwlato at gmail.com (John Lato) Date: Fri Aug 1 18:59:25 2008 Subject: [Haskell-cafe] Cabal files on Windows In-Reply-To: <1217597991.7661.15.camel@localhost> References: <9979e72e0807261823h2eb0dcefk82ed2174737ff212@mail.gmail.com> <1217190323.12754.252.camel@localhost> <9979e72e0807271901h337738b2iefb751f24ef7a987@mail.gmail.com> <1217597991.7661.15.camel@localhost> Message-ID: <9979e72e0808011559w43480d49k1147c688e6d5842a@mail.gmail.com> On Fri, Aug 1, 2008 at 8:39 AM, Duncan Coutts wrote: > On Sun, 2008-07-27 at 21:01 -0500, John Lato wrote: > >> > Use Haskell String syntax for paths that contain spaces: >> > >> > include-dirs: "C:\\Program Files\\program\\include" >> >> Hi Duncan, >> >> Thanks, this worked (mostly). Although I had to change the line to >> >> include-dirs: "\"C:\\Program Files\\program\\include\"" >> >> so that the path would be passed properly to cpp through c2hs. > > Thanks for for filing the ticket John. > > http://hackage.haskell.org/trac/hackage/ticket/316#comment:1 > > Turns out Cabal is doing it right and it's c2hs that we need to fix. > Shouldn't be too hard. Just need to change the way c2hs invokes cpp in > Main.hs: > > let cmd = unwords [cpp, cppOpts, newHeaderFile, ">" ++ preprocFile] > tracePreproc cmd > exitCode <- liftIO $ system cmd > > to something like: > > let args = ?cppOpts ++ [?newHeaderFile] > ?tracePreproc (unwords (cmd : args)) > ?exitCode <- liftIO $ do > ?preprocHnd <- openFile WriteMode? preprocFile > ?process <- runProcess cpp args > Nothing ?Nothing > Nothing ?(Just ?preprocHnd) ?Nothing > waitForProcess process > > Try that, tell me if it works and we can add the patch to the c2hs repo. > I got some compilation errors with this patch. After I changed the top two lines as follows: let args = [cppOpts, newHeaderFile] --cppOpts :: String, not [String] tracePreproc (unwords (cpp:args)) --I think you meant cpp instead of cmd here c2hs builds, but I think you can see the problem already. cppOpts needs to be a list of arguments, rather than one string, to use it with runProcess. Now running c2hs yields a cpp error about an invalid argument, specifically "-x c -IC:\\Program Files\include". I've added a ticket to trac (#11) for this, and included a patch to fix the problem. Thanks, John From vigalchin at gmail.com Sat Aug 2 02:37:53 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Aug 2 02:37:46 2008 Subject: [Haskell-cafe] question about "faulting in" Haskell packages ... Message-ID: <5ae4f2ba0808012337j83564ednaf80f1b3a85a7d96@mail.gmail.com> Hello, Sorry I asked this question before .. say I want to install package A that depends on package B, C, D but maybe B and D are not installed on my machine. Basically I want to "fault in" (i.e. install automatically) in B and D with "no fuss no muss". ??? In reality I would like to get my laptop which is running Ubuntu totally "faulted up" with all Haskell packages ... ;^) Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080802/4eb75671/attachment.htm From dav.vire+haskell at gmail.com Sat Aug 2 02:52:09 2008 From: dav.vire+haskell at gmail.com (david48) Date: Sat Aug 2 02:52:04 2008 Subject: [Haskell-cafe] question about "faulting in" Haskell packages ... In-Reply-To: <4c88418c0808012344t78780285n61b7acbed123a8b@mail.gmail.com> References: <5ae4f2ba0808012337j83564ednaf80f1b3a85a7d96@mail.gmail.com> <4c88418c0808012344t78780285n61b7acbed123a8b@mail.gmail.com> Message-ID: <4c88418c0808012352h210ff054i7c9fd1ff24580eff@mail.gmail.com> You need to get cabal-install. Here's how I got it working on kubuntu : 1) install GHC 6.8.3 from haskell.org's binaries (kubuntu hardy isn't at 6.8.3 yet....) 2) download from hackage : * cabal-install-0.5.1.tar.gz from hackage * HTTP-3001.0.4.tar.gz * zlib-0.4.0.4.tar.gz * Cabal-1.4.0.1.tar.gz 3) build and install http, zlib, Cabal and then cabal-install for each package you have to type (*) : runhaskell Setup.hs configure runhaskell Setup.hs build sudo runhaskell Setup.hs install (*) sometimes it'll be Setup.lhs, I'm annoyed that it's not always the same name, can't rely on shell history :( 4) once cabal-install is installed you can do cabal update sudo cabal upgrade --global that'll upgrade all your ghc's packages. 5) from now if you want to install package a just type cabal install a --global cabal should download packages b,c,d for you if required. P.S. Sorry for the previous email, it got sent before I finished it :) From vigalchin at gmail.com Sat Aug 2 03:23:23 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Aug 2 03:23:18 2008 Subject: [Haskell-cafe] question about "faulting in" Haskell packages ... In-Reply-To: <4c88418c0808012352h210ff054i7c9fd1ff24580eff@mail.gmail.com> References: <5ae4f2ba0808012337j83564ednaf80f1b3a85a7d96@mail.gmail.com> <4c88418c0808012344t78780285n61b7acbed123a8b@mail.gmail.com> <4c88418c0808012352h210ff054i7c9fd1ff24580eff@mail.gmail.com> Message-ID: <5ae4f2ba0808020023v4c757759xee84bb1211b8fb05@mail.gmail.com> cool david .... 1) I have to upgrade to ghc 6.8.3 2) I "may/probably will have more" questions very kind thanks, vasili On Sat, Aug 2, 2008 at 1:52 AM, david48 > wrote: > You need to get cabal-install. > Here's how I got it working on kubuntu : > > 1) install GHC 6.8.3 from haskell.org's binaries (kubuntu hardy isn't > at 6.8.3 yet....) > 2) download from hackage : > * cabal-install-0.5.1.tar.gz from hackage > * HTTP-3001.0.4.tar.gz > * zlib-0.4.0.4.tar.gz > * Cabal-1.4.0.1.tar.gz > > 3) build and install http, zlib, Cabal and then cabal-install > > for each package you have to type (*) : > > runhaskell Setup.hs configure > runhaskell Setup.hs build > sudo runhaskell Setup.hs install > > (*) sometimes it'll be Setup.lhs, I'm annoyed that it's not always the > same name, can't rely on shell history :( > > 4) once cabal-install is installed you can do > > cabal update > sudo cabal upgrade --global > > that'll upgrade all your ghc's packages. > > 5) from now if you want to install package a just type > > cabal install a --global > > cabal should download packages b,c,d for you if required. > > > > P.S. Sorry for the previous email, it got sent before I finished it :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080802/450ff328/attachment.htm From iavor.diatchki at gmail.com Sat Aug 2 04:03:33 2008 From: iavor.diatchki at gmail.com (iavor.diatchki@gmail.com) Date: Sat Aug 2 04:03:26 2008 Subject: [Haskell-cafe] Using fundeps to resolve polymorphic types to concrete types In-Reply-To: <20080729013258.GA19607@shion.is.fushizen.net> References: <20080729013258.GA19607@shion.is.fushizen.net> Message-ID: <5ab17e790808020103m13e039blba29ae5a2e602447@mail.gmail.com> Hi, On 7/29/08, Bryan Donlan wrote: > Hi, > > Is there any theoretical reason that functional dependencies can't be used > to resolve a polymorphic type to a concrete type? For example: > >> -- compile with -fglasgow-exts >> >> class DeriveType a b | a -> b >> >> data A = A >> data B = B >> >> instance DeriveType A B >> > >> simpleNarrow :: DeriveType A b => b -> B >> simpleNarrow = id > > Since 'b' is uniquely determined by the fundep in DeriveType, it seems that > this ought to work; ie, since the only type equation satisfying DeriveType A > b > is B -> B, it should reduce to that before trying to fit its type against > its > body. According to the theory of functional dependencies this function should type check but there is a bug in the current implementation (or you may view it as an incompleteness---the compiler is not smart enough to infer that "b" in this case is really "B" while checking the signature). Iavor From nominolo at googlemail.com Sat Aug 2 04:12:21 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Aug 2 04:12:41 2008 Subject: [Haskell-cafe] How can I get the mutable array out of an IOUArray for FFI use? In-Reply-To: <2f9b2d30807290022s4a588512x2cd772cfd9ebaac7@mail.gmail.com> References: <2f9b2d30807290022s4a588512x2cd772cfd9ebaac7@mail.gmail.com> Message-ID: <1DA0A2FB-EB45-4BB8-BD68-A68B66FE257C@googlemail.com> Maybe you can rewrite your code using the functions from this module: http://haskell.org/ghc/docs/latest/html/libraries/array/Data-Array- Storable.html On 29 Jul 2008, at 09:22, Ryan Ingram wrote: > I wrote some fast bit-twiddling functions in C because my Haskell > performance wasn't good enough. Now I'm trying to recompile with > GHC6.8.3 and failing. This code worked on GHC6.6.1. > > I get the following error: > >> ghc --make main.hs > > Bitmap.hs:11:7: > Could not find module `Data.Array.IO.Internals': > it is hidden (in package array-0.1.0.0) > > I suppose I can declare a copy of the internal type and use > unsafeCoerce#, but that seems like a terrible idea if there is a > better way. What's the right way to make this work? Can I force that > module to be unhidden? Should I file a GHC bug? > > -- ryan > > {-# OPTIONS_GHC -fffi -fglasgow-exts #-} > {-# INCLUDE "bitmap_operations.h" #-} > > module Bitmap ( > clearBitmap, > ) where > import Foreign.Ptr > import Data.Array.Base > import Data.Array.IO.Internals > import GHC.Exts > import Data.Word > > foreign import ccall unsafe clear_bitmap :: MutableByteArray# > RealWorld -> Word32 -> Word32 -> IO () > > {-# INLINE unsafeGetMutableArray# #-} > unsafeGetMutableArray# :: IOUArray Int Word32 -> MutableByteArray# > RealWorld > unsafeGetMutableArray# (IOUArray (STUArray _ _ array#)) = array# > > clearBitmap :: IOUArray Int Word32 -> Word32 -> Word32 -> IO () > clearBitmap a1 color size > = clear_bitmap (unsafeGetMutableArray# a1) color size > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe / Thomas -- Monkey killing monkey killing monkey over pieces of the ground. Silly monkeys give them thumbs they forge a blade And where there's one they're bound to divide it Right in two -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080802/ba79f4ea/PGP.bin From niklas.broberg at gmail.com Sat Aug 2 15:46:34 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Aug 2 15:46:25 2008 Subject: [Haskell-cafe] question about "faulting in" Haskell packages ... In-Reply-To: <4c88418c0808012352h210ff054i7c9fd1ff24580eff@mail.gmail.com> References: <5ae4f2ba0808012337j83564ednaf80f1b3a85a7d96@mail.gmail.com> <4c88418c0808012344t78780285n61b7acbed123a8b@mail.gmail.com> <4c88418c0808012352h210ff054i7c9fd1ff24580eff@mail.gmail.com> Message-ID: > for each package you have to type (*) : > > runhaskell Setup.hs configure > runhaskell Setup.hs build > sudo runhaskell Setup.hs install > > (*) sometimes it'll be Setup.lhs, I'm annoyed that it's not always the > same name, can't rely on shell history :( That's why you should always write e.g. 'runhaskell Setup configure', since runhaskell is clever enough to figure out the suffix for you. :-) Cheers, /Niklas From almeidaraf at gmail.com Sat Aug 2 21:10:36 2008 From: almeidaraf at gmail.com (Rafael C. de Almeida) Date: Sat Aug 2 21:10:32 2008 Subject: [Haskell-cafe] Web processing Message-ID: <4895058C.3000002@gmail.com> Hello, I understand that nowadays there are several frameworks and wrapper libraries for making some sense of the XHTML documents you find over the web. That is, making the life of those who want to process the semi-structured data you find on the sites. I don't have much experience on that field myself, but I want to learn a little more about how I can, for instance, associate information from one site with information in another site. Even though it is structured differently in both places. Does anyone know about libraries that would help me out with that sort of work? Hope I'm being clear. []'s Rafael From jason.dusek at gmail.com Sat Aug 2 21:22:50 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Aug 2 21:22:41 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal Message-ID: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> I'm trying to figure out the adjunction diagrams for the adjunction where the diagonal functor is right adjoint to the coproduct functor. I'm |almost done|, but the co-unit has me stumped, because I can't figure out how the arrow at the top can be unique -- it seems it could be either one of: i_1 . [f,g] i_2 . [f,g] i_1, i_2 : C -> C+C f : A -> C g : B -> C The net effect of [id,id] on the right is to blur out the distinction. On #haskell, someone suggested there is a constraint I am missing; I've poked around for a day and still can't figure it out. -- _jsn |almost done| http://hpaste.org/9303 From jason.dusek at gmail.com Sat Aug 2 21:26:48 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Aug 2 21:26:38 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <42784f260808021826q7b79951fkde63b5b46ce798f4@mail.gmail.com> Eric Kow wrote: > "I would contribute to darcs if only..." ...there were interest in binary file handling. -- _jsn From ben.franksen at online.de Sat Aug 2 21:35:13 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sat Aug 2 21:35:18 2008 Subject: [Haskell-cafe] Re: Cabal + yi + alex problem. References: <20080730073405.GA19682@kierun.org> <1217407476-sup-5296@existential.local> <20080730085935.GA19968@kierun.org> <1217408744-sup-6870@port-ext16.ensta.fr> <20080730185826.GA10438@colquitt.org> <1217452516-sup-5176@existential.local> Message-ID: Austin Seipp wrote: >> For that matter, "ghc-pkg list | grep -i alex" doesn't list anything, >> after I cabal-installed it. How does cabal verify the prerequisite alex >> version? (Or does it?) > > ghc-pkg lists libraries that are registered with the ghc package > manager (globally and locally); alex is simply an application, not a > library, so there's really nothing for GHC to register. As for telling > what version is necessary, I haven't the slightest. Slightly OT, but this division of work between cabal and ghc-pkg has always looked strange to me. Cabal knows better what meta information to store about a package, library or application. IMO the package database should reside with cabal; implementations like ghc or hugs or whatever could query cabal about the information they need (e.g. for building). Cheers Ben From jeremy at n-heptane.com Sat Aug 2 21:47:04 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Sat Aug 2 21:43:10 2008 Subject: [Haskell-cafe] Web processing In-Reply-To: <4895058C.3000002@gmail.com> References: <4895058C.3000002@gmail.com> Message-ID: <87k5eyeup3.wl%jeremy@n-heptane.com> Hello, I would recommend using TagSoup: http://www-users.cs.york.ac.uk/~ndm/tagsoup/ The tutorial easy, and has good advice: http://www.cs.york.ac.uk/fp/darcs/tagsoup/tagsoup.htm I would not bother trying to use a real XML parser, because I suspect that many of the XHTML pages you want to parse, are not actually valid XHTML, which means the XML parsers will fail. Also, some of the sites you are interested in might not be XHTML at all. So, using TagSoup for everything seems simpliest. The process is very lo-fi. Write some code using TagSoup which scrapes the data you care about from the web pages and turns it into Haskell data structures. This code should not be clever, and it will need to be updating whenever the site you are scraping changes enough to break your code. This process should work fine if you are talking about scraping data from some specific sites. If you want to make a web crawler which automatically finds relevant pages and scrapes the data, then that is a much bigger project. You will still want to use something like TagSoup to do the initial parsing, but extracting the data will be much trickier (though, possibly worth billions of $$$ if done well). j. ps. I only have experience with TagSoup, so there may be other libraries which are even better. The key feature of TagSoup is that it allows you to process malformed, invalid HTML -- which is important if you don't control the creation of the HTML you are parsing. At Sat, 02 Aug 2008 22:10:36 -0300, Rafael C. de Almeida wrote: > > Hello, > > I understand that nowadays there are several frameworks and wrapper > libraries for making some sense of the XHTML documents you find over the > web. That is, making the life of those who want to process the > semi-structured data you find on the sites. > > I don't have much experience on that field myself, but I want to learn a > little more about how I can, for instance, associate information from > one site with information in another site. Even though it is structured > differently in both places. Does anyone know about libraries that would > help me out with that sort of work? Hope I'm being clear. > > []'s > Rafael > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Sat Aug 2 21:48:16 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 2 21:48:07 2008 Subject: [Haskell-cafe] Web processing In-Reply-To: <87k5eyeup3.wl%jeremy@n-heptane.com> References: <4895058C.3000002@gmail.com> <87k5eyeup3.wl%jeremy@n-heptane.com> Message-ID: <20080803014816.GB6317@scytale.galois.com> jeremy: > Hello, > > I would recommend using TagSoup: > > http://www-users.cs.york.ac.uk/~ndm/tagsoup/ > > The tutorial easy, and has good advice: > > http://www.cs.york.ac.uk/fp/darcs/tagsoup/tagsoup.htm > There's also a wrapper for this, that uses curl+bytestrings for the download part, and exposes tags, xml and rss/atom parsers for the content itself, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/download-curl -- Don From derek.a.elkins at gmail.com Sat Aug 2 21:54:19 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Aug 2 21:54:09 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> Message-ID: <1217728459.13277.21.camel@derek-laptop> On Sat, 2008-08-02 at 18:22 -0700, Jason Dusek wrote: > I'm trying to figure out the adjunction diagrams for the > adjunction where the diagonal functor is right adjoint to the > coproduct functor. I'm |almost done|, but the co-unit has me > stumped, because I can't figure out how the arrow at the top > can be unique -- it seems it could be either one of: > > i_1 . [f,g] > i_2 . [f,g] > > i_1, i_2 : C -> C+C > f : A -> C > g : B -> C > > The net effect of [id,id] on the right is to blur out the > distinction. On #haskell, someone suggested there is a > constraint I am missing; I've poked around for a day and still > can't figure it out. [id,id] is the counit. [id,id] : C+C -> C Given a function f : A+B -> C there exists a unique function f* : (A,B) -> (C,C) that is a pair of functions h : A -> C and k : B -> C such that [id,id] . h+k = f. The one way is obvious given f, h = f . inL and k = f . inR So a solution exists. To show that it is unique assume we are given an h and k such that the above equation holds we need to show that h = f . inL (and similarly for k.) So start by precomposing both sides of the equation with inL giving: [id,id] . h+k . inL = f . inL We simply need to show that the left side is h. The injections together form the unit. Naturality of the unit says that for any h and k: h : A -> B k : C -> D inL . h = h+k . inL inR . k = h+k . inR Using this in the above we have: [id,id] . inL . h = f . inL Now we use one of the triangle identities which states: [id,id] . inL = id [id,id] . inR = id and this finishes the proof: id . h = f . inL h = f . inL From jgoerzen at complete.org Sat Aug 2 22:04:28 2008 From: jgoerzen at complete.org (John Goerzen) Date: Sat Aug 2 22:04:25 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP Message-ID: <4895122C.7070301@complete.org> Hi folks, I'm interested in writing a library to work with IMAP servers. I'm interested in thoughts people have on parsing libraries and methods. I'm a huge fan of Parsec overall -- it lets me have a single-stage parser, for instance. But it isn't sufficiently lazy for this task, and I probably will need to deal with ByteStrings instead of Strings, since some IMAP messages may be 30MB or more. So to give a very, very brief rundown of RFC3501, there are lots of ways that an IMAP server can encode things. For instance, we could see this: A283 SEARCH "TEXT" "string not in mailbox" which is the same as: A283 SEARCH TEXT "string not in mailbox" and the same as: A283 SEARCH {4} "string not in mailbox" TEXT The braces mean that the given number of octets follows after the CRLF at the end of the given line. We could even see: A283 SEARCH {4} {21} TEXTstring not in mailbox Note that when downloading messages, I would fully expect to see things like * FETCH {10485760} representing a 10MB message. Also, quoted strings have escaping rules. [ please note that the above is paraphrased and isn't really true RFC3501 for simplicity sake ] Now then... some goals. 1) Ideally I could parse stuff lazily. I have tried this with FTP and it is more complex than it seems at first, due to making sure you never, never, never consume too much data. But being able to parse lazily would make it so incredibly easy to issue a command saying "download all new mail", and things get written to disk as they come in, with no buffer at all. 2) Avoiding Strings wherever possible. 3) Avoiding complex buffering schemes where I have to manually buffer data packets. Thoughts and ideas? BTW, if any of you have heard of OfflineIMAP, yes I am considering rewriting OfflineIMAP in Haskell. -- John From jason.dusek at gmail.com Sat Aug 2 23:00:19 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Aug 2 23:00:09 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <1217728459.13277.21.camel@derek-laptop> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> Message-ID: <42784f260808022000v589d81frb61611bb0d615c27@mail.gmail.com> Derek Elkins wrote: > h : A -> C and k : B -> C > [...snip...] > h : A -> B > k : C -> D Are these the same h and k? -- ??_jsn ? From derek.a.elkins at gmail.com Sat Aug 2 23:11:15 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Aug 2 23:11:05 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <42784f260808022000v589d81frb61611bb0d615c27@mail.gmail.com> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> <42784f260808022000v589d81frb61611bb0d615c27@mail.gmail.com> Message-ID: <1217733075.13277.24.camel@derek-laptop> On Sat, 2008-08-02 at 20:00 -0700, Jason Dusek wrote: > Derek Elkins wrote: > > h : A -> C and k : B -> C > > [...snip...] > > h : A -> B > > k : C -> D > > Are these the same h and k? No. As it says in the line just before what you quoted these are -any- h and k. They do end up being instantiated to the above h and k albeit with specializations of the latter types. From newsham at lava.net Sun Aug 3 01:13:07 2008 From: newsham at lava.net (Tim Newsham) Date: Sun Aug 3 01:13:08 2008 Subject: [Haskell-cafe] code review? store server, 220loc. Message-ID: Anyone interested in critiquing some code? I'm looking for ideas for making it faster and/or simpler: http://www.thenewsh.com/%7Enewsham/store/Server5.hs This is an exercise to see how well a server in Haskell would perform. My goals are roughly: - retargetability to other server types (ie. easy to replace request and response structures and business logic). - readability. - performance. My measurements show that a simple dummy server (accept, forkio, recv byte) handles roughly 7500 requests/connects per second, the server/client that do real messages do about 4500 req and connections per second. If all requests are on the same connection one after another it does about 13500 requests/second. For comparisons, a C ping-pong server does about 3600/second if it has to fork for each new connection/request, and about 35000/sec if its all on the same connection. So it seems at least competitive with a forking C server. I havent tested threaded C servers. Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Sun Aug 3 01:17:43 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 3 01:17:37 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: References: Message-ID: <20080803051743.GC6868@scytale.galois.com> newsham: > Anyone interested in critiquing some code? I'm looking for ideas > for making it faster and/or simpler: > > http://www.thenewsh.com/%7Enewsham/store/Server5.hs > > This is an exercise to see how well a server in Haskell would perform. > My goals are roughly: > - retargetability to other server types (ie. easy to > replace request and response structures and business logic). > - readability. > - performance. > > My measurements show that a simple dummy server (accept, forkio, > recv byte) handles roughly 7500 requests/connects per second, > the server/client that do real messages do about 4500 req and > connections per second. If all requests are on the same connection > one after another it does about 13500 requests/second. For > comparisons, a C ping-pong server does about 3600/second if > it has to fork for each new connection/request, and about 35000/sec > if its all on the same connection. So it seems at least competitive > with a forking C server. I havent tested threaded C servers. > packBS :: String -> B.ByteString packBS = B.pack . map (toEnum.fromEnum) -- | Convert a bytestring to a string. unpackBS :: B.ByteString -> String unpackBS = map (toEnum.fromEnum) . B.unpack are Data.ByteString.Char8.pack/unpack. What optimisation and runtime flags did you use (-threaded or not?) From jason.dusek at gmail.com Sun Aug 3 02:40:10 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Aug 3 02:39:58 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <1217728459.13277.21.camel@derek-laptop> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> Message-ID: <42784f260808022340k4d5da511x22729aa15af63162@mail.gmail.com> Derek Elkins wrote: > [id,id] is the counit. > [id,id] : C+C -> C > Given a function f : A+B -> C there exists a unique function > f* : (A,B) -> (C,C) that is a pair of functions > h : A -> C and k : B -> C such that > [id,id] . h+k = f. This f is what I have labelled [f,g] (or f+g) in the diagram I linked to, right? In that case h and k are just f and g, respectively, and the unique arrow that goes from A+B to C+C is f+g -- but that would make C+C just the same as C. -- _jsn From trentbuck at gmail.com Sun Aug 3 01:17:40 2008 From: trentbuck at gmail.com (Trent W. Buck) Date: Sun Aug 3 03:19:54 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> Message-ID: <30tze27k3v.fsf@Clio.twb.ath.cx> "Neil Mitchell" writes: > The darcs 2.0 announcement read like an obituary I don't know why, but a lot of people I spoke to seemed to have that impression, and I essentially had to wave changelogs under their face to convince them that darcs was still being worked on *at all*. I had to point out that it was a *release* announcement -- how could a dead project have a new major version? Perhaps a chirpy journalism major should be writing vapidly up-beat announcement posts, denying even the possibility of problems :-P From derek.a.elkins at gmail.com Sun Aug 3 03:26:33 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Aug 3 03:26:25 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <42784f260808022340k4d5da511x22729aa15af63162@mail.gmail.com> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> <42784f260808022340k4d5da511x22729aa15af63162@mail.gmail.com> Message-ID: <1217748393.13277.37.camel@derek-laptop> On Sat, 2008-08-02 at 23:40 -0700, Jason Dusek wrote: > Derek Elkins wrote: > > [id,id] is the counit. > > [id,id] : C+C -> C > > Given a function f : A+B -> C there exists a unique function > > f* : (A,B) -> (C,C) that is a pair of functions > > h : A -> C and k : B -> C such that > > [id,id] . h+k = f. > > This f is what I have labelled [f,g] (or f+g) in the diagram I > linked to, right? Yes. [f,g] is the right notation. The statement of the universal arrow, however, uses -any- arrow A+B -> C so I thought it best not to expose any of its structure. Anyway, showing that it has such structure is what proving uniqueness of f* does. > In that case h and k are just f and g, respectively, and the > unique arrow that goes from A+B to C+C is f+g -- but that > would make C+C just the same as C. The unique arrow is f* : (A,B) -> (C,C), -not- an arrow A+B -> C+C. An arrow f : A+B -> C does -not- uniquely determine an arrow A+B -> C+C such that the universal arrow diagram commutes. From dons at galois.com Sun Aug 3 03:36:39 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 3 03:36:32 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <30tze27k3v.fsf@Clio.twb.ath.cx> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> Message-ID: <20080803073639.GA7215@scytale.galois.com> trentbuck: > "Neil Mitchell" writes: > > The darcs 2.0 announcement read like an obituary > > I don't know why, but a lot of people I spoke to seemed to have that > impression, and I essentially had to wave changelogs under their face to > convince them that darcs was still being worked on *at all*. I had to > point out that it was a *release* announcement -- how could a dead > project have a new major version? The 2.0 release should have been a triumph. That announce was a strategic error of pretty immense proportions. And as a result, it's basically impossible to justify work on the project to outsiders, or new transition to darcs on projects. And it made those who recommended darcs look foolish. The once shining "smart dvcs" brand of darcs has been trampled. To really turn things around -- which maybe could be done -- we'd need new leadership, and an aggressive change in project direction, to counter the slide. And that's a *lot* of work: full time, active project leadership, lots of public activity, clear goals, clear direction. It could make someone famous. Do we have a young turk to take up the challenge? And all this delay while the git juggernaut takes over the internet. > Perhaps a chirpy journalism major should be writing vapidly up-beat > announcement posts, denying even the possibility of problems :-P I think Eric's doing language processing, not journalism ;) -- Don From allbery at ece.cmu.edu Sun Aug 3 03:45:46 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 3 03:45:40 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <30tze27k3v.fsf@Clio.twb.ath.cx> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> Message-ID: On 2008 Aug 3, at 1:17, Trent W. Buck wrote: > "Neil Mitchell" writes: >> The darcs 2.0 announcement read like an obituary > > I don't know why, but a lot of people I spoke to seemed to have that > impression, and I essentially had to wave changelogs under their > face to That would be this part in particular: > Unfortunately, it is also a rather labor-intensive process, and due > to a lack of contributors, we've moving to a more streamlined > process. Starting with the darcs 2.0.0 release, there will be just > one central branch of darcs and only one maintainer: for now this is > me, David Roundy. Moreover, I will be attempting to act as a much > lower-profile maintainer than we've had previously. I will not be > reading bug reports, reading the darcs-users email list or even the > darcs-devel mailing list. I will only be reviewing patches that are > contributed. Which is pretty much saying "darcs 2 has moved to maintenance mode". And this: > Darcs 2.0.0 contains some performance regressions when running with > large repositories. It is possible that these regressions will be > sufficient to prevent its effective use in some projects. If this > describes your project--and the only way to know is to try it--then > I recommend considering either switching to a different revision > control system, or helping us to improve darcs. The former is > certainly the easier path. didn't help. All in all, it sounded an awful lot like "here's our final release, find new maintainers if you want it to continue" --- followed by an ominous silence from the darcs camp. (Hm, I feel a blog rant coming on.) -- 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 jason.dusek at gmail.com Sun Aug 3 03:52:14 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Aug 3 03:52:07 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <1217748393.13277.37.camel@derek-laptop> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> <42784f260808022340k4d5da511x22729aa15af63162@mail.gmail.com> <1217748393.13277.37.camel@derek-laptop> Message-ID: <42784f260808030052j4b3f13e6iaa4307b8420dc8e7@mail.gmail.com> Derek Elkins wrote: > Jason Dusek wrote: > > the unique arrow that goes from A+B to C+C is f+g -- but > > that would make C+C just the same as C. > > The unique arrow is f* : (A,B) -> (C,C), -not- an arrow A+B -> > C+C. An arrow f : A+B -> C does -not- uniquely determine an > arrow A+B -> C+C such that the universal arrow diagram > commutes. Yes, I have confused my meaning a bit. +(f*) is also unique, and that was the arrow I was thinking of. So, we have f* : (A, B) -> (C, C), comprising h and k, so I am not sure sure how + will act on it. As I've seen with + so far, it works like this on arrows: +((A -> C), (B -> C)) |-> A+B -> C So, for example, +(f, g) |-> [f,g] -- so what is f* made of? This is what seems to be happening: +((A, B) -> (C, C)) |-> A+B -> C+C So how are h and k paired? Their pairing puts them CxC but seemingly in a different way from the way I've paired f and g. -- _jsn From donn at avvanta.com Sun Aug 3 04:52:08 2008 From: donn at avvanta.com (Donn Cave) Date: Sun Aug 3 04:49:37 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP In-Reply-To: <4895122C.7070301@complete.org> References: <4895122C.7070301@complete.org> Message-ID: <20080803015208.eb2182d0.donn@avvanta.com> On Sat, 02 Aug 2008 21:04:28 -0500 John Goerzen wrote: ... > The braces mean that the given number of octets follows after the CRLF > at the end of the given line. We could even see: > > A283 SEARCH {4} {21} > TEXTstring not in mailbox I don't think it's quite that bad. The literal count must immediately precede the value -- {4}\r\nTEXT -- the way I read it. I think most servers use this mechanism for mail message data only, but seems to me there's one out there that may occasionally slip a literal into LIST results. > 1) Ideally I could parse stuff lazily. I have tried this with FTP and > it is more complex than it seems at first, due to making sure you never, > never, never consume too much data. But being able to parse lazily > would make it so incredibly easy to issue a command saying "download all > new mail", and things get written to disk as they come in, with no > buffer at all. I'm not sure what that means, but to start at the beginning, ideally the IMAP parser would be pure, right? > 2) Avoiding Strings wherever possible. It certainly makes sense to me that message data would be bytestring, not only the "body" of the message but header fields as well. Flags, for me, would be string, unless you want to parse the standard flags into a sum type. No big deal, maybe bytestrings are more convenient than I realize. > 3) Avoiding complex buffering schemes where I have to manually buffer > data packets. This sounds to me like the application's problem, not the parser's? I actually wrote the beginnings of an IMAP parser, for my own entertainment. Substantially incomplete, in terms of support for various IMAP responses, but it works against a couple of IMAP servers, and it supports GSSAPI authentication and SSL. Well, of course the IMAP parsing code itself has no idea about GSSAPI or SSL, that being the application's job, but I think it's worth looking at how for example GSSAPI authentication works with IMAP, while designing the parser. In the most general view, it may return either (response, remainder) or (insufficient-data), and in the latter case the application gets more data from the server and tries again. -- Donn Cave From derek.a.elkins at gmail.com Sun Aug 3 05:41:15 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Aug 3 05:41:06 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <42784f260808030052j4b3f13e6iaa4307b8420dc8e7@mail.gmail.com> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> <42784f260808022340k4d5da511x22729aa15af63162@mail.gmail.com> <1217748393.13277.37.camel@derek-laptop> <42784f260808030052j4b3f13e6iaa4307b8420dc8e7@mail.gmail.com> Message-ID: <1217756475.13277.72.camel@derek-laptop> On Sun, 2008-08-03 at 00:52 -0700, Jason Dusek wrote: > Derek Elkins wrote: > > Jason Dusek wrote: > > > the unique arrow that goes from A+B to C+C is f+g -- but > > > that would make C+C just the same as C. > > > > The unique arrow is f* : (A,B) -> (C,C), -not- an arrow A+B -> > > C+C. An arrow f : A+B -> C does -not- uniquely determine an > > arrow A+B -> C+C such that the universal arrow diagram > > commutes. > > Yes, I have confused my meaning a bit. +(f*) is also unique, > and that was the arrow I was thinking of. Again, f* is what is being solved for and proved unique. > > So, we have f* : (A, B) -> (C, C), comprising h and k, so I > am not sure sure how + will act on it. As I've seen with + so > far, it works like this on arrows: > > +((A -> C), (B -> C)) |-> A+B -> C > > So, for example, +(f, g) |-> [f,g] -- so what is f* made of? > This is what seems to be happening: > > +((A, B) -> (C, C)) |-> A+B -> C+C > > So how are h and k paired? Their pairing puts them CxC but > seemingly in a different way from the way I've paired f and g. The notation (A,B) is the notation for an object in a product category in this case. It is also the notation for a product in a category. Usually context makes it clear which is which. The notation f+g is the notation for the functorial action of + : CxC -> C on arrows, that is, if f : A -> B and g : C -> D then f+g : A+C -> B+D. One issue you seem to have is with the notation which is admittedly rather ambiguous. Another is with the precise definition of universal arrow. e : FY -> B is a universal arrow (from F) iff forall A and forall f : FA -> B there exists a unique arrow g : A -> Y such that e . Fg = f I prefer the representability perspective on universal arrows and that can be arrived at by essentially Skolemizing the above definition. If we have a function f : X -> Y then forall x in X there exists a y in Y namely f(x). Adding that y must be unique adds the requirement that f be injective. Taking this we can rewrite the above as e : FY -> B is a universal arrow (from F) iff there exists an injective function t : Hom(FA,B) -> Hom(A,Y) forall A such that forall f : FA -> B (that is forall f in Hom(FA,B)) e . F(t(f)) = f Since for any arrow g : A -> Y e . Fg = e . Fg and thus g = t(e . Fg) by uniqueness, we find that t is actually surjective as well as injective, that is -every- function A -> Y is in the image of t. A function is injective and surjective iff it is a isomorphism. So we can simplify the above. e : FY -> B is a universal arrow (from F) iff forall A there is an isomorphism Hom(FA,B) ~ Hom(A,Y) This can be further simplified by the definition of a natural isomorphism in Set. e : FY -> B is a universal arrow (from F) iff there is a natural isomorphism Hom(F-,B) ~ Hom(-,Y) The derivation of this definition captures the general pattern for all proofs of the statements along the line of your original question. There are three definitions of adjunction: one that uses representability (i.e. an isomorphism of homsets like the last definition of universal arrow above), one that uses universal arrows (i.e. assume either the unit or the counit is component-wise a universal arrow for all components), and one that uses the triangle identities. It is a crucial skill to be able to switch between these definitions seamlessly. From bradypus at xs4all.nl Sun Aug 3 05:56:43 2008 From: bradypus at xs4all.nl (Arie Groeneveld) Date: Sun Aug 3 05:56:18 2008 Subject: [Haskell-cafe] timing question Message-ID: <489580DB.2020607@xs4all.nl> Suppose I've: f = map g I want to know how much time it takes (interpreted mode) to fully process list xs (at least 1e6 elements) with function g. Is it sufficient to execute: *Main> last . f $ xs (x.xx secs, yyyyyyyyyyy bytes) Are there any hidden difficulties involved? Reason is: comparing timings Haskell vs an interpreted language without laziness. thanks =@@i From newsham at lava.net Sun Aug 3 06:29:45 2008 From: newsham at lava.net (Tim Newsham) Date: Sun Aug 3 06:29:45 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: <20080803051743.GC6868@scytale.galois.com> References: <20080803051743.GC6868@scytale.galois.com> Message-ID: > newsham: >> Anyone interested in critiquing some code? I'm looking for ideas >> for making it faster and/or simpler: > > What optimisation and runtime flags did you use (-threaded or not?) currently "ghc -O --make $< -o $@". For some measurements I tried -threaded which seemed to have a slight slowdown and +RTS -N2 at runtime which didnt seem to help. I also ran some tests with multiple clients running concurrently, and it seemed to handle them at approximately the same rate with and without the threaded and RTS flags (on an amd64x2). Those flags should have allowed it to handle two client connections (via forkIO) concurrently, right? [ps: the same web directory has test clients and other versions of the server.] Tim Newsham http://www.thenewsh.com/~newsham/ From bulat.ziganshin at gmail.com Sun Aug 3 06:34:59 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Aug 3 06:34:57 2008 Subject: [Haskell-cafe] timing question In-Reply-To: <489580DB.2020607@xs4all.nl> References: <489580DB.2020607@xs4all.nl> Message-ID: <1805785403.20080803143459@gmail.com> Hello Arie, Sunday, August 3, 2008, 1:56:43 PM, you wrote: *Main>> last . f $ xs this way you will get only "spin" of list computed, not elements itself. something like sum should be used instead -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bradypus at xs4all.nl Sun Aug 3 07:06:40 2008 From: bradypus at xs4all.nl (Arie Groeneveld) Date: Sun Aug 3 07:06:18 2008 Subject: [Haskell-cafe] timing question In-Reply-To: <1805785403.20080803143459@gmail.com> References: <489580DB.2020607@xs4all.nl> <1805785403.20080803143459@gmail.com> Message-ID: <48959140.4020203@xs4all.nl> Sorry, should go the forum. Ok, thanks. In this case the list consists of 6-digit alphanumeric codes. So doing something like: foldl1 (\x y -> g y) xs will do the job? =@@i Bulat Ziganshin schreef: > Hello Arie, > > Sunday, August 3, 2008, 1:56:43 PM, you wrote: > > *Main>> last . f $ xs > > this way you will get only "spin" of list computed, not elements > itself. something like sum should be used instead > > > From ashley.moran at patchspace.co.uk Sun Aug 3 07:23:21 2008 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun Aug 3 07:23:27 2008 Subject: [darcs-users] [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <20080803073639.GA7215@scytale.galois.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <20080803073639.GA7215@scytale.galois.com> Message-ID: Sorry for the duplication, I'm now on the haskell-cafe list and wanted to track the other half of this thread. On Aug 03, 2008, at 8:36 am, Don Stewart wrote: > And all this delay while the git juggernaut takes over the internet. That's the biggest tragedy. It's the same disappointment I have knowing Linux is more popular than FreeBSD! Still, a project doesn't have to have a near-monopoly to be successful. There are still far less people using Ruby than Java, but there's more than enough to provide a vibrant ecosystem. (And it's one that churns out way more cool stuff than the Java world - there's no technical reason why Haskell couldn't do so too.) GitHub is responsible for git's popularity. Git is so popular not because it's the best, but because it has the best Web 2.0 site. I work primarily in web development and it did occur to me to have a stab at darcshub, but I didn't know how much work would be involved in making something useful (I don't have much spare time right now), and if I'd be the only person that used it... I think that would be a major boost for darcs though, if anyone wanted a go. And it could be in any language, not just Haskell. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ From duncan.coutts at worc.ox.ac.uk Sun Aug 3 07:43:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 3 07:42:56 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: References: Message-ID: <1217763787.7661.39.camel@localhost> On Sat, 2008-08-02 at 19:13 -1000, Tim Newsham wrote: > My measurements show that a simple dummy server (accept, forkio, > recv byte) handles roughly 7500 requests/connects per second, > the server/client that do real messages do about 4500 req and > connections per second. If all requests are on the same connection > one after another it does about 13500 requests/second. For > comparisons, a C ping-pong server does about 3600/second if > it has to fork for each new connection/request, and about 35000/sec > if its all on the same connection. So it seems at least competitive > with a forking C server. I havent tested threaded C servers. What kind of performance do you actually need? Can your network connection actually sustain the bandwidth of your synthetic benchmarks? For reference, I've got a demo HAppS-based server which handles reasonably high load pretty well I think: ?(tested using apache-bench, loopback interface, amd64 @ 2.2GHz) ?With cached content 450k: ??with 1 ?concurrent client: 760 requests per second ~1ms latency 34Mb/s ?with 100 ?concurrent clients: 1040 requests per second ~90ms latency 46Mb/s on a non-cached generated-on-demand 3k page: ??with 1 ?concurrent client: 280 requests per second ~4ms latency 900Kb/s ?bandwidth ??with 100 ?concurrent clients: ?240 requests per second ~400ms latency 750Kb/s bandwidth Using http keep-alive boots requests per sec by ~20% Obviously this is testing with a loopback network. My point is, it's serving at a rather higher rate than most real network connections I could buy (except local ethernet networks). Duncan From ashley.moran at patchspace.co.uk Sun Aug 3 08:44:45 2008 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun Aug 3 08:44:47 2008 Subject: [darcs-users] [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <20080803135354.14d2a78a@yacu> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <20080803073639.GA7215@scytale.galois.com> <6E88FE73-3C97-433C-86FB-AD3BEFCCFBD0@patchspace.co.uk> <20080803135354.14d2a78a@yacu> Message-ID: On Aug 03, 2008, at 12:53 pm, Lele Gaifax wrote: > I fail to see what's so cool with GitHub: a quick overview didn't > reveal anything that couldn't be done with, say, Trac+Darcs. Can you > elaborate on that? Hi Lele It probably doesn't do anything you couldn't in Trac+darcs. But that's not the point - it's easy to jump on there, and fork a repo, track the changes in both directions. The barrier to working on a project on there is virtually nil (there is, of course, the issue of figuring out git when you've got the source on your machine, but that's a separate issue). What GitHub does really well is build a community around the repos. They could have used Hg or bzr or pretty much and DVCS and been as successful, but they (unfortunately) chose git. > IMHO, the biggest problem with darcs is with its underdocumented (from > the technical point of view) code base, that only an handful of people > understand. As already stated, I doubt Haskell is the real culprit > here: the algorithms are effectively difficult to explain in any > language, English to starts with. I wish David used a less succint > coding style, and could spend some time to enlight and mentor new > developers, but that's the way it is. My issue with the code base is the lack of unit tests. Coming from a Ruby background, I'm used to very short methods with very specific tests, often for things that to new programmers look trivial. To RSpec users, these unit tests *are* the documentation. By comparison, darcs only has functional tests, and it's hard to see how you can tell what code is covered by them. This would make me very wary about hacking at the code, not knowing if I could inadvertently break something. It also means you have to understand much bigger chunks of code to know how to fix something. I've very often fixed a bug in Ruby code because there's a one-line spec that describes exactly the behaviour that is at fault (or a missing one for the case I want). I don't know what the standard for Haskell testing is, and how FP testing compares to OOP testing. As a very trivial example the function "showPatchInfo :: PatchInfo -> Doc" could do with a test to show it produces output of the format "Initial import Ashley Moran **20080630153800]" (and if it *doesn't*, that is the point I'm making!) I think having the patch algorithms broken down and tested in this way would be the best form of documentation, although a plain-English specification would probably also be necessary. Simpler stuff (like showPatchInfo) just needs something to demonstrate what it does. Just my (naive) opinion coming from a OOP, test-obsessed background. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ From ketil at malde.org Sun Aug 3 10:26:32 2008 From: ketil at malde.org (Ketil Malde) Date: Sun Aug 3 10:26:25 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: (Brandon S. Allbery's message of "Sun\, 3 Aug 2008 03\:45\:46 -0400") References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> Message-ID: <877iayfa3r.fsf@malde.org> "Brandon S. Allbery KF8NH" writes: >> "Neil Mitchell" writes: >>> The darcs 2.0 announcement read like an obituary >> I don't know why, but a lot of people I spoke to seemed to have that >> impression, and I essentially had to wave changelogs under their >> face to [...] > didn't help. All in all, it sounded an awful lot like "here's our > final release, find new maintainers if you want it to continue" --- > followed by an ominous silence from the darcs camp. Well, it seems to be up to 2.0.2 now, so it's clearly too early to pass out the shovels. On the other hand, I was trying to pull down the repo, and got a 404 - that's not so good. Is it down temporarily, or is the front page incorrect? -k -- If I haven't seen further, it is by standing in the footprints of giants From bremner at unb.ca Sun Aug 3 10:36:36 2008 From: bremner at unb.ca (David Bremner) Date: Sun Aug 3 10:36:27 2008 Subject: [darcs-users] [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <20080803073639.GA7215@scytale.galois.com> Message-ID: <0tej56jhcb.wl%bremner@pivot.cs.unb.ca> At Sun, 3 Aug 2008 12:23:21 +0100, Ashley Moran wrote: > > GitHub is responsible for git's popularity. Git is so popular not > because it's the best, but because it has the best Web 2.0 site. I > work primarily in web development and it did occur to me to have a > stab at darcshub, but I didn't know how much work would be involved in > making something useful (I don't have much spare time right now), and > if I'd be the only person that used it... I think this view is probably coloured by your background in web development. I have used git for about a year now, and never visited GitHub. I'm not saying you have to like git, but it does have other features other than a snazzy web site. I do agree that adoption of development tools is driven by network effects. When I chose a DVCS to learn, I only wanted to learn one, so I chose the one that seemed like it had the most momentum. The rich get richer... Maybe the answer is to work on Darcs-git :-) David From roly.perera at dynamicaspects.org Sun Aug 3 10:39:24 2008 From: roly.perera at dynamicaspects.org (Roly Perera) Date: Sun Aug 3 10:44:52 2008 Subject: [Haskell-cafe] Kleisli composition operator Message-ID: Hi, I'm obviously missing something basic here but I don't seem to be able to use the >=> operator which is apparently defined in the Prelude and also in Control.Monad. My imports are: import Prelude hiding (abs, lookup, init) import Data.Maybe import Data.List as List hiding (lookup, insert, delete, union, init) import Data.Map as Map hiding (update, delete, union, null, findIndex) import qualified Data.Tree as Tree import Control.Monad import Control.Monad.State Any suggestions anyone? thanks, Roly Perera From roly.perera at dynamicaspects.org Sun Aug 3 10:52:25 2008 From: roly.perera at dynamicaspects.org (Roly Perera) Date: Sun Aug 3 10:52:24 2008 Subject: [Haskell-cafe] Re: Kleisli composition operator References: Message-ID: > I'm obviously missing something basic here but I don't seem to be able to use > the >=> operator which is apparently defined in the Prelude and also in > Control.Monad. Sorry, I wasn't very clear in my original posting. What I meant to say is that the compiler seems to be unable to find a definition of >=>. I get the message: Not in scope: `>=>' My understanding is that I shouldn't need to import this at all by default, and that importing Control.Monad should also pick it up. > My imports are: > > import Prelude hiding (abs, lookup, init) > > import Data.Maybe > import Data.List as List hiding (lookup, insert, delete, union, init) > import Data.Map as Map hiding (update, delete, union, null, findIndex) > import qualified Data.Tree as Tree > import Control.Monad > import Control.Monad.State > > Any suggestions anyone? > > thanks, > Roly Perera From gwern0 at gmail.com Sun Aug 3 11:03:52 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Aug 3 11:04:10 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <877iayfa3r.fsf@malde.org> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <877iayfa3r.fsf@malde.org> Message-ID: <20080803150352.GA13167@craft> On 2008.08.03 16:26:32 +0200, Ketil Malde scribbled 0.7K characters: > "Brandon S. Allbery KF8NH" writes: > > >> "Neil Mitchell" writes: > > >>> The darcs 2.0 announcement read like an obituary > > >> I don't know why, but a lot of people I spoke to seemed to have that > >> impression, and I essentially had to wave changelogs under their > >> face to > > [...] > > > didn't help. All in all, it sounded an awful lot like "here's our > > final release, find new maintainers if you want it to continue" --- > > followed by an ominous silence from the darcs camp. > > Well, it seems to be up to 2.0.2 now, so it's clearly too early to > pass out the shovels. On the other hand, I was trying to pull down > the repo, and got a 404 - that's not so good. Is it down temporarily, > or is the front page incorrect? > > -k > -- I just darcs get http://darcs.net, so I would guess it was either temporary or a problem on your end. -- gwern JICS Golf package ETA QinetiQ AFSPC NSOF JCE DREO UXO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080803/42443c4b/attachment.bin From duncan.coutts at worc.ox.ac.uk Sun Aug 3 11:09:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 3 11:09:25 2008 Subject: [Haskell-cafe] Re: Kleisli composition operator In-Reply-To: References: Message-ID: <1217776186.7661.47.camel@localhost> On Sun, 2008-08-03 at 14:52 +0000, Roly Perera wrote: > > I'm obviously missing something basic here but I don't seem to be able to use > > the >=> operator which is apparently defined in the Prelude and also in > > Control.Monad. > > Sorry, I wasn't very clear in my original posting. What I meant to say is that > the compiler seems to be unable to find a definition of >=>. I get the message: > > Not in scope: `>=>' > > My understanding is that I shouldn't need to import this at all by default, and > that importing Control.Monad should also pick it up. It's not in the Prelude but it is in ?Control.Monad in base version 3 and later. You're probably using an older GHC which has base version 2.x. You can define it locally: -- | Left-to-right Kleisli composition of monads. (>=>) :: Monad m => (a -> m b) -> (b -> m c) -> (a -> m c) f >=> g = \x -> f x >>= g Duncan From daniel.is.fischer at web.de Sun Aug 3 11:18:54 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Aug 3 11:16:47 2008 Subject: [Haskell-cafe] Re: Kleisli composition operator In-Reply-To: References: Message-ID: <200808031718.54664.daniel.is.fischer@web.de> Am Sonntag, 3. August 2008 16:52 schrieb Roly Perera: > > I'm obviously missing something basic here but I don't seem to be able to > > use the >=> operator which is apparently defined in the Prelude and also > > in Control.Monad. > > Sorry, I wasn't very clear in my original posting. What I meant to say is > that the compiler seems to be unable to find a definition of >=>. I get > the message: > > Not in scope: `>=>' > > My understanding is that I shouldn't need to import this at all by default, > and that importing Control.Monad should also pick it up. > > > My imports are: > > > > import Prelude hiding (abs, lookup, init) > > > > import Data.Maybe > > import Data.List as List hiding (lookup, insert, delete, union, init) > > import Data.Map as Map hiding (update, delete, union, null, findIndex) > > import qualified Data.Tree as Tree > > import Control.Monad > > import Control.Monad.State > > > > Any suggestions anyone? > > > > thanks, > > Roly Perera > Which implementation are you using? IIRC, GHC didn't have it in Control.Monad before the 6.8 branch. From roly.perera at dynamicaspects.org Sun Aug 3 11:31:38 2008 From: roly.perera at dynamicaspects.org (Roly Perera) Date: Sun Aug 3 11:31:36 2008 Subject: [Haskell-cafe] Re: Kleisli composition operator References: <200808031718.54664.daniel.is.fischer@web.de> Message-ID: Daniel Fischer web.de> writes: > Which implementation are you using? > IIRC, GHC didn't have it in Control.Monad before the 6.8 branch. Duncan Coutts writes: > It's not in the Prelude but it is in ?Control.Monad in base version 3 > and later. You're probably using an older GHC which has base version > 2.x. Thanks for the quick responses. Looks like I need to install a version later than 6.8. Roly From ashley.moran at patchspace.co.uk Sun Aug 3 12:07:10 2008 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun Aug 3 12:07:17 2008 Subject: [darcs-users] [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <0tej56jhcb.wl%bremner@pivot.cs.unb.ca> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <20080803073639.GA7215@scytale.galois.com> <0tej56jhcb.wl%bremner@pivot.cs.unb.ca> Message-ID: On Aug 03, 2008, at 3:36 pm, David Bremner wrote: > I think this view is probably coloured by your background in web > development. I have used git for about a year now, and never visited > GitHub. I'm not saying you have to like git, but it does have other > features other than a snazzy web site. Hi David I think I gave the wrong impression there. After all, I use darcs despite it not having a snazzy website! What I mean is that git usage has snowballed since GitHub was released, so people are clearly attracted to the website first, and the SCM second. It's a bit like the way Rails created thousands of Ruby programmers by association, many of them with no idea what Ruby was all about, just a vague notion that Rails could solve their problem. Ultimately my point is I think that MercurialHub or BazaarHub (BazaarBazaar?) would have been as successful. > I do agree that adoption of development tools is driven by network > effects. When I chose a DVCS to learn, I only wanted to learn one, so > I chose the one that seemed like it had the most momentum. The rich > get richer... I tend to very stubbornly work the other way... choose the tool I think works best with very little regard for its momentum, unless of course it clearly has none. Hence my love of darcs and recent interest in Haskell. (I'll figure it out, one day!) > Maybe the answer is to work on Darcs-git :-) Well that's been looked at before... unfortunately it's been abandoned now. There's also discussion on darcs-users that a Haskell implementation of Git would finally settle the "Haskell is too slow" debate. Now I think if the world is going to use git, a better implementation would be a good thing (I know a developer who got VERY frustrated trying to program against it). Personally I think the developer time would be better invested in fixing darcs bugs and improving its performance. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ From ketil at malde.org Sun Aug 3 12:36:22 2008 From: ketil at malde.org (Ketil Malde) Date: Sun Aug 3 12:36:09 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <20080803150352.GA13167@craft> (Gwern Branwen's message of "Sun\, 3 Aug 2008 11\:03\:52 -0400") References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <877iayfa3r.fsf@malde.org> <20080803150352.GA13167@craft> Message-ID: <87tze2dpix.fsf@malde.org> Gwern Branwen writes: > I just darcs get http://darcs.net, so I would guess it was either temporary or a problem on your end. Seems I needed a newer darcs - the one shipped with Ubuntu is 1.0.9, which appears to be too old, and it works when I build a new 2.0.2 from the tarball. (Anybody with write access to the front page who can make a note of minimum version required to 'darcs get' the repository?) -k -- If I haven't seen further, it is by standing in the footprints of giants From brad.larsen at gmail.com Sun Aug 3 12:58:20 2008 From: brad.larsen at gmail.com (Brad Larsen) Date: Sun Aug 3 12:58:10 2008 Subject: [Haskell-cafe] timing question In-Reply-To: <48959140.4020203@xs4all.nl> References: <489580DB.2020607@xs4all.nl> <1805785403.20080803143459@gmail.com> <48959140.4020203@xs4all.nl> Message-ID: Arie, foldl1 is not strict in its function argument. Using it will cause stack overflows for large lists. For example: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> foldl1 (+) [0..1000000] *** Exception: stack overflow foldl1' from Data.List is strict in its function argument, and is probably what you want. See also . Regards, Brad Larsen On Sun, 03 Aug 2008 07:06:40 -0400, Arie Groeneveld wrote: > Sorry, should go the forum. > > Ok, thanks. In this case the list consists of 6-digit alphanumeric > codes. So doing something like: > > foldl1 (\x y -> g y) xs > > will do the job? > > > =@@i > > > Bulat Ziganshin schreef: >> Hello Arie, >> >> Sunday, August 3, 2008, 1:56:43 PM, you wrote: >> >> *Main>> last . f $ xs >> >> this way you will get only "spin" of list computed, not elements >> itself. something like sum should be used instead >> >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jason.dusek at gmail.com Sun Aug 3 13:01:12 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Aug 3 13:00:59 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <1217756475.13277.72.camel@derek-laptop> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> <42784f260808022340k4d5da511x22729aa15af63162@mail.gmail.com> <1217748393.13277.37.camel@derek-laptop> <42784f260808030052j4b3f13e6iaa4307b8420dc8e7@mail.gmail.com> <1217756475.13277.72.camel@derek-laptop> Message-ID: <42784f260808031001i2715ff20ra533ba6f0f591db7@mail.gmail.com> Derek Elkins wrote: > The notation f+g is the notation for the functorial action of > + : CxC -> C on arrows, that is, if f : A -> B and g : C -> D > then f+g : A+C -> B+D. So [f,g] and f+g different. I assumed that the functorial action of + on arrows was to take ((A -> C), (B -> C)) to A+B -> C, which goes a long way to explaining my confusion :) -- _jsn From jason.dusek at gmail.com Sun Aug 3 13:03:08 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Aug 3 13:02:56 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <42784f260808031001i2715ff20ra533ba6f0f591db7@mail.gmail.com> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <1217728459.13277.21.camel@derek-laptop> <42784f260808022340k4d5da511x22729aa15af63162@mail.gmail.com> <1217748393.13277.37.camel@derek-laptop> <42784f260808030052j4b3f13e6iaa4307b8420dc8e7@mail.gmail.com> <1217756475.13277.72.camel@derek-laptop> <42784f260808031001i2715ff20ra533ba6f0f591db7@mail.gmail.com> Message-ID: <42784f260808031003g4e9f26b4n88cdbd6b97102542@mail.gmail.com> So I guess the Wikipedia page has an error in it? http://en.wikipedia.org/wiki/Coproduct#Definition -- _jsn From ashley.moran at patchspace.co.uk Sun Aug 3 13:10:05 2008 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun Aug 3 13:10:06 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <87tze2dpix.fsf@malde.org> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <877iayfa3r.fsf@malde.org> <20080803150352.GA13167@craft> <87tze2dpix.fsf@malde.org> Message-ID: On Aug 03, 2008, at 5:36 pm, Ketil Malde wrote: > Seems I needed a newer darcs - the one shipped with Ubuntu is 1.0.9, > which appears to be too old, and it works when I build a new 2.0.2 > from the tarball. (Anybody with write access to the front page who > can make a note of minimum version required to 'darcs get' the > repository?) Hi Ketil Just FYI, Iain Lane made a darcs package for 2.0.2: https://launchpad.net/~laney/+archive Bit easier than compiling it from scratch. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ From lrpalmer at gmail.com Sun Aug 3 13:15:29 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Aug 3 13:15:17 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <7ca3f0160808031015s7333a69axa6bd844f7fe9a525@mail.gmail.com> On Fri, Aug 1, 2008 at 3:45 PM, Eric Kow wrote: > Dear Haskellers, > > I would like to take an informal poll for the purposes of darcs > recruitment. Could you please complete this sentence for me? > > "I would contribute to darcs if only..." > I haven't used darcs much, so it's possible that I'll be forced to start contributing by my own binding hypothetical. I would contribute to darcs if only it had support / could have support for splitting and merging repositories. For example, I like to work in a big repository of all my stuff ever, because most of the things I do rarely exceed an experiment in one file. But once something does get big enough to be interesting, I want to split it off into its own repository. But that's just the use case: doing it the git way (go through all patches, discard irrelevant ones, filter relevant ones, thus losing all correlation with the original repository) is not going to inspire me; I'd like to see support for it in the beautiful patch theory. Luke > > The answers I am most interested in hearing go beyond "... I had more > time". For instance, if you are contributing to other Haskell/volunteer > projects, why are you contributing more to them, rather than darcs? > > > > > > > > The context: > > Lately, darcs has suffered a setback: the GHC team has decided that it > is now time to switch to a different system, like git or Mercurial. > This is probably a good thing for GHC and for us. By the way, good > luck to them, and thanks for everything! (better GHC == better darcs) > > But where is darcs going? For now, we are going to have to focus on > what we do best, providing precision merging and a consistent user > interface for small-to-medium sized projects. I want more, though! I > want to see darcs 2.1 come out next year, performance enhanced out the > wazoo, and running great on Windows. And I want to see Future Darcs, > the universal revision control system, seamlessly integrating with > everybody else. > > We need to learn to do better so that darcs can achieve this kind of > wild success. For example, whereas darcs suffers from the "day job" > problem, xmonad has had to turn developers away! > > As Don mentions, this is partly thanks to their extreme accessibility > (better self-documentation). But does anyone have more specific ideas > about things we need to change so that you can contribute to darcs? > How do we hit critical hacker mass? > > I have jotted down some other thoughts here regarding recruitment here: > http://wiki.darcs.net/index.html/Recruitment > > In the meantime, if you have been discouraged from hacking on darcs, > we want to know why, and how we can change things! > > Thanks, > _______________________________________________ > 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/20080803/21f2c379/attachment.htm From daniel.is.fischer at web.de Sun Aug 3 13:26:20 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Aug 3 13:24:11 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <42784f260808031003g4e9f26b4n88cdbd6b97102542@mail.gmail.com> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <42784f260808031001i2715ff20ra533ba6f0f591db7@mail.gmail.com> <42784f260808031003g4e9f26b4n88cdbd6b97102542@mail.gmail.com> Message-ID: <200808031926.20482.daniel.is.fischer@web.de> Am Sonntag, 3. August 2008 19:03 schrieb Jason Dusek: > So I guess the Wikipedia page has an error in it? > > http://en.wikipedia.org/wiki/Coproduct#Definition One typo, it must be f_j = f o i_j instead of f_j = i_j o f, apart from that it looks correct. Didn't go through the examples, though, there may be further mistakes. From lrpalmer at gmail.com Sun Aug 3 13:24:23 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Aug 3 13:24:12 2008 Subject: [Haskell-cafe] timing question In-Reply-To: <48959140.4020203@xs4all.nl> References: <489580DB.2020607@xs4all.nl> <1805785403.20080803143459@gmail.com> <48959140.4020203@xs4all.nl> Message-ID: <7ca3f0160808031024q745ad5c2lf40a2ddae2f37b89@mail.gmail.com> On Sun, Aug 3, 2008 at 11:06 AM, Arie Groeneveld wrote: > Sorry, should go the forum. > > Ok, thanks. In this case the list consists of 6-digit alphanumeric > codes. So doing something like: > > foldl1 (\x y -> g y) xs No, that still doesn't force elements. Let's say g is (+1): f = \x y -> (+1) y foldl1 f [1,2,3] (1 `f` 2) `f` 3 (+1) 3 4 So we don't need to compute (+1) on any numbers but 3. The most direct way is to force the elements of the list: import Control.Parallel.Strategies seqList rwhnf (map g xs) Note that the notion of "compute" in this example is to WHNF, so for example if g produces lists, it will only evaluate far enough to determine whether the list is a nil or a cons, not the whole thing. > will do the job? > > > =@@i > > > Bulat Ziganshin schreef: > >> Hello Arie, >> >> Sunday, August 3, 2008, 1:56:43 PM, you wrote: >> >> *Main>> last . f $ xs >> >> this way you will get only "spin" of list computed, not elements >> itself. something like sum should be used instead >> >> >> >> > > _______________________________________________ > 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/20080803/ee06fe99/attachment.htm From dons at galois.com Sun Aug 3 13:32:09 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 3 13:31:57 2008 Subject: [Haskell-cafe] timing question In-Reply-To: <489580DB.2020607@xs4all.nl> References: <489580DB.2020607@xs4all.nl> Message-ID: <20080803173209.GA10149@scytale.galois.com> bradypus: > Suppose I've: > > f = map g > > I want to know how much time it takes (interpreted mode) to fully > process list xs (at least 1e6 elements) with function g. Is it > sufficient to execute: > > *Main> last . f $ xs > > (x.xx secs, yyyyyyyyyyy bytes) > > Are there any hidden difficulties involved? > > Reason is: comparing timings Haskell vs an interpreted language without > laziness. > If you care about timings, it's probably a better idea to compile the code (with optimisations on), to get a better idea of what the code would do in a production environment. You could then just time the binary, main = print . sum $ .... ghc -O2 A.hs --make time ./A -- Don From andrewcoppin at btinternet.com Sun Aug 3 05:35:32 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Aug 3 13:32:59 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <30tze27k3v.fsf@Clio.twb.ath.cx> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> Message-ID: <48957BE4.90807@btinternet.com> Trent W. Buck wrote: > I don't know why, but a lot of people I spoke to seemed to have that > impression, and I essentially had to wave changelogs under their face to > convince them that darcs was still being worked on *at all*. I had to > point out that it was a *release* announcement -- how could a dead > project have a new major version? > > Perhaps a chirpy journalism major should be writing vapidly up-beat > announcement posts, denying even the possibility of problems :-P > Correct me if I'm wrong, but... I was under the impression that Darcs is a revision control system. It controls revisions. Well Darcs already does that. So... what's to develop? It's not like it's slow or buggy. I can't actually think of any features it doesn't have that I want. So... what now? In case that sounds really negative and critical, let me phrase it another way: Given that Darcs is more or less perfect now, what's to add? From jason.dusek at gmail.com Sun Aug 3 14:03:03 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Aug 3 14:02:54 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <200808031926.20482.daniel.is.fischer@web.de> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <42784f260808031001i2715ff20ra533ba6f0f591db7@mail.gmail.com> <42784f260808031003g4e9f26b4n88cdbd6b97102542@mail.gmail.com> <200808031926.20482.daniel.is.fischer@web.de> Message-ID: <42784f260808031103p49b54c9cp2d05c33e6064d1fa@mail.gmail.com> What about the part that reads: The unique arrow f making this diagram commute is then correspondingly denoted f1 ? f2 or f1 ? f2 or f1 + f2 or [f1, f2] This would seem to say that [f,g] and f+g are the same thing -- but if I've understood Derek Elkins' remarks, the latter is the functorial action on arrows while the former is just the mediating arrow. -- _jsn From simon at joyful.com Sun Aug 3 14:33:50 2008 From: simon at joyful.com (Simon Michael) Date: Sun Aug 3 14:33:55 2008 Subject: [Haskell-cafe] website update how-to In-Reply-To: <87tze2dpix.fsf@malde.org> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <877iayfa3r.fsf@malde.org> <20080803150352.GA13167@craft> <87tze2dpix.fsf@malde.org> Message-ID: Ketil Malde wrote: > (Anybody with write access to the front page who > can make a note of minimum version required to 'darcs get' the > repository?) I've submitted a patch. For reference, here's how to change the website: 0. get yourself a working darcs 2 by installing a binary or building the source tarball 1. darcs get or pull the latest darcs code 2. edit and record doc/index.html.in 3. darcs send and wait for David's review From duncan.coutts at worc.ox.ac.uk Sun Aug 3 14:50:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 3 14:50:27 2008 Subject: [Haskell-cafe] Re: Kleisli composition operator In-Reply-To: References: <200808031718.54664.daniel.is.fischer@web.de> Message-ID: <1217789446.7661.49.camel@localhost> On Sun, 2008-08-03 at 15:31 +0000, Roly Perera wrote: > Daniel Fischer web.de> writes: > > > Which implementation are you using? > > IIRC, GHC didn't have it in Control.Monad before the 6.8 branch. > > Duncan Coutts writes: > > > It's not in the Prelude but it is in ?Control.Monad in base version 3 > > and later. You're probably using an older GHC which has base version > > 2.x. > > Thanks for the quick responses. Looks like I need to install a version later > than 6.8. GHC 6.8 comes with base-3 so has ?(>=>) in Control.Monad. Duncan From mad.one at gmail.com Sun Aug 3 14:51:22 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sun Aug 3 14:51:14 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <48957BE4.90807@btinternet.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <48957BE4.90807@btinternet.com> Message-ID: <1217787447-sup-9690@existential.local> Excerpts from Andrew Coppin's message of Sun Aug 03 04:35:32 -0500 2008: > Correct me if I'm wrong, but... I was under the impression that Darcs is > a revision control system. It controls revisions. > > Well Darcs already does that. So... what's to develop? It's not like > it's slow or buggy. I can't actually think of any features it doesn't > have that I want. So... what now? > > In case that sounds really negative and critical, let me phrase it > another way: Given that Darcs is more or less perfect now, what's to add? At this point I feel it is an issue of what can be fixed rather than what can be added. The current issues with darcs right now I feel are: * Predictability. There is no such thing with darcs. If I try to get copies of the base libraries up to date in the latest GHC-head (via a ./darcs-all pull -a,) it might pull all the libraries. It might not. It might randomly stop at identifying the repository format of 'base/array.' It might get all the way to 'base/unix' and begin pulling patches before it stops. In either case, darcs never quits, I'm never sure of what state it is in during the pull and frankly I just don't know what's going on sometimes. * Usability is dodgy under high load. To date, I think GHC is the best candidate for qualifying as 'high load,' but even then I'm not sure if the comparison is quite as fair if GHC is still using an old-fashioned darcs format (i.e. darcs1-style repo.) Regardless I am still skeptical at this point of darcs ability to handle high load. * Random quirks, e.g. some file edits may unknowingly introduce an explicit dependency on patches, meanining while two patches A and B are unrelated in all forms of the word, it will still mark 'A' as dependent on 'B'. So you've basically lost the ability to unrecord flexibly, since unrecord is going to skip the patches that are marked as dependent on something else, when they really are not. Quite honestly I think darcs 2 is a fine release and a very good improvement; it fixed a lot of the older nasty quirks (exponential-time merge bug in particular) and any project considering darcs should use the new format immediately. I think for medium to small sized projects it is great. It will continue to fit those projects very well, but when push comes to shove, darcs won't cut it, I feel. To answer the question and be honest about it: I would work on darcs if I was getting paid. Darcs lost I think because of its internals, because it simply was not feasible for people to get involved and make core improvements. You basically were either David or you weren't. Other VCS's generally speaking have a lot more simple foundation: git only has only 4 base objects that you encounter every day in your workflow. These are the primitives of all operations in git, and everything else is built on top of them. Because of it, anybody with some experience in using git can probably get reasonably comfortable with the source code in a non-crazy amount of time. There is a lower barrier of entry to the source code, ideas and development process. The simpler design simply facilitates contributions where it matters, IMO. While I don't want to sound so unsupportive of the excellent work everybody involved in darcs has contributed, that is currently the way I see darcs and unless I was getting paid I would not be compelled to work on the source code as I have already moved to another system (git.) I think darcs made a landmark is usability for a DVCS, and I also think the way in which patches are managed with darcs is very nice. However, I've found git's approach sufficiently simple (to the point where my limited brain can comprehend it) and cherry-picking is a common point among version control systems these days (git add -i.) So I've found home elsewhere. Austin From allbery at ece.cmu.edu Sun Aug 3 14:56:40 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 3 14:56:34 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <7ca3f0160808031015s7333a69axa6bd844f7fe9a525@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <7ca3f0160808031015s7333a69axa6bd844f7fe9a525@mail.gmail.com> Message-ID: <1F074FA8-437B-4257-8C91-3A2116D62AA6@ece.cmu.edu> On 2008 Aug 3, at 13:15, Luke Palmer wrote: > On Fri, Aug 1, 2008 at 3:45 PM, Eric Kow wrote: > "I would contribute to darcs if only..." > > I haven't used darcs much, so it's possible that I'll be forced to > start contributing by my own binding hypothetical. > > I would contribute to darcs if only it had support / could have > support for splitting and merging repositories. For example, I Maybe that's what you should contribute. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080803/23df760b/attachment.htm From allbery at ece.cmu.edu Sun Aug 3 15:00:43 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 3 15:00:36 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <48957BE4.90807@btinternet.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <48957BE4.90807@btinternet.com> Message-ID: On 2008 Aug 3, at 5:35, Andrew Coppin wrote: > Well Darcs already does that. So... what's to develop? It's not like > it's slow or buggy. I slow: see ghc moving away from darcs. once you reach a certain number of patches, it becomes *very* slow --- even with darcs 2's speedups. buggy: there are known screw cases where darcs cannot solve the constraint problem set by certain combinations of patches. (I admit to being uncertain about the latter; it sounds to me a lot like the room scheduling problem, which is NP-complete. But I didn't get most of the fancy maths so I could well be wrong.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Sun Aug 3 15:06:58 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 3 15:06:50 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <48957BE4.90807@btinternet.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <48957BE4.90807@btinternet.com> Message-ID: On 2008 Aug 3, at 5:35, Andrew Coppin wrote: > Well Darcs already does that. So... what's to develop? It's not like > it's slow or buggy. I Oh, two more under "buggy": (a) as mentioned by others, the ghc repos often cause darcs2 to spin without doing anything. (This may secretly be the network library; strace looks an awful lot like my lambdabot when it gets stuck, but it's hard to tell because that may just be the thread scheduler.) (b) it doesn't handle the case where a file is renamed to avoid upper/ lowercase issues, on filesystems which treat them the same (Windows, OSX). It should be possible to arrange to not have both on disk at the same time. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From newsham at lava.net Sun Aug 3 15:09:30 2008 From: newsham at lava.net (Tim Newsham) Date: Sun Aug 3 15:09:18 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: <1217763787.7661.39.camel@localhost> References: <1217763787.7661.39.camel@localhost> Message-ID: > What kind of performance do you actually need? Can your network > connection actually sustain the bandwidth of your synthetic benchmarks? This is just an exercise at the moment, so no particular performance goal beyond "how fast can it go". > ?(tested using apache-bench, loopback interface, amd64 @ 2.2GHz) > ?With cached content 450k: > ??with 1 ?concurrent client: > 760 requests per second > ~1ms latency > 34Mb/s [...] > Obviously this is testing with a loopback network. My point is, it's > serving at a rather higher rate than most real network connections I > could buy (except local ethernet networks). My requests and responses are fairly small, a typical request is 29bytes and a typical response is 58bytes. If you just count these payloads its about 390kB/sec for 4.5kreq/sec and 1.2MB/sec for 13.5kreq/sec (of course its more like double these as the TCP overhead will be about the same size). Anyway, with such small sizes, the performance shouldn't be limited by the bandwidth (I dont think). If this was a back-end storage server, the network probably wouldn't be the limiting factor. > Duncan Tim Newsham http://www.thenewsh.com/~newsham/ From dagit at codersbase.com Sun Aug 3 15:47:49 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sun Aug 3 15:47:37 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <48957BE4.90807@btinternet.com> Message-ID: I've been lurking on this thread, collecting the valuable feedback. Thanks all. On Sun, Aug 3, 2008 at 12:06 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On 2008 Aug 3, at 5:35, Andrew Coppin wrote: > > Well Darcs already does that. So... what's to develop? It's not like it's >> slow or buggy. I >> > > Oh, two more under "buggy": > > (a) as mentioned by others, the ghc repos often cause darcs2 to spin > without doing anything. (This may secretly be the network library; strace > looks an awful lot like my lambdabot when it gets stuck, but it's hard to > tell because that may just be the thread scheduler.) I just want to clarify one point about darcs1 vs. darcs2. The darcs2 program works on both darcs1 and darcs2 format repositories. When it works with darcs1 format repositories it works the way darcs has always worked on darcs1 repositiories. Thus, it's not fair to say that the above problem exists in darcs2 format repositories since the GHC repository was never publicly converted to darcs2 format. So, the spinning of the darcs2 program on the GHC repository is due to flaws in darcs1 format that have hopefully all been corrected in darcs2 format. Yes, this is a known bug, but also one that has received considerable effort, and is currently presumed to be fixed for darcs2 format repositories. Bug reports and test cases to the contrary are welcome. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080803/dc0ddeaa/attachment.htm From derek.a.elkins at gmail.com Sun Aug 3 16:22:25 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Aug 3 16:22:12 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <42784f260808031103p49b54c9cp2d05c33e6064d1fa@mail.gmail.com> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <42784f260808031001i2715ff20ra533ba6f0f591db7@mail.gmail.com> <42784f260808031003g4e9f26b4n88cdbd6b97102542@mail.gmail.com> <200808031926.20482.daniel.is.fischer@web.de> <42784f260808031103p49b54c9cp2d05c33e6064d1fa@mail.gmail.com> Message-ID: <1217794946.13277.85.camel@derek-laptop> On Sun, 2008-08-03 at 11:03 -0700, Jason Dusek wrote: > What about the part that reads: > > The unique arrow f making this diagram commute is then > correspondingly denoted f1 ? f2 or f1 ? f2 or f1 + f2 or > [f1, f2] > > This would seem to say that [f,g] and f+g are the same thing > -- but if I've understood Derek Elkins' remarks, the latter is > the functorial action on arrows while the former is just the > mediating arrow. In my experience the functorial action of a functor on arrows almost always has the same symbol as the action on objects. Furthermore, I don't think I've ever seen an example where the symbol used for the action on objects was used for something other than the action on arrows. I do think I have seen examples when a different symbol was used. If A+B is used then f+g should be the action on arrows. Admittedly wikipedia does violate this. Perhaps it's using conventions from some branch that I'm not familiar with. Maybe it is just silly. "Categories for the Working Mathematician" uses the convention I describe here. Although it doesn't seem to have a notation for the mediating arrow (what I usually write as [f,g]). From duncan.coutts at worc.ox.ac.uk Sun Aug 3 16:43:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 3 16:43:28 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <1217796230.7661.77.camel@localhost> On Fri, 2008-08-01 at 16:45 +0100, Eric Kow wrote: > Dear Haskellers, > > I would like to take an informal poll for the purposes of darcs > recruitment. Could you please complete this sentence for me? > > "I would contribute to darcs if only..." > > The answers I am most interested in hearing go beyond "... I had more > time". For instance, if you are contributing to other Haskell/volunteer > projects, why are you contributing more to them, rather than darcs? It would be useful if some darcs 2 hackers, contributors could help the ghc people evaluate if darcs 2 is still in the running. That would mean identifying the key bugs (eg windows case-insensitive file bugs, slow pulls) and seeing how hard they are to fix. Also doing a test conversion to darcs 2 format and benchmarking some of the key operations described on the ghc evaluation page. http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation Duncan From lutzsteens at gmx.de Sun Aug 3 17:15:53 2008 From: lutzsteens at gmx.de (Ludger Steens) Date: Sun Aug 3 17:16:03 2008 Subject: [Haskell-cafe] Memory problems reading a IntMap from a binary file Message-ID: <48962009.7050302@gmx.de> Hi, I have IntMap String with about 40,000 entries. After saving it to disk (via Data.Binary) the file is 3.5 Mb small. However if I load it and save it back again my program needs 180 MB memory. Is there anything I do wrong or does the map really need that much memory? The (simple) program I wrote: main = do mp <- decodeFile "i.bin" :: IO ( IntMap String ) encodeFile "i2.bin" mp exitWith ExitSuccess Thanks, Ludger From jason.dusek at gmail.com Sun Aug 3 17:37:50 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Aug 3 17:37:37 2008 Subject: [Haskell-cafe] adjoint of coproduct & diagonal In-Reply-To: <1217794946.13277.85.camel@derek-laptop> References: <42784f260808021822r1937f1dajd128151669844ede@mail.gmail.com> <42784f260808031001i2715ff20ra533ba6f0f591db7@mail.gmail.com> <42784f260808031003g4e9f26b4n88cdbd6b97102542@mail.gmail.com> <200808031926.20482.daniel.is.fischer@web.de> <42784f260808031103p49b54c9cp2d05c33e6064d1fa@mail.gmail.com> <1217794946.13277.85.camel@derek-laptop> Message-ID: <42784f260808031437ld82a2d1y2b612b6f773b520b@mail.gmail.com> Derek Elkins wrote: > Jason Dusek wrote: >> What about the part that reads: >> >> The unique arrow f making this diagram commute is then >> correspondingly denoted f1 ? f2 or f1 ? f2 or f1 + f2 or >> [f1, f2] >> >> This would seem to say that [f,g] and f+g are the same thing >> -- but if I've understood Derek Elkins' remarks, the latter is >> the functorial action on arrows while the former is just the >> mediating arrow. > > In my experience the functorial action of a functor on arrows almost > always has the same symbol as the action on objects. Furthermore, I > don't think I've ever seen an example where the symbol used for the > action on objects was used for something other than the action on > arrows. I do think I have seen examples when a different symbol was > used. If A+B is used then f+g should be the action on arrows. > > Admittedly wikipedia does violate this. Perhaps it's using conventions > from some branch that I'm not familiar with. Maybe it is just silly. Indeed. Using f1 ? f2 or f1 + f2 for the mediating arrow is confusing, to say the least. -- _jsn From dons at galois.com Sun Aug 3 19:10:44 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 3 19:10:37 2008 Subject: [Haskell-cafe] Memory problems reading a IntMap from a binary file In-Reply-To: <48962009.7050302@gmx.de> References: <48962009.7050302@gmx.de> Message-ID: <20080803231044.GB10926@scytale.galois.com> lutzsteens: > Hi, > > I have IntMap String with about 40,000 entries. After saving it to disk > (via Data.Binary) the file is 3.5 Mb small. However if I load it and > save it back again my program needs 180 MB memory. Is there anything I > do wrong or does the map really need that much memory? String can be really expensive. Try an IntMap ByteString > > The (simple) program I wrote: > > main = > do > mp <- decodeFile "i.bin" :: IO ( IntMap String ) > encodeFile "i2.bin" mp > exitWith ExitSuccess > > Thanks, > Ludger > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ben.franksen at online.de Sun Aug 3 19:16:49 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 3 19:16:45 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <7ca3f0160808031015s7333a69axa6bd844f7fe9a525@mail.gmail.com> Message-ID: Luke Palmer wrote: > On Fri, Aug 1, 2008 at 3:45 PM, Eric Kow wrote: >> >> "I would contribute to darcs if only..." >> > > I haven't used darcs much, so it's possible that I'll be forced to start > contributing by my own binding hypothetical. > > I would contribute to darcs if only it had support / could have support > for > splitting and merging repositories. For example, I like to work in a big > repository of all my stuff ever, because most of the things I do rarely > exceed an experiment in one file. But once something does get big enough > to > be interesting, I want to split it off into its own repository. But > that's just the use case: doing it the git way (go through all patches, > discard irrelevant ones, filter relevant ones, thus losing all correlation > with the original repository) is not going to inspire me; I'd like to see > support for it in the beautiful patch theory. I have once proposed a scheme that would nicely solve this. The naive way to emulate your split feature would be to create a branch where you delete all the stuff you don't want and then maybe move the subproject to a new directory (nearer the top-level). This doesn't work, however, at least not in practice. This is because deletion of a file conflicts with a change to the same file which leads to a huge amount of conflicts each time you pull from the old combined repo. And the reason you get these conflicts is that in darcs a file always gets emptied before deletion, and this is because changing a file depends on its existence in the first place. I proposed to change this and allow changes to non-existing files, so called 'ghosts'. This has a number of interesting consequences, among them that you could delete as many files as you want and will never again get a conflict with changes to those files (that is, unless you explicitly 'resurrect' the ghost). Unfortunately few people (and none of the core-developers) seemed to be interested :( The small thread that developed on the darcs-users list should still be available in the archives if you are interested in the details. Cheers Ben From ben.franksen at online.de Sun Aug 3 19:20:30 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 3 19:24:52 2008 Subject: [Haskell-cafe] Re: question about "faulting in" Haskell packages ... References: <5ae4f2ba0808012337j83564ednaf80f1b3a85a7d96@mail.gmail.com> <4c88418c0808012344t78780285n61b7acbed123a8b@mail.gmail.com> <4c88418c0808012352h210ff054i7c9fd1ff24580eff@mail.gmail.com> Message-ID: david48 wrote: > for each package you have to type (*) : > > runhaskell Setup.hs configure > runhaskell Setup.hs build > sudo runhaskell Setup.hs install > > (*) sometimes it'll be Setup.lhs, I'm annoyed that it's not always the > same name, can't rely on shell history :( Same here; my solution is to always compile it using 'ghc --make Setup' (note the missing extension) and then ./Setup afterwards. Cheers Ben From allbery at ece.cmu.edu Sun Aug 3 19:32:42 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 3 19:32:31 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <7ca3f0160808031015s7333a69axa6bd844f7fe9a525@mail.gmail.com> Message-ID: On 2008 Aug 3, at 19:16, Ben Franksen wrote: > The naive way to emulate your split feature would be to create a > branch > where you delete all the stuff you don't want and then maybe move the > subproject to a new directory (nearer the top-level). This doesn't > work, > however, at least not in practice. This is because deletion of a file > conflicts with a change to the same file which leads to a huge > amount of > conflicts each time you pull from the old combined repo. And the > reason you > get these conflicts is that in darcs a file always gets emptied before > deletion, and this is because changing a file depends on its > existence in > the first place. I proposed to change this and allow changes to > non-existing files, so called 'ghosts'. This has a number of > interesting > consequences, among them that you could delete as many files as you > want > and will never again get a conflict with changes to those files > (that is, > unless you explicitly 'resurrect' the ghost). > > Unfortunately few people (and none of the core-developers) seemed to > be > interested :( The small thread that developed on the darcs-users list > should still be available in the archives if you are interested in the > details. I would suggest that they'd be more interested if you provided code; if they have no need for your proposal they're unlikely to devote time to coding it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ben.franksen at online.de Sun Aug 3 19:37:06 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 3 19:37:09 2008 Subject: [Haskell-cafe] Re: Brainstorming on how to parse IMAP References: <4895122C.7070301@complete.org> Message-ID: John Goerzen wrote: > I'm interested in writing a library to work with IMAP servers. > > I'm interested in thoughts people have on parsing libraries and methods. > I'm a huge fan of Parsec overall -- it lets me have a single-stage > parser, for instance. But it isn't sufficiently lazy for this task, and > I probably will need to deal with ByteStrings instead of Strings, since > some IMAP messages may be 30MB or more. You might be interested in Frisby: http://repetae.net/computer/frisby/ Cheers Ben From andrew.appleyard at gmail.com Sun Aug 3 19:45:22 2008 From: andrew.appleyard at gmail.com (Andrew Appleyard) Date: Sun Aug 3 19:47:48 2008 Subject: [Haskell-cafe] HDBC-ODBC linking problems in windows. In-Reply-To: <4f712c6f0808011109p3c6f2358nbb91b1c552d4cf72@mail.gmail.com> References: <4f712c6f0808011109p3c6f2358nbb91b1c552d4cf72@mail.gmail.com> Message-ID: <48964312.90001@gmail.com> Hi PJ, On 2/08/2008 4:09 AM, you wrote: > I am having issues getting hdbc/odbc working on windows. > > When using GHC, I am not able to compile a simple program. It ends up > with linker errors like > [...] > Is there an easy workaround for this? Or am I doing something wrong? > > MySetup > ======= > Windows XP SP2 > ghc 6.8.3 > hdbc 1.1.5.0 > hdbc-odbc 1.1.4.3.0 hdbc-odbc 1.1.4.4 contains a patch to the calling convention of the ODBC functions (from ccall to stdcall). Grab version 1.1.4.4 from Hackage [1] and hopefully that'll fix your problem. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-odbc Regards, Andrew From ben.franksen at online.de Sun Aug 3 20:07:18 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 3 20:07:19 2008 Subject: [Haskell-cafe] Re: Re: poll: how can we help you contribute to darcs? References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <7ca3f0160808031015s7333a69axa6bd844f7fe9a525@mail.gmail.com> Message-ID: Brandon S. Allbery KF8NH wrote: > On 2008 Aug 3, at 19:16, Ben Franksen wrote: >> The naive way to emulate your split feature would be to create a >> branch >> where you delete all the stuff you don't want and then maybe move the >> subproject to a new directory (nearer the top-level). This doesn't >> work, >> however, at least not in practice. This is because deletion of a file >> conflicts with a change to the same file which leads to a huge >> amount of >> conflicts each time you pull from the old combined repo. And the >> reason you >> get these conflicts is that in darcs a file always gets emptied before >> deletion, and this is because changing a file depends on its >> existence in >> the first place. I proposed to change this and allow changes to >> non-existing files, so called 'ghosts'. This has a number of >> interesting >> consequences, among them that you could delete as many files as you >> want >> and will never again get a conflict with changes to those files >> (that is, >> unless you explicitly 'resurrect' the ghost). >> >> Unfortunately few people (and none of the core-developers) seemed to >> be >> interested :( The small thread that developed on the darcs-users list >> should still be available in the archives if you are interested in the >> details. > > I would suggest that they'd be more interested if you provided code; > if they have no need for your proposal they're unlikely to devote time > to coding it. You are suggesting that I am expecting others to devote time to code proposals of mine. I don't know where you get this idea. I am used to discuss the merits of a new feature, especially one so far-reaching, before starting to unilaterally throw code at a project. Your own style of collaboration might be different, though. Anyway, I would suggest that you add something of interest rather than patronizing people with dubious 'suggestions'. Cheers Ben From trentbuck at gmail.com Sun Aug 3 20:21:54 2008 From: trentbuck at gmail.com (Trent W. Buck) Date: Sun Aug 3 20:22:05 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <877iayfa3r.fsf@malde.org> <20080803150352.GA13167@craft> <87tze2dpix.fsf@malde.org> Message-ID: <30ljzdaau5.fsf@Clio.twb.ath.cx> Ashley Moran writes: > On Aug 03, 2008, at 5:36 pm, Ketil Malde wrote: >> Seems I needed a newer darcs - the one shipped with Ubuntu is 1.0.9, >> which appears to be too old, and it works when I build a new 2.0.2 >> from the tarball. (Anybody with write access to the front page who >> can make a note of minimum version required to 'darcs get' the >> repository?) AFAIK, the current darcs darcs repo should be gettable with any 2.x version of darcs. Since darcs is self-hosting, you gotta expect bootstrapping issues when using older-than-the-current-release versions to checkout the repo. (Hence grabbing the source tarball.) > FYI, Iain Lane made a darcs package for 2.0.2: > https://launchpad.net/~laney/+archive You should also be able to backport it from Intrepid (Hardy+1). There may be a hardy-backports version, too, but packages.ubuntu.com won't talk to me just now. From jgoerzen at complete.org Sun Aug 3 20:56:19 2008 From: jgoerzen at complete.org (John Goerzen) Date: Sun Aug 3 20:56:14 2008 Subject: [darcs-users] [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <20080803073639.GA7215@scytale.galois.com> <0tej56jhcb.wl%bremner@pivot.cs.unb.ca> Message-ID: <489653B3.4090902@complete.org> Ashley Moran wrote: > On Aug 03, 2008, at 3:36 pm, David Bremner wrote: > >> I think this view is probably coloured by your background in web >> development. I have used git for about a year now, and never visited >> GitHub. I'm not saying you have to like git, but it does have other >> features other than a snazzy web site. > > Hi David > > I think I gave the wrong impression there. After all, I use darcs > despite it not having a snazzy website! What I mean is that git usage > has snowballed since GitHub was released, so people are clearly > attracted to the website first, and the SCM second. It's a bit like > the way Rails created thousands of Ruby programmers by association, > many of them with no idea what Ruby was all about, just a vague notion > that Rails could solve their problem. I know of exactly 0 programmers that use Git because of GitHub. I have interacted with exactly 1 project that used GitHub. I know of many, many programmers that use Git. Git people are choosing Git for other reasons. I've spelled out some of the reasons I chose it before; I could bore you with URLs if you like ;-) Git is a really nice DVCS. That has nothing to do with the presence of one particular website. > I tend to very stubbornly work the other way... choose the tool I > think works best with very little regard for its momentum, unless of > course it clearly has none. Hence my love of darcs and recent > interest in Haskell. (I'll figure it out, one day!) Haskell has momentum, I swear! > There's also discussion on darcs-users that a Haskell implementation > of Git would finally settle the "Haskell is too slow" debate. Now I > think if the world is going to use git, a better implementation would > be a good thing (I know a developer who got VERY frustrated trying to > program against it). Personally I think the developer time would be > better invested in fixing darcs bugs and improving its performance. Yes, I am not sure the world needs a reimplemented Git. As a user, I would say, "what's the benefit?" I don't see one. That's an awful lot of work. As a developer, yes Git's internals are, shall we say, inconsistent. But what do I care? Git's interface is a shell tool, and I can use any programming language I want to work with it. I've already done so with sh, Haskell, and (ugh) Ruby. -- John From jgoerzen at complete.org Sun Aug 3 20:57:57 2008 From: jgoerzen at complete.org (John Goerzen) Date: Sun Aug 3 20:57:52 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <48957BE4.90807@btinternet.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> <48957BE4.90807@btinternet.com> Message-ID: <48965415.50004@complete.org> Andrew Coppin wrote: > Trent W. Buck wrote: >> I don't know why, but a lot of people I spoke to seemed to have that >> impression, and I essentially had to wave changelogs under their face to >> convince them that darcs was still being worked on *at all*. I had to >> point out that it was a *release* announcement -- how could a dead >> project have a new major version? >> >> Perhaps a chirpy journalism major should be writing vapidly up-beat >> announcement posts, denying even the possibility of problems :-P >> > > Correct me if I'm wrong, but... I was under the impression that Darcs is > a revision control system. It controls revisions. > > Well Darcs already does that. So... what's to develop? It's not like > it's slow or buggy. I can't actually think of any features it doesn't > have that I want. So... what now? Erm, actually it is. Both. Well, at least the slow bit is still quite there in 2.0, though better. The IndempotentMerge problem? I guess it sounds like this is better in 2.0, though not completely fixed. I still laugh when I remember droundy telling me something along the lines of, "No, that is NOT an infinite loop. It will finish in a couple of weeks." -- John From vigalchin at gmail.com Mon Aug 4 01:32:13 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Aug 4 01:32:01 2008 Subject: [Haskell-cafe] your RSA code Message-ID: <5ae4f2ba0808032232s4efe0ff1lc7574d454efcefb9@mail.gmail.com> Hi John, I am reading your RSA code as suggested. 1) Do you have an example code that uses your RSA API? 2) a ForeignPtr is created in function createPkey and "returned" to the caller. I am trying to follow which function(s) GC the associated heap. ?? 3) My assertion: It seems in my Posix asynch IO case ... that functions like aioRead, aioWrite, lioListIO would create ForeignPtrs that would "carried around in the AIO application and the associated heap would only be GC'd (garbage collected) when aioReturn or aio_Cancel get called. True? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080804/eb63c475/attachment.htm From ketil at malde.org Mon Aug 4 05:44:50 2008 From: ketil at malde.org (Ketil Malde) Date: Mon Aug 4 05:44:34 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <1217796230.7661.77.camel@localhost> (Duncan Coutts's message of "Sun\, 03 Aug 2008 21\:43\:50 +0100") References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> Message-ID: <87k5exazcd.fsf@malde.org> Duncan Coutts writes: > It would be useful if some darcs 2 hackers, contributors could help the > ghc people evaluate if darcs 2 is still in the running. This looks like a very easy and low-investement way to get involved. Expanding a bit on this: The page at asks for people to hammer the hashed and darcs-2 repo formats. While I haven't really had any trouble with the old darcs-1 format, I can still experiment a bit. However, the page looks to be a bit stale, can somebody in the know look over it and update it so that it is current? It'd be nice if there were some suggestions or a 'howto' on how to go about testing. Anyway, I just want to say that I really enjoy using darcs, and in addition to being a really nice and easy to use VCS, it is also a high-profile Haskell project with substantial PR value. If we really want Haskell to fail in attaining its goal of not attaining popularty, darcs is an important piece. -k -- If I haven't seen further, it is by standing in the footprints of giants From Malcolm.Wallace at cs.york.ac.uk Mon Aug 4 06:10:42 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Aug 4 06:11:08 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP In-Reply-To: <4895122C.7070301@complete.org> References: <4895122C.7070301@complete.org> Message-ID: <20080804111042.3aeacf89.Malcolm.Wallace@cs.york.ac.uk> > 1) Ideally I could parse stuff lazily. I have tried this with FTP and > it is more complex than it seems at first, due to making sure you > never, never, never consume too much data. PolyParse has lazy variants of its combinators, which would probably be of use here. Software: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/polyparse Paper: http://www-users.cs.york.ac.uk/~malcolm/partialparse.html > 2) Avoiding Strings wherever possible. PolyParse is completely independent of token type. There is a rudimentary module implementing the combinators on top of ByteString. (Not currently exposed in the package interface, BTW.) I'm sure it would not be difficult to build on top of LazyByteString also. Patches gratefully accepted. > 3) Avoiding complex buffering schemes where I have to manually buffer > data packets. Provided the parser is lazy enough, the buffering would be done at the level of Lazy ByteString (but I don't know whether LBS is suitable for network-reading or not). > Thoughts and ideas? > A283 SEARCH {4} {21} > TEXTstring not in mailbox Assuming the first line can be read strictly, and the remainder should be lazy, the parser might look something like this: searchResult = do n <- qnumber word "SEARCH" extents <- many1 (braces number) return SearchResult n `apply` (mapAF (\m-> exactly m char) extents) where -- embed map in an applicative functor mapAF :: (a -> Parser b) -> [a] -> Parser [b] mapAF p [] = return [] mapAF p (x:xs) = return (:) `apply` p x `apply` mapAF p xs Regards, Malcolm From gue.schmidt at web.de Mon Aug 4 05:47:46 2008 From: gue.schmidt at web.de (=?UTF-8?B?R8O8wp9udGhlciBTY2htaWR0?=) Date: Mon Aug 4 06:39:53 2008 Subject: [Haskell-cafe] ActiveX and COM Message-ID: Hi, what is currently the recommend way to interface with COM from haskell? I need to create an Excel Sheet and thus need to use Excel via COM. G?nther From wferi at niif.hu Mon Aug 4 07:04:35 2008 From: wferi at niif.hu (Ferenc Wagner) Date: Mon Aug 4 07:04:28 2008 Subject: [Haskell-cafe] Re: [darcs-users] poll: how can we help you contribute to darcs? In-Reply-To: <48937862.5060500@freegeek.org> (wren ng thornton's message of "Fri, 01 Aug 2008 16:56:02 -0400") References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <48937862.5060500@freegeek.org> Message-ID: <877iaxkpmk.fsf@tac.ki.iif.hu> wren ng thornton writes: > [Bug trackers are an excellent source of tasks for active developers to > use so things don't get lost, but they're awful for new developers. For > someone just joining the project it's rarely clear how important a task > is, how hard, or how far reaching its consequences (or whether someone's > already working on it). Good trackers have fields to note these things, > but the notes are engineered for active developers; the extent to which > those notes are even used or accurate varies wildly from project to > project. Hence, having a clear discussion about what things really are > important and how much they interact with everything else is a great boon.] Agreed. In short, shouldn't Darcs come up with sth like http://wiki.winehq.org/JanitorialProjects or http://janitor.kernelnewbies.org/ perhaps? And of course with some serious up-to-date documentation on the theory behind Darcs. AFAIK Ian Lynagh started working on one. I'd say: first be precise. Don't be afraid of abstract algebra, it's university material, quite some people actually understands it. And those can later explain the hard to grasp parts. But I never felt like diving into the bunch of hazy metaphors I found about the inner workings of Darcs, even though I was and still am interested. So I nevert felt qualified to touch anything important or assess the performance problems for example. -- Cheers, Feri. From david.waern at gmail.com Mon Aug 4 07:43:23 2008 From: david.waern at gmail.com (David Waern) Date: Mon Aug 4 07:43:11 2008 Subject: [Haskell-cafe] ANN: Haddock version 2.2.1 In-Reply-To: References: Message-ID: -------------------------------------------- -- Haddock 2.2.1 -------------------------------------------- A new version of Haddock, the Haskell documentation tool, is out. The homepage will be updated soon, containing a windows binary release. Please use the bug tracker to submit bug reports and feature requests. -------------------------------------------- -- Changes since version 2.1.0 -------------------------------------------- * Support for GHC 6.8.3 * The Hoogle backend is back * Show associated types in the documentation for class declarations * Show type family declarations * Show type equality predicates * Major bug fixes (#1 and #44) * It is no longer required to specify the path to GHC's lib dir * Remove unnecessary parenthesis in type signatures * Minor bug fixes -------------------------------------------- -- Links -------------------------------------------- Homepage: http://www.haskell.org/haddock Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1 Bugtracker and wiki: http://trac.haskell.org/haddock Mailing list: haskelldoc@haskell.org Code repository: http://code.haskell.org/haddock -------------------------------------------- -- Details -------------------------------------------- This release contains experimental and incomplete support for GHC's Type Families extension. We have basic support for rendering of type family declarations and associated types in the documentation. Type/Data instances are not shown in the documentation at all, and associated types are not shown for class instances. Feedback is appreciated, especially for ideas of how to render type family instances. Use either the bugtracker, or send a mail to the mailing list. We have also got the Hoogle backend back, thanks to Neil Mitchell! The plan is to be compatible with the upcoming pre-release of Hoogle 4, which is being developed by Neil as a Summer of Code project. -------------------------------------------- -- Get Involved -------------------------------------------- Haddock is an important project, as it is part of the Haskell infrastructure core. The code base is gradually becoming easier to read, better documented and more stable, but more work is needed. To get involved, start by grabbing the code at http://code.haskell.org/haddock then take a look at the bug and feature tracker at http://trac.haskell.org/haddock for things to work on. David From quarantedeux42 at yahoo.fr Mon Aug 4 08:14:19 2008 From: quarantedeux42 at yahoo.fr (Fernand) Date: Mon Aug 4 08:14:10 2008 Subject: [Haskell-cafe] ActiveX and COM In-Reply-To: References: Message-ID: <4896F29B.7030304@yahoo.fr> G??nther Schmidt ?????: > Hi, > > what is currently the recommend way to interface with COM from haskell? > > I need to create an Excel Sheet and thus need to use Excel via COM. > > G?nther You have the HDirect package, you need some tweaking to compile it with the current GHC. I only have a professionnal access to a Windows box, so I have no time to work on an official patch. You may contact me by e-mail, and I'll send you my patched version of the library and some instruction on how to build something that should be workable. If you need to simply create and Excel Sheet, you may also try it using the new Microsoft XML format (it will only work with Office 2007, though) ; then you do not need COM. Sincerely yours, Fernand From bit at mutantlemon.com Mon Aug 4 08:50:04 2008 From: bit at mutantlemon.com (Bit Connor) Date: Mon Aug 4 08:49:49 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> Message-ID: <6205bd290808040550n7b4a3d8fn3b0bb37973b54262@mail.gmail.com> What about the idea of creating a GUI interface to darcs? I love the command line as much as the next guy, but I think darcs could really benefit from a polished GUI. I used tortoise darcs on a small project a while ago and it was pretty nice, but I think there is potential for much better. I think that if darcs had a usable GUI then it would be a great advantage over other its competitors and it could tremendously increase its user base. I have been thinking about making a gtk2hs darcs frontend for a while now, what does everyone think about this? On Fri, Aug 1, 2008 at 6:45 PM, Eric Kow wrote: > Dear Haskellers, > > I would like to take an informal poll for the purposes of darcs > recruitment. Could you please complete this sentence for me? > > "I would contribute to darcs if only..." > > The answers I am most interested in hearing go beyond "... I had more > time". For instance, if you are contributing to other Haskell/volunteer > projects, why are you contributing more to them, rather than darcs? > > > > > > > > The context: > > Lately, darcs has suffered a setback: the GHC team has decided that it > is now time to switch to a different system, like git or Mercurial. > This is probably a good thing for GHC and for us. By the way, good > luck to them, and thanks for everything! (better GHC == better darcs) > > But where is darcs going? For now, we are going to have to focus on > what we do best, providing precision merging and a consistent user > interface for small-to-medium sized projects. I want more, though! I > want to see darcs 2.1 come out next year, performance enhanced out the > wazoo, and running great on Windows. And I want to see Future Darcs, > the universal revision control system, seamlessly integrating with > everybody else. > > We need to learn to do better so that darcs can achieve this kind of > wild success. For example, whereas darcs suffers from the "day job" > problem, xmonad has had to turn developers away! > > As Don mentions, this is partly thanks to their extreme accessibility > (better self-documentation). But does anyone have more specific ideas > about things we need to change so that you can contribute to darcs? > How do we hit critical hacker mass? > > I have jotted down some other thoughts here regarding recruitment here: > http://wiki.darcs.net/index.html/Recruitment > > In the meantime, if you have been discouraged from hacking on darcs, > we want to know why, and how we can change things! > > Thanks, > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From claus.reinke at talk21.com Mon Aug 4 09:37:37 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Aug 4 09:37:26 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> Message-ID: <017b01c8f637$43c1aee0$05347ad5@cr3lt> > It would be useful if some darcs 2 hackers, contributors could help the > ghc people evaluate if darcs 2 is still in the running. That would mean > identifying the key bugs (eg windows case-insensitive file bugs, slow > pulls) and seeing how hard they are to fix. Also doing a test conversion > to darcs 2 format and benchmarking some of the key operations described > on the ghc evaluation page. > > http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation I think Simon Marlow has been running a converted ghc repo for a while, reporting performance and other issues arising; he even put up a fixed darcs 2 binary for windows. One thing I have been wondering about, assuming that darcs 2 (with darcs 2 format) really fixes the bugs that make darcs 1 such a headache with ghc, so that performance on large repos would be the major remaining hurdle, is this: - according to specs, all darcs repos are equal, patches have no particular order, other than calculated dependencies, and versions are just sets of patches - in practice, major projects tend to have a reference repo, and lots of developer or branch repos; in the ghc case, any successful patch ultimately makes it into the main repo and is pulled from there into every other repo (some of which might have the patch already) Could darcs 2 performance be improved by making use of the order of patches in the reference repo, to identify reference versions and reign in exponential permutation issues? In other words, all repos are equal, all patches are equal, but once a patch has made the roundtrip through the reference repo, it i Claus From claus.reinke at talk21.com Mon Aug 4 09:39:44 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Aug 4 09:39:33 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com><1217796230.7661.77.camel@localhost> <017b01c8f637$43c1aee0$05347ad5@cr3lt> Message-ID: <017f01c8f637$8f9cef00$05347ad5@cr3lt> > Could darcs 2 performance be improved by making use of the > order of patches in the reference repo, to identify reference > versions and reign in exponential permutation issues? In other > words, all repos are equal, all patches are equal, but once a patch has made the > roundtrip through the reference repo, it i s more than equal - there would be unlocated and located (wrt to the reference repo) patches. Claus From olivier.boudry at gmail.com Mon Aug 4 10:19:21 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Mon Aug 4 10:19:07 2008 Subject: [Haskell-cafe] ActiveX and COM In-Reply-To: <4896F29B.7030304@yahoo.fr> References: <4896F29B.7030304@yahoo.fr> Message-ID: On Mon, Aug 4, 2008 at 2:14 PM, Fernand wrote: > If you need to simply create and Excel Sheet, you may also try it using the > new Microsoft XML format (it will only work with Office 2007, though) ; then > you do not need COM. > > Sincerely yours, > > Fernand Hi Fernand and G?nther, A few month ago I wrote some haskell to parse an XML document and create an Excel XML document from the data. I just pasted the code here: http://hpaste.org/9381 I'm using Excel 2003 and it works with XML. Best regards, Olivier. From olivier.boudry at gmail.com Mon Aug 4 10:47:27 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Mon Aug 4 10:47:12 2008 Subject: [Haskell-cafe] ActiveX and COM In-Reply-To: References: <4896F29B.7030304@yahoo.fr> Message-ID: Ooops, I just realized that hpaste truncated my source file at 5k (it's 8k long). Unfortunately the Excel file creation code is in the truncated part of the file ;-) So if you are interested in getting the full source, just ask. From zooko at zooko.com Mon Aug 4 11:13:51 2008 From: zooko at zooko.com (zooko) Date: Mon Aug 4 11:14:00 2008 Subject: [darcs-users] [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <42784f260808021826q7b79951fkde63b5b46ce798f4@mail.gmail.com> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <42784f260808021826q7b79951fkde63b5b46ce798f4@mail.gmail.com> Message-ID: On Aug 2, 2008, at 19:26 PM, Jason Dusek wrote: > Eric Kow wrote: >> "I would contribute to darcs if only..." > > ...there were interest in binary file handling. I'm interested in binary file handling. But what do you mean -- do you want darcs to do some kind of binary deltas and then merge them? Sounds crazy. Or do you just want it to be efficient in time and space to hurl big files around without applying patches to binaries? By the way, one of the things that intrigues me is that the best open source compression tool out there is written in Haskell: https://haskell.org/bz There might be some interesting advantages that a revision control tool could gain with the use of a good compression tool like that... Regards, Zooko From allbery at ece.cmu.edu Mon Aug 4 11:47:20 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 4 11:47:07 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP In-Reply-To: <20080804111042.3aeacf89.Malcolm.Wallace@cs.york.ac.uk> References: <4895122C.7070301@complete.org> <20080804111042.3aeacf89.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <25A30F50-F789-4078-BDB7-8C8077BC7473@ece.cmu.edu> On 2008 Aug 4, at 6:10, Malcolm Wallace wrote: >> A283 SEARCH {4} {21} >> TEXTstring not in mailbox > > Assuming the first line can be read strictly, and the remainder should > be lazy, the parser might look something like this: FWIW, the actual data looks more like A283 SEARCH {4} TEXT {21} string not in mailbox (the literal declaration is followed immediately by CRLF, the literal, CRLF, then the command line context resumes) also, literals require multiple exchanges with the server unless the LITERAL+ extension is present and being used ({4+} instead of {4}). -- 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 bulat.ziganshin at gmail.com Mon Aug 4 11:31:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Aug 4 12:22:15 2008 Subject: [darcs-users] [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <42784f260808021826q7b79951fkde63b5b46ce798f4@mail.gmail.com> Message-ID: <633702461.20080804193136@gmail.com> Hello zooko, Monday, August 4, 2008, 7:13:51 PM, you wrote: > By the way, one of the things that intrigues me is that the best open > source compression tool out there is written in Haskell: > https://haskell.org/bz > There might be some interesting advantages that a revision control > tool could gain with the use of a good compression tool like that... 1. it is most efficient around all programs around, either open-source or commercial: http://www.maximumcompression.com/data/summary_mf2.php#data 2. compression libs used in freearc all written in C++. the only good thing is that i provide Haskell interface to these libs: http://haskell.org/haskellwiki/Library/Compression it really may be good idea to use, say, grzip instead of bzip2 to compress patch files, but i don't think this is highly important. at least interface is simple -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jason.dusek at gmail.com Mon Aug 4 13:00:55 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Aug 4 13:00:40 2008 Subject: [darcs-users] [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <42784f260808021826q7b79951fkde63b5b46ce798f4@mail.gmail.com> Message-ID: <42784f260808041000u70591bd5x481bfe9373d15a95@mail.gmail.com> zooko wrote: > Jason Dusek wrote: > > Eric Kow wrote: > > > > > > "I would contribute to darcs if only..." > > > > ...there were interest in binary file handling. > > ...what do you mean -- do you want darcs to do some kind of > binary deltas and then merge them? Sounds crazy. Or do you > just want it to be efficient in time and space to hurl big > files around without applying patches to binaries? I don't see how you can be efficient in space without doing binary deltas, but I don't care for binary merging (mergelets, anyone?). -- _jsn From Christian.Maeder at dfki.de Mon Aug 4 13:32:13 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Aug 4 13:31:56 2008 Subject: [Haskell-cafe] Re: ANN: Haddock version 2.2.1 In-Reply-To: References: Message-ID: <48973D1D.6010406@dfki.de> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1 depends on ghc-paths http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.2 ghc-paths failed for me with: Setup.hs:7:7: Could not find module `Distribution.Simple.PackageIndex': I've ghc-6.8.3 and Cabal-1.2.4.0 Can haddock-2.2.1 replace may old haddock-0.8 (or haddock-0.9)? Cheers Christian David Waern wrote: > -------------------------------------------- > -- Haddock 2.2.1 > -------------------------------------------- > > A new version of Haddock, the Haskell documentation tool, is out. > > The homepage will be updated soon, containing a windows binary release. > > Please use the bug tracker to submit bug reports and feature requests. > > -------------------------------------------- > -- Changes since version 2.1.0 > -------------------------------------------- > > * Support for GHC 6.8.3 > > * The Hoogle backend is back > > * Show associated types in the documentation for class declarations > > * Show type family declarations > > * Show type equality predicates > > * Major bug fixes (#1 and #44) > > * It is no longer required to specify the path to GHC's lib dir > > * Remove unnecessary parenthesis in type signatures > > * Minor bug fixes > > -------------------------------------------- > -- Links > -------------------------------------------- > > Homepage: > http://www.haskell.org/haddock > > Hackage page: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1 > > Bugtracker and wiki: > http://trac.haskell.org/haddock > > Mailing list: > haskelldoc@haskell.org > > Code repository: > http://code.haskell.org/haddock > > -------------------------------------------- > -- Details > -------------------------------------------- > > This release contains experimental and incomplete support for GHC's > Type Families extension. We have basic support for rendering of type > family declarations and associated types in the documentation. > Type/Data instances are not shown in the documentation at all, and > associated types are not shown for class instances. Feedback is > appreciated, especially for ideas of how to render type family > instances. Use either the bugtracker, or send a mail to the mailing > list. > > We have also got the Hoogle backend back, thanks to Neil Mitchell! The > plan is to be compatible with the upcoming pre-release of Hoogle 4, > which is being developed by Neil as a Summer of Code project. > > -------------------------------------------- > -- Get Involved > -------------------------------------------- > > Haddock is an important project, as it is part of the Haskell > infrastructure core. The code base is gradually becoming easier to > read, better documented and more stable, but more work is needed. To > get involved, start by grabbing the code at > > http://code.haskell.org/haddock > > then take a look at the bug and feature tracker at > > http://trac.haskell.org/haddock > > for things to work on. > > David From gwern0 at gmail.com Mon Aug 4 13:48:04 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon Aug 4 13:48:09 2008 Subject: [Haskell-cafe] Re: ANN: Haddock version 2.2.1 In-Reply-To: <48973D1D.6010406@dfki.de> References: <48973D1D.6010406@dfki.de> Message-ID: <20080804174804.GA11112@craft> On 2008.08.04 19:32:13 +0200, Christian Maeder scribbled 3.0K characters: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1 > depends on ghc-paths > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.2 > ghc-paths failed for me with: > > Setup.hs:7:7: > Could not find module `Distribution.Simple.PackageIndex': > > I've ghc-6.8.3 and Cabal-1.2.4.0 > > Can haddock-2.2.1 replace may old haddock-0.8 (or haddock-0.9)? > > Cheers Christian ghc-paths is very picky about its cabal version. Apparently Cabal 1.4.x works; you can get it from darcs at (dunno about any packages). -- gwern monarchist emc Taiwan SIGDASYS ation HRT SURSAT GNU OPS Ingram -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080804/5bb61133/attachment.bin From pjdtech2000 at gmail.com Mon Aug 4 13:54:24 2008 From: pjdtech2000 at gmail.com (PJ Durai) Date: Mon Aug 4 13:54:09 2008 Subject: [Haskell-cafe] HDBC-ODBC linking problems in windows. In-Reply-To: <48964312.90001@gmail.com> References: <4f712c6f0808011109p3c6f2358nbb91b1c552d4cf72@mail.gmail.com> <48964312.90001@gmail.com> Message-ID: <4f712c6f0808041054r323a7753ted4c1be8edb3883d@mail.gmail.com> On 8/3/08, Andrew Appleyard wrote: > Hi PJ, > > On 2/08/2008 4:09 AM, you wrote: > > I am having issues getting hdbc/odbc working on windows. > > > > When using GHC, I am not able to compile a simple program. It ends up > > with linker errors like > > [...] > > Is there an easy workaround for this? Or am I doing something wrong? > > > > MySetup > > ======= > > Windows XP SP2 > > ghc 6.8.3 > > hdbc 1.1.5.0 > > hdbc-odbc 1.1.4.3.0 > > > > hdbc-odbc 1.1.4.4 contains a patch to the calling convention of the ODBC > functions (from ccall to stdcall). > > Grab version 1.1.4.4 from Hackage [1] and hopefully that'll fix your > problem. > > [1] > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-odbc That works ! Thanks. From Christian.Maeder at dfki.de Mon Aug 4 14:47:12 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Aug 4 14:46:56 2008 Subject: [Haskell-cafe] Re: ANN: Haddock version 2.2.1 In-Reply-To: <20080804174804.GA11112@craft> References: <48973D1D.6010406@dfki.de> <20080804174804.GA11112@craft> Message-ID: <48974EB0.9050704@dfki.de> Right, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.4.0.1 works. It seems that the dependencies for ghc-paths could be improved. Thanks Christian Gwern Branwen wrote: > On 2008.08.04 19:32:13 +0200, Christian Maeder scribbled 3.0K characters: >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.2.1 >> depends on ghc-paths >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.2 >> ghc-paths failed for me with: >> >> Setup.hs:7:7: >> Could not find module `Distribution.Simple.PackageIndex': >> >> I've ghc-6.8.3 and Cabal-1.2.4.0 >> >> Can haddock-2.2.1 replace may old haddock-0.8 (or haddock-0.9)? I'm still struggling with this point. haddock-0.8 accepted the same file multiple times and several Main modules. >> >> Cheers Christian > > ghc-paths is very picky about its cabal version. Apparently Cabal 1.4.x works; you can get it from darcs at (dunno about any packages). > > -- > gwern > monarchist emc Taiwan SIGDASYS ation HRT SURSAT GNU OPS Ingram From brianh at metamilk.com Mon Aug 4 14:51:27 2008 From: brianh at metamilk.com (Brian Hulley) Date: Mon Aug 4 14:50:51 2008 Subject: [Haskell-cafe] Capitalization and associated type families Message-ID: <48974FAF.6050607@metamilk.com> Hi, I'm familiar with the capitalization rules for identifiers in Haskell and know that they are very useful and practical e.g. by allowing variables to be distinguished from "constants" in patterns etc. However I'm trying to understand on a much deeper level whether or not they can really be justified and indeed if there is a danger that they can lead to inconsistency in the light of future extensions to the language. For example, why is there any distinction between a type "variable" and a type "constant"? To make this clearer consider the type of (map): (a -> b) -> List a -> List b (ignoring the special [] syntax for list types which would just confuse the issue here). With explicit quantifiers, we'd write: forall a b. (a -> b) -> List a -> List b Now this begs the question: why does "List" need to start with a capital? (supposing that quantifiers were always written explicitly) The same distinction between "constants" and "variables" is also used in predicate logic e.g. On(x, Table) & Colour(x, Red) but similarly the above could surely be written just as easily by: exists x. on(x, table) & colour(x, red) where (on), (table), (colour), and (red) are just considered to be variables that have already been introduced (by some enclosing scope) instead of having to think of them as "constants" and make a distinction between "constant" and "variable". Anyway to get to the point of this post what I'm really trying to find is some explanation of why there is the concept of "constant" as opposed to "variable" or whether this concept is now redundant in the light of lexical scoping/ explicit quantification? Somewhat related to this issue is the syntax of associated type families. For example in section 5.2.2 of http://www.haskell.org/haskellwiki/GHC/Indexed_types there is the example: class C a b where data T a which raises in my mind several questions: 1) Why is (T) given a parameter? I.e. why does an associated type declared inside a class decl not automatically get all the parameters of the class passed to it so that one would just write: class C a b where data T f :: T -> T === data family T a b class C a b where ... f :: T a b -> T a b 2) Compare: class C a b t | a b -> t with class C a b where data T In other words, why is (T) a "constant" when it is declared inside the class but a "variable" when passed as a parameter? Is the fact that (T) needs to be given a parameter even when it is declared inside the "scope" of the class type parameters the result of needing to fulfill the idea of "constant" vs "variable"? 3) In the syntax: class C a b data T a it seems rather odd that the "a" in "T a" should be related to the "a" in "C a b" since one might expect that the name chosen for a parameter should be local to the data decl. Apologies for such a rambling post. I've spent literally at least 6 months scouring the internet trying to find a real discussion about capitalization rules because I'm trying to answer the following question: if I make use of a similar capitalization rule in my own language, can I guarantee that this rule will not lead to an inconsistency at some future point? Ie is there a real rock solid theoretical basis for making a distinction between "constants" and "variables" that holds even in the presence of lexical scoping? Thanks, Brian. From jonathanccast at fastmail.fm Mon Aug 4 15:04:21 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Aug 4 15:05:43 2008 Subject: [Haskell-cafe] Capitalization and associated type families In-Reply-To: <48974FAF.6050607@metamilk.com> References: <48974FAF.6050607@metamilk.com> Message-ID: <1217876661.29128.11.camel@jcchost> On Mon, 2008-08-04 at 19:51 +0100, Brian Hulley wrote: > Hi, > I'm familiar with the capitalization rules for identifiers in Haskell > and know that they are very useful and practical e.g. by allowing > variables to be distinguished from "constants" in patterns etc. > > However I'm trying to understand on a much deeper level whether or not > they can really be justified and indeed if there is a danger that they > can lead to inconsistency in the light of future extensions to the language. > > For example, why is there any distinction between a type "variable" and > a type "constant"? > > To make this clearer consider the type of (map): > > (a -> b) -> List a -> List b > > (ignoring the special [] syntax for list types which would just confuse > the issue here). > > With explicit quantifiers, we'd write: > > forall a b. (a -> b) -> List a -> List b > > Now this begs the question: why does "List" need to start with a > capital? (supposing that quantifiers were always written explicitly) AFAIK, it doesn't; the variable/constant distinction is just there to let the implementation put the foralls in for you. Similarly, if we had explicit foralls on equations, we could say forall n x xn. drop (n+1) (x:xn) = drop n xn but forall n. drop n nil = nil and it would be perfectly clear that `nil' in the latter case was a constructor. Of course, if you want to introduce this rule, you'd better start out with it and be consistent --- require every variable to be explicitly brought into scope. I think you'd find it pretty annoying after trying to program in your new language for a while, though. jcc From gwern0 at gmail.com Mon Aug 4 15:52:04 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon Aug 4 15:53:16 2008 Subject: [Haskell-cafe] Re: ANN: Haddock version 2.2.1 In-Reply-To: <48974EB0.9050704@dfki.de> References: <48973D1D.6010406@dfki.de> <20080804174804.GA11112@craft> <48974EB0.9050704@dfki.de> Message-ID: <20080804195204.GA12968@craft> On 2008.08.04 20:47:12 +0200, Christian Maeder scribbled 1.1K characters: > Right, > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.4.0.1 > works. > > It seems that the dependencies for ghc-paths could be improved. > > Thanks Christian Yes, I emailed Marlow suggesting that yesterday. (Or perhaps it was the day before.) -- gwern Firewalls CAVE Richard Croatian Honduras WAS AKR 701 hrt varon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080804/542d53b8/attachment.bin From icfp.publicity at googlemail.com Mon Aug 4 17:43:48 2008 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Mon Aug 4 17:43:36 2008 Subject: [Haskell-cafe] ICFP08 Call for Participation Message-ID: <53ff55480808041443s74abdbf0w4ffd04dd9265f14e@mail.gmail.com> ===================================================================== Call for Participation The 13th ACM SIGPLAN International Conference on Functional Programming (ICFP 2008) http://www.icfpconference.org/icfp2008 Victoria, BC, Canada, 22-24 September 2008 ===================================================================== ICFP 2008 provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Preliminary program: * http://www.icfpconference.org/icfp2008/schedule.html * Invited speakers: + Butler Lampson, Microsoft Research; Lazy and Speculative Execution in Computer Systems + Olivier Danvy, University of Aarhus; Defunctionalized Interpreters for Higher-Order Languages + Mark Jones, Portland State University; Polymorphism and Page Tables -- Systems Programming From a Functional Programmer's Perspective Schedule including related workshops: * Sep 20: ACM SIGPLAN Workshop on Generic Programming * Sep 20: ACM SIGPLAN Workshop on Mechanizing Metatheory * Sep 20: ACM SIGPLAN Workshop on Scheme and Functional Programming * Sep 21: ACM SIGPLAN Workshop on ML * Sep 21: ACM SIGPLAN Functional and Declarative Programming in Education * Sep 22-24: ICFP08 * Sep 25: ACM SIGPLAN Haskell Symposium * Sep 25: Functional Programming Developer Tracks * Sep 26: Commercial Users of Functional Programming * Sep 27: ACM SIGPLAN Erlang Workshop * Sep 27: Functional Programming Developer Tracks Registration information: * http://www.regmaster.com/conf/icfp2008.html * Early registration deadline: August 20, 2008 Conference hotel accommodation information: * http://www.deltahotels.com/groups/online/VIC/acm.php * Conference rate deadline: August 18, 2008 * Wiki page to coordinate room-sharing: http://www.icfpconference.org/pmwiki/pmwiki.php?n=Main.ICFP08RoomShare Conference organizers: * General Chair: James Hook (Portland State University) * Program Chair: Peter Thiemann (Universit?t Freiburg) * Local Arrangements Chair: George Tzanetakis (University of Victoria) * Workshop Co-Chairs: Michael Sperber (DeinProgramm) and Graham Hutton (University of Nottingham) * Programming Contest Co-Chairs: John Reppy (University of Chicago) and Tim Sheard (Portland State University) * Publicity Chair: Matthew Fluet (Toyota Technological Institute at Chicago) From brianh at metamilk.com Mon Aug 4 18:04:40 2008 From: brianh at metamilk.com (Brian Hulley) Date: Mon Aug 4 18:04:03 2008 Subject: [Haskell-cafe] Capitalization and associated type families In-Reply-To: <1217876661.29128.11.camel@jcchost> References: <48974FAF.6050607@metamilk.com> <1217876661.29128.11.camel@jcchost> Message-ID: <48977CF8.4020503@metamilk.com> Jonathan Cast wrote: > On Mon, 2008-08-04 at 19:51 +0100, Brian Hulley wrote: >> For example, why is there any distinction between a type "variable" and >> a type "constant"? >> >> forall a b. (a -> b) -> List a -> List b >> >> Now this begs the question: why does "List" need to start with a >> capital? (supposing that quantifiers were always written explicitly) > > AFAIK, it doesn't; the variable/constant distinction is just there to > let the implementation put the foralls in for you. Hi Jonathan - thanks - this confirms what I've been thinking. However consider: class Foo a where f :: a -> b -> (a, b) Here there is no capitalization distinction in the type of (f) but the implementation can still insert the "forall b." since (a) is already in scope. Therefore similarly, if type constructors like "List" were instead written using lowercase, since they would already be in scope it would be clear even without explicit quantifiers that (a) and (b), but not (list), were to be quantified in the type of (map) (assuming of course that there was no top level data decl for (a) or (b)). > Similarly, if we had > explicit foralls on equations, we could say > > forall n x xn. drop (n+1) (x:xn) = drop n xn > > but > > forall n. drop n nil = nil > > and it would be perfectly clear that `nil' in the latter case was a > constructor. Actually I quite like the above because it shows that pattern matching can be understood in terms of universally quantified predicates. Regarding the verbosity, patterns are something of a special case since variables (that are introduced in the pattern) can only occur once and there is no need to have higher rank quantification in value patterns (disregarding explicit tests for _|_). Therefore special syntax could be used to make the above shorter e.g. borrowing the '?' from Felix (http://felix.sourceforge.net/doc/tutorial/introduction/en_flx_tutorial_top.html (section 2.11/2.17 etc)): drop (?n + 1) (_ : ?xn) = drop n xn drop ?n nil = nil (where glued prefix binds tighter than application). > > Of course, if you want to introduce this rule, you'd better start out > with it and be consistent --- require every variable to be explicitly > brought into scope. I think you'd find it pretty annoying after trying > to program in your new language for a while, though. > I agree that there are many good points in favour of Haskell's use of a case distinction, not the least being that it gives definite guidance on when to use lower or upper case identifiers and therefore avoids the mess you find in C++ programs where every programmer has their own private conventions which can lead to confusion and useless debate. However it still seems to me that the case distinction, at least on the level of type constructors, becomes problematic and possibly inconsistent especially if I consider the effects of trying to incorporate something like the ML module system as well as type classes. (For example the Moby language (http://moby.cs.uchicago.edu/ ), a possible successor to SML, uses capitalization for type constructors similar to Haskell which means that type parameters in functor applications must be uppercase, which conflicts with the use of lowercase type params for classes which are a special kind of functor... (Moby itself doesn't encounter any difficulty since it doesn't have type classes)). Best regards, Brian. From jefferson.r.heard at gmail.com Mon Aug 4 18:04:19 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Mon Aug 4 18:04:05 2008 Subject: [Haskell-cafe] Looking for a more functional way to do this Message-ID: <4165d3a70808041504l92b9ff6u90e9e031dcd7b580@mail.gmail.com> Working with HOpenGL and GLUT, I find myself approaching a common problem with a common solution that I don't really like all that much, as it reeks of procedural programming. Basically the problem is that of complex program state, such that when the user provides input to the program in the form of a mouse click or a typed string or character, the program updates its internal state to reflect this, whether that's changing the rotation, scale, or position of a screen element, or deciding what data to have loaded from disc. What I often do is something that looks like this: data ProgramState = ProgramState { some_associative_data :: Map String String , position :: GL.Vector3 Float , look_at :: GL Vector3 Float , selectables :: Map GLuint NamedObject } render :: IORef ProgramState -> IO () render state = do st <- readIORef state ... handleMouseClicks :: IORef ProgramState -> GLUT.KeyboardMouseHandler handleMouseClicks state ... = do st <- readIORef state ... main = do ... let st = ProgramState { Map.empty ... } render' = render st mouse' = handleMouseClicks st GLUT.renderCallback $= render GLUT.keyboardMouseCallback $= Just mouse' and so on and so forth. Generally there are not fewer than 5 and not more than about 32 variables that I have to track between mouse clicks, and there's all this boilerplate code as well. I'm searching for a better way to do this, and I feel sure there is one. I'm considering using Template Haskell or possibly SYB to generate this code, but it also seems like I also ought to be able to declare some kind of state monad or continuation monad that can encapsulate ProgramState without having to declare an explicit structure for it everytime. For one thing, I'd like to genericize this code and write something akin to Processing for Haskell (http://www.processing.org). From jonathanccast at fastmail.fm Mon Aug 4 18:29:27 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Aug 4 18:30:49 2008 Subject: [Haskell-cafe] Capitalization and associated type families In-Reply-To: <48977CF8.4020503@metamilk.com> References: <48974FAF.6050607@metamilk.com> <1217876661.29128.11.camel@jcchost> <48977CF8.4020503@metamilk.com> Message-ID: <1217888967.29128.46.camel@jcchost> On Mon, 2008-08-04 at 23:04 +0100, Brian Hulley wrote: > Jonathan Cast wrote: > > On Mon, 2008-08-04 at 19:51 +0100, Brian Hulley wrote: > >> For example, why is there any distinction between a type "variable" and > >> a type "constant"? > >> > >> forall a b. (a -> b) -> List a -> List b > >> > >> Now this begs the question: why does "List" need to start with a > >> capital? (supposing that quantifiers were always written explicitly) > > > > AFAIK, it doesn't; the variable/constant distinction is just there to > > let the implementation put the foralls in for you. > > Hi Jonathan - thanks - this confirms what I've been thinking. However > consider: > > class Foo a where > > f :: a -> b -> (a, b) > > Here there is no capitalization distinction in the type of (f) but the > implementation can still insert the "forall b." since (a) is already in > scope. Therefore similarly, if type constructors like "List" were > instead written using lowercase, since they would already be in scope it > would be clear even without explicit quantifiers that (a) and (b), but > not (list), were to be quantified in the type of (map) (assuming of > course that there was no top level data decl for (a) or (b)). Sure. ML does it this way, in fact. Not for type variables, but for regular pattern variables. So, IIRC, in ML the empty list is written nil. But (playing Devil's advocate) if you have a function declaration f niil = ... That's a variable pattern... The Miranda capitalization rule (which Haskell adopted) is designed to find such typos automatically, since now you have to write f Niil and Niil can't be a variable. The fact that type signatures in Haskell type classes are subject to the same problem is certainly a weakness of the design. I think if new type variables (universally quantified locally) had a different syntax, so you said f :: a -> 'b -> (a, 'b) where a by itself meant a had better already be in scope, that would be more consistent. Then you could drop the capitalization convention entirely. > > Similarly, if we had > > explicit foralls on equations, we could say > > > > forall n x xn. drop (n+1) (x:xn) = drop n xn > > > > but > > > > forall n. drop n nil = nil > > > > and it would be perfectly clear that `nil' in the latter case was a > > constructor. > > Actually I quite like the above because it shows that pattern matching > can be understood in terms of universally quantified predicates. > > Regarding the verbosity, patterns are something of a special case since > variables (that are introduced in the pattern) can only occur once and > there is no need to have higher rank quantification in value patterns > (disregarding explicit tests for _|_). Therefore special syntax could be > used to make the above shorter e.g. borrowing the '?' from Felix > (http://felix.sourceforge.net/doc/tutorial/introduction/en_flx_tutorial_top.html > (section 2.11/2.17 etc)): > > drop (?n + 1) (_ : ?xn) = drop n xn > drop ?n nil = nil > > (where glued prefix binds tighter than application). I think this goes with ML's type variable syntax ('a), actually. > > Of course, if you want to introduce this rule, you'd better start out > > with it and be consistent --- require every variable to be explicitly > > brought into scope. I think you'd find it pretty annoying after trying > > to program in your new language for a while, though. > > > > I agree that there are many good points in favour of Haskell's use of a > case distinction, not the least being that it gives definite guidance on > when to use lower or upper case identifiers and therefore avoids the > mess you find in C++ programs where every programmer has their own > private conventions which can lead to confusion and useless debate. Another system with this advantage would be to invalidate identifiers beginning with upper case letters entirely :) (If you really wanted to go B&D, disallow underscores as well. Then every identifier /has/ to be camel-case.) > However it still seems to me that the case distinction, at least on the > level of type constructors, becomes problematic and possibly > inconsistent especially if I consider the effects of trying to > incorporate something like the ML module system as well as type classes. > (For example the Moby language (http://moby.cs.uchicago.edu/ ), a > possible successor to SML, uses capitalization for type constructors > similar to Haskell which means that type parameters in functor > applications must be uppercase, which conflicts with the use of > lowercase type params for classes which are a special kind of functor... > (Moby itself doesn't encounter any difficulty since it doesn't have type > classes)). It's weird. ML-derived languages are functional languages at the value level (and have regular lambda-bound variables in consequence), but are logical languages at the type level (and have logical variables in consequence). So ordinary lambda-bound variables, like in ML-style functors (parametrized modules) act more like type constants than like type variables. Food for thought --- thanks for that! jcc From bos at serpentine.com Mon Aug 4 20:15:26 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Aug 4 20:15:10 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: References: Message-ID: On Sat, Aug 2, 2008 at 10:13 PM, Tim Newsham wrote: > Anyone interested in critiquing some code? I'm looking for ideas > for making it faster and/or simpler: > > http://www.thenewsh.com/%7Enewsham/store/Server5.hs The code looks fairly reasonable, although most of your strictness annotations are unlikely to do much (particularly those on String fields). You should try profiling this. I can see a few possible problems (such as reading String from a socket, instead of a ByteString), but it's difficult to predict what might be causing your code to be so slow. Haskell code ought to be much more competitive with C for an application like this. From newsham at lava.net Mon Aug 4 23:45:33 2008 From: newsham at lava.net (Tim Newsham) Date: Mon Aug 4 23:45:17 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: References: Message-ID: > You should try profiling this. I can see a few possible problems (such > as reading String from a socket, instead of a ByteString), but it's > difficult to predict what might be causing your code to be so slow. > Haskell code ought to be much more competitive with C for an > application like this. I haven't tried profiling yet, I should do that (ugh, will prob have to rebuild some libraries I'm using to support that). Anyway, I haven't yet used any ByteString IO functions. I ran some tests when I was starting and it seems that using Handle IO functions was a bit slower than using the Socket IO functions directly. It looks like there are a bunch of Handle IO functions that can return ByteStrings but I don't see any for sockets... Are there any? If not, I suspect it will be a wash switching to Handles and ByteStrings (especially since most of my requests and responses are quite small). I'll write up some tests to see how well those perform.. Tim Newsham http://www.thenewsh.com/~newsham/ From allbery at ece.cmu.edu Tue Aug 5 00:34:13 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Aug 5 00:33:59 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: References: Message-ID: <9D010887-8DB8-4FDF-AECF-A300D1A0E5CF@ece.cmu.edu> On 2008 Aug 4, at 23:45, Tim Newsham wrote: > Anyway, I haven't yet used any ByteString IO functions. I ran > some tests when I was starting and it seems that using Handle IO > functions was a bit slower than using the Socket IO functions > directly. > It looks like there are a bunch of Handle IO functions that can > return ByteStrings but I don't see any for sockets... Are there any? There's something on hackage... http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-bytestring -- 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 at malde.org Tue Aug 5 02:26:54 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Aug 5 02:26:40 2008 Subject: [Haskell-cafe] poll: how can we help you contribute to darcs? In-Reply-To: <87k5exazcd.fsf@malde.org> (Ketil Malde's message of "Mon\, 04 Aug 2008 11\:44\:50 +0200") References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> <87k5exazcd.fsf@malde.org> Message-ID: <87wsiwc6z5.fsf@malde.org> Ketil Malde writes: > Duncan Coutts writes: >> It would be useful if some darcs 2 hackers, contributors could help the >> ghc people evaluate if darcs 2 is still in the running. > This looks like a very easy and low-investement way to get involved. ...and now I feel I've done my part :-) Anyway: I took the 'biolib' repo with 2005 patches, and made three copies, here's the timing results: darcs get ../biolib biolib-1 0.20s user 0.16s system 100% cpu 0.360 total darcs get --hashed ../biolib biolib-h 0.64s user 0.17s system 98% cpu 0.813 total darcs convert ../biolib biolib-2 0.62s user 0.18s system 7% cpu 11.101 total (The 11 seconds in the last one is me typing in "I understand the consequences of my action". The warnings are almost scary enough for me to worry about the state of my source repo, but I trust it is safe to do this and discard the new repos afterwards..) The 'convert' printed something looking like a patch: merger 0.0 ( hunk ./Bio/Alignment/AlignData.hs 5 -module Bio.EditList.AlignData ( $ +module Bio.Alignment.AlignData ( $ hunk ./Bio/Alignment/AlignData.hs 3 -{-# OPTIONS -fglasgow-exts #-} - -module Bio.EditList.AlignData ( $ +module Bio.EditList.AlignData ( ) and I'm not quite sure what this is about? Anyway, I then proceeded to run various queries (what, changes, diff), but apparently, this repo is way too small to actually show anything useful, it all completes in about 0.05-0.2 seconds. The consequences of moving to the darcs-2 format are a bit unclear to me. For instance, I'd like to keep my main (export) repo in darcs-1 format, in order to make it as accessible as possible (Ubuntu still ships with darcs-1.0.9, and that's a fairly cutting edge distribution.) Can I convert my working repos to darcs-2? Should I? How about darcs-hashed? In short, I'd like to see examples of recommended migration strategies, and associated benefits. -k -- If I haven't seen further, it is by standing in the footprints of giants From bradypus at xs4all.nl Tue Aug 5 02:43:52 2008 From: bradypus at xs4all.nl (Arie Groeneveld) Date: Tue Aug 5 02:43:06 2008 Subject: [Haskell-cafe] timing question In-Reply-To: <20080803173209.GA10149@scytale.galois.com> References: <489580DB.2020607@xs4all.nl> <20080803173209.GA10149@scytale.galois.com> Message-ID: <4897F6A8.2000201@xs4all.nl> Thanks for all the advises so far. Ok, here's my monster that need to be timed in order to make a comparison: (it's about the control digit of SEDOL numbers http://en.wikipedia.org/wiki/SEDOL ): knip _ [] = Nothing knip k xs = Just (splitAt k xs) ip xs = sum . zipWith (*) xs an = ['0'..'9']++['A'..'Z'] s = take 841 $ cycle "0987654321" f = \xs -> xs ++ [(sna!!).ip [1,3,1,7,3,9]. map (flip (fromJust .) an . findIndex . (==))$xs] Here's my try for timing: *Main> (foldl1 (\x y -> f y) .concat.replicate 1000000 $ unfoldr (knip 6) an) "UVWXYZ7" (1.31 secs, 330291000 bytes) (It's incl. the construction of the test list, as is in the language to compare ) I need the whole list to be evaluated. Interpreted mode IS A MUST :-) BTW I increased stack size thanks Don Stewart schreef: > bradypus: > >> Suppose I've: >> >> f = map g >> >> I want to know how much time it takes (interpreted mode) to fully >> process list xs (at least 1e6 elements) with function g. Is it >> sufficient to execute: >> >> *Main> last . f $ xs >> >> (x.xx secs, yyyyyyyyyyy bytes) >> >> Are there any hidden difficulties involved? >> >> Reason is: comparing timings Haskell vs an interpreted language without >> laziness. >> >> > > If you care about timings, it's probably a better idea to compile the > code (with optimisations on), to get a better idea of what the code > would do in a production environment. > > You could then just time the binary, > > main = print . sum $ .... > > ghc -O2 A.hs --make > time ./A > > -- Don > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080805/ff7335ff/attachment.htm From bradypus at xs4all.nl Tue Aug 5 03:15:57 2008 From: bradypus at xs4all.nl (Arie Groeneveld) Date: Tue Aug 5 03:15:13 2008 Subject: [Haskell-cafe] timing question In-Reply-To: <4897F6A8.2000201@xs4all.nl> References: <489580DB.2020607@xs4all.nl> <20080803173209.GA10149@scytale.galois.com> <4897F6A8.2000201@xs4all.nl> Message-ID: <4897FE2D.7030206@xs4all.nl> Acc. to Luke Palmers suggestion this will be the right answer? *Main> seqList rwhnf(map f $ concat.replicate 1000000 $ unfoldr (knip 6) an) () (3.46 secs, 834240864 bytes) or with/without list construction *Main> let ry = concat.replicate 1000000 $ unfoldr (knip 6) an (0.00 secs, 0 bytes) *Main> seqList rwhnf(map f ry) () (4.48 secs, 833668720 bytes) *Main> seqList rwhnf(map f ry) () (3.18 secs, 627071612 bytes) *Main> Arie Groeneveld schreef: > Thanks for all the advises so far. > > Ok, here's my monster that need to be timed in order to make a comparison: > (it's about the control digit of SEDOL numbers > http://en.wikipedia.org/wiki/SEDOL ): > > > knip _ [] = Nothing > knip k xs = Just (splitAt k xs) > > ip xs = sum . zipWith (*) xs > > an = ['0'..'9']++['A'..'Z'] > > s = take 841 $ cycle "0987654321" > f = \xs -> xs ++ [(sna!!).ip [1,3,1,7,3,9]. map (flip (fromJust .) an > . findIndex . (==))$xs] > > > > Here's my try for timing: > > *Main> (foldl1 (\x y -> f y) .concat.replicate 1000000 $ unfoldr (knip > 6) an) > "UVWXYZ7" > (1.31 secs, 330291000 bytes) > > (It's incl. the construction of the test list, as is in the language > to compare ) > > I need the whole list to be evaluated. > Interpreted mode IS A MUST :-) > > BTW I increased stack size > > > thanks > > > Don Stewart schreef: >> bradypus: >> >>> Suppose I've: >>> >>> f = map g >>> >>> I want to know how much time it takes (interpreted mode) to fully >>> process list xs (at least 1e6 elements) with function g. Is it >>> sufficient to execute: >>> >>> *Main> last . f $ xs >>> >>> (x.xx secs, yyyyyyyyyyy bytes) >>> >>> Are there any hidden difficulties involved? >>> >>> Reason is: comparing timings Haskell vs an interpreted language without >>> laziness. >>> >>> >> >> If you care about timings, it's probably a better idea to compile the >> code (with optimisations on), to get a better idea of what the code >> would do in a production environment. >> >> You could then just time the binary, >> >> main = print . sum $ .... >> >> ghc -O2 A.hs --make >> time ./A >> >> -- Don >> >> >> > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20080805/0db0ca13/attachment-0001.htm From simonmar at microsoft.com Tue Aug 5 04:11:28 2008 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Aug 5 04:11:15 2008 Subject: [Haskell-cafe] Re: ANN: Haddock version 2.2.1 In-Reply-To: <20080804195204.GA12968@craft> References: <48973D1D.6010406@dfki.de> <20080804174804.GA11112@craft> <48974EB0.9050704@dfki.de> <20080804195204.GA12968@craft> Message-ID: <1C6E59C47F062E42820BEE74FD3388E918DF3F7AEF@EA-EXMSG-C333.europe.corp.microsoft.com> > On 2008.08.04 20:47:12 +0200, Christian Maeder > scribbled 1.1K characters: > > Right, > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.4.0.1 > > works. > > > > It seems that the dependencies for ghc-paths could be improved. > > > > Thanks Christian > > Yes, I emailed Marlow suggesting that yesterday. (Or perhaps it was the > day before.) Sorry - I fixed the .cabal file and then got sidetracked into trying to make it work with Cabal-1.5 too. I'll upload the version with the fixed dependency now. Cheers, Simon From simonmar at microsoft.com Tue Aug 5 04:22:17 2008 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Aug 5 04:22:01 2008 Subject: [Haskell-cafe] Re: ANN: Haddock version 2.2.1 References: <48973D1D.6010406@dfki.de> <20080804174804.GA11112@craft> <48974EB0.9050704@dfki.de> <20080804195204.GA12968@craft> Message-ID: <1C6E59C47F062E42820BEE74FD3388E918DF3F7B10@EA-EXMSG-C333.europe.corp.microsoft.com> > > On 2008.08.04 20:47:12 +0200, Christian Maeder > > > scribbled 1.1K characters: > > > Right, > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal- > 1.4.0.1 > > > works. > > > > > > It seems that the dependencies for ghc-paths could be improved. > > > > > > Thanks Christian > > > > Yes, I emailed Marlow suggesting that yesterday. (Or perhaps it was the > > day before.) > > Sorry - I fixed the .cabal file and then got sidetracked into trying to > make it work with Cabal-1.5 too. I'll upload the version with the fixed > dependency now. Hackage won't let me upload a package with cabal-version: >= 1.4 && < 1.5, but it will let me upload with just >= 1.4, so I've done that for now. The package will fail to build if you have Cabal 1.5.x installed, presumably. Cheers, Simon From nfjinjing at gmail.com Tue Aug 5 04:59:10 2008 From: nfjinjing at gmail.com (jinjing) Date: Tue Aug 5 04:58:55 2008 Subject: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell) Message-ID: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> Hi there, Here's the project link: http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown I found Haskore pretty fun :) so I'm documenting it while learning it. Please don't hesitate to give suggestions / corrections. Questions: * How much music theory should be there ? ( I'm gonna learn those anyway ) * What kind of examples would be cool ? regards, jinjing From lemming at henning-thielemann.de Tue Aug 5 07:56:21 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Aug 5 07:56:05 2008 Subject: [Haskell-cafe] array fusion interface In-Reply-To: <2518b95d0808021030t7ef56868h1d13e49f3d59376f@mail.gmail.com> References: <2518b95d0807220617s115405acuddd67e63a2118046@mail.gmail.com> <2518b95d0808021030t7ef56868h1d13e49f3d59376f@mail.gmail.com> Message-ID: On Sat, 2 Aug 2008, Evan Laforge wrote: > >> I have streams of samples with irregular sampling rates, so they look > >> like [(Time, SampleVal)]. In practice, this means [(Double, Double)]. > > > > Maybe I have already mentioned my eventlist package on Hackage which > > supports such resampling operations - but is based on lists. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/event-list > > Ah, I had seen event-list and even downloaded and read parts of it, > but it was hard for me to figure out what was going on and how to > actually use it based on the scattered comments in the source. I commented only non-trivial parts, because I thought it is clear, that 'mapTime' is a 'map' on the time stamps and so on. > Apparently there are absolute and relative time variants, but within > that there are further "body" and "time" variants, and they're built > on a similarly sparsely documented alternating list library. Are > there some simple examples of its use out there? There are all four variants of whether a list starts and ends with a time or a data body. The 'midi' package uses 'event-list'. > Unfortunately, storable vector, unlike ByteString, doesn't export > 'create' and whatnot so I have to keep a locally patched version of > it. Well, it does export 'create': http://hackage.haskell.org/packages/archive/storablevector/0.1.2.2/doc/html/Data-StorableVector-Base.html However in my applications I could use the safe 'unfoldrN' in most cases. From lemming at henning-thielemann.de Tue Aug 5 08:02:35 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Aug 5 08:02:17 2008 Subject: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell) In-Reply-To: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> References: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> Message-ID: On Tue, 5 Aug 2008, jinjing wrote: > Here's the project link: > > http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown Would you like to post this to haskell-art@lists.lurk.org as well? From gue.schmidt at web.de Tue Aug 5 09:02:59 2008 From: gue.schmidt at web.de (=?UTF-8?B?R8O8wp9udGhlciBTY2htaWR0?=) Date: Tue Aug 5 09:02:58 2008 Subject: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard on Hackage Message-ID: Hi, does anybody know if the Greencard package / lib is the same software that is mentioned in the paper "Scripting COM Components from Haskell"? http://research.microsoft.com/~simonpj/papers/com.ps.gz I managed to install the hackage Greencard package on XP with GHC 6.8.3 but it seems to be quite different from what the paper describes. G?nther From kr.angelov at gmail.com Tue Aug 5 09:29:52 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Tue Aug 5 09:29:34 2008 Subject: [Haskell-cafe] ActiveX and COM In-Reply-To: References: Message-ID: Hi G?nther, You can also consider the hscom library: http://darcs.haskell.org/packages/hscom/ There is a simple demo that automates MS Agent. The library is not completed but if you are interested only in controlling Excel via automation it should provide what you need. I started hscom because I was disappointed from HDirect while working on Visual Haskell. It overcomes some problems and in addition it is designed to be more in the style of the modern FFI library. The library is not under active development but I can assist with simple fixes. Regards, Krasimir On Mon, Aug 4, 2008 at 11:47 AM, G??nther Schmidt wrote: > Hi, > > what is currently the recommend way to interface with COM from haskell? > > I need to create an Excel Sheet and thus need to use Excel via COM. > > G?nther > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From kr.angelov at gmail.com Tue Aug 5 09:30:49 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Tue Aug 5 09:30:33 2008 Subject: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard on Hackage In-Reply-To: References: Message-ID: No! Greencard is another story. The paper describes HDirect. On Tue, Aug 5, 2008 at 3:02 PM, G??nther Schmidt wrote: > Hi, > > does anybody know if the Greencard package / lib is the same software that > is mentioned in the paper "Scripting COM Components from Haskell"? > > http://research.microsoft.com/~simonpj/papers/com.ps.gz > > I managed to install the hackage Greencard package on XP with GHC 6.8.3 but > it seems to be quite different from what the paper describes. > > G?nther > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgoerzen at complete.org Tue Aug 5 11:13:26 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Aug 5 11:13:15 2008 Subject: [Haskell-cafe] Re: Brainstorming on how to parse IMAP In-Reply-To: References: <4895122C.7070301@complete.org> Message-ID: <48986E16.4040205@complete.org> Ben Franksen wrote: > John Goerzen wrote: >> I'm interested in writing a library to work with IMAP servers. >> >> I'm interested in thoughts people have on parsing libraries and methods. >> I'm a huge fan of Parsec overall -- it lets me have a single-stage >> parser, for instance. But it isn't sufficiently lazy for this task, and >> I probably will need to deal with ByteStrings instead of Strings, since >> some IMAP messages may be 30MB or more. > > You might be interested in Frisby: http://repetae.net/computer/frisby/ Are there any examples available for it anywhere? > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgoerzen at complete.org Tue Aug 5 11:22:26 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Aug 5 11:22:08 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP In-Reply-To: <4895122C.7070301@complete.org> References: <4895122C.7070301@complete.org> Message-ID: <48987032.2020006@complete.org> Hi folks, Thanks to those that responded on this -- certainly some libraries to check out here. One problem with that is that if I use specific parsing library foo, then only others that are familiar with specific parsing library foo can hack on it. In general though, I think this speaks to more generic problems: 1) A lot of network protocols require reading data of arbitrary length until a certain delimiter is found. Often that delimiter is \n. Haskell is really weak at this. We can turn a Socket into a Handle and use hGetLine, but this has a security weakness: it has no upper bounds on the amount of data read, and this is vulnerable to resource exhaustion DOS from the remote end. There is, as far as I can tell, no general-purpose "buffer until I see foo" framework in Haskell. (Note that just reading character-by-character is too slow as well). 1a) Even more generally, a "read one packet of data, however much becomes available" notion is pretty weak. For a lazy ByteString, my only two choices are to block until n bytes are available (where n is specified in advance), or to not block at all. There is no "block until some data, however much, becomes available, and return that chunk up to a maxmimum size x." Well, Network.Socket.recv may do this, but it returns a String. Is there even a way to do this with a ByteString? 2) A lot of RFC protocols -- and IMAP in particular -- can involve complex responses from the server with hierarchical data, and the parse of, say, line 1 and of each successive line can indicate whether or not to read more data from the server. Parsing of these lines is a stateful activity. 3) The linkage between Parsec and IO is weak. I cannot write an "IMAPResponse" parser. I would have a write a set of parsers to parse individual components of the IMAP response as part of the IO monad code that reads the IMAP response, since the result of one dictates how much network data I attempt to read. -- John From donn at avvanta.com Tue Aug 5 12:42:27 2008 From: donn at avvanta.com (Donn Cave) Date: Tue Aug 5 12:42:10 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP Message-ID: <20080805164227.36CC6F3941@mail.avvanta.com> Quoth John Goerzen : ... | One problem with that is that if I use specific parsing library foo, | then only others that are familiar with specific parsing library foo can | hack on it. Well, you asked. For me, the parsing is a relatively minor part of the problem and maybe not one that benefits greatly from external support. MIME might be a different story. | 2) A lot of RFC protocols -- and IMAP in particular -- can involve | complex responses from the server with hierarchical data, and the parse | of, say, line 1 and of each successive line can indicate whether or not | to read more data from the server. Parsing of these lines is a stateful | activity. I mentioned that my parser may return an incomplete status. In principle, something like parseResponse :: ByteString -> Maybe (IMAPResponse, ByteString) That means the parse needs to be repeated each time until enough input data has accumulated. I worried a little about how to represent a useful incomplete parse state, but decided that it isn't worth the trouble - the amount of parsing in an ordinary response is too trivial. | 3) The linkage between Parsec and IO is weak. I cannot write an | "IMAPResponse" parser. I would have a write a set of parsers to parse | individual components of the IMAP response as part of the IO monad code | that reads the IMAP response, since the result of one dictates how much | network data I attempt to read. The parser should just parse data, and not read it. You don't need to worry about whether you can get recv(2) semantics on a socket with bytestrings, and you don't need to saddle users of this parser with whatever choice you might make there. You don't need to supply an SSL input function with the same semantics, or account for the possibility that data might actually not be coming from a socket at all (UNIX pipes are not unheard of.) You don't need to lock users into whatever execution dispatching might be supported by that I/O, potentially ruling out graphics libraries etc. that might not be compatible. So I would let the application come up with the data. In general, I don't think there's any way to specify how much to read - I mean, the counted literal certainly provides that information, but that's the exception - so I would assume the application will need some kind of recv(2)-like function that reads data as available. By the way, if you haven't already run across this, you may be interested to read about the IMAP "IDLE" command, cf. RFC2177. I think the value of this feature can be overstated, but it depends on the server, and some IMAP client implementators are very fond of it. At this point, the reason it might be interesting is that it moves away from the call & response pattern. Donn From jeremy at n-heptane.com Tue Aug 5 13:01:23 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Aug 5 12:57:13 2008 Subject: [Haskell-cafe] GHC Feature or Bug: f x = (`head` x, ()) Message-ID: <874p5zwg4c.wl%jeremy@n-heptane.com> Hello, GHC is happy to compile this code: > f x = (`head` x, ()) but Hugs does not like it, and Section 3.5 of the Haskell Report does not give any obvious indications that it is valid. Numerous people have suggested that some additional parens are required: > f x = ((`head` x), ()) Is this GHC behavior intentional? If not, is it perhaps a happy accident? Or is it ambigious in some way with out the additional parenthesis ? I am curious because trhsx (the preprocessor for HSP/HSX) currently does not accept this construct. If it is a bug in GHC (that will eventually be fixed), then we can leave trhsx alone. If it is a feature, then a precise definition of the adjusted syntax would be helpful. (Or, if this construct is valid H98, an explaination of how to read the report correctly). Thanks! j. From jgoerzen at complete.org Tue Aug 5 13:43:03 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Aug 5 13:42:46 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP In-Reply-To: <20080805164227.36CC6F3941@mail.avvanta.com> References: <20080805164227.36CC6F3941@mail.avvanta.com> Message-ID: <48989127.6010704@complete.org> Donn Cave wrote: > I mentioned that my parser may return an incomplete status. In principle, > something like > > parseResponse :: ByteString -> Maybe (IMAPResponse, ByteString) > > That means the parse needs to be repeated each time until enough input > data has accumulated. I worried a little about how to represent a > useful incomplete parse state, but decided that it isn't worth the > trouble - the amount of parsing in an ordinary response is too trivial. But the problem here is getting that first ByteString in the first place. Are you suggesting it would be the result of hGetContents or somesuch, reading from a socket? I've tried the sort of approach with my FTP library. It can be done, but it is exceptionally tricky and I wouldn't do it again. You have to make extremely careful use of things like try in Parsec, and even just regular choices (sometimes it wants to read a character that won't exist yet.) Also buffering plays into it too. The trick with reading from the network in a back-and-forth protocol is knowing how much to read. You have to be very careful here. If you try to read too much (and are blocking until you read), you will get deadlock because you are reading data that the other end isn't going to send yet. And that, as I see it, is the problem with the above. It seems to be a chicken-and-egg problem in my mind: how do you know how much data to read until you've parsed the last bit of data that tells you how to read the next bit? > | 3) The linkage between Parsec and IO is weak. I cannot write an > | "IMAPResponse" parser. I would have a write a set of parsers to parse > | individual components of the IMAP response as part of the IO monad code > | that reads the IMAP response, since the result of one dictates how much > | network data I attempt to read. > > > The parser should just parse data, and not read it. > > You don't need to worry about whether you can get recv(2) semantics on > a socket with bytestrings, and you don't need to saddle users of this > parser with whatever choice you might make there. You don't need to > supply an SSL input function with the same semantics, or account for > the possibility that data might actually not be coming from a socket > at all (UNIX pipes are not unheard of.) You don't need to lock users > into whatever execution dispatching might be supported by that I/O, > potentially ruling out graphics libraries etc. that might not be compatible. > > So I would let the application come up with the data. In general, Well, your response here begs the question of how much you want to automate from the application. Yes, there are multiple ways of communicating with IMAP servers, but you have the same synchronization issues with all of them. Yes, I plan to let the application supply functions to read data. But in the end, that is pointless if those functions can't be written in Haskell! > I don't think there's any way to specify how much to read - I mean, > the counted literal certainly provides that information, but that's the > exception - so I would assume the application will need some kind of > recv(2)-like function that reads data as available. Exactly. But there is no recv()-like function, except the one that returns IO String. There is no recv()-like function that returns IO ByteString. (I actually notice now a package on Hackage that does this... why it's not in core, I don't know.) > By the way, if you haven't already run across this, you may be interested > to read about the IMAP "IDLE" command, cf. RFC2177. I think the value > of this feature can be overstated, but it depends on the server, and some > IMAP client implementators are very fond of it. At this point, the reason > it might be interesting is that it moves away from the call & response > pattern. It's on my todo list. -- John From donn at avvanta.com Tue Aug 5 14:38:47 2008 From: donn at avvanta.com (Donn Cave) Date: Tue Aug 5 14:38:33 2008 Subject: [Haskell-cafe] Brainstorming on how to parse IMAP Message-ID: <20080805183847.5C06993C49@mail.avvanta.com> Quoth John Goerzen : | Donn Cave wrote: ... |> So I would let the application come up with the data. In general, | | Well, your response here begs the question of how much you want to | automate from the application. Yes, there are multiple ways of | communicating with IMAP servers, but you have the same synchronization | issues with all of them. Yes, I plan to let the application supply | functions to read data. But in the end, that is pointless if those | functions can't be written in Haskell! Sorry, I didn't entirely understand that, but the way I see it, you might or might not be able to map the set of issues with one transport vs. another onto some common abstraction. And anyway it's much easier and cleaner for you to implement the protocol parser as a pure function of bytestring -> response, than tangle it up with I/O. OK, here's a trivial example of what I see as the virtues of this approach. I don't think I actually return any size information along with my `incomplete' failure response, but it occurs to me that I should. Then a graphic application can use that to start a progress indicator for large transfers. It will be easy for my application to update that progress indicator, because it got the expected size and is getting the data. Harder to make that work through generic I/O functions invoked inside the parser, I think. | > I don't think there's any way to specify how much to read - I mean, | > the counted literal certainly provides that information, but that's the | > exception - so I would assume the application will need some kind of | > recv(2)-like function that reads data as available. | | Exactly. But there is no recv()-like function, except the one that | returns IO String. There is no recv()-like function that returns IO | ByteString. Well, right, that's needed. I just hacked out my own FFI. (Likewise for SSL.) In a platform context where you're forced to use buffered input semantics, you might use hGetLine and then read fixed amounts as required for counted literals (so the parser would need to return a bytes-needed-to-complete value to support that.) Donn From rendel at daimi.au.dk Tue Aug 5 14:39:28 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Tue Aug 5 14:39:17 2008 Subject: [Haskell-cafe] Capitalization and associated type families In-Reply-To: <48977CF8.4020503@metamilk.com> References: <48974FAF.6050607@metamilk.com> <1217876661.29128.11.camel@jcchost> <48977CF8.4020503@metamilk.com> Message-ID: <48989E60.5090206@daimi.au.dk> Brian Hulley wrote: > class Foo a where > > f :: a -> b -> (a, b) > > Here there is no capitalization distinction in the type of (f) but the > implementation can still insert the "forall b." since (a) is already in > scope. Therefore similarly, if type constructors like "List" were > instead written using lowercase, since they would already be in scope it > would be clear even without explicit quantifiers that (a) and (b), but > not (list), were to be quantified in the type of (map) (assuming of > course that there was no top level data decl for (a) or (b)). So adding b to the export list of an imported module would change the type of f? Tillmann From haskell at list.mightyreason.com Tue Aug 5 14:39:59 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Aug 5 14:39:53 2008 Subject: [Haskell-cafe] Re: Brainstorming on how to parse IMAP In-Reply-To: <4895122C.7070301@complete.org> References: <4895122C.7070301@complete.org> Message-ID: <48989E7F.7000005@list.mightyreason.com> Hi John, I recently posted new and fancy binary Get monads in http://article.gmane.org/gmane.comp.lang.haskell.libraries/9691 and http://article.gmane.org/gmane.comp.lang.haskell.libraries/9756 which might be of interest since network protocol are usually specified in bytes at the wire level. The latest one takes input which may or may not be complete and returns a stream (a Seq) of results. When it reaches the end of the input it pauses and asks for more. This handling of partial input might be good for network protocols where you can feed the data from the socket to the parser in pieces. (This Get monad eats lazy bytestrings). The latest MyGetW.hs allows the Get code to send a Data.Sequence.Seq of results by using yieldItem (and perhaps flushItems). This is in addition to any final result of the parser. It has the usual binary Get interface, so you can pull bytestrings and words and (fancy) any Storable off the input. I call it "fancy" because the monad is a transformer, and it is a MonadError/MonadPlus/Alternative, and it supports lookAhead and callCC/MonadCont and Reader/Writer/State. Whew. As for IMAP, I use imapfilter (http://imapfilter.hellug.gr/) which uses Lua. Cheers, Chris From ben.franksen at online.de Tue Aug 5 14:52:42 2008 From: ben.franksen at online.de (Ben Franksen) Date: Tue Aug 5 14:52:31 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> <87k5exazcd.fsf@malde.org> <87wsiwc6z5.fsf@malde.org> Message-ID: Ketil Malde wrote: > The consequences of moving to the darcs-2 format are a bit unclear to > me. For instance, I'd like to keep my main (export) repo in darcs-1 > format, in order to make it as accessible as possible (Ubuntu still > ships with darcs-1.0.9, and that's a fairly cutting edge > distribution.) Can I convert my working repos to darcs-2? No. You cannot push or pull between darcs-2 format repos and darcs-1 or hashed format repos. This might not be optimal but is understandable, since the theory underlying the darcs-2 repository format is different. The more important problem is that conversion to darcs-2 format doesn't support multiple branches at all. Some people recommend the use of tailor for this. However, on some of our repositories this fails to produce correct results, or crashes somewhere during the conversion. I have tried it and it is an endless frustration. BTW, this is a point where projects (such as darcs) cannot be careful enough: migration paths simply /must/ exists. This should have been top priority and a milestone for the release of darcs-2.0. As it is, I have asked twice on the darcs-users list how to convert multible branches before I even got a single reply. I had the impression the remaining developers are feeling almost as helpless as me. > Should I? No. > How about darcs-hashed? Yes, darcs-hashed can be used together with darcs-1 repos. This works fine, IME. > In short, I'd like to see examples of > recommended migration strategies, and associated benefits. Me too. Cheers Ben From brianh at metamilk.com Tue Aug 5 15:06:30 2008 From: brianh at metamilk.com (Brian Hulley) Date: Tue Aug 5 15:05:49 2008 Subject: [Haskell-cafe] Capitalization and associated type families In-Reply-To: <1217888967.29128.46.camel@jcchost> References: <48974FAF.6050607@metamilk.com> <1217876661.29128.11.camel@jcchost> <48977CF8.4020503@metamilk.com> <1217888967.29128.46.camel@jcchost> Message-ID: <4898A4B6.2080407@metamilk.com> Jonathan Cast wrote: > > It's weird. ML-derived languages are functional languages at the value > level (and have regular lambda-bound variables in consequence), but are > logical languages at the type level (and have logical variables in > consequence). So ordinary lambda-bound variables, like in ML-style > functors (parametrized modules) act more like type constants than like > type variables. Thanks - the above seems to be a promising avenue of thought to arrive at clarity regarding case distinctions at the type level, and I can see here the basis for a good argument of why there would actually be no inconsistency regarding the use of capitals for module type members and lowercase for the class parameters. Perhaps this is also the root of the difference between associated type synonyms and class params. Ie at the type level, uppercase == functional variable (aka "constant") and lowercase == logic variable... The type level now seems to me to be quite significantly more complicated than the value level due to the mixing of functional and logic programming, not to mention that at the type level "variables" in an outer scope become "constants" in an inner scope as far as pattern matching is concerned whereas for value patterns variables are always fresh and never scoped (over other patterns). Therefore I've decided to deal with the issue of case at each level separately since it seems immediately clear that the case distinction at the value level, as in Haskell/OCaml/Moby, is obviously good due to the "foolproof" nature of value patterns you pointed out, whereas at the type level it may also be good but I'll need a few more months to think about it... ;-) Cheers, Brian. From brianh at metamilk.com Tue Aug 5 15:22:23 2008 From: brianh at metamilk.com (Brian Hulley) Date: Tue Aug 5 15:21:48 2008 Subject: [Haskell-cafe] Capitalization and associated type families In-Reply-To: <48989E60.5090206@daimi.au.dk> References: <48974FAF.6050607@metamilk.com> <1217876661.29128.11.camel@jcchost> <48977CF8.4020503@metamilk.com> <48989E60.5090206@daimi.au.dk> Message-ID: <4898A86F.8000009@metamilk.com> Tillmann Rendel wrote: > Brian Hulley wrote: > >> class Foo a where >> >> f :: a -> b -> (a, b) >> >> Here there is no capitalization distinction in the type of (f) but the >> implementation can still insert the "forall b." since (a) is already >> in scope. Therefore similarly, if type constructors like "List" were >> instead written using lowercase, since they would already be in scope >> it would be clear even without explicit quantifiers that (a) and (b), >> but not (list), were to be quantified in the type of (map) (assuming >> of course that there was no top level data decl for (a) or (b)). > > So adding b to the export list of an imported module would change the > type of f? Yes, if the module in which the above class decl were defined imported a data type (b) from some other module (or defined it elsewhere in the same module) then (f)'s type would change. (Of course at the moment this can't happen because (b) is lowercase so it can't be introduced by data/type decls or imported/exported.) The type of (f) would also change if Haskell were extended to support nested classes: class Bar b where class Foo a where f :: a -> b -> (a, b) But as Jonathan pointed out this behaviour is not really all that ideal since even in Haskell at the moment a simple spelling mistake could cause silent quantification instead of an error (which is perhaps the main justification for why constructors introduced by data/type decls must currently be capitalized -- unfortunately there is no corresponding protection when writing types inside class decls): class Zap aaaaa where g :: aaaaa -> aaaa ^ oops! Cheers - Brian. From ben.franksen at online.de Tue Aug 5 15:44:15 2008 From: ben.franksen at online.de (Ben Franksen) Date: Tue Aug 5 15:44:15 2008 Subject: [Haskell-cafe] Re: Re: Brainstorming on how to parse IMAP References: <4895122C.7070301@complete.org> <48986E16.4040205@complete.org> Message-ID: John Goerzen wrote: > Ben Franksen wrote: >> John Goerzen wrote: >>> I'm interested in writing a library to work with IMAP servers. >>> >>> I'm interested in thoughts people have on parsing libraries and methods. >>> I'm a huge fan of Parsec overall -- it lets me have a single-stage >>> parser, for instance. But it isn't sufficiently lazy for this task, and >>> I probably will need to deal with ByteStrings instead of Strings, since >>> some IMAP messages may be 30MB or more. >> >> You might be interested in Frisby: http://repetae.net/computer/frisby/ > > Are there any examples available for it anywhere? I am pretty sure John Meacham has some examples but I personally don't know any. I have once used it for something but in the end went back to parsec because it was slightly faster and I had no need for the lazyness. Cheers Ben From ben.franksen at online.de Tue Aug 5 15:52:54 2008 From: ben.franksen at online.de (Ben Franksen) Date: Tue Aug 5 15:52:45 2008 Subject: [Haskell-cafe] Re: Brainstorming on how to parse IMAP References: <4895122C.7070301@complete.org> <48989E7F.7000005@list.mightyreason.com> Message-ID: ChrisK wrote: > I recently posted new and fancy binary Get monads in > http://article.gmane.org/gmane.comp.lang.haskell.libraries/9691 > and > http://article.gmane.org/gmane.comp.lang.haskell.libraries/9756 > which might be of interest since network protocol are usually specified in > bytes at the wire level. > > The latest one takes input which may or may not be complete and returns > a > stream (a Seq) of results. IIRC Seq is not a 'Stream' but a strict sequence? Or do you meant 'a stream (of Seq)'? Cheers Ben From ryani.spam at gmail.com Tue Aug 5 15:54:07 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Aug 5 15:53:49 2008 Subject: [Haskell-cafe] Capitalization and associated type families In-Reply-To: <4898A86F.8000009@metamilk.com> References: <48974FAF.6050607@metamilk.com> <1217876661.29128.11.camel@jcchost> <48977CF8.4020503@metamilk.com> <48989E60.5090206@daimi.au.dk> <4898A86F.8000009@metamilk.com> Message-ID: <2f9b2d30808051254k5a157d96yacc44ff217a56034@mail.gmail.com> On Tue, Aug 5, 2008 at 12:22 PM, Brian Hulley wrote: > unfortunately there is no corresponding protection when writing types inside > class decls: > > class Zap aaaaa where > g :: aaaaa -> aaaa > ^ oops! Well, I think there's a pretty good protection; instances usually won't typecheck until it's fixed. -- ryan From haskell at list.mightyreason.com Tue Aug 5 16:49:24 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Aug 5 16:49:26 2008 Subject: [Haskell-cafe] Re: Brainstorming on how to parse IMAP In-Reply-To: References: <4895122C.7070301@complete.org> <48989E7F.7000005@list.mightyreason.com> Message-ID: <4898BCD4.1070805@list.mightyreason.com> I am glad you asked Ben, Short answer: It can return a Seq of your values. The values in the Seq are lazy, the Seq itself is finite. It can return what it has so far before it finishes parsing (or even before the rest of the input has arrived from the network). Ben Franksen wrote: > ChrisK wrote: >> I recently posted new and fancy binary Get monads in >> http://article.gmane.org/gmane.comp.lang.haskell.libraries/9691 >> and >> http://article.gmane.org/gmane.comp.lang.haskell.libraries/9756 >> which might be of interest since network protocol are usually specified in >> bytes at the wire level. >> >> The latest one takes input which may or may not be complete and returns >> a >> stream (a Seq) of results. > > IIRC Seq is not a 'Stream' but a strict sequence? Or do you meant 'a stream > (of Seq)'? I meant it returns many (Seq y), one after the other, while doing parsing in between. > > Cheers > Ben Long answer: The complicated parser looks like this. Start with the run function: runCompGet :: (Monad m,Monoid w) => CompGet a y r w user m a -> r -> user -> L.ByteString -> m (CompResult y w user m a) This takes a CompGet and a reader state r and a user state user and the (initial) input L.ByteString (Data.ByteString.Lazy.ByteString). It evaluates to the inner monad 'm' returning a CompResult. The CompResult is a three-fold type: > data CompResult y w user m a = > CFailed (Seq y) !Int64 String > | CFinished (Seq y) !L.ByteString !Int64 w user a > | CPartial (Seq y) (Either ( m (CompResult y w user m a) ) > ( Maybe L.ByteString -> m (CompResult y w user m a) )) All three have (Seq y) which are the Data.Sequence.Seq of things which have been queued by "yieldItem". CFailed also has the Int64 count of bytes parsed successfully and an error message String. Nothing more can be done. CFinished also has the unused tail of the input as a L.ByteString and an Int64 of the bytes consumed. And the output of the writer w, the final user state, and lastly it has the end value returned by the computation which has type 'a'. Nothing more can be done. CPartial is the intermediate result. It also carries Either: Left : the rest of the computation, currently suspended, to continue running. Right: a function from (Maybe ByteString) to the suspended computation. The Left is a result of the "flushItems" command and is merely a way to return the (Seq y) so far before continuing. The Right is a result of running out of input data. This allows the program to feed more input into the parser which will be appended to all the previous input. One does this by passing (Just someByteString) to the function. If the parser again runs out of data it will again return CPartial with a Right value. Alternatively, one can pass Nothing. This tells the parser that there will never ever be more input. The parser will never ask for (though it may flushItems and return a Right valued CPartial). A key thing about the (Seq y) is that yielded items are only returned once. The CPartial may be returned many times and each time it will have an empty list or fresh list of (Seq y). The values in the Seq are lazy, the Seq itself is finite. To collect all the value the caller has to concatenate all the (Seq y)'s that are returned during parsing. As for parsing, the module offers the usual BinaryParser interface (package binary-strict) and has an interface which mostly overlaps Data.Binary.Get (package binary). For example: it has "getByteString" and "getWord64be" and "getStorable". You don't have to use the "yieldItem" command. You can just return the results in the final "a" return value (or the "user" state or the writer "w" value). In this situation you only get an answer when CFinished is returned (and nothing if CFailed is returned). I could not use the writer mechanism for yield-ing because the "listen" and "pass" parts of the MonadWriter class ensure it has the wrong semantics. You might wonder: *) If the parser code uses MonadPlus to give several alternatives *) The first alternative gets more input via CPartial (perhaps several times) *) The first alternative then fails *) The second alternative starts parsing from the same position the first did *) Does the second alternative see the new input passed to CPartial earlier? The answer is yes. Changes to the input stream by appending with CPartial affect the whole computation and are never rolled back. You might wonder: *) If the first alternative calls "yieldItem foo" *) The first alternative fails *) The second alternative calls flushItems *) Does the CPartial (Seq y) contain "foo"? The answer is yes. Items yielded are never rolled back. [ Doing all of this in the presence of throwError/mzero/fail and lookAhead* and callCC was interesting to code. ] Cheers, Chris From jgm at berkeley.edu Tue Aug 5 16:52:24 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Tue Aug 5 16:51:55 2008 Subject: [Haskell-cafe] Re: Brainstorming on how to parse IMAP In-Reply-To: <48986E16.4040205@complete.org> References: <4895122C.7070301@complete.org> <48986E16.4040205@complete.org> Message-ID: <20080805205224.GB551@berkeley.edu> +++ John Goerzen [Aug 05 08 10:13 ]: > >> I'm interested in thoughts people have on parsing libraries and methods. > >> I'm a huge fan of Parsec overall -- it lets me have a single-stage > >> parser, for instance. But it isn't sufficiently lazy for this task, and > >> I probably will need to deal with ByteStrings instead of Strings, since > >> some IMAP messages may be 30MB or more. > > > > You might be interested in Frisby: http://repetae.net/computer/frisby/ > > Are there any examples available for it anywhere? I wrote a markdown parser using Frisby: http://github.com/jgm/markdown-peg/tree/master John From pieter at laeremans.org Tue Aug 5 17:21:43 2008 From: pieter at laeremans.org (Pieter Laeremans) Date: Tue Aug 5 17:21:27 2008 Subject: [Haskell-cafe] Stripping text of xml tags and special symbols Message-ID: Hi, I 've got a lot of files which I need to proces in order to make them indexable by sphinx. The files contain the data of a website with a custom perl based cms. Unfortunatly they sometimes contain xml/html tags like And since most of the texts are in dutch and some are in French they also contain a lot of special characters like ? ?, ... I'm trying to replace the custom based perl based cms by a haskell one. And I would like to add search capability. Since someone wrote sphinx bindings a few weeks ago I thought I try that. But transforming the files in something that sphinx seems a challenge. Most special character problems seem to go aways when I use encodeString (Codec.Binary.UTF8.String) on the indexable data. But the sphinx indexer complains that the xml isn't valid. When I look at the errors this seems due to some documents containing not well formed html. I would like to use a programmatic solution to this problem. And is there some haskell function which converts special tokens lik & -> & and ? -> &egu; ? thanks in advance, Pieter -- Pieter Laeremans "The future is here. It's just not evenly distributed yet." W. Gibson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080805/b41bdeb6/attachment.htm From jeremy at n-heptane.com Tue Aug 5 17:46:15 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Aug 5 17:42:07 2008 Subject: [Haskell-cafe] Stripping text of xml tags and special symbols In-Reply-To: References: Message-ID: <87zlnruod4.wl%jeremy@n-heptane.com> At Tue, 5 Aug 2008 23:21:43 +0200, Pieter Laeremans wrote: > And is there some haskell function which converts special tokens lik & -> > & and ? -> &egu; ? By default, xml only has 5 predefined entities: quot, amp, apos, lt, and gt. Any additional ones are defined in the DTD. But you can *always* use numeric character references like: &#nnnn; or &#xhhhh; So, you should be able to implement a simple function which whitelists a few characters ('a'..'z', 'A'..'Z', '0'..'9', ...), and encodes everything else? You might look at the source code for Text.XML.HaXml.Escape and Network.URI.escapeString for inspiration. j. http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references From benja.fallenstein at gmail.com Tue Aug 5 17:48:28 2008 From: benja.fallenstein at gmail.com (Benja Fallenstein) Date: Tue Aug 5 17:48:11 2008 Subject: [Haskell-cafe] Stripping text of xml tags and special symbols In-Reply-To: References: Message-ID: Hi Pieter, 2008/8/5 Pieter Laeremans : > But the sphinx indexer complains that the xml isn't valid. When I look at > the errors this seems due to some documents containing not well formed > html. If you need to cope with non-well-formed HTML, try HTML Tidy: http://tidy.sourceforge.net/ All the best, - Benja From newsham at lava.net Tue Aug 5 17:55:19 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 5 17:55:20 2008 Subject: [Haskell-cafe] code review? store server, 220loc. In-Reply-To: References: Message-ID: > On Sat, Aug 2, 2008 at 10:13 PM, Tim Newsham wrote: >> http://www.thenewsh.com/%7Enewsham/store/Server5.hs > > You should try profiling this. I can see a few possible problems (such > as reading String from a socket, instead of a ByteString), but it's > difficult to predict what might be causing your code to be so slow. > Haskell code ought to be much more competitive with C for an > application like this. Profiling didn't turn up anything obvious: http://www.thenewsh.com/~newsham/store/Server9.prof one thing I dont quite understand is that it seems to be crediting more time to "put8" and "get8" than is warranted, perhaps all of the "get" and "put" functions... One suprising result from testing: http://www.thenewsh.com/~newsham/store/TestBin.hs shows that the Data.Binary marshalling is actually very fast, but when I want to add a length field at the start of the buffer it has a huge impact on performance. I've tried several variations without much luck... (also the third test case is very odd in that skipping a conversion to strict bytestring actually makes it slower(!)). soo... I think thats probably one of the things limiting my performance. Another one is probably my need to do two reads (one for length one for the data) for each received record... I think with some trickiness I could get around that (since recv will return only as many bytes as are immediately available) but I don't know that its worth the effort right now.... Anyway, any thoughts, especially on how to make the bytestring operations faster, would be appreciated. Tim Newsham From jvlask at hotmail.com Tue Aug 5 22:12:28 2008 From: jvlask at hotmail.com (john lask) Date: Tue Aug 5 22:12:10 2008 Subject: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard on Hackage In-Reply-To: References: Message-ID: Gunther Hdirect can be found at: http://www.haskell.org/hdirect/ the Hdirect library was conceived prior to the finalisation of the haskell ffi, consequently some work would be required to adapt it to the current ffi. What you want is just the automation library which is only part of the overall package (the package includes ihc, the interface generator, from memory ), the automation library could easily be seporated from the rest of the package, stripping away the hdirect marshalling utils to make use of the current ffi functions and marshalling utils. This would be a relatively straight forward task, for someone that way inclined. you might also want to have a look at hugs.net: http://www.galois.com/~sof/hugs98.net/ John. > Date: Tue, 5 Aug 2008 15:30:49 +0200 > From: kr.angelov@gmail.com > To: gue.schmidt@web.de > Subject: Re: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard on Hackage > CC: haskell-cafe@haskell.org > > No! Greencard is another story. The paper describes HDirect. > > On Tue, Aug 5, 2008 at 3:02 PM, G??nther Schmidt wrote: >> Hi, >> >> does anybody know if the Greencard package / lib is the same software that >> is mentioned in the paper "Scripting COM Components from Haskell"? >> >> http://research.microsoft.com/~simonpj/papers/com.ps.gz >> >> I managed to install the hackage Greencard package on XP with GHC 6.8.3 but >> it seems to be quite different from what the paper describes. >> >> G?nther >> >> _______________________________________________ >> 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 _________________________________________________________________ Meet singles near you. Try ninemsn dating now! http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=WL_TAGLINE&_m=EXT From andrewcoppin at btinternet.com Tue Aug 5 15:28:41 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue Aug 5 23:31:05 2008 Subject: [Haskell-cafe] Show me Message-ID: <4898A9E9.1060503@btinternet.com> Suppose we have the following: data Foo x list_foo :: [x] -> Foo x foo_list :: Foo x -> [x] What would be the best way to write a Show instance? The thing that I came up with is instance (Show x) => Show (Foo x) where show foo = "list_foo " ++ show (foo_list foo) But apparently you're supposed to use the strange "showsPrec" method that I don't understand. So can somebody show me a correct instance definition for this type please? From jonathanccast at fastmail.fm Tue Aug 5 23:41:45 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Aug 5 23:41:26 2008 Subject: [Haskell-cafe] Show me In-Reply-To: <4898A9E9.1060503@btinternet.com> References: <4898A9E9.1060503@btinternet.com> Message-ID: <1217994105.6389.1.camel@jonathans-macbook> On Tue, 2008-08-05 at 20:28 +0100, Andrew Coppin wrote: > Suppose we have the following: > > data Foo x > list_foo :: [x] -> Foo x > foo_list :: Foo x -> [x] > > What would be the best way to write a Show instance? > > The thing that I came up with is > > instance (Show x) => Show (Foo x) where > show foo = "list_foo " ++ show (foo_list foo) > > But apparently you're supposed to use the strange "showsPrec" method > that I don't understand. So can somebody show me a correct instance > definition for this type please? instance Show x => Show (Foo x) where showsPrec n foo = ("list_foo "++) . shows (foo_list foo) You use the n parameter if you've got an infix operator in your syntax and you want to put parentheses around an instance of it if n has the wrong value (either too high or too low, I can never remember). jcc From eric.kow at gmail.com Wed Aug 6 01:29:32 2008 From: eric.kow at gmail.com (Eric Y. Kow) Date: Wed Aug 6 01:29:19 2008 Subject: [Haskell-cafe] helping you contribute to darcs (poll results so far) Message-ID: <20080806052932.GA5571@Macintosh.local> Dear Haskellers, Last Friday, I had posted a message asking how the darcs community could a better job recruiting developers to hack on darcs. Thanks for all the great responses! I am gratified by the suggestions you have offered, as well as the recent uptick in community involvement. The responses so far fall along three themes: offering new features, improving code accessibility and shaking up the community: Features - GUI (david48, Bit Conner) - splitting/merging (Luke Palmer, Ben Franksen) - binary file handling (Jason Dusek) - ... already does what I want (Allan Clark, Andrew Coppin) Code accessibility - split into libs (Neil Mitchell) - unit tests! (Ashley Moran) - code documentation (Lele Gaifax) - patch theory docs (Apfelmus, Ferenc Wagner) - inherent simplicity of model, cf git (Austin Seipp) Community - release announcements (Brandon Allbery, Neil Mitchell, Don Stewart) - showing ways to help (Wren Ng Thorton, Ferenc Wagner) - announcing our need for help (Wren Ng Thorton) - easier entry point to darcs code, ? la xmonad (Petr Rockai) - more active leadership (Don Stewart, Lele Gaifax) One thing which is clear is that the darcs team have failed to communicate effectively: the code is not as well-documented as it should be, patch theory is still not defined clearly or rigorously enough for Haskellers, the recent release announcements gave people the impression that darcs was being abandoned, and we haven't made it clear that we needed your help. We need your help ----------------- Hopefully one thing is clearer after this discussion. We definitely need your help! What we need most of all are some Haskell optimisation gurus to join the project, even in a minor way. Darcs 2 offers some huge improvements in safety and core efficiency. Unfortunately, these improvements are overshadowed by poor performance. Paradoxically speaking, darcs 2 just isn't fast enough for people to notice how much faster it has gotten! We need somebody to comb through our code and spot the silly things which are making performance suffer. Is there something too strict? Too lazy? Are going about IO completely the wrong way? There is no patch theory needed for this! Anybody with an eye for performance should be able to rip into this code and find something to fix. If you are not an optimisation guru, there are still loads of ways to help. For starters, you could help us to improve our support for Windows, or maybe some of the ProbablyEasy bugs: http://bugs.darcs.net/issue?@columns=title,id,activity,status,assignedto&@filter=topic,status&topic=6&status=-1,1,2,3,4,5,6,7 We will communicate better -------------------------- The darcs 2 release announcement was very frank, but it also painted an inaccurate picture of the situation. Here is a clearer picture: we are all still very interested in darcs and want to keep using it! If you have a large repository and you cannot wait for us to fix performance bugs, we wish you the best with git (etc). But if darcs can handle your repository, we hope you stick around. It is true that David is taking a lower profile, but this just means that he is not following every discussion on the mailing list or every new bug and feature request. David is still receiving patches and reviewing them on a daily basis, providing the usual technical insight. So keep sending those patches! That's all for now ------------------ I am going to leave things here for now, despite all the interesting points we could still address and see where else the discussion leads. In my next reply, I hope to address some of the more of suggestions you have offered. Thanks again! -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/a4c62b79/attachment.bin From vigalchin at gmail.com Wed Aug 6 01:43:55 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Aug 6 01:43:36 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? Message-ID: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> Hello, 1) Is there a common assumed semantics across all of the Haskell "with" things? withString? withData? 2) If the answer to 1) is yes, then does this imply some kind of polymorphism? Couldn't "with" be "reduced" to a higher order function then ?? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/d4419fc3/attachment.htm From ahey at iee.org Wed Aug 6 02:01:04 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 6 02:00:45 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <404396ef0808011554u5fb1dcacldbbce86a6063c957@mail.gmail.com> <30tze27k3v.fsf@Clio.twb.ath.cx> Message-ID: <48993E20.5000503@iee.org> Brandon S. Allbery KF8NH wrote: > (Hm, I feel a blog rant coming on.) I take it you mean as the perfect example of how to kill off interest in your own project :-) I can't help thinking this was so obviously going to happen that it must have been Davids intent at the time he wrote that announcement. The only doubt I have is whether he was just in a grumpy mood at the time and now regrets this, or whether he still feels this way. To answer the OP's question, when I first looked at darcs I was quite enthusastic about it and did indeed consider hacking on it. But a few hours browsing the source code made me realise I would never be able to do this easily because of the lack of decent documentation of source. It was "literate" haskell (which I dislike anyway) and the literate commentation that I could see told me practically nothing about the code I was actually looking at. Instead it was just the markup that would eventually become the user guide (presumably). So as well as having no useful documentation (for a would be contributor) I had make the extra mental effort deliberately avoiding reading the distacting and utterly irrelevant literate commentation clutter. It would have been easier if there was no comments at all. The net result was that I couldn't even figure out what the various functions I was looking at were trying to do (and hence whether of not they might be the source of the bug or performance bottleneck or whatever). Put simply, (as someone else observed earlier) it seemed to me like it was written and organised so as to be unmaintainable by anyone other than David himself. That said, I think by normal the standards of OS projects darcs *user* documentation is very good, but for would be hackers this is not enough (decent source documentation is needed too IMO). I also think Neils idea of breaking darcs up from 1 monolithic prog to a darcs lib suite is a good idea. This would give decent haddock documentation for most of the code base and an easy way to have multiple user interfaces (gui/web/command line based). Regards -- Adrian Hey From ketil at malde.org Wed Aug 6 02:02:09 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Aug 6 02:01:43 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: (Ben Franksen's message of "Tue\, 05 Aug 2008 20\:52\:42 +0200") References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> <87k5exazcd.fsf@malde.org> <87wsiwc6z5.fsf@malde.org> Message-ID: <87iquebs0u.fsf@malde.org> Ben Franksen writes: >> Can I convert my working repos to darcs-2? > No. You cannot push or pull between darcs-2 format repos and darcs-1 or > hashed format repos. This might not be optimal but is understandable, since > the theory underlying the darcs-2 repository format is different. So if I'm pulling from/pushing to a darcs-2-format repo, my local repo must be darcs-2 as well? > The more important problem is that conversion to darcs-2 format doesn't > support multiple branches at all. To make this perfectly clear: this is the *conversion process* only, you can still have multiple branches *after* all repos have been synced to a single conversion. Right?) Should something like this work? darcs convert main main-2 cd branch mv _darcs old_darcs cp -a ../main-2/_darcs . darcs rec -am "amalgam of changes in 'branch'" (But you'd lose your recorded history specific to the branch.) -k -- If I haven't seen further, it is by standing in the footprints of giants From jason.dusek at gmail.com Wed Aug 6 02:30:29 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 6 02:30:08 2008 Subject: [Haskell-cafe] more adjunction questions -- where to send them? Message-ID: <42784f260808052330h10b2f40du4d8fbad6efc472e5@mail.gmail.com> I've gotten most of my category theory help through the Haskell community one way or another, but I hesitate to ask more questions on this list if there is a better forum. Googling turned up an old, closed list. Is there somewhere else I should be asking my questions -- for example, I am now working on the adjunction of "right product" and "exponentiation" -- or is the Haskell Cafe list a good place? -- _jsn From jpm at cs.uu.nl Wed Aug 6 02:45:06 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Wed Aug 6 02:44:45 2008 Subject: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell) In-Reply-To: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> References: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> Message-ID: <52f14b210808052345k2ea65729r778bfc7a7347fbcc@mail.gmail.com> Hi Jinjing, I remember having written a report on Haskore some years ago, together with a classmate. I think that the example of transformations in twelve-tone technique (see [1]) is one that looks very nice in Haskore due to its simplicity. It's also simple to present to people who do not know music theory, but are (minimally) mathematically inclined. Cheers, Pedro [1] http://en.wikipedia.org/wiki/Twelve-tone_technique#Tone_row On Tue, Aug 5, 2008 at 10:59, jinjing wrote: > Hi there, > > Here's the project link: > > http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown > > I found Haskore pretty fun :) so I'm documenting it while learning it. > Please don't hesitate to give suggestions / corrections. > > Questions: > > * How much music theory should be there ? ( I'm gonna learn those anyway ) > * What kind of examples would be cool ? > > regards, > > jinjing > _______________________________________________ > 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/20080806/19ec49d1/attachment.htm From jeremy at n-heptane.com Wed Aug 6 03:20:17 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Aug 6 03:16:02 2008 Subject: [Haskell-cafe] helping you contribute to darcs (poll results so far) In-Reply-To: <20080806052932.GA5571@Macintosh.local> References: <20080806052932.GA5571@Macintosh.local> Message-ID: <871w12txse.wl%jeremy@n-heptane.com> At Wed, 6 Aug 2008 06:29:32 +0100, Eric Y. Kow wrote: > > Dear Haskellers, > > patch theory is still not defined clearly or rigorously enough for Haskellers Are the darcs developers familiar with these papers (available on citeseer): Undo Actions in Collaborative Work, Prakash & Knister 1992 Undoing Actions in Collaborative Work: Framework and Experience, Prakash & Knister 1994 The papers describe an undo mechanism for multiuser collaborative editing which sounds like how I imagine darcs patch theory to be (and, they even run into the dreaded exponential merge bug and propose a solution). They include some formal reasoning that may be easy to adapt to darcs? hope this helps, j. > Last Friday, I had posted a message asking how the darcs community > could a better job recruiting developers to hack on darcs. Thanks for > all the great responses! I am gratified by the suggestions you have > offered, as well as the recent uptick in community involvement. > > The responses so far fall along three themes: offering new features, > improving code accessibility and shaking up the community: > > Features > - GUI (david48, Bit Conner) > - splitting/merging (Luke Palmer, Ben Franksen) > - binary file handling (Jason Dusek) > - ... already does what I want (Allan Clark, Andrew Coppin) > > Code accessibility > - split into libs (Neil Mitchell) > - unit tests! (Ashley Moran) > - code documentation (Lele Gaifax) > - patch theory docs (Apfelmus, Ferenc Wagner) > - inherent simplicity of model, cf git (Austin Seipp) > > Community > - release announcements (Brandon Allbery, Neil Mitchell, Don Stewart) > - showing ways to help (Wren Ng Thorton, Ferenc Wagner) > - announcing our need for help (Wren Ng Thorton) > - easier entry point to darcs code, ? la xmonad (Petr Rockai) > - more active leadership (Don Stewart, Lele Gaifax) > > One thing which is clear is that the darcs team have failed to > communicate effectively: the code is not as well-documented as it should > be, patch theory is still not defined clearly or rigorously enough for > Haskellers, the recent release announcements gave people the impression > that darcs was being abandoned, and we haven't made it clear that we > needed your help. > > We need your help > ----------------- > Hopefully one thing is clearer after this discussion. We definitely > need your help! > > What we need most of all are some Haskell optimisation gurus to join > the project, even in a minor way. Darcs 2 offers some huge improvements > in safety and core efficiency. Unfortunately, these improvements are > overshadowed by poor performance. Paradoxically speaking, darcs 2 just > isn't fast enough for people to notice how much faster it has gotten! > We need somebody to comb through our code and spot the silly things > which are making performance suffer. Is there something too strict? > Too lazy? Are going about IO completely the wrong way? > > There is no patch theory needed for this! Anybody with an eye for > performance should be able to rip into this code and find something > to fix. > > If you are not an optimisation guru, there are still loads of ways to > help. For starters, you could help us to improve our support for > Windows, or maybe some of the ProbablyEasy bugs: > > http://bugs.darcs.net/issue?@columns=title,id,activity,status,assignedto&@filter=topic,status&topic=6&status=-1,1,2,3,4,5,6,7 > > We will communicate better > -------------------------- > The darcs 2 release announcement was very frank, but it also painted an > inaccurate picture of the situation. > > Here is a clearer picture: we are all still very interested in darcs and > want to keep using it! If you have a large repository and you cannot > wait for us to fix performance bugs, we wish you the best with git > (etc). But if darcs can handle your repository, we hope you stick > around. > > It is true that David is taking a lower profile, but this just means > that he is not following every discussion on the mailing list or > every new bug and feature request. David is still receiving patches > and reviewing them on a daily basis, providing the usual technical > insight. So keep sending those patches! > > That's all for now > ------------------ > I am going to leave things here for now, despite all the interesting > points we could still address and see where else the discussion leads. > In my next reply, I hope to address some of the more of suggestions you > have offered. > > Thanks again! > > -- > Eric Kow > PGP Key ID: 08AC04F9 From jeremy at n-heptane.com Wed Aug 6 03:25:41 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Aug 6 03:21:26 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> Message-ID: <87zlnqsiyy.wl%jeremy@n-heptane.com> At Wed, 6 Aug 2008 00:43:55 -0500, Galchin, Vasili wrote: > > [1 ] > [1.1 ] > Hello, > > 1) Is there a common assumed semantics across all of the Haskell "with" > things? withString? withData? A vague semantic is that some resource is acquired, used, and then released. > 2) If the answer to 1) is yes, then does this imply some kind of > polymorphism? Couldn't "with" be "reduced" to a higher order function then > ?? I think Control.Exception.bracket is used to implement many, but not all, of the with* functions. > newThing :: IO a > newThing = ... > destroyThing :: a -> IO b > destroyThing ... > withThing :: (Thing -> IO a) -> IO a > withThing useThing = bracket newThing destroyThing useThing I have not fully answered either of your questions, but hopefully this is a start. j. From vigalchin at gmail.com Wed Aug 6 03:28:08 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Aug 6 03:27:49 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <87zlnqsiyy.wl%jeremy@n-heptane.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> <87zlnqsiyy.wl%jeremy@n-heptane.com> Message-ID: <5ae4f2ba0808060028n7f6ba20dk4f20014e6aca5b98@mail.gmail.com> hmmm .. Jeremy .... http://notes-on-haskell.blogspot.com/2007/03/design-patterns-in-haskell-bracket.html.... thx, vasili On Wed, Aug 6, 2008 at 2:25 AM, Jeremy Shaw wrote: > At Wed, 6 Aug 2008 00:43:55 -0500, > Galchin, Vasili wrote: > > > > [1 ] > > [1.1 ] > > Hello, > > > > 1) Is there a common assumed semantics across all of the Haskell > "with" > > things? withString? withData? > > A vague semantic is that some resource is acquired, used, and then > released. > > > 2) If the answer to 1) is yes, then does this imply some kind of > > polymorphism? Couldn't "with" be "reduced" to a higher order function > then > > ?? > > I think Control.Exception.bracket is used to implement many, but not > all, of the with* functions. > > > newThing :: IO a > > newThing = ... > > > destroyThing :: a -> IO b > > destroyThing ... > > > withThing :: (Thing -> IO a) -> IO a > > withThing useThing = bracket newThing destroyThing useThing > > I have not fully answered either of your questions, but hopefully this > is a start. > > j. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/e719aa42/attachment.htm From vigalchin at gmail.com Wed Aug 6 04:29:00 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Aug 6 04:28:40 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <87zlnqsiyy.wl%jeremy@n-heptane.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> <87zlnqsiyy.wl%jeremy@n-heptane.com> Message-ID: <5ae4f2ba0808060129g1f4d0a24we03cdbd4da04be21@mail.gmail.com> Hi Jeremy and the haskell community, I think now my question is why isn't there a higher-order "with" function in the Haskell Prelude? Regards, Vasili On Wed, Aug 6, 2008 at 2:25 AM, Jeremy Shaw wrote: > At Wed, 6 Aug 2008 00:43:55 -0500, > Galchin, Vasili wrote: > > > > [1 ] > > [1.1 ] > > Hello, > > > > 1) Is there a common assumed semantics across all of the Haskell > "with" > > things? withString? withData? > > A vague semantic is that some resource is acquired, used, and then > released. > > > 2) If the answer to 1) is yes, then does this imply some kind of > > polymorphism? Couldn't "with" be "reduced" to a higher order function > then > > ?? > > I think Control.Exception.bracket is used to implement many, but not > all, of the with* functions. > > > newThing :: IO a > > newThing = ... > > > destroyThing :: a -> IO b > > destroyThing ... > > > withThing :: (Thing -> IO a) -> IO a > > withThing useThing = bracket newThing destroyThing useThing > > I have not fully answered either of your questions, but hopefully this > is a start. > > j. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/171da5fb/attachment.htm From johan.tibell at gmail.com Wed Aug 6 04:54:18 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Aug 6 04:53:57 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> Message-ID: <90889fe70808060154i2de47594rfc2d709e86441690@mail.gmail.com> 2008/8/6 Galchin, Vasili : > Hello, > > 1) Is there a common assumed semantics across all of the Haskell "with" > things? withString? withData? You probably knew this already but there's nothing in the "with idiom" that prevents the resource to escape. Oleg recently wrote about (lightweight) monadic regions and how they can statically assure that this doesn't happen. Cheers, Johan From vigalchin at gmail.com Wed Aug 6 05:09:58 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Aug 6 05:09:38 2008 Subject: [Haskell-cafe] Haskell garbage collector notes? Message-ID: <5ae4f2ba0808060209u7542cf6bpa42571e91397a61f@mail.gmail.com> hello, Is http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes a reliable source of info on the ghc garbage collector? thx, vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/58ec4663/attachment.htm From igloo at earth.li Wed Aug 6 05:48:03 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 6 05:47:45 2008 Subject: [Haskell-cafe] helping you contribute to darcs (poll results so far) In-Reply-To: <871w12txse.wl%jeremy@n-heptane.com> References: <20080806052932.GA5571@Macintosh.local> <871w12txse.wl%jeremy@n-heptane.com> Message-ID: <20080806094803.GA2457@matrix.chaos.earth.li> On Wed, Aug 06, 2008 at 12:20:17AM -0700, Jeremy Shaw wrote: > > Are the darcs developers familiar with these papers (available on citeseer): > > Undo Actions in Collaborative Work, Prakash & Knister 1992 > Undoing Actions in Collaborative Work: Framework and Experience, Prakash & Knister 1994 > > The papers describe an undo mechanism for multiuser collaborative > editing which sounds like how I imagine darcs patch theory to be (and, > they even run into the dreaded exponential merge bug and propose a > solution). > > They include some formal reasoning that may be easy to adapt to darcs? I've just had a quick read of http://citeseer.ist.psu.edu/prakash92undoing.html AFAICS this only really deals with the case where there are no conflicts, and doesn't talk about merging. Thanks Ian From Alistair.Bayley at invesco.com Wed Aug 6 06:00:31 2008 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Wed Aug 6 06:00:39 2008 Subject: [Haskell-cafe] Haskell garbage collector notes? In-Reply-To: <5ae4f2ba0808060209u7542cf6bpa42571e91397a61f@mail.gmail.com> References: <5ae4f2ba0808060209u7542cf6bpa42571e91397a61f@mail.gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E950B@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Galchin, Vasili > > Is > http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes > a reliable source of info on the ghc garbage collector? Depends which version of GHC... the next release (6.10) will include the new parallel GC: http://research.microsoft.com/~simonpj/papers/parallel-gc/index.htm http://hackage.haskell.org/trac/ghc/wiki/Status/Releases Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From mad.one at gmail.com Wed Aug 6 06:01:23 2008 From: mad.one at gmail.com (Austin Seipp) Date: Wed Aug 6 06:01:15 2008 Subject: [Haskell-cafe] Haskell garbage collector notes? In-Reply-To: <5ae4f2ba0808060209u7542cf6bpa42571e91397a61f@mail.gmail.com> References: <5ae4f2ba0808060209u7542cf6bpa42571e91397a61f@mail.gmail.com> Message-ID: <1218016520-sup-253@existential.local> Excerpts from Galchin, Vasili's message of Wed Aug 06 04:09:58 -0500 2008: > Is http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes a > reliable source of info on the ghc garbage collector? The page seems to be a little light for the most part, and it does not seem to take into account the recent changes to give GHC a parallel garbage collector (which is now integrated into the HEAD as far as I can tell.) For notes on the new parallel GC, you will want to see this paper: http://research.microsoft.com/%7Esimonpj/papers/parallel-gc/index.htm You may also want to look through the GHC Commentary regarding the RTS, as I am sure it also contains information you will want to be aware of (there are likely many cross-cutting concerns): http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts In particular, the storage manager overview should be of interest: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage Hope it helps. Austin From lrpalmer at gmail.com Wed Aug 6 06:03:16 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Aug 6 06:02:57 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <5ae4f2ba0808060129g1f4d0a24we03cdbd4da04be21@mail.gmail.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> <87zlnqsiyy.wl%jeremy@n-heptane.com> <5ae4f2ba0808060129g1f4d0a24we03cdbd4da04be21@mail.gmail.com> Message-ID: <7ca3f0160808060303o2e3bc598l758409a14ec77e42@mail.gmail.com> 2008/8/6 Galchin, Vasili > Hi Jeremy and the haskell community, > > I think now my question is why isn't there a higher-order "with" > function in the Haskell Prelude? > There is. Well, not in the prelude, but in the base package at least. It's called "bracket". But I think the reason that not all "with" functions are implemented with bracket is because "with" is not as well defined as a function; it is an idiom, and varies in too many ways to have a well-defined semantics. However, you could presumably abstract this more using typeclasses with fundeps or associated types. class Resource a where type Constr a acquire :: Constr a -> IO a release :: a -> IO () with :: (Resource a) => Constr a -> (a -> IO b) -> IO b with constr = bracket (acquire constr) release I haven't calculated how many of the existing with* functions would fit into this abstraction. Luke > Regards, Vasili > > On Wed, Aug 6, 2008 at 2:25 AM, Jeremy Shaw wrote: > >> At Wed, 6 Aug 2008 00:43:55 -0500, >> Galchin, Vasili wrote: >> > >> > [1 ] >> > [1.1 ] >> > Hello, >> > >> > 1) Is there a common assumed semantics across all of the Haskell >> "with" >> > things? withString? withData? >> >> A vague semantic is that some resource is acquired, used, and then >> released. >> >> > 2) If the answer to 1) is yes, then does this imply some kind of >> > polymorphism? Couldn't "with" be "reduced" to a higher order function >> then >> > ?? >> >> I think Control.Exception.bracket is used to implement many, but not >> all, of the with* functions. >> >> > newThing :: IO a >> > newThing = ... >> >> > destroyThing :: a -> IO b >> > destroyThing ... >> >> > withThing :: (Thing -> IO a) -> IO a >> > withThing useThing = bracket newThing destroyThing useThing >> >> I have not fully answered either of your questions, but hopefully this >> is a start. >> >> j. >> > > > _______________________________________________ > 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/20080806/fcd4be45/attachment.htm From vikrant.patil at gmail.com Wed Aug 6 06:22:36 2008 From: vikrant.patil at gmail.com (Vikrant) Date: Wed Aug 6 06:22:24 2008 Subject: [Haskell-cafe] Re: [haskell-art] Haskore Tutorial In-Reply-To: <81ea7d400808051003i21f30ad4i2bf12266f00aff19@mail.gmail.com> References: <81ea7d400808050633r1158c644t49f3ff62ed7173fb@mail.gmail.com> <20080805163942.0a7dc3f4@ls10pc7> <20080805190052.328d4f6e@ls10pc7> <81ea7d400808051003i21f30ad4i2bf12266f00aff19@mail.gmail.com> Message-ID: Hi, I get this error. I think have zlib installed! what package should I install to compile cabal on my machine (ubuntu - 8.04) Configuring cabal-install-0.5.2... Setup: At least the following dependencies are missing: zlib >=0.4 status of zlib on my machine is as following bahs$ aptitude search zlib p gambas2-gb-compress-bzlib2 - The Gambas bzlib2 component p gambas2-gb-compress-zlib - The Gambas zlib compression component p libcompress-raw-zlib-perl - low-level interface to zlib compression l p libcompress-zlib-perl - Perl module for creation and manipulation p libio-compress-zlib-perl - Perl interface to zlib p libio-zlib-perl - IO:: style interface to Compress::Zlib p libjzlib-java - Reimplementation of zlib in pure java i libzlib-ruby - transitional dummy package v libzlib-ruby1.8 - i zlib-bin - compression library - sample programs i zlib1g - compression library - runtime p zlib1g-dbg - compression library - development i A zlib1g-dev - compression library - development i zlibc - Uncompressing C Library Regards, Vikrant 2008/8/5 jinjing > What I did was to compile from source: > > http://hackage.haskell.org/trac/hackage/wiki/CabalInstall > > notice the darcs repo? > > http://darcs.haskell.org/cabal-install/ > > I used > > runghc Setup configure --user --prefix=$HOME > > to keep packages in user space, i.e. inside ~/.cabal folder. > > > On Wed, Aug 6, 2008 at 1:00 AM, Sebastian Menge > wrote: > > Am Tue, 5 Aug 2008 22:10:16 +0530 > > schrieb Vikrant : > > > >> well, How do I get cabal! on my ubuntu installation it gives me error > >> saying libghc6-cabal-dev depends ghc < 6.6.1 but 6.8.2 installed! > > > > Thats a known bug, but I cant remeber my workaround. Anyways I have > > installed > > > > libhugs-cabal-bundled > > > > IIRC from a gutsy-repository > > > > HTH, Sebastian. > > _______________________________________________ > > haskell-art mailing list > > haskell-art@lurk.org > > http://lists.lurk.org/mailman/listinfo/haskell-art > > > _______________________________________________ > haskell-art mailing list > haskell-art@lurk.org > http://lists.lurk.org/mailman/listinfo/haskell-art > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/be3e11e5/attachment.htm From rendel at daimi.au.dk Wed Aug 6 07:32:28 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Wed Aug 6 07:32:10 2008 Subject: [Haskell-cafe] Re: [haskell-art] Haskore Tutorial In-Reply-To: References: <81ea7d400808050633r1158c644t49f3ff62ed7173fb@mail.gmail.com> <20080805163942.0a7dc3f4@ls10pc7> <20080805190052.328d4f6e@ls10pc7> <81ea7d400808051003i21f30ad4i2bf12266f00aff19@mail.gmail.com> Message-ID: <48998BCC.5040609@daimi.au.dk> Vikrant wrote: > I get this error. I think have zlib installed! what package should I > install to compile cabal on my machine (ubuntu - 8.04) > > Configuring cabal-install-0.5.2... > Setup: At least the following dependencies are missing: > zlib >=0.4 That's the Haskell package zlib, you can get it from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib Tillmann From Christian.Maeder at dfki.de Wed Aug 6 08:40:46 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Aug 6 08:40:29 2008 Subject: [Haskell-cafe] Re: GHC Feature or Bug: f x = (`head` x, ()) In-Reply-To: <874p5zwg4c.wl%jeremy@n-heptane.com> References: <874p5zwg4c.wl%jeremy@n-heptane.com> Message-ID: <48999BCE.8060008@dfki.de> Jeremy Shaw wrote: > Hello, > > GHC is happy to compile this code: > >> f x = (`head` x, ()) Also (+ x, ()) ((), + x) ((), + x, ()) are accepted by GHC This looks like a bug to me, because (+, ()) ((), x +) are rejected. Sections need to be in parens. If one allows sections as tuple components, then the latter should may be made legal, too. Cheers Christian > > but Hugs does not like it, and Section 3.5 of the Haskell Report does > not give any obvious indications that it is valid. Numerous people > have suggested that some additional parens are required: > >> f x = ((`head` x), ()) > > Is this GHC behavior intentional? If not, is it perhaps a happy > accident? Or is it ambigious in some way with out the additional > parenthesis ? > > I am curious because trhsx (the preprocessor for HSP/HSX) currently > does not accept this construct. If it is a bug in GHC (that will > eventually be fixed), then we can leave trhsx alone. If it is a > feature, then a precise definition of the adjusted syntax would be > helpful. (Or, if this construct is valid H98, an explaination of how > to read the report correctly). > > Thanks! > j. From allbery at ece.cmu.edu Wed Aug 6 10:42:52 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 6 10:42:39 2008 Subject: [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <87iquebs0u.fsf@malde.org> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> <87k5exazcd.fsf@malde.org> <87wsiwc6z5.fsf@malde.org> <87iquebs0u.fsf@malde.org> Message-ID: <1B78A7EF-C6F1-44C9-AB26-C67A94B591FF@ece.cmu.edu> On 2008 Aug 6, at 2:02, Ketil Malde wrote: > Ben Franksen writes: > >>> Can I convert my working repos to darcs-2? > >> No. You cannot push or pull between darcs-2 format repos and >> darcs-1 or >> hashed format repos. This might not be optimal but is >> understandable, since >> the theory underlying the darcs-2 repository format is different. > > So if I'm pulling from/pushing to a darcs-2-format repo, my local repo > must be darcs-2 as well? Given that darcs2 has a different format, that's kinda obvious. -- 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 byorgey at seas.upenn.edu Wed Aug 6 11:03:26 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Aug 6 11:03:09 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 80 - August 6, 2008 Message-ID: <20080806150326.GA20321@minus.seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20080806 Issue 80 - August 6, 2008 --------------------------------------------------------------------------- Welcome to issue 80 of HWN, a newsletter covering developments in the [1]Haskell community. Community News Brent Yorgey (byorgey, your friendly neighborhood HWN editor) has completed a move to Philadelphia and looks forward to starting a PhD in the programming languages group at U Penn next month. Roman Cheplyaka (Feuerbach) won second prize at the 2008 [2]International Mathematics Competition! Announcements prof2dot, version 0.4.1. Gregory Wright [3]announced the release of prof2dot, a graphical profiling tool for use with GHC. prof2dot is a filter that takes the profiling output generated by running a GHC-compiled program with the "+RTS -pix -RTS", option and turns it into a graphviz dot file. GHC switching to git. Simon Marlow [4]announced that the GHC team has made the decision to switch the version control system hosting the GHC repository from darcs to git. Haddock 2.2.1. David Waern [5]announced the release of version 2.2.1 of Haddock, the Haskell documentation tool. Haskore tutorial. jinjing is creating [6]a Haskore tutorial while learning it. Suggestions and corrections are welcome. Hoogle 4 beta. Neil Mitchell [7]announced the availability of beta versions of Hoogle 4, both a [8]web client and [9]command-line version. Testing and [10]feedback welcome! Design your own xmonad shirt. David Lazar has prepared a design on [11]spreadshirt under Designs > Computer > Programming. Choose the color and other formatting and get your very own custom xmonad shirt! Google Summer of Code Progress updates from participants in the 2008 [12]Google Summer of Code. Generic tries. Jamie Brandon is working on a library for efficient maps using generalized tries. This week, he has worked on implementing AVL trees and has created several [13]more [14]benchmarks. Hoogle 4. Neil Mitchell (ndm) is working on [15]Hoogle 4. [16]This week, he finished up type search, which now gives much better results than Hoogle 3. He also [17]released a [18]public beta version of the command-line interface. [19]Bug reports or feature requests are welcome. DPH physics engine. Roman Cheplyaka (Feuerbach) is working on a [20]physics engine using [21]Data Parallel Haskell. [22]Last week, he won second prize at the 2008 International Mathematics Competition; while he was away he also found time to read several papers on broad phase collision detection and to begin thinking about [23]general convex polyhedra. GHC plugins. Max Bolingbroke is working on dynamically loaded plugins for GHC. Cabal dependency framework. Andrea Vezzosi (Saizan) is working on a [24]make-like dependency analysis framework for Cabal. Language.C. Benedikt Huber (visq) is [25]working on Language.C, a standalone parser/pretty printer library for C99. GHC API. Thomas Schilling (nominolo) is working on [26]improvements to the GHC API. Discussion poll: how can we help you contribute to darcs?. Eric Kow (kowey) [27]asked how the darcs team could better encourage more people to contribute, precipitating a long and productive discussion with many good suggestions. Jobs Lectureship in Functional Programming, Nottingham. Graham Hutton [28]announced an opening for a Lecturer (Assistant Professor) in the Functional Programming Lab in Nottingham, a recently formed research group that comprises Thorsten Altenkirch, Graham Hutton, Henrik Nilsson, four research fellows, and eleven PhD students. Applications from the Haskell community are encouraged! The closing date for applications is Friday, 15th August 2008. Blog noise [29]Haskell news from the [30]blogosphere. * Roman Cheplyaka: [31]Physics and polyhedra. * Chris Done: [32]Kibro: Haskell, lighttpd and fastcgi. * Neil Mitchell: [33]Hoogle 4.0 web client preview. * >>> Sven Heyll: [34]Lazy Evaluation (there be dragons and basement cats). * Clifford Beshers: [35]Two-dimensional zip. * Brent Yorgey: [36]Philadelphia!. * Luke Plant: [37]Haskell API docs suck. A lot.. * Neil Mitchell: [38]Hoogle 4.0 release (beta, command line). * Mikael Johansson (Syzygy-): [39]The end of the line. * Jamie Brandon: [40]Yet more mini benchmarks. * Douglas M. Auclair (geophf): [41]Combinators in Haskell. * Holumbus: [42]Search Packages. * Douglas M. Auclair (geophf): [43]How do I get better?. * Neil Mitchell: [44]GSoC Hoogle: Week 10. * Dan Piponi (sigfpe): [45]Hopf Algebra = Group + Monad. * >>> Ayumilove: [46]Haskell Programming Tutorial Part 4. * Douglas M. Auclair (geophf): [47]Trivial Monad solutions. * Douglas M. Auclair (geophf): [48]Trivial Monad solutions (cont.). * Douglas M. Auclair (geophf): [49]Orators' exercise. * Roman Cheplyaka: [50]Status report: week 9-10. * Matthew Sackman: [51]Reflections on the ICFP Programming Contest 2008. * Jamie Brandon: [52]More benchmarks. * Chris Done: [53]GHCi on Acid (GOA). * Audrey Tang: [54]Pugs now builds again from SVN.. * "FP Lunch": [55]An ad-hoc approach to productive definitions. * Ketil Malde: [56]A plan for Bloom filters. * Audrey Tang: [57]Pugs.hs is back.. * Holumbus: [58]OpenSearch Available Again. Quotes of the Week * shepheb: don't forget YMCArray * matthew-_: you know I increasingly think I'm a very bad haskell programmer - I spend all my time programming at the type level, which is basically untyped. So I just write untyped programs, that happen to run at compile time. * SyntaxNinja: just picture monads as tiny, silly, luminous, and devious sprites who fly around your haskell code carrying state from one piece of code to another. I don't think that'll help, but it can't hurt. * poetix: Avoiding lambdas is pointless <-- *groan* * kzm: My program contains a bug. How ungrateful, after all I've done for it. * sw17ch: FunPtrs do not live up to their name About the Haskell Weekly News New editions are posted to [59]the Haskell mailing list as well as to [60]the Haskell Sequence and [61]Planet Haskell. [62]RSS is also available, and headlines appear on [63]haskell.org. Headlines are available as [64]PDF. To help create new editions of this newsletter, please see the information on [65]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [66]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://imc-math.org/ 3. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/14821 4. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/14819 5. http://www.haskell.org//pipermail/haskell-cafe/2008-August/045791.html 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/42861 7. http://neilmitchell.blogspot.com/2008/08/hoogle-40-web-client-preview.html 8. http://haskell.org/hoogle/beta/ 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hoogle 10. http://code.google.com/p/ndmitchell/issues/list 11. http://spreadshirt.com/ 12. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 13. http://jamiiecb.blogspot.com/2008/08/more-benchmarks.html 14. http://jamiiecb.blogspot.com/2008/08/yet-more-mini-benchmarks.html 15. http://code.haskell.org/hoogle/ 16. http://neilmitchell.blogspot.com/2008/08/gsoc-hoogle-week-10.html 17. http://neilmitchell.blogspot.com/2008/08/hoogle-40-release-beta-command-line.html 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hoogle 19. http://code.google.com/p/ndmitchell/issues/list 20. http://haskell.org/haskellwiki/Hpysics 21. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell 22. http://physics-dph.blogspot.com/2008/08/status-report-week-9-10.html 23. http://physics-dph.blogspot.com/2008/08/physics-and-polyhedra.html 24. http://code.haskell.org/~Saizan/cabal 25. http://www.sivity.net/projects/language.c/wiki/ 26. http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus 27. http://www.haskell.org//pipermail/haskell-cafe/2008-August/045701.html 28. http://article.gmane.org/gmane.comp.lang.haskell.general/16365 29. http://planet.haskell.org/ 30. http://haskell.org/haskellwiki/Blog_articles 31. http://physics-dph.blogspot.com/2008/08/physics-and-polyhedra.html 32. http://chrisdone.com/blog/2008/08/06/kibro-haskell-lighttpd-and-fastcgi/ 33. http://neilmitchell.blogspot.com/2008/08/hoogle-40-web-client-preview.html 34. http://sheyll.blogspot.com/2008/08/lazy-evaluation-there-be-dragons-and.html 35. http://cliffordbeshers.blogspot.com/2008/08/two-dimensional-zip.html 36. http://byorgey.wordpress.com/2008/08/04/philadelphia/ 37. http://lukeplant.me.uk/blog.php?id=1107301692 38. http://neilmitchell.blogspot.com/2008/08/hoogle-40-release-beta-command-line.html 39. http://blog.mikael.johanssons.org/archive/2008/08/the-end-of-the-line/ 40. http://jamiiecb.blogspot.com/2008/08/yet-more-mini-benchmarks.html 41. http://logicaltypes.blogspot.com/2008/08/combinators-in-haskell.html 42. http://holumbus.fh-wedel.de/blog/?p=14 43. http://logicaltypes.blogspot.com/2008/08/how-do-i-get-better.html 44. http://neilmitchell.blogspot.com/2008/08/gsoc-hoogle-week-10.html 45. http://sigfpe.blogspot.com/2008/08/hopf-algebra-group-monad.html 46. http://www.5min.com/Video/Ayumilove-Haskell-Programming-Tutorial-Part-4-32807921?src=rss 47. http://logicaltypes.blogspot.com/2008/05/trivial-monad-solutions.html 48. http://logicaltypes.blogspot.com/2008/05/trivial-monad-solutions-cont.html 49. http://logicaltypes.blogspot.com/2008/05/orators-exercise.html 50. http://physics-dph.blogspot.com/2008/08/status-report-week-9-10.html 51. http://www.wellquite.org/icfp_contest_2008_reflections.html 52. http://jamiiecb.blogspot.com/2008/08/more-benchmarks.html 53. http://chrisdone.com/blog/2008/08/01/ghci-on-acid-goa/ 54. http://pugs.blogs.com/pugs/2008/08/pugs-now-builds.html 55. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=109 56. http://blog.malde.org/index.php/2008/07/31/a-plan-for-bloom-filters/ 57. http://pugs.blogs.com/pugs/2008/07/pugshs-is-back.html 58. http://holumbus.fh-wedel.de/blog/?p=13 59. http://www.haskell.org/mailman/listinfo/haskell 60. http://sequence.complete.org/ 61. http://planet.haskell.org/ 62. http://sequence.complete.org/node/feed 63. http://haskell.org/ 64. http://code.haskell.org/~byorgey/code/hwn/archives/20080806.pdf 65. http://haskell.org/haskellwiki/HWN 66. http://code.haskell.org/~byorgey/code/hwn/ From jules at jellybean.co.uk Wed Aug 6 11:44:52 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Aug 6 11:44:25 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <90889fe70808060154i2de47594rfc2d709e86441690@mail.gmail.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> <90889fe70808060154i2de47594rfc2d709e86441690@mail.gmail.com> Message-ID: <4899C6F4.90907@jellybean.co.uk> Johan Tibell wrote: > 2008/8/6 Galchin, Vasili : >> Hello, >> >> 1) Is there a common assumed semantics across all of the Haskell "with" >> things? withString? withData? > > You probably knew this already but there's nothing in the "with idiom" > that prevents the resource to escape. And, it doesn't always matter. Some withs are more unsafe that others :) if the 'with' constructs a nice ordinary heap allocated haskell structure from the external resource then it may not matter one jot if it escapes: it may be out-of-date, perhaps, but still a useful data value. On the other hand sometimes it does matter.... > Oleg recently wrote about > (lightweight) monadic regions and how they can statically assure that > this doesn't happen. > Which is clever. From johan.tibell at gmail.com Wed Aug 6 12:21:58 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Aug 6 12:21:37 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <4899C6F4.90907@jellybean.co.uk> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> <90889fe70808060154i2de47594rfc2d709e86441690@mail.gmail.com> <4899C6F4.90907@jellybean.co.uk> Message-ID: <90889fe70808060921y178731e2o539a64f30d512d25@mail.gmail.com> On Wed, Aug 6, 2008 at 5:44 PM, Jules Bean wrote: > Johan Tibell wrote: >> You probably knew this already but there's nothing in the "with idiom" >> that prevents the resource to escape. > > And, it doesn't always matter. Some withs are more unsafe that others :) > > if the 'with' constructs a nice ordinary heap allocated haskell structure > from the external resource then it may not matter one jot if it escapes: it > may be out-of-date, perhaps, but still a useful data value. I'm sure you're right but at the moment I can't really think of any such structure. Perhaps you could give an example? Why would you need the "with" in the first place for such a structure? Cheers, Johan From jonathanccast at fastmail.fm Wed Aug 6 12:32:41 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 6 12:34:10 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <90889fe70808060921y178731e2o539a64f30d512d25@mail.gmail.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> <90889fe70808060154i2de47594rfc2d709e86441690@mail.gmail.com> <4899C6F4.90907@jellybean.co.uk> <90889fe70808060921y178731e2o539a64f30d512d25@mail.gmail.com> Message-ID: <1218040361.10631.37.camel@jcchost> On Wed, 2008-08-06 at 18:21 +0200, Johan Tibell wrote: > On Wed, Aug 6, 2008 at 5:44 PM, Jules Bean wrote: > > Johan Tibell wrote: > >> You probably knew this already but there's nothing in the "with idiom" > >> that prevents the resource to escape. > > > > And, it doesn't always matter. Some withs are more unsafe that others :) > > > > if the 'with' constructs a nice ordinary heap allocated haskell structure > > from the external resource then it may not matter one jot if it escapes: it > > may be out-of-date, perhaps, but still a useful data value. > > I'm sure you're right but at the moment I can't really think of any > such structure. Perhaps you could give an example? Why would you need > the "with" in the first place for such a structure? http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html withMVar :: MVar a -> (a -> IO b) -> IO b (useful for synchronization, among other things). modifyMVar :: MVar a -> (a -> IO (a, b)) -> IO b although that isn't quite within the boundaries of what `bracket' can do. jcc From aneumann at inf.fu-berlin.de Wed Aug 6 12:43:04 2008 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Wed Aug 6 12:45:55 2008 Subject: [Haskell-cafe] Looking for a more functional way to do this In-Reply-To: <4165d3a70808041504l92b9ff6u90e9e031dcd7b580@mail.gmail.com> References: <4165d3a70808041504l92b9ff6u90e9e031dcd7b580@mail.gmail.com> Message-ID: <4899D498.2080504@inf.fu-berlin.de> There is the State Monad which is build just for that kind of purpose, I believe: http://www.haskell.org/all_about_monads/html/statemonad.html That would safe you from passing around the State Jefferson Heard schrieb: > Working with HOpenGL and GLUT, I find myself approaching a common > problem with a common solution that I don't really like all that much, > as it reeks of procedural programming. Basically the problem is that > of complex program state, such that when the user provides input to > the program in the form of a mouse click or a typed string or > character, the program updates its internal state to reflect this, > whether that's changing the rotation, scale, or position of a screen > element, or deciding what data to have loaded from disc. > > What I often do is something that looks like this: > > data ProgramState = ProgramState { > some_associative_data :: Map String String > , position :: GL.Vector3 Float > , look_at :: GL Vector3 Float > , selectables :: Map GLuint NamedObject > } > > render :: IORef ProgramState -> IO () > render state = do > st <- readIORef state > ... > > handleMouseClicks :: IORef ProgramState -> GLUT.KeyboardMouseHandler > handleMouseClicks state ... = do > st <- readIORef state > ... > > main = do > ... > let st = ProgramState { Map.empty ... } > render' = render st > mouse' = handleMouseClicks st > > GLUT.renderCallback $= render > GLUT.keyboardMouseCallback $= Just mouse' > > and so on and so forth. Generally there are not fewer than 5 and not > more than about 32 variables that I have to track between mouse > clicks, and there's all this boilerplate code as well. I'm searching > for a better way to do this, and I feel sure there is one. I'm > considering using Template Haskell or possibly SYB to generate this > code, but it also seems like I also ought to be able to declare some > kind of state monad or continuation monad that can encapsulate > ProgramState without having to declare an explicit structure for it > everytime. > > For one thing, I'd like to genericize this code and write something > akin to Processing for Haskell (http://www.processing.org). > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/1adbe139/signature.bin From ryani.spam at gmail.com Wed Aug 6 14:03:05 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Aug 6 14:02:45 2008 Subject: [Haskell-cafe] Show me In-Reply-To: <1217994105.6389.1.camel@jonathans-macbook> References: <4898A9E9.1060503@btinternet.com> <1217994105.6389.1.camel@jonathans-macbook> Message-ID: <2f9b2d30808061103l1bec494ft42b3581f4b54fcca@mail.gmail.com> You may find this helper function useful: > showAp :: Show a => Int -> String -> a -> ShowS > showAp n f x = showParen (n > ap_prec) inside > where > inside = showString f . showString " " . showsPrec (app_prec+1) x > ap_prec = 10 -- "precedence" of function application; higher than any infix operator. You can use it like so: > instance Show x => Show (Foo x) where > showsPrec n foo = showAp n "list_foo" (foo_list foo) See the Haskell 98 report section 10.5 "Derived Instances: An Example": http://www.haskell.org/onlinereport/derived.html -- ryan On Tue, Aug 5, 2008 at 8:41 PM, Jonathan Cast wrote: > On Tue, 2008-08-05 at 20:28 +0100, Andrew Coppin wrote: >> Suppose we have the following: >> >> data Foo x >> list_foo :: [x] -> Foo x >> foo_list :: Foo x -> [x] >> >> What would be the best way to write a Show instance? >> >> The thing that I came up with is >> >> instance (Show x) => Show (Foo x) where >> show foo = "list_foo " ++ show (foo_list foo) >> >> But apparently you're supposed to use the strange "showsPrec" method >> that I don't understand. So can somebody show me a correct instance >> definition for this type please? > > instance Show x => Show (Foo x) where > showsPrec n foo = ("list_foo "++) . shows (foo_list foo) > > You use the n parameter if you've got an infix operator in your syntax > and you want to put parentheses around an instance of it if n has the > wrong value (either too high or too low, I can never remember). > > jcc > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jeremy at n-heptane.com Wed Aug 6 14:28:58 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Aug 6 14:24:41 2008 Subject: [Haskell-cafe] helping you contribute to darcs (poll results so far) In-Reply-To: <20080806094803.GA2457@matrix.chaos.earth.li> References: <20080806052932.GA5571@Macintosh.local> <871w12txse.wl%jeremy@n-heptane.com> <20080806094803.GA2457@matrix.chaos.earth.li> Message-ID: <87y73aro9h.wl%jeremy@n-heptane.com> At Wed, 6 Aug 2008 10:48:03 +0100, Ian Lynagh wrote: > I've just had a quick read of > http://citeseer.ist.psu.edu/prakash92undoing.html > AFAICS this only really deals with the case where there are no > conflicts, and doesn't talk about merging. AFAIK, the papers do not talking about merging. They cover conflicts in the case where you want to remove/reorder an older patch which conflicts with a newer one. But, they do not cover conflicts happening during a merge. Based on those papers, and no knowledge of how darcs actually works I can only assume a merge works something like this: 1. find the common patches in both repos and reorder them to be at the beginning. 2. in some order apply the rest of the patches. When a conflict occurs, put some conflict markers in the file. Obviously, there are some big gaps in my understanding :) It is my hope that the framework and lemmas in those papers could be extended to include merging, etc. But, that assumes that the darcs patch theory and their multiple selective undo are sufficiently similar, which is beyond my knowledge. I have implemented some of the ideas from those papers here: http://src.seereason.com/collaborate/ Assuming the two systems are sufficiently similar, I would be interested in extending it to support darcs style merging. It seems like having a small (~200 lines) file which implements the core concepts of darcs patch theory in simplified context might be a useful way to learn about it ? Since I don't know the darcs internals or patch theory, I don't have a concept of how much is still missing (from those papers and my code), and I am not sure what parts of the darcs patch theory are giving people trouble. So, if this stuff is not valuable, I will not be suprised. But, if it is at all valuable, I would feel stupid not sharing it :) j. From jefferson.r.heard at gmail.com Wed Aug 6 14:27:47 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Wed Aug 6 14:27:26 2008 Subject: [Haskell-cafe] Looking for a more functional way to do this In-Reply-To: <4899D498.2080504@inf.fu-berlin.de> References: <4165d3a70808041504l92b9ff6u90e9e031dcd7b580@mail.gmail.com> <4899D498.2080504@inf.fu-berlin.de> Message-ID: <4165d3a70808061127y543d4d9cm249d22d146e32c26@mail.gmail.com> Adrian, my understanding is that it's not that simple, because I need to preserve the state between calls to GLUT's callbacks, which all return IO (). 2008/8/6 Adrian Neumann : > There is the State Monad which is build just for that kind of purpose, I > believe: > > http://www.haskell.org/all_about_monads/html/statemonad.html > > That would safe you from passing around the State > > Jefferson Heard schrieb: >> >> Working with HOpenGL and GLUT, I find myself approaching a common >> problem with a common solution that I don't really like all that much, >> as it reeks of procedural programming. Basically the problem is that >> of complex program state, such that when the user provides input to >> the program in the form of a mouse click or a typed string or >> character, the program updates its internal state to reflect this, >> whether that's changing the rotation, scale, or position of a screen >> element, or deciding what data to have loaded from disc. >> >> What I often do is something that looks like this: >> >> data ProgramState = ProgramState { >> some_associative_data :: Map String String >> , position :: GL.Vector3 Float >> , look_at :: GL Vector3 Float >> , selectables :: Map GLuint NamedObject >> } >> >> render :: IORef ProgramState -> IO () >> render state = do >> st <- readIORef state >> ... >> >> handleMouseClicks :: IORef ProgramState -> GLUT.KeyboardMouseHandler >> handleMouseClicks state ... = do >> st <- readIORef state >> ... >> >> main = do >> ... >> let st = ProgramState { Map.empty ... } >> render' = render st >> mouse' = handleMouseClicks st >> >> GLUT.renderCallback $= render >> GLUT.keyboardMouseCallback $= Just mouse' >> >> and so on and so forth. Generally there are not fewer than 5 and not >> more than about 32 variables that I have to track between mouse >> clicks, and there's all this boilerplate code as well. I'm searching >> for a better way to do this, and I feel sure there is one. I'm >> considering using Template Haskell or possibly SYB to generate this >> code, but it also seems like I also ought to be able to declare some >> kind of state monad or continuation monad that can encapsulate >> ProgramState without having to declare an explicit structure for it >> everytime. >> >> For one thing, I'd like to genericize this code and write something >> akin to Processing for Haskell (http://www.processing.org). >> _______________________________________________ >> 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 > > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From claudiusmaximus at goto10.org Wed Aug 6 14:39:24 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Wed Aug 6 14:39:13 2008 Subject: [Haskell-cafe] Looking for a more functional way to do this In-Reply-To: <4165d3a70808061127y543d4d9cm249d22d146e32c26@mail.gmail.com> References: <4165d3a70808041504l92b9ff6u90e9e031dcd7b580@mail.gmail.com> <4899D498.2080504@inf.fu-berlin.de> <4165d3a70808061127y543d4d9cm249d22d146e32c26@mail.gmail.com> Message-ID: <4899EFDC.30508@goto10.org> Jefferson Heard wrote: > Adrian, my understanding is that it's not that simple, because I need > to preserve the state between calls to GLUT's callbacks, which all > return IO (). Then maybe see: http://www.haskell.org/pipermail/haskell-cafe/2007-July/028501.html > 2008/8/6 Adrian Neumann : >> There is the State Monad which is build just for that kind of purpose, I >> believe: >> >> http://www.haskell.org/all_about_monads/html/statemonad.html >> >> That would safe you from passing around the State >> >> Jefferson Heard schrieb: >>> Working with HOpenGL and GLUT, [snip] Claude From igloo at earth.li Wed Aug 6 14:59:11 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 6 14:58:53 2008 Subject: [Haskell-cafe] helping you contribute to darcs (poll results so far) In-Reply-To: <87y73aro9h.wl%jeremy@n-heptane.com> References: <20080806052932.GA5571@Macintosh.local> <871w12txse.wl%jeremy@n-heptane.com> <20080806094803.GA2457@matrix.chaos.earth.li> <87y73aro9h.wl%jeremy@n-heptane.com> Message-ID: <20080806185911.GA32189@matrix.chaos.earth.li> On Wed, Aug 06, 2008 at 11:28:58AM -0700, Jeremy Shaw wrote: > At Wed, 6 Aug 2008 10:48:03 +0100, > Ian Lynagh wrote: > > > I've just had a quick read of > > http://citeseer.ist.psu.edu/prakash92undoing.html > > AFAICS this only really deals with the case where there are no > > conflicts, and doesn't talk about merging. > > AFAIK, the papers do not talking about merging. > > They cover conflicts in the case where you want to remove/reorder an > older patch which conflicts with a newer one. Only in the case where you have already undone the newer one, and thus can just remove both the new patch and its inverse, I thought. > Since I don't know the darcs internals or patch theory, I don't have a > concept of how much is still missing The difficult part is still missing :-) Thanks Ian From allbery at ece.cmu.edu Wed Aug 6 10:42:52 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 6 15:08:34 2008 Subject: [darcs-users] [Haskell-cafe] Re: poll: how can we help you contribute to darcs? In-Reply-To: <87iquebs0u.fsf@malde.org> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> <87k5exazcd.fsf@malde.org> <87wsiwc6z5.fsf@malde.org> <87iquebs0u.fsf@malde.org> Message-ID: <1B78A7EF-C6F1-44C9-AB26-C67A94B591FF@ece.cmu.edu> On 2008 Aug 6, at 2:02, Ketil Malde wrote: > Ben Franksen writes: > >>> Can I convert my working repos to darcs-2? > >> No. You cannot push or pull between darcs-2 format repos and >> darcs-1 or >> hashed format repos. This might not be optimal but is >> understandable, since >> the theory underlying the darcs-2 repository format is different. > > So if I'm pulling from/pushing to a darcs-2-format repo, my local repo > must be darcs-2 as well? Given that darcs2 has a different format, that's kinda obvious. -- 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 _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users From jeremy at n-heptane.com Wed Aug 6 03:20:17 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Aug 6 15:50:15 2008 Subject: [darcs-users] [Haskell-cafe] helping you contribute to darcs (poll results so far) In-Reply-To: <20080806052932.GA5571@Macintosh.local> References: <20080806052932.GA5571@Macintosh.local> Message-ID: <871w12txse.wl%jeremy@n-heptane.com> At Wed, 6 Aug 2008 06:29:32 +0100, Eric Y. Kow wrote: > > Dear Haskellers, > > patch theory is still not defined clearly or rigorously enough for Haskellers Are the darcs developers familiar with these papers (available on citeseer): Undo Actions in Collaborative Work, Prakash & Knister 1992 Undoing Actions in Collaborative Work: Framework and Experience, Prakash & Knister 1994 The papers describe an undo mechanism for multiuser collaborative editing which sounds like how I imagine darcs patch theory to be (and, they even run into the dreaded exponential merge bug and propose a solution). They include some formal reasoning that may be easy to adapt to darcs? hope this helps, j. > Last Friday, I had posted a message asking how the darcs community > could a better job recruiting developers to hack on darcs. Thanks for > all the great responses! I am gratified by the suggestions you have > offered, as well as the recent uptick in community involvement. > > The responses so far fall along three themes: offering new features, > improving code accessibility and shaking up the community: > > Features > - GUI (david48, Bit Conner) > - splitting/merging (Luke Palmer, Ben Franksen) > - binary file handling (Jason Dusek) > - ... already does what I want (Allan Clark, Andrew Coppin) > > Code accessibility > - split into libs (Neil Mitchell) > - unit tests! (Ashley Moran) > - code documentation (Lele Gaifax) > - patch theory docs (Apfelmus, Ferenc Wagner) > - inherent simplicity of model, cf git (Austin Seipp) > > Community > - release announcements (Brandon Allbery, Neil Mitchell, Don Stewart) > - showing ways to help (Wren Ng Thorton, Ferenc Wagner) > - announcing our need for help (Wren Ng Thorton) > - easier entry point to darcs code, ? la xmonad (Petr Rockai) > - more active leadership (Don Stewart, Lele Gaifax) > > One thing which is clear is that the darcs team have failed to > communicate effectively: the code is not as well-documented as it should > be, patch theory is still not defined clearly or rigorously enough for > Haskellers, the recent release announcements gave people the impression > that darcs was being abandoned, and we haven't made it clear that we > needed your help. > > We need your help > ----------------- > Hopefully one thing is clearer after this discussion. We definitely > need your help! > > What we need most of all are some Haskell optimisation gurus to join > the project, even in a minor way. Darcs 2 offers some huge improvements > in safety and core efficiency. Unfortunately, these improvements are > overshadowed by poor performance. Paradoxically speaking, darcs 2 just > isn't fast enough for people to notice how much faster it has gotten! > We need somebody to comb through our code and spot the silly things > which are making performance suffer. Is there something too strict? > Too lazy? Are going about IO completely the wrong way? > > There is no patch theory needed for this! Anybody with an eye for > performance should be able to rip into this code and find something > to fix. > > If you are not an optimisation guru, there are still loads of ways to > help. For starters, you could help us to improve our support for > Windows, or maybe some of the ProbablyEasy bugs: > > http://bugs.darcs.net/issue?@columns=title,id,activity,status,assignedto&@filter=topic,status&topic=6&status=-1,1,2,3,4,5,6,7 > > We will communicate better > -------------------------- > The darcs 2 release announcement was very frank, but it also painted an > inaccurate picture of the situation. > > Here is a clearer picture: we are all still very interested in darcs and > want to keep using it! If you have a large repository and you cannot > wait for us to fix performance bugs, we wish you the best with git > (etc). But if darcs can handle your repository, we hope you stick > around. > > It is true that David is taking a lower profile, but this just means > that he is not following every discussion on the mailing list or > every new bug and feature request. David is still receiving patches > and reviewing them on a daily basis, providing the usual technical > insight. So keep sending those patches! > > That's all for now > ------------------ > I am going to leave things here for now, despite all the interesting > points we could still address and see where else the discussion leads. > In my next reply, I hope to address some of the more of suggestions you > have offered. > > Thanks again! > > -- > Eric Kow > PGP Key ID: 08AC04F9 _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users From brianh at metamilk.com Wed Aug 6 16:34:31 2008 From: brianh at metamilk.com (Brian Hulley) Date: Wed Aug 6 16:33:45 2008 Subject: [Haskell-cafe] Looking for a more functional way to do this In-Reply-To: <4165d3a70808061127y543d4d9cm249d22d146e32c26@mail.gmail.com> References: <4165d3a70808041504l92b9ff6u90e9e031dcd7b580@mail.gmail.com> <4899D498.2080504@inf.fu-berlin.de> <4165d3a70808061127y543d4d9cm249d22d146e32c26@mail.gmail.com> Message-ID: <489A0AD7.40603@metamilk.com> Jefferson Heard wrote: > Adrian, my understanding is that it's not that simple, because I need > to preserve the state between calls to GLUT's callbacks, which all > return IO (). > > 2008/8/6 Adrian Neumann : >> There is the State Monad... >>> >>> >>> data ProgramState = ProgramState { >>> some_associative_data :: Map String String >>> , position :: GL.Vector3 Float >>> , look_at :: GL Vector3 Float >>> , selectables :: Map GLuint NamedObject >>> } >>> >>> render :: IORef ProgramState -> IO () You might find it easier to think in terms of a Reader monad where each component of your ProgramState above is now a separate IORef. Then you can just use a function: mkCallback :: ReaderT ProgramStateRefs IO () -> IO () to create the necessary callbacks for GLUT, and there is no need to interleave any state between calls (since it's all kept in the IO monad directly). Eg: data ProgramStateRefs = ProgramStateRefs { some_associative_data :: IORef (Map String String) , ... } main = do r <- createProgramStateRefs let mkCallback :: ReaderT ProgramStateRefs IO a -> IO a mkCallback (ReaderT r_ma) = r_ma r GLUT.renderCallback $= mkCallback onRender ... onRender :: ReaderT ProgramStateRefs IO () onRender = do ... You can then go further and use phantom types to build specialized monads by newtyping the (ReaderT ProgramStateRefs IO) to limit the operations possible in each callback (e.g. to prevent calls to rendering methods inside a keyboard handler etc) though at some point there is a tradeoff between how much you really need to enforce statically and how much time you have to devise suitable schemes of phantom type parameters to enforce it. (Disclaimer: the above code is untested and may contain errors ;-) ) Regards, Brian. From jeremy at n-heptane.com Wed Aug 6 16:41:23 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed Aug 6 16:37:04 2008 Subject: [Haskell-cafe] helping you contribute to darcs (poll results so far) In-Reply-To: <20080806185911.GA32189@matrix.chaos.earth.li> References: <20080806052932.GA5571@Macintosh.local> <871w12txse.wl%jeremy@n-heptane.com> <20080806094803.GA2457@matrix.chaos.earth.li> <87y73aro9h.wl%jeremy@n-heptane.com> <20080806185911.GA32189@matrix.chaos.earth.li> Message-ID: <87tzdxswp8.wl%jeremy@n-heptane.com> At Wed, 6 Aug 2008 19:59:11 +0100, Ian Lynagh wrote: > > On Wed, Aug 06, 2008 at 11:28:58AM -0700, Jeremy Shaw wrote: > > At Wed, 6 Aug 2008 10:48:03 +0100, > > Ian Lynagh wrote: > > > > > I've just had a quick read of > > > http://citeseer.ist.psu.edu/prakash92undoing.html > > > AFAICS this only really deals with the case where there are no > > > conflicts, and doesn't talk about merging. > > > > AFAIK, the papers do not talking about merging. > > > > They cover conflicts in the case where you want to remove/reorder an > > older patch which conflicts with a newer one. > > Only in the case where you have already undone the newer one, and thus > can just remove both the new patch and its inverse, I thought. That sounds right to me. > > Since I don't know the darcs internals or patch theory, I don't have a > > concept of how much is still missing > > The difficult part is still missing :-) Right, but is the difficulty in thinking up the ideas and figuring out solutions to the problems ? Or is the implementation also neccessarily very large and complex (even if implemented in my toy code which only has two operations: 'insert' and 'delete') I guess the best question is, how far from reality is the theory of patches as written in the darcs manual: http://darcs.net/manual/node8.html Is the additional complexity/difficulty in actually implementing functions like unwind, or is there just a bunch more theory missing from that page? Would a function like unwind be easier to implement, if it was done in my toy setting, and if I did not care about efficiency and computational complexity? thanks! j. From jason.dusek at gmail.com Wed Aug 6 16:56:08 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 6 16:55:46 2008 Subject: [Haskell-cafe] adjunction of product and exponentiation Message-ID: <42784f260808061356x6d27fe11ud37b919f3a40f87f@mail.gmail.com> The problem as stated is to find the unit for the adjunction: ((- x A), (-)^A x A) The latter functor takes an arrow f to (f . -) x id_A and does the obvious thing for objects. The co-unit diagram is given as: B^A x A ---- eval_AB ----> B ^ ^ | | | | curry(g) x id_A g : C x A -> B | | | | | | C x A --------------------+ This diagram is somewhat puzzling, because it seems the second functor has turned into (-)^A ! Continuing in with that, we get a unit diagram like this: C ---- magic ----> (C x A)^A | | | | | | curry(g) (g . -) | | | | | v +------------------> B^A So what is the magic? It is an arrow that takes a C to an arrow that takes an A and makes the product C x A. I want to write curry(C x A) but that is ridiculous looking. What's the right notation for this thing? -- _jsn From briqueabraque at yahoo.com Wed Aug 6 17:11:50 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Wed Aug 6 17:11:39 2008 Subject: [Haskell-cafe] USB and serial port Message-ID: Hi, What are the alternatives to read a USB port (actually, a COM serial port with an USB adapter) in Haskell, running in Linux? Thanks, Maur?cio From magnus at therning.org Wed Aug 6 17:17:10 2008 From: magnus at therning.org (Magnus Therning) Date: Wed Aug 6 17:16:52 2008 Subject: [Haskell-cafe] USB and serial port In-Reply-To: References: Message-ID: <489A14D6.6000805@therning.org> Maur??cio wrote: > Hi, > > What are the alternatives to read > a USB port (actually, a COM serial > port with an USB adapter) in > Haskell, running in Linux? Guessing wildly here... Either as a regular file, or a wrapper around some ioctl calls? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/48e762bc/signature.bin From jonathanccast at fastmail.fm Wed Aug 6 17:32:32 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 6 17:33:58 2008 Subject: [Haskell-cafe] adjunction of product and exponentiation In-Reply-To: <42784f260808061356x6d27fe11ud37b919f3a40f87f@mail.gmail.com> References: <42784f260808061356x6d27fe11ud37b919f3a40f87f@mail.gmail.com> Message-ID: <1218058352.10631.42.camel@jcchost> On Wed, 2008-08-06 at 13:56 -0700, Jason Dusek wrote: > The problem as stated is to find the unit for the adjunction: > > ((- x A), (-)^A x A) > > The latter functor takes an arrow f to (f . -) x id_A and does > the obvious thing for objects. The co-unit diagram is given > as: > > B^A x A ---- eval_AB ----> B > ^ ^ > | | > | | > curry(g) x id_A g : C x A -> B > | | > | | > | | > C x A --------------------+ > > This diagram is somewhat puzzling, because it seems the second > functor has turned into (-)^A ! Continuing in with that, we > get a unit diagram like this: > > C ---- magic ----> (C x A)^A > | | > | | > | | > curry(g) (g . -) > | | > | | > | v > +------------------> B^A > > So what is the magic? It is an arrow that takes a C to an > arrow that takes an A and makes the product C x A. I want to > write curry(C x A) but that is ridiculous looking. What's the > right notation for this thing? It's a curried pairing operator. Haskell calls it (,); it might also be called pair. It is also, of course, equal to curry(id), so if you write identity arrows as the corresponding objects then curry(C x A) is perfectly reasonable. (This function is rather fundamental, meaning its main purpose is to justify a move that, 99% of the time it's made, is made without any comment at all. Spelling it out /is/ ridiculous, in the same sense that explicitly invoking modus ponens in your proofs is ridiculous. Unless you're doing low-level formal proof theory, of course.) jcc From hjgtuyl at chello.nl Wed Aug 6 17:47:00 2008 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Wed Aug 6 17:46:37 2008 Subject: [Haskell-cafe] USB and serial port In-Reply-To: References: Message-ID: On Wed, 06 Aug 2008 23:11:50 +0200, Maur??cio wrote: > Hi, > > What are the alternatives to read > a USB port (actually, a COM serial > port with an USB adapter) in > Haskell, running in Linux? > Have a look at: http://www8.garmin.com/support/commProtocol.html Maybe you can find somfing useful at sourceforce.net -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From icfp.publicity at googlemail.com Wed Aug 6 21:37:58 2008 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Wed Aug 6 21:37:39 2008 Subject: [Haskell-cafe] DEFUN 2008 (Developer Tracks on Functional Programming): Call for participation Message-ID: <53ff55480808061837k6330fa54h62dc238e42b82dbf@mail.gmail.com> ACM SIGPLAN 2008 Developer Tracks on Functional Programming http://www.deinprogramm.de/defun-2008/ Victoria, BC, Canada, 25, 27 September, 2008 Held in conjunction with ICFP 2008: http://www.icfpconference.org/icfp2008/ DEFUN 2008 is the event for developers using functional languages: Recognized experts on functional programming technologies share their knowledge and professional skills in talks and tutorials in 10 exciting tracks. Find out how to best make functional programming work in your development project! Acquire new development skills! Learn about other functional languages! The DEFUN program (attached) has tracks with the following types of presentations: - Half-day general language tutorials for specific functional languages, given by recognized experts for the respective languages. - Half-day tutorials on specific techniques or the use of specific technologies in functional programming. - 45-minute "how-to" talks that provide specific information on how to solve specific problems using functional programming. These talks focus on concrete examples, but provide useful information for developers working on different projects or in different contexts. The developer tracks are complementary to ICFP itself (which is for researchers). They are anchored by CUFP, the Haskell Symposium, and the Erlang workshop. Organizers Kathleen Fisher AT&T Labs Simon Peyton Jones Microsoft Research Mike Sperber (co-chair) DeinProgramm Don Stewart (co-chair) Galois PROGRAM: Note: The sessions of a given morning or afternoon are concurrent. The markers (M1, M2, A1, A2, etc.) mark a particular session, and correspond to the designations on the registration forms. Note that the talks M5 together constitute a session. DAY 1 - 25 SEPTEMBER, 2008 MORNING SESSION M1 (Tutorial): Practical Erlang Programming Francesco Cesarini Erlang Training and Consulting M2 (Tutorial): A Gentle Introduction to Functional Information Visualization Jefferson Heard Renaissance Computing Institute, University of North Carolina M3 (Tutorial): JavaScript: from basics to building custom frameworks Sameer Sundresh and Erik Hinterbichler University of Illinois Urbana-Champaign and Pattern Insight, Inc. AFTERNOON SESSION A1 (Tutorial): Erlang DBG and the Trace Biff Tamas Nagy Erlang Training and Consulting A2 (Tutorial): Erlang QuickCheck Tutorial Thomas Arts IT University of Gothenburg and Quviq A3 (Tutorial): Practical and Portable Programming in Scheme Donovan Kolbly TippingPoint Technologies DAY 2 - 27 SEPTEMBER 2008 MORNING SESSION M4 (Tutorial): Real World Haskell Bryan O'Sullivan M5 (Talks): Ten one-liners: handling power series in Haskell Doug McIlroy Dartmouth Incremental multi-level input processing with left-fold enumerator Oleg Kiselyov How we locate wild animals with a functional program Ryan Newton MIT AFTERNOON SESSION A4 (Tutorial): Using QuickCheck and HPC - Obtaining Quality Assurance for Haskell Code Andy Gill Kansas University Koen Claessen Chalmers A5 (Tutorial): Introduction to F# Don Syme and Chris Smith Microsoft Research From vigalchin at gmail.com Thu Aug 7 01:13:43 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 7 01:13:20 2008 Subject: [Haskell-cafe] heap lifetime question Message-ID: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> Hello, What is the lifetime of various heap objects ... e.g. created by allocaBytes, alloca, etc? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/63f12240/attachment.htm From bulat.ziganshin at gmail.com Thu Aug 7 01:25:57 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 7 01:27:59 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> Message-ID: <368402629.20080807092557@gmail.com> Hello Vasili, Thursday, August 7, 2008, 9:13:43 AM, you wrote: > ??? What is the lifetime of various heap objects ... e.g. created by allocaBytes, alloca, etc? alloca/allocaBytes just mimicks stack allocation but actually allocates buffer in usual heap. this buffer lives while references to it exists on practice, it's usually gc'ed by next minor GC -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From vigalchin at gmail.com Thu Aug 7 01:30:32 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 7 01:30:09 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: <368402629.20080807092557@gmail.com> References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> Message-ID: <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> so Bulat .. You seem to be saying what I suspect ... i.e. if an allocaBytes call is inside a function, when the function is exited then the said heap object is GC'd?? Regards, Vasili On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin wrote: > Hello Vasili, > > Thursday, August 7, 2008, 9:13:43 AM, you wrote: > > > What is the lifetime of various heap objects ... e.g. created by > allocaBytes, alloca, etc? > > alloca/allocaBytes just mimicks stack allocation but actually allocates > buffer in usual heap. this buffer lives while references to it exists > > on practice, it's usually gc'ed by next minor GC > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/dd9577e8/attachment.htm From vigalchin at gmail.com Thu Aug 7 01:33:32 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 7 01:33:10 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> Message-ID: <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> If I am correct, I cannot associate a ForeignPtr with alloca or allocaBytes object via "newForeignPtr" because the alloca/allocaBytes heap object will be GC'd when I leave the function that allocated this object/. I.e. if I have a heap object that I want to live beyond a function invocation, I must be very careful in coding.... Vasili On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili wrote: > so Bulat .. > > You seem to be saying what I suspect ... i.e. if an allocaBytes call > is inside a function, when the function is exited then the said heap object > is GC'd?? > > Regards, Vasili > > > > On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin < > bulat.ziganshin@gmail.com> wrote: > >> Hello Vasili, >> >> Thursday, August 7, 2008, 9:13:43 AM, you wrote: >> >> > What is the lifetime of various heap objects ... e.g. created by >> allocaBytes, alloca, etc? >> >> alloca/allocaBytes just mimicks stack allocation but actually allocates >> buffer in usual heap. this buffer lives while references to it exists >> >> on practice, it's usually gc'ed by next minor GC >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/e249362f/attachment.htm From jason.dusek at gmail.com Thu Aug 7 01:50:49 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Aug 7 01:50:26 2008 Subject: [Haskell-cafe] adjunction of product and exponentiation In-Reply-To: <1218058352.10631.42.camel@jcchost> References: <42784f260808061356x6d27fe11ud37b919f3a40f87f@mail.gmail.com> <1218058352.10631.42.camel@jcchost> Message-ID: <42784f260808062250p104eb0b7kc209c28c9edab032@mail.gmail.com> Jonathan Cast wrote: > Jason Dusek wrote: > > It is an arrow that takes a C to an arrow that takes an A > > and makes the product C x A. I want to write curry(C x A) > > but that is ridiculous looking. What's the right notation > > for this thing? > > It's a curried pairing operator. Haskell calls it (,); it > might also be called pair. It is also, of course, equal to > curry(id), so if you write identity arrows as the > corresponding objects then curry(C x A) is perfectly > reasonable. Why is it equal to curry(id)? -- _jsn From bulat.ziganshin at gmail.com Thu Aug 7 01:58:34 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 7 01:59:19 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> Message-ID: <155136561.20080807095834@gmail.com> Hello Vasili, Thursday, August 7, 2008, 9:33:32 AM, you wrote: oh, it was my mistake. alloca behavior is completely defined by it's generic implementation: allocaBytes :: Int -> (Ptr a -> IO b) -> IO b allocaBytes size = bracket (mallocBytes size) free although GHC implementation is much more efficient btw, why you can't download ghc library sources and read them yourself?? > If I am correct, I cannot associate a ForeignPtr with alloca or > allocaBytes object via "newForeignPtr" because the > alloca/allocaBytes heap object will be GC'd when I leave the > function that allocated this object/. I.e. if I have a heap object > that I want to live beyond a function invocation, I must be very careful in coding.... > > Vasili > On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili wrote: > > so Bulat .. > ???? You seem to be saying what I suspect ... i.e. if an > allocaBytes call is inside a function, when the function is exited > then the said heap object is GC'd?? > Regards, Vasili > > > On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin > wrote: > Hello Vasili, > > Thursday, August 7, 2008, 9:13:43 AM, you wrote: > >> ??? What is the lifetime of various heap objects ... e.g. created by allocaBytes, alloca, etc? > > > alloca/allocaBytes just mimicks stack allocation but actually allocates > buffer in usual heap. this buffer lives while references to it exists > > on practice, it's usually gc'ed by next minor GC > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com > > > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jonathanccast at fastmail.fm Thu Aug 7 02:07:20 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Aug 7 02:06:57 2008 Subject: [Haskell-cafe] adjunction of product and exponentiation In-Reply-To: <42784f260808062250p104eb0b7kc209c28c9edab032@mail.gmail.com> References: <42784f260808061356x6d27fe11ud37b919f3a40f87f@mail.gmail.com> <1218058352.10631.42.camel@jcchost> <42784f260808062250p104eb0b7kc209c28c9edab032@mail.gmail.com> Message-ID: <1218089240.6439.9.camel@jonathans-macbook> On Wed, 2008-08-06 at 22:50 -0700, Jason Dusek wrote: > Jonathan Cast wrote: > > Jason Dusek wrote: > > > It is an arrow that takes a C to an arrow that takes an A > > > and makes the product C x A. I want to write curry(C x A) > > > but that is ridiculous looking. What's the right notation > > > for this thing? > > > > It's a curried pairing operator. Haskell calls it (,); it > > might also be called pair. It is also, of course, equal to > > curry(id), so if you write identity arrows as the > > corresponding objects then curry(C x A) is perfectly > > reasonable. > > Why is it equal to curry(id)? curry f x y = f (x, y) So therefore curry id x y = id (x, y) = (x, y) Eta-contracting, we get curry id = \ x. \ y. (x, y) which is your function. jcc From vigalchin at gmail.com Thu Aug 7 02:26:17 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 7 02:25:54 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: <155136561.20080807095834@gmail.com> References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> <155136561.20080807095834@gmail.com> Message-ID: <5ae4f2ba0808062326x6f3a8251p19ea535299520a68@mail.gmail.com> In which directory are they? Vasili On Thu, Aug 7, 2008 at 12:58 AM, Bulat Ziganshin wrote: > Hello Vasili, > > Thursday, August 7, 2008, 9:33:32 AM, you wrote: > > oh, it was my mistake. alloca behavior is completely defined by it's > generic implementation: > > allocaBytes :: Int -> (Ptr a -> IO b) -> IO b > allocaBytes size = bracket (mallocBytes size) free > > although GHC implementation is much more efficient > > btw, why you can't download ghc library sources and read them yourself?? > > > > > If I am correct, I cannot associate a ForeignPtr with alloca or > > allocaBytes object via "newForeignPtr" because the > > alloca/allocaBytes heap object will be GC'd when I leave the > > function that allocated this object/. I.e. if I have a heap object > > that I want to live beyond a function invocation, I must be very careful > in coding.... > > > > Vasili > > > On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili > wrote: > > > > so Bulat .. > > > You seem to be saying what I suspect ... i.e. if an > > allocaBytes call is inside a function, when the function is exited > > then the said heap object is GC'd?? > > > Regards, Vasili > > > > > > > > On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin > > wrote: > > Hello Vasili, > > > > > Thursday, August 7, 2008, 9:13:43 AM, you wrote: > > > >> What is the lifetime of various heap objects ... e.g. created by > allocaBytes, alloca, etc? > > > > > > alloca/allocaBytes just mimicks stack allocation but actually allocates > > buffer in usual heap. this buffer lives while references to it exists > > > > on practice, it's usually gc'ed by next minor GC > > > > -- > > Best regards, > > Bulat mailto:Bulat.Ziganshin@gmail.com > > > > > > > > > > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/c24f0156/attachment.htm From tittoassini at gmail.com Thu Aug 7 02:31:46 2008 From: tittoassini at gmail.com (Titto Assini) Date: Thu Aug 7 02:31:23 2008 Subject: [Haskell-cafe] Last Call for the Italian Haskellers Summer Meeting Message-ID: <2d34474e0808062331w3826a89bn33b19cbd00cbd299@mail.gmail.com> As usual we will now switch to Dante's "bella lingua". Ottimissimi, mancano pochi giorni al primo incontro estivo/balneare degli haskeller italiani. Per informazioni e registrarsi date uno sguardo a: http://www.haskell.org/haskellwiki/ItaloHaskell/Summer_2008 Oppure contattate il sottoscritto via email o per telefono al 0584 791669. A presto ragazzi, titto -- Pasqualino "Titto" Assini, Ph.D. 25 Heath Road - CO79PT Wivenhoe - Colchester - U.K. From vigalchin at gmail.com Thu Aug 7 02:33:07 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 7 02:32:44 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: <5ae4f2ba0808062326x6f3a8251p19ea535299520a68@mail.gmail.com> References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> <155136561.20080807095834@gmail.com> <5ae4f2ba0808062326x6f3a8251p19ea535299520a68@mail.gmail.com> Message-ID: <5ae4f2ba0808062333q2a152ad4id9465df13cf39c91@mail.gmail.com> ok .. I will take a stab at it ... /ghc-6.8.2/libraries/base/Foreign/Marshal .... I am not so familiar with the ghc run-time model ... V. On Thu, Aug 7, 2008 at 1:26 AM, Galchin, Vasili wrote: > In which directory are they? > > Vasili > > > On Thu, Aug 7, 2008 at 12:58 AM, Bulat Ziganshin < > bulat.ziganshin@gmail.com> wrote: > >> Hello Vasili, >> >> Thursday, August 7, 2008, 9:33:32 AM, you wrote: >> >> oh, it was my mistake. alloca behavior is completely defined by it's >> generic implementation: >> >> allocaBytes :: Int -> (Ptr a -> IO b) -> IO b >> allocaBytes size = bracket (mallocBytes size) free >> >> although GHC implementation is much more efficient >> >> btw, why you can't download ghc library sources and read them yourself?? >> >> >> >> > If I am correct, I cannot associate a ForeignPtr with alloca or >> > allocaBytes object via "newForeignPtr" because the >> > alloca/allocaBytes heap object will be GC'd when I leave the >> > function that allocated this object/. I.e. if I have a heap object >> > that I want to live beyond a function invocation, I must be very careful >> in coding.... >> > >> > Vasili >> >> > On Thu, Aug 7, 2008 at 12:30 AM, Galchin, Vasili >> wrote: >> > >> > so Bulat .. >> >> > You seem to be saying what I suspect ... i.e. if an >> > allocaBytes call is inside a function, when the function is exited >> > then the said heap object is GC'd?? >> >> > Regards, Vasili >> > >> >> > >> >> > On Thu, Aug 7, 2008 at 12:25 AM, Bulat Ziganshin >> > wrote: >> > Hello Vasili, >> > >> >> > Thursday, August 7, 2008, 9:13:43 AM, you wrote: >> > >> >> What is the lifetime of various heap objects ... e.g. created by >> allocaBytes, alloca, etc? >> > >> > >> > alloca/allocaBytes just mimicks stack allocation but actually allocates >> > buffer in usual heap. this buffer lives while references to it exists >> > >> > on practice, it's usually gc'ed by next minor GC >> > >> > -- >> > Best regards, >> > Bulat mailto:Bulat.Ziganshin@gmail.com >> > >> > >> >> > >> >> > >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/f970089a/attachment.htm From lemming at henning-thielemann.de Thu Aug 7 02:36:17 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Aug 7 02:35:55 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: <155136561.20080807095834@gmail.com> References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> <155136561.20080807095834@gmail.com> Message-ID: On Thu, 7 Aug 2008, Bulat Ziganshin wrote: > Hello Vasili, > > Thursday, August 7, 2008, 9:33:32 AM, you wrote: > > oh, it was my mistake. alloca behavior is completely defined by it's > generic implementation: > > allocaBytes :: Int -> (Ptr a -> IO b) -> IO b > allocaBytes size = bracket (mallocBytes size) free > > although GHC implementation is much more efficient That is, it is not a good idea to use 'allocaBytes n return' in order to carry a pointer of an allocated piece of memory out of the inner action. From vigalchin at gmail.com Thu Aug 7 02:38:56 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 7 02:38:33 2008 Subject: [Haskell-cafe] heap lifetime question In-Reply-To: References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> <155136561.20080807095834@gmail.com> Message-ID: <5ae4f2ba0808062338q2141e5cyf5b356d992a894d1@mail.gmail.com> that is what I thought .. especially after just looking at the implementation for alloca/allocaBytes. For me and others on thie group is there documentation on the ghc run-time model and also the run-time library architecture. Both would help/aid in reading the code and of course educate more people? Regards, Vasili On Thu, Aug 7, 2008 at 1:36 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Thu, 7 Aug 2008, Bulat Ziganshin wrote: > > > Hello Vasili, > > > > Thursday, August 7, 2008, 9:33:32 AM, you wrote: > > > > oh, it was my mistake. alloca behavior is completely defined by it's > > generic implementation: > > > > allocaBytes :: Int -> (Ptr a -> IO b) -> IO b > > allocaBytes size = bracket (mallocBytes size) free > > > > although GHC implementation is much more efficient > > That is, it is not a good idea to use 'allocaBytes n return' in order to > carry a pointer of an allocated piece of memory out of the inner action. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/ed3a3fea/attachment.htm From lemming at henning-thielemann.de Thu Aug 7 03:13:38 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Aug 7 03:13:16 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> Message-ID: On Wed, 6 Aug 2008, Galchin, Vasili wrote: > 1) Is there a common assumed semantics across all of the Haskell "with" > things? withString? withData? > > 2) If the answer to 1) is yes, then does this imply some kind of > polymorphism? Couldn't "with" be "reduced" to a higher order function then > ?? The Continuation monad abstracts the idea of 'with': http://www.haskell.org/pipermail/haskell-cafe/2008-February/038963.html From vigalchin at gmail.com Thu Aug 7 03:18:14 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 7 03:17:51 2008 Subject: [Haskell-cafe] the Haskell "with" "pattern"? In-Reply-To: References: <5ae4f2ba0808052243j5a73963ar7f06a7aae7f9f5c5@mail.gmail.com> Message-ID: <5ae4f2ba0808070018u785c3c7emb9cd537b4c36b5bd@mail.gmail.com> Henning, Cool ... thx, vasili On Thu, Aug 7, 2008 at 2:13 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Wed, 6 Aug 2008, Galchin, Vasili wrote: > > > 1) Is there a common assumed semantics across all of the Haskell > "with" > > things? withString? withData? > > > > 2) If the answer to 1) is yes, then does this imply some kind of > > polymorphism? Couldn't "with" be "reduced" to a higher order function > then > > ?? > > The Continuation monad abstracts the idea of 'with': > http://www.haskell.org/pipermail/haskell-cafe/2008-February/038963.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/8acb0328/attachment.htm From marco-oweber at gmx.de Thu Aug 7 03:40:52 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Aug 7 03:40:32 2008 Subject: [Haskell-cafe] USB and serial port In-Reply-To: References: Message-ID: <20080807074052.GA21686@gmx.de> On Wed, Aug 06, 2008 at 06:11:50PM -0300, Maur??cio wrote: > Hi, > > What are the alternatives to read > a USB port (actually, a COM serial > port with an USB adapter) in > Haskell, running in Linux? Just be aware that the USB-serial converter can be polled only every ms. So if you have really time critical applications you may see some porblems. I've spend days no knowing why I wasn't able to program a avr microcontroller till trying a real serial device (without USB) and it suddenly worked.. So if someting does'nt work maybe try a real serial interface first :) Marc From briqueabraque at yahoo.com Thu Aug 7 08:02:55 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Thu Aug 7 08:02:40 2008 Subject: [Haskell-cafe] Re: USB and serial port In-Reply-To: <20080807074052.GA21686@gmx.de> References: <20080807074052.GA21686@gmx.de> Message-ID: Marc Weber a ?crit : > On Wed, Aug 06, 2008 at 06:11:50PM -0300, Maur??cio wrote: >> Hi, >> >> What are the alternatives to read >> a USB port (actually, a COM serial >> port with an USB adapter) in >> Haskell, running in Linux? > > Just be aware that the USB-serial converter can be polled only every ms. > So if you have really time critical applications you may see some > porblems. I've spend days no knowing why I wasn't able to program a avr > microcontroller till trying a real serial device (without USB) and it > suddenly worked.. So if someting does'nt work maybe try a real serial > interface first :) > > Marc I would, if my computer had one... :) From gtener at gmail.com Thu Aug 7 11:24:17 2008 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Thu Aug 7 11:23:55 2008 Subject: [Haskell-cafe] USB and serial port In-Reply-To: References: Message-ID: <220e47b40808070824l1137ef3fy8e7c1117356d65f8@mail.gmail.com> I'm currently using partial wrapper around libusb[1] in my work. It doesn't provide full interface to the library itself, so I didn't have to translate C structures. Perhaps someone can make a regular wrapper - the libusb API is pretty small and concise. Regards, Christopher Skrz?tnicki [1] http://libusb.wiki.sourceforge.net/ On Wed, Aug 6, 2008 at 23:11, Maur??cio wrote: > Hi, > > What are the alternatives to read > a USB port (actually, a COM serial > port with an USB adapter) in > Haskell, running in Linux? > > Thanks, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From matthew at wellquite.org Thu Aug 7 12:00:25 2008 From: matthew at wellquite.org (Matthew Sackman) Date: Thu Aug 7 12:00:17 2008 Subject: [Haskell-cafe] Re: Anglo Haskell 2008 In-Reply-To: <20080729142754.GF5180@koba.home.wellquite.org> References: <20080701121531.GB1808@arkansas.doc.ic.ac.uk> <20080707153853.GB6240@wellquite.org> <20080729142754.GF5180@koba.home.wellquite.org> Message-ID: <20080807160024.GX17334@arkansas.doc.ic.ac.uk> Anglo Haskell 2008 is all but upon us! In under 18 hours a weekend[0] the like of which has not previously been seen (except in 2006 and 2007) shall be unleashed. Full details of the momentus events that will befall us this weekend can be found on the wiki: http://www.haskell.org/haskellwiki/AngloHaskell/2008 For all of you who are not lucky enough to attend, salvation is at hand - a live broadcast of the audio (sorry, no video) will be available from: http://streams.wellquite.org:8000/AngloHaskell2008.ogg This will be available from 11am BST (GMT/UTC + 1) tomorrow (Friday 8th) and from 1pm BST Saturday. The recording will also be dumped to disk and should eventually be edited and appear with the slides presented for at least the main talks. Looking forward to seeing you *all* there tomorrow! Matthew [0] Err, technically, a Friday and Saturday. From edward.ing at gmail.com Thu Aug 7 12:39:02 2008 From: edward.ing at gmail.com (Edward Ing) Date: Thu Aug 7 12:38:40 2008 Subject: [Haskell-cafe] Network.CGI Content header problem in Firefox. Message-ID: <8f66da400808070939x26e1ede9p589a902bfd0fd498@mail.gmail.com> Hi, I am doing some tests with Haskell to produce CGI programmes. I am running Microsoft IIS 5.0 as the weberver executing haskell compile executables that are cgi. If I set the header with a content type, Firefox always reports the content-type as application/octet-stream, and tries to initiate a download. IExplorer 6.0 does not report the type at all. It seems like the setHeader function does not result in sending headers. Has anyone seen this problem. Code snippet here ==== main :: IO() main = runCGI $ handleErrors cgiMain cgiMain :: CGI CGIResult cgiMain = do x <- getVars y <- getInputs prog <- progURI query <- queryURI request <- requestURI path <- pathInfo inputs <- getInputs setHeader("Content-type" "text/plain") setCookie (Cookie "bbb" "hello" Nothing Nothing Nothing False ) liftIO (putStr "asdfasdf") output $ (uris "prog" prog) ++ (uris "query" query) ++ (uris "request" request) ++ "\npath: " ++ path ++ "\n" ++ (varsToString inputs) ++(varsToString x) ++ "\n\nVars\n"++ (varsToString y) From westondan at imageworks.com Thu Aug 7 13:35:17 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Aug 7 13:34:58 2008 Subject: [Haskell-cafe] Last Call for the Italian Haskellers Summer Meeting In-Reply-To: <2d34474e0808062331w3826a89bn33b19cbd00cbd299@mail.gmail.com> References: <2d34474e0808062331w3826a89bn33b19cbd00cbd299@mail.gmail.com> Message-ID: <489B3255.7000300@imageworks.com> Shouldn't that be "posta elettronica" (or "posteletta" along the lines of the Frence "courriel")? Somehow I doubt that Dante would have approved of the word "email". Titto Assini wrote: > As usual we will now switch to Dante's "bella lingua". > > > Ottimissimi, > > mancano pochi giorni al primo incontro estivo/balneare degli haskeller italiani. > > Per informazioni e registrarsi date uno sguardo a: > http://www.haskell.org/haskellwiki/ItaloHaskell/Summer_2008 > > Oppure contattate il sottoscritto via email o per telefono al 0584 791669. > > A presto ragazzi, > > titto > From jonathanccast at fastmail.fm Thu Aug 7 13:40:18 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Aug 7 13:41:45 2008 Subject: [Haskell-cafe] Last Call for the Italian Haskellers Summer Meeting In-Reply-To: <489B3255.7000300@imageworks.com> References: <2d34474e0808062331w3826a89bn33b19cbd00cbd299@mail.gmail.com> <489B3255.7000300@imageworks.com> Message-ID: <1218130818.20988.35.camel@jcchost> On Thu, 2008-08-07 at 10:35 -0700, Dan Weston wrote: > Shouldn't that be "posta elettronica" (or "posteletta" along the lines > of the Frence "courriel")? eposta, surely... jcc From hjgtuyl at chello.nl Thu Aug 7 13:42:48 2008 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Thu Aug 7 13:42:23 2008 Subject: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell) In-Reply-To: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> References: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> Message-ID: On Tue, 05 Aug 2008 10:59:10 +0200, jinjing wrote: > Hi there, > > Here's the project link: > > http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown > > I found Haskore pretty fun :) so I'm documenting it while learning it. > Please don't hesitate to give suggestions / corrections. > About the installation section: I think beginners will be grateful if you write down the full "darcs get" commands and explain the --global parameter of the "cabal install" command. There are two more packages that need to be downloaded: - package hosc depends on package binary - package haskore depends on package unix Windows users will be grateful if you tell them that Haskore cannot be built on Windows, because of the dependance on the unix package. It would have saved me a lot of time if I knew that beforehand. For the people interested in porting Haskore to Windows I'll describe what I have done so far: src\Haskore\Basic\Timer\Posix.hs: System.Posix.Unistd.usleep replaced by Control.Concurrent.threadDelay (of course, the name of the file is not correct after this; better put the timer function in another file) File Haskore.cabal: removed "unix" from section "Build-depends" Added to cabal file: if os(windows) cpp-options: -DWIN32 Added to src\Haskore\Interface\CSound\Play.lhs: > {-# OPTIONS -cpp #-} and around the signal handling part and the line > import qualified System.Posix.Signals as Signals : #ifndef WIN32 ... #endif Same treatment for src/Haskore/Interface/MIDI/Play.lhs Finally I discovered that in the file src/Haskore/Interface/SuperCollider/Channel/Env.hs environment variables are set and that there is no setEnv or putEnv for Windows. GCC knows the function setenv(), but that function does not work as expected (on Windows); once the program terminates, the created environment variable has dissapeared. After I discovered that, I decided it would be too much yak shaving for me to go on. To solve this problem, on would either create an improved setenv() function, or redesign Haskore to pass the information some other way (and of course the program(s) that read this information). -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From tretriluxana.s at gmail.com Thu Aug 7 14:31:10 2008 From: tretriluxana.s at gmail.com (Sukit Tretriluxana) Date: Thu Aug 7 14:30:47 2008 Subject: [Haskell-cafe] Currying function using values from array Message-ID: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> Dear Haskell experts, I am currently studying Groovy language. An experiment I did with its closure is to perform closure/function "curry" using an array containing the values for the parameter binding. See the sample below. int addThemUp(a,b,c,d,e) { a+b+c+d+e } def arrayCurry(arr, cls) { arr.inject(cls) { c, v -> c.curry(v) } } println addThemUp(1,2,3,4,5) println arrayCurry([1,2,3,4,5], this.&addThemUp)() println arrayCurry([1,2,3,4], this.&addThemUp)(5) The printouts from the above code are the same, verifying that the code works fine. Then I come to ask myself how I can do the same in Haskell. I'm not a Haskell expert so I couldn't figure it. I wonder if you guys could shed some light on this. Thanks, Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/a2c34609/attachment.htm From nfjinjing at gmail.com Thu Aug 7 14:41:29 2008 From: nfjinjing at gmail.com (jinjing) Date: Thu Aug 7 14:41:06 2008 Subject: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell) In-Reply-To: References: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> Message-ID: <81ea7d400808071141t3b2a1e7avcf9c26fae160f4d6@mail.gmail.com> Thanks Henk-Jan van Tuyl, It's been updated/changed accordingly. jinjing On Fri, Aug 8, 2008 at 1:42 AM, Henk-Jan van Tuyl wrote: > On Tue, 05 Aug 2008 10:59:10 +0200, jinjing wrote: > >> Hi there, >> >> Here's the project link: >> >> http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown >> >> I found Haskore pretty fun :) so I'm documenting it while learning it. >> Please don't hesitate to give suggestions / corrections. >> > > > About the installation section: I think beginners will be grateful if you > write down the full "darcs get" commands and explain the --global parameter > of the "cabal install" command. > > There are two more packages that need to be downloaded: > - package hosc depends on package binary > - package haskore depends on package unix > > Windows users will be grateful if you tell them that Haskore cannot be built > on Windows, because of the dependance on the unix package. It would have > saved me a lot of time if I knew that beforehand. > > > > For the people interested in porting Haskore to Windows I'll describe what I > have done so far: > > src\Haskore\Basic\Timer\Posix.hs: > System.Posix.Unistd.usleep replaced by Control.Concurrent.threadDelay > (of course, the name of the file is not correct after this; better put the > timer function in another file) > > > File Haskore.cabal: > removed "unix" from section "Build-depends" > > Added to cabal file: > if os(windows) > cpp-options: -DWIN32 > > Added to src\Haskore\Interface\CSound\Play.lhs: >> >> {-# OPTIONS -cpp #-} > > and around the signal handling part and the line >> >> import qualified System.Posix.Signals as Signals > > : > > #ifndef WIN32 > ... > #endif > > > Same treatment for src/Haskore/Interface/MIDI/Play.lhs > > Finally I discovered that in the file > src/Haskore/Interface/SuperCollider/Channel/Env.hs > environment variables are set and that there is no setEnv or putEnv for > Windows. > GCC knows the function setenv(), but that function does not work as expected > (on Windows); once the program terminates, the created environment variable > has dissapeared. After I discovered that, I decided it would be too much yak > shaving for me to go on. To solve this problem, on would either create an > improved setenv() function, or redesign Haskore to pass the information some > other way (and of course the program(s) that read this information). > > > -- > Met vriendelijke groet, > Henk-Jan van Tuyl > > > -- > http://functor.bamikanarie.com > http://Van.Tuyl.eu/ > -- > > From lemming at henning-thielemann.de Thu Aug 7 15:35:16 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Aug 7 15:34:55 2008 Subject: [Haskell-cafe] Currying function using values from array In-Reply-To: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> References: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> Message-ID: On Thu, 7 Aug 2008, Sukit Tretriluxana wrote: > Dear Haskell experts, > > I am currently studying Groovy language. An experiment I did with its > closure is to perform closure/function "curry" using an array containing the > values for the parameter binding. See the sample below. > > int addThemUp(a,b,c,d,e) { a+b+c+d+e } > def arrayCurry(arr, cls) { arr.inject(cls) { c, v -> c.curry(v) } } > println addThemUp(1,2,3,4,5) > println arrayCurry([1,2,3,4,5], this.&addThemUp)() > println arrayCurry([1,2,3,4], this.&addThemUp)(5) > > The printouts from the above code are the same, verifying that the code > works fine. Then I come to ask myself how I can do the same in Haskell. I'm > not a Haskell expert so I couldn't figure it. I wonder if you guys could > shed some light on this. I do not know Groovy, but maybe you want something like addThemUp :: Num a => (a,a,a,a,a) -> a addThemUp (a,b,c,d,e) = a+b+c+d+e -- should be better named list5Curry or so arrayCurry :: ((a,a,a,a,a) -> a) -> [a] -> a arrayCurry cls [a,b,c,d,e] = cls (a,b,c,d,e) print (addThemUp(1,2,3,4,5::Int)) print (arrayCurry addThemUp [1,2,3,4,5::Int]) However, it's hardly of any use, since you won't use a list if the number of elements is fixed (and small) or if the elements even must have distinct types. From jefferson.r.heard at gmail.com Thu Aug 7 15:43:21 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Thu Aug 7 15:42:58 2008 Subject: [Haskell-cafe] ANN: FTGL 1.0. Portable truetype font rendering in OpenGL Message-ID: <4165d3a70808071243i4aeb1c27j767c0f93ce1c1c8f@mail.gmail.com> Hi folks. I've just released some Haskell bindings to FTGL at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FTGL . FTGL is an easy to use library for portable rendering of TrueType fonts in OpenGL, with functions for creating bitmapped fonts, texture-mapped fonts, buffered fonts, polygonal 2D fonts, and extruded polygonal 3D fonts. The code works on Windows and Linux. I've not tested it yet on the Mac. To use FTGL in your programs, just import Graphics.Rendering.FTGL and use do font <- createTextureFont "font.ttf" setFontFaceSize font 24 72 renderFont font "some string" More documentation can be found at the FTGL homepage at http://ftgl.sourceforge.net -- Jeff From dons at galois.com Thu Aug 7 15:44:44 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 7 15:44:20 2008 Subject: [Haskell-cafe] ANN: FTGL 1.0. Portable truetype font rendering in OpenGL In-Reply-To: <4165d3a70808071243i4aeb1c27j767c0f93ce1c1c8f@mail.gmail.com> References: <4165d3a70808071243i4aeb1c27j767c0f93ce1c1c8f@mail.gmail.com> Message-ID: <20080807194444.GB29207@scytale.galois.com> jefferson.r.heard: > Hi folks. I've just released some Haskell bindings to FTGL at > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FTGL . > FTGL is an easy to use library for portable rendering of TrueType > fonts in OpenGL, with functions for creating bitmapped fonts, > texture-mapped fonts, buffered fonts, polygonal 2D fonts, and extruded > polygonal 3D fonts. The code works on Windows and Linux. I've not > tested it yet on the Mac. > > To use FTGL in your programs, just import Graphics.Rendering.FTGL and use > > do > font <- createTextureFont "font.ttf" > setFontFaceSize font 24 72 > renderFont font "some string" > > More documentation can be found at the FTGL homepage at > http://ftgl.sourceforge.net Good work. Native packages for Arch Linux available, http://aur.archlinux.org/packages.php?ID=18918 From felipe.lessa at gmail.com Thu Aug 7 15:49:15 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu Aug 7 15:48:50 2008 Subject: [Haskell-cafe] Re: [HOpenGL] ANN: FTGL 1.0. Portable truetype font rendering in OpenGL In-Reply-To: <4165d3a70808071243i4aeb1c27j767c0f93ce1c1c8f@mail.gmail.com> References: <4165d3a70808071243i4aeb1c27j767c0f93ce1c1c8f@mail.gmail.com> Message-ID: On Thu, Aug 7, 2008 at 4:43 PM, Jefferson Heard wrote: > Hi folks. I've just released some Haskell bindings to FTGL at > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FTGL . That's a great contribution, thanks! Now we have OpenGL, GLFW, FTGL, DevIL, OpenAL, and it's getting better and better. -- Felipe. From tanielsen at gmail.com Thu Aug 7 15:49:57 2008 From: tanielsen at gmail.com (Tom Nielsen) Date: Thu Aug 7 15:49:33 2008 Subject: [Haskell-cafe] Currying function using values from array In-Reply-To: References: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> Message-ID: <78dc001e0808071249w1624d9cg339c2970550c8999@mail.gmail.com> Maybe you want something like curryWithList :: ([a]->b)->[a]->([a]->b) curryWithList f lst1= \lst2 ->f (lst1++lst2) addThemUp = sum curried = curryWithList addThemUp [1,2,3,4] curried [5] =15 On Thu, Aug 7, 2008 at 8:35 PM, Henning Thielemann wrote: > > On Thu, 7 Aug 2008, Sukit Tretriluxana wrote: > >> Dear Haskell experts, >> >> I am currently studying Groovy language. An experiment I did with its >> closure is to perform closure/function "curry" using an array containing the >> values for the parameter binding. See the sample below. >> >> int addThemUp(a,b,c,d,e) { a+b+c+d+e } >> def arrayCurry(arr, cls) { arr.inject(cls) { c, v -> c.curry(v) } } >> println addThemUp(1,2,3,4,5) >> println arrayCurry([1,2,3,4,5], this.&addThemUp)() >> println arrayCurry([1,2,3,4], this.&addThemUp)(5) >> >> The printouts from the above code are the same, verifying that the code >> works fine. Then I come to ask myself how I can do the same in Haskell. I'm >> not a Haskell expert so I couldn't figure it. I wonder if you guys could >> shed some light on this. > > I do not know Groovy, but maybe you want something like > > addThemUp :: Num a => (a,a,a,a,a) -> a > addThemUp (a,b,c,d,e) = a+b+c+d+e > > -- should be better named list5Curry or so > arrayCurry :: ((a,a,a,a,a) -> a) -> [a] -> a > arrayCurry cls [a,b,c,d,e] = cls (a,b,c,d,e) > > print (addThemUp(1,2,3,4,5::Int)) > print (arrayCurry addThemUp [1,2,3,4,5::Int]) > > However, it's hardly of any use, since you won't use a list if the number > of elements is fixed (and small) or if the elements even must have > distinct types. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From edward.ing at gmail.com Thu Aug 7 15:58:29 2008 From: edward.ing at gmail.com (Edward Ing) Date: Thu Aug 7 15:58:06 2008 Subject: [Haskell-cafe] Building fastcgi from hackage on windows. Message-ID: <8f66da400808071258i7d145dferf8beb1dce63b0962@mail.gmail.com> I am using the cabal system to build the hackage version of fastcgi. I get the below messages with the "runghc Setup.lhs build" command. Network\FastCGI.hsc:59:21: fcgiapp.h: No such file or directory Network\FastCGI.hsc: In function `main': Network\FastCGI.hsc:200:0: error: `FCGX_Request' undeclared (first use in this function) It looks like I need the fastcgi sources. Where does this source come from? I didn't get any dependency messages when I did the setup config. Edward Ing From gue.schmidt at web.de Thu Aug 7 17:49:45 2008 From: gue.schmidt at web.de (=?windows-1252?Q?G=FCnther_Schmidt?=) Date: Thu Aug 7 17:49:28 2008 Subject: [Haskell-cafe] Re: Scripting COM Components from Haskell - GreenCard on Hackage In-Reply-To: References: Message-ID: Dear John, would you happen to be "that way inclined"? :) G?nther john lask schrieb: > > What you want is just the automation library which is only part of the overall package (the package includes ihc, the interface generator, from memory ), the automation library could easily be seporated from the rest of the package, stripping away the hdirect marshalling utils to make use of the current ffi functions and marshalling utils. This would be a relatively straight forward task, for someone that way inclined. > From gwern0 at gmail.com Thu Aug 7 19:50:40 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Aug 7 19:51:00 2008 Subject: [Haskell-cafe] Re: ANN: Haddock version 2.2.1 In-Reply-To: <1C6E59C47F062E42820BEE74FD3388E918DF3F7B10@EA-EXMSG-C333.europe.corp.microsoft.com> References: <48973D1D.6010406@dfki.de> <20080804174804.GA11112@craft> <48974EB0.9050704@dfki.de> <20080804195204.GA12968@craft> <1C6E59C47F062E42820BEE74FD3388E918DF3F7B10@EA-EXMSG-C333.europe.corp.microsoft.com> Message-ID: <20080807235039.GB23678@craft> On 2008.08.05 09:22:17 +0100, Simon Marlow scribbled 0.8K characters: > > > On 2008.08.04 20:47:12 +0200, Christian Maeder > > > > > scribbled 1.1K characters: > > > > Right, > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal- > > 1.4.0.1 > > > > works. > > > > > > > > It seems that the dependencies for ghc-paths could be improved. > > > > > > > > Thanks Christian > > > > > > Yes, I emailed Marlow suggesting that yesterday. (Or perhaps it was the > > > day before.) > > > > Sorry - I fixed the .cabal file and then got sidetracked into trying to > > make it work with Cabal-1.5 too. I'll upload the version with the fixed > > dependency now. > > Hackage won't let me upload a package with cabal-version: >= 1.4 && < 1.5, but it will let me upload with just >= 1.4, so I've done that for now. The package will fail to build if you have Cabal 1.5.x installed, presumably. > > Cheers, > Simon Hm. So far as I know there was only one 1.4 release, so couldn't you do cabal-version: == 1.4.0.1? -- gwern mol snuffle evil Firewalls fissionable SRT Speakeasy HIC 5.53 Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/3697be50/attachment-0001.bin From tretriluxana.s at gmail.com Thu Aug 7 19:52:51 2008 From: tretriluxana.s at gmail.com (Sukit Tretriluxana) Date: Thu Aug 7 19:52:25 2008 Subject: [Haskell-cafe] Currying function using values from array In-Reply-To: <78dc001e0808071249w1624d9cg339c2970550c8999@mail.gmail.com> References: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> <78dc001e0808071249w1624d9cg339c2970550c8999@mail.gmail.com> Message-ID: <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> Thanks Tom and Henning for your response. Let me put the question in another way by generalizing and tweaking it a little bit. How in Haskell that I can create a function that curries *any *other function, which receives multiple parameters, by using a the input from a list (same data type) or a tuple (mixed data type) such that it either returns another closure (if not all parameters are curried) or the final value of the computation (when all parameters are known)? Ed On Thu, Aug 7, 2008 at 12:49 PM, Tom Nielsen wrote: > Maybe you want something like > > curryWithList :: ([a]->b)->[a]->([a]->b) > curryWithList f lst1= \lst2 ->f (lst1++lst2) > > addThemUp = sum > curried = curryWithList addThemUp [1,2,3,4] > curried [5] =15 > > On Thu, Aug 7, 2008 at 8:35 PM, Henning Thielemann > wrote: > > > > On Thu, 7 Aug 2008, Sukit Tretriluxana wrote: > > > >> Dear Haskell experts, > >> > >> I am currently studying Groovy language. An experiment I did with its > >> closure is to perform closure/function "curry" using an array containing > the > >> values for the parameter binding. See the sample below. > >> > >> int addThemUp(a,b,c,d,e) { a+b+c+d+e } > >> def arrayCurry(arr, cls) { arr.inject(cls) { c, v -> c.curry(v) } } > >> println addThemUp(1,2,3,4,5) > >> println arrayCurry([1,2,3,4,5], this.&addThemUp)() > >> println arrayCurry([1,2,3,4], this.&addThemUp)(5) > >> > >> The printouts from the above code are the same, verifying that the code > >> works fine. Then I come to ask myself how I can do the same in Haskell. > I'm > >> not a Haskell expert so I couldn't figure it. I wonder if you guys could > >> shed some light on this. > > > > I do not know Groovy, but maybe you want something like > > > > addThemUp :: Num a => (a,a,a,a,a) -> a > > addThemUp (a,b,c,d,e) = a+b+c+d+e > > > > -- should be better named list5Curry or so > > arrayCurry :: ((a,a,a,a,a) -> a) -> [a] -> a > > arrayCurry cls [a,b,c,d,e] = cls (a,b,c,d,e) > > > > print (addThemUp(1,2,3,4,5::Int)) > > print (arrayCurry addThemUp [1,2,3,4,5::Int]) > > > > However, it's hardly of any use, since you won't use a list if the number > > of elements is fixed (and small) or if the elements even must have > > distinct types. > > _______________________________________________ > > 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/20080807/8fc9ce78/attachment.htm From iainspeed at gmail.com Thu Aug 7 19:54:28 2008 From: iainspeed at gmail.com (Iain Barnett) Date: Thu Aug 7 19:54:15 2008 Subject: [Haskell-cafe] Building fastcgi from hackage on windows. In-Reply-To: <8f66da400808071258i7d145dferf8beb1dce63b0962@mail.gmail.com> References: <8f66da400808071258i7d145dferf8beb1dce63b0962@mail.gmail.com> Message-ID: On 7 Aug 2008, at 8:58 pm, Edward Ing wrote: > I am using the cabal system to build the hackage version of fastcgi. > I get the below messages with the "runghc Setup.lhs build" command. > > Network\FastCGI.hsc:59:21: fcgiapp.h: No such file or directory > Network\FastCGI.hsc: In function `main': > > Network\FastCGI.hsc:200:0: > error: `FCGX_Request' undeclared (first use in this function) > > > > It looks like I need the fastcgi sources. Where does this source come > from? I didn't get any dependency messages when I did the setup > config. > > > Edward Ing > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe I had a similar problem about a month ago, but I can't remember *exactly* what I did to fix it. I think I made sure the following were installed (I'm pretty sure I ran cabal installs for all of them regardless of what ghc-pkg told me, and it worked) network-2.0 alex-2.2 HTTP-3001.0.4 cgi-3001.1.6.0 From my cabal build-log: package: fastcgi-3001.0.2 os: osx arch: i386 compiler: ghc-6.6 client: cabal-install-0.5.1 flags: -small_base dependencies: base-2.0 cgi-3001.1.6.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried Sorry to be so vague, but I mainly remember swearing a lot at the screen until it worked. Iain From edward.ing at gmail.com Thu Aug 7 21:10:28 2008 From: edward.ing at gmail.com (Edward Ing) Date: Thu Aug 7 21:10:04 2008 Subject: [Haskell-cafe] Building fastcgi from hackage on windows. In-Reply-To: References: <8f66da400808071258i7d145dferf8beb1dce63b0962@mail.gmail.com> Message-ID: <8f66da400808071810x2b32e5e0j4b7e18f95202d94a@mail.gmail.com> Oh yes. I should mention that I am building this on Windows XP. I build Network.FastCGI on Ubuntu and it worked because I was able to install the libfcgi-dev (which had the libraries and the headers.) My guess is that WIndows XP is the problem, and that the task of building on XP is quite different. Where are include headers and libraries found in Windows XP system? What fastcgi implementation would you need for a Windows XP? These are the probably the important questions. Edward Ing On Thu, Aug 7, 2008 at 7:54 PM, Iain Barnett wrote: > On 7 Aug 2008, at 8:58 pm, Edward Ing wrote: > >> I am using the cabal system to build the hackage version of fastcgi. >> I get the below messages with the "runghc Setup.lhs build" command. >> >> Network\FastCGI.hsc:59:21: fcgiapp.h: No such file or directory >> Network\FastCGI.hsc: In function `main': >> >> Network\FastCGI.hsc:200:0: >> error: `FCGX_Request' undeclared (first use in this function) >> >> >> >> It looks like I need the fastcgi sources. Where does this source come >> from? I didn't get any dependency messages when I did the setup >> config. >> >> >> Edward Ing > > I had a similar problem about a month ago, but I can't remember *exactly* > what I did to fix it. I think I made sure the following were installed (I'm > pretty sure I ran cabal installs for all of them regardless of what ghc-pkg > told me, and it worked) > > network-2.0 > alex-2.2 > HTTP-3001.0.4 > cgi-3001.1.6.0 > > From my cabal build-log: > From dagit at codersbase.com Thu Aug 7 21:28:37 2008 From: dagit at codersbase.com (Jason Dagit) Date: Thu Aug 7 21:28:11 2008 Subject: [Haskell-cafe] instance deduction and phantom types Message-ID: Hello, I recently had a problem where GHC couldn't deduce some type classes from my constraints. I would get error messages like: Could not deduce (Conflict (PatchInfoAnd p), Patchy (PatchInfoAnd p)) from the context (RepoPatch p) But, I had some instances like this (minus the function definitions): class (Patchy p, Effect p, FromPrims p, Conflict p) => RepoPatch p instance Effect p => Effect (PatchInfoAnd p) instance Conflict (p x y) => Conflict (PatchInfoAnd (p x y)) instance RepoPatch (p x y) => Patchy (PatchInfoAnd (p x y)) The x and y in the last two are just phantom types on p. When I noticed that the phantom types were missing from the instance definition of Effect (PatchInfoAnd p), I removed them from the last two definitions. This made the "Could not deduce..." error message disappear. Why do the phantom types not belong in the instance definition? I'd like to understand the problem more fully, but I'm not sure what the problem is or how to get started researching it, so if someone could point me in the right direction I'd be very happy! Thanks! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/7cbcfb92/attachment.htm From jefferson.r.heard at gmail.com Thu Aug 7 21:33:54 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Thu Aug 7 21:33:31 2008 Subject: [Haskell-cafe] Re: [HOpenGL] ANN: FTGL 1.0. Portable truetype font rendering in OpenGL In-Reply-To: References: <4165d3a70808071243i4aeb1c27j767c0f93ce1c1c8f@mail.gmail.com> Message-ID: <4165d3a70808071833r1c776766v3d31988dcebdf26d@mail.gmail.com> Is DeviL currently working? I don't see any Haddock documentation, and it says "build-failure ghc-6.8"... On Thu, Aug 7, 2008 at 3:49 PM, Felipe Lessa wrote: > On Thu, Aug 7, 2008 at 4:43 PM, Jefferson Heard > wrote: >> Hi folks. I've just released some Haskell bindings to FTGL at >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FTGL . > > That's a great contribution, thanks! Now we have OpenGL, GLFW, FTGL, > DevIL, OpenAL, and it's getting better and better. > > -- > Felipe. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards Is From ryani.spam at gmail.com Thu Aug 7 22:51:08 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Aug 7 22:50:44 2008 Subject: [Haskell-cafe] instance deduction and phantom types In-Reply-To: References: Message-ID: <2f9b2d30808071951o6a2115a2q748242c5a8156073@mail.gmail.com> I'm just guessing from this email; I can't see your code. Let me know if I go wrong anywhere. It looks like you expect your patches to be some type (p :: * -> * -> *); that is, a type like > data Patch x y = ... So I suspect you defined your classes like so: > class Conflict p where > hasConflict :: p x y -> Bool However, the instance declaration: > instance Conflict (p x y) => Conflict (PatchInfoAnd (p x y)) is referring to ANY types p :: * -> * -> * -> * -> * x :: * y :: * so that (p x y :: * -> * -> *); that is, a type like this: > data PatchBroken a b x y = ... in this case an instance for Conflict (PatchBroken Int Bool) would give instances for Conflict (PatchInfoAnd (PatchBroken Int Bool)). You see, there's no way for the instance declaration for Conflict to apply from your context (RepoPatch p); in fact, it can't possibly match, because the "p" in RepoPatch p has kind * -> * -> *, whereas the "p" in the instance declaration has kind * -> * -> * -> * -> *. You just had useless instance declarations that would never trigger. By removing the extra "x y" that were not expected to be there, you fixed the code to match your actual intent, and the compiler was able to derive the proper typeclass memberships. -- ryan 2008/8/7 Jason Dagit : > Hello, > > I recently had a problem where GHC couldn't deduce some type classes from my > constraints. I would get error messages like: > Could not deduce (Conflict (PatchInfoAnd p), > Patchy (PatchInfoAnd p)) > from the context (RepoPatch p) > > But, I had some instances like this (minus the function definitions): > class (Patchy p, Effect p, FromPrims p, Conflict p) => RepoPatch p > > instance Effect p => Effect (PatchInfoAnd p) > > instance Conflict (p x y) => Conflict (PatchInfoAnd (p x y)) > > instance RepoPatch (p x y) => Patchy (PatchInfoAnd (p x y)) > > The x and y in the last two are just phantom types on p. When I noticed > that the phantom types were missing from the instance definition of Effect > (PatchInfoAnd p), I removed them from the last two definitions. This made > the "Could not deduce..." error message disappear. > > Why do the phantom types not belong in the instance definition? I'd like to > understand the problem more fully, but I'm not sure what the problem is or > how to get started researching it, so if someone could point me in the right > direction I'd be very happy! > > Thanks! > Jason > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ryani.spam at gmail.com Thu Aug 7 22:58:22 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Aug 7 22:57:57 2008 Subject: [Haskell-cafe] instance deduction and phantom types In-Reply-To: <2f9b2d30808071951o6a2115a2q748242c5a8156073@mail.gmail.com> References: <2f9b2d30808071951o6a2115a2q748242c5a8156073@mail.gmail.com> Message-ID: <2f9b2d30808071958u7c6cf328j7fb11fab0b4ec1d5@mail.gmail.com> Also, you may find it helpful to add > {-# LANGUAGE KindSignatures #-} to the top of your program, and start annotating your class and instance declarations for clarity: > class Conflict (p :: * -> * -> *) where > hasConflict :: p x y -> Bool The compiler has been doing kind inference where necessary to figure this out; for example, the declaration I just gave shows that p must have kind (* -> * -> *) because "p x y" is a function argument and only concrete types of kind * can be used as function arguments. If you don't specify and the compiler can't determine otherwise, it assumes you mean kind "*"; so if you had a typeclass with no functions: > class Demo a "a :: *" is assumed. The KindSignatures extension allows you to explicitly override this when needed: > class Demo2 (a :: (* -> *) -> * -> *) > instance Demo2 (ReaderT r) -- ryan On Thu, Aug 7, 2008 at 7:51 PM, Ryan Ingram wrote: > I'm just guessing from this email; I can't see your code. Let me know > if I go wrong anywhere. > > It looks like you expect your patches to be some type (p :: * -> * -> > *); that is, a type like > >> data Patch x y = ... > > So I suspect you defined your classes like so: > >> class Conflict p where >> hasConflict :: p x y -> Bool > > However, the instance declaration: > >> instance Conflict (p x y) => Conflict (PatchInfoAnd (p x y)) > > is referring to ANY types > p :: * -> * -> * -> * -> * > x :: * > y :: * > so that (p x y :: * -> * -> *); that is, a type like this: > >> data PatchBroken a b x y = ... > > in this case an instance for Conflict (PatchBroken Int Bool) would > give instances for Conflict (PatchInfoAnd (PatchBroken Int Bool)). > > You see, there's no way for the instance declaration for Conflict to > apply from your context (RepoPatch p); in fact, it can't possibly > match, because the "p" in RepoPatch p has kind * -> * -> *, whereas > the "p" in the instance declaration has kind * -> * -> * -> * -> *. > > You just had useless instance declarations that would never trigger. > By removing the extra "x y" that were not expected to be there, you > fixed the code to match your actual intent, and the compiler was able > to derive the proper typeclass memberships. > > -- ryan > > 2008/8/7 Jason Dagit : >> Hello, >> >> I recently had a problem where GHC couldn't deduce some type classes from my >> constraints. I would get error messages like: >> Could not deduce (Conflict (PatchInfoAnd p), >> Patchy (PatchInfoAnd p)) >> from the context (RepoPatch p) >> >> But, I had some instances like this (minus the function definitions): >> class (Patchy p, Effect p, FromPrims p, Conflict p) => RepoPatch p >> >> instance Effect p => Effect (PatchInfoAnd p) >> >> instance Conflict (p x y) => Conflict (PatchInfoAnd (p x y)) >> >> instance RepoPatch (p x y) => Patchy (PatchInfoAnd (p x y)) >> >> The x and y in the last two are just phantom types on p. When I noticed >> that the phantom types were missing from the instance definition of Effect >> (PatchInfoAnd p), I removed them from the last two definitions. This made >> the "Could not deduce..." error message disappear. >> >> Why do the phantom types not belong in the instance definition? I'd like to >> understand the problem more fully, but I'm not sure what the problem is or >> how to get started researching it, so if someone could point me in the right >> direction I'd be very happy! >> >> Thanks! >> Jason >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > From dagit at codersbase.com Thu Aug 7 23:11:16 2008 From: dagit at codersbase.com (Jason Dagit) Date: Thu Aug 7 23:10:51 2008 Subject: [Haskell-cafe] instance deduction and phantom types In-Reply-To: <2f9b2d30808071958u7c6cf328j7fb11fab0b4ec1d5@mail.gmail.com> References: <2f9b2d30808071951o6a2115a2q748242c5a8156073@mail.gmail.com> <2f9b2d30808071958u7c6cf328j7fb11fab0b4ec1d5@mail.gmail.com> Message-ID: Thank you for the quick response. It's very helpful and makes perfect sense now. On Thu, Aug 7, 2008 at 7:58 PM, Ryan Ingram wrote: > Also, you may find it helpful to add > > > {-# LANGUAGE KindSignatures #-} > > to the top of your program, and start annotating your class and > instance declarations for clarity: > > > class Conflict (p :: * -> * -> *) where > > hasConflict :: p x y -> Bool > Ah, yes we do that sometimes, but not with consistency. > > On Thu, Aug 7, 2008 at 7:51 PM, Ryan Ingram wrote: > > I'm just guessing from this email; I can't see your code. Let me know > > if I go wrong anywhere. > > > > It looks like you expect your patches to be some type (p :: * -> * -> > > *); that is, a type like > > > >> data Patch x y = ... > Yes, that's right and sorry for not including Patch. > > > > > However, the instance declaration: > > > >> instance Conflict (p x y) => Conflict (PatchInfoAnd (p x y)) > > > > is referring to ANY types > > p :: * -> * -> * -> * -> * > > x :: * > > y :: * > > so that (p x y :: * -> * -> *); that is, a type like this: > > > >> data PatchBroken a b x y = ... > > > > in this case an instance for Conflict (PatchBroken Int Bool) would > > give instances for Conflict (PatchInfoAnd (PatchBroken Int Bool)). > That makes perfect sense. So, by including x and y in the instance I was dramatically changing the kind inference. That didn't occur to me earlier, but it does make sense. Thanks! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080807/72ecb490/attachment.htm From bulat.ziganshin at gmail.com Fri Aug 8 01:49:45 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Aug 8 01:51:17 2008 Subject: [Haskell-cafe] Currying function using values from array In-Reply-To: <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> References: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> <78dc001e0808071249w1624d9cg339c2970550c8999@mail.gmail.com> <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> Message-ID: <13510381636.20080808094945@gmail.com> Hello Sukit, Friday, August 8, 2008, 3:52:51 AM, you wrote: it requires use of typeclasses instance C f => C (a->f) curry (somef::(a->f)) (someas::[a]) = (somef (head someas)) (tail someas) and so on. look into hslua sources, for example: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslua > Thanks Tom and Henning for your response. Let me put the question > in another way by generalizing and tweaking it a little bit. > How in Haskell that I can create a function that curries any other > function, which receives multiple parameters, by using a the input > from a list (same data type) or a tuple (mixed data type) such that > it either returns another closure (if not all parameters are > curried) or the final value of the computation (when all parameters are known)? > > Ed > On Thu, Aug 7, 2008 at 12:49 PM, Tom Nielsen wrote: > Maybe you want something like > > curryWithList :: ([a]->b)->[a]->([a]->b) > curryWithList f lst1= \lst2 ->f (lst1++lst2) > > addThemUp = sum > curried = curryWithList addThemUp [1,2,3,4] > curried [5] =15 > > On Thu, Aug 7, 2008 at 8:35 PM, Henning Thielemann > wrote: >> >> On Thu, 7 Aug 2008, Sukit Tretriluxana wrote: >> >>> Dear Haskell experts, >>> >>> I am currently studying Groovy language. An experiment I did with its >>> closure is to perform closure/function "curry" using an array containing the >>> values for the parameter binding. See the sample below. >>> >>> int addThemUp(a,b,c,d,e) { a+b+c+d+e } >>> def arrayCurry(arr, cls) { arr.inject(cls) { c, v -> c.curry(v) } } >>> println addThemUp(1,2,3,4,5) >>> println arrayCurry([1,2,3,4,5], this.&addThemUp)() >>> println arrayCurry([1,2,3,4], this.&addThemUp)(5) >>> >>> The printouts from the above code are the same, verifying that the code >>> works fine. Then I come to ask myself how I can do the same in Haskell. I'm >>> not a Haskell expert so I couldn't figure it. I wonder if you guys could >>> shed some light on this. >> >> I do not know Groovy, but maybe you want something like >> >> ?addThemUp :: Num a => (a,a,a,a,a) -> a >> ?addThemUp (a,b,c,d,e) = a+b+c+d+e >> >> ?-- should be better named list5Curry or so >> ?arrayCurry :: ((a,a,a,a,a) -> a) -> [a] -> a >> ?arrayCurry cls [a,b,c,d,e] = cls (a,b,c,d,e) >> >> ?print (addThemUp(1,2,3,4,5::Int)) >> ?print (arrayCurry addThemUp [1,2,3,4,5::Int]) >> >> However, it's hardly of any use, since you won't use a list if the number >> of elements is fixed (and small) or if the elements even must have >> distinct types. > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jason.dusek at gmail.com Fri Aug 8 04:23:11 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Aug 8 04:22:44 2008 Subject: [Haskell-cafe] adjunction of product and exponentiation In-Reply-To: <1218089240.6439.9.camel@jonathans-macbook> References: <42784f260808061356x6d27fe11ud37b919f3a40f87f@mail.gmail.com> <1218058352.10631.42.camel@jcchost> <42784f260808062250p104eb0b7kc209c28c9edab032@mail.gmail.com> <1218089240.6439.9.camel@jonathans-macbook> Message-ID: <42784f260808080123p3a16023dt73faba1e40e35843@mail.gmail.com> Thanks! -- _jsn From tittoassini at gmail.com Fri Aug 8 05:57:50 2008 From: tittoassini at gmail.com (Pasqualino 'Titto' Assini) Date: Fri Aug 8 05:57:30 2008 Subject: [Haskell-cafe] Last Call for the Italian Haskellers Summer Meeting In-Reply-To: <489B3255.7000300@imageworks.com> References: <2d34474e0808062331w3826a89bn33b19cbd00cbd299@mail.gmail.com> <489B3255.7000300@imageworks.com> Message-ID: <200808081157.50311.tittoassini@gmail.com> On Thursday 07 August 2008 19:35:17 Dan Weston wrote: > Shouldn't that be "posta elettronica" (or "posteletta" along the lines > of the Frence "courriel")? Somehow I doubt that Dante would have > approved of the word "email". Actually I don't think that he would have disapproved. Dante wrote the "Divina Commedia" in the Florentine dialect, a 'vulgar' language that was far from codified and quite open to external influences. Mussolini, on the contrary, with his nationalistic/racist mindset would have been mightly pissed off by my usage of 'email' and would have certainly insisted for 'posta elettronica' (a perfect valid term by the way, just a bit longer than necessary). But then who cares if Mussolini spins in his grave? Best, titto > Titto Assini wrote: > > As usual we will now switch to Dante's "bella lingua". > > > > > > Ottimissimi, > > > > mancano pochi giorni al primo incontro estivo/balneare degli haskeller > > italiani. > > > > Per informazioni e registrarsi date uno sguardo a: > > http://www.haskell.org/haskellwiki/ItaloHaskell/Summer_2008 > > > > Oppure contattate il sottoscritto via email o per telefono al 0584 > > 791669. > > > > A presto ragazzi, > > > > titto -- -------------------------------- Pasqualino "Titto" Assini PhD 25 Heath Road - Wivenhoe CO79PT - Colchester - U.K. From iainspeed at gmail.com Fri Aug 8 06:08:23 2008 From: iainspeed at gmail.com (Iain Barnett) Date: Fri Aug 8 06:08:11 2008 Subject: [Haskell-cafe] Building fastcgi from hackage on windows. In-Reply-To: <8f66da400808071810x2b32e5e0j4b7e18f95202d94a@mail.gmail.com> References: <8f66da400808071258i7d145dferf8beb1dce63b0962@mail.gmail.com> <8f66da400808071810x2b32e5e0j4b7e18f95202d94a@mail.gmail.com> Message-ID: <0B171B2A-C008-4FCD-9C33-AED0B4051F80@gmail.com> have you installed this? http://www.softpedia.com/progDownload/Microsoft-FastCGI-Extension-for- IIS-Download-84830.html I use Asp.Net when I'm on Windows, so I don't know the answers to your questions but you might find more info on running it here http://forums.iis.net/1103.aspx Iain On 8 Aug 2008, at 2:10 am, Edward Ing wrote: > Oh yes. I should mention that I am building this on Windows XP. I > build Network.FastCGI on Ubuntu and it worked because I was able to > install the libfcgi-dev (which had the libraries and the headers.) > > My guess is that WIndows XP is the problem, and that the task of > building on XP is quite different. Where are include headers and > libraries found in Windows XP system? What fastcgi implementation > would you need for a Windows XP? These are the probably the important > questions. > > > Edward Ing > > On Thu, Aug 7, 2008 at 7:54 PM, Iain Barnett > wrote: >> On 7 Aug 2008, at 8:58 pm, Edward Ing wrote: >> >>> I am using the cabal system to build the hackage version of fastcgi. >>> I get the below messages with the "runghc Setup.lhs build" command. >>> >>> Network\FastCGI.hsc:59:21: fcgiapp.h: No such file or directory >>> Network\FastCGI.hsc: In function `main': >>> >>> Network\FastCGI.hsc:200:0: >>> error: `FCGX_Request' undeclared (first use in this function) >>> >>> >>> >>> It looks like I need the fastcgi sources. Where does this source >>> come >>> from? I didn't get any dependency messages when I did the setup >>> config. >>> >>> >>> Edward Ing >> >> I had a similar problem about a month ago, but I can't remember >> *exactly* >> what I did to fix it. I think I made sure the following were >> installed (I'm >> pretty sure I ran cabal installs for all of them regardless of >> what ghc-pkg >> told me, and it worked) >> >> network-2.0 >> alex-2.2 >> HTTP-3001.0.4 >> cgi-3001.1.6.0 >> >> From my cabal build-log: >> From mik at konecny.aow.cz Fri Aug 8 08:38:56 2008 From: mik at konecny.aow.cz (Michal Konecny) Date: Fri Aug 8 08:38:34 2008 Subject: [Haskell-cafe] ANN: interval and polynomial enclosure arithmetics Message-ID: <200808081338.57827.mik@konecny.aow.cz> Hello, I have recently released the following two Haskell packages, which model and reasonably efficiently implement exact real arithmetic: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AERN-Real implements arbitrary-precision interval arithmetic for approximating real numbers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AERN-RnToRm implements arbitrary-precision arithmetic of bounded-degree piecewise-polynomial enclosures for approximating functions of type R^n -> R^m The libraries are fairly stable and complete (AERN-Real more so than AERN-RnToRm) and members of the KEG research group at Aston University have used it for reliably solving differential equations and numerical constraint satisfaction problems. Also, the libraries are designed in multiple levels of abstraction that are clearly separated by type classes. Thanks to this it is very easy to switch between different implementations of the lower-levels, eg using a different floating point type or different representation of polynomials. There are many similarities between AERN-Real and Augustsson's numbers package. The main difference is in how the bit-size of arbitrary precision floating point numbers is determined. In numbers, the bit size is determined statically via types using a type-level encoding of natural numbers. In AERN-Real, the bit-size is part of the floating-point number, which slows the arithmetic down a bit but one can change precision dynamically. Best regards, Michal -- |-| Dr. Michal Konecny, Computer Science, Aston University |-| Room MB212D | Tel +44 121 204 3462 | Fax +44 121 204 3681 |-| http://www.aston.ac.uk/~konecnym |-| OpenPGP key http://www.aston.ac.uk/~konecnym/ki.aston -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080808/0435eef5/attachment.bin From briqueabraque at yahoo.com Fri Aug 8 08:54:47 2008 From: briqueabraque at yahoo.com (=?UTF-8?B?TWF1csOtwq1jaW8=?=) Date: Fri Aug 8 08:54:35 2008 Subject: [Haskell-cafe] Re: USB and serial port In-Reply-To: <220e47b40808070824l1137ef3fy8e7c1117356d65f8@mail.gmail.com> References: <220e47b40808070824l1137ef3fy8e7c1117356d65f8@mail.gmail.com> Message-ID: Interesting! The new version of the library really deserves a wrapper. Thanks, Maur?cio > I'm currently using partial wrapper around libusb[1] in my work. It > doesn't provide full interface to the library itself, so I didn't have > to translate C structures. Perhaps someone can make a regular wrapper > - the libusb API is pretty small and concise. > > Regards, > Christopher Skrz?tnicki > > [1] http://libusb.wiki.sourceforge.net/ > > On Wed, Aug 6, 2008 at 23:11, Maur??cio wrote: >> Hi, >> >> What are the alternatives to read >> a USB port(...) From edward.ing at gmail.com Fri Aug 8 10:53:33 2008 From: edward.ing at gmail.com (Edward Ing) Date: Fri Aug 8 10:53:06 2008 Subject: [Haskell-cafe] Building fastcgi from hackage on windows. In-Reply-To: <0B171B2A-C008-4FCD-9C33-AED0B4051F80@gmail.com> References: <8f66da400808071258i7d145dferf8beb1dce63b0962@mail.gmail.com> <8f66da400808071810x2b32e5e0j4b7e18f95202d94a@mail.gmail.com> <0B171B2A-C008-4FCD-9C33-AED0B4051F80@gmail.com> Message-ID: <8f66da400808080753x549334ffg28652e4901d869a2@mail.gmail.com> I have this installed. The problem is that I have no binary version of the Network.FastCGI. So to install it I am going through the cabal process and on the build it seems to need the Fastcgi.h to build the foreign interfaces (and probably the static libraries to link ?). Unfortunately the Microsoft download pack doesn't have that - just the .dll (or perhaps cabal can't find where the fastcgi.h are). Edward Ing On Fri, Aug 8, 2008 at 6:08 AM, Iain Barnett wrote: > have you installed this? > http://www.softpedia.com/progDownload/Microsoft-FastCGI-Extension-for-IIS-Download-84830.html > > I use Asp.Net when I'm on Windows, so I don't know the answers to your > questions but you might find more info on running it here > http://forums.iis.net/1103.aspx > > Iain > > From gtener at gmail.com Fri Aug 8 12:45:29 2008 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Fri Aug 8 12:45:01 2008 Subject: [Haskell-cafe] Re: USB and serial port In-Reply-To: References: <220e47b40808070824l1137ef3fy8e7c1117356d65f8@mail.gmail.com> Message-ID: <220e47b40808080945g214e83b5g62ead61b0522c1da@mail.gmail.com> Which version do you consider "new": the current 0.1.12 or the future 1.0 version? Regards, Christopher Skrz?tnicki On Fri, Aug 8, 2008 at 14:54, Maur??cio wrote: > Interesting! The new version of the library > really deserves a wrapper. > > Thanks, > Maur?cio > >> I'm currently using partial wrapper around libusb[1] in my work. It >> doesn't provide full interface to the library itself, so I didn't have >> to translate C structures. Perhaps someone can make a regular wrapper >> - the libusb API is pretty small and concise. >> >> Regards, >> Christopher Skrz?tnicki >> >> [1] http://libusb.wiki.sourceforge.net/ >> >> On Wed, Aug 6, 2008 at 23:11, Maur??cio wrote: >>> >>> Hi, >>> >>> What are the alternatives to read >>> a USB port(...) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From andrewcoppin at btinternet.com Wed Aug 6 14:06:44 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Aug 8 13:44:46 2008 Subject: [Haskell-cafe] Show me In-Reply-To: <1217994105.6389.1.camel@jonathans-macbook> References: <4898A9E9.1060503@btinternet.com> <1217994105.6389.1.camel@jonathans-macbook> Message-ID: <4899E834.7010707@btinternet.com> Jonathan Cast wrote: > instance Show x => Show (Foo x) where > showsPrec n foo = ("list_foo "++) . shows (foo_list foo) > > You use the n parameter if you've got an infix operator in your syntax > and you want to put parentheses around an instance of it if n has the > wrong value (either too high or too low, I can never remember). > OK. So... should the call to shows actually be showsPrec? Or does it not matter in this case? Actually, now that I think of it, my *next* problem is going to be writing a matching Read instance... From andrewcoppin at btinternet.com Wed Aug 6 14:09:43 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Aug 8 13:44:50 2008 Subject: [Haskell-cafe] Phantoms Message-ID: <4899E8E7.6090000@btinternet.com> I just (re)discovered that I can do things like data Foo x = Foo Int Int Now "Foo Int" and "Foo Double" are, as far as the type checker cares, two completely different types, even though in fact they are the same. This is actually Quite Useful, in the particular case I'm working on. Here's the thing though... How do I get it so that "Foo Int" and "Foo Double" produce slightly different strings when printed? From briqueabraque at yahoo.com Fri Aug 8 13:47:13 2008 From: briqueabraque at yahoo.com (=?UTF-8?B?TWF1csOtwq1jaW8=?=) Date: Fri Aug 8 13:47:01 2008 Subject: [Haskell-cafe] Re: USB and serial port In-Reply-To: <220e47b40808080945g214e83b5g62ead61b0522c1da@mail.gmail.com> References: <220e47b40808070824l1137ef3fy8e7c1117356d65f8@mail.gmail.com> <220e47b40808080945g214e83b5g62ead61b0522c1da@mail.gmail.com> Message-ID: 1.0. By the time one finishes a Haskell wrapper, 1.0 will be probably available, so I think it's better to start with that. > Which version do you consider "new": the current 0.1.12 or the future > 1.0 version? > > Regards, > Christopher Skrz?tnicki > > On Fri, Aug 8, 2008 at 14:54, Maur??cio wrote: >> Interesting! The new version of the library >> really deserves a wrapper. >> >> Thanks, >> Maur?cio >> >>> I'm currently using partial wrapper around libusb[1] (...) From bulat.ziganshin at gmail.com Fri Aug 8 13:56:50 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Aug 8 13:58:45 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <4899E8E7.6090000@btinternet.com> References: <4899E8E7.6090000@btinternet.com> Message-ID: <349654066.20080808215650@gmail.com> Hello Andrew, Wednesday, August 6, 2008, 10:09:43 PM, you wrote: > Here's the thing though... How do I get it so that "Foo Int" and "Foo > Double" produce slightly different strings when printed? instnace Show (Foo Int) ... instnace Show (Foo Double) ... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jonathanccast at fastmail.fm Fri Aug 8 13:59:04 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Aug 8 14:00:34 2008 Subject: [Haskell-cafe] Show me In-Reply-To: <4899E834.7010707@btinternet.com> References: <4898A9E9.1060503@btinternet.com> <1217994105.6389.1.camel@jonathans-macbook> <4899E834.7010707@btinternet.com> Message-ID: <1218218344.20988.69.camel@jcchost> On Wed, 2008-08-06 at 19:06 +0100, Andrew Coppin wrote: > Jonathan Cast wrote: > > instance Show x => Show (Foo x) where > > showsPrec n foo = ("list_foo "++) . shows (foo_list foo) > > > > You use the n parameter if you've got an infix operator in your syntax > > and you want to put parentheses around an instance of it if n has the > > wrong value (either too high or too low, I can never remember). > OK. So... should the call to shows actually be showsPrec? Or does it not > matter in this case? According to http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-Show.html#shows, shows = showsPrec 0 (which is a global function like show, not a class method). In this case, showsPrec will then further dispatch to your showList method, which has the default implementation, which will ignore the precedence parameter. So it doesn't matter in this case. > Actually, now that I think of it, my *next* problem is going to be > writing a matching Read instance... Are you familiar with Text.ParserCombinators.ReadP? http://www.haskell.org/ghc/docs/latest/html/libraries/base/Text-ParserCombinators-ReadP.html? It's an explicit monad, so it's rather easier to use that ReadS. jcc From trevor at galois.com Fri Aug 8 13:59:48 2008 From: trevor at galois.com (Trevor Elliott) Date: Fri Aug 8 14:00:57 2008 Subject: [Haskell-cafe] Phantoms Message-ID: <1218218388.5874.8.camel@trogdor> Hi Andrew, Here's an example that might help: > import Data.Typeable > > data Test a = Test Int > > instance Typeable a => Show (Test a) where > show t@(Test i) = "Test " ++ show (typeOf (ty t)) ++ " " ++ show i > where > ty :: Test a -> a, > ty = undefined and its use: *Main> show (Test 10 :: Test Int) "Test Int 10" *Main> show (Test 10 :: Test String) "Test [Char] 10" --trevor On Wed, 2008-08-06 at 19:09 +0100, Andrew Coppin wrote: > I just (re)discovered that I can do things like > > data Foo x = Foo Int Int > > Now "Foo Int" and "Foo Double" are, as far as the type checker cares, > two completely different types, even though in fact they are the same. > This is actually Quite Useful, in the particular case I'm working on. > > Here's the thing though... How do I get it so that "Foo Int" and "Foo > Double" produce slightly different strings when printed? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080808/157ce00b/attachment.bin From lchangying at gmail.com Fri Aug 8 14:42:01 2008 From: lchangying at gmail.com (Changying Li) Date: Fri Aug 8 14:49:39 2008 Subject: [Haskell-cafe] please help me to find errors from my first app Message-ID: <87tzdv8i2u.fsf@gmail.com> Hi. I want to write a reverse proxy like perlbal to practive haskell. Now I just write a very simple script to forward any request to www.google.com. but it dosn't work. I run command ' runhaskell Proxy.hs' and 'wget http://localhost:8080/'. but wget just wait forever and runhaskkell can get request. when I break wget, the 'runhaskell' can print response returned from www.google.com. why? module Main where import System.Posix.Process import Network import Prelude hiding (putStr) import System.IO hiding (hGetContents, putStr) import Control.Concurrent import System.Posix.Signals import Data.ByteString.Lazy.Char8 (hGetContents, hPut, putStr,hGet,cons) listenPort = PortNumber 8080 connectToHost = "208.67.219.230" connectToPort = PortNumber 80 main :: IO () main = do hSetBuffering stdout NoBuffering socket <- listenOn listenPort let doLoop = do (hdl, _, _) <- accept socket forkIO $ processRequest hdl doLoop doLoop processRequest :: Handle -> IO () processRequest hRequest = do installHandler sigPIPE Ignore Nothing; hSetBuffering hRequest NoBuffering hSetBuffering stdout NoBuffering request <- hGetContents hRequest putStr $ '>' `cons` (' ' `cons` request) hResponse <- connectTo connectToHost connectToPort hSetBuffering hResponse NoBuffering hPut hResponse request response <- hGetContents hResponse putStr $ '<' `cons` (' ' `cons` response) hPut hRequest response hClose hRequest hClose hResponse -- Thanks & Regards Changying Li From lemming at henning-thielemann.de Fri Aug 8 14:58:21 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Aug 8 14:58:01 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <4899E8E7.6090000@btinternet.com> References: <4899E8E7.6090000@btinternet.com> Message-ID: On Wed, 6 Aug 2008, Andrew Coppin wrote: > I just (re)discovered that I can do things like > > data Foo x = Foo Int Int > > Now "Foo Int" and "Foo Double" are, as far as the type checker cares, > two completely different types, even though in fact they are the same. > This is actually Quite Useful, in the particular case I'm working on. > > Here's the thing though... How do I get it so that "Foo Int" and "Foo > Double" produce slightly different strings when printed? The non-hacky Haskell 98 solution is: class ShowPhantom a where showPhantom :: Foo a -> String You can call this from the 'show' implemention for 'Foo a'. From bjorn at bringert.net Fri Aug 8 15:09:01 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Fri Aug 8 15:08:33 2008 Subject: [Haskell-cafe] Building fastcgi from hackage on windows. In-Reply-To: <8f66da400808080753x549334ffg28652e4901d869a2@mail.gmail.com> References: <8f66da400808071258i7d145dferf8beb1dce63b0962@mail.gmail.com> <8f66da400808071810x2b32e5e0j4b7e18f95202d94a@mail.gmail.com> <0B171B2A-C008-4FCD-9C33-AED0B4051F80@gmail.com> <8f66da400808080753x549334ffg28652e4901d869a2@mail.gmail.com> Message-ID: Hi Edward, I have never compiled the fastcgi package on Windows myself, but my best tip would be to try to install the FastCGI development kit (= C headers and libraries), see http://www.fastcgi.com/#TheDevKit /Bjorn On Fri, Aug 8, 2008 at 4:53 PM, Edward Ing wrote: > I have this installed. The problem is that I have no binary version of > the Network.FastCGI. So to install it I am going through the cabal > process and on the build it seems to need the Fastcgi.h to build the > foreign interfaces (and probably the static libraries to link ?). > Unfortunately the Microsoft download pack doesn't have that - just the > .dll (or perhaps cabal can't find where the fastcgi.h are). > > Edward Ing > > On Fri, Aug 8, 2008 at 6:08 AM, Iain Barnett wrote: >> have you installed this? >> http://www.softpedia.com/progDownload/Microsoft-FastCGI-Extension-for-IIS-Download-84830.html >> >> I use Asp.Net when I'm on Windows, so I don't know the answers to your >> questions but you might find more info on running it here >> http://forums.iis.net/1103.aspx >> >> Iain >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ryani.spam at gmail.com Fri Aug 8 17:08:22 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Aug 8 17:07:54 2008 Subject: [Haskell-cafe] Currying function using values from array In-Reply-To: <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> References: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> <78dc001e0808071249w1624d9cg339c2970550c8999@mail.gmail.com> <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> Message-ID: <2f9b2d30808081408o43a05a0ai70dbe3d6709c81f5@mail.gmail.com> 2008/8/7 Sukit Tretriluxana : > How in Haskell that I can create a function that curries any other function, > which receives multiple parameters, by using a the input from a list (same > data type) or a tuple (mixed data type) such that it either returns another > closure (if not all parameters are curried) or the final value of the > computation (when all parameters are known)? Here's a solution that uses tuples only (no lists, they are somewhat more difficult to typecheck correctly), along with several tests. The payoff is functions with signatures like this: -- tncurry :: (a -> b -> c -> r) -> (a,b,c) -> r -- trcurry :: ((a,b,c) -> r) -> a -> b -> c -> r -- ncurry :: (a -> b -> c -> r) -> (a, (b, (c, ()))) -> r -- rcurry :: ((a, (b, (c, ()))) -> r) -> a -> b -> c -> r but that work on any number of arguments. (disclaimer: I've only implemented tncurry & trcurry up to 4-tuples; additional tuple sizes require 3 lines of boilerplate code each). -- ryan {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances -fno-monomorphism-restriction #-} module Curry where -- no-monomorphism-restriction is just so we don't -- have to put dummy arguments on the tests. class IsFunction f a r | f -> a r, a r -> f where apply :: f -> a -> r instance IsFunction (a -> b) a b where apply = ($) class NCurry f a r | f a -> r where ncurry :: f -> a -> r instance NCurry r () r where ncurry x _ = x instance (IsFunction f' b f, NCurry f a r) => NCurry f' (b,a) r where ncurry f (b,a) = ncurry (apply f b) a class RCurry t x r | t x -> r where rcurry :: (t -> x) -> r instance RCurry () r r where rcurry f = f () instance RCurry t x r => RCurry (a,t) x (a -> r) where rcurry f x = rcurry (\t -> f (x,t)) -- some tests test1 = ncurry (+) (5, (10, ())) -- test1 :: Num f => f -- test1 => 15 plus :: Num a => (a, (a, ())) -> a plus = ncurry (+) test2 = rcurry plus -- test2 :: Num a => a -> a -> a test_broken = rcurry (ncurry (+)) -- test_broken :: (Num a, NCurry (a -> a -> a) t r, RCurry t r r1) => r1 {- test_broken 5 10 => No instances for (NCurry (a -> a -> a) t r, RCurry t r (t1 -> t2 -> t3)) This is an instance of the "read.show" problem; ncurry (+) has many types: ncurry (+) :: Num a => () -> a -> a -> a ncurry (+) :: Num a => (a,()) -> a -> a ncurry (+) :: Num a => (a,(a,())) -> a Even though rcurry would work on any of these, it's ambiguous which one to choose, so the type inferencer gives up. -} test3 = test2 5 10 -- test3 :: Num t => t -- test3 => 15 -- stupid constant function dumb a b c d = c test4 = ncurry dumb ("wrong", (5, ("correct", ([1..50], ())))) -- test4 :: [Char] -- test4 => "correct" dumb2 (a, (b, (c, (d, ())))) = c test5 = rcurry dumb2 -- test5 :: t -> t1 -> r -> t2 -> r test6 = rcurry dumb2 "wrong" 5 "correct" [1..50] -- test6 :: [Char] -- test6 => "correct" -- We can also use "real" tuples instead of tuple-lists, with -- some boilerplate... class TupleChange n t | n -> t, t -> n where toTuple :: n -> t fromTuple :: t -> n -- Haskell doesn't have a "1-tuple", so make it ourselves data Tuple1 x = Tuple1 x deriving (Eq, Show, Ord) instance TupleChange () () where toTuple = id fromTuple = id instance TupleChange (a, ()) (Tuple1 a) where toTuple (a, ()) = Tuple1 a fromTuple (Tuple1 a) = (a, ()) instance TupleChange (a, (b, ())) (a, b) where toTuple (a, (b, ())) = (a,b) fromTuple (a,b) = (a, (b, ())) instance TupleChange (a, (b, (c, ()))) (a,b,c) where toTuple (a, (b, (c, ()))) = (a,b,c) fromTuple (a,b,c) = (a, (b, (c, ()))) instance TupleChange (a, (b, (c, (d, ())))) (a,b,c,d) where toTuple (a, (b, (c, (d, ())))) = (a,b,c,d) fromTuple (a,b,c,d) = (a, (b, (c, (d, ())))) tncurry f = ncurry f . fromTuple trcurry f = rcurry (f . toTuple) -- Tests of tncurry/trcurry & show closures test7 = tncurry (+) (Tuple1 5) -- test7 :: Num a => a -> a -- test7 10 => 15 dumb3 (a,b,c,d) = c test8 = trcurry dumb3 -- test8 :: t -> t1 -> r -> t2 -> r -- test9 creates a closure waiting for more -- arguments... test9 = tncurry dumb ("foo", "bar", "hat") -- test9 :: t -> [Char] -- test9 "baz" => "hat" -- although you do have to use tncurry again -- with each call if you want to keep applying -- it with tuples test10 = tncurry (tncurry dumb ("foo", "bar", "hat")) (Tuple1 "baz") -- test10 :: [Char] -- test10 => "hat" From schlepptop at henning-thielemann.de Fri Aug 8 17:39:29 2008 From: schlepptop at henning-thielemann.de (Lemming) Date: Fri Aug 8 17:38:03 2008 Subject: [Haskell-cafe] Currying function using values from array In-Reply-To: <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> References: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> <78dc001e0808071249w1624d9cg339c2970550c8999@mail.gmail.com> <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> Message-ID: <489CBD11.3090104@henning-thielemann.de> Sukit Tretriluxana schrieb: > Thanks Tom and Henning for your response. Let me put the question in > another way by generalizing and tweaking it a little bit. > > How in Haskell that I can create a function that curries *any *other > function, which receives multiple parameters, by using a the input from > a list (same data type) or a tuple (mixed data type) such that it either > returns another closure (if not all parameters are curried) or the final > value of the computation (when all parameters are known)? Is this a theoretical question or do you actually need this? If yes, I wonder what application it may be. From tretriluxana.s at gmail.com Fri Aug 8 18:29:59 2008 From: tretriluxana.s at gmail.com (Sukit Tretriluxana) Date: Fri Aug 8 18:29:30 2008 Subject: [Haskell-cafe] Currying function using values from array In-Reply-To: <489CBD11.3090104@henning-thielemann.de> References: <8252533f0808071131h2c72247atdf7edd52029caf7d@mail.gmail.com> <78dc001e0808071249w1624d9cg339c2970550c8999@mail.gmail.com> <8252533f0808071652w5674a2d2ic686092267e3ad44@mail.gmail.com> <489CBD11.3090104@henning-thielemann.de> Message-ID: <8252533f0808081529m5f0eec27uc78e6a00df2f5bd0@mail.gmail.com> Thanks so much for the response so far. To Lemming's question, this is just a theoretical question. I try comparing what I can do in Groovy with Haskell. So far I could come up with solutions but not this one. I'm not an expert on this but I'm not sure if template haskell or type class would come to rescue this situation. And if so, I wonder how it looks like. Ed On Fri, Aug 8, 2008 at 2:39 PM, Lemming wrote: > Sukit Tretriluxana schrieb: > >> Thanks Tom and Henning for your response. Let me put the question in >> another way by generalizing and tweaking it a little bit. >> >> How in Haskell that I can create a function that curries *any *other >> function, which receives multiple parameters, by using a the input from a >> list (same data type) or a tuple (mixed data type) such that it either >> returns another closure (if not all parameters are curried) or the final >> value of the computation (when all parameters are known)? >> > > Is this a theoretical question or do you actually need this? If yes, I > wonder what application it may be. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080808/25abe01f/attachment.htm From roma at ro-che.info Sat Aug 9 08:03:46 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat Aug 9 08:03:18 2008 Subject: [Haskell-cafe] ANN: interval and polynomial enclosure arithmetics In-Reply-To: <200808081338.57827.mik@konecny.aow.cz> References: <200808081338.57827.mik@konecny.aow.cz> Message-ID: <20080809120346.GA6516@flit> * Michal Konecny [2008-08-08 13:38:56+0100] > and members of the KEG research group at Aston > University have used it for reliably solving differential equations > and numerical constraint satisfaction problems. This's very interesting. Do you have any published papers (or other sources of information) about it? -- Roman I. Cheplyaka :: http://ro-che.info/ kzm: My program contains a bug. How ungrateful, after all I've done for it. From haskell at pkturner.org Sat Aug 9 08:40:40 2008 From: haskell at pkturner.org (Scott Turner) Date: Sat Aug 9 08:40:11 2008 Subject: [Haskell-cafe] please help me to find errors from my first app In-Reply-To: <87tzdv8i2u.fsf@gmail.com> References: <87tzdv8i2u.fsf@gmail.com> Message-ID: <200808090840.41191.haskell@pkturner.org> On 2008 August 08 Friday, Changying Li wrote: > I want to write a reverse proxy like perlbal to practive haskell. Now I > just write a very simple script to forward any request to > www.google.com. > > but it dosn't work. I run command ' runhaskell Proxy.hs' and 'wget > http://localhost:8080/'. but wget just wait forever and runhaskkell can > get request. when I break wget, the 'runhaskell' can print response > returned from www.google.com. The problem is with > request <- hGetContents hRequest which blocks until wget closes the connection. Using lazy bytestrings just defers the problem slightly. Your processRequest blocks when the 'request' string is used. For some insight into how this can be avoided, see hGetBufNonBlocking. I'm not familiar enough with the Haskell libraries to point you to the ideal solution. From lemming at henning-thielemann.de Sat Aug 9 13:56:14 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Aug 9 13:56:22 2008 Subject: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell) In-Reply-To: References: <81ea7d400808050159q6d35f2d5hfc3911caff7b13c6@mail.gmail.com> Message-ID: On Thu, 7 Aug 2008, Henk-Jan van Tuyl wrote: > On Tue, 05 Aug 2008 10:59:10 +0200, jinjing wrote: > > > Hi there, > > > > Here's the project link: > > > > http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown > > > > I found Haskore pretty fun :) so I'm documenting it while learning it. > > Please don't hesitate to give suggestions / corrections. > > > > > About the installation section: I think beginners will be grateful if you > write down the full "darcs get" commands and explain the --global > parameter of the "cabal install" command. > > There are two more packages that need to be downloaded: > - package hosc depends on package binary > - package haskore depends on package unix > > Windows users will be grateful if you tell them that Haskore cannot be > built on Windows, because of the dependance on the unix package. It would > have saved me a lot of time if I knew that beforehand. 'unix' is only one of the dependencies, that is there due to Haskore's monolithic nature. I see you have found the offending places yourself. As a first hack you can hide them with Cabal flags and CPP, as you did, but in the long run, there should be small packages that allow the user to install the things that work for him. From jefferson.r.heard at gmail.com Sat Aug 9 14:30:49 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sat Aug 9 14:30:18 2008 Subject: [Haskell-cafe] ANN: Tutorial on information visualization and visual analytics in Haskell Message-ID: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> This is the tutorial I'll be presenting at DEFUN 2008. I'll be building a site around it until then, complete with compilable code examples, but I thought I would let everyone get a sneak peek at the long version of the tutorial before I'm done with it. The code is as yet untested, and keep in mind, advanced Haskellers, that I'm purposefully simplifying some things to be understood by the beginner to the intermediate Haskeller. Comments and questions are welcome and encouraged. Please do ignore typos in the inline code for now, though, as I'll be spending this week testing it out and making sure everything works. The link is: http://bluheron.europa.renci.org/docs/BeautifulCode.pdf -- Jeff From dons at galois.com Sat Aug 9 15:43:42 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 9 15:43:10 2008 Subject: [Haskell-cafe] xmonad on the openmoko mobile phone Message-ID: <20080809194342.GE3902@scytale.galois.com> Haskell fans might be impressed by the good work of Joachim Breitner, who got xmonad running on his openmoko phone, http://www.joachim-breitner.de/blog/archives/300-Xmonad-on-my-mobile-phone.html You can see a photo here, http://galois.com/~dons/images/openmoko-nomeata.jpg Haskell on the iphone next? -- Don From brianchina60221 at gmail.com Sat Aug 9 18:09:06 2008 From: brianchina60221 at gmail.com (brian) Date: Sat Aug 9 18:08:35 2008 Subject: [Haskell-cafe] self-referential data Message-ID: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> >From https://secure.wikimedia.org/wikipedia/en/wiki/Bencoding , I think I should code data BValue = BString String | BInteger Integer | BList [BValue] | BDictionary (M.Map BString BValue) but: Not in scope: type constructor or class `BString' The implementations I've found just implemented BDictionary's map key as String, but I think that's kind of wrong. From byorgey at seas.upenn.edu Sat Aug 9 18:18:04 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Aug 9 18:17:32 2008 Subject: [Haskell-cafe] self-referential data In-Reply-To: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> References: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> Message-ID: <20080809221804.GA14137@minus.seas.upenn.edu> On Sat, Aug 09, 2008 at 05:09:06PM -0500, brian wrote: > >From https://secure.wikimedia.org/wikipedia/en/wiki/Bencoding , I > think I should code > > data BValue = BString String > | BInteger Integer > | BList [BValue] > | BDictionary (M.Map BString BValue) > > but: Not in scope: type constructor or class `BString' > > The implementations I've found just implemented BDictionary's map key > as String, but I think that's kind of wrong. The problem is that BString is not a type, it is a data constructor. You could use M.Map BValue BValue, but of course that's probably not what you want either. What's wrong with just using 'String' as the Map key? -Brent From brianchina60221 at gmail.com Sat Aug 9 19:11:39 2008 From: brianchina60221 at gmail.com (brian) Date: Sat Aug 9 19:11:08 2008 Subject: [Haskell-cafe] self-referential data In-Reply-To: <20080809221804.GA14137@minus.seas.upenn.edu> References: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> <20080809221804.GA14137@minus.seas.upenn.edu> Message-ID: <22f6a8f70808091611q603e5ba4wd05f7d3898c0b0d4@mail.gmail.com> On Sat, Aug 9, 2008 at 5:18 PM, Brent Yorgey wrote: > The problem is that BString is not a type, it is a data constructor. I know. > You could use M.Map BValue BValue, but of course that's probably not > what you want either. Right. That wouldn't be according to spec either. > What's wrong with just using 'String' as the Map key? It seems wrong. Yeah, it's just a String, but we're being all abstract because that's better practice. It happens that when you parse bencoded data, the length of the string is given. Maybe I want to store that in BString, too. But mainly I want to know how to think about it differently so that I know what to do when it comes up again and actually matters. From maciej.podgurski at googlemail.com Sat Aug 9 21:32:21 2008 From: maciej.podgurski at googlemail.com (Maciej Podgurski) Date: Sat Aug 9 21:30:13 2008 Subject: [Haskell-cafe] self-referential data In-Reply-To: <22f6a8f70808091611q603e5ba4wd05f7d3898c0b0d4@mail.gmail.com> References: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> <20080809221804.GA14137@minus.seas.upenn.edu> <22f6a8f70808091611q603e5ba4wd05f7d3898c0b0d4@mail.gmail.com> Message-ID: <489E4525.9020209@googlemail.com> brian wrote: > On Sat, Aug 9, 2008 at 5:18 PM, Brent Yorgey wrote: >> The problem is that BString is not a type, it is a data constructor. > > I know. > >> You could use M.Map BValue BValue, but of course that's probably not >> what you want either. > > Right. That wouldn't be according to spec either. > >> What's wrong with just using 'String' as the Map key? > > It seems wrong. Yeah, it's just a String, but we're being all abstract > because that's better practice. It happens that when you parse > bencoded data, the length of the string is given. Maybe I want to > store that in BString, too. > > But mainly I want to know how to think about it differently so that I > know what to do when it comes up again and actually matters. What about using a type parameter: data BValue bString = BString bString | BInteger Integer | BList [BValue bString] | BDictionary (Map bString (BValue bString)) Regards, Maciej From dagit at codersbase.com Sat Aug 9 23:15:35 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sat Aug 9 23:15:03 2008 Subject: [Haskell-cafe] Future of Darcs: Thanks for the poll responses and increase in contributors Message-ID: Hello, I just wanted to thank everyone that has shown their support for darcs recently by either stopping by #darcs on freenode or joining in discussions on the darcs-user mailing list. I'm cross posting to haskell-cafe because I suspect many of you came from there. There has been a lot of enthusiasm from people, a lot of discussion about patch theory and excitement about fixing bugs and performance issues. Several people have taken an interest in making darcs work flawlessly on the GHC repository (yes, I know they have already commited to switching, but it gives a great test case to improve on). Eric Kow and myself have been working on a roadmap for future darcs improvements, and we plan to annouce an official version soon. The tentative one can be found here: http://wiki.darcs.net/DarcsWiki/Roadmap Mainly I just wanted to say, Thanks! We're considering the feedback we received from the poll and the future of darcs is not uncertain and we'll do a better job of communicating that message in the future. Now, back to hacking on darcs! Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080809/8ff1f9aa/attachment.htm From wren at freegeek.org Sat Aug 9 23:31:52 2008 From: wren at freegeek.org (wren ng thornton) Date: Sat Aug 9 23:31:23 2008 Subject: [Haskell-cafe] self-referential data In-Reply-To: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> References: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> Message-ID: <489E6128.30704@freegeek.org> brian wrote: >>From https://secure.wikimedia.org/wikipedia/en/wiki/Bencoding , I > think I should code > > data BValue = BString String > | BInteger Integer > | BList [BValue] > | BDictionary (M.Map BString BValue) > > but: Not in scope: type constructor or class `BString' > > The implementations I've found just implemented BDictionary's map key > as String, but I think that's kind of wrong. Data Types a la Carte[1] seems like a good fit: > newtype BString e = BString String > newtype BInteger e = BInteger Integer > newtype BList e = BList [Bvalue] > newtype BDictionary e = BDictionary (M.Map (BString e) BValue) > > newtype Y f = Y { unY :: f (Y f) } > data (f :+: g) e = Inl (f e) | Inr (g e) > > type BValue = Y (BString > :+: BInteger > :+: BList > :+: BDictionary > ) ...with the necessary Functor instances. Or, since BString is the only member of the coproduct that needs special treatment, you could squash things a bit more: > newtype BString e = BString String > data BValue_ e = BInteger Integer > | BList [Bvalue] > | BDictionary (M.Map (BString e) BValue) > > type BValue = Y (BString :+: BValue_) The former is more homogeneous and so would probably look prettier in code, but the latter is a bit more efficient since it needs less coproduct tagging and function indirection. Of course, another approach is to just go with your first approach and doubly wrap String. So there's a newtype BString_ = BString_ String, and BValue has a constructor (BString BString_) and the dictionary uses the BString_ data type. [1] With added discussion: http://wadler.blogspot.com/2008/02/data-types-la-carte.html -- Live well, ~wren From bos at serpentine.com Sun Aug 10 00:13:03 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Aug 10 00:12:34 2008 Subject: [Haskell-cafe] ANN: Tutorial on information visualization and visual analytics in Haskell In-Reply-To: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> Message-ID: On Sat, Aug 9, 2008 at 11:30 AM, Jefferson Heard wrote: > I'll be > building a site around it until then, complete with compilable code > examples, but I thought I would let everyone get a sneak peek at the > long version of the tutorial before I'm done with it. That's a beautiful piece of work. I'm looking forward to seeing the talk! From dons at galois.com Sun Aug 10 00:50:04 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 10 00:49:31 2008 Subject: [Haskell-cafe] ANN: Tutorial on information visualization and visual analytics in Haskell In-Reply-To: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> Message-ID: <20080810045004.GA5594@scytale.galois.com> jefferson.r.heard: > This is the tutorial I'll be presenting at DEFUN 2008. I'll be > building a site around it until then, complete with compilable code > examples, but I thought I would let everyone get a sneak peek at the > long version of the tutorial before I'm done with it. The code is as > yet untested, and keep in mind, advanced Haskellers, that I'm > purposefully simplifying some things to be understood by the beginner > to the intermediate Haskeller. Comments and questions are welcome and > encouraged. Please do ignore typos in the inline code for now, > though, as I'll be spending this week testing it out and making sure > everything works. > > The link is: > > http://bluheron.europa.renci.org/docs/BeautifulCode.pdf This is a beautiful piece of work, Jefferson! And maybe a nice time to mention that Jefferson will be presenting, along with some other leading lights in the community, at DEFUN, our first developer-oriented workshop at ICFP. http://www.deinprogramm.de/defun-2008/ So if the ICFP theory-heavy schedule seems a bit dry to you, consider registering for the DEFUN tutorials, and come away having built some beautiful code in Haskell. -- Don From chak at cse.unsw.edu.au Sun Aug 10 04:46:43 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 04:46:14 2008 Subject: [Haskell-cafe] xmonad on the openmoko mobile phone In-Reply-To: <20080809194342.GE3902@scytale.galois.com> References: <20080809194342.GE3902@scytale.galois.com> Message-ID: <394C2C55-0771-49CF-B317-2CE8182C04E2@cse.unsw.edu.au> Don Stewart: > Haskell fans might be impressed by the good work of Joachim Breitner, > who got xmonad running on his openmoko phone, > > http://www.joachim-breitner.de/blog/archives/300-Xmonad-on-my-mobile-phone.html > > You can see a photo here, > > http://galois.com/~dons/images/openmoko-nomeata.jpg Yay! > Haskell on the iphone next? The iPhone SDK includes a version of gcc to generate code for the iPhone. Be cool if anybody try to use that with GHC. Manuel From tittoassini at gmail.com Sun Aug 10 05:19:08 2008 From: tittoassini at gmail.com (Titto Assini) Date: Sun Aug 10 05:18:35 2008 Subject: [Haskell-cafe] Last Reminder: The Italian Haskellers Summer Meeting takes place tomorrow at Monterosso, 5 Terre Message-ID: <2d34474e0808100219g776c6dd8r906528b9b318bcf7@mail.gmail.com> Il titolo dice tutto, maggiori dettagli ad: http://www.haskell.org/haskellwiki/?title=ItaloHaskell/Summer_2008 A domani, titto -- Pasqualino "Titto" Assini, Ph.D. 25 Heath Road - CO79PT Wivenhoe - Colchester - U.K. From miguelimo38 at yandex.ru Sun Aug 10 12:36:27 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sun Aug 10 12:36:10 2008 Subject: [Haskell-cafe] xmonad on the openmoko mobile phone In-Reply-To: <20080809194342.GE3902@scytale.galois.com> References: <20080809194342.GE3902@scytale.galois.com> Message-ID: On 9 Aug 2008, at 23:43, Don Stewart wrote: > Haskell on the iphone next? Did that. Hugs compiles well; GHC will probably too, I just didn't have time for this. No haskell-specific hacks, only jailbreak. From jefferson.r.heard at gmail.com Sun Aug 10 13:46:50 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sun Aug 10 13:46:22 2008 Subject: [Haskell-cafe] Re: ANN: Tutorial on information visualization and visual analytics in Haskell In-Reply-To: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> Message-ID: <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> As is always the case with anything you release to the public, I've discovered inconsistencies and typos in the text since I released it. I've tried to clean up all the typos I could find. Still working on the code, but there's a new edition out there on the website. On Sat, Aug 9, 2008 at 2:30 PM, Jefferson Heard wrote: > This is the tutorial I'll be presenting at DEFUN 2008. I'll be > building a site around it until then, complete with compilable code > examples, but I thought I would let everyone get a sneak peek at the > long version of the tutorial before I'm done with it. The code is as > yet untested, and keep in mind, advanced Haskellers, that I'm > purposefully simplifying some things to be understood by the beginner > to the intermediate Haskeller. Comments and questions are welcome and > encouraged. Please do ignore typos in the inline code for now, > though, as I'll be spending this week testing it out and making sure > everything works. > > The link is: > > http://bluheron.europa.renci.org/docs/BeautifulCode.pdf > > -- Jeff > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From warren at live.com Sun Aug 10 14:29:46 2008 From: warren at live.com (Warren Aldred) Date: Sun Aug 10 14:29:00 2008 Subject: [Haskell-cafe] Recommended Haskell Books In-Reply-To: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> Message-ID: Hi all, I'm new to Haskell and looking for recommendations on introductory Haskell books. Online or offline. Any suggestions? Thanks kindly, Warren From jgbailey at gmail.com Sun Aug 10 14:34:25 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Sun Aug 10 14:33:52 2008 Subject: [Haskell-cafe] ANN: Tutorial on information visualization and visual analytics in Haskell In-Reply-To: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> Message-ID: On Sat, Aug 9, 2008 at 11:30 AM, Jefferson Heard wrote: > The link is: > > http://bluheron.europa.renci.org/docs/BeautifulCode.pdf Very readable and interesting. You may want to add some pictures or graphs if you weren't planning on that already. I really like how you have comments next to the haskell code. Is that a literate file? Are you using some well-known tool to weave the comments into the code? It looks like presentations I've seen with CWEB but I don't know of a tool like that for Haskell code ... Justin From philipn at gmail.com Sun Aug 10 14:49:31 2008 From: philipn at gmail.com (Philip Neustrom) Date: Sun Aug 10 14:48:57 2008 Subject: [Haskell-cafe] Recommended Haskell Books In-Reply-To: References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> Message-ID: Yup! You should check out this page on the Haskell wiki: http://haskell.org/haskellwiki/Books_and_tutorials It has links to lists of commonly recommended books and tutorials. Personally, I like "Yet Another Haskell Tutorial" alongside "The Haskell School of Expression" (book). Best, Philip Neustrom On Sun, Aug 10, 2008 at 11:29 AM, Warren Aldred wrote: > Hi all, > > I'm new to Haskell and looking for recommendations on introductory Haskell > books. Online or offline. Any suggestions? > > Thanks kindly, > Warren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mfeathers at mindspring.com Sun Aug 10 14:47:20 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Sun Aug 10 14:53:02 2008 Subject: [Haskell-cafe] Thinking about an unlistN Message-ID: <489F37B8.4040708@mindspring.com> I wrote this function the other day, and I was wondering if I'm missing something.. whether there is already a function or idiom around to do this. unlist3 :: (a -> a -> a -> b) -> [a] -> b unlist3 f (x:y:z:xs) = f x y z I was also wondering whether the function can be generalized to N or whether this is just one of those edges in the type system that you can't abstract over. Thanks, Michael From philipn at gmail.com Sun Aug 10 14:58:32 2008 From: philipn at gmail.com (Philip Neustrom) Date: Sun Aug 10 14:57:58 2008 Subject: [Haskell-cafe] Thinking about an unlistN In-Reply-To: <489F37B8.4040708@mindspring.com> References: <489F37B8.4040708@mindspring.com> Message-ID: I'm no expert, but it looks like the generalization of that would be some f that took a list: f :: [a] -> b so what you'd have is a fold, right? foldr1 :: (a -> a -> a) -> [a] -> a Best, Philip Neustrom On Sun, Aug 10, 2008 at 11:47 AM, Michael Feathers wrote: > > I wrote this function the other day, and I was wondering if I'm missing > something.. whether there is already a function or idiom around to do this. > > > unlist3 :: (a -> a -> a -> b) -> [a] -> b > unlist3 f (x:y:z:xs) = f x y z > > > I was also wondering whether the function can be generalized to N or whether > this is just one of those edges in the type system that you can't abstract > over. > > > Thanks, > > Michael > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mfeathers at mindspring.com Sun Aug 10 14:57:25 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Sun Aug 10 15:03:09 2008 Subject: [Haskell-cafe] Thinking about an unlistN In-Reply-To: References: <489F37B8.4040708@mindspring.com> Message-ID: <489F3A15.3020702@mindspring.com> Philip, Thanks. It's not quite that, though. It's more like an adapter for a function with a specific arity. If I have, say, a function f :: a -> a -> a -> a -> b it would be nice to be able to just: unlistN 4 f [1..4] Michael (does look like there's no way to make that fly with the type system however) Philip Neustrom wrote: > I'm no expert, but it looks like the generalization of that would be > some f that took a list: > > f :: [a] -> b > > so what you'd have is a fold, right? > > foldr1 :: (a -> a -> a) -> [a] -> a > > Best, > Philip Neustrom > > On Sun, Aug 10, 2008 at 11:47 AM, Michael Feathers > wrote: >> I wrote this function the other day, and I was wondering if I'm missing >> something.. whether there is already a function or idiom around to do this. >> >> >> unlist3 :: (a -> a -> a -> b) -> [a] -> b >> unlist3 f (x:y:z:xs) = f x y z >> >> >> I was also wondering whether the function can be generalized to N or whether >> this is just one of those edges in the type system that you can't abstract >> over. >> >> >> Thanks, >> >> Michael >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -- Now Playing: Clammbon - 246 http://youtube.com/watch?v=PO77bN8W1mA From mik at konecny.aow.cz Sun Aug 10 15:53:01 2008 From: mik at konecny.aow.cz (Michal Konecny) Date: Sun Aug 10 15:52:57 2008 Subject: [Haskell-cafe] Re: ANN: interval and polynomial enclosure arithmetics Message-ID: <200808102053.27750.mik@konecny.aow.cz> Roman Cheplyaka ro-che.info> writes: > * Michal Konecny konecny.aow.cz> [2008-08-08 13:38:56+0100] > > and members of the KEG research group at Aston > > University have used it for reliably solving differential equations > > and numerical constraint satisfaction problems. > > This's very interesting. Do you have any published papers (or other > sources of information) about it? Unfortunately, there isn't much yet but more is on the way. Only the following two papers are available at the moment: http://www-users.aston.ac.uk/~konecnym/papers/cfv08.html is about using our polynomial enclosures to prove NCSPs that arise from floating-point software verification problems. http://www-users.aston.ac.uk/~konecnym/papers/wollic08.html analyses the convergence rate of an ODE solver that uses piecewise constant enclosures (which is rather inefficient). Best regards, Michal -- |o| Michal Konecny |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aow -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080810/f9817e53/attachment.bin From thomas.dubuisson at gmail.com Sun Aug 10 16:04:47 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sun Aug 10 16:04:10 2008 Subject: [Haskell-cafe] Recommended Haskell Books In-Reply-To: References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> Message-ID: <1218398687.27088.3.camel@tom-laptop> I know someone else is going to say it, so I may as well beat them to the punch: Real World Haskell isn't released yet, but beta chapters are available online at book.realworldhaskell.org/beta As for me, I learned though the Yet Another Haskell tutorial, Haskell School of Expression (book), Haskell: The Craft of Functional Programming (book), and plenty of playing around. Tom On Sun, 2008-08-10 at 11:29 -0700, Warren Aldred wrote: > Hi all, > > I'm new to Haskell and looking for recommendations on introductory Haskell > books. Online or offline. Any suggestions? > > Thanks kindly, > Warren > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From anton at appsolutions.com Sun Aug 10 16:42:04 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Sun Aug 10 16:35:59 2008 Subject: [Haskell-cafe] Thinking about an unlistN In-Reply-To: <489F37B8.4040708@mindspring.com> References: <489F37B8.4040708@mindspring.com> Message-ID: <489F529C.6030301@appsolutions.com> Michael Feathers wrote: > > I wrote this function the other day, and I was wondering if I'm missing > something.. whether there is already a function or idiom around to do this. > > > unlist3 :: (a -> a -> a -> b) -> [a] -> b > unlist3 f (x:y:z:xs) = f x y z > > > I was also wondering whether the function can be generalized to N or > whether this is just one of those edges in the type system that you > can't abstract over. In Scheme and Lisp, the "apply" function does this, so the following Scheme definition would do the trick: (define unlist apply) (Although this doesn't ignore the xs as in the example; that would require some code to extract a sublist of the desired length.) In Haskell, bring on the type system shenanigans! ;) Anton From benja.fallenstein at gmail.com Sun Aug 10 17:24:07 2008 From: benja.fallenstein at gmail.com (Benja Fallenstein) Date: Sun Aug 10 17:23:33 2008 Subject: [Haskell-cafe] Thinking about an unlistN In-Reply-To: <489F3A15.3020702@mindspring.com> References: <489F37B8.4040708@mindspring.com> <489F3A15.3020702@mindspring.com> Message-ID: Hi, On Sun, Aug 10, 2008 at 8:57 PM, Michael Feathers wrote: > If I have, say, a function f :: a -> a -> a -> a -> b it would be nice to be > able to just: > > unlistN 4 f [1..4] It indeed doesn't work like this; there's more than one way to do something *like* this, if you really want to. The closest one is probably to use type-level numbers: {-# OPTIONS_GHC -fglasgow-exts #-} data Zero data Suc a zero :: Zero; zero = undefined; suc :: a -> Suc a; suc = undefined one = suc zero; two = suc one; three = suc two; four = suc three class Unlist n a b where type UnlistFn n a b unlist :: n -> UnlistFn n a b -> [a] -> b instance Unlist Zero a b where type UnlistFn Zero a b = b unlist _ r _ = r instance Unlist n a b => Unlist (Suc n) a b where type UnlistFn (Suc n) a b = a -> UnlistFn n a b unlist _ f (x:xs) = unlist (undefined :: n) (f x) xs main = print (unlist four (,,,) "abcd") This prints ('a','b','c','d'). Hope this is fun[*], - Benja [*] I hesistate to say "hope this helps" in this case :-) From ben.franksen at online.de Sun Aug 10 17:33:31 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 10 17:33:13 2008 Subject: [Haskell-cafe] Re: Re[2]: heap lifetime question References: <5ae4f2ba0808062213x2e40b185nde7efaf9e75f2694@mail.gmail.com> <368402629.20080807092557@gmail.com> <5ae4f2ba0808062230v63f7284djbd181026d3c1fc3c@mail.gmail.com> <5ae4f2ba0808062233q21c0e864k49ed4871754acadb@mail.gmail.com> <155136561.20080807095834@gmail.com> <5ae4f2ba0808062338q2141e5cyf5b356d992a894d1@mail.gmail.com> Message-ID: Galchin, Vasili wrote: > that is what I thought .. especially after just looking at the > implementation for alloca/allocaBytes. For me and others on thie group is > there documentation on the ghc run-time model and also the run-time > library architecture. Both would help/aid in reading the code and of > course educate more people? I'd rather use the FFI Addendum (http://www.cse.unsw.edu.au/~chak/haskell/ffi/) as reference than the ghc implementation. Section 5.8 "MarshalAlloc" says alloca :: Storable a => (Ptr a -> IO b) -> IO b Allocate a block of memory of the same size as malloc, but the reference is passed to a computation instead of being returned. When the computation terminates, free the memory area again. The operation is exception-safe; i.e., allocated memory is freed if an exception is thrown in the marshalling computation. allocaBytes :: Int -> (Ptr a -> IO b) -> IO b As alloca, but allocate a memory area of the given size. The same alignment constraint as for mallocBytes holds. Cheers Ben From jefferson.r.heard at gmail.com Sun Aug 10 17:56:31 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sun Aug 10 17:55:58 2008 Subject: [Haskell-cafe] ANN: Tutorial on information visualization and visual analytics in Haskell In-Reply-To: References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> Message-ID: <4165d3a70808101456j336ff3b8j2cb23e7575dc0c61@mail.gmail.com> The final version will have graphics from the code that I present, yes, as well as from other projects I've done in Haskell in information visualization. As for the comments next to the Haskell Code, no -- there was no special tool involved. Sadly, I wrote the entire document in Word 2007, as it was the best tool I had at hand. After coming up with a template, I had basically everything I needed, and it was going to be less work than tweaking LaTeX to do exactly what I wanted to do with the code. On Sun, Aug 10, 2008 at 2:34 PM, Justin Bailey wrote: > On Sat, Aug 9, 2008 at 11:30 AM, Jefferson Heard > wrote: >> The link is: >> >> http://bluheron.europa.renci.org/docs/BeautifulCode.pdf > > Very readable and interesting. You may want to add some pictures or > graphs if you weren't planning on that already. > > I really like how you have comments next to the haskell code. Is that > a literate file? Are you using some well-known tool to weave the > comments into the code? It looks like presentations I've seen with > CWEB but I don't know of a tool like that for Haskell code ... > > Justin > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards Ye From robgreayer at yahoo.com Sun Aug 10 22:34:34 2008 From: robgreayer at yahoo.com (Robert Greayer) Date: Sun Aug 10 22:34:00 2008 Subject: [Haskell-cafe] Thinking about an unlistN In-Reply-To: <489F37B8.4040708@mindspring.com> Message-ID: <47144.55012.qm@web65716.mail.ac4.yahoo.com> --- On Sun, 8/10/08, Michael Feathers wrote: > I wrote this function the other day, and I was wondering if > I'm missing > something.. whether there is already a function or idiom > around to do this. > > > unlist3 :: (a -> a -> a -> b) -> [a] -> b > unlist3 f (x:y:z:xs) = f x y z > > > I was also wondering whether the function can be > generalized to N or > whether this is just one of those edges in the type system > that you > can't abstract over. > Well, there's always haskell's Swiss Army Knife, TH: > module Unlist(unlistN) where > > import Language.Haskell.TH > > unlistN n = do > f <- newName "f" > xs <- sequence (replicate n (newName "x")) > lamE [varP f,(foldr ((flip infixP) '(:)) (wildP) (map varP xs))] > (foldl appE (varE f) (map varE xs)) > {-# OPTIONS_GHC -XTemplateHaskell #-} > module UseUnlist where > > import Unlist > > f i0 i1 i2 i3 = i0 + i1 + i2 + i3 > > x = $(unlistN 4) f [1,2,3,4,5,6,7] rcg From lchangying at gmail.com Sun Aug 10 23:09:59 2008 From: lchangying at gmail.com (Changying Li) Date: Sun Aug 10 23:09:40 2008 Subject: [Haskell-cafe] Re: please help me to find errors from my first app References: <87tzdv8i2u.fsf@gmail.com> <200808090840.41191.haskell@pkturner.org> Message-ID: <878wv4s0vs.fsf@gmail.com> thanks. I know how to do it. I should treat it as a stream. -- Thanks & Regards Changying Li From DekuDekuplex at Yahoo.com Mon Aug 11 00:12:31 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Mon Aug 11 00:12:07 2008 Subject: [Haskell-cafe] Re: Recommended Haskell Books References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> Message-ID: <5aev949m3invh4v6jrlgkqralpp923afjt@4ax.com> On Sun, 10 Aug 2008 11:29:46 -0700, "Warren Aldred" wrote: >Hi all, > >I'm new to Haskell and looking for recommendations on introductory Haskell >books. Online or offline. Any suggestions? Another suggestion is _The Haskell Road to Logic, Maths, and Programming,_ by Kees Doets and Jan van Eijck (see http://fldit-www.cs.uni-dortmund.de/~peter/PS07/HR.pdf). This book assumes very little mathematical background, is written in a "literate programming" style, and is very easy to follow. In general, I would recommend focusing on the books, and not too much on most of the tutorials. Some other readers have said that many Haskell tutorials try to cover too many topics in too short a tutorial, and wind up not discussing the material adequately. Haskell has a very sharp learning curve, and it is essential to cover the basics adequately before diving into deeper material. I would recommend taking the time to digest the material fully without rushing. -- Benjamin L. Russell From lrpalmer at gmail.com Mon Aug 11 02:38:48 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Aug 11 02:38:13 2008 Subject: [Haskell-cafe] Re: Recommended Haskell Books In-Reply-To: <5aev949m3invh4v6jrlgkqralpp923afjt@4ax.com> References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> <5aev949m3invh4v6jrlgkqralpp923afjt@4ax.com> Message-ID: <7ca3f0160808102338r73f6006q71d2df90dc82bdbc@mail.gmail.com> On Mon, Aug 11, 2008 at 4:12 AM, Benjamin L. Russell wrote: > On Sun, 10 Aug 2008 11:29:46 -0700, "Warren Aldred" > wrote: > > >Hi all, > > > >I'm new to Haskell and looking for recommendations on introductory Haskell > >books. Online or offline. Any suggestions? > > Another suggestion is _The Haskell Road to Logic, Maths, and > Programming,_ by Kees Doets and Jan van Eijck (see > http://fldit-www.cs.uni-dortmund.de/~peter/PS07/HR.pdf). > This book > assumes very little mathematical background, is written in a "literate > programming" style, and is very easy to follow. > > In general, I would recommend focusing on the books, and not too much > on most of the tutorials. Some other readers have said that many > Haskell tutorials try to cover too many topics in too short a > tutorial, and wind up not discussing the material adequately. Haskell > has a very sharp learning curve, and it is essential to cover the > basics adequately before diving into deeper material. Depending, of course, on your learning style. I was never very good at the "dependency-driven" learning style; I have found it easier for me to learn what I'm interested in. If I don't have the background to understand it yet, then I'll half-understand it. And gradually everything starts coming together. To each his own, YMMV, et cetera. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080811/2a853605/attachment.htm From jason.dusek at gmail.com Mon Aug 11 04:04:10 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Aug 11 04:03:35 2008 Subject: [Haskell-cafe] best strategy for comparing comparisons Message-ID: <42784f260808110104w63c4e0e5s2f2e673aaae2f381@mail.gmail.com> I'd like to perform a micro-benchmark, pitting ByteString comparision against Word comparison. What I'd like to do is: . Generate a bunch of random Word32s. . Generate strict ByteStrings containing those Word32s. . Compare every Word32 with every other Word32 for equality, and see how long it takes. . Ditto with ByteStrings. The first two are easy and I'm done with them already. The latter two seem like they'll run afoul of laziness. I have two ideas about how to do them: . Do every comparison with a list comprehension, compressing the result as I go using `all`. . Do every comparison in a recursive IO procedure. Are there other ways? Will strictness annotations, for example, allow me to run comparisons on larger lists? -- _jsn From vigalchin at gmail.com Mon Aug 11 05:09:27 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Aug 11 05:08:50 2008 Subject: [Haskell-cafe] I want to upgrade to ghc 6.8.3 Message-ID: <5ae4f2ba0808110209w3787cfbdn875212d5fff972b1@mail.gmail.com> Hello, I am building 6.8.3 from my "local" 6.8.2. However, I am getting errors in compiling one of the Main.hs. E.g. Main.hs:76:23: Ambiguous occurrence `flags' It could refer to either `Main.flags', defined at Main.hs:118:0 or `System.Posix.flags', imported from System.Posix at Main.hs:59:0-18 ...... I did a "find . -name Main.hs" and there are several Main.hs. I am not sure which one is causing trouble or why. ?? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080811/420db679/attachment.htm From tom.davie at gmail.com Mon Aug 11 06:52:08 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Mon Aug 11 06:51:34 2008 Subject: [Haskell-cafe] Lambdabot Message-ID: <8D64CBBE-5797-443B-9085-AAE31FAD53F3@gmail.com> I've been trying to lambdabot running properly recently, and have consistently hit an error "fd:6: hClose: resource vanished (Broken pipe)" whenever I try to run anything that involves executing haskell (including but not limited to evaluating arbitrary expressions, the brainfuck module, unlambda). A quick google revealed that it's a very common error, but not potential solutions. Any ideas on what's up would be very useful. Bob From matthew at wellquite.org Mon Aug 11 11:23:19 2008 From: matthew at wellquite.org (Matthew Sackman) Date: Mon Aug 11 11:22:50 2008 Subject: [Haskell-cafe] Anglo Haskell 2008 - slides, audio and incriminating photos In-Reply-To: <20080807160024.GX17334@arkansas.doc.ic.ac.uk> References: <20080701121531.GB1808@arkansas.doc.ic.ac.uk> <20080707153853.GB6240@wellquite.org> <20080729142754.GF5180@koba.home.wellquite.org> <20080807160024.GX17334@arkansas.doc.ic.ac.uk> Message-ID: <20080811152319.GZ17334@arkansas.doc.ic.ac.uk> (actually, we didn't take any photos!) So, Anglo Haskell 2008 has been and gone. Many fair souls braved both the weather and the London transport system and were entertained for two days at Imperial College, London. Slides and audio are now available from: http://www.wellquite.org/anglohaskell2008/ Your challenge, if you choose to accept it, is to work out when the speakers change which slide is on the screen. Bonus points will be awarded to anyone who also identifies when to turn *back* to a previous slide! Cheers, Matthew From usenet at mkarcher.dialup.fu-berlin.de Mon Aug 11 12:02:08 2008 From: usenet at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Mon Aug 11 12:01:40 2008 Subject: [Haskell-cafe] Re: self-referential data References: <22f6a8f70808091509of726485h37d5d02a05d400b3@mail.gmail.com> <20080809221804.GA14137@minus.seas.upenn.edu> <22f6a8f70808091611q603e5ba4wd05f7d3898c0b0d4@mail.gmail.com> Message-ID: brian wrote: > > What's wrong with just using 'String' as the Map key? > It seems wrong. Yeah, it's just a String, but we're being all abstract > because that's better practice. It happens that when you parse > bencoded data, the length of the string is given. Maybe I want to > store that in BString, too. So, why not just type BString_ = String data BValue = BString BString_ | BDictionary (Map BString_ BValue) you always can change BString_ to obtain a different representation for a) String values in you BValues and b) keys in your BDictionary at the same time. The "BString" data constructor means "This BValue is something called BString, oh, and, by the way, there is a string stored here". It does not mean at all that "BString" somehow represents the String type. So it really makes no sense as parameter to the Map. Just imagine, what would happen, if the BString constructor has more than one parameter. What should be the key for the map in that case? If you want to add a layer of abstraction, use a newtype instead of the type alias. But that means, standard string functions don't work on BString_ anymore. On the other hand, you are right that there is no really simple sum type notation in haskell, like "a BValue(type) is either a BString(type), a BInteger(type) or a BDictionary(type)", but you have to say the more verbose variant: "a BValue(type) is constructed in on of the following ways: a mark called BString(data constructor) accompanied by a String; a mark called BInteger(data constructor) accompanied by an Integer or a mark called BDictionary(data constructor) accompanied by a Map." These marks are surely no types. Your intuition seems more like what the other poster also suggests: data BString = BString String data BInteger = BInteger Integer data BDictionary = BDictionary (Map BString BValue) data BValue = BVString BString | BVInteger BInteger | BVDictionary BDictionary There just is no way around the data constructors (called BV...), even if they seem kind-of redundant. You might want to use newtype instead of data in the first three definitions to reduce runtime overhead, or even use type aliases for added convenience in trade for abstraction. Regards, Michael Karcher From usenet at mkarcher.dialup.fu-berlin.de Mon Aug 11 12:13:12 2008 From: usenet at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Mon Aug 11 12:12:42 2008 Subject: [Haskell-cafe] Re: best strategy for comparing comparisons References: <42784f260808110104w63c4e0e5s2f2e673aaae2f381@mail.gmail.com> Message-ID: Jason Dusek wrote: [These are point 3 and 4] > . Compare every Word32 with every other Word32 for equality, > and see how long it takes. > . Ditto with ByteStrings. > > The first two are easy and I'm done with them already. The > latter two seem like they'll run afoul of laziness. I have two > ideas about how to do them: > > . Do every comparison with a list comprehension, compressing > the result as I go using `all`. all is not a good idea: It stops as soon as it sees one false. Better count the number of equals. let count = length $ filter id [a==b,a <- bytestrings, b <- bytestrings] > . Do every comparison in a recursive IO procedure. Should work too. But you have to take care that implicit I/O thingies don't spoil one version of your timing tests. > Are there other ways? Will strictness annotations, for > example, allow me to run comparisons on larger lists? Strictness annotation might help, but I don't think they are the correct tool to use here. The counting test I proposed above should run in O(1) stack and heap, as well as O(n^2) time, which is the best you can expect (of course, the list of bytestrings is O(n) on the heap). Regards, Michael Karcher From jgbailey at gmail.com Mon Aug 11 15:06:40 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Mon Aug 11 15:06:04 2008 Subject: [Haskell-cafe] Thinking about an unlistN In-Reply-To: <489F37B8.4040708@mindspring.com> References: <489F37B8.4040708@mindspring.com> Message-ID: On Sun, Aug 10, 2008 at 11:47 AM, Michael Feathers wrote: > > unlist3 :: (a -> a -> a -> b) -> [a] -> b > unlist3 f (x:y:z:xs) = f x y z > Oleg has written about this. Be careful, its easy to overdose on: "Functions with the variable number of (variously typed) arguments" http://okmij.org/ftp/Haskell/types.html#polyvar-fn > > I was also wondering whether the function can be generalized to N or whether > this is just one of those edges in the type system that you can't abstract > over. With template haskell I don't think that exists. Justin From cmb21 at kent.ac.uk Mon Aug 11 17:03:09 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Mon Aug 11 17:02:33 2008 Subject: [Haskell-cafe] Cyclic Inclusions Message-ID: Hi, I have a question about cyclic inclusions. It appears in the Haskell 98 report that mutually recursive modules are allowed, however GHC complains at any Haskell project that has cyclic inclusions (implicit or explicit). Am I right in thinking that this is a GHC limitation? http://www.haskell.org/onlinereport/modules.html Kind regards, Chris. From dons at galois.com Mon Aug 11 17:07:00 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 11 17:06:26 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: Message-ID: <20080811210700.GF18593@scytale.galois.com> cmb21: > Hi, > > I have a question about cyclic inclusions. It appears in the Haskell 98 > report that mutually recursive modules are allowed, however GHC complains > at any Haskell project that has cyclic inclusions (implicit or explicit). > Am I right in thinking that this is a GHC limitation? > > > http://www.haskell.org/onlinereport/modules.html > > GHC provides a mechanism to support mutually recursive modules, but you must break the cycle manually, via a boot file. http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion From cmb21 at kent.ac.uk Mon Aug 11 18:02:52 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Mon Aug 11 18:02:15 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080811210700.GF18593@scytale.galois.com> References: <20080811210700.GF18593@scytale.galois.com> Message-ID: Hi Don, > > GHC provides a mechanism to support mutually recursive modules, but > you must break the cycle manually, via a boot file. > > http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion > Yes, I saw that, thanks! I guess this is because it's hard to compile a mutually recursive module... Chris. From clawsie at fastmail.fm Mon Aug 11 19:44:53 2008 From: clawsie at fastmail.fm (brad clawsie) Date: Mon Aug 11 19:46:41 2008 Subject: [Haskell-cafe] searchmonkey for haskell apis Message-ID: <87wsinf762.fsf@jobbicycle.corp.yahoo.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i've been looking into the possibility of creating some xslt to expose haskell apis to yahoo search via searchmonkey. if you see the java api search plugin, you can see some possibilities. i was wondering if anyone maintaining any the official api docs had considered looking at searchmonkey. from a site owner's perspective, some rdf metadata can be inlined with the api docs which yahoo will automatically crawl to build up a search corpus, which could then be rendered into a display using the searchmonkey tools. this approach would be superior to the xslt approach i suggest above, since it exposes industry standard metadata that any search engine can use. the xslt approach is an option yahoo offers to let third-parties "scrape" sites they want put in ysearch. since two parties approaches might conflict, i thought i would send out a note. thanks. brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkigzvsACgkQxRg3RkRK91MwiACeJ66+jYgPfKvoYCDNYsUulnTo 308An3NrwfkGAgfWJud4MaggHf0Zh9vw =n/9o -----END PGP SIGNATURE----- From patperry at stanford.edu Mon Aug 11 19:53:57 2008 From: patperry at stanford.edu (Patrick Perry) Date: Mon Aug 11 19:53:29 2008 Subject: [Haskell-cafe] ANN: BLAS bindings for haskell, version 0.5 Message-ID: <5FAAC27D-7562-4FF7-ABBE-B61245B8A1A6@stanford.edu> Hey everyone, I've put together a new release of the Haskell BLAS bindings, now available on hackage. Here are the new features: * Add Banded matrix data type, as well as Tri Banded and Herm Banded. * Add support for trapezoidal dense matrices (Tri Matrix (m,n) e, where m is not the same as n). Note that trapezoidal banded matrices are *NOT* supported. * Add Diag matrix data type for diagonal matrices. * Add Perm matrix data type, for permutation matrices. * Enhance the RMatrix and RSolve type classes with an API that allows specifying where to store the result of a computation. * Enhance the IMatrix, RMatrix, ISolve, and RSolve type classes to add "scale and multiply" operations. * Remove the scale parameter for Tri and Herm matrix data types. * Flatten the data types for DVector and DMatrix. * Some inlining and unpacking performance improvements. As far as what to expect in version 0.6, I plan to add support for operations in the ST monad. This is going to require a pretty big code reorganization and will cause quite a few API breakages, but I think it's worth the pain. The next release will also come with a tutorial and examples. After the big code reorganization, I'll get started on LAPACK bindings. Please let me know if you are using the library. I'm really interested in what people like and don't like. If you think that some functionality is missing, let me know. If you think the API is awkward in certain places, let me know that, too. Patrick Cross-posted to: http://quantile95.com/2008/08/11/ann-blas-bindings-for-haskell-version-05/ From dons at galois.com Mon Aug 11 19:55:31 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 11 19:54:52 2008 Subject: [Haskell-cafe] ANN: BLAS bindings for haskell, version 0.5 In-Reply-To: <5FAAC27D-7562-4FF7-ABBE-B61245B8A1A6@stanford.edu> References: <5FAAC27D-7562-4FF7-ABBE-B61245B8A1A6@stanford.edu> Message-ID: <20080811235531.GB19946@scytale.galois.com> patperry: > Hey everyone, > > I've put together a new release of the Haskell BLAS bindings, now > available on hackage. > Arch Linux package available, http://aur.archlinux.org/packages.php?ID=18098 Cheers, Don From ajb at spamcop.net Mon Aug 11 20:53:44 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Mon Aug 11 20:53:05 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: <20080811210700.GF18593@scytale.galois.com> Message-ID: <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> G'day all. Quoting "C.M.Brown" : > Yes, I saw that, thanks! I guess this is because it's hard to compile a > mutually recursive module... It's because you don't need to declare the types of exported definitions. Consider, this highly artificial example: module A where import B f (x,y) = g (x,'A') module B where import A g (x,y) = f (True,y) To infer the types of f and g, you need to analyse both modules together. And yes, some people think that this is a bug in the specification. Cheers, Andrew Bromage From onlyforjob at 163.com Mon Aug 11 21:09:39 2008 From: onlyforjob at 163.com (shoulders) Date: Mon Aug 11 21:08:59 2008 Subject: [Haskell-cafe] my first post In-Reply-To: References: Message-ID: <000701c8fc18$18a6d320$8653a8c0@synnex.org> Thanks -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA8=D4=C211=C8=D5 18:33 =CA=D5=BC=FE=C8=CB: onlyforjob@163.com =D6=F7=CC=E2: The results of your email commands The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts You can access your personal options via the following url: = http://www.haskell.org/mailman/options/haskell-cafe/onlyforjob%40163.com =20 help Help for Haskell-Cafe mailing list: This is email command help for version 2.1.5 of the "Mailman" list manager. The following describes commands you can send to get information about and control your subscription to Mailman lists at this site. A command can be in the subject line or in the body of the message. Note that much of the following can also be accomplished via the World Wide Web, at: http://www.haskell.org/mailman/listinfo/haskell-cafe In particular, you can use the Web site to have your password sent to your delivery address. List specific commands (subscribe, who, etc) should be sent to the *-request address for the particular list, e.g. for the 'mailman' list, use 'mailman-request@...'. About the descriptions - words in "<>"s signify REQUIRED items and words in "[]" denote OPTIONAL items. Do not include the "<>"s or "[]"s when you use the commands. The following commands are valid: =20 confirm Confirm an action. The confirmation-string is required and = should be supplied by a mailback confirmation notice. end Stop processing commands. Use this if your mail program automatically adds a signature file. help Print this help message. info Get information about this mailing list. lists See a list of the public mailing lists on this GNU Mailman = server. password [ ] [address=3D
] Retrieve or change your password. With no arguments, this = returns your current password. With arguments and you can change your password. If you're posting from an address other than your membership address, specify your membership address with `address=3D
' (no brackets around the email address, and no quotes!). Note that in this = case the response is always sent to the subscribed address. set ... Set or view your membership options. Use `set help' (without the quotes) to get a more detailed list = of the options you can change. Use `set show' (without the quotes) to view your current option settings. subscribe [password] [digest|nodigest] [address=3D
] Subscribe to this mailing list. Your password must be given to unsubscribe or change your options, but if you omit the = password, one will be generated for you. You may be periodically reminded of = your password. The next argument may be either: `nodigest' or `digest' (no quotes!). If you wish to subscribe an address other than the address you = sent this request from, you may specify `address=3D
' (no = brackets around the email address, and no quotes!) unsubscribe [password] [address=3D
] Unsubscribe from the mailing list. If given, your password must match your current password. If omitted, a confirmation email will be sent to the unsubscribing address. If you wish to unsubscribe an = address other than the address you sent this request from, you may = specify `address=3D
' (no brackets around the email address, and = no quotes!) who password See everyone who is on this mailing list. The roster is limited = to list administrators and moderators only; you must supply the = list admin or moderator password to retrieve the roster. Commands should be sent to haskell-cafe-request@haskell.org Questions and concerns for the attention of a person should be sent to haskell-cafe-owner@haskell.org - Done. From brianchina60221 at gmail.com Tue Aug 12 00:38:08 2008 From: brianchina60221 at gmail.com (brian) Date: Tue Aug 12 00:37:30 2008 Subject: [Haskell-cafe] Recommended Haskell Books In-Reply-To: References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <4165d3a70808101046k2e1d94b0hd7cd361fb0bb26c0@mail.gmail.com> Message-ID: <22f6a8f70808112138g45e124e5s8c501a39bc27c32c@mail.gmail.com> On Sun, Aug 10, 2008 at 1:29 PM, Warren Aldred wrote: > I'm new to Haskell and looking for recommendations on introductory Haskell > books. Online or offline. Any suggestions? I like _Programming in Haskell_ (Hutton) _The Haskell School of Expression_ (Hudak) _Real World Haskell_ (Goerzen, O'Sullivan, Stewart) I'd advise against _The Haskell Road to Logic, Maths, and Programming_ until much later unless you're strongly mathematically inclined. From haskell at kudling.de Tue Aug 12 04:50:07 2008 From: haskell at kudling.de (haskell@kudling.de) Date: Tue Aug 12 04:49:29 2008 Subject: [Haskell-cafe] Recommended Haskell Books Message-ID: <20869877.34401218531007370.JavaMail.servlet@kundenserver> Also the Beta Version of "Real World Haskell" looks promising: http://book.realworldhaskell.org/beta/index.html >On Sun, Aug 10, 2008 at 1:29 PM, Warren Aldred wrote: >> I'm new to Haskell and looking for recommendations on introductory Haskell >> books. Online or offline. Any suggestions? > >I like >_Programming in Haskell_ (Hutton) >_The Haskell School of Expression_ (Hudak) >_Real World Haskell_ (Goerzen, O'Sullivan, Stewart) > >I'd advise against _The Haskell Road to Logic, Maths, and Programming_ >until much later unless you're strongly mathematically inclined. From conor at strictlypositive.org Tue Aug 12 05:11:49 2008 From: conor at strictlypositive.org (Conor McBride) Date: Tue Aug 12 05:11:11 2008 Subject: [Haskell-cafe] GLfloat on a Mac Message-ID: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> Hi folks I thought I'd try a bit of OpenGL. Perhaps I should send this to the more specific list, but perhaps other people are, like me, trying out a variety of UI technology. I thought I'd give OpenGL a go, because I saw the name whizz by when I upgraded to 6.8.3. I found the tutorial and got copy-paste cracking. It was all going swimmingly while I did almost nothing, but then ghc started dying on me. I chopped down my failing code to this joyous specimen: HelloWorld.lhs contains ---------------------------------- > module Main where > import Graphics.Rendering.OpenGL > import Graphics.UI.GLUT > myFloat :: GLfloat > myFloat = 0.0 > main = return () ---------------------------------- $ ghc -package GLUT HelloWorld.lhs -o HelloWorld Illegal instruction I'm using ghc 6.8.3 on a Mac PowerBook G4. Googling "OpenGL illegal instruction" produced an unending choice of horror stories. What message am I not getting? Is there some crucial manual I'm not reading? Is there something which we should be being told on the relevant wiki page? Distressed Conor From allbery at ece.cmu.edu Tue Aug 12 05:18:44 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Aug 12 05:18:07 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> Message-ID: On 2008 Aug 12, at 5:11, Conor McBride wrote: > $ ghc -package GLUT HelloWorld.lhs -o HelloWorld > Illegal instruction > > I'm using ghc 6.8.3 on a Mac PowerBook G4. Googling > "OpenGL illegal instruction" produced an unending > choice of horror stories. > > What message am I not getting? Is there some crucial > manual I'm not reading? Is there something which we > should be being told on the relevant wiki page? You need to find (or build) a G4-compatible ghc; the 6.8.3 build for Leopard (and Tiger?) was built for a G5, and the above is the result. -- 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 malcolm.wallace at cs.york.ac.uk Tue Aug 12 05:19:53 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Aug 12 05:19:15 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> Message-ID: > $ ghc -package GLUT HelloWorld.lhs -o HelloWorld > Illegal instruction > > I'm using ghc 6.8.3 on a Mac PowerBook G4. Googling > "OpenGL illegal instruction" produced an unending > choice of horror stories. Not much help, but it compiles fine for me using ghc-6.8.3 on an iBook G4. I'm running MacOS 10.5.4, with gcc-4.0.1. Is it possible you have an older version of XCode (Apple's developer tools including gcc)? Regards, Malcolm From tom.davie at gmail.com Tue Aug 12 05:26:22 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Aug 12 05:25:45 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> Message-ID: <46ABD4E3-269B-45FB-AC6F-9E0CCC082A31@gmail.com> On 12 Aug 2008, at 11:11, Conor McBride wrote: > Hi folks > > I thought I'd try a bit of OpenGL. Perhaps I should > send this to the more specific list, but perhaps > other people are, like me, trying out a variety of > UI technology. I thought I'd give OpenGL a go, because > I saw the name whizz by when I upgraded to 6.8.3. I > found the tutorial and got copy-paste cracking. > > It was all going swimmingly while I did almost nothing, > but then ghc started dying on me. I chopped down my > failing code to this joyous specimen: > > HelloWorld.lhs contains > > ---------------------------------- > > > module Main where > > > import Graphics.Rendering.OpenGL > > import Graphics.UI.GLUT > > > myFloat :: GLfloat > > myFloat = 0.0 > > > main = return () > > ---------------------------------- > > $ ghc -package GLUT HelloWorld.lhs -o HelloWorld > Illegal instruction > > I'm using ghc 6.8.3 on a Mac PowerBook G4. Googling > "OpenGL illegal instruction" produced an unending > choice of horror stories. > > What message am I not getting? Is there some crucial > manual I'm not reading? Is there something which we > should be being told on the relevant wiki page? > > Distressed > > Conor I was going to say that this builds and runs fine on my MacPro so it could be an endianness issue, but Malcolm's experience seems to contradict that. Bob From conor at strictlypositive.org Tue Aug 12 05:43:33 2008 From: conor at strictlypositive.org (Conor McBride) Date: Tue Aug 12 05:42:54 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> Message-ID: <02225E46-396C-444C-AB9D-BF3B863FD43B@strictlypositive.org> Hi Thanks for the quick response. On 12 Aug 2008, at 10:18, Brandon S. Allbery KF8NH wrote: > > On 2008 Aug 12, at 5:11, Conor McBride wrote: > >> $ ghc -package GLUT HelloWorld.lhs -o HelloWorld >> Illegal instruction >> >> I'm using ghc 6.8.3 on a Mac PowerBook G4. Googling >> "OpenGL illegal instruction" produced an unending >> choice of horror stories. >> >> What message am I not getting? Is there some crucial >> manual I'm not reading? Is there something which we >> should be being told on the relevant wiki page? > > > You need to find (or build) a G4-compatible ghc; the 6.8.3 build > for Leopard (and Tiger?) was built for a G5, and the above is the > result. This sounds like bad news to me. I wonder how broken this G5 ghc is for a G4. Perhaps it should be labelled G5 rather than PowerPC in the large print. I'm quite scared about trying to build ghc: I worry that it may involve confronting large areas of my ignorance. I'm running Mac OS X 10.4.11 on a 1.5GHz PowerPC G4 PowerBook with 768MB of memory. I've got gcc 4.0.0. I'm using the 6.8.3 build whose entry on this page http://www.haskell.org/ghc/download_ghc_683.html reads ----- MacOS X (PowerPC) * ghc-6.8.3-powerpc-apple-darwin.tar.bz2 This is a binary distribution for Mac OS X 10.4 (Tiger) on PowerPC G5 machines, prepared by Christian Maeder. It needs libreadline. 5.2.dylib and libncurses.5.dylib under /opt/local/lib/. libgmp.a is statically linked in. ----- Now I'm wondering how badly I've shot myself in the foot. Alarmed Conor From cmb21 at kent.ac.uk Tue Aug 12 05:59:48 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue Aug 12 05:59:09 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> Message-ID: Andrew, Thanks very much for your reponse. It was very helpful; this makes a lot of sense! Regards, Chris. On Mon, 11 Aug 2008 ajb@spamcop.net wrote: > G'day all. > > Quoting "C.M.Brown" : > > > Yes, I saw that, thanks! I guess this is because it's hard to compile a > > mutually recursive module... > > It's because you don't need to declare the types of exported definitions. > > Consider, this highly artificial example: > > module A where > > import B > > f (x,y) = g (x,'A') > > > module B where > > import A > > g (x,y) = f (True,y) > > To infer the types of f and g, you need to analyse both modules together. > > And yes, some people think that this is a bug in the specification. > > Cheers, > Andrew Bromage > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jules at jellybean.co.uk Tue Aug 12 06:19:48 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Aug 12 06:19:14 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: <02225E46-396C-444C-AB9D-BF3B863FD43B@strictlypositive.org> References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> <02225E46-396C-444C-AB9D-BF3B863FD43B@strictlypositive.org> Message-ID: <48A163C4.2090400@jellybean.co.uk> Conor McBride wrote: > This sounds like bad news to me. I wonder how broken this > G5 ghc is for a G4. Perhaps it should be labelled G5 > rather than PowerPC in the large print. I'm quite scared > about trying to build ghc: I worry that it may involve > confronting large areas of my ignorance. > > I'm running Mac OS X 10.4.11 on a 1.5GHz PowerPC G4 > PowerBook with 768MB of memory. I've got gcc 4.0.0. > I'm using the 6.8.3 build whose entry on this page FWIW, I use ghc on my G4 and I got it by compiling from MacPorts. It took the best part of day, but the resulting binary works. Jules From conor at strictlypositive.org Tue Aug 12 06:27:30 2008 From: conor at strictlypositive.org (Conor McBride) Date: Tue Aug 12 06:26:59 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: <48A163C4.2090400@jellybean.co.uk> References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> <02225E46-396C-444C-AB9D-BF3B863FD43B@strictlypositive.org> <48A163C4.2090400@jellybean.co.uk> Message-ID: On 12 Aug 2008, at 11:19, Jules Bean wrote: > Conor McBride wrote: >> This sounds like bad news to me. I wonder how broken this >> G5 ghc is for a G4. Perhaps it should be labelled G5 >> rather than PowerPC in the large print. I'm quite scared >> about trying to build ghc: I worry that it may involve >> confronting large areas of my ignorance. >> I'm running Mac OS X 10.4.11 on a 1.5GHz PowerPC G4 >> PowerBook with 768MB of memory. I've got gcc 4.0.0. >> I'm using the 6.8.3 build whose entry on this page > > FWIW, I use ghc on my G4 and I got it by compiling from MacPorts. > > It took the best part of day, but the resulting binary works. I'm not sure whirl is the right word, but I'll give it one anyway. Cheers Conor From martin.hofmann at uni-bamberg.de Tue Aug 12 08:50:06 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Tue Aug 12 08:49:27 2008 Subject: [Haskell-cafe] "Prompt" Monad Message-ID: <1218545406.5947.14.camel@ios.cogsys.wiai.uni-bamberg.de> I just came across last year's thread about Ryan Ingram's "Prompt" monad ( http://www.mail-archive.com/haskell-cafe@haskell.org/msg33040.html ) and wondered if it might be useful for debugging and program analysis purposes. In particular, I thought about enforcing program decisions interactively. Consider for example modifying the heuristic function of a search algorithm at specific breakpoints. Is this possible with the "Prompt" monad? Furthermore, could somebody post the full code of it (and maybe a short example how to use it if at hand)? I was not able to run the code from the previous posts and the referring links are dead. Thanks a lot, Martin From tom.davie at gmail.com Tue Aug 12 09:32:14 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Aug 12 09:31:37 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> Message-ID: <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> On 12 Aug 2008, at 11:59, C.M.Brown wrote: > Andrew, > > Thanks very much for your reponse. It was very helpful; this makes a > lot > of sense! > >> And yes, some people think that this is a bug in the specification. >> I'm not sure that it does make a lot of sense -- we allow (mutually) recursive functions, even though they come with an efficiency penalty. Why should we not allow (mutually) recursive modules, even though they too come with an efficiency penalty. This is even an example where the efficiency loss is *only* at compile time, and only happens once, so it's somewhat a better situation than allowing mutually recursive functions. I'd say it falls very heavily into the ghc-bug category, not the spec bug category (even if there's reasons for the bug existing in ghc). Bob From cmb21 at kent.ac.uk Tue Aug 12 09:43:37 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue Aug 12 09:42:58 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> Message-ID: > I'm not sure that it does make a lot of sense -- we allow (mutually) > recursive functions, even though they come with an efficiency > penalty. Why should we not allow (mutually) recursive modules, even > though they too come with an efficiency penalty. This is even an > example where the efficiency loss is *only* at compile time, and only > happens once, so it's somewhat a better situation than allowing > mutually recursive functions. > > I'd say it falls very heavily into the ghc-bug category, not the spec > bug category (even if there's reasons for the bug existing in ghc). Perhaps it would be better for GHC to allow compilation of cyclic inclusions via a flag? -fcyclic or something? Or, to do it by default unless a -fno-cyclic flag is raised? It does seem strange that the only way to compile cyclic modules is to hack together a build using hi-boot files. Regards, Chris. From ajb at spamcop.net Tue Aug 12 10:01:06 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Aug 12 10:00:25 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> Message-ID: <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> G'day all. Quoting Thomas Davie : > I'm not sure that it does make a lot of sense -- we allow (mutually) > recursive functions, even though they come with an efficiency penalty. > Why should we not allow (mutually) recursive modules, even though they > too come with an efficiency penalty. The problem is not mutually recursive modules. Plenty of statically typed languages support mutually recursive modules. The problem is that it's impossible in general to say what the "interface" of a module is by examining the module alone. This is a very unusual property as real-world programming languages go. You could fix this by, for example, requiring that all symbols exported from a module have an explicit type annotation. Or, if you think that's not lazy enough, it could be an error to use an imported symbol that doesn't have an explicit type annotation. You could even formalise .hi-boot files if you were truly desperate. If the Haskell spec requires that multiple modules be analysed simultaneously (or multiple times to fixpoint), then that's a bug in the spec. Separate compilation is too important. Cheers, Andrew Bromage From lemming at henning-thielemann.de Tue Aug 12 10:28:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Aug 12 10:27:31 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> Message-ID: On Tue, 12 Aug 2008, ajb@spamcop.net wrote: > G'day all. > > Quoting Thomas Davie : > >> I'm not sure that it does make a lot of sense -- we allow (mutually) >> recursive functions, even though they come with an efficiency penalty. >> Why should we not allow (mutually) recursive modules, even though they >> too come with an efficiency penalty. > > The problem is not mutually recursive modules. Plenty of statically > typed languages support mutually recursive modules. > > The problem is that it's impossible in general to say what the > "interface" of a module is by examining the module alone. This is a > very unusual property as real-world programming languages go. > > You could fix this by, for example, requiring that all symbols > exported from a module have an explicit type annotation. As far as I know the real difficulties come from mutually recursive class definitions. From tom.davie at gmail.com Tue Aug 12 10:35:41 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Aug 12 10:35:04 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> Message-ID: <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> On 12 Aug 2008, at 16:01, ajb@spamcop.net wrote: > G'day all. > > Quoting Thomas Davie : > >> I'm not sure that it does make a lot of sense -- we allow (mutually) >> recursive functions, even though they come with an efficiency >> penalty. >> Why should we not allow (mutually) recursive modules, even though >> they >> too come with an efficiency penalty. > > The problem is not mutually recursive modules. Plenty of statically > typed languages support mutually recursive modules. > > The problem is that it's impossible in general to say what the > "interface" of a module is by examining the module alone. This is a > very unusual property as real-world programming languages go. > > You could fix this by, for example, requiring that all symbols > exported from a module have an explicit type annotation. Or, if you > think that's not lazy enough, it could be an error to use an imported > symbol that doesn't have an explicit type annotation. You could even > formalise .hi-boot files if you were truly desperate. > > If the Haskell spec requires that multiple modules be analysed > simultaneously (or multiple times to fixpoint), then that's a bug in > the spec. Separate compilation is too important. Why is separate compilation important? I can understand your point about a module on it's own not being analyzable, and that that's an odd property -- on the other hand, the rapidly emerging "atomic" unit in Haskell is the package, so I see no reason why modules within one package shouldn't depend on each other. Finally, as chris suggests, if separate compilation is important to you, why not have a flag in ghc -frequire-hi-boot or something? Bob From conor at strictlypositive.org Tue Aug 12 10:55:22 2008 From: conor at strictlypositive.org (Conor McBride) Date: Tue Aug 12 10:54:44 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> <02225E46-396C-444C-AB9D-BF3B863FD43B@strictlypositive.org> <48A163C4.2090400@jellybean.co.uk> Message-ID: <2C8FAA02-426F-4C9D-9F1D-FC8899BCA217@strictlypositive.org> On 12 Aug 2008, at 11:27, Conor McBride wrote: > > On 12 Aug 2008, at 11:19, Jules Bean wrote: > >> >> FWIW, I use ghc on my G4 and I got it by compiling from MacPorts. >> >> It took the best part of day, but the resulting binary works. > > I'm not sure whirl is the right word, but I'll give it one anyway. After a very long time, it fell over with a large error message that I don't understand. Somehow, I'll get over it. I can't help thinking that this stuff shouldn't be hard. And yet it is. Sorry to anyone for whom this is just spam, and much gratitude to clued in people who can tell me in which particular way I'm being an idiot at the moment. All the best Conor -------------- next part -------------- A non-text attachment was scrubbed... Name: oops Type: application/octet-stream Size: 8761 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080812/778c5eed/oops.obj From jules at jellybean.co.uk Tue Aug 12 11:34:17 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Aug 12 11:33:39 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: <2C8FAA02-426F-4C9D-9F1D-FC8899BCA217@strictlypositive.org> References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> <02225E46-396C-444C-AB9D-BF3B863FD43B@strictlypositive.org> <48A163C4.2090400@jellybean.co.uk> <2C8FAA02-426F-4C9D-9F1D-FC8899BCA217@strictlypositive.org> Message-ID: <48A1AD79.1070108@jellybean.co.uk> Conor McBride wrote: > After a very long time, it fell over with a large error message that > I don't understand. > > Somehow, I'll get over it. > > I can't help thinking that this stuff shouldn't be hard. And yet it > is. Sorry to anyone for whom this is just spam, and much gratitude > to clued in people who can tell me in which particular way I'm being > an idiot at the moment. It used to be easier. I don't know why it isn't any more. This trac bug seems relevant http://hackage.haskell.org/trac/ghc/ticket/2262 There is a workaround suggested there. I don't know why this happens for you and not for the port uploader. There are many things I fail to understand about building on OSX :( Jules From ryani.spam at gmail.com Tue Aug 12 13:28:58 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Aug 12 13:28:17 2008 Subject: [Haskell-cafe] "Prompt" Monad In-Reply-To: <1218545406.5947.14.camel@ios.cogsys.wiai.uni-bamberg.de> References: <1218545406.5947.14.camel@ios.cogsys.wiai.uni-bamberg.de> Message-ID: <2f9b2d30808121028p3909228ep1de0ad9d2a86a5c5@mail.gmail.com> Latest code is on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt There is a "sample" file with lots of other monads implemented in terms of Prompt included, along with some links to other samples; I seem to recall there being a "guess a number" game on paste.lisp.org that used Prompt to switch between user control and AI control. Let me know if you have any problems building it and I'll patch it up. -- ryan On Tue, Aug 12, 2008 at 5:50 AM, Martin Hofmann wrote: > I just came across last year's thread about Ryan Ingram's "Prompt" monad > ( http://www.mail-archive.com/haskell-cafe@haskell.org/msg33040.html ) > and wondered if it might be useful for debugging and program analysis > purposes. In particular, I thought about enforcing program decisions > interactively. Consider for example modifying the heuristic function of > a search algorithm at specific breakpoints. > > Is this possible with the "Prompt" monad? Furthermore, could somebody > post the full code of it (and maybe a short example how to use it if at > hand)? I was not able to run the code from the previous posts and the > referring links are dead. > > Thanks a lot, > > Martin > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From cmb21 at kent.ac.uk Tue Aug 12 13:38:11 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue Aug 12 13:37:33 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> Message-ID: > The problem is not mutually recursive modules. Plenty of statically > typed languages support mutually recursive modules. > > The problem is that it's impossible in general to say what the > "interface" of a module is by examining the module alone. This is a > very unusual property as real-world programming languages go. > > You could fix this by, for example, requiring that all symbols > exported from a module have an explicit type annotation. Or, if you > think that's not lazy enough, it could be an error to use an imported > symbol that doesn't have an explicit type annotation. You could even > formalise .hi-boot files if you were truly desperate. I don't really see this as being any kind of real issue at all. Surely all GHC needs to do is to concatenate all the modules together, alpha-reduce the import/export relations and do a compile/type check over the concatenated module. > > If the Haskell spec requires that multiple modules be analysed > simultaneously (or multiple times to fixpoint), then that's a bug in > the spec. Separate compilation is too important. Why is it a bug in the spec exactly? And why is separate compilation so important? Chris. From isaacdupree at charter.net Tue Aug 12 15:40:09 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Aug 12 15:39:41 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> Message-ID: <48A1E719.7000400@charter.net> C.M.Brown wrote: > I don't really see this as being any kind of real issue at all. Surely all > GHC needs to do is to concatenate all the modules together, alpha-reduce > the import/export relations and do a compile/type check over the > concatenated module. FWIW, I agree (in principle -- I haven't looked at the GHC implementation enough to see whether its internal representations could easily do type inference involving symbols in multiple modules, and GHC HQ understandably isn't interested in implementing it themselves http://hackage.haskell.org/trac/ghc/ticket/1409 ). There is a bit of a question in my mind about what to do with .hi/.o files for the combined blob. There's also a scalability / memory use issue, that is also the plug for separate compilation: if you make really big modules (whether manually or programmatically), compiling them takes lots of memory and time, significantly more total time and maximum memory than you need for via separate compilation. I consider this a bug. (Well, I don't know if what I said is true -- it's just an excuse that's often given for why GHC compiling things together is a bad idea. And there are several compile-time performance bugs in Trac.) Admittedly, it's a challenging problem to automatically segment a large module so you only need to do a little work at once. Essentially, the module system partly has the purpose of telling the compiler how not to try to optimize, even if it would be beneficial; and thereby you get reasonable compilation times. This would be inexcusable in my mind if the same sort of module segmentation didn't also help *humans* understand the contents of the modules :-). I wonder if there can be some sort of system with pragmas that accomplishes the same purpose of guiding the compiler... probably not for Haskell so much as in general -Isaac From tom.davie at gmail.com Tue Aug 12 17:06:20 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Aug 12 17:06:00 2008 Subject: [Haskell-cafe] GLfloat on a Mac In-Reply-To: <2C8FAA02-426F-4C9D-9F1D-FC8899BCA217@strictlypositive.org> References: <54964774-6FC1-4CA4-82BD-BDEFD1E00BCF@strictlypositive.org> <02225E46-396C-444C-AB9D-BF3B863FD43B@strictlypositive.org> <48A163C4.2090400@jellybean.co.uk> <2C8FAA02-426F-4C9D-9F1D-FC8899BCA217@strictlypositive.org> Message-ID: <51ADFEBB-0799-4039-BF11-0AFD271D65BE@gmail.com> On 12 Aug 2008, at 16:55, Conor McBride wrote: > > On 12 Aug 2008, at 11:27, Conor McBride wrote: > >> >> On 12 Aug 2008, at 11:19, Jules Bean wrote: >> >>> >>> FWIW, I use ghc on my G4 and I got it by compiling from MacPorts. >>> >>> It took the best part of day, but the resulting binary works. >> >> I'm not sure whirl is the right word, but I'll give it one anyway. > > After a very long time, it fell over with a large error message that > I don't understand. > > Somehow, I'll get over it. > > I can't help thinking that this stuff shouldn't be hard. And yet it > is. Sorry to anyone for whom this is just spam, and much gratitude > to clued in people who can tell me in which particular way I'm being > an idiot at the moment. > > All the best > > Conor FWIW my experience is that my experience of getting GHC running on a Mac got dramatically better as soon as I bought an Intel based mac. Firstly the compile times are *vastly* reduced (we're talking from 24 hours to 1 hour, or even 20 minutes on a Mac Pro). Secondly, and more importantly, more people seem to have intel macs, and are willing to devote their time to getting it working nicely on them, so in general, you tell it to build once, and it works. Bob From abimelech at gmail.com Tue Aug 12 18:44:55 2008 From: abimelech at gmail.com (Leif Warner) Date: Tue Aug 12 18:44:14 2008 Subject: [Haskell-cafe] Dealing with heterogeneously-typed lists? Message-ID: <54d4ec0f0808121544s62fbdcf3x1588fbae55d01d84@mail.gmail.com> Hi all, I'm dealing with some datatype, say: data Invoice = Invoice { invoiceNum :: String, dollarAmt :: Currency, printDate :: Date, dueDate :: Date, vendorNum :: Int, vendorName :: String, isStock :: Bool, } that I want to put in or take out of rows in xml spreadsheets, databases, that sort of thing. The elements of the spreadsheet row want type annotations like "String", "Number, "DateTime", etc. Also, each data element is required to be formatted differently, e.g. (show dueDate) ++ "T00:00:00", because the spreadsheet format wants a time tacked on, too. I know in a language like Java or C++ I might do some sort of run-time type identification, which would detect the type of each element in the list, and output it appropriately. As it is, I'm tupling each accessor function with the the type the spreadsheet wants, as a string: e.g. [(invoiceNum, "String"), (dollarAmt, "Number"), (printDate, "DateTime"),...] Is there a better way of doing this? Maybe messing with the "show" function to precede the string representation with a few characters about the type it's supposed to be? Or would looking into something like this be a good idea? It looks a lil old... http://homepages.cwi.nl/~ralf/HList/ --Strongly typed heterogeneous collections Thanks! -Leif -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080812/200b7d02/attachment.htm From newsham at lava.net Tue Aug 12 20:13:26 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 20:12:48 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString Message-ID: I have a program that read in and populated a large data structure and then saved it out with Data.Binary and Data.ByteString.Lazy.Char8: saveState db = B.writeFile stateFile =<< encode <$> atomically (readTVar db) when I go to read this in later I get a stack overflow: loadState db = do d <- decode <$> B.readFile stateFile atomically $ writeTVar db d Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. or from ghci: d <- liftM decode (Data.ByteString.Lazy.Char8.readFile "savedState.bin") :: IO InstrsDb fromList *** Exception: stack overflow The data type I'm storing is a Map (of maps): type DailyDb = M.Map Date Daily type InstrsDb = M.Map String DailyDb What's going on here? Why is the system capable of building and saving the data but not in reading and umarhsalling it? What is the proper way to track down where the exception is happening? Any debugging tips? I also noticed another issue while testing. If my program loads the data at startup by calling loadState then all later calls to saveState give an error: Log: savedState.bin: openFile: resource busy (file is locked) this does not occur if the program wasnt loaded. My best guess here is that B.readFile isnt completing and closing the file for some reason. Is there a good way to force this? Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Tue Aug 12 20:18:20 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 12 20:17:37 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: Message-ID: <20080813001820.GH25256@scytale.galois.com> newsham: > I have a program that read in and populated a large data structure and > then saved it out with Data.Binary and Data.ByteString.Lazy.Char8: > > saveState db = B.writeFile stateFile =<< > encode <$> atomically (readTVar db) > > when I go to read this in later I get a stack overflow: > > loadState db = do > d <- decode <$> B.readFile stateFile > atomically $ writeTVar db d > > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. > > or from ghci: > > d <- liftM decode > (Data.ByteString.Lazy.Char8.readFile > "savedState.bin") :: IO InstrsDb > > fromList *** Exception: stack overflow > > The data type I'm storing is a Map (of maps): > > type DailyDb = M.Map Date Daily > type InstrsDb = M.Map String DailyDb > > What's going on here? Why is the system capable of building and saving > the data but not in reading and umarhsalling it? What is the proper way > to track down where the exception is happening? Any debugging tips? So a big Map is serialised as a huge list. instance (Ord k, Binary k, Binary e) => Binary (Map.Map k e) where put = put . Map.toAscList get = liftM Map.fromDistinctAscList get so that fromAscList's the result of parsing the map as a list, via, instance Binary a => Binary [a] where put l = put (length l) >> mapM_ put l get = do n <- get :: Get Int replicateM n get so that's a length-prefixed list, strictly. Which is possibly where the stack's being consumed. Does just bumping the stack size a bit help? Alternatively, you could consider serialising the Map in some other format (i.e. newtype the list, and serialise that say, in a lazy/chunked encoding). > I also noticed another issue while testing. If my program loads > the data at startup by calling loadState then all later calls to > saveState give an error: > > Log: savedState.bin: openFile: resource busy (file is locked) > > this does not occur if the program wasnt loaded. My best guess here > is that B.readFile isnt completing and closing the file for some > reason. Is there a good way to force this? Lazy IO. So force the result to be evaluated, and then close the handle, or use strict bytestring reading. -- Don From newsham at lava.net Tue Aug 12 20:28:49 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 20:28:08 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080813001820.GH25256@scytale.galois.com> References: <20080813001820.GH25256@scytale.galois.com> Message-ID: > so that fromAscList's the result of parsing the map as a list, via, > > instance Binary a => Binary [a] where > put l = put (length l) >> mapM_ put l > get = do n <- get :: Get Int > replicateM n get > > so that's a length-prefixed list, strictly. Which is possibly where the > stack's being consumed. Does just bumping the stack size a bit help? ugh.. length prefix.. I could bump the stack size to fix my immediate situation, but my goal is to have a server with a huge in-memory data set, and my test data so far is quite small. > Alternatively, you could consider serialising the Map in some other > format (i.e. newtype the list, and serialise that say, in a lazy/chunked > encoding). hackery :( but that sounds like the obvious fix. >> Log: savedState.bin: openFile: resource busy (file is locked) >> >> this does not occur if the program wasnt loaded. My best guess here >> is that B.readFile isnt completing and closing the file for some >> reason. Is there a good way to force this? > > Lazy IO. So force the result to be evaluated, and then close the handle, > or use strict bytestring reading. There is no visible handle. It's all hidden in readFile. I will try forcing the data. > -- Don Tim Newsham http://www.thenewsh.com/~newsham/ From newsham at lava.net Tue Aug 12 20:34:44 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 20:34:03 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> Message-ID: >>> Log: savedState.bin: openFile: resource busy (file is locked) >>> >>> this does not occur if the program wasnt loaded. My best guess here >>> is that B.readFile isnt completing and closing the file for some >>> reason. Is there a good way to force this? >> >> Lazy IO. So force the result to be evaluated, and then close the handle, >> or use strict bytestring reading. > > There is no visible handle. It's all hidden in readFile. > I will try forcing the data. I tried to force the data with: loadState db = do d <- decode <$> B.readFile stateFile let force = sum $ M.elems $ M.size `fmap` d force `seq` atomically $ writeTVar db d and I get the same error when trying to writeFile after doing a loadState. >> -- Don Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Tue Aug 12 20:32:31 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 12 20:36:34 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> Message-ID: <20080813003231.GL25256@scytale.galois.com> newsham: > >so that fromAscList's the result of parsing the map as a list, via, > > > > instance Binary a => Binary [a] where > > put l = put (length l) >> mapM_ put l > > get = do n <- get :: Get Int > > replicateM n get > > > >so that's a length-prefixed list, strictly. Which is possibly where the > >stack's being consumed. Does just bumping the stack size a bit help? > > ugh.. length prefix.. > I could bump the stack size to fix my immediate situation, but my goal > is to have a server with a huge in-memory data set, and my test data > so far is quite small. > > >Alternatively, you could consider serialising the Map in some other > >format (i.e. newtype the list, and serialise that say, in a lazy/chunked > >encoding). > > hackery :( > but that sounds like the obvious fix. Not hackery, just a different encoding. The default Binary encodings don't work cover all use cases and all scales. To hit other sweet spots, use your own instances. > >> Log: savedState.bin: openFile: resource busy (file is locked) > >> > >>this does not occur if the program wasnt loaded. My best guess here > >>is that B.readFile isnt completing and closing the file for some > >>reason. Is there a good way to force this? > > > >Lazy IO. So force the result to be evaluated, and then close the handle, > >or use strict bytestring reading. > > There is no visible handle. It's all hidden in readFile. > I will try forcing the data. So you can decode using openFile, hGet and hClose on strict bytetrings, or force the data. -- Don From bos at serpentine.com Tue Aug 12 20:40:55 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Aug 12 20:40:14 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: Message-ID: On Tue, Aug 12, 2008 at 5:13 PM, Tim Newsham wrote: > The data type I'm storing is a Map (of maps): > > type DailyDb = M.Map Date Daily > type InstrsDb = M.Map String DailyDb > > What's going on here? The default marshalling scheme that Binary uses for lists and maps (which are flattened to lists before writing out) is not streamable. Instead of writing out data in chunks, it computes the length of the list and writes that, followed by the elements. Presumably on the read side, a huge thunk is being built up before any actual Map creation starts. > I also noticed another issue while testing. If my program loads > the data at startup by calling loadState then all later calls to > saveState give an error: > > Log: savedState.bin: openFile: resource busy (file is locked) > > this does not occur if the program wasnt loaded. Your loading of state isn't being forced to complete, so the file handle is still open when you try to save to the same file. The H98 standard requires that file handles be locked for exclusive access during writes. To force the read to finish, use rnf. You can find a description of how to use it, and the typeclasses involved, here: http://book.realworldhaskell.org/beta/concurrent.html From bos at serpentine.com Tue Aug 12 20:45:19 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Aug 12 20:44:38 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> Message-ID: On Tue, Aug 12, 2008 at 5:34 PM, Tim Newsham wrote: > I tried to force the data with: > > loadState db = do > d <- decode <$> B.readFile stateFile > let force = sum $ M.elems $ M.size `fmap` d > force `seq` atomically $ writeTVar db d > > and I get the same error when trying to writeFile after doing > a loadState. What happens if you simply print the number of elements in the map? Forcing its spine is all you should need. From felipe.lessa at gmail.com Tue Aug 12 20:48:09 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Tue Aug 12 20:47:27 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080813003231.GL25256@scytale.galois.com> References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> Message-ID: On Tue, Aug 12, 2008 at 9:32 PM, Don Stewart wrote: > Not hackery, just a different encoding. The default Binary encodings > don't work cover all use cases and all scales. To hit other sweet spots, > use your own instances. Doesn't Data.Map.size run in O(1) time? Maybe something like using different encodings for big maps in the default implementation would help? -- Felipe. From newsham at lava.net Tue Aug 12 20:48:38 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 20:47:56 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> Message-ID: On Tue, 12 Aug 2008, Bryan O'Sullivan wrote: > On Tue, Aug 12, 2008 at 5:34 PM, Tim Newsham wrote: > >> I tried to force the data with: >> >> loadState db = do >> d <- decode <$> B.readFile stateFile >> let force = sum $ M.elems $ M.size `fmap` d >> force `seq` atomically $ writeTVar db d >> >> and I get the same error when trying to writeFile after doing >> a loadState. > > What happens if you simply print the number of elements in the map? > Forcing its spine is all you should need. This is what the sum above does. Its a Map of Maps, so this maps M.size over the outter Map and sums the resulting elements. That should touch every map element, at least. Tim Newsham http://www.thenewsh.com/~newsham/ From newsham at lava.net Tue Aug 12 20:58:38 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 20:57:56 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080813004714.GN25256@scytale.galois.com> References: <20080813004714.GN25256@scytale.galois.com> Message-ID: > Maybe it makes sense to have the streamble list instance in Binary as > well, with some examples? A flexible format that doesn't sacrifice too much space efficiency would be to encode in chunks of up to 255 elements: Chunk = { length :: Word8 elems :: [Elem] -- 0..255 repetitions } Chunks = [Chunk] -- terminated with the first 0 length Chunk streamable, amortized cost is about 1/256th of the length, and the encoding is much more efficient than the current scheme for short lists (like most strings). Currently a string "foobar" is 8 bytes for length and 7 for the actual string. > -- Don Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Tue Aug 12 20:47:14 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 12 20:58:13 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: Message-ID: <20080813004714.GN25256@scytale.galois.com> bos: > On Tue, Aug 12, 2008 at 5:13 PM, Tim Newsham wrote: > > > The data type I'm storing is a Map (of maps): > > > > type DailyDb = M.Map Date Daily > > type InstrsDb = M.Map String DailyDb > > > > What's going on here? > > The default marshalling scheme that Binary uses for lists and maps > (which are flattened to lists before writing out) is not streamable. > Instead of writing out data in chunks, it computes the length of the > list and writes that, followed by the elements. Presumably on the read > side, a huge thunk is being built up before any actual Map creation > starts. Maybe it makes sense to have the streamble list instance in Binary as well, with some examples? -- Don From newsham at lava.net Tue Aug 12 21:01:37 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 21:00:55 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> Message-ID: > Doesn't Data.Map.size run in O(1) time? Maybe something like using > different encodings for big maps in the default implementation would > help? ugh, of course. Ok, so I fixed it to: loadState db = do d <- decode <$> B.readFile stateFile let force = sum $ map (sum . map fromEnum . M.keys) $ M.elems d print force force `seq` atomically $ writeTVar db d (my keys are dates, which are Enum). This should look at every key in every inner map. Shouldn't that be sufficient to force the entire data set (or do I have to touch the fields in the data elements too?). I still get the same error condition. > Felipe. Tim Newsham http://www.thenewsh.com/~newsham/ From bos at serpentine.com Tue Aug 12 21:07:57 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Aug 12 21:07:15 2008 Subject: [Haskell-cafe] Dealing with heterogeneously-typed lists? In-Reply-To: <54d4ec0f0808121544s62fbdcf3x1588fbae55d01d84@mail.gmail.com> References: <54d4ec0f0808121544s62fbdcf3x1588fbae55d01d84@mail.gmail.com> Message-ID: 2008/8/12 Leif Warner : > I know in a language like Java or C++ I might do some sort of run-time type > identification, which would detect the type of each element in the list, and > output it appropriately. I think I've missed a step. Why do you want to break the fields of an Invoice out into a list in the first place? From bos at serpentine.com Tue Aug 12 21:12:28 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Aug 12 21:11:49 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> Message-ID: On Tue, Aug 12, 2008 at 6:01 PM, Tim Newsham wrote: > (my keys are dates, which are Enum). This should look at > every key in every inner map. Shouldn't that be sufficient to > force the entire data set (or do I have to touch the fields in the > data elements too?) You might have to force the last value of the alist that the map gets flattened into, since otherwise there's no guarantee that it will be read. You really, really want to be using rnf for this job, instead of turning your brain into a pretzel shape. From newsham at lava.net Tue Aug 12 21:28:44 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 21:28:01 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> Message-ID: > You might have to force the last value of the alist that the map gets > flattened into, since otherwise there's no guarantee that it will be > read. > > You really, really want to be using rnf for this job, instead of > turning your brain into a pretzel shape. *nod* that's my eventual goal but I'd like to make sure I understand what is going on here first and rule out any bugs before I go using some class I'm not that familiar with. I'm starting to wonder if this isn't an issue with Data.ByteString.Lazy.Char8.{read,write}File. I am now printing out the data entirely: d <- decode <$> B.readFile stateFile print d and I still get the same error when I go to writeFile later. There should be no data items in any of my structures that the print statement does not force. Tim Newsham http://www.thenewsh.com/~newsham/ From newsham at lava.net Tue Aug 12 21:44:01 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 12 21:43:20 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> Message-ID: > I'm starting to wonder if this isn't an issue with > Data.ByteString.Lazy.Char8.{read,write}File. This simple test case fails: module Main where import qualified Data.ByteString.Lazy.Char8 as B main = do print =<< B.readFile "xxx" B.writeFile "xxx" =<< B.readFile "test.hs" If you replace B.readFile with readFile and B.writeFile with writeFile it works properly. ByteString bug? Tim Newsham http://www.thenewsh.com/~newsham/ From ajb at spamcop.net Tue Aug 12 23:06:48 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Aug 12 23:06:06 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> Message-ID: <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> G'day all. Quoting Thomas Davie : > Why is separate compilation important? I'm a little shocked that anyone on this list should have to ask this question. Two people have asked it now. The simplest answer is that unless your program fits in cache, it takes longer to compile two modules concurrently than it takes to compile them separately. This is even more true if one of those modules does not actually need recompilation. The longer answer is that in the Real World, programmer time is far, far more precious than computer time. Every second that the programmer waits for the computer to finish some task, there is a priority inversion. It's therefore highly desirable that jobs done by computer are as fast as possible or, failing that, as predictable as possible, so the programmer knows to do something else while waiting. Separate compilation puts a predictable upper bound on the amount of recompilation that has to be done given some set of changes. True, so does requiring recompilation of a package as a whole, but Haskell development would then be notorious for its sluggishness. > I can understand your point > about a module on it's own not being analyzable, and that that's an odd > property -- on the other hand, the rapidly emerging "atomic" unit in > Haskell is the package, so I see no reason why modules within one > package shouldn't depend on each other. Implicit in my working definition of "module" is that a module has a well-defined interface. Am I the only one who has that understanding? (Well, me and David Parnas, at any rate.) For the record, I have no problem with modules depending on each other, so long as they only depend on their well-defined interfaces. > Finally, as chris suggests, if separate compilation is important to > you, why not have a flag in ghc -frequire-hi-boot or something? Well, if I wanted separate header files, and the inevitable multiple- maintenance headaches associated with them, I'd program in C. Except for mutually recursive modules, GHC can and does generate header files automatically, so I don't see why my time should be wasted doing the job of a compiler. If something is preventing the compiler from doing that job, then that something should be fixed. Cheers, Andrew Bromage From dons at galois.com Tue Aug 12 23:12:05 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 12 23:11:22 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> Message-ID: <20080813031205.GA3743@scytale.galois.com> bos: > On Tue, Aug 12, 2008 at 6:01 PM, Tim Newsham wrote: > > > (my keys are dates, which are Enum). This should look at > > every key in every inner map. Shouldn't that be sufficient to > > force the entire data set (or do I have to touch the fields in the > > data elements too?) > > You might have to force the last value of the alist that the map gets > flattened into, since otherwise there's no guarantee that it will be > read. > > You really, really want to be using rnf for this job, instead of > turning your brain into a pretzel shape. The Pretzel being one of the lesser-known lazy, cyclic, functional data structures. -- Don From ajb at spamcop.net Tue Aug 12 23:27:17 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Aug 12 23:26:35 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> Message-ID: <20080812232717.fm4wh6ug1wo4s080-nwo@webmail.spamcop.net> G'day all. Quoting Henning Thielemann : > As far as I know the real difficulties come from mutually recursive > class definitions. I wouldn't be surprised, because that's a more blatant instance of the same problem. With classes and instances, there is no way to specify whether or not they are exported or not, which makes it that much harder to identify what the interface of a module is. Cheers, Andrew Bromage From dons at galois.com Wed Aug 13 00:43:15 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 13 00:42:33 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> Message-ID: <20080813044314.GB3743@scytale.galois.com> newsham: > >I'm starting to wonder if this isn't an issue with > >Data.ByteString.Lazy.Char8.{read,write}File. > > This simple test case fails: > > module Main where > import qualified Data.ByteString.Lazy.Char8 as B > main = do > print =<< B.readFile "xxx" > B.writeFile "xxx" =<< B.readFile "test.hs" > > If you replace B.readFile with readFile and B.writeFile with writeFile > it works properly. ByteString bug? Ah, that would be a bug in older ByteString implementations, that were a bit incautious about closing handles. This example works for me with bytestring-0.9.1.0 You're looking for a post-Dec 19, 2007 release, after the patch, Wed Dec 19 22:06:13 PST 2007 Don Stewart * For lazy IO operations, be sure to hClose the resource on EOF -- Don From martin.hofmann at uni-bamberg.de Wed Aug 13 02:32:28 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Wed Aug 13 02:31:45 2008 Subject: [Haskell-cafe] "Prompt" Monad In-Reply-To: <2f9b2d30808121028p3909228ep1de0ad9d2a86a5c5@mail.gmail.com> References: <1218545406.5947.14.camel@ios.cogsys.wiai.uni-bamberg.de> <2f9b2d30808121028p3909228ep1de0ad9d2a86a5c5@mail.gmail.com> Message-ID: <1218609148.6180.1.camel@ios.cogsys.wiai.uni-bamberg.de> Thanks a lot. That is exactly what I have been looking for. Cheers, Martin On Tue, 2008-08-12 at 10:28 -0700, Ryan Ingram wrote: > Latest code is on hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt > > There is a "sample" file with lots of other monads implemented in > terms of Prompt included, along with some links to other samples; I > seem to recall there being a "guess a number" game on paste.lisp.org > that used Prompt to switch between user control and AI control. > > Let me know if you have any problems building it and I'll patch it up. > > -- ryan > > On Tue, Aug 12, 2008 at 5:50 AM, Martin Hofmann > wrote: > > I just came across last year's thread about Ryan Ingram's "Prompt" monad > > ( http://www.mail-archive.com/haskell-cafe@haskell.org/msg33040.html ) > > and wondered if it might be useful for debugging and program analysis > > purposes. In particular, I thought about enforcing program decisions > > interactively. Consider for example modifying the heuristic function of > > a search algorithm at specific breakpoints. > > > > Is this possible with the "Prompt" monad? Furthermore, could somebody > > post the full code of it (and maybe a short example how to use it if at > > hand)? I was not able to run the code from the previous posts and the > > referring links are dead. > > > > Thanks a lot, > > > > Martin > > > > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- --------------------------------------------------------------- Dipl.-Wirtsch.Inf. (E.M.B.Sc.) Martin Hofmann? Cognitive Systems Group Faculty Information Systems and Applied Computer Science University of Bamberg http://www.cogsys.wiai.uni-bamberg.de/members/hofmann http://www.inductive-programming.org From ketil at malde.org Wed Aug 13 02:51:20 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Aug 13 02:50:14 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080813031205.GA3743@scytale.galois.com> (Don Stewart's message of "Tue\, 12 Aug 2008 20\:12\:05 -0700") References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> <20080813031205.GA3743@scytale.galois.com> Message-ID: <87skt9wgpj.fsf@malde.org> Don Stewart writes: >> You really, really want to be using rnf for this job, instead of >> turning your brain into a pretzel shape. > The Pretzel being one of the lesser-known lazy, cyclic, functional data structures. So "pretzel-brain" is actually a honorific, rather than derogative term? /me makes mental note. -k -- If I haven't seen further, it is by standing in the footprints of giants From dons at galois.com Wed Aug 13 03:06:44 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 13 03:06:02 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <87skt9wgpj.fsf@malde.org> References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> <20080813031205.GA3743@scytale.galois.com> <87skt9wgpj.fsf@malde.org> Message-ID: <20080813070644.GA4299@scytale.galois.com> ketil: > Don Stewart writes: > > >> You really, really want to be using rnf for this job, instead of > >> turning your brain into a pretzel shape. > > > The Pretzel being one of the lesser-known lazy, cyclic, functional data structures. > > So "pretzel-brain" is actually a honorific, rather than derogative term? > /me makes mental note. Yes, bestowed upon those who've read Okasaki, and can tie-the-knot. -- Don From tom.davie at gmail.com Wed Aug 13 03:22:31 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Aug 13 03:21:55 2008 Subject: [Haskell-cafe] Dealing with heterogeneously-typed lists? In-Reply-To: <54d4ec0f0808121544s62fbdcf3x1588fbae55d01d84@mail.gmail.com> References: <54d4ec0f0808121544s62fbdcf3x1588fbae55d01d84@mail.gmail.com> Message-ID: <68153152-4F0E-40DD-ADA0-A65FA0FD0E08@gmail.com> On 13 Aug 2008, at 00:44, Leif Warner wrote: > Hi all, > I'm dealing with some datatype, say: > data Invoice = > Invoice { invoiceNum :: String, > dollarAmt :: Currency, > printDate :: Date, > > dueDate :: Date, > vendorNum :: Int, > vendorName :: String, > isStock :: Bool, > } You probably don't want to put these things into a list at all. Instead, you want to define an Instance of the Show class for Invoice. Bob From tom.davie at gmail.com Wed Aug 13 04:26:57 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Aug 13 04:26:34 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> Message-ID: <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> On 13 Aug 2008, at 05:06, ajb@spamcop.net wrote: > G'day all. > > Quoting Thomas Davie : > >> Why is separate compilation important? > > I'm a little shocked that anyone on this list should have to ask this > question. Two people have asked it now. > > The simplest answer is that unless your program fits in cache, it > takes longer to compile two modules concurrently than it takes to > compile them separately. This is even more true if one of those > modules does not actually need recompilation. > > The longer answer is that in the Real World, programmer time is > far, far more precious than computer time. Every second that the > programmer waits for the computer to finish some task, there is a > priority inversion. Really? So you're using YHC then? It after all compiles *much* faster than GHC, but produces slower binaries. To be honest, ghc compiles things so fast (at least on any of my systems) that I couldn't care less if it took 10 times as long (I would however like some added convenience for that time spent) > It's therefore highly desirable that jobs done by computer are as > fast as possible or, failing that, as predictable as possible, so > the programmer knows to do something else while waiting. > > Separate compilation puts a predictable upper bound on the amount > of recompilation that has to be done given some set of changes. > True, so does requiring recompilation of a package as a whole, but > Haskell development would then be notorious for its sluggishness. It does? If I compile a module on which lots of other modules depend, I have to do lots of recompilation... If I compile a module which is in a cyclic dependancy group, I have to do lots of recompilation, I don't see that there's a difference here. >> I can understand your point >> about a module on it's own not being analyzable, and that that's an >> odd >> property -- on the other hand, the rapidly emerging "atomic" unit in >> Haskell is the package, so I see no reason why modules within one >> package shouldn't depend on each other. > > Implicit in my working definition of "module" is that a module has a > well-defined interface. Am I the only one who has that understanding? > (Well, me and David Parnas, at any rate.) > > For the record, I have no problem with modules depending on each > other, > so long as they only depend on their well-defined interfaces. That's a fair point about programming style, otoh, I don't think it's a reason to restrict users to not using cyclic dependancies. >> Finally, as chris suggests, if separate compilation is important to >> you, why not have a flag in ghc -frequire-hi-boot or something? > > Well, if I wanted separate header files, and the inevitable multiple- > maintenance headaches associated with them, I'd program in C. Except > for mutually recursive modules, GHC can and does generate header files > automatically, so I don't see why my time should be wasted doing the > job of a compiler. > > If something is preventing the compiler from doing that job, then that > something should be fixed. Something *does* prevent the compiler doing that job -- the fact that ghc can't deal with cyclic module includes without an hi-boot file. This is *exactly* my point -- I don't see why my time should be wasted doing the job of the compiler just because I happen to have a cyclic dependancy, that the compiler could quite happily sort out, by making my compile time in this situation slightly longer. If I *really* think I'm going to save more time by writing a hi-boot file, then I would be able to turn on the option! Bob From lemming at henning-thielemann.de Wed Aug 13 05:10:38 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Aug 13 05:10:32 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> Message-ID: On Wed, 13 Aug 2008, Thomas Davie wrote: > On 13 Aug 2008, at 05:06, ajb@spamcop.net wrote: > >> Quoting Thomas Davie : >> >>> Why is separate compilation important? >> >> I'm a little shocked that anyone on this list should have to ask this >> question. Two people have asked it now. > > Really? So you're using YHC then? It after all compiles *much* faster than > GHC, but produces slower binaries. To be honest, ghc compiles things so fast > (at least on any of my systems) that I couldn't care less if it took 10 times > as long (I would however like some added convenience for that time spent) It's the ubiquitous "computers are fast enough today" argument. I don't buy it. We don't have compile time to waste. There will always be computers that are much slower and have less memory than the current customer desktop computers, there are always tasks that a computer can do instead of doing slowed down compilation. I'm glad that we have overcome C's way of concatening all header files together before starting compilation. From tom.davie at gmail.com Wed Aug 13 06:02:11 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Aug 13 06:01:40 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> Message-ID: <23505EF9-D14C-4D57-9E50-A9902C913417@gmail.com> On 13 Aug 2008, at 11:10, Henning Thielemann wrote: > > On Wed, 13 Aug 2008, Thomas Davie wrote: > >> On 13 Aug 2008, at 05:06, ajb@spamcop.net wrote: >> >>> Quoting Thomas Davie : >>>> Why is separate compilation important? >>> I'm a little shocked that anyone on this list should have to ask >>> this >>> question. Two people have asked it now. >> >> Really? So you're using YHC then? It after all compiles *much* >> faster than GHC, but produces slower binaries. To be honest, ghc >> compiles things so fast (at least on any of my systems) that I >> couldn't care less if it took 10 times as long (I would however >> like some added convenience for that time spent) > > It's the ubiquitous "computers are fast enough today" argument. I > don't buy it. We don't have compile time to waste. There will always > be computers that are much slower and have less memory than the > current customer desktop computers, there are always tasks that a > computer can do instead of doing slowed down compilation. I'm glad > that we have overcome C's way of concatening all header files > together before starting compilation. If you don't want to be slowed down by the compiler, why aren't you writing machine code directly? The point is that time saved with convenience (often) comes at the cost of time spent while compiling. Adding an option to ghc to allow you to not waste time writing hi-boot files allows me to make an informed decision about whether it will take me longer to (a) figure out *how* to write an hi-boot file (b) actually do the writing, or if it'll take less time/effort to just let the compiler do it for me. Bob From cmb21 at kent.ac.uk Wed Aug 13 06:43:59 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Aug 13 06:43:18 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> Message-ID: Andrew, [...] > For the record, I have no problem with modules depending on each other, > so long as they only depend on their well-defined interfaces. > > > Finally, as chris suggests, if separate compilation is important to > > you, why not have a flag in ghc -frequire-hi-boot or something? > > Well, if I wanted separate header files, and the inevitable multiple- > maintenance headaches associated with them, I'd program in C. Except > for mutually recursive modules, GHC can and does generate header files > automatically, so I don't see why my time should be wasted doing the > job of a compiler. > > If something is preventing the compiler from doing that job, then that > something should be fixed. But isn't this exactly the point I was trying to make!? The whole point, to me, in functional programming, is that we shouldn't have to worry about the underlying implementation. What you've listed above are the restrictions of a particular compiler implementation. All of which, if needed, can be controlled by a flag if compilation performance is so important. Regards, Chris. From gale at sefer.org Wed Aug 13 06:56:10 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Aug 13 06:55:26 2008 Subject: [Haskell-cafe] Re: ``Orphan instances'' should be avoided anyway. In-Reply-To: References: <20080810200107.B5A303241BE@www.haskell.org> <638ABD0A29C8884A91BC5FB5C349B1C32AE8065EE6@EA-EXMSG-C334.europe.corp.microsoft.com> <20080812034824.1592.qmail@schroeder.cas.mcmaster.ca> <20080812173828.3155.qmail@schroeder.cas.mcmaster.ca> <1218562976.1523.20.camel@jcchost> <2608b8a80808121506j4e2bd234l5fa4a99bf551466c@mail.gmail.com> Message-ID: <2608b8a80808130356w3ea22f44w58e64952453443f3@mail.gmail.com> I wrote: >> ...there must be some >> way to control the import and export of instances, just as we can >> now control the import and export of every other kind of symbol >> binding. Henning Thielemann wrote: > For me it's most often the case that an instance is missing. > If there is no way to change existing instance definitions, > then you must use 'newtype'. Yes, in that case newtype is a work-around, often messy. > Generalized newtype deriving simplifies to adapt the instances you want. That's only one part of it. Using a newtype can sometimes spew wreckage all over the place. But a more difficult case is when you need to use two libraries that already define conflicting instances. That requires a newtype plus however many adaptor functions you need, all inside a wrapper module. What a mess. These cases are likely to arise most often in large software projects. So there hasn't been a big enough demand yet for this feature to be implemented in any compiler, resulting in it being rejected from Haskell', unfortunately. But for large projects it has to work the other way around - the language features need to be there already for the language to be adopted for the project. Or to keep project managers from cursing themselves later on if they do choose Haskell. Anyway, I find the current behavior to be ugly and unintuitive. Why is it that when I say import Control.Monad.Error (throwError, runErrorT) there is no way to prevent also getting a surprising Monad Either instance? Never mind how things should have been named in Control.Monad.Error - that's the way it is right now. I need to be able to import the module without getting the instance. Regards, Yitz From ajb at spamcop.net Wed Aug 13 07:03:45 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Aug 13 07:03:03 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> Message-ID: <20080813070345.ac6enx9wusss0w48-nwo@webmail.spamcop.net> G'day all. Quoting "C.M.Brown" : > But isn't this exactly the point I was trying to make!? The whole point, > to me, in functional programming, is that we shouldn't have to worry about > the underlying implementation. It is not exposing an underlying implementation detail to mandate that modules should have well-defined interfaces. If anything, it's enforcing good programming practice. Cheers, Andrew Bromage From cmb21 at kent.ac.uk Wed Aug 13 07:15:08 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Aug 13 07:14:26 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080813070345.ac6enx9wusss0w48-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <20080813070345.ac6enx9wusss0w48-nwo@webmail.spamcop.net> Message-ID: Andrew, > > But isn't this exactly the point I was trying to make!? The whole point, > > to me, in functional programming, is that we shouldn't have to worry about > > the underlying implementation. > > It is not exposing an underlying implementation detail to mandate that > modules should have well-defined interfaces. If anything, it's > enforcing good programming practice. I agree absolutely that having well-defined interfaces is a good thing. I wasn't actually referring to that, I apologise for not being clear. However I saw no real argument for not having cyclic inclusions. You say we shouldn't have to spend time writing hi-boot files, and yet you also think that GHC should not do it automatically. So we have to restrict all programmers to never writing cyclic inclusions? :) Kind Regards, Chris. From ajb at spamcop.net Wed Aug 13 07:18:01 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Aug 13 07:17:18 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> Message-ID: <20080813071801.sdpi584u80wg4c4o-nwo@webmail.spamcop.net> G'day all. Quoting Thomas Davie : > To be honest, ghc compiles things so fast (at least on any of > my systems) that I couldn't care less if it took 10 times as long (I would > however like some added convenience for that time spent) Have you ever compiled GHC itself? Just curious what you'd think about a 10x speed hit there. If it helps, think about the lifetime of a program. If you assume that a program grows linearly over time, and that recompilations occur at a roughly constant rate, it follows that the time spent recompiling is O(n^2). Constant factors matter. > If I compile a module on which lots of other modules depend, > I have to do lots of recompilation... If I compile a module which is in > a cyclic dependancy group, I have to do lots of recompilation, I don't > see that there's a difference here. If you only change the implementation of a module, not its interface, you don't need to recompile anything that imports it. (At least, this is true at -O0, which if you care about fast recompilation because you're deep in development, you're probably doing.) > That's a fair point about programming style, otoh, I don't think it's a > reason to restrict users to not using cyclic dependancies. As previously noted, cyclic dependencies alone aren't the problem. Cheers, Andrew Bromage From tom.davie at gmail.com Wed Aug 13 07:29:39 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Aug 13 07:29:13 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080813071801.sdpi584u80wg4c4o-nwo@webmail.spamcop.net> References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> <20080813071801.sdpi584u80wg4c4o-nwo@webmail.spamcop.net> Message-ID: <8BEBD43F-BA8F-4226-BCB1-D4D0753ED8A7@gmail.com> On 13 Aug 2008, at 13:18, ajb@spamcop.net wrote: > G'day all. > > Quoting Thomas Davie : > >> To be honest, ghc compiles things so fast (at least on any of >> my systems) that I couldn't care less if it took 10 times as long >> (I would >> however like some added convenience for that time spent) > > Have you ever compiled GHC itself? Just curious what you'd think > about > a 10x speed hit there. On the machine I'm sat at now, it takes 20 minutes. Secondly, you would *only* pay the speed penalty when you had cyclic includes, and you didn't use the flag to use an hi-boot file, so it would continue to take 20 minutes. > If it helps, think about the lifetime of a program. If you assume > that > a program grows linearly over time, and that recompilations occur at > a roughly constant rate, it follows that the time spent recompiling > is O(n^2). Constant factors matter. But the penalty would be no where near that big -- unless you happened to have *all* your modules depend on *all* other modules. >> If I compile a module on which lots of other modules depend, >> I have to do lots of recompilation... If I compile a module which >> is in >> a cyclic dependancy group, I have to do lots of recompilation, I >> don't >> see that there's a difference here. > > If you only change the implementation of a module, not its interface, > you don't need to recompile anything that imports it. (At least, this > is true at -O0, which if you care about fast recompilation because > you're deep in development, you're probably doing.) Well, if this turned out to take a long time, then I'd probably switch to writing an hi-boot file... Something that I wouldn't have to waste time doing at all if it happened that ghc was still "fast enough" without providing one. Bob From ajb at spamcop.net Wed Aug 13 07:30:27 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Aug 13 07:29:43 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <20080813070345.ac6enx9wusss0w48-nwo@webmail.spamcop.net> Message-ID: <20080813073027.3unz5stofzokw084-nwo@webmail.spamcop.net> G'day. Quoting "C.M.Brown" : > However I saw no real argument for not having cyclic inclusions. You > say we shouldn't have to spend time writing hi-boot files, and yet > you also think > that GHC should not do it automatically. So we have to restrict all > programmers to never writing cyclic inclusions? :) GHC generates .hi files for most modules automatically. The only reason why hi-boot files are needed for cyclic imports is because of the possibility that you can't generate a .hi file from the module alone. If you could do that, then you could support cyclic imports without needing hi-boot files. Cheers, Andrew Bromage From duncan.coutts at worc.ox.ac.uk Wed Aug 13 08:04:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 13 08:02:47 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: Message-ID: <1218629064.7661.526.camel@localhost> On Tue, 2008-08-12 at 14:13 -1000, Tim Newsham wrote: > I also noticed another issue while testing. If my program loads > the data at startup by calling loadState then all later calls to > saveState give an error: > > Log: savedState.bin: openFile: resource busy (file is locked) You're not using an old version of bytestring are you, anything older than 0.9.0.4? We had a bug where the handle was not closed as soon as we got to the end of the stream, so even forcing the whole input didn't help. Duncan From tittoassini at gmail.com Wed Aug 13 09:25:35 2008 From: tittoassini at gmail.com (Titto Assini) Date: Wed Aug 13 09:24:52 2008 Subject: [Haskell-cafe] The Italian Haskellers Summer Meeting is Over: What Next? Message-ID: <2d34474e0808130625x44a1e1edr10e165b35fa388c6@mail.gmail.com> E cosi' il primo incontro balnear/ricreativo degli Haskeller Italiani si e' felicemente concluso. Come da programma, rigidamente rispettato, abbiamo fatto il bagno e mangiato pizza e gelato ma soprattutto ci siamo conosciuti ed abbiamo discusso di tutto e di piu', prevalentemente Haskell (folds, arrows, happs, sviluppo web) ma non solo (democrazia elettronica, la crisi economica, mercato ed autosufficienza). Non si puo' dire che l'affluenza sia stata oceanica ma non dimentichiamo che con 3 persone si puo' fare una cellula rivoluzionaria e con una cellula rivoluzionaria si puo' cominciare a pensare a fare la rivoluzione :-) Insomma e' stato piacevole ed utile e lo riorganizzeremo certamente il prossimo anno. Ed adesso? E' evidente, dobbiamo organizzare un incontro invernale, sullo stile di AngloHaskell, per presentare e discutere progetti di sviluppo, idee per futuri progetti ed iniziative che possano servire a rafforzare ed estendere la comunita' Haskell Italiana. Interessati? Date uno sguardo a http://www.haskell.org/haskellwiki/ItaloHaskell Saluti, titto -- Pasqualino "Titto" Assini, Ph.D. 25 Heath Road - CO79PT Wivenhoe - Colchester - U.K. From lemming at henning-thielemann.de Wed Aug 13 09:51:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Aug 13 09:51:14 2008 Subject: [Haskell-cafe] Re: ``Orphan instances'' should be avoided anyway. In-Reply-To: <2608b8a80808130356w3ea22f44w58e64952453443f3@mail.gmail.com> References: <20080810200107.B5A303241BE@www.haskell.org> <638ABD0A29C8884A91BC5FB5C349B1C32AE8065EE6@EA-EXMSG-C334.europe.corp.microsoft.com> <20080812034824.1592.qmail@schroeder.cas.mcmaster.ca> <20080812173828.3155.qmail@schroeder.cas.mcmaster.ca> <1218562976.1523.20.camel@jcchost> <2608b8a80808121506j4e2bd234l5fa4a99bf551466c@mail.gmail.com> <2608b8a80808130356w3ea22f44w58e64952453443f3@mail.gmail.com> Message-ID: On Wed, 13 Aug 2008, Yitzchak Gale wrote: > Why is it that when I say > > import Control.Monad.Error (throwError, runErrorT) > > there is no way to prevent also getting a surprising Monad Either > instance? Never mind how things should have been named > in Control.Monad.Error - that's the way it is right now. I need to > be able to import the module without getting the instance. Indeed, the instances that are imported without request contradict to the module concept. In case of Control.Monad.Error I suggest to give http://darcs.haskell.org/explicit-exception/src/Control/Monad/Exception/Synchronous.hs a try. I'm working on it as counter-proposal to the extensible extension proposal. This module defines exceptions without abusing the Either type. From byorgey at seas.upenn.edu Wed Aug 13 11:27:50 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Aug 13 11:27:07 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 81 - August 13, 2008 Message-ID: <20080813152750.GA14379@minus.seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20080813 Issue 81 - August 13, 2008 --------------------------------------------------------------------------- Welcome to issue 81 of HWN, a newsletter covering developments in the [1]Haskell community. This week saw some interesting talks at [2]AngloHaskell, and some cool new packages to hit Hackage, like [3]Language.C, [4]AERN-Real, [5]FTGL, and [6]Hoogle. What are you waiting for? Get out there and build something! Announcements Initial release of Language.C (language-c-0.3). Benedikt Huber [7]announced the [8]first release of [9]Language.C, a library for analysing and generating C code. This release features a reasonably well tested parser, a pretty printer, and a preview of the analysis framework. darcs roadmap. Jason Dagit [10]wrote to the list to thank everyone for their support for darcs, and to announce a webpage with a [11]roadmap for future darcs features. Darcs is alive and well! Anglo Haskell 2008 -- slides and audio. Matthew Sackman [12]announced that [13]slides and audio from Anglo Haskell 2008 are now available. BLAS bindings for haskell, version 0.5. Patrick Perry [14]announced a new release of the Haskell BLAS bindings, including a number of new features and improvements. Tutorial on information visualization and visual analytics in Haskell. Jefferson Heard [15]announced the [16]tutorial he will be presenting at DEFUN 2008, to give everyone a sneak peek at the long version of the tutorial before he's done with it. Comments and questions are welcome and encouraged. interval and polynomial enclosure arithmetics. Michal Konecny [17]announced the release of the [18]AERN-Real and [19]AERN-RnToRm packages, which model and reasonably efficiently implement exact real arithmetic. FTGL 1.0. Portable truetype font rendering in OpenGL. Jefferson Heard [20]announced the release of [21]Haskell bindings to FTGL, an easy to use library for portable rendering of TrueType fonts in OpenGL. Google Summer of Code Progress updates from participants in the 2008 [22]Google Summer of Code. GHC plugins. Max Bolingbroke is working on dynamically loaded plugins for GHC. [23]This week, he gave [24]a talk at AngloHaskell. Language.C. Benedikt Huber (visq) is [25]working on Language.C, a standalone parser/pretty printer library for C99. This week, he [26]announced the [27]first release of the [28]Language.C package. Hoogle 4. Neil Mitchell (ndm) is working on [29]Hoogle 4. [30]This week, he released several [31]command-line versions and a [32]web version of Hoogle 4, updated the manual, and gave [33]a talk at AngloHaskell. Next week, he plans to work on generating better Hoogle databases, and some bug fixes. DPH physics engine. Roman Cheplyaka (Feuerbach) is working on a [34]physics engine using [35]Data Parallel Haskell. [36]This week, he added complete support for general polyhedra, and fixed some bugs in the collision handler. He also added support for bounding spheres, although the results so far are disappointing, due to delays in the GHC implementation of parallel arrays. Next week, he plans to implement static bodies and BSP trees. Generic tries. Jamie Brandon is working on a library for efficient maps using generalized tries. GHC API. Thomas Schilling (nominolo) is working on [37]improvements to the GHC API. Cabal dependency framework. Andrea Vezzosi (Saizan) is working on a [38]make-like dependency analysis framework for Cabal. Blog noise [39]Haskell news from the [40]blogosphere. * >>> Nicholas Lativy: [41]Haskell in less than five minutes. Nicholas refreshes his memory of Haskell. * Douglas M. Auclair (geophf): [42]Monoid use. * Roman Cheplyaka: [43]Status report: week 11-12. * Douglas M. Auclair (geophf): [44]Combinatory Birds as Types. * Douglas M. Auclair (geophf): [45]Getting Better, part ][. * Neil Mitchell: [46]GSoC Hoogle: Week 11. * Max Bolingbroke: [47]Compiler Plugins AngloHaskell Talk. * London Haskell Users Group: [48]Video: Paradise, a DSEL for Derivatives Pricing. * Roman Cheplyaka (Feuerbach): [49]Compiling GHC. Roman records his experiences building the latest development version of GHC. * Luke Palmer: [50]Mindfuck: The Reverse State Monad. * Dan Piponi (sigfpe): [51]Untangling with Continued Fractions: Part 0. * Joachim Breitner: [52]Xmonad on my mobile phone. * Luke Palmer: [53]Composable Input for Fruit. * >>> Louis: [54]A Gentle Introduction to Haskell. Louis is learning Haskell by working through the Gentle Introduction. * >>> Bryan St. Amour: [55]Some Project Euler. Bryan learns some Haskell the good old-fashioned way---by solving Project Euler problems. * Magnus Therning: [56]TagSoup, meet Parsec!. Magnus uses Parsec to parse streams of tags. * Thomas M. DuBuisson: [57]hsXenCtrl and pureMD5. * Alpheccar: [58]Haskell, iPhone and Biotech. * >>> codeflow: [59]About AI and neural networks. codeflow implements neural networks in Haskell for some soccer-playing AI software. * >>> Vincent Kriek: [60]And the winner is.... Vincent decides to stick with xmonad. * >>> Matthew Trinneer: [61]A New Paradigm - Haskell and HAppS. Quotes of the Week * Anatoly Yakovenko: theory doesn't scare me. i am using haskell after all, so i am used to reading long winded papers. * bwr: mapM_ putStrLn$reverse[(++)([1..y-30]>>" ")$concat$map([" "," /", " -", " \\"]!!)[(foldr(.)(scanl(+)1)([1..y]>>[scanl(+)0])[2..]!!(2*(1+y)+x) )`mod`4|x<-[-y-2..59-y*2]]|y<-[30..61]] About the Haskell Weekly News New editions are posted to [62]the Haskell mailing list as well as to [63]the Haskell Sequence and [64]Planet Haskell. [65]RSS is also available, and headlines appear on [66]haskell.org. To help create new editions of this newsletter, please see the information on [67]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [68]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://www.wellquite.org/anglohaskell2008/ 3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/language%2Dc 4. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AERN-Real 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FTGL 6. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hoogle 7. http://article.gmane.org/gmane.comp.lang.haskell.libraries/9809 8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/language%2Dc 9. http://www.sivity.net/projects/language.c 10. http://www.haskell.org//pipermail/haskell-cafe/2008-August/045959.html 11. http://wiki.darcs.net/DarcsWiki/Roadmap 12. http://www.haskell.org//pipermail/haskell-cafe/2008-August/045986.html 13. http://www.wellquite.org/anglohaskell2008/ 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43036 15. http://article.gmane.org/gmane.comp.lang.haskell.cafe/42994 16. http://bluheron.europa.renci.org/docs/BeautifulCode.pdf 17. http://article.gmane.org/gmane.comp.lang.haskell.general/16368 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AERN-Real 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AERN-RnToRm 20. http://article.gmane.org/gmane.comp.lang.haskell.cafe/42955 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FTGL 22. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 23. http://blog.omega-prime.co.uk/2008/08/11/compiler-plugins-anglohaskell-talk/ 24. http://www.wellquite.org/anglohaskell2008/ 25. http://www.sivity.net/projects/language.c/wiki/ 26. http://article.gmane.org/gmane.comp.lang.haskell.libraries/9809 27. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/language%2Dc 28. http://www.sivity.net/projects/language.c 29. http://code.haskell.org/hoogle/ 30. http://neilmitchell.blogspot.com/2008/08/gsoc-hoogle-week-11.html 31. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hoogle 32. http://haskell.org/hoogle/beta/ 33. http://www.wellquite.org/anglohaskell2008/ 34. http://haskell.org/haskellwiki/Hpysics 35. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell 36. http://physics-dph.blogspot.com/2008/08/status-report-week-11-12.html 37. http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus 38. http://code.haskell.org/~Saizan/cabal 39. http://planet.haskell.org/ 40. http://haskell.org/haskellwiki/Blog_articles 41. http://blog.lativy.org/2008/08/13/haskell-in-less-than-five-minutes/ 42. http://logicaltypes.blogspot.com/2008/05/monoid-use.html 43. http://physics-dph.blogspot.com/2008/08/status-report-week-11-12.html 44. http://logicaltypes.blogspot.com/2008/08/combinatory-birds-as-types.html 45. http://logicaltypes.blogspot.com/2008/08/getting-better-part.html 46. http://neilmitchell.blogspot.com/2008/08/gsoc-hoogle-week-11.html 47. http://blog.omega-prime.co.uk/2008/08/11/compiler-plugins-anglohaskell-talk/ 48. http://www.londonhug.net/2008/08/11/video-paradise-a-dsel-for-derivatives-pricing/ 49. http://ro-che.blogspot.com/2008/08/compiling-ghc.html 50. http://luqui.org/blog/archives/2008/08/10/mindfuck-the-reverse-state-monad/ 51. http://sigfpe.blogspot.com/2008/08/untangling-with-continued-fractions.html 52. https://www.joachim-breitner.de/blog/archives/300-Xmonad-on-my-mobile-phone.html 53. http://luqui.org/blog/archives/2008/08/09/composable-input-for-fruit/ 54. http://lbks23.wordpress.com/2008/08/09/a-gentle-introduction-to-haskell/ 55. http://bryanstamour.com/?p=46 56. http://therning.org/magnus/archives/367 57. http://tommd.wordpress.com/2008/08/07/hsxenctrl-and-puremd5/ 58. http://www.alpheccar.org/en/posts/show/92 59. http://codeflow.wordpress.com/2008/08/03/about-ai-and-neural-networks/ 60. http://www.vincentkriek.nl/post/and-the-winner-is/ 61. http://thespohtexperiment.blogspot.com/2008/08/new-paradigm.html 62. http://www.haskell.org/mailman/listinfo/haskell 63. http://sequence.complete.org/ 64. http://planet.haskell.org/ 65. http://sequence.complete.org/node/feed 66. http://haskell.org/ 67. http://haskell.org/haskellwiki/HWN 68. http://code.haskell.org/~byorgey/code/hwn/ From jason.dusek at gmail.com Wed Aug 13 14:27:57 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 13 14:27:13 2008 Subject: [Haskell-cafe] whatever happened to sendFile? Message-ID: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> I found an old lib for it: http://www.haskell.org/ghc/docs/6.0/html/unix/System.Sendfile.html Hoogle turns up nothing, though. -- _jsn From iavor.diatchki at gmail.com Wed Aug 13 14:46:44 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Aug 13 14:46:02 2008 Subject: [Haskell-cafe] Cyclic Inclusions In-Reply-To: <20080813073027.3unz5stofzokw084-nwo@webmail.spamcop.net> References: <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <20080813070345.ac6enx9wusss0w48-nwo@webmail.spamcop.net> <20080813073027.3unz5stofzokw084-nwo@webmail.spamcop.net> Message-ID: <5ab17e790808131146h60977111k4e4f7c99eb194e72@mail.gmail.com> Hello, The Haskell'98 report does not specify if/how recursive modules should work. I wrote a paper a long time ago that formalizes and implements this feature (http://www.purely-functional.net/yav/publications/modules98.pdf). I very much doubt that separate compilation is much of a problem in practise because you only need to compile modules that are _recursive_ at the same time, and usually these tend to be fairly small. Figuring out the interface of the modules is a bit trickier in some pathological cases involving module re-exports, but this is already the case with non-recursive modules. One real technical problem that I remember was implementing "defaulting", which is specified in terms of a single module. With recursive modules, one could get mutually recursive functions from different modules, in which case it is not clear which set of defaulting rules to apply or how to combine them. Hope that this helps, -Iavor On Wed, Aug 13, 2008 at 4:30 AM, wrote: > G'day. > > Quoting "C.M.Brown" : > >> However I saw no real argument for not having cyclic inclusions. You >> say we shouldn't have to spend time writing hi-boot files, and yet you >> also think >> that GHC should not do it automatically. So we have to restrict all >> programmers to never writing cyclic inclusions? :) > > GHC generates .hi files for most modules automatically. The only reason > why hi-boot files are needed for cyclic imports is because of the > possibility that you can't generate a .hi file from the module alone. If > you could do that, then you could support cyclic imports without needing > hi-boot files. > > Cheers, > Andrew Bromage > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From chaddai.fouche at gmail.com Wed Aug 13 15:01:55 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Wed Aug 13 15:01:25 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> Message-ID: 2008/8/13 Jason Dusek : > I found an old lib for it: > > http://www.haskell.org/ghc/docs/6.0/html/unix/System.Sendfile.html > > Hoogle turns up nothing, though. > That don't sound very useful... Maybe when we only had String it was much more performant for big transfert, but now we can recode this in one short line of ByteString code and get the same performance as C. -- Jeda? From allbery at ece.cmu.edu Wed Aug 13 15:04:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 13 15:03:32 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> Message-ID: <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> On 2008 Aug 13, at 15:01, Chadda? Fouch? wrote: > 2008/8/13 Jason Dusek : >> I found an old lib for it: >> >> http://www.haskell.org/ghc/docs/6.0/html/unix/System.Sendfile.html >> >> Hoogle turns up nothing, though. >> > > That don't sound very useful... Maybe when we only had String it was > much more performant for big transfert, but now we can recode this in > one short line of ByteString code and get the same performance as C. sendfile() is actually a system call, not a library function. -- 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 jason.dusek at gmail.com Wed Aug 13 15:06:15 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 13 15:05:31 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> Message-ID: <42784f260808131206q1632db5s7239263c3a5579c4@mail.gmail.com> Chadda? Fouch? wrote: > Maybe when we only had String it was much more performant for > big transfert, but now we can recode this in one short line of > ByteString code and get the same performance as C. Oh? Using lazy ByteString? -- _jsn From allbery at ece.cmu.edu Wed Aug 13 15:17:49 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 13 15:17:08 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> Message-ID: <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> On 2008 Aug 13, at 15:04, Brandon S. Allbery KF8NH wrote: > > On 2008 Aug 13, at 15:01, Chadda? Fouch? wrote: > >> 2008/8/13 Jason Dusek : >>> I found an old lib for it: >>> >>> http://www.haskell.org/ghc/docs/6.0/html/unix/System.Sendfile.html >>> >>> Hoogle turns up nothing, though. >> >> That don't sound very useful... Maybe when we only had String it was >> much more performant for big transfert, but now we can recode this in >> one short line of ByteString code and get the same performance as C. > > sendfile() is actually a system call, not a library function. I should clarify: what sendfile() is supposed to optimize isn't writing large strings, or even the user<->kernel roundtrips; it's an optimization to the kernel network stack (network buffer management, to be specific). Web servers use it to serve static content (e.g. icons, images, stylesheets) because it significantly reduces system load. -- 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 chaddai.fouche at gmail.com Wed Aug 13 15:26:40 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Wed Aug 13 15:25:57 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> Message-ID: 2008/8/13 Brandon S. Allbery KF8NH : > > I should clarify: what sendfile() is supposed to optimize isn't writing > large strings, or even the user<->kernel roundtrips; it's an optimization to > the kernel network stack (network buffer management, to be specific). Web > servers use it to serve static content (e.g. icons, images, stylesheets) > because it significantly reduces system load. > Ok, so it could still be useful in a restricted area (but then it should be easy to write a FFI wrapper for it anyway). -- Jeda? From allbery at ece.cmu.edu Wed Aug 13 15:49:24 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 13 15:48:44 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> Message-ID: <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> On 2008 Aug 13, at 15:26, Chadda? Fouch? wrote: > 2008/8/13 Brandon S. Allbery KF8NH : >> >> I should clarify: what sendfile() is supposed to optimize isn't >> writing >> large strings, or even the user<->kernel roundtrips; it's an >> optimization to >> the kernel network stack (network buffer management, to be >> specific). Web >> servers use it to serve static content (e.g. icons, images, >> stylesheets) >> because it significantly reduces system load. >> > > Ok, so it could still be useful in a restricted area (but then it > should be easy to write a FFI wrapper for it anyway). Right. I intended that to be a heads-up in both directions: it is not simply a library convenience function, so one needs to think about when to use it. In particular, it's possible that overuse of sendfile() in the wrong circumstances will create additional system load instead of reducing it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jason.dusek at gmail.com Wed Aug 13 15:52:32 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 13 15:51:49 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> Message-ID: <42784f260808131252hc9ed62do5a6b7f59fa0d1876@mail.gmail.com> Brandon S. Allbery KF8NH wrote: > I should clarify: what sendfile() is supposed to optimize > isn't writing large strings, or even the user<->kernel > roundtrips; it's an optimization to the kernel network stack > (network buffer management, to be specific). Web servers use > it to serve static content (e.g. icons, images, stylesheets) > because it significantly reduces system load. Indeed, and it my intention to use it for just this purpose -- serving numerous large images from a Haskell network server. However -- and here is the weird part -- it needs to work on Windows as well, because the server must be able to run locally for clients. -- _jsn From newsham at lava.net Wed Aug 13 15:56:53 2008 From: newsham at lava.net (Tim Newsham) Date: Wed Aug 13 15:56:24 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080813044314.GB3743@scytale.galois.com> References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: > Ah, that would be a bug in older ByteString implementations, that were a > bit incautious about closing handles. This example works for me with > > bytestring-0.9.1.0 Yup, thank you Don and Duncan for pointing this out. I updated my bytestring library and the test case no longer fails. However, I'm still having problems and not sure why. I was able to distill the problem down to this: $ od -x 1word32.bin 0000000 0500 2ca4 $ runhaskell test6.hs loading... saving... test6.hs: 1word32.bin: openFile: resource busy (file is locked) $ cat test6.hs module Main where import Control.Applicative import Control.Parallel.Strategies (rnf, NFData, using) import Data.Binary import qualified Data.ByteString.Lazy.Char8 as B import Data.Word stateFile = "1word32.bin" loadState :: IO Word32 loadState = decode <$> B.readFile stateFile saveState :: Word32 -> IO () saveState db = B.writeFile stateFile $ encode db {- -- Works! loadState = B.readFile stateFile saveState = B.writeFile stateFile -} -- force x = print x >> return x force = return . (`using` rnf) main = do putStrLn "loading..." d <- force =<< loadState putStrLn "saving..." saveState d I tried this both with "print" and "rnf" to the same effect. It looks like there still might be some situations where the file isn't being closed? Should the file be closed when the last byte is read (in this case its definitely reading all four bytes) or when the first byte after that is read (in this case it probably doesn't attempt to read more than 4 bytes)? Tim Newsham http://www.thenewsh.com/~newsham/ From shoulders at yahoo.cn Mon Aug 11 04:38:24 2008 From: shoulders at yahoo.cn (shoulders) Date: Wed Aug 13 17:00:27 2008 Subject: [Haskell-cafe] help Message-ID: <52284.81229.qm@web92101.mail.cnh.yahoo.com> --------------------------------- ÑÅ»¢ÓÊÏ䣬ÄúµÄÖÕÉúÓÊÏ䣡 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080811/a3f76193/attachment.htm From andrewcoppin at btinternet.com Mon Aug 11 12:32:46 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Aug 13 17:00:36 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <349654066.20080808215650@gmail.com> References: <4899E8E7.6090000@btinternet.com> <349654066.20080808215650@gmail.com> Message-ID: <48A069AE.40706@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Wednesday, August 6, 2008, 10:09:43 PM, you wrote: > > >> Here's the thing though... How do I get it so that "Foo Int" and "Foo >> Double" produce slightly different strings when printed? >> > > instnace Show (Foo Int) ... > instnace Show (Foo Double) ... > ...WHY did I not think of this myself? o_O From andrewcoppin at btinternet.com Wed Aug 13 16:58:38 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Aug 13 17:00:42 2008 Subject: [Haskell-cafe] What's in a name? Message-ID: <48A34AFE.9000106@btinternet.com> The naming of cats is a difficult matter... Ahem. So as you may have noticed, we seem to have a profusion of packages all called "binary" or something dangeriously similar. There's also several "MD5" packages. I could point out a few others. So what I'm wondering is... Do we have a formal convention for the naming of packages and/or the naming of the modules they contain? How are name collisions supposed to be avoided? (E.g., Java uses domain names for this. If I write a package named Foo, I put all the classes in orphi.me.uk.Foo.*) From ryani.spam at gmail.com Wed Aug 13 17:28:58 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Aug 13 17:28:15 2008 Subject: [Haskell-cafe] "Prompt" Monad In-Reply-To: <1218609148.6180.1.camel@ios.cogsys.wiai.uni-bamberg.de> References: <1218545406.5947.14.camel@ios.cogsys.wiai.uni-bamberg.de> <2f9b2d30808121028p3909228ep1de0ad9d2a86a5c5@mail.gmail.com> <1218609148.6180.1.camel@ios.cogsys.wiai.uni-bamberg.de> Message-ID: <2f9b2d30808131428l591932f8he9be2d744fbb7b9@mail.gmail.com> No problem. Let me know what you end up doing with it, or if you have any questions! -- ryan On Tue, Aug 12, 2008 at 11:32 PM, Martin Hofmann wrote: > Thanks a lot. That is exactly what I have been looking for. > > > Cheers, > > Martin > > > On Tue, 2008-08-12 at 10:28 -0700, Ryan Ingram wrote: >> Latest code is on hackage: >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt >> >> There is a "sample" file with lots of other monads implemented in >> terms of Prompt included, along with some links to other samples; I >> seem to recall there being a "guess a number" game on paste.lisp.org >> that used Prompt to switch between user control and AI control. >> >> Let me know if you have any problems building it and I'll patch it up. >> >> -- ryan >> >> On Tue, Aug 12, 2008 at 5:50 AM, Martin Hofmann >> wrote: >> > I just came across last year's thread about Ryan Ingram's "Prompt" monad >> > ( http://www.mail-archive.com/haskell-cafe@haskell.org/msg33040.html ) >> > and wondered if it might be useful for debugging and program analysis >> > purposes. In particular, I thought about enforcing program decisions >> > interactively. Consider for example modifying the heuristic function of >> > a search algorithm at specific breakpoints. >> > >> > Is this possible with the "Prompt" monad? Furthermore, could somebody >> > post the full code of it (and maybe a short example how to use it if at >> > hand)? I was not able to run the code from the previous posts and the >> > referring links are dead. >> > >> > Thanks a lot, >> > >> > Martin >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -- > --------------------------------------------------------------- > Dipl.-Wirtsch.Inf. (E.M.B.Sc.) Martin Hofmann? > Cognitive Systems Group > Faculty Information Systems and Applied Computer Science > University of Bamberg > http://www.cogsys.wiai.uni-bamberg.de/members/hofmann > http://www.inductive-programming.org > > > From newsham at lava.net Wed Aug 13 18:02:31 2008 From: newsham at lava.net (Tim Newsham) Date: Wed Aug 13 18:01:47 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: > Should the file be closed when the last byte is read (in this > case its definitely reading all four bytes) or when the first > byte after that is read (in this case it probably doesn't > attempt to read more than 4 bytes)? I'll answer my own question. Both Prelude.readFile and Data.ByteString.Lazy.Char8.readFile will keep the file open after reading the last byte and close it when trying to read further. Proof: module Main where import Control.Applicative -- import qualified Data.ByteString.Lazy.Char8 as B import Prelude as B stateFile = "1word32.bin" main = do x <- B.take 4 <$> B.readFile stateFile -- x <- B.take 5 <$> B.readFile stateFile print x B.writeFile stateFile x This works for Prelude and ByteString when taking 5 (there are exactly 4 bytes in "1word32.bin") and fail when taking 4. I'm not sure that this behavior is so bad.. there might be some advantages... but it might be nice to have it close after the last byte is read... However, I think probably the real blame here should probably go to Data.Binary which doesn't attempt to check that it has consumed all of its input after doing a "decode". If "decode" completes and there is unconsumed data, it should probably raise an error (it already raises errors for premature EOF). There's no reason for it not to, since it does not provide the unconsumed data to the caller when its done, anyway... Thoughts? Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Wed Aug 13 18:03:43 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 13 18:02:57 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: <20080813220343.GA7429@scytale.galois.com> newsham: > >Should the file be closed when the last byte is read (in this > >case its definitely reading all four bytes) or when the first > >byte after that is read (in this case it probably doesn't > >attempt to read more than 4 bytes)? > > I'll answer my own question. Both Prelude.readFile and > Data.ByteString.Lazy.Char8.readFile will keep the file open > after reading the last byte and close it when trying to > read further. Proof: > > module Main where > import Control.Applicative > -- import qualified Data.ByteString.Lazy.Char8 as B > import Prelude as B > > stateFile = "1word32.bin" > main = do > x <- B.take 4 <$> B.readFile stateFile > -- x <- B.take 5 <$> B.readFile stateFile > print x > B.writeFile stateFile x > > This works for Prelude and ByteString when taking 5 (there are > exactly 4 bytes in "1word32.bin") and fail when taking 4. > > I'm not sure that this behavior is so bad.. there might be some > advantages... but it might be nice to have it close after the last > byte is read... > > However, I think probably the real blame here should probably go > to Data.Binary which doesn't attempt to check that it has consumed > all of its input after doing a "decode". If "decode" completes > and there is unconsumed data, it should probably raise an error > (it already raises errors for premature EOF). There's no reason > for it not to, since it does not provide the unconsumed data to > the caller when its done, anyway... > This is perhaps a use case for Data.Binary.Strict then. -- Don From thomas.dubuisson at gmail.com Wed Aug 13 18:13:03 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Wed Aug 13 18:12:18 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A34AFE.9000106@btinternet.com> References: <48A34AFE.9000106@btinternet.com> Message-ID: <1218665583.5981.10.camel@tom-laptop> > Do we have a formal convention for the naming of > packages and/or the naming of the modules they contain? There is a recommended set of categories and in general I believe library authors try and follow the previously established names. > How are name > collisions supposed to be avoided? In the case of pureMD5 I looked at the other modules and decided to name mine something with a proper hierarchy that doesn't collide with 'Crypto'. Hence the extra "Pure" part of the module name. I believe that an informal process, such as what I did, is much better than formalizing every aspect of Haskell/Hackage libraries. The cost in terms of processes / bureaucracy are just too much to formalize everything. Suggestion: Have Hackage warn when a library is uploaded that has Module conflicts with other libraries. Thomas From jason.dusek at gmail.com Wed Aug 13 18:25:46 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 13 18:25:02 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> Message-ID: <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> Brandon S. Allbery KF8NH wrote: > Right. I intended that to be a heads-up in both directions: > it is not simply a library convenience function, so one needs > to think about when to use it. In particular, it's possible > that overuse of sendfile() in the wrong circumstances will > create additional system load instead of reducing it. Can you say more about this? I assume that sending static images back and forth is a good fit for sendfile(). -- _jsn From allbery at ece.cmu.edu Wed Aug 13 18:29:47 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 13 18:29:05 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> Message-ID: <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> On 2008 Aug 13, at 18:25, Jason Dusek wrote: > Brandon S. Allbery KF8NH wrote: >> Right. I intended that to be a heads-up in both directions: >> it is not simply a library convenience function, so one needs >> to think about when to use it. In particular, it's possible >> that overuse of sendfile() in the wrong circumstances will >> create additional system load instead of reducing it. > > Can you say more about this? I assume that sending static > images back and forth is a good fit for sendfile(). Your previously stated use case sounds like a good fit. I can easily imagine sendfile() implementations starving other network operations, though (and IIRC linux's early sendfile() implementation did so). It's essentially an optimization specific to web servers. -- 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 jason.dusek at gmail.com Wed Aug 13 18:40:43 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 13 18:39:58 2008 Subject: [Haskell-cafe] Re: whatever happened to sendFile? In-Reply-To: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> Message-ID: <42784f260808131540u397c8c0j18b1d24e09545014@mail.gmail.com> It looks like there could be a Haskell sendfile for Windows as as well *NIX. However, the *NIX implementations are: :: File Descriptor -> File Descriptor -> IO () while the Windows version is: :: File Descriptor -> Socket -> IO () A cross platfrom implementation would cover the case we most care about -- writing services that pass static files back to clients -- but would have to cut some functionality from the *NIX sendfile(). |...for Windows...| http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.sendfile.aspx -- _jsn From john at repetae.net Wed Aug 13 18:47:34 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 13 18:46:52 2008 Subject: [Haskell-cafe] Re: whatever happened to sendFile? In-Reply-To: <42784f260808131540u397c8c0j18b1d24e09545014@mail.gmail.com> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <42784f260808131540u397c8c0j18b1d24e09545014@mail.gmail.com> Message-ID: <20080813224734.GI11895@sliver.repetae.net> On Wed, Aug 13, 2008 at 03:40:43PM -0700, Jason Dusek wrote: > A cross platfrom implementation would cover the case we most > care about -- writing services that pass static files back to > clients -- but would have to cut some functionality from the > *NIX sendfile(). There isn't a standard unix sendfile, while a few different ones have functions called 'sendfile', they have different meanings/prototypes in general. If 'sendfile(2)' is going to be exposed, it should be in a low level platform specific library, however, since you are dealing with deciding to use unportable behavior, it is hard to see what this will gain over a manual FFI wrapper. John -- John Meacham - ?repetae.net?john? From jason.dusek at gmail.com Wed Aug 13 19:02:39 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 13 19:01:57 2008 Subject: [Haskell-cafe] Re: whatever happened to sendFile? In-Reply-To: <20080813224734.GI11895@sliver.repetae.net> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <42784f260808131540u397c8c0j18b1d24e09545014@mail.gmail.com> <20080813224734.GI11895@sliver.repetae.net> Message-ID: <42784f260808131602w6ed52b9bi4b29196b137ff230@mail.gmail.com> John Meacham wrote: > There isn't a standard unix sendfile, while a few different > ones have functions called 'sendfile', they have different > meanings/prototypes in general. If 'sendfile(2)' is going to > be exposed, it should be in a low level platform specific > library, however, since you are dealing with deciding to use > unportable behavior, it is hard to see what this will gain > over a manual FFI wrapper. Well, for my purposes, I need to have at least three of them -- Linux, Darwin (BSD) and Windows. However, I think you are ultimately right, the heterogenity of sendfile() suggests that one should not stomp all over it with yet another variant. Maybe a reasonable compromise is a function that is more limited by design, with a distinctive name -- `fileSock`? -- that offers access to a universal subset of the functionality of sendfile() -- namely, pushing a file's contents over a socket efficiently. -- _jsn From patperry at stanford.edu Wed Aug 13 19:19:06 2008 From: patperry at stanford.edu (Patrick Perry) Date: Wed Aug 13 19:18:24 2008 Subject: [Haskell-cafe] Bug with QuickCheck 1.1 and GHC 6.8.2 Message-ID: I'm running into problems with generating an arbitrary function of type Double -> Double. Specifically, the following code: {-# LANGUAGE PatternSignatures #-} import Test.QuickCheck import Text.Show.Functions prop_ok (f :: Double -> Double) = f (-5.5) `seq` True prop_bug (f :: Double -> Double) = f (-5.6) `seq` True main = do putStr "prop_ok:\t" >> quickCheck prop_ok putStr "prop_bug:\t" >> quickCheck prop_bug On an Intel Core 2 Duo running Mac OS 10.5.4 with GHC 6.8.2 the output I get is prop_ok: OK, passed 100 tests. prop_bug: Test: Prelude.(!!): negative index On Intel Xeon running RedHat with GHC 6.8.2 both tests hang. Has anyone seen this before? Is it fixed in QuickCheck2? Thanks, Patrick From aslatter at gmail.com Wed Aug 13 19:30:45 2008 From: aslatter at gmail.com (Antoine Latter) Date: Wed Aug 13 19:30:01 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: <694519c50808131630w7fd7b0bye12ee40f60ecfa0f@mail.gmail.com> On Wed, Aug 13, 2008 at 5:02 PM, Tim Newsham wrote: > > However, I think probably the real blame here should probably go > to Data.Binary which doesn't attempt to check that it has consumed > all of its input after doing a "decode". If "decode" completes > and there is unconsumed data, it should probably raise an error > (it already raises errors for premature EOF). There's no reason > for it not to, since it does not provide the unconsumed data to > the caller when its done, anyway... > Would the error be raised in 'decode' or in 'runGet'? On a project in progress I rely on 'runGet' to toss out padding bytes for me. -Antoine From patperry at stanford.edu Wed Aug 13 19:58:53 2008 From: patperry at stanford.edu (Patrick Perry) Date: Wed Aug 13 19:58:10 2008 Subject: [Haskell-cafe] Bug with QuickCheck 1.1 and GHC 6.8.2 Message-ID: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> The bug is in the "variant" function in QuickCheck. I replaced variant :: Int -> Gen a -> Gen a variant v (Gen m) = Gen (\n r -> m n (rands r !! (v+1)) where rands r0 = r1 : rands r2 where (r1, r2) = split r0 with variant :: Int -> Gen a -> Gen a variant v (Gen m) = Gen (\n r -> m n (rands r !! v')) where v' = abs (v+1) `mod` 10000 rands r0 = r1 : rands r2 where (r1, r2) = split r0 and now everything works fine. "10000" seems like a reasonable value here, but one could hard-code a lower or higher value as well. Can someone make sure this gets fixed in the next version of QuickCheck? I'm not sure who the maintainer is. Patrick From newsham at lava.net Wed Aug 13 20:22:44 2008 From: newsham at lava.net (Tim Newsham) Date: Wed Aug 13 20:22:00 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: Ok, surely at least everyone must agree that this is a bug: force :: Word8 -> IO Word8 force x = print x >> return x -- force = return . (`using` rnf) main = do d <- force =<< decodeFile stateFile encodeFile stateFile d where stateFile = "1word32.bin" test8.hs: 1word32.bin: openBinaryFile: resource busy (file is locked) the built-in Data.Binary.decodeFile function doesn't close its handle when it is done (same reason as my earlier examples). > However, I think probably the real blame here should probably go > to Data.Binary which doesn't attempt to check that it has consumed > all of its input after doing a "decode". If "decode" completes > and there is unconsumed data, it should probably raise an error > (it already raises errors for premature EOF). There's no reason > for it not to, since it does not provide the unconsumed data to > the caller when its done, anyway... I would have expected this to fix my problems: binEof :: Get () binEof = do more <- not <$> isEmpty when more $ error "expected EOF" decodeFully :: Binary b => B.ByteString -> b decodeFully = runGet (get << binEof) where a << b = a >>= (\x -> b >> return x) but even when using decodeFully, it still doesn't close the handle. Shouldn't Data.Binary.Get.isEmpty force a file handle close in the case that it returns True? Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Wed Aug 13 20:29:46 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 13 20:28:59 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: <20080814002946.GH7429@scytale.galois.com> newsham: > Ok, surely at least everyone must agree that this is a bug: > > force :: Word8 -> IO Word8 > force x = print x >> return x > -- force = return . (`using` rnf) > > main = do > d <- force =<< decodeFile stateFile > encodeFile stateFile d > where stateFile = "1word32.bin" > > test8.hs: 1word32.bin: openBinaryFile: resource busy (file is locked) > Remember that decodeFile f = liftM decode (L.readFile f) and readFile :: FilePath -> IO ByteString readFile f = openBinaryFile f ReadMode >>= hGetContents where hGetContents sits in a loop, reading chunks, loop = do c <- S.hGetNonBlocking h k if S.null c then do eof <- hIsEOF h if eof then hClose h >> return Empty else hWaitForInput h (-1) >> loop else do cs <- lazyRead return (Chunk c cs) while isEmpty is just, isEmpty :: Get Bool isEmpty = do S s ss _ <- get return (B.null s && L.null ss) That is, it checks the parsed chunk, it doesn't demand any more reading be done. So the only way you're going to get that Handle closed by readFile is to ensure you read till EOF is hit. After you decode, just ask keep asking for bytes till EOF, or close it yourself, decodeFile f = do h <- openFile f ReadMode ss <- L.hGetContents h let e = decode ss rnf e `seq` hClose h or some such, where you can confirm the decoding as taken place. From newsham at lava.net Wed Aug 13 20:39:07 2008 From: newsham at lava.net (Tim Newsham) Date: Wed Aug 13 20:38:23 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080814002946.GH7429@scytale.galois.com> References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> <20080814002946.GH7429@scytale.galois.com> Message-ID: So am I understanding you correctly that you believe this is not a bug? That the use Data.Binary.decodeFile function leaks a file descriptor and this is proper behavior? I still don't understand your explanation of how isEmpty can return True without having read to EOF. The ByteString continues to contain more data until an EOF is reached. Doesn't one of return (B.null s && L.null ss) force getContents to read until EOF? On Wed, 13 Aug 2008, Don Stewart wrote: > newsham: >> Ok, surely at least everyone must agree that this is a bug: >> >> force :: Word8 -> IO Word8 >> force x = print x >> return x >> -- force = return . (`using` rnf) >> >> main = do >> d <- force =<< decodeFile stateFile >> encodeFile stateFile d >> where stateFile = "1word32.bin" >> >> test8.hs: 1word32.bin: openBinaryFile: resource busy (file is locked) >> > > Remember that > > decodeFile f = liftM decode (L.readFile f) > > and > > readFile :: FilePath -> IO ByteString > readFile f = openBinaryFile f ReadMode >>= hGetContents > > where hGetContents sits in a loop, reading chunks, > > loop = do > c <- S.hGetNonBlocking h k > if S.null c > then do eof <- hIsEOF h > if eof then hClose h >> return Empty > else hWaitForInput h (-1) > >> loop > else do cs <- lazyRead > return (Chunk c cs) > > while isEmpty is just, > > isEmpty :: Get Bool > isEmpty = do > S s ss _ <- get > return (B.null s && L.null ss) > > That is, it checks the parsed chunk, it doesn't demand any more reading be done. > > So the only way you're going to get that Handle closed by readFile is to ensure > you read till EOF is hit. After you decode, just ask keep asking for bytes till EOF, > or close it yourself, > > decodeFile f = do > h <- openFile f ReadMode > ss <- L.hGetContents h > let e = decode ss > rnf e `seq` hClose h > > or some such, where you can confirm the decoding as taken place. > Tim Newsham http://www.thenewsh.com/~newsham/ From duncan.coutts at worc.ox.ac.uk Wed Aug 13 21:58:22 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 14 08:57:12 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813001820.GH25256@scytale.galois.com> <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: <1218679102.7661.590.camel@localhost> On Wed, 2008-08-13 at 12:02 -1000, Tim Newsham wrote: > However, I think probably the real blame here should probably go > to Data.Binary which doesn't attempt to check that it has consumed > all of its input after doing a "decode". If "decode" completes > and there is unconsumed data, it should probably raise an error > (it already raises errors for premature EOF). There's no reason > for it not to, since it does not provide the unconsumed data to > the caller when its done, anyway... > > Thoughts? I think you're right. The Binary instances cannot and must not read more than they need to, so that gives us the behaviour that we read exactly the length of the file, but no more, and thus we never hit EOF, so we don't close the file. So yes, decode should force the tail so that it can indeed hit EOF. Duncan From dons at galois.com Wed Aug 13 23:24:02 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 08:58:11 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813044314.GB3743@scytale.galois.com> <20080814002946.GH7429@scytale.galois.com> Message-ID: <20080814032402.GA8646@scytale.galois.com> bos: > On Wed, Aug 13, 2008 at 5:39 PM, Tim Newsham wrote: > > So am I understanding you correctly that you believe this is not > > a bug? That the use Data.Binary.decodeFile function leaks a file > > descriptor and this is proper behavior? > > I think he might be saying that decodeFile is not the place for > checking this condition. I will put words in his mouth and say that > checking for EOF after a decode is the responsibility of the > application code, because the lower level cannot possibly know whether > it makes sense for there to be residual data in the ByteString. There > are plenty of file formats that consist of back-to-back concatenated > chunks of data, in which reading just one chunk does not by any means > require that a file can only contain one. Exactly. This particular condition -- that encode should consume exactly the amount of data in the input file, and be sitting on EOF at the end -- is application dependent. That said, there's an argument to be made that the wrapper, decodeFile, could reasonable assume this is the most common case. -- Don From dons at galois.com Wed Aug 13 21:02:10 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 08:58:14 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813044314.GB3743@scytale.galois.com> <20080814002946.GH7429@scytale.galois.com> Message-ID: <20080814010210.GI7429@scytale.galois.com> newsham: > So am I understanding you correctly that you believe this is not > a bug? That the use Data.Binary.decodeFile function leaks a file > descriptor and this is proper behavior? It's not a bug. It's lazy IO. If you want the Handle closed, demand all the input. isEmpty will do this for you, if you're at the end of the file already. > I still don't understand your explanation of how isEmpty can > return True without having read to EOF. The ByteString continues > to contain more data until an EOF is reached. Doesn't one of > > return (B.null s && L.null ss) isEmpty is perfectly fine. You're just not demanding its result. Consider, {-# LANGUAGE BangPatterns #-} import Data.Word import Data.Binary import Data.Binary.Get import qualified Data.ByteString.Lazy as L import System.IO main = do encodeFile stateFile (42 :: Word32) d <- strictDecodeFile stateFile :: IO Word32 encodeFile stateFile d print d where stateFile = "1word32.bin" strictDecodeFile :: Binary a => FilePath -> IO a strictDecodeFile f = do ss <- L.readFile f return $! runGet (do v <- get !m <- isEmpty -- if we're at the end, this will close it return v) ss Look at strictDecodeFile. It's pretty much identical to the normal decodeFile, but it assumes 'get' will consume the entire file. It then checks for null, which will trigger an EOF and close if you are actually at the end. So we just decode the file, and check if the buffer's empty at the end. $ ghc --make A.hs [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... $ ./A 42 But if we leave out that bang pattern on isEmpty, the test won't run, and we'll get, $ ./A A: 1word32.bin: openBinaryFile: resource busy (file is locked) So were you just confused about how to use isEmpty? You could also explicit close in strictDecodeFile, strictDecodeFile :: Binary a => FilePath -> IO a strictDecodeFile f = do h <- openFile f ReadMode ss <- L.hGetContents h f let !v = runGet (do v <- get return v) ss hClose h return v Whatever works best for you. -- Don From johan.tibell at gmail.com Thu Aug 14 07:57:33 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Aug 14 08:59:24 2008 Subject: [Haskell-cafe] Bug with QuickCheck 1.1 and GHC 6.8.2 In-Reply-To: References: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> <90889fe70808140217h6d7f5a9fjff015beca1c7c9a4@mail.gmail.com> Message-ID: <90889fe70808140457g3f9186ccmdc6e37abd2774e18@mail.gmail.com> On Thu, Aug 14, 2008 at 12:15 PM, Patrick Perry wrote: > Actually, a much better solution is: > > variant :: Int -> Gen a -> Gen a > variant v (Gen m) = Gen (\n r -> m n (rands r v)) > where > rands r0 0 = r0 > rands r0 n = let (r1,r2) = split r0 > (n',s) = n `quotRem` 2 > in case s of > 0 -> rands r1 n' > _ -> rands r2 n' It's not really clear to me how this works. Could you please explain? Cheers, Johan From leather at cs.uu.nl Thu Aug 14 04:53:49 2008 From: leather at cs.uu.nl (Sean Leather) Date: Thu Aug 14 09:00:45 2008 Subject: [Haskell-cafe] Is www.haskell.org down? Message-ID: <3c6288ab0808140153r464598fbh248ba0fccc16dfc1@mail.gmail.com> I can't reach www.haskell.org , and I'm having withdrawal issues. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080814/0d1e4ed6/attachment.htm From newsham at lava.net Wed Aug 13 23:40:56 2008 From: newsham at lava.net (Tim Newsham) Date: Thu Aug 14 09:02:45 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> <20080814002946.GH7429@scytale.galois.com> Message-ID: > I think he might be saying that decodeFile is not the place for > application code, because the lower level cannot possibly know whether > it makes sense for there to be residual data in the ByteString. There > are plenty of file formats that consist of back-to-back concatenated > chunks of data, in which reading just one chunk does not by any means > require that a file can only contain one. Right, but because of the way decodeFile works, whenever you do not have a data type that explicitely checks for EOF in it's Get definition, decodeFile will leak a file handle. There is no way to check that there is residual data, to access it, or to close the file handle. Since this is the normal state of affairs (are there any Get definitions in the current library which check for EOF when done?) I would suggest that this is an API bug. I would suggest that "decodeFile" should check for EOF when done. A second wrapper function "decodePartialFile" could return the unconsumed data, perhaps, for situations when the EOF behavior is not desired, or return some other way for the file to be closed. Additionally, I would suggest that the Data.Binary library provide a combinator for consuming data fully (ie. checking for EOF). ie: fully :: Get a -> Get a fully a = do x <- a e <- isEmpty return $ case e of False -> error "expected EOF" True -> x decodeFully = runGet $ fully get decodeFile fn = decodeFully <$> B.readFile fn to make it easy for developers who do not use the decodeFile primitive to add EOF checking to their marshalling functions. As it currently stands, the most obvious application of the Data.Binary API leads to subtly confusing errors that may go unnoticed for a while. (This would be a fine point for the documentation to address to prevent others from falling in the same hole). I'm currently using definitions like these and (`using` rnf) and have a server that is able to repeatedly read and write the state file. Many thanks to Dons, Brian, Duncan and everyone else who helped me out... Tim Newsham http://www.thenewsh.com/~newsham/ From dougal at dougalstanton.net Thu Aug 14 09:03:48 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Thu Aug 14 09:03:03 2008 Subject: [Haskell-cafe] Is www.haskell.org down? In-Reply-To: <3c6288ab0808140153r464598fbh248ba0fccc16dfc1@mail.gmail.com> References: <3c6288ab0808140153r464598fbh248ba0fccc16dfc1@mail.gmail.com> Message-ID: <2d3641330808140603w2c8829a7l6d84216e4759f57b@mail.gmail.com> 2008/8/14 Sean Leather : > I can't reach www.haskell.org , and I'm having withdrawal issues. > I also can't get any response from it. It's not just you! D From patperry at stanford.edu Thu Aug 14 06:15:18 2008 From: patperry at stanford.edu (Patrick Perry) Date: Thu Aug 14 09:08:21 2008 Subject: [Haskell-cafe] Bug with QuickCheck 1.1 and GHC 6.8.2 In-Reply-To: <90889fe70808140217h6d7f5a9fjff015beca1c7c9a4@mail.gmail.com> References: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> <90889fe70808140217h6d7f5a9fjff015beca1c7c9a4@mail.gmail.com> Message-ID: Actually, a much better solution is: variant :: Int -> Gen a -> Gen a variant v (Gen m) = Gen (\n r -> m n (rands r v)) where rands r0 0 = r0 rands r0 n = let (r1,r2) = split r0 (n',s) = n `quotRem` 2 in case s of 0 -> rands r1 n' _ -> rands r2 n' Patrick On Aug 14, 2008, at 2:17 AM, Johan Tibell wrote: > On Thu, Aug 14, 2008 at 1:58 AM, Patrick Perry > wrote: >> variant :: Int -> Gen a -> Gen a >> variant v (Gen m) = Gen (\n r -> m n (rands r !! v')) >> where >> v' = abs (v+1) `mod` 10000 >> rands r0 = r1 : rands r2 where (r1, r2) = split r0 > > Note that if you have a uniformly distributed random value in [0, n) > and take its value mod k you don't end up with another random > uniformly distributed value unless n `mod` k == 0. Consider n = 3 and > k = 2. What you can do is to throw away all random numbers larger than > n - (n `mod` k) and just generate a new number. This will terminate > with a high probability if n >> k. > > Cheers, > > Johan From jed at 59A2.org Thu Aug 14 08:47:27 2008 From: jed at 59A2.org (Jed Brown) Date: Thu Aug 14 09:12:57 2008 Subject: [Haskell-cafe] Bug with QuickCheck 1.1 and GHC 6.8.2 In-Reply-To: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> References: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> Message-ID: <20080814124727.GS1713@brakk.ethz.ch> On Wed 2008-08-13 16:58, Patrick Perry wrote: > variant :: Int -> Gen a -> Gen a > variant v (Gen m) = Gen (\n r -> m n (rands r !! v')) > where > v' = abs (v+1) `mod` 10000 > rands r0 = r1 : rands r2 where (r1, r2) = split r0 This sort of defeats the purpose of variant since it is now a nearly random sampling in the predefined range. I filed a bug report (http://hackage.haskell.org/trac/ghc/ticket/2065) but it was closed since it works with QC-2. However, most people don't seem to use QC-2 so it still seems relevant to me. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080814/07c38f1f/attachment.bin From lemming at henning-thielemann.de Thu Aug 14 01:41:53 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Aug 14 09:14:08 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A34AFE.9000106@btinternet.com> References: <48A34AFE.9000106@btinternet.com> Message-ID: On Wed, 13 Aug 2008, Andrew Coppin wrote: > The naming of cats is a difficult matter... > > Ahem. So as you may have noticed, we seem to have a profusion of packages all > called "binary" or something dangeriously similar. There's also several "MD5" > packages. I could point out a few others. So what I'm wondering is... Do we > have a formal convention for the naming of packages and/or the naming of the > modules they contain? There is a page on the Wiki which lists several common top-level module names. Unfortunately www.haskell.org seems to be down currently. From bos at serpentine.com Wed Aug 13 23:19:51 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Aug 14 09:21:06 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> <20080814002946.GH7429@scytale.galois.com> Message-ID: On Wed, Aug 13, 2008 at 5:39 PM, Tim Newsham wrote: > So am I understanding you correctly that you believe this is not > a bug? That the use Data.Binary.decodeFile function leaks a file > descriptor and this is proper behavior? I think he might be saying that decodeFile is not the place for checking this condition. I will put words in his mouth and say that checking for EOF after a decode is the responsibility of the application code, because the lower level cannot possibly know whether it makes sense for there to be residual data in the ByteString. There are plenty of file formats that consist of back-to-back concatenated chunks of data, in which reading just one chunk does not by any means require that a file can only contain one. From bulat.ziganshin at gmail.com Thu Aug 14 03:56:54 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 14 09:25:01 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <48A069AE.40706@btinternet.com> References: <4899E8E7.6090000@btinternet.com> <349654066.20080808215650@gmail.com> <48A069AE.40706@btinternet.com> Message-ID: <1073063269.20080814115654@gmail.com> Hello Andrew, Monday, August 11, 2008, 8:32:46 PM, you wrote: >>> Here's the thing though... How do I get it so that "Foo Int" and "Foo >>> Double" produce slightly different strings when printed? >> instnace Show (Foo Int) ... >> instnace Show (Foo Double) ... > ...WHY did I not think of this myself? o_O because it's impossible with OOP classes? :))) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Thu Aug 14 05:17:33 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Aug 14 09:25:25 2008 Subject: [Haskell-cafe] Bug with QuickCheck 1.1 and GHC 6.8.2 In-Reply-To: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> References: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> Message-ID: <90889fe70808140217h6d7f5a9fjff015beca1c7c9a4@mail.gmail.com> On Thu, Aug 14, 2008 at 1:58 AM, Patrick Perry wrote: > variant :: Int -> Gen a -> Gen a > variant v (Gen m) = Gen (\n r -> m n (rands r !! v')) > where > v' = abs (v+1) `mod` 10000 > rands r0 = r1 : rands r2 where (r1, r2) = split r0 Note that if you have a uniformly distributed random value in [0, n) and take its value mod k you don't end up with another random uniformly distributed value unless n `mod` k == 0. Consider n = 3 and k = 2. What you can do is to throw away all random numbers larger than n - (n `mod` k) and just generate a new number. This will terminate with a high probability if n >> k. Cheers, Johan From dagit at codersbase.com Thu Aug 14 02:43:37 2008 From: dagit at codersbase.com (Jason Dagit) Date: Thu Aug 14 09:33:18 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <4899E8E7.6090000@btinternet.com> References: <4899E8E7.6090000@btinternet.com> Message-ID: On Wed, Aug 6, 2008 at 11:09 AM, Andrew Coppin wrote: > I just (re)discovered that I can do things like > > data Foo x = Foo Int Int > > Now "Foo Int" and "Foo Double" are, as far as the type checker cares, two > completely different types, even though in fact they are the same. This is > actually Quite Useful, in the particular case I'm working on. Phantom types are indeed useful for many things, but a bit of cautionary advice. If you start to depend on the phantoms for type safety AND you export your data constructors then you run a serious risk of being type unsafe. Bonus points if you can demonstrate an equivalent of unsafeCoerce# this way. Example: fooCast :: Foo Int -> Foo Double fooCast (Foo x) = Foo x On noes! We just cast that Foo Int to a Foo Double without changing it! It works because the value on the RHS is consider freshly constructed and other than sharing x it is unrelated to the one on the LHS. Note that by contrast this does not type check: foo :: Foo Int -> Foo Double foo f@(Foo x) = f Or, for that matter, any other variant where you don't use the constructor on the RHS. One way to get around this is to create your own constructor functions: mkFooInt :: Int -> Foo Int mkFooInt = Foo mkFooDouble :: Int -> Foo Double mkFooDouble = Foo Now export these instead of your data constructor. Similarly you'll probably want ones to take the place of pattern matching. The most obvious general purpose one being: unFoo :: Foo a -> Int unFoo (Foo a) = a But, if you're really relying on that phantom as a "witness", then you should probably define separate unFooInt :: Foo Int -> Int and unFooDouble : Foo Double -> Int. Here is the part where it gets really interesting. If you use GADTs, it rolls some of the above into one nice declaration: data Foo a where FooInt :: Int -> Foo Int FooDouble :: Int -> Foo Double I'm not sure if the GADT way can lead to an unsafeCoerce# equivalents or not. Maybe someone else can comment on that. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080813/aa330faf/attachment.htm From ok at cs.otago.ac.nz Thu Aug 14 00:26:18 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Aug 14 09:34:04 2008 Subject: [Haskell-cafe] Re: whatever happened to sendFile? In-Reply-To: <20080813224734.GI11895@sliver.repetae.net> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <42784f260808131540u397c8c0j18b1d24e09545014@mail.gmail.com> <20080813224734.GI11895@sliver.repetae.net> Message-ID: <1866A31D-0FD5-400E-99C2-77F8EAE23912@cs.otago.ac.nz> On 14 Aug 2008, at 10:47 am, John Meacham wrote: > There isn't a standard unix sendfile, while a few different ones have > functions called 'sendfile', they have different meanings/prototypes > in > general. For example, I'm typing this on an Intel Mac running Mac OS 10.5.4, and 'man sendfile' shows sendfile -- send a file to a socket and claims that it is checked runtime error if the destination is anything but a socket. It looks as though file -> socket is the only moderately portable case, and of course systems without can fake it by a sequence of reads and writes. From bertram.felgenhauer at googlemail.com Thu Aug 14 06:59:53 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Aug 14 09:34:08 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: <20080814105953.GA4185@zombie.inf.tu-dresden.de> Tim Newsham wrote: [snip] > I would have expected this to fix my problems: > > binEof :: Get () > binEof = do > more <- not <$> isEmpty > when more $ error "expected EOF" > > decodeFully :: Binary b => B.ByteString -> b > decodeFully = runGet (get << binEof) > where a << b = a >>= (\x -> b >> return x) Remember that the Get monad is lazy; the result of binEof is never used, so the action is not performed. decodeFully :: Binary b => B.ByteString -> b decodeFully = runGet (get << binEof) where a << b = a >>= (\x -> b >>= \y -> y `seq` return x) works, for example, and also where a << b = a >>= (\x -> b >>= \y -> return (y `seq` x)) and where (<<) = liftM2 (flip seq) HTH, Bertram From agentzh at gmail.com Thu Aug 14 04:31:32 2008 From: agentzh at gmail.com (Agent Zhang) Date: Thu Aug 14 09:58:44 2008 Subject: [Haskell-cafe] GHC 6.8.3 binary for older linux Message-ID: Halo~ I ran into the following error while trying to run a binary generated by GHC 6.8.x on our production machines with a not-so-recent linux installed (kernel 2.6.9). $ ./restyscript restyscript: timer_create: Invalid argument Evan building a pure static-linking executable did not solve the problem. Then I downloaded the binary GHC 6.8.3 from haskell.org on that machine, but the ghc crashes as well: $ ghc Floating point exception My teammate chaos++ found that the last time precision argument passed to the timer_create function was just too big. Manually editing the binary executable (the restyscript file in the previous example) solved this issue completely, but, yeah, it's terribly hacky. So I decided to build a GHC 6.8.3 from source on that old system using GHC 6.4.2. Fortunately, the binary GHC 6.4.2 from haskell.org does work there. The newly-built GHC solves all the problem. No floating-point exception nor invalid argument for timer_create. I've put my binary distribution on my site here: http://agentzh.org/misc/ghc-6.8.3-i386-old-linux.tar.bz2 Hopefully it'll be useful for someone else ;) Not sure if it's worth putting to the official download page as well :) Ideally GHC should inspect the kernel version and timer_create support at *runtime*, rather compile-time. It'll make our lives much easier ;) Thanks! -agentzh From jon at ffconsultancy.com Thu Aug 14 10:03:17 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Thu Aug 14 10:01:29 2008 Subject: [Haskell-cafe] Is www.haskell.org down? In-Reply-To: <2d3641330808140603w2c8829a7l6d84216e4759f57b@mail.gmail.com> References: <3c6288ab0808140153r464598fbh248ba0fccc16dfc1@mail.gmail.com> <2d3641330808140603w2c8829a7l6d84216e4759f57b@mail.gmail.com> Message-ID: <200808141503.17912.jon@ffconsultancy.com> On Thursday 14 August 2008 14:03:48 Dougal Stanton wrote: > 2008/8/14 Sean Leather : > > I can't reach www.haskell.org , and I'm having withdrawal issues. > > I also can't get any response from it. It's not just you! Haskell.org probably broke under stress after someone posted this link on the caml-list: http://www.reddit.com/comments/6v2nl/ghc_project_switches_to_git/ -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From Malcolm.Wallace at cs.york.ac.uk Thu Aug 14 05:14:50 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Aug 14 10:05:00 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <48A069AE.40706@btinternet.com> References: <4899E8E7.6090000@btinternet.com> <349654066.20080808215650@gmail.com> <48A069AE.40706@btinternet.com> Message-ID: <20080814101450.3bb46bf7.Malcolm.Wallace@cs.york.ac.uk> Andrew Coppin wrote: > > instnace Show (Foo Int) ... > > instnace Show (Foo Double) ... > > > > ...WHY did I not think of this myself? o_O Because it is not Haskell'98? It requires {-# LANGUAGE OverlappingInstances #-} Regards, Malcolm From DekuDekuplex at Yahoo.com Thu Aug 14 02:18:16 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Thu Aug 14 10:10:37 2008 Subject: [Haskell-cafe] haskell.org is down Message-ID: <0cj7a499bhn7tlvvl1tkc1oulvn7s56fhp@4ax.com> I tried posting a message to the haskell-beginners mailing list about a half-hour ago, but it seems that all of haskell.org has been down for at least the past half-hour. If anybody on this mailing list responsible for server maintenance receives this message, could you please check into this matter? I would like to be able to post messages on the haskell-related mailing lists, but I can't even get the list of mailing lists to come up, much less post. -- Benjamin L. Russell From jason.dusek at gmail.com Thu Aug 14 00:55:11 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Aug 14 10:21:25 2008 Subject: [Haskell-cafe] Re: whatever happened to sendFile? In-Reply-To: <42784f260808131540u397c8c0j18b1d24e09545014@mail.gmail.com> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <42784f260808131540u397c8c0j18b1d24e09545014@mail.gmail.com> Message-ID: <42784f260808132155k1770cdbaxa6a34e20fde3e830@mail.gmail.com> It turns out that Windows has a "transmit file" function that is more like UNIX sendfile. |transmit file| http://msdn.microsoft.com/en-us/library/ms740565(VS.85).aspx -- _jsn From allbery at ece.cmu.edu Thu Aug 14 11:34:46 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 14 11:34:02 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <87procrtyv.fsf@malde.org> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> <87procrtyv.fsf@malde.org> Message-ID: <217CF2ED-1F6F-48FE-B1C0-084179927EDE@ece.cmu.edu> On 2008 Aug 14, at 2:28, Ketil Malde wrote: > "Brandon S. Allbery KF8NH" writes: >> Your previously stated use case sounds like a good fit. I can easily >> imagine sendfile() implementations starving other network operations, >> though (and IIRC linux's early sendfile() implementation did so). >> It's essentially an optimization specific to web servers. > > Isn't it superseeded by splice(2) nowadays? Most Unixen have some version of sendfile(); how portable is splice()? (Of course, there could be a system-dependent mapping; one is needed for Windows already.) -- 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 at malde.org Thu Aug 14 02:28:24 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Aug 14 11:40:26 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> (Brandon S. Allbery's message of "Wed\, 13 Aug 2008 18\:29\:47 -0400") References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> Message-ID: <87procrtyv.fsf@malde.org> "Brandon S. Allbery KF8NH" writes: > On 2008 Aug 13, at 18:25, Jason Dusek wrote: >> Can you say more about this? I assume that sending static >> images back and forth is a good fit for sendfile(). > Your previously stated use case sounds like a good fit. I can easily > imagine sendfile() implementations starving other network operations, > though (and IIRC linux's early sendfile() implementation did so). > It's essentially an optimization specific to web servers. Isn't it superseeded by splice(2) nowadays? -k -- If I haven't seen further, it is by standing in the footprints of giants From bos at serpentine.com Wed Aug 13 23:17:00 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Aug 14 12:10:10 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> Message-ID: On Wed, Aug 13, 2008 at 3:02 PM, Tim Newsham wrote: > However, I think probably the real blame here should probably go > to Data.Binary which doesn't attempt to check that it has consumed > all of its input after doing a "decode". If "decode" completes > and there is unconsumed data, it should probably raise an error > (it already raises errors for premature EOF). There's no reason > for it not to, since it does not provide the unconsumed data to > the caller when its done, anyway... You missed runGetState in Data.Binary.Get, which I added. It's definitely not an error in the abstract to have excess input after you're done decoding. In your specific application, it might be, but then you should write a combinator that checks for this state. From asmith9983 at gmail.com Thu Aug 14 12:14:26 2008 From: asmith9983 at gmail.com (A Smith) Date: Thu Aug 14 12:13:42 2008 Subject: [Haskell-cafe] Haskell equivalent toPerl stat function Message-ID: <1e11fb0e0808140914s569f053di4c5b6845ead9d2df@mail.gmail.com> Hi I'm new to Haskell, so correct me if this is the wrong list or the wrong question. I'm looking for a function similar to the Perl stat to provide me with the last modify time of a file. I've been poring over source code entries referencing hfileSize but can't find the specific bit which reads the directory entry, so I could copy the code. Any advice would be welcome. -- Andrew in Edinburgh,Scotland From vanenkj at gmail.com Thu Aug 14 12:26:00 2008 From: vanenkj at gmail.com (John Van Enk) Date: Thu Aug 14 12:25:14 2008 Subject: [Haskell-cafe] Haskell equivalent toPerl stat function In-Reply-To: <1e11fb0e0808140914s569f053di4c5b6845ead9d2df@mail.gmail.com> References: <1e11fb0e0808140914s569f053di4c5b6845ead9d2df@mail.gmail.com> Message-ID: See System.Posix.Files. http://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Files.html#v%3AmodificationTime I think this is what you want. On Thu, Aug 14, 2008 at 12:14 PM, A Smith wrote: > Hi > I'm new to Haskell, so correct me if this is the wrong list or the > wrong question. > I'm looking for a function similar to the Perl stat to provide me > with the last modify time of a file. > I've been poring over source code entries referencing hfileSize but > can't find the specific bit which reads the directory entry, so I > could copy the code. > Any advice would be welcome. > -- > Andrew in Edinburgh,Scotland > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080814/93cc1508/attachment.htm From bulat.ziganshin at gmail.com Thu Aug 14 12:30:02 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 14 12:29:44 2008 Subject: [Haskell-cafe] Haskell equivalent toPerl stat function In-Reply-To: References: <1e11fb0e0808140914s569f053di4c5b6845ead9d2df@mail.gmail.com> Message-ID: <577128627.20080814203002@gmail.com> Hello John, Thursday, August 14, 2008, 8:26:00 PM, you wrote: > See System.Posix.Files. ... on Unix. there is also universal function in System.Directory: getModificationTime -- :: FilePath -> IO ClockTime > http://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Files.html#v%3AmodificationTime > > I think this is what you want. > On Thu, Aug 14, 2008 at 12:14 PM, A Smith wrote: > Hi > I'm new to Haskell, so correct me if this is the wrong list or the > wrong question. > I'm looking for a function similar to the Perl stat ?to provide me > with the last modify time of a file. > I've been poring over source code entries referencing hfileSize but > can't find the specific bit which reads the directory entry, so I > could copy the code. > Any advice would be welcome. > -- > Andrew in Edinburgh,Scotland > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From benjovi at gmx.net Thu Aug 14 12:53:37 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Thu Aug 14 12:52:54 2008 Subject: [Haskell-cafe] Fwd: ANN: Initial release of Language.C References: <4FD16766-82FF-4FF8-9E71-DEEE6D7F62AE@gmx.net> Message-ID: <2FEE02E8-063E-48D7-AA73-986BB78EDA19@gmx.net> Hello, I'm forwarding this to cafe, in case some of you are interested in this as well but not subscribed to libraries. Again, feedback is most welcome. I've almost finished integrating Language.C with c2hs too (fixing a few bugs along the way), so there will be a quite complex example available soon. Thanks for your interest. Begin forwarded message to libraries@haskell.org: > From: Benedikt Huber > Date: 13. August 2008 15:45:50 GMT+02:00 I'm pleased to announce the first release of Language.C, a library for analysing and generating C code. This release features * A reasonably well tested parser handling and recording all of C99 and most GNU extensions, most notably gcc's attribute syntax. * A pretty printer generating source code from the AST, covering the same language subset as the parser. * A preview of the analysis framework, including functionality for dissecting C's cruel type and variable declarations. Places: * The project's homepage is located at http://www.sivity.net/projects/language.c (Getting Started, Bug Tracker) * The package is available via hackage (language-c-0.3) * darcs repo: http://code.haskell.org/language-c * API docs: http://code.haskell.org/~bhuber/docs/language-c-latest/ The library originated from the C-related code in c2hs (http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ ), and is the topic of my SoC project, mentored by Iavor Diatchki. (Iavor, Don Steward and Duncan Coutts provided great support, thank you) Feedback and suggestions in any form are most welcome, especially because there is a large range of features which could be implemented. The current status and a few ideas for the next releases are summarized at http://www.sivity.net/projects/language.c/wiki/ ProjectPlan. best regards, benedikt From patperry at stanford.edu Thu Aug 14 13:08:08 2008 From: patperry at stanford.edu (Patrick Perry) Date: Thu Aug 14 13:07:25 2008 Subject: [Haskell-cafe] Bug with QuickCheck 1.1 and GHC 6.8.2 In-Reply-To: <90889fe70808140457g3f9186ccmdc6e37abd2774e18@mail.gmail.com> References: <4FFF1CFE-4CA0-4EE4-90AB-54274B0F031A@stanford.edu> <90889fe70808140217h6d7f5a9fjff015beca1c7c9a4@mail.gmail.com> <90889fe70808140457g3f9186ccmdc6e37abd2774e18@mail.gmail.com> Message-ID: <55682B91-CB65-4739-941B-CC88CDF88650@stanford.edu> 'split' has type split :: StdGen -> (StdGen, StdGen) It takes a generator and produces two independent generators. The old version of variant calls 'split' n times to get a new generator, and it only calls "split" on the second result. The new version calls split (log n) times. It gets a unique generator for each value of n by using both results from split. For example, rands 2 r0 = let (r1, r2) = split r0 (r3, r4) = split r1 in r4 rands 3 r0 = let (r1,r2) = split r0 (r3',r4') = split r2 in r4' Patrick On Aug 14, 2008, at 4:57 AM, Johan Tibell wrote: > On Thu, Aug 14, 2008 at 12:15 PM, Patrick Perry > wrote: >> Actually, a much better solution is: >> >> variant :: Int -> Gen a -> Gen a >> variant v (Gen m) = Gen (\n r -> m n (rands r v)) >> where >> rands r0 0 = r0 >> rands r0 n = let (r1,r2) = split r0 >> (n',s) = n `quotRem` 2 >> in case s of >> 0 -> rands r1 n' >> _ -> rands r2 n' > > It's not really clear to me how this works. Could you please explain? > > Cheers, > > Johan From dons at galois.com Thu Aug 14 13:21:33 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 13:20:46 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <1218679102.7661.590.camel@localhost> References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> Message-ID: <20080814172133.GA10871@scytale.galois.com> duncan.coutts: > On Wed, 2008-08-13 at 12:02 -1000, Tim Newsham wrote: > > > However, I think probably the real blame here should probably go > > to Data.Binary which doesn't attempt to check that it has consumed > > all of its input after doing a "decode". If "decode" completes > > and there is unconsumed data, it should probably raise an error > > (it already raises errors for premature EOF). There's no reason > > for it not to, since it does not provide the unconsumed data to > > the caller when its done, anyway... > > > > Thoughts? > > I think you're right. The Binary instances cannot and must not read more > than they need to, so that gives us the behaviour that we read exactly > the length of the file, but no more, and thus we never hit EOF, so we > don't close the file. So yes, decode should force the tail so that it > can indeed hit EOF. Duncan, You're suggesting that decode and decodeFile should whnf the next cell? -- Don From dons at galois.com Thu Aug 14 13:24:27 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 13:23:40 2008 Subject: [Haskell-cafe] haskell.org is down In-Reply-To: <0cj7a499bhn7tlvvl1tkc1oulvn7s56fhp@4ax.com> References: <0cj7a499bhn7tlvvl1tkc1oulvn7s56fhp@4ax.com> Message-ID: <20080814172427.GB10871@scytale.galois.com> DekuDekuplex: > I tried posting a message to the haskell-beginners mailing list about > a half-hour ago, but it seems that all of haskell.org has been down > for at least the past half-hour. > > If anybody on this mailing list responsible for server maintenance > receives this message, could you please check into this matter? I > would like to be able to post messages on the haskell-related mailing > lists, but I can't even get the list of mailing lists to come up, much > less post. Everything should be back in order now. Apparently Yale's packet filters decided haskell.org was a threat :) -- Don From dons at galois.com Thu Aug 14 13:25:44 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 13:25:01 2008 Subject: [Haskell-cafe] Is www.haskell.org down? In-Reply-To: <200808141503.17912.jon@ffconsultancy.com> References: <3c6288ab0808140153r464598fbh248ba0fccc16dfc1@mail.gmail.com> <2d3641330808140603w2c8829a7l6d84216e4759f57b@mail.gmail.com> <200808141503.17912.jon@ffconsultancy.com> Message-ID: <20080814172544.GC10871@scytale.galois.com> jon: > On Thursday 14 August 2008 14:03:48 Dougal Stanton wrote: > > 2008/8/14 Sean Leather : > > > I can't reach www.haskell.org , and I'm having withdrawal issues. > > > > I also can't get any response from it. It's not just you! > > Haskell.org probably broke under stress after someone posted this link on the > caml-list: > > http://www.reddit.com/comments/6v2nl/ghc_project_switches_to_git/ > That wasn't the reason Jon. I doubt the caml-list would generate enough traffic anyway. -- Don From dons at galois.com Thu Aug 14 13:57:43 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 13:56:59 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? Message-ID: <20080814175743.GE10871@scytale.galois.com> By the way, for those wondering why Jon Harrop would say such an unusual thing on the Haskell list, have a look at his contributions over on the OCaml list, http://article.gmane.org/gmane.comp.lang.caml.general/43430 Some choice quotes: "almost all of the examples of Haskell's use in industry are fakes" "nobody has ever done anything significant using Haskell" Jon's the primary source of FUD against Haskell and its community, as he goes around promoting his site in other functional programming communities. This kind of behaviour's been going on for a few years now, sadly. It's all rather disappointing. -- Don From gianfranco.alongi at gmail.com Thu Aug 14 14:07:40 2008 From: gianfranco.alongi at gmail.com (Gianfranco Alongi) Date: Thu Aug 14 14:06:54 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? In-Reply-To: <20080814175743.GE10871@scytale.galois.com> References: <20080814175743.GE10871@scytale.galois.com> Message-ID: This is ... disturbing. On Thu, Aug 14, 2008 at 7:57 PM, Don Stewart wrote: > By the way, for those wondering why Jon Harrop would say such an unusual > thing on the Haskell list, have a look at his contributions over on the > OCaml list, > > http://article.gmane.org/gmane.comp.lang.caml.general/43430 > > Some choice quotes: > > "almost all of the examples of Haskell's use in industry are fakes" > > "nobody has ever done anything significant using Haskell" > > Jon's the primary source of FUD against Haskell and its community, as he > goes around promoting his site in other functional programming > communities. This kind of behaviour's been going on for a few years now, > sadly. > > It's all rather disappointing. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Patience is the last resort for those unable to take action From ketil at malde.org Thu Aug 14 14:52:06 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Aug 14 14:50:47 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? In-Reply-To: <20080814175743.GE10871@scytale.galois.com> (Don Stewart's message of "Thu\, 14 Aug 2008 10\:57\:43 -0700") References: <20080814175743.GE10871@scytale.galois.com> Message-ID: <87fxp7qvjd.fsf@malde.org> Don Stewart writes: > By the way, for those wondering why Jon Harrop would say such an unusual > thing on the Haskell list, have a look at his contributions over on the > OCaml list, > > http://article.gmane.org/gmane.comp.lang.caml.general/43430 Well, to be perfectly honest: | > What are the advantages/disadvantages when comparing OCaml to Haskell? | | Techically, predictable performance, high performance on x64, tools like | camlp4 and language features including records, functors, polymorphic | variants and structurally-typed objects are probably the main advantages of | OCaml over Haskell. I think we can match language features with classes, concurrency, GADTs, STM, and so on. Predictable performance is a point, especially memory-wise. At least, I sometimes get surprises when a usage pattern causes too much or too little laziness. GHC uses a *lot* of memory in general, and in particular on 64 bits. I belive OCaml has a simpler semantics, and thus it is easier to optimize performance, especially for a beginner. Decent programmers get decent performance with Haskell, see e.g. the language shootout. | Non-technically, OCaml has more well-tested libraries, more practical books | (e.g. my own), more high-profile open source projects (e.g. FFTW has millions | of users) I'm not so sure about the library thing, it seems that Haskell has a bigger community, and while some libraries are less maintained than one would wish, some are pretty solid. Clearly, OCaml has been used in some serious settings, although I don't see why the number of users of one particular application should be significant to me. | There are far more practically-minded people in the OCaml community | and that is reflected in the much larger number of commercial | products that use OCaml. This almost reads as damning with faint praise. Do we have the educated, smart people, and a larger number of open source products? | Tangentially, OCaml has a successful relative in F# whereas | Haskell's close relatives are extinct. Or you could say that OCaml is one member of a family of languages, each slightly different, while Haskell managed to unify the ecosystem and community around a single standard. It would bear pointing out that just about every new, cool feature in emerging languages seem to come from Haskell. | nobody has ever done anything significant using Haskell He is entitled to his opinion of what is significant or not, just as I am entitled to my opinion of his opinion. -k -- If I haven't seen further, it is by standing in the footprints of giants From lemming at henning-thielemann.de Thu Aug 14 14:58:59 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Aug 14 14:58:14 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: References: <48A34AFE.9000106@btinternet.com> Message-ID: On Thu, 14 Aug 2008, Henning Thielemann wrote: > On Wed, 13 Aug 2008, Andrew Coppin wrote: > >> The naming of cats is a difficult matter... >> >> Ahem. So as you may have noticed, we seem to have a profusion of packages >> all called "binary" or something dangeriously similar. There's also several >> "MD5" packages. I could point out a few others. So what I'm wondering is... >> Do we have a formal convention for the naming of packages and/or the naming >> of the modules they contain? > > There is a page on the Wiki which lists several common top-level module > names. Unfortunately www.haskell.org seems to be down currently. http://www.haskell.org/haskellwiki/Hierarchical_module_names From ndmitchell at gmail.com Thu Aug 14 14:59:26 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Aug 14 14:58:38 2008 Subject: [Haskell-cafe] searchmonkey for haskell apis In-Reply-To: <87wsinf762.fsf@jobbicycle.corp.yahoo.com> References: <87wsinf762.fsf@jobbicycle.corp.yahoo.com> Message-ID: <404396ef0808141159k596ce130rc6ab7de53d5b3275@mail.gmail.com> Hi Brad, I already generate lots of Haskell API data for Hoogle (http://haskell.org/hoogle and http://haskell.org/hoogle/beta). Do you have any more details, or a link to the java api search plugin? If you want to do this, I'd love to talk - it should be possible to add it into Hoogle without too much difficulty, although I've little interest in doing the work myself :-) Thanks Neil On Tue, Aug 12, 2008 at 12:44 AM, brad clawsie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > i've been looking into the possibility of creating some xslt to expose > haskell apis to yahoo search via searchmonkey. > > if you see the java api search plugin, you can see some possibilities. > > i was wondering if anyone maintaining any the official api docs had > considered looking at searchmonkey. from a site owner's perspective, > some rdf metadata can be inlined with the api docs which yahoo will > automatically crawl to build up a search corpus, which could then be > rendered into a display using the searchmonkey tools. this approach > would be superior to the xslt approach i suggest above, since it exposes > industry standard metadata that any search engine can use. the xslt > approach is an option yahoo offers to let third-parties "scrape" sites > they want put in ysearch. > > since two parties approaches might conflict, i thought i would send out > a note. thanks. > > brad > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkigzvsACgkQxRg3RkRK91MwiACeJ66+jYgPfKvoYCDNYsUulnTo > 308An3NrwfkGAgfWJud4MaggHf0Zh9vw > =n/9o > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From duncan.coutts at worc.ox.ac.uk Thu Aug 14 14:17:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 14 15:05:19 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080814172133.GA10871@scytale.galois.com> References: <20080813003231.GL25256@scytale.galois.com> <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> Message-ID: <1218737836.13639.52.camel@localhost> On Thu, 2008-08-14 at 10:21 -0700, Don Stewart wrote: > > I think you're right. The Binary instances cannot and must not read more > > than they need to, so that gives us the behaviour that we read exactly > > the length of the file, but no more, and thus we never hit EOF, so we > > don't close the file. So yes, decode should force the tail so that it > > can indeed hit EOF. > > Duncan, > > You're suggesting that decode and decodeFile should whnf the next cell? At least decodeFile should, since it doesn't give you any other access to the file handle otherwise. Does decode return the tail? I don't remember. If not it should also whnf it. If it does then the user can choose (they might want to do something else with the trailing data). Duncan From chad.scherrer at gmail.com Thu Aug 14 15:26:13 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Thu Aug 14 15:25:37 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? References: <20080814175743.GE10871@scytale.galois.com> Message-ID: Don Stewart galois.com> writes: > Some choice quotes: > > "almost all of the examples of Haskell's use in industry are fakes" > > "nobody has ever done anything significant using Haskell" > > Jon's the primary source of FUD against Haskell and its community, as he > goes around promoting his site in other functional programming > communities. This kind of behaviour's been going on for a few years now, > sadly. Maybe trolls are just an unfortunate growing pain. Never see those in purely academic languages. From jon at ffconsultancy.com Thu Aug 14 16:05:57 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Thu Aug 14 16:04:06 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? In-Reply-To: <87fxp7qvjd.fsf@malde.org> References: <20080814175743.GE10871@scytale.galois.com> <87fxp7qvjd.fsf@malde.org> Message-ID: <200808142105.57627.jon@ffconsultancy.com> On Thursday 14 August 2008 19:52:06 Ketil Malde wrote: > Don Stewart writes: > > http://article.gmane.org/gmane.comp.lang.caml.general/43430 > > Well, to be perfectly honest: > | > What are the advantages/disadvantages when comparing OCaml to Haskell? > | > | Techically, predictable performance, high performance on x64, tools like > | camlp4 and language features including records, functors, polymorphic > | variants and structurally-typed objects are probably the main advantages > | of OCaml over Haskell. > > I think we can match language features with classes, concurrency, > GADTs, STM, and so on. Predictable performance is a point, especially > memory-wise. At least, I sometimes get surprises when a usage pattern > causes too much or too little laziness. GHC uses a *lot* of memory in > general, and in particular on 64 bits. Yes. Compilation speed as well. > I belive OCaml has a simpler semantics, and thus it is easier to > optimize performance, especially for a beginner. Decent programmers > get decent performance with Haskell, see e.g. the language shootout. Isn't Darcs an obvious counter example? > | Non-technically, OCaml has more well-tested libraries, more practical > | books (e.g. my own), more high-profile open source projects (e.g. FFTW > | has millions of users) > > I'm not so sure about the library thing, it seems that Haskell has a > bigger community, What gave you that impression? According to the Debian and Ubuntu package popularity contest results, OCaml currently has 10,635 registered installs compared to 6,606 for GHC. Moreover, this ratio has been constant for several years now. > and while some libraries are less maintained than > one would wish, some are pretty solid. Clearly, OCaml has been used > in some serious settings, although I don't see why the number of users > of one particular application should be significant to me. There are data for more applications, of course: Debian and Ubuntu registered installs ------------------------------------- 184,574: FFTW ( 14,298 lines of OCaml) 12,866: Unison ( 23,993 lines of OCaml) 7,286: MLDonkey (171,332 lines of OCaml) 4,365: Darcs ( 3,939 lines of Haskell) 4,066: FreeTennis ( 7,419 lines of OCaml) 4,057: Planets ( 3,296 lines of OCaml) 3,465: HPodder ( 2,225 lines of Haskell) 2,965: LEdit ( 2,048 lines of OCaml) 2,822: Hevea ( 11,596 lines of OCaml) 2,657: Polygen ( 1,331 lines of OCaml) That is 221,293 installs of popular OCaml software compared to only 7,830 installs of Haskell software. And 235,312 lines of OCaml code tested by many users compared to only 6,164 lines of well-tested Haskell code. > | There are far more practically-minded people in the OCaml community > | and that is reflected in the much larger number of commercial > | products that use OCaml. > > This almost reads as damning with faint praise. Do we have the > educated, smart people, and a larger number of open source products? The above statistics certainly that OCaml has four times as many popular open source projects as Haskell. > | Tangentially, OCaml has a successful relative in F# whereas > | Haskell's close relatives are extinct. > > Or you could say that OCaml is one member of a family of languages, > each slightly different, while Haskell managed to unify the > ecosystem and community around a single standard. Or you could say that the only popular Haskell is GHC's proprietary dialect. Either way, I think it is clear that OCaml has more users than GHC and OCaml+F# have far more users than all Haskell dialects combined. > It would bear pointing out that just about every new, cool feature in > emerging languages seem to come from Haskell. Like F#'s active patterns? > | nobody has ever done anything significant using Haskell > > He is entitled to his opinion of what is significant or not, just as I > am entitled to my opinion of his opinion. Have any open source projects written in Haskell ever garnered a significant number of users? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From allbery at ece.cmu.edu Thu Aug 14 16:09:16 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 14 16:08:30 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? In-Reply-To: <200808142105.57627.jon@ffconsultancy.com> References: <20080814175743.GE10871@scytale.galois.com> <87fxp7qvjd.fsf@malde.org> <200808142105.57627.jon@ffconsultancy.com> Message-ID: <6364E7DB-DF92-4439-8CFA-69456D2189C4@ece.cmu.edu> On Aug 14, 2008, at 16:05 , Jon Harrop wrote: > (spew) Where exactly did we pick up this, er, individual? Would they please take it back as defective? -- 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 vanenkj at gmail.com Thu Aug 14 16:18:13 2008 From: vanenkj at gmail.com (John Van Enk) Date: Thu Aug 14 16:17:27 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? In-Reply-To: <200808142105.57627.jon@ffconsultancy.com> References: <20080814175743.GE10871@scytale.galois.com> <87fxp7qvjd.fsf@malde.org> <200808142105.57627.jon@ffconsultancy.com> Message-ID: Generally, I'm fine with this kind of conversation, but this is obviously not going to lead to anything useful (and seemingly, this is intentional). I'd suggest killing this thread so that more useful conversation can receive focus. /jve On Thu, Aug 14, 2008 at 4:05 PM, Jon Harrop wrote: > On Thursday 14 August 2008 19:52:06 Ketil Malde wrote: > > Don Stewart writes: > > > http://article.gmane.org/gmane.comp.lang.caml.general/43430 > > > > Well, to be perfectly honest: > > | > What are the advantages/disadvantages when comparing OCaml to > Haskell? > > | > > | Techically, predictable performance, high performance on x64, tools > like > > | camlp4 and language features including records, functors, polymorphic > > | variants and structurally-typed objects are probably the main > advantages > > | of OCaml over Haskell. > > > > I think we can match language features with classes, concurrency, > > GADTs, STM, and so on. Predictable performance is a point, especially > > memory-wise. At least, I sometimes get surprises when a usage pattern > > causes too much or too little laziness. GHC uses a *lot* of memory in > > general, and in particular on 64 bits. > > Yes. Compilation speed as well. > > > I belive OCaml has a simpler semantics, and thus it is easier to > > optimize performance, especially for a beginner. Decent programmers > > get decent performance with Haskell, see e.g. the language shootout. > > Isn't Darcs an obvious counter example? > > > | Non-technically, OCaml has more well-tested libraries, more practical > > | books (e.g. my own), more high-profile open source projects (e.g. FFTW > > | has millions of users) > > > > I'm not so sure about the library thing, it seems that Haskell has a > > bigger community, > > What gave you that impression? > > According to the Debian and Ubuntu package popularity contest results, > OCaml > currently has 10,635 registered installs compared to 6,606 for GHC. > Moreover, > this ratio has been constant for several years now. > > > and while some libraries are less maintained than > > one would wish, some are pretty solid. Clearly, OCaml has been used > > in some serious settings, although I don't see why the number of users > > of one particular application should be significant to me. > > There are data for more applications, of course: > > Debian and Ubuntu registered installs > ------------------------------------- > 184,574: FFTW ( 14,298 lines of OCaml) > 12,866: Unison ( 23,993 lines of OCaml) > 7,286: MLDonkey (171,332 lines of OCaml) > 4,365: Darcs ( 3,939 lines of Haskell) > 4,066: FreeTennis ( 7,419 lines of OCaml) > 4,057: Planets ( 3,296 lines of OCaml) > 3,465: HPodder ( 2,225 lines of Haskell) > 2,965: LEdit ( 2,048 lines of OCaml) > 2,822: Hevea ( 11,596 lines of OCaml) > 2,657: Polygen ( 1,331 lines of OCaml) > > That is 221,293 installs of popular OCaml software compared to only 7,830 > installs of Haskell software. > > And 235,312 lines of OCaml code tested by many users compared to only 6,164 > lines of well-tested Haskell code. > > > | There are far more practically-minded people in the OCaml community > > | and that is reflected in the much larger number of commercial > > | products that use OCaml. > > > > This almost reads as damning with faint praise. Do we have the > > educated, smart people, and a larger number of open source products? > > The above statistics certainly that OCaml has four times as many popular > open > source projects as Haskell. > > > | Tangentially, OCaml has a successful relative in F# whereas > > | Haskell's close relatives are extinct. > > > > Or you could say that OCaml is one member of a family of languages, > > each slightly different, while Haskell managed to unify the > > ecosystem and community around a single standard. > > Or you could say that the only popular Haskell is GHC's proprietary > dialect. > > Either way, I think it is clear that OCaml has more users than GHC and > OCaml+F# have far more users than all Haskell dialects combined. > > > It would bear pointing out that just about every new, cool feature in > > emerging languages seem to come from Haskell. > > Like F#'s active patterns? > > > | nobody has ever done anything significant using Haskell > > > > He is entitled to his opinion of what is significant or not, just as I > > am entitled to my opinion of his opinion. > > Have any open source projects written in Haskell ever garnered a > significant > number of users? > > -- > Dr Jon D Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/products/?e > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080814/a81b01b3/attachment.htm From dons at galois.com Thu Aug 14 16:20:44 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 16:19:57 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? In-Reply-To: <200808142105.57627.jon@ffconsultancy.com> References: <20080814175743.GE10871@scytale.galois.com> <87fxp7qvjd.fsf@malde.org> <200808142105.57627.jon@ffconsultancy.com> Message-ID: <20080814202044.GE14958@scytale.galois.com> jon: > > I'm not so sure about the library thing, it seems that Haskell has a > > bigger community, > > What gave you that impression? > > According to the Debian and Ubuntu package popularity contest results, OCaml > currently has 10,635 registered installs compared to 6,606 for GHC. Moreover, > this ratio has been constant for several years now. Why, say, do we see the following results: * The #haskell IRC channel contains 500 people, the #ocaml channel 70? * 250 unique developers have uploaded 600 new libraries to hackage.haskell.org in the past year. How's the Caml Hump going? * On Arch Linux, we find 480 Haskell packages and tools, but only 21 for OCaml. Why the difference? * The caml-list had 315 posts for June, 08, while haskell-cafe had over 1400 Your statistics focus soley on the Debian-based distribution statitics, which have had an active OCaml group for several years now. What do the registered install stats look like, on say, Arch Linux, or Gentoo? -- Don From nominolo at googlemail.com Thu Aug 14 16:41:23 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Aug 14 16:40:36 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? In-Reply-To: <20080814202044.GE14958@scytale.galois.com> References: <20080814175743.GE10871@scytale.galois.com> <87fxp7qvjd.fsf@malde.org> <200808142105.57627.jon@ffconsultancy.com> <20080814202044.GE14958@scytale.galois.com> Message-ID: <916b84820808141341k4936b29k3e368a233382eef4@mail.gmail.com> Don't feed the (incredibly obvious) troll. He's doing no-one any good--not even to the O'Caml community. Haskell can learn from O'Caml, O'Caml can learn from Haskell. I also think that most users of either language actually know that. On Thu, Aug 14, 2008 at 10:20 PM, Don Stewart wrote: > jon: >> > I'm not so sure about the library thing, it seems that Haskell has a >> > bigger community, >> >> What gave you that impression? >> >> According to the Debian and Ubuntu package popularity contest results, OCaml >> currently has 10,635 registered installs compared to 6,606 for GHC. Moreover, >> this ratio has been constant for several years now. > > Why, say, do we see the following results: > > * The #haskell IRC channel contains 500 people, the #ocaml channel 70? > > * 250 unique developers have uploaded 600 new libraries to hackage.haskell.org in the past year. > How's the Caml Hump going? > > * On Arch Linux, we find 480 Haskell packages and tools, but only 21 > for OCaml. Why the difference? > > * The caml-list had 315 posts for June, 08, while haskell-cafe had > over 1400 > > Your statistics focus soley on the Debian-based distribution statitics, > which have had an active OCaml group for several years now. What do the > registered install stats look like, on say, Arch Linux, or Gentoo? > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From martindemello at gmail.com Thu Aug 14 16:51:40 2008 From: martindemello at gmail.com (Martin DeMello) Date: Thu Aug 14 16:50:53 2008 Subject: [Haskell-cafe] cabal on ubuntu Message-ID: I'm running Ubuntu 8 (Hardy Heron), and while trying to install cabal ran into this bug: https://bugs.launchpad.net/ubuntu/+source/haskell-cabal/+bug/231099 I finally had to install cabal manually, but it took me a lot of googling to be sure that was the right thing to do. Could someone who knows more than me put a howto in the ubuntu wiki https://wiki.ubuntu.com/MOTU/Teams/UncommonProgrammingLanguages/Haskell and/or the haskell one http://www.haskell.org/haskellwiki/GNU/Linux#Ubuntu ? martin From vanenkj at gmail.com Thu Aug 14 17:13:18 2008 From: vanenkj at gmail.com (John Van Enk) Date: Thu Aug 14 17:12:31 2008 Subject: [Haskell-cafe] cabal on ubuntu In-Reply-To: References: Message-ID: > UncommonProgrammingLanguages :( On Thu, Aug 14, 2008 at 4:51 PM, Martin DeMello wrote: > I'm running Ubuntu 8 (Hardy Heron), and while trying to install cabal > ran into this bug: > > https://bugs.launchpad.net/ubuntu/+source/haskell-cabal/+bug/231099 > > I finally had to install cabal manually, but it took me a lot of > googling to be sure that was the right thing to do. Could someone who > knows more than me put a howto in the ubuntu wiki > https://wiki.ubuntu.com/MOTU/Teams/UncommonProgrammingLanguages/Haskell > and/orthe haskell one > http://www.haskell.org/haskellwiki/GNU/Linux#Ubuntu ? > > martin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080814/8d9c955d/attachment.htm From dons at galois.com Thu Aug 14 17:17:05 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 14 17:16:15 2008 Subject: [Haskell-cafe] Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc. Message-ID: <20080814211705.GH14958@scytale.galois.com> Hey all, Below is a job opportunity for a Haskell programmer at Peerium, Inc. I was asked for forward to the community. Enjoy! -- Don ------------------------------------------------------------------------ Subject: Haskell Job Opportunity Platform Architect at Peerium, Inc. Please mail resumes to: hr@peerium.com Location: Cambridge, MA (Greater Boston Area) http://www.peerium.com Type: Full-time Skills: Proficiency and a strong interest in Haskell programming :) Bachelor's degree in computer science or equivalent from a four-year institution. Job Description Platform architects work with the founders to design and implement components of the runtime and supporting libraries for our software platform. Company Description At Peerium, we're striving to bring a new level of quality and efficiency to online communication and collaboration within virtual communities, social networks, and business environments. We believe that a new environment that supports the effortless sharing of both information and software will enable a level of online cooperation far beyond current Web-based technologies -- modern programming techniques will enable the creation of more robust and more powerful programs within these environments. ----- To this end, we're building a new software platform for direct, real- time communication and collaboration within graphically rich environments. We're currently building our first publicly available software product using many in-house technologies, including a powerful new programming language. Our first software product brings together a broad range of technologies, including: * Concurrent, distributed, functional programming * Graphically-rich, OpenGL interfaces * Peer-to-peer network protocols * Cryptographically secure communication * Distributed computation * Ubiquitous online agents ----- Peerium is located in the heart of Harvard Square in Cambridge, Massachusetts. From newsham at lava.net Thu Aug 14 17:32:00 2008 From: newsham at lava.net (Tim Newsham) Date: Thu Aug 14 17:31:27 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813004714.GN25256@scytale.galois.com> Message-ID: >> Maybe it makes sense to have the streamble list instance in Binary as >> well, with some examples? > Chunk = { > length :: Word8 > elems :: [Elem] -- 0..255 repetitions > } > Chunks = [Chunk] -- terminated with the first 0 length Chunk I tried my hand at the encoding above: http://www.thenewsh.com/%7Enewsham/store/test10.hs it seems to work, although it doesn't seem to be very efficient. I'm getting very large memory growth when I was hoping it would be lazy and memory efficient... What's leaking? >> -- Don Tim Newsham http://www.thenewsh.com/~newsham/ From ronwalf at volus.net Thu Aug 14 18:26:02 2008 From: ronwalf at volus.net (Ron Alford) Date: Thu Aug 14 18:25:28 2008 Subject: [Haskell-cafe] GHC Error: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: References: <1216622333-sup-3336@existential.local> <1216625156-sup-7796@existential.local> Message-ID: I reopened the bug, since I found slight changes to the file were able to reproduce the bug in recent versions of ghc-6.9. I also can't get the -S compilation step to work with the new file, unless I'm missing a step. -Ron Alford On Mon, Jul 21, 2008 at 3:32 AM, Ron Alford wrote: > Oops, already posted the bug: > http://hackage.haskell.org/trac/ghc/ticket/2456 > > On Mon, Jul 21, 2008 at 3:29 AM, Austin Seipp wrote: >> Status update: after checking out the latest HEAD and building it, the >> above error does not occur: >> >> $ ~/ghc-head/bin/ghc --version >> The Glorious Glasgow Haskell Compilation System, version 6.9.20080720 >> $ ~/ghc-head/bin/ghc --make DerivingError.hs >> >> : >> Warning: -fallow-overlapping-instances is deprecated: Use the >> OverlappingInstances language instead >> [1 of 1] Compiling DerivingError ( DerivingError.hs, DerivingError.o ) >> $ >> >> However, this doesn't exactly help your immediate problem, and it >> likely won't until 6.10.1 is released, as 6.8.3 is going to be the >> last release of the 6.8 branch. >> >> Truly sorry I couldn't have helped you more. >> >> Austin >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From ok at cs.otago.ac.nz Thu Aug 14 19:07:28 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Aug 14 19:06:47 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <87procrtyv.fsf@malde.org> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> <87procrtyv.fsf@malde.org> Message-ID: On 14 Aug 2008, at 6:28 pm, Ketil Malde wrote: > Isn't [sendfile()] superseeded by splice(2) nowadays? Solaris 10: f% man splice No manual entry for splice Mac OS X 10.5.4 m% man splice No manual entry for splice Linux 2.6.23... o% man splice .......... one of the descriptors MUST refer to a pipe. So of the three tolerably current "UNIX" systems available to me, two of them don't have it, and the third seems to be saying you cannot use it to move data from a file (which is not a pipe) to a socket (which is not a pipe), which is the use-case for sendfile(). From allbery at ece.cmu.edu Thu Aug 14 20:17:24 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 14 20:16:41 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> <87procrtyv.fsf@malde.org> Message-ID: <629DA58D-F758-4931-83AB-0BD58E44380B@ece.cmu.edu> On 2008 Aug 14, at 19:07, Richard A. O'Keefe wrote: > to me, two of them don't have it, and the third seems to be > saying you cannot use it to move data from a file (which is > not a pipe) to a socket (which is not a pipe), which is the > use-case for sendfile(). Actually, while I'm not sure how Linux does it, on the *BSDs pipes are actually socketpairs. -- 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 donn at avvanta.com Thu Aug 14 21:49:43 2008 From: donn at avvanta.com (Donn Cave) Date: Thu Aug 14 21:48:46 2008 Subject: [Haskell-cafe] Re: Is www.haskell.org down? Message-ID: <20080815014943.32F2693C4E@mail.avvanta.com> Quoth "Thomas Schilling" : | ... Haskell can learn from | O'Caml, O'Caml can learn from Haskell. I also think that most users | of either language actually know that. I'd like to start with a name for it. - Objective CAML (name of the language) - ocaml (name of the compiler) - OCaml (expedient name for language) I'm always a little piqued by "O'Caml", since I was so fond of O'Haskell. Now, there was a real Irishman. Donn From noandrews at gmail.com Thu Aug 14 22:32:43 2008 From: noandrews at gmail.com (Nicholas Andrews) Date: Thu Aug 14 22:31:55 2008 Subject: [Haskell-cafe] Cabal has trouble with projects that have both src and lib directories? Message-ID: Hi! I'm trying to set up a project with both src and lib directories with cabal. My blah.cabal file looks like: Library Build-Depends: base Exposed-Modules: Foo hs-source-dirs: lib/foo Executable hai Build-depends: base Main-is: Bar.hs ghc-options: -O hs-source-dirs: src/bar Other-Modules: Foo extra-libraries: Foo extra-lib-dirs: lib/bar But I get: $ runhaskell blah.cabal configure $ runhaskell blah.cabal build src/bar/Bar.hs:6:7: Could not find module `Foo': Use -v to see a list of the files... In Bar.hs, line 6 says "import Svm" What's wrong? Thanks! From ketil at malde.org Fri Aug 15 01:42:26 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Aug 15 01:41:05 2008 Subject: [Haskell-cafe] Cabal has trouble with projects that have both src and lib directories? In-Reply-To: (Nicholas Andrews's message of "Thu\, 14 Aug 2008 22\:32\:43 -0400") References: Message-ID: <874p5mrfzx.fsf@malde.org> "Nicholas Andrews" writes: > $ runhaskell blah.cabal configure blah.cabal isn't a Haskell file, you need a file Setup.hs that you can 'runhaskell'. Setup.hs need only contain the following three lines: #!/usr/bin/env runhaskell import Distribution.Simple main = defaultMain -k -- If I haven't seen further, it is by standing in the footprints of giants From jules at jellybean.co.uk Fri Aug 15 02:00:54 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Aug 15 02:00:08 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <20080814101450.3bb46bf7.Malcolm.Wallace@cs.york.ac.uk> References: <4899E8E7.6090000@btinternet.com> <349654066.20080808215650@gmail.com> <48A069AE.40706@btinternet.com> <20080814101450.3bb46bf7.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <48A51B96.7080102@jellybean.co.uk> Malcolm Wallace wrote: > Andrew Coppin wrote: > >>> instnace Show (Foo Int) ... >>> instnace Show (Foo Double) ... >>> >> ...WHY did I not think of this myself? o_O > > Because it is not Haskell'98? > It requires {-# LANGUAGE OverlappingInstances #-} No it doesn't? It requires the much more semantically simple -XFlexibleInstances, as far as I know. Overlapping would only be needed if there was also a polymorphic instance on Foo a? Jules From ok at cs.otago.ac.nz Fri Aug 15 02:23:01 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri Aug 15 02:22:18 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <629DA58D-F758-4931-83AB-0BD58E44380B@ece.cmu.edu> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> <87procrtyv.fsf@malde.org> <629DA58D-F758-4931-83AB-0BD58E44380B@ece.cmu.edu> Message-ID: <124E406E-F8C4-4890-9C00-809A9A92C733@cs.otago.ac.nz> On 15 Aug 2008, at 12:17 pm, Brandon S. Allbery KF8NH wrote: > Actually, while I'm not sure how Linux does it, on the *BSDs pipes > are actually socketpairs. This raises the question, which the documentation did not make clear to me, whether a "named pipe" is a pipe. One would hope it was, but S_IFIFO and S_IFSOCK are different... From martin.hofmann at uni-bamberg.de Fri Aug 15 02:24:53 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Fri Aug 15 02:24:06 2008 Subject: [Haskell-cafe] "Prompt" Monad In-Reply-To: <2f9b2d30808131428l591932f8he9be2d744fbb7b9@mail.gmail.com> References: <1218545406.5947.14.camel@ios.cogsys.wiai.uni-bamberg.de> <2f9b2d30808121028p3909228ep1de0ad9d2a86a5c5@mail.gmail.com> <1218609148.6180.1.camel@ios.cogsys.wiai.uni-bamberg.de> <2f9b2d30808131428l591932f8he9be2d744fbb7b9@mail.gmail.com> Message-ID: <1218781493.9204.1.camel@localhost> I am working on a system to induce recursive functional programs from examples, e.g. 'learn' the reverse function from rev [] = [] rev [a] = [a] rev [a,b] = [b,a] rev [a,b,c] = [c,b,a] ... Although I use analytical methods to reduce search to a minimum, I have to handle a huge search space and traverse it relying on heuristics. For details see our project site http://www.cogsys.wiai.uni-bamberg.de/effalip/ where you can find a prototype of our system (however implemented in MAUDE and not in Haskell). To improve these heuristics I thought about intervening the search during testing. So set some kind of breakpoints where to decide which part of the search space to explore next. This is were your monad might be useful. However I just started to dip into this whole Monad and MonadT universe, so any kind of suggestions are very much appreciated. Martin From allbery at ece.cmu.edu Fri Aug 15 02:26:18 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Aug 15 02:25:36 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <124E406E-F8C4-4890-9C00-809A9A92C733@cs.otago.ac.nz> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> <87procrtyv.fsf@malde.org> <629DA58D-F758-4931-83AB-0BD58E44380B@ece.cmu.edu> <124E406E-F8C4-4890-9C00-809A9A92C733@cs.otago.ac.nz> Message-ID: On 2008 Aug 15, at 2:23, Richard A. O'Keefe wrote: > On 15 Aug 2008, at 12:17 pm, Brandon S. Allbery KF8NH wrote: >> Actually, while I'm not sure how Linux does it, on the *BSDs pipes >> are actually socketpairs. > > This raises the question, which the documentation did not make clear > to me, > whether a "named pipe" is a pipe. One would hope it was, but > S_IFIFO and S_IFSOCK are different... They have to be: bound AF_UNIX sockets and fifos have very different semantics. That said, fifos could still be a different socket type, just as pipes are a distinct socket type. -- 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 lemming at henning-thielemann.de Fri Aug 15 03:24:07 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Aug 15 03:23:36 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: <48A51B96.7080102@jellybean.co.uk> References: <4899E8E7.6090000@btinternet.com> <349654066.20080808215650@gmail.com> <48A069AE.40706@btinternet.com> <20080814101450.3bb46bf7.Malcolm.Wallace@cs.york.ac.uk> <48A51B96.7080102@jellybean.co.uk> Message-ID: On Fri, 15 Aug 2008, Jules Bean wrote: > Malcolm Wallace wrote: >> Andrew Coppin wrote: >> >>>> instnace Show (Foo Int) ... >>>> instnace Show (Foo Double) ... >>>> >>> ...WHY did I not think of this myself? o_O >> >> Because it is not Haskell'98? It requires {-# LANGUAGE >> OverlappingInstances #-} > > No it doesn't? > > It requires the much more semantically simple -XFlexibleInstances, as far as > I know. > > Overlapping would only be needed if there was also a polymorphic instance on > Foo a? Btw. was anything bad about the suggested Haskell98 solution? From kolar at fit.vutbr.cz Fri Aug 15 03:39:15 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Fri Aug 15 03:36:41 2008 Subject: [Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64 Message-ID: <48A532A3.7070202@fit.vutbr.cz> Hello all, Is there any plan to make a package for archlinux x86_64 with (more or less) complete GHC 6.8.3 binaries? I know I can download and install myself, usually I do so myself, but the reason is to prepare a list of packages for others. So far, the 6.8.2 is available. Is there any possibility I could help with it? Some guidelines, how to prepare such a package, submit to a right place, etc. Thanks, Dusan From vpkaihla at gmail.com Fri Aug 15 03:46:04 2008 From: vpkaihla at gmail.com (Vesa Kaihlavirta) Date: Fri Aug 15 03:45:16 2008 Subject: [Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64 In-Reply-To: <48A532A3.7070202@fit.vutbr.cz> References: <48A532A3.7070202@fit.vutbr.cz> Message-ID: <25acdd550808150046t55c97709y3735073343d6a953@mail.gmail.com> On 8/15/08, Dusan Kolar wrote: > Hello all, > > Is there any plan to make a package for archlinux x86_64 with (more or > less) complete GHC 6.8.3 binaries? I know I can download and install myself, > usually I do so myself, but the reason is to prepare a list of packages for > others. So far, the 6.8.2 is available. > > Is there any possibility I could help with it? Some guidelines, how to > prepare such a package, submit to a right place, etc. Hi, Arch ghc maintainer here. We have opted to delay the upgrade of ghc because that version includes some regressions that we're not so wild about, and because upgrading ghc leads to lots of recompilations to prevent breakage. Do you have a specific need for that version? --vk From kolar at fit.vutbr.cz Fri Aug 15 03:57:41 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Fri Aug 15 03:55:02 2008 Subject: [Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64 In-Reply-To: <25acdd550808150046t55c97709y3735073343d6a953@mail.gmail.com> References: <48A532A3.7070202@fit.vutbr.cz> <25acdd550808150046t55c97709y3735073343d6a953@mail.gmail.com> Message-ID: <48A536F5.90309@fit.vutbr.cz> >> Is there any plan to make a package for archlinux x86_64 with (more or >> less) complete GHC 6.8.3 binaries? I know I can download and install myself, >> usually I do so myself, but the reason is to prepare a list of packages for >> others. So far, the 6.8.2 is available. >> >> > Hi, Arch ghc maintainer here. > > We have opted to delay the upgrade of ghc because that version > includes some regressions that we're not so wild about, and because > upgrading ghc leads to lots of recompilations to prevent breakage. > > Do you have a specific need for that version? > Well, just wanted to get ready some stuff for the coming academic year. So the main reason was to force everybody involved to use the version and, if possible, with not too much effort. If it is much effort to make the package, I can prepare a workaround, no problem, thanks. Dusan From DekuDekuplex at Yahoo.com Fri Aug 15 04:26:27 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Fri Aug 15 04:25:50 2008 Subject: [Haskell-cafe] Re: Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc. References: <20080814211705.GH14958@scytale.galois.com> Message-ID: <5jeaa4hb5l8euunbpqct6n4ikdn4ugu97h@4ax.com> On Thu, 14 Aug 2008 14:17:05 -0700, Don Stewart wrote: >[...] > >Skills: > Proficiency and a strong interest in Haskell programming :) > > Bachelor's degree in computer science or equivalent from a four-year > institution. This is the required background of Haskell-related job offering that I am looking for, except that I happen to be located in Tokyo, Japan. Does anybody know of any job offerings with this required background that are either located within commuting distance, or that allow telecommuting? Alternatively, equivalent Haskell-related offerings in other areas of Japan, in both academia and industry, could also prove to be alternatives. In particular, Haskell-related career paths that would lead from a Bachelor's degree in Computer Science to documenting Haskell libraries/tools and writing beginner-level Haskell textbooks would be of particular interest. -- Benjamin L. Russell From jules at jellybean.co.uk Fri Aug 15 04:49:42 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Aug 15 04:48:59 2008 Subject: [Haskell-cafe] Phantoms In-Reply-To: References: <4899E8E7.6090000@btinternet.com> <349654066.20080808215650@gmail.com> <48A069AE.40706@btinternet.com> <20080814101450.3bb46bf7.Malcolm.Wallace@cs.york.ac.uk> <48A51B96.7080102@jellybean.co.uk> Message-ID: <48A54326.9070009@jellybean.co.uk> Henning Thielemann wrote: >> instance on Foo a? > > Btw. was anything bad about the suggested Haskell98 solution? You called it 'non-hacky'; I would call it 'slightly hacky' since, IMO, it qualifies as a hack around a deficiency in the class system. However, I don't think there is anything wrong with it. After all it's the same trick the Prelude uses for instance Show [Char]. Jules From pkeir at dcs.gla.ac.uk Fri Aug 15 09:11:58 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Fri Aug 15 09:11:11 2008 Subject: [Haskell-cafe] Pretty Print, text or ++? Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> Hi there, I'm writing a pretty printer using the Text.PrettyPrint library, and there's a pattern I'm coming across quite often. Does anyone know whether, text (a ++ b ++ c ++ d) or text a <+> text b <+> text c <+> text d runs quicker? Cheers, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080815/f1ec713c/attachment-0001.htm From vanenkj at gmail.com Fri Aug 15 09:31:46 2008 From: vanenkj at gmail.com (John Van Enk) Date: Fri Aug 15 09:30:57 2008 Subject: [Haskell-cafe] Pretty Print, text or ++? In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> Message-ID: Paul, Something tells me you might want to look at `concat': concat :: [[a]] -> [a] /jve 2008/8/15 Paul Keir > Hi there, > > I'm writing a pretty printer using the Text.PrettyPrint library, and > there's a pattern I'm coming across quite often. Does anyone know whether, > > text (a ++ b ++ c ++ d) > or > text a <+> text b <+> text c <+> text d > > runs quicker? > > Cheers, > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080815/b3be52dd/attachment.htm From dot at dotat.at Fri Aug 15 09:34:26 2008 From: dot at dotat.at (Tony Finch) Date: Fri Aug 15 09:33:39 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: <629DA58D-F758-4931-83AB-0BD58E44380B@ece.cmu.edu> References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> <87procrtyv.fsf@malde.org> <629DA58D-F758-4931-83AB-0BD58E44380B@ece.cmu.edu> Message-ID: On Thu, 14 Aug 2008, Brandon S. Allbery KF8NH wrote: > > Actually, while I'm not sure how Linux does it, on the *BSDs pipes are > actually socketpairs. Not any more. FreeBSD replaced the socketpair implementation with a faster one in 1996 and OpenBSD imported it soon after. NetBSD imported it in 2001 and Mac OS X in 10.4 (2005). Dragonfly BSD forked from FreeBSD after the new pipe code was introduced. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST ICELAND: SOUTHWESTERLY BACKING SOUTHEASTERLY 4 OR 5, OCCASIONALLY 6 IN NORTH. MODERATE. SHOWERS. MODERATE OR GOOD. From pkeir at dcs.gla.ac.uk Fri Aug 15 09:35:47 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Fri Aug 15 09:39:47 2008 Subject: [Haskell-cafe] Pretty Print, text or ++? References: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CCA7F@EX2.ad.dcs.gla.ac.uk> Thanks, So you're recommending: text (concat [a,b,c,d,e]) Might this not transform my pretty printing into ugly printing; when longer strings are used? Paul -----Original Message----- From: sw17ch@gmail.com on behalf of John Van Enk Sent: Fri 15/08/2008 14:31 To: Paul Keir Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Pretty Print, text or ++? Paul, Something tells me you might want to look at `concat': concat :: [[a]] -> [a] /jve 2008/8/15 Paul Keir > Hi there, > > I'm writing a pretty printer using the Text.PrettyPrint library, and > there's a pattern I'm coming across quite often. Does anyone know whether, > > text (a ++ b ++ c ++ d) > or > text a <+> text b <+> text c <+> text d > > runs quicker? > > Cheers, > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080815/e6e576a1/attachment.htm From Christian.Maeder at dfki.de Fri Aug 15 09:50:16 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Aug 15 09:49:21 2008 Subject: [Haskell-cafe] Re: Pretty Print, text or ++? In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> Message-ID: <48A58998.3080102@dfki.de> Paul Keir wrote: > Hi there, > > I'm writing a pretty printer using the Text.PrettyPrint library, and > there's a pattern I'm coming across quite often. Does anyone know whether, > > text (a ++ b ++ c ++ d) > or > text a <+> text b <+> text c <+> text d > > runs quicker? Don't worry about speed. Write it as: hsep[text a, text b, text c, text d] and you can easily change hsep to sep or fsep, if the lines get too long. (And maybe you have some other docs that may be part of the list that are not constructed using "text".) HTH Christian From benjovi at gmx.net Fri Aug 15 09:53:30 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Fri Aug 15 09:52:51 2008 Subject: [Haskell-cafe] Re: Pretty Print, text or ++? In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> Message-ID: <48A58A5A.3060408@gmx.net> Paul Keir schrieb: > Hi there, > > I'm writing a pretty printer using the Text.PrettyPrint library, and > there's a pattern I'm coming across quite often. Does anyone know whether, > > text (a ++ b ++ c ++ d) > or > text a <+> text b <+> text c <+> text d > > runs quicker? Hi Paul, > text (a ++ b ++ c ++ d) is the same as > hcat (map text [a,b,c,d]) (horizontal concatenation without seperating spaces) while > text a <+> text b <+> text c <+> text d corresponds to > hsep (map text [a,b,c,d]) or > text (unwords [a,b,c,d]) With <+>, hsep or hcat, pretty printing won't choose the best layout - you tell the pretty printer to layout documents 'beside'. For autolayout, see sep,cat and the paragraph-fill variants fsep and fcat. Regarding performance: `unwords` will propably be a little faster (untested), but less flexible. There is no asymptotic overhead when using the pretty printer. cheers, benedikt > > Cheers, > Paul > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From Malcolm.Wallace at cs.york.ac.uk Fri Aug 15 09:47:07 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Aug 15 09:54:21 2008 Subject: [Haskell-cafe] Pretty Print, text or ++? In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> Message-ID: <20080815144707.61e3a38d.Malcolm.Wallace@cs.york.ac.uk> "Paul Keir" wrote: > text (a ++ b ++ c ++ d) The above is going to be ugly-printed onto a single line, whilst this: > text a <+> text b <+> text c <+> text d has a chance to be pretty-printed onto several lines, if each component is individually long. It doesn't really matter which expression is faster, if they do different things. The first solution fails to use the pretty-printing API to any significant advantage, whilst the second is more in the spirit of the thing. Regards, Malcolm From vanenkj at gmail.com Fri Aug 15 09:58:59 2008 From: vanenkj at gmail.com (John Van Enk) Date: Fri Aug 15 09:58:12 2008 Subject: [Haskell-cafe] Pretty Print, text or ++? In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CCA7F@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> <3CDFB8AFEA98E34CB599475AB11589C80CCA7F@EX2.ad.dcs.gla.ac.uk> Message-ID: Paul, I'm sorry, I ignored the "PrettyPrint" part and latched onto the "faster" part. You definitely don't want concat. I was looking at run-time. :) /jve On Fri, Aug 15, 2008 at 9:35 AM, Paul Keir wrote: > Thanks, > > So you're recommending: > > text (concat [a,b,c,d,e]) > > Might this not transform my pretty printing into ugly printing; when longer > strings are used? > > Paul > > > > -----Original Message----- > From: sw17ch@gmail.com on behalf of John Van Enk > Sent: Fri 15/08/2008 14:31 > To: Paul Keir > Cc: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Pretty Print, text or ++? > > Paul, > > Something tells me you might want to look at `concat': > > concat :: [[a]] -> [a] > > /jve > > > 2008/8/15 Paul Keir > > > Hi there, > > > > I'm writing a pretty printer using the Text.PrettyPrint library, and > > there's a pattern I'm coming across quite often. Does anyone know > whether, > > > > text (a ++ b ++ c ++ d) > > or > > text a <+> text b <+> text c <+> text d > > > > runs quicker? > > > > Cheers, > > Paul > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > -- > /jve > > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080815/510a0fad/attachment.htm From pkeir at dcs.gla.ac.uk Fri Aug 15 10:07:20 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Fri Aug 15 10:11:00 2008 Subject: [Haskell-cafe] RE: Pretty Print, text or ++? References: <3CDFB8AFEA98E34CB599475AB11589C80CCA7D@EX2.ad.dcs.gla.ac.uk> <48A58A5A.3060408@gmx.net> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CCA81@EX2.ad.dcs.gla.ac.uk> Awesome! Thanks to you all. I'll start with hsep[map a, b, c, d] and then I can try changing hsep for other things. Paul -----Original Message----- From: Benedikt Huber [mailto:benjovi@gmx.net] Sent: Fri 15/08/2008 14:53 To: Paul Keir Cc: haskell-cafe@haskell.org Subject: Re: Pretty Print, text or ++? Paul Keir schrieb: > Hi there, > > I'm writing a pretty printer using the Text.PrettyPrint library, and > there's a pattern I'm coming across quite often. Does anyone know whether, > > text (a ++ b ++ c ++ d) > or > text a <+> text b <+> text c <+> text d > > runs quicker? Hi Paul, > text (a ++ b ++ c ++ d) is the same as > hcat (map text [a,b,c,d]) (horizontal concatenation without seperating spaces) while > text a <+> text b <+> text c <+> text d corresponds to > hsep (map text [a,b,c,d]) or > text (unwords [a,b,c,d]) With <+>, hsep or hcat, pretty printing won't choose the best layout - you tell the pretty printer to layout documents 'beside'. For autolayout, see sep,cat and the paragraph-fill variants fsep and fcat. Regarding performance: `unwords` will propably be a little faster (untested), but less flexible. There is no asymptotic overhead when using the pretty printer. cheers, benedikt > > Cheers, > Paul > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20080815/5d7846c9/attachment.htm From noandrews at gmail.com Fri Aug 15 10:40:32 2008 From: noandrews at gmail.com (Nicholas Andrews) Date: Fri Aug 15 10:39:47 2008 Subject: [Haskell-cafe] Cabal has trouble with projects that have both src and lib directories? In-Reply-To: <874p5mrfzx.fsf@malde.org> References: <874p5mrfzx.fsf@malde.org> Message-ID: Sorry, I meant runhaskell Setup.hs . To clarify, I DO have a Setup.hs, and am getting the error in my original post when running it. On Fri, Aug 15, 2008 at 1:42 AM, Ketil Malde wrote: > "Nicholas Andrews" writes: > >> $ runhaskell blah.cabal configure > > blah.cabal isn't a Haskell file, you need a file Setup.hs that you can > 'runhaskell'. Setup.hs need only contain the following three lines: > > #!/usr/bin/env runhaskell > import Distribution.Simple > main = defaultMain > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > From allbery at ece.cmu.edu Fri Aug 15 12:48:25 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Aug 15 12:47:39 2008 Subject: [Haskell-cafe] whatever happened to sendFile? In-Reply-To: References: <42784f260808131127m125ecf76u4ce0940bd66dde1@mail.gmail.com> <800F3A38-3AAC-467F-BF4A-B3C90DB22533@ece.cmu.edu> <37F10DC5-EE4A-48BF-81EC-3E314882A59D@ece.cmu.edu> <288E689E-8ED7-4970-94CF-72616A9DF182@ece.cmu.edu> <42784f260808131525h5d2a5ef7w9e4fad1f3d88c6b6@mail.gmail.com> <4EE9A096-CBC0-4691-B2E6-620F0ABDB84E@ece.cmu.edu> <87procrtyv.fsf@malde.org> <629DA58D-F758-4931-83AB-0BD58E44380B@ece.cmu.edu> Message-ID: <852E6D5E-77C2-4360-B634-94D2C3D12D4F@ece.cmu.edu> On 2008 Aug 15, at 9:34, Tony Finch wrote: > On Thu, 14 Aug 2008, Brandon S. Allbery KF8NH wrote: >> Actually, while I'm not sure how Linux does it, on the *BSDs pipes >> are >> actually socketpairs. > > Not any more. FreeBSD replaced the socketpair implementation with a > faster > one in 1996 and OpenBSD imported it soon after. NetBSD imported it in > 2001 and Mac OS X in 10.4 (2005). Dragonfly BSD forked from FreeBSD > after > the new pipe code was introduced. Hm. Somehow I missed that. In any case, the real point is that historically (the socketpair stuff goes back to 4.2BSD) pipes were often considered a special case of sockets, so documentation referring to pipes might well actually mean or include sockets. Someone will have to inspect the Linux splice() implementation to see if it actually works on sockets. -- 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 andrewcoppin at btinternet.com Fri Aug 15 13:37:51 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Aug 15 14:12:16 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: References: <48A34AFE.9000106@btinternet.com> Message-ID: <48A5BEEF.6020804@btinternet.com> Henning Thielemann wrote: > > On Thu, 14 Aug 2008, Henning Thielemann wrote: > >> On Wed, 13 Aug 2008, Andrew Coppin wrote: >> >>> The naming of cats is a difficult matter... >>> >>> Ahem. So as you may have noticed, we seem to have a profusion of >>> packages all called "binary" or something dangeriously similar. >>> There's also several "MD5" packages. I could point out a few others. >>> So what I'm wondering is... Do we have a formal convention for the >>> naming of packages and/or the naming of the modules they contain? >> >> There is a page on the Wiki which lists several common top-level >> module names. Unfortunately www.haskell.org seems to be down currently. > > http://www.haskell.org/haskellwiki/Hierarchical_module_names Right. So if for some reason two people both developed a hashtable implementation (say), we would end up with two modules both called Data.Hashtable, but (hopefully) the packages themselves would be called james-hashtable and chris-hashtable (or something). Now both packages can be installed at once, but when I say "import Data.Hashtable", GHC has no way to know which one I mean. That doesn't sound too clever to me... From felipe.lessa at gmail.com Fri Aug 15 14:21:32 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri Aug 15 14:20:47 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A5BEEF.6020804@btinternet.com> References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> Message-ID: On Fri, Aug 15, 2008 at 2:37 PM, Andrew Coppin wrote: > Now both packages can be installed at once, but when I say "import > Data.Hashtable", GHC has no way to know which one I mean. That doesn't sound > too clever to me... GHC can hide packages or, put it another way, can show only the packages you want. That's what Cabal does when compiling. For example, try to remove some package from the dependencies and watch GHC complain. -- Felipe. From dons at galois.com Fri Aug 15 14:29:46 2008 From: dons at galois.com (Don Stewart) Date: Fri Aug 15 14:28:56 2008 Subject: [Haskell-cafe] Re: Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc. In-Reply-To: <5jeaa4hb5l8euunbpqct6n4ikdn4ugu97h@4ax.com> References: <20080814211705.GH14958@scytale.galois.com> <5jeaa4hb5l8euunbpqct6n4ikdn4ugu97h@4ax.com> Message-ID: <20080815182946.GD19745@scytale.galois.com> DekuDekuplex: > On Thu, 14 Aug 2008 14:17:05 -0700, Don Stewart > wrote: > > >[...] > > > >Skills: > > Proficiency and a strong interest in Haskell programming :) > > > > Bachelor's degree in computer science or equivalent from a four-year > > institution. > > This is the required background of Haskell-related job offering that I > am looking for, except that I happen to be located in Tokyo, Japan. Have you been to the Tokyo user group meetings? They're organised by Starling software, so perhaps a good place to network, http://www.starling-software.com/en/tsac.html -- Don From dons at galois.com Fri Aug 15 14:36:04 2008 From: dons at galois.com (Don Stewart) Date: Fri Aug 15 14:35:19 2008 Subject: [Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64 In-Reply-To: <48A532A3.7070202@fit.vutbr.cz> References: <48A532A3.7070202@fit.vutbr.cz> Message-ID: <20080815183604.GF19745@scytale.galois.com> kolar: > Hello all, > > Is there any plan to make a package for archlinux x86_64 with (more or > less) complete GHC 6.8.3 binaries? I know I can download and install > myself, usually I do so myself, but the reason is to prepare a list of > packages for others. So far, the 6.8.2 is available. > > Is there any possibility I could help with it? Some guidelines, how to > prepare such a package, submit to a right place, etc. > We can certainly host a ghc 6.8.3 package -- these are easy to produce. However, since it's identical to 6.8.2, functionality-wise, we're not upgrading officially yet. If you're interested in Arch/Haskell, I'd also recommend hanging out in the #arch-haskell IRC channel on freenode, where most design decisions get discussed. Finally, I'd like to mention we now have 489 Haskell packages natively bundled for Arch. :) Kick butt! http://aur.archlinux.org/packages.php?O=0&L=0&C=0&K=arch-haskell&SB=v&SO=d&PP=25&SeB=m&do_Orphans= -- Don From leather at cs.uu.nl Fri Aug 15 17:26:02 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Aug 15 17:25:12 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> Message-ID: <3c6288ab0808151426s7922ab3bt3ab7f5c2c78e545a@mail.gmail.com> > Andrew Coppin wrote: > > Now both packages can be installed at once, but when I say "import > > Data.Hashtable", GHC has no way to know which one I mean. That doesn't > sound > > too clever to me... > I agree, Andrew. The hierarchical module approach depends on a global resource for allocating names (or at least everybody agreeing on the scheme of choice). By trying to make all module names equal descriptive categories, it doesn't scale well. There are too many possibilities for overlap or different categorizations for the same thing. Felipe Lessa wrote: > GHC can hide packages or, put it another way, can show only the > packages you want. That's what Cabal does when compiling. For example, > try to remove some package from the dependencies and watch GHC > complain. > That doesn't work if you want to use two packages that have modules sharing the same hierarchical name, and this is a definite possibility given my statements above. Of course, having the ability to import modules from specific packages [1] would fix this, but only as long as the package names are also unique. Personally, I like the Java package naming scheme recommendation. It scales better, because each package name uses the organization or URI to uniquely identify a subset. Sean [1] http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/29319 - But notice the not really intended for general use bit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080815/5d7db449/attachment.htm From dave at zednenem.com Fri Aug 15 17:53:48 2008 From: dave at zednenem.com (David Menendez) Date: Fri Aug 15 17:52:58 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A34AFE.9000106@btinternet.com> References: <48A34AFE.9000106@btinternet.com> Message-ID: <49a77b7a0808151453t2418f904i5950e8605dfc8790@mail.gmail.com> Whoops. Forgot to hit "reply all". On Wed, Aug 13, 2008 at 4:58 PM, Andrew Coppin wrote: > The naming of cats is a difficult matter... > > Ahem. So as you may have noticed, we seem to have a profusion of packages > all called "binary" or something dangeriously similar. There's also several > "MD5" packages. I could point out a few others. So what I'm wondering is... > Do we have a formal convention for the naming of packages and/or the naming > of the modules they contain? How are name collisions supposed to be avoided? > (E.g., Java uses domain names for this. If I write a package named Foo, I > put all the classes in orphi.me.uk.Foo.*) So far as I know, there are no rules about naming packages, except that Hackage won't allow two packages with the same name. There is a loose convention about fitting modules into the larger hierarchy. Personally, I think trying to fit modules from different packages into the same hierarchy is a mistake, in that you either get the same module name used twice (meaning that both packages can't be used in the same program), or need to insert the package name into the name. Thus, "Test.HUnit", "Test.QuickCheck", "Text.ParserCombinators.Parsec", "Text.Pretty.HughesPJ", and so forth. We'd be better off just using the package name as the first element of the module names. Or, if that's objectionable, using something like "Package.Parsec" or "Lib.Parsec" (or "Hackage.Parsec", since Hackage enforces the uniqueness of package names). This is arguably one area where Java does better than Haskell. The resulting module names are long, but they don't require coordination and they don't raise tricky questions. (Quick, what's the difference between Data.* and Control.*? Is QuickCheck under Debug.* or Test.*?) -- Dave Menendez From wren at freegeek.org Fri Aug 15 19:24:39 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Aug 15 19:23:51 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <3c6288ab0808151426s7922ab3bt3ab7f5c2c78e545a@mail.gmail.com> References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> <3c6288ab0808151426s7922ab3bt3ab7f5c2c78e545a@mail.gmail.com> Message-ID: <48A61037.1010109@freegeek.org> Sean Leather wrote: > That doesn't work if you want to use two packages that have modules > sharing the same hierarchical name, and this is a definite possibility > given my statements above. Of course, having the ability to import > modules from specific packages [1] would fix this, but only as long as > the package names are also unique. > > Personally, I like the Java package naming scheme recommendation. It > scales better, because each package name uses the organization or URI to > uniquely identify a subset. Personally, I have major qualms with the Java package naming scheme. In particular, using domain names sets the barrier to entry much too high for casual developers (e.g. most of the Haskell user base). Yes, DNs are cheap and plentiful, but this basically requires a lifetime lease of the DN in question and the migration path is covered in brambles. The alternative is simply to lie and make up a DN, in which case this degenerates into the exact same resource quandary as doing nothing (but with high overhead in guilt or registration paperwork). The way CPAN is set up is much more egalitarian, though mired in a bit much administrivia for casual developers. The orthogonality of package names to module names is something I consider very much a feature, and not a bug. The only other packaging system I've seen to offer this is Monticello for Squeak/SmallTalk, and I've missed it ever since. By making packages orthogonal that allows for developers to create drop-in replacement packages that offer the same module services as another package, without needing to alter any code that uses the old package (save relinking/recompiling). This is the same advantage as allowing different modules to offer the same functions (e.g. having Data.ByteString as a drop-in for the [ ]-portions of the Prelude), but lifted up to the next tier. The question then is two-fold. First, is the question of how to minimize the problems of ambiguity and how to resolve conflicts when they arise. Second, is the question of whether this is really the job of Haskell, the language itself, or whether it is more appropriately dealt with by the build tools, e.g. Cabal. I'll deal a bit more with the latter question. (( For readers who don't want to slog through the rest of this post, the conclusion is that I feel an agile packaging system is an imperative, as discussed above. The trick is finding a way to be agile without creating a maintenance and conflict nightmare. But given the imperative: baby, bathwater, etc. )) I do like your (Sean Leather's) patch for being able to specify package names in source code, though I'd think something like Core's "package:module.module.module" syntax would be better if it gets adopted into Haskell'. I do however think that specifying the package should be optional, with conflicts to be resolved by commandline flags or via Cabal. Without this we loose the ability to have drop-in replacement packages, which in turn greatly complicates migration paths. The community is still young, but forks do happen and we would do best to allow for forwards compatibility whenever possible. This approach also gives the same sort of split control as the various {-# FOO #-} pragma give. As an ad-hoc GHC solution, adding a new PACKAGE pragma would be better than just using a string there. In theory we can already do this with OPTIONS_GHC, though that pragma seems not to respect the -package option. Of course, the new pragma should be position restricted to make it obvious which imports it applies to, rather than assuming to apply to the whole file (i.e. by putting it where you put the strings). One issue with this and Java's scheme of just concatenating package names onto module names is that they offer no provisions for specifying version restrictions. For a PACKAGE pragma we could design it deal with this too, since the modules themselves don't have versions. Of course this starts getting into hairy issues which Cabal was designed to resolve, so porting it back to the compiler seems misguided. Perhaps a simpler option, for a Haskell' world, would be to give modules versions and give the import syntax some way of specifying the version to use. Sticking with something like the current packaging system, packages would just specify the module versions they provide, and those versions need not be related to the version of the package itself. This has the benefit of being able to release and maintain legacy packages, once the world has forked or moved on to a new major version. As an addendum to this, it could be helpful if "package" names (i.e. alphanumeric sequences) were a part of the module version specification. This way a package hfoo-legacy could continue to provide the hfoo-1.24 versions of modules, and it would be the package that forked off rather than forcing the new hfoo package to rename itself to break ties from the legacy code. Another ability that the package/module system lacks right now is a good way for annotating deprecations. Java has this, but again they do it wrong. Whenever something is specified as deprecated it needs to provide a migration path to non-deprecated code. Simply saying "you fail" is an insufficient error message. This proposal doesn't solve the resource allocation issue. That issue will always be around so long as we assume nodes in the dependency graph have unique names. And that assumption is a very useful expedient so we're unlikely to abandon it any time soon (though maybe we should). But I think giving modules explicit name-version annotations is a better path forward than adding more bureaucracy to the module hierarchy. I think the suggested best practices for naming modules should be refined since they're starting to get out of date with all the code on Hackage. In particular there's a lot of conflict about (1) where to put new interesting Num data types (Data.Number.*, Data.*, Numeric.*, ...?); (2) where to put testing and diagnostic tools (Debug.*, Test.*); and (3) where to put modules for the core operation of application projects. But beyond providing better guidance, I don't think we should have a central body issuing leases for the module namespace. Especially because we already have a packaging system which is orthogonal to the module system. One of the reasons I love Haskell so much is because it is so extremely agile. I've been an active open-source developer for many years, and of all the languages I've used Haskell has by far the easiest system for communal public release of code. Perl's community is also very nice though it's gotten to be large enough that they do really need the bureaucracy they have. All the same it means less of my Perl code has made it into the wild than I would have liked. As for C and Java, the only stuff of mine that's managed to eek out into the public are whole projects, never any of the many small building blocks it takes to make something run and to make people able to bang out a program in a few hours because all the dirty work is already done and available in a large public repository. -- Live well, ~wren From wren at freegeek.org Fri Aug 15 20:50:40 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Aug 15 20:49:52 2008 Subject: [Haskell-cafe] ANN: logfloat Message-ID: <48A62460.4020105@freegeek.org> -------------------------------------------- -- Announcing: logfloat 0.8.2 -------------------------------------------- I just released a new package, logfloat, for manipulating log-domain floating numbers. The main reason for casting numbers into the log-domain is to prevent underflow when multiplying many small probabilities as is done in Hidden Markov Models and other statistical models often used for natural language processing. The log-domain also helps prevent overflow when multiplying many large numbers. In rare cases it can speed up numerical computation (since addition is faster than multiplication, though logarithms are exceptionally slow), but the primary goal is to improve accuracy of results. A secondary goal has been to maximize efficiency since these computations are frequently done within a /O(n^3)/ loop. The Data.Numeric.LogFloat module provides a new data type LogFloat which handles all the conversions and optimizations and can be treated as any other number thanks to type classes. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat -------------------------------------------- -- Details -------------------------------------------- The package's version numbers start from 0.8 since this began as a port of my Perl module for doing the same thing. The code is very heavily documented, largely for pedagogical reasons. Since Haddock doesn't play very nicely with literate Haskell, there's also a small lhs2hs converter script which gets run when you call: runhaskell Setup.hs haddock. This converter requires the bytestring package. The library proper does not, so I didn't include this dependency for the package itself. The package uses GHC's rewrite rules to do log/exp fusion. In general, since a newtype is used, the module shouldn't add overhead (beyond crossing the log/exp boundary). In the future I'll be experimenting with strictness as well to try to ensure that everything stays in registers for those /O(n^3)/ loops. I'm not sure whether it'd be helpful to keep a lazy version around as well... The LogFloat type is restricted to non-negative numbers. In the future I'll also add a signed variant for those who aren't just doing statistical work. -- Live well, ~wren From dons at galois.com Fri Aug 15 20:53:37 2008 From: dons at galois.com (Don Stewart) Date: Fri Aug 15 20:53:06 2008 Subject: [Haskell-cafe] ANN: logfloat In-Reply-To: <48A62460.4020105@freegeek.org> References: <48A62460.4020105@freegeek.org> Message-ID: <20080816005337.GA21330@scytale.galois.com> wren: > -------------------------------------------- > -- Announcing: logfloat 0.8.2 > -------------------------------------------- > > I just released a new package, logfloat, for manipulating log-domain > floating numbers. > Arch Linux package now ready, http://aur.archlinux.org/packages.php?ID=18832 From wren at freegeek.org Fri Aug 15 20:59:04 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Aug 15 20:58:18 2008 Subject: [Haskell-cafe] ANN: logfloat In-Reply-To: <48A62460.4020105@freegeek.org> References: <48A62460.4020105@freegeek.org> Message-ID: <48A62658.4070908@freegeek.org> wren ng thornton wrote: > -------------------------------------------- > -- Announcing: logfloat 0.8.2 > -------------------------------------------- [...] > The code is very heavily documented, largely for pedagogical reasons. > Since Haddock doesn't play very nicely with literate Haskell, there's > also a small lhs2hs converter script which gets run when you call: > runhaskell Setup.hs haddock. This converter requires the bytestring > package. The library proper does not, so I didn't include this > dependency for the package itself. It looks like Hackage's build bot doesn't do `runhaskell Setup.hs haddock` for generating the documentation. So for now at least, the documentation can be found at: http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ I'll work on correcting that in the future. -- Live well, ~wren From felipe.lessa at gmail.com Fri Aug 15 21:11:15 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri Aug 15 21:10:24 2008 Subject: [Haskell-cafe] ANN: logfloat In-Reply-To: <48A62658.4070908@freegeek.org> References: <48A62460.4020105@freegeek.org> <48A62658.4070908@freegeek.org> Message-ID: I should point out just in case that 1 / 0 isn't infinity on all Fractional types (e.g. Rational). I guess it shouldn't cause a problem with your library, but a warning on the Haddock entry would be nice to avoid surprising people who didn't see the internal implementation. Nice lib, by the way. Thanks, -- Felipe. From wren at freegeek.org Fri Aug 15 21:28:56 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Aug 15 21:28:07 2008 Subject: [Haskell-cafe] ANN: logfloat In-Reply-To: References: <48A62460.4020105@freegeek.org> <48A62658.4070908@freegeek.org> Message-ID: <48A62D58.4060706@freegeek.org> Felipe Lessa wrote: > I should point out just in case that 1 / 0 isn't infinity on all > Fractional types (e.g. Rational). I guess it shouldn't cause a problem > with your library, but a warning on the Haddock entry would be nice to > avoid surprising people who didn't see the internal implementation. > > Nice lib, by the way. Thanks, Ah, interesting. I missed that one. I'm wondering if there's any portable notion of infinity on Rationals. GHC.Real uses 1%0, but Hugs gives an overflow for toRational(1/0)... Time to go digging. In the mean time I'll add a note about it. Thanks. -- Live well, ~wren From dave at zednenem.com Fri Aug 15 21:29:54 2008 From: dave at zednenem.com (David Menendez) Date: Fri Aug 15 21:29:04 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A61037.1010109@freegeek.org> References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> <3c6288ab0808151426s7922ab3bt3ab7f5c2c78e545a@mail.gmail.com> <48A61037.1010109@freegeek.org> Message-ID: <49a77b7a0808151829i4268d9dy691036065cf63344@mail.gmail.com> On Fri, Aug 15, 2008 at 7:24 PM, wren ng thornton wrote: > (( For readers who don't want to slog through the rest of this post, the > conclusion is that I feel an agile packaging system is an imperative, as > discussed above. The trick is finding a way to be agile without creating a > maintenance and conflict nightmare. But given the imperative: baby, > bathwater, etc. )) Have you seen the PackageMounting proposal? Essentially, each package would get its own hierarchy, which would then be attached to the larger module hierarchy at compile-time according to compiler options, or Cabal data, or methods as yet unseen. If, for some reason, you need to import two versions of the same package, or two packages that have a module name collision, you can change the default mounting point for one or both. -- Dave Menendez From robgreayer at yahoo.com Fri Aug 15 22:18:39 2008 From: robgreayer at yahoo.com (Robert Greayer) Date: Fri Aug 15 22:17:48 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A61037.1010109@freegeek.org> Message-ID: <430951.41502.qm@web65714.mail.ac4.yahoo.com> --- On Sat, 8/16/08, wren ng thornton wrote: > Personally, I have major qualms with the Java package > naming scheme. In > particular, using domain names sets the barrier to entry > much too high > for casual developers (e.g. most of the Haskell user base). > Yes, DNs are > cheap and plentiful, but this basically requires a lifetime > lease of the > DN in question and the migration path is covered in > brambles. The > alternative is simply to lie and make up a DN, in which > case this > degenerates into the exact same resource quandary as doing > nothing (but > with high overhead in guilt or registration paperwork). This does sound in theory like a real problem; the actual practice has worked out much differently for Java: the existence of durable domains willing to host development of small libraries for the Java space are plentiful. In other words, the barrier to entry has turned out to be quite low. Nevertheless, hackage of course provides an even cheaper alternative to DN-based naming, since package names registered on hackage are guaranteed unique (across the hackage-using community). The ubiquitous convention for Haskell could easily be that if you want your library to interoperate without conflict, register it on hackage (otherwise you take your chances, just as in Java if you ignore the DN-based convention). Having the ability to use package names to avoid module-name conflicts (i.e. an agile packaging system, in your words) would still be needed. The need to *recompile* to avoid conflicts is a problem though, if haskell aspires to attract commercial package vendors. I don't know how it could be avoided though. rcg From wren at freegeek.org Sat Aug 16 00:27:44 2008 From: wren at freegeek.org (wren ng thornton) Date: Sat Aug 16 00:26:59 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <49a77b7a0808151829i4268d9dy691036065cf63344@mail.gmail.com> References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> <3c6288ab0808151426s7922ab3bt3ab7f5c2c78e545a@mail.gmail.com> <48A61037.1010109@freegeek.org> <49a77b7a0808151829i4268d9dy691036065cf63344@mail.gmail.com> Message-ID: <48A65740.7030209@freegeek.org> David Menendez wrote: > On Fri, Aug 15, 2008 at 7:24 PM, wren ng thornton wrote: >> (( For readers who don't want to slog through the rest of this post, the >> conclusion is that I feel an agile packaging system is an imperative, as >> discussed above. The trick is finding a way to be agile without creating a >> maintenance and conflict nightmare. But given the imperative: baby, >> bathwater, etc. )) > > Have you seen the PackageMounting proposal? > > > > Essentially, each package would get its own hierarchy, which would > then be attached to the larger module hierarchy at compile-time > according to compiler options, or Cabal data, or methods as yet > unseen. If, for some reason, you need to import two versions of the > same package, or two packages that have a module name collision, you > can change the default mounting point for one or both. I hadn't seen it. It looks pretty nice. It reminds me of the recent discussion about hierarchical imports for the Gtk library.[1] A feature that's typically nice in grafting systems is to allow re-grafting (and pruning), so that after a package is mounted subpackages can be moved around (or removed). These features add complication to building the right tree before linking, but it adds a great deal of power and flexibility. A typical use case is when your project is using some other large project and you want to mark certain parts of that project as deprecated, unsafe, overridden, etc so that your own code doesn't accidentally use it. Defensive programming and all that. Of course, used improperly, it also lets you create byzantine structures that channel mind-bending energies that keep systems administrators tossing and turning at nights. [1] http://www.haskell.org/pipermail/haskell-cafe/2008-June/thread.html#44133 -- Live well, ~wren From lemming at henning-thielemann.de Sat Aug 16 01:25:13 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Aug 16 01:24:23 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A5BEEF.6020804@btinternet.com> References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> Message-ID: On Fri, 15 Aug 2008, Andrew Coppin wrote: > Henning Thielemann wrote: >> >> http://www.haskell.org/haskellwiki/Hierarchical_module_names > > > Right. So if for some reason two people both developed a hashtable > implementation (say), we would end up with two modules both called > Data.Hashtable, but (hopefully) the packages themselves would be called > james-hashtable and chris-hashtable (or something). > > Now both packages can be installed at once, but when I say "import > Data.Hashtable", GHC has no way to know which one I mean. That doesn't sound > too clever to me... Although it is possible to hide packages by GHC options, we should not do this, because several libraries might use different Hash tables and it would not be possible to write a program which uses many of these libraries. It's better to add a distinguishing part to the module name, like Data.HashTable.Coppin or so. From andrewcoppin at btinternet.com Sat Aug 16 05:00:10 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Aug 16 04:59:14 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> Message-ID: <48A6971A.7030300@btinternet.com> Henning Thielemann wrote: > Although it is possible to hide packages by GHC options, we should not > do this, because several libraries might use different Hash tables and > it would not be possible to write a program which uses many of these > libraries. It's better to add a distinguishing part to the module > name, like Data.HashTable.Coppin or so. This is more the sort of thing I had in mind, yes. As others have pointed out, not everybody has a domain name, so Java's technique of inserting a domain name perhaps isn't the best one. However, if we all agreed that, say, packages should be named "coppin-hashtable" or something, then there wouldn't be much danger of ambiguous package names. (As I already pointed out, there's at least 3 packages called "bianry", which is just confusing.) It's rather less clear what to do with something like, say, ByteString, which is the product of a large number of collaborators. Then again, it's a big enough package that nobody is likely to come up with a similar one. (Unless it's a fork I suppose - in which case a prefix or suffix for the person who forked it might be appropriate?) What to do at the module level is less obvious. Having several packages provide different implementations of the same thing is arguably useful. (E.g., I know Gtk2hs provies an SOE module. What about wxHaskell? If the interface is standard enough, a given application might not actually care which implementation it gets.) I'm open to suggestions here... I don't claim to have all the answers. I'd just like to see some debate happening. ;-) From robgreayer at yahoo.com Sat Aug 16 11:20:45 2008 From: robgreayer at yahoo.com (Robert Greayer) Date: Sat Aug 16 11:19:53 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A6971A.7030300@btinternet.com> Message-ID: <747330.43946.qm@web65705.mail.ac4.yahoo.com> --- On Sat, 8/16/08, Andrew Coppin wrote: > > Although it is possible to hide packages by GHC options, we should not > > do this, because several libraries might use different Hash tables and > > it would not be possible to write a program which uses many of these > > libraries. It's better to add a distinguishing part to the module > > name, like Data.HashTable.Coppin or so. > > This is more the sort of thing I had in mind, yes. This seems to be a common approach, but it runs counter to the objective of separating 'provenance' from module naming. 'Coppin' is (part of, sans version) the provenance of the hashtable implementation, so I'm not sure how this sort of scheme is better than just shoving the unique prefix at the front of the module, e.g. Coppin.Data.Hashtable Though embedding the provenance down in the hierarchy is a common pattern, I think it is can be pretty messy. For example, the Parsec package exposes many modules, including "Text.Parsec.String" and "Text.ParserCombinators.Parsec.Token" -- the provenance appears at different levels in the hierarchy. If you're going to shove the package name in there, it seems simpler to me to just shove it at the front: Parsec.Text.ParserCombinators.Token. The package mounting scheme might solve this (though it seems to me that it requires that source for packages be kept around. I may be wrong). > (As I already pointed out, there's at least 3 packages called "bianry", > which is just confusing.) On hackage? I only see one with that the exact name "binary". From lchangying at gmail.com Sat Aug 16 12:22:35 2008 From: lchangying at gmail.com (Changying Li) Date: Sat Aug 16 12:24:19 2008 Subject: [Haskell-cafe] why isn't the thread blocked? Message-ID: <87hc9lgcac.fsf@gmail.com> I writed a little program to test forkIO. in fact, I want to know how to implement the 'select' system call in haskell: module Main where import Control.Concurrent.Chan import Control.Concurrent import System.IO main = do chan <- newChan handles <- mapM ((flip openFile) ReadMode) ["/tmp/a","/tmp/b","/tmp/c"] let readF h = do myID <- myThreadId chan' <- dupChan chan char <- hGetChar h writeChan chan' $ show myID putStrLn [char] threads <- mapM (\h -> forkIO $ readF h) handles nr <- readChan chan mapM killThread $ filter (\x -> show x == nr ) threads putStrLn nr I first mkfifo /tmp/{a,b,c} , then run 'echo "hello" >/tmp/a', then 'runhaskell thisProgram.hs' but I got an error: test.hs: /tmp/b: hGetChar: end of file test.hs: /tmp/c: hGetChar: end of file I think the thread will be blocked when /tmp/b has nothing. but it get EOF, why ? -- Thanks & Regards Changying Li From allbery at ece.cmu.edu Sat Aug 16 12:54:27 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Aug 16 12:53:36 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A6971A.7030300@btinternet.com> References: <48A34AFE.9000106@btinternet.com> <48A5BEEF.6020804@btinternet.com> <48A6971A.7030300@btinternet.com> Message-ID: On 2008 Aug 16, at 5:00, Andrew Coppin wrote: > What to do at the module level is less obvious. Having several > packages provide different implementations of the same thing is > arguably useful. (E.g., I know Gtk2hs provies an SOE module. What > about wxHaskell? If the interface is standard enough, a given > application might not actually care which implementation it gets.) > I'm open to suggestions here... The standard way to deal with this is virtual packages. But this would require significant changes to Cabal, not only to track multiple names for a single package but also to not complain about collisions. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Sat Aug 16 12:57:15 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Aug 16 12:56:23 2008 Subject: [Haskell-cafe] why isn't the thread blocked? In-Reply-To: <87hc9lgcac.fsf@gmail.com> References: <87hc9lgcac.fsf@gmail.com> Message-ID: <0923D727-69E1-4D2D-8867-91CDBD2730CB@ece.cmu.edu> On 2008 Aug 16, at 12:22, Changying Li wrote: > test.hs: /tmp/b: hGetChar: end of file > > test.hs: /tmp/c: hGetChar: end of file > > > I think the thread will be blocked when /tmp/b has nothing. > but it get EOF, why ? Because FIFOs are odd. Open them for read/write to avoid unexpected EOFs and unexpected blocking. -- 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 andrewcoppin at btinternet.com Sat Aug 16 13:22:08 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Aug 16 13:21:08 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <747330.43946.qm@web65705.mail.ac4.yahoo.com> References: <747330.43946.qm@web65705.mail.ac4.yahoo.com> Message-ID: <48A70CC0.2040502@btinternet.com> Robert Greayer wrote: > This seems to be a common approach, but it runs counter to the objective of separating 'provenance' from module naming. 'Coppin' is (part of, sans version) the provenance of the hashtable implementation, so I'm not sure how this sort of scheme is better than just shoving the unique prefix at the front of the module, e.g. > > Coppin.Data.Hashtable > > Though embedding the provenance down in the hierarchy is a common pattern, I think it is can be pretty messy. For example, the Parsec package exposes many modules, including "Text.Parsec.String" and "Text.ParserCombinators.Parsec.Token" -- the provenance appears at different levels in the hierarchy. If you're going to shove the package name in there, it seems simpler to me to just shove it at the front: Parsec.Text.ParserCombinators.Token. The package mounting scheme might solve this (though it seems to me that it requires that source for packages be kept around. I may be wrong). > Yeah, as I said, it's not immediately obvious exactly what the best solution is. Maybe we just need to get everybody to come up with more inventive names than just "hashtable" or "binary". (E.g., We have several parsers already, but they all have distinctive names that are unlikely to clash. Maybe we just need to do that for everything? IDK.) >> (As I already pointed out, there's at least 3 packages called "bianry", > which is just confusing.) >> > > On hackage? I only see one with that the exact name "binary". > OK, that's interesting. Apparently something has changed. Last time I looked, there was "binary", "old-binary", "new-binary", "alt-binary" and so forth. (It seems there is now a "binary-strict", but it's pretty obvious how that relates to the normal "binary" package.) Obviously, having this profusion of nearly identical names is just confusing. From allbery at ece.cmu.edu Sat Aug 16 13:28:11 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Aug 16 13:27:23 2008 Subject: [Haskell-cafe] What's in a name? In-Reply-To: <48A70CC0.2040502@btinternet.com> References: <747330.43946.qm@web65705.mail.ac4.yahoo.com> <48A70CC0.2040502@btinternet.com> Message-ID: On 2008 Aug 16, at 13:22, Andrew Coppin wrote: > Yeah, as I said, it's not immediately obvious exactly what the best > solution is. Maybe we just need to get everybody to come up with > more inventive names than just "hashtable" or "binary". (E.g., We > have several parsers already, but they all have distinctive names > that are unlikely to clash. Maybe we just need to do that for > everything? IDK.) The names should really be more descriptive. What makes hashtable A different/distinct from hashtable B? What's so special about new- binary? -- 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 ramsdell0 at gmail.com Sat Aug 16 15:38:54 2008 From: ramsdell0 at gmail.com (John D. Ramsdell) Date: Sat Aug 16 15:38:01 2008 Subject: [Haskell-cafe] permutations and performance Message-ID: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> I tried to replace a permutation generator with one that generates each permutation from the previous one, in a stream-like fashion. I had hoped the stream-based algorithm would be more efficient because I use only one permutation at a time, so only the permutation and the previous one need be in memory at one time. I thought I'd share the results of testing the two algorithms. I first forced the algorithms to produce answers by printing the length of their results. Bad idea. The stream-based algorithm produces a stack overflow on an input that it can handle when the contents of every permutation is forced. In this run, touch = length. $ ghc -O perms.lhs $ echo '(True, 9)' | ./a.out Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. $ echo '(False, 9)' | ./a.out 362880 $ I forced all parts of the computation by summing all of the numbers in the output. The result show the more obvious algorithm is faster. $ ghc -O perms.lhs $ echo '(True, 12)' | time ./a.out 31614105600 299.56user 0.97system 5:00.75elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+479minor)pagefaults 0swaps $ echo '(False, 12)' | time ./a.out 31614105600 213.86user 0.55system 3:34.90elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+841minor)pagefaults 0swaps $ > module Main(main) where > main = > do (new, n) <- readLn :: IO (Bool, Int) > case new of > True -> print $ touch $ npermutations n > False -> print $ touch $ permutations n Touch all the numbers in the output. Originally, touch = length. > touch :: [[Int]] -> Int > touch xs = > sum (map sum xs) The permutation algorithm used by Serge Mechveliani in The Algebraic Domain Constructor DoCon. The idea of the algorithm was suggested to him by S.M.Abramov. > npermutations :: Int -> [[Int]] > npermutations n = > first : next (spanMonotoneous first) > where > first = take n [0..] > next (_ , []) = [] > next (decr, j:js) = > p : next (spanMonotoneous p) > where > p = concat [reverse smallers, [j], reverse greaters, [i], js] > (greaters, i:smallers) = span (> j) decr > spanMonotoneous (x:y:xs) > | x <= y = ([x], y:xs) > | otherwise = (x:ys, zs) > where > (ys,zs) = spanMonotoneous (y:xs) > spanMonotoneous xs = (xs, []) > p : next (spanMonotoneous p) > where > p = concat [reverse smallers, [j], reverse greaters, [i], js] > (greaters, i:smallers) = span (> j) decr > spanMonotoneous (x:y:xs) > | x <= y = ([x], y:xs) > | otherwise = (x:ys, zs) > where > (ys,zs) = spanMonotoneous (y:xs) > spanMonotoneous xs = (xs, []) Straight forward permation algorithm. > permutations :: Int -> [[Int]] > permutations n > | n <= 0 = [] > | n == 1 = [[0]] > | otherwise = > concatMap (insertAtAllPos (n - 1)) (permutations (n - 1)) > where > insertAtAllPos x [] = [[x]] > insertAtAllPos x (y : l) = > (x : y : l) : map (y :) (insertAtAllPos x l) From lemming at henning-thielemann.de Sat Aug 16 15:53:23 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Aug 16 15:51:16 2008 Subject: [Haskell-cafe] permutations and performance In-Reply-To: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> References: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> Message-ID: <48A73033.2080800@henning-thielemann.de> John D. Ramsdell wrote: > Straight forward permation algorithm. > >> permutations :: Int -> [[Int]] >> permutations n >> | n <= 0 = [] >> | n == 1 = [[0]] Btw. I think that case is redundant. >> | otherwise = >> concatMap (insertAtAllPos (n - 1)) (permutations (n - 1)) >> where >> insertAtAllPos x [] = [[x]] >> insertAtAllPos x (y : l) = >> (x : y : l) : map (y :) (insertAtAllPos x l) From ben.franksen at online.de Sat Aug 16 16:12:51 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sat Aug 16 16:12:06 2008 Subject: [Haskell-cafe] Re: Phantoms References: <4899E8E7.6090000@btinternet.com> Message-ID: Jason Dagit wrote: > On Wed, Aug 6, 2008 at 11:09 AM, Andrew Coppin > wrote: > >> I just (re)discovered that I can do things like >> >> data Foo x = Foo Int Int >> >> Now "Foo Int" and "Foo Double" are, as far as the type checker cares, two >> completely different types, even though in fact they are the same. This >> is actually Quite Useful, in the particular case I'm working on. > > Phantom types are indeed useful for many things, but a bit of cautionary > advice. If you start to depend on the phantoms for type safety AND you > export your data constructors then you run a serious risk of being type > unsafe. Bonus points if you can demonstrate an equivalent of > unsafeCoerce# this way. This would be very bad, but I doubt it is possible. > Example: > fooCast :: Foo Int -> Foo Double > fooCast (Foo x) = Foo x > > On noes! We just cast that Foo Int to a Foo Double without changing it! What's the problem? > It works because the value on the RHS is consider freshly constructed and > other than sharing x it is unrelated to the one on the LHS. Right. You must call the data constructor Foo in order to exploit that it has the type Foo :: Int -> Foo a I don't see how this is not type safe, and I was not able to produce an #unsafeCoerce with this technique. One would need some unFoo a -> a but the a in data Foo a is phantom, i.e. there is no thing of type a in a Foo. Cheers Ben From aslatter at gmail.com Sat Aug 16 17:07:25 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sat Aug 16 17:06:31 2008 Subject: [Haskell-cafe] X Haskell Bindings Message-ID: <694519c50808161407r1e965eb6r78157b98bf43baa3@mail.gmail.com> Haskellers, I'm slowly porting XCB (the X C Bindings) to Haskell, and I would like input from any interested parties. The following is a summary of my plan so far. I'm interested in hearing any suggestions or concerns about what a Haskell library for writing X clients should look like. This is not a release announcement, and I can't make any promises about when this will be delivered. Code is available in darcs: -- darcs get http://community.haskell.org/~aslatter/code/xhb Some of the advantages XCB claims over xlib are: + smaller API + latency hiding when communicating with the X server + direct access to the X protocol + improved threading support + easier to extend What I plan for the X Haskell Bindings (XHB) are as follows: + All requests to the server are non-blocking (under most circumstances) + Requests which produce a reply from the server return a "token" or "receipt" + The caller may then, at a time of their choosing, query the receipt for the response (or error) from the server. This query is blocking. The API will look something like: > -- | Create a window as specified > createWindow :: Connection -> CreateWindow -> IO () > -- | Instruct the server that it should begin displaying the named window > mapWindow :: Connection -> WINDOW -> IO () > -- | List all of the extensions supported by the server > listExtensions :: Connection -> IO (Receipt (ListExtensionsReply)) > -- | Query a receipt for a response > getReply :: Receipt a -> IO (Either XError a) Note that the first two requests do not have replies, whereas the third request expects a reply from the server. Since the request to create a window has so many parameters, these parameters are all wrapped up into a "CreateWindow" data type, which is only ever used by the "createWindow" function. The "mapWindow" request only has one parameter, so it does not need it's own "MapWindow" data type. What I don't have planned out is what to do with the stream of events and errors that come back from the server. If an error is related to an outstanding receipt, it gets dumped there for the caller to examine directly. Other errors go into an error queue. Events go into a similar event queue. How should this queue be exposed in the API? Should the user of the library register an error/event callback? > registerErrorCallback :: Connection -> (XError -> IO ()) -> IO () Or is something like this enough: > pollForError :: Connection -> IO (Maybe (XError)) > waitForError :: Connection -> IO XError Each X extension defines its own set of errors and events (potentially). Should all of these be lumped together into one giant sum-type for errors and one for events? Take care, Antoine From schlepptop at henning-thielemann.de Sat Aug 16 17:28:40 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat Aug 16 17:26:32 2008 Subject: [Haskell-cafe] permutations and performance In-Reply-To: <7687290b0808161258l4e8bb09evcfa720ea8e329b43@mail.gmail.com> References: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> <48A73033.2080800@henning-thielemann.de> <7687290b0808161258l4e8bb09evcfa720ea8e329b43@mail.gmail.com> Message-ID: <48A74688.1090809@henning-thielemann.de> John D. Ramsdell schrieb: > Try deleting it and see what happens. Erm, yes, this case is wrong: >>>> | n <= 0 = [] There is _one_ permutation with no elements, namely [], thus it must be | n == 0 = [[]] From wren at freegeek.org Sun Aug 17 01:30:55 2008 From: wren at freegeek.org (wren ng thornton) Date: Sun Aug 17 01:30:03 2008 Subject: [Haskell-cafe] ANN: logfloat In-Reply-To: <48A62460.4020105@freegeek.org> References: <48A62460.4020105@freegeek.org> Message-ID: <48A7B78F.3080002@freegeek.org> -------------------------------------------- -- Announcing: logfloat 0.8.5 -------------------------------------------- New official release of the logfloat package for manipulating log-domain floating numbers. This is primarily a maintenance release updating the documentation and with minor tweaks on typeclass-restricted polymorphism. Substantively, I also broke out a new type class for numbers which can represent transfinite values. This is primarily to deal with issues about Rationals and other Fractional types which cannot represent them. I also decided to switch the code over to *.hs format so that the Hackage build bot can generate the documentation more reliably. -------------------------------------------- -- Description -------------------------------------------- The main reason for casting numbers into the log-domain is to prevent underflow when multiplying many small probabilities as is done in Hidden Markov Models and other statistical models often used for natural language processing. The log-domain also helps prevent overflow when multiplying many large numbers. In rare cases it can speed up numerical computation (since addition is faster than multiplication, though logarithms are exceptionally slow), but the primary goal is to improve accuracy of results. A secondary goal has been to maximize efficiency since these computations are frequently done within a /O(n^3)/ loop. The Data.Numeric.LogFloat module provides a new data type LogFloat which handles all the conversions and optimizations and can be treated as any other number thanks to type classes. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ -- Live well, ~wren From vigalchin at gmail.com Sun Aug 17 06:02:18 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sun Aug 17 06:01:24 2008 Subject: [Haskell-cafe] Sun OpenSPARC project? Message-ID: <5ae4f2ba0808170302x14a90106wc43e9173e64b384b@mail.gmail.com> Hello, Is this project open to the entire Haskell community or only students? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/375b82a6/attachment.htm From frank at geoinfo.tuwien.ac.at Sun Aug 17 06:21:56 2008 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Sun Aug 17 06:20:48 2008 Subject: [Haskell-cafe] duplicate symbols for ODBC-1.1.4.4 when running with GHCi Message-ID: <1218968516.8816.18.camel@bernH> when i run a program (which works with GHC) under GHCi (in eclipse with FP support) then i get GHCi linker duplicate definition for symbol _sqlSucceeded whilst processing .... HSHDBC-odbc-1.1.4.4.o what is wrong here? any suggestion what i can change? thank you andrew From frank at geoinfo.tuwien.ac.at Sun Aug 17 07:02:42 2008 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Sun Aug 17 07:01:33 2008 Subject: [Haskell-cafe] duplicate symbols for ODBC-1.1.4.4 when running with GHCi In-Reply-To: <1218968516.8816.18.camel@bernH> References: <1218968516.8816.18.camel@bernH> Message-ID: <1218970962.8816.21.camel@bernH> additional information - the problem occurs only under windows (with ghc 6.8.3), not under linux (ubuntu) - with ghc 6.8.2 with linux (ghc 6.8.2) it executes under ghci. On Sun, 2008-08-17 at 12:21 +0200, Andrew U. Frank wrote: > when i run a program (which works with GHC) under GHCi (in eclipse with > FP support) then i get > > GHCi linker > duplicate definition for symbol _sqlSucceeded > whilst processing .... HSHDBC-odbc-1.1.4.4.o > > what is wrong here? any suggestion what i can change? > > thank you > andrew > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mad.one at gmail.com Sun Aug 17 11:17:01 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sun Aug 17 11:16:08 2008 Subject: [Haskell-cafe] Houston-area FPers? Message-ID: <1218985861-sup-4729@existential.local> Hi, In less than a week I'll be moving to Houston TX in order to start school at university (University of Houston.) I'm wondering if there are any functional programmers (particularly haskellers) in that part of the state? If so, a group meeting and perhaps eventually a user-group would be lovely - if only to chat and talk about what everybody is working on for the time being until something more formal can be set up. I'm posting this a little early to try and get the most responses possible - unfortunately at the moment I will not have my own mode of transportation around town (see: car) and I'm not a houston native as you can see, so it will take time for me to get up to speed with college *and* getting around town, but if anybody is in that area I'd like to hear back from you. Austin From gale at sefer.org Sun Aug 17 11:27:05 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Aug 17 11:26:09 2008 Subject: [Haskell-cafe] permutations and performance In-Reply-To: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> References: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> Message-ID: <2608b8a80808170827n5b5cf016sdf1836e0bf499649@mail.gmail.com> John D. Ramsdell wrote: > I tried to replace a permutation generator with one that generates > each permutation from the previous one, in a stream-like fashion. I > had hoped the stream-based algorithm would be more efficient because I > use only one permutation at a time, so only the permutation and the > previous one need be in memory at one time. I thought I'd share the > results of testing the two algorithms. Yes, thanks for the interesting discussion. You may also be interested in the following recent thread: http://www.haskell.org/pipermail/libraries/2007-December/008788.html There, Twan van Laarhoven designs the implementation of the permutations function that is slated to be included in GHC 6.10. That implementation is pretty well tweaked for speed, while satisfying the following condition suggested by David Benbennick: map (take n) (take (factorial n) $ permutations [1..]) == permutations [1..n] It's also interesting that this function has an unusually long history for computer science. Some of the best algorithms were first discovered by English church bell ringers nearly 400 years ago. Knuth discusses permutations in Volume 4 Fascicle 2. Regards, Yitz From duncan.coutts at worc.ox.ac.uk Sun Aug 17 10:49:08 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 17 11:27:15 2008 Subject: [Haskell-cafe] Cabal has trouble with projects that have both src and lib directories? In-Reply-To: References: Message-ID: <1218984548.13639.137.camel@localhost> On Thu, 2008-08-14 at 22:32 -0400, Nicholas Andrews wrote: > Hi! > > I'm trying to set up a project with both src and lib directories with > cabal. My blah.cabal file looks like: > > Library > Build-Depends: base > Exposed-Modules: Foo > hs-source-dirs: lib/foo > > Executable hai > Build-depends: base > Main-is: Bar.hs > ghc-options: -O > hs-source-dirs: src/bar > Other-Modules: Foo > extra-libraries: Foo > extra-lib-dirs: lib/bar You will have to use: ? > Library > Build-Depends: base > Exposed-Modules: Foo > hs-source-dirs: lib/foo > > Executable hai > Build-depends: base > Main-is: Bar.hs > hs-source-dirs: src/bar, ?lib/bar > Other-Modules: Foo Theo only downside is that the module Foo will be built twice. > What's wrong? Currently there is no way for the hai executable to use "build-depends: blah", (though that's the obvious way in future that we could let an exe depend on a lib in the same package). See: http://hackage.haskell.org/trac/hackage/ticket/89 http://hackage.haskell.org/trac/hackage/ticket/276 Duncan From duncan.coutts at worc.ox.ac.uk Sun Aug 17 10:50:17 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 17 11:27:20 2008 Subject: [Haskell-cafe] GHC 6.8.3 binary for older linux In-Reply-To: References: Message-ID: <1218984617.13639.139.camel@localhost> On Thu, 2008-08-14 at 16:31 +0800, Agent Zhang wrote: > Halo~ > > I ran into the following error while trying to run a binary generated > by GHC 6.8.x on our production machines with a not-so-recent linux > installed (kernel 2.6.9). > > $ ./restyscript > restyscript: timer_create: Invalid argument You know we ran into this recently while trying to set up the new hoogle beta on haskell.org itself. (You may be surprised to know that haskell.org does not have ghc installed on it.) > So I decided to build a GHC 6.8.3 from source on that old system using > GHC 6.4.2. Fortunately, the binary GHC 6.4.2 from haskell.org does > work there. The newly-built GHC solves all the problem. No > floating-point exception nor invalid argument for timer_create. I've > put my binary distribution on my site here: > > http://agentzh.org/misc/ghc-6.8.3-i386-old-linux.tar.bz2 That may well be useful to people. Thanks for doing the work. Duncan From eric.kow at gmail.com Sun Aug 17 16:33:17 2008 From: eric.kow at gmail.com (Eric Y. Kow) Date: Sun Aug 17 16:32:29 2008 Subject: [Haskell-cafe] darcs hacking sprint (25-26 October) Message-ID: <20080817203317.GZ90292@Macintosh.local> Dear Haskellers, As Jason mentions, there has been recently been a lot of interest in darcs and an influx of new contributors. Thanks, everybody! Things are moving faster now with a few extra brains on board. We have some very ambitious plans, though and we still need all the help we can get. Do you think you might be interested in participating, but don't really know where to start? We may have just the solution for you: Darcs hacking sprint -------------------- You are cordially invited to hack on darcs with us for a weekend, specifically, that of 25-26 October. We will primarily be working on performance hacking of all sorts http://wiki.darcs.net/DarcsWiki/Roadmap If there are sufficient new hackers, I plan to prepare an overview and a set of starter tasks to help you get to grips with the darcs code. Venues ------ The venues are not yet fixed, although we have some tentative offers for space in London (thanks to Ganesh) and Portland (thanks to Galois). We will also be available via IRC, with some possibility for video-conferencing of some sort. For more information, please see http://wiki.darcs.net/index.html/Sprints If you have any suggestions for possible venues in London, please let me know. Our current London host can accommodate a handful of people, but we would love to have more people joining in on the fun! Also, if there are people who cannot make it to either London and Portland, perhaps you could gather into satellite teams? I hear Boulder, Colorado is a possibility. RSVP ---- If you would like to participate in any way, please let me know * when you are available (25/26 October) * roughly where you are based * if you are willing to travel Again, if you have suggestions for a good London venue, please send them my way. Many thanks! -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/a4194451/attachment.bin From eric.kow at gmail.com Sun Aug 17 16:46:27 2008 From: eric.kow at gmail.com (Eric Y. Kow) Date: Sun Aug 17 16:45:34 2008 Subject: [Haskell-cafe] Re: darcs hacking sprint (25-26 October) In-Reply-To: <20080817203317.GZ90292@Macintosh.local> References: <20080817203317.GZ90292@Macintosh.local> Message-ID: <20080817204627.GB90292@Macintosh.local> On Sun, Aug 17, 2008 at 21:33:17 +0100, Eric Y. Kow wrote: > The venues are not yet fixed, although we have some tentative offers for > space in London (thanks to Ganesh) and Portland (thanks to Galois). Correction! We have a tentative offer for space near *Cambridge* (thanks to Ganesh) and to Ian for picking up on the blunder. Thanks! -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/2849d7a9/attachment.bin From newsham at lava.net Sun Aug 17 17:26:55 2008 From: newsham at lava.net (Tim Newsham) Date: Sun Aug 17 17:26:01 2008 Subject: [Haskell-cafe] FRP question Message-ID: I'm interested in FRP, have read several of the papers and am wondering if it could be applied to writing multi-client server programs. What would be the input type events for such a system? What would be the output type events? How would the system handle the fact that it has to multiplex several IO streams (sockets)? I'm trying to answer these questions myself and having a hard time. Should input events include new connection requests and shutdowns? Individual bytes? Streams of bytes? or higher level PDUs? What kind of output should be generated? Full PDUs? streams of bytes? Pairs of (connection identifier,data)? How would such a system effectively hide the multiplexed IO going on? Is this sort of problem poorly suited for FRP? Tim Newsham http://www.thenewsh.com/~newsham/ From pedagand at gmail.com Sun Aug 17 19:38:32 2008 From: pedagand at gmail.com (Pierre-Evariste Dagand) Date: Sun Aug 17 19:37:36 2008 Subject: [Haskell-cafe] FRP question In-Reply-To: References: Message-ID: <6cb897b30808171638l55e48ceaj4ca17e35cb778a6@mail.gmail.com> Hi, > I'm interested in FRP, have read several of the papers and am wondering > if it could be applied to writing multi-client server programs. That's funny: in the last few months, I have developed a functional-reactive framework for large scale distributed system programming. You can find the source code and a technical report here: http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/ This code is in OCaml but the concepts can be translated in Haskell: advised by Conal Elliott, I have already written the core of Opis in Haskell (i.e the Arrow instances and a small network simulator) to ensure the feasibility of a purely functional implementation. The implementation in Haskell is based on the Mealy automaton while my code in OCaml efficiently emulates this construct (based on suggestions of Zheng Li, Oleg Kiselyov and Jacques Garrigue). > What would be the input type events for such a system? What would > be the output type events? How would the system handle the fact > that it has to multiplex several IO streams (sockets)? In my system, the input events are network events -- such as a received TCP message or a UDP packet as well as notifications (connection closed, listening on port X, ...) -- or timer events -- such as "a timer has just fired", "the timer is correctly set up" or "the timer has been removed" -- or user events -- whatever the user wants to signal. The outputs are commands to the "launcher" system: the launcher will collect these outputs and interpret them in term of (side-effecting) actions. For example, the reactive function might ask to "send the data D to peer x": thus, the launcher will connect to x, marshal the data and send it to x. Similarly, you can ask to listen on a network port, set up a timer, send an event to the user, ... The multiplexing is done out of the reactive function, in the launcher system. For networking, for instance, it opens one thread per open connection. Once a thread has retrieved a complete message, it sends it to reactive processing by a "Chan" (in Control.Concurrent). I hope the technical report is clearer than this rough description. I can send you a more "haskeller-friendly" paper if you are interested. > Should input events include new connection requests and shutdowns? New connection requests are silent whereas a connection shutdown raises an input event. > Individual bytes? Streams of bytes? or higher level PDUs? > What kind of output should be generated? Full PDUs? streams of > bytes? Pairs of (connection identifier,data)? I work at the message level. For instance, the reactive function outputs "Send( destination_ip , TCP, data )", then the launcher marshals "data" and sends it to "destination_ip". On the other side, the launcher marshals the received buffer of bytes to the same type and transmits "TCP_in( source_ip , data )" to the reactive function. Hence, for the reactive function, values are typed "end-to-end", hence reducing the risk of error in marshaling. > How would such a system effectively hide the multiplexed IO going on? Personally, I chose to hide this multiplexing on the "launcher" side, ie. out of the reactive function. As the "launcher" side is developed once and for all (by me), a Opis' user will not have to deal with multiplexing: she just has to care with processing well-defined inputs by reacting with the correct outputs. > Is this sort of problem poorly suited for FRP? According to my experience, developing peer-to-peer systems in Opis has been a great pleasure, because of its simplicity. On the other hand, my architecture is based on the Arrow type to build the reactive functions. Hence, I work hand-in-hand with the type-checker. When developing a protocol in Opis, it is sometimes like working with a theorem prover: if you forget that a given event could occur, the type-checker complains, for example. Hence, in the P2P field, my tool is a complete alien: people say that it looks great but don't want to invest time to learn it... :-( The "side-effects" of using purely functional structures are plentiful (and well-known here): ease of debugging of pure functions, modularity (given a reactive function, I can run it live on a network, simulate, debug, or model-check it without modification), ease of backtracking (useful for the debugger and the model-checker), reproducibility (see the complexity profiler), provability (see the use of Isabelle's certified code), and so on ... Currently, I'm developing a complete formalisation of the Mealy arrow instance in Coq and, hopefully, one day, I will be able to develop a complete P2P protocol in Coq ;-) Hope this inspires you, Regards, -- Pierre-Evariste DAGAND http://perso.eleves.bretagne.ens-cachan.fr/~dagand/ From spencerjanssen at gmail.com Sun Aug 17 20:34:42 2008 From: spencerjanssen at gmail.com (Spencer Janssen) Date: Sun Aug 17 20:31:42 2008 Subject: [Haskell-cafe] X Haskell Bindings In-Reply-To: <694519c50808161407r1e965eb6r78157b98bf43baa3@mail.gmail.com> References: <694519c50808161407r1e965eb6r78157b98bf43baa3@mail.gmail.com> Message-ID: <20080818003442.GA22625@celeborn> On Sat, Aug 16, 2008 at 04:07:25PM -0500, Antoine Latter wrote: > Haskellers, > > I'm slowly porting XCB (the X C Bindings) to Haskell, and I would like > input from any interested parties. > > The following is a summary of my plan so far. I'm interested in > hearing any suggestions or concerns about what a Haskell library for > writing X clients should look like. This is not a release > announcement, and I can't make any promises about when this will be > delivered. > > Code is available in darcs: > -- darcs get http://community.haskell.org/~aslatter/code/xhb > > Some of the advantages XCB claims over xlib are: > + smaller API > + latency hiding when communicating with the X server > + direct access to the X protocol > + improved threading support > + easier to extend > > What I plan for the X Haskell Bindings (XHB) are as follows: > > + All requests to the server are non-blocking (under most circumstances) > > + Requests which produce a reply from the server return a "token" or "receipt" > > + The caller may then, at a time of their choosing, query the receipt > for the response (or error) from the > server. This query is blocking. > > The API will look something like: > > > -- | Create a window as specified > > createWindow :: Connection -> CreateWindow -> IO () > > > -- | Instruct the server that it should begin displaying the named window > > mapWindow :: Connection -> WINDOW -> IO () > > > -- | List all of the extensions supported by the server > > listExtensions :: Connection -> IO (Receipt (ListExtensionsReply)) > > > -- | Query a receipt for a response > > getReply :: Receipt a -> IO (Either XError a) > > Note that the first two requests do not have replies, whereas the > third request expects a reply from the server. > > Since the request to create a window has so many parameters, these > parameters are all wrapped up into a "CreateWindow" data type, which > is only ever used by the "createWindow" function. The "mapWindow" > request only has one parameter, so it does not need it's own > "MapWindow" data type. I think this is a nice idea. This type signature from the X11 library is absolutely unmanageable: createWindow :: Display -> Window -> Position -> Position -> Dimension -> Dimension -> CInt -> CInt -> WindowClass -> Visual -> AttributeMask -> Ptr SetWindowAttributes -> IO Window > What I don't have planned out is what to do with the stream of events > and errors that come back from the server. > > If an error is related to an outstanding receipt, it gets dumped there > for the caller to examine directly. Other errors go into an error > queue. > > Events go into a similar event queue. > > How should this queue be exposed in the API? Should the user of the > library register an error/event callback? > > > registerErrorCallback :: Connection -> (XError -> IO ()) -> IO () Classic libX11 does this, and it is rather inconvenient to program with. Occasionally it is necessary to handle an error thrown by a specific request, yielding code like this: do h <- getHandler c -- save the old handler so we can restore it later setHandler c myHandlingFn performSomeActionsWhichMayFail setHandler c h Not only is this code ugly, it does not work correctly when the connection may be concurrently used by several threads. > Or is something like this enough: > > > pollForError :: Connection -> IO (Maybe (XError)) > > > waitForError :: Connection -> IO XError I think XCB's error system is particularly nice. Requests with no corresponding responses have two variants: unchecked (the default), and checked. Unchecked requests have a void return type, and any errors they generate go in the error queue. Checked requests return a cookie (the same mechanism used for requests with responses) which can be used to collect any errors generated by that response. > Each X extension defines its own set of errors and events > (potentially). Should all of these be lumped together into one giant > sum-type for errors and one for events? > > Take care, > Antoine Cheers, Spencer Janssen From allbery at ece.cmu.edu Sun Aug 17 21:18:45 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 17 21:18:04 2008 Subject: [Haskell-cafe] X Haskell Bindings In-Reply-To: <20080818003442.GA22625@celeborn> References: <694519c50808161407r1e965eb6r78157b98bf43baa3@mail.gmail.com> <20080818003442.GA22625@celeborn> Message-ID: On 2008 Aug 17, at 20:34, Spencer Janssen wrote: > On Sat, Aug 16, 2008 at 04:07:25PM -0500, Antoine Latter wrote: >> Since the request to create a window has so many parameters, these >> parameters are all wrapped up into a "CreateWindow" data type, which >> is only ever used by the "createWindow" function. The "mapWindow" >> request only has one parameter, so it does not need it's own >> "MapWindow" data type. > > I think this is a nice idea. This type signature from the X11 > library is > absolutely unmanageable: It's never been manageable, even from C (hence XCreateSimpleWindow() in Xlib which defaults most of that). > do h <- getHandler c -- save the old handler so we can restore it > later > setHandler c myHandlingFn > performSomeActionsWhichMayFail > setHandler c h > > Not only is this code ugly, it does not work correctly when the > connection may > be concurrently used by several threads. or when the async response comes after the handler's been reset (i.e. you need to call XSynchronize() and handle any errors before resetting the handler). -- 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 ramsdell0 at gmail.com Sun Aug 17 22:34:29 2008 From: ramsdell0 at gmail.com (John D. Ramsdell) Date: Sun Aug 17 22:33:34 2008 Subject: [Haskell-cafe] permutations and performance In-Reply-To: <2608b8a80808170827n5b5cf016sdf1836e0bf499649@mail.gmail.com> References: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> <2608b8a80808170827n5b5cf016sdf1836e0bf499649@mail.gmail.com> Message-ID: <7687290b0808171934j3cae92a7j37d1d34714ff6e66@mail.gmail.com> On Sun, Aug 17, 2008 at 11:27 AM, Yitzchak Gale wrote: > There, Twan van Laarhoven designs the implementation > of the permutations function that is slated to be included in > GHC 6.10. I look forward to Twan's design. I found the Haskell 1.3 definition. > -- permutations xs returns the list of all permutations of xs. > -- e.g., permutations "abc" == ["abc","bac","bca","acb","cab","cba"] > permutations :: [a] -> [[a]] > permutations [] = [[]] > permutations (x:xs) = [zs | ys <- permutations xs, zs <- interleave x ys ] > where interleave :: a -> [a] -> [[a]] > interleave x [] = [[x]] > interleave x (y:ys) = [x:y:ys] ++ map (y:) (interleave x ys) I like the use of list comprehension, but I was surprised the last line was not: > interleave x (y:ys) = (x:y:ys) : map (y:) (interleave x ys) John From ramsdell0 at gmail.com Sun Aug 17 22:40:30 2008 From: ramsdell0 at gmail.com (John D. Ramsdell) Date: Sun Aug 17 22:39:32 2008 Subject: [Haskell-cafe] permutations and performance In-Reply-To: <48A74688.1090809@henning-thielemann.de> References: <7687290b0808161238h4e7c28e3vea5b82ad5c60e9f1@mail.gmail.com> <48A73033.2080800@henning-thielemann.de> <7687290b0808161258l4e8bb09evcfa720ea8e329b43@mail.gmail.com> <48A74688.1090809@henning-thielemann.de> Message-ID: <7687290b0808171940y49c67e93n4866a276a5b8a50@mail.gmail.com> On Sat, Aug 16, 2008 at 5:28 PM, Henning Thielemann wrote: > There is _one_ permutation with no elements, namely [], thus it must be > | n == 0 = [[]] I see. John From vigalchin at gmail.com Sun Aug 17 22:47:33 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sun Aug 17 22:46:37 2008 Subject: [Haskell-cafe] Houston area FPers.... Message-ID: <5ae4f2ba0808171947v52dae7a2gf9582c1b31f50d20@mail.gmail.com> Hi Austin, I live next to the NASA Johnson Space Center. JSC is minutes away from Uof H Clear Lake. Which campus are you going to? (main campus?). Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/9a4978cd/attachment.htm From DekuDekuplex at Yahoo.com Sun Aug 17 23:05:48 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Sun Aug 17 23:04:59 2008 Subject: [Haskell-cafe] Re: Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc. References: <20080814211705.GH14958@scytale.galois.com> <5jeaa4hb5l8euunbpqct6n4ikdn4ugu97h@4ax.com> <20080815182946.GD19745@scytale.galois.com> Message-ID: On Fri, 15 Aug 2008 11:29:46 -0700, Don Stewart wrote: >DekuDekuplex: >> On Thu, 14 Aug 2008 14:17:05 -0700, Don Stewart >> wrote: >> >> >[...] >> > >> >Skills: >> > Proficiency and a strong interest in Haskell programming :) >> > >> > Bachelor's degree in computer science or equivalent from a four-year >> > institution. >> >> This is the required background of Haskell-related job offering that I >> am looking for, except that I happen to be located in Tokyo, Japan. > >Have you been to the Tokyo user group meetings? >They're organised by Starling software, so perhaps a good place to >network, > > http://www.starling-software.com/en/tsac.html Yes, but they were only interested in having me do some writing projects on a "non-commercial" basis, and I had to work a little late last time and wasn't able to arrive until shortly before the meeting was over, so I wasn't able to "network" much. Thanks for the tip, though. There is also a Japanese-language Category Theory study group that I often attend (see http://www.sampou.org/cgi-bin/haskell.cgi?CategoryTheory%3A%B7%F7%CF%C0%CA%D9%B6%AF%B2%F1) (the link target is in Japanese). Please let me know if you find anything else. -- Benjamin L. Russell From vigalchin at gmail.com Sun Aug 17 23:47:48 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sun Aug 17 23:46:50 2008 Subject: [Haskell-cafe] the cabal category field and "uploads" Message-ID: <5ae4f2ba0808172047l4189dd4coef7d45766cdf6e15@mail.gmail.com> Hi Ross, When I upload a code contribution, how do I specify which category in the Hackage database, e.g. System? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/43a6a9b7/attachment.htm From vigalchin at gmail.com Mon Aug 18 00:22:38 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Aug 18 00:21:43 2008 Subject: [Haskell-cafe] Re: Houston area FPers.... In-Reply-To: <5ae4f2ba0808171947v52dae7a2gf9582c1b31f50d20@mail.gmail.com> References: <5ae4f2ba0808171947v52dae7a2gf9582c1b31f50d20@mail.gmail.com> Message-ID: <5ae4f2ba0808172122k3df095e4r46e6eca18b087cb@mail.gmail.com> Austin, I have a friend (a former tech lead) at Google who told me that http://www.cs.rice.edu/~taha/ ... is doing FP research Rice U. Kind regards, Vasili On Sun, Aug 17, 2008 at 9:47 PM, Galchin, Vasili wrote: > Hi Austin, > > I live next to the NASA Johnson Space Center. JSC is minutes away > from Uof H Clear Lake. Which campus are you going to? (main campus?). > > Kind regards, Vasili > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/a116882b/attachment.htm From dons at galois.com Mon Aug 18 00:37:05 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 18 00:36:06 2008 Subject: [Haskell-cafe] the cabal category field and "uploads" In-Reply-To: <5ae4f2ba0808172047l4189dd4coef7d45766cdf6e15@mail.gmail.com> References: <5ae4f2ba0808172047l4189dd4coef7d45766cdf6e15@mail.gmail.com> Message-ID: <20080818043705.GA29062@scytale.galois.com> vigalchin: > Hi Ross, > > When I upload a code contribution, how do I specify which category in > the Hackage database, e.g. System? > add: category: System to your project's .cabal file From vigalchin at gmail.com Mon Aug 18 00:39:53 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Aug 18 00:38:56 2008 Subject: [Haskell-cafe] the cabal category field and "uploads" In-Reply-To: <20080818043705.GA29062@scytale.galois.com> References: <5ae4f2ba0808172047l4189dd4coef7d45766cdf6e15@mail.gmail.com> <20080818043705.GA29062@scytale.galois.com> Message-ID: <5ae4f2ba0808172139u6de10b68n54038b57abe7c898@mail.gmail.com> thanks, Don! Vasili ;^) On Sun, Aug 17, 2008 at 11:37 PM, Don Stewart wrote: > vigalchin: > > Hi Ross, > > > > When I upload a code contribution, how do I specify which > category in > > the Hackage database, e.g. System? > > > > add: > > category: System > > to your project's .cabal file > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/4ccf6d70/attachment.htm From dagit at codersbase.com Mon Aug 18 04:21:43 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Aug 18 04:20:45 2008 Subject: [Haskell-cafe] Re: Phantoms In-Reply-To: References: <4899E8E7.6090000@btinternet.com> Message-ID: On Sat, Aug 16, 2008 at 1:12 PM, Ben Franksen wrote: > > Jason Dagit wrote: > > On Wed, Aug 6, 2008 at 11:09 AM, Andrew Coppin > > wrote: > > > >> I just (re)discovered that I can do things like > >> > >> data Foo x = Foo Int Int > >> > >> Now "Foo Int" and "Foo Double" are, as far as the type checker cares, two > >> completely different types, even though in fact they are the same. This > >> is actually Quite Useful, in the particular case I'm working on. > > > > Phantom types are indeed useful for many things, but a bit of cautionary > > advice. If you start to depend on the phantoms for type safety AND you > > export your data constructors then you run a serious risk of being type > > unsafe. Bonus points if you can demonstrate an equivalent of > > unsafeCoerce# this way. > > This would be very bad, but I doubt it is possible. > > > Example: > > fooCast :: Foo Int -> Foo Double > > fooCast (Foo x) = Foo x > > > > On noes! We just cast that Foo Int to a Foo Double without changing it! > > What's the problem? It's not so bad if you keep in mind that it's possible. Sometimes it's exactly what you want. > > > It works because the value on the RHS is consider freshly constructed and > > other than sharing x it is unrelated to the one on the LHS. > > Right. You must call the data constructor Foo in order to exploit that it > has the type > > Foo :: Int -> Foo a > > I don't see how this is not type safe, and I was not able to produce an > #unsafeCoerce with this technique. One would need some > > unFoo a -> a > > but the a in data Foo a is phantom, i.e. there is no thing of type a > > in a Foo. Ah, it seems that the example I remembered cooking up requires GADTs, lexically scoped type variables and one unsafeCoerce#, so I guess it can be dismissed on the grounds that it uses unsafeCoerce# internally. I only need that because to make my thing work I need the following: data EqCheck a b where IsEq :: EqCheck a a NotEq :: EqCheck a b (=\/=) :: C a b -> C a c -> EqCheck b c Without unsafeCoerce# I don't see how to implement (=\/=). But, if you had that you could do the following: (=\/=) :: C a b -> C a c -> EqCheck b c a =\/= b | unC a == unC b = unsafeCoerce# IsEq | otherwise = NotEq data C x y = C String unsafeC :: String -> C x y unsafeC a = C a unC :: C x y -> String unC (C x) = x myCoerce :: forall a b. a -> b myCoerce x = fromJust $ do let ab = unsafeC "" :: C a b let aa = unsafeC "" :: C a a IsEq <- return $ aa =\/= ab return x Actually, it turns out that this also requires ghc 6.6. I just tried this out in both 6.6 and 6.8 and it turns out that in 6.8 the type checker was upgraded, in particular the way type checking works for GADTs was refined and the above program is rejected. I'm glad to see that myCoerce is not possible without using an unsafeCoerce# yourself. Thanks, Jason From vigalchin at gmail.com Mon Aug 18 04:37:25 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Aug 18 04:36:27 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file Message-ID: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> Hello, It seems to me that the "build depends" attribute/field is only informational, i.e. it doesn't cause "faulting in" dependencies if not present? If true, this seems to be a deficiency in cabal. ?? Kind regards, Vasili PS It seems to me that for HaskellDB the "build depends" is incomplete in that it should contain "old time" and "TextPrettyPrint.HughesPJ"?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080818/245a4304/attachment.htm From vigalchin at gmail.com Mon Aug 18 04:42:59 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Aug 18 04:42:01 2008 Subject: [Haskell-cafe] Re: "build depends:" in a .cabal file In-Reply-To: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> Message-ID: <5ae4f2ba0808180142n135b513ufa8c4506a8f3bc57@mail.gmail.com> cabal should access to currently installed packages from the package db. Just thinking out loud ... a digraph of dependencies would have to be built from "build depends" to drive possible "faulting in " .... On Mon, Aug 18, 2008 at 3:37 AM, Galchin, Vasili wrote: > Hello, > > It seems to me that the "build depends" attribute/field is only > informational, i.e. it doesn't cause "faulting in" dependencies if not > present? If true, this seems to be a deficiency in cabal. ?? > > Kind regards, Vasili > > PS It seems to me that for HaskellDB the "build depends" is incomplete in > that it should contain "old time" and "TextPrettyPrint.HughesPJ"?? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080818/52f404df/attachment.htm From kolar at fit.vutbr.cz Mon Aug 18 04:51:01 2008 From: kolar at fit.vutbr.cz (=?iso-8859-2?b?S29s4fgg?= =?iso-8859-2?b?RHW5YW4=?=) Date: Mon Aug 18 04:50:04 2008 Subject: [Haskell-cafe] Serial COM port access on Windows Message-ID: <20080818105101.1830443gm4stf2o0@email.fit.vutbr.cz> Dear all, Is there any more or less specific library for access to serial COM port from Haskell on Windows? Or am I expected to use a file mapping? Could you point me to some texts/examples? I tried some google (GHC specific) with no expected result. The issue is the following - I have a device communicating via Bluetooth with my PC, PC can create a serial COM port over the Bluetooth connection... I used C and a specific library for C so far, but I'd rather not encapsulate it by some Foreign calls in Haskell. Thanks for hints, Dusan From ryani.spam at gmail.com Mon Aug 18 05:14:05 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Aug 18 05:13:06 2008 Subject: [Haskell-cafe] FRP question In-Reply-To: References: Message-ID: <2f9b2d30808180214s7765ddb9g8230c485e3155285@mail.gmail.com> I think FRP is well-suited to this problem; it lets you abstract out the imperative network code from the "reactive core" of the code. The network code can live in a separate thread that uses select() and listen(), and updates event streams. I was thinking about writing a MUD using FRP; in my mind, the framework looked something like this: -- A connection is -- 1) An event that fires once when the connection is closed -- 2) An event that fires each time a line is received over the connection -- 3) A routine that outputs a line to that connection -- 4) A routine that closes the conection data Connection = Conn { connClosed :: Event () , connLines :: Event String , connWrite :: String -> IO () , connDisconnect :: IO () } -- Listen on a given port for connections and return them as an FRP event stream. -- Since Connection contains an event stream, this is going -- to be a nested event; we will use join/>>= on Event at some point to get the -- commands from each connection listen :: Int -> IO (Event Connection) -- the server is an FRP program that outputs an event stream of IO actions; -- the actions will generally just be "write a message to a particular socket" server :: Event Connection -> Event (IO ()) -- Now main is trivial to implement, given sinkE from Conal's FRP paper -- http://conal.net/papers/simply-reactive/ -- sinkE :: (a -> IO ()) -> Event a -> IO () main = listen 4200 >>= sinkE id . server -- An example server that writes "hello world" to each client and disconnects them server conns = do connection <- conns return $ do connWrite connection "Hello World." connDisconnect connection -- ryan On Sun, Aug 17, 2008 at 2:26 PM, Tim Newsham wrote: > I'm interested in FRP, have read several of the papers and am wondering > if it could be applied to writing multi-client server programs. > What would be the input type events for such a system? What would > be the output type events? How would the system handle the fact > that it has to multiplex several IO streams (sockets)? > > I'm trying to answer these questions myself and having a hard time. > Should input events include new connection requests and shutdowns? > Individual bytes? Streams of bytes? or higher level PDUs? > What kind of output should be generated? Full PDUs? streams of > bytes? Pairs of (connection identifier,data)? > How would such a system effectively hide the multiplexed IO going on? > Is this sort of problem poorly suited for FRP? > > Tim Newsham > http://www.thenewsh.com/~newsham/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lemming at henning-thielemann.de Mon Aug 18 05:15:06 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Aug 18 05:14:10 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> Message-ID: On Mon, 18 Aug 2008, Galchin, Vasili wrote: > Hello, > > It seems to me that the "build depends" attribute/field is only > informational, i.e. it doesn't cause "faulting in" dependencies if not > present? If true, this seems to be a deficiency in cabal. ?? At least when compiling with GHC, Cabal exposes only packages which are mentioned under Build-Depends. That is, if a package is missing in Build-Depends, the project cannot be compiled. It is however possible to forget modules in the Exposed-Modules and Other-Modules section and GHC finds them anyway. From frank at geoinfo.tuwien.ac.at Mon Aug 18 06:36:46 2008 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Mon Aug 18 06:35:30 2008 Subject: [Haskell-cafe] missingH 0.18.6 - problems with cabal configure In-Reply-To: References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> Message-ID: <1219055806.8816.29.camel@bernH> when i run cabal i get an error message: :~/haskellSources/packages/MissingH-0.18.6$ runhaskell Setup configure Setup.hs:19:35: Couldn't match expected type `(Either GenericPackageDescription PackageDescription, HookedBuildInfo)' against inferred type `PackageDescription' In the first argument of `(confHook defaultUserHooks)', namely `mydescrip' In the expression: let mydescrip = case os of "mingw32" -> ... _ -> ... in (confHook defaultUserHooks) mydescrip flags In the definition of `customConfHook': customConfHook descrip flags = let mydescrip = ... in (confHook defaultUserHooks) mydescrip flags what is wrong? i use ghc 6.8.2 and cabal 1.2.3.0 thanks for help! andrew From duncan.coutts at worc.ox.ac.uk Mon Aug 18 07:20:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 18 07:19:14 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> Message-ID: <1219058405.13639.204.camel@localhost> On Mon, 2008-08-18 at 03:37 -0500, Galchin, Vasili wrote: > Hello, > > It seems to me that the "build depends" attribute/field is only > informational, i.e. it doesn't cause "faulting in" dependencies if not > present? If true, this seems to be a deficiency in cabal. ?? I'm not quite sure what you mean. They are certainly not just informational. If you miss dependencies then the package will not compile. If by "faulting in" you mean downloading and installing missing dependencies, then that's exactly what the cabal-install tool does. As you mention in your other email, Cabal and cabal-install do indeed access the db of installed packages and build a dependency graph. cabal-install also uses a simple constraint solver to find a satisfactory dep graph of installable packages. Duncan From bjorn.buckwalter at gmail.com Mon Aug 18 10:24:56 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Mon Aug 18 10:25:39 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? Message-ID: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> All, I have a growing amount of astrodynamics code that relies on various physical "constants". The problem with these so called "constants" are that they either aren't really constants or aren't well known. An example is the leap second table (see Data.Time.Clock.TAI). I'd like to be able to fetch current values of these constants at runtime and make them accessible to my astrodynamics functions by some means. To clarify, once initialized the constants will be considered constant for the remainder of the program. I'd store the constants in a data structure along the lines of: > data AstroData a = AstroData > { mu_Earth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to "just what you need" and rendering the Reader monad obsolete... What do you people recommend? Thanks, Bjorn Buckwalter From bjorn.buckwalter at gmail.com Mon Aug 18 10:59:14 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Mon Aug 18 10:58:16 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? Message-ID: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> All, I have a growing amount of astrodynamics code that relies on various physical "constants". The problem with these so called "constants" are that they either aren't really constants or aren't well known. An example is the leap second table (see Data.Time.Clock.TAI). I'd like to be able to fetch current values of these constants at runtime and make them accessible to my astrodynamics functions by some means. To clarify, once initialized the constants will be considered constant for the remainder of the program. I'd store the constants in a data structure along the lines of: > data AstroData a = AstroData > { mu_Earth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to "just what you need" and rendering the Reader monad obsolete... What do you people recommend? Thanks, Bjorn Buckwalter From lemming at henning-thielemann.de Mon Aug 18 11:16:12 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Aug 18 11:15:28 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> Message-ID: On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > I would like to know if there is any consensus on what is the best way > to make such a data structure accessible in pure functions. Passing it > explicitly would be a mess. It seems that two options are to use > either a Reader monad or implicit parameters. Using a Reader monad is > straight forward enough though it requires writing/converting code > in/to monadic style and adds some clutter to the formulae. It seems > implicit parameters could be cleaner but I've seen them referred to as > everything from evil to "just what you need" and rendering the Reader > monad obsolete... I expect that you will get the same range of opinions as you got from your search. As far as I know implicit parameters break referential transparency. http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters So I prefer Reader monad. The burden of converting to monadic style pays off when you need to use the same code with different values for the "constants". (E.g. find out for which value of the Planck constant the universe collapses and for which it oscillates etc. :-) From bjorn.buckwalter at gmail.com Mon Aug 18 12:32:35 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Mon Aug 18 12:31:36 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> Message-ID: <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann wrote: > > On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > >> I would like to know if there is any consensus on what is the best way >> to make such a data structure accessible in pure functions. Passing it >> explicitly would be a mess. It seems that two options are to use >> either a Reader monad or implicit parameters. Using a Reader monad is >> straight forward enough though it requires writing/converting code >> in/to monadic style and adds some clutter to the formulae. It seems >> implicit parameters could be cleaner but I've seen them referred to as >> everything from evil to "just what you need" and rendering the Reader >> monad obsolete... > > I expect that you will get the same range of opinions as you got from your > search. As far as I know implicit parameters break referential transparency. > http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters > So I prefer Reader monad. The burden of converting to monadic style pays > off when you need to use the same code with different values for the > "constants". (E.g. find out for which value of the Planck constant the > universe collapses and for which it oscillates etc. :-) Love the example but could you elaborate a little on how monadic style helps with this? (This is probably a matter of it not being obvious to me what approach you would take to solving the problem.) By the way, can anyone comment on implicit parameters interacting with monadic code? If I were to use implicit parameters and later realize that I need other monadic functionality, e.g. Writer, would I be in a tough spot or would the implicit parameters continue to work "seemlesly" in the monadic code? Thanks, Bjorn Buckwalter From allbery at ece.cmu.edu Mon Aug 18 12:49:43 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 18 12:48:50 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> Message-ID: <6FE8DA6B-4FFE-470D-A56B-B73125601BC0@ece.cmu.edu> On 2008 Aug 18, at 10:59, Bjorn Buckwalter wrote: > I would like to know if there is any consensus on what is the best way > to make such a data structure accessible in pure functions. Passing it > explicitly would be a mess. It seems that two options are to use > either a Reader monad or implicit parameters. Using a Reader monad is > straight forward enough though it requires writing/converting code > in/to monadic style and adds some clutter to the formulae. It seems > implicit parameters could be cleaner but I've seen them referred to as > everything from evil to "just what you need" and rendering the Reader > monad obsolete... > > What do you people recommend? Last time I ran into this, I needed a Reader for other reasons so just reused it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Mon Aug 18 12:50:40 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 18 12:49:42 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> Message-ID: On 2008 Aug 18, at 11:16, Henning Thielemann wrote: > know implicit parameters break referential transparency. > http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters Are you making the same mistake I did? Linear implicit parameters are different from implicit parameters. -- 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 lemming at henning-thielemann.de Mon Aug 18 13:55:45 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Aug 18 13:54:43 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> Message-ID: On Mon, 18 Aug 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 18, at 11:16, Henning Thielemann wrote: >> know implicit parameters break referential transparency. >> http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters > > Are you making the same mistake I did? Linear implicit parameters are > different from implicit parameters. I haven't look into the details, so I certainly make any possible mistake. From lemming at henning-thielemann.de Mon Aug 18 14:02:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Aug 18 14:02:03 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> Message-ID: On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann > wrote: >> >> On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: >> >>> I would like to know if there is any consensus on what is the best way >>> to make such a data structure accessible in pure functions. Passing it >>> explicitly would be a mess. It seems that two options are to use >>> either a Reader monad or implicit parameters. Using a Reader monad is >>> straight forward enough though it requires writing/converting code >>> in/to monadic style and adds some clutter to the formulae. It seems >>> implicit parameters could be cleaner but I've seen them referred to as >>> everything from evil to "just what you need" and rendering the Reader >>> monad obsolete... >> >> I expect that you will get the same range of opinions as you got from your >> search. As far as I know implicit parameters break referential transparency. >> http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters >> So I prefer Reader monad. The burden of converting to monadic style pays >> off when you need to use the same code with different values for the >> "constants". (E.g. find out for which value of the Planck constant the >> universe collapses and for which it oscillates etc. :-) > > Love the example but could you elaborate a little on how monadic style > helps with this? (This is probably a matter of it not being obvious to > me what approach you would take to solving the problem.) Instead of muEarth :: GravitationalParameter a muEarth = ??? escapeVelocity :: a escapeVelocity = ... muEarth ... you would write data AstroData a = AstroData { muEarth :: GravitationalParameter a , leapSeconds :: LeapSecondTable } escapeVelocity :: Reader (AstroData a) a escapeVelocity = do mu <- asks muEarth return (... mu ...) Even better you would introduce a newtype for Reader (AstroData a). This way you can add any monadic functionality later (Writer et.al.). From bjorn.buckwalter at gmail.com Mon Aug 18 15:37:53 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Mon Aug 18 15:36:53 2008 Subject: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <8b2a1a960808181236h31bac586u7a59ccfafeaf24c2@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> <8b2a1a960808181236h31bac586u7a59ccfafeaf24c2@mail.gmail.com> Message-ID: <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann wrote: > > On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > >> On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann >> wrote: >>> >>> On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: >>> >>>> I would like to know if there is any consensus on what is the best way >>>> to make such a data structure accessible in pure functions. Passing it >>>> explicitly would be a mess. It seems that two options are to use >>>> either a Reader monad or implicit parameters. Using a Reader monad is >>>> straight forward enough though it requires writing/converting code >>>> in/to monadic style and adds some clutter to the formulae. It seems >>>> implicit parameters could be cleaner but I've seen them referred to as >>>> everything from evil to "just what you need" and rendering the Reader >>>> monad obsolete... >>> >>> I expect that you will get the same range of opinions as you got from >>> your >>> search. As far as I know implicit parameters break referential >>> transparency. >>> >>> http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters >>> So I prefer Reader monad. The burden of converting to monadic style pays >>> off when you need to use the same code with different values for the >>> "constants". (E.g. find out for which value of the Planck constant the >>> universe collapses and for which it oscillates etc. :-) >> >> Love the example but could you elaborate a little on how monadic style >> helps with this? (This is probably a matter of it not being obvious to >> me what approach you would take to solving the problem.) > > Instead of > muEarth :: GravitationalParameter a > muEarth = ??? > > escapeVelocity :: a > escapeVelocity = ... muEarth ... > > you would write > > data AstroData a = AstroData > { muEarth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } > > escapeVelocity :: Reader (AstroData a) a > escapeVelocity = > do mu <- asks muEarth > return (... mu ...) > > Even better you would introduce a newtype for Reader (AstroData a). This way > you can add any monadic functionality later (Writer et.al.). Right, and I'd evaluate it using e.g.: runReader escapeVelocity myAstroData But with implicit params I suppose I'd define (untested) e.g.: escapeVelocity :: (?astro :: AstroData a) => a escapeVelocity = ... mu ... where mu = muEarth ?astro To evaluate this I'd use: let ?astro = myAstroData in escapeVelocity Which is comparable to the Reader version (with the advantage/disadvantage of the body of 'escapeVelocity' not being monadic). In retrospect I think I misunderstood what you were saying in you first email. I thought you were arguing that the monadic style would have an advantage over implicit params in the Planck problem. But you probably only meant to reemphasize the advantage (of either solution) over hard-coding constants... Thanks again, your Reader example is virtually identical to what I started off with so at least I know I'm not completely off target for a monadic implementation. (Sorry about the reposts Henning, I keep forgetting to cc the caf?!) From schlepptop at henning-thielemann.de Mon Aug 18 15:47:18 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon Aug 18 15:46:13 2008 Subject: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> <8b2a1a960808181236h31bac586u7a59ccfafeaf24c2@mail.gmail.com> <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> Message-ID: <48A9D1C6.90902@henning-thielemann.de> Bjorn Buckwalter schrieb: > On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann >> wrote: >> >> Instead of >> muEarth :: GravitationalParameter a >> muEarth = ??? >> >> escapeVelocity :: a >> escapeVelocity = ... muEarth ... >> >> you would write >> >> data AstroData a = AstroData >> { muEarth :: GravitationalParameter a >> , leapSeconds :: LeapSecondTable >> } >> >> escapeVelocity :: Reader (AstroData a) a >> escapeVelocity = >> do mu <- asks muEarth >> return (... mu ...) >> >> Even better you would introduce a newtype for Reader (AstroData a). This way >> you can add any monadic functionality later (Writer et.al.). > > Right, and I'd evaluate it using e.g.: > > runReader escapeVelocity myAstroData > > But with implicit params I suppose I'd define (untested) e.g.: > > escapeVelocity :: (?astro :: AstroData a) => a > escapeVelocity = ... mu ... where mu = muEarth ?astro > > To evaluate this I'd use: > > let ?astro = myAstroData in escapeVelocity > > Which is comparable to the Reader version (with the > advantage/disadvantage of the body of 'escapeVelocity' not being > monadic). In my opinion the implicit parameters don't make things simpler, only less portable, that's why I prefer the Reader monad. > In retrospect I think I misunderstood what you were saying in you > first email. I thought you were arguing that the monadic style would > have an advantage over implicit params in the Planck problem. But you > probably only meant to reemphasize the advantage (of either solution) > over hard-coding constants... indeed From daveroundy at gmail.com Mon Aug 18 16:08:26 2008 From: daveroundy at gmail.com (David Roundy) Date: Mon Aug 18 16:07:32 2008 Subject: [Haskell-cafe] X Haskell Bindings In-Reply-To: <694519c50808161407r1e965eb6r78157b98bf43baa3@mail.gmail.com> References: <694519c50808161407r1e965eb6r78157b98bf43baa3@mail.gmail.com> Message-ID: <117f2cc80808181308s220b5660n74fc707e96fb9ff0@mail.gmail.com> On 8/16/08, Antoine Latter wrote: > The following is a summary of my plan so far. I'm interested in > hearing any suggestions or concerns about what a Haskell library for > writing X clients should look like. This is not a release > announcement, and I can't make any promises about when this will be > delivered. > > Code is available in darcs: > -- darcs get http://community.haskell.org/~aslatter/code/xhb > > Some of the advantages XCB claims over xlib are: > + smaller API > + latency hiding when communicating with the X server > + direct access to the X protocol > + improved threading support > + easier to extend > > What I plan for the X Haskell Bindings (XHB) are as follows: It seems to me that you could make this a bit more haskelly... > + All requests to the server are non-blocking (under most circumstances) > > + Requests which produce a reply from the server return a "token" or "receipt" Why not abstract this token or receipt into a function? i.e. why not change... > > -- | List all of the extensions supported by the server > > listExtensions :: Connection -> IO (Receipt (ListExtensionsReply)) > > > -- | Query a receipt for a response > > getReply :: Receipt a -> IO (Either XError a) to listExtensions :: Connection -> IO (IO ListExtensionsReply) and then you don't need to use a getReply, or a Receipt data type. This should be equally general, if (as I imagine) the only thing you can do with a Receipt is to getReply it. And to me it seems like a friendly way of describing what this function does. > Each X extension defines its own set of errors and events > (potentially). Should all of these be lumped together into one giant > sum-type for errors and one for events? Or maybe just a couple of existential types together with dynamic? (i.e. like xmonad's SomeMessage) David From qdunkan at gmail.com Mon Aug 18 16:20:45 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Aug 18 16:19:46 2008 Subject: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <48A9D1C6.90902@henning-thielemann.de> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> <8b2a1a960808181236h31bac586u7a59ccfafeaf24c2@mail.gmail.com> <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> <48A9D1C6.90902@henning-thielemann.de> Message-ID: <2518b95d0808181320h2ff28d80g109ff256553b4ca2@mail.gmail.com> >> Which is comparable to the Reader version (with the >> advantage/disadvantage of the body of 'escapeVelocity' not being >> monadic). > > In my opinion the implicit parameters don't make things simpler, only less > portable, that's why I prefer the Reader monad. They also seem to be removed from ghc: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html So it would probably be a mistake to write new code using them. As an aside, if that's really the complete patch I'm impressed how few lines were involved. 136 lines out of TcSimplify.lhs and misc tiny changes in other files. From allbery at ece.cmu.edu Mon Aug 18 16:24:07 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 18 16:23:11 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <2518b95d0808181320h2ff28d80g109ff256553b4ca2@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> <8b2a1a960808181236h31bac586u7a59ccfafeaf24c2@mail.gmail.com> <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> <48A9D1C6.90902@henning-thielemann.de> <2518b95d0808181320h2ff28d80g109ff256553b4ca2@mail.gmail.com> Message-ID: <4D655E13-F901-4FAB-8C78-CE56F7EF428B@ece.cmu.edu> On 2008 Aug 18, at 16:20, Evan Laforge wrote: >>> Which is comparable to the Reader version (with the >>> advantage/disadvantage of the body of 'escapeVelocity' not being >>> monadic). >> >> In my opinion the implicit parameters don't make things simpler, >> only less >> portable, that's why I prefer the Reader monad. > > They also seem to be removed from ghc: > > http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html Again, that's *linear* implicit parameters (%foo instead of ?foo). -- 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 kieran at us.ibm.com Mon Aug 18 16:36:52 2008 From: kieran at us.ibm.com (Kieran Beltran) Date: Mon Aug 18 16:36:38 2008 Subject: [Haskell-cafe] Kieran Beltran/Watson/IBM is out of the office. Message-ID: I will be out of the office starting 08/18/2008 and will not return until 08/25/2008. I will be on vacation for a few days. If this is urgent please reach my Admin Kristine Smester ((917) 472-3387), otherwise I will respond to your message when I return. From qdunkan at gmail.com Mon Aug 18 17:09:43 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Aug 18 17:08:43 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <4D655E13-F901-4FAB-8C78-CE56F7EF428B@ece.cmu.edu> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> <8b2a1a960808181236h31bac586u7a59ccfafeaf24c2@mail.gmail.com> <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> <48A9D1C6.90902@henning-thielemann.de> <2518b95d0808181320h2ff28d80g109ff256553b4ca2@mail.gmail.com> <4D655E13-F901-4FAB-8C78-CE56F7EF428B@ece.cmu.edu> Message-ID: <2518b95d0808181409q5c66d898yf682fd0f354cff21@mail.gmail.com> >> They also seem to be removed from ghc: >> >> http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html > > > Again, that's *linear* implicit parameters (%foo instead of ?foo). Oh, you're right. I made exactly the same mistake you made, and right after you warned against making it too. I always thought "linear" was the ? stuff, but now I see it's not. Maybe it's best that it's gone so we only have one flavor of "implicit parameters" feature from here on out. From vigalchin at gmail.com Mon Aug 18 17:12:22 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Aug 18 17:11:22 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: <1219058405.13639.204.camel@localhost> References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219058405.13639.204.camel@localhost> Message-ID: <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> . > > If by "faulting in" you mean downloading and installing missing > dependencies, then that's exactly what the cabal-install tool does. > This is exactly by "faulting in" .. an analogy ... Installing cabal-install seems to be a chicken and egg problem if enough packages are not already installed ... if not enough then one (me) can die of a thousand paper cuts bootstrapping packages up to where cabal-install can be installed. I am running Ubuntu Linux. Cabl-install is written in Haskell? If so, is there a pre-compiled Cabal-install that I can just install with all dependencies (packages) including. I also want to install HaskellDB painlessly ;^) ?? > > As you mention in your other email, Cabal and cabal-install do indeed > access the db of installed packages and build a dependency graph. > cabal-install also uses a simple constraint solver to find a > satisfactory dep graph of installable packages. > > > Duncan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080818/f43341ac/attachment.htm From dagit at codersbase.com Mon Aug 18 17:30:27 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Aug 18 17:29:27 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219058405.13639.204.camel@localhost> <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> Message-ID: 2008/8/18 Galchin, Vasili : > > >> . >> >> If by "faulting in" you mean downloading and installing missing >> dependencies, then that's exactly what the cabal-install tool does. > > This is exactly by "faulting in" .. an analogy ... > > Installing cabal-install seems to be a chicken and egg problem > if enough packages are not already installed ... if not enough then one > (me) can die of a thousand paper cuts bootstrapping packages up to where > cabal-install can be installed. I am running Ubuntu Linux. Cabl-install is > written in Haskell? If so, is there a pre-compiled Cabal-install that I can > just install with all dependencies (packages) including. I also want to > install HaskellDB painlessly ;^) ?? In my experience, with recent GHC there are only 3 packages needed to install cabal-install and it's pretty painless. You need zlib, HTTP and something else that I can't recall off the top of my head (but it tells you). Each of these packages can be had from hackage and they are very standard cabal installations. Sometimes you also need to upgrade cabal; I don't think this was an issue with ghc 6.8.2 and newer though. Cabal-install is worth the pain. Once you have a recent cabal-install it becomes painless to try out new packages via Hackage. And we have some very cool packages there these days. I really need to get all my side projects there so people can play with them. Jason From allbery at ece.cmu.edu Mon Aug 18 17:36:43 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 18 17:35:45 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <2518b95d0808181409q5c66d898yf682fd0f354cff21@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> <8b2a1a960808181236h31bac586u7a59ccfafeaf24c2@mail.gmail.com> <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> <48A9D1C6.90902@henning-thielemann.de> <2518b95d0808181320h2ff28d80g109ff256553b4ca2@mail.gmail.com> <4D655E13-F901-4FAB-8C78-CE56F7EF428B@ece.cmu.edu> <2518b95d0808181409q5c66d898yf682fd0f354cff21@mail.gmail.com> Message-ID: <0B7B17CC-96CD-490C-97E4-7F39EA13745A@ece.cmu.edu> On 2008 Aug 18, at 17:09, Evan Laforge wrote: >>> They also seem to be removed from ghc: >>> >>> http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html >> >> >> Again, that's *linear* implicit parameters (%foo instead of ?foo). > > Oh, you're right. I made exactly the same mistake you made, and right > after you warned against making it too. I always thought "linear" was > the ? stuff, but now I see it's not. Maybe it's best that it's gone > so we only have one flavor of "implicit parameters" feature from here > on out. Don't feel too bad; the main reason I'm commenting on it is I managed to confuse a bunch of people in public before I was set straight on it, so I kinda feel a bit guilty when people are confused by it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From derek.a.elkins at gmail.com Mon Aug 18 17:39:00 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Aug 18 17:38:04 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219058405.13639.204.camel@localhost> <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> Message-ID: <1219095540.13277.103.camel@derek-laptop> On Mon, 2008-08-18 at 14:30 -0700, Jason Dagit wrote: > 2008/8/18 Galchin, Vasili : > > > > > >> . > >> > >> If by "faulting in" you mean downloading and installing missing > >> dependencies, then that's exactly what the cabal-install tool does. > > > > This is exactly by "faulting in" .. an analogy ... > > > > Installing cabal-install seems to be a chicken and egg problem > > if enough packages are not already installed ... if not enough then one > > (me) can die of a thousand paper cuts bootstrapping packages up to where > > cabal-install can be installed. I am running Ubuntu Linux. Cabl-install is > > written in Haskell? If so, is there a pre-compiled Cabal-install that I can > > just install with all dependencies (packages) including. I also want to > > install HaskellDB painlessly ;^) ?? > > In my experience, with recent GHC there are only 3 packages needed to > install cabal-install and it's pretty painless. You need zlib, HTTP > and something else that I can't recall off the top of my head (but it > tells you). Each of these packages can be had from hackage and they > are very standard cabal installations. Sometimes you also need to > upgrade cabal; I don't think this was an issue with ghc 6.8.2 and > newer though. > > Cabal-install is worth the pain. Once you have a recent cabal-install > it becomes painless to try out new packages via Hackage. And we have > some very cool packages there these days. I really need to get all my > side projects there so people can play with them. > > Don't forget that once you get cabal-install going the first time you can upgrade via cabal install cabal-install. From allbery at ece.cmu.edu Mon Aug 18 17:41:05 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 18 17:40:07 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219058405.13639.204.camel@localhost> <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> Message-ID: <28B0DE60-21B6-4346-9A10-BE11E3F435D3@ece.cmu.edu> On 2008 Aug 18, at 17:30, Jason Dagit wrote: > In my experience, with recent GHC there are only 3 packages needed to > install cabal-install and it's pretty painless. You need zlib, HTTP > and something else that I can't recall off the top of my head (but it > tells you). Each of these packages can be had from hackage and they > are very standard cabal installations. Sometimes you also need to > upgrade cabal; I don't think this was an issue with ghc 6.8.2 and > newer though. When I installed cabal-install under 6.8.2 I also had to get a Cabal 1.4 prerelease from darcs, IIRC. cabal-install would be helped a lot by either (a) being folded into Cabal, and in particular the Cabal that comes with GHC; or, failing that, (b) being available as a prebuilt bootstrap package. -- 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 catamorphism at gmail.com Mon Aug 18 20:49:55 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon Aug 18 20:48:54 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 Message-ID: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> Hi all, I uploaded to Hackage a little program I wrote to organize my music file collection in the hopes that someone else might find it useful too: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert I had a directory tree full of .wav files that I ripped from CDs at times when I didn't want to wait for an .mp3 or .ogg encoder to run. The trouble is that .wav files don't have metadata (ID3 tags) that specify artist, album and track names. So, wavconvert takes a directory tree as an argument, and converts any .wav files in it to .ogg (using an external OGG encoder) while filling in the ID3 tags based on the directory names. The name is a bit misleading, since this is not an OGG encoder written in Haskell; it just handles invoking an existing encoder with the right flags to set the metadata. I'd welcome any patches to make this more generally useful (as it is, it assumes a particular file structure and OGG encoder.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Research is what I'm doing when I don't know what I'm doing."--Wernher von Braun From duncan.coutts at worc.ox.ac.uk Mon Aug 18 19:20:17 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 18 20:52:00 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: <28B0DE60-21B6-4346-9A10-BE11E3F435D3@ece.cmu.edu> References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219058405.13639.204.camel@localhost> <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> <28B0DE60-21B6-4346-9A10-BE11E3F435D3@ece.cmu.edu> Message-ID: <1219101617.13639.221.camel@localhost> On Mon, 2008-08-18 at 17:41 -0400, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 18, at 17:30, Jason Dagit wrote: > > In my experience, with recent GHC there are only 3 packages needed to > > install cabal-install and it's pretty painless. You need zlib, HTTP > > and something else that I can't recall off the top of my head (but it > > tells you). Each of these packages can be had from hackage and they > > are very standard cabal installations. Sometimes you also need to > > upgrade cabal; I don't think this was an issue with ghc 6.8.2 and > > newer though. > > When I installed cabal-install under 6.8.2 I also had to get a Cabal > 1.4 prerelease from darcs, IIRC. Which is now released on hackage. It's all on hackage. > cabal-install would be helped a lot by either (a) being folded into > Cabal, and in particular the Cabal that comes with GHC; or, failing > that, (b) being available as a prebuilt bootstrap package. We cannot fold it into the Cabal lib package but it will come with the first Haskell Platform release. Now that the development version can re-install itself on Windows (you've no idea how painful windows makes this) I might make a pre-built .exe version available. Duncan From dons at galois.com Mon Aug 18 21:22:06 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 18 21:21:08 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> Message-ID: <20080819012206.GA1191@scytale.galois.com> catamorphism: > Hi all, > > I uploaded to Hackage a little program I wrote to organize my music > file collection in the hopes that someone else might find it useful > too: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert Tim wins the prize for the 500th Haskell package in Arch Linux, http://aur.archlinux.org/packages.php?ID=19205 -- Don From duncan.coutts at worc.ox.ac.uk Mon Aug 18 22:02:47 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 18 22:01:56 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <20080819012206.GA1191@scytale.galois.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> Message-ID: <1219111367.13639.252.camel@localhost> On Mon, 2008-08-18 at 18:22 -0700, Don Stewart wrote: > Tim wins the prize for the 500th Haskell package in Arch Linux, > > http://aur.archlinux.org/packages.php?ID=19205 Which, I should like to note, demonstrates why the original Cabal design[1] was basically right[2] in that it allows this kind of automated translation into native packages. You cannot do that with autoconf. The other distros are following a similar course though not yet quite as successfully as Don has demonstrated for Arch. There are similar translation tools for Gentoo, Debian and RPM-based distros with varying levels of sophistication and automation. I think the folks who hack on these translation tools should get together and share code and experience so we can all achieve better levels of automation. The highest levels of automation will also require more centralised QA on hackage. That's where we should be going. Duncan [1] http://haskell.org/cabal/proposal/index.html [2] I'm not at all claiming credit for that design. That was decided well before I started hacking on Cabal. From onlyforjob at 163.com Mon Aug 18 22:04:18 2008 From: onlyforjob at 163.com (shoulders) Date: Mon Aug 18 22:03:17 2008 Subject: [Haskell-cafe] how can I receive the mail? In-Reply-To: <20080818202319.185203243B9@www.haskell.org> References: <20080818202319.185203243B9@www.haskell.org> Message-ID: <000001c9019f$e5f84250$8653a8c0@synnex.org> -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] =B4=FA=B1=ED = haskell-cafe-request@haskell. org =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA8=D4=C219=C8=D5 4:23 =CA=D5=BC=FE=C8=CB: haskell-cafe@haskell.org =D6=F7=CC=E2: Haskell-Cafe Digest, Vol 60, Issue 20 Send Haskell-Cafe mailing list submissions to haskell-cafe@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/haskell-cafe or, via email, send a message with subject or body 'help' to haskell-cafe-request@haskell.org You can reach the person managing the list at haskell-cafe-owner@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Haskell-Cafe digest..." Today's Topics: 1. Re: permutations and performance (John D. Ramsdell) 2. Houston area FPers.... (Galchin, Vasili) 3. Re: Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc. (Benjamin L.Russell) 4. the cabal category field and "uploads" (Galchin, Vasili) 5. Re: Houston area FPers.... (Galchin, Vasili) 6. Re: the cabal category field and "uploads" (Don Stewart) 7. Re: the cabal category field and "uploads" (Galchin, Vasili) 8. Re: Re: Phantoms (Jason Dagit) 9. "build depends:" in a .cabal file (Galchin, Vasili) 10. Re: "build depends:" in a .cabal file (Galchin, Vasili) 11. Serial COM port access on Windows ( Kol?? Du?an ) 12. Re: FRP question (Ryan Ingram) 13. Re: "build depends:" in a .cabal file (Henning Thielemann) 14. missingH 0.18.6 - problems with cabal configure (Andrew U. Frank) 15. Re: "build depends:" in a .cabal file (Duncan Coutts) 16. Reader monad, implicit parameters, or something else altogether? (Bjorn Buckwalter) 17. Reader monad, implicit parameters, or something else altogether? (Bjorn Buckwalter) 18. Re: Reader monad, implicit parameters, or something else altogether? (Henning Thielemann) 19. Re: Reader monad, implicit parameters, or something else altogether? (Bjorn Buckwalter) 20. Re: Reader monad, implicit parameters, or something else altogether? (Brandon S. Allbery KF8NH) 21. Re: Reader monad, implicit parameters, or something else altogether? (Brandon S. Allbery KF8NH) 22. Re: Reader monad, implicit parameters, or something else altogether? (Henning Thielemann) 23. Re: Reader monad, implicit parameters, or something else altogether? (Henning Thielemann) 24. Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? (Bjorn Buckwalter) 25. Re: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? (Henning Thielemann) 26. Re: X Haskell Bindings (David Roundy) 27. Re: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? (Evan Laforge) 28. Re: Reader monad, implicit parameters, or something else altogether? (Brandon S. Allbery KF8NH) ---------------------------------------------------------------------- Message: 1 Date: Sun, 17 Aug 2008 22:40:30 -0400 From: "John D. Ramsdell" Subject: Re: [Haskell-cafe] permutations and performance To: "Henning Thielemann" Cc: Haskell Cafe Message-ID: <7687290b0808171940y49c67e93n4866a276a5b8a50@mail.gmail.com> Content-Type: text/plain; charset=3DUTF-8 On Sat, Aug 16, 2008 at 5:28 PM, Henning Thielemann wrote: > There is _one_ permutation with no elements, namely [], thus it must = be > | n =3D=3D 0 =3D [[]] I see. John ------------------------------ Message: 2 Date: Sun, 17 Aug 2008 21:47:33 -0500 From: "Galchin, Vasili" Subject: [Haskell-cafe] Houston area FPers.... To: mad.one@gmail.com Cc: Galchin Vasili , "haskell-cafe@haskell.org" Message-ID: <5ae4f2ba0808171947v52dae7a2gf9582c1b31f50d20@mail.gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" Hi Austin, I live next to the NASA Johnson Space Center. JSC is minutes away from Uof H Clear Lake. Which campus are you going to? (main campus?). Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/9a4978= cd/ attachment-0001.htm ------------------------------ Message: 3 Date: Mon, 18 Aug 2008 12:05:48 +0900 From: Benjamin L.Russell Subject: [Haskell-cafe] Re: Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc. To: haskell-cafe@haskell.org Message-ID: Content-Type: text/plain; charset=3Dus-ascii On Fri, 15 Aug 2008 11:29:46 -0700, Don Stewart wrote: >DekuDekuplex: >> On Thu, 14 Aug 2008 14:17:05 -0700, Don Stewart >> wrote: >>=20 >> >[...] >> > >> >Skills: >> > Proficiency and a strong interest in Haskell programming :) =20 >> > >> > Bachelor's degree in computer science or equivalent from a = four-year >> > institution. >>=20 >> This is the required background of Haskell-related job offering that = I >> am looking for, except that I happen to be located in Tokyo, Japan. > >Have you been to the Tokyo user group meetings?=20 >They're organised by Starling software, so perhaps a good place to >network, >=20 > http://www.starling-software.com/en/tsac.html Yes, but they were only interested in having me do some writing projects on a "non-commercial" basis, and I had to work a little late last time and wasn't able to arrive until shortly before the meeting was over, so I wasn't able to "network" much. Thanks for the tip, though. There is also a Japanese-language Category Theory study group that I often attend (see http://www.sampou.org/cgi-bin/haskell.cgi?CategoryTheory%3A%B7%F7%CF%C0%C= A%D 9%B6%AF%B2%F1) (the link target is in Japanese). Please let me know if you find anything else. -- Benjamin L. Russell ------------------------------ Message: 4 Date: Sun, 17 Aug 2008 22:47:48 -0500 From: "Galchin, Vasili" Subject: [Haskell-cafe] the cabal category field and "uploads" To: "Ross Paterson" Cc: Galchin Vasili , "haskell-cafe@haskell.org" Message-ID: <5ae4f2ba0808172047l4189dd4coef7d45766cdf6e15@mail.gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" Hi Ross, When I upload a code contribution, how do I specify which category = in the Hackage database, e.g. System? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/43a6a9= b7/ attachment-0001.htm ------------------------------ Message: 5 Date: Sun, 17 Aug 2008 23:22:38 -0500 From: "Galchin, Vasili" Subject: [Haskell-cafe] Re: Houston area FPers.... To: mad.one@gmail.com Cc: Galchin Vasili , "haskell-cafe@haskell.org" Message-ID: <5ae4f2ba0808172122k3df095e4r46e6eca18b087cb@mail.gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" Austin, I have a friend (a former tech lead) at Google who told me that http://www.cs.rice.edu/~taha/ ... is doing FP research Rice U. Kind regards, Vasili On Sun, Aug 17, 2008 at 9:47 PM, Galchin, Vasili = wrote: > Hi Austin, > > I live next to the NASA Johnson Space Center. JSC is minutes = away > from Uof H Clear Lake. Which campus are you going to? (main campus?). > > Kind regards, Vasili > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/a11688= 2b/ attachment-0001.htm ------------------------------ Message: 6 Date: Sun, 17 Aug 2008 21:37:05 -0700 From: Don Stewart Subject: Re: [Haskell-cafe] the cabal category field and "uploads" To: "Galchin, Vasili" Cc: Ross Paterson , "haskell-cafe@haskell.org" Message-ID: <20080818043705.GA29062@scytale.galois.com> Content-Type: text/plain; charset=3Dus-ascii vigalchin: > Hi Ross, >=20 > When I upload a code contribution, how do I specify which = category in > the Hackage database, e.g. System? >=20 add: category: System to your project's .cabal file ------------------------------ Message: 7 Date: Sun, 17 Aug 2008 23:39:53 -0500 From: "Galchin, Vasili" Subject: Re: [Haskell-cafe] the cabal category field and "uploads" To: "Don Stewart" Cc: Ross Paterson , "haskell-cafe@haskell.org" Message-ID: <5ae4f2ba0808172139u6de10b68n54038b57abe7c898@mail.gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" thanks, Don! Vasili ;^) On Sun, Aug 17, 2008 at 11:37 PM, Don Stewart wrote: > vigalchin: > > Hi Ross, > > > > When I upload a code contribution, how do I specify which > category in > > the Hackage database, e.g. System? > > > > add: > > category: System > > to your project's .cabal file > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080817/4ccf6d= 70/ attachment-0001.htm ------------------------------ Message: 8 Date: Mon, 18 Aug 2008 01:21:43 -0700 From: "Jason Dagit" Subject: Re: [Haskell-cafe] Re: Phantoms To: "Ben Franksen" Cc: haskell-cafe@haskell.org Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 On Sat, Aug 16, 2008 at 1:12 PM, Ben Franksen wrote: > > Jason Dagit wrote: > > On Wed, Aug 6, 2008 at 11:09 AM, Andrew Coppin > > wrote: > > > >> I just (re)discovered that I can do things like > >> > >> data Foo x =3D Foo Int Int > >> > >> Now "Foo Int" and "Foo Double" are, as far as the type checker = cares, two > >> completely different types, even though in fact they are the same. = This > >> is actually Quite Useful, in the particular case I'm working on. > > > > Phantom types are indeed useful for many things, but a bit of = cautionary > > advice. If you start to depend on the phantoms for type safety AND = you > > export your data constructors then you run a serious risk of being = type > > unsafe. Bonus points if you can demonstrate an equivalent of > > unsafeCoerce# this way. > > This would be very bad, but I doubt it is possible. > > > Example: > > fooCast :: Foo Int -> Foo Double > > fooCast (Foo x) =3D Foo x > > > > On noes! We just cast that Foo Int to a Foo Double without changing = it! > > What's the problem? It's not so bad if you keep in mind that it's possible. Sometimes it's exactly what you want. > > > It works because the value on the RHS is consider freshly = constructed and > > other than sharing x it is unrelated to the one on the LHS. > > Right. You must call the data constructor Foo in order to exploit that = it > has the type > > Foo :: Int -> Foo a > > I don't see how this is not type safe, and I was not able to produce = an > #unsafeCoerce with this technique. One would need some > > unFoo a -> a > > but the a in data Foo a is phantom, i.e. there is no thing of type = a > > in a Foo. Ah, it seems that the example I remembered cooking up requires GADTs, lexically scoped type variables and one unsafeCoerce#, so I guess it can be dismissed on the grounds that it uses unsafeCoerce# internally. I only need that because to make my thing work I need the following: data EqCheck a b where IsEq :: EqCheck a a NotEq :: EqCheck a b (=3D\/=3D) :: C a b -> C a c -> EqCheck b c Without unsafeCoerce# I don't see how to implement (=3D\/=3D). But, if you had that you could do the following: (=3D\/=3D) :: C a b -> C a c -> EqCheck b c a =3D\/=3D b | unC a =3D=3D unC b =3D unsafeCoerce# IsEq | otherwise =3D NotEq data C x y =3D C String unsafeC :: String -> C x y unsafeC a =3D C a unC :: C x y -> String unC (C x) =3D x myCoerce :: forall a b. a -> b myCoerce x =3D fromJust $ do let ab =3D unsafeC "" :: C a b let aa =3D unsafeC "" :: C a a IsEq <- return $ aa =3D\/=3D ab return x Actually, it turns out that this also requires ghc 6.6. I just tried this out in both 6.6 and 6.8 and it turns out that in 6.8 the type checker was upgraded, in particular the way type checking works for GADTs was refined and the above program is rejected. I'm glad to see that myCoerce is not possible without using an unsafeCoerce# yourself. Thanks, Jason ------------------------------ Message: 9 Date: Mon, 18 Aug 2008 03:37:25 -0500 From: "Galchin, Vasili" Subject: [Haskell-cafe] "build depends:" in a .cabal file To: "haskell-cafe@haskell.org" Cc: Galchin Vasili Message-ID: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" Hello, It seems to me that the "build depends" attribute/field is only informational, i.e. it doesn't cause "faulting in" dependencies if not present? If true, this seems to be a deficiency in cabal. ?? Kind regards, Vasili PS It seems to me that for HaskellDB the "build depends" is incomplete = in that it should contain "old time" and "TextPrettyPrint.HughesPJ"?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080818/245a43= 04/ attachment-0001.htm ------------------------------ Message: 10 Date: Mon, 18 Aug 2008 03:42:59 -0500 From: "Galchin, Vasili" Subject: [Haskell-cafe] Re: "build depends:" in a .cabal file To: "haskell-cafe@haskell.org" Cc: Galchin Vasili Message-ID: <5ae4f2ba0808180142n135b513ufa8c4506a8f3bc57@mail.gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" cabal should access to currently installed packages from the package db. Just thinking out loud ... a digraph of dependencies would have to be = built from "build depends" to drive possible "faulting in " .... On Mon, Aug 18, 2008 at 3:37 AM, Galchin, Vasili = wrote: > Hello, > > It seems to me that the "build depends" attribute/field is only > informational, i.e. it doesn't cause "faulting in" dependencies if not > present? If true, this seems to be a deficiency in cabal. ?? > > Kind regards, Vasili > > PS It seems to me that for HaskellDB the "build depends" is incomplete = in > that it should contain "old time" and "TextPrettyPrint.HughesPJ"?? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080818/52f404= df/ attachment-0001.htm ------------------------------ Message: 11 Date: Mon, 18 Aug 2008 10:51:01 +0200 From: " Kol?? Du?an " Subject: [Haskell-cafe] Serial COM port access on Windows To: "Haskell Cafe" Message-ID: <20080818105101.1830443gm4stf2o0@email.fit.vutbr.cz> Content-Type: text/plain; charset=3DISO-8859-2; DelSp=3D"Yes"; format=3D"flowed" Dear all, Is there any more or less specific library for access to serial COM =20 port from Haskell on Windows? Or am I expected to use a file mapping? =20 Could you point me to some texts/examples? I tried some google (GHC =20 specific) with no expected result. The issue is the following - I have a device communicating via =20 Bluetooth with my PC, PC can create a serial COM port over the =20 Bluetooth connection... I used C and a specific library for C so far, =20 but I'd rather not encapsulate it by some Foreign calls in Haskell. Thanks for hints, Dusan ------------------------------ Message: 12 Date: Mon, 18 Aug 2008 02:14:05 -0700 From: "Ryan Ingram" Subject: Re: [Haskell-cafe] FRP question To: "Tim Newsham" Cc: haskell-cafe@haskell.org Message-ID: <2f9b2d30808180214s7765ddb9g8230c485e3155285@mail.gmail.com> Content-Type: text/plain; charset=3DISO-8859-1 I think FRP is well-suited to this problem; it lets you abstract out the imperative network code from the "reactive core" of the code. The network code can live in a separate thread that uses select() and listen(), and updates event streams. I was thinking about writing a MUD using FRP; in my mind, the framework looked something like this: -- A connection is -- 1) An event that fires once when the connection is closed -- 2) An event that fires each time a line is received over the = connection -- 3) A routine that outputs a line to that connection -- 4) A routine that closes the conection data Connection =3D Conn { connClosed :: Event () , connLines :: Event String , connWrite :: String -> IO () , connDisconnect :: IO () } -- Listen on a given port for connections and return them as an FRP event stream. -- Since Connection contains an event stream, this is going -- to be a nested event; we will use join/>>=3D on Event at some point = to get the -- commands from each connection listen :: Int -> IO (Event Connection) -- the server is an FRP program that outputs an event stream of IO = actions; -- the actions will generally just be "write a message to a particular socket" server :: Event Connection -> Event (IO ()) -- Now main is trivial to implement, given sinkE from Conal's FRP paper -- http://conal.net/papers/simply-reactive/ -- sinkE :: (a -> IO ()) -> Event a -> IO () main =3D listen 4200 >>=3D sinkE id . server -- An example server that writes "hello world" to each client and disconnects them server conns =3D do connection <- conns return $ do connWrite connection "Hello World." connDisconnect connection -- ryan On Sun, Aug 17, 2008 at 2:26 PM, Tim Newsham wrote: > I'm interested in FRP, have read several of the papers and am = wondering > if it could be applied to writing multi-client server programs. > What would be the input type events for such a system? What would > be the output type events? How would the system handle the fact > that it has to multiplex several IO streams (sockets)? > > I'm trying to answer these questions myself and having a hard time. > Should input events include new connection requests and shutdowns? > Individual bytes? Streams of bytes? or higher level PDUs? > What kind of output should be generated? Full PDUs? streams of > bytes? Pairs of (connection identifier,data)? > How would such a system effectively hide the multiplexed IO going on? > Is this sort of problem poorly suited for FRP? > > Tim Newsham > http://www.thenewsh.com/~newsham/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ------------------------------ Message: 13 Date: Mon, 18 Aug 2008 11:15:06 +0200 (CEST) From: Henning Thielemann Subject: Re: [Haskell-cafe] "build depends:" in a .cabal file To: "Galchin, Vasili" Cc: "haskell-cafe@haskell.org" Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed On Mon, 18 Aug 2008, Galchin, Vasili wrote: > Hello, > > It seems to me that the "build depends" attribute/field is only > informational, i.e. it doesn't cause "faulting in" dependencies if not > present? If true, this seems to be a deficiency in cabal. ?? At least when compiling with GHC, Cabal exposes only packages which are=20 mentioned under Build-Depends. That is, if a package is missing in=20 Build-Depends, the project cannot be compiled. It is however possible to = forget modules in the Exposed-Modules and Other-Modules section and GHC=20 finds them anyway. ------------------------------ Message: 14 Date: Mon, 18 Aug 2008 12:36:46 +0200 From: "Andrew U. Frank" Subject: [Haskell-cafe] missingH 0.18.6 - problems with cabal configure To: "haskell-cafe@haskell.org" Message-ID: <1219055806.8816.29.camel@bernH> Content-Type: text/plain when i run cabal i get an error message: :~/haskellSources/packages/MissingH-0.18.6$ runhaskell Setup configure Setup.hs:19:35: Couldn't match expected type `(Either GenericPackageDescription PackageDescription, HookedBuildInfo)' against inferred type `PackageDescription' In the first argument of `(confHook defaultUserHooks)', namely `mydescrip' In the expression: let mydescrip =3D case os of "mingw32" -> ... _ -> ... in (confHook defaultUserHooks) mydescrip flags In the definition of `customConfHook': customConfHook descrip flags =3D let mydescrip =3D ... in (confHook defaultUserHooks) mydescrip flags what is wrong? i use ghc 6.8.2 and cabal 1.2.3.0 thanks for help! andrew ------------------------------ Message: 15 Date: Mon, 18 Aug 2008 12:20:05 +0100 From: Duncan Coutts Subject: Re: [Haskell-cafe] "build depends:" in a .cabal file To: "Galchin, Vasili" Cc: "haskell-cafe@haskell.org" Message-ID: <1219058405.13639.204.camel@localhost> Content-Type: text/plain On Mon, 2008-08-18 at 03:37 -0500, Galchin, Vasili wrote: > Hello, >=20 > It seems to me that the "build depends" attribute/field is only > informational, i.e. it doesn't cause "faulting in" dependencies if not > present? If true, this seems to be a deficiency in cabal. ?? I'm not quite sure what you mean. They are certainly not just informational. If you miss dependencies then the package will not compile. If by "faulting in" you mean downloading and installing missing dependencies, then that's exactly what the cabal-install tool does. As you mention in your other email, Cabal and cabal-install do indeed access the db of installed packages and build a dependency graph. cabal-install also uses a simple constraint solver to find a satisfactory dep graph of installable packages. Duncan ------------------------------ Message: 16 Date: Mon, 18 Aug 2008 10:24:56 -0400 From: "Bjorn Buckwalter" Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: "Haskell-Cafe Haskell-Cafe" Message-ID: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> Content-Type: text/plain; charset=3DISO-8859-1 All, I have a growing amount of astrodynamics code that relies on various physical "constants". The problem with these so called "constants" are that they either aren't really constants or aren't well known. An example is the leap second table (see Data.Time.Clock.TAI). I'd like to be able to fetch current values of these constants at runtime and make them accessible to my astrodynamics functions by some means. To clarify, once initialized the constants will be considered constant for the remainder of the program. I'd store the constants in a data structure along the lines of: > data AstroData a =3D AstroData > { mu_Earth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to "just what you need" and rendering the Reader monad obsolete... What do you people recommend? Thanks, Bjorn Buckwalter ------------------------------ Message: 17 Date: Mon, 18 Aug 2008 10:59:14 -0400 From: "Bjorn Buckwalter" Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: "Haskell-Cafe Haskell-Cafe" Message-ID: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> Content-Type: text/plain; charset=3DISO-8859-1 All, I have a growing amount of astrodynamics code that relies on various physical "constants". The problem with these so called "constants" are that they either aren't really constants or aren't well known. An example is the leap second table (see Data.Time.Clock.TAI). I'd like to be able to fetch current values of these constants at runtime and make them accessible to my astrodynamics functions by some means. To clarify, once initialized the constants will be considered constant for the remainder of the program. I'd store the constants in a data structure along the lines of: > data AstroData a =3D AstroData > { mu_Earth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to "just what you need" and rendering the Reader monad obsolete... What do you people recommend? Thanks, Bjorn Buckwalter ------------------------------ Message: 18 Date: Mon, 18 Aug 2008 17:16:12 +0200 (MEST) From: Henning Thielemann Subject: Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: Bjorn Buckwalter Cc: Haskell-Cafe Haskell-Cafe Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > I would like to know if there is any consensus on what is the best way > to make such a data structure accessible in pure functions. Passing it > explicitly would be a mess. It seems that two options are to use > either a Reader monad or implicit parameters. Using a Reader monad is > straight forward enough though it requires writing/converting code > in/to monadic style and adds some clutter to the formulae. It seems > implicit parameters could be cleaner but I've seen them referred to as > everything from evil to "just what you need" and rendering the Reader > monad obsolete... I expect that you will get the same range of opinions as you got from = your=20 search. As far as I know implicit parameters break referential=20 transparency. =20 http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearI= mpl icitParameters So I prefer Reader monad. The burden of converting to monadic style = pays=20 off when you need to use the same code with different values for the=20 "constants". (E.g. find out for which value of the Planck constant the=20 universe collapses and for which it oscillates etc. :-) ------------------------------ Message: 19 Date: Mon, 18 Aug 2008 12:32:35 -0400 From: "Bjorn Buckwalter" Subject: Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: "Henning Thielemann" Cc: Haskell-Cafe Haskell-Cafe Message-ID: <8b2a1a960808180932s6763eda9v727369a4ea1bc5fc@mail.gmail.com> Content-Type: text/plain; charset=3DISO-8859-1 On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann wrote: > > On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > >> I would like to know if there is any consensus on what is the best = way >> to make such a data structure accessible in pure functions. Passing = it >> explicitly would be a mess. It seems that two options are to use >> either a Reader monad or implicit parameters. Using a Reader monad is >> straight forward enough though it requires writing/converting code >> in/to monadic style and adds some clutter to the formulae. It seems >> implicit parameters could be cleaner but I've seen them referred to = as >> everything from evil to "just what you need" and rendering the Reader >> monad obsolete... > > I expect that you will get the same range of opinions as you got from = your > search. As far as I know implicit parameters break referential transparency. > http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearI= mpl icitParameters > So I prefer Reader monad. The burden of converting to monadic style = pays > off when you need to use the same code with different values for the > "constants". (E.g. find out for which value of the Planck constant the > universe collapses and for which it oscillates etc. :-) Love the example but could you elaborate a little on how monadic style helps with this? (This is probably a matter of it not being obvious to me what approach you would take to solving the problem.) By the way, can anyone comment on implicit parameters interacting with monadic code? If I were to use implicit parameters and later realize that I need other monadic functionality, e.g. Writer, would I be in a tough spot or would the implicit parameters continue to work "seemlesly" in the monadic code? Thanks, Bjorn Buckwalter ------------------------------ Message: 20 Date: Mon, 18 Aug 2008 12:49:43 -0400 From: "Brandon S. Allbery KF8NH" Subject: Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: Bjorn Buckwalter Cc: Haskell-Cafe Haskell-Cafe Message-ID: <6FE8DA6B-4FFE-470D-A56B-B73125601BC0@ece.cmu.edu> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; = delsp=3Dyes On 2008 Aug 18, at 10:59, Bjorn Buckwalter wrote: > I would like to know if there is any consensus on what is the best way > to make such a data structure accessible in pure functions. Passing it > explicitly would be a mess. It seems that two options are to use > either a Reader monad or implicit parameters. Using a Reader monad is > straight forward enough though it requires writing/converting code > in/to monadic style and adds some clutter to the formulae. It seems > implicit parameters could be cleaner but I've seen them referred to as > everything from evil to "just what you need" and rendering the Reader > monad obsolete... > > What do you people recommend? Last time I ran into this, I needed a Reader for other reasons so just =20 reused it. --=20 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 ------------------------------ Message: 21 Date: Mon, 18 Aug 2008 12:50:40 -0400 From: "Brandon S. Allbery KF8NH" Subject: Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: Henning Thielemann Cc: Bjorn Buckwalter , Haskell-Cafe Haskell-Cafe Message-ID: Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; = delsp=3Dyes On 2008 Aug 18, at 11:16, Henning Thielemann wrote: > know implicit parameters break referential transparency. > http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearI= mpl icitParameters Are you making the same mistake I did? Linear implicit parameters are =20 different from implicit parameters. --=20 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 ------------------------------ Message: 22 Date: Mon, 18 Aug 2008 19:55:45 +0200 (MEST) From: Henning Thielemann Subject: Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: "Brandon S. Allbery KF8NH" Cc: Bjorn Buckwalter , Haskell-Cafe Haskell-Cafe Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed On Mon, 18 Aug 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 18, at 11:16, Henning Thielemann wrote: >> know implicit parameters break referential transparency. >> http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearI= mpl icitParameters > > Are you making the same mistake I did? Linear implicit parameters are = > different from implicit parameters. I haven't look into the details, so I certainly make any possible = mistake. ------------------------------ Message: 23 Date: Mon, 18 Aug 2008 20:02:30 +0200 (MEST) From: Henning Thielemann Subject: Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: Bjorn Buckwalter Cc: Haskell-Cafe Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann > wrote: >> >> On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: >> >>> I would like to know if there is any consensus on what is the best = way >>> to make such a data structure accessible in pure functions. Passing = it >>> explicitly would be a mess. It seems that two options are to use >>> either a Reader monad or implicit parameters. Using a Reader monad = is >>> straight forward enough though it requires writing/converting code >>> in/to monadic style and adds some clutter to the formulae. It seems >>> implicit parameters could be cleaner but I've seen them referred to = as >>> everything from evil to "just what you need" and rendering the = Reader >>> monad obsolete... >> >> I expect that you will get the same range of opinions as you got from your >> search. As far as I know implicit parameters break referential transparency. >> http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearI= mpl icitParameters >> So I prefer Reader monad. The burden of converting to monadic style = pays >> off when you need to use the same code with different values for the >> "constants". (E.g. find out for which value of the Planck constant = the >> universe collapses and for which it oscillates etc. :-) > > Love the example but could you elaborate a little on how monadic style > helps with this? (This is probably a matter of it not being obvious to > me what approach you would take to solving the problem.) Instead of muEarth :: GravitationalParameter a muEarth =3D ??? escapeVelocity :: a escapeVelocity =3D ... muEarth ... you would write data AstroData a =3D AstroData { muEarth :: GravitationalParameter a , leapSeconds :: LeapSecondTable } escapeVelocity :: Reader (AstroData a) a escapeVelocity =3D do mu <- asks muEarth return (... mu ...) Even better you would introduce a newtype for Reader (AstroData a). This = way you can add any monadic functionality later (Writer et.al.). ------------------------------ Message: 24 Date: Mon, 18 Aug 2008 15:37:53 -0400 From: "Bjorn Buckwalter" Subject: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: "Haskell-Cafe Haskell-Cafe" , "Henning Thielemann" Message-ID: <8b2a1a960808181237w559574f4oa52f84fe89f2b5b2@mail.gmail.com> Content-Type: text/plain; charset=3DISO-8859-1 On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann wrote: > > On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: > >> On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann >> wrote: >>> >>> On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: >>> >>>> I would like to know if there is any consensus on what is the best = way >>>> to make such a data structure accessible in pure functions. Passing = it >>>> explicitly would be a mess. It seems that two options are to use >>>> either a Reader monad or implicit parameters. Using a Reader monad = is >>>> straight forward enough though it requires writing/converting code >>>> in/to monadic style and adds some clutter to the formulae. It seems >>>> implicit parameters could be cleaner but I've seen them referred to = as >>>> everything from evil to "just what you need" and rendering the = Reader >>>> monad obsolete... >>> >>> I expect that you will get the same range of opinions as you got = from >>> your >>> search. As far as I know implicit parameters break referential >>> transparency. >>> >>> http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearI= mpl icitParameters >>> So I prefer Reader monad. The burden of converting to monadic style pays >>> off when you need to use the same code with different values for the >>> "constants". (E.g. find out for which value of the Planck constant = the >>> universe collapses and for which it oscillates etc. :-) >> >> Love the example but could you elaborate a little on how monadic = style >> helps with this? (This is probably a matter of it not being obvious = to >> me what approach you would take to solving the problem.) > > Instead of > muEarth :: GravitationalParameter a > muEarth =3D ??? > > escapeVelocity :: a > escapeVelocity =3D ... muEarth ... > > you would write > > data AstroData a =3D AstroData > { muEarth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } > > escapeVelocity :: Reader (AstroData a) a > escapeVelocity =3D > do mu <- asks muEarth > return (... mu ...) > > Even better you would introduce a newtype for Reader (AstroData a). = This way > you can add any monadic functionality later (Writer et.al.). Right, and I'd evaluate it using e.g.: runReader escapeVelocity myAstroData But with implicit params I suppose I'd define (untested) e.g.: escapeVelocity :: (?astro :: AstroData a) =3D> a escapeVelocity =3D ... mu ... where mu =3D muEarth ?astro To evaluate this I'd use: let ?astro =3D myAstroData in escapeVelocity Which is comparable to the Reader version (with the advantage/disadvantage of the body of 'escapeVelocity' not being monadic). In retrospect I think I misunderstood what you were saying in you first email. I thought you were arguing that the monadic style would have an advantage over implicit params in the Planck problem. But you probably only meant to reemphasize the advantage (of either solution) over hard-coding constants... Thanks again, your Reader example is virtually identical to what I started off with so at least I know I'm not completely off target for a monadic implementation. (Sorry about the reposts Henning, I keep forgetting to cc the cafi!) ------------------------------ Message: 25 Date: Mon, 18 Aug 2008 21:47:18 +0200 From: Henning Thielemann Subject: Re: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: Bjorn Buckwalter Cc: Haskell Cafe Message-ID: <48A9D1C6.90902@henning-thielemann.de> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Bjorn Buckwalter schrieb: > On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann >> wrote: >> >> Instead of >> muEarth :: GravitationalParameter a >> muEarth =3D ??? >> >> escapeVelocity :: a >> escapeVelocity =3D ... muEarth ... >> >> you would write >> >> data AstroData a =3D AstroData >> { muEarth :: GravitationalParameter a >> , leapSeconds :: LeapSecondTable >> } >> >> escapeVelocity :: Reader (AstroData a) a >> escapeVelocity =3D >> do mu <- asks muEarth >> return (... mu ...) >> >> Even better you would introduce a newtype for Reader (AstroData a). = This way >> you can add any monadic functionality later (Writer et.al.). >=20 > Right, and I'd evaluate it using e.g.: >=20 > runReader escapeVelocity myAstroData >=20 > But with implicit params I suppose I'd define (untested) e.g.: >=20 > escapeVelocity :: (?astro :: AstroData a) =3D> a > escapeVelocity =3D ... mu ... where mu =3D muEarth ?astro >=20 > To evaluate this I'd use: >=20 > let ?astro =3D myAstroData in escapeVelocity >=20 > Which is comparable to the Reader version (with the > advantage/disadvantage of the body of 'escapeVelocity' not being > monadic). In my opinion the implicit parameters don't make things simpler, only=20 less portable, that's why I prefer the Reader monad. > In retrospect I think I misunderstood what you were saying in you > first email. I thought you were arguing that the monadic style would > have an advantage over implicit params in the Planck problem. But you > probably only meant to reemphasize the advantage (of either solution) > over hard-coding constants... indeed ------------------------------ Message: 26 Date: Mon, 18 Aug 2008 16:08:26 -0400 From: "David Roundy" Subject: Re: [Haskell-cafe] X Haskell Bindings To: "Antoine Latter" Cc: haskell Message-ID: <117f2cc80808181308s220b5660n74fc707e96fb9ff0@mail.gmail.com> Content-Type: text/plain; charset=3DISO-8859-1 On 8/16/08, Antoine Latter wrote: > The following is a summary of my plan so far. I'm interested in > hearing any suggestions or concerns about what a Haskell library for > writing X clients should look like. This is not a release > announcement, and I can't make any promises about when this will be > delivered. > > Code is available in darcs: > -- darcs get http://community.haskell.org/~aslatter/code/xhb > > Some of the advantages XCB claims over xlib are: > + smaller API > + latency hiding when communicating with the X server > + direct access to the X protocol > + improved threading support > + easier to extend > > What I plan for the X Haskell Bindings (XHB) are as follows: It seems to me that you could make this a bit more haskelly... > + All requests to the server are non-blocking (under most = circumstances) > > + Requests which produce a reply from the server return a "token" or "receipt" Why not abstract this token or receipt into a function? i.e. why not change... > > -- | List all of the extensions supported by the server > > listExtensions :: Connection -> IO (Receipt (ListExtensionsReply)) > > > -- | Query a receipt for a response > > getReply :: Receipt a -> IO (Either XError a) to listExtensions :: Connection -> IO (IO ListExtensionsReply) and then you don't need to use a getReply, or a Receipt data type. This should be equally general, if (as I imagine) the only thing you can do with a Receipt is to getReply it. And to me it seems like a friendly way of describing what this function does. > Each X extension defines its own set of errors and events > (potentially). Should all of these be lumped together into one giant > sum-type for errors and one for events? Or maybe just a couple of existential types together with dynamic? (i.e. like xmonad's SomeMessage) David ------------------------------ Message: 27 Date: Mon, 18 Aug 2008 13:20:45 -0700 From: "Evan Laforge" Subject: Re: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: "Henning Thielemann" Cc: Bjorn Buckwalter , Haskell Cafe Message-ID: <2518b95d0808181320h2ff28d80g109ff256553b4ca2@mail.gmail.com> Content-Type: text/plain; charset=3DISO-8859-1 >> Which is comparable to the Reader version (with the >> advantage/disadvantage of the body of 'escapeVelocity' not being >> monadic). > > In my opinion the implicit parameters don't make things simpler, only = less > portable, that's why I prefer the Reader monad. They also seem to be removed from ghc: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html So it would probably be a mistake to write new code using them. As an aside, if that's really the complete patch I'm impressed how few lines were involved. 136 lines out of TcSimplify.lhs and misc tiny changes in other files. ------------------------------ Message: 28 Date: Mon, 18 Aug 2008 16:24:07 -0400 From: "Brandon S. Allbery KF8NH" Subject: Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? To: "Evan Laforge" Cc: Henning Thielemann , Bjorn Buckwalter , Haskell Cafe Message-ID: <4D655E13-F901-4FAB-8C78-CE56F7EF428B@ece.cmu.edu> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; = delsp=3Dyes On 2008 Aug 18, at 16:20, Evan Laforge wrote: >>> Which is comparable to the Reader version (with the >>> advantage/disadvantage of the body of 'escapeVelocity' not being >>> monadic). >> >> In my opinion the implicit parameters don't make things simpler, =20 >> only less >> portable, that's why I prefer the Reader monad. > > They also seem to be removed from ghc: > > http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html Again, that's *linear* implicit parameters (%foo instead of ?foo). --=20 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 ------------------------------ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe End of Haskell-Cafe Digest, Vol 60, Issue 20 ******************************************** From ajb at spamcop.net Mon Aug 18 22:54:50 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Mon Aug 18 22:53:49 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> References: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> Message-ID: <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> G'day all. Quoting Bjorn Buckwalter : > I'd store the constants in a data structure along the lines of: > >> data AstroData a = AstroData >> { mu_Earth :: GravitationalParameter a >> , leapSeconds :: LeapSecondTable >> } > > I would like to know if there is any consensus on what is the best way > to make such a data structure accessible in pure functions. Passing it > explicitly would be a mess. In this situation, there isn't necessarily any shame in using a top-level unsafePerformIO as long as it's well-hidden: module AstroData (AstroData(..), globalAstroData) where data AstroData = AstroData Int -- You really don't want this function inlined. You also -- really don't want this function to be polymorphic. {-# NOINLINE globalAstroData #-} globalAstroData :: AstroData globalAstroData = unsafePerformIO $ do d <- return 42 -- Or whatever return (AstroData d) Cheers, Andrew Bromage From dons at galois.com Mon Aug 18 23:15:27 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 18 23:14:27 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <1219111367.13639.252.camel@localhost> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> Message-ID: <20080819031527.GB1203@scytale.galois.com> duncan.coutts: > On Mon, 2008-08-18 at 18:22 -0700, Don Stewart wrote: > > > Tim wins the prize for the 500th Haskell package in Arch Linux, > > > > http://aur.archlinux.org/packages.php?ID=19205 > > Which, I should like to note, demonstrates why the original Cabal > design[1] was basically right[2] in that it allows this kind of > automated translation into native packages. > > You cannot do that with autoconf. > > The other distros are following a similar course though not yet quite as > successfully as Don has demonstrated for Arch. There are similar > translation tools for Gentoo, Debian and RPM-based distros with varying > levels of sophistication and automation. I think the folks who hack on > these translation tools should get together and share code and > experience so we can all achieve better levels of automation. The > highest levels of automation will also require more centralised QA on > hackage. That's where we should be going. > > Duncan > > [1] http://haskell.org/cabal/proposal/index.html > [2] I'm not at all claiming credit for that design. That was decided > well before I started hacking on Cabal. > Yes, I want to write something about this soon, but essentially, having a pure, declarative specifcation language for build dependencies -- with no runtime initialisation (yes, I'm looking at you, autoconf!) to define how the package is constructed -- enables analysis and translation tools like cabal2arch, which are an order of magnitude more productive. Use build-type: Simple! One person can maintain 500 packages with minimal manual intervention, while our competitors (6 erlang packages, 21 ocaml packages, 494 python packages :) have to waste a lot more manpower keeping things in shape. Cabal is going to benefit Haskell a lot in the long term -- this kind of productivity improvement is game changing. This leads nicely into the question of where we go from here. We have central hosting, a declarative build system of the first order, and native packages that are easy to construct. The next phase is a standard, comprehensive platform of packages, we can rely on, built upon the automation Cabal enables. See the Batteries Included proposal[1] for more info. -- Don [1] http://www.cse.unsw.edu.au/~dons/papers/CPJS08.html From ok at cs.otago.ac.nz Mon Aug 18 23:39:53 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon Aug 18 23:38:59 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> References: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> Message-ID: Just an idiot-level question: so these "constants" are subject to revision, but *how often*? What is the actual cost of recompiling and using them *as* constants, compared with the cost of rereading the stuff every time you run the program and passing it around? -- If stupidity were a crime, who'd 'scape hanging? From ajb at spamcop.net Tue Aug 19 00:27:49 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Aug 19 00:26:50 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: References: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> Message-ID: <20080819002749.x5ugoazcgs8gso8w-nwo@webmail.spamcop.net> G'day all. Quoting "Richard A. O'Keefe" : > Just an idiot-level question: so these "constants" are subject > to revision, but *how often*? Good question. For leap seconds: - The data can change no quicker than once every 6 months. - The shortest time between changes was 6 months, and the longest (so far) was 7 years. - The mean change is once every 18 months. - You get just under 6 months' notice before a change comes into effect. (No more, no less.) For most programs, it's the last point that concerns me the most... > What is the actual cost of > recompiling and using them *as* constants, compared with the > cost of rereading the stuff every time you run the program and > passing it around? ...because the main cost probably isn't recompiling, it's redeployment. I don't know about this program in particular, but release cycles longer than six months are hardly uncommon in our business. Cheers, Andrew Bromage From praki.prakash at gmail.com Tue Aug 19 01:09:57 2008 From: praki.prakash at gmail.com (Praki Prakash) Date: Tue Aug 19 01:14:07 2008 Subject: [Haskell-cafe] Unboxing VT_VARIANT in hscom Message-ID: I am a Haskell newbie trying to do COM automation using Haskell. I am using hscom (Krasimir's implementation of COM automation). I have run into a problem and need some help. I have a Variant returned from a COM method invocation. When I print it, it shows up as below. Variant VT_DISPATCH I need to invoke methods on the wrapped interface. My attempt to unbox it as below runs into 'rigid type' error. someFunc (Variant VT_DISPATCH val) query = do dispId <- getMethodID "MethodName" val The code above generates this error. Couldn't match expected type `IDispatch a' against inferred type `a1' `a1' is a rigid type variable bound by... I am probably missing something pretty basic. Any help on this is greatly appreciated! Thanks From johan.tibell at gmail.com Tue Aug 19 02:49:42 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Aug 19 02:48:41 2008 Subject: [Haskell-cafe] ANN: benchpress 0.2.1 Message-ID: <90889fe70808182349i55ae1067rd42055811df8ffb9@mail.gmail.com> I'm pleased to announce the first public release of benchpress. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/benchpress benchpress is a micro-benchmark library that produces statistics such as min, mean, standard deviation, median, and max execution time. It also computes execution time percentiles. Release bundle: http://hackage.haskell.org/packages/archive/benchpress/0.2.1/benchpress-0.2.1.tar.gz Docs: http://hackage.haskell.org/packages/archive/benchpress/0.2.1/doc/html/Test-BenchPress.html Code: git clone git://github.com/tibbe/benchpress.git An example benchmark: > import qualified Data.ByteString as B > import System.IO > import Test.BenchPress > > inpath, outpath :: String > inpath = "/tmp/infile" > outpath = "/tmp/outfile" > > blockSize :: Int > blockSize = 4 * 1024 > > copyUsingByteString :: Handle -> Handle -> IO () > copyUsingByteString inf outf = go > where > go = do > bs <- B.hGet inf blockSize > let numRead = B.length bs > if numRead > 0 > then B.hPut outf bs >> go > else return () > > main :: IO () > main = bench 100 $ do > inf <- openBinaryFile inpath ReadMode > outf <- openBinaryFile outpath WriteMode > copyUsingByteString inf outf > hClose outf > hClose inf And the output, best viewed using a fixed-width font: $ ./example Times (ms) min mean +/-sd median max 232.774 273.611 53.317 266.648 722.332 Percentiles (ms) 50% 266.644 66% 266.826 75% 269.616 80% 295.040 90% 295.360 95% 305.855 98% 350.742 99% 450.855 100% 722.332 Cheers, Johan From ketil at malde.org Tue Aug 19 02:51:04 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Aug 19 02:49:17 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <1219111367.13639.252.camel@localhost> (Duncan Coutts's message of "Tue\, 19 Aug 2008 03\:02\:47 +0100") References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> Message-ID: <87hc9h33c7.fsf@malde.org> Duncan Coutts writes: > The other distros are following a similar course though not yet quite as > successfully as Don has demonstrated for Arch. There are similar > translation tools for Gentoo, Debian and RPM-based distros What is the current recommended way to build debian packages? I notice there's a step-by-step description at http://www.haskell.org/haskellwiki/Creating_Debian_packages_from_Cabal_package Any reason the manual steps here aren't automated? There's also a different script posted at http://urchin.earth.li/pipermail/debian-haskell/2008-January/000370.html and I distinctly remember other recipes as well, although I can't find them at the moment. For RPM, there seems to be a tool at http://www.serpentine.com/blog/software/cabal-rpm/ Should we (i.e. haskell.org) provide apt- and yummable repositories for (source?) packages for .rpm and .deb? -k -- If I haven't seen further, it is by standing in the footprints of giants From DekuDekuplex at Yahoo.com Tue Aug 19 03:03:43 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Tue Aug 19 03:03:01 2008 Subject: [Haskell-cafe] (fwd) OT: Cartoon Guide to Lob's Theorem Message-ID: While this is somewhat off-topic, I found this interesting reference to a cartoon guide to Lob's Theorem, so I am forwarding it to this mailing list for some enjoyment in mathematical logic: On Mon, 18 Aug 2008 12:31:11 -0400, in gmane.lisp.scheme.plt Psy-Kosh wrote: >This is a bit off topic, but I suspect some here would appreciate this: >http://www.overcomingbias.com/2008/08/lobs-theorem.html > >Remenicent of the graphical lambda game thing. > >Psy-Kosh >_________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-scheme -- Benjamin L. Russell From vigalchin at gmail.com Tue Aug 19 03:11:08 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Aug 19 03:10:07 2008 Subject: [Haskell-cafe] ANN: posix-realtime 0.0.1 (system category) Message-ID: <5ae4f2ba0808190011w518ea844r48e00033e6574ff5@mail.gmail.com> Hello, 1) I have added more to "the posix realtime" support. - I put in parens above because I have currently uploaded outside the Haskell Unix library .. i.e. I am still open to submitting to the Unix library. - I have also put in parens because I have not personally implemented all of the posix realtime support .... others have also implemented Posix realtime support. 2) I am still trying to learn the Haskell FFI .. my bad .. thank you Brandon, Derek, Don(2?), Jason, Bulat, Duncan, Felipe, Bryan, Ketli, Luke, Jonthan, Jeremy, Jules. . .. Sorry for list .. alittle corney .. but nonetheless very grateful! Who did I forget who answered my questions? Is this a pre-order? ;^) 3) There are still issues with RTDataTypes.hsc that I am working with .. in particular Sigevent. 4) This has been a learning exercise for me as I said in terms of the Haskell API and Haskell monad class. Someone one in the 2) list suggested aHaskell Posix AIO (async IO) API implemented in terms of the State monad or Continuation monad ... I didn't ignore this suggestion ... I am still thinking about .. i.e. the AIO "API" is a somewhat moving target. Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080819/530e5f5c/attachment.htm From vigalchin at gmail.com Tue Aug 19 03:22:33 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Aug 19 03:21:32 2008 Subject: [Haskell-cafe] Re: ANN: posix-realtime 0.0.1 (system category) In-Reply-To: <5ae4f2ba0808190011w518ea844r48e00033e6574ff5@mail.gmail.com> References: <5ae4f2ba0808190011w518ea844r48e00033e6574ff5@mail.gmail.com> Message-ID: <5ae4f2ba0808190022n100bb352v27139b4036679d98@mail.gmail.com> oops .. features supported.. 1) asynchronous I/O 2) locked memory 3) mqueue (message queues) 4) realtime scheduling 5) timers and clocks Regards, Vasili On Tue, Aug 19, 2008 at 2:11 AM, Galchin, Vasili wrote: > Hello, > > 1) I have added more to "the posix realtime" support. > > - I put in parens above because I have currently uploaded > outside the Haskell Unix library .. i.e. I am still open to submitting to > the Unix library. > > - I have also put in parens because I have not personally > implemented all of the posix realtime support .... others have also > implemented Posix realtime support. > > 2) I am still trying to learn the Haskell FFI .. my bad .. thank you > Brandon, Derek, Don(2?), Jason, Bulat, Duncan, Felipe, Bryan, Ketli, Luke, > Jonthan, Jeremy, Jules. . .. Sorry for list .. alittle corney .. but > nonetheless very grateful! Who did I forget who answered my questions? Is > this a pre-order? ;^) > > 3) There are still issues with RTDataTypes.hsc that I am working with > .. in particular Sigevent. > > 4) This has been a learning exercise for me as I said in terms of the > Haskell API and Haskell monad class. Someone one in the 2) list suggested > aHaskell Posix AIO (async IO) API implemented in terms of the State monad or > Continuation monad ... I didn't ignore this suggestion ... I am still > thinking about .. i.e. the AIO "API" is a somewhat moving target. > > Kind regards, Vasili > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080819/b8a1a4e0/attachment.htm From v.dijk.bas at gmail.com Tue Aug 19 03:37:07 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue Aug 19 03:36:06 2008 Subject: [Haskell-cafe] ANN: benchpress 0.2.1 In-Reply-To: <90889fe70808182349i55ae1067rd42055811df8ffb9@mail.gmail.com> References: <90889fe70808182349i55ae1067rd42055811df8ffb9@mail.gmail.com> Message-ID: On Tue, Aug 19, 2008 at 8:49 AM, Johan Tibell wrote: > benchpress is a micro-benchmark library that produces statistics such > as min, mean, standard deviation, median, and max execution time. It > also computes execution time percentiles. Nice, I'm certainty going to use this. Thanks! It would be even nicer if you could also measure the elapsed CPU time (using System.CPUTime.getCPUTime). Than the measurement is not influenced by time spent in other processes and IO time. regards, Bas From mle+cl at mega-nerd.com Tue Aug 19 03:38:53 2008 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Tue Aug 19 03:38:36 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> Message-ID: <20080819173853.f901dfb5.mle+cl@mega-nerd.com> Tim Chevalier wrote: > The trouble is that .wav files don't have metadata (ID3 tags) that > specify artist, album and track names. WAV files can't have ID3 tags, but they most definitely can support metadata including all the ones you mention and much more in an LIST/INFO chunk. libsndfile (http://www.mega-nerd.com/libsndfile) supports TITLE, COPYRIGHT, SOFTWARE, ARTIST, COMMENY, DATE, ALBUM and LICENSE fields. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "XML is not a language in the sense of a programming language any more than sketches on a napkin are a language." -- Charles Simonyi From apfelmus at quantentunnel.de Tue Aug 19 04:17:39 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Aug 19 04:16:46 2008 Subject: [Haskell-cafe] Re: Reader monad, implicit parameters, or something else altogether? In-Reply-To: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> References: <8b2a1a960808180759x6781d139h216cadc61e64ca24@mail.gmail.com> Message-ID: Bjorn Buckwalter wrote: > It seems that two options are to use > either a Reader monad or implicit parameters. Using a Reader monad is > straight forward enough though it requires writing/converting code > in/to monadic style and adds some clutter to the formulae. It seems > implicit parameters could be cleaner but I've seen them referred to as > everything from evil to "just what you need" and rendering the Reader > monad obsolete... > > What do you people recommend? I'd go for applicative functors :) instance Applicative ((->) Constants) where pure = const f <*> x = \r -> (f r) (x r) This way, you don't have to use do-syntax and can keep an applicative look-and-feel. mu = \AstroData{mu_Earth} -> mu_Earth example = pure (*) <*> pure 5 <*> mu Lifting arithmetic operations and numbers will get annoying with the time, but that's nothing an instance Num can't solve. (If it can't, just hide (*) and (+) from the prelude and define your own.) Regards, apfelmus From kr.angelov at gmail.com Tue Aug 19 04:49:28 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Tue Aug 19 04:48:25 2008 Subject: [Haskell-cafe] Unboxing VT_VARIANT in hscom In-Reply-To: References: Message-ID: This looks like a GHC bug to me. I am pretty sure that this worked before. Variant is defined like this: data Variant = forall a . Variant (VarType a) a data VarType a where .... VT_DISPATCH :: VarType (IDispatch ()) >From this it clear that val is of type (IDispatch ()) because the VarType has value VT_DISPATCH. A workaround is to add explicit type singnature for val: someFunc (Variant VT_DISPATCH val) query = do dispId <- getMethodID "MethodName" (val :: IDispatch ()) I don't know why this doesn't work without the signature. Regards, Krasimir On Tue, Aug 19, 2008 at 7:09 AM, Praki Prakash wrote: > I am a Haskell newbie trying to do COM automation using Haskell. I am using > hscom (Krasimir's implementation of COM automation). I have run into a problem > and need some help. > > I have a Variant returned from a COM method invocation. When I print it, it > shows up as below. > > Variant VT_DISPATCH > > I need to invoke methods on the wrapped interface. My attempt to unbox it as > below runs into 'rigid type' error. > > someFunc (Variant VT_DISPATCH val) query = do > dispId <- getMethodID "MethodName" val > > The code above generates this error. > > Couldn't match expected type `IDispatch a' > against inferred type `a1' > `a1' is a rigid type variable bound by... > > I am probably missing something pretty basic. Any help on this is greatly > appreciated! > > Thanks > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From johan.tibell at gmail.com Tue Aug 19 04:54:25 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Aug 19 04:53:23 2008 Subject: [Haskell-cafe] ANN: benchpress 0.2.1 In-Reply-To: References: <90889fe70808182349i55ae1067rd42055811df8ffb9@mail.gmail.com> Message-ID: <90889fe70808190154t60d634bam23dcd3afeb09dd1c@mail.gmail.com> On Tue, Aug 19, 2008 at 9:37 AM, Bas van Dijk wrote: > On Tue, Aug 19, 2008 at 8:49 AM, Johan Tibell wrote: >> benchpress is a micro-benchmark library that produces statistics such >> as min, mean, standard deviation, median, and max execution time. It >> also computes execution time percentiles. > > Nice, I'm certainty going to use this. Thanks! > > It would be even nicer if you could also measure the elapsed CPU time > (using System.CPUTime.getCPUTime). Than the measurement is not > influenced by time spent in other processes and IO time. Thanks. I will ponder how to best expose this in the interface. An option would be to return a tuple of Stats records where the first component is the wall clock time and the second is the CPU time. I might have to run the action twice to avoid extra measuring overhead. For example, in startCpu <- getCPUTime startWall <- getCurrentTime action endWall <- getCurrentTime endCpu <- getCPUTime the measured time includes the two calls to getCurrentTime. Running the action twice will double the benchmark running time which might or might not matter. Cheers, Johan From v.dijk.bas at gmail.com Tue Aug 19 08:14:32 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue Aug 19 08:13:30 2008 Subject: [Haskell-cafe] ANN: benchpress 0.2.1 In-Reply-To: <90889fe70808190154t60d634bam23dcd3afeb09dd1c@mail.gmail.com> References: <90889fe70808182349i55ae1067rd42055811df8ffb9@mail.gmail.com> <90889fe70808190154t60d634bam23dcd3afeb09dd1c@mail.gmail.com> Message-ID: On Tue, Aug 19, 2008 at 10:54 AM, Johan Tibell wrote: > I will ponder how to best expose this in the interface. Nice > I might have to run the action twice to avoid extra measuring overhead. I don't think it matters because the extra measuring overhead is constant over the measuring iterations. Bas From johan.tibell at gmail.com Tue Aug 19 08:45:01 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Aug 19 08:43:58 2008 Subject: [Haskell-cafe] ANN: benchpress 0.2.1 In-Reply-To: References: <90889fe70808182349i55ae1067rd42055811df8ffb9@mail.gmail.com> <90889fe70808190154t60d634bam23dcd3afeb09dd1c@mail.gmail.com> Message-ID: <90889fe70808190545i701aa8aendf43a7ec8bdc39be@mail.gmail.com> On Tue, Aug 19, 2008 at 2:14 PM, Bas van Dijk wrote: > On Tue, Aug 19, 2008 at 10:54 AM, Johan Tibell wrote: >> I might have to run the action twice to avoid extra measuring overhead. > > I don't think it matters because the extra measuring overhead is > constant over the measuring iterations. I want the reported times to differ as little as possible from the actual running times. Any constant overhead skews the results upwards. It might matter is the action being benchmark has a very low run time. Maybe I misunderstood what you said. -- Johan From igloo at earth.li Tue Aug 19 09:06:23 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Aug 19 09:05:22 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <87hc9h33c7.fsf@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> Message-ID: <20080819130623.GA16954@matrix.chaos.earth.li> On Tue, Aug 19, 2008 at 08:51:04AM +0200, Ketil Malde wrote: > > What is the current recommended way to build debian packages? I > notice there's a step-by-step description at > > http://www.haskell.org/haskellwiki/Creating_Debian_packages_from_Cabal_package That's the way I recommend. > Any reason the manual steps here aren't automated? There's not much benefit from automating them (although if someone did so, with a nice way to edit the description etc, then it would be handy). The vast majority of the time in creating Debian packages is: Collecting the copyright info to put in debian/copyright. In theory this is just taking the "copyright" field from the cabal file, but it's often not that simple, e.g. the latest (1.4.2) X11 package claims: 1999-2003, Alastair Reid 2003-2007, libraries@haskell.org but when packaging it I found: 1997-2003, Alastair Reid 2006, Frederik Eaton 2007, Spencer Janssen 2003-2007, libraries@haskell.org in the sources, plus the copyright for the configure script. Checking the Cabal package description is suitable, or writing a suitable description. Testing the package. Thanks Ian, who has no idea what "libraries@haskell.org" claiming copyright actually means, if anything From dmhouse at gmail.com Tue Aug 19 09:15:33 2008 From: dmhouse at gmail.com (David House) Date: Tue Aug 19 09:14:31 2008 Subject: [Haskell-cafe] Re: darcs hacking sprint (25-26 October) In-Reply-To: <20080817204627.GB90292@Macintosh.local> References: <20080817203317.GZ90292@Macintosh.local> <20080817204627.GB90292@Macintosh.local> Message-ID: 2008/8/17 Eric Y. Kow : > Correction! We have a tentative offer for space near *Cambridge* > (thanks to Ganesh) and to Ian for picking up on the blunder. Where exactly? -- -David House, dmhouse@gmail.com From garious at gmail.com Tue Aug 19 12:12:00 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Tue Aug 19 12:10:57 2008 Subject: [Haskell-cafe] lines of code metrics Message-ID: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> Does anyone know of a good case study comparing a project written in C versus one written in Haskell? I'm mostly looking for a comparison of lines of code, but any other metric, such as time to market and code quality metrics could also be -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080819/e7dfb3a8/attachment.htm From dagit at codersbase.com Tue Aug 19 12:55:07 2008 From: dagit at codersbase.com (Jason Dagit) Date: Tue Aug 19 12:54:06 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> Message-ID: 2008/8/19 Greg Fitzgerald : > Does anyone know of a good case study comparing a project written in C > versus one written in Haskell? I'm mostly looking for a comparison of lines > of code, but any other metric, such as time to market and code quality > metrics could also be You can easily get some of this data for micro-benchmarks from the shoot out, but it will be laden with caveats and biases: http://shootout.alioth.debian.org/ While I'm sure your question is the right one ("Which technologies improve the development metrics we care about?"), it would seem that the biggest factor for things like time to market and code quality is actually the group of humans involved: http://alistair.cockburn.us/index.php/Characterizing_people_as_non-linear,_first-order_components_in_software_development (these are each very similar and by the same author) http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf http://www.cis.udel.edu/~silber/470STUFF/article.pdf http://www.acm.org/pubs/articles/journals/cacm/1999-42-10/p109-prechelt/p109-prechelt.pdf I found the last one from norvig.com where he has these two essays that go well together: http://norvig.com/java-lisp.html http://norvig.com/21-days.html Good luck! Jason From atomb at galois.com Tue Aug 19 13:01:59 2008 From: atomb at galois.com (Aaron Tomb) Date: Tue Aug 19 13:00:59 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> Message-ID: <80372216-E479-4291-B973-A49F0D7DF121@galois.com> On Aug 19, 2008, at 9:12 AM, Greg Fitzgerald wrote: > Does anyone know of a good case study comparing a project written in > C versus one written in Haskell? I'm mostly looking for a > comparison of lines of code, but any other metric, such as time to > market and code quality metrics could also be There's one I know of that compares Haskell to C++ and a number of other languages: Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity http://www.haskell.org/papers/NSWC/jfp.ps Aaron From dbuchmann at gmx.net Tue Aug 19 13:38:45 2008 From: dbuchmann at gmx.net (Dennis Buchmann) Date: Tue Aug 19 13:37:44 2008 Subject: [Haskell-cafe] Haskell Xcode Plugin Message-ID: <449D8487-0EC8-43D8-9259-E34633E2E6AB@gmx.net> Hello, during my search for an acceptable development environment under Mac OS X I found this Plugin for Xcode: http://hoovy.org/HaskellXcodePlugin/ Unfortunately, I'm not able to get it to run in Xcode v3.0 and the developer seems to be not contactable at the moment. So, has anyone installed this plugin successfully (with problems in the beginning)? With best regards Dennis Buchmann From bulat.ziganshin at gmail.com Tue Aug 19 13:41:57 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Aug 19 13:43:01 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> Message-ID: <1223375016.20080819214157@gmail.com> Hello Greg, Tuesday, August 19, 2008, 8:12:00 PM, you wrote: > Does anyone know of a good case study comparing a project written > in C versus one written in Haskell? ?I'm mostly looking for a > comparison of lines of code, but any other metric, such as time to > market and code quality metrics could also be? once i compared informally LOC for freearc (freearc.org) and 7-zip (7zip.org) - both are archivers with rather close functionality at the time of comparison - freearc was 3 times smaller. i also think that it wsas developed about 3 times faster than rar/7zip archivers, although this comparison is rather rough overall, i see from 10x improvements when we say about multithreading or complex algorithms to Haskell being even worse than C++ when we say about imperative, especially low-level, especially optimized code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Tue Aug 19 14:05:14 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Aug 19 14:04:14 2008 Subject: [Haskell-cafe] Haskell Xcode Plugin In-Reply-To: <449D8487-0EC8-43D8-9259-E34633E2E6AB@gmx.net> References: <449D8487-0EC8-43D8-9259-E34633E2E6AB@gmx.net> Message-ID: <2FFDE354-A7EB-4D8D-A4D4-6E924574A9A6@ece.cmu.edu> On 2008 Aug 19, at 13:38, Dennis Buchmann wrote: > during my search for an acceptable development environment under > Mac OS X I found this Plugin for Xcode: http://hoovy.org/HaskellXcodePlugin/ > > Unfortunately, I'm not able to get it to run in Xcode v3.0 and the > developer seems Last I looked, that plugin worked only with very old versions of XCode. -- 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 jefferson.r.heard at gmail.com Tue Aug 19 16:00:24 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Tue Aug 19 15:59:24 2008 Subject: [Haskell-cafe] ANN: Tutorial on information visualization and visual analytics in Haskell In-Reply-To: <20080810045004.GA5594@scytale.galois.com> References: <4165d3a70808091130j45d48432s22972a03b337c00e@mail.gmail.com> <20080810045004.GA5594@scytale.galois.com> Message-ID: <4165d3a70808191300w34e3230cp6230b4df342b71bb@mail.gmail.com> The tutorial has now been updated to what I think will more or less be the final version. There are now figures where appropriate. The code has been checked, and I'm sure now that the examples work. Now that I'm done, I'll repeat the original announcement, and all can enjoy: This is the tutorial I'll be presenting at DEFUN 2008. I'll be building a site around it until then, complete with compilable code examples, but I thought I would let everyone get a sneak peek at the long version of the tutorial before I'm done with it. The code is as yet untested, and keep in mind, advanced Haskellers, that I'm purposefully simplifying some things to be understood by the beginner to the intermediate Haskeller. Comments and questions are welcome and encouraged. The link is: http://bluheron.europa.renci.org/docs/BeautifulCode.pdf On Sun, Aug 10, 2008 at 12:50 AM, Don Stewart wrote: > jefferson.r.heard: >> This is the tutorial I'll be presenting at DEFUN 2008. I'll be >> building a site around it until then, complete with compilable code >> examples, but I thought I would let everyone get a sneak peek at the >> long version of the tutorial before I'm done with it. The code is as >> yet untested, and keep in mind, advanced Haskellers, that I'm >> purposefully simplifying some things to be understood by the beginner >> to the intermediate Haskeller. Comments and questions are welcome and >> encouraged. Please do ignore typos in the inline code for now, >> though, as I'll be spending this week testing it out and making sure >> everything works. >> >> The link is: >> >> http://bluheron.europa.renci.org/docs/BeautifulCode.pdf > > This is a beautiful piece of work, Jefferson! > > > And maybe a nice time to mention that Jefferson will be presenting, > along with some other leading lights in the community, at DEFUN, our > first developer-oriented workshop at ICFP. > > http://www.deinprogramm.de/defun-2008/ > > So if the ICFP theory-heavy schedule seems a bit dry to you, consider > registering for the DEFUN tutorials, and come away having built some > beautiful code in Haskell. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From catamorphism at gmail.com Tue Aug 19 16:11:21 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue Aug 19 16:10:18 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <20080819173853.f901dfb5.mle+cl@mega-nerd.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819173853.f901dfb5.mle+cl@mega-nerd.com> Message-ID: <4683d9370808191311k25060f5ctd89eb7dc06fcb7d3@mail.gmail.com> On 8/19/08, Erik de Castro Lopo wrote: > Tim Chevalier wrote: > > > The trouble is that .wav files don't have metadata (ID3 tags) that > > specify artist, album and track names. > > > WAV files can't have ID3 tags, but they most definitely can support > metadata including all the ones you mention and much more in an > LIST/INFO chunk. > > libsndfile (http://www.mega-nerd.com/libsndfile) supports TITLE, > COPYRIGHT, SOFTWARE, ARTIST, COMMENY, DATE, ALBUM and LICENSE > fields. > I stand corrected. However, some CD ripping programs don't fill in the metadata when creating WAV files. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Being a nerd, which is to say going too far and caring too much about a subject, is the best way to make friends I know." --Sarah Vowell From jeremy at n-heptane.com Tue Aug 19 17:28:36 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Aug 19 17:22:55 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> Message-ID: <87r68kg0e3.wl%jeremy@n-heptane.com> At Tue, 19 Aug 2008 14:06:23 +0100, Ian Lynagh wrote: > > Any reason the manual steps here aren't automated? > > There's not much benefit from automating them (although if someone did > so, with a nice way to edit the description etc, then it would be > handy). The vast majority of the time in creating Debian packages is: We (at seereason) have a tool, cabal-debian, for automating the process. It has the following features: 1. automatically generates a working debian directory from the .cabal file with no user intervention (most of the time). It copies as much information from the .cabal file to the debian directory as possible. 2. automatically calculates build-depends during initial (or subsequent) debianization 3. checks that .cabal build-depends and debian build-depends are in-sync during dpkg-buildpackage run. 4. automatically calculates install dependencies of binary .debs during dpkg-buildpackage run. (by writing substvar files and using ${haskell:Depends} in debian/control). 5. can be used to create new debian/control and debian/changelog for an already debianized package. (Useful when information copied from the .cabal file changes in the .cabal file). As you state, most generated packages would need additional polish before they could be uploaded to Debian. The Future ---------- cabal-debian seems good enough for general release. I can imagine cabal-debian being used in three ways: 1. a way for users to quickly debianize a cabal library for local use (because going around the debian package system often leads to pain in the long run). 2. a way for debian/ubuntu developers to create a starting point for a real Debian package. 3. a way to standardize on policy issues, by encapsulating them in a tool which "Does It Right". 4. a way to create an unofficial Haskell repository with lots of packages In my opinion, cabal-debian is quite suitable for (1) already. (2) and (3) require agreement from the Haskell Debian community as to what the best practices really are, and patches to make that happen. cabal-debian currently uses: - haskell-devscripts - the cdbs extension for supporting haskell (the one posted on debian-haskell mailing list a while ago) - haskell-utils The basic build is done using the cdbs extension for Haskell (which uses haskell-devscripts). But the version dependencies are updated during the build process using a script from haskell-utils. For (4), it should be pretty easy to use cabal-debian plus this autobuilder: http://src.seereason.com/autobuilder/ to easily create a repository of debian packages that not quite up to debian standards. Whether you would *want* such a thing is obviously an issue for debate: quantity vs quality. But the technology already exists if the desire is there. What's Next? ------------ We are working on getting cabal-debian uploaded to hackage, but we have some patches against haskell-devscripts, and a patch against haskell-utils. The patch against haskell-utils has not been accepted, and may possibly be rejected due to some issue with the way Debian's autobuilders work? It does not make much sense to upload cabal-debian to hackage until the supporting tools are up-to-date. So I guess we need to get our patches accepted upstream. (modifying them if needed). We have also started a tool that is essentially cabal-install + cabal-debian. It has the same purpose as cabal-install, but it debianizes the packages on-the-fly. How You Can Help ---------------- We, (at seereason), make no claims that cabal-debian does anything the right way, the best way, or even a sensible way. Our primary requirements are: 1. that cabal-debian generates sane debianization with minimal pain 2. that the generated debian packages can be built by our autobuilder. This essentially means that you should be able to build them in three steps: i. check out the source ii. install the build-depends listed in debian/control iii. run dpkg-buildpackage I believe this is slight issue with haskell-utils based packages which have a procedure more like: i. check out the source ii. run update-haskell-control iii. install build-dependencies iv. run dpkg-buildpackage If update-haskell-control generated >= build-depends instead of = build-depends, then things would work ok with our autobuilder, but possibly not with Debian's?. Anyway, the point is, we are wide open to suggestions and improvements to cabal-debian. In fact, nothing would make us happier than someone coming along and taking over the whole thing ;) Obtaining --------- cabal-debian can be obtained (via darcs get) here: http://src.seereason.com/cabal-debian/ but you will need other dependencies from here: http://src.seereason.com/ and you will need a patch to haskell-devscripts from here: http://src.seereason.com/quilt/haskell-devscripts-quilt/ and haskell-utils from here: http://src.seereason.com/quilt/haskell-utils-quilt/ Example ------- Here is an example debian directory generated by cabal-debian (which no manual modifications or intervention, AFAIK): http://src.seereason.com/debian/shellac-debian/debian/ You would need the patched haskell-devscripts/haskell-utils and possibly cabal-debian to actually build it though. j. From mle+cl at mega-nerd.com Tue Aug 19 16:24:41 2008 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Tue Aug 19 17:42:39 2008 Subject: [Haskell-cafe] ANN: wavconvert 0.1.1 In-Reply-To: <4683d9370808191311k25060f5ctd89eb7dc06fcb7d3@mail.gmail.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819173853.f901dfb5.mle+cl@mega-nerd.com> <4683d9370808191311k25060f5ctd89eb7dc06fcb7d3@mail.gmail.com> Message-ID: <20080820062441.a8cdbe0b.mle+cl@mega-nerd.com> Tim Chevalier wrote: > I stand corrected. However, some CD ripping programs don't fill in the > metadata when creating WAV files. Its not just some, its the vast majority of them :-). Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "The one thing that reading these five books has hammered home is how much C++ has turned into 3 languages stuck in a bag fighting to get out. Low C++, High C++, and Generic C++." From kr.angelov at gmail.com Wed Aug 20 03:58:50 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Aug 20 03:57:45 2008 Subject: [Haskell-cafe] Unboxing VT_VARIANT in hscom In-Reply-To: References: Message-ID: Aha. I got it. You should compile with -fglasgow-exts option. The extra type signatures doesn't matter. On Wed, Aug 20, 2008 at 8:20 AM, Praki Prakash wrote: > Krasimir - thanks for your reply. I had tried explicit typing but I still > get the same error. I have some code below and the error message. > > import Control.Exception > import Foreign > import Foreign.COM.Client > import Foreign.COM.Automation > import System.IO > > data WmiConnection = > WmiConnection { > execQuery :: String -> IO () > } > > main = withCOM $ do > conn <- wmiconnect "." "root\\cimv2" > execQuery conn "Select * From ..." > print "done" > > wmiconnect :: String -> String -> IO WmiConnection > wmiconnect comp cimroot = > do > clsid <- progid2clsid "WbemScripting.SWbemLocator" > (bracket (createInstance clsid iidIUnknown) release $ \iunkn -> > bracket (queryInterface iidIDispatch iunkn) release $ \idisp -> do > dispId <- getMethodID "ConnectServer" idisp > withBSTR comp $ \pComputer -> > withBSTR cimroot $ \pCimRoot -> do > (res,args) <- invoke dispId InvokeMethod [Variant VT_BSTR > pComputer, > Variant VT_BSTR > pCimRoot > ] idisp > print res > let conn = WmiConnection{ execQuery = queryFunc res } > return conn) > where > queryFunc :: Variant -> String -> IO () > queryFunc (Variant VT_DISPATCH idisp) query = do > dispId <- getMethodID "ExecQuery" idisp > return () > {- > queryFunc (Variant vt idisp) query = > if vt == VT_DISPATCH > then do > dispId <- getMethodID "ExecQuery" idisp > return "" > else > fail "error" > > return () > -} > > C:\>ghc --make test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > > test.hs:35:47: > Couldn't match expected type `IDispatch a' > against inferred type `a1' > `a1' is a rigid type variable bound by > the constructor `Variant' at test.hs:34:22 > In the second argument of `getMethodID', namely `idisp' > In a 'do' expression: dispId <- getMethodID "ExecQuery" idisp > In the expression: > do dispId <- getMethodID "ExecQuery" idisp > return () > > Any further suggestions? > > Thanks, > Praki > > On Tue, Aug 19, 2008 at 1:49 AM, Krasimir Angelov > wrote: >> >> This looks like a GHC bug to me. I am pretty sure that this worked >> before. Variant is defined like this: >> >> data Variant = forall a . Variant (VarType a) a >> >> data VarType a where >> .... >> VT_DISPATCH :: VarType (IDispatch ()) >> >> From this it clear that val is of type (IDispatch ()) because the >> VarType has value VT_DISPATCH. A workaround is to add explicit type >> singnature for val: >> >> someFunc (Variant VT_DISPATCH val) query = do >> dispId <- getMethodID "MethodName" (val :: IDispatch ()) >> >> I don't know why this doesn't work without the signature. >> >> Regards, >> Krasimir >> >> >> On Tue, Aug 19, 2008 at 7:09 AM, Praki Prakash >> wrote: >> > I am a Haskell newbie trying to do COM automation using Haskell. I am >> > using >> > hscom (Krasimir's implementation of COM automation). I have run into a >> > problem >> > and need some help. >> > >> > I have a Variant returned from a COM method invocation. When I print it, >> > it >> > shows up as below. >> > >> > Variant VT_DISPATCH >> > >> > I need to invoke methods on the wrapped interface. My attempt to unbox >> > it as >> > below runs into 'rigid type' error. >> > >> > someFunc (Variant VT_DISPATCH val) query = do >> > dispId <- getMethodID "MethodName" val >> > >> > The code above generates this error. >> > >> > Couldn't match expected type `IDispatch a' >> > against inferred type `a1' >> > `a1' is a rigid type variable bound by... >> > >> > I am probably missing something pretty basic. Any help on this is >> > greatly >> > appreciated! >> > >> > Thanks >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > From lemming at henning-thielemann.de Wed Aug 20 04:04:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Aug 20 04:03:18 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219058405.13639.204.camel@localhost> <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> Message-ID: On Mon, 18 Aug 2008, Jason Dagit wrote: > 2008/8/18 Galchin, Vasili : >> >>> If by "faulting in" you mean downloading and installing missing >>> dependencies, then that's exactly what the cabal-install tool does. >> >> This is exactly by "faulting in" .. an analogy ... >> >> Installing cabal-install seems to be a chicken and egg problem >> if enough packages are not already installed ... if not enough then one >> (me) can die of a thousand paper cuts bootstrapping packages up to where >> cabal-install can be installed. I am running Ubuntu Linux. Cabl-install is >> written in Haskell? If so, is there a pre-compiled Cabal-install that I can >> just install with all dependencies (packages) including. I also want to >> install HaskellDB painlessly ;^) ?? > > In my experience, with recent GHC there are only 3 packages needed to > install cabal-install and it's pretty painless. You need zlib, HTTP > and something else that I can't recall off the top of my head (but it > tells you). I believe it's filepath. Actually, installing all of those packages is not so easy, because for installation of zlib you need zlib headers (zlib-devel package) and Cabal can't tell you! I think, cabal-install should be shipped in binary form, too, because compiling it manually is no fun. However, once cabal-install runs you won't like to miss it anymore. From vigalchin at gmail.com Wed Aug 20 04:09:55 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Aug 20 04:08:51 2008 Subject: [Haskell-cafe] the "process" package ... Message-ID: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> Hello, The "process" package Internal.hs references HsProcessConfig.h but this include file is not in the package "include" directory. Is this C include supposed to be generated? ?? KInd regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080820/50fd8ac6/attachment.htm From vigalchin at gmail.com Wed Aug 20 04:21:51 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Aug 20 04:20:50 2008 Subject: [Haskell-cafe] "build depends:" in a .cabal file In-Reply-To: References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219058405.13639.204.camel@localhost> <5ae4f2ba0808181412p1c1e561fk3eb4bceee2d2d7e8@mail.gmail.com> Message-ID: <5ae4f2ba0808200121o6637b6f5u312f5800af76eec7@mail.gmail.com> thanks Henning. In any case, thanks to pushing I got Cabal installed. Regards, Vasili On Wed, Aug 20, 2008 at 3:04 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Mon, 18 Aug 2008, Jason Dagit wrote: > > 2008/8/18 Galchin, Vasili : >> >>> >>> If by "faulting in" you mean downloading and installing missing >>>> dependencies, then that's exactly what the cabal-install tool does. >>>> >>> >>> This is exactly by "faulting in" .. an analogy ... >>> >>> Installing cabal-install seems to be a chicken and egg problem >>> if enough packages are not already installed ... if not enough then one >>> (me) can die of a thousand paper cuts bootstrapping packages up to where >>> cabal-install can be installed. I am running Ubuntu Linux. Cabl-install >>> is >>> written in Haskell? If so, is there a pre-compiled Cabal-install that I >>> can >>> just install with all dependencies (packages) including. I also want to >>> install HaskellDB painlessly ;^) ?? >>> >> >> In my experience, with recent GHC there are only 3 packages needed to >> install cabal-install and it's pretty painless. You need zlib, HTTP >> and something else that I can't recall off the top of my head (but it >> tells you). >> > > I believe it's filepath. Actually, installing all of those packages is not > so easy, because for installation of zlib you need zlib headers (zlib-devel > package) and Cabal can't tell you! I think, cabal-install should be shipped > in binary form, too, because compiling it manually is no fun. However, once > cabal-install runs you won't like to miss it anymore. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080820/2a154807/attachment.htm From vigalchin at gmail.com Wed Aug 20 04:28:54 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Aug 20 04:27:52 2008 Subject: [Haskell-cafe] a recent Haskell contribution? Message-ID: <5ae4f2ba0808200128x3530f634sd85feda3508fab8d@mail.gmail.com> Hello, Recently someone made a post about a message-passing IPC that they contributed (within one month?). I have been searching the Haskell cafe archive to no avail. Can the contributor (or any one else) tell where the code is and any papers? Thank you, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080820/9fb0f54e/attachment.htm From lemming at henning-thielemann.de Wed Aug 20 04:49:16 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Aug 20 04:48:13 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> References: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> Message-ID: On Mon, 18 Aug 2008, ajb@spamcop.net wrote: > G'day all. > > Quoting Bjorn Buckwalter : > >> I'd store the constants in a data structure along the lines of: >> >>> data AstroData a = AstroData >>> { mu_Earth :: GravitationalParameter a >>> , leapSeconds :: LeapSecondTable >>> } >> >> I would like to know if there is any consensus on what is the best way >> to make such a data structure accessible in pure functions. Passing it >> explicitly would be a mess. > > In this situation, there isn't necessarily any shame in using a > top-level unsafePerformIO as long as it's well-hidden: > > module AstroData (AstroData(..), globalAstroData) where > > data AstroData = AstroData Int But here my argument about playing around with the Planck constant becomes relevant. From jason.dusek at gmail.com Wed Aug 20 05:49:51 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 20 05:48:46 2008 Subject: [Haskell-cafe] FRP question In-Reply-To: <6cb897b30808171638l55e48ceaj4ca17e35cb778a6@mail.gmail.com> References: <6cb897b30808171638l55e48ceaj4ca17e35cb778a6@mail.gmail.com> Message-ID: <42784f260808200249r6db89b85kffba69b5af68ad68@mail.gmail.com> What's the Haskeller friendly paper? -- _jsn From Malcolm.Wallace at cs.york.ac.uk Wed Aug 20 06:13:55 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 20 06:14:53 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> Message-ID: <20080820111355.51c0256f.Malcolm.Wallace@cs.york.ac.uk> "Greg Fitzgerald" wrote: > Does anyone know of a good case study comparing a project written in C > versus one written in Haskell? I'm mostly looking for a comparison of > lines of code, Some of the "Experience Report" category of paper at ICFP 2007 and 2008 might have the kind of thing you are looking for. I know that mine: "Experience Report: Visualizing Data Through Functional Pipelines" David Duke, Rita Borgo, Colin Runciman, Malcolm Wallace ICFP 2008 has a brief comparison of sLoC between Haskell and C++ implementations of similar algorithms. (But you may have to wait until it is published to obtain an electronic copy.) Regards, Malcolm From duncan.coutts at worc.ox.ac.uk Wed Aug 20 07:48:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 20 07:47:47 2008 Subject: [Haskell-cafe] the "process" package ... In-Reply-To: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> References: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> Message-ID: <1219232935.13639.285.camel@localhost> On Wed, 2008-08-20 at 03:09 -0500, Galchin, Vasili wrote: > Hello, > > The "process" package Internal.hs references HsProcessConfig.h > but this include file is not in the package "include" directory. Is > this C include supposed to be generated? ?? Yes. It's generated by the ./configure script, which gets run automatically when you configure the package in the standard way. If you got the code straight from darcs then you need to run autoreconf first to generate the ./configure script. Duncan From r.kelsall at millstream.com Wed Aug 20 08:19:36 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Wed Aug 20 08:18:45 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> Message-ID: <48AC0BD8.8070001@millstream.com> Greg Fitzgerald wrote: > Does anyone know of a good case study comparing a project written in C > versus one written in Haskell? I'm mostly looking for a comparison of > lines of code, but any other metric, such as time to market and code > quality metrics could also be Maybe this one is relevant: "Evaluating High-Level Distributed Language Constructs" by Phil Trinder http://www.macs.hw.ac.uk/~trinder/papers/ICFP2007.pdf which compares GdH, Erlang and C++. Richard. From wnoise at ofb.net Wed Aug 20 08:23:32 2008 From: wnoise at ofb.net (Aaron Denney) Date: Wed Aug 20 08:22:44 2008 Subject: [Haskell-cafe] Re: Cyclic Inclusions References: <20080811210700.GF18593@scytale.galois.com> <20080811205344.oad17jkkz4sgc0cc-nwo@webmail.spamcop.net> <324349FB-938F-47E8-95C1-DC82B021602E@gmail.com> <20080812100106.x4c1fsws4cocwos4-nwo@webmail.spamcop.net> <6149DD4E-E685-418D-AD06-AFB27C2929B0@gmail.com> <20080812230648.2u2tlgd3kcgwo4kc-nwo@webmail.spamcop.net> <554EE2F6-E9F6-4ADB-B8C6-D5342C039651@gmail.com> <20080813071801.sdpi584u80wg4c4o-nwo@webmail.spamcop.net> Message-ID: On 2008-08-13, ajb@spamcop.net wrote: > If you only change the implementation of a module, not its interface, > you don't need to recompile anything that imports it. (At least, this > is true at -O0, which if you care about fast recompilation because > you're deep in development, you're probably doing.) This is only true if the interface can be tracked separately from the implementation. Which, despite the flaws, C's header files can be coaxed into doing. -- Aaron Denney -><- From pedagand at gmail.com Wed Aug 20 11:38:29 2008 From: pedagand at gmail.com (Pierre-Evariste Dagand) Date: Wed Aug 20 11:37:24 2008 Subject: [Haskell-cafe] FRP question In-Reply-To: <42784f260808200249r6db89b85kffba69b5af68ad68@mail.gmail.com> References: <6cb897b30808171638l55e48ceaj4ca17e35cb778a6@mail.gmail.com> <42784f260808200249r6db89b85kffba69b5af68ad68@mail.gmail.com> Message-ID: <6cb897b30808200838p1018bb30j57e31fae3698488f@mail.gmail.com> 2008/8/20, Jason Dusek : > What's the Haskeller friendly paper? This version of the paper was submitted to ICFP this year (and was rejected): http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/icfp_paper.pdf In the technical report, we tried to address ICFP reviewers' comments. Sadly for us haskellers, a reviewer was strongly opposed to the use of Haskell to present a project in OCaml. That's why we decided to only use OCaml in the technical report. The core Arrow implementation and the structure of launchers did not changed a lot. However, we corrected the definition of timers to be simpler and fixed a problem with the random number embedding. Also, the term "multiplexer" in this paper corresponds to "launcher" in the technical report. My adviser did not liked the word "multiplexer". If people here are interested in an Haskell-Opis (HOpis ?), I would gladly put my current Haskell implementation on a public repository and start translating the OCaml code in Haskell. Regards, -- Pierre-Evariste DAGAND http://perso.eleves.bretagne.ens-cachan.fr/~dagand/ From dons at galois.com Wed Aug 20 12:38:08 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 20 12:36:59 2008 Subject: [Haskell-cafe] 500 Haskell packages in Arch Linux Message-ID: <20080820163808.GC6483@scytale.galois.com> Monday was something of a landmark, as the 500th Haskell package was added to the Arch Linux distribution. I've written about the approach we took to fully automating the construction of native packages from Hackage, http://cgi.cse.unsw.edu.au/~dons/blog/2008/08/21#the_500 As well as a survey of 10 cool packages that are a little unknown. And some fun stats. On Hackage we have: * 723 unique packages * Over a million lines of Haskell code * 2600 pages of API documentation And in Arch, there are: 6 Erlang packages 21 OCaml packages 28 Lisp packages 101 Ruby packages 495 Python packages and now, 504 Haskell packages :) -- Don From derek.a.elkins at gmail.com Wed Aug 20 12:43:07 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Aug 20 12:42:47 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <48AC243E.2070200@imn.htwk-leipzig.de> References: <48AC243E.2070200@imn.htwk-leipzig.de> Message-ID: <1219250587.13277.123.camel@derek-laptop> On Wed, 2008-08-20 at 16:03 +0200, Johannes Waldmann wrote: > Hello. > > I plan to give a course in compiler construction, > using Haskell as the implementation language > (not as source or target language). > > Something along these lines: > 1. combinator parsers (Parsec), > 2. simple interpreter (arithmetical expressions) > 3. add algebraic data types, functions > 4. type checker > 5. code generator. > Ideally, 2..5 would be using the very same tree traversal code > and just change the monad for evaluation. > > Any comments appreciated. Have you given such a course? Taken? [I've replied to Haskell-Cafe which is a better list for this discussion.] 2 & 3 are going to have different trees so using the same tree traversal code would require some finesse, though the code for 2 should only need extension not change. One thing you may want to look at is attribute grammars which can be cast into a monadic framework and gives a natural example of using the backward state monad and allows you to connect to other formalisms used for compiler construction. Another possibility is abstract interpretation. Both code generation and type checking can be viewed as examples of abstract interpretation (as well as, of course, actual interpretation.) Also many analyses fit into the model of abstract interpretation. I'd also recommend transforming the initial AST to some intermediate form before doing 2-5. Not only is this a virtually universal practice, but it will the later stages, particularly the interpreter and the code generator easier to write and, in the code generator's case, able to produce better output. Ultimately, trying to have the same code produce all of these is going to lead to some compromises. You are either going to have to forsake some quality in the output, or you are going to have unnatural or, at least, non-trivial implementations of some the functions. The recommendation to for the use of a intermediate language mitigates this somewhat. From mad.one at gmail.com Wed Aug 20 12:59:37 2008 From: mad.one at gmail.com (Austin Seipp) Date: Wed Aug 20 12:58:38 2008 Subject: [Haskell-cafe] a recent Haskell contribution? In-Reply-To: <5ae4f2ba0808200128x3530f634sd85feda3508fab8d@mail.gmail.com> References: <5ae4f2ba0808200128x3530f634sd85feda3508fab8d@mail.gmail.com> Message-ID: <1219251509-sup-6074@existential.local> Hi, Perhaps you are talking about Communicating Haskell Processes (CHP)? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/chp Austin From chris at eidhof.nl Wed Aug 20 13:58:34 2008 From: chris at eidhof.nl (Chris Eidhof) Date: Wed Aug 20 13:57:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <1219250587.13277.123.camel@derek-laptop> References: <48AC243E.2070200@imn.htwk-leipzig.de> <1219250587.13277.123.camel@derek-laptop> Message-ID: <3D7CFDF0-94DA-4B70-A1A3-2712365D02E0@eidhof.nl> >> I plan to give a course in compiler construction, >> using Haskell as the implementation language >> (not as source or target language). >> >> Something along these lines: >> 1. combinator parsers (Parsec), >> 2. simple interpreter (arithmetical expressions) >> 3. add algebraic data types, functions >> 4. type checker >> 5. code generator. >> Ideally, 2..5 would be using the very same tree traversal code >> and just change the monad for evaluation. >> >> Any comments appreciated. Have you given such a course? Taken? At Utrecht University, they teach excellent courses on exactly this subject, using Haskell. The course webpage [1] is probably a useful resource for you, as it shows exactly what we were thought (I participated in the course last year). We made heavy use of Utrecht's Attribute Grammar Compiler [2], which is a pre-processor for Haskell that allows you to very easily build programs using an attribute grammar. This proved to be a really nice way to do the tree transformations. I very much liked the idea of attribute grammars, but I personally don't like pre-processors very much. Also, we targeted Simple Stack Machine as a platform. This is an assembly-like language that has a graphical interpreter, so you can actually see your code, do single-stepping, see your stack, etc. It proved to be quite useful. As a student, I it added a lot of educational value, but a real language would also be cool (e.g. Harpy [4]). HTH, -chris [1]: http://www.cs.uu.nl/docs/vakken/ipt/ [2]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uuagc [3]: http://people.cs.uu.nl/atze/SSM/index.html [4]: http://uebb.cs.tu-berlin.de/harpy/ From cppljevans at suddenlink.net Wed Aug 20 13:55:32 2008 From: cppljevans at suddenlink.net (Larry Evans) Date: Wed Aug 20 13:59:03 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <1219250587.13277.123.camel@derek-laptop> References: <48AC243E.2070200@imn.htwk-leipzig.de> <1219250587.13277.123.camel@derek-laptop> Message-ID: On 08/20/08 11:43, Derek Elkins wrote: > On Wed, 2008-08-20 at 16:03 +0200, Johannes Waldmann wrote: >> Hello. >> >> I plan to give a course in compiler construction, >> using Haskell as the implementation language >> (not as source or target language). >> >> Something along these lines: >> 1. combinator parsers (Parsec), >> 2. simple interpreter (arithmetical expressions) >> 3. add algebraic data types, functions >> 4. type checker >> 5. code generator. >> Ideally, 2..5 would be using the very same tree traversal code >> and just change the monad for evaluation. >> >> Any comments appreciated. Have you given such a course? Taken? > > [I've replied to Haskell-Cafe which is a better list for this > discussion.] > > 2 & 3 are going to have different trees so using the same tree traversal > code would require some finesse, though the code for 2 should only need > extension not change. > > One thing you may want to look at is attribute grammars which can be > cast into a monadic framework and gives a natural example of using the > backward state monad and allows you to connect to other formalisms used > for compiler construction. Could you give some examples or links or references? > > Another possibility is abstract interpretation. Both code generation > and type checking can be viewed as examples of abstract interpretation > (as well as, of course, actual interpretation.) Also many analyses fit > into the model of abstract interpretation. Links or references? [snip] I'd also would like to see First and Follow sets: http://www.jambe.co.nz/UNI/FirstAndFollowSets.html calculated in haskell. I'd think it would be natural since, AFAICT, the calculation of the First sets is a homomorphism on the algebra of grammar expressions. IOW FIRST( x <|> y ) = set_union(FIRST(x),FIRST(y)) and I *think* maybe a similar definition can be made for the sequencing operator. Since I've seen haskell associated with algebras and expecially monads, I guess haskell would be especially adept at this. WARNING: I've not written a line of haskell code. -regards Larry From dons at galois.com Wed Aug 20 14:16:52 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 20 14:15:51 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <3D7CFDF0-94DA-4B70-A1A3-2712365D02E0@eidhof.nl> References: <48AC243E.2070200@imn.htwk-leipzig.de> <1219250587.13277.123.camel@derek-laptop> <3D7CFDF0-94DA-4B70-A1A3-2712365D02E0@eidhof.nl> Message-ID: <20080820181652.GF6770@scytale.galois.com> chris: > >>I plan to give a course in compiler construction, > >>using Haskell as the implementation language > >>(not as source or target language). > >> > >>Something along these lines: > >>1. combinator parsers (Parsec), > >>2. simple interpreter (arithmetical expressions) > >>3. add algebraic data types, functions > >>4. type checker > >>5. code generator. > >>Ideally, 2..5 would be using the very same tree traversal code > >>and just change the monad for evaluation. > >> > >>Any comments appreciated. Have you given such a course? Taken? > > At Utrecht University, they teach excellent courses on exactly this > subject, using Haskell. The course webpage [1] is probably a useful > resource for you, as it shows exactly what we were thought (I > participated in the course last year). We made heavy use of Utrecht's > Attribute Grammar Compiler [2], which is a pre-processor for Haskell > that allows you to very easily build programs using an attribute > grammar. This proved to be a really nice way to do the tree > transformations. I very much liked the idea of attribute grammars, but > I personally don't like pre-processors very much. > > Also, we targeted Simple Stack Machine as a platform. This is an > assembly-like language that has a graphical interpreter, so you can > actually see your code, do single-stepping, see your stack, etc. It > proved to be quite useful. As a student, I it added a lot of > educational value, but a real language would also be cool (e.g. Harpy > [4]). And Language.C http://hackage.haskell.org/cgi-bin/hackage-scripts/package/language-c From byorgey at seas.upenn.edu Wed Aug 20 14:18:08 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Aug 20 14:17:03 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 82 - August 20, 2008 Message-ID: <20080820181808.GA8235@minus.seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20080820 Issue 82 - August 20, 2008 --------------------------------------------------------------------------- Welcome to issue 82 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements Lava2000 on Hackage. Emil Axelsson [2]announced that [3]Lava2000 has been uploaded to Hackage. Lava is a structural hardware description library embedded in Haskell. This version of Lava focuses on verification, and connects to a number of different verification engines (although only Smv and Satzoo are maintained in this version). QuickCheck and HPC Tutorial. Andy Gill [4]announced a half day tutorial on QuickCheck and HPC to be held at [5]DEFUN, taught by Andy Gill and Koen Claessen. The latest version of QuickCheck will also be released in conjunction with the tutorial. Compiler Construction course using Haskell?. Johannes Waldmann [6]announced that he plans to give a course in compiler construction, using Haskell as the implementation language. Any comments are appreciated, especially from anyone who has given or taken such a course. witness 0.1, open-witness 0.1. Ashley Yakeley [7]announced the release of these new packages and the draft paper on which they are based. posix-realtime 0.0.1. Vasili Galchin [8]announced the release of the posix-realtime package. benchpress 0.2.1. Johan Tibell [9]announced the first public release of [10]benchpress, a micro-benchmark library that produces statistics such as min, mean, standard deviation, median, and max execution time. wavconvert 0.1.1. Tim Chevalier [11]announced the release of [12]wavconvert, a tool which takes a directory tree as an argument, and converts any .wav files in it to .ogg (using an external OGG encoder) while filling in the ID3 tags based on the directory names. darcs hacking sprint (25-26 October). Eric Y. Kow [13]announced a darcs hacking sprint, to be held on the 25-26 of October, in Cambridge and Portland (and over IRC). The perfect opportunity to get involved, if you are interested in doing some hacking on darcs. Let Eric know if you are interested. X Haskell Bindings. Antoine Latter [14]announced that he is slowly [15]porting XCB (the X C Bindings) to Haskell, and would like input from any interested parties. logfloat. wren ng thornton [16]announced the release of the logfloat package for manipulating log-domain floating numbers. The main reason for casting numbers into the log-domain is to prevent underflow when multiplying many small probabilities as is done in Hidden Markov Models and other statistical models often used for natural language processing. The log-domain also helps prevent overflow when multiplying many large numbers. Roguestar 0.2.2. Christopher Lane Hinson [17]announced the release of version 0.2.2 of Roguestar. Google Summer of Code Progress updates from participants in the 2008 [18]Google Summer of Code. Hoogle 4. Neil Mitchell (ndm) is working on [19]Hoogle 4. [20]This week, he worked on getting out the last kinks to make [21]Hoogle 4 usable as a replacement for [22]Hoogle 3. Although this is the last official week of the GSoC, he plans to continue working on it when he has time. DPH physics engine. Roman Cheplyaka (Feuerbach) is working on a [23]physics engine using [24]Data Parallel Haskell. GHC plugins. Max Bolingbroke is working on dynamically loaded plugins for GHC. Cabal dependency framework. Andrea Vezzosi (Saizan) is working on a [25]make-like dependency analysis framework for Cabal. Language.C. Benedikt Huber (visq) is [26]working on Language.C, a standalone parser/pretty printer library for C99. Generic tries. Jamie Brandon is working on a library for efficient maps using generalized tries. GHC API. Thomas Schilling (nominolo) is working on [27]improvements to the GHC API. Jobs Platform Architect at Peerium, Inc.. Don Stewart [28]forwarded a job opportunity for a Haskell programmer at [29]Peerium, Inc. Peerium is building a new software platform for direct, real-time communication and collaboration within graphically rich environments, and is looking for a platform architect proficient in Haskell to work with the founders to design and implement components of the runtime and supporting libraries for our software platform. Resumes should be forwarded to hr [30]peerium.com. Blog noise [31]Haskell news from the [32]blogosphere. * Don Stewart: [33]The 500 Packages: Haskell, Distros, and Maintainership. * Neil Mitchell: [34]Hoogle New Features. Neil has finished his Google Summer of Code work on the [35]new version of Hoogle, but still intends to continue working on it when he gets the chance. A number of new features have been added. * Well-Typed.Com: [36]Solving the diamond dependency problem. Duncan explains how the newest version of Cabal (mostly) solves the DDDP (dreaded diamond dependency problem). * Real-World Haskell: [37]Two new chapters, preorder links, and a page count estimate. Two new beta chapters are up! * Dan Piponi (sigfpe): [38]Untangling with Continued Fractions: Part 1. Dan continues his fascinating series on rational tangles, showing how to describe a tangle using do-notation. * Christopher Lane Hinson: [39]ANN: Roguestar 0.2.2. * Luis Araujo: [40]Himerge (and Haskell) out to the street!. * Neil Mitchell: [41]GSoC Hoogle: Week 12. * Twan van Laarhoven: [42]A generic merge function. * Luke Palmer: [43]Slicing open the belly of the IO monad in an alternate universe. Luke explores methods of safely performing some I/O without the IO monad in the context of FRP. * Ketil Malde: [44]The wee beginnings of a biohaskell tutorial? -- and some thoughts on programming productivity. * Douglas M. Auclair (geophf): [45]Using Difference Lists. * Real-World Haskell: [46]Mid-August status update. Quotes of the Week * SimonM: People don't seem to believe me when I say this. In retrospect we shouldn't have called it forkOS, we should have called it forkReallyExpensiveOnlyNecessaryForCallingOpenGL_IO. * quicksilver: unsafeInterleaveIO gives you a way to cheat if you're happy to descend into a mire of programs with no semantics. * dmhouse: Eurgh, metastereo quotes. * quicksilver: [on @yhjulwwiefzojcbxybbruweejw] it's the noise a haskell developer makes if you kick him in the de bruijn index. About the Haskell Weekly News New editions are posted to [47]the Haskell mailing list as well as to [48]the Haskell Sequence and [49]Planet Haskell. [50]RSS is also available, and headlines appear on [51]haskell.org. To help create new editions of this newsletter, please see the information on [52]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [53]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.general/16381 3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/chalmers-lava2000 4. http://article.gmane.org/gmane.comp.lang.haskell.general/16380 5. http://www.deinprogramm.de/defun-2008/ 6. http://article.gmane.org/gmane.comp.lang.haskell.general/16379 7. http://article.gmane.org/gmane.comp.lang.haskell.general/16376 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43295 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43292 10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/benchpress 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43282 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43240 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43230 15. http://community.haskell.org/~aslatter/code/xhb 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43211 17. http://blog.downstairspeople.org/2008/08/16/ann-roguestar-022/ 18. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 19. http://code.haskell.org/hoogle/ 20. http://neilmitchell.blogspot.com/2008/08/gsoc-hoogle-week-12.html 21. http://haskell.org/hoogle/beta 22. http://haskell.org/hoogle 23. http://haskell.org/haskellwiki/Hpysics 24. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell 25. http://code.haskell.org/~Saizan/cabal 26. http://www.sivity.net/projects/language.c/wiki/ 27. http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus 28. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43175 29. http://www.peerium.com/ 30. file://localhost/home/brent/haskell/hwn/at] 31. http://planet.haskell.org/ 32. http://haskell.org/haskellwiki/Blog_articles 33. http://cgi.cse.unsw.edu.au/~dons/blog/2008/08/21#the_500 34. http://neilmitchell.blogspot.com/2008/08/hoogle-new-features.html 35. http://haskell.org/hoogle/ 36. http://blog.well-typed.com/2008/08/solving-the-diamond-dependency-problem/ 37. http://www.realworldhaskell.org/blog/2008/08/18/two-new-chapters-preorder-links-and-a-page-count-estimate/ 38. http://sigfpe.blogspot.com/2008/08/untangling-with-continued-fractions_16.html 39. http://blog.downstairspeople.org/2008/08/16/ann-roguestar-022/ 40. http://araujoluis.blogspot.com/2008/08/himerge-and-haskell-out-to-street.html 41. http://neilmitchell.blogspot.com/2008/08/gsoc-hoogle-week-12.html 42. http://twan.home.fmf.nl/blog/haskell/generic-merge.details 43. http://luqui.org/blog/archives/2008/08/14/slicing-open-the-belly-of-the-io-monad-in-an-alternate-universe/ 44. http://blog.malde.org/index.php/2008/08/14/the-wee-beginnings-of-a-biohaskell-tutorial-and-some-thoughts-on-programming-productivity/ 45. http://logicaltypes.blogspot.com/2008/08/using-difference-lists.html 46. http://www.realworldhaskell.org/blog/2008/08/13/mid-august-status-update/ 47. http://www.haskell.org/mailman/listinfo/haskell 48. http://sequence.complete.org/ 49. http://planet.haskell.org/ 50. http://sequence.complete.org/node/feed 51. http://haskell.org/ 52. http://haskell.org/haskellwiki/HWN 53. http://code.haskell.org/~byorgey/code/hwn/ From kr.angelov at gmail.com Wed Aug 20 14:22:33 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Aug 20 14:21:27 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <48AC243E.2070200@imn.htwk-leipzig.de> References: <48AC243E.2070200@imn.htwk-leipzig.de> Message-ID: Hi Johannes, There is a similar course in Chalmers. The home page is here: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/progs/current/ There students were required to implement full parser, partial typechecker and partial interpreter for C++ in either C++, Java or Haskell. We used BNFC for the parser: http://www.cs.chalmers.se/Cs/Research/Language-technology/BNFC/ which was easier for most students I think. In any way I would recomend Happy+Alex or BNFC instead of Parsec but this is only my personal preference. Best Regards, Krasimir 2008/8/20 Johannes Waldmann : > Hello. > > I plan to give a course in compiler construction, > using Haskell as the implementation language > (not as source or target language). > > Something along these lines: > 1. combinator parsers (Parsec), > 2. simple interpreter (arithmetical expressions) > 3. add algebraic data types, functions > 4. type checker > 5. code generator. > Ideally, 2..5 would be using the very same tree traversal code > and just change the monad for evaluation. > > Any comments appreciated. Have you given such a course? Taken? > > If I really decide to do it, > then slides (in German) will be made available. > > Best regards, J.W. > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > From dons at galois.com Wed Aug 20 14:26:34 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 20 14:25:25 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: References: <48AC243E.2070200@imn.htwk-leipzig.de> Message-ID: <20080820182634.GG6770@scytale.galois.com> Similar course at UNSW, http://www.cse.unsw.edu.au/~cs3161/ type checker, type inference and interpreter + proofs. kr.angelov: > Hi Johannes, > > There is a similar course in Chalmers. The home page is here: > > http://www.cs.chalmers.se/Cs/Grundutb/Kurser/progs/current/ > > There students were required to implement full parser, partial > typechecker and partial interpreter for C++ in either C++, Java or > Haskell. We used BNFC for the parser: > > http://www.cs.chalmers.se/Cs/Research/Language-technology/BNFC/ > > which was easier for most students I think. In any way I would > recomend Happy+Alex or BNFC instead of Parsec but this is only my > personal preference. > > Best Regards, > Krasimir > > > > 2008/8/20 Johannes Waldmann : > > Hello. > > > > I plan to give a course in compiler construction, > > using Haskell as the implementation language > > (not as source or target language). > > > > Something along these lines: > > 1. combinator parsers (Parsec), > > 2. simple interpreter (arithmetical expressions) > > 3. add algebraic data types, functions > > 4. type checker > > 5. code generator. > > Ideally, 2..5 would be using the very same tree traversal code > > and just change the monad for evaluation. > > > > Any comments appreciated. Have you given such a course? Taken? > > > > If I really decide to do it, > > then slides (in German) will be made available. > > > > Best regards, J.W. > > > > > > _______________________________________________ > > Haskell mailing list > > Haskell@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From nicolas.frisby at gmail.com Wed Aug 20 14:53:07 2008 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Wed Aug 20 14:52:01 2008 Subject: [Haskell-cafe] cabal build command and package versions Message-ID: <5ce89fb50808201153kcdcf062i8a226afb9916d059@mail.gmail.com> I have a question about cabal's behavior for the build command. When using the build command on a cabalized project, any version changes for installed packages go unnoticed - the necessary modules in the project are not re-compiled. If however, you run the configure command (though the .cabal file for the project has not changed) and then the build command, the appropriate modules (and only the appropriate modules) are re-compiled. Not knowing that the configure command is necessary to detect changes in package that the current project depends on and proceeding only with the build command has led to BusErrors and GHC incurring the impossible in my exploration. Is there a reason that the build command does not check the packages for version changes? It seems fair to expect package-sensitivity of the process that determines if modules need to be re-compiled. This process, I think, is part of the build command and not the configure command. Here's an example scenario: - Imagine package Q depends on package P. - We "runhaskell Setup.hs clean/configure/build/install" them both, from scratch, at version 0. - Then we change package P (by, say, introducing new fields to a constructor that Q cases over), bump its version to 1, and "runhaskell Setup.hs clean/configure/build/install" on it. - If we now "runhaskell build" on package Q, nothing is re-compiled, though a package dependency has changed. "runhaskell Setup.hs build" does not notice this. - However, if we "runhaskell configure/build" on package Q, then the (necessary) modules are re-compiled. Thanks for your time. From ben.franksen at online.de Wed Aug 20 14:53:56 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Aug 20 14:53:07 2008 Subject: [Haskell-cafe] Re: missingH 0.18.6 - problems with cabal configure References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219055806.8816.29.camel@bernH> Message-ID: Andrew U. Frank wrote: > when i run cabal i get an error message: > :~/haskellSources/packages/MissingH-0.18.6$ runhaskell Setup configure > > Setup.hs:19:35: > Couldn't match expected type `(Either > GenericPackageDescription > PackageDescription, > HookedBuildInfo)' > against inferred type `PackageDescription' > In the first argument of `(confHook defaultUserHooks)', namely > `mydescrip' > In the expression: > let > mydescrip = case os of > "mingw32" -> ... > _ -> ... > in (confHook defaultUserHooks) mydescrip flags > In the definition of `customConfHook': > customConfHook descrip flags > = let mydescrip = ... > in (confHook defaultUserHooks) mydescrip > flags > > > what is wrong? i use ghc 6.8.2 and cabal 1.2.3.0 Looks like you'll have to upgrade Cabal (the library). Which version exactly you need I don't know but I'd try the latest and if that fails from there on work backwards. HTH -- b32n From waldmann at imn.htwk-leipzig.de Wed Aug 20 15:47:08 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Aug 20 15:46:34 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <20080820182634.GG6770@scytale.galois.com> References: <48AC243E.2070200@imn.htwk-leipzig.de> <20080820182634.GG6770@scytale.galois.com> Message-ID: <48AC74BC.3070606@imn.htwk-leipzig.de> Thanks for all the pointers. This is very useful. On parsers: yes, LL/LR theory and table-based parsers have been developed for a reason and it's no easy decision to throw them out. Still, even Parsec kind of computes the FIRST sets? And - I positively hate preprocessors. I really want my domain specific languages embedded because I want to use Haskell's types, functions, modules etc. for the domain specific objects (parsers, AST walkers, etc.) Best regards, J.W. From waldmann at imn.htwk-leipzig.de Wed Aug 20 15:55:36 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Aug 20 15:54:30 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <019c01c902fb$2e3e4710$2c408351@cr3lt> References: <48AC243E.2070200@imn.htwk-leipzig.de> <019c01c902fb$2e3e4710$2c408351@cr3lt> Message-ID: <48AC76B8.2080009@imn.htwk-leipzig.de> > This has me worried slightly: do you intend to showcase > monads, or do you intend to teach compiler construction? The subject is Compiler Construction ... Doing tree traversals via monads would, in OO-Speak, just correspond to using some Visitor pattern for the AST. The students know about these patterns. J.W. From flippa at flippac.org Wed Aug 20 15:55:56 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Aug 20 15:55:02 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <48AC74BC.3070606@imn.htwk-leipzig.de> References: <48AC243E.2070200@imn.htwk-leipzig.de> <20080820182634.GG6770@scytale.galois.com> <48AC74BC.3070606@imn.htwk-leipzig.de> Message-ID: On Wed, 20 Aug 2008, Johannes Waldmann wrote: > On parsers: yes, LL/LR theory and table-based parsers have been > developed for a reason and it's no easy decision to throw them out. > Still, even Parsec kind of computes the FIRST sets? > No, it doesn't. That's not actually possible for monadic parsers as they support context-sensitive languages and have no means of telling them from context-free ones. -- flippa@flippac.org "I think you mean Philippa. I believe Phillipa is the one from an alternate universe, who has a beard and programs in BASIC, using only gotos for control flow." -- Anton van Straaten on Lambda the Ultimate From waldmann at imn.htwk-leipzig.de Wed Aug 20 16:07:56 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Aug 20 16:06:50 2008 Subject: [Haskell-cafe] Re: [Haskell] Compiler Construction course using Haskell? In-Reply-To: <7AD7B094-FA32-4CCB-ABE1-A7DD223DBC13@eecs.oregonstate.edu> References: <48AC243E.2070200@imn.htwk-leipzig.de> <7AD7B094-FA32-4CCB-ABE1-A7DD223DBC13@eecs.oregonstate.edu> Message-ID: <48AC799C.9010301@imn.htwk-leipzig.de> Martin Erwig wrote (on a similar course he taught): > * Many students did not know Haskell before, so I had to teach some > Haskell and was forced to avoid some more advanced features, such as > type classes and monads. Yeah, in my case I know they don't know Haskell... Still, I trust them to pick it up quickly, and understand type classes (by analogy to interfaces in Java) and - they have to learn monads. These are master students, they should be open to a challenge ... NB: The course is declared "optional". As a prerequisite, there is a (mandatory) course in Principles of Programming Languages. J.W. From qdunkan at gmail.com Wed Aug 20 16:15:55 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Aug 20 16:14:50 2008 Subject: [Haskell-cafe] unknown flags scramble Message-ID: <2518b95d0808201315l7f09db1dg36e64fa0f4a71d73@mail.gmail.com> I've been getting a mysterious error for a while now. It's come and gone, but seems to be showing up slightly more consistently now. Before I was on ghc 6.8.2 and now I'm on ghc 6.8.3, OS X 10.4 and now 10.5, i386 arch. The problem is that randomly while compiling I get an error like this: unknown flags in {-# OPTIONS #-} pragma: -XDeriveDataTypeabl References: <6cb897b30808171638l55e48ceaj4ca17e35cb778a6@mail.gmail.com> <42784f260808200249r6db89b85kffba69b5af68ad68@mail.gmail.com> <6cb897b30808200838p1018bb30j57e31fae3698488f@mail.gmail.com> Message-ID: <20080820203227.GH6770@scytale.galois.com> pedagand: > 2008/8/20, Jason Dusek : > > What's the Haskeller friendly paper? > > This version of the paper was submitted to ICFP this year (and was rejected): > > http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/icfp_paper.pdf > > In the technical report, we tried to address ICFP reviewers' comments. > Sadly for us haskellers, a reviewer was strongly opposed to the use of > Haskell to present a project in OCaml. That's why we decided to only > use OCaml in the technical report. That's so cool. :) Were you using Haskell as the pseudocode? -- Don From pedagand at gmail.com Wed Aug 20 16:50:48 2008 From: pedagand at gmail.com (Pierre-Evariste Dagand) Date: Wed Aug 20 16:49:43 2008 Subject: [Haskell-cafe] FRP question In-Reply-To: <20080820203227.GH6770@scytale.galois.com> References: <6cb897b30808171638l55e48ceaj4ca17e35cb778a6@mail.gmail.com> <42784f260808200249r6db89b85kffba69b5af68ad68@mail.gmail.com> <6cb897b30808200838p1018bb30j57e31fae3698488f@mail.gmail.com> <20080820203227.GH6770@scytale.galois.com> Message-ID: <6cb897b30808201350o1c70375fweec6a0d9b41d5236@mail.gmail.com> > Were you using Haskell as the pseudocode? Actually, in the ICFP paper mentionned above, we describe the most important parts of our Arrow implementation and then wrote a complete tutorial on 2.5 pages. So, that was not pseudocode but real, executable code. However, we did not use the Arrow syntax, to simplify the translation in other languages. Using Haskell was motivated (on a suggestion of Conal Elliott) to prove the purity of our solution and that our constructs actually instanciate Arrow and its friends. Btw, for those of you interested in the Arrow instance, including Mealy, Conal Elliott blog [http://conal.net/blog/] is a must-read. -- Pierre-Evariste DAGAND http://perso.eleves.bretagne.ens-cachan.fr/~dagand/ From garious at gmail.com Wed Aug 20 17:32:40 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Aug 20 17:31:34 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <80372216-E479-4291-B973-A49F0D7DF121@galois.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> <80372216-E479-4291-B973-A49F0D7DF121@galois.com> Message-ID: <1f3dc80d0808201432s5d26e1dbv4f2c25407ffdc3c@mail.gmail.com> On Aug 19, 2008, at 9:12 AM, Greg Fitzgerald wrote: > > Does anyone know of a good case study comparing a project written in C >> versus one written in Haskell? I'm mostly looking for a comparison of lines >> of code, but any other metric, such as time to market and code quality >> metrics could also be >> > > ... loads of great references ... Thank you all for your help! These references are a great help for pushing Haskell at work. -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080820/de9295d1/attachment.htm From dons at galois.com Wed Aug 20 17:36:54 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 20 17:35:45 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <1f3dc80d0808201432s5d26e1dbv4f2c25407ffdc3c@mail.gmail.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> <80372216-E479-4291-B973-A49F0D7DF121@galois.com> <1f3dc80d0808201432s5d26e1dbv4f2c25407ffdc3c@mail.gmail.com> Message-ID: <20080820213654.GL6770@scytale.galois.com> garious: > On Aug 19, 2008, at 9:12 AM, Greg Fitzgerald wrote: > > Does anyone know of a good case study comparing a project written in C > versus one written in Haskell? I'm mostly looking for a comparison of > lines of code, but any other metric, such as time to market and code > quality metrics could also be > > > ... loads of great references ... > > Thank you all for your help! These references are a great help for > pushing Haskell at work. I've also set up the "Who's using Haskell" section on haskell.org's front page -- let me know what you think -- with further documentation on the Industry page, with references to CUFP. Domain-specific stories there can be useful. -- Don From thomas.dubuisson at gmail.com Thu Aug 21 01:34:46 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Wed Aug 20 18:33:57 2008 Subject: [Haskell-cafe] a recent Haskell contribution? In-Reply-To: <5ae4f2ba0808200128x3530f634sd85feda3508fab8d@mail.gmail.com> References: <5ae4f2ba0808200128x3530f634sd85feda3508fab8d@mail.gmail.com> Message-ID: <1219296886.18526.6.camel@myhost> You might be talking about my 'ipc' library [1] I mentioned here a little while ago [2]. Don't forget the plethora of caviats (quick hack, BSD sockets, trunkates messages around 4 kB). I thought I'd be interested in developing and supporting some high level IPC library but I'm really not and I don't foresee many users. If no ones becomes interested in this library, and that wouldn't be surprising, I intend to delete it from hackage (if possible) to help the community avoid clutter. [1] http://www.haskell.org/haskellwiki/IPC [2] http://www.mail-archive.com/haskell-cafe@haskell.org/msg43842.html On Wed, 2008-08-20 at 03:28 -0500, Galchin, Vasili wrote: > Hello, > > Recently someone made a post about a message-passing IPC that > they contributed (within one month?). I have been searching the > Haskell cafe archive to no avail. Can the contributor (or any one > else) tell where the code is and any papers? > > Thank you, Vasili > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From duncan.coutts at worc.ox.ac.uk Wed Aug 20 19:23:58 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 20 19:22:45 2008 Subject: [Haskell-cafe] Re: missingH 0.18.6 - problems with cabal configure In-Reply-To: References: <5ae4f2ba0808180137k4ed172c4r6ba9bc4960f1e905@mail.gmail.com> <1219055806.8816.29.camel@bernH> Message-ID: <1219274638.13639.306.camel@localhost> On Wed, 2008-08-20 at 20:53 +0200, Ben Franksen wrote: > Andrew U. Frank wrote: > > > when i run cabal i get an error message: > > :~/haskellSources/packages/MissingH-0.18.6$ runhaskell Setup configure > > > > Setup.hs:19:35: > > Couldn't match expected type `(Either > > GenericPackageDescription > > PackageDescription, > > HookedBuildInfo)' > > against inferred type `PackageDescription' > > In the first argument of `(confHook defaultUserHooks)', namely > > `mydescrip' > > In the expression: > > let > > mydescrip = case os of > > "mingw32" -> ... > > _ -> ... > > in (confHook defaultUserHooks) mydescrip flags > > In the definition of `customConfHook': > > customConfHook descrip flags > > = let mydescrip = ... > > in (confHook defaultUserHooks) mydescrip > > flags > > > > > > what is wrong? i use ghc 6.8.2 and cabal 1.2.3.0 > > Looks like you'll have to upgrade Cabal (the library). Which version exactly > you need I don't know but I'd try the latest and if that fails from there > on work backwards. Actually it's an API change that came in in Cabal-1.2. Looking at the code in the error message it looks like you're generating a different package description based on the OS. That can now be done declaratively in the .cabal file itself using something like: library build-depends: base, blah, blah if os(windows) build-depends: Win32 cpp-options: -DDO_THE_OTHER_THING else ... Take a look in the Cabal user guide or at other .cabal files for examples. Duncan From duncan.coutts at worc.ox.ac.uk Wed Aug 20 19:42:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 20 19:40:52 2008 Subject: [Haskell-cafe] cabal build command and package versions In-Reply-To: <5ce89fb50808201153kcdcf062i8a226afb9916d059@mail.gmail.com> References: <5ce89fb50808201153kcdcf062i8a226afb9916d059@mail.gmail.com> Message-ID: <1219275725.13639.316.camel@localhost> On Wed, 2008-08-20 at 13:53 -0500, Nicolas Frisby wrote: > I have a question about cabal's behavior for the build command. When > using the build command on a cabalized project, any version changes > for installed packages go unnoticed - the necessary modules in the > project are not re-compiled. Yes. That's a ghc bug. > If however, you run the configure command (though the .cabal file for > the project has not changed) and then the build command, the > appropriate modules (and only the appropriate modules) are > re-compiled. Really? I didn't think that made any difference. I've no idea what configure would be doing that would get ghc to notice when it simply lacks the ability to do so in general. > Not knowing that the configure command is necessary to detect changes > in package that the current project depends on and proceeding only > with the build command has led to BusErrors and GHC incurring the > impossible in my exploration. Yes, it's a pretty annoying ghc bug. You'll be glad to know that it is fixed in ghc-6.10: http://hackage.haskell.org/trac/ghc/ticket/1372 You'll notice a lot of people have commented on this one. It's tripped up a lot of people. > Is there a reason that the build command does not check the packages > for version changes? It seems fair to expect package-sensitivity of > the process that determines if modules need to be re-compiled. This > process, I think, is part of the build command and not the configure > command. There's really not much we can do in Cabal itself. It has to be fixed in ghc and fortunately it now is fixed. That's because Cabal just uses ghc --make for builds and rebuilds, so if it doesn't realise that it has to rebuild after dependent packages change then we can't do much. As I say, I've no idea why configure should make any difference. If it does it's only by fluke and not design. Duncan From garious at gmail.com Wed Aug 20 19:53:46 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Aug 20 19:52:40 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <20080820213654.GL6770@scytale.galois.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> <80372216-E479-4291-B973-A49F0D7DF121@galois.com> <1f3dc80d0808201432s5d26e1dbv4f2c25407ffdc3c@mail.gmail.com> <20080820213654.GL6770@scytale.galois.com> Message-ID: <1f3dc80d0808201653i1a13f97eu8a805af2fa11ac1d@mail.gmail.com> >> Greg wrote: >> Thank you all for your help! These references are a great help for >> pushing Haskell at work. > > Don wrote: > I've also set up the "Who's using Haskell" section on haskell.org's > front page -- let me know what you think Great, thanks! I added Qualcomm. -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080820/64e7d666/attachment.htm From ok at cs.otago.ac.nz Wed Aug 20 19:57:23 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Aug 20 19:56:19 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <48AC0BD8.8070001@millstream.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> <48AC0BD8.8070001@millstream.com> Message-ID: <9618F840-5499-45DB-8DA1-CF34190AD9D6@cs.otago.ac.nz> Speaking of GdH, the web page http://www.macs.hw.ac.uk/~dsg/gdh/ was last updated in June 2007, it says, but the binary snapshot (Linux only) is February 2002, and the "installing GdH" part says it's built using the GHC 5.00 sources. Is GdH dead, or is there a more up to date version lurking somewhere else? From dons at galois.com Wed Aug 20 20:00:57 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 20 19:59:48 2008 Subject: [Haskell-cafe] lines of code metrics In-Reply-To: <1f3dc80d0808201653i1a13f97eu8a805af2fa11ac1d@mail.gmail.com> References: <1f3dc80d0808190912r3d0c2be4gd0247ba2db7870bc@mail.gmail.com> <80372216-E479-4291-B973-A49F0D7DF121@galois.com> <1f3dc80d0808201432s5d26e1dbv4f2c25407ffdc3c@mail.gmail.com> <20080820213654.GL6770@scytale.galois.com> <1f3dc80d0808201653i1a13f97eu8a805af2fa11ac1d@mail.gmail.com> Message-ID: <20080821000057.GA8189@scytale.galois.com> garious: > >> Greg wrote: > >> Thank you all for your help! These references are a great help for > >> pushing Haskell at work. > > > > Don wrote: > > I've also set up the "Who's using Haskell" section on [1]haskell.org's > > front page -- let me know what you think > > Great, thanks! I added Qualcomm. Awesome. I'd strongly encourage people using Haskell in their workplace to mention this on the Industry wiki, http://haskell.org/haskellwiki/Haskell_in_industry -- Don From vigalchin at gmail.com Thu Aug 21 01:36:34 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 21 01:35:28 2008 Subject: [Haskell-cafe] the "process" package ... In-Reply-To: <1219232935.13639.285.camel@localhost> References: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> <1219232935.13639.285.camel@localhost> Message-ID: <5ae4f2ba0808202236k1d287520v1f3503fa6f968773@mail.gmail.com> Hi Duncan, In reality there is a complaint about no "configure" file. In any case, you really mean "autoconf" and not "autoreconf" yes? If I should run "autoconf", there is no configure.ac or configure.in file under the process directory! ?? Thanks, Vasili On Wed, Aug 20, 2008 at 6:48 AM, Duncan Coutts wrote: > On Wed, 2008-08-20 at 03:09 -0500, Galchin, Vasili wrote: > > Hello, > > > > The "process" package Internal.hs references HsProcessConfig.h > > but this include file is not in the package "include" directory. Is > > this C include supposed to be generated? ?? > > Yes. It's generated by the ./configure script, which gets run > automatically when you configure the package in the standard way. If you > got the code straight from darcs then you need to run autoreconf first > to generate the ./configure script. > > Duncan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080821/ec608cb1/attachment.htm From simonpj at microsoft.com Thu Aug 21 03:23:56 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 21 03:22:51 2008 Subject: [Haskell-cafe] cabal build command and package versions In-Reply-To: <1219275725.13639.316.camel@localhost> References: <5ce89fb50808201153kcdcf062i8a226afb9916d059@mail.gmail.com> <1219275725.13639.316.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE853DF3A@EA-EXMSG-C334.europe.corp.microsoft.com> | On Wed, 2008-08-20 at 13:53 -0500, Nicolas Frisby wrote: | > I have a question about cabal's behavior for the build command. When | > using the build command on a cabalized project, any version changes | > for installed packages go unnoticed - the necessary modules in the | > project are not re-compiled. | | Yes. That's a ghc bug. Different to the one below? Is it in Trac? | > Not knowing that the configure command is necessary to detect changes | > in package that the current project depends on and proceeding only | > with the build command has led to BusErrors and GHC incurring the | > impossible in my exploration. | | Yes, it's a pretty annoying ghc bug. You'll be glad to know that it is | fixed in ghc-6.10: | | http://hackage.haskell.org/trac/ghc/ticket/1372 | | You'll notice a lot of people have commented on this one. It's tripped | up a lot of people. And happily it's fixed for 6.10! Simon From magnus at therning.org Thu Aug 21 03:41:09 2008 From: magnus at therning.org (Magnus Therning) Date: Thu Aug 21 03:40:01 2008 Subject: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages In-Reply-To: References: Message-ID: Sorry for not responding earlier but I didn't pay attention to this thread at the time. The reason for finding it now is that I listened to the FLOSS Weekly's episode on CouchDB yesterday; I stumbled on this email from a search for haskell+couchdb. On Sat, Jan 5, 2008 at 4:14 PM, Dimitry Golubovsky wrote: > 4. The dataenc package (http://code.haskell.org/dataenc/devo/) from > which I pulled the Codec.Binary.Base64 module. The package may need > some adjustment to GHC 6.8.x packages structure as only "base" listed > in build-depends does not seem to be enough: when building it, Cabal > complains for hidden packages such as collections (which I had to add > manually to the cabal file), etc. Is it some problem with my GHC > setup, or does just the dataenc.cabal need to be updated? As the author of dataenc I'm interested in fixing any problems you see with it. Maybe you could offer some more information: 1. Is this still a problem? (I'm using GHC 6.8.2 and I'm having no such problems at the moment.) 2. What can I do to make sure that I get contacted if similar issues come up in the future? (Currently bugs can only be reported by contacting me directly, preferably via email. Since you didn't I suspect I haven't communicated that clearly enough though.) /M From marlowsd at gmail.com Thu Aug 21 03:52:36 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 21 03:51:36 2008 Subject: [Haskell-cafe] Re: unknown flags scramble In-Reply-To: <2518b95d0808201315l7f09db1dg36e64fa0f4a71d73@mail.gmail.com> References: <2518b95d0808201315l7f09db1dg36e64fa0f4a71d73@mail.gmail.com> Message-ID: <48AD1EC4.3070605@gmail.com> Evan Laforge wrote: > I've been getting a mysterious error for a while now. It's come and > gone, but seems to be showing up slightly more consistently now. > Before I was on ghc 6.8.2 and now I'm on ghc 6.8.3, OS X 10.4 and now > 10.5, i386 arch. The problem is that randomly while compiling I get > an error like this: > > unknown flags in {-# OPTIONS #-} pragma: > -XDeriveDataTypeabl Font(..), FontFace(..) ) where import qualified Data.Generics as > Foreign import qualified Ui.Util as Util {-# LINE 14 "Ui/Font.hsc" > > It looks like somehow pragma parsing gets a bunch of random junk > scrambled in. In the past this would happen consistently until I did > a make clean and rebuild, but more recently all I have to do is try > again and it doesn't happen the second time. I haven't gotten it > while compiling for a while, but since I'm using hint which uses the > ghc api to interpret haskell, I'm getting this quite frequently inside > a GhcException when hint wants to interpret some code. I've also > gotten this from ghci occasionally, and the usual fix is just to do a > reload, and the second time it works. > > Does this sound familiar to anyone? It's not fatal since a retry > clears things up, but it's a little worrying and would not look very > good in released software. I cast about a bit on the ghc trac and > didn't find any open bugs like this. This is one symptom of http://hackage.haskell.org/trac/ghc/ticket/1736, which turned out to be the same bug as http://hackage.haskell.org/trac/ghc/ticket/2240, and haunted us for a long time before we found it. Sadly we found it after the 6.8.3 release, but you could backport the fix and build your own 6.8.3 if you are badly affected. Cheers, Simon From qdunkan at gmail.com Thu Aug 21 03:57:12 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Thu Aug 21 03:56:03 2008 Subject: [Haskell-cafe] Re: unknown flags scramble In-Reply-To: <48AD1EC4.3070605@gmail.com> References: <2518b95d0808201315l7f09db1dg36e64fa0f4a71d73@mail.gmail.com> <48AD1EC4.3070605@gmail.com> Message-ID: <2518b95d0808210057v5d876505jbcb3a30bafaa8bad@mail.gmail.com> > This is one symptom of http://hackage.haskell.org/trac/ghc/ticket/1736, > which turned out to be the same bug as > http://hackage.haskell.org/trac/ghc/ticket/2240, and haunted us for a long > time before we found it. > > Sadly we found it after the 6.8.3 release, but you could backport the fix > and build your own 6.8.3 if you are badly affected. That's great to hear! Well, about it being fixed I mean. I think I can live with this until the next ghc release... yet another reason to await it eagerly! From chak at cse.unsw.edu.au Thu Aug 21 05:06:04 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Aug 21 05:05:02 2008 Subject: [Haskell-cafe] Haskell Xcode Plugin In-Reply-To: <449D8487-0EC8-43D8-9259-E34633E2E6AB@gmx.net> References: <449D8487-0EC8-43D8-9259-E34633E2E6AB@gmx.net> Message-ID: Dennis Buchmann: > during my search for an acceptable development environment under > Mac OS X I found this Plugin for Xcode: http://hoovy.org/HaskellXcodePlugin/ > > Unfortunately, I'm not able to get it to run in Xcode v3.0 and the > developer seems > to be not contactable at the moment. > So, has anyone installed this plugin successfully (with problems in > the beginning)? I have a student working on a plugin for Xcode 3.0. Hopefully, he'll be able to release something in about two month. Manuel From duncan.coutts at worc.ox.ac.uk Thu Aug 21 06:01:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 21 05:59:46 2008 Subject: [Haskell-cafe] the "process" package ... In-Reply-To: <5ae4f2ba0808202236k1d287520v1f3503fa6f968773@mail.gmail.com> References: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> <1219232935.13639.285.camel@localhost> <5ae4f2ba0808202236k1d287520v1f3503fa6f968773@mail.gmail.com> Message-ID: <1219312862.13639.322.camel@localhost> On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: > Hi Duncan, > > In reality there is a complaint about no "configure" file. In any > case, you really mean "autoconf" and not "autoreconf" yes? If I should > run "autoconf", there is no configure.ac or configure.in file under > the process directory! ?? Ah, you're using process-1.0.0.0 from hackage. It does indeed appear to be borked because it specifies build-type: Configure and yet contains no ./configure script. Sorry, I assumed that you were missing ./configure because you were using the darcs version. Duncan From duncan.coutts at worc.ox.ac.uk Thu Aug 21 06:03:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 21 06:01:44 2008 Subject: [Haskell-cafe] cabal build command and package versions In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE853DF3A@EA-EXMSG-C334.europe.corp.microsoft.com> References: <5ce89fb50808201153kcdcf062i8a226afb9916d059@mail.gmail.com> <1219275725.13639.316.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE853DF3A@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1219312981.13639.324.camel@localhost> On Thu, 2008-08-21 at 08:23 +0100, Simon Peyton-Jones wrote: > | On Wed, 2008-08-20 at 13:53 -0500, Nicolas Frisby wrote: > | > I have a question about cabal's behavior for the build command. When > | > using the build command on a cabalized project, any version changes > | > for installed packages go unnoticed - the necessary modules in the > | > project are not re-compiled. > | > | Yes. That's a ghc bug. > > Different to the one below? Is it in Trac? Same one, the one recently fixed. > | Yes, it's a pretty annoying ghc bug. You'll be glad to know that it is > | fixed in ghc-6.10: > | > | http://hackage.haskell.org/trac/ghc/ticket/1372 > | > | You'll notice a lot of people have commented on this one. It's tripped > | up a lot of people. > > And happily it's fixed for 6.10! yay :-) Duncan From zooko at zooko.com Thu Aug 21 12:59:29 2008 From: zooko at zooko.com (zooko) Date: Thu Aug 21 12:58:50 2008 Subject: [Haskell-cafe] darcs upgrade HOWTO (was: poll: how can we help you contribute to darcs?) In-Reply-To: <87wsiwc6z5.fsf@malde.org> References: <4a0b969d0808010845g44ecdcd7n52b0bb431c73d70@mail.gmail.com> <1217796230.7661.77.camel@localhost> <87k5exazcd.fsf@malde.org> <87wsiwc6z5.fsf@malde.org> Message-ID: On Aug 5, 2008, at 0:26 AM, Ketil Malde wrote: > The consequences of moving to the darcs-2 format are a bit unclear to > me. For instance, I'd like to keep my main (export) repo in darcs-1 > format, in order to make it as accessible as possible (Ubuntu still > ships with darcs-1.0.9, and that's a fairly cutting edge > distribution.) Can I convert my working repos to darcs-2? Should I? > How about darcs-hashed? In short, I'd like to see examples of > recommended migration strategies, and associated benefits. Here's what I recommend, and what I've been doing for months, both with the large Tahoe code base -- http://allmydata.org/trac/tahoe and with numerous smaller codebases -- http://allmydata.org/trac . 1. Upgrade any executables you have to the latest stable version of darcs immediately. The new executables are fully backwards compatible -- you will not have any compatibility problems as a result of upgrading. They are also much less buggy and faster than older darcs executables. (There are at least two known issues with the darcs-2.0.2 executable which cause performance problems -- one is a issue with ghc v6.8.2 and the other is an issue with the latest version of libcurl -- v7.18.2. Hopefully the darcs core team will release darcs-2.0.3 soon to fix these two issues, but even if darcs-2.0.2 is still the current version, I recommend it over any previous version.) If your use of darcs is currently satisfying (fast enough, no bugs getting in your way), then stop at this step. You are now using the latest stable darcs executable while using old-fashioned darcs-v1 repositories. Other people who are using older versions of darcs can continue to share patches with your repositories just like always. 2. If there are problems with this situation of using darcs-2 executables and darcs-1-format repositories, then report it to the darcs-users mailing list, and then make a new hashed-format repository in parallel with your existing darcs-1-format repository, like this: darcs get --hashed ${repo} ${repo}-hashedformat Now people who have new darcs-v2 can push and pull to the - hashedformat repository and people who have darcs-v1 can continue to push and pull to the original repository. You can transfer patches between those repositories with normal darcs push and pull. For those projects of mine which have a high rate of patches I have gone ahead and added post-apply hooks to automatically do a "push --all" to the other one, like this: echo "apply posthook darcs push --all --repodir=/home/source/darcs/ tahoe/${repo}-hashedformat /home/source/darcs/tahoe/${repo}" >> $ {repo}-hashedformat/_darcs/prefs/defaults echo "apply run-posthook" >> ${repo}-hashedformat/_darcs/prefs/defaults echo "apply posthook darcs push --all --repodir=/home/source/darcs/ tahoe/${repo} /home/source/darcs/tahoe/${repo}-hashedformat" >> $ {repo}/_darcs/prefs/defaults echo "apply run-posthook" >> ${repo}/_darcs/prefs/defaults (Note that this is mutually recursive, but it terminates because the post-apply hook doesn't trigger in the case that zero patches were pushed.) If your use of darcs is currently satisfying then stop at this step. You are now using the latest stable darcs executable, and maintaining two darcs repositories -- an old-fashioned darcs-1-format repository for your darcs-1-executable-using friends and a hashed-format repository for your darcs-2-executable using friends. Your post- apply hooks cause these two repositories to get automatically synced with each other. 3. If there are problems with this situation of using darcs-2 executables and a pair of repos -- one of which is darcs-1-format repo for the use of darcs-1-executable-using users and the other of which is a hashed-format repo for the use of darcs-2-executable-using users -- then report it to the darcs-users mailing list and await further instructions. Note that these instructions do not involve any use of darcs-2-format repositories. Those are only for projects which (a) have no darcs-1- executable-using users, and (b) have no extant branches stored in darcs-1-format or hashed-format repositories. Personally step 2 has satisfied all my needs so I use the step 2 strategy for all my publicly shared repositories, although I do tend to create new private repositories with darcs-2-format. If someone wants to adapt this message to the darcs wiki I would be grateful. Regards, Zooko http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $5/month From kaol at iki.fi Thu Aug 21 13:10:08 2008 From: kaol at iki.fi (Kari Pahula) Date: Thu Aug 21 13:09:00 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <87r68kg0e3.wl%jeremy@n-heptane.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> Message-ID: <20080821171008.GA21733@piperka.net> On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote: > - the cdbs extension for supporting haskell (the one posted on > debian-haskell mailing list a while ago) I keep the newest version of that at http://people.debian.org/~kaol/repos/hlibrary/ One thing that it doesn't do yet is to register the -doc packages. From dons at galois.com Thu Aug 21 14:18:03 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 21 14:16:57 2008 Subject: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages In-Reply-To: References: Message-ID: <20080821181803.GC10969@scytale.galois.com> magnus: > Sorry for not responding earlier but I didn't pay attention to this > thread at the time. The reason for finding it now is that I listened > to the FLOSS Weekly's episode on CouchDB yesterday; I stumbled on this > email from a search for haskell+couchdb. > > On Sat, Jan 5, 2008 at 4:14 PM, Dimitry Golubovsky wrote: > > 4. The dataenc package (http://code.haskell.org/dataenc/devo/) from > > which I pulled the Codec.Binary.Base64 module. The package may need > > some adjustment to GHC 6.8.x packages structure as only "base" listed > > in build-depends does not seem to be enough: when building it, Cabal > > complains for hidden packages such as collections (which I had to add > > manually to the cabal file), etc. Is it some problem with my GHC > > setup, or does just the dataenc.cabal need to be updated? > > As the author of dataenc I'm interested in fixing any problems you see > with it. Maybe you could offer some more information: > > 1. Is this still a problem? (I'm using GHC 6.8.2 and I'm having no > such problems at the moment.) > 2. What can I do to make sure that I get contacted if similar issues > come up in the future? (Currently bugs can only be reported by > contacting me directly, preferably via email. Since you didn't I > suspect I haven't communicated that clearly enough though.) I think the best result here would be to put a CouchDB binding on hackage. Is anyone in a position to do this? -- Don From dons at galois.com Thu Aug 21 14:19:55 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 21 14:18:42 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <20080821171008.GA21733@piperka.net> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> Message-ID: <20080821181955.GD10969@scytale.galois.com> kaol: > On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote: > > - the cdbs extension for supporting haskell (the one posted on > > debian-haskell mailing list a while ago) > > I keep the newest version of that at > http://people.debian.org/~kaol/repos/hlibrary/ > > One thing that it doesn't do yet is to register the -doc packages. Can the Debian/Haskell interest parties say something about who's doing what in this area? Is there hope for a concrete effort to import large numbers of hackage apps and tools into Debian? -- Don From golubovsky at gmail.com Thu Aug 21 14:29:21 2008 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Thu Aug 21 14:28:12 2008 Subject: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages In-Reply-To: <20080821181803.GC10969@scytale.galois.com> References: <20080821181803.GC10969@scytale.galois.com> Message-ID: Don & All, On 8/21/08, Don Stewart wrote: > I think the best result here would be to put a CouchDB binding > on hackage. > > Is anyone in a position to do this? As for myself, honestly, I did not plan to do this at this time as I am busy with other stuff (Yhc Core conversion). I'd be glad to help anyone who is willing to put CouchDB interface on Hackage. I'd like to note though that this may be a bit premature at the moment. CouchDB has been going through significant redevelopment within Apache Incubator (I am not a developer, but just watch silently), and what is available within the Yhc source tree may not work properly with the current CouchDB: it was for 0.7.x while they have 0.8.x in the incubator. So I would wait for "graduation" of CouchDB from the incubator, or at least checked with its core developers regarding API stability. Besides, the CouchDB interface in question was written only to satisfy the needs of the Yhc Web Service and may be missing some pieces, although it may be good for a starting point. Thank you. -- Dimitry Golubovsky Anywhere on the Web From golubovsky at gmail.com Thu Aug 21 15:00:11 2008 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Thu Aug 21 14:59:02 2008 Subject: [Haskell-cafe] Lines of code metrics Message-ID: Hi, Greg Fitzgerald wrote: >Does anyone know of a good case study comparing a project written in C >versus one written in Haskell? I'm mostly looking for a comparison of lines >of code, but any other metric, such as time to market and code quality >metrics could also be Just curious, has anybody tried to apply Halstead's code metrics (see e. g. http://www.sei.cmu.edu/str/descriptions/halstead_body.html), but there is a 70s' book titled "Elements of Software Science" to Haskell and other functional languages vs. C and other imperative languages? I myself played with these calculations in late 80s trying to estimate code quality of Pascal programs on PDP-11, but that was a pain to count functions' operands properly as they might come from global variables. Application of these formulas to functional languages might be mich cleaner, so has anybody tried? Thanks. -- Dimitry Golubovsky Anywhere on the Web From jeremy at n-heptane.com Thu Aug 21 15:09:04 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Aug 21 15:03:12 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <20080821171008.GA21733@piperka.net> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> Message-ID: <87ljyqfanj.wl%jeremy@n-heptane.com> At Thu, 21 Aug 2008 20:10:08 +0300, Kari Pahula wrote: > > On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote: > > - the cdbs extension for supporting haskell (the one posted on > > debian-haskell mailing list a while ago) > > I keep the newest version of that at > http://people.debian.org/~kaol/repos/hlibrary/ > > One thing that it doesn't do yet is to register the -doc packages. Cool. We made some modifications including some patches for the -doc stuff I believe. I'll try to do a merge and get some patches back to you. j. From adam.smyczek at gmail.com Thu Aug 21 15:20:47 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Thu Aug 21 15:19:44 2008 Subject: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages In-Reply-To: References: <20080821181803.GC10969@scytale.galois.com> Message-ID: Actually few days ago I run into CouchDB and started to prototype a binding using JSON and Curl from hackage. Once the base functionality is supported, I could post it for review. Adam On Aug 21, 2008, at 11:29 AM, Dimitry Golubovsky wrote: > Don & All, > > On 8/21/08, Don Stewart wrote: > >> I think the best result here would be to put a CouchDB binding >> on hackage. >> >> Is anyone in a position to do this? > > As for myself, honestly, I did not plan to do this at this time as I > am busy with other stuff (Yhc Core conversion). I'd be glad to help > anyone who is willing to put CouchDB interface on Hackage. > > I'd like to note though that this may be a bit premature at the > moment. CouchDB has been going through significant redevelopment > within Apache Incubator (I am not a developer, but just watch > silently), and what is available within the Yhc source tree may not > work properly with the current CouchDB: it was for 0.7.x while they > have 0.8.x in the incubator. > > So I would wait for "graduation" of CouchDB from the incubator, or at > least checked with its core developers regarding API stability. > > Besides, the CouchDB interface in question was written only to satisfy > the needs of the Yhc Web Service and may be missing some pieces, > although it may be good for a starting point. > > Thank you. > > -- > Dimitry Golubovsky > > Anywhere on the Web > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From waldmann at imn.htwk-leipzig.de Thu Aug 21 15:31:26 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Aug 21 15:30:18 2008 Subject: [Haskell-cafe] Lines of code metrics In-Reply-To: References: Message-ID: <48ADC28E.8010201@imn.htwk-leipzig.de> > Just curious, has anybody tried to apply Halstead's code metrics [...] As I understand it, Halstead's metric punishes the re-use of "operands" (= variables). This is what happens if you start your program with a bunch of global definitions (e.g. int i,j,k,l because you might want them as loop indices) that actually should be local. This totally does not apply to Haskell: there is no assignment, you cannot overwrite, so indeed each operand ("variable") serves only one purpose, as it should be. NB: My private set of Haskell metrics: * lines of code (per declaration) (should be <= 5) * number of declarations (per module) (should be <= 5 as well :-) * number of usages of Int, String, List, IO (should be <= 0 :-) :-) Not entirely joking - J.W. From clifford.beshers at gmail.com Thu Aug 21 15:42:13 2008 From: clifford.beshers at gmail.com (Clifford Beshers) Date: Thu Aug 21 15:41:06 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <20080821181955.GD10969@scytale.galois.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> Message-ID: <6841b9520808211242i2e177d82jea1cb4d5e99e103a@mail.gmail.com> On Thu, Aug 21, 2008 at 11:19 AM, Don Stewart wrote > > > > Can the Debian/Haskell interest parties say something about > who's doing what in this area? Is there hope for a concrete > effort to import large numbers of hackage apps and tools into Debian? I made a stab at it, but ran into issues with build dependencies that I didn't have the time to solve, so I switched to just importing the packages I needed. Currently, we at SeeReason are building packages for our own use based on Ubuntu Hardy Heron. People are welcome to use them at their own risk. If it breaks your computer, you get to keep both halves. People are also welcome to use our autobuilder, which we use to build the packages. All packages can be found at deb.seereason.com. We are trying to limit the amount of time we spend on these tools, but would be happy to provide pointers to self-starters and/or discuss options for other people to work on them. Cliff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080821/e7ce1603/attachment.htm From gwern0 at gmail.com Thu Aug 21 17:00:16 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Aug 21 16:59:47 2008 Subject: [Haskell-cafe] ANN: Mueval 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.6.4 Message-ID: <20080821210016.GA17488@craft> Evening folks. So it's that time again, to do a Mueval announcement! This time I'd like to announce version 0.6.4, & 0.6.3. And 0.6.2. And 0.6.1. And 0.6. And 0.5.1. These releases have some nice stuff to them; perhaps the most interesting aspect is that I've carried through on my threats^Wpromises, and Lambdabot in #haskell now uses Mueval. GETTING All the stuff from the previous ANNs still apply here: you can get it at , do a 'darcs get --lazy http://code.haskell.org/mubot/', cabal-install mueval, and so on. DEPENDENCIES 0.6.4 does add an additional dependency, on haskell-src-exts, for use in some experimental parsing code, so you'll now need that in addition to Hint, utf8-string, and show. (Upgrading Hint is mandatory, utf8-string unnecessary, and show nice but certainly not necessary.) BUILDING Same as usual. CHANGES 0.5.1 * SmallCheck support 0.6 * A new option, --loadfile, which loads a given *.{l}hs file with a module and makes its function available for evaluation. This is a complex option; see the README. * Cleaner output, thanks to a needless show call sjanssen identified. 0.6.2 * Speed improvements (shorter timeouts, optimizations) * Mueval imports many more modules by default, so one can freely use standard functions from Control.Monad, for example; this also brings with it many test examples from #haskell. * experimental --noimports flag, to disable default imports (such as the above, and also of the Prelude). This was motivated by Lambdabot's Caleskell, but I'm not sure why it doesn't interact well with --loadfile (and so doesn't work with Lambdabot). 0.6.3 * Saizan contributed some significant improvements to error reporting and thread handling, so the infamous time-out errors are replaced by normal errors more reminiscent of GHCi. 0.6.4 * Fixed an issue with lazy printing of results * Exceptions are now caught and printed more prettily; again, thanks to Saizan * Forced a dependency on the latest Hint; this fixes an error where one could successfully evaluate: bash-3.2$ mueval -e '1 + 1 {- addition example -}' 2 but not: bash-3.2$ mueval -e '1 + 1 -- addition example' * Added a --rlimits option. I decided that the POSIX resource limits were causing too many people problems. So now non-time resource limits are disabled unless specifically requested with --rlimits. * mmorrow contributed some experimental parsing patches intended to catch subtle invocations of dangerous functions. If haskell-src-exts is too burdensome a dependency, Mueval/Context.hs and mueval.cabal can be easily edited to remove the dependency. KNOWN ISSUES * Qualified imports do not work. That is, one cannot do $ mueval -e 'M.map (+1) $ M.fromList [(1,2)]' or whatever and expect the proper Data.Map functions to be substituted in. This is a weakness in the GHC API, AFAIK. It is possible that this will be fixed in future versions of Hint or GHC, but I do not expect that to happen for months. * Many limits in System.Posix.Resource are simply completely broken for many users; that is, *no* value can be set using them. I have been unable to figure out the heck why this is the case (I can't reproduce it), and AFAIK no one has filed a bug with the GHC developers, so this probably won't be fixed anytime soon. -- gwern Secure wwics P415 SASP Comirex mailbomb ISADC Sayeret SBI Jatti -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080821/1c6a0097/attachment.bin From leather at cs.uu.nl Thu Aug 21 17:19:50 2008 From: leather at cs.uu.nl (Sean Leather) Date: Thu Aug 21 17:18:43 2008 Subject: [Haskell-cafe] Libraries of standard QuickCheck properties Message-ID: <3c6288ab0808211419y7bfe90a5o5040bf82e138ad9d@mail.gmail.com> This in response to a comment on a GHC ticket [1]. I thought it was interesting enough to warrant general discussion. Comment (by JeremyShaw): > > > Also, where does the H98 report say all instances of Eq must be > transitive, reflexive, symmetric, and antisymmetric? It just says "The Eq > class provides equality (==)..", whatever that might mean :-) > > Well, it does not say it explicitly, but I suspect H98's usage of Eq > implicitly demands those laws be followed. Indeed. The same goes for the implicit law that (x /= y) /= (x == y), since both (/=) and (==) can be overridden. [2] Hopefully in Haskell' the laws > will not only be stated, but there will be some QuickCheck-style > properties you can use to test your own instances ;) This is an interesting thought. Has there been any work towards collecting properties written with QuickCheck (or similar) into a reusable chunk of some form? It would be very convenient to have parametrized properties that tested implicit laws such as equality, monads, and other things that come with the Haskell Platform. Not only would such a library be useful to use, but it would provide a number of readily available examples for would-be testers, thus encouraging testing. Sean [1] http://hackage.haskell.org/trac/ghc/ticket/2528#comment:6 [2] http://www.haskell.org/tutorial/monads.html#sect9.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080821/89f2fc92/attachment-0001.htm From vigalchin at gmail.com Thu Aug 21 18:01:26 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 21 18:00:17 2008 Subject: [Haskell-cafe] the "process" package ... In-Reply-To: <1219312862.13639.322.camel@localhost> References: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> <1219232935.13639.285.camel@localhost> <5ae4f2ba0808202236k1d287520v1f3503fa6f968773@mail.gmail.com> <1219312862.13639.322.camel@localhost> Message-ID: <5ae4f2ba0808211501x6fb8ad5ckd07683752d658cd2@mail.gmail.com> how do I unbork it? Are darcs version of package same as hackage version of packages teh same contents? Regards, Vasili On Thu, Aug 21, 2008 at 5:01 AM, Duncan Coutts wrote: > On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: > > Hi Duncan, > > > > In reality there is a complaint about no "configure" file. In any > > case, you really mean "autoconf" and not "autoreconf" yes? If I should > > run "autoconf", there is no configure.ac or configure.in file under > > the process directory! ?? > > Ah, you're using process-1.0.0.0 from hackage. It does indeed appear to > be borked because it specifies build-type: Configure and yet contains > no ./configure script. > > Sorry, I assumed that you were missing ./configure because you were > using the darcs version. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080821/73081270/attachment.htm From lrpalmer at gmail.com Thu Aug 21 18:01:48 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Aug 21 18:00:40 2008 Subject: [Haskell-cafe] Libraries of standard QuickCheck properties In-Reply-To: <3c6288ab0808211419y7bfe90a5o5040bf82e138ad9d@mail.gmail.com> References: <3c6288ab0808211419y7bfe90a5o5040bf82e138ad9d@mail.gmail.com> Message-ID: <7ca3f0160808211501h24d27f84x59655a3ddf03b69b@mail.gmail.com> 2008/8/21 Sean Leather : > This in response to a comment on a GHC ticket [1]. I thought it was > interesting enough to warrant general discussion. > >> Comment (by JeremyShaw): >> >> > Also, where does the H98 report say all instances of Eq must be >> transitive, reflexive, symmetric, and antisymmetric? It just says "The Eq >> class provides equality (==)..", whatever that might mean :-) >> >> Well, it does not say it explicitly, but I suspect H98's usage of Eq >> implicitly demands those laws be followed. > > Indeed. The same goes for the implicit law that (x /= y) /= (x == y), since > both (/=) and (==) can be overridden. [2] > >> Hopefully in Haskell' the laws >> will not only be stated, but there will be some QuickCheck-style >> properties you can use to test your own instances ;) > > This is an interesting thought. Has there been any work towards collecting > properties written with QuickCheck (or similar) into a reusable chunk of > some form? Yes, it's in development, called 'checkers'. code.haskell.org/checkers Luke From arjun at cs.brown.edu Thu Aug 21 18:23:59 2008 From: arjun at cs.brown.edu (Arjun Guha) Date: Thu Aug 21 18:22:49 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? Message-ID: Hi, I'm using HTTP-3001.0.4 with GHC 6.8.3 under Mac OS X 10.5 and Debian Lenny. If I open and close many connections, I eventually get the error. Anyone else seen this before? *** Exception: socket: resource exhausted (Too many open files) Apparently, the socket is not closing. in TCP.hs:168, the call to shutdown is raising a "socket already closed" exception. So, the program never reaches the sClose on line 171. A simple fix is: wanderlust:Network arjun$ diff TCP.hs.original TCP.hs 172c172 < } --- > } `Exception.catch` (\_ -> sClose sk) The code that demonstrates this problem on Mac OS X is: > module Main where > > import Network.HTTP > import Network.URI (parseURI) > import Data.Maybe (fromJust) > import Control.Monad > > googleM n = do > s <- simpleHTTP $ Request (fromJust $ parseURI "http://www.google.com ") > GET [] "" > when (n `mod` 100 == 0) $ putStrLn (show n) > return () > > main = mapM_ googleM [1..5000] On Debian Lenny, the code works fine with google.com. However, when I try to connect to my local CouchDB server, it throws an exception after roughly 1000 connections. Thanks. Arjun From arjun at cs.brown.edu Thu Aug 21 18:29:14 2008 From: arjun at cs.brown.edu (Arjun Guha) Date: Thu Aug 21 18:28:05 2008 Subject: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages In-Reply-To: References: <20080821181803.GC10969@scytale.galois.com> Message-ID: > On 8/21/08, Don Stewart wrote: > >> I think the best result here would be to put a CouchDB binding >> on hackage. >> >> Is anyone in a position to do this? > > As for myself, honestly, I did not plan to do this at this time as I > am busy with other stuff (Yhc Core conversion). I'd be glad to help > anyone who is willing to put CouchDB interface on Hackage. I'm using CouchDB for a little HAppS-based web service. I'll put it on Hackage in about a week--once I'm done with the the web service. For the moment the code is here and is cabalized. http://github.com/arjunguha/haskell-couchdb/tree/master Feedback welcome. Arjun From atomb at galois.com Thu Aug 21 18:44:27 2008 From: atomb at galois.com (Aaron Tomb) Date: Thu Aug 21 18:43:19 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? In-Reply-To: References: Message-ID: <668127F9-24FB-49D5-BE7A-5D0EB23402FE@galois.com> On Aug 21, 2008, at 3:23 PM, Arjun Guha wrote: > Hi, > > I'm using HTTP-3001.0.4 with GHC 6.8.3 under Mac OS X 10.5 and > Debian Lenny. If I open and close many connections, I eventually > get the error. Anyone else seen this before? I've never looked into it deeply, but I just wanted to chime in that I've seen this, too. Aaron From dougal at dougalstanton.net Thu Aug 21 18:56:47 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Thu Aug 21 18:55:38 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? In-Reply-To: <668127F9-24FB-49D5-BE7A-5D0EB23402FE@galois.com> References: <668127F9-24FB-49D5-BE7A-5D0EB23402FE@galois.com> Message-ID: <2d3641330808211556g74eecdcax928609e260dbf5f9@mail.gmail.com> On Thu, Aug 21, 2008 at 11:44 PM, Aaron Tomb wrote: > > > I've never looked into it deeply, but I just wanted to chime in that I've > seen this, too. I may be confusing it with something else, but I seem to recall something very similar from a while back, in a blog post somewhere? I can't remember the details, but someone was writing a server application of some kind and came across a socket leaking error that was a one-line fix line this. The description and the fix just seem so familiar. :-\ Sorry, this is the most incoherent and useless post! Maybe someone else has been paying more attention and can remember who it was, and where. Cheers, D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From dougal at dougalstanton.net Thu Aug 21 19:02:33 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Thu Aug 21 19:01:25 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? In-Reply-To: <2d3641330808211556g74eecdcax928609e260dbf5f9@mail.gmail.com> References: <668127F9-24FB-49D5-BE7A-5D0EB23402FE@galois.com> <2d3641330808211556g74eecdcax928609e260dbf5f9@mail.gmail.com> Message-ID: <2d3641330808211602x5eac4852o434cedb663a76fd9@mail.gmail.com> On Thu, Aug 21, 2008 at 11:56 PM, Dougal Stanton wrote: Aha, I knew I wasn't dreaming! Paul Brown posted this discussion back in February. It looks like the same thing. Has there been an update of HTTP since then? Cheers, D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From arjun at cs.brown.edu Thu Aug 21 19:12:08 2008 From: arjun at cs.brown.edu (Arjun Guha) Date: Thu Aug 21 19:10:59 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? In-Reply-To: <2d3641330808211602x5eac4852o434cedb663a76fd9@mail.gmail.com> References: <668127F9-24FB-49D5-BE7A-5D0EB23402FE@galois.com> <2d3641330808211556g74eecdcax928609e260dbf5f9@mail.gmail.com> <2d3641330808211602x5eac4852o434cedb663a76fd9@mail.gmail.com> Message-ID: <873D8AFE-AF49-4509-A146-28D7D5A1D8F7@cs.brown.edu> > Aha, I knew I wasn't dreaming! > > > > Paul Brown posted this discussion back in February. It looks like the > same thing. Has there been an update of HTTP since then? Nope, it hasn't been updated. I'm just running a locally patched version. This is the same issue, thanks! Arjun From dm.maillists at gmail.com Thu Aug 21 20:04:30 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Thu Aug 21 20:03:34 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? In-Reply-To: <873D8AFE-AF49-4509-A146-28D7D5A1D8F7@cs.brown.edu> References: <2d3641330808211602x5eac4852o434cedb663a76fd9@mail.gmail.com> <873D8AFE-AF49-4509-A146-28D7D5A1D8F7@cs.brown.edu> Message-ID: <200808221204.30525.dm.maillists@gmail.com> On Fri, 22 Aug 2008 11:12:08 Arjun Guha wrote: > > Aha, I knew I wasn't dreaming! > > > > > > > > Paul Brown posted this discussion back in February. It looks like the > > same thing. Has there been an update of HTTP since then? > > Nope, it hasn't been updated. I'm just running a locally patched > version. This is the same issue, thanks! Beware of the browse function in Browser, there is a connection leak in there as well, at least there was back in March or April. Not sure if it has been fixed in the official repos. I seem to recall the sockets getting put into some half-closed state, presumably when GHC GC'd them, eventually exhausting limits. That may be particular to running on Linux, I guess. Dan From lane at downstairspeople.org Thu Aug 21 20:52:00 2008 From: lane at downstairspeople.org (Christopher Lane Hinson) Date: Thu Aug 21 20:50:51 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <20080821181955.GD10969@scytale.galois.com> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> Message-ID: > Can the Debian/Haskell interest parties say something about > who's doing what in this area? Is there hope for a concrete > effort to import large numbers of hackage apps and tools into Debian? > > -- Don I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at. Having a debianized cabal-install would be the biggest win in my book. If there were an unofficial debianized mirror of hackage, I probably wouldn't use it anyway. --Lane From bremner at unb.ca Thu Aug 21 21:32:25 2008 From: bremner at unb.ca (David Bremner) Date: Thu Aug 21 21:31:18 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> Message-ID: <0ttzdd4yxi.wl%bremner@pivot.cs.unb.ca> At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote: > > I'm not a DD, but I think uploading ~500 hackage packages to debian would > be a bit of a no-no. Debian packages are expected to have active > maintainers both upstream and on the debian side, and to build without a > hitch on ten different architectures, or they don't make it into stable > and the DD responsible gets whined at. Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages). Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team. David From bremner at unb.ca Thu Aug 21 21:35:50 2008 From: bremner at unb.ca (David Bremner) Date: Thu Aug 21 21:34:42 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> Message-ID: <0tsksx4yrt.wl%bremner@pivot.cs.unb.ca> At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote: > > I'm not a DD, but I think uploading ~500 hackage packages to debian would > be a bit of a no-no. Debian packages are expected to have active > maintainers both upstream and on the debian side, and to build without a > hitch on ten different architectures, or they don't make it into stable > and the DD responsible gets whined at. Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages). Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team. One of the main tools that makes this possible is dh-make-perl, which is the moral equivalent of cabal-debian, I guess. Just as important is the shared version control setup and team procedures. David From bremner at unb.ca Thu Aug 21 21:35:57 2008 From: bremner at unb.ca (David Bremner) Date: Thu Aug 21 21:34:51 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> Message-ID: <0tr68h4yrm.wl%bremner@pivot.cs.unb.ca> At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote: > > I'm not a DD, but I think uploading ~500 hackage packages to debian would > be a bit of a no-no. Debian packages are expected to have active > maintainers both upstream and on the debian side, and to build without a > hitch on ten different architectures, or they don't make it into stable > and the DD responsible gets whined at. Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages). Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team. One of the main tools that makes this possible is dh-make-perl, which is the moral equivalent of cabal-debian, I guess. Just as important is the shared version control setup and team procedures. David From duncan.coutts at worc.ox.ac.uk Thu Aug 21 18:29:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 21 22:04:34 2008 Subject: [Haskell-cafe] the "process" package ... In-Reply-To: <5ae4f2ba0808211501x6fb8ad5ckd07683752d658cd2@mail.gmail.com> References: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> <1219232935.13639.285.camel@localhost> <5ae4f2ba0808202236k1d287520v1f3503fa6f968773@mail.gmail.com> <1219312862.13639.322.camel@localhost> <5ae4f2ba0808211501x6fb8ad5ckd07683752d658cd2@mail.gmail.com> Message-ID: <1219357780.13639.357.camel@localhost> On Thu, 2008-08-21 at 17:01 -0500, Galchin, Vasili wrote: > how do I unbork it? Are darcs version of package same as hackage > version of packages teh same contents? To be honest I'd not bother. You already have the version of the process package that came with ghc and there are no new releases that you need. That's why nobody else noticed the problem, because nobody needs to install this package, because it comes with ghc. If you really want to re-install it anyway then you could use the darcs version that goes with the ghc-6.8.x branch: http://darcs.haskell.org/ghc-6.8/packages/process Obviously in principle the version on hackage should have worked. You'll be glad to know that hackage now checks that packages that use build-type Configure do indeed actually have a ./configure file, so this particular error cannot be repeated. Duncan > Regards, Vasili > > > On Thu, Aug 21, 2008 at 5:01 AM, Duncan Coutts > wrote: > On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: > > Hi Duncan, > > > > In reality there is a complaint about no "configure" > file. In any > > case, you really mean "autoconf" and not "autoreconf" yes? > If I should > > run "autoconf", there is no configure.ac or configure.in > file under > > the process directory! ?? > > > Ah, you're using process-1.0.0.0 from hackage. It does indeed > appear to > be borked because it specifies build-type: Configure and yet > contains > no ./configure script. > > Sorry, I assumed that you were missing ./configure because you > were > using the darcs version. > > Duncan > > > From duncan.coutts at worc.ox.ac.uk Thu Aug 21 22:15:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 21 22:14:25 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? In-Reply-To: <873D8AFE-AF49-4509-A146-28D7D5A1D8F7@cs.brown.edu> References: <668127F9-24FB-49D5-BE7A-5D0EB23402FE@galois.com> <2d3641330808211556g74eecdcax928609e260dbf5f9@mail.gmail.com> <2d3641330808211602x5eac4852o434cedb663a76fd9@mail.gmail.com> <873D8AFE-AF49-4509-A146-28D7D5A1D8F7@cs.brown.edu> Message-ID: <1219371348.13639.361.camel@localhost> On Thu, 2008-08-21 at 19:12 -0400, Arjun Guha wrote: > > Aha, I knew I wasn't dreaming! > > > > > > > > Paul Brown posted this discussion back in February. It looks like the > > same thing. Has there been an update of HTTP since then? > > Nope, it hasn't been updated. I'm just running a locally patched > version. This is the same issue, thanks! If someone could figure out the right fix and send it to the maintainer that'd be great. We do need a decent working pure-haskell http package. For one thing cabal-install uses the HTTP package and it has to work for downloading dozens or hundreds of packages in a single session. As an aside, cabal-install could use the Network.Browser module better, by using a single call to browse for all downloads rather than one per download. As I understand it, that'd allow it to re-use a single connection. Duncan From jason.dusek at gmail.com Thu Aug 21 22:46:08 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Aug 21 22:45:00 2008 Subject: [Haskell-cafe] parser combinators need how many values to report errors? Message-ID: <42784f260808211946v1e5be397y3b2417c48047af4a@mail.gmail.com> I'm looking for a copy of: Predictive Parser Combinators Need four Values to Report Errors. I've poked around on the JFP's web site at Cambridge and they don't seem to have Volume 6 anymore. -- _jsn From vigalchin at gmail.com Fri Aug 22 00:00:06 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Aug 21 23:58:56 2008 Subject: [Haskell-cafe] the "process" package ... In-Reply-To: <1219357780.13639.357.camel@localhost> References: <5ae4f2ba0808200109m1f7fd814j24bc494e002f68c@mail.gmail.com> <1219232935.13639.285.camel@localhost> <5ae4f2ba0808202236k1d287520v1f3503fa6f968773@mail.gmail.com> <1219312862.13639.322.camel@localhost> <5ae4f2ba0808211501x6fb8ad5ckd07683752d658cd2@mail.gmail.com> <1219357780.13639.357.camel@localhost> Message-ID: <5ae4f2ba0808212100s5adaa5dcg1abfbdef9c572e3c@mail.gmail.com> To be honest I'd not bother. You already have the version of the process > package that came with ghc and there are no new releases that you need. > That's why nobody else noticed the problem, because nobody needs to > install this package, because it comes with ghc. > problem here Duncan .. when I run "cabal install haskelldb" e.g. "process" is rightly seen as a dependency BUT unrightly as not currently installed .... ??? > > If you really want to re-install it anyway then you could use the darcs > version that goes with the ghc-6.8.x branch: > > http://darcs.haskell.org/ghc-6.8/packages/process > > Obviously in principle the version on hackage should have worked. You'll > be glad to know that hackage now checks that packages that use > build-type Configure do indeed actually have a ./configure file, so this > particular error cannot be repeated. > > Duncan > > > Regards, Vasili > > > > > > On Thu, Aug 21, 2008 at 5:01 AM, Duncan Coutts > > wrote: > > On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: > > > Hi Duncan, > > > > > > In reality there is a complaint about no "configure" > > file. In any > > > case, you really mean "autoconf" and not "autoreconf" yes? > > If I should > > > run "autoconf", there is no configure.ac or configure.in > > file under > > > the process directory! ?? > > > > > > Ah, you're using process-1.0.0.0 from hackage. It does indeed > > appear to > > be borked because it specifies build-type: Configure and yet > > contains > > no ./configure script. > > > > Sorry, I assumed that you were missing ./configure because you > > were > > using the darcs version. > > > > Duncan > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080821/b6a68e6f/attachment.htm From dm.maillists at gmail.com Fri Aug 22 00:15:28 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Fri Aug 22 00:14:28 2008 Subject: [Haskell-cafe] HTTP package: connection closing bug? In-Reply-To: <1219371348.13639.361.camel@localhost> References: <873D8AFE-AF49-4509-A146-28D7D5A1D8F7@cs.brown.edu> <1219371348.13639.361.camel@localhost> Message-ID: <200808221615.28998.dm.maillists@gmail.com> On Fri, 22 Aug 2008 14:15:48 Duncan Coutts wrote: > On Thu, 2008-08-21 at 19:12 -0400, Arjun Guha wrote: > > > Aha, I knew I wasn't dreaming! > > > > > > > > > > > > Paul Brown posted this discussion back in February. It looks like the > > > same thing. Has there been an update of HTTP since then? > > > > Nope, it hasn't been updated. I'm just running a locally patched > > version. This is the same issue, thanks! Looks like there is a patch committed to http's darcs repo, 3rd May, from prb to address this problem. > > If someone could figure out the right fix and send it to the maintainer > that'd be great. We do need a decent working pure-haskell http package. Agreed. I think http needs serious work before it would fit the bill though. > For one thing cabal-install uses the HTTP package and it has to work for > downloading dozens or hundreds of packages in a single session. > > As an aside, cabal-install could use the Network.Browser module better, > by using a single call to browse for all downloads rather than one per > download. As I understand it, that'd allow it to re-use a single > connection. It's quite likely you are leaking a connection on every call to browse. I recall someone asking about how to configure hackage's Apache to handle more than 1000 open connections... maybe cabal-install is the reason for it needing so many concurrent connections. I've sent a patch for Network.Browser.browse to Bjorn. Dan From vigalchin at gmail.com Fri Aug 22 01:29:40 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Aug 22 01:28:30 2008 Subject: [Haskell-cafe] question about uploads of code contribution Message-ID: <5ae4f2ba0808212229h774ad9c3sb7c1517f0e3b38e2@mail.gmail.com> Hello, 1) I want to upload a version with minor changes. Should I send out an "announcement"? 2) does the hackage database have a "reader/writer" lock to protect readers, i.e. people downloading when I am uploading? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080822/32178dd4/attachment.htm From jeremy at n-heptane.com Fri Aug 22 01:55:29 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Fri Aug 22 01:49:35 2008 Subject: [Haskell-cafe] question about uploads of code contribution In-Reply-To: <5ae4f2ba0808212229h774ad9c3sb7c1517f0e3b38e2@mail.gmail.com> References: <5ae4f2ba0808212229h774ad9c3sb7c1517f0e3b38e2@mail.gmail.com> Message-ID: <87fxoxfvam.wl%jeremy@n-heptane.com> At Fri, 22 Aug 2008 00:29:40 -0500, Galchin, Vasili wrote: > 2) does the hackage database have a "reader/writer" lock to protect > readers, i.e. people downloading when I am uploading? 1. new versions must have a different version number 2. the version number is in the tarball name therefore: 3. uploading a new version is a non-destructive operation and will not affect anyone downloading older versions. At least, that is my understanding. j. From vigalchin at gmail.com Fri Aug 22 02:05:02 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Aug 22 02:03:52 2008 Subject: [Haskell-cafe] question about uploads of code contribution In-Reply-To: <87fxoxfvam.wl%jeremy@n-heptane.com> References: <5ae4f2ba0808212229h774ad9c3sb7c1517f0e3b38e2@mail.gmail.com> <87fxoxfvam.wl%jeremy@n-heptane.com> Message-ID: <5ae4f2ba0808212305p5c796c4du65535789471ade3a@mail.gmail.com> ahhh ... makes perfect sense vis-a-vis the read/write problem Jeremy. Hopefully using an incremented version number is enforced via the hackage database!! ;^) Vasili On Fri, Aug 22, 2008 at 12:55 AM, Jeremy Shaw wrote: > At Fri, 22 Aug 2008 00:29:40 -0500, > Galchin, Vasili wrote: > > > 2) does the hackage database have a "reader/writer" lock to protect > > readers, i.e. people downloading when I am uploading? > > 1. new versions must have a different version number > 2. the version number is in the tarball name > > therefore: > > 3. uploading a new version is a non-destructive operation and will > not affect anyone downloading older versions. > > At least, that is my understanding. > > j. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080822/5ea7d039/attachment.htm From leather at cs.uu.nl Fri Aug 22 02:54:48 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Aug 22 02:53:37 2008 Subject: [Haskell-cafe] Libraries of standard QuickCheck properties In-Reply-To: <7ca3f0160808211501h24d27f84x59655a3ddf03b69b@mail.gmail.com> References: <3c6288ab0808211419y7bfe90a5o5040bf82e138ad9d@mail.gmail.com> <7ca3f0160808211501h24d27f84x59655a3ddf03b69b@mail.gmail.com> Message-ID: <3c6288ab0808212354t5f53bafep1e16fbdd629887b5@mail.gmail.com> > > This is an interesting thought. Has there been any work towards > collecting > > properties written with QuickCheck (or similar) into a reusable chunk of > > some form? > > Yes, it's in development, called 'checkers'. code.haskell.org/checkers > Great! I especially like the Char generators. This would be nice to eventually have in the Haskell Platform after some general usage and maturity. It would be even better if 'checkers' used QuickCheck 2 when it is released (apparently last week in September [1]). That version works nicely with HUnit. [1] http://thread.gmane.org/gmane.comp.lang.haskell.general/16380 Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080822/b23d826c/attachment.htm From ketil at malde.org Fri Aug 22 04:57:04 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Aug 22 04:54:54 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: (Christopher Lane Hinson's message of "Thu\, 21 Aug 2008 20\:52\:00 -0400 \(EDT\)") References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> Message-ID: <87bpzl1l7j.fsf@malde.org> Christopher Lane Hinson writes: > Having a debianized cabal-install would be the biggest win in my book. If > there were an unofficial debianized mirror of hackage, I probably wouldn't > use it anyway. I might. I generally want to use newer versions of development stuff (i.e. Haskell libraries etc) than is available in official repos. Were there an unofficial, cutting edge repo at hackage, I could just add it to my sources.list, instead of compiling stuff myself from darcs repos or hackage tarballs. Even if we only get a handful of users, this would be an important testing stage for packages before submitting them to official Debian (and Ubuntu) repos. I'm all for it. -k -- If I haven't seen further, it is by standing in the footprints of giants From magnus at therning.org Fri Aug 22 05:13:30 2008 From: magnus at therning.org (Magnus Therning) Date: Fri Aug 22 05:12:18 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <0ttzdd4yxi.wl%bremner@pivot.cs.unb.ca> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> <0ttzdd4yxi.wl%bremner@pivot.cs.unb.ca> Message-ID: On Fri, Aug 22, 2008 at 2:32 AM, David Bremner wrote: > > At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), > Christopher Lane Hinson wrote: >> >> I'm not a DD, but I think uploading ~500 hackage packages to debian would >> be a bit of a no-no. Debian packages are expected to have active >> maintainers both upstream and on the debian side, and to build without a >> hitch on ten different architectures, or they don't make it into stable >> and the DD responsible gets whined at. > > Fundamentally I think Lane is correct, but it is worth noting that the > debian perl team maintains 938 CPAN modules. The effort involved is > not trivial, but the number of consistently active people involved is > not so huge (maybe 5 core people, and lots of people who are > interested in one or two packages). > > Now, there are only 1217 registered installs of ghc6 on debian, > compared to 74000+ perl installs (essentially everyone installs perl I > guess), so it is not clear that the critical mass exists for a debian > perl style team. To add to this I suspect that there are more people involved in the perl team than there even are DDs with ghc6 installed, but maybe I'm just being negative. Maybe the time is ripe for a Debian haskell team? I know the idea has been floated before on the Debian Haskell list but I don't think it's ever gained any momentum. /M From dons at galois.com Fri Aug 22 05:50:21 2008 From: dons at galois.com (Don Stewart) Date: Fri Aug 22 05:49:07 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: References: <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> <0ttzdd4yxi.wl%bremner@pivot.cs.unb.ca> Message-ID: <20080822095021.GB13834@scytale.galois.com> magnus: > On Fri, Aug 22, 2008 at 2:32 AM, David Bremner wrote: > > > > At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), > > Christopher Lane Hinson wrote: > >> > >> I'm not a DD, but I think uploading ~500 hackage packages to debian would > >> be a bit of a no-no. Debian packages are expected to have active > >> maintainers both upstream and on the debian side, and to build without a > >> hitch on ten different architectures, or they don't make it into stable > >> and the DD responsible gets whined at. > > > > Fundamentally I think Lane is correct, but it is worth noting that the > > debian perl team maintains 938 CPAN modules. The effort involved is > > not trivial, but the number of consistently active people involved is > > not so huge (maybe 5 core people, and lots of people who are > > interested in one or two packages). > > > > Now, there are only 1217 registered installs of ghc6 on debian, > > compared to 74000+ perl installs (essentially everyone installs perl I > > guess), so it is not clear that the critical mass exists for a debian > > perl style team. > > To add to this I suspect that there are more people involved in the > perl team than there even are DDs with ghc6 installed, but maybe I'm > just being negative. Maybe the time is ripe for a Debian haskell > team? I know the idea has been floated before on the Debian Haskell > list but I don't think it's ever gained any momentum. And good integration will only serve to increase the number of users, and build further critical mass. It has to start somewhere people! -- Don From ndmitchell at gmail.com Fri Aug 22 06:49:12 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Aug 22 06:48:00 2008 Subject: [Haskell-cafe] question about uploads of code contribution In-Reply-To: <5ae4f2ba0808212229h774ad9c3sb7c1517f0e3b38e2@mail.gmail.com> References: <5ae4f2ba0808212229h774ad9c3sb7c1517f0e3b38e2@mail.gmail.com> Message-ID: <404396ef0808220349j632f69cey41cb1b937d8f2bf@mail.gmail.com> Hi > 1) I want to upload a version with minor changes. Should I send out an > "announcement"? How minor are the changes? I tend to annouce no more than once every few months for a package, and when its popular or has new features people might be interested in (I am assuming this is a package you wrote in the first place and uploaded last time? If not, you probably shouldn't be uploading it) Thanks Neil From sethg at ropine.com Fri Aug 22 10:06:18 2008 From: sethg at ropine.com (Seth Gordon) Date: Fri Aug 22 10:05:08 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <87bpzl1l7j.fsf@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> <87bpzl1l7j.fsf@malde.org> Message-ID: <48AEC7DA.5010704@ropine.com> Ketil Malde wrote: > Christopher Lane Hinson writes: > >> Having a debianized cabal-install would be the biggest win in my book. If >> there were an unofficial debianized mirror of hackage, I probably wouldn't >> use it anyway. > > I might. I would. (I run Ubuntu at home, Debian on my personal mail/web server, and Debian at work.) I'd rather have all my software maintained by the distro's package-management system (if I can do it and still have access to the most recent versions). One of the things that made me tear my hair out when I first tried to learn Plone was that my Plone book, the Plone website, and Ubuntu all recommended different systems for installing Plone and all its dependencies, and IIRC they defaulted to different versions as well. From bos at serpentine.com Fri Aug 22 14:10:19 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Aug 22 14:09:07 2008 Subject: [Haskell-cafe] "Real World Haskell" hits a milestone Message-ID: Hi, all - I'm proud to report that John, Don and I have finished the draft manuscript of our book. It is now available online in its entirety. For more details, see here: http://www.realworldhaskell.org/blog/2008/08/22/our-writing-is-now-complete/ We expect the final book to be published around the beginning of November, and to weigh in at about 700 pages. Thank you to everyone in the Haskell community who has encouraged and assisted us so far! From bulat.ziganshin at gmail.com Fri Aug 22 15:15:15 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Aug 22 15:15:37 2008 Subject: [Haskell-cafe] "Real World Haskell" hits a milestone In-Reply-To: References: Message-ID: <1203592654.20080822231515@gmail.com> Hello Bryan, Friday, August 22, 2008, 10:10:19 PM, you wrote: > I'm proud to report that John, Don and I have finished the draft > manuscript of our book. It is now available online in its entirety. many thanks! the book is huge step toward in spreading Haskell to rule the world :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From hthiel.char at zonnet.nl Fri Aug 22 16:11:24 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Fri Aug 22 16:11:02 2008 Subject: [Haskell-cafe] ANN: First Monad Tutorial of the Season Message-ID: <1219435884.380.10.camel@localhost.localdomain> Hello All, I'm proud to announce the first monad tutorial of the new season. It's under the Wiki permissive licence, but the web page has some clip art, so 'The Greenhorn's Guide to becoming a Monad Cowboy' is on http://www.muitovar.com/monad/moncow.xhtml Best Regards, Hans van Thiel From dmehrtash at gmail.com Fri Aug 22 16:46:46 2008 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Fri Aug 22 16:45:33 2008 Subject: [Haskell-cafe] "Real World Haskell" hits a milestone In-Reply-To: <1203592654.20080822231515@gmail.com> References: <1203592654.20080822231515@gmail.com> Message-ID: Are the book's sample code available for download? Thanks Daryoush On Fri, Aug 22, 2008 at 12:15 PM, Bulat Ziganshin wrote: > Hello Bryan, > > Friday, August 22, 2008, 10:10:19 PM, you wrote: > > I'm proud to report that John, Don and I have finished the draft > > manuscript of our book. It is now available online in its entirety. > > many thanks! the book is huge step toward in spreading Haskell to rule > the world :) > > > -- > 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/20080822/fde0a6c5/attachment.htm From nomeata at debian.org Fri Aug 22 17:16:11 2008 From: nomeata at debian.org (Joachim Breitner) Date: Fri Aug 22 17:15:01 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> <0ttzdd4yxi.wl%bremner@pivot.cs.unb.ca> Message-ID: <1219432470.3425.35.camel@otto.ehbuehl.net> Hi, Am Freitag, den 22.08.2008, 10:13 +0100 schrieb Magnus Therning: > On Fri, Aug 22, 2008 at 2:32 AM, David Bremner wrote: > > At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), > > Christopher Lane Hinson wrote: > >> I'm not a DD, but I think uploading ~500 hackage packages to debian would > >> be a bit of a no-no. Debian packages are expected to have active > >> maintainers both upstream and on the debian side, and to build without a > >> hitch on ten different architectures, or they don't make it into stable > >> and the DD responsible gets whined at. > > > > Fundamentally I think Lane is correct, but it is worth noting that the > > debian perl team maintains 938 CPAN modules. The effort involved is > > not trivial, but the number of consistently active people involved is > > not so huge (maybe 5 core people, and lots of people who are > > interested in one or two packages). > > > > Now, there are only 1217 registered installs of ghc6 on debian, > > compared to 74000+ perl installs (essentially everyone installs perl I > > guess), so it is not clear that the critical mass exists for a debian > > perl style team. > > To add to this I suspect that there are more people involved in the > perl team than there even are DDs with ghc6 installed, but maybe I'm > just being negative. Maybe the time is ripe for a Debian haskell > team? I know the idea has been floated before on the Debian Haskell > list but I don't think it's ever gained any momentum. I had it floated to the debian-haskell mailing list once, but as you said, there were not much responses. The Debian Perl Group (which was started by me some years ago) is indeed a good example for good library package maintenance. What made it successful was, in my opinion, people with constant devotion (that was not me :-)) and a faible for developing tools for the team. Have a look at http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi and you see how it was possible to maintain this number of packages with just a few people. Incidentally, a few days ago Ian Lynagh was asking if someone wants to take over his haskell packages, so if there were a group to be formed, it could start with all the base packages. OTOH, this leaves the question open of who will maintain the compiler itself. Of course, this is a totally different thing than maintaining cabalized libraries and so far, no one has stepped up to give it a shot. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080822/a816063e/attachment.bin From dons at galois.com Fri Aug 22 17:21:35 2008 From: dons at galois.com (Don Stewart) Date: Fri Aug 22 17:20:31 2008 Subject: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages) In-Reply-To: <1219432470.3425.35.camel@otto.ehbuehl.net> References: <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <20080821171008.GA21733@piperka.net> <20080821181955.GD10969@scytale.galois.com> <0ttzdd4yxi.wl%bremner@pivot.cs.unb.ca> <1219432470.3425.35.camel@otto.ehbuehl.net> Message-ID: <20080822212135.GC22501@scytale.galois.com> nomeata: > Hi, > > Am Freitag, den 22.08.2008, 10:13 +0100 schrieb Magnus Therning: > > On Fri, Aug 22, 2008 at 2:32 AM, David Bremner wrote: > > > At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), > > > Christopher Lane Hinson wrote: > > >> I'm not a DD, but I think uploading ~500 hackage packages to debian would > > >> be a bit of a no-no. Debian packages are expected to have active > > >> maintainers both upstream and on the debian side, and to build without a > > >> hitch on ten different architectures, or they don't make it into stable > > >> and the DD responsible gets whined at. > > > > > > Fundamentally I think Lane is correct, but it is worth noting that the > > > debian perl team maintains 938 CPAN modules. The effort involved is > > > not trivial, but the number of consistently active people involved is > > > not so huge (maybe 5 core people, and lots of people who are > > > interested in one or two packages). > > > > > > Now, there are only 1217 registered installs of ghc6 on debian, > > > compared to 74000+ perl installs (essentially everyone installs perl I > > > guess), so it is not clear that the critical mass exists for a debian > > > perl style team. > > > > To add to this I suspect that there are more people involved in the > > perl team than there even are DDs with ghc6 installed, but maybe I'm > > just being negative. Maybe the time is ripe for a Debian haskell > > team? I know the idea has been floated before on the Debian Haskell > > list but I don't think it's ever gained any momentum. > > I had it floated to the debian-haskell mailing list once, but as you > said, there were not much responses. > > The Debian Perl Group (which was started by me some years ago) is indeed > a good example for good library package maintenance. What made it > successful was, in my opinion, people with constant devotion (that was > not me :-)) and a faible for developing tools for the team. Have a look > at http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi and you see > how it was possible to maintain this number of packages with just a few > people. > > Incidentally, a few days ago Ian Lynagh was asking if someone wants to > take over his haskell packages, so if there were a group to be formed, > it could start with all the base packages. > > OTOH, this leaves the question open of who will maintain the compiler > itself. Of course, this is a totally different thing than maintaining > cabalized libraries and so far, no one has stepped up to give it a shot. Yes, the key is to find a motivated Debian maintainer who can build a coalition around them. -- Don From vigalchin at gmail.com Fri Aug 22 17:48:23 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Aug 22 17:47:12 2008 Subject: [Haskell-cafe] multi-core programming in Haskell Message-ID: <5ae4f2ba0808221448t14b791e1u7d69665f80edd548@mail.gmail.com> Hello, With pure side of the Haskell house, there is hope that the generated code could automagically scale as more cores are added yes? It seems that it is on the stateful monadic side of the house in an appplication that it is the programmer responsibility to design the software so that it scales across increasing cores? (I am assuming that things like "par" construct are monadic). On Monday, I am starting a several month project with a company. Alledgely some of the code will be written in Python. I would like engage the manager in a discussion about multi-core "enabling" the code now when we design and implement not later as an afterthought. Seems like a gnarly subject given current "state-of-the-art" software tools. Ideas?! Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080822/c19cddd5/attachment.htm From ndmitchell at gmail.com Fri Aug 22 18:21:02 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Aug 22 18:19:48 2008 Subject: [Haskell-cafe] multi-core programming in Haskell In-Reply-To: <5ae4f2ba0808221448t14b791e1u7d69665f80edd548@mail.gmail.com> References: <5ae4f2ba0808221448t14b791e1u7d69665f80edd548@mail.gmail.com> Message-ID: <404396ef0808221521h66f367b7u7ef13eec2badd706@mail.gmail.com> Hi > across increasing cores? (I am assuming that things like "par" construct are > monadic). http://haskell.org/hoogle/?q=par Control.Parallel par :: a -> b -> b No monads :-) Thanks Neil From alexander.dunlap at gmail.com Fri Aug 22 21:58:22 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Fri Aug 22 21:57:08 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: References: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> Message-ID: <57526e770808221858l199ba273n11f3d3eac3579a8c@mail.gmail.com> On Wed, Aug 20, 2008 at 1:49 AM, Henning Thielemann wrote: > > On Mon, 18 Aug 2008, ajb@spamcop.net wrote: > >> G'day all. >> >> Quoting Bjorn Buckwalter : >> >>> I'd store the constants in a data structure along the lines of: >>> >>>> data AstroData a = AstroData >>>> { mu_Earth :: GravitationalParameter a >>>> , leapSeconds :: LeapSecondTable >>>> } >>> >>> I would like to know if there is any consensus on what is the best way >>> to make such a data structure accessible in pure functions. Passing it >>> explicitly would be a mess. >> >> In this situation, there isn't necessarily any shame in using a >> top-level unsafePerformIO as long as it's well-hidden: >> >> module AstroData (AstroData(..), globalAstroData) where >> >> data AstroData = AstroData Int > > But here my argument about playing around with the Planck constant becomes > relevant. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > You can always change how you unsafePerformIO the data, though. If you want to set Planck's constant to 42 (or whatever), just change the unsafePerformIO $ to unsafePerformIO $ return 42. Alex From tom.davie at gmail.com Sat Aug 23 06:36:49 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Aug 23 06:35:38 2008 Subject: [Haskell-cafe] Haskell Speed Myth Message-ID: Lo guys, I thought you'd like to know about this result. I've been playing with the debian language shootout programs under OS X, looking at how fast Haskell code is compared to C on OS X, rather than linux. Interestingly, Haskell comes out rather better on OS X than it did on Linux. Here's my results (times in seconds): C Haskell Relative speed Inverse Binary Trees 6.842 1.228 0.179479684302835 5.57166123778502 Fannkuch 5.683 15.73 2.76790427591061 0.361284170375079 Mandelbrot 1.183 2.287 1.93322062552832 0.517271534761697 nbody 10.275 16.219 1.57849148418491 0.633516246377705 nsieve 0.167 0.253 1.51497005988024 0.660079051383399 nsieve-bits 0.471 0.713 1.51380042462845 0.660589060308555 partial sums 1.047 1.313 1.25405921680993 0.797410510281797 pidigits 1.238 1.4 1.13085621970921 0.884285714285714 recursive 1.554 3.594 2.31274131274131 0.432387312186978 spectral-norm 27.939 19.165 0.685958695729983 1.45781372293243 threadring 91.284 1.389 0.0152162481924543 65.719222462203 ------------------------------------------------------------------------- Averages 1.35333620432893 0.738914688605306 Some notes: Hardware: 2Ghz Core2Duo, enough ram to not worry about paging Some programs are not included, this is because the C code produced compile errors. The Haskell code appears to be portable in *all* cases. The average slowdown for running Haskell is only 1.3 times on OS X! That's pretty damn good. I'm sure some people will say "yeh, but you have to optimise your code pretty heavily to get that kind of result". Interestingly, the programs that have the biggest speed advantage over C here are also the most "na?vely" written ones. The thing that seems to make C slower is the implementation of malloc in OS X. This has a couple of implications, first, if apple replaced the malloc library, it would probably push the result back to the 1.7 times slower we see under Linux. Second, Fannkuch can probably be optimised differently for Haskell to look even better -- at the moment, the haskell code actually uses malloc! Finally, that threading example... WOW! 65 times faster, and the code is *really* simple. The C on the other hand is a massive mess. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080823/bcf3db95/attachment.htm From waldmann at imn.htwk-leipzig.de Sat Aug 23 08:41:08 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Aug 23 08:39:54 2008 Subject: [Haskell-cafe] Re: [Haskell] Another First course in Haskell In-Reply-To: <20080822035347.GA23256@cse.iitk.ac.in> References: <20080822035347.GA23256@cse.iitk.ac.in> Message-ID: <48B00564.1030001@imn.htwk-leipzig.de> Piyush P Kurur wrote: ( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 ) > I am planing a haskell based functional programming course. > It is supposed to be a first course and I intend to show how > real world applications can be built quite easily in haskell. > Any feed back is really welcome. Is it a first course in programming, or in functional programming? Either way, I recommend focus on "data" and then "class/instance", i.e. have the students use algebraic data types right from the beginning (*). Another idea for teaching is to introduce the language by having the students use standard libraries (e.g. Data.Map), also right from the start. So they are forced to read type signatures etc. (**) (*) that's the main problem I see with Hutton's book http://www.cs.nott.ac.uk/~gmh/book.html : it has "Declaring types and classes" as chapter 10 (of 13 total). I think that's way off - and it leaves readers (students) with the impression that declarative programming basically deals with (functions on) lists. This may have been true in the 70s/80s (LISP, Prolog), but it certainly shouldn't be true today. Recall the proverb "Get your data structures correct first, and the rest of the program will write itself." (David Jones, cited in John Bentley: More Programming Pearls) I think this is independent of language and paradigm. (**) again, Hutton's book does not contain a single "import" declaration in the programming examples (did not check fully, but got this impression while browsing). Yes , Data.* is not Standard Haskell(98) and that's probably why he avoided it but the result diametrically contradicts everyday programming experience where the typical application program (in any language) is just some glue between library functions that do 90 percent of the actual work. Sure, a student programmer must be able to write a stand-alone bubble/quick/mergesort but it is equally (if not more) important that he knows how to (1) find and (2) call a sorting routine in any given programming environment. (So, have your students use http://www.haskell.org/hoogle/ ) Best regards, J.W. From bos at serpentine.com Sat Aug 23 08:45:07 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Aug 23 08:43:53 2008 Subject: [Haskell-cafe] "Real World Haskell" hits a milestone In-Reply-To: References: <1203592654.20080822231515@gmail.com> Message-ID: On Fri, Aug 22, 2008 at 1:46 PM, Daryoush Mehrtash wrote: > Are the book's sample code available for download? Not yet. From chris at eidhof.nl Sat Aug 23 10:55:23 2008 From: chris at eidhof.nl (Chris Eidhof) Date: Sat Aug 23 10:54:10 2008 Subject: [Haskell-cafe] Type family fun Message-ID: <40E6D26F-C084-47DA-B511-5F53EAF0EDE6@eidhof.nl> Hey all, I was playing around with type families, and I have a strange problem. Suppose we have an alternative to an Either datatype: > data (:|:) a b = Inl a | Inr b and a class Ix: > class Ix i where > type IxMap i :: * -> * > empty :: IxMap i [Int] Now I want to give an instance for (a :|: b): > instance (Ix l, Ix r) => Ix (l :|: r) where > type IxMap (l :|: r) = BiApp (IxMap l) (IxMap r) > empty = BiApp empty empty BiApp is defined as following: > data BiApp a b c = BiApp (a c) (b c) However, it looks like the recursive calls to empty can't be unified, I get the following error message: Couldn't match expected type `IxMap l' against inferred type `IxMap i' Expected type: IxMap (l :|: r) [Int] Inferred type: BiApp (IxMap i) (IxMap i1) [Int] In the expression: BiApp empty empty In the definition of `empty': empty = BiApp empty empty In the inferred type, there should be IxMap l instead of IxMap i, does anybody know what I'm doing wrong? Thanks, -chris From lrpalmer at gmail.com Sat Aug 23 14:01:30 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Aug 23 14:00:15 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: References: Message-ID: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> 2008/8/23 Thomas Davie : > Finally, that threading example... WOW! 65 times faster, and the code is > *really* simple. The C on the other hand is a massive mess. I've been wondering about this, but I can't check because I don't have a multi core cpu. I've heard GHC's single threaded runtime is very very good. What are the results for the threading example when compiled with -threaded and run with at least +RTS -N2? Luke From alexander.dunlap at gmail.com Sat Aug 23 14:46:50 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Aug 23 14:45:34 2008 Subject: [Haskell-cafe] Type family fun In-Reply-To: <40E6D26F-C084-47DA-B511-5F53EAF0EDE6@eidhof.nl> References: <40E6D26F-C084-47DA-B511-5F53EAF0EDE6@eidhof.nl> Message-ID: <57526e770808231146j23a43532hc992d98750fb06bd@mail.gmail.com> On Sat, Aug 23, 2008 at 7:55 AM, Chris Eidhof wrote: > Hey all, > > I was playing around with type families, and I have a strange problem. > > Suppose we have an alternative to an Either datatype: > >> data (:|:) a b = Inl a | Inr b > > and a class Ix: > >> class Ix i where >> type IxMap i :: * -> * >> empty :: IxMap i [Int] > > Now I want to give an instance for (a :|: b): > >> instance (Ix l, Ix r) => Ix (l :|: r) where >> type IxMap (l :|: r) = BiApp (IxMap l) (IxMap r) >> empty = BiApp empty empty > > BiApp is defined as following: > >> data BiApp a b c = BiApp (a c) (b c) > > However, it looks like the recursive calls to empty can't be unified, I get > the following error message: > > Couldn't match expected type `IxMap l' > against inferred type `IxMap i' > Expected type: IxMap (l :|: r) [Int] > Inferred type: BiApp (IxMap i) (IxMap i1) [Int] > In the expression: BiApp empty empty > In the definition of `empty': empty = BiApp empty empty > > In the inferred type, there should be IxMap l instead of IxMap i, does > anybody know what I'm doing wrong? > > Thanks, > > -chris > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Hi, I'm not very familiar with type families, but shouldn't BiApp be defined as > data BiApp a b c = BiApp (a b) (a c) since you're applying it as BiApp (IxMap l) (IxMap r)? Alex From tom.davie at gmail.com Sat Aug 23 15:19:55 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Aug 23 15:18:43 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> Message-ID: On 23 Aug 2008, at 20:01, Luke Palmer wrote: > 2008/8/23 Thomas Davie : >> Finally, that threading example... WOW! 65 times faster, and the >> code is >> *really* simple. The C on the other hand is a massive mess. > > I've been wondering about this, but I can't check because I don't have > a multi core cpu. I've heard GHC's single threaded runtime is very > very good. What are the results for the threading example when > compiled with -threaded and run with at least +RTS -N2? That's really interesting -- I just tried this. Compiling not using -threaded: 1.289 seconds Compiling using -threaded, but not running with -N2: 3.403 seconds Compiling using -threaded, and using -N2: 55.072 seconds Wow! Haskell's runtime really is a *lot* better than trying to use operating system threads. I wonder if there's a point at which it becomes better to use both CPUs, or if the overhead of using OS threads for that problem is just too high. Bob From tom.davie at gmail.com Sat Aug 23 16:16:12 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Aug 23 16:15:00 2008 Subject: [Haskell-cafe] Haskell Propeganda Message-ID: Today I made an interesting discovery. We all know the benefits of a strong type system, and often tout it as a major advantage of using Haskell. The discovery I made, was that C programmer don't realise the implications of that, as this comment highlights: http://games.slashdot.org/comments.pl?sid=654821&cid=24716845 Apparently, no one realises that a SEGFAULT is a type error, just not a very helpful one. Bob From dons at galois.com Sat Aug 23 16:18:18 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 23 16:29:56 2008 Subject: [Haskell-cafe] Re: [Haskell] Another First course in Haskell In-Reply-To: <48B00564.1030001@imn.htwk-leipzig.de> References: <20080822035347.GA23256@cse.iitk.ac.in> <48B00564.1030001@imn.htwk-leipzig.de> Message-ID: <20080823201818.GA2965@scytale.galois.com> It seems to me we should condense this thread into a series of new entires on the "Haskell in Education" page? People seem to be doing new courses, and new kinds of courses, in Haskell, so reflecting that online is a good idea. http://haskell.org/haskellwiki/Haskell_in_education waldmann: > Piyush P Kurur wrote: > > ( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 ) > > > I am planing a haskell based functional programming course. > > It is supposed to be a first course and I intend to show how > > real world applications can be built quite easily in haskell. > > > Any feed back is really welcome. > > Is it a first course in programming, or in functional programming? From ziman at centrum.sk Sat Aug 23 16:36:57 2008 From: ziman at centrum.sk (Matus Tejiscak) Date: Sat Aug 23 16:35:41 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: Message-ID: <1219523817.7218.12.camel@idefix.localdomain> On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote: > Today I made an interesting discovery. > > We all know the benefits of a strong type system, and often tout it as > a major advantage of using Haskell. The discovery I made, was that C > programmer don't realise the implications of that, as this comment > highlights: > > http://games.slashdot.org/comments.pl?sid=654821&cid=24716845 > > Apparently, no one realises that a SEGFAULT is a type error, just not > a very helpful one. > > Bob Type errors are useful because they emerge at compile time and prevent you from compiling (and running) a broken program. A segfault is a runtime error and as such provides no such guide -- it may or may not arise and you don't know something's wrong until sigsegv kills your app, screws all your data, crashes the airplane etc. (without the possibility to tell whether/when it will happen). Matus From tom.davie at gmail.com Sat Aug 23 17:06:30 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Aug 23 17:05:17 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <1219523817.7218.12.camel@idefix.localdomain> References: <1219523817.7218.12.camel@idefix.localdomain> Message-ID: <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> On 23 Aug 2008, at 22:36, Matus Tejiscak wrote: > On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote: >> Today I made an interesting discovery. >> >> We all know the benefits of a strong type system, and often tout it >> as >> a major advantage of using Haskell. The discovery I made, was that C >> programmer don't realise the implications of that, as this comment >> highlights: >> >> http://games.slashdot.org/comments.pl?sid=654821&cid=24716845 >> >> Apparently, no one realises that a SEGFAULT is a type error, just not >> a very helpful one. >> >> Bob > > Type errors are useful because they emerge at compile time and prevent > you from compiling (and running) a broken program. A segfault is a > runtime error and as such provides no such guide -- it may or may not > arise and you don't know something's wrong until sigsegv kills your > app, > screws all your data, crashes the airplane etc. (without the > possibility > to tell whether/when it will happen). I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying "we can give you programs that never segfault", instead of "we have a strong type system". Bob From newsham at lava.net Sat Aug 23 17:10:55 2008 From: newsham at lava.net (Tim Newsham) Date: Sat Aug 23 17:09:49 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> Message-ID: > I guess I didn't express my point very clearly... That C programmers > apparently don't realise that a type system that's sound will give them > something -- i.e. their programmer won't ever segfault. I wonder when we try > to advertise Haskell if we should be saying "we can give you programs that > never segfault", instead of "we have a strong type system". That would be overpromissing. You can definitely get segfaults in Haskell. The obvious example being http://codepad.org/Q8cgS6x8 but many less contrived and more unexpected examples arise naturally (unfortunately). By the way, the Java camp has (correctly) been touting this argument for quite a while. > Bob Tim Newsham http://www.thenewsh.com/~newsham/ From dons at galois.com Sat Aug 23 17:13:50 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 23 17:12:32 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> Message-ID: <20080823211350.GB2965@scytale.galois.com> newsham: > >I guess I didn't express my point very clearly... That C programmers > >apparently don't realise that a type system that's sound will give them > >something -- i.e. their programmer won't ever segfault. I wonder when we > >try to advertise Haskell if we should be saying "we can give you programs > >that never segfault", instead of "we have a strong type system". > > That would be overpromissing. You can definitely get segfaults in > Haskell. The obvious example being > > http://codepad.org/Q8cgS6x8 > > but many less contrived and more unexpected examples arise naturally > (unfortunately). > > By the way, the Java camp has (correctly) been touting this argument for > quite a while. And it is just a property of strong typing, not static typing. The Pythonists would happily make the same remark. We promise both safety and efficiency. -- Don From tom.davie at gmail.com Sat Aug 23 17:17:31 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Aug 23 17:16:18 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> Message-ID: On 23 Aug 2008, at 23:10, Tim Newsham wrote: >> I guess I didn't express my point very clearly... That C >> programmers apparently don't realise that a type system that's >> sound will give them something -- i.e. their programmer won't ever >> segfault. I wonder when we try to advertise Haskell if we should >> be saying "we can give you programs that never segfault", instead >> of "we have a strong type system". > > That would be overpromissing. You can definitely get segfaults in > Haskell. The obvious example being > > http://codepad.org/Q8cgS6x8 > > but many less contrived and more unexpected examples arise naturally > (unfortunately). > > By the way, the Java camp has (correctly) been touting this argument > for quite a while. I'd be interested to see your other examples -- because that error is not happening in Haskell! You can't argue that Haskell doesn't give you no segfaults, because you can embed a C segfault within Haskell. Bob From maarten.hazewinkel at gmail.com Sat Aug 23 17:22:21 2008 From: maarten.hazewinkel at gmail.com (Maarten Hazewinkel) Date: Sat Aug 23 17:21:08 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> Message-ID: <4303DC96-FF64-446A-AA96-999B9EEE0F59@mac.com> On 23 Aug 2008, at 23:10, Tim Newsham wrote: >> I guess I didn't express my point very clearly... That C >> programmers apparently don't realise that a type system that's >> sound will give them something -- i.e. their programmer won't ever >> segfault. I wonder when we try to advertise Haskell if we should >> be saying "we can give you programs that never segfault", instead >> of "we have a strong type system". > > By the way, the Java camp has (correctly) been touting this argument > for quite a while. As a day-time java programmer, I can say from experience that sometimes (100% pure) Java programs DO segfault. I've had it happen to me, and while you can justifiably say it's an error in the JVM somehow triggered by your program behaviour/timing, that doesn't help you very much at the time. Maarten Hazewinkel From cmb21 at kent.ac.uk Sat Aug 23 17:29:19 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Sat Aug 23 17:29:01 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> Message-ID: > I guess I didn't express my point very clearly... That C programmers > apparently don't realise that a type system that's sound will give > them something -- i.e. their programmer won't ever segfault. I wonder > when we try to advertise Haskell if we should be saying "we can give > you programs that never segfault", instead of "we have a strong type > system". I'm sure this point is already made somewhere. But I certainly agree that it's a useful point to make to C programmers who are interested in Haskell. I wonder whether seg faults are the true analogue to errors such as "error: head empty list." or pattern match errors. Not that I'm saying we should be encouraging such errors in our Haskell programs. Chris. From newsham at lava.net Sat Aug 23 17:37:30 2008 From: newsham at lava.net (Tim Newsham) Date: Sat Aug 23 17:36:16 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <4303DC96-FF64-446A-AA96-999B9EEE0F59@mac.com> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <4303DC96-FF64-446A-AA96-999B9EEE0F59@mac.com> Message-ID: > As a day-time java programmer, I can say from experience that sometimes (100% > pure) Java programs DO segfault. > > I've had it happen to me, and while you can justifiably say it's an error in > the JVM somehow triggered by your program behaviour/timing, that doesn't help > you very much at the time. Sure, and just as java has its runtime, so does Haskell. Runtimes are software and prone to being buggy. Runtimes are often written in languages like C where bugs can lead to memory corruption, crashes and arbitrary malicious code execution. Here's a small example that I unfortunately ran across today: ghc -c wxdirect/src/CompileClassTypes.hs -o dist/wxdirect/CompileClassTypes.o -idist/wxdirect -odir dist/wxdirect -hidir dist/wxdirect -package parsec -cpp -package time Segmentation fault (core dumped) :( > Maarten Hazewinkel The point being that Haskell, while having a theorem checker that helps programmers find and avoid bugs and while being based on semi-formal concepts that can be used to avoid some pitfalls, is still no silver bullet against any and all crashes. Promising would-be converts that it is will only lead to disappointment. Tim Newsham http://www.thenewsh.com/~newsham/ From daniel.is.fischer at web.de Sat Aug 23 18:15:57 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Aug 23 18:12:38 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: Message-ID: <200808240015.57217.daniel.is.fischer@web.de> Am Samstag, 23. August 2008 23:17 schrieb Thomas Davie: > > I'd be interested to see your other examples -- because that error is > not happening in Haskell! You can't argue that Haskell doesn't give > you no segfaults, because you can embed a C segfault within Haskell. > > Bob Use ST(U)Arrays, and use unsafeWrite because you do the indexchecking yourself. Then be stupid and confuse two bounds so that you actually write beyond the array bounds. I've had that happen _once_. But if you explicitly say you want it unsafe, you're prepared for it :) Daniel From gtener at gmail.com Sat Aug 23 18:34:55 2008 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Sat Aug 23 18:33:39 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> Message-ID: <220e47b40808231534w1aa9980br9ce4e7335272f9b7@mail.gmail.com> Recently I wrote computation intensive program that could easily utilize both cores. However, there was overhead just from compiling with -threaded and making some forkIO's. Still, the overhead was not larger than 50% and with 4 cores I would probably still get the results faster - I didn't experience an order of magnitude slowdown. Perhaps it's the issue with OS X. On Sat, Aug 23, 2008 at 21:19, Thomas Davie wrote: > > On 23 Aug 2008, at 20:01, Luke Palmer wrote: > >> 2008/8/23 Thomas Davie : >>> >>> Finally, that threading example... WOW! 65 times faster, and the code is >>> *really* simple. The C on the other hand is a massive mess. >> >> I've been wondering about this, but I can't check because I don't have >> a multi core cpu. I've heard GHC's single threaded runtime is very >> very good. What are the results for the threading example when >> compiled with -threaded and run with at least +RTS -N2? > > That's really interesting -- I just tried this. > > Compiling not using -threaded: 1.289 seconds > Compiling using -threaded, but not running with -N2: 3.403 seconds > Compiling using -threaded, and using -N2: 55.072 seconds > > Wow! Haskell's runtime really is a *lot* better than trying to use > operating system threads. I wonder if there's a point at which it becomes > better to use both CPUs, or if the overhead of using OS threads for that > problem is just too high. > > Bob > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From gtener at gmail.com Sat Aug 23 18:49:34 2008 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Sat Aug 23 18:48:18 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <200808240015.57217.daniel.is.fischer@web.de> References: <200808240015.57217.daniel.is.fischer@web.de> Message-ID: <220e47b40808231549h6bdbabefy9d0efa2dd4b6c864@mail.gmail.com> You can get nice exception (but not segfault) when trying to fire this code: > {-# OPTIONS_GHC -XRecursiveDo #-} > > module Main where > > import Control.Concurrent > import Control.Monad.Fix > > loopChan :: IO (Chan ()) > loopChan = mdo chan <- dupChan chan > return chan > > main = do > c <- loopChan > writeChan c () You just can't use a duplicate of a channel to create itself. > Prelude> :l loop_channel.hs > [1 of 1] Compiling LC ( loop_channel.hs, interpreted ) > Ok, modules loaded: LC. > *LC> :type loopChan > loopChan :: IO (Chan ()) > *LC> c <- loopChan > *** Exception: <> Still I don't think it's a bug, but merely complicated way to crash your program. Haskell is great, but it also has many pitfalls, just like any other language. Christopher Skrz?tnicki On Sun, Aug 24, 2008 at 00:15, Daniel Fischer wrote: > Am Samstag, 23. August 2008 23:17 schrieb Thomas Davie: >> >> I'd be interested to see your other examples -- because that error is >> not happening in Haskell! You can't argue that Haskell doesn't give >> you no segfaults, because you can embed a C segfault within Haskell. >> >> Bob > > Use ST(U)Arrays, and use unsafeWrite because you do the indexchecking > yourself. Then be stupid and confuse two bounds so that you actually write > beyond the array bounds. > I've had that happen _once_. > But if you explicitly say you want it unsafe, you're prepared for it :) > > Daniel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery at ece.cmu.edu Sat Aug 23 19:26:44 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Aug 23 19:25:30 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <220e47b40808231534w1aa9980br9ce4e7335272f9b7@mail.gmail.com> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <220e47b40808231534w1aa9980br9ce4e7335272f9b7@mail.gmail.com> Message-ID: <80679C7C-1C0F-4905-BC7D-6A94EF736066@ece.cmu.edu> On 2008 Aug 23, at 18:34, Krzysztof Skrz?tnicki wrote: > Recently I wrote computation intensive program that could easily > utilize both cores. However, there was overhead just from compiling > with -threaded and making some forkIO's. Still, the overhead was not > larger than 50% and with 4 cores I would probably still get the > results faster - I didn't experience an order of magnitude slowdown. > Perhaps it's the issue with OS X. All that's needed for multicore to be a *lot* slower is doing it wrong. Make sure you're forcing the right things in the right places, or you could quietly be building up thunks on both cores that will cause lots of cross-core signaling or locking. And, well, make sure the generated code isn't stupid. Quite possibly the PPC code is an order of magnitude worse than the better-tested Intel code. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From nielsadb at gmail.com Sat Aug 23 19:29:18 2008 From: nielsadb at gmail.com (Niels Aan de Brugh) Date: Sat Aug 23 19:28:08 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: Message-ID: <48B09D4E.1080609@gmail.com> Thomas Davie wrote: > http://games.slashdot.org/comments.pl?sid=654821&cid=24716845 > > Apparently, no one realises that a SEGFAULT is a type error, just not > a very helpful one. Right, so here's an action plan for a clueless C-programmer: - Recompile program in debug mode. - Start application in debugger. - See where error happens, check out call-stack, check out local variables and possibly some heap. - Fix problem, repeat action plan if needed. Here's an error the Haskell run-time system might throw: *** Exception: Prelude.head: empty list (or whatever) So now what? Action plan = []. Perhaps Hat could help here? Or the new GHCi debugger? As a professional C++ programmer and a free-time fan of Haskell I'm not sure e.g. Visual Studio and the Haskell debugging tools I've just mentioned are on the same level of usability. Be careful with your propaganda before you have the real-world tools to back it up. Regards, Niels, devil's advocate, never idealistic. From allbery at ece.cmu.edu Sat Aug 23 19:30:32 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Aug 23 19:29:19 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> Message-ID: <2096648F-620F-4C97-975D-AD367D9014D0@ece.cmu.edu> On 2008 Aug 23, at 17:29, C.M.Brown wrote: > I wonder whether seg faults are the true analogue to errors such as > "error: head empty list." or pattern match errors. Not really; while laziness does introduce a certain amount of "spooky action at a difference" to such errors, it's not nearly as bad as the memory corruption (due to effective type mismatches) that often leads to the segfault. -- 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 brianchina60221 at gmail.com Sat Aug 23 19:41:52 2008 From: brianchina60221 at gmail.com (brian) Date: Sat Aug 23 19:40:36 2008 Subject: [Haskell-cafe] parsec, hGetContents Message-ID: <22f6a8f70808231641j6351fa81hf673559364591046@mail.gmail.com> I'm writing an NNTP client API. When I connect with connectTo, I get a Handle 'h'. I immediately hGetContents h to get a string 'c' that I hope contains all the data the server will ever send. I put h and c in a data Connection and pass it to the functions that send or receive. I send a command and receive a response. The response might look like "200 OK\r\n". Parsec parses c. No problem. But if I send another command and receive another response, parsec parses the same string because (I think) I haven't trimmed the part I parsed on the previous command. Maybe c looks like "200 OK\r\n200 second thing\r\n". So I was thinking I need to parse and return the unparsed part so that the next parse will work. Parsec has a getInput that returns the unparsed part, but it blocks if there is no more to parse. That is, after I parse "200 OK\r\n", if I ask parsec for the "rest", it blocks because there isn't any "rest" yet. How should I be doing this? Before people suggest I hGetLine and parse that, I don't like hGetLine for this because 1) it assumes '\n' signifies the end of a line, whereas in my case the protocol specifies "\r\n" and 2) if the "line" doesn't have an ending, I can't tell it from what hGetLine returns. That is, hGetLine on a handle having "abc\n" returns the same thing as on a handle having "abc". Also, if I can parse c directly, I can write parsers (especially those for multiline respones) much more naturally than I can if I have to get lines separately. Thanks very much for any help. From brianchina60221 at gmail.com Sat Aug 23 19:43:55 2008 From: brianchina60221 at gmail.com (brian) Date: Sat Aug 23 19:42:39 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B09D4E.1080609@gmail.com> References: <48B09D4E.1080609@gmail.com> Message-ID: <22f6a8f70808231643j44b50b27j7ea20eb139229755@mail.gmail.com> On Sat, Aug 23, 2008 at 6:29 PM, Niels Aan de Brugh wrote: > > Here's an error the Haskell run-time system might throw: > *** Exception: Prelude.head: empty list > (or whatever) > > So now what? Action plan = []. http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14 From nielsadb at gmail.com Sat Aug 23 20:22:49 2008 From: nielsadb at gmail.com (Niels Aan de Brugh) Date: Sat Aug 23 20:21:39 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <22f6a8f70808231643j44b50b27j7ea20eb139229755@mail.gmail.com> References: <48B09D4E.1080609@gmail.com> <22f6a8f70808231643j44b50b27j7ea20eb139229755@mail.gmail.com> Message-ID: <48B0A9D9.3040406@gmail.com> brian wrote: >> Here's an error the Haskell run-time system might throw: >> *** Exception: Prelude.head: empty list >> (or whatever) >> >> So now what? Action plan = []. >> > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14 > Thank you for the URL, but I'm aware of the work in GHC(i). As I've mentioned in my previous e-mail the tooling is definitely not on-par with something like Visual Studio, or perhaps Eclipse for Java. And by not on-par I mean it's miles away from the same level. Microsoft engineers have surely done a good job in the Visual Studio 2005 debugger and unfortunately Microsoft Research doesn't have the same resources to work on the Haskell debugger. Referring to the OP: if Haskell is ever to become a mainstream language (and I certainly hope it will!) an IDE and integrated visual debugger is a must. Until then, perhaps is better to be conservative when kicking on the C language, it has survived worse storms (and not because it's the better language). Regards, Niels From thomas.dubuisson at gmail.com Sat Aug 23 23:44:25 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sat Aug 23 20:43:28 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B0A9D9.3040406@gmail.com> References: <48B09D4E.1080609@gmail.com> <22f6a8f70808231643j44b50b27j7ea20eb139229755@mail.gmail.com> <48B0A9D9.3040406@gmail.com> Message-ID: <1219549465.3996.12.camel@myhost> wrt head [], Niels said: > So now what? Action plan = [] Oh come now. Between ghci, hpc, and manual analysis I've never hit a Haskell error and thrown my hands up, "I can't go any further, I'm at a complete loss!" Also it helps that I run into this extremely rarely - I have a larger habit of hidding black holes :-( Niels said: > Thank you for the URL, but I'm aware of the work in GHC(i). It might interest you to know some people actually use hpc for debugging with reasonble success - it colors the unevaluated sections and this can be very helpful in determining where a program stopped and threw an exception. If you have your eyes on the future you should see Dana Xu's work on static contract checking (check out her Cambridge page). Cheers, Tom From ajb at spamcop.net Sat Aug 23 21:03:36 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sat Aug 23 21:02:22 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <20080823211350.GB2965@scytale.galois.com> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <20080823211350.GB2965@scytale.galois.com> Message-ID: <20080823210336.kan9rwvbk8kcwssk-nwo@webmail.spamcop.net> G'day all. Quoting Don Stewart : > We promise both safety and efficiency. We also provide (though don't promise) modularity, robustness and correctness, which is not something that Java gives you out of the box. Cheers, Andrew Bromage From thomas.dubuisson at gmail.com Sun Aug 24 00:31:30 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sat Aug 23 21:30:27 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> Message-ID: <1219552290.3996.33.camel@myhost> > That's really interesting -- I just tried this. > > Compiling not using -threaded: 1.289 seconds > Compiling using -threaded, but not running with -N2: 3.403 seconds > Compiling using -threaded, and using -N2: 55.072 seconds > I was hoping to see a relative improvement when introducting an opportunity parallelism in the program, so I made a version with two MVars filled at the start. This didn't work out though - perhaps some performance stands to be gained by improving the GHC scheduler wrt cpu / OS thread affinity for the Haskell threads? For the curious: -O2: 7.3 seconds (CPU: 99.7% user) -O2 -threaded: 11.5 seconds (CPU: 95% user, 5% system) -O2 -threaded ... +RTS -N2: killed after 3 minutes (CPUs: 15% user, 20% system) Thats quite a lot of CPU time going to the system. Specs: Linux 2.6.26 (Arch) x86_64 Intel Core 2 Duo 2.5GHz SOURCE Notice the threads still exist when a value of 0 is seen - this is OK as the other value will be terminating ringsize threads earlier and this thread will never be needed again. import Control.Monad import Control.Concurrent import System.Environment ring = 503 new l i = do r <- newEmptyMVar forkIO (thread i l r) return r thread :: Int -> MVar Int -> MVar Int -> IO () thread i l r = go where go = do m <- takeMVar l when (m == 1) (print i) putMVar r $! m - 1 when (m > 0) go main = do val <- return . read . head =<< getArgs a <- newMVar val b <- newMVar val y <- foldM new a [2..ring] forkIO $ thread (ring+1) y b z <- foldM new b [(ring + 2)..(ring + ring)] thread 1 z a From trebla at vex.net Sat Aug 23 23:04:14 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat Aug 23 23:02:57 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: Message-ID: <48B0CFAE.4070206@vex.net> "Dear friends, Haskell prevents more errors and earlier." This is honest, relevant, good advocacy. "Dear friends, segfaults are type errors, not logical errors." Why would you indulge in this? It's even less relevant than bikeshed colours. On the bright side, only mainstream communities have enough people with enough time for such word-plays; this indicates that Haskell is mainstream. From vigalchin at gmail.com Sat Aug 23 23:54:30 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Aug 23 23:53:13 2008 Subject: [Haskell-cafe] multi-core programming in Haskell In-Reply-To: References: <5ae4f2ba0808221448t14b791e1u7d69665f80edd548@mail.gmail.com> Message-ID: <5ae4f2ba0808232054m129af82bs953ea8252cfae268@mail.gmail.com> Thank you Murray. My post was not so clear .... I was referring to "automatic" parellelization vs "manual" parallelization. By "automatic" I mean the programmer doesn't have to indicate where to parallelize ... instead the compiler decides how to parallize! Vasili On Sat, Aug 23, 2008 at 12:58 AM, Murray Gross wrote: > > > Vasili: > > Each "par" "sparks" a new thread, which is then queued for execution. At > appropriate points, the threads are distributed to available (free) > processors (cores). The result is that parallelization scales automatically > with the number of available processors. Take a look at the GPH site for > papers that will provide more information on how parallel (and distributed) > Haskell does things. > > Best, > > Murray Gross, > Brooklyn College > > > > > > On Fri, 22 Aug 2008, Galchin, Vasili wrote: > > Hello, >> >> With pure side of the Haskell house, there is hope that the generated >> code could automagically scale as more cores are added yes? It seems that >> it >> is on the stateful monadic side of the house in an appplication that it is >> the programmer responsibility to design the software so that it scales >> across increasing cores? (I am assuming that things like "par" construct >> are >> monadic). On Monday, I am starting a several month project with a company. >> Alledgely some of the code will be written in Python. I would like engage >> the manager in a discussion about multi-core "enabling" the code now when >> we >> design and implement not later as an afterthought. Seems like a gnarly >> subject given current "state-of-the-art" software tools. Ideas?! >> >> Regards, Vasili >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080823/2843707e/attachment.htm From gwern0 at gmail.com Sun Aug 24 01:01:30 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Aug 24 01:00:47 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B09D4E.1080609@gmail.com> References: <48B09D4E.1080609@gmail.com> Message-ID: <20080824050130.GA28982@craft> On 2008.08.24 01:29:18 +0200, Niels Aan de Brugh scribbled 1.0K characters: > Thomas Davie wrote: >> http://games.slashdot.org/comments.pl?sid=654821&cid=24716845 >> >> Apparently, no one realises that a SEGFAULT is a type error, just not >> a very helpful one. > Right, so here's an action plan for a clueless C-programmer: > - Recompile program in debug mode. > - Start application in debugger. > - See where error happens, check out call-stack, check out local > variables and possibly some heap. > - Fix problem, repeat action plan if needed. > > Here's an error the Haskell run-time system might throw: > *** Exception: Prelude.head: empty list > (or whatever) > > So now what? Action plan = []. Perhaps Hat could help here? Or the new > GHCi debugger? As a professional C++ programmer and a free-time fan of > Haskell I'm not sure e.g. Visual Studio and the Haskell debugging tools > I've just mentioned are on the same level of usability. > > Be careful with your propaganda before you have the real-world tools to > back it up. > > Regards, > Niels, devil's advocate, never idealistic. What do I do? In the very rare case that it isn't immediately obvious where the head is coming from, I pull out the interlude library: . 2 or 3 lines later, I run the binary and find out the answer. -- gwern CESID Security Delta d DUVDEVAN SRI composition data-haven SONANGOL World -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080824/588ed555/attachment.bin From lemming at henning-thielemann.de Sun Aug 24 03:55:14 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Aug 24 03:54:01 2008 Subject: [Haskell-cafe] Lines of code metrics In-Reply-To: <48ADC28E.8010201@imn.htwk-leipzig.de> References: <48ADC28E.8010201@imn.htwk-leipzig.de> Message-ID: On Thu, 21 Aug 2008, Johannes Waldmann wrote: > NB: My private set of Haskell metrics: > * lines of code (per declaration) (should be <= 5) > * number of declarations (per module) (should be <= 5 as well :-) > * number of usages of Int, String, List, IO (should be <= 0 :-) :-) * number of usages of unsafePerformIO, unsafeInterleaveIO, use of Ptr or IO at all These would be nice metrics for me to decide, whether I want to download a package from Hackage. From tom.davie at gmail.com Sun Aug 24 04:00:04 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sun Aug 24 03:58:51 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B0CFAE.4070206@vex.net> References: <48B0CFAE.4070206@vex.net> Message-ID: On 24 Aug 2008, at 05:04, Albert Y. C. Lai wrote: > "Dear friends, Haskell prevents more errors and earlier." This is > honest, relevant, good advocacy. > > "Dear friends, segfaults are type errors, not logical errors." Why > would you indulge in this? It's even less relevant than bikeshed > colours. Is it? when I write C I spend a lot of my time sat in gdb trying to figure out where the error that the Haskell type system would have caught for me is. This is *very* relevant, it's right at the bottom line of whether I'm more productive in Haskell or in C. Bob From lemming at henning-thielemann.de Sun Aug 24 04:09:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Aug 24 04:08:53 2008 Subject: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether? In-Reply-To: <57526e770808221858l199ba273n11f3d3eac3579a8c@mail.gmail.com> References: <8b2a1a960808180724k1881b4dfr40e5d1da5128f06e@mail.gmail.com> <20080818225450.luxidshioog04sg0-nwo@webmail.spamcop.net> <57526e770808221858l199ba273n11f3d3eac3579a8c@mail.gmail.com> Message-ID: On Fri, 22 Aug 2008, Alexander Dunlap wrote: > You can always change how you unsafePerformIO the data, though. If you > want to set Planck's constant to 42 (or whatever), just change the > unsafePerformIO $ to unsafePerformIO $ return 42. you can't change it at runtime From tom.davie at gmail.com Sun Aug 24 04:29:50 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sun Aug 24 04:28:36 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <80679C7C-1C0F-4905-BC7D-6A94EF736066@ece.cmu.edu> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <220e47b40808231534w1aa9980br9ce4e7335272f9b7@mail.gmail.com> <80679C7C-1C0F-4905-BC7D-6A94EF736066@ece.cmu.edu> Message-ID: On 24 Aug 2008, at 01:26, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 23, at 18:34, Krzysztof Skrz?tnicki wrote: >> Recently I wrote computation intensive program that could easily >> utilize both cores. However, there was overhead just from compiling >> with -threaded and making some forkIO's. Still, the overhead was not >> larger than 50% and with 4 cores I would probably still get the >> results faster - I didn't experience an order of magnitude slowdown. >> Perhaps it's the issue with OS X. > > > All that's needed for multicore to be a *lot* slower is doing it > wrong. Make sure you're forcing the right things in the right > places, or you could quietly be building up thunks on both cores > that will cause lots of cross-core signaling or locking. And, well, > make sure the generated code isn't stupid. Quite possibly the PPC > code is an order of magnitude worse than the better-tested Intel code. Except that the test was running on a Core2Duo, and it runs very fast when ghc does the threading on one core. My personal guess is that to do it properly threaded requires *lots* of kernel boundary crosses to do the locking etc on OS X (being a nearly-micro-kernel). The test program was almost 100% made up of thread locking code. Bob From johan.tibell at gmail.com Sun Aug 24 04:31:48 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun Aug 24 04:30:30 2008 Subject: [Haskell-cafe] ANN: benchpress 0.2.1 In-Reply-To: References: <90889fe70808182349i55ae1067rd42055811df8ffb9@mail.gmail.com> Message-ID: <90889fe70808240131n3fffd1c5y171bc6e6e1e689a9@mail.gmail.com> On Tue, Aug 19, 2008 at 9:37 AM, Bas van Dijk wrote: > On Tue, Aug 19, 2008 at 8:49 AM, Johan Tibell wrote: >> benchpress is a micro-benchmark library that produces statistics such >> as min, mean, standard deviation, median, and max execution time. It >> also computes execution time percentiles. > > Nice, I'm certainty going to use this. Thanks! > > It would be even nicer if you could also measure the elapsed CPU time > (using System.CPUTime.getCPUTime). Than the measurement is not > influenced by time spent in other processes and IO time. Available in 0.2.2 on Hackage. Cheers, Johan From tom.davie at gmail.com Sun Aug 24 04:31:52 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sun Aug 24 04:30:41 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <1219552290.3996.33.camel@myhost> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <1219552290.3996.33.camel@myhost> Message-ID: <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> On 24 Aug 2008, at 06:31, Thomas M. DuBuisson wrote: > >> That's really interesting -- I just tried this. >> >> Compiling not using -threaded: 1.289 seconds >> Compiling using -threaded, but not running with -N2: 3.403 seconds >> Compiling using -threaded, and using -N2: 55.072 seconds >> > > I was hoping to see a relative improvement when introducting an > opportunity parallelism in the program, so I made a version with two > MVars filled at the start. This didn't work out though - perhaps some > performance stands to be gained by improving the GHC scheduler wrt > cpu / > OS thread affinity for the Haskell threads? > > For the curious: > > -O2: 7.3 seconds (CPU: 99.7% user) > -O2 -threaded: 11.5 seconds (CPU: 95% user, 5% system) > -O2 -threaded ... +RTS -N2: killed after 3 minutes (CPUs: 15% user, > 20% > system) > > Thats quite a lot of CPU time going to the system. > > Specs: > Linux 2.6.26 (Arch) x86_64 > Intel Core 2 Duo 2.5GHz Hmm thanks, that's interesting -- I was think it was probably caused by OS X, but it appears to happen on Linux too. Could you try running the old code too, and see if you experience the order of magnitude slowdown too? Bob From stefan at cs.uu.nl Sun Aug 24 04:44:59 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Aug 24 04:43:42 2008 Subject: [Haskell-cafe] Type family fun In-Reply-To: <40E6D26F-C084-47DA-B511-5F53EAF0EDE6@eidhof.nl> References: <40E6D26F-C084-47DA-B511-5F53EAF0EDE6@eidhof.nl> Message-ID: Chris, > In the inferred type, there should be IxMap l instead of IxMap i, > does anybody know what I'm doing wrong? Your calls to empty are just ambiguous. Let's say I want to get a hold of an empty map for A :|: B for some types A and B. And let's say that you've instance for A hanging around that specifies type IxMap A = C. Now our call to empty for A :|: B delegates to empty to get the left map. Clearly you expect it to call to the instance for A, but any type D with IxMap D = C would do. Does that make sense? Cheers, Stefan On Aug 23, 2008, at 4:55 PM, Chris Eidhof wrote: > Hey all, > > I was playing around with type families, and I have a strange problem. > > Suppose we have an alternative to an Either datatype: > > > data (:|:) a b = Inl a | Inr b > > and a class Ix: > > > class Ix i where > > type IxMap i :: * -> * > > empty :: IxMap i [Int] > > Now I want to give an instance for (a :|: b): > > > instance (Ix l, Ix r) => Ix (l :|: r) where > > type IxMap (l :|: r) = BiApp (IxMap l) (IxMap r) > > empty = BiApp empty empty > > BiApp is defined as following: > > > data BiApp a b c = BiApp (a c) (b c) > > However, it looks like the recursive calls to empty can't be > unified, I get the following error message: > > Couldn't match expected type `IxMap l' > against inferred type `IxMap i' > Expected type: IxMap (l :|: r) [Int] > Inferred type: BiApp (IxMap i) (IxMap i1) [Int] > In the expression: BiApp empty empty > In the definition of `empty': empty = BiApp empty empty > > In the inferred type, there should be IxMap l instead of IxMap i, > does anybody know what I'm doing wrong? > > Thanks, > > -chris > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ryani.spam at gmail.com Sun Aug 24 05:14:23 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Aug 24 05:13:05 2008 Subject: [Haskell-cafe] Type family fun In-Reply-To: References: <40E6D26F-C084-47DA-B511-5F53EAF0EDE6@eidhof.nl> Message-ID: <2f9b2d30808240214l6e70eb33n915e5f6f5a9856b6@mail.gmail.com> On Sun, Aug 24, 2008 at 1:44 AM, Stefan Holdermans wrote: ] Your calls to empty are just ambiguous. Now, you are probably wondering how to fix it. Here's two different solutions: > {-# LANGUAGE TypeFamilies, TypeOperators, ScopedTypeVariables #-} > module Ix where The first solution still uses type families, but "empty" takes a parameter so that the which instance to use can be chosen unambiguously. > class Ix i where > type IxMap i :: * -> * > empty :: i -> IxMap i [Int] > -- uses ScopedTypeVariables > instance (Ix left, Ix right) => Ix (left :|: right) where > type IxMap (left :|: right) = BiApp (IxMap left) (IxMap right) > empty _ = BiApp (empty (undefined :: left)) (empty (undefined :: right)) The second solution uses data families instead, because no such ambiguity can exist. > class IxD i where > data IxMapD i :: * -> * > emptyD :: IxMapD i [Int] > instance (IxD left, IxD right) => IxD (left :|: right) where > data IxMapD (left :|: right) a = BiAppD (IxMapD left a) (IxMapD right a) > emptyD = BiAppD emptyD emptyD -- ryan > data (:|:) a b = Inl a | Inr b > data BiApp a b c = BiApp (a c) (b c) From cmb21 at kent.ac.uk Sun Aug 24 07:16:09 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Sun Aug 24 07:15:58 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <2096648F-620F-4C97-975D-AD367D9014D0@ece.cmu.edu> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <2096648F-620F-4C97-975D-AD367D9014D0@ece.cmu.edu> Message-ID: Hi Brandon, OK, so you're basically saying that segfaults can be eliminated with a strong type system, whereas pattern matching errors is the result of some dodgy laziness going on? I personally think such pattern matching errors are a weaknesss of the language; with possibly no solutions to resolve. regards, Chris. On Sat, 23 Aug 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 23, at 17:29, C.M.Brown wrote: > > I wonder whether seg faults are the true analogue to errors such as > > "error: head empty list." or pattern match errors. > > Not really; while laziness does introduce a certain amount of "spooky > action at a difference" to such errors, it's not nearly as bad as the > memory corruption (due to effective type mismatches) that often leads > to the segfault. > > From andrewcoppin at btinternet.com Sun Aug 24 09:25:08 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Aug 24 09:23:45 2008 Subject: [Haskell-cafe] Why doesn't this work? Message-ID: <48B16134.7040307@btinternet.com> colour_grid :: (Particle -> IO ()) -> Grid ph -> IO () colour_grid fn g = sequence_ $ runST $ do ps <- grid_coords g mapM (\pix -> do particle <- read_grid g pix return $ fn particle ) ps When I attempt to run this, GHCi just gives me a very cryptic type checker error. I can't figure out what's wrong here. As far as I can tell, this should run... From alfonso.acosta at gmail.com Sun Aug 24 09:36:52 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sun Aug 24 09:35:34 2008 Subject: [Haskell-cafe] Why doesn't this work? In-Reply-To: <48B16134.7040307@btinternet.com> References: <48B16134.7040307@btinternet.com> Message-ID: <6a7c66fc0808240636x2dfb2511ieddb89a6a3a51776@mail.gmail.com> I haven't tried to run the code, but my first bet is that, due to the rank-2 polymorphism of ST, you should use parenthesis instead of $ in the case of runST. On Sun, Aug 24, 2008 at 3:25 PM, Andrew Coppin wrote: > colour_grid :: (Particle -> IO ()) -> Grid ph -> IO () > colour_grid fn g = sequence_ $ runST $ do > ps <- grid_coords g > > mapM > (\pix -> do > particle <- read_grid g pix > return $ fn particle > ) > ps > > When I attempt to run this, GHCi just gives me a very cryptic type checker > error. I can't figure out what's wrong here. As far as I can tell, this > should run... > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jvlask at hotmail.com Sun Aug 24 09:51:34 2008 From: jvlask at hotmail.com (john lask) Date: Sun Aug 24 09:50:17 2008 Subject: [Haskell-cafe] (no subject) Message-ID: Hi has anyone had any success in running a recent version of hs-plugins on a windows platform. I refer to this post to the haskell list in December last year. The current version of hs-plugins dosn't appear to work either. Same problem ... http://www.haskell.org/pipermail/haskell/2007-December/020043.html jvl _________________________________________________________________ Meet singles near you. Try ninemsn dating now! http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=WL_TAGLINE&_m=EXT From thomas.dubuisson at gmail.com Sun Aug 24 14:03:30 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sun Aug 24 11:02:26 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <1219552290.3996.33.camel@myhost> <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> Message-ID: <1219601010.3996.49.camel@myhost> > Hmm thanks, that's interesting -- I was think it was probably caused > by OS X, but it appears to happen on Linux too. Could you try running > the old code too, and see if you experience the order of magnitude > slowdown too? The original program on my Linux 2.6.26 Core2 Duo: [tom@myhost Test]$ time ./tr-threaded 1000000 37 real 0m0.635s user 0m0.530s sys 0m0.077s [tom@myhost Test]$ time ./tr-nothreaded 1000000 37 real 0m0.352s user 0m0.350s sys 0m0.000s [tom@myhost Test]$ time ./tr-threaded 1000000 +RTS -N2 37 real 0m13.954s user 0m4.333s sys 0m5.736s -------------------------- Seeing as there still was obviously not enough computation to justify the OS threads in my last example, I made a test where it hashed a 32 byte string (show . md5 . encode $ val): [tom@myhost Test]$ time ./threadring-nothreaded 1000000 50 552 real 0m1.408s user 0m1.323s sys 0m0.083s [tom@myhost Test]$ time ./threadring-threaded 1000000 50 552 real 0m1.948s user 0m1.807s sys 0m0.143s [tom@myhost Test]$ time ./threadring-threaded 1000000 +RTS -N2 552 50 real 0m1.663s user 0m1.427s sys 0m0.237s [tom@myhost Test]$ --------------------------- Seeing as this still doesn't beat the old RTS, I decided to increase the per unit work a little more. This code will hash 10KB every time the token is passed / decremented. [tom@myhost Test]$ time ./threadring-nothreaded 100000 (308,77851ef5e9e781c04850a7df9cc855d2) real 2m56.453s user 2m55.399s sys 0m0.457s [tom@myhost Test]$ time ./threadring-threaded 100000 (308,77851ef5e9e781c04850a7df9cc855d2) real 3m6.430s user 3m5.868s sys 0m0.460s [tom@myhost Test]$ time ./threadring-threaded 100000 +RTS -N2 (810,77851ef5e9e781c04850a7df9cc855d2) (308,77851ef5e9e781c04850a7df9cc855d2) real 1m55.616s user 2m47.982s sys 0m3.586s * Yes, I notice its exiting before the output gets printed a couple times, oh well. ------------------------- REFLECTION Yay, the multicore version pays off when the workload is non-trivial. CPU utilization is still rather low for the -N2 case (70%). I think the Haskell threads have an affinity for certain OS threads (and thus a CPU). Perhaps it results in a CPU having both tokens of work and the other having none? From thomas.dubuisson at gmail.com Sun Aug 24 14:17:50 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sun Aug 24 11:16:47 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <2096648F-620F-4C97-975D-AD367D9014D0@ece.cmu.edu> Message-ID: <1219601870.3996.52.camel@myhost> Chris said: > I personally think such pattern matching errors > are a weaknesss of the language; with possibly no solutions to resolve. Actually tools like CATCH [1] exist and could be incorporated into a compiler to eliminate this problem. [1] http://www-users.cs.york.ac.uk/~ndm/catch/ From gale at sefer.org Sun Aug 24 11:21:33 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Aug 24 11:20:15 2008 Subject: [Haskell-cafe] Why doesn't this work? In-Reply-To: <6a7c66fc0808240636x2dfb2511ieddb89a6a3a51776@mail.gmail.com> References: <48B16134.7040307@btinternet.com> <6a7c66fc0808240636x2dfb2511ieddb89a6a3a51776@mail.gmail.com> Message-ID: <2608b8a80808240821s6f282f27ue4953c81c6d6980@mail.gmail.com> Alfonso Acosta wrote: > I haven't tried to run the code, but my first bet is that, due to the > rank-2 polymorphism of ST, you should use parenthesis instead of $ in > the case of runST. Perhaps if Andrew is using an old compiler. That is no longer a problem in recent versions of GHC. A more basic issue is that fn is in the IO monad, but its use inside the mapM will need it to be in the ST monad. Regards, Yitz From daniel.is.fischer at web.de Sun Aug 24 11:36:18 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Aug 24 11:32:59 2008 Subject: [Haskell-cafe] Why doesn't this work? In-Reply-To: <2608b8a80808240821s6f282f27ue4953c81c6d6980@mail.gmail.com> References: <48B16134.7040307@btinternet.com> <6a7c66fc0808240636x2dfb2511ieddb89a6a3a51776@mail.gmail.com> <2608b8a80808240821s6f282f27ue4953c81c6d6980@mail.gmail.com> Message-ID: <200808241736.18610.daniel.is.fischer@web.de> Am Sonntag, 24. August 2008 17:21 schrieb Yitzchak Gale: > Alfonso Acosta wrote: > > I haven't tried to run the code, but my first bet is that, due to the > > rank-2 polymorphism of ST, you should use parenthesis instead of $ in > > the case of runST. > > Perhaps if Andrew is using an old compiler. > That is no longer a problem in recent versions of GHC. > > A more basic issue is that fn is in the IO monad, > but its use inside the mapM will need it to be in the ST > monad. No, return (fn particle) :: ST s (IO ()) , so that's fine. Indeed, filling in a few dummies, the code compiles with the 6.8 branch. > > Regards, > Yitz Cheers, Daniel From haskell at randomhacks.net Sun Aug 24 11:41:04 2008 From: haskell at randomhacks.net (Eric Kidd) Date: Sun Aug 24 11:39:45 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats Message-ID: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> Greetings, Haskell folks! I'm working on a toy program for drum synthesis. This has lead me to explore the various sound-related libraries in Hackage. Along the way, I've learned several things: 1. There's a lot of Haskell sound libraries, but no agreement on how to represent buffers of audio data. 2. Some of the most useful sound libraries aren't listed in Hackage's "Sound" section, including HCodecs, SDL-mixer and hogg. 3. The Haskell OpenAL bindings are great, but ALUT has been removed from MacOS 10.5. Of course, a pure-Haskell version of ALUT would be pretty easy to write, and it could be used as a fallback. 4. '[[a]]' is _not_ a good representation for multi-channel audio data. Manipulating even 10 seconds of audio is noticeably slow. 5. HCodecs is probably the best library for reading WAVE files. It uses 'DiffUArray Int a' to represent audio data, and not '[[a]]'. It also supports MIDI and SoundFont, which is quite handy. 6. YampaSynth looks really cool, and it might be possible to turn it into a reusable MIDI synthesizer library for use with HCodecs. This would be extremely useful: it would provide a basis for all kinds of crazy MIDI-based programming in Haskell. At the end of this e-mail, you can find a list of Haskell sound libraries and their supported audio formats. What would the ideal Haskell sound API look like? Personally, I would love to see: a. Something like HCodecs's Data.Audio as the basic sound format. Data.Audio is an array-based API, and it supports converting between a wide range of common sample formats. I don't know how fast this is, but it already exists, and it's used by YampaSynth. b. OpenAL for sound playback, with a portable version of ALUT. This may require writing a pure-Haskell version of ALUT. c. Utility functions to convert Data.Audio to OpenAL.AL.Buffer. d. An easy-to-use API for audio processing. It might be possible to start with something like Jack's 'mainMono' and 'mainStereo' functions, which map a function over an audio stream. Other nice-to-have features might include: e. A standard MIDI format, based on either the HCodecs package or the midi package. (HCodecs is used by YampaSynth, and the midi package is used by alsa-midi.) f. A modular version of YampaSynth which can convert MIDI data structures into Data.Audio values. It looks like Haskell could be a really sweet audio programming environment with just a bit of integration work. What do folks think? Are there other libraries I should look at more closely? Other features that should be included in an ideal audio API? Thank you for your advice and feedback! Cheers, Eric Haskell audio libraries Reading and writing sound files: HCodecs: (Audible a) => DiffUArray Int a hsndfile: MArray with Float and Double HSoundFile: [[Double]] ALUT: OpenAL.AL.Buffer WAVE: [[Int32]] Playing sounds: OpenAL: Ptr UInt8, Ptr Int16, 1-N channels SDL-mixer: ForeignPtr ChunkStruct, ForeignPtr MusicStruct Sound processing libraries: dsp: Array a, [a] jack: Operates via mapping functions mainMono :: (CFloat -> IO CFloat) -> IO () mainStereo :: ((CFloat, CFloat) -> IO (CFloat, CFloat)) -> IO () MIDI-based: HCodecs: Reads and writes MIDI files midi: Reads and writes MIDI files alsa-midi: Uses midi library YampaSynth: Stand-alone program Special-purpose APIs only (FFIs, etc.): hCsound: CsoundPtr hsc3: UGen No public sound-buffer API: hbeat: The relevant source files are missing! hogg: Very low-level API for Ogg internals only libmpd: No sound buffer API sonic-visualizer: No sound buffer API truelevel: Stand-alone program (uses WAVE) wavconvert: Stand-alone program From allbery at ece.cmu.edu Sun Aug 24 11:45:48 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 24 11:44:32 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <48B0CFAE.4070206@vex.net> Message-ID: On 2008 Aug 24, at 4:00, Thomas Davie wrote: > On 24 Aug 2008, at 05:04, Albert Y. C. Lai wrote: > >> "Dear friends, Haskell prevents more errors and earlier." This is >> honest, relevant, good advocacy. >> >> "Dear friends, segfaults are type errors, not logical errors." Why >> would you indulge in this? It's even less relevant than bikeshed >> colours. > > Is it? when I write C I spend a lot of my time sat in gdb trying to > figure out where the error that the Haskell type system would have > caught for me is. This is *very* relevant, it's right at the bottom > line of whether I'm more productive in Haskell or in C. Half agreed. It occurs to me this morning that one thing to consider is that often segfaults are more the kind of error that requires dependent types, which are Hard in Haskell (see, for example, the discussion of type-level naturals elsethread). (Example: copying a buffer when the copy length is negative due to a bug.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Sun Aug 24 11:52:21 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 24 11:51:05 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <2096648F-620F-4C97-975D-AD367D9014D0@ece.cmu.edu> Message-ID: <85B28C82-BF39-4598-BE96-95E46039689B@ece.cmu.edu> On 2008 Aug 24, at 7:16, C.M.Brown wrote: > OK, so you're basically saying that segfaults can be eliminated with a > strong type system, whereas pattern matching errors is the result of > some Not really, no. A sufficiently strong type system will eliminate segfaults (modulo bugs in the language runtime or erroneous use of the FFI); but Haskell arguably doesn't have a sufficiently strong type system: pattern match errors being the symptom, and the resolution is dependent types. That said, what I was really saying was that a pattern match error still gives you more information, and more easily, than a segfault: if it's not something trivial like dereferencing a null pointer, the segfault may well be in completely unrelated code because the erroneous operation (for example) overran a buffer and corrupted unrelated data. Whereas with laziness, you may have to do some footwork to find the actual error (ghci's debugger helps, as does hpc as someone else mentioned upthread) but it's deterministic. -- 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 emax at chalmers.se Sun Aug 24 12:17:23 2008 From: emax at chalmers.se (Emil Axelsson) Date: Sun Aug 24 12:16:05 2008 Subject: [Haskell-cafe] Why doesn't this work? In-Reply-To: <48B16134.7040307@btinternet.com> References: <48B16134.7040307@btinternet.com> Message-ID: <48B18993.9010102@chalmers.se> BTW, this is a case where it may be more convenient to use forM: forM ps $ \pix -> do particle <- read_grid g pix return $ fn particle (untested...) forM is just another way of saying (flip mapM). / Emil Andrew Coppin skrev: > colour_grid :: (Particle -> IO ()) -> Grid ph -> IO () > colour_grid fn g = sequence_ $ runST $ do > ps <- grid_coords g > > mapM > (\pix -> do > particle <- read_grid g pix > return $ fn particle > ) > ps > > When I attempt to run this, GHCi just gives me a very cryptic type > checker error. I can't figure out what's wrong here. As far as I can > tell, this should run... > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From vanenkj at gmail.com Sun Aug 24 12:41:39 2008 From: vanenkj at gmail.com (John Van Enk) Date: Sun Aug 24 12:40:21 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> Message-ID: Eric, I'm hoping to publish my library in the next week here: darcs get http://code.haskell.org/portaudio/ It implements the Haskell bindings to the PortAudio library. This is the library behind Audacious. I *have not* implemented the callback model yet, but I plan to do that. Perhaps this will be something which is useful to you? On Sun, Aug 24, 2008 at 11:41 AM, Eric Kidd wrote: > Greetings, Haskell folks! > > I'm working on a toy program for drum synthesis. This has lead me to > explore the various sound-related libraries in Hackage. Along the way, > I've learned several things: > > 1. There's a lot of Haskell sound libraries, but no agreement on how > to represent buffers of audio data. > 2. Some of the most useful sound libraries aren't listed in Hackage's > "Sound" section, including HCodecs, SDL-mixer and hogg. > 3. The Haskell OpenAL bindings are great, but ALUT has been removed > from MacOS 10.5. Of course, a pure-Haskell version of ALUT would > be pretty easy to write, and it could be used as a fallback. > 4. '[[a]]' is _not_ a good representation for multi-channel audio > data. Manipulating even 10 seconds of audio is noticeably slow. > 5. HCodecs is probably the best library for reading WAVE files. It > uses 'DiffUArray Int a' to represent audio data, and not '[[a]]'. > It also supports MIDI and SoundFont, which is quite handy. > 6. YampaSynth looks really cool, and it might be possible to turn it > into a reusable MIDI synthesizer library for use with HCodecs. > This would be extremely useful: it would provide a basis for all > kinds of crazy MIDI-based programming in Haskell. > > At the end of this e-mail, you can find a list of Haskell sound > libraries and their supported audio formats. > > What would the ideal Haskell sound API look like? Personally, I would > love to see: > > a. Something like HCodecs's Data.Audio as the basic sound format. > Data.Audio is an array-based API, and it supports converting > between a wide range of common sample formats. I don't know how > fast this is, but it already exists, and it's used by YampaSynth. > b. OpenAL for sound playback, with a portable version of ALUT. This > may require writing a pure-Haskell version of ALUT. > c. Utility functions to convert Data.Audio to OpenAL.AL.Buffer. > d. An easy-to-use API for audio processing. It might be possible to > start with something like Jack's 'mainMono' and 'mainStereo' > functions, which map a function over an audio stream. > > Other nice-to-have features might include: > > e. A standard MIDI format, based on either the HCodecs package or the > midi package. (HCodecs is used by YampaSynth, and the midi package > is used by alsa-midi.) > f. A modular version of YampaSynth which can convert MIDI data > structures into Data.Audio values. > > It looks like Haskell could be a really sweet audio programming > environment with just a bit of integration work. What do folks think? > Are there other libraries I should look at more closely? Other features > that should be included in an ideal audio API? > > Thank you for your advice and feedback! > > Cheers, > Eric > > > Haskell audio libraries > > Reading and writing sound files: > HCodecs: (Audible a) => DiffUArray Int a > hsndfile: MArray with Float and Double > HSoundFile: [[Double]] > ALUT: OpenAL.AL.Buffer > WAVE: [[Int32]] > > Playing sounds: > OpenAL: Ptr UInt8, Ptr Int16, 1-N channels > SDL-mixer: ForeignPtr ChunkStruct, ForeignPtr MusicStruct > > Sound processing libraries: > dsp: Array a, [a] > jack: Operates via mapping functions > mainMono :: (CFloat -> IO CFloat) -> IO () > mainStereo :: ((CFloat, CFloat) -> IO (CFloat, CFloat)) -> IO () > > MIDI-based: > HCodecs: Reads and writes MIDI files > midi: Reads and writes MIDI files > alsa-midi: Uses midi library > YampaSynth: Stand-alone program > > Special-purpose APIs only (FFIs, etc.): > hCsound: CsoundPtr > hsc3: UGen > > No public sound-buffer API: > hbeat: The relevant source files are missing! > hogg: Very low-level API for Ogg internals only > libmpd: No sound buffer API > sonic-visualizer: No sound buffer API > truelevel: Stand-alone program (uses WAVE) > wavconvert: Stand-alone program > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080824/88406b83/attachment.htm From haskell at randomhacks.net Sun Aug 24 13:06:40 2008 From: haskell at randomhacks.net (Eric Kidd) Date: Sun Aug 24 13:05:22 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> Message-ID: <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> On Sun, Aug 24, 2008 at 12:41 PM, John Van Enk wrote: > It implements the Haskell bindings to the PortAudio library. This is the > library behind Audacious. I *have not* implemented the callback model yet, > but I plan to do that. > > Perhaps this will be something which is useful to you? Looks like a great binding! We actually use portaudio in callback mode at work, with reasonable success (from C++). One question: I notice that your writeStream function represents audio using '[[a]]'. writeStream :: (Storable a) => PaStream a -- ^ The output stream -> [[a]] -- ^ The samples to be played -> Int -- ^ Number of frames -> IO (Either String ErrorCode) -- ^ The return status of the write In my experiments, I've been somewhat unsatisfied with the performance of '[[a]]' as an audio format. Would you be interested in also supporting an array-based format for audio data? I'm currently converting my program to use HCodec's Data.Audio representation, which looks pretty promising. I don't know how it performs yet, but I'll let you know. Thank you for the pointer to your library! It will make an excellent addition to the available Haskell sound libraries. Cheers, Eric From gale at sefer.org Sun Aug 24 14:32:01 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Aug 24 14:30:42 2008 Subject: [Haskell-cafe] Why doesn't this work? In-Reply-To: <200808241736.18610.daniel.is.fischer@web.de> References: <48B16134.7040307@btinternet.com> <6a7c66fc0808240636x2dfb2511ieddb89a6a3a51776@mail.gmail.com> <2608b8a80808240821s6f282f27ue4953c81c6d6980@mail.gmail.com> <200808241736.18610.daniel.is.fischer@web.de> Message-ID: <2608b8a80808241132pc1e014v9627d9481062c449@mail.gmail.com> I wrote: >> A more basic issue is that fn is in the IO monad, >> but its use inside the mapM will need it to be in the ST >> monad. Daniel Fischer wrote: > No, > return (fn particle) :: ST s (IO ()) > , so that's fine. Ah, true. But I doubt that Andrew really meant to do the calculation in ST s (IO ()). > Indeed, filling in a few dummies, the code compiles > with the 6.8 branch. So then the only way to know why it didn't compile for Andrew is if we see more of the code. But that's only a technical issue. I hope that now Andrew has a better idea about what's wrong. If not - please let us know. Regards, Yitz From dons at galois.com Sun Aug 24 15:55:26 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 24 15:54:03 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> Message-ID: <20080824195526.GD7128@scytale.galois.com> haskell: > At the end of this e-mail, you can find a list of Haskell sound > libraries and their supported audio formats. Could you add that detail to the Haskell wiki Audio page? -- Don From vanenkj at gmail.com Sun Aug 24 16:13:17 2008 From: vanenkj at gmail.com (John Van Enk) Date: Sun Aug 24 16:11:59 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: Eric, I was hoping to use a packed format like ByteString eventually. Right now, I want to get everything working nicely. As it stands, I end up marshaling a lot of information into/out of arrays which I'd much rather keep as a block of memory. I'm guessing that some sort of unboxed array would be close to what I want. If you have suggestions, I'm more than open to them. (This is my first attempt at writing a library.) /jve On Sun, Aug 24, 2008 at 1:06 PM, Eric Kidd wrote: > On Sun, Aug 24, 2008 at 12:41 PM, John Van Enk wrote: > > It implements the Haskell bindings to the PortAudio library. This is the > > library behind Audacious. I *have not* implemented the callback model > yet, > > but I plan to do that. > > > > Perhaps this will be something which is useful to you? > > Looks like a great binding! We actually use portaudio in callback mode > at work, with reasonable success (from C++). > > One question: I notice that your writeStream function represents audio > using '[[a]]'. > > writeStream :: (Storable a) => PaStream a -- ^ The output stream > -> [[a]] -- ^ The samples to be played > -> Int -- ^ Number of frames > -> IO (Either String ErrorCode) -- ^ The return status > of the write > > In my experiments, I've been somewhat unsatisfied with the performance > of '[[a]]' as an audio format. Would you be interested in also > supporting an array-based format for audio data? > > I'm currently converting my program to use HCodec's Data.Audio > representation, which looks pretty promising. I don't know how it > performs yet, but I'll let you know. > > Thank you for the pointer to your library! It will make an excellent > addition to the available Haskell sound libraries. > > Cheers, > Eric > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080824/00716537/attachment.htm From haskell at randomhacks.net Sun Aug 24 16:52:18 2008 From: haskell at randomhacks.net (Eric Kidd) Date: Sun Aug 24 16:50:58 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: <431341160808241352s6538cc2ey8f379fe080584cba@mail.gmail.com> On Sun, Aug 24, 2008 at 4:13 PM, John Van Enk wrote: > I'm guessing that some sort of unboxed array would be close to what I want. > If you have suggestions, I'm more than open to them. (This is my first > attempt at writing a library.) I'm still trying to answer this question myself. :-) I'll let you know how HCodec's AudioData format actually works in practice once I my code is converted. Honestly, an ideal format should allow iteration over one or more StorableArray chunks. This would make it much easier to interact with the outside world. Unfortunately, HCodec's DiffUArray format seems to require a conversion step to get a StorableArray, so I'm going to have to benchmark it. Good luck with your first Haskell library! Cheers, Eric From dmehrtash at gmail.com Sun Aug 24 17:22:01 2008 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Sun Aug 24 17:20:43 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell Message-ID: I am trying to convert a string to a float. It seems that Data.ByteString library only supports readInt. After some googling I came accross a possibloe implementation: http://sequence.svcs.cs.pdx.edu/node/373 My questions are: a) is there a standard library implementation of string -> Double and float? b) Why is it that the ByteString only supports readInt? Is there a reason for it? Thanks, Daryoush Mehrtash -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080824/0e09a619/attachment.htm From dons at galois.com Sun Aug 24 17:23:49 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 24 17:22:27 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: References: Message-ID: <20080824212349.GF7128@scytale.galois.com> dmehrtash: > I am trying to convert a string to a float. It seems that Data.ByteString > library only supports readInt. After some googling I came accross a > possibloe implementation: [1]http://sequence.svcs.cs.pdx.edu/node/373 > Use the bytstring-lexing library, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-lexing Which provides a copying and non-copying lexer for doubles, readDouble :: ByteString -> Maybe (Double, ByteString) unsafeReadDouble :: ByteString -> Maybe (Double, ByteString) -- Don From tom.davie at gmail.com Sun Aug 24 17:33:47 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sun Aug 24 17:32:32 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: <20080824212349.GF7128@scytale.galois.com> References: <20080824212349.GF7128@scytale.galois.com> Message-ID: On 24 Aug 2008, at 23:23, Don Stewart wrote: > dmehrtash: >> I am trying to convert a string to a float. It seems that >> Data.ByteString >> library only supports readInt. After some googling I came >> accross a >> possibloe implementation: [1]http://sequence.svcs.cs.pdx.edu/node/373 >> > > Use the bytstring-lexing library, > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-lexing > > Which provides a copying and non-copying lexer for doubles, > > readDouble :: ByteString -> Maybe (Double, ByteString) > unsafeReadDouble :: ByteString -> Maybe (Double, ByteString) Incidentally, is there any reason we can't have this for Lazy BSes? Bob From dmehrtash at gmail.com Sun Aug 24 18:10:00 2008 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Sun Aug 24 18:08:41 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: <20080824212349.GF7128@scytale.galois.com> References: <20080824212349.GF7128@scytale.galois.com> Message-ID: I am curious to understand the logic, the "Haskell Think", here. Why is it that the byteString only supports conversion to int. daryoush On Sun, Aug 24, 2008 at 2:23 PM, Don Stewart wrote: > dmehrtash: > > I am trying to convert a string to a float. It seems that > Data.ByteString > > library only supports readInt. After some googling I came accross a > > possibloe implementation: [1]http://sequence.svcs.cs.pdx.edu/node/373 > > > > Use the bytstring-lexing library, > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-lexing > > Which provides a copying and non-copying lexer for doubles, > > readDouble :: ByteString -> Maybe (Double, ByteString) > unsafeReadDouble :: ByteString -> Maybe (Double, ByteString) > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080824/7703bc95/attachment.htm From dons at galois.com Sun Aug 24 18:12:33 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 24 18:11:13 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: References: <20080824212349.GF7128@scytale.galois.com> Message-ID: <20080824221233.GG7128@scytale.galois.com> We wrote a readInt a long time ago, because we needed it. It turns out that really though, there's a large class of functions for parsing bytestrings should come with, so I've started adding those to the bytestring-lexing package. In hindisight ByteString.readInt should have been in a separate package. -- Don dmehrtash: > I am curious to understand the logic, the "Haskell Think", here. Why is > it that the byteString only supports conversion to int. > > daryoush > On Sun, Aug 24, 2008 at 2:23 PM, Don Stewart <[1]dons@galois.com> wrote: > > dmehrtash: > > I am trying to convert a string to a float. It seems that > Data.ByteString > > library only supports readInt. After some googling I came > accross a > > possibloe implementation: > [1][2]http://sequence.svcs.cs.pdx.edu/node/373 > > > > Use the bytstring-lexing library, > > > [3]http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-lexing > > Which provides a copying and non-copying lexer for doubles, > > readDouble :: ByteString -> Maybe (Double, ByteString) > unsafeReadDouble :: ByteString -> Maybe (Double, ByteString) > -- Don > > References > > Visible links > 1. mailto:dons@galois.com > 2. http://sequence.svcs.cs.pdx.edu/node/373 > 3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-lexing From jefferson.r.heard at gmail.com Sun Aug 24 18:13:13 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sun Aug 24 18:11:54 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: References: <20080824212349.GF7128@scytale.galois.com> Message-ID: <4165d3a70808241513wc483e20g1489ea77149af229@mail.gmail.com> Because normally, Prelude.read covers this. Don's link is the most efficient, but you can also do (read . ByteString.unpack $ bytestring) :: Double to get a Double from a printed representation of most numbers. 2008/8/24 Daryoush Mehrtash : > I am curious to understand the logic, the "Haskell Think", here. Why is it > that the byteString only supports conversion to int. > > daryoush > On Sun, Aug 24, 2008 at 2:23 PM, Don Stewart wrote: >> >> dmehrtash: >> > I am trying to convert a string to a float. It seems that >> > Data.ByteString >> > library only supports readInt. After some googling I came accross >> > a >> > possibloe implementation: [1]http://sequence.svcs.cs.pdx.edu/node/373 >> > >> >> Use the bytstring-lexing library, >> >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-lexing >> >> Which provides a copying and non-copying lexer for doubles, >> >> readDouble :: ByteString -> Maybe (Double, ByteString) >> unsafeReadDouble :: ByteString -> Maybe (Double, ByteString) >> >> -- Don > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From ben.franksen at online.de Sun Aug 24 18:14:44 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 24 18:13:39 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season References: <1219435884.380.10.camel@localhost.localdomain> Message-ID: Hans van Thiel wrote: > I'm proud to announce the first monad tutorial of the new season. It's > under the Wiki permissive licence, but the web page has some clip art, > so 'The Greenhorn's Guide to becoming a Monad Cowboy' is on > http://www.muitovar.com/monad/moncow.xhtml "First, let's talk about prefix, infix and postfix. Suppose you want to put the argument of a unary function after the function (postfix)." You mean 'before', not 'after'. Cheers Ben From ben.franksen at online.de Sun Aug 24 18:33:23 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 24 18:32:15 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season References: <1219435884.380.10.camel@localhost.localdomain> Message-ID: Hans van Thiel wrote: > so 'The Greenhorn's Guide to becoming a Monad Cowboy' is on > http://www.muitovar.com/monad/moncow.xhtml Forgot to say: nicely written! Some more comments: You can declare a fixity (infixr) for flop instead of using parentheses (yes, this is allowed; see 'elem' in the Prelude). Would make the code more readable. "(Recall that a type definition is just like a data definition, but with no choice operator (|).)" First, you mean to say 'newtype', not 'type' (as in the code). Second, a newtype may also contain only one data element (i.e. one type expression after the constructor), not many, as in a data type definition. Third, newtype is unlifted. Cheers Ben From ben.franksen at online.de Sun Aug 24 18:37:28 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 24 18:38:44 2008 Subject: [Haskell-cafe] Re: ANN: Mueval 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.6.4 References: <20080821210016.GA17488@craft> Message-ID: Gwern Branwen wrote: > All the stuff from the previous ANNs still apply here: you can get it at > , Did that. Got: ben@sarun[1]: .../software/repos > mueval mueval: NotAllowed "Could not find module `Data.Number.BigFloat':\n Use -v to see a list of the files searched for." (using ghc-6.8.3) Cheers Ben From ben.franksen at online.de Sun Aug 24 18:47:53 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Aug 24 18:46:45 2008 Subject: [Haskell-cafe] Re: multi-core programming in Haskell References: <5ae4f2ba0808221448t14b791e1u7d69665f80edd548@mail.gmail.com> <5ae4f2ba0808232054m129af82bs953ea8252cfae268@mail.gmail.com> Message-ID: Galchin, Vasili wrote: > Thank you Murray. My post was not so clear .... I was referring to > "automatic" parellelization vs "manual" parallelization. By "automatic" I > mean the programmer doesn't have to indicate where to parallelize ... > instead the compiler decides how to parallize! Not on the horizon, it's too difficult. The best effort I know of automatically introduces par to the code /after running/ the program a few times (with the same given input data). There was some paper somewhere describing the idea and what the results were (IIRC, they achieved a respectable speedup in cases where there was enough potential for parallelization). Note this is /not/ something a compiler could do. Cheers Ben From dons at galois.com Sun Aug 24 18:52:45 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 24 18:51:22 2008 Subject: [Haskell-cafe] Re: multi-core programming in Haskell In-Reply-To: References: <5ae4f2ba0808221448t14b791e1u7d69665f80edd548@mail.gmail.com> <5ae4f2ba0808232054m129af82bs953ea8252cfae268@mail.gmail.com> Message-ID: <20080824225245.GH7128@scytale.galois.com> ben.franksen: > Galchin, Vasili wrote: > > Thank you Murray. My post was not so clear .... I was referring to > > "automatic" parellelization vs "manual" parallelization. By "automatic" I > > mean the programmer doesn't have to indicate where to parallelize ... > > instead the compiler decides how to parallize! > > Not on the horizon, it's too difficult. The best effort I know of > automatically introduces par to the code /after running/ the program a few > times (with the same given input data). There was some paper somewhere > describing the idea and what the results were (IIRC, they achieved a > respectable speedup in cases where there was enough potential for > parallelization). Note this is /not/ something a compiler could do. For restricted subsets of Haskell (e.g. data parallel array programming), the compiler can essentially do this. But you have to restrict yourself enough to make the problem (and cost model) tractably to do automatically. -- Don From duncan.coutts at worc.ox.ac.uk Sun Aug 24 20:46:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 24 20:44:38 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: Message-ID: <1219625180.13639.465.camel@localhost> This topic came up in #haskell this evening... On Sun, 2008-08-24 at 16:12 -0700, Ashley Yakeley wrote: > 1. Global mutable state. For instance, here's the count variable for > Data.Unique rewritten: > > uniqSource :: MVar Integer > uniqSource <- newMVarTL 0 > > Isn't that much nicer? > It's nicer syntax but it's still not true. There's still no such thing as a global variable. There's always a scope. In this case what scope are we looking for? Process scope? Only one instance of ?uniqSource per process? If so, it's not right. We can link in multiple copies of a package and thereby end up with multiple instances (this really happens, it's not a far fetched scenario). So ?uniqSource is a package-name/version scope mutable variable. To get the right thing for the annoying C libs that have 'global' init and finalise functions you need something else. Not actually process scope, that's too wide. You need exactly the same scope as the system linker is using, so that we get one variable per instance of the C library linked into the process. Consider a process using several dlls where each one links to a C lib that needs 'global' initialisation, we must have exactly one 'global' var instance per dll in this case because that's the linker namespace scope. The scope you need depends on the application. A language extension like this is likely to only cover package-name/version scope, not scopes like thread, OS thread, rts instance, linker, process, user account, OS, subnet, interweb, planet etc. So in practise, what scopes do we often need, and does ?package-name/version scope correspond to many of those use cases? Duncan From gwern0 at gmail.com Sun Aug 24 21:44:39 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Aug 24 21:44:04 2008 Subject: [Haskell-cafe] Re: ANN: Mueval 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.6.4 In-Reply-To: References: <20080821210016.GA17488@craft> Message-ID: <20080825014439.GA25093@craft> On 2008.08.25 00:37:28 +0200, Ben Franksen scribbled 0.4K characters: > Gwern Branwen wrote: > > All the stuff from the previous ANNs still apply here: you can get it at > > , > > Did that. Got: > > ben@sarun[1]: .../software/repos > mueval > mueval: NotAllowed "Could not find module `Data.Number.BigFloat':\n Use -v > to see a list of the files searched for." > > (using ghc-6.8.3) > > Cheers > Ben Yes, mmorrow ran into this issue as well. Apparently a number of numeric modules just aren't installed for some people. I don't know why. I fixed this in darcs Mueval by moving all the ones mmorrow identified as problematic into the allowable-but-not-defaults list. Seemed to work, although obviously if you/he specifically request --module Data.Number.BigFloat I would expect it to break again. -- gwern One SAO E.O.D. Propaganda LLNL Terrorism anarchy USSS forcast Chan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080824/d0480bb8/attachment.bin From ashley at semantic.org Sun Aug 24 22:34:06 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Aug 24 22:32:48 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219625180.13639.465.camel@localhost> References: <1219625180.13639.465.camel@localhost> Message-ID: <48B21A1E.8040502@semantic.org> Duncan Coutts wrote: > This topic came up in #haskell this evening... > > On Sun, 2008-08-24 at 16:12 -0700, Ashley Yakeley wrote: >> 1. Global mutable state. For instance, here's the count variable for >> Data.Unique rewritten: >> >> uniqSource :: MVar Integer >> uniqSource <- newMVarTL 0 >> >> Isn't that much nicer? >> > > It's nicer syntax but it's still not true. There's still no such thing > as a global variable. There's always a scope. > > In this case what scope are we looking for? Process scope? Only one > instance of ?uniqSource per process? It is actually process scope, I believe. But it's one instance of "base-3.0.2.0:Data.Unique.uniqSource" per process: we don't care if there's also a "base-4.0:Data.Unique.uniqSource". The reason we don't care in this case is that base-3.0.2.0:Data.Unique.Unique and base-4.0:Data.Unique.Unique are different types, so they can't collide. These are different names in the same scope. The scope I'm interested in is "Main.main" scope, i.e., the initialiser should be run no more than once per run of "main". -- Ashley Yakeley From ashley at semantic.org Sun Aug 24 23:11:16 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Aug 24 23:09:57 2008 Subject: [Haskell-cafe] Re: Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> Message-ID: <48B222D4.70709@semantic.org> Thomas Davie wrote: > I'd be interested to see your other examples -- because that error is > not happening in Haskell! You can't argue that Haskell doesn't give you > no segfaults, because you can embed a C segfault within Haskell. This segfaults on my x86_64 Linux box: module Main where import Data.Typeable import Data.IORef data T = T instance Typeable T where typeOf _ = typeOf (undefined :: IORef ()) main :: IO () main = writeIORef (maybe undefined id (cast T)) () You'll note nothing marked "Foreign" or "unsafe", and only the base library used. Does the segfault "happen in Haskell" or not? -- Ashley Yakeley From dons at galois.com Sun Aug 24 23:59:21 2008 From: dons at galois.com (Don Stewart) Date: Sun Aug 24 23:57:58 2008 Subject: [Haskell-cafe] Re: Haskell Propeganda In-Reply-To: <48B222D4.70709@semantic.org> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <48B222D4.70709@semantic.org> Message-ID: <20080825035921.GA8011@scytale.galois.com> ashley: > Thomas Davie wrote: > >I'd be interested to see your other examples -- because that error is > >not happening in Haskell! You can't argue that Haskell doesn't give you > >no segfaults, because you can embed a C segfault within Haskell. > > This segfaults on my x86_64 Linux box: > > module Main where > import Data.Typeable > import Data.IORef > data T = T > instance Typeable T where > typeOf _ = typeOf (undefined :: IORef ()) > main :: IO () > main = writeIORef (maybe undefined id (cast T)) () > > You'll note nothing marked "Foreign" or "unsafe", and only the base > library used. Does the segfault "happen in Haskell" or not? You just wrote unsafeCoere# a different way: typeOf T = typeOf (undefined :: IORef ()) Manual Typeable deriving should probably be disabled :-) -- Don From ashley at semantic.org Mon Aug 25 00:33:29 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Aug 25 00:32:12 2008 Subject: [Haskell-cafe] Re: Haskell Propeganda In-Reply-To: <20080825035921.GA8011@scytale.galois.com> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <48B222D4.70709@semantic.org> <20080825035921.GA8011@scytale.galois.com> Message-ID: <48B23619.1040101@semantic.org> Don Stewart wrote: > You just wrote unsafeCoere# a different way: > > typeOf T = typeOf (undefined :: IORef ()) Right. It's straightforward to write unsafe segfaulting code in apparently safe Haskell. > Manual Typeable deriving should probably be disabled :-) Another ugly special-case hack. There's a better way. -- Ashley Yakeley From allbery at ece.cmu.edu Mon Aug 25 00:38:49 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 25 00:37:36 2008 Subject: [Haskell-cafe] Re: Haskell Propeganda In-Reply-To: <48B23619.1040101@semantic.org> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <48B222D4.70709@semantic.org> <20080825035921.GA8011@scytale.galois.com> <48B23619.1040101@semantic.org> Message-ID: On 2008 Aug 25, at 0:33, Ashley Yakeley wrote: > Don Stewart wrote: >> You just wrote unsafeCoere# a different way: >> typeOf T = typeOf (undefined :: IORef ()) > > Right. It's straightforward to write unsafe segfaulting code in > apparently safe Haskell. typeOf / Typeable is itself an ugly special case, and really should be designed into the language: it's about runtime type information. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ashley at semantic.org Mon Aug 25 00:46:52 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Aug 25 00:45:35 2008 Subject: [Haskell-cafe] Re: Haskell Propeganda In-Reply-To: References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <48B222D4.70709@semantic.org> <20080825035921.GA8011@scytale.galois.com> <48B23619.1040101@semantic.org> Message-ID: <48B2393C.1030505@semantic.org> Brandon S. Allbery KF8NH wrote: > typeOf / Typeable is itself an ugly special case, Right. > and really should be designed into the language That's not necessary. The same thing can be done with top-level "<-" (see other thread). -- Ashley Yakeley From mutjida at gmail.com Mon Aug 25 01:03:01 2008 From: mutjida at gmail.com (jeff p) Date: Mon Aug 25 01:01:41 2008 Subject: [Haskell-cafe] Re: Haskell Propeganda In-Reply-To: <20080825035921.GA8011@scytale.galois.com> References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <48B222D4.70709@semantic.org> <20080825035921.GA8011@scytale.galois.com> Message-ID: Hello, > Manual Typeable deriving should probably be disabled :-) > There are legitimate reasons to define your own Typeable instances. Since Typeable already contains all the machinery you need to type a standard functional language, it is nice to just add Typeable instances when defining your own DSL which builds upon standard language constructs; the alternative is to recreate the Typeable machinery for your own type representations. -Jeff From lemming at henning-thielemann.de Mon Aug 25 02:52:15 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Aug 25 02:51:25 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> Message-ID: On Sun, 24 Aug 2008, Eric Kidd wrote: > Greetings, Haskell folks! > > I'm working on a toy program for drum synthesis. This has lead me to > explore the various sound-related libraries in Hackage. Along the way, > I've learned several things: > > 1. There's a lot of Haskell sound libraries, but no agreement on how > to represent buffers of audio data. In my sound synthesis library http://darcs.haskell.org/synthesizer/ I use mainly two representations: 1. Chunky sequences based on StorableVector. This is for efficient storage and functions that need to process data in a non-causal way. They are not good for fusion. http://darcs.haskell.org/synthesizer/src/Synthesizer/Storable/Signal.hs 2. A Stream like sequences without wrappers. In fact, they are no data storages but generator functions equipped with a seed. I use them for causal signal processes. I think that most functions needed for drum synthesis are causal. By inlining them, many subsequent causal signal processes are fused to one. http://darcs.haskell.org/synthesizer/src/Synthesizer/State/Signal.hs > 2. Some of the most useful sound libraries aren't listed in Hackage's > "Sound" section, including HCodecs, SDL-mixer and hogg. my library is also not at Hackage, it's too much experimental currently > 3. The Haskell OpenAL bindings are great, but ALUT has been removed > from MacOS 10.5. Of course, a pure-Haskell version of ALUT would > be pretty easy to write, and it could be used as a fallback. > 4. '[[a]]' is _not_ a good representation for multi-channel audio > data. Manipulating even 10 seconds of audio is noticeably slow. Using the signal representations I mentioned above, I can synthesize some songs in realtime. For stereo signals I use Signal (a,a). However, a StereoFrame data type with Storable instance might be even better. > 5. HCodecs is probably the best library for reading WAVE files. It > uses 'DiffUArray Int a' to represent audio data, and not '[[a]]'. > It also supports MIDI and SoundFont, which is quite handy. > 6. YampaSynth looks really cool, and it might be possible to turn it > into a reusable MIDI synthesizer library for use with HCodecs. > This would be extremely useful: it would provide a basis for all > kinds of crazy MIDI-based programming in Haskell. If you are after realtime synthesis you might also want to look into SuperCollider. I posted some code to control SuperCollider via MIDI to haskell-art. I can send it to you, if you like. > What would the ideal Haskell sound API look like? Personally, I would > love to see: > > a. Something like HCodecs's Data.Audio as the basic sound format. > Data.Audio is an array-based API, and it supports converting > between a wide range of common sample formats. I don't know how > fast this is, but it already exists, and it's used by YampaSynth. > b. OpenAL for sound playback, with a portable version of ALUT. This > may require writing a pure-Haskell version of ALUT. So far I used Sox' play command fed by a pipe with runInteractiveCommand. > Other nice-to-have features might include: > > e. A standard MIDI format, based on either the HCodecs package or the > midi package. (HCodecs is used by YampaSynth, and the midi package > is used by alsa-midi.) midi package is mainly used by Haskore > f. A modular version of YampaSynth which can convert MIDI data > structures into Data.Audio values. > > It looks like Haskell could be a really sweet audio programming > environment with just a bit of integration work. What do folks think? > Are there other libraries I should look at more closely? Other features > that should be included in an ideal audio API? What do you mean by 'API'? I think there should not be one library handling all kind of music tasks. For interoperability common data structures are nice. However, what signal representation concerns, I think we need more than one representation, because different applications have different needs. > Haskell audio libraries I have advertised my libraries for years in Haskell-Wiki and HCAR, but it seems that people do not look there. :-( > Reading and writing sound files: > HCodecs: (Audible a) => DiffUArray Int a > hsndfile: MArray with Float and Double > HSoundFile: [[Double]] > ALUT: OpenAL.AL.Buffer > WAVE: [[Int32]] > > Playing sounds: > OpenAL: Ptr UInt8, Ptr Int16, 1-N channels > SDL-mixer: ForeignPtr ChunkStruct, ForeignPtr MusicStruct Sox via pipe, using any data structure which can be written to a file > Sound processing libraries: > dsp: Array a, [a] > jack: Operates via mapping functions > mainMono :: (CFloat -> IO CFloat) -> IO () > mainStereo :: ((CFloat, CFloat) -> IO (CFloat, CFloat)) -> IO () synthesizer: StorableVector, State, Generic (older: list, fusable list) > MIDI-based: > HCodecs: Reads and writes MIDI files > midi: Reads and writes MIDI files > alsa-midi: Uses midi library > YampaSynth: Stand-alone program Haskore uses MIDI and other back-ends like Haskell Synthesizer, CSound, SuperCollider > Special-purpose APIs only (FFIs, etc.): > hCsound: CsoundPtr > hsc3: UGen HasSound > No public sound-buffer API: > hbeat: The relevant source files are missing! > hogg: Very low-level API for Ogg internals only > libmpd: No sound buffer API > sonic-visualizer: No sound buffer API > truelevel: Stand-alone program (uses WAVE) > wavconvert: Stand-alone program From lemming at henning-thielemann.de Mon Aug 25 03:01:49 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Aug 25 03:00:29 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: On Sun, 24 Aug 2008, John Van Enk wrote: > Eric, > > I was hoping to use a packed format like ByteString eventually. Right now, I > want to get everything working nicely. As it stands, I end up marshaling a > lot of information into/out of arrays which I'd much rather keep as a block > of memory. > > I'm guessing that some sort of unboxed array would be close to what I want. > If you have suggestions, I'm more than open to them. (This is my first > attempt at writing a library.) In recent versions of StorableVector (not at hackage yet, only in darcs repository) there is a chunky lazy variant. However there are also the uvector and vector packages, and no-one seems to know, on which one we should focus. Let me elaborate on my point, that there is not one data structre which fits all needs: The great thing about Haskell's laziness is that you can implement feedback easily. But this does not work with chunky lazy sequences (StorableVector.Lazy) and causes quadratic computation time with my State.Signal representation. It works only with element-wise lazy structures, aka lists. I have an idea for a more efficient data structure for that problem, but I'm uncertain if it is really more efficient in the end. From jed at 59A2.org Mon Aug 25 04:12:41 2008 From: jed at 59A2.org (Jed Brown) Date: Mon Aug 25 04:11:26 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <1219601010.3996.49.camel@myhost> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <1219552290.3996.33.camel@myhost> <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> <1219601010.3996.49.camel@myhost> Message-ID: <20080825081241.GH31645@brakk.ethz.ch> On Sun 2008-08-24 11:03, Thomas M. DuBuisson wrote: > Yay, the multicore version pays off when the workload is non-trivial. > CPU utilization is still rather low for the -N2 case (70%). I think the > Haskell threads have an affinity for certain OS threads (and thus a > CPU). Perhaps it results in a CPU having both tokens of work and the > other having none? This must be obvious to everyone but the original thread-ring cannot possibly be faster with multiple OS thread since a thread can only be running if it has the token, otherwise it is just blocked on the token. If there are threads executing simultaneously, the token must at least be written to the shared cache if not to main memory. With the single threaded runtime, the token may never leave L1. The difference between -threaded -N1 and -nothreaded may be influenced by the effectiveness of prefetching the next thread (since presumably not all 503 threads can reside in L1). Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080825/11917dd7/attachment.bin From wss at cs.nott.ac.uk Mon Aug 25 04:28:43 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Mon Aug 25 04:27:23 2008 Subject: [Haskell-cafe] ANN: The Monad.Reader - Issue 11 Message-ID: I am pleased to announce that a new issue of The Monad.Reader is now available: http://www.haskell.org/haskellwiki/The_Monad.Reader Issue 11 consists of the following three articles: * David F. Place How to Refold a Map * Kenneth Knowles First-Order Logic a la Carte * Douglas M. Auclair MonadPlus: What a Super Monad! The Monad.Reader is a quarterly magazine about functional programming. It is less formal than a journal, but a bit more enduring than a wiki page or blog post. If you'd like to write something for the next issue of The Monad.Reader, please get in touch. I haven't fixed the deadline for the next issue just yet. Expect a deadline early 2009. Wouter From briqueabraque at yahoo.com Mon Aug 25 07:23:07 2008 From: briqueabraque at yahoo.com (=?UTF-8?B?TWF1csOtwq1jaW8=?=) Date: Mon Aug 25 07:22:02 2008 Subject: [Haskell-cafe] Prototype of a syntax reference Message-ID: Hi, I'm trying to make a syntax reference in the form of source code. It's not ready, but if someone shares the same ideas I could use some help. (Should I put this on a wiki? Where?) My ?design principles? are: ? It should contain just pieces of uncommented code. The idea is not to use it as a fast tutorial, but as a reminder of how to write all kinds of things, and solve all questions of type ?is this allowed??; ? It should be small, and fit on a printed A4 page; ? It should show the complete syntax of everything, not the most common. For instance, ?case of? should show the use of guards; ? It should be an example of valid code, not good one. The idea is to show what can be done, not what should :) ? It should use expanded code, not identation rules. Replacement of identation for code (like {} etc.) have simple rules, and the proper way to ident can be deduced from expanded code. Sometimes this is important if we are trying to solve syntax errors; ? It should use Unicode. It's nice to know which kind of Unicode characters can actually be used; ? It should use no predefined types or classes except Bool. I?ll write a Prelude code reference if this first attempt go right. So I came up with the weird code below. It should contain a lot more, and be more dense (more syntax examples per lines of code), but it's already usefull for a begginer like me. What do you think? Best, Maur?cio module ?a (Ex?mplo(?wir?,?wet'?,?wet'?),a???,Cl???) where { class Cl??? ? where { (?) :: ? -> ? -> ?; ?Amber :: ? -> ?; ?Amber a = a ? a; }; data D? = U1 | U2 | U3; data D? = V?1 | V?2 | JustV?; data D? = Op??o | OutraOp??o; data Ex?mplo = ?wir? | ?wet'? D? | ?wet'? D? Ex?mplo; osmesmos :: D? -> D? -> Bool; osmesmos Op??o Op??o = True; osmesmos OutraOp??o OutraOp??o = True; osmesmos _ _ = False; a??? = (?wet'? V?2 a???) ? ?wir?; instance Cl??? Ex?mplo where { ?wir? ? _ = ?wir?; a@(?wet'? b) ? x = case x of { ?wir? -> a; y@(?wet'? o) | (osmesmos o Op??o) -> a | otherwise -> ?wet'? V?1 y; y@(?wet'? _ _) -> y ? a }; a@(?wet'? V?1 _) ? _ = a; a@(?wet'? V?2 x) ? _ = x; a@(?wet'? JustV? _) ? y = y; } } From phercek at gmail.com Mon Aug 25 08:28:17 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon Aug 25 08:29:36 2008 Subject: [Haskell-cafe] Re: Prototype of a syntax reference In-Reply-To: References: Message-ID: Maur??cio wrote: > ? It should show the complete syntax of > everything, not the most common. For instance, > ?case of? should show the use of guards; > > ? It should be an example of valid code, not good > one. The idea is to show what can be done, not > what should :) This can help you when you will generate all the options. It can also help you when analyzing whether your options are right, or (for example) when looking where are all the places some language construct can be used in. Enable java script for the page and try to click on all the places where you see "hand" cursor: http://www.hck.sk/users/peter/HaskellEx.htm The page above is the one I used when learning Haskell. I'm curious whether you can fit it on one A4 page. Probably depends on font size :) Peter. From hthiel.char at zonnet.nl Mon Aug 25 08:33:08 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Mon Aug 25 08:32:35 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: References: <1219435884.380.10.camel@localhost.localdomain> Message-ID: <1219667589.2872.18.camel@localhost.localdomain> On Mon, 2008-08-25 at 00:33 +0200, Ben Franksen wrote: > Hans van Thiel wrote: > > so 'The Greenhorn's Guide to becoming a Monad Cowboy' is on > > http://www.muitovar.com/monad/moncow.xhtml > > Forgot to say: nicely written! > > Some more comments: > > You can declare a fixity (infixr) for flop instead of using parentheses > (yes, this is allowed; see 'elem' in the Prelude). Would make the code more > readable. > > "(Recall that a type definition is just like a data definition, but with no > choice operator (|).)" First, you mean to say 'newtype', not 'type' (as in > the code). Thanks for the feedback. If and when I get some more comments and error reports, I'll try to fix them. > Second, a newtype may also contain only one data element (i.e. > one type expression after the constructor), not many, as in a data type > definition. Yes, that's what I thought too, but then I got confused by State s a, which looks to have two. Could you explain? > Third, newtype is unlifted. The books I use for reference, the Craft and SOE, don't seem to mention this. I have to confess, I don't really understand the difference between newtype and data. Again, an explanation would be appreciated. As a general comment on the teaching of Haskell, all books and tutorials, which I've seen, appear to treat this aspect of Haskell as if it were self explanatory. This while the better known imperative languages don't have anything like it. Only Real World Haskell explains algebraic data types to some satisfaction (IMHO, of course). Best Regards, Hans From ketil at malde.org Mon Aug 25 10:48:29 2008 From: ketil at malde.org (Ketil Malde) Date: Mon Aug 25 10:45:51 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <87r68kg0e3.wl%jeremy@n-heptane.com> (Jeremy Shaw's message of "Tue\, 19 Aug 2008 14\:28\:36 -0700") References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> Message-ID: <874p59m9qa.fsf_-_@malde.org> I've had an interested user, who tried to get one of my programs to run on a Debian machine - running Debian Etch, released a couple of months ago. Here are some of the hurdles stumbled upon in the process: 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file. 2. ghc-6.8.3, presumably the binary snapshots, didn't work, neither in i386 nor in x86_64 incarnation. 3. ghc 6.8.1-i386 appears to work, but some of the dependencies failed to compile (tagsoup, in this case) 4. A precompiled (by me), statically linked binary refuses to run with a message of "FATAL: kernel too old". Granted, not all of this is our fault, but it won't help users to start charging the windmills of Debian conservativism. We really need to make this process smoother, and ideally, provide debs for Etch backports. I'm not sure how to go about any of this, beyond debianizing my own packages. But that's why I'm telling you. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From isaacdupree at charter.net Mon Aug 25 10:48:09 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Aug 25 10:46:58 2008 Subject: [Haskell-cafe] Prototype of a syntax reference In-Reply-To: References: Message-ID: <48B2C629.7030106@charter.net> Maur??cio wrote: > ? It should be an example of valid code, not good > one. The idea is to show what can be done, not > what should :) then put lots of semicolons somewhere: while they are at minimum a separator, it's generally allowed to insert as many extra semicolons as you want at the beginning, end, or wherever you could put a single semicolon. (I wish the same were true for commas.) -Isaac From bremner at unb.ca Mon Aug 25 11:48:00 2008 From: bremner at unb.ca (David Bremner) Date: Mon Aug 25 11:46:41 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <874p59m9qa.fsf_-_@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> Message-ID: <87d4jxxfin.wl%bremner@pivot.cs.unb.ca> Ketil Malde wrote: >I've had an interested user, who tried to get one of my programs to >run on a Debian machine - running Debian Etch, released a couple of >months ago. Your user is pretty much at the pessimal point in the release cycle. Etch is more than a year old, and lenny (the next release) is in pre-release freeze. None of which helps your users, of course. Perhaps things will improve once lenny is out. [non-working versions snipped] >Granted, not all of this is our fault, but it won't help users to >start charging the windmills of Debian conservativism. We really need >to make this process smoother, and ideally, provide debs for Etch >backports. Another option is to try installing the version from lenny (6.8.2). This may or may not pull in a wack of dependencies, but is not difficult to try out [1]. >I'm not sure how to go about any of this, beyond debianizing my own >packages. But that's why I'm telling you. :-) There was some discussion on the list recently about a tool to semi-automatically debianize haskell packages. Perhaps this is of interest to you. There is also a debian-haskell [2] list, which might be relevant. David [1]: http://wiki.debian.org/AptPinning [2]: currently at http://urchin.earth.li/mailman/listinfo/debian-haskell but possible moving. From ahey at iee.org Mon Aug 25 11:55:05 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Aug 25 11:53:45 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> Message-ID: <48B2D5D9.8020608@iee.org> (Moving to Haskell cafe) Edward Kmett wrote: > On Sun, Aug 24, 2008 at 7:12 PM, Ashley Yakeley wrote: > >> Is there any interest in implementing a top level "<-" to run monadic code? >> > > This is actually implemented in jhc. See the 'top level actions' section of > http://repetae.net/computer/jhc/manual.html Gosh! I was always quite impressed by Johns determination to write a Haskell compiler and by his self discipline in resisting the temptation to fix everything that was wrong with Haskell and keep to standards :-) I implemented my own ACIO monad a while ago (which is of course quite useless without top level <- bindings) and it turned out that there was quite a lot that could go in here. The only problem seemed to be that some things that seemed perfectly reasonable to create via ACIO had *IO* finalisers associated with them, which didn't feel right to me. But if you think about how finalisers get run I'm inclined to think we should insist that they are ACIO too. Regards -- Adrian Hey From frank at geoinfo.tuwien.ac.at Mon Aug 25 12:08:56 2008 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Mon Aug 25 12:07:37 2008 Subject: [Haskell-cafe] problem with cabal for syb-with-class Message-ID: <1219680537.14617.12.camel@bernH> i tried to install wxGeneric and need syb-with-class. i got the package from hackage. configure runs fine, but when i build i get: Data/Generics/SYB/WithClass/Instances.hs:11:7: Could not find module `Data.Array': it is a member of package array-0.1.0.0, which is hidden but array-0.1.0.0 is installed, as shown later. what can be wrong? why is an installed package complained about as hidden? thanks for help! andrew frank@bernH:~/haskellSources/packages/syb-with-class-0.3$ ghc-pkg describe array name: array version: 0.1.0.0 license: BSD3 copyright: maintainer: libraries@haskell.org stability: homepage: package-url: description: This package defines the classes @IArray@ of immutable arrays and @MArray@ of arrays mutable within appropriate monads, as well as some instances of these classes. category: author: exposed: True exposed-modules: Data.Array Data.Array.Base Data.Array.Diff Data.Array.IArray Data.Array.IO Data.Array.MArray Data.Array.ST Data.Array.Storable Data.Array.Unboxed hidden-modules: Data.Array.IO.Internals import-dirs: /usr/lib/ghc-6.8.2/lib/array-0.1.0.0 library-dirs: /usr/lib/ghc-6.8.2/lib/array-0.1.0.0 hs-libraries: HSarray-0.1.0.0 extra-libraries: extra-ghci-libraries: include-dirs: includes: depends: base-3.0.1.0 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /usr/share/doc/ghc6-doc/libraries/array/array.haddock haddock-html: /usr/share/doc/ghc6-doc/libraries/array f From mads_lindstroem at yahoo.dk Mon Aug 25 12:10:41 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Mon Aug 25 12:18:34 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <874p59m9qa.fsf_-_@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> Message-ID: <1219680641.4486.15.camel@localhost.localdomain> Hi Ketil Malde wrote: > I've had an interested user, who tried to get one of my programs to > run on a Debian machine - running Debian Etch, released a couple of > months ago. Here are some of the hurdles stumbled upon in the > process: Debian Etch were released in April 8th, 2007. 16 months ago. Hardly "a copule of months ago". See http://www.debian.org/News/2007/20070408.en.html . Sure, there have been updates since then, but they are mainly concerned with security and drivers for new hardware. > > 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file. > 2. ghc-6.8.3, presumably the binary snapshots, didn't work, neither > in i386 nor in x86_64 incarnation. > 3. ghc 6.8.1-i386 appears to work, but some of the dependencies failed > to compile (tagsoup, in this case) > 4. A precompiled (by me), statically linked binary refuses to run with > a message of "FATAL: kernel too old". > > Granted, not all of this is our fault, but it won't help users to > start charging the windmills of Debian conservativism. We really need > to make this process smoother, and ideally, provide debs for Etch > backports. > > I'm not sure how to go about any of this, beyond debianizing my own > packages. But that's why I'm telling you. :-) There are several options: 1) Use the testing or unstable branch of Debian. They got newer packages. Testing (aka. Lenny) has GHC 6.8.2 http://packages.debian.org/lenny/ghc6 . 2) Compile GHC yourself. You can even compile and install GHC (and most Haskell software) on a dedicated user account. In this way you avoid messing up you Debian installation if something goes wrong. 3) If testing/unstable is too risky, then use backports to stable. See http://www.backports.org/dokuwiki/doku.php . Unfortunately, they do not have GHC in their repository. Maybe somebody else has. 4) Wait for the next release of Debian. It should not be too far into the future, as the next release is now frozon http://www.debian.org/News/weekly/2008/08/ . But with a project like Debian that releases when ready, not on a deadline, you never quite know when the next release will be there. > > -k Greetings, Mads Lindstr?m From daniel.is.fischer at web.de Mon Aug 25 13:22:49 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Aug 25 13:20:54 2008 Subject: [Haskell-cafe] problem with cabal for syb-with-class In-Reply-To: <1219680537.14617.12.camel@bernH> References: <1219680537.14617.12.camel@bernH> Message-ID: <200808251922.49358.daniel.is.fischer@web.de> Am Montag, 25. August 2008 18:08 schrieb Andrew U. Frank: > i tried to install wxGeneric and need syb-with-class. > i got the package from hackage. > configure runs fine, but when i build i get: > > Data/Generics/SYB/WithClass/Instances.hs:11:7: > Could not find module `Data.Array': > it is a member of package array-0.1.0.0, which is hidden > > but array-0.1.0.0 is installed, as shown later. > what can be wrong? why is an installed package complained about as > hidden? > > thanks for help! > > andrew > Probably an old .cabal file where array is not yet listed among the build-depends. Cabal hides all packages not listed there when building. Try adding array to that list and building again (the same may be necessary for some other packages which were split off base). Cheers, Daniel From dons at galois.com Mon Aug 25 13:23:43 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 25 13:22:20 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: <20080825172343.GA9655@scytale.galois.com> lemming: > > On Sun, 24 Aug 2008, John Van Enk wrote: > > >Eric, > > > >I was hoping to use a packed format like ByteString eventually. Right > >now, I > >want to get everything working nicely. As it stands, I end up marshaling a > >lot of information into/out of arrays which I'd much rather keep as a > >block > >of memory. > > > >I'm guessing that some sort of unboxed array would be close to what I > >want. > >If you have suggestions, I'm more than open to them. (This is my first > >attempt at writing a library.) > > In recent versions of StorableVector (not at hackage yet, only in darcs > repository) there is a chunky lazy variant. However there are also the > uvector and vector packages, and no-one seems to know, on which one we > should focus. There's no immediate plans to merge them, but uvector will likely gain a lazy variant soonish. As 'vector's announcement said, uvector is the stable, more conservative variant that works with 6.8.2, and has a richer API. -- Don From twinside at gmail.com Mon Aug 25 13:43:17 2008 From: twinside at gmail.com (Twinside) Date: Mon Aug 25 13:42:03 2008 Subject: [Haskell-cafe] OpenGL's VBO with Haskell Message-ID: <000001c906da$101468e0$303d3aa0$@com> Hi Haskell list, Today I'm turning to you for the use of VBO (Vertex Buffer Object) in Haskell. I seem to be able to create one without any problem using the following code : ------------------------------------------------------ vboOfList :: Int -> [Float] -> IO BufferObject vboOfList size elems = let ptrsize = toEnum $ size * 4 arrayType = ElementArrayBuffer in do [array] <- genObjectNames 1 bindBuffer arrayType $= Just array arr <- newListArray (0, size - 1) elems withStorableArray arr (\ptr -> bufferData arrayType $= (ptrsize, ptr, StaticDraw)) bindBuffer ArrayBuffer $= Nothing reportErrors return array ------------------------------------------------------ However the problem arise when I try to draw primitives using this vbo : ------------------------------------------------------ displayVbo buff size = do let stride = toEnum sizeOfVertexInfo vxDesc = VertexArrayDescriptor 3 Float stride $ offset 0 colors = VertexArrayDescriptor 4 Float stride $ offset 12 texCoo = VertexArrayDescriptor 2 Float stride $ offset (12 + 16) filt = VertexArrayDescriptor 4 Float stride $ offset (12 + 16 + 8) bindBuffer ArrayBuffer $= Just buff arrayPointer VertexArray $= vxDesc arrayPointer ColorArray $= colors arrayPointer TextureCoordArray $= texCoo arrayPointer SecondaryColorArray $= filt drawArrays Quads 0 size bindBuffer ArrayBuffer $= Nothing ------------------------------------------------------ Nothing is displayed on screen. As you can see, my VBO contain interleaved data : - 3 float for the vertex - 4 for the color - 2 for the texture coordinate - 4 for the secondary color) The 'offset' function has type Int -> Ptr Float, and is used to forge a pointer from an Int, to mimic the C way of using VBO. As far as I've checked, the values in my list for VBO generation are valid and well displayed using other techniques. So is there a workaround other method for my solution, preferably by keeping my data interleaved? Secondly, is there any sample for advanced features like VBOs in Haskell? Regards, Vincent From dons at galois.com Mon Aug 25 13:57:50 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 25 13:56:29 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <20080825081241.GH31645@brakk.ethz.ch> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <1219552290.3996.33.camel@myhost> <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> <1219601010.3996.49.camel@myhost> <20080825081241.GH31645@brakk.ethz.ch> Message-ID: <20080825175750.GD9655@scytale.galois.com> jed: > On Sun 2008-08-24 11:03, Thomas M. DuBuisson wrote: > > Yay, the multicore version pays off when the workload is non-trivial. > > CPU utilization is still rather low for the -N2 case (70%). I think the > > Haskell threads have an affinity for certain OS threads (and thus a > > CPU). Perhaps it results in a CPU having both tokens of work and the > > other having none? > > This must be obvious to everyone but the original thread-ring cannot > possibly be faster with multiple OS thread since a thread can only be > running if it has the token, otherwise it is just blocked on the token. > If there are threads executing simultaneously, the token must at least > be written to the shared cache if not to main memory. With the single > threaded runtime, the token may never leave L1. The difference between > -threaded -N1 and -nothreaded may be influenced by the effectiveness of > prefetching the next thread (since presumably not all 503 threads can > reside in L1). > Simon Marlow sez: The thread-ring benchmark needs careful scheduling to get a speedup on multiple CPUs. I was only able to get a speedup by explicitly locking half of the ring onto each CPU. You can do this using GHC.Conc.forkOnIO in GHC 6.8.x, and you'll also need +RTS -qm -qw. Also make sure that you're not using the main thread for any part of the main computation, because the main thread is a bound thread and runs in its own OS thread, so communication between the main thread and any other thread is slow. From vanenkj at gmail.com Mon Aug 25 14:16:59 2008 From: vanenkj at gmail.com (John Van Enk) Date: Mon Aug 25 14:15:38 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: How well would the storablevector package (Data.StorableVector) work for storing audio data? One of the major issues I'm still working over is that I want to maintain something similar to a [[a]] format (since the underlying PortAudio library and hardware could support hundreds of interleaved channels) but I would like to be able to build in some typechecking to the functions to make sure the number of channels matches the nubmer expected in the functions. I've considered doing the following: > data SingleChannel > data DualChannel > data TriChannel > type Frames = [[a]] > data AudioData a = AudioData Frames > adata = [[x] | x <- [...]] :: AudioData SingleChannel I'd like to have a better way of: 1) packing the audio data in something other than a list 2) representing more information about the data parameters (such as sample rate and number of channels) without relying as heavily upon runtime checks/errors (which HCodecs Data.Audio format seems to rely on). The ideal format would be [(a,a,..a)], but this seems cumbersome (since each tuple would have to be defined individually), I'm pretty sure that a runtime check on both sample rate, and number of channels will be necessary, but I just want to ask a little more before continuing down that path. I also noticed that Data.Audio uses a DiffUArray. In this circumstance, would a StorableVector be better, or a DiffUArray? On Sun, Aug 24, 2008 at 1:06 PM, Eric Kidd wrote: > On Sun, Aug 24, 2008 at 12:41 PM, John Van Enk wrote: > > It implements the Haskell bindings to the PortAudio library. This is the > > library behind Audacious. I *have not* implemented the callback model > yet, > > but I plan to do that. > > > > Perhaps this will be something which is useful to you? > > Looks like a great binding! We actually use portaudio in callback mode > at work, with reasonable success (from C++). > > One question: I notice that your writeStream function represents audio > using '[[a]]'. > > writeStream :: (Storable a) => PaStream a -- ^ The output stream > -> [[a]] -- ^ The samples to be played > -> Int -- ^ Number of frames > -> IO (Either String ErrorCode) -- ^ The return status > of the write > > In my experiments, I've been somewhat unsatisfied with the performance > of '[[a]]' as an audio format. Would you be interested in also > supporting an array-based format for audio data? > > I'm currently converting my program to use HCodec's Data.Audio > representation, which looks pretty promising. I don't know how it > performs yet, but I'll let you know. > > Thank you for the pointer to your library! It will make an excellent > addition to the available Haskell sound libraries. > > Cheers, > Eric > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080825/94216718/attachment.htm From jefferson.r.heard at gmail.com Mon Aug 25 14:35:28 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Mon Aug 25 14:34:06 2008 Subject: [Haskell-cafe] OpenGL's VBO with Haskell In-Reply-To: <000001c906da$101468e0$303d3aa0$@com> References: <000001c906da$101468e0$303d3aa0$@com> Message-ID: <4165d3a70808251135m20dd48ecu15d0467187c029e0@mail.gmail.com> That code looks like it ought to work, and I assume if you're using VBOs that you know how to make sure your frustum is setup so that you're object's visible. Are you running this in Windows or in Linux or ? and what version of GHC are you using? There is also a specific HOpenGL mailinglist, just called HOpenGL that you can join by searching for it on the http://haskell.org site. On Mon, Aug 25, 2008 at 1:43 PM, Twinside wrote: > Hi Haskell list, > > Today I'm turning to you for the use of VBO (Vertex Buffer Object) in > Haskell. I seem > to be able to create one without any problem using the following code : > > ------------------------------------------------------ > vboOfList :: Int -> [Float] -> IO BufferObject > vboOfList size elems = > let ptrsize = toEnum $ size * 4 > arrayType = ElementArrayBuffer > in do > [array] <- genObjectNames 1 > bindBuffer arrayType $= Just array > arr <- newListArray (0, size - 1) elems > withStorableArray arr (\ptr -> bufferData arrayType $= (ptrsize, ptr, > StaticDraw)) > bindBuffer ArrayBuffer $= Nothing > reportErrors > return array > ------------------------------------------------------ > > However the problem arise when I try to draw primitives using this vbo : > > ------------------------------------------------------ > displayVbo buff size = do > let stride = toEnum sizeOfVertexInfo > vxDesc = VertexArrayDescriptor 3 Float stride $ offset 0 > colors = VertexArrayDescriptor 4 Float stride $ offset 12 > texCoo = VertexArrayDescriptor 2 Float stride $ offset (12 + 16) > filt = VertexArrayDescriptor 4 Float stride $ offset (12 + 16 + 8) > bindBuffer ArrayBuffer $= Just buff > > arrayPointer VertexArray $= vxDesc > arrayPointer ColorArray $= colors > arrayPointer TextureCoordArray $= texCoo > arrayPointer SecondaryColorArray $= filt > > drawArrays Quads 0 size > bindBuffer ArrayBuffer $= Nothing > ------------------------------------------------------ > > Nothing is displayed on screen. > > As you can see, my VBO contain interleaved data : > - 3 float for the vertex > - 4 for the color > - 2 for the texture coordinate > - 4 for the secondary color) > > The 'offset' function has type Int -> Ptr Float, and is used to forge a > pointer from an Int, to mimic > the C way of using VBO. As far as I've checked, the values in my list for > VBO generation are valid and well > displayed using other techniques. > > So is there a workaround other method for my solution, preferably by keeping > my data interleaved? > Secondly, is there any sample for advanced features like VBOs in Haskell? > > Regards, > Vincent > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From ryani.spam at gmail.com Mon Aug 25 14:36:12 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Aug 25 14:34:50 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: <1219667589.2872.18.camel@localhost.localdomain> References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> Message-ID: <2f9b2d30808251136q60c9d042ue01614a95b37da6d@mail.gmail.com> On Mon, Aug 25, 2008 at 5:33 AM, Hans van Thiel wrote: > The books I use for reference, the Craft and SOE, don't seem to mention > this. I have to confess, I don't really understand the difference > between newtype and data. Again, an explanation would be appreciated. A newtype has no run-time representation; it is an entity at type-checking time, nothing more. data, on the other hand, has a runtime representation. > data D = D Int > newtype N = N Int > d1 = D 1 > n1 = N 1 > i1 = 1 :: Int In memory at runtime, these look different; n1 looks exactly the same as i1. We can represent them both in this way: lit = 1 :: Int# (unlifted, unboxed int) i1 = { tag = I#, content -> lit } n1 = { tag = I#, content -> lit } But d1 is different; it looks like this: d1 = { tag = D, content -> i1 } There's an extra level of indirection between the "data" version and the contents. What does this mean? Well, in particular, you get different behavior in a couple of cases when dealing with "error" (or infinite loops): > u = error "u" > du = D (error "du") > nu = N (error "nu") > ignoreD (D _) = "ok!" > ignoreN (N _) = "ok!" ignoreD u => error "u" ignoreN u => "ok!" ignoreD looks for the "D" tag on its argument, which forces its argument to be evaluated. That fails and you get an error. But "unwrapping" the newtype doesn't do anything; it's just there for typechecking. So there is no error in that case. -- ryan From jefferson.r.heard at gmail.com Mon Aug 25 14:37:51 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Mon Aug 25 14:36:30 2008 Subject: [Haskell-cafe] OpenGL's VBO with Haskell In-Reply-To: <4165d3a70808251135m20dd48ecu15d0467187c029e0@mail.gmail.com> References: <000001c906da$101468e0$303d3aa0$@com> <4165d3a70808251135m20dd48ecu15d0467187c029e0@mail.gmail.com> Message-ID: <4165d3a70808251137m7a3f001r3dea99d78247f123@mail.gmail.com> Oh, and you might try this using Vertex Arrays instead of VBOs. I'll also assume you're checking for the appropriate ARB extensions to make sure VBOs are available on your hardware... If this displays correctly using Vertex Arrays (which can still be interleaved), then I would check your hardware if I were you. On Mon, Aug 25, 2008 at 2:35 PM, Jefferson Heard wrote: > That code looks like it ought to work, and I assume if you're using > VBOs that you know how to make sure your frustum is setup so that > you're object's visible. Are you running this in Windows or in Linux > or ? and what version of GHC are you using? > > There is also a specific HOpenGL mailinglist, just called HOpenGL that > you can join by searching for it on the http://haskell.org site. > > On Mon, Aug 25, 2008 at 1:43 PM, Twinside wrote: >> Hi Haskell list, >> >> Today I'm turning to you for the use of VBO (Vertex Buffer Object) in >> Haskell. I seem >> to be able to create one without any problem using the following code : >> >> ------------------------------------------------------ >> vboOfList :: Int -> [Float] -> IO BufferObject >> vboOfList size elems = >> let ptrsize = toEnum $ size * 4 >> arrayType = ElementArrayBuffer >> in do >> [array] <- genObjectNames 1 >> bindBuffer arrayType $= Just array >> arr <- newListArray (0, size - 1) elems >> withStorableArray arr (\ptr -> bufferData arrayType $= (ptrsize, ptr, >> StaticDraw)) >> bindBuffer ArrayBuffer $= Nothing >> reportErrors >> return array >> ------------------------------------------------------ >> >> However the problem arise when I try to draw primitives using this vbo : >> >> ------------------------------------------------------ >> displayVbo buff size = do >> let stride = toEnum sizeOfVertexInfo >> vxDesc = VertexArrayDescriptor 3 Float stride $ offset 0 >> colors = VertexArrayDescriptor 4 Float stride $ offset 12 >> texCoo = VertexArrayDescriptor 2 Float stride $ offset (12 + 16) >> filt = VertexArrayDescriptor 4 Float stride $ offset (12 + 16 + 8) >> bindBuffer ArrayBuffer $= Just buff >> >> arrayPointer VertexArray $= vxDesc >> arrayPointer ColorArray $= colors >> arrayPointer TextureCoordArray $= texCoo >> arrayPointer SecondaryColorArray $= filt >> >> drawArrays Quads 0 size >> bindBuffer ArrayBuffer $= Nothing >> ------------------------------------------------------ >> >> Nothing is displayed on screen. >> >> As you can see, my VBO contain interleaved data : >> - 3 float for the vertex >> - 4 for the color >> - 2 for the texture coordinate >> - 4 for the secondary color) >> >> The 'offset' function has type Int -> Ptr Float, and is used to forge a >> pointer from an Int, to mimic >> the C way of using VBO. As far as I've checked, the values in my list for >> VBO generation are valid and well >> displayed using other techniques. >> >> So is there a workaround other method for my solution, preferably by keeping >> my data interleaved? >> Secondly, is there any sample for advanced features like VBOs in Haskell? >> >> Regards, >> Vincent >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > I try to take things like a crow; war and chaos don't always ruin a > picnic, they just mean you have to be careful what you swallow. > > -- Jessica Edwards > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From dons at galois.com Mon Aug 25 14:49:18 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 25 14:47:53 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: <2f9b2d30808251136q60c9d042ue01614a95b37da6d@mail.gmail.com> References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> <2f9b2d30808251136q60c9d042ue01614a95b37da6d@mail.gmail.com> Message-ID: <20080825184918.GA30281@scytale.galois.com> ryani.spam: > On Mon, Aug 25, 2008 at 5:33 AM, Hans van Thiel wrote: > > The books I use for reference, the Craft and SOE, don't seem to mention > > this. I have to confess, I don't really understand the difference > > between newtype and data. Again, an explanation would be appreciated. > > A newtype has no run-time representation; it is an entity at > type-checking time, nothing more. data, on the other hand, has a > runtime representation. > > > data D = D Int > > newtype N = N Int > > > d1 = D 1 > > n1 = N 1 > > i1 = 1 :: Int > > In memory at runtime, these look different; n1 looks exactly the same > as i1. We can represent them both in this way: > > lit = 1 :: Int# (unlifted, unboxed int) > i1 = { tag = I#, content -> lit } > n1 = { tag = I#, content -> lit } > > But d1 is different; it looks like this: > > d1 = { tag = D, content -> i1 } > > There's an extra level of indirection between the "data" version and > the contents. What does this mean? Well, in particular, you get > different behavior in a couple of cases when dealing with "error" (or > infinite loops): Though the D tag will be represented as a bit set on the bottom of the thunk pointer in GHC (useful to remember). 'data' tags are cheap. From nielsadb at gmail.com Mon Aug 25 14:54:46 2008 From: nielsadb at gmail.com (Niels Aan de Brugh) Date: Mon Aug 25 14:53:31 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <48B09D4E.1080609@gmail.com> Message-ID: <48B2FFF6.2050708@gmail.com> Christopher Lane Hinson wrote: >> Here's an error the Haskell run-time system might throw: >> *** Exception: Prelude.head: empty list >> (or whatever) >> >> So now what? Action plan = []. > > rgrep " head " . > > Lists 17 items for three projects I've been working on summing to > 10000 lines of haskell. Use listToMaybe or pattern matching and > -Wall, and raise an explicit (error "with explanation"), which is all > good practice in the C world as well. Please, don't make undocumented > use of partial functions in serious code. You're absolutely right, and the compiler can warn the programmer for such mistakes. However, I've found that analysing the run-time behaviour/errors (if they do occur) in a Haskell program to be harder than in a language like C(++) which has many very mature engineering tools available. No doubt this is a matter of time and money, not which language is better suited for "real work". Regards, Niels From jason.dusek at gmail.com Mon Aug 25 15:00:07 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Aug 25 14:58:44 2008 Subject: [Haskell-cafe] can the default instances in GHC be recompiled with overlap? Message-ID: <42784f260808251200x32d8109ew16c0396f73544b6f@mail.gmail.com> Per the GHC manual section on instance overlap: If an instance declaration is compiled without -XOverlappingInstances, then that instance can never be overlapped. This could perhaps be inconvenient. It is inconvenient for certain things. If I want to declare a special `instance Show [MyType] where...` I am out of luck. However, the solution need not involve a change to the way instances are handled -- if all the `GHC.*` instances were compiled with overlapping instances, I'd be able to declare my instance. Is there a substantial barrier, either theoretical or practical, to recompiling GHC this way? -- _jsn |...GHC manual section...| http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap From ben.franksen at online.de Mon Aug 25 15:16:41 2008 From: ben.franksen at online.de (Ben Franksen) Date: Mon Aug 25 15:15:31 2008 Subject: [Haskell-cafe] Re: Re: ANN: First Monad Tutorial of the Season References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> Message-ID: Hans van Thiel wrote: > On Mon, 2008-08-25 at 00:33 +0200, Ben Franksen wrote: >> Hans van Thiel wrote: >> > so 'The Greenhorn's Guide to becoming a Monad Cowboy' is on >> > http://www.muitovar.com/monad/moncow.xhtml >> >> "(Recall that a type definition is just like a data definition, but with >> no choice operator (|).)" First, you mean to say 'newtype', not 'type' >> (as in the code). > Thanks for the feedback. If and when I get some more comments and error > reports, I'll try to fix them. >> Second, a newtype may also contain only one data element (i.e. >> one type expression after the constructor), not many, as in a data type >> definition. > Yes, that's what I thought too, but then I got confused by State s a, > which looks to have two. Could you explain? Most probably you are confusing type and data constructor. This is a common error and a hurdle I remember falling over more than once. It is due to the fact that in Haskell both are in completely separate name spaces, nevertheless both use capitalized names. Thus people often use the same name for both, especially with newtype, as there may only be one data constructor. In your case you have newtype State s a = State { runState :: (s -> (a, s)) } where the type constructor takes two (type-) arguments (even for a newtype it can take as many as you like), but the data constructor takes only one value as argument, namely a function from s to (a,s). Clear now? >> Third, newtype is unlifted. > The books I use for reference, the Craft and SOE, don't seem to mention > this. I have to confess, I don't really understand the difference > between newtype and data. Again, an explanation would be appreciated. Did Ryan's explanation help? > As a general comment on the teaching of Haskell, all books and > tutorials, which I've seen, appear to treat this aspect of Haskell as if > it were self explanatory. This while the better known imperative > languages don't have anything like it. Only Real World Haskell explains > algebraic data types to some satisfaction (IMHO, of course). This is one of the more difficult aspects Haskell, IME. I found the Haskell wiki book (http://en.wikibooks.org/wiki/Haskell) very useful, especially the chapter on denotational semantics (http://en.wikibooks.org/wiki/Haskell/Denotational_semantics). If you have a background in imperative languages, especially low-level ones like C, then it may help to think of the values of a lifted type (data ...) as being represented by a pointer to the data proper (e.g. a struct), whereas values of an unlifted type (newtype ...) are represented exactly as the argument type. A value of a lifted type always has one additional value in its type, namely bottom. You may think of bottom as being represented by a null pointer. In fact, one could say that, in Java, Objects are always lifted whereas basic types like integer are unlifted. Now, before I get shot down by the purists, I know that this is not exactly true, since bottom is also the value of an infinite loop, so Java in fact has a 'real' bottom in addition to null, etc. See the above cited online book chapter for a more precise (and still very readable) treatment. Cheers Ben From sebastian.sylvan at gmail.com Mon Aug 25 15:17:38 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Mon Aug 25 15:16:16 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B2FFF6.2050708@gmail.com> References: <48B09D4E.1080609@gmail.com> <48B2FFF6.2050708@gmail.com> Message-ID: <3d96ac180808251217k740aa616vb4085f6992ea158b@mail.gmail.com> On Mon, Aug 25, 2008 at 7:54 PM, Niels Aan de Brugh wrote: > Christopher Lane Hinson wrote: > >> Here's an error the Haskell run-time system might throw: >>> *** Exception: Prelude.head: empty list >>> (or whatever) >>> >>> So now what? Action plan = []. >>> >> >> rgrep " head " . >> >> Lists 17 items for three projects I've been working on summing to 10000 >> lines of haskell. Use listToMaybe or pattern matching and -Wall, and raise >> an explicit (error "with explanation"), which is all good practice in the C >> world as well. Please, don't make undocumented use of partial functions in >> serious code. >> > You're absolutely right, and the compiler can warn the programmer for such > mistakes. However, I've found that analysing the run-time behaviour/errors > (if they do occur) in a Haskell program to be harder than in a language like > C(++) which has many very mature engineering tools available. No doubt this > is a matter of time and money, not which language is better suited for "real > work". > I sort of agree with this, but I don't think that the total amount of time spent on that activity is even comparable for the two languages. In C/C++ breaking into the debugger and stepping through code is often the easiest way to even understand working code. That's both a testament to the high quality of the visual studio debugger, but it's also an indictment of how difficult it is to understand code written in the language. In Haskell, on the other hand, everything is much more modular and "direct" and if you can't work out what the program does, a little poking in an interactive session will usually get you there far faster then anything you could do in C++. The same goes for tracking down bugs, IMO. It would be nicer to have better traditional debugging tools of course (particularly something that ties into a nice IDE), and I do think this should be a priority, but even then they wouldn't need to be used nearly as often as for C/C++. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080825/3e51280d/attachment.htm From ben.franksen at online.de Mon Aug 25 15:22:53 2008 From: ben.franksen at online.de (Ben Franksen) Date: Mon Aug 25 15:21:47 2008 Subject: [Haskell-cafe] Re: Re: Haskell Propeganda References: <1219523817.7218.12.camel@idefix.localdomain> <7B85E78B-AD4E-4510-93F1-4E417A4AC368@gmail.com> <48B222D4.70709@semantic.org> <20080825035921.GA8011@scytale.galois.com> Message-ID: Don Stewart wrote: > ashley: >> Thomas Davie wrote: >> >I'd be interested to see your other examples -- because that error is >> >not happening in Haskell! You can't argue that Haskell doesn't give you >> >no segfaults, because you can embed a C segfault within Haskell. >> >> This segfaults on my x86_64 Linux box: >> >> module Main where >> import Data.Typeable >> import Data.IORef >> data T = T >> instance Typeable T where >> typeOf _ = typeOf (undefined :: IORef ()) >> main :: IO () >> main = writeIORef (maybe undefined id (cast T)) () >> >> You'll note nothing marked "Foreign" or "unsafe", and only the base >> library used. Does the segfault "happen in Haskell" or not? > > You just wrote unsafeCoere# a different way: > > typeOf T = typeOf (undefined :: IORef ()) > > Manual Typeable deriving should probably be disabled :-) But then we need stand-alone deriving clause, otherwise you are lost if someone didn't derive Typeable in her library. We need stand-alone deriving anyway. Cheers Ben From briqueabraque at yahoo.com Mon Aug 25 15:26:58 2008 From: briqueabraque at yahoo.com (=?windows-1252?Q?Maur=ED=ADcio?=) Date: Mon Aug 25 15:25:54 2008 Subject: [Haskell-cafe] Re: Prototype of a syntax reference In-Reply-To: <48B2C629.7030106@charter.net> References: <48B2C629.7030106@charter.net> Message-ID: >> ? It should be an example of valid code, not good >> one. The idea is to show what can be done, not >> what should :) > > then put lots of semicolons somewhere: while they are at minimum a > separator, it's generally allowed to insert as many extra semicolons as > you want at the beginning, end, or wherever you could put a single > semicolon. > > (I wish the same were true for commas.) > > -Isaac I think I did that at least once (although by mistake). :) Best, Maur?cio From allbery at ece.cmu.edu Mon Aug 25 15:31:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 25 15:29:53 2008 Subject: [Haskell-cafe] can the default instances in GHC be recompiled with overlap? In-Reply-To: <42784f260808251200x32d8109ew16c0396f73544b6f@mail.gmail.com> References: <42784f260808251200x32d8109ew16c0396f73544b6f@mail.gmail.com> Message-ID: <91D60AD1-BB01-4271-9771-DAB417E61ADD@ece.cmu.edu> On Aug 25, 2008, at 15:00 , Jason Dusek wrote: > It is inconvenient for certain things. If I want to declare a > special `instance Show [MyType] where...` I am out of luck. In this particular case, can't you just define showList? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dons at galois.com Mon Aug 25 17:28:28 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 25 17:27:15 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <1218737836.13639.52.camel@localhost> References: <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> <1218737836.13639.52.camel@localhost> Message-ID: <20080825212828.GA742@scytale.galois.com> duncan.coutts: > On Thu, 2008-08-14 at 10:21 -0700, Don Stewart wrote: > > > > I think you're right. The Binary instances cannot and must not read more > > > than they need to, so that gives us the behaviour that we read exactly > > > the length of the file, but no more, and thus we never hit EOF, so we > > > don't close the file. So yes, decode should force the tail so that it > > > can indeed hit EOF. > > > > Duncan, > > > > You're suggesting that decode and decodeFile should whnf the next cell? > > At least decodeFile should, since it doesn't give you any other access > to the file handle otherwise. > > Does decode return the tail? I don't remember. If not it should also > whnf it. If it does then the user can choose (they might want to do > something else with the trailing data). I've pushed a decodeFile that does a whnf on the tail after decoding. If you're at the end of the file, that's sufficient to close the Handle. You'll also need bytestring >= 0.9.1.0 (note, not the one that comes by default with ghc 6.8.x) -- Don From bit at mutantlemon.com Mon Aug 25 17:43:53 2008 From: bit at mutantlemon.com (Bit Connor) Date: Mon Aug 25 17:42:31 2008 Subject: [Haskell-cafe] OpenGL's VBO with Haskell In-Reply-To: <000001c906da$101468e0$303d3aa0$@com> References: <000001c906da$101468e0$303d3aa0$@com> Message-ID: <6205bd290808251443v36a541b3o8ebd30358416c2b5@mail.gmail.com> Hi, I used VBO with haskell and I remember it being pretty straightforward, pretty much the same as in C. This was a while ago and I don't really remember how things work so I can't really comment on your code. But I'll see if I can find my old haskell VBO code. On Mon, Aug 25, 2008 at 8:43 PM, Twinside wrote: > Hi Haskell list, > > Today I'm turning to you for the use of VBO (Vertex Buffer Object) in > Haskell. I seem > to be able to create one without any problem using the following code : > > ------------------------------------------------------ > vboOfList :: Int -> [Float] -> IO BufferObject > vboOfList size elems = > let ptrsize = toEnum $ size * 4 > arrayType = ElementArrayBuffer > in do > [array] <- genObjectNames 1 > bindBuffer arrayType $= Just array > arr <- newListArray (0, size - 1) elems > withStorableArray arr (\ptr -> bufferData arrayType $= (ptrsize, ptr, > StaticDraw)) > bindBuffer ArrayBuffer $= Nothing > reportErrors > return array > ------------------------------------------------------ > > However the problem arise when I try to draw primitives using this vbo : > > ------------------------------------------------------ > displayVbo buff size = do > let stride = toEnum sizeOfVertexInfo > vxDesc = VertexArrayDescriptor 3 Float stride $ offset 0 > colors = VertexArrayDescriptor 4 Float stride $ offset 12 > texCoo = VertexArrayDescriptor 2 Float stride $ offset (12 + 16) > filt = VertexArrayDescriptor 4 Float stride $ offset (12 + 16 + 8) > bindBuffer ArrayBuffer $= Just buff > > arrayPointer VertexArray $= vxDesc > arrayPointer ColorArray $= colors > arrayPointer TextureCoordArray $= texCoo > arrayPointer SecondaryColorArray $= filt > > drawArrays Quads 0 size > bindBuffer ArrayBuffer $= Nothing > ------------------------------------------------------ > > Nothing is displayed on screen. > > As you can see, my VBO contain interleaved data : > - 3 float for the vertex > - 4 for the color > - 2 for the texture coordinate > - 4 for the secondary color) > > The 'offset' function has type Int -> Ptr Float, and is used to forge a > pointer from an Int, to mimic > the C way of using VBO. As far as I've checked, the values in my list for > VBO generation are valid and well > displayed using other techniques. > > So is there a workaround other method for my solution, preferably by keeping > my data interleaved? > Secondly, is there any sample for advanced features like VBOs in Haskell? > > Regards, > Vincent > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jason.dusek at gmail.com Mon Aug 25 18:44:53 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Aug 25 18:43:30 2008 Subject: [Haskell-cafe] can the default instances in GHC be recompiled with overlap? In-Reply-To: <91D60AD1-BB01-4271-9771-DAB417E61ADD@ece.cmu.edu> References: <42784f260808251200x32d8109ew16c0396f73544b6f@mail.gmail.com> <91D60AD1-BB01-4271-9771-DAB417E61ADD@ece.cmu.edu> Message-ID: <42784f260808251544k4153d330ye453995f4f68f07c@mail.gmail.com> Brandon S. Allbery KF8NH wrote: > Jason Dusek wrote: > > > > It is inconvenient for certain things. If I want to declare a > > special `instance Show [MyType] where...` I am out of luck. > > In this particular case, can't you just define showList? Will GHCi use that automatically? Probably not... Nor can I write nice codez with print, printf, &c. I have to use my silly function now. I want to be in the Show typeclass for clarity as well as convenience. -- _jsn From jonathanccast at fastmail.fm Mon Aug 25 18:46:18 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Aug 25 18:48:25 2008 Subject: [Haskell-cafe] can the default instances in GHC be recompiled with overlap? In-Reply-To: <42784f260808251544k4153d330ye453995f4f68f07c@mail.gmail.com> References: <42784f260808251200x32d8109ew16c0396f73544b6f@mail.gmail.com> <91D60AD1-BB01-4271-9771-DAB417E61ADD@ece.cmu.edu> <42784f260808251544k4153d330ye453995f4f68f07c@mail.gmail.com> Message-ID: <1219704378.658.50.camel@jcchost> On Mon, 2008-08-25 at 15:44 -0700, Jason Dusek wrote: > Brandon S. Allbery KF8NH wrote: > > Jason Dusek wrote: > > > > > > It is inconvenient for certain things. If I want to declare a > > > special `instance Show [MyType] where...` I am out of luck. > > > > In this particular case, can't you just define showList? > > Will GHCi use that automatically? Probably not... Nor can I > write nice codez with print, printf, &c. I have to use my > silly function now. I want to be in the Show typeclass for > clarity as well as convenience. showList is a method of the Show type class... http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v% 3AshowList jcc From waterson at maubi.net Mon Aug 25 19:16:05 2008 From: waterson at maubi.net (Chris Waterson) Date: Mon Aug 25 19:14:46 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> Message-ID: On Aug 24, 2008, at 8:41 AM, Eric Kidd wrote: > Greetings, Haskell folks! > > I'm working on a toy program for drum synthesis. This has lead me to > explore the various sound-related libraries in Hackage. Along the > way, > I've learned several things: Hey Erik, I've also created (minimal, for fun) bindings to libmad and OS/X CoreAudio. The original post is here: http://www.haskell.org/pipermail/haskell-cafe/2008-March/040796.html Here is a direct link to the source: http://maubi.net/~waterson/REPO/hmad http://maubi.net/~waterson/REPO/CoreAudio I represented the samples using a lazily generated list of numbers, and it worked pretty well. chris From jason.dusek at gmail.com Mon Aug 25 19:56:12 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Aug 25 19:54:49 2008 Subject: [Haskell-cafe] can the default instances in GHC be recompiled with overlap? In-Reply-To: <1219704378.658.50.camel@jcchost> References: <42784f260808251200x32d8109ew16c0396f73544b6f@mail.gmail.com> <91D60AD1-BB01-4271-9771-DAB417E61ADD@ece.cmu.edu> <42784f260808251544k4153d330ye453995f4f68f07c@mail.gmail.com> <1219704378.658.50.camel@jcchost> Message-ID: <42784f260808251656v71f0dba0le6aa8745a7e49a99@mail.gmail.com> Oh! Thank you -- that turned out to be the right thing. I'm glad someone thought of this already. -- _jsn From marco-oweber at gmx.de Mon Aug 25 20:11:02 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Aug 25 20:09:42 2008 Subject: [Haskell-cafe] How to implement type level type equality? Message-ID: <20080826001102.GA1625@gmx.de> I'm trying to write a validating XML library. I'm struggling with implementnig the choice alternative. Once piece of the code is Where st is the state representing the subelemnts which may still be attached to the current element. (Basically some tree containing Seq, Or, one or more, 0 or more, 0 or 1) Each xml tag is represented by it's own type. el is the element which should be added. (1): match of types, I'd like to return a C(onsumed) (2): no match, I'd like to return a F(ailure) class Consume st el r | st el -> r -- result is on of C,R,F -- element instance Consume ANY el C instance Consume (Elem el) el C -- (1) instance Consume (Elem el') el (F ExpectedButGot el' el) --(2) Of course this results in: || Functional dependencies conflict between instance declarations: Is there a nice way to implement this type level equality function? Of course I could give an instance for each possible comparison instance EQ TAG_A TAG_A HTrue instance EQ TAG_A TAG_DIV HFalse instance EQ TAG_A TAG_HTML HFalse which would work find but would also be a mess if a xml dtd has many elements. (100 elements means 100 * 100 comparisons = 10.000 *shrug*) I fear this slowing down compilation time a way too much. So my current idea is to assign numbers to all tags and do some type level number comparison. This will work resulting in something like this: data Zero data Succ a class Eq a b c | a b -> c instances: Eq (Succ a) Zero HFalse Eq Zero Zero HFalse Eq Zero (Succ a) HFalse Eq (Eq a b c) => (Succ b) (Succ a) c I want to know wether you know about a more elegant solution. Sincerly Marc Weber From briqueabraque at yahoo.com Mon Aug 25 21:15:35 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Aug 25 21:14:27 2008 Subject: [Haskell-cafe] Valid Haskell characters Message-ID: Hi, In Haskell reference, I see the following definitions: uniWhite -> any Unicode character defined as whitespace; uniSmall -> any Unicode lowercase letter; uniLarge -> any uppercase or titlecase Unicode letter; uniSymbol -> any Unicode symbol or punctuation. Where do I get lists for those characters? My first attempt was to check: http://unicode.org/Public/UNIDATA/UnicodeData.txt and consider large anything marked as CAPITAL and small anything marked as SMALL. I didn't know what to guess about the symbols. Am I using the right reference? How can I recognize (or get a list of) valid uppercase and lowercase unicode letters, as well as symbols and punctuation? Thanks for your help, Maur?cio From mutjida at gmail.com Mon Aug 25 21:17:19 2008 From: mutjida at gmail.com (jeff p) Date: Mon Aug 25 21:15:58 2008 Subject: [Haskell-cafe] How to implement type level type equality? In-Reply-To: <20080826001102.GA1625@gmx.de> References: <20080826001102.GA1625@gmx.de> Message-ID: Hello, The HList paper (http://homepages.cwi.nl/~ralf/HList/) presents a reasonable general type level equality (though it requires GHC). The paper also describes some other implementations including the interpretation of types as type-level nats. -Jeff On Mon, Aug 25, 2008 at 8:11 PM, Marc Weber wrote: > I'm trying to write a validating XML library. > I'm struggling with implementnig the choice alternative. > > Once piece of the code is > > Where st is the state representing the subelemnts which may still be > attached to the current element. (Basically some tree containing > Seq, Or, one or more, 0 or more, 0 or 1) > Each xml tag is represented by it's own type. el is the element which > should be added. > > (1): match of types, I'd like to return a C(onsumed) > (2): no match, I'd like to return a F(ailure) > > class Consume st el r | st el -> r -- result is on of C,R,F > > -- element > instance Consume ANY el C > instance Consume (Elem el) el C -- (1) > instance Consume (Elem el') el (F ExpectedButGot el' el) --(2) > > Of course this results in: > || Functional dependencies conflict between instance declarations: > > Is there a nice way to implement this type level equality function? > Of course I could give an instance for each possible comparison > instance EQ TAG_A TAG_A HTrue > instance EQ TAG_A TAG_DIV HFalse > instance EQ TAG_A TAG_HTML HFalse > which would work find but would also be a mess if a xml dtd has many > elements. > (100 elements means 100 * 100 comparisons = 10.000 *shrug*) > I fear this slowing down compilation time a way too much. > > So my current idea is to assign numbers to all tags and do some type > level number comparison. This will work resulting in something like > this: > data Zero > data Succ a > > class Eq a b c | a b -> c > > instances: > Eq (Succ a) Zero HFalse > Eq Zero Zero HFalse > Eq Zero (Succ a) HFalse > Eq (Eq a b c) => (Succ b) (Succ a) c > > I want to know wether you know about a more elegant solution. > > Sincerly > Marc Weber > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dgoldsmith at mac.com Mon Aug 25 21:31:19 2008 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Mon Aug 25 21:29:59 2008 Subject: [Haskell-cafe] Valid Haskell characters In-Reply-To: References: Message-ID: <70268956-B647-43FB-91EA-9C36378E18CD@mac.com> You can't determine Unicode character properties by analyzing the names of the characters. Read chapter 4 of the standard: http://www.unicode.org/versions/Unicode5.0.0/ch04.pdf and get the property values here: http://www.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt It sounds like the properties you want are "Case" and "General Category". Maybe the spec should be more explicit on exactly how the definitions map onto Unicode properties, so there is no ambiguity. Deborah On Aug 25, 2008, at 6:15 PM, Maur? cio wrote: > Hi, > > In Haskell reference, I see the > following definitions: > > uniWhite -> any Unicode character defined > as whitespace; > > uniSmall -> any Unicode lowercase letter; > > uniLarge -> any uppercase or titlecase > Unicode letter; > > uniSymbol -> any Unicode symbol or > punctuation. > > Where do I get lists for those > characters? My first attempt was to > check: > > http://unicode.org/Public/UNIDATA/UnicodeData.txt > > and consider large anything marked as > CAPITAL and small anything marked as SMALL. I > didn't know what to guess about the symbols. > Am I using the right reference? How can I > recognize (or get a list of) valid uppercase and > lowercase unicode letters, as well as symbols > and punctuation? > > Thanks for your help, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From john at repetae.net Mon Aug 25 22:03:26 2008 From: john at repetae.net (John Meacham) Date: Mon Aug 25 22:02:03 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B2D5D9.8020608@iee.org> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> Message-ID: <20080826020325.GB15616@sliver.repetae.net> On Mon, Aug 25, 2008 at 04:55:05PM +0100, Adrian Hey wrote: > (Moving to Haskell cafe) > > Edward Kmett wrote: >> On Sun, Aug 24, 2008 at 7:12 PM, Ashley Yakeley wrote: >> >>> Is there any interest in implementing a top level "<-" to run monadic code? >>> >> >> This is actually implemented in jhc. See the 'top level actions' section of >> http://repetae.net/computer/jhc/manual.html > > Gosh! I was always quite impressed by Johns determination to write a > Haskell compiler and by his self discipline in resisting the temptation > to fix everything that was wrong with Haskell and keep to standards :-) Heh. :) I have not had much time recently to work on jhc. but I hope to pick it up full steam soon. There have been a lot of strong contributers in the community as well. (sigh. day job syndrome). > I implemented my own ACIO monad a while ago (which is of course quite > useless without top level <- bindings) and it turned out that there > was quite a lot that could go in here. Yeah, I based my design on what I thought was the 'community consensus' on how they should look the last time the discussion came up. (not counting those that were adamantly opposed to the idea alltogether ;) ) I forgot who came up with the original ACIO idea, but I'd give them props in the manual if they wish. > The only problem seemed to be that some things that seemed perfectly > reasonable to create via ACIO had *IO* finalisers associated with them, > which didn't feel right to me. But if you think about how finalisers > get run I'm inclined to think we should insist that they are ACIO too. Yeah, this sounds like a great idea. there were a whole lot of issues dealing with finalizers and concurrency, and restricting them in some way similar to ACIO might be good... however, you want something a little weaker than ACIO I think. it must satisfy the ACIO conditions, but _may_ assume its argument (the item being collected) is never referenced again. hence something like 'free' is okay which wouldn't be if other references to the object exist. do you think that is 'formal' enough of a description? seems clear enough if ACIO is well defined which I think it is. John -- John Meacham - ?repetae.net?john? From briqueabraque at yahoo.com Mon Aug 25 22:18:31 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Aug 25 22:17:25 2008 Subject: [Haskell-cafe] Re: Valid Haskell characters In-Reply-To: <70268956-B647-43FB-91EA-9C36378E18CD@mac.com> References: <70268956-B647-43FB-91EA-9C36378E18CD@mac.com> Message-ID: On chapter 4 I see the following nice table in page 139. Do you think I can use it together with UnicodeData.txt to choose valid characters for Haskell? Here is the only place I found where names match with haskell syntax reference (uppercase, lowercase, punctuation, symbol). Thanks, Maur?cio Table 4-7. General Category Lu = Letter, uppercase Ll = Letter, lowercase Lt = Letter, titlecase Lm = Letter, modifier Lo = Letter, other Mn = Mark, nonspacing Mc = Mark, spacing combining Me = Mark, enclosing Nd = Number, decimal digit Nl = Number, letter No = Number, other Pc = Punctuation, connector Pd = Punctuation, dash Ps = Punctuation, open Pe = Punctuation, close Pi = Punctuation, initial quote (may behave like Ps or Pe depending on usage) Pf = Punctuation, final quote (may behave like Ps or Pe depending on usage) Po = Punctuation, other Sm = Symbol, math Sc = Symbol, currency Sk = Symbol, modifier So = Symbol, other Zs = Separator, space Zl = Separator, line Zp = Separator, paragraph Cc = Other, control Cf = Other, format Cs = Other, surrogate Co = Other, private use Cn = Other, not assigned (including noncharacters) Deborah Goldsmith a ?crit : > You can't determine Unicode character properties by analyzing the names > of the characters. > > Read chapter 4 of the standard: > http://www.unicode.org/versions/Unicode5.0.0/ch04.pdf > > and get the property values here: > http://www.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt > > It sounds like the properties you want are "Case" and "General > Category". Maybe the spec should be more explicit on exactly how the > definitions map onto Unicode properties, so there is no ambiguity. > > Deborah > > On Aug 25, 2008, at 6:15 PM, Maur? cio wrote: > >> Hi, >> >> In Haskell reference, I see the >> following definitions: >> >> uniWhite -> any Unicode character defined >> as whitespace; >> >> uniSmall -> any Unicode lowercase letter; >> >> uniLarge -> any uppercase or titlecase >> Unicode letter; >> >> uniSymbol -> any Unicode symbol or >> punctuation. >> >> Where do I get lists for those >> characters? My first attempt was to >> check: >> >> http://unicode.org/Public/UNIDATA/UnicodeData.txt >> >> and consider large anything marked as >> CAPITAL and small anything marked as SMALL. I >> didn't know what to guess about the symbols. >> Am I using the right reference? How can I >> recognize (or get a list of) valid uppercase and >> lowercase unicode letters, as well as symbols >> and punctuation? >> >> Thanks for your help, >> Maur?cio >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe From thomas.dubuisson at gmail.com Tue Aug 26 02:02:59 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Mon Aug 25 23:01:48 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <20080825175750.GD9655@scytale.galois.com> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <1219552290.3996.33.camel@myhost> <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> <1219601010.3996.49.camel@myhost> <20080825081241.GH31645@brakk.ethz.ch> <20080825175750.GD9655@scytale.galois.com> Message-ID: <1219730579.7571.11.camel@myhost> dons: > Simon Marlow sez: > > The thread-ring benchmark needs careful scheduling to get a speedup > on multiple CPUs. I was only able to get a speedup by explicitly > locking half of the ring onto each CPU. You can do this using > GHC.Conc.forkOnIO in GHC 6.8.x, and you'll also need +RTS -qm -qw. > > Also make sure that you're not using the main thread for any part of > the main computation, because the main thread is a bound thread and > runs in its own OS thread, so communication between the main thread > and any other thread is slow. I had to see the results for myself :-) old RTS: 0m54.296s threaded RTS (-N1): 0m56.839s threaded RTS (-N2): 0m52.623s Wow! 3x the performance for a simple change. Frustrating that there isn't a protable/standard way to express this. Also frustrating that the threaded version doesn't improve on the situation (utilization is back at 50%). Anyway, that was a fun miro-benchmark to play with. Tom From dons at galois.com Mon Aug 25 23:10:27 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 25 23:09:06 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <1219730579.7571.11.camel@myhost> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <1219552290.3996.33.camel@myhost> <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> <1219601010.3996.49.camel@myhost> <20080825081241.GH31645@brakk.ethz.ch> <20080825175750.GD9655@scytale.galois.com> <1219730579.7571.11.camel@myhost> Message-ID: <20080826031027.GA1321@scytale.galois.com> thomas.dubuisson: > dons: > > Simon Marlow sez: > > > > The thread-ring benchmark needs careful scheduling to get a speedup > > on multiple CPUs. I was only able to get a speedup by explicitly > > locking half of the ring onto each CPU. You can do this using > > GHC.Conc.forkOnIO in GHC 6.8.x, and you'll also need +RTS -qm -qw. > > > > Also make sure that you're not using the main thread for any part of > > the main computation, because the main thread is a bound thread and > > runs in its own OS thread, so communication between the main thread > > and any other thread is slow. > > I had to see the results for myself :-) > > old RTS: 0m54.296s > threaded RTS (-N1): 0m56.839s > threaded RTS (-N2): 0m52.623s > > Wow! 3x the performance for a simple change. Frustrating that there > isn't a protable/standard way to express this. Also frustrating that > the threaded version doesn't improve on the situation (utilization is > back at 50%). > > Anyway, that was a fun miro-benchmark to play with. Did we gain any insights for submitting to the multicore shootout, http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all (Where I note GHC is currently in second place, though we've not submitted any parallel programs yet). Also CC'd Isaac, Mr. Shootout. Isaac, is the quad core shootout open for business? Should we rally the troops? -- Don From ok at cs.otago.ac.nz Mon Aug 25 23:27:58 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon Aug 25 23:26:37 2008 Subject: [Haskell-cafe] Valid Haskell characters In-Reply-To: <6747_1219714300_m7Q1Vchb023278_70268956-B647-43FB-91EA-9C36378E18CD@mac.com> References: <6747_1219714300_m7Q1Vchb023278_70268956-B647-43FB-91EA-9C36378E18CD@mac.com> Message-ID: <33F6A6B0-D4BC-449E-A955-6EE7FD464401@cs.otago.ac.nz> On 26 Aug 2008, at 1:31 pm, Deborah Goldsmith wrote: > You can't determine Unicode character properties by analyzing the > names of the characters. However, the OP *does* have a copy of the UnicodeData...txt file, and you *can* determine the relevant Unicode character properties from that. For example, consider the entry for space: 0020;SPACE;Zs;0;WS;;;;;N;;;;; ^^ The Zs bit says it's a white space character (Zs: separator/space, Zl: separator/line, Zp: separator/paragraph). Or look at capital A: 0041;LATIN CAPITAL LETTER A;Lu;0;L;;;;;N;;;;0061;^ ^^ The Lu bit says it's a L(etter) that is u(pper case). Upper case: Lu, lower case: Ll, title case: Lt, modifier letter: Lm, other letter: Lo, digit: Nd, ... If memory serves me correctly, this is explained in the UnicodeData.html file, under a heading something like Normative Categories. From dgoldsmith at mac.com Mon Aug 25 23:30:35 2008 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Mon Aug 25 23:29:14 2008 Subject: [Haskell-cafe] Re: Valid Haskell characters In-Reply-To: References: <70268956-B647-43FB-91EA-9C36378E18CD@mac.com> Message-ID: <31237746-8E9E-4DD5-8AD7-E2B376A004E6@mac.com> No, the general category is not enough. Please read both references. As you can tell from DerivedCoreProperties.txt, for example: # Derived Property: Uppercase # Generated from: Lu + Other_Uppercase So general category Lu is not the same thing as "Uppercase" Deborah On Aug 25, 2008, at 7:18 PM, Maur? cio wrote: > On chapter 4 I see the following > nice table in page 139. Do you think > I can use it together with UnicodeData.txt > to choose valid characters for Haskell? > Here is the only place I found where names > match with haskell syntax reference > (uppercase, lowercase, punctuation, symbol). > > Thanks, > Maur?cio > > Table 4-7. General Category > > Lu = Letter, uppercase > Ll = Letter, lowercase > Lt = Letter, titlecase > Lm = Letter, modifier > Lo = Letter, other > Mn = Mark, nonspacing > Mc = Mark, spacing combining > Me = Mark, enclosing > Nd = Number, decimal digit > Nl = Number, letter > No = Number, other > Pc = Punctuation, connector > Pd = Punctuation, dash > Ps = Punctuation, open > Pe = Punctuation, close > Pi = Punctuation, initial quote (may behave like Ps or Pe depending > on usage) > Pf = Punctuation, final quote (may behave like Ps or Pe depending on > usage) > Po = Punctuation, other > Sm = Symbol, math > Sc = Symbol, currency > Sk = Symbol, modifier > So = Symbol, other > Zs = Separator, space > Zl = Separator, line > Zp = Separator, paragraph > Cc = Other, control > Cf = Other, format > Cs = Other, surrogate > Co = Other, private use > Cn = Other, not assigned (including noncharacters) > > > > > Deborah Goldsmith a ?crit : >> You can't determine Unicode character properties by analyzing the >> names of the characters. >> Read chapter 4 of the standard: >> http://www.unicode.org/versions/Unicode5.0.0/ch04.pdf >> and get the property values here: >> http://www.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt >> It sounds like the properties you want are "Case" and "General >> Category". Maybe the spec should be more explicit on exactly how >> the definitions map onto Unicode properties, so there is no >> ambiguity. >> Deborah >> On Aug 25, 2008, at 6:15 PM, Maur? cio wrote: >>> Hi, >>> >>> In Haskell reference, I see the >>> following definitions: >>> >>> uniWhite -> any Unicode character defined >>> as whitespace; >>> >>> uniSmall -> any Unicode lowercase letter; >>> >>> uniLarge -> any uppercase or titlecase >>> Unicode letter; >>> >>> uniSymbol -> any Unicode symbol or >>> punctuation. >>> >>> Where do I get lists for those >>> characters? My first attempt was to >>> check: >>> >>> http://unicode.org/Public/UNIDATA/UnicodeData.txt >>> >>> and consider large anything marked as >>> CAPITAL and small anything marked as SMALL. I >>> didn't know what to guess about the symbols. >>> Am I using the right reference? How can I >>> recognize (or get a list of) valid uppercase and >>> lowercase unicode letters, as well as symbols >>> and punctuation? >>> >>> Thanks for your help, >>> Maur?cio >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dgoldsmith at mac.com Mon Aug 25 23:42:34 2008 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Mon Aug 25 23:41:15 2008 Subject: [Haskell-cafe] Valid Haskell characters In-Reply-To: <33F6A6B0-D4BC-449E-A955-6EE7FD464401@cs.otago.ac.nz> References: <6747_1219714300_m7Q1Vchb023278_70268956-B647-43FB-91EA-9C36378E18CD@mac.com> <33F6A6B0-D4BC-449E-A955-6EE7FD464401@cs.otago.ac.nz> Message-ID: <48B8F98F-60FA-418B-916B-3BFFE6D741DB@mac.com> All characters with general category Lu have the property Uppercase, but the converse is not true. Deborah On Aug 25, 2008, at 8:27 PM, Richard A. O'Keefe wrote: > > On 26 Aug 2008, at 1:31 pm, Deborah Goldsmith wrote: > >> You can't determine Unicode character properties by analyzing the >> names of the characters. > > However, the OP *does* have a copy of the UnicodeData...txt file, > and you *can* determine the relevant Unicode character properties > from that. > > For example, consider the entry for space: > 0020;SPACE;Zs;0;WS;;;;;N;;;;; > ^^ > The Zs bit says it's a white space character > (Zs: separator/space, Zl: separator/line, Zp: > separator/paragraph). > > Or look at capital A: > 0041;LATIN CAPITAL LETTER A;Lu;0;L;;;;;N;;;;0061;^ > ^^ > The Lu bit says it's a L(etter) that is u(pper case). > > Upper case: Lu, lower case: Ll, title case: Lt, > modifier letter: Lm, other letter: Lo, digit: Nd, > ... > > If memory serves me correctly, this is explained in the > UnicodeData.html file, under a heading something like > Normative Categories. > > From briqueabraque at yahoo.com Tue Aug 26 00:04:01 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Aug 26 00:02:49 2008 Subject: [Haskell-cafe] Re: Valid Haskell characters In-Reply-To: <48B8F98F-60FA-418B-916B-3BFFE6D741DB@mac.com> References: <6747_1219714300_m7Q1Vchb023278_70268956-B647-43FB-91EA-9C36378E18CD@mac.com> <33F6A6B0-D4BC-449E-A955-6EE7FD464401@cs.otago.ac.nz> <48B8F98F-60FA-418B-916B-3BFFE6D741DB@mac.com> Message-ID: One may wonder which of them was used in Haskell compilers. Did they take only Lu characters, or were they carefull to accept all Uppercase? Maur?cio Deborah Goldsmith a ?crit : > All characters with general category Lu have the property Uppercase, but > the converse is not true. > > Deborah > > On Aug 25, 2008, at 8:27 PM, Richard A. O'Keefe wrote: > >> >> On 26 Aug 2008, at 1:31 pm, Deborah Goldsmith wrote: >> >>> You can't determine Unicode character properties by analyzing the >>> names of the characters. >> >> However, the OP *does* have a copy of the UnicodeData...txt file, >> and you *can* determine the relevant Unicode character properties from >> that. >> >> For example, consider the entry for space: >> 0020;SPACE;Zs;0;WS;;;;;N;;;;; >> ^^ >> The Zs bit says it's a white space character >> (Zs: separator/space, Zl: separator/line, Zp: >> separator/paragraph). >> >> Or look at capital A: >> 0041;LATIN CAPITAL LETTER A;Lu;0;L;;;;;N;;;;0061;^ >> ^^ >> The Lu bit says it's a L(etter) that is u(pper case). >> >> Upper case: Lu, lower case: Ll, title case: Lt, >> modifier letter: Lm, other letter: Lo, digit: Nd, >> ... >> >> If memory serves me correctly, this is explained in the >> UnicodeData.html file, under a heading something like >> Normative Categories. >> >> From ok at cs.otago.ac.nz Tue Aug 26 00:08:10 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue Aug 26 00:06:50 2008 Subject: [Haskell-cafe] Valid Haskell characters In-Reply-To: <26156_1219722162_m7Q3gd3m002984_48B8F98F-60FA-418B-916B-3BFFE6D741DB@mac.com> References: <6747_1219714300_m7Q1Vchb023278_70268956-B647-43FB-91EA-9C36378E18CD@mac.com> <33F6A6B0-D4BC-449E-A955-6EE7FD464401@cs.otago.ac.nz> <26156_1219722162_m7Q3gd3m002984_48B8F98F-60FA-418B-916B-3BFFE6D741DB@mac.com> Message-ID: <996C6F36-A32F-4462-804C-4F63D1F3C6FA@cs.otago.ac.nz> On 26 Aug 2008, at 3:42 pm, Deborah Goldsmith wrote: > All characters with general category Lu have the property Uppercase, > but the converse is not true. It depends on what the OP wants to do with the information. For example, Unicode Standard Annex 31, http://www.unicode.org/reports/tr31/tr31-9.html is defined in terms of the General Character classification, *not* in terms of the binary properties "Upper", "Alpha", &c. When the Haskell report says uniSmall -> any Unicode lowercase letter uniLarge -> any uppercase or titlecase Unicode letter it is really unclear what definition is meant: are we talking about characters in general category Lu or Lt, or are we talking about characters with the Uppercase property? Since it's _identifiers_, I'd expect UAX#31 to apply, so it should be general category. The specification of the Char module is similarly ambiguous. Since this is *not* about identifiers, I suppose this time the Other_Uppercase characters might well be included. It would be nice to have this spelled out clearly somewhere not too far from the Report on haskell.org. From briqueabraque at yahoo.com Tue Aug 26 00:10:08 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Aug 26 00:09:01 2008 Subject: [Haskell-cafe] 2 modules in one file Message-ID: Hi, Is it allowed to write two different modules in a single file? Something like: module Mod1 (...) where { ... } module Mod2 (...) where { import Mod1; ... } I tried, and got an error, but would like to confirm that there's no way to do that. Thanks, Maur?cio From andy.haskell at zambezi.org.uk Tue Aug 26 00:15:14 2008 From: andy.haskell at zambezi.org.uk (Andy Smith) Date: Tue Aug 26 00:15:14 2008 Subject: [Haskell-cafe] Valid Haskell characters In-Reply-To: <70268956-B647-43FB-91EA-9C36378E18CD@mac.com> References: <70268956-B647-43FB-91EA-9C36378E18CD@mac.com> Message-ID: <5540a5470808252115v470cb52et6b97d9696b39a479@mail.gmail.com> 2008/8/26 Deborah Goldsmith : > It sounds like the properties you want are "Case" and "General Category". > Maybe the spec should be more explicit on exactly how the definitions map > onto Unicode properties, so there is no ambiguity. This is proposed for Haskell'. http://hackage.haskell.org/trac/haskell-prime/wiki/UnicodeInHaskellSource says: "The report should at least be absolutely clear about which Unicode character properties (N, Ll, Lu, Sm, etc.) correspond to which lexical class in the syntax." I don't know if there's any difference in how current Haskell compilers handle this. Andy From ashley at semantic.org Tue Aug 26 00:52:02 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Aug 26 00:50:39 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080826020325.GB15616@sliver.repetae.net> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> Message-ID: <48B38BF2.1050202@semantic.org> John Meacham wrote: > ... if ACIO is well defined which I think it is. Affine: ma >> mb = mb Central: do {a <- ma;b <- mb;return (a,b)} = do {b <- mb;a <- ma;return (a,b)} ...for some concept of "=". Is this correct? Are there any other constraints? From jgm at berkeley.edu Tue Aug 26 02:22:56 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Tue Aug 26 02:21:31 2008 Subject: [Haskell-cafe] ANN: zip-archive 0.0 Message-ID: <20080826062256.GB551@berkeley.edu> I've written a library, zip-archive, for dealing with zip archives. Haddock documentation (with links to source code): http://johnmacfarlane.net/zip-archive/ Darcs repository: http://johnmacfarlane.net/repos/zip-archive/ It comes with an example program that duplicates some of the functionality of 'zip' (configure with '-fexecutable' to build it). I intend to put it on HackageDB, but I thought I'd get some feedback first. Bug reports, patches, and suggestions on the API are all welcome. John From ahey at iee.org Tue Aug 26 03:07:24 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Aug 26 03:06:01 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080826020325.GB15616@sliver.repetae.net> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> Message-ID: <48B3ABAC.5040905@iee.org> John Meacham wrote: > I forgot who came up with the original ACIO idea, but I'd give them > props in the manual if they wish. I think this is based on Ian Starks message.. http://www.haskell.org/pipermail/haskell-cafe/2004-November/007664.html > Yeah, this sounds like a great idea. there were a whole lot of issues > dealing with finalizers and concurrency, and restricting them in some > way similar to ACIO might be good... however, you want something a > little weaker than ACIO I think. it must satisfy the ACIO conditions, > but _may_ assume its argument (the item being collected) is never > referenced again. hence something like 'free' is okay which wouldn't be > if other references to the object exist. do you think that is 'formal' > enough of a description? seems clear enough if ACIO is well defined which I > think it is. Yes, now I cast my mind back that was something that was troubling me. Clearly the one thing you're most likely to want to do in a finaliser is free some external resource, which certainly wouldn't be ACIO ordinarily. But as you say, giving sane semantics and type safety to finalisers is very tricky indeed. I can't help thinking that semantically finaliser execution should be treated like some kind of external event handling, like an interrupt. Not sure what that should be properly, but I think finalisers should be the same. But from a top level aThing <- someACIO point of view, if we're going to say that it doesn't matter if someACIO is executed before main is entered (possibly even at compile time) or on demand, then we clearly don't want to observe any difference between the latter case and the former (if aThing becomes garbage without ever being demanded). Maybe it would be safest to just say anything with a finaliser can't be created at the top level. We can always define an appropriate top level "get" IO action using runOnce or whatever. Regards -- Adrian Hey From judah.jacobson at gmail.com Tue Aug 26 04:14:34 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Aug 26 04:13:12 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B3ABAC.5040905@iee.org> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> Message-ID: <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> On Tue, Aug 26, 2008 at 12:07 AM, Adrian Hey wrote: > > > But from a top level aThing <- someACIO point of view, if we're going to > say that it doesn't matter if someACIO is executed before main is > entered (possibly even at compile time) or on demand, then we clearly > don't want to observe any difference between the latter case and the > former (if aThing becomes garbage without ever being demanded). > > Maybe it would be safest to just say anything with a finaliser can't be > created at the top level. We can always define an appropriate top level > "get" IO action using runOnce or whatever. I've been wondering: is there any benefit to having top-level ACIO'd <- instead of just using runOnce (or perhaps "oneshot") as the primitive for everything? For example: oneshot uniqueRef :: IO (MVar Integer) uniqueRef =< newMVar 0 It was also suggested in that wiki page: http://haskell.org/haskellwiki/Top_level_mutable_state#Proposal_4:_Shared_on-demand_IO_actions_.28oneShots.29 Those proposals eliminate the need for creating an ACIO monad and enforcing its axioms, since one-shot actions are executed in-line with other I/O actions (rather than at some nebulous "before the program is run" time). So, in the context of top-level initializers, does ACIO offer something beyond what oneshot provides on its own? If not, I prefer the latter since it seems like a much simpler solution. Best, -Judah From wren at freegeek.org Tue Aug 26 04:19:49 2008 From: wren at freegeek.org (wren ng thornton) Date: Tue Aug 26 04:18:29 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: <1219667589.2872.18.camel@localhost.localdomain> References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> Message-ID: <48B3BCA5.7010502@freegeek.org> Hans van Thiel wrote: > As a general comment on the teaching of Haskell, all books and > tutorials, which I've seen, appear to treat this aspect of Haskell as if > it were self explanatory. This while the better known imperative > languages don't have anything like it. Only Real World Haskell explains > algebraic data types to some satisfaction (IMHO, of course). (Hopefully this different take on it helps more than it hurts...) In addition to keeping the type-level and the value-level separated, Haskell does a little bit to keep the type/interface-level and the implementation-level separate. The "data" keyword introduces both a new type and also a new implementation. This is the only way of introducing new implementations. ADTs are beauty incarnate, but unfortunately not well known outside of functional languages and abstract algebra. The "newtype" keyword introduces a new type, but it reuses an old implementation under the covers. Even though they have the same underlying implementation, the newtype and the type of the old implementation are considered entirely different semantically and so one cannot be used in lieu of the other. The dubiously named "type" keyword introduces an alias shorthand for some type that already exists. These aliases are, in a sense, never checked; that is, the macro is just expanded. This means that we can't carry any additional semantic information by using aliases and so if we have: type Celsius = Int type Fahrenheit = Int ...the type checker will do nothing to save us. If we wanted to add semantic tags to the Int type in order to say what units the number represents, then we could do that with a "newtype" and the type checker would ensure that we didn't mix units. Re "data" vs "newtype", where a newtype is possible (single data constructor, which has exactly one argument) there are still a few differences at the semantic level. Since a newtype's data constructor doesn't exist at runtime, evaluating a newtype to WHNF will evaluate the argument to WHNF; hence a newtype can be thought of as the data version with an obligatory strictness annotation. In terms of bottom, this means that: data Foo = Foo Int ...has both _|_ and (Foo _|_). Whereas, both of the following: data Foo = Foo !Int newtype Foo = Foo Int ...have only _|_. It should also be noted that the overhead for newtypes is not *always* removed. In particular, if we have the following definitions: data Z = Z newtype S a = S a We must keep the tags (i.e. boxes) for S around because (S Z) and (S (S Z)) need to be distinguishable. This only really comes up with polymorphic newtypes (since that enables recursion), and it highlights the difference between strict fields and unpacked strict fields. Typically newtypes are unpacked as well as strict (hence no runtime tag overhead), but it's not guaranteed. Another operational difference between newtypes and an equivalent data declaration has to do with the type class dictionaries. IIRC, with GeneralizedNewtypeDeriving the newtype actually uses the exact same dictionaries as the underlying type, thus avoiding unwrapping/rewrapping overhead. I'm somewhat fuzzy on all the details here, bit its another reason to use newtypes when you can. -- Live well, ~wren From ashley at semantic.org Tue Aug 26 06:02:09 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Aug 26 06:00:45 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B3ABAC.5040905@iee.org> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> Message-ID: <48B3D4A1.80104@semantic.org> Adrian Hey wrote: > Maybe it would be safest to just say anything with a finaliser can't be > created at the top level. Do you have an example of something that is correctly ACIO to create, but has a problematic finaliser? -- Ashley Yakeley From frank at geoinfo.tuwien.ac.at Tue Aug 26 06:06:08 2008 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Tue Aug 26 06:04:43 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class In-Reply-To: <1219680537.14617.12.camel@bernH> References: <1219680537.14617.12.camel@bernH> Message-ID: <1219745168.14617.21.camel@bernH> in fairness, i have to add that i did inadvertetly install version 0.3. of syb-with-class and got the error i still cannot understand. installing version 0.4 did work flawlessly! nevertheless, i would be interested to understand the problem i encountered. andrew On Mon, 2008-08-25 at 18:08 +0200, Andrew U. Frank wrote: > i tried to install wxGeneric and need syb-with-class. > i got the package from hackage. > configure runs fine, but when i build i get: > > Data/Generics/SYB/WithClass/Instances.hs:11:7: > Could not find module `Data.Array': > it is a member of package array-0.1.0.0, which is hidden > > but array-0.1.0.0 is installed, as shown later. > what can be wrong? why is an installed package complained about as > hidden? > > thanks for help! > > andrew > > frank@bernH:~/haskellSources/packages/syb-with-class-0.3$ ghc-pkg > describe array > name: array > version: 0.1.0.0 > license: BSD3 > copyright: > maintainer: libraries@haskell.org > stability: > homepage: > package-url: > description: This package defines the classes @IArray@ of immutable > arrays and > @MArray@ of arrays mutable within appropriate monads, as > well as > some instances of these classes. > category: > author: > exposed: True > exposed-modules: Data.Array Data.Array.Base Data.Array.Diff > Data.Array.IArray Data.Array.IO Data.Array.MArray > Data.Array.ST > Data.Array.Storable Data.Array.Unboxed > hidden-modules: Data.Array.IO.Internals > import-dirs: /usr/lib/ghc-6.8.2/lib/array-0.1.0.0 > library-dirs: /usr/lib/ghc-6.8.2/lib/array-0.1.0.0 > hs-libraries: HSarray-0.1.0.0 > extra-libraries: > extra-ghci-libraries: > include-dirs: > includes: > depends: base-3.0.1.0 > hugs-options: > cc-options: > ld-options: > framework-dirs: > frameworks: > haddock-interfaces: /usr/share/doc/ghc6-doc/libraries/array/array.haddock > haddock-html: /usr/share/doc/ghc6-doc/libraries/array > f > From ashley at semantic.org Tue Aug 26 06:15:37 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Aug 26 06:14:13 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> Message-ID: <48B3D7C9.6060308@semantic.org> Judah Jacobson wrote: > I've been wondering: is there any benefit to having top-level ACIO'd > <- instead of just using runOnce (or perhaps "oneshot") as the > primitive for everything? I don't think oneshots are very good for open witness declarations (such as the open exceptions I mentioned originally), since there are pure functions that do useful things with them. Not sure about TVars either, which operate in the STM monad. Would you also need a oneshotSTM (or a class)? -- Ashley Yakeley From marco-oweber at gmx.de Tue Aug 26 06:45:11 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Aug 26 06:43:50 2008 Subject: [Haskell-cafe] 2 modules in one file In-Reply-To: References: Message-ID: <20080826104511.GB1625@gmx.de> > Is it allowed to write two > different modules in a single > file? Something like: > > module Mod1 (...) where { > ... > } > > module Mod2 (...) where { > import Mod1; > ... > } > > I tried, and got an error, > but would like to confirm > that there's no way to do > that. No, that's not possible because haskell will use the module name A.B.C to look the module up in path A/B/C.[l]hs. So using modules module A where .. module B where the compiler could only find one of them. (naming the file A.hs or B.hs) You have to use one file for each module I think there is another tool somewhere to merge many modules into one. But I don't think that's what you're looking for. (I haven't tried that myself) Marc Weber From thomas.dubuisson at gmail.com Tue Aug 26 11:12:43 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Tue Aug 26 08:11:32 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <20080826031027.GA1321@scytale.galois.com> References: <7ca3f0160808231101o52929366lb659e84a724e21d4@mail.gmail.com> <1219552290.3996.33.camel@myhost> <9D612A29-E679-4A0E-AF5D-B5C1022D03C0@gmail.com> <1219601010.3996.49.camel@myhost> <20080825081241.GH31645@brakk.ethz.ch> <20080825175750.GD9655@scytale.galois.com> <1219730579.7571.11.camel@myhost> <20080826031027.GA1321@scytale.galois.com> Message-ID: <1219763563.7571.15.camel@myhost> > > Wow! 3x the performance for a simple change. Frustrating that there > > isn't a protable/standard way to express this. Also frustrating that > > the threaded version doesn't improve on the situation (utilization is > > back at 50%). GRrrrr, retraction, retraction! I was obviously too tired when I posted this. In generallizing the system to take run-time specified number of CPUs (for forkOnIO) and tokens the behavior changed from my 3 minute runs. I'll play with it more tonight. Thomas From bjorn at bringert.net Tue Aug 26 09:01:03 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Tue Aug 26 08:59:39 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: References: Message-ID: 2008/8/24 Daryoush Mehrtash : > I am trying to convert a string to a float. It seems that Data.ByteString > library only supports readInt. After some googling I came accross a > possibloe implementation: http://sequence.svcs.cs.pdx.edu/node/373 > > My questions are: > > a) is there a standard library implementation of string -> Double and float? > b) Why is it that the ByteString only supports readInt? Is there a reason > for it? Hi Daryoush, are you really looking for ByteString -> Float conversion, or just plain String -> Float? The latter is really simple, the function is called 'read' and is available in the Prelude: $ ghci GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> read "3.14" :: Float 3.14 /Bjorn From duncan.coutts at worc.ox.ac.uk Tue Aug 26 09:22:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 26 09:20:42 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class In-Reply-To: <1219745168.14617.21.camel@bernH> References: <1219680537.14617.12.camel@bernH> <1219745168.14617.21.camel@bernH> Message-ID: <1219756960.24846.9.camel@localhost> On Tue, 2008-08-26 at 12:06 +0200, Andrew U. Frank wrote: > in fairness, i have to add that i did inadvertetly install version 0.3. > of syb-with-class and got the error i still cannot understand. > > installing version 0.4 did work flawlessly! > > nevertheless, i would be interested to understand the problem i > encountered. The error message unfortunately refers to the mechanism and not the cause. When Cabal builds a package it tells ghc to hide every package and then use only the packages listed in the build-depends field: ghc --make -hide-all-packages -package base-3.0.1.0 ... etc So when ghc finds that one of your modules needs to import something that is not in one of the given packages it says that it's in another package that is 'hidden'. Of course it's only hidden because Cabal told ghc to hide them. So what the error message really means is that you're missing a package from the build-depends field in the .cabal file. The error message will improve when Cabal does it's own dependency chasing, but don't hold your breath. Duncan From dougal at dougalstanton.net Tue Aug 26 09:30:30 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Tue Aug 26 09:29:17 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class In-Reply-To: <1219756960.24846.9.camel@localhost> References: <1219680537.14617.12.camel@bernH> <1219745168.14617.21.camel@bernH> <1219756960.24846.9.camel@localhost> Message-ID: <2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> On Tue, Aug 26, 2008 at 2:22 PM, Duncan Coutts wrote: > So when ghc finds that one of your modules needs to import something > that is not in one of the given packages it says that it's in another > package that is 'hidden'. Of course it's only hidden because Cabal told > ghc to hide them. Yes, it is one of those unfortunate error messages that says "I know what the problem is *and* how to fix it, but I'm not going to". ;-) Cheers, Dougal From daveroundy at gmail.com Tue Aug 26 09:54:19 2008 From: daveroundy at gmail.com (David Roundy) Date: Tue Aug 26 09:52:55 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <200808240015.57217.daniel.is.fischer@web.de> References: <200808240015.57217.daniel.is.fischer@web.de> Message-ID: <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> On Sat, Aug 23, 2008 at 6:15 PM, Daniel Fischer wrote: > Am Samstag, 23. August 2008 23:17 schrieb Thomas Davie: >> >> I'd be interested to see your other examples -- because that error is >> not happening in Haskell! You can't argue that Haskell doesn't give >> you no segfaults, because you can embed a C segfault within Haskell. > > Use ST(U)Arrays, and use unsafeWrite because you do the indexchecking > yourself. Then be stupid and confuse two bounds so that you actually write > beyond the array bounds. > I've had that happen _once_. > But if you explicitly say you want it unsafe, you're prepared for it :) Which illustrates the point that it's not type safety that protects us from segfaults, so much as bounds checking, and that's got a non-trivial runtime cost. At least, most segfaults that *I've* caused (in C or C++) have been from overwriting the bounds of arrays, and that's precisely the problem that Haskell does *not* solve using its type system. There have attempts to do so, but I've not heard of instances where they have been used in real programs. David From duncan.coutts at worc.ox.ac.uk Tue Aug 26 10:09:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 26 10:08:01 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class In-Reply-To: <2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> References: <1219680537.14617.12.camel@bernH> <1219745168.14617.21.camel@bernH> <1219756960.24846.9.camel@localhost> <2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> Message-ID: <1219759788.24846.23.camel@localhost> On Tue, 2008-08-26 at 14:30 +0100, Dougal Stanton wrote: > On Tue, Aug 26, 2008 at 2:22 PM, Duncan Coutts > wrote: > > > So when ghc finds that one of your modules needs to import something > > that is not in one of the given packages it says that it's in another > > package that is 'hidden'. Of course it's only hidden because Cabal told > > ghc to hide them. > > Yes, it is one of those unfortunate error messages that says "I know > what the problem is *and* how to fix it, but I'm not going to". ;-) ?Actually it's more like: ?"I know what the problem is but I cannot fix it. He knows how to fix it, but doesn't know there's a problem!" :-) GHC knows what the problem is but it's just following orders. Cabal gave the orders but doesn't know there is a problem. That's why it'll be fixed when Cabal does the dep chasing rather than delegating that to ghc --make. Cabal will then be able to either just pull in the (probably) right packages, or report the problem using the language of the problem domain and not the implementation. Duncan From claus.reinke at talk21.com Tue Aug 26 10:53:12 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Aug 26 10:51:52 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class References: <1219680537.14617.12.camel@bernH><1219745168.14617.21.camel@bernH> <1219756960.24846.9.camel@localhost><2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> <1219759788.24846.23.camel@localhost> Message-ID: <017801c9078b$781795f0$94407ad5@cr3lt> >> > So when ghc finds that one of your modules needs to import something >> > that is not in one of the given packages it says that it's in another >> > package that is 'hidden'. Of course it's only hidden because Cabal told >> > ghc to hide them. >> >> Yes, it is one of those unfortunate error messages that says "I know >> what the problem is *and* how to fix it, but I'm not going to". ;-) > > ?Actually it's more like: ?"I know what the problem is but I cannot fix > it. He knows how to fix it, but doesn't know there's a problem!" :-) > > GHC knows what the problem is but it's just following orders. Cabal gave > the orders but doesn't know there is a problem. Since you said "don't hold your breath for Cabal's dependencies": Cabal doesn't have to pass on ghc's messages uninterpreted. That's a lot like implementing a map as a list and complaining about empty list instead of element not found. Cabal is the interface here, ghc is the tool. The interface shouldn't just pass instructions to the tool, it should also interpret and present the tool's responses. As suggested in this thread: http://www.haskell.org/pipermail/cabal-devel/2007-December/001497.html http://www.haskell.org/pipermail/cabal-devel/2007-December/001499.html Hmm, the archive failed to decode the code sketch attached to the last message there (which demonstrated that some basic help could be hacked up as a simple pattern->message script wrapping cabal), so I attach the old code again for reference. Claus -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal.hs Type: application/octet-stream Size: 2462 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080826/ec2773a7/cabal.obj From hthiel.char at zonnet.nl Tue Aug 26 11:23:26 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Tue Aug 26 11:22:47 2008 Subject: [Haskell-cafe] Re: Re: ANN: First Monad Tutorial of the Season In-Reply-To: References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> Message-ID: <1219764206.3715.11.camel@localhost.localdomain> [snip] > > Most probably you are confusing type and data constructor. This is a common > error and a hurdle I remember falling over more than once. It is due to the > fact that in Haskell both are in completely separate name spaces, > nevertheless both use capitalized names. Thus people often use the same > name for both, especially with newtype, as there may only be one data > constructor. In your case you have > > newtype State s a = State { runState :: (s -> (a, s)) } > > where the type constructor takes two (type-) arguments (even for a newtype > it can take as many as you like), but the data constructor takes only one > value as argument, namely a function from s to (a,s). > > Clear now? A newtype has only one data constructor, a data definition may have more (when it contains a choice (|) operator). That's clear now. > > >> Third, newtype is unlifted. > > The books I use for reference, the Craft and SOE, don't seem to mention > > this. I have to confess, I don't really understand the difference > > between newtype and data. Again, an explanation would be appreciated. > > Did Ryan's explanation help? > > > As a general comment on the teaching of Haskell, all books and > > tutorials, which I've seen, appear to treat this aspect of Haskell as if > > it were self explanatory. This while the better known imperative > > languages don't have anything like it. Only Real World Haskell explains > > algebraic data types to some satisfaction (IMHO, of course). > > This is one of the more difficult aspects Haskell, IME. I found the Haskell > wiki book (http://en.wikibooks.org/wiki/Haskell) very useful, especially > the chapter on denotational semantics > (http://en.wikibooks.org/wiki/Haskell/Denotational_semantics). > The wikibook has a lot of good material, IMO. I'll certainly read that chapter. > If you have a background in imperative languages, especially low-level ones > like C, then it may help to think of the values of a lifted type (data ...) > as being represented by a pointer to the data proper (e.g. a struct), > whereas values of an unlifted type (newtype ...) are represented exactly as > the argument type. That makes sense to me. Thanks, everybody! > A value of a lifted type always has one additional value > in its type, namely bottom. You may think of bottom as being represented by > a null pointer. In fact, one could say that, in Java, Objects are always > lifted whereas basic types like integer are unlifted. > > Now, before I get shot down by the purists, I know that this is not exactly > true, since bottom is also the value of an infinite loop, so Java in fact > has a 'real' bottom in addition to null, etc. See the above cited online > book chapter for a more precise (and still very readable) treatment. > > Cheers > Ben > > From frank at geoinfo.tuwien.ac.at Tue Aug 26 11:43:50 2008 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Tue Aug 26 11:42:29 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class In-Reply-To: <1219759788.24846.23.camel@localhost> References: <1219680537.14617.12.camel@bernH> <1219745168.14617.21.camel@bernH> <1219756960.24846.9.camel@localhost> <2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> <1219759788.24846.23.camel@localhost> Message-ID: <1219765430.14617.40.camel@bernH> thank you very much for the explanation! i take that in this case, the error is in the cabal, which does not list the required package. andrew On Tue, 2008-08-26 at 15:09 +0100, Duncan Coutts wrote: > On Tue, 2008-08-26 at 14:30 +0100, Dougal Stanton wrote: > > On Tue, Aug 26, 2008 at 2:22 PM, Duncan Coutts > > wrote: > > > > > So when ghc finds that one of your modules needs to import something > > > that is not in one of the given packages it says that it's in another > > > package that is 'hidden'. Of course it's only hidden because Cabal told > > > ghc to hide them. > > > > Yes, it is one of those unfortunate error messages that says "I know > > what the problem is *and* how to fix it, but I'm not going to". ;-) > > ?Actually it's more like: ?"I know what the problem is but I cannot fix > it. He knows how to fix it, but doesn't know there's a problem!" :-) > > GHC knows what the problem is but it's just following orders. Cabal gave > the orders but doesn't know there is a problem. > > That's why it'll be fixed when Cabal does the dep chasing rather than > delegating that to ghc --make. Cabal will then be able to either just > pull in the (probably) right packages, or report the problem using the > language of the problem domain and not the implementation. > > Duncan > From twinside at gmail.com Tue Aug 26 12:18:39 2008 From: twinside at gmail.com (Twinside) Date: Tue Aug 26 12:17:20 2008 Subject: [Haskell-cafe] OpenGL's VBO with Haskell In-Reply-To: <6205bd290808251443v36a541b3o8ebd30358416c2b5@mail.gmail.com> References: <000001c906da$101468e0$303d3aa0$@com> <6205bd290808251443v36a541b3o8ebd30358416c2b5@mail.gmail.com> Message-ID: <000001c90797$6756fce0$3604f6a0$@com> First thanks you two for the reply. Now for the solution, I'm a bit ashamed of myself, because I simply forgot to put a clientState VertexArray $= Enabled The rest of the code is valid beside this 'little' miss -----Message d'origine----- De?: mutantlemon@gmail.com [mailto:mutantlemon@gmail.com] De la part de Bit Connor Envoy??: lundi 25 ao?t 2008 23:44 ??: Twinside Cc?: haskell-cafe@haskell.org Objet?: Re: [Haskell-cafe] OpenGL's VBO with Haskell Hi, I used VBO with haskell and I remember it being pretty straightforward, pretty much the same as in C. This was a while ago and I don't really remember how things work so I can't really comment on your code. But I'll see if I can find my old haskell VBO code. On Mon, Aug 25, 2008 at 8:43 PM, Twinside wrote: > Hi Haskell list, > > Today I'm turning to you for the use of VBO (Vertex Buffer Object) in > Haskell. I seem > to be able to create one without any problem using the following code : > > ------------------------------------------------------ > vboOfList :: Int -> [Float] -> IO BufferObject > vboOfList size elems = > let ptrsize = toEnum $ size * 4 > arrayType = ElementArrayBuffer > in do > [array] <- genObjectNames 1 > bindBuffer arrayType $= Just array > arr <- newListArray (0, size - 1) elems > withStorableArray arr (\ptr -> bufferData arrayType $= (ptrsize, ptr, > StaticDraw)) > bindBuffer ArrayBuffer $= Nothing > reportErrors > return array > ------------------------------------------------------ > > However the problem arise when I try to draw primitives using this vbo : > > ------------------------------------------------------ > displayVbo buff size = do > let stride = toEnum sizeOfVertexInfo > vxDesc = VertexArrayDescriptor 3 Float stride $ offset 0 > colors = VertexArrayDescriptor 4 Float stride $ offset 12 > texCoo = VertexArrayDescriptor 2 Float stride $ offset (12 + 16) > filt = VertexArrayDescriptor 4 Float stride $ offset (12 + 16 + 8) > bindBuffer ArrayBuffer $= Just buff > > arrayPointer VertexArray $= vxDesc > arrayPointer ColorArray $= colors > arrayPointer TextureCoordArray $= texCoo > arrayPointer SecondaryColorArray $= filt > > drawArrays Quads 0 size > bindBuffer ArrayBuffer $= Nothing > ------------------------------------------------------ > > Nothing is displayed on screen. > > As you can see, my VBO contain interleaved data : > - 3 float for the vertex > - 4 for the color > - 2 for the texture coordinate > - 4 for the secondary color) > > The 'offset' function has type Int -> Ptr Float, and is used to forge a > pointer from an Int, to mimic > the C way of using VBO. As far as I've checked, the values in my list for > VBO generation are valid and well > displayed using other techniques. > > So is there a workaround other method for my solution, preferably by keeping > my data interleaved? > Secondly, is there any sample for advanced features like VBOs in Haskell? > > Regards, > Vincent > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bulat.ziganshin at gmail.com Tue Aug 26 12:18:47 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Aug 26 12:24:50 2008 Subject: [Haskell-cafe] Re[2]: [Haskell] Top Level <- In-Reply-To: <1219767261.5868.0.camel@derek-laptop> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> Message-ID: <1568927011.20080826201847@gmail.com> Hello Derek, Tuesday, August 26, 2008, 8:14:21 PM, you wrote: >> but from my POV it's important to push this feature into haskell >> standard > Haskell should be moving -toward- a capability-like model, not away from > it. what you mean by "capability-like model"? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From derek.a.elkins at gmail.com Tue Aug 26 12:28:26 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Aug 26 12:27:05 2008 Subject: [Haskell-cafe] Re: Re[2]: [Haskell] Top Level <- In-Reply-To: <1568927011.20080826201847@gmail.com> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <1568927011.20080826201847@gmail.com> Message-ID: <1219768106.5868.2.camel@derek-laptop> On Tue, 2008-08-26 at 20:18 +0400, Bulat Ziganshin wrote: > Hello Derek, > > Tuesday, August 26, 2008, 8:14:21 PM, you wrote: > > >> but from my POV it's important to push this feature into haskell > >> standard > > > Haskell should be moving -toward- a capability-like model, not away from > > it. > > what you mean by "capability-like model"? http://erights.org/elib/capability/index.html From ryani.spam at gmail.com Tue Aug 26 12:45:33 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Aug 26 12:44:10 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: <48B3BCA5.7010502@freegeek.org> References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> <48B3BCA5.7010502@freegeek.org> Message-ID: <2f9b2d30808260945j43f26d2aua4a988880e875869@mail.gmail.com> On Tue, Aug 26, 2008 at 1:19 AM, wren ng thornton wrote: > It should also be noted that the overhead for newtypes is not *always* > removed. In particular, if we have the following definitions: > > data Z = Z > newtype S a = S a > > We must keep the tags (i.e. boxes) for S around because (S Z) and (S (S Z)) > need to be distinguishable. This only really comes up with polymorphic > newtypes (since that enables recursion), and it highlights the difference > between strict fields and unpacked strict fields. Typically newtypes are > unpacked as well as strict (hence no runtime tag overhead), but it's not > guaranteed. Is this true? (S Z) and (S (S Z)) only need to be distinguished during typechecking. This would be different if it was some sort of existential type: > newtype N = forall a. Num a => N a but GHC at least disallows existential boxes in newtypes. -- ryan From dmehrtash at gmail.com Tue Aug 26 13:27:35 2008 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Tue Aug 26 13:26:11 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: References: Message-ID: Bjorn, I am initializing a list from a file. I am reading the lines from the file, splitting them into bytestring and then converting them to float. Should I be using String -> Float or ByteString -> Float? thanks Daryoush On Tue, Aug 26, 2008 at 6:01 AM, Bjorn Bringert wrote: > 2008/8/24 Daryoush Mehrtash : > > I am trying to convert a string to a float. It seems that > Data.ByteString > > library only supports readInt. After some googling I came accross a > > possibloe implementation: http://sequence.svcs.cs.pdx.edu/node/373 > > > > My questions are: > > > > a) is there a standard library implementation of string -> Double and > float? > > b) Why is it that the ByteString only supports readInt? Is there a reason > > for it? > > Hi Daryoush, > > are you really looking for ByteString -> Float conversion, or just > plain String -> Float? The latter is really simple, the function is > called 'read' and is available in the Prelude: > > $ ghci > GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> read "3.14" :: Float > 3.14 > > /Bjorn > / -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080826/8cf6ef51/attachment.htm From dons at galois.com Tue Aug 26 13:32:16 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 26 13:30:49 2008 Subject: [Haskell-cafe] String to Double conversion in Haskell In-Reply-To: References: Message-ID: <20080826173216.GA3200@scytale.galois.com> dmehrtash: > Bjorn, > I am initializing a list from a file. I am reading the lines from the > file, splitting them into bytestring and then converting them to float. > Should I be using String -> Float or ByteString -> Float? I'd try reading the file entirely as a bytestring, then splitting out the Doubles, using ByteString -> Float. -- Don From ahey at iee.org Tue Aug 26 13:34:38 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Aug 26 13:33:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219767261.5868.0.camel@derek-laptop> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> Message-ID: <48B43EAE.1050207@iee.org> I have a feeling this is going to be a very long thread so I'm trying to go to Haskell cafe again (without mucking it up again). Derek Elkins wrote: > Haskell should be moving -toward- a capability-like model, not away from > it. Could you show how to implement Data.Random or Data.Unique using such a model, or any (preferably all) of the use cases identified can be implemented? Like what about implementing the socket API starting with nothing but primitives to peek/poke ethernet mac and dma controller registers? Why should Haskell should be moving -toward- a capability-like model and why does top level <- declarations take us away from it? Regards -- Adrian Hey From igouy2 at yahoo.com Tue Aug 26 13:39:27 2008 From: igouy2 at yahoo.com (Isaac Gouy) Date: Tue Aug 26 13:38:03 2008 Subject: [Haskell-cafe] Haskell Speed Myth Message-ID: <256721.56318.qm@web65407.mail.ac4.yahoo.com> > dons: > (Where I note GHC is currently in second place, though we've not > submitted any parallel programs yet). We might call that the thread-ring effect :-) > Also CC'd Isaac, Mr. Shootout. Isaac, is the quad core shootout > open for business? Should we rally the troops? iirc there was some discussion after the last GHC release about cleaning up the programs to make them less low-level given the improved capabilities of the compiler - I don't think that ever happened, and "low level" seems to be a common complaint against the Haskell programs shown in the benchmarks game. As Simon Peyton-Jones suggested we're certainly open for suggestions: http://groups.google.com/group/fa.haskell/browse_thread/thread/7eb82c689de8688/4f3c47b976394666?lnk=st&q=alioth+shootout#4f3c47b976394666 However, we're operating new measurement scripts on both u64q (published) and gp4 (unpublished), and my focus is still on catching up to where we were with measurements from the old scripts, and installing third-party libraries on u64q. From wren at freegeek.org Tue Aug 26 13:39:43 2008 From: wren at freegeek.org (wren ng thornton) Date: Tue Aug 26 13:38:19 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: <2f9b2d30808260945j43f26d2aua4a988880e875869@mail.gmail.com> References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> <48B3BCA5.7010502@freegeek.org> <2f9b2d30808260945j43f26d2aua4a988880e875869@mail.gmail.com> Message-ID: <4817.192.12.13.2.1219772383.squirrel@mail.freegeek.org> Ryan Ingram wrote: > wren ng thornton wrote: >> It should also be noted that the overhead for newtypes is not *always* >> removed. In particular, if we have the following definitions: >> >> data Z = Z >> newtype S a = S a >> >> We must keep the tags (i.e. boxes) for S around because (S Z) and (S (S Z)) >> need to be distinguishable. This only really comes up with polymorphic >> newtypes (since that enables recursion), and it highlights the difference >> between strict fields and unpacked strict fields. Typically newtypes are >> unpacked as well as strict (hence no runtime tag overhead), but it's not >> guaranteed. > > Is this true? (S Z) and (S (S Z)) only need to be distinguished > during typechecking. > > This would be different if it was some sort of existential type: >> newtype N = forall a. Num a => N a > but GHC at least disallows existential boxes in newtypes. They only need to be distinguished at type checking time, true; but if you have a function that takes peano integers (i.e. is polymorphic over Z and (S a) from above) then you need to keep around enough type information to know which specialization of the function to take. The problem is that the polymorphism means that you can't do full type erasure because there's a type variable you need to keep track of. >From my experiments looking at memory usage, the above declarations take the same amount of memory as a pure ADT, which means linear in the value of the peano integer. It may be that I misinterpreted the results, but I see no other way to deal with polymorphic newtypes so I'm pretty sure this is what's going on. -- Live well, ~wren From dons at galois.com Tue Aug 26 13:47:02 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 26 13:45:32 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <256721.56318.qm@web65407.mail.ac4.yahoo.com> References: <256721.56318.qm@web65407.mail.ac4.yahoo.com> Message-ID: <20080826174702.GB3200@scytale.galois.com> igouy2: > > dons: > > > (Where I note GHC is currently in second place, though we've not > > submitted any parallel programs yet). > > We might call that the thread-ring effect :-) > > > > Also CC'd Isaac, Mr. Shootout. Isaac, is the quad core shootout > > open for business? Should we rally the troops? > > iirc there was some discussion after the last GHC release about > cleaning up the programs to make them less low-level given the improved > capabilities of the compiler - I don't think that ever happened, and > "low level" seems to be a common complaint against the Haskell programs > shown in the benchmarks game. > > As Simon Peyton-Jones suggested we're certainly open for suggestions: > > http://groups.google.com/group/fa.haskell/browse_thread/thread/7eb82c689de8688/4f3c47b976394666?lnk=st&q=alioth+shootout#4f3c47b976394666 > > However, we're operating new measurement scripts on both u64q > (published) and gp4 (unpublished), and my focus is still on catching up > to where we were with measurements from the old scripts, and installing > third-party libraries on u64q. So still consolidating the system. Do I understand though, that if we submit, say, a quad-core version of binary-trees, for example, using `par` and -N4, it'll go live on the benchmark page? -- Don From lennart at augustsson.net Tue Aug 26 13:55:24 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Aug 26 13:54:07 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B43EAE.1050207@iee.org> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> Message-ID: Making a network stack from peek and poke is easy in a well structured OS. The boot loader (or whatever) hands you the capability (call it something else if you want) to do raw hardware access, and you build from there. If you look at well structured OSs like NetBSD, this is pretty much how they work. No hardware drivers use global variables. -- Lennart On Tue, Aug 26, 2008 at 6:34 PM, Adrian Hey wrote: > I have a feeling this is going to be a very long thread so I'm trying > to go to Haskell cafe again (without mucking it up again). > > Derek Elkins wrote: >> >> Haskell should be moving -toward- a capability-like model, not away from >> it. > > Could you show how to implement Data.Random or Data.Unique using such a > model, or any (preferably all) of the use cases identified can be > implemented? Like what about implementing the socket API starting with > nothing but primitives to peek/poke ethernet mac and dma controller > registers? > > Why should Haskell should be moving -toward- a capability-like model and > why does top level <- declarations take us away from it? > > Regards > -- > Adrian Hey > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From igouy2 at yahoo.com Tue Aug 26 13:57:48 2008 From: igouy2 at yahoo.com (Isaac Gouy) Date: Tue Aug 26 13:56:23 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <20080826174702.GB3200@scytale.galois.com> Message-ID: <618875.73550.qm@web65401.mail.ac4.yahoo.com> --- Don Stewart wrote: -snip- > So still consolidating the system. Pretty much. > Do I understand though, that if we submit, say, a quad-core version > of > binary-trees, for example, using `par` and -N4, it'll go live on the > benchmark page? That's an open question - should it? How should the benchmarks game approach multicore? From dons at galois.com Tue Aug 26 14:01:28 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 26 13:59:58 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <618875.73550.qm@web65401.mail.ac4.yahoo.com> References: <20080826174702.GB3200@scytale.galois.com> <618875.73550.qm@web65401.mail.ac4.yahoo.com> Message-ID: <20080826180128.GD3200@scytale.galois.com> igouy2: > > --- Don Stewart wrote: > > -snip- > > > So still consolidating the system. > > Pretty much. > > > > Do I understand though, that if we submit, say, a quad-core version > > of > > binary-trees, for example, using `par` and -N4, it'll go live on the > > benchmark page? > > That's an open question - should it? > > How should the benchmarks game approach multicore? Well, there's a famous paper, Algorithm + Strategy = Parallelism I'd imagine we use the benchmark game's algorithms, but let submitters determine the strategy. Then the results would show a) how well you utilize the cores, and b) overall wall clock results. I'm keen to get going on this, if only because I think we can turn out parallelised versions of many of the existing programs, fairly cheaply. -- Don From derek.a.elkins at gmail.com Tue Aug 26 14:10:34 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Aug 26 14:09:14 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B43EAE.1050207@iee.org> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> Message-ID: <1219774234.5868.20.camel@derek-laptop> On Tue, 2008-08-26 at 18:34 +0100, Adrian Hey wrote: > I have a feeling this is going to be a very long thread so I'm trying > to go to Haskell cafe again (without mucking it up again). > > Derek Elkins wrote: > > Haskell should be moving -toward- a capability-like model, not away from > > it. > > Could you show how to implement Data.Random or Data.Unique using such a > model, or any (preferably all) of the use cases identified can be > implemented? Like what about implementing the socket API starting with > nothing but primitives to peek/poke ethernet mac and dma controller > registers? Data.Random and Data.Unique are trivial. Already the immutable interfaces are fine. You could easily pass around a mutable object holding the state if you didn't want to be curtailed into a State monad. If you have full access to the DMA controller your language is not even memory safe. This is not a common situation for most developers. I have no trouble requiring people who want to hack OSes having to use implementation-specific extensions as they have to do today in any other language. However, this is only a problem for capabilities (as the capability model requires memory safety,) not for a language lacking top-level mutable state. Access to the DMA controller and the Ethernet interface can still be passed in, it doesn't need to be a top-level action. There are entire operating systems built around capability models, so it is certainly possible to do these things. > > Why should Haskell should be moving -toward- a capability-like model and > why does top level <- declarations take us away from it? Answering the second question first: mutable global variables are usually -explicitly- disallowed from a capability model. To answer your first question: safety, security, analyzability, encapsulation, locality are all things that Haskell strives for. Personally, I think that every language should be moving in this direction as much as possible, but the Haskell culture, in particular, emphasizes these things. It's notable that O'Haskell and Timber themselves moved toward a capability model. From lemming at henning-thielemann.de Tue Aug 26 14:11:37 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Aug 26 14:10:15 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: On Mon, 25 Aug 2008, John Van Enk wrote: > How well would the storablevector package (Data.StorableVector) work for > storing audio data? One of the major issues I'm still working over is that I > want to maintain something similar to a [[a]] format (since the underlying > PortAudio library and hardware could support hundreds of interleaved > channels) but I would like to be able to build in some typechecking to the > functions to make sure the number of channels matches the nubmer expected in > the functions. With data Stereo a = Stereo !a !a you could also use Stereo (Stereo a) for quadrophony and so on. Would this be convenient enough? StorableVector stores everything of fixed length for which a Storable instance is defined. From lennart at augustsson.net Tue Aug 26 14:16:53 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Aug 26 14:15:27 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: <4817.192.12.13.2.1219772383.squirrel@mail.freegeek.org> References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> <48B3BCA5.7010502@freegeek.org> <2f9b2d30808260945j43f26d2aua4a988880e875869@mail.gmail.com> <4817.192.12.13.2.1219772383.squirrel@mail.freegeek.org> Message-ID: The values Z, S Z, and S (S Z) all have the same runtime representation and there is no linear increase in size when you add a extra S. BUT, if you make something overloaded and there is a dictionary associated with the type (Z, S Z, or S (S Z)) then the dictionary takes up space, and that space is linear in the number of S constructors. -- Lennart On Tue, Aug 26, 2008 at 6:39 PM, wren ng thornton wrote: > Ryan Ingram wrote: >> wren ng thornton wrote: >>> It should also be noted that the overhead for newtypes is not *always* >>> removed. In particular, if we have the following definitions: >>> >>> data Z = Z >>> newtype S a = S a >>> >>> We must keep the tags (i.e. boxes) for S around because (S Z) and (S (S > Z)) >>> need to be distinguishable. This only really comes up with polymorphic >>> newtypes (since that enables recursion), and it highlights the difference >>> between strict fields and unpacked strict fields. Typically newtypes are >>> unpacked as well as strict (hence no runtime tag overhead), but it's not >>> guaranteed. >> >> Is this true? (S Z) and (S (S Z)) only need to be distinguished >> during typechecking. >> >> This would be different if it was some sort of existential type: >>> newtype N = forall a. Num a => N a >> but GHC at least disallows existential boxes in newtypes. > > They only need to be distinguished at type checking time, true; but if you > have a function that takes peano integers (i.e. is polymorphic over Z and > (S a) from above) then you need to keep around enough type information to > know which specialization of the function to take. The problem is that the > polymorphism means that you can't do full type erasure because there's a > type variable you need to keep track of. > > >From my experiments looking at memory usage, the above declarations take > the same amount of memory as a pure ADT, which means linear in the value > of the peano integer. It may be that I misinterpreted the results, but I > see no other way to deal with polymorphic newtypes so I'm pretty sure this > is what's going on. > > -- > Live well, > ~wren > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From vanenkj at gmail.com Tue Aug 26 14:30:20 2008 From: vanenkj at gmail.com (John Van Enk) Date: Tue Aug 26 14:28:55 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: I think the problem I'll run into is the 128 channel case. I'm hoping for a general solution... I'm almost positive this will require runtime checks. Your solution is what I was thinking for functions requiring exactly N channels (I'm not sure if there are many functions like that). On Tue, Aug 26, 2008 at 2:11 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Mon, 25 Aug 2008, John Van Enk wrote: > > How well would the storablevector package (Data.StorableVector) work for >> storing audio data? One of the major issues I'm still working over is that >> I >> want to maintain something similar to a [[a]] format (since the underlying >> PortAudio library and hardware could support hundreds of interleaved >> channels) but I would like to be able to build in some typechecking to the >> functions to make sure the number of channels matches the nubmer expected >> in >> the functions. >> > > With > data Stereo a = Stereo !a !a > > you could also use > Stereo (Stereo a) > for quadrophony and so on. Would this be convenient enough? > > StorableVector stores everything of fixed length for which a Storable > instance is defined. > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080826/8176d142/attachment.htm From judah.jacobson at gmail.com Tue Aug 26 16:16:48 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Aug 26 16:15:24 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B3D7C9.6060308@semantic.org> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> <48B3D7C9.6060308@semantic.org> Message-ID: <6d74b0d20808261316k1c234edi51c0831c8c33d1d5@mail.gmail.com> On Tue, Aug 26, 2008 at 3:15 AM, Ashley Yakeley wrote: > Judah Jacobson wrote: >> >> I've been wondering: is there any benefit to having top-level ACIO'd >> <- instead of just using runOnce (or perhaps "oneshot") as the >> primitive for everything? > > I don't think oneshots are very good for open witness declarations (such as > the open exceptions I mentioned originally), since there are pure functions > that do useful things with them. I think you're saying that you want to write "w <- newIOWitness" at the top level, so that w can then be referenced in a pure function. Fair enough. But newIOWitness's implementation requires writeIORef (or an equivalent), which is not ACIO, right? I suppose you could call unsafeIOToACIO, but if that function is used often it seems to defeat the purpose of defining an ACIO monad in the first place. > Not sure about TVars either, which operate in the STM monad. Would you also > need a oneshotSTM (or a class)? Interesting point; I think you can work around it, but it does make the code a little more complicated. For example: oneshot uniqueVar :: IO (TVar Integer) uniqueVar =< atomically $ newTVar 0 -- alternately, use newTVarIO uniqueIntSTM :: IO (STM Integer) uniqueIntSTM = uniqueVar >>= \v -> return $ do n <- readTVar v writeTVar v (n+1) return n getUniqueInt :: IO Integer getUniqueInt = uniqueIntSTM >>= atomically -Judah From brianchina60221 at gmail.com Tue Aug 26 16:35:28 2008 From: brianchina60221 at gmail.com (brian) Date: Tue Aug 26 16:34:03 2008 Subject: [Haskell-cafe] Parsec and network data Message-ID: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Hi, I've been struggling with this problem for days and I'm dying. Please help. I want to use Parsec to parse NNTP data coming to me from a handle I get from connectTo. One unworkable approach I tried is to get a lazy String from the handle with hGetContents. The problem: suppose the first message from the NNTP server is "200 OK\r\n". Parsec parses it beautifully. Now I need to discard the parsed part so that Parsec will parse whatever the server sends next, so I use Parsec's getInput to get the remaining data. But there isn't any, so it blocks. Deadlock: the client is inappropriately waiting for server data and the server is waiting for my first command. Another approach that doesn't quite work is to create an instance of Parsec's Stream with timeout functionality: instance Stream Handle IO Char where uncons h = do r <- hWaitForInput h ms if r then liftM (\c -> Just (c, h)) (hGetChar h) else return Nothing where ms = 5000 It's probably obvious to you why it doesn't work, but it wasn't to me at first. The problem: suppose you tell parsec you're looking for (many digit) followed by (string "\r\n"). "123\r\n" won't match; "123\n" will. My Stream has no backtracking. Even if you don't need 'try', it won't work for even basic stuff. Here's another way: http://www.mail-archive.com/haskell-cafe@haskell.org/msg22385.html The OP had the same problem I did, so he made a variant of hGetContents with timeout support. The problem: he used something from unsafe*. I came to Haskell for rigor and reliability and it would make me really sad to have to use a function with 'unsafe' in its name that has a lot of wacky caveats about inlining, etc. In that same thread, Bulat says a timeout-enabled Stream could help. But I can't tell what library that is. 'cabal list stream' shows me 3 libraries none of which seems to be the one in question. Is Streams a going concern? Should I be checking that out? I'm not doing anything with hGetLine because 1) there's no way to specify a maximum number of characters to read 2) what is meant by a "line" is not specified 3) there is no way to tell if it read a line or just got to the end of the data. Even using something like hGetLine that worked better would make the parsing more obscure. Thank you very very much for *any* help. From vanenkj at gmail.com Tue Aug 26 16:38:40 2008 From: vanenkj at gmail.com (John Van Enk) Date: Tue Aug 26 16:37:15 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Message-ID: Are you doing this all in a single thread? On Tue, Aug 26, 2008 at 4:35 PM, brian wrote: > Hi, I've been struggling with this problem for days and I'm dying. Please > help. > > I want to use Parsec to parse NNTP data coming to me from a handle I > get from connectTo. > > One unworkable approach I tried is to get a lazy String from the > handle with hGetContents. The problem: suppose the first message from > the NNTP server is "200 OK\r\n". Parsec parses it beautifully. Now I > need to discard the parsed part so that Parsec will parse whatever the > server sends next, so I use Parsec's getInput to get the remaining > data. But there isn't any, so it blocks. Deadlock: the client is > inappropriately waiting for server data and the server is waiting for > my first command. > > Another approach that doesn't quite work is to create an instance of > Parsec's Stream with timeout functionality: > > instance Stream Handle IO Char where > uncons h = > do r <- hWaitForInput h ms > if r > then liftM (\c -> Just (c, h)) (hGetChar h) > else return Nothing > where ms = 5000 > > It's probably obvious to you why it doesn't work, but it wasn't to me > at first. The problem: suppose you tell parsec you're looking for > (many digit) followed by (string "\r\n"). "123\r\n" won't match; > "123\n" will. My Stream has no backtracking. Even if you don't need > 'try', it won't work for even basic stuff. > > Here's another way: > http://www.mail-archive.com/haskell-cafe@haskell.org/msg22385.html > The OP had the same problem I did, so he made a variant of > hGetContents with timeout support. The problem: he used something from > unsafe*. I came to Haskell for rigor and reliability and it would make > me really sad to have to use a function with 'unsafe' in its name that > has a lot of wacky caveats about inlining, etc. > > In that same thread, Bulat says a timeout-enabled Stream could help. > But I can't tell what library that is. 'cabal list stream' shows me 3 > libraries none of which seems to be the one in question. Is Streams a > going concern? Should I be checking that out? > > I'm not doing anything with hGetLine because 1) there's no way to > specify a maximum number of characters to read 2) what is meant by a > "line" is not specified 3) there is no way to tell if it read a line > or just got to the end of the data. Even using something like hGetLine > that worked better would make the parsing more obscure. > > Thank you very very much for *any* help. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080826/7bd0c505/attachment.htm From brianchina60221 at gmail.com Tue Aug 26 16:40:10 2008 From: brianchina60221 at gmail.com (brian) Date: Tue Aug 26 16:38:46 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Message-ID: <22f6a8f70808261340p32375829y97891dbc6c899733@mail.gmail.com> On Tue, Aug 26, 2008 at 3:38 PM, John Van Enk wrote: > Are you doing this all in a single thread? Yes. From vanenkj at gmail.com Tue Aug 26 16:43:45 2008 From: vanenkj at gmail.com (John Van Enk) Date: Tue Aug 26 16:42:20 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <22f6a8f70808261340p32375829y97891dbc6c899733@mail.gmail.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <22f6a8f70808261340p32375829y97891dbc6c899733@mail.gmail.com> Message-ID: Perhaps you'll want to continue with the hGetLine setup in one thread (assuming the NNTP data is line delimited), then in another, parse the data, then in a third, respond. Lookup how to use MVar's. Allowing the threads to block on reads/writes is a lot easier (logically) than figuring out the mess in a single threaded system. When you have a system like Haskell's threading tools, you're much better off splitting the tasks up into blocking calls with MVar's to synchronize. (Perhaps MVar's aren't quite the correct solution here, but it seems like it would work to me.) On Tue, Aug 26, 2008 at 4:40 PM, brian wrote: > On Tue, Aug 26, 2008 at 3:38 PM, John Van Enk wrote: > > Are you doing this all in a single thread? > > Yes. > -- /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080826/58b2e682/attachment.htm From ahey at iee.org Tue Aug 26 16:47:18 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Aug 26 16:45:56 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> Message-ID: <48B46BD6.30604@iee.org> Lennart Augustsson wrote: > Making a network stack from peek and poke is easy in a well structured OS. > The boot loader (or whatever) hands you the capability (call it > something else if you want) to do raw hardware access, and you build > from there. If you look at well structured OSs like NetBSD, this is > pretty much how they work. No hardware drivers use global variables. So? We all know this is possible outside Haskell. But I don't want to rely on mysterious black box OS's to "hand me the capability" any more than I want to rely on mysterious extant but unimplementable libs like Data.Unique. Most real world computing infrastructure uses no OS at all. How could I use Haskell to implement such systems? Also (to mis-quote Linus Torvalds) could you or anyone else who agrees with you please SHOW ME THE CODE in *Haskell*! If scripture is all that's on offer I'm just not going to take any of you seriously. Frankly I'm tired of the patronising lectures that always acompany these threads. It'd be good if someone who "knows" global variables are evil could put their code where their mouth is for a change. Fixing up the base libs to eliminate the dozen or so uses of the "unsafePerformIO hack" might be a good place to start. I'll even let you change the API of these libs if you must, provided you can give a sensible explanation why the revised API is better, safer, more convenient or whatever. Regards -- Adrian Hey From jeremy at n-heptane.com Tue Aug 26 17:46:20 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Aug 26 17:39:52 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Message-ID: <87abezfo0j.wl%jeremy@n-heptane.com> Hello, Polyparse has some lazy parsers: http://www.cs.york.ac.uk/fp/polyparse/ Perhaps that would do the trick? j. At Tue, 26 Aug 2008 15:35:28 -0500, brian wrote: > > Hi, I've been struggling with this problem for days and I'm dying. Please help. > > I want to use Parsec to parse NNTP data coming to me from a handle I > get from connectTo. > > One unworkable approach I tried is to get a lazy String from the > handle with hGetContents. The problem: suppose the first message from > the NNTP server is "200 OK\r\n". Parsec parses it beautifully. Now I > need to discard the parsed part so that Parsec will parse whatever the > server sends next, so I use Parsec's getInput to get the remaining > data. But there isn't any, so it blocks. Deadlock: the client is > inappropriately waiting for server data and the server is waiting for > my first command. > > Another approach that doesn't quite work is to create an instance of > Parsec's Stream with timeout functionality: > > instance Stream Handle IO Char where > uncons h = > do r <- hWaitForInput h ms > if r > then liftM (\c -> Just (c, h)) (hGetChar h) > else return Nothing > where ms = 5000 > > It's probably obvious to you why it doesn't work, but it wasn't to me > at first. The problem: suppose you tell parsec you're looking for > (many digit) followed by (string "\r\n"). "123\r\n" won't match; > "123\n" will. My Stream has no backtracking. Even if you don't need > 'try', it won't work for even basic stuff. > > Here's another way: > http://www.mail-archive.com/haskell-cafe@haskell.org/msg22385.html > The OP had the same problem I did, so he made a variant of > hGetContents with timeout support. The problem: he used something from > unsafe*. I came to Haskell for rigor and reliability and it would make > me really sad to have to use a function with 'unsafe' in its name that > has a lot of wacky caveats about inlining, etc. > > In that same thread, Bulat says a timeout-enabled Stream could help. > But I can't tell what library that is. 'cabal list stream' shows me 3 > libraries none of which seems to be the one in question. Is Streams a > going concern? Should I be checking that out? > > I'm not doing anything with hGetLine because 1) there's no way to > specify a maximum number of characters to read 2) what is meant by a > "line" is not specified 3) there is no way to tell if it read a line > or just got to the end of the data. Even using something like hGetLine > that worked better would make the parsing more obscure. > > Thank you very very much for *any* help. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From newsham at lava.net Tue Aug 26 17:49:51 2008 From: newsham at lava.net (Tim Newsham) Date: Tue Aug 26 17:48:26 2008 Subject: [Haskell-cafe] contributing to standard library Message-ID: Like everyone else who has used Haskell for a while, I'm accumulating functions which I feel should have already been in the standard libraries. What's the normal path to contributing functions for consideration in future standard libraries? Is there some experimental standard lib that we can contribute to to "try out" for the big league? Here are some functions: http://www.thenewsh.com/%7Enewsham/x/machine/Missing.hs Tim Newsham http://www.thenewsh.com/~newsham/ From allbery at ece.cmu.edu Tue Aug 26 17:52:39 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Aug 26 17:51:22 2008 Subject: [Haskell-cafe] contributing to standard library In-Reply-To: References: Message-ID: <6B350D07-780F-41FF-BDF1-18360B675B95@ece.cmu.edu> On 2008 Aug 26, at 17:49, Tim Newsham wrote: > Like everyone else who has used Haskell for a while, I'm accumulating > functions which I feel should have already been in the standard > libraries. What's the normal path to contributing functions for > consideration in future standard libraries? Is there some > experimental standard lib that we can contribute to to "try > out" for the big league? > > Here are some functions: > http://www.thenewsh.com/%7Enewsham/x/machine/Missing.hs I think MissingH has served for that in the past. The official route is libraries@haskell.org. -- 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 bos at serpentine.com Tue Aug 26 17:55:41 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Aug 26 17:54:16 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080825212828.GA742@scytale.galois.com> References: <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> <1218737836.13639.52.camel@localhost> <20080825212828.GA742@scytale.galois.com> Message-ID: On Mon, Aug 25, 2008 at 2:28 PM, Don Stewart wrote: > I've pushed a decodeFile that does a whnf on the tail after decoding. Does this mean that there are now NFData instances for bytestrings? That would be handy. From waldmann at imn.htwk-leipzig.de Tue Aug 26 17:57:43 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Aug 26 17:56:21 2008 Subject: [Haskell-cafe] contributing to standard library In-Reply-To: References: Message-ID: <48B47C57.9000807@imn.htwk-leipzig.de> > functions which I feel should have already been in the standard > libraries. have you tried searching with "hoogle" for the types of your functions. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080826/da691f26/signature.bin From dons at galois.com Tue Aug 26 18:04:22 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 26 18:02:55 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> <1218737836.13639.52.camel@localhost> <20080825212828.GA742@scytale.galois.com> Message-ID: <20080826220422.GI3200@scytale.galois.com> bos: > On Mon, Aug 25, 2008 at 2:28 PM, Don Stewart wrote: > > > I've pushed a decodeFile that does a whnf on the tail after decoding. > > Does this mean that there are now NFData instances for bytestrings? > That would be handy. No, since I can get whnf with `seq`. However, that does sound like a good idea (a patch to the parallel library? ) From ashley at semantic.org Tue Aug 26 18:07:21 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Aug 26 18:05:56 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <6d74b0d20808261316k1c234edi51c0831c8c33d1d5@mail.gmail.com> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> <48B3D7C9.6060308@semantic.org> <6d74b0d20808261316k1c234edi51c0831c8c33d1d5@mail.gmail.com> Message-ID: <1219788441.10665.0.camel@sherbourne> Judah Jacobson wrote: > I think you're saying that you want to write "w <- newIOWitness" at > the top level, so that w can then be referenced in a pure function. > Fair enough. But newIOWitness's implementation requires writeIORef > (or an equivalent), which is not ACIO, right? newIOWitness is very like newUnique. In both cases, the internal implementation updates an MVar to make them unique. Internally the open-witness package would use unsafeIOtoACIO (just as it already uses unsafeCoerce), but an exposed newIOWitnessACIO would be safe. > oneshot uniqueVar :: IO (TVar Integer) > uniqueVar =< atomically $ newTVar 0 -- alternately, use newTVarIO > > uniqueIntSTM :: IO (STM Integer) > uniqueIntSTM = uniqueVar >>= \v -> return $ do > n <- readTVar v > writeTVar v (n+1) > return n > > getUniqueInt :: IO Integer > getUniqueInt = uniqueIntSTM >>= atomically This complicates the purpose of STM, which is to make composable STM transactions. I would rather do this: uniqueVar :: TVar Integer uniqueVar <- newTVarACIO uniqueInt :: STM Integer uniqueInt = do n <- readTVar uniqueVar writeTVar uniqueVar (n+1) return n AFAICT, one-shots are less powerful and just as complicated as an ACIO monad. -- Ashley Yakeley From judah.jacobson at gmail.com Tue Aug 26 18:11:45 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Aug 26 18:10:19 2008 Subject: [Haskell-cafe] contributing to standard library In-Reply-To: References: Message-ID: <6d74b0d20808261511s688fcf5fne3b64f135963163b@mail.gmail.com> On Tue, Aug 26, 2008 at 2:49 PM, Tim Newsham wrote: > Like everyone else who has used Haskell for a while, I'm accumulating > functions which I feel should have already been in the standard > libraries. What's the normal path to contributing functions for > consideration in future standard libraries? Is there some > experimental standard lib that we can contribute to to "try > out" for the big league? > > Here are some functions: > http://www.thenewsh.com/%7Enewsham/x/machine/Missing.hs > The official process for proposing a change to the standard libraries is documented at: http://www.haskell.org/haskellwiki/Library_submissions -Judah From lemming at henning-thielemann.de Tue Aug 26 18:17:09 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Aug 26 18:15:42 2008 Subject: [Haskell-cafe] Haskell audio libraries & audio formats In-Reply-To: References: <431341160808240841j254aefe1se0e5c254c4bdc339@mail.gmail.com> <431341160808241006t7ce726a7h724882b5a8ae0d65@mail.gmail.com> Message-ID: On Tue, 26 Aug 2008, John Van Enk wrote: > I think the problem I'll run into is the 128 channel case. I'm hoping for a > general solution... I'm almost positive this will require runtime checks. > Your solution is what I was thinking for functions requiring exactly N > channels (I'm not sure if there are many functions like that). If the number of channels is variable it might be better to use a list of StorableVectors instead. I think it is more common to process the channels separately instead of simultaneously. From bos at serpentine.com Tue Aug 26 18:31:02 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Aug 26 18:29:37 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: <20080826220422.GI3200@scytale.galois.com> References: <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> <1218737836.13639.52.camel@localhost> <20080825212828.GA742@scytale.galois.com> <20080826220422.GI3200@scytale.galois.com> Message-ID: On Tue, Aug 26, 2008 at 3:04 PM, Don Stewart wrote: > No, since I can get whnf with `seq`. However, that does sound like a > good idea (a patch to the parallel library? ) I suspect that patching parallel doesn't scale. It doesn't have a maintainer, so it will be slow, and the package will end up dragging in everything under the sun if we centralise instances in there. I think that the instance belongs in bytestring instead. I know that this would make everything depend on parallel, but that doesn't seem as bad a problem. From brianchina60221 at gmail.com Tue Aug 26 18:52:57 2008 From: brianchina60221 at gmail.com (brian) Date: Tue Aug 26 18:51:32 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <22f6a8f70808261340p32375829y97891dbc6c899733@mail.gmail.com> Message-ID: <22f6a8f70808261552o1e86e6c1g7288ba5e4027f180@mail.gmail.com> On Tue, Aug 26, 2008 at 3:43 PM, John Van Enk wrote: > Perhaps you'll want to continue with the hGetLine setup in one thread > (assuming the NNTP data is line delimited), then in another, parse the data, > then in a third, respond. Sorry if my writing was unclear. I think hGetLine is really unsuited for doing anything with data from a network. It's like the Haskell equivalent of gets(3). I think it's only suitable for quick tests or toy programs. The only way I can think to make it a little safer is to wrap it in a timeout, and that'd still be really bad. From duncan.coutts at worc.ox.ac.uk Tue Aug 26 16:01:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 26 19:28:32 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class In-Reply-To: <017801c9078b$781795f0$94407ad5@cr3lt> References: <1219680537.14617.12.camel@bernH> <1219745168.14617.21.camel@bernH> <1219756960.24846.9.camel@localhost> <2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> <1219759788.24846.23.camel@localhost> <017801c9078b$781795f0$94407ad5@cr3lt> Message-ID: <1219780914.24846.48.camel@localhost> On Tue, 2008-08-26 at 15:53 +0100, Claus Reinke wrote: > > GHC knows what the problem is but it's just following orders. Cabal gave > > the orders but doesn't know there is a problem. > > Since you said "don't hold your breath for Cabal's dependencies": > Cabal doesn't have to pass on ghc's messages uninterpreted. That's > a lot like implementing a map as a list and complaining about empty > list instead of element not found. I see what you're saying, but in practise it's just not possible. GHC can return a non-zero exit code for a multitude of reasons (most of which will be genuine errors in your source code). It's just not practical to parse the error messages that ghc produces and try and reinterpret them. I fear it'd quite easy to introduce more problems than are solved this way. If one wanted to take this approach you'd need to have some mode where error messages are produced in a machine readable format (which is of course doable if you write a client using the ghc api). A quicker hack would be to change ghcs error message in this circumstance, where the -hide-all-packages flag is given. Given our limited amount of volunteer developer time I think it's much better investing it in proper solutions. Duncan From duncan.coutts at worc.ox.ac.uk Tue Aug 26 16:36:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 26 19:28:44 2008 Subject: [Haskell-cafe] ANN: zip-archive 0.0 In-Reply-To: <20080826062256.GB551@berkeley.edu> References: <20080826062256.GB551@berkeley.edu> Message-ID: <1219782971.24846.77.camel@localhost> On Mon, 2008-08-25 at 23:22 -0700, John MacFarlane wrote: > I've written a library, zip-archive, for dealing with zip archives. Great. I saw your query about this from a month ago. > Haddock documentation (with links to source code): > http://johnmacfarlane.net/zip-archive/ > > Darcs repository: > http://johnmacfarlane.net/repos/zip-archive/ > > It comes with an example program that duplicates some of the > functionality of 'zip' (configure with '-fexecutable' to build it). > > I intend to put it on HackageDB, but I thought I'd get some feedback > first. Bug reports, patches, and suggestions on the API are all welcome. ?Generally it looks good, that the operations on the archive are mostly separated from IO of writing out archives or creating entries from disk files etc. Looking at the API there feels to be slightly too much exposed. Eg does the MSDOSDateTime need to be exposed, or the (de)compressData functions. I've been reworking the tar library recently and currently have an api that looks like: -- * Reading and writing the tar format read :: ByteString -> Entries write :: [Entry] -> ByteString -- * Packing and unpacking files to\/from a tar archive pack :: FilePath -> ?FilePath -> IO [Entry] unpack :: FilePath -> Entries -> IO () Entry is like your ZipEntry. Entries is a little special. Tar is really a linear/streamable format, we typically read the file front to back. Of course with zip it's more complex as you have an index (right?) and you can jump around without reading all the data. So Entries represents the unfolding of a tar file as a sequence of entries, but with the possibility of failure (eg format decoding failures): -- | A tar archive is a sequence of entries. data Entries = Next Entry Entries | Done | Fail String So that's why we have Entries for the result of decoding and just an ordinary list for the input to encoding. Zip is more complex of course because you often want to add files to existing archives, or lookup individual entries without just iterating through each entry. My personal inclination is to leave off the Zip prefix in the names and use qualified imports. I'd also leave out trivial compositions like readZipArchive f = ?toZipArchive <$> B.readFile f writeZipArchive f = B.writeFile f . fromZipArchive but reasonable people disagree. For both the pack in my tar lib and your addFilesToZipArchive, there's a getDirectoryContentsRecursive function asking to get out. This function seems to come up often. Ideally pack/unpack and addFilesToZipArchive/extractFilesFromZipArchive would just be mapM_ extract or create for an individual entry over the contents of the archive or the result of a recursive traversal. So yeah, I feel these operations ought to be simpler compositions of other things, in your lib and mine, since this bit is often the part where different use cases need slight variations, eg in how they write files, or deal with os-specific permissions/security stuff. So if these are compositions of simpler stuff it should be easier to add in extra stuff or replace bits. Duncan From duncan.coutts at worc.ox.ac.uk Tue Aug 26 19:44:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 26 19:42:35 2008 Subject: [Haskell-cafe] two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> <1218737836.13639.52.camel@localhost> <20080825212828.GA742@scytale.galois.com> <20080826220422.GI3200@scytale.galois.com> Message-ID: <1219794277.24846.81.camel@localhost> On Tue, 2008-08-26 at 15:31 -0700, Bryan O'Sullivan wrote: > On Tue, Aug 26, 2008 at 3:04 PM, Don Stewart wrote: > > > No, since I can get whnf with `seq`. However, that does sound like a > > good idea (a patch to the parallel library? ) > > I suspect that patching parallel doesn't scale. It doesn't have a > maintainer, so it will be slow, and the package will end up dragging > in everything under the sun if we centralise instances in there. I > think that the instance belongs in bytestring instead. I know that > this would make everything depend on parallel, but that doesn't seem > as bad a problem. This is a general problem we have with packages and instances. Perhaps in this specific case it wouldn't cause many problems to make bytestring depend on parallel (though it means bytestring cannot be a boot lib and cannot be used to implement basic IO) but in general it can be a problem. I can't see any obvious solutions. We don't want lots of tiny packages that just depend on two other packages and define a instance. Duncan From g9ks157k at acme.softbase.org Tue Aug 26 19:48:49 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Aug 26 19:47:29 2008 Subject: [Haskell-cafe] unsafeInterleaveIO, lazyness and sharing Message-ID: <200808270148.49971.g9ks157k@acme.softbase.org> Hello, Haskell is non-strict but not necessarily lazy. So it?s possible that an expression is reduced to WHNF although it is not used yet. Could this ?early reduction? also happen to outputs of unsafeInterleaveIO actions (which might trigger the action too early)? While I?d expect those outputs to be evaluated lazily (reduced as late as possible), I cannot find anything in the docs that guarantees this. In addition, I?d like to know whether unsafeInterleaveIO outputs are guaranteed to be evaluated at most once so that the ?interleaved action? is executed at most once. Again, I suppose that this is the case while I cannot find a guarantee for it. Best wishes, Wolfgang From john at repetae.net Tue Aug 26 20:34:37 2008 From: john at repetae.net (John Meacham) Date: Tue Aug 26 20:33:11 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> Message-ID: <20080827003437.GH15616@sliver.repetae.net> On Tue, Aug 26, 2008 at 01:14:34AM -0700, Judah Jacobson wrote: > On Tue, Aug 26, 2008 at 12:07 AM, Adrian Hey wrote: > > > > > > But from a top level aThing <- someACIO point of view, if we're going to > > say that it doesn't matter if someACIO is executed before main is > > entered (possibly even at compile time) or on demand, then we clearly > > don't want to observe any difference between the latter case and the > > former (if aThing becomes garbage without ever being demanded). > > > > Maybe it would be safest to just say anything with a finaliser can't be > > created at the top level. We can always define an appropriate top level > > "get" IO action using runOnce or whatever. > > I've been wondering: is there any benefit to having top-level ACIO'd > <- instead of just using runOnce (or perhaps "oneshot") as the > primitive for everything? For example: > > oneshot uniqueRef :: IO (MVar Integer) > uniqueRef =< newMVar 0 > > It was also suggested in that wiki page: > http://haskell.org/haskellwiki/Top_level_mutable_state#Proposal_4:_Shared_on-demand_IO_actions_.28oneShots.29 > > Those proposals eliminate the need for creating an ACIO monad and > enforcing its axioms, since one-shot actions are executed in-line with > other I/O actions (rather than at some nebulous "before the program is > run" time). Actually, due to the definition of ACIO, there is no difference between the two (for actions actually in ACIO). It was formulated to have this property. both implementations (executing them before the program is run, or on first call) and ways of thinking about things are valid and will be indistinguishable for all proper ACIO actions. note, you can implement oneshot IO actions on top of ACIO top level actions, but not the reverse. I think ACIO is cleaner overall, since we have a nice formal definition of when ACIO actions are valid without having to invoke the more complicated IO monad. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Aug 26 20:39:21 2008 From: john at repetae.net (John Meacham) Date: Tue Aug 26 20:37:54 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B3ABAC.5040905@iee.org> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> Message-ID: <20080827003920.GI15616@sliver.repetae.net> On Tue, Aug 26, 2008 at 08:07:24AM +0100, Adrian Hey wrote: > But from a top level aThing <- someACIO point of view, if we're going to > say that it doesn't matter if someACIO is executed before main is > entered (possibly even at compile time) or on demand, then we clearly > don't want to observe any difference between the latter case and the > former (if aThing becomes garbage without ever being demanded). > > Maybe it would be safest to just say anything with a finaliser can't be > created at the top level. We can always define an appropriate top level > "get" IO action using runOnce or whatever. If the finalizer is also in the weaker form of ACIO (ACIO under the no more references exist to its argument presumption, maybe called 'linearity condition' or something?), then it shouldn't matter at all. I can't think of any finalizers that don't obey this property that wern't problematic under the old model to begin with. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Aug 26 20:48:09 2008 From: john at repetae.net (John Meacham) Date: Tue Aug 26 20:46:43 2008 Subject: [Haskell-cafe] Re: [Haskell] Re:Fwd: Haskell job opportunity: Platform Architect at In-Reply-To: <42784f260808201517h2d81278bt273f12f00d77fe7e@mail.gmail.com> References: <26155532.1219248877855.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <90889fe70808201112w4cf238b3i90fa5df477324a72@mail.gmail.com> <42784f260808201517h2d81278bt273f12f00d77fe7e@mail.gmail.com> Message-ID: <20080827004809.GJ15616@sliver.repetae.net> On Wed, Aug 20, 2008 at 03:17:14PM -0700, Jason Dusek wrote: > What is your company going to do? What sort of dot-com attitude is that? Your company does whatever the buzzword that the venture capitalist you are currently talking to is enthralled with. :) 'monadic B2B ultra-wideband catamorphic connection oriented infospherespace' John -- John Meacham - ?repetae.net?john? From jason.dusek at gmail.com Tue Aug 26 21:04:14 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Tue Aug 26 21:02:49 2008 Subject: [Haskell-cafe] Re: [Haskell] Re:Fwd: Haskell job opportunity: Platform Architect at In-Reply-To: <20080827004809.GJ15616@sliver.repetae.net> References: <26155532.1219248877855.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <90889fe70808201112w4cf238b3i90fa5df477324a72@mail.gmail.com> <42784f260808201517h2d81278bt273f12f00d77fe7e@mail.gmail.com> <20080827004809.GJ15616@sliver.repetae.net> Message-ID: <42784f260808261804v41877b02i11d095c33a6718b3@mail.gmail.com> John Meacham wrote: > Your company does whatever the buzzword that the venture > capitalist you are currently talking to is enthralled with. :) Then we'll need some green, renewable monads! -- _jsn From haskell at colquitt.org Tue Aug 26 21:14:39 2008 From: haskell at colquitt.org (John Dorsey) Date: Tue Aug 26 21:13:13 2008 Subject: [Haskell-cafe] unsafeInterleaveIO, lazyness and sharing In-Reply-To: <200808270148.49971.g9ks157k@acme.softbase.org> References: <200808270148.49971.g9ks157k@acme.softbase.org> Message-ID: <20080827011438.GB10438@colquitt.org> Wolfgang, > Haskell is non-strict but not necessarily lazy. So it's possible > that an expression is reduced to WHNF although it is not used yet. > Could this early reduction also happen to outputs of > unsafeInterleaveIO actions (which might trigger the action too early)? > While I'd expect those outputs to be evaluated lazily (reduced as > late as possible), I cannot find anything in the docs that guarantees > this. "unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. This is used to implement lazy file reading, see hGetContents." http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html#v:unsafeInterleaveIO Is this the kind of guarantee you're looking for? I'd bet against getting any decent durable, portable guarantees for any unsafe* functions in Haskell; but the above behavioral description may be strong enough to suit you. > In addition, I'd like to know whether unsafeInterleaveIO outputs are > guaranteed to be evaluated at most once so that the interleaved action is > executed at most once. Again, I suppose that this is the case while I cannot > find a guarantee for it. I'd be surprised if an implementation didn't have that behavior. I'd also be wary of anyone claiming to guarantee it, beyond compiler X version Y. John Dorsey From lennart at augustsson.net Tue Aug 26 21:20:30 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Aug 26 21:19:04 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B46BD6.30604@iee.org> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> Message-ID: I told you where to look at code. It's C code, mind you, but written in a decent way. No well written device driver ever accesses memory or IO ports directly, doing so would seriously hamper portability. Instead you use an abstraction layer to access to hardware, and the driver gets passed a "bus" (whatever that might be) access token (akin to a capability). I know you're not going to be convinced, so I won't even try. :) -- Lennart On Tue, Aug 26, 2008 at 9:47 PM, Adrian Hey wrote: > Lennart Augustsson wrote: >> >> Making a network stack from peek and poke is easy in a well structured OS. >> The boot loader (or whatever) hands you the capability (call it >> something else if you want) to do raw hardware access, and you build >> from there. If you look at well structured OSs like NetBSD, this is >> pretty much how they work. No hardware drivers use global variables. > > So? We all know this is possible outside Haskell. But I don't want to > rely on mysterious black box OS's to "hand me the capability" any > more than I want to rely on mysterious extant but unimplementable libs > like Data.Unique. Most real world computing infrastructure uses no OS at > all. How could I use Haskell to implement such systems? > > Also (to mis-quote Linus Torvalds) could you or anyone else who agrees > with you please SHOW ME THE CODE in *Haskell*! If scripture is all > that's on offer I'm just not going to take any of you seriously. > > Frankly I'm tired of the patronising lectures that always acompany these > threads. It'd be good if someone who "knows" global variables are evil > could put their code where their mouth is for a change. Fixing up > the base libs to eliminate the dozen or so uses of the "unsafePerformIO > hack" might be a good place to start. I'll even let you change the API > of these libs if you must, provided you can give a sensible explanation > why the revised API is better, safer, more convenient or whatever. > > Regards > -- > Adrian Hey > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lennart at augustsson.net Tue Aug 26 21:23:04 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Aug 26 21:21:37 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B46BD6.30604@iee.org> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> Message-ID: BTW, I'm not contradicting that the use of global variables can be necessary when interfacing with legacy code, I just don't think it's the right design when doing something new. -- Lennart On Tue, Aug 26, 2008 at 9:47 PM, Adrian Hey wrote: > Lennart Augustsson wrote: >> >> Making a network stack from peek and poke is easy in a well structured OS. >> The boot loader (or whatever) hands you the capability (call it >> something else if you want) to do raw hardware access, and you build >> from there. If you look at well structured OSs like NetBSD, this is >> pretty much how they work. No hardware drivers use global variables. > > So? We all know this is possible outside Haskell. But I don't want to > rely on mysterious black box OS's to "hand me the capability" any > more than I want to rely on mysterious extant but unimplementable libs > like Data.Unique. Most real world computing infrastructure uses no OS at > all. How could I use Haskell to implement such systems? > > Also (to mis-quote Linus Torvalds) could you or anyone else who agrees > with you please SHOW ME THE CODE in *Haskell*! If scripture is all > that's on offer I'm just not going to take any of you seriously. > > Frankly I'm tired of the patronising lectures that always acompany these > threads. It'd be good if someone who "knows" global variables are evil > could put their code where their mouth is for a change. Fixing up > the base libs to eliminate the dozen or so uses of the "unsafePerformIO > hack" might be a good place to start. I'll even let you change the API > of these libs if you must, provided you can give a sensible explanation > why the revised API is better, safer, more convenient or whatever. > > Regards > -- > Adrian Hey > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ashley at semantic.org Tue Aug 26 21:44:52 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Aug 26 21:43:27 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> Message-ID: <48B4B194.4040307@semantic.org> Lennart Augustsson wrote: > No hardware drivers use global variables. No problem, write your hardware drivers in a different monad. Thus IO is the type for code that can use global variables, and H (or whatever) is the type for code that must not. -- Ashley Yakeley From duncan.coutts at worc.ox.ac.uk Tue Aug 26 22:06:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 26 22:04:04 2008 Subject: [Haskell-cafe] unsafeInterleaveIO, lazyness and sharing In-Reply-To: <200808270148.49971.g9ks157k@acme.softbase.org> References: <200808270148.49971.g9ks157k@acme.softbase.org> Message-ID: <1219802764.24846.96.camel@localhost> On Wed, 2008-08-27 at 01:48 +0200, Wolfgang Jeltsch wrote: > Hello, > > Haskell is non-strict but not necessarily lazy. So it?s possible that an > expression is reduced to WHNF although it is not used yet. Could this ?early > reduction? also happen to outputs of unsafeInterleaveIO actions (which might > trigger the action too early)? While I?d expect those outputs to be > evaluated lazily (reduced as late as possible), I cannot find anything in the > docs that guarantees this. > > In addition, I?d like to know whether unsafeInterleaveIO outputs are > guaranteed to be evaluated at most once so that the ?interleaved action? is > executed at most once. Again, I suppose that this is the case while I cannot > find a guarantee for it. I believe ghc does provide the behaviour you want, almost. I say almost because there is an issue with concurrency. In early versions of ghc's smp implementation it was easy to set up an experiment where two threads would pull on the result of hGetContents and observe different results. This was because different threads could occasionally enter an IO thunk simultaneously. This is now fixed but I understand the fix is not an absolute guarantee. This concurrency difference is the distinction between unsafeInterleaveIO and unsafeDupableInterleaveIO. ?unsafeDupableInterleaveIO itself is not currently documented but the difference is the same as for unsafeDupablePerformIO which is documented as: This version of 'unsafePerformIO' is slightly more efficient, because it omits the check that the IO is only being performed by a single thread. Hence, when you write 'unsafeDupablePerformIO', there is a possibility that the IO action may be performed multiple times (on a multiprocessor), and you should therefore ensure that it gives the same results each time. Though as I said, the check that the IO is only being performed by a single thread is apparently not an absolute guarantee. The details of why exactly I do not fully understand. If you want a full explanation ask Simon Marlow. Duncan From wren at freegeek.org Tue Aug 26 22:55:50 2008 From: wren at freegeek.org (wren ng thornton) Date: Tue Aug 26 22:54:26 2008 Subject: [Haskell-cafe] Re: ANN: First Monad Tutorial of the Season In-Reply-To: References: <1219435884.380.10.camel@localhost.localdomain> <1219667589.2872.18.camel@localhost.localdomain> <48B3BCA5.7010502@freegeek.org> <2f9b2d30808260945j43f26d2aua4a988880e875869@mail.gmail.com> <4817.192.12.13.2.1219772383.squirrel@mail.freegeek.org> Message-ID: <48B4C236.6070007@freegeek.org> Lennart Augustsson wrote: > The values Z, S Z, and S (S Z) all have the same runtime > representation and there is no linear increase in size when you add a > extra S. > > BUT, if you make something overloaded and there is a dictionary > associated with the type (Z, S Z, or S (S Z)) then the dictionary > takes up space, and that space is linear in the number of S > constructors. Ah yes, that makes more sense. Since your instance would look like: instance Foo a => Foo (S a) where foo :: a -> Int a dictionary for Foo (S(S Z)) would have entries for foo@(S(S Z)) and also the dictionary for Foo (S Z) which has foo@(S Z) and a dictionary for Foo Z which has... It's still something to watch out for if you're really worrying about performance. I wonder if this is documented on the wiki's section about performance anywhere, the overhead for inductive type class instances I mean. -- Live well, ~wren From timd at macquarie.com.au Tue Aug 26 22:58:16 2008 From: timd at macquarie.com.au (Tim Docker) Date: Tue Aug 26 22:56:51 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> Message-ID: <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> David Roundy wrote: > Which illustrates the point that it's not type safety > that protects us from segfaults, so much as bounds checking, > and that's got a non-trivial runtime cost. At least, most > segfaults that *I've* caused (in C or C++) have been from > overwriting the bounds of arrays, and that's precisely the problem > that Haskell does *not* solve using its type system. That differs from my experience. Most segfaults that *I've* caused (in C or C++) have been due to dereferencing null pointers. Type safety does help you here, in that Maybe lets you distinguish the types of things that are optionally present from those that must be. Tim From nonexistent.ftp+haskellcafe at gmail.com Tue Aug 26 23:32:37 2008 From: nonexistent.ftp+haskellcafe at gmail.com (Garrick Chin) Date: Tue Aug 26 23:31:11 2008 Subject: [Haskell-cafe] Building SDL-image package on Windows Message-ID: Hello, I'm trying to build the latest SDL-image package (0.5.2) from Hackage on Windows and encountering problems. These are the steps I've taken so far: 1. Downloaded SDL 1.2.13 developmental library for Mingw32 to E:\SDL-1.2.13, and SDL_image 1.2.6 developmental library for VC8 to E:\SDL_image-1.2.6. 2. Installed SDL package from Hackage, modifying the SDL.cabal according to the included WIN32 readme file and then runghc Setup.lhs configure/build/install 3. Downloaded the SDL-image package from Hackage, modified the SDL-image.cabal file to add the line "Include-Dirs: E:\SDL_image-1.2.6\include\SDL, E:\SDL-1.2.13\include\SDL" so Cabal can find the header files. After doing "runghc Setup.lhs configure", "runghc Setup.lhs build -v" gives me the following output: Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library SDL-image-0.5.2... Creating dist\build\Graphics\UI\SDL\Image (and its parents) E:\ghc\ghc-6.8.2\bin\hsc2hs.exe --cc=E:\ghc\ghc-6.8.2\bin\ghc.exe --ld=E:\ghc\ghc-6.8.2\bin\ghc.exe --cflag=-package --cflag=SDL-0.5.4 --cflag=-package --cflag=base-3.0.1.0 --cflag=-IE:\SDL_image-1.2.6\include\SDL --cflag=-IE:\SDL-1.2.13\include\SDL -o dist\build\Graphics\UI\SDL\Image\Version.hs Graphics\UI\SDL\Image\Version.hsc E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to `__stginit_ZCMain' E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status linking dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o failed command was: E:\ghc\ghc-6.8.2\bin\ghc.exe dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o -o dist\build\Graphics\UI\SDL\Image\Version_hsc_make.exe The results of a limited google search suggests that the __stginit_ZCMain linker error has to do with GHC expecting a main function, but I'm not really sure how that works in context of a library. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080826/dc43ecf3/attachment.htm From dagit at codersbase.com Wed Aug 27 01:58:57 2008 From: dagit at codersbase.com (Jason Dagit) Date: Wed Aug 27 01:57:30 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <1219680641.4486.15.camel@localhost.localdomain> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> <1219680641.4486.15.camel@localhost.localdomain> Message-ID: On Mon, Aug 25, 2008 at 9:10 AM, Mads Lindstr?m wrote: > Hi > > Ketil Malde wrote: >> I've had an interested user, who tried to get one of my programs to >> run on a Debian machine - running Debian Etch, released a couple of >> months ago. Here are some of the hurdles stumbled upon in the >> process: > > Debian Etch were released in April 8th, 2007. 16 months ago. Hardly "a > copule of months ago". See > http://www.debian.org/News/2007/20070408.en.html . Sure, there have been > updates since then, but they are mainly concerned with security and > drivers for new hardware. > >> >> 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file. >> 2. ghc-6.8.3, presumably the binary snapshots, didn't work, neither >> in i386 nor in x86_64 incarnation. >> 3. ghc 6.8.1-i386 appears to work, but some of the dependencies failed >> to compile (tagsoup, in this case) >> 4. A precompiled (by me), statically linked binary refuses to run with >> a message of "FATAL: kernel too old". >> >> Granted, not all of this is our fault, but it won't help users to >> start charging the windmills of Debian conservativism. We really need >> to make this process smoother, and ideally, provide debs for Etch >> backports. >> >> I'm not sure how to go about any of this, beyond debianizing my own >> packages. But that's why I'm telling you. :-) > > There are several options: > > 1) Use the testing or unstable branch of Debian. They got newer > packages. Testing (aka. Lenny) has GHC 6.8.2 > http://packages.debian.org/lenny/ghc6 . I'd stay away from 6.8.2 if I were you. It has at least one annoying bug that was fixed in 6.8.3. The one I'm thinking of is getSymbolicLinkStatus returning bogus mtimes on some 32bit platforms. > 2) Compile GHC yourself. You can even compile and install GHC (and most > Haskell software) on a dedicated user account. In this way you avoid > messing up you Debian installation if something goes wrong. I find with Debian this is the way to go. Install your system and use Debian's packages for everything, and then install your own copy of anything for which you care what version you're running. Not everyone will like this option, but I find it's a decent balance between using what Debian provides and getting the satisfaction of using the versions of things I care about. Jason From ketil at malde.org Wed Aug 27 02:42:15 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Aug 27 02:39:27 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <87abezfo0j.wl%jeremy@n-heptane.com> (Jeremy Shaw's message of "Tue\, 26 Aug 2008 14\:46\:20 -0700") References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <87abezfo0j.wl%jeremy@n-heptane.com> Message-ID: <878wuj9cxk.fsf@malde.org> "Jeremy Shaw" writes: I probably shouldn't post when I don't quite understand the question, and I'm unsure whether this is about timeouts, lazy parsing of responses, or line endings? These seem like independent issues to me. Anyway: > Polyparse has some lazy parsers: but Tomasz Zielonka once posted a 'lazyMany' combinator for Parsec, which I've used successfully. Isn't lazy parsing of many NNTPResponse or similar what you want? (If you can't find the original post, there's a copy at http://malde.org/~ketil/biohaskell/biolib/Bio/Util/Parsex.hs) PS: While I try to avoid 'unsafePerformIO', I tend to make use of 'unsafeInterleaveIO'. Although I'm sure the creative people here can demonstrate cases of nasal demons caused by that function, too. -k -- If I haven't seen further, it is by standing in the footprints of giants From ketil at malde.org Wed Aug 27 02:53:18 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Aug 27 02:50:29 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: (Jason Dagit's message of "Tue\, 26 Aug 2008 22\:58\:57 -0700") References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> <1219680641.4486.15.camel@localhost.localdomain> Message-ID: <87fxor7xup.fsf@malde.org> "Jason Dagit" writes: >> 2) Compile GHC yourself. > I find with Debian this is the way to go. Ouch. Okay, I've compiled GHC once. But I would like end-users to be able to use my software, and I simply cannot require them to go through this. > Install your system and use Debian's packages for everything, and > then install your own copy of anything for which you care what > version you're running. Right, I generally do this too. But even Ubuntu's GHC is recent enough that I make do with it. I had a look at cabal-debian, but installation was a bit complex, and I'm not even sure with what or how to apply various patches needed. It'd be great if this worked OOB on Lenny and Hardy. Another Debian question, once I've populated the debian/ directory one way or another, how should this be integrated with the rest of the project? Should it be part of the darcs archive, or a separate archive (foo-debian), or what? How do people organize this? -k -- If I haven't seen further, it is by standing in the footprints of giants From bulat.ziganshin at gmail.com Wed Aug 27 03:08:46 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 03:15:50 2008 Subject: [Haskell-cafe] contributing to standard library In-Reply-To: References: Message-ID: <1819429757.20080827110846@gmail.com> Hello Tim, Wednesday, August 27, 2008, 1:49:51 AM, you wrote: > Like everyone else who has used Haskell for a while, I'm accumulating > functions which I feel should have already been in the standard > libraries i have such module with 100+ functions. should i propose to add them all too? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/b942f097/attachment.htm From DekuDekuplex at Yahoo.com Wed Aug 27 03:22:56 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Wed Aug 27 03:21:42 2008 Subject: [Haskell-cafe] apparent minor bug in "Getting started" tutorial at "Haskell Hacking: a journal of Haskell programming" Message-ID: This is just a minor documentation bug report, but I tried following the instructions in the "Getting started" tutorial at "Haskell Hacking: a journal of Haskell programming" (http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/16#programming-haskell-intro) for GHCi 6.8.3 on Windows XP Professional (Service Pack 2), as follows: >You can compile this code to a native binary using GHC, by writing in a source file: > > main = putStrLn "G'day, world!" > >and then compiling the source to native code. Assuming your file is A.hs: > > $ ghc A.hs > >This produces a new executable, ./a.out (a.out.exe on windows), which you can run like any other program on your system: > > $ ./a.out > G'day, world! However, this produced the following files, instead: A.hi A.o main.exe main.exe.manifest There was no a.out file, and running A.o popped up a Windows dialog box asking me to specify which application to run the program with. So, I ran $ ghc --help and found the following documentation: >To compile and link a complete Haskell program, run the compiler like >so: > > ghc --make Main > >where the module Main is in a file named Main.hs (or Main.lhs) in the >current directory. The other modules in the program will be located >and compiled automatically, and the linked program will be placed in >the file `a.out' (or `Main.exe' on Windows). > >[...] > >Given the above, here are some TYPICAL invocations of ghc: > > # compile a Haskell module to a .o file, optimising: > % ghc -c -O Foo.hs Running $ main.exe produced the desired result: >G'day, world! Would it be possible to update the documentation to reflect the need to enter $ main.exe after compilation instead of $ a.out ? Thank you. -- Benjamin L. Russell From DekuDekuplex at Yahoo.com Wed Aug 27 03:28:06 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Wed Aug 27 03:28:47 2008 Subject: [Haskell-cafe] Re: apparent minor bug in "Getting started" tutorial at "Haskell Hacking: a journal of Haskell programming" References: Message-ID: <6b0ab4tqopjqh1i57o90mqc64n386n5nkb@4ax.com> On Wed, 27 Aug 2008 16:22:56 +0900, Benjamin L.Russell wrote: Sorry, what I really meant was not to update the reference to "a.out" to be changed to "main.exe", but to change the following line: >>This produces a new executable, ./a.out (a.out.exe on windows), which you can run like any other program on your system: to read as follows: >>This produces a new executable, ./a.out (main.exe on windows), which you can run like any other program on your system: There was no "a.out.exe" on Windows, but only a "main.exe". Sorry for the confusion. -- Benjamin L. Russell From bulat.ziganshin at gmail.com Wed Aug 27 03:41:30 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 03:40:10 2008 Subject: [Haskell-cafe] Pure hashtable library Message-ID: <1365585749.20080827114130@gmail.com> Hello haskell-cafe, solving one more task that uses English dictionary, i've thought: why we don't yet have pure hashtable library? There is imperative hashtables, pretty complex as they need to rebuild entire table as it grows. There is also simple assoc lists and tree/trie implementations, but there is no simple non-modifiable hashes. how should it look: * hashtable is represented as an array of assoc lists: Array Int [(a,b)] * interface to extract data from ht is the same as from assoc list: lookup :: HT a b -> a -> Maybe b * ht may be built from assoc list. we should just know it's size beforehand in order to create Array of reasonable size. constructor also need a hashing function: create :: [(a,b)] -> Int -> (a->Int) -> HT a b given these constraints, it should be just a 10-20 lines of code, and provide much better efficiency than any tree/trie implementations -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/632eb037/attachment.htm From ahey at iee.org Wed Aug 27 03:42:30 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 27 03:41:07 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> Message-ID: <48B50566.1070600@iee.org> Lennart Augustsson wrote: > BTW, I'm not contradicting that the use of global variables can be > necessary when interfacing with legacy code, I just don't think it's > the right design when doing something new. AFAICS the use of top level mutable state in the base libs has nothing at all to do with interfacing with legacy code, it's a semantic necessity and there's no legacy code involved. If you want to dispute that then please show some real Haskell code that does as good or better job without it (or point me too the relevant legacy code that makes it necessary). Regards -- Adrian Hey From jason.dusek at gmail.com Wed Aug 27 03:55:31 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed Aug 27 03:54:05 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1365585749.20080827114130@gmail.com> References: <1365585749.20080827114130@gmail.com> Message-ID: <42784f260808270055v6086fcb7h411f68f4624c47f7@mail.gmail.com> Bulat Ziganshin : > given these constraints, it should be just a 10-20 lines of > code, and provide much better efficiency than any tree/trie > implementations Much better efficiency in what way? -- _jsn From ahey at iee.org Wed Aug 27 04:07:30 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 27 04:06:06 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> Message-ID: <48B50B42.6010306@iee.org> Lennart Augustsson wrote: > I told you where to look at code. It's C code, mind you, but written > in a decent way. > No well written device driver ever accesses memory or IO ports > directly, doing so would seriously hamper portability. Well something must be accessing both. Dunno what you mean by "directly" I take it you must mean that the driver does not make use of global variables or "baked in" port addresses in it's source code. > Instead you use an abstraction layer to access to hardware, and the > driver gets passed a "bus" (whatever that might be) access token (akin > to a capability). > > I know you're not going to be convinced, so I won't even try. :) I have actually spent the last 20 years or so writing both non-hosted and hosted device drivers for a few OS's. I'm perfectly convinced about the truth of what you say, but not at all convinced about the relevance. It's a red herring IMO as you've introduced a very complex and mysterious black box that itself cannot be implemented without making use of "global variables". You can find them easily enough in the Linux kernel source. I'm sure they'll be there in NetBSD too (never looked though). Regards -- Adrian Hey From bulat.ziganshin at gmail.com Wed Aug 27 04:09:59 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 04:08:43 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <42784f260808270055v6086fcb7h411f68f4624c47f7@mail.gmail.com> References: <1365585749.20080827114130@gmail.com> <42784f260808270055v6086fcb7h411f68f4624c47f7@mail.gmail.com> Message-ID: <1853565763.20080827120959@gmail.com> Hello Jason, Wednesday, August 27, 2008, 11:55:31 AM, you wrote: >> given these constraints, it should be just a 10-20 lines of >> code, and provide much better efficiency than any tree/trie >> implementations > Much better efficiency in what way? instead of going through many levels of tree/trie, lookup function will just select array element by hash value and look through a few elements in assoc list: data HT a b = HT (a->Int) -- hash function (Array Int [(a,b)]) HT.lookup (HT hash arr) a = List.lookup (arr!hash a) a -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/5413ca69/attachment.htm From tom.davie at gmail.com Wed Aug 27 04:15:43 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Aug 27 04:14:19 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1853565763.20080827120959@gmail.com> References: <1365585749.20080827114130@gmail.com> <42784f260808270055v6086fcb7h411f68f4624c47f7@mail.gmail.com> <1853565763.20080827120959@gmail.com> Message-ID: On 27 Aug 2008, at 10:09, Bulat Ziganshin wrote: > Hello Jason, > > Wednesday, August 27, 2008, 11:55:31 AM, you wrote: > > >> given these constraints, it should be just a 10-20 lines of > >> code, and provide much better efficiency than any tree/trie > >> implementations > > > Much better efficiency in what way? > > instead of going through many levels of tree/trie, lookup function > will just select array element by hash value and look through a few > elements in assoc list: > > data HT a b = HT (a->Int) -- hash function > (Array Int [(a,b)]) > > HT.lookup (HT hash arr) a = List.lookup (arr!hash a) a Which makes two assumptions. One is that your array is big enough (believable), and the other, that your font is big enough. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/7106550e/attachment-0001.htm From lennart at augustsson.net Wed Aug 27 04:32:58 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Aug 27 04:31:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B50B42.6010306@iee.org> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <48B50B42.6010306@iee.org> Message-ID: I've also written quite a few hosted and non-hosted device drivers (in C). None of them have any global variables. On Wed, Aug 27, 2008 at 9:07 AM, Adrian Hey wrote: > Lennart Augustsson wrote: >> >> I told you where to look at code. It's C code, mind you, but written >> in a decent way. >> No well written device driver ever accesses memory or IO ports >> directly, doing so would seriously hamper portability. > > Well something must be accessing both. Dunno what you mean by "directly" > I take it you must mean that the driver does not make use of global > variables or "baked in" port addresses in it's source code. > >> Instead you use an abstraction layer to access to hardware, and the >> driver gets passed a "bus" (whatever that might be) access token (akin >> to a capability). >> >> I know you're not going to be convinced, so I won't even try. :) > > I have actually spent the last 20 years or so writing both non-hosted > and hosted device drivers for a few OS's. I'm perfectly convinced about > the truth of what you say, but not at all convinced about the relevance. > > It's a red herring IMO as you've introduced a very complex and > mysterious black box that itself cannot be implemented without making > use of "global variables". You can find them easily enough in the Linux > kernel source. I'm sure they'll be there in NetBSD too (never looked > though). > > Regards > -- > Adrian Hey > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From Alistair.Bayley at invesco.com Wed Aug 27 04:39:43 2008 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Wed Aug 27 04:38:21 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: References: <1365585749.20080827114130@gmail.com><42784f260808270055v6086fcb7h411f68f4624c47f7@mail.gmail.com><1853565763.20080827120959@gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E9548@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Thomas Davie > > > Much better efficiency in what way? > > instead of going through many levels of tree/trie, > lookup function will just select array element by hash value > and look through a few elements in assoc list: > > data HT a b = HT (a->Int) -- hash function > (Array Int [(a,b)]) > > HT.lookup (HT hash arr) a = List.lookup (arr!hash a) a > > Which makes two assumptions. One is that your array is big > enough (believable), and the other, that your font is big enough. > ... and the other, that your font is big enough. Que? This is lost on me. Care to explain? Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From bit at mutantlemon.com Wed Aug 27 04:40:35 2008 From: bit at mutantlemon.com (Bit Connor) Date: Wed Aug 27 04:39:08 2008 Subject: [Haskell-cafe] Building SDL-image package on Windows In-Reply-To: References: Message-ID: <6205bd290808270140g73615341y5ac542139e560c09@mail.gmail.com> Hi, I wrote the instructions in the WIN32 file. This looks like the same problem that I originally had with the SDL package, mangling of "main" function in C land by the hand of the C SDL.h include file. If you look at the .hsc files from the SDL package, you will see the fix I applied at the top of each file, after #including SDL.h the evil "main" macro is undefined: #include "SDL.h" #ifdef main #undef main #endif Probably the same must be done for all the .hsc files in SDL-image(and probably also all other haskell SDL addon packages). Please let me know if this information is helpful. 2008/8/27 Garrick Chin : > Hello, > > I'm trying to build the latest SDL-image package (0.5.2) from Hackage on > Windows and encountering problems. These are the steps I've taken so far: > > 1. Downloaded SDL 1.2.13 developmental library for Mingw32 to > E:\SDL-1.2.13, and SDL_image 1.2.6 developmental library for VC8 to > E:\SDL_image-1.2.6. > 2. Installed SDL package from Hackage, modifying the SDL.cabal according to > the included WIN32 readme file and then runghc Setup.lhs > configure/build/install > 3. Downloaded the SDL-image package from Hackage, modified the > SDL-image.cabal file to add the line "Include-Dirs: > E:\SDL_image-1.2.6\include\SDL, E:\SDL-1.2.13\include\SDL" so Cabal can find > the header files. After doing "runghc Setup.lhs configure", "runghc > Setup.lhs build -v" gives me the following output: > > Creating dist\build (and its parents) > Creating dist\build\autogen (and its parents) > Preprocessing library SDL-image-0.5.2... > Creating dist\build\Graphics\UI\SDL\Image (and its parents) > E:\ghc\ghc-6.8.2\bin\hsc2hs.exe --cc=E:\ghc\ghc-6.8.2\bin\ghc.exe > --ld=E:\ghc\ghc-6.8.2\bin\ghc.exe --cflag=-package --cflag=SDL-0.5.4 > --cflag=-package --cflag=base-3.0.1.0 > --cflag=-IE:\SDL_image-1.2.6\include\SDL --cflag=-IE:\SDL-1.2.13\include\SDL > -o dist\build\Graphics\UI\SDL\Image\Version.hs > Graphics\UI\SDL\Image\Version.hsc > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference > to `__stginit_ZCMain' > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference > to `ZCMain_main_closure' > collect2: ld returned 1 exit status > linking dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o failed > command was: E:\ghc\ghc-6.8.2\bin\ghc.exe > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o -o > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.exe > > The results of a limited google search suggests that the __stginit_ZCMain > linker error has to do with GHC expecting a main function, but I'm not > really sure how that works in context of a library. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ahey at iee.org Wed Aug 27 04:54:37 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 27 04:53:15 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <48B50B42.6010306@iee.org> Message-ID: <48B5164D.3040507@iee.org> Lennart Augustsson wrote: > I've also written quite a few hosted and non-hosted device drivers (in C). > None of them have any global variables. The point is to be able to properly model, understand and if necessary implement *entire systems* without using "global variables" (allegedly). You can always define sub-system boundaries in such a way that you can claim that this/that or the other sub-system, device driver or whatever does not use "global variables" if you put the global variables somewhere else and pass a reference to the sub-system concerned. We could play that game with Data.Unique, for example. Regards -- Adrian Hey From tom.davie at gmail.com Wed Aug 27 05:26:05 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Aug 27 05:24:40 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E9548@GBLONXMB02.corp.amvescap.net> References: <1365585749.20080827114130@gmail.com><42784f260808270055v6086fcb7h411f68f4624c47f7@mail.gmail.com><1853565763.20080827120959@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9548@GBLONXMB02.corp.amvescap.net> Message-ID: On 27 Aug 2008, at 10:39, Bayley, Alistair wrote: >> From: haskell-cafe-bounces@haskell.org >> [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Thomas Davie >> >> > Much better efficiency in what way? >> >> instead of going through many levels of tree/trie, >> lookup function will just select array element by hash value >> and look through a few elements in assoc list: >> >> data HT a b = HT (a->Int) -- hash function >> (Array Int [(a,b)]) >> >> HT.lookup (HT hash arr) a = List.lookup (arr!hash a) a >> >> Which makes two assumptions. One is that your array is big >> enough (believable), and the other, that your font is big enough. > > >> ... and the other, that your font is big enough. > > Que? This is lost on me. Care to explain? Sorry, I probably should have sent that, it was a dig at the fact that the message was sent with all the text in font-size 930 or so. Bob From john at repetae.net Wed Aug 27 05:35:22 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 05:33:54 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> Message-ID: <20080827093521.GP15616@sliver.repetae.net> On Wed, Aug 27, 2008 at 02:23:04AM +0100, Lennart Augustsson wrote: > BTW, I'm not contradicting that the use of global variables can be > necessary when interfacing with legacy code, I just don't think it's > the right design when doing something new. As with all design decisions, it is sometimes the right thing and sometimes the wrong one. And sometimes the most expedient. (which, occasionally, is a perfectly valid driving force behind a certain bit of coding). However, I am fully convinced it is necessary. You don't even have to look further than Haskell 98 to find a use in the Random module, and Data.Unique _depends_ on the state being global for correctness. now, _interfaces_ that depend on global state are a completely different matter. To quote what I wrote in the jhc manual: "Note, top level global variables can be indicative of design issues. In general, they should only be used when necessary to interface with an external library, opaque uses inside a library where the shared state can not be externally observed, or inside your Main program as design dictates." However, note the weasel words. Those are in there on purpose, every design calls for different solutions. To blanketly say certain constructs are just wrong to the point of disallowing them in the language, especially when they are common practice at the moment, just doesn't seem right. John -- John Meacham - ?repetae.net?john? From deduktionstheorem at web.de Wed Aug 27 05:52:23 2008 From: deduktionstheorem at web.de (Stephan Friedrichs) Date: Wed Aug 27 05:50:58 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1365585749.20080827114130@gmail.com> References: <1365585749.20080827114130@gmail.com> Message-ID: <48B523D7.3060001@web.de> Bulat Ziganshin wrote: > solving one more task that uses English dictionary, i've thought: why we > don't yet have pure hashtable library? There is imperative hashtables, > [...] > how should it look: > > * hashtable is represented as an array of assoc lists: Array Int [(a,b)] Don't immutable arrays get rather inefficient when modified? > > [...] Just a tought: You might want to have a look at the bloom filter implementation. On one hand, it is an alternative for your dictionary and on the other and, its implementation uses hash functions and arrays as well. IIRC it does that in a state monad that keeps the array mutable and finally freezes it before usage, which might be a good idea for pure hash table as well. //Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr From waldmann at imn.htwk-leipzig.de Wed Aug 27 05:53:41 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Aug 27 05:54:19 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B523D7.3060001@web.de> References: <1365585749.20080827114130@gmail.com> <48B523D7.3060001@web.de> Message-ID: <48B52425.6060507@imn.htwk-leipzig.de> >> * hashtable is represented as an array of assoc lists: Array Int [(a,b)] > > Don't immutable arrays get rather inefficient when modified? Bulat was specifically asking for "simple *non-modifiable* hashes" http://article.gmane.org/gmane.comp.lang.haskell.cafe/43612 J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/eec12040/signature.bin From eric.kow at gmail.com Wed Aug 27 06:44:06 2008 From: eric.kow at gmail.com (Eric Kow) Date: Wed Aug 27 06:42:39 2008 Subject: [Haskell-cafe] darcs weekly news #1 Message-ID: <4a0b969d0808270344x5f37c3c4taab551065a855a4b@mail.gmail.com> Hi everybody, I thought it would be useful if we got back into the habit up summarising our weekly darcs activities. This is the first entry of what I hope to be Darcs Weekly News. Note that I have also Bcc'ed the Haskell Cafe; which I will not be doing everytime, but just this once :-) News and discussions -------------------- hacking sprint (25/26 October) We are now planning three sites for the upcoming darcs hacking sprint: Brighton (moved from Cambridge), Paris and Portland. More news as we finalise the venues in the next two weeks! performance benchmarking Eric is working on integrating performance regression testing into the darcs buildbot. The progress is slow but steady! darcs 2 real world comparison Jason analyses a comparison of darcs push between 1.0.9 and 2.0.2. http://blog.codersbase.com/2008/08/21/darcs-2-real-world-push-performance-evaluation/ darcs weekly news Most of darcs weekly news is automated, but we still need human editors! To help out, darcs get http://code.haskell.org/darcs/darcs-news Issues resolved in the last two weeks (5) ----------------------------------------- * issue115 (Dmitry Kurochkin) match patches touching given files. http://bugs.darcs.net/issue115 * issue823 (Dmitry Kurochkin) do not exit on keyboard interrupt when getting patches. http://bugs.darcs.net/issue823 * issue936 (Dmitry Kurochkin) fix type witnesses configure check. http://bugs.darcs.net/issue936 * issue950 (David Roundy) fix fix_filepath to work with --repodir (and add test demonstrating this). http://bugs.darcs.net/issue950 * issue995 (Dmitry Kurochkin) changes --context : {--human-readable,--xml-output} have no effect. http://bugs.darcs.net/issue995 Patches applied in the last two weeks (69) ------------------------------------------ 2008-08-25 Jason Dagit minor refator to get_extra improve comments 2008-08-25 Eric Kow Same ChangeLog entries since 2.0.2 Some more globally ignored changes. 2008-08-24 David Roundy Simplify filepath handling, cutting lots of hardly-used code. don't bother computing path when checking prereqs (since we now can handle looking at beginning/ending working directories). resolve issue950: fix fix_filepath to work with --repodir (and add test demonstrating this). eliminate fix_flag. add new framework for ensuring that certain arguments are converted to absolute paths. make Darcs.Lock functions accept FilePathLike arguments. refactor maybeMkSubPath very slightly. refactor repoPath very slightly. make makeAbsolute behavior match comment. 2008-08-22 Dmitry Kurochkin Fix makeAbsolute to work with '../foo' paths. 2008-08-22 David Roundy move withCurrentDirectory, withTempDir and withPermDir rewrite mkAbsolutePath to be safe. 2008-08-22 Eric Kow Changelog (ignore 'Add a test entries') 2008-08-22 David Roundy resolve conflicts. 2008-08-19 Dmitry Kurochkin Resolve issue936: fix type witnesses configure check. Use forkIO in URL module as suggested by Simon Marlow. Remove HTTP.copyUrl, integrate it to URL module. More URL module refactoring. 2008-08-22 Eric Kow Canonize Nathaniel Filardo and Simon Marlow. Add test case for issue966 (from Dan Pascu's bug report) 2008-08-21 David Roundy remove trailing whitespace. 2008-08-21 Dmitry Kurochkin Documentation for match touch primitive. Resolve issue115: match patches touching given files. 2008-08-22 Eric Kow Remove unused FileSystem module. 2008-08-20 David Roundy fix type witnesses in with_selected_patch_from_repo. clean up bugs functions (eliminate darcsBug.h). 2008-08-19 Jason Dagit Fix a bug with incorrectly specified with_selecte_patch_from_repository. 2008-08-19 Dmitry Kurochkin Remove HTTP.exists, use Autoconf.have_HTTP instead. 2008-08-19 David Roundy fix improper use of bug in HTTP. 2008-08-19 Dmitry Kurochkin Do not import HTTP module in Darcs.Bug, use bug and debugFail for error reporting in HTTP module. 2008-08-19 David Roundy fix incompatibility with ghc 6.6. make scan_bundle create a lazy patch bundle. resolve conflicts with Darcs.Ordered change. 2008-08-15 Jason Dagit replace separate_middle_last_from_first and separate_last_from_first_middle with get_choices correct a bug in with_selected_patches_from_repository refine type witnesses in SelectChanges make WhatsNew work with type witnesses major refactor of SelectChanges to work with type witnesses 2008-08-16 nwf@cs.jhu.edu Move Darcs.Patch.Ordered to Darcs.Ordered since it isn't patchy 2008-08-19 Simon Marlow Fix use of threadWaitRead on Windows Fix Windows build 2008-08-17 Dmitry Kurochkin URL module refactoring. Do not compile curl support if libwww is enabled. URL.hs: always import debugFail, again. URL.hs: call debugFail when download fails. URL.hs: debug messages. Spacing in Darcs/Commands/Changes.lhs Rename catchInt to catchInterrupt, better message when get is interrupted. Resolve issue995: changes --context : {--human-readable,--xml-output} have no effect. 2008-08-18 Eric Kow Add test for issue1017 (as suggested by Bjorn Bringert) 2008-08-19 David Roundy don't print "Wrote patch to -" when writing patch to stdout. always send with context. 2008-08-18 Eric Kow Tidy up known failing shell tests. Tidy up failing test for issue1013. Move hidden conflicts bug to tests directory. Add failing test for issue1012 (Simon Marlow). 2008-08-15 Dmitry Kurochkin Resolve issue823: do not exit on keyboard interrupt when getting patches. 2008-08-14 David Roundy fix buggy comments in bugs/identical-patches.sh. 2008-08-13 Eric Kow Add Ian's identical-patch test case. 2008-08-13 Dmitry Kurochkin URL.hs: store only URL in waitToStart queue. 2008-08-14 Eric Kow Add (failing) test for issue944. 2008-08-13 nwf@cs.jhu.edu Split Cache mostly out of Darsc/Repository/Prefs into its own file (take 2) 2008-08-13 Jason Dagit remove a few unsightly functions 2008-08-13 Dmitry Kurochkin Fix URL module bug with pipelining enabled. Minor change to URL module. Enable pipelining by default, add --disable-pipelining option (issue838). -- Eric Kow PGP Key ID: 08AC04F9 From ahey at iee.org Wed Aug 27 06:53:19 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 27 06:51:55 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080827093521.GP15616@sliver.repetae.net> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> Message-ID: <48B5321F.7030501@iee.org> John Meacham wrote: > As with all design decisions, it is sometimes the right thing and > sometimes the wrong one. And sometimes the most expedient. (which, > occasionally, is a perfectly valid driving force behind a certain bit of > coding). However, I am fully convinced it is necessary. You don't even > have to look further than Haskell 98 to find a use in the Random module, > and Data.Unique _depends_ on the state being global for correctness. ..and of course there's stdin, stdout. That takes some explaining. Even with the proposed ACIO and top level <- bindings I still couldn't implement a lib that exported a top level nonStdout handle. It'd have to be a getNonStdout IO action. Regarding the necessity of "global variables", despite what I've been saying it is of course possible to implement entire systems (programs/processes or whatever main corresponds to) without them if you don't mind explicitly creating all those micro states immediately on entry to main and passing the references around. But this is a highly unmodular, inconvenient, unsafe (because you must expose and allow potentially uncontrained use of newWhateverMicroState constuctors) and a general maintainance nightmare. Definitely not the way to go IMO. So it would be more accurate to say that IMO it's impossible to implement many sane and inherently safe IO lib APIs without using "global variables". But people who prefer insane and inherently unsafe APIs could live without them quite happily I guess :-) Regards -- Adrian Hey From daveroundy at gmail.com Wed Aug 27 07:18:58 2008 From: daveroundy at gmail.com (David Roundy) Date: Wed Aug 27 07:17:33 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> <1219680641.4486.15.camel@localhost.localdomain> Message-ID: <117f2cc80808270418x29c5f083vea10ff98e9ab1b73@mail.gmail.com> On Wed, Aug 27, 2008 at 1:58 AM, Jason Dagit wrote: >> 2) Compile GHC yourself. You can even compile and install GHC (and most >> Haskell software) on a dedicated user account. In this way you avoid >> messing up you Debian installation if something goes wrong. > > I find with Debian this is the way to go. Install your system and use > Debian's packages for everything, and then install your own copy of > anything for which you care what version you're running. > > Not everyone will like this option, but I find it's a decent balance > between using what Debian provides and getting the satisfaction of > using the versions of things I care about. I've always used the version of ghc that comes with debian. Part of creating decent software is making sure that it compiles with a stable non-bleeding-edge compiler that is readily available to users. But that's probably because I'm lazy, and would rather write software that just works than play with the latest bells and whistles. I have had to compile ghc myself on a few occasions to help the ghc folks track down compiler bugs (i.e. to check behavior under a different compiler), but for normal use, I would say the sane thing is to stick with the debian version of ghc. David From Malcolm.Wallace at cs.york.ac.uk Wed Aug 27 07:19:43 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 27 07:19:32 2008 Subject: [Haskell-cafe] 2 modules in one file In-Reply-To: References: Message-ID: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> Maur??cio wrote: > Is it allowed to write two > different modules in a single > file? Some compilers permit it (e.g. Freja), most do not (e.g. ghc). The Language Report makes no specification for the mapping between module sources and the files that contain them. Regards, Malcolm From claus.reinke at talk21.com Wed Aug 27 07:33:31 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Aug 27 07:32:10 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class References: <1219680537.14617.12.camel@bernH> <1219745168.14617.21.camel@bernH> <1219756960.24846.9.camel@localhost> <2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> <1219759788.24846.23.camel@localhost> <017801c9078b$781795f0$94407ad5@cr3lt> <1219780914.24846.48.camel@localhost> Message-ID: <01c801c90838$be63eba0$130e7ad5@cr3lt> >> Cabal doesn't have to pass on ghc's messages uninterpreted. That's >> a lot like implementing a map as a list and complaining about empty >> list instead of element not found. > > I see what you're saying, but in practise it's just not possible. GHC > can return a non-zero exit code for a multitude of reasons (most of > which will be genuine errors in your source code). It's just not > practical to parse the error messages that ghc produces and try and > reinterpret them. I fear it'd quite easy to introduce more problems than > are solved this way. Introducing more problems is quite possible, though changes in error messages should mostly mean that the rules won't trigger and no helpful explanation is given. And even that could be cured by having the collection of rules updateable, separately from Cabal itself. And when the forthcoming next base split, and extensible exceptions, and Cabal Api changes, and .. are going to introduce new break points, updating the rules will offer help for those breakages, too. Given the shakiness of this simplistic approach, one might not want to enable it by default, but what about an option '--explain' and a hint if things go wrong: "if you would like help interpreting common Cabal package issues, you can try repeating your command with our experimental --explain option". What I don't understand are your "in practise it's just not possible" and "It's just not practical to parse the error messages that ghc produces and try and reinterpret them". I assume you've tried the code I first sent some 9 months ago, and again this week, and found that it wouldn't work for some reasons,but you haven't told me those reasons yet. > If one wanted to take this approach you'd need to have some mode where > error messages are produced in a machine readable format (which is of > course doable if you write a client using the ghc api). > > A quicker hack would be to change ghcs error message in this > circumstance, where the -hide-all-packages flag is given. One would want to have such support depend on an extra option, '--errors-in-xml' or something equally scary, but I'm afraid the extra readability/stability would be mostly illusionary. We're talking about "good enough" hacks to cover "not quite right" left-overs from too much instability in the Haskell tool chains - as long as the instabilities remain, there is no "perfect" solution. > Given our limited amount of volunteer developer time I think it's > much better investing it in proper solutions. How many times over the last 9 months have you had to explain what a script could have told your Cabal users? And how many more Cabal/Haskell users have been scared away in that time, without even raising their build problems on any of the lists? "Proper" solutions are alright when we have them. "Good enough" but hacky is much better than nothing. With an '--explain' option and a collection of rules, you'd have to explain every error condition just once, then update the rules/explanations, and let Cabal repeat the explanation whenever needed. If those canned explanations don't work, users can still ask here. Claus From ahey at iee.org Wed Aug 27 07:56:22 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 27 07:54:58 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B3D4A1.80104@semantic.org> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> <48B3D4A1.80104@semantic.org> Message-ID: <48B540E6.2010008@iee.org> Ashley Yakeley wrote: > Adrian Hey wrote: >> Maybe it would be safest to just say anything with a finaliser can't be >> created at the top level. > > Do you have an example of something that is correctly ACIO to create, > but has a problematic finaliser? Sorry for the delay in getting my attention. I've been looking at my old ACIO code (which I've largely forgotten the details of) and dug up the following snippet. -- * Weak pointers -- | All these functions require that finalisers (if any) are in the -- ACIO Monad. -- I'm not sure what such a finaliser can usefully do, but it can't be -- in the IO Monad and preserve ACIO Monad properties AFAICS. mkWeak,mkWeakPtr,mkWeakPair,addFinalizer,mkWeakIORef, I must admit I can't remember much about any of this, I just worked my way through the IO libs trying to figure out which actions might plausibly (if not usefully :-) be regarded as ACIO. There seemed to be quite a lot at the end of the day. I also added a few forkIO variants which force the forked thread to block on certain things (empty MVar,Chan, QSem..) waiting for some IO monad action to kick them into life. Regards -- Adrian Hey From jmaessen at alum.mit.edu Wed Aug 27 08:06:11 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed Aug 27 08:04:46 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1365585749.20080827114130@gmail.com> References: <1365585749.20080827114130@gmail.com> Message-ID: On Aug 27, 2008, at 3:41 AM, Bulat Ziganshin wrote: > Hello haskell-cafe, > > solving one more task that uses English dictionary, i've thought: > why we don't yet have pure hashtable library? There is imperative > hashtables, pretty complex as they need to rebuild entire table as > it grows. There is also simple assoc lists and tree/trie > implementations, but there is no simple non-modifiable hashes. I know that Lennart had such a hashtable implementation as part of the hbcc source tree (so dating back to the late stream age or the very very early monad age), though I think it relied upon hbc's LazyArray. One obvious way to make non-modifiable hash tables useful is to "eat your own tail" non-strictly--- aggregate a set of hash table entries, construct a hash table from them, and plumb the resulting hash table into the original computation by tying the knot. This works really well if you can construct the bucket lists lazily and if you specify the table size up front. You can't make this trick work at all for tree-based maps in general, because the structure of the tree depends upon all the keys inserted. You also can't make this trick work if you base the size of the hash table on the number of keys inserted, maximum bucket load, etc. Finally, it doesn't work with strict arrays at all. So a nice niche for a small and clever static hash table. -Jan From frank at geoinfo.tuwien.ac.at Wed Aug 27 08:40:07 2008 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Wed Aug 27 08:38:46 2008 Subject: [Haskell-cafe] best runProcess solution to work with windows and linux Message-ID: <1219840807.6803.3.camel@bernH> i use System.POSIX.IO to run a process and access the handles (after due transformation) to get the values back. this solution is unfortunately not portable and works only on unix (or cygwin) but not for plain windows. there seems to be a somewhat comparable package in system.win32.process. is there a solution independent of OS? what is the best approach to use to run a process and read the result back which works in both unix and windows? any suggestion highly appreciated! andrew From ahey at iee.org Wed Aug 27 09:15:14 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 27 09:13:50 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> Message-ID: <48B55362.7040104@iee.org> Judah Jacobson wrote: > I've been wondering: is there any benefit to having top-level ACIO'd > <- instead of just using runOnce (or perhaps "oneshot") as the > primitive for everything? For example: > > oneshot uniqueRef :: IO (MVar Integer) > uniqueRef =< newMVar 0 I've been wondering about something like this too (in some way just have a oneShot or runOnce and the *only* thing in ACIO as a magic primitive). runOnce :: IO a -> ACIO (IO a) It would certainly simplify the ACIO monad :-), but I'm not sure it's really as flexible. Provided newMVar can be ACIO then this can be implemented directly (doesn't need to be a primitive). But we can't go the other way round (use runOnce to create genuine top level MVars or channels say). Does that matter? Probably not for monadic IO code. It's not a huge inconvenience to write.. do ... thing <- getThing foo thing vs.. do ... foo thing -- thing is at top level But for top level non monadic code/expressions/data structures I can see a certain convenience in having thing as top level identifier if possible, which it often won't be anyway I guess for other reasons (like it's creation and initialisation requires real IO). So I don't have any particularly strong opinion either way. In practice if thing (or getThing) is to be exported then it would probably be prudent to assume creation and initialisation might require real IO at some point in the future even if they don't right now, so you'd export getThing (= return thing) anyway, rather then have an exported thing dissappear from the API at some point. My 2p.. Regards -- Adrian Hey From darrinth at gmail.com Wed Aug 27 10:11:06 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Wed Aug 27 10:09:39 2008 Subject: [Haskell-cafe] Re: [Haskell] Another First course in Haskell In-Reply-To: <48B00564.1030001@imn.htwk-leipzig.de> References: <20080822035347.GA23256@cse.iitk.ac.in> <48B00564.1030001@imn.htwk-leipzig.de> Message-ID: On Sat, Aug 23, 2008 at 8:41 AM, Johannes Waldmann < waldmann@imn.htwk-leipzig.de> wrote: > (*) that's the main problem I see with Hutton's book > http://www.cs.nott.ac.uk/~gmh/book.html: > it has "Declaring types and classes" as chapter 10 (of 13 total). > I think that's way off - and it leaves readers (students) > with the impression that declarative programming > basically deals with (functions on) lists. > This may have been true in the 70s/80s (LISP, Prolog), > but it certainly shouldn't be true today. > > Recall the proverb "Get your data structures correct first, > and the rest of the program will write itself." > (David Jones, cited in John Bentley: More Programming Pearls) > I think this is independent of language and paradigm. > > If functions on lists isn't the thing, what is the thing? "Data structures" isn't a very satisfactory answer for a n00b like me, because it doesn't capture Haskell's distinctive. I've had this same sense, but in a vague newbie way. This also seems to reflect a growing dissatisfaction with the prelude. Back in the day lazy lists were the thing and the Prelude seems to largely reflect that. Now it's something else I can't possibly articulate. But I can definitely see it trying to replace a significant amount of prelude functionality. Witness that nobody loves strings anymore because ByteStrings are cooler. The stream/fusion lists are way cooler than the stock lists. etc. Or I have no idea what I'm talking about. -- Darrin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/89d96b3e/attachment.htm From john at repetae.net Wed Aug 27 10:13:30 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 10:12:04 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B55362.7040104@iee.org> References: <7fb8f82f0808250743wb7b7fablc2c6d2188e863dfa@mail.gmail.com> <48B2D5D9.8020608@iee.org> <20080826020325.GB15616@sliver.repetae.net> <48B3ABAC.5040905@iee.org> <6d74b0d20808260114ta051c9cm5531b683d320d7fb@mail.gmail.com> <48B55362.7040104@iee.org> Message-ID: <20080827141329.GS15616@sliver.repetae.net> I think a strong advantage of the straight up ACIO formulation (rather than a one-shot IO based thing) is that it can be fully, correctly, and safely be defined without referencing the IO monad or its interaction with the IO monad at all. In practice, ACIO will be generally be used to interact with IO code. But being able to formalize it completely independently of the IO monad and all the IO monad entails is an enticing posibility. John -- John Meacham - ?repetae.net?john? From ndmitchell at gmail.com Wed Aug 27 10:27:00 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Aug 27 10:25:32 2008 Subject: [Haskell-cafe] Re: [Haskell] Another First course in Haskell In-Reply-To: <48B00564.1030001@imn.htwk-leipzig.de> References: <20080822035347.GA23256@cse.iitk.ac.in> <48B00564.1030001@imn.htwk-leipzig.de> Message-ID: <404396ef0808270727o4be62795m572419dc5a68e3b1@mail.gmail.com> Hi > (*) that's the main problem I see with Hutton's book > http://www.cs.nott.ac.uk/~gmh/book.html : > it has "Declaring types and classes" as chapter 10 (of 13 total). > I think that's way off - and it leaves readers (students) > with the impression that declarative programming > basically deals with (functions on) lists. > This may have been true in the 70s/80s (LISP, Prolog), > but it certainly shouldn't be true today. That book is about teaching Haskell, not advertising it. If I wanted to advertise how cool Haskell was, I probably wouldn't dwell on lists. But to learn Haskell, I spent the first few years doing either list processing or very simple algebraic data types, and I think it made me a better programmer as a result. If you want to program Haskell, get the basics sorted. Once you have sorted the basics of functional programming, you can move on to the Haskell specific bits. The course I learnt from at York left out things such as modules, type classes (beyond slight Eq/Ord signatures), monads, IO (other than interact) and anything not in Haskell 98. What it did cover very well was functional programming and functional reasoning. Thanks Neil From waldmann at imn.htwk-leipzig.de Wed Aug 27 10:31:15 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Aug 27 10:31:54 2008 Subject: [Haskell-cafe] Re: [Haskell] Another First course in Haskell In-Reply-To: References: <20080822035347.GA23256@cse.iitk.ac.in> <48B00564.1030001@imn.htwk-leipzig.de> Message-ID: <48B56533.1080709@imn.htwk-leipzig.de> Darrin Thompson wrote: > If functions on lists isn't the thing, what is the thing? "Data structures" > isn't a very satisfactory answer for a n00b like me, because it doesn't > capture Haskell's distinctive. [...] Well indeed you can (should) have problem-specific (algebraic) data types in any language. In Haskell it's just a "data" declaration, while in OO design they call it the "compositum" pattern (and need some hundred more lines to write it down). What is "distinctively Haskell"? The focus in teaching could be: (1) data abstraction (-> functions, -> higher order functions) (2) type abstraction (-> type constructors, polymorphism etc.) ... and of course all the benefits from abstraction (=> re-usability) and strong typing (=> safety). J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/c6d085f3/signature.bin From ndmitchell at gmail.com Wed Aug 27 10:37:37 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Aug 27 10:36:09 2008 Subject: [Haskell-cafe] Re: [Haskell] Another First course in Haskell In-Reply-To: <404396ef0808270727o4be62795m572419dc5a68e3b1@mail.gmail.com> References: <20080822035347.GA23256@cse.iitk.ac.in> <48B00564.1030001@imn.htwk-leipzig.de> <404396ef0808270727o4be62795m572419dc5a68e3b1@mail.gmail.com> Message-ID: <404396ef0808270737k77b97f84g48b82aa0cffdd49b@mail.gmail.com> > That book is about teaching Haskell, not advertising it. If I wanted > to advertise how cool Haskell was, I probably wouldn't dwell on lists. > But to learn Haskell, I spent the first few years doing either list > processing or very simple algebraic data types, and I think it made me > a better programmer as a result. > > If you want to program Haskell, get the basics sorted. Once you have > sorted the basics of functional programming, you can move on to the > Haskell specific bits. The course I learnt from at York left out > things such as modules, type classes (beyond slight Eq/Ord > signatures), monads, IO (other than interact) and anything not in > Haskell 98. What it did cover very well was functional programming and > functional reasoning. Of course, after teaching these bits, say towards the end of a course or in a Real World Haskell book, the extra Haskell bits should definately be covered! They are what makes a Haskell programmer, but not what makes a functional programmer. Thanks Neil From philip.weaver at gmail.com Wed Aug 27 10:47:53 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Wed Aug 27 10:46:25 2008 Subject: [Haskell-cafe] best runProcess solution to work with windows and linux In-Reply-To: <1219840807.6803.3.camel@bernH> References: <1219840807.6803.3.camel@bernH> Message-ID: On Wed, Aug 27, 2008 at 5:40 AM, Andrew U. Frank wrote: > i use System.POSIX.IO to run a process and access the handles (after due > transformation) to get the values back. > this solution is unfortunately not portable and works only on unix (or > cygwin) but not for plain windows. there seems to be a somewhat > comparable package in system.win32.process. > is there a solution independent of OS? what is the best approach to use > to run a process and read the result back which works in both unix and > windows? > The System.Process module works well on both unix and windows: http://hackage.haskell.org/packages/archive/process/1.0.0.0/doc/html/System-Process.html > > any suggestion highly appreciated! > > andrew > > > _______________________________________________ > 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/20080827/88af2cf3/attachment.htm From marco-oweber at gmx.de Wed Aug 27 11:07:18 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Aug 27 11:05:54 2008 Subject: [Haskell-cafe] HEq and Context reduction stack overflow In-Reply-To: References: <20080826001102.GA1625@gmx.de> Message-ID: <20080827150718.GA18263@gmx.de> On Mon, Aug 25, 2008 at 09:17:19PM -0400, jeff p wrote: > The HList paper (http://homepages.cwi.nl/~ralf/HList/) presents a Thanks Jeff -- packages: HList {-# OPTIONS_GHC -fallow-undecidable-instances -XEmptyDataDecls -XMultiParamTypeClasses #-} module Main where import Data.HList import HAppS.Data import System.Environment class TypeToNat typE nr | typE -> nr instance ( TypeToNat a elNr , TypeToNat b elNr' , HEq elNr elNr' r) => HEq a b r data Id_A instance TypeToNat Id_A HZero data Root_T instance TypeToNat Id_A nr => TypeToNat Root_T (HSucc nr) main = do putStrLn (show (undefined :: (HEq Id_A Id_A a) => a )) || [1 of 1] Compiling Main ( test.hs, test.o ) || test.hs|19 error| || Context reduction stack overflow; size = 20 || Use -fcontext-stack=N to increase stack size to N || `$dHEq :: {HEq elNr elNr' a}' || arising from instantiating a type signature at test.hs:20:18-52 || `$dHEq :: {HEq elNr elNr' a}' However adding a dummy type T works fine: -- packages: HList {-# OPTIONS_GHC -XEmptyDataDecls -XMultiParamTypeClasses -fallow-undecidable-instances #-} module Main where import Data.HList import HAppS.Data import System.Environment data T a class TypeToNat typE nr | typE -> nr instance ( TypeToNat a elNr , TypeToNat b elNr' , HEq elNr elNr' r) => HEq (T a) (T b) r data Id_A instance TypeToNat Id_A HZero data Root_T instance TypeToNat Id_A nr => TypeToNat Root_T (HSucc nr) main = do putStrLn (show (undefined :: (HEq (T Id_A) (T Id_A) a) => a )) I don't see what's wrong with the first version.. Can you help me understand this implicationa ? Sincerly Marc Weber From ahey at iee.org Wed Aug 27 11:08:09 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Aug 27 11:06:53 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <55D891AF-8197-45CD-AB7D-FC593EC5BCE3@gmail.com> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <48B50B42.6010306@iee.org> <48B5164D.3040507@iee.org> <55D891AF-8197-45CD-AB7D-FC593EC5BCE3@gmail.com> Message-ID: <48B56DD9.5040404@iee.org> Lennart Augustssom wrote: > Since at some point you have to interface with the hardware you are > forced to obey whatever convention is used for interrupts etc. At that > point you may very well have to use global variables. But you can > quickly abstract away from that in stay in the safe land without globals. BTW, did you notice that the non-hosted driver API example I put on the wiki page doesn't use "globals" either :-) The two device handles are at the top level (are "globals" as you would say), but the driver code takes these as an argument so doesn't care if they're top level or not. If I don't have the device handles at the top level or some means to get them from the top level then I have no alternative but to export createDeviceHandle either directly to the "user level" API (really bad!) or to some other bit of higher level system code that can be trusted not to create 2 or more handles for the same device (and no handles for non-existant devices). Let's assume it's that latter. In the simple case where it is known at compile time that there are exactly 2 devices in the system at known base addresses, can you explain how the higher level bit of the system guarantees that user level application code will only ever have access to 2 different device handles in total (one for each device), no matter what? How does it solve this problem in the more complex complex case where hardware must be probed somehow to discover how many devices there are and where they are? All without using any global variables please. Also, assuming you succeed, please explain what advantages or extra safety your solution provides over a solution which does use global variables. The obvious solution seems to be to have this code present this function to the user level API.. getAvailableDeviceHandles :: IO [DeviceHandle] Which shouldn't be hard to implement in either case, except for the fact IO state "getters" can't be implemented at all without top level mutable state or runOnce primitives or something like that (AFAICS). newAvailableDeviceHandles perhaps? I guess that could come in handy if the user code decides it doesn't like the old ones for some reason :-) Regards -- Adrian Hey From allbery at ece.cmu.edu Wed Aug 27 11:10:11 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 27 11:08:50 2008 Subject: [Haskell-cafe] Re: apparent minor bug in "Getting started" tutorial at "Haskell Hacking: a journal of Haskell programming" In-Reply-To: <6b0ab4tqopjqh1i57o90mqc64n386n5nkb@4ax.com> References: <6b0ab4tqopjqh1i57o90mqc64n386n5nkb@4ax.com> Message-ID: <9F49EAAB-007E-4675-82C5-7D42FB56D302@ece.cmu.edu> On 2008 Aug 27, at 3:28, Benjamin L.Russell wrote: > On Wed, 27 Aug 2008 16:22:56 +0900, Benjamin L.Russell > wrote: > > Sorry, what I really meant was not to update the reference to "a.out" > to be changed to "main.exe", but to change the following line: > >>> This produces a new executable, ./a.out (a.out.exe on windows), >>> which you can run like any other program on your system: > > to read as follows: > >>> This produces a new executable, ./a.out (main.exe on windows), >>> which you can run like any other program on your system: > > There was no "a.out.exe" on Windows, but only a "main.exe". Both the Unix and Windows examples need to be changed, actually; IIRC that behavior changed with 6.8. -- 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 gale at sefer.org Wed Aug 27 11:11:37 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Aug 27 11:10:11 2008 Subject: [Haskell-cafe] 2 modules in one file In-Reply-To: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> Maur??cio wrote: >> Is it allowed to write two >> different modules in a single >> file? That would be a really nice feature, especially since modules are Haskell's only encapsulation tool. You want it to be a lightweight as possible. Malcolm Wallace wrote: > Some compilers permit it (e.g. Freja), most do not (e.g. ghc). The > Language Report makes no specification for the mapping between module > sources and the files that contain them. The Hierarchical Module Namespace Extension addendum to the Haskell 98 Report http://www.haskell.org/hierarchical-modules/ recommends, but does not require, a Java-like mapping between hierarchical module names and and the filesystem. In particular, compilers complying with that recommendation require there to be only one module per file. Most compilers do comply. In my opinion, that is a bad policy. It is fine as a simple default for small projects, even though it's a bit ugly and ad hoc. (For example - what does this mean on platforms whose filesystem is not hierarchical?) But for large and complex projects, this policy really complicates the task of the project manager who wants to be able to present various views of the source to teams working on different subprojects, while juggling the version control in an intelligent way. Directory tree structure is sometimes the perfect tool for that, but Haskell has stolen it away. It would be nice if compilers would offer, as an optional alternative, a system of locating modules based on manifest files. That would then allow multiple modules per source file. Regards, Yitz From waldmann at imn.htwk-leipzig.de Wed Aug 27 11:13:58 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Aug 27 11:14:35 2008 Subject: [Haskell-cafe] Re: [Haskell] Another First course in Haskell In-Reply-To: <404396ef0808270737k77b97f84g48b82aa0cffdd49b@mail.gmail.com> References: <20080822035347.GA23256@cse.iitk.ac.in> <48B00564.1030001@imn.htwk-leipzig.de> <404396ef0808270727o4be62795m572419dc5a68e3b1@mail.gmail.com> <404396ef0808270737k77b97f84g48b82aa0cffdd49b@mail.gmail.com> Message-ID: <48B56F36.10709@imn.htwk-leipzig.de> Neil Mitchell wrote: >> If you want to program Haskell, get the basics sorted. Once you have >> sorted the basics of functional programming, you can move on to the >> Haskell specific bits. The course I learnt from at York left out >> things such as modules, type classes (beyond slight Eq/Ord >> signatures), monads, IO (other than interact) and anything not in >> Haskell 98. I think what you describe as "basics" is "basics of programmning" (i.e. how to write one "toy" function) and sure this is important. But I think the other topics (modules, classes, monads, extra libraries) are equally important because they are "basics of software engineering" (how to write/organize a bunch of functions that do some "real" work). I wouldn't call these "Haskell specific" because the underlying concepts are perfectly general - and if you leave them out, students will ask for them because they already know Java has a module system, and interfaces, etc. and they have been trained early to use this (this is basic undergraduate CS stuff, no?) Perhaps you're saying that *because* students already know that, one shouldn't spend too much time on it in a Haskell course. Agreed, but then my conclusion is to use e.g. (hierarchical) modules right from the start. I generally tell my students that Haskell has about everything you would expect from a modern general-purpose programming language (that's where I'd put modules, classes, libraries) *plus* additional benefits: more efficiency (in writing - you need less code because you have more ways of abstraction) and more safety (because of strong typing). This does not contradict what you write. Indeed one can practice abstraction and typing rules using functions over lists of lists of ints. Problem is that afterwards, the student knows about functions and types but still has to unlearn the habit of coding everything as lists of lists of ints... J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/0fbe14a7/signature.bin From jules at jellybean.co.uk Wed Aug 27 11:21:46 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Aug 27 11:20:18 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1365585749.20080827114130@gmail.com> References: <1365585749.20080827114130@gmail.com> Message-ID: <48B5710A.40101@jellybean.co.uk> Bulat Ziganshin wrote: > Hello haskell-cafe, > > solving one more task that uses English dictionary, i've thought: why we don't yet have pure hashtable library? There is imperative hashtables, pretty complex as they need to rebuild entire table as it grows. There is also simple assoc lists and tree/trie implementations, but there is no simple non-modifiable hashes. > > how should it look: > * hashtable is represented as an array of assoc lists: Array Int [(a,b)] > > * interface to extract data from ht is the same as from assoc list: > lookup :: HT a b -> a -> Maybe b > > * ht may be built from assoc list. we should just know it's size beforehand in order to create Array of reasonable size. constructor also need a hashing function: > > create :: [(a,b)] -> Int -> (a->Int) -> HT a b > > > given these constraints, it should be just a 10-20 lines of code, and provide much better efficiency than any tree/trie implementations Prove it. To get "much better efficient" than a trie, the hash function has to be so fast that it is faster than following (log n) pointers, and yet also so "perfect" that it doesn't generate too many collisions. As you correctly say, a simple implementation is easy to do, so why not do it and see how it performs? :) Jules From nhn at Cs.Nott.AC.UK Wed Aug 27 11:42:23 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Wed Aug 27 11:43:40 2008 Subject: [Haskell-cafe] 2 modules in one file In-Reply-To: <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> Message-ID: <48B575DF.8000300@cs.nott.ac.uk> Hi, Yitzchak Gale wrote: > But for large and complex projects, this policy really complicates > the task of the project manager who wants to be able to > present various views of the source to teams working on > different subprojects, while juggling the version control > in an intelligent way. Directory tree structure is sometimes > the perfect tool for that, but Haskell has stolen it away. > It would be nice if compilers would offer, as an optional alternative, > a system of locating modules based on manifest files. > That would then allow multiple modules per source file. Not that it is of any practical relevance now, but this was exactly the thinking behind the design (some 10 - 15 years ago, time flies!) of how Freja manages files and modules, as Malcolm mentioned. I believe a clear separation between a language and aspects of the environment in which programs are developed, such as file systems, is a good thing. And while the Haskell standard as such respects this, I've always found the fact that most tools rely on naming conventions for mapping names of modules to names of files very unfortunate. Hierarchical modules makes this even worse: what says that I necessarily want the module hierarchy reflected in the directory hierarchy? And indeed, as Yitzchak said, what about non-hierarchical file systems, or maybe storing source code by completely different means? And there are also potential issues with not every legal module name being a legal file name across all possible file systems. So, yes, a system of locating modules based on manifest files would be great. I'd use it all the time whenever possible, and never look back! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From bulat.ziganshin at gmail.com Wed Aug 27 11:36:05 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 11:44:52 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B5710A.40101@jellybean.co.uk> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> Message-ID: <1806696757.20080827193605@gmail.com> Hello Jules, Wednesday, August 27, 2008, 7:21:46 PM, you wrote: >> given these constraints, it should be just a 10-20 lines of code, and provide much better efficiency than any tree/trie implementations > Prove it. > To get "much better efficient" than a trie, the hash function has to be > so fast that it is faster than following (log n) pointers afaiu, trie search follows n pointers - i.e. every char in string forms a new trie level. add to this that every search need to scan a list of all possible chars - or you need to use the same hashing. so, we have the following lookup times: trie: O(len)*O(width) hashed trie: O(len) hash: O(len) where len is length of string searched and width is average amount of chars at each trie level -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jed at 59A2.org Wed Aug 27 11:55:41 2008 From: jed at 59A2.org (Jed Brown) Date: Wed Aug 27 11:54:17 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B5710A.40101@jellybean.co.uk> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> Message-ID: <20080827155541.GB9785@brakk.ethz.ch> On Wed 2008-08-27 16:21, Jules Bean wrote: > Bulat Ziganshin wrote: >> Hello haskell-cafe, >> >> solving one more task that uses English dictionary, i've thought: why we don't yet have pure hashtable library? There is imperative hashtables, pretty complex as they need to rebuild entire table as it grows. There is also simple assoc lists and tree/trie implementations, but there is no simple non-modifiable hashes. >> >> how should it look: >> * hashtable is represented as an array of assoc lists: Array Int [(a,b)] >> >> * interface to extract data from ht is the same as from assoc list: >> lookup :: HT a b -> a -> Maybe b >> >> * ht may be built from assoc list. we should just know it's size beforehand in order to create Array of reasonable size. constructor also need a hashing function: >> >> create :: [(a,b)] -> Int -> (a->Int) -> HT a b >> >> >> given these constraints, it should be just a 10-20 lines of code, and provide much better efficiency than any tree/trie implementations > > Prove it. > > To get "much better efficient" than a trie, the hash function has to be > so fast that it is faster than following (log n) pointers, and yet also > so "perfect" that it doesn't generate too many collisions. Many people have probably seen this and it has nothing to do with Haskell, but it is a good performance comparison of a simple hash to an optimized trie. http://www.nothings.org/computer/judy/ The conclusion (we're only interested in lookup times) is that the trie is preferable for sequential lookups, slower for random access hits, and about the same for random access misses. Also, the hash was uniformly better for small sizes (< 10k). BTW a single cache miss has a latency around 250 cycles, you can compute a hell of a hash for that. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/124b1cf0/attachment.bin From daniel.is.fischer at web.de Wed Aug 27 12:01:24 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Aug 27 11:57:54 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1806696757.20080827193605@gmail.com> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> Message-ID: <200808271801.24909.daniel.is.fischer@web.de> Am Mittwoch, 27. August 2008 17:36 schrieb Bulat Ziganshin: > Hello Jules, > > Wednesday, August 27, 2008, 7:21:46 PM, you wrote: > >> given these constraints, it should be just a 10-20 lines of code, and > >> provide much better efficiency than any tree/trie implementations > > > > Prove it. > > > > To get "much better efficient" than a trie, the hash function has to be > > so fast that it is faster than following (log n) pointers > > afaiu, trie search follows n pointers - i.e. every char in string > forms a new trie level. add to this that every search need to scan a > list of all possible chars - or you need to use the same hashing. so, > we have the following lookup times: > > trie: O(len)*O(width) > hashed trie: O(len) > hash: O(len) Wouldn't the hashtable have lookup time O(len+bucketsize)? > > where len is length of string searched and width is average amount of > chars at each trie level From jules at jellybean.co.uk Wed Aug 27 11:59:55 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Aug 27 11:58:27 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1806696757.20080827193605@gmail.com> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> Message-ID: <48B579FB.40707@jellybean.co.uk> Bulat Ziganshin wrote: > Hello Jules, > > Wednesday, August 27, 2008, 7:21:46 PM, you wrote: > >>> given these constraints, it should be just a 10-20 lines of code, and provide much better efficiency than any tree/trie implementations > >> Prove it. > >> To get "much better efficient" than a trie, the hash function has to be >> so fast that it is faster than following (log n) pointers > > afaiu, trie search follows n pointers No. "n" is the number of strings in my data set (dictionary). If I have "n" strings the average string length is asymptotically, in some sense, "log n". Of course for particular data sets it's may be more . But "log n" is the length of the shortest unique coding, it's also the number of characters you typically need to traverse before you have reached a unique prefix, at which point your trie can short-circuit. I appreciate that I didn't define my terminology ;) You might have a different "n". I repeat my challenge "Prove it". I will be interested to see how much a good immutable hash outperforms Data.Map. I would then also be interested to see how much it outperforms a decent Data.Map (such as your own AVL one) and a decent trie. Jules From dmhouse at gmail.com Wed Aug 27 12:02:48 2008 From: dmhouse at gmail.com (David House) Date: Wed Aug 27 12:01:19 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <874p59m9qa.fsf_-_@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> Message-ID: 2008/8/25 Ketil Malde : > 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file. Is it not an option to make your software work with the not-quite-latest compiler? 6.8 is less than a year old, so I imagine 6.6 is still in quite a few major distro's stable repositories. I don't know the details of what changed with Cabal between 6.6 and 6.8, and you didn't provide any details of what broke, so this might not be an option. But something to consider. -- -David From marco-oweber at gmx.de Wed Aug 27 12:12:28 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Aug 27 12:11:03 2008 Subject: [Haskell-cafe] HEq and Context reduction stack overflow, non optimal ghc behaviour ? In-Reply-To: <20080827150718.GA18263@gmx.de> References: <20080826001102.GA1625@gmx.de> <20080827150718.GA18263@gmx.de> Message-ID: <20080827161228.GB18263@gmx.de> > -- packages: HList > {-# OPTIONS_GHC -fallow-undecidable-instances -XEmptyDataDecls -XMultiParamTypeClasses #-} > module Main where > import Data.HList > import HAppS.Data > import System.Environment > > > class TypeToNat typE nr | typE -> nr > instance ( TypeToNat a elNr > , TypeToNat b elNr' > , HEq elNr elNr' r) => HEq a b r > > data Id_A > instance TypeToNat Id_A HZero > data Root_T > instance TypeToNat Id_A nr => TypeToNat Root_T (HSucc nr) > > main = do > putStrLn (show (undefined :: (HEq Id_A Id_A a) => a )) > > > || [1 of 1] Compiling Main ( test.hs, test.o ) > || > test.hs|19 error| > || Context reduction stack overflow; size = 20 > || Use -fcontext-stack=N to increase stack size to N > || `$dHEq :: {HEq elNr elNr' a}' > || arising from instantiating a type signature at test.hs:20:18-52 > || `$dHEq :: {HEq elNr elNr' a}' I should have added that Data.HList exposes the more specific instances instance HEq HZero HZero HTrue instance HNat n => HEq HZero (HSucc n) HFalse instance HNat n => HEq (HSucc n) HZero HFalse instance (HNat n, HNat n', HEq n n' b ) => HEq (HSucc n) (HSucc n') b That's why I think ghc tries to resolve the wrong instance first: summary: class TypeToNat a b | a -> b class HEq a b c | a b -> c instance ( TypeToNat a elNr -- (1) , TypeToNat b elNr' -- (2) , HEq elNr elNr' r) => HEq a b r -- (3) putStrLn (show (undefined :: (HEq Id_A Id_A a) => a )) When ghc tries to resolve HEq it starts with TypeToNat ( TypeToNat Id_A , TypeToNat Id_A , HEq ) Now ghc can try to resolve (1),(2),(3) in arbitrary order.. What happens if ghc starts with (3)? It tries to find an instance for not known types.. Damn. There is even a matching instance.. , the same one. This time it starts even with HEq which is even more bad! after the second recursion it already knows that won't find a solution, because it will try to resolve HEq again and again.. What happens if ghc starts with (1 or 2)? It happily finds an instance *and* it can even resolve elNr and elNr' Those can then be used to find an instance for (3) easily So I think the behaviour of ghc should be changed to prefer resolving class constraints which reduce the amount of unkown types first I even consider this beeing a bug ? So maybe this thread should be moved to glasgow-haskell-users ? Sincerly Marc Weber From jonathanccast at fastmail.fm Wed Aug 27 12:12:42 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 12:14:51 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B5321F.7030501@iee.org> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> Message-ID: <1219853562.24685.10.camel@jcchost> On Wed, 2008-08-27 at 11:53 +0100, Adrian Hey wrote: > John Meacham wrote: > > As with all design decisions, it is sometimes the right thing and > > sometimes the wrong one. And sometimes the most expedient. (which, > > occasionally, is a perfectly valid driving force behind a certain bit of > > coding). However, I am fully convinced it is necessary. You don't even > > have to look further than Haskell 98 to find a use in the Random module, > > and Data.Unique _depends_ on the state being global for correctness. > > ..and of course there's stdin, stdout. That takes some explaining. Not really. If you don't have buffered IO, then you just say stdin = 0 stdout = 1 stderr = 2 If you need buffered IO, you just change your IO monad* to look like: newtype NewIO alpha = NewIO (ReaderT (Map Fd Buffer) OldIO alpha) Of course, if you do this, you can't go mixing IO with unique values with RNG with mutable state with everything else under the sun anymore. You might actually have to declare exactly what effects you need when you give your function's type, now. Clearly, a horror we must avoid at all costs. jcc * I wonder why that name was chosen? The design doesn't seem to have anything to do with IO, it's more of a `we have this in C so we want it in Haskell too' monad. From bulat.ziganshin at gmail.com Wed Aug 27 12:09:22 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 12:15:04 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <200808271801.24909.daniel.is.fischer@web.de> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <200808271801.24909.daniel.is.fischer@web.de> Message-ID: <122623542.20080827200922@gmail.com> Hello Daniel, Wednesday, August 27, 2008, 8:01:24 PM, you wrote: >> trie: O(len)*O(width) >> hashed trie: O(len) >> hash: O(len) > Wouldn't the hashtable have lookup time O(len+bucketsize)? i suppose that bucketsize=O(1): constructor should get [approximate] size of hashed assoclist and it will select appropriate Array size -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Aug 27 12:19:03 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 12:17:42 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B523D7.3060001@web.de> References: <1365585749.20080827114130@gmail.com> <48B523D7.3060001@web.de> Message-ID: <12210361015.20080827201903@gmail.com> Hello Stephan, Wednesday, August 27, 2008, 1:52:23 PM, you wrote: > and on the other and, its implementation uses hash functions and arrays > as well. IIRC it does that in a state monad that keeps the array mutable > and finally freezes it before usage, which might be a good idea for pure > hash table as well. actually, any building of immutable arrays internally done in this way. we just don't need to write this low-level function ourselves as Array library provides us pure function to build array from list/assoclist -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From brianchina60221 at gmail.com Wed Aug 27 12:26:30 2008 From: brianchina60221 at gmail.com (brian) Date: Wed Aug 27 12:25:02 2008 Subject: [Haskell-cafe] Re: Parsec and network data In-Reply-To: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Message-ID: <22f6a8f70808270926r7c00e9ffuc16868a31e431545@mail.gmail.com> I made a small example related to the problem: http://hpaste.org/9957 It's my attempt to run data from the network directly into Parsec without having to fear deadlock due to blocking. The idea is that we feed Parsec from a timeout-enabled Stream based on Handle. As long as Parsec is able to read the data it wants reasonably quickly, everything is OK. If the remote host stops sending data, we don't hang; we just treat it as a parse error. But the code demonstrates a problem. Why is it doing that? How to fix it? Thanks. From emax at chalmers.se Wed Aug 27 13:02:50 2008 From: emax at chalmers.se (Emil Axelsson) Date: Wed Aug 27 13:01:23 2008 Subject: [Haskell-cafe] ANNOUNCE: Wired 0.1.1 Message-ID: <48B588BA.3050900@chalmers.se> Hello, This is to announce the first release of the hardware description library Wired. Wired can be seen as an extension to Lava that targets (not exclusively) semi-custom VLSI design. A particular aim of Wired is to give the designer more control over the routing wires' effects on performance. The only working backends in this version are simulation and verification (through Lava), and generation of postscript layouts. Soon, there will also be static timing analysis and DEF file generation. The DEF format is accepted by most tools for physical design. Wired is available from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Wired or using Darcs: darcs get http://www.cs.chalmers.se/~emax/darcs/Wired/ There is also a homepage at: http://www.cs.chalmers.se/~emax/wired/index.html Comments, questions, patches are welcome. Cheers, / Emil From ketil at malde.org Wed Aug 27 13:08:02 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Aug 27 13:05:10 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: (David House's message of "Wed\, 27 Aug 2008 17\:02\:48 +0100") References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> Message-ID: <877ia2o07h.fsf@malde.org> "David House" writes: >> 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file. > Is it not an option to make your software work with the > not-quite-latest compiler? Yes it is, although I don't have the details either. Neither do I have an Etch system around, but I should probably install a virtual machine or something. Ideally, I should work out the minimal requirements (including for dependencies, and for dependencies' dependencies), but in practice, I end up depending on whatever is installed on the computer I use. Lazyness bites again. :-) Would it be an idea for hackage to have various "build hosts", automatically trying to compile things on less-than-current installs? -k -- If I haven't seen further, it is by standing in the footprints of giants From derek.a.elkins at gmail.com Wed Aug 27 13:17:46 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Aug 27 13:16:21 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080827093521.GP15616@sliver.repetae.net> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> Message-ID: <1219857466.5819.1.camel@derek-laptop> On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote: [cut] > > However, note the weasel words. Those are in there on purpose, every > design calls for different solutions. To blanketly say certain > constructs are just wrong to the point of disallowing them in the > language, especially when they are common practice at the moment, just > doesn't seem right. How can a Haskell user say this? And this is indeed exactly what capability languages do. In fact, this is what almost every language does (for one thing in common practice or another.) From bremner at unb.ca Wed Aug 27 13:43:24 2008 From: bremner at unb.ca (David Bremner) Date: Wed Aug 27 13:41:57 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <877ia2o07h.fsf@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> <877ia2o07h.fsf@malde.org> Message-ID: <87k5e25p6r.wl%bremner@pivot.cs.unb.ca> Ketil Malde wrote: >Neither do I have an Etch system around, but I should probably >install a virtual machine or something. Ideally, I should >work out the minimal requirements (including for dependencies, and for >dependencies' dependencies), but in practice, I end up depending on >whatever is installed on the computer I use. Lazyness bites again. :-) If you have a Debian (or presumably Ubuntu) machine of some kind, then the package "pbuilder" makes it reasonably easy to set up build environments for particular releases. It is oriented towards building debian packages, but you can "login" to the environment. This is a lot lighter weight than a virtual machine (it uses chroot). David From RafaelGCPP.Linux at gmail.com Wed Aug 27 14:22:05 2008 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Wed Aug 27 14:20:37 2008 Subject: [Haskell-cafe] Is there GHC 6.8.3 on Ubuntu? Message-ID: <351ff25e0808271122o3086a896t671deebe97880cf4@mail.gmail.com> Is there anyone packing GHC 6.8.3 for Ubuntu Hardy? Thanks -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/80e60d65/attachment.htm From briqueabraque at yahoo.com Wed Aug 27 14:23:40 2008 From: briqueabraque at yahoo.com (=?windows-1252?Q?Maur=ED=ADcio?=) Date: Wed Aug 27 14:22:21 2008 Subject: [Haskell-cafe] Haskell symbol ~ Message-ID: Hi, What does '~' mean in Haskell? I read in haskell.org/haskellwiki/Keywords that ?(...) Matching the pattern ~pat against a value always suceeds, and matching will only diverge when one of the variables bound in the pattern is used.? Isn't that true for any variable, due to lazyness? At the same place, I found that example, but wasn't wise enough to figure out what it does: (f *** g) ~(x,y) = (f x, g y) Can you help me understand it? Thanks, Maur?cio From allbery at ece.cmu.edu Wed Aug 27 14:47:13 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 27 14:45:50 2008 Subject: [Haskell-cafe] Haskell symbol ~ In-Reply-To: References: Message-ID: On 2008 Aug 27, at 14:23, Maur? cio wrote: > What does '~' mean in Haskell? I > read in haskell.org/haskellwiki/Keywords > that ?(...) Matching the pattern ~pat > against a value always suceeds, and > matching will only diverge when one of > the variables bound in the pattern is > used.? Isn't that true for any > variable, due to lazyness? Only in let-patterns; others, including case expressions and top level definitions, are strict (which is in fact the normal way to force a value). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Wed Aug 27 14:52:50 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 27 14:51:25 2008 Subject: [Haskell-cafe] timer_create revisited Message-ID: <305A5B4B-850A-4E9B-ADEE-24E397A2998C@ece.cmu.edu> I'm trying to build GHC 6.8.2 (6.8.3 once I get all this nailed down...) from an old bootstrap ghc on SuSE 9.3-64 (yes, I know) because the 6.6.1 and newer binary tarballs for amd64 Linux doesn't work with the "timer_create" issue. The problem is, having built a shiny new 6.8.2 both stage1 and stage2, the result works but compiled programs have the "timer_create" problem. (??) At this point I'm stymied. Suggestions, other than "upgrade" (not currently possible due to commercial software support and timing issues)? -- 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 ndmitchell at gmail.com Wed Aug 27 14:56:56 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Aug 27 14:55:28 2008 Subject: [Haskell-cafe] Haskell symbol ~ In-Reply-To: References: Message-ID: <404396ef0808271156t36e5cb5er72e7ebb58edde954@mail.gmail.com> Hi > At the same place, I found that example, > but wasn't wise enough to figure out > what it does: > > (f *** g) ~(x,y) = (f x, g y) > > Can you help me understand it? It means exactly the same as: (f *** g) xy = (f (fst xy), g (snd xy)) i.e. if you call (f *** g) undefined, you will get (f undefined, g undefined). If the pattern was strict (i.e. no ~) you would get undefined. Please update the keyword wiki so it makes sense to you, after you have got your head round it. Thanks Neil From benja.fallenstein at gmail.com Wed Aug 27 15:11:07 2008 From: benja.fallenstein at gmail.com (Benja Fallenstein) Date: Wed Aug 27 15:09:39 2008 Subject: [Haskell-cafe] Haskell symbol ~ In-Reply-To: References: Message-ID: Hi Maur??cio, I've got one thing to add to the replies so far: On Wed, Aug 27, 2008 at 8:23 PM, Maur??cio wrote: > What does '~' mean in Haskell? I > read in haskell.org/haskellwiki/Keywords > that "(...) Matching the pattern ~pat > against a value always suceeds, and > matching will only diverge when one of > the variables bound in the pattern is > used." Isn't that true for any > variable, due to lazyness? To any variable, yes. But you don't apply it to a variable, you apply it to a constructor pattern: not ~xs but ~(x:xs). Best, - Benja From ryani.spam at gmail.com Wed Aug 27 15:12:12 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Aug 27 15:10:44 2008 Subject: [Haskell-cafe] Haskell symbol ~ In-Reply-To: <404396ef0808271156t36e5cb5er72e7ebb58edde954@mail.gmail.com> References: <404396ef0808271156t36e5cb5er72e7ebb58edde954@mail.gmail.com> Message-ID: <2f9b2d30808271212o4eb3edbax78e9ed4cebdd9b3f@mail.gmail.com> Here is another example: > f1 n ~(x:xs) = (n, x) > f2 n (x:xs) = (n,x) f1 5 [] = (5, error "irrefutable pattern match failure") f2 5 [] = error "pattern match failure" In particular: fst (f1 5 []) = 5 fst (f2 5 []) = error "pattern match failure" The "~" delays the pattern match until evaluation of the variables inside the pattern is demanded. If the variable is never demanded, the pattern match doesn't happen. It's especially useful for single-constructor datatypes (like pairs) if you want the code to be more lazy. -- ryan On Wed, Aug 27, 2008 at 11:56 AM, Neil Mitchell wrote: > Hi > >> At the same place, I found that example, >> but wasn't wise enough to figure out >> what it does: >> >> (f *** g) ~(x,y) = (f x, g y) >> >> Can you help me understand it? > > It means exactly the same as: > > (f *** g) xy = (f (fst xy), g (snd xy)) > > i.e. if you call (f *** g) undefined, you will get (f undefined, g > undefined). If the pattern was strict (i.e. no ~) you would get > undefined. > > Please update the keyword wiki so it makes sense to you, after you > have got your head round it. > > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From cmb21 at kent.ac.uk Wed Aug 27 15:14:23 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Aug 27 15:12:59 2008 Subject: [Haskell-cafe] Haskell symbol ~ In-Reply-To: References: Message-ID: Hi, I may be wrong here, but I don't belive it's just let-patterns that have this property. I.e. what's the difference between... (Just x) = _|_ f = x vs. f = let (Just x) = _|_ in x vs. f = x where (Just x) = _|_ I believe Haskell uses Normal Order Reduction in all these cases. Why is it just let-patterns? Can you give an example? Thanks, Chris. On Wed, 27 Aug 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 27, at 14:23, Maur? cio wrote: > > What does '~' mean in Haskell? I > > read in haskell.org/haskellwiki/Keywords > > that ?(...) Matching the pattern ~pat > > against a value always suceeds, and > > matching will only diverge when one of > > the variables bound in the pattern is > > used.? Isn't that true for any > > variable, due to lazyness? > > Only in let-patterns; others, including case expressions and top level > definitions, are strict (which is in fact the normal way to force a > value). > > From jonathanccast at fastmail.fm Wed Aug 27 15:14:13 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 15:16:24 2008 Subject: [Haskell-cafe] Haskell symbol ~ In-Reply-To: References: Message-ID: <1219864454.24685.12.camel@jcchost> On Wed, 2008-08-27 at 20:14 +0100, C.M.Brown wrote: > Hi, > > I may be wrong here, but I don't belive it's just let-patterns that have > this property. I.e. what's the difference between... > > (Just x) = _|_ > > f = x > > vs. > > f = let (Just x) = _|_ in x > > vs. > > f = x where (Just x) = _|_ > > I believe Haskell uses Normal Order Reduction in all these cases. Why is > it just let-patterns? Can you give an example? Those are all syntax sugar for let patterns. jcc From westondan at imageworks.com Wed Aug 27 15:23:45 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed Aug 27 15:22:19 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> Message-ID: <48B5A9C1.10805@imageworks.com> Tim Docker wrote: > > David Roundy wrote: > >> Which illustrates the point that it's not type safety >> that protects us from segfaults, so much as bounds checking, >> and that's got a non-trivial runtime cost. At least, most >> segfaults that *I've* caused (in C or C++) have been from >> overwriting the bounds of arrays, and that's precisely the problem >> that Haskell does *not* solve using its type system. > > That differs from my experience. Most segfaults that *I've* caused (in > C or C++) have been due to dereferencing null pointers. Type safety > does help you here, in that Maybe lets you distinguish the types of > things that are optionally present from those that must be. > > Tim Huh? Type safety buys you not having to worry about dereferencing stale nonnull pointers (lifetime of reference exceeding lifetime of referent), but nothing about dereferencing null pointers, which are the moral equivalent of Nothing. Failure to handle a null pointer is just like using fromJust and results in the same program termination (undefined). Dan From jonathanccast at fastmail.fm Wed Aug 27 15:21:39 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 15:23:52 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B5A9C1.10805@imageworks.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> Message-ID: <1219864899.24685.14.camel@jcchost> On Wed, 2008-08-27 at 12:23 -0700, Dan Weston wrote: > Tim Docker wrote: > > > > David Roundy wrote: > > > >> Which illustrates the point that it's not type safety > >> that protects us from segfaults, so much as bounds checking, > >> and that's got a non-trivial runtime cost. At least, most > >> segfaults that *I've* caused (in C or C++) have been from > >> overwriting the bounds of arrays, and that's precisely the problem > >> that Haskell does *not* solve using its type system. > > > > That differs from my experience. Most segfaults that *I've* caused (in > > C or C++) have been due to dereferencing null pointers. Type safety > > does help you here, in that Maybe lets you distinguish the types of > > things that are optionally present from those that must be. > > > > Tim > > Huh? Type safety buys you not having to worry about dereferencing stale > nonnull pointers (lifetime of reference exceeding lifetime of referent), > but nothing about dereferencing null pointers, which are the moral > equivalent of Nothing. Actually, that's garbage collection. > Failure to handle a null pointer is just like using fromJust and results > in the same program termination (undefined). jcc From gale at sefer.org Wed Aug 27 15:50:43 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Aug 27 15:49:16 2008 Subject: [Haskell-cafe] 2 modules in one file In-Reply-To: <48B575DF.8000300@cs.nott.ac.uk> References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> <48B575DF.8000300@cs.nott.ac.uk> Message-ID: <2608b8a80808271250p5ab5b6a3t8ea5b8c006c39aba@mail.gmail.com> I have submitted this as Feature Request #2550 http://hackage.haskell.org/trac/ghc/ticket/2550 Please add any comments as appropriate. Thanks, Yitz From cmb21 at kent.ac.uk Wed Aug 27 15:51:39 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Aug 27 15:50:14 2008 Subject: [Haskell-cafe] Haskell symbol ~ In-Reply-To: <1219864454.24685.12.camel@jcchost> References: <1219864454.24685.12.camel@jcchost> Message-ID: I personally think it's bad to start using "let-patterns" as a synonym for general pattern bindings when explaining these concepts. It may be true that it's all transformed into the same thing at core level, but a let expression binds a definition at the expression level, rather than at the equation level; it becomes difficult when we have guards, for example: f pat1 | pat1 == x = x | pat2 == e2 = x where Just x = ... f pat2 = ... g pat1 | pat1 == let Just x = ... in x = let Just x = ... in x | pat2 == e2 = let Just x = ... in x g pat2 = ... In theory x is lazy in f, but computed twice in g. The only way to make the two the same is to introduce a case expression within a let binding -- but then you have to start thinking about things like uncurrying g if it has multiple parameters and its implications with partial applications. Most decent compiler implementations would make a closue for x anyway (if it's a big enough expression to compute), but I think it's certainly worth making the distinction, otherwise new people are going to start thinking they need to define everything using "let" clauses rather than "wheres" for laziness. Regards, Chris. On Wed, 27 Aug 2008, Jonathan Cast wrote: > On Wed, 2008-08-27 at 20:14 +0100, C.M.Brown wrote: > > Hi, > > > > I may be wrong here, but I don't belive it's just let-patterns that have > > this property. I.e. what's the difference between... > > > > (Just x) = _|_ > > > > f = x > > > > vs. > > > > f = let (Just x) = _|_ in x > > > > vs. > > > > f = x where (Just x) = _|_ > > > > I believe Haskell uses Normal Order Reduction in all these cases. Why is > > it just let-patterns? Can you give an example? > > Those are all syntax sugar for let patterns. > > jcc > > > From andrewcoppin at btinternet.com Wed Aug 27 15:59:28 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Aug 27 15:57:59 2008 Subject: [Haskell-cafe] Compiler's bane Message-ID: <48B5B220.4000307@btinternet.com> Hi guys. I'm writing a simple interpretter for a small extended-lambda-calculus sort of language. And I'd just like to say... RECURSIVE LET-BINDS! GAAAAH!!! >_< No other part of the program has consumed nearly as much brain power as me trying to figure out when it is and isn't safe to replace a variable with its RHS. To illustrate: let x = f x; y = 5 in x y A simple-minded interpretter might try to replace every occurrance of "x" with "f x". This yields let y = 5 in (f x) y ...and x is now a free variable. OOPS! Trying to tease out exactly under which conditions you can and cannot perform the substitution is utterly maddening. Since this is a Haskell mailing list and as such it is populated by vast numbers of people with PhDs and so forth... does anybody happen to know the *correct* solution to this conundrum? Before I become clinically insane...? o_O By the way... To all those people who work on projects like GHC and so on, who have to get this stuff right "for real": you have my infinite respect! From dons at galois.com Wed Aug 27 16:00:00 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 27 15:58:46 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <87fxor7xup.fsf@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> <1219680641.4486.15.camel@localhost.localdomain> <87fxor7xup.fsf@malde.org> Message-ID: <20080827200000.GD7196@scytale.galois.com> ketil: > "Jason Dagit" writes: > > >> 2) Compile GHC yourself. > > > I find with Debian this is the way to go. > > Ouch. Okay, I've compiled GHC once. But I would like end-users to be > able to use my software, and I simply cannot require them to go > through this. Yes, scary and unacceptable. -- Don From ndmitchell at gmail.com Wed Aug 27 16:08:51 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Aug 27 16:07:23 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48B5B220.4000307@btinternet.com> References: <48B5B220.4000307@btinternet.com> Message-ID: <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> Hi > I'm writing a simple interpretter for a small extended-lambda-calculus sort > of language. And I'd just like to say... RECURSIVE LET-BINDS! GAAAAH!!! >_< Agreed :-) > To illustrate: > > let x = f x; y = 5 in x y > > A simple-minded interpretter might try to replace every occurrance of "x" > with "f x". This yields > > let y = 5 in (f x) y That's wrong, its a two step transformation. You just substitute all occurances of x for f x: let x = f (f x); y = 5 in (f x) y For the case let x = 5 in x, you do the same thing: let x = 5 in 5 Now as a second step you hoover up unused let bindings and disguard: 5 You seem to be combining the substitution and the removing of dead let bindings, if you separate them you should have more luck. Thanks Neil From john at repetae.net Wed Aug 27 16:16:31 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 16:15:02 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48B5B220.4000307@btinternet.com> References: <48B5B220.4000307@btinternet.com> Message-ID: <20080827201631.GU15616@sliver.repetae.net> On Wed, Aug 27, 2008 at 08:59:28PM +0100, Andrew Coppin wrote: > let y = 5 in (f x) y > > ...and x is now a free variable. OOPS! > > Trying to tease out exactly under which conditions you can and cannot > perform the substitution is utterly maddening. Since this is a Haskell > mailing list and as such it is populated by vast numbers of people with > PhDs and so forth... does anybody happen to know the *correct* solution > to this conundrum? Before I become clinically insane...? o_O A simple solution is to separate your 'substitution' and 'simplification' passes. As in, perform any substitutions you like, but _keep_ the original binding for x. let the simplifier/optimizer recognize when bindings are dead and remove them. It can do so simply by keeping track of free variables in the subterms, which is also useful for things like let floating transformations. John -- John Meacham - ?repetae.net?john? From bremner at unb.ca Wed Aug 27 16:20:49 2008 From: bremner at unb.ca (David Bremner) Date: Wed Aug 27 16:19:22 2008 Subject: [Haskell-cafe] Cleaning up the Debian act (report from the trenches) In-Reply-To: <87fxor7xup.fsf@malde.org> References: <4683d9370808181749y24c2cbc2uc4b125b427fb27db@mail.gmail.com> <20080819012206.GA1191@scytale.galois.com> <1219111367.13639.252.camel@localhost> <87hc9h33c7.fsf@malde.org> <20080819130623.GA16954@matrix.chaos.earth.li> <87r68kg0e3.wl%jeremy@n-heptane.com> <874p59m9qa.fsf_-_@malde.org> <1219680641.4486.15.camel@localhost.localdomain> <87fxor7xup.fsf@malde.org> Message-ID: <87hc965hwe.wl%bremner@pivot.cs.unb.ca> Ketil Malde wrote: >Another Debian question, once I've populated the debian/ directory one >way or another, how should this be integrated with the rest of the >project? Should it be part of the darcs archive, or a separate >archive (foo-debian), or what? How do people organize this? debian-mentors@lists.debian.org is a good place for generic debian packaging questions. After you have a package which works, and which hopefully lintian (a tool for checking debian packages) does not complain about, you can ask on debian-mentors for a sponsor, who will check over the package and hopefully upload it. Right now there is not too much interest in uploading new packages, because people are trying to get lenny out the door. If you like irc, there is also #debian-mentors on irc.oftc.net In general the debian packaging should be maintained separately. There are many different ways to implement this, but the end product (a debian source package) consists of blah.orig.tar.gz, and a blah.diff.gz file that contains all of the debian specific changes. In practice people maintain a seperate version control repo (or branch) for the debian version. John Goerzen has written a tool called darcs-buildpackage, which I haven't used, but which might be helpful for you (there is also git-buildpackage, and svn-buildpackage). David From atomb at galois.com Wed Aug 27 16:34:53 2008 From: atomb at galois.com (Aaron Tomb) Date: Wed Aug 27 16:33:26 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B5A9C1.10805@imageworks.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> Message-ID: <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> On Aug 27, 2008, at 12:23 PM, Dan Weston wrote: > Huh? Type safety buys you not having to worry about dereferencing > stale nonnull pointers (lifetime of reference exceeding lifetime of > referent), but nothing about dereferencing null pointers, which are > the moral equivalent of Nothing. What type safety buys you, in my mind, is that Nothing is only a valid value for explicit Maybe types. In cases where you don't use Maybe, the "null" situation just can't occur. In languages with null pointers, any pointer could possibly be null. When you do use Maybe, you have to explicitly handle the Just and Nothing cases separately. Pattern matching reminds you that both are possible. I tend to view fromJust as a function you should only use if you're _very_, _very_ sure that the Nothing case is impossible. But, if so, why are you using a Maybe type in the first place? Aaron From bulat.ziganshin at gmail.com Wed Aug 27 16:31:08 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 16:38:00 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: References: <1365585749.20080827114130@gmail.com> Message-ID: <1157805913.20080828003108@gmail.com> Hello Jan-Willem, Wednesday, August 27, 2008, 4:06:11 PM, you wrote: > One obvious way to make non-modifiable hash tables useful is to "eat > your own tail" non-strictly--- aggregate a set of hash table entries, > construct a hash table from them, and plumb the resulting hash table > into the original computation by tying the knot. This works really > well if you can construct the bucket lists lazily and if you specify > the table size up front. i think it's impossible since you need to scan whole assoclist to build list of entries for any value of hash function. actually, the same is true for any array building code - while the *values* of array elements may be calculated lazy, *positions* cannot -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jonathanccast at fastmail.fm Wed Aug 27 16:39:38 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 16:41:49 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> Message-ID: <1219869578.24685.19.camel@jcchost> On Wed, 2008-08-27 at 13:34 -0700, Aaron Tomb wrote: > On Aug 27, 2008, at 12:23 PM, Dan Weston wrote: > > > Huh? Type safety buys you not having to worry about dereferencing > > stale nonnull pointers (lifetime of reference exceeding lifetime of > > referent), but nothing about dereferencing null pointers, which are > > the moral equivalent of Nothing. > > What type safety buys you, in my mind, is that Nothing is only a valid > value for explicit Maybe types. In cases where you don't use Maybe, > the "null" situation just can't occur. In languages with null > pointers, any pointer could possibly be null. > > When you do use Maybe, you have to explicitly handle the Just and > Nothing cases separately. Pattern matching reminds you that both are > possible. I tend to view fromJust as a function you should only use if > you're _very_, _very_ sure that the Nothing case is impossible. But, > if so, why are you using a Maybe type in the first place? Consider: substType v ty x = fromJust $ do TyVar s <- cast x guard $ v == s cast ty `mplus` do ForAll s ty' <- cast x guard $ v == s cast $ ForAll s ty' `mplus` do ForAll s ty' <- cast x guard $ s `Set.member` freeTV ty let v' = Set.findMax (freeTV ty `Set.union` freeTV ty') ++ "1" ty'' = substType v ty $ substType s (TyVar v') $ ty' cast $ ForAll v' ty'' `mplus` do ForAll s ty' <- cast x cast $ ForAll s $ substType v ty ty' `mplus` do TyLambda s ty' <- cast x guard $ v == s cast $ TyLambda s ty' `mplus` do TyLambda s ty' <- cast x guard $ s `Set.member` freeTV ty let v' = Set.findMax (freeTV ty `Set.union` freeTV ty') ++ "1" ty'' = substType v ty $ substType s (TyVar v') $ ty' cast $ TyLambda v' ty'' `mplus` do TyLambda s ty' <- cast x cast $ TyLambda s $ substType v ty ty' `mplus` do return $ gmapT (substType v ty) x ForAll :: String -> Type -> Type TyLambda :: String -> Expr -> Expr The last `case' is a catch-all, so you do know the result of the mplus's is a Just, but you still need the Maybe. jcc From daniel.is.fischer at web.de Wed Aug 27 16:49:35 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Aug 27 16:46:03 2008 Subject: [Haskell-cafe] Haskell Propaganda In-Reply-To: <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> References: <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> Message-ID: <200808272249.35184.daniel.is.fischer@web.de> Am Mittwoch, 27. August 2008 22:34 schrieb Aaron Tomb: > On Aug 27, 2008, at 12:23 PM, Dan Weston wrote: > > Huh? Type safety buys you not having to worry about dereferencing > > stale nonnull pointers (lifetime of reference exceeding lifetime of > > referent), but nothing about dereferencing null pointers, which are > > the moral equivalent of Nothing. > > What type safety buys you, in my mind, is that Nothing is only a valid > value for explicit Maybe types. In cases where you don't use Maybe, > the "null" situation just can't occur. In languages with null > pointers, any pointer could possibly be null. > > When you do use Maybe, you have to explicitly handle the Just and > Nothing cases separately. Pattern matching reminds you that both are > possible. I tend to view fromJust as a function you should only use if > you're _very_, _very_ sure that the Nothing case is impossible. But, > if so, why are you using a Maybe type in the first place? Good question. Maybe because you use a function which returns a Maybe result but you know in your use case it's always a Just. But then still a case fun args of Just val -> use val Nothing -> error $ LOCATION ++ " Hey, that ought to be impossible! Go investigate!" would be cleaner. If fromJust is more efficient and this code is called many times in your programme, that could count as a reason. > > Aaron Cheers, Daniel From bulat.ziganshin at gmail.com Wed Aug 27 16:47:38 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 16:46:44 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B579FB.40707@jellybean.co.uk> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <48B579FB.40707@jellybean.co.uk> Message-ID: <1589457071.20080828004738@gmail.com> Hello Jules, Wednesday, August 27, 2008, 7:59:55 PM, you wrote: >>> To get "much better efficient" than a trie, the hash function has to be >>> so fast that it is faster than following (log n) pointers >> >> afaiu, trie search follows n pointers > No. > "n" is the number of strings in my data set (dictionary). > If I have "n" strings the average string length is asymptotically, in > some sense, "log n". Of course for particular data sets it's may be more . > But "log n" is the length of the shortest unique coding, it's also the > number of characters you typically need to traverse before you have > reached a unique prefix, at which point your trie can short-circuit. > I appreciate that I didn't define my terminology ;) You might have a > different "n". > I repeat my challenge "Prove it". I will be interested to see how much a > good immutable hash outperforms Data.Map. > I would then also be interested to see how much it outperforms a decent > Data.Map (such as your own AVL one) and a decent trie. 1) i don't have time/interest to do it, so i just pushed the idea 2) what you have proved there is that for set of n randomly chosen strings trie lookup need O(log n) time - the same is true for hash 3) practical performance of trie will suffer by the need to follow several trie levels each providing several elements to check. OTOH hash lookup will usually need only 1-2 checks, including one check on full string size 4) using ByteString for hash indexes would make lookups much faster -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From emmanuel.delaborde at cimex.com Wed Aug 27 16:49:57 2008 From: emmanuel.delaborde at cimex.com (Emmanuel) Date: Wed Aug 27 16:48:29 2008 Subject: [Haskell-cafe] Problem building the plugins package Message-ID: <761C5A0C-9FC7-428B-B6A6-24B1AAD373F4@cimex.com> Hello I am having troubles building the plugins package : manu:~/Desktop/tmp manu$ cabal install plugins Resolving dependencies... cabal: cannot configure plugins-1.2. It requires ghc >=6.8 There is no available version of ghc that satisfies >=6.8 I am on a Mac PPC (OS X 10.4) with ghc-6.8.2 and Cabal-1.4.0.1 so the error message is puzzling... Can anyone help ? I'd like to install Lambdabot and plugins is one of the dependencies... Thanks Manu From bulat.ziganshin at gmail.com Wed Aug 27 16:53:16 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 16:56:52 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219853562.24685.10.camel@jcchost> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> Message-ID: <1279379444.20080828005316@gmail.com> Hello Jonathan, Wednesday, August 27, 2008, 8:12:42 PM, you wrote: > * I wonder why that name was chosen? The design doesn't seem to have > anything to do with IO, it's more of a `we have this in C so we want it > in Haskell too' monad. s/it/exchange with external world, i.e., essentially, I/O/ -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From john at repetae.net Wed Aug 27 17:00:22 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 16:58:52 2008 Subject: [Haskell-cafe] xmonad on the openmoko mobile phone In-Reply-To: References: <20080809194342.GE3902@scytale.galois.com> Message-ID: <20080827210022.GV15616@sliver.repetae.net> On Sun, Aug 10, 2008 at 08:36:27PM +0400, Miguel Mitrofanov wrote: > > On 9 Aug 2008, at 23:43, Don Stewart wrote: > >> Haskell on the iphone next? > > Did that. Hugs compiles well; GHC will probably too, I just didn't have > time for this. No haskell-specific hacks, only jailbreak. jhc cross compiles to iPhone as well. John -- John Meacham - ?repetae.net?john? From jonathanccast at fastmail.fm Wed Aug 27 16:57:19 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 16:59:30 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1279379444.20080828005316@gmail.com> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> Message-ID: <1219870639.24685.27.camel@jcchost> On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote: > Hello Jonathan, > > Wednesday, August 27, 2008, 8:12:42 PM, you wrote: > > > * I wonder why that name was chosen? The design doesn't seem to have > > anything to do with IO, it's more of a `we have this in C so we want it > > in Haskell too' monad. > > s/it/exchange with external world, i.e., essentially, I/O/ Bald assertion. I don't buy it. What do IORefs have to do with exchange with the external world? jcc From robgreayer at yahoo.com Wed Aug 27 17:01:46 2008 From: robgreayer at yahoo.com (Robert Greayer) Date: Wed Aug 27 17:00:17 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B5A9C1.10805@imageworks.com> Message-ID: <488214.3139.qm@web65706.mail.ac4.yahoo.com> --- On Wed, 8/27/08, Dan Weston wrote: > > Failure to handle a null pointer is just like using > fromJust and results > in the same program termination (undefined). > > Dan > Well, not (IMHO) 'just like': 'fromJust Nothing' turns into a 'catchable' exception in the IO Monad, but a SEGFAULT certainly doesn't. E.g. > import Control.Exception as C > import Data.Maybe > main = do > (fromJust Nothing >>= ( \ s -> putStrLn s)) `C.catch` > (\ _ -> putStrLn "ok") prints 'ok', whereas: > import Foreign.Ptr > import Foreign.Storable > import qualified Control.Exception as E > main = poke nullPtr '\0' `E.catch` (\ _ -> putStrLn "ok") just segfaults... From bulat.ziganshin at gmail.com Wed Aug 27 17:09:38 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 17:08:19 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219870639.24685.27.camel@jcchost> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> Message-ID: <1291026720.20080828010938@gmail.com> Hello Jonathan, Thursday, August 28, 2008, 12:57:19 AM, you wrote: >> s/it/exchange with external world, i.e., essentially, I/O/ > Bald assertion. I don't buy it. What do IORefs have to do with > exchange with the external world? IORefs got their names because they are implemented in IO monad :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jonathanccast at fastmail.fm Wed Aug 27 17:11:35 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 17:13:46 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1291026720.20080828010938@gmail.com> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> <1291026720.20080828010938@gmail.com> Message-ID: <1219871496.24685.29.camel@jcchost> On Thu, 2008-08-28 at 01:09 +0400, Bulat Ziganshin wrote: > Hello Jonathan, > > Thursday, August 28, 2008, 12:57:19 AM, you wrote: > > >> s/it/exchange with external world, i.e., essentially, I/O/ > > > Bald assertion. I don't buy it. What do IORefs have to do with > > exchange with the external world? > > IORefs got their names because they are implemented in IO monad :) But why are they implemented in the IO monad? jcc From dons at galois.com Wed Aug 27 17:15:48 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 27 17:14:18 2008 Subject: [Haskell-cafe] xmonad on the openmoko mobile phone In-Reply-To: <20080827210022.GV15616@sliver.repetae.net> References: <20080809194342.GE3902@scytale.galois.com> <20080827210022.GV15616@sliver.repetae.net> Message-ID: <20080827211548.GH7196@scytale.galois.com> john: > On Sun, Aug 10, 2008 at 08:36:27PM +0400, Miguel Mitrofanov wrote: > > > > On 9 Aug 2008, at 23:43, Don Stewart wrote: > > > >> Haskell on the iphone next? > > > > Did that. Hugs compiles well; GHC will probably too, I just didn't have > > time for this. No haskell-specific hacks, only jailbreak. > > jhc cross compiles to iPhone as well. That's rather exciting. Any chance of a demo on your blog? From daniel.is.fischer at web.de Wed Aug 27 17:20:39 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Aug 27 17:17:06 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219870639.24685.27.camel@jcchost> References: <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> Message-ID: <200808272320.39348.daniel.is.fischer@web.de> Am Mittwoch, 27. August 2008 22:57 schrieb Jonathan Cast: > On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote: > > Hello Jonathan, > > > > Wednesday, August 27, 2008, 8:12:42 PM, you wrote: > > > * I wonder why that name was chosen? The design doesn't seem to have > > > anything to do with IO, it's more of a `we have this in C so we want it > > > in Haskell too' monad. > > > > s/it/exchange with external world, i.e., essentially, I/O/ > > Bald assertion. I don't buy it. What do IORefs have to do with > exchange with the external world? > > jcc > Well, you wrote > change your IO monad* > * I wonder why that name was chosen? The design doesn't seem to have > anything to do with IO, it's more of a `we have this in C so we want it > in Haskell too' monad. I believe, Bulat took it to include getLine, readFile, writeFile et al. From bulat.ziganshin at gmail.com Wed Aug 27 17:23:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 27 17:22:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219871496.24685.29.camel@jcchost> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> <1291026720.20080828010938@gmail.com> <1219871496.24685.29.camel@jcchost> Message-ID: <698600452.20080828012307@gmail.com> Hello Jonathan, Thursday, August 28, 2008, 1:11:35 AM, you wrote: >> IORefs got their names because they are implemented in IO monad :) > But why are they implemented in the IO monad? because they need its features. but i/o may be implemented w/o IORefs. so sequence was: searching for a was to make i/o in Haskell (you can read about this in "History of Haskell"), finding monads as general approach to implement side-effects, naming one of monads used to interact with external world as IO, adding "variables" support to list of operations of this monad -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lennart at augustsson.net Wed Aug 27 17:25:18 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Aug 27 17:23:49 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48B5B220.4000307@btinternet.com> References: <48B5B220.4000307@btinternet.com> Message-ID: You can get rid of all recursive bindings by transforming them into a use of a fixpoint combinator. And then you can use a non-recursive definition of the fixpoint combinator, and never worry about recursive bindings again. -- Lennart On Wed, Aug 27, 2008 at 8:59 PM, Andrew Coppin wrote: > Hi guys. > > I'm writing a simple interpretter for a small extended-lambda-calculus sort > of language. And I'd just like to say... RECURSIVE LET-BINDS! GAAAAH!!! >_< > > No other part of the program has consumed nearly as much brain power as me > trying to figure out when it is and isn't safe to replace a variable with > its RHS. > > To illustrate: > > let x = f x; y = 5 in x y > > A simple-minded interpretter might try to replace every occurrance of "x" > with "f x". This yields > > let y = 5 in (f x) y > > ...and x is now a free variable. OOPS! > > Trying to tease out exactly under which conditions you can and cannot > perform the substitution is utterly maddening. Since this is a Haskell > mailing list and as such it is populated by vast numbers of people with PhDs > and so forth... does anybody happen to know the *correct* solution to this > conundrum? Before I become clinically insane...? o_O > > > > By the way... To all those people who work on projects like GHC and so on, > who have to get this stuff right "for real": you have my infinite respect! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery at ece.cmu.edu Wed Aug 27 17:26:59 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 27 17:25:34 2008 Subject: [Haskell-cafe] Haskell Propaganda In-Reply-To: <200808272249.35184.daniel.is.fischer@web.de> References: <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <200808272249.35184.daniel.is.fischer@web.de> Message-ID: On 2008 Aug 27, at 16:49, Daniel Fischer wrote: > Am Mittwoch, 27. August 2008 22:34 schrieb Aaron Tomb: >> When you do use Maybe, you have to explicitly handle the Just and >> Nothing cases separately. Pattern matching reminds you that both are >> possible. I tend to view fromJust as a function you should only use >> if >> you're _very_, _very_ sure that the Nothing case is impossible. But, >> if so, why are you using a Maybe type in the first place? > > Good question. Maybe because you use a function which returns a > Maybe result > but you know in your use case it's always a Just. But then still a > case fun args of > Just val -> use val > Nothing -> error $ LOCATION ++ " Hey, that ought to be impossible! Go > investigate!" > > would be cleaner. If fromJust is more efficient and this code is > called many > times in your programme, that could count as a reason. I have more than once seen a NULL dereference not get caught until later (admittedly I think most POSIX-like systems unmap page 0 these days; but think of embedded systems or other non-POSIX environments). even fromJust gives you more of an ability to track the problem down in that case. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ganesh at earth.li Wed Aug 27 17:29:28 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed Aug 27 17:27:59 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219853562.24685.10.camel@jcchost> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> Message-ID: On Wed, 27 Aug 2008, Jonathan Cast wrote: > * I wonder why that name was chosen? The design doesn't seem to have > anything to do with IO, it's more of a `we have this in C so we want it > in Haskell too' monad. The 'C' in ACIO says that it commutes with any operation in the IO monad. Without that property you can't safely implement it in a program where the top-level has type IO a. http://www.haskell.org/pipermail/haskell-cafe/2004-November/007664.html Ganesh From mattam at mattam.org Wed Aug 27 17:29:36 2008 From: mattam at mattam.org (Matthieu Sozeau) Date: Wed Aug 27 17:29:04 2008 Subject: [Haskell-cafe] Associative Commutative Unification In-Reply-To: <7687290b0807111902x362c48fehfce32376dc606dd3@mail.gmail.com> References: <7687290b0807061933w6196b9a2hd1f393ecaa8e461e@mail.gmail.com> <20080707023856.GB10461@liouville.galois.com> <7687290b0807080524p11e35860h833463b93be648c8@mail.gmail.com> <20080708123155.GA634@netsoc.tcd.ie> <7687290b0807110539j59234e8br8252d53af8f8749f@mail.gmail.com> <44b20d900807110718j7558a59eu242d3cdab670dd9a@mail.gmail.com> <7687290b0807111902x362c48fehfce32376dc606dd3@mail.gmail.com> Message-ID: Le 12 juil. 08 ? 04:02, John D. Ramsdell a ?crit : >> CIMe[1] might be useful to solve the generated diophantine equations. > > It also has AC unification, and it probably wouldn't be all that hard > to translate our code into OCaml. I think CiME isn't supported > anymore. Still it's worth considering. It's quite large. The source > distribution compiled effortlessly on Ubuntu. That's about all I know > now. CIMe 2 is not maintained anymore, but a third version is in the works, see: http://www3.iie.cnam.fr/~urbain/a3pat/a3pat_intro.en.html -- Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080827/6baf67a2/attachment.htm From nornagon at gmail.com Wed Aug 27 17:32:30 2008 From: nornagon at gmail.com (Jeremy Apthorp) Date: Wed Aug 27 17:31:03 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: References: <48B5B220.4000307@btinternet.com> Message-ID: <14d615330808271432x3d8f9452l4988d6c2fe1ad855@mail.gmail.com> 2008/8/28 Lennart Augustsson : > You can get rid of all recursive bindings by transforming them into a > use of a fixpoint combinator. > And then you can use a non-recursive definition of the fixpoint > combinator, and never worry about recursive bindings again. This[1] might be a good explanation of why that works. It helped me understand it, at least. [1] - http://mvanier.livejournal.com/2897.html Jeremy From duncan.coutts at worc.ox.ac.uk Wed Aug 27 17:32:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 27 17:48:41 2008 Subject: [Haskell-cafe] Re: problem with cabal for syb-with-class In-Reply-To: <01c801c90838$be63eba0$130e7ad5@cr3lt> References: <1219680537.14617.12.camel@bernH> <1219745168.14617.21.camel@bernH> <1219756960.24846.9.camel@localhost> <2d3641330808260630y2558c2d7m70d8cefa1c95a61d@mail.gmail.com> <1219759788.24846.23.camel@localhost> <017801c9078b$781795f0$94407ad5@cr3lt> <1219780914.24846.48.camel@localhost> <01c801c90838$be63eba0$130e7ad5@cr3lt> Message-ID: <1219872741.24846.217.camel@localhost> On Wed, 2008-08-27 at 12:33 +0100, Claus Reinke wrote: > >> Cabal doesn't have to pass on ghc's messages uninterpreted. That's > >> a lot like implementing a map as a list and complaining about empty > >> list instead of element not found. > > > > I see what you're saying, but in practise it's just not possible. GHC > > can return a non-zero exit code for a multitude of reasons (most of > > which will be genuine errors in your source code). It's just not > > practical to parse the error messages that ghc produces and try and > > reinterpret them. I fear it'd quite easy to introduce more problems than > > are solved this way. > > Introducing more problems is quite possible, though changes in error > messages should mostly mean that the rules won't trigger and no > helpful explanation is given. Yes, it if it can degrade gracefully that's not so bad. > And even that could be cured by having the collection of rules > updateable, separately from Cabal itself. Hmm. Yet more work. > What I don't understand are your "in practise it's just not possible" > and "It's just not practical to parse the error messages that ghc produces > and try and reinterpret them". I assume you've tried the code I first > sent some 9 months ago, and again this week, and found that it wouldn't > work for some reasons,but you haven't told me those reasons yet. The easiest reason is that we cannot use regexes in Cabal, but that's really just skirting the issue. The next reason is that it is still a not insignificant effort to integrate this concept. The honest reason is that I don't like the whole approach and I'm not inclined to spend my time on it. I'm not saying I'd reject a working patch against Cabal HEAD, just that I'm not interested it doing it myself. Feel free to file a ticket, attach your proof of concept code and persuade someone to put in the time. If it works and doesn't look like it'd cause more problems than it solves then I'd be happy to apply such a patch. Duncan From jonathanccast at fastmail.fm Wed Aug 27 17:47:10 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 17:49:22 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <200808272320.39348.daniel.is.fischer@web.de> References: <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> <200808272320.39348.daniel.is.fischer@web.de> Message-ID: <1219873630.24685.35.camel@jcchost> On Wed, 2008-08-27 at 23:20 +0200, Daniel Fischer wrote: > Am Mittwoch, 27. August 2008 22:57 schrieb Jonathan Cast: > > On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote: > > > Hello Jonathan, > > > > > > Wednesday, August 27, 2008, 8:12:42 PM, you wrote: > > > > * I wonder why that name was chosen? The design doesn't seem to have > > > > anything to do with IO, it's more of a `we have this in C so we want it > > > > in Haskell too' monad. > > > > > > s/it/exchange with external world, i.e., essentially, I/O/ > > > > Bald assertion. I don't buy it. What do IORefs have to do with > > exchange with the external world? > > > > jcc > > > > Well, you wrote > > > change your IO monad* > > > * I wonder why that name was chosen? The design doesn't seem to have > > anything to do with IO, it's more of a `we have this in C so we want it > > in Haskell too' monad. > > I believe, Bulat took it to include getLine, readFile, writeFile et al. These things existed in Haskell 1.0, before IORefs ever did. jcc From jonathanccast at fastmail.fm Wed Aug 27 17:50:47 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 17:52:58 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <698600452.20080828012307@gmail.com> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> <1291026720.20080828010938@gmail.com> <1219871496.24685.29.camel@jcchost> <698600452.20080828012307@gmail.com> Message-ID: <1219873847.24685.40.camel@jcchost> On Thu, 2008-08-28 at 01:23 +0400, Bulat Ziganshin wrote: > Hello Jonathan, > > Thursday, August 28, 2008, 1:11:35 AM, you wrote: > >> IORefs got their names because they are implemented in IO monad :) > > > But why are they implemented in the IO monad? > > because they need its features. but i/o may be implemented w/o IORefs. > so sequence was: searching for a was to make i/o in Haskell (you can > read about this in "History of Haskell"), finding monads as general > approach to implement side-effects, Note that this was true even in Haskell 1.0: the Haskell report included example code with definitions of (>>=) and return in the context of I/O, but without the explicit recognition of the connection to monads. > naming one of monads used to > interact with external world as IO, adding "variables" support to list > of operations of this monad Do you really think I'm unaware of the history? I know what happened, what I don't understand is, looking at the matter from a language-design perspective circa 2008, IORefs would go in the same monad as Handles. What is the theoretical justification for this, independent of GHC's current implementation of these and their requisite monad(s)? jcc From jonathanccast at fastmail.fm Wed Aug 27 17:55:10 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 17:57:22 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219873847.24685.40.camel@jcchost> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> <1291026720.20080828010938@gmail.com> <1219871496.24685.29.camel@jcchost> <698600452.20080828012307@gmail.com> <1219873847.24685.40.camel@jcchost> Message-ID: <1219874110.24685.46.camel@jcchost> On Wed, 2008-08-27 at 14:50 -0700, Jonathan Cast wrote: > On Thu, 2008-08-28 at 01:23 +0400, Bulat Ziganshin wrote: > > Hello Jonathan, > > > > Thursday, August 28, 2008, 1:11:35 AM, you wrote: > > >> IORefs got their names because they are implemented in IO monad :) > > > > > But why are they implemented in the IO monad? > > > > because they need its features. Oh, and by the way: what `features' of IO do IORefs use? Other than the fact that IO can implement anything in C, of course. jcc From lennart at augustsson.net Wed Aug 27 18:00:12 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Aug 27 17:58:44 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219873847.24685.40.camel@jcchost> References: <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> <1291026720.20080828010938@gmail.com> <1219871496.24685.29.camel@jcchost> <698600452.20080828012307@gmail.com> <1219873847.24685.40.camel@jcchost> Message-ID: IMO, there's no justification for having IORefs etc in the IO monad. They should be in a separate monad. There could then be an operation to lift that monad to the IO monad, if you so wish. But wait, we already have that, it's the ST monad! (So there is no justification.) -- Lennart On Wed, Aug 27, 2008 at 10:50 PM, Jonathan Cast wrote: > On Thu, 2008-08-28 at 01:23 +0400, Bulat Ziganshin wrote: >> Hello Jonathan, >> >> Thursday, August 28, 2008, 1:11:35 AM, you wrote: >> >> IORefs got their names because they are implemented in IO monad :) >> >> > But why are they implemented in the IO monad? >> >> because they need its features. but i/o may be implemented w/o IORefs. >> so sequence was: searching for a was to make i/o in Haskell (you can >> read about this in "History of Haskell"), finding monads as general >> approach to implement side-effects, > > Note that this was true even in Haskell 1.0: the Haskell report included > example code with definitions of (>>=) and return in the context of I/O, > but without the explicit recognition of the connection to monads. > >> naming one of monads used to >> interact with external world as IO, adding "variables" support to list >> of operations of this monad > > Do you really think I'm unaware of the history? I know what happened, > what I don't understand is, looking at the matter from a language-design > perspective circa 2008, IORefs would go in the same monad as Handles. > What is the theoretical justification for this, independent of GHC's > current implementation of these and their requisite monad(s)? > > jcc > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From nonexistent.ftp+haskellcafe at gmail.com Wed Aug 27 18:05:57 2008 From: nonexistent.ftp+haskellcafe at gmail.com (Garrick Chin) Date: Wed Aug 27 18:04:28 2008 Subject: [Haskell-cafe] Building SDL-image package on Windows In-Reply-To: <6205bd290808270140g73615341y5ac542139e560c09@mail.gmail.com> References: <6205bd290808270140g73615341y5ac542139e560c09@mail.gmail.com> Message-ID: Hello, Adding the main macro undef has solved the linker errors and both SDL_image and SDL_ttf build and install correctly now. For both SDL_image and SDL_ttf only the ./Graphics/UI/SDL/Image/Version.hsc file needed to be changed, pasting in the undef macro under "#include SDL_image.h" and "#include SDL_ttf.h" respectively. Thanks for your help! It would probably be a good idea to include these notes in a WIN32 file like for the SDL package for other users. I sent an e-mail to the listed maintainer on Hackage yesterday, is that the best way to about doing this? On Wed, Aug 27, 2008 at 4:40 AM, Bit Connor wrote: > Hi, I wrote the instructions in the WIN32 file. > > This looks like the same problem that I originally had with the SDL > package, mangling of "main" function in C land by the hand of the C > SDL.h include file. > > If you look at the .hsc files from the SDL package, you will see the > fix I applied at the top of each file, after #including SDL.h the evil > "main" macro is undefined: > > #include "SDL.h" > #ifdef main > #undef main > #endif > > Probably the same must be done for all the .hsc files in SDL-image(and > probably also all other haskell SDL addon packages). > > Please let me know if this information is helpful. > > 2008/8/27 Garrick Chin > >: > > Hello, > > > > I'm trying to build the latest SDL-image package (0.5.2) from Hackage on > > Windows and encountering problems. These are the steps I've taken so > far: > > > > 1. Downloaded SDL 1.2.13 developmental library for Mingw32 to > > E:\SDL-1.2.13, and SDL_image 1.2.6 developmental library for VC8 to > > E:\SDL_image-1.2.6. > > 2. Installed SDL package from Hackage, modifying the SDL.cabal according > to > > the included WIN32 readme file and then runghc Setup.lhs > > configure/build/install > > 3. Downloaded the SDL-image package from Hackage, modified the > > SDL-image.cabal file to add the line "Include-Dirs: > > E:\SDL_image-1.2.6\include\SDL, E:\SDL-1.2.13\include\SDL" so Cabal can > find > > the header files. After doing "runghc Setup.lhs configure", "runghc > > Setup.lhs build -v" gives me the following output: > > > > Creating dist\build (and its parents) > > Creating dist\build\autogen (and its parents) > > Preprocessing library SDL-image-0.5.2... > > Creating dist\build\Graphics\UI\SDL\Image (and its parents) > > E:\ghc\ghc-6.8.2\bin\hsc2hs.exe --cc=E:\ghc\ghc-6.8.2\bin\ghc.exe > > --ld=E:\ghc\ghc-6.8.2\bin\ghc.exe --cflag=-package --cflag=SDL-0.5.4 > > --cflag=-package --cflag=base-3.0.1.0 > > --cflag=-IE:\SDL_image-1.2.6\include\SDL > --cflag=-IE:\SDL-1.2.13\include\SDL > > -o dist\build\Graphics\UI\SDL\Image\Version.hs > > Graphics\UI\SDL\Image\Version.hsc > > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined > reference > > to `__stginit_ZCMain' > > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined > reference > > to `ZCMain_main_closure' > > collect2: ld returned 1 exit status > > linking dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o failed > > command was: E:\ghc\ghc-6.8.2\bin\ghc.exe > > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o -o > > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.exe > > > > The results of a limited google search suggests that the __stginit_ZCMain > > linker error has to do with GHC expecting a main function, but I'm not > > really sure how that works in context of a library. > > > > _______________________________________________ > > 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/20080827/39c5e34c/attachment.htm From john at repetae.net Wed Aug 27 18:25:03 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 18:23:34 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219857466.5819.1.camel@derek-laptop> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> Message-ID: <20080827222503.GW15616@sliver.repetae.net> On Wed, Aug 27, 2008 at 12:17:46PM -0500, Derek Elkins wrote: > On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote: > > However, note the weasel words. Those are in there on purpose, every > > design calls for different solutions. To blanketly say certain > > constructs are just wrong to the point of disallowing them in the > > language, especially when they are common practice at the moment, just > > doesn't seem right. > > How can a Haskell user say this? And this is indeed exactly what > capability languages do. In fact, this is what almost every language > does (for one thing in common practice or another.) But as a system designer I *need* things like peek/poke/ACIO etc. I am the one implementing 'Random' or 'Data.Unique'. If I have to resort to C code to do such things, that makes haskell unsuitable for a wide variety of systems programming tasks (including implementing the haskell 98 libraries). I know it is certainly possible to do a lot of things in a capability-based system. but you don't always want or have the ability to use such a system. I am not sure why it was thought netbsd didn't use global state. a simple grep of the kernel headers for '^extern' turns up hundreds of them. even pure capability based systems such as EROS need it for their implementation. What such systems strive for is no or reduced state in their interface. which is a very different thing and also something that I strive for in haskell code. (and is fairly easy to achieve actually) John -- John Meacham - ?repetae.net?john? From jonathanccast at fastmail.fm Wed Aug 27 18:26:51 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Aug 27 18:29:02 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> <1279379444.20080828005316@gmail.com> <1219870639.24685.27.camel@jcchost> <1291026720.20080828010938@gmail.com> <1219871496.24685.29.camel@jcchost> <698600452.20080828012307@gmail.com> <1219873847.24685.40.camel@jcchost> Message-ID: <1219876011.24685.54.camel@jcchost> On Wed, 2008-08-27 at 23:00 +0100, Lennart Augustsson wrote: > IMO, there's no justification for having IORefs etc in the IO monad. > They should be in a separate monad. There could then be an operation > to lift that monad to the IO monad, if you so wish. > But wait, we already have that, it's the ST monad! (So there is no > justification.) Right. We'd have ST (which has the advantage that, if you don't have any free variables of STRef type, your code can be used in a pure context), together with a monad homomorphism stToProgram :: ST RealWorld alpha -> Program alpha We'd also have IO (stripped of IORef, Random, Unique, and other such irrelevant ugliness), together with a monad homomorphism ioToProgram :: IO alpha -> Program alpha Then, the top-level type rule would be Main.main :: Program () We'd flame people for using the Program monad outside of the Main module or monad homomorphisms like ioToProgram or stToProgram. Then, using the functional programming language research of the last 20 years instead of ignoring it for historical reasons, we'd get a free monad homomorphism ioAndStToProgram :: Coproduct IO (ST RealWorld) alpha -> Program alpha which would let you use both in the same program. It doesn't dispense with the need for top-level Program (yet), but it's a step in the right direction. jcc From ben.franksen at online.de Wed Aug 27 18:56:08 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Aug 27 18:54:54 2008 Subject: [Haskell-cafe] Re: Haskell Propaganda References: <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <200808272249.35184.daniel.is.fischer@web.de> Message-ID: Brandon S. Allbery KF8NH wrote: > On 2008 Aug 27, at 16:49, Daniel Fischer wrote: >> Am Mittwoch, 27. August 2008 22:34 schrieb Aaron Tomb: >>> When you do use Maybe, you have to explicitly handle the Just and >>> Nothing cases separately. Pattern matching reminds you that both are >>> possible. I tend to view fromJust as a function you should only use >>> if >>> you're _very_, _very_ sure that the Nothing case is impossible. But, >>> if so, why are you using a Maybe type in the first place? >> >> Good question. Maybe because you use a function which returns a >> Maybe result >> but you know in your use case it's always a Just. But then still a >> case fun args of >> Just val -> use val >> Nothing -> error $ LOCATION ++ " Hey, that ought to be impossible! Go >> investigate!" >> >> would be cleaner. If fromJust is more efficient and this code is >> called many >> times in your programme, that could count as a reason. > > I have more than once seen a NULL dereference not get caught until > later (admittedly I think most POSIX-like systems unmap page 0 these > days; but think of embedded systems or other non-POSIX environments). Oh yes, embedded systems indeed. We have only recently discovered a subtle bug in some C code I wrote years ago where I mixed up the order of two statements. The result was that memory at address zero was overwritten with a string. Interestingly, we /never/ had any segfaults, exceptions, whatever, not even broken behavior of any sort. I discovered the problem only when I explicitly looked at the memory area in question to find out what the system uses as default interrupt handler (yes, this was VxWorks on an 68040, and the interrupt vector table is located at zero). In the end I managed to crash a computer by issuing '1/0' on the shell (apparently the vector for the division by zero fault handler had been overwritten)... however, that was after I already knew there was something bad going on. Note that C compilers are, in principle, free to interpret the value 0, when compared or assigned to a pointer, as any address they like, so in principle the C compiler could 're-map' 0 to some never-mapped memory region. I know of no case where this is done, though. > even fromJust gives you more of an ability to track the problem down > in that case. Definitely. Cheers Ben From lennart at augustsson.net Wed Aug 27 19:15:10 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Aug 27 19:13:41 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080827222503.GW15616@sliver.repetae.net> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> Message-ID: I didn't say NetBSD doesn't use global variables, I said the device driver model doesn't use global variables. And quite a few things that used to be in global variables have been moved into allocated variables and are being passed around instead. That's simply a better way to structure the code. I don't don't think global variables should be banned, I just think they should be severly discouraged. On Wed, Aug 27, 2008 at 11:25 PM, John Meacham wrote: > On Wed, Aug 27, 2008 at 12:17:46PM -0500, Derek Elkins wrote: >> On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote: >> > However, note the weasel words. Those are in there on purpose, every >> > design calls for different solutions. To blanketly say certain >> > constructs are just wrong to the point of disallowing them in the >> > language, especially when they are common practice at the moment, just >> > doesn't seem right. >> >> How can a Haskell user say this? And this is indeed exactly what >> capability languages do. In fact, this is what almost every language >> does (for one thing in common practice or another.) > > But as a system designer I *need* things like peek/poke/ACIO etc. I am > the one implementing 'Random' or 'Data.Unique'. If I have to resort to C > code to do such things, that makes haskell unsuitable for a wide variety > of systems programming tasks (including implementing the haskell 98 > libraries). I know it is certainly possible to do a lot of things in a > capability-based system. but you don't always want or have the ability > to use such a system. > > I am not sure why it was thought netbsd didn't use global state. a > simple grep of the kernel headers for '^extern' turns up hundreds of > them. even pure capability based systems such as EROS need it for their > implementation. What such systems strive for is no or reduced state in > their interface. which is a very different thing and also something that > I strive for in haskell code. (and is fairly easy to achieve actually) > > John > > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery at ece.cmu.edu Wed Aug 27 19:50:22 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 27 19:48:59 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <1219869578.24685.19.camel@jcchost> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <1219869578.24685.19.camel@jcchost> Message-ID: On 2008 Aug 27, at 16:39, Jonathan Cast wrote: > The last `case' is a catch-all, so you do know the result of the > mplus's > is a Just, but you still need the Maybe. I have to admit my thought here is that the problem isn't the Maybe, it's the fromJust. Make it go away, force people to explicitly pattern match so they have to think about it (and hopefully the compiler warns them of the missing pattern). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Wed Aug 27 19:55:43 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 27 19:54:18 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219853562.24685.10.camel@jcchost> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> Message-ID: <738ADE6A-0BEB-4FEF-B296-66533C2314C4@ece.cmu.edu> On 2008 Aug 27, at 12:12, Jonathan Cast wrote: > * I wonder why that name was chosen? The design doesn't seem to have > anything to do with IO, it's more of a `we have this in C so we want > it > in Haskell too' monad. As I understand it, "IO" means "anything not encompassed by equationally-reasoned visible program state". This includes randomness (the IO-based aspect of which requires process or OS state). This also encompasses mutable state (e.g. IORefs), since mutability doesn't fit with equational reasoning. So the name is perhaps poorly chosen, because it only encompasses the most common visible application. (And IORefs particularly so, since they're only so named by analogy with STRefs.) -- 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 john at repetae.net Wed Aug 27 20:07:28 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 20:06:01 2008 Subject: [Haskell-cafe] xmonad on the openmoko mobile phone In-Reply-To: <20080827211548.GH7196@scytale.galois.com> References: <20080809194342.GE3902@scytale.galois.com> <20080827210022.GV15616@sliver.repetae.net> <20080827211548.GH7196@scytale.galois.com> Message-ID: <20080828000728.GX15616@sliver.repetae.net> On Wed, Aug 27, 2008 at 02:15:48PM -0700, Don Stewart wrote: > john: > > On Sun, Aug 10, 2008 at 08:36:27PM +0400, Miguel Mitrofanov wrote: > > > > > > On 9 Aug 2008, at 23:43, Don Stewart wrote: > > > > > >> Haskell on the iphone next? > > > > > > Did that. Hugs compiles well; GHC will probably too, I just didn't have > > > time for this. No haskell-specific hacks, only jailbreak. > > > > jhc cross compiles to iPhone as well. > > That's rather exciting. Any chance of a demo on your blog? I'll see if I can put something together. jhc is in some sense natively a cross compiler, it spits out 100% portable C code by default and you have to work (by using 'foreign' imports on nonportable functions for instance) at breaking cross-compilation. So, for a quick and dirty cross compilation, take the foo_code.c file that jhc generates, the first 3 lines will look something like so: char jhc_c_compile[] = "gcc '-std=gnu99' -D_GNU_SOURCE '-falign-functions=4' -ffast-math -Wshadow -Wextra -Wall -Wno-unused-parameter -DNDEBUG -O3 -fomit-frame-pointer"; char jhc_command[] = "jhc --noauto -v --ho-dir regress/results/ho --noauto -i./lib/base -i./lib/haskell98 -flint -o enum enum.hs"; char jhc_version[] = "jhc 0.5.20080307 (eogmidkiv-1)"; and just change the 'gcc' in the jhc_c_compile line to gcc-iphone-arm or whatever and run it on the command line. I usually only test on linux so I occasionally accidentally break cross compilation, but it is generally easy to fix. I try to test on Mac OSX, solaris, and OpenBSD when possible as that gives a nice wide range. Of course, you probably want to use some Mac OSX framework features, which will require writing some foreign bindings, but I endevour to ensure that if you only use haskell 98 or haskell' features (or your library is built on top of said features) then jhc's output is pure, portable (in practice), C. John -- John Meacham - ?repetae.net?john? From timd at macquarie.com.au Wed Aug 27 21:13:35 2008 From: timd at macquarie.com.au (Tim Docker) Date: Wed Aug 27 21:12:10 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <48B5A9C1.10805@imageworks.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com><9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> Message-ID: <9A015D433594EA478964C5B34AF3179B0109A270@ntsydexm06.pc.internal.macquarie.com> Dan Weston wrote: > Tim Docker wrote: > > > That differs from my experience. Most segfaults that *I've* caused (in > > C or C++) have been due to dereferencing null pointers. Type safety > > does help you here, in that Maybe lets you distinguish the types of > > things that are optionally present from those that must be. > > Huh? Type safety buys you not having to worry about dereferencing stale nonnull > pointers (lifetime of reference exceeding lifetime of referent), but nothing > about dereferencing null pointers, which are the moral equivalent of Nothing. > > Failure to handle a null pointer is just like using fromJust and results in > the same program termination (undefined). Well as someone else pointed out, you can reliably catch a pattern match failure. You may or may not be able to catch a segfault. But my point is that haskell trivially lets you distinguish between values (type X), and nullable values (type Maybe X), and doing so is standard practice when using the language. The compiler will disallow any inconsistency in the use of these two types. C however, does not have a compile time distinction between a pointer to a value that might be null, and one that is guaranteed not to be null. The code writer must track this distinction manually. Mistakes result in segvs, not compile errors. Tim From ok at cs.otago.ac.nz Wed Aug 27 21:28:46 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Aug 27 21:27:23 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> Message-ID: Someone wrote: >> >> trie: O(len)*O(width) >> hashed trie: O(len) >> hash: O(len) If "width" here refers to the branching factor of the trie, it's actually O(len.lg(width)), and the width that matters is not the *possible* number of choices but the *actual* number. The great problem with hash tables is devising good hash functions. There is a vast literature about hash tables, but there is very little about how to design good hash functions for anything other than numbers and maybe strings. It would be nice to think that _had__ there been plenty of good advice about constructing good hash functions the Java library implementors would have taken it. As it is, their hashing functions for collections leave much to be desired. From ok at cs.otago.ac.nz Wed Aug 27 21:46:41 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Aug 27 21:45:18 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <12697_1219869313_m7RKZCTi011219_63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <12697_1219869313_m7RKZCTi011219_63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> Message-ID: On 28 Aug 2008, at 8:34 am, Aaron Tomb wrote: > What type safety buys you, in my mind, is that Nothing is only a > valid value for explicit Maybe types. In cases where you don't use > Maybe, the "null" situation just can't occur. In languages with null > pointers, any pointer could possibly be null. This is not true of Eiffel. The ECMA Eiffel standard has ?T either a void reference or a reference to an instance of T !T a reference to an instance of T T same as !T in ECMA Eiffel; used to be same as ?T I suppose you could call the detachable type ?T an *implicit* Maybe. Needless to say, the switch in semantics of undecorated T helped to fork the Eiffel community... From john at repetae.net Wed Aug 27 22:32:00 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 22:30:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> Message-ID: <20080828023200.GZ15616@sliver.repetae.net> On Thu, Aug 28, 2008 at 12:15:10AM +0100, Lennart Augustsson wrote: > I didn't say NetBSD doesn't use global variables, I said the device > driver model doesn't use global variables. And quite a few things > that used to be in global variables have been moved into allocated > variables and are being passed around instead. That's simply a better > way to structure the code. Indeed. I have experimented with single address space operating systems where it is pretty much the only way to do things at the user level. But I still want to be able to implement my kernel in haskell. :) > > I don't don't think global variables should be banned, I just think > they should be severly discouraged. Oh, I certainly agree with that. especially among new programmers. I think ACIO is a particularly elegant way to provide them in haskell for when they are needed. Every time I can avoid resorting to C code for a task without sacrificing performance, aethetics, or correctness, it is a good day. John -- John Meacham - ?repetae.net?john? From ryani.spam at gmail.com Thu Aug 28 00:17:29 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Aug 28 00:16:01 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Message-ID: <2f9b2d30808272117h826855bh45eb1ff86e897d8f@mail.gmail.com> On Tue, Aug 26, 2008 at 1:35 PM, brian wrote: > One unworkable approach I tried is to get a lazy String from the > handle with hGetContents. > [...] > The OP had the same problem I did, so he made a variant of > hGetContents with timeout support. The problem: he used something from > unsafe*. I came to Haskell for rigor and reliability and it would make > me really sad to have to use a function with 'unsafe' in its name that > has a lot of wacky caveats about inlining, etc. unsafeInterleaveIO has no weird inlining caveats (as opposed to unsafePerformIO, which does). In fact, hGetContents is implemented using unsafeInterleaveIO; the source is here: http://haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO.html#hGetContents The "unsafe" bit is that it potentially allows side effects embedded within pure values; if the value is never demanded, the side effect never executes, so the observable behavior of your program can be made to depend on whether or not (or when) that value is evaluated. But when you are reading from a network stream, that's exactly what you want. -- ryan From nicolas.frisby at gmail.com Thu Aug 28 00:46:02 2008 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Thu Aug 28 00:44:34 2008 Subject: [Haskell-cafe] dangling symbolic links Message-ID: <5ce89fb50808272146s6bbf5731vcfe89291946eedea@mail.gmail.com> I think I've exhausted my options without catching exceptions. If I have an invalid symbolic link, how can I identify that it exists? (Sorry about the line wrap.) tmp$ ls -l # no tricks up my sleeve, empty directory tmp$ touch foo tmp$ ln -s foo bar tmp$ ls -l total 8 lrwxr-xr-x 1 nfrisby nfrisby 3 Aug 27 23:29 bar -> foo -rw-r--r-- 1 nfrisby nfrisby 0 Aug 27 23:29 foo tmp$ ghc -e 'System.Directory.doesFileExist "bar"' True tmp$ rm foo tmp$ ls -l total 8 lrwxr-xr-x 1 nfrisby nfrisby 3 Aug 27 23:29 bar -> foo tmp$ ghc -e 'System.Directory.doesFileExist "bar"' # it follows the broken link False tmp$ ghc -e 'System.Posix.Files.fileExist "bar"' # the POSIX API also follows False tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap` System.Posix.Files.getFileStatus "bar"' # so does this one POSIX API also follows *** Exception: bar: getFileStatus: does not exist (No such file or directory) tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap` System.Posix.Files.getSymbolicLinkStatus "bar"' # the most successful so far True tmp$ rm bar # but it isn't an existence check... tmp$ ls -l tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap` System.Posix.Files.getSymbolicLinkStatus "bar"' *** Exception: bar: getSymbolicLinkStatus: does not exist (No such file or directory) Is there a way to check for the existence of a symbolic link without testing if getSymbolicLinkStatus raises an exception? This is with Darwin Kernel Version 8.11.1, GHC 6.8.2, directory-1.0.0.0, and unix-2.3.0.0. Thanks. From nicolas.frisby at gmail.com Thu Aug 28 00:48:17 2008 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Thu Aug 28 00:46:47 2008 Subject: [Haskell-cafe] Re: dangling symbolic links In-Reply-To: <5ce89fb50808272146s6bbf5731vcfe89291946eedea@mail.gmail.com> References: <5ce89fb50808272146s6bbf5731vcfe89291946eedea@mail.gmail.com> Message-ID: <5ce89fb50808272148x12f5a30au5f4dbb657b4cd645@mail.gmail.com> Ah the magic of using a mailing list... I just realized that using getDirectoryContents lists the entry. Still, a "doesLinkExist" function might be nice... On Wed, Aug 27, 2008 at 11:46 PM, Nicolas Frisby wrote: > I think I've exhausted my options without catching exceptions. > > If I have an invalid symbolic link, how can I identify that it exists? > > (Sorry about the line wrap.) > > tmp$ ls -l # no tricks up my sleeve, empty directory > tmp$ touch foo > tmp$ ln -s foo bar > tmp$ ls -l > total 8 > lrwxr-xr-x 1 nfrisby nfrisby 3 Aug 27 23:29 bar -> foo > -rw-r--r-- 1 nfrisby nfrisby 0 Aug 27 23:29 foo > tmp$ ghc -e 'System.Directory.doesFileExist "bar"' > True > tmp$ rm foo > tmp$ ls -l > total 8 > lrwxr-xr-x 1 nfrisby nfrisby 3 Aug 27 23:29 bar -> foo > tmp$ ghc -e 'System.Directory.doesFileExist "bar"' # it follows > the broken link > False > tmp$ ghc -e 'System.Posix.Files.fileExist "bar"' # the > POSIX API also follows > False > tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap` > System.Posix.Files.getFileStatus "bar"' # so does this one POSIX API > also follows > *** Exception: bar: getFileStatus: does not exist (No such file or directory) > tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap` > System.Posix.Files.getSymbolicLinkStatus "bar"' # the most > successful so far > True > tmp$ rm bar # but it isn't an existence check... > tmp$ ls -l > tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap` > System.Posix.Files.getSymbolicLinkStatus "bar"' > *** Exception: bar: getSymbolicLinkStatus: does not exist (No such > file or directory) > > Is there a way to check for the existence of a symbolic link without > testing if getSymbolicLinkStatus raises an exception? > > This is with Darwin Kernel Version 8.11.1, GHC 6.8.2, > directory-1.0.0.0, and unix-2.3.0.0. > > Thanks. > From allbery at ece.cmu.edu Thu Aug 28 00:55:03 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 28 00:54:07 2008 Subject: [Haskell-cafe] dangling symbolic links In-Reply-To: <5ce89fb50808272146s6bbf5731vcfe89291946eedea@mail.gmail.com> References: <5ce89fb50808272146s6bbf5731vcfe89291946eedea@mail.gmail.com> Message-ID: <1684319C-7331-44EB-A0AC-73432539F826@ece.cmu.edu> On 2008 Aug 28, at 0:46, Nicolas Frisby wrote: > I think I've exhausted my options without catching exceptions. > > If I have an invalid symbolic link, how can I identify that it exists? getSymbolicLinkStatus vs. getFileStatus? The former will return if the link exists, the latter if its target does. (Where not returning means throwing an exception in IO.) -- 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 jason.dusek at gmail.com Thu Aug 28 01:41:07 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Aug 28 01:39:37 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> Message-ID: <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> I would much rather have a pure Trie that is foldable. If we have a Trie, we get a space efficient sorted list, too. -- _jsn From waldmann at imn.htwk-leipzig.de Thu Aug 28 01:45:09 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Aug 28 01:43:41 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <12697_1219869313_m7RKZCTi011219_63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> Message-ID: <48B63B65.7030705@imn.htwk-leipzig.de> > The ECMA Eiffel standard has > ?T either a void reference or a reference to an instance of T > !T a reference to an instance of T > T same as !T in ECMA Eiffel; used to be same as ?T similarly, C# "invented" Maybe and called it Nullable: http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx NB: this is very good "propaganda" also in the sense that as a teacher you can say: if you learn Haskell now, with high probability you are learning things that will appear in following years' versions of C#/Java/whatever. Best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080828/1e11e02b/signature.bin From jules at jellybean.co.uk Thu Aug 28 01:45:22 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Aug 28 01:43:58 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> Message-ID: <48B63B72.7010208@jellybean.co.uk> Jason Dusek wrote: > I would much rather have a pure Trie that is foldable. If we > have a Trie, we get a space efficient sorted list, too. Well, Data.Sequence can be used as a space efficient sorted list which is Foldable - if you make the decision to insert elements into it in a sorted way, obviously. It's a fingertree not a trie, of course. What advantages would a Trie have over Data.Sequence? Jules From bulat.ziganshin at gmail.com Thu Aug 28 02:22:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 28 02:22:11 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> Message-ID: <22163347.20080828102256@gmail.com> Hello Richard, Thursday, August 28, 2008, 5:28:46 AM, you wrote: >>> trie: O(len)*O(width) >>> hashed trie: O(len) >>> hash: O(len) > If "width" here refers to the branching factor of the trie, > it's actually O(len.lg(width)), and the width that matters > is not the *possible* number of choices but the *actual* > number. i thought about using list to hold all variations at the trie node. with a (balanced) tree at each node we will have even more overheads > The great problem with hash tables is devising good hash > functions. There is a vast literature about hash tables, > but there is very little about how to design good hash > functions for anything other than numbers and maybe strings. 1. tries also work only for strings and other lists 2. i don't want to go into discussing well-known pluses and minuses of data structures. my point was just that we have great alternative to trees/tries which should be implemented many years ago. i've used a lots of assoclists in my program, sometimes this really degraded performance (although it's yet another question - why tree/trie structures doesn't provide simple List.lookup replacement function and why i'm so lazy to still not learning their APIs) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ketil at malde.org Thu Aug 28 02:25:10 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Aug 28 02:22:23 2008 Subject: [Haskell-cafe] Is there GHC 6.8.3 on Ubuntu? In-Reply-To: <351ff25e0808271122o3086a896t671deebe97880cf4@mail.gmail.com> (Rafael Gustavo da Cunha Pereira Pinto's message of "Wed\, 27 Aug 2008 15\:22\:05 -0300") References: <351ff25e0808271122o3086a896t671deebe97880cf4@mail.gmail.com> Message-ID: <87ljyhmzax.fsf@malde.org> "Rafael Gustavo da Cunha Pereira Pinto" writes: > Is there anyone packing GHC 6.8.3 for Ubuntu Hardy? The next Ubuntu release (8.10 Intrepid), seems to come with 6.8.2 as well. If you want to pack 6.8.3, go for it! If you just wanted to use it, I've had success using the binary snapshots on previous Ubuntus. -k -- If I haven't seen further, it is by standing in the footprints of giants From dons at galois.com Thu Aug 28 02:32:43 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 28 02:31:10 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <22163347.20080828102256@gmail.com> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <22163347.20080828102256@gmail.com> Message-ID: <20080828063243.GD9712@scytale.galois.com> bulat.ziganshin: > Hello Richard, > > Thursday, August 28, 2008, 5:28:46 AM, you wrote: > > >>> trie: O(len)*O(width) > >>> hashed trie: O(len) > >>> hash: O(len) > > > If "width" here refers to the branching factor of the trie, > > it's actually O(len.lg(width)), and the width that matters > > is not the *possible* number of choices but the *actual* > > number. > > i thought about using list to hold all variations at the trie node. with > a (balanced) tree at each node we will have even more overheads > > > > The great problem with hash tables is devising good hash > > functions. There is a vast literature about hash tables, > > but there is very little about how to design good hash > > functions for anything other than numbers and maybe strings. > > 1. tries also work only for strings and other lists > 2. i don't want to go into discussing well-known pluses and minuses of > data structures. my point was just that we have great alternative to > trees/tries which should be implemented many years ago. i've used a > lots of assoclists in my program, sometimes this really degraded > performance (although it's yet another question - why tree/trie > structures doesn't provide simple List.lookup replacement function and > why i'm so lazy to still not learning their APIs) > Seems like you can make a pure hashtable by unsafePerformIO on the impure one, and exporting only 'lookup'.. -- Don From ketil at malde.org Thu Aug 28 02:40:42 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Aug 28 02:37:45 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> (Aaron Tomb's message of "Wed\, 27 Aug 2008 13\:34\:53 -0700") References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> Message-ID: <87hc95myl1.fsf@malde.org> Aaron Tomb writes: >> Huh? Type safety buys [...] nothing about dereferencing null >> pointers, which are the moral equivalent of Nothing. > What type safety buys you, in my mind, is that Nothing is only a valid > value for explicit Maybe types. In cases where you don't use Maybe, > the "null" situation just can't occur. In languages with null > pointers, any pointer could possibly be null. To write Haskell that is obviously safe, you need to check all cases of algebraic data types - both Just and Nothing. To do something similar in C, you need to check every pointer for NULL. The great thing about Maybe is that once I've checked it isn't Nothing, I can extract the value and dispense with further checks. foo mbx = maybe default (bar x) mbx Usually, you don't want to go on processing a NULL pointer anyway, but in C, 'bar' might be called with NULL, so it'll have to check it again. And 'bar' is less likely than 'foo' to be able to do anything sensible with NULL, and thus 'foo' needs to be able to handle errors returned from 'bar', too. I think an important reason we get NULL pointer SEGVs is that all this checking when you "know" it can't happen gets tedious, and thus ignored and forgotten. -k -- If I haven't seen further, it is by standing in the footprints of giants From dons at galois.com Thu Aug 28 02:41:50 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 28 02:40:16 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <87hc95myl1.fsf@malde.org> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <87hc95myl1.fsf@malde.org> Message-ID: <20080828064150.GE9712@scytale.galois.com> ketil: > Aaron Tomb writes: > > >> Huh? Type safety buys [...] nothing about dereferencing null > >> pointers, which are the moral equivalent of Nothing. > > > What type safety buys you, in my mind, is that Nothing is only a valid > > value for explicit Maybe types. In cases where you don't use Maybe, > > the "null" situation just can't occur. In languages with null > > pointers, any pointer could possibly be null. > > To write Haskell that is obviously safe, you need to check all cases > of algebraic data types - both Just and Nothing. > To do something similar in C, you need to check every pointer for NULL. > > The great thing about Maybe is that once I've checked it isn't > Nothing, I can extract the value and dispense with further checks. > > foo mbx = maybe default (bar x) mbx And GHC will warn me when I forget to check all cases, and prevent me from compiling at all, if I don't do any check. -- Don From bulat.ziganshin at gmail.com Thu Aug 28 02:56:24 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 28 02:55:13 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <20080828063243.GD9712@scytale.galois.com> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <22163347.20080828102256@gmail.com> <20080828063243.GD9712@scytale.galois.com> Message-ID: <1752122903.20080828105624@gmail.com> Hello Don, Thursday, August 28, 2008, 10:32:43 AM, you wrote: > Seems like you can make a pure hashtable by unsafePerformIO on the > impure one, and exporting only 'lookup'.. probably yes, but it will lose a bit of performance due to incremental building of hashtable. actually, writing HT module from scratch is very easy - all we need is a prime searching function (in order to establish array size). everything else: data HT a b = HT (a->Int) (Array Int [(a,b)]) create size hash list = HT hashfunc (accumArray (flip (:)) [] (0, arrsize-1) (map (\(a,b) -> (hashfunc a,b)) list) ) where arrsize = head$ filter (>size)$ iterate (\x->3*x+1) 1 hashfunc a = hash a `mod` arrsize lookup a (HT hash arr) = List.lookup a (arr!hash a) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lennart at augustsson.net Thu Aug 28 04:00:41 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Aug 28 03:59:11 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080828023200.GZ15616@sliver.repetae.net> References: <534781822.20080826190130@gmail.com> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> Message-ID: I'm certain you can write a kernel in Haskell where the only use of global variables is those that hardware interfacing forces you to use. On Thu, Aug 28, 2008 at 3:32 AM, John Meacham wrote: > On Thu, Aug 28, 2008 at 12:15:10AM +0100, Lennart Augustsson wrote: >> I didn't say NetBSD doesn't use global variables, I said the device >> driver model doesn't use global variables. And quite a few things >> that used to be in global variables have been moved into allocated >> variables and are being passed around instead. That's simply a better >> way to structure the code. > > Indeed. I have experimented with single address space operating systems where > it is pretty much the only way to do things at the user level. But I > still want to be able to implement my kernel in haskell. :) > >> >> I don't don't think global variables should be banned, I just think >> they should be severly discouraged. > > Oh, I certainly agree with that. especially among new programmers. I > think ACIO is a particularly elegant way to provide them in haskell for > when they are needed. Every time I can avoid resorting to C code for a > task without sacrificing performance, aethetics, or correctness, it is a > good day. > > John > > > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bulat.ziganshin at gmail.com Thu Aug 28 04:20:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Aug 28 04:19:20 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> Message-ID: <16682395.20080828122004@gmail.com> Hello Lennart, Thursday, August 28, 2008, 12:00:41 PM, you wrote: > I'm certain you can write a kernel in Haskell where the only use of > global variables is those that hardware interfacing forces you to use. moreover, you can write it in Turing machine. the question is just how comfortable it will be :) having an experience of writing medium-size "real-world" app, i have to say that global vars make life much easier - it's a pain to pass all the refs across all the function boundaries. OTOH they are headache - the only parts of program that can't be instantiated many times in concurrent threads are those using global vars so, for me global vars is a must - sometimes you just don't have time budget to make aesthetic design and anyway adding a lot of vars to every function you wrote doesn't look very beautiful. OTOH it's better to limit their usage, but this decision should be made by user, not enforced by language. at practice, ghc already provides the way to make global vars, we say only about making this feature simpler and more standard -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ahey at iee.org Thu Aug 28 04:30:08 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 04:28:44 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219853562.24685.10.camel@jcchost> References: <534781822.20080826190130@gmail.com> <1219767261.5868.0.camel@derek-laptop> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <48B5321F.7030501@iee.org> <1219853562.24685.10.camel@jcchost> Message-ID: <48B66210.2050907@iee.org> Jonathan Cast wrote: > On Wed, 2008-08-27 at 11:53 +0100, Adrian Hey wrote: >> John Meacham wrote: >>> As with all design decisions, it is sometimes the right thing and >>> sometimes the wrong one. And sometimes the most expedient. (which, >>> occasionally, is a perfectly valid driving force behind a certain bit of >>> coding). However, I am fully convinced it is necessary. You don't even >>> have to look further than Haskell 98 to find a use in the Random module, >>> and Data.Unique _depends_ on the state being global for correctness. >> ..and of course there's stdin, stdout. That takes some explaining. > > Not really. If you don't have buffered IO, then you just say > > stdin = 0 > stdout = 1 > stderr = 2 nonStdout = 42? I'm afraid I have no idea what your point is :-( I tried it anyway and doesn't seem to work, but that ain't so surprising as Handles aren't Nums. What needs explaining IMO is that we appear to have "global" Handles exported at the top level from System.IO, but no way for users to write their own modules that do the same for nonStdout, or even to implement getNonStdout. I think that's pretty weird and inconsistent. But perhaps you could show me how to do it with some real Haskell :-) > If you need buffered IO, you just change your IO monad* to look like: > > newtype NewIO alpha = NewIO (ReaderT (Map Fd Buffer) OldIO alpha) > > Of course, if you do this, you can't go mixing IO with unique values > with RNG with mutable state with everything else under the sun anymore. > You might actually have to declare exactly what effects you need when > you give your function's type, now. Clearly, a horror we must avoid at > all costs. Indeed. If anyone thinks that's the way to go maybe Clean would be of some interest. IMHO Cleans treatment of IO and concurrency is just about the worst thing in an otherwise pretty decent language :-( Regards -- Adrian Hey From jason.dusek at gmail.com Thu Aug 28 04:30:49 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Aug 28 04:29:18 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B63B72.7010208@jellybean.co.uk> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> <48B63B72.7010208@jellybean.co.uk> Message-ID: <42784f260808280130j49f1fd5ra4f5e843daf602e3@mail.gmail.com> Jules Bean wrote: > Jason Dusek wrote: > > I would much rather have a pure Trie that is foldable. If we > > have a Trie, we get a space efficient sorted list, too. > > Well, Data.Sequence can be used as a space efficient sorted > list which is Foldable - if you make the decision to insert > elements into it in a sorted way, obviously. > > What advantages would a Trie have over Data.Sequence? A trie is guaranteed sorted -- so using a trie amounts to a "type level" guarantee for binary search and any other algorithm that relies on sortedness. -- _jsn From dougal at dougalstanton.net Thu Aug 28 04:49:18 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Thu Aug 28 04:47:48 2008 Subject: [Haskell-cafe] Is there GHC 6.8.3 on Ubuntu? In-Reply-To: <87ljyhmzax.fsf@malde.org> References: <351ff25e0808271122o3086a896t671deebe97880cf4@mail.gmail.com> <87ljyhmzax.fsf@malde.org> Message-ID: <2d3641330808280149i2bd0bcffs6fb622ba0a6ef7a7@mail.gmail.com> On Thu, Aug 28, 2008 at 7:25 AM, Ketil Malde wrote: > > If you want to pack 6.8.3, go for it! If you just wanted to use it, > I've had success using the binary snapshots on previous Ubuntus. > Agreed. The default Linux binary works fine for me in Hardy Heron, just installed in my ~/bin. D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From ahey at iee.org Thu Aug 28 05:00:50 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 04:59:24 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> Message-ID: <48B66942.3050703@iee.org> Lennart Augustsson wrote: > I don't don't think global variables should be banned, I just think > they should be severly discouraged. If you're saying a language should not provide a sound way to do this (as I believe you are), then AFAICT for all practical purposes you *are* saying you think global variables should be banned. Where are we going to be if the unsafePerformIO hack ever becomes *really* unsafe? and.. > I'm certain you can write a kernel in Haskell where the only use of > global variables is those that hardware interfacing forces you to use. But what you haven't explained is why this is even desirable? I don't doubt it's true in an academic sense if you don't mind sacrificing safety and modularity. Why wasn't this done in the (presumably) much simpler case of the Haskell base libs? No hardware constraints there. There are plenty situations where it makes no semantic sense to allow 2 or more or some "thing". A list of all active processes for example. Why would I ever want 2 or more lists of all active processes? I think I'd just be setting myself up for trouble and heartache by even allowing such a possibility. Now I could get the safety I need by wrapping all this stuff up in my own custom augmented IO monad right at the start of main. But this solution still lacks modularity. The top level <- bindings are just a modular and extensible way to achieve the same thing AFAICS (augmenting "real world" state with my own custom state). Regards -- Adrian Hey From jules at jellybean.co.uk Thu Aug 28 05:07:44 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Aug 28 05:06:15 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <42784f260808280130j49f1fd5ra4f5e843daf602e3@mail.gmail.com> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> <48B63B72.7010208@jellybean.co.uk> <42784f260808280130j49f1fd5ra4f5e843daf602e3@mail.gmail.com> Message-ID: <48B66AE0.30009@jellybean.co.uk> Jason Dusek wrote: > Jules Bean wrote: >> Jason Dusek wrote: >>> I would much rather have a pure Trie that is foldable. If we >>> have a Trie, we get a space efficient sorted list, too. >> Well, Data.Sequence can be used as a space efficient sorted >> list which is Foldable - if you make the decision to insert >> elements into it in a sorted way, obviously. >> >> What advantages would a Trie have over Data.Sequence? > > A trie is guaranteed sorted -- so using a trie amounts to a > "type level" guarantee for binary search and any other > algorithm that relies on sortedness. ...No more so than a simple wrapper over a Data.Sequence which puts the elements in the right place. Insert for Data.Sequence is log(i) where i is the position of the insertion; clearly bounded by log(n). toList is O(n) and index is (at worst) log(i). I think the corresponding operations with tries are log(n), so asymptotically tries are identical for 'uniformly distributed' keys although fingertrees are faster if there is a bias towards elements near the ends of the lists. So, it's all in the constants, isn't it? Jules From tphyahoo at gmail.com Thu Aug 28 05:27:37 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Thu Aug 28 05:26:06 2008 Subject: [Haskell-cafe] building documentation Message-ID: <910ddf450808280227y12d6ce25k1c330e1e4dbc4804@mail.gmail.com> I'm on ubuntu, ghc 6.8.3. I built this using the Generic i386 Linux build at http://www.haskell.org/ghc/download_ghc_683.html How do I build local documentation that matches what I see at http://www.haskell.org/ghc/docs/latest/html/libraries/ -- and am I correct that this is 6.8.3 right now? When I go to file:///usr/share/doc/ghc6-doc/libraries/index.html to browse local docu, I am missing for example Control.Monad.Error. From waldmann at imn.htwk-leipzig.de Thu Aug 28 05:30:34 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Aug 28 05:31:09 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B66942.3050703@iee.org> References: <534781822.20080826190130@gmail.com> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> Message-ID: <48B6703A.5040507@imn.htwk-leipzig.de> Adrian Hey wrote: > There are plenty situations where it makes no semantic sense to allow > 2 or more or some "thing". A list of all active processes for example. "all" referring to what scope? perhaps there occurs a situation with several process (thread) pools, severals cores etc. See also "singleton considered harmful", there are similar arguments: http://www.oreillynet.com/cs/user/view/cs_msg/23417 and also Section 13.3 "Global Data" in McConnell: Code Complete (2nd ed.) has a nice discussion. J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080828/45f895da/signature.bin From ahey at iee.org Thu Aug 28 06:03:38 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 06:02:12 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B6703A.5040507@imn.htwk-leipzig.de> References: <534781822.20080826190130@gmail.com> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <48B6703A.5040507@imn.htwk-leipzig.de> Message-ID: <48B677FA.5070802@iee.org> Johannes Waldmann wrote: > Adrian Hey wrote: > >> There are plenty situations where it makes no semantic sense to allow >> 2 or more or some "thing". A list of all active processes for example. > > "all" referring to what scope? perhaps there occurs a situation > with several process (thread) pools, severals cores etc. Seeing as we're talking about an OS kernel I guess the scope would be all processes active on the (possibly virtual) machine being managed by the OS. But it really doesn't matter what the scope is. "All" is the key word here. > See also "singleton considered harmful", there are similar arguments: > http://www.oreillynet.com/cs/user/view/cs_msg/23417 Following the arguments made against the singleton pattern over the years leads me to conclude there are 2 distinct camps. Applications programmers who consider it bad because it's way of making "global variables" and we all know how bad they are, right? Typically these folk appear to have no clue about how the underlying IO library, "framework" and OS infrastructure they are dependent on *actually works*. System programmers who recognise the need for singletons but regard being forced to use the singleton pattern hack as language design defect. The situation seems similar with us. The unsafePerformIO hack is just terrible (especially for a language like Haskell), but why is it being used so often? Is it incompetance of library writers or a language design defect? Regards -- Adrian Hey From patperry at stanford.edu Thu Aug 28 07:24:21 2008 From: patperry at stanford.edu (Patrick Perry) Date: Thu Aug 28 07:22:53 2008 Subject: [Haskell-cafe] ANN: gsl-random 0.1 and monte-carlo-0.1 Message-ID: <25AF4720-77B9-431C-A72A-BDA4F6217F28@stanford.edu> Hi everyone, I've started on bindings for the random number generators and random distributions provided by the gsl. The package is available here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gsl-random I've also written a monad and transformer for doing monte carlo computations that uses gsl-random internally. Here is that package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monte-carlo For a quick tutorial in the latter package, see my blog: http://quantile95.com/2008/08/27/a-monte-carlo-monad-for-haskell/ There is also a more complicated example in the "examples" directory. Currently, only normal, uniform, and poisson random variables are supported. I have no plans to add anything else unless I need it, but I will happily accept patches if someone else is willing to do the work. One thing you may need to watch out for is that gsl-random needs to link with cblas. If your cblas is not called "cblas", you may have to edit "gsl-random.cabal" to get things to work correctly. To use the cblas that comes with the gsl, change "cblas" to "gslcblas". To use ATLAS, change "cblas" to "cblas atlas". Patrick From briqueabraque at yahoo.com Thu Aug 28 08:15:45 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Thu Aug 28 08:14:23 2008 Subject: [Haskell-cafe] Re: Haskell symbol ~ In-Reply-To: <404396ef0808271156t36e5cb5er72e7ebb58edde954@mail.gmail.com> References: <404396ef0808271156t36e5cb5er72e7ebb58edde954@mail.gmail.com> Message-ID: >> At the same place, I found that example, >> but wasn't wise enough to figure out >> what it does: >> >> (f *** g) ~(x,y) = (f x, g y) >> >> (...) > (...) > Please update the keyword wiki so it makes sense to you, after you > have got your head round it. After the explanations, I think I got it, and just updated the wiki. If you guys have some time please check it for style and errors. I also got a few wrong default links (I just created +++ inside and it links to something that doesn't exist). Here it is: http://haskell.org/haskellwiki/Keywords#.7E Thanks, Maur?cio From ndmitchell at gmail.com Thu Aug 28 08:22:54 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Aug 28 08:21:23 2008 Subject: [Haskell-cafe] Re: Haskell symbol ~ In-Reply-To: References: <404396ef0808271156t36e5cb5er72e7ebb58edde954@mail.gmail.com> Message-ID: <404396ef0808280522r2bcec9bejfd5efc9f4f6f76ad@mail.gmail.com> Hi > After the explanations, I think I got it, and just > updated the wiki. Many thanks. That wiki page is automatically pulled into the Hoogle search engine when I update it, so having good definitions for every new keyword is a real bonus :-) > I also got a > few wrong default links (I just created +++ inside > and it links to something that > doesn't exist). I wouldn't worry about that, I think its a bug in the wiki software. Does anyone know who our wiki software guru is? Perhaps wiki links should point at Hoogle, rather than using its own (obviously imperfect) database? Thanks Neil From bit at mutantlemon.com Thu Aug 28 08:38:51 2008 From: bit at mutantlemon.com (Bit Connor) Date: Thu Aug 28 08:37:21 2008 Subject: [Haskell-cafe] Building SDL-image package on Windows In-Reply-To: References: <6205bd290808270140g73615341y5ac542139e560c09@mail.gmail.com> Message-ID: <6205bd290808280538q52ef86a7ve569be71c1f2c1e4@mail.gmail.com> I think the best thing to do is to darcs send a patch with the necessary changes On Thu, Aug 28, 2008 at 1:05 AM, Garrick Chin wrote: > Hello, > > Adding the main macro undef has solved the linker errors and both SDL_image > and SDL_ttf build and install correctly now. For both SDL_image and SDL_ttf > only the ./Graphics/UI/SDL/Image/Version.hsc file needed to be changed, > pasting in the undef macro under "#include SDL_image.h" and "#include > SDL_ttf.h" respectively. Thanks for your help! > > It would probably be a good idea to include these notes in a WIN32 file like > for the SDL package for other users. I sent an e-mail to the listed > maintainer on Hackage yesterday, is that the best way to about doing this? > > On Wed, Aug 27, 2008 at 4:40 AM, Bit Connor wrote: >> >> Hi, I wrote the instructions in the WIN32 file. >> >> This looks like the same problem that I originally had with the SDL >> package, mangling of "main" function in C land by the hand of the C >> SDL.h include file. >> >> If you look at the .hsc files from the SDL package, you will see the >> fix I applied at the top of each file, after #including SDL.h the evil >> "main" macro is undefined: >> >> #include "SDL.h" >> #ifdef main >> #undef main >> #endif >> >> Probably the same must be done for all the .hsc files in SDL-image(and >> probably also all other haskell SDL addon packages). >> >> Please let me know if this information is helpful. >> >> 2008/8/27 Garrick Chin : >> > Hello, >> > >> > I'm trying to build the latest SDL-image package (0.5.2) from Hackage on >> > Windows and encountering problems. These are the steps I've taken so >> > far: >> > >> > 1. Downloaded SDL 1.2.13 developmental library for Mingw32 to >> > E:\SDL-1.2.13, and SDL_image 1.2.6 developmental library for VC8 to >> > E:\SDL_image-1.2.6. >> > 2. Installed SDL package from Hackage, modifying the SDL.cabal >> > according to >> > the included WIN32 readme file and then runghc Setup.lhs >> > configure/build/install >> > 3. Downloaded the SDL-image package from Hackage, modified the >> > SDL-image.cabal file to add the line "Include-Dirs: >> > E:\SDL_image-1.2.6\include\SDL, E:\SDL-1.2.13\include\SDL" so Cabal can >> > find >> > the header files. After doing "runghc Setup.lhs configure", "runghc >> > Setup.lhs build -v" gives me the following output: >> > >> > Creating dist\build (and its parents) >> > Creating dist\build\autogen (and its parents) >> > Preprocessing library SDL-image-0.5.2... >> > Creating dist\build\Graphics\UI\SDL\Image (and its parents) >> > E:\ghc\ghc-6.8.2\bin\hsc2hs.exe --cc=E:\ghc\ghc-6.8.2\bin\ghc.exe >> > --ld=E:\ghc\ghc-6.8.2\bin\ghc.exe --cflag=-package --cflag=SDL-0.5.4 >> > --cflag=-package --cflag=base-3.0.1.0 >> > --cflag=-IE:\SDL_image-1.2.6\include\SDL >> > --cflag=-IE:\SDL-1.2.13\include\SDL >> > -o dist\build\Graphics\UI\SDL\Image\Version.hs >> > Graphics\UI\SDL\Image\Version.hsc >> > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined >> > reference >> > to `__stginit_ZCMain' >> > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined >> > reference >> > to `ZCMain_main_closure' >> > collect2: ld returned 1 exit status >> > linking dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o failed >> > command was: E:\ghc\ghc-6.8.2\bin\ghc.exe >> > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o -o >> > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.exe >> > >> > The results of a limited google search suggests that the >> > __stginit_ZCMain >> > linker error has to do with GHC expecting a main function, but I'm not >> > really sure how that works in context of a library. >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > > > From jmaessen at alum.mit.edu Thu Aug 28 09:44:11 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Thu Aug 28 09:42:42 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <1157805913.20080828003108@gmail.com> References: <1365585749.20080827114130@gmail.com> <1157805913.20080828003108@gmail.com> Message-ID: <53DD2573-9683-4F45-A3FC-BF5075C8B4CF@alum.mit.edu> On Aug 27, 2008, at 4:31 PM, Bulat Ziganshin wrote: > Hello Jan-Willem, > > Wednesday, August 27, 2008, 4:06:11 PM, you wrote: > >> One obvious way to make non-modifiable hash tables useful is to "eat >> your own tail" non-strictly--- aggregate a set of hash table entries, >> construct a hash table from them, and plumb the resulting hash table >> into the original computation by tying the knot. This works really >> well if you can construct the bucket lists lazily and if you specify >> the table size up front. > > i think it's impossible since you need to scan whole assoclist to > build list of entries for any value of hash function. I think this is because I wasn't quite clear enough about the problem I was solving. I think you'll agree that we can use an assocList non- strictly in the following sense: * We can do lookups that succeed so long as we can compute all keys up to and including the key that matches. * We never do non-strict lookups that fail, as that would require examining the entire assocList. Now I can build a hashtable with the same property from an assocList, albeit very inefficiently, using code like this (untested): lazyArray :: (Ix i) => (i,i) -> [(i,v)] -> Array i [v] lazyArray bnds kvs = array bnds [ (k, map snd . filter ((k==) . fst) $ kvs) | k <- range bnds ] makeHash :: (Eq k, Hashable k) => [(k,v)] -> Array Int [(k,v)] makeHash assocList = lazyArray (0,n-1) labeledAssocList where labeledAssocList = [ (hashToSize n k, (k,v)) | (k,v) <- assocList ] We label each assocList element with its corresponding hash bucket (labeledAssocList); each bucket then contains exactly the elements of assocList that map to that bucket, in exactly the order in which they occurred in assocList. The LazyArray library in hbc essentially did exactly what the lazyArray function I've shown above does, only the input list is traversed once rather than having a separate traversal for each bucket. This can actually be implemented using the ST monad augmented by unsafeFreezeSTArray and unsafeInterleaveST; indeed the "State in Haskell" paper by Peyton Jones and Launchbury gives the implementation of a very similar function. I have code for LazyArray based on the above paper that works with GHC, but I haven't needed it in a while. -Jan From dmhouse at gmail.com Thu Aug 28 09:49:54 2008 From: dmhouse at gmail.com (David House) Date: Thu Aug 28 09:48:24 2008 Subject: [Haskell-cafe] Re: Haskell symbol ~ In-Reply-To: References: <404396ef0808271156t36e5cb5er72e7ebb58edde954@mail.gmail.com> Message-ID: 2008/8/28 Maur??cio : > After the explanations, I think I got it, and just > updated the wiki. Glad you've understood it. Seems I arrived a little late at this thread, but there is also: http://en.wikibooks.org/wiki/Haskell/Laziness#Lazy_pattern_matching In addition, the first three chapters of that page might be worth reading if you're a little unclear about laziness etc. in general. -- -David From allbery at ece.cmu.edu Thu Aug 28 09:49:49 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 28 09:48:35 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <20080828064150.GE9712@scytale.galois.com> References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <87hc95myl1.fsf@malde.org> <20080828064150.GE9712@scytale.galois.com> Message-ID: On 2008 Aug 28, at 2:41, Don Stewart wrote: > ketil: >> The great thing about Maybe is that once I've checked it isn't >> Nothing, I can extract the value and dispense with further checks. >> >> foo mbx = maybe default (bar x) mbx > > And GHC will warn me when I forget to check all cases, and prevent me > from compiling at all, if I don't do any check. ...unless you use fromJust. GNU ld supports "pragmas" which cause the use of certain functions to output warnings at link time (try compiling a C program that uses gets()). It occurs to me that this, either in compiler or linker, would be a nice thing for ghc to do when using fromJust or other partial functions. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jonathanccast at fastmail.fm Thu Aug 28 12:07:21 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Aug 28 12:09:36 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B66942.3050703@iee.org> References: <534781822.20080826190130@gmail.com> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> Message-ID: <1219939641.908.8.camel@jcchost> On Thu, 2008-08-28 at 10:00 +0100, Adrian Hey wrote: > Lennart Augustsson wrote: > > I don't don't think global variables should be banned, I just think > > they should be severly discouraged. > > If you're saying a language should not provide a sound way to do > this (as I believe you are), then AFAICT for all practical purposes > you *are* saying you think global variables should be banned. > > Where are we going to be if the unsafePerformIO hack ever becomes > *really* unsafe? > > and.. > > > I'm certain you can write a kernel in Haskell where the only use of > > global variables is those that hardware interfacing forces you to use. > > But what you haven't explained is why this is even desirable? I don't > doubt it's true in an academic sense if you don't mind sacrificing > safety What `safety' is being sacrificed? > and modularity. What modularity? jcc From ahey at iee.org Thu Aug 28 12:26:27 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 12:25:12 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219939641.908.8.camel@jcchost> References: <534781822.20080826190130@gmail.com> <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> Message-ID: <48B6D1B3.4030007@iee.org> Jonathan Cast wrote: > On Thu, 2008-08-28 at 10:00 +0100, Adrian Hey wrote: >> Lennart Augustsson wrote: >> > I don't don't think global variables should be banned, I just think >> > they should be severly discouraged. >> >> If you're saying a language should not provide a sound way to do >> this (as I believe you are), then AFAICT for all practical purposes >> you *are* saying you think global variables should be banned. >> >> Where are we going to be if the unsafePerformIO hack ever becomes >> *really* unsafe? >> >> and.. >> >>> I'm certain you can write a kernel in Haskell where the only use of >>> global variables is those that hardware interfacing forces you to use. >> But what you haven't explained is why this is even desirable? I don't >> doubt it's true in an academic sense if you don't mind sacrificing >> safety > > What `safety' is being sacrificed? > >> and modularity. > > What modularity? As I've pointed out several times already you can find simple examples in the standard haskell libs. So far nobody has accepted my challenge to re-implement any of these "competantly" (I.E. avoiding the use of global variables). Why don't you try it with Data.Unique and find out :-) Regards -- Adrian Hey From dons at galois.com Thu Aug 28 12:56:21 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 28 12:54:47 2008 Subject: [Haskell-cafe] ANN: gsl-random 0.1 and monte-carlo-0.1 In-Reply-To: <25AF4720-77B9-431C-A72A-BDA4F6217F28@stanford.edu> References: <25AF4720-77B9-431C-A72A-BDA4F6217F28@stanford.edu> Message-ID: <20080828165621.GA11349@scytale.galois.com> patperry: > Hi everyone, > > I've started on bindings for the random number generators and random > distributions provided by the gsl. The package is available here: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gsl-random > > I've also written a monad and transformer for doing monte carlo > computations that uses gsl-random internally. Here is that package: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monte-carlo > > For a quick tutorial in the latter package, see my blog: > http://quantile95.com/2008/08/27/a-monte-carlo-monad-for-haskell/ > > There is also a more complicated example in the "examples" directory. > Currently, only normal, uniform, and poisson random variables are > supported. I have no plans to add anything else unless I need it, but > I will happily accept patches if someone else is willing to do the work. > > One thing you may need to watch out for is that gsl-random needs to > link with cblas. If your cblas is not called "cblas", you may have to > edit "gsl-random.cabal" to get things to work correctly. To use the > cblas that comes with the gsl, change "cblas" to "gslcblas". To use > ATLAS, change "cblas" to "cblas atlas". Arch packages available here, http://aur.archlinux.org/packages.php?ID=19416 http://aur.archlinux.org/packages.php?ID=19417 Note I had to patch gsl-random's .cabal file to not explicitly look for extra libs in /opt/local/lib. The exact path (if any) should be cabal (or ./configure's) job, I think. -- Don From dan.doel at gmail.com Thu Aug 28 13:17:29 2008 From: dan.doel at gmail.com (Dan Doel) Date: Thu Aug 28 13:12:04 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B6D1B3.4030007@iee.org> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> Message-ID: <200808281317.30358.dan.doel@gmail.com> On Thursday 28 August 2008 12:26:27 pm Adrian Hey wrote: > As I've pointed out several times already you can find simple examples > in the standard haskell libs. So far nobody has accepted my challenge to > re-implement any of these "competantly" (I.E. avoiding the use of global > variables). > > Why don't you try it with Data.Unique and find out :-) Here's a first pass: -- snip -- {-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-} module Unique where import Control.Monad.Reader import Control.Monad.Trans import Control.Concurrent.MVar -- Give Uniques a phantom region parameter, so that you can't accidentally -- compare Uniques from two different uniqueness sources. newtype Unique r = Unique Integer deriving Eq newtype U r a = U { unU :: ReaderT (MVar Integer) IO a } deriving (Functor, Monad, MonadIO) -- Higher rank type for region consistency runU :: (forall r. U r a) -> IO a runU m = newMVar 0 >>= runReaderT (unU m) newUnique :: U r (Unique r) newUnique = U (do source <- ask val <- lift $ takeMVar source let next = val + 1 lift $ putMVar source next return $ Unique next) -- hashUnique omitted -- snip -- It's possible that multiple unique sources can exist in a program with this implementation, but because of the region parameter, the fact that a Unique may not be "globally" unique shouldn't be a problem. If your whole program needs arbitrary access to unique values, then I suppose something like: main = runU realMain realMain :: U r () realMain = ... is in order. Insert standard complaints about this implementation requiring liftIO all over the place if you actually want to do other I/O stuff inside the U monad. You could also make a version that extracts to STM, or even a pure version if you don't need unique values across multiple threads. -- Dan From jason.dusek at gmail.com Thu Aug 28 13:18:04 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Aug 28 13:16:33 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B66AE0.30009@jellybean.co.uk> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> <48B63B72.7010208@jellybean.co.uk> <42784f260808280130j49f1fd5ra4f5e843daf602e3@mail.gmail.com> <48B66AE0.30009@jellybean.co.uk> Message-ID: <42784f260808281018p803e42fv8a882fd495927fe9@mail.gmail.com> Jules Bean wrote: > Jason Dusek wrote: > > Jules Bean wrote: > > > Jason Dusek wrote: > > > > I would much rather have a pure Trie that is foldable. > > > > If we have a Trie, we get a space efficient sorted list, > > > > too. > > > > > > Well, Data.Sequence can be used as a space efficient > > > sorted list which is Foldable - if you make the decision > > > to insert elements into it in a sorted way, obviously. > > > > > > What advantages would a Trie have over Data.Sequence? > > > > A trie is guaranteed sorted -- so using a trie amounts to a > > "type level" guarantee for binary search and any other > > algorithm that relies on sortedness. > > ...No more so than a simple wrapper over a Data.Sequence which > puts the elements in the right place. If by a wrapper you mean a function, well that's not type level at all. A binary search that insists on tries will, with a correct trie implementation, behave correctly on every input; a binary search that works with `Data.Sequence` will fail on a substantial portion of the inputs accepted by the type system, regardless of the data structure's correctness. -- _jsn From newsham at lava.net Thu Aug 28 13:21:33 2008 From: newsham at lava.net (Tim Newsham) Date: Thu Aug 28 13:20:01 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <87hc95myl1.fsf@malde.org> <20080828064150.GE9712@scytale.galois.com> Message-ID: > GNU ld supports "pragmas" which cause the use of certain functions to output > warnings at link time (try compiling a C program that uses gets()). It > occurs to me that this, either in compiler or linker, would be a nice thing > for ghc to do when using fromJust or other partial functions. would you include all partial functions in this, such as head? > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com Tim Newsham http://www.thenewsh.com/~newsham/ From lennart at augustsson.net Thu Aug 28 13:31:19 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Aug 28 13:29:47 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B6D1B3.4030007@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> Message-ID: I don't think anyone has claimed that any interface can be implemented without globals. Of course some can't (just pick an interface that is the specification of a global variable). What I (and others) claims is that such interfaces are bad. Using a global variable makes an assumption that there's only ever going to be one of something, and that's just an inflexible assumption to make. You think global variables are essential, I think they are a sign of bad design. So we have different opinions and neither one of us is going to convince the other. I think a lot of things related to the IO monad in Haskell is bad design; influenced by imperative thinking. For instance, I think the main function should have a type like main :: (IOMonad io) => io a where IOMonad contains some basic functionality like calling C. Then you could do things like implement runInsandboxIO which traces all C calls. -- Lennart On Thu, Aug 28, 2008 at 5:26 PM, Adrian Hey wrote: > Jonathan Cast wrote: >> >> On Thu, 2008-08-28 at 10:00 +0100, Adrian Hey wrote: >>> >>> Lennart Augustsson wrote: >>> > I don't don't think global variables should be banned, I just think >>> > they should be severly discouraged. >>> >>> If you're saying a language should not provide a sound way to do >>> this (as I believe you are), then AFAICT for all practical purposes >>> you *are* saying you think global variables should be banned. >>> >>> Where are we going to be if the unsafePerformIO hack ever becomes >>> *really* unsafe? >>> >>> and.. >>> >>>> I'm certain you can write a kernel in Haskell where the only use of >>>> global variables is those that hardware interfacing forces you to use. >>> >>> But what you haven't explained is why this is even desirable? I don't >>> doubt it's true in an academic sense if you don't mind sacrificing >>> safety >> >> What `safety' is being sacrificed? >> >>> and modularity. >> >> What modularity? > > As I've pointed out several times already you can find simple examples > in the standard haskell libs. So far nobody has accepted my challenge to > re-implement any of these "competantly" (I.E. avoiding the use of global > variables). > > Why don't you try it with Data.Unique and find out :-) > > Regards > -- > Adrian Hey > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From droundy at darcs.net Thu Aug 28 14:28:35 2008 From: droundy at darcs.net (David Roundy) Date: Thu Aug 28 14:27:02 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <200808281317.30358.dan.doel@gmail.com> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> Message-ID: <20080828182834.GS12859@darcs.net> On Thu, Aug 28, 2008 at 01:17:29PM -0400, Dan Doel wrote: > On Thursday 28 August 2008 12:26:27 pm Adrian Hey wrote: > > As I've pointed out several times already you can find simple examples > > in the standard haskell libs. So far nobody has accepted my challenge to > > re-implement any of these "competantly" (I.E. avoiding the use of global > > variables). > > > > Why don't you try it with Data.Unique and find out :-) > > Here's a first pass: > > -- snip -- > > {-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-} > > module Unique where If you want this to actually provide any guarantees, of course, you'll have to provide an export list. David From ahey at iee.org Thu Aug 28 15:28:22 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 15:26:56 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> Message-ID: <48B6FC56.4050301@iee.org> Lennart Augustsson wrote: > I don't think anyone has claimed that any interface can be implemented > without globals. > Of course some can't (just pick an interface that is the specification > of a global variable). I said in the original challenge even I'd let you (anyone) change the interface if you could provide a sensible explanation of why the new interface was better, safer, more convenient or whatever. > What I (and others) claims is that such interfaces are bad. Using a > global variable makes an assumption that there's only ever going to be > one of something, It's not an assumption, any more than I always want 1*N to yield N is an assumption. It's a fundamental property I absolutely want to guarantee. By far the simplest way to do this is simply not to expose a newWhatever constructor in my API. If I expose anything it should be Whatever itself or getWatever, neither of which is possible if Whatever contains MVars, Chans and the like. What's more, there seems to be no good *semantic* reason why this should not be possible. The only objections seem dogmatic to me. > and that's just an inflexible assumption to make. > > You think global variables are essential, I think they are a sign of > bad design. So we have different opinions and neither one of us is > going to convince the other. You might stand some chance of convincing me by showing a better design :-) Dan seems to have had a reasonable go at 1 of them. I'm not sure passes the improved interface test but I'll think about it. But there are quite a few left. There's the Hughes paper too of course, using implicit parameters (a highly dubious language feature IMO). But even if someone does produce an entirely unsafePerformIO hack free set of standard libs, I have to ask why jump through all these hoops? There's no semantic difficulty with the proposed language extension, and it should be very simple to implement (John seems to have done it already). Regards -- Adrian Hey From ganesh at earth.li Thu Aug 28 15:34:47 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Thu Aug 28 15:33:17 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B6FC56.4050301@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> Message-ID: On Thu, 28 Aug 2008, Adrian Hey wrote: > implicit parameters (a highly dubious language feature IMO). How can you say that with a straight face at the same time as advocating global variables? :-) Ganesh From ben.franksen at online.de Thu Aug 28 15:34:41 2008 From: ben.franksen at online.de (Ben Franksen) Date: Thu Aug 28 15:33:30 2008 Subject: [Haskell-cafe] Re: two problems with Data.Binary and Data.ByteString References: <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> <1218737836.13639.52.camel@localhost> <20080825212828.GA742@scytale.galois.com> <20080826220422.GI3200@scytale.galois.com> <1219794277.24846.81.camel@localhost> Message-ID: Duncan Coutts wrote: > On Tue, 2008-08-26 at 15:31 -0700, Bryan O'Sullivan wrote: >> On Tue, Aug 26, 2008 at 3:04 PM, Don Stewart wrote: >> > No, since I can get whnf with `seq`. However, that does sound like a >> > good idea (a patch to the parallel library? ) >> >> I suspect that patching parallel doesn't scale. It doesn't have a >> maintainer, so it will be slow, and the package will end up dragging >> in everything under the sun if we centralise instances in there. I >> think that the instance belongs in bytestring instead. I know that >> this would make everything depend on parallel, but that doesn't seem >> as bad a problem. > > This is a general problem we have with packages and instances. Perhaps > in this specific case it wouldn't cause many problems to make bytestring > depend on parallel (though it means bytestring cannot be a boot lib and > cannot be used to implement basic IO) but in general it can be a > problem. I can't see any obvious solutions. We don't want lots of tiny > packages that just depend on two other packages and define a instance. Just some raw ideas: What if we had a way to express 'optional dependencies' between packages in a cabal file. Something like 'if package x is installed (and satisfies given version constraints) then add module UseX'. One problem with this idea is that I might install the missing (optional) package afterwards, and then I still do not have the instance I would like (unless I re-build). Could cabal be instructed to re-build a package if an optional dependency becomes available (or if one gets removed)? Cheers Ben From jonathanccast at fastmail.fm Thu Aug 28 15:41:14 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Aug 28 15:43:27 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B6FC56.4050301@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> Message-ID: <1219952474.908.26.camel@jcchost> On Thu, 2008-08-28 at 20:28 +0100, Adrian Hey wrote: > Lennart Augustsson wrote: > > I don't think anyone has claimed that any interface can be implemented > > without globals. > > Of course some can't (just pick an interface that is the specification > > of a global variable). > > I said in the original challenge even I'd let you (anyone) change the > interface if you could provide a sensible explanation of why the > new interface was better, safer, more convenient or whatever. > > > What I (and others) claims is that such interfaces are bad. Using a > > global variable makes an assumption that there's only ever going to be > > one of something, > > It's not an assumption, any more than I always want 1*N to yield N is > an assumption. > > It's a fundamental property I absolutely want to guarantee. By far the > simplest way to do this is simply not to expose a newWhatever > constructor in my API. If I expose anything it should be Whatever itself > or getWatever, neither of which is possible if Whatever contains MVars, > Chans and the like. This has been answered repeatedly, at least implicitly. Unless you insist that getWhatever should live in the IO monad and have no functional arguments (why?), there is no reason why this should be impossible. > What's more, there seems to be no good *semantic* reason why this should > not be possible. The only objections seem dogmatic to me. I haven't seen you give a non-dogmatic reason for wanting global variables yet, either. > > and that's just an inflexible assumption to make. > > > > You think global variables are essential, I think they are a sign of > > bad design. So we have different opinions and neither one of us is > > going to convince the other. > > You might stand some chance of convincing me by showing a better > design :-) > > Dan seems to have had a reasonable go at 1 of them. I'm not sure > passes the improved interface test but I'll think about it. But > there are quite a few left. There are even more implemented in languages such as ML, Lisp, Perl, etc. I think habit and the fact that globals sort of work in Haskell are the major drivers of their use in the existing standard library. See my position as an attempt to drive back those battalions of darkness :) > There's the Hughes paper too of course, using implicit parameters > (a highly dubious language feature IMO). > > But even if someone does produce an entirely unsafePerformIO hack > free set of standard libs, I have to ask why jump through all these > hoops? To improve the APIs available? You're advocating an extension to a *purely functional programming language*. That's an awfully weird hoop you've already jumped through, there. Some of us think it logically extends to condemning global variables; I haven't seen you give a reason for disagreeing. > There's no semantic difficulty with the proposed language > extension, Although I've noticed it's grossly under-powered compared to what's needed to implement stdin the way you want to. jcc From jules at jellybean.co.uk Thu Aug 28 15:55:36 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Aug 28 15:54:05 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <42784f260808281018p803e42fv8a882fd495927fe9@mail.gmail.com> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> <48B63B72.7010208@jellybean.co.uk> <42784f260808280130j49f1fd5ra4f5e843daf602e3@mail.gmail.com> <48B66AE0.30009@jellybean.co.uk> <42784f260808281018p803e42fv8a882fd495927fe9@mail.gmail.com> Message-ID: <48B702B8.2020704@jellybean.co.uk> Jason Dusek wrote: > Jules Bean wrote: >> Jason Dusek wrote: >>> Jules Bean wrote: >>>> Jason Dusek wrote: >>>>> I would much rather have a pure Trie that is foldable. >>>>> If we have a Trie, we get a space efficient sorted list, >>>>> too. >>>> Well, Data.Sequence can be used as a space efficient >>>> sorted list which is Foldable - if you make the decision >>>> to insert elements into it in a sorted way, obviously. >>>> >>>> What advantages would a Trie have over Data.Sequence? >>> A trie is guaranteed sorted -- so using a trie amounts to a >>> "type level" guarantee for binary search and any other >>> algorithm that relies on sortedness. >> ...No more so than a simple wrapper over a Data.Sequence which >> puts the elements in the right place. > > If by a wrapper you mean a function, well that's not type > level at all. A binary search that insists on tries will, with > a correct trie implementation, behave correctly on every > input; a binary search that works with `Data.Sequence` will > fail on a substantial portion of the inputs accepted by the > type system, regardless of the data structure's correctness. No. I meant a newtype with a non-exported constructor and exporting only methods which preserve sortedness. Jules From ganesh at earth.li Thu Aug 28 16:05:03 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Thu Aug 28 16:03:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B6FC56.4050301@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> Message-ID: On Thu, 28 Aug 2008, Adrian Hey wrote: > There's no semantic difficulty with the proposed language extension, How does it behave in the presence of dynamic loading? What about remote procedure calls? Also what if I want a thread-local variable? It seems like an extension like this should also support that, and perhaps other scopes as Duncan suggested; why is the process scope special? Ganesh From patperry at stanford.edu Thu Aug 28 16:10:17 2008 From: patperry at stanford.edu (Patrick Perry) Date: Thu Aug 28 16:08:50 2008 Subject: [Haskell-cafe] ANN: gsl-random 0.1 and monte-carlo-0.1 In-Reply-To: <20080828165621.GA11349@scytale.galois.com> References: <25AF4720-77B9-431C-A72A-BDA4F6217F28@stanford.edu> <20080828165621.GA11349@scytale.galois.com> Message-ID: Thanks for the heads up, Don. I fixed the file in version 0.1.1. I also changed the default CBLAS to the one that comes with the GSL. Anyone who cares at all about performance will want to configure the package to use the best CBLAS on their system. If this is ATLAS, make sure you pass the "-fatlas" argument when you configure the package. Patrick On Aug 28, 2008, at 9:56 AM, Don Stewart wrote: > patperry: >> Hi everyone, >> >> I've started on bindings for the random number generators and random >> distributions provided by the gsl. The package is available here: >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gsl-random >> >> I've also written a monad and transformer for doing monte carlo >> computations that uses gsl-random internally. Here is that package: >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monte- >> carlo >> >> For a quick tutorial in the latter package, see my blog: >> http://quantile95.com/2008/08/27/a-monte-carlo-monad-for-haskell/ >> >> There is also a more complicated example in the "examples" directory. >> Currently, only normal, uniform, and poisson random variables are >> supported. I have no plans to add anything else unless I need it, >> but >> I will happily accept patches if someone else is willing to do the >> work. >> >> One thing you may need to watch out for is that gsl-random needs to >> link with cblas. If your cblas is not called "cblas", you may have >> to >> edit "gsl-random.cabal" to get things to work correctly. To use the >> cblas that comes with the gsl, change "cblas" to "gslcblas". To use >> ATLAS, change "cblas" to "cblas atlas". > > Arch packages available here, > > http://aur.archlinux.org/packages.php?ID=19416 > http://aur.archlinux.org/packages.php?ID=19417 > > Note I had to patch gsl-random's .cabal file to not explicitly look > for > extra libs in /opt/local/lib. The exact path (if any) should be cabal > (or ./configure's) job, I think. > > -- Don > > From john at repetae.net Thu Aug 28 17:01:20 2008 From: john at repetae.net (John Meacham) Date: Thu Aug 28 16:59:48 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> Message-ID: <20080828210120.GA15616@sliver.repetae.net> On Thu, Aug 28, 2008 at 09:00:41AM +0100, Lennart Augustsson wrote: > I'm certain you can write a kernel in Haskell where the only use of > global variables is those that hardware interfacing forces you to use. And hence you need a safe way to use program-scope variables. It is true that there are many many programs that can be written without them. But those don't concern us, if there are _any_ programs that need them that we wish to write in haskell then we need a safe way in haskell to use them. The truth is, 'process scope' is a useful scope to attach information too. Many operating systems attach various resources to process scope, memory allocation, file descriptors, protection domains. this in and of itself makes it useful for any programs on these operating systems to be able to augment this process scope. I mean, why is it okay to use 'process scope' state provided by the operating system or haskell runtime, but _not_ be able to express such things in haskell itself? I mean, lets look at the items provided for by plain haskell 98 which involve entities that are process scope or bigger: getStdGen, setStdGen, getEnv, getArgs, stdin,stdout,stderr, cpuTimePrecision, isEOF, getCurrentDirectory, setCurrentDirectory, system, exitWith, exitFailure, getProgName, getClockTime, probably others in more subtle ways. do we really want to say that these are all wrong or _must_ be provided by C or the operating system because implementing them in haskell would somehow be unclean? Why shouldn't we be able to implement the concept of a 'current directory' in haskell when we are perfectly happy to use the OS provided one? What if you have an exokernel, where it is expected these things _will_ be implemented in the userspace code. why shouldn't that part of the exokernel be written in haskell? John -- John Meacham - ?repetae.net?john? From ahey at iee.org Thu Aug 28 17:01:29 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 17:00:05 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> Message-ID: <48B71229.2030904@iee.org> Ganesh Sittampalam wrote: > On Thu, 28 Aug 2008, Adrian Hey wrote: > >> implicit parameters (a highly dubious language feature IMO). > > How can you say that with a straight face at the same time as advocating > global variables? :-) Quite easily, what's the problem? IORefs, Chans etc are perfectly ordinary values. Why should they not exist at the top level? The "global variable" lives in "the world", not the IORef. The IORef is just a reference, no different from filepaths in principle (and if having them at the top level is also evil then making this so easy and not screaming about it seems a little inconsistent to me). Regards -- Adrian Hey From dons at galois.com Thu Aug 28 17:09:42 2008 From: dons at galois.com (Don Stewart) Date: Thu Aug 28 17:08:08 2008 Subject: [Haskell-cafe] Galois Tech Talks: Stream Fusion for Haskell Arrays In-Reply-To: <90889fe70807130141y466e422fie1525b4e13500b5e@mail.gmail.com> References: <20080711221333.GB14364@scytale.galois.com> <90889fe70807111526l42def894w12617ab13eee3c61@mail.gmail.com> <20080712221650.GC17008@scytale.galois.com> <90889fe70807130141y466e422fie1525b4e13500b5e@mail.gmail.com> Message-ID: <20080828210942.GA13881@scytale.galois.com> johan.tibell: > On Sun, Jul 13, 2008 at 12:16 AM, Don Stewart wrote: > > johan.tibell: > >> On Sat, Jul 12, 2008 at 12:13 AM, Don Stewart wrote: > >> Any possibility of you guys taping the talk? > > > > Unlikely next week, but soon, yes! > > How about the slides? Slides for the last 3 talks are now up, on the Galois blog, http://www.galois.com/blog/ * Large Scale Monadic Refinement * Adventures in Foreign Function Interfaces * Stream Fusion for Haskell Arrays Cheers, Don From ahey at iee.org Thu Aug 28 17:24:24 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 17:22:57 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219952474.908.26.camel@jcchost> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <1219952474.908.26.camel@jcchost> Message-ID: <48B71788.2050708@iee.org> Jonathan Cast wrote: > This has been answered repeatedly, at least implicitly. Unless you > insist that getWhatever should live in the IO monad and have no > functional arguments (why?), there is no reason why this should be > impossible. > >> What's more, there seems to be no good *semantic* reason why this should >> not be possible. The only objections seem dogmatic to me. > > I haven't seen you give a non-dogmatic reason for wanting global > variables yet, either. You consider real examples from real *standard* libs that we're all using (and presumably not written by clueless hackers such as myself) to be dogmatic? I would call that pragmatic myself. These are the standard libs after all. Shouldn't we expect them to be the perfect examples of how to do things rite? >> But even if someone does produce an entirely unsafePerformIO hack >> free set of standard libs, I have to ask why jump through all these >> hoops? > > To improve the APIs available? There's nothing wrong with the APIs as they are as far as I am concerned. It's their implemenation that's the problem. > You're advocating an extension to a > *purely functional programming language*. So? What's being proposed doesn't compromise referential transparency (at least no more that the IO monad already does, as some might argue). >> There's no semantic difficulty with the proposed language >> extension, > > Although I've noticed it's grossly under-powered compared to what's > needed to implement stdin the way you want to. Can't recall expressing any opinion about how stdin should be implemented so I don't know what your on about here. Regards -- Adrian Hey From jason.dusek at gmail.com Thu Aug 28 17:48:32 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Aug 28 17:46:59 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <48B702B8.2020704@jellybean.co.uk> References: <1365585749.20080827114130@gmail.com> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> <48B63B72.7010208@jellybean.co.uk> <42784f260808280130j49f1fd5ra4f5e843daf602e3@mail.gmail.com> <48B66AE0.30009@jellybean.co.uk> <42784f260808281018p803e42fv8a882fd495927fe9@mail.gmail.com> <48B702B8.2020704@jellybean.co.uk> Message-ID: <42784f260808281448s127515f3ga498915849ff42fb@mail.gmail.com> Well, sure, that could work too. -- _jsn From jonathanccast at fastmail.fm Thu Aug 28 17:45:14 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Aug 28 17:47:28 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B71788.2050708@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <1219952474.908.26.camel@jcchost> <48B71788.2050708@iee.org> Message-ID: <1219959914.908.55.camel@jcchost> On Thu, 2008-08-28 at 22:24 +0100, Adrian Hey wrote: > Jonathan Cast wrote: > > This has been answered repeatedly, at least implicitly. Unless you > > insist that getWhatever should live in the IO monad and have no > > functional arguments (why?), there is no reason why this should be > > impossible. > > > >> What's more, there seems to be no good *semantic* reason why this should > >> not be possible. The only objections seem dogmatic to me. > > > > I haven't seen you give a non-dogmatic reason for wanting global > > variables yet, either. > > You consider real examples from real *standard* libs that we're all > using (and presumably not written by clueless hackers such as myself) > to be dogmatic? Yeah. Same as if the examples were APIs from ML, or Lisp. The neat thing about Haskell is *precisely* that the ML I/O system has an API that is illegal in Haskell. I see no reason, in principle, why the Haskell standard libraries shouldn't contain APIs that should be illegal in new-and-improved Future Haskell. > I would call that pragmatic myself. These are the > standard libs after all. Shouldn't we expect them to be the perfect > examples of how to do things rite? > > >> But even if someone does produce an entirely unsafePerformIO hack > >> free set of standard libs, I have to ask why jump through all these > >> hoops? > > > > To improve the APIs available? > > There's nothing wrong with the APIs as they are as far as I am > concerned. Right. That's exactly what we're arguing about. We maintain they are inferior. You haven't really given any defense of them at all, other than their existence. I consider that a rather weak argument. > It's their implemenation that's the problem. > > > You're advocating an extension to a > > *purely functional programming language*. > > So? What's being proposed doesn't compromise referential transparency > (at least no more that the IO monad already does, as some might argue). What's a referential transparency? I just want a language completely specified by its denotational semantics, in the obvious fashion (e.g., (->) maps to an exponential in a real category). If IO compromises that (heck, who am I kidding, *since* IO compromises that), I'm arguing we get rid of whatever features it has that are questionable. > >> There's no semantic difficulty with the proposed language > >> extension, > > > > Although I've noticed it's grossly under-powered compared to what's > > needed to implement stdin the way you want to. > > Can't recall expressing any opinion about how stdin should be > implemented so I don't know what your on about here. Well, you didn't like *my* implementation. You seem to be rather keen on the current implementation GHC happens to use, where stdin contains internally a mutable buffer. You also seem to be rather insistent that, whatever mechanism GHC uses to get that mutable buffer, be useable to create *any other top-level handle* I want. Now, I happen to know that the only top-level handles that can be established without issuing an open system call are stdin stdout stderr (unless you're happy to have your global nonStdErr start its life attached to an unopened FD). I really don't see what your point is, unless you want to be able to `call open at the top level'. On Thu, 2008-08-28 at 22:01 +0100, Adrian Hey wrote: > Ganesh Sittampalam wrote: > > On Thu, 28 Aug 2008, Adrian Hey wrote: > > > >> implicit parameters (a highly dubious language feature IMO). > > > > How can you say that with a straight face at the same time as advocating > > global variables? :-) > > Quite easily, what's the problem? IORefs, Chans etc are perfectly > ordinary values. Why should they not exist at the top level? They aren't the denotations of any closed Haskell expressions. Scarcely `perfectly ordinary'. > The "global variable" lives in "the world", not the IORef. The > IORef is just a reference, no different from filepaths in principle You didn't like my implementation of stdout along those lines, though... > (and if having them at the top level is also evil then making this > so easy and not screaming about it seems a little inconsistent to me). Good point. We don't just pretend that filepaths make sense in themselves, independently of context. (Or would you like to tell me what the contents of ~/src/globalscript-0.0.1/Language/GlobalScript/Syntax.lhs are?) In fact, this mailing list is dedicated to a language that has the radical idea that you should have to use a whole different type (built using this scary category-theoretical concept called a `monad') just to associate filepaths with file contents. jcc From paul at cogito.org.uk Thu Aug 28 17:56:11 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Thu Aug 28 17:54:49 2008 Subject: [Haskell-cafe] Calling Lockheed, Indra, Thales, Raytheon Message-ID: <48B71EFB.9060309@cogito.org.uk> This is a strange question, I know, but is there anyone working in any of the above companies on this mailing list? Everyone will no doubt be wondering what they have in common. I'm afraid I can't discuss that. Paul. From jonathanccast at fastmail.fm Thu Aug 28 17:53:19 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Aug 28 17:55:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219959914.908.55.camel@jcchost> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <1219952474.908.26.camel@jcchost> <48B71788.2050708@iee.org> <1219959914.908.55.camel@jcchost> Message-ID: <1219960399.908.57.camel@jcchost> On Thu, 2008-08-28 at 14:45 -0700, Jonathan Cast wrote: > On Thu, 2008-08-28 at 22:24 +0100, Adrian Hey wrote: > > Jonathan Cast wrote: > > > This has been answered repeatedly, at least implicitly. Unless you > > > insist that getWhatever should live in the IO monad and have no > > > functional arguments (why?), there is no reason why this should be > > > impossible. > > > > > >> What's more, there seems to be no good *semantic* reason why this should > > >> not be possible. The only objections seem dogmatic to me. > > > > > > I haven't seen you give a non-dogmatic reason for wanting global > > > variables yet, either. > > > > You consider real examples from real *standard* libs that we're all > > using (and presumably not written by clueless hackers such as myself) > > to be dogmatic? > > Yeah. Same as if the examples were APIs from ML, or Lisp. The neat > thing about Haskell is *precisely* that the ML I/O system has an API > that is illegal in Haskell. I see no reason, in principle, why the > Haskell standard libraries shouldn't contain APIs that should be illegal > in new-and-improved Future Haskell. > > > I would call that pragmatic myself. These are the > > standard libs after all. Shouldn't we expect them to be the perfect > > examples of how to do things rite? > > > > >> But even if someone does produce an entirely unsafePerformIO hack > > >> free set of standard libs, I have to ask why jump through all these > > >> hoops? > > > > > > To improve the APIs available? > > > > There's nothing wrong with the APIs as they are as far as I am > > concerned. > > Right. That's exactly what we're arguing about. We maintain they are > inferior. You haven't really given any defense of them at all, other > than their existence. I consider that a rather weak argument. > > > It's their implemenation that's the problem. > > > > > You're advocating an extension to a > > > *purely functional programming language*. > > > > So? What's being proposed doesn't compromise referential transparency > > (at least no more that the IO monad already does, as some might argue). > > What's a referential transparency? I just want a language completely > specified by its denotational semantics, in the obvious fashion (e.g., > (->) maps to an exponential in a real category). > > If IO compromises that (heck, who am I kidding, *since* IO compromises > that), I'm arguing we get rid of whatever features it has that are > questionable. > > > >> There's no semantic difficulty with the proposed language > > >> extension, > > > > > > Although I've noticed it's grossly under-powered compared to what's > > > needed to implement stdin the way you want to. > > > > Can't recall expressing any opinion about how stdin should be > > implemented so I don't know what your on about here. > > Well, you didn't like *my* implementation. You seem to be rather keen > on the current implementation GHC happens to use, where stdin contains > internally a mutable buffer. You also seem to be rather insistent that, > whatever mechanism GHC uses to get that mutable buffer, be useable to > create *any other top-level handle* I want. Now, I happen to know that > the only top-level handles that can be established without issuing an > open system call are > > stdin > stdout > stderr > > (unless you're happy to have your global nonStdErr start its life > attached to an unopened FD). I really don't see what your point is, > unless you want to be able to `call open at the top level'. > > On Thu, 2008-08-28 at 22:01 +0100, Adrian Hey wrote: > > Ganesh Sittampalam wrote: > > > On Thu, 28 Aug 2008, Adrian Hey wrote: > > > > > >> implicit parameters (a highly dubious language feature IMO). > > > > > > How can you say that with a straight face at the same time as advocating > > > global variables? :-) > > > > Quite easily, what's the problem? IORefs, Chans etc are perfectly > > ordinary values. Why should they not exist at the top level? > > They aren't the denotations of any closed Haskell expressions. Scarcely > `perfectly ordinary'. > > > The "global variable" lives in "the world", not the IORef. The > > IORef is just a reference, no different from filepaths in principle > > You didn't like my implementation of stdout along those lines, though... > > > (and if having them at the top level is also evil then making this > > so easy and not screaming about it seems a little inconsistent to me). > > Good point. We don't just pretend that filepaths make sense in > themselves, independently of context. (Or would you like to tell me > what the contents of > ~/src/globalscript-0.0.1/Language/GlobalScript/Syntax.lhs are?) In > fact, this mailing list is dedicated to a language that has the radical > idea that you should have to use a whole different type (built using > this scary category-theoretical concept called a `monad') just to > associate filepaths with file contents. All true. But nevertheless reading it over I think I need to step away from this and cool down a little. jcc From gale at sefer.org Thu Aug 28 18:06:01 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Aug 28 18:04:29 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> Message-ID: <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> Lennart Augustsson wrote: > I don't think anyone has claimed that any interface can be implemented > without globals. > Of course some can't (just pick an interface that is the specification > of a global variable). > What I (and others) claims is that such interfaces are bad. Using a > global variable makes an assumption that there's only ever going to be > one of something, and that's just an inflexible assumption to make. Not true, it's an idiom that comes up often enough. The "right" way to do these kinds of things is to provide some sort of context around the calling function. Something like withAcquiredResource $ \handle -> do ... You (and others) are right that this is better than trying to keep global state in the context of the called function. The problem is that it is not always possible. There are situations in which you simply cannot make demands on a prior context. One important example is when refactoring a single component within an existing mature system. Another is when writing a library for general use if such demands on the calling context seem onerous for the service that the library provides (this latter is the situation for Data.Unique, according to many opinions). I find that Haskell's composability properties help it to outshine any other development environment I know. Experience shows that this is eventually true even for IO related issues - but those generally take a lot more work to discover the right approach. I feel that here we are still working on "tackling the awkward squad". However we work that out, right now we need a working idiom to get out of trouble when this situation comes up. What we have is a hack that is not guaranteed to work. We are abusing the NOINLINE pragma and assuming things about it that are not part of its intended use. We are lucky that it happens to work right now in GHC. So my proposal is that, right now, we make the simple temporary fix of adding an ONLYONCE pragma that does have the proper guaranteed sematics. In the meantime, we can keep tackling the awkward squad. Thanks, Yitz From paul at cogito.org.uk Thu Aug 28 18:16:45 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Thu Aug 28 18:15:15 2008 Subject: [Haskell-cafe] Calling Lockheed, Indra, Thales, Raytheon In-Reply-To: <48B71EFB.9060309@cogito.org.uk> References: <48B71EFB.9060309@cogito.org.uk> Message-ID: <48B723CD.4020303@cogito.org.uk> Paul Johnson wrote: > This is a strange question, I know, but is there anyone working in any > of the above companies on this mailing list? > > Everyone will no doubt be wondering what they have in common. I'm > afraid I can't discuss that. > I will say that this is not a job search, and I'm not trying to sell anyone anything. Paul. From ahey at iee.org Thu Aug 28 18:22:11 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 18:20:44 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> Message-ID: <48B72513.7010700@iee.org> Ganesh Sittampalam wrote: > On Thu, 28 Aug 2008, Adrian Hey wrote: > >> There's no semantic difficulty with the proposed language extension, > > How does it behave in the presence of dynamic loading? To answer this you need to be precise about the semantics of what is being dynamically loaded. But this is too complex an issue for me to get in to right now. Actually as far as things like hs-plugins are concerned I'd alway meant one day what exactly a "plugin" is, semantically. But as I've never had cause to use them so never got round to it. Like is it a value, or does it have state and identity or what? > What about remote procedure calls? Dunno, what problem do you anticipate? > Also what if I want a thread-local variable? Well actually I would say that threads are bad concurrency model so I'm not keen on thread local state at all. Mainly because I'd like to get rid of threads, but also a few other doubts even if we keep threads. Yes, I'm no big fan of the IO monad (or any other monad in fact) and IORefs and all that (all smacks of putting a purely function veneer on good ol fashioned procedural programming to me). But we are where we are and this isn't going to change any time soon. Just trying to fix what seem like obvious problems with Haskells current IO without doing anything too radical and unproven. (I.E. Just making existing practice *safe*, at least in the sense that the compiler ain't gonna fcuk it up with INLINING or CSE and every one understands what is and isn't safe in ACIO) Regards -- Adrian Hey From allbery at ece.cmu.edu Thu Aug 28 18:27:09 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 28 18:25:43 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <87hc95myl1.fsf@malde.org> <20080828064150.GE9712@scytale.galois.com> Message-ID: On 2008 Aug 28, at 13:21, Tim Newsham wrote: >> GNU ld supports "pragmas" which cause the use of certain functions >> to output warnings at link time (try compiling a C program that >> uses gets()). It occurs to me that this, either in compiler or >> linker, would be a nice thing for ghc to do when using fromJust or >> other partial functions. > > would you include all partial functions in this, such as head? I'd like to, but IMO head is a little more acceptable because lists aren't binary like Maybe. fromJust really is the Haskell equivalent of dereferencing a pointer without checking if it's NULL, aside from being more reliably detectable. -- 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 lennart at augustsson.net Thu Aug 28 18:48:04 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Aug 28 18:46:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> Message-ID: As I said earlier, global variables may be necessary when interfacing with legacy things (software or hardware). If Haskell had always taken the pragmatic path of adding what seems easiest and most in line with imperative practice it would not be the language it is today. It would be Perl, ML, or Java. The Haskell philosophy has always been to stick it out until someone comes up with the right solution to a problem rather than picking some easy way out. So I'd rather keep global variables being eye sores (as they are now) to remind us to keep looking for a nice way. For people who don't like this philosophy there are plenty of other languages. And this concludes my contributions on this matter. :) -- Lennart On Thu, Aug 28, 2008 at 11:06 PM, Yitzchak Gale wrote: > The "right" way to do these kinds of things is to provide > some sort of context around the calling function. > Something like withAcquiredResource $ \handle -> do ... > You (and others) are right that this is better than trying to > keep global state in the context of the called function. > > The problem is that it is not always possible. There are > situations in which you simply cannot make demands > on a prior context. One important example is when > refactoring a single component within an existing mature > system. Another is when writing a library for general use > if such demands on the calling context seem onerous > for the service that the library provides (this latter is the > situation for Data.Unique, according to many opinions). From flippa at flippac.org Thu Aug 28 18:59:03 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Thu Aug 28 18:57:32 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> Message-ID: <1219964343.6198.2.camel@flippa-eee> On Thu, 2008-08-28 at 23:48 +0100, Lennart Augustsson wrote: > The Haskell philosophy has always been to stick it out until someone > comes up with the right solution to a problem rather than picking some > easy way out. So I'd rather keep global variables being eye sores (as > they are now) to remind us to keep looking for a nice way. > For people who don't like this philosophy there are plenty of other languages. Talking of which, we really ought to look at an IO typeclass or two (not just our existing MonadIO) and rework the library ops to use it in Haskell'. You're not the only one to want it, and if it's not fixed this time it may never get fixed. -- Philippa Cowderoy From allbery at ece.cmu.edu Thu Aug 28 19:21:48 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 28 19:20:20 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080828210120.GA15616@sliver.repetae.net> References: <48B43EAE.1050207@iee.org> <48B46BD6.30604@iee.org> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <20080828210120.GA15616@sliver.repetae.net> Message-ID: <4A3C15C3-4ACB-4375-8BA5-589EB8E772F9@ece.cmu.edu> On 2008 Aug 28, at 17:01, John Meacham wrote: > On Thu, Aug 28, 2008 at 09:00:41AM +0100, Lennart Augustsson wrote: >> I'm certain you can write a kernel in Haskell where the only use of >> global variables is those that hardware interfacing forces you to >> use. > > OS provided one? What if you have an exokernel, where it is expected > these things _will_ be implemented in the userspace code. why > shouldn't > that part of the exokernel be written in haskell? What's stopping it? Just wrap it in a state-carrying monad representing a context. That way you can also keep multiple contexts if necessary (and I think it is often necessary, or at least desirable, with most exokernel clients). -- 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 gale at sefer.org Thu Aug 28 19:22:15 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Aug 28 19:20:43 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> Message-ID: <2608b8a80808281622v60da3fdma61f096dc06a7fca@mail.gmail.com> Lennart Augustsson wrote: > As I said earlier, global variables may be necessary when interfacing > with legacy things (software or hardware). By "prior context" I didn't mean legacy languages. I meant logically prior - enclosing contexts. It will always be necessary on occasion to refactor code without having any access to the enclosing context. If that refactoring happens to include acquiring an external resource once, using it while our program is running, and releasing it at the end, it is currently an awkward situation for us. We're working on finding a fitting solution to this. > The Haskell philosophy has always been to stick it out until someone > comes up with the right solution to a problem rather than picking some > easy way out. So I'd rather keep global variables being eye sores (as > they are now) to remind us to keep looking for a nice way. I agree. But the eyesores do need to be guaranteed to work. That is not currently the case. It's easy to fix the eyesores, so I think we should do that now. Regards, Yitz From roma at ro-che.info Thu Aug 28 19:33:21 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu Aug 28 19:31:57 2008 Subject: [Haskell-cafe] ANN: gsl-random 0.1 and monte-carlo-0.1 In-Reply-To: <25AF4720-77B9-431C-A72A-BDA4F6217F28@stanford.edu> References: <25AF4720-77B9-431C-A72A-BDA4F6217F28@stanford.edu> Message-ID: <20080828233321.GA7986@flit> * Patrick Perry [2008-08-28 04:24:21-0700] > Hi everyone, > > I've started on bindings for the random number generators and random > distributions provided by the gsl. The package is available here: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gsl-random > > I've also written a monad and transformer for doing monte carlo > computations that uses gsl-random internally. Here is that package: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monte-carlo > > For a quick tutorial in the latter package, see my blog: > http://quantile95.com/2008/08/27/a-monte-carlo-monad-for-haskell/ Should be http://quantile95.com/2008/08/26/a-monte-carlo-monad-for-haskell/ > There is also a more complicated example in the "examples" directory. > Currently, only normal, uniform, and poisson random variables are > supported. I have no plans to add anything else unless I need it, but I > will happily accept patches if someone else is willing to do the work. > > One thing you may need to watch out for is that gsl-random needs to link > with cblas. If your cblas is not called "cblas", you may have to edit > "gsl-random.cabal" to get things to work correctly. To use the cblas > that comes with the gsl, change "cblas" to "gslcblas". To use ATLAS, > change "cblas" to "cblas atlas". > > > Patrick > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Roman I. Cheplyaka :: http://ro-che.info/ kzm: My program contains a bug. How ungrateful, after all I've done for it. From alexander.dunlap at gmail.com Thu Aug 28 19:24:04 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Thu Aug 28 19:50:15 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <87hc95myl1.fsf@malde.org> <20080828064150.GE9712@scytale.galois.com> Message-ID: On Thu, 28 Aug 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Aug 28, at 13:21, Tim Newsham wrote: >>> GNU ld supports "pragmas" which cause the use of certain functions to >>> output warnings at link time (try compiling a C program that uses gets()). >>> It occurs to me that this, either in compiler or linker, would be a nice >>> thing for ghc to do when using fromJust or other partial functions. >> >> would you include all partial functions in this, such as head? > > > I'd like to, but IMO head is a little more acceptable because lists aren't > binary like Maybe. fromJust really is the Haskell equivalent of > dereferencing a pointer without checking if it's NULL, aside from being more > reliably detectable. > > -- > 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 Tools like Neil Mitchell's Catch can do more sophisticated checking, as long as your program can be compiled by YHC. Sometimes fromJust can be quite useful, though, especially in tandem with isJust. For example, > prop_foobar :: SomeType -> Property > prop_foobar x > = isJust (someTypeToMaybe x) ==> fromJust x == expectedResult Alex From ndmitchell at gmail.com Thu Aug 28 20:02:08 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Aug 28 20:00:39 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <87hc95myl1.fsf@malde.org> <20080828064150.GE9712@scytale.galois.com> Message-ID: <404396ef0808281702q66b6c93fq1f660be4a73d719c@mail.gmail.com> Hi > Tools like Neil Mitchell's Catch can do more sophisticated checking, as long > as your program can be compiled by YHC. Sometimes fromJust can be quite > useful, though, especially in tandem with isJust. For example, > >> prop_foobar :: SomeType -> Property >> prop_foobar x >> = isJust (someTypeToMaybe x) ==> fromJust x == expectedResult I was thinking of jumping in on this thread, to advertise Catch, but unfortunately "can be compiled with Yhc" makes it a fairly niche tool :-( However, the fundamental bit of Catch works on an a normal Core language, and I do want to hook it up to GHC's Core language at some point. It could certainly deal with prop_foobar, and things that are far more complex. To get an idea of what Catch can do, I recommend reading the draft paper and skipping to section 5.4 where I verify the entire HsColour program with one small refactoring and no annotations. I even found 3 real crashing bugs in HsColour, that were fixed because Catch pointed them out. Incomplete patterns + a checker (Catch) are just a faster and more efficient way of writing complete patterns without dead code :-) Catch: http://www-users.cs.york.ac.uk/~ndm/catch/ Thanks Neil From ahey at iee.org Thu Aug 28 20:10:43 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 20:09:16 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> Message-ID: <48B73E83.303@iee.org> Lennart Augustsson wrote: > The Haskell philosophy has always been to stick it out until someone > comes up with the right solution to a problem rather than picking some > easy way out. I understood from your previous remarks that you regarded this as a non-problem even in C. There's no justification for using them, at least if you have clean slate priveleges (no legacy issues). That kind of implies to me that we (or at least you) already have the right solution. What is it and why can't we use it right now in Haskell? (Again assuming we have clean slate and no legacy issues). Or can we.. > So I'd rather keep global variables being eye sores (as > they are now) to remind us to keep looking for a nice way. Are you looking? I can't even figure out from your posts if you're even prepared to admit that there *is* a problem, other than there being so many people in the world who can't write proper code, in Haskell or C :-) Regards -- Adrian Hey From ahey at iee.org Thu Aug 28 20:45:16 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Aug 28 20:43:49 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> Message-ID: <48B7469C.6030005@iee.org> Lennart Augustsson wrote: > If Haskell had always taken the pragmatic path of adding what seems > easiest and most in line with imperative practice it would not be the > language it is today. It would be Perl, ML, or Java. > The Haskell philosophy has always been to stick it out until someone > comes up with the right solution to a problem rather than picking some > easy way out. BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's not get too snobby about this. (Sorry, I couldn't resist.) Regards -- Adrian Hey From allbery at ece.cmu.edu Thu Aug 28 20:47:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 28 20:45:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B7469C.6030005@iee.org> References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> <48B7469C.6030005@iee.org> Message-ID: <5A1A1BBF-C733-4F6D-979E-D069B0269CCA@ece.cmu.edu> On 2008 Aug 28, at 20:45, Adrian Hey wrote: > Lennart Augustsson wrote: >> If Haskell had always taken the pragmatic path of adding what seems >> easiest and most in line with imperative practice it would not be the >> language it is today. It would be Perl, ML, or Java. >> The Haskell philosophy has always been to stick it out until someone >> comes up with the right solution to a problem rather than picking >> some >> easy way out. > > BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's > not get too snobby about this. (Sorry, I couldn't resist.) It's anything but easy; there are specific rules you need to follow, including use of certain compiler pragmas, to insure it works properly. -- 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 qdunkan at gmail.com Thu Aug 28 21:02:28 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Thu Aug 28 21:00:56 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: <404396ef0808281702q66b6c93fq1f660be4a73d719c@mail.gmail.com> References: <48B5A9C1.10805@imageworks.com> <63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> <87hc95myl1.fsf@malde.org> <20080828064150.GE9712@scytale.galois.com> <404396ef0808281702q66b6c93fq1f660be4a73d719c@mail.gmail.com> Message-ID: <2518b95d0808281802v3837ac8fvcf71755b6f3dcf1@mail.gmail.com> On Thu, Aug 28, 2008 at 5:02 PM, Neil Mitchell wrote: > Hi > >> Tools like Neil Mitchell's Catch can do more sophisticated checking, as long >> as your program can be compiled by YHC. Sometimes fromJust can be quite >> useful, though, especially in tandem with isJust. For example, >> >>> prop_foobar :: SomeType -> Property >>> prop_foobar x >>> = isJust (someTypeToMaybe x) ==> fromJust x == expectedResult > > I was thinking of jumping in on this thread, to advertise Catch, but > unfortunately "can be compiled with Yhc" makes it a fairly niche tool > :-( However, the fundamental bit of Catch works on an a normal Core > language, and I do want to hook it up to GHC's Core language at some > point. It could certainly deal with prop_foobar, and things that are > far more complex. So are we going to get ghc -Wcatch? That would be really cool. catch has always sounded very interesting, but I've never used it because I use too many ghc libs. From ok at cs.otago.ac.nz Thu Aug 28 22:40:42 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Aug 28 22:39:19 2008 Subject: [Haskell-cafe] Pure hashtable library In-Reply-To: <3589_1219917383_m7S9uKgW014520_48B66AE0.30009@jellybean.co.uk> References: <1365585749.20080827114130@gmail.com> <48B5710A.40101@jellybean.co.uk> <1806696757.20080827193605@gmail.com> <32129_1219854090_m7RGLS5w025646_200808271801.24909.daniel.is.fischer@web.de> <42784f260808272241p46cef74dy5acb005ed0f59f05@mail.gmail.com> <48B63B72.7010208@jellybean.co.uk> <42784f260808280130j49f1fd5ra4f5e843daf602e3@mail.gmail.com> <3589_1219917383_m7S9uKgW014520_48B66AE0.30009@jellybean.co.uk> Message-ID: On 28 Aug 2008, at 9:07 pm, Jules Bean wrote: > Insert for Data.Sequence is log(i) where i is the position of the > insertion; clearly bounded by log(n). toList is O(n) and index is > (at worst) log(i). > > I think the corresponding operations with tries are log(n), Let the key you want to insert have length L. Then insertion into a trie is O(L), independent of the size of the collection. If the "alphabet" the key's elements are drawn from is large, you can use a Ternary Search Tree, and insertion is then O(L.lg B) where B is the branching factor. There are fast Trie construction algorithms which are linear in the total size of the collection, \sum_{i=1}^{n}L_i. The worst case for Data.Sequence is where keys mostly vary at the end, in which case comparisons take O(L) time, and the cost is O(L.lg n), where n is usually much bigger than B. > So, it's all in the constants, isn't it? No. From DekuDekuplex at Yahoo.com Thu Aug 28 22:49:38 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Thu Aug 28 22:49:39 2008 Subject: [Haskell-cafe] Re: Calling Lockheed, Indra, Thales, Raytheon References: <48B71EFB.9060309@cogito.org.uk> <48B723CD.4020303@cogito.org.uk> Message-ID: On Thu, 28 Aug 2008 23:16:45 +0100, Paul Johnson wrote: >Paul Johnson wrote: >> This is a strange question, I know, but is there anyone working in any >> of the above companies on this mailing list? >> >> Everyone will no doubt be wondering what they have in common. I'm >> afraid I can't discuss that. >> >I will say that this is not a job search, and I'm not trying to sell >anyone anything. Hm ... that sounds like a very strange inquiry. So you want to know the names of people working for those companies without disclosing the reason or purpose of the inquiry? I don't work for any of them, but if I did, I probably wouldn't respond. The very first thing that would come to mind is that they are keeping a black list of people who are posting messages to this mailing list. :-( -- Benjamin L. Russell From dan.doel at gmail.com Fri Aug 29 00:22:48 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Aug 29 00:17:17 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <20080828182834.GS12859@darcs.net> References: <534781822.20080826190130@gmail.com> <200808281317.30358.dan.doel@gmail.com> <20080828182834.GS12859@darcs.net> Message-ID: <200808290022.49248.dan.doel@gmail.com> On Thursday 28 August 2008 2:28:35 pm David Roundy wrote: > On Thu, Aug 28, 2008 at 01:17:29PM -0400, Dan Doel wrote: > > On Thursday 28 August 2008 12:26:27 pm Adrian Hey wrote: > > > As I've pointed out several times already you can find simple examples > > > in the standard haskell libs. So far nobody has accepted my challenge > > > to re-implement any of these "competantly" (I.E. avoiding the use of > > > global variables). > > > > > > Why don't you try it with Data.Unique and find out :-) > > > > Here's a first pass: > > > > -- snip -- > > > > {-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-} > > > > module Unique where > > If you want this to actually provide any guarantees, of course, you'll > have to provide an export list. Yes, quite right. I didn't spend a lot of time on it. I believe U and unU would need to be hidden to prevent people from doing bad things. Another problem I thought of after the fact is that if you need to extend the IO monad in any other similar way, you're out of luck. However, I think you can modify things to something like: newtype UT r m a = UT { unUT :: ReaderT (MVar Integer) m a } ... runUT :: MonadIO m => (forall r. UT r m a) -> m a runUT m = liftIO (newMVar 0) >>= runReaderT (unUT m) ... Or if you want to get really fancy, maybe you could invent an entire new sectioned, composable IO monad like Datatypes a la Carte. But that's a fair amount more work. Cheers. -- Dan From duncan.coutts at worc.ox.ac.uk Thu Aug 28 16:56:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 29 02:08:59 2008 Subject: [Haskell-cafe] Re: two problems with Data.Binary and Data.ByteString In-Reply-To: References: <20080813044314.GB3743@scytale.galois.com> <1218679102.7661.590.camel@localhost> <20080814172133.GA10871@scytale.galois.com> <1218737836.13639.52.camel@localhost> <20080825212828.GA742@scytale.galois.com> <20080826220422.GI3200@scytale.galois.com> <1219794277.24846.81.camel@localhost> Message-ID: <1219956985.24846.244.camel@localhost> On Thu, 2008-08-28 at 21:34 +0200, Ben Franksen wrote: > Just some raw ideas: > > What if we had a way to express 'optional dependencies' between packages in > a cabal file. Something like 'if package x is installed (and satisfies > given version constraints) then add module UseX'. > > One problem with this idea is that I might install the missing (optional) > package afterwards, and then I still do not have the instance I would like > (unless I re-build). Could cabal be instructed to re-build a package if an > optional dependency becomes available (or if one gets removed)? Right, requiring an order of installation is rather unfortunate. Always rebuilding things doesn't really fit well with many deployment models. Duncan From ahey at iee.org Fri Aug 29 04:22:15 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Aug 29 04:20:48 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <5A1A1BBF-C733-4F6D-979E-D069B0269CCA@ece.cmu.edu> References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> <48B7469C.6030005@iee.org> <5A1A1BBF-C733-4F6D-979E-D069B0269CCA@ece.cmu.edu> Message-ID: <48B7B1B7.5070905@iee.org> Brandon S. Allbery KF8NH wrote: > > On 2008 Aug 28, at 20:45, Adrian Hey wrote: > >> Lennart Augustsson wrote: >>> If Haskell had always taken the pragmatic path of adding what seems >>> easiest and most in line with imperative practice it would not be the >>> language it is today. It would be Perl, ML, or Java. >>> The Haskell philosophy has always been to stick it out until someone >>> comes up with the right solution to a problem rather than picking some >>> easy way out. >> >> BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's >> not get too snobby about this. (Sorry, I couldn't resist.) > > > It's anything but easy; there are specific rules you need to follow, > including use of certain compiler pragmas, to insure it works properly. Yes, of course. The worst thing about all this is that the single most common use case AFAICS (the one under discussion) isn't even a "safe" use. Just pointing out that this pseudo function is certainly not something one would expect from an organisation as dedicated to the persuit of perfection as Lennart would have us believe. It's an expedient hack. Not that I wish to seem ungrateful or anything :-) Regards -- Adrian Hey From wren at freegeek.org Fri Aug 29 04:29:18 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Aug 29 04:27:46 2008 Subject: [Haskell-cafe] HEq and Context reduction stack overflow, non optimal ghc behaviour ? In-Reply-To: <20080827161228.GB18263@gmx.de> References: <20080826001102.GA1625@gmx.de> <20080827150718.GA18263@gmx.de> <20080827161228.GB18263@gmx.de> Message-ID: <48B7B35E.1000608@freegeek.org> Marc Weber wrote: > Now ghc can try to resolve (1),(2),(3) in arbitrary order.. > What happens if ghc starts with (3)? > It tries to find an instance for not known types.. > Damn. There is even a matching instance.. > , the same one. This time it starts even with > HEq which is even more bad! > after the second recursion it already knows that won't find a > solution, because it will try to resolve > HEq again and again.. > > What happens if ghc starts with (1 or 2)? > It happily finds an instance *and* it can even resolve elNr and elNr' > Those can then be used to find an instance for (3) easily > > So I think the behaviour of ghc should be changed to prefer resolving > class constraints which reduce the amount of unkown types first > > I even consider this beeing a bug ? > > So maybe this thread should be moved to glasgow-haskell-users ? There are a number of issues like this due to the fact that typeclass instances aren't determined by full SLD resolution. More particularly the determinism information in fundeps seems to be ignored in this whole process. Not that I'm a GHC hacker (yet), but research in this area is at the top of my to-do stack; alas that's still a ways away. To put a refinement on your proposal, I'd suggest that fundeps be used to construct a dataflow graph in order to know which instances to pursue first (namely, the leaves). To resolve the ordering any toposort of the dataflow graph should be fine. This still has the problem of if there's no toposort, though: class Foo a b | a -> b class Bar a b | b -> a class Wtf a b instance (Foo a b, Bar a b) => Wtf a b There are a few standard approaches to break the cycle, though if instances of Foo or Bar are given inductively we might run into the same problems as your code. Here's another proposal, and perhaps an easier one to hack together for the time being. When pursuing the context of an instance for some class A, resolve all instances for non-A classes before pursuing instances for A. It's not a general solution, but it's closer to correct at least. -- Live well, ~wren From wren at freegeek.org Fri Aug 29 04:57:14 2008 From: wren at freegeek.org (wren ng thornton) Date: Fri Aug 29 04:55:42 2008 Subject: [Haskell-cafe] Haskell Propeganda In-Reply-To: References: <200808240015.57217.daniel.is.fischer@web.de> <117f2cc80808260654r6c8bb44rc2817b4c329a6368@mail.gmail.com> <9A015D433594EA478964C5B34AF3179B0109A259@ntsydexm06.pc.internal.macquarie.com> <48B5A9C1.10805@imageworks.com> <12697_1219869313_m7RKZCTi011219_63215556-A8DE-4141-BC5B-E4A828D3360B@galois.com> Message-ID: <48B7B9EA.9060104@freegeek.org> Richard A. O'Keefe wrote: > > On 28 Aug 2008, at 8:34 am, Aaron Tomb wrote: >> What type safety buys you, in my mind, is that Nothing is only a valid >> value for explicit Maybe types. In cases where you don't use Maybe, >> the "null" situation just can't occur. In languages with null >> pointers, any pointer could possibly be null. > > This is not true of Eiffel. > The ECMA Eiffel standard has > ?T either a void reference or a reference to an instance of T > !T a reference to an instance of T > T same as !T in ECMA Eiffel; used to be same as ?T > > I suppose you could call the detachable type ?T an *implicit* Maybe. > Needless to say, the switch in semantics of undecorated T helped to > fork the Eiffel community... Just because the devil needs more advocacy... there are safer dialects of C that have non-nullable pointers in addition to the standard variety. Cyclone[1] comes to mind, there are others. In so far as propaganda goes, imperative programming is ugly, unsafe, and evil, but it is getting better. Blanket statements about their failings tend toward falsity as they keep adopting things from the functional world. [1] http://www.cs.bu.edu/groups/ibench/presentations/2003-04-10.pdf -- Live well, ~wren From briqueabraque at yahoo.com Fri Aug 29 09:30:35 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Fri Aug 29 09:29:17 2008 Subject: [Haskell-cafe] Named field syntax Message-ID: Hi, I see that this works: data Test = Test Integer String This also works: data Test = Test {a::Integer,b::String} However, this doesn't: data Test = Test Integer {b::String} Is there some way to name only a single, or a few, of some data type fields? Thanks, Maur?cio From ketil at malde.org Fri Aug 29 09:40:42 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Aug 29 09:37:39 2008 Subject: [Haskell-cafe] Named field syntax In-Reply-To: (=?utf-8?Q?=22Maur=C3=AD=22's?= message of "Fri\, 29 Aug 2008 10\:30\:35 -0300") References: Message-ID: <87d4jsszvp.fsf@malde.org> Maur??cio writes: > However, this doesn't work: > > data Test = Test Integer {b::String} > Is there some way to name only a single, or a few, > of some data type fields? data Test = Test Integer String b :: Test -> String b (Test i s) = s :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From waldmann at imn.htwk-leipzig.de Fri Aug 29 09:39:15 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Aug 29 09:39:49 2008 Subject: [Haskell-cafe] Named field syntax In-Reply-To: References: Message-ID: <48B7FC03.1060502@imn.htwk-leipzig.de> > data Test = Test Integer {b::String} positional (= unnamed) record notation is a language design error :-) and its use should be discouraged. - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080829/b2ef9bb9/signature.bin From briqueabraque at yahoo.com Fri Aug 29 09:41:41 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Fri Aug 29 09:40:17 2008 Subject: [Haskell-cafe] Syntax of 'do' Message-ID: Hi, http://haskell.org/haskellwiki/Keywords says that: ------------- [do is a] syntactic sugar for use with monadic expressions. For example: do { x ; result <- y ; foo result } is shorthand for: x >> y >>= \result -> foo result ------------- I did some tests hiding Prelude.>> and Prelude.>>= and applying >> and >>= to non-monadic types, and saw that 'do' would not apply to them. So, I would like to add the following to that text: ------------- as long as proper types apply: x :: Prelude.Monad a y :: Prelude.Monad b foo :: b -> Prelude.Monad c ------------- Is that correct (Haskell and English)? Thanks, Maur?cio From miguelimo38 at yandex.ru Fri Aug 29 09:48:59 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Aug 29 09:47:33 2008 Subject: [Haskell-cafe] Syntax of 'do' In-Reply-To: References: Message-ID: -XNoImplicitPrelude ? On 29 Aug 2008, at 17:41, Maur? cio wrote: > Hi, > > http://haskell.org/haskellwiki/Keywords says that: > > ------------- > [do is a] syntactic sugar for use with monadic > expressions. For example: > > do { x ; result <- y ; foo result } > > is shorthand for: > > x >> y >>= \result -> foo result > ------------- > > I did some tests hiding Prelude.>> and Prelude.>>= > and applying >> and >>= to non-monadic types, and > saw that 'do' would not apply to them. So, I would > like to add the following to that text: > > ------------- > as long as proper types apply: > > x :: Prelude.Monad a > y :: Prelude.Monad b > foo :: b -> Prelude.Monad c > ------------- > > Is that correct (Haskell and English)? > > Thanks, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery at ece.cmu.edu Fri Aug 29 10:13:57 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Aug 29 10:12:33 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B7B1B7.5070905@iee.org> References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> <48B7469C.6030005@iee.org> <5A1A1BBF-C733-4F6D-979E-D069B0269CCA@ece.cmu.edu> <48B7B1B7.5070905@iee.org> Message-ID: <8FFB54A5-F470-4B8C-92CE-83278EEA2501@ece.cmu.edu> On 2008 Aug 29, at 4:22, Adrian Hey wrote: > Brandon S. Allbery KF8NH wrote: >> On 2008 Aug 28, at 20:45, Adrian Hey wrote: >>> Lennart Augustsson wrote: >>>> If Haskell had always taken the pragmatic path of adding what seems >>>> easiest and most in line with imperative practice it would not be >>>> the >>>> language it is today. It would be Perl, ML, or Java. >>>> The Haskell philosophy has always been to stick it out until >>>> someone >>>> comes up with the right solution to a problem rather than picking >>>> some >>>> easy way out. >>> >>> BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's >>> not get too snobby about this. (Sorry, I couldn't resist.) >> It's anything but easy; there are specific rules you need to >> follow, including use of certain compiler pragmas, to insure it >> works properly. > > Yes, of course. The worst thing about all this is that the single most > common use case AFAICS (the one under discussion) isn't even a "safe" > use. Just pointing out that this pseudo function is certainly not > something one would expect from an organisation as dedicated to the > persuit of perfection as Lennart would have us believe. It's an > expedient hack. Not that I wish to seem ungrateful or anything :-) ...but, as he noted, we *do* that until we find the right way to do it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bulat.ziganshin at gmail.com Fri Aug 29 10:21:17 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Aug 29 10:20:18 2008 Subject: [Haskell-cafe] Syntax of 'do' In-Reply-To: References: Message-ID: <17010022428.20080829182117@gmail.com> Hello Mauri?cio, Friday, August 29, 2008, 5:41:41 PM, you wrote: afaik, this shorthand isn't exact. actually there is more code dealing with fails and this code use Monad operations > Hi, > http://haskell.org/haskellwiki/Keywords says that: > ------------- > [do is a] syntactic sugar for use with monadic > expressions. For example: > do { x ; result <- y ; foo result } > is shorthand for: > x >> y >>= \result -> foo result > ------------- > I did some tests hiding Prelude.>> and Prelude.>>= and applying >>> and >>= to non-monadic types, and > saw that 'do' would not apply to them. So, I would > like to add the following to that text: > ------------- > as long as proper types apply: > x :: Prelude.Monad a > y :: Prelude.Monad b foo :: b ->> Prelude.Monad c > ------------- > Is that correct (Haskell and English)? > Thanks, > Mauricio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Fri Aug 29 10:31:52 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Aug 29 10:30:23 2008 Subject: [Haskell-cafe] Named field syntax In-Reply-To: References: Message-ID: <1922A8A3-3114-44B7-A77F-1E7EB12870E2@ece.cmu.edu> On 2008 Aug 29, at 9:30, Maur? cio wrote: > However, this doesn't: > > data Test = Test Integer {b::String} > > Is there some way to name only a single, or a few, > of some data type fields? There's no shorthand for it, no (and therefore you can't get one that works for pattern matching). Personally, I haven't found it a hardship, because you can always used the unnamed field 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 dmhouse at gmail.com Fri Aug 29 11:07:48 2008 From: dmhouse at gmail.com (David House) Date: Fri Aug 29 11:06:14 2008 Subject: [Haskell-cafe] Syntax of 'do' In-Reply-To: References: Message-ID: 2008/8/29 Maur??cio : > x :: Prelude.Monad a > y :: Prelude.Monad b > foo :: b -> Prelude.Monad c Monad is not a type, it is a type class, so you probably mean: x :: Monad m => m a y :: Monad m => m b foo :: Monad m => b -> m c With the further understanding that all three `m's must be the same. -- -David From philip.weaver at gmail.com Fri Aug 29 11:37:03 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Aug 29 11:35:29 2008 Subject: [Haskell-cafe] Syntax of 'do' In-Reply-To: References: Message-ID: On Fri, Aug 29, 2008 at 6:41 AM, Maur??cio wrote: > Hi, > > http://haskell.org/haskellwiki/Keywords says that: > > ------------- > [do is a] syntactic sugar for use with monadic > expressions. For example: > > do { x ; result <- y ; foo result } > > is shorthand for: > > x >> y >>= \result -> foo result > ------------- > > I did some tests hiding Prelude.>> and Prelude.>>= > and applying >> and >>= to non-monadic types, and > saw that 'do' would not apply to them. So, I would > like to add the following to that text: > It sounds like you tried to redefine (>>) and (>>=) and make 'do' use the new definitions. This is not possible, regardless of what types you give (>>) and (>>=). If you want to define (>>) and (>>=), do so for a particular instance of Monad. > ------------- > as long as proper types apply: > > x :: Prelude.Monad a > y :: Prelude.Monad b > foo :: b -> Prelude.Monad c > ------------- > > Is that correct (Haskell and English)? > > Thanks, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080829/5694026c/attachment.htm From dmhouse at gmail.com Fri Aug 29 11:50:04 2008 From: dmhouse at gmail.com (David House) Date: Fri Aug 29 11:48:30 2008 Subject: [Haskell-cafe] Syntax of 'do' In-Reply-To: References: Message-ID: 2008/8/29 Philip Weaver : > It sounds like you tried to redefine (>>) and (>>=) and make 'do' use the > new definitions. This is not possible, regardless of what types you give > (>>) and (>>=). Watch out for rebindable syntax: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax At first reading, I thought that -XNoImplicitPrelude was required to turn this on. But now I'm not sure: it seems that if you hide Prelude.>>= and Prelude.return, that ought to be enough to make do notation work with your alternative definitions. I'm not at home, so I can't try this right now. -- -David From ahey at iee.org Fri Aug 29 11:56:07 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Aug 29 11:54:40 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <8FFB54A5-F470-4B8C-92CE-83278EEA2501@ece.cmu.edu> References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> <48B7469C.6030005@iee.org> <5A1A1BBF-C733-4F6D-979E-D069B0269CCA@ece.cmu.edu> <48B7B1B7.5070905@iee.org> <8FFB54A5-F470-4B8C-92CE-83278EEA2501@ece.cmu.edu> Message-ID: <48B81C17.8030501@iee.org> Brandon S. Allbery KF8NH wrote: > On 2008 Aug 29, at 4:22, Adrian Hey wrote: >> Brandon S. Allbery KF8NH wrote: >>> On 2008 Aug 28, at 20:45, Adrian Hey wrote: >>>> Lennart Augustsson wrote: >>>>> If Haskell had always taken the pragmatic path of adding what seems >>>>> easiest and most in line with imperative practice it would not be the >>>>> language it is today. It would be Perl, ML, or Java. >>>>> The Haskell philosophy has always been to stick it out until someone >>>>> comes up with the right solution to a problem rather than picking some >>>>> easy way out. >>>> >>>> BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's >>>> not get too snobby about this. (Sorry, I couldn't resist.) >>> It's anything but easy; there are specific rules you need to follow, >>> including use of certain compiler pragmas, to insure it works properly. >> >> Yes, of course. The worst thing about all this is that the single most >> common use case AFAICS (the one under discussion) isn't even a "safe" >> use. Just pointing out that this pseudo function is certainly not >> something one would expect from an organisation as dedicated to the >> persuit of perfection as Lennart would have us believe. It's an >> expedient hack. Not that I wish to seem ungrateful or anything :-) > > > ...but, as he noted, we *do* that until we find the right way to do it. So what's the problem with doing it *safely*, that is at least until someone has found the mythic "right way to do it". Not that anybody has ever been able to offer any rational explanation of what's *wrong* with the current proposed solution AFAICS. Regards -- Adrian Hey From igouy2 at yahoo.com Fri Aug 29 12:11:50 2008 From: igouy2 at yahoo.com (Isaac Gouy) Date: Fri Aug 29 12:10:16 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <20080826180128.GD3200@scytale.galois.com> Message-ID: <500831.96537.qm@web65413.mail.ac4.yahoo.com> --- Don Stewart wrote: -snip > > How should the benchmarks game approach multicore? > > Well, there's a famous paper, > > Algorithm + Strategy = Parallelism > > I'd imagine we use the benchmark game's algorithms, but let > submitters determine the strategy. Then the results would show > > a) how well you utilize the cores, and > b) overall wall clock results. otoh I see the attraction of showing parallelised versions alongside existing programs; otoh that adds yet another layer of confusion about why the measurements differ (and another level of quarreling about whether even vaguely the same thing is being measured); otoh some existing programs already use more cores when they can ... The Scala threadring program shows 524s cpu but 157s elapsed: http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all > I'm keen to get going on this, if only because I think we can turn > out parallelised versions of many of the existing programs, fairly > cheaply. I'm always delighted that you're keen to get going on things like this! The benchmarks game always seems to demand somewhat unnatural acts and here's another - is there an effective way to /prevent/ ghc using multiple cores when multiple cores are available? Can we force ghc to only use one core on the quadcore machine? (Moreover can we do the same trick for other languages?) From donn at avvanta.com Fri Aug 29 12:15:22 2008 From: donn at avvanta.com (Donn Cave) Date: Fri Aug 29 12:14:09 2008 Subject: [Haskell-cafe] Parsec and network data References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Message-ID: <20080829161522.79B9E93C51@mail.avvanta.com> Quoth brian : | I want to use Parsec to parse NNTP data coming to me from a handle I | get from connectTo. Are you still having trouble with this? Take my opinion for what it's worth - I'm no Haskell guru - but for me, your basic approach is unsound. I would implement the network service input data stream myself, with timeouts, encryption, whatever as required, and then apply the parser to available data as a simple, pure function that returns NNTP results and whatever data remains. So the parser would never see any streams or handles or anything, it would just get strings to parse. Donn Cave, donn@avvanta.com From atomb at galois.com Fri Aug 29 12:29:44 2008 From: atomb at galois.com (Aaron Tomb) Date: Fri Aug 29 12:28:12 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <500831.96537.qm@web65413.mail.ac4.yahoo.com> References: <500831.96537.qm@web65413.mail.ac4.yahoo.com> Message-ID: On Aug 29, 2008, at 9:11 AM, Isaac Gouy wrote: > The benchmarks game always seems to demand somewhat unnatural acts and > here's another - is there an effective way to /prevent/ ghc using > multiple cores when multiple cores are available? Can we force ghc to > only use one core on the quadcore machine? (Moreover can we do the > same > trick for other languages?) There is indeed. In fact, GHC-compiled programs will only use multiple processors if you explicitly tell them to. To make use of two processors, for instance, you have to pass the flags '+RTS -N2' to the compiled executable when you run it. This tells it to schedule its internal threads on two OS threads, which the OS will presumably run on two processors if possible. Aaron From waldmann at imn.htwk-leipzig.de Fri Aug 29 14:01:01 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Aug 29 13:59:27 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <20080829161522.79B9E93C51@mail.avvanta.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> Message-ID: <48B8395D.1080605@imn.htwk-leipzig.de> Donn Cave wrote: > ... I would implement the network service > input data stream myself, with timeouts, encryption, whatever as required, > and then apply the parser to available data as a simple, pure function > that returns NNTP results and whatever data remains. So the parser would > never see any streams or handles or anything, it would just get strings > to parse. A likely problem with that is that your implementation of the "input data stream" will still need to parse some information from it. So you're going to replicate code from the parser. I think the following is analoguous. Imagine you're writing a parser for a simple programming language. A program is a sequence of statements. Fine, you do "readFile" (once) and then apply a pure Parsec parser. Then you decide to include "import" statements in your language. Suddenly the parser needs to do IO. Assume the import statements need not be the first statements of the program (there may be headers, comments etc. before). Then you really have to interweave the parsing and the IO. If anyone has a nice solution to this, please tell. - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080829/c12db864/signature.bin From dons at galois.com Fri Aug 29 14:16:29 2008 From: dons at galois.com (Don Stewart) Date: Fri Aug 29 14:14:50 2008 Subject: [Haskell-cafe] Haskell Speed Myth In-Reply-To: <500831.96537.qm@web65413.mail.ac4.yahoo.com> References: <20080826180128.GD3200@scytale.galois.com> <500831.96537.qm@web65413.mail.ac4.yahoo.com> Message-ID: <20080829181629.GB17700@scytale.galois.com> igouy2: > otoh I see the attraction of showing parallelised versions alongside > existing programs; otoh that adds yet another layer of confusion about > why the measurements differ (and another level of quarreling about > whether even vaguely the same thing is being measured); otoh some > existing programs already use more cores when they can ... > > The Scala threadring program shows 524s cpu but 157s elapsed: > > http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all Very cool! > > I'm keen to get going on this, if only because I think we can turn > > out parallelised versions of many of the existing programs, fairly > > cheaply. > > I'm always delighted that you're keen to get going on things like this! > > The benchmarks game always seems to demand somewhat unnatural acts and > here's another - is there an effective way to /prevent/ ghc using > multiple cores when multiple cores are available? Can we force ghc to > only use one core on the quadcore machine? (Moreover can we do the same > trick for other languages?) Certainly, for the quad core, to get all 4 cores in play: * compile with -threaded * run with +RTS -N4 to force single core, we'll: * compile normally * run normally -- Don From derek.a.elkins at gmail.com Fri Aug 29 14:23:18 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Aug 29 14:21:49 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <48B8395D.1080605@imn.htwk-leipzig.de> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> <48B8395D.1080605@imn.htwk-leipzig.de> Message-ID: <1220034198.10520.0.camel@derek-laptop> On Fri, 2008-08-29 at 20:01 +0200, Johannes Waldmann wrote: > Donn Cave wrote: > > > ... I would implement the network service > > input data stream myself, with timeouts, encryption, whatever as required, > > and then apply the parser to available data as a simple, pure function > > that returns NNTP results and whatever data remains. So the parser would > > never see any streams or handles or anything, it would just get strings > > to parse. > > A likely problem with that is that your implementation of the "input > data stream" will still need to parse some information from it. > So you're going to replicate code from the parser. > > I think the following is analoguous. > > Imagine you're writing a parser for a simple programming language. > A program is a sequence of statements. > Fine, you do "readFile" (once) and then apply a pure Parsec parser. > > Then you decide to include "import" statements in your language. > Suddenly the parser needs to do IO. Assume the import statements > need not be the first statements of the program > (there may be headers, comments etc. before). > Then you really have to interweave the parsing and the IO. > > If anyone has a nice solution to this, please tell. - J.W. Using parsec3 you can just do exactly what you said. From brianchina60221 at gmail.com Fri Aug 29 14:34:42 2008 From: brianchina60221 at gmail.com (brian) Date: Fri Aug 29 14:33:08 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <20080829161522.79B9E93C51@mail.avvanta.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> Message-ID: <22f6a8f70808291134g67e7a08dh92fc71a9df8d4208@mail.gmail.com> On Fri, Aug 29, 2008 at 11:15 AM, Donn Cave wrote: > Quoth brian : > > | I want to use Parsec to parse NNTP data coming to me from a handle I > | get from connectTo. > > I would implement the network service > input data stream myself, with timeouts Could you explain a little about how this would look? If it's reading characters trying to make a String we want to call a 'line', isn't that what the parser is supposed to be doing? If you were parsing /etc/passwd, would you read each line yourself and give each one to Parsec? > So the parser would > never see any streams or handles or anything, it would just get strings > to parse. Well, I think the parser still works with a Stream. For example, Text/Parsec/ByteString.hs makes ByteString an instance of Stream. My next try is to make this thing an instance of Stream: data Connection = Connection { connectionHandle :: Handle , connectionData :: C.ByteString } In uncons, the easy case is when connectionData is nonnull. If it is null, hWaitForInput on the handle. If we get something, read it and return appropriate stuff. If not, it's a parse error similar to getting unexpected EOF in a file. From darrinth at gmail.com Fri Aug 29 14:43:49 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Fri Aug 29 14:42:14 2008 Subject: [Haskell-cafe] New Category Theory Intros Message-ID: These category theory intros were new to me. Thought others here might care. http://golem.ph.utexas.edu/category/2008/08/new_structures_for_physics_i.html -- Darrin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080829/bd3b6c9c/attachment.htm From andrewcoppin at btinternet.com Fri Aug 29 15:56:16 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Aug 29 15:54:37 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> Message-ID: <48B85460.2070109@btinternet.com> Neil Mitchell wrote: > Hi > > >> I'm writing a simple interpretter for a small extended-lambda-calculus sort >> of language. And I'd just like to say... RECURSIVE LET-BINDS! GAAAAH!!! >_< >> > > Agreed :-) > I'm glad it's not just me! ;-) (Oleg cat sez: "see, yr type problum not so hard".) >> To illustrate: >> >> let x = f x; y = 5 in x y >> >> A simple-minded interpretter might try to replace every occurrance of "x" >> with "f x". This yields >> >> let y = 5 in (f x) y >> > > That's wrong, its a two step transformation. You just substitute all > occurances of x for f x: > > let x = f (f x); y = 5 in (f x) y > > For the case let x = 5 in x, you do the same thing: > > let x = 5 in 5 > > Now as a second step you hoover up unused let bindings and disguard: > > 5 > > You seem to be combining the substitution and the removing of dead let > bindings, if you separate them you should have more luck. > Right. So substitute in the RHS and then perform a let-cull afterwards. Got it. I've been playing with this today, and no matter what rules I come up with, it seems to be ridiculously easy to put the interpretter into an infinite loop from which it will never escape. Is there any way to know which binds are "worth" expanding and which ones aren't? (I have a sinking feeling this might be equivilent to the Halting Problem...) For example, if you have "let x = f y; y = g x in x" then since all the functions are free variables, there's really nothing much "useful" you can do to simplify this any further. However, my interpretter merrily goes into an endless loop building a huge expression like "f (g (f (g (f (g..." Is it possible to avoid this? (The problem isn't unique to recursive let-binds of course. I discovered today that (\x -> x x) (\x -> x x) reduces to itself, so that puts the interpretter into a loop too. However, NON-recursive let-binds always terminate eventually. It's only the recursive ones that cause problems.) My word, this stuff is really surprisingly hard! At least this time I built a general-purpose renamer rather than trying to avoid name capture by construction! ;-) From jonathanccast at fastmail.fm Fri Aug 29 16:12:48 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Aug 29 16:15:03 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48B85460.2070109@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> Message-ID: <1220040768.908.67.camel@jcchost> On Fri, 2008-08-29 at 20:56 +0100, Andrew Coppin wrote: > Neil Mitchell wrote: > > Hi > > > > > >> I'm writing a simple interpretter for a small extended-lambda-calculus sort > >> of language. And I'd just like to say... RECURSIVE LET-BINDS! GAAAAH!!! >_< > >> > > > > Agreed :-) > > > > I'm glad it's not just me! ;-) > > (Oleg cat sez: "see, yr type problum not so hard".) > > >> To illustrate: > >> > >> let x = f x; y = 5 in x y > >> > >> A simple-minded interpretter might try to replace every occurrance of "x" > >> with "f x". This yields > >> > >> let y = 5 in (f x) y > >> > > > > That's wrong, its a two step transformation. You just substitute all > > occurances of x for f x: > > > > let x = f (f x); y = 5 in (f x) y > > > > For the case let x = 5 in x, you do the same thing: > > > > let x = 5 in 5 > > > > Now as a second step you hoover up unused let bindings and disguard: > > > > 5 > > > > You seem to be combining the substitution and the removing of dead let > > bindings, if you separate them you should have more luck. > > > > Right. So substitute in the RHS and then perform a let-cull afterwards. > Got it. > > I've been playing with this today, and no matter what rules I come up > with, it seems to be ridiculously easy to put the interpretter into an > infinite loop from which it will never escape. Is there any way to know > which binds are "worth" expanding and which ones aren't? (I have a > sinking feeling this might be equivilent to the Halting Problem...) > > For example, if you have "let x = f y; y = g x in x" then since all the > functions are free variables, there's really nothing much "useful" you > can do to simplify this any further. However, my interpretter merrily > goes into an endless loop building a huge expression like "f (g (f (g (f > (g..." Is it possible to avoid this? If you want to avoid infinite normal forms (or just plain lack of normal forms, as in let x = x in x or (\x -> x x) (\ x -> x x)), you need to follow three rules: 1) Static typing 2) No value recursion 3) If you allow data types, no recursive data types Otherwise, your language will be Turing-complete, so yes, trying to determine ahead of time if even a HNF exists will be the halting problem. If you really want to write a general-purpose evaluator, then infinite normal forms may not be an issue, as long as they are generated lazily, so your evaluator can at least print something out while it goes into an infinite loop. Otherwise, you can declare f x, where f is an unknown function, a HNF, and stop at that point, or go on only under the client's control. The optimizers used by GHC and YHC pick one function out of each recursive binding group, and just refuse to inline it at all. If you don't mind producing expressions that aren't really in any definable HNF, that would be an alternative as well. jcc From conor at strictlypositive.org Fri Aug 29 16:48:03 2008 From: conor at strictlypositive.org (Conor McBride) Date: Fri Aug 29 16:46:40 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <1220040768.908.67.camel@jcchost> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <1220040768.908.67.camel@jcchost> Message-ID: <57B581CE-D96F-4321-B804-83B3D349D8BA@strictlypositive.org> Hi On 29 Aug 2008, at 21:12, Jonathan Cast wrote: > > If you want to avoid infinite normal forms (or just plain lack of > normal > forms, as in let x = x in x or (\x -> x x) (\ x -> x x)), you need to > follow three rules: > > 1) Static typing With you there. > 2) No value recursion Mostly with you: might allow productive corecursion computing only on demand. > 3) If you allow data types, no recursive data types I can think of a few Turing incomplete languages with (co)recursive data types, so > Otherwise, your language will be Turing-complete, seems suspect to me. It's quite possible to identify a total fragment of Haskell, eg, by seeing which of your Haskell programs compile in Agda. Things aren't as hopeless as you suggest. Cheers Conor From jonathanccast at fastmail.fm Fri Aug 29 16:49:59 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Aug 29 16:52:13 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <57B581CE-D96F-4321-B804-83B3D349D8BA@strictlypositive.org> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <1220040768.908.67.camel@jcchost> <57B581CE-D96F-4321-B804-83B3D349D8BA@strictlypositive.org> Message-ID: <1220042999.908.72.camel@jcchost> On Fri, 2008-08-29 at 21:48 +0100, Conor McBride wrote: > Hi > > On 29 Aug 2008, at 21:12, Jonathan Cast wrote: > > > > > If you want to avoid infinite normal forms (or just plain lack of > > normal > > forms, as in let x = x in x or (\x -> x x) (\ x -> x x)), you need to > > follow three rules: > > > > 1) Static typing > > With you there. > > > 2) No value recursion > > Mostly with you: might allow productive corecursion > computing only on demand. > > > 3) If you allow data types, no recursive data types > > I can think of a few Turing incomplete languages with > (co)recursive data types, so > > Otherwise, your language will be Turing-complete, > > seems suspect to me. OK. If you have any of 1) Dynamic typing, as implemented in say Scheme, or 2) Unlimited recursion, as implemented in say Haskell, or 3) Unlimited recursive data types, as implemented in say Haskell your language is Turing-complete. > It's quite possible to identify a total fragment of > Haskell, eg, by seeing which of your Haskell programs > compile in Agda. > Things aren't as hopeless as you suggest. OK. There are intermediate cases that involve some suitably restricted form of recursion. I don't actually know anything about them, so I won't comment on the suitability of such restrictions for Andrew's interpreter. But I should have remembered their existence. jcc From roma at ro-che.info Fri Aug 29 16:59:54 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri Aug 29 16:58:27 2008 Subject: [Haskell-cafe] Named field syntax In-Reply-To: <48B7FC03.1060502@imn.htwk-leipzig.de> References: <48B7FC03.1060502@imn.htwk-leipzig.de> Message-ID: <20080829205954.GA6102@flit> * Johannes Waldmann [2008-08-29 15:39:15+0200] > > data Test = Test Integer {b::String} > > positional (= unnamed) record notation is a language design error :-) > and its use should be discouraged. - J.W. Polluting namespace with unneeded functions should not be encouraged either. Consider for instance defining datatype for 3x3 matrix. Would the absence of unnamed record notation make you more happy? -- Roman I. Cheplyaka :: http://ro-che.info/ kzm: My program contains a bug. How ungrateful, after all I've done for it. From donn at avvanta.com Fri Aug 29 18:18:05 2008 From: donn at avvanta.com (Donn Cave) Date: Fri Aug 29 18:16:32 2008 Subject: [Haskell-cafe] Parsec and network data References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> <48B8395D.1080605@imn.htwk-leipzig.de> Message-ID: <20080829221805.7669F276CBF@mail.avvanta.com> Quoth Johannes Waldmann : ... | I think the following is analoguous. | | Imagine you're writing a parser for a simple programming language. | A program is a sequence of statements. | Fine, you do "readFile" (once) and then apply a pure Parsec parser. | | Then you decide to include "import" statements in your language. | Suddenly the parser needs to do IO. Assume the import statements | need not be the first statements of the program | (there may be headers, comments etc. before). | Then you really have to interweave the parsing and the IO. I think "readFile" might be where the analogy fails. In a network client like we were talking about, it's understood that you have to interweave the parsing and I/O, to some extent. From this point of view, I don't see a problem with this programming language parser, in fact I suppose I might indeed do it that way - maybe map the file to a ByteString or something, would have to think about it. Donn Cave, donn@avvanta.com From donn at avvanta.com Fri Aug 29 18:49:09 2008 From: donn at avvanta.com (Donn Cave) Date: Fri Aug 29 18:47:55 2008 Subject: [Haskell-cafe] Parsec and network data References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> <22f6a8f70808291134g67e7a08dh92fc71a9df8d4208@mail.gmail.com> Message-ID: <20080829224909.762BC93C50@mail.avvanta.com> Quoth brian : | On Fri, Aug 29, 2008 at 11:15 AM, Donn Cave wrote: |> Quoth brian : |> |> | I want to use Parsec to parse NNTP data coming to me from a handle I |> | get from connectTo. |> |> I would implement the network service |> input data stream myself, with timeouts | | Could you explain a little about how this would look? | | If it's reading characters trying to make a String we want to call a | 'line', isn't that what the parser is supposed to be doing? If you | were parsing /etc/passwd, would you read each line yourself and give | each one to Parsec? You bet, given that passwd is a simple line record file and I'm reasonably confident that hGetLine will do what I want for a disk file (or more or less so, anyway, since while I don't want end of file to raise an exception, I'm aware of work-arounds for this.) On the other hand, for the very same reason, I wouldn't worry too much about letting a parse function read the data -- from a disk file. With a network client, though, the value of those buffered I/O routines isn't so obvious to me. While it can be a convenient metaphor in some common circumstances, a socket is not a file and the notion easily becomes more trouble than it's worth. I wouldn't read byte-by-byte, but rather read available data into my own buffer. Donn Cave, donn@avvanta.com From ganesh at earth.li Fri Aug 29 18:52:37 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Fri Aug 29 18:51:02 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B72513.7010700@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> Message-ID: On Thu, 28 Aug 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> On Thu, 28 Aug 2008, Adrian Hey wrote: >> >>> There's no semantic difficulty with the proposed language extension, >> >> How does it behave in the presence of dynamic loading? > > To answer this you need to be precise about the semantics of what > is being dynamically loaded. But this is too complex an issue > for me to get in to right now. If you want to standardise a language feature, you have to explain its behaviour properly. This is one part of the necessary explanation. To be concrete about scenarios I was considering, what happens if: - the same process loads two copies of the GHC RTS as part of two completely independent libraries? For added complications, imagine that one of the libraries uses a different implementation instead (e.g. Hugs) - one Haskell program loads several different plugins in a way that allows Haskell values to pass across the plugin boundary How do these scenarios work with use cases for <- like (a) Data.Unique and (b) preventing multiple instantiation of a sub-library? > Actually as far as things like hs-plugins are concerned I'd alway meant > one day what exactly a "plugin" is, semantically. But as I've never had > cause to use them so never got round to it. Like is it a value, or does > it have state and identity or what? Personally I think of them as values. I'm not sure what your questions about state and identity mean. If you don't have global variables, then state doesn't matter. >> What about remote procedure calls? > > Dunno, what problem do you anticipate? Will Data.Unique still work properly if a value is sent across a RPC interface? >> Also what if I want a thread-local variable? > > Well actually I would say that threads are bad concurrency model so > I'm not keen on thread local state at all. Mainly because I'd like to > get rid of threads, but also a few other doubts even if we keep > threads. Even if you don't like them, people still use them. > (I.E. Just making existing practice *safe*, at least in the sense that > the compiler ain't gonna fcuk it up with INLINING or CSE and every one > understands what is and isn't safe in ACIO) Creating new language features means defining their semantics rather more clearly than just "no inlining or cse", IMO. Ganesh From westondan at imageworks.com Fri Aug 29 19:33:50 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Aug 29 19:32:19 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> Message-ID: <48B8875E.5080406@imageworks.com> C++ faced this very issue by saying that with global data, uniqueness of initialization is guaranteed but order of evaluation is not. Assuming that the global data are merely thunk wrappers over some common data source, this means that at minimum, there can be no data dependencies between plugins where the order of evaluation matters. Another C++ comparison is with a virtual base class, where A::B::D and A::C::D are supposed to be equal, irrespective of whether it was B or C that first called the constructor. In this case, some witness (a vtable) is necessary to ensure that this happens correctly. Dan Ganesh Sittampalam wrote: > On Thu, 28 Aug 2008, Adrian Hey wrote: > >> Ganesh Sittampalam wrote: >>> On Thu, 28 Aug 2008, Adrian Hey wrote: >>> >>>> There's no semantic difficulty with the proposed language extension, >>> >>> How does it behave in the presence of dynamic loading? >> >> To answer this you need to be precise about the semantics of what >> is being dynamically loaded. But this is too complex an issue >> for me to get in to right now. > > If you want to standardise a language feature, you have to explain its > behaviour properly. This is one part of the necessary explanation. > > To be concrete about scenarios I was considering, what happens if: > > - the same process loads two copies of the GHC RTS as part of two > completely independent libraries? For added complications, imagine that > one of the libraries uses a different implementation instead (e.g. Hugs) > > - one Haskell program loads several different plugins in a way that > allows Haskell values to pass across the plugin boundary > > How do these scenarios work with use cases for <- like (a) Data.Unique > and (b) preventing multiple instantiation of a sub-library? > >> Actually as far as things like hs-plugins are concerned I'd alway >> meant one day what exactly a "plugin" is, semantically. But as I've >> never had cause to use them so never got round to it. Like is it a >> value, or does it have state and identity or what? > > Personally I think of them as values. I'm not sure what your questions > about state and identity mean. If you don't have global variables, then > state doesn't matter. > >>> What about remote procedure calls? >> >> Dunno, what problem do you anticipate? > > Will Data.Unique still work properly if a value is sent across a RPC > interface? > >>> Also what if I want a thread-local variable? >> >> Well actually I would say that threads are bad concurrency model so >> I'm not keen on thread local state at all. Mainly because I'd like to >> get rid of threads, but also a few other doubts even if we keep >> threads. > > Even if you don't like them, people still use them. > >> (I.E. Just making existing practice *safe*, at least in the sense that >> the compiler ain't gonna fcuk it up with INLINING or CSE and every one >> understands what is and isn't safe in ACIO) > > Creating new language features means defining their semantics rather > more clearly than just "no inlining or cse", IMO. > > Ganesh > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From bos at serpentine.com Fri Aug 29 19:44:38 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Aug 29 19:43:02 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B8875E.5080406@imageworks.com> References: <534781822.20080826190130@gmail.com> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> Message-ID: On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston wrote: > C++ faced this very issue by saying that with global data, uniqueness of > initialization is guaranteed but order of evaluation is not. In C++ circles, this is referred to as the "static initialization order fiasco", and it is a frequent cause of crashes that are very difficult to debug. http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 I think it would be fair to say that C++ pushed this problem off to every user of the language. I haven't seen a coherent description of what the semantics of top-level "<-" should be, but avoidance of widespread swearing would be at the top of my list of requirements. From westondan at imageworks.com Fri Aug 29 19:59:41 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Aug 29 19:58:10 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> Message-ID: <48B88D6D.2010109@imageworks.com> I actually was more interested in the problems with the "obvious fix" for this, namely the "construct on first use" idiom: int A(int a) { static int aa = a; return aa; } int B() { return A(3); } int C() { return A(7); } int D() { if (today() == "Tuesday") B(); else C(); return a(0); } What is the value of D? Notice that this is never a problem with pure functions. The problem is that today() makes this an IO monad, and the swearing starts again. Dan Bryan O'Sullivan wrote: > On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston wrote: >> C++ faced this very issue by saying that with global data, uniqueness of >> initialization is guaranteed but order of evaluation is not. > > In C++ circles, this is referred to as the "static initialization > order fiasco", and it is a frequent cause of crashes that are very > difficult to debug. > > http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 > > I think it would be fair to say that C++ pushed this problem off to > every user of the language. I haven't seen a coherent description of > what the semantics of top-level "<-" should be, but avoidance of > widespread swearing would be at the top of my list of requirements. > > From ahey at iee.org Fri Aug 29 21:28:25 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Aug 29 21:26:55 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> Message-ID: <48B8A239.4030904@iee.org> Ganesh Sittampalam wrote: > Will Data.Unique still work properly if a value is sent across a RPC > interface? A value of type Unique you mean? This isn't possible. Data.Unique has been designed so cannot be Shown/Read or otherwise serialised/deserialised (for obvious reasons I guess). >>> Also what if I want a thread-local variable? >> >> Well actually I would say that threads are bad concurrency model so >> I'm not keen on thread local state at all. Mainly because I'd like to >> get rid of threads, but also a few other doubts even if we keep >> threads. > > Even if you don't like them, people still use them. AFAICS this is irrelvant for the present discussions as Haskell doesn't support thread local variable thingies. If it ever does being precise about that is someone elses problem. For the time being the scope of IORefs/MVars/Chans is (and should remain) whatever process is described by main (whether or not they appear at top level). >> (I.E. Just making existing practice *safe*, at least in the sense that >> the compiler ain't gonna fcuk it up with INLINING or CSE and every one >> understands what is and isn't safe in ACIO) > > Creating new language features means defining their semantics rather > more clearly than just "no inlining or cse", IMO. I wouldn't even know how to go about that to the satisfaction of purists. But "global variables" *are* being used whether or not the top level <- bindings are implemented. They're in the standard libraries! So if this stuff matters someone had better figure it out :-) Regards -- Adrian Hey From ahey at iee.org Fri Aug 29 21:53:18 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Aug 29 21:51:47 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8875E.5080406@imageworks.com> Message-ID: <48B8A80E.4040907@iee.org> Bryan O'Sullivan wrote: > I haven't seen a coherent description of > what the semantics of top-level "<-" should be, but avoidance of > widespread swearing would be at the top of my list of requirements. Don't the ACIO monad properties satisfy you? Anyway, as I pointed out in my last post, if this is a problem with top level <- ACIO monad bindings it's still going to be a problem (probably much worse) with unsafePerformIO hack IO monad bindings. This problem isn't just going to go away, no matter how long it's ignored :-) Regards -- Adrian Hey From marco-oweber at gmx.de Fri Aug 29 21:58:46 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Aug 29 21:57:12 2008 Subject: [Haskell-cafe] ANN: vxml (validating xml lib) - proof of concept - need some guidance - bad type level performance (ghc) Message-ID: <20080830015846.GB7458@gmx.de> Hi @ll. This shouldn't have been an announce yet.. it's more crying for help to get to know how / wether to continue :-) I had an idea: a xml generating library validating the result against a given dtd (to be used in web frameworks etc .. ) After one week of coding I got the result git clone git://mawercer.de/vxml (1) (see README) git hash as of writing : 4dc53 A minimal example looks like this (taken from test.hs): import Text.XML.Validated.TH $( dtdToTypes "dtds/xhtml1-20020801/DTD/xhtml1-strict_onefile.dtd" (XmlIds (Just "-//W3C//DTD XHTML 1.0 Strict//EN") (Just "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd") ) ) main = putStrLn $ xml $ ((html << (head << (title <<< "vxml hello world"))) << (body << (div <<< "PCDATA text" )) ) Which takes about 7 secs to compile on my (fast) 2.5 Ghz machine. Before Oleg telling me about how to use the TypeEq implementation found in HList it took several hours (switch the cabal configure flag to see experience the incredible slow TypeToNat implementation) However type checking the simple small document (2) already takes 35 seconds, duplicating the tags within the body raises compilation time to 74 seconds. (Have a look at test/XmlToQ.hs to automatically create the code generating such a given xml file (its used in run-testcases.hs) The dtd representation used is very easy to understand: (3a) shows allowed subelements of the head tag Seq = sequence Star = zero or more ... (3b) shows the list of allowed attributes for a more commonly used tag such as div the element list (3a) is 324 lines long and there are approximately 15 attributes. Use a line such as putStrLn $ xml $ debugEl div to get this view. All the work is done by class Consume st el r | st el -> r -- result is on of C,CS,R,F class Retry elType st el st' | st el -> st' st = state as given in (3a) el = child to be added (Elem Html_T) or PCDATA C = element consumed, end CS a = element consumed, continue with state a R a = retry with given state (can happen after removing a Star = ()* on a no match ) F a = no match, show failure a instance Retry elType C el C instance Retry elType (CS st) el st instance ( -- retry Consume st el r , Retry elType r el st' ) => Retry elType (R st) el st' Maybe you knowing much more about ghc internals have some more ideas how to optimize? I only came up with a) implement xml HTrue $ xmldoc -- type checking variant xml HFalse $ xmldoc -- unchecked but faster variant so you can run xml HTrue once a day only while having lunch.. ( doubt Maybe you have to take lunch two or more times on intermediate web projects .. ) b) change (A attrType) to attrType only and (Elem e) to e which does not work for the same reason as class TypeEq a b c | a b -> c instance TypeEq a a HTrue instance TypeEq a b HFalse doesn't. Of course a a will match a b as well, but the result is totally different.. So would it be possible to either tell ghc to ignore this happily taking the result of the better matching instance? Or to explicitely tell ghc when an instance matches the way it does in current implementations make it a no match if some constraints can or cannot be satisfied such as this: class TypeEq a b c | a b -> c instance TypeEq a a HTrue instance [ NoMatchOn a b -- if this can be satisfied ignore this instance ] => TypeEq a b HFalse class NoMatchOn a b instance NoMatchOn a a c) Having a reduction rule such as this: If the left side of (Or a b) returnns C (consumed) tell ghc to not evaluate the result of (Consume b element result) which must be done to see wether there is closer instance match (Is this correct ?) Of course not everything is implemented yet.. but except speed I consider it beeing quite usable. He, thanks for reading till the end. Any feedback and suggestions are appreciated. If you have any trouble contact me on irc. I've been using $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Sincerly Marc Weber (1) If you are interested and either don't have git or are not familiar using it I can send you a tarball. (2) Example 6 - XHTML 1.0 Strict as application/xhtml+xml

Example 6 - XHTML 1.0 Strict as application/xhtml+xml

This document is valid XHTML 1.0 Strict served as application/xhtml+xml.

This document references CSS rules contained in an external stylesheet via link.

Note how the CSS rules for the background are applied in Netscape 7.x, Mozilla, Opera 7 but that Internet Explorer can not display the page at all.

Valid XHTML 1.0!

(3a) (Seq (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))) (Or (Seq (Elem Title_T) (Seq (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))) (Query (Seq (Elem Base_T) (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))))))) (Seq (Elem Base_T) (Seq (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))) (Seq (Elem Title_T) (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T))))))))))) (3b) (HCons (A Lang_A) (HCons (A Xml:lang_A) (HCons (A Dir_A) (HCons (A Id_A) (HCons (A Profile_A) HNil))))) From briqueabraque at yahoo.com Fri Aug 29 22:28:36 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Fri Aug 29 22:27:17 2008 Subject: [Haskell-cafe] Re: Syntax of 'do' In-Reply-To: References: Message-ID: >> It sounds like you tried to redefine (>>) and >> (>>=) and make 'do' use the new definitions. >> This is not possible, regardless of what types >> you give (>>) and (>>=). > > Watch out for rebindable syntax: (...) > > At first reading, I thought that > -XNoImplicitPrelude was required to turn this > on. But now I'm not sure: (...) I wrote this test to check your sugestion. It does build with -XNoImplicitPrelude, but not without it: ---------- module Test where { import Prelude hiding ( ( >> ) , ( >>= ) ) ; data PseudoMonad a = PseudoMonad a ; ( >> ) = \(PseudoMonad x) (PseudoMonad _) -> PseudoMonad x ; ( >>= ) = (\(PseudoMonad a) f -> f a) :: PseudoMonad Integer -> (Integer -> PseudoMonad Integer) -> PseudoMonad Integer; plusOne n = (PseudoMonad (n + 1)) :: PseudoMonad Integer; c = (PseudoMonad 1) >> ((PseudoMonad 2) >>= (\n -> plusOne n)); d = do {(PseudoMonad 1) ; a <- (PseudoMonad 2) ; plusOne a } } ---------- It's interesting that the types involved in >>= etc. should still be like "t t1", that's why I had to create PseudoMonad. Using just Integer (i.e., 2 >> 3 would be valid) doesn't work, even if all operators are defined accordingly. Best, Maur?cio From philip.weaver at gmail.com Fri Aug 29 23:22:23 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Aug 29 23:20:47 2008 Subject: [Haskell-cafe] Syntax of 'do' In-Reply-To: References: Message-ID: On Fri, Aug 29, 2008 at 8:50 AM, David House wrote: > 2008/8/29 Philip Weaver : > > It sounds like you tried to redefine (>>) and (>>=) and make 'do' use the > > new definitions. This is not possible, regardless of what types you give > > (>>) and (>>=). > > Watch out for rebindable syntax: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax > Oh, I had no idea! Thanks :). > > At first reading, I thought that -XNoImplicitPrelude was required to > turn this on. But now I'm not sure: it seems that if you hide > Prelude.>>= and Prelude.return, that ought to be enough to make do > notation work with your alternative definitions. I'm not at home, so I > can't try this right now. > > -- > -David > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080829/e8455db4/attachment.htm From philip.weaver at gmail.com Fri Aug 29 23:33:06 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Aug 29 23:31:30 2008 Subject: [Haskell-cafe] Named field syntax In-Reply-To: <20080829205954.GA6102@flit> References: <48B7FC03.1060502@imn.htwk-leipzig.de> <20080829205954.GA6102@flit> Message-ID: On Fri, Aug 29, 2008 at 1:59 PM, Roman Cheplyaka wrote: > * Johannes Waldmann [2008-08-29 > 15:39:15+0200] > > > data Test = Test Integer {b::String} > > > > positional (= unnamed) record notation is a language design error :-) > > and its use should be discouraged. - J.W. > > Polluting namespace with unneeded functions should not be encouraged > either. Consider for instance defining datatype for 3x3 matrix. > Would the absence of unnamed record notation make you more happy? > Also, if positional record notation is a design error, then is it also a design error not to require all arguments to be explicitly associated with named formal parameters at a function call site (e.g. f(x = 1, y = 2, z = 3))? > > -- > Roman I. Cheplyaka :: http://ro-che.info/ > kzm: My program contains a bug. How ungrateful, after all I've done for it. > _______________________________________________ > 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/20080829/9b47f9e2/attachment.htm From wren at freegeek.org Sat Aug 30 00:48:22 2008 From: wren at freegeek.org (wren ng thornton) Date: Sat Aug 30 00:46:49 2008 Subject: [Haskell-cafe] ANN: LogFloat 0.9 Message-ID: <48B8D116.9050205@freegeek.org> -------------------------------------------- -- Announcing: logfloat 0.9.1 -------------------------------------------- New official release of the logfloat package for manipulating log-domain floating numbers. This release is mainly for those who are playing with Transfinite rather than LogFloat, but the interface changes warrant a minor version change. If you're just using the LogFloat stuff you shouldn't notice any changes except that the constructors/destructors may be a bit pickier about being used when a polymorphic return type is expected. -------------------------------------------- -- Changes -------------------------------------------- * John Meacham pointed out that the Num and Ord superclasses on Transfinite may be onerous due to the growing disaffection with the Prelude. The Num requirement has been lifted, and the Ord requirement has been weakened to the new PartialOrd class. * Introduced a new class for partially ordered types: PartialOrd. * The transfinite-value respecting logarithm has been moved from Data.Number.LogFloat to Data.Number.Transfinite because it's more appropriate there. (It's still reexported by Data.Number.LogFloat.) * In the continuing battle between transfinite values and Rationals, I've added a new class RealToFrac for overloading the Prelude's realToFrac function. On GHC, primitive converters are used to improve both performance and correctness. For non-GHC compilers, only a few generic instances are given. For an older discussion on this topic, see: http://www.haskell.org/pipermail/haskell-prime/2006-February/000791.html * Due to all this development on trying to solve the issues of transfinite values, the "stability" of the package has been changed from stable to provisional. -------------------------------------------- -- Future Extensions -------------------------------------------- * A strict version. The current lazy version will move to Data.Number.LogFloat.Lazy, and the strict version will be the standard one in Data.Number.LogFloat * A signed version in Data.Number.LogFloat.Signed * A test suite -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ -- Live well, ~wren From dons at galois.com Sat Aug 30 01:55:38 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 30 01:54:19 2008 Subject: [Haskell-cafe] ANN: LogFloat 0.9 In-Reply-To: <48B8D116.9050205@freegeek.org> References: <48B8D116.9050205@freegeek.org> Message-ID: <20080830055538.GA20006@scytale.galois.com> wren: > -------------------------------------------- > -- Announcing: logfloat 0.9.1 > -------------------------------------------- > > New official release of the logfloat package for manipulating log-domain > floating numbers. This release is mainly for those who are playing with > Transfinite rather than LogFloat, but the interface changes warrant a > minor version change. And in Arch Linux http://aur.archlinux.org/packages.php?ID=18832 -- Don (come on packagers!) From apfelmus at quantentunnel.de Sat Aug 30 03:48:37 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sat Aug 30 03:47:11 2008 Subject: [Haskell-cafe] Re: Parsec and network data In-Reply-To: <48B8395D.1080605@imn.htwk-leipzig.de> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> <48B8395D.1080605@imn.htwk-leipzig.de> Message-ID: Johannes Waldmann wrote: > Imagine you're writing a parser for a simple programming language. > A program is a sequence of statements. > Fine, you do "readFile" (once) and then apply a pure Parsec parser. > > Then you decide to include "import" statements in your language. > Suddenly the parser needs to do IO. Assume the import statements > need not be the first statements of the program > (there may be headers, comments etc. before). > Then you really have to interweave the parsing and the IO. > > If anyone has a nice solution to this, please tell. - J.W. Design your language in a way that the *parse* tree does not depend on import statements? I.e. Chasing imports is performed after you've got an abstract syntax tree. Regards, apfelmus From wnoise at ofb.net Sat Aug 30 04:06:33 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sat Aug 30 04:05:07 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- References: <534781822.20080826190130@gmail.com> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> Message-ID: On 2008-08-28, Yitzchak Gale wrote: > However we work that out, right now we need a working > idiom to get out of trouble when this situation comes up. > What we have is a hack that is not guaranteed to work. > We are abusing the NOINLINE pragma and assuming > things about it that are not part of its intended use. > We are lucky that it happens to work right now in GHC. > > So my proposal is that, right now, we make the simple > temporary fix of adding an ONLYONCE pragma that does > have the proper guaranteed sematics. > > In the meantime, we can keep tackling the awkward squad. What keeps this a "temporary fix". Even now, industrial user demands keep us from making radical changes to the languages and libraries. If we adopt a not entirely satisfactory solution, it's never going away. If we keep the NOINLINE pragma hack, we can claim it was never supported and do away with it. If we don't have a real solution, perhaps in this case we haven't worn the hair shirt long enough? -- Aaron Denney -><- From wnoise at ofb.net Sat Aug 30 04:21:02 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sat Aug 30 04:19:39 2008 Subject: [Haskell-cafe] Re: 2 modules in one file References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> Message-ID: On 2008-08-27, Yitzchak Gale wrote: [hierarchical modules mapped to filesystem paths] > In my opinion, that is a bad policy. It is fine as a simple default for > small projects, even though it's a bit ugly and ad hoc. (For example - > what does this mean on platforms whose filesystem is not > hierarchical?) The language standards are always going to require something from the platforms we develop on (which is different N.B. than the ones we deploy to). I have no trouble counting real filesystems among them. > But for large and complex projects, this policy really complicates > the task of the project manager who wants to be able to > present various views of the source to teams working on > different subprojects, while juggling the version control > in an intelligent way. Directory tree structure is sometimes > the perfect tool for that, but Haskell has stolen it away. This is a valid point, but I personally get extremely frustrated at remapping in source code repositories, precisely because allowing different views means people can say "builds for me" without any guarantee of anything useful for anyone else. > It would be nice if compilers would offer, as an optional alternative, > a system of locating modules based on manifest files. > That would then allow multiple modules per source file. And simplify supporting recursive modules... -- Aaron Denney -><- From wnoise at ofb.net Sat Aug 30 04:22:09 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sat Aug 30 04:23:28 2008 Subject: [Haskell-cafe] Re: 2 modules in one file References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> <48B575DF.8000300@cs.nott.ac.uk> Message-ID: On 2008-08-27, Henrik Nilsson wrote: > And there are also potential issues with not every legal module name > being a legal file name across all possible file systems. I find this unconvincing. Broken file systems need to be fixed. -- Aaron Denney -><- From ganesh at earth.li Sat Aug 30 05:37:26 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 05:35:49 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B8A239.4030904@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> Message-ID: On Sat, 30 Aug 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> Will Data.Unique still work properly if a value is sent across a RPC >> interface? > > A value of type Unique you mean? This isn't possible. Data.Unique has > been designed so cannot be Shown/Read or otherwise > serialised/deserialised (for obvious reasons I guess). How do the implementers of Data.Unique know that they musn't let them be serialised/deserialised? What stops the same rule from applying to Data.Random? >>>> Also what if I want a thread-local variable? >>> >>> Well actually I would say that threads are bad concurrency model so >>> I'm not keen on thread local state at all. Mainly because I'd like to >>> get rid of threads, but also a few other doubts even if we keep >>> threads. >> >> Even if you don't like them, people still use them. > > AFAICS this is irrelvant for the present discussions as Haskell doesn't > support thread local variable thingies. If it ever does being precise > about that is someone elses problem. The fact that your proposal isn't general enough to handle them is a mark against it; standardised language features should be widely applicable, and as orthogonal as possible to other considerations. > For the time being the scope of IORefs/MVars/Chans is (and should > remain) whatever process is described by main (whether or not they > appear at top level). And if main isn't the entry point? This comes back to my questions about dynamic loading. >>> (I.E. Just making existing practice *safe*, at least in the sense that >>> the compiler ain't gonna fcuk it up with INLINING or CSE and every one >>> understands what is and isn't safe in ACIO) >> >> Creating new language features means defining their semantics rather more >> clearly than just "no inlining or cse", IMO. > > I wouldn't even know how to go about that to the satisfaction of > purists. But "global variables" *are* being used whether or not the top > level <- bindings are implemented. They're in the standard libraries! > > So if this stuff matters someone had better figure it out :-) It's a hack that isn't robust in many situations. We should find better ways to do it, not standardise it. Cheers, Ganesh From ahey at iee.org Sat Aug 30 06:28:14 2008 From: ahey at iee.org (Adrian Hey) Date: Sat Aug 30 06:26:44 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> Message-ID: <48B920BE.30507@iee.org> Ganesh Sittampalam wrote: > How do the implementers of Data.Unique know that they musn't let them be > serialised/deserialised? Because if you could take a String and convert it to a Unique there would be no guarantee that result was *unique*. > What stops the same rule from applying to Data.Random? Well the only data type defined by this is StdGen, which is a Read/Show instance. I guess there's no semantic problem with that (can't think of one off hand myself). >>>>> Also what if I want a thread-local variable? >>>> >>>> Well actually I would say that threads are bad concurrency model so >>>> I'm not keen on thread local state at all. Mainly because I'd like to >>>> get rid of threads, but also a few other doubts even if we keep >>>> threads. >>> >>> Even if you don't like them, people still use them. >> >> AFAICS this is irrelvant for the present discussions as Haskell doesn't >> support thread local variable thingies. If it ever does being precise >> about that is someone elses problem. > > The fact that your proposal isn't general enough to handle them is a > mark against it; standardised language features should be widely > applicable, and as orthogonal as possible to other considerations. I think the whole thread local state thing is a complete red herring. I've never seen a convincing use case for it and I suspect the only reason these to issues have become linked is that some folk are so convinced that "global variables are evil", they mistakenly think thread local variables must be less evil (because they are "less global"). Anyway, if you understand the reasons why all the real world libraries that do currently use "global variables" do this, it's not hard to see why they don't want this to be thread local (it would break all the safety properties they're trying to ensure). So whatever problem thread local variables might solve, it isn't this one. >> For the time being the scope of IORefs/MVars/Chans is (and should >> remain) whatever process is described by main (whether or not they >> appear at top level). > > And if main isn't the entry point? This comes back to my questions about > dynamic loading. Well you're talking about some non-standard Haskell, so with this and other non standard stuff (like plugins etc) I guess the answer is it's up to whoever's doing this to make sure they do it right. I can't comment further as I don't know what it is they're trying to do, but AFAICS it's not a language design issue at present. If plugins breaks is down to plugins to fix itself, at least until such time as a suitable formal theory of plugins has been developed so it can become standard Haskell :-) >>>> (I.E. Just making existing practice *safe*, at least in the sense >>>> that the compiler ain't gonna fcuk it up with INLINING or CSE and >>>> every one understands what is and isn't safe in ACIO) >>> >>> Creating new language features means defining their semantics rather >>> more clearly than just "no inlining or cse", IMO. >> >> I wouldn't even know how to go about that to the satisfaction of >> purists. But "global variables" *are* being used whether or not the top >> level <- bindings are implemented. They're in the standard libraries! >> >> So if this stuff matters someone had better figure it out :-) > > It's a hack that isn't robust in many situations. We should find better > ways to do it, not standardise it. Nobody's talking about standardising the current hack. This the whole point of the top level <- proposal, which JM seems to think is sound enough for incorporation into JHC (correctly IMO). Nobody's found fault with it, other than the usual global variables are evil mantra :-) Regards -- Adrian Hey From nominolo at googlemail.com Sat Aug 30 06:51:38 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Aug 30 06:50:04 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> Message-ID: <916b84820808300351m37f1e659gc194d1e3735fa66e@mail.gmail.com> There's a whole bunch of other problems with lazy network IO. The big problem is that you cannot detect when your stream ends since that will happen inside unsafeInterleaveIO which is invisible from inside pure code. You also have no guarantee that the lazy code actually consumes code enough. Finalisers don't help, either, since there is in fact no guarantee they are actually run, never mind on time. The proposed solution by Oleg & co. is to use enumerations/left folds [1]. The basic idea is to use a callback which gets handed a chunk of the input from the network. When the last chunk is handed-out the connection is closed automatically. Using continuations, you can turn this into a stream again [2] which is needed for many input processing tasks, like parsing. I remember Johan Tibell (CC'd) working on an extended variant of Parsec that can deal with this chunked processing. The idea is to teach Parsec about a partial input and have it return a function to process the rest (a continuation) if it encounters the end of a chunk (but not the end of a file). Maybe Johan can tell you more about this, or point you to his implementation. [1]: http://okmij.org/ftp/papers/LL3-collections-enumerators.txt [2]: http://okmij.org/ftp/Haskell/fold-stream.lhs / Thomas On Tue, Aug 26, 2008 at 10:35 PM, brian wrote: > Hi, I've been struggling with this problem for days and I'm dying. Please help. > > I want to use Parsec to parse NNTP data coming to me from a handle I > get from connectTo. > > One unworkable approach I tried is to get a lazy String from the > handle with hGetContents. The problem: suppose the first message from > the NNTP server is "200 OK\r\n". Parsec parses it beautifully. Now I > need to discard the parsed part so that Parsec will parse whatever the > server sends next, so I use Parsec's getInput to get the remaining > data. But there isn't any, so it blocks. Deadlock: the client is > inappropriately waiting for server data and the server is waiting for > my first command. > > Another approach that doesn't quite work is to create an instance of > Parsec's Stream with timeout functionality: > > instance Stream Handle IO Char where > uncons h = > do r <- hWaitForInput h ms > if r > then liftM (\c -> Just (c, h)) (hGetChar h) > else return Nothing > where ms = 5000 > > It's probably obvious to you why it doesn't work, but it wasn't to me > at first. The problem: suppose you tell parsec you're looking for > (many digit) followed by (string "\r\n"). "123\r\n" won't match; > "123\n" will. My Stream has no backtracking. Even if you don't need > 'try', it won't work for even basic stuff. > > Here's another way: > http://www.mail-archive.com/haskell-cafe@haskell.org/msg22385.html > The OP had the same problem I did, so he made a variant of > hGetContents with timeout support. The problem: he used something from > unsafe*. I came to Haskell for rigor and reliability and it would make > me really sad to have to use a function with 'unsafe' in its name that > has a lot of wacky caveats about inlining, etc. > > In that same thread, Bulat says a timeout-enabled Stream could help. > But I can't tell what library that is. 'cabal list stream' shows me 3 > libraries none of which seems to be the one in question. Is Streams a > going concern? Should I be checking that out? > > I'm not doing anything with hGetLine because 1) there's no way to > specify a maximum number of characters to read 2) what is meant by a > "line" is not specified 3) there is no way to tell if it read a line > or just got to the end of the data. Even using something like hGetLine > that worked better would make the parsing more obscure. > > Thank you very very much for *any* help. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ashley at semantic.org Sat Aug 30 07:05:22 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 07:03:47 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> Message-ID: <48B92972.8000700@semantic.org> Ganesh Sittampalam wrote: > If you want to standardise a language feature, you have to explain its > behaviour properly. This is one part of the necessary explanation. > > To be concrete about scenarios I was considering, what happens if: > > - the same process loads two copies of the GHC RTS as part of two > completely independent libraries? For added complications, imagine that > one of the libraries uses a different implementation instead (e.g. Hugs) > > - one Haskell program loads several different plugins in a way that > allows Haskell values to pass across the plugin boundary > > How do these scenarios work with use cases for <- like (a) Data.Unique > and (b) preventing multiple instantiation of a sub-library? That's a good question. But before you propose these scenarios, you must establish that they are sane for Haskell as it is today. In particular, would _local_ IORefs work correctly? After all, the memory allocator must be "global" in some sense. Could you be sure that different calls to newIORef returned separate IORefs? Perhaps this is the One True Global Scope: the scope in which refs from newIORef are guaranteed to be separate. It's the scope in which values from newUnique are supposed to be different, and it would also be the scope in which top-level <- would be called at most once. -- Ashley Yakeley From ashley at semantic.org Sat Aug 30 07:09:48 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 07:08:11 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <1219964343.6198.2.camel@flippa-eee> References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <2608b8a80808281506u730fd14et2776e36e129c3ebf@mail.gmail.com> <1219964343.6198.2.camel@flippa-eee> Message-ID: <48B92A7C.6060106@semantic.org> Philippa Cowderoy wrote: > Talking of which, we really ought to look at an IO typeclass or two (not > just our existing MonadIO) and rework the library ops to use it in > Haskell'. You're not the only one to want it, and if it's not fixed this > time it may never get fixed. This could allow both the best of both worlds, as we could have a monad that one couldn't create global variables for, and a monad for which one could. -- Ashley Yakeley From ganesh at earth.li Sat Aug 30 07:14:37 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 07:13:00 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B92972.8000700@semantic.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B92972.8000700@semantic.org> Message-ID: On Sat, 30 Aug 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> If you want to standardise a language feature, you have to explain its >> behaviour properly. This is one part of the necessary explanation. >> >> To be concrete about scenarios I was considering, what happens if: >> >> - the same process loads two copies of the GHC RTS as part of two >> completely independent libraries? For added complications, imagine that >> one of the libraries uses a different implementation instead (e.g. Hugs) >> >> - one Haskell program loads several different plugins in a way that >> allows Haskell values to pass across the plugin boundary >> >> How do these scenarios work with use cases for <- like (a) Data.Unique and >> (b) preventing multiple instantiation of a sub-library? > > That's a good question. But before you propose these scenarios, you must > establish that they are sane for Haskell as it is today. > > In particular, would _local_ IORefs work correctly? After all, the memory > allocator must be "global" in some sense. Could you be sure that different > calls to newIORef returned separate IORefs? Yes, I would expect that. Allocation areas propagate downwards from the OS to the top-level of a process and then into dynamically loaded modules if necessary. Any part of this puzzle that fails to keep them separate (in some sense) is just broken. > Perhaps this is the One True Global Scope: the scope in which refs from > newIORef are guaranteed to be separate. Every single call to newIORef, across the whole world, returns a different ref. The "same" one as a previous one can only be returned once the old one has become unused (and GCed). > It's the scope in which values from newUnique are supposed to be > different, and it would also be the scope in which top-level <- would be > called at most once. I don't really follow this. Do you mean the minimal such scope, or the maximal such scope? The problem here is not about separate calls to newIORef, it's about how many times an individual <- will be executed. Ganesh From ashley at semantic.org Sat Aug 30 07:18:27 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 07:16:51 2008 Subject: [Haskell-cafe] Re: Calling Lockheed, Indra, Thales, Raytheon In-Reply-To: <48B71EFB.9060309@cogito.org.uk> References: <48B71EFB.9060309@cogito.org.uk> Message-ID: <48B92C83.5050206@semantic.org> Paul Johnson wrote: > This is a strange question, I know, but is there anyone working in any > of the above companies on this mailing list? > > Everyone will no doubt be wondering what they have in common. I'm > afraid I can't discuss that. Air Traffic Control? -- Ashley Yakeley From ganesh at earth.li Sat Aug 30 07:24:28 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 07:22:52 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B920BE.30507@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B920BE.30507@iee.org> Message-ID: On Sat, 30 Aug 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> How do the implementers of Data.Unique know that they musn't let them be >> serialised/deserialised? > > Because if you could take a String and convert it to a Unique there > would be no guarantee that result was *unique*. Well, yes, but if I implemented a library in standard Haskell it would always be safely serialisable/deserialisable (I think). So the global variables hack somehow destroys that property - how do I work out why it does in some cases but not others? > I think the whole thread local state thing is a complete red herring. > > I've never seen a convincing use case for it and I suspect the only Well, I've never seen a convincing use case for global variables :-) > reason these to issues have become linked is that some folk are so > convinced that "global variables are evil", they mistakenly think > thread local variables must be less evil (because they are "less > global"). I don't think they're less evil, just that you might want them for the same sorts of reasons you might want global variables. > If plugins breaks is down to plugins to fix itself, at least until such > time as a suitable formal theory of plugins has been developed so it can > become standard Haskell :-) Dynamic loading and plugins work fine with standard Haskell now, because nothing in standard Haskell breaks them. The <- proposal might well break them, which is a significant downside for it. In general, the smaller the "world" that the Haskell standard lives in, the less it can interfere with other concerns. <- massively increases that world, by introducing the concept of a process scope. >> It's a hack that isn't robust in many situations. We should find better >> ways to do it, not standardise it. > > Nobody's talking about standardising the current hack. This the whole > point of the top level <- proposal, It just amounts to giving the current hack some nicer syntax and stating some rules under which it can be used. Those rules aren't actually strong enough to provide a guarantee of process level scope. > which JM seems to think is sound enough for incorporation into JHC > (correctly IMO). Nobody's found fault with it, other than the usual > global variables are evil mantra :-) Several people have found faults with it, you've just ignored or dismissed them. No doubt from your perspective the faults are irrelevant or untrue, but that's not my perspective. Ganesh From noteed at gmail.com Sat Aug 30 07:34:25 2008 From: noteed at gmail.com (minh thu) Date: Sat Aug 30 07:32:48 2008 Subject: [Haskell-cafe] Re: Calling Lockheed, Indra, Thales, Raytheon In-Reply-To: <48B92C83.5050206@semantic.org> References: <48B71EFB.9060309@cogito.org.uk> <48B92C83.5050206@semantic.org> Message-ID: <40a414c20808300434v5c5d7df2wf199877deb50a639@mail.gmail.com> 2008/8/30 Ashley Yakeley : > Paul Johnson wrote: >> >> This is a strange question, I know, but is there anyone working in any of >> the above companies on this mailing list? >> >> Everyone will no doubt be wondering what they have in common. I'm afraid >> I can't discuss that. > > Air Traffic Control? Maybe global warming. Thu From lennart at augustsson.net Sat Aug 30 07:36:21 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Aug 30 07:34:45 2008 Subject: [Haskell-cafe] Re: Calling Lockheed, Indra, Thales, Raytheon In-Reply-To: <48B92C83.5050206@semantic.org> References: <48B71EFB.9060309@cogito.org.uk> <48B92C83.5050206@semantic.org> Message-ID: They are all "defense" contractors. On Sat, Aug 30, 2008 at 12:18 PM, Ashley Yakeley wrote: > Paul Johnson wrote: >> >> This is a strange question, I know, but is there anyone working in any of >> the above companies on this mailing list? >> >> Everyone will no doubt be wondering what they have in common. I'm afraid >> I can't discuss that. > > Air Traffic Control? > > -- > Ashley Yakeley > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ashley at semantic.org Sat Aug 30 07:42:16 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 07:40:40 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B92972.8000700@semantic.org> Message-ID: <48B93218.4010600@semantic.org> Ganesh Sittampalam wrote: > Every single call to newIORef, across the whole world, returns a > different ref. How do you know? How can you compare them, except in the same Haskell expression? > The "same" one as a previous one can only be returned > once the old one has become unused (and GCed). Perhaps, but internally the IORef is a pointer value, and those pointer values might be the same. From the same perspective, one could say that every single call to newUnique across the whole world returns a different value, but internally they are Integers that might repeat. >> It's the scope in which values from newUnique are supposed to be >> different, and it would also be the scope in which top-level <- would >> be called at most once. > > I don't really follow this. Do you mean the minimal such scope, or the > maximal such scope? The problem here is not about separate calls to > newIORef, it's about how many times an individual <- will be executed. Two IO executions are in the same "global scope" if their resulting values can be used in the same expression. Top-level <- declarations must execute at most once in this scope. -- Ashley Yakeley From ganesh at earth.li Sat Aug 30 08:07:08 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 08:05:31 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B93218.4010600@semantic.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B92972.8000700@semantic.org> <48B93218.4010600@semantic.org> Message-ID: On Sat, 30 Aug 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> Every single call to newIORef, across the whole world, returns a different >> ref. > > How do you know? How can you compare them, except in the same Haskell > expression? I can write to one and see if the other changes. >> The "same" one as a previous one can only be returned once the old one has >> become unused (and GCed). > > Perhaps, but internally the IORef is a pointer value, and those pointer > values might be the same. From the same perspective, one could say that How can they be the same unless the memory management system is broken? I consider different pointers on different machines or in different virtual address spaces different too; it's the fact that they don't alias that matters. > every single call to newUnique across the whole world returns a different > value, but internally they are Integers that might repeat. The thing about pointers is that they are managed by the standard behaviour of memory allocation. This isn't true of Integers. In fact this point suggests an implementation for Data.Unique that should actually be safe without global variables: just use IORefs for the actual Unique values. IORefs already support Eq, as it happens. That gives you process scope for free, and if you want bigger scopes you can pair that with whatever makes sense, e.g. process ID, MAC address, etc. > Two IO executions are in the same "global scope" if their resulting > values can be used in the same expression. Top-level <- declarations > must execute at most once in this scope. This brings us back to the RPC question, and indeed to just passing values to somewhere else via FFI. I think you can work around some of that by talking about ADTs that aren't serialisable (e.g. ban the class Storable), but now we have different global scopes for different kinds of values, so which scope do we use to define <- ? Ganesh From ashley at semantic.org Sat Aug 30 08:09:15 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 08:07:39 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B93218.4010600@semantic.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B92972.8000700@semantic.org> <48B93218.4010600@semantic.org> Message-ID: <48B9386B.9000102@semantic.org> Ashley Yakeley wrote: >> I don't really follow this. Do you mean the minimal such scope, or the >> maximal such scope? The problem here is not about separate calls to >> newIORef, it's about how many times an individual <- will be executed. > > Two IO executions are in the same "global scope" if their resulting > values can be used in the same expression. Top-level <- declarations > must execute at most once in this scope. Better: Two newIORef executions are in the same "global scope" if their resulting refs can be used in the same expression. Top-level <- declarations must execute at most once in this scope. -- Ashley Yakeley From ashley at semantic.org Sat Aug 30 08:16:56 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 08:15:19 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> Message-ID: <48B93A38.7060002@semantic.org> Ganesh Sittampalam wrote: > How do the implementers of Data.Unique know that they musn't let them be > serialised/deserialised? What stops the same rule from applying to > Data.Random? Unique values should be no more deserialisable than IORefs. Is it the functionality of Data.Unique that you object to, or the fact that it's implemented with a global variable? If the former, one could easily build Unique values on top of IORefs, since IORef is in Eq. Thus Data.Unique is no worse than IORefs (ignoring hashability, anyway). If the latter, how do you recommend implementing Data.Unique? Implementing them on IORefs seems ugly. Or should they just be a primitive of the platform, like IORefs themselves? -- Ashley Yakeley From ganesh at earth.li Sat Aug 30 08:27:29 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 08:25:52 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B93A38.7060002@semantic.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> Message-ID: On Sat, 30 Aug 2008, Ashley Yakeley wrote: > Is it the functionality of Data.Unique that you object to, or the fact that > it's implemented with a global variable? > If the former, one could easily build Unique values on top of IORefs, since > IORef is in Eq. Thus Data.Unique is no worse than IORefs (ignoring > hashability, anyway). > > If the latter, how do you recommend implementing Data.Unique? > Implementing them on IORefs seems ugly. This seems fine to me. It's based on something that already does work properly across a process scope, instead of some new language feature that is actually hard to implement across the process scope. Ganesh From ashley at semantic.org Sat Aug 30 08:27:43 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 08:26:07 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B92972.8000700@semantic.org> <48B93218.4010600@semantic.org> Message-ID: <48B93CBF.5060403@semantic.org> Ganesh Sittampalam wrote: > How can they be the same unless the memory management system is broken? > I consider different pointers on different machines or in different > virtual address spaces different too; it's the fact that they don't > alias that matters. But the actual pointer value might repeat. >> every single call to newUnique across the whole world returns a >> different value, but internally they are Integers that might repeat. > > The thing about pointers is that they are managed by the standard > behaviour of memory allocation. This isn't true of Integers. But it could be. A global variable allows us to do the same thing as the memory allocator, and allocate unique Integers just as the allocator allocates unique pointer values. Now you can say that the same pointer value on different machines is different pointers; equally, you can say the same Integer in Unique on different machines is different Uniques: it's the fact that they don't alias that matters. > In fact this point suggests an implementation for Data.Unique that > should actually be safe without global variables: just use IORefs for > the actual Unique values. IORefs already support Eq, as it happens. That > gives you process scope for free, Isn't this rather ugly, though? We're using IORefs for something that doesn't involve reading or writing to them. Shouldn't there be a more general mechanism? -- Ashley Yakeley From ashley at semantic.org Sat Aug 30 08:30:26 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 08:28:49 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> Message-ID: <48B93D62.5000109@semantic.org> Ganesh Sittampalam wrote: > This seems fine to me. It's based on something that already does work > properly across a process scope, But you agree that IORefs define a concept of "process scope"? > instead of some new language feature that is actually hard to implement across the process scope. If we have a concept of "process scope", how is it hard to implement? -- Ashley Yakeley From ganesh at earth.li Sat Aug 30 08:37:37 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 08:35:59 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B93D62.5000109@semantic.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> Message-ID: On Sat, 30 Aug 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> This seems fine to me. It's based on something that already does work >> properly across a process scope, > > But you agree that IORefs define a concept of "process scope"? I'm not sure that they *define* process scope, because it might be safe to use them across multiple processes; it depends on OS-dependent properties. But they exist *at least* at process scope. >> instead of some new language feature that is actually hard to implement >> across the process scope. > > If we have a concept of "process scope", how is it hard to implement? Because memory allocation is already implemented, and not in a Haskell-dependent way. If two completely separate Haskell libraries are present in the same process, linked together by a C program, they don't even know about each others existence. But they still don't share memory space. Ganesh From ahey at iee.org Sat Aug 30 08:40:18 2008 From: ahey at iee.org (Adrian Hey) Date: Sat Aug 30 08:38:47 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B920BE.30507@iee.org> Message-ID: <48B93FB2.3060505@iee.org> Ganesh Sittampalam wrote: > On Sat, 30 Aug 2008, Adrian Hey wrote: >> Because if you could take a String and convert it to a Unique there >> would be no guarantee that result was *unique*. > > Well, yes, but if I implemented a library in standard Haskell it would > always be safely serialisable/deserialisable (I think). So the global > variables hack somehow destroys that property - how do I work out why it > does in some cases but not others? This has nothing to do with the use of global variables. If you have a set of values that are guaranteed to be distinct ("unique") and you add another random/arbitrary value to that set you have no way of knowing that it is different from any current member (other than searching the entire set, assuming it's available). > Well, I've never seen a convincing use case for global variables :-) Well apart from all the libs that couldn't be implemented with them... >> reason these to issues have become linked is that some folk are so >> convinced that "global variables are evil", they mistakenly think >> thread local variables must be less evil (because they are "less >> global"). > > I don't think they're less evil, just that you might want them for the > same sorts of reasons you might want global variables. "Global variables" are needed to ensure important safety properties, but the only reasons I've seen people give for thread local variables is that explicit state threading is just so tiresome and ugly. Well that may be (wouldn't disagree), but I'm not aware of any library that simply couldn't be implemented without them. >> If plugins breaks is down to plugins to fix itself, at least until >> such time as a suitable formal theory of plugins has been developed so >> it can become standard Haskell :-) > > Dynamic loading and plugins work fine with standard Haskell now, because > nothing in standard Haskell breaks them. The <- proposal might well > break them, which is a significant downside for it. I don't see how, but if so <- bindings are not the cause of the brokeness. They'd still be broken using the unsafePerformIO hack. > In general, the > smaller the "world" that the Haskell standard lives in, the less it can > interfere with other concerns. <- massively increases that world, by > introducing the concept of a process scope. All IORefs,MVars,Chans scope across the entire process defined by main. Or at least they *should*, if they don't then something is already badly wrong somewhere. This has nothing to do with whether or not they appear at top level. This is what an IORef/MVar whatever is defined to be. > >>> It's a hack that isn't robust in many situations. We should find >>> better ways to do it, not standardise it. >> >> Nobody's talking about standardising the current hack. This the whole >> point of the top level <- proposal, > > It just amounts to giving the current hack some nicer syntax and stating > some rules under which it can be used. No, the unsafePerformIO hack is a hack because it's *unsound*. The compiler doesn't know how to translate this into code that does what the programmer intended. Fortunately ghc at least does have a couple of flags that give the intended result (we hope). The new binding syntax is nicer, but it's real purpose is to leave the compiler no "wriggle room" when interpreting the programmers intent. But then again, I'm sure that some that will be adamant that any way of making "global variables" is a hack. But they'll still be happy to go on using file IO, sockets etc regardless, blissfully unaware of the hacks they are dependent on :-) > Those rules aren't actually > strong enough to provide a guarantee of process level scope. The rules for <- bindings shouldn't have to guarantee this. This should be guaranteed by newMVar returning a new *MVar*, wherever it's used (for example). >> which JM seems to think is sound enough for incorporation into JHC >> (correctly IMO). Nobody's found fault with it, other than the usual >> global variables are evil mantra :-) > > Several people have found faults with it, you've just ignored or > dismissed them. No doubt from your perspective the faults are irrelevant > or untrue, but that's not my perspective. I mean semantic faults, as in the proposal just doesn't do what it promises for some subtle reason. If you consider not giving you thread local variables a fault I guess you're entitled to that view, but this was never the intent of the proposal in the first place (that's not what people are trying to do when they use the unsafePerformIO hack). Regards -- Adrian Hey From ashley at semantic.org Sat Aug 30 08:41:44 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 08:40:07 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> Message-ID: <48B94008.6060209@semantic.org> Ganesh Sittampalam wrote: > On Sat, 30 Aug 2008, Ashley Yakeley wrote: > >> Ganesh Sittampalam wrote: >>> This seems fine to me. It's based on something that already does work >>> properly across a process scope, >> >> But you agree that IORefs define a concept of "process scope"? > > I'm not sure that they *define* process scope, because it might be safe > to use them across multiple processes; it depends on OS-dependent > properties. But they exist *at least* at process scope. How can one use IORefs across multiple processes? They cannot be serialised. From ganesh at earth.li Sat Aug 30 08:52:03 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 08:50:25 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B94008.6060209@semantic.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> Message-ID: On Sat, 30 Aug 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> On Sat, 30 Aug 2008, Ashley Yakeley wrote: >> >>> Ganesh Sittampalam wrote: >>>> This seems fine to me. It's based on something that already does work >>>> properly across a process scope, >>> >>> But you agree that IORefs define a concept of "process scope"? >> >> I'm not sure that they *define* process scope, because it might be safe >> to use them across multiple processes; it depends on OS-dependent >> properties. But they exist *at least* at process scope. > > How can one use IORefs across multiple processes? They cannot be serialised. Firstly, that's a property of the current implementation, rather than a universal one, IMO. I don't for example see why you couldn't add a newIORef variant that points into shared memory, locking issues aside. Also, the issue is not whether you can *use* them across multiple processes, but whether they are unique across multiple processes. Uniqueness has two possible definitions; aliasing, and representational equality. No two IORefs will ever alias, so by that definition they exist at global scope. For representational equality, that exists at least at process scope, and perhaps more. Ganesh From waldmann at imn.htwk-leipzig.de Sat Aug 30 09:07:57 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Aug 30 09:06:22 2008 Subject: [Haskell-cafe] Re: Parsec and network data In-Reply-To: References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> <48B8395D.1080605@imn.htwk-leipzig.de> Message-ID: <48B9462D.2040303@imn.htwk-leipzig.de> apfelmus wrote: > Design your language in a way that the *parse* tree does not depend on import > statements? I.e. Chasing imports is performed after you've got an abstract > syntax tree. OK, that would work. This property does not hold for Haskell, because you need the fixities of the operators (so, another language design error :-) J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080830/7a4bb2c4/signature.bin From ashley at semantic.org Sat Aug 30 09:13:18 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 09:11:42 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> Message-ID: <48B9476E.3030501@semantic.org> Ganesh Sittampalam wrote: > Firstly, that's a property of the current implementation, rather than a > universal one, IMO. I don't for example see why you couldn't add a > newIORef variant that points into shared memory, locking issues aside. OK, so that would be a new Haskell feature. And it's that feature that would be the problem, not top-level <-. It would bring its own garbage collection issues, for instance. Currently we have shared memory should be raw bytes, and IORef values can't be serialised there. > Also, the issue is not whether you can *use* them across multiple > processes, but whether they are unique across multiple processes. > Uniqueness has two possible definitions; aliasing, and representational > equality. No two IORefs will ever alias, so by that definition they > exist at global scope. For representational equality, that exists at > least at process scope, and perhaps more. By global scope, I mean the largest execution scope an IORef created by newIORef can have. Each top-level IORef declaration should create an IORef at most once in this scope. IORefs cannot be serialised, so they cannot be sent over serialised RPC. So let us consider your shared memory possibility. Do you mean simply an IORef of a block of bytes of the shared memory? That would be fine, but that is really a different type than IORef. It still keeps the "global scopes" separate, as IORefs cannot be passed through [Word8]. Or do you mean you could use shared memory to pass across IORefs? This would mean joining the address spaces with no memory protection between them. It would mean joining the garbage collectors somehow. Once you've dealt with that, the issue of making sure that each initialiser runs only once for the new shared space is really only one more issue. -- Ashley Yakeley From ganesh at earth.li Sat Aug 30 09:30:36 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Aug 30 09:28:59 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B9476E.3030501@semantic.org> References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> Message-ID: On Sat, 30 Aug 2008, Ashley Yakeley wrote: > Ganesh Sittampalam wrote: >> Firstly, that's a property of the current implementation, rather than a >> universal one, IMO. I don't for example see why you couldn't add a >> newIORef variant that points into shared memory, locking issues aside. > > OK, so that would be a new Haskell feature. And it's that feature that > would be the problem, not top-level <-. It would bring its own garbage > collection issues, for instance. OK, never mind about that; I agree it's not a very good idea. An IORef shouldn't escape the scope of the RTS/GC that created it. >> Also, the issue is not whether you can *use* them across multiple >> processes, but whether they are unique across multiple processes. >> Uniqueness has two possible definitions; aliasing, and representational >> equality. No two IORefs will ever alias, so by that definition they exist >> at global scope. For representational equality, that exists at least at >> process scope, and perhaps more. > > By global scope, I mean the largest execution scope an IORef created by > newIORef can have. Each top-level IORef declaration should create an IORef > at most once in this scope. That's a reasonable definition, if by "execution scope" you mean your previous definition of "where the IORef can be directly used". But it's not process scope; two independent Haskell libraries in the same process can no more share IORefs than two separate Haskell processes. [what I meant by global scope above was "the entire world"] Ganesh From waldmann at imn.htwk-leipzig.de Sat Aug 30 09:33:15 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Aug 30 09:31:42 2008 Subject: [Haskell-cafe] Named field syntax In-Reply-To: References: <48B7FC03.1060502@imn.htwk-leipzig.de> <20080829205954.GA6102@flit> Message-ID: <48B94C1B.1080003@imn.htwk-leipzig.de> > Consider for instance defining datatype for 3x3 matrix. I think the only sensible modelling for that would use dependent types. > Also, if positional record notation is a design error, then is it also a > design error not to require all arguments to be explicitly associated > with named formal parameters at a function call site (e.g. f(x = 1, y = > 2, z = 3))? well, same question for incomplete "case" expressions. Would you rule them out? Leaving out some parameter associations would be possible if we could declare default parameters (in record types and function declarations) - but this conflicts with partial application. if you define f (x :: Int) (y :: Int = 42) :: Int, and write (f 0), does it have type Int -> Int (partial app) or type Int (using the default)? I understand no-one seriously wants to remove partial application for functions but if we (hypothetically, but we're in the *-cafe) forbid positional notation for record constructors, then we could have default values in record types, and I can imagine quite some applications for that, and especially so if the default value can be defined to depend on the (other) values (that are given on construction). Well, my horror for positional notation is basically that introducing or removing a component/parameter breaks all code that uses the type/function. So, perhaps instead of changes in the language I just want a refactoring tool that supports * change function signature (remove, insert, swap parameters, including all necessary changes at call sites) * for data declaration, convert positional to named notation J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080830/2f984052/signature.bin From ahey at iee.org Sat Aug 30 10:02:22 2008 From: ahey at iee.org (Adrian Hey) Date: Sat Aug 30 10:00:51 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B93FB2.3060505@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B920BE.30507@iee.org> <48B93FB2.3060505@iee.org> Message-ID: <48B952EE.9000109@iee.org> Adrian Hey wrote: > "Global variables" are needed to ensure important safety properties, > but the only reasons I've seen people give for thread local variables > is that explicit state threading is just so tiresome and ugly. Well > that may be (wouldn't disagree), but I'm not aware of any library > that simply couldn't be implemented without them. I thought I ought to say a bit more about my unkind and hasty words re. thread local variables. This is discussed from time to time and there's a wiki page here sumarising proposals... http://www.haskell.org/haskellwiki/Thread-local_storage One thing that worries me is that nobody seems to know what problem thread local storage is solving, hence diversity of proposals. I'm also a struggling to see why we need it, but I don't have any passionate objections to it either. Unfortunately for those of us that want a solution to the "global variables" problem the two issues seem have been linked as being the part of same problem, so while there's all this uncertainty about what thread local variables are actually going to be used for and what they should look like the (IMO) much simpler "global variables" problem/solution is in limbo. This has been going on 4 or 5 years now IIRC. But the "global variables" problem is really much simpler. All we want is something that does exactly what the unsafePerformIO hack currently does (assuming flag/pragma hackery does the trick), but does it reliably. (IMO, YMMV..) Regards -- Adrian Hey From allbery at ece.cmu.edu Sat Aug 30 10:12:19 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Aug 30 10:10:48 2008 Subject: [Haskell-cafe] Re: 2 modules in one file In-Reply-To: References: <20080827121943.49b4de05.Malcolm.Wallace@cs.york.ac.uk> <2608b8a80808270811x35b940e4la2bc22c6616b265b@mail.gmail.com> <48B575DF.8000300@cs.nott.ac.uk> Message-ID: <9A31DE7E-0C6A-4BCB-B528-07C267574D5C@ece.cmu.edu> On 2008 Aug 30, at 4:22, Aaron Denney wrote: > On 2008-08-27, Henrik Nilsson wrote: >> And there are also potential issues with not every legal module name >> being a legal file name across all possible file systems. > > I find this unconvincing. Broken file systems need to be fixed. Language people trying to impose constraints on filesystems is the tail wagging the dog. -- 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 hjgtuyl at chello.nl Sat Aug 30 11:32:26 2008 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat Aug 30 11:30:45 2008 Subject: [Haskell-cafe] FunGEn Message-ID: L.S., I found the Functional Game Engine FunGEn on the web: http://www.cin.ufpe.br/~haskell/fungen/download.html It looks useful, but since it hasn't been maintained for a long time, it doesn't compile. Is there a newer version I can download? -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From johan.tibell at gmail.com Sat Aug 30 12:49:10 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Aug 30 12:47:32 2008 Subject: [Haskell-cafe] Parsec and network data In-Reply-To: <916b84820808300351m37f1e659gc194d1e3735fa66e@mail.gmail.com> References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <916b84820808300351m37f1e659gc194d1e3735fa66e@mail.gmail.com> Message-ID: <90889fe70808300949g78b40597m251dcd045513c1af@mail.gmail.com> On Sat, Aug 30, 2008 at 3:51 AM, Thomas Schilling wrote: > I remember Johan Tibell (CC'd) working on an extended variant of > Parsec that can deal with this chunked processing. The idea is to > teach Parsec about a partial input and have it return a function to > process the rest (a continuation) if it encounters the end of a chunk > (but not the end of a file). Maybe Johan can tell you more about > this, or point you to his implementation. I have written a parser for my web server that uses continuations to resume parsing. It's not really Parsec like anymore though. It only parses LL(1) grammars as that's all I need to parse HTTP. I haven't released a first version of my server yet, indeed most of the code is on this laptop and not in the Git repo [1], but if you would like to steal some ideas feel free. 1. http://www.johantibell.com/cgi-bin/gitweb.cgi?p=hyena.git;a=blob;f=Hyena/Parser.hs;h=8086b11bfeb3bca15bfd16ec9c6a4b34aadf528e;hb=HEAD Cheers, Johan From allbery at ece.cmu.edu Sat Aug 30 14:19:54 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Aug 30 14:18:27 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B920BE.30507@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B920BE.30507@iee.org> Message-ID: On 2008 Aug 30, at 6:28, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> How do the implementers of Data.Unique know that they musn't let >> them be serialised/deserialised? > > Because if you could take a String and convert it to a Unique there > would be no guarantee that result was *unique*. > >> What stops the same rule from applying to Data.Random? > > Well the only data type defined by this is StdGen, which is a Read/ > Show > instance. I guess there's no semantic problem with that (can't think > of > one off hand myself). You *want* to be able to reproduce a given random seed, for simulations and the like. -- 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 simon at joyful.com Sat Aug 30 15:06:33 2008 From: simon at joyful.com (Simon Michael) Date: Sat Aug 30 15:05:13 2008 Subject: [Haskell-cafe] Re: FunGEn In-Reply-To: References: Message-ID: <48B99A39.8040101@joyful.com> Henk-Jan van Tuyl wrote: > L.S., > > I found the Functional Game Engine FunGEn on the web: > http://www.cin.ufpe.br/~haskell/fungen/download.html > It looks useful, but since it hasn't been maintained for a long time, it > doesn't compile. Is there a newer version I can download? Hi Henk-Jan, yes, see my updates at http://joyful.com/darcsweb/darcsweb.cgi?r=fungen;a=summary . Thanks to Andre Furtado for this nice engine. I suggested he choose a license such as X11 or GPLv3 so it could be uploaded to hackage. He was unsure about his licensing options given that Fungen depends on HOpenGL and got busy. Please contact him so this can get licensed and packaged for wider exposure. From byorgey at seas.upenn.edu Sat Aug 30 15:07:22 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Aug 30 15:05:47 2008 Subject: [Haskell-cafe] Haskell Weekly News: Issue 83 - August 30, 2008 Message-ID: <20080830190721.GA31316@minus.seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20080830 Issue 83 - August 30, 2008 --------------------------------------------------------------------------- Welcome to issue 83 of HWN, a newsletter covering developments in the [1]Haskell community. This is the "better late than never" edition. As an excuse I could tell you that my home internet service has been horrible (now fixed) and I was away from home for a few days with my wife celebrating our third wedding anniversary. But instead, I give you a link to the [2]Uncyclopedia entry on Haskell. If you haven't already seen it, you should give it a read, being sure not to drink any milk at the same time, or at least pointing your nose away from the keyboard if you insist on drinking milk. Community News If Dell sends John Goerzen (CosmicRay) one more catalog, it will [3]actually be a federal crime. Announcements LogFloat 0.9. wren ng thornton [4]announced a new official release of the [5]logfloat package for manipulating log-domain floating numbers. This release is mainly for those who are playing with Transfinite rather than LogFloat, but the interface changes warrant a minor version change. validating xml lib - need some guidance. Marc Weber [6]asked for help developing an xml generating library validating the result against a given DTD. gsl-random 0.1 and monte-carlo-0.1. Patrick Perry [7]announced that he has started on [8]bindings for the random number generators and random distributions provided by the gsl. He has also written a [9]monad and transformer for doing monte carlo computations that uses gsl-random internally. For a quick tutorial in the latter package, see [10]his blog. Wired 0.1.1. Emil Axelsson [11]announced the first release of the hardware description library [12]Wired. Wired can be seen as an extension to Lava that targets (not exclusively) semi-custom VLSI design. A particular aim of Wired is to give the designer more control over the routing wires' effects on performance. darcs weekly news #1. Eric Kow [13]sent out the first edition of the new Darcs Weekly News! zip-archive 0.0. John MacFarlane [14]announced the release of the [15]zip-archive library for dealing with zip archives. The Monad.Reader - Issue 11. Wouter Swierstra [16]announced a new issue of [17]The Monad.Reader, with articles by David Place, Kenn Knowles, and Doug Auclair. First Monad Tutorial of the Season. Hans van Thiel [18]announced a new monad tutorial, [19]The Greenhorn's Guide to becoming a Monad Cowboy. "Real World Haskell" hits a milestone. Bryan O'Sullivan [20]proudly announced that the draft manuscript of Real World Haskell is [21]complete! It is now available online in its entirety. The authors expect the final book to be published around the beginning of November, and to weigh in at about 700 pages. Mueval 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.6.4. Gwern Branwen [22]announced a number of new releases of [23]Mueval. Lambdabot now uses mueval for all its dynamic Haskell evaluation needs. Hoogle Database Generation. Neil Mitchell (ndm) [24]announced that a new release of the [25]Hoogle command line is out, including bug fixes and additional features. Upgrading is recommended.Two interesting features of Hoogle 4 are working with multiple function databases (from multiple packages), and running your own web server. Blog noise [26]Haskell news from the [27]blogosphere. * Real-World Haskell: [28]Source handed over to production. * Douglas M. Auclair (geophf): [29]Earning \bot-Trophies. * Douglas M. Auclair (geophf): [30]Scanner-parsers II: State Monad Transformers. * Douglas M. Auclair (geophf): [31]Scanner-parsers I: lifting functions. * >>> software engineering radio: [32]Episode 108: Simon Peyton Jones on Functional Programming and Haskell. A podcast interview with Simon Peyton Jones. * Neil Mitchell: [33]Running your own Hoogle on a Web Server. * Braden Shepherdson: [34]Announcing xmonad-light. Braden is rolling out a new configuration framework for xmonad, providing an easier learning curve for those not wanting to learn Haskell right away, and an easy transition to a more powerful Haskell configuration when they want it. * Gabor Grief: [35]Category. Gabor is excited that base-3.0 will include Control.Category. * Douglas M. Auclair (geophf): [36]Ten = 1+2+3+4. Solving an arithmetic puzzle with Haskell, Prolog-style. * Paul R Brown: [37]perpubplat now on github. * Douglas M. Auclair (geophf): [38]"Lucky you!"?. Doug shares some secrets of his success in getting Haskell/Dylan/Mercury/Prolog jobs. * Neil Mitchell: [39]Hoogle Database Generation. Neil releases a new command-line version of Hoogle, including bug fixes and additional features -- multiple function databases and the ability to run your own Hoogle server. * Patrick Perry: [40]A Monte Carlo Monad for Haskell. * Mads Lindstroem: [41]Proposal: Adding composability to WxHaskell. * Tom Moertel: [42]PXSL Tools now on Hackage and GitHub. * Gabor Greif: [43]Uploaded. Gabor uploads his first contribution to Hackage, [44]thrist-0.1. * Muad`Dib (vixey): [45]Tail Call Optimization doesn't exist in Haskell. * >>> Hans van Thiel: [46]The Greenhorn's Guide to becoming a Monad Cowboy. YAMT * Dan Piponi (sigfpe): [47]Untangling with Continued Fractions: Part 2. Dan continues his excellent series on rational tangles, this time showing the connection between tangles and rational numbers. * >>> Praki Prakash: [48]Learning Haskell Redux. * Gabor Greif: [49]Ca(ni)balized. Gabor creates his first cabal package! * Real-World Haskell: [50]Our writing is now complete!. * Tom Moertel: [51]Thinking algebraically: a functional-programming dividend that pays during your imperative-programming day job. * Jason Dagit: [52]Darcs 2 Real-World Push Performance Evaluation. * Well-Typed.Com: [53]What's wrong with make?. A lot, apparently: it's too static, and makes it easy to write incorrect rules. Duncan (dcoutts) provides an analysis. * Dougal Stanton: [54]Lord of the Flies as a window onto monadic IO. * Real-World Haskell: [55]A tighter page count estimate. Real World Haskell is going to be about 700 pages!? * Real-World Haskell: [56]Real World Haskell tutorial next month at DEFUN 2008. Quotes of the Week * shepheb: #haskell isn't so much on-topic when discussing Haskell, but off-off-topic. * chrisdone: it's neat how you learn haskell because you are drawn in by the purely functional paradigm, and then you find loads more things like algebraic data types, monad abstractions, arrows and applicative, lack of objects... so that when people say "well, it's not haskell, but at least X is functional", it's just not the same at all * lambdabot: [tristes_tigres] @vixen unsafe [lambdabot] you're turning me on :) * b\6: sometimes i make variables f and ck and find some reason to multiply them like f*ck if i'm having a bad day. * waynemokane: wow... thanks everyone - it looks like I have a full day of reading type signatures ahead of me. * mauke: call/cthulhu * seydar: monads are just like saran wrap. * b\6: keep this info private, but you can actually overclock your brain. the technique i use is to loop mplayer playing oggs but increase the speed like -speed 1.25 for 125% normal. your brain's speed increases accordingly, allowing you to solve problems much more easily. About the Haskell Weekly News New editions are posted to [57]the Haskell mailing list as well as to [58]the Haskell Sequence and [59]Planet Haskell. [60]RSS is also available, and headlines appear on [61]haskell.org. To help create new editions of this newsletter, please see the information on [62]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [63]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://uncyclopedia.org/wiki/Haskell 3. http://changelog.complete.org/posts/741-From-Dell,-a-Uniquely-Terrible-Experience.html 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43829 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43825 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43764 8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gsl-random 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monte-carlo 10. http://quantile95.com/2008/08/27/a-monte-carlo-monad-for-haskell/ 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43658 12. http://www.cs.chalmers.se/~emax/wired/index.html 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43626 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43539 15. http://johnmacfarlane.net/zip-archive/ 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43491 17. http://www.haskell.org/haskellwiki/The_Monad.Reader 18. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43403 19. http://www.muitovar.com/monad/moncow.xhtml 20. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43401 21. http://www.realworldhaskell.org/blog/2008/08/22/our-writing-is-now-complete/ 22. http://article.gmane.org/gmane.comp.lang.haskell.cafe/43372 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mueval 24. http://neilmitchell.blogspot.com/2008/08/hoogle-database-generation.html 25. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hoogle 26. http://planet.haskell.org/ 27. http://haskell.org/haskellwiki/Blog_articles 28. http://www.realworldhaskell.org/blog/2008/08/30/source-handed-over-to-production/ 29. http://logicaltypes.blogspot.com/2008/08/earning.html 30. http://logicaltypes.blogspot.com/2008/08/scanner-parsers-ii-state-monad.html 31. http://logicaltypes.blogspot.com/2008/08/scanner-parsers-i-lifting-functions.html 32. http://www.se-radio.net/podcast/2008-08/episode-108-simon-peyton-jones-functional-programming-and-haskell 33. http://neilmitchell.blogspot.com/2008/08/running-your-own-hoogle-on-web-server.html 34. http://braincrater.wordpress.com/2008/08/28/announcing-xmonad-light/ 35. http://heisenbug.blogspot.com/2008/08/category.html 36. http://logicaltypes.blogspot.com/2008/08/ten-1234.html 37. http://mult.ifario.us/p/perpubplat-now-on-github 38. http://logicaltypes.blogspot.com/2008/08/lucky-you.html 39. http://neilmitchell.blogspot.com/2008/08/hoogle-database-generation.html 40. http://quantile95.com/2008/08/27/a-monte-carlo-monad-for-haskell/ 41. http://lindstroem.wordpress.com/2008/03/16/proposal-adding-composability-to-wxhaskell/ 42. http://blog.moertel.com/articles/2008/08/24/pxsl-tools-now-on-hackage-and-github 43. http://heisenbug.blogspot.com/2008/08/uploaded.html 44. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/thrist 45. http://muaddibspace.blogspot.com/2008/08/tail-call-optimization-doesnt-exist-in.html 46. http://www.muitovar.com/monad/moncow.xhtml 47. http://sigfpe.blogspot.com/2008/08/untangling-with-continued-fractions_23.html 48. http://monadict.blogspot.com/2008/08/learning-haskell-redux-when-you-are.html 49. http://heisenbug.blogspot.com/2008/08/canibalized.html 50. http://www.realworldhaskell.org/blog/2008/08/22/our-writing-is-now-complete/ 51. http://blog.moertel.com/articles/2008/08/20/thinking-algebraically-a-functional-programming-dividend-that-pays-during-your-imperative-programming-day-job 52. http://blog.codersbase.com/2008/08/21/darcs-2-real-world-push-performance-evaluation/ 53. http://blog.well-typed.com/2008/08/whats-wrong-with-make/ 54. http://www.dougalstanton.net/blog/index.php/2008/08/21/lord-of-the-flies-as-a-window-onto-monadic-io/ 55. http://www.realworldhaskell.org/blog/2008/08/20/a-tighter-page-count-estimate/ 56. http://www.realworldhaskell.org/blog/2008/08/20/real-world-haskell-tutorial-next-month-at-defun-2008/ 57. http://www.haskell.org/mailman/listinfo/haskell 58. http://sequence.complete.org/ 59. http://planet.haskell.org/ 60. http://sequence.complete.org/node/feed 61. http://haskell.org/ 62. http://haskell.org/haskellwiki/HWN 63. http://code.haskell.org/~byorgey/code/hwn/ From gwern0 at gmail.com Sat Aug 30 15:48:12 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Aug 30 15:48:09 2008 Subject: [Haskell-cafe] Re: FunGEn In-Reply-To: <48B99A39.8040101@joyful.com> References: <48B99A39.8040101@joyful.com> Message-ID: <20080830194812.GA29265@craft> On 2008.08.30 12:06:33 -0700, Simon Michael scribbled 0.7K characters: > Henk-Jan van Tuyl wrote: >> L.S., >> >> I found the Functional Game Engine FunGEn on the web: >> http://www.cin.ufpe.br/~haskell/fungen/download.html >> It looks useful, but since it hasn't been maintained for a long time, >> it doesn't compile. Is there a newer version I can download? > > Hi Henk-Jan, > > yes, see my updates at > http://joyful.com/darcsweb/darcsweb.cgi?r=fungen;a=summary . > > Thanks to Andre Furtado for this nice engine. I suggested he choose a > license such as X11 or GPLv3 so it could be uploaded to hackage. He was > unsure about his licensing options given that Fungen depends on HOpenGL > and got busy. Please contact him so this can get licensed and packaged > for wider exposure. The HOpenGL stuff is BSD3-licensed like the rest of the base libraries, isn't it? I think that means there are no license restrictions in that direction; Andre just needs to pick a Free license Hackage likes (==DFSG-compatible or OSI-approved). I don't see what the problem is. -- gwern InfoSec Z-150T HERF Met Information Texas Cornflower 20755 Bubba IS -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080830/74edfa51/attachment.bin From ashley at semantic.org Sat Aug 30 16:40:49 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Aug 30 16:39:12 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: References: <534781822.20080826190130@gmail.com> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> Message-ID: <48B9B051.4060009@semantic.org> Ganesh Sittampalam wrote: >> By global scope, I mean the largest execution scope an IORef created >> by newIORef can have. Each top-level IORef declaration should create >> an IORef at most once in this scope. > > That's a reasonable definition, if by "execution scope" you mean your > previous definition of "where the IORef can be directly used". But it's > not process scope; two independent Haskell libraries in the same process > can no more share IORefs than two separate Haskell processes. > > [what I meant by global scope above was "the entire world"] OK. Let's call it "top-level scope". Haskell naturally defines such a thing, regardless of processes and processors. Each top-level <- would run at most once in top-level scope. If you had two Haskell runtimes call by C code, each would have its own memory allocator and GC; IORefs, Uniques and thunks cannot be shared between them; and each would have its own top-level scope, even though they're in the same process. -- Ashley Yakeley From wnoise at ofb.net Sat Aug 30 16:41:28 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sat Aug 30 16:40:04 2008 Subject: [Haskell-cafe] Re: Parsec and network data References: <22f6a8f70808261335l27e9542bxcbbc6e1f53b07176@mail.gmail.com> <20080829161522.79B9E93C51@mail.avvanta.com> <48B8395D.1080605@imn.htwk-leipzig.de> <48B9462D.2040303@imn.htwk-leipzig.de> Message-ID: On 2008-08-30, Johannes Waldmann wrote: > apfelmus wrote: > >> Design your language in a way that the *parse* tree does not depend >> on import statements? I.e. Chasing imports is performed after you've >> got an abstract syntax tree. > > OK, that would work. > > This property does not hold for Haskell, > because you need the fixities of the operators > (so, another language design error :-) Yes, but you can partially parse into a list, which later gets completely parsed. It's not like C with its textual inclusion, and constructs changing what counts as a type. -- Aaron Denney -><- From briqueabraque at yahoo.com Sat Aug 30 21:44:57 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Sat Aug 30 21:43:40 2008 Subject: [Haskell-cafe] Discussing FFI Message-ID: Hi, I saw the (a?) page about FFI on Haskell: http://www.cse.unsw.edu.au/~chak/haskell/ffi It shows a link to a mailing list but, checking the list archives at: http://www.haskell.org/pipermail/ffi , it seems it's dead since 2007. Is there a new list about FFI? Where should I discuss my begginer issues about it? Thanks, Maur?cio From dons at galois.com Sat Aug 30 21:47:29 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 30 21:45:51 2008 Subject: [Haskell-cafe] Discussing FFI In-Reply-To: References: Message-ID: <20080831014729.GB22451@scytale.galois.com> briqueabraque: > Hi, > > I saw the (a?) page about FFI on Haskell: > > http://www.cse.unsw.edu.au/~chak/haskell/ffi > > It shows a link to a mailing list but, > checking the list archives at: > > http://www.haskell.org/pipermail/ffi , > > it seems it's dead since 2007. Is there > a new list about FFI? Where should I > discuss my begginer issues about it? The FFI is standard Haskell, so just talk about it on haskell-cafe@haskell.org From marco-oweber at gmx.de Sun Aug 31 01:13:15 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Aug 31 01:11:38 2008 Subject: [Haskell-cafe] idea: TH calculating type level function results / binary types? Message-ID: <20080831051315.GA15496@gmx.de> Hi, Maybe you've noted that I've started writing an XML library which validates the generated XML against a given DTD at compile time. Not everything is implemented right now and it would be quite usable if it didn't take that much time. The problem: To see some details have look at my small announcement on haskellcafe. type checking 12 lines of XML code has taken > 3hourse using some TypeToNat type equality comparison > 35sec using an implementation proposed by Oleg > 30sec no longer using HLists to check wether an attribute may be added but an AttrOk tag attr class (proposed by Oleg) > ?sec after finishing a state transformation implementation propably generating thausands of intermediate state or a mixture of this and the parser like apporach. Even if the last approach works it's a pity because: * it took much time to write * hard to read code * no error messages.. In the 30sec apprach I've used some instances such as class Consume elType state state' | elType state -> state' class FailHelper state' state'' | state' -> state'' instance FailHelper (Fail a) => FailHelper (F a) () -- F indicating sub element could not be consumed, failure instance FailHelper a a -- So I got error messages telling me no instance for MoreElementsExpected (Or (E Html_T) (E Body_T)) or such.. that's nice and usable. I can't think of a nice way reporting errors when transforming a dtd line (a,b,c) (= tag sequence a b c) into data State1 data State2 data State3 instance Conseme State1 A_T State2 -- consume tag a instance Conseme State2 B_T State3 -- consume tag b instance Conseme State3 C_T ConsumedEnd -- consume tag c in a convinient way without adding much bloat. The XHMTL spec has about 150 ! tags.. So even if creating this kind of state transforming instances this will result in a lot of bloat. So if the compiler has to load a some MB large .hi file it will spend unnecessary time just loading them. an idea: (new?) solution: What about enhancing ghc so that a) you can define type level functions and calculate the result using template haskell functions: benefits: * speed (it can even be compiled! ) * nice error messages on failure * mantainable code * reusing known source (such as parser combinator libraries) syntax could look like this: class Bar a b c d | a b -> c, a b -> d instance (Maybe x) z $(calculateC) $(calculateD) calculateC :: Type -> Type -> Type calculateD :: Type -> Type -> Type an efficient implementation for TypeEq a b typebool | a b -> typebool could be done by everyone with ease without reading HList source or Olegs papers.. (you should do so anyway ..) b) add some binary serialization support so that you don't have to do expensive data -> type level -> data (de)serializations. .hi files wouldn't blow much this way as well. So a parse specification such as (1) could really be included within types and could become even more complex. Than an exisiting parser combinator library could be used and a validating XML library could be written within some hours.. I think ghc is already a superiour compiler because it allows such advanced technics thereby making users such as me even ask for more :-) I consider this a good sign. So has anyone thought about this before? Would someone help / guide me implementing this extension in the near future? Of course it will clash with some instance -X extensions.. but I think that in everyday use you'd probably use either this template haskell approach or use normal class instance declarations so it I guess it could be handled. Maybe this does already exist in one or the other way? Sincerly Marc Weber (1) (Seq (Elem Title_T) (Seq (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))) (Query (Seq (Elem Base_T) (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))))))) From andrewcoppin at btinternet.com Sun Aug 31 03:46:32 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Aug 31 03:44:46 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <1220040768.908.67.camel@jcchost> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <1220040768.908.67.camel@jcchost> Message-ID: <48BA4C58.3000807@btinternet.com> Jonathan Cast wrote: > On Fri, 2008-08-29 at 20:56 +0100, Andrew Coppin wrote: > >> I've been playing with this today, and no matter what rules I come up >> with, it seems to be ridiculously easy to put the interpretter into an >> infinite loop from which it will never escape. Is there any way to know >> which binds are "worth" expanding and which ones aren't? (I have a >> sinking feeling this might be equivilent to the Halting Problem...) >> >> For example, if you have "let x = f y; y = g x in x" then since all the >> functions are free variables, there's really nothing much "useful" you >> can do to simplify this any further. However, my interpretter merrily >> goes into an endless loop building a huge expression like "f (g (f (g (f >> (g..." Is it possible to avoid this? >> > > If you want to avoid infinite normal forms (or just plain lack of normal > forms, as in let x = x in x or (\x -> x x) (\ x -> x x)), you need to > follow three rules: > > 1) Static typing > 2) No value recursion > 3) If you allow data types, no recursive data types > > Otherwise, your language will be Turing-complete, so yes, trying to > determine ahead of time if even a HNF exists will be the halting > problem. > > If you really want to write a general-purpose evaluator, then infinite > normal forms may not be an issue, as long as they are generated lazily, > so your evaluator can at least print something out while it goes into an > infinite loop. Otherwise, you can declare f x, where f is an unknown > function, a HNF, and stop at that point, or go on only under the > client's control. > > The optimizers used by GHC and YHC pick one function out of each > recursive binding group, and just refuse to inline it at all. If you > don't mind producing expressions that aren't really in any definable > HNF, that would be an alternative as well. > Right. So if I have, say, the factorial function defined using the Y combinator, there's no way to stop the interpretter expanding an infinite number of copies of Y, even though in theory the factorial function should terminate? Oh well, I guess I'll just have to live with that one. Maybe I can make the binding to expand user-selectable or something... From ryani.spam at gmail.com Sun Aug 31 05:52:58 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Aug 31 05:51:18 2008 Subject: [Haskell-cafe] Compiler's bane In-Reply-To: <48BA4C58.3000807@btinternet.com> References: <48B5B220.4000307@btinternet.com> <404396ef0808271308g6e08e633pd49d49e9fd7af14a@mail.gmail.com> <48B85460.2070109@btinternet.com> <1220040768.908.67.camel@jcchost> <48BA4C58.3000807@btinternet.com> Message-ID: <2f9b2d30808310252h1a3be45fva1fa8b51b4ebe352@mail.gmail.com> On Sun, Aug 31, 2008 at 12:46 AM, Andrew Coppin wrote: > Right. So if I have, say, the factorial function defined using the Y > combinator, there's no way to stop the interpretter expanding an infinite > number of copies of Y, even though in theory the factorial function should > terminate? Well, this is exactly what ghci is doing; you just have to choose an evaluation order that makes sense. Lets consider a simple translation for recursive lets: > let x = exp1 in exp2 (where x may be free in exp1 and/or exp2) Here's a simple translation into lambda-calculus: > (\x. exp2) (y (\x. exp1)) (Of course, this representation for let can lose sharing; without knowing what you have or your goals I don't know if you care). Now, you just have to choose a y-combinator that makes sense for your evaluation order. If you do normal-order evaluation like Haskell ("non-strict"), this Y should work for you: y = \f. (\x. f (x x)) (\x. f (x x)) > Oh well, I guess I'll just have to live with that one. Maybe I can make the > binding to expand user-selectable or something... Now, if you are eagerly-expanding the entire expression, trying to get to head normal form, then any expression that ends up with "y" in it won't terminate. But if you use normal form evaluation order, then if a normal form exists, you will find it and terminate. So evaluating "fact" to normal form won't terminate, but evaluating "fact 5" should. -- ryan From jason.dusek at gmail.com Sun Aug 31 06:47:10 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Aug 31 06:45:29 2008 Subject: [Haskell-cafe] Calling Lockheed, Indra, Thales, Raytheon In-Reply-To: <48B71EFB.9060309@cogito.org.uk> References: <48B71EFB.9060309@cogito.org.uk> Message-ID: <42784f260808310347j193e4e2lc2193fbe3deebdf0@mail.gmail.com> You could dump the archives, grep out the names and then Google... -- _jsn From ahey at iee.org Sun Aug 31 08:34:46 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Aug 31 08:33:13 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <200808281317.30358.dan.doel@gmail.com> References: <534781822.20080826190130@gmail.com> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <200808281317.30358.dan.doel@gmail.com> Message-ID: <48BA8FE6.4090904@iee.org> Dan Doel wrote: > Here's a first pass: > > -- snip -- > > {-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-} > > module Unique where > > import Control.Monad.Reader > import Control.Monad.Trans > > import Control.Concurrent.MVar > > -- Give Uniques a phantom region parameter, so that you can't accidentally > -- compare Uniques from two different uniqueness sources. > newtype Unique r = Unique Integer deriving Eq > > newtype U r a = U { unU :: ReaderT (MVar Integer) IO a } > deriving (Functor, Monad, MonadIO) > > -- Higher rank type for region consistency > runU :: (forall r. U r a) -> IO a > runU m = newMVar 0 >>= runReaderT (unU m) > > newUnique :: U r (Unique r) > newUnique = U (do source <- ask > val <- lift $ takeMVar source > let next = val + 1 > lift $ putMVar source next > return $ Unique next) > > -- hashUnique omitted > > -- snip -- > > It's possible that multiple unique sources can exist in a program with this > implementation, but because of the region parameter, the fact that a Unique > may not be "globally" unique shouldn't be a problem. If your whole program > needs arbitrary access to unique values, then I suppose something like: > > main = runU realMain > > realMain :: U r () > realMain = ... > > is in order. > > Insert standard complaints about this implementation requiring liftIO all over > the place if you actually want to do other I/O stuff inside the U monad. Well that wouldn't be my main complaint :-) Thanks for taking the time to do this Dan. I think the safety requirement has been met, but I think it fails on the improved API. The main complaint would be what I see as loss of modularity, in that somehow what should be a small irrelevant detail of the implementation of some obscure module somewhere has propogated it's way all the way upto main. This is something it seems to have in common with all other attempts I've seen to solve the "global variable" problem without actually using a..you know what :-) It doesn't matter whether it's explicit state handle args, withWhateverDo wrappers, novel monads or what. They all have this effect. To me this seems completely at odds with what I thought was generally accepted wisdom of how to write good maintainable, modular software. Namely hiding as much implemention detail possible and keeping APIs as simple and stable as they can be. I don't know if I'm alone in that view nowadays. I'm also not sure I understand why so many people seem to feel that stateful effects must be "accounted for" somehow in the args and/or types of the effecting function. Like if I had.. getThing :: IO Thing ..as an FFI binding, nobody would give it a moments thought. They'd see it from it's type that it had some mysterious world state dependent/effecting behaviour, but would be quite happy to just accept that the didn't really need to worry about all that magic... instead they'd accept that it "just works". Why then, if I want to implement precisely the same thing in Haskell (using a "global variable") does it suddenly become so important for this stateful magic to be accounted for? Like the presence of that "global variable" must be made so very painfully apparent in main (and everywhere else on the dependency path too I guess). In short, I just don't get it :-) Purists aren't going to like it, but I think folk *will* be using "real" global variables in I/O libs for the forseeable future. Seems a shame that they'll have to do this with unsafePerformIO hack though :-( Regards -- Adrian Hey From ganesh at earth.li Sun Aug 31 10:04:47 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Aug 31 10:03:07 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B9B051.4060009@semantic.org> References: <534781822.20080826190130@gmail.com> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B93A38.7060002@semantic.org> <48B93D62.5000109@semantic.org> <48B94008.6060209@semantic.org> <48B9476E.3030501@semantic.org> <48B9B051.4060009@semantic.org> Message-ID: On Sat, 30 Aug 2008, Ashley Yakeley wrote: > OK. Let's call it "top-level scope". Haskell naturally defines such a > thing, regardless of processes and processors. Each top-level <- would > run at most once in top-level scope. > > If you had two Haskell runtimes call by C code, each would have its own > memory allocator and GC; IORefs, Uniques and thunks cannot be shared > between them; and each would have its own top-level scope, even though > they're in the same process. That sounds more feasible - though it does constrain a plugin architecture (in which Haskell code can dynamically load other Haskell code) to cooperate with the loading RTS and not load multiple copies of modules; this might make linking tricky. There's also the problem Duncan Coutts mentioned about loading multiple versions of the same module - what are the semantics of <- in relation to that? Also, it's no use for mediating access to a resource or library that can only be accessed once, right? In fact, even without the problem of two Haskell runtimes in one process this can't work, since some library in another language might also choose to access that resource or library. What applications does this leave beyond Data.Unique and Random? Ganesh From ganesh at earth.li Sun Aug 31 10:20:05 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Aug 31 10:18:25 2008 Subject: [Haskell-cafe] Re: [Haskell] Top Level <- In-Reply-To: <48B93FB2.3060505@iee.org> References: <534781822.20080826190130@gmail.com> <20080827093521.GP15616@sliver.repetae.net> <1219857466.5819.1.camel@derek-laptop> <20080827222503.GW15616@sliver.repetae.net> <20080828023200.GZ15616@sliver.repetae.net> <48B66942.3050703@iee.org> <1219939641.908.8.camel@jcchost> <48B6D1B3.4030007@iee.org> <48B6FC56.4050301@iee.org> <48B72513.7010700@iee.org> <48B8A239.4030904@iee.org> <48B920BE.30507@iee.org> <48B93FB2.3060505@iee.org> Message-ID: On Sat, 30 Aug 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: > >> Well, yes, but if I implemented a library in standard Haskell it would >> always be safely serialisable/deserialisable (I think). So the global >> variables hack somehow destroys that property - how do I work out why it >> does in some cases but not others? > > This has nothing to do with the use of global variables. If you have > a set of values that are guaranteed to be distinct ("unique") and you > add another random/arbitrary value to that set you have no way of > knowing that it is different from any current member (o