August 2013 - Libraries

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

Re: new-typeable, new cast?
by José Pedro Magalhães 01 Aug '13

01 Aug '13

Hi, On Mon, Mar 4, 2013 at 4:51 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > Unless I'm missing something, this all looks very straightforward. The > implementation is there, already, in the guise of (gcast Refl). We would > just shuffle the definitions around a bit. Am I indeed missing something? > I think that is the case indeed. Though I agree that it would be a nice addition to Data.Typeable. Cheers, Pedro > > As for the name, I agree that :~: is awkward to type. But, I think == > should be saved for type-level Boolean equality, as a closer analogue to > its term-level meaning. I don't have a better suggestion than :~:. Or, if > we just allow Constraint/* polymorphism, than we can simply use ~, as that > *already* is a GADT wrapping around an even more primitive denotation of > equality. (Just kidding about the Constraint/* polymorphism…) > > Richard > > On Mar 4, 2013, at 10:30 AM, Simon Peyton-Jones wrote: > > > ok good. Since this is in the intersection of singletons and Typeable, I > wonder if Pedro and Richard might together lead on driving this to a > conclusion and implementing it? > > > > Simon > > > > | -----Original Message----- > > | From: Stephanie Weirich [mailto:sweirich@cis.upenn.edu] > > | Sent: 04 March 2013 14:24 > > | To: Shachaf Ben-Kiki > > | Cc: Simon Peyton-Jones; libraries(a)haskell.org; Richard Eisenberg > > | (eir(a)cis.upenn.edu) Dimitrios Vytiniotis; Iavor Diatchki; Conor > > | McBride; Pedro Magalhães > > | Subject: Re: new-typeable, new cast? > > | > > | Nice! I agree that having a (poly-kinded!) function of type > > | > > | >> eqT :: forall (a :: k) (b :: k). (Typeable a, Typeable b) => Maybe > (a > > | >> :~: b) > > | > > | around is The Right Way to Go. I'd call this function "eqT" or > > | "eqTypeable", after the similar operation in Data.Type.Equality. Thanks > > | for pointing out that we can get such a function so easily from gcast. > > | (Note that gcast itself can be polykinded now, I'm writing down the > > | kinds to make them obvious.) > > | > > | gcast :: forall (a :: k) (b::k) (c::k ->*). (Typeable a, Typeable b) -> > > | c a -> Maybe (c b) > > | > > | WRT to gcast1 and gcast2, these functions can be subsumed by eqT, but > > | not by polykinded gcast due to the restrictions on higher-order > > | polymorphism. > > | > > | gcast1 can convert [b Int] to [Maybe Int], but gcast cannot. eqT can do > > | so with a pattern match. This behavior does seem rather special-purpose > > | though---eqT is much more flexible. > > | > > | With singletons, we could imagine two different polykinded operations, > > | that differ only in whether their arguments are explicit/implicit. > > | > > | eqTypeable :: (Typeable a, Typeable b) => Maybe (a :~: b) > > | > > | eqSing :: Sing a -> Sing b -> Maybe (a :~: b) > > | > > | Again, Sing should be kind-indexed, so that we can have Sing True, Sing > > | 0, and (eventually) Sing Int. > > | > > | --Stephanie > > | > > | > > | On Mar 4, 2013, at 8:46 AM, Shachaf Ben-Kiki wrote: > > | > > | > On Mon, Mar 4, 2013 at 4:24 AM, Simon Peyton-Jones > > | > <simonpj(a)microsoft.com> wrote: > > | >> | λ> data a :~: b where Refl :: a :~: a > > | >> | λ> :t gcast Refl > > | >> | gcast Refl :: forall a b. (Typeable a, Typeable b) => Maybe > > | >> | ((:~:) * a b) > > | >> > > | >> That is a ferociously-unintuitive use of 'gcast'! It too me dome > > | while to convince myself that it was right. Though it does indeed > > | work. I'd see (gcast Refl) as the primitive, with 'gcast' itself as a > > | simple derived function. > > | >> > > | >> I'm not sure what name to give the new cast function > > | >> ?? :: Typeable a, Typeable b) => Maybe (a :~: b) > > | >> > > | >> > > | >> Do we need gcast1 and gcast2 any more, in our new polykinded world? > > | Can they be depreceated? > > | >> > > | >> Simon > > | >> > > | > > > | > A couple of people have suggested "same". (I wonder if this would > also > > | > subsume eqSingNat/eqSingSym?). > > | > > > | > By the way -- since (:~:) seems to be in HEAD now, but not yet > > | > released, is there a chance of renaming it? ":~:" is pretty awkward > to > > | > type, given all the new TypeOperators options these days; how about > > | > "=="? > > | > > > | > Shachaf > > | > > > > > > >

7 17