- ghc-devs - Haskell.org

Do we need to maintain PrimRep.VecRep?
by Ömer Sinan Ağacan 08 Jun '16

08 Jun '16

I have some code that does things depending on PrimReps of terms and so I have to handle VecRep there. To understand what VecRep exactly is and how to use it I looked at its uses, and all I can find was that we have a wired-in DataCon `vecRepDataCon` which has a type that I thought should have VecRep PrimRep, but when I test in GHCi I see that its PrimRep is PtrRep: λ> map typePrimRep (map dataConRepType (tyConDataCons runtimeRepTyCon)) [PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep,PtrRep] (This DataCon is not exported and only used in runtimeRepTyCon) So I think VecRep may not be in use at the moment. Do we still need to maintain it? What's the use case? Can anyone show me a Core term that has a type whose PrimRep is VecRep? Thanks..

3 5

Testsuite total failure on Windows
by Simon Peyton Jones 07 Jun '16

07 Jun '16

Thomie Is this you working on my show-stopping problem with the tetssuite? sh: line 0: cd: c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw123.T9662: No such file or directory If so, thank you! If not, might you look (email attached). I am so stuck. Even a commit to roll back would be fine. But I don't know where to start. Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 07 June 2016 20:33 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/thomie: Testsuite driver: always quote | opts.testdir (9bee6ef) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/thomie | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell… | rg%2ftrac%2fghc%2fchangeset%2f9bee6ef2fb5c280e061144368d75a0ef947e68c9%2fghc& | data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c511d448661614206dbb808d38f0 | b2182%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uOhvqGkrC3j2fRIYwTeDZ28%2f | x58jMs5jh1BdUDMiERY%3d | | >--------------------------------------------------------------- | | commit 9bee6ef2fb5c280e061144368d75a0ef947e68c9 | Author: Thomas Miedema <thomasmiedema(a)gmail.com> | Date: Tue Jun 7 15:59:15 2016 +0200 | | Testsuite driver: always quote opts.testdir | | This makes sure the testsuite keeps working when testdir contains | backward slashes. | | | >--------------------------------------------------------------- | | 9bee6ef2fb5c280e061144368d75a0ef947e68c9 | testsuite/driver/runtests.py | 2 +- | testsuite/driver/testlib.py | 42 +++++++++++++++++++------------ | -- | testsuite/tests/cabal/cabal01/Makefile | 2 +- | testsuite/tests/ghci/linking/dyn/all.T | 4 ++-- | testsuite/tests/rename/prog006/Makefile | 2 +- | 5 files changed, 29 insertions(+), 23 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies-harder -- | ignore-space-at-eol --cc 9bee6ef2fb5c280e061144368d75a0ef947e68c9 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c511d448661614206dbb | 808d38f0b2182%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2%2bhPH%2bwQOwvVTE | QdWNZZBmPziSwaudLrYp4DCOGXct8%3d

3 2

Help! Windows build broken in teestsuite
by Simon Peyton Jones 07 Jun '16

07 Jun '16

Aargh! The Windows build is broken again. This time it’s the testsuite. It seems to be trying to run the test in a temp directory, and failing to find the directory. Thomie, could this be something to do with your work on the testsuite? Please fix! Or tell me what to revert. It leaves me stuck. Thanks Simon /cygdrive/c/code/HEAD/testsuite/tests/indexed-types/should_fail$ make TEST=T9662 PYTHON="python" "python" ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=0 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e cleanup=True --rootdir=. --configfile=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/cygdrive/c/code/HEAD/testsuite"' --config 'compiler="/cygdrive/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/cygdrive/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' --config 'hp2ps="/cygdrive/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/cygdrive/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../../timeout/install-inplace/bin/timeout.exe"' \ --only=T9662 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at 06/07/16 07:45:13 GMT Summer Time ====> Scanning ./all.T =====> T9662(normal) 1 of 1 [0, 0, 0] cd c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw\1\2\3\.\T9662 && "C:/code/HEAD/inplace/bin/ghc-stage2.exe" -c T9662.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history > T9662.comp.stderr 2>&1 sh: line 0: cd: c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw123.T9662: No such file or directory

1 0

Proposal: Left-Associative Semigroup Operator Alias in "Data.Semigroup"
by Herbert Valerio Riedel 06 Jun '16

06 Jun '16

Hello! In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>) subtly conflicts with definitions of (<>) in pretty printing APIs, for which the left-associative variant is sometimes desirable. This subtle overloading of (<>) is error-prone, as one has to remember which version of (<>) is currently in scope in order to be able to reason about non-trivial expressions involving this operator. This proposal is an attempt to resolve this unfortunate and confusing situation by completing the `Semigroup`/`Monoid` vocabulary with a standard left-associative alias. Please see https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp for more details. Discussion period: 4 weeks

2 1

x86-64 unknown-linux
by Richard Eisenberg 06 Jun '16

06 Jun '16

Hi devs, I would like to download GHC 8 binaries for Arch Linux on an x86-64 architecture. I assume I'm looking for an unknown-linux build, and it looks like what I want is a Tier 1 platform, according to https://ghc.haskell.org/trac/ghc/wiki/Platforms Yet I don't see this release in https://downloads.haskell.org/~ghc/8.0.1/ Can you help? Thanks! Richard

2 2

Why does the LLVM invoke command-line tools instead of using the library?
by Nicola Gigante 05 Jun '16

05 Jun '16

Hi all, while looking at the GHC 8 Trac page I encountered the page about the plans for the improved LLVM backend: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend <https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend> I know nearly nothing about the internals of the GHC backend so I may be asking something trivial, but from reading that page I understand that GHC currently calls LLVM command line tools to optimize and compile the IR, is it right? LLVM is a C++ library, but it also exports a portable and stable C API which I think is already covered by the llvm-general package. So as someone who worked on LLVM in the past, and appreciated its library-based integration-friendly design I’m wondering why is GHC using the command line tools instead of linking to the library? Best Regards, Nicola

2 1

Break Base Faster
by Ericson, John 02 Jun '16

02 Jun '16

I'm excited for the various proposals to clean up base's warts, but the time-frames over which to distribute the breaking changes are just so long---approaching a decade IIUC for Monad-Fail for example. First off, If anybody has some links to where/why the long transitions were proposed, I'd love to read them as I am not sure of the exact motivation. If, in fact, we could just break everything all at once without pissing people off, then the rest of my email can be discarded :). As I see it, the underlying issue here is that we are assuming each GHC version will only work with one version of base. Well, as it stands, none of the proposed *breaking* changes interact much with the language itself, so the relationship between base and GHC is less constrained than it seems. I went on #ghc and learned that multiple bases was tried in the past for Haskell98 compatability and exceptions in 6.10, and the experience was unpleasant. But I hope that Cabal support for multiple versions of a package in a single build plan ( http://www.well-typed.com/blog/2015/07/cabal-setup-deps/) Stackage package sets, and split base can improve the experience this time around. Cabal improvements perhaps open the door to linking packages that use different base versions together, with blanket instances from e.g. (new.Monad, new.MonadFail) => old.Monad to ease the pain. With package-qualified-imports, I hope we can have legacy base import from base, but otherwise we can make them both rely on other packages (especially with split-base), from which base will just re-export definitions. In the event that linking both bases is impossible, or the blanket instances are insufficient for making the same library work with other libraries requiring either base. Stackage will allow for curating separate package sets for each base version. I imagine the prospect of splitting the Haskell ecosystem with multiple bases sounds daunting to some, but package sets like Stackage provides provide enough cohesion *within* the ecosystem centered around each base that I'd wager we'd still be in better shape than how things were circa 6.10. Finally, split base I hope will generally make experimentation easier by allowing packages to specify more exactly what they need, and lower the barrier of entry for new bases. As mentioned above, it allow for legacy base to more more naturally contain blanket instances of normal base's classes by avoiding package-qualified imports. For the first release with split base, I'd follow Rust's example where base is a "facade" and the packages that back it are initially unstable like ghc-prim. According to https://ghc.haskell.org/trac/ghc/wiki/SplitBase#Non-Obviousinterdependencies, the completion of MonadFail is in fact a big prerequisite to an acyclic split base. If my previous statements are correct on the benefits of split base, this puts us in an pleasant situation where MonadFail can speed up split base, and split base can speed up Monad fail. As a final thought, I think that multiple bases is far superior than taking the "-compat" route a la transformers-compat: IMO the need to change upstream code to use "-compat" severely negates the benefits. John

2 1

Deriving Generic1
by Simon Peyton Jones 01 Jun '16

01 Jun '16

Ryan If you compile newtype Compose f g a = Compose (f (g a)) deriving( Generic1 ) and do –show-iface on the resulting hi file, you’ll see $fGeneric1Compose :: forall (f :: * -> *) k (g :: k -> *). Functor f => Generic1 (Compose f g) I was expecting to see $fGeneric1Compose :: forall (f :: k1 -> *) k (g :: k -> k1). (..something..) => Generic1 (Compose f g) Otherwise the Generic1 instance only works if its first argument has kind (* -> *). Is that the intention? Maybe so… Simon

2 1

Core of a whole package
by Alberto Sadde O. 01 Jun '16

01 Jun '16

Hi, I am trying to get the Core of a whole package. I have been using the GHC API to get the Core of each file in a package but I have a problems with non-exposed modules of the package. I might not been setting up all the flags correctly but at this point I am completely lost!! I posted a question on S.O. <http://stackoverflow.com/questions/37410615/ghc-api-compile-whole-package-t…> The code I am using is in the above link. Any help/comments/tips would be greatly appreciated! Many thanks, Alberto

2 5

Re: Strictness/laziness warnings
by David Feuer 30 May '16

30 May '16

Mostly I'm looking for a rough estimate. Some false positives and false negatives are tolerable. If I have something like f :: Int -> Maybe String -> String f _ Nothing = "Hi there!" f n (Just b) = if n > 0 then show b else "whatever" then I'd likely be interested in a warning about the fact that the first case is not strict in the Int and the second is. I'd also likely be interested in a warning about the first case because I'm taking a small primitive value (Int) and doing so lazily. On Sun, May 29, 2016 at 11:04 PM, wren romano <winterkoninkje(a)gmail.com> wrote: > On Sat, May 28, 2016 at 10:14 PM, Edward Kmett <ekmett(a)gmail.com> wrote: >> How would you detect the argument only being forced some of the time? Sounds >> like a lot of long-term cross-module book-keeping. > > Sounds to me like what the strictness analyzer is already doing, ne? I > missed the beginning of the thread, so might be off base. If it's more > about noticing when the use sites of a given function have some > pattern not captured by the strictness determined from the function's > definition, then it seems like we shouldn't need /cross/-module > bookkeeping: we should be able to just tabulate how each use site's > strictness does/doesn't match the interface's spec. > > -- > Live well, > ~wren

2 1