January 2011 - Haskell-prime

Announce: ~Haskell 2011
by Malcolm Wallace 14 Apr '11

14 Apr '11

The Haskell Language committee has had a quiet year. Following the announcement of Haskell 2010 in Nov 2009 [1], and the publication of the 2010 Report in July 2010 [2], we found a distinct lack of complete new proposals to decide upon. As a result, the committee has made the following decisions: (a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts (b) this delta will be applied to the 2010 Report to form a new baseline; (c) we will _not_ issue a new language standard called 2011; (d) we intend to issue a new language standard in 2012; (e) the committee will continue for another year without new nominations. However, let me make it clear that the apparent lull in committee activity does not mean there are no active proposals being made. On the contrary, proposals for language features (and removals) are made by the community at large (that's you) - the committee's main role is not to make proposals, but to decide which to accept. And there have in fact been a large number of proposals, but very few have made it all the way to the stage of producing a "language report delta" that could be accepted (or modified) by the committee. So, I wish to declare "open season" on proposals for the 2012 standard. If there is a language feature you care about, please do take an hour or two to review the details on our wiki [3], search for older discussions on the mailing lists, and draft the Report changes you think would be necessary. I'm looking forward to a more active and exciting collection of potential language changes for 2012, but it will only happen if you get involved. Regards, Malcolm (Haskell 2011 committee chair) [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html [2] http://www.haskell.org/pipermail/haskell/2010-July/022189.html [3] http://hackage.haskell.org/trac/haskell-prime/

4 5

Local definitions in the class instances
by Boris Lykah 02 Feb '11

02 Feb '11

I think it would be convenient to allow adding variables and functions, which are not members of the class, to a class instance so that they are visible only in the instance scope. It will help if the same functions are used by several class functions. Example: When implementing Num class for my datatype, I found that I routinely do unwrapping in each operator definition. I extracted it into functions, but as they are used only in instance definition, I want to put them there and restrict them to that scope. It would be neater than leaving them in the global scope or copypasting into each operator. > newtype Wrapped = Wrapped Integer deriving (Show, Eq) > instance Num Wrapped where > (+) = lift2 (+) > (-) = lift2 (-) > (*) = lift2 (*) > abs = lift abs > signum = lift signum > fromInteger = Wrapped > lift2 f (Wrapped a) (Wrapped b) = Wrapped (f a b) > lift f (Wrapped a) = Wrapped (f a) The extension implementation should be very simple. -- Regards, Boris

8 9

RelaxedLayout language extensions should be default for Haskell
by Axel Simon 21 Jan '11

21 Jan '11

Hi, following the discussion on the ghc mailing list, I propose that the new "RelaxedLayout" extension that is proposed for ghc 7.1 should be incorporated into the language standard. The motivation is that ghc <7.1 have silently implemented the "RelaxedLayout" by default and that removing this feature will break many programs without any gain except that ghc complies to the standard. Hence, it would be better that the standard is adjusted, as this would imply no changes to current ghc compilers nor user programs. As I'm not familiar with the technical details, I can only give an idea about what "RelaxedLayout" does. Haskell 2010 would parse foo = do some computation trace "hello" $ do other computation such that "other computation" belongs to the first "do", i.e. foo = do { some computation ; trace "hello" $ do ; other computation } which leads to a parse error since the second "do" not followed by any instructions. The relaxed layout extension opens a new block after a "do" if the next line commences on in the same column as the current block. Thus, it would parse the example above as: foo = do { some computation ; trace "hello" $ do { other computation } } Observations: - the proposal has been implemented in ghc for years - it does not break any existing programs (as far as I can see) - incorporating this proposal into the standard involves no implementation effort for the ghc compiler nor any program that compiles with ghc Cheers, Axel

1 1

Re: [Haskell] Announce: ~Haskell 2011
by Malcolm Wallace 20 Jan '11

20 Jan '11

>> (a) we wish to accept the NoDatatypeContexts proposal >> http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts > > The Trac-Wiki says: "What removing the datatype contexts from a source > file will do is make some previously illegal programs legal." What > is an > example? As on the wiki, data Eq a => Foo a = Constr a getVal :: Foo a -> a getVal (Constr x) = x would previously have been rejected. Once the compiler forces the user to remove the Eq a => context on the datatype, the rest of the program will be accepted. Regards, Malcolm

1 0

In opposition of Functor as super-class of Monad
by oleg＠okmij.org 08 Jan '11

08 Jan '11

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. For the sake of the argument, let us suppose that Functor is a superclass of Monad. Let us see how to define a new Monad instance. For the sake of a better illustration, I'll use a complex monad. I just happen to have an example of that: Iteratee. The data type Iteratee is defined as follows: > type ErrMsg = String -- simplifying > data Stream el = EOF (Maybe ErrMsg) | Chunk [el] deriving Show > > data Iteratee el m a = IE_done a > | IE_cont (Maybe ErrMsg) > (Stream el -> m (Iteratee el m a, Stream el)) We wish to define an instance for Monad (Iteratee el m). Since Functor is a superclass of Monad, we must define a functor instance: > instance Functor m => Functor (Iteratee el m) where > fmap f (IE_done a) = IE_done (f a) > fmap f (IE_cont e k) = IE_cont e (\s -> fmap docase (k s)) > where > docase (IE_done a,s) = (IE_done (f a), s) > docase (i, s) = (fmap f i, s) There are two ways to proceed with the Monad instance -- to be precise, there are two ways of defining bind. Method A: just define bind as usual > instance (Functor (Iteratee el m),Monad m) => Monad (Iteratee el m) where > return = IE_done > > IE_done a >>= f = f a > IE_cont e k >>= f = IE_cont e (\s -> k s >>= docase) > where > docase (IE_done a, stream) = case f a of > IE_cont Nothing k -> k stream > i -> return (i,stream) > docase (i, s) = return (i >>= f, s) Although we must state the constraint (Functor (Iteratee el m)) to satisfy the super-class constraint, we have not made any use of the constraint. We defined bind without resorting to fmap. That seems like a waste. What makes it seem more like a waste is that the code for fmap and for bind is almost the same. We had to repeat essentially the same algorithm, analysing Iteratee and the continuation. Method B: define bind in terms of fmap Alas, just fmap is not sufficient to define bind. We need join: > joinIter :: Monad m => Iteratee el m (Iteratee el m a) -> Iteratee el m a > joinIter (IE_done i) = i > joinIter (IE_cont e k) = IE_cont e (\s -> k s >>= docase) > where > docase (IE_done (IE_cont Nothing k), s) = k s > docase (IE_done i, s) = return (i, s) > docase (i, s) = return (joinIter i, s) Only after defining join we can write > bind m f = joinIter $ fmap f m Again we see code duplication: the code for join resembles the code for fmap. The code for join follows the same pattern of analysing Iteratee and the continuation. In either way, Functor as a super-class of Monad leads to code duplication. That gives a bad feeling practically -- and theoretically. The experiment has led me wonder if a superclass constraint is the right way to state the relationship between Monads and Functors. It _almost_ makes me wish the constraint go the other way: > instance Monad m => Functor m where > fmap f m = m >>= (return . f) That is, we need an instance rather than a superclass constraint, and in the other direction. The instance constraint says that every monad is a functor. Moreover, \f m = m >>= (return . f) is a _proof term_ that every monad is a functor. We can state it once and for all, for all present and future monads. Alas, the instance ``instance Monad m => Functor m'' above has several drawbacks (for one, requiring overlapping instances everywhere). This makes me wonder if something is amiss. In the meanwhile, there is a practical work-around. Introduce a TemplateHaskell operation generating an instance such as > instance Monad (Iteratee el m) => Functor (Iteratee el m) where > fmap f m = m >>= (return . f) (the code for the method remains the same; only the type in the instance head varies). Alas, that requires undecidable instances. All the code before was Haskell98.

12 13

Functor hierarchy proposal and class system extension proposal
by Howard B. Golden 07 Jan '11

07 Jan '11

Hi, In 2006, Ashley Yakeley proposed the functor hierarchy proposal (http://www.haskell.org/haskellwiki/Functor_hierarchy_proposal) and, in 2007, Brianh (his wiki handle since I don't know his name) proposed the class system extension proposal (http://www.haskell.org/haskellwiki/Class_system_extension_proposal) I recently Googled these proposals and didn't see any significant discussion since they were originally proposed. If there has been some, please point me to it so I can read it. Making functor a superclass of monad has the benefit of consistency with the mathematical definitions. It may also simplify the libraries. The class system extension proposal makes it possible to inherit the default implementations of functions from a superclass, thus simplifying the code that would otherwise be required to create a monad if the functor hierarchy proposal is adopted. Is there any interest in considering these proposals for the next iteration of Haskell'? Cheers, Howard B. Golden Northridge, California, USA

6 8

Haskell 2011?
by Ian Lynagh 05 Jan '11

05 Jan '11

Hi all, I haven't heard anything about Haskell 2011 since http://www.haskell.org/pipermail/haskell-prime/2010-August/003263.html Can someone let me know what's happening please? Will there be a Haskell 2011? Thanks Ian

2 1

ExplicitForAll complete
by Ian Lynagh 05 Jan '11

05 Jan '11

Hi all, I've completed the ExplicitForAll proposal, started by Niklas Broberg (but any errors are doubtless mine!): http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall http://hackage.haskell.org/trac/haskell-prime/ticket/133 I imagine this is too late for H2011 (if that will actually be happening?), but there wasn't an H2012 milestone, so I put it in H2011 anyway. Please feel free to remilestone. Thanks Ian

5 8