July 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

Proposal: Non-recursive let
by oleg＠okmij.org 11 Jul '13

11 Jul '13

[reposting to Haskell-prime] Jon Fairbairn wrote: > It just changes forgetting to use different variable names because of > recursion (which is currently uniform throughout the language) to > forgetting to use non recursive let instead of let. Let me bring to the record the message I just wrote on Haskell-cafe http://www.haskell.org/pipermail/haskell-cafe/2013-July/109116.html and repeat the example: In OCaml, I can (and often do) write let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in ... In Haskell I'll have to uniquely number the s's: let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ... and re-number them if I insert a new statement. I once wrote about 50-100 lines of code with the fragment like the above and the only problem was my messing up the numbering (at one place I used s2 where I should've used s3). In the chain of lets, it becomes quite a chore to use different variable names -- especially as one edits the code and adds new let statements. I have also had problems with non-termination, unintended recursion. The problem is not caught statically and leads to looping, which may be quite difficult to debug. Andreas should tell his story. In my OCaml experience, I don't ever remember writing let rec by mistake. Occasionally I write let where let rec is meant, and the type checker very quickly points out a problem (an unbound identifier). No need to debug anything. Incidentally, time and again people ask on the Caml list why 'let' in OCaml is by default non-recursive. The common answer is that the practitioners find in their experience the non-recursive let to be a better default. Recursion should be intended and explicit -- more errors are caught that way. Let me finally disagree with the uniformity principle. It may be uniform to have equi-recursive types. OCaml has equi-recursive types; internally the type checker treats _all_ types as (potentially) equi-recursive. At one point OCaml allowed equi-recursive types in user programs as well. They were introduced for the sake of objects; so the designers felt uniformly warrants to offer them in all circumstances. The users vocally disagreed. Equi-recursive types mask many common type errors, making them much more difficult to find. As the result, OCaml developers broke the uniformity. Now, equi-recursive types may only appear in surface programs in very specific circumstances (where objects or their duals are involved). Basically, the programmer must really intend to use them. Here is an example from the natural language, English. Some verbs go from regular (uniform conjugation) to irregular: http://en.wiktionary.org/wiki/dive

3 3

Proposal: Non-recursive let
by Andreas Abel 10 Jul '13

10 Jul '13

Proposal: add a non-recursive let to the Haskell language. In let' p = e in e' do { ... let' p = e ... } the variables of pattern p are then *not* in scope in e. Reasons for adding a non-recursive let: 1. recursive-let is the source for many non-termination bugs. An instance of such a bug is in the state monad of mtl-2.1 (forgive me, Edward, for quoting this again): http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Mo… state :: (s -> (a, s)) -> m a state f = do s <- get let ~(a, s) = f s put s return a here, a non-recursive let was meant, the s bound by the let was supposed to be a new state, shadowing the old state. However, since let is recursive, this actually causes a loop. Another instance (cut-down) are let-guards like let Just x | x > 0 = e in x The "x > 0" is understood as an assertion here, documenting an invariant. However, Haskell reads this as let Just x = case () of { () | x > 0 -> e } in x leading to non-termination. A non-recursive version let' Just x | x > 0 = e in x could be interpreted as case e of { Just x | x > 0 -> x } instead, which is meaningful (in contrast to the current interpretation). 2. Connected to 1., a non-recursive let allows for painless shadowing. For instance, the hack do ... x <- return $ f x exploiting non-recursiveness of the <- binding, would be unnecessary, instead we could write do ... let' x = f x NB: In a do-Block, we could drop the keyword let' and simply write do ... x = f x for a non-monadic binding, in accordance to x <- mf x, See also http://www.haskell.org/pipermail/beginners/2009-February/001075.html http://stackoverflow.com/questions/8398607/declaration-order-in-let-binding… PS.: I can work out the details of grammar and semantics if this proposal finds followers. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

3 4

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