- Glasgow-haskell-users

New GHC Features for 7.10.1 and Beyond
by Gershom Bazerman 01 Apr '14

01 Apr '14

There's been lots of exciting work going into the forthcoming GHC 7.8.1 release. But even with all these new features, our language is far from complete and I wouldn't want the GHC team to rest on their laurels. Especially with so much renewed community involvement in GHC development, it seems appropriate to share some ideas some of us have been discussing for future releases, and take a poll of community consensus regarding which ones people might be excited to jump in and help out with, or might find particularly helpful. One important area that needs work is exceptions. These are famously difficult, and many libraries have been written to provide checked exceptions, or unify error and exceptions in various ways. It seems to me that the problem, all along, has been that we've decided to give Haskell _imprecise exceptions_ with special semantics. It would alleviate a great deal of confusion if we implemented a -fprecise-exceptions flag that remedied this. Additionally, while we have long known that Haskell is not a "lazy" language but a "non-strict" one, our leading compiler only rarely takes advantage of this. It is well known that for every program there is a reduction strategy that preserves non-strict semantics while using as few reductions as possible. This is known as the "optimal reduction" strategy, and it is calculable and well understood. We should put some work into a -foptimal-reduction flag. Another important area of research is quantum computation. The D-Wave Two, with 512 qbits, is a commercially available quantum computer now deployed in a few leading institutions. As more and more people begin to purchase D-Wave systems for home hacking, every language worth its salt will need to be able to target this system. Now that cross compilation is more fully supported, it would be good to start putting work into a dwave backend. We've also seen a lot of interest in distribution and cloud computing. From the articles I've read, efficient concurrent programming involves using node.js, so I think we should put some work into writing a new-new-new-IO Manager built on top of this technology. Furthermore, it's ridiculous that while Haskell allows simple concurrent and distributed programming, it offers no simple way to set up a distributed environment. Work should be put into a compiler mode that provisions cloud resources automatically and distributes the target binary among them, with a flag such as: -fvia-s3 _credit_card_number_ There are a few cases where a good idea in GHC can be taken further, and I don't know why we haven't tried already. For example, we've found that despite introducing some occasional problems, the state hack also has drastically improved performance. Since it works so well, we should provide a dual to -fno-state-hack, -fmore-state-hack, for those who really need every last drop of performance. Similarly, now we have type holes that let us see what types should be inserted in various spots. -fvalue-holes is the next logical step, to tell us what terms we should be writing. Also, while we've put so much emphasis on correctness, we've also loosened the bolts optionally the other way, with flags such as -XIncoherentInstances. Along the same lines, I would like to introduce -XImpossibleInstances to let us express such useful things as "instance Int String," "instance IO Comonad," and "instance data if". -fdefer-type-errors allows us to defer type errors to runtime. Having spent some time with JavaScript lately, I think this doesn't go nearly far enough. It would be good to run programs with other sorts of problems as well, for educational purposes and for quick hacking. So work should be put into a -fdefer-scope-errors flag, as well as -fon-error-resume-next, which has done wonders for the resilience of Visual Basic code (see also the wildly useful ability to set the top level error handler in PHP). With all these features put together, we have a powerful new way to approach Haskell programming, and it would be good to enable them by default on .ilhs files (illiterate haskell). It also was pointed out to me recently by Jason Dagit that while we have had debates and confusion over closed and open type families and functions for years, topologists have solved this problem elegantly. With some basic point set topology under one's belt, a -XClopenTypeFamilies extension seems almost trivial to implement. Finally, I'm very sorry to see that my proposal for youtube syntax has languished, and I hope it can be revived: http://www.haskell.org/pipermail/haskell-cafe/2012-April/100527.html HTH HAND, Gershom

5 4

Haskell Support on Windows
by harry 01 Apr '14

01 Apr '14

I've been getting the impression that a lot of the stickier GHC bugs are Windows specific, while very few GHC hackers actually use Windows, other than to ensure that GHC works on it. Windows is already somewhat of a second-class citizen in Hackage, where platform-sensitive packages tend to only work out-of-the box on Linux. Perhaps it should be "demoted" to second-tier GHC support as well, at least to the extent that Windows bugs won't hold up a release? (I write this as a Windows user who also manages some Linux servers. I agree that Windows support is important, but it seems to be unreasonably "taking" far more than it "gives".) -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Support-on-Windows-tp5746711.h… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 1

SV: Haskell Support on Windows
by Niklas Larsson 31 Mar '14

31 Mar '14

Seems to me that a less pessimistic solution would be to set up a windows buildbot. Niklas ----- Ursprungligt meddelande ----- Från: "harry" <voldermort(a)hotmail.com> Skickat: ‎2014-‎03-‎31 14:27 Till: "glasgow-haskell-users(a)haskell.org" <glasgow-haskell-users(a)haskell.org> Ämne: Haskell Support on Windows I've been getting the impression that a lot of the stickier GHC bugs are Windows specific, while very few GHC hackers actually use Windows, other than to ensure that GHC works on it. Windows is already somewhat of a second-class citizen in Hackage, where platform-sensitive packages tend to only work out-of-the box on Linux. Perhaps it should be "demoted" to second-tier GHC support as well, at least to the extent that Windows bugs won't hold up a release? (I write this as a Windows user who also manages some Linux servers. I agree that Windows support is important, but it seems to be unreasonably "taking" far more than it "gives".) -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Support-on-Windows-tp5746711.h… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

Haskell Weekly News
by harry 31 Mar '14

31 Mar '14

There hasn't been a HWN since mid-December. I've emailed the editor with no response, and there doesn't seem to have been any (public) online activity from him since. I hope he's OK, but either way, it seems that HWN needs a new editor. Any volunteers? -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Weekly-News-tp5746682.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

1 0

Module that causes GHC-7.8 to exhaust memory when -O2 is on
by David Fox 30 Mar '14

30 Mar '14

The repository at http://src.seereason.com/o2bug contains a package that causes GHC-7.8.1 (rc2?) to exhaust 16GB of RAM and die when the -O2 flag is turned on. I haven't been able to simplify it very much, almost any change to JSON.Render causes it to start working properly. I did get it to fail using only packages available in hackage. Just thought I should let folks know about this issue. Let me know if it fails to fail. Maybe someone who can log in could put this in trac.

2 2

positive type-level naturals
by Henning Thielemann 19 Mar '14

19 Mar '14

Am 16.03.2014 09:40, schrieb Christiaan Baaij: > To answer the second question (under the assumption that you want > phantom-type style Vectors and not GADT-style): Now I like to define non-empty vectors. The phantom parameter for the length shall refer to the actual vector length, not to length-1, for consistency between possibly empty and non-empty vectors. I have modified your code as follows: {-# LANGUAGE Rank2Types #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} module PositiveNat where import Data.Proxy (Proxy(Proxy)) import GHC.TypeLits (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal, type (<=), type (+)) data Vector (n :: Nat) a = Vector a [a] withVector :: forall a b. a -> [a] -> (forall n . (KnownNat n, 1<=n) => Vector n a -> b) -> b withVector x xs f = case someNatVal $ toInteger $ length xs of Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m+1) a) vecLen :: forall n . KnownNat n => Vector n Integer -> Integer vecLen _ = natVal (Proxy :: Proxy n) -- > withVector vecLen [1,2,3,4] -- 4 GHC-7.8 complains with: PositiveNat.hs:23:40: Could not deduce ((1 GHC.TypeLits.<=? (n + 1)) ~ 'True) from the context (KnownNat n) bound by a pattern with constructor SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> SomeNat, in a case alternative at PositiveNat.hs:23:13-34 In the expression: f (Vector x xs :: Vector (m + 1) a) In a case alternative: Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) In the expression: case someNatVal $ toInteger $ length xs of { Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) } How can I convince GHC that n+1 is always at least 1? When I remove the (1<=n) constraint, I still get: PositiveNat.hs:23:40: Could not deduce (KnownNat (n + 1)) arising from a use of ‘f’ from the context (KnownNat n) bound by a pattern with constructor SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> SomeNat, in a case alternative at PositiveNat.hs:23:13-34 In the expression: f (Vector x xs :: Vector (m + 1) a) In a case alternative: Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) In the expression: case someNatVal (toInteger (length xs)) of { Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) } That is, I also have to convince GHC, that if (KnownNat n) then (n+1) is also KnownNat. How to do that?

6 16

Mac CPP problem with ghc-clang-wrapper
by Christian Maeder 18 Mar '14

18 Mar '14

Hi, under mavericks using the ghc-clang-wrapper (ghc-7.6) or using ghc-7.8.20140130 I can no longer install the HaXml package. The source line: putStrLn $ "part of HaXml-"++show MAJOR.MINOR seems to put spaces around the decimal point between MAJOR and MINOR and fails as shown below. Is this already a known problem? Cheers Christian [14 of 42] Compiling Text.XML.HaXml.Wrappers ( src/Text/XML/HaXml/Wrappers.hs, dist/build/Text/XML/HaXml/Wrappers.o ) src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match type ‛[Char]’ with ‛b0 -> c0’ Expected type: b0 -> c0 Actual type: String Possible cause: ‛show’ is applied to too many arguments In the first argument of ‛(.)’, namely ‛show 1’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match expected type ‛[Char]’ with actual type ‛a0 -> c0’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ In the second argument of ‛($)’, namely ‛"part of HaXml-" ++ show 1 . 24’ In a stmt of a 'do' block: putStrLn $ "part of HaXml-" ++ show 1 . 24 Failed to install HaXml-1.24

2 1

importing (<=) from GHC.TypeLits
by Henning Thielemann 17 Mar '14

17 Mar '14

I want to import Nat and type-level (<=) from GHC.TypeLits: import GHC.TypeLits (Nat, (<=)) "Nat" is found this way, but (<=) is not: Module ‘GHC.TypeLits’ does not export ‘(<=)’ What is the trick? The doc only shows the anonymous import: http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/promotion.html

5 6

type-level induction on Nat
by Henning Thielemann 17 Mar '14

17 Mar '14

Am 16.03.2014 09:40, schrieb Christiaan Baaij: > To answer the second question (under the assumption that you want > phantom-type style Vectors and not GADT-style): That works, someNatVal was the missing piece. Now the natural next question is how to perform type-level induction on Nat. This page mentions the Nat1 type, a unary representation of natural numbers: https://ghc.haskell.org/trac/ghc/wiki/TypeNats/MatchingOnNats Since the unary natural number kind so ubiquituous in examples, is there a recommended module to import it from, which also contains the injectivity magic of FromNat1? I cannot see it in: http://hackage.haskell.org/package/base-4.7.0.0/candidate/docs/GHC-TypeLits… although it seems to have been there: http://co-dan.github.io/base-docs/src/GHC-TypeLits.html

2 2

splicing varPs in quasi-quote brackets
by Christian Höner zu Siederdissen 17 Mar '14

17 Mar '14

Hello everybody, I wrote me this nice function 'buildRns' which splices in $(varP w) nice and recursively. Unfortunately, this only seems to work in the 7.8 branch, not in 7.6.3. Is this indeed new, or am I missing something obvious? The message is: ADP/Fusion/TH.hs:106:86: Parse error in pattern: $(varP w) The code works wonderfully in 7.8. It not only compiles, but also produces working code in applications. I have no problem waiting until 7.8 is stable, but being backwards compatible to 7.6 would be nice. Many thanks, Christian buildRns f xs [] = appE ([| return . SM.singleton |]) (foldl (\g z -> appE g (varE z)) (return f) xs) buildRns f xs (VarP v : ys) = buildRns f (xs++[v]) ys buildRns f xs (TupP [_,VarP v] : ys) = do w <- newName "w" [| $(varE v) >>= return . SM.concatMapM (\ $(varP w) -> $(buildRns f (xs++[w]) ys)) |] -->>>>> ^^^^^^^^^

4 4