May 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

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

Aprovados lista publicada Senador Guiomard
by Edson 29 May '13

29 May '13

Aprovados lista publicada Senador Guiomard: Pedra Preta: ALANA KELLY AFIO CAETANO, KARLA ALEXSANDRA LEITAO LIMA, FABIANA MAIA DE ALCANTARA, MÔNICA MÁRCIA DE LIMA, JOÃO CARLOS MOREIRA DE CARVALHO, CATARINA LABORE VIDAL FERNANDES, MARCELA TEOFILO BARROSO, IKARO GABRIEL CAVALCANTE MONTEIRO PINHEIRO. ROMÁRIO JOSÉ REZENDE DE BRITO, EDNAIRAN DOS SANTOS MARTINS, MARINALDO MANOEL DA SILVA JUNIOR, JOSÉ ELYELSON MARQUES TORRES, VALCLEIDE DOS SANTOS MENDES. Guimarães. Senador Guiomard, ANA CLARA DE MORAES HOLANDA, LORENNA DOS SANTOS SILVA, FRANCISCO JEFERSON GUERRA DA COSTA, PEDRO AMARANTE SILVA FILHO, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL AGUIAR DE SOUSA, MARIA ISABELA DE BRITO MORAIS, JARDEL SOUSA DA SILVA. SILVANA FERREIRA DE ARAÚJO, ARTHUR MAURICIO DE SOUZA RODRIGUES, LUCAS RAMOS DE LIMA, GLEYCIANNE M. DE CARVALHO, REBECCA ERONIDES NOJOSA ARRUDA. Brasópolis. Mucugê e ANNIBERG CORDEIRO DE SOUZA SILVA, LUCAS FONTENELE SILVA DE CARVALHO, GERLANDE MARIA FERREIRA, RAFAELLA SAMPAIO DE ALENCAR, JOÃO CARLOS MOREIRA DE CARVALHO, DENISE ARAÚJO JUSTINO, MARIA NIVANEIDE DE ABREU LIMA, JOELMA CÂNDIDO DA SILVA. TERESA RAQUEL DE MORAES ANDRADE, CARLA NAYANNE MOREIRA DE SOUZA, MAIRA NOGUEIRA ALVES, IAN VIEIRA LIMA AMORA DE SOUZA, ROBERTO ALMEIDA PIRES. Inaciolândia.

1 0

Re: proposal for trailing comma and semicolon
by Neil Sculthorpe 20 May '13

20 May '13

Same with me. I like using them, but turning on a language extension feels excessive. > I use them sometimes, but would do that much more if they didn't require > adding an extension. > > Roman > > * Edward Kmett <ekmett(a)gmail.com> [2013-05-17 15:24:27-0400] >> I personally use tuple sections a fair bit, though admittedly mostly for >> simple (,a) or (a,) cases. >> >> >> On Fri, May 17, 2013 at 3:01 PM, Ian Lynagh <ian(a)well-typed.com> wrote: >> >>> On Fri, May 17, 2013 at 02:04:44PM -0400, Edward Kmett wrote: >>>> My main concern is its a really weird corner case for the grammar to >>>> remember for tuple sections and it does have very weird grammar >>>> specification issues. >>> Tuple sections could look like >>> (True, _) >>> rather than >>> (True,) >>> >>> Does anyone know how common tuple sections are, incidentally? They've >>> been around since GHC 6.12, so it would be interesting to know if people >>> are actually using them.

1 0

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 02 May '13

02 May '13

> In your class Sum example, > > class Sum x y z | x y -> z, x z -> y > > your own solution has a bunch of helper classes First of all, on the top of other issues, I haven't actually shown an implementation in the message on Haskell'. I posed this as a general issue. In special cases like below > class Sum2 a b c | a b -> c, a c -> b > instance Sum2 Z b b > instance (Sum2 a' b c') => Sum2 (S a') b (S c') > -- note that in the FunDeps, var a is not a target > -- so the instances discriminate on var a I didn't doubt the translation would go through because there is a case analysis on a. But the general case can be more complex. For example, class Sum2 a b c | a b -> c, a c -> b instance Sum2 Z Z Z instance Sum2 O Z O instance Sum2 Z O O instance Sum2 O O Z > In your overlap example you introduce a definition that won't compile! > > > > {- -- correctly prohibited! > > instance x ~ Bool => C1 [Char] x where > > foo = const True > > -} > You expect too much if you think a mechanical translation will 'magic' a > non-compiling program into something that will compile. > I do expect equality constraints to not play well with overlaps. Combining > FunDeps with overlaps is also hazardous. I'm only claiming that EC's will > be at least as good. I don't understand the remark. The code marked `correctly prohibited' is in the comments. There are no claims were made about that code. If you found that comment disturbing, please delete it. It won't affect the the example: the types were improved in t11 but were not improved in t21. Therefore, EC's are not just as good. Functional dependencies seem to do better.

1 0

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

Mobile support
by Andrew Pennebaker 01 May '13

01 May '13

That would be cool!

1 0

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