From igloo at earth.li Thu May 1 11:41:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu May 1 11:36:00 2008 Subject: QuickCheck properties for IntSet In-Reply-To: <20080430210836.GD11012@scytale.galois.com> References: <20071203205507.GB22650@scytale.galois.com> <20080430173443.GA16101@matrix.chaos.earth.li> <20080430204811.GA13912@matrix.chaos.earth.li> <20080430210836.GD11012@scytale.galois.com> Message-ID: <20080501154136.GA22809@matrix.chaos.earth.li> On Wed, Apr 30, 2008 at 02:08:36PM -0700, Donald Bruce Stewart wrote: > > So I don't know what is being decided here? > > No QuickCheck properties for the containers library because Ian doesn't > believe in them? Or ..? Well, I've decided that I'm not going to just apply the patch, but I am not the library maintainer. We have http://www.haskell.org/haskellwiki/Library_submissions for deciding whether or not changes should be made. Thanks Ian From ross at soi.city.ac.uk Thu May 1 12:18:12 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu May 1 12:12:37 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <20080430235547.GG11012@scytale.galois.com> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> Message-ID: <20080501161812.GA3529@soi.city.ac.uk> On Wed, Apr 30, 2008 at 04:55:47PM -0700, Don Stewart wrote: > ross: > > A previous proposal: > > > > http://hackage.haskell.org/trac/ghc/ticket/1773 > > > > split the Arrow class, making (>>>) and (<<<) functions in > > Control.Category. This breaks programs that use Control.Arrow. > > > > To avoid some of the breakage, the proposal is that Control.Arrow should > > re-export (>>>) and (<<<), imported from Control.Category. > > This patch has been applied (xmonad was broken due to the change, so I > thought it best to act). I thought we had a process for API changes. I'm not sure what the right thing is here. I usually prefer to avoid re-exports because they create problems with warnings. From dons at galois.com Thu May 1 13:14:37 2008 From: dons at galois.com (Don Stewart) Date: Thu May 1 13:09:05 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <20080501161812.GA3529@soi.city.ac.uk> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> Message-ID: <20080501171437.GA31583@scytale.galois.com> ross: > On Wed, Apr 30, 2008 at 04:55:47PM -0700, Don Stewart wrote: > > ross: > > > A previous proposal: > > > > > > http://hackage.haskell.org/trac/ghc/ticket/1773 > > > > > > split the Arrow class, making (>>>) and (<<<) functions in > > > Control.Category. This breaks programs that use Control.Arrow. > > > > > > To avoid some of the breakage, the proposal is that Control.Arrow should > > > re-export (>>>) and (<<<), imported from Control.Category. > > > > This patch has been applied (xmonad was broken due to the change, so I > > thought it best to act). > > I thought we had a process for API changes. Yeah, that's my fault. I saw Duncan submitted the proposal about a week ago, and no one had objected, and then I ran into xmonad breaking due to it. > I'm not sure what the right thing is here. I usually prefer to avoid > re-exports because they create problems with warnings. If it is objected to we can revert. -- Don From kolmodin at dtek.chalmers.se Thu May 1 14:33:04 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Thu May 1 14:10:22 2008 Subject: getLazyByteString network I/O Bug In-Reply-To: <20080423035626.GD1527@lucky.cynic.net> References: <20080423035626.GD1527@lucky.cynic.net> Message-ID: <481A0CE0.1020506@dtek.chalmers.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Right, so it comes down to how binary handles chunks of the ByteString that might not yet be available. We have do decide what is reasonable to handle, and what could possibly trigger an error. splitAtST is too strict in the #ifndef BYTESTRING_IN_BASE version. Why the versions differ? I don't know. Even if it did not need any more data it forces the next chunk. This is easy to fix. This solves the problem when you ask for some data which is available, but the data after that is not. As I don't fully understand the splitAtST solution I can't say which splitAtST version is buggy. Then reading the last available data would create a state ~ S B.empty lbs x where lbs is an unevaluated lazy bytestring. ~ All is well as lbs remains unevaluated Curt, this is probably the bug you ran into. However, another issue; if you run any action and ask for 0 bytes; ~ like ~ * getByteString 0, or ~ * getLazyByteString 0 and no bytes are available, it would still block. Like so: ~ runGet (getByteString 0) (...blocking lazy bytestring...) This is due to that creating the state (mkState) forces the first chunk. 152 mkState :: L.ByteString -> Int64 -> S 153 mkState l = case l of 154 L.Empty -> S B.empty L.empty 155 L.Chunk x xs -> S x xs Is it acceptable to block in this case? By making splitAtST not force its last argument, let getLazyByteString and getBytes return an empty string immediately when 0 bytes are requested, we solve the three issues. Too hackish? Would anyone like to shed some light on why splitAtST forced the last argument? Cheers, ~ Lennart Kolmodin Curt Sampson wrote: | dcoutts on #haskell suggested that a difference in behaviour | between Data.Binary's getByteString and getLazyByteString was a | bug. Basically, in my particular case I send something to the | server (or for the purposes of this test, just connect) and it | sends back a non-newline-terminated response. If I pull it from the | getContents of the handle using getByteString, it works fine; if I use | getLazyByteString, it blocks, even though it has all of the data it | needs to satisfy the request. | | BTW, I did try setting the mode of the handle to non-blocking, but it | didn't make any difference in either case. | | I've attached a small project that displays this difference; see the | README at the top level to see how to try it for yourself. | | Incidently, I'm ghc 6.8.2 on NetBSD 4, and of course using the version | of Data.Binary that's included in the project, 0.4.1. | | Also, let me know if this is about the right amount of work for a test | case for something like this. It took me about an hour to put together, | so if you didn't really need all of this, I can probably send you less | next time. | | cjs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgaDOAACgkQ4txYG4KUCuEZ3ACfYJIPl/hKYoyudojK9VX5KTBe kjMAn3jFY0XnZdT7jlOZsJ004q0y6aIo =eG2B -----END PGP SIGNATURE----- From niklas.broberg at gmail.com Thu May 1 14:29:55 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu May 1 14:24:29 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <20080501161812.GA3529@soi.city.ac.uk> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> Message-ID: > I'm not sure what the right thing is here. I usually prefer to avoid > re-exports because they create problems with warnings. I think this is a bit sad actually. The situation discussed here is (IMO) exactly the kind of situation that re-exports are intended for. That some tools give warnings for re-exports is a flaw in those tools, not a problem with the re-export per se. Generally, if module A exports foo, module B imports A and re-exports foo, and module C imports both A and B, there should be no ambiguity. Not even if it reexports all of modules A and B. Why would e.g. GHC need to warn in that case? Cheers, /Niklas From simonpj at microsoft.com Thu May 1 14:34:38 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 1 14:29:05 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> Quite right. Please a bug report with a repo case if there is a bug. Thanks Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On | Behalf Of Niklas Broberg | Sent: 01 May 2008 19:30 | To: libraries@haskell.org | Subject: Re: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) | | > I'm not sure what the right thing is here. I usually prefer to avoid | > re-exports because they create problems with warnings. | | I think this is a bit sad actually. The situation discussed here is | (IMO) exactly the kind of situation that re-exports are intended for. | That some tools give warnings for re-exports is a flaw in those tools, | not a problem with the re-export per se. | | Generally, if module A exports foo, module B imports A and re-exports | foo, and module C imports both A and B, there should be no ambiguity. | Not even if it reexports all of modules A and B. Why would e.g. GHC | need to warn in that case? | | Cheers, | | /Niklas | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at worc.ox.ac.uk Thu May 1 15:36:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 15:29:53 2008 Subject: QuickCheck properties for IntSet In-Reply-To: <20080501154136.GA22809@matrix.chaos.earth.li> References: <20071203205507.GB22650@scytale.galois.com> <20080430173443.GA16101@matrix.chaos.earth.li> <20080430204811.GA13912@matrix.chaos.earth.li> <20080430210836.GD11012@scytale.galois.com> <20080501154136.GA22809@matrix.chaos.earth.li> Message-ID: <1209670566.30059.204.camel@localhost> On Thu, 2008-05-01 at 16:41 +0100, Ian Lynagh wrote: > On Wed, Apr 30, 2008 at 02:08:36PM -0700, Donald Bruce Stewart wrote: > > > > So I don't know what is being decided here? > > > > No QuickCheck properties for the containers library because Ian doesn't > > believe in them? Or ..? > > Well, I've decided that I'm not going to just apply the patch, but I am > not the library maintainer. We have > http://www.haskell.org/haskellwiki/Library_submissions > for deciding whether or not changes should be made. Well, that's really for interface or behaviour changes. I think it is clear that the library should come with those QC properties. The issue at stake is if they should be run every time as part of GHC's testing process. So I'd suggest applying the patch and then disabling the automatic running of the tests until that issue is decided. It'd be a bit sad to let good test code languish just because we can't decide if it should be run regularly or not. Duncan From qdunkan at gmail.com Thu May 1 17:28:51 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Thu May 1 17:23:17 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> On Thu, May 1, 2008 at 11:34 AM, Simon Peyton-Jones wrote: > > Quite right. Please a bug report with a repo case if there is a bug. > > Thanks > > Simon Is it the same as this one? http://hackage.haskell.org/trac/ghc/ticket/1148 I use qualified imports, and I see it on about half the modules I compile. From nominolo at googlemail.com Thu May 1 18:28:52 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu May 1 18:23:26 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> Message-ID: <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> On 20 apr 2008, at 22.22, Duncan Coutts wrote: > All, > > In the initial discussions on a common architecture for building > applications and libraries one of the goals was to reduce or eliminate > untracked dependencies. The aim being that you could reliably deploy a > package from one machine to another. > > We settled on a fairly traditional model, where one specifies the > names > and versions of packages of Haskell code. > > An obvious alternative model is embodied in ghc --make and in autoconf > style systems where you look in the environment not for packages but > rather for specific modules or functions. > > Both models have passionate advocates. There are of course advantages > and disadvantages to each. Both models seem to get implemented as > reactions having the other model inflicted on the author. For example > the current Cabal model of package names and versions was a > reaction to > the perceived problem of untracked dependencies with the ghc --make > system. One could see implementations such as searchpath and franchise > as reactions in the opposite direction. > > The advantages and disadvantages of specifying dependencies on module > names vs package names and versions are mostly inverses. Module name > clashes between packages are problematic with one system and not a > problem with the other. Moving modules between packages is not a > problem > for one system and a massive pain for the other. > > The fact is that both module name and package name + version are being > used as proxies to represent some vague combination of required > Haskell > interface and implementation thereof. Sometimes people intend only to > specify an interface and sometimes people really want to specify > (partial) semantics (eg to require a version of something including > some > bug fix / semantic change). In this situation the package version is > being used to specify an implementation as a proxy for semantics. > > Neither are very good ways of identifying an interface or > implementation/semantics. Modules do move from one package to another > without fundamentally changing. Modules do change interface and > semantics without changing name. There is no guarantee about the > relationship between a package's version and its interface or > semantics > though there are some conventions. > > Another view would be to try and identify the requirements about > dependent code more accurately. For example to view modules as > functors > and look at what interface they require of the modules they import. > Then > we can say that they depend on any module that provides a superset of > that interface. It doesn't help with semantics of course. Dependencies > like these are not so compact and easy to write down. > > I don't have any point here exactly, except that there is no obvious > solution. I guess I'd like to provoke a bit of a discussion on this, > though hopefully not just rehashing known issues. In particular if > people have any ideas about how we could improve either model to > address > their weak points then that'd be well worth discussing. > > For example the package versioning policy attempts to tighten the > relationship between a package version and changes in its interface > and > semantics. It still does not help at all with modules moving between > packages. > > Duncan > [Replying so late as I only saw this today.] I believe that using tight version constraints in conjunction with the PVP to be a good solution. For now. I don't quite know how Searchpath works (the website is rather taciturn), but I think that we should strive for a better approximation to real dependencies, specifically, name, interface, and semantics of imported functions. As I see it, what's missing is proper tool support to do it practically for both library authors and users. Library users really shouldn't need to do anything except to run a tool to determine all dependencies of a given package. Library authors should be able to run a tool that determines what's new and what might have changed. The package author then merely decides whether semantics was changed and if so, in what way (i.e., compatible or not to previous semantics). Packages will still carry versions, but they are only used to mark changes. Semantic information is provided via a "change database" which contains enough information to determine whether a version of a package contains appropriate implementations of the functions (or, more generally, entities) used in a dependent package. For example, if we write a program that uses the function 'Foo.foo' contained in package 'foo' and we happen to have used 'foo-0.42' for testing of our program. Then, given the knowledge that 'Foo.foo' was introduced in 'foo-0.23' and changed semantics in 'foo-2.0' then we know that 'foo >= 0.23 && < 2.0' is the correct and complete dependency description. That's the ideal, maybe we can work towards this? Or does this sound crazy? / Thomas -- "Today a young man on acid realized that all matter is merely energy condensed to a slow vibration, that we are all one consciousness experiencing itself subjectively, there is no such thing as death, life is only a dream, and we are the imagination of ourselves." -- Bill Hicks -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20080502/d52106e0/PGP.bin From duncan.coutts at worc.ox.ac.uk Thu May 1 19:49:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 19:43:19 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> Message-ID: <1209685777.30059.228.camel@localhost> On Fri, 2008-05-02 at 00:28 +0200, Thomas Schilling wrote: > On 20 apr 2008, at 22.22, Duncan Coutts wrote: > [Replying so late as I only saw this today.] > > I believe that using tight version constraints in conjunction with > the PVP to be a good solution. For now. I think I tend to agree. > I don't quite know how Searchpath works (the website is rather > taciturn), but I think that we should strive for a better > approximation to real dependencies, specifically, name, interface, > and semantics of imported functions. As I see it, what's missing is > proper tool support to do it practically for both library authors and > users. Yes, we can make package name and version a better approximation of the package interface with tools to enforce the versioning policy. > Library users really shouldn't need to do anything except to run a > tool to determine all dependencies of a given package. Library > authors should be able to run a tool that determines what's new and > what might have changed. The package author then merely decides > whether semantics was changed and if so, in what way (i.e., > compatible or not to previous semantics). Packages will still carry > versions, but they are only used to mark changes. Semantic > information is provided via a "change database" which contains enough > information to determine whether a version of a package contains > appropriate implementations of the functions (or, more generally, > entities) used in a dependent package. > > For example, if we write a program that uses the function 'Foo.foo' > contained in package 'foo' and we happen to have used 'foo-0.42' for > testing of our program. Then, given the knowledge that 'Foo.foo' was > introduced in 'foo-0.23' and changed semantics in 'foo-2.0' then we > know that 'foo >= 0.23 && < 2.0' is the correct and complete > dependency description. > > That's the ideal, maybe we can work towards this? > Or does this sound crazy? I think extracting package APIs and comparing them across versions is an excellent thing to do. It'd help users see what has changed and it'd let us enforce the versioning policy (at least for interface changes, not for semantic changes). Having a central collection of those interfaces and using that to work out which versions of which packages would be compatible with the program I just wrote is quite an interesting idea. It's related to what I was saying about identifying code by it's full interface, as a functor, but then using that to map back to packages that provide the interface. Something like that might go some way to addressing David Roundy's quite legitimate criticism that the system of specifying deps on package names and versions requires one to know the full development history of that code, eg to track it across package renames. However it would only help for the development _history_, we still have no solution for the problem of packages being renamed (or modules moving between packages) breaking other existing packages. Though similarly we have no solution to the problem of modules being renamed. Perhaps it's just that we have not done much module renaming recently so people don't see it as an issue. Duncan From simonpj at microsoft.com Fri May 2 03:30:03 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 2 03:24:32 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> | Is it the same as this one? http://hackage.haskell.org/trac/ghc/ticket/1148 | | I use qualified imports, and I see it on about half the modules I compile. I don't think so. I believe the original message concerned a variable or type that was in scope in two different ways. Niklas said | Generally, if module A exports foo, module B imports A and re-exports | foo, and module C imports both A and B, there should be no ambiguity. | Not even if it reexports all of modules A and B. Why would e.g. GHC | need to warn in that case? Perhaps Niklas can say whether #1148 is the bug he is describing, and if not file a new one? Simon From ross at soi.city.ac.uk Fri May 2 04:10:24 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri May 2 04:04:48 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502081024.GA2756@soi.city.ac.uk> On Fri, May 02, 2008 at 08:30:03AM +0100, Simon Peyton-Jones wrote: > | Generally, if module A exports foo, module B imports A and re-exports > | foo, and module C imports both A and B, there should be no ambiguity. > | Not even if it reexports all of modules A and B. Why would e.g. GHC > | need to warn in that case? > > Perhaps Niklas can say whether #1148 is the bug he is describing, and if not file a new one? Niklas's example: module A where foo x = x module B(foo) where import A module C where import A import B c = foo 'a' ghc -W says C.hs:2:0: Warning: Module `A' is imported, but nothing from it is used, except perhaps instances visible in `A' To suppress this warning, use: import A() It's true that the import can be deleted, but not that "nothing from it is used". From simonpj at microsoft.com Fri May 2 04:13:52 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 2 04:08:14 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <20080502081024.GA2756@soi.city.ac.uk> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C54C0@EA-EXMSG-C334.europe.corp.microsoft.com> Aha. So now it's unclear what the desired behaviour is. Do we want a warning for import statements that can be deleted altogether? If not, I can easily remove it! Or is it just the wording of the warning that is bad? S | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Ross Paterson | Sent: 02 May 2008 09:10 | To: libraries@haskell.org | Subject: Re: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) | | On Fri, May 02, 2008 at 08:30:03AM +0100, Simon Peyton-Jones wrote: | > | Generally, if module A exports foo, module B imports A and re-exports | > | foo, and module C imports both A and B, there should be no ambiguity. | > | Not even if it reexports all of modules A and B. Why would e.g. GHC | > | need to warn in that case? | > | > Perhaps Niklas can say whether #1148 is the bug he is describing, and if not file a new one? | | Niklas's example: | | module A where | foo x = x | | module B(foo) where | import A | | module C where | import A | import B | c = foo 'a' | | ghc -W says | | C.hs:2:0: | Warning: Module `A' is imported, but nothing from it is used, | except perhaps instances visible in `A' | To suppress this warning, use: import A() | | It's true that the import can be deleted, but not that "nothing from it | is used". | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries From apfelmus at quantentunnel.de Fri May 2 05:27:37 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri May 2 05:22:19 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <1209685777.30059.228.camel@localhost> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> <1209685777.30059.228.camel@localhost> Message-ID: Duncan Coutts wrote: > Thomas Schilling wrote: >> >> For example, if we write a program that uses the function 'Foo.foo' >> contained in package 'foo' and we happen to have used 'foo-0.42' for >> testing of our program. Then, given the knowledge that 'Foo.foo' was >> introduced in 'foo-0.23' and changed semantics in 'foo-2.0' then we >> know that 'foo >= 0.23 && < 2.0' is the correct and complete >> dependency description. I would go even further and simply use "my program 'bar' compiles with foo-0.42" as dependency description. In other words, whether the package foo-0.23 can be used to supply this dependency or not will be determined when somebody else tries to compile Bar with it. In both cases, the basic idea is that the library user should *not* think about library versions, he just uses the one that is in scope on his system. Figuring out which other versions can be substituted is the job of the library author. In other words, the burden of proof is shifted from the user ("will my program compile with foo-1.1?") to the author ("which versions of my library are compatible?"), where it belongs. > However it would only help for the development _history_, we still have > no solution for the problem of packages being renamed (or modules moving > between packages) breaking other existing packages. Though similarly we > have no solution to the problem of modules being renamed. Perhaps it's > just that we have not done much module renaming recently so people don't > see it as an issue. With the approach above, it's possible to handle package/module renaming. For instance, if the package 'foo' is split into 'f-0.1' and 'oo-0.1' at some point, we can still use the union of these two to fulfill the old dependency 'foo-0.42'. In other words, the basic model is that a module/package like 'bar' with a dependency like 'foo-0.42' as just a function that maps a value of the same type (= export list) as 'foo-0.42' to another value (namely the set of exports of 'bar'). So, we can compile for instance bar (foo-0.42) or bar (f-0.1 `union` oo-0.1) Of course, the problems are 1) specifying the types of the parameters, 2) automatically choosing good parameters. For 1), one could use a very detailed import list, but I think that this feels wrong. I mean, if I have to specify the imports myself, why did I import foo-0.42 in the first place? Put differently, when I say 'import Data.Map' I want to import both its implementation and the interface. So, I argue that the goal is to allow type specifications of the form 'same type as foo-0.42'. Problem 2) exists because if I have foo-0.5 on in scope on my system and a package lists foo-0.42 as a dependency, the compiler should somehow figure out that he can use foo-0.5 as argument. Of course, it will be tricky/impossible to figure out that f-0.1 `union` oo-0.1 is a valid argument, too. So, the task would be to develop a formalism, i.e. some kind of "lambda calculus for modules" that can handle problems 1) and 2). The formalism should be simple to understand and use yet powerful, just like our beloved lambda calculus. A potential pitfall to any solution is that name and version number don't identify a compiled package uniquely! For instance, foo-0.3 (bytestring-1.1) is very different from foo-0.3 (bytestring-1.2) if foo exports the ByteString type. That's the diamond import problem. In other words, foo-0.3 is always the same function, but the evaluated results are not. Regards, apfelmus From igloo at earth.li Fri May 2 08:43:39 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri May 2 08:38:02 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C54C0@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C54C0@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502124339.GA6322@matrix.chaos.earth.li> On Fri, May 02, 2008 at 09:13:52AM +0100, Simon Peyton-Jones wrote: > Aha. So now it's unclear what the desired behaviour is. Do we want a warning for import statements that can be deleted altogether? If not, I can easily remove it! Or is it just the wording of the warning that is bad? I would like what the warning says, rather than what it does. Something like: For each use of a variable foo, mark imports import M (..., foo, ...) as "used" if any exist; otherwise mark any imports import M which export foo as "used". Then warn about any imports not marked as "used" (except imports of the form import M () of course). > | Warning: Module `A' is imported, but nothing from it is used, > | except perhaps instances visible in `A' > | To suppress this warning, use: import A() Thanks Ian From niklas.broberg at gmail.com Fri May 2 09:46:04 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri May 2 09:40:25 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <20080502081024.GA2756@soi.city.ac.uk> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> Message-ID: > > Perhaps Niklas can say whether #1148 is the bug he is describing, and if not file a new one? > > > Niklas's example: > > module A where > foo x = x > > module B(foo) where > import A > > module C where > import A > import B > c = foo 'a' > > ghc -W says > > C.hs:2:0: > Warning: Module `A' is imported, but nothing from it is used, > except perhaps instances visible in `A' > To suppress this warning, use: import A() > > It's true that the import can be deleted, but not that "nothing from it > is used". This is actually not what I was hinting at, I'll see if I can reproduce the bug I experienced. The basic idea behind it was that module A in package a defines some type class, with member function foo. Modules B and C in packages b and c separately import A and create instances of that class, and reexports foo. Then module D in package D cannot import both B and C and use foo, it will give an "Ambiguous occurence" error. I tried reproducing this in a simpler setting, with ABCD all in one package, but the error wouldn't appear. I hope I wasn't imagining things (or rather, it would be good if I was :-)). There may have been some qualified imports involved too... But there are a few other inconvenient behaviors related only to warnings, for instance module A where foo x = x module B(foo) where import A module C (module A, module B) where import A import B %> ghc --make C.hs -W: C.hs:1:20: Warning: `foo' is exported by `module B' and `module A' That's certainly true, but it's the same 'foo'. Just a warning of course, and I'm not so sure I would argue that it shouldn't be there. It's the same kind of warning as with any other multiple export of a symbol I guess. But this pattern is not uncommon (in my code at least), so the warning is inconvenient. Then again, that particular warning can be turned off. Another, somewhat stranger, behavior: module A where foo x = x module B(foo) where import A module C(foo) where import A module D () where import B import C bar x = foo x %> ghc --make D.hs -W D.hs:2:0: Warning: Module `B' is imported, but nothing from it is used, except perhaps instances visible in `B' To suppress this warning, use: import B() D.hs:3:0: Warning: Module `C' is imported, but nothing from it is used, except perhaps instances visible in `C' To suppress this warning, use: import C() D.hs:4:0: Warning: Defined but not used: `bar' This might be said to be a bug, although it's a bug that would rarely bite you, since it requires that 'bar' is not exported (or used in something that is exported). If you export bar, then the warning talks only of B - which is a rather arbitrary choice. I'll see what I can do about that more serious bug. As regards to this particular discussion though - my main point is that we shouldn't make decisions on libraries based on what tools make of them, rather the other way around. Obvious perhaps (I hope), but bears repeating. :-) Cheers, /Niklas From droundy at darcs.net Fri May 2 12:55:32 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 2 12:49:53 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> Message-ID: <20080502165531.GN23619@darcs.net> On Sun, Apr 20, 2008 at 09:22:56PM +0100, Duncan Coutts wrote: > In the initial discussions on a common architecture for building > applications and libraries one of the goals was to reduce or eliminate > untracked dependencies. The aim being that you could reliably deploy a > package from one machine to another. > > We settled on a fairly traditional model, where one specifies the names > and versions of packages of Haskell code. Do you actually have any precedent for such a system? I've never heard of one, but then I've been sort of sheltered, due to living in the linux world where there is a distinction between packagers and upstream authors. I consider this a useful distinction. But that's probably because I'm lazy, or perhaps because I care about my users--and thus like to give them options and reduce the dependencies of my software. I know there is a long history of the autoconf-style approach being successful. Can you point to any success stories of the approach chosen for cabal? David From nominolo at googlemail.com Sat May 3 09:35:23 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat May 3 09:29:50 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> <1209685777.30059.228.camel@localhost> Message-ID: <09CAC1C8-8897-4728-BBFE-CCC2D4FA53E3@googlemail.com> On 2 maj 2008, at 11.27, apfelmus wrote: > Duncan Coutts wrote: >> Thomas Schilling wrote: >>> >>> For example, if we write a program that uses the function >>> 'Foo.foo' contained in package 'foo' and we happen to have used >>> 'foo-0.42' for testing of our program. Then, given the >>> knowledge that 'Foo.foo' was introduced in 'foo-0.23' and >>> changed semantics in 'foo-2.0' then we know that 'foo >= 0.23 && >>> < 2.0' is the correct and complete dependency description. > > I would go even further and simply use "my program 'bar' compiles > with foo-0.42" as dependency description. In other words, whether > the package foo-0.23 can be used to supply this dependency or not > will be determined when somebody else tries to compile Bar with it. > > In both cases, the basic idea is that the library user should *not* > think about library versions, he just uses the one that is in scope > on his system. Figuring out which other versions can be substituted > is the job of the library author. In other words, the burden of > proof is shifted from the user ("will my program compile with > foo-1.1?") to the author ("which versions of my library are > compatible?"), where it belongs. I think we mean the same thing. If I write a program and test it against a specific version of a library then my program's source code and knowledge about which specific versions of libraries I used, most of the time, contains *all* the information necessary to determine which other library versions it can be built with. From the source code we need information about what is imported, from the library author we need a *formal* changelog. This changelog describes for each released version what part of the interface and semantics have changed. The problem here is, of course, that this is a lot of information to provide. Furthermore, I think we need information about imports from the library user, if we ignore this, then the PVP is *exactly* what we need. The PVP describes when things *could* break, but it does so in an extremely pessimistic way. If we have information about what exactly changed and what is used by a particular library, we can find out what the exact version range is. For example, if we build our package against foo-0.42 and bar-2.3 and both packages follow the PVP then the following will trivially be true: build-depends: foo-0.42.*, bar-2.3.* where "-X.Y.*" is a shortcut for ">= X.Y && < X.(Y+1)". The problem is that this is extremely pessimistic, so we have to manually check whenever a new version of a dependency comes out and update the "known-to-work-with"-range. With more information (obtained mostly by tools) we can automate this process, and, in fact, both approaches can co-exist. > >> However it would only help for the development _history_, we still >> have >> no solution for the problem of packages being renamed (or modules >> moving >> between packages) breaking other existing packages. Though >> similarly we >> have no solution to the problem of modules being renamed. Perhaps >> it's >> just that we have not done much module renaming recently so people >> don't >> see it as an issue. > > With the approach above, it's possible to handle package/module > renaming. For instance, if the package 'foo' is split into 'f-0.1' > and 'oo-0.1' at some point, we can still use the union of these two > to fulfill the old dependency 'foo-0.42'. This is kind of the same like using a "virtual package" that is simply a re-export of other packages. This would help a lot with our current problems with the base split (which will continue, as base will be split up even further). > > In other words, the basic model is that a module/package like 'bar' > with a dependency like 'foo-0.42' as just a function that maps a > value of the same type (= export list) as 'foo-0.42' to another > value (namely the set of exports of 'bar'). So, we can compile for > instance > > bar (foo-0.42) > > or > > bar (f-0.1 `union` oo-0.1) > > Of course, the problems are > > 1) specifying the types of the parameters, > 2) automatically choosing good parameters. > > For 1), one could use a very detailed import list, but I think that > this feels wrong. I mean, if I have to specify the imports myself, > why did I import foo-0.42 in the first place? Put differently, when > I say 'import Data.Map' I want to import both its implementation > and the interface. So, I argue that the goal is to allow type > specifications of the form 'same type as foo-0.42'. > > Problem 2) exists because if I have foo-0.5 on in scope on my > system and a package lists foo-0.42 as a dependency, the compiler > should somehow figure out that he can use foo-0.5 as argument. Of > course, it will be tricky/impossible to figure out that f-0.1 > `union` oo-0.1 is a valid argument, too. > > > So, the task would be to develop a formalism, i.e. some kind of > "lambda calculus for modules" that can handle problems 1) and 2). > The formalism should be simple to understand and use yet powerful, > just like our beloved lambda calculus. > > > A potential pitfall to any solution is that name and version number > don't identify a compiled package uniquely! For instance, > > foo-0.3 (bytestring-1.1) > > is very different from > > foo-0.3 (bytestring-1.2) > > if foo exports the ByteString type. That's the diamond import > problem. In other words, foo-0.3 is always the same function, but > the evaluated results are not. I think a formal changelog can also help with renaming (even of exported entities), but, I agree, for all this to work we need to formalise it first, and then build tools to automate most of the work. / Thomas -- My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20080503/108402f5/PGP.bin From igloo at earth.li Sat May 3 09:51:33 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat May 3 09:45:51 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080502165531.GN23619@darcs.net> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> Message-ID: <20080503135133.GA8582@matrix.chaos.earth.li> On Fri, May 02, 2008 at 09:55:32AM -0700, David Roundy wrote: > On Sun, Apr 20, 2008 at 09:22:56PM +0100, Duncan Coutts wrote: > > > > We settled on a fairly traditional model, where one specifies the names > > and versions of packages of Haskell code. > > Do you actually have any precedent for such a system? > > I know there is a long history of the autoconf-style approach being > successful. Can you point to any success stories of the approach chosen > for cabal? LaTeX does things like \RequirePackage{longtable}[1995/01/01] According to http://peak.telecommunity.com/DevCenter/PythonEggs, with python eggs you do things like from pkg_resources import require require("FooBar>=1.2") According to http://blogs.cocoondev.org/crafterm/archives/004653.html, with Ruby gems you do things like s.add_dependency("dependency", ">= 0.x.x") (URLs found by googling for "how to make a ") Those were just the first 3 things I thought of. I don't know what you would consider a success, though. Thanks Ian From droundy at darcs.net Sat May 3 14:30:44 2008 From: droundy at darcs.net (David Roundy) Date: Sat May 3 14:25:01 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080503135133.GA8582@matrix.chaos.earth.li> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> <20080503135133.GA8582@matrix.chaos.earth.li> Message-ID: <20080503183043.GC23619@darcs.net> On Sat, May 03, 2008 at 02:51:33PM +0100, Ian Lynagh wrote: > On Fri, May 02, 2008 at 09:55:32AM -0700, David Roundy wrote: > > On Sun, Apr 20, 2008 at 09:22:56PM +0100, Duncan Coutts wrote: > > > > > > We settled on a fairly traditional model, where one specifies the names > > > and versions of packages of Haskell code. > > > > Do you actually have any precedent for such a system? > > > > I know there is a long history of the autoconf-style approach being > > successful. Can you point to any success stories of the approach chosen > > for cabal? > > LaTeX does things like > \RequirePackage{longtable}[1995/01/01] I wouldn't call LaTeX a build system, although it's certainly a wonderful typesetting system. > According to http://peak.telecommunity.com/DevCenter/PythonEggs, with > python eggs you do things like > from pkg_resources import require > require("FooBar>=1.2") >From what I can tell, python eggs aren't a build system either, but rather a binary package format. > According to http://blogs.cocoondev.org/crafterm/archives/004653.html, > with Ruby gems you do things like > s.add_dependency("dependency", ">= 0.x.x") It seems that a ruby gem is also a binary package. > (URLs found by googling for "how to make a ") > > Those were just the first 3 things I thought of. > I don't know what you would consider a success, though. I'd definitely call LaTeX a success, have no idea about gems or eggs (which I'd never heard of before this email), but none of these are build systems, so far as I can tell. -- David Roundy Department of Physics Oregon State University From igloo at earth.li Sun May 4 12:20:54 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun May 4 12:15:09 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080503183043.GC23619@darcs.net> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> <20080503135133.GA8582@matrix.chaos.earth.li> <20080503183043.GC23619@darcs.net> Message-ID: <20080504162054.GA14443@matrix.chaos.earth.li> On Sat, May 03, 2008 at 11:30:44AM -0700, David Roundy wrote: > On Sat, May 03, 2008 at 02:51:33PM +0100, Ian Lynagh wrote: > > > > According to http://peak.telecommunity.com/DevCenter/PythonEggs, with > > python eggs you do things like > > from pkg_resources import require > > require("FooBar>=1.2") > > >From what I can tell, python eggs aren't a build system either, but rather > a binary package format. To install a trac plugin you download a tarball and do something like python setup.py bdist_egg to create the .egg file, which you can then put in the appropriate place. I think in general you can also do python setup.py install to have it installed as a python library. I know virtually nothing about eggs, and even less about gems, but I am under the impression that they aim to solve the same problem as Cabal. Thanks Ian From droundy at darcs.net Mon May 5 06:50:45 2008 From: droundy at darcs.net (David Roundy) Date: Mon May 5 06:44:58 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080504162054.GA14443@matrix.chaos.earth.li> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> <20080503135133.GA8582@matrix.chaos.earth.li> <20080503183043.GC23619@darcs.net> <20080504162054.GA14443@matrix.chaos.earth.li> Message-ID: <20080505105044.GH23619@darcs.net> On Sun, May 04, 2008 at 05:20:54PM +0100, Ian Lynagh wrote: > On Sat, May 03, 2008 at 11:30:44AM -0700, David Roundy wrote: > > On Sat, May 03, 2008 at 02:51:33PM +0100, Ian Lynagh wrote: > > > > > > According to http://peak.telecommunity.com/DevCenter/PythonEggs, with > > > python eggs you do things like > > > from pkg_resources import require > > > require("FooBar>=1.2") > > > > > From what I can tell, python eggs aren't a build system either, but > > > rather a binary package format. > > To install a trac plugin you download a tarball and do something like > python setup.py bdist_egg to create the .egg file, which you can then put > in the appropriate place. I think in general you can also do python > setup.py install to have it installed as a python library. > > I know virtually nothing about eggs, and even less about gems, but I am > under the impression that they aim to solve the same problem as Cabal. Maybe the problem is that noone seems to know what problem cabal is supposed to be solving. What problem is that? Some say it's a configuration/build system. Others say it's a packaging system. I think it's the latter. David From thomas.dubuisson at gmail.com Mon May 5 08:16:55 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Mon May 5 08:08:46 2008 Subject: Deriving instance for Foreign.C.Error.Errno (trac 2261) Message-ID: <1209989817.2761.3.camel@Clunker> Errno, the Haskell encapsulation of the CInt 'errno' value, should be an instance of the commonly used type classes so higher level data structures that include it aren't bothered. This change will break code that has custom instances for Errno, but this should be little (if any) code. A patch is attached to the trac ticket to derive Show and Ord while Eq remains a custom instance. One could argue that, like Eq, Show and Ord should be customized to provide a identical result for all 'invalid' errno's - any thoughts on if this is necessary and what the corner case result would be? http://hackage.haskell.org/trac/ghc/ticket/2261 Thomas P.S. Traveling soon, so I won't be responsive - sorry. From duncan.coutts at worc.ox.ac.uk Mon May 5 18:31:03 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 18:24:10 2008 Subject: Deriving instance for Foreign.C.Error.Errno (trac 2261) In-Reply-To: <1209989817.2761.3.camel@Clunker> References: <1209989817.2761.3.camel@Clunker> Message-ID: <1210026663.30059.296.camel@localhost> On Mon, 2008-05-05 at 08:16 -0400, Thomas M. DuBuisson wrote: > Errno, the Haskell encapsulation of the CInt 'errno' value, should be an > instance of the commonly used type classes so higher level data > structures that include it aren't bothered. > > This change will break code that has custom instances for Errno, but > this should be little (if any) code. > > A patch is attached to the trac ticket to derive Show and Ord while Eq > remains a custom instance. One could argue that, like Eq, Show and Ord > should be customized to provide a identical result for all 'invalid' > errno's - any thoughts on if this is necessary and what the corner case > result would be? > > http://hackage.haskell.org/trac/ghc/ticket/2261 Having it an instance of Ord and Show seems fine. If the Eq instance equates all the invalid errnos then the Ord instance should do so too because it is important that: compare a b == Eq <=> a == b Duncan From thomas.dubuisson at gmail.com Mon May 5 22:42:57 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Mon May 5 22:34:37 2008 Subject: Deriving instance for Foreign.C.Error.Errno (trac 2261) In-Reply-To: <1210026663.30059.296.camel@localhost> References: <1209989817.2761.3.camel@Clunker> <1210026663.30059.296.camel@localhost> Message-ID: <1210041778.2761.38.camel@Clunker> Duncan Coutts wrote: | If the Eq instance equates all the invalid errnos then the Ord instance | should do so too because it is important that | compare a b == Eq <=> a == b Unfortunatly the default is not equal: > instance Eq Errno where > errno1@(Errno no1) == errno2@(Errno no2) > | isValidErrno errno1 && isValidErrno errno2 = no1 == no2 > | otherwise So if the errnos are invalid compare could return: A) {GT or LT} -- thus (a < b && b < a), no good B) EQ -- Contradicting the current definition of Eq C) Option 'B' and change the definition of Eq (allowing invalid == invalid) I encourage option C, which basically means deriving all the instances (the only invalid Errno is -1). I'm not sure how this affects existing code using Errno, but if its all static checks (unkErr == ePERM) then things should still be fine. Anyone know of the reason for or a use of the current behavior? Thomas From simonpj at microsoft.com Tue May 6 04:58:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 6 04:52:22 2008 Subject: proposal #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE554E695@EA-EXMSG-C334.europe.corp.microsoft.com> | This is actually not what I was hinting at, I'll see if I can | reproduce the bug I experienced. The basic idea behind it was that | module A in package a defines some type class, with member function | foo. Modules B and C in packages b and c separately import A and | create instances of that class, and reexports foo. Then module D in | package D cannot import both B and C and use foo, it will give an | "Ambiguous occurence" error. I tried reproducing this in a simpler | setting, with ABCD all in one package, but the error wouldn't appear. | I hope I wasn't imagining things (or rather, it would be good if I was | :-)). There may have been some qualified imports involved too... That certainly sounds like a bug. If you can reproduce it, please file it as such. Simon From duncan.coutts at worc.ox.ac.uk Tue May 6 07:00:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 06:54:01 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080502165531.GN23619@darcs.net> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> Message-ID: <1210071657.30059.349.camel@localhost> On Fri, 2008-05-02 at 09:55 -0700, David Roundy wrote: > On Sun, Apr 20, 2008 at 09:22:56PM +0100, Duncan Coutts wrote: > > In the initial discussions on a common architecture for building > > applications and libraries one of the goals was to reduce or eliminate > > untracked dependencies. The aim being that you could reliably deploy a > > package from one machine to another. > > > > We settled on a fairly traditional model, where one specifies the names > > and versions of packages of Haskell code. > > Do you actually have any precedent for such a system? I would count all the distro packaging systems as precedent. There are a few others but those are the most significant. > I've never heard of one, but then I've been sort of sheltered, due to > living in the linux world where there is a distinction between > packagers and upstream authors. I consider this a useful distinction. I agree it is a useful distinction. I was a packager for gentoo for three years. The jobs have roughly the same goal -- to deliver great software to users -- but there is certainly a different focus. > But that's probably because I'm lazy, or perhaps because I care about > my users--and thus like to give them options and reduce the > dependencies of my software. We are actually very lucky to have people doing the packaging job for us. It takes time and because of that only the most important bits of software get packaged. If we could significantly reduce the amount of time that packing people have to spend on each package then we could increase the number of packages that could benefit. So that's what Cabal's model of specifying dependencies is for, to provide enough information to enable package management. Without that information provided up front the packaging people have to spend much more time manually discovering the dependencies by reading through README and configure.ac files. With Cabal packages we have the possibility of generating distro packages automatically. Several distros have tools to do this automatic translation. This is something that is essentially impossible with autoconf. When we started using our translation tool in Gentoo we were able to increase the number of packages we provided by an order of magnitude. Of course we do not expect every little Haskell package to appear in every distro but the information provided by packages makes it possible to provide package management (in the form of cabal-install) even for the packages that do not meet the popularity or QA standards for the distros. > I know there is a long history of the autoconf-style approach being > successful. Can you point to any success stories of the approach chosen > for cabal? Again I'd point to all the package management systems. If you want examples of build systems that provide enough information for package management then admittedly there are fewer. Ian already pointed out Python eggs and Ruby Gems. I think CPAN also has some method for tracking dependencies though I don't know if or how CPAN modules specify dependencies. Duncan From duncan.coutts at worc.ox.ac.uk Tue May 6 07:13:03 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 07:06:09 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080505105044.GH23619@darcs.net> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> <20080503135133.GA8582@matrix.chaos.earth.li> <20080503183043.GC23619@darcs.net> <20080504162054.GA14443@matrix.chaos.earth.li> <20080505105044.GH23619@darcs.net> Message-ID: <1210072383.30059.360.camel@localhost> On Mon, 2008-05-05 at 03:50 -0700, David Roundy wrote: > Maybe the problem is that noone seems to know what problem cabal is > supposed to be solving. What problem is that? Some say it's a > configuration/build system. Others say it's a packaging system. I think > it's the latter. I'd say that Cabal is a build system but one that provides enough information to enable package management. That's the reason for the slight blurring/confusion with packaging systems. There is a much clearer division with autoconf/automake because it is a build system that does not provide enough information to enable package management. Cabal interfaces with package management systems in a similar way to ./configure && make && make install as one can see from the scripts that the distros use to build packages from source. Tools like cabal-rpm, hackport and dh_haskell use the information provided by cabal packages to make distro packages semi-automatically (It does not eliminate the QA job). cabal-install is a package manager for those Cabal packages that are not already packaged by the distros. It seems likely that there will always be a significant number of such packages as there is with CPAN etc. Hackage is an archive and distribution point for Cabal packages. Duncan From rl at cse.unsw.edu.au Fri May 9 00:33:09 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri May 9 00:27:19 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> Message-ID: <4823D405.2070303@cse.unsw.edu.au> Duncan Coutts wrote: > > In the initial discussions on a common architecture for building > applications and libraries one of the goals was to reduce or eliminate > untracked dependencies. The aim being that you could reliably deploy a > package from one machine to another. Sorry for jumping in so late but here are my two cents anyway. IMO, a package is absolutely the wrong thing to depend on. Essentially, a package is an implementation of an interface and depending on implementations is a bad thing. Code should only depend on interfaces which are completely independent entities. I suspect that a lot of the problems with packages occur because the current system doesn't follow this simple principle. It would be nice if Cabal had an explicit concept of interfaces, with the idea that code depends on them and packages implement them. In the simplest case, an interface is just a name. Ideally, it would be a combination of type signatures, Quickcheck properties, proof obligations etc. The important thing is that it has an explicit definition which is completely independent of any concrete implementation and which never changes. Something like this would immediately solve a lot of problems. Several packages could implement the same interface and we could pick which one we want when building stuff. We could have much more fine-grained dependencies (if all I need is an AVL tree, I don't want to depend on the entire containers package, but rather just on the AVL part of it). One package could implement several versions of an interface to ensure compatibility with old code (I could imagine module names like AVL_1.Data.AVLTree, AVL_2.Data.AVLTree etc., where AVL_1 and AVL_2 are interface names; Cabal could then map the right module to Data.AVLTree when building). If interface definitions include something like Quickcheck properties, we would have at least some assurance that a package actually does implement its interfaces. Moreover, this would also make the properties themselves reusable. Note that I don't propose that we automatically extract interfaces from code. In fact, I think that would be precisely the wrong way to go. An interface is not a by-product of implementing a package. It should be defined explicitly. In general, I don't think that existing package management systems do a very good job of specifying dependencies. They sort of work for distributing software but do they really work for versioning libraries? In any case, we ought to have something better for Haskell where we (hopefully) have somewhat different standards when it comes to correctness and ease of use. It might be more worthwhile to look at systems such as Corba, Microsoft's OLE or whatever that's called nowadays, Java's equivalent, whatever that is and, of course, ML's modules. None of these is quite right for what we want but IMO they are much closer to our problem domain than something like RPM. Roman From marlowsd at gmail.com Fri May 9 08:00:11 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri May 9 07:54:14 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080505105044.GH23619@darcs.net> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> <20080503135133.GA8582@matrix.chaos.earth.li> <20080503183043.GC23619@darcs.net> <20080504162054.GA14443@matrix.chaos.earth.li> <20080505105044.GH23619@darcs.net> Message-ID: <48243CCB.4010409@gmail.com> David Roundy wrote: > On Sun, May 04, 2008 at 05:20:54PM +0100, Ian Lynagh wrote: >> On Sat, May 03, 2008 at 11:30:44AM -0700, David Roundy wrote: >>> On Sat, May 03, 2008 at 02:51:33PM +0100, Ian Lynagh wrote: >>>> According to http://peak.telecommunity.com/DevCenter/PythonEggs, with >>>> python eggs you do things like >>>> from pkg_resources import require >>>> require("FooBar>=1.2") >>>> From what I can tell, python eggs aren't a build system either, but >>>> rather a binary package format. >> To install a trac plugin you download a tarball and do something like >> python setup.py bdist_egg to create the .egg file, which you can then put >> in the appropriate place. I think in general you can also do python >> setup.py install to have it installed as a python library. >> >> I know virtually nothing about eggs, and even less about gems, but I am >> under the impression that they aim to solve the same problem as Cabal. > > Maybe the problem is that noone seems to know what problem cabal is > supposed to be solving. What problem is that? Some say it's a > configuration/build system. Others say it's a packaging system. I think > it's the latter. Does it matter? It's fine for a system to not fit entirely into one of the predefined boxes that you know about (e.g. is ZFS a file system or a volume manager?). Cabal solves a specific problem, which is: it allows a package to be built from source, and installed, on a system with only a Haskell compiler (and Cabal). the last part is important for people on Windows who don't want to install Cygwin or MSYS just to build Haskell packages. Now, we discovered that by adding bits here and there we could solve other problems too: e.g. Cabal also builds programs. But the above statement was originally the main reason for Cabal's existence. Cheers, Simon From droundy at darcs.net Fri May 9 08:28:30 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 9 08:22:29 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <48243CCB.4010409@gmail.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> <20080503135133.GA8582@matrix.chaos.earth.li> <20080503183043.GC23619@darcs.net> <20080504162054.GA14443@matrix.chaos.earth.li> <20080505105044.GH23619@darcs.net> <48243CCB.4010409@gmail.com> Message-ID: <20080509122822.GF8845@darcs.net> On Fri, May 09, 2008 at 01:00:11PM +0100, Simon Marlow wrote: > David Roundy wrote: > >Maybe the problem is that noone seems to know what problem cabal is > >supposed to be solving. What problem is that? Some say it's a > >configuration/build system. Others say it's a packaging system. I think > >it's the latter. > > Does it matter? It's fine for a system to not fit entirely into one of the > predefined boxes that you know about (e.g. is ZFS a file system or a volume > manager?). Cabal solves a specific problem, which is: > > it allows a package to be built from source, and installed, on > a system with only a Haskell compiler (and Cabal). > > the last part is important for people on Windows who don't want to install > Cygwin or MSYS just to build Haskell packages. > > Now, we discovered that by adding bits here and there we could solve other > problems too: e.g. Cabal also builds programs. But the above statement was > originally the main reason for Cabal's existence. I guess my problem is that some of the advocates of cabal don't seem to understand this, and seem to think that it's some sort of a general-purpose build system. The trouble is that it isn't an autoconf-replacement or a make-replacement, but folks keep comparing it with those programs and arguing that it should replace them. Indeed, it can replace them for simple packages, as you note, but it doesn't compete in terms of either generality or flexibility. David From marlowsd at gmail.com Fri May 9 08:59:54 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri May 9 08:53:56 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <20080509122822.GF8845@darcs.net> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <20080502165531.GN23619@darcs.net> <20080503135133.GA8582@matrix.chaos.earth.li> <20080503183043.GC23619@darcs.net> <20080504162054.GA14443@matrix.chaos.earth.li> <20080505105044.GH23619@darcs.net> <48243CCB.4010409@gmail.com> <20080509122822.GF8845@darcs.net> Message-ID: <48244ACA.8030704@gmail.com> David Roundy wrote: > On Fri, May 09, 2008 at 01:00:11PM +0100, Simon Marlow wrote: >> David Roundy wrote: >>> Maybe the problem is that noone seems to know what problem cabal is >>> supposed to be solving. What problem is that? Some say it's a >>> configuration/build system. Others say it's a packaging system. I think >>> it's the latter. >> Does it matter? It's fine for a system to not fit entirely into one of the >> predefined boxes that you know about (e.g. is ZFS a file system or a volume >> manager?). Cabal solves a specific problem, which is: >> >> it allows a package to be built from source, and installed, on >> a system with only a Haskell compiler (and Cabal). >> >> the last part is important for people on Windows who don't want to install >> Cygwin or MSYS just to build Haskell packages. >> >> Now, we discovered that by adding bits here and there we could solve other >> problems too: e.g. Cabal also builds programs. But the above statement was >> originally the main reason for Cabal's existence. > > I guess my problem is that some of the advocates of cabal don't seem to > understand this, and seem to think that it's some sort of a general-purpose > build system. The trouble is that it isn't an autoconf-replacement or a > make-replacement, but folks keep comparing it with those programs and > arguing that it should replace them. Indeed, it can replace them for > simple packages, as you note, but it doesn't compete in terms of either > generality or flexibility. The problem we found before Cabal was that people would appear and ask how to build a Haskell package, and they generally didn't know enough make or autoconf to do it alone. Even if they did, it's still a daunting task. Cabal just automates all this nicely. Before Cabal I could count on one hand the number of third-party Haskell packages available, and they all had their own hand-written build systems, which were often flaky. Now we have hundreds of packages that just work. We designed Cabal so that you could use it with autoconf as your configuration tool, and many packages do this. But you can't use autoconf to configure Haskell dependencies, because we want to know dependencies up front for things like cabal-install. So Cabal was never designed to replace autoconf or make, except for the particular case of building Haskell packages and programs. Generally the approach has been that if we can get rid of the need for autoconf by adding a tiny bit to Cabal, then that's a trade worth making, but I don't think anyone's saying we should re-implement autoconf in Cabal. However, re-implementing make in Cabal isn't nearly such a bad idea :-) Cheers, Simon From dons at galois.com Sat May 10 01:36:09 2008 From: dons at galois.com (Don Stewart) Date: Sat May 10 01:30:07 2008 Subject: Release of unix 2.4.0.0 Message-ID: <20080510053609.GA24496@scytale.galois.com> Vasili Galchin did a release of a new version of the unix library. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.4.0.0 Hmm :( This is a core package, maintained by libraries@, so shouldn't be being uploaded to hackage by 3rd parties. What can we do? -- Don From dons at galois.com Sat May 10 01:51:11 2008 From: dons at galois.com (Don Stewart) Date: Sat May 10 01:45:08 2008 Subject: Release of unix 2.4.0.0 In-Reply-To: <20080510053609.GA24496@scytale.galois.com> References: <20080510053609.GA24496@scytale.galois.com> Message-ID: <20080510055111.GB24496@scytale.galois.com> dons: > Vasili Galchin did a release of a new version of the unix library. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.4.0.0 > > Hmm :( > > This is a core package, maintained by libraries@, so shouldn't be being > uploaded to hackage by 3rd parties. > > What can we do? It's also been pointed out that the darcs version of the unix package is 2.2, while the version on hackage is 2.3. with cabal install now able to auto-grab the latest thing named 'unix' this is a little concerning. -- Don From dons at galois.com Sat May 10 01:58:47 2008 From: dons at galois.com (Don Stewart) Date: Sat May 10 01:52:47 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> Message-ID: <20080510055847.GC24496@scytale.galois.com> vigalchin: > Hello, > > Additional POSIX realtime (POSIX 1003.1b) support has been added: > > 1) MQueue.hsc - POSIX message queues > > Supported FFI bindings for: > > - mq_open > > - mq_close > > - mq_unlink > > - mq_getattributes > > - mq_setattributes > > - mq_send > > Not yet supported bindings: > > - mq_rcv .. still debugging a mysterious problem > > - mq_notify - will support when asynchronous I/O is implemented > > 2) RTsched.hsc - real time scheduling > > Supported bindings for: > > - sched_yield > > - sched_get_param > > - sched_set_param > > - sched _get_scheduler > > - sched_set_scheduler > > - sched_get_priority_min > > - sched_get_priority_max > > Unsupported currently: > > - sched_rr_get_interval - still looking for the TimeSpec data > type in order to get "peek" working > > 3) Files.hsc > > Added bindings for: > > - fsync > > - fdatasync > > I am new to Haskell but would like to make a lot of contributions to > insure Haskell success in the marketplace (of ideas ;^)). I apologize for > any glitches and look for feedback. Very interesting! However... this library is a core package, and maintained by libraries@haskell.org, so you should not release it yourself. Instead, submit your patches to libraries@ for inclusion, following the patch submission guide here: http://haskell.org/haskellwiki/How_to_write_a_Haskell_program Where the patches will be tested on other unix platforms, and then encorporated into the main 'unix' repository. Also, as unix .hsc files tend to be a bit fragile, portability wise, it might be a good idea to instead place your patches in a separate library on hackage, rather than patching the 'unix' package directly. We have many other unix-alike packages, so one for message queues, and real time scheduling make sense -- separate from the core 'unix' package (like the mmap package, for example). -- Don From dons at galois.com Sat May 10 02:21:40 2008 From: dons at galois.com (Don Stewart) Date: Sat May 10 02:15:46 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> Message-ID: <20080510062140.GD24496@scytale.galois.com> vigalchin: > so Don you are saying that mqueue and RTsched I should put on Hackage to > avoid putting in the Unix package? Vis-a-vis fsync and fdatasync I have no > choice .. they both IMO belong in Files.hsc. Right, there are two options: 1) put it in a new package. unix-extensions or 2) submit it as a patch to the libraries@haskell.org mailing list, and it can be put in the main 'unix' darcs repository, which then gets uploaded to hackage in the next release cycle. It's currently a bug that anyone can (accidentally) release their own versions of the core libraries. Cheers, Don From duncan.coutts at worc.ox.ac.uk Sat May 10 06:11:28 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 10 06:04:00 2008 Subject: Release of unix 2.4.0.0 In-Reply-To: <20080510055111.GB24496@scytale.galois.com> References: <20080510053609.GA24496@scytale.galois.com> <20080510055111.GB24496@scytale.galois.com> Message-ID: <1210414288.5824.43.camel@localhost> On Fri, 2008-05-09 at 22:51 -0700, Don Stewart wrote: > dons: > > Vasili Galchin did a release of a new version of the unix library. > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.4.0.0 > > > > Hmm :( > > > > This is a core package, maintained by libraries@, so shouldn't be being > > uploaded to hackage by 3rd parties. > > > > What can we do? Remove it. > It's also been pointed out that the darcs version of the unix package is > 2.2, while the version on hackage is 2.3. Actually that's just because the packages that go with ghc HEAD have not had their versions bumped compared to the ones that came out with ghc-6.8.x. Though it does make one wonder what other patches did not make it to the HEAD branches. Duncan From igloo at earth.li Sat May 10 06:17:49 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat May 10 06:11:48 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <20080510062140.GD24496@scytale.galois.com> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> Message-ID: <20080510101748.GA19744@matrix.chaos.earth.li> On Fri, May 09, 2008 at 11:21:40PM -0700, Donald Bruce Stewart wrote: > vigalchin: > > so Don you are saying that mqueue and RTsched I should put on Hackage to > > avoid putting in the Unix package? Vis-a-vis fsync and fdatasync I have no > > choice .. they both IMO belong in Files.hsc. > > 2) submit it as a patch to the libraries@haskell.org mailing list, > and it can be put in the main 'unix' darcs repository, which then > gets uploaded to hackage in the next release cycle. Or better still, follow http://www.haskell.org/haskellwiki/Library_submissions so it doesn't end up being overlooked and forgotten about. > It's currently a bug that anyone can (accidentally) release their own > versions of the core libraries. Yes, this mix-up is really our fault; we don't advertise or enforce our policies well enough (I'm not even sure if we've got total agreement on what they are?). It's also raised an interesting question of who can upload the packages maintained by libraries@. I guess we just create a sensible looking list of people (roughly equal to those who release Haskell implementations probably makes sense). Thanks Ian From bulat.ziganshin at gmail.com Sat May 10 06:24:11 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 10 06:19:41 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <20080510101748.GA19744@matrix.chaos.earth.li> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> Message-ID: <699202671.20080510142411@gmail.com> Hello Ian, Saturday, May 10, 2008, 2:17:49 PM, you wrote: > It's also raised an interesting question of who can upload the packages > maintained by libraries@. I guess we just create a sensible looking list > of people (roughly equal to those who release Haskell implementations > probably makes sense). i propose to assign password to each package uploaded to hackage and require this password when next version of package is uploaded. it should be easy to implement and should provide enough security for our rather small community -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ross at soi.city.ac.uk Sat May 10 06:51:19 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat May 10 06:45:17 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <20080510101748.GA19744@matrix.chaos.earth.li> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> Message-ID: <20080510105118.GA3500@soi.city.ac.uk> On Sat, May 10, 2008 at 11:17:49AM +0100, Ian Lynagh wrote: > On Fri, May 09, 2008 at 11:21:40PM -0700, Donald Bruce Stewart wrote: > > It's currently a bug that anyone can (accidentally) release their own > > versions of the core libraries. > > Yes, this mix-up is really our fault; we don't advertise or enforce our > policies well enough (I'm not even sure if we've got total agreement on > what they are?). > > It's also raised an interesting question of who can upload the packages > maintained by libraries@. I guess we just create a sensible looking list > of people (roughly equal to those who release Haskell implementations > probably makes sense). Up to now, releases of these packages have been part of GHC releases; the versions on hackage have been images of the packages from GHC source releases. If we're going to do releases of them more often, that ought to be done via the libraries list. It's a special case of a broader problem with non-maintainer uploads (i.e. releases), which cause exactly the same problems for other packages too. If we had an agreed policy we could advertise and enforce it, but we don't. I don't think that mechanized enforcement is the priority; having a policy is. We also need to ensure that the version in the darcs repo is larger than the most recent release, but smaller than the release to follow. From bulat.ziganshin at gmail.com Sat May 10 07:02:22 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 10 06:56:48 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <20080510105118.GA3500@soi.city.ac.uk> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> <20080510105118.GA3500@soi.city.ac.uk> Message-ID: <7310635656.20080510150222@gmail.com> Hello Ross, Saturday, May 10, 2008, 2:51:19 PM, you wrote: > It's a special case of a broader problem with non-maintainer uploads > (i.e. releases), which cause exactly the same problems for other packages > too. If we had an agreed policy we could advertise and enforce it, but > we don't. I don't think that mechanized enforcement is the priority; > having a policy is. at least we should start with it :) i propose that uploader of first version takes "ownership" of package which may be transferred to other person. uploads of subsequent versions can be made by "owner" or his "trusted persons" password-protection mechanism i've proposed in previous message partially enforces this policy, although with many caveats. i hope, though, that it will be enough for current community size -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Sat May 10 07:31:17 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat May 10 07:25:12 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <7310635656.20080510150222@gmail.com> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> <20080510105118.GA3500@soi.city.ac.uk> <7310635656.20080510150222@gmail.com> Message-ID: <404396ef0805100431sb046d13k5d5c4622c3f34291@mail.gmail.com> Hi > password-protection mechanism i've proposed in previous message > partially enforces this policy, although with many caveats. i hope, Yay, another password... My suggestion would be that each account has a list of permissible packages it can upload. i.e. Ian/Ross/Simon would all have their accounts include unix as a permissible package. If a user uploads a new package, which has not been on hackage before, it gets added to their list. A little UI to allow logged in users to add additional package maintainers and we'd be all sort - but the UI could come later. In general it would enforce what we want, with no overhead in the common case. Thanks Neil From duncan.coutts at worc.ox.ac.uk Sat May 10 07:47:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 10 07:40:19 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <404396ef0805100431sb046d13k5d5c4622c3f34291@mail.gmail.com> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> <20080510105118.GA3500@soi.city.ac.uk> <7310635656.20080510150222@gmail.com> <404396ef0805100431sb046d13k5d5c4622c3f34291@mail.gmail.com> Message-ID: <1210420068.5824.50.camel@localhost> On Sat, 2008-05-10 at 12:31 +0100, Neil Mitchell wrote: > Hi > > > password-protection mechanism i've proposed in previous message > > partially enforces this policy, although with many caveats. i hope, > > Yay, another password... > > My suggestion would be that each account has a list of permissible > packages it can upload. i.e. Ian/Ross/Simon would all have their > accounts include unix as a permissible package. If a user uploads a > new package, which has not been on hackage before, it gets added to > their list. A little UI to allow logged in users to add additional > package maintainers and we'd be all sort - but the UI could come > later. In general it would enforce what we want, with no overhead in > the common case. Yes, I agree. (I know it's a relation but it seems more intuitive to view it from the package side rather than the user side) Duncan From duncan.coutts at worc.ox.ac.uk Sat May 10 08:00:28 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 10 07:53:11 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <20080510105118.GA3500@soi.city.ac.uk> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> <20080510105118.GA3500@soi.city.ac.uk> Message-ID: <1210420828.5824.63.camel@localhost> On Sat, 2008-05-10 at 11:51 +0100, Ross Paterson wrote: > It's a special case of a broader problem with non-maintainer uploads > (i.e. releases), which cause exactly the same problems for other packages > too. If we had an agreed policy we could advertise and enforce it, but > we don't. I don't think that mechanized enforcement is the priority; > having a policy is. This seems like a good moment to revisit that discussion http://haskell.org/pipermail/libraries/2008-February/009343.html Here's a straw man policy: We want packages to be uploaded by maintainers or someone the maintainer/author has delegated that responsibility to. Packages can be forked at any time but with new names. Transferring maintenance of a package from one person to another is easy since it's just delegation. The tricky case is when the original maintainer/author disappears without delegating/nominating new maintainers and a new volunteer wants to pick up the package under the original name. We can borrow a policy here from some existing organisation, the procedure usually involves trying to find the maintainer, giving them time to respond, then announcing that you want to take over maintenance and seeking feedback and hopefully reaching a consensus. Duncan From bulat.ziganshin at gmail.com Sat May 10 08:57:58 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 10 08:52:20 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <1210420828.5824.63.camel@localhost> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> <20080510105118.GA3500@soi.city.ac.uk> <1210420828.5824.63.camel@localhost> Message-ID: <78841955.20080510165758@gmail.com> Hello Duncan, Saturday, May 10, 2008, 4:00:28 PM, you wrote: > We want packages to be uploaded by maintainers or someone the > maintainer/author has delegated that responsibility to. > Packages can be forked at any time but with new names. Transferring > maintenance of a package from one person to another is easy since it's > just delegation. there is a difference: generally speaking, we have a list of persons that can upload new versions of package and list of persons who can change the first list am i correctly understood that you propose to make these lists identical? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sat May 10 09:56:33 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 10 09:49:04 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <78841955.20080510165758@gmail.com> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> <20080510105118.GA3500@soi.city.ac.uk> <1210420828.5824.63.camel@localhost> <78841955.20080510165758@gmail.com> Message-ID: <1210427793.5824.64.camel@localhost> On Sat, 2008-05-10 at 16:57 +0400, Bulat Ziganshin wrote: > Saturday, May 10, 2008, 4:00:28 PM, you wrote: > > > We want packages to be uploaded by maintainers or someone the > > maintainer/author has delegated that responsibility to. > > > Packages can be forked at any time but with new names. Transferring > > maintenance of a package from one person to another is easy since it's > > just delegation. > > there is a difference: generally speaking, we have a list of persons > that can upload new versions of package and list of persons who can > change the first list > > am i correctly understood that you propose to make these lists > identical? Yes, it's simpler. Duncan From apa3a at yahoo.com Sat May 10 10:10:08 2008 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Sat May 10 10:04:05 2008 Subject: Patch: fixed typo in base modules comments Message-ID: <13640.75596.qm@web56707.mail.re3.yahoo.com> Replaced "iff" with "if". Please apply. Andriy ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- A non-text attachment was scrubbed... Name: iff.patch.gz Type: application/postscript Size: 29098 bytes Desc: 1617657719-iff.patch.gz Url : http://www.haskell.org/pipermail/libraries/attachments/20080510/d177d383/iff.patch-0001.ai From lennart at augustsson.net Sat May 10 10:17:41 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat May 10 10:11:36 2008 Subject: Patch: fixed typo in base modules comments In-Reply-To: <13640.75596.qm@web56707.mail.re3.yahoo.com> References: <13640.75596.qm@web56707.mail.re3.yahoo.com> Message-ID: But all those iffs are supposed to be iffs (that's iff in the usual "if and only if" meaning). 2008/5/10 Andriy Palamarchuk : > Replaced "iff" with "if". > Please apply. > Andriy > > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080510/7476e2ba/attachment.htm From igloo at earth.li Sat May 10 10:17:40 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat May 10 10:11:37 2008 Subject: Patch: fixed typo in base modules comments In-Reply-To: <13640.75596.qm@web56707.mail.re3.yahoo.com> References: <13640.75596.qm@web56707.mail.re3.yahoo.com> Message-ID: <20080510141740.GA23186@matrix.chaos.earth.li> On Sat, May 10, 2008 at 07:10:08AM -0700, Andriy Palamarchuk wrote: > Replaced "iff" with "if". "iff" is actually correctly spelt - it means "if and only if". Thanks Ian From ndmitchell at gmail.com Sat May 10 10:22:33 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat May 10 10:16:27 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <1210427793.5824.64.camel@localhost> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> <20080510055847.GC24496@scytale.galois.com> <5ae4f2ba0805092315h533b7dd6i71b267aff60ac72b@mail.gmail.com> <20080510062140.GD24496@scytale.galois.com> <20080510101748.GA19744@matrix.chaos.earth.li> <20080510105118.GA3500@soi.city.ac.uk> <1210420828.5824.63.camel@localhost> <78841955.20080510165758@gmail.com> <1210427793.5824.64.camel@localhost> Message-ID: <404396ef0805100722x31ff7213j7c919ecfec1153bf@mail.gmail.com> Hi >> there is a difference: generally speaking, we have a list of persons >> that can upload new versions of package and list of persons who can >> change the first list >> >> am i correctly understood that you propose to make these lists >> identical? > > Yes, it's simpler. For the most part, yes. In reality, I suspect Ian/Ross/Simon and the other Hackage admins will be able to edit all the lists. Thanks Neil From bjorn.buckwalter at gmail.com Sun May 11 20:13:29 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Sun May 11 20:07:19 2008 Subject: Data.Time questions Message-ID: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> Dear all, I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. Before submitting a patch I want to confirm with you that they belong in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is this correct? I'm doing work on additional time coordinates of interest to e.g. astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 seconds, previously known as Terrestrial Dynamical Time or TDT) and perhaps Geocentric Coordinate Time (TCG) and others. Would you be interested in receiving patches with these rather esoteric time coordinates? If not I'll release them in a new "time-astro" package. Thanks, Bjorn Buckwalter From dons at galois.com Sun May 11 20:17:56 2008 From: dons at galois.com (Don Stewart) Date: Sun May 11 20:11:49 2008 Subject: Data.Time questions In-Reply-To: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> References: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> Message-ID: <20080512001756.GA12845@scytale.galois.com> bjorn.buckwalter: > Dear all, > > I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. > Before submitting a patch I want to confirm with you that they belong > in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is > this correct? > > I'm doing work on additional time coordinates of interest to e.g. > astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 > seconds, previously known as Terrestrial Dynamical Time or TDT) and > perhaps Geocentric Coordinate Time (TCG) and others. Would you be > interested in receiving patches with these rather esoteric time > coordinates? If not I'll release them in a new "time-astro" package. 'space-time' would be a nice package name. import System.Time.Space :) From ashley at semantic.org Sun May 11 21:06:53 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sun May 11 21:00:43 2008 Subject: Data.Time questions In-Reply-To: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> References: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> Message-ID: <4827982D.9040706@semantic.org> Bjorn Buckwalter wrote: > Dear all, > > I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. > Before submitting a patch I want to confirm with you that they belong > in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is > this correct? I'm not sure if it matters, since it is instances rather than new exported symbols, and anyone using those instances must have both AbsoluteTime and ParseTime in scope already. > I'm doing work on additional time coordinates of interest to e.g. > astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 > seconds, previously known as Terrestrial Dynamical Time or TDT) and > perhaps Geocentric Coordinate Time (TCG) and others. Would you be > interested in receiving patches with these rather esoteric time > coordinates? If not I'll release them in a new "time-astro" package. Are you going to create a new type for TT? TT is isomorphic to TAI in the category of measurements. I've generally tried to avoid separate types for isomorphic measurements. That's why it's called AbsoluteTime rather than TAITime... -- Ashley Yakeley From bjorn.buckwalter at gmail.com Sun May 11 22:21:27 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Sun May 11 22:15:17 2008 Subject: Data.Time questions In-Reply-To: <4827982D.9040706@semantic.org> References: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> <4827982D.9040706@semantic.org> Message-ID: <8b2a1a960805111921i39fcca89v8d36e29880379113@mail.gmail.com> On Sun, May 11, 2008 at 9:06 PM, Ashley Yakeley wrote: >> I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. >> Before submitting a patch I want to confirm with you that they belong >> in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is >> this correct? > > I'm not sure if it matters, since it is instances rather than new exported > symbols, and anyone using those instances must have both AbsoluteTime and > ParseTime in scope already. True for the 'ParseTime' instance but not necessarily so for the 'Read' instance. I recall being rather confused at first that 'UTCTime' and its 'Show' and 'Read' instances were in three different modules, but perhaps it has to be that was due to dependencies. This doesn't seem to be the case with 'AbsoluteTime' so since you don't seems to have any preference I'll put them all in 'Data.Time.Clock.TAI'. >> I'm doing work on additional time coordinates of interest to e.g. >> astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 >> seconds, previously known as Terrestrial Dynamical Time or TDT) and >> perhaps Geocentric Coordinate Time (TCG) and others. Would you be >> interested in receiving patches with these rather esoteric time >> coordinates? If not I'll release them in a new "time-astro" package. > > Are you going to create a new type for TT? > > TT is isomorphic to TAI in the category of measurements. I've generally > tried to avoid separate types for isomorphic measurements. That's why it's > called AbsoluteTime rather than TAITime... I did already create a new type for TT. However, what you are saying makes sense too (I've been wondering about the 'AbsoluteTime' name). I'm not sure that how to best handle parsing and formatting of TT without another type though... I'll give it some thought. Hmm, I realize I might also have to reconsider my 'ParseTime' instance for 'AbsoluteTime' before I submit that patch... Thanks, Bjorn From ashley at semantic.org Mon May 12 05:15:09 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon May 12 05:08:59 2008 Subject: Data.Time questions In-Reply-To: <8b2a1a960805111921i39fcca89v8d36e29880379113@mail.gmail.com> References: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> <4827982D.9040706@semantic.org> <8b2a1a960805111921i39fcca89v8d36e29880379113@mail.gmail.com> Message-ID: <48280A9D.8070207@semantic.org> Bjorn Buckwalter wrote: > I did already create a new type for TT. However, what you are saying > makes sense too (I've been wondering about the 'AbsoluteTime' name). > I'm not sure that how to best handle parsing and formatting of TT > without another type though... I'll give it some thought. > Hmm, I realize I might also have to reconsider my 'ParseTime' instance > for 'AbsoluteTime' before I submit that patch... I see the problem now. TT and TAI are the same up to isomorphism, but they both can be written in YMD HMS format, with a 32.184s difference. So how to parse? So far I note the interesting property that any given String logically corresponds to at most one type: "2008-05-01": Day "05:45": TimeOfDay "UTC-7": TimeZone "2008-05-01 05:45": LocalTime "2008-05-01 05:45 UTC-7": ZonedTime I'm not sure if that really matters, especially as one would need a new union type make use of it, but we could do an "instance ParseTime AbsoluteTime" if we insist on virtual time-zone strings: "2008-01-01 00:00:00 TAI": AbsoluteTime "2008-01-01 00:00:32.184 TT": AbsoluteTime "2007-12-31 23:59:41 GPS": AbsoluteTime I'm not sure what to do about FormatTime, though. Another approach is to consider the TAI, TT, GPS time-scales as a parallel system of "zones". So we currently have data ZonedTime = ZonedTime LocalTime TimeZone utcToZonedTime :: TimeZone -> UTCTime -> ZonedTime zonedTimeToUTC :: ZonedTime -> UTCTime We could add something like data ScaledTime = ScaledTime LocalTime TimeScale absoluteToScaledTime :: TimeScale -> AbsoluteTime -> ScaledTime scaledTimeToAbsolute :: ScaledTime -> AbsoluteTime This would then give us "2008-01-01 00:00:00 TAI": ScaledTime "2008-01-01 00:00:32.184 TT": ScaledTime "2007-12-31 23:59:41 GPS": ScaledTime This would belong in the "specialist" module Data.Time.Clock.TAI, which isn't included in Data.Time, so it shouldn't bother ordinary users of time. -- Ashley Yakeley From marlowsd at gmail.com Mon May 12 07:04:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon May 12 06:58:31 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <4823D405.2070303@cse.unsw.edu.au> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <4823D405.2070303@cse.unsw.edu.au> Message-ID: <48282442.7050001@gmail.com> Roman Leshchinskiy wrote: > IMO, a package is absolutely the wrong thing to depend on. Essentially, > a package is an implementation of an interface and depending on > implementations is a bad thing. Code should only depend on interfaces > which are completely independent entities. I suspect that a lot of the > problems with packages occur because the current system doesn't follow > this simple principle. > > It would be nice if Cabal had an explicit concept of interfaces, with > the idea that code depends on them and packages implement them. In the > simplest case, an interface is just a name. Ideally, it would be a > combination of type signatures, Quickcheck properties, proof obligations > etc. The important thing is that it has an explicit definition which is > completely independent of any concrete implementation and which never > changes. > > Something like this would immediately solve a lot of problems. Several > packages could implement the same interface and we could pick which one > we want when building stuff. We could have much more fine-grained > dependencies (if all I need is an AVL tree, I don't want to depend on > the entire containers package, but rather just on the AVL part of it). > One package could implement several versions of an interface to ensure > compatibility with old code (I could imagine module names like > AVL_1.Data.AVLTree, AVL_2.Data.AVLTree etc., where AVL_1 and AVL_2 are > interface names; Cabal could then map the right module to Data.AVLTree > when building). If interface definitions include something like > Quickcheck properties, we would have at least some assurance that a > package actually does implement its interfaces. Moreover, this would > also make the properties themselves reusable. We already have interfaces, in the sense that a package *is* an interface. You're suggestion decoupling these notions, which I believe would add a lot of extra complexity without enough benefit to make it worthwhile. Let's take the examples you gave above: 1. several packages could implement the same interface. This can be done by having a single package that exports an interface and depends on one of the underlying "providers" selected at build-time. 2. fine-grained dependencies: just split up packages, or define new packages that just re-export parts of existing packages, if that's what you want. 3. one package could implement several versions of an interface. This is no different from having several versions of a package that can all be installed and used together. 4. interface definitions could have QuickCheck properties. Absolutely! And packages can have QuickCheck properties too. Admittedly in order to do most of this we need to be able to define packages that re-export the contents of other packages. You can in fact already do this, but it's clumsy, we just need some tool and compiler support to make it smoother. I'm already convinced that we need this, and I believe we should do it in the GHC 6.10 timeframe in order to allow better backwards compatibility. Using the Package Versioning Policy we have a clear way to know when a package's interface has changed, or when the interface has remained the same but the implementation has changed. We need tool support to check that the author is adhering to the PVP, though. Basically the current scheme minimizes the cognitive load by having a single concept (the package) that embodies several units: distribution, licensing, dependency, linking (amongst others). Cheers, Simon From bjorn.buckwalter at gmail.com Mon May 12 08:13:44 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Mon May 12 08:07:34 2008 Subject: Data.Time questions In-Reply-To: <48280A9D.8070207@semantic.org> References: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> <4827982D.9040706@semantic.org> <8b2a1a960805111921i39fcca89v8d36e29880379113@mail.gmail.com> <48280A9D.8070207@semantic.org> Message-ID: <8b2a1a960805120513w56b1045cha7067bc9203dbf68@mail.gmail.com> On Mon, May 12, 2008 at 5:15 AM, Ashley Yakeley wrote: >> I did already create a new type for TT. However, what you are saying >> makes sense too (I've been wondering about the 'AbsoluteTime' name). >> I'm not sure that how to best handle parsing and formatting of TT >> without another type though... I'll give it some thought. > >> Hmm, I realize I might also have to reconsider my 'ParseTime' instance >> for 'AbsoluteTime' before I submit that patch... > > I see the problem now. TT and TAI are the same up to isomorphism, but they > both can be written in YMD HMS format, with a 32.184s difference. So how to > parse? > > So far I note the interesting property that any given String logically > corresponds to at most one type: > > "2008-05-01": Day > "05:45": TimeOfDay > "UTC-7": TimeZone > "2008-05-01 05:45": LocalTime > "2008-05-01 05:45 UTC-7": ZonedTime > > I'm not sure if that really matters, especially as one would need a new > union type make use of it, but we could do an "instance ParseTime > AbsoluteTime" if we insist on virtual time-zone strings: > > "2008-01-01 00:00:00 TAI": AbsoluteTime > "2008-01-01 00:00:32.184 TT": AbsoluteTime > "2007-12-31 23:59:41 GPS": AbsoluteTime > > I'm not sure what to do about FormatTime, though. We could perhaps use a phantom type: data AbsTime a = MkAbsTime {unAbsTime :: DiffTime} deriving (Eq,Ord) data TAI = TAI data TT = TT ... type TAITime = AbsTime TAI ... This would allow using different instances for e.g. 'Show' while avoiding duplicating other code. > Another approach is to consider the TAI, TT, GPS time-scales as a parallel > system of "zones". So we currently have > > data ZonedTime = ZonedTime LocalTime TimeZone > utcToZonedTime :: TimeZone -> UTCTime -> ZonedTime > zonedTimeToUTC :: ZonedTime -> UTCTime > > We could add something like > > data ScaledTime = ScaledTime LocalTime TimeScale > absoluteToScaledTime :: TimeScale -> AbsoluteTime -> ScaledTime > scaledTimeToAbsolute :: ScaledTime -> AbsoluteTime > > This would then give us > > "2008-01-01 00:00:00 TAI": ScaledTime > "2008-01-01 00:00:32.184 TT": ScaledTime > "2007-12-31 23:59:41 GPS": ScaledTime Note that for e.g. TCG the length of a second is "Scaled" w.r.t a TT seconds by dTT/dTCG = 1 ? LG. Do you propose such information be included in the TimeScale? > This would belong in the "specialist" module Data.Time.Clock.TAI, which > isn't included in Data.Time, so it shouldn't bother ordinary users of time. With the ideas above it seems we are straying further and further from the brute-force implementation I was originally envisioning for TT. I'll try to explore the design space... let me know if you have any more ideas or insights. Thanks, Bjorn From rl at cse.unsw.edu.au Mon May 12 09:53:55 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Mon May 12 09:47:57 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <48282442.7050001@gmail.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <4823D405.2070303@cse.unsw.edu.au> <48282442.7050001@gmail.com> Message-ID: <48284BF3.3080601@cse.unsw.edu.au> Simon Marlow wrote: > > We already have interfaces, in the sense that a package *is* an > interface. You're suggestion decoupling these notions, which I believe > would add a lot of extra complexity without enough benefit to make it > worthwhile. Well, a package is an interface in the sense that it incidentially defines one. However, I have no idea how to extract the interface from the package. I also don't really understand how to depend on it (see below). In general, I think it's fair to say that what we have now is somewhat akin to dynamic typing of packages. I'd like to have static typing. I expect the benefits to be similar to those of static over dynamic typing. As to the complexity, I don't think having explicit interfaces would be much more complex than implementing a tool which checks that the package versioning policy is being followed. > Let's take the examples you gave above: > > 1. several packages could implement the same interface. This can be > done by having a single package that exports an interface and depends on > one of the underlying "providers" selected at build-time. By build-time, do you mean when building the application which depends on the interface or when building the interface package? I'm interested in the former but I suspect you mean the latter. As an example, suppose Alice writes a package and Bob writes an application that depends on it. Now, Chris doesn't like Alice and forks her package. He now wants to build Bob's application with his package instead of Alice's. How can he do it at the moment without having Alice and/or Bob apply any patches to their stuff? What if instead of an app, Bob writes a package which other apps depend on? > 2. fine-grained dependencies: just split up packages, or define new > packages that just re-export parts of existing packages, if that's what > you want. I don't think that splitting up packages is really an option since the packages' authors wouldn't always agree to it and in any case, we don't want to have a lot of artificially small packages. Reexporting would work, I guess, but do I now have to distribute all those packages which just reexport along with my stuff? I general, IMO packages and interfaces are simply at different levels of granularity. To make this more concrete: suppose Alice implements package trees and Bob package containers. Both contain compatible implementations of AVL trees. Chris need AVL trees in his application but doesn't care where they come from and wants his users to be able to pick one when building the app. What does he do? And how do Alice and Bob ensure that their implementations are, in fact, compatible? > 3. one package could implement several versions of an interface. This > is no different from having several versions of a package that can all > be installed and used together. I have to disagree here. There is quite a difference between maintaining a legacy interface in new versions of software and maintaining several versions of that software. Suppose I write a package and a lot of applications (not necessarily mine) depend on version 1 of that package. Now, for version 2 I completely redesign it such that the interface becomes incompatible with version 1. Unless there is a way for me to somehow provide the version 1 interface in my version 2 package, I'll have to keep maintaining the old version until all those applications migrate. This can be done now, I suppose, but not without jumping through some hoops. > 4. interface definitions could have QuickCheck properties. Absolutely! > And packages can have QuickCheck properties too. Of course, but these properties can't be easily shared between packages which implement the same interface. Suppose Alice implements a package and Bob wants to reimplement it. He can copy Alice's QuickCheck properties into his code, of course, but that means that he we now have two sets of those properties which will be maintained separately. Also, these properties aren't really visible to a package's client at the moment since we don't even have a convention where to put those. IIUC, they aren't even considered part of the interface when it comes to package versioning. This is bad! > Using the Package Versioning Policy we have a clear way to know when a > package's interface has changed, or when the interface has remained the > same but the implementation has changed. We need tool support to check > that the author is adhering to the PVP, though. What will this tool check? That the set of exported names doesn't change? That they have the same signatures? That the QuickCheck properties remain the same? That the package satisfies the same theories (once we have support for formal reasoning)? If the answer to any of the above is no, then why not? On the other hand, if it will do all of the above, then wouldn't it be much easier to explicitly specify the interface instead of having to extract it from the package somehow? Also, I don't really understand how PVP is supposed to work, to be honest. If all I need is function doThis from package foo 1.0, what do I depend on? foo 1.*? What if foo 2.0 has a slightly different interface but still exports doThis? Finally, I was always under the impression that PVP is something we want to have for the core packages. I didn't realise that it is supposed to be a universally accepted policy and I don't think that would work. Almost all software companies, for instance, have their own versioning policy. We can't make them use ours. In general, the larger the Haskell community becomes the less likely it will be that any kind of convention will work. We ought to plan for the future and adopt an approach that scales. > Basically the current scheme minimizes the cognitive load by having a > single concept (the package) that embodies several units: distribution, > licensing, dependency, linking (amongst others). I have my doubts about minimizing the cognitive load. To return to the dynamic vs. static typing analogy: although static typing requires more bookkeeping and introduces more concepts, it certainly leads to less cognitive load for me. Abstraction barriers are good! Well, as long as there aren't too many but at the moment, we don't have *any*. Roman From ashley at semantic.org Tue May 13 20:30:51 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue May 13 20:24:36 2008 Subject: Data.Time questions In-Reply-To: <48280A9D.8070207@semantic.org> References: <8b2a1a960805111713h2ea81b30y37728c0be39cf2d5@mail.gmail.com> <4827982D.9040706@semantic.org> <8b2a1a960805111921i39fcca89v8d36e29880379113@mail.gmail.com> <48280A9D.8070207@semantic.org> Message-ID: <1210725051.6429.3.camel@sherbourne> On Mon, 2008-05-12 at 02:15 -0700, I wrote: > I see the problem now. TT and TAI are the same up to isomorphism, but > they both can be written in YMD HMS format, with a 32.184s difference. > So how to parse? Perhaps we shouldn't at all. This is what Steve Allen has to say: "The forms of dynamical, atomic, and coordinate time above are not based on earth rotation. They have no connection with days in the traditional sense; thus they have no simple relationship with the concept of a calendar. It is important to remember that the 24-hour cycle of tags like 12:00:00 really only makes sense for earth rotation time." "To their credit, the BIPM do report TAI and TT using modified Julian date (MJD) notation. Nevertheless, it remains commonplace to use the traditional calendrical and sexagesimal notations when counting the seconds which are defined by these time scales. (Indeed, for the sake of human cognition this notational convenience is very nearly a requirement.) Unfortunately, that usage leads to even greater confusion about the meanings of time scales." "Denoting TAI with a tag in the form 1958-01-01T00:00:00, and denoting TT, TCG, or TCB with a tag in the form 1977-01-01T00:00:00 should be considered as a convenience only. They are merely counts of elapsed time where one anonymous and indistinguishable second follows another. It is very appropriate to count these forms of time using decimal notation from the epochs represented by those tags. But there is no observable event that happens cyclically at 12:00:00 for dynamical, atomic, or coordinate time -- the entire notion of such a cyclical process is contrary to their uniformly-incrementing conceptual definitions." -- Ashley Yakeley From jules at jellybean.co.uk Wed May 14 09:58:46 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed May 14 09:52:34 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <481758D6.30102@gmail.com> References: <480E6478.5040209@gmail.com> <1208905284.27748.126.camel@localhost> <480E763A.6080201@gmail.com> <1208942866.27748.162.camel@localhost> <481758D6.30102@gmail.com> Message-ID: <482AF016.60401@jellybean.co.uk> Simon Marlow wrote: > Duncan Coutts wrote: >> On Tue, 2008-04-22 at 16:35 -0700, Simon Marlow wrote: >>> Duncan Coutts wrote: >>> >>>> Do you suppose we can rename the system/rawSystem given that we're >>>> already moving them from one module to another? >>>> >>>> Just off the top of my head, how about "runShellCommand" & >>>> "runProgram", >>>> better suggestions welcome. >>> Well, ideally we'd do a complete renaming sweep, e.g. runProcess >>> should be spawnProcess (or just removed entirely), then we could use >>> runProcess for what is currently called rawSystem. But I've got >>> enough flak for changing APIs in the past so I wimped out this time :-) >> >> Ah but this isn't a change, it's a new api, so we have complete freedom. >> We're adding a new replacement for system/rawSystem and deprecating the >> old module. > > I can't think of a good naming scheme that doesn't break backwards > compatibility. Suggestions welcome. > > Ideally we'd change runProcess to spawnProcess, and similarly for > runCommand, runInteractiveCommand etc. But then what do we use for > 'system' and 'rawSystem'? Good names for these are 'runCommand' and > 'runProcess' respectively, but we can't re-use those names without > breaking the API (we want to leave the old versions in place deprecated > for a while). Surely you can put the nicest new names in another module System.Process.RunCommand (or whatever) programs which use the old versions will still work. Programs which want the nicely named new versions can import from the new module. One day, in a later version, you can move them out to the main namespace. Jules From bulat.ziganshin at gmail.com Wed May 14 10:20:05 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 14 10:14:32 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <482AF016.60401@jellybean.co.uk> References: <480E6478.5040209@gmail.com> <1208905284.27748.126.camel@localhost> <480E763A.6080201@gmail.com> <1208942866.27748.162.camel@localhost> <481758D6.30102@gmail.com> <482AF016.60401@jellybean.co.uk> Message-ID: <9210531431.20080514182005@gmail.com> Hello Jules, Wednesday, May 14, 2008, 5:58:46 PM, you wrote: > Surely you can put the nicest new names in another module > System.Process.RunCommand > (or whatever) > programs which use the old versions will still work. Programs which want > the nicely named new versions can import from the new module. yes, it will work, but may become source of confusion: it will be impossible to copy-paste code between modules importing old and new functions and it will be impossible to understand behavior of code snippet without looking into imports -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jules at jellybean.co.uk Wed May 14 10:23:54 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed May 14 10:17:38 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <9210531431.20080514182005@gmail.com> References: <480E6478.5040209@gmail.com> <1208905284.27748.126.camel@localhost> <480E763A.6080201@gmail.com> <1208942866.27748.162.camel@localhost> <481758D6.30102@gmail.com> <482AF016.60401@jellybean.co.uk> <9210531431.20080514182005@gmail.com> Message-ID: <482AF5FA.5020406@jellybean.co.uk> Bulat Ziganshin wrote: > Hello Jules, > > Wednesday, May 14, 2008, 5:58:46 PM, you wrote: > >> Surely you can put the nicest new names in another module > >> System.Process.RunCommand > >> (or whatever) > >> programs which use the old versions will still work. Programs which want >> the nicely named new versions can import from the new module. > > yes, it will work, but may become source of confusion: it will be > impossible to copy-paste code between modules importing old and new > functions and it will be impossible to understand behavior of code > snippet without looking into imports > True enough. And this is already true. Consider the Traversable/Foldable functions which 'replace' the Data.List / Control.Monad versions. I feel haskell is slightly weak at this kind of book-keeping actually. It's annoying that having decided to prefer the 'new' mapM_, and hiding the old from Control.Monad, you have to also hide it from the other places which re-export it. I don't have a concrete suggestion for how to improve this :-( But the problem will surely come up again and again as the libraries get bigger and more things get either deprecated or generalised. Jules From marlowsd at gmail.com Thu May 15 05:45:32 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 05:39:20 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <482AF5FA.5020406@jellybean.co.uk> References: <480E6478.5040209@gmail.com> <1208905284.27748.126.camel@localhost> <480E763A.6080201@gmail.com> <1208942866.27748.162.camel@localhost> <481758D6.30102@gmail.com> <482AF016.60401@jellybean.co.uk> <9210531431.20080514182005@gmail.com> <482AF5FA.5020406@jellybean.co.uk> Message-ID: <482C063C.4010203@gmail.com> The latest version of the Process overhaul is here: http://darcs.haskell.org/~simonmar/process/System-Process.html and the patch is here: http://darcs.haskell.org/~simonmar/process-2.0.patch Changes from previous: - changes to readProcess, and added readProcessWithExitCode, as discussed on the list. - added close_fds flag to the CreateProcess record, to request closing all FDs in the child. See: http://hackage.haskell.org/trac/ghc/ticket/1415 - made it work on Windows, and the patch passes GHC's validate on both Windows and Linux. Reminder: the deadline for discussion is 20 May (5 days). Cheers, Simon From twanvl at gmail.com Thu May 15 20:14:02 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu May 15 20:07:54 2008 Subject: Proposal/Idea: Split up base even further Message-ID: <482CD1CA.3010506@gmail.com> Hello librarians, Here is an idea to resolve some of the problems that remain with the base package: The problem: Users can not update their version of the 'base' package, since it is tied to Ghc. If a useful new function is added using it requires updating the compiler. On the one hand this puts people off using these new functions. On the other hand it also makes updates to for instance Data.List take way longer to reach the users because we have to wait for the next Ghc release. The proposal: User code should NEVER import the library that is now called 'base', it should provide an internal API only. For example, base can include the modules Internal.Data.List Internal.Control.Monad Internal.IO etc. Which are as minimal and low level as possible, containing just the things that Ghc RELIES on like: - type classes for which instances can be derived (Eq, Ord, etc.) - data types and classes with syntactic sugar (Bool, [], Num, Monad) - low level stuff like IO and ST and primitives In short, everything that is now under Ghc.*, and hopefully less, becomes the new base library. In my opinion half of that can still be moved out, like most of Ghc.List, Ghc.Enum, Ghc.IO and Ghc.Read. The next layer can then consist of many packages like "containers", "control", "numeric", "concurrent", "ioref", "file-io", "foreign", etc. For example the Data.List module imports Internal.Data.List for the basic list data type. It re-exports this, and adds many additional functions that don't belong in the minimal base library. Thoughts? Twan From ndmitchell at gmail.com Fri May 16 09:34:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri May 16 09:28:24 2008 Subject: Proposal: overhaul System.Process In-Reply-To: <482C063C.4010203@gmail.com> References: <480E6478.5040209@gmail.com> <1208905284.27748.126.camel@localhost> <480E763A.6080201@gmail.com> <1208942866.27748.162.camel@localhost> <481758D6.30102@gmail.com> <482AF016.60401@jellybean.co.uk>