- ghc-devs - Haskell.org

RE: [commit: ghc] wip/oneShot: Avoid inlining oneShot in unfoldings (16066a1)
by Simon Peyton Jones 27 Oct '14

27 Oct '14

| Avoid inlining oneShot in unfoldings I'm sure there's a reason for this but, again, please say what is, lest I accidentally reverse it in 3 years time. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 25 October 2014 13:59 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/oneShot: Avoid inlining oneShot in unfoldings | (16066a1) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/oneShot | Link : | http://ghc.haskell.org/trac/ghc/changeset/16066a165dd7245be58d0fbee265e13 | fb21e2aed/ghc | | >--------------------------------------------------------------- | | commit 16066a165dd7245be58d0fbee265e13fb21e2aed | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Sat Oct 25 14:46:27 2014 +0200 | | Avoid inlining oneShot in unfoldings | | | >--------------------------------------------------------------- | | 16066a165dd7245be58d0fbee265e13fb21e2aed | compiler/basicTypes/MkId.lhs | 4 ++-- | 1 file changed, 2 insertions(+), 2 deletions(-) | | diff --git a/compiler/basicTypes/MkId.lhs b/compiler/basicTypes/MkId.lhs | index 05dcdd5..31cd426 100644 | --- a/compiler/basicTypes/MkId.lhs | +++ b/compiler/basicTypes/MkId.lhs | @@ -1124,8 +1124,8 @@ lazyId = pcMiscPrelId lazyIdName ty info | oneShotId :: Id | oneShotId = pcMiscPrelId oneShotName ty info | where | - info = noCafIdInfo `setInlinePragInfo` alwaysInlinePragma | - `setUnfoldingInfo` mkCompulsoryUnfolding rhs | + info = noCafIdInfo -- `setInlinePragInfo` alwaysInlinePragma | + `setUnfoldingInfo` mkWwInlineRule rhs 1 | ty = mkForAllTys [alphaTyVar, betaTyVar] (mkFunTy fun_ty fun_ty) | fun_ty = mkFunTy alphaTy betaTy | [body, x] = mkTemplateLocals [fun_ty, alphaTy] | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

GHC on mingw-w64 / gcc 4.8.3 on Windows
by Gintautas Miliauskas 27 Oct '14

27 Oct '14

The patch to migrate to mingw-w64 / gcc 4.8.3 is finally starting to look reasonable (Phab:D339 <https://phabricator.haskell.org/D339>). Whew! The part about downloading the tarball was relatively straightforward, but the mingw migration has been really tricky, in part due to the gcc version bump, but mostly, I think, due to use of mingw-w64 on i686 as well (which is a supported configuration). In particular, "#define _MSVCRT_ 1" took ages to figure out after digging through heaps of headers and weird errors. I am not sure I would have signed on if I had an idea of how much effort this needed... Jeez. On the bright side, now that we have standartised on mingw-w64, further gcc version upgrades should be relatively straightforward. Could people with some experience in Windows matters take a look at the patch? In particular, rts/Linker.c has been a problem; my fixes there seem to work but I have no idea if the approach is right (the whole file does seem like a grabbag of ad-hocness though). The patch also could use some more testing (both for x86 and for x86-64). There are still some validate.sh failures (although I am actually seeing fewer than with the legacy setup), some of which could probably be fixed easily. Some additional eyes and fingers on keyboards would be very welcome there. If you want to experiment with the patch, make sure to also patch in the related changes listed in the last comment on the Phab page. -- Gintautas Miliauskas

4 5

Re: Call Arity, oneShot, or both
by David Feuer 27 Oct '14

27 Oct '14

Joachim Breitner כתב That would be great! But do we have evidence of this user-written code > that benefits? So far I have only seen relevant improvement due to > list-fusion a left-foldish function. > I was under the impression that the transformation was much more general than that, improving various recursive forms. Was I wrong? But aside from that, I would be astonished if the library authors were the only ones writing left-accumulating folds! David

2 1

RE: [commit: ghc] wip/oneShot: Use oneShot in the definition of foldl etc. (6f101d2)
by Simon Peyton Jones 26 Oct '14

26 Oct '14

No Notes! Surely, surely it deserves one! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 25 October 2014 11:27 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/oneShot: Use oneShot in the definition of | foldl etc. (6f101d2) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/oneShot | Link : | http://ghc.haskell.org/trac/ghc/changeset/6f101d20805fb52de0423bc8beab373 | b94bd4a7d/ghc | | >--------------------------------------------------------------- | | commit 6f101d20805fb52de0423bc8beab373b94bd4a7d | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Sat Oct 25 12:27:06 2014 +0200 | | Use oneShot in the definition of foldl etc. | | | >--------------------------------------------------------------- | | 6f101d20805fb52de0423bc8beab373b94bd4a7d | libraries/base/Data/OldList.hs | 5 +++-- | libraries/base/GHC/List.lhs | 6 +++--- | 2 files changed, 6 insertions(+), 5 deletions(-) | | diff --git a/libraries/base/Data/OldList.hs | b/libraries/base/Data/OldList.hs | index 0e6709e..75fba35 100644 | --- a/libraries/base/Data/OldList.hs | +++ b/libraries/base/Data/OldList.hs | @@ -499,7 +499,8 @@ pairWithNil x = (x, []) | | mapAccumLF :: (acc -> x -> (acc, y)) -> x -> (acc -> (acc, [y])) -> acc | -> (acc, [y]) | {-# INLINE [0] mapAccumLF #-} | -mapAccumLF f = \x r s -> let (s', y) = f s x | +mapAccumLF f = \x r -> oneShot $ \s -> | + let (s', y) = f s x | (s'', ys) = r s' | in (s'', y:ys) | | @@ -1058,7 +1059,7 @@ unfoldr f b0 = build (\c n -> | | -- | A strict version of 'foldl'. | foldl' :: forall a b . (b -> a -> b) -> b -> [a] -> b | -foldl' k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> z `seq` fn (k z v)) | (id :: b -> b) xs z0 | +foldl' k z0 xs = foldr (\(v::a) (fn::b->b) -> oneShot (\(z::b) -> z | `seq` fn (k z v))) (id :: b -> b) xs z0 | -- Implementing foldl' via foldr is only a good idea if the compiler can | optimize | -- the resulting code (eta-expand the recursive "go"), so this needs - | fcall-arity! | -- Also see #7994 | diff --git a/libraries/base/GHC/List.lhs b/libraries/base/GHC/List.lhs | index 2d01678..c7a0cb3 100644 | --- a/libraries/base/GHC/List.lhs | +++ b/libraries/base/GHC/List.lhs | @@ -186,7 +186,7 @@ filterFB c p x r | p x = x `c` r | | foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b | {-# INLINE foldl #-} | -foldl k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id :: b | -> b) xs z0 | +foldl k z0 xs = foldr (\(v::a) (fn::b->b) -> oneShot (\(z::b) -> fn (k z | v))) (id :: b -> b) xs z0 | -- Implementing foldl via foldr is only a good idea if the compiler can | optimize | -- the resulting code (eta-expand the recursive "go"), so this needs - | fcall-arity! | -- Also see #7994 | @@ -221,7 +221,7 @@ scanl = scanlGo | | {-# INLINE [0] scanlFB #-} | scanlFB :: (b -> a -> b) -> (b -> c -> c) -> a -> (b -> c) -> b -> c | -scanlFB f c = \b g x -> let b' = f x b in b' `c` g b' | +scanlFB f c = \b g -> oneShot (\x -> let b' = f x b in b' `c` g b') | | {-# INLINE [0] constScanl #-} | constScanl :: a -> b -> a | @@ -258,7 +258,7 @@ scanl' = scanlGo' | | {-# INLINE [0] scanlFB' #-} | scanlFB' :: (b -> a -> b) -> (b -> c -> c) -> a -> (b -> c) -> b -> c | -scanlFB' f c = \b g x -> let b' = f x b in b' `seq` b' `c` g b' | +scanlFB' f c = \b g -> oneShot (\x -> let b' = f x b in b' `seq` b' `c` | g b') | | {-# INLINE [0] flipSeqScanl' #-} | flipSeqScanl' :: a -> b -> a | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

RE: [commit: ghc] wip/oneShot: Add GHC.Prim.oneShot (955d9f5)
by Simon Peyton Jones 26 Oct '14

26 Oct '14

Is all this one-shot stuff carefully documented somewhere? I think it's basically a good plan, but I see no Notes, alas. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 25 October 2014 11:27 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/oneShot: Add GHC.Prim.oneShot (955d9f5) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/oneShot | Link : | http://ghc.haskell.org/trac/ghc/changeset/955d9f53b6c934585a90423dfc95d86 | d8a129908/ghc | | >--------------------------------------------------------------- | | commit 955d9f53b6c934585a90423dfc95d86d8a129908 | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Sun Jan 26 11:36:23 2014 +0000 | | Add GHC.Prim.oneShot | | Conflicts: | compiler/basicTypes/MkId.lhs | | | >--------------------------------------------------------------- | | 955d9f53b6c934585a90423dfc95d86d8a129908 | compiler/basicTypes/MkId.lhs | 17 +++++++++++++++-- | compiler/prelude/PrelNames.lhs | 3 ++- | 2 files changed, 17 insertions(+), 3 deletions(-) | | diff --git a/compiler/basicTypes/MkId.lhs b/compiler/basicTypes/MkId.lhs | index bf1c199..05dcdd5 100644 | --- a/compiler/basicTypes/MkId.lhs | +++ b/compiler/basicTypes/MkId.lhs | @@ -135,7 +135,8 @@ ghcPrimIds | seqId, | magicDictId, | coerceId, | - proxyHashId | + proxyHashId, | + oneShotId | ] | \end{code} | | @@ -1016,7 +1017,7 @@ another gun with which to shoot yourself in the | foot. | \begin{code} | lazyIdName, unsafeCoerceName, nullAddrName, seqName, | realWorldName, voidPrimIdName, coercionTokenName, | - magicDictName, coerceName, proxyName, dollarName :: Name | + magicDictName, coerceName, proxyName, dollarName, oneShotName :: Name | unsafeCoerceName = mkWiredInIdName gHC_PRIM (fsLit "unsafeCoerce#") | unsafeCoerceIdKey unsafeCoerceId | nullAddrName = mkWiredInIdName gHC_PRIM (fsLit "nullAddr#") | nullAddrIdKey nullAddrId | seqName = mkWiredInIdName gHC_PRIM (fsLit "seq") | seqIdKey seqId | @@ -1028,6 +1029,7 @@ magicDictName = mkWiredInIdName gHC_PRIM | (fsLit "magicDict") magicDict | coerceName = mkWiredInIdName gHC_PRIM (fsLit "coerce") | coerceKey coerceId | proxyName = mkWiredInIdName gHC_PRIM (fsLit "proxy#") | proxyHashKey proxyHashId | dollarName = mkWiredInIdName gHC_BASE (fsLit "$") | dollarIdKey dollarId | +oneShotName = mkWiredInIdName gHC_PRIM (fsLit "oneShot") | oneShotKey oneShotId | \end{code} | | \begin{code} | @@ -1119,6 +1121,17 @@ lazyId = pcMiscPrelId lazyIdName ty info | info = noCafIdInfo | ty = mkForAllTys [alphaTyVar] (mkFunTy alphaTy alphaTy) | | +oneShotId :: Id | +oneShotId = pcMiscPrelId oneShotName ty info | + where | + info = noCafIdInfo `setInlinePragInfo` alwaysInlinePragma | + `setUnfoldingInfo` mkCompulsoryUnfolding rhs | + ty = mkForAllTys [alphaTyVar, betaTyVar] (mkFunTy fun_ty fun_ty) | + fun_ty = mkFunTy alphaTy betaTy | + [body, x] = mkTemplateLocals [fun_ty, alphaTy] | + x' = setOneShotLambda x | + rhs = mkLams [alphaTyVar, betaTyVar, body, x'] $ Var body `App` Var | x | + | | ------------------------------------------------------------------------ | -------- | magicDictId :: Id -- See Note [magicDictId magic] | diff --git a/compiler/prelude/PrelNames.lhs | b/compiler/prelude/PrelNames.lhs | index e053b11..e2ade33 100644 | --- a/compiler/prelude/PrelNames.lhs | +++ b/compiler/prelude/PrelNames.lhs | @@ -1682,10 +1682,11 @@ rootMainKey, runMainKey :: Unique | rootMainKey = mkPreludeMiscIdUnique 101 | runMainKey = mkPreludeMiscIdUnique 102 | | -thenIOIdKey, lazyIdKey, assertErrorIdKey :: Unique | +thenIOIdKey, lazyIdKey, assertErrorIdKey, oneShotKey :: Unique | thenIOIdKey = mkPreludeMiscIdUnique 103 | lazyIdKey = mkPreludeMiscIdUnique 104 | assertErrorIdKey = mkPreludeMiscIdUnique 105 | +oneShotKey = mkPreludeMiscIdUnique 106 | | breakpointIdKey, breakpointCondIdKey, breakpointAutoIdKey, | breakpointJumpIdKey, breakpointCondJumpIdKey, | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Re: Call Arity, oneShot, or both
by David Feuer 26 Oct '14

26 Oct '14

> There is also the option of combining both. Then we do not get the > regression, but still the improvement for fft2: I *definitely* think we should leave Call Arity in place by default unless and until something strictly better comes along. One very nice feature is that it works for a lot of user-written code of various kinds without the user having to do *anything* special. oneShot seems more limited in applicability, for use primarily in library code. So I would personally think that it should be added, with an option, of course, to turn it off. I would also go for documenting it as experimental and provisional. David

2 1

old-time.git/tests/time004.hs is DST-sensitive :-/
by Herbert Valerio Riedel 26 Oct '14

26 Oct '14

Hi *, if anyone wonders, why TEST=time004 suddenly fails: it's sensitive to DST (and depends on your system's TZ-config): http://git.haskell.org/packages/old-time.git/blob/HEAD:/tests/time004.hs For me, the comparison this unit-test checks now suddenly fails, because the DST-switch occurs on different days in 2012 and 2013 in my TZ, i.e. length "Sun Oct 27 10:56:42 CET 2013" /= length "Sat Oct 27 11:56:42 CEST 2012" Does anyone happen to know what the rationale behind this 'time004' unit test was? Cheers, hvr

1 1

Improving specialization, redux
by David Feuer 25 Oct '14

25 Oct '14

I spoke with Simon today, and I think I have a bit of a better idea now of what's going on with specialization, and why it sometimes fails to specialize things as much as it could. Apparently, the replacement of (sel @ type dict) by sel.type is accomplished by the use of a rewrite rule generated by the specializer when it specializes an overloaded function using that (or something similar to that, anyway). The trouble is that as things are currently done, there's no way in general to get the right replacement to stick on the RHS of the rule when such forms arise in other contexts. The type checker constructs dictionaries in type checking, but afterwards we can't produce new ones. The most likely way to solve this is probably to (somehow) decouple dictionary creation and selection from type checking so as to expose those facilities to later phases. The concept would be something vaguely like this: instead of creating rewrite rules, the specializer would instead check whether the appropriate dictionary already existed, and create it if not. The simplifier would then check for a dictionary every time it encountered a class method whose instance is determined. No, I have no idea how much work such a change would involve.

1 0

Making GHCi awesomer?
by Christopher Done 24 Oct '14

24 Oct '14

Good evening, So I’ve been working on Haskell user-facing tooling in general for some years. By that I mean the level of Emacs talking with Haskell tools. I wrote the interactive-haskell-mode (most functionality exists in this file <https://github.com/haskell/haskell-mode/blob/master/haskell-process.el#L1> ). which launches a GHCi process in a pipe and tries very earnestly to handle input/output with the process reasonably. For Emacs fanciers: Written in Elisp, there’s a nice command queue that you put commands onto, they will all be run on a FIFO one-by-one order, and eventually you’ll get a result back. Initially it was just me using it, but with the help of Herbert Riedel it’s now a mode on equal footing with the venerable inferior-haskell-mode all ye Emacs users know and love. It’s part of haskell-mode and can be enabled by enabling the interactive-haskell-mode minor mode. For years I’ve been using GHCi as a base and it’s been very reliable for almost every project I’ve done (the only exceptions are things like SDL and OpenGL, which are well known to be difficult to load in GHCi, at least on Linux). I think we’ve built up a good set of functionality <https://github.com/haskell/haskell-mode/wiki/Haskell-Interactive-Mode> purely based on asking GHCi things and getting it to do things. I literally use GHCi for everything. For type-checking, type info, I even send “:!cabal build” to it. Everything goes through it. I love my GHCi. Now, I’m sort of at the end of the line of where I can take GHCi. Here are the problems as I see them today: 1. There is no programmatic means of communicating with the process. I can’t send a command and get a result cleanly, I have to regex match on the prompt, and that is only so reliable. At the moment we solve this by using \4 (aka ‘END OF TRANSMISSION’). Also messages (warnings, errors, etc.) need to be parsed which is also icky, especially in the REPL when e.g. a defaulted Integer warning will mix with the output. Don’t get me started on handling multi-line prompts! Hehe. 2. GHCi, as a REPL, does not distinguish between stdout, stderr and the result of your evaluation. This can be problematic for making a smooth REPL UI, your results can often (with threading) be interspersed in unkind ways. I cannot mitigate this with any kind of GHCi trickery. 3. It forgets information when you reload. (I know this is intentional.) 4. Not enough information is exposed to the user. (Is there ever? ;) 5. There is a time-to-market overhead of contributing to GHCi — if I want a cool feature, I can write it on a locally compiled version of GHC. But for the work projects I have, I’m restricted to given GHC versions, as are other people. They have to wait to get the good features. 6. This is just a personal point — I’ve like to talk to GHCi over a socket, so that I can run it on a remote machine. Those familiar with Common Lisp will be reminded of SLIME and Swank. Examples for point 4 are: - Type of sub-expressions. - Go to definition of thing at point (includes local scope). - Local-scope completion. - A hoogle-like query (as seen in Idris recently). - Documentation lookup. - Suggest imports for symbols. - Show core for the current module. - Show CMM for the current module, ASM, etc. SLIME can do this. - Expand the template-haskell at point. - The :i command is amazingly useful, but programmatic access would be even better.¹ - Case split anyone? - Etc. ¹I’ve integrated with it in Emacs so that I can C-c C-i any identifier and it’ll popup a buffer with the :i result and then within that buffer I can drill down further with C-c C-i again. It makes for very natural exploration of a type. You’ve seen some of these features in GHC Mod, in hdevtools, in the FP Haskell Center, maybe some are in Yi, possibly also in Leksah (?). So in light of point (5), I thought: I’ve used the GHC API before, it can do interactive evaluation, why not write a project like “ghc-server” which encodes all these above ideas as a “drop-in” replacement for GHCi? After all I could work on my own without anybody getting my way over architecture decisions, etc. And that’s what I did. It’s here <https://github.com/chrisdone/ghc-server>. Surprisingly, it kind of works. You run it in your directoy like you would do “cabal repl” and it sets up all the extensions and package dependencies and starts accepting connections. It will compile across three major GHC versions. Hurray! Rub our hands together and call it done, right? Sadly not, the trouble is twofold: 1. The first problem with this is that every three projects will segfault or panic when trying to load in a project that GHCi will load in happily. The reasons are mysterious to me and I’ve already lugged over the GHC API to get to this point, so that kind of thing happening means that I have to fall back to my old GHCi-based setup, and is disappointing. People have similar complaints of GHC Mod & co. “Getting it to work” is a deterrant. 2. While this would be super beneficial for me, and has been a good learning experience for “what works and what doesn’t”, we end up with yet another alternative tool, that only a few people are using. 3. There are just certain behaviours and fixes here and there that GHCi does that take time to reproduce. So let’s go back to the GHCi question: is there still a development overhead for adding features to GHCi? Yes, new ideas need acceptance and people have to wait (potentially a year) for a new feature that they could be using right now. An alternative method is to do what Herbert did which is to release a “ghci-ng” <http://hackage.haskell.org/package/ghci-ng> which sports new shiny features that people (with the right GHC version) will be able to compile and use as a drop-in for GHCi. It’s the same codebase, but with more stuff! An example is the “:complete” command, this lets IDE implementers do completion at least at the REPL level. Remember the list of features earlier? Why are they not in GHCi? So, of course, this got me thinking that I could instead make ghc-server be based off of GHCi’s actual codebase. I could rebase upon the latest GHC release and maintain 2-3 GHC versions backwards. That’s certainly doable, it would essentially give me “GHCi++”. Good for me, I just piggy back on the GHCi goodness and then use the GHC API for additional things as I’m doing now. But is there a way I can get any of this into the official repo? For example, could I hack on this (perhaps with Herbert) as “ghci-ng”, provide an alternative JSON communication layer (e.g. via some —use-json flag) and and socket listener (—listen-on ), a way to distinguish stdout/stderr (possibly by forking a process, unsure at this stage), and then any of the above features (point 4) listed. I make sure that I’m rebasing upon HEAD, as if to say ghci-ng is a kind of submodule, and then when release time comes we merge back in any new stuff since the last release. Early adopters can use ghci-ng, and everyone benefits from official GHC releases. The only snag there is that, personally speaking, it would be better if ghci-ng would compile on older GHC versions. So if GHC 7.10 is the latest release, it would still be nice (and it *seems* pretty feasible) that GHC 7.8 users could still cabal install it without issue. People shouldn’t have to wait if they don’t have to. Well, that’s everything. Thoughts? Ciao!

14 20

RE: Does D351 Unwiring-Integer patch now look like you envisioned?
by Simon Peyton Jones 24 Oct '14

24 Oct '14

I replied, but failed to press "Submit" (which is several screenfuls away). Sorry The Maybe DataCon idea looks right to me. FWIW I *hate* the way that TidyPgm is forced to predict what CorePrep will do. I've created https://ghc.haskell.org/trac/ghc/ticket/9718 to explain. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 24 October 2014 08:48 | To: Simon Peyton Jones | Subject: Does D351 Unwiring-Integer patch now look like you | envisioned? | | Hello Simon, | | I was wondering if | | https://phabricator.haskell.org/D351 | | looks the way you expected, and more specifically I'd like some | feedback on the `DataCon` vs. `Maybe Id` comment at | | https://phabricator.haskell.org/D351#8682 | | Thanks! | hvr

2 1