- Libraries - Haskell.org

QuickCheck failures with new 'tar' release...
by Michael Alan Dorman 20 Jul '15

20 Jul '15

I'm not sure if there's a more appropriate venue to bring this up; the package doesn't seem to have any sort of explicit issue tracker. On the NixOS build servers, we're seeing across-the-board failures for the 0.4.2.0 release of the 'tar' library, specifically, two properties that were added in the latest release. It looks to me like prop_lookup is fundamentally broken---it falls over in the face of a lookup for 'a/b' in a list of entries that includes 'a/b/c/d', because while the library lookup function returns a match including the remainder of the path as a result, the Data.List.lookup that it's comparing against returns nothing. I don't see a way for the test as it is constituted to work reliably. I'm going to guess that prop_valid suffers from a similar issue. Either way, it would be nice if they could either be corrected, or diked out until that happens. Mike.

3 3

Proposal: instance Alternative ZipList
by Edward Kmett 20 Jul '15

20 Jul '15

The ZipList data type admits one legal Alternative instance instance Alternative ZipList where pure = ZipList [] ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys) The legality of this instance was first noted in http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf I propose adding this instance, which acts like a generalized version of the Alternative for Maybe, choosing with a left bias. Discussion Period: 2 weeks -Edward

4 5

Improving the "Get Haskell Experience"
by Mark Lentczner 19 Jul '15

19 Jul '15

*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.* At ICFP '14, there were several long group discussions of the state of "getting Haskell", including Haskell Platform, Stackage, and other approaches. Over the last year, there have been a few more public discussions and evolution on the ideas, and other installer developments. In particular, Stackage's LTS package sets are a direct development from this work, and the release of stack has offered new options. Today, drawing from all this good work and ideas from so many, we'd would like to propose a concrete plan: - Haskell Platform becomes the standard way to get *GHC* and related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a user-friendly, cross-platform installer that gives a standard way to "get Haskell" for most users. - Use the *stack* model for package installation: - The global db has only the GHC packages - There is a package db for each curated set, Haskell Platform becomes one such set - Projects each have their own package db, much like sandboxes. - Haskell Platform's installer will no longer include pre-built, pre-installed packages other than GHC's set. Instead, it is configured so that *stack* can be used to build and install, on as needed, the corresponding Haskell Platform release packages. We think this plan solves many different community needs: - We have a clear way to "get Haskell" that works for a wide variety of use cases. - HP installer gets much smaller, and about as minimal as a working installation can get. - By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings. - By building and installing the Platform packages into it's own package db, users get the benefit of building and installing these common packages only once per system, yet can easily bypass them for any given project if desired. - Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work. To do this, we have a bit of work ahead of us: We need to settle on installation layout for each OS (including getting msys into the Windows installer); decide on the naming and versioning of the Platform package set (is it just LTS? does it have a different life cycle? etc...); getting *stack* ready such a distribution; and configuring (or updating) *cabal-install* to support the three-layer package db scheme. We think we can do this in short order. We recognize this represents a significant change for the Platform, and will require buy-in from the various parts, especially *ghc*, *cabal*, and *stack*. We'd like to get your input. - Michael & Mark

9 13

Re: More general Generic and Data instances for Data.Proxy.Proxy?
by Ryan Scott 18 Jul '15

18 Jul '15

It does seem unnecessary. The Data instance for Proxy is manually written in Data.Data: proxyConstr :: ConstrproxyConstr = mkConstr proxyDataType "Proxy" [] PrefixproxyDataType :: DataTypeproxyDataType = mkDataType "Data.Proxy.Proxy" [proxyConstr] instance (Data t) => Data (Proxy t) where gfoldl _ z Proxy = z Proxy toConstr Proxy = proxyConstr gunfold _ z c = case constrIndex c of 1 -> z Proxy _ -> error "Data.Data.gunfold(Proxy)" dataTypeOf _ = proxyDataType dataCast1 f = gcast1 f If dataCast1 weren't defined to be gcast1, then that instance would only require a Typeable t constraint, which would make it polykinded. To be honest, I'm not sure why gcast1 requires a Data t constraint (I don't use Data that often, so hopefully someone more knowledgeable than me can answer this).

3 2

Re: More general Generic and Data instances for Data.Proxy.Proxy?
by Ryan Scott 18 Jul '15

18 Jul '15

Actually, Data.Data already has PolyKinds enabled, but the (Data t => Data (Proxy t)) instance requires that the type parameter be of kind *, since the Data typeclass has kind * -> Constraint. On the other hand, switching on PolyKinds in GHC.Generics should provide a polykinded Generic (Proxy t) instance (the corresponding instance in the tagged library is already polykinded, in fact). If we enable PolyKinds in GHC.Generics, we could also make Rep, Generic1, Rep1, V1, U1, Rec1, K1, M1, (:+:), (:*:), and (:.:) polykinded.

2 1

More general Generic and Data instances for Data.Proxy.Proxy?
by Carl Howells 17 Jul '15

17 Jul '15

At the moment, the following two instances are listed in the haddocks for Data.Proxy.Proxy: Data t => Data (Proxy * t) Generic (Proxy * t) Do those instances need to be that restrictive? Would it be possible to generalize those instances to these? Data (Proxy k t) Generic (Proxy k t) I'm not 100% comfortable with either of those classes, so I'm not sure if those instances work right, but it seems like they should in a hand-wavy way. -- Carl Howells

2 1

RFC for a change in EmptyDataDecls instance deriving
by Ömer Sinan Ağacan 16 Jul '15

16 Jul '15

# RFC for a change in EmptyDataDecls instance deriving Hi all, There were some requests about EmptyDataDecls instance deriving and recently I made some progress towards implementing those. However as I implement things people started suggesting different behaviors than what I've implemented etc. In the end, we thought it'd be a good idea to ask libraries mailing list for which behavior to implement. # Summary Haskell 2010 doesn't support data types without any constructors(aka. empty data type)[1]. GHC supports it via EmptyDataDecls[2], but it fails to derive instances: Decl.hs:3:18: Can't make a derived instance of ‘Eq Z’: ‘Z’ must have at least one data constructor Possible fix: use a standalone deriving declaration instead In the data declaration for ‘Z’ Using StandaloneDeriving works, and it generates methods that calls `error`: Derived instances: instance GHC.Classes.Eq Main.Z where (GHC.Classes.==) = GHC.Err.error "Void ==" (GHC.Classes./=) a_aCf b_aCg = GHC.Classes.not ((GHC.Classes.==) a_aCf b_aCg) Note that these methods fail in first applications. So `(==) a` is an error, it doesn't need to be a fully saturated application. Ticket 7401[3] asks for a change in default deriving mechanism. I submitted a patch[4] that makes standard deriving work same as standalone deriving, for empty data types. This is completely backwards-compatible change, since previously deriving on empty data types wasn't working.(I also made some improvements on error messages) But then some people suggested that derived methods are not good, and we should use empty pattern match in method bodies instead[5]. E.g. if we derive Eq for an empty data type, generated instance should be: instance Eq X where a == b = case a of {} See [5] for motivation. So now we're also thinking about changing StandaloneDeriving for empty types too, to use empty pattern match instead of `error`. One thing to note is Data.Void.Void is doing completely different thing, it's Eq is defined like this: instance Eq Void where _ == _ = True So now that we have the story, my questions are: 1. What do you think is the right way to derive instances for empty data types? An `error` or pattern match on bottom argument(e.g. empty case)? 2. Do you think with EmptyDataDecls and StandaloneDeriving, `deriving(..)` and standalone deriving should derive same instances? 3. Should we change instances of Void on the way, for consistency? (Ord and Eq especially) My answers: 1. Empty case. Users can always implement instances manually for always succeeding (==) etc. 2. Definitely. Current deriving mechanisms are already complex and it's hard to predict interactions between them(see [6]), I think we should do our best to keep them as simple as possible. Personally I'd hate it if standalone deriving and `deriving(...)` would implement different instances. 3. No opinion. May break some code? But making the change might be good for consistency? If answers to (2) is yes, then we can just merge [4](which also improves error messages), but if we want to change how we define instances too, then it'll need some more work and I'll be working on that. In any case, I think we should update the user manual to specify what will be the derived instances. (as far as I can see currently it's not specified) --- [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200… [2]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-e… [3]: https://ghc.haskell.org/trac/ghc/ticket/7401 [4]: https://phabricator.haskell.org/D978 [5]: https://ghc.haskell.org/trac/ghc/ticket/10577 [6]: https://ghc.haskell.org/trac/ghc/ticket/10598

7 15

Request for feedback on spec/proposal for distributing package collections via hackage
by Duncan Coutts 14 Jul '15

14 Jul '15

Hi folks, I'd like to get feedback on a spec/proposal for distributing package collections via hackage. This is currently somewhere beyond vapourware but certainly not a fait accompli and hopefully it is at an appropriate point to get feedback. The basic idea is that package collections are: * useful (IMHO, one of the top two solutions to dependency hell, alongside nix-style package management); and * just as we distribute packages via hackage, we should also be able to easily distribute package collections. One would then use them with tools like cabal and stack. Distributing via hackage (both in the sense of the format/protocol and in the sense of the central community hackage instance) seems natural, and allows taking advantage of much of the infrastructure we have for packages already like: * existing user accounts and management infrastructure on the hackage website * allowing anyone to host collections on their own servers, just as they can host their own package archives currently (either as static file sets or with smart servers) * low barrier for distribution, potentially encouraging more collections to be created potentially covering more use cases * security infrastructure (currently in alpha) * automatic mirroring (currently in alpha) Two obvious examples are stackage-lts and stackage-nightly but if we lower the barrier for distribution then there may well be many more. For example, the existing Linux distros put a lot of effort into selecting and maintain package collections, and some of these collections could be distributed via hackage. In fast several Linux distributions already use Hackage's "distro" feature to advertise which versions of packages are provided by that distro. One can also imagine special-purpose collections, and there's probably cases we've not thought of yet. Package collections are different things from packages, not like "meta packages" that one gets in some package systems. A package collection at it's simplest is just a set of source package identifiers (ie names-version pairs). Like packages, package collections have names and versions and are immutable once distributed. The intention is that users can configure their tool to use collection(s), either by nailing down a specific collection version, or by not specifying a version it would default to the latest version of the named collection. (But the specific behaviour is up to the tool) Use cases: * versioned collections. For some collections the policy by which it's defined naturally uses meaningful versions. * daily collections. These can have a date-form version number imposed on them. * "live" "rolling" collections. These could have a simple monotonic increasing version with no particular meaning attached. For such collections, clients might be configured to use the latest (by not specifying a version), but it's always possible to pick a specific revision. * special-purpose collections. Not necessarily collections aiming to cover a large number of common packages, but aiming to cover some application area, or related stack of packages (e.g. some of the web frameworks). * negative collections. Collections of packages you may specifically want to avoid (e.g. deprecated by their authors, or known-broken). Using such collections would rely on clients that can be configured to treat it negatively. Specifics: A package collection specifies a set of source package ids (id being name-version pair). It also optionally specifies a (partial) flag assignment for any package name. The collection does not specify how tools should treat them. That is, a collection does not specify if it should be treated as a strong or a soft constraint, inclusive or exclusive, positive or negative. Such things are completely up to the client's policy and configuration. Similarly for flag assignments, collections do not specify whether tools should interpret these as strong or soft constraints. Syntax: Package collection names and versions exactly follow those of package names (but they live in a different namespace). For example, "stackage-lts-2.9", or "deprecated-343" (the latter being a "rolling" collection with a meaningless monotonically increasing version). A collection distributed in the archive format is just a text file with one entry per line, such as: foo-1.0 foo-1.1 bar >= 3 && < 4 bar +this -that So each line can be one of: * a simple package id * a package version range, using Cabal version range syntax * a package name with a flag assignment, + for on, - for off The interpretation of the above is that: * both foo-1.0 and foo-1.1 are in the collection (ie union not intersection) * all versions of bar between 3 and 4 are in the collection * the package bar has flag 'this' as True, and flag 'that' as False Of course for some collections the policy is that only one version of any package is included, but this is a policy question and the format itself does not impose this constraint. Hackage archive format: collection files live under a different prefix from package tarballs (but are still considered part of the archive) and are named after the collection id. The collection files are not compressed (but of course http clients and servers can negotiate transport compression). The collection files are not included in nor listed in the existing 00-index.tar.gz, but there's other json format metadata for a client to enumerate the available collections and versions. And like with package tarballs, a client that wants a specific collection version can construct the url and fetch it directly. Security: The hackage security system that's currently in alpha testing can easily be extended to cover collections, similarly to how it covers package tarballs. Misc notes: There is no requirement that a hackage-format repo containing collections be closed. That is, the collections may refer to packages not in that archive. This could be useful for private hackage repos that host a small number of private packages, but also host collections that refer both to the private packages and public ones from the community central hackage. The resolution of package names is done by the clients, and some clients may be configured to union/overlay multiple repos. On the other hand, for the central community hackage it may be sensible to enforce a policy that the collections it distributes be closed (ie refer only to packages distributed via hackage). Questions: Is this sufficiently flexible to fully cover the obvious use cases? Are there any interesting use cases that are excluded? Anything else? Duncan

3 4

To all users of FGL
by Ivan Lazar Miljenovic 13 Jul '15

13 Jul '15

As you may now, for the past few months I've been (finally!) cleaning up FGL, adding tests, etc. One of the issues that has arisen with this is that the behaviour of the delLEdge [1] function is not well specified when dealing with multiple edges. Specifically, the documentation states that the purpose is to "Remove *an* LEdge from the Graph." (emphasis added)... but the behaviour when dealing with multiple edges is to remove *all* such edges from the graph. The current version on GitHub is to instead just delete a single such labelled edge, with a new function "delAllLEdge" that replicates the current behaviour. Before releasing this change, however, I wanted to make sure that I wouldn't break people's code if they rely upon this functionality; I did try and search through GitHub to see who - if anyone - is using this function, but primarily found various copies of fgl embedded into other people's repositories. As such, please check your code and let me know if this change in behaviour might affect you (if this is the case, I might let delLEdge keep the current behaviour and have a new function delete just one edge). [1]: http://hackage.haskell.org/package/fgl-5.5.1.0/docs/Data-Graph-Inductive-Gr… -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Using newtypes or any data with unboxed Vectors
by Ken Bateman 12 Jul '15

12 Jul '15

I think I've managed to come up with an easy, useful, and sound way for mere mortals to use unboxed vectors with arbitrary datatypes, without using template Haskell. I had a need for this capability, googled about it, and I didn't find a satisfying way to do it. This technique seemed useful and simple enough to go into the vector library, but there's so much stuff going on in there I'm not ready to submit a patch. A user just needs to create an UnboxEquivalent instance for their type, and then they can work with what looks and acts like a vector of their type, but is in fact backed by a newtype-wrapped unboxed vector of the equivalent type. newtype SmallPos = Pos Int deriving (Eq, Ord, Show) smallPos :: Int -> SmallPos smallPos x | x > 0 && x < 100 = Pos x | otherwise = error "bad SmallPos" instance UnboxEquivalent SmallPos where type UnboxEquiv SmallPos = Word8 toUnbox (Pos x) = fromIntegral x fromUnbox x = (Pos (fromIntegral x)) test1 :: EVector SmallPos test1 = Data.Vector.Generic.fromList $ map smallPos [5..15] UnboxEquivalent.hs is at http://lpaste.net/136381 Some really simple test code is at http://lpaste.net/136382 I haven't performance tested it, or stuck {-# INLINE #-} annotations in, but I think everything should be optimizing away to nothing, except of course for the toUnbox and fromUnbox calls. What do you think? -Ken

2 1