February 2013 - ghc-devs

Why write out-of-line PrimOps in Cmm?
by Alexander Kjeldaas 14 Feb '13

14 Feb '13

I was looking at the eventlog code, and I wanted to move processing of a full eventlog buffer into Haskell, instead of the now fixed behavior of writing the data to a file. To do this, I though that having a haskell process blocked on an MVar, or Chan would be nice, and then some way to signal the process. But the low-level PrimOps for MVars, takeMVar, tryTakeMVar etc are in PrimOps.cmm and I don't know how to call them from the RTS. This lead me to question what the point of out-of-line PrimOps in PrimOps.cmm is. I don't think the commentary covers this. http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps So why aren't all the stuff in PrimOps.cmm just "ccall" wrappers around C implementations? Wouldn't that in general be more flexible for the RTS? Alexander

2 1

Merging polykinded typeable
by José Pedro Magalhães 14 Feb '13

14 Feb '13

Hi Simon, I think the polykinded stuff is now ready to merge. A few issues remain: 1) dynamic004 fails when run without optimisation (it times out). This is potentially worrying. It's doing a comparison of the typeReps of nested lists, up to 1000 nested lists. This worked fine before with -O0, but not anymore. With -O1 it works fine, though. Hopefully it's ok to just run this test with optimisation only, and assume that no one should expect great performance of Typeable on huge types with -O0... 2) With -XAutoDeriveTypeable, if you also derive Typeable instances in the module, you'll get a "duplicate instances" error. I think you'd rather have this be a warning, so that the semantics if -XAutoDeriveTypeable would be "derive Typeable for types/classes for which Typeable is not yet derived", instead of "derive Typeable for all types/classes declared". But I found this a bit tricky to check for, and as such haven't implemented it yet. I can point you to the place in the code where this is happening. 3) I don't know where to put `data Proxy t = Proxy`. I kind of need it for defining things in the library, but it doesn't need to be exported to the user, as we now have `typeRep :: forall proxy. proxy a -> TypeRep`. I do export it from Data.Typeable.Internal, because I want to use it in Data.Typeable, but I don't re-export it from Data.Typeable. This is, in principle, all fine, but I think that the Proxy datatype is so commonplace that it should probably be defined in GHC somewhere, so that it doesn't start showing up repeated in all sorts of libraries. Perhaps we can just put it in GHC.Exts? Either way, I'd like to merge this to the master branch now, and deal with the issues above after that. This is because it's tiresome to keep my branch up-to-date with master, and I don't think the remaining issues are blocking, or will affect the stability of the master branch. Regarding documentation, I've updated the user's guide to mention the new behaviour of Typeable, the fact that you can't define instances by hand, and the new flags (-XAutoDeriveTypeable and -fwarn-typeable-instances). I've written a blog post in the past about the new features ( http://hauptwerk.blogspot.co.uk/2012/11/coming-soon-in-ghc-head-poly-kinded…) and I'll write another one about how to make sure your old Typeable code works in the new version. If you want to have a look at the code before merging, let me know, and I'll update the new-typeable branch. (I've stopped working on that branch, and now I have a local branch ready for merging with a single commit to master). Cheers, Pedro

2 3

Vector primops sizes
by Michael Baikov 14 Feb '13

14 Feb '13

Recently merged vector primops support only 16 bytes operands - Int32 x 4, Double x 2 and so on. Current AVX instructions support 256 bit operands and with simple cut'n'paste work it's possible to support at least Double x 4 operands. I made those changes and GHC generates (using llvm) proper AVX code using ymm registers. Also it might make sense to support primops for vector types larger than any currently supported primitive types - I have those changes in my branch as well and llvm generates pretty good code as well - those changes might be useful to provide access for llvm shufflevector instruction or writing high performance processing of large vectors - with less potential overhead. Do we want to support larger vectors directly or ghc should be made smart enough to fuse operations with vector primops performed in parallel into larger vectors/registers for llvm? Do we want to provide access to llvm shufflevector instruction?

5 7

[PATCH] base: use --target as target, not uname
by Sergei Trofimovich 14 Feb '13

14 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- configure.ac | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b679520..7553a7a 100644 --- a/configure.ac +++ b/configure.ac @@ -5,17 +5,23 @@ AC_CONFIG_SRCDIR([include/HsBase.h]) AC_CONFIG_HEADERS([include/HsBaseConfig.h include/EventConfig.h]) +AC_CANONICAL_BUILD +AC_CANONICAL_HOST +AC_CANONICAL_TARGET + AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() -case `uname -s` in - MINGW*|CYGWIN*) +AC_MSG_CHECKING(for WINDOWS platform) +case $host in + *mingw32*|*cygwin*) WINDOWS=YES;; *) WINDOWS=NO;; esac +AC_MSG_RESULT($WINDOWS) # do we have long longs? AC_CHECK_TYPES([long long]) -- 1.8.1.2

3 4

[PATCH] Fix comment to use correct option name
by shelarcy 14 Feb '13

14 Feb '13

Hello, Source Code Comments decribe wrong (old) option name in two place. I made patch to fix that. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

2 1

[PATCH] hsc2hs: use configuration of current compiler, not built
by Sergei Trofimovich 13 Feb '13

13 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 of such kind: "/usr/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -static -H32m -O -w -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.0 -package containers-0.5.0.0 -package directory-1.2.0.0 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/Paths_hsc2hs.o utils/hsc2hs/dist/build/Main.o: In function `s4cN_info': (.text+0x182): undefined reference to `GetModuleFileNameW' Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- Main.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Main.hs b/Main.hs index 30b3a2d..5309179 100644 --- a/Main.hs +++ b/Main.hs @@ -11,7 +11,7 @@ -- See the documentation in the Users' Guide for more details. #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) -#include "../../includes/ghcconfig.h" +#include "ghcconfig.h" #endif import Control.Monad ( liftM, forM_ ) -- 1.8.1.1

2 2

Re: GHC 7.8 release?
by Simon Marlow 13 Feb '13

13 Feb '13

On 13/02/13 07:06, wren ng thornton wrote: > On 2/12/13 3:37 AM, Simon Marlow wrote: >> One reason for the major version bumps is that base is a big >> conglomeration of modules, ranging from those that hardly ever change >> (Prelude) to those that change frequently (GHC.*). For example, the new >> IO manager that is about to get merged in will force a major bump of >> base, because it changes GHC.Event. The unicode support in the IO >> library was similar: although it only added to the external APIs that >> most people use, it also changed stuff inside GHC.* that we expose for a >> few clients. >> >> The solution to this would be to split up base further, but of course >> doing that is itself a major upheaval. However, having done that, it >> might be more feasible to have non-API-breaking releases. > > While it will lead to much wailing and gnashing of teeth in the short > term, if it's feasible to break GHC.* off into its own package, then I > think we should. The vast majority of base seems quite stable or else is > rolling along at a reasonable pace. And yet, every time a new GHC comes > out, there's a new wave of fiddling the knobs on cabal files because > nothing really changed. On the other hand, GHC.* moves rather quickly. > Nevertheless, GHC.* is nice to have around, so we don't want to just > hide that churning. The impedance mismatch here suggests that they > really should be separate packages. I wonder whether GHC.* should be > moved in with ghc-prim, or whether they should remain separate... > > But again, this depends on how feasible it would be to actually split > the packages apart. Is it feasible? So I think we'd need to add another package, call it ghc-base perhaps. The reason is that ghc-prim sits below the integer package (integer-simple or integer-gmp). It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. In fact, maybe you want to do it exactly like this for simplicity - all the code goes in ghc-base. There would be some impact on compilation time, as we'd have twice as many interfaces to read. I believe Ian has done some experiments with splitting base further, so he might have more to add here. Cheers, Simon

5 4

Re: [commit: ghc] master: add $(CrossCompilePrefix) to hp2ps (#7639) (b0fad0c)
by Gabor Greif 13 Feb '13

13 Feb '13

Hi Simon, all, this reminds me of a local patch (see below), that allows one to keep different 'build.mk' customizations for cross targets and normal builds at the same time, so the error-prone manual swapping of these is automated. OK to push? Cheers, Gabor ##################################################### [ggreif-hc_stm-r6.0][!1180] git show b716a1132010cccbf87612b4c1b0816c0585eb91 commit b716a1132010cccbf87612b4c1b0816c0585eb91 Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Nov 23 17:54:00 2012 +0100 allow different customizations per cross target diff --git a/mk/custom-settings.mk b/mk/custom-settings.mk index e64bb36..3390888 100644 --- a/mk/custom-settings.mk +++ b/mk/custom-settings.mk @@ -5,7 +5,7 @@ ifeq "$(Validating)" "YES" include mk/validate-settings.mk -include mk/validate.mk else --include mk/build.mk +-include mk/$(CrossCompilePrefix)build.mk endif ifeq "$(BINDIST)" "YES" On 2/1/13, Simon Marlow <marlowsd(a)gmail.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/b0fad0c580e0dd52d73743a877608… > >>--------------------------------------------------------------- > > commit b0fad0c580e0dd52d73743a877608af60408ec89 > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Thu Jan 31 12:05:03 2013 +0000 > > add $(CrossCompilePrefix) to hp2ps (#7639) > >>--------------------------------------------------------------- > > utils/hp2ps/ghc.mk | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/utils/hp2ps/ghc.mk b/utils/hp2ps/ghc.mk > index 59791c8..097f912 100644 > --- a/utils/hp2ps/ghc.mk > +++ b/utils/hp2ps/ghc.mk > @@ -16,7 +16,7 @@ utils/hp2ps_dist_C_SRCS = AreaBelow.c Curves.c > Error.c Main.c \ > Axes.c Dimensions.c Key.c PsFile.c > Shade.c \ > Utilities.c > utils/hp2ps_dist_EXTRA_LIBRARIES = m > -utils/hp2ps_dist_PROG = hp2ps$(exeext) > +utils/hp2ps_dist_PROG = $(CrossCompilePrefix)hp2ps$(exeext) > utils/hp2ps_dist_INSTALL = YES > utils/hp2ps_dist_INSTALL_INPLACE = YES > > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 5

RE: [GHC] #7631: Allow to differentiate between newtypes and datatypes when using Generics
by Simon Peyton-Jones 13 Feb '13

13 Feb '13

Thanks for fixing Pedro Our usual test-case nomenclature would be to use "T7631" as the test name. Not worth changing now. Simon | -----Original Message----- | From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets-bounces@haskell.org] | On Behalf Of GHC | Sent: 13 February 2013 10:44 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7631: Allow to differentiate between newtypes and | datatypes when using Generics | | #7631: Allow to differentiate between newtypes and datatypes when using | Generics | ---------------------------------+------------------------------------------ | Reporter: Feuerbach | Owner: dreixel | Type: feature request | Status: closed | Priority: normal | Component: libraries (other) | Version: 7.7 | Resolution: fixed | Keywords: generics | Os: Unknown/Multiple | Architecture: Unknown/Multiple | Failure: None/Unknown | Blockedby: | Blocking: | Related: | | ---------------------------------+------------------------------------------ | Changes (by dreixel): | | * status: new => closed | * resolution: => fixed | | | Comment: | | Done. New test is `GenNewtype`. | | -- | Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7631#comment:4> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

Re: RFC: Singleton equality witnesses
by Gabor Greif 13 Feb '13

13 Feb '13

Richard and all, sorry for reviving such an ancient thread, but I'd like to move this forward a bit :-) In the meantime Iavor has added the (:~:) GADT, so I can reuse it. It has been commented that it could (finally) end up in GHC.Exts, but for now I want my changes minimized. I have added the class @SingEquality@ and have implemented the @sameSing@ method in terms of Iavor's functions. This is rather pretty now. Here is the patch: ------------------------------------------------------ $ git show 0eacf265255b9c5e0191b6a5100f3076b8eb5520 commit 0eacf265255b9c5e0191b6a5100f3076b8eb5520 Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Nov 30 12:23:28 2012 +0100 Introduce the SingEquality class with customizable witness type and a sameSing method that may produce the latter. diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs index f8b759e..5546a5a 100644 --- a/GHC/TypeLits.hs +++ b/GHC/TypeLits.hs @@ -30,7 +30,7 @@ module GHC.TypeLits , type (-) -- * Comparing for equality - , type (:~:) (..), eqSingNat, eqSingSym + , type (:~:) (..), eqSingNat, eqSingSym, SingEquality (..) -- * Destructing type-nat singletons. , isZero, IsZero(..) @@ -56,6 +56,7 @@ import Unsafe.Coerce(unsafeCoerce) -- import Data.Bits(testBit,shiftR) import Data.Maybe(Maybe(..)) import Data.List((++)) +import Control.Monad (guard, return, (>>)) -- | (Kind) A kind useful for passing kinds as parameters. data OfKind (a :: *) = KindParam @@ -133,6 +134,11 @@ class (kparam ~ KindParam) => SingE (kparam :: OfKind k) where type DemoteRep kparam :: * fromSing :: Sing (a :: k) -> DemoteRep kparam +class (kparam ~ KindParam, SingE (kparam :: OfKind k)) => SingEquality (kparam :: OfKind k) where + type SameSing kparam :: k -> k -> * + type SameSing kparam = (:~:) + sameSing :: Sing a -> Sing b -> Maybe (SameSing kparam a b) + instance SingE (KindParam :: OfKind Nat) where type DemoteRep (KindParam :: OfKind Nat) = Integer fromSing (SNat n) = n @@ -141,6 +147,12 @@ instance SingE (KindParam :: OfKind Symbol) where type DemoteRep (KindParam :: OfKind Symbol) = String fromSing (SSym s) = s +instance SingEquality (KindParam :: OfKind Nat) where + sameSing = eqSingNat + +instance SingEquality (KindParam :: OfKind Symbol) where + sameSing = eqSingSym + {- | A convenient name for the type used to representing the values for a particular singleton family. For example, @Demote 2 ~ Integer@, and also @Demote 3 ~ Integer@, but @Demote "Hello" ~ String@. -} ------------------------------------------------------ Regarding Richard's decidable equality suggestion, I think this would be the next step. IIRC, empty case expressions have been implemented, so GHC HEAD should be prepared. What do you think? Okay to push in this form? Cheers, Gabor On 12/5/12, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > I don't think anything here is *high priority*, just musings on how best to > move forward. > > About empty case, consider this: > >> data a :~: b where >> Refl :: a :~: a >> >> absurd :: True :~: False -> a > > Now, I want to write a term binding for absurd. GHC can figure out that > (True :~: False) is an empty type. So, if we have (absurd x = case x of …), > there are no valid patterns, other than _, that could be used. Instead of > writing (absurd _ = undefined), I would much prefer to write (absurd x = > case x of {}). Why? If I compile with -fwarn-incomplete-patterns and > -Werror, then the latter has no possible source of partiality and yet > compiles. The former looks dangerous, and GHC doesn't check to make sure > that, in fact, the function can never get called. > > The bottom line, for me at least, is that I want to avoid the partial > constructs (incomplete patterns, undefined, etc) in Haskell as much as > possible, especially when I'm leveraging the type system to a high degree. > The lack of empty case statements forces me to use undefined where it isn't > really necessary. > > I'll leave it to others to comment on TypeRep, as I'm a little hazy there > myself. > > Richard > >

5 14