- Libraries - Haskell.org

(no subject)
by Gabriel Gonzalez 14 Aug '13

14 Aug '13

> My preference is to call the new transformer ExceptT, with a basic monad called Except, in line with most of the other transformers, and to deprecate ErrorT. (The rationale for the name is that Either isn't just for exceptions, and exceptions aren't just for errors.) Specializing to an identity base monad is usually a misfeature in real code and only useful for pedagogical purposes. Experts leave it polymorphic like this: expertCode :: (Monad m) => EitherT E m R By designing the API entirely around the identity specialization you're optimizing for a narrow skill range of intermediate Haskell programmers who are: a) Smart enough to figure out that `ExceptT` is the official generalization of `EitherT` b) Not smart enough to figure out how to keep the base monad polymorphic So I propose that you leave the monad transformer name as `EitherT`, but use `Except` for the `Identity` specialization: type Except e r = EitherT e Identity r This has the nice properties that: * The identity specialization doesn't conflict with `Either` * Beginners find `transformers` when they search for `EitherT` as they inevitably will * Existing packages that use `EitherT` won't break, thus preserving compatibility with the code bases that Edwards already mentioned

4 5

Void type in base
by Shachaf Ben-Kiki 13 Aug '13

13 Aug '13

It seems strange that there's a canonical unit type -- () -- which is used extensively, but no canonical type for its dual, the uninhabited type. The closest we have is in Edward Kmett's void package, but several people seem to prefer to write it themselves rather than incur an extra dependency, which is a shame. The proposal is just to copy the Data.Void API into base: data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception (void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.) void could then re-export Data.Void so packages that depend on it will keep working. ("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.) hashable and semigroups would also need to be updated to add their respective instances as non-orphans. The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`. Discussion period: 2 weeks. Shachaf

11 17

Workflow for maintaining Haskell platform packages
by Sven Panne 12 Aug '13

12 Aug '13

Currently I'm trying to pick up my work on the OpenGL-related packages again, and while doing that, I came across some organizational difficulties: The GLUT/OpenGL/OpenGLRaw/GLURaw packages are now part of the Haskell platform (thanks to Jason and others, this is really great!), and they depend on each other, e.g. GLUT => OpenGL => OpenGLRaw. So my question is: What is the recommended workflow to easily maintain/extend packages contained in the Haskell platform? I want to be able to quickly go back to the distributed package versions, OTOH I want to relatively quickly try out new things, extend APIs, etc. for the upcoming new versions of those packages. Any hints how to do that are highly appreciated. Cheers, S.

4 9

Re: leftToMaybe/rightToMaybe
by wren ng thornton 11 Aug '13

11 Aug '13

On 8/9/13 2:52 AM, Andreas Abel wrote: > I bet that most imports of Control.Arrow are to make up for an > impoverished Data.Tuple, and proper arrow programming is the exception. I, for one, exclusively use the main arrow combinators[1] at (->) for the purpose of manipulating co/products in the obvious categorical way. The only time I'd use any other instance of Arrow/ArrowChoice is if that's the API some library gives me. I'd certainly never define my own instances because the Arrow class is IMO fundamentally broken. The presence of the arr method requires that *all* Haskell functions can be embedded into your category, which makes Arrows unsuitable for any of the subcategories or DSLs I happen to care about. I know there are some folks who are really attached to Arrows, but I'd much rather see Arrow/ArrowChoice abandoned in favor of extending Category to have subclasses for categories with co/products. [1] first, second, (&&&), (***), left, right, (|||), (+++) -- Live well, ~wren

2 1

Proposal: Add isFullTBQueue to Control.Concurrent.STM.TBQueue
by Merijn Verstraaten 11 Aug '13

11 Aug '13

As the subject implies, I would like to add "isFullTBQueue" to Control.Concurrent.STM.TBQueue with the obvious semantics. I don't think there's much to discuss/object, so let's say 1 week time for discussion/objections. Cheers, Merijn

2 1

leftToMaybe/rightToMaybe
by Christopher Done 09 Aug '13

09 Aug '13

How about popping these in Data.Either? -- | Maybe get the left side of an Either. leftToMaybe :: Either a b -> Maybe a leftToMaybe = either Just (const Nothing) -- | Maybe get the right side of an Either. rightToMaybe :: Either a b -> Maybe b rightToMaybe = either (const Nothing) Just

17 28

Re: Improving void
by wren ng thornton 07 Aug '13

07 Aug '13

On 8/5/13 3:06 PM, Edward Kmett wrote: > Right now the definition of Control.Monad.void is: > > void :: Functor f => f a -> f () > > void = fmap (const ()) > > I propose we replace it with > > void :: Functor f => f a -> f () > > void = (() <$) > > This expands out to the former definition by the default definition of > (<$) and Data.Functor.Functor exports (<$) explicitly to make it > possible to optimize this sort of thing. It seems a shame not to use > it. +1. That was the entire point of (<$) being added to the class afterall. -- Live well, ~wren

2 1

Improving void
by Edward Kmett 06 Aug '13

06 Aug '13

Right now the definition of Control.Monad.void is: void :: Functor f => f a -> f () void = fmap (const ()) I propose we replace it with void :: Functor f => f a -> f () void = (() <$) This expands out to the former definition by the default definition of (<$) and Data.Functor.Functor exports (<$) explicitly to make it possible to optimize this sort of thing. It seems a shame not to use it. Discussion Period: 2 weeks

7 8

cabal log and cleanup questions
by harry 03 Aug '13

03 Aug '13

I've noticed that cabal install seems to create two copies of the logs- one defined by build-summary in the config file, and another in the packages directory (build-reports.log). Can I stop it creating this second log? There's a log-dir option in the config file, but it doesn't seem to do anything. I'm also looking for a simple command to delete all of the downloaded packages, but not the database (so I won't have to cabal update again.) I'm not even sure which files this would have to keep - I'm guessing 00-index.tar and perhaps 00-index.cache? -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-log-and-cleanup-questions-tp5733… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

1 0

Proposal: Add Monad instance for WrappedMonad
by Daniel Gorín 03 Aug '13

03 Aug '13

Control.Applicative.WrappedMonad allows one to use the Functor and Applicative interfaces of something that is only known to be a Monad but, oddly enough, it hides its Monad interface. The proposal is to add the missing Monad instance. A typical use case for this instance would be: f :: Failure String m => T1 -> m T2 f = unwrapMonad . f' where f' x = do ... -- one can also use (<$>), (<*>), etc here (NB. the Failure class is a subclass of Monad only). A related proposal for the transformers package would be to add a MonadTrans instance for WrappedMonad as well. Thanks, Daniel

4 3