From simons at cryp.to Mon Dec 1 04:04:41 2008 From: simons at cryp.to (Peter Simons) Date: Mon Dec 1 03:58:18 2008 Subject: How to expose cabal-generated installation paths? References: <87hc5xe4u5.fsf@write-only.cryp.to> <1227644724.19577.28.camel@localhost> Message-ID: <87d4gc466u.fsf@write-only.cryp.to> Hi Duncan, > It's filed as ticket: http://hackage.haskell.org/trac/hackage/ticket/396 I believe that I can work around this problem by making Paths_funcmp a private module, i.e. one that is not exported. Thank you for the explanation. Take care, Peter From Christian.Maeder at dfki.de Mon Dec 1 06:09:09 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Dec 1 06:02:40 2008 Subject: Binary Trees missing on hackage Message-ID: <4933C5D5.2000902@dfki.de> Hi, I was surprised that I could not find a "classical" binary tree data structure on hackage, mainly for teaching purposes, like: data BinTree a = Nil | Node (BinTree a) a (BinTree a) with a couple of utility functions and instances (i.e. in-order traversal). Surely, one may argue, that such a tree can always be defined on the fly when needed, but nobody would argue so for lists or tuples. (Although I've rarely seen someone redefining lists, it is quite common to introduce user-defined products or enumerations.) There are rose trees in Data.Tree and many other variants of trees are conceivable, ie. data Boom a = Leaf a | Node (Boom a) (Boom a) or a kind of combination: data BinLeafTree a b = Leaf b | Node (BinLeafTree a b) a (BinLeafTree a b) I don't know, why I find the above BinTree most important. I'm not even sure if such a tree could be re-used for Search- or AVL-trees that need strict fields with redundant size or height counters for efficiency reasons. In any case I would find such a data type at least as useful as http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OneTuple Who would supply and maintain such a package? Or did I simply not search hard enough? Cheers Christian P.S. I took the (non-empty) "Boom" from the Boom-Hierarchy described in "An Exploration of the Bird-Meertens Formalism" by Roland Backhouse 1988, Groningen From wagner.andrew at gmail.com Mon Dec 1 06:24:11 2008 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Mon Dec 1 06:17:41 2008 Subject: Binary Trees missing on hackage In-Reply-To: <4933C5D5.2000902@dfki.de> References: <4933C5D5.2000902@dfki.de> Message-ID: The reasons I've always heard for this is that 1.) It's so easy to define a tree and 2.) There are tons of different variations of trees and what you can do with them. Not that I 100% agree, just what I've always heard. On Mon, Dec 1, 2008 at 6:09 AM, Christian Maeder wrote: > Hi, > > I was surprised that I could not find a "classical" binary tree data > structure on hackage, mainly for teaching purposes, like: > > data BinTree a = Nil | Node (BinTree a) a (BinTree a) > > with a couple of utility functions and instances (i.e. in-order traversal). > > Surely, one may argue, that such a tree can always be defined on the fly > when needed, but nobody would argue so for lists or tuples. (Although > I've rarely seen someone redefining lists, it is quite common to > introduce user-defined products or enumerations.) > > There are rose trees in Data.Tree and many other variants of trees are > conceivable, ie. > > data Boom a = Leaf a | Node (Boom a) (Boom a) > > or a kind of combination: > > data BinLeafTree a b = > Leaf b > | Node (BinLeafTree a b) a (BinLeafTree a b) > > I don't know, why I find the above BinTree most important. I'm not even > sure if such a tree could be re-used for Search- or AVL-trees that need > strict fields with redundant size or height counters for efficiency > reasons. > > In any case I would find such a data type at least as useful as > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OneTuple > > Who would supply and maintain such a package? Or did I simply not search > hard enough? > > Cheers Christian > > P.S. I took the (non-empty) "Boom" from the Boom-Hierarchy described in > "An Exploration of the Bird-Meertens Formalism" by Roland Backhouse > 1988, Groningen > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081201/8e976edb/attachment-0001.htm From Axel.Simon at ens.fr Mon Dec 1 07:41:29 2008 From: Axel.Simon at ens.fr (Axel Simon) Date: Mon Dec 1 07:35:04 2008 Subject: Profiling options Message-ID: <1228135289.13936.29.camel@aconit> Hi all, I'm trying to build a library with Cabal and then profile certain modules. I'm not very proficient with profiling, so it might be genuinely wrong what I'm doing. I compile my library with --enable-library-profiling and at the moment have ghc-prof-options: -auto-all in my cabal file. However, I only want to use -auto in one core module since seeing all the other functions is just obfuscating the profile since the costs are also accredited to callers of the functions that I want to profile. I tried to use {-# OPTIONS -auto #-} in the specific module but ghc ignores this since -auto is a static option. Cabal, on the other hand, does not allow me to add an option when compiling a specific module. It it true that I'm stuck with using -auto on either all or no module when I build my library using Cabal? The only thing on profiling and Cabal I've found is Ticket #200, however, this ticket seems to advocate that the user never needs any control over what is being profiled and what is not. So, is my attempt to profile a single module really a stupid idea or is it Cabal that should provide better support for profiling individual modules? Thanks, Axel. From wagner.andrew at gmail.com Mon Dec 1 08:28:27 2008 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Mon Dec 1 08:22:00 2008 Subject: Binary Trees missing on hackage In-Reply-To: References: <4933C5D5.2000902@dfki.de> Message-ID: Hm, I've been thinking about this this morning as I've gone about my commute. I could indeed imagine a class like the following that had multiple implementations like you're talking about: class Tree t where drawTree :: t String -> String flatten :: t a -> [a] etc. (see http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Tree.html) I think that for this to be valuable, though, we would need to show that there are functions which can take a generic Tree t and do something useful with it. Still, I suspect there's something there. Maybe I'll take a stab at it this week sometime. On Mon, Dec 1, 2008 at 6:24 AM, Andrew Wagner wrote: > The reasons I've always heard for this is that 1.) It's so easy to define a > tree and 2.) There are tons of different variations of trees and what you > can do with them. Not that I 100% agree, just what I've always heard. > > On Mon, Dec 1, 2008 at 6:09 AM, Christian Maeder > wrote: > >> Hi, >> >> I was surprised that I could not find a "classical" binary tree data >> structure on hackage, mainly for teaching purposes, like: >> >> data BinTree a = Nil | Node (BinTree a) a (BinTree a) >> >> with a couple of utility functions and instances (i.e. in-order >> traversal). >> >> Surely, one may argue, that such a tree can always be defined on the fly >> when needed, but nobody would argue so for lists or tuples. (Although >> I've rarely seen someone redefining lists, it is quite common to >> introduce user-defined products or enumerations.) >> >> There are rose trees in Data.Tree and many other variants of trees are >> conceivable, ie. >> >> data Boom a = Leaf a | Node (Boom a) (Boom a) >> >> or a kind of combination: >> >> data BinLeafTree a b = >> Leaf b >> | Node (BinLeafTree a b) a (BinLeafTree a b) >> >> I don't know, why I find the above BinTree most important. I'm not even >> sure if such a tree could be re-used for Search- or AVL-trees that need >> strict fields with redundant size or height counters for efficiency >> reasons. >> >> In any case I would find such a data type at least as useful as >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OneTuple >> >> Who would supply and maintain such a package? Or did I simply not search >> hard enough? >> >> Cheers Christian >> >> P.S. I took the (non-empty) "Boom" from the Boom-Hierarchy described in >> "An Exploration of the Bird-Meertens Formalism" by Roland Backhouse >> 1988, Groningen >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081201/95573ebe/attachment.htm From Christian.Maeder at dfki.de Mon Dec 1 09:39:18 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Dec 1 09:32:46 2008 Subject: Binary Trees missing on hackage In-Reply-To: References: <4933C5D5.2000902@dfki.de> Message-ID: <4933F716.2000806@dfki.de> I find classes for sequences, collections (edison) and graphs (fgl) and your proposed trees a bit awkward. I'ld like to see the actual data types first. Like for lists I can imagine a whole bunch of useful functions for BinTree (below) that are already implemented multiple times for user defined binary trees (in other libraries). Cheers Christian Andrew Wagner wrote: > Hm, I've been thinking about this this morning as I've gone about my > commute. I could indeed imagine a class like the following that had > multiple implementations like you're talking about: > > class Tree t where > drawTree :: t String -> String > flatten :: t a -> [a] > etc. > (see http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Tree.html) > > > I think that for this to be valuable, though, we would need to show that > there are functions which can take a generic Tree t and do something > useful with it. Still, I suspect there's something there. Maybe I'll > take a stab at it this week sometime. > > On Mon, Dec 1, 2008 at 6:24 AM, Andrew Wagner > wrote: > > The reasons I've always heard for this is that 1.) It's so easy to > define a tree and 2.) There are tons of different variations of > trees and what you can do with them. Not that I 100% agree, just > what I've always heard. > > On Mon, Dec 1, 2008 at 6:09 AM, Christian Maeder > > wrote: > > Hi, > > I was surprised that I could not find a "classical" binary tree data > structure on hackage, mainly for teaching purposes, like: > > data BinTree a = Nil | Node (BinTree a) a (BinTree a) > > with a couple of utility functions and instances (i.e. in-order > traversal). > > Surely, one may argue, that such a tree can always be defined on > the fly > when needed, but nobody would argue so for lists or tuples. > (Although > I've rarely seen someone redefining lists, it is quite common to > introduce user-defined products or enumerations.) > > There are rose trees in Data.Tree and many other variants of > trees are > conceivable, ie. > > data Boom a = Leaf a | Node (Boom a) (Boom a) > > or a kind of combination: > > data BinLeafTree a b = > Leaf b > | Node (BinLeafTree a b) a (BinLeafTree a b) > > I don't know, why I find the above BinTree most important. I'm > not even > sure if such a tree could be re-used for Search- or AVL-trees > that need > strict fields with redundant size or height counters for > efficiency reasons. > > In any case I would find such a data type at least as useful as > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OneTuple > > Who would supply and maintain such a package? Or did I simply > not search > hard enough? > > Cheers Christian > > P.S. I took the (non-empty) "Boom" from the Boom-Hierarchy > described in > "An Exploration of the Bird-Meertens Formalism" by Roland Backhouse > 1988, Groningen > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery at ece.cmu.edu Mon Dec 1 21:47:38 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Dec 1 21:41:34 2008 Subject: [Haskell-cafe] Re: Binary Trees missing on hackage In-Reply-To: References: <4933C5D5.2000902@dfki.de> Message-ID: <6F033122-937D-4913-A33C-B5945C153A0F@ece.cmu.edu> On 2008 Dec 1, at 8:28, Andrew Wagner wrote: > Hm, I've been thinking about this this morning as I've gone about my > commute. I could indeed imagine a class like the following that had > multiple implementations like you're talking about: One can indeed --- but it turns out to be even more general than just trees. Go look at the Foldable and Traversable classes. -- 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/libraries/attachments/20081201/b26491ae/attachment.htm From hpacheco at gmail.com Mon Dec 1 22:15:27 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Dec 1 22:08:53 2008 Subject: Building haddock when accessing data files from package code In-Reply-To: <1227886665.10115.44.camel@localhost> References: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> <1227881870.10115.29.camel@localhost> <7b92c2840811280625t1a086d24jd2e6f6ccf3ec7045@mail.gmail.com> <1227886665.10115.44.camel@localhost> Message-ID: <7b92c2840812011915u2ddd1a14v88632717ebb203e8@mail.gmail.com> Well, I am using cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library The suggested trick (adding dist/build/autogen to Hs-Source-Dirs) solved the problem. Here goes the important part of my .cabal file: Data-files: GHood.jar Build-type: Simple Cabal-Version: >=1.2 Flag splitBase Description: Choose the new smaller, split-up base package. Library Hs-Source-Dirs: src, dist/build/autogen Build-Depends: base, haskell98 if flag(splitBase) Build-Depends: base >= 3, array >= 0.1, pretty >= 1.0 else Build-Depends: base < 3 exposed-modules: Debug.Observe other-modules: Paths_GHood extensions: ScopedTypeVariables Rank2Types TypeSynonymInstances On Fri, Nov 28, 2008 at 3:37 PM, Duncan Coutts wrote: > On Fri, 2008-11-28 at 14:25 +0000, Hugo Pacheco wrote: > > I don't know if I got the ideia. > > I have always built before and always got the error: > > > > > > $ runhaskell Setup.lhs configure > > $ runhaskell Setup.lhs build > > $ runhaskell Setup.lhs haddock > > .. > > Setup.lhs: can't find source for module Paths_module > > Ok, that is supposed to work. We'll need more details, eg the Cabal lib > version and the .cabal file you're using. > > There was a bug in this area in Cabal-1.4.x: > http://hackage.haskell.org/trac/hackage/ticket/187 > > Duncan > > > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081202/70a6c736/attachment-0001.htm From bart at cs.pdx.edu Tue Dec 2 02:44:10 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Tue Dec 2 02:37:54 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd References: Message-ID: I've attached new patches against Darcs head to my proposal at http://hackage.haskell.org/trac/ghc/ticket/2717 The patches implement Set.nubOrd and IntSet.nubInt, and modify the documentation for List.nub. Please take a look at these patches and give any comments on this "final" version of code or documentation. If I don't hear otherwise shortly, I'll go ahead and request that these patches be incorporated for 2.6.11. Thanks. Bart Massey bart cs.pdx.edu From gale at sefer.org Tue Dec 2 06:18:38 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Dec 2 06:12:03 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd In-Reply-To: References: Message-ID: <2608b8a80812020318g487372ccvf701dba37fde995c@mail.gmail.com> Bart Massey wrote: > The patches implement Set.nubOrd and IntSet.nubInt, and modify the documentation > for List.nub. Could you please call it IntSet.nubOrd instead? The namespaces of Set and IntSet should be compatible wherever possible, so that you can just change the import statement (and perhaps a type signature) to switch between them. Thanks, Yitz From ndmitchell at gmail.com Tue Dec 2 06:28:23 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Dec 2 06:21:47 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd In-Reply-To: <2608b8a80812020318g487372ccvf701dba37fde995c@mail.gmail.com> References: <2608b8a80812020318g487372ccvf701dba37fde995c@mail.gmail.com> Message-ID: <404396ef0812020328k2e68f233s7c44ad9cc743c127@mail.gmail.com> Hi > Could you please call it IntSet.nubOrd instead? I considered raising this, but decided nubInt is better than nubOrd. These functions don't really belong in Set/IntSet - its just a case of dependencies etc. As such, I don't think the usual rules apply, because nubOrd doesn't work on Set's at all. From a usage point of view, nubInt/nubOrd is much clearer. Thanks Neil From gale at sefer.org Tue Dec 2 07:01:47 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Dec 2 06:55:11 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd In-Reply-To: <404396ef0812020328k2e68f233s7c44ad9cc743c127@mail.gmail.com> References: <2608b8a80812020318g487372ccvf701dba37fde995c@mail.gmail.com> <404396ef0812020328k2e68f233s7c44ad9cc743c127@mail.gmail.com> Message-ID: <2608b8a80812020401w5115c0aete1b5ce71d2b78bcc@mail.gmail.com> I wrote: >> Could you please call it IntSet.nubOrd instead? Neil Mitchell wrote: > I considered raising this, but decided nubInt is better than nubOrd. > These functions don't really belong in Set/IntSet - its just a case of > dependencies etc. As such, I don't think the usual rules apply, > because nubOrd doesn't work on Set's at all. From a usage point of > view, nubInt/nubOrd is much clearer. Usually the difference between using the Map or IntMap version of nub won't be that significant. If you are worried about the distinction being clear, you can always use qualified imports, so that you'll write Map.nubOrd vs. IntMap.nubOrd. It has become standard style to give two functions the same name if they live in different modules and they do the "same thing" except at different types. In general I think it is worthwhile to emphasize simplicity and consistency in namespace choices. In the case of Map and IntMap, I would like to see us strive for the two modules to export *exactly* the same set of symbols, except for the type names/constructors Map and IntMap. Thanks, Yitz From bart at cs.pdx.edu Tue Dec 2 12:20:15 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Tue Dec 2 12:13:49 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd References: <2608b8a80812020318g487372ccvf701dba37fde995c@mail.gmail.com> <404396ef0812020328k2e68f233s7c44ad9cc743c127@mail.gmail.com> <2608b8a80812020401w5115c0aete1b5ce71d2b78bcc@mail.gmail.com> Message-ID: Yitzchak Gale sefer.org> writes: > > > Could you please call it IntSet.nubOrd instead? > > Neil Mitchell wrote: > > I considered raising this, but decided nubInt is better > > than nubOrd. From a usage point of view, nubInt/nubOrd > > is much clearer. > > In the case of Map and IntMap,I would like to see us > strive for the two modules to export *exactly* the same > set of symbols, except for the type names/constructors Map > and IntMap. There's only two possibilities that make sense to me: (1) do what I did and call the three functions in question nub, nubOrd, and nubInt, or (2) call them all nub. If we're going to be consistent with names across types, then there's no reason for nubOrd to be a special case either, I think. And calling a function nubOrd when it won't work with arbitrary Ord data just seems broken to me. Given the pain in the neck that is Haskell's management of names that are duplicated in different imported modules, and the propensity to use Data.List and Data.Set together, I prefer (1). But if folks prefer (2), or if they prefer Yitzchak's intermediate version, please let us know on-list ASAP. Bart Massey bart cs.pdx.edu From ndmitchell at gmail.com Tue Dec 2 12:25:37 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Dec 2 12:19:00 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd In-Reply-To: References: <2608b8a80812020318g487372ccvf701dba37fde995c@mail.gmail.com> <404396ef0812020328k2e68f233s7c44ad9cc743c127@mail.gmail.com> <2608b8a80812020401w5115c0aete1b5ce71d2b78bcc@mail.gmail.com> Message-ID: <404396ef0812020925t1ebe6d79uf1696fabba47e58f@mail.gmail.com> > There's only two possibilities that make sense to me: (1) do > what I did and call the three functions in question nub, > nubOrd, and nubInt, or (2) call them all nub. If we're > going to be consistent with names across types, then there's > no reason for nubOrd to be a special case either, I think. > And calling a function nubOrd when it won't work with > arbitrary Ord data just seems broken to me. > > Given the pain in the neck that is Haskell's management of > names that are duplicated in different imported modules, and > the propensity to use Data.List and Data.Set together, I > prefer (1). But if folks prefer (2), or if they prefer > Yitzchak's intermediate version, please let us know on-list > ASAP. (+1) for option (1) Neil From duncan.coutts at worc.ox.ac.uk Wed Dec 3 07:25:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Dec 3 07:18:35 2008 Subject: Building haddock when accessing data files from package code In-Reply-To: <7b92c2840812011915u2ddd1a14v88632717ebb203e8@mail.gmail.com> References: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> <1227881870.10115.29.camel@localhost> <7b92c2840811280625t1a086d24jd2e6f6ccf3ec7045@mail.gmail.com> <1227886665.10115.44.camel@localhost> <7b92c2840812011915u2ddd1a14v88632717ebb203e8@mail.gmail.com> Message-ID: <1228307111.10115.258.camel@localhost> On Tue, 2008-12-02 at 03:15 +0000, Hugo Pacheco wrote: > Well, I am using > > > cabal-install version 0.6.0 > using version 1.6.0.1 of the Cabal library > > > The suggested trick (adding dist/build/autogen to Hs-Source-Dirs) > solved the problem. If possible would you mind testing the patch that we think fixes this bug: http://hackage.haskell.org/trac/hackage/ticket/396 It's in the development version of Cabal. If it works for you then I'll push it to the Cabal-1.6 branch and it'll appear in Cabal-1.6.0.2. The development version of the Cabal lib lives at: darcs get http://darcs.haskell.org/cabal/ Alternatively if your code is available then I could use that to confirm the fix. Duncan From hpacheco at gmail.com Wed Dec 3 17:27:14 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Wed Dec 3 17:20:34 2008 Subject: Building haddock when accessing data files from package code In-Reply-To: <1228307111.10115.258.camel@localhost> References: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> <1227881870.10115.29.camel@localhost> <7b92c2840811280625t1a086d24jd2e6f6ccf3ec7045@mail.gmail.com> <1227886665.10115.44.camel@localhost> <7b92c2840812011915u2ddd1a14v88632717ebb203e8@mail.gmail.com> <1228307111.10115.258.camel@localhost> Message-ID: <7b92c2840812031427h3b7e227dqa1100e99cdf3ba36@mail.gmail.com> It worked! Thanks, hugo On Wed, Dec 3, 2008 at 12:25 PM, Duncan Coutts wrote: > On Tue, 2008-12-02 at 03:15 +0000, Hugo Pacheco wrote: > > Well, I am using > > > > > > cabal-install version 0.6.0 > > using version 1.6.0.1 of the Cabal library > > > > > > The suggested trick (adding dist/build/autogen to Hs-Source-Dirs) > > solved the problem. > > If possible would you mind testing the patch that we think fixes this > bug: > > http://hackage.haskell.org/trac/hackage/ticket/396 > > It's in the development version of Cabal. If it works for you then I'll > push it to the Cabal-1.6 branch and it'll appear in Cabal-1.6.0.2. > > The development version of the Cabal lib lives at: > darcs get http://darcs.haskell.org/cabal/ > > Alternatively if your code is available then I could use that to confirm > the fix. > > Duncan > > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081203/2b7bb104/attachment.htm From benedikt.ahrens at web.de Fri Dec 5 11:14:44 2008 From: benedikt.ahrens at web.de (ben.a) Date: Fri Dec 5 11:07:58 2008 Subject: treating spaces with Parsec Message-ID: <20857293.post@talk.nabble.com> hello, i am trying to write a parser in haskell, using parsec. the task is as follows: a string shall go into a data type (String, [(String, [Integer])]). as an example: "LC.app : 0 , 2 22. abs : 1 ." shall give ("LC", [("app", [0, 2, 22]), ("abs", [1])]) the string is separated by dots, and the integers are separated by either commas or spaces (this is why i cannot use lexer). i have written the following parser, which is not elegant at all, and has the flaw that it does not accept the example because of the space between the 1 and the last dot. furthermore it won't accept newline as a separator for SepBy. -------- the types type Constructor = (String, [Integer]) type Sig = (String, [Constructor]) -- ("LC", [("app", [0, 0]), ("abs", [1])]) -------- the main parser parseString2 :: Parser Sig parseString2 = do spaces name <- word spaces eol sig <- endBy line eol return (name, sig) --------- the parser for one symbol line :: Parser Constructor line = do spaces constru <- word spaces (char ':') spaces ar <- sepBy number separator return (constru, ar) -------- the parser for the integer values number :: Parser Integer number = do ds <- many1 digit; return (read ds) -------- the end of line parser -------- two symbols are separated by at least one point or newline eol :: Parser () eol = do skipMany1 (char '.' <|> char '\n') -------- a separator between two integers is a space or a comma separator :: Parser () separator = skipMany1 (space <|> char ',') i would appreciate if somebody could help me. i tried to exploit all the manuals i found for haskell, but was not successful. greetings ben -- View this message in context: http://www.nabble.com/treating-spaces-with-Parsec-tp20857293p20857293.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From doaitse at swierstra.net Sun Dec 7 16:05:30 2008 From: doaitse at swierstra.net (S. Doaitse Swierstra) Date: Sun Dec 7 15:58:48 2008 Subject: [Announce] TTTAS (with excuse for second attempt to post) Message-ID: <5AF74C18-ED38-4C1F-A9FC-512AD7AEEE9A@swierstra.net> We are pleased to announce the availability of the package "TTTAS", which contains the code associated with our paper at the coming TLDI workshop: \@inproceedings{ BSV09, author = {Arthur Baars and S. Doaitse Swierstra and Marcos Viera}, title = {Typed Transformations of Typed Abstract Syntax}, booktitle = {TLDI '09: fourth ACM SIGPLAN Workshop on Types in Language Design and Implementation}, year = {2009}, location = {Savannah, Georgia, USA}, publisher = {ACM}, address = {New York, NY, USA}, } For more information see: http://www.cs.uu.nl/wiki/bin/view/Center/TTTAS Arthur Baars Marcos Viera Doaitse Swierstra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081207/23ab5283/attachment.htm From doaitse at swierstra.net Sun Dec 7 16:07:22 2008 From: doaitse at swierstra.net (S.Doaitse Swierstra) Date: Sun Dec 7 16:00:49 2008 Subject: [Haskell] ANNOUNCE: ChristmasTree 0.1 (excuses for second attempt) In-Reply-To: <49399A47.1020103@van.steenbergen.nl> References: <1213789520.15010.837.camel@localhost> <7A61F72B-55DD-4390-AA51-1A6B6FBF2C31@swierstra.net> <49399A47.1020103@van.steenbergen.nl> Message-ID: <1B6E1D99-7B9E-4493-88B2-0EA4A54A5906@swierstra.net> We are pleased to announce the availability of the package "ChristmasTree", which contains the code associated with our paper at the last Haskell symposium: @inproceedings{1411296, author = {Marcos Viera and S. Doaitse Swierstra and Eelco Lempsink}, title = {Haskell, do you read me?: constructing and composing efficient top-down parsers at runtime}, booktitle = {Haskell '08: Proceedings of the first ACM SIGPLAN symposium on Haskell}, year = {2008}, isbn = {978-1-60558-064-7}, pages = {63--74}, location = {Victoria, BC, Canada}, doi = {http://doi.acm.org/10.1145/1411286.1411296}, publisher = {ACM}, address = {New York, NY, USA}, } The name of the package stands for: "Changing Haskell's Read Implementation Such That by Manipulating Abstract Syntax Trees it Reads Expressions Efficiently" which, given the time of year, seems appropriate. Feel free to download and unpack this "present" at what for the Dutch is called "Sinterklaasavond" (http://en.wikipedia.org/wiki/Sinterklaas), Arthur Baars Marcos Viera Eelco Lempsink Doaitse Swierstra PS: the package uses our library supporting transformation of typed abstract syntax, which we placed in a separate package TTTAS From haskell at list.mightyreason.com Sun Dec 7 16:17:04 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sun Dec 7 16:10:15 2008 Subject: Announcing Haskell protocol-buffers version 1.2.2 Message-ID: <493C3D50.5010806@list.mightyreason.com> Hi everyone, To keep up with protocol-buffers 2.0.3 here is an improved Haskell "hprotoc" version 1.2.2 : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers-descriptor http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc The darcs repository with all 3 packages is at http://darcs.haskell.org/packages/protocol-buffers2/ These ought to be compatible with the previous version 1.2.1. As usual, this code read a ".proto" file which describes message formats and generates Haskell modes to encode and decode corresponding data type to the binary wire format. Google's original protocol buffers are at http://code.google.com/apis/protocolbuffers/docs/overview.html and generate code for C++, Python, and Java. Other languages are listed on the wiki at http://code.google.com/p/protobuf/wiki/OtherLanguages (including Haskell). The two changes are support for the field-option-like syntax for EnumValueOptions, and adjacent string literals are concatenated. Note that strings are checked for valid utf8 encoding after concatenation, not individually. But backslash escape codes are decoded for each individual string, not after concatenation. If these quirks become problems they can be changed. The protoc bug fixed in 2.0.3: > * Fixed bug where .proto files which use custom options but don't actually > define them (i.e. they import another .proto file defining the options) > had to explicitly import descriptor.proto." did not affect hprotoc, which already did the Right Thing? (I just tested to be sure). The protoc bug fixed in 2.0.3: > * If an input file is a Windows absolute path (e.g. "C:\foo\bar.proto") and > the import path only contains "." (or contains "." but does not contain > the file), protoc incorrectly thought that the file was under ".", because > it thought that the path was relative (since it didn't start with a slash). > This has been fixed. is unlikely to be be present in hprotoc. But since I never run or test on Windows I make no promises hprotoc is finding the correct relative paths on Windows. Cheers, Chris Kuklewicz From pixel at mandriva.com Mon Dec 8 06:55:37 2008 From: pixel at mandriva.com (Pixel) Date: Mon Dec 8 06:46:42 2008 Subject: treating spaces with Parsec In-Reply-To: <20857293.post@talk.nabble.com> (ben a.'s message of "Fri\, 5 Dec 2008 08\:14\:44 -0800 \(PST\)") References: <20857293.post@talk.nabble.com> Message-ID: "ben.a" writes: [...] > "LC.app : 0 , 2 22. abs : 1 ." [...] > line = do > spaces > constru <- word > spaces > (char ':') > spaces > ar <- sepBy number separator > return (constru, ar) [...] > -------- a separator between two integers is a space or a comma > separator :: Parser () > separator = skipMany1 (space <|> char ',') the culprit is "sepBy number separator": for things like "1 2 " it will read a separator, and so will wait for the next number, and won't expect eol. replace "sepBy number separator" with "endBy number separator" and see it will work. this is quite ugly though since it allows "xxx : 1, ." a better solution could be to use: separated_numbers1 :: Parser [Integer] separated_numbers1 = do x <- number spaces xs <- (char ',' >> spaces >> separated_numbers1) <|> option [] separated_numbers1 return (x : xs) From benedikt.ahrens at web.de Mon Dec 8 08:22:47 2008 From: benedikt.ahrens at web.de (ben.a) Date: Mon Dec 8 08:15:52 2008 Subject: treating spaces with Parsec In-Reply-To: References: <20857293.post@talk.nabble.com> Message-ID: <20895257.post@talk.nabble.com> The solution you suggested works really fine. Thanks a lot for your effort. ben Pixel-2 wrote: > > "ben.a" writes: > > [...] > >> "LC.app : 0 , 2 22. abs : 1 ." > > [...] > >> line = do >> spaces >> constru <- word >> spaces >> (char ':') >> spaces >> ar <- sepBy number separator >> return (constru, ar) > > [...] > >> -------- a separator between two integers is a space or a comma >> separator :: Parser () >> separator = skipMany1 (space <|> char ',') > > the culprit is "sepBy number separator": for things like "1 2 " it > will read a separator, and so will wait for the next number, and won't > expect eol. > > replace "sepBy number separator" with "endBy number separator" and see > it will work. > > this is quite ugly though since it allows "xxx : 1, ." > > > a better solution could be to use: > > separated_numbers1 :: Parser [Integer] > separated_numbers1 = > do x <- number > spaces > xs <- (char ',' >> spaces >> separated_numbers1) <|> option [] > separated_numbers1 > return (x : xs) > -- View this message in context: http://www.nabble.com/treating-spaces-with-Parsec-tp20857293p20895257.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From isaacdupree at charter.net Mon Dec 8 20:42:15 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Dec 8 20:35:23 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd In-Reply-To: References: <2608b8a80812020318g487372ccvf701dba37fde995c@mail.gmail.com> <404396ef0812020328k2e68f233s7c44ad9cc743c127@mail.gmail.com> <2608b8a80812020401w5115c0aete1b5ce71d2b78bcc@mail.gmail.com> Message-ID: <493DCCF7.5060700@charter.net> Bart Massey wrote: > There's only two possibilities that make sense to me: (1) do > what I did and call the three functions in question nub, > nubOrd, and nubInt, or (2) call them all nub. it would be possible to do both: for example, export it as both "nub" and "nubInt" from IntMap. But if that seems too silly, I vote for (1) -Isaac From niklas.broberg at gmail.com Tue Dec 9 19:53:09 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Dec 9 19:46:15 2008 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.4 In-Reply-To: <1228832307.10115.417.camel@localhost> References: <1228832307.10115.417.camel@localhost> Message-ID: (CC libraries) > So when will we simply declare that haskell-src-exts is the new > haskell-src? :-) I talked about this with Ross Paterson at one point, and his main objection (which I very much agree with) was that haskell-src-exts doesn't let you *optionally* handle extensions, so in some cases valid H98 programs will be discarded due to syntax stealing (e.g. $x from TH). I've had ideas for how to fix this shortcoming for a long while, but never really had the time to actually implement it. It is still my hope and goal that haskell-src-exts will replace the haskell-src package, when it is ready to do so. What do others think about this? Cheers, /Niklas From jpm at cs.uu.nl Thu Dec 11 03:43:14 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Dec 11 03:36:12 2008 Subject: [Hs-Generics] RE: Generics In-Reply-To: <404396ef0811270417k5cf4ab93kd12e40b52ccc0f12@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811270417k5cf4ab93kd12e40b52ccc0f12@mail.gmail.com> Message-ID: <52f14b210812110043o74927a7frea5236af0529006a@mail.gmail.com> Hello Neil, On Thu, Nov 27, 2008 at 13:17, Neil Mitchell wrote: > Hi Jos?, > > You may also want to weigh in on this issue: > > http://hackage.haskell.org/trac/ghc/ticket/2782 > > The instance of Ratio changed between 6.10 and 6.8 in a way that means > a program can't reflect on the fields contained within the :% > constructor using the value undefined. The reason is that :% is marked > as strict in both arguments, so _|_ :% _|_ == _|_. This breaks > Uniplate, and I've had to explicitly make a test for a type of > Rational in the Uniplate code - which is ugly. I'm not sure how many > other programs this might break - or if the impact was well understood > when the change was made. > > This change is made massively worse by giving the error message > "undefined" when it fails! If an SYB using program goes from working > in GHC 6.8 to failing in GHC 6.10 with "undefined", this may be a > culprit. I see that this in particular has been fixed already. > > > I'm not sure there is a nice solution - reflection at the type level > (using _|_ at the value level), combined with strictness at the value > level, has limitations. It may be that the reflection machinery in SYB > can be tweaked to either alert the user in advance (i.e. by getting > the strictness of various fields), or providing some operation > combining gmapQ and fromConstr which isn't strict. To see my use case > take a look at "contains" in: > > http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs I'm not sure there's an easy solution either. As you say, the problem here seems to be caused by the strictness. Getting the strictness of each field would require changes to the representation types and to the deriving mechanism. Would your problem be solved if you used fromConstrB instead of simply fromConstr and built an entirely determined (without bottoms) value? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081211/61156726/attachment-0001.htm From ndmitchell at gmail.com Thu Dec 11 03:49:12 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Dec 11 03:42:10 2008 Subject: [Hs-Generics] RE: Generics In-Reply-To: <52f14b210812110043o74927a7frea5236af0529006a@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811270417k5cf4ab93kd12e40b52ccc0f12@mail.gmail.com> <52f14b210812110043o74927a7frea5236af0529006a@mail.gmail.com> Message-ID: <404396ef0812110049v620d0902i4beb657737c36126@mail.gmail.com> Hi Pedro, >> I'm not sure there is a nice solution - reflection at the type level >> (using _|_ at the value level), combined with strictness at the value >> level, has limitations. It may be that the reflection machinery in SYB >> can be tweaked to either alert the user in advance (i.e. by getting >> the strictness of various fields), or providing some operation >> combining gmapQ and fromConstr which isn't strict. To see my use case >> take a look at "contains" in: >> >> http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs > > I'm not sure there's an easy solution either. As you say, the problem here > seems to be caused by the strictness. Getting the strictness of each field > would require changes to the representation types and to the deriving > mechanism. > > Would your problem be solved if you used fromConstrB instead of simply > fromConstr and built an entirely determined (without bottoms) value? I might be able to use fromConstrB, but it requires a lot more work - initialising lots of things and creating lots of dummy values. I'll look into it. I also note that the documentation for fromConstrB seems to have disappeared. See: http://haskell.org/ghc/docs/latest/html/libraries/syb/doc-index.html - the entry is still there but the link is gone. (I'm also aware that the Hoogle documentation for it is missing, but hope to fix that this weekend - I've had issues trying to build things) Thanks Neil From jpm at cs.uu.nl Thu Dec 11 03:53:48 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Dec 11 03:46:47 2008 Subject: [Hs-Generics] RE: Generics In-Reply-To: <404396ef0812110049v620d0902i4beb657737c36126@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811270417k5cf4ab93kd12e40b52ccc0f12@mail.gmail.com> <52f14b210812110043o74927a7frea5236af0529006a@mail.gmail.com> <404396ef0812110049v620d0902i4beb657737c36126@mail.gmail.com> Message-ID: <52f14b210812110053n13f16b1eg581d5e062b5c2881@mail.gmail.com> Hello Neil, On Thu, Dec 11, 2008 at 09:49, Neil Mitchell wrote: > Hi Pedro, > > >> I'm not sure there is a nice solution - reflection at the type level > >> (using _|_ at the value level), combined with strictness at the value > >> level, has limitations. It may be that the reflection machinery in SYB > >> can be tweaked to either alert the user in advance (i.e. by getting > >> the strictness of various fields), or providing some operation > >> combining gmapQ and fromConstr which isn't strict. To see my use case > >> take a look at "contains" in: > >> > >> http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs > > > > I'm not sure there's an easy solution either. As you say, the problem > here > > seems to be caused by the strictness. Getting the strictness of each > field > > would require changes to the representation types and to the deriving > > mechanism. > > > > Would your problem be solved if you used fromConstrB instead of simply > > fromConstr and built an entirely determined (without bottoms) value? > > I might be able to use fromConstrB, but it requires a lot more work - > initialising lots of things and creating lots of dummy values. I'll > look into it. Would this help? {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE FlexibleContexts #-} > > module Data.Generics.Builders (empty) where > > import Data.Data > import Data.Generics.Aliases (extB) > > -- | Construct the empty value for a datatype. For algebraic datatypes, the > -- leftmost constructor is chosen. > empty :: forall a. Data a => a > empty = general > `extB` char > `extB` int > `extB` integer > `extB` float > `extB` double where > -- Generic case > general :: Data a => a > general = fromConstrB empty (indexConstr (dataTypeOf general) 1) > > -- Base cases > char = '\NUL' > int = 0 :: Int > integer = 0 :: Integer > float = 0.0 :: Float > double = 0.0 :: Double > > > I also note that the documentation for fromConstrB seems to have > disappeared. See: > http://haskell.org/ghc/docs/latest/html/libraries/syb/doc-index.html - > the entry is still there but the link is gone. fromConstrB is not in the syb package. It's in base4, in Data.Data: http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Data.html#v%3AfromConstrB Thanks, Pedro > > > (I'm also aware that the Hoogle documentation for it is missing, but > hope to fix that this weekend - I've had issues trying to build > things) > > Thanks > > Neil > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081211/7e57b321/attachment.htm From ndmitchell at gmail.com Thu Dec 11 03:57:26 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Dec 11 03:50:22 2008 Subject: [Hs-Generics] RE: Generics In-Reply-To: <52f14b210812110053n13f16b1eg581d5e062b5c2881@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811270417k5cf4ab93kd12e40b52ccc0f12@mail.gmail.com> <52f14b210812110043o74927a7frea5236af0529006a@mail.gmail.com> <404396ef0812110049v620d0902i4beb657737c36126@mail.gmail.com> <52f14b210812110053n13f16b1eg581d5e062b5c2881@mail.gmail.com> Message-ID: <404396ef0812110057g45d08067q69ff8272d13d6408@mail.gmail.com> HI Pedro, > Would this help? > >> {-# LANGUAGE ScopedTypeVariables #-} >> {-# LANGUAGE FlexibleContexts #-} >> >> module Data.Generics.Builders (empty) where >> >> import Data.Data >> import Data.Generics.Aliases (extB) >> >> -- | Construct the empty value for a datatype. For algebraic datatypes, >> the >> -- leftmost constructor is chosen. >> empty :: forall a. Data a => a >> empty = general >> `extB` char >> `extB` int >> `extB` integer >> `extB` float >> `extB` double where >> -- Generic case >> general :: Data a => a >> general = fromConstrB empty (indexConstr (dataTypeOf general) 1) >> >> -- Base cases >> char = '\NUL' >> int = 0 :: Int >> integer = 0 :: Integer >> float = 0.0 :: Float >> double = 0.0 :: Double Yep, that should do it! Many thanks Neil From jpm at cs.uu.nl Thu Dec 11 04:00:11 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Dec 11 03:53:08 2008 Subject: [Hs-Generics] RE: Generics In-Reply-To: <404396ef0812110057g45d08067q69ff8272d13d6408@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0811270417k5cf4ab93kd12e40b52ccc0f12@mail.gmail.com> <52f14b210812110043o74927a7frea5236af0529006a@mail.gmail.com> <404396ef0812110049v620d0902i4beb657737c36126@mail.gmail.com> <52f14b210812110053n13f16b1eg581d5e062b5c2881@mail.gmail.com> <404396ef0812110057g45d08067q69ff8272d13d6408@mail.gmail.com> Message-ID: <52f14b210812110100h680a963v942a5d4462724f4b@mail.gmail.com> On Thu, Dec 11, 2008 at 09:57, Neil Mitchell wrote: > HI Pedro, > > > Would this help? > > > >> {-# LANGUAGE ScopedTypeVariables #-} > >> {-# LANGUAGE FlexibleContexts #-} > >> > >> module Data.Generics.Builders (empty) where > >> > >> import Data.Data > >> import Data.Generics.Aliases (extB) > >> > >> -- | Construct the empty value for a datatype. For algebraic datatypes, > >> the > >> -- leftmost constructor is chosen. > >> empty :: forall a. Data a => a > >> empty = general > >> `extB` char > >> `extB` int > >> `extB` integer > >> `extB` float > >> `extB` double where > >> -- Generic case > >> general :: Data a => a > >> general = fromConstrB empty (indexConstr (dataTypeOf general) 1) > >> > >> -- Base cases > >> char = '\NUL' > >> int = 0 :: Int > >> integer = 0 :: Integer > >> float = 0.0 :: Float > >> double = 0.0 :: Double > > Yep, that should do it! It's slated for release with the next version of the SYB library, so in a near future you'll only need to import it. Cheers, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081211/1e666c68/attachment.htm From igloo at earth.li Thu Dec 11 09:35:11 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Dec 11 09:28:08 2008 Subject: extralibs and the haskell-platform Message-ID: <20081211143511.GA9331@matrix.chaos.earth.li> Hi all, As the plan is for the extralibs to become part of the Haskell Platform, I think we ought to have a BTS for them. I therefore propose that we create a project on community.haskell.org for each of those that are maintained by libraries@haskell.org. For now that will only provide a BTS (trac), but once the GHC VCS switch has happened it would make sense to move the authoritative darcs repos to community too. The packages in question are: haskell-src html HUnit mtl network parallel stm (I've left QuickCheck off as I think that it has real maintainers again) Also, I've created a haskell-platform mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Currently it gets mail for any changes to the haskell-platform trac, but I think that it makes sense to send mail for all the HP package tracs there too, so you don't need to subscribe to dozens of low-traffic lists to keep on top of what's going on. If the volume becomes too high then we can move the noisier packages to their own list. For now at least, discussion should stay on libraries@haskell.org. Any comments/objections? Thanks Ian From jpm at cs.uu.nl Thu Dec 11 10:06:50 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Dec 11 09:59:48 2008 Subject: Proposal #2875: Correct SYB's representation of Char Message-ID: <52f14b210812110706g53cf284agc752570821ace133@mail.gmail.com> Hello all, SYB uses DataRep to represent datatypes: -- | Public representation of datatypes data DataRep = AlgRep [Constr] | IntRep | FloatRep | StringRep | NoRep I believe that StringRep should be CharRep. Note that IntRep is used for the primitive Int and Integer datatypes, FloatRep for Float and Double, and StringRep (apparently) for Char. String, however, is represented as AlgRep [[],(:)]: *Main> dataTypeOf 'p' DataType {tycon = "Prelude.Char", datarep = StringRep} *Main> dataTypeOf "p" DataType {tycon = "Prelude.[]", datarep = AlgRep [[],(:)]} This makes sense, since String is not a primitive datatype. But it causes the apparently wrong behavior: *Main> fromConstr (mkStringConstr (dataTypeOf "a") "ab") :: String "*** Exception: mkStringConstr *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: String "*** Exception: constrIndex The correct way of using mkStringConstr is to construct a Char. This, however, only works for strings with a single character: *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "b") :: Char 'b' *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: Char *** Exception: gunfold *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "") :: Char *** Exception: gunfold I find this behavior counterintuitive. Therefore I propose to rename StringRep to CharRep and mkStringConstr to mkCharConstr. For backwards compatibility, this entails: * Deprecating mkStringConstr and StringConstr * Deprecating mkStringRep and StringRep * Introducing mkCharConstr and CharConstr * Introducing mkCharRep and CharRep Additionally, due to deprecation warnings, the following have to change as well: * libraries/template-haskell/Language/Haskell/TH/Quote.hs * compiler/utils/Serialized.hs A patch is attached in #2875 ( http://hackage.haskell.org/trac/ghc/ticket/2875). I propose a discussion period of 4 weeks, therefore until the 8th of January. Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081211/c4bef831/attachment-0001.htm From ndmitchell at gmail.com Thu Dec 11 10:16:29 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Dec 11 10:09:26 2008 Subject: [Hs-Generics] Proposal #2875: Correct SYB's representation of Char In-Reply-To: <52f14b210812110706g53cf284agc752570821ace133@mail.gmail.com> References: <52f14b210812110706g53cf284agc752570821ace133@mail.gmail.com> Message-ID: <404396ef0812110716q19b6b770sa18f48ac18f86e0f@mail.gmail.com> Hi, I agree with the idea. However, remember that this won't be fully backwards compatible as anyone who performs a pattern match will now get a crash. Given that, I think I'd be more in favour of renaming StringRep to CharRep in one single step, otherwise you are going to allow the old code to compile fine and crash at runtime. Having mkStringRep be deprecated is a good idea though. Thanks Neil On Thu, Dec 11, 2008 at 3:06 PM, Jos? Pedro Magalh?es wrote: > Hello all, > > SYB uses DataRep to represent datatypes: > > -- | Public representation of datatypes > data DataRep = AlgRep [Constr] > | IntRep > | FloatRep > | StringRep > | NoRep > > I believe that StringRep should be CharRep. Note that IntRep is used for the > primitive Int and Integer datatypes, FloatRep for Float and Double, and > StringRep (apparently) for Char. String, however, is represented as AlgRep > [[],(:)]: > > *Main> dataTypeOf 'p' > DataType {tycon = "Prelude.Char", datarep = StringRep} > *Main> dataTypeOf "p" > DataType {tycon = "Prelude.[]", datarep = AlgRep [[],(:)]} > > This makes sense, since String is not a primitive datatype. But it causes > the apparently wrong behavior: > > *Main> fromConstr (mkStringConstr (dataTypeOf "a") "ab") :: String > "*** Exception: mkStringConstr > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: String > "*** Exception: constrIndex > > The correct way of using mkStringConstr is to construct a Char. This, > however, only works for strings with a single character: > > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "b") :: Char > 'b' > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: Char > *** Exception: gunfold > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "") :: Char > *** Exception: gunfold > > I find this behavior counterintuitive. Therefore I propose to rename > StringRep to CharRep and mkStringConstr to mkCharConstr. For backwards > compatibility, this entails: > > * Deprecating mkStringConstr and StringConstr > * Deprecating mkStringRep and StringRep > * Introducing mkCharConstr and CharConstr > * Introducing mkCharRep and CharRep > > Additionally, due to deprecation warnings, the following have to change as > well: > > * libraries/template-haskell/Language/Haskell/TH/Quote.hs > * compiler/utils/Serialized.hs > > A patch is attached in #2875 > (http://hackage.haskell.org/trac/ghc/ticket/2875). I propose a discussion > period of 4 weeks, therefore until the 8th of January. > > > Thanks, > Pedro > > _______________________________________________ > Generics mailing list > Generics@haskell.org > http://www.haskell.org/mailman/listinfo/generics > > From duncan.coutts at worc.ox.ac.uk Thu Dec 11 18:22:17 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Dec 11 18:15:27 2008 Subject: extralibs and the haskell-platform In-Reply-To: <20081211143511.GA9331@matrix.chaos.earth.li> References: <20081211143511.GA9331@matrix.chaos.earth.li> Message-ID: <1229037737.10115.586.camel@localhost> On Thu, 2008-12-11 at 14:35 +0000, Ian Lynagh wrote: > Hi all, > > As the plan is for the extralibs to become part of the Haskell Platform, > I think we ought to have a BTS for them. I therefore propose that we > create a project on community.haskell.org for each of those that are > maintained by libraries@haskell.org. For now that will only provide a > BTS (trac), but once the GHC VCS switch has happened it would make sense > to move the authoritative darcs repos to community too. > > The packages in question are: > haskell-src > html > HUnit > mtl > network > parallel > stm > (I've left QuickCheck off as I think that it has real maintainers again) We want all packages that are part of the platform to have a place to report bugs. The .cabal file can now specify a bug-reports: url. This does not need to be a full blown bug tracker, an email address will do. The important point is that users and people coordinating the platform release know where to direct bug reports. For the packages that have no obvious maintainer setting up our own trac instances for them is the obvious thing to do. > Also, I've created a haskell-platform mailing list: > http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform > Currently it gets mail for any changes to the haskell-platform trac, but > I think that it makes sense to send mail for all the HP package tracs > there too, so you don't need to subscribe to dozens of low-traffic lists > to keep on top of what's going on. If the volume becomes too high then > we can move the noisier packages to their own list. For now at least, > discussion should stay on libraries@haskell.org. Yes, policy decisions on libraries@haskell.org and the mechanics on the separate haskell-platform mailing list. > Any comments/objections? That's great. From valery.vv at gmail.com Fri Dec 12 09:05:45 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Fri Dec 12 08:59:32 2008 Subject: cabal-install sends invalid proxy password Message-ID: Dear lazy programmers, I was surprised to discover that `cabal-install' -- a popular utility for installing Hackage packages -- cannot work with HTTP proxies. Despite all the necessary code linked in. `cabal update' command returns HTTP 407 (Proxy Authentication Required) error. The problem is explained below and patches follow. * * * Our office LAN has an HTTP proxy server with authorization. And my shell environment has a variable like http_proxy='http://user:password@proxyhost:proxyport/' tcpdump-ing shows that `cabal update' sends invalid credentials in HTTP "CONNECT" request. The proper string would be "user:password" (base64-encoded) while `cabal' sends "user:password@". There's no surprise proxy server denies connection! I've traced the problem down to `userinfo' function, defined in network-2.2.0.1/Network/URI.hs:451: > -- RFC3986, section 3.2.1 > > userinfo :: URIParser String > userinfo = > do { uu <- many (uchar ";:&=+$,") > ; char '@' > ; return (concat uu ++"@") > } Let us see section 3.2 of RFC3986: > authority = [ userinfo "@" ] host [ ":" port ] > [... > ...] The user information, if present, is followed by a > commercial at-sign ("@") that delimits it from the host. There is no reason for "@" character to be a part of `userinfo' expression. * * * So, the Right Way(TM) to make cabal-install go through proxies is fixing `userinfo' function of `network' package (see the `network-2.2.0.1.patch'). Until then, we should have a workaround in `cabal-install' (cabal-install-0.6.0.patch). I do. Happy hacking! -- vvv -------------- next part -------------- A non-text attachment was scrubbed... Name: network-2.2.0.1.patch Type: application/octet-stream Size: 1598 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20081212/6ca19fe0/network-2.2.0.1.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-install-0.6.0.patch Type: application/octet-stream Size: 799 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20081212/6ca19fe0/cabal-install-0.6.0.obj From byorgey at seas.upenn.edu Tue Dec 16 12:13:36 2008 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Tue Dec 16 12:06:17 2008 Subject: old-time missing configure script? Message-ID: <20081216171335.GA927@seas.upenn.edu> Hi all, Does anyone know what is going on with the 'old-time' package? When I try installing it from Hackage via cabal-install, I get the error Configuring old-time-1.0.0.0... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. cabal: configure script not found. cabal: Error: some packages failed to install: old-time-1.0.0.0 failed during the configure step. The exception was: exit: ExitFailure 1 And indeed, the build-type is specified as Configure but there is no configure script included. -Brent From benjovi at gmx.net Tue Dec 16 19:56:47 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Tue Dec 16 19:49:35 2008 Subject: possible bug in pretty-1.0.1.0 In-Reply-To: <20081215161756.GA29082@berkeley.edu> References: <20081215161756.GA29082@berkeley.edu> Message-ID: <49484E4F.7020506@gmx.net> John MacFarlane schrieb: > I noticed a difference in how "hang" works between pretty-1.0.0.0 and > pretty-1.0.1.0. I think it's a bug. If this isn't the right place to > report it, please let me know where I should. (Maintainer is listed > as libraries@haskell.org, but that is a closed mailing list. Perhaps > Cabal should include a report-bugs-at field?) > > John > > GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help > ... > Prelude Text.PrettyPrint> putStrLn $ render $ hang (char '*') 4 (text "hi" $$ text "there") > Loading package pretty-1.0.0.0 ... linking ... done. > * hi > there > > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > ... > Prelude Text.PrettyPrint> putStrLn $ render $ hang (char '*') 4 (text "hi" $$ text "there") > Loading package pretty-1.0.1.0 ... linking ... done. > * > hi > there Hi John, I think you're right, from the perspective of 'hang' the last set of patches (http://hackage.haskell.org/trac/ghc/ticket/2393) indeed introduced a bug. Unfortunately a good description of what hang is _intended_ to mean is still missing in the documentation, but I'll assume that > hang (text "*") 4 (sep [ text "hi", text "there" ]) should either layout as > * hi there or > * hi > there If only the second layout is of interest (like in your example), then > hang' d1 n d2 = d1 $$ (nest n d2) should do the job. Related issue, we changed vcat to mean (foldr $+$ empty) instead of (foldr $$ empty) - either revert this change or update the documentation ? [1] Unfortunately, the situations is a bit trickier for hang (i.e. for sep[A, nest n B]); allowing overlap violates Invariant 7: The first line of the first layout has to be longer than the first line of the second layout because > sep [A, nest n B] ~ > oneLiner (A <+> B) `union` A $$ (nest n B) > with e.g. [A="a",B="b",n="4"] > "a b" `union` "a b" which causes the pretty printer to select an even longer! line if (A <+> B) doesn't fit on one line. I'm not sure how to resolve this - should sep [A, B] really overlap A and B if they do not fit on a line ??? Still, if it seems to be the right thing to do, it is easy to allow overlap in sep/cat. Otherwise hang might need to be changed. best regards, benedikt [1] Either hunk ./Text/PrettyPrint/HughesPJ.hs 114 - vcat is a list version of $$ + vcat is a list version of $+$ hunk ./Text/PrettyPrint/HughesPJ.hs 316 -vcat :: [Doc] -> Doc; -- ^List version of '$$'. +vcat :: [Doc] -> Doc; -- ^List version of '$+$'. or hunk ./Text/PrettyPrint/HughesPJ.hs 497 -vcat = reduceAB . foldr (above_' True) empty +vcat = reduceAB . foldr (above_' False) empty because of 505: above_' g p q = Above p g q 536: | Above Doc Bool Doc -- True <=> never overlap From dominic.steinitz at blueyonder.co.uk Wed Dec 17 05:17:32 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Wed Dec 17 05:10:24 2008 Subject: cabal-install sends invalid proxy password References: Message-ID: Valery V. Vorotyntsev gmail.com> writes: > > Dear lazy programmers, > > I was surprised to discover that `cabal-install' -- a popular utility > for installing Hackage packages -- cannot work with HTTP proxies. > Despite all the necessary code linked in. > > `cabal update' command returns HTTP 407 (Proxy Authentication Required) > error. The problem is explained below and patches follow. > I just tripped over the same problem yesterday so your patch saved me a lot of debugging. Dominic. From valery.vv at gmail.com Wed Dec 17 08:36:19 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Wed Dec 17 08:29:30 2008 Subject: cabal-install sends invalid proxy password In-Reply-To: References: Message-ID: On Wed, Dec 17, 2008 at 12:17 PM, Dominic Steinitz wrote: > > I just tripped over the same problem yesterday so your patch saved me a lot of > debugging. That's nice! Thanks for feedback. -- vvv From jpm at cs.uu.nl Wed Dec 17 08:37:12 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Wed Dec 17 08:29:50 2008 Subject: [Hs-Generics] Proposal #2875: Correct SYB's representation of Char In-Reply-To: <404396ef0812110716q19b6b770sa18f48ac18f86e0f@mail.gmail.com> References: <52f14b210812110706g53cf284agc752570821ace133@mail.gmail.com> <404396ef0812110716q19b6b770sa18f48ac18f86e0f@mail.gmail.com> Message-ID: <52f14b210812170537u27fa1e60hb65c6d3f8cbd4ac@mail.gmail.com> On Thu, Dec 11, 2008 at 16:16, Neil Mitchell wrote: > Hi, > > I agree with the idea. However, remember that this won't be fully > backwards compatible as anyone who performs a pattern match will now > get a crash. Given that, I think I'd be more in favour of renaming > StringRep to CharRep in one single step, otherwise you are going to > allow the old code to compile fine and crash at runtime. Having > mkStringRep be deprecated is a good idea though. It would still warn about the use of deprecated StringRep (and also a non-exaustive pattern match with -Wall). But I won't oppose to changing it in one go. But then mkStringRep would disappear? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081217/3f887717/attachment-0001.htm From ndmitchell at gmail.com Wed Dec 17 08:41:22 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Dec 17 08:33:59 2008 Subject: [Hs-Generics] Proposal #2875: Correct SYB's representation of Char In-Reply-To: <52f14b210812170537u27fa1e60hb65c6d3f8cbd4ac@mail.gmail.com> References: <52f14b210812110706g53cf284agc752570821ace133@mail.gmail.com> <404396ef0812110716q19b6b770sa18f48ac18f86e0f@mail.gmail.com> <52f14b210812170537u27fa1e60hb65c6d3f8cbd4ac@mail.gmail.com> Message-ID: <404396ef0812170541s53a21f9ct263fcfa8b583daa0@mail.gmail.com> Hi >> I agree with the idea. However, remember that this won't be fully >> backwards compatible as anyone who performs a pattern match will now >> get a crash. Given that, I think I'd be more in favour of renaming >> StringRep to CharRep in one single step, otherwise you are going to >> allow the old code to compile fine and crash at runtime. Having >> mkStringRep be deprecated is a good idea though. > > It would still warn about the use of deprecated StringRep (and also a > non-exaustive pattern match with -Wall). Yes, but you'd have to have either the deprecated warning or the non-exhaustive pattern. > But I won't oppose to changing it > in one go. But then mkStringRep would disappear? No, its a function, deprecate it, but leave it present. Constructors are different - two constructors for one purpose is an absolute pain. Functions can come and go, and can duplicate functionality without any trouble. Thanks Neil From duncan.coutts at worc.ox.ac.uk Thu Dec 18 07:57:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Dec 18 07:50:05 2008 Subject: [Haskell] possible bug in pretty-1.0.1.0 In-Reply-To: <20081215161756.GA29082@berkeley.edu> References: <20081215161756.GA29082@berkeley.edu> Message-ID: <1229605050.10115.690.camel@localhost> On Mon, 2008-12-15 at 08:17 -0800, John MacFarlane wrote: > I noticed a difference in how "hang" works between pretty-1.0.0.0 and > pretty-1.0.1.0. I think it's a bug. If this isn't the right place to > report it, please let me know where I should. (Maintainer is listed > as libraries@haskell.org, but that is a closed mailing list. Perhaps > Cabal should include a report-bugs-at field?) I'd just like to advertise the fact that as of Cabal-1.6 you can put a bug-reports field in your .cabal file and it will be displayed by hackage. We would like to encourage all package authors to use this. It can be a mailto: url to a maintainer or mailing list or it can be a http: url to a bug tracker website. (Cabal-1.6 also supports specifying darcs/git/whatever repos) Duncan From ndmitchell at gmail.com Thu Dec 18 08:27:57 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Dec 18 08:20:39 2008 Subject: [Haskell] possible bug in pretty-1.0.1.0 In-Reply-To: <1229605050.10115.690.camel@localhost> References: <20081215161756.GA29082@berkeley.edu> <1229605050.10115.690.camel@localhost> Message-ID: <404396ef0812180527v7f46869ax425c003215225a3d@mail.gmail.com> Hi Duncan, > I'd just like to advertise the fact that as of Cabal-1.6 you can put a > bug-reports field in your .cabal file and it will be displayed by > hackage. Fantastic. Is it backwards compatible? i.e. if I add such a field, will Cabal-1.2 give warnings/errors? Thanks Neil From duncan.coutts at worc.ox.ac.uk Thu Dec 18 10:32:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Dec 18 10:25:08 2008 Subject: [Haskell] possible bug in pretty-1.0.1.0 In-Reply-To: <404396ef0812180527v7f46869ax425c003215225a3d@mail.gmail.com> References: <20081215161756.GA29082@berkeley.edu> <1229605050.10115.690.camel@localhost> <404396ef0812180527v7f46869ax425c003215225a3d@mail.gmail.com> Message-ID: <1229614344.10115.691.camel@localhost> On Thu, 2008-12-18 at 13:27 +0000, Neil Mitchell wrote: > Hi Duncan, > > > I'd just like to advertise the fact that as of Cabal-1.6 you can put a > > bug-reports field in your .cabal file and it will be displayed by > > hackage. > > Fantastic. Is it backwards compatible? i.e. if I add such a field, > will Cabal-1.2 give warnings/errors? It should give warnings but not errors. Unfortunately for the source repo stuff that uses a new section which the old parser did not handle quite so gracefully. Duncan From duncan.coutts at worc.ox.ac.uk Thu Dec 18 11:54:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Dec 18 11:46:56 2008 Subject: cabal-install sends invalid proxy password In-Reply-To: References: Message-ID: <1229619250.10115.696.camel@localhost> On Fri, 2008-12-12 at 16:05 +0200, Valery V. Vorotyntsev wrote: > Dear lazy programmers, > > I was surprised to discover that `cabal-install' -- a popular utility > for installing Hackage packages -- cannot work with HTTP proxies. > Despite all the necessary code linked in. Thanks for reporting this. As you guessed, we've never tested it with a proxy that requires authentication. > So, the Right Way(TM) to make cabal-install go through proxies is > fixing `userinfo' function of `network' package (see the > `network-2.2.0.1.patch'). Good work. We should have this reviewed by the maintainers of the network package. > Until then, we should have a workaround in > `cabal-install' (cabal-install-0.6.0.patch). I do. Thanks, I'll apply that patch. Looking at the code it looks like it will not break when the proper fix is applied to the url code in the network package. Do you agree? Duncan From valery.vv at gmail.com Thu Dec 18 14:25:00 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Thu Dec 18 14:17:34 2008 Subject: cabal-install sends invalid proxy password In-Reply-To: <1229619250.10115.696.camel@localhost> References: <1229619250.10115.696.camel@localhost> Message-ID: On 12/18/08, Duncan Coutts wrote: > > So, the Right Way(TM) to make cabal-install go through proxies is > > fixing `userinfo' function of `network' package (see the > > `network-2.2.0.1.patch'). > > Good work. We should have this reviewed by the maintainers of the > network package. > > > Until then, we should have a workaround in > > `cabal-install' (cabal-install-0.6.0.patch). I do. > > Thanks, I'll apply that patch. Looking at the code it looks like it will > not break when the proper fix is applied to the url code in the network > package. Do you agree? It will not break. It will degrade from "savior" into "harmless cruft". And when we are sure that `network' package is fixed, we should revert `cabal-install-0.6.0.patch'. Thank you, Duncan! -- vvv From v.dijk.bas at gmail.com Sat Dec 20 13:09:49 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Sat Dec 20 13:02:17 2008 Subject: Add Applicative instances for MTL types Message-ID: Hello, In a project of mine I needed an Applicative instance for Identity and noticed it didn't exist. So I decided to add Applicative (and Alternative instances where possible) for all MTL types. When I was about to submit a library proposal I saw there already existed one. So I added my patch to that ticket. My patch I different in that my Applicative instances don't require a Monad constraint. This also means that most Functor instances now also depend on Applicative rather than on Monad. See the ticket for the details: http://hackage.haskell.org/trac/ghc/ticket/2316 Discussion period: 5 weeks (taking the holidays into account) This is the old thread about this proposal: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9140/focus=9154 regards, Bas From nicolas.frisby at gmail.com Mon Dec 22 13:19:44 2008 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Mon Dec 22 13:12:04 2008 Subject: blame: mtl MonadReader instance for ContT Message-ID: <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> This mtl instance is in conflict with a usage of shift/reset that I'm porting from ML (Sheard's type-directed partial evaluator). > instance (MonadReader r' m) => MonadReader r' (ContT r m) where > local f m = ContT $ \c -> do > r <- ask > local f (runContT m (local (const r) . c)) I need to remove the "local (const r)" bit. I think this is just a different point in the diverse design space of dynamic binding/delimited control. Since Haskell lacks visibility management for importing instances, I'm forced to duplicate the rest of the ContT code in order to replace this instance with my own. 1) I am hoping this list can recall the reason for putting this design decision into the mtl. Perhaps there's a reason to prefer this particular side-effect interaction. 2) I am suggesting that the mtl be restructured such that this instance be delegated to a separate module so that i) I can avoid importing it along with the other useful instances ii) and the mtl could provide alternative instances. An alternative to breaking out the modules would be to not provide the instance. Another, more radical alternative could involve phantom types. I don't know of any in the mtl, but this same consideration might be applicable to other libraries with "arbitrary" instances. From rfhayes at reillyhayes.com Mon Dec 22 20:58:27 2008 From: rfhayes at reillyhayes.com (R Hayes) Date: Mon Dec 22 20:50:49 2008 Subject: [Haskell-cafe] Cabal Install & Links to Source from Haddock Docs In-Reply-To: <910ddf450812210111o5968073bm7d904107259ee7d6@mail.gmail.com> References: <910ddf450812210111o5968073bm7d904107259ee7d6@mail.gmail.com> Message-ID: Thank you. As it turns out, I was aware of that recipe. What I wanted was to be able to use cabal install's nice dependency following features and still get source links in my documentation. Personally, I feel that inclusion of source and docs should be the DEFAULT for cabal, as well as for binary distributions of ghc. -rhayes On Dec 21, 2008, at 1:11 AM, Thomas Hartman wrote: > the answer: not cabal install, just cabal. > > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3> > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3>cabal > --help | grep -i doc > haddock Generate Haddock HTML documentation. > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3>cabal > haddock --help | grep -i link > --hyperlink-source Hyperlink the documentation to the source > code > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3>cabal > haddock --hyperlink-source > > 2008/12/21 R Hayes : >> >> Is there a way I can get Haddock Docs WITH links to source (local) >> from >> modules installed with "cabal install xxx"? >> >> Getting the docs themselves is pretty easy by changing either >> ~/.cabal/config or using --enable-documentation. >> >> Automatically generating the source (colourised or not) and >> integrated links >> eludes me. >> >> -r >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From duncan.coutts at worc.ox.ac.uk Tue Dec 23 07:38:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Dec 23 07:31:38 2008 Subject: [Haskell-cafe] Cabal Install & Links to Source from Haddock Docs In-Reply-To: References: <910ddf450812210111o5968073bm7d904107259ee7d6@mail.gmail.com> Message-ID: <1230035931.11245.3.camel@localhost> On Mon, 2008-12-22 at 17:58 -0800, R Hayes wrote: > Thank you. As it turns out, I was aware of that recipe. What I > wanted was to be able to use cabal install's nice dependency following > features and still get source links in my documentation. Due to popular demand we quickly added the --enable-documentation flag but did not manage to agree a design for exposing the other haddock/documentation flags via cabal install. We'd appreciate if you could add your suggestions for the design of the command line interface to this ticket: http://hackage.haskell.org/trac/hackage/ticket/206 > Personally, I feel that inclusion of source and docs should be the > DEFAULT for cabal, as well as for binary distributions of ghc. You can set it as a default in the ~/.cabal/config file. Duncan From schlepptop at henning-thielemann.de Tue Dec 23 16:37:07 2008 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Tue Dec 23 16:24:05 2008 Subject: blame: mtl MonadReader instance for ContT In-Reply-To: <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> References: <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> Message-ID: <49515A03.9050904@henning-thielemann.de> Nicolas Frisby schrieb: > This mtl instance is in conflict with a usage of shift/reset that I'm > porting from ML (Sheard's type-directed partial evaluator). > >> instance (MonadReader r' m) => MonadReader r' (ContT r m) where >> local f m = ContT $ \c -> do >> r <- ask >> local f (runContT m (local (const r) . c)) > > I need to remove the "local (const r)" bit. I think this is just a > different point in the diverse design space of dynamic > binding/delimited control. Since Haskell lacks visibility management > for importing instances, I'm forced to duplicate the rest of the ContT > code in order to replace this instance with my own. You may define a newtype, lift all required instances with -XGeneralizedNewtypeDeriving and define your own MonadReader instance. > > 1) I am hoping this list can recall the reason for putting this design > decision into the mtl. Perhaps there's a reason to prefer this > particular side-effect interaction. > > 2) I am suggesting that the mtl be restructured such that this > instance be delegated to a separate module so that > i) I can avoid importing it along with the other useful instances > ii) and the mtl could provide alternative instances. > An alternative to breaking out the modules would be to not provide > the instance. > Another, more radical alternative could involve phantom types. > > I don't know of any in the mtl, but this same consideration might be > applicable to other libraries with "arbitrary" instances. It was discussed in length, that different instances for the same class/type pair leads to trouble sooner or later. (keyword "orphan instances") - Just imagine people who import two instances via two different import paths, then the compiler does not know, which instances to use. Instead newtype is the answer. From lemming at henning-thielemann.de Tue Dec 23 17:23:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Dec 23 17:15:38 2008 Subject: blame: mtl MonadReader instance for ContT In-Reply-To: <49515A03.9050904@henning-thielemann.de> References: <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> <49515A03.9050904@henning-thielemann.de> Message-ID: On Tue, 23 Dec 2008, Henning Thielemann wrote: > Nicolas Frisby schrieb: >> This mtl instance is in conflict with a usage of shift/reset that I'm >> porting from ML (Sheard's type-directed partial evaluator). >> >>> instance (MonadReader r' m) => MonadReader r' (ContT r m) where >>> local f m = ContT $ \c -> do >>> r <- ask >>> local f (runContT m (local (const r) . c)) >> >> I need to remove the "local (const r)" bit. I think this is just a >> different point in the diverse design space of dynamic >> binding/delimited control. Since Haskell lacks visibility management >> for importing instances, I'm forced to duplicate the rest of the ContT >> code in order to replace this instance with my own. > > You may define a newtype, lift all required instances with > -XGeneralizedNewtypeDeriving and define your own MonadReader instance. I have put this on: http://haskell.org/haskellwiki/Multiple_instances From dominic.steinitz at blueyonder.co.uk Wed Dec 24 08:19:55 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Wed Dec 24 08:12:18 2008 Subject: Cabal Bug / Feature and Improvement Message-ID: Currently if I do not want to use the default locations for cabal then the following: >dist\build\cabal\cabal.exe --config-file=urghh --remote-repo-cache=foo --verbose=3 update will create urghh but will still (silently) put the repository cache at repoLocalDir = "C:\\Documents and Settings\\steinitd\\Application Data\\cabal\\packages\\hackage.haskell.org" I've made a few changes which will put the cache at "foo". I don't have access to darcs at the moment so I've attached the changes. Let me know if a darcs patch is worth doing. Dominic. In Config.hs: loadConfig :: Verbosity -> GlobalFlags {-Flag FilePath-} -> Flag Bool -> IO SavedConfig loadConfig verbosity globalFlags {-configFileFlag-} userInstallFlag = addBaseConf $ do configFile <- maybe defaultConfigFile return (flagToMaybe (globalConfigFile globalFlags){-configFileFlag-}) minp <- readConfigFile mempty configFile case minp of Nothing -> do notice verbosity $ "Config file " ++ configFile ++ " not found." notice verbosity $ "Writing default configuration to " ++ configFile commentConf <- commentSavedConfig initialConf <- initialSavedConfig writeConfigFile configFile commentConf (initialConf `mappend` (mempty {savedGlobalFlags = globalFlags})) return initialConf The other cases of loadConfig are unchanged. In Main.hs global replace: loadConfig verbosity (globalConfigFile globalFlags) by loadConfig verbosity globalFlags From duncan.coutts at worc.ox.ac.uk Thu Dec 25 18:47:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Dec 26 14:01:00 2008 Subject: Cabal Bug / Feature and Improvement In-Reply-To: References: Message-ID: <1230248866.11869.27.camel@lantern> On Wed, 2008-12-24 at 13:19 +0000, Dominic Steinitz wrote: > Currently if I do not want to use the default locations for cabal then the > following: > > >dist\build\cabal\cabal.exe --config-file=urghh --remote-repo-cache=foo > --verbose=3 update > > will create urghh but will still (silently) put the repository cache at > > repoLocalDir = "C:\\Documents and Settings\\steinitd\\Application > Data\\cabal\\packages\\hackage.haskell.org" Ah so when the config file does not exist the --remote-repo-cache flag is ignored and the default value from the newly created config file is used instead. > I've made a few changes which will put the cache at "foo". I don't have access > to darcs at the moment so I've attached the changes. Let me know if a > darcs patch is worth doing. Yes please though check that it's not already fixed. I made some changes in that code relatively recently. There are a couple other path settings that are still hard coded and should really be configurable. We should also have a way to operate without any config file at all for install scripts etc. Duncan From dominic.steinitz at blueyonder.co.uk Fri Dec 26 17:03:18 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri Dec 26 17:06:42 2008 Subject: Cabal Bug / Feature and Improvement In-Reply-To: <1230248866.11869.27.camel@lantern> References: <1230248866.11869.27.camel@lantern> Message-ID: <495554A6.9000706@blueyonder.co.uk> Duncan Coutts wrote: > On Wed, 2008-12-24 at 13:19 +0000, Dominic Steinitz wrote: >> Currently if I do not want to use the default locations for cabal then the >> following: >> >>> dist\build\cabal\cabal.exe --config-file=urghh --remote-repo-cache=foo >> --verbose=3 update >> >> will create urghh but will still (silently) put the repository cache at >> >> repoLocalDir = "C:\\Documents and Settings\\steinitd\\Application >> Data\\cabal\\packages\\hackage.haskell.org" > > Ah so when the config file does not exist the --remote-repo-cache flag > is ignored and the default value from the newly created config file is > used instead. > >> I've made a few changes which will put the cache at "foo". I don't have access >> to darcs at the moment so I've attached the changes. Let me know if a >> darcs patch is worth doing. > > Yes please though check that it's not already fixed. I made some changes > in that code relatively recently. Ok I've grabbed the latest version via darcs and you certainly have done something in this area. On linux I now get "foo" created with what look like the right things in it. However: dom@lagrange:~/cabal-install> cat urghh remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive remote-repo-cache: /home/dom/.cabal/packages which looks a bit suspicious to me as /home/dom/.cabal doesn't exist (presumably it isn't created). With my patch, "urghh" has what I believe is the correct remote-repo-cache of "foo". I haven't had chance to see where you made your change but it doesn't look to be in the same area as where I made my change. If I get time tomorrow I'll have a look. Do you concur with my view on what should be put in the config-file? > > There are a couple other path settings that are still hard coded and > should really be configurable. We should also have a way to operate > without any config file at all for install scripts etc. > I think but I haven't checked that my change would over-write any hard-coded global flag. Is that the required behaviour? I think this could allow you to operate without a config file if all you need is the global flags. I suspect users will need other flags but I think a slight modification to the one I suggested could handle that by using "mappend" to override all the hard-coded settings. Something like this maybe: > initialConf `mappend` (mempty {savedGlobalFlags = globalFlags}) 'mappend` > otherFlagsWhichNeedOverWriting Dominic. From duncan.coutts at worc.ox.ac.uk Fri Dec 26 18:59:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Dec 26 18:49:46 2008 Subject: Cabal Bug / Feature and Improvement In-Reply-To: <495554A6.9000706@blueyonder.co.uk> References: <1230248866.11869.27.camel@lantern> <495554A6.9000706@blueyonder.co.uk> Message-ID: <1230335968.11869.57.camel@lantern> On Fri, 2008-12-26 at 22:03 +0000, Dominic Steinitz wrote: > Duncan Coutts wrote: > > On Wed, 2008-12-24 at 13:19 +0000, Dominic Steinitz wrote: > >> Currently if I do not want to use the default locations for cabal then the > >> following: > >> > >>> dist\build\cabal\cabal.exe --config-file=urghh --remote-repo-cache=foo > >> --verbose=3 update > >> > >> will create urghh but will still (silently) put the repository cache at > >> > >> repoLocalDir = "C:\\Documents and Settings\\steinitd\\Application > >> Data\\cabal\\packages\\hackage.haskell.org" > > > > Ah so when the config file does not exist the --remote-repo-cache flag > > is ignored and the default value from the newly created config file is > > used instead. > > > >> I've made a few changes which will put the cache at "foo". I don't have access > >> to darcs at the moment so I've attached the changes. Let me know if a > >> darcs patch is worth doing. > > > > Yes please though check that it's not already fixed. I made some changes > > in that code relatively recently. > > Ok I've grabbed the latest version via darcs and you certainly have done > something in this area. On linux I now get "foo" created with what look > like the right things in it. However: > > dom@lagrange:~/cabal-install> cat urghh > remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive > remote-repo-cache: /home/dom/.cabal/packages > > which looks a bit suspicious to me as /home/dom/.cabal doesn't exist > (presumably it isn't created). With my patch, "urghh" has what I believe > is the correct remote-repo-cache of "foo". So what you want is for the initial package config file to contain the settings you specify on the command line? It seems to me that's likely to lead to confusion because those settings would not be saved if the config file already existed. If we want a way of creating a config file from command line settings (and the use case for that is not at all clear to me) then I think it should be explicit. What seems more useful is to avoid creating any config file at all. > I haven't had chance to see where you made your change but it doesn't > look to be in the same area as where I made my change. If I get time > tomorrow I'll have a look. I think it's in Main. We combine (using mappend) flags from three sources, the defaults, any config file and the command line. > Do you concur with my view on what should be put in the config-file? I'm not sure that I do. I think I'd like to see the bigger picture of what you're really trying to achieve. > > There are a couple other path settings that are still hard coded and > > should really be configurable. We should also have a way to operate > > without any config file at all for install scripts etc. > > > > I think but I haven't checked that my change would over-write any > hard-coded global flag. Is that the required behaviour? I think this > could allow you to operate without a config file if all you need is the > global flags. I suspect users will need other flags but I think a slight > modification to the one I suggested could handle that by using "mappend" > to override all the hard-coded settings. Something like this maybe: > > > initialConf `mappend` (mempty {savedGlobalFlags = globalFlags}) 'mappend` > > otherFlagsWhichNeedOverWriting Honestly, I'm not quite sure what you're trying to do exactly. Perhaps seeing the whole patch would help or if you can explain the use case. Duncan From ccshan at post.harvard.edu Sat Dec 27 18:14:04 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Sat Dec 27 21:57:11 2008 Subject: blame: mtl MonadReader instance for ContT References: <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> Message-ID: Nicolas Frisby wrote in article <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> in gmane.comp.lang.haskell.libraries: > > instance (MonadReader r' m) => MonadReader r' (ContT r m) where > > local f m = ContT $ \c -> do > > r <- ask > > local f (runContT m (local (const r) . c)) > > 1) I am hoping this list can recall the reason for putting this design > decision into the mtl. Perhaps there's a reason to prefer this > particular side-effect interaction. For what it's worth, this interaction is justified in Section 8.4 of: Sheng Liang, Paul Hudak, and Mark Jones. 1995. Monad transformers and modular interpreters. In POPL '95: Conference record of the annual ACM symposium on principles of programming languages, 333-343. New York: ACM Press. http://web.cecs.pdx.edu/~mpj/pubs/modinterp.html -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 100 Days to close Guantanamo and end torture http://100dayscampaign.org/ From haskell at list.mightyreason.com Mon Dec 29 09:24:00 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Mon Dec 29 09:16:02 2008 Subject: Different QSem(N) (was Re: IORef vs TVar performance: 6 seconds versus 4 minutes) In-Reply-To: <20081229112805.GA4206@zombie.inf.tu-dresden.de> References: <49584BEC.6030402@cs.pdx.edu> <2f9b2d30812282115v3dab4288pa9b1beb1eaf8f47@mail.gmail.com> <2518b95d0812282308q352aa9bdydd7d5c3bc51fc53a@mail.gmail.com> <20081229112805.GA4206@zombie.inf.tu-dresden.de> Message-ID: <4958DD80.7070506@list.mightyreason.com> I think I can improve on your code. Bertram Felgenhauer wrote: > But why does it manually manage the waiters at all? MVars are fair, in > ghc at least. So this should work: > > data Sem = Sem (MVar Int) (MVar Int) I changed the above to be a data > > newSem :: Int -> IO Sem > newSem initial = liftM2 Sem (newMVar initial) newEmptyMVar > > -- | Wait for a unit to become available > waitSem :: Sem -> IO () > waitSem (Sem sem wakeup) = do > avail' <- modifyMVar sem (\avail -> return (avail-1, avail-1)) Threads can get out of order at this point. This "order bug" may be undesirable. Also, killing the thread while it waits for "wakeup" below would be bad. You need an exception handler and some kind of cleanup. > when (avail' < 0) $ takeMVar wakeup >>= putMVar sem > -- | Signal that a unit of the 'Sem' is available > signalSem :: Sem -> IO () > signalSem (Sem sem wakeup) = do > avail <- takeMVar sem > if avail < 0 then putMVar wakeup (avail+1) > else putMVar sem (avail+1) You should change this from "= do" to "= block $ do". > > (I should turn this into a library proposal.) > > Bertram If you do not need to take N at a time then the untested code below has no "order bug" and is fair. > module Sem where > > import Control.Concurrent.MVar > import Control.Monad(when,liftM2) > > data Sem = Sem { avail :: MVar Int -- ^ provides fast path and fair queue > , lock :: MVar () } -- ^ Held while signalling the queue > > -- It makes no sense here to initialize with a negative number, so > -- this is treated the same as initializing with 0. > newSem :: Int -> IO Sem > newSem init | init < 1 = liftM2 Sem newEmptyMVar (newMVar ()) > | otherwise = liftM2 Sem (newMVar init) (newMVar ()) > > waitSem :: Sem -> IO () > waitSem (Sem sem _) = block $ do > avail <- takeMVar sem > when (avail > 1) (signalSemN (pred avail)) > > signalSem :: Sem -> IO () > signalSem = signalSemN 1 > > signalSemN :: Int -> Sem -> IO () > signalSemN i (Sem sem lock) | i <= 1 = return () > | otherwise = > withMVar lock $ \ _ -> block $ do > old <- tryTakeMVar sem > case old of > Nothing -> putMVar sem i > Just v -> putMVar sem $! succ i All waitSem block in arrival order with the takeMVar in waitSem. The signalSemN avoid conflicting by serializing on the "MVar ()" lock. The above is quite fast so long as the semaphore holds no more than the value 1. Once it hold more than 1 the waiter must take time to add back the remaining value. Note that once threads are woken up in order, they may still go out of order blocking for the () lock when adding back the remaining value (in the presence of other signalers). The above is also exception safe. The only place it can die is during the takeMVar and this merely remove a blocked waiter. I see no way to add a fair waitSemN without changing Sem. But if I change Sem then I can make a fair waitSemN. The untested code is below: > module Sem where > > import Control.Concurrent.MVar > import Control.Monad(when,liftM3) > import Control.Exception.Base > > data Sem = Sem { semWait :: MVar () -- for serializing waiting threads > , semAvail :: MVar Int -- positive quantity available > , semSignal :: MVar () -- for serializing signaling threads > } > > > newSem i | i<=0 = liftM3 Sem (newMVar ()) newEmptyMVar (newMVar ()) > | otherwise = liftM3 Sem (newMVar ()) (newMVar i) (newMVar ()) > > waitSem :: Sem -> IO () > waitSem = waitSemN 1 > > waitSemN :: Int -> Sem -> IO () > waitSemN i sem@(Sem w a s) | i<=0 = return () > | otherwise = withMVar w $ \ _ -> block $ do > let go n = do > avail <- onException (takeMVar a) (signalSemN (i-n) sem) > case compare avail n of > LT -> go $! n-avail > EQ -> return () > GT -> signalSemN (avail-n) sem > go i > > signalSem :: Sem -> IO () > signalSem = signalSemN 1 > > signalSemN :: Int -> Sem -> IO () > signalSemN i (Sem _ a s) | i<=0 = return () > | otherwise = withMVar s $ \ _ -> block $ do > ma <- tryTakeMVar a > case ma of Nothing -> putMVar a i > Just v -> putMVar a $! v+i Trying for exception safety makes the above slightly tricky. It works by allowing only a single thread to get the semWait lock. This keeps all the arriving threads in the fair blocking queue for the semWait lock. The holder of the semWait lock then nibbles at semAvail's positive value until it is satisfied. Excess value is added back safely with signalSemN. Cheers, Chris Kuklewicz From dominic.steinitz at blueyonder.co.uk Mon Dec 29 11:07:51 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon Dec 29 10:59:59 2008 Subject: Cabal Bug / Feature and Improvement References: <1230248866.11869.27.camel@lantern> <495554A6.9000706@blueyonder.co.uk> <1230335968.11869.57.camel@lantern> Message-ID: Duncan Coutts worc.ox.ac.uk> writes: > I'm not sure that I do. I think I'd like to see the bigger picture of > what you're really trying to achieve. > > > Honestly, I'm not quite sure what you're trying to do exactly. Perhaps > seeing the whole patch would help or if you can explain the use case. Here's my use case. I've expressed in the form of requirements and how I think they could be solved using ghc and cabal. We have a small team of developers and a much larger team of users who use a very restricted subset of Haskell. We have a version control system. We want everyone to use exactly the same community packages. Currently, we keep these packages under version control and manually modify ghc's package.conf (also under version control). The reason we do this is that the developers and users are able to check out sources to an arbitrary location on their local disk and we want the users to be able to build and run our code without manual configuration or separate installation of anything. Furthermore, each developer and user could have several "workspaces" (checked out versions of the sources at different locations on their local disk) on the go at the same time. We modify ghc's package.conf to use $topdir and relative paths - see http://www.nabble.com/Re%3A-haddock-not-finding-base- lib-docs----%24topdir---p7699303.html - so that package.conf is in sync with the place where the developer / user has checked out their sources (without package.conf needing to be modified on a per user and per workspace basis). The requirement for everyone to use the exactly the same community packages is partly driven by audit requirements. Furthermore, because we are behind a proxy, currently we would have to get every user to modify their registry if we wanted them to install community packages. We'd rather not do that especially as these settings can get over-written e.g. when Internet Explorer gets patched. We'd like to move away from manually modifying ghc's package.conf and to doing things the community way by using cabal more. Here's what I think would work. 1. A developer realises that package A is required. He cabal fetches to a remote-repo-cache which is under version control. This will also fetch any dependencies. 2. He installs package A using the remote-repo-cache and specifying --package- db. Note that the package-db is "[]" in the version control system and only every gets updated in the checked out source. It never gets checked back in. The cabal install of package A updates the package-db. 3. He uses e.g. ghci with -package-conf, -no-user-package-conf and -package A. 4. He checks in the remote-repo-cache. 4. Now another developer wishes to work on the code. 5. He checks out the sources from version control and cabal installs all the packages in the remote-repo-cache specifying --package-db. We'd probably do this in our build system by automatically building any package that has appeared in the repo-cache since the last update. He now has all the packages in the remote-repo-cache and his package.db has been updated to reflect this even though the file itself is not ever checked into the version control system. We'd certainly want this to happen behind the scenes for our users who will not add packages but who will certainly use them (even if they don't realise they are). Dominic. From nicolas.frisby at gmail.com Mon Dec 29 13:16:31 2008 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Mon Dec 29 13:08:29 2008 Subject: blame: mtl MonadReader instance for ContT In-Reply-To: References: <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> Message-ID: <5ce89fb50812291016oda99984u480414f4c9675f25@mail.gmail.com> Thanks for the pointer. I did come across that. They only call this particular lifting "not natural," which doesn't seem much of a justification - unless they mean natural in a more formal sense that isn't immediately obvious to me. I revisited that paper upon finding the reference in your Delimited Dynamic Binding, the examples of which finally lent some clarity to the differences in the computational behaviors I was dealing with. On Sat, Dec 27, 2008 at 5:14 PM, Chung-chieh Shan wrote: > Nicolas Frisby wrote in article <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> in gmane.comp.lang.haskell.libraries: >> > instance (MonadReader r' m) => MonadReader r' (ContT r m) where >> > local f m = ContT $ \c -> do >> > r <- ask >> > local f (runContT m (local (const r) . c)) >> >> 1) I am hoping this list can recall the reason for putting this design >> decision into the mtl. Perhaps there's a reason to prefer this >> particular side-effect interaction. > > For what it's worth, this interaction is justified in Section 8.4 of: > Sheng Liang, Paul Hudak, and Mark Jones. 1995. Monad transformers and > modular interpreters. In POPL '95: Conference record of the annual ACM > symposium on principles of programming languages, 333-343. New York: > ACM Press. http://web.cecs.pdx.edu/~mpj/pubs/modinterp.html > > -- > Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig > 100 Days to close Guantanamo and end torture http://100dayscampaign.org/ > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From bertram.felgenhauer at googlemail.com Mon Dec 29 13:32:54 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Dec 29 13:24:59 2008 Subject: Different QSem(N) In-Reply-To: <4958DD80.7070506@list.mightyreason.com> References: <49584BEC.6030402@cs.pdx.edu> <2f9b2d30812282115v3dab4288pa9b1beb1eaf8f47@mail.gmail.com> <2518b95d0812282308q352aa9bdydd7d5c3bc51fc53a@mail.gmail.com> <20081229112805.GA4206@zombie.inf.tu-dresden.de> <4958DD80.7070506@list.mightyreason.com> Message-ID: <20081229183254.GB10905@zombie.inf.tu-dresden.de> ChrisK wrote: > I think I can improve on your code. > > Bertram Felgenhauer wrote: >> -- | Wait for a unit to become available >> waitSem :: Sem -> IO () >> waitSem (Sem sem wakeup) = do >> avail' <- modifyMVar sem (\avail -> return (avail-1, avail-1)) > > Threads can get out of order at this point. Is this observable, i.e. distinguishable from the threads entering 'waitSem' in a different order? I think not. > Also, killing the thread while it waits for "wakeup" below would > be bad. You need an exception handler and some kind of cleanup. True. I didn't try for exception safety, mainly because Control.Concurrent.QSem isn't currently exception safe. I would require the caller of waitSem/signalSem to call 'block' if they need exception safety, because outside any 'block', an exception might occur right before or after the semaphore operation - causing tokens (the things that the semaphore counter counts) to get unaccountably lost or created, making exception safety rather meaningless. > If you do not need to take N at a time then the untested code below has no > "order bug" and is fair. > >> module Sem where >> import Control.Concurrent.MVar >> import Control.Monad(when,liftM2) >> data Sem = Sem { avail :: MVar Int -- ^ provides fast path and fair >> queue >> , lock :: MVar () } -- ^ Held while signalling the queue >> -- It makes no sense here to initialize with a negative number, so >> -- this is treated the same as initializing with 0. >> newSem :: Int -> IO Sem >> newSem init | init < 1 = liftM2 Sem newEmptyMVar (newMVar ()) >> | otherwise = liftM2 Sem (newMVar init) (newMVar ()) >> waitSem :: Sem -> IO () >> waitSem (Sem sem _) = block $ do >> avail <- takeMVar sem >> when (avail > 1) (signalSemN (pred avail)) These (pred avail) tokens may be lost if signalSemN blocks on the semaphore lock and an asynchronous exception is caught at that point. (withMVar uses takeMVar internally, and the fact that it's inside 'block' doesn't help - it's a blocking operation) >> signalSem :: Sem -> IO () >> signalSem = signalSemN 1 >> signalSemN :: Int -> Sem -> IO () >> signalSemN i (Sem sem lock) | i <= 1 = return () ^^^^^^ should be i <= 0 >> | otherwise = >> withMVar lock $ \ _ -> block $ do >> old <- tryTakeMVar sem >> case old of >> Nothing -> putMVar sem i >> Just v -> putMVar sem $! succ i ^^^^^^ should be old + i > I see no way to add a fair waitSemN without changing Sem. But if I change > Sem then I can make a fair waitSemN. The untested code is below: > >> signalSemN :: Int -> Sem -> IO () >> signalSemN i (Sem _ a s) | i<=0 = return () >> | otherwise = withMVar s $ \ _ -> block $ do Same as above: Exceptions may creep into the withMVar, and the signalSemN call from waitSemN may thus fail. >> ma <- tryTakeMVar a >> case ma of Nothing -> putMVar a i >> Just v -> putMVar a $! v+i > Trying for exception safety makes the above slightly tricky. Indeed. I need to think about this some more. > Cheers, > Chris Kuklewicz Bertram