- Libraries - Haskell.org

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 17 Jul '15

17 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

Abstract FilePath Proposal
by Herbert Valerio Riedel 10 Jul '15

10 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello *, What? ===== We (see From: & CC: headers) propose, plain and simple, to turn the currently defined type-synonym type FilePath = String into an abstract/opaque data type instead. Why/How/When? ============= For details (including motivation and a suggested transition scheme) please consult https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath Suggested discussion period: 4 weeks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526 YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5 KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+ NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb HjIPRrJbVK9AABo4AZ/Y =lg0o -----END PGP SIGNATURE-----

26 42

Generalizing replicateM?
by Fumiaki Kinoshita 08 Jul '15

08 Jul '15

I noticed that traceM is generalized to use Applicative. Then, how about replicateM/replicateM_? I don't quite like confusing names, but is better than needlessly restrictive.

5 5

Re: Generalizing replicateM?
by Ryan Scott 07 Jul '15

07 Jul '15

It looks like M Farkas-Dyck submitted a patch to generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, and replicateM_ to use Applicative instead of Monad: https://ghc.haskell.org/trac/ghc/ticket/10168. Also, +1 on the suggestion. Let's tie up the loose ends of the AMP now that's it's official.

2 1