- Libraries - Haskell.org

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 02 Oct '13

02 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

[Proposal] add view function for NPlusKPatterns
by Stijn van Drongelen 30 Sep '13

30 Sep '13

Hello, I'm working on a desugaring library for Haskell. Desugaring NPlusKPatterns currently takes up the most code, since a proper translation involves generating two guards. Meanwhile, most other pattern-related language extensions are defined in terms of ViewPatterns, which are trivial to desugar. In my laziness to fix this otherwise, I propose that the following function is added to the Prelude: > maySubtractIntegral :: Integral a => a -> a -> Maybe a > maySubtractIntegral k nplusk = if n >= 0 then Just n else Nothing > where > n = nplusk - k So that `NPlusKPatterns` like < func (n+42) = expr may be desugared to < func (maySubtractIntegral 42 -> Just n) = expr rather than < func nplusk | n <- nplusk - 42, n >= 0 = expr The name of this function is, of course, subject to bikeshedding. Note that the signature is correct; though (Ord a, Num a) is more general, it's too weak for the semantics of the language extension. Discussion period: 2 weeks

3 3

Missing Traversable instances
by hsyl20 . 29 Sep '13

29 Sep '13

Hi, I would like to use a Traversable instance for "Either e". I have read it is a recurrent demand [1][2] to integrate it in base. Could we do it for the next release? Thanks Sylvain [1] http://haskell.1045720.n5.nabble.com/Proposal-Add-the-missing-instances-for… [2] http://osdir.com/ml/libraries@haskell.org/2011-01/msg00325.html

3 3

cabal-install error messages
by Harry Garrood 27 Sep '13

27 Sep '13

I recently was trying to `cabal install` (with a sandbox) a package I'd made, which depends on scotty-0.5.0. Cabal-install was giving me this message: $ cabal install Resolving dependencies... cabal: Could not resolve dependencies: trying: multicopter-0.0.1 (user goal) next goal: scotty (dependency of multicopter-0.0.1) rejecting: scotty-0.4.6, 0.4.5, 0.4.4, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.0, 0.2.0, 0.1.0, 0.0.1 (conflict: multicopter => scotty>=0.5.0) Dependency tree exhaustively searched. Note: when using a sandbox, all packages are required to have consistent dependencies. Try reinstalling/unregistering the offending packages or recreating the sandbox. My first assumption was that scotty, and some other package that my package depend on, both want different versions of a third package. I tried removing everything else from the build-depends field, but I got the same message. Then I did a `cabal update` which appears to have fixed it. My question is: Should cabal-install, in this situation, say something like "I'm not aware of a version 0.5.0 for the 'scotty' package. Try `cabal update`" instead?

1 0