- ghc-devs - Haskell.org

Re: [commit: ghc] master: Add OverloadedLists, allowing list syntax to be overloaded (3234a4a)
by Johan Tibell 14 Feb '13

14 Feb '13

Did we end up supporting a length hint so we can efficiently create e.g. vectors that need upfront allocation of the space before writing the elements? Or is the plan to do like we for String and have literals desugar to e.g. fromIntList# :: Int# -> Ptr Int# -> [Int] intList# :: Ptr Int# intList# = [1,2,3,4]# myliteral = fromList (fromIntList# 4 intList#) On Thu, Feb 14, 2013 at 6:56 AM, Simon Peyton Jones <simonpj(a)microsoft.com>wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > > http://hackage.haskell.org/trac/ghc/changeset/3234a4ade7204c4206831b4c1dc4a… > > >--------------------------------------------------------------- > > commit 3234a4ade7204c4206831b4c1dc4a8b23624cc6b > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Feb 14 13:04:14 2013 +0000 > > Add OverloadedLists, allowing list syntax to be overloaded > > This work was all done by > Achim Krause <achim.t.krause(a)gmail.com> > George Giorgidze <giorgidze(a)gmail.com> > Weijers Jeroen <jeroen.weijers(a)uni-tuebingen.de> > > It allows list syntax, such as [a,b], [a..b] and so on, to be > overloaded so that it works for a variety of types. > > The design is described here: > http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists > > Eg. you can use it for maps, so that > [(1,"foo"), (4,"bar")] :: Map Int String > > The main changes > * The ExplicitList constructor of HsExpr gets witness field > * Ditto ArithSeq constructor > * Ditto the ListPat constructor of HsPat > > Everything else flows from this. > > compiler/deSugar/Check.lhs | 15 ++-- > compiler/deSugar/Coverage.lhs | 16 +++- > compiler/deSugar/DsArrows.lhs | 2 +- > compiler/deSugar/DsExpr.lhs | 42 +++++++---- > compiler/deSugar/DsMeta.hs | 7 +- > compiler/deSugar/Match.lhs | 31 ++++++-- > compiler/hsSyn/Convert.lhs | 6 +- > compiler/hsSyn/HsExpr.lhs | 12 ++- > compiler/hsSyn/HsPat.lhs | 12 ++- > compiler/hsSyn/HsUtils.lhs | 6 +- > compiler/main/DynFlags.hs | 2 + > compiler/parser/Parser.y.pp | 12 ++-- > compiler/parser/RdrHsSyn.lhs | 4 +- > compiler/prelude/PrelNames.lhs | 26 ++++++- > compiler/prelude/TysWiredIn.lhs | 2 +- > compiler/rename/RnEnv.lhs | 18 +++-- > compiler/rename/RnExpr.lhs | 45 +++++++---- > compiler/rename/RnPat.lhs | 21 ++++- > compiler/typecheck/TcExpr.lhs | 111 ++++++++++++++++---------- > compiler/typecheck/TcHsSyn.lhs | 30 ++++++-- > compiler/typecheck/TcHsType.lhs | 2 +- > compiler/typecheck/TcPat.lhs | 14 +++- > compiler/typecheck/TcRnDriver.lhs | 2 +- > compiler/typecheck/TcRnTypes.lhs | 2 + > compiler/utils/Outputable.lhs | 4 +- > docs/users_guide/flags.xml | 7 ++ > docs/users_guide/glasgow_exts.xml | 157 > +++++++++++++++++++++++++++++++++++++ > 27 files changed, 469 insertions(+), 139 deletions(-) > > > Diff suppressed because of size. To see it, use: > > git show 3234a4ade7204c4206831b4c1dc4a8b23624cc6b > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

Today's validate failures
by Simon Marlow 14 Feb '13

14 Feb '13

On x86_64/Linux: Unexpected passes: perf/should_run T149 (normal) Unexpected failures: perf/compiler T3064 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) simplCore/should_compile T3717 [stderr mismatch] (optasm) simplCore/should_compile T3772 [bad stdout] (normal) simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile T4930 [stderr mismatch] (optasm) simplCore/should_compile T7360 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm)

3 2

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