February 2013 - Haskell-prime

Re: In opposition of Functor as super-class of Monad
by Petr P 08 Jul '13

08 Jul '13

Hi, I was thinking lately about the well known problem that Monad is neither Functor nor Applicative. As I understand, it is caused by some historical issues. What I like about Haskell is that it allows to describe very nicely what different objects actually are - something that I find very important for programming. And this issue violates this principle. This has been discussed here more than year ago in http://www.haskell.org/pipermail/haskell-prime/2011-January/003312.html : On 1/4/11 11:24, oleg at okmij.org wrote: > I'd like to argue in opposition of making Functor a super-class of > Monad. I would argue that superclass constraints are not the right > tool for expressing mathematical relationship such that all monads are > functors and applicatives. > > Then argument is practical. It seems that making Functor a superclass > of Monad makes defining new monad instances more of a chore, leading > to code duplication. To me, code duplication is a sign that an > abstraction is missing or misused. > ... The main objections were that it would break existing code and that it would lead to code duplication. The former is serious, the second can be easily solved by standard Haskell, since one can define instance Applicative ... where pure = return (<*>) = ap instance Functor ... where fmap = liftM To address the first objection: AFAIK nobody mentioned the "Default superclass instances" proposal: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances To give an example how it would work: class Applicative f => Monad f where (>>=) :: f a -> (a -> f b) -> f b ... instance Applicative f where ff <*> fs = ff >>= \ f -> fs >>= \ s -> return (f s) ... This says that if somebody defines an instance of Monad it automatically becomes an instance of Applicative as defined in the nested "instance" block. So there is no need to define Applicative/Functor explicitly, making existing code work. Implementing this proposal would allow making Monad to extend Functor and Applicative without breaking existing code. Moreover, this would simplify other things, for example it would be possible to define an instance of Traversable and the instances for Functor and Foldable would be defined implicitly using fmapDefault and foldMapDefault. I'm sure there are many other cases where splitting type classes into a more fine-grained hierarchy would be beneficial, and the main reason against it is simply not to break compatibility with existing code. IMHO this would be worthwhile to consider for some future revision of Haskell. Best regards, Petr Pudlak

8 11

Bang patterns
by Ian Lynagh 08 Feb '13

08 Feb '13

Hi all, I would like to get a full specification of the bang patterns syntax, partly so it can be proposed for H', and partly so we can resolve tickets like http://hackage.haskell.org/trac/ghc/ticket/1087 correctly. I think there are 3 possibilities: The first is suggested by "A bang only really has an effect if it precedes a variable or wild-card pattern" on http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns We could therefore alter the lexical syntax to make strict things into lexems, for example reservedid -> ... | _ | !_ strictvarid -> ! varid etc. This would mean that "f !x" is 2 lexemes, and "f ! x" 3 lexemes, with the former defining the function 'f' and the latter defining the operator '!'. This has 3 downsides: * It would require also accepting the more radical proposal of making let strict, as it would no longer be possible to write let ![x,y] = undefined in () * It would mean that "f !x" and "f !(x)" are different. Probably not a big issue in practice. * It may interact badly with other future extensions. For example, {-# LANGUAGE ViewPatterns #-} f !(view -> x) = () should arguably be strict in x. (you might also argue that it should define the operator '!'. Currently, in ghc, it defines an 'f' that is lazy in x, which IMO is a bug). The second is to parse '!' differently depending on whether or not it is followed by a space. In the absence of a decision to require infix operators to be surrounded by spaces, I think this is a bad idea: Tricky to specify, and to understand. The third is to parse '!' in patterns in the same way that '~' is parsed in patterns, except that (!) would be accepted as binding the operator '!'. This means that "f ! x" defines f. So my proposal would be to go with option 3. What do you think? And did I miss any better options? Thanks Ian

8 16

Call for Nominations: Haskell Prime language committee
by Malcolm Wallace 04 Feb '13

04 Feb '13

Dear Haskell lovers, The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse. Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard. We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience. If you think you would like to contribute, please nominate yourself by sending a email to haskell-2011-committee(a)haskell.org describing who you are, and what you think the committee might hope to achieve. The address above is populated by the existing committee members, but is now (temporarily) open to all during the nomination period. Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013. The process for deciding a new language committee is described at http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Regards, Malcolm

1 0

Status of Haskell'?
by Roman Cheplyaka 01 Feb '13

01 Feb '13

Hi, Can someone comment on the status of Haskell'? As I understood from [1], new language releases were supposed to be made annually, and there hasn't been a release for 3 years. [1]: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Roman

18 33