June 2013 - Haskell-prime

proposal for trailing comma and semicolon
by Garrett Mitchener 19 Aug '13

19 Aug '13

There's a weird idiom that I see all the time in Haskell code where coders put commas at the beginning of lines: data Thing = Thing { x :: Int ,y :: Int ,z :: Int ,foo :: String } ... items = [ "red" ,"blue" ,"green" ] and it's pretty clear that the reason for this is that it's easier to comment out the last item by prefixing -- items = [ "red" ,"blue" -- ,"green" ] instead of items = [ "red", "blue" -- , -- "green" ] The same sort of thing shows up with semicolons sometimes too let { x = 1 ;y = 2 ;z = 3 } in However, this punctuation-at-the-front just seems wrong. It ultimately comes from using , as a separator rather than a terminator in the syntax of sequences. But Python has this nifty quirk where you can leave a comma after the last item in a sequence, so that the following is OK in Python but not in Haskell: items = [ "red", "blue", -- "green" ] Part of why Python does this is to allow room in the syntax for tuples with a single item as in (1,) There might be problems doing this with Haskell tuples because of tuple sections like (,,,) building a 4-tuple from 4 arguments, and where (x,y,) is interpreted as a function that takes another item and produces a three-component tuple. Anyway, this is a "paper cut" in the language that has been bugging me for a while, and since there's now a call for suggestions for Haskell 2014, I thought I'd ask about it. -- Garrett Mitchener

12 13

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

Interfaces - the Golden Path of Haskell?
by Wvv 08 Jul '13

08 Jul '13

This is fairly the same as http://hackage.haskell.org/trac/ghc/ticket/8021 but it's rewritten a little Interfaces Interface is a generalization of the class. Now class become just *instances* of interface For backward compatibility compiler should calculate interface by itself, but it should allow to write interfaces to everybody (more detail at "Maybe Problems"). /-- it is calculated by the Compiler or is written directly/ class interface Monoid (a :: k) where /-- like Typeable/ mempty :: * mappend :: * -> * -> * class Monoid a where ... class Monad m => Monoid m where ... class Arrow c => Monoid c where ... It is easy to use them with functions: foo :: (Monad m => Monoid m , Monad m ) => m a bar :: (Arrow c => Monoid c, Arrow c) => c b a These classes are open, you could lately add class MyClass c => Monoid c where ... We use like Typeable (a :: k) because: () => Monoid a :: * Monad m => Monoid m :: * -> * Arrow c => Monoid c :: * -> * -> * Backward compatibility If class have single constraint, you could write without it. If class have many constraints, you could write without it, if it is empty one. bar :: MonadPlus m => m a <<==>> bar :: () => Monad m => MonadPlus m => m a foo :: Monoid a => a <<==>> foo :: () => Monoid a => a baz :: Monad m => Monoid m => m a <<==>> baz :: () => Monad m => Monoid m => m a Better than superclasses we already have class Num a where ... But we wish to generalize it. It's easy now, we just add: class Additive a where addplus = ... class Multiplicative a where multprod = ... class (Additive a, Multiplicative a) => Num a where (+) = addplus (*) = multprod foo :: (Additive a, Multiplicative a) => Num a => a -> a -> a Maybe Problems 1) If we have already class class Foo a where data F :: ... type S :: ... data family G ... what interface do we have ? Possible reply - no data in the interface. 2) What is the interface of Typeable ? 2.1) What is the interface of class with unwritten interface? Possible reply - the same as class, so it is easy to Compiler. 3) Misfeature - to allow write interface manually Why? You can't change it later. So, it must be deprecated from the beginning. -- View this message in context: http://haskell.1045720.n5.nabble.com/Interfaces-the-Golden-Path-of-Haskell-… Sent from the Haskell - Haskell-prime mailing list archive at Nabble.com.

2 4

Remove Enum from Float and Double
by harry 18 Jun '13

18 Jun '13

There have been several discussions over the years regarding Enum instances for Float and Double. The conclusion each time appears to have been that there are no instances which are both sane and practical. I would like to propose that these instances be removed from Haskell 2014. This may be covered by the various alternative prelude and number class proposals, but they are much more ambitious and less likely to make it into the standard in the short term.

7 13

Proposal: NoImplicitPreludeImport
by Ian Lynagh 05 Jun '13

05 Jun '13

Dear Haskellers, I have made a wiki page describing a new proposal, NoImplicitPreludeImport, which I intend to propose for Haskell 2014: http://hackage.haskell.org/trac/haskell-prime/wiki/NoImplicitPreludeImport What do you think? Thanks to the folks on #ghc who gave some comments on an earlier draft. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

10 16