January 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

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

Request: export runTcInteractive from TcRnDriver
by p.k.f.holzenspies＠utwente.nl 12 Mar '14

12 Mar '14

Dear GHC-devs, Is there a reason why, in HEAD, TcRnDriver does *not* export runTcInteractive? If not, can it please be added? (I considered sending a patch with this email, but it's so trivial a change that the check of the patch is more work than manually adding runTcInteractive to the export list.) I'm developing against the GHC API of 7.6.3 and it would have saved me hours of work to have precisely that function. Seeing it's in HEAD, but not being exported seems a shame ;) Regards, Philip

3 3

workaround to get both domain-specific errors and also multi-modal type inference?
by Nicolas Frisby 19 Feb '14

19 Feb '14

Hi all. I have a question for those savvy to the type-checker's internal workings. For uses of the following function, can anyone suggest a means of forcing GHC to attempt to solve C a b even if a~b fails? > dslAsTypeOf :: (C a b,a~b) => a -> b -> a > dslAsTypeOf x _ = x > > class C a b -- no methods Just for concreteness, the following are indicative of the variety of instances that I expect C to have. (I don't think this actually affects the question above.) > instance C DSLType1 DSLType1 > instance C DSLType2 DSLType2 > instance C x y => C (DSLType3 x) (DSLType3 y) > > instance IndicativeErrorMessage1 => C DSLType1 DSLType2 > instance IndicativeErrorMessage2 => C DSLType2 (DSLType3 y) > > class IndicativeErrorMessage1 -- will never have instances > class IndicativeErrorMessage2 -- will never have instances Thank you for your time. =================================== Keep reading for the "short story", the "long story", and two ideas for a small GHC patch that would enable my technique outlined above. ===== short story ===== The motivation of dslAsTypeOf is to provide improved error messages when a and b are not equal. Unfortunately, the user will never see IndicativeErrorMessage. It appears that GHC does not attempt to solve C a b if a~b fails. That's understandable, since the solution of C a b almost certainly depends on the "value" of its arguments... Hence, the question at the top of this email. ===== long story ===== A lot of the modern type-level programming capabilities can be put to great use in creating type systems for embedded domain specific languages. These type systems can enforce some impressive properties. However, the error messages you get when one of those property is not satisfied can be pretty abysmal. In my particular case, I have a phantom type where the tag carries all the domain-specific information. > newtype U (tag :: [Info]) a = U a and I have an binary operation that requires the tag to be equivalent for all three types. > plus :: Num a => U tag a -> U tag a -> U tag a > plus (U x) (U y) = U $ x + y This effectively enforces the property I want for U values. Unfortunately, the error messages can seem dimwitted. > ill_typed = plus (U 1 :: U [Foo,Bar,Baz] Int) (U 2 :: U [Foo,Baz] Int) The `ill_typed` value gives an error message (in GHC 7.8) saying Bar : Baz : [] is not equal to Baz : [] (It's worse in GHC 7.4. I don't have access to a 7.6 at the moment.) I'd much rather have it say that "Bar is missing from the first summand's list." And I can define a class that effectively conveys that information in a "domain-specific error message" which is actually a "no instance of <IndicativeClassName> tag1 tag2" message. > friendlier_plus :: (FriendlyEqCheck tag1 tag2 tag3,Num a) => U tag1 a -> U tag2 a -> U tag3 a The `friendlier_plus' function gives useful error messages if tag1, tag2, and tag3 are all fully monomorphic. However, it does not support inference: > zero :: Num a => U tag a > zero = U 0 > > x = U 4 :: U [Foo,Baz] Int > > -- both of these are ill-typed :( > should_work1 = (friendlier_plus zero x) `asTypeOf` x -- tag1 is unconstrained > should_work2 = friendlier_plus x x -- tag3 is unconstrained Neither of those terms type-check, since FriendlyEqCheck can't determine if the unconstrained `tag' variable is equal to the other tags. So, can we get the best of both worlds? > best_plus :: > ( FriendlyEqCheck tag1 tag2 tag3 , tag1 ~ tag2, tag2 ~ tag3, Num a) => U tag1 a -> U tag2 a -> U tag3 a No, unfortunately not. Now the `should_work*' functions type-check, but an ill-typed use of `best_plus' gives the same poor error message that `plus' would give. Hence, the question at the top of this email. ===== two ideas ===== If my question at the top of this email cannot be answered in the affirmative, perhaps a small patch to GHC would make this sort of approach a viable lightweight workaround for improving domain-specific error messages. (I cannot estimate how difficult this would be to implement in the type-checker.) Two alternative ideas. 1) An "ALWAYS_ATTEMPT" PRAGMA that you can place on the class C so that it is attempted even if a related ~ constraint fails. 2) An OrElse constraint former, offering *very* constrained back-tracking. > possibleAsTypeOf :: ((a ~ b) `OrElse` C a b) => a -> b -> a > possibleAsTypeOf x _ = x Requirements: C must have no superclasses, no methods, and no fundeps. Specification: If (a~b) fails and (C a b) is satisfiable, then the original inequality error message would be shown to the user. Else, C's error message is used. =================================== You made it to the bottom of the email! Thanks again.

5 12

Idea for improving communication between devs and potential devs
by Howard B. Golden 19 Feb '14

19 Feb '14

Hi, I'd like to get involved in developing, but I recognize the learning curve involved. To get started I'd like to improve the Trac wiki documentation. Part of this would include additional documentation of less-documented parts of the compiler and RTS. In addition, I'd like to start some sort of "what's new" that boils down the GHC Dev mailing list discussion as LWN does for the Linux kernel mailing list. I don't imagine that I can do this all by myself, but I hope this idea would resonate with others looking to get started as well. This is meant to be more frequent and more detailed than what HCAR does for GHC now, though I don't expect anyone can do it weekly. Please let me know what you think about this idea. I'm open to any suggestions for improving it also. Howard B. Golden Northridge, CA, USA

6 7

Nightlies
by Mateusz Kowalczyk 08 Feb '14

08 Feb '14

Hi all, I'd just like to query the status of the nightly builds. Is anything happening in that area? [1] is right on the front page of the GHC Trac even though no builds were ran for ~5 months. Perhaps it should be moved out of the way if there's no plan to resume these in the near future. Does anything specific need doing to get these to run again? [1]: https://ghc.haskell.org/trac/ghc/wiki/Builder -- Mateusz K.

10 22

GHC boot-library package changelogs & release-notes
by Herbert Valerio Riedel 04 Feb '14

04 Feb '14

Hello fellow GHC devs, As some of you might have noticed, I added a changelog.md file to libraries/base: https://github.com/ghc/packages-base/blob/c8634027d4e3315a2276fb1be8168c486… (please feel free to fix any typos/omissions/whatever you notice) My hope/motivation is that since Hackage gained the ability to display changelog files, the rather extensive changes in `base` might be a bit more easily/conveniently accessible on Hackage. I chose to use Markdown format, as I believe it may be more convenient to maintain/edit the `base` changelog as plain text rather than having to edit XML after each noteworthy change in `base`. And as the release-notes typically only exploit a subset of the Docbook facilities, the conversion to Docbook XML could be performed semi-automatically shortly before a release. Moreover, the release notes from previous major GHC release (which in the past contained the major changes in `base` et al.) are usually removed again. While a separate changelog file would usually retain (more) version history. Therefore, I'd propose to switch from editing the user's guide release note for library release notes to using Hackage-changelog files in Markdown format (following a common structural convention) and make it the release-manager's responsibility to integrate the respective package's changelog content into the user's guide. Any comments? Cheers, hvr

4 3

Re: [commit: haddock] master: Update tests (18e9417)
by Gabor Greif 31 Jan '14

31 Jan '14

Unless I missed something big style, -XTypeHoles has been renamed to -XTypedHoles and not removed at all. Are you sure this patch is valid? Cheers, Gabor On 1/30/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/haddock > > On branch : master > Link : > http://git.haskell.org/haddock.git/commitdiff/18e9417edcda21dd23edf675b41f4… > >>--------------------------------------------------------------- > > commit 18e9417edcda21dd23edf675b41f46ab336d773f > Author: Mateusz Kowalczyk <fuuzetsu(a)fuuzetsu.co.uk> > Date: Wed Jan 29 21:41:58 2014 +0000 > > Update tests > > This updates tests due to Haddock Trac #271 fix and due to removal of > TypeHoles as an extension from GHC. > > >>--------------------------------------------------------------- > > 18e9417edcda21dd23edf675b41f46ab336d773f > html-test/ref/Extensions.html | 2 +- > html-test/ref/Test.html | 2 +- > html-test/src/Extensions.hs | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/html-test/ref/Extensions.html b/html-test/ref/Extensions.html > index 82fd732..382083c 100644 > --- a/html-test/ref/Extensions.html > +++ b/html-test/ref/Extensions.html > @@ -47,7 +47,7 @@ window.onload = function () > {pageLoad();setSynopsis("mini_Extensions.html");}; > ><th > >Extensions</th > ><td > - >TypeHoles</td > + >ExplicitForAll</td > ></tr > ></table > ><p class="caption" > diff --git a/html-test/ref/Test.html b/html-test/ref/Test.html > index 0214662..bd447ea 100644 > --- a/html-test/ref/Test.html > +++ b/html-test/ref/Test.html > @@ -41,7 +41,7 @@ window.onload = function () > {pageLoad();setSynopsis("mini_Test.html");}; > ><th > >License</th > ><td > - >(c) Simon Marlow 2002</td > + >BSD-style</td > ></tr > ><tr > ><th > diff --git a/html-test/src/Extensions.hs b/html-test/src/Extensions.hs > index 6b3535c..61eac21 100644 > --- a/html-test/src/Extensions.hs > +++ b/html-test/src/Extensions.hs > @@ -1,4 +1,4 @@ > -{-# LANGUAGE Haskell2010, TypeHoles, MonomorphismRestriction #-} > +{-# LANGUAGE Haskell2010, ExplicitForAll, MonomorphismRestriction #-} > {-# OPTIONS_HADDOCK show-extensions #-} > module Extensions where > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 2

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Austin Seipp 31 Jan '14

31 Jan '14

(Grr, resending to list...) Hello all, The 7.8 branch is officially ready for RC1 (after some final Haddock bugs got quickly squashed by Gergo and Mateusz.) Pali, Luke - this is specifically for you two as you have offered to make the FreeBSD and iOS builds (Luke - 7.8 should contain both the fix for __thread and the perf-cross flavor, so it should work out of the box for you.) Attached is a fingerprint file for the GHC repository. You can restore it with: $ ./utils/fingerprint/fingerprint.py restore -f ghc-7.8-rc1.fingerprint See here for more details - https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingth… Alternatively, simply checking out to the 'ghc-7.8' branch will result in the same thing - no new commits will go in until after RC1: $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 $ cd ghc-7.8 $ ./sync-all get -b ghc-7.8 --extra --nofib Afterwords, just build and make the binaries as you normally would: $ ./boot; ./configure $ make $ make binary-dist Please let me know when the builds are done and somewhere to obtain them, and I'll upload them to haskell.org for the RC. I'll begin my builds now too... On Thu, Jan 30, 2014 at 5:02 PM, Austin Seipp <aseipp(a)pobox.com> wrote: > Hello all, > > The 7.8 branch is officially ready for RC1 (after some final Haddock > bugs got quickly squashed by Gergo and Mateusz.) > > Pali, Luke - this is specifically for you two as you have offered to > make the FreeBSD and iOS builds (Luke - 7.8 should contain both the > fix for __thread and the perf-cross flavor, so it should work out of > the box for you.) > > Attached is a fingerprint file for the GHC repository. You can restore it with: > > $ ./utils/fingerprint/fingerprint.py restore -f ghc-7.8-rc1.fingerprint > > See here for more details - > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingth… > > Alternatively, simply checking out to the 'ghc-7.8' branch will result > in the same thing - no new commits will go in until after RC1: > > $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 > $ cd ghc-7.8 > $ ./sync-all get -b ghc-7.8 --extra --nofib > > Afterwords, just build and make the binaries as you normally would: > > $ ./boot; ./configure > $ make > $ make binary-dist > > Please let me know when the builds are done and somewhere to obtain > them, and I'll upload them to haskell.org for the RC. I'll begin my > builds now too... > > > On Thu, Jan 30, 2014 at 4:31 AM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: >> Hello Herbert, >> >>> Hello Kazu, >>> >>> ..as this is a Cabal issue, this needs to be handled upstream; could you >>> please file an issue at >>> >>> https://github.com/haskell/cabal/issues/new >> >> Done. >> >> https://github.com/haskell/cabal/issues/1660 >> >> --Kazu >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Páli Gábor János 31 Jan '14

31 Jan '14

On Fri, Jan 31, 2014 at 12:02 AM, Austin Seipp <aseipp(a)pobox.com> wrote: > Please let me know when the builds are done and somewhere to obtain > them, and I'll upload them to haskell.org for the RC. I'll begin my > builds now too... All right, I have put the 32-bit and 64-bit FreeBSD builds here: http://haskell.inf.elte.hu/ghc/ Note that I included the corresponding SHA-256 checksum as well. Also, I composed a brief README for the users on how to install and use the binary distributions. Let me know if there is anything else I can do.

2 2