- Haskell-prime - Haskell.org

Creating a list of extensions to add to Haskell'
by Henk-Jan van Tuyl 19 Apr '12

19 Apr '12

L.S., Many libraries on Hackage use language extensions, or depend on other libraries that use extensions. When an extension is no longer supported, or another Haskell compiler must be used, this may lead to a lot of maintenance work. To prevent an extreme amount of maintenance, I try to avoid using language extensions, but many libraries on Hackage use them. My proposal is: Make an inventory, of the most used language extensions (based on the number of Hackage downloads of packages depending directly or indirectly on them). If the most used extensions are theoretically sound and improve software developed with them, they should be included in the next Haskell standard. Packages, using rejected extensions, should be redesigned or shunned (marked as such in Hackage). Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

2 1

Re: String != [Char]
by Edward Kmett 01 Apr '12

01 Apr '12

>From Greg Weber, *Fri Mar 23 14:24:24 CET 2012:* > > This proposal doesn't have to break any codebases. > One possibility is to add the Text type to the standard while > keeping String and marking it as deprecated. I for one would like to go on the record as being against any notion of "deprecating" String. Text is good for many use-cases, but it has very different* asymptotic* behavior for many operations, and cannot serve as a one-size-fits-all replacement for String. I am less strongly against adding Text to the standard, but mostly because I am leery in that it brings a lot of language specification baggage and risks making attempts to explore the design space around Text harder. (e.g. Jasper's GSoC project this last year to investigate using UTF-8 encoded Data.Text would have been a much harder sell if Text was codified in the language standard!) Text has a remarkably (necessarily) large API and for the first time, as far as I can see, the specification would be largely requiring users to use qualified imports to access everything inside of it, which complicates the language standard from a pedagogical standpoint. Isn't it enough that it is part of the platform? -Edward

23 80

Faça parte da minha rede no LinkedIn
by Carlos Camarao Figueiredo 29 Mar '12

29 Mar '12

LinkedIn ------------ Eu gostaria de adicioná-lo à minha rede profissional no LinkedIn. -Carlos Camarao Carlos Camarao Figueiredo Professor na UFMG Belo Horizonte e Região, Brasil Confirme que você conhece Carlos Camarao Figueiredo: https://www.linkedin.com/e/g4afbk-h0e41yt6-n/isd/6485083729/t-WWDysg/?hs=fa… -- Você está recebendo convites de conexão por e-mail. Clique aqui para parar de recebê-los: http://www.linkedin.com/e/g4afbk-h0e41yt6-n/TxW8ibFUf804HWGRSSBmLzVTlbMbbXm… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043 - EUA.

1 0

String != [Char]
by Greg Weber 23 Mar '12

23 Mar '12

the text library and Text data type have shown the worth in real world Haskell usage with GHC. I try to avoid String whenever possible, but I still have to deal with conversions and other issues. There is a lot of real work to be done to convert away from [Char], but I think we need to take it out of the language definition as a first step. I can only see one issue with the proposal: it can be convenient to operate on a list of characters. But I think there are plenty of solutions at our disposal. A simple conversion from Text to a list of characters might suffice. In GHC, OverloadedStrings means users would still be free to use String the same way they are now.

15 30

What is a punctuation character?
by Gabriel Dos Reis 20 Mar '12

20 Mar '12

Hi, The lexical structure chapter defines the non-terminal uniSymbol as uniSymbol ::= any Unicode symbol or punctuation There is a slight ambiguity here: is that description supposed to be parsed as: (a) "Unicode (symbol or punctuation)", or (b) "(Unicode symbol) or punctuation"? If (b), then what qualifies as "punctuation"? As far as I can tell, that is not defined anywhere in the Report. Is it "punctuation" in the basic ASCII charset or in the extended ASCII charset? Everywhere else the Report has been careful in listing which ASCII characters are meant. Thanks, -- Gaby

7 18

Hierarchical module broken link
by Gabriel Dos Reis 15 Mar '12

15 Mar '12

Hi, The page with link http://www.haskell.org/hierarchical-modules/ from http://hackage.haskell.org/trac/haskell-prime/wiki/HierarchicalModules is broken (404 error). Thanks, -- Gaby

1 0

FW: 7.4.1-pre: Show & Integral
by Simon Peyton-Jones 06 Mar '12

06 Mar '12

I'm confused too. I'd welcome clarification from the Haskell Prime folk. S -----Original Message----- From: Serge D. Mechveliani [mailto:mechvel@botik.ru] Sent: 23 December 2011 17:36 To: Simon Peyton-Jones Subject: Re: 7.4.1-pre: Show & Integral On Thu, Dec 22, 2011 at 08:14:54PM +0000, Simon Peyton-Jones wrote: > | 2011/12/22 Edward Kmett <ekmett(a)gmail.com>: > | > The change, however, was a deliberate _break_ with the standard that > | > passed through the library review process a few months ago, and is now > | > making its way out into the wild. > | > | Is it reasonable to enquire how many standard-compliant implementations > | of Haskell there are? > > Just to be clear, the change IS the standard. GHC has to change to be compliant. > At least that's how I understand it. I am confused. I am looking now at the on-line specification of Haskell-2010, 6.3 Standard Haskell Classes. It shows that Integral includes Show: Eq Show \ / Num | Enum Real \ | Integral This is also visible in the further standard class declarations in this chapter. Hence, for `x :: Integral a => a' it is correct to write (shows x ""). And ghc-7.4.0.20111219 does not allow this. So, ghc-7.4.0.20111219 breaks the 2010 standard. Now, Edward Kmett writes that this break is done deliberately. Am I missing something? I witness this for the first time: that GHC deliberately breaks the current Haskell standard. Probably, many people (as myself) dislike this point of the standard. Well, they can write a dummy Show implementation for their type T: showsPrec _ _ = showString "(<t> :: T)", and wait for an improved standard, say, Haskell-II -- ? Regards, ------ Sergei mechvel(a)botik.ru

4 3

Re: simple extension to ghc's record disambiguation rules
by Anthony Clayden 18 Feb '12

18 Feb '12

> Hi, I'd like to propose an extremely simple extension to > ghc's record disambiguation rules, > John, I've just posted a proposal on the 'Records in Haskell' wiki that I think will do the job for you. "Declared Overloaded Record Fields" (DORF). I'd appreciate feedback. > my motivation is that I often have record types with > multiple constructors but common fields. > This is exactly the use case I'm aiming at. > > so, my proposal is that when you come across something > like > > (e::RecType) { blah = foo } > > (with an explicit type signature like shown) > ... My proposal is the same, except that you don't need a type sig (or not always). That record syntax desugars to a call to `set', which is a method of class `Has' (which also has method `get'). Has/get/set are overloaded for each record/field combination. The instance is generated at the record declaration, instead of the H98 record selector function. > > It is also backwards compatible for expressions, but would > be a new thing for patterns which generally don't allow > type signatures there. > DORF is backwards compatible with H98 record selectors, in the sense that polymorphic selectors (using `get') are just functions. > It sidesteps type checker interactions by only being > triggered when an explicit type annotation is included. > (DORF uses usual instance resolution by record type and field.) > ideally it would be combined with the 'update' and > 'label-based pattern-matching' extensions from this page > http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords > > John > DORF supports update and pattern matching by label, per -XDismabiguateRecordFields and friends. Anthony

1 0

simple extension to ghc's record disambiguation rules
by John Meacham 18 Feb '12

18 Feb '12

Hi, I'd like to propose an extremely simple extension to ghc's record disambiguation rules, my motivation is that I often have record types with multiple constructors but common fields. so the handy idiom of f Rec { .. } = do blah return Rec { .. } won't work, because I don't know the specific constructor. so, my proposal is that when you come across something like (e::RecType) { blah = foo } (with an explicit type signature like shown) You interpret 'blah' as if it is a field of the record of type 'Rec'. This gives the advantages of record field names being scoped by type but without you having to specify the precise constructor. It is also backwards compatible for expressions, but would be a new thing for patterns which generally don't allow type signatures there. It sidesteps type checker interactions by only being triggered when an explicit type annotation is included. ideally it would be combined with the 'update' and 'label-based pattern-matching' extensions from this page http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords John

1 0

Re: Proposal: require spaces around the dot operator
by Doug McIlroy 13 Feb '12

13 Feb '12

> +1 to the idea of requiring spaces around all operators. > It's just good style > Cutting things close syntactically just because you can is perhaps > not the best of ideas Haskell is mathematical both in substance and style. I would not lightly prohibit the use of spacing conventions that have proved over centuries to aid in understanding syntactic strucure. For example, this code fragment to define addition on lists is instantly intelligible. instance Num a => Num [a] where (f:fs) + (g:gs) = f+g : fs+gs But the formula becomes merely an obscure procession of symbols when rewritten with the operators set off by spaces: ( fs : gs ) + ( g : gs ) = f + g : fs + gs And it becomes too long and too subtly modulated to take in at a glance if more spacing is added to emphasize precedence: ( f : fs ) + ( g : gs ) = f + g : fs + gs Doug McIlroy

5 4