May 2013 - ghc-devs - Haskell.org

Re: PolyKinds, Control.Category and GHC 7.6.1
by Austin Seipp 30 May '13

30 May '13

Very well then. If there are no objections in the typical 2wk time frame*, I will craft a patch to base and commit it to fix this. * Technically, some might consider this proposal open for 9 months. I'm new to library changes however, so I'll go by all the rules as I should. :) On Thu, May 16, 2013 at 11:02 AM, Edward Kmett <ekmett(a)gmail.com> wrote: > As noted by Simon, the bound on that should be >= 706 though. > > > On Thu, May 16, 2013 at 12:02 PM, Austin Seipp <aseipp(a)pobox.com> wrote: >> >> Also, apologies for reviving a thread. I also did not include Edward's >> original message for better context. It is inline below. >> >> -------------------------- >> 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 >> -------------------------- >> >> >> -- >> Regards, >> Austin - PGP: 4096R/0x91384671 > > -- Regards, Austin - PGP: 4096R/0x91384671

1 1

--with-gcc does not work well
by Kazu Yamamoto 30 May '13

30 May '13

Hi, I'm trying to validate GHC head with GCC 4.7 on FreeBSD. I run "validate" without any modifications: % config_args="--prefix=/ghc-head --with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 --with-gcc-4.2=/usr/local/bin/gcc47 --with-system-libffi --with-ffi-includes=/usr/local/include --with-ffi-libraries=/usr/local/lib" THREADS=10 sh validate This caused an error: Configuring terminfo-0.3.2.5... configure: WARNING: unrecognized options: --with-compiler, --with-iconv-includes, --with-iconv-libraries, --with-gmp-includes, --with-gmp-libraries, --with-gcc checking for gcc... cc checking whether the C compiler works... no configure: error: in `/usr/home/kazu/work/ghc/libraries/terminfo': configure: error: C compiler cannot create executables For GCC, "cc" is guessed. This is because "mk/config.mk.in" does not use "gcc47" to CC_STAGE0. I don't know this is a correct way but I patched as follows: diff --git a/mk/config.mk.in b/mk/config.mk.in index 55f5756..51d3e96 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -487,13 +487,13 @@ GccLT34 = @GccLT34@ GccLT46 = @GccLT46@ CC = $(WhatGccIsCalled) -CC_STAGE0 = @CC_STAGE0@ +CC_STAGE0 = $(CC) CC_STAGE1 = $(CC) CC_STAGE2 = $(CC) CC_STAGE3 = $(CC) AS = $(WhatGccIsCalled) -AS_STAGE0 = @CC_STAGE0@ +AS_STAGE0 = $(AS) AS_STAGE1 = $(AS) AS_STAGE2 = $(AS) AS_STAGE3 = $(AS) After that, "validate" caused this error: gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -fno-stack-protector -Werror -Wall -Icompiler/stage1 -Icompiler/. -Icompiler/parser ... -Werror=unused-but-set-variable -Wno-error=inline -MM compiler/ghci/keepCAFsForGHCi.c -MF compiler/stage1/build/.depend-v.c_asm.bit cc1: error: -Werror=unused-but-set-variable: No option -Wunused-but-set-variable "gcc" is used instead of "gcc47". Note "gcc" is GCC 4.2 which does not accept -Wunused-but-set-variable. This is because that CPP is defined independently on --with-gcc. So, I had to specify CPP to configure: % config_args="--prefix=/ghc-head --with-gcc=/usr/local/bin/gcc47 ... CPP=cpp47 THREADS=10 sh validate Unfortunately, this also caused another error: "/usr/local/bin/ghc" -optc-Werror -optc-Wall -optc-isystem'/usr/home/kazu/work/ghc/compiler/stage1' ... -Wall -XHaskell98 -XNondecreasingIndentation -XCPP -XPatternGuards -fwarn-tabs -O -no-user-package-conf -rtsopts -c ghc/hschooks.c -o ghc/stage1/build/hschooks.o cc1: error: -Werror=unused-but-set-variable: No option -Wunused-but-set-variable Since I don't know how to pass "-pgmc gcc47", I gave up here. I think that the --with-gcc option for "configure" does not work well and we need to fix this. --Kazu

4 7

Module import and use in GHC plugin?
by Conal Elliott 30 May '13

30 May '13

In writing GHC plugins, how can I (a) add a module import (preferably qualified) and (b) make vars/ids for names imported from the newly imported module (to insert in the transformed Core code)? If it's not possible to do what I want, I'd be willing to require an explicit import (say "import qualified Foo") in client code, as a temporary workaround. So far I've been unable to import even from the base package. Maybe I'm missing something basic that you folks have learned. My simple & unsuccessful attempt is at https://github.com/conal/plugin-import-id . Help greatly appreciated. Thanks, - Conal

3 2

Stuck
by Simon Peyton-Jones 28 May '13

28 May '13

Ian I'm stuck again. This time I'm trying to run nofib. But all attempts yield gibberish below Apparently mk/config.mk.in contains GHC_STAGE2 = $(ghc-stage2_INPLACE) which is, I believe, essential to nofib. But I can't see anywhere that ghc-stage2_INPLACE is set. It would be great to have your help in getting un-stuck. Thanks Simon simonpj@cam-05-unx:~/5builds/HEAD/nofib$ make boot /bin/sh: 1: /5playpen/simonpj/HEAD/: Permission denied /bin/sh: 1: [: -gt: unexpected operator /bin/sh: 1: [: -ge: unexpected operator ------------------------------------------------------------------------ == Recursively making `boot' in runstdtest nofib-analyse imaginary spectral real shootout ... PWD = /5playpen/simonpj/HEAD/nofib ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make boot ; in /5playpen/simonpj/HEAD/nofib/runstdtest ------------------------------------------------------------------------ /bin/sh: 1: /5playpen/simonpj/HEAD/: Permission denied /bin/sh: 1: [: -gt: unexpected operator /bin/sh: 1: [: -ge: unexpected operator

2 2

Shift/reduce conflicts
by Twan van Laarhoven 27 May '13

27 May '13

I just noticed that on HEAD, happy reports for Parser.y.pp: $ happy -agc --strict compiler/stage1/build/Parser.y unused rules: 2 shift/reduce conflicts: 49 reduce/reduce conflicts: 1 But the code claims: 12 October 2012 Conflicts: 43 shift/reduce 1 reduce/reduce So somewhere recently we have picked up 6 additional shift/reduce conflicts. Twan

3 2

fixing up links to commits and ghc source on trac wiki/trackers
by Carter Schonwald 25 May '13

25 May '13

Hey all, Currently the commit/ source file links on trac wiki and tickets are all dead, and while thats not a problem for active ghc devs and such, it does create more friction for new users. My understanding is the previously the file and commit references would point at a haskell.org repository, would it be worth having them point at the github analogues thereof? (and for that matter would that be easy to do, or take up more of the finite ghc dev time?) (in my tickets or the like, i'm by hand doing ghc file / commit links to github to make it easier for myself and others to look up the relevant info.)

5 5

[PATCH 2/2] add arm-unknown-linux to platforms which do not support shared libs
by Karel Gardas 24 May '13

24 May '13

This patch disables shared libs support on arm-unknown-linux platform. It unbreaks ghc-stage2 on this platform after recent Ian's changes in dynamic/shared libs domain. The reason why ghc-stage2 fails when linked with shared libs is still unknown so this is just a workaround at the moment, but it at least recovers previous "correct" behavior of ghc-stage2 on ARM/Linux --- mk/config.mk.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mk/config.mk.in b/mk/config.mk.in index de55f0d..2a03ecf 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -95,7 +95,7 @@ TargetElf = YES endif # Some platforms don't support shared libraries -NoSharedLibsPlatformList = +NoSharedLibsPlatformList = arm-unknown-linux ifeq "$(SOLARIS_BROKEN_SHLD)" "YES" NoSharedLibsPlatformList += i386-unknown-solaris2 -- 1.7.3.2

1 0

[PATCH] set DYNAMIC_GHC_PROGRAMS to NO if platform does not support shared libs
by Karel Gardas 24 May '13

24 May '13

--- mk/config.mk.in | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/mk/config.mk.in b/mk/config.mk.in index 5ef1f5c..0429796 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -138,6 +138,8 @@ else ifeq "$(TargetOS_CPP)" "freebsd" # FreeBSD cannot do proper resolution for $ORIGIN (due to a bug in # rtld(1)), so disable it by default (see #7819). DYNAMIC_GHC_PROGRAMS = NO +else ifeq "$(PlatformSupportsSharedLibs)" "NO" +DYNAMIC_GHC_PROGRAMS = NO else DYNAMIC_GHC_PROGRAMS = YES endif -- 1.7.3.2

1 0

Re: ghc-devs Digest, Vol 117, Issue 43
by Kyle Van Berendonck 23 May '13

23 May '13

Not sure if this applies here, but withSocketsDo is a huge gotcha. It doesn't affect Linux, but all networking code on BSD(?)/Windows that doesn't use it fails to boot with an unfriendly runtime error (and many people leave it out). A warning for this would be good. Regards. On Thu, May 23, 2013 at 8:00 PM, <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Language level heads-up warnings (David Luposchainsky) > 2. RE: Language level heads-up warnings (Simon Peyton-Jones) > 3. Re: Language level heads-up warnings (David Luposchainsky) > 4. RE: Language level heads-up warnings (Simon Peyton-Jones) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 May 2013 13:36:18 +0200 > From: David Luposchainsky <dluposchainsky(a)googlemail.com> > Subject: Language level heads-up warnings > To: ghc-devs(a)haskell.org > Message-ID: <519CADB2.5080904(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello GHC-Devs, > > The discussion on the libraries mailing list brought up the issue of > breaking compatbility in favour of language evolution/sanitation again; > topics mentioned specifically were Prelude's monomorphic > Foldable/Traversable functions, and the Applicative/Monad issue. > > The main arguments of both sides are these: > > (+) We've been aware of certain unfortunate features of Base for a long > time, and we understand very well how to fix this, and what the > consequences are. > > (-) Changing core language features is something you can never forsee > the consequences of. Breaking compatibility should be avoided at all costs. > > (There's also the argument about beginner friendliness, which is not > backed by evidence, so I'll leave it out here.) > > These two seem contradictory, however they have one almost obvious > common ground: we can already write code right now that will be > unaffected by moving Foldable/Traversable/Applicative+Monad to the > Prelude. Suppose all code is written with this in mind, the change is > trivial. > > Which brings us to the actual problem, namely that code is not written > with this in mind. It is easy to forget about the issue in a practical > setting, regardless of how small the required effort is. Therefore, I'd > like to bring forward the idea of "language level heads-up warnings" > (suggestions for better names appreciated). > > Right now, we can only deprecate functions. When used, GHC informs us > "hey, this will work for now, but better use that in the future". > However, this mechanism is too specialized to tackle the problem above: > for example, there is no way to warn a user about a Monad that is not an > Applicative. > > If the community agrees on making one of the "big" changes, what would > you think of adding warnings about language usage? I'm sure over the > course of a couple of GHC releases, the great majority of libraries > would be modified to rectify these warnings again. If you want an > example: "Warning: Monad without Applicative. This will be enforced in a > future language standard." > > These warnings would have to be hardcoded into GHC, but keep in mind > that this is only for very few, relatively high impact changes, and can > be removed once everything is done. In my opinion, this may be a far > better transitional feature than the alternative (adding compatibility > modules, convincing thousands of developers to listen to the people in > favour of the change, ...). > > Greetings, > David > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 May 2013 13:42:10 +0000 > From: Simon Peyton-Jones <simonpj(a)microsoft.com> > Subject: RE: Language level heads-up warnings > To: David Luposchainsky <dluposchainsky(a)googlemail.com>, > "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Message-ID: > < > 59543203684B2244980D7E4057D5FBC1481A7305(a)DB3EX14MBXC306.europe.corp.microsoft.com > > > > Content-Type: text/plain; charset="us-ascii" > > Yes, I think that if the libraries community thought it was important, I > (or indeed someone else) could add a couple of ad-hoc warnings to GHC > without much work. But you'd all need to be clear and specific about what > warnings were wanted, and they'd need to be easy to check (ie no global > program analysis). > > Simon > > -----Original Message----- > From: ghc-devs-bounces(a)haskell.org [mailto:ghc-devs-bounces@haskell.org] > On Behalf Of David Luposchainsky > Sent: 22 May 2013 12:36 > To: ghc-devs(a)haskell.org > Subject: Language level heads-up warnings > > Hello GHC-Devs, > > The discussion on the libraries mailing list brought up the issue of > breaking compatbility in favour of language evolution/sanitation again; > topics mentioned specifically were Prelude's monomorphic > Foldable/Traversable functions, and the Applicative/Monad issue. > > The main arguments of both sides are these: > > (+) We've been aware of certain unfortunate features of Base for a long > time, and we understand very well how to fix this, and what the > consequences are. > > (-) Changing core language features is something you can never forsee the > consequences of. Breaking compatibility should be avoided at all costs. > > (There's also the argument about beginner friendliness, which is not > backed by evidence, so I'll leave it out here.) > > These two seem contradictory, however they have one almost obvious common > ground: we can already write code right now that will be unaffected by > moving Foldable/Traversable/Applicative+Monad to the Prelude. Suppose all > code is written with this in mind, the change is trivial. > > Which brings us to the actual problem, namely that code is not written > with this in mind. It is easy to forget about the issue in a practical > setting, regardless of how small the required effort is. Therefore, I'd > like to bring forward the idea of "language level heads-up warnings" > (suggestions for better names appreciated). > > Right now, we can only deprecate functions. When used, GHC informs us > "hey, this will work for now, but better use that in the future". > However, this mechanism is too specialized to tackle the problem above: > for example, there is no way to warn a user about a Monad that is not an > Applicative. > > If the community agrees on making one of the "big" changes, what would you > think of adding warnings about language usage? I'm sure over the course of > a couple of GHC releases, the great majority of libraries would be modified > to rectify these warnings again. If you want an > example: "Warning: Monad without Applicative. This will be enforced in a > future language standard." > > These warnings would have to be hardcoded into GHC, but keep in mind that > this is only for very few, relatively high impact changes, and can be > removed once everything is done. In my opinion, this may be a far better > transitional feature than the alternative (adding compatibility modules, > convincing thousands of developers to listen to the people in favour of the > change, ...). > > Greetings, > David > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > ------------------------------ > > Message: 3 > Date: Wed, 22 May 2013 15:54:02 +0200 > From: David Luposchainsky <dluposchainsky(a)googlemail.com> > Subject: Re: Language level heads-up warnings > To: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Message-ID: <519CCDFA.40009(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 2013-05-22 15:42, Simon Peyton-Jones wrote: > > Yes, I think that if the libraries community thought it was > > important, I (or indeed someone else) could add a couple of ad-hoc > > warnings to GHC without much work. But you'd all need to be clear and > > specific about what warnings were wanted, and they'd need to be easy > > to check (ie no global program analysis). > > Simon, > > good to hear that it's worth thinking about. > > I'm not sure what exactly "no global program analysis" means here. Where > would the boundaries of such warnings be? I could imagine problems if > Applicative/Monad are defined in separate packages/modules (although > that may be rare in practice). > > Greetings, > David > > > > ------------------------------ > > Message: 4 > Date: Wed, 22 May 2013 13:59:03 +0000 > From: Simon Peyton-Jones <simonpj(a)microsoft.com> > Subject: RE: Language level heads-up warnings > To: David Luposchainsky <dluposchainsky(a)googlemail.com>, > "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Message-ID: > < > 59543203684B2244980D7E4057D5FBC1481A745D(a)DB3EX14MBXC306.europe.corp.microsoft.com > > > > Content-Type: text/plain; charset="us-ascii" > > I'm just saying that GHC has to be able to check while compiling one > module, ie as now. (It can see details of the things it imports, > obviously, since it needs to know that to compile the module) > > | -----Original Message----- > | From: David Luposchainsky [mailto:dluposchainsky@googlemail.com] > | Sent: 22 May 2013 14:54 > | To: ghc-devs(a)haskell.org > | Cc: Simon Peyton-Jones > | Subject: Re: Language level heads-up warnings > | > | On 2013-05-22 15:42, Simon Peyton-Jones wrote: > | > Yes, I think that if the libraries community thought it was > | > important, I (or indeed someone else) could add a couple of ad-hoc > | > warnings to GHC without much work. But you'd all need to be clear and > | > specific about what warnings were wanted, and they'd need to be easy > | > to check (ie no global program analysis). > | > | Simon, > | > | good to hear that it's worth thinking about. > | > | I'm not sure what exactly "no global program analysis" means here. Where > | would the boundaries of such warnings be? I could imagine problems if > | Applicative/Monad are defined in separate packages/modules (although > | that may be rare in practice). > | > | Greetings, > | David > > > > ------------------------------ > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > End of ghc-devs Digest, Vol 117, Issue 43 > ***************************************** >

1 0

Language level heads-up warnings
by David Luposchainsky 22 May '13

22 May '13

Hello GHC-Devs, The discussion on the libraries mailing list brought up the issue of breaking compatbility in favour of language evolution/sanitation again; topics mentioned specifically were Prelude's monomorphic Foldable/Traversable functions, and the Applicative/Monad issue. The main arguments of both sides are these: (+) We've been aware of certain unfortunate features of Base for a long time, and we understand very well how to fix this, and what the consequences are. (-) Changing core language features is something you can never forsee the consequences of. Breaking compatibility should be avoided at all costs. (There's also the argument about beginner friendliness, which is not backed by evidence, so I'll leave it out here.) These two seem contradictory, however they have one almost obvious common ground: we can already write code right now that will be unaffected by moving Foldable/Traversable/Applicative+Monad to the Prelude. Suppose all code is written with this in mind, the change is trivial. Which brings us to the actual problem, namely that code is not written with this in mind. It is easy to forget about the issue in a practical setting, regardless of how small the required effort is. Therefore, I'd like to bring forward the idea of "language level heads-up warnings" (suggestions for better names appreciated). Right now, we can only deprecate functions. When used, GHC informs us "hey, this will work for now, but better use that in the future". However, this mechanism is too specialized to tackle the problem above: for example, there is no way to warn a user about a Monad that is not an Applicative. If the community agrees on making one of the "big" changes, what would you think of adding warnings about language usage? I'm sure over the course of a couple of GHC releases, the great majority of libraries would be modified to rectify these warnings again. If you want an example: "Warning: Monad without Applicative. This will be enforced in a future language standard." These warnings would have to be hardcoded into GHC, but keep in mind that this is only for very few, relatively high impact changes, and can be removed once everything is done. In my opinion, this may be a far better transitional feature than the alternative (adding compatibility modules, convincing thousands of developers to listen to the people in favour of the change, ...). Greetings, David

2 3