March 2014 - ghc-devs

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

FFI: c/c++ struct on stack as an argument or return value
by Yuras Shumovich 07 Oct '14

07 Oct '14

Hi, Right now ghc's FFI doesn't support c/c++ structures. Whenever we have foreign function that accepts or returns struct by value, we have to create wrapper that accepts or returns pointer to struct. It is inconvenient, but actually not a big deal. But there is no easy workaround when you want to export haskell function to use it with c/c++ API that requires structures to be passed by value (Usually it is a callback in c/c++ API. You can't change it's signature, and if it doesn't provide some kind of "void* userdata", then you are stuck.) I'm interested in fixing that. I'm going to start with 'foreign import "wrapper" ...' stuff. Calling conventions for passing c/c++ structures by value are pretty tricky and platform/compiler specific. So initially I'll use libffi for that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see rts/Adjustor.c). It will allow me to explore design space without bothering about low level implementation details. Later it could be implemented for native (non-libffi) adjustors. Is anybody interested it that? I appreciate any comments/ideas. Right now I don't have clear design. It would be nice to support plain haskell data types that are 1) not recursive, 2) has one constructor and 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any ideas are welcome. An example how to use libffi with structures: http://www.atmark-techno.com/~yashi/libffi.html#Structures Thanks, Yuras

7 19

Extending fold/build fusion
by Akio Takano 05 Sep '14

05 Sep '14

Hi, I have been thinking about how foldl' can be turned into a good consumer, and I came up with something that I thought would work. So I'd like to ask for opinions from the ghc devs: if this idea looks good, if it is a known bad idea, if there is a better way to do it, etc. The main idea is to have an extended version of foldr: -- | A mapping between @a@ and @b@. data Wrap a b = Wrap (a -> b) (b -> a) foldrW :: (forall e. Wrap (f e) (e -> b -> b)) -> (a -> b -> b) -> b -> [a] -> b foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 where go = unwrap $ \list z' -> case list of [] -> z' x:xs -> f x $ wrap go xs z' This allows the user to apply an arbitrary "worker-wrapper" transformation to the loop. Using this, foldl' can be defined as newtype Simple b e = Simple { runSimple :: e -> b -> b } foldl' :: (b -> a -> b) -> b -> [a] -> b foldl' f initial xs = foldrW (Wrap wrap unwrap) g id xs initial where wrap (Simple s) e k a = k $ s e a unwrap u = Simple $ \e -> u e id g x next acc = next $! f acc x The wrap and unwrap functions here ensure that foldl' gets compiled into a loop that returns a value of 'b', rather than a function 'b -> b', effectively un-CPS-transforming the loop. I put preliminary code and some more explanation on Github: https://github.com/takano-akio/ww-fusion Thank you, Takano Akio

5 20

7.8.1 plan
by Austin Seipp 16 Jul '14

16 Jul '14

Hello all, As I'm sure you're all aware, it's the final countdown. The (final) source distribution will be up within a few hours, and then we'll continue on from there. Yay! I will post an update when that is, so Gabor/Luke/Karel can make binaries from the sources as I do so. Second, there are just two things I want to note: - For people following the Windows debacle in #8834, there has been a bug fixed, but one may still remain. The TL;DR of this is that we currently have a committed workaround in place we'll keep using, but Simon has made some good steps towards finding the bug. - Lots of people, I'm sure, are wondering what's going on with Safe Haskell and the GND story. The TL;DR of this one is that "everything will be the same as in 7.6" - GND is considered an Unsafe feature, and Data.Coerce is behind Unsafe bars. From a safety point of view, nothing should change for library authors I cherry picked these changes into 7.8 last night. In the mean time, the 7.8 branch is effectively closed. If you have something to commit, and I *really* mean something, you can let me know. But your deadline is hours, not days! I'm doing a final review of all the trees before pushing the library tags, and after that I'll begin rolling the sdist. Anyway, the time is finally here, so let's get it over with! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

16 41

Proposal: Partial Type Signatures
by Thomas Winant 19 Jun '14

19 Jun '14

Dear GHC developers, Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I have been working on a proposal for adding *Partial Type Signatures* to GHC. In a partial type signature, annotated types can be mixed with inferred types. A type signature is written like before, but can now contain wildcards, written as underscores. The types of these wildcards or unknown types will be inferred by the type checker, e.g. foo :: _ -> Bool foo x = not x -- Inferred: Bool -> Boo The proposal also includes a form of generalisation which aligns with the existing generalisation that GHC does. We have written down a motivation (when and how might you use this) and details about the design and implementation on the following wiki page: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures We have a (work in progress) implementation [1] of the feature based on GHC. It currently implements most of what we propose, but there are some remaining important bugs mostly concerning the generalisation. We also described our design and presented a formalisation based on the OutsideIn(X) formalism in a paper [2] presented at PADL'14. What we are hoping to get from the people on this list is any of the below: * Read the design, play with the implementation and tell us any comments you may have about the feature, its design and implementation. * Opinions on whether this feature might be acceptable in GHC upstream at some point (if not, we do not think it's worth developing the implementation much further). * Perhaps a code review or a discussion with someone more knowledgeable about the internals of GHC's type checker about how we might fix the remaining problems in our implementation (specifically, we could use some help with implementing the generalisation of partial type signatures). * Feedback on the `Questions and issues' section on the wiki page. Kind regards, Thomas Winant [1]: https://github.com/mrBliss/ghc-head/ [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

12 26

RE: OverloadedRecordFields
by Simon Peyton Jones 18 Apr '14

18 Apr '14

Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense Simon | -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | > Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | > | > Simon | > | > | -----Original Message----- | > | From: Adam Gundry [mailto:adam@well-typed.com] | > | Sent: 17 January 2014 10:15 | > | To: Simon Peyton Jones | > | Subject: OverloadedRecordFields | > | | > | Hi Simon, | > | | > | I'm conscious that things have gone off the boil a little wrt | > | OverloadedRecordFields, partially as a consequence of the delayed | > | 7.8 release but also my lack of time for other projects since | > | starting work for Well-Typed. With that in mind, I'd like to propose | > | a plan to get back on track: | > | | > | 1. Revert to the three-parameter story, where we have | > | | > | t ~ FldTy r f => Has r f t | > | | > | rather than | > | | > | Has r f. | > | | > | The two-parameter version generates significantly worse error | > | messages, and there are some other unresolved problems, so I'm not | > | sure it is worth the minor simplification. | > | | > | 2. Roll back some of the refactoring that I've struggled to get | > | right (in particular, trying to make the generated FldTy/UpdTy | > | axioms implicitTyThings). We can always revisit this in the future | though. | > | | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful | > | by now, but presumably with 7.8 imminent there won't be many major | > | changes coming for a while? | > | | > | 4. Review the proposed changes with you and fix any show-stopping | > | problems. | > | | > | 5. Merge into HEAD after 7.8 is released. | > | | > | Does this sound plausible? I'm happy to Skype if you like. | > | | > | Cheers, | > | | > | Adam | > | | > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | > | Neil Ghani has got me some funding to work with them both on units | > | of measure for Haskell. We are still sorting out the details, but I | > | hope it might be possible to work on some kind of plugin mechanism | > | for GHC's constraint solver, along the lines that Iavor has been | > | investigating, if that would be of interest? | > | | > | -- | > | Adam Gundry, Haskell Consultant | > | Well-Typed LLP, http://www.well-typed.com/ | > | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/

4 4

ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
by Sergei Trofimovich 09 Apr '14

09 Apr '14

Hello! I have noticed the problem in ghc-7.6.3 first when tried to build all haskell userland with -O2 opt level. It led to amazing bugs! Here is one of those (highlighting-kate hackage package): > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) > stack overflow: use +RTS -K<size> to increase it How to reproduce it: 1. Download a bundled file (6.6MB): http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz 2. Unpack and run there: ./mk.sh The script is designed to plug any built ghc version w/o external depends. Command will fail as: $ ./mk.sh ... [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K<size> to increase it On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash there similar way. I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around. Nothing else. It's very hard to shrink such large thing manually down to 2-3 files. Would be cool if ghc (and cabal) would be able to spit something self-sufficient (like 'gcc -i' does) for devs to reproduce. Adding '-v' shows such log: ... *** Simplifier: Result size of Simplifier iteration=1 = {terms: 21,973, types: 21,838, coercions: 1,842} Result size of Simplifier iteration=2 = {terms: 21,952, types: 21,819, coercions: 1,842} Result size of Simplifier = {terms: 21,950, types: 21,817, coercions: 1,842} *** SpecConstr: Result size of SpecConstr***<CRASH> Thanks! -- Sergei

2 3

Backward-compatible role annotations
by Richard Eisenberg 09 Apr '14

09 Apr '14

I spent some time thinking about what, precisely, can be done here to make folks happier. (See the thread beginning here: http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the answer seemed to all be in the concrete syntax. The only logical alternative (that I could think of) to having roles is to disallow GND, and I don't think anyone is proposing that. And, it is impossible to infer an author's desired roles for a datatype. The heuristics mentioned here all seem far too fragile and hard to predict to become a lasting feature of GHC (in my opinion). What's left? Concrete syntax. So, I have written and uploaded no-role-annots-1.0, a backward-compatible alternative to role annotations -- no CPP required. It's not as principled as proper role annotations, but it should do the job for most users. Here are two examples: 1. Datatypes: > import Language.Haskell.RoleAnnots > > data Map k v = > (Nominal k, Representational v) => MkMap [(k,v)] The constraints (which need be put on only one data constructor, if there are many) will get the built-in role inference mechanism to do what the user requests. In this example, the `Representational v` is actually redundant, but causes no harm. Because these classes have universal instances ("instance Nominal a") and have no methods, they should have no run-time significance. The only downside I can see is that the code above needs -XGADTs or -XExistentialQuantification to work, though it is neither a GADT nor has existentials. (Pattern-matching on such a definition needs no extensions.) 2. Newtypes: Newtype constructors cannot be constrained, unfortunately. So, we have to resort to Template Haskell: > import Language.Haskell.RoleAnnots > > roleAnnot [NominalR, RepresentationalR] > [d| newtype Map k v = MkMap [(k, v)] |] This is clearly worse, but I was able to come up with no other solution that worked for newtypes. Note that, in the example, I used the fact that Template Haskell interprets a bare top-level expression as a Template Haskell splice. We could also wrap that line in $( ... ) to be more explicit about the use of TH. Also problematic here is that the code above requires -XRoleAnnotations in GHC 7.8. To get this extension enabled without using CPP, put it in a condition chunk in your .cabal file, like this: > if impl(ghc >= 7.8) > default-extensions: RoleAnnotations I hope this is helpful to everyone. Please feel free to post issues/pull requests to my github repo at github.com/goldfirere/no-role-annots. Thanks, Richard

3 6

Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM
by eng. Vassil Ognyanov Keremidchiev 03 Apr '14

03 Apr '14

Hello! Could someone help me with compiling GHC under Ubuntu as a ARM cross-compiler? Currently I have done those steps: sudo apt-get update sudo apt-get install autoconf alex happy libtool autopoint zlib1g-dev libncurses5-dev ghc-haddock sudo export PATH=~/.cabal/bin:$PATH sudo cabal install --reinstall happy alex terminfo libffi html regex-compat git clone http://darcs.haskell.org/ghc.git cd ghc ./sync-all --no-dph get ./sync-all pull ./boot sudo ./configure --target=arm-linux-gnueabi --enable-unregisterised cp mk/build.mk.sample mk/build.mk # here I enable quick-cross configuration sudo make and I get: echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >> compiler/stage1/build/.depend-v.c_asm.tmp mv compiler/stage1/build/.depend-v.c_asm.tmp compiler/stage1/build/.depend-v.c_asm inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabi-nm" /usr/bin/arm-linux-gnueabi-nm: includes/dist-derivedconstants/header/tmp.o: File format not recognized deriveConstants: readProcess: /usr/bin/arm-linux-gnueabi-nm "includes/dist-derivedconstants/header/tmp.o" (exit 1): failed make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 make: *** [all] Error 2 What I have done wrong? I did not understand the error message well, too.

3 13

RE: Gearing up (again) for the next release: 2014.2.0.0
by Simon Peyton Jones 31 Mar '14

31 Mar '14

| If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. Well, five weeks ago we marked the ticket as "not a release blocker". No one commented. And it's not a regression, is it? I don't think -dynamic-too existed in 7.6. We'd welcome help with this. There is some reason it's not straightforward to fix, but I've forgotten what it is. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of harry | Sent: 31 March 2014 09:21 | To: libraries(a)haskell.org | Subject: RE: Gearing up (again) for the next release: 2014.2.0.0 | | Simon Peyton Jones wrote | > We have not begun to think about when to release 7.8.2. It’ll depend | on | > what issues show up in 7.8.1 and how urgent they seem to be. We have | > delayed 7.8.1 for ages, and given masses of warning about the release, | so | > I’d be sad if there are known, show-stopping bugs in it that we already | > know about. If there really really really are, maybe we should delay | > 7.8.1 further. But that process can go on indefinitely (as we have | > already seen), so I’m pretty reluctant. | > | > But I’d certainly listen to a consensus view from the HP team. You | > represent our customers. | | If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next- | release-2014-2-0-0-tp5746660p5746686.html | Sent from the Haskell - Libraries mailing list archive at Nabble.com. | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0