From juhp at community.haskell.org Mon Feb 3 03:13:18 2014 From: juhp at community.haskell.org (Jens Petersen) Date: Mon, 3 Feb 2014 12:13:18 +0900 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: +1 for Carter's proposal - I had actually been planning to make the same suggestion, but just saw this thread now... On 27 January 2014 09:39, Austin Seipp wrote: > As for shipping with GHC itself: this is technically possible, but > slightly annoying to implement, and it also makes the build processes > for a release slightly more annoying (which is mostly my problem.) But > it is all doable. However, keep in mind I *do not* maintain the binary > distributions for everything, nor do Cabal devs have access to all > hardware - so all people making upstream releases for their platforms > (i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal > themselves. But perhaps that's not a huge deal. > If ghc provided cabal-install I would be happy to ship that in Fedora instead of a separate package. To me cabal-install is probably the most important tool/package in HP (except for ghc itself of course): many people build/bootstrap latest ghc themselves it seems and so providing the latest cabal-install out of the box too would be a big win IMO, making it much easier to test ghc. (I wouldn't even mind if ghc shipped cabal-install's dependencies too.) Jens ps Of course it could be made a configure option whether to build cabal-install or now: the cabal-install source is already there. ;) :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Wed Feb 5 04:34:20 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Wed, 5 Feb 2014 04:34:20 +0000 Subject: System.Directory.getPermissions crashes when checking file on read-only file system Message-ID: Prelude> System.Directory.getPermissions "/usr/bin/ld" *** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system) That seems wrong. An access(*, W_OK) syscall by design should return EROFS on a read-only file system by specification. This breaks Cabal on SmartOS since /usr is read-only by design and Cabal calls getPermissions "/usr/bin/ld". Is this a Cabal bug or a directory library bug? I am happy to contribute to fixing this in any way I can. Best, Alain From bos at serpentine.com Wed Feb 5 05:33:02 2014 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 4 Feb 2014 21:33:02 -0800 Subject: New Win32 release more or less ready Message-ID: Hi, Austin - I've played some catchup with the Win32 library today, and HEAD currently builds with 7.4 through 7.8 (32- and 64-bit) and contains some additional bugfixes. Unless some last minute changes come in, this is more or less what we should ship with GHC 7.8.1 final. Let me know when you're ready to roll a new 7.8.1 RC, and I can tag and upload Win32 2.3.0.2 to Hackage. B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Feb 5 08:56:45 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 5 Feb 2014 10:56:45 +0200 Subject: Proposal: add Control.Exception.SomeAsyncException Message-ID: <20140205085645.GA32199@sniper> It is often useful to distinguish between synchronous and asynchronous exceptions. The common idiom is to run a user-supplied computation catching any synchronous exceptions but allowing asynchronous exceptions (such as user interrupt) pass through. There's no way to know how ? synchronously or asynchronously ? an exception was thrown, so we have to work around it by relying on the exception type itself. Unfortunately, the AsyncException type was designed as a leaf in the exceptions hierarchy, so it's not possible to extend it with user-defined asynchronous exception types. Thus I propose to add SomeAsyncException as an extensible type ("class") of asynchronous exceptions. It will be a direct subclass of SomeException, and will become the superclass of the existing AsyncException type. Users can then define their own asynchronous exceptions by subclassing SomeAsyncException. My main motivation for this change is exceptions used for timeouts. So the second part of this proposal it to mark System.Timeout.Timeout as an asynchronous exception. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From greg at gregorycollins.net Wed Feb 5 09:48:21 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Wed, 5 Feb 2014 10:48:21 +0100 Subject: System.Directory.getPermissions crashes when checking file on read-only file system In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 5:34 AM, Alain O'Dea wrote: > a directory library bug Looks like this to me. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Feb 5 10:08:23 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 5 Feb 2014 12:08:23 +0200 Subject: Proposal: add Control.Exception.SomeAsyncException In-Reply-To: <20140205085645.GA32199@sniper> References: <20140205085645.GA32199@sniper> Message-ID: <20140205100823.GA2257@sniper> I just discovered that SomeAsyncException under the exact same name and with the same intention has been added to base-4.7 (GHC 7.8). How cool is that? I'll release http://hackage.haskell.org/package/asynchronous-exceptions which can act as a compatibility package for older bases. Roman * Roman Cheplyaka [2014-02-05 10:56:45+0200] > It is often useful to distinguish between synchronous and asynchronous > exceptions. The common idiom is to run a user-supplied computation > catching any synchronous exceptions but allowing asynchronous exceptions > (such as user interrupt) pass through. > > There's no way to know how ? synchronously or asynchronously ? an > exception was thrown, so we have to work around it by relying on the > exception type itself. > > Unfortunately, the AsyncException type was designed as a leaf in the > exceptions hierarchy, so it's not possible to extend it with > user-defined asynchronous exception types. > > Thus I propose to add SomeAsyncException as an extensible type ("class") > of asynchronous exceptions. It will be a direct subclass of > SomeException, and will become the superclass of the existing > AsyncException type. > > Users can then define their own asynchronous exceptions by subclassing > SomeAsyncException. > > My main motivation for this change is exceptions used for timeouts. So > the second part of this proposal it to mark System.Timeout.Timeout as an > asynchronous exception. > > Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From qdunkan at gmail.com Wed Feb 5 18:41:54 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 5 Feb 2014 10:41:54 -0800 Subject: Proposal: add Control.Exception.SomeAsyncException In-Reply-To: <20140205100823.GA2257@sniper> References: <20140205085645.GA32199@sniper> <20140205100823.GA2257@sniper> Message-ID: On Wed, Feb 5, 2014 at 2:08 AM, Roman Cheplyaka wrote: > I just discovered that SomeAsyncException under the exact same name and > with the same intention has been added to base-4.7 (GHC 7.8). How cool > is that? In the python world this was called the time machine effect. Looks like the ghc devs have their own time machine! I recently fixed a bug with catching SomeException instead of only synchronous exceptions. I'd imagine that catching async exceptions is very often a bug, since it catches ^C and ThreadKilled and the like. If I did lots of work with exceptions I'd probably go as far as to define an alternate 'catch' that rethrows async exceptions. But I think even with AsyncException as its own class you can't say "everything except", so it still requires an explicit rethrow, yes? E.g.: case Exception.fromException exc of Just (exc :: Exception.AsyncException) -> Exception.throwIO exc Nothing -> return () From merijn at inconsistent.nl Wed Feb 5 18:46:02 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Wed, 5 Feb 2014 19:46:02 +0100 Subject: Proposal: add Control.Exception.SomeAsyncException In-Reply-To: References: <20140205085645.GA32199@sniper> <20140205100823.GA2257@sniper> Message-ID: <10CB64FB-AEED-4633-854A-DB75CF732024@inconsistent.nl> On Feb 5, 2014, at 19:41 , Evan Laforge wrote: > But I think even with AsyncException as its own class you can't say > "everything except", so it still requires an explicit rethrow, yes? > E.g.: > > case Exception.fromException exc of > Just (exc :: Exception.AsyncException) -> Exception.throwIO exc > Nothing -> return () Well, you can do: newtype AllBut e = AllBut SomeException deriving (Show, Typeable) instance forall e . Exception e => Exception (AllBut e) where fromException x = case fromException x :: Maybe e of Nothing -> Just (AllBut x) Just _ -> Nothing This lets you write "foo `catch` \(AllBut _ :: AllBut AsyncException) -> doStuff", which will catch everything *except* async exceptions. Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jwlato at gmail.com Wed Feb 5 18:51:46 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 5 Feb 2014 10:51:46 -0800 Subject: Proposal: add Control.Exception.SomeAsyncException In-Reply-To: References: <20140205085645.GA32199@sniper> <20140205100823.GA2257@sniper> Message-ID: On Feb 5, 2014 10:42 AM, "Evan Laforge" wrote: > > On Wed, Feb 5, 2014 at 2:08 AM, Roman Cheplyaka wrote: > > I just discovered that SomeAsyncException under the exact same name and > > with the same intention has been added to base-4.7 (GHC 7.8). How cool > > is that? I think this is a good enhancement, however I'm of the opinion that "catching all exceptions except async" is an anti-pattern that should usually be avoided. There was a discussion about this on -cafe several months back that I think covers it pretty well. John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Thu Feb 6 00:59:20 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Wed, 5 Feb 2014 19:59:20 -0500 Subject: incorrect MonadPlus law "v >> mzero = mzero"? In-Reply-To: References: Message-ID: On Wed, Jan 29, 2014 at 8:57 AM, Petr Pudl?k wrote: > I'm not sure what should be the proper solution. Perhaps to change the laws > to: > > return x >> mzero = mzero > (v >> mzero) >>= f = (v >> mzero)` > > That is, if an expression ends with `mzero`, it behaves like `mzero`. As others've mentioned, these come for free from being a monad together with (mzero >>= f) = mzero. The rules I'd expect MonadPlus to obey are: mzero >>= f = mzero (x `mplus` y) >> mzero = (x >> mzero) `mplus` (y >> mzero) x `mplus` (y `mplus` z) = (x `mplus` y) `mplus` z x `mplus` mzero = x mzero `mplus` y = y The last three simply state that (mplus,mzero) forms a monoid. The first two laws indicate that the (>>) notion of "multiplication" distributes over the mplus notion of "addition", but only from the right side. These laws together with the associativity of (>>) mean that MonadPlus forms a right-seminearring (or right-nearsemiring, if you prefer). If we additionally require that mplus is commutative, then its an commutative right-seminearring. Seminearrings show up naturally all over the place, especially in linguistic contexts (i.e., parsing and generation of "strings"). I know Edward Kmett has talked about them before, and other algebraically minded folks are probably familiar with them too. They're one of my favorites and not too much more difficult to work with than semirings. ObTangent: For the algebraically minded, we have that S is a semiring just in case (1) S is a right-seminearring (2) S is a left-seminearring (just flip the directionality of the first two laws above) (3) the addition of S is commutative (4) there exists an identity element for multiplication -- Live well, ~wren From winterkoninkje at gmail.com Thu Feb 6 01:01:02 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Wed, 5 Feb 2014 20:01:02 -0500 Subject: incorrect MonadPlus law "v >> mzero = mzero"? In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 7:59 PM, wren ng thornton wrote: > The rules I'd expect MonadPlus to obey are: > > mzero >>= f = mzero > > (x `mplus` y) >> mzero = (x >> mzero) `mplus` (y >> mzero) Er, sorry, that should've been: (x `mplus` y) >> z = (x >> z) `mplus` (y >> z) from which the above instance follows trivially. -- Live well, ~wren From jwlato at gmail.com Thu Feb 6 01:38:35 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 5 Feb 2014 17:38:35 -0800 Subject: incorrect MonadPlus law "v >> mzero = mzero"? In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 5:01 PM, wren ng thornton wrote: > On Wed, Feb 5, 2014 at 7:59 PM, wren ng thornton > wrote: > > The rules I'd expect MonadPlus to obey are: > > > > mzero >>= f = mzero > > > > (x `mplus` y) >> mzero = (x >> mzero) `mplus` (y >> mzero) > > Er, sorry, that should've been: > > (x `mplus` y) >> z = (x >> z) `mplus` (y >> z) > > from which the above instance follows trivially. I don't think this is correct. consider the original instance with x /= mzero. Then we have left side (x `mplus` y) >> mzero x >> mzero -- by def. of mplus right side (x >> mzero) `mplus` (y >> mzero) mzero'x `mplus` (y >> mzero) -- mzero'x is a zero with x's effects, this reduction comes from the monad laws (y >> mzero) -- by mplus Or concretely, > let x = lift (print "x!") :: MaybeT IO () > let y = lift (print "y!") :: MaybeT IO () > runMaybeT $ (x `mplus` y) >> mzero "x!" Nothing > runMaybeT $ (x >> mzero) `mplus` (y >> mzero) "x!" "y!" Nothing John -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Thu Feb 6 02:32:19 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Wed, 5 Feb 2014 21:32:19 -0500 Subject: incorrect MonadPlus law "v >> mzero = mzero"? In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 8:38 PM, John Lato wrote: > On Wed, Feb 5, 2014 at 5:01 PM, wren ng thornton > wrote: >> >> On Wed, Feb 5, 2014 at 7:59 PM, wren ng thornton >> wrote: >> > The rules I'd expect MonadPlus to obey are: >> > >> > mzero >>= f = mzero >> > >> > (x `mplus` y) >> mzero = (x >> mzero) `mplus` (y >> mzero) >> >> Er, sorry, that should've been: >> >> (x `mplus` y) >> z = (x >> z) `mplus` (y >> z) >> >> from which the above instance follows trivially. > > I don't think this is correct. [...] Or concretely, > >> let x = lift (print "x!") :: MaybeT IO () >> let y = lift (print "y!") :: MaybeT IO () >> runMaybeT $ (x `mplus` y) >> mzero > > "x!" > Nothing > >> runMaybeT $ (x >> mzero) `mplus` (y >> mzero) > > "x!" > "y!" > Nothing Well, notably, the Maybe part of things does agree. It's the transformer part which breaks things. However, this is something that could be "fixed" by changing the implementation of mplus for MaybeT. In particular, if we have it fully execute both arguments, but then discard the results of latter ones whenever earlier ones have succeeded. That is, mplus x y = MaybeT $ do v <- runMaybeT x w <- runMaybeT y case v of Nothing -> return w Just _ -> return v This "fix" ensures that the law is obeyed regardless of the underlying monad. However, it's not necessarily the instance we want. So the question is: for monad transformers, what --explicitly, concretely-- do we want? Do we consider the current MaybeT instance sacrosanct? What about the other popular instances? I still think the above laws are the most sensible ones. I discuss a bit about why I believe that in this blog post I just posted[1]. The only alternative I see is to drop every law about how mplus interacts with bind, which isn't a solution quite so much as giving up. [1] -- Live well, ~wren From winterkoninkje at gmail.com Thu Feb 6 03:05:29 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Wed, 5 Feb 2014 22:05:29 -0500 Subject: incorrect MonadPlus law "v >> mzero = mzero"? In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 9:32 PM, wren ng thornton wrote: > I still think the above laws are the most sensible ones. I discuss a > bit about why I believe that in this blog post I just posted[1]. The > only alternative I see is to drop every law about how mplus interacts > with bind, which isn't a solution quite so much as giving up. > > [1] I had commented in that post about how the generalization of the distributivity law could possibly lead to problems, but didn't really explore it. I just now posted an addendum showing that (for Maybe/MaybeT) it is indeed the generalization itself which causes the problems; and that, if we use the *exact* distributivity law from seminearrings[2] rather than the generalized version, then the problem goes away (for Maybe). I still submit that this is the right law to have, following the same overall justification as before. The generalized law is nice, but I wouldn't be too sad about using the non-generalized law instead. Any IO/STM examples which break the non-generalized law? [2] That is, mzero >>= f = mzero -- this one is still generalized (x `mplus` y) >> z = (x >> z) `mplus` (y >> z) -- no longer generalized (x `mplus` y) `mplus` z = x `mplus` (y `mplus` z) x `mplus` mzero = x mzero `mplus` y = y -- Live well, ~wren From jwlato at gmail.com Thu Feb 6 04:22:37 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 5 Feb 2014 20:22:37 -0800 Subject: incorrect MonadPlus law "v >> mzero = mzero"? In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 6:32 PM, wren ng thornton wrote: > On Wed, Feb 5, 2014 at 8:38 PM, John Lato wrote: > > On Wed, Feb 5, 2014 at 5:01 PM, wren ng thornton < > winterkoninkje at gmail.com> > > wrote: > >> > >> On Wed, Feb 5, 2014 at 7:59 PM, wren ng thornton > >> wrote: > >> > The rules I'd expect MonadPlus to obey are: > >> > > >> > mzero >>= f = mzero > >> > > >> > (x `mplus` y) >> mzero = (x >> mzero) `mplus` (y >> mzero) > >> > >> Er, sorry, that should've been: > >> > >> (x `mplus` y) >> z = (x >> z) `mplus` (y >> z) > >> > >> from which the above instance follows trivially. > > > > I don't think this is correct. [...] Or concretely, > > > >> let x = lift (print "x!") :: MaybeT IO () > >> let y = lift (print "y!") :: MaybeT IO () > >> runMaybeT $ (x `mplus` y) >> mzero > > > > "x!" > > Nothing > > > >> runMaybeT $ (x >> mzero) `mplus` (y >> mzero) > > > > "x!" > > "y!" > > Nothing > > Well, notably, the Maybe part of things does agree. It's the > transformer part which breaks things. However, this is something that > could be "fixed" by changing the implementation of mplus for MaybeT. > In particular, if we have it fully execute both arguments, but then > discard the results of latter ones whenever earlier ones have > succeeded. That is, > > mplus x y = MaybeT $ do > v <- runMaybeT x > w <- runMaybeT y > case v of > Nothing -> return w > Just _ -> return v > > This "fix" ensures that the law is obeyed regardless of the underlying > monad. However, it's not necessarily the instance we want. So the > question is: for monad transformers, what --explicitly, concretely-- do > we want? Do we consider the current MaybeT instance sacrosanct? What > about the other popular instances? > That instance would mean that x `mplus` y /= x, when y assumes certain zeros. This property is more important to me than the other, at least as far as MaybeT is concerned. YMMV. Personally, I'm ok with treating all zeros as equal so far as the laws are concerned. Any particular instance with multiple zeros should document how they're propagated at mplus though. Of course, if we treat zeros as equivalent, then (v >> mzero = mzero) holds ;) John > I still think the above laws are the most sensible ones. I discuss a > bit about why I believe that in this blog post I just posted[1]. The > only alternative I see is to drop every law about how mplus interacts > with bind, which isn't a solution quite so much as giving up. > > [1] > > -- > Live well, > ~wren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Feb 7 13:47:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 7 Feb 2014 08:47:36 -0500 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages References: <52F49474.8080102@gmail.com> Message-ID: Hi libraries, The message below came through Cafe. It reports a problem when emailing libraries at haskell.org, which is listed as the maintainer of several public packages. Yet, the list does not accept emails from non-subscribers. These two facts seem to be at odds, and turns people away from reporting bugs. Can we fix this? Or, do we want a separate, world-writable libraries-bugs at haskell.org? Thanks! Richard Begin forwarded message: > From: Szymon Py?alski > Subject: [Haskell-cafe] Filing bugs for haskell packages > Date: February 7, 2014 3:08:20 AM EST > To: haskell-cafe at haskell.org > > Hello! > > I am new to haskell and I found a bug in package http://hackage.haskell.org/package/regex-compat-0.92/docs/Text-Regex.html > > On the hackage page it says that the maintainer e-mail of this package is: libraries at haskell.org. So i sent a bug report there, but bounced back to me because of quota. So apparently nobody reads these e-mails. > > How can I file a bug report for this package? I don't feel good enough in haskell to try and fix it myself. > > Greetings > Szymon Py?alski > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Fri Feb 7 14:01:45 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Fri, 07 Feb 2014 14:01:45 +0000 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: References: <52F49474.8080102@gmail.com> Message-ID: <52F4E749.2070900@nh2.me> Being able to post without subscription sounds sensible. I'm subscribed to > 10 mailing lists of projects for which I report less than a bug per year because of exactly this problem, and it is very annoying. Even if you take the extra effort and go through a sign up/off for every single bug you want to report, this doesn't really work because you might miss replies in between the signed-up periods, and while you are signed up you get all the clutter from the mailing list that is unrelated to your problem. I recall other projects implementing an open-mailing-list principle (posting without subscription), and I think it works great. On 07/02/14 13:47, Richard Eisenberg wrote: > Hi libraries, > > The message below came through Cafe. It reports a problem when emailing > libraries at haskell.org , which is listed as > the maintainer of several public packages. Yet, the list does not accept > emails from non-subscribers. These two facts seem to be at odds, and > turns people away from reporting bugs. Can we fix this? Or, do we want a > separate, world-writable libraries-bugs at haskell.org > ? > > Thanks! > Richard From fuuzetsu at fuuzetsu.co.uk Fri Feb 7 14:10:56 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 07 Feb 2014 14:10:56 +0000 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <52F4E749.2070900@nh2.me> References: <52F49474.8080102@gmail.com> <52F4E749.2070900@nh2.me> Message-ID: <52F4E970.6040100@fuuzetsu.co.uk> On 07/02/14 14:01, Niklas Hamb?chen wrote: > Being able to post without subscription sounds sensible. > > I'm subscribed to > 10 mailing lists of projects for which I report less > than a bug per year because of exactly this problem, and it is very > annoying. > > Even if you take the extra effort and go through a sign up/off for every > single bug you want to report, this doesn't really work because you > might miss replies in between the signed-up periods, and while you are > signed up you get all the clutter from the mailing list that is > unrelated to your problem. > > I recall other projects implementing an open-mailing-list principle > (posting without subscription), and I think it works great. > > On 07/02/14 13:47, Richard Eisenberg wrote: >> Hi libraries, >> >> The message below came through Cafe. It reports a problem when emailing >> libraries at haskell.org , which is listed as >> the maintainer of several public packages. Yet, the list does not accept >> emails from non-subscribers. These two facts seem to be at odds, and >> turns people away from reporting bugs. Can we fix this? Or, do we want a >> separate, world-writable libraries-bugs at haskell.org >> ? >> >> Thanks! >> Richard > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > I think a separate mailing list that you can post to without subscription would be the best. Spam is always a concern but at least it'd be contained to a single list. -- Mateusz K. From nicolas at incubaid.com Fri Feb 7 14:19:31 2014 From: nicolas at incubaid.com (Nicolas Trangez) Date: Fri, 07 Feb 2014 15:19:31 +0100 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <52F4E749.2070900@nh2.me> References: <52F49474.8080102@gmail.com> <52F4E749.2070900@nh2.me> Message-ID: <1391782771.2859.37.camel@chi.nicolast.be> On Fri, 2014-02-07 at 14:01 +0000, Niklas Hamb?chen wrote: > I'm subscribed to > 10 mailing lists of projects for which I report > less > than a bug per year because of exactly this problem, and it is very > annoying. IMHO this yields a different question: is a mailing list a suitable method to report/track/discuss *bugs* discovered by end-users? Nicolas From mle+hs at mega-nerd.com Fri Feb 7 21:19:46 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 8 Feb 2014 08:19:46 +1100 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <1391782771.2859.37.camel@chi.nicolast.be> References: <52F49474.8080102@gmail.com> <52F4E749.2070900@nh2.me> <1391782771.2859.37.camel@chi.nicolast.be> Message-ID: <20140208081946.ed24903f9152bd862ce53de4@mega-nerd.com> Nicolas Trangez wrote: > On Fri, 2014-02-07 at 14:01 +0000, Niklas Hamb?chen wrote: > > I'm subscribed to > 10 mailing lists of projects for which I report > > less > > than a bug per year because of exactly this problem, and it is very > > annoying. > > IMHO this yields a different question: is a mailing list a suitable > method to report/track/discuss *bugs* discovered by end-users? +1 The libraries list has uses for discssion of library related issues but is not really a good venue for reporting bugs. We should probably use a *bug tracker* for bugs. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From haskell at nand.wakku.to Fri Feb 7 21:49:17 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Fri, 7 Feb 2014 22:49:17 +0100 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <20140208081946.ed24903f9152bd862ce53de4@mega-nerd.com> References: <52F49474.8080102@gmail.com> Message-ID: <20140207224917.GA6053@nanodesu.talocan.mine.nu> <52F4E749.2070900 at nh2.me> <1391782771.2859.37.camel at chi.nicolast.be> <20140208081946.ed24903f9152bd862ce53de4 at mega-nerd.com> > +1 > > The libraries list has uses for discssion of library related issues > but is not really a good venue for reporting bugs. We should probably > use a *bug tracker* for bugs. > > Erik +1 I'd also like to firmly request it be possible to submit bugs *without* registering first. I lost count of how many bugs I've neglected to submit just because I didn't want to go through the hassle of creating an account first. I really like a model like github's issues page, where you can at best just type a simple description of the bug. I think it's more important to enable people to make bug reports without hassle, than it is to force people to categorize them correctly etc. first. From alain.odea at gmail.com Fri Feb 7 21:54:12 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 7 Feb 2014 21:54:12 +0000 Subject: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <20140208081946.ed24903f9152bd862ce53de4@mega-nerd.com> References: <52F49474.8080102@gmail.com> <52F4E749.2070900@nh2.me> <1391782771.2859.37.camel@chi.nicolast.be> <20140208081946.ed24903f9152bd862ce53de4@mega-nerd.com> Message-ID: <603E033D-0A61-4656-86FB-25292C524626@gmail.com> > On Feb 7, 2014, at 21:19, Erik de Castro Lopo wrote: > > Nicolas Trangez wrote: > >>> On Fri, 2014-02-07 at 14:01 +0000, Niklas Hamb?chen wrote: >>> I'm subscribed to > 10 mailing lists of projects for which I report >>> less >>> than a bug per year because of exactly this problem, and it is very >>> annoying. >> >> IMHO this yields a different question: is a mailing list a suitable >> method to report/track/discuss *bugs* discovered by end-users? > > +1 > > The libraries list has uses for discssion of library related issues > but is not really a good venue for reporting bugs. We should probably > use a *bug tracker* for bugs. I'm new to reporting library issues in Haskell. It seems like the GHC Trac was the effective venue for reporting issues on platform libraries. Herbert filed the bug for me after I reported it here. It may be more effective for Hackage to link to a web page with bug reporting instructions rather than a maintainer email. It certainly reduces the burden on maintainers and provides clarity to reporters. Lowering the bar on bug reporting too far may facilitate non-constructive complaints. If there were endemic quality problems or a perception of quality problems in Haskell libraries, lowering the bar would be wise to address that. I believe that the quality of Haskell libraries and the perception of their quality generally is very high. Best, Alain From alain.odea at gmail.com Fri Feb 7 22:10:44 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 7 Feb 2014 22:10:44 +0000 Subject: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <603E033D-0A61-4656-86FB-25292C524626@gmail.com> References: <52F49474.8080102@gmail.com> <52F4E749.2070900@nh2.me> <1391782771.2859.37.camel@chi.nicolast.be> <20140208081946.ed24903f9152bd862ce53de4@mega-nerd.com> <603E033D-0A61-4656-86FB-25292C524626@gmail.com> Message-ID: <12B13905-D938-45CA-B96C-2B3EE3346162@gmail.com> > On Feb 7, 2014, at 21:54, Alain O'Dea wrote: > > > >> On Feb 7, 2014, at 21:19, Erik de Castro Lopo wrote: >> >> Nicolas Trangez wrote: >> >>>> On Fri, 2014-02-07 at 14:01 +0000, Niklas Hamb?chen wrote: >>>> I'm subscribed to > 10 mailing lists of projects for which I report >>>> less >>>> than a bug per year because of exactly this problem, and it is very >>>> annoying. >>> >>> IMHO this yields a different question: is a mailing list a suitable >>> method to report/track/discuss *bugs* discovered by end-users? >> >> +1 >> >> The libraries list has uses for discssion of library related issues >> but is not really a good venue for reporting bugs. We should probably >> use a *bug tracker* for bugs. > > It may be more effective for Hackage to link to a web page with bug reporting instructions rather than a maintainer email. ... so it is good that it actually does :D I'm in in rare form today. From mle+hs at mega-nerd.com Fri Feb 7 22:42:10 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 8 Feb 2014 09:42:10 +1100 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <20140207224917.GA6053@nanodesu.talocan.mine.nu> References: <52F49474.8080102@gmail.com> <20140207224917.GA6053@nanodesu.talocan.mine.nu> Message-ID: <20140208094210.b7e4bd660021d1b895e08ffc@mega-nerd.com> Niklas Haas wrote: > I'd also like to firmly request it be possible to submit bugs *without* > registering first. I lost count of how many bugs I've neglected to > submit just because I didn't want to go through the hassle of creating > an account first. The problem with being about to raise a ticket without creating an account is spam. Lots of it and its generated by automated tools. > I really like a model like github's issues page, where you can at best > just type a simple description of the bug. Yes, but even on github you need to be signed in. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From gershomb at gmail.com Fri Feb 7 22:59:18 2014 From: gershomb at gmail.com (Gershom Bazerman) Date: Fri, 07 Feb 2014 17:59:18 -0500 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <20140208094210.b7e4bd660021d1b895e08ffc@mega-nerd.com> References: <52F49474.8080102@gmail.com> <20140207224917.GA6053@nanodesu.talocan.mine.nu> <20140208094210.b7e4bd660021d1b895e08ffc@mega-nerd.com> Message-ID: <52F56546.70503@gmail.com> On 2/7/14, 5:42 PM, Erik de Castro Lopo wrote: > The problem with being about to raise a ticket without creating an > account is spam. Lots of it and its generated by automated tools. Agreed. Folks have no idea how much spam we filter on the various haskell infrastructure things, be they wikis or tracs or email lists. We accidentally opened the lists up to unregistered email and got a wave of spam there too, immediately. Whatever we do, it'll need to require registration, whether its sticking with libraries@ as a place to report bugs, or doing something else... --Gershom From ivan.miljenovic at gmail.com Fri Feb 7 23:03:10 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sat, 8 Feb 2014 10:03:10 +1100 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <52F56546.70503@gmail.com> References: <52F49474.8080102@gmail.com> <20140207224917.GA6053@nanodesu.talocan.mine.nu> <20140208094210.b7e4bd660021d1b895e08ffc@mega-nerd.com> <52F56546.70503@gmail.com> Message-ID: On 8 February 2014 09:59, Gershom Bazerman wrote: > On 2/7/14, 5:42 PM, Erik de Castro Lopo wrote: >> >> The problem with being about to raise a ticket without creating an account >> is spam. Lots of it and its generated by automated tools. > > Agreed. > > Folks have no idea how much spam we filter on the various haskell > infrastructure things, be they wikis or tracs or email lists. We > accidentally opened the lists up to unregistered email and got a wave of > spam there too, immediately. > > Whatever we do, it'll need to require registration, whether its sticking > with libraries@ as a place to report bugs, or doing something else... As an alternative, maybe having a "report bug" page which doesn't require registration but instead uses a CAPTCHA or something to prevent bots? > > --Gershom > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From fuuzetsu at fuuzetsu.co.uk Sat Feb 8 01:10:28 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 08 Feb 2014 01:10:28 +0000 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: References: <52F49474.8080102@gmail.com> <20140207224917.GA6053@nanodesu.talocan.mine.nu> <20140208094210.b7e4bd660021d1b895e08ffc@mega-nerd.com> <52F56546.70503@gmail.com> Message-ID: <52F58404.4050807@fuuzetsu.co.uk> On 07/02/14 23:03, Ivan Lazar Miljenovic wrote: > On 8 February 2014 09:59, Gershom Bazerman wrote: >> On 2/7/14, 5:42 PM, Erik de Castro Lopo wrote: >>> >>> The problem with being about to raise a ticket without creating an account >>> is spam. Lots of it and its generated by automated tools. >> >> Agreed. >> >> Folks have no idea how much spam we filter on the various haskell >> infrastructure things, be they wikis or tracs or email lists. We >> accidentally opened the lists up to unregistered email and got a wave of >> spam there too, immediately. >> >> Whatever we do, it'll need to require registration, whether its sticking >> with libraries@ as a place to report bugs, or doing something else... > > As an alternative, maybe having a "report bug" page which doesn't > require registration but instead uses a CAPTCHA or something to > prevent bots? > >> >> --Gershom >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > > The problem with this approach is that there's only one way communication: someone fills in the form and relevant people get notified. If it's something simple, great, that can just be fixed. What happens if you need more information? You'd have to require the user to input contact information. Assume you do. What next? If you send them an e-mail, only you and they will see it: there's no public forum where more than one maintainer (or anyone that wants to) can pitch in and ask questions. At best you can forward the user's replies to a bigger audience but there's no way to go the other way around. In the end, to communicate with the user past the initial report, it's vital that the user can be reached somewhere where all interested parties can have a look at and communicate with each other. I think it's clear that there's a need for something with persistent communication channel, like an issue tracker. I think the best thing that can be done is to make the registration process easy: pop in your e-mail, solve captcha/verify e-mail and you're good. I think that requiring an account on an issue tracker is not too much. Requiring a subscription to a mailing list where all the communication gets sent to everyone _is_ too much and I think it's the only problem that needs working on here. -- Mateusz K. From schlepptop at henning-thielemann.de Sat Feb 8 10:51:13 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat, 08 Feb 2014 11:51:13 +0100 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <52F58404.4050807@fuuzetsu.co.uk> References: <52F49474.8080102@gmail.com> <20140207224917.GA6053@nanodesu.talocan.mine.nu> <20140208094210.b7e4bd660021d1b895e08ffc@mega-nerd.com> <52F56546.70503@gmail.com> <52F58404.4050807@fuuzetsu.co.uk> Message-ID: <52F60C21.1000106@henning-thielemann.de> Am 08.02.2014 02:10, schrieb Mateusz Kowalczyk: > I think it's clear that there's a need for something with persistent > communication channel, like an issue tracker. I think the best thing > that can be done is to make the registration process easy: pop in your > e-mail, solve captcha/verify e-mail and you're good. I think that > requiring an account on an issue tracker is not too much. It is too much, since it requires (preferably) a new password that store safely and change frequently, as adviced by security experts. I guess a simple question like "what is Haskell's surname?" should keep the bots out. From ganesh at earth.li Sat Feb 8 16:29:57 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat, 08 Feb 2014 16:29:57 +0000 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <52F4E749.2070900@nh2.me> References: <52F49474.8080102@gmail.com> <52F4E749.2070900@nh2.me> Message-ID: <52F65B85.6080001@earth.li> For what it's worth, I did exactly this for the http at projects.haskell.org list which is listed as the maintainer in the cabal file, and the list is overwhelmed by spam. Some subscribers even get bounced off it by mailman every so often because their own spam filtering is better than the pre-list filtering, and so they bounce enough of the messages that mailman sends them to trigger the "broken email address" check. I'm vaguely planning on giving up and going back to having myself only listed as maintainer as a result. I definitely wouldn't want people to have to subscribe to email the maintainer address though. On 07/02/2014 14:01, Niklas Hamb?chen wrote: > Being able to post without subscription sounds sensible. > > I'm subscribed to > 10 mailing lists of projects for which I report less > than a bug per year because of exactly this problem, and it is very > annoying. > > Even if you take the extra effort and go through a sign up/off for every > single bug you want to report, this doesn't really work because you > might miss replies in between the signed-up periods, and while you are > signed up you get all the clutter from the mailing list that is > unrelated to your problem. > > I recall other projects implementing an open-mailing-list principle > (posting without subscription), and I think it works great. > > On 07/02/14 13:47, Richard Eisenberg wrote: >> Hi libraries, >> >> The message below came through Cafe. It reports a problem when emailing >> libraries at haskell.org , which is listed as >> the maintainer of several public packages. Yet, the list does not accept >> emails from non-subscribers. These two facts seem to be at odds, and >> turns people away from reporting bugs. Can we fix this? Or, do we want a >> separate, world-writable libraries-bugs at haskell.org >> ? >> >> Thanks! >> Richard > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From bart at cs.pdx.edu Sat Feb 8 16:53:03 2014 From: bart at cs.pdx.edu (Bart Massey) Date: Sat, 8 Feb 2014 08:53:03 -0800 Subject: Fwd: [Haskell-cafe] Filing bugs for haskell packages In-Reply-To: <52F65B85.6080001@earth.li> References: <52F49474.8080102@gmail.com> <52F4E749.2070900@nh2.me> <52F65B85.6080001@earth.li> Message-ID: It is possible to set things up so that users can authenticate using an existing account on Facebook, GitHub, Google, etc. Not sure how much better this is than from-scratch registration, or how spam-proof it is, but more and more sites seem to be giving it a go. It at least amortizes password creation and maintenance. I think some kind of registration is a pretty low bar for reporting bugs. I do it all the time for various projects, and it's kind of expected if you're going to use a bug tracker. --Bart On Sat, Feb 8, 2014 at 8:29 AM, Ganesh Sittampalam wrote: > For what it's worth, I did exactly this for the > http at projects.haskell.org list which is listed as the maintainer in the > cabal file, and the list is overwhelmed by spam. > > Some subscribers even get bounced off it by mailman every so often > because their own spam filtering is better than the pre-list filtering, > and so they bounce enough of the messages that mailman sends them to > trigger the "broken email address" check. > > I'm vaguely planning on giving up and going back to having myself only > listed as maintainer as a result. I definitely wouldn't want people to > have to subscribe to email the maintainer address though. > > On 07/02/2014 14:01, Niklas Hamb?chen wrote: >> Being able to post without subscription sounds sensible. >> >> I'm subscribed to > 10 mailing lists of projects for which I report less >> than a bug per year because of exactly this problem, and it is very >> annoying. >> >> Even if you take the extra effort and go through a sign up/off for every >> single bug you want to report, this doesn't really work because you >> might miss replies in between the signed-up periods, and while you are >> signed up you get all the clutter from the mailing list that is >> unrelated to your problem. >> >> I recall other projects implementing an open-mailing-list principle >> (posting without subscription), and I think it works great. >> >> On 07/02/14 13:47, Richard Eisenberg wrote: >>> Hi libraries, >>> >>> The message below came through Cafe. It reports a problem when emailing >>> libraries at haskell.org , which is listed as >>> the maintainer of several public packages. Yet, the list does not accept >>> emails from non-subscribers. These two facts seem to be at odds, and >>> turns people away from reporting bugs. Can we fix this? Or, do we want a >>> separate, world-writable libraries-bugs at haskell.org >>> ? >>> >>> Thanks! >>> Richard >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From bernardy at chalmers.se Tue Feb 11 19:15:20 2014 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Tue, 11 Feb 2014 20:15:20 +0100 Subject: Maintainership of dvi-processing Message-ID: Hello, I wish for the dependencies of package dvi-processing to be updated to current versions. The listed maintainer ("AaronBlack") appears to be unsearchable on the internet (no mention on the name can be found in connection to the Haskell language, except has maintainer on Hackage). Hackage does not seem to want to reveal an email address either. Hence I propose to take over maintainership of the package. I beg the powers that be to let me know if this would be possible, and if so when it can happen. Many anticipated thanks, JP Bernardy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Tue Feb 11 19:33:59 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Tue, 11 Feb 2014 14:33:59 -0500 Subject: Maintainership of dvi-processing In-Reply-To: References: Message-ID: <87txc5qw9k.fsf@gmail.com> Jean-Philippe Bernardy writes: > Hello, > > I wish for the dependencies of package dvi-processing to be updated to > current versions. The listed maintainer ("AaronBlack") appears to be > unsearchable on the internet (no mention on the name can be found in > connection to the Haskell language, except has maintainer on Hackage). > Hackage does not seem to want to reveal an email address either. > On this note, it seems that this package has never had an Author: tag. It seems to me that this should be a prerequisite for upload to package and as such `cabal check` should check for this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From fuuzetsu at fuuzetsu.co.uk Tue Feb 11 20:38:26 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 11 Feb 2014 20:38:26 +0000 Subject: Maintainership of dvi-processing In-Reply-To: <87txc5qw9k.fsf@gmail.com> References: <87txc5qw9k.fsf@gmail.com> Message-ID: <52FA8A42.2030102@fuuzetsu.co.uk> On 11/02/14 19:33, Ben Gamari wrote: > Jean-Philippe Bernardy writes: > >> Hello, >> >> I wish for the dependencies of package dvi-processing to be updated to >> current versions. The listed maintainer ("AaronBlack") appears to be >> unsearchable on the internet (no mention on the name can be found in >> connection to the Haskell language, except has maintainer on Hackage). >> Hackage does not seem to want to reveal an email address either. >> > On this note, it seems that this package has never had an Author: > tag. It seems to me that this should be a prerequisite for upload to > package and as such `cabal check` should check for this. > > Cheers, > > - Ben > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > Does cabal check work at the moment? If I try to use it, I get a 404 error in my terminal. -- Mateusz K. From bgamari.foss at gmail.com Tue Feb 11 21:08:43 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Tue, 11 Feb 2014 16:08:43 -0500 Subject: Maintainership of dvi-processing In-Reply-To: <52FA8A42.2030102@fuuzetsu.co.uk> References: <87txc5qw9k.fsf@gmail.com> <52FA8A42.2030102@fuuzetsu.co.uk> Message-ID: <87r479qrvo.fsf@gmail.com> Mateusz Kowalczyk writes: > > Does cabal check work at the moment? If I try to use it, I get a 404 > error in my terminal. > Works for me but I must say I may be a bit ahead of the curve in my Cabal version, $ cabal -V cabal-install version 1.19.2 using version 1.19.2 of the Cabal library -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From abela at chalmers.se Wed Feb 12 01:21:42 2014 From: abela at chalmers.se (Andreas Abel) Date: Wed, 12 Feb 2014 02:21:42 +0100 Subject: Maintainership of dvi-processing In-Reply-To: References: Message-ID: <52FACCA6.2090609@chalmers.se> Upload date Sat Jul 7 01:10:36 UTC 2012 Don't listen to the devil, but you can do a pirate upload (at least that was possible on old hackage). In case the original author rises from his coffin you can always hand author/maintainership back. On 11.02.2014 20:15, Jean-Philippe Bernardy wrote: > Hello, > > I wish for the dependencies of package dvi-processing to be updated to > current versions. The listed maintainer ("AaronBlack") appears to be > unsearchable on the internet (no mention on the name can be found in > connection to the Haskell language, except has maintainer on Hackage). > Hackage does not seem to want to reveal an email address either. > > Hence I propose to take over maintainership of the package. I beg the > powers that be to let me know if this would be possible, and if so when > it can happen. > > Many anticipated thanks, > JP Bernardy. -- Andreas Abel <>< Du bist der geliebte Mensch. Depeartment of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From ekmett at gmail.com Wed Feb 12 04:01:25 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 11 Feb 2014 23:01:25 -0500 Subject: Maintainership of dvi-processing In-Reply-To: <52FACCA6.2090609@chalmers.se> References: <52FACCA6.2090609@chalmers.se> Message-ID: Nowadays to do that you'd need someone like Austin to go hack up the maintainers list for the package and add you. -Edward On Tue, Feb 11, 2014 at 8:21 PM, Andreas Abel wrote: > Upload date Sat Jul 7 01:10:36 UTC 2012 > > Don't listen to the devil, but you can do a pirate upload (at least that > was possible on old hackage). In case the original author rises from his > coffin you can always hand author/maintainership back. > > > On 11.02.2014 20:15, Jean-Philippe Bernardy wrote: > >> Hello, >> >> I wish for the dependencies of package dvi-processing to be updated to >> current versions. The listed maintainer ("AaronBlack") appears to be >> unsearchable on the internet (no mention on the name can be found in >> connection to the Haskell language, except has maintainer on Hackage). >> Hackage does not seem to want to reveal an email address either. >> >> Hence I propose to take over maintainership of the package. I beg the >> powers that be to let me know if this would be possible, and if so when >> it can happen. >> >> Many anticipated thanks, >> JP Bernardy. >> > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Depeartment of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www2.tcs.ifi.lmu.de/~abel/ > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From difrumin at gmail.com Wed Feb 12 06:33:57 2014 From: difrumin at gmail.com (Daniil Frumin) Date: Wed, 12 Feb 2014 10:33:57 +0400 Subject: Maintainership of dvi-processing In-Reply-To: References: Message-ID: This is very similar to a situation that was discussed earlier on Cafe. I think you should be given (at least temporal) maintainership to upload a new version of the package given that the package is currently un maintained >> On 11 Feb 2014, at 23:15, Jean-Philippe Bernardy wrote: >> >> Hello, >> >> I wish for the dependencies of package dvi-processing to be updated to current versions. The listed maintainer ("AaronBlack") appears to be unsearchable on the internet (no mention on the name can be found in connection to the Haskell language, except has maintainer on Hackage). Hackage does not seem to want to reveal an email address either. >> >> Hence I propose to take over maintainership of the package. I beg the powers that be to let me know if this would be possible, and if so when it can happen. >> >> Many anticipated thanks, >> JP Bernardy. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries -- Sincerely yours, -- Daniil From fa-ml at ariis.it Wed Feb 12 07:33:14 2014 From: fa-ml at ariis.it (fa-ml) Date: Wed, 12 Feb 2014 08:33:14 +0100 Subject: cabal and extra-libs Message-ID: <20140212073314.GA29603@x60s.casa> Hello list, recently I am having trouble installing a package (hbro, more info here [1]). Today I decided to remove every 0mq installed (even system ones) and run another installation to see what went wrong. So I downloaded zmq3, reinstalled it, tried to run cabal install hnro which lead to Loading package zeromq3-haskell-0.5.1 ... : can't load .so/.DLL for: libzmq.so (libzmq.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: After locating libzmq.so, I typed cabal install hbro --extra-lib-dirs=/home/user/media/vcs/zeromq-3.2.4/src/.libs/ This unfortunately was greeted with the same error, which makes me question wheter I am invoking cabal with the right parameters/wheter cabal actually looks inside that directory. Cabal version: cabal-install version 0.14.0 using version 1.14.0 of the Cabal library # I use debian/wheezy Am I incorrectly calling cabal or is this a bug? -F [1] http://www.haskell.org/pipermail/beginners/2014-February/013152.html From schlepptop at henning-thielemann.de Wed Feb 12 09:29:16 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed, 12 Feb 2014 10:29:16 +0100 Subject: pkg-config for zeromq (Was: cabal and extra-libs) In-Reply-To: <20140212073314.GA29603@x60s.casa> References: <20140212073314.GA29603@x60s.casa> Message-ID: <52FB3EEC.7090900@henning-thielemann.de> Am 12.02.2014 08:33, schrieb fa-ml: > Hello list, > > recently I am having trouble installing a package (hbro, > more info here [1]). > Today I decided to remove every 0mq installed (even system ones) > and run another installation to see what went wrong. > So I downloaded zmq3, reinstalled it, tried to run > > cabal install hnro Since zeromq seems to have a pkg-config file https://www.archlinux.org/packages/community/i686/zeromq/files/ I'd strongly suggest the package maintainer of zeromq3-haskell to use the PkgConfig-depends field of Cabal instead of the custom extralibs. From tw at dtex.org Wed Feb 12 19:48:50 2014 From: tw at dtex.org (Toralf Wittner) Date: Wed, 12 Feb 2014 20:48:50 +0100 Subject: pkg-config for zeromq (Was: cabal and extra-libs) In-Reply-To: <52FB3EEC.7090900@henning-thielemann.de> References: <20140212073314.GA29603@x60s.casa> <52FB3EEC.7090900@henning-thielemann.de> Message-ID: <52FBD022.9080008@dtex.org> On 12/02/14 10:29, Henning Thielemann wrote: > Am 12.02.2014 08:33, schrieb fa-ml: >> Hello list, >> >> recently I am having trouble installing a package (hbro, >> more info here [1]). >> Today I decided to remove every 0mq installed (even system ones) >> and run another installation to see what went wrong. >> So I downloaded zmq3, reinstalled it, tried to run >> >> cabal install hnro > > Since zeromq seems to have a pkg-config file > > https://www.archlinux.org/packages/community/i686/zeromq/files/ > > I'd strongly suggest the package maintainer of zeromq3-haskell to use > the PkgConfig-depends field of Cabal instead of the custom extralibs. > Thanks for your suggestion. I have pushed new versions to hackage which use pkgconfig-depends. From fa-ml at ariis.it Thu Feb 13 04:47:49 2014 From: fa-ml at ariis.it (fa-ml) Date: Thu, 13 Feb 2014 05:47:49 +0100 Subject: pkg-config for zeromq (Was: cabal and extra-libs) In-Reply-To: <52FBD022.9080008@dtex.org> References: <20140212073314.GA29603@x60s.casa> <52FB3EEC.7090900@henning-thielemann.de> <52FBD022.9080008@dtex.org> Message-ID: <20140213044749.GA19692@x60s.casa> On Wed, Feb 12, 2014 at 08:48:50PM +0100, Toralf Wittner wrote: > On 12/02/14 10:29, Henning Thielemann wrote: > >I'd strongly suggest the package maintainer of zeromq3-haskell to use > >the PkgConfig-depends field of Cabal instead of the custom extralibs. > > > > Thanks for your suggestion. I have pushed new versions to hackage > which use pkgconfig-depends. That did the trick, than you both From carter.schonwald at gmail.com Thu Feb 13 06:15:10 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 13 Feb 2014 01:15:10 -0500 Subject: Taking over maintenance of posix-realtime? In-Reply-To: <52FC6085.6020707@gmail.com> References: <52FC6085.6020707@gmail.com> Message-ID: ccing libraries list :) -Carter On Thu, Feb 13, 2014 at 1:04 AM, Michal J. Gajda wrote: > Dear Package Trustees, > > The posix-realtime-0.0.0.1 has been uploaded in 2008, and it doesn't > work with current GHC 7.6.3. > I managed to make it compile (see http://github.com/mgajda/posix-realtime > ). > I got permission from Vasili (original developer) to take over maintenance. > Could you please make me a member of maintainer group on Hackage? > (Currently it is libraries at ... but nobody seems to take responsibility. > I assume libraries at ... is a placeholder for "No real maintainer, so > maybe somebody else does it" then.) > > Or just change maintainer group to me, since obviously nobody else > seemed to show interest in the package so far? > -- > Best regards > Michal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 14 08:10:48 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 14 Feb 2014 03:10:48 -0500 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed Message-ID: Hey all, someone needs to help take over language C maintainer ship, because its going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue) I know Anthony and Jason have at points patched language-c for their respective needs, so i'm cc'ing em :) -Carter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at skybluetrades.net Fri Feb 14 08:27:29 2014 From: ian at skybluetrades.net (Ian Ross) Date: Fri, 14 Feb 2014 09:27:29 +0100 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: Benedikt Huber is maintaining language-c -- he's pushed minor changes to the darcs repo recently, so I'm guessing he could also make a new release. I'd be happy to take over maintainership of language-c (I'm doing some things to c2hs and language-c is one of the main dependencies of that), though on the understanding that it would just be for minor maintenance tasks. There is a broader question about language-c ( https://github.com/haskell/c2hs/issues/57#issuecomment-27450437): there have been various requests to support the most recent C standard as well as C99, which would be a big job, but Geoffrey Mainland has another package ( http://hackage.haskell.org/package/language-c-quote) that supports the latest standards, although with less analysis than language-c and probably less extensively tested than language-c (just because it's newer). Manuel has suggested that merging the two efforts would be a good idea. I don't know how keen Geoffrey would be on that, I don't know how much work it would be, and I don't know how much work it would be to update the reverse dependencies of the two existing packages (language-c has 13, language-c-quote has 2) to use a new merged package. If we could get some agreement on a way forward, I'd be open to working on producing a merged language-c and updating c2hs to use the new merged version as a test case. (Of course, I don't want to do this in a way that results in a third C language package that needs to be supported!) Cheers, Ian. On 14 February 2014 09:10, Carter Schonwald wrote: > Hey all, > someone needs to help take over language C maintainer ship, because its > going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ > alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an > example issue) > > I know Anthony and Jason have at points patched language-c for their > respective needs, so i'm cc'ing em :) > > -Carter > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -- Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net www.skybluetrades.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From difrumin at gmail.com Fri Feb 14 13:02:57 2014 From: difrumin at gmail.com (Daniil Frumin) Date: Fri, 14 Feb 2014 17:02:57 +0400 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: > turns out that when the maintainer person does sdist, happy / alex are run locally by cabal somehow Wow, how is that even possible? Where does it get alex/happy from? :O On Fri, Feb 14, 2014 at 12:10 PM, Carter Schonwald wrote: > Hey all, > someone needs to help take over language C maintainer ship, because its > going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ > alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an > example issue) > > I know Anthony and Jason have at points patched language-c for their > respective needs, so i'm cc'ing em :) > > -Carter > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Sincerely yours, -- Daniil From roma at ro-che.info Fri Feb 14 13:18:54 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 14 Feb 2014 15:18:54 +0200 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: <20140214131854.GA7997@sniper> That's right, cabal "caches" alex/happy output in the tarball, so that users who build the package don't need to have alex/happy installed. Check yourself: % curl http://hackage.haskell.org/package/language-c-0.4.2/language-c-0.4.2.tar.gz | tar tzf - | grep dist So all maintainers of packages that use happy and/or alex have to reupload the package with a version sdist'ed on a system with the latest alex/happy to make it buildable with GHC 7.8. Roman * Daniil Frumin [2014-02-14 17:02:57+0400] > > turns out that when the maintainer person does sdist, happy / alex are run locally by cabal somehow > > Wow, how is that even possible? Where does it get alex/happy from? :O > > On Fri, Feb 14, 2014 at 12:10 PM, Carter Schonwald > wrote: > > Hey all, > > someone needs to help take over language C maintainer ship, because its > > going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ > > alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an > > example issue) > > > > I know Anthony and Jason have at points patched language-c for their > > respective needs, so i'm cc'ing em :) > > > > -Carter > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > -- > Sincerely yours, > -- Daniil > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From difrumin at gmail.com Fri Feb 14 13:59:25 2014 From: difrumin at gmail.com (Daniil Frumin) Date: Fri, 14 Feb 2014 17:59:25 +0400 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: <20140214131854.GA7997@sniper> References: <20140214131854.GA7997@sniper> Message-ID: But the users still need to have alex and happy libraries installed, do not they? On Fri, Feb 14, 2014 at 5:18 PM, Roman Cheplyaka wrote: > That's right, cabal "caches" alex/happy output in the tarball, so that > users who build the package don't need to have alex/happy installed. > Check yourself: > > % curl http://hackage.haskell.org/package/language-c-0.4.2/language-c-0.4.2.tar.gz | tar tzf - | grep dist > > So all maintainers of packages that use happy and/or alex have to > reupload the package with a version sdist'ed on a system with the latest > alex/happy to make it buildable with GHC 7.8. > > Roman > > * Daniil Frumin [2014-02-14 17:02:57+0400] >> > turns out that when the maintainer person does sdist, happy / alex are run locally by cabal somehow >> >> Wow, how is that even possible? Where does it get alex/happy from? :O >> >> On Fri, Feb 14, 2014 at 12:10 PM, Carter Schonwald >> wrote: >> > Hey all, >> > someone needs to help take over language C maintainer ship, because its >> > going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ >> > alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an >> > example issue) >> > >> > I know Anthony and Jason have at points patched language-c for their >> > respective needs, so i'm cc'ing em :) >> > >> > -Carter >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://www.haskell.org/mailman/listinfo/libraries >> > >> >> >> >> -- >> Sincerely yours, >> -- Daniil >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries -- Sincerely yours, -- Daniil From allbery.b at gmail.com Fri Feb 14 15:30:53 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 14 Feb 2014 10:30:53 -0500 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: <20140214131854.GA7997@sniper> Message-ID: On Fri, Feb 14, 2014 at 8:59 AM, Daniil Frumin wrote: > But the users still need to have alex and happy libraries installed, > do not they? They somewhat infamously do not have libraries. (Infamously because this means nothing registered with ghc-pkg, so cabal can't tell if they're installed or not.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Fri Feb 14 15:38:00 2014 From: mainland at apeiron.net (Geoffrey Mainland) Date: Fri, 14 Feb 2014 10:38:00 -0500 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: <52FE3858.7020804@apeiron.net> I'm interested in merging language-c and language-c-quote, but I don't really have time to work on it at the moment. The two issues are performance and functionality; it is not clear to me what would need to be added to language-c-quote to make it as functional as language-c, and I don't know how much worse language-c-quote performs. Regardless, I think the chances of making language-c-quote API compatible with language-c are approximately nil. Geoff On 02/14/2014 03:27 AM, Ian Ross wrote: > Benedikt Huber is maintaining language-c -- he's pushed minor changes > to the darcs repo recently, so I'm guessing he could also make a new > release. I'd be happy to take over maintainership of language-c (I'm > doing some things to c2hs and language-c is one of the main > dependencies of that), though on the understanding that it would just > be for minor maintenance tasks. > > There is a broader question about language-c > (https://github.com/haskell/c2hs/issues/57#issuecomment-27450437): > there have been various requests to support the most recent C standard > as well as C99, which would be a big job, but Geoffrey Mainland has > another package (http://hackage.haskell.org/package/language-c-quote) > that supports the latest standards, although with less analysis than > language-c and probably less extensively tested than language-c (just > because it's newer). Manuel has suggested that merging the two > efforts would be a good idea. I don't know how keen Geoffrey would be > on that, I don't know how much work it would be, and I don't know how > much work it would be to update the reverse dependencies of the two > existing packages (language-c has 13, language-c-quote has 2) to use a > new merged package. > > If we could get some agreement on a way forward, I'd be open to > working on producing a merged language-c and updating c2hs to use the > new merged version as a test case. (Of course, I don't want to do > this in a way that results in a third C language package that needs to > be supported!) > > Cheers, > > Ian. > > > > On 14 February 2014 09:10, Carter Schonwald > > wrote: > > Hey all, > someone needs to help take over language C maintainer ship, > because its going to be broken on 7.8 unless someone pushes a > sdist'd with a new happy/ alex to hackage (see > https://github.com/haskell/c2hs/issues/64 for an example issue) > > I know Anthony and Jason have at points patched language-c for > their respective needs, so i'm cc'ing em :) > > -Carter > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > > -- > Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net > www.skybluetrades.net > From acowley at seas.upenn.edu Fri Feb 14 16:38:02 2014 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Fri, 14 Feb 2014 11:38:02 -0500 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: On Friday, February 14, 2014, Carter Schonwald wrote: > Hey all, > someone needs to help take over language C maintainer ship, because its > going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ > alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an > example issue) > > I know Anthony and Jason have at points patched language-c for their > respective needs, so i'm cc'ing em :) > > -Carter > To clarify the situation for anyone who wants to take up the language-c mantle, I have a fork at https://github.com/acowley/language-c that lets one use c2hs on OS X Mavericks, in particular for OpenCL and OpenGL. You will probably find evidence of me reporting and talking about this issue in various places; I never got any response from anyone, but sensed a healthy amount of Won't Fix in the air. A more popular fix has been to #define hacks for individual package build systems, but this is crazy as it means the hack has to be replicated everywhere. If c2hs is absolutely necessary, then its use of language-c should be reconsidered. All I did was hack the language-c parser to be more liberal in the attributes it accepts. I have no reason to believe that my changes are correct, but it is apparent that nobody is using these parse results: we just need the parser to not error out. TL;DR: Long term, language-c should have a stripped down mode of operation that better fits c2hs's needs. Short term, my language-c fork seems to work on OS X, but I haven't tested much elsewhere. Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Fri Feb 14 18:06:22 2014 From: jwlato at gmail.com (John Lato) Date: Fri, 14 Feb 2014 10:06:22 -0800 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: On Feb 14, 2014 8:38 AM, "Anthony Cowley" wrote: > > On Friday, February 14, 2014, Carter Schonwald wrote: >> >> Hey all, >> someone needs to help take over language C maintainer ship, because its going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue) >> >> I know Anthony and Jason have at points patched language-c for their respective needs, so i'm cc'ing em :) >> >> -Carter > > > To clarify the situation for anyone who wants to take up the language-c mantle, I have a fork at https://github.com/acowley/language-c that lets one use c2hs on OS X Mavericks, in particular for OpenCL and OpenGL. You will probably find evidence of me reporting and talking about this issue in various places; I never got any response from anyone, but sensed a healthy amount of Won't Fix in the air. > > A more popular fix has been to #define hacks for individual package build systems, but this is crazy as it means the hack has to be replicated everywhere. If c2hs is absolutely necessary, then its use of language-c should be reconsidered. All I did was hack the language-c parser to be more liberal in the attributes it accepts. I have no reason to believe that my changes are correct, but it is apparent that nobody is using these parse results: we just need the parser to not error out. > > TL;DR: Long term, language-c should have a stripped down mode of operation that better fits c2hs's needs. Short term, my language-c fork seems to work on OS X, but I haven't tested much elsewhere. Another option is language-objective-c, which started as a fork of language-c, supports nearly everything language-c does, and I'm still actively maintaining it. Unfortunately I don't have the resources to test it on newer osx versions, so I'd appreciate if somebody else could give it a try (I'll need to push a new version for 7.8 though). John L -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagitj at gmail.com Fri Feb 14 19:36:30 2014 From: dagitj at gmail.com (Jason Dagit) Date: Fri, 14 Feb 2014 11:36:30 -0800 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: On Fri, Feb 14, 2014 at 12:10 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Hey all, > someone needs to help take over language C maintainer ship, because its > going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ > alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an > example issue) > > I know Anthony and Jason have at points patched language-c for their > respective needs, so i'm cc'ing em :) > I made some changes to language-c-quote in the past, but Geoffrey has made all of those improvements (and more! Thanks!) since then so I no longer do that. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at cse.unsw.edu.au Sat Feb 15 03:48:51 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat, 15 Feb 2014 14:48:51 +1100 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: <52FE3858.7020804@apeiron.net> References: <52FE3858.7020804@apeiron.net> Message-ID: <9B5E1510-3328-4C4F-9C93-305F4F3093D6@cse.unsw.edu.au> As far as functionality goes, I think, the simplest approach would be to use the language-c-quote parser inside language-c ? i.e., parse with language-c-quote, and then, convert the language-c-quote AST to the language-c AST. This is as language-c contains quite a bit of functionality to analyse the C AST and c2hs needs that functionality. Rewriting it all in terms of the language-c-quote AST (which is quite different) would be a lot of (and pretty boring) work. Writing an AST to AST conversion should be quite straight forward and much less work. Concerning performance, I assume that the main difference is that language-c uses ?ByteString?s whereas language-c-quote uses ?String?s for parsing. Using ?ByteString? in language-c-quote would be a good move anyway and shouldn?t be much work. (It?s also something, I might be able to help with.) Manuel Geoffrey Mainland : > I'm interested in merging language-c and language-c-quote, but I don't > really have time to work on it at the moment. The two issues are > performance and functionality; it is not clear to me what would need to > be added to language-c-quote to make it as functional as language-c, and > I don't know how much worse language-c-quote performs. Regardless, I > think the chances of making language-c-quote API compatible with > language-c are approximately nil. > > Geoff > > On 02/14/2014 03:27 AM, Ian Ross wrote: >> Benedikt Huber is maintaining language-c -- he's pushed minor changes >> to the darcs repo recently, so I'm guessing he could also make a new >> release. I'd be happy to take over maintainership of language-c (I'm >> doing some things to c2hs and language-c is one of the main >> dependencies of that), though on the understanding that it would just >> be for minor maintenance tasks. >> >> There is a broader question about language-c >> (https://github.com/haskell/c2hs/issues/57#issuecomment-27450437): >> there have been various requests to support the most recent C standard >> as well as C99, which would be a big job, but Geoffrey Mainland has >> another package (http://hackage.haskell.org/package/language-c-quote) >> that supports the latest standards, although with less analysis than >> language-c and probably less extensively tested than language-c (just >> because it's newer). Manuel has suggested that merging the two >> efforts would be a good idea. I don't know how keen Geoffrey would be >> on that, I don't know how much work it would be, and I don't know how >> much work it would be to update the reverse dependencies of the two >> existing packages (language-c has 13, language-c-quote has 2) to use a >> new merged package. >> >> If we could get some agreement on a way forward, I'd be open to >> working on producing a merged language-c and updating c2hs to use the >> new merged version as a test case. (Of course, I don't want to do >> this in a way that results in a third C language package that needs to >> be supported!) >> >> Cheers, >> >> Ian. >> >> >> >> On 14 February 2014 09:10, Carter Schonwald >> > wrote: >> >> Hey all, >> someone needs to help take over language C maintainer ship, >> because its going to be broken on 7.8 unless someone pushes a >> sdist'd with a new happy/ alex to hackage (see >> https://github.com/haskell/c2hs/issues/64 for an example issue) >> >> I know Anthony and Jason have at points patched language-c for >> their respective needs, so i'm cc'ing em :) >> >> -Carter >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> >> >> >> -- >> Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net >> www.skybluetrades.net >> From chak at cse.unsw.edu.au Sat Feb 15 03:49:59 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat, 15 Feb 2014 14:49:59 +1100 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: John, You may be aware of this already, but I did at support for Objective-C to language-c-quote. Manuel John Lato : > On Feb 14, 2014 8:38 AM, "Anthony Cowley" wrote: > > > > On Friday, February 14, 2014, Carter Schonwald wrote: > >> > >> Hey all, > >> someone needs to help take over language C maintainer ship, because its going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue) > >> > >> I know Anthony and Jason have at points patched language-c for their respective needs, so i'm cc'ing em :) > >> > >> -Carter > > > > > > To clarify the situation for anyone who wants to take up the language-c mantle, I have a fork at https://github.com/acowley/language-c that lets one use c2hs on OS X Mavericks, in particular for OpenCL and OpenGL. You will probably find evidence of me reporting and talking about this issue in various places; I never got any response from anyone, but sensed a healthy amount of Won't Fix in the air. > > > > A more popular fix has been to #define hacks for individual package build systems, but this is crazy as it means the hack has to be replicated everywhere. If c2hs is absolutely necessary, then its use of language-c should be reconsidered. All I did was hack the language-c parser to be more liberal in the attributes it accepts. I have no reason to believe that my changes are correct, but it is apparent that nobody is using these parse results: we just need the parser to not error out. > > > > TL;DR: Long term, language-c should have a stripped down mode of operation that better fits c2hs's needs. Short term, my language-c fork seems to work on OS X, but I haven't tested much elsewhere. > > Another option is language-objective-c, which started as a fork of language-c, supports nearly everything language-c does, and I'm still actively maintaining it. Unfortunately I don't have the resources to test it on newer osx versions, so I'd appreciate if somebody else could give it a try (I'll need to push a new version for 7.8 though). > > John L > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Sat Feb 15 20:55:18 2014 From: jwlato at gmail.com (John Lato) Date: Sat, 15 Feb 2014 12:55:18 -0800 Subject: who's maintaining language-c? tis borken on hackage with 7.8 till a new version is pushed In-Reply-To: References: Message-ID: Manuel, Yes I am aware of that. But iirc there was some functionality I wanted that was not in language-c-quote (probably related to headers? ) But that was a while ago, so it may work now. I no longer do much work on osx though, so it's a low priority for me. Cheers, John On Feb 14, 2014 7:49 PM, "Manuel M T Chakravarty" wrote: > John, > > You may be aware of this already, but I did at support for Objective-C to > language-c-quote. > > Manuel > > > John Lato : > > On Feb 14, 2014 8:38 AM, "Anthony Cowley" wrote: > > > > On Friday, February 14, 2014, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> > >> Hey all, > >> someone needs to help take over language C maintainer ship, because its > going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ > alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an > example issue) > >> > >> I know Anthony and Jason have at points patched language-c for their > respective needs, so i'm cc'ing em :) > >> > >> -Carter > > > > > > To clarify the situation for anyone who wants to take up the language-c > mantle, I have a fork at https://github.com/acowley/language-c that lets > one use c2hs on OS X Mavericks, in particular for OpenCL and OpenGL. You > will probably find evidence of me reporting and talking about this issue in > various places; I never got any response from anyone, but sensed a healthy > amount of Won't Fix in the air. > > > > A more popular fix has been to #define hacks for individual package > build systems, but this is crazy as it means the hack has to be replicated > everywhere. If c2hs is absolutely necessary, then its use of language-c > should be reconsidered. All I did was hack the language-c parser to be more > liberal in the attributes it accepts. I have no reason to believe that my > changes are correct, but it is apparent that nobody is using these parse > results: we just need the parser to not error out. > > > > TL;DR: Long term, language-c should have a stripped down mode of > operation that better fits c2hs's needs. Short term, my language-c fork > seems to work on OS X, but I haven't tested much elsewhere. > > Another option is language-objective-c, which started as a fork of > language-c, supports nearly everything language-c does, and I'm still > actively maintaining it. Unfortunately I don't have the resources to test > it on newer osx versions, so I'd appreciate if somebody else could give it > a try (I'll need to push a new version for 7.8 though). > > John L > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sun Feb 16 10:14:12 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 16 Feb 2014 11:14:12 +0100 Subject: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property Message-ID: <87r473uzyj.fsf@gnu.org> Hello *, Right now, there seems to be no "defined" way to create a zero 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits cleared without involving at least two operations from the 'Bits' class (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). OTOH, introducing a new method 'class Bits a where bitZero :: a' seems overkill to me. However, "bit (-1)"[1] seems to result in just such a zero-value for all 'Bits' instances from base, so I'd hereby propose to simply document this as an expected property of 'bit', as well as the recommended way to introduce a zero-value (for when 'Num' is not available). Discussion period: 2 weeks [1]: ...or more generally 'bit n == 0' for n<0, as it's usually implemented as 'bit n = 1 shift n' From schlepptop at henning-thielemann.de Sun Feb 16 12:17:40 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Feb 2014 13:17:40 +0100 Subject: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property In-Reply-To: <87r473uzyj.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> Message-ID: <5300AC64.4030403@henning-thielemann.de> Am 16.02.2014 11:14, schrieb Herbert Valerio Riedel: > Hello *, > > Right now, there seems to be no "defined" way to create a zero > 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits > cleared without involving at least two operations from the 'Bits' class > (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). > > OTOH, introducing a new method 'class Bits a where bitZero :: a' seems > overkill to me. > > However, "bit (-1)" It would be better to forbid "bit (-1)" by the type system, if this would be possible. If only indices would be allowed that actually exist, then we would have a nice law like "popCount (bit n) == 1". I would not like that the exceptional "bit (-1)" becomes the blessed way to create zeros. An additional "zero" method with a default implementation would be the clean way. From arjanen.loic at gmail.com Sun Feb 16 14:10:42 2014 From: arjanen.loic at gmail.com (ARJANEN =?ISO-8859-1?Q?Lo=EFc?= Jean David) Date: Sun, 16 Feb 2014 15:10:42 +0100 Subject: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property In-Reply-To: <87r473uzyj.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> Message-ID: <1759239.FYxPxuDdch@berenger> Hello, I'll have to come down against that proposal because, at least on amd64 for 64 bits-sized types (Int, Int64, Word & Word64), it doesn't works. That's probably because bit n is usually implemented as 1 shifL n and that on this architechture, the arithmetic left-shift instruction takes only the shift count's 6 low-order bits into account. So we have bit (-1) = shiftL 1 (-1) = shiftL 1 63 = 2 ^ 63. I suspect the same may happen for 32 bits-sized types on x86 where only the 5 low order-bits of the shift count are considered. Regards, ARJANEN Lo?c Le dimanche 16 f?vrier 2014, 11:14:12 Herbert Valerio Riedel a ?crit : > Hello *, > > Right now, there seems to be no "defined" way to create a zero > 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits > cleared without involving at least two operations from the 'Bits' class > (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). > > OTOH, introducing a new method 'class Bits a where bitZero :: a' seems > overkill to me. > > However, "bit (-1)"[1] seems to result in just such a zero-value for all > 'Bits' instances from base, so I'd hereby propose to simply document > this as an expected property of 'bit', as well as the recommended way to > introduce a zero-value (for when 'Num' is not available). > > Discussion period: 2 weeks > > [1]: ...or more generally 'bit n == 0' for n<0, as it's usually > implemented as 'bit n = 1 shift n' From hvr at gnu.org Sun Feb 16 16:42:45 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 16 Feb 2014 17:42:45 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method (was: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property) In-Reply-To: <1759239.FYxPxuDdch@berenger> ("ARJANEN =?utf-8?Q?Lo=C3=AFc?= Jean David"'s message of "Sun, 16 Feb 2014 15:10:42 +0100") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> Message-ID: <87ha7zuhyy.fsf_-_@gnu.org> Hi, On 2014-02-16 at 15:10:42 +0100, ARJANEN Lo?c Jean David wrote: > I'll have to come down against that proposal because, at least on amd64 for 64 > bits-sized types (Int, Int64, Word & Word64), it doesn't works. You're right, I don't know how I could have missed that :-/ Since the presumed pre-condition for the proposal (that 'bit (-1) == 0' would already hold) I hereby amend the proposal to > Introduce a new class method > > class Bits a where > ... > -- | Value with all bits cleared > bitZero :: a > ... > > modulo naming of 'bitZero' (I'm hesitant to consume "zero" from the namespace as was suggested by Henning) From ekmett at gmail.com Sun Feb 16 16:43:48 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 16 Feb 2014 11:43:48 -0500 Subject: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property In-Reply-To: <87r473uzyj.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> Message-ID: Nothing forbids you from allowing negative bit positions in a data type, for instance for fractional bits in a fixed position numeric type. Consequently, I'm -1 on this proposal. You can currently construct 0 several ways, e.g. clearBit (bit 0) 0 could be use to supply a default for any such zeroBits member of the class. -Edward On Sun, Feb 16, 2014 at 5:14 AM, Herbert Valerio Riedel wrote: > Hello *, > > Right now, there seems to be no "defined" way to create a zero > 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits > cleared without involving at least two operations from the 'Bits' class > (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). > > OTOH, introducing a new method 'class Bits a where bitZero :: a' seems > overkill to me. > > However, "bit (-1)"[1] seems to result in just such a zero-value for all > 'Bits' instances from base, so I'd hereby propose to simply document > this as an expected property of 'bit', as well as the recommended way to > introduce a zero-value (for when 'Num' is not available). > > Discussion period: 2 weeks > > [1]: ...or more generally 'bit n == 0' for n<0, as it's usually > implemented as 'bit n = 1 shift n' > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sun Feb 16 16:45:43 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 16 Feb 2014 11:45:43 -0500 Subject: Proposal: add new Data.Bits.Bits(bitZero) method (was: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property) In-Reply-To: <87ha7zuhyy.fsf_-_@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: `bitZero` sounds like it should equal `bit 0`, which it doesn't. zeroBits ? -Edward On Sun, Feb 16, 2014 at 11:42 AM, Herbert Valerio Riedel wrote: > Hi, > > On 2014-02-16 at 15:10:42 +0100, ARJANEN Lo?c Jean David wrote: > > I'll have to come down against that proposal because, at least on amd64 > for 64 > > bits-sized types (Int, Int64, Word & Word64), it doesn't works. > > You're right, I don't know how I could have missed that :-/ > > Since the presumed pre-condition for the proposal (that 'bit (-1) == 0' > would already hold) I hereby amend the proposal to > > > Introduce a new class method > > > > class Bits a where > > ... > > -- | Value with all bits cleared > > bitZero :: a > > ... > > > > modulo naming of 'bitZero' > > (I'm hesitant to consume "zero" from the namespace as was suggested by > Henning) > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Sun Feb 16 16:49:23 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Feb 2014 17:49:23 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <87ha7zuhyy.fsf_-_@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: <5300EC13.6040202@henning-thielemann.de> Am 16.02.2014 17:42, schrieb Herbert Valerio Riedel: >> Introduce a new class method >> >> class Bits a where >> ... >> -- | Value with all bits cleared >> bitZero :: a >> ... >> >> modulo naming of 'bitZero' > > (I'm hesitant to consume "zero" from the namespace as was suggested by Henning) Let me defend "zero": Functions in the module that contain "Bit" in the name (clearBit, setBit, testBit) access a single bit. All functions that access many bits do not contain "Bit" (rotate, shift, xor, popCount). I propose to import the "zero" function with qualification, as well as the other functions from the module. I also propose to provide a default implementation of "zero", like "clearBit (bit 0) 0". This way, the "zero" method can be introduced without breaking existing code. From emertens at gmail.com Sun Feb 16 16:51:49 2014 From: emertens at gmail.com (Eric Mertens) Date: Sun, 16 Feb 2014 08:51:49 -0800 Subject: Proposal: add new Data.Bits.Bits(bitZero) method (was: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: The last time this topic came up (back when Num was split off) the discussion was derailed by the idea of a Bool class and then forgotten. I've hoped for an explicit zero element since then. +1 zeroBits On Feb 16, 2014 8:45 AM, "Edward Kmett" wrote: > `bitZero` sounds like it should equal `bit 0`, which it doesn't. > > zeroBits ? > > -Edward > > > On Sun, Feb 16, 2014 at 11:42 AM, Herbert Valerio Riedel wrote: > >> Hi, >> >> On 2014-02-16 at 15:10:42 +0100, ARJANEN Lo?c Jean David wrote: >> > I'll have to come down against that proposal because, at least on amd64 >> for 64 >> > bits-sized types (Int, Int64, Word & Word64), it doesn't works. >> >> You're right, I don't know how I could have missed that :-/ >> >> Since the presumed pre-condition for the proposal (that 'bit (-1) == 0' >> would already hold) I hereby amend the proposal to >> >> > Introduce a new class method >> > >> > class Bits a where >> > ... >> > -- | Value with all bits cleared >> > bitZero :: a >> > ... >> > >> > modulo naming of 'bitZero' >> >> (I'm hesitant to consume "zero" from the namespace as was suggested by >> Henning) >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Sun Feb 16 17:02:01 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Feb 2014 18:02:01 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: <5300EF09.5010300@henning-thielemann.de> Am 16.02.2014 17:51, schrieb Eric Mertens: > The last time this topic came up (back when Num was split off) the > discussion was derailed by the idea of a Bool class and then forgotten. > I've hoped for an explicit zero element since then. I think it was this discussion: https://www.haskell.org/pipermail/libraries/2011-October/016919.html From arjanen.loic at gmail.com Sun Feb 16 18:16:14 2014 From: arjanen.loic at gmail.com (ARJANEN =?ISO-8859-1?Q?Lo=EFc?= Jean David) Date: Sun, 16 Feb 2014 19:16:14 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <5300EC13.6040202@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <87ha7zuhyy.fsf_-_@gnu.org> <5300EC13.6040202@henning-thielemann.de> Message-ID: <3051373.Yt9jiOk2LO@berenger> Le dimanche 16 f?vrier 2014, 17:49:23 Henning Thielemann a ?crit : > Am 16.02.2014 17:42, schrieb Herbert Valerio Riedel: > >> Introduce a new class method > >> > >> class Bits a where > >> > >> ... > >> -- | Value with all bits cleared > >> bitZero :: a > >> ... > >> > >> modulo naming of 'bitZero' > > > > (I'm hesitant to consume "zero" from the namespace as was suggested by > > Henning) > Let me defend "zero": Functions in the module that contain "Bit" in the > name (clearBit, setBit, testBit) access a single bit. All functions that > access many bits do not contain "Bit" (rotate, shift, xor, popCount). I > propose to import the "zero" function with qualification, as well as the > other functions from the module. > > I also propose to provide a default implementation of "zero", like > "clearBit (bit 0) 0". This way, the "zero" method can be introduced > without breaking existing code. I'm in favour of that modified proposal, so +1 for a "zero" member of Bits. And if we fear problems with collisions, we could always name the member something like zeroValue or zeroBits. From schlepptop at henning-thielemann.de Sun Feb 16 18:29:15 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sun, 16 Feb 2014 19:29:15 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <3051373.Yt9jiOk2LO@berenger> References: <87r473uzyj.fsf@gnu.org> <87ha7zuhyy.fsf_-_@gnu.org> <5300EC13.6040202@henning-thielemann.de> <3051373.Yt9jiOk2LO@berenger> Message-ID: <5301037B.3050800@henning-thielemann.de> Am 16.02.2014 19:16, schrieb ARJANEN Lo?c Jean David: > I'm in favour of that modified proposal, so +1 for a "zero" member of Bits. > > And if we fear problems with collisions, we could always name the member > something like zeroValue or zeroBits. If people adhere to the package versioning policy, then there cannot be collisions. That is, import Data.Bits requires strict version bounds (>=x.y.z.w && =x.y.z && Hi all, I often come up using this snippet: map ($ a) l with l :: [a -> b] In Control.Lens, there's a nice combinator for that, (??) : l ?? a I think it'd be great to include that in Data.Functor, because it's a very common use case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.y.volkov at gmail.com Sun Feb 16 20:42:23 2014 From: nikita.y.volkov at gmail.com (Nikita Volkov) Date: Mon, 17 Feb 2014 00:42:23 +0400 Subject: Adding (??) into Data.Functor In-Reply-To: References: Message-ID: I too find such a function useful and deserving a place in the "base", however I don't think that it's a good idea to make it an operator, especially such a misleading one. I bet that I'm hardly alone in perception of question marks as of indicator of a questionable data (e.g., Maybe), but in no way of lists or functions. Therefore I suggest to instead consider some verbal name for it. E.g., "mapApp" or "mapf" (as an opposite to "fmap"). Also, since the variable input of this combinator seems to be on the functor side I suggest to inverse the arguments order order, i.e.: mapf :: a -> f (a -> b) -> f b This way it'll target composition. And since it's a combinator over functions it's a pretty important thing. E.g.: mapf 2 . map (*) $ [1..10] So, +1 for the combinator, -1 for the proposed name and arguments order . -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.y.volkov at gmail.com Sun Feb 16 20:48:58 2014 From: nikita.y.volkov at gmail.com (Nikita Volkov) Date: Mon, 17 Feb 2014 00:48:58 +0400 Subject: Adding (??) into Data.Functor In-Reply-To: References: Message-ID: By the way, your original example (`l ?? a`) can already be written as `l <*> pure a` using the Applicative. So a new operator wouldn't gain that much. 2014-02-17 0:42 GMT+04:00 Nikita Volkov : > I too find such a function useful and deserving a place in the "base", > however I don't think that it's a good idea to make it an operator, > especially such a misleading one. I bet that I'm hardly alone in perception > of question marks as of indicator of a questionable data (e.g., Maybe), but > in no way of lists or functions. Therefore I suggest to instead consider > some verbal name for it. E.g., "mapApp" or "mapf" (as an opposite to > "fmap"). > > Also, since the variable input of this combinator seems to be on the > functor side I suggest to inverse the arguments order order, i.e.: > > mapf :: a -> f (a -> b) -> f b > > This way it'll target composition. And since it's a combinator over > functions it's a pretty important thing. E.g.: > > mapf 2 . map (*) $ [1..10] > > So, +1 for the combinator, -1 for the proposed name and arguments order . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitri.sabadie at gmail.com Sun Feb 16 21:17:55 2014 From: dimitri.sabadie at gmail.com (Dimitri Sabadie) Date: Sun, 16 Feb 2014 22:17:55 +0100 Subject: Adding (??) into Data.Functor In-Reply-To: References: Message-ID: I know the pure case, and it's not really what we expect I guess. For list, pure embed the value in a list and do combinatorial computations between the two lists, whereas map ($ a) just maps the value over the list (faster I guess). I'm okay about your two points : let's make it a verbal function, and use a -> f (a -> b) -> f b as signature. Now, mapf sounds a bit cryptic I guess. Something like applyOn, onTo, or something like that would be clearer IMHO. On Sun, Feb 16, 2014 at 9:48 PM, Nikita Volkov wrote: > By the way, your original example (`l ?? a`) can already be written as `l > <*> pure a` using the Applicative. So a new operator wouldn't gain that > much. > > > 2014-02-17 0:42 GMT+04:00 Nikita Volkov : > > I too find such a function useful and deserving a place in the "base", >> however I don't think that it's a good idea to make it an operator, >> especially such a misleading one. I bet that I'm hardly alone in perception >> of question marks as of indicator of a questionable data (e.g., Maybe), but >> in no way of lists or functions. Therefore I suggest to instead consider >> some verbal name for it. E.g., "mapApp" or "mapf" (as an opposite to >> "fmap"). >> >> Also, since the variable input of this combinator seems to be on the >> functor side I suggest to inverse the arguments order order, i.e.: >> >> mapf :: a -> f (a -> b) -> f b >> >> This way it'll target composition. And since it's a combinator over >> functions it's a pretty important thing. E.g.: >> >> mapf 2 . map (*) $ [1..10] >> >> So, +1 for the combinator, -1 for the proposed name and arguments order . >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Mon Feb 17 08:41:59 2014 From: abela at chalmers.se (Andreas Abel) Date: Mon, 17 Feb 2014 09:41:59 +0100 Subject: Adding (??) into Data.Functor In-Reply-To: References: Message-ID: <5301CB57.60804@chalmers.se> I am a -1 on both proposals, i.e., on having a special map for the "apply to a fixed argument" case. On 16.02.2014 21:42, Nikita Volkov wrote: > Also, since the variable input of this combinator seems to be on the > functor side I suggest to inverse the arguments order order, i.e.: > > mapf :: a -> f (a -> b) -> f b > > This way it'll target composition. And since it's a combinator over > functions it's a pretty important thing. E.g.: > mapf 2 . map (*) $ [1..10] I'd simply write map (2 *) [1..10] Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Depeartment of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From twanvl at gmail.com Mon Feb 17 13:18:09 2014 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon, 17 Feb 2014 14:18:09 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: <53020C11.2070403@gmail.com> +1 to `zeroBits`. The name fits in with `setBit` etc. I'm also okay with the name `zero`. Twan On 16/02/14 17:45, Edward Kmett wrote: > `bitZero` sounds like it should equal `bit 0`, which it doesn't. > > zeroBits ? > > -Edward > > > On Sun, Feb 16, 2014 at 11:42 AM, Herbert Valerio Riedel > wrote: > > Hi, > > On 2014-02-16 at 15:10:42 +0100, ARJANEN Lo?c Jean David wrote: > > I'll have to come down against that proposal because, at least on amd64 > for 64 > > bits-sized types (Int, Int64, Word & Word64), it doesn't works. > > You're right, I don't know how I could have missed that :-/ > > Since the presumed pre-condition for the proposal (that 'bit (-1) == 0' > would already hold) I hereby amend the proposal to > > > Introduce a new class method > > > > class Bits a where > > ... > > -- | Value with all bits cleared > > bitZero :: a > > ... > > > > modulo naming of 'bitZero' > > (I'm hesitant to consume "zero" from the namespace as was suggested by Henning) > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From dimitri.sabadie at gmail.com Mon Feb 17 13:51:41 2014 From: dimitri.sabadie at gmail.com (Dimitri Sabadie) Date: Mon, 17 Feb 2014 14:51:41 +0100 Subject: Adding (??) into Data.Functor In-Reply-To: <5301CB57.60804@chalmers.se> References: <5301CB57.60804@chalmers.se> Message-ID: This is a special case you mentionned there; it's not about lists, it's about Functor. And applying a function with fmap using ($) is quite ugly. On Mon, Feb 17, 2014 at 9:41 AM, Andreas Abel wrote: > I am a -1 on both proposals, i.e., on having a special map for the "apply > to a fixed argument" case. > > > On 16.02.2014 21:42, Nikita Volkov wrote: > >> Also, since the variable input of this combinator seems to be on the >> functor side I suggest to inverse the arguments order order, i.e.: >> >> mapf :: a -> f (a -> b) -> f b >> >> This way it'll target composition. And since it's a combinator over >> functions it's a pretty important thing. E.g.: >> mapf 2 . map (*) $ [1..10] >> > > I'd simply write > > map (2 *) [1..10] > > Cheers, > Andreas > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Depeartment of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www2.tcs.ifi.lmu.de/~abel/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Feb 17 16:15:34 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 17 Feb 2014 11:15:34 -0500 Subject: Adding (??) into Data.Functor In-Reply-To: <5301CB57.60804@chalmers.se> References: <5301CB57.60804@chalmers.se> Message-ID: I am also -1 on adding it to Data.Functor despite having written it for lens. On Mon, Feb 17, 2014 at 3:41 AM, Andreas Abel wrote: > I am a -1 on both proposals, i.e., on having a special map for the "apply > to a fixed argument" case. > > > On 16.02.2014 21:42, Nikita Volkov wrote: > >> Also, since the variable input of this combinator seems to be on the >> functor side I suggest to inverse the arguments order order, i.e.: >> >> mapf :: a -> f (a -> b) -> f b >> >> This way it'll target composition. And since it's a combinator over >> functions it's a pretty important thing. E.g.: >> mapf 2 . map (*) $ [1..10] >> > > I'd simply write > > map (2 *) [1..10] > > Cheers, > Andreas > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Depeartment of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www2.tcs.ifi.lmu.de/~abel/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From twanvl at gmail.com Mon Feb 17 16:21:03 2014 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon, 17 Feb 2014 17:21:03 +0100 Subject: Adding (??) into Data.Functor In-Reply-To: References: Message-ID: <530236EF.1000500@gmail.com> Would (<$$>) be a sensible name? To match (<**>) from Control.Applicative (<$$>) :: Functor f => a -> f (a -> b) -> f b I don't really feel the need for such a function, though. On a related note, the documentation for (<**>) is pretty bad. It says "A variant of <*> with the arguments reversed." but that doesn't make it clear that the function is different from `flip (<*>)`. Twan On 16/02/14 19:51, Dimitri Sabadie wrote: > Hi all, > > I often come up using this snippet: > map ($ a) l > with > l :: [a -> b] > > In Control.Lens, there?s a nice combinator for that, (??) : > > l ?? a > > I think it?d be great to include that in Data.Functor, because it?s a very > common use case. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From difrumin at gmail.com Mon Feb 17 16:29:30 2014 From: difrumin at gmail.com (Daniil Frumin) Date: Mon, 17 Feb 2014 20:29:30 +0400 Subject: Adding (??) into Data.Functor In-Reply-To: <530236EF.1000500@gmail.com> References: <530236EF.1000500@gmail.com> Message-ID: On Mon, Feb 17, 2014 at 8:21 PM, Twan van Laarhoven wrote: > Would (<$$>) be a sensible name? To match (<**>) from Control.Applicative > > (<$$>) :: Functor f => a -> f (a -> b) -> f b > > I don't really feel the need for such a function, though. > > > On a related note, the documentation for (<**>) is pretty bad. It says "A > variant of <*> with the arguments reversed." but that doesn't make it clear > that the function is different from `flip (<*>)`. > Is the current definition not equivalent to `flip (<*>)` though? > > Twan > > > On 16/02/14 19:51, Dimitri Sabadie wrote: >> >> Hi all, >> >> I often come up using this snippet: >> map ($ a) l >> with >> l :: [a -> b] >> >> In Control.Lens, there's a nice combinator for that, (??) : >> >> l ?? a >> >> I think it'd be great to include that in Data.Functor, because it's a very >> common use case. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- Sincerely yours, -- Daniil From twanvl at gmail.com Mon Feb 17 16:43:17 2014 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon, 17 Feb 2014 17:43:17 +0100 Subject: Adding (??) into Data.Functor In-Reply-To: References: <530236EF.1000500@gmail.com> Message-ID: <53023C25.80405@gmail.com> On 17/02/14 17:29, Daniil Frumin wrote: > On Mon, Feb 17, 2014 at 8:21 PM, Twan van Laarhoven wrote: >> Would (<$$>) be a sensible name? To match (<**>) from Control.Applicative >> >> (<$$>) :: Functor f => a -> f (a -> b) -> f b >> >> I don't really feel the need for such a function, though. >> >> >> On a related note, the documentation for (<**>) is pretty bad. It says "A >> variant of <*> with the arguments reversed." but that doesn't make it clear >> that the function is different from `flip (<*>)`. >> > > Is the current definition not equivalent to `flip (<*>)` though? It is defined as (<**>) = liftA2 (flip ($)) So it does not flip the order of effects. Twan From difrumin at gmail.com Mon Feb 17 18:08:03 2014 From: difrumin at gmail.com (Daniil Frumin) Date: Mon, 17 Feb 2014 22:08:03 +0400 Subject: Adding (??) into Data.Functor In-Reply-To: <53023C25.80405@gmail.com> References: <530236EF.1000500@gmail.com> <53023C25.80405@gmail.com> Message-ID: Oh, I forgot about the effect order, sorry for hijacking the thread. On Mon, Feb 17, 2014 at 8:43 PM, Twan van Laarhoven wrote: > On 17/02/14 17:29, Daniil Frumin wrote: >> >> On Mon, Feb 17, 2014 at 8:21 PM, Twan van Laarhoven >> wrote: >>> >>> Would (<$$>) be a sensible name? To match (<**>) from Control.Applicative >>> >>> (<$$>) :: Functor f => a -> f (a -> b) -> f b >>> >>> I don't really feel the need for such a function, though. >>> >>> >>> On a related note, the documentation for (<**>) is pretty bad. It says "A >>> variant of <*> with the arguments reversed." but that doesn't make it >>> clear >>> that the function is different from `flip (<*>)`. >>> >> >> Is the current definition not equivalent to `flip (<*>)` though? > > > It is defined as > > (<**>) = liftA2 (flip ($)) > > So it does not flip the order of effects. > > > Twan -- Sincerely yours, -- Daniil From ekmett at gmail.com Mon Feb 17 23:53:41 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 17 Feb 2014 18:53:41 -0500 Subject: Adding (??) into Data.Functor In-Reply-To: <530236EF.1000500@gmail.com> References: <530236EF.1000500@gmail.com> Message-ID: FWIW The reason it is called (??) is to make it look like a placeholder. foo ?? bar makes a function to replace the ?? placeholder. It is somewhat more readable than an infixed `flip`. Given my druthers l'd have kept the name (?) for this in lens rather than let it devolve to (??), but too many people complained about taking a name they were already using as (?) was the first operator added to lens without a word frequency search against hackage first. The number of collisions it had in practice was rather high. It was added to lens because a lot of users were asking for variants of a lot of the lens named combinators that swapped the second and third arguments, so they could compose more nicely. By adding one name, (??) we were able to deflect all of those requests. Given creative use of multiple (??)'s you can use it to shuffle any argument to last position, but that violates the 'place holder' intuition. It has the more general type of Stefan Ljungstrand"s version of flip from lambdabot, because, well, everything in lens tries to be as general as possible, but the fact that it works for all functors is more or less an accident that only a few users seem to exploit. The major uses folks seem to put it to is to shuffle the arguments for things like runState, etc. to put the monadic action last. runState ?? myState $ do ... is a lot less noisy than surrounding the whole do in quotes or giving a name to the action I remain slightly against adding it to a place like Data.Functor because I don't like randomly stealing operator names and for most applications flip is more clear as the named combinator conveys intuition about its purpose. It fits into the lens ecosystem where I'm willing to assume a great deal of time invested in understanding local idioms, but I feel it is a poor fit for the larger ecosystem for those reasons. -Edward On Mon, Feb 17, 2014 at 11:21 AM, Twan van Laarhoven wrote: > Would (<$$>) be a sensible name? To match (<**>) from Control.Applicative > > (<$$>) :: Functor f => a -> f (a -> b) -> f b > > I don't really feel the need for such a function, though. > > > On a related note, the documentation for (<**>) is pretty bad. It says "A > variant of <*> with the arguments reversed." but that doesn't make it clear > that the function is different from `flip (<*>)`. > > > Twan > > > On 16/02/14 19:51, Dimitri Sabadie wrote: > >> Hi all, >> >> I often come up using this snippet: >> map ($ a) l >> with >> l :: [a -> b] >> >> In Control.Lens, there?s a nice combinator for that, (??) : >> >> l ?? a >> >> I think it?d be great to include that in Data.Functor, because it?s a very >> common use case. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagitj at gmail.com Tue Feb 18 18:12:17 2014 From: dagitj at gmail.com (Jason Dagit) Date: Tue, 18 Feb 2014 10:12:17 -0800 Subject: Thank you for the donations to Haskell.org! Message-ID: On behalf of Haskell.org, we would like to thank all the generous donors we had in 2013! Just in the last week of the year, we received about half of the total donations for the year. Nearly $900! That brings the total donations for the year to $1976! Thank you very much! We are very grateful for all the donations we receive, financial and otherwise. As examples, GlobalSign graciously provides us with a free SSL certificate for use on hackage and each year community members collectively provide countless hours of time and energy towards making the Haskell community vibrant, positive, and relevant. At the moment our primary expenses are hosting for haskell.org and hackage. The donations we have received will help ensure that we continue to have adequate hosting for the ever growing hackage! Thank you and let's continue our momentum into 2014! Sincerely, The Haskell.org Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sat Feb 22 10:03:12 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sat, 22 Feb 2014 11:03:12 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <87ha7zuhyy.fsf_-_@gnu.org> (Herbert Valerio Riedel's message of "Sun, 16 Feb 2014 17:42:45 +0100") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: <87wqgnforj.fsf_-_@gnu.org> Hello *, Here's a mid-discussion summary of the proposal >> Introduce a new class method >> >> class Bits a where >> ... >> -- | Value with all bits cleared >> <0-value-method> :: a >> ... >> >> modulo naming of '<0-value-method>' from my point of view: - The idea came up already in 2011 when Num-superclass was to be removed from Bits (but discussion derailed) - So far general consensus (i.e. no "-1"s afaics) it's desired to have an all-bits-clear value introducing method in 'Bits' - Use "clearBit (bit 0) 0" as default implementation for smooth upgrade-path - Nameing for <0-value-method> boils down to two candidates: a) 'Data.Bits.zero' - based on the idea tha 'Data.Bits' ought to be imported qualified (or with explicit import-list) anyway (-> thus following PVP practice) - many existing Data.Bits.Bits methods such as 'rotate', 'complement', 'popCount', 'xor', or 'shift' don't have the name 'bit' in it (and those few that have, operate on single bits) - supporters (in no particular order): - ARJANEN Lo?c Jean David - Henning Thielemann - Herbert Valerio Riedel (+0.99) - Twan van Laarhoven b) 'Data.Bits.zeroBits' - more verbose name reduces risk of namespace conflicts with unqualified imports - supporters (in no particular order): - Edward Kmett - Eric Mertens - Herbert Valerio Riedel - Twan van Laarhoven - (maybe?) ARJANEN Lo?c Jean David So far there doesn't seem to be a very clear preference for 'zeroBits' over 'zero'. It might help, if those how expressed some kind of support for both variants could clarify if their preference has any bias towards 'zeroBits' or 'zero'. Cheers, hvr From carter.schonwald at gmail.com Sat Feb 22 14:56:39 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 22 Feb 2014 09:56:39 -0500 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <87wqgnforj.fsf_-_@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> Message-ID: Zero is a big bit of name space. Id favor zerobits over zero. On Saturday, February 22, 2014, Herbert Valerio Riedel wrote: > Hello *, > > Here's a mid-discussion summary of the proposal > > >> Introduce a new class method > >> > >> class Bits a where > >> ... > >> -- | Value with all bits cleared > >> <0-value-method> :: a > >> ... > >> > >> modulo naming of '<0-value-method>' > > from my point of view: > > - The idea came up already in 2011 when Num-superclass was to be removed > from Bits > (but discussion derailed) > > - So far general consensus (i.e. no "-1"s afaics) it's desired to have > an all-bits-clear value introducing method in 'Bits' > > - Use "clearBit (bit 0) 0" as default implementation for smooth > upgrade-path > > - Nameing for <0-value-method> boils down to two candidates: > > a) 'Data.Bits.zero' > > - based on the idea tha 'Data.Bits' ought to be imported > qualified (or with explicit import-list) anyway > (-> thus following PVP practice) > > - many existing Data.Bits.Bits methods such as 'rotate', > 'complement', 'popCount', 'xor', or 'shift' don't have > the name 'bit' in it (and those few that have, operate > on single bits) > > - supporters (in no particular order): > > - ARJANEN Lo?c Jean David > - Henning Thielemann > - Herbert Valerio Riedel (+0.99) > - Twan van Laarhoven > > b) 'Data.Bits.zeroBits' > > - more verbose name reduces risk of namespace conflicts with > unqualified imports > > - supporters (in no particular order): > > - Edward Kmett > - Eric Mertens > - Herbert Valerio Riedel > - Twan van Laarhoven > - (maybe?) ARJANEN Lo?c Jean David > > > So far there doesn't seem to be a very clear preference for > 'zeroBits' over 'zero'. It might help, if those how expressed some > kind of support for both variants could clarify if their preference > has any bias towards 'zeroBits' or 'zero'. > > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Feb 22 15:48:06 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 22 Feb 2014 10:48:06 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <87wqgnforj.fsf_-_@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> Message-ID: I am notably strongly against taking 'zero' as it is much more appropriately used by more algebraic classes, and it is an annoyingly common name to take for such an often unqualified import. -Edward On Sat, Feb 22, 2014 at 5:03 AM, Herbert Valerio Riedel wrote: > Hello *, > > Here's a mid-discussion summary of the proposal > > >> Introduce a new class method > >> > >> class Bits a where > >> ... > >> -- | Value with all bits cleared > >> <0-value-method> :: a > >> ... > >> > >> modulo naming of '<0-value-method>' > > from my point of view: > > - The idea came up already in 2011 when Num-superclass was to be removed > from Bits > (but discussion derailed) > > - So far general consensus (i.e. no "-1"s afaics) it's desired to have > an all-bits-clear value introducing method in 'Bits' > > - Use "clearBit (bit 0) 0" as default implementation for smooth > upgrade-path > > - Nameing for <0-value-method> boils down to two candidates: > > a) 'Data.Bits.zero' > > - based on the idea tha 'Data.Bits' ought to be imported > qualified (or with explicit import-list) anyway > (-> thus following PVP practice) > > - many existing Data.Bits.Bits methods such as 'rotate', > 'complement', 'popCount', 'xor', or 'shift' don't have > the name 'bit' in it (and those few that have, operate > on single bits) > > - supporters (in no particular order): > > - ARJANEN Lo?c Jean David > - Henning Thielemann > - Herbert Valerio Riedel (+0.99) > - Twan van Laarhoven > > b) 'Data.Bits.zeroBits' > > - more verbose name reduces risk of namespace conflicts with > unqualified imports > > - supporters (in no particular order): > > - Edward Kmett > - Eric Mertens > - Herbert Valerio Riedel > - Twan van Laarhoven > - (maybe?) ARJANEN Lo?c Jean David > > > So far there doesn't seem to be a very clear preference for > 'zeroBits' over 'zero'. It might help, if those how expressed some > kind of support for both variants could clarify if their preference > has any bias towards 'zeroBits' or 'zero'. > > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Sat Feb 22 18:36:25 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Sat, 22 Feb 2014 19:36:25 +0100 Subject: [base] Fix off-by-one error in writeBlocks Message-ID: <20140222193625.GA15695@nanodesu.talocan.mine.nu> I've noticed an off-by-one issue in writeBlocks which writes a character fewer than expected per block buffer in block buffering mode, when not using CRLF mode (+ adding a newline). I've implemented a patch which fixes this particular issue, but I haven't eyeballed the Core or benchmarked it thoroughly to make sure it's not a big performance regression. The only concern I have, apart from performance, is that due to the way the loop works we technically inspect the next cons cell *before* actually flushing the buffer, so it's too strict by exactly one character. I didn't know how to solve this without inverting the entire loop though, and I'm very wary of the performance impact that would have. I would appreciate feedback and comments. Is this issue worth pushing the change in the first place? Discussion period: 2 weeks -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-diff Size: 3658 bytes Desc: not available URL: From acowley at seas.upenn.edu Sat Feb 22 19:51:24 2014 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Sat, 22 Feb 2014 14:51:24 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <87wqgnforj.fsf_-_@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> Message-ID: <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> I am -1 on the name zero. I don't think importing Data.Bits unqualified is uncommon at all, and zero is prime naming real estate. I am +0.5 on the addition overall, as most uses of Bits are with types that also have Num instances. If we are naming this thing, then I vote for zeroBits. Anthony > On Feb 22, 2014, at 5:03 AM, Herbert Valerio Riedel wrote: > > Hello *, > > Here's a mid-discussion summary of the proposal > >>> Introduce a new class method >>> >>> class Bits a where >>> ... >>> -- | Value with all bits cleared >>> <0-value-method> :: a >>> ... >>> >>> modulo naming of '<0-value-method>' > > from my point of view: > > - The idea came up already in 2011 when Num-superclass was to be removed from Bits > (but discussion derailed) > > - So far general consensus (i.e. no "-1"s afaics) it's desired to have > an all-bits-clear value introducing method in 'Bits' > > - Use "clearBit (bit 0) 0" as default implementation for smooth upgrade-path > > - Nameing for <0-value-method> boils down to two candidates: > > a) 'Data.Bits.zero' > > - based on the idea tha 'Data.Bits' ought to be imported > qualified (or with explicit import-list) anyway > (-> thus following PVP practice) > > - many existing Data.Bits.Bits methods such as 'rotate', > 'complement', 'popCount', 'xor', or 'shift' don't have > the name 'bit' in it (and those few that have, operate > on single bits) > > - supporters (in no particular order): > > - ARJANEN Lo?c Jean David > - Henning Thielemann > - Herbert Valerio Riedel (+0.99) > - Twan van Laarhoven > > b) 'Data.Bits.zeroBits' > > - more verbose name reduces risk of namespace conflicts with unqualified imports > > - supporters (in no particular order): > > - Edward Kmett > - Eric Mertens > - Herbert Valerio Riedel > - Twan van Laarhoven > - (maybe?) ARJANEN Lo?c Jean David > > > So far there doesn't seem to be a very clear preference for > 'zeroBits' over 'zero'. It might help, if those how expressed some > kind of support for both variants could clarify if their preference > has any bias towards 'zeroBits' or 'zero'. > > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From carter.schonwald at gmail.com Sun Feb 23 04:48:38 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 22 Feb 2014 23:48:38 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: Bump! have we reached any consensus on the different variations of this proposal? a) i seem to recall some of the cabal maintainers expressing interest in hosting binaries for major platforms b) some sort of platform-lite thats the ghc bin dist + cabal-install, targeted at folks using haskell on server rather than desktop envs -- there was a bunch of strong support for this (esp those using haskell and aren't on the major linux distros) c) incuding a cabal install binary in the release build bin dist for ghc (there were some reasonable arguments against this) am I missing any major ideas folks had? both the "mini lite platform for servers" and "cabal binaries to easily download" are great ideas. -Carter On Sun, Feb 2, 2014 at 10:13 PM, Jens Petersen wrote: > +1 for Carter's proposal - I had actually been planning to make the same > suggestion, but just saw this thread now... > > On 27 January 2014 09:39, Austin Seipp wrote: > >> As for shipping with GHC itself: this is technically possible, but >> slightly annoying to implement, and it also makes the build processes >> for a release slightly more annoying (which is mostly my problem.) But >> it is all doable. However, keep in mind I *do not* maintain the binary >> distributions for everything, nor do Cabal devs have access to all >> hardware - so all people making upstream releases for their platforms >> (i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal >> themselves. But perhaps that's not a huge deal. >> > > If ghc provided cabal-install I would be happy to ship that in Fedora > instead of a separate package. To me cabal-install is probably the most > important tool/package in HP (except for ghc itself of course): many people > build/bootstrap latest ghc themselves it seems and so providing > the latest cabal-install out of the box too would be a big win IMO, > making it much easier to test ghc. (I wouldn't even mind if ghc > shipped cabal-install's dependencies too.) > > Jens > > ps Of course it could be made a configure option whether to build > cabal-install or now: the cabal-install source is already there. ;) :) > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Sun Feb 23 16:31:20 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sun, 23 Feb 2014 17:31:20 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: Hi, On 23 February 2014 05:48, Carter Schonwald wrote: > Bump! > > have we reached any consensus on the different variations of this proposal? > > a) i seem to recall some of the cabal maintainers expressing interest in hosting binaries for major platforms Austin promised to provide us with build bots for 3/4 of the tier 1 platforms. I assume that he is busy with preparing with the 7.8 release now. From zcarterc at gmail.com Mon Feb 24 03:13:36 2014 From: zcarterc at gmail.com (Carter Charbonneau) Date: Sun, 23 Feb 2014 20:13:36 -0700 Subject: Burning more bridges (mostly numeric ones) Message-ID: The Burning Bridges thread got lots done, but seemed to miss a few things, and didn't even touch on the Numeric classes. The Numeric classes should be fixed at some point, and sooner is better than later. However, it would be a large change and would go nicely with a major version bump in base. 5 is coming up soon. Proposals, ordered from relatively controversial to insanely so (at least IMO): 1. Replace (.) and id from versions from Control.Category in Prelude This is a small change, and has close to the same effect as the Foldable/ Traversable change. The key difference is that this is a much smaller change and there is little current use for the versions from Control.Category However, historically they have seen use with the other lens-ish libraries, and AFAICT are the reason the lenses in `lens` are "backwards", or at least called so my some. 1.2 Use Semigroupoid for (.) and Ob for id instead. Personally, I really like this idea, but I think it would be much more controversial. 2. Move Semigroup into Prelude 2.1 Make Monoid depend on Semigroup. 3. Do something with the Numeric classes. This isn't so much of a proposal as a request for discussion from people more experienced than me, but I still think a general idea if people think that doing *anything* is a good idea would be useful. 3.1 Split each numeric operation into it's own class. Say no to 3.2 and yes here for no hierarchy in them/ConstraintKinds/empty classes. Pros: EDSLs, convenience. Cons: Would be major breakage, would need ConstraintKinds/empty classes to have a hierarchy. 3.2 Hierarchy. the classes are TBD, this is here for a straw poll. From carter.schonwald at gmail.com Mon Feb 24 04:13:52 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 23 Feb 2014 23:13:52 -0500 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: Message-ID: Darn, theres another carter on this list!!! (welcome!) These are some good points to push on, but *the two weeks* before ghc 7.8 is tentatively due for release! Also, 3 is * too big* to be included in this thread, the ones before are worth several threads alone. I humbly ask all subsequent respondents to focus on #'s 1 and 2. fixing the numeric components of prelude actually will require some innovation on the way we can even organize / structure type classes if we really wish to map the standard pen+paper algebraic structures to their computational analogues in a prelude friendly way. I've got many good reasons to care about improving this piece of Base, including the fact that I'm spending (a professionally inadvisable) large amount of time figuring out how to improve the entire numerical computing substrate for Haskell. And i'm leaning towards figuring out the numeric prelude that needs to be *correct and good* and then pushing for a subset thereof for getting into base. This is one of those areas that "commitee" doesn't matter. the design has to work. It has to be useable. And i don't think theres currently any strong "heres the right design" choice. Also whatever new design lands in GHC BASE defacto determines the next haskell standard (ishhh). That said, I think after the split-base work lands, doing surgery on the default numerical classes becomes more tenable cheers :) On Sun, Feb 23, 2014 at 10:13 PM, Carter Charbonneau wrote: > The Burning Bridges thread got lots done, but seemed to miss a few things, > and > didn't even touch on the Numeric classes. The Numeric classes should be > fixed > at some point, and sooner is better than later. However, it would be a > large > change and would go nicely with a major version bump in base. 5 is coming > up soon. Proposals, ordered from relatively controversial to insanely so > (at least IMO): > > 1. Replace (.) and id from versions from Control.Category in Prelude > This is a small change, and has close to the same effect as the Foldable/ > Traversable change. The key difference is that this is a much smaller > change > and there is little current use for the versions from Control.Category > However, historically they have seen use with the other lens-ish > libraries, > and AFAICT are the reason the lenses in `lens` are "backwards", or at > least > called so my some. > > 1.2 Use Semigroupoid for (.) and Ob for id instead. Personally, I really > like > this idea, but I think it would be much more controversial. > > 2. Move Semigroup into Prelude > > 2.1 Make Monoid depend on Semigroup. > > 3. Do something with the Numeric classes. This isn't so much of a proposal > as a > request for discussion from people more experienced than me, but I still > think a general idea if people think that doing *anything* is a good idea > would be useful. > > 3.1 Split each numeric operation into it's own class. Say no to 3.2 and > yes here > for no hierarchy in them/ConstraintKinds/empty classes. > Pros: EDSLs, convenience. > Cons: Would be major breakage, would need ConstraintKinds/empty classes > to > have a hierarchy. > > 3.2 Hierarchy. the classes are TBD, this is here for a straw poll. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Mon Feb 24 09:47:47 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 10:47:47 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> Message-ID: <530B1543.8080805@henning-thielemann.de> Am 22.02.2014 15:56, schrieb Carter Schonwald: > Zero is a big bit of name space. Id favor zerobits over zero. ... only if you plan to add another "zero" thing to the Data.Bits module. Conflicts with other modules must be resolved with importing mechanisms, but not by finding names that are different from all other identifiers in all other modules in all other packages. It just makes no sense to have a nice module system, but use it like the #include directive of the C preprocessor and eventually maybe complain about the deficiencies of the current module system. From schlepptop at henning-thielemann.de Mon Feb 24 09:54:14 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 10:54:14 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> Message-ID: <530B16C6.9000904@henning-thielemann.de> Am 22.02.2014 20:51, schrieb Anthony Cowley: > I am -1 on the name zero. I don't think importing Data.Bits unqualified is uncommon at all, and zero is prime naming real estate. Can you promise that you will use tight version bounds on 'base' if you import Data.Bits unqualified and without explicit import list in order to conform to the PVP? From daniel.trstenjak at gmail.com Mon Feb 24 10:14:39 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 24 Feb 2014 11:14:39 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <530B1543.8080805@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B1543.8080805@henning-thielemann.de> Message-ID: <20140224101439.GA8982@machine> On Mon, Feb 24, 2014 at 10:47:47AM +0100, Henning Thielemann wrote: > ... only if you plan to add another "zero" thing to the Data.Bits > module. Conflicts with other modules must be resolved with importing > mechanisms, but not by finding names that are different from all > other identifiers in all other modules in all other packages. It > just makes no sense to have a nice module system, but use it like > the #include directive of the C preprocessor and eventually maybe > complain about the deficiencies of the current module system. Yes, I'm thinking in the same way. Having "unique" names also seems to encourage to import modules unqualified, which sometimes is understandable - and I won't tell that I'm never doing it ;) - but at the end might have its own issues. Sure, the possibility to get future conflicts by importing 'zero' unqualified might be higher than with 'zeroBits', but using the qualified name 'Bits.zero' isn't any longer and it's more likely that you won't be getting conflicts in the future that way. And if you're having some local, algorithmic code, these post fixes like 'Bits' are just annoying and cluttering your code. Greetings, Daniel From jmacristovao at gmail.com Mon Feb 24 10:39:17 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Mon, 24 Feb 2014 10:39:17 +0000 Subject: Proposal: improve the Data.Tree API Message-ID: Hello, The Data.Tree API seems rather poor. Some research on hackage shows some additional functions being defined in very unrelated packages: http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies.html#g:3 http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat I propose the addition of the following functions, that seem rather straigh forward to me: -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence -- of the specified node value lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) -- | get the sub-tree rooted at the first (left-most, depth-first) value that -- matches the provided condition findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) -- | keep only the elements that match the provided condition filter :: (a -> Bool) -> Tree a -> Tree a The 'Tree' is appended in the name, to distinguish from the Foldable instances, that return the value, and not a sub-tree. Additionally, the following two functions might also be useful (even if the implementation is very simple in the second case): -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) -- | Length of the tree length :: Tree a -> Int There are probably more useful functions to add, so suggestions are welcomed. Previous discussion: https://github.com/haskell/containers/issues/39#issuecomment-35799628 Discussion period: 2 weeks Cheers, Jo?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Mon Feb 24 10:50:49 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 24 Feb 2014 21:50:49 +1100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: Message-ID: On 24 February 2014 21:39, Jo?o Crist?v?o wrote: > Hello, > > The Data.Tree API seems rather poor. Some research on hackage shows some > additional functions being defined in very unrelated packages: > > http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies.html#g:3 > > http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat > > I propose the addition of the following functions, that seem rather straigh > forward to me: > > -- | get the sub-tree rooted at the first (left-most, depth-first) > occurrence > -- of the specified node value > lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) > > -- | get the sub-tree rooted at the first (left-most, depth-first) value > that > -- matches the provided condition > findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) > > -- | keep only the elements that match the provided condition > filter :: (a -> Bool) -> Tree a -> Tree a > > The 'Tree' is appended in the name, to distinguish from the Foldable > instances, that return the value, and not a sub-tree. > > Additionally, the following two functions might also be useful (even if the > implementation is very simple in the second case): > -- | get the sub-tree for the specified node value in the first tree in > -- forest in which it occurs. > lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) > > -- | Length of the tree > length :: Tree a -> Int What is the length of a tree? The number of sub-trees of that particular root node? The overall width of the tree? The number of nodes? > > There are probably more useful functions to add, so suggestions are > welcomed. > > Previous discussion: > https://github.com/haskell/containers/issues/39#issuecomment-35799628 > > Discussion period: 2 weeks > > Cheers, > Jo?o > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jmacristovao at gmail.com Mon Feb 24 10:55:59 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Mon, 24 Feb 2014 10:55:59 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: Message-ID: I was thinking of: length :: Tree a -> Int length = L.length . flatten But to be honest, I don't have strong feelings about this, I'm willing to drop this particular function (length) from the proposal, if there is no consensus. Jo?o 2014-02-24 10:50 GMT+00:00 Ivan Lazar Miljenovic : > On 24 February 2014 21:39, Jo?o Crist?v?o wrote: > > Hello, > > > > The Data.Tree API seems rather poor. Some research on hackage shows some > > additional functions being defined in very unrelated packages: > > > > > http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies.html#g:3 > > > > > http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat > > > > I propose the addition of the following functions, that seem rather > straigh > > forward to me: > > > > -- | get the sub-tree rooted at the first (left-most, depth-first) > > occurrence > > -- of the specified node value > > lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) > > > > -- | get the sub-tree rooted at the first (left-most, depth-first) value > > that > > -- matches the provided condition > > findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) > > > > -- | keep only the elements that match the provided condition > > filter :: (a -> Bool) -> Tree a -> Tree a > > > > The 'Tree' is appended in the name, to distinguish from the Foldable > > instances, that return the value, and not a sub-tree. > > > > Additionally, the following two functions might also be useful (even if > the > > implementation is very simple in the second case): > > -- | get the sub-tree for the specified node value in the first tree in > > -- forest in which it occurs. > > lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) > > > > -- | Length of the tree > > length :: Tree a -> Int > > What is the length of a tree? The number of sub-trees of that > particular root node? The overall width of the tree? The number of > nodes? > > > > > There are probably more useful functions to add, so suggestions are > > welcomed. > > > > Previous discussion: > > https://github.com/haskell/containers/issues/39#issuecomment-35799628 > > > > Discussion period: 2 weeks > > > > Cheers, > > Jo?o > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Mon Feb 24 10:48:57 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 11:48:57 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: Message-ID: <530B2399.3040907@henning-thielemann.de> Am 24.02.2014 11:39, schrieb Jo?o Crist?v?o: > -- | Length of the tree > length :: Tree a -> Int This one could be implemented more generally (maybe additionally) in Data.Foldable. But this would be another proposal. From jmacristovao at gmail.com Mon Feb 24 11:11:00 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Mon, 24 Feb 2014 11:11:00 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: <530B2399.3040907@henning-thielemann.de> References: <530B2399.3040907@henning-thielemann.de> Message-ID: Yes, indeed, thats a totally different discussion I do not want to enter: http://www.reddit.com/r/haskell/comments/xo05l/why_isnt_length_part_of_foldable/ So, I'll 'erase' the length function from the proposal, since: * it's definition is not unanymous * my definition (number of elements) is simple enough to be implemented in several ways Cheers Jo?o 2014-02-24 10:48 GMT+00:00 Henning Thielemann < schlepptop at henning-thielemann.de>: > Am 24.02.2014 11:39, schrieb Jo?o Crist?v?o: > > > -- | Length of the tree >> length :: Tree a -> Int >> > > This one could be implemented more generally (maybe additionally) in > Data.Foldable. But this would be another proposal. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at ibotty.net Mon Feb 24 11:17:29 2014 From: haskell at ibotty.net (Tobias Florek) Date: Mon, 24 Feb 2014 12:17:29 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: Message-ID: <530B2A49.8030605@ibotty.net> hi, > But to be honest, I don't have strong feelings about this, I'm willing > to drop this particular function (length) from the proposal, if there is > no consensus. then what about the arguably better name `size`? cheers, tobias florek From ivan.miljenovic at gmail.com Mon Feb 24 11:38:24 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 24 Feb 2014 22:38:24 +1100 Subject: Proposal: improve the Data.Tree API In-Reply-To: <530B2A49.8030605@ibotty.net> References: <530B2A49.8030605@ibotty.net> Message-ID: On 24 February 2014 22:17, Tobias Florek wrote: > hi, > >> But to be honest, I don't have strong feelings about this, I'm willing >> to drop this particular function (length) from the proposal, if there is >> no consensus. > > then what about the arguably better name `size`? Huh, I thought we already had that. Some things I missed when I last used Data.Tree: * An Ord instance (achievable via standalone deriving, though this isn't ideal) * A function to take the mirror-image of a tree (name not that important): mirror :: Tree a -> Tree a mirror (Node a ts) = Node a . reverse $ map mirror ts * Functions to take/drop so many levels of the tree (take is relatively easy; drop would result in a Forest). > > cheers, > tobias florek > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jmacristovao at gmail.com Mon Feb 24 12:55:31 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Mon, 24 Feb 2014 12:55:31 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: Hi Ivan, >> then what about the arguably better name `size`? > Huh, I thought we already had that. We do? If there is consensus I would then add `size` with the arguably more efficient implementation: size :: Tree a -> Int size = getSum . F.foldMap (const $ Sum 1) > * An Ord instance (achievable via standalone deriving, though this isn't ideal) Agreed. > * Functions to take/drop so many levels of the tree (take is > relatively easy; drop would result in a Forest). Similar to treeprune in http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat? > mirror :: Tree a -> Tree a > mirror (Node a ts) = Node a . reverse $ map mirror ts I don't have strong feeling about this one, but if more people see as useful, why not... Jo?o 2014-02-24 11:38 GMT+00:00 Ivan Lazar Miljenovic : > On 24 February 2014 22:17, Tobias Florek wrote: > > hi, > > > >> But to be honest, I don't have strong feelings about this, I'm willing > >> to drop this particular function (length) from the proposal, if there is > >> no consensus. > > > > then what about the arguably better name `size`? > > Huh, I thought we already had that. > > Some things I missed when I last used Data.Tree: > > * An Ord instance (achievable via standalone deriving, though this isn't > ideal) > > * A function to take the mirror-image of a tree (name not that important): > > mirror :: Tree a -> Tree a > mirror (Node a ts) = Node a . reverse $ map mirror ts > > * Functions to take/drop so many levels of the tree (take is > relatively easy; drop would result in a Forest). > > > > > > cheers, > > tobias florek > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Feb 24 13:13:20 2014 From: voldermort at hotmail.com (harry) Date: Mon, 24 Feb 2014 05:13:20 -0800 (PST) Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: Message-ID: <1393247600013-5744545.post@n5.nabble.com> Carter Charbonneau wrote > 2. Move Semigroup into Prelude > > 2.1 Make Monoid depend on Semigroup. NonEmpty seems to be frequently reimplemented, particularly by beginners. Including Semigroup in Prelude would save all this duplication. -- View this message in context: http://haskell.1045720.n5.nabble.com/Burning-more-bridges-mostly-numeric-ones-tp5744526p5744545.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From twanvl at gmail.com Mon Feb 24 17:34:24 2014 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon, 24 Feb 2014 18:34:24 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> Message-ID: <530B82A0.6090009@gmail.com> I agree with Edward that it would be better to reserve 'zero' for something like an additive identity. I'll withdraw my +1 for the name `zero`, in favor of +1 for `zeroBits`. Twan On 22/02/14 16:48, Edward Kmett wrote: > I am notably strongly against taking 'zero' as it is much more appropriately > used by more algebraic classes, and it is an annoyingly common name to take for > such an often unqualified import. > > -Edward > > > On Sat, Feb 22, 2014 at 5:03 AM, Herbert Valerio Riedel > wrote: > > Hello *, > > Here's a mid-discussion summary of the proposal > > >> Introduce a new class method > >> > >> class Bits a where > >> ... > >> -- | Value with all bits cleared > >> <0-value-method> :: a > >> ... > >> > >> modulo naming of '<0-value-method>' > > from my point of view: > > - The idea came up already in 2011 when Num-superclass was to be removed > from Bits > (but discussion derailed) > > - So far general consensus (i.e. no "-1"s afaics) it's desired to have > an all-bits-clear value introducing method in 'Bits' > > - Use "clearBit (bit 0) 0" as default implementation for smooth upgrade-path > > - Nameing for <0-value-method> boils down to two candidates: > > a) 'Data.Bits.zero' > > - based on the idea tha 'Data.Bits' ought to be imported > qualified (or with explicit import-list) anyway > (-> thus following PVP practice) > > - many existing Data.Bits.Bits methods such as 'rotate', > 'complement', 'popCount', 'xor', or 'shift' don't have > the name 'bit' in it (and those few that have, operate > on single bits) > > - supporters (in no particular order): > > - ARJANEN Lo?c Jean David > - Henning Thielemann > - Herbert Valerio Riedel (+0.99) > - Twan van Laarhoven > > b) 'Data.Bits.zeroBits' > > - more verbose name reduces risk of namespace conflicts with > unqualified imports > > - supporters (in no particular order): > > - Edward Kmett > - Eric Mertens > - Herbert Valerio Riedel > - Twan van Laarhoven > - (maybe?) ARJANEN Lo?c Jean David > > > So far there doesn't seem to be a very clear preference for > 'zeroBits' over 'zero'. It might help, if those how expressed some > kind of support for both variants could clarify if their preference > has any bias towards 'zeroBits' or 'zero'. > > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From schlepptop at henning-thielemann.de Mon Feb 24 17:41:00 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 18:41:00 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <530B82A0.6090009@gmail.com> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> Message-ID: <530B842C.1090609@henning-thielemann.de> Am 24.02.2014 18:34, schrieb Twan van Laarhoven: > I agree with Edward that it would be better to reserve 'zero' for > something like an additive identity. Why would you want to reserve Bits.zero for an additive zero? This makes no sense. > I'll withdraw my +1 for the name `zero`, in favor of +1 for `zeroBits`. What is bad about Bits.zero? From allbery.b at gmail.com Mon Feb 24 17:57:21 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 24 Feb 2014 12:57:21 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <530B842C.1090609@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> Message-ID: On Mon, Feb 24, 2014 at 12:41 PM, Henning Thielemann < schlepptop at henning-thielemann.de> wrote: > Am 24.02.2014 18:34, schrieb Twan van Laarhoven: > > I agree with Edward that it would be better to reserve 'zero' for >> something like an additive identity. >> > > Why would you want to reserve Bits.zero for an additive zero? This makes > no sense. There is something vaguely smelly about specifically omitting the context > it is an annoyingly common name to take for > such an often unqualified import. in the original message. Yes, we're quite aware you do not consider it legitimate. Distorting someone else's meaning to press your point is also not legitimate. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Mon Feb 24 18:00:04 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 19:00:04 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <87wqgnforj.fsf_-_@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> Message-ID: <530B88A4.7040302@henning-thielemann.de> Am 22.02.2014 11:03, schrieb Herbert Valerio Riedel: > So far there doesn't seem to be a very clear preference for > 'zeroBits' over 'zero'. It might help, if those how expressed some > kind of support for both variants could clarify if their preference > has any bias towards 'zeroBits' or 'zero'. It turns out to be another round of the discussion qualified imports vs. unqualified imports. Many Haskell programmers seem to avoid qualified imports at all costs. I can't explain that, maybe the proponents of qualified imports can do it. But I suspect that what we really discuss is something more critical: It's about conformance to PVP vs. non-conformance to PVP and thus letting Hackage users fix packages of lazy programmers. I guess, what the proponents of "zeroBit" really want, is to import unqualified, implicitly and without version bounds when importing 'base'. If you want to conform to the PVP and thus give the user a good experience, then you have to give up one of these three conveniences. Strict version bounds on "base" requires to update Cabal descriptions frequently. I guess you don't want that. Explicit imports mean that you have to maintain import lists. I guess you don't want that as well. The only convenient option is to import qualified. But then Bits.zero is much better than Bits.zeroBits. From schlepptop at henning-thielemann.de Mon Feb 24 18:09:16 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 19:09:16 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> Message-ID: <530B8ACC.8090407@henning-thielemann.de> Am 24.02.2014 18:57, schrieb Brandon Allbery: > On Mon, Feb 24, 2014 at 12:41 PM, Henning Thielemann > > wrote: > > Am 24.02.2014 18 :34, schrieb Twan van Laarhoven: > > I agree with Edward that it would be better to reserve 'zero' for > something like an additive identity. > > > Why would you want to reserve Bits.zero for an additive zero? This > makes no sense. > > > There is something vaguely smelly about specifically omitting the context > > > it is an annoyingly common name to take for >> such an often unqualified import. > > in the original message. Yes, we're quite aware you do not consider it > legitimate. Distorting someone else's meaning to press your point is > also not legitimate. The phrase "reserve 'zero'" suggests that once we choose Bits.zero, the identifier 'zero' is reserved once and for all and cannot be used for something different anymore. That is, this phrasing removes the option of qualified imports from the scope and thus generates the wrong context. Can someone please, please tell me why we must avoid qualified imports at all costs? Why is this option repeatedly ignored when just saying zeroBits (+1) or zero (-1)? From ekmett at gmail.com Mon Feb 24 19:56:27 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 24 Feb 2014 14:56:27 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <530B8ACC.8090407@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> Message-ID: Henning, As far as I know the only serious proponent of using qualified imports for all imports *all* the time is you. Name conflicts don't affect you. We get that. We got that loud and clear virtually every time the naming of pretty much anything has arisen on this mailing list for the last few years. That doesn't change the fact that your practice and common practice diverge. I'm hard pressed to like an option that causes pain for the sloppy majority. -Edward On Mon, Feb 24, 2014 at 1:09 PM, Henning Thielemann < schlepptop at henning-thielemann.de> wrote: > Am 24.02.2014 18:57, schrieb Brandon Allbery: > >> On Mon, Feb 24, 2014 at 12:41 PM, Henning Thielemann >> > > wrote: >> >> Am 24.02.2014 18 :34, schrieb Twan van >> Laarhoven: >> >> >> I agree with Edward that it would be better to reserve 'zero' for >> something like an additive identity. >> >> >> Why would you want to reserve Bits.zero for an additive zero? This >> makes no sense. >> >> >> There is something vaguely smelly about specifically omitting the context >> >> > it is an annoyingly common name to take for >> >>> such an often unqualified import. >>> >> >> in the original message. Yes, we're quite aware you do not consider it >> legitimate. Distorting someone else's meaning to press your point is >> also not legitimate. >> > > The phrase "reserve 'zero'" suggests that once we choose Bits.zero, the > identifier 'zero' is reserved once and for all and cannot be used for > something different anymore. That is, this phrasing removes the option of > qualified imports from the scope and thus generates the wrong context. > > Can someone please, please tell me why we must avoid qualified imports at > all costs? Why is this option repeatedly ignored when just saying zeroBits > (+1) or zero (-1)? > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cam at uptoisomorphism.net Mon Feb 24 19:56:48 2014 From: cam at uptoisomorphism.net (Casey McCann) Date: Mon, 24 Feb 2014 14:56:48 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <530B8ACC.8090407@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> Message-ID: On Mon, Feb 24, 2014 at 1:09 PM, Henning Thielemann wrote: > Am 24.02.2014 18:57, schrieb Brandon Allbery: >> >> There is something vaguely smelly about specifically omitting the context >> >> > it is an annoyingly common name to take for >>> >>> such an often unqualified import. >> >> >> in the original message. Yes, we're quite aware you do not consider it >> legitimate. Distorting someone else's meaning to press your point is >> also not legitimate. > > > The phrase "reserve 'zero'" suggests that once we choose Bits.zero, the > identifier 'zero' is reserved once and for all and cannot be used for > something different anymore. That is, this phrasing removes the option of > qualified imports from the scope and thus generates the wrong context. > > Can someone please, please tell me why we must avoid qualified imports at > all costs? Why is this option repeatedly ignored when just saying zeroBits > (+1) or zero (-1)? Because it is a thoroughly irrelevant option, empirically speaking, on account of approximately nobody actually using Data.Bits that way. Based on a quick Google search of hackage, here are the use cases wherein Data.Bits is imported qualified: - Intentionally defining functions with clashing names which are then exported with the intent of being imported unqualified elsewhere - Machine-generated code too lazy to worry about namespace issues - Commented-out import lines Your own code, by the way, falling into the third category. If your primary contention here is that core library APIs should be re-designed based not on how they are actually used in practice, but rather on pie-in-the-sky notions regarding how they ought to be used in some uniquely ideal world, perhaps you should raise that point in its own thread rather than endlessly hijacking discussions about modules you may or may not even use. A debate over painting new doors for a bikeshed is not the time or place to propose tearing down the entire shed and building a gazebo in its place. As for the real question, I'd prefer something along the lines of "clearedBits". Only the haddock comments on the shift functions use 1/0 to talk about individual bits, the function names and the other haddocks consistently use set/clear. It's not a big deal though. I'm also wondering if anyone has examples of the name "zero" in code that's actually used and doesn't expect to stomp all over the namespace anyway by redefining arithmetic. "zero" sounds suspiciously like one of those names that's so common nobody actually uses it because they don't want to clash with all the other places it's being conspicuously not used. (see: mzero, zeroArrow...) I'm not at all sure Data.Bits is the flag we'd want to plant in it regardless, but it would be nice to know if "zero" is actually in common use. - C. From dan.doel at gmail.com Mon Feb 24 20:24:08 2014 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 24 Feb 2014 15:24:08 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> Message-ID: On Mon, Feb 24, 2014 at 2:56 PM, Casey McCann wrote: > Because it is a thoroughly irrelevant option, empirically speaking, on > account of approximately nobody actually using Data.Bits that way. > There's some reason for that, too. Bits has operators, which are especially ugly when qualified, and I suspect most people are even more annoyed by using two import statements to manage this than they are about using qualified imports in the first place. In fact, most of the library has unique enough names that it needn't be imported qualified, and qualifying would make code read worse (to me, and I'm sure others; x `Bits.shiftR` n). So in this case, we'd be adding one function that encourages qualification to a module that otherwise doesn't. -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Mon Feb 24 20:28:19 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 24 Feb 2014 12:28:19 -0800 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> Message-ID: On Mon, Feb 24, 2014 at 11:56 AM, Edward Kmett wrote: > Henning, > > As far as I know the only serious proponent of using qualified imports for > all imports all the time is you. Well, so am I, but I'm not the crusading sort. Unqualified import as default is definitely the dominant style, to the point where language extensions tend to assume it, e.g. record puns, or even the whole shared record names debate. Interestingly, python and java seem to lean the other way. Not sure about ocaml, but I remember qualified names from back in the day. A culture thing, I guess. Infix operators and backticks are uniquely haskelly things that probably contribute a little. From schlepptop at henning-thielemann.de Mon Feb 24 20:30:56 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 21:30:56 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> Message-ID: <530BAC00.3010402@henning-thielemann.de> Am 24.02.2014 20:56, schrieb Edward Kmett: > As far as I know the only serious proponent of using qualified imports > for all imports /all/ the time is you. First, there are some important packages like containers and bytestring that clearly are intended for qualified imports, and I really like that insertFM was replaced by Map.insert in the past. Second, your argument addresses a person not the issue. > Name conflicts don't affect you. We get that. We got that loud and clear > virtually every time the naming of pretty much anything has arisen on > this mailing list for the last few years. Sure, because there is no general discussion about the pros and cons of various naming styles. That's why it is discussed for every single identifier. How should a general discussion look like? What could be its outcome? That I am no longer allowed to propose the qualified import style? > That doesn't change the fact that your practice and common practice diverge. And I challenge the common practice, because it prefers convenience for few package authors over convenience for many package user (that may not even be a Haskell programmer). For an example let me look at your lens package. You use unqualified and implicit imports. That is according to the PVP you would need to use tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you don't. That is, your package does not conform to the PVP. It implies that users may have to fix your package when one of the imported packages starts to export identifiers that clash with those from "lens". Of course, there is no need to conform to the PVP. But it works best if many people adhere to it. I have not written the PVP, that is, there must be at least one other person who cares. I understand the need for it and try to comply to it. Maybe I am in a minority. Looking at Hackage it seems I am in a minority. But I believe I am in the minority who cares whether packages work together. Shall I capitulate to the majority which does not seem to care about package interoperability? I am also ok if sloppy common practice happens in many Hackage packages. I do not need to use them. But I need to use 'base'. From schlepptop at henning-thielemann.de Mon Feb 24 20:36:35 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 21:36:35 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> Message-ID: <530BAD53.3050309@henning-thielemann.de> Am 24.02.2014 21:24, schrieb Dan Doel: > On Mon, Feb 24, 2014 at 2:56 PM, Casey McCann > wrote: > > Because it is a thoroughly irrelevant option, empirically speaking, on > account of approximately nobody actually using Data.Bits that way. > > > There's some reason for that, too. Bits has operators, which are > especially ugly when qualified, and I suspect most people are even more > annoyed by using two import statements to manage this than they are > about using qualified imports in the first place. For Data.Map we are used to write two import statements. It's not that uncommon. But I agree that qualification and infix operators don't work well together. That said, I am also not happy with 'rotate' and 'shift' being designed for infix use, since this way I cannot use (.) and ($) for composition of bit manipulations. From schlepptop at henning-thielemann.de Mon Feb 24 20:42:24 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 21:42:24 +0100 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> Message-ID: <530BAEB0.10606@henning-thielemann.de> Am 24.02.2014 20:56, schrieb Casey McCann: > As for the real question, I'd prefer something along the lines of > "clearedBits". Great, lets call it Bits.cleared, this would make sense with qualification and would not risk name clashes for unqualified use. This would serve both camps. From igloo at earth.li Mon Feb 24 21:12:38 2014 From: igloo at earth.li (Ian Lynagh) Date: Mon, 24 Feb 2014 21:12:38 +0000 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> Message-ID: <20140224211238.GA23749@matrix.chaos.earth.li> On Sat, Feb 22, 2014 at 02:51:24PM -0500, Anthony Cowley wrote: > I am -1 on the name zero. I don't think importing Data.Bits unqualified is uncommon at all, and zero is prime naming real estate. I am +0.5 on the addition overall, as most uses of Bits are with types that also have Num instances. For those that don't have a Num instance, "zero" may not make as much sense. Perhaps something like noBits would be better. And FiniteBits may also want an allBits? Thanks Ian From schlepptop at henning-thielemann.de Mon Feb 24 21:43:44 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 22:43:44 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530BAC00.3010402@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <530BBD10.4050300@henning-thielemann.de> Am 24.02.2014 21:30, schrieb Henning Thielemann: > For an example let me look at your lens package. You use unqualified and > implicit imports. That is according to the PVP you would need to use > tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you > don't. Sorry, it must be "containers >=0.4.0 && <0.5.1", but it is "containers >=0.4.0 && <0.6". From ekmett at gmail.com Mon Feb 24 21:53:21 2014 From: ekmett at gmail.com (Edward A Kmett) Date: Mon, 24 Feb 2014 16:53:21 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530BBD10.4050300@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530BBD10.4050300@henning-thielemann.de> Message-ID: <4D58D494-10BE-4EC0-AFA7-F24BFB9D1DF8@gmail.com> ...and I have had a half dozen problems caused by this policy in 5 years precisely because people are careful with their names in the packages I do depend upon. What I maintain now is approximately a full time job. Depending on minor versions and multiplying my workload by a nontrivial factor to eliminate a non-problem isn't going to happen. -Edward > On Feb 24, 2014, at 4:43 PM, Henning Thielemann wrote: > > Am 24.02.2014 21:30, schrieb Henning Thielemann: > >> For an example let me look at your lens package. You use unqualified and >> implicit imports. That is according to the PVP you would need to use >> tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you >> don't. > > Sorry, it must be "containers >=0.4.0 && <0.5.1", but it is "containers >=0.4.0 && <0.6". > From ekmett at gmail.com Mon Feb 24 22:00:23 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 24 Feb 2014 17:00:23 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <20140224211238.GA23749@matrix.chaos.earth.li> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> <20140224211238.GA23749@matrix.chaos.earth.li> Message-ID: Note: at least for Integer, allBits / oneBits is also definable, despite note being Finite On Mon, Feb 24, 2014 at 4:12 PM, Ian Lynagh wrote: > On Sat, Feb 22, 2014 at 02:51:24PM -0500, Anthony Cowley wrote: > > I am -1 on the name zero. I don't think importing Data.Bits unqualified > is uncommon at all, and zero is prime naming real estate. I am +0.5 on the > addition overall, as most uses of Bits are with types that also have Num > instances. > > For those that don't have a Num instance, "zero" may not make as much > sense. > > Perhaps something like noBits would be better. And FiniteBits may also > want an allBits? > > > Thanks > Ian > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Mon Feb 24 21:59:40 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Feb 2014 22:59:40 +0100 Subject: qualification of Data.Map (Was: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAD53.3050309@henning-thielemann.de> Message-ID: <530BC0CC.4070304@henning-thielemann.de> Am 24.02.2014 22:37, schrieb Casey McCann: > The need for qualification with Data.Map (and the modules it would > clash with) is a clear wart due to lacking appropriate type classes > for collections. You probably shouldn't use that to support your > point. That's an interesting point. However, I don't believe that there is an elegant solution to e.g. unify Map.insert and Set.insert using an advanced type class. I often see people trying to resolve name conflicts by type classes, often indicated by FlexibleInstances. I think this in turn is abuse. It is certainly ok to use (<>) for different types via the Monoid class, but already this one is difficult, because for Maps there are different sensible implementations. That is, we won't get rid from names with module dependend types, we cannot and should not resolve every conflict using type classes. There are many cases where the module system is the better tool than advanced type hacks. From gershomb at gmail.com Tue Feb 25 06:23:56 2014 From: gershomb at gmail.com (Gershom Bazerman) Date: Tue, 25 Feb 2014 01:23:56 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> <20140224211238.GA23749@matrix.chaos.earth.li> Message-ID: <530C36FC.6030405@gmail.com> The issue isn't about qualified or unqualified names at all. It is about names which express intent clearly and evocatively, and names which are unacceptably ambiguous. As such, I propose zero --> whereDidTheBitsGo and conversely, allBits --> iHaveAllTheBits It seems to me that these are expressive names with unmistakable meanings. -G On 2/24/14, 5:00 PM, Edward Kmett wrote: > Note: at least for Integer, allBits / oneBits is also definable, > despite note being Finite > > > On Mon, Feb 24, 2014 at 4:12 PM, Ian Lynagh > wrote: > > On Sat, Feb 22, 2014 at 02:51:24PM -0500, Anthony Cowley wrote: > > I am -1 on the name zero. I don't think importing Data.Bits > unqualified is uncommon at all, and zero is prime naming real > estate. I am +0.5 on the addition overall, as most uses of Bits > are with types that also have Num instances. > > For those that don't have a Num instance, "zero" may not make as much > sense. > > Perhaps something like noBits would be better. And FiniteBits may also > want an allBits? > > > Thanks > Ian > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Feb 25 06:44:45 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 25 Feb 2014 08:44:45 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530BAC00.3010402@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Mon, Feb 24, 2014 at 10:30 PM, Henning Thielemann < schlepptop at henning-thielemann.de> wrote: > Am 24.02.2014 20:56, schrieb Edward Kmett: > > As far as I know the only serious proponent of using qualified imports >> for all imports /all/ the time is you. >> > > First, there are some important packages like containers and bytestring > that clearly are intended for qualified imports, and I really like that > insertFM was replaced by Map.insert in the past. Second, your argument > addresses a person not the issue. > > Name conflicts don't affect you. We get that. We got that loud and clear >> virtually every time the naming of pretty much anything has arisen on >> this mailing list for the last few years. >> > > Sure, because there is no general discussion about the pros and cons of > various naming styles. That's why it is discussed for every single > identifier. How should a general discussion look like? What could be its > outcome? That I am no longer allowed to propose the qualified import style? > > That doesn't change the fact that your practice and common practice >> diverge. >> > > And I challenge the common practice, because it prefers convenience for > few package authors over convenience for many package user (that may not > even be a Haskell programmer). > > For an example let me look at your lens package. You use unqualified and > implicit imports. That is according to the PVP you would need to use tight > version bounds like "containers >=0.4.0 && <0.5.0.1", but you don't. That > is, your package does not conform to the PVP. It implies that users may > have to fix your package when one of the imported packages starts to export > identifiers that clash with those from "lens". Of course, there is no need > to conform to the PVP. But it works best if many people adhere to it. > > I have not written the PVP, that is, there must be at least one other > person who cares. I understand the need for it and try to comply to it. > Maybe I am in a minority. Looking at Hackage it seems I am in a minority. > But I believe I am in the minority who cares whether packages work > together. Shall I capitulate to the majority which does not seem to care > about package interoperability? > > I am also ok if sloppy common practice happens in many Hackage packages. I > do not need to use them. But I need to use 'base'. > > This email seems to conflate a number of different issues together. I'd like to address them separately. Firstly, regarding naming style. As I see it, there are essentially three camps on this one: 1. Short names that are intended to be imported qualified. Examples: Data.Map, Data.ByteString. 2. Longer names that can be imported unqualified. Examples: Data.IORef, Control.Concurrent.MVar. 3. Typeclass-based approaches that generalize across multiple libraries. Examples: Data.Foldable, Data.Traversable. The initial discussion came down to an argument between (1) and (2). What I disagree in your email Henning is the implication that this "sloppy practice" in base will somehow negatively affect you. As I see it, the sum total of negative effect is that you'll be required to type a few extra characters (e.g., zeroBits instead of zero). Am I missing something? Given that (a) a huge amount of base already works this way, (b) having the longer name will allow the unqualified import approach, and (c) it has a small impact on those wanting unqualified imports, I'd come down with a strong vote in favor of option (2). Next is the issue of PVP. I am someone who has stopped religiously following the PVP in the past few years. Your email seems to imply that only those following the PVP care about making sure that "packages work together." I disagree here; I don't use the PVP specifically because I care about package interoperability. The point of the PVP is to ensure that code builds. It's a purely compile-time concept. The PVP solves the problem of an update to a dependency causing a downstream package to break. And assuming everyone adheres to it[1], it ensures that cabal will never try to perform a build which isn't guaranteed to work. But that's only one half of the "package interoperability" issue. I face this first hand on a daily basis with my Stackage maintenance. I spend far more time reporting issues of restrictive upper bounds than I do with broken builds from upstream changes. So I look at this as purely a game of statistics: are you more likely to have code break because version 1.2 of text changes the type of the map function and you didn't have an upper bound, or because two dependencies of yours have *conflicting* versions bounds on a package like aeson[2]? In my experience, the latter occurs far more often than the former. My point here is: please don't try to frame this argument as "sloppy people who hate compatibility" versus "PVP-adhering people who make Hackage better." Some of us who have stopped following the PVP have done so for very principled reasons, even if you disagree with them. (And Edward's comments on maintenance effort is not to be ignored either.) Three final points: * I know that back in the base 3/4 transition there was good reason for upper bounds on base. Today, it makes almost no sense: it simply prevents cabal from even *trying* to perform a compilation. Same goes with libraries like array and template-haskell, which make up most of the issue with testing of GHC 7.8 Stackage builds[3]. Can any PVP proponent explain why these upper bounds still help us on corelibs? * If you're concerned about your production code base breaking by changes on Hackage, you're doing it wrong. Basing your entire production build on the presumption that Hackage maintainers perfectly follow the PVP and never make any mistakes in new releases of their packages is a recipe for disaster. You should be pinning down the exact versions of packages you depend on. Greg Weber described a technique for this[4]. * The PVP doesn't in any way solve all problems. You can perfectly adhere to the PVP and still experience breakage. I've seen a number of examples of this in the past, mostly to do with the fact that you don't lock down the versions of transitive dependencies, which can cause re-exports to include new functions or expose (or hide) typeclass instances. Michael [1] And never makes any mistakes of course. [2] This just occurred in Stackage. [3] https://github.com/fpco/stackage/issues/128 [4] http://blog.docmunch.com/blog/2013/haskell-version-lockdown -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Tue Feb 25 07:21:41 2014 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 25 Feb 2014 08:21:41 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530BAC00.3010402@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: 2014-02-24 21:30 GMT+01:00 Henning Thielemann : > [...] You use unqualified and > implicit imports. That is according to the PVP you would need to use tight > version bounds like "containers >=0.4.0 && <0.5.0.1", but you don't. That > is, your package does not conform to the PVP. [...] o_O Dumb question: Can somebody please explain why this doesn't conform to the PVP? I have a very hard time reading that out of http://www.haskell.org/haskellwiki/Package_versioning_policy. Perhaps I'm looking at the wrong document or this interpretation is just wishful thinking... Regarding upper bounds: I never understood what their advantage should be, IMHO they only lead to a version hell where you can't compile your stuff anymore *only* because of the bounds, not because of anything else. From daniel.trstenjak at gmail.com Tue Feb 25 07:43:52 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 25 Feb 2014 08:43:52 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <20140225074352.GA2812@machine> Hi Michael, > (b) having the longer name will allow the unqualified import approach ... The longer name just reduces the possibility of conflicts, which might be already sufficient and in the case of 'zeroBits' it might be really the right thing. I think the point of proponents of qualified imports is, that by having 'Bits.zero' instead of 'zeroBits' you're typing almost the same amount of characters, but the first solution is safer. I don't think that anybody would like to write 'Bits.zeroBits', sure you could still explicitly import 'zeroBits' and still have the same safety, but then you have more work with the imports, and at the end nobody wants to do more work and this seems to be the common ground of users and non users of qualified imports ;). > But that's only one half of the "package interoperability" issue. I face this > first hand on a daily basis with my Stackage maintenance. I spend far more time > reporting issues of restrictive upper bounds than I do with broken builds from > upstream changes. So I look at this as purely a game of statistics: are you > more likely to have code break because version 1.2 of text changes the type of > the map function and you didn't have an upper bound, or because two > dependencies of yours have *conflicting* versions bounds on a package like > aeson[2]? In my experience, the latter occurs far more often than the former. I mostly came to the conclusion, that the PVP is perfectly fine for binaries/executables, especially in conjunction with a cabal sandbox, but in a lot of cases annoying for libraries. Greetings, Daniel From jwlato at gmail.com Tue Feb 25 07:45:57 2014 From: jwlato at gmail.com (John Lato) Date: Mon, 24 Feb 2014 23:45:57 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Mon, Feb 24, 2014 at 11:21 PM, Sven Panne wrote: > > > Regarding upper bounds: I never understood what their advantage should > be, IMHO they only lead to a version hell where you can't compile your > stuff anymore *only* because of the bounds, not because of anything > else. IMHO this is a bad enough outcome, but it can also allow you to compile code in a way that it behaves incorrectly (if a function's behavior has changed but the type has not). It also leads to a situation where cabal generates what it thinks is an acceptable dependency solution, but that solution fails, making the user need to solve the dependency tree themselves and specify constraints on the cabal command line. This is reason the PVP specifies upper bounds on versions: it makes that work the responsibility of the developer rather than the user. At the time the PVP was introduced, users often experienced serious hardships when installing various combinations of packages, and IIRC it was widely perceived that developers should shoulder the load of making sure their packages would work together as specified. However, I think the PVP may have been a victim of its own success; user complaints about botched installs and invalid install plans seem quite rare these days, and some developers are pushing back against this extra workload. (or maybe there are no Haskell users?) John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Tue Feb 25 07:51:46 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 25 Feb 2014 08:51:46 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <20140225075146.GB2812@machine> Hi Sven, > o_O Dumb question: Can somebody please explain why this doesn't > conform to the PVP? I have a very hard time reading that out of > http://www.haskell.org/haskellwiki/Package_versioning_policy. Perhaps > I'm looking at the wrong document or this interpretation is just > wishful thinking... If I'm getting it right, you don't have to increase a major version number if you're e.g. just adding another function. But if the user of your library imports unqualified or implicit, then he will also get your added function and this function might conflict with functions in your code base. Greetings, Daniel From hvr at gnu.org Tue Feb 25 09:12:53 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 25 Feb 2014 10:12:53 +0100 Subject: qualified imports, PVP and so on In-Reply-To: (Michael Snoyman's message of "Tue, 25 Feb 2014 08:44:45 +0200") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <87bnxvtv1m.fsf@gnu.org> On 2014-02-25 at 07:44:45 +0100, Michael Snoyman wrote: [...] > * I know that back in the base 3/4 transition there was good reason for > upper bounds on base. Today, it makes almost no sense: it simply prevents > cabal from even *trying* to perform a compilation. Same goes with libraries > like array and template-haskell, which make up most of the issue with > testing of GHC 7.8 Stackage builds[3]. Can any PVP proponent explain why > these upper bounds still help us on corelibs? I assume by 'corelibs' you mean the set of non-upgradeble libs, i.e. those tied to the compiler version? (E.g. `bytestring` would be upgradeable, as opposed to `base` or `template-haskell`) Well, `base` (together with the other few non-upgradeable libs) is indeed a special case; also, in `base` usually care is taken to avoid semantic changes (not visible at the type-signature level), so an upper bound doesn't gain that much in terms of protecting against semantic breakages. Otoh, the situation changes if you have a library where you have different versions, which are tied to different version ranges of base, where you want Cabal to select the matching version. Admittedly, this is a special case for when use of MIN_VERSION_base() wouldn't suffice, but I wanted to give an example exploiting upper-bounds on the `base` lib. There's one other possible minor benefit I can think of, that upper bounds give over compile-errors, which is a more user-friendly message, to point to the reason of the failure, instead of requiring you guess what the actual cause of the compile-error was. But for non-upgradeable packages such as `base`, which do big major version jumps for almost every release (mostly due to changes in GHC modules exposing internals or adding type-class instances[1]), erring on the confusing-compile-error side seems to provide more value. So, as for `base` I mostly agree, that there seems to be little benefit for upper bounds, *unless* a base3/4 situation comes up again in the future. So, I'd suggest (for those who don't want to follow PVP with `base`) to keep using at least a "super"-major upper bound, such as 'base < 5' to leave a door open for such an eventuality. Cheers, hvr [1]: I'd argue (but I'd need research this, to back this up with numbers), that we're often suffering from the PVP, because it requires us to perform major-version jumps mostly due to typeclasses, in order to protect against conflicts with possible non-hideable orphan-instances; and that (as some have suggested in past already), we might want to reconsider requiring only a minor bump on instance-additions, and discourage the orphan-instance business by requiring those packages to have tighter-than-major upper-bounds From michael at snoyman.com Tue Feb 25 09:23:49 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 25 Feb 2014 11:23:49 +0200 Subject: qualified imports, PVP and so on In-Reply-To: <87bnxvtv1m.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <87bnxvtv1m.fsf@gnu.org> Message-ID: On Tue, Feb 25, 2014 at 11:12 AM, Herbert Valerio Riedel wrote: > On 2014-02-25 at 07:44:45 +0100, Michael Snoyman wrote: > > [...] > > > * I know that back in the base 3/4 transition there was good reason for > > upper bounds on base. Today, it makes almost no sense: it simply prevents > > cabal from even *trying* to perform a compilation. Same goes with > libraries > > like array and template-haskell, which make up most of the issue with > > testing of GHC 7.8 Stackage builds[3]. Can any PVP proponent explain why > > these upper bounds still help us on corelibs? > > I assume by 'corelibs' you mean the set of non-upgradeble libs, > i.e. those tied to the compiler version? (E.g. `bytestring` would be > upgradeable, as opposed to `base` or `template-haskell`) > > Yes, that's what I meant. I realize now corelibs wasn't the right term, but I don't think we *have* a correct term for this. I like your usage of upgradeable. > Well, `base` (together with the other few non-upgradeable libs) is > indeed a special case; also, in `base` usually care is taken to avoid > semantic changes (not visible at the type-signature level), so an upper > bound doesn't gain that much in terms of protecting against semantic > breakages. > > Otoh, the situation changes if you have a library where you have > different versions, which are tied to different version ranges of base, > where you want Cabal to select the matching version. Admittedly, this is > a special case for when use of MIN_VERSION_base() wouldn't suffice, but > I wanted to give an example exploiting upper-bounds on the `base` lib. > > That situation is technically possible, but highly unlikely to ever occur in practice. Consider what would have to happen: foo-1 is released, which works with base 4.5 and 4.6. It has a version bound base >= 4.5 && < 4.7. foo-2 is released, which only works with base 4.5. It changes its version bound to base >= 4.5 && < 4.6. In other words, a later release of the package would have to drop support for newer GHCs. The far more likely scenario to occur is where foo-1 simply didn't include upper bounds, and foo-2 adds them in. In that case, cabal will try to use foo-1, even though it won't anyway. Does anyone have an actual example of base or template-haskell upper bounds that provided benefit? > There's one other possible minor benefit I can think of, that upper > bounds give over compile-errors, which is a more user-friendly message, > to point to the reason of the failure, instead of requiring you guess > what the actual cause of the compile-error was. But for non-upgradeable > packages such as `base`, which do big major version jumps for almost > every release (mostly due to changes in GHC modules exposing internals > or adding type-class instances[1]), erring on the > confusing-compile-error side seems to provide more value. > > I'd actually argue that this is a disadvantage. It's true that we want users to have a good experience, but the *best* experience would be to let upstream packages get fixed. Imagine a common build error caused by the removal of `catch` from Prelude in base 4.6. With upper bounds, a user gets the error message "doesn't work with base 4.6" and reports to the package maintainer. The package maintainer then needs to download GHC and try to compile his package before getting any idea what the problem is (if there even *is* a problem!). With more verbose errors, a user could give a meaningful error message and, in many cases, a maintainer would be able to fix the problem without even needing to download a new version of the compiler. > So, as for `base` I mostly agree, that there seems to be little benefit > for upper bounds, *unless* a base3/4 situation comes up again in the > future. So, I'd suggest (for those who don't want to follow PVP with > `base`) to keep using at least a "super"-major upper bound, such as > 'base < 5' to leave a door open for such an eventuality. > > > Cheers, > hvr > > > [1]: I'd argue (but I'd need research this, to back this up with > numbers), that we're often suffering from the PVP, because it > requires us to perform major-version jumps mostly due to > typeclasses, in order to protect against conflicts with possible > non-hideable orphan-instances; and that (as some have suggested in > past already), we might want to reconsider requiring only a minor > bump on instance-additions, and discourage the orphan-instance > business by requiring those packages to have tighter-than-major > upper-bounds > +1, forcing major version bumps for each new instance just in case someone has an orphan instance is complete overkill. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue Feb 25 10:33:27 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 25 Feb 2014 12:33:27 +0200 Subject: Merge either into transformers Message-ID: <20140225103327.GA20172@sniper> Hi Ross, I proposed to merge either into transformers more than a year ago[1], and everyone seemed to agree. Could you please do it? [1]: http://www.haskell.org/pipermail/libraries/2012-December/019027.html Thanks, Roman From cam at uptoisomorphism.net Tue Feb 25 13:55:11 2014 From: cam at uptoisomorphism.net (Casey McCann) Date: Tue, 25 Feb 2014 08:55:11 -0500 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <530C36FC.6030405@gmail.com> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> <20140224211238.GA23749@matrix.chaos.earth.li> <530C36FC.6030405@gmail.com> Message-ID: On Tue, Feb 25, 2014 at 1:23 AM, Gershom Bazerman wrote: > The issue isn't about qualified or unqualified names at all. It is about > names which express intent clearly and evocatively, and names which are > unacceptably ambiguous. > > As such, I propose > > zero --> whereDidTheBitsGo > > and conversely, > > allBits --> iHaveAllTheBits > > It seems to me that these are expressive names with unmistakable meanings. Well, for names in that vein, I'd suggest notOneBit and everyLastBit. This avoids reinventing the wheel by relying on standard English idioms, and it's well-known that imitating the flawless logical structure of the English language is the highest goal for any programming language. - C. From mblazevic at stilo.com Tue Feb 25 15:00:23 2014 From: mblazevic at stilo.com (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=) Date: Tue, 25 Feb 2014 10:00:23 -0500 Subject: Merge either into transformers In-Reply-To: <20140225103327.GA20172@sniper> References: <20140225103327.GA20172@sniper> Message-ID: <530CB007.4090600@stilo.com> On 14-02-25 05:33 AM, Roman Cheplyaka wrote: > Hi Ross, > > I proposed to merge either into transformers more than a year ago[1], > and everyone seemed to agree. Could you please do it? > > [1]: http://www.haskell.org/pipermail/libraries/2012-December/019027.html While you're at it, Ross, the subsequent discussion led to another proposal which was also accepted (with some bikeshedding whose resolution was left to you) but never merged: http://www.haskell.org/pipermail/libraries/2012-December/019099.html Sorry to pile on, but I assume it's easier to merge both proposals at the same time. Perhaps this puts them over the actionable critical mass. Thanks. From allbery.b at gmail.com Tue Feb 25 15:12:29 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 25 Feb 2014 10:12:29 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman wrote: > But that's only one half of the "package interoperability" issue. I face > this first hand on a daily basis with my Stackage maintenance. I spend far > more time reporting issues of restrictive upper bounds than I do with > broken builds from upstream changes. So I look at this as purely a game of > statistics: are you more likely to have code break because version 1.2 of > text changes the type of the map function and you didn't have an upper > bound, or because two dependencies of yours have *conflicting* versions > bounds on a package like aeson[2]? In my experience, the latter occurs far > more often than the former. I have a question for you. Is it better to save a developer some work, or is it better to force that work onto end users? Because we keep constantly seeing examples where saving the developer some upper bounds PVP work forces users to deal with unexpected errors, but since Haskell developers don't see that user pain it is considered irrelevant/nonexistent and certainly not any justification for saving developers some work. Personally, I think any ecosystem which strongly prefers pushing versioning pain points onto end users instead of developers is doing itself a severe disservice. Are there things that could be improved about versioning policy? Absolutely. But pushing problems onto end users is not an improvement. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Feb 25 15:16:59 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 25 Feb 2014 10:16:59 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 2:21 AM, Sven Panne wrote: > Regarding upper bounds: I never understood what their advantage should > be, IMHO they only lead to a version hell where you can't compile your > stuff anymore *only* because of the bounds, not because of anything > else. > A couple months ago we had yet another example of "that will never happen" caused by people ignoring upper bounds. Developers never saw any problem, of course; and who cares about all the users who had compiles explode with unexpected errors? I think it took less than two weeks after someone patched up the most visibly affected packages before developers were shouting to remove upper bounds from the PVP again, because the affected users are just users and apparently not important enough to consider when setting versioning policy. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Feb 25 15:19:58 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 25 Feb 2014 10:19:58 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <20140225075146.GB2812@machine> References: <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <20140225075146.GB2812@machine> Message-ID: On Tue, Feb 25, 2014 at 2:51 AM, Daniel Trstenjak < daniel.trstenjak at gmail.com> wrote: > > Hi Sven, > > > o_O Dumb question: Can somebody please explain why this doesn't > > conform to the PVP? I have a very hard time reading that out of > > http://www.haskell.org/haskellwiki/Package_versioning_policy. Perhaps > > I'm looking at the wrong document or this interpretation is just > > wishful thinking... > > If I'm getting it right, you don't have to increase a major version > number if you're e.g. just adding another function. > > But if the user of your library imports unqualified or implicit, > then he will also get your added function and this function might > conflict with functions in your code base. Note: this particular concern would be much lessened at least for local definitions, had we done anything with Lennart's perfectly reasonable suggestion to change the scoping rules to let local definitions win over imports. When I mentioned above that I had had half a dozen problems in five years, four of them would have been resolved successfully by that proposal. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From omari at smileystation.com Tue Feb 25 15:26:56 2014 From: omari at smileystation.com (Omari Norman) Date: Tue, 25 Feb 2014 10:26:56 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 10:16 AM, Brandon Allbery wrote: > because the affected users are just > users and apparently not important enough to consider when setting > versioning policy. Users are important enough to consider, but their needs should not trump all others. In particular, (nearly?) all software on Hackage is given to users at no charge. Developers invest their time. Their needs are important too. If policies make it too troublesome for developers to maintain software or publicly post it on Hackage, they will just stop posting it. Obviously there is a balance to be struck, as if you make things too hard for users then there will be no users. The problem is that the PVP is putting a considerable maintenance burden on developers but it's not even clear there is commensurate benefit to users. Often it's hard to get different packages to work together because upper bounds are too tight. From twanvl at gmail.com Tue Feb 25 15:28:19 2014 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue, 25 Feb 2014 16:28:19 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <530CB693.8060605@gmail.com> On 25/02/14 16:12, Brandon Allbery wrote: > On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman > wrote: > > But that's only one half of the "package interoperability" issue. I face > this first hand on a daily basis with my Stackage maintenance. I spend far > more time reporting issues of restrictive upper bounds than I do with broken > builds from upstream changes. So I look at this as purely a game of > statistics: are you more likely to have code break because version 1.2 of > text changes the type of the map function and you didn't have an upper > bound, or because two dependencies of yours have *conflicting* versions > bounds on a package like aeson[2]? In my experience, the latter occurs far > more often than the former. > > > I have a question for you. > > Is it better to save a developer some work, or is it better to force that work > onto end users? > > Because we keep constantly seeing examples where saving the developer some upper > bounds PVP work forces users to deal with unexpected errors, but since Haskell > developers don't see that user pain it is considered irrelevant/nonexistent and > certainly not any justification for saving developers some work. > > Personally, I think any ecosystem which strongly prefers pushing versioning pain > points onto end users instead of developers is doing itself a severe disservice. > > Are there things that could be improved about versioning policy? Absolutely. But > pushing problems onto end users is not an improvement. Strict upper bounds are horrible when a new version of, say, the base library comes out. In reality 90% of the code will not break, it will just require a new release with increased version bounds. These upper bounds actually *hurt* users, because they suddenly couldn't use half of Hackage. This reminds me of the situation of Firefox extensions. In earlier versions of the browser these came with strict upper bounds, saying "I work in Firefox 11 up to 13". But then every month or so when a new version came out, all extensions would stop working. Newer versions of the browser have switched to an 'assume it works' model, where problems are reported and only then will the extension be disabled. So, violating upper-bounds should be a warning at most, perhaps for some kind of loose 'tested-with' upper bound. Additionally, we need a way to report build successes and failures to Hackage, and automatically update these 'tested-with' upper bounds. In other words, make a distinction between upper bounds violations that mean "not known to work with versions >X" and "known not to work with versions >X". Twan From ekmett at gmail.com Tue Feb 25 15:33:51 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 25 Feb 2014 10:33:51 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 10:16 AM, Brandon Allbery wrote: > On Tue, Feb 25, 2014 at 2:21 AM, Sven Panne wrote: > >> Regarding upper bounds: I never understood what their advantage should >> be, IMHO they only lead to a version hell where you can't compile your >> stuff anymore *only* because of the bounds, not because of anything >> else. >> > > A couple months ago we had yet another example of "that will never happen" > caused by people ignoring upper bounds. Developers never saw any problem, > of course; and who cares about all the users who had compiles explode with > unexpected errors? I think it took less than two weeks after someone > patched up the most visibly affected packages before developers were > shouting to remove upper bounds from the PVP again, because the affected > users are just users and apparently not important enough to consider when > setting versioning policy. > I tried living without upper bounds. My attempt was not motivated out of disdain for users, but from the fact that all of the complaints I had had had been about the opposite, constraints that were too tight. The change was motivate largely by a desire to *improve* end user experience. However, after removing the bounds, the situations users wound up in were very hard to fix. From a POSIWID perspective, the purpose of removing upper bounds is to make Haskell nigh unusable without sandboxing or --force. Consequently, I reverted to PVP compliance within a month. Yes, compliance. Despite Henning's attempt to grab the moral high ground there, the PVP does not *require* the use of qualified imports to depend on minor versions, it merely indicates that doing so is a slight risk. To minimize breakage when new package versions are released, you can use > dependencies that are insensitive to minor version changes (e.g. foo >= > 1.2.1 && < 1.3). However, note that this approach is slightly risky: when > a package exports more things than before, there is a chance that your code > will fail to compile due to new name-clash errors. The risk from new name > clashes may be small, but you are on the safe side if you import > identifiers explicitly or using qualification > . -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Tue Feb 25 15:38:42 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 25 Feb 2014 16:38:42 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <20140225153842.GA10245@machine> Hi Brandon, On Tue, Feb 25, 2014 at 10:12:29AM -0500, Brandon Allbery wrote: > Is it better to save a developer some work, or is it better to force that work > onto end users? What is an end user? Someone installing a package containing an executable? Then the package is an end point in the dependency graph and the PVP can work pretty well for this case. But if the package contains a library, then the end user is also the developer, so you can only choose which kind of pain you prefer. > Because we keep constantly seeing examples where saving the developer some > upper bounds PVP work forces users to deal with unexpected errors, but since > Haskell developers don't see that user pain it is considered irrelevant/ > nonexistent and certainly not any justification for saving developers some > work. I think that in most cases it doesn't really make much difference for the end user, if they're seeing a package version mismatch or if they're seeing a compile error. Sure, the package version mismatch is more telling, but in most cases he will be equally lost and has to ask for help. Greetings, Daniel From michael at snoyman.com Tue Feb 25 16:09:59 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 25 Feb 2014 18:09:59 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 5:12 PM, Brandon Allbery wrote: > On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman wrote: > >> But that's only one half of the "package interoperability" issue. I face >> this first hand on a daily basis with my Stackage maintenance. I spend far >> more time reporting issues of restrictive upper bounds than I do with >> broken builds from upstream changes. So I look at this as purely a game of >> statistics: are you more likely to have code break because version 1.2 of >> text changes the type of the map function and you didn't have an upper >> bound, or because two dependencies of yours have *conflicting* versions >> bounds on a package like aeson[2]? In my experience, the latter occurs far >> more often than the former. > > > I have a question for you. > > Is it better to save a developer some work, or is it better to force that > work onto end users? > > Because we keep constantly seeing examples where saving the developer > some upper bounds PVP work forces users to deal with unexpected errors, but > since Haskell developers don't see that user pain it is considered > irrelevant/nonexistent and certainly not any justification for saving > developers some work. > > Personally, I think any ecosystem which strongly prefers pushing > versioning pain points onto end users instead of developers is doing itself > a severe disservice. > > Are there things that could be improved about versioning policy? > Absolutely. But pushing problems onto end users is not an improvement. > > I think it's a false dichotomy. I've received plenty of complaints from users about being unable to install newer versions of some dependency because a library that Yesod depends on has an unnecessary strict upper bound. Are there situations where the PVP saves a user some pain? Yes. Are there situations where the PVP causes a user some pain? Yes. It's disingenuous to frame this as a black and white "developer vs user" issue, it's far more complex than that. After a lot of experience, I believe the PVP- or at least strict adherence to it- is a net loss. And I think the *real* solution is something like Stackage, where curators have taken care of the versioning pain points instead of either developers or end users. Linux distributions have been doing this for a long time. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Feb 25 16:33:04 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 25 Feb 2014 11:33:04 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <20140225153842.GA10245@machine> References: <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <20140225153842.GA10245@machine> Message-ID: On Tue, Feb 25, 2014 at 10:38 AM, Daniel Trstenjak < daniel.trstenjak at gmail.com> wrote: > On Tue, Feb 25, 2014 at 10:12:29AM -0500, Brandon Allbery wrote: > > Is it better to save a developer some work, or is it better to force > that work > > onto end users? > > What is an end user? Someone installing a package containing an executable? > Then the package is an end point in the dependency graph and the PVP can > work pretty well for this case. > > But if the package contains a library, then the end user is also the > developer, so you can only choose which kind of pain you prefer. *A* developer, but not the developer of the package with the loose upper bound or the package that refused to compile with incomprehensible errors because of it, and generally not in a position to recognize the reason for the errors because they don't know the internals of the package they're trying to use. And I am certain of this because I'm sitting in #haskell fielding questions from them multiple times a day when some package gets broken by an overly lax or missing upper bound. Also note that overly strict versioning certainly also leads to breakage --- but it's reported clearly by cabal as a version issue, not as ghc vomiting up unexpected errors from something that is presented as a curated package that should build without problems. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Feb 25 16:38:40 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 25 Feb 2014 11:38:40 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: This thread is kinda missing an important point. Namely that on hackage now, the admins and trustees have the power to edit the cabal files to fix broken constraints. (As do maintainers of their own packages) Whether relaxing incorrectly conservative or over strengthening overly lax constraints, this now doesn't require a rerelease to "fix". There are valid reasons of provinence for why that might not make sense in all case Unless I'm missing the point, doesn't that solve most of the matter? -carter On Tuesday, February 25, 2014, Michael Snoyman wrote: > > > > On Tue, Feb 25, 2014 at 5:12 PM, Brandon Allbery > > wrote: > >> On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman >> > wrote: >> >>> But that's only one half of the "package interoperability" issue. I face >>> this first hand on a daily basis with my Stackage maintenance. I spend far >>> more time reporting issues of restrictive upper bounds than I do with >>> broken builds from upstream changes. So I look at this as purely a game of >>> statistics: are you more likely to have code break because version 1.2 of >>> text changes the type of the map function and you didn't have an upper >>> bound, or because two dependencies of yours have *conflicting* versions >>> bounds on a package like aeson[2]? In my experience, the latter occurs far >>> more often than the former. >> >> >> I have a question for you. >> >> Is it better to save a developer some work, or is it better to force that >> work onto end users? >> >> Because we keep constantly seeing examples where saving the developer >> some upper bounds PVP work forces users to deal with unexpected errors, but >> since Haskell developers don't see that user pain it is considered >> irrelevant/nonexistent and certainly not any justification for saving >> developers some work. >> >> Personally, I think any ecosystem which strongly prefers pushing >> versioning pain points onto end users instead of developers is doing itself >> a severe disservice. >> >> Are there things that could be improved about versioning policy? >> Absolutely. But pushing problems onto end users is not an improvement. >> >> > I think it's a false dichotomy. I've received plenty of complaints from > users about being unable to install newer versions of some dependency > because a library that Yesod depends on has an unnecessary strict upper > bound. Are there situations where the PVP saves a user some pain? Yes. Are > there situations where the PVP causes a user some pain? Yes. > > It's disingenuous to frame this as a black and white "developer vs user" > issue, it's far more complex than that. After a lot of experience, I > believe the PVP- or at least strict adherence to it- is a net loss. > > And I think the *real* solution is something like Stackage, where curators > have taken care of the versioning pain points instead of either developers > or end users. Linux distributions have been doing this for a long time. > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Feb 25 16:58:16 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 25 Feb 2014 18:58:16 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 6:38 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > This thread is kinda missing an important point. > > Namely that on hackage now, the admins and trustees have the power to edit > the cabal files to fix broken constraints. (As do maintainers of their own > packages) > > Whether relaxing incorrectly conservative or over strengthening overly lax > constraints, this now doesn't require a rerelease to "fix". There are > valid reasons of provinence for why that might not make sense in all case > > Unless I'm missing the point, doesn't that solve most of the matter? > -carter > > > The question would still remain: who's responsible for making those changes, and what is the default position for the version bounds? We could default to leaving version bounds off, and add them after the fact as necessary. This would reduce developer and Hackage maintainer overhead, but some users may get the "scary" error messages[1]. Or we could default to the PVP approach, and then increase the work on developers/maintainers, with the flip side that (1) users will never get the "scary" error messages, and (2) until developers/maintainers make the change, users may be blocked from even attempting to compile packages together. There's also the issue that, currently, Hackage2 has turned off developer abilities to change version bounds, so all of the version tweaking onus would fall to admins and trustees. Overall, I don't see this as a big improvement over the PVP status quo. It's not any harder for me to upload version 1.0.2.1 of a package with a tweaked version bound than to go to the Hackage web interface and manually edit version 1.0.2's cabal file. What I see the editing feature as very useful for is if we want to add upper bounds after the fact. Michael [1] Which I still think have value, since they are far more informative to a package author. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Tue Feb 25 17:05:51 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 25 Feb 2014 18:05:51 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: I believe this feature is currently turned off, because it comes with its own set of problems. Erik On Feb 25, 2014 5:38 PM, "Carter Schonwald" wrote: > This thread is kinda missing an important point. > > Namely that on hackage now, the admins and trustees have the power to edit > the cabal files to fix broken constraints. (As do maintainers of their own > packages) > > Whether relaxing incorrectly conservative or over strengthening overly lax > constraints, this now doesn't require a rerelease to "fix". There are > valid reasons of provinence for why that might not make sense in all case > > Unless I'm missing the point, doesn't that solve most of the matter? > -carter > > On Tuesday, February 25, 2014, Michael Snoyman > wrote: > >> >> >> >> On Tue, Feb 25, 2014 at 5:12 PM, Brandon Allbery wrote: >> >>> On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman wrote: >>> >>>> But that's only one half of the "package interoperability" issue. I >>>> face this first hand on a daily basis with my Stackage maintenance. I spend >>>> far more time reporting issues of restrictive upper bounds than I do with >>>> broken builds from upstream changes. So I look at this as purely a game of >>>> statistics: are you more likely to have code break because version 1.2 of >>>> text changes the type of the map function and you didn't have an upper >>>> bound, or because two dependencies of yours have *conflicting* versions >>>> bounds on a package like aeson[2]? In my experience, the latter occurs far >>>> more often than the former. >>> >>> >>> I have a question for you. >>> >>> Is it better to save a developer some work, or is it better to force >>> that work onto end users? >>> >>> Because we keep constantly seeing examples where saving the developer >>> some upper bounds PVP work forces users to deal with unexpected errors, but >>> since Haskell developers don't see that user pain it is considered >>> irrelevant/nonexistent and certainly not any justification for saving >>> developers some work. >>> >>> Personally, I think any ecosystem which strongly prefers pushing >>> versioning pain points onto end users instead of developers is doing itself >>> a severe disservice. >>> >>> Are there things that could be improved about versioning policy? >>> Absolutely. But pushing problems onto end users is not an improvement. >>> >>> >> I think it's a false dichotomy. I've received plenty of complaints from >> users about being unable to install newer versions of some dependency >> because a library that Yesod depends on has an unnecessary strict upper >> bound. Are there situations where the PVP saves a user some pain? Yes. Are >> there situations where the PVP causes a user some pain? Yes. >> >> It's disingenuous to frame this as a black and white "developer vs user" >> issue, it's far more complex than that. After a lot of experience, I >> believe the PVP- or at least strict adherence to it- is a net loss. >> >> And I think the *real* solution is something like Stackage, where >> curators have taken care of the versioning pain points instead of either >> developers or end users. Linux distributions have been doing this for a >> long time. >> >> Michael >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Tue Feb 25 17:17:04 2014 From: tab at snarc.org (Vincent Hanquez) Date: Tue, 25 Feb 2014 17:17:04 +0000 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <530CD010.1030607@snarc.org> On 2014-02-25 15:12, Brandon Allbery wrote: > On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman > wrote: > > But that's only one half of the "package interoperability" issue. > I face this first hand on a daily basis with my Stackage > maintenance. I spend far more time reporting issues of restrictive > upper bounds than I do with broken builds from upstream changes. > So I look at this as purely a game of statistics: are you more > likely to have code break because version 1.2 of text changes the > type of the map function and you didn't have an upper bound, or > because two dependencies of yours have *conflicting* versions > bounds on a package like aeson[2]? In my experience, the latter > occurs far more often than the former. > > > I have a question for you. > > Is it better to save a developer some work, or is it better to force > that work onto end users? > As a *user* of many libraries, I had more problems with libraries that follow the PvP religiously than the other way around. I usually like to have the latest and greatest libraries, specially text, aeson, and such, and there I have to manually bump dependencies of packages I depend on, until the developers gets to update the package on hackage (which sometimes takes many weeks). As a *developer*, following the PvP would cost me a lot of my *free* time. This is particularly true when the surface of contact with a library is small, it's very unlikely that I will run into an API changes. When I do, I release a new package quickly that account for the API change, or I can put a upper bounds if I can't make the necessary changes quickly enough. I usually found out quite quickly with stackage nowadays, most of times, before any users get bitten. Some other time, I'm testing some development ghc or some new unreleased libraries, and I need to remove upper bounds from packages so that I can test something. Anyway, there's lots of reason that the PvP doesn't works fully. It solves some problems for sure, but sadly swipe all the other problems under the carpet. One problem being that a single set of numbers doesn't properly account for API complexity and stability that might differ in different modules of the same package. -- Vincent From carter.schonwald at gmail.com Tue Feb 25 17:26:34 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 25 Feb 2014 12:26:34 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530CD010.1030607@snarc.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530CD010.1030607@snarc.org> Message-ID: indeed. So lets think about how to add module types or some approximation thereof to GHC? (seriously, thats the only sane "best solution" i can think of, but its not something that can be done casually). Theres also the fact that any module system design will have to explicitly deal with type class instances in a more explicit fashion than we've done thus far. On Tue, Feb 25, 2014 at 12:17 PM, Vincent Hanquez wrote: > On 2014-02-25 15:12, Brandon Allbery wrote: > > On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman > michael at snoyman.com>> wrote: >> >> But that's only one half of the "package interoperability" issue. >> I face this first hand on a daily basis with my Stackage >> maintenance. I spend far more time reporting issues of restrictive >> upper bounds than I do with broken builds from upstream changes. >> So I look at this as purely a game of statistics: are you more >> likely to have code break because version 1.2 of text changes the >> type of the map function and you didn't have an upper bound, or >> because two dependencies of yours have *conflicting* versions >> bounds on a package like aeson[2]? In my experience, the latter >> occurs far more often than the former. >> >> >> I have a question for you. >> >> Is it better to save a developer some work, or is it better to force that >> work onto end users? >> >> As a *user* of many libraries, I had more problems with libraries that > follow the PvP religiously than the other way around. I usually like to > have the latest and greatest libraries, specially text, aeson, and such, > and there I have to manually bump dependencies of packages I depend on, > until the developers gets to update the package on hackage (which sometimes > takes many weeks). > > As a *developer*, following the PvP would cost me a lot of my *free* time. > This is particularly true when the surface of contact with a library is > small, it's very unlikely that I will run into an API changes. When I do, I > release a new package quickly that account for the API change, or I can put > a upper bounds if I can't make the necessary changes quickly enough. I > usually found out quite quickly with stackage nowadays, most of times, > before any users get bitten. > > Some other time, I'm testing some development ghc or some new unreleased > libraries, and I need to remove upper bounds from packages so that I can > test something. > > Anyway, there's lots of reason that the PvP doesn't works fully. It solves > some problems for sure, but sadly swipe all the other problems under the > carpet. One problem being that a single set of numbers doesn't properly > account for API complexity and stability that might differ in different > modules of the same package. > > -- > Vincent > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Feb 25 17:27:36 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 25 Feb 2014 12:27:36 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: This is currently disabled if you go to try it. On Tue, Feb 25, 2014 at 11:38 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > This thread is kinda missing an important point. > > Namely that on hackage now, the admins and trustees have the power to edit > the cabal files to fix broken constraints. (As do maintainers of their own > packages) > > Whether relaxing incorrectly conservative or over strengthening overly lax > constraints, this now doesn't require a rerelease to "fix". There are > valid reasons of provinence for why that might not make sense in all case > > Unless I'm missing the point, doesn't that solve most of the matter? > -carter > > > On Tuesday, February 25, 2014, Michael Snoyman > wrote: > >> >> >> >> On Tue, Feb 25, 2014 at 5:12 PM, Brandon Allbery wrote: >> >>> On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman wrote: >>> >>>> But that's only one half of the "package interoperability" issue. I >>>> face this first hand on a daily basis with my Stackage maintenance. I spend >>>> far more time reporting issues of restrictive upper bounds than I do with >>>> broken builds from upstream changes. So I look at this as purely a game of >>>> statistics: are you more likely to have code break because version 1.2 of >>>> text changes the type of the map function and you didn't have an upper >>>> bound, or because two dependencies of yours have *conflicting* versions >>>> bounds on a package like aeson[2]? In my experience, the latter occurs far >>>> more often than the former. >>> >>> >>> I have a question for you. >>> >>> Is it better to save a developer some work, or is it better to force >>> that work onto end users? >>> >>> Because we keep constantly seeing examples where saving the developer >>> some upper bounds PVP work forces users to deal with unexpected errors, but >>> since Haskell developers don't see that user pain it is considered >>> irrelevant/nonexistent and certainly not any justification for saving >>> developers some work. >>> >>> Personally, I think any ecosystem which strongly prefers pushing >>> versioning pain points onto end users instead of developers is doing itself >>> a severe disservice. >>> >>> Are there things that could be improved about versioning policy? >>> Absolutely. But pushing problems onto end users is not an improvement. >>> >>> >> I think it's a false dichotomy. I've received plenty of complaints from >> users about being unable to install newer versions of some dependency >> because a library that Yesod depends on has an unnecessary strict upper >> bound. Are there situations where the PVP saves a user some pain? Yes. Are >> there situations where the PVP causes a user some pain? Yes. >> >> It's disingenuous to frame this as a black and white "developer vs user" >> issue, it's far more complex than that. After a lot of experience, I >> believe the PVP- or at least strict adherence to it- is a net loss. >> >> And I think the *real* solution is something like Stackage, where >> curators have taken care of the versioning pain points instead of either >> developers or end users. Linux distributions have been doing this for a >> long time. >> >> Michael >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From R.Paterson at city.ac.uk Tue Feb 25 17:40:05 2014 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Tue, 25 Feb 2014 17:40:05 +0000 Subject: Merge either into transformers In-Reply-To: <20140225103327.GA20172@sniper> References: <20140225103327.GA20172@sniper> Message-ID: <20140225174005.GA11523@city.ac.uk> On Tue, Feb 25, 2014 at 12:33:27PM +0200, Roman Cheplyaka wrote: > I proposed to merge either into transformers more than a year ago[1], > and everyone seemed to agree. Could you please do it? > > [1]: http://www.haskell.org/pipermail/libraries/2012-December/019027.html Not everyone agreed when we discussed this last August. My proposal then was to introduce a new constructor ExceptT on the same pattern as ReaderT, etc, and to deprecate ErrorT, and that's what I intend to include in the next major release, after GHC 7.8 comes out. From greg at gregorycollins.net Tue Feb 25 19:23:44 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 25 Feb 2014 11:23:44 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Mon, Feb 24, 2014 at 10:44 PM, Michael Snoyman wrote: > But that's only one half of the "package interoperability" issue. I face > this first hand on a daily basis with my Stackage maintenance. I spend far > more time reporting issues of restrictive upper bounds than I do with > broken builds from upstream changes. So I look at this as purely a game of > statistics: are you more likely to have code break because version 1.2 of > text changes the type of the map function and you didn't have an upper > bound, or because two dependencies of yours have *conflicting* versions > bounds on a package like aeson[2]? In my experience, the latter occurs far > more often than the former. That's because you maintain a lot of packages, and you're considering buildability on short time frames (i.e. you mostly care about "does all the latest stuff build right now?"). The consequences of violating the PVP are that as a piece of code ages, the probability that it still builds goes to *zero*, even if you go and dig out the old GHC version that you were using at the time. I find this really unacceptable, and believe that people who are choosing not to be compliant with the policy are BREAKING HACKAGE and making life harder for everyone by trading convenience now for guaranteed pain later. In fact, in my opinion the server ought to be machine-checking PVP compliance and refusing to accept packages that don't obey the policy. Like Ed said, this is pretty cut and dried: we have a policy, you're choosing not to follow it, you're not in compliance, you're breaking stuff. We can have a discussion about changing the policy (and this has definitely been discussed to death before), but I don't think your side has the required consensus/votes needed to change the policy. As such, I really wish that you would reconsider your stance here. I've long maintained that the solution to this issue should be tooling. The dependency graph that you stipulate in your cabal file should be a *warrant* that "this package is known to be compatible with these versions of these packages". If a new major version of package "foo" comes out, a bumper tool should be able to try relaxing the dependency and seeing if your package still builds, bumping your version number accordingly based on the PVP rules. Someone released a tool to attempt to do this a couple of days ago --- I haven't tried it yet but surely with a bit of group effort we can improve these tools so that they really fast and easy to use. Of course, people who want to follow PVP are also going to need tooling to make sure their programs still build in the future because so many people have broken the policy in the past -- that's where proposed kludges like "cabal freeze" are going to come in. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Tue Feb 25 20:17:57 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 25 Feb 2014 21:17:57 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <20140225201757.GA20851@machine> On Tue, Feb 25, 2014 at 11:23:44AM -0800, Gregory Collins wrote: > Someone released a tool to attempt to do this a couple of days ago --- > I haven't tried it yet but surely with a bit of group effort we can > improve these tools so that they really fast and easy to use. That's an amazing tool ... ;) > Of course, people who want to follow PVP are also going to need tooling to make > sure their programs still build in the future because so many people have > broken the policy in the past -- that's where proposed kludges like "cabal > freeze" are going to come in. If I understood it correctly, then cabal >1.19 supports the option '--allow-newer' to be able to ignore upper bounds, which might solve several of the issues here, so upper bounds could be set but still ignored if desired. Greetings, Daniel From ekmett at gmail.com Tue Feb 25 20:26:43 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 25 Feb 2014 15:26:43 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <20140225201757.GA20851@machine> References: <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <20140225201757.GA20851@machine> Message-ID: It alleviates the common case, but it doesn't resolve the scenario where someone put a hard bound in for a reason due to a known change in semantics or known incompatibility. On Tue, Feb 25, 2014 at 3:17 PM, Daniel Trstenjak < daniel.trstenjak at gmail.com> wrote: > > On Tue, Feb 25, 2014 at 11:23:44AM -0800, Gregory Collins wrote: > > Someone released a tool to attempt to do this a couple of days ago --- > > I haven't tried it yet but surely with a bit of group effort we can > > improve these tools so that they really fast and easy to use. > > That's an amazing tool ... ;) > > > Of course, people who want to follow PVP are also going to need tooling > to make > > sure their programs still build in the future because so many people have > > broken the policy in the past -- that's where proposed kludges like > "cabal > > freeze" are going to come in. > > If I understood it correctly, then cabal >1.19 supports the option > '--allow-newer' > to be able to ignore upper bounds, which might solve several of the issues > here, > so upper bounds could be set but still ignored if desired. > > > Greetings, > Daniel > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Feb 25 20:38:38 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 25 Feb 2014 22:38:38 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 9:23 PM, Gregory Collins wrote: > > On Mon, Feb 24, 2014 at 10:44 PM, Michael Snoyman wrote: > >> But that's only one half of the "package interoperability" issue. I face >> this first hand on a daily basis with my Stackage maintenance. I spend far >> more time reporting issues of restrictive upper bounds than I do with >> broken builds from upstream changes. So I look at this as purely a game of >> statistics: are you more likely to have code break because version 1.2 of >> text changes the type of the map function and you didn't have an upper >> bound, or because two dependencies of yours have *conflicting* versions >> bounds on a package like aeson[2]? In my experience, the latter occurs far >> more often than the former. > > > That's because you maintain a lot of packages, and you're considering > buildability on short time frames (i.e. you mostly care about "does all the > latest stuff build right now?"). The consequences of violating the PVP are > that as a piece of code ages, the probability that it still builds goes to > *zero*, even if you go and dig out the old GHC version that you were > using at the time. I find this really unacceptable, and believe that people > who are choosing not to be compliant with the policy are BREAKING HACKAGE > and making life harder for everyone by trading convenience now for > guaranteed pain later. In fact, in my opinion the server ought to be > machine-checking PVP compliance and refusing to accept packages that don't > obey the policy. > > Like Ed said, this is pretty cut and dried: we have a policy, you're > choosing not to follow it, you're not in compliance, you're breaking stuff. > We can have a discussion about changing the policy (and this has definitely > been discussed to death before), but I don't think your side has the > required consensus/votes needed to change the policy. As such, I really > wish that you would reconsider your stance here. > > I really don't like this appeal to authority. I don't know who the "royal we" is that you are referring to here, and I don't accept the premise that the rest of us must simply adhere to a policy because "it was decided." "My side" as you refer to it is giving concrete negative consequences to the PVP. I'd expect "your side" to respond in kind, not simply assert that we're "breaking Hackage" and other such hyperbole. Now, I think I understand what you're alluding to. Assuming I understand you correctly, I think you're advocating irresponsible development. I have codebases which I maintain and which use older versions of packages. I know others who do the same. The rule for this is simple: if your development process only works by assuming third parties to adhere to some rules you've established, you're in for a world of hurt. You're correct: if everyone rigidly followed the PVP, *and* no one every made any mistakes, *and* the PVP solved all concerns, then you could get away with the development practices you're talking about. But that's not the real world. In the real world: * The PVP itself does *not* guarantee reliable builds in all cases. If a transitive dependency introduces new exports, or provides new typeclass instances, a fully PVP-compliant stack can be broken. (If anyone doubts this claim, let me know, I can spell out the details. This has come up in practice.) * People make mistakes. I've been bitten by people making breaking changes in point releases by mistake. If the only way your build will succeed is by assuming no one will ever mess up, you're in trouble. * Just because your code *builds*, doesn't mean your code *works*. Semantics can change: bugs can be introduced, bugs that you depended upon can be resolved, performance characteristics can change in breaking ways, etc. I absolutely believe that, if you want to have code that builds reliably, you have to specify all of your deep dependencies. That's what I do for any production software, and it's what I recommend to anyone who will listen to me. Trying to push this off as a responsibility of every Hackage package author is (1) shifting the burden to the wrong place, and (2) irresponsible, since some maintainer out in the rest of the world has no obligation to make sure your code keeps working. That's your responsibility. > I've long maintained that the solution to this issue should be tooling. > The dependency graph that you stipulate in your cabal file should be a > *warrant* that "this package is known to be compatible with these versions > of these packages". If a new major version of package "foo" comes out, a > bumper tool should be able to try relaxing the dependency and seeing if > your package still builds, bumping your version number accordingly based on > the PVP rules. Someone released a tool to attempt to do this a couple of > days ago --- I haven't tried it yet but surely with a bit of group effort > we can improve these tools so that they really fast and easy to use. > > Of course, people who want to follow PVP are also going to need tooling to > make sure their programs still build in the future because so many people > have broken the policy in the past -- that's where proposed kludges like > "cabal freeze" are going to come in. > > This is where we apparently fundamentally disagree. cabal freeze IMO is not at all a kludge. It's the only sane approach to reliable builds. If I ran my test suite against foo version 1.0.1, performed manual testing on 1.0.1, did my load balancing against 1.0.1, I don't want some hotfix build to automatically get upgraded to version 1.0.2, based on the assumption that foo's author didn't break anything. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Tue Feb 25 21:16:54 2014 From: tab at snarc.org (Vincent Hanquez) Date: Tue, 25 Feb 2014 21:16:54 +0000 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <530D0846.2080102@snarc.org> On 2014-02-25 19:23, Gregory Collins wrote: > > On Mon, Feb 24, 2014 at 10:44 PM, Michael Snoyman > wrote: > > But that's only one half of the "package interoperability" issue. > I face this first hand on a daily basis with my Stackage > maintenance. I spend far more time reporting issues of restrictive > upper bounds than I do with broken builds from upstream changes. > So I look at this as purely a game of statistics: are you more > likely to have code break because version 1.2 of text changes the > type of the map function and you didn't have an upper bound, or > because two dependencies of yours have *conflicting* versions > bounds on a package like aeson[2]? In my experience, the latter > occurs far more often than the former. > > > That's because you maintain a lot of packages, and you're considering > buildability on short time frames (i.e. you mostly care about "does > all the latest stuff build right now?"). The consequences of violating > the PVP are that as a piece of code ages, the probability that it > still builds goes to *zero*, even if you go and dig out the old GHC > version that you were using at the time. I find this really > unacceptable, and believe that people who are choosing not to be > compliant with the policy are BREAKING HACKAGE and making life harder > for everyone by trading convenience now for guaranteed pain later. In > fact, in my opinion the server ought to be machine-checking PVP > compliance and refusing to accept packages that don't obey the policy. If you're going to dig an old ghc version, what's stopping you from downloading old packages manually from hackage ? I'm sure it can even be automated (more or less). However, I don't think we should optimise for this use case; I'ld rather use maintained packages that are regularly updated. And even if I wanted to use an old package, provided it's not tied to something fairly internals like GHC's api or such, in a language like haskell, porting to recent version of libraries should be easier than in most other language. Furthermore, some old libraries should not be used anymore. Consider old libraries that have security issues for example. Whilst it's not the intent, It's probably a good thing that those old libraries don't build anymore, and people are forced to move to the latest maintained version. The PvP at it stand seems to be a refuge for fossilised packages. > Like Ed said, this is pretty cut and dried: we have a policy, you're > choosing not to follow it, you're not in compliance, you're breaking > stuff. We can have a discussion about changing the policy (and this > has definitely been discussed to death before), but I don't think your > side has the required consensus/votes needed to change the policy. As > such, I really wish that you would reconsider your stance here. "we have a policy". *ouch*, I'm sorry, but I find those biggoted views damaging in a nice inclusive haskell community (as I like to view it). While we may have different opinions, I think we're all trying our best to contribute to the haskell ecosystem the way we see fit. -- Vincent From tab at snarc.org Tue Feb 25 21:23:24 2014 From: tab at snarc.org (Vincent Hanquez) Date: Tue, 25 Feb 2014 21:23:24 +0000 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530CD010.1030607@snarc.org> Message-ID: <530D09CC.8050800@snarc.org> On 2014-02-25 17:26, Carter Schonwald wrote: > indeed. > > So lets think about how to add module types or some approximation > thereof to GHC? (seriously, thats the only sane "best solution" i can > think of, but its not something that can be done casually). Theres > also the fact that any module system design will have to explicitly > deal with type class instances in a more explicit fashion than we've > done thus far. Yes. I think that's the only way a PvP could actually work. I would imagine that it could be quite fiddly and the reason why it wasn't been done yet. But, clearly for this scheme to work, it need to remove the human part in the equation as much as possible. It still wouldn't be perfect, as there would still be stuff that can't be accounted for (bug, laziness, performance issues,...) , but clearly it would work better than a simple flat sequence of number that is suppose to represent many different aspects of a package and the author's understanding of a policy. -- Vincent From omari at smileystation.com Tue Feb 25 21:33:57 2014 From: omari at smileystation.com (Omari Norman) Date: Tue, 25 Feb 2014 16:33:57 -0500 Subject: Changes to time for Safe Haskell Message-ID: It would be great to make some minor changes to time so that the Data.Time packages are Safe or Trustworthy for Safe Haskell. Currently I have a raft of packages that are Unsafe solely due to Data.Time being unsafe. The necessary changes are minor, and I changed nothing in the functions themselves. One module just needs to import Foreign.Safe rather than Foreign. Another is Unsafe due to use of rewrite rules; I simply marked those modules Trustworthy. Safe Haskell will be much more useful if modules that sit at the bottom of tall stacks, such as Data.Time, are Safe. Thanks, Omari -------------- next part -------------- 1 patch for repository http://code.haskell.org/time: Thu Feb 13 18:24:36 EST 2014 omari at smileystation.com * Changes for Safe Haskell Makes minimal necessary changes so that modules will infer as Safe for Safe Haskell. Some modules are using rewrite rules, which are not Safe; to these I added Trustworthy pragmas. The rewrite rules will continue to fire as normal, according to GHC's documentation. Other modules import Foreign. I changed these to import Foreign.Safe instead. I changed the time.cabal file so that the minimum version of Base is 4.4; that was the first version of Base that has the Foreign.Safe module. (base 4.4 came with GHC 7.2, which is over two years old.) New patches: [Changes for Safe Haskell omari at smileystation.com**20140213232436 Ignore-this: c7c8f97541bd4ab2620613c51fad3b91 Makes minimal necessary changes so that modules will infer as Safe for Safe Haskell. Some modules are using rewrite rules, which are not Safe; to these I added Trustworthy pragmas. The rewrite rules will continue to fire as normal, according to GHC's documentation. Other modules import Foreign. I changed these to import Foreign.Safe instead. I changed the time.cabal file so that the minimum version of Base is 4.4; that was the first version of Base that has the Foreign.Safe module. (base 4.4 came with GHC 7.2, which is over two years old.) ] { hunk ./Data/Time/Clock/CTimeval.hs 7 #ifndef mingw32_HOST_OS -- All Unix-specific, this -import Foreign +import Foreign.Safe import Foreign.C data CTimeval = MkCTimeval CLong CLong hunk ./Data/Time/Clock/Scale.hs 1 +{-# LANGUAGE Trustworthy #-} {-# OPTIONS -fno-warn-unused-imports #-} #include "HsConfigure.h" -- #hide hunk ./Data/Time/Clock/UTC.hs 2 {-# OPTIONS -fno-warn-unused-imports #-} +{-# LANGUAGE Trustworthy #-} #include "HsConfigure.h" -- #hide module Data.Time.Clock.UTC hunk ./Data/Time/LocalTime/TimeZone.hs 20 import Data.Time.Clock import Data.Time.Clock.POSIX -import Foreign +import Foreign.Safe import Foreign.C import Control.DeepSeq import Data.Typeable hunk ./time.cabal 39 library build-depends: - base >= 4 && < 5, + base >= 4.4 && < 5, deepseq >= 1.1, old-locale ghc-options: -Wall } Context: [TAG 1.4.1 Ashley Yakeley **20130630082310 Ignore-this: 5332cf440a95a0cd691a8fb72d632282 ] Patch bundle hash: 3212b712858c755593312eba3c045851a5d071f7 From mightybyte at gmail.com Tue Feb 25 21:34:04 2014 From: mightybyte at gmail.com (MightyByte) Date: Tue, 25 Feb 2014 16:34:04 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530D0846.2080102@snarc.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> Message-ID: On Tue, Feb 25, 2014 at 4:16 PM, Vincent Hanquez wrote: > If you're going to dig an old ghc version, what's stopping you from > downloading old packages manually from hackage ? I'm sure it can even be > automated (more or less). It's much more difficult because the scale is much greater. Also, if people aren't putting in version bounds, then you have no clue what versions to try. Leaving out version bounds is throwing away information. > However, I don't think we should optimise for this use case; I'ld rather use > maintained packages that are regularly updated. When I write code and get it working, I want it to work for all time. There's absolutely no reason we shouldn't be able to make that happen. If we ignore this case, then Haskell will never be suitable for use in serious production situations. Large organizations want to know that if they start using something it will continue to work. (And don't respond to this with the "avoid success at all costs" line. Haskell is now mature enough that I and a growing number of other people use Haskell on a daily basis for mission-critical applications.) > And even if I wanted to use an old package, provided it's not tied to something fairly internals like > GHC's api or such, in a language like haskell, porting to recent version of > libraries should be easier than in most other language. It might be easier, but it can still require a LOT of effort...much more than is justified in some situations. And that doesn't mean that in those situations getting old code working doesn't have significant value. > Furthermore, some old libraries should not be used anymore. Consider old > libraries that have security issues for example. Whilst it's not the intent, > It's probably a good thing that those old libraries don't build anymore, and > people are forced to move to the latest maintained version. This argument does not hold water when getting a legacy piece of code working has significant intrinsic value. There are plenty of situations where code can have great value to a person/organization even if it doesn't touch the wild internet. From tab at snarc.org Tue Feb 25 21:37:29 2014 From: tab at snarc.org (Vincent Hanquez) Date: Tue, 25 Feb 2014 21:37:29 +0000 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <530D0D19.2010901@snarc.org> On 2014-02-25 20:38, Michael Snoyman wrote: > > > > On Tue, Feb 25, 2014 at 9:23 PM, Gregory Collins > > wrote: > > I really don't like this appeal to authority. I don't know who the > "royal we" is that you are referring to here, and I don't accept the > premise that the rest of us must simply adhere to a policy because "it > was decided." "My side" as you refer to it is giving concrete negative > consequences to the PVP. I'd expect "your side" to respond in kind, > not simply assert that we're "breaking Hackage" and other such hyperbole. > Strongly agreed. > > Of course, people who want to follow PVP are also going to need > tooling to make sure their programs still build in the future > because so many people have broken the policy in the past -- > that's where proposed kludges like "cabal freeze" are going to > come in. > > > This is where we apparently fundamentally disagree. cabal freeze IMO > is not at all a kludge. It's the only sane approach to reliable > builds. If I ran my test suite against foo version 1.0.1, performed > manual testing on 1.0.1, did my load balancing against 1.0.1, I don't > want some hotfix build to automatically get upgraded to version 1.0.2, > based on the assumption that foo's author didn't break anything. > This is probably also the only sane approach at the moment for safe builds. Considering the whole hackage infrastructure is quite insecure at the moment (http download/upload, no package signing, etc), freezing your build packages after you have audited them is probably the only sensible way to ship secure products. In a production environment (at 2 different work places), i've seen two approachs for proper builds: * still using hackage directly, but pinning each package with a cryptographic hash on your build site. * a private hackage instance where packages are manually imported. build is using exclusively this. Using hackage directly(+ depending on the PvP) is at the moment too much like playing russian roulette. -- Vincent From tab at snarc.org Tue Feb 25 21:51:30 2014 From: tab at snarc.org (Vincent Hanquez) Date: Tue, 25 Feb 2014 21:51:30 +0000 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> Message-ID: <530D1062.5010006@snarc.org> On 2014-02-25 21:34, MightyByte wrote: > On Tue, Feb 25, 2014 at 4:16 PM, Vincent Hanquez wrote: >> If you're going to dig an old ghc version, what's stopping you from >> downloading old packages manually from hackage ? I'm sure it can even be >> automated (more or less). > It's much more difficult because the scale is much greater. Also, if > people aren't putting in version bounds, then you have no clue what > versions to try. Leaving out version bounds is throwing away > information. I'm not saying this is not painful, but i've done it in the past, and using dichotomy and educated guesses (for example not using libraries released after a certain date), you converge pretty quickly on a solution. But the bottom line is that it's not the common use case. I rarely have to dig old unused code. >> However, I don't think we should optimise for this use case; I'ld rather use >> maintained packages that are regularly updated. > When I write code and get it working, I want it to work for all time. > There's absolutely no reason we shouldn't be able to make that happen. > If we ignore this case, then Haskell will never be suitable for use > in serious production situations. Large organizations want to know > that if they start using something it will continue to work. (And > don't respond to this with the "avoid success at all costs" line. > Haskell is now mature enough that I and a growing number of other > people use Haskell on a daily basis for mission-critical > applications.) This is moot IMHO. A large organisation would *not* rely on cabal, nor the PvP to actually download packages properly: Not only this is insecure, and as Michael mentioned, you would not get the guarantee you need anyway. Even if the above wasn't an issue, Haskell doesn't run in a bubble. I don't expect old ghc and old packages to work with newer operating systems and newer libraries forever. >> Furthermore, some old libraries should not be used anymore. Consider old >> libraries that have security issues for example. Whilst it's not the intent, >> It's probably a good thing that those old libraries don't build anymore, and >> people are forced to move to the latest maintained version. > This argument does not hold water when getting a legacy piece of code > working has significant intrinsic value. There are plenty of > situations where code can have great value to a person/organization > even if it doesn't touch the wild internet. Sure, in this case it doesn't apply to my "security issue" example, does it ? -- Vincent From greg at gregorycollins.net Tue Feb 25 21:52:28 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 25 Feb 2014 13:52:28 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 12:38 PM, Michael Snoyman wrote: > On Tue, Feb 25, 2014 at 9:23 PM, Gregory Collins wrote: > >> Like Ed said, this is pretty cut and dried: we have a policy, you're >> choosing not to follow it, you're not in compliance, you're breaking stuff. >> We can have a discussion about changing the policy (and this has definitely >> been discussed to death before), but I don't think your side has the >> required consensus/votes needed to change the policy. As such, I really >> wish that you would reconsider your stance here. >> > > I really don't like this appeal to authority. I don't know who the "royal > we" is that you are referring to here, and I don't accept the premise that > the rest of us must simply adhere to a policy because "it was decided." "My > side" as you refer to it is giving concrete negative consequences to the > PVP. I'd expect "your side" to respond in kind, not simply assert that > we're "breaking Hackage" and other such hyperbole. > This is not an appeal to authority, it's an appeal to consensus. The community comes together to work on lots of different projects like Hackage and the platform and we have established procedures and policies (like the PVP and the Hackage platform process) to manage this. I think the following facts are uncontroversial: - a Hackage package versioning policy exists and has been published in a known location - we don't have another one - you're violating it Now you're right to argue that the PVP as currently constituted causes problems, i.e. "I can't upgrade to new-shiny-2.0 quickly enough" and "I manage 200 packages and you're driving me insane". And new major base versions cause a month of churn before everything goes green again. Everyone understands this. But the solution is either to vote to change the policy or to write tooling to make your life less insane, not just to ignore it, because the situation this creates (programs bitrot and become unbuildable over time at 100% probability) is really disappointing. Now, I think I understand what you're alluding to. Assuming I understand > you correctly, I think you're advocating irresponsible development. I have > codebases which I maintain and which use older versions of packages. I know > others who do the same. The rule for this is simple: if your development > process only works by assuming third parties to adhere to some rules you've > established, you're in for a world of hurt. You're correct: if everyone > rigidly followed the PVP, *and* no one every made any mistakes, *and* the > PVP solved all concerns, then you could get away with the development > practices you're talking about. > There's a strawman in there -- in an ideal world PVP violations would be rare and would be considered bugs. Also, if it were up to me we'd be machine-checking PVP compliance. I don't know what you're talking about re: "irresponsible development". In the scenario I'm talking about, my program depends on "foo-1.2", "foo-1.2" depends on any version of "bar", and then when "bar-2.0" is released "foo-1.2" stops building and there's no way to fix this besides trial and error because the solver doesn't have enough information to do its work (and it's been lied to!!!). The only practical solutions right now are to: - commit to maintaining every program you've ever written on the hackage upgrade treadmill forever, or - write down the exact versions of all of the libraries you need in the transitive closure of the dependency graph. #2 is best practice for repeatable builds anyways and you're right that cabal freeze will help here, but it doesn't help much for all the programs written before "cabal freeze" comes out. But that's not the real world. In the real world: > > * The PVP itself does *not* guarantee reliable builds in all cases. If a > transitive dependency introduces new exports, or provides new typeclass > instances, a fully PVP-compliant stack can be broken. (If anyone doubts > this claim, let me know, I can spell out the details. This has come up in > practice.) > Of course. But compute the probability of this occurring (rare) vs the probability of breakage given no upper bounds (100% as t -> ?). Think about what you're saying semantically when you say you depend only on "foo > 3": "foo version 4.0 *or any later version*". You can't own up to this contract. * Just because your code *builds*, doesn't mean your code *works*. > Semantics can change: bugs can be introduced, bugs that you depended upon > can be resolved, performance characteristics can change in breaking ways, > etc. > I think you're making my point for me -- given that this paragraph you wrote is 100% correct, it makes sense for cabal not to try to build against the new version of a dependency until the package maintainer has checked that things still work and given the solver the go-ahead by bumping the package upper bound. This is where we apparently fundamentally disagree. cabal freeze IMO is not > at all a kludge. It's the only sane approach to reliable builds. If I ran > my test suite against foo version 1.0.1, performed manual testing on 1.0.1, > did my load balancing against 1.0.1, I don't want some hotfix build to > automatically get upgraded to version 1.0.2, based on the assumption that > foo's author didn't break anything. > This wouldn't be an assumption, Michael -- the tool should run the build and the test suites. We'd bump version on green tests. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Tue Feb 25 22:08:26 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 25 Feb 2014 14:08:26 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530D0846.2080102@snarc.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> Message-ID: On Tue, Feb 25, 2014 at 1:16 PM, Vincent Hanquez wrote: > On 2014-02-25 19:23, Gregory Collins wrote: > >> >> That's because you maintain a lot of packages, and you're considering >> buildability on short time frames (i.e. you mostly care about "does all the >> latest stuff build right now?"). The consequences of violating the PVP are >> that as a piece of code ages, the probability that it still builds goes to >> *zero*, even if you go and dig out the old GHC version that you were using >> at the time. I find this really unacceptable, and believe that people who >> are choosing not to be compliant with the policy are BREAKING HACKAGE and >> making life harder for everyone by trading convenience now for guaranteed >> pain later. In fact, in my opinion the server ought to be machine-checking >> PVP compliance and refusing to accept packages that don't obey the policy. >> > If you're going to dig an old ghc version, what's stopping you from > downloading old packages manually from hackage ? I'm sure it can even be > automated (more or less). > The solver can't help you here. Like I wrote in my last message to Michael: if I depend on foo-1.2, and foo-1.2 depends on "bar", and "bar-2.0" comes out that breaks "foo-1.2", what can I do? I have to binary search the transitive closure of the dependency space because the solver cannot help. However, I don't think we should optimise for this use case; I'ld rather > use maintained packages that are regularly updated. And even if I wanted to > use an old package, provided it's not tied to something fairly internals > like GHC's api or such, in a language like haskell, porting to recent > version of libraries should be easier than in most other language. > > Furthermore, some old libraries should not be used anymore. Consider old > libraries that have security issues for example. Whilst it's not the > intent, It's probably a good thing that those old libraries don't build > anymore, and people are forced to move to the latest maintained version. > > The PvP at it stand seems to be a refuge for fossilised packages. I care much more about programs than about libraries here. Most Haskell programs that were ever written never made it to Hackage. I don't understand the point about old libraries: people will stop using libraries that aren't updated by their maintainers, or someone else will take them over. Like Ed said, this is pretty cut and dried: we have a policy, you're >> choosing not to follow it, you're not in compliance, you're breaking stuff. >> We can have a discussion about changing the policy (and this has definitely >> been discussed to death before), but I don't think your side has the >> required consensus/votes needed to change the policy. As such, I really >> wish that you would reconsider your stance here. >> > > "we have a policy". > > *ouch*, I'm sorry, but I find those biggoted views damaging in a nice > inclusive haskell community (as I like to view it). > I don't see what bigotry or inclusiveness has to do with this. This is a conversation between insiders anyways :) While we may have different opinions, I think we're all trying our best to > contribute to the haskell ecosystem the way we see fit. Of course, nobody's saying otherwise. People arguing for the omission of upper bounds often point to breakage caused by the PVP -- I just want to make it clear that people who ignore PVP cause breakage too, and this breakage is worse (because it affects end users instead of Haskell nerds, who know how to fix it). See e.g. https://github.com/snapframework/cufp2011/issues/4 for an instance where one of your packages broke a program of mine for no reason. This program would have continued building fine basically forever if you'd followed the PVP. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From omari at smileystation.com Tue Feb 25 22:15:46 2014 From: omari at smileystation.com (Omari Norman) Date: Tue, 25 Feb 2014 17:15:46 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 4:52 PM, Gregory Collins wrote: > write down the exact versions of all of the libraries you need in the > transitive closure of the dependency graph. I cobbled together a rudimentary tool that does just that: https://hackage.haskell.org/package/sunlight the idea being that, to my knowledge, there were no tools making it easy to verify that a package builds with the *minimum* specified versions. Typical CI testing will eagerly pull the latest dependencies. sunlight builds in a sandbox, runs your tests, and snapshots the resulting GHC package database. It can do this for multiple GHC versions, and will do one build with the minimum versions possible (it does require that you specify a minimum version for each dependency, but not a maximum). At least then you can consult a record showing the exact package graph that actually worked. From ganesh at earth.li Tue Feb 25 22:40:02 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue, 25 Feb 2014 22:40:02 +0000 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <530D1BC2.8080001@earth.li> On 25/02/2014 06:44, Michael Snoyman wrote: > Next is the issue of PVP. I am someone who has stopped religiously > following the PVP in the past few years. Your email seems to imply that > only those following the PVP care about making sure that "packages work > together." I disagree here; I don't use the PVP specifically because I > care about package interoperability. > > The point of the PVP is to ensure that code builds. It's a purely > compile-time concept. The PVP solves the problem of an update to a > dependency causing a downstream package to break. And assuming everyone > adheres to it[1], it ensures that cabal will never try to perform a > build which isn't guaranteed to work. > > But that's only one half of the "package interoperability" issue. I face > this first hand on a daily basis with my Stackage maintenance. I spend > far more time reporting issues of restrictive upper bounds than I do > with broken builds from upstream changes. So I look at this as purely a > game of statistics: are you more likely to have code break because > version 1.2 of text changes the type of the map function and you didn't > have an upper bound, or because two dependencies of yours have > *conflicting* versions bounds on a package like aeson[2]? In my > experience, the latter occurs far more often than the former. It's worth mentioning that cabal failing to find a solution is far less costly for me to discover than cabal finding a solution and then having a build of a large graph of packages fail, because by that point I've wasted a lot of time waiting for the build and I now have a thoroughly confused package database to recover from (whether using a sandbox or not). Ganesh From hvr at gnu.org Tue Feb 25 22:52:23 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 25 Feb 2014 23:52:23 +0100 Subject: qualified imports, PVP and so on In-Reply-To: (Michael Snoyman's message of "Tue, 25 Feb 2014 22:38:38 +0200") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: <878usyst3s.fsf@gnu.org> On 2014-02-25 at 21:38:38 +0100, Michael Snoyman wrote: [...] > * The PVP itself does *not* guarantee reliable builds in all cases. If a > transitive dependency introduces new exports, or provides new typeclass > instances, a fully PVP-compliant stack can be broken. (If anyone doubts > this claim, let me know, I can spell out the details. This has come up in > practice.) ...are you simply referring to the fact that in order to guarantee PVP-semantics of a package version, one has to take care to restrict the version bounds of that package's build-deps in such a way, that any API entities leaking from its (direct) build-deps (e.g. typeclass instances or other re-exported entities) are not a function of the "internal" degree of freedoms the build-dep version-ranges provide? Or is there more to it? From mightybyte at gmail.com Tue Feb 25 23:28:14 2014 From: mightybyte at gmail.com (MightyByte) Date: Tue, 25 Feb 2014 18:28:14 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <530D1062.5010006@snarc.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez wrote: > > I'm not saying this is not painful, but i've done it in the past, and using > dichotomy and educated guesses (for example not using libraries released > after a certain date), you converge pretty quickly on a solution. > > But the bottom line is that it's not the common use case. I rarely have to > dig old unused code. And I have code that I would like to have working today, but it's too expensive to go through this process. The code has significant value to me and other people, but not enough to justify the large cost of getting it working again. > This is moot IMHO. A large organisation would *not* rely on cabal, nor the > PvP to actually download packages properly: Sorry, let me rephrase. s/Large organizations/organizations/ Not everyone is big enough to devote the kind of resources it would take to set up their own system. I've personally worked at two such companies. Building tools that can serve the needs of these organizations will help the Haskell community as a whole. > Not only this is insecure, and as Michael mentioned, you would not get the > guarantee you need anyway. In many cases security doesn't matter because code doesn't interact with the outside world. We're not talking about guaranteeing that building with a later version is buggy. We're talking about guaranteeing that the package will work the way it always worked. It's kind of a package-level purity/immutability. > Even if the above wasn't an issue, Haskell doesn't run in a bubble. I don't > expect old ghc and old packages to work with newer operating systems and > newer libraries forever. I don't expect this either. I expect old packages to work the way they always worked with the packages they always worked with. From michael at snoyman.com Wed Feb 26 05:25:09 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 07:25:09 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: > On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez wrote: > > > > I'm not saying this is not painful, but i've done it in the past, and > using > > dichotomy and educated guesses (for example not using libraries released > > after a certain date), you converge pretty quickly on a solution. > > > > But the bottom line is that it's not the common use case. I rarely have > to > > dig old unused code. > > And I have code that I would like to have working today, but it's too > expensive to go through this process. The code has significant value > to me and other people, but not enough to justify the large cost of > getting it working again. > > I think we need to make these cases more concrete to have a meaningful discussion. Between Doug and Gregory, I'm understanding two different use cases: 1. Existing, legacy code, built again some historical version of Hackage, without information on the exact versions of all deep dependencies. 2. Someone starting a new project who wants to use an older version of a package on Hackage. If I've missed a use case, please describe it. For (1), let's start with the time machine game: *if* everyone had been using the PVP, then theoretically this wouldn't have happened. And *if* the developers had followed proper practice and documented their complete build environment, then PVP compliance would be irrelevant. So if we could go back in time and twist people's arms, no problems would exist. Hurray, we've established that 20/20 hindsight is very nice :). But what can be done today? Actually, I think the solution is a very simple tool, and I'll be happy to write it if people want: cabal-timemachine. It takes a timestamp, and then deletes all cabal files from our 00-index.tar file that represent packages uploaded after that date. Assuming you know the last date of a successful build, it should be trivial to get a build going again. And if you *don't* know the date, you can bisect until you get a working build. (For that matter, the tool could even *include* a bisecter in it.) Can anyone picture a scenario where this wouldn't solve the problem even better than PVP compliance? I still maintain that new codebases should be creating freeze files (or whatever we want to call them), and we need a community supported tool for it. After speaking with various Haskell-based companies, I'm fairly certain just about everyone's reinvented their own proprietary version of such a tool. For (2), talking about older versions of a package is not relevant. I actively maintain a number of my older package releases, as I'm sure others do as well. The issue isn't about *age* of a package, but about *maintenance* of a package. And we simply shouldn't be encouraging users to start off with an unmaintained version of a package. This is a completely separate discussion from the legacy code base, where- despite the valid security and bug concerns Vincent raised- it's likely not worth updating to the latest and greatest. All of that said, I still think the only real solution is getting end users off of Hackage. We need an intermediate, stabilizing layer. That's why I started Stackage, and I believe that it's the only solution that will ultimately make library authors and end-users happy. Everything we're discussing now is window dressing. My offer of cabal-timemachine was serious: I'll be happy to start that project, and I *do* think it will solve many people's issues. I'd just like it if it was released concurrently with cabal-freeze, so that once you figure out the right set of packages, you can freeze them in place and never run into these issues again. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 05:39:09 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 07:39:09 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 11:52 PM, Gregory Collins wrote: > On Tue, Feb 25, 2014 at 12:38 PM, Michael Snoyman wrote: > >> On Tue, Feb 25, 2014 at 9:23 PM, Gregory Collins > > wrote: >> >>> Like Ed said, this is pretty cut and dried: we have a policy, you're >>> choosing not to follow it, you're not in compliance, you're breaking stuff. >>> We can have a discussion about changing the policy (and this has definitely >>> been discussed to death before), but I don't think your side has the >>> required consensus/votes needed to change the policy. As such, I really >>> wish that you would reconsider your stance here. >>> >> >> I really don't like this appeal to authority. I don't know who the "royal >> we" is that you are referring to here, and I don't accept the premise that >> the rest of us must simply adhere to a policy because "it was decided." "My >> side" as you refer to it is giving concrete negative consequences to the >> PVP. I'd expect "your side" to respond in kind, not simply assert that >> we're "breaking Hackage" and other such hyperbole. >> > > This is not an appeal to authority, it's an appeal to consensus. The > community comes together to work on lots of different projects like Hackage > and the platform and we have established procedures and policies (like the > PVP and the Hackage platform process) to manage this. I think the following > facts are uncontroversial: > > - a Hackage package versioning policy exists and has been published in > a known location > - we don't have another one > - you're violating it > > Now you're right to argue that the PVP as currently constituted causes > problems, i.e. "I can't upgrade to new-shiny-2.0 quickly enough" and "I > manage 200 packages and you're driving me insane". And new major base > versions cause a month of churn before everything goes green again. > Everyone understands this. But the solution is either to vote to change the > policy or to write tooling to make your life less insane, not just to > ignore it, because the situation this creates (programs bitrot and become > unbuildable over time at 100% probability) is really disappointing. > > You talk about voting on the policy as if that's the natural thing to do. When did we vote to accept the policy in the first place? I don't remember ever putting my name down as "I agree, this makes sense." Talking about voting, violating, complying, etc, in a completely open system like Hackage, makes no sense, and is why your comments come off as an appeal to authority. If you want to have more rigid rules on what packages can be included, start a downstream, PVP-only Hackage, and don't allow in violating packages. If it takes off, and users have demonstrated that they care very much about PVP compliance, then us PVP naysayers will have hard evidence that our beliefs were mistaken. Right now, it's just a few people constantly accusing us of violations and insisting we spend a lot more work on a policy we believe to be flawed. > Now, I think I understand what you're alluding to. Assuming I understand >> you correctly, I think you're advocating irresponsible development. I have >> codebases which I maintain and which use older versions of packages. I know >> others who do the same. The rule for this is simple: if your development >> process only works by assuming third parties to adhere to some rules you've >> established, you're in for a world of hurt. You're correct: if everyone >> rigidly followed the PVP, *and* no one every made any mistakes, *and* the >> PVP solved all concerns, then you could get away with the development >> practices you're talking about. >> > > There's a strawman in there -- in an ideal world PVP violations would be > rare and would be considered bugs. > Then you're missing my point completely. You're advocating making package management policy based on developer practices of not pinning down deep dependencies. My point is that *bugs happen*. And as I keep saying, it's not just build-time bugs: runtime bugs are possible and far worse. I see no reason that package authors should go through lots of effort to encourage bad practice. > Also, if it were up to me we'd be machine-checking PVP compliance. I don't > know what you're talking about re: "irresponsible development". In the > scenario I'm talking about, my program depends on "foo-1.2", "foo-1.2" > depends on any version of "bar", and then when "bar-2.0" is released > "foo-1.2" stops building and there's no way to fix this besides trial and > error because the solver doesn't have enough information to do its work > (and it's been lied to!!!). The only practical solutions right now are to: > > - commit to maintaining every program you've ever written on the > hackage upgrade treadmill forever, or > - write down the exact versions of all of the libraries you need in > the transitive closure of the dependency graph. > > #2 is best practice for repeatable builds anyways and you're right that > cabal freeze will help here, but it doesn't help much for all the programs > written before "cabal freeze" comes out. > > Playing the time machine game is silly. Older programs are broken. End of story. If we all agree to start using the PVP now, it won't fix broken programs. If we release "cabal freeze" now, it won't fix broken programs. But releasing "cabal freeze" *will* prevent this problem from happening in the future. > But that's not the real world. In the real world: >> >> * The PVP itself does *not* guarantee reliable builds in all cases. If a >> transitive dependency introduces new exports, or provides new typeclass >> instances, a fully PVP-compliant stack can be broken. (If anyone doubts >> this claim, let me know, I can spell out the details. This has come up in >> practice.) >> > > Of course. But compute the probability of this occurring (rare) vs the > probability of breakage given no upper bounds (100% as t -> ?). Think about > what you're saying semantically when you say you depend only on "foo > 3": > "foo version 4.0 *or any later version*". You can't own up to this > contract. > > That's because you're defining the build-depends to mean "I guarantee this to be the case." I could just as easily argue that `foo < 4` is also a lie: how do you know that it *won't* build? This argument has been had many times, please stop trying to make it seem like a clear-cut argument. > * Just because your code *builds*, doesn't mean your code *works*. >> Semantics can change: bugs can be introduced, bugs that you depended upon >> can be resolved, performance characteristics can change in breaking ways, >> etc. >> > > I think you're making my point for me -- given that this paragraph you > wrote is 100% correct, it makes sense for cabal not to try to build against > the new version of a dependency until the package maintainer has checked > that things still work and given the solver the go-ahead by bumping the > package upper bound. > > Again, you're missing it. If there's a point release, PVP-based code will automatically start using that new point release. That's simply not good practice for a production system. > This is where we apparently fundamentally disagree. cabal freeze IMO is >> not at all a kludge. It's the only sane approach to reliable builds. If I >> ran my test suite against foo version 1.0.1, performed manual testing on >> 1.0.1, did my load balancing against 1.0.1, I don't want some hotfix build >> to automatically get upgraded to version 1.0.2, based on the assumption >> that foo's author didn't break anything. >> > > This wouldn't be an assumption, Michael -- the tool should run the build > and the test suites. We'd bump version on green tests. > > Maybe you write perfect code every time. But I've seen this process many times in the past: * Work on version 2 of an application. * Create a staging build of version 2. * Run automated tests on version 2. * QA manually tests version 2. * Release version 2. * Three weeks later, discover a bug. * Write a hotfix, deploy to staging, run automated tests, QA the changed code, and ship. In these circumstances, it would be terrible if my build system automatically accepted a new point release of a package on Hackage because the PVP says it's OK. Yes, we should all have 100% test coverage, with automated testing that covers all functionality of the product, and every single release would have full test coverage. But we all know that's not the real world. Letting a build system throw variables into an equation is irresponsible. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 05:45:30 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 07:45:30 +0200 Subject: qualified imports, PVP and so on In-Reply-To: <878usyst3s.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 12:52 AM, Herbert Valerio Riedel wrote: > On 2014-02-25 at 21:38:38 +0100, Michael Snoyman wrote: > > [...] > > > * The PVP itself does *not* guarantee reliable builds in all cases. If a > > transitive dependency introduces new exports, or provides new typeclass > > instances, a fully PVP-compliant stack can be broken. (If anyone doubts > > this claim, let me know, I can spell out the details. This has come up in > > practice.) > > ...are you simply referring to the fact that in order to guarantee > PVP-semantics of a package version, one has to take care to restrict the > version bounds of that package's build-deps in such a way, that any API > entities leaking from its (direct) build-deps (e.g. typeclass instances > or other re-exported entities) are not a function of the "internal" > degree of freedoms the build-dep version-ranges provide? Or is there > more to it? > That's essentially it. I'll give one of the examples I ran into. (Names omitted on purpose, if the involved party wants to identify himself, please do so, I just didn't feel comfortable doing so without your permission.) Version 0.2 of monad-logger included MonadLogger instances for IO and other base monads. For various reasons, these were removed, and the version bumped to 0.3. This is in full compliance with the PVP. persistent depends on monad-logger. It can work with either version 0.2 or 0.3 of monad-logger, and the cabal file allows this via `monad-logger >= 0.2 && < 0.4` (or something like that). Again, full PVP compliance. A user wrote code against persistent when monad-logger version 0.2 was available. He used a function that looked like: runDatabase :: MonadLogger m => Persistent a -> m a (highly simplified). In his application, he used this in the IO monad. He depended on persistent with proper lower and upper bounds. Once again, full PVP compliance. Once I released version 0.3 of monad-logger, his next build automatically upgraded him to monad-logger 0.3, and suddenly his code broke, because there's no MonadLogger instance for IO. Now *if* the program had been using a system like "cabal freeze" or the like, this could have never happened: cabal wouldn't be trying to automatically upgrade to monad-logger 0.3. Will this kind of bug happen all the time? No, I doubt it. But if the point of the PVP is to guarantee that builds will work (ignoring runtime concerns), and the PVP clearly fails at that job as well, we really need to reassess putting ourselves through this pain and suffering. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Feb 26 06:03:00 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 25 Feb 2014 22:03:00 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman wrote: > > > On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: > >> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez wrote: >> > >> > I'm not saying this is not painful, but i've done it in the past, and >> using >> > dichotomy and educated guesses (for example not using libraries released >> > after a certain date), you converge pretty quickly on a solution. >> > >> > But the bottom line is that it's not the common use case. I rarely have >> to >> > dig old unused code. >> >> And I have code that I would like to have working today, but it's too >> expensive to go through this process. The code has significant value >> to me and other people, but not enough to justify the large cost of >> getting it working again. >> >> > > I think we need to make these cases more concrete to have a meaningful > discussion. Between Doug and Gregory, I'm understanding two different use > cases: > > 1. Existing, legacy code, built again some historical version of Hackage, > without information on the exact versions of all deep dependencies. > 2. Someone starting a new project who wants to use an older version of a > package on Hackage. > > If I've missed a use case, please describe it. > > For (1), let's start with the time machine game: *if* everyone had been > using the PVP, then theoretically this wouldn't have happened. And *if* the > developers had followed proper practice and documented their complete build > environment, then PVP compliance would be irrelevant. So if we could go > back in time and twist people's arms, no problems would exist. Hurray, > we've established that 20/20 hindsight is very nice :). > > But what can be done today? Actually, I think the solution is a very > simple tool, and I'll be happy to write it if people want: > cabal-timemachine. It takes a timestamp, and then deletes all cabal files > from our 00-index.tar file that represent packages uploaded after that > date. Assuming you know the last date of a successful build, it should be > trivial to get a build going again. And if you *don't* know the date, you > can bisect until you get a working build. (For that matter, the tool could > even *include* a bisecter in it.) Can anyone picture a scenario where this > wouldn't solve the problem even better than PVP compliance? > This scenario is never better than PVP compliance. First of all, the user may want some packages that are newer than the timestamp, which this wouldn't support. As people have already mentioned, it's entirely possible for valid install graphs to exist that cabal will fail to find if it doesn't have upper bound information available, because it finds other *invalid* graphs. And even aside from that issue, this would push the work of making sure that a library is compatible with its dependencies onto the library *users*, instead of the developer, where it rightfully belongs (and your proposal ends up pushing even more work onto users!). Why do you think it's acceptable for users to do the testing to make sure that your code works with other packages that your code requires? > > For (2), talking about older versions of a package is not relevant. I > actively maintain a number of my older package releases, as I'm sure others > do as well. The issue isn't about *age* of a package, but about > *maintenance* of a package. And we simply shouldn't be encouraging users to > start off with an unmaintained version of a package. This is a completely > separate discussion from the legacy code base, where- despite the valid > security and bug concerns Vincent raised- it's likely not worth updating to > the latest and greatest. > Usually the case is not that somebody *wants* to use an older version of package 'foo', it's that they're using some package 'bar' which hasn't yet been updated to be compatible with the latest 'foo'. There are all sorts of reasons this may happen, including big API shifts (e.g. parsec2/parsec3, openGL), poor timing in a maintenance cycle, and the usual worldly distractions. But if packages have upper bounds, the user can 'cabal install', get a coherent package graph, and begin working. At the very worst, cabal will give them a clear lead as to what needs to be updated/who to ping. This is much better than the situation with no upper bounds, where a 'cabal install' may fail miserably or even put together code that produces garbage. And again, it's the library *user* who ends up having to deal with these problems. Upper bounds lead to a better user experience. > > All of that said, I still think the only real solution is getting end > users off of Hackage. We need an intermediate, stabilizing layer. That's > why I started Stackage, and I believe that it's the only solution that will > ultimately make library authors and end-users happy. Everything we're > discussing now is window dressing. > A curated ecosystem can certainly function, but it seems like a lot more work than just following the PVP and specifying upper bounds. And upper bounds are likely to work better with packages that, for whatever reason, aren't in that curated ecosystem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Wed Feb 26 06:10:52 2014 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 26 Feb 2014 07:10:52 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530CD010.1030607@snarc.org> Message-ID: On 2014-02-25 18:26, Carter Schonwald wrote: > indeed. > > So lets think about how to add module types or some approximation thereof > to GHC? (seriously, thats the only sane "best solution" i can think of, but > its not something that can be done casually). Theres also the fact that any > module system design will have to explicitly deal with type class instances > in a more explicit fashion than we've done thus far. This may be relevant: http://plv.mpi-sws.org/backpack/ Regards, From michael at snoyman.com Wed Feb 26 07:11:40 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 09:11:40 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 8:03 AM, John Lato wrote: > On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman wrote: > >> >> >> On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: >> >>> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez wrote: >>> > >>> > I'm not saying this is not painful, but i've done it in the past, and >>> using >>> > dichotomy and educated guesses (for example not using libraries >>> released >>> > after a certain date), you converge pretty quickly on a solution. >>> > >>> > But the bottom line is that it's not the common use case. I rarely >>> have to >>> > dig old unused code. >>> >>> And I have code that I would like to have working today, but it's too >>> expensive to go through this process. The code has significant value >>> to me and other people, but not enough to justify the large cost of >>> getting it working again. >>> >>> >> >> I think we need to make these cases more concrete to have a meaningful >> discussion. Between Doug and Gregory, I'm understanding two different use >> cases: >> >> 1. Existing, legacy code, built again some historical version of Hackage, >> without information on the exact versions of all deep dependencies. >> 2. Someone starting a new project who wants to use an older version of a >> package on Hackage. >> >> If I've missed a use case, please describe it. >> >> For (1), let's start with the time machine game: *if* everyone had been >> using the PVP, then theoretically this wouldn't have happened. And *if* the >> developers had followed proper practice and documented their complete build >> environment, then PVP compliance would be irrelevant. So if we could go >> back in time and twist people's arms, no problems would exist. Hurray, >> we've established that 20/20 hindsight is very nice :). >> >> But what can be done today? Actually, I think the solution is a very >> simple tool, and I'll be happy to write it if people want: >> cabal-timemachine. It takes a timestamp, and then deletes all cabal files >> from our 00-index.tar file that represent packages uploaded after that >> date. Assuming you know the last date of a successful build, it should be >> trivial to get a build going again. And if you *don't* know the date, you >> can bisect until you get a working build. (For that matter, the tool could >> even *include* a bisecter in it.) Can anyone picture a scenario where this >> wouldn't solve the problem even better than PVP compliance? >> > > This scenario is never better than PVP compliance. First of all, the user > may want some packages that are newer than the timestamp, which this > wouldn't support. As people have already mentioned, it's entirely possible > for valid install graphs to exist that cabal will fail to find if it > doesn't have upper bound information available, because it finds other > *invalid* graphs. > > And even aside from that issue, this would push the work of making sure > that a library is compatible with its dependencies onto the library > *users*, instead of the developer, where it rightfully belongs (and your > proposal ends up pushing even more work onto users!). > > Why do you think it's acceptable for users to do the testing to make sure > that your code works with other packages that your code requires? > You're not at all addressing the case I described. The case was a legacy project that someone is trying to rebuild. I'm not talking about any other case in this scenario. To repeat myself: > 1. Existing, legacy code, built again some historical version of Hackage, without information on the exact versions of all deep dependencies. In *that specific case*, why wouldn't having a tool to go back in time and build against a historical version of Hackage be *exactly* what you'd need to rebuild the project? > >> For (2), talking about older versions of a package is not relevant. I >> actively maintain a number of my older package releases, as I'm sure others >> do as well. The issue isn't about *age* of a package, but about >> *maintenance* of a package. And we simply shouldn't be encouraging users to >> start off with an unmaintained version of a package. This is a completely >> separate discussion from the legacy code base, where- despite the valid >> security and bug concerns Vincent raised- it's likely not worth updating to >> the latest and greatest. >> > > Usually the case is not that somebody *wants* to use an older version of > package 'foo', it's that they're using some package 'bar' which hasn't yet > been updated to be compatible with the latest 'foo'. There are all sorts > of reasons this may happen, including big API shifts (e.g. parsec2/parsec3, > openGL), poor timing in a maintenance cycle, and the usual worldly > distractions. But if packages have upper bounds, the user can 'cabal > install', get a coherent package graph, and begin working. At the very > worst, cabal will give them a clear lead as to what needs to be updated/who > to ping. This is much better than the situation with no upper bounds, > where a 'cabal install' may fail miserably or even put together code that > produces garbage. > > And again, it's the library *user* who ends up having to deal with these > problems. Upper bounds lead to a better user experience. > I disagree with that assertion. I get plenty of complaints from users about trying to install packages and getting "confusing error messages" about cabal plan mismatches. I don't disagree that the PVP does make the user experience better in some cases. What I disagree with is the implication that it makes the user experience better in *all* cases. This is simply not a black-and-white issue. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Wed Feb 26 08:03:17 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Wed, 26 Feb 2014 00:03:17 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> Message-ID: On Tue, Feb 25, 2014 at 9:39 PM, Michael Snoyman wrote: > You talk about voting on the policy as if that's the natural thing to do. > When did we vote to accept the policy in the first place? I don't remember > ever putting my name down as "I agree, this makes sense." Talking about > voting, violating, complying, etc, in a completely open system like > Hackage, makes no sense, and is why your comments come off as an appeal to > authority. Michael, where do I start. This policy was written and put into place in October 2007, based on an earlier proposal by Bulat Ziganshin from 2006. Simon Marlow wrote a draft on the wiki, the matter was discussed on haskell-cafe@, in #ghc, on the wiki, and presumably in person. Consensus was reached and the policy has been periodically updated by the community since. I don't want to "appeal to authority" here, but from the logs it's clear that the people involved were Simon, Duncan, Ian, Don, etc., i.e. the people actually responsible for building and running all the crap we're talking about in the first place, including Hackage itself. I know it furthers your argument to question the policy's legitimacy, and I'm sorry consensus was reached without your agreement when it was drafted, but it wasn't dropped from the sky by unaccountable people just to inconvenience you. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Feb 26 08:36:29 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 26 Feb 2014 00:36:29 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Tue, Feb 25, 2014 at 11:11 PM, Michael Snoyman wrote: > > > > On Wed, Feb 26, 2014 at 8:03 AM, John Lato wrote: > >> On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman wrote: >> >>> >>> >>> On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: >>> >>>> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez wrote: >>>> > >>>> > I'm not saying this is not painful, but i've done it in the past, and >>>> using >>>> > dichotomy and educated guesses (for example not using libraries >>>> released >>>> > after a certain date), you converge pretty quickly on a solution. >>>> > >>>> > But the bottom line is that it's not the common use case. I rarely >>>> have to >>>> > dig old unused code. >>>> >>>> And I have code that I would like to have working today, but it's too >>>> expensive to go through this process. The code has significant value >>>> to me and other people, but not enough to justify the large cost of >>>> getting it working again. >>>> >>>> >>> >>> I think we need to make these cases more concrete to have a meaningful >>> discussion. Between Doug and Gregory, I'm understanding two different use >>> cases: >>> >>> 1. Existing, legacy code, built again some historical version of >>> Hackage, without information on the exact versions of all deep dependencies. >>> 2. Someone starting a new project who wants to use an older version of a >>> package on Hackage. >>> >>> If I've missed a use case, please describe it. >>> >>> For (1), let's start with the time machine game: *if* everyone had been >>> using the PVP, then theoretically this wouldn't have happened. And *if* the >>> developers had followed proper practice and documented their complete build >>> environment, then PVP compliance would be irrelevant. So if we could go >>> back in time and twist people's arms, no problems would exist. Hurray, >>> we've established that 20/20 hindsight is very nice :). >>> >>> But what can be done today? Actually, I think the solution is a very >>> simple tool, and I'll be happy to write it if people want: >>> cabal-timemachine. It takes a timestamp, and then deletes all cabal files >>> from our 00-index.tar file that represent packages uploaded after that >>> date. Assuming you know the last date of a successful build, it should be >>> trivial to get a build going again. And if you *don't* know the date, you >>> can bisect until you get a working build. (For that matter, the tool could >>> even *include* a bisecter in it.) Can anyone picture a scenario where this >>> wouldn't solve the problem even better than PVP compliance? >>> >> >> This scenario is never better than PVP compliance. First of all, the >> user may want some packages that are newer than the timestamp, which this >> wouldn't support. As people have already mentioned, it's entirely possible >> for valid install graphs to exist that cabal will fail to find if it >> doesn't have upper bound information available, because it finds other >> *invalid* graphs. >> >> And even aside from that issue, this would push the work of making sure >> that a library is compatible with its dependencies onto the library >> *users*, instead of the developer, where it rightfully belongs (and your >> proposal ends up pushing even more work onto users!). >> >> Why do you think it's acceptable for users to do the testing to make sure >> that your code works with other packages that your code requires? >> > > You're not at all addressing the case I described. The case was a legacy > project that someone is trying to rebuild. I'm not talking about any other > case in this scenario. To repeat myself: > > > 1. Existing, legacy code, built again some historical version of > Hackage, without information on the exact versions of all deep dependencies. > > In *that specific case*, why wouldn't having a tool to go back in time and > build against a historical version of Hackage be *exactly* what you'd need > to rebuild the project? > I had understood people talking about "legacy projects" to mean something other than how you read it. In which case, I would suggest that there is a third use case, which IMHO is more important than either of the use cases you have identified. Here's an example: 1. package foo-0.1 appears on hackage 2. package bar-0.1 appears on hackage with a dependency on foo >= 0.1 3. awesomeApp-0.1 appears on hackage, which depends on bar-0.1 and text>=1.0 4. users install awesomeApp 5. package foo-0.2 appears on hackage, with lots of breaking changes 6. awesomeApp users notice that it sometimes breaks with Hungarian characters, and the problem is traced to an error in text 6. text-1.0.0.1 is released with some bug fixes 7. awesomeApp users attempt to do cabal update; cabal install, which fails inscrutably (because it tries to mix foo-0.2 with bar-0.1) There's nothing in this situation that requires any of these packages be unmaintained. The problem is that, rather than wanting to reproduce a fixed set of package versions (which cabal already allows for if that's really desired), sometimes it's desirable that updates be held back in active code bases. Replace "foo" with "QuickCheck" for example (where for a long time users stayed with quickcheck2 because version 3 had major performance regressions in certain use cases). This sort of conflict used to happen *all the time*, and it's very frustrating to users (because something worked before, now it's not working, and they're not generally in a good position to know why). It's annoying to reproduce because the install graph cabal produces depends in part on the user's installed packages. So just because something builds on a developer's box doesn't mean that it would build on the user's box, or it would work for some users but not others (sandboxing has at least helped with that problem). > >> >>> For (2), talking about older versions of a package is not relevant. I >>> actively maintain a number of my older package releases, as I'm sure others >>> do as well. The issue isn't about *age* of a package, but about >>> *maintenance* of a package. And we simply shouldn't be encouraging users to >>> start off with an unmaintained version of a package. This is a completely >>> separate discussion from the legacy code base, where- despite the valid >>> security and bug concerns Vincent raised- it's likely not worth updating to >>> the latest and greatest. >>> >> >> Usually the case is not that somebody *wants* to use an older version of >> package 'foo', it's that they're using some package 'bar' which hasn't yet >> been updated to be compatible with the latest 'foo'. There are all sorts >> of reasons this may happen, including big API shifts (e.g. parsec2/parsec3, >> openGL), poor timing in a maintenance cycle, and the usual worldly >> distractions. But if packages have upper bounds, the user can 'cabal >> install', get a coherent package graph, and begin working. At the very >> worst, cabal will give them a clear lead as to what needs to be updated/who >> to ping. This is much better than the situation with no upper bounds, >> where a 'cabal install' may fail miserably or even put together code that >> produces garbage. >> >> And again, it's the library *user* who ends up having to deal with these >> problems. Upper bounds lead to a better user experience. >> > > I disagree with that assertion. I get plenty of complaints from users > about trying to install packages and getting "confusing error messages" > about cabal plan mismatches. I don't disagree that the PVP does make the > user experience better in some cases. What I disagree with is the > implication that it makes the user experience better in *all* cases. This > is simply not a black-and-white issue. > That's a straw man, I don't think anyone has argued that they make the user experience better in *all* cases. The PVP helps significantly, it avoids especially problematic situations like the one above, and in particular it's quite easy for the developer to fix the simple cases. Unlike the 2006 status quo, when problems required manually solving the dependency graph. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Feb 26 09:05:35 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 26 Feb 2014 10:05:35 +0100 Subject: qualified imports, PVP and so on In-Reply-To: (Michael Snoyman's message of "Wed, 26 Feb 2014 07:45:30 +0200") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> Message-ID: <87vbw2s0ps.fsf@gnu.org> On 2014-02-26 at 06:45:30 +0100, Michael Snoyman wrote: > On Wed, Feb 26, 2014 at 12:52 AM, Herbert Valerio Riedel wrote: >> On 2014-02-25 at 21:38:38 +0100, Michael Snoyman wrote: >> >> [...] >> >> > * The PVP itself does *not* guarantee reliable builds in all cases. If a >> > transitive dependency introduces new exports, or provides new typeclass >> > instances, a fully PVP-compliant stack can be broken. (If anyone doubts >> > this claim, let me know, I can spell out the details. This has come up in >> > practice.) >> >> ...are you simply referring to the fact that in order to guarantee >> PVP-semantics of a package version, one has to take care to restrict the >> version bounds of that package's build-deps in such a way, that any API >> entities leaking from its (direct) build-deps (e.g. typeclass instances >> or other re-exported entities) are not a function of the "internal" >> degree of freedoms the build-dep version-ranges provide? Or is there >> more to it? > > That's essentially it. I'll give one of the examples I ran into. (Names > omitted on purpose, if the involved party wants to identify himself, please > do so, I just didn't feel comfortable doing so without your permission.) > Version 0.2 of monad-logger included MonadLogger instances for IO and other > base monads. For various reasons, these were removed, and the version > bumped to 0.3. This is in full compliance with the PVP. > > persistent depends on monad-logger. It can work with either version 0.2 or > 0.3 of monad-logger, and the cabal file allows this via `monad-logger >= > 0.2 && < 0.4` (or something like that). Again, full PVP compliance. > > A user wrote code against persistent when monad-logger version 0.2 was > available. He used a function that looked like: > > runDatabase :: MonadLogger m => Persistent a -> m a > > (highly simplified). In his application, he used this in the IO monad. He > depended on persistent with proper lower and upper bounds. Once again, full > PVP compliance. > > Once I released version 0.3 of monad-logger, his next build automatically > upgraded him to monad-logger 0.3, and suddenly his code broke, because > there's no MonadLogger instance for IO. > > Now *if* the program had been using a system like "cabal freeze" or the > like, this could have never happened: cabal wouldn't be trying to > automatically upgrade to monad-logger 0.3. > > Will this kind of bug happen all the time? No, I doubt it. But if the point > of the PVP is to guarantee that builds will work (ignoring runtime > concerns), and the PVP clearly fails at that job as well, we really need to > reassess putting ourselves through this pain and suffering. >From my point of view, I'd argue that a) 'persistent' failed to live up to the "spirit" of the PVP contract, i.e. to expose a "contact-surface" which satisfies certain invariants within specific package-version ranges. b) However, the PVP can be blamed as well, as in its current form it doesn't explicitly address the issue of API-leakage from transitive build-dependencies. [1] The question for me now is whether the PVP is fixable in this respect, and at what cost. Moreover, it seems to me, it always comes down to type-class instances causing most problems with the PVP (either by requiring version-bump cascades throughout the PVP-adhering domain of Hackage, or by their hard hard to constraint leakage through package module/boundaries); maybe we need address this issue at the language-level and provide some facility for limiting the propagation of type-class instances first. [1]: An alternative to what I'm suggesting in 'a)' (i.e. that it'd be `persistent`'s obligation), could be that the package you mentioned (which broke due to monad-logger having a non-monotonic API change), might become required to include packages supplying the instances they depends upon in their build-depends, thus turning an transitive dep into a direct dependency. Cheers, hvr From johan.tibell at gmail.com Wed Feb 26 09:17:22 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 26 Feb 2014 10:17:22 +0100 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> Message-ID: Hi Michael, On Wed, Feb 26, 2014 at 6:45 AM, Michael Snoyman wrote: > That's essentially it. I'll give one of the examples I ran into. (Names > omitted on purpose, if the involved party wants to identify himself, please > do so, I just didn't feel comfortable doing so without your permission.) > Version 0.2 of monad-logger included MonadLogger instances for IO and other > base monads. For various reasons, these were removed, and the version > bumped to 0.3. This is in full compliance with the PVP. > > persistent depends on monad-logger. It can work with either version 0.2 or > 0.3 of monad-logger, and the cabal file allows this via `monad-logger >= > 0.2 && < 0.4` (or something like that). Again, full PVP compliance. > > A user wrote code against persistent when monad-logger version 0.2 was > available. He used a function that looked like: > > runDatabase :: MonadLogger m => Persistent a -> m a > > (highly simplified). In his application, he used this in the IO monad. He > depended on persistent with proper lower and upper bounds. Once again, full > PVP compliance. > > Once I released version 0.3 of monad-logger, his next build automatically > upgraded him to monad-logger 0.3, and suddenly his code broke, because > there's no MonadLogger instance for IO. > > Now *if* the program had been using a system like "cabal freeze" or the > like, this could have never happened: cabal wouldn't be trying to > automatically upgrade to monad-logger 0.3. > I'm trying to wrap my head around this. * Is runDatabase above a function in persistent or related packages or a function that the user wrote? * What was the user's dependency range for monad-logger? If he is using the IO instance of MonadLogger from monad-logger, he ought to have a monad-logger == 2.0.* dependency (since removing instances require a major version bump.) * Does any involved package use orphan instances? Cheers, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 09:37:43 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 11:37:43 +0200 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 11:17 AM, Johan Tibell wrote: > Hi Michael, > > On Wed, Feb 26, 2014 at 6:45 AM, Michael Snoyman wrote: > >> That's essentially it. I'll give one of the examples I ran into. (Names >> omitted on purpose, if the involved party wants to identify himself, please >> do so, I just didn't feel comfortable doing so without your permission.) >> Version 0.2 of monad-logger included MonadLogger instances for IO and other >> base monads. For various reasons, these were removed, and the version >> bumped to 0.3. This is in full compliance with the PVP. >> >> persistent depends on monad-logger. It can work with either version 0.2 >> or 0.3 of monad-logger, and the cabal file allows this via `monad-logger >= >> 0.2 && < 0.4` (or something like that). Again, full PVP compliance. >> >> A user wrote code against persistent when monad-logger version 0.2 was >> available. He used a function that looked like: >> >> runDatabase :: MonadLogger m => Persistent a -> m a >> >> (highly simplified). In his application, he used this in the IO monad. He >> depended on persistent with proper lower and upper bounds. Once again, full >> PVP compliance. >> >> Once I released version 0.3 of monad-logger, his next build automatically >> upgraded him to monad-logger 0.3, and suddenly his code broke, because >> there's no MonadLogger instance for IO. >> >> Now *if* the program had been using a system like "cabal freeze" or the >> like, this could have never happened: cabal wouldn't be trying to >> automatically upgrade to monad-logger 0.3. >> > > I'm trying to wrap my head around this. > > * Is runDatabase above a function in persistent or related packages or a > function that the user wrote? > It was in persistent. The actual function name is different, but the concept is the same. > * What was the user's dependency range for monad-logger? If he is using > the IO instance of MonadLogger from monad-logger, he ought to have a > monad-logger == 2.0.* dependency (since removing instances require a major > version bump.) > The user didn't directly depend on monad-logger at all, as there was no need with version 0.2 of monad-logger. > * Does any involved package use orphan instances? > > Nope, no orphans at all. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 09:45:40 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 11:45:40 +0200 Subject: qualified imports, PVP and so on In-Reply-To: <87vbw2s0ps.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 11:05 AM, Herbert Valerio Riedel wrote: > On 2014-02-26 at 06:45:30 +0100, Michael Snoyman wrote: > > On Wed, Feb 26, 2014 at 12:52 AM, Herbert Valerio Riedel wrote: > >> On 2014-02-25 at 21:38:38 +0100, Michael Snoyman wrote: > >> > >> [...] > >> > >> > * The PVP itself does *not* guarantee reliable builds in all cases. > If a > >> > transitive dependency introduces new exports, or provides new > typeclass > >> > instances, a fully PVP-compliant stack can be broken. (If anyone > doubts > >> > this claim, let me know, I can spell out the details. This has come > up in > >> > practice.) > >> > >> ...are you simply referring to the fact that in order to guarantee > >> PVP-semantics of a package version, one has to take care to restrict the > >> version bounds of that package's build-deps in such a way, that any API > >> entities leaking from its (direct) build-deps (e.g. typeclass instances > >> or other re-exported entities) are not a function of the "internal" > >> degree of freedoms the build-dep version-ranges provide? Or is there > >> more to it? > > > > That's essentially it. I'll give one of the examples I ran into. (Names > > omitted on purpose, if the involved party wants to identify himself, > please > > do so, I just didn't feel comfortable doing so without your permission.) > > Version 0.2 of monad-logger included MonadLogger instances for IO and > other > > base monads. For various reasons, these were removed, and the version > > bumped to 0.3. This is in full compliance with the PVP. > > > > persistent depends on monad-logger. It can work with either version 0.2 > or > > 0.3 of monad-logger, and the cabal file allows this via `monad-logger >= > > 0.2 && < 0.4` (or something like that). Again, full PVP compliance. > > > > A user wrote code against persistent when monad-logger version 0.2 was > > available. He used a function that looked like: > > > > runDatabase :: MonadLogger m => Persistent a -> m a > > > > (highly simplified). In his application, he used this in the IO monad. He > > depended on persistent with proper lower and upper bounds. Once again, > full > > PVP compliance. > > > > Once I released version 0.3 of monad-logger, his next build automatically > > upgraded him to monad-logger 0.3, and suddenly his code broke, because > > there's no MonadLogger instance for IO. > > > > Now *if* the program had been using a system like "cabal freeze" or the > > like, this could have never happened: cabal wouldn't be trying to > > automatically upgrade to monad-logger 0.3. > > > > Will this kind of bug happen all the time? No, I doubt it. But if the > point > > of the PVP is to guarantee that builds will work (ignoring runtime > > concerns), and the PVP clearly fails at that job as well, we really need > to > > reassess putting ourselves through this pain and suffering. > > From my point of view, I'd argue that > > a) 'persistent' failed to live up to the "spirit" of the PVP contract, > i.e. to expose a "contact-surface" which satisfies certain > invariants within specific package-version ranges. > > How would persistent have done better? AFAICT, the options are: 1. Do what I did: state a true version dependency on monad-logger, that it works with both version 0.2 and 0.3. 2. Constrain it to one or the other, which would be a falsehood that would restrict users' ability to use the package. Let's try it a different way. If transformers removed a MonadIO instance between version 2 and 3 of the library, should that mean that every single package with type signatures involving MonadIO should be constrained to one specific version of transformers? > b) However, the PVP can be blamed as well, as in its current form it > doesn't explicitly address the issue of API-leakage from transitive > build-dependencies. [1] > > The question for me now is whether the PVP is fixable in this respect, > and at what cost. > > Moreover, it seems to me, it always comes down to type-class instances > causing most problems with the PVP (either by requiring version-bump > cascades throughout the PVP-adhering domain of Hackage, or by their hard > hard to constraint leakage through package module/boundaries); maybe we > need address this issue at the language-level and provide some facility > for limiting the propagation of type-class instances first. > > There's one other issue, which is reexports. As an extreme example, imagine: * Version 1 of the foo package has the Foo module, and it exports foo1 and foo2. * Version 2 of the foo package has the Foo module, and it exports foo1. * Version 1 of the bar package as the Bar module, defined as: module Bar (module Foo) where import Foo * According to the PVP, the bar package can have a version bound on foo of `foo > 1 && < 2.1`. * User code that depends on foo2 being exported from Bar will be broken by the transitive update of foo. The example's extreme, but it's the same basic problem as typeclass instances. Michael > > > [1]: An alternative to what I'm suggesting in 'a)' (i.e. that it'd be > `persistent`'s obligation), could be that the package you > mentioned (which broke due to monad-logger having a non-monotonic > API change), might become required to include packages supplying > the instances they depends upon in their build-depends, thus > turning an transitive dep into a direct dependency. > > I don't think I follow this comment, sorry. > Cheers, > hvr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 09:56:58 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 11:56:58 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 10:36 AM, John Lato wrote: > On Tue, Feb 25, 2014 at 11:11 PM, Michael Snoyman wrote: > >> >> >> >> On Wed, Feb 26, 2014 at 8:03 AM, John Lato wrote: >> >>> On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman wrote: >>> >>>> >>>> >>>> On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: >>>> >>>>> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez >>>>> wrote: >>>>> > >>>>> > I'm not saying this is not painful, but i've done it in the past, >>>>> and using >>>>> > dichotomy and educated guesses (for example not using libraries >>>>> released >>>>> > after a certain date), you converge pretty quickly on a solution. >>>>> > >>>>> > But the bottom line is that it's not the common use case. I rarely >>>>> have to >>>>> > dig old unused code. >>>>> >>>>> And I have code that I would like to have working today, but it's too >>>>> expensive to go through this process. The code has significant value >>>>> to me and other people, but not enough to justify the large cost of >>>>> getting it working again. >>>>> >>>>> >>>> >>>> I think we need to make these cases more concrete to have a meaningful >>>> discussion. Between Doug and Gregory, I'm understanding two different use >>>> cases: >>>> >>>> 1. Existing, legacy code, built again some historical version of >>>> Hackage, without information on the exact versions of all deep dependencies. >>>> 2. Someone starting a new project who wants to use an older version of >>>> a package on Hackage. >>>> >>>> If I've missed a use case, please describe it. >>>> >>>> For (1), let's start with the time machine game: *if* everyone had been >>>> using the PVP, then theoretically this wouldn't have happened. And *if* the >>>> developers had followed proper practice and documented their complete build >>>> environment, then PVP compliance would be irrelevant. So if we could go >>>> back in time and twist people's arms, no problems would exist. Hurray, >>>> we've established that 20/20 hindsight is very nice :). >>>> >>>> But what can be done today? Actually, I think the solution is a very >>>> simple tool, and I'll be happy to write it if people want: >>>> cabal-timemachine. It takes a timestamp, and then deletes all cabal files >>>> from our 00-index.tar file that represent packages uploaded after that >>>> date. Assuming you know the last date of a successful build, it should be >>>> trivial to get a build going again. And if you *don't* know the date, you >>>> can bisect until you get a working build. (For that matter, the tool could >>>> even *include* a bisecter in it.) Can anyone picture a scenario where this >>>> wouldn't solve the problem even better than PVP compliance? >>>> >>> >>> This scenario is never better than PVP compliance. First of all, the >>> user may want some packages that are newer than the timestamp, which this >>> wouldn't support. As people have already mentioned, it's entirely possible >>> for valid install graphs to exist that cabal will fail to find if it >>> doesn't have upper bound information available, because it finds other >>> *invalid* graphs. >>> >>> And even aside from that issue, this would push the work of making sure >>> that a library is compatible with its dependencies onto the library >>> *users*, instead of the developer, where it rightfully belongs (and your >>> proposal ends up pushing even more work onto users!). >>> >>> Why do you think it's acceptable for users to do the testing to make >>> sure that your code works with other packages that your code requires? >>> >> >> You're not at all addressing the case I described. The case was a legacy >> project that someone is trying to rebuild. I'm not talking about any other >> case in this scenario. To repeat myself: >> >> > 1. Existing, legacy code, built again some historical version of >> Hackage, without information on the exact versions of all deep dependencies. >> >> In *that specific case*, why wouldn't having a tool to go back in time >> and build against a historical version of Hackage be *exactly* what you'd >> need to rebuild the project? >> > > I had understood people talking about "legacy projects" to mean something > other than how you read it. In which case, I would suggest that there is a > third use case, which IMHO is more important than either of the use cases > you have identified. Here's an example: > > 1. package foo-0.1 appears on hackage > 2. package bar-0.1 appears on hackage with a dependency on foo >= 0.1 > 3. awesomeApp-0.1 appears on hackage, which depends on bar-0.1 and > text>=1.0 > 4. users install awesomeApp > 5. package foo-0.2 appears on hackage, with lots of breaking changes > 6. awesomeApp users notice that it sometimes breaks with Hungarian > characters, and the problem is traced to an error in text > 6. text-1.0.0.1 is released with some bug fixes > 7. awesomeApp users attempt to do cabal update; cabal install, which > fails inscrutably (because it tries to mix foo-0.2 with bar-0.1) > > There's nothing in this situation that requires any of these packages be > unmaintained. The problem is that, rather than wanting to reproduce a > fixed set of package versions (which cabal already allows for if that's > really desired), sometimes it's desirable that updates be held back in > active code bases. Replace "foo" with "QuickCheck" for example (where for > a long time users stayed with quickcheck2 because version 3 had major > performance regressions in certain use cases). > > This sort of conflict used to happen *all the time*, and it's very > frustrating to users (because something worked before, now it's not > working, and they're not generally in a good position to know why). It's > annoying to reproduce because the install graph cabal produces depends in > part on the user's installed packages. So just because something builds on > a developer's box doesn't mean that it would build on the user's box, or it > would work for some users but not others (sandboxing has at least helped > with that problem). > > IIUC, this is *exactly* the case of an unmaintained package. I'm not advocating leaving a package like bar-0.1 on Hackage without an upper bound on foo, if it's known that it breaks in that case. In order for the package to be properly maintained, the maintainer would have to (1) make bar work with foo-0.2, or (2) add an upper bound. So to me, this falls squarely into the category of unmaintained. Let me relax my position just a bit. If package maintainers are not going to be responsive to updates in the Hackage ecosystem, then I agree that they should use the PVP. I also think they should advertise their packages as not being actively maintained, and people should try to avoid using them if possible. But if an author is giving quick updates to packages, I don't see a huge benefit to the PVP for users, and instead see some downsides (inability to test against newer dependencies), not to mention the much higher maintenance burden for library authors. >> >>> >>>> For (2), talking about older versions of a package is not relevant. I >>>> actively maintain a number of my older package releases, as I'm sure others >>>> do as well. The issue isn't about *age* of a package, but about >>>> *maintenance* of a package. And we simply shouldn't be encouraging users to >>>> start off with an unmaintained version of a package. This is a completely >>>> separate discussion from the legacy code base, where- despite the valid >>>> security and bug concerns Vincent raised- it's likely not worth updating to >>>> the latest and greatest. >>>> >>> >>> Usually the case is not that somebody *wants* to use an older version of >>> package 'foo', it's that they're using some package 'bar' which hasn't yet >>> been updated to be compatible with the latest 'foo'. There are all sorts >>> of reasons this may happen, including big API shifts (e.g. parsec2/parsec3, >>> openGL), poor timing in a maintenance cycle, and the usual worldly >>> distractions. But if packages have upper bounds, the user can 'cabal >>> install', get a coherent package graph, and begin working. At the very >>> worst, cabal will give them a clear lead as to what needs to be updated/who >>> to ping. This is much better than the situation with no upper bounds, >>> where a 'cabal install' may fail miserably or even put together code that >>> produces garbage. >>> >>> And again, it's the library *user* who ends up having to deal with these >>> problems. Upper bounds lead to a better user experience. >>> >> >> I disagree with that assertion. I get plenty of complaints from users >> about trying to install packages and getting "confusing error messages" >> about cabal plan mismatches. I don't disagree that the PVP does make the >> user experience better in some cases. What I disagree with is the >> implication that it makes the user experience better in *all* cases. This >> is simply not a black-and-white issue. >> > > That's a straw man, I don't think anyone has argued that they make the > user experience better in *all* cases. The PVP helps significantly, it > avoids especially problematic situations like the one above, and in > particular it's quite easy for the developer to fix the simple cases. > Unlike the 2006 status quo, when problems required manually solving the > dependency graph. > You said: > Upper bounds lead to a better user experience. That's what I'm disagreeing with. I do not believe that, overall, the PVP is giving users a better experience. I've had a huge downturn in reported errors with Yesod since I stopped strictly following the PVP. It's anecdotal, but everything in this thread is really anecdotal. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Feb 26 10:22:01 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 26 Feb 2014 11:22:01 +0100 Subject: qualified imports, PVP and so on In-Reply-To: (Michael Snoyman's message of "Wed, 26 Feb 2014 11:45:40 +0200") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> Message-ID: <87ob1urx6e.fsf@gnu.org> On 2014-02-26 at 10:45:40 +0100, Michael Snoyman wrote: [...] >> >> ...are you simply referring to the fact that in order to guarantee >> >> PVP-semantics of a package version, one has to take care to restrict the >> >> version bounds of that package's build-deps in such a way, that any API >> >> entities leaking from its (direct) build-deps (e.g. typeclass instances >> >> or other re-exported entities) are not a function of the "internal" >> >> degree of freedoms the build-dep version-ranges provide? Or is there >> >> more to it? [...] >> From my point of view, I'd argue that >> >> a) 'persistent' failed to live up to the "spirit" of the PVP contract, >> i.e. to expose a "contact-surface" which satisfies certain >> invariants within specific package-version ranges. > How would persistent have done better? AFAICT, the options are: > > 1. Do what I did: state a true version dependency on monad-logger, that it > works with both version 0.2 and 0.3. Yes, "persistent" itself does in fact work with both major versions of "monad-logger", but alas the API reachable through depending solely on "persistent" leaks details of the underlying monad-logger version used. ...but the PVP's primary statement is define how a package shall behave from the point of view of its users (where by user I mean package build-depending on `persistent`). So... > 2. Constrain it to one or the other, which would be a falsehood that would > restrict users' ability to use the package. ...this is would actually be, what I'd interpret the PVP to expect/require from "persistent" in order to satisfy its goal to shield the package's users from incompatible changes. > Let's try it a different way. If transformers removed a MonadIO instance > between version 2 and 3 of the library, should that mean that every single > package with type signatures involving MonadIO should be constrained to one > specific version of transformers? yes, that'd be what I'm suggesting here (the [1] footnote is a different suggestion for the same problem though) >> b) However, the PVP can be blamed as well, as in its current form it >> doesn't explicitly address the issue of API-leakage from transitive >> build-dependencies. [1] >> >> The question for me now is whether the PVP is fixable in this respect, >> and at what cost. >> >> Moreover, it seems to me, it always comes down to type-class instances >> causing most problems with the PVP (either by requiring version-bump >> cascades throughout the PVP-adhering domain of Hackage, or by their hard >> hard to constraint leakage through package module/boundaries); maybe we >> need address this issue at the language-level and provide some facility >> for limiting the propagation of type-class instances first. >> >> > There's one other issue, which is reexports. As an extreme example, imagine: > > * Version 1 of the foo package has the Foo module, and it exports foo1 and > foo2. > * Version 2 of the foo package has the Foo module, and it exports foo1. > * Version 1 of the bar package as the Bar module, defined as: Yes, I'm well aware of this problem, but that's easier to control, as you can use explicit import/export lists to constraint what entities you expose to direct users of your package. That's what I'm doing e.g. in http://hackage.haskell.org/package/deepseq-generics-0.1.1.1/docs/Control-DeepSeq-Generics.html where I'm explicitly naming the entities I re-export from Control.DeepSeq for convenience. (However, I'm lacking such a facility for instances) > > module Bar (module Foo) where > import Foo > * According to the PVP, the bar package can have a version bound on foo of > `foo > 1 && < 2.1`. > * User code that depends on foo2 being exported from Bar will be broken by > the transitive update of foo. > > The example's extreme, but it's the same basic problem as typeclass > instances. [...] >> [1]: An alternative to what I'm suggesting in 'a)' (i.e. that it'd be >> `persistent`'s obligation), could be that the package you >> mentioned (which broke due to monad-logger having a non-monotonic >> API change), might become required to include packages supplying >> the instances they depends upon in their build-depends, thus >> turning an transitive dep into a direct dependency. > I don't think I follow this comment, sorry. I'm basically just saying, that the package which used "persistent", ought to add "monad-logger ==0.2.*" to its direct build-dependencies, as it depends on an instance provided by monad-logger. The huge down-side is, that you'd have to know about type-class instances leaked through persistent, in order to know that'd you have to add some of "persistent"'s transitive build-depends to your own package, in order to safe yourself from missing out on type-class instances. From michael at snoyman.com Wed Feb 26 10:42:28 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 12:42:28 +0200 Subject: qualified imports, PVP and so on In-Reply-To: <87ob1urx6e.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 12:22 PM, Herbert Valerio Riedel wrote: > On 2014-02-26 at 10:45:40 +0100, Michael Snoyman wrote: > > [...] > > >> >> ...are you simply referring to the fact that in order to guarantee > >> >> PVP-semantics of a package version, one has to take care to restrict > the > >> >> version bounds of that package's build-deps in such a way, that any > API > >> >> entities leaking from its (direct) build-deps (e.g. typeclass > instances > >> >> or other re-exported entities) are not a function of the "internal" > >> >> degree of freedoms the build-dep version-ranges provide? Or is there > >> >> more to it? > > [...] > > >> From my point of view, I'd argue that > >> > >> a) 'persistent' failed to live up to the "spirit" of the PVP contract, > >> i.e. to expose a "contact-surface" which satisfies certain > >> invariants within specific package-version ranges. > > > How would persistent have done better? AFAICT, the options are: > > > > 1. Do what I did: state a true version dependency on monad-logger, that > it > > works with both version 0.2 and 0.3. > > Yes, "persistent" itself does in fact work with both major versions of > "monad-logger", but alas the API reachable through depending solely on > "persistent" leaks details of the underlying monad-logger version used. > > ...but the PVP's primary statement is define how a package shall behave > from the point of view of its users (where by user I mean package > build-depending on `persistent`). So... > > > 2. Constrain it to one or the other, which would be a falsehood that > would > > restrict users' ability to use the package. > > ...this is would actually be, what I'd interpret the PVP to > expect/require from "persistent" in order to satisfy its goal to shield > the package's users from incompatible changes. > > > Let's try it a different way. If transformers removed a MonadIO instance > > between version 2 and 3 of the library, should that mean that every > single > > package with type signatures involving MonadIO should be constrained to > one > > specific version of transformers? > > yes, that'd be what I'm suggesting here (the [1] footnote is a different > suggestion for the same problem though) > > So let's analyze how far you want to go here. Imagine if version 0.3.0 of transformers did not have a MonadIO instance for StateT, and version 0.3.1 added it. Now some library has a function: myFunc :: MonadIO m => Int -> m String What versions of transformers is it allowed to work with? If it allows version 0.3.0 and 0.3.1, and a user depends on the presence of the MonadIO StateT instance, the build can be broken by moving back to version 0.3.0 (which may be demanded by some other packages dependencies). This is simply the reverse of the monad-logger situation, where an instance was added instead of being removed. I don't see a reasonable solution to this situation... well, besides everyone just trusting a curator to build all of these packages for them. And just to be clear: if persistent had bumped its lower version bound on monad-logger, then users still on the old version of monad-logger would be unable to upgrade, and for no real reason. persistent would have required a major version bump most likely[1], which would have caused all packages downstream from it to do version bumps as well. Forgetting about my position as a library author, or as a Stackage maintainer, and speaking purely as a library *user*, this would be a terrible situation to be in. [1] That's another hole in the PVP I think. It doesn't explicitly address the issue of an API change by eliminating compatibility with a previously accepted dependency, but I've seen huge breakages occur due to this. > >> b) However, the PVP can be blamed as well, as in its current form it > >> doesn't explicitly address the issue of API-leakage from transitive > >> build-dependencies. [1] > >> > >> The question for me now is whether the PVP is fixable in this respect, > >> and at what cost. > >> > >> Moreover, it seems to me, it always comes down to type-class instances > >> causing most problems with the PVP (either by requiring version-bump > >> cascades throughout the PVP-adhering domain of Hackage, or by their hard > >> hard to constraint leakage through package module/boundaries); maybe we > >> need address this issue at the language-level and provide some facility > >> for limiting the propagation of type-class instances first. > >> > >> > > There's one other issue, which is reexports. As an extreme example, > imagine: > > > > * Version 1 of the foo package has the Foo module, and it exports foo1 > and > > foo2. > > * Version 2 of the foo package has the Foo module, and it exports foo1. > > * Version 1 of the bar package as the Bar module, defined as: > > Yes, I'm well aware of this problem, but that's easier to control, as > you can use explicit import/export lists to constraint what entities you > expose to direct users of your package. That's what I'm doing e.g. in > > > http://hackage.haskell.org/package/deepseq-generics-0.1.1.1/docs/Control-DeepSeq-Generics.html > > where I'm explicitly naming the entities I re-export from > Control.DeepSeq for convenience. (However, I'm lacking such a facility > for instances) > > Agreed, the reexport issue is something that can be dealt with, whereas typeclasses don't have such a facility right now. I just wanted to point it out to make sure we were considering all issues. > > > > module Bar (module Foo) where > > import Foo > > * According to the PVP, the bar package can have a version bound on foo > of > > `foo > 1 && < 2.1`. > > * User code that depends on foo2 being exported from Bar will be broken > by > > the transitive update of foo. > > > > The example's extreme, but it's the same basic problem as typeclass > > instances. > > [...] > > >> [1]: An alternative to what I'm suggesting in 'a)' (i.e. that it'd be > >> `persistent`'s obligation), could be that the package you > >> mentioned (which broke due to monad-logger having a non-monotonic > >> API change), might become required to include packages supplying > >> the instances they depends upon in their build-depends, thus > >> turning an transitive dep into a direct dependency. > > > I don't think I follow this comment, sorry. > > I'm basically just saying, that the package which used "persistent", > ought to add "monad-logger ==0.2.*" to its direct build-dependencies, as > it depends on an instance provided by monad-logger. The huge down-side > is, that you'd have to know about type-class instances leaked through > persistent, in order to know that'd you have to add some of > "persistent"'s transitive build-depends to your own package, in order to > safe yourself from missing out on type-class instances. > And my approach is that the only sane way to create repeatable builds is to *always* list the exact versions of all packages you depend upon. And in my opinion, it's far more important to ensure that the code behaves the same way than that it simply builds. The only real way to do that is to always use the same versions of all dependencies. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Feb 26 10:50:18 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 26 Feb 2014 11:50:18 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 10:56 AM, Michael Snoyman wrote: > On Wed, Feb 26, 2014 at 10:36 AM, John Lato wrote: >> Upper bounds lead to a better user experience. > > That's what I'm disagreeing with. I do not believe that, overall, the PVP is > giving users a better experience. I've had a huge downturn in reported > errors with Yesod since I stopped strictly following the PVP. It's > anecdotal, but everything in this thread is really anecdotal. But you also tell people to use stackage and yesod-platform, which fixes a lot of packages to a specific version, IIRC. That means that not having upper bounds is kind of moot. As a counter-anecdote, almost all build-related problems we've had in the past year have been (http-)conduit or tls related, due to the lack of upper bounds. Erik From michael at snoyman.com Wed Feb 26 10:55:42 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 12:55:42 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 12:50 PM, Erik Hesselink wrote: > On Wed, Feb 26, 2014 at 10:56 AM, Michael Snoyman > wrote: > > On Wed, Feb 26, 2014 at 10:36 AM, John Lato wrote: > >> Upper bounds lead to a better user experience. > > > > That's what I'm disagreeing with. I do not believe that, overall, the > PVP is > > giving users a better experience. I've had a huge downturn in reported > > errors with Yesod since I stopped strictly following the PVP. It's > > anecdotal, but everything in this thread is really anecdotal. > > But you also tell people to use stackage and yesod-platform, which > fixes a lot of packages to a specific version, IIRC. That means that > not having upper bounds is kind of moot. > > As a counter-anecdote, almost all build-related problems we've had in > the past year have been (http-)conduit or tls related, due to the lack > of upper bounds. > > Erik > That's a fair point, I left out X factors in this analysis. So I'll say something else instead: back when I followed strict PVP compliance, I still got a lot of reports of broken builds, and my maintenance overhead was very high. Since I dropped PVP compliance and implemented alternative solutions, the reports I've received have gone down dramatically, and I spend far less time on maintenance. So color me unconvinced that the PVP really made a big difference in users' experiences. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Wed Feb 26 11:47:32 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Wed, 26 Feb 2014 11:47:32 +0000 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: > On Feb 26, 2014, at 7:11, Michael Snoyman wrote: > > > > >> On Wed, Feb 26, 2014 at 8:03 AM, John Lato wrote: >>> On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman wrote: >>> >>> >>>> On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: >>>> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez wrote: >>>> > >>>> > I'm not saying this is not painful, but i've done it in the past, and using >>>> > dichotomy and educated guesses (for example not using libraries released >>>> > after a certain date), you converge pretty quickly on a solution. >>>> > >>>> > But the bottom line is that it's not the common use case. I rarely have to >>>> > dig old unused code. >>>> >>>> And I have code that I would like to have working today, but it's too >>>> expensive to go through this process. The code has significant value >>>> to me and other people, but not enough to justify the large cost of >>>> getting it working again. >>> >>> >>> I think we need to make these cases more concrete to have a meaningful discussion. Between Doug and Gregory, I'm understanding two different use cases: >>> >>> 1. Existing, legacy code, built again some historical version of Hackage, without information on the exact versions of all deep dependencies. >>> 2. Someone starting a new project who wants to use an older version of a package on Hackage. >>> >>> If I've missed a use case, please describe it. >>> >>> For (1), let's start with the time machine game: *if* everyone had been using the PVP, then theoretically this wouldn't have happened. And *if* the developers had followed proper practice and documented their complete build environment, then PVP compliance would be irrelevant. So if we could go back in time and twist people's arms, no problems would exist. Hurray, we've established that 20/20 hindsight is very nice :). >>> >>> But what can be done today? Actually, I think the solution is a very simple tool, and I'll be happy to write it if people want: cabal-timemachine. It takes a timestamp, and then deletes all cabal files from our 00-index.tar file that represent packages uploaded after that date. Assuming you know the last date of a successful build, it should be trivial to get a build going again. And if you *don't* know the date, you can bisect until you get a working build. (For that matter, the tool could even *include* a bisecter in it.) Can anyone picture a scenario where this wouldn't solve the problem even better than PVP compliance? >> >> This scenario is never better than PVP compliance. First of all, the user may want some packages that are newer than the timestamp, which this wouldn't support. As people have already mentioned, it's entirely possible for valid install graphs to exist that cabal will fail to find if it doesn't have upper bound information available, because it finds other *invalid* graphs. >> >> And even aside from that issue, this would push the work of making sure that a library is compatible with its dependencies onto the library *users*, instead of the developer, where it rightfully belongs (and your proposal ends up pushing even more work onto users!). >> >> Why do you think it's acceptable for users to do the testing to make sure that your code works with other packages that your code requires? > > You're not at all addressing the case I described. The case was a legacy project that someone is trying to rebuild. I'm not talking about any other case in this scenario. To repeat myself: > > > 1. Existing, legacy code, built again some historical version of Hackage, without information on the exact versions of all deep dependencies. > > In *that specific case*, why wouldn't having a tool to go back in time and build against a historical version of Hackage be *exactly* what you'd need to rebuild the project? > >>> >>> For (2), talking about older versions of a package is not relevant. I actively maintain a number of my older package releases, as I'm sure others do as well. The issue isn't about *age* of a package, but about *maintenance* of a package. And we simply shouldn't be encouraging users to start off with an unmaintained version of a package. This is a completely separate discussion from the legacy code base, where- despite the valid security and bug concerns Vincent raised- it's likely not worth updating to the latest and greatest. >> >> Usually the case is not that somebody *wants* to use an older version of package 'foo', it's that they're using some package 'bar' which hasn't yet been updated to be compatible with the latest 'foo'. There are all sorts of reasons this may happen, including big API shifts (e.g. parsec2/parsec3, openGL), poor timing in a maintenance cycle, and the usual worldly distractions. But if packages have upper bounds, the user can 'cabal install', get a coherent package graph, and begin working. At the very worst, cabal will give them a clear lead as to what needs to be updated/who to ping. This is much better than the situation with no upper bounds, where a 'cabal install' may fail miserably or even put together code that produces garbage. >> >> And again, it's the library *user* who ends up having to deal with these problems. Upper bounds lead to a better user experience. > > I disagree with that assertion. I get plenty of complaints from users about trying to install packages and getting "confusing error messages" about cabal plan mismatches. I don't disagree that the PVP does make the user experience better in some cases. What I disagree with is the implication that it makes the user experience better in *all* cases. This is simply not a black-and-white issue. > > Michael This is not a new problem. Java users faced it with Maven and it was solved by curation of Maven Central and the ability to add outside repositories as needed. Node.js users faced it with NPM and solved it with dependency freezing. Ruby users faced it with Gem and solved it with dependency freezing. I imagine there are a world of different solutions to this problem. The PVP isn't a complete solution, but I consider it to be a sensible baseline (like code style conventions and warning free builds) and it appears to me to be in line with best practices from packaging systems of many other languages. What follows is my opinion, and it comes from a position of relative inexperience with Haskell and considerable experience operating on other language communities. I feel that the PVP should be encouraged and violations should be considered bugs. Users and concerned community members should report them to maintainers. I support having a stable set of packages curated as it serves an immediate need, possibly with an alternate that does PVP-only/gated curation. I believe Hackage should continue to exist as is (without gated curation) to facilitate availability and sharing of new libraries. I think standard package dependency freezing metadata and tools should be defined and users encouraged to employ them. One way or another -- as a user of Haskell -- I would benefit significantly from standard answers to these problems and good examples from the community leadership to follow. Best, Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Feb 26 11:57:19 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 26 Feb 2014 06:57:19 -0500 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: Michael, Technically it'd have to do a major version bump to add the instance. Herbert, That said, transitively bumping all the dependent packages whenever anyone upstream's guts change in ways you may never know about isn't a palatable option. It requires every user of every library to know about every instance or import statement that could transitively drag along an orphan even in private modules. This just isn't a realistic model of user behavior. I'm unwilling to accept the corollary that I cannot be compatible with both the current release of a package and the current platform if there have been any instances added in between. If the user wants to lock down the instances they can fix the version of the upstream dependency that is supplying it. The way I see it, if I don't supply the data type, and I don't supply the class, then using a class is fine in my API across major versions. Otherwise nobody can ship anything that crosses more than even one base version let alone versions of other packages. The only breakages that can occur be introduced are all due to orphan instances. What you propose when carried through to its logical conclusion would basically kill all development between platform releases. -Edward On Wed, Feb 26, 2014 at 5:42 AM, Michael Snoyman wrote: > > > > On Wed, Feb 26, 2014 at 12:22 PM, Herbert Valerio Riedel wrote: > >> On 2014-02-26 at 10:45:40 +0100, Michael Snoyman wrote: >> >> [...] >> >> >> >> ...are you simply referring to the fact that in order to guarantee >> >> >> PVP-semantics of a package version, one has to take care to >> restrict the >> >> >> version bounds of that package's build-deps in such a way, that any >> API >> >> >> entities leaking from its (direct) build-deps (e.g. typeclass >> instances >> >> >> or other re-exported entities) are not a function of the "internal" >> >> >> degree of freedoms the build-dep version-ranges provide? Or is there >> >> >> more to it? >> >> [...] >> >> >> From my point of view, I'd argue that >> >> >> >> a) 'persistent' failed to live up to the "spirit" of the PVP contract, >> >> i.e. to expose a "contact-surface" which satisfies certain >> >> invariants within specific package-version ranges. >> >> > How would persistent have done better? AFAICT, the options are: >> > >> > 1. Do what I did: state a true version dependency on monad-logger, that >> it >> > works with both version 0.2 and 0.3. >> >> Yes, "persistent" itself does in fact work with both major versions of >> "monad-logger", but alas the API reachable through depending solely on >> "persistent" leaks details of the underlying monad-logger version used. >> >> ...but the PVP's primary statement is define how a package shall behave >> from the point of view of its users (where by user I mean package >> build-depending on `persistent`). So... >> >> > 2. Constrain it to one or the other, which would be a falsehood that >> would >> > restrict users' ability to use the package. >> >> ...this is would actually be, what I'd interpret the PVP to >> expect/require from "persistent" in order to satisfy its goal to shield >> the package's users from incompatible changes. >> >> > Let's try it a different way. If transformers removed a MonadIO instance >> > between version 2 and 3 of the library, should that mean that every >> single >> > package with type signatures involving MonadIO should be constrained to >> one >> > specific version of transformers? >> >> yes, that'd be what I'm suggesting here (the [1] footnote is a different >> suggestion for the same problem though) >> >> > So let's analyze how far you want to go here. Imagine if version 0.3.0 of > transformers did not have a MonadIO instance for StateT, and version 0.3.1 > added it. Now some library has a function: > > myFunc :: MonadIO m => Int -> m String > > What versions of transformers is it allowed to work with? If it allows > version 0.3.0 and 0.3.1, and a user depends on the presence of the MonadIO > StateT instance, the build can be broken by moving back to version 0.3.0 > (which may be demanded by some other packages dependencies). This is simply > the reverse of the monad-logger situation, where an instance was added > instead of being removed. I don't see a reasonable solution to this > situation... well, besides everyone just trusting a curator to build all of > these packages for them. > > And just to be clear: if persistent had bumped its lower version bound on > monad-logger, then users still on the old version of monad-logger would be > unable to upgrade, and for no real reason. persistent would have required a > major version bump most likely[1], which would have caused all packages > downstream from it to do version bumps as well. > > Forgetting about my position as a library author, or as a Stackage > maintainer, and speaking purely as a library *user*, this would be a > terrible situation to be in. > > [1] That's another hole in the PVP I think. It doesn't explicitly address > the issue of an API change by eliminating compatibility with a previously > accepted dependency, but I've seen huge breakages occur due to this. > > >> >> b) However, the PVP can be blamed as well, as in its current form it >> >> doesn't explicitly address the issue of API-leakage from transitive >> >> build-dependencies. [1] >> >> >> >> The question for me now is whether the PVP is fixable in this respect, >> >> and at what cost. >> >> >> >> Moreover, it seems to me, it always comes down to type-class instances >> >> causing most problems with the PVP (either by requiring version-bump >> >> cascades throughout the PVP-adhering domain of Hackage, or by their >> hard >> >> hard to constraint leakage through package module/boundaries); maybe we >> >> need address this issue at the language-level and provide some facility >> >> for limiting the propagation of type-class instances first. >> >> >> >> >> > There's one other issue, which is reexports. As an extreme example, >> imagine: >> > >> > * Version 1 of the foo package has the Foo module, and it exports foo1 >> and >> > foo2. >> > * Version 2 of the foo package has the Foo module, and it exports foo1. >> > * Version 1 of the bar package as the Bar module, defined as: >> >> Yes, I'm well aware of this problem, but that's easier to control, as >> you can use explicit import/export lists to constraint what entities you >> expose to direct users of your package. That's what I'm doing e.g. in >> >> >> http://hackage.haskell.org/package/deepseq-generics-0.1.1.1/docs/Control-DeepSeq-Generics.html >> >> where I'm explicitly naming the entities I re-export from >> Control.DeepSeq for convenience. (However, I'm lacking such a facility >> for instances) >> >> > Agreed, the reexport issue is something that can be dealt with, whereas > typeclasses don't have such a facility right now. I just wanted to point it > out to make sure we were considering all issues. > > >> > >> > module Bar (module Foo) where >> > import Foo >> > * According to the PVP, the bar package can have a version bound on foo >> of >> > `foo > 1 && < 2.1`. >> > * User code that depends on foo2 being exported from Bar will be broken >> by >> > the transitive update of foo. >> > >> > The example's extreme, but it's the same basic problem as typeclass >> > instances. >> >> [...] >> >> >> [1]: An alternative to what I'm suggesting in 'a)' (i.e. that it'd be >> >> `persistent`'s obligation), could be that the package you >> >> mentioned (which broke due to monad-logger having a non-monotonic >> >> API change), might become required to include packages supplying >> >> the instances they depends upon in their build-depends, thus >> >> turning an transitive dep into a direct dependency. >> >> > I don't think I follow this comment, sorry. >> >> I'm basically just saying, that the package which used "persistent", >> ought to add "monad-logger ==0.2.*" to its direct build-dependencies, as >> it depends on an instance provided by monad-logger. The huge down-side >> is, that you'd have to know about type-class instances leaked through >> persistent, in order to know that'd you have to add some of >> "persistent"'s transitive build-depends to your own package, in order to >> safe yourself from missing out on type-class instances. >> > > And my approach is that the only sane way to create repeatable builds is > to *always* list the exact versions of all packages you depend upon. And in > my opinion, it's far more important to ensure that the code behaves the > same way than that it simply builds. The only real way to do that is to > always use the same versions of all dependencies. > > Michael > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Feb 26 11:58:05 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 26 Feb 2014 12:58:05 +0100 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 10:37 AM, Michael Snoyman wrote: > On Wed, Feb 26, 2014 at 11:17 AM, Johan Tibell wrote: > >> * What was the user's dependency range for monad-logger? If he is using >> the IO instance of MonadLogger from monad-logger, he ought to have a >> monad-logger == 2.0.* dependency (since removing instances require a major >> version bump.) >> > > The user didn't directly depend on monad-logger at all, as there was no > need with version 0.2 of monad-logger. > I guess the reason didn't have to depend directly on monad-logger was because he/she never mentioned any types from that package by name and thus didn't require an import of monad-logger modules. I wonder if we should have the PVP require that if a type you export in your API loses a class instance, then you're required to bump the major version number. This would have helped in this case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 11:59:18 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 13:59:18 +0200 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 1:57 PM, Edward Kmett wrote: > Michael, > > Technically it'd have to do a major version bump to add the instance. > > You're right, my mistake. I don't think that distinction affects the rest of my description, however. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 12:02:53 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 14:02:53 +0200 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 1:58 PM, Johan Tibell wrote: > On Wed, Feb 26, 2014 at 10:37 AM, Michael Snoyman wrote: > >> On Wed, Feb 26, 2014 at 11:17 AM, Johan Tibell wrote: >> >>> * What was the user's dependency range for monad-logger? If he is using >>> the IO instance of MonadLogger from monad-logger, he ought to have a >>> monad-logger == 2.0.* dependency (since removing instances require a major >>> version bump.) >>> >> >> The user didn't directly depend on monad-logger at all, as there was no >> need with version 0.2 of monad-logger. >> > > I guess the reason didn't have to depend directly on monad-logger was > because he/she never mentioned any types from that package by name and thus > didn't require an import of monad-logger modules. > > I wonder if we should have the PVP require that if a type you export in > your API loses a class instance, then you're required to bump the major > version number. This would have helped in this case. > In this case, that change would not have helped at all: the type which lost an instance as IO, which was not exported by persistent (or monad-logger, for that matter). MonadLogger *also* wasn't exported by persistent. But I don't like this approach to the problem anyway. The theory seems to be that, if we just keep "improving" the PVP, and make library authors' lives more difficult, eventually we'll address all issues. Dependency freezing is a complete solution to the problem described here, I don't understand why there seems to be so much resistance to it. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Feb 26 12:03:45 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 26 Feb 2014 13:03:45 +0100 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: I think we should relax the PVP requirement to bump the major version number when adding an instance and instead require that the major version bump is only required when using orphan instances and otherwise only a minor version bump is required. Unless I missed some case, code that depends on a library that follows this rule should not not break. Here's my reasoning: If you add a non-orphan instance, it must be because * you define the data type or the type class in your package and * depend on a package that declares the other entity. Therefore, no package that depend on your package can declare a non-orphan instance that could collide with the instance you declare. On Wed, Feb 26, 2014 at 12:57 PM, Edward Kmett wrote: > Michael, > > Technically it'd have to do a major version bump to add the instance. > > Herbert, > > That said, transitively bumping all the dependent packages whenever anyone > upstream's guts change in ways you may never know about isn't a palatable > option. It requires every user of every library to know about every > instance or import statement that could transitively drag along an orphan > even in private modules. This just isn't a realistic model of user behavior. > > I'm unwilling to accept the corollary that I cannot be compatible with > both the current release of a package and the current platform if there > have been any instances added in between. > > If the user wants to lock down the instances they can fix the version of > the upstream dependency that is supplying it. > > The way I see it, if I don't supply the data type, and I don't supply the > class, then using a class is fine in my API across major versions. > Otherwise nobody can ship anything that crosses more than even one base > version let alone versions of other packages. > > The only breakages that can occur be introduced are all due to orphan > instances. > > What you propose when carried through to its logical conclusion would > basically kill all development between platform releases. > > -Edward > > > > > On Wed, Feb 26, 2014 at 5:42 AM, Michael Snoyman wrote: > >> >> >> >> On Wed, Feb 26, 2014 at 12:22 PM, Herbert Valerio Riedel wrote: >> >>> On 2014-02-26 at 10:45:40 +0100, Michael Snoyman wrote: >>> >>> [...] >>> >>> >> >> ...are you simply referring to the fact that in order to guarantee >>> >> >> PVP-semantics of a package version, one has to take care to >>> restrict the >>> >> >> version bounds of that package's build-deps in such a way, that >>> any API >>> >> >> entities leaking from its (direct) build-deps (e.g. typeclass >>> instances >>> >> >> or other re-exported entities) are not a function of the "internal" >>> >> >> degree of freedoms the build-dep version-ranges provide? Or is >>> there >>> >> >> more to it? >>> >>> [...] >>> >>> >> From my point of view, I'd argue that >>> >> >>> >> a) 'persistent' failed to live up to the "spirit" of the PVP >>> contract, >>> >> i.e. to expose a "contact-surface" which satisfies certain >>> >> invariants within specific package-version ranges. >>> >>> > How would persistent have done better? AFAICT, the options are: >>> > >>> > 1. Do what I did: state a true version dependency on monad-logger, >>> that it >>> > works with both version 0.2 and 0.3. >>> >>> Yes, "persistent" itself does in fact work with both major versions of >>> "monad-logger", but alas the API reachable through depending solely on >>> "persistent" leaks details of the underlying monad-logger version used. >>> >>> ...but the PVP's primary statement is define how a package shall behave >>> from the point of view of its users (where by user I mean package >>> build-depending on `persistent`). So... >>> >>> > 2. Constrain it to one or the other, which would be a falsehood that >>> would >>> > restrict users' ability to use the package. >>> >>> ...this is would actually be, what I'd interpret the PVP to >>> expect/require from "persistent" in order to satisfy its goal to shield >>> the package's users from incompatible changes. >>> >>> > Let's try it a different way. If transformers removed a MonadIO >>> instance >>> > between version 2 and 3 of the library, should that mean that every >>> single >>> > package with type signatures involving MonadIO should be constrained >>> to one >>> > specific version of transformers? >>> >>> yes, that'd be what I'm suggesting here (the [1] footnote is a different >>> suggestion for the same problem though) >>> >>> >> So let's analyze how far you want to go here. Imagine if version 0.3.0 of >> transformers did not have a MonadIO instance for StateT, and version 0.3.1 >> added it. Now some library has a function: >> >> myFunc :: MonadIO m => Int -> m String >> >> What versions of transformers is it allowed to work with? If it allows >> version 0.3.0 and 0.3.1, and a user depends on the presence of the MonadIO >> StateT instance, the build can be broken by moving back to version 0.3.0 >> (which may be demanded by some other packages dependencies). This is simply >> the reverse of the monad-logger situation, where an instance was added >> instead of being removed. I don't see a reasonable solution to this >> situation... well, besides everyone just trusting a curator to build all of >> these packages for them. >> >> And just to be clear: if persistent had bumped its lower version bound on >> monad-logger, then users still on the old version of monad-logger would be >> unable to upgrade, and for no real reason. persistent would have required a >> major version bump most likely[1], which would have caused all packages >> downstream from it to do version bumps as well. >> >> Forgetting about my position as a library author, or as a Stackage >> maintainer, and speaking purely as a library *user*, this would be a >> terrible situation to be in. >> >> [1] That's another hole in the PVP I think. It doesn't explicitly address >> the issue of an API change by eliminating compatibility with a previously >> accepted dependency, but I've seen huge breakages occur due to this. >> >> >>> >> b) However, the PVP can be blamed as well, as in its current form it >>> >> doesn't explicitly address the issue of API-leakage from >>> transitive >>> >> build-dependencies. [1] >>> >> >>> >> The question for me now is whether the PVP is fixable in this respect, >>> >> and at what cost. >>> >> >>> >> Moreover, it seems to me, it always comes down to type-class instances >>> >> causing most problems with the PVP (either by requiring version-bump >>> >> cascades throughout the PVP-adhering domain of Hackage, or by their >>> hard >>> >> hard to constraint leakage through package module/boundaries); maybe >>> we >>> >> need address this issue at the language-level and provide some >>> facility >>> >> for limiting the propagation of type-class instances first. >>> >> >>> >> >>> > There's one other issue, which is reexports. As an extreme example, >>> imagine: >>> > >>> > * Version 1 of the foo package has the Foo module, and it exports foo1 >>> and >>> > foo2. >>> > * Version 2 of the foo package has the Foo module, and it exports foo1. >>> > * Version 1 of the bar package as the Bar module, defined as: >>> >>> Yes, I'm well aware of this problem, but that's easier to control, as >>> you can use explicit import/export lists to constraint what entities you >>> expose to direct users of your package. That's what I'm doing e.g. in >>> >>> >>> http://hackage.haskell.org/package/deepseq-generics-0.1.1.1/docs/Control-DeepSeq-Generics.html >>> >>> where I'm explicitly naming the entities I re-export from >>> Control.DeepSeq for convenience. (However, I'm lacking such a facility >>> for instances) >>> >>> >> Agreed, the reexport issue is something that can be dealt with, whereas >> typeclasses don't have such a facility right now. I just wanted to point it >> out to make sure we were considering all issues. >> >> >>> > >>> > module Bar (module Foo) where >>> > import Foo >>> > * According to the PVP, the bar package can have a version bound on >>> foo of >>> > `foo > 1 && < 2.1`. >>> > * User code that depends on foo2 being exported from Bar will be >>> broken by >>> > the transitive update of foo. >>> > >>> > The example's extreme, but it's the same basic problem as typeclass >>> > instances. >>> >>> [...] >>> >>> >> [1]: An alternative to what I'm suggesting in 'a)' (i.e. that it'd be >>> >> `persistent`'s obligation), could be that the package you >>> >> mentioned (which broke due to monad-logger having a >>> non-monotonic >>> >> API change), might become required to include packages supplying >>> >> the instances they depends upon in their build-depends, thus >>> >> turning an transitive dep into a direct dependency. >>> >>> > I don't think I follow this comment, sorry. >>> >>> I'm basically just saying, that the package which used "persistent", >>> ought to add "monad-logger ==0.2.*" to its direct build-dependencies, as >>> it depends on an instance provided by monad-logger. The huge down-side >>> is, that you'd have to know about type-class instances leaked through >>> persistent, in order to know that'd you have to add some of >>> "persistent"'s transitive build-depends to your own package, in order to >>> safe yourself from missing out on type-class instances. >>> >> >> And my approach is that the only sane way to create repeatable builds is >> to *always* list the exact versions of all packages you depend upon. And in >> my opinion, it's far more important to ensure that the code behaves the >> same way than that it simply builds. The only real way to do that is to >> always use the same versions of all dependencies. >> >> Michael >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 12:05:05 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 14:05:05 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 1:47 PM, Alain O'Dea wrote: > On Feb 26, 2014, at 7:11, Michael Snoyman wrote: > > > > I disagree with that assertion. I get plenty of complaints from users > about trying to install packages and getting "confusing error messages" > about cabal plan mismatches. I don't disagree that the PVP does make the > user experience better in some cases. What I disagree with is the > implication that it makes the user experience better in *all* cases. This > is simply not a black-and-white issue. > > Michael > > > This is not a new problem. > > Java users faced it with Maven and it was solved by curation of Maven > Central and the ability to add outside repositories as needed. > > Node.js users faced it with NPM and solved it with dependency freezing. > > Ruby users faced it with Gem and solved it with dependency freezing. > > You've presented three examples of other languages solving the problems using the two techniques I've been advocating through this thread: curation and dependency freezing. Is there an example of a language that took an approach like the PVP and succeeded in solving it? > I imagine there are a world of different solutions to this problem. The > PVP isn't a complete solution, but I consider it to be a sensible baseline > (like code style conventions and warning free builds) and it appears to me > to be in line with best practices from packaging systems of many other > languages. > > What follows is my opinion, and it comes from a position of relative > inexperience with Haskell and considerable experience operating on other > language communities. > > I feel that the PVP should be encouraged and violations should be > considered bugs. Users and concerned community members should report them > to maintainers. > Please, please, please don't actually encourage this. There are many things which I consider bad practice in Haskell code. I don't open up bug reports against each package that disagrees with me. If a package on Hackage in fact does *not* build with some dependency it claims to build against, that's a perfectly reasonable thing to report (and I do so on a regular basis via Stackage). But insisting that people add upper bounds when they've clearly stated they do not want to is crossing the line. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 12:09:37 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 14:09:37 +0200 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 2:03 PM, Johan Tibell wrote: > I think we should relax the PVP requirement to bump the major version > number when adding an instance and instead require that the major version > bump is only required when using orphan instances and otherwise only a > minor version bump is required. Unless I missed some case, code that > depends on a library that follows this rule should not not break. > > Here's my reasoning: > > If you add a non-orphan instance, it must be because > > * you define the data type or the type class in your package and > * depend on a package that declares the other entity. > > Therefore, no package that depend on your package can declare a non-orphan > instance that could collide with the instance you declare. > > > +1. If we're discussing PVP changes, the other one I'd like to propose is: Don't include upper bounds on base, template-haskell, or other libraries which cannot be upgraded, unless you know with certainty that your package will not compile with those other versions. Motivation: * The bounds will never help cabal choose a better build plan. * The bounds may cause valid builds to never be attempted. * The bounds make it very difficult to check and debug new versions of GHC. * Including the bounds if you know the build will fail makes for more user-friendly messages. * Leaving off the bounds if you're not certain will result in users getting more verbose error messages. While uglier, these error messages will be helpful for the package maintainer to adjust the package for the new version of GHC. I'd also want to push the bounds a little bit further a make a distinction between experimental and stable packages, but that's a bigger proposal and I'd rather start with something more modest. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Feb 26 12:25:53 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 26 Feb 2014 13:25:53 +0100 Subject: qualified imports, PVP and so on In-Reply-To: (Michael Snoyman's message of "Wed, 26 Feb 2014 14:09:37 +0200") References: <87r473uzyj.fsf@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: <87d2iarrfy.fsf@gnu.org> On 2014-02-26 at 13:09:37 +0100, Michael Snoyman wrote: [...] > +1. If we're discussing PVP changes, the other one I'd like to propose is: > > Don't include upper bounds on base, template-haskell, or other libraries > which cannot be upgraded, unless you know with certainty that your package > will not compile with those other versions. Motivation: > > * The bounds will never help cabal choose a better build plan. ...this assumes (as I mentioned in an earlier post) that GHC is never going to ship again with two versions of base (like in the past with base3/4). For that case, we'd want at least something like `base < 5` as upper bound in place (with the policy that `5.*` will only ever be reached if something really disruptive is done to `base`) From johan.tibell at gmail.com Wed Feb 26 12:37:24 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 26 Feb 2014 13:37:24 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances Message-ID: Hi all, (This email is about trying to improve the PVP. If you think the PVP is a bad idea to begin with, please discuss that in a separate email thread.) The PVP [1] states that A.B is known as the major version number, and C the minor version number. > When a package is updated, the following rules govern how the version > number must change relative to the previous version: > > - If any entity was removed, or the types of any entities or the > definitions of datatypes or classes were changed, or instances were added > or removed, then the new A.B must be greater than the previous A.B. Note > that modifying imports or depending on a newer version of another package > may cause extra instances to be exported and thus force a major version > change. > > > - Otherwise, if only new bindings, types, classes or modules (but see > below) were added to the interface, then A.B may remain the same but the > new C must be greater than the old C. > > > - Otherwise, A.B.C may remain the same (other version components may > change). > > Bumping the major version number often introduce a number of downstream changes, as package author need to loosen dependency constraints to allow the new package version to be used. This creates quite a bit of work for maintainers. A particular onerous requirement is to have to bump the major version whenever you add a new instance. In spirit adding a new instances feels like adding a new function, like making an extension to the API, something ought to not break clients who use qualified imports and/or explicit import lists. For this reason and because of the cost to downstream maintainers, I've sometimes avoided bumping the major version in the past when adding a new instance. However, introducing a new instance can only break other packages if those packages define orphan instance. Here's my reasoning: 1. Assume there are no orphan instances. 2. Package D defines a data type and package C defines a type class (it's possible that D=C.) 3. An instance can only be added by either D or C. 4. D and C cannot both depend on each other, so both cannot add the same instance. 5. Another package O cannot add an instance (remember that orphans are disallowed). 6. Since O cannot define an instance, there cannot be any conflicts in O if D or C (whichever depends on the other) adds an instance. If this is true, we could change the first two PVP rules to (differences in *italics*): - If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or *orphan* instances were added or *any instances were* removed, then the new A.B must be greater than the previous A.B. Note that modifying imports or depending on a newer version of another package may cause extra instances to be exported and thus force a major version change. - Otherwise, if only new bindings, types, classes, *non-orphan instances*, or modules (but see below) were added to the interface, then A.B may remain the same but the new C must be greater than the old C. and add the following clarifying sentence: *If a package defines an orphan instance, it must depend on the minor version of the packages that define the data type and the type class to be backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < 2.1.2.* I believe this would result in less work for maintainers. 1. http://www.haskell.org/haskellwiki/Package_versioning_policy Discussion period: 3 weeks. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Wed Feb 26 12:39:52 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 26 Feb 2014 23:39:52 +1100 Subject: qualified imports, PVP and so on In-Reply-To: <87d2iarrfy.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> <87d2iarrfy.fsf@gnu.org> Message-ID: On 26 February 2014 23:25, Herbert Valerio Riedel wrote: > On 2014-02-26 at 13:09:37 +0100, Michael Snoyman wrote: > > [...] > >> +1. If we're discussing PVP changes, the other one I'd like to propose is: >> >> Don't include upper bounds on base, template-haskell, or other libraries >> which cannot be upgraded, unless you know with certainty that your package >> will not compile with those other versions. Motivation: >> >> * The bounds will never help cabal choose a better build plan. > > ...this assumes (as I mentioned in an earlier post) that GHC is never > going to ship again with two versions of base (like in the past with > base3/4). For that case, we'd want at least something like `base < 5` as > upper bound in place (with the policy that `5.*` will only ever be > reached if something really disruptive is done to `base`) Agreed; there were a few packages that failed on Gentoo because the author stated that it worked with "base < 5", even though they'd only tested it with cabal-install and at the time it was defaulting to base-3 (though using the runhaskell Setup.hs method used the "best version"). That might be reasonable for the other such libraries though. But to be specific: are we including libraries such as bytestring, containers, etc. as those that can be upgraded or cannot be upgraded? -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From johan.tibell at gmail.com Wed Feb 26 12:45:39 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 26 Feb 2014 13:45:39 +0100 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 1:09 PM, Michael Snoyman wrote: > * The bounds will never help cabal choose a better build plan. > It won't help cabal but it might inform the user what's wrong so he/she can do something about it. Dependency errors are more high-level than compilation errors. > * The bounds make it very difficult to check and debug new versions of GHC. > I believe we added a cabal flag to skip the upper bounds check. Mikhail, do you remember? > * Including the bounds if you know the build will fail makes for more > user-friendly messages. > I think the more friendly message for base is: this package doesn't work with this (new) version of GHC. We sometimes have breaking base changes (like in the upcoming 7.8 release, which changes some primops.) Having an error on the base version is better than a compilation error in that case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Wed Feb 26 12:56:26 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed, 26 Feb 2014 13:56:26 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: Message-ID: <530DE47A.8080007@henning-thielemann.de> Am 26.02.2014 13:37, schrieb Johan Tibell: > Hi all, > > (This email is about trying to improve the PVP. If you think the PVP is > a bad idea to begin with, please discuss that in a separate email thread.) As far as I remember we already discussed this: http://www.haskell.org/pipermail/libraries/2011-December/017337.html From michael at snoyman.com Wed Feb 26 13:14:41 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 15:14:41 +0200 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: <530DE47A.8080007@henning-thielemann.de> References: <530DE47A.8080007@henning-thielemann.de> Message-ID: On Wed, Feb 26, 2014 at 2:56 PM, Henning Thielemann < schlepptop at henning-thielemann.de> wrote: > Am 26.02.2014 13:37, schrieb Johan Tibell: > > Hi all, >> >> (This email is about trying to improve the PVP. If you think the PVP is >> a bad idea to begin with, please discuss that in a separate email thread.) >> > > As far as I remember we already discussed this: > http://www.haskell.org/pipermail/libraries/2011-December/017337.html > > > As last time, I'm +1 on this proposal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 13:15:46 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 15:15:46 +0200 Subject: qualified imports, PVP and so on In-Reply-To: <87d2iarrfy.fsf@gnu.org> References: <87r473uzyj.fsf@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> <87d2iarrfy.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 2:25 PM, Herbert Valerio Riedel wrote: > On 2014-02-26 at 13:09:37 +0100, Michael Snoyman wrote: > > [...] > > > +1. If we're discussing PVP changes, the other one I'd like to propose > is: > > > > Don't include upper bounds on base, template-haskell, or other libraries > > which cannot be upgraded, unless you know with certainty that your > package > > will not compile with those other versions. Motivation: > > > > * The bounds will never help cabal choose a better build plan. > > ...this assumes (as I mentioned in an earlier post) that GHC is never > going to ship again with two versions of base (like in the past with > base3/4). For that case, we'd want at least something like `base < 5` as > upper bound in place (with the policy that `5.*` will only ever be > reached if something really disruptive is done to `base`) > > You're right, that should be included. A further reason would be that Hackage demand an upper bound on base anyway, and it seems a pretty accepted practice to use < 5. If this was standardized in the PVP, I think we'd be better off. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 13:16:48 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 15:16:48 +0200 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> <87d2iarrfy.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 2:39 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 26 February 2014 23:25, Herbert Valerio Riedel wrote: > > On 2014-02-26 at 13:09:37 +0100, Michael Snoyman wrote: > > > > [...] > > > >> +1. If we're discussing PVP changes, the other one I'd like to propose > is: > >> > >> Don't include upper bounds on base, template-haskell, or other libraries > >> which cannot be upgraded, unless you know with certainty that your > package > >> will not compile with those other versions. Motivation: > >> > >> * The bounds will never help cabal choose a better build plan. > > > > ...this assumes (as I mentioned in an earlier post) that GHC is never > > going to ship again with two versions of base (like in the past with > > base3/4). For that case, we'd want at least something like `base < 5` as > > upper bound in place (with the policy that `5.*` will only ever be > > reached if something really disruptive is done to `base`) > > Agreed; there were a few packages that failed on Gentoo because the > author stated that it worked with "base < 5", even though they'd only > tested it with cabal-install and at the time it was defaulting to > base-3 (though using the runhaskell Setup.hs method used the "best > version"). > > That might be reasonable for the other such libraries though. But to > be specific: are we including libraries such as bytestring, > containers, etc. as those that can be upgraded or cannot be upgraded? > I'm making the more modest proposal, and just focusing on libraries which cannot at all be upgraded. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Feb 26 13:18:45 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 15:18:45 +0200 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 2:45 PM, Johan Tibell wrote: > On Wed, Feb 26, 2014 at 1:09 PM, Michael Snoyman wrote: > >> * The bounds will never help cabal choose a better build plan. >> > > It won't help cabal but it might inform the user what's wrong so he/she > can do something about it. Dependency errors are more high-level than > compilation errors. > > >> * The bounds make it very difficult to check and debug new versions of >> GHC. >> > > I believe we added a cabal flag to skip the upper bounds check. Mikhail, > do you remember? > > Even with that flag, we'd still have a bit of a problem. It would be nice if cabal could ignore an upper bound on template-haskell, but respect an upper bound on some other package that *can* be installed with a newer GHC. Perhaps adding that flexibility to cabal would be possible. > * Including the bounds if you know the build will fail makes for more >> user-friendly messages. >> > > I think the more friendly message for base is: this package doesn't work > with this (new) version of GHC. We sometimes have breaking base changes > (like in the upcoming 7.8 release, which changes some primops.) Having an > error on the base version is better than a compilation error in that case. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Wed Feb 26 13:19:23 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 26 Feb 2014 14:19:23 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: Message-ID: <530DE9DB.8060808@dfki.de> Hi, I tend to agree to this proposal, but I would like to encourage developers/researchers to invent something like named instances (or dictionaries), that are not transitively reexported and could coexist with current instances. (These would allow several, differently named, instances for the same type and class combination.) Non-orphaned instances are simply a too heavy burden for modularization! Nobody, who invents a shiny new class, supplies instances for all the base types and conversely, nobody, who defines a new type, also supports all our shiny classes in the base package. So many (though minor) package updates are required to add missing instances and the problem becomes more difficult for classes and types that are not in base. Cheers Christian Am 26.02.2014 13:37, schrieb Johan Tibell: > Hi all, > > (This email is about trying to improve the PVP. If you think the PVP is > a bad idea to begin with, please discuss that in a separate email thread.) > > The PVP [1] states that > > A.B is known as the major version number, and C the minor version > number. When a package is updated, the following rules govern how > the version number must change relative to the previous version: > > * If any entity was removed, or the types of any entities or the > definitions of datatypes or classes were changed, or instances > were added or removed, then the new A.B must be greater than the > previous A.B. Note that modifying imports or depending on a > newer version of another package may cause extra instances to be > exported and thus force a major version change. > > * Otherwise, if only new bindings, types, classes or modules (but > see below) were added to the interface, then A.B may remain the > same but the new C must be greater than the old C. > > * Otherwise, A.B.C may remain the same (other version components > may change). > > > Bumping the major version number often introduce a number of downstream > changes, as package author need to loosen dependency constraints to > allow the new package version to be used. This creates quite a bit of > work for maintainers. > > A particular onerous requirement is to have to bump the major version > whenever you add a new instance. In spirit adding a new instances feels > like adding a new function, like making an extension to the API, > something ought to not break clients who use qualified imports and/or > explicit import lists. For this reason and because of the cost to > downstream maintainers, I've sometimes avoided bumping the major version > in the past when adding a new instance. > > However, introducing a new instance can only break other packages if > those packages define orphan instance. Here's my reasoning: > > 1. Assume there are no orphan instances. > 2. Package D defines a data type and package C defines a type class > (it's possible that D=C.) > 3. An instance can only be added by either D or C. > 4. D and C cannot both depend on each other, so both cannot add the > same instance. > 5. Another package O cannot add an instance (remember that orphans are > disallowed). > 6. Since O cannot define an instance, there cannot be any conflicts in > O if D or C (whichever depends on the other) adds an instance. > > If this is true, we could change the first two PVP rules to (differences > in /italics/): > > * If any entity was removed, or the types of any entities or the > definitions of datatypes or classes were changed, or /orphan/ > instances were added or /any instances were/ removed, then the new > A.B must be greater than the previous A.B. Note that modifying > imports or depending on a newer version of another package may cause > extra instances to be exported and thus force a major version change. > > * Otherwise, if only new bindings, types, classes, /non-orphan > instances/, or modules (but see below) were added to the interface, > then A.B may remain the same but the new C must be greater than the > old C. > > and add the following clarifying sentence: > > /If a package defines an orphan instance, it must depend on the minor > version of the packages that define the data type and the type class to > be backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < > 2.1.2./ > > I believe this would result in less work for maintainers. > > 1. http://www.haskell.org/haskellwiki/Package_versioning_policy > > Discussion period: 3 weeks. > > -- Johan > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From hvr at gnu.org Wed Feb 26 13:47:28 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 26 Feb 2014 14:47:28 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: (Johan Tibell's message of "Wed, 26 Feb 2014 13:37:24 +0100") References: Message-ID: <871tyqrnnz.fsf@gnu.org> On 2014-02-26 at 13:37:24 +0100, Johan Tibell wrote: [...] > If this is true, we could change the first two PVP rules to (differences in > *italics*): > > - If any entity was removed, or the types of any entities or the > definitions of datatypes or classes were changed, or *orphan* instances > were added or *any instances were* removed, then the new A.B must be > greater than the previous A.B. Note that modifying imports or depending on > a newer version of another package may cause extra instances to be exported > and thus force a major version change. > > > - Otherwise, if only new bindings, types, classes, *non-orphan instances*, > or modules (but see below) were added to the interface, then A.B may remain > the same but the new C must be greater than the old C. > > and add the following clarifying sentence: > > *If a package defines an orphan instance, it must depend on the minor > version of the packages that define the data type and the type class to be > backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < > 2.1.2.* [...] general +1 from me From daniel.trstenjak at gmail.com Wed Feb 26 14:04:35 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Wed, 26 Feb 2014 15:04:35 +0100 Subject: qualified imports, PVP and so on In-Reply-To: References: <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: <20140226140435.GA28584@machine> On Wed, Feb 26, 2014 at 03:18:45PM +0200, Michael Snoyman wrote: > Even with that flag, we'd still have a bit of a problem. It would be nice if > cabal could ignore an upper bound on template-haskell, but respect an upper > bound on some other package that *can* be installed with a newer GHC. Perhaps > adding that flexibility to cabal would be possible. I think that's a call for soft bounds (known to work with) and hard bounds (known to not work with) and the flag '--allow-newer' would be only allowed to overwrite the soft bounds. Greetings, Daniel From carter.schonwald at gmail.com Wed Feb 26 14:11:32 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 26 Feb 2014 09:11:32 -0500 Subject: qualified imports, PVP and so on In-Reply-To: <20140226140435.GA28584@machine> References: <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> <20140226140435.GA28584@machine> Message-ID: Yeah. I think that idea was ok'd by all. On Wednesday, February 26, 2014, Daniel Trstenjak < daniel.trstenjak at gmail.com> wrote: > > On Wed, Feb 26, 2014 at 03:18:45PM +0200, Michael Snoyman wrote: > > Even with that flag, we'd still have a bit of a problem. It would be > nice if > > cabal could ignore an upper bound on template-haskell, but respect an > upper > > bound on some other package that *can* be installed with a newer GHC. > Perhaps > > adding that flexibility to cabal would be possible. > > I think that's a call for soft bounds (known to work with) and hard > bounds (known to not work with) and the flag '--allow-newer' would be > only allowed to overwrite the soft bounds. > > > Greetings, > Daniel > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Feb 26 14:59:23 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 26 Feb 2014 15:59:23 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: <530DE47A.8080007@henning-thielemann.de> References: <530DE47A.8080007@henning-thielemann.de> Message-ID: On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann < schlepptop at henning-thielemann.de> wrote: > As far as I remember we already discussed this: > http://www.haskell.org/pipermail/libraries/2011-December/017337.html Apparently I'm getting old and forgetful. :/ By looking at the last thread and this thread I think the following people support the proposal: Johan Tibell Michael Snoyman Christian Maeder Henning Thielemann And the following people against: Ganesh Sittampalam Ivan Lazar Miljenovic Erik Hesselink There were also lots of discussion by other people and, as per the rule on mailing lists discussions, discussions that weared off in a bunch of directions*. Some comments to help further discussions: - You can still write "orphan" instances by using a newtype, if the instance is only used internally. I did this in e.g. ekg which needed some aeson instances. It added a couple if line of code to the library as a whole. - You can still write orphan instances, you just need to have tighter version bounds. - There were some comments along the lines of "I prefer major version bumps to breakages." This doesn't introduce breakages, as long as people follow the updated PVP. P.S. Other core library maintainers and I have already avoided bumping the major versions in several libraries, including containers and hashable, in the past, as I knew that would require more or less every package author to release a new version of their packages. In other words, we don't quite follow the PVP today and I don't think we should (i.e. we should change the PVP to match current practice.) * This is probably what I eventually abandoned the discussion and it's something that has annoyed me about libraries@ discussions for quite some time. We, as a community, need to get better at concentrate on the technical discussion at hand. We cannot redesign Haskell in every libraries proposal thread, as fun as that might be. The alternative would be to have less community input on these decisions -- which I think would be a shame -- as is common in other language communities. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Feb 26 15:00:40 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 26 Feb 2014 10:00:40 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: Can we all zoom out for a moment? Can we turn this into a technology problem we can solve, rather than an anthropological issue? what about adding some sort of model of "module type signature" tooling to cabal/cabal-install experimentally (and perhaps eventually GHC?). A lot of our package version problems stem from ...... our *untyped* module system. We currently don't have any static ways of reasoning / checking if two packages of modules are actually intercompatible without actually compiling them! But the information is there! Yes we need to figure out how such a design would support type classes gracefully (in a way we can all be happy with), but thats just a bullet point, not a barrier. Theres some smart folks who've started exploring the design space in their research (its a huge design space), but perhaps we as a community should actually commit to a "k year plan, for some finite k <= 5" to actually work out typeful tooling for this recurrent library tooling pain, which requires that WE EXPERIMENT :) seriously, lets stop focusing on the symptom, and do we what we do best, collaborate to build tools that systematically improve all of our respective approaches ('cause lets be honest, i don't think the camps here are going to change, and tribalism never helps anyone). basically everyone's correct and wrong because its such a darn high dimensional problem that none of us have the time to correctly communicate the full nuances of the respective stances. As always, sending an email to the libraries list when theres been this many people on the thread is a dangerous thing, but sometimes danger is my middle name. i imagine several of you are writing up haskell module type systems papers for ICFP when not opining on this thread (not really, but I wish!) let me start this (hopefully useful aside) with some thoughts 1) pinning package deps to a fixed version is a social construct for encoding "i want this exact set of operations with this semantics" 2) saying i want dependency P to satisfy version range ">= A && < B" is a way of saying "assuming my understanding of the range of code semantics and module types exposed over this version range is true / consistent, my code can correctly work over this range" 3) even if we had decent module types and ways of say "code works over this set of interfaces over this version range", versions and things like PVP still have value in communicating when a package is likely to be the same or different 4) cabal does need a proper SMT solver tool for handling version constraints as is, which is a totally unrelated problem, but another fun one thats actually resolvable by way of using technology seriously, lets all zoom out of ask "how can we come up with a roadmap for evolving haskell tooling that solves the underlying need that this whole thread is indirectly about". And no it needs to be tool that doesn't pin everything to a single version, thats for APPs not LIBRARIES :) -Carter On Wed, Feb 26, 2014 at 7:05 AM, Michael Snoyman wrote: > > > > On Wed, Feb 26, 2014 at 1:47 PM, Alain O'Dea wrote: > >> On Feb 26, 2014, at 7:11, Michael Snoyman wrote: >> >> >> >> I disagree with that assertion. I get plenty of complaints from users >> about trying to install packages and getting "confusing error messages" >> about cabal plan mismatches. I don't disagree that the PVP does make the >> user experience better in some cases. What I disagree with is the >> implication that it makes the user experience better in *all* cases. This >> is simply not a black-and-white issue. >> >> Michael >> >> >> This is not a new problem. >> >> Java users faced it with Maven and it was solved by curation of Maven >> Central and the ability to add outside repositories as needed. >> >> Node.js users faced it with NPM and solved it with dependency freezing. >> >> Ruby users faced it with Gem and solved it with dependency freezing. >> >> > You've presented three examples of other languages solving the problems > using the two techniques I've been advocating through this thread: curation > and dependency freezing. Is there an example of a language that took an > approach like the PVP and succeeded in solving it? > > >> I imagine there are a world of different solutions to this problem. The >> PVP isn't a complete solution, but I consider it to be a sensible baseline >> (like code style conventions and warning free builds) and it appears to me >> to be in line with best practices from packaging systems of many other >> languages. >> >> What follows is my opinion, and it comes from a position of relative >> inexperience with Haskell and considerable experience operating on other >> language communities. >> >> I feel that the PVP should be encouraged and violations should be >> considered bugs. Users and concerned community members should report them >> to maintainers. >> > > Please, please, please don't actually encourage this. There are many > things which I consider bad practice in Haskell code. I don't open up bug > reports against each package that disagrees with me. If a package on > Hackage in fact does *not* build with some dependency it claims to build > against, that's a perfectly reasonable thing to report (and I do so on a > regular basis via Stackage). But insisting that people add upper bounds > when they've clearly stated they do not want to is crossing the line. > > Michael > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Feb 26 15:11:14 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 26 Feb 2014 16:11:14 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530DE47A.8080007@henning-thielemann.de> Message-ID: On Wed, Feb 26, 2014 at 3:59 PM, Johan Tibell wrote: > By looking at the last thread and this thread I think the following people > support the proposal: > Forgot: Herbert Valerio Riedel -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Wed Feb 26 15:38:41 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Wed, 26 Feb 2014 07:38:41 -0800 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> <87d2iarrfy.fsf@gnu.org> Message-ID: On Wed, Feb 26, 2014 at 5:15 AM, Michael Snoyman wrote: > A further reason would be that Hackage demand an upper bound on base anyway This is policy also and can be changed. -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Feb 26 15:42:56 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 26 Feb 2014 16:42:56 +0100 Subject: qualified imports, PVP and so on In-Reply-To: (Gregory Collins's message of "Wed, 26 Feb 2014 07:38:41 -0800") References: <87r473uzyj.fsf@gnu.org> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> <87d2iarrfy.fsf@gnu.org> Message-ID: <87ob1tribj.fsf@gnu.org> On 2014-02-26 at 16:38:41 +0100, Gregory Collins wrote: > On Wed, Feb 26, 2014 at 5:15 AM, Michael Snoyman wrote: > >> A further reason would be that Hackage demand an upper bound on base anyway > > This is policy also and can be changed. Btw, in case anyone is interested in the motivation for that policy at the time it was enabled: http://www.haskell.org/pipermail/cabal-devel/2009-June/005313.html Cheers, hvr From greg at gregorycollins.net Wed Feb 26 15:43:27 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Wed, 26 Feb 2014 07:43:27 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 12:36 AM, John Lato wrote: > 7. awesomeApp users attempt to do cabal update; cabal install, which > fails inscrutably (because it tries to mix foo-0.2 with bar-0.1) > > There's nothing in this situation that requires any of these packages be > unmaintained. The problem is that, rather than wanting to reproduce a > fixed set of package versions (which cabal already allows for if that's > really desired), sometimes it's desirable that updates be held back in > active code bases > Not to mention, if I maintain "bar", I can basically never go on vacation, because the dude who maintains "foo" can push a new update and break all my users any time. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Wed Feb 26 15:45:06 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Wed, 26 Feb 2014 07:45:06 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 3:47 AM, Alain O'Dea wrote: > I imagine there are a world of different solutions to this problem. The > PVP isn't a complete solution, but I consider it to be a sensible baseline > (like code style conventions and warning free builds) and it appears to me > to be in line with best practices from packaging systems of many other > languages. Like "semantic versioning" (http://semver.org/) which is very well regarded by people I talk to. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Feb 26 15:57:15 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 26 Feb 2014 10:57:15 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 2:11 AM, Michael Snoyman wrote: > I disagree with that assertion. I get plenty of complaints from users > about trying to install packages and getting "confusing error messages" > about cabal plan mismatches. I don't disagree that the PVP does make the > user experience better in some cases. What I disagree with is the > implication that it makes the user experience better in *all* cases. This > is simply not a black-and-white issue. > And how much of this is because you use your own versioning riules instead of what everyone else uses, thereby almost guaranteeing conflicts with everyone else when anything is updated? Seriously, the easiest way to get in trouble with the current system is to insist you get to not follow it, because stuff breaks. Asserting it's everyone else's fault isn't a solution. Seriously, if everyone follows your versioning system, hsenv becomes essential just as RVM is essential in the Rails community; everyone has to provide their own curated system (your Stackage isn't going to serve everyone's needs, and asking you to make it serve everyone's needs is unreasonable and quite likely an impossible task when everyone else is also doing their own thing) and users have to maintain separate ecosystems for everything they use. This isn't maintainable for much of anyone. (I see someone else later on actually advocated this as a solution. It's not. It's an ongoing maintenance disaster that leads to unmanageable systems.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Feb 26 16:01:22 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 26 Feb 2014 11:01:22 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 6:47 AM, Alain O'Dea wrote: > Ruby users faced it with Gem and solved it with dependency freezing. Ruby didn't solve it for anyone but developers. End users are required to build what amounts to a separate Ruby installation using RVM for every Ruby application, because every application works with only its curated sets of gems. This is, quite simply, nonsense. You've pushed the whole problem into the user's lap and required them to do a lot of extra work for every application they want to use. This "solution" is exactly the thing I want to *avoid*. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Wed Feb 26 16:01:27 2014 From: mblazevic at stilo.com (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=) Date: Wed, 26 Feb 2014 11:01:27 -0500 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: Message-ID: <530E0FD7.8030507@stilo.com> On 14-02-26 07:37 AM, Johan Tibell wrote: >... > > If this is true, we could change the first two PVP rules to (differences > in /italics/): > > * If any entity was removed, or the types of any entities or the > definitions of datatypes or classes were changed, or /orphan/ > instances were added or /any instances were/ removed, then the new > A.B must be greater than the previous A.B. Note that modifying > imports or depending on a newer version of another package may cause > extra instances to be exported and thus force a major version change. > > * Otherwise, if only new bindings, types, classes, /non-orphan > instances/, or modules (but see below) were added to the interface, > then A.B may remain the same but the new C must be greater than the > old C. > > and add the following clarifying sentence: > > /If a package defines an orphan instance, it must depend on the minor > version of the packages that define the data type and the type class to > be backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < > 2.1.2./ > +1, except I'd add the following ammendment: In the interim period (for a year or so after the PVP change), the library maintainers that wish to take advantage of the change (i.e., add a new instance while incrementing only the minor package version) should check if any of the packages depending on their libraries contain clashing orphan instances. If so, they need to try to contact the depending package maintainers and get them to tighten the dependency bounds before the minor release. After the interim period is over, the responsibility falls onto the maintainers of the depending packages. Also, we should consider reserving the third component of the version for instance additions, and relegating function and type additions to lower components. From michael at snoyman.com Wed Feb 26 16:06:44 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 18:06:44 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wednesday, February 26, 2014, Brandon Allbery wrote: > On Wed, Feb 26, 2014 at 2:11 AM, Michael Snoyman > > wrote: > >> I disagree with that assertion. I get plenty of complaints from users >> about trying to install packages and getting "confusing error messages" >> about cabal plan mismatches. I don't disagree that the PVP does make the >> user experience better in some cases. What I disagree with is the >> implication that it makes the user experience better in *all* cases. This >> is simply not a black-and-white issue. >> > > And how much of this is because you use your own versioning riules instead > of what everyone else uses, thereby almost guaranteeing conflicts with > everyone else when anything is updated? Seriously, the easiest way to get > in trouble with the current system is to insist you get to not follow it, > because stuff breaks. Asserting it's everyone else's fault isn't a solution. > > Given that yesod followed the pvp strictly for a number of years and still faced a large number of dependency issues, I don't think the problem is in the lack of pvp support. The most recent example of this issue was a user trying to use ghc 7.8 and getting an error message about an upper bound on base in the esqueleto package. I'm sure most of us on this mailing list would consider this an easy error message, but at least one of our mythical end users was seriously confused by this situation. It turned out that simply dropping the upper bound was sufficient. So I come back to this being a numbers game. End users don't necessarily find cabal version error messages any better than ghc build failures. The question is how can we minimize any kind of build failure. Michael Seriously, if everyone follows your versioning system, hsenv becomes > essential just as RVM is essential in the Rails community; everyone has to > provide their own curated system (your Stackage isn't going to serve > everyone's needs, and asking you to make it serve everyone's needs is > unreasonable and quite likely an impossible task when everyone else is also > doing their own thing) and users have to maintain separate ecosystems for > everything they use. This isn't maintainable for much of anyone. > > Actually, why wouldn't stackage as a curated system work for everyone? Stackage already has over 10% of hackage covered, and I'd imagine if you look at hackage download numbers, that covers the vast majority of the most downloaded packages. I really do think that a curated system could make most people happy, if it gets enough buy-in. > (I see someone else later on actually advocated this as a solution. It's > not. It's an ongoing maintenance disaster that leads to unmanageable > systems.) > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mightybyte at gmail.com Wed Feb 26 16:21:29 2014 From: mightybyte at gmail.com (MightyByte) Date: Wed, 26 Feb 2014 11:21:29 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 4:56 AM, Michael Snoyman wrote: > > On Wed, Feb 26, 2014 at 10:36 AM, John Lato wrote: >> >> I had understood people talking about "legacy projects" to mean something >> other than how you read it. In which case, I would suggest that there is a >> third use case, which IMHO is more important than either of the use cases >> you have identified. Here's an example: >> >> 1. package foo-0.1 appears on hackage >> 2. package bar-0.1 appears on hackage with a dependency on foo >= 0.1 >> 3. awesomeApp-0.1 appears on hackage, which depends on bar-0.1 and >> text>=1.0 >> 4. users install awesomeApp >> 5. package foo-0.2 appears on hackage, with lots of breaking changes >> 6. awesomeApp users notice that it sometimes breaks with Hungarian >> characters, and the problem is traced to an error in text >> 6. text-1.0.0.1 is released with some bug fixes >> 7. awesomeApp users attempt to do cabal update; cabal install, which >> fails inscrutably (because it tries to mix foo-0.2 with bar-0.1) >> There's another simpler example here where foo-0.2 breaks something and because bar has no upper bound, awesomeApp's build spontaneously fails. I don't think it's reasonable to require that package authors specify dependency bounds for the transitive closure of things they depend on. That's unintuitive and it doesn't scale well as the number of packages and average number of dependencies in a single package increases. The solver needs to know that foo-0.2 is not known to work with bar. We should not throw away that information. I've already encountered several cases complex enough that cabal could not find a solution even though some existed. We need to bound this problem with as many tools as we can. > > IIUC, this is *exactly* the case of an unmaintained package. I'm not > advocating leaving a package like bar-0.1 on Hackage without an upper bound > on foo, if it's known that it breaks in that case. In order for the package > to be properly maintained, the maintainer would have to (1) make bar work > with foo-0.2, or (2) add an upper bound. So to me, this falls squarely into > the category of unmaintained. Calling that an unmaintained package is intellectually dishonest. Any reasonable definition of "unmaintained" will acknowledge that there will always exist some nonzero amount of time between the time foo is updated and the time bar and awesomeApp can be fixed without claiming that they are unmaintained. This is a fact of the reality we live in. I strongly believe that packages should not break spontaneously because of the actions of others. > If package maintainers are not going to be responsive to updates in the > Hackage ecosystem, then I agree that they should use the PVP. I also think > they should advertise their packages as not being actively maintained, and > people should try to avoid using them if possible. But if an author is > giving quick updates to packages, I don't see a huge benefit to the PVP for > users, and instead see some downsides (inability to test against newer > dependencies), not to mention the much higher maintenance burden for library > authors. I'm sorry, but this is completely ridiculous. There are life situations that happen that preclude package updates. And that doesn't mean that the package is unmaintained. Here's the other side of the story. A large majority of snap's breakages have been caused by dependencies that don't supply upper bounds such as clientsession, cipher-aes, http-conduit, etc. In fact, we switched from http-conduit to http-streams precisely because of this problem. If package maintainers are not going to be responsible and put proper upper bounds for all their dependencies, then I think they should advertise their packages as chronically unstable and likely to break anyone else that uses them at a moment's notice. People should avoid using them if possible. The downsides that you're claiming aren't the fault of the PVP. They are a deficiency in our tooling, and fully locking down the transitive closure is not a good solution. What we need is a way to differentiate known bad upper bounds from unverified upper bounds. It could be something as simple as allowing That's what I'm disagreeing with. I do not believe that, overall, the PVP is > giving users a better experience. I've had a huge downturn in reported > errors with Yesod since I stopped strictly following the PVP. It's > anecdotal, but everything in this thread is really anecdotal. I suspect that the root cause for you holding tihs position is that you happen to be operating in a relatively self-contained corner of the package space and don't often depend on fast-moving packages that aren't under your control. From carter.schonwald at gmail.com Wed Feb 26 16:35:20 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 26 Feb 2014 11:35:20 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: michael, respectfully, i've had the experience of trying to build a yesod app (git-annex) in a cabal sandbox and i had a version conflict between your own libraries. the only way I could build git-annex was by disabling the web-gui yesod piece. The key piece here is your libraries conflicted with themselves. Thats on you. likewise, 9 time out of 10, when someone tries haskell for the first and they tell me "cabal didn't work", I can guess "you tried to install yesod". They then say "yes", and then I have to explain to them that "yesod has notoriously fragile build constraints, even people who use yesod find it maddening depending on their use case". Michael, respectfully, most version constraint build failures are human friendly, yours are cthulian. I spend a wee bit of time every major GHC release helping patch all the various libs i use (including helping get pandoc ready for each new ghc). It usaually pretty easy. Its often just needing a teeny bit of CPP for an API change plus adjusting cabal range to be wider. I'm totally ok with doing that 1-2 times a year in exchange for nice things. I'd rather do a test and patch cycle every year than have surprise build failures. On Wed, Feb 26, 2014 at 11:06 AM, Michael Snoyman wrote: > > > On Wednesday, February 26, 2014, Brandon Allbery > wrote: > >> On Wed, Feb 26, 2014 at 2:11 AM, Michael Snoyman wrote: >> >>> I disagree with that assertion. I get plenty of complaints from users >>> about trying to install packages and getting "confusing error messages" >>> about cabal plan mismatches. I don't disagree that the PVP does make the >>> user experience better in some cases. What I disagree with is the >>> implication that it makes the user experience better in *all* cases. This >>> is simply not a black-and-white issue. >>> >> >> And how much of this is because you use your own versioning riules >> instead of what everyone else uses, thereby almost guaranteeing conflicts >> with everyone else when anything is updated? Seriously, the easiest way to >> get in trouble with the current system is to insist you get to not follow >> it, because stuff breaks. Asserting it's everyone else's fault isn't a >> solution. >> >> > Given that yesod followed the pvp strictly for a number of years and still > faced a large number of dependency issues, I don't think the problem is in > the lack of pvp support. > > The most recent example of this issue was a user trying to use ghc 7.8 and > getting an error message about an upper bound on base in the esqueleto > package. I'm sure most of us on this mailing list would consider this an > easy error message, but at least one of our mythical end users was > seriously confused by this situation. It turned out that simply dropping > the upper bound was sufficient. > > So I come back to this being a numbers game. End users don't necessarily > find cabal version error messages any better than ghc build failures. The > question is how can we minimize any kind of build failure. > > Michael > > Seriously, if everyone follows your versioning system, hsenv becomes >> essential just as RVM is essential in the Rails community; everyone has to >> provide their own curated system (your Stackage isn't going to serve >> everyone's needs, and asking you to make it serve everyone's needs is >> unreasonable and quite likely an impossible task when everyone else is also >> doing their own thing) and users have to maintain separate ecosystems for >> everything they use. This isn't maintainable for much of anyone. >> >> > Actually, why wouldn't stackage as a curated system work for everyone? > Stackage already has over 10% of hackage covered, and I'd imagine if you > look at hackage download numbers, that covers the vast majority of the most > downloaded packages. I really do think that a curated system could make > most people happy, if it gets enough buy-in. > > >> (I see someone else later on actually advocated this as a solution. It's >> not. It's an ongoing maintenance disaster that leads to unmanageable >> systems.) >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Feb 26 16:56:09 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 26 Feb 2014 11:56:09 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 11:06 AM, Michael Snoyman wrote: > On Wednesday, February 26, 2014, Brandon Allbery > wrote: > >> Seriously, if everyone follows your versioning system, hsenv becomes >> essential just as RVM is essential in the Rails community; everyone has to >> provide their own curated system (your Stackage isn't going to serve >> everyone's needs, and asking you to make it serve everyone's needs is >> unreasonable and quite likely an impossible task when everyone else is also >> doing their own thing) and users have to maintain separate ecosystems for >> everything they use. This isn't maintainable for much of anyone. >> > >> > Actually, why wouldn't stackage as a curated system work for everyone? > Stackage already has over 10% of hackage covered, and I'd imagine if you > look at hackage download numbers, that covers the vast majority of the most > downloaded packages. I really do think that a curated system could make > most people happy, if it gets enough buy-in. > Because you don't have any particular reason to curate packages you are not using yourself, and as Hackage grows you also won't have *time* to do so, even if you dropped Yesod and devoted your full time to Stackage curation. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From leon.p.smith at gmail.com Wed Feb 26 17:28:35 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Wed, 26 Feb 2014 12:28:35 -0500 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: <530E0FD7.8030507@stilo.com> References: <530E0FD7.8030507@stilo.com> Message-ID: I feel indifferent on this proposal. I certainly think the PVP is wrong in the case when a library both adds a newtype or data type declaration and then adds an instance for it, as it's impossible to break downstream dependencies in this way. So I've been ignoring the strict letter of the PVP in this particular case, although I'd argue that I'm still following the spirit of the PVP. So whether or not this change is adopted, I do think this point should be clarified. My opinion on orphaned instances is that they should (almost always) be avoided in hackage-released libraries, but that they are mostly harmless in executables, whether hackage-released or not. So under these assumptions, it's still possible to break something; the question in my mind is whether or not it would be more work to tighten up dependencies after the fact (under the optimistic assumption that things usually won't break) or loosen things up. Given that I'm not, at the moment, a fan of upper bounds at all, I don't feel like this tradeoff impacts me much. (Although obviously I'm coming down on the side of the optimistic assumption.) But I do think it's important to have a good semantics for the PVP. (And incidentally, once (if?) we start adjusting version ranges without updating the version of the package, then I will adopt upper bounds, and I also feel that this issue would become mostly moot anyway.) I also second Christian's comment that we really do need a more coherent story on orphaned instances, as avoiding them really does put a damper on modularity. Best, Leon On Wed, Feb 26, 2014 at 11:01 AM, Mario Bla?evi? wrote: > On 14-02-26 07:37 AM, Johan Tibell wrote: > >> ... >> >> >> If this is true, we could change the first two PVP rules to (differences >> in /italics/): >> >> * If any entity was removed, or the types of any entities or the >> definitions of datatypes or classes were changed, or /orphan/ >> instances were added or /any instances were/ removed, then the new >> >> A.B must be greater than the previous A.B. Note that modifying >> imports or depending on a newer version of another package may cause >> extra instances to be exported and thus force a major version change. >> >> * Otherwise, if only new bindings, types, classes, /non-orphan >> instances/, or modules (but see below) were added to the interface, >> >> then A.B may remain the same but the new C must be greater than the >> old C. >> >> and add the following clarifying sentence: >> >> /If a package defines an orphan instance, it must depend on the minor >> >> version of the packages that define the data type and the type class to >> be backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < >> 2.1.2./ >> >> > > +1, except I'd add the following ammendment: > > In the interim period (for a year or so after the PVP change), the library > maintainers that wish to take advantage of the change (i.e., add a new > instance while incrementing only the minor package version) should check if > any of the packages depending on their libraries contain clashing orphan > instances. If so, they need to try to contact the depending package > maintainers and get them to tighten the dependency bounds before the minor > release. After the interim period is over, the responsibility falls onto > the maintainers of the depending packages. > > Also, we should consider reserving the third component of the > version for instance additions, and relegating function and type additions > to lower components. > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Wed Feb 26 18:14:04 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed, 26 Feb 2014 19:14:04 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: <530DE9DB.8060808@dfki.de> References: <530DE9DB.8060808@dfki.de> Message-ID: <530E2EEC.8080000@henning-thielemann.de> Am 26.02.2014 14:19, schrieb Christian Maeder: > Hi, > > I tend to agree to this proposal, but I would like to encourage > developers/researchers to invent something like named instances (or > dictionaries), that are not transitively reexported and could coexist > with current instances. (These would allow several, differently named, > instances for the same type and class combination.) I expressed the idea of programmable instance selection in the past: http://www.haskell.org/pipermail/libraries/2013-March/019533.html http://www.haskell.org/pipermail/libraries/2012-November/018831.html This approach may also solve the orphan instance problem, but I have no idea how to design programmable instance selection. However, I suspect that GHC assumes at several places that there is only one instance per pair of class and type. What about packing and unpacking of class dictionaries in existentially quantified types? From bart at cs.pdx.edu Wed Feb 26 18:32:59 2014 From: bart at cs.pdx.edu (Bart Massey) Date: Wed, 26 Feb 2014 10:32:59 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530CD010.1030607@snarc.org> Message-ID: Bardur: Yes! I want *this*! In addition to short-circuiting this epic argument, it looks way better. I've always wished Haskell had the ML module system, but this looks even better than that in some ways. So, yes. Let's get backpack into GHC, require it on Hackage, and get on with it. Note that backpack by itself isn't sufficient, since it only guarantees type-compatibility, not semantic compatibility. We would have to add additional rules requiring at least partial semantic compatibility of any changes to the semantics at a given name. --Bart On Tue, Feb 25, 2014 at 10:10 PM, Bardur Arantsson wrote: > On 2014-02-25 18:26, Carter Schonwald wrote: >> indeed. >> >> So lets think about how to add module types or some approximation thereof >> to GHC? (seriously, thats the only sane "best solution" i can think of, but >> its not something that can be done casually). Theres also the fact that any >> module system design will have to explicitly deal with type class instances >> in a more explicit fashion than we've done thus far. > > This may be relevant: > > http://plv.mpi-sws.org/backpack/ > > Regards, > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From carter.schonwald at gmail.com Wed Feb 26 18:37:32 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 26 Feb 2014 13:37:32 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530CD010.1030607@snarc.org> Message-ID: Bart, backpack is just a first design iteration. We shouldn't regard it as the final answer, but as a starting point for understanding / exploring the design space. On Wednesday, February 26, 2014, Bart Massey wrote: > Bardur: Yes! I want *this*! In addition to short-circuiting this epic > argument, it looks way better. I've always wished Haskell had the ML > module system, but this looks even better than that in some ways. So, > yes. Let's get backpack into GHC, require it on Hackage, and get on > with it. Note that backpack by itself isn't sufficient, since it only > guarantees type-compatibility, not semantic compatibility. We would > have to add additional rules requiring at least partial semantic > compatibility of any changes to the semantics at a given name. --Bart > > On Tue, Feb 25, 2014 at 10:10 PM, Bardur Arantsson > > wrote: > > On 2014-02-25 18:26, Carter Schonwald wrote: > >> indeed. > >> > >> So lets think about how to add module types or some approximation > thereof > >> to GHC? (seriously, thats the only sane "best solution" i can think of, > but > >> its not something that can be done casually). Theres also the fact that > any > >> module system design will have to explicitly deal with type class > instances > >> in a more explicit fashion than we've done thus far. > > > > This may be relevant: > > > > http://plv.mpi-sws.org/backpack/ > > > > Regards, > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Wed Feb 26 19:07:12 2014 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 26 Feb 2014 21:07:12 +0200 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: <530E2EEC.8080000@henning-thielemann.de> References: <530DE9DB.8060808@dfki.de> <530E2EEC.8080000@henning-thielemann.de> Message-ID: Johan Tibell wrote: > we could change the first two PVP rules to... > ...or _orphan_ instances were added or > _any_ instances were removed... > I believe this would result in less work for maintainers. The burden is actually not nearly as onerous as it used to be with the many great new Cabal features that allow manually tweaking cabal's build plan in various ways. Many thanks to Johan and the Cabal team! But yes, I agree, this is a good change to PVP. +1 Christian Maeder wrote: >> I tend to agree to this proposal, but I would like to encourage >> developers/researchers to invent something like named instances (or >> dictionaries), that are not transitively reexported and could coexist >> with current instances. (These would allow several, differently named, >> instances for the same type and class combination.) Henning Thielemann wrote: > ...What about packing and unpacking of > class dictionaries in existentially quantified types? I strongly agree with Christian, and I thank Henning for suggesting an implementation direction. But - focus, focus, focus! Make believe I never said that. Thanks, Yitz From michael at snoyman.com Wed Feb 26 19:19:25 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 21:19:25 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 6:21 PM, MightyByte wrote: > On Wed, Feb 26, 2014 at 4:56 AM, Michael Snoyman > wrote: > I suspect that the root cause for you holding tihs position is that you > happen > to be operating in a relatively self-contained corner of the package space > and > don't often depend on fast-moving packages that aren't under your control. > Choosing this point in the thread to respond to a few points, for no particular reason. I'm willing to reconsider my stance on the PVP, and a lot of the feedback here is making me rethink some decisions. Let me take a different stab at the problem. I think the main problem with PVP right now is one of *scope*. I see it as trying to address two different issues: 1. Make sure that any code that anyone ever wrote will continue to build in the future. 2. Provide guidelines to package authors to make sure that `cabal install foo` works reliably, regardless of what's happened on the rest of Hackage. It's (1) that I take huge issue with, because (as I've been trying to demonstrate) I don't see any way that a policy like PVP could ever fully solve this problem. And more to the point: I think "my code builds" isn't the goal that we should be striving for anyway, it's the goal of reproducible builds. I simply don't think it's worthwhile to push this burden onto package maintainers, as the only realistic solution is dependency freezing, which does in fact fully solve the problem. But the feedback I'm reading on (2) is making me reconsider my stance. I have to say though, as much as people in this thread are saying the PVP will solve these problems, I'm highly skeptical, since Yesod *did* in fact follow the PVP very strictly for years, and the result was people complaining about broken builds on a regular basis. It's entirely possible though that this was the fault of cabal-install's older dependency solver, and if Yesod switched over to the PVP now, things would be better. I still have some concerns about the PVP's stance on a few issues, namely: 1. The upper bounds on non-upgradable packages, which I've raised elsewhere in this thread. 2. The lack of flexibility in interpretation. I think there's a qualitative difference between depending on the text package by simply importing Data.Text (Text), versus using some experimental features of a version 0.1 library. So I suppose if those points were addressed, a lot of my PVP skepticism would disappear, and I'd be more inclined to coming back into the fold, so to say. My question is: am I alone in thinking these are in fact issues with the PVP? Is anyone else willing to embark on a more significant overhaul of the policy? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Feb 26 19:21:17 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 26 Feb 2014 11:21:17 -0800 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530DE47A.8080007@henning-thielemann.de> Message-ID: +1 to this proposal in general, as well as updating the PVP to match current practice. John On Feb 26, 2014 6:59 AM, "Johan Tibell" wrote: > On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann < > schlepptop at henning-thielemann.de> wrote: > >> As far as I remember we already discussed this: >> http://www.haskell.org/pipermail/libraries/2011-December/017337.html > > > Apparently I'm getting old and forgetful. :/ > > By looking at the last thread and this thread I think the following people > support the proposal: > > Johan Tibell > Michael Snoyman > Christian Maeder > Henning Thielemann > > And the following people against: > > Ganesh Sittampalam > Ivan Lazar Miljenovic > Erik Hesselink > > There were also lots of discussion by other people and, as per the rule on > mailing lists discussions, discussions that weared off in a bunch of > directions*. > > Some comments to help further discussions: > > - You can still write "orphan" instances by using a newtype, if the > instance is only used internally. I did this in e.g. ekg which needed some > aeson instances. It added a couple if line of code to the library as a > whole. > - You can still write orphan instances, you just need to have tighter > version bounds. > - There were some comments along the lines of "I prefer major version > bumps to breakages." This doesn't introduce breakages, as long as people > follow the updated PVP. > > P.S. Other core library maintainers and I have already avoided bumping the > major versions in several libraries, including containers and hashable, in > the past, as I knew that would require more or less every package author to > release a new version of their packages. In other words, we don't quite > follow the PVP today and I don't think we should (i.e. we should change the > PVP to match current practice.) > > * This is probably what I eventually abandoned the discussion and it's > something that has annoyed me about libraries@ discussions for quite some > time. We, as a community, need to get better at concentrate on the > technical discussion at hand. We cannot redesign Haskell in every libraries > proposal thread, as fun as that might be. The alternative would be to have > less community input on these decisions -- which I think would be a shame > -- as is common in other language communities. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Feb 26 19:32:04 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 26 Feb 2014 14:32:04 -0500 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530E0FD7.8030507@stilo.com> Message-ID: I agree that creating a new class or data type and supplying instances for it fits within the spirit of what the PVP allows in a minor revision, and should probably be clarified as we slowly try to etch a more accurate notion of what it means to be 'safe' in PVP terms. w.r.t. having upper bounds at all, I think that belongs in a separate discussion. For the record, you can put me down as +1 on this proposal in spirit. There may be some quibbling I'd take with the language though for the case where you have a package with classes and a package that has orphans for those classes for a package that was too burdensome to add as a dependency for the base package, both under the control of the same maintainer. (Mutatis mutandis for data types) An example would be vector-instances. As I control both it, and most of the packages it makes orphans for, I'm simply constraining myself from not releasing versions of those packages with conflicting instances unless I bump them out of bounds. I'd like to find a way to spell this out in clearer PVP'ese, but it is the way in which I'm most likely to be PVP non-compliant in the future. On Wed, Feb 26, 2014 at 12:28 PM, Leon Smith wrote: > I feel indifferent on this proposal. > > I certainly think the PVP is wrong in the case when a library both adds a > newtype or data type declaration and then adds an instance for it, as it's > impossible to break downstream dependencies in this way. So I've been > ignoring the strict letter of the PVP in this particular case, although > I'd argue that I'm still following the spirit of the PVP. So whether or > not this change is adopted, I do think this point should be clarified. > > My opinion on orphaned instances is that they should (almost always) be > avoided in hackage-released libraries, but that they are mostly harmless > in executables, whether hackage-released or not. So under these > assumptions, it's still possible to break something; the question in my > mind is whether or not it would be more work to tighten up dependencies > after the fact (under the optimistic assumption that things usually won't > break) or loosen things up. Given that I'm not, at the moment, a fan of > upper bounds at all, I don't feel like this tradeoff impacts me much. > (Although obviously I'm coming down on the side of the optimistic > assumption.) But I do think it's important to have a good semantics for > the PVP. > > (And incidentally, once (if?) we start adjusting version ranges without > updating the version of the package, then I will adopt upper bounds, and > I also feel that this issue would become mostly moot anyway.) > > I also second Christian's comment that we really do need a more coherent > story on orphaned instances, as avoiding them really does put a damper on > modularity. > > Best, > Leon > > > On Wed, Feb 26, 2014 at 11:01 AM, Mario Bla?evi? wrote: > >> On 14-02-26 07:37 AM, Johan Tibell wrote: >> >>> ... >>> >>> >>> If this is true, we could change the first two PVP rules to (differences >>> in /italics/): >>> >>> * If any entity was removed, or the types of any entities or the >>> definitions of datatypes or classes were changed, or /orphan/ >>> instances were added or /any instances were/ removed, then the new >>> >>> A.B must be greater than the previous A.B. Note that modifying >>> imports or depending on a newer version of another package may cause >>> extra instances to be exported and thus force a major version change. >>> >>> * Otherwise, if only new bindings, types, classes, /non-orphan >>> instances/, or modules (but see below) were added to the interface, >>> >>> then A.B may remain the same but the new C must be greater than the >>> old C. >>> >>> and add the following clarifying sentence: >>> >>> /If a package defines an orphan instance, it must depend on the minor >>> >>> version of the packages that define the data type and the type class to >>> be backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < >>> 2.1.2./ >>> >>> >> >> +1, except I'd add the following ammendment: >> >> In the interim period (for a year or so after the PVP change), the >> library maintainers that wish to take advantage of the change (i.e., add a >> new instance while incrementing only the minor package version) should >> check if any of the packages depending on their libraries contain clashing >> orphan instances. If so, they need to try to contact the depending package >> maintainers and get them to tighten the dependency bounds before the minor >> release. After the interim period is over, the responsibility falls onto >> the maintainers of the depending packages. >> >> Also, we should consider reserving the third component of the >> version for instance additions, and relegating function and type additions >> to lower components. >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Feb 26 19:38:05 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 26 Feb 2014 21:38:05 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <530D1062.5010006@snarc.org> Message-ID: <20140226193805.GA16421@sniper> * Michael Snoyman [2014-02-26 21:19:25+0200] > I still have some concerns about the PVP's stance on a few issues, namely: > > 1. The upper bounds on non-upgradable packages, which I've raised elsewhere > in this thread. > 2. The lack of flexibility in interpretation. I think there's a qualitative > difference between depending on the text package by simply importing > Data.Text (Text), versus using some experimental features of a version 0.1 > library. > > So I suppose if those points were addressed, a lot of my PVP skepticism > would disappear, and I'd be more inclined to coming back into the fold, so > to say. > > My question is: am I alone in thinking these are in fact issues with the > PVP? No, you're not alone. And here are two other issues with PVP and upper bounds: http://ro-che.info/articles/2013-10-05-why-pvp-doesnt-work.html Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gale at sefer.org Wed Feb 26 19:45:14 2014 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 26 Feb 2014 21:45:14 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: Michael Snoyman wrote: > 1. Make sure that any code that anyone ever wrote will continue to build in > the future. > 2. Provide guidelines to package authors to make sure that `cabal install > foo` works reliably, regardless of what's happened on the rest of Hackage. > > It's (1) that I take huge issue with, because (as I've been trying to > demonstrate) I don't see any way that a policy like PVP could ever fully > solve this problem. As a commercial shop that must reproduce builds, we have wasted many many hours in the past on cabal hell. Almost all of it was caused by authors of packages we depend on omitting upper bounds. I am aware that some people have other needs, and have wasted their cabal hell time on the opposite problem. However, now the amount of time we waste on cabal hell, though non-zero, is much less. The reason is better ways in cabal to tweak cabal's build plan manually and reproduce winning build plans in the future, such as local cabal.config files. Whatever time we still do waste is still caused by people not being careless about upper bounds. And I believe that people with the opposite problem are wasting less and less time on cabal hell, too. As better tools continually become available, it becomes less disastrous when dependency version bounds are not exactly right. But on the other hand, those bounds are critically important semantic information about a package that make a huge contribution to the potential quality that build tools can achieve. And only the package author can easily provide that information So in my opinion, the proven, working, way forward is: 1. Continue to improve cabal's build plan tools, such as cabal freeze. And yes, cabal-timemachine would be cool :) 2. Continue to adhere to PVP. Package authors should do the best they can to guess the range of dependency versions that their package is very likely to build with. So for example: For libraries like the tagged library, or the deepseq library, which haven't changed in any essential way over any number of major version bumps, go ahead and omit the upper bound. For most vanilla packages, try to be as accurate as you can about the lower bound (without going crazy), and use a two-component upper bound. For base, if you are not using fancy new GHC features, minor version bumps are unlikely to break your package, but a major bump of base (if that will ever happen again) is likely to break quite a few packages and maybe yours. For maintainers like Edward with a huge burden - well, I'm sure Edward will figure out the most reasonable and helpful thing to do in his situation. Perhaps higher powered tools, like some variation on cabal-bounds, would be helpful for him. Etc. Thanks, Yitz From michael at snoyman.com Wed Feb 26 20:00:48 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 22:00:48 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 9:45 PM, Yitzchak Gale wrote: > Michael Snoyman wrote: > > 1. Make sure that any code that anyone ever wrote will continue to build > in > > the future. > > 2. Provide guidelines to package authors to make sure that `cabal install > > foo` works reliably, regardless of what's happened on the rest of > Hackage. > > > > It's (1) that I take huge issue with, because (as I've been trying to > > demonstrate) I don't see any way that a policy like PVP could ever fully > > solve this problem. > > As a commercial shop that must reproduce builds, > we have wasted many many hours in the past on > cabal hell. Almost all of it was caused by authors > of packages we depend on omitting upper bounds. > > I am aware that some people have other needs, > and have wasted their cabal hell time on the opposite > problem. > > However, now the amount of time we waste on cabal > hell, though non-zero, is much less. The reason is better > ways in cabal to tweak cabal's build plan manually and > reproduce winning build plans in the future, such as > local cabal.config files. Whatever time we still do waste > is still caused by people not being careless about > upper bounds. And I believe that people with the > opposite problem are wasting less and less time > on cabal hell, too. > > As better tools continually become available, it > becomes less disastrous when dependency > version bounds are not exactly right. But on the > other hand, those bounds are critically important > semantic information about a package that make > a huge contribution to the potential quality that > build tools can achieve. And only the package author > can easily provide that information > > So in my opinion, the proven, working, way forward is: > > 1. Continue to improve cabal's build plan tools, such > as cabal freeze. And yes, cabal-timemachine would > be cool :) > > 2. Continue to adhere to PVP. Package authors should > do the best they can to guess the range of dependency > versions that their package is very likely to build with. > > So for example: > > For libraries like the tagged library, or the deepseq library, > which haven't changed in any essential way over any number > of major version bumps, go ahead and omit the upper > bound. > > Actually, that's not going to help anyone much. If the library really is completely stable, then who cares if I have to change an upper bound when the package never changes? The real issue is packages with a largely stable subset, and some other part that's still changing. The two prime examples of this are text and bytestring. Both of them expose an incredibly stable core API, which is what most people use. Occasionally, there is a new feature added, or some more obscure feature changes somehow. But likely 95% of packages depending on these two will never be affected by those changes. Requiring every usage of text to have an upper bound stratifies Hackage into (1) packages that depend on the new features, and (2) PVP-adhering packages whose authors haven't updated their dependencies yet. With my Stackage hat on, this is by far the most time-consuming issue I have to deal with. base squarely falls in this category, since the vast majority of it doesn't change between releases. It happens to *also* fall in the category of non-upgradeable packages. > For most vanilla packages, try to be as accurate as you > can about the lower bound (without going crazy), and > use a two-component upper bound. > > For base, if you are not using fancy new GHC features, > minor version bumps are unlikely to break your package, > but a major bump of base (if that will ever happen again) > is likely to break quite a few packages and maybe yours. > > To be clear, base has a major version bump every release of GHC. According to the PVP, the first two components of the version number constitute the major version, while the third number is the minor version. > For maintainers like Edward with a huge burden - well, > I'm sure Edward will figure out the most reasonable > and helpful thing to do in his situation. Perhaps higher > powered tools, like some variation on cabal-bounds, > would be helpful for him. > > Etc. > > Thanks, > Yitz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Feb 26 20:01:37 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 26 Feb 2014 12:01:37 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 1:56 AM, Michael Snoyman wrote: > > On Wed, Feb 26, 2014 at 10:36 AM, John Lato wrote: > >> On Tue, Feb 25, 2014 at 11:11 PM, Michael Snoyman wrote: >>> >>> >>> On Wed, Feb 26, 2014 at 8:03 AM, John Lato wrote: >>> >>>> On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman wrote: >>>> >>>>> >>>>> >>>>> On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: >>>>> >>>>>> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez >>>>>> wrote: >>>>>> > >>>>>> > I'm not saying this is not painful, but i've done it in the past, >>>>>> and using >>>>>> > dichotomy and educated guesses (for example not using libraries >>>>>> released >>>>>> > after a certain date), you converge pretty quickly on a solution. >>>>>> > >>>>>> > But the bottom line is that it's not the common use case. I rarely >>>>>> have to >>>>>> > dig old unused code. >>>>>> >>>>>> And I have code that I would like to have working today, but it's too >>>>>> expensive to go through this process. The code has significant value >>>>>> to me and other people, but not enough to justify the large cost of >>>>>> getting it working again. >>>>>> >>>>>> >>>>> >>>>> I think we need to make these cases more concrete to have a meaningful >>>>> discussion. Between Doug and Gregory, I'm understanding two different use >>>>> cases: >>>>> >>>>> 1. Existing, legacy code, built again some historical version of >>>>> Hackage, without information on the exact versions of all deep dependencies. >>>>> 2. Someone starting a new project who wants to use an older version of >>>>> a package on Hackage. >>>>> >>>>> If I've missed a use case, please describe it. >>>>> >>>>> For (1), let's start with the time machine game: *if* everyone had >>>>> been using the PVP, then theoretically this wouldn't have happened. And >>>>> *if* the developers had followed proper practice and documented their >>>>> complete build environment, then PVP compliance would be irrelevant. So if >>>>> we could go back in time and twist people's arms, no problems would exist. >>>>> Hurray, we've established that 20/20 hindsight is very nice :). >>>>> >>>>> But what can be done today? Actually, I think the solution is a very >>>>> simple tool, and I'll be happy to write it if people want: >>>>> cabal-timemachine. It takes a timestamp, and then deletes all cabal files >>>>> from our 00-index.tar file that represent packages uploaded after that >>>>> date. Assuming you know the last date of a successful build, it should be >>>>> trivial to get a build going again. And if you *don't* know the date, you >>>>> can bisect until you get a working build. (For that matter, the tool could >>>>> even *include* a bisecter in it.) Can anyone picture a scenario where this >>>>> wouldn't solve the problem even better than PVP compliance? >>>>> >>>> >>>> This scenario is never better than PVP compliance. First of all, the >>>> user may want some packages that are newer than the timestamp, which this >>>> wouldn't support. As people have already mentioned, it's entirely possible >>>> for valid install graphs to exist that cabal will fail to find if it >>>> doesn't have upper bound information available, because it finds other >>>> *invalid* graphs. >>>> >>>> And even aside from that issue, this would push the work of making sure >>>> that a library is compatible with its dependencies onto the library >>>> *users*, instead of the developer, where it rightfully belongs (and your >>>> proposal ends up pushing even more work onto users!). >>>> >>>> Why do you think it's acceptable for users to do the testing to make >>>> sure that your code works with other packages that your code requires? >>>> >>> >>> You're not at all addressing the case I described. The case was a >>> legacy project that someone is trying to rebuild. I'm not talking about any >>> other case in this scenario. To repeat myself: >>> >>> > 1. Existing, legacy code, built again some historical version of >>> Hackage, without information on the exact versions of all deep dependencies. >>> >>> In *that specific case*, why wouldn't having a tool to go back in time >>> and build against a historical version of Hackage be *exactly* what you'd >>> need to rebuild the project? >>> >> >> I had understood people talking about "legacy projects" to mean something >> other than how you read it. In which case, I would suggest that there is a >> third use case, which IMHO is more important than either of the use cases >> you have identified. Here's an example: >> >> 1. package foo-0.1 appears on hackage >> 2. package bar-0.1 appears on hackage with a dependency on foo >= 0.1 >> 3. awesomeApp-0.1 appears on hackage, which depends on bar-0.1 and >> text>=1.0 >> 4. users install awesomeApp >> 5. package foo-0.2 appears on hackage, with lots of breaking changes >> 6. awesomeApp users notice that it sometimes breaks with Hungarian >> characters, and the problem is traced to an error in text >> 6. text-1.0.0.1 is released with some bug fixes >> 7. awesomeApp users attempt to do cabal update; cabal install, which >> fails inscrutably (because it tries to mix foo-0.2 with bar-0.1) >> >> There's nothing in this situation that requires any of these packages be >> unmaintained. The problem is that, rather than wanting to reproduce a >> fixed set of package versions (which cabal already allows for if that's >> really desired), sometimes it's desirable that updates be held back in >> active code bases. Replace "foo" with "QuickCheck" for example (where for >> a long time users stayed with quickcheck2 because version 3 had major >> performance regressions in certain use cases). >> >> This sort of conflict used to happen *all the time*, and it's very >> frustrating to users (because something worked before, now it's not >> working, and they're not generally in a good position to know why). It's >> annoying to reproduce because the install graph cabal produces depends in >> part on the user's installed packages. So just because something builds on >> a developer's box doesn't mean that it would build on the user's box, or it >> would work for some users but not others (sandboxing has at least helped >> with that problem). >> >> > IIUC, this is *exactly* the case of an unmaintained package. I'm not > advocating leaving a package like bar-0.1 on Hackage without an upper bound > on foo, if it's known that it breaks in that case. In order for the package > to be properly maintained, the maintainer would have to (1) make bar work > with foo-0.2, or (2) add an upper bound. So to me, this falls squarely into > the category of unmaintained. > I disagree. I think it's unreasonable to expect that maintainers provide 24/7 availability and near-immediate maintenance releases when updated deps are released. And in the meantime (which may be days, or even a couple weeks for a single-maintainer who might be on holiday), there's plenty of time for this to bite hard. In the past, this meant that broken packages would remain available on hackage for a long time. At least now the package maintainers can do so themselves, but it still means that broken packages have escaped into the wild, which is also bad. > > Let me relax my position just a bit. If package maintainers are not going > to be responsive to updates in the Hackage ecosystem, then I agree that > they should use the PVP. I also think they should advertise their packages > as not being actively maintained, and people should try to avoid using them > if possible. But if an author is giving quick updates to packages, I don't > see a huge benefit to the PVP for users, and instead see some downsides > (inability to test against newer dependencies), not to mention the much > higher maintenance burden for library authors. > What do you consider "responsive"? 2 hours? 24? 1 week? I suspect that you have IMO unrealistic expectations of maintainers, so I think it would be good to get into specifics. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Feb 26 20:04:05 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 26 Feb 2014 15:04:05 -0500 Subject: qualified imports, PVP and so on In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <878usyst3s.fsf@gnu.org> <87vbw2s0ps.fsf@gnu.org> <87ob1urx6e.fsf@gnu.org> Message-ID: I very much agree with the sentiment that bounds on, say, template-haskell or ghc-prim never help build plans. One of the most common complaints I get from users has to do with the garbage type errors they get out of the template-haskell that runs lens when some package somewhere has "upgraded" their `template-haskell` install to a non-compatible version. By the time they discover this they are often several packages further along in the install and only have the vaguest inkling of what caused the problem in the first place. Regarding base I still use the < 5 bound, as as Herbert pointed out if we ever needed to ship with support for two versions of base during some big cut-over, it'd be nice to have it work. That said, I'm somewhat leery of how well the community could deal with that in practice. Even the old monads-fd vs mtl split nearly rent the ecosystem asunder. ;) -Edward On Wed, Feb 26, 2014 at 7:09 AM, Michael Snoyman wrote: > > > > On Wed, Feb 26, 2014 at 2:03 PM, Johan Tibell wrote: > >> I think we should relax the PVP requirement to bump the major version >> number when adding an instance and instead require that the major version >> bump is only required when using orphan instances and otherwise only a >> minor version bump is required. Unless I missed some case, code that >> depends on a library that follows this rule should not not break. >> >> Here's my reasoning: >> >> If you add a non-orphan instance, it must be because >> >> * you define the data type or the type class in your package and >> * depend on a package that declares the other entity. >> >> Therefore, no package that depend on your package can declare a >> non-orphan instance that could collide with the instance you declare. >> >> >> > +1. If we're discussing PVP changes, the other one I'd like to propose is: > > Don't include upper bounds on base, template-haskell, or other libraries > which cannot be upgraded, unless you know with certainty that your package > will not compile with those other versions. Motivation: > > * The bounds will never help cabal choose a better build plan. > * The bounds may cause valid builds to never be attempted. > * The bounds make it very difficult to check and debug new versions of GHC. > * Including the bounds if you know the build will fail makes for more > user-friendly messages. > * Leaving off the bounds if you're not certain will result in users > getting more verbose error messages. While uglier, these error messages > will be helpful for the package maintainer to adjust the package for the > new version of GHC. > > I'd also want to push the bounds a little bit further a make a distinction > between experimental and stable packages, but that's a bigger proposal and > I'd rather start with something more modest. > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Wed Feb 26 20:04:40 2014 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 26 Feb 2014 22:04:40 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <20140226193805.GA16421@sniper> References: <530D1062.5010006@snarc.org> <20140226193805.GA16421@sniper> Message-ID: Michael Snoyman wrote: >> I still have some concerns about the PVP's stance on a few issues, namely: >> >> 1. The upper bounds on non-upgradable packages, which I've raised elsewhere >> in this thread. >> 2. The lack of flexibility in interpretation. I think there's a qualitative >> difference between depending on the text package by simply importing >> Data.Text (Text), versus using some experimental features of a version 0.1 >> library. >> >> So I suppose if those points were addressed, a lot of my PVP skepticism >> would disappear, and I'd be more inclined to coming back into the fold, so >> to say. >> >> My question is: am I alone in thinking these are in fact issues with the >> PVP? Roman Cheplyaka wrote: > No, you're not alone. And here are two other issues with PVP and upper > bounds: > http://ro-che.info/articles/2013-10-05-why-pvp-doesnt-work.html I appreciate those concerns, but they are all concerns about being able to build packages, not about the semantics of the PVP. Trouble with building is being addressed by improvements in cabal, combining better algorithms with better quick and easy ways to intervene manually. I now find that even when thing go very wrong - complex dependency SATs, errors in package versions or dependency bounds in other people's packages, etc. - I can usually get a successful build quite quickly, and I hope this will only continue to improve. I agree 100% with Michael's #2 - dependency bounds ranges are a way of expressing the package author's best assessment of what is needed, and what will likely be needed in the foreseeable future, for the package to build. They don't need to follow any hard and fast rules. But yes, an upper bound is called for in most cases. Roman is right that it is important for package authors to do the best they can to support the latest versions of their dependencies. But even when they do that, upper bounds are not useless. They are important for people using your packages who need to support a product version over time. And they are important semantic information that you can easily make available for use by current and future build tools. Thanks, Yitz From gale at sefer.org Wed Feb 26 20:12:06 2014 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 26 Feb 2014 22:12:06 +0200 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530E0FD7.8030507@stilo.com> Message-ID: Edward Kmett wrote: > There may be some quibbling I'd take with the language though for the case > where you have a package with classes and a package that has orphans for > those classes for a package that was too burdensome to add as a dependency > for the base package, both under the control of the same maintainer. > (Mutatis mutandis for data types) > > An example would be vector-instances. As I control both it, and most of the > packages it makes orphans for, I'm simply constraining myself from not > releasing versions of those packages with conflicting instances unless I > bump them out of bounds. > > I'd like to find a way to spell this out in clearer PVP'ese, but it is the > way in which I'm most likely to be PVP non-compliant in the future. Would it help to make an exception for "standards-track" libraries like vector? In that case, orphan instances are expected to be only temporarily orphan. Hopefully, they will all eventually make their way to their permanent homes. Thanks, Yitz From michael at snoyman.com Wed Feb 26 20:13:54 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 26 Feb 2014 22:13:54 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 10:01 PM, John Lato wrote: > On Wed, Feb 26, 2014 at 1:56 AM, Michael Snoyman wrote: > >> >> On Wed, Feb 26, 2014 at 10:36 AM, John Lato wrote: >> >>> On Tue, Feb 25, 2014 at 11:11 PM, Michael Snoyman wrote: >>>> >>>> >>>> On Wed, Feb 26, 2014 at 8:03 AM, John Lato wrote: >>>> >>>>> On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 26, 2014 at 1:28 AM, MightyByte wrote: >>>>>> >>>>>>> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez >>>>>>> wrote: >>>>>>> > >>>>>>> > I'm not saying this is not painful, but i've done it in the past, >>>>>>> and using >>>>>>> > dichotomy and educated guesses (for example not using libraries >>>>>>> released >>>>>>> > after a certain date), you converge pretty quickly on a solution. >>>>>>> > >>>>>>> > But the bottom line is that it's not the common use case. I rarely >>>>>>> have to >>>>>>> > dig old unused code. >>>>>>> >>>>>>> And I have code that I would like to have working today, but it's too >>>>>>> expensive to go through this process. The code has significant value >>>>>>> to me and other people, but not enough to justify the large cost of >>>>>>> getting it working again. >>>>>>> >>>>>>> >>>>>> >>>>>> I think we need to make these cases more concrete to have a >>>>>> meaningful discussion. Between Doug and Gregory, I'm understanding two >>>>>> different use cases: >>>>>> >>>>>> 1. Existing, legacy code, built again some historical version of >>>>>> Hackage, without information on the exact versions of all deep dependencies. >>>>>> 2. Someone starting a new project who wants to use an older version >>>>>> of a package on Hackage. >>>>>> >>>>>> If I've missed a use case, please describe it. >>>>>> >>>>>> For (1), let's start with the time machine game: *if* everyone had >>>>>> been using the PVP, then theoretically this wouldn't have happened. And >>>>>> *if* the developers had followed proper practice and documented their >>>>>> complete build environment, then PVP compliance would be irrelevant. So if >>>>>> we could go back in time and twist people's arms, no problems would exist. >>>>>> Hurray, we've established that 20/20 hindsight is very nice :). >>>>>> >>>>>> But what can be done today? Actually, I think the solution is a very >>>>>> simple tool, and I'll be happy to write it if people want: >>>>>> cabal-timemachine. It takes a timestamp, and then deletes all cabal files >>>>>> from our 00-index.tar file that represent packages uploaded after that >>>>>> date. Assuming you know the last date of a successful build, it should be >>>>>> trivial to get a build going again. And if you *don't* know the date, you >>>>>> can bisect until you get a working build. (For that matter, the tool could >>>>>> even *include* a bisecter in it.) Can anyone picture a scenario where this >>>>>> wouldn't solve the problem even better than PVP compliance? >>>>>> >>>>> >>>>> This scenario is never better than PVP compliance. First of all, the >>>>> user may want some packages that are newer than the timestamp, which this >>>>> wouldn't support. As people have already mentioned, it's entirely possible >>>>> for valid install graphs to exist that cabal will fail to find if it >>>>> doesn't have upper bound information available, because it finds other >>>>> *invalid* graphs. >>>>> >>>>> And even aside from that issue, this would push the work of making >>>>> sure that a library is compatible with its dependencies onto the library >>>>> *users*, instead of the developer, where it rightfully belongs (and your >>>>> proposal ends up pushing even more work onto users!). >>>>> >>>>> Why do you think it's acceptable for users to do the testing to make >>>>> sure that your code works with other packages that your code requires? >>>>> >>>> >>>> You're not at all addressing the case I described. The case was a >>>> legacy project that someone is trying to rebuild. I'm not talking about any >>>> other case in this scenario. To repeat myself: >>>> >>>> > 1. Existing, legacy code, built again some historical version of >>>> Hackage, without information on the exact versions of all deep dependencies. >>>> >>>> In *that specific case*, why wouldn't having a tool to go back in time >>>> and build against a historical version of Hackage be *exactly* what you'd >>>> need to rebuild the project? >>>> >>> >>> I had understood people talking about "legacy projects" to mean >>> something other than how you read it. In which case, I would suggest that >>> there is a third use case, which IMHO is more important than either of the >>> use cases you have identified. Here's an example: >>> >>> 1. package foo-0.1 appears on hackage >>> 2. package bar-0.1 appears on hackage with a dependency on foo >= 0.1 >>> 3. awesomeApp-0.1 appears on hackage, which depends on bar-0.1 and >>> text>=1.0 >>> 4. users install awesomeApp >>> 5. package foo-0.2 appears on hackage, with lots of breaking changes >>> 6. awesomeApp users notice that it sometimes breaks with Hungarian >>> characters, and the problem is traced to an error in text >>> 6. text-1.0.0.1 is released with some bug fixes >>> 7. awesomeApp users attempt to do cabal update; cabal install, which >>> fails inscrutably (because it tries to mix foo-0.2 with bar-0.1) >>> >>> There's nothing in this situation that requires any of these packages be >>> unmaintained. The problem is that, rather than wanting to reproduce a >>> fixed set of package versions (which cabal already allows for if that's >>> really desired), sometimes it's desirable that updates be held back in >>> active code bases. Replace "foo" with "QuickCheck" for example (where for >>> a long time users stayed with quickcheck2 because version 3 had major >>> performance regressions in certain use cases). >>> >>> This sort of conflict used to happen *all the time*, and it's very >>> frustrating to users (because something worked before, now it's not >>> working, and they're not generally in a good position to know why). It's >>> annoying to reproduce because the install graph cabal produces depends in >>> part on the user's installed packages. So just because something builds on >>> a developer's box doesn't mean that it would build on the user's box, or it >>> would work for some users but not others (sandboxing has at least helped >>> with that problem). >>> >>> >> IIUC, this is *exactly* the case of an unmaintained package. I'm not >> advocating leaving a package like bar-0.1 on Hackage without an upper bound >> on foo, if it's known that it breaks in that case. In order for the package >> to be properly maintained, the maintainer would have to (1) make bar work >> with foo-0.2, or (2) add an upper bound. So to me, this falls squarely into >> the category of unmaintained. >> > > I disagree. I think it's unreasonable to expect that maintainers provide > 24/7 availability and near-immediate maintenance releases when updated deps > are released. And in the meantime (which may be days, or even a couple > weeks for a single-maintainer who might be on holiday), there's plenty of > time for this to bite hard. In the past, this meant that broken packages > would remain available on hackage for a long time. At least now the > package maintainers can do so themselves, but it still means that broken > packages have escaped into the wild, which is also bad. > > >> >> Let me relax my position just a bit. If package maintainers are not going >> to be responsive to updates in the Hackage ecosystem, then I agree that >> they should use the PVP. I also think they should advertise their packages >> as not being actively maintained, and people should try to avoid using them >> if possible. But if an author is giving quick updates to packages, I don't >> see a huge benefit to the PVP for users, and instead see some downsides >> (inability to test against newer dependencies), not to mention the much >> higher maintenance burden for library authors. >> > > What do you consider "responsive"? 2 hours? 24? 1 week? I suspect that > you have IMO unrealistic expectations of maintainers, so I think it would > be good to get into specifics. > I think I just realized the assumption I've been making which skews my view of things a bit here. I think it's a terrible idea that we're telling new users to go onto Hackage, type cabal install foo, and hope for the best. Not just because of build plan issues. Who knows if the newest version of a package actually works as advertised? There's been no testing period at all, no vetting. This is one of the primary reasons for yesod-platform: it gives users a starting point with a sane build plan and at least some degree of integration testing (though I'll admit that the level of testing isn't nearly to what I'd like it to be). If the constraints on the system are: 1. Any user at any time must be able to go onto Hackage and cabal install foo. 2. There can be no point at which foo doesn't install. Then requiring preemptive upper bounds is the only solution. I simply don't like those constraints, and think we're approaching the problem wrong as a community. There's one other constraint that I'm trying to optimize for, which is "when a user runs `cabal install foo bar`, there's a high probability that a sane build plan exists." This is the constraint which the PVP hinders. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.vorozhtsov at gmail.com Wed Feb 26 20:39:44 2014 From: mikhail.vorozhtsov at gmail.com (Mikhail Vorozhtsov) Date: Thu, 27 Feb 2014 00:39:44 +0400 Subject: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <20140224211238.GA23749@matrix.chaos.earth.li> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <0F5F01CB-4AFC-41DC-B9D5-FEF6033BE36B@seas.upenn.edu> <20140224211238.GA23749@matrix.chaos.earth.li> Message-ID: <530E5110.3000507@gmail.com> Wanna paint this bikeshed too! I used `allZeroes` and `allOnes` here[1]. http://hackage.haskell.org/package/data-dword-0.2.2/docs/Data-DoubleWord.html#t:BinaryWord On 02/25/2014 01:12 AM, Ian Lynagh wrote: > On Sat, Feb 22, 2014 at 02:51:24PM -0500, Anthony Cowley wrote: >> I am -1 on the name zero. I don't think importing Data.Bits unqualified is uncommon at all, and zero is prime naming real estate. I am +0.5 on the addition overall, as most uses of Bits are with types that also have Num instances. > For those that don't have a Num instance, "zero" may not make as much > sense. > > Perhaps something like noBits would be better. And FiniteBits may also > want an allBits? > > > Thanks > Ian > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ekmett at gmail.com Wed Feb 26 21:20:47 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 26 Feb 2014 16:20:47 -0500 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530E0FD7.8030507@stilo.com> Message-ID: Well, at the time I wrote that package vector was kind of out in left field and considered a 'big' dependency by many people. How perspectives change. ;) It was originally written because Data.Vector.Vector used to have no instances for Foldable, Traversable, Monad, etc. and Roman at the time was against adding them, as they had comparatively low performance. It accreted the rest of the instances necessary for working with my other packages after it had already come into existence, largely due to the fact that my packages at the time were all struggling to have a separate Haskell 98 core, and adding Vector instances immediately destroyed that ambition. Eventually Roman relented on adding the instances for the base classes, and I was left with a hollow shell of a package full of orphans. Moreover, as time has worn on the noises of people who want a simpler dependency structure resonates better with me than than the noises of folks who want me to maintain 4x as many packages to maintain distinctions that literally nobody is using. So I've started collapsing many packages together (many of my 4.0 updates were for this purpose). Finally, vector moved into the platform. So upon reflection, all of the reasons for the creation of that package are out dated. I'll look into just doing the dependency-inversion and moving the remaining instances for my classes out to the libraries defining them when I can muster that much willpower. ;) Another package I had orphaned a bunch of instances on was aeson. Now that that too is platformed, I feel less guilty about depending on it directly. *tl;dr* Rambling historical musings on why my vector-instances package is now a bad idea. I'm just a flat +1 on this proposal now, no caveats. On Wed, Feb 26, 2014 at 3:12 PM, Yitzchak Gale wrote: > Edward Kmett wrote: > > There may be some quibbling I'd take with the language though for the > case > > where you have a package with classes and a package that has orphans for > > those classes for a package that was too burdensome to add as a > dependency > > for the base package, both under the control of the same maintainer. > > (Mutatis mutandis for data types) > > > > An example would be vector-instances. As I control both it, and most of > the > > packages it makes orphans for, I'm simply constraining myself from not > > releasing versions of those packages with conflicting instances unless I > > bump them out of bounds. > > > > I'd like to find a way to spell this out in clearer PVP'ese, but it is > the > > way in which I'm most likely to be PVP non-compliant in the future. > > Would it help to make an exception for "standards-track" libraries > like vector? In that case, orphan instances are expected to be > only temporarily orphan. Hopefully, they will all eventually make > their way to their permanent homes. > > Thanks, > Yitz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Wed Feb 26 23:28:34 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed, 26 Feb 2014 23:28:34 +0000 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530DE47A.8080007@henning-thielemann.de> Message-ID: <530E78A2.1060802@earth.li> On 26/02/2014 14:59, Johan Tibell wrote: > On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann > > wrote: > > As far as I remember we already discussed this: > > http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html > > > > Apparently I'm getting old and forgetful. :/ > > By looking at the last thread and this thread I think the following > people support the proposal: > > Johan Tibell > Michael Snoyman > Christian Maeder > Henning Thielemann > > And the following people against: > > Ganesh Sittampalam > Ivan Lazar Miljenovic > Erik Hesselink I think my previous opposition was based on the fact that orphan instances appeared to be ruled out altogether by the proposal then. Given the statement in your new proposal "If a package defines an orphan instance, it must depend on the minor version of the packages", I'm now a +1. Ganesh From ivan.miljenovic at gmail.com Wed Feb 26 23:47:38 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 27 Feb 2014 10:47:38 +1100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: <530E78A2.1060802@earth.li> References: <530DE47A.8080007@henning-thielemann.de> <530E78A2.1060802@earth.li> Message-ID: On 27 February 2014 10:28, Ganesh Sittampalam wrote: > On 26/02/2014 14:59, Johan Tibell wrote: >> On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann >> > > wrote: >> >> As far as I remember we already discussed this: >> >> http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html >> >> >> >> Apparently I'm getting old and forgetful. :/ >> >> By looking at the last thread and this thread I think the following >> people support the proposal: >> >> Johan Tibell >> Michael Snoyman >> Christian Maeder >> Henning Thielemann >> >> And the following people against: >> >> Ganesh Sittampalam >> Ivan Lazar Miljenovic >> Erik Hesselink > > I think my previous opposition was based on the fact that orphan > instances appeared to be ruled out altogether by the proposal then. > > Given the statement in your new proposal "If a package defines an orphan > instance, it must depend on the minor version of the packages", I'm now > a +1. I think I was the same, so I'm now +1 as well. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From hesselink at gmail.com Thu Feb 27 00:05:22 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 27 Feb 2014 01:05:22 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530DE47A.8080007@henning-thielemann.de> <530E78A2.1060802@earth.li> Message-ID: On Thu, Feb 27, 2014 at 12:47 AM, Ivan Lazar Miljenovic wrote: > On 27 February 2014 10:28, Ganesh Sittampalam wrote: >> On 26/02/2014 14:59, Johan Tibell wrote: >>> On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann >>> >> > wrote: >>> >>> As far as I remember we already discussed this: >>> >>> http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html >>> >>> >>> >>> Apparently I'm getting old and forgetful. :/ >>> >>> By looking at the last thread and this thread I think the following >>> people support the proposal: >>> >>> Johan Tibell >>> Michael Snoyman >>> Christian Maeder >>> Henning Thielemann >>> >>> And the following people against: >>> >>> Ganesh Sittampalam >>> Ivan Lazar Miljenovic >>> Erik Hesselink >> >> I think my previous opposition was based on the fact that orphan >> instances appeared to be ruled out altogether by the proposal then. >> >> Given the statement in your new proposal "If a package defines an orphan >> instance, it must depend on the minor version of the packages", I'm now >> a +1. > > I think I was the same, so I'm now +1 as well. I've also changed my mind, depending on a minor version (or going with a newtype) seems good enough. I guess that's all the -1's... Erik From winterkoninkje at gmail.com Thu Feb 27 01:30:03 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Wed, 26 Feb 2014 20:30:03 -0500 Subject: Proposal: add new Data.Bits.Bits(bitZero) method (was: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: I'm +1 for the following slightly extended proposal: * add zeroBits * with default implementation: clearBit (bit 0) 0 * and requiring the following laws for all n valid for the type: * clearBit zeroBits n == zeroBits * setBit zeroBits n == bit n * testBit zeroBits n == False * popCount zeroBits == 0 -- Live well, ~wren From michael at snoyman.com Thu Feb 27 05:58:33 2014 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 27 Feb 2014 07:58:33 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Wed, Feb 26, 2014 at 6:35 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > michael, > respectfully, i've had the experience of trying to build a yesod app > (git-annex) in a cabal sandbox and i had a version conflict between your > own libraries. the only way I could build git-annex was by disabling the > web-gui yesod piece. The key piece here is your libraries conflicted with > themselves. Thats on you. > > If you have the details on when that happened, I'd be very curious to hear them. I thought my release process had ironed out those possibilities, but if not, I'd like to know about it. Which packages conflicted? > likewise, 9 time out of 10, when someone tries haskell for the first and > they tell me "cabal didn't work", I can guess "you tried to install yesod". > They then say "yes", and then I have to explain to them that "yesod has > notoriously fragile build constraints, even people who use yesod find it > maddening depending on their use case". > > Are these people usually following the actual Yesod installation instructions? Does anyone tell them to follow the Yesod installation instructions? I created the yesod-platform because the PVP *wasn't* fixing this issue. That's why I'm so skeptical that "start using the PVP" would actually fix any of that. > Michael, respectfully, most version constraint build failures are human > friendly, yours are cthulian. > > > I spend a wee bit of time every major GHC release helping patch all the > various libs i use (including helping get pandoc ready for each new ghc). > It usaually pretty easy. Its often just needing a teeny bit of CPP for an > API change plus adjusting cabal range to be wider. I'm totally ok with > doing that 1-2 times a year in exchange for nice things. I'd rather do a > test and patch cycle every year than have surprise build failures. > > > > On Wed, Feb 26, 2014 at 11:06 AM, Michael Snoyman wrote: > >> >> >> On Wednesday, February 26, 2014, Brandon Allbery >> wrote: >> >>> On Wed, Feb 26, 2014 at 2:11 AM, Michael Snoyman wrote: >>> >>>> I disagree with that assertion. I get plenty of complaints from users >>>> about trying to install packages and getting "confusing error messages" >>>> about cabal plan mismatches. I don't disagree that the PVP does make the >>>> user experience better in some cases. What I disagree with is the >>>> implication that it makes the user experience better in *all* cases. This >>>> is simply not a black-and-white issue. >>>> >>> >>> And how much of this is because you use your own versioning riules >>> instead of what everyone else uses, thereby almost guaranteeing conflicts >>> with everyone else when anything is updated? Seriously, the easiest way to >>> get in trouble with the current system is to insist you get to not follow >>> it, because stuff breaks. Asserting it's everyone else's fault isn't a >>> solution. >>> >>> >> Given that yesod followed the pvp strictly for a number of years and >> still faced a large number of dependency issues, I don't think the problem >> is in the lack of pvp support. >> >> The most recent example of this issue was a user trying to use ghc 7.8 >> and getting an error message about an upper bound on base in the esqueleto >> package. I'm sure most of us on this mailing list would consider this an >> easy error message, but at least one of our mythical end users was >> seriously confused by this situation. It turned out that simply dropping >> the upper bound was sufficient. >> >> So I come back to this being a numbers game. End users don't necessarily >> find cabal version error messages any better than ghc build failures. The >> question is how can we minimize any kind of build failure. >> >> Michael >> >> Seriously, if everyone follows your versioning system, hsenv becomes >>> essential just as RVM is essential in the Rails community; everyone has to >>> provide their own curated system (your Stackage isn't going to serve >>> everyone's needs, and asking you to make it serve everyone's needs is >>> unreasonable and quite likely an impossible task when everyone else is also >>> doing their own thing) and users have to maintain separate ecosystems for >>> everything they use. This isn't maintainable for much of anyone. >>> >>> >> Actually, why wouldn't stackage as a curated system work for everyone? >> Stackage already has over 10% of hackage covered, and I'd imagine if you >> look at hackage download numbers, that covers the vast majority of the most >> downloaded packages. I really do think that a curated system could make >> most people happy, if it gets enough buy-in. >> >> >>> (I see someone else later on actually advocated this as a solution. It's >>> not. It's an ongoing maintenance disaster that leads to unmanageable >>> systems.) >>> >>> -- >>> brandon s allbery kf8nh sine nomine >>> associates >>> allbery.b at gmail.com >>> ballbery at sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 27 08:05:43 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 27 Feb 2014 03:05:43 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: i have no clue, i'm just there dealing with the fallout of a confused new person who is convinced that cabal just doesn't work. and no fallout shelters in sight so I have to provide quick solutions that work? to prevent frustration radiation poisoning. why not just put all the modules in the same package? :) I jest, BUT i have a real point in saying that. why should i have to use a wrapper package which pins all the constraints? On Thu, Feb 27, 2014 at 12:58 AM, Michael Snoyman wrote: > > > > On Wed, Feb 26, 2014 at 6:35 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> michael, >> respectfully, i've had the experience of trying to build a yesod app >> (git-annex) in a cabal sandbox and i had a version conflict between your >> own libraries. the only way I could build git-annex was by disabling the >> web-gui yesod piece. The key piece here is your libraries conflicted with >> themselves. Thats on you. >> >> > If you have the details on when that happened, I'd be very curious to hear > them. I thought my release process had ironed out those possibilities, but > if not, I'd like to know about it. Which packages conflicted? > > >> likewise, 9 time out of 10, when someone tries haskell for the first and >> they tell me "cabal didn't work", I can guess "you tried to install yesod". >> They then say "yes", and then I have to explain to them that "yesod has >> notoriously fragile build constraints, even people who use yesod find it >> maddening depending on their use case". >> >> > Are these people usually following the actual Yesod installation > instructions? Does anyone tell them to follow the Yesod installation > instructions? I created the yesod-platform because the PVP *wasn't* fixing > this issue. That's why I'm so skeptical that "start using the PVP" would > actually fix any of that. > > >> Michael, respectfully, most version constraint build failures are human >> friendly, yours are cthulian. >> >> >> I spend a wee bit of time every major GHC release helping patch all the >> various libs i use (including helping get pandoc ready for each new ghc). >> It usaually pretty easy. Its often just needing a teeny bit of CPP for an >> API change plus adjusting cabal range to be wider. I'm totally ok with >> doing that 1-2 times a year in exchange for nice things. I'd rather do a >> test and patch cycle every year than have surprise build failures. >> >> >> >> On Wed, Feb 26, 2014 at 11:06 AM, Michael Snoyman wrote: >> >>> >>> >>> On Wednesday, February 26, 2014, Brandon Allbery >>> wrote: >>> >>>> On Wed, Feb 26, 2014 at 2:11 AM, Michael Snoyman wrote: >>>> >>>>> I disagree with that assertion. I get plenty of complaints from users >>>>> about trying to install packages and getting "confusing error messages" >>>>> about cabal plan mismatches. I don't disagree that the PVP does make the >>>>> user experience better in some cases. What I disagree with is the >>>>> implication that it makes the user experience better in *all* cases. This >>>>> is simply not a black-and-white issue. >>>>> >>>> >>>> And how much of this is because you use your own versioning riules >>>> instead of what everyone else uses, thereby almost guaranteeing conflicts >>>> with everyone else when anything is updated? Seriously, the easiest way to >>>> get in trouble with the current system is to insist you get to not follow >>>> it, because stuff breaks. Asserting it's everyone else's fault isn't a >>>> solution. >>>> >>>> >>> Given that yesod followed the pvp strictly for a number of years and >>> still faced a large number of dependency issues, I don't think the problem >>> is in the lack of pvp support. >>> >>> The most recent example of this issue was a user trying to use ghc 7.8 >>> and getting an error message about an upper bound on base in the esqueleto >>> package. I'm sure most of us on this mailing list would consider this an >>> easy error message, but at least one of our mythical end users was >>> seriously confused by this situation. It turned out that simply dropping >>> the upper bound was sufficient. >>> >>> So I come back to this being a numbers game. End users don't necessarily >>> find cabal version error messages any better than ghc build failures. The >>> question is how can we minimize any kind of build failure. >>> >>> Michael >>> >>> Seriously, if everyone follows your versioning system, hsenv becomes >>>> essential just as RVM is essential in the Rails community; everyone has to >>>> provide their own curated system (your Stackage isn't going to serve >>>> everyone's needs, and asking you to make it serve everyone's needs is >>>> unreasonable and quite likely an impossible task when everyone else is also >>>> doing their own thing) and users have to maintain separate ecosystems for >>>> everything they use. This isn't maintainable for much of anyone. >>>> >>>> >>> Actually, why wouldn't stackage as a curated system work for everyone? >>> Stackage already has over 10% of hackage covered, and I'd imagine if you >>> look at hackage download numbers, that covers the vast majority of the most >>> downloaded packages. I really do think that a curated system could make >>> most people happy, if it gets enough buy-in. >>> >>> >>>> (I see someone else later on actually advocated this as a solution. >>>> It's not. It's an ongoing maintenance disaster that leads to unmanageable >>>> systems.) >>>> >>>> -- >>>> brandon s allbery kf8nh sine nomine >>>> associates >>>> allbery.b at gmail.com >>>> ballbery at sinenomine.net >>>> unix, openafs, kerberos, infrastructure, xmonad >>>> http://sinenomine.net >>>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Feb 27 08:12:56 2014 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 27 Feb 2014 10:12:56 +0200 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Thu, Feb 27, 2014 at 10:05 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > i have no clue, i'm just there dealing with the fallout of a confused new > person who is convinced that cabal just doesn't work. and no fallout > shelters in sight so I have to provide quick solutions that work(tm) to > prevent frustration radiation poisoning. > > why not just put all the modules in the same package? :) > I jest, BUT i have a real point in saying that. > > why should i have to use a wrapper package which pins all the constraints? > > That's a great question. It seems to be the question no one's able to answer, myself included. As I keep saying, Yesod went through years of PVP compliance, and users were constantly having build problems. It may have been the cabal-install dependency solver prior to 0.14, and now that problem is resolved. I'm not sure. I know that the new dependency solver used Yesod as a stress test case. Releasing yesod-platform was pragmatic on two fronts: 1. It guaranteed a sane build plan when cabal (for whatever reason) couldn't determine one. 2. It prevents users from getting a completely untested set of packages, hopefully insulating them from some of the turbulence of Hackage. I think you need to dial back your assumptions here. Your initial email made it sound like I'd broken the Yesod stack single-handedly a bunch of times recently. That worries me. If that actually happened, please explain how it happened. If users are getting build errors when they don't use yesod-platform, well, that's something we've known about in the Yesod community for a long time. The PVP didn't solve it, yesod-platform is a hack which fixes most of the end-user issue, and I'd love to get to a real solution. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 27 08:49:03 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 27 Feb 2014 03:49:03 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: ah, pardon the implication (one challenge when helping people new to haskell is i don't often get the console logs that were part of their "cabal "). So we have a mix of concerns, some of which are a historical artifact of cabal having been terrible in the past, and now its not (quite) as bad, but far from perfect. things I think would help on all fronts, and I think we (as a community) actually need to figure out how to allocate manpower to the following a) improve the solver tooling. Get some sort of SMT solver ACTUALLY in cabal. The constraint plans aren't that complicated compared with SMT solver benchmarks! I know of several folks who've done their own internal hacked up cabal to do this, and i've heard rumors that *someone* (don't know ) b) proactively work on tooling to improve how constraint failures are reported (though perhaps having the SMT solver tooling would address this). It'd be very very helpful to be able to identify the *minimal* set of constraints + deps that create a conflict, and explanations in that error the exhibit how the conflict in constraints is created. I think everyone agrees these are valuable, its just it requires someone to be able to commit the time to actually doing it. (which is the tricky bit) On Thu, Feb 27, 2014 at 3:12 AM, Michael Snoyman wrote: > > > > On Thu, Feb 27, 2014 at 10:05 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> i have no clue, i'm just there dealing with the fallout of a confused new >> person who is convinced that cabal just doesn't work. and no fallout >> shelters in sight so I have to provide quick solutions that work? to >> prevent frustration radiation poisoning. >> >> why not just put all the modules in the same package? :) >> I jest, BUT i have a real point in saying that. >> >> why should i have to use a wrapper package which pins all the >> constraints? >> >> > That's a great question. It seems to be the question no one's able to > answer, myself included. As I keep saying, Yesod went through years of PVP > compliance, and users were constantly having build problems. It may have > been the cabal-install dependency solver prior to 0.14, and now that > problem is resolved. I'm not sure. I know that the new dependency solver > used Yesod as a stress test case. > > Releasing yesod-platform was pragmatic on two fronts: > > 1. It guaranteed a sane build plan when cabal (for whatever reason) > couldn't determine one. > 2. It prevents users from getting a completely untested set of packages, > hopefully insulating them from some of the turbulence of Hackage. > > I think you need to dial back your assumptions here. Your initial email > made it sound like I'd broken the Yesod stack single-handedly a bunch of > times recently. That worries me. If that actually happened, please explain > how it happened. If users are getting build errors when they don't use > yesod-platform, well, that's something we've known about in the Yesod > community for a long time. The PVP didn't solve it, yesod-platform is a > hack which fixes most of the end-user issue, and I'd love to get to a real > solution. > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmacristovao at gmail.com Thu Feb 27 11:34:23 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Thu, 27 Feb 2014 11:34:23 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: Hey, So, proposal 2.0, with the received feedback: -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence -- of the specified node value lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) -- | get the sub-tree rooted at the first (left-most, depth-first) value that -- matches the provided condition findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) -- | keep only the elements that match the provided condition filter :: (a -> Bool) -> Tree a -> Tree a -- | Size of the (flattened) tree size :: Tree a -> Int size = getSum . F.foldMap (const $ Sum 1) -- | Maximum depth of tree maxDepth :: Tree a -> Int -- | Remove all nodes past a certain depth prune :: Int -> Tree a -> Tree a -- | Take the mirror-image of a tree mirror :: Tree a -> Tree a mirror (Node a ts) = Node a . reverse $ map mirror ts Any additions / comments? Thanks, Jo?o 2014-02-24 12:55 GMT+00:00 Jo?o Crist?v?o : > Hi Ivan, > > >>> then what about the arguably better name `size`? >> Huh, I thought we already had that. > > We do? > If there is consensus I would then add `size` with the arguably more > efficient implementation: > size :: Tree a -> Int > size = getSum . F.foldMap (const $ Sum 1) > > >> * An Ord instance (achievable via standalone deriving, though this isn't >> ideal) > > Agreed. > >> * Functions to take/drop so many levels of the tree (take is >> relatively easy; drop would result in a Forest). > > Similar to treeprune in > http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat > ? > > >> mirror :: Tree a -> Tree a >> mirror (Node a ts) = Node a . reverse $ map mirror ts > > I don't have strong feeling about this one, but if more people see as > useful, why not... > > Jo?o > > > 2014-02-24 11:38 GMT+00:00 Ivan Lazar Miljenovic > : > >> On 24 February 2014 22:17, Tobias Florek wrote: >> > hi, >> > >> >> But to be honest, I don't have strong feelings about this, I'm willing >> >> to drop this particular function (length) from the proposal, if there >> >> is >> >> no consensus. >> > >> > then what about the arguably better name `size`? >> >> Huh, I thought we already had that. >> >> Some things I missed when I last used Data.Tree: >> >> * An Ord instance (achievable via standalone deriving, though this isn't >> ideal) >> >> * A function to take the mirror-image of a tree (name not that important): >> >> mirror :: Tree a -> Tree a >> mirror (Node a ts) = Node a . reverse $ map mirror ts >> >> * Functions to take/drop so many levels of the tree (take is >> relatively easy; drop would result in a Forest). >> >> >> > >> > cheers, >> > tobias florek >> > >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://www.haskell.org/mailman/listinfo/libraries >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > From ivan.miljenovic at gmail.com Thu Feb 27 11:43:24 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 27 Feb 2014 22:43:24 +1100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: And an Ord instance. On 27 February 2014 22:34, Jo?o Crist?v?o wrote: > Hey, > So, proposal 2.0, with the received feedback: > > -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence > -- of the specified node value > lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) > > -- | get the sub-tree rooted at the first (left-most, depth-first) value that > -- matches the provided condition > findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) > > -- | get the sub-tree for the specified node value in the first tree in > -- forest in which it occurs. > lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) > > -- | keep only the elements that match the provided condition > filter :: (a -> Bool) -> Tree a -> Tree a > > -- | Size of the (flattened) tree > size :: Tree a -> Int > size = getSum . F.foldMap (const $ Sum 1) > > -- | Maximum depth of tree > maxDepth :: Tree a -> Int > > -- | Remove all nodes past a certain depth > prune :: Int -> Tree a -> Tree a > > -- | Take the mirror-image of a tree > mirror :: Tree a -> Tree a > mirror (Node a ts) = Node a . reverse $ map mirror ts > > Any additions / comments? > Thanks, > Jo?o > > 2014-02-24 12:55 GMT+00:00 Jo?o Crist?v?o : >> Hi Ivan, >> >> >>>> then what about the arguably better name `size`? >>> Huh, I thought we already had that. >> >> We do? >> If there is consensus I would then add `size` with the arguably more >> efficient implementation: >> size :: Tree a -> Int >> size = getSum . F.foldMap (const $ Sum 1) >> >> >>> * An Ord instance (achievable via standalone deriving, though this isn't >>> ideal) >> >> Agreed. >> >>> * Functions to take/drop so many levels of the tree (take is >>> relatively easy; drop would result in a Forest). >> >> Similar to treeprune in >> http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat >> ? >> >> >>> mirror :: Tree a -> Tree a >>> mirror (Node a ts) = Node a . reverse $ map mirror ts >> >> I don't have strong feeling about this one, but if more people see as >> useful, why not... >> >> Jo?o >> >> >> 2014-02-24 11:38 GMT+00:00 Ivan Lazar Miljenovic >> : >> >>> On 24 February 2014 22:17, Tobias Florek wrote: >>> > hi, >>> > >>> >> But to be honest, I don't have strong feelings about this, I'm willing >>> >> to drop this particular function (length) from the proposal, if there >>> >> is >>> >> no consensus. >>> > >>> > then what about the arguably better name `size`? >>> >>> Huh, I thought we already had that. >>> >>> Some things I missed when I last used Data.Tree: >>> >>> * An Ord instance (achievable via standalone deriving, though this isn't >>> ideal) >>> >>> * A function to take the mirror-image of a tree (name not that important): >>> >>> mirror :: Tree a -> Tree a >>> mirror (Node a ts) = Node a . reverse $ map mirror ts >>> >>> * Functions to take/drop so many levels of the tree (take is >>> relatively easy; drop would result in a Forest). >>> >>> >>> > >>> > cheers, >>> > tobias florek >>> > >>> > >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries at haskell.org >>> > http://www.haskell.org/mailman/listinfo/libraries >>> >>> >>> >>> -- >>> Ivan Lazar Miljenovic >>> Ivan.Miljenovic at gmail.com >>> http://IvanMiljenovic.wordpress.com >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >> >> -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jmacristovao at gmail.com Thu Feb 27 11:48:47 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Thu, 27 Feb 2014 11:48:47 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: You're right, sorry, forgot that one. 2014-02-27 11:43 GMT+00:00 Ivan Lazar Miljenovic : > And an Ord instance. > > On 27 February 2014 22:34, Jo?o Crist?v?o wrote: >> Hey, >> So, proposal 2.0, with the received feedback: >> >> -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence >> -- of the specified node value >> lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) >> >> -- | get the sub-tree rooted at the first (left-most, depth-first) value that >> -- matches the provided condition >> findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) >> >> -- | get the sub-tree for the specified node value in the first tree in >> -- forest in which it occurs. >> lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) >> >> -- | keep only the elements that match the provided condition >> filter :: (a -> Bool) -> Tree a -> Tree a >> >> -- | Size of the (flattened) tree >> size :: Tree a -> Int >> size = getSum . F.foldMap (const $ Sum 1) >> >> -- | Maximum depth of tree >> maxDepth :: Tree a -> Int >> >> -- | Remove all nodes past a certain depth >> prune :: Int -> Tree a -> Tree a >> >> -- | Take the mirror-image of a tree >> mirror :: Tree a -> Tree a >> mirror (Node a ts) = Node a . reverse $ map mirror ts >> >> Any additions / comments? >> Thanks, >> Jo?o >> >> 2014-02-24 12:55 GMT+00:00 Jo?o Crist?v?o : >>> Hi Ivan, >>> >>> >>>>> then what about the arguably better name `size`? >>>> Huh, I thought we already had that. >>> >>> We do? >>> If there is consensus I would then add `size` with the arguably more >>> efficient implementation: >>> size :: Tree a -> Int >>> size = getSum . F.foldMap (const $ Sum 1) >>> >>> >>>> * An Ord instance (achievable via standalone deriving, though this isn't >>>> ideal) >>> >>> Agreed. >>> >>>> * Functions to take/drop so many levels of the tree (take is >>>> relatively easy; drop would result in a Forest). >>> >>> Similar to treeprune in >>> http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.html#v:subtreeat >>> ? >>> >>> >>>> mirror :: Tree a -> Tree a >>>> mirror (Node a ts) = Node a . reverse $ map mirror ts >>> >>> I don't have strong feeling about this one, but if more people see as >>> useful, why not... >>> >>> Jo?o >>> >>> >>> 2014-02-24 11:38 GMT+00:00 Ivan Lazar Miljenovic >>> : >>> >>>> On 24 February 2014 22:17, Tobias Florek wrote: >>>> > hi, >>>> > >>>> >> But to be honest, I don't have strong feelings about this, I'm willing >>>> >> to drop this particular function (length) from the proposal, if there >>>> >> is >>>> >> no consensus. >>>> > >>>> > then what about the arguably better name `size`? >>>> >>>> Huh, I thought we already had that. >>>> >>>> Some things I missed when I last used Data.Tree: >>>> >>>> * An Ord instance (achievable via standalone deriving, though this isn't >>>> ideal) >>>> >>>> * A function to take the mirror-image of a tree (name not that important): >>>> >>>> mirror :: Tree a -> Tree a >>>> mirror (Node a ts) = Node a . reverse $ map mirror ts >>>> >>>> * Functions to take/drop so many levels of the tree (take is >>>> relatively easy; drop would result in a Forest). >>>> >>>> >>>> > >>>> > cheers, >>>> > tobias florek >>>> > >>>> > >>>> > _______________________________________________ >>>> > Libraries mailing list >>>> > Libraries at haskell.org >>>> > http://www.haskell.org/mailman/listinfo/libraries >>>> >>>> >>>> >>>> -- >>>> Ivan Lazar Miljenovic >>>> Ivan.Miljenovic at gmail.com >>>> http://IvanMiljenovic.wordpress.com >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com From johan.tibell at gmail.com Thu Feb 27 13:08:27 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 27 Feb 2014 14:08:27 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: Hi, General comment: none of the other containers APIs use a function suffix. I noticed that Data.Tree does for a bunch of functions. Perhaps we should avoid continuing down that path and instead have functions like 'lookup' and 'lookupInForest'. On Thu, Feb 27, 2014 at 12:34 PM, Jo?o Crist?v?o wrote: > -- | get the sub-tree rooted at the first (left-most, depth-first) value > that > -- matches the provided condition > findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) > I believe we usually use a "By" suffix for functions that take the predicate as an argument instead of as an instance. So I'd vote for lookupBy instead of findTree. Cheers, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Thu Feb 27 14:05:00 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Thu, 27 Feb 2014 15:05:00 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: <530F460C.1040803@henning-thielemann.de> Am 27.02.2014 14:08, schrieb Johan Tibell: > General comment: none of the other containers APIs use a > function suffix. I noticed that Data.Tree does for a bunch of > functions. Perhaps we should avoid continuing down that path and instead > have functions like 'lookup' and 'lookupInForest'. Yes please, but I already got lots of resistance for a qualifiable name in Data.Bits. From sean.leather at gmail.com Thu Feb 27 14:53:01 2014 From: sean.leather at gmail.com (Sean Leather) Date: Thu, 27 Feb 2014 16:53:01 +0200 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: On Thu, Feb 27, 2014 at 3:08 PM, Johan Tibell wrote: > General comment: none of the other containers APIs use a > function suffix. I noticed that Data.Tree does for a bunch of > functions. > Isn't that because there are Tree and Forest variants of functions with different types? For example: unfoldTree :: (b -> (a, [b])) -> b -> Tree a unfoldForest :: (b -> (a, [b])) -> [b] -> Forest a The other container APIs do not have mutually recursive type names like Tree and Forest and, therefore, do not have analogous function variants. Perhaps we should avoid continuing down that path and instead have > functions like 'lookup' and 'lookupInForest'. > To be consistent with the Data.Tree naming pattern of Tree/Forest variants, maybe these functions should be lookupTree/lookupForest or lookupInTree/lookupInForest. Otherwise, your conclusion may be valid for functions that are do not have variants. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Feb 27 15:13:01 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 27 Feb 2014 16:13:01 +0100 Subject: [PATCH 2/3] Inline nand, nor, nany and nall In-Reply-To: <1393513982-8917-1-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: <1393513982-8917-3-git-send-email-alexander@plaimi.net> --- GHC/List.lhs | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/GHC/List.lhs b/GHC/List.lhs index a8b8950..7fb751a 100644 --- a/GHC/List.lhs +++ b/GHC/List.lhs @@ -530,6 +530,7 @@ or (x:xs) = x || or xs -- -- /Since: 4.7.0.0/ nand :: [Bool] -> Bool +{-# INLINE nand #-} nand = not . and -- | 'nor' returns the negated disjunction of a Boolean list. For the result @@ -538,6 +539,7 @@ nand = not . and -- -- /Since: 4.7.0.0/ nor :: [Bool] -> Bool +{-# INLINE nor #-} nor = not . or -- | Applied to a predicate and a list, 'any' determines if any element @@ -577,6 +579,7 @@ all p (x:xs) = p x && all p xs -- 'True', the list must be finite; 'False', however, results from a 'True' -- value for the predicate applied to an element at a finite index of a finite or infinite list. nany :: (a -> Bool) -> [a] -> Bool +{-# INLINE nany #-} nany p = not . any p -- | Applied to a predicate and a list, 'nall' determines if not all elements @@ -584,6 +587,7 @@ nany p = not . any p -- 'False', the list must be finite; 'True', however, results from a 'False' -- value for the predicate applied to an element at a finite index of a finite or infinite list. nall :: (a -> Bool) -> [a] -> Bool +{-# INLINE nall #-} nall p = not . all p -- | 'elem' is the list membership predicate, usually written in infix form, -- 1.8.3.2 From alexander at plaimi.net Thu Feb 27 15:13:02 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 27 Feb 2014 16:13:02 +0100 Subject: [PATCH 3/3] Put nand, nor, nany and nall in Prelude In-Reply-To: <1393513982-8917-1-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: <1393513982-8917-4-git-send-email-alexander@plaimi.net> Again, if 'and' and 'or' are exposed without it being a problem, 'nand' and 'nor' could be too without causing a dramatic namespace pollution. --- Prelude.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Prelude.hs b/Prelude.hs index 6be7846..79e3868 100644 --- a/Prelude.hs +++ b/Prelude.hs @@ -83,7 +83,7 @@ module Prelude ( -- ** Reducing lists (folds) foldl, foldl1, foldr, foldr1, -- *** Special folds - and, or, any, all, + and, or, nand, nor, any, all, nany, nall, sum, product, concat, concatMap, maximum, minimum, -- 1.8.3.2 From alexander at plaimi.net Thu Feb 27 15:12:59 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 27 Feb 2014 16:12:59 +0100 Subject: [PATCH 0/3] Implement nand/nor/nany/nall in Data.List Message-ID: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Hi. I'm a complete GHC newbie (and, really, a Haskell newbie still as well). To dive in and learn, I hacked together this. I did it primarily to familiarise myself with GHC workflow, formalities and procedures. Things like style conventions, using Trac, learning how to build GHC, how the files are structured and so on. However, my primary intention of learning does not mean that I don't find these patches valuable. I'm sick of typing (not . and), and even more sick of reading it. I find nand much more intuitive to read. Herbert told me to send these here since they affect base. I can imagine people are vary of putting stuff in base, and certainly prelude. But if I seem ignorant and ahistorical, that's because I *am*. So please, if there is something wrong with my patches, don't hesitate to educate me. Learning the ways of GHC hacking is after all my long-term goal. :-) Alexander Berntsen (3): Implement nand, nor, nany and nall in Data.List Inline nand, nor, nany and nall Put nand, nor, nany and nall in Prelude Data/List.hs | 4 ++++ GHC/List.lhs | 38 ++++++++++++++++++++++++++++++++++++-- Prelude.hs | 2 +- changelog.md | 3 +++ 4 files changed, 44 insertions(+), 3 deletions(-) -- 1.8.3.2 From alexander at plaimi.net Thu Feb 27 15:13:00 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 27 Feb 2014 16:13:00 +0100 Subject: [PATCH 1/3] Implement nand, nor, nany and nall in Data.List In-Reply-To: <1393513982-8917-1-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: <1393513982-8917-2-git-send-email-alexander@plaimi.net> Implement negation-shorthands for `and`, `or`, `any` and `all` in Data.List: `nand`, `nor`, `nany`, `nall`. These functions compose `not` with `and`, `or`, `any` and `all` respectively. The rationale is less typing, and a more readable and immediately obvious way of doing this. The added namespace pollution should not be dramatic. If someone has defined the negations of `and` etc. elsewhere, they have likely defined `and` etc. as well. --- Data/List.hs | 4 ++++ GHC/List.lhs | 34 ++++++++++++++++++++++++++++++++-- changelog.md | 3 +++ 3 files changed, 39 insertions(+), 2 deletions(-) diff --git a/Data/List.hs b/Data/List.hs index 09aed9d..6675dfc 100644 --- a/Data/List.hs +++ b/Data/List.hs @@ -53,8 +53,12 @@ module Data.List , concatMap , and , or + , nand + , nor , any , all + , nany + , nall , sum , product , maximum diff --git a/GHC/List.lhs b/GHC/List.lhs index e004ded..a8b8950 100644 --- a/GHC/List.lhs +++ b/GHC/List.lhs @@ -25,8 +25,8 @@ module GHC.List ( foldl, scanl, scanl1, foldr, foldr1, scanr, scanr1, iterate, repeat, replicate, cycle, take, drop, splitAt, takeWhile, dropWhile, span, break, - reverse, and, or, - any, all, elem, notElem, lookup, + reverse, and, or, nand, nor, + any, all, nany, nall, elem, notElem, lookup, concatMap, zip, zip3, zipWith, zipWith3, unzip, unzip3, errorEmptyList, @@ -524,6 +524,22 @@ or (x:xs) = x || or xs #-} #endif +-- | 'nand' returns the negated conjunction of a Boolean list. For the result +-- to be 'False', the list must be finite; 'True', however, results from a +-- 'False' value at a finite index of a finite or infinite list. +-- +-- /Since: 4.7.0.0/ +nand :: [Bool] -> Bool +nand = not . and + +-- | 'nor' returns the negated disjunction of a Boolean list. For the result +-- to be 'True', the list must be finite; 'False', however, results from a +-- 'True' value at a finite index of a finite or infinite list. +-- +-- /Since: 4.7.0.0/ +nor :: [Bool] -> Bool +nor = not . or + -- | Applied to a predicate and a list, 'any' determines if any element -- of the list satisfies the predicate. For the result to be -- 'False', the list must be finite; 'True', however, results from a 'True' @@ -556,6 +572,20 @@ all p (x:xs) = p x && all p xs #-} #endif +-- | Applied to a predicate and a list, 'nany' determines if no element +-- of the list satisfies the predicate. For the result to be +-- 'True', the list must be finite; 'False', however, results from a 'True' +-- value for the predicate applied to an element at a finite index of a finite or infinite list. +nany :: (a -> Bool) -> [a] -> Bool +nany p = not . any p + +-- | Applied to a predicate and a list, 'nall' determines if not all elements +-- of the list satisfy the predicate. For the result to be +-- 'False', the list must be finite; 'True', however, results from a 'False' +-- value for the predicate applied to an element at a finite index of a finite or infinite list. +nall :: (a -> Bool) -> [a] -> Bool +nall p = not . all p + -- | 'elem' is the list membership predicate, usually written in infix form, -- e.g., @x \`elem\` xs at . For the result to be -- 'False', the list must be finite; 'True', however, results from an element equal to @x@ found at a finite index of a finite or infinite list. diff --git a/changelog.md b/changelog.md index 88ceec5..20c90f7 100644 --- a/changelog.md +++ b/changelog.md @@ -125,4 +125,7 @@ * Remove deprecated function `unsafePerformIO` export from `Foreign` (still available via `System.IO.Unsafe.unsafePerformIO`). + * Implement negation-shortands for `and`, `or`, `any` and `all` in + `Data.List`: `nand`, `nor`, `nany`, and `nall`. + * Various fixes and other improvements (see Git history for full details). -- 1.8.3.2 From daniel.trstenjak at gmail.com Thu Feb 27 15:27:42 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Thu, 27 Feb 2014 16:27:42 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: <530F460C.1040803@henning-thielemann.de> References: <530B2A49.8030605@ibotty.net> <530F460C.1040803@henning-thielemann.de> Message-ID: <20140227152742.GA28846@machine> On Thu, Feb 27, 2014 at 03:05:00PM +0100, Henning Thielemann wrote: > Yes please, but I already got lots of resistance for a qualifiable > name in Data.Bits. I really think that 'Data.Bits' is a bit special in this regard with all of its functions, which are often used with back ticks and importing all of them explicitely is really a bit annoying. Otherwise I'm with you :). Greetings, Daniel From haskell at nand.wakku.to Thu Feb 27 15:44:22 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Thu, 27 Feb 2014 16:44:22 +0100 Subject: [PATCH 1/3] Implement nand, nor, nany and nall in Data.List In-Reply-To: <1393513982-8917-2-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: <20140227164422.GA22354@nanodesu.talocan.mine.nu> <1393513982-8917-2-git-send-email-alexander at plaimi.net> On Thu, 27 Feb 2014 16:13:00 +0100, Alexander Berntsen wrote: > Implement negation-shorthands for `and`, `or`, `any` and `all` in > Data.List: `nand`, `nor`, `nany`, `nall`. These functions compose `not` > with `and`, `or`, `any` and `all` respectively. In lens we have ?none? for what you call nany, which I find much more readable and clear. I don't like ?nall? either but I don't know a better term for it. nand/nor at least are in widespread use outside of this patch, so I don't find them to be too confusing. From alexander at plaimi.net Thu Feb 27 15:55:16 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 27 Feb 2014 16:55:16 +0100 Subject: [PATCH 1/3] Implement nand, nor, nany and nall in Data.List In-Reply-To: <20140227164422.GA22354@nanodesu.talocan.mine.nu> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> <20140227164422.GA22354@nanodesu.talocan.mine.nu> Message-ID: <530F5FE4.4020508@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27/02/14 16:44, Niklas Haas wrote: > In lens we have ?none? for what you call nany, which I find much > more readable and clear. I don't like ?nall? either but I don't > know a better term for it. nand/nor at least are in widespread use > outside of this patch, so I don't find them to be too confusing. I agree that `none' is more readable than `nany' (though I have seen `nany' used elsewhere). However, I couldn't think of a better name for `nall' -- and `nand' and `nor' are both very common nomenclature. As such, I just settled for consistency. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMPX+QACgkQRtClrXBQc7XvAQEAkGAn2Dw0WJMD24BPSJFLbB5r sQmrVc/+yWokEAc7LMQBAIQHnx+gWAFdjkD0R0nophjl4hm82vHPpkiyqWr0nDhN =wYoY -----END PGP SIGNATURE----- From carter.schonwald at gmail.com Thu Feb 27 16:13:57 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 27 Feb 2014 11:13:57 -0500 Subject: [PATCH 1/3] Implement nand, nor, nany and nall in Data.List In-Reply-To: <530F5FE4.4020508@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> <20140227164422.GA22354@nanodesu.talocan.mine.nu> <530F5FE4.4020508@plaimi.net> Message-ID: Nexist On Thursday, February 27, 2014, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 27/02/14 16:44, Niklas Haas wrote: > > In lens we have ?none? for what you call nany, which I find much > > more readable and clear. I don't like ?nall? either but I don't > > know a better term for it. nand/nor at least are in widespread use > > outside of this patch, so I don't find them to be too confusing. > I agree that `none' is more readable than `nany' (though I have seen > `nany' used elsewhere). However, I couldn't think of a better name for > `nall' -- and `nand' and `nor' are both very common nomenclature. As > such, I just settled for consistency. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlMPX+QACgkQRtClrXBQc7XvAQEAkGAn2Dw0WJMD24BPSJFLbB5r > sQmrVc/+yWokEAc7LMQBAIQHnx+gWAFdjkD0R0nophjl4hm82vHPpkiyqWr0nDhN > =wYoY > -----END PGP SIGNATURE----- > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Thu Feb 27 16:17:24 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Thu, 27 Feb 2014 08:17:24 -0800 Subject: [PATCH 0/3] Implement nand/nor/nany/nall in Data.List In-Reply-To: <1393513982-8917-1-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: Thanks for the patches. This is a -1 vote from me: in general lately the trend has been against adding shorthand functions that can be expressed as the trivial combination of a few other combinators, especially in base. On Thu, Feb 27, 2014 at 7:12 AM, Alexander Berntsen wrote: > Hi. I'm a complete GHC newbie (and, really, a Haskell newbie still as > well). To dive in and learn, I hacked together this. > > I did it primarily to familiarise myself with GHC workflow, formalities > and procedures. Things like style conventions, using Trac, learning how > to build GHC, how the files are structured and so on. > > However, my primary intention of learning does not mean that I don't > find these patches valuable. I'm sick of typing (not . and), and even > more sick of reading it. I find nand much more intuitive to read. > > Herbert told me to send these here since they affect base. I can imagine > people are vary of putting stuff in base, and certainly prelude. But if > I seem ignorant and ahistorical, that's because I *am*. So please, if > there is something wrong with my patches, don't hesitate to educate me. > Learning the ways of GHC hacking is after all my long-term goal. :-) > > Alexander Berntsen (3): > Implement nand, nor, nany and nall in Data.List > Inline nand, nor, nany and nall > Put nand, nor, nany and nall in Prelude > > Data/List.hs | 4 ++++ > GHC/List.lhs | 38 ++++++++++++++++++++++++++++++++++++-- > Prelude.hs | 2 +- > changelog.md | 3 +++ > 4 files changed, 44 insertions(+), 3 deletions(-) > > -- > 1.8.3.2 > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Feb 27 16:20:41 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 27 Feb 2014 17:20:41 +0100 Subject: [PATCH 0/3] Implement nand/nor/nany/nall in Data.List In-Reply-To: References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: Agreed, -1 for me too for the same reason. Erik On Thu, Feb 27, 2014 at 5:17 PM, Gregory Collins wrote: > Thanks for the patches. This is a -1 vote from me: in general lately the > trend has been against adding shorthand functions that can be expressed as > the trivial combination of a few other combinators, especially in base. > > > On Thu, Feb 27, 2014 at 7:12 AM, Alexander Berntsen > wrote: >> >> Hi. I'm a complete GHC newbie (and, really, a Haskell newbie still as >> well). To dive in and learn, I hacked together this. >> >> I did it primarily to familiarise myself with GHC workflow, formalities >> and procedures. Things like style conventions, using Trac, learning how >> to build GHC, how the files are structured and so on. >> >> However, my primary intention of learning does not mean that I don't >> find these patches valuable. I'm sick of typing (not . and), and even >> more sick of reading it. I find nand much more intuitive to read. >> >> Herbert told me to send these here since they affect base. I can imagine >> people are vary of putting stuff in base, and certainly prelude. But if >> I seem ignorant and ahistorical, that's because I *am*. So please, if >> there is something wrong with my patches, don't hesitate to educate me. >> Learning the ways of GHC hacking is after all my long-term goal. :-) >> >> Alexander Berntsen (3): >> Implement nand, nor, nany and nall in Data.List >> Inline nand, nor, nany and nall >> Put nand, nor, nany and nall in Prelude >> >> Data/List.hs | 4 ++++ >> GHC/List.lhs | 38 ++++++++++++++++++++++++++++++++++++-- >> Prelude.hs | 2 +- >> changelog.md | 3 +++ >> 4 files changed, 44 insertions(+), 3 deletions(-) >> >> -- >> 1.8.3.2 >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > > > > -- > Gregory Collins > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From ky3 at atamo.com Thu Feb 27 16:21:11 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 27 Feb 2014 23:21:11 +0700 Subject: [PATCH 0/3] Implement nand/nor/nany/nall in Data.List In-Reply-To: <1393513982-8917-1-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: On Thu, Feb 27, 2014 at 10:12 PM, Alexander Berntsen wrote: > Herbert told me to send these here since they affect base. I can imagine > people are vary of putting stuff in base, and certainly prelude. But if > I seem ignorant and ahistorical, that's because I *am*. So please, if > there is something wrong with my patches, don't hesitate to educate me. > Learning the ways of GHC hacking is after all my long-term goal. :-) > Hi Alexander, It's hard to explain the general nervousness with modifying prelude + base. It's like a shared commons where rapid changes cause confusion. The general wisdom is that it's very easy to add idiomatic functions to one's kit. And by kit, I mean something like John Goerzen's MissingH. The big, silent shops that use Haskell commercially all have their own kits. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Thu Feb 27 16:30:50 2014 From: greg at gregweber.info (Greg Weber) Date: Thu, 27 Feb 2014 08:30:50 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: I actually think work on the a) cabal solver has been a distraction from more pressing issues: the need for sandboxes (that is done now) and reproducible builds (frozen dependencies). If you look at Ruby's Bundler, which has been extremely successful, it has historically (maybe they have a better solver now) been a dumb tool in terms of its solver that works extremely well. I think 90+% of this conversation is pretty wasteful, because once we have reproducible builds everything is going to change. If the energy could be re-directed to being able to create reproducible builds in Haskell, then we could figure out what the next most important priority is. Of course, I agree that better error messages like b) are always valuable. yesod-platform is essentially a reproducible build and it has been able to fix dependency issues that previously seemed unfixable. At my work we add a cabal.config to our projects to create reproducible builds, and everyone in industry does something similar for their applications. On Thu, Feb 27, 2014 at 12:49 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > ah, pardon the implication (one challenge when helping people new to > haskell is i don't often get the console logs that were part of their > "cabal "). > > So we have a mix of concerns, some of which are a historical artifact of > cabal having been terrible in the past, and now its not (quite) as bad, but > far from perfect. > > things I think would help on all fronts, and I think we (as a community) > actually need to figure out how to allocate manpower to the following > > a) improve the solver tooling. Get some sort of SMT solver ACTUALLY in > cabal. > > The constraint plans aren't that complicated compared with SMT solver > benchmarks! > I know of several folks who've done their own internal hacked up cabal to > do this, and i've heard rumors that *someone* (don't know ) > > b) proactively work on tooling to improve how constraint failures are > reported (though perhaps having the SMT solver tooling would address this). > > It'd be very very helpful to be able to identify the *minimal* set of > constraints + deps that create a conflict, and explanations in that error > the exhibit how the conflict in constraints is created. > > I think everyone agrees these are valuable, its just it requires someone > to be able to commit the time to actually doing it. (which is the tricky > bit) > > > > On Thu, Feb 27, 2014 at 3:12 AM, Michael Snoyman wrote: > >> >> >> >> On Thu, Feb 27, 2014 at 10:05 AM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> i have no clue, i'm just there dealing with the fallout of a confused >>> new person who is convinced that cabal just doesn't work. and no fallout >>> shelters in sight so I have to provide quick solutions that work(tm) to >>> prevent frustration radiation poisoning. >>> >>> why not just put all the modules in the same package? :) >>> I jest, BUT i have a real point in saying that. >>> >>> why should i have to use a wrapper package which pins all the >>> constraints? >>> >>> >> That's a great question. It seems to be the question no one's able to >> answer, myself included. As I keep saying, Yesod went through years of PVP >> compliance, and users were constantly having build problems. It may have >> been the cabal-install dependency solver prior to 0.14, and now that >> problem is resolved. I'm not sure. I know that the new dependency solver >> used Yesod as a stress test case. >> >> Releasing yesod-platform was pragmatic on two fronts: >> >> 1. It guaranteed a sane build plan when cabal (for whatever reason) >> couldn't determine one. >> 2. It prevents users from getting a completely untested set of packages, >> hopefully insulating them from some of the turbulence of Hackage. >> >> I think you need to dial back your assumptions here. Your initial email >> made it sound like I'd broken the Yesod stack single-handedly a bunch of >> times recently. That worries me. If that actually happened, please explain >> how it happened. If users are getting build errors when they don't use >> yesod-platform, well, that's something we've known about in the Yesod >> community for a long time. The PVP didn't solve it, yesod-platform is a >> hack which fixes most of the end-user issue, and I'd love to get to a real >> solution. >> >> Michael >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 27 16:38:51 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 27 Feb 2014 11:38:51 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: I don't care. I want a better solver. And I'm willing to help make it happen. On Thursday, February 27, 2014, Greg Weber wrote: > I actually think work on the a) cabal solver has been a distraction from > more pressing issues: the need for sandboxes (that is done now) and > reproducible builds (frozen dependencies). If you look at Ruby's Bundler, > which has been extremely successful, it has historically (maybe they have a > better solver now) been a dumb tool in terms of its solver that works > extremely well. I think 90+% of this conversation is pretty wasteful, > because once we have reproducible builds everything is going to change. If > the energy could be re-directed to being able to create reproducible builds > in Haskell, then we could figure out what the next most important priority > is. > > Of course, I agree that better error messages like b) are always valuable. > > yesod-platform is essentially a reproducible build and it has been able to > fix dependency issues that previously seemed unfixable. > At my work we add a cabal.config to our projects to create reproducible > builds, and everyone in industry does something similar for their > applications. > > > On Thu, Feb 27, 2014 at 12:49 AM, Carter Schonwald < > carter.schonwald at gmail.com > > wrote: > >> ah, pardon the implication (one challenge when helping people new to >> haskell is i don't often get the console logs that were part of their >> "cabal "). >> >> So we have a mix of concerns, some of which are a historical artifact of >> cabal having been terrible in the past, and now its not (quite) as bad, but >> far from perfect. >> >> things I think would help on all fronts, and I think we (as a community) >> actually need to figure out how to allocate manpower to the following >> >> a) improve the solver tooling. Get some sort of SMT solver ACTUALLY in >> cabal. >> >> The constraint plans aren't that complicated compared with SMT solver >> benchmarks! >> I know of several folks who've done their own internal hacked up cabal >> to do this, and i've heard rumors that *someone* (don't know ) >> >> b) proactively work on tooling to improve how constraint failures are >> reported (though perhaps having the SMT solver tooling would address this). >> >> It'd be very very helpful to be able to identify the *minimal* set of >> constraints + deps that create a conflict, and explanations in that error >> the exhibit how the conflict in constraints is created. >> >> I think everyone agrees these are valuable, its just it requires someone >> to be able to commit the time to actually doing it. (which is the tricky >> bit) >> >> >> >> On Thu, Feb 27, 2014 at 3:12 AM, Michael Snoyman >> > wrote: >> >>> >>> >>> >>> On Thu, Feb 27, 2014 at 10:05 AM, Carter Schonwald < >>> carter.schonwald at gmail.com >>> > wrote: >>> >>>> i have no clue, i'm just there dealing with the fallout of a confused >>>> new person who is convinced that cabal just doesn't work. and no fallout >>>> shelters in sight so I have to provide quick solutions that work? to >>>> prevent frustration radiation poisoning. >>>> >>>> why not just put all the modules in the same package? :) >>>> I jest, BUT i have a real point in saying that. >>>> >>>> why should i have to use a wrapper package which pins all the >>>> constraints? >>>> >>>> >>> That's a great question. It seems to be the question no one's able to >>> answer, myself included. As I keep saying, Yesod went through years of PVP >>> compliance, and users were constantly having build problems. It may have >>> been the cabal-install dependency solver prior to 0.14, and now that >>> problem is resolved. I'm not sure. I know that the new dependency solver >>> used Yesod as a stress test case. >>> >>> Releasing yesod-platform was pragmatic on two fronts: >>> >>> 1. It guaranteed a sane build plan when cabal (for whatever reason) >>> couldn't determine one. >>> 2. It prevents users from getting a completely untested set of packages, >>> hopefully insulating them from some of the turbulence of Hackage. >>> >>> I think you need to dial back your assumptions here. Your initial email >>> made it sound like I'd broken the Yesod stack single-handedly a bunch of >>> times recently. That worries me. If that actually happened, please explain >>> how it happened. If users are getting build errors when they don't use >>> yesod-platform, well, that's something we've known about in the Yesod >>> community for a long time. The PVP didn't solve it, yesod-platform is a >>> hack which fixes most of the end-user issue, and I'd love to get to a real >>> solution. >>> >>> Michael >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Feb 27 17:26:11 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 27 Feb 2014 18:26:11 +0100 Subject: [PATCH 0/3] Implement nand/nor/nany/nall in Data.List In-Reply-To: <1393513982-8917-1-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> Message-ID: Hi Alexander, Glad to see your getting familiar with GHC. :) Unfortunately I will have to agree with the other comments in this thread that adding these simple compositions isn't really worth it (especially not in the Prelude.) On Thu, Feb 27, 2014 at 4:12 PM, Alexander Berntsen wrote: > Hi. I'm a complete GHC newbie (and, really, a Haskell newbie still as > well). To dive in and learn, I hacked together this. > > I did it primarily to familiarise myself with GHC workflow, formalities > and procedures. Things like style conventions, using Trac, learning how > to build GHC, how the files are structured and so on. > > However, my primary intention of learning does not mean that I don't > find these patches valuable. I'm sick of typing (not . and), and even > more sick of reading it. I find nand much more intuitive to read. > > Herbert told me to send these here since they affect base. I can imagine > people are vary of putting stuff in base, and certainly prelude. But if > I seem ignorant and ahistorical, that's because I *am*. So please, if > there is something wrong with my patches, don't hesitate to educate me. > Learning the ways of GHC hacking is after all my long-term goal. :-) > > Alexander Berntsen (3): > Implement nand, nor, nany and nall in Data.List > Inline nand, nor, nany and nall > Put nand, nor, nany and nall in Prelude > > Data/List.hs | 4 ++++ > GHC/List.lhs | 38 ++++++++++++++++++++++++++++++++++++-- > Prelude.hs | 2 +- > changelog.md | 3 +++ > 4 files changed, 44 insertions(+), 3 deletions(-) > > -- > 1.8.3.2 > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Thu Feb 27 17:28:01 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 27 Feb 2014 18:28:01 +0100 Subject: [PATCH 1/3] Implement nand, nor, nany and nall in Data.List In-Reply-To: <1393513982-8917-2-git-send-email-alexander@plaimi.net> (Alexander Berntsen's message of "Thu, 27 Feb 2014 16:13:00 +0100") References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> <1393513982-8917-2-git-send-email-alexander@plaimi.net> Message-ID: <87ppm8ea8u.fsf@gnu.org> Hello Alexander, While the patches are nicely done, I'm -1 on these additions, as I don't think there's enough value (in terms of Fairbairn threshold) to have these definitions added. Fwiw, I'd go even as far as saying that I wouldn't miss it if `Data.List.{and,or}` weren't defined in `base` as I'd rather use the 'All' and 'Any' newtypes with their Monoid instances or just `{all,any} id`, given that `Data.List{all,any}` are already taken by `map`-preprocessed versions of `and`/`or`. Cheers, On 2014-02-27 at 16:13:00 +0100, Alexander Berntsen wrote: [...] > +nand :: [Bool] -> Bool > +nand = not . and [...] > +nor :: [Bool] -> Bool > +nor = not . or From austin at well-typed.com Thu Feb 27 17:35:38 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 27 Feb 2014 11:35:38 -0600 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: Hi Greg, On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber wrote: > I actually think work on the a) cabal solver has been a distraction from > more pressing issues: the need for sandboxes (that is done now) and > reproducible builds (frozen dependencies). If you look at Ruby's Bundler, > which has been extremely successful, it has historically (maybe they have a > better solver now) been a dumb tool in terms of its solver that works > extremely well. I think 90+% of this conversation is pretty wasteful, > because once we have reproducible builds everything is going to change. If > the energy could be re-directed to being able to create reproducible builds > in Haskell, then we could figure out what the next most important priority > is. I'd like to carefully point out however, that it is not a zero-sum game - work dedicated to improving the constraint solver is not work which is implicitly taken away any other set of tools - like a 'freeze' command. There is no 'distraction' IMO - it is a set of individuals (or companies, even) each with their own priorities. I think this is the sign of a healthy community, actually - one that places importance on its tools and seeks to find optimal ways to improve them in a variety of ways. A freeze command and an improved solver are both excellent (and worthy) improvements. In reality, bundler works precisely for the reason you said it did: it avoids all the actually difficult problems. But that comes at a cost, because Bundler for example can't actually tell me when things *are* going to break. If I bump my dependencies, create a new Gemfile lock, and test - it could all simply explode later on at runtime, even if it could have been concluded from the constraints that it was all invalid in the first place. The only thing bundler buys me is that this explosion won't potentially extend to the rest of my global environment when it happens. Which is a good thing, truth be told, and why it is so popular - otherwise this happens constantly. Despite the fact people complain when cabal bails about reinstalls breaking things - this is infinitely preferable to things 'working now' and 'exploding later'. Even in a sandbox, or when you unfreeze your dependencies to upgrade them. Work on improving the solver here is not wasted IMO - and even the bundler developers are looking into things like SAT solvers amongst many options, precisely because the basic resolver has many bugs. Even if it's all safe in a sandbox: https://github.com/bundler/bundler/issues/2437 These two concerns are, as far as I can see, in no way opposed in spirit or practice, and suggesting one is essentially wasted effort that distracts people - when I see no evidence of that - strikes me as odd. > Of course, I agree that better error messages like b) are always valuable. I think that the only way to do that is to actually stress the solver and integrate build reports into things like the Hackage server. Going by heresay from users for these issues is, in my experience, tremendously difficult. Freezing every dependency to its exact necessary state so it always works does not necessarily tell us anything about this behavior in the large (besides "it does work"), how the solver fails, how to report that in a sensible manner, or what kind of problems or usage patterns which will arise in conjunction with these things. 'cabal install' might as well be Prolog and tell me 'Yes' or 'No' if things will work, if we're not interested in that stuff. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From dan.doel at gmail.com Thu Feb 27 17:38:16 2014 From: dan.doel at gmail.com (Dan Doel) Date: Thu, 27 Feb 2014 12:38:16 -0500 Subject: [PATCH 2/3] Inline nand, nor, nany and nall In-Reply-To: <1393513982-8917-3-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> <1393513982-8917-3-git-send-email-alexander@plaimi.net> Message-ID: With regard to this patch (disregarding all the other things that people have weighed in on).... Does it actually do anything? These are all very short functions; I'd rather expect that GHC (and other compilers) would decide to inline them itself. Hope you're not getting too discouraged. :) -- Dan On Thu, Feb 27, 2014 at 10:13 AM, Alexander Berntsen wrote: > --- > GHC/List.lhs | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/GHC/List.lhs b/GHC/List.lhs > index a8b8950..7fb751a 100644 > --- a/GHC/List.lhs > +++ b/GHC/List.lhs > @@ -530,6 +530,7 @@ or (x:xs) = x || or xs > -- > -- /Since: 4.7.0.0/ > nand :: [Bool] -> Bool > +{-# INLINE nand #-} > nand = not . and > > -- | 'nor' returns the negated disjunction of a Boolean list. For the > result > @@ -538,6 +539,7 @@ nand = not . and > -- > -- /Since: 4.7.0.0/ > nor :: [Bool] -> Bool > +{-# INLINE nor #-} > nor = not . or > > -- | Applied to a predicate and a list, 'any' determines if any element > @@ -577,6 +579,7 @@ all p (x:xs) = p x && all p xs > -- 'True', the list must be finite; 'False', however, results from a > 'True' > -- value for the predicate applied to an element at a finite index of a > finite or infinite list. > nany :: (a -> Bool) -> [a] -> Bool > +{-# INLINE nany #-} > nany p = not . any p > > -- | Applied to a predicate and a list, 'nall' determines if not all > elements > @@ -584,6 +587,7 @@ nany p = not . any p > -- 'False', the list must be finite; 'True', however, results from a > 'False' > -- value for the predicate applied to an element at a finite index of a > finite or infinite list. > nall :: (a -> Bool) -> [a] -> Bool > +{-# INLINE nall #-} > nall p = not . all p > > -- | 'elem' is the list membership predicate, usually written in infix > form, > -- > 1.8.3.2 > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Feb 27 17:51:32 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 27 Feb 2014 18:51:32 +0100 Subject: [PATCH 2/3] Inline nand, nor, nany and nall In-Reply-To: References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> <1393513982-8917-3-git-send-email-alexander@plaimi.net> Message-ID: <530F7B24.2010601@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27/02/14 18:38, Dan Doel wrote: > With regard to this patch (disregarding all the other things that > people have weighed in on).... Does it actually do anything? These > are all very short functions; I'd rather expect that GHC (and > other compilers) would decide to inline them itself. I honestly do not know if GHC does this automatically. If someone can give me an answer with an explanation, that would be interesting. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMPeyQACgkQRtClrXBQc7VaBAD/V5W4WX464O8Kl45V8MkmbI3W SFfwwtlgHyoThbR5UI8A/3vAKk3y6Mgydk6Q8+fj9HM34dzqRRbCUchRs8Wjl1CD =mMzW -----END PGP SIGNATURE----- From ekmett at gmail.com Thu Feb 27 20:20:57 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 27 Feb 2014 15:20:57 -0500 Subject: [PATCH 1/3] Implement nand, nor, nany and nall in Data.List In-Reply-To: <87ppm8ea8u.fsf@gnu.org> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> <1393513982-8917-2-git-send-email-alexander@plaimi.net> <87ppm8ea8u.fsf@gnu.org> Message-ID: I'm with Herbert on the -1. They are easy enough compositions, so there is the Fairbairn threshold argument, but then there is the fact that Data.List is a common unqualified import, and that Data.Foldable _also_ exports versions of these combinators, so for consistency would want these, and as that is heading into the Prelude, the namespace pollution just gets worse. -Edward On Thu, Feb 27, 2014 at 12:28 PM, Herbert Valerio Riedel wrote: > Hello Alexander, > > While the patches are nicely done, I'm -1 on these additions, as I don't > think there's enough value (in terms of Fairbairn threshold) to have > these definitions added. > > Fwiw, I'd go even as far as saying that I wouldn't miss it if > `Data.List.{and,or}` weren't defined in `base` as I'd rather use the > 'All' and 'Any' newtypes with their Monoid instances or just > `{all,any} id`, given that `Data.List{all,any}` are already taken by > `map`-preprocessed versions of `and`/`or`. > > Cheers, > > On 2014-02-27 at 16:13:00 +0100, Alexander Berntsen wrote: > > [...] > > > +nand :: [Bool] -> Bool > > +nand = not . and > > [...] > > > +nor :: [Bool] -> Bool > > +nor = not . or > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Thu Feb 27 20:36:51 2014 From: greg at gregweber.info (Greg Weber) Date: Thu, 27 Feb 2014 12:36:51 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: On Thu, Feb 27, 2014 at 9:35 AM, Austin Seipp wrote: > Hi Greg, > > On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber wrote: > > I actually think work on the a) cabal solver has been a distraction from > > more pressing issues: the need for sandboxes (that is done now) and > > reproducible builds (frozen dependencies). If you look at Ruby's Bundler, > > which has been extremely successful, it has historically (maybe they > have a > > better solver now) been a dumb tool in terms of its solver that works > > extremely well. I think 90+% of this conversation is pretty wasteful, > > because once we have reproducible builds everything is going to change. > If > > the energy could be re-directed to being able to create reproducible > builds > > in Haskell, then we could figure out what the next most important > priority > > is. > > I'd like to carefully point out however, that it is not a zero-sum > game - work dedicated to improving the constraint solver is not work > which is implicitly taken away any other set of tools - like a > 'freeze' command. There is no 'distraction' IMO - it is a set of > individuals (or companies, even) each with their own priorities. I > think this is the sign of a healthy community, actually - one that > places importance on its tools and seeks to find optimal ways to > improve them in a variety of ways. A freeze command and an improved > solver are both excellent (and worthy) improvements. > I agree that it is not zero sum, but I do think that at some point the wrong priorities must have been chosen since I have to go to special effort to produce a consistent build. Also this is all getting mixed up with a lot of talk about PVP and other things whose relevance changes if the underlying installation machinery supports what every application developer should be doing. > In reality, bundler works precisely for the reason you said it did: it > avoids all the actually difficult problems. But that comes at a cost, > because Bundler for example can't actually tell me when things *are* > going to break. If I bump my dependencies, create a new Gemfile lock, > and test - it could all simply explode later on at runtime, even if it > could have been concluded from the constraints that it was all invalid > in the first place. The only thing bundler buys me is that this > explosion won't potentially extend to the rest of my global > environment when it happens. Which is a good thing, truth be told, and > why it is so popular - otherwise this happens constantly. > This wasn't my experience using bundler. Bundler supports conservative upgrades that create consistent packages. So if you want to upgrade something you place a range on it and ask Bundler to upgrade it. I don't doubt though that it may let you manually subvert the system. > These two concerns are, as far as I can see, in no way opposed in > spirit or practice, and suggesting one is essentially wasted effort > that distracts people - when I see no evidence of that - strikes me as > odd. > > I think the industrial Haskell group supported work on a better solver, which was definitely helpful, but I just think it would have been wiser to support work on consistent builds first. I agree that they can be worked on independently. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Feb 27 21:00:37 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 27 Feb 2014 16:00:37 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: cool, so is docmunch going to allocate some money or manpower to help out? :) On Thu, Feb 27, 2014 at 3:36 PM, Greg Weber wrote: > > > > On Thu, Feb 27, 2014 at 9:35 AM, Austin Seipp wrote: > >> Hi Greg, >> >> On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber wrote: >> > I actually think work on the a) cabal solver has been a distraction from >> > more pressing issues: the need for sandboxes (that is done now) and >> > reproducible builds (frozen dependencies). If you look at Ruby's >> Bundler, >> > which has been extremely successful, it has historically (maybe they >> have a >> > better solver now) been a dumb tool in terms of its solver that works >> > extremely well. I think 90+% of this conversation is pretty wasteful, >> > because once we have reproducible builds everything is going to change. >> If >> > the energy could be re-directed to being able to create reproducible >> builds >> > in Haskell, then we could figure out what the next most important >> priority >> > is. >> >> I'd like to carefully point out however, that it is not a zero-sum >> game - work dedicated to improving the constraint solver is not work >> which is implicitly taken away any other set of tools - like a >> 'freeze' command. There is no 'distraction' IMO - it is a set of >> individuals (or companies, even) each with their own priorities. I >> think this is the sign of a healthy community, actually - one that >> places importance on its tools and seeks to find optimal ways to >> improve them in a variety of ways. A freeze command and an improved >> solver are both excellent (and worthy) improvements. >> > > I agree that it is not zero sum, but I do think that at some point the > wrong priorities must have been chosen since I have to go to special effort > to produce a consistent build. Also this is all getting mixed up with a lot > of talk about PVP and other things whose relevance changes if the > underlying installation machinery supports what every application developer > should be doing. > > >> In reality, bundler works precisely for the reason you said it did: it >> avoids all the actually difficult problems. But that comes at a cost, >> because Bundler for example can't actually tell me when things *are* >> going to break. If I bump my dependencies, create a new Gemfile lock, >> and test - it could all simply explode later on at runtime, even if it >> could have been concluded from the constraints that it was all invalid >> in the first place. The only thing bundler buys me is that this >> explosion won't potentially extend to the rest of my global >> environment when it happens. Which is a good thing, truth be told, and >> why it is so popular - otherwise this happens constantly. >> > > This wasn't my experience using bundler. Bundler supports conservative > upgrades that create consistent packages. So if you want to upgrade > something you place a range on it and ask Bundler to upgrade it. I don't > doubt though that it may let you manually subvert the system. > > >> These two concerns are, as far as I can see, in no way opposed in >> spirit or practice, and suggesting one is essentially wasted effort >> that distracts people - when I see no evidence of that - strikes me as >> odd. >> >> > I think the industrial Haskell group supported work on a better solver, > which was definitely helpful, but I just think it would have been wiser to > support work on consistent builds first. I agree that they can be worked on > independently. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Feb 27 21:36:22 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 27 Feb 2014 16:36:22 -0500 Subject: [PATCH 3/3] Put nand, nor, nany and nall in Prelude In-Reply-To: <1393513982-8917-4-git-send-email-alexander@plaimi.net> References: <1393513982-8917-1-git-send-email-alexander@plaimi.net> <1393513982-8917-4-git-send-email-alexander@plaimi.net> Message-ID: and and or have been exposed in the Prelude for 22+ years. They were in by Haskell 1.2 from 1992 at latest, and where possibly around earlier. Any pain they cause is *long* since over. Adding nand and nor for trivial compositions causes fresh pain for anyone already using those names ... to save 3 characters. -Edward On Thu, Feb 27, 2014 at 10:13 AM, Alexander Berntsen wrote: > Again, if 'and' and 'or' are exposed without it being a problem, 'nand' > and 'nor' could be too without causing a dramatic namespace pollution. > --- > Prelude.hs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Prelude.hs b/Prelude.hs > index 6be7846..79e3868 100644 > --- a/Prelude.hs > +++ b/Prelude.hs > @@ -83,7 +83,7 @@ module Prelude ( > -- ** Reducing lists (folds) > foldl, foldl1, foldr, foldr1, > -- *** Special folds > - and, or, any, all, > + and, or, nand, nor, any, all, nany, nall, > sum, product, > concat, concatMap, > maximum, minimum, > -- > 1.8.3.2 > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Feb 27 21:39:27 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 27 Feb 2014 16:39:27 -0500 Subject: Proposal: add new Data.Bits.Bits(bitZero) method (was: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: I like those laws insofar as they go. It'd be nice to sit down and specify the rest of the Data.Bits laws some day. (Not volunteering!) -Edward On Wed, Feb 26, 2014 at 8:30 PM, wren ng thornton wrote: > I'm +1 for the following slightly extended proposal: > > * add zeroBits > * with default implementation: clearBit (bit 0) 0 > * and requiring the following laws for all n valid for the type: > * clearBit zeroBits n == zeroBits > * setBit zeroBits n == bit n > * testBit zeroBits n == False > * popCount zeroBits == 0 > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Fri Feb 28 03:17:47 2014 From: greg at gregweber.info (Greg Weber) Date: Thu, 27 Feb 2014 19:17:47 -0800 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: That was the plan. I spend a large amount of company time contributing back to open source. Originally I was going to spend some of it on helping implement cabal freeze, but I left it in the hands of others that were more capable and I haven't checked back in a long time. On Thu, Feb 27, 2014 at 1:00 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > cool, so is docmunch going to allocate some money or manpower to help out? > :) > > > On Thu, Feb 27, 2014 at 3:36 PM, Greg Weber wrote: > >> >> >> >> On Thu, Feb 27, 2014 at 9:35 AM, Austin Seipp wrote: >> >>> Hi Greg, >>> >>> On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber >>> wrote: >>> > I actually think work on the a) cabal solver has been a distraction >>> from >>> > more pressing issues: the need for sandboxes (that is done now) and >>> > reproducible builds (frozen dependencies). If you look at Ruby's >>> Bundler, >>> > which has been extremely successful, it has historically (maybe they >>> have a >>> > better solver now) been a dumb tool in terms of its solver that works >>> > extremely well. I think 90+% of this conversation is pretty wasteful, >>> > because once we have reproducible builds everything is going to >>> change. If >>> > the energy could be re-directed to being able to create reproducible >>> builds >>> > in Haskell, then we could figure out what the next most important >>> priority >>> > is. >>> >>> I'd like to carefully point out however, that it is not a zero-sum >>> game - work dedicated to improving the constraint solver is not work >>> which is implicitly taken away any other set of tools - like a >>> 'freeze' command. There is no 'distraction' IMO - it is a set of >>> individuals (or companies, even) each with their own priorities. I >>> think this is the sign of a healthy community, actually - one that >>> places importance on its tools and seeks to find optimal ways to >>> improve them in a variety of ways. A freeze command and an improved >>> solver are both excellent (and worthy) improvements. >>> >> >> I agree that it is not zero sum, but I do think that at some point the >> wrong priorities must have been chosen since I have to go to special effort >> to produce a consistent build. Also this is all getting mixed up with a lot >> of talk about PVP and other things whose relevance changes if the >> underlying installation machinery supports what every application developer >> should be doing. >> >> >>> In reality, bundler works precisely for the reason you said it did: it >>> avoids all the actually difficult problems. But that comes at a cost, >>> because Bundler for example can't actually tell me when things *are* >>> going to break. If I bump my dependencies, create a new Gemfile lock, >>> and test - it could all simply explode later on at runtime, even if it >>> could have been concluded from the constraints that it was all invalid >>> in the first place. The only thing bundler buys me is that this >>> explosion won't potentially extend to the rest of my global >>> environment when it happens. Which is a good thing, truth be told, and >>> why it is so popular - otherwise this happens constantly. >>> >> >> This wasn't my experience using bundler. Bundler supports conservative >> upgrades that create consistent packages. So if you want to upgrade >> something you place a range on it and ask Bundler to upgrade it. I don't >> doubt though that it may let you manually subvert the system. >> >> >>> These two concerns are, as far as I can see, in no way opposed in >>> spirit or practice, and suggesting one is essentially wasted effort >>> that distracts people - when I see no evidence of that - strikes me as >>> odd. >>> >>> >> I think the industrial Haskell group supported work on a better solver, >> which was definitely helpful, but I just think it would have been wiser to >> support work on consistent builds first. I agree that they can be worked on >> independently. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Feb 28 03:47:37 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 27 Feb 2014 22:47:37 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530D0846.2080102@snarc.org> <530D1062.5010006@snarc.org> Message-ID: cool! :) On Thu, Feb 27, 2014 at 10:17 PM, Greg Weber wrote: > That was the plan. I spend a large amount of company time contributing > back to open source. Originally I was going to spend some of it on helping > implement cabal freeze, but I left it in the hands of others that were more > capable and I haven't checked back in a long time. > > > On Thu, Feb 27, 2014 at 1:00 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> cool, so is docmunch going to allocate some money or manpower to help >> out? :) >> >> >> On Thu, Feb 27, 2014 at 3:36 PM, Greg Weber wrote: >> >>> >>> >>> >>> On Thu, Feb 27, 2014 at 9:35 AM, Austin Seipp wrote: >>> >>>> Hi Greg, >>>> >>>> On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber >>>> wrote: >>>> > I actually think work on the a) cabal solver has been a distraction >>>> from >>>> > more pressing issues: the need for sandboxes (that is done now) and >>>> > reproducible builds (frozen dependencies). If you look at Ruby's >>>> Bundler, >>>> > which has been extremely successful, it has historically (maybe they >>>> have a >>>> > better solver now) been a dumb tool in terms of its solver that works >>>> > extremely well. I think 90+% of this conversation is pretty wasteful, >>>> > because once we have reproducible builds everything is going to >>>> change. If >>>> > the energy could be re-directed to being able to create reproducible >>>> builds >>>> > in Haskell, then we could figure out what the next most important >>>> priority >>>> > is. >>>> >>>> I'd like to carefully point out however, that it is not a zero-sum >>>> game - work dedicated to improving the constraint solver is not work >>>> which is implicitly taken away any other set of tools - like a >>>> 'freeze' command. There is no 'distraction' IMO - it is a set of >>>> individuals (or companies, even) each with their own priorities. I >>>> think this is the sign of a healthy community, actually - one that >>>> places importance on its tools and seeks to find optimal ways to >>>> improve them in a variety of ways. A freeze command and an improved >>>> solver are both excellent (and worthy) improvements. >>>> >>> >>> I agree that it is not zero sum, but I do think that at some point the >>> wrong priorities must have been chosen since I have to go to special effort >>> to produce a consistent build. Also this is all getting mixed up with a lot >>> of talk about PVP and other things whose relevance changes if the >>> underlying installation machinery supports what every application developer >>> should be doing. >>> >>> >>>> In reality, bundler works precisely for the reason you said it did: it >>>> avoids all the actually difficult problems. But that comes at a cost, >>>> because Bundler for example can't actually tell me when things *are* >>>> going to break. If I bump my dependencies, create a new Gemfile lock, >>>> and test - it could all simply explode later on at runtime, even if it >>>> could have been concluded from the constraints that it was all invalid >>>> in the first place. The only thing bundler buys me is that this >>>> explosion won't potentially extend to the rest of my global >>>> environment when it happens. Which is a good thing, truth be told, and >>>> why it is so popular - otherwise this happens constantly. >>>> >>> >>> This wasn't my experience using bundler. Bundler supports conservative >>> upgrades that create consistent packages. So if you want to upgrade >>> something you place a range on it and ask Bundler to upgrade it. I don't >>> doubt though that it may let you manually subvert the system. >>> >>> >>>> These two concerns are, as far as I can see, in no way opposed in >>>> spirit or practice, and suggesting one is essentially wasted effort >>>> that distracts people - when I see no evidence of that - strikes me as >>>> odd. >>>> >>>> >>> I think the industrial Haskell group supported work on a better solver, >>> which was definitely helpful, but I just think it would have been wiser to >>> support work on consistent builds first. I agree that they can be worked on >>> independently. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Fri Feb 28 09:36:31 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 28 Feb 2014 10:36:31 +0100 Subject: Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: (Edward Kmett's message of "Thu, 27 Feb 2014 16:39:27 -0500") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> Message-ID: <87wqgf60kg.fsf@gnu.org> Fyi, here's a draft patch: https://github.com/hvr/packages-base/commit/03c015951a385533b9f419863c37b7df1f791190 feel free to comment on the patch (by annotating on GitHub, or discussing it here), as this is what I'll probably push to GHC HEAD after the deadline. Note: I still have to go over the existing Bits instances, to see if GHC is properly inlining/constant-folding 'clearBit (bit 0) 0' with the default-impl, or if I need to add a couple of 'zeroBits = 0' to the instances in `base`. On 2014-02-27 at 22:39:27 +0100, Edward Kmett wrote: > I like those laws insofar as they go. > > It'd be nice to sit down and specify the rest of the Data.Bits laws some > day. (Not volunteering!) > > -Edward > > > On Wed, Feb 26, 2014 at 8:30 PM, wren ng thornton > wrote: > >> I'm +1 for the following slightly extended proposal: >> >> * add zeroBits >> * with default implementation: clearBit (bit 0) 0 >> * and requiring the following laws for all n valid for the type: >> * clearBit zeroBits n == zeroBits >> * setBit zeroBits n == bit n >> * testBit zeroBits n == False >> * popCount zeroBits == 0 >> >> -- >> Live well, >> ~wren >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- "Elegance is not optional" -- Richard O'Keefe From jmacristovao at gmail.com Fri Feb 28 12:10:51 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Fri, 28 Feb 2014 12:10:51 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: <20140227152742.GA28846@machine> References: <530B2A49.8030605@ibotty.net> <530F460C.1040803@henning-thielemann.de> <20140227152742.GA28846@machine> Message-ID: I'm with Sean here, In Data.Map, for example, the lookup function returns the type Maybe a, not Data.Map k a. And find, in Data.Foldable (for which Tree has an instance) also returns a Maybe a. But the lookupTree/findTree/lookupTreeInForest functions return Maybe (Tree a), thus I added the final 'Tree' in the name. The only function name where that did not apply was filter, since (for example) for lists the filter function also returns the type of the original container, not the inner type. This was the rationale I followed. I'm afraid that renaming findTree to findBy will be confusing, as it seems that you just provide a 'evaluator function', but still return the inner type a (like find), instead of the (actual) Tree a. Cheers, Jo?o 2014-02-27 15:27 GMT+00:00 Daniel Trstenjak : > On Thu, Feb 27, 2014 at 03:05:00PM +0100, Henning Thielemann wrote: > > Yes please, but I already got lots of resistance for a qualifiable > > name in Data.Bits. > > I really think that 'Data.Bits' is a bit special in this regard with > all of its functions, which are often used with back ticks and > importing all of them explicitely is really a bit annoying. > > Otherwise I'm with you :). > > > Greetings, > Daniel > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Feb 28 13:11:10 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 28 Feb 2014 14:11:10 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> <530F460C.1040803@henning-thielemann.de> <20140227152742.GA28846@machine> Message-ID: OK. That sounds fine by me. Milan? On Fri, Feb 28, 2014 at 1:10 PM, Jo?o Crist?v?o wrote: > I'm with Sean here, > > In Data.Map, for example, the lookup function returns the type Maybe a, > not Data.Map k a. > And find, in Data.Foldable (for which Tree has an instance) also returns a > Maybe a. > > But the lookupTree/findTree/lookupTreeInForest functions return Maybe > (Tree a), thus I added the final 'Tree' in the name. > > The only function name where that did not apply was filter, since (for > example) for lists the filter function also returns the type of the > original container, not the inner type. > > This was the rationale I followed. I'm afraid that renaming findTree to > findBy will be confusing, as it seems that you just provide a 'evaluator > function', but still return the inner type a (like find), instead of the > (actual) Tree a. > > Cheers, > Jo?o > > > 2014-02-27 15:27 GMT+00:00 Daniel Trstenjak : > > On Thu, Feb 27, 2014 at 03:05:00PM +0100, Henning Thielemann wrote: >> > Yes please, but I already got lots of resistance for a qualifiable >> > name in Data.Bits. >> >> I really think that 'Data.Bits' is a bit special in this regard with >> all of its functions, which are often used with back ticks and >> importing all of them explicitely is really a bit annoying. >> >> Otherwise I'm with you :). >> >> >> Greetings, >> Daniel >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fox at ucw.cz Fri Feb 28 13:32:12 2014 From: fox at ucw.cz (Milan Straka) Date: Fri, 28 Feb 2014 14:32:12 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> <530F460C.1040803@henning-thielemann.de> <20140227152742.GA28846@machine> Message-ID: <20140228133212.GA13446@auryn.cz> Hi all, > -----Original message----- > From: Johan Tibell > Sent: 28 Feb 2014, 14:11 > > OK. That sounds fine by me. Milan? I like lookupTree (being the one who suggested that), as it is returning a Tree. But maybe it would be better to have lookupTreeBy instead of findTree -- when you see lookupTree and lookupTreeBy, it is quite obvious how they differ. If I saw lookupTree and findTree, I would have to see the docs to find the difference. I am nevertheless not convinced about lookupTreeInForest -- the name seems too long. Also, many other functions could be applied to Forest -- filterForest, pruneForest, forestSize, ... Just a wild idea -- if we want to export more functions working with Forest a, what if we added Data.Tree.Forest module, and export from there? The functions would then have the same name as the Tree counterparts. Cheers, Milan > On Fri, Feb 28, 2014 at 1:10 PM, Jo?o Crist?v?o wrote: > > > I'm with Sean here, > > > > In Data.Map, for example, the lookup function returns the type Maybe a, > > not Data.Map k a. > > And find, in Data.Foldable (for which Tree has an instance) also returns a > > Maybe a. > > > > But the lookupTree/findTree/lookupTreeInForest functions return Maybe > > (Tree a), thus I added the final 'Tree' in the name. > > > > The only function name where that did not apply was filter, since (for > > example) for lists the filter function also returns the type of the > > original container, not the inner type. > > > > This was the rationale I followed. I'm afraid that renaming findTree to > > findBy will be confusing, as it seems that you just provide a 'evaluator > > function', but still return the inner type a (like find), instead of the > > (actual) Tree a. > > > > Cheers, > > Jo?o > > > > > > 2014-02-27 15:27 GMT+00:00 Daniel Trstenjak : > > > > On Thu, Feb 27, 2014 at 03:05:00PM +0100, Henning Thielemann wrote: > >> > Yes please, but I already got lots of resistance for a qualifiable > >> > name in Data.Bits. > >> > >> I really think that 'Data.Bits' is a bit special in this regard with > >> all of its functions, which are often used with back ticks and > >> importing all of them explicitely is really a bit annoying. > >> > >> Otherwise I'm with you :). > >> > >> > >> Greetings, > >> Daniel > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > From daniel.trstenjak at gmail.com Fri Feb 28 14:22:32 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 28 Feb 2014 15:22:32 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: <20140228133212.GA13446@auryn.cz> References: <530B2A49.8030605@ibotty.net> <530F460C.1040803@henning-thielemann.de> <20140227152742.GA28846@machine> <20140228133212.GA13446@auryn.cz> Message-ID: <20140228142232.GA12551@machine> Hi Milan, On Fri, Feb 28, 2014 at 02:32:12PM +0100, Milan Straka wrote: > I like lookupTree (being the one who suggested that), as it is returning > a Tree. Ok, that's a good point. > But maybe it would be better to have lookupTreeBy instead of findTree -- > when you see lookupTree and lookupTreeBy, it is quite obvious how they > differ. If I saw lookupTree and findTree, I would have to see the docs > to find the difference. Why then not going with the shorter 'findTree' and 'findTreeBy'? Greetings, Daniel From fox at ucw.cz Fri Feb 28 17:54:23 2014 From: fox at ucw.cz (Milan Straka) Date: Fri, 28 Feb 2014 18:54:23 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: <20140228142232.GA12551@machine> References: <530F460C.1040803@henning-thielemann.de> <20140227152742.GA28846@machine> <20140228133212.GA13446@auryn.cz> <20140228142232.GA12551@machine> Message-ID: <20140228175423.GA14874@auryn.cz> Hi Daniel, > -----Original message----- > From: Daniel Trstenjak > Sent: 28 Feb 2014, 15:22 > > > But maybe it would be better to have lookupTreeBy instead of findTree -- > > when you see lookupTree and lookupTreeBy, it is quite obvious how they > > differ. If I saw lookupTree and findTree, I would have to see the docs > > to find the difference. > > Why then not going with the shorter 'findTree' and 'findTreeBy'? we are using mostly lookup in containers. Also lookup would be more consistent with Data.List.lookup (versus Data.List.find). Cheers, Milan From johan.tibell at gmail.com Fri Feb 28 18:46:38 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 28 Feb 2014 19:46:38 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: <20140228175423.GA14874@auryn.cz> References: <530F460C.1040803@henning-thielemann.de> <20140227152742.GA28846@machine> <20140228133212.GA13446@auryn.cz> <20140228142232.GA12551@machine> <20140228175423.GA14874@auryn.cz> Message-ID: On Fri, Feb 28, 2014 at 6:54 PM, Milan Straka wrote: > we are using mostly lookup in containers. Also lookup would be more > consistent with Data.List.lookup (versus Data.List.find). > Also, when we use functions called find in containers it's for functions that call 'error' on lookup failure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Fri Feb 28 20:10:09 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 28 Feb 2014 21:10:09 +0100 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <4D58D494-10BE-4EC0-AFA7-F24BFB9D1DF8@gmail.com> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530BBD10.4050300@henning-thielemann.de> <4D58D494-10BE-4EC0-AFA7-F24BFB9D1DF8@gmail.com> Message-ID: <5310ED21.6000408@henning-thielemann.de> I got distracted by writing a tool that checks consistency of package dependencies and import styles. It's not yet perfect, but usable: https://hackage.haskell.org/package/check-pvp Description: Check whether the version ranges used in the @Build-Depends@ field matches the style of module imports according to the Package Versioning Policy (PVP). See . The tool essentially looks for any dependency like @containers >=0.5 && <0.6@ that allows the addition of identifiers to modules within the version range. Then it checks whether all module imports from @containers@ are protected against name clashes that could be caused by addition of identifiers. . You must run the tool in a directory containing a Cabal package. . > $ check-pvp . This requires that the package is configured, since only then the association of packages to modules is known. If you want to run the tool on a non-configured package you may just check all imports for addition-proof style. . > $ check-pvp --include-all . It follows a detailed description of the procedure and the rationale behind it. . First the program classifies all dependencies in the Cabal file of the package. You can show all classifications with the @--classify-dependencies@ option, otherwise only problematic dependencies are shown. . A dependency like @containers >=0.5.0.3 && <0.5.1@ does not allow changes of the API of @containers@ and thus the program does not check its imports. Clashing import abbreviations are an exception. . The dependency @containers >=0.5.1 && <0.6@ requires more care when importing modules from @containers@ and this is what the program is going to check next. This is the main purpose of the program! I warmly recommend this kind of dependency range since it greatly reduces the work to keep your package going together with its imported packages. . Dependencies like @containers >=0.5@ or @containers >=0.5 && <1@ are always problematic, since within the specified version ranges identifier can disappear. There is no import style that protects against removed identifiers. . An inclusive upper bound as in @containers >=0.5 && <=0.6@ will also cause a warning, because it is unnecessarily strict. If you know that @containers-0.6@ works for you, then @containers-0.6.0.1@ or @containers-0.6.1@ will also work, depending on your import style. A special case of inclusive upper bounds are specific versions like in @containers ==0.6 at . The argument for the warning remains the same. . Please note that the check of ranges is performed entirely on the package description. The program will not inspect the imported module contents. E.g. if you depend on @containers >=0.5 && <0.6@ but import in a way that risks name clashes, then you may just extend the dependency to @containers >=0.5 && <0.6.1@ in order to let the checker fall silent. If you use the dependency @containers >=0.5 && <0.6.1@ then the checker expects that you have verified that your package works with all versions of kind @0.5.x@ and the version @0.6.0 at . Other versions would then work, too, due to the constraints imposed by package versioning policy. . Let us now look at imports that must be protected against identifier additions. . The program may complain about a lax import. This means you have imported like . > import Data.Map as Map . Additions to @Data.Map@ may clash with other identifiers, thus you must import either . > import qualified Data.Map as Map . or . > import Data.Map (Map) . The program may complain about an open list of constructors as in . > import Data.Sequence (ViewL(..)) . Additions of constructors to @ViewL@ may also conflict with other identifiers. You must instead import like . > import Data.Sequence (ViewL(EmptyL, (:<))) . or . > import qualified Data.Sequence as Seq . The program emits an error on clashing module abbreviations like . > import qualified Data.Map.Lazy as Map > import qualified Data.Map.Strict as Map . This error is raised whenever multiple modules are imported with the same abbreviation, where at least one module is open for additions. Our test is overly strict in the sense that it also blames . > import qualified Data.Map as Map > import qualified Data.Map as Map . but I think it is good idea to avoid redundant imports anyway. . Additionally you can enable a test for hiding imports with the @--pedantic@ option. The import . > import Data.Map hiding (insert) . is not bad in the sense of the PVP, but this way you depend on the existence of the identifier @insert@ although you do not need it. If it is removed in a later version of @containers@, then your import breaks although you did not use the identifier. . Finally you can control what items are checked. First of all you can select the imports that are checked. Normally the imports are checked that belong to lax dependencies like @containers >=0.5 && <0.6 at . However this requires the package to be configured in order to know which import belongs to which dependency. E.g. @Data.Map@ belongs to @containers at . You can just check all imports for being addition-proof using the @--include-all@ option. Following you can write the options @--include-import@, @--exclude-import@, @--include-dependency@, @--exclude-dependency@ that allow to additionally check or ignore imports from certain modules or packages. These modifiers are applied from left to right. E.g. @--exclude-import=Prelude@ will accept any import style for @Prelude@ and @--exclude-dependency=foobar@ will ignore the package @foobar@, say, because it does not conform to the PVP. . Secondly, you may ignore certain modules or components of the package using the options @--exclude-module@, @--exclude-library@, @--exclude-executables@, @--exclude-testsuites@, @--exclude-benchmarks at . E.g. @--exclude-module=Paths_PKG@ will exclude the Paths module that is generated by Cabal. I assume that it will always be free of name clashes. . Known problems: . * The program cannot automatically filter out the @Paths@ module. . * The program cannot find and check preprocessed modules. . * The program may yield wrong results in the presence of Cabal conditions. . If this program proves to be useful it might eventually be integrated in the @check@ command of @cabal-install at . See . . Alternative: If you want to allow exclusively large version ranges, i.e. @>=x.y && . Unfortunately there is no GHC warning on clashing module abbreviations. See . From ekmett at gmail.com Fri Feb 28 20:23:01 2014 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 28 Feb 2014 15:23:01 -0500 Subject: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method) In-Reply-To: <5310ED21.6000408@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530BBD10.4050300@henning-thielemann.de> <4D58D494-10BE-4EC0-AFA7-F24BFB9D1DF8@gmail.com> <5310ED21.6000408@henning-thielemann.de> Message-ID: I just want to say thank you for writing this tool. I may not agree with your interpretation of the PVP on this particular issue, and will probably only use it on a couple of smaller packages that have almost no imports, but at least putting code out there to help those who do want to work in that style is a very helpful and valuable thing. -Edward On Fri, Feb 28, 2014 at 3:10 PM, Henning Thielemann < schlepptop at henning-thielemann.de> wrote: > I got distracted by writing a tool that checks consistency of package > dependencies and import styles. It's not yet perfect, but usable: > > https://hackage.haskell.org/package/check-pvp > > > Description: > Check whether the version ranges used in the @Build-Depends@ field > matches the style of module imports > according to the Package Versioning Policy (PVP). > See . > The tool essentially looks for any dependency > like @containers >=0.5 && <0.6@ > that allows the addition of identifiers to modules > within the version range. > Then it checks whether all module imports from @containers@ > are protected against name clashes > that could be caused by addition of identifiers. > . > You must run the tool in a directory containing a Cabal package. > . > > $ check-pvp > . > This requires that the package is configured, > since only then the association of packages to modules is known. > If you want to run the tool on a non-configured package > you may just check all imports for addition-proof style. > . > > $ check-pvp --include-all > . > It follows a detailed description of the procedure > and the rationale behind it. > . > First the program classifies all dependencies > in the Cabal file of the package. > You can show all classifications with the @--classify-dependencies at option, > otherwise only problematic dependencies are shown. > . > A dependency like @containers >=0.5.0.3 && <0.5.1@ > does not allow changes of the API of @containers@ > and thus the program does not check its imports. > Clashing import abbreviations are an exception. > . > The dependency @containers >=0.5.1 && <0.6@ > requires more care when importing modules from @containers@ > and this is what the program is going to check next. > This is the main purpose of the program! > I warmly recommend this kind of dependency range > since it greatly reduces the work > to keep your package going together with its imported packages. > . > Dependencies like @containers >=0.5@ or @containers >=0.5 && <1@ > are always problematic, > since within the specified version ranges identifier can disappear. > There is no import style that protects against removed identifiers. > . > An inclusive upper bound as in @containers >=0.5 && <=0.6@ > will also cause a warning, because it is unnecessarily strict. > If you know that @containers-0.6@ works for you, > then @containers-0.6.0.1@ or @containers-0.6.1@ will also work, > depending on your import style. > A special case of inclusive upper bounds are specific versions > like in @containers ==0.6 at . > The argument for the warning remains the same. > . > Please note that the check of ranges > is performed entirely on the package description. > The program will not inspect the imported module contents. > E.g. if you depend on @containers >=0.5 && <0.6@ > but import in a way that risks name clashes, > then you may just extend the dependency to @containers >=0.5 && <0.6.1@ > in order to let the checker fall silent. > If you use the dependency @containers >=0.5 && <0.6.1@ > then the checker expects that you have verified > that your package works with all versions of kind @0.5.x@ > and the version @0.6.0 at . > Other versions would then work, too, > due to the constraints imposed by package versioning policy. > . > Let us now look at imports > that must be protected against identifier additions. > . > The program may complain about a lax import. > This means you have imported like > . > > import Data.Map as Map > . > Additions to @Data.Map@ may clash with other identifiers, > thus you must import either > . > > import qualified Data.Map as Map > . > or > . > > import Data.Map (Map) > . > The program may complain about an open list of constructors as in > . > > import Data.Sequence (ViewL(..)) > . > Additions of constructors to @ViewL@ may also conflict with other > identifiers. > You must instead import like > . > > import Data.Sequence (ViewL(EmptyL, (:<))) > . > or > . > > import qualified Data.Sequence as Seq > . > The program emits an error on clashing module abbreviations like > . > > import qualified Data.Map.Lazy as Map > > import qualified Data.Map.Strict as Map > . > This error is raised > whenever multiple modules are imported with the same abbreviation, > where at least one module is open for additions. > Our test is overly strict in the sense that it also blames > . > > import qualified Data.Map as Map > > import qualified Data.Map as Map > . > but I think it is good idea to avoid redundant imports anyway. > . > Additionally you can enable a test for hiding imports > with the @--pedantic@ option. > The import > . > > import Data.Map hiding (insert) > . > is not bad in the sense of the PVP, > but this way you depend on the existence of the identifier @insert@ > although you do not need it. > If it is removed in a later version of @containers@, > then your import breaks although you did not use the identifier. > . > Finally you can control what items are checked. > First of all you can select the imports that are checked. > Normally the imports are checked that belong to lax dependencies > like @containers >=0.5 && <0.6 at . > However this requires the package to be configured > in order to know which import belongs to which dependency. > E.g. @Data.Map@ belongs to @containers at . > You can just check all imports for being addition-proof > using the @--include-all@ option. > Following you can write the options > @--include-import@, > @--exclude-import@, > @--include-dependency@, > @--exclude-dependency@ > that allow to additionally check or ignore imports > from certain modules or packages. > These modifiers are applied from left to right. > E.g. @--exclude-import=Prelude@ will accept any import style for > @Prelude@ > and @--exclude-dependency=foobar@ will ignore the package @foobar@, > say, because it does not conform to the PVP. > . > Secondly, you may ignore certain modules or components of the package > using the options > @--exclude-module@, > @--exclude-library@, > @--exclude-executables@, > @--exclude-testsuites@, > @--exclude-benchmarks at . > E.g. @--exclude-module=Paths_PKG@ will exclude the Paths module > that is generated by Cabal. > I assume that it will always be free of name clashes. > . > Known problems: > . > * The program cannot automatically filter out the @Paths@ module. > . > * The program cannot find and check preprocessed modules. > . > * The program may yield wrong results in the presence of Cabal > conditions. > . > If this program proves to be useful > it might eventually be integrated in the @check@ command of > @cabal-install at . > See . > . > Alternative: > If you want to allow exclusively large version ranges, i.e. @>=x.y && > then you may also add the option @-fwarn-missing-import-lists@ > to the @GHC-Options@ fields of your Cabal file. > See . > Unfortunately there is no GHC warning on clashing module abbreviations. > See . > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Fri Feb 28 20:59:30 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 28 Feb 2014 21:59:30 +0100 Subject: qualified imports, PVP and so on -> check-pvp In-Reply-To: <5310ED21.6000408@henning-thielemann.de> References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530BBD10.4050300@henning-thielemann.de> <4D58D494-10BE-4EC0-AFA7-F24BFB9D1DF8@gmail.com> <5310ED21.6000408@henning-thielemann.de> Message-ID: <5310F8B2.4010709@henning-thielemann.de> Am 28.02.2014 21:10, schrieb Henning Thielemann: > I got distracted by writing a tool that checks consistency of package > dependencies and import styles. It's not yet perfect, but usable: > > https://hackage.haskell.org/package/check-pvp > > > Description: > ... > The program may complain about an open list of constructors as in > . > > import Data.Sequence (ViewL(..)) > . > Additions of constructors to @ViewL@ may also conflict with other > identifiers. Maybe I am too strict here. The PVP considers additions of constructors and class methods as changes, not additions. That is, we don't need to fear additions of constructor and methods within the range >=x.y && References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> <530B82A0.6090009@gmail.com> <530B842C.1090609@henning-thielemann.de> <530B8ACC.8090407@henning-thielemann.de> <530BAC00.3010402@henning-thielemann.de> <530BBD10.4050300@henning-thielemann.de> <4D58D494-10BE-4EC0-AFA7-F24BFB9D1DF8@gmail.com> <5310ED21.6000408@henning-thielemann.de> Message-ID: I second that sentiment of appreciation. As much as we all disagree on some things, we all agree you make a tremendous amount of neat code available to the community. On Friday, February 28, 2014, Edward Kmett wrote: > I just want to say thank you for writing this tool. > > I may not agree with your interpretation of the PVP on this particular > issue, and will probably only use it on a couple of smaller packages that > have almost no imports, but at least putting code out there to help those > who do want to work in that style is a very helpful and valuable thing. > > -Edward > > > On Fri, Feb 28, 2014 at 3:10 PM, Henning Thielemann < > schlepptop at henning-thielemann.de> wrote: > > I got distracted by writing a tool that checks consistency of package > dependencies and import styles. It's not yet perfect, but usable: > > https://hackage.haskell.org/package/check-pvp > > > Description: > Check whether the version ranges used in the @Build-Depends@ field > matches the style of module imports > according to the Package Versioning Policy (PVP). > See . > The tool essentially looks for any dependency > like @containers >=0.5 && <0.6@ > that allows the addition of identifiers to modules > within the version range. > Then it checks whether all module imports from @containers@ > are protected against name clashes > that could be caused by addition of identifiers. > . > You must run the tool in a directory containing a Cabal package. > . > > $ check-pvp > . > This requires that the package is configured, > since only then the association of packages to modules is known. > If you want to run the tool on a non-configured package > you may just check all imports for addition-proof style. > . > > $ check-pvp --include-all > . > It follows a detailed description of the procedure > and the rationale behind it. > . > First the program classifies all dependencies > in the Cabal file of the package. > You can show all classifications with the @--classify-dependencies at option, > otherwise only problematic dependencies are shown. > . > A dependency like @containers >=0.5.0.3 && <0.5.1@ > does not allow changes of the API of @containers@ > and thus the program does not check its imports. > Clashing import abbreviations are an exception. > . > The dependency @containers >=0.5.1 && <0.6@ > requires more care when importing modules from @containers@ > and this is what the program is going to check next. > This is the main purpose of the program! > I warmly recommend this kind of dependency range > since it greatly reduces the work > to keep your package going together with its imported packages. > . > Dependencies like @containers >=0.5@ or @containers >=0.5 && <1@ > are always problematic, > since within the specified version ranges identifier can disappear. > There is no import style that protects against removed identifiers. > . > An inclusive upper bound as in @containers >=0.5 && <=0.6@ > will also cause a warning, because it is unnecessarily strict. > If you know that @containers-0.6@ works for you, > then @containers-0.6.0.1@ or @containers-0.6.1@ will also work, > depending on your import style. > A special case of inclusive upper bounds are specific versions > like in @containers ==0.6 at . > The argument for the warning remains the same. > . > Please note that the check of ranges > is performed entirely on the package description. > The program will not inspect the imported module contents. > E.g. if you depend on @containers >=0.5 && <0.6@ > but import in a way that risks name clashes, > then you may just extend the dependency to @containers >=0.5 && <0.6.1@ > in order to let the checker fall silent. > If you use the dependency @containers >=0.5 && <0.6.1@ > then the checker expects that you have verified > that your package works with all versions of kind @0.5.x@ > and the version @0.6.0 at . > Other versions would then work, too, > due to the constraints imposed by package versioning policy. > . > Let us now look at imports > that must be protected against identifier additions. > . > The program may complain about a lax import. > This means you have imported like > . > > import Data.Map as Map > . > Additions to @Data.Map@ may clash with other identifiers, > thus you must import either > . > > import qualified Data.Map as Map > . > or > . > > import Data.Map (Map) > . > The program may complain about an open list of constructors as in > . > > import Data.Sequence (ViewL(..)) > . > Additions of constructors to @ViewL@ may also conflict with other > identifiers. > You must instead import like > . > > import Data.Sequence (ViewL(Empt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: