- Glasgow-haskell-users

Unicode alternative for '..' (ticket #3894)
by Roel van Dijk 21 Apr '10

21 Apr '10

I'm a big fan of the UnicodeSyntax [1] language extension. But I don't particularly like the alternative for the ellipsis '..'. I'm not sure if it was a conscious choice or a mistake to use the '⋯' character. I haven't really encountered that symbol before except for matrices and the like [2]. Therefore I propose to change the character from '⋯' to '…'. I submitted a bug report for this a few weeks ago [3]. Today I attached a patch which implements this change. Here are 4 code snippets for comparison: -- Simple ASCII import Data.Bool ( Bool(..) ) f :: [Int] f = [1, 3 .. 10] ++ [10..100] -- Current situation (MIDLINE HORIZONTAL ELLIPSIS, U+22EF) import Data.Bool ( Bool(⋯) ) f ∷ [Int] f = [1, 3 ⋯ 10] ++ [10⋯100] -- Proposed change (HORIZONTAL ELLIPSIS, U+2026) import Data.Bool ( Bool(…) ) f ∷ [Int] f = [1, 3 … 10] ++ [10…100] -- Another alternative (TWO DOT LEADER, U+2025) import Data.Bool ( Bool(‥) ) f ∷ [Int] f = [1, 3 ‥ 10] ++ [10‥100] The TWO DOT LEADER also looks nice, but I think we must consider more than looks alone (which is a matter of fonts) and take the semantics into account. I would really like some feedback on this since it is a change that breaks backwards compatibility (even though it is a really small change). Regards, Roel van Dijk 1 - http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#u… 2 - http://en.wikipedia.org/wiki/Ellipsis#In_mathematical_notation 3 - http://hackage.haskell.org/trac/ghc/ticket/3894

4 6

Output character encoding for ghc on OpenBSD
by Matthias Kilian 19 Apr '10

19 Apr '10

Hi, as some of you may know, I'm working on an update of OpenBSDs ghc port to 6.12.2, currently chasing down the last remaining testsuite failures. Yesterday, I ran into a problem which I have a fix for, but only a really ugly fix, and I need some opinions of what users would prefer. The problem is that Haskell uses unicode characters internally (ghc itself uses UTF-32 internally, where the endianess depends on the architecture it's running on), and that any Haskell program (including ghc and ghci) has to convert between the internal representation and the actual locale settings of the system it's running on. Unfortunately, OpenBSD is really bad if it comes to locale support; the only supported locales are the C and the POSIX locales, so even if you set LC_ALL or LC_CTYPE to something like, for example, de_DE.iso88591, this would have no effect on OpenBSD. Anyway, the short story is that I have to either hard-code the character set to something like utf-8, or ghc will start to behave really strange (for example, ghci would terminate immediately if you just *type* a non-ASCII character). So what would you prefer? - Use utf-8 and only utf-8 (i.e. hardcoded)? - Use something like iso-8859-15 (hardcoded)? - Make it configurable via some non-standard environment variable (GHC_CODESET, for example). If so, what should be the default if the environment variable isn't set? Back to 7 bit (ASCII)? utf-8? Some of the latin variants? Your suggestions are appreciated. Thanks in advance. Ciao, Kili

3 4

Encountered absent arg
by Louis Wasserman 19 Apr '10

19 Apr '10

Yo, I didn't find many references to this on Google except a 2001 message saying "Send this problem to us!" I don't know what's changed since then, so I'll poke the list: I compiled my code with -fdicts-strict. (Why is this not a mainstream thing? It eliminates gratuitous polymorphism overhead, which is one of my biggest sources of angst!) Looking at ghc-core, my code appears to *always* give the exception "Oops! Entered absent arg ww_s9eC{v} [lid] <pred>main:Data.Algebra.Ring.Ring{tc r2tU} c{tv a8Os} [tv]" Is this typical? Where should I send this? Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

4 4

"ld" memory usage
by Roman Beslik 18 Apr '10

18 Apr '10

Hi. This is not strictly a GHC question. I observed that "ld" when linking GHC-compiled programs eats 0.5 GB of resident memory. ~3 times more than GHC or Haddock. So if there is not enough free memory "ld" uses virtual memory and works very slowly (practically does not use CPU). I'd like to know, is anyone interested in researching and improving memory usage? Is it "ld" or GHC problem? I found a similar discussion here http://article.gmane.org/gmane.comp.lang.haskell.cafe/66189 but it was too broad and went nowhere. -- Best regards, Roman Beslik.

4 5

Literate files in the GHC source
by Tyson Whitehead 17 Apr '10

17 Apr '10

I'm just wondering how exactly are the literate files in the GHC source suppose to be treated. I would like to read some of the documentation. The presence of various latex commands such as subsection strongly suggests they are done in latex. Running pdflatex, however, doesn't work. Nor does created a wrapper latex file to define the document class, the code environment, etc., as it then bombs out on such things as non-escaped '#'s. I searched around on the Internet and mailing list archives didn't seem to find anything. If I had to guess, I would suspect it started as actually latex documentation, but has fallen into a state of disrepair. Is this correct? Thanks! -Tyson

2 1

Re: Can't install Criterion package on ghc ..
by John Lato 17 Apr '10

17 Apr '10

> From: Mozhgan kabiri <mozhgan.kabiri(a)gmail.com> > > Hi, > > I am trying to install Criterion package, but I keep getting an error and I > can't figure it out why it is like this !! > > mozhgan@Mozhgan-KCh:~$ cabal install Criterion > Resolving dependencies... > Configuring vector-algorithms-0.3... > Preprocessing library vector-algorithms-0.3... > Building vector-algorithms-0.3... ... > [8 of 9] Compiling Data.Vector.Algorithms.Intro ( > Data/Vector/Algorithms/Intro.hs, dist/build/Data/Vector/Algorithms/Intro.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.4 for i386-unknown-linux): > idInfo co{v a9WB} [tv] This is definitely a bug in GHC, most likely related to type families and fixed in GHC-6.12.x If you can upgrade to ghc-6.12.1, that should solve this problem. If you need to remain on ghc-6.10.4, try installing an older version of criterion. You can do this with 'cabal install criterion-0.4.1.0' Criterion-0.5 is the first version to depend upon vector-algorithms, so any previous version has a chance of working. John

6 8

Using -fext-core without a Main function
by Hal Daume III 16 Apr '10

16 Apr '10

If I have a file 'Foo.hs' that contains one line 'addOne x = x + 1', I want to run something like: ghc -c -fext-core Foo.hs to get the core version of this file. Unfortunately, when I do that, it complains that Main doesn't have a function main. And it doesn't produce the .hcr file. I tried adding -no-hs-main but that doesn't help. I can add 'main = undefined' to Foo.hs, but then the core file doesn't contain the declaration of addOne because it's not used. Any suggestions? Thanks! -h -- Hal Daume III --- me AT hal3 DOT name | http://www DOT hal3 DOT name "Arrest this man, he talks in maths." | http://nlpers.blogspot.com

3 3

ANNOUNCE: GHC 6.12.2 Release Candidate 1
by Ian Lynagh 16 Apr '10

16 Apr '10

Hi all, We are pleased to announce the first release candidate for GHC 6.12.2: http://www.haskell.org/ghc/dist/6.12.2-rc1/ As well as the source tarball: ghc-6.12.1.20100330-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

4 5

interaction of GADTs and data families: a bug?
by Sebastian Fischer 16 Apr '10

16 Apr '10

Dear GHC experts, Certain behaviour when using {-# LANGUAGE GADTs, TypeFamilies #-} surprises me. The following is accepted by GHC 6.12.1: data GADT a where BoolGADT :: GADT Bool foo :: GADT a -> a -> Int foo BoolGADT True = 42 But the following is not: data family DataFam a data instance DataFam Bool where BoolDataFam :: DataFam Bool fffuuuu :: DataFam a -> a -> Int fffuuuu BoolDataFam True = 42 GHC 6.12.1 throws the following error (GHC 6.10.4 panics): Couldn't match expected type `a' against inferred type `Bool' `a' is a rigid type variable bound by the type signature for `fffuuuu' at gadtDataFam.hs:13:19 In the pattern: BoolDataFam In the definition of `fffuuuu': fffuuuu BoolDataFam True = 42 I expect that `fffuuuu` should be accepted just like `foo`. Do I expect too much? Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

5 10

Advice on Multiple GHC installations
by Bradford Larsen 16 Apr '10

16 Apr '10

I would like to have several versions of ghc installed simultaneously, on the handful of Ubuntu systems I work on. In the past, I have had just a single version of ghc installed on each system, usually the most recent stable generic Linux binary installation. Three questions: 1. Does there exist an `experimental' apt repository for Ubuntu anywhere which packages versions of ghc more recent than 6.8? 2. If I cannot install multiple ghc versions from a different apt repository, does anyone have advice for how to work with multiple simultaneous installations? A how-to guide or anything like that? 3. Does having multiple installations break cabal at all? I'd like to be able to use ghc 6.12.* by default, but be able to selectively choose an older toolchain for compatibility purposes, bug hunting, etc. Thanks! Sincerely, Brad

5 7