April 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

Re: relaxing instance declarations
by Doug McIlroy 02 May '13

02 May '13

Max's idea (see below) of a second where clause is cute, but not sanctioned by Haskell syntax. Iavor wrote, "It would be quite arbitrary to restrict this only to instances." Actually what I have in mind is to make the language MORE consistent, by eliminating distinctions between instance-wheres and ordinary declaration-wheres. Currently instance-wheres may only declare class methods, while declaration-wheres may declare variables at will. Also instance-wheres may not declare type signatures, while declaration-wheres may. I propose dropping these restrictions on instance-wheres. Hazard: Adding a method to an existing class could accidentally capture a name that was previously local to an instance-where. Capture can be prevented by declaring type signatures for local variables. The compiler might warn when such defensive declarations are lacking. Doug On Mon, 29 Apr 2013 15:56 Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote Hello, I think that if we want something along those lines, we should consider a more general construct that allows declarations to scope over other declarations (like SML's `local` construct). It would be quite arbitrary to restrict this only to instances. -Iavor On Mon, Apr 29, 2013 at 2:41 PM, Max Bolingbroke <batterseapower(a)hotmail.com > wrote: > You could probably get away with just using two "where" clauses: > > instance Foo a where > bar = ... > where > auxilliary = ... > > > > > On 28 April 2013 18:42, Edward Kmett <ekmett(a)gmail.com> wrote: > >> Makes sense. I'm not sure what a good syntactic story would be for that >> feature though. Just writing down member names that aren't in the class >> seems to be too brittle and error prone, and new keywords seems uglier than >> the current situation. >> >> Sent from my iPad >> >> On Apr 28, 2013, at 1:24 PM, Doug McIlroy <doug(a)cs.dartmouth.edu> wrote: >> >> > Not always. For example, you can't mess with the declaration >> > of a standard class, such as Num. >> > >> > On Sun, Apr 28, 2013 at 12:06 PM, Edward Kmett <ekmett(a)gmail.com> >> wrote: >> > >> >> You can always put those helper functions in the class and then just >> not >> >> export them from the module. >> > >> > On Sun, Apr 28, 2013 at 10:49 AM, Doug McIlroy <doug(a)cs.dartmouth.edu >> >wrote: >> > >> >> Is there any strong reason why the where clause in an instance >> >> declaration cannot declare anything other than class >> >> operators? If not, I suggest relaxing the restriction. >> >> >> >> It is not unusual for declarations of class operators to >> >> refer to special auxiliary functions. Under current rules >> >> such functions have to be declared outside the scope in >> >> which they are used. >> >> >> >> Doug McIlroy >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> >> > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > > Content-Type: text/html; charset=UTF-8

4 3

Re: Is it time to start deprecating FunDeps?
by oleg＠okmij.org 01 May '13

01 May '13

Anthony Clayden wrote: > Better still, given that there is a mechanical way to convert FunDeps to > equalities, we could start treating the FunDep on a class declaration as > documentation, and validate that the instances observe the mechanical > translation. I think this mechanical way is not complete. First of all, how do you mechanically convert something like class Sum x y z | x y -> z, x z -> y Second, in the presence of overlapping, the translation gives different results: compare the inferred types for t11 and t21. There is no type improvement in t21. (The code also exhibits the coherence problem for overlapping instances: the inferred type of t2 changes when we remove the last instance of C2, from Bool to [Char].) {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances, TypeFamilies #-} {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE OverlappingInstances #-} module FD where class C1 a b | a -> b where foo :: a -> b instance C1 [a] [a] where foo = id instance C1 (Maybe a) (Maybe a) where foo = id {- -- correctly prohibited! instance x ~ Bool => C1 [Char] x where foo = const True -} t1 = foo "a" t11 = \x -> foo [x] -- t11 :: t -> [t] -- Anthony Clayden's translation class C2 a b where foo2 :: a -> b instance x ~ [a] => C2 [a] x where foo2 = id instance x ~ (Maybe a) => C2 (Maybe a) x where foo2 = id instance x ~ Bool => C2 [Char] x where foo2 = const True t2 = foo2 "a" t21 = \x -> foo2 [x] -- t21 :: C2 [t] b => t -> b

4 7

Is it time to start deprecating FunDeps?
by AntC 01 May '13

01 May '13

Now that the Type Equality coercions extension is stable and has been blessed by SPJ as "a functional-dependency-like mechanism (but using equalities) for the result type" [in http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#Hig herranktypesandtypefunctions], no code is compelled to use FunDeps. [Note that this is orthogonal to the issue of overlaps. You can use the equalities mechanism happily with overlaps, see example below. This is also orthogonal to type functions/families/associated types. You can use the equalities mechanism happily without type families.] There's plenty of code using FunDeps, so we couldn't just withdraw the extension. But we could start deprecating it. Better still, given that there is a mechanical way to convert FunDeps to equalities, we could start treating the FunDep on a class declaration as documentation, and validate that the instances observe the mechanical translation. Here's an example of the mechanical translation for HDeleteMany, the classic awkward example from HList. The problem is to delete all occurences of element type e in a HList l. Here's the 'non-solution' naieve attempt from the HList paper: class HDeleteMany e l l' | e l -> l' instance HDeleteMany a HNil HNil -- base case OK instance (HList l, HDeleteMany e l l') => HDeleteMany e (HCons e l) l' -- element match, so omit instance (HList l, HDeleteMany e l l') => HDeleteMany e (HCons e' l) (HCons e' l') -- element not match, so retain -- + recurse on the tail "The two overlapping instance heads for HCons are in no substitution ordering." Here's the mechanical translation, which _does_ compile: class HDeleteMany e l l' -- | e l -> l' instance (HNil ~ l') -- force the result => HDeleteMany a HNil l' -- base case OK instance (HList l, HDeleteMany e l l') => HDeleteMany e (HCons e l) l' -- same as above instance (HList l, HDeleteMany e l l'', (HCons e' l'') ~ l') => HDeleteMany e (HCons e' l) l' -- force the result The translation rules (applying for the 'target' term of a FunDep) are: 1. If the target is a bare typevar not appearing otherwise in the head, we're done OK. Otherwise: 2. Replace the target with a fresh typevar. (This forces instance match without inspecting the use site.) 3. Add a type equality constraint equating the fresh typevar with the as-was target term. (This forces the result type, in the same way as a FunDep target.) Possible GSOC project?

5 7

Re: relaxing instance declarations
by Doug McIlroy 29 Apr '13

29 Apr '13

Not always. For example, you can't mess with the declaration of a standard class, such as Num. On Sun, Apr 28, 2013 at 12:06 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > You can always put those helper functions in the class and then just not > export them from the module. On Sun, Apr 28, 2013 at 10:49 AM, Doug McIlroy <doug(a)cs.dartmouth.edu>wrote: > Is there any strong reason why the where clause in an instance > declaration cannot declare anything other than class > operators? If not, I suggest relaxing the restriction. > > It is not unusual for declarations of class operators to > refer to special auxiliary functions. Under current rules > such functions have to be declared outside the scope in > which they are used. > > Doug McIlroy

4 3

relaxing instance declarations
by Doug McIlroy 28 Apr '13

28 Apr '13

Is there any strong reason why the where clause in an instance declaration cannot declare anything other than class operators? If not, I suggest relaxing the restriction. It is not unusual for declarations of class operators to refer to special auxiliary functions. Under current rules such functions have to be declared outside the scope in which they are used. Doug McIlroy

2 1