September 2013 - Haskell-Cafe

Re: [Haskell-cafe] Proposal: new function for lifting
by Nick Vanderweit 27 Sep '13

27 Sep '13

Sorry for sending this twice; I didn't reply to the list initially. I thought people [1] were generally talking about lift from Control.Monad.Trans: class MonadTrans t where lift :: Monad m => m a -> t m a The idea being that lifting through a monad stack feels tedious. The proposed solution is to use instances to do the lifting for you, like in mtl. So we've got instances like: MonadState s m => MonadState s (ReaderT r m) Which let you automatically lift get/put/modify up a stack, without doing any work. This is different from liftM*, which are about applying a pure function to monadic arguments. This can be done quite nicely with (<$>) and (<*>) from Data.Functor and Control.Applicative, respectively. Your first example can be written: (+) <$> (Just 42) <*> Nothing Nick [1] http://blog.ezyang.com/2013/09/if-youre-using-lift-youre-doing-it-wrong-pro…

1 0

Non-termination using Free Monads and Data Types a la Carte
by Alexander Solla 27 Sep '13

27 Sep '13

I am trying to use a data types a la carte approach to define a free monad for templating purposes. I am using Edward Kmett's free package, and a module implementing data types a la carte's injections, modelled on the IOSpec Types module. I have written a few combinators, but I am stuck. My program keeps diverging, and I don't see why. Consider: math :: Math :<: f => MathExpr a -> Free f () blank :: f :<: (Textual :+: Math) => Free f () -> Free (Blank k f) () equals :: Free (Math :+: (Blank L Math)) () -> Free (Math :+: (Blank R Math)) () -> Free Equation () The intention is that a blank takes in a properly typed abstract syntax tree and tags it with "blank k", so that the parsers/renderers do the "right thing" (when I get around to implementing them) The composition (blank . math) has the type: blank . math :: ( f :<: (Textual :+: Math) , Math :<: f ) => MathExpr a -> Free (Blank k f) () Notice that f must be simultaneously less than or equal to the join of Textual and Math, and greater than or equal to Math. So the only possibility for f is Math. (I realize the compiler can't infer this without more work on my part) The problem happens when I try to evaluate (using scoped type signatures to get around my comment above): test :: Free Equation () test = (hoistFree (inj :: Blank 'L Math a -> (Math :+: Blank 'L Math) a) . blank . (math :: MathExpr x -> Free Math ()) $ "hi" ) `equals` (math $ "world") which apparently loops, pegging my CPU at 100%. The computation prints its result as: Free (Equation (Free (DirectSum {unDirectSum = Right at which point the value is truncated and GHCi quits. So it apparently gets as far as figuring out that the first argument to equals is in the latter part of the direct sum, but it doesn't seem t be able to compute blank. Relatively minimal source is available at: monad: http://lpaste.net/93471 data types a la carte: http://lpaste.net/93472 All my functions are total and I don't see a bottom here, but I was never any good at fixed point combinators. Any ideas?

1 0

[ANNOUNCE] cereal-0.4.0.0
by Trevor Elliott 27 Sep '13

27 Sep '13

Hi Everyone, I'm happy to announce the newest release of the cereal[1] binary serialization library. This includes a number of bug fixes, as well as instances of Serialize for the newtypes defined in Data.Monoid. Happy hacking! --trevor [1] http://hackage.haskell.org/package/cereal-0.4.0.0

1 0

Proposal: RankedInstances
by Wvv 26 Sep '13

26 Sep '13

The main power of Haskell is on instances. But Haskell instances system work fine with lower number of instances (rare instances). But we want hight density of instances! If we wish to have more selective instances we use `OverlappingInstances` (which are desined in a poor way) and if we still have too many instances we use `IncoherentInstances`. ~~`RankedInstances` extension ~~ I suggest simple `RankedInstances` extension. We use it (!)before OverlappingInstances (it must include `RankedInstances`), and in many cases instead of. This extension is easy to implement and it give us a lot of new possibilities and instruments. Now the system of instances is flat, and compiler takes all of them and check if only 1 match. If it is not(less or more than) - compiler trow an error. I suggest to add rankings, so compiler * compiler set N=0 * took all N-ranked instances and ** try to find only one match instance. *** If it found 1 - this is RESULT: needed instance, *** If it found many instances - still throw an error ******* (then we use `OverlappingInstances` to resolve this) *** If compiler found NO instances, compiler set N=N+1 and repeat * If N=MaxRank and still no matches compiler throw an error ~~How to add a rank~~ I suggest next grammar: {-# LANGUAGE RankedInstances #-} instance rank 1. C a => D a where ... instance C2 a => E a where ... <<==>> instance rank 0. C2 a => E a where ... So, all written instances(without ranking) are 0-ranked instances. Backward compatibility => without -XRankedInstances all instances with rank n, where n >0 - are not exported ~Example~ 1) instance rank 1. C Int a where ... -- (A) instance C a Bool where ... -- (B) rank 0 1+) instance rank 1. C Int a where ... -- (A) instance rank 1. C a Bool where ... -- (B) instance C Int Bool where ... -- (C) rank 0 2) instance rank 1. C Int [a] where ... -- (C) instance C Int [Int] where ... -- (D) As we see, all instances are unambiguous! ~~ Rank Scale~~ It is for discussion, I see this like: 0 - default 1 ..9 - user free (without fear to overlap with devs instances) 10 .. 14 - Generic 15 .. - superclass' instances ~~ Higher Rank instances~~ We don't need to use `default` inside of class: instance rank 10. (Generic a, GToJSON (Rep a)) => ToJSON a where toJSON = genericToJSON defaultOptions We could add superclass' instances now, something like these: instance rank 15. Monad m => Applicative m where pure = return (<*>) = ap instance rank 16. Monad m => Functor m where fmap = liftM instance rank 17. Applicative m => Functor m where fmap f x = pure f <*> x ~~Inherit mechanism~~ What do if we want to use any proposed instance, not in the rank order ? For example we have data, which is Monad and Applicative, but not a Functor. We'll use automatically "instance rank 16. Monad m => Functor m", but not "instance rank 17. Applicative m => Functor m" . But we wish to use the last one. We need to create a new instance and inherit the behavior of needed instance data D a .... instance Monad D where ... instance Applicative D where ... instance rank 1. Functor D inherit (D ~ m) instance Applicative m => Functor m foo = ... fmap So, in this case we'll use `fmap` as Applicative Functor. Inherit mechanism defaulting : instance C a => D a where ... <<==>> instance C a => D a inherit (a ~ b) class D b where ~~ "As" pattern in RankedInstances~~ Now we add "as" pattern and rewrite both of our instances: instance rank 17. Applicative m => ApFunctor@Functor m where fmap f x = pure f <*> x instance ApFunctor D --by the way 0-ranked Wow!!! It is simple, safe and looks nicer! ~~Partly Applied Instances~~ We describe a situation when we write a child class and want automatically get access to parent's classes. But sometimes we need to use already defined parent classes to describe children classes We CANNOT do next: instance rank 20. (Functor m, Applicative m) => Monad m where ma >> mb = (fmap (const id) ma) `apply` mb instance rank 21. Applicative m => Monad m where ma >> mb = (pure (const id) <*> ma) `apply` mb Because if we define data D a ... instance Functor D ... instance Applicative D ... D a >>= D b -- this will compiler, but we have no full applied MonadInstance How to resolve this? I suggest to add one reserved world "newclass" (as an analog of newtype) --instance (Functor m, Applicative m) => FAMonad@Monad m where newclass (Functor m, Applicative m) => FAMonad@Monad m where ma >> mb = (fmap (const id) ma) `apply` mb --instance Applicative m => AMonad@Monad m where newclass (Applicative m) => AMonad@Monad m where ma >> mb = (pure (const id) <*> ma) `apply` mb The "newclass" is just an instance, but guarded - compiler did count it when it try to match So, now next throw an error: D a >>= D b And we have an ability to write more precisely instance AMonad H where instance FAMonad K where ~~~BIG Example~~~~ Let try to divide "class (Eq a)=>Ord a" to both: ORIGINAL ONE: class (Eq a) => Ord a where compare :: a -> a -> Ordering ... compare x y = if x == y then EQ else if x <= y then LT else GT Proposed one (it is just an example, not a "real" proposal): class Ord' a where ........... compare x y = if x < y then LT else if x > y then GT else EQ -- without Eq it is a last choice newclass (Eq a) => Ord@Ord' a where compare x y = if x == y then EQ else if x <= y then LT else GT So now we have both Ord' a for nonEQ data and for Eq data. And this has a backward compatibility! -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-RankedInstances-tp5737152.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 0

Looking for numbers to support using haskell
by Mike Meyer 26 Sep '13

26 Sep '13

Hi all, I'm looking for articles that provide some technical support for why Haskell rocks. Not just cheerleading, but something with a bit of real information in it - a comparison of code snippets in multiple languages, or the results of a study on programmer productivity (given all the noise and heat on the topic of type checking, surely there's a study somewhere that actually provides light as well), etc. Basically, I'd love things that would turn into an elevator pitch of "I can show you how to be X times more productive than you are using Y", and then the article provides the evidence to support that claim. Thanks, Mike

5 5

Why superclass' instances are bad idea?
by Wvv 26 Sep '13

26 Sep '13

I suggest to add superclass' instances into libraries. http://ghc.haskell.org/trac/ghc/ticket/8348 In brief, we could write next: >{-# LANGUAGE FlexibleInstances #-} >{-# LANGUAGE UndecidableInstances #-} > >instance Monad m => Applicative m where > pure = return > (<*>) = ap > >instance Monad m => Functor m where > fmap = liftM > >instance Monad m => Bind m where > (>>-) = flip (>>=) > B.join = M.join this code is valid! I've already defined 3 "superclassses" for Monad: Functor, Applicative and Bind! Similar idea said Edward Kmett in 2010 (founded by monoidal) ( http://stackoverflow.com/questions/3213490/how-do-i-write-if-typeclass-a-th… ) And he said "but effectively what this instance is saying is that every Applicative should be derived by first finding an instance for Monad, and then dispatching to it. So while it would have the intention of saying that every Monad is Applicative (by the way the implication-like => reads) what it actually says is that every Applicative is a Monad, because having an instance head 't' matches any type. In many ways, the syntax for 'instance' and 'class' definitions is backwards." Why? I don't understand. Not every Applicative is a Monad, but every Monad is Applicative -- View this message in context: http://haskell.1045720.n5.nabble.com/Why-superclass-instances-are-bad-idea-… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 2

FP Complete competition clarification
by Mike Meyer 26 Sep '13

26 Sep '13

I got some clarification on what "unpublished" means for FP Complete competition entries. Basically, you can enter code that you've already published, providing it has an appropriate license (or can be republished with such a license). The tutorial/description/documentation that shows how to use it must be unpublished. So, if you're looking for a good excuse to document an existing project, how about a chance to win $1000 by doing so?

2 1

Hackage 2 switchover imminent
by Duncan Coutts 26 Sep '13

26 Sep '13

Hi everyone, Having been running the Hackage 2 alpha & beta for several months we intend to do the final switchover tomorrow (Wednesday 25th Sept). This will involve disabling uploads to the old server for a few hours. If all goes well we will switch the DNS over. If anything goes wrong we will just re-enable the old server. After the switch, everyone with a hackage account will need to do a one-time self-service account upgrade. A small handful of hackage early adopters will need assistance from an administrator to upgrade their accounts. We will email these people individually with instructions. If you wish to help or keep an eye on the switchover process then you are welcome to join us on the #hackage IRC channel on Freenode. If you run into problems after the switch there are site administrators you can contact and there is an issue tracker. Please report bugs in the site issue tracker: https://github.com/haskell/hackage-server/issues For issues with accounts or permissions please contact the administrators by email at admins(a)hackage.haskell.org -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 2

Re: [Haskell-cafe] [GSoC 2013] Porting Charts to Diagrams - Final Report
by Daniel Santa Cruz 26 Sep '13

26 Sep '13

Awesome work, Jan. I'm looking forward to playing around with the new libs! As a side note, what did you use to generate your email? Did you manage all the footnotes by hand? Daniel

1 0

Haskell Job Opportunity (Remote Work)
by Benny 25 Sep '13

25 Sep '13

Hello, ShotVibe is an early-stage Israeli startup company in the mobile photo sharing space. We are looking for an experienced or expert level Haskell programmer for backend web related projects. The work will be done by you remotely, using a freelancer model, with the potential for longer term work in the near future (also remote). One of the projects we have is a server application that queues messages that are to be sent to end user mobile phones, and pushes them through the "push notification" APIs supplied by Google and Apple. The work needed here involves some bug fixes, and some new features. This project will likely eventually be open sourced. Another project that we need to be written from scratch is a web application that handles photo uploads and processes them (including verifying user authentication with our main web backend, image resizing, and storing images on Amazon S3). This will probably end up only a few hundred lines of Haskell code, but involves integrating a bunch of stuff together. We are also interested in experimenting in using Haskell for some other areas of our backend where we are currently using Python. If you are interested you may contact me at: benny(a)shotvibe.com Please feel free to forward this email to any friends or acquaintances that may be interested.

1 0