October 2013 - Libraries

TypeLits
by Richard Eisenberg 09 Oct '13

09 Oct '13

Hi Iavor, It was very nice to see you last week -- it's too bad we have to wait another year for another ICFP! :) A question I got asked between sessions at ICFP led me to look at singletons again, and it seems that singletons has gone out of sync with TypeLits. When I looked closely at TypeLits, I saw a number of changes there, and I wonder if we can think a bit about the design before 7.8 rolls out. Forgive me if some of these suggestions are not new -- I just haven't looked closely at TypeLits for some time. Specifically: - I see that you define singleton instances for Bool. This makes sense, if we are to avoid orphan instances of the various singletons classes. But, it would seem helpful to define singleton support for more than just Bool here, if we are going down this road. For example, singletons for [], Maybe, Either, and the tuples are quite useful. - You don't export the constructors for Sing (k :: Bool). I think these need to be publicly visible. - I believe that Edward's reflection package will be incorporated into base. (Edward?) If so, it's possible that incoherentForgetSing can be cleaned up somewhat. - Why use LocalProxy? What's wrong with plain old Proxy? - I see Show and Read instances defined for singletons. Though these are useful, they prevent clients from defining their own instances, and I can imagine a user (possibly me) wanting a singleton to have a distinct Show instance from its base type. Perhaps these should be moved to a different module which can selectively be imported? - The definition for (:~:) is redundant with the new Data.Type.Equality. - The eqSing... functions are now redundant with the EqualityT class in Data.Type.Equality. Instead, TypeLits should probably define instances for EqualityT. - TypeLits defines KindIs, which is redundant with Data.Proxy's KProxy. It might be that KindIs is easier to use than KProxy, but base probably shouldn't have both types floating around. - I'm confused about IsZero. How is it different (in practical usage situations) from eqSingNat? Also, I'd like to note that IsZero uses a unary representation, which might be problematic. - The definitions for Nat1 don't need to be in base. Perhaps we want them there -- I think it will get a lot of use -- but maybe we should just think about it for a moment before going forward. I should admit that the redundancies are new -- after some discussion in the spring, I finally implemented the new bits that are now redundant with TypeLits only a month or two ago. --- Now having posed these questions, here are my proposed answers: - To avoid orphans, TypeLits should define singleton instances for all the types above, with all constructors exported. - Remove redundancy with other parts of base. I personally prefer KProxy over KindIs, because I find the KindIs name confusing. - Remove Show instances for singletons from base. If someone thinks these will have wide use, they can be defined in a library. - Keep Nat1 right where it is. Thoughts, anyone? Thanks, Richard

5 10

I've forked test-framework
by Bryan O'Sullivan 08 Oct '13

08 Oct '13

It doesn't build with GHC 7.8, and Max hasn't responded to pull requests or repeated comments from multiple people over a span of several weeks. https://github.com/haskell/test-framework

1 0

Proposal: Partitionable goes somewhere + containers instances
by Ryan Newton 07 Oct '13

07 Oct '13

<subject change> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki <mike(a)izbicki.me> wrote: > I've got a Partitionable class that I've been using for this purpose: > > https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/Cons… > Mike -- Neat, that's a cool library! Edward -- ideally, where in the standard libraries should the Partitionable comonoid go? Btw, I'm not sure what the ideal return type for comappend is, given that it needs to be able to "bottom out". Mike, our partition function's list return type seems more reasonable. Or maybe something simple would be this: *class Partitionable t where* * partition :: t -> Maybe (t,t)* That is, at some point its not worth splitting and returns Nothing, and you'd better be able to deal with the 't' directly. So what I really want is for the *containers package to please get some kind of Partitionable instances! * Johan & others, I would be happy to provide a patch if the class can be agreed on. This is important because currently the balanced tree structure of Data.Set/Map is an *amazing and beneficial property* that is *not* exposed at all through the API. For example, it would be great to have a parallel traverse_ for Maps and Sets in the Par monad. The particular impetus is that our new and enhanced Par monad makes extensive use of Maps and Sets, both the pure, balanced ones, and lockfree/inplace ones based on concurrent skip lists: http://www.cs.indiana.edu/~rrnewton/haddock/lvish/ Alternatively, it would be ok if there were a "Data.Map.Internal" module that exposed the Bin/Tip, but I assume people would rather have a clean Partitionable instance... Best, -Ryan On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki <mike(a)izbicki.me> wrote: > I've got a Partitionable class that I've been using for this purpose: > > > https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/Cons… > > The function called "parallel" in the HLearn library will automatically > parallelize any homomorphism from a Partionable to a Monoid. I > specifically use that to parallelize machine learning algorithms. > > I have two thoughts for better abstractions: > > 1) This Partitionable class is essentially a comonoid. By reversing the > arrows of mappend, we get: > > comappend :: a -> (a,a) > > By itself, this works well if the number of processors you have is a power > of two, but it needs some more fanciness to get things balanced properly > for other numbers of processors. I bet there's another algebraic structure > that would capture these other cases, but I'm not sure what it is. > > 2) I'm working with parallelizing tree structures right now (kd-trees, > cover trees, oct-trees, etc.). The real problem is not splitting the > number of data points equally (this is easy), but splitting the amount of > work equally. Some points take longer to process than others, and this > cannot be determined in advance. Therefore, an equal split of the data > points can result in one processor getting 25% of the work load, and the > second processor getting 75%. Some sort of lazy Partitionable class that > was aware of processor loads and didn't split data points until they were > needed would be ideal for this scenario. > > On Sat, Sep 28, 2013 at 6:46 PM, adam vogt <vogt.adam(a)gmail.com> wrote: > >> On Sat, Sep 28, 2013 at 1:09 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: >> > Hi all, >> > >> > We all know and love Data.Foldable and are familiar with left folds and >> > right folds. But what you want in a parallel program is a balanced fold >> > over a tree. Fortunately, many of our datatypes (Sets, Maps) actually >> ARE >> > balanced trees. Hmm, but how do we expose that? >> >> Hi Ryan, >> >> At least for Data.Map, the Foldable instance seems to have a >> reasonably balanced fold called fold (or foldMap): >> >> > fold t = go t >> > where go (Bin _ _ v l r) = go l `mappend` (v `mappend` go r) >> >> This doesn't seem to be guaranteed though. For example ghc's derived >> instance writes the foldr only, so fold would be right-associated for >> a: >> >> > data T a = B (T a) (T a) | L a deriving (Foldable) >> >> Regards, >> Adam >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >

8 17

Operator priorities in GHC.TypeLits
by Krzysztof Gogolewski 06 Oct '13

06 Oct '13

Hello, GHC.TypeLits currently has no operator priorities; 2 + 2 * 2 is parsed as (2 + 2) * 2. Is it OK to add priorities as in http://lpaste.net/93745? This seems to work but I'm bit surprised it was not done before. The priorities are the same as for operators in Prelude. Unfortunately, this does not handle ~, which still needs brackets in 2 ~ (1+1); I don't know what to do about it. K.

2 1

findExecutable - Alternate Implementation Proposal (#2184)
by Muhaimin Ahsan 03 Oct '13

03 Oct '13

http://ghc.haskell.org/trac/ghc/ticket/2184 Since no one has objected to this proposal in the last email I sent out mentioning this, I think it should be merged in for 7.8. Muhaimin

1 0

Using lenses
by Simon Peyton-Jones 03 Oct '13

03 Oct '13

Friends Some of you will know that I've promised to give a talk about Edward's lens library<http://hackage.haskell.org/package/lens> at the Haskell Exchange<http://skillsmatter.com/event/scala/haskell-exchange> in London next Wednesday (9th). I did this to give everyone (including me) a break from GHC hackery, and also to force me to learn about this lens voodoo that everyone is twittering about. Edward generously gave me quite a bit of one-to-one attention last week (my hair is still standing on end), but this message is to ask your help too. Specifically, I'd like to give some compelling use-cases. If you are using the lens library yourself, could you spare a few minutes to tell me how you are using it? I expect to cover Lens and Traversal but not Prism. The use-case everyone starts with is nested records, but I'd like to go beyond that. The next levels seem to be: * Lenses as views of data that isn't "really there" e.g. regarding a record with rectangular coordinates as having polar coordinates too. * Lenses and Traversals that focus on elements of finite maps (Control.Lens.At) What else? I'm sure you are using them in all sorts of cool ways that I would never think of, and I'd love to know. Please don't tell me anything secret! And don't burn too many cycles on this...I don't want to waste your time, and I can always get back to you if I can't understand what you say. Sooner is better than later...Weds is coming. Simon "Edward's prophet" PJ

5 4

Re: Using lenses
by Niklas Haas 03 Oct '13

03 Oct '13

I use lenses for almost all of my code, now, in particular the ‘lens’ library due to the tons of syntactic conveniences it provides. The main thing I tend to use ‘lens’ for is actually folds (or traversals), not lenses themselves. I like to construct big folds, restrict them with filters or prisms, take them apart with stuff like ‘splittingOn’ or ‘chunking’, glue them together with combining functions like ‘failing’ or ‘mappend’, and finally read them out with things like ‘preview’, ‘foldrOf’, ‘has’ or ‘elemOf’. My other big use case for lenses is combining them with StateT to write pretty darn imperative-looking code, which is the ‘records’ or ‘lenses’ approach most people are probably more familiar with.

1 0

Using lenses
by Greg Weber 03 Oct '13

03 Oct '13

I use lens (makeFields) to almost solve the record namespacing issue. Constructing a new record still requires long form, but for retrieval or update I can use short form.

1 0

Haskell Platform Proposal: add the 'aeson' library
by Bas van Dijk 02 Oct '13

02 Oct '13

Hello, I would like to propose adding the 'aeson' library to the next Haskell Platform which is scheduled for November. The detailed proposal is kept at: http://trac.haskell.org/haskell-platform/wiki/Proposals/aeson Discussion deadline: October 7th, 2013 Regards, Bas

17 20

OT: Symbolic type variables (was Re: [Proposal] Renaming (:=:) to (==))
by Erik Hesselink 01 Oct '13

01 Oct '13

On Mon, Sep 30, 2013 at 8:25 PM, Conal Elliott <conal(a)conal.net> wrote: > I'm hoping we don't get more deeply invested in the syntactic change in GHC > 7.6 that removed the possibility of symbolic type variables ("~>", "*", "+", > etc). I had a new job and wasn't paying attention when SPJ polled the > community. From my perspective, the loss has much greater scope than the > gain for type level naturals. I'd like to keep the door open to the > possibility of bringing back the old notation with the help of a language > pragma. It would take a few of us to draft a proposal addressing details. I also miss these on a regular basis. I seem to remember that during the proposal, there was a mention of reversing the situation, i.e. having a prefix for type variable operators instead. Did anything ever come of that? Erik

2 1