August 2012 - Glasgow-haskell-users

question about type lits and optimization in ghc
by Carter Schonwald 21 Aug '12

21 Aug '12

Hey GHC folks! In the case where type lits (naturals specifically) are statically known (rather than abstract), is it possible to have a sort of static copy propagation / Singelton simplification happen at compile time? (Ie can GHC do such things with type lits as presently implemented?) a simple example might be that a statically sized matrix, and being able to specialize the stride and bounds checking at compile time (pseudo code example follows) data Mat (row::Nat) (col::Nat) elem = ... some vector representation index:: (Mat r c el) -> (Word,Word) -> el index mt ix = ... some stride based indexing calculation that gets at the "r" and "c" numbers via the singletons to translate the ix tuple into the index into the underlying vector representation {-# perhaps an inline pragma? #-} indexSpec3x3:: (Mat 3 3 el) -> (Word, Word) -> el indexSpec3x3 smat ix = smat `index` ix under what circumstances can i get something like the body of indexSpec3x3 to use the static type level natural number machinery to partially specialize the computation? Does my question even make sense as phrased? thanks! -Carter

1 0

Re: build failures when hiding non-visible imports
by John Lato 21 Aug '12

21 Aug '12

> From: Brandon Allbery <allbery.b(a)gmail.com> > > On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> meaning: flags for treating it as a warning vs as an error? (pardon, i'm >> over thinking ambiguity in phrasing). >> if thats the desired difference, that sounds good to me! >> > > I would expect it means that, having demoted it to a warning, we would have > -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or whatever we call > it) as with all other warnings. > > For warning vs. error, it seems to me that should be more general: perhaps > taking any of the -f[no-]warn-* options and replacing "warn" with "err". Yes. To be concrete, this is what I would like to see. In a statement of the form: import Module hiding (x) where Module doesn't export x, ghc should report a warning instead of an error This warning would be enabled/disabled by the usual flags (I like -fwarn-unused-import-hiding, but -fwarn-hiding-no-target is good too). The warning would be on by default. If a user wants this to be an error, I think -Werror should be sufficient. I am unable to think of any case where hiding a non-visible symbol would lead to errors on its own, and any errors likely to occur in tandem with this issue already have their own, more helpful, error conditions (e.g. symbols not in scope, symbols in a qualified import list not visible). I agree with Ganesh's point that it would be beneficial to have this available for ghc-7.6.1 if possible. John L.

3 2

build failures when hiding non-visible imports
by John Lato 20 Aug '12

20 Aug '12

Hello, One of the issues I've noticed with ghc-7.6 is that a number of packages fail due to problematic import statements. For example, any module which uses > import Prelude hiding (catch) now fails to build with the error Module `Prelude' does not export `catch' Of course fixing this example is relatively straightforward, but that isn't always the case. Would it be reasonable to change ghc's behavior to treat this as a warning instead of an error? Cheers, John L.

8 7

funny type inference error with ghc7.6rc1
by Carter Schonwald 20 Aug '12

20 Aug '12

Hey All, When playing with the current hackage versions of Epic and Idris to make them play nice with ghc7.6rc1 http://hackage.haskell.org/package/idris-0.9.2.1 and http://hackage.haskell.org/package/epic-0.9.3 (current version on github now builds on ghc 7.6, https://github.com/edwinb/EpiVM) I ran into some funny type inference problems. Namely, using the idris-0.9.2.1 source and iteratively seeing how ghc complains, I repeated found that ghc would infer extraneous class constraints with variables that don't appear in the function type! eg (Num a, Ord a) => PArg -> Doc, when the *correct* type to infer would be PArg -> Doc. heres some gists with links to more info https://gist.github.com/3365312 https://gist.github.com/3365073 https://gist.github.com/3364775 Anyways, I'm not sure what to make of this, is this a reasonable artifact of type inference getting confused on functions with a large number of case analyses when various typeclass extensions are enabled? Or Is this a bug in terms of what inference should be able to handle? Just to be clear, when I add the infererred type ascriptions without the type class constraint, everything type checks in those modules. So my confusion is why the inference adding those unused class constraint variables! thanks all, -Carter

2 2

Template Haskell
by Simon Peyton-Jones 15 Aug '12

15 Aug '12

Folks Mikhail has improved Template Haskell's handling of INLINE pragmas, SPECIALISE pragmas, and RULES. I plan to commit his patch: http://hackage.haskell.org/trac/ghc/ticket/7064 This of course involves some changes to TH.Syntax, which will affect you if you are using the (limited) existing support for pragmas in TH. Yell if you want to suggest any modifications to what Mikhail has done. (Including things like what to call the types and their data constructors.) The patch is attached to the ticket. Thanks to Mikhail. Simon

3 3

Non-updateable thunks
by Joachim Breitner 14 Aug '12

14 Aug '12

Hello, I’m still working on issues of performance vs. sharing; I must assume some of the people here on the list must have seen my "dup"-paper¹ as referees. I’m now wondering about a approach where the compiler (either automatically or by user annotation; I’ll leave that question for later) would mark some thunks as reentrant, i.e. simply skip the blackholing and update frame pushing. A quick test showed that this should work quite well, take the usual example: import System.Environment main = do a <- getArgs let n = length a print n let l = [n..30000000] print $ last l + last l This obviously leaks memory: $ ./Test +RTS -t 0 60000000 <<ghc: 2400054760 bytes, 4596 GCs, 169560494/935354240 avg/max bytes residency (11 samples), 2121M in use, 0.00 INIT (0.00 elapsed), 0.63 MUT (0.63 elapsed), 4.28 GC (4.29 elapsed) :ghc>> I then modified the the assembly (a crude but effective way of testing this ;-)) to not push a stack frame: $ diff -u Test.s Test-modified.s --- Test.s 2012-08-01 11:30:00.000000000 +0200 +++ Test-modified.s 2012-08-01 11:29:40.000000000 +0200 @@ -56,20 +56,20 @@ leaq -40(%rbp),%rax cmpq %r15,%rax jb .LcpZ - addq $16,%r12 - cmpq 144(%r13),%r12 - ja .Lcq1 - movq $stg_upd_frame_info,-16(%rbp) - movq %rbx,-8(%rbp) + //addq $16,%r12 + //cmpq 144(%r13),%r12 + //ja .Lcq1 + //movq $stg_upd_frame_info,-16(%rbp) + //movq %rbx,-8(%rbp) movq $ghczmprim_GHCziTypes_Izh_con_info,-8(%r12) movq $30000000,0(%r12) leaq -7(%r12),%rax - movq %rax,-24(%rbp) + movq %rax,-8(%rbp) movq 16(%rbx),%rax - movq %rax,-32(%rbp) - movq $stg_ap_pp_info,-40(%rbp) + movq %rax,-16(%rbp) + movq $stg_ap_pp_info,-24(%rbp) movl $base_GHCziEnum_zdfEnumInt_closure,%r14d - addq $-40,%rbp + addq $-24,%rbp jmp base_GHCziEnum_enumFromTo_info .Lcq1: movq $16,192(%r13) Now it runs fast and slim (and did not crash on the first try, which I find surprising after hand-modifying the assembly code): $ ./Test +RTS -t 0 60000000 <<ghc: 4800054840 bytes, 9192 GCs, 28632/28632 avg/max bytes residency (1 samples), 1M in use, 0.00 INIT (0.00 elapsed), 0.73 MUT (0.73 elapsed), 0.04 GC (0.04 elapsed) :ghc>> My question is: Has anybody worked in that direction? And are there any fundamental problems with the current RTS implementation and such closures? Greetings, Joachim ¹ http://arxiv.org/abs/1207.2017 currently not about to appear anywhere else, but I have not given up hope yet :-) -- Dipl.-Math. Dipl.-Inform. Joachim Breitner Wissenschaftlicher Mitarbeiter http://pp.info.uni-karlsruhe.de/~breitner

3 4

PolyKinds, Control.Category and GHC 7.6.1
by Edward Kmett 14 Aug '12

14 Aug '12

Would it be possible to add something like {-# LANGUAGE CPP #-} #if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 704 {-# LANGUAGE PolyKinds #-} #endif to the top of Control.Category before the 7.6.1 final release? Control.Category.Category is pretty much the only type in base that directly benefits from PolyKinds without any code changes, but without enabling the extension there nobody can define categories for kinds other than *, and most interesting categories actually have more exotic kinds. I only noticed that it wasn't there in the release candidate just now. -Edward Kmett

4 4

Request for comments on proposal for literate programming using markdown
by Philip Holzenspies 09 Aug '12

09 Aug '12

Dear GHC-ers, A little while ago, I submitted a new feature request on the Trac. I'm more than happy to build this myself, but I would like to get it right the first time, so I'm looking for comments from developers and users alike. If you're interested in literate programming and would like to have the ability to do it in markdown, please read and comment on this: http://hackage.haskell.org/trac/ghc/ticket/7120 Regards, Philip

2 1

API for looking-up/retrieving Haddock comments?
by Herbert Valerio Riedel 08 Aug '12

08 Aug '12

Hello, I've been wondering if there have been attempts to provide some library/API or similiar facility (other than pointing your web-browser to the static Haddock HTML report) for looking up Haddock comments associated with Haskell symbols? As an obvious application: When coding in dynamic languages (e.g. Python, Elisp, or GNU R to name a few), I've learned to appreciate the ability to lookup up documentation interactively from the tab-completing REPL w/o having to "switch context/focus" to different application (as I currently do: I have to switch from GHCi to a web-browser and first locate the appropriate package/module and then find the symbol I'm interested in). cheers, hvr

3 4

New INLINE pragma syntax idea, and some questions
by Brandon Simmons 07 Aug '12

07 Aug '12

I've been wondering for some time about the details of how GHC uses syntax with inlining, and how other transformations come into play in the process (I recently asked a question on SO if anyone wants some karma: http://stackoverflow.com/q/11690146/176841) I know this is a big topic and there's probably a lot more out there I should read. In particular I don't fully understand why these sorts of contortions... http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-Li… ...are required. It seems like a programmer has to throw "equational reasoning", separation of concerns, and all the little elegant bits about the language out the window just to indicate something boring to the compiler. Disclaimer: The following is less a proposal meant to be taken seriously, and more me trying to better understand things. Could the following be used as syntax for indicating inlining? Rather than relying on the syntactic LHS, instead let that be specified in the type signature... foldl :: (a -> b -> a) -> a -> [b] -> {-# INLINE #-} a foldl f z [] = z foldl f z (x:xs) = foldl f (f z x) xs ...indicating, in this case, that foldl should be inlined when "fully-applied" means its first three arguments (I guess that's the intent of the original version linked above?). Then (waves hands) the compiler could do the necessary transformations that the programmer had to do to foldl above. Maybe what I'm proposing is actually a separate NORECURSIVE_TRANSFORM pragma or something. An alternative if including the pragma in the type sig. isn't sound, is to allow it in the function definition left-hand side, after the bindings we would like applied before inlining. Brandon

3 3