December 2013 - Libraries

Re: Removing MonadFail from Monad
by David Luposchainsky 17 Dec '13

17 Dec '13

Hey Andreas, On 16.12.2013 23:39, Andreas Abel wrote: > "Only one data constructor" should be understood hereditarily; the > description is not entirely accurate: > > -- Only one data constructor: do not add MonadFail constraint > do (Only x) <- computation >>> let f (Only x) = more > more >>> in computation >>= f > > (Only x) should be pat such that every constructor in pat is an > "only-one" constructor. Do you mean in case patterns of nested "Only" types appear, like `Only (Only' x)`? I hadn't thought of that, good point. >> - The case of one data constructor should emit a warning if the data >> type is defined via `data`: adding another data constructor can make >> patterns in unrelated modules refutable. > > I don't understand the restriction "is defined via data" since I am not > aware of defining constructors outside of data or with something other > than the data keyword. Please clarify. I meant "data and not newtype". If "Only" is a newtype data constructor, the pattern is irrefutable by design, is it not? Greetings, David/quchen

3 4

cabal: question on compiling build prerequisites
by selinger＠mathstat.dal.ca 14 Dec '13

14 Dec '13

This may be a silly question, but I can't seem to find the answer in the documentation. I would like to create a Cabal package where some of the source files use a custom pre-processor. The pre-processor is itself a Haskell program, let's say MyPreProc.hs in the package's root directory. I figured out how to activate the preprocessor, for example, cabal build --ghc-options="-F -pgmF ./MyPreProc" I also figured out how to achieve the same effect using hooks. However, there is one problem: how can I tell cabal to actually compile MyPreProc.hs before any of the commands using the preprocessor are run? The package's Setup.hs file is automatically compiled during "cabal configure". I would like MyPreProc.hs to be compiled at the same time as well - or at least some time before the proprocessor needs to be used. The .cabal file contains all kinds of related variables, such as "build-depends" (but only packages can be listed here, not programs to be compiled), "other-modules" (but these modules would already require the pre-processor, so the pre-processor should be compiled first), "build-tools" (but this only refers to external programs). My current solution is to make the pre-processor a shell script, rather than a Haskell program. But this is ugly and not portable (won't work in Windows, for example). To clarify: my custom preprocessor is local to this package. It has no independent value, so it would not make sense to publish it as a separate package just so that I can add it to build-depends. Is there a known solution to this problem? Thanks, -- Peter

5 11

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