October 2013 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: Use time rather than old-time in directory
by Ian Lynagh 17 Sep '14

17 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by John Wiegley 11 Aug '14

11 Aug '14

1. I propose that we add the following package to base: http://hackage.haskell.org/packages/archive/semigroups/0.9.2/doc/html/Data-… This is somewhat in the spirit of the AMP proposal: further improving the correctness of our algebraic abstractions. 2. That we make Semigroup a superclass of Monoid, so that (minimally): class Semigroup a where (<>) :: a -> a -> a class Semigroup a => Monoid a where mempty :: a mconcat :: [a] -> a mconcat = foldr (<>) mempty mappend :: Semigroup a => a -> a -> a mappend = (<>) 3. (Optional, recommended) There are other useful functions that can be added to Semigroup, such as sconcat and times1p, but I will let Edward speak to whether those should be proposed at this time. 4. (Optional, recommended) That we fix the Monoid instance for Maybe to be: instance Semigroup a => Semigroup (Maybe a) where Just x <> Just y = Just (x <> y) _ <> _ = Nothing instance Semigroup a => Monoid (Maybe a) where mempty = Nothing For some clarification on what semigroups are and why we'd want to change Monoid, I excerpt here a selection from Brent Yorgey's "Monoids and Variations" paper: Semigroups A semigroup is like a monoid without the requirement of an identity element: it consists simply of a set with an associative binary operation.... Of course, any monoid is automatically a semigroup (by forgetting about its identity element). In the other direction, to turn a semigroup into a monoid, simply add a new distinguished element to serve as the identity, and extend the definition of the binary operation appropriately. This creates an identity element by definition, and it is not hard to see that it preserves associativity.... Adding a new distinguished element to a type is typically accomplished by wrapping it in Maybe. One might therefore expect to turn an instance of Semigroup into an instance of Monoid by wrapping it in Maybe. Sadly, Data.Monoid does not define semigroups, and has a Monoid instance for Maybe which requires a Monoid constraint on its argument type... This is somewhat odd: in essence, it ignores the identity element of [the type] and replaces it with a different one. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

9 9

Wither Haskell Platform 2013.4.0.0
by Mark Lentczner 27 Oct '13

27 Oct '13

Friends — Deep apologies for being so out of touch the last two months(*). In theory, we should be rev'ing up to produce Haskell Platform 2013.4.0.0, but I'd like to explore our options at this time: *1) Proceed as normal:* Such a release would use GHC 7.6.3, as did HP 2013.2.0.0, since that is still the current GHC release. Hence all the core library versions would remain the same, and by my rough eyeballing it, half the platform libraries would remain the same. The only big change might be OpenGL/GLUT libs, which has bumped a major version... though I don't know if that API change is too great or not. Given the time frame, we are unlikely to have any additional packages. This stance brings up the issue that 7.6.3, out of the box, won't work with Xcode 5, and hence the upcoming release of OS X Mavericks (10.9). *2) Delay a month:* This would give us time to consider new packages, which would make the release somewhat more valuable. However, a December release is hard due to holidays, so likelihood would be late December, or January release. *3) Ask GHC Central to produce 7.6.4:* This would incorporate the changes needed work with Xcode 5. This would clearly involve a month delay as in #2. *4) Skip it:* We could just decide that 2013.4.0.0 doesn't offer enough value to run the process now, and simply focus our efforts this cycle on improving the infrastructure that builds HP. Thoughts? I'm particularly interested to hear from HP library maintainers to know if there was/is something important to get out in an HP ASAP. I'd also like to better understand what our Xcode5 options are, and if/how/when we could see the latest cabal in the platform. Again, sorry that this small HP timing crisis is mostly my fault, — Mark (*) At least my excuse is that I was writing music with Haskell for those two months!

15 26

type-level definitions naming
by Richard Eisenberg 23 Oct '13

23 Oct '13

I've made the changes that I see fit, regarding http://ghc.haskell.org/trac/ghc/wiki/TypeLevelNamingIssues As I wanted a little feedback before pushing, the changes are at my fork of the base repo, at https://github.com/goldfirere/packages-base Here is what I've done: - The function with type (a :~: b) -> a -> b is now named castWith. - There is a new function (in Data.Type.Equality) gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r. Type inference for this function works well. - I've renamed EqualityT and CoercionT to EqualityType and CoercionType. The T's at the ends of the old names made me think of monad transformers. I don't like the new names, though. - EqualityType's method is now maybeEquality (instead of equalsT). CoercionType's method is now maybeCoercion (instead of coercionT). - I've added (==) as type-level Boolean equality to Data.Type.Equality. Instead of the fully-general poly-kinded definition, my experience has shown that a recursive definition of Boolean equality over algebraic types is superior to the general poly-kinded one. So, (==) is an open type family, with many closed type family specializations over certain types (including * and (k1 -> k2), as well as promoted versions of the base datatypes). - An earlier version of TypeLits had Nat1 as a canonical unary natural number type and conversions to and from. I expect this will be a popular addition, so I restored it. I also added instances of Eq, Ord, Data, Typeable, Read, Show, Num, Integral, Real, Enum, and Ix, in case someone wants to use Nat1 at the term level. Questions for you all: - Better name ideas for EqualityType/maybeEquality and CoercionType/maybeCoercion? I'm very unsatisfied. - OK to add (==)? There is a naming tension with the (<=) and (<=?) operators in TypeLits. Following the convention of appending ? for Boolean operators, (==) should be spelled (~?). But, I don't like that terribly much, for aesthetic more than practical reasons. Please disagree with me or suggest a more unified structure. (Maybe the constraint (<=) should really be (<~)... but I think that's *very* confusing, as it looks like an arrow!) - OK to add Nat1? Comments on the instances? Thanks, Richard

4 9

GHC HEAD vs Hackage, panic-free edition
by bos 18 Oct '13

18 Oct '13

Thanks to the efforts of the Simons, we now have a GHC that does not panic on any package that it's able to try compiling. Since the last report, the number of packages on Hackage has increased by 1.8%, from 5564 to 5604, but the number of failing builds has dropped by 4.2%, from 1186 to 1136. This is partly due to a few widely-used packages (e.g. test-framework) being updated to build with HEAD. Here are the top 20 packages that caused a build failure in a package that depended upon them, with the count of the number of failed builds next to each. I have highlighted in *red+bold* package versions that are out of date, typically where the depending-upon package simply has upper bounds on its dependencies that are too strict. For packages that are listed in blue, the versions that are breaking are the latest available. I've CCed the authors of said packages on this email. Folks, please fix your stuff! 60 *network-**2.4.0.*0 63 *primitive-0.4.1* 65 Tensor-1.0.0.1 (Typeable problems) 74 *array-0.3.0.3* 98 *convertible-1.0.11.1* 99 MissingH-1.2.0.2 (broken by a change to unix package) 102 yesod-core-1.2.4.4 (http://lpaste.net/94162) 104 *HTTP-4000.0.7* 121 *mtl-1.1.1.1* 126 process-1.1.0.2 (unsafePerformIO) 138 glib-0.12.4 (Setup.hs broken by recent Cabal changes) 166 MonadCatchIO-mtl-0.3.0.5 (exception problems) 207 MonadCatchIO-transformers-0.3.0.0 (exception problems) 231 *containers-0.4.2.1* 231 OpenGLRaw-1.4.0.0 (a problem with my system, ignore) 242 enumerator-0.4.19 (already pinged jmillikin) 403 *transformers-0.2.2.0* 410 cairo-0.12.4 (Setup.hs broken by recent Cabal changes) 499 *template-haskell-2.8.0.0* 868 *unix-2.3.2.0*

9 9

Free monads
by Andres Löh 17 Oct '13

17 Oct '13

Hi everyone. I'll follow Simon's lead, and ask a similar question with a similar motivation. I'm going to talk about free monads at the upcoming Haskell eXchange next Wednesday. I'll not limit myself to a particular library, and I'm open to related approaches (e.g. "operational") as well. I'm also looking for as many compelling examples as possible. Like Simon, I don't want to know anything secret or anything that you wouldn't like me to include in my talk. Most useful are pointers to existing libraries using free monads that I might have missed (for example, because they're new or very specialized). Thanks a lot for your help in advance. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

11 13

Proposal: GHC.Generics marked UNSAFE for SafeHaskell
by Ryan Newton 16 Oct '13

16 Oct '13

Hi all, We had a discussion on haskell-cafe, which only confirmed the unreliability of "Eq" and "Ord". Fine. But if I instead want to define a SafeEq class and instances based on GHC.Generics, then I can't have users writing Generic instances that lie about the structure of their types. But as you can see this module is currently marked "Trustworthy": http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-G… I simply propose that this is changed to "Unsafe"! [1] *Context:* The bottom line is that I believe in the Safe-Haskell mission here, and I want to be able to deliver practical libraries that give a strong guarantee that types can't be broken. Currently, the LVish<http://www.cs.indiana.edu/~rrnewton/papers/2013_07_LVish_quasiDet_working_d…>library has one big hole in it because of this Eq/Ord limitation; the problem is documented here<http://www.cs.indiana.edu/~rrnewton/haddock/lvish/Control-LVish.html#g:1> . If we can provide incontrovertible Safe-Haskel guarantees, this is a huge, qualitative difference compared to what's possible in the C++, Java's and MLs of the world. There are plenty of libraries that provide guarantees like "deterministic parallelism" IFF the user does everything right and breaks no rules (CnC, Pochoir, etc). But we can do better! Best, -Ryan [1] Small detail... some of these bindings, like the class name "Generic" itself, will still need to be accessible from a Trustworthy library. I propose GHC.Generics.Safe for that, following existing precedent. On Sun, Oct 6, 2013 at 5:18 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: > Thanks for the responses all. > > I'm afraid the point about GHC.Generics got lost here. I'll respond and > then rename this as a specific library proposal. > > I don't want to fix the world's Eq instances, but I am ok with requiring > that people "derive Generic" for any data they want to put in an LVar > container. (From which I can give them a SafeEq instance.) > > It's not just LVish that is in this boat.... any library that tries to > provide deterministic parallelism outside of the IO monad has some very > fine lines to walk. Take a look at Accelerate. It is deterministic (as > long as you run only with the CUDA backend and only on one specific GPU... > otherwise fold topologies may look different and non-associative folds may > leak). Besides, "runAcc" does a huge amount of implicit IO (writing to > disk, calling nvcc, etc)! At the very least this could fail if the disk if > full. But then again, regular "pure" computations fail when memory runs > out... so I'm ok grouping these in the same bucket for now. "Determinism > modulo available resources." > > A possible problem with marking "instance Eq" as an unsafe feature is that >> many modules would be only Trustworthy instead of Safe. >> > > My proposal is actually more narrow than that. My proposal is to mark > GHC.Generics as Unsafe. > > That way I can define my own SafeEq, and know that someone can't break it > by making a Generic instance that lies. It is very hard for me to see why > people should be able to make their own Generic instances (that might lie > about the structure of the type), in Safe-Haskell. > >> >> That would go against my "every purely functional module is automatically >> safe because the compiler checks that it cannot launch the missiles" >> understanding of Safe Haskell. >> > > Heh, that may already be violated by the fact that you can't use other > extensions like OverlappingInstances, or provide your own Typeable > instances. > > >> >> Actually, Eq instances are not unsafe per se, but only if I also use some >> other module that assumes certain properties about all Eq instances in >> scope. So in order to check safety, two independent modules (the provider >> and the consumer of the Eq instance) would have to cooperate. > > > I've found, that this is a very common problem that we have when trying to > make our libraries Safe-Haskell compliant -- often we want to permit and > deny combinations of modules. I don't have a solution I'm afraid. > > >

12 34

Module reexports at the package level
by Joachim Breitner 15 Oct '13

15 Oct '13

Hi, not sure if this is the right mailing list, as it affects GHC and Cabal, but can be used by all library authors. But it is a close fit. I’d like to propose Module re-reports on the package level, in order to make package reorganization easier on the users. For details, please see http://ghc.haskell.org/trac/ghc/wiki/ModuleReexports and for discussion, I suggest to use the trac ticket http://ghc.haskell.org/trac/ghc/ticket/8407 Questions are: * Is this useful enough? * Is the design (syntax and semantics) good? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 9

Proposal: Add common instances for Control.Applicative.Const
by Eric Mertens 15 Oct '13

15 Oct '13

Hello, It would be handy for Control.Applicative.Const to have the various derivable instances (Eq, Ord, Read, Show). In particular Read and Show would make debugging easier. -- Eric Mertens

4 6