April 2011 - Haskell-prime

TypeSynonymInstances should be enabled by default
by Andrew Pennebaker 21 Apr '11

21 Apr '11

Source: https://github.com/mcandre/genetics With {-# LANGUAGE TypeSynonymInstances #-} , my genetic algorithm code compiles and runs perfectly. $ make $ ./helloga ... hellowobld helloworyd helloporld hellyworld helloworrd hellowofld hellpworld Best candidate: helloworld Without it, Haskell refuses to declare an instance on Strings. $ make ghc --make -O2 -fforce-recomp helloga.hs [1 of 2] Compiling Genetics ( Genetics.hs, Genetics.o ) [2 of 2] Compiling Main ( helloga.hs, helloga.o ) helloga.hs:27:10: Illegal instance declaration for `Gene String' (All instance types must be of the form (T t1 ... tn) where T is not a synonym. Use -XTypeSynonymInstances if you want to disable this.) In the instance declaration for `Gene String' make: *** [all] Error 1 The fix is easy to discover and apply, but this is my first typeclass, nothing complicated. As a newbie I prefer that it "just works" without my having to use the special compile flag. Cheers, Andrew Pennebaker www.yellosoft.us

2 1

Proposal: Define UTF-8 to be the encoding of Haskell source files
by Roel van Dijk 18 Apr '11

18 Apr '11

Per the Haskell Prime process I would like to make an official proposal [1]. * Proposal The Haskell 2010 language specification states that: "Haskell uses the Unicode character set" [2]. It does not state what encoding should be used. This means, strictly speaking, it is not possible to reliably exchange Haskell source files on the byte level. I propose to make UTF-8 the only allowed encoding for Haskell source files. Implementations must discard an initial Byte Order Mark (BOM) if present [3]. * Pros - Ensures that Haskell source can be reliably exchanged on the byte level. - Disallows implicit ISO-8859-* encodings in source code, ensuring portability. - Little or no implementation burden for compiler writers. * Cons - Existing code relying on a non-UTF8, locale-/implementation-specific encoding will need conversion. (Only relevant for Hugs-only code). * Implementation status ** GHC "GHC assumes that source files are ASCII or UTF-8 only, other encodings are not recognised. However, invalid UTF-8 sequences will be ignored in comments, so it is possible to use other encodings such as Latin-1, as long as the non-comment source code is ASCII only." [4] >From this I deduce that all current code accepted by GHC is compatible with UTF-8. No working code will be broken. ** JHC "JHC allows unrestricted use of the Unicode character set in Haskell source, treating input as UTF-8." [5] ** Hugs Hugs treats input as being in the encoding specified by the current locale, but permits Unicode only in comments and character and string literals. [6] * Related proposal There is one, 5 year old, proposal that is related: "SourceEncodingDetection" [5]. There it is proposed to detect the encoding using an algorithm which can distinguish between UTF-8, UTF-16 and (not always) UTF-32. It can also detect the endianness of the document, if applicable. I think choosing just UTF-8 is a better choice than a detection algorithm. It places less burden on implementation writers and is even more portable. * Next step Discussion! There was already some discussion on the haskell-cafe mailing list [7]. Attached is a patch for the Haskell Report which adds a note stating that source encodings must be UTF-8. Regards, Roel van Dijk [1] - http://hackage.haskell.org/trac/haskell-prime/wiki/Process [2] - http://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-150002.1 [3] - http://www.unicode.org/faq/utf_bom.html#bom5 [4] - http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/separate-compil… [5] - http://hackage.haskell.org/trac/haskell-prime/wiki/SourceEncodingDetection [6] - http://cvs.haskell.org/Hugs/pages/users_guide/locale.html [7] - http://article.gmane.org/gmane.comp.lang.haskell.cafe/87815

5 10

minor bug in Haskell 2010 standard
by Peter Klausler 14 Apr '11

14 Apr '11

A brief correction to a problem that may have already been noticed and rectified: on page 84 (being page 104 of the PDF), in the last sentence of section 6.4.3, it reads: "0**y is 1 if y is 1, and 0 otherwise." Surely this should read "0**y is 1 if y is 0, and 0 otherwise", yes? Best regards, Peter Klausler at Google in Madison

1 0

Announce: ~Haskell 2011
by Malcolm Wallace 14 Apr '11

14 Apr '11

The Haskell Language committee has had a quiet year. Following the announcement of Haskell 2010 in Nov 2009 [1], and the publication of the 2010 Report in July 2010 [2], we found a distinct lack of complete new proposals to decide upon. As a result, the committee has made the following decisions: (a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts (b) this delta will be applied to the 2010 Report to form a new baseline; (c) we will _not_ issue a new language standard called 2011; (d) we intend to issue a new language standard in 2012; (e) the committee will continue for another year without new nominations. However, let me make it clear that the apparent lull in committee activity does not mean there are no active proposals being made. On the contrary, proposals for language features (and removals) are made by the community at large (that's you) - the committee's main role is not to make proposals, but to decide which to accept. And there have in fact been a large number of proposals, but very few have made it all the way to the stage of producing a "language report delta" that could be accepted (or modified) by the committee. So, I wish to declare "open season" on proposals for the 2012 standard. If there is a language feature you care about, please do take an hour or two to review the details on our wiki [3], search for older discussions on the mailing lists, and draft the Report changes you think would be necessary. I'm looking forward to a more active and exciting collection of potential language changes for 2012, but it will only happen if you get involved. Regards, Malcolm (Haskell 2011 committee chair) [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html [2] http://www.haskell.org/pipermail/haskell/2010-July/022189.html [3] http://hackage.haskell.org/trac/haskell-prime/

4 5

[Colin Paul Adams] Re: Proposal: Define UTF-8 to be the encoding of Haskell source files
by Colin Paul Adams 07 Apr '11

07 Apr '11

I forgot to CC the list: >>>>> "Roel" == Roel van Dijk <vandijk.roel(a)gmail.com> writes: Roel> I propose to make UTF-8 the only allowed encoding for Haskell Roel> source files. Implementations must discard an initial Byte Roel> Order Mark (BOM) if present [3]. Roel> * Pros - Ensures that Haskell source can be reliably exchanged Roel> on the byte level. - Disallows implicit ISO-8859-* encodings Roel> in source code, ensuring portability. - Little or no Roel> implementation burden for compiler writers. Having thought this over a bit more, I don't think it's a good idea. Allowed? Allowed for what? What does it achieve? Nothing, as far as I can see. Authors will still be able to write their Haskell code in any encoding they like. And any compiler can have a front-end script with an option to specify the encoding used by source files, which simply uses iconv on the fly to translate. I think the real place to mandate UTF-8 would be for Hackage. That's where it matters (an alternative design would be to add an encoding field in the .cabal file, but I don't think this has much merit). -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

5 13

Re: Proposal: Define UTF-8 to be the encoding of Haskell source files
by Doug McIlroy 07 Apr '11

07 Apr '11

This suggestion supposes that every system names files in the same way modulo choice of "directory separator": > To find a source file corresponding to a module name used in an import > declaration, the following mapping from module name to OS file name is > used. The '.' character is mapped to the OS's directory separator > string while all other characters map to themselves. The ".hs" or > ".lhs" extension is added. Where both ".hs" and ".lhs" files exist for > the same module, the ".lhs" one should be used. This supposition is unwarranted. We have all seen relative naming systems that run both ways: a.b.c versus c(b(a)). And Haskellites would simplify the latter to c$b$a. Secondary storage may be organized by files, segments, objects, etc. Combinations of these notions have been created in order to cater for legacy languages that depend on particular models. It is a step too far to try to predict how Haskell modules will be adopted into every possible naming environment. Doug McIlroy

2 1

Proposal: add ghc -fwarn-non-ascii warning flag
by Christian Maeder 07 Apr '11

07 Apr '11

similar in spirit to the -fwarn-tabs warning. C. P.S. In the mean time you may use http://projects.haskell.org/style-scanner/ (Caveat, it crashes on latin1 files when compiled with ghc-6.12 or greater.)

1 0

Re: Proposal: Define UTF-8 to be the encoding of Haskell source files
by Jason Reich 07 Apr '11

07 Apr '11

Tillmann Rendel wrote: > How would that affect the non-code parts of literate Haskell (*.lhs) > files? In particular, would it place any burden on third-party tools > processing these files? lhs2TeX already has limited support for UTF-8 for the rendering of Literate Agda files. Jason

2 1