- ghc-devs - Haskell.org

Re: More failure
by Andrey Mokhov 10 Dec '19

10 Dec '19

Hi Simon, (Re-sending from the email address that's allowed on the mailing list.) > Ugh. That's not a very happy state of affairs, is it? It didn't happen with 'make'. > Is it a fundamental problem, or just not yet fixed? I think this is not a fundamental problem, but the problem of getting dependencies right. In this case, the complexity comes from the fact that a single invocation of GHC produces a set of files, and which set depends on the command line flags, which are in turn determined dynamically by reading environment settings (specifically, `platformSupportsSharedLibs`). Such rules are hard to describe precisely, because build systems are tuned to the typical case where we statically know, for every output file, which rule produces it -- recall the Tasks = k -> Maybe Task function from our paper. In this case, we deal with something like k -> f (Maybe Task) instead, i.e. with `f` around the Maybe. The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy. (I never really had a chance to look at dynamic builds, since they are not supported on Windows. I guess I should finally find a Linux box for Hadrian.) Cheers, Andrey

2 2

Running test with the stage-1 compiler
by Simon Peyton Jones 10 Dec '19

10 Dec '19

Apparently 'sh validate' now uses Hadrian. This has broken one of my workflows: * build the stage1 compiler * cd testsuite/tests * make stage=1 That is, run the testsuite with the stage-1 compile. (This often produces a small test case for a compiler crash, much easier than debugging GHC compiling itself.) How do I do this? Thanks Simon

4 4

More failure
by Simon Peyton Jones 09 Dec '19

09 Dec '19

More pain. I said sh validate --fast --no-clean and got this output Error when running Shake build system: at action, called at src/Rules.hs:71:19 in main:Rules at need, called at src/Rules.hs:93:5 in main:Rules * Depends on: _validatebuild/stage1/lib/package.conf.d/base-4.14.0.0.conf at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register * Depends on: _validatebuild/stage1/libraries/base/build/libHSbase-4.14.0.0-ghc8.11.0.20191201.so at need, called at src/Rules/Library.hs:146:5 in main:Rules.Library * Depends on: _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o at &%>, called at src/Rules/Compile.hs:54:7 in main:Rules.Compile * Depends on: _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_hi at error, called at src/Development/Shake/Internal/Rules/Files.hs:245:13 in shake-0.18.3-593067565aafb558d09b4352b8abc327d8911a39a0e9abab2804b002b1ae536e:Development.Shake.Internal.Rules.Files * Raised the exception: Error, &%> rule failed to produce 1 file (out of 2) _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_hi - MISSING I think I'm going to have to revert to 'sh validate -legacy'. Please let me know when I should try again with Hadrian. Simon

2 2

re-engineering overloading and rebindable syntax
by Richard Eisenberg 05 Dec '19

05 Dec '19

Hi devs, I've recently discovered the `overloaded` package, which allows us to do very clever things around overloading in a source plugin. In my over-excitement, I wondered about removing GHC's capability to do overloading and rebindable syntax, leaving those features to be implemented by source plugins. To first approximation, this would work well. But there are many drawbacks: poorer error messages, worries around the trustworthiness of non-GHC source plugins, cross compilation, etc. The idea is not viable right now. Yet: I wonder if we couldn't take the general idea of doing this as source plugins, without actually implementing it that way. Currently, there is a good deal of code scattered throughout GHC to deal with overloaded constructs (numbers, strings, lists) and rebindable syntax. These make their presence known in a number of places in HsExpr and friends, and various machinations in the renamer and type-checker are needed to deal with them. The type-checker for rebindable syntax is buggy (#14963 and friends); the fix will involve likely *more* code devoted to rebindable syntax (albeit simpler code than what we have today). If, say, the renamer implemented all overloading and rebindable syntax just by a straightforward syntactic transformation, this would all be much simpler. (Actually, it could also be done in the parser, but I think the renamer is a better home.) Pros: - much, much simpler implementation - localized implementation: nothing in the type checker at all nor in HsSyn Con: - worse error messages, which would now refer to the desugared code instead of the user-written code. I can't think of any other downside. How can we mitigate this? By expanding the possibilities of a SrcSpan. A SrcSpan is really a description of the provenance of a piece of AST. Right now, it considers two possibilities: that the code came from a specific stretch of rows and columns in an input file, or that the code came from elsewhere. Instead, we can expand (and perhaps rename) SrcSpan to include more possibilities. In support of my idea above, we could now have a SrcSpan that says some AST came from overloading. Such code is suppressed by default when pretty-printing. Thus, `fromString "blah"` could render as just `"blah"` (what the user wrote), if fromString was inserted by the translation pass described above. We can have a separate new SrcSpan that says that AST was written by translation from some original AST. That way, `ifThenElse a b c` can be printed as `if a then b else c`, if the former were translated from the latter. Though it's beyond my use-case above, we can also imagine a new SrcSpans that refer to a Template Haskell splice or a quasiquote. What do we think? Is this a worthwhile direction of travel? I think the end result would be both a cleaner implementation of overloading and rebindable syntax *and* more informative and useful source-code provenances. Richard

4 3

users-guide page for master branch
by Takenobu Tani 03 Dec '19

03 Dec '19

Hi Ben, devs, This is not in hurry. It looks like the users-guide page for master branch [1] has not been updated recently. [1]: https://ghc.gitlab.haskell.org/ghc/doc/users_guide Regards, Takenobu

2 3

Injecting imported functions using a core plugin
by Josef Svenningsson 26 Nov '19

26 Nov '19

Hi ghc-devs, I’m currently writing a core plugin that I could use some help with. Consider the following two modules: ``` module A where foo :: Int bar :: Int module B where baz :: Int baz = bar ``` When compiling module B I run my plugin. The goal of the plugin is to replace the occurrence of `bar` with `foo`. Note that we can be sure that `foo` is actually imported, but unfortunately doesn’t occur anywhere in B before the plugin performs the transformation. The problem I have is that in order to inject `foo` in B I need to have an `Id` which represents `foo` and I’m having some trouble constructing such an `Id`. I’ve looked through the various environments that are available during the core to core transformations but none of them provides enough information to actually produce the `foo` `Id` as far as I can see. I hope I’m missing something. What do I need to do in order to construct the `foo` `Id` in module B? Thanks, Josef PS. The way I’ve phrased my problem in this email it would be possible to solve it with rewrite rules. My actual use case is unfortunately more complicated and rewrite rules don’t provide enough power to do what I want.

3 4

Multiple instance pragmas
by Domínguez, Facundo 25 Nov '19

25 Nov '19

Dear devs, I have a program [1] which depends on the ability to specify some instances to be both overlappable and incoherent. GHC so far, allows only one of the OVERLAPPABLE or INCOHERENT pragmas to be specified per instance. One can still have an overlappable and incoherent instance by using -XIncoherenInstances, but this extension is deprecated. Is there any chance that a patch is accepted to allow multiple instance pragmas? And if not, what would the reason for this constraint? Thanks, Facundo [1] https://gist.github.com/facundominguez/2c0292bf6a721b450c46486ff3b71f24

3 2

-dynamic-too implementation question
by Ömer Sinan Ağacan 25 Nov '19

25 Nov '19

Hi, If anyone here knows about how -dynamic-too is implemented feedback in #17502 would be appreciated. As far as I can see it's unnecessarily inefficient currently, and the code is very hard to follow, but it's possible that I'm missing something, and it'd be good to know what before investing time into it. Thanks, Ömer

1 0

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-alpha1 released
by Ben Gamari 24 Nov '19

24 Nov '19

Hello all, The GHC team is happy to announce the availability of the first alpha release in the GHC 8.10 series. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-alpha1/ GHC 8.10.1 will bring a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events This release marks the beginning of the 8.10 pre-release cycle. The next alpha release will be in roughly two weeks. This next alpha will likely be the last release before the release candidate in late December. If all goes well the final release will be cut roughly two weeks after the candidate, in mid-January. This being an alpha release, there are a few issues that are still outstanding: * The new Alpine Linux binary distribution is not present due to an apparent correctness issue [1]; any help Alpine users can offer here would be greatly appreciated. * We have yet to sort out compliance with Apple's notarization requirements [2] which will be likely be necessary for users of macOS Catalina. * There is an issue with the users guide build that has yet to be sorted out. * There are a couple of non-regression correctness issues which we plan to fix for the final 8.10.1 but are not fixed in this release. * Debian 10 builds are not yet available. Please do test this release and let us know if you encounter any other issues. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 [2] https://gitlab.haskell.org/ghc/ghc/issues/17418

1 0

Service outage
by Ben Gamari 22 Nov '19

22 Nov '19

Hello all, DreamHost, which hosts our GitLab artifact and log storage, is currently having some network trouble. Artifact and CI log download will be unavailable until this is resolved. I have engaged with DreamHost to try to expedite resolution of the issue but have no yet heard back. Cheers, - Ben

1 0