From ndmitchell at gmail.com Tue May 1 05:02:54 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 1 05:00:16 2007 Subject: FilePath documentation differences Message-ID: <404396ef0705010202g6992d694kc086d4ddcd1e17fb@mail.gmail.com> Hi, The filepath documentation seems to be different on my machine, versus on Haskell.org: My locally generated copy: http://www.cs.york.ac.uk/fp/haddock/filepath/System-FilePath-Posix.html GHC version: http://www.haskell.org/ghc/docs/latest/html/libraries/filepath/System-FilePath-Posix.html It is missing the description and examples at the top. Is this intentional? Thanks Neil From igloo at earth.li Tue May 1 06:42:14 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue May 1 06:39:35 2007 Subject: FilePath documentation differences In-Reply-To: <404396ef0705010202g6992d694kc086d4ddcd1e17fb@mail.gmail.com> References: <404396ef0705010202g6992d694kc086d4ddcd1e17fb@mail.gmail.com> Message-ID: <20070501104214.GA1525@matrix.chaos.earth.li> On Tue, May 01, 2007 at 10:02:54AM +0100, Neil Mitchell wrote: > > My locally generated copy: > http://www.cs.york.ac.uk/fp/haddock/filepath/System-FilePath-Posix.html > > GHC version: > http://www.haskell.org/ghc/docs/latest/html/libraries/filepath/System-FilePath-Posix.html > > It is missing the description and examples at the top. Is this intentional? No. The missing stuff is at the top of a file that gets #include'd in. I suspect cpp's creating a #LINE or something that's confusing haddock, but I haven't looked into it yet. Was your copy generated with cpp or cpphs? Thanks Ian From ndmitchell at gmail.com Tue May 1 08:22:53 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 1 08:20:14 2007 Subject: FilePath documentation differences In-Reply-To: <20070501104214.GA1525@matrix.chaos.earth.li> References: <404396ef0705010202g6992d694kc086d4ddcd1e17fb@mail.gmail.com> <20070501104214.GA1525@matrix.chaos.earth.li> Message-ID: <404396ef0705010522u1457f601mc488fd66593c145d@mail.gmail.com> Hi Ian, > No. The missing stuff is at the top of a file that gets #include'd in. I > suspect cpp's creating a #LINE or something that's confusing haddock, > but I haven't looked into it yet. Was your copy generated with cpp or > cpphs? cpphs Thanks Neil From simonmarhaskell at gmail.com Thu May 3 03:34:50 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 3 03:32:14 2007 Subject: Test, please ignore Message-ID: <4639909A.3050407@gmail.com> I've had a report of difficulty posting to the list, and we haven't had any posts in a couple of days, so this is a test. From nonce+haskell.org at dfranke.us Thu May 3 16:44:02 2007 From: nonce+haskell.org at dfranke.us (Daniel Franke) Date: Thu May 3 16:42:25 2007 Subject: POSIX named semaphore and shared memory object bindings Message-ID: <20070503204402.GA24476@laurelin.dfranke.us> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070503/c8051be1/attachment.bin From duncan.coutts at worc.ox.ac.uk Thu May 3 16:52:39 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 3 17:02:35 2007 Subject: POSIX named semaphore and shared memory object bindings In-Reply-To: <20070503204402.GA24476@laurelin.dfranke.us> References: <20070503204402.GA24476@laurelin.dfranke.us> Message-ID: <1178225559.9770.144.camel@localhost> On Thu, 2007-05-03 at 16:44 -0400, Daniel Franke wrote: > 2. The HEAD version of `unix' depends on the HEAD version of `Cabal', > which currently won't build: > > Distribution/Compat/TempFile.hs:6:7: > Could not find module `IO': > it is a member of package haskell98, which is hidden Fixed thanks. Trying to keep things working on nhc and ghc simultaneously doesn't seem to be that easy :-(. Duncan From nonce+haskell.org at dfranke.us Thu May 3 18:22:40 2007 From: nonce+haskell.org at dfranke.us (Daniel Franke) Date: Thu May 3 18:20:13 2007 Subject: POSIX named semaphore and shared memory object bindings In-Reply-To: <1178225559.9770.144.camel@localhost> References: <20070503204402.GA24476@laurelin.dfranke.us> <1178225559.9770.144.camel@localhost> Message-ID: <20070503222239.GB2435@laurelin.dfranke.us> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070503/507f7e6c/attachment-0001.bin From marco-oweber at gmx.de Fri May 4 06:56:36 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Fri May 4 06:53:43 2007 Subject: StringBuffer.lhs (compiler/utils/) - hGetStringBuffer ? should the 'h' be there? Message-ID: <20070504105636.GC9283@gmx.de> hPutStrLn etc all denote that you have to pass a handle hGetStringBuffer has the type hGetStringBuffer :: FilePath -> IO StringBuffer so I think the h is superfluous here ? Marc From isaacdupree at charter.net Sat May 5 08:03:57 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat May 5 07:59:56 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) Message-ID: <463C72AD.8050701@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The obvious "evaluate x = x `seq` return x" fails one of the following laws for evaluate: " evaluate x `seq` y ==> y evaluate x `catch` f ==> (return $! x) `catch` f evaluate x >>= f ==> (return $! x) >>= f Note: the first equation implies that (evaluate x) is not the same as (return $! x). " However, strictness does not obey the monad laws. A correct definition for IO would be "evaluate x = (x `seq` return x) >>= return", or equally, "(return $! x) >>= return", or even more horrible-looking, "fmap id (return $! x)"! This works because (at least in present Haskell implementations) IO's (>>=) is not strict in its first argument. Noticing that this function has been implemented (slightly wrongly) for NHC in base, so I mention this odd suggestion. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPHKtHgcxvIWYTTURAmT2AKC+pipeHff1jVOCqxjOOz2p+6/JqQCeNqAN bjkaLwbn+BRVCya2e49diF4= =J9iV -----END PGP SIGNATURE----- From frederik at a5.repetae.net Sun May 6 14:44:53 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun May 6 14:42:34 2007 Subject: why is Data.Set not a Monad? Message-ID: <20070506184453.GA25354@a5.repetae.net> Hello, Anyone know why Data.Set is not a Monad? Or Data.Map? It seems Data.Map is a Functor, but not Data.Set... I am confused. Am I not importing the right modules? Thanks, Frederik From nonce+haskell.org at dfranke.us Sun May 6 14:58:07 2007 From: nonce+haskell.org at dfranke.us (Daniel Franke) Date: Sun May 6 14:55:04 2007 Subject: why is Data.Set not a Monad? In-Reply-To: <20070506184453.GA25354@a5.repetae.net> References: <20070506184453.GA25354@a5.repetae.net> Message-ID: <20070506185807.GA3430@laurelin.dfranke.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, May 06, 2007 at 07:44:53PM +0100, Frederik Eaton wrote: > Anyone know why Data.Set is not a Monad? Or Data.Map? I'm not sure why it ought to be. I assume that you want return = singleton and fail _ = emptySet, but how do you propose to define (>>=)? - -- Daniel Franke df@dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGPiU/KTA17JAC/eYRAkDSAJ98FGzjOUP77FpXHrnsrvmvkkQI/gCcC2A1 t+AFrEIgJGluZLXe+nYWV3Y= =Hoh2 -----END PGP SIGNATURE----- From dan.doel at gmail.com Sun May 6 16:00:09 2007 From: dan.doel at gmail.com (Dan Doel) Date: Sun May 6 15:56:25 2007 Subject: why is Data.Set not a Monad? In-Reply-To: <20070506184453.GA25354@a5.repetae.net> References: <20070506184453.GA25354@a5.repetae.net> Message-ID: <200705061600.09336.dan.doel@gmail.com> On Sunday 06 May 2007, Frederik Eaton wrote: > Hello, > > Anyone know why Data.Set is not a Monad? Or Data.Map? > > It seems Data.Map is a Functor, but not Data.Set... > > I am confused. Am I not importing the right modules? Thanks, These questions all have slightly different answers, I think. Somewhat out of order: 1) Data.Map isn't a monad because it isn't one. Consider: return :: a -> Map k a What key will return choose to inject a value into a map? The only option that leaps to mind is: return a = singleton undefined a But that's hardly useful. 2) Data.Set is a monad, but you can't convince Haskell's type system of that the way things are currently structured. This is because set operations require elements to be instances of the Ord typeclass, and the Monad typeclass signature doesn't allow for that. In the current typeclass, you have: return :: a -> m a While Set requires: return :: Ord a => a -> m a -- return = singleton It is possible to structure things so that Set can be given a Monad instance, but it may require some extensions. Here's one such way. Consider the following typeclass: class Monad m a where return :: a -> m a (>>=) :: (Monad m b) => m a -> (a -> m b) -> m b Here, 'm' is the monad type constructor, and 'a' will be the types it works on. An instance is needed for each such allowable a. In Set's case, with undecidable instances, this is easy: instance (Ord a) => Monad' Set a where return a = singleton a ... The (Ord a) context is provided for return. However, bind is still a problem, because the obvious definition: m >>= f = fold (union . f) empty m :: (Ord b) => Set a -> (a -> Set b) -> Set b Has an (Ord b) context that we can't provide. One way (not the only one, I'm sure) to solve this is to rebuild Set as a GADT, so that the (Ord b) context is packaged with the set. This can be simulated by wrapping the existing set (suppose the current set is imported qualified): data Set a where Empty :: Set a Wrap :: Ord a => Set a -> Set a singleton :: Ord a => a -> Set a singleton a = Wrap (Set.singleton a) union :: Set a -> Set a -> Set a union Empty t = t union s Empty = s union (Wrap s) (Wrap t) = Wrap (Set.union s t) fold :: (a -> b -> b) -> b -> Set a -> b fold _ z Empty = z fold f z (Wrap s) = Set.fold f z s Now, since the GADT union doesn't require an Ord context, we can write: instance Ord a => Monad Set a where return a = singleton a -- The same as before s >>= f = fold (union . f) Empty s So, we're finally at a 'valid' Monad instance for Set, and it only took us multi-parameter type classes, undecidable instances, and GADTs. :) Existing monads can be declared members of the revised class like so: instance Monad [] a where return a = [a] l >>= f = foldr ((++) . f) [] l Simply not restricting the parameter 'a' leaves you with the case we currently have. Other approaches have been suggested, I think, but this is one. I'm not sure it's an advisable road to take, as it's rather complicated, but it's an option. 3) As for Functors, it's easy to define an fmap operation for Map k v. You take your function of type (v -> u) and apply it to each element, storing the result at the same key. However, consider the type of the obvious fmap implementation for Set a: fmap f s = fold (insert . f) empty s :: Ord b => (a -> b) -> Set a -> Set b This requires an (Ord b) context that is absent from the Functor method's signature, just as we ran into problems with the signatures in the current Monad class. In fact, Set's 'map' function requires Ord contexts for a and b both. The problem here is that you can't use the same tricks as above to provide the (Ord b) context for fmap via a GADT (insert still requires a provided context). I suppose you could, of course, take *both* a and b as parameters to the class, so that you could place constraints on both. The same thing would work for Monad above, off the top of my head, and you could avoid the GADT. However, I suspect if you start down a road of taking a parameter for each distinct type variable in your method signatures, and having to declare (whether explicitly or implicitly) n^m instances for a class, rather than 1, things are going to get hairy. Data.Set does provide a 'mapMonotonic' function of type: (a -> b) -> Set a -> Set b which is the right type, but it appears to assume that the function respects the ordering, such that: a1 `compare` a2 == f a1 `compare` f a2 or something like that. You could, therefore, pass in a function that doesn't follow that, and up with a Set that isn't a set. Thus, it's unsuitable for use as fmap. Anyhow, I hope that made some sense at least, and answered some of your questions. I'll attach a file that has a slightly more fleshed out implementation of the GADT set wrapper, along with a monad instance, in case you want to play with it. Some things are renamed a bit compared to the above, since, for example, there already is a Monad typeclass. Cheers. -- Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: GADTSet.hs Type: text/x-hssrc Size: 1167 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070506/27d0d4b1/GADTSet.bin From stefanor at cox.net Sun May 6 16:03:56 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sun May 6 16:01:02 2007 Subject: why is Data.Set not a Monad?y In-Reply-To: <200705061600.09336.dan.doel@gmail.com> References: <20070506184453.GA25354@a5.repetae.net> <200705061600.09336.dan.doel@gmail.com> Message-ID: <20070506200356.GA10115@localhost.localdomain> On Sun, May 06, 2007 at 04:00:09PM -0400, Dan Doel wrote: > above, since, for example, there already is a Monad typeclass. You could just have used {-# OPTIONS_GHC -fno-implicit-prelude #-} and rebound do. > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} OPTIONS is obsolescent - new code should use OPTIONS_GHC, etc. (since options are by there nature compiler dependant) Stefan From ndmitchell at gmail.com Sun May 6 16:48:39 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun May 6 16:45:54 2007 Subject: why is Data.Set not a Monad?y In-Reply-To: <20070506200356.GA10115@localhost.localdomain> References: <20070506184453.GA25354@a5.repetae.net> <200705061600.09336.dan.doel@gmail.com> <20070506200356.GA10115@localhost.localdomain> Message-ID: <404396ef0705061348k429bbf6ds661867fe32ea1e09@mail.gmail.com> Hi > You could just have used {-# OPTIONS_GHC -fno-implicit-prelude #-} and > rebound do. > > > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > > OPTIONS is obsolescent - new code should use OPTIONS_GHC, etc. (since > options are by there nature compiler dependant) New code should ideally use LANGUAGE: {-# LANGUAGE AllowUndecidableInstances #-} It also means you can't throw in everything (all extensions), but have to be more selective. In some cases you still need to use OPTIONS_GHC though, particularly for # in id's - although hopefully someone will be adding MagicHash soon :-) Thanks Neil From frederik at a5.repetae.net Sun May 6 23:56:35 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun May 6 23:54:13 2007 Subject: why is Data.Set not a Monad? In-Reply-To: <200705061600.09336.dan.doel@gmail.com> References: <20070506184453.GA25354@a5.repetae.net> <200705061600.09336.dan.doel@gmail.com> Message-ID: <20070507035635.GA31133@a5.repetae.net> Hi Dan, Thank you for your interesting report. I'm sorry that I did not figure some of those things out myself. I guess I'd thought that the primary use of Set would be to replace lists for applications where order doesn't matter, or maybe where an efficient 'union' is needed; but many of these (e.g. parsing) commonly use a monadic interface, so it seems strange for Set not to have one. But I can't suggest a solution better than the ones you have proposed. Frederik On Sun, May 06, 2007 at 04:00:09PM -0400, Dan Doel wrote: > On Sunday 06 May 2007, Frederik Eaton wrote: > > Hello, > > > > Anyone know why Data.Set is not a Monad? Or Data.Map? > > > > It seems Data.Map is a Functor, but not Data.Set... > > > > I am confused. Am I not importing the right modules? Thanks, > > These questions all have slightly different answers, I think. Somewhat out of > order: > > 1) Data.Map isn't a monad because it isn't one. Consider: > > return :: a -> Map k a > > What key will return choose to inject a value into a map? The only option that > leaps to mind is: > > return a = singleton undefined a > > But that's hardly useful. > > 2) Data.Set is a monad, but you can't convince Haskell's type system of that > the way things are currently structured. This is because set operations > require elements to be instances of the Ord typeclass, and the Monad > typeclass signature doesn't allow for that. In the current typeclass, you > have: > > return :: a -> m a > > While Set requires: > > return :: Ord a => a -> m a -- return = singleton > > It is possible to structure things so that Set can be given a Monad instance, > but it may require some extensions. Here's one such way. Consider the > following typeclass: > > class Monad m a where > return :: a -> m a > (>>=) :: (Monad m b) => m a -> (a -> m b) -> m b > > Here, 'm' is the monad type constructor, and 'a' will be the types it works > on. An instance is needed for each such allowable a. In Set's case, with > undecidable instances, this is easy: > > instance (Ord a) => Monad' Set a where > return a = singleton a > ... > > The (Ord a) context is provided for return. However, bind is still a problem, > because the obvious definition: > > m >>= f = fold (union . f) empty m > :: (Ord b) => Set a -> (a -> Set b) -> Set b > > Has an (Ord b) context that we can't provide. One way (not the only one, I'm > sure) to solve this is to rebuild Set as a GADT, so that the (Ord b) context > is packaged with the set. This can be simulated by wrapping the existing set > (suppose the current set is imported qualified): > > data Set a where > Empty :: Set a > Wrap :: Ord a => Set a -> Set a > > singleton :: Ord a => a -> Set a > singleton a = Wrap (Set.singleton a) > > union :: Set a -> Set a -> Set a > union Empty t = t > union s Empty = s > union (Wrap s) (Wrap t) = Wrap (Set.union s t) > > fold :: (a -> b -> b) -> b -> Set a -> b > fold _ z Empty = z > fold f z (Wrap s) = Set.fold f z s > > Now, since the GADT union doesn't require an Ord context, we can write: > > instance Ord a => Monad Set a where > return a = singleton a -- The same as before > s >>= f = fold (union . f) Empty s > > So, we're finally at a 'valid' Monad instance for Set, and it only took us > multi-parameter type classes, undecidable instances, and GADTs. :) Existing > monads can be declared members of the revised class like so: > > instance Monad [] a where > return a = [a] > l >>= f = foldr ((++) . f) [] l > > Simply not restricting the parameter 'a' leaves you with the case we currently > have. > > Other approaches have been suggested, I think, but this is one. I'm not sure > it's an advisable road to take, as it's rather complicated, but it's an > option. > > 3) As for Functors, it's easy to define an fmap operation for Map k v. You > take your function of type (v -> u) and apply it to each element, storing the > result at the same key. However, consider the type of the obvious fmap > implementation for Set a: > > fmap f s = fold (insert . f) empty s :: Ord b => (a -> b) -> Set a -> Set b > > This requires an (Ord b) context that is absent from the Functor method's > signature, just as we ran into problems with the signatures in the current > Monad class. In fact, Set's 'map' function requires Ord contexts for a and b > both. > > The problem here is that you can't use the same tricks as above to provide the > (Ord b) context for fmap via a GADT (insert still requires a provided > context). I suppose you could, of course, take *both* a and b as parameters > to the class, so that you could place constraints on both. The same thing > would work for Monad above, off the top of my head, and you could avoid the > GADT. However, I suspect if you start down a road of taking a parameter for > each distinct type variable in your method signatures, and having to declare > (whether explicitly or implicitly) n^m instances for a class, rather than 1, > things are going to get hairy. > > Data.Set does provide a 'mapMonotonic' function of type: > > (a -> b) -> Set a -> Set b > > which is the right type, but it appears to assume that the function respects > the ordering, such that: > > a1 `compare` a2 == f a1 `compare` f a2 > > or something like that. You could, therefore, pass in a function that doesn't > follow that, and up with a Set that isn't a set. Thus, it's unsuitable for > use as fmap. > > Anyhow, I hope that made some sense at least, and answered some of your > questions. I'll attach a file that has a slightly more fleshed out > implementation of the GADT set wrapper, along with a monad instance, in case > you want to play with it. Some things are renamed a bit compared to the > above, since, for example, there already is a Monad typeclass. > > Cheers. > > -- Dan > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > > module GADTSet where > > import qualified Data.Set as Set > > data Set v where > Empty :: Set v > Wrap :: Ord v => Set.Set v -> Set v > > instance Show v => Show (Set v) where > show Empty = "Empty" > show (Wrap s) = show s > > empty :: Set v > empty = Empty > > singleton :: Ord v => v -> Set v > singleton v = Wrap $ Set.singleton v > > insert :: Ord v => v -> Set v -> Set v > insert v Empty = Wrap $ Set.singleton v > insert v (Wrap s) = Wrap $ Set.insert v s > > union :: Set v -> Set v -> Set v > union Empty t = t > union s Empty = s > union (Wrap s) (Wrap t) = Wrap $ Set.union s t > > member :: v -> Set v -> Bool > member _ Empty = False > member v (Wrap s) = Set.member v s > > fromList :: Ord v => [v] -> Set v > fromList l = Wrap $ Set.fromList l > > fold :: (a -> b -> b) -> b -> Set a -> b > fold _ z Empty = z > fold f z (Wrap s) = Set.fold f z s > > class ExtMonad m a where > ret :: a -> m a > (>>>=) :: ExtMonad m b => m a -> (a -> m b) -> m b > > instance Ord v => ExtMonad Set v where > ret = singleton > s >>>= f = fold (union . f) Empty s > > instance ExtMonad [] a where > ret a = [a] > l >>>= f = foldr ((++) . f) [] l > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- http://ofb.net/~frederik/ From nonce+haskell.org at dfranke.us Mon May 7 00:23:20 2007 From: nonce+haskell.org at dfranke.us (Daniel Franke) Date: Mon May 7 00:20:45 2007 Subject: why is Data.Set not a Monad? In-Reply-To: <20070507035635.GA31133@a5.repetae.net> References: <20070506184453.GA25354@a5.repetae.net> <200705061600.09336.dan.doel@gmail.com> <20070507035635.GA31133@a5.repetae.net> Message-ID: <20070507042319.GA3543@laurelin.dfranke.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, May 07, 2007 at 04:56:35AM +0100, Frederik Eaton wrote: > I guess I'd thought that the primary use of Set would be to replace > lists for applications where order doesn't matter, or maybe where an > efficient 'union' is needed; but many of these (e.g. parsing) commonly > use a monadic interface, so it seems strange for Set not to have one. A reasonably elegant solution might be to use StateT, with the contents of the set as your state. - -- Daniel Franke df@dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGPqm3KTA17JAC/eYRAgklAJ0bmOM/1MkmCZiEb0BM/RXclqGpPACgyKg+ FvI7/vT3d1lTJ1ZHoqwPa2U= =e/Y8 -----END PGP SIGNATURE----- From ahey at iee.org Mon May 7 05:23:24 2007 From: ahey at iee.org (Adrian Hey) Date: Mon May 7 05:20:35 2007 Subject: Why isn't Data.Map not an instance of Monoid :-) Message-ID: <463EF00C.4030503@iee.org> Hello Folks, Just been going through making sure the class instances for the AVL based Data.Map clone make sense, and I find this in Data.Map (and the clone). instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions This worries me because there is no obviously correct choice for the semantics of union for maps (as in which maps associated values get dropped). I've always felt that it was bad practice to provide library functions which simply make an arbitrary but a significant choice on users behalf, knowing it's likely that this isn't going to be what 50% of users actually want. So I'd been giving serious consideration to deprecating union, thereby forcing users to specify the behaviour they actually want using unionWith. The only reason I didn't in the end is that it's easy enough for users to get what they want in this case using flip (provided they don't care about "biasing" for keys) But it's not so easy if functions like this are used as class methods. So my inclination was to drop the Monoid instance for Maps. But I see by doing this I break Jean-Philippes instance of the Map class (which has a Monoid constraint) in the new Collections API.. http://darcs.haskell.org/packages/collections-ghc6.6/Data/Collections.hs AFAICT Jean-Philippe class only uses mempty, so I had been considering.. instance Ord k => Monoid (Map k v) where mempty = empty mappend = error "Data.Map.AVL: undefined Monoid.mappend." mconcat = error "Data.Map.AVL: undefined Monoid.mconcat." However, fooling people into thinking it is a Monoid when it isn't all so seems bad. So what do you think about this? Keep it or drop it? Does anybody (other than Jean-Philippe :-) currently rely on Data.Map being a Monoid instance? Regards -- Adrian Hey From Malcolm.Wallace at cs.york.ac.uk Mon May 7 06:13:29 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon May 7 06:16:00 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: <463C72AD.8050701@charter.net> References: <463C72AD.8050701@charter.net> Message-ID: <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> Isaac Dupree wrote: > The obvious "evaluate x = x `seq` return x" fails one of the following > laws for evaluate: > > evaluate x `seq` y ==> y I'm not sure why anyone thinks this "law" should hold, since it completely changes the known semantics of `seq`. A more accurate law would be: evaluate x `seq` y ==> if x==_|_ then _|_ else y Where did you find the erroneous version? Regards, Malcolm From la at iki.fi Mon May 7 06:47:46 2007 From: la at iki.fi (Lauri Alanko) Date: Mon May 7 06:44:48 2007 Subject: Why isn't Data.Map not an instance of Monoid :-) In-Reply-To: <463EF00C.4030503@iee.org> References: <463EF00C.4030503@iee.org> Message-ID: <20070507104746.GA21836@cs.helsinki.fi> On Mon, May 07, 2007 at 10:23:24AM +0100, Adrian Hey wrote: > instance (Ord k) => Monoid (Map k v) where > mempty = empty > mappend = union > mconcat = unions > > This worries me because there is no obviously correct choice for the > semantics of union for maps (as in which maps associated values get > dropped). Right. I think that the real fundamental MMap type should be something like: instance (Ord k, Monoid v) => Monoid (MMap k v) where mempty = empty mappend = unionWith mappend and with a lookup operation lookup :: (Ord k, Monoid v) => k -> MMap k v -> v which returns mempty when the key was not found in the map, _or_ if a mempty value was somehow stored in the map. The distinction is purely an implementation detail and shouldn't be visible. Then it is easy to see that the current Data.Map is just a wrapper to the above interface specialized to a left-biased monoid on Maybe. So Data.Map isn't as general as it should be, but at least it's _consistently_ non-general. There's not much point in generalizing the monoid instance of the map as long as there is still an implicit Maybe in the values. I'm not really advocating changing the Data.Map interface: Data.Map is intentionally specialized and optimized for pragmatic purposes. Abstract algebraic generalizations belong to Edison. Lauri From ahey at iee.org Mon May 7 07:35:22 2007 From: ahey at iee.org (Adrian Hey) Date: Mon May 7 07:32:32 2007 Subject: Why isn't Data.Map not an instance of Monoid :-) In-Reply-To: <20070507104746.GA21836@cs.helsinki.fi> References: <463EF00C.4030503@iee.org> <20070507104746.GA21836@cs.helsinki.fi> Message-ID: <463F0EFA.2070004@iee.org> Lauri Alanko wrote: > On Mon, May 07, 2007 at 10:23:24AM +0100, Adrian Hey wrote: >> instance (Ord k) => Monoid (Map k v) where >> mempty = empty >> mappend = union >> mconcat = unions >> >> This worries me because there is no obviously correct choice for the >> semantics of union for maps (as in which maps associated values get >> dropped). > > Right. I think that the real fundamental MMap type should be something like: > > instance (Ord k, Monoid v) => Monoid (MMap k v) where > mempty = empty > mappend = unionWith mappend Ross Paterson has suggested the same thing so I'll go with that, unless Jean-Philippe has some objection (I think Data.Map and Data.Map.AVL should be the same in this regard). This still breaks the Coolections module though, but I guess it's fixable. > and with a lookup operation > > lookup :: (Ord k, Monoid v) => k -> MMap k v -> v > > which returns mempty when the key was not found in the map, _or_ if a > mempty value was somehow stored in the map. The distinction is purely > an implementation detail and shouldn't be visible. > > Then it is easy to see that the current Data.Map is just a wrapper to > the above interface specialized to a left-biased monoid on Maybe. So > Data.Map isn't as general as it should be, but at least it's > _consistently_ non-general. There's not much point in generalizing the > monoid instance of the map as long as there is still an implicit Maybe > in the values. Actually at the moment lookup is.. lookup :: (Monad m,Ord k) => k -> Map k a -> m a Maybe we should have something like. lookupMaybe :: Ord k => k -> Map k a -> Maybe a lookupMonad :: (Monad m,Ord k) => k -> Map k a -> m a lookupMonoid :: (Ord k, Monoid a) => k -> Map k a -> a Hmm.. > I'm not really advocating changing the Data.Map interface: Data.Map is > intentionally specialized and optimized for pragmatic > purposes. Abstract algebraic generalizations belong to Edison. Or Jean-Philippes collections classes Regards -- Adrian Hey From nad at cs.chalmers.se Mon May 7 11:19:50 2007 From: nad at cs.chalmers.se (Nils Anders Danielsson) Date: Mon May 7 11:16:52 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> (Malcolm Wallace's message of "Mon, 7 May 2007 11:13:29 +0100") References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> Message-ID: On Mon, 07 May 2007, Malcolm Wallace wrote: > Isaac Dupree wrote: > >> The obvious "evaluate x = x `seq` return x" fails one of the following >> laws for evaluate: >> >> evaluate x `seq` y ==> y > > I'm not sure why anyone thinks this "law" should hold, since it > completely changes the known semantics of `seq`. A more accurate law > would be: > > evaluate x `seq` y ==> if x==_|_ then _|_ else y You seem to be assuming that evaluate ? = ?, which is not necessarily the case. > Where did you find the erroneous version? Presumably he found it by reading the documentation for evaluate: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#7 -- /NAD From Malcolm.Wallace at cs.york.ac.uk Mon May 7 12:54:04 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon May 7 12:55:27 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> Nils Anders Danielsson wrote: > > Where did you find the erroneous version? > Presumably he found it by reading the documentation for evaluate: > http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#7 Actually, I checked the source code for Control.Exception before asking the question, and those laws definitely do not appear there. So now I'm kind of puzzled as to how Haddock managed to generate documentation for them! > >> evaluate x `seq` y ==> y > > > > I'm not sure why anyone thinks this "law" should hold, > > You seem to be assuming that evaluate x = x, which is not > necessarily the case. Yes, I did make a mistake when I asked the question, in assuming some intuitive semantics rather than the actually written ones. So taking the law at face value, it seems to say that 'evaluate' is supposed to force its argument, yet the result should be guaranteed to be in WHNF, even if the argument was in fact undefined. Given that the result is in the IO monad, it can only mean one of two things: (1) That 'evaluate' should _not_ force its argument when it is called, but that rather that the argument should be forced only when the resultant IO action is executed. This conflicts with the documentation, which implies that the argument is forced _before_ the IO action is created or executed. But I guess this semantics accords with Isaac's suggested definition: evaluate x = (x `seq` return x) >>= return (2) A constraint on the internal representation of IO computations, such that it must implement imprecise exceptions. Thus, 'evaluate' could catch any exception caused by undefinedness in its argument, and wrap it up as a defined value again, e.g. evaluate x = (x `seq` return x) `catch` (\e-> IO (\world-> (x,world))) Hmm, actually this _also_ has the property of delaying when x is forced to the moment of execution of the result. Maybe evaluate x = (x `seq` return x) `FATBAR` return x or something otherwise not expressible in Haskell without extra primitives? Of course, perhaps 'evaluate' is itself supposed to be primitive. I'm not sure I have expressed my reasoning very clearly, but either way, some clarification would be welcome. Regards, Malcolm From isaacdupree at charter.net Mon May 7 18:57:51 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon May 7 18:53:44 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <463FAEEF.2050102@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Malcolm Wallace wrote: > Nils Anders Danielsson wrote: > >>> Where did you find the erroneous version? >> Presumably he found it by reading the documentation for evaluate: >> http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#7 > > Actually, I checked the source code for Control.Exception before asking > the question, and those laws definitely do not appear there. So now I'm > kind of puzzled as to how Haddock managed to generate documentation for > them! In the source code, grep found it at the end of libraries/base/GHC/Exception.lhs > (1) That 'evaluate' should _not_ force its argument when it is called, > but that rather that the argument should be forced only when the > resultant IO action is executed. This conflicts with the > documentation, which implies that the argument is forced _before_ > the IO action is created or executed. I didn't think so... though in most cases the IO action is only scrutinized/created in order to immediately execute it. > But I guess this semantics > accords with Isaac's suggested definition: > evaluate x = (x `seq` return x) >>= return I think evaluate's non-strictness until the IO is executed is similar to IO's (>>=)'s non-strictness in its first argument (would there be be any performance consequences to this artificially being different, in GHC, I wonder?) except that evaluate is documented, and that behavior has a purpose re: exceptions considering that evaluate is found in Control.Exception and I haven't found anything indicating that IO's (>>=) must not be strict in the first argument, it's just that all implementations seem to do it that way, so, is my suggested implementation really a good idea? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGP67vHgcxvIWYTTURAuOvAJ9Xbua9wQN2IyoasgVEeF2Qp4dcYACfbY6i /Fvp7mUccUD329WHV4/5WQc= =r8fm -----END PGP SIGNATURE----- From stefanor at cox.net Mon May 7 19:11:04 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Mon May 7 19:08:26 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: <463FAEEF.2050102@charter.net> References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> <463FAEEF.2050102@charter.net> Message-ID: <20070507231104.GA3224@localhost.localdomain> On Mon, May 07, 2007 at 06:57:51PM -0400, Isaac Dupree wrote: > Malcolm Wallace wrote: > > But I guess this semantics > > accords with Isaac's suggested definition: > > evaluate x = (x `seq` return x) >>= return Let's try a little Equational Reasoning: evaluate x = (x `seq` return x) >>= return evaluate x = (>>=) (seq x (return x)) return evaluate x = bindIO (seq x (returnIO x)) returnIO evaluate x = IO (\st1 -> case unIO (seq x (returnIO x)) st1 of (# st2, a #) -> unIO (returnIO a) st2) evaluate x = IO (\st1 -> case unIO (seq x (returnIO x)) st1 of (# st2, a #) -> (# st2, a #)) evaluate x = IO (\st1 -> case seq x (\st3 -> (# st3, x #)) st1 of (# st2, a #) -> (# st2, a #)) evaluate x = IO (\st1 -> case (case x of __DEFAULT -> (\st3 -> (# st3, x #))) st1 of (# st2, a #) -> (# st2, a #)) evaluate x = IO (\st1 -> case x of __DEFAULT -> case (\st3 -> (# st3, x #)) st1 of (# st2, a #) -> (# st2, a #)) evaluate x = IO (\st1 -> case x of __DEFAULT -> case (# st1, x #) of (# st2, a #) -> (# st2, a #)) evaluate x = IO (\st1 -> case x of __DEFAULT -> (# st1, x #)) evaluate x = IO (\st1 -> case x `seq` () of () -> (# st1, x #)) evaluate x = GHC.Exception.evaluate x Stefan From simonmarhaskell at gmail.com Tue May 8 04:12:44 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue May 8 04:10:17 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <464030FC.4080102@gmail.com> Malcolm Wallace wrote: > Nils Anders Danielsson wrote: > >>> Where did you find the erroneous version? >> Presumably he found it by reading the documentation for evaluate: >> http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#7 > > Actually, I checked the source code for Control.Exception before asking > the question, and those laws definitely do not appear there. So now I'm > kind of puzzled as to how Haddock managed to generate documentation for > them! > >>>> evaluate x `seq` y ==> y >>> I'm not sure why anyone thinks this "law" should hold, >> You seem to be assuming that evaluate x = x, which is not >> necessarily the case. > > Yes, I did make a mistake when I asked the question, in assuming some > intuitive semantics rather than the actually written ones. So taking > the law at face value, it seems to say that 'evaluate' is supposed to > force its argument, yet the result should be guaranteed to be in WHNF, > even if the argument was in fact undefined. Given that the result is in > the IO monad, it can only mean one of two things: > > (1) That 'evaluate' should _not_ force its argument when it is called, > but that rather that the argument should be forced only when the > resultant IO action is executed. This conflicts with the > documentation, which implies that the argument is forced _before_ > the IO action is created or executed. But I guess this semantics > accords with Isaac's suggested definition: > evaluate x = (x `seq` return x) >>= return That's exactly right. Evaluate was introduced because it does something different from (return $!). We tried in the documentation to be clear about its semantics, but perhaps we weren't clear enough. I'll add Isaac's suggested definition to the docs. Cheers, Simon From simonmarhaskell at gmail.com Tue May 8 05:34:52 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue May 8 05:31:53 2007 Subject: Test, please ignore Message-ID: <4640443C.8020504@gmail.com> I've had a report of difficulty posting to the list, so this is a test. From duncan.coutts at worc.ox.ac.uk Tue May 8 12:38:45 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 8 12:49:58 2007 Subject: darcs patch: Make Gen an instance of Applicative Message-ID: Thanks to Björn Bringert and Koen Claessen, the QuickCheck 2 darcs repository is now hosted at: darcs get http://darcs.haskell.org/QuickCheck/ 'darcs send' will send patches to the libraries mailing list. We figured this list is appropriate since QC is a tool that many people depend on so getting a wider range of reviewers is good and yet development activity isn't likely to be so high that a seperate mailing list would be needed. Here's one such patch: Tue May 8 17:32:04 BST 2007 Duncan Coutts * Make Gen an instance of Applicative So we can use the nice syntax: f <$> a <*> b <*> c -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 3184 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070508/2c90809d/attachment.bin From ross at soi.city.ac.uk Tue May 8 13:37:31 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue May 8 13:34:29 2007 Subject: HackageDB: request for requests Message-ID: <20070508173731.GA4474@soi.city.ac.uk> As you may know, Sascha B?hme will be doing a Google Summer of Code project on enhancing the (currently rather basic) web interface to HackageDB. There's a list of ideas at http://hackage.haskell.org/trac/hackage/wiki/HackageToDo Let's hear views on what's most important, what's missing, how it should be done, etc, but don't expect it all to get done this (northern-hemisphere) summer. From maeder at tzi.de Tue May 8 17:33:28 2007 From: maeder at tzi.de (Christian Maeder) Date: Tue May 8 17:30:42 2007 Subject: problems using ghc-6.6.1 (due to fgl-5.4.1) Message-ID: <4640ECA8.5040704@tzi.de> I wrote: > Dear Hets- and GHC-Developers, > we have a problem using ghc-6.6.1. The created hets binary runs a > couple > of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where "hiding (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 From bringert at cs.chalmers.se Tue May 8 17:57:09 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Tue May 8 17:52:17 2007 Subject: darcs patch: Make Gen an instance of Applicative In-Reply-To: References: Message-ID: <8646ADFE-3884-4015-B919-9B705DBFA61D@cs.chalmers.se> I like this, but I'm afraid the compatibility price might be too high. AFAIK, Control.Applicative is only available in base >= 2.0 , which means that QuickCheck 2 wouldn't work with Haskell implementations which come with base < 2.0. This means that no program which wants to be testable with older implementations can switch to QC2. Is this acceptable instead: return f `ap` a `ap` b `ap` c ? That's already possible, right? /Bj?rn On May 8, 2007, at 18:38 , Duncan Coutts wrote: > Thanks to Bj?rn Bringert and Koen Claessen, the QuickCheck 2 darcs > repository > is now hosted at: > > darcs get http://darcs.haskell.org/QuickCheck/ > > 'darcs send' will send patches to the libraries mailing list. > > We figured this list is appropriate since QC is a tool that many > people depend > on so getting a wider range of reviewers is good and yet > development activity > isn't likely to be so high that a seperate mailing list would be > needed. > > Here's one such patch: > > Tue May 8 17:32:04 BST 2007 Duncan Coutts > > * Make Gen an instance of Applicative > So we can use the nice syntax: f <$> a <*> b <*> c > > > New patches: > > [Make Gen an instance of Applicative > Duncan Coutts **20070508163204 > So we can use the nice syntax: f <$> a <*> b <*> c > ] { > hunk ./Test/QuickCheck/Gen.hs 17 > +import Control.Applicative (Applicative(..), (<$>)) > hunk ./Test/QuickCheck/Gen.hs 35 > +instance Applicative Gen where > + pure x = > + MkGen (\_ _ -> x) > + > + MkGen f <*> MkGen x = > + MkGen (\r n -> > + let (r1,r2) = split r > + in f r1 n (x r2 n)) > + > } > > Context: > > [Haddock tweak. > bringert@cs.chalmers.se**20061126234053] > [Added a version of sampling that returns the test cases > dpt@math.columbia.edu**20061126220704] > [Added LICENSE file. > bringert@cs.chalmers.se**20061126232241] > [Fixed silly missed use of Positive constructor. Reported by Audrey > Tang. > bringert@cs.chalmers.se**20061124212824] > [Added README. > bringert@cs.chalmers.se**20061123144917] > [Some haddock mark-up fixes to support haddock 0.7. > bringert@cs.chalmers.se**20061123144831] > [Removed BUGS. > bringert@cs.chalmers.se**20061123144204] > [Changed distribution of NonNegative to 1:5 for 0:everything else > (was 9:1). > bringert@cs.chalmers.se**20061120210126] > [Added NonZero and reimplemented Positive in terms of NonZero and > NonNegative. > bringert@cs.chalmers.se**20061120205417] > [Added BUGS file. > bringert@cs.chalmers.se**20061120205405] > [Added Integral and Real instances for Positive and NonNegative. > bringert@cs.chalmers.se**20061120204544] > [Some haddock tweaks. > bringert@cs.chalmers.se**20061120112922] > [More haddock comments. > bringert@cs.chalmers.se**20061120112532] > [More haddock and export list fixes. > bringert@cs.chalmers.se**20061117201830] > [Added lots of Haddock comments and cleaned up export lists. > bringert@cs.chalmers.se**20061117200346] > [Commented out generics import that Haddock choked on. > bringert@cs.chalmers.se**20061117152818] > [Removed shrinkSub workarounds for old GHC bugs. > bringert@cs.chalmers.se**20061117152630] > [Get rid of the last uses of modules from the haskell98 package, > replace with base modules. > bringert@cs.chalmers.se**20061117152400] > [Added Cabal build system. > bringert@cs.chalmers.se**20061117152230] > [Removed Koen's CVS update script. > bringert@cs.chalmers.se**20061117151819] > [Renamed modules to Test.QuickCheck.*. > bringert@cs.chalmers.se**20061117151417] > [More fixes to get examples to compile. > bringert@cs.chalmers.se**20061114164526] > [Fixed some imports in examples. > bringert@cs.chalmers.se**20061114163012] > [Fixed Chalmers/QuickCheck/Monadic.hs to compile with GHC 6.6. > bringert@cs.chalmers.se**20061114162953] > [Moved examples to a top-level directory. > bringert@cs.chalmers.se**20061114160643] > [Fixed ExSet2 and ExLambda to compile with GHC 6.6. > bringert@cs.chalmers.se**20061114160531] > [Comment out generics stuff to compile with GHC 6.6. > bringert@cs.chalmers.se**20061114160414] > [Renamed QuickCheck to Chalmers to get module names right. > bringert@cs.chalmers.se**20061114160326] > [Tailorization of QuickCheck > tailor@momo.medic.chalmers.se**20061114165514 > Import of the upstream sources from the repository > > /users/cs/koen/CvsRoot > > as of revision 2006-05-03 18:37:52 by koen > > ] > Patch bundle hash: > 133c0e3a886385a943e73a6b7551229f2c07b96c > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ashley at semantic.org Tue May 8 20:47:27 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Tue May 8 20:44:49 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: <464030FC.4080102@gmail.com> References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> <464030FC.4080102@gmail.com> Message-ID: Simon Marlow wrote: > That's exactly right. Evaluate was introduced because it does something > different from (return $!). We tried in the documentation to be clear > about its semantics, but perhaps we weren't clear enough. I'll add > Isaac's suggested definition to the docs. If Isaac's definition is accurate, we might as well generalise it to any Monad. -- Ashley Yakeley From stefanor at cox.net Tue May 8 20:50:34 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue May 8 20:47:32 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> <464030FC.4080102@gmail.com> Message-ID: <20070509005034.GA11135@localhost.localdomain> On Tue, May 08, 2007 at 05:47:27PM -0700, Ashley Yakeley wrote: > Simon Marlow wrote: > >That's exactly right. Evaluate was introduced because it does something > >different from (return $!). We tried in the documentation to be clear > >about its semantics, but perhaps we weren't clear enough. I'll add > >Isaac's suggested definition to the docs. > > If Isaac's definition is accurate, we might as well generalise it to any > Monad. Isaac's definition is equivalent to the standard evaluate as I proved. However, my proof could be using misfeatures of IO. Stefan From john at repetae.net Tue May 8 20:51:37 2007 From: john at repetae.net (John Meacham) Date: Tue May 8 20:48:35 2007 Subject: [Haskell] -compiler-options vs {#-LANGUAGE Flags-#} In-Reply-To: References: <20070323212704.GA19807@thened.net> <46051716.9080300@dtek.chalmers.se> <20070405174209.GE16785@momenergy.repetae.net> Message-ID: <20070509005137.GA15709@momenergy.repetae.net> On Thu, Apr 05, 2007 at 07:07:34PM +0100, David House wrote: > On 05/04/07, John Meacham wrote: > >A very big problem with the pragma as it relates to > >Distribution.Extension is that it is unextensable. > > Yet another use case for Andres L?h and Ralf Hinze's open datatypes > [1]. Shame they're still lacking an implementation. > > [1]: http://www.informatik.uni-bonn.de/~loeh/OpenDatatypes.html Well, The mistake is making them a data type at all, cabal doesn't do anything with them other than pass them to the appropriate compiler (perhaps after translating them to flags if the compiler doesn't support the LANGUAGE pragma). it should not have to enumerate a set of valid ones inside its code, just translation tables for the various compilers (or a note saying the compiler supports the LANGUAGE pragma, so the table isn't needed) likewise for the License field and getting rid of all built in preprocessors. cabal is just too inflexible (and much bigger than it needs to be) with so much stuff built in. ideally, the compilers would also not be hard coded into it, but that would be a bigger task but fixing up the rest shouldn't be hard. as a compiler writer, what I would love is if there were a document on the cabal site that said "to allow cabal to use your compiler, have it (or a wrapper) accept the following command line options and do X with them" likewise for a preprocessor or a language extension. none of these should require editing cabals code at all or require people to put something odd in their Setup.hs files to support the new compiler. perhaps what can be done for compiler support is to add a new 'common api' that newer compilers can use and a real --compiler option rather than the current --ghc --hugs hardcoded stuff. it should be just as easy as adding a specific hard-coded 'jhc' target and wouldn't feel so dirty. :) John -- John Meacham - ?repetae.net?john? From stefanor at cox.net Tue May 8 20:55:49 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue May 8 20:52:48 2007 Subject: [Haskell] -compiler-options vs {#-LANGUAGE Flags-#} In-Reply-To: <20070509005137.GA15709@momenergy.repetae.net> References: <20070323212704.GA19807@thened.net> <46051716.9080300@dtek.chalmers.se> <20070405174209.GE16785@momenergy.repetae.net> <20070509005137.GA15709@momenergy.repetae.net> Message-ID: <20070509005549.GA11180@localhost.localdomain> On Tue, May 08, 2007 at 05:51:37PM -0700, John Meacham wrote: > perhaps what can be done for compiler support is to add a new 'common > api' that newer compilers can use and a real --compiler option rather > than the current --ghc --hugs hardcoded stuff. it should be just as easy > as adding a specific hard-coded 'jhc' target and wouldn't feel so dirty. > :) I second John's proposal. Cabal should not be cloning the ugly mess that is Unix build technology. Cabal is a fresh start - if we don't believe that, cabal will become just as nasty as fptools, with the added insult of requiring a Haskell compiler. Stefan From simonpj at microsoft.com Wed May 9 03:13:25 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 9 03:10:25 2007 Subject: problems using ghc-6.6.1 (due to fgl-5.4.1) In-Reply-To: <4640ECA8.5040704@tzi.de> References: <4640ECA8.5040704@tzi.de> Message-ID: Aha! So the problem is a library change rather than a compiler change. That's a relief. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Christian Maeder | Sent: 08 May 2007 22:33 | To: hets-devel@tzi.de; GHC Users Mailing List; libraries@haskell.org | Subject: problems using ghc-6.6.1 (due to fgl-5.4.1) | | I wrote: | > Dear Hets- and GHC-Developers, | | > we have a problem using ghc-6.6.1. The created hets binary runs a | > couple | > of times slower than the one created using ghc-6.6. | | This problem is gone when I install and use fgl-5.3 (where "hiding | (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). | | I strongly suspect the new functions context1l' and context4l' in | Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic | slow down. | | In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic | edge (an edge from and to the very same node) was only returned as | ingoing edge and not as outgoing one. (a design decision documented | elsewhere). | | I think, the change in fgl-5.4.1 now returns a cyclic edge also as | outgoing edge (and possibly twice as ingoing one). | | Our application heavily uses in- and outgoing edges that may be cyclic. | | Christian | | P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From duncan.coutts at worc.ox.ac.uk Wed May 9 04:26:22 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 9 04:37:33 2007 Subject: [Haskell] -compiler-options vs {#-LANGUAGE Flags-#} In-Reply-To: <20070509005549.GA11180@localhost.localdomain> References: <20070323212704.GA19807@thened.net> <46051716.9080300@dtek.chalmers.se> <20070405174209.GE16785@momenergy.repetae.net> <20070509005137.GA15709@momenergy.repetae.net> <20070509005549.GA11180@localhost.localdomain> Message-ID: <1178699182.16518.63.camel@localhost> On Tue, 2007-05-08 at 17:55 -0700, Stefan O'Rear wrote: > On Tue, May 08, 2007 at 05:51:37PM -0700, John Meacham wrote: > > perhaps what can be done for compiler support is to add a new 'common > > api' that newer compilers can use and a real --compiler option rather > > than the current --ghc --hugs hardcoded stuff. it should be just as easy > > as adding a specific hard-coded 'jhc' target and wouldn't feel so dirty. > > :) > > I second John's proposal. Cabal should not be cloning the ugly mess > that is Unix build technology. Cabal is a fresh start - if we don't > believe that, cabal will become just as nasty as fptools, with the > added insult of requiring a Haskell compiler. The issue preventing progress with Cabal is a lack of developers interested in sending patches and implementing all these great ideas that everyone has. Duncan From duncan.coutts at worc.ox.ac.uk Wed May 9 07:16:08 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 9 07:27:20 2007 Subject: darcs patch: Make Gen an instance of Applicative In-Reply-To: <8646ADFE-3884-4015-B919-9B705DBFA61D@cs.chalmers.se> References: <8646ADFE-3884-4015-B919-9B705DBFA61D@cs.chalmers.se> Message-ID: <1178709368.16518.150.camel@localhost> On Tue, 2007-05-08 at 23:57 +0200, Bjorn Bringert wrote: > I like this, but I'm afraid the compatibility price might be too > high. AFAIK, Control.Applicative is only available in base >= 2.0 , > which means that QuickCheck 2 wouldn't work with Haskell > implementations which come with base < 2.0. This means that no > program which wants to be testable with older implementations can > switch to QC2. Yeah, I guess that's true. The applicative stuff is of course just pure Haskell code, it could be packaged for older systems that don't have base 2.0. Ironically the intention of putting it into base was to make it more available, not less so. It's a shame that this blocks progress. This would need Cabal configurations to be able to say that we depend on base > 2.0 or a separate Control.Applicative package. Or as people have suggested before, what we really want to say is that we depend on a particular interface and that happens to be provided by base 2.0. But that's such a huge can of worms. Ho hum. > Is this acceptable instead: return f `ap` a `ap` b `ap` c ? That's > already possible, right? Yeah, you can. It's not nearly as nice though and it doesn't let you use the other applicative functions that rely on the type class. Duncan From maeder at tzi.de Wed May 9 08:26:05 2007 From: maeder at tzi.de (Christian Maeder) Date: Wed May 9 08:23:35 2007 Subject: fgl-5.4.1 In-Reply-To: <4640ECA8.5040704@tzi.de> References: <4640ECA8.5040704@tzi.de> Message-ID: <4641BDDD.4090006@tzi.de> I have adopted our sources now so that they also work with fgl-5.4.1. So neither ghc-6.6.1 nor fgl-5.4.1 need to change. The problem was that "inn" returns loops since fgl-5.4, that led to more edges to be processed (by our function selectProofBasis). Another problem (not relevant for our performance loss, though) is that "inn" and "out" both return the same loops, which may lead to a duplication of loops if reinserted. Further technical comments below. Christian Christian Maeder schrieb: > I wrote: >> Dear Hets- and GHC-Developers, > >> we have a problem using ghc-6.6.1. The created hets binary runs a >> couple >> of times slower than the one created using ghc-6.6. > > This problem is gone when I install and use fgl-5.3 (where "hiding > (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). > > I strongly suspect the new functions context1l' and context4l' in > Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic > slow down. > > In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic > edge (an edge from and to the very same node) was only returned as > ingoing edge and not as outgoing one. (a design decision documented > elsewhere). > > I think, the change in fgl-5.4.1 now returns a cyclic edge also as > outgoing edge (and possibly twice as ingoing one). Exchange in- and outgoing (and cyclic edge with loop). The loops are not duplicated by a single call. Just the function matchGr (method match) from Data.Graph.Inductive.Tree returns the loops as successors only. (Therefore the filtering in context4l' might be just unnecessary for this instance) context1l' :: Context a b -> Adj b context1l' (p,v,_,s) = p++filter ((==v).snd) s context4l' :: Context a b -> Adj b context4l' (p,v,_,s) = s++filter ((==v).snd) p From simonmarhaskell at gmail.com Thu May 10 04:14:18 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 10 04:11:17 2007 Subject: Fwd: Report this to bug-autoconf@gnu.org In-Reply-To: <458732f90705100052w7502be4cj4e9f169e0ce0d41@mail.gmail.com> References: <458732f90705100052w7502be4cj4e9f169e0ce0d41@mail.gmail.com> Message-ID: <4642D45A.3010902@gmail.com> Forwarding to list on behalf of "Marek Burza" . > ---------- Forwarded message ---------- > From: "Marek Burza" > > To: libraries@haskell.org > Date: Thu, 10 May 2007 09:50:23 +0200 > Subject: Fwd: Report this to bug-autoconf@gnu.org > > Hi, > > When I tried to install network package an error ocurred to me > below you can find a more detailed description on what it is and how it > can be fixed > - I figured you might be interested > > Best regards, > Mark > > ---------- Forwarded message ---------- > From: *Ralf Wildenhues* < Ralf.Wildenhues@gmx.de > > > Date: 10-May-2007 08:59 > Subject: Re: Report this to bug-autoconf@gnu.org > > To: Marek Burza < mkburza@gmail.com > > Cc: bug-autoconf@gnu.org > > Hello Marek, > > Thanks for the report. > > * Marek Burza wrote on Wed, May 09, 2007 at 05:57:45PM CEST: > > > > I was trying to install an extension (network-2.0) to Haskell on cygwin > > and I got an error or warning which requested to be reported to you :) > > You can see the output below and if you need more info I'll be glad to > > provide it to you. > [...] > > > checking winsock.h usability... no > > checking winsock.h presence... yes > > configure: WARNING: winsock.h: present but cannot be compiled > > configure: WARNING: winsock.h: check for missing prerequisite headers? > > configure: WARNING: winsock.h: proceeding with the preprocessor's result > > configure: WARNING: ## ------------------------------------ ## > > configure: WARNING: ## Report this to bug-autoconf@gnu.org > . ## > > configure: WARNING: ## ------------------------------------ ## > > checking for winsock.h... yes > [...] > > Please read > > http://www.gnu.org/software/autoconf/manual/html_node/Present-But-Cannot-Be-Compiled.html > > and then show that to the maintainer of the Haskell package, who can > fix this in his package. The error becomes clearer if you look at the > part of the config.log file that deals with this compile failure (and > maybe also some Cygwin documentation). > > > nlv13536@NLVEHVRES2DT1C9 $ runghc Setup.hs build > > Preprocessing library network-2.0.. . > > Building network-2.0... > > cbits\ancilData.c: In function `sendFd': > > > > cbits\ancilData.c:47:0: > > error: variable `msg' has initializer but incomplete type > [...] > > FWIW, these may or may not be followup errors; I don't know. > > Cheers, > Ralf > From isaacdupree at charter.net Thu May 10 16:51:00 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 10 16:46:34 2007 Subject: The Proper Definition of (evaluate :: a -> IO a) In-Reply-To: <20070509005034.GA11135@localhost.localdomain> References: <463C72AD.8050701@charter.net> <20070507111329.3b3b44a6.Malcolm.Wallace@cs.york.ac.uk> <20070507175404.0a2baf30.Malcolm.Wallace@cs.york.ac.uk> <464030FC.4080102@gmail.com> <20070509005034.GA11135@localhost.localdomain> Message-ID: <464385B4.7030107@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan O'Rear wrote: > On Tue, May 08, 2007 at 05:47:27PM -0700, Ashley Yakeley wrote: >> If Isaac's definition is accurate, we might as well generalise it to any >> Monad. > > Isaac's definition is equivalent to the standard evaluate as I proved. > However, my proof could be using misfeatures of IO. Monads like Maybe and [] have no definition of evaluate consistent with all the laws, they only have (return) and (return $!) as distinct possibilities. In which case my definition makes evaluate in those monads be equivalent to (return $!). Which might not be that bad. For monads such as Lazy ST, it is clear that (>>=) cannot be strict in its first argument in order for the laziness to work, so evaluate can be defined with all the laws. In other function-based monads - including IO - it is not so documented or necessary. What is evaluate used for? Based on Google codesearch and my own experiences: In a forkIO for the sole purpose of parallel evaluation. Could be summarized by: forkEvaluate :: a -> IO a forkEvaluate a = forkIO (evaluate a >> return ()) Aren't there supposed to be more functional ways like `par` to achieve this? Anyway, looks like that definition only works in the IO monad. To immediately catch exceptions from it (Control.Exception.catch or try). This also only works in the IO monad (or derived monads that can define catch... there is always (liftIO . evaluate) I guess). To simply make things be evaluated sooner. This is sometimes necessary, to counteract the effects of file-reading using unsafeInterleaveIO, for example. I haven't seen this use in non-IO monads (which might violate separation of concerns) but it could be. In practice, even in IO code, (return $!) ends up being used. After all it is not hidden away in a Control.Exception module (that is officially non-portable perhaps). No opinion :) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQ4W0HgcxvIWYTTURAiXIAKDWeixSdezmSz2bGCfxZ1Ox3MYMHQCghVKh xe9UYKbp/IVkx3t6thYj/xM= =ZmRd -----END PGP SIGNATURE----- From dominic.steinitz at blueyonder.co.uk Sun May 13 05:04:40 2007 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sun May 13 05:32:04 2007 Subject: Is there already a list class? References: 20070110015252.GA29286@gmx.de Message-ID: <4646D4A8.3070706@blueyonder.co.uk> Did anything ever come of this discussion? http://www.haskell.org/pipermail/libraries/2007-January/006704.html I found myself writing this the other day to capture the fact that IA5 characters are the building blocks of IA5 strings. Dominic. newtype IA5String = IA5String {unIA5String :: String} newtype IA5Char = IA5Char {unIA5Char :: Char} class List a b | a -> b where nil :: b cons :: a -> b -> b instance List IA5Char IA5String where nil = IA5String [] cons x y = IA5String ((unIA5Char x):(unIA5String y)) From waldmann at imn.htwk-leipzig.de Tue May 15 05:26:20 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue May 15 05:23:02 2007 Subject: cgi-compat and ghc-6.6.1 Message-ID: <46497CBC.4050905@imn.htwk-leipzig.de> What is the status of cgi-compat with ghc-6.6.1? I have some older code that wants Network.CGI.Compat, which seems not available in ghc-6.6.1 standard installation. When I build cgi-compat from source cgi-compat-2006.9.6.tar.gz it will complain about missing "fps". I delete this requirement from cgi.cabal and then can build and install. But now when I compile my program, the message is Could not find module `Network.CGI.Compat': it was found in multiple packages: cgi-compat-2006.9.6 cgi-3001.1.1 I can ghc-pkg hide cgi-3001.1.1 and that seems to solve it for the moment. If I find the time, I probably should change my sources to use the newer API - is there a "migration guide" somewhere? Best regards, Johannes Waldmann. From bringert at cs.chalmers.se Tue May 15 09:00:15 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Tue May 15 08:51:11 2007 Subject: cgi-compat and ghc-6.6.1 In-Reply-To: <46497CBC.4050905@imn.htwk-leipzig.de> References: <46497CBC.4050905@imn.htwk-leipzig.de> Message-ID: <4649AEDF.7030605@cs.chalmers.se> Johannes Waldmann wrote: > What is the status of cgi-compat with ghc-6.6.1? > > I have some older code that wants Network.CGI.Compat, > which seems not available in ghc-6.6.1 standard installation. > > When I build cgi-compat from source cgi-compat-2006.9.6.tar.gz > it will complain about missing "fps". I delete this requirement > from cgi.cabal and then can build and install. > > But now when I compile my program, the message is > Could not find module `Network.CGI.Compat': > it was found in multiple packages: > cgi-compat-2006.9.6 cgi-3001.1.1 The problem here is name confusion. Unfortunately, the name cgi-compat has nothing to do with the Network.CGI.Compat module. compat in the former stands for "compatible with ghc < 6.6", or more precisely, with base < 2.0 and network < 2.0. If you want the Network.CGI.Compat module, install an older version of the cgi package, e.g. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cgi-3000.0.0 > I can ghc-pkg hide cgi-3001.1.1 and that seems to solve it > for the moment. If I find the time, I probably should change my sources > to use the newer API - is there a "migration guide" somewhere? There's no migration guide, only the haddock docs: http://www.haskell.org/ghc/docs/latest/html/libraries/cgi/Network-CGI.html However, since the old API was so limited, you'll probably only need 'getInput', 'getVar', 'output', and 'runCGI'. /Bj?rn From rob at mits.coop Wed May 16 09:01:03 2007 From: rob at mits.coop (Robert Marlow) Date: Wed May 16 08:57:58 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1174403822.3736.347.camel@localhost> References: <1174403822.3736.347.camel@localhost> Message-ID: <1179320463.24910.151.camel@localhost> There doesn't seem to be any further concerns about this patch and it has been tested against ia32 linux ghc and hugs. Can this patch now be accepted or can somebody test it against windows? On Wed, 2007-03-21 at 00:17 +0900, Robert Marlow wrote: > I've made a proposal to add ByteString based datagram communication to > Network.Socket and Network. Details are at: > > http://hackage.haskell.org/trac/ghc/ticket/1238#preview > > I rushed to get this done before I go on a trip tomorrow so I haven't > completed testing and won't be available to discuss it for the next 9 > days. As such, if discussion is needed, an extended deadline would be > appreciated. > > Testing windows is a bit awkward for me since I don't have a windows > machine, so if anyone can test that platform I'd be very appreciative. > I'll try to work through the problems I was having with hugs and test > when I get back unless someone else wants to test it first. > > Thanks. > -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From droundy at darcs.net Wed May 16 12:19:50 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 16 12:16:24 2007 Subject: darcs patch: fix failure to compile with cabal included with ghc 6.6 Message-ID: I'm not sure if this is sufficient, or even a good idea, but removing this type signature makes Setup.hs able to run on my system with an older cabal. David Wed May 16 09:18:47 PDT 2007 David Roundy * fix failure to compile with cabal included with ghc 6.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 628 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070516/6e126793/attachment.bin From droundy at darcs.net Wed May 16 12:23:02 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 16 12:19:36 2007 Subject: darcs patch: fix failure to compile with cabal included with ghc 6.6 In-Reply-To: References: Message-ID: <20070516162300.GD24339@abridgegame.org> On Wed, May 16, 2007 at 09:19:50AM -0700, David Roundy wrote: > I'm not sure if this is sufficient, or even a good idea, but > removing this type signature makes Setup.hs able to run on my > system with an older cabal. > > David > > Wed May 16 09:18:47 PDT 2007 David Roundy > * fix failure to compile with cabal included with ghc 6.6 It doesn't look like this patch will do me much good, since as far as I can tell, include/HsX11Config.h.in isn't included in the darcs repository, but is required for building X11. It'd probably be a good idea to add it. -- David Roundy Department of Physics Oregon State University From droundy at darcs.net Wed May 16 12:28:16 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 16 12:24:49 2007 Subject: darcs patch: add test that X11 will actually build. Message-ID: Just for future benefits, it seems a good idea to occasionally check that the X11 library actually can be built. This patch is untested, since the X11 library won't build for me. David Wed May 16 09:26:26 PDT 2007 David Roundy * add test that X11 will actually build. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 428 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070516/844dfeab/attachment.bin From ross at soi.city.ac.uk Wed May 16 12:43:33 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed May 16 12:40:05 2007 Subject: darcs patch: fix failure to compile with cabal included with ghc 6.6 In-Reply-To: <20070516162300.GD24339@abridgegame.org> References: <20070516162300.GD24339@abridgegame.org> Message-ID: <20070516164333.GA8405@soi.city.ac.uk> On Wed, May 16, 2007 at 09:23:02AM -0700, David Roundy wrote: > It doesn't look like this patch will do me much good, since as far as I can > tell, include/HsX11Config.h.in isn't included in the darcs repository, but > is required for building X11. It'd probably be a good idea to add it. It's a generated file -- when building this package with Cabal directly from darcs it's necessary to run autoreconf before doing anything else. From droundy at darcs.net Wed May 16 12:55:58 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 16 12:52:31 2007 Subject: darcs patch: fix failure to compile with cabal includ... (and 1 more) Message-ID: Here's a fixed patch for testing that X11 actually builds. This time it calls autoreconf as the README instructs. David Wed May 16 09:18:47 PDT 2007 David Roundy * fix failure to compile with cabal included with ghc 6.6 Wed May 16 09:55:02 PDT 2007 David Roundy * add fixed test that X11 builds -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 809 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070516/5056d77b/attachment.bin From droundy at darcs.net Wed May 16 13:00:25 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 16 12:56:58 2007 Subject: darcs patch: fix failure to compile with cabal included with ghc 6.6 In-Reply-To: <20070516164333.GA8405@soi.city.ac.uk> References: <20070516162300.GD24339@abridgegame.org> <20070516164333.GA8405@soi.city.ac.uk> Message-ID: <20070516170022.GE24339@abridgegame.org> On Wed, May 16, 2007 at 05:43:33PM +0100, Ross Paterson wrote: > On Wed, May 16, 2007 at 09:23:02AM -0700, David Roundy wrote: > > It doesn't look like this patch will do me much good, since as far as I can > > tell, include/HsX11Config.h.in isn't included in the darcs repository, but > > is required for building X11. It'd probably be a good idea to add it. > > It's a generated file -- when building this package with Cabal directly > from darcs it's necessary to run autoreconf before doing anything else. Sorry about that, I did read that README, but read it a little too quickly and ran autoconf rather than autoreconf. Sorry about that! -- David Roundy Department of Physics Oregon State University From bos at serpentine.com Thu May 17 02:02:22 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu May 17 02:00:19 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1179320463.24910.151.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1179320463.24910.151.camel@localhost> Message-ID: <464BEFEE.5030409@serpentine.com> Robert Marlow wrote: > There doesn't seem to be any further concerns about this patch and it > has been tested against ia32 linux ghc and hugs. Can this patch now be > accepted or can somebody test it against windows? For a single patch, it does rather a lot of different things. It should at least be split into four different patches. Also, am I not mistaken, or does it not change the existing API? -sendTo, -- :: HostName -> PortID -> String -> IO () +sendTo, -- :: HostName -> PortID -> B.ByteString -> IO Socket +sendTo_, -- :: HostName -> PortID -> B.ByteString -> IO () References: <20070516162300.GD24339@abridgegame.org> <20070516164333.GA8405@soi.city.ac.uk> <20070516170022.GE24339@abridgegame.org> Message-ID: <464BF025.1010600@serpentine.com> David Roundy wrote: > Sorry about that, I did read that README, but read it a little too quickly > and ran autoconf rather than autoreconf. Sorry about that! I get bitten by forgetting to run autoreconf all the time :-( References: <1174403822.3736.347.camel@localhost> <1179320463.24910.151.camel@localhost> <464BEFEE.5030409@serpentine.com> Message-ID: <1179385444.24910.185.camel@localhost> The old API is considered only useful for "testing" anyway, since it uses hGetContents and consequently can cause open socket leaks. This patch is intended to make those functions more useful and closer to what a network programmer might expect from a functions named sendTo / recvFrom. How do you think the patch should be broken up and why? On Wed, 2007-05-16 at 23:02 -0700, Bryan O'Sullivan wrote: > Robert Marlow wrote: > > There doesn't seem to be any further concerns about this patch and it > > has been tested against ia32 linux ghc and hugs. Can this patch now be > > accepted or can somebody test it against windows? > > For a single patch, it does rather a lot of different things. It should > at least be split into four different patches. > > Also, am I not mistaken, or does it not change the existing API? > > -sendTo, -- :: HostName -> PortID -> String -> IO () > +sendTo, -- :: HostName -> PortID -> B.ByteString -> IO Socket > +sendTo_, -- :: HostName -> PortID -> B.ByteString -> IO () > > -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From waldmann at imn.htwk-leipzig.de Thu May 17 10:38:53 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu May 17 10:35:24 2007 Subject: terminateProcess Message-ID: <464C68FD.1070001@imn.htwk-leipzig.de> according to documentation of System.Process.terminateProcess, "This function should not be used under normal circumstances." Well, then what function then *should* be used normally? I have the following code in a multithreaded Haskell program, which does not work (if this thread is killed, the external process keeps running after the Haskell program exits) bracket ( System.Process.runCommand cmd ) ( terminateProcess p ) ( polling_waitForProcess ) It took me a while to figure out why "waitForProcess" here does not work: Control.Concurrent.throwTo says "If the target thread is currently making a foreign call, then the exception will not be raised (and hence throwTo will not return until the call has completed.") That's why I defined let polling_waitForProcess p = do me <- getProcessExitCode p case me of Just e -> return () Nothing -> do threadDelay ( 10^5 ) polling_waitForProcess p any hints appreciated, J.W. From bos at serpentine.com Thu May 17 10:50:19 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu May 17 10:46:49 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1179385444.24910.185.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1179320463.24910.151.camel@localhost> <464BEFEE.5030409@serpentine.com> <1179385444.24910.185.camel@localhost> Message-ID: <464C6BAB.8010008@serpentine.com> Robert Marlow wrote: > The old API is considered only useful for "testing" anyway, since it > uses hGetContents and consequently can cause open socket leaks. This > patch is intended to make those functions more useful and closer to what > a network programmer might expect from a functions named sendTo / > recvFrom. That's fair enough, but this kind of rationale belongs in the header of the patch that makes that change, so that people won't be scratching their heads, wondering what happened. > How do you think the patch should be broken up and why? The description of the patch says that it does four different things. That's your cue :-) References: <1174403822.3736.347.camel@localhost> <1179320463.24910.151.camel@localhost> <464BEFEE.5030409@serpentine.com> <1179385444.24910.185.camel@localhost> <464C6BAB.8010008@serpentine.com> Message-ID: <1179443868.24910.217.camel@localhost> On Thu, 2007-05-17 at 07:50 -0700, Bryan O'Sullivan wrote: > That's fair enough, but this kind of rationale belongs in the header of > the patch that makes that change, so that people won't be scratching > their heads, wondering what happened. Oh! Thanks for pointing that out. Fixed. > The description of the patch says that it does four different things. > That's your cue :-) Oh I see what you mean. They're all related to the same change. I've changed the patch header to try to explain that too. The overall goal of fixing up sendTo / recvFrom in Network is simpler to achieve with the listed changes. Given those additional changes wouldn't be terribly important if it weren't for the the implementation of datagram communication in Network, I don't think it's a good idea to split the patch up. -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From simonmarhaskell at gmail.com Fri May 18 08:55:55 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri May 18 08:52:31 2007 Subject: terminateProcess In-Reply-To: <464C68FD.1070001@imn.htwk-leipzig.de> References: <464C68FD.1070001@imn.htwk-leipzig.de> Message-ID: <464DA25B.70800@gmail.com> Johannes Waldmann wrote: > according to documentation of System.Process.terminateProcess, > "This function should not be used under normal circumstances." > Well, then what function then *should* be used normally? You just shouldn't terminate processes, unless you know that the process you're terminating won't mind. terminateProcess doesn't necessarily give the victim a chance to clean up - on Unix it gets a SIGTERM but on Windows it gets summarily executed (because there's no other way to terminate processes on Windows, AFAIK). So if your process needs to clean up on exit, you shouldn't use terminateProcess. > I have the following code in a multithreaded Haskell program, > which does not work (if this thread is killed, > the external process keeps running after the Haskell program exits) > > bracket > ( System.Process.runCommand cmd ) > ( terminateProcess p ) > ( polling_waitForProcess ) > > It took me a while to figure out why "waitForProcess" here > does not work: Control.Concurrent.throwTo says > "If the target thread is currently making a foreign call, then the > exception will not be raised (and hence throwTo will not return > until the call has completed.") So you can work around this using an extra thread and an MVar: something like myWaitForProcess p = do m <- newEmptyMVar forkIO $ do r <- waitForProcess p; putMVar m r takeMVar m as for why your code doesn't kill the process, I'm not exactly sure. What platform? If Unix, perhaps the process is ignoring SIGTERM? You might have to wait a little while for the process to shutdown. For example code that uses terminateProcess, you could look at http://darcs.haskell.org/testsuite/timeout/timeout.hs Cheers, Simon From bertram.felgenhauer at googlemail.com Sat May 19 09:57:59 2007 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat May 19 09:54:49 2007 Subject: darcs patch: base.cabal: install all include files from include/ Message-ID: <1179583079.17812@zombie> Hi, the base package needs to install some more header files to make compilations via C work properly (as required, for example, by gtk2hs). This can now be done properly with Cabal. See the patch below. Bertram Sat May 19 15:47:19 CEST 2007 Bertram Felgenhauer * base.cabal: install all include files from include/ many of them are needed by HsBase.h; Typeable.h is useful for Haskell code -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 56675 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070519/e15e9715/attachment-0001.bin From igloo at earth.li Sun May 20 12:45:29 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun May 20 12:41:49 2007 Subject: darcs patch: add test that X11 will actually build. In-Reply-To: References: Message-ID: <20070520164529.GA11396@matrix.chaos.earth.li> Hi David, On Wed, May 16, 2007 at 09:28:16AM -0700, David Roundy wrote: > Just for future benefits, it seems a good idea to occasionally > check that the X11 library actually can be built. The nightly builds check that the library can be built. > changepref test > > runhaskell Setup.hs configure && runhaskell Setup.hs build My opinion is that this (building the package every time you run "darcs record") is too expensive, and will just mean everyone adds --no-test to their default arguments. Also, Setup won't necessarily find a compiler that can compile the HEAD versions of the libraries. If other developers think it is useful then we could add this test, though, as it's easier to opt-out (by adding --no-test to the defaults) than to opt-in. Thanks Ian From igloo at earth.li Sun May 20 13:20:18 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun May 20 13:16:36 2007 Subject: darcs patch: fix failure to compile with cabal included with ghc 6.6 In-Reply-To: References: Message-ID: <20070520172018.GB11396@matrix.chaos.earth.li> Hi David, On Wed, May 16, 2007 at 09:19:50AM -0700, David Roundy wrote: > > { > hunk ./Setup.hs 47 > > type Hook a = PackageDescription -> LocalBuildInfo -> UserHooks -> a -> IO () > > -add_ghc_options :: [String] -> Hook a -> Hook a Thanks for the patch! I've applied something similar, with a comment as to why it's done. Thanks Ian From bos at serpentine.com Mon May 21 00:43:36 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon May 21 00:41:59 2007 Subject: IPv6 support patches for network - please apply Message-ID: <46512378.8090605@serpentine.com> Hi - As there's been no recent discussion of my patches to add IPv6 support to the network library, and I've resolved every question and comment that people had, I propose that they now be applied. The trac ticket is here: http://hackage.haskell.org/trac/ghc/ticket/1212 And the darcs patches against network are here: http://darcs.serpentine.com/network6 Thanks, References: <46267118.9050107@imn.htwk-leipzig.de> <46267898.70906@charter.net> Message-ID: On Wed, 18 Apr 2007, Isaac Dupree wrote: > And then what do you do with (set1 `union` set2) where they have > different comparators? C++ collections have that think-o, I don't know > about Java.... the problem being that the comparators are not statically > required to be "the same", just the same *type*, so, what do you do with > two different ones? I expect that local instances of equal types provide equal method dictionaries, don't they? However I don't think that local instances solve the problem here. Locally used (<) for complex numbers should be regarded the same error like (<) for complex numbers everywhere. From rt014i7347 at blueyonder.co.uk Mon May 21 17:31:51 2007 From: rt014i7347 at blueyonder.co.uk (Stephen Tetley) Date: Mon May 21 17:27:53 2007 Subject: anyone interested in developing a Language.C library? Message-ID: <46520FC7.1020903@blueyonder.co.uk> Hello I've a Frown port of the c2hs parser here: http://slackwise.org/spt/files/Haskell/lang_c-2007_05_21.tar.gz I've also done some work towards packaging the original c2hs code so it follows the form of the Language/Haskell library (removed the 'C' prefix from file names, added Haddock markers in some of the comments). Other changes include some work to handle GCC attributes (added in the syntax tree and some of the productions in the parser); and some work on a pretty printer (there is a rough version implemented with UUAG and the PPrint library that needs better parens handling). Also I've changed the AST slightly to remove some of the dependency on c2hs - the parser just tracks source position rather than source locations and unique names. I haven't looked further at disentangling the Happy parser, and with the changes to the syntax tree and file layout it would need some work to reinstate it. I hope to look at this in the next couple of weeks. Best wishes Stephen Tetley Duncan Coutts wrote: > * The parser error messages are terrible (it might be interesting > to try porting from happy to frown for this purpose) From agl at imperialviolet.org Tue May 22 13:28:24 2007 From: agl at imperialviolet.org (Adam Langley) Date: Tue May 22 13:24:37 2007 Subject: darcs patch: Add proximal lookup functions in Map (and 2 more) In-Reply-To: References: <20070522172130.BFE7F26AE2C@localhost> Message-ID: <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> Please see attached 2 patches (and 1 misc patch) to Data.Map which add the ability to lookup entries by proximity. For example, if I have a Map which relates times to the state of a system at that time: let m = Map.fromList [(1, x), (10, y), (15, z)] Then, if I want to find out the state at time 5: Map.nearestLesserOrEqual 5 m -> (1, x) In a similar fashion, nearestGreaterOrEqual and nearest are also provided. Thanks AGL Tue May 22 10:15:05 PDT 2007 agl@imperialviolet.org * Add proximal lookup functions in Map These functions require the key to be an instance of Num, because they use the numerical distance, |x-y|, to find elements in a map which are close to a query key. This is useful, for example, if the map is mapping times to state changes and you want to find out the state at any given time. Tue May 22 10:16:00 PDT 2007 agl@imperialviolet.org * Update deprecated Debug.QuickCheck name Tue May 22 10:16:28 PDT 2007 agl@imperialviolet.org * Add tests for proximal lookup functions -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 62692 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070522/de2fff9d/attachment-0001.bin From ross at soi.city.ac.uk Tue May 22 13:41:47 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue May 22 13:38:01 2007 Subject: darcs patch: Add proximal lookup functions in Map (and 2 more) In-Reply-To: <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> References: <20070522172130.BFE7F26AE2C@localhost> <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> Message-ID: <20070522174147.GA14513@soi.city.ac.uk> On Tue, May 22, 2007 at 10:28:24AM -0700, Adam Langley wrote: > Please see attached 2 patches (and 1 misc patch) to Data.Map which add > the ability to lookup entries by proximity. For example, if I have a > Map which relates times to the state of a system at that time: > let m = Map.fromList [(1, x), (10, y), (15, z)] > Then, if I want to find out the state at time 5: > Map.nearestLesserOrEqual 5 m > -> (1, x) > > In a similar fashion, nearestGreaterOrEqual and nearest are also provided. nearest needs Num, but the other two shouldn't. From agl at imperialviolet.org Tue May 22 16:48:08 2007 From: agl at imperialviolet.org (Adam Langley) Date: Tue May 22 16:44:22 2007 Subject: darcs patch: Add proximal lookup functions in Map (and 2 more) In-Reply-To: <20070522174147.GA14513@soi.city.ac.uk> References: <20070522172130.BFE7F26AE2C@localhost> <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> <20070522174147.GA14513@soi.city.ac.uk> Message-ID: <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> On 5/22/07, Ross Paterson wrote: > nearest needs Num, but the other two shouldn't. That's a great point, I hadn't thought about that. I don't know if people usually send a correction patch, or remake the patch but I've done the former: Tue May 22 13:41:29 PDT 2007 agl@imperialviolet.org * Num k isn't needed for nearestGreaterOrEqual nor nearestLesserOrEqual -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 -------------- next part -------------- A non-text attachment was scrubbed... Name: map-correction Type: application/octet-stream Size: 62185 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070522/5935f414/map-correction-0001.obj From dagit at codersbase.com Tue May 22 18:02:32 2007 From: dagit at codersbase.com (Jason Dagit) Date: Tue May 22 17:58:43 2007 Subject: darcs patch: Add proximal lookup functions in Map (and 2 more) In-Reply-To: <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> References: <20070522172130.BFE7F26AE2C@localhost> <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> <20070522174147.GA14513@soi.city.ac.uk> <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> Message-ID: On 5/22/07, Adam Langley wrote: > On 5/22/07, Ross Paterson wrote: > > nearest needs Num, but the other two shouldn't. > > That's a great point, I hadn't thought about that. I don't know if > people usually send a correction patch, or remake the patch but I've > done the former: I can't speak for the protocol of this libraries list, but in darcs-devel people usually use 'amend-record' when the changes are small (like correcting a typo). Jason From isaacdupree at charter.net Tue May 22 18:20:35 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue May 22 18:15:21 2007 Subject: darcs patch: Add ... darcs patch revision protocol In-Reply-To: References: <20070522172130.BFE7F26AE2C@localhost> <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> <20070522174147.GA14513@soi.city.ac.uk> <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> Message-ID: <46536CB3.6070104@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Dagit wrote: > On 5/22/07, Adam Langley wrote: >> On 5/22/07, Ross Paterson wrote: >> > nearest needs Num, but the other two shouldn't. >> >> That's a great point, I hadn't thought about that. I don't know if >> people usually send a correction patch, or remake the patch but I've >> done the former: > > I can't speak for the protocol of this libraries list, but in > darcs-devel people usually use 'amend-record' when the changes are > small (like correcting a typo). I prefer making another patch and sending the two patches together, as per the darcs manual http://www.darcs.net/manual/node7.html#SECTION00791000000000000000 in case someone else has already applied the first patch, it makes darcs work better. (the changelog-spamming effect is unfortunate, maybe there should be some convention to distinguish how important a change is, like wikipedia's minor edits? "MINOR: blah blah"... but I don't like that judgement call. Does anyone mind the extra patch-count much?) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGU2yzHgcxvIWYTTURApCaAKC8qNom2LZLgWG2qJiLZfLDner86wCgglfN XZQCVnTO+bxleUBA48prj1Q= =pBt0 -----END PGP SIGNATURE----- From igloo at earth.li Tue May 22 20:42:59 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue May 22 20:39:10 2007 Subject: darcs patch: base.cabal: install all include files from include/ In-Reply-To: <1179583079.17812@zombie> References: <1179583079.17812@zombie> Message-ID: <20070523004259.GA12950@matrix.chaos.earth.li> Hi Bertram, On Sat, May 19, 2007 at 03:57:59PM +0200, Bertram Felgenhauer wrote: > > the base package needs to install some more header files to make > compilations via C work properly (as required, for example, by gtk2hs). > This can now be done properly with Cabal. See the patch below. Thanks for the patch. However, in my working tree the header files have moved around a bit as a result of breaking up base; I'll look into doing the equivalent once the dust has settled. Thanks Ian From shae at ScannedInAvian.com Thu May 24 12:47:48 2007 From: shae at ScannedInAvian.com (shae@ScannedInAvian.com) Date: Thu May 24 12:44:06 2007 Subject: darcs patch: Control.Concurrent documentation fix Message-ID: <20070524164748.8E87D5BA44@thunderbird.scannedinavian.com> Thu May 24 11:33:25 CDT 2007 shae@ScannedInAvian.com * Control.Concurrent documentation fix -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 57442 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070524/93ca1914/attachment-0001.bin From isaacdupree at charter.net Sat May 26 18:12:28 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat May 26 18:07:04 2007 Subject: darcs patch revision protocol In-Reply-To: <46536CB3.6070104@charter.net> References: <20070522172130.BFE7F26AE2C@localhost> <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> <20070522174147.GA14513@soi.city.ac.uk> <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> <46536CB3.6070104@charter.net> Message-ID: <4658B0CC.2000209@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (cc'ing darcs-users as this is really a darcs issue) Isaac Dupree wrote: > Jason Dagit wrote: >> On 5/22/07, Adam Langley wrote: >>> On 5/22/07, Ross Paterson wrote: >>>> nearest needs Num, but the other two shouldn't. >>> That's a great point, I hadn't thought about that. I don't know if >>> people usually send a correction patch, or remake the patch but I've >>> done the former: >> I can't speak for the protocol of this libraries list, but in >> darcs-devel people usually use 'amend-record' when the changes are >> small (like correcting a typo). > > I prefer making another patch and sending the two patches together, as > per the darcs manual > http://www.darcs.net/manual/node7.html#SECTION00791000000000000000 > in case someone else has already applied the first patch, it makes darcs > work better. (the changelog-spamming effect is unfortunate hmm, would it make any sense for an amended patch to list the identities/hashes of the patches that are obsoleted by it, so that this effect isn't such a problem? (Then there would be a functional reason to use amend-record, so I could complain that there doesn't seem to be a way to remove modifications from a patch using amend-record, just to add them) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGWLDLHgcxvIWYTTURArouAKC7jDqiNzL6/K2rvphiA6AiFnEf6wCg1J0+ F86+1fkAxTinzsHBlpNm0TE= =GH0o -----END PGP SIGNATURE----- From Andreas-Haskell at gmx.net Tue May 29 12:27:11 2007 From: Andreas-Haskell at gmx.net (Andreas Marth) Date: Tue May 29 12:26:13 2007 Subject: package haskell-src depending on happy? Message-ID: <147001c7a20e$363f52f0$6702a8c0@GPO> Hi! I just tried to install haskell-src with cabal and passed 'runhaskell setup.hs configure' but 'runhaskell setup.hs build' died with "Language\Haskell\Parser.ly: no happy preprocessor available". This looks to me like happy is required for haskell-src, but it is not mentenied in the dependencies. Do I really have to install happy? (In the past that was a nightmare if I remember correctly.) My system is Win2k and ghc-6.1.1. Kind regards Andreas From igloo at earth.li Tue May 29 16:31:01 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue May 29 16:27:04 2007 Subject: darcs patch: Control.Concurrent documentation fix In-Reply-To: <20070524164748.8E87D5BA44@thunderbird.scannedinavian.com> References: <20070524164748.8E87D5BA44@thunderbird.scannedinavian.com> Message-ID: <20070529203101.GA25615@matrix.chaos.earth.li> On Thu, May 24, 2007 at 11:47:48AM -0500, shae@ScannedInAvian.com wrote: > Thu May 24 11:33:25 CDT 2007 shae@ScannedInAvian.com > * Control.Concurrent documentation fix Applied, thanks! Ian From dons at cse.unsw.edu.au Wed May 30 03:09:32 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 30 03:05:23 2007 Subject: uploading tagged core/extra libs to hackage Message-ID: <20070530070932.GA25170@cse.unsw.EDU.AU> After the recent GHC 6.6.1 release, a number of the core and extra libs got new tags. In particular, xmonad wants X11 1.2.1, which was tagged during the 6.6.1 ghc release, but not uploaded to hackage. Igloo, could these newly tagged libs be uploaded? (We're holding up an xmonad release, to get X11 1.2.1 onto hackage first) -- Don From simonmarhaskell at gmail.com Wed May 30 06:00:49 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 30 05:56:41 2007 Subject: package haskell-src depending on happy? In-Reply-To: <147001c7a20e$363f52f0$6702a8c0@GPO> References: <147001c7a20e$363f52f0$6702a8c0@GPO> Message-ID: <465D4B51.3090109@gmail.com> Andreas Marth wrote: > I just tried to install haskell-src with cabal and passed 'runhaskell > setup.hs configure' but 'runhaskell setup.hs build' died with > "Language\Haskell\Parser.ly: no happy preprocessor available". > This looks to me like happy is required for haskell-src, but it is not > mentenied in the dependencies. Yes haskell-src does require happy, dependencies only mention libraries which is why you don't see it there. > Do I really have to install happy? (In the past that was a nightmare if I > remember correctly.) > My system is Win2k and ghc-6.1.1. Happy should be easy to install on Windows. There's a binary zip file you can unpack anywhere you like, or you can build from source using Cabal. http://www.haskell.org/happy Cheers, Simon From simonmarhaskell at gmail.com Wed May 30 06:09:55 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 30 06:05:46 2007 Subject: HUnit broken for GHC In-Reply-To: <461F860E.6060503@cs.tu-berlin.de> References: <461F860E.6060503@cs.tu-berlin.de> Message-ID: <465D4D73.1020704@gmail.com> Martin Grabmueller wrote: > > I noticed that HUnit does not work for GHC when trying to build > some HUnit test cases for my code. > > There is already an (old) entry in the GHC bugtracker > > http://cvs.haskell.org/trac/ghc/ticket/476 > > about this issue, which contained a patch. Somehow, this patch > never made it into the HUnit repository. I have tried out the > patch with the HUnit and GHC fresh from darcs, and it seemed to > work. > > So my question is: what is the procedure for getting this patch > into the official darcs repository? A simple "darcs send"? I've applied and pushed the patch, sorry for the delay. Cheers, Simon From igloo at earth.li Wed May 30 07:58:59 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed May 30 07:55:00 2007 Subject: IPv6 support patches for network - please apply In-Reply-To: <46512378.8090605@serpentine.com> References: <46512378.8090605@serpentine.com> Message-ID: <20070530115859.GA14023@matrix.chaos.earth.li> On Sun, May 20, 2007 at 09:43:36PM -0700, Bryan O'Sullivan wrote: > > As there's been no recent discussion of my patches to add IPv6 support > to the network library, and I've resolved every question and comment > that people had, I propose that they now be applied. Now done; thanks! Ian From bos at serpentine.com Wed May 30 11:56:58 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed May 30 11:53:42 2007 Subject: IPv6 support patches for network - please apply In-Reply-To: <20070530115859.GA14023@matrix.chaos.earth.li> References: <46512378.8090605@serpentine.com> <20070530115859.GA14023@matrix.chaos.earth.li> Message-ID: <465D9ECA.7000503@serpentine.com> Ian Lynagh wrote: > Now done; thanks! Hooray, thanks! Are there plans for a 6.6.2 release of GHC that might include this, or is it likely to wait until 6.8? I'm trying to figure out which API to write up for the book. References: <46512378.8090605@serpentine.com> <20070530115859.GA14023@matrix.chaos.earth.li> <465D9ECA.7000503@serpentine.com> Message-ID: <20070530162057.GA15690@matrix.chaos.earth.li> On Wed, May 30, 2007 at 08:56:58AM -0700, Bryan O'Sullivan wrote: > > Are there plans for a 6.6.2 release of GHC that might include this, or > is it likely to wait until 6.8? I'm trying to figure out which API to > write up for the book. The plan is not to release 6.6.2, and if we do release it then it probably wouldn't have this change anyway (it would probably use the exact same extralibs as 6.6.1, as the old build system has been removed from the extralibs now). It will be in 6.8 (in as much as the extralibs are "in" GHC releases) which is tentatively scheduled for sometime this summer. Of course, the point of extralibs is that network can be released asynchronously, so you can use it with 6.6.1 today should you wish. Personally, I'd therefore recommend writing up the new API. Thanks Ian From sjanssen at cse.unl.edu Wed May 30 14:21:21 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Wed May 30 14:17:56 2007 Subject: uploading tagged core/extra libs to hackage In-Reply-To: <20070530070932.GA25170@cse.unsw.EDU.AU> References: <20070530070932.GA25170@cse.unsw.EDU.AU> Message-ID: <20070530132121.5b965c1f@localhost> On Wed, 30 May 2007 17:09:32 +1000 dons@cse.unsw.edu.au (Donald Bruce Stewart) wrote: > After the recent GHC 6.6.1 release, a number of the core and extra > libs got new tags. > > In particular, xmonad wants X11 1.2.1, which was tagged during the > 6.6.1 ghc release, but not uploaded to hackage. > > Igloo, could these newly tagged libs be uploaded? (We're holding up > an xmonad release, to get X11 1.2.1 onto hackage first) > > -- Don X11 1.2.1 wasn't quite suitable for release (the Setup.hs isn't compatible with old Cabal versions), so I've tagged X11 1.2.2 with Igloo's blessing. The patches are in the repo, waiting for a person with a hackage account. Cheers, Spencer Janssen From agl at imperialviolet.org Wed May 30 14:33:59 2007 From: agl at imperialviolet.org (Adam Langley) Date: Wed May 30 14:29:58 2007 Subject: darcs patch: Add proximal lookup functions in Map (and 2 more) In-Reply-To: <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> References: <20070522172130.BFE7F26AE2C@localhost> <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> <20070522174147.GA14513@soi.city.ac.uk> <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> Message-ID: <396556a20705301133o6b0e49d3w118a8f4a246927b3@mail.gmail.com> On 5/22/07, Adam Langley wrote: > That's a great point, I hadn't thought about that. I don't know if > people usually send a correction patch, or remake the patch but I've > done the former: Well, I don't think we had a clear resolution on the patch protocol, so this is just a note to say that I think these four patches are ready to be merged if someone with the power considers the extra functions to be worth the extra code. thanks AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From Malcolm.Wallace at cs.york.ac.uk Thu May 31 06:21:14 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu May 31 06:19:16 2007 Subject: darcs patch: Add proximal lookup functions in Map (and 2 more) In-Reply-To: <396556a20705301133o6b0e49d3w118a8f4a246927b3@mail.gmail.com> References: <20070522172130.BFE7F26AE2C@localhost> <396556a20705221028u3d8e61e1i4627117de23e9c5f@mail.gmail.com> <20070522174147.GA14513@soi.city.ac.uk> <396556a20705221348u5b85b4dq8ae41d4ad983e91c@mail.gmail.com> <396556a20705301133o6b0e49d3w118a8f4a246927b3@mail.gmail.com> Message-ID: <20070531112114.066a7c15.Malcolm.Wallace@cs.york.ac.uk> "Adam Langley" wrote: > > That's a great point, I hadn't thought about that. I don't know if > > people usually send a correction patch, or remake the patch but I've > > done the former: In general, the rule would be that a patch published only by email can be amended at low cost, since very few people apply such patches directly to their own repositories. Once a patch has been committed to the main on-line repository however, a large number of people are likely to have pulled it, so amending is no longer suitable, and recording a second patch is preferable. Regards, Malcolm From john at repetae.net Thu May 31 17:25:31 2007 From: john at repetae.net (John Meacham) Date: Thu May 31 17:21:28 2007 Subject: [Haskell-cafe] Just for a laugh... In-Reply-To: <465F2650.4070807@btinternet.com> References: <465F2650.4070807@btinternet.com> Message-ID: <20070531212530.GC15061@momenergy.repetae.net> On Thu, May 31, 2007 at 08:47:28PM +0100, Andrew Coppin wrote: > My first instinct was to use Data.Bits - but I see no instance for > Double. (Presumably because performing bitwise operations on a Double is > a pretty odd thing to want to do.) So my next guess is to do some > bizzare type system hackery that allows you to transform a Double > into... whichever integer type is the same size, and proceed from there. > Does anybody know how to do that? This reminds me. it would be nice if we could remove the 'Num' superclass of Bits, having bitwise operations and being a number are fairly unrelated and having to declare bogus instances is annoying. It is probably just a holdover from C that we think of them as related. 'Bool' would be a simple example of something that is a good instance of bits, but not Num. John -- John Meacham - ?repetae.net?john? From apa3a at yahoo.com Thu May 31 23:18:12 2007 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Thu May 31 23:14:01 2007 Subject: Control.Monad.Cont documentation Message-ID: <65608.4654.qm@web56404.mail.re3.yahoo.com> > ----- Original Message ---- > From: Simon Marlow > > I tried the proposed revision and it doesn't compile for me, see > > http://hackage.haskell.org/trac/ghc/ticket/1169 Simon, David, thank you for following up on this ticket. Sorry, I dropped out of loop for a couple months. I'll resubmit the patch soon. Andriy ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz