- Libraries - Haskell.org

text, warp and blaze-builder
by Christian Maeder 12 Dec '13

12 Dec '13

Hi, with the new version 1.0.0.0 of text I have a problem to use warp that indirectly (via blaze-builder) relies on text-0.11.3.1 I do: import qualified Data.Text as T and get: Couldn't match type `text-0.11.3.1:Data.Text.Internal.Text' with `T.Text' Expected type: [T.Text] Actual type: [text-0.11.3.1:Data.Text.Internal.Text] How is this best fixed? Cheers Christian Part of "ghc-pkg list" shows: text-0.11.3.1 text-1.0.0.0

10 17

cabal-install and local path disclosure
by harry 10 Dec '13

10 Dec '13

When compiling cabal-install, some paths on my system are hard-coded in the executable. Is it possible to avoid this? My use case is a CI server that's compiling cabal-install, then deploying it to less privileged servers which shouldn't know anything about the CI server. -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-local-path-disclosur… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

2 1

Performance bug in HTTP library affecting "cabal update"
by Thomas Schilling 10 Dec '13

10 Dec '13

Hi Ganesh and Mark, I just sent a pull request to the HTTP library [1] that dramatically improves the performance of "cabal update" (80s -> 8s on my machine). It would be nice if we could make a new release soon and compile the next Platform's "cabal-install" against it. Mark, any concerns? [1]: https://github.com/haskell/HTTP/pull/48

6 6

Proposal: add $> to Data.Functor
by Ben Franksen 08 Dec '13

08 Dec '13

Data.Functor has <$> and <$, but not $>, which should be a flipped version of <$, analogous to <*>, <*, and *> in Control.Applicative. I was astonished to see that Data.Functor doesn't have it so I had to write it myself. Then I looked on hackage and found it defined in comonad package (also re-exported from semigroupoids). One (seemingly unmaintained, last version Apr 2012) package named iterIO has it, too. infixl 4 $> -- | Replace the contents of a functor uniformly with a constant value. ($>) :: Functor f => f b -> a -> f a ($>) = flip (<$) I propose to add this to Data.Functor; mostly because I think users expect it there (again by analogy with Applicative), even though it is trivial to write (but then writing <$ is trivial, too). Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams

5 5

Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by Ricardo Catalinas Jiménez 07 Dec '13

07 Dec '13

Hi, Please review this pull request: https://github.com/jimenezrick/unix/compare/master...file-utils.patch If you find interesting this patch, then: git pull https://github.com/jimenezrick/unix.git file-utils /Ricardo

1 0

Proposal: add fusion RULES for Data.Map.mapMaybe
by Akio Takano 04 Dec '13

04 Dec '13

Hi, Currently mapMaybe does not fuse at all. The attached patch implements necessary rules for fold/build fusion in both sides (the result and the second argument) to happen. When fusion does not happen, the function should behave exactly the same as before. I ran some benchmarks, testing cases where fusion does and does not happen: http://htmlpreview.github.io/?https://github.com/takano-akio/mapmaybe-bench… The benchmark code is: https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/main.hs Discussion period: 2 weeks. Thank you, Takano Akio

3 3

role signatures in libraries
by Richard Eisenberg 03 Dec '13

03 Dec '13

Hi libraries, It seems that the syntax and semantics of role annotations has settled, and so it's time to add role annotations to various libraries. Here are the key ideas: tl;dr: Add nominal role annotations for abstract datatypes whose data has an invariant based on a class instance. Set and Map are top candidates. - We have three notions of equality: nominal, representational, and phantom. - Type equality as we know it is called *nominal*. - A newtype is considered *representationally* equal to its representation type. * Thus, if we have `newtype Age = MkAge Int`, `Age` and `Int` are representationally equal. - Any two types are "phantomly" equal. * See below for an illustrative example of why this notion is useful. - Every type parameter of every datatype and class is assigned a role. A parameter's role says what notion of equality must hold to show that two instantiations of the datatype are representationally equal. * Say we have `Bar a` where a's role is nominal. That means that `Bar Age` is *not* representationally equal to `Bar Int`. * Say we have `Foo a` where a's role is representational. That means that `Foo Age` is representationally equal to `Foo Int`. * Say we have `Quux a` where a's role is phantom. That means that `Quux Int` is representationally equal to `Quux Bool`. - Datatype roles are inferred to be the most permissive possible. * `data Bar a = MkBar (F a)` where `F` is a type family: a's role will be inferred to be nominal. * `data Foo a = MkFoo a`: a's role will be inferred to be representational. * `data Quux a = MkQuux String`: a's role will be inferred to be phantom. - Class roles are inferred to be nominal. * This choice follows from the idea that the dictionaries for `Ord Int` and `Ord Age` should not be assumed to be the same. - A role annotation can be used to change a parameter's role. The syntax is a top-level declaration `type role <typename> <list of roles>`. You need the extension RoleAnnotations to use these. Role names are spelled out (nominal, representational, phantom) and are in lower-case. * If we wanted, say, Quux's parameter's role to be representational, we could say `type role Quux representational`. - Role annotations must be in the same module as a type is defined in. - Roles can be left out by inserting `_`. This causes the role to be inferred. - Role annotations cannot be used to undercut type safety. They are checked to make sure they meet this requirement. - The new function `coerce` (in GHC.Exts) allows for 0-cost conversion between representationally equal types. * This means that converting [Quux Bool] to [Quux Int] is now free. This is why phantom equality is interesting. - You should consider adding a role annotation on any type that has an invariant based on class instances. * For example, the information stored in a Set is ordered according to the data's Ord instance. So, there should probably be an annotation `type role Set nominal`. * As a further example, the data stored in a Map cares about the Ord instance of its first parameter but not its second. So, we would probably want `type role Map nominal representational`. Note that the new roles stuff does *not* allow programmers to do more bad things than they could previously. A sufficiently clever use of GeneralizedNewtypeDeriving could invalidate any instance-based invariants you wished to impose. However, we now have the power to stop these leaks of abstraction. We also have, in `coerce`, an easier way to take advantage of any remaining holes, making it even more important to close the gaps. The user manual is updated with respect to all the roles stuff -- you may want to see there for more info. Please let me know if you have any questions about this! Richard

6 7

aeson and dlist in HP 2013.4.0.0
by Mark Lentczner 28 Nov '13

28 Nov '13

We seem to have several interlocking decisions to make about *aeson* and *dlist* in the platform: *Background:* *let me know if I got any of this wrong* - There is clear agreement to have *aeson* in the platform. - *aeson* 0.6.2.1 would require *dlist* & *blaze-builder* to be added. - There is a patch to *aeson*, already in head, that makes *aeson* use the builder in *bytestring*, and drop the dependency on *blaze-builder*. This is good, as a *bytestring* in GHC 7.8 will make *blaze-builder*obsolete. - *aeson* head uses a new Scientific type for arbitrary precision floating point. This will break users of the Number constructor of the Value type. However, it is believed that most users are probably using existing functions to parse to an from standard numeric types when needed, and those continue to work. Unclear how much impact this will have. Also, Scientific could be in it's own package (which would need to be added to the platform), or simply exposed from *aeson*. - *dlist* is stable, but could use some love - which was lovingly offered, and we could have a bump which adds some useful typeclass instances. - It was noted that *dlist* could be replaced by Endo, or explicit use of simple types. There didn't seem to be much support for the idea of altering *aeson* to do so. *Options for aeson:* 1. skip it in this release 2. include *aeson* 0.6.2.1 - requiring both *dlist* and *blaze-builder* 3. include *aeson* 0.6.2.x, a version with the patch that uses *bytestring*'s builder, and so require only *dlist* 4. include *aeson* 0.7.0.0 - requiring *dlist* and possibly *scientific* *Options for dlist, if required by the aeson choice, or because we now like it anyway:* 1. include *dlist* 0.5 2. include *dlist* 0.6, with new typeclass instances added *Options for scientific, if required by the aeson choice:* 1. include Scientific type in *aeson* 2. include a new *scientific* pacakge *Discussion:* I think the best option, if we are ready to embrace aeson, is jump in with both feet: aeson 0.7.0.0, & dlist 0.6. Leaving the issue of is scientific ready to be included as it's own package, or should it just be exported by aeson for now. Thoughts? — Mark

19 37

2013.4.0.0 proposal - getting to alpha
by Mark Lentczner 27 Nov '13

27 Nov '13

Here is the current status of the 2013.4.0.0 proposal. *Outstanding Issues* We have a few decisions outstanding, and I'd like to have these decided by Nov. 23 (one week). - fgl - waiting to hear if Ivan will have new version ready in time. - aeson / dlist - there are serveral options -- I'll start a separate thread on this topic. - alex / happy - I'd like to hear an "okay" from the maintainers on the major version bump *Current Proposed Versions* *GHC 7.6.3* -- same as last time (erroneously listed as a version bump last time) *Packages with no changes:* fgl, haskell-src, html, HUnit, mtl, parsec, QuickCheck, random, regex-base, regex-compat, regex-posix, split, stm, text, transformers, xhtml, zlib *Packages held back:* cgi: 3001.1.7.5 (3001.1.8.4* requires MonadCatchIO-mtl)* *Packages with minor version bumps:* HTTP: 4000.2.8 → 4000.2.9 network: 2.4.1.2 → 2.4.2.0 parallel: 3.2.0.3 → 3.2.0.4 syb: 0.4.0 → 0.4.1 unordered-containers: 0.2.3.0 → 0.2.3.3 vector: 0.10.0.1 → 0.10.9.1? primitive: 0.5.0.1 → 0.5.1.0? *Packages with major version bumps:* case-insensitive: 1.0.0.1 → 1.1.0.1 hashable: 1.1.2.5 → 1.2.1.0 GLUT: 2.4.0.0 → 2.5.0.1 GLURaw: 1.3.0.0 → 1.4.0.0 OpenGL: 2.8.0.0 → 2.9.1.0 OpenGLRaw: 1.3.0.0 → 1.4.0.0 alex: 3.0.5 → 3.1.0 *pending okay* happy: 1.18.10 → 1.19.0 *pending okay* *Cabal:* Cabal: 1.16.0 → 1.18.1.2 *consensus seems to be that this will be okay* cabal-install: 1.16.0.2 → 1.18.0.2 *Platform Packagers:* This is likely to be the last HP source release that contains all the ad hoc scripts for packaging. I canvased the group last time and as I recall, everyone said they just used the .cabal file - and no one used the scripts. I plan to replace them with a new tool built for the needs of the release, and ditch this old set of scripts. If you need 'em, speak now, or forever hold your peace! — Mark

7 11

Re: 2013.4.0.0 proposal - getting to alpha
by Ivan Lazar Miljenovic 26 Nov '13

26 Nov '13

Hurt, no; but it will make it inconsistent across platforms (as Linux distros typically just have meta-packages for the Platform, rather than an installer that can do this). On 26 November 2013 17:16, Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> wrote: > Hi, > > On Tue, Nov 26, 2013 at 6:02 AM, Ivan Lazar Miljenovic > <ivan.miljenovic(a)gmail.com> wrote: >> On 26 November 2013 15:46, Mikhail Glushenkov >> <the.dead.shall.rise(a)gmail.com> wrote: >>> [...] >>> The installer can run `ghc-pkg hide >>> Cabal-1.16` as the final step, so the user will never even see the >>> extra copy of Cabal. >> >> Is this necessary? > > Well, hiding Cabal-1.16 certainly can't hurt, can it? > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

4 5