- Glasgow-haskell-users

GHC API: getting the unfolding of a "strange" Id
by Christiaan Baaij 04 Apr '14

04 Apr '14

Dear list, I'm using the GHC API to get Core Expressions from haskell interface (.hi) files, and have encountered a strange kind of 'Id' for which I can't seem to get the unfolding: The properties of this 'Id' are the following: - varName: $fNumFixed2 - IdDetails: VannillaId - Pretty print of IdInfo.inlinePragInfo: [Always] - IdInfo.unfoldingInfo: NoUnfolding The source file which gives rise to this 'Id' is: https://github.com/christiaanb/clash-prelude/blob/master/src/CLaSH/Sized/Fi… As you can see, the file is compiled with: -fexpose-all-unfoldings The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function, so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'. Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would expect to have a usable 'Unfolding' in general. How can GHC inline the body of this 'Id' if it has no unfolding? Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the $fNumFixed2 'Id' is no longer included in the interface file. At positions where "$fNumFixed2" was originally used, a equality constraint can eventually be found: Using -O: (CLaSH.Sized.Fixed.$fNumFixed2 @(GHC.TypeLits.+ 4 4) Using -O0 -fno-omit-interface-pragmas: (GHC.Types.Eq# @GHC.Types.Bool @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4)) @GHC.Types.True _CO_) So my question is, what kind of "strange" 'Id' is this $fNumFixed2? And how can I get the Core expression for this 'Id' from the interface file? And if I can't get it from the interface file, is there a straightforward way to generate it from the 'Id'? Cheers, Christiaan

2 6

Bang Patterns
by Dan Doel 03 Apr '14

03 Apr '14

Greetings, I've been thinking about bang patterns as part of implementing our own Haskell-like compiler here, and have been testing out GHC's implementation to see how it works. I've come to one case that seems like it doesn't work how I think it should, or how it is described, and wanted to ask about it. Specifically, consider: case Nothing of !(~(Just x)) -> 5 Nothing -> 12 Now, the way I'd expect this to work, and how I think the spec says it works, is that my Nothing is evaluated, and then the irrefutable ~(Just x) matches Nothing, giving a result of 5. In fact, GHC warns about overlapping patterns for this. However, this actually evaluates to 12, meaning that !(~p) appears to cancel out and be equivalent to p. It seems to me this might be a side effect of the logic used to implement 'let !p = ...', but I'm not certain. So, my question is whether this is intentional. If it is, then the bang patterns description should probably mention it, since it's subtly different than the rest of the specification. Also the warning should be removed, because there is no overlapping in the above case statement. If it is unintentional, we should probably decide either to make it intentional (and perform the above changes), or to change the implementation. :) Cheers, -- Dan

2 2

Eta Reduction
by Dan Doel 02 Apr '14

02 Apr '14

In the past year or two, there have been multiple performance problems in various areas related to the fact that lambda abstraction is not free, though we tend to think of it as so. A major example of this was deriving of Functor. If we were to derive Functor for lists, we would end up with something like: instance Functor [] where fmap _ [] = [] fmap f (x:xs) = f x : fmap (\y -> f y) xs This definition is O(n^2) when fully evaluated,, because it causes O(n) eta expansions of f, so we spend time following indirections proportional to the depth of the element in the list. This has been fixed in 7.8, but there are other examples. I believe lens, [1] for instance, has some stuff in it that works very hard to avoid this sort of cost; and it's not always as easy to avoid as the above example. Composing with a newtype wrapper, for instance, causes an eta expansion that can only be seen as such at the core level. The obvious solution is: do eta reduction. However, this is not operationally sound currently. The problem is that seq is capable of telling the difference between the following two expressions: undefined \x -> undefined x The former causes seq to throw an exception, while the latter is considered defined enough to not do so. So, if we eta reduce, we can cause terminating programs to diverge if they make use of this feature. Luckily, there is a solution. Semantically one would usually identify the above two expressions. While I do believe one could construct a semantics that does distinguish them, it is not the usual practice. This suggests that there is a way to not distinguish them, perhaps even including seq. After all, the specification of seq is monotone and continuous regardless of whether we unify ⊥ with \x -> ⊥ x or insert an extra element for the latter. The currently problematic case is function spaces, so I'll focus on it. How should: seq : (a -> b) -> c -> c act? Well, other than an obvious bottom, we need to emit bottom whenever our given function is itself bottom at every input. This may first seem like a problem, but it is actually quite simple. Without loss of generality, let us assume that we can enumerate the type a. Then, we can feed these values to the function, and check their results for bottom. Conal Elliot has prior art for this sort of thing with his unamb [2] package. For each value x :: a, simply compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find one, we know the function is non-bottom, and we can return our value of c. If we never finish searching, then the function must be bottom, and seq should not terminate, so we have satisfied the specification. Now, some may complain about the enumeration above. But this, too, is a simple matter. It is well known that Haskell programs are denumerable. So it is quite easy to enumerate all Haskell programs that produce a value, check whether that value has the type we're interested in, and compute said value. All of this can be done in Haskell. Thus, every Haskell type is programatically enumerable in Haskell, and we can use said enumeration in our implementation of seq for function types. I have discussed this with Russell O'Connor [3], and he assures me that this argument should be sufficient even if we consider semantic models of Haskell that contain values not denoted by any Haskell program, so we should be safe there. The one possible caveat is that this implementation of seq is not operationally uniform across all types, so the current fully polymorphic type of seq may not make sense. But moving back to a type class based approach isn't so bad, and this time we will have a semantically sound backing, instead of just having a class with the equivalent of the current magic function in it. Once this machinery is in place, we can eta reduce to our hearts' content, and not have to worry about breaking semantics. We'd no longer put the burden on programmers to use potentially unsafe hacks to avoid eta expansions. I apologize for not sketching an implementation of the above algorithm, but I'm sure it should be elementary enough to make it into GHC in the next couple versions. Everyone learns about this type of thing in university computer science programs, no? Thoughts? Comments? Questions? Cheers, -- Dan [1] http://hackage.haskell.org/package/lens [2] http://hackage.haskell.org/package/unamb [3] http://r6.ca/

4 6

Buildbots
by harry 01 Apr '14

01 Apr '14

It having been suggested that a buildbot for Windows may be needed, and it being possible that I may receive permission from management for setting one up in my department's server room, I set about attempting to discover what this actually entails. A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, which tells me that "Buildbot is currently down, and we are working on a replacement. See Builder for more details." If I follow the 'down' link , I get to the GHC status April 2010 page, which says that buildbot has been abandoned, suggesting that the page should be deleted. Could someone confirm before I go ahead and delete it? The Builder page has clear instructions on how to set up a build slave, and a link to the build results. The build results contains an assortment of dud links and builds from August and earlier. What is the current state of automated builds? -- View this message in context: http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

9 20

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