- Haskell-prime - Haskell.org

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

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

02 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

Haskell 2014
by Ian Lynagh 01 May '13

01 May '13

Dear Haskellers, We are pleased to announce that the Haskell 2014 committee has now formed, and we would be delighted to receive your proposals for changes to the language. Please see http://hackage.haskell.org/trac/haskell-prime/wiki/Process for details on the proposal process. The committee will meet 4 times a year, to consider proposals completed before: * 1st August * 1st November * 1st February * 1st May so if you have been meaning to put the finishing touches to a proposal, then we would encourage you to do so by the end of July! The source for the Haskell report will be updated as proposals are accepted, but new versions of the standard will only be released once a year, during January. The Haskell 2014 committee is comprised of: * Carlos Camarão * Iavor Diatchki * Ian Lynagh (chair) * John Meacham * Neil Mitchell * Ganesh Sittampalam * David Terei * Bas van Dijk * Henk-Jan van Tuyl Thanks Ian (Haskell 2014 committee chair) -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0