- ghc-devs - Haskell.org

Partial type synonyms -- first-class!
by ÉRDI Gergő 17 Aug '22

17 Aug '22

As I mentioned at the end of the original thread (but probably no one was interested in this enough to read that far), after a breakthrough idea I have now started working on partial type synonyms that are NOT just defined using macro expansion semantics, and indeed can be a first-class abstraction. I think if I can iron out the wrinkles detailed at the bottom of this message, this would be good for a GHC proposal. 1. Defining partial type synonyms The idea is to typecheck the type synonym declaration type Syn a = MyType _ [a] Int into a type synonym that has some implicit (invisible) type parameters: type Syn {w1} a = MyType w1 [a] Int We don't need to come up with any new design for "what this means": this means exactly the same as type Syn w1 a = MyType w1 [a] Int which is something you can already write today. The only difference is how `w1` is given at use sites. 2. Using partial type synonyms When a partial type synonym is applied, its argument list is expanded by adding wildcard arguments for the invisible parameters. So this use site: Syn Double is typececked into the type application Syn {_} Double Again, we don't need to come up with any new design for "what this means": this is the same as writing `Syn _ Double` into the same position, it's just the `_` is not written in the surface syntax. In particular: * The level of the type variable conjured for the `_` is determined fully by where the `Syn Double` occurs, and not at all by the definition of `Syn` * Using the type synonym `Syn` is only valid where a wildcard occurrence would be valid. In particular, using `Syn` in a type signature causes the signature itself to be regarded as partial (`isCompleteHsSig` returns `False` for it). 3. Implementation I have a proof-of-concept implementation at https://gitlab.haskell.org/cactus/ghc/-/compare/master...cactus%2Fpartial-t… I tried to make it as small a change as I could. Its key points are: * In the renamer, we allow wildcards in `TySynCtx` context * In `tcTySynRhs`, we allow wildcards in the right-hand side, retrieve them from the result of typechecking, and intersperse them with the "normal" type parameters to get a well-scoped telescope. * About a third of the lines changed is just a boring refactoring of `isCompleteHsSig` to be able to look up type synonym `TyCon`s. This is needed because a type signature referring to partial type synonyms will be partial itself once those type synonym applications are elaborated. * When typechecking a type application, implicit arguments get filled with the result of `tcAnonWildCardOcc`. Now, my questions about the problems I've encountered along the way. I hope these questions are concrete enough that I can get concrete answers to them from this list: 1. How do I find the wildcard-originating tyvars robustly? Currently, I am using `candidateQTyVarsWithBinders` but that picks up "regular" out-of-scope tyvars as well. I believe this causes a regression of #17567; furthermore, it means if the user writes `type Syn a = Foo b` it is handled the same as if they wrote `type Syn a = Foo _`, but it would be better to reject it instead. 2. What should the `Role` of these implicit type parameters be? For now, I've went with `Nominal` for lack of a better answer. 3. When typechecking a type application, I need to insert wildcards for these implicit arguments. I am currently using `AnonTCB InvisArg` binders to represent these implicit type parameters, which means by the time I get to `tcInferTyApps`, they would get passed through `instantiate` to `tcInstInvisibleTyBinder`. I currently have a horrible kuldge here to check, before calling `tcInstInivisibleTyBinder`, that the invisible binder's kind doesn't meet the preconditions of it; and if it doesn't, I create a wildcard instead. But of course, it would be nicer if I could put something in the `TcTyConBinder` that identifies these binders properly. Thanks in advance, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------'

5 6

Question about ambiguous predicates in pattern bindings
by Benjamin Redelings 16 Aug '22

16 Aug '22

Hi, 1. I'm reading "A Static semantics for Haskell" and trying to code it up. I came across some odd behavior with pattern bindings, and I was wondering if someone could explain or point me in the right direction. Suppose you have the declaration (x,y) = ('a',2) My current code is yielding: x :: Num a => Char y :: Num a => a However, I notice that ghci gives x the type Char, with no constraint, which is what I would expect. It also gives y the type 'Num b => b', so I don't think it is defaulting a to Int here. The weird results from my code stem from rule BIND-PRED in Figure 15 of https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semanti… E |- bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, theta => LVE) Here theta = ( Num a ) and LVE = { x :: Char, y :: a }. So, theta => LVE is { x :: Num a => Char, y :: Num a => a } The obvious thing to do is avoid changing a type T to Num a => T if T does not contain a. Also I'm not totally sure if that trick gets to the bottom of the issue. However, the paper doesn't mention define theta => LVE that way. Is there something else I should read on this? 2. If we just chop out predicates which mention variables not in the type ( == ambiguous predicates?) then I'm not totally sure how to create code for this. I would imagine that we have something like tup dn = ('a', fromInteger dn 2) x = case (tup dn) of (x,y) -> x y dn case (tup dn) of (x,y) -> y In this case its not clear where to get the `dn` argument of `tup` from, in the definition of `x`. Can we pass in `undefined`? Should we do something else? If anyone can shed light on this, I would be grateful :-) -BenRI

4 8

Test failures on `master`
by Erdi, Gergo 16 Aug '22

16 Aug '22

PUBLIC Hi, As of dca43a04fb, I am seeing the following test failures locally. Is this due to some configuration problem in my development environment, or did something slip through CI? Thanks, Gergo Unexpected failures: /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/driver/j-space/jspace.run jspace [bad exit code (2)] (normal) /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/plugins/plugins-external.run plugins-external [bad exit code (2)] (normal) /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/quasiquotation/qq005/qq005.run qq005 [exit code non-0] (normal) /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/quasiquotation/qq006/qq006.run qq006 [stderr mismatch] (normal) /tmp/ghctest-2v5a6979/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code (1)] (normal) /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/plugins/test-echo-in-line.run test-echo-in-line [bad stdout] (normal) /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/plugins/test-echo-in-line-many-args.run test-echo-in-line-many-args [bad stdout] (normal) /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/plugins/test-echo-in-turn.run test-echo-in-turn [bad stdout] (normal) /tmp/ghctest-2v5a6979/test spaces/testsuite/tests/plugins/test-echo-in-turn-many-args.run test-echo-in-turn-many-args [bad stdout] (normal) /tmp/ghctest-2v5a6979/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (normal) This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

1 0

9.4.2 release plans
by Matthew Pickering 15 Aug '22

15 Aug '22

Hi all, Within the next week we are planning to release 9.4.2 to fix the critical issues found in 9.4.1. The 9.4.2 milestone is up-to-date with all the issues which are planned to be fixed in this release. https://gitlab.haskell.org/ghc/ghc/-/milestones/378#tab-issues Amongst these are: * -x option broken on command line (#22044 ) * Darwin bindists can't be installed (#21974) * Bytecode interpreter incorrect result when inlining constructor wrappers (#22042) * Some fixes to the make build system (#22047) Cheers, Matt

1 0

Re: Partial type synonyms -- first-class!
by Erdi, Gergo 12 Aug '22

12 Aug '22

PUBLIC For anyone interested, I've added MRs https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8818 and https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8819 to track my progress. From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Edward Kmett Sent: Friday, August 12, 2022 10:43 AM To: ÉRDI Gergő <gergo(a)erdi.hu> Cc: GHC Devs <ghc-devs(a)haskell.org> Subject: [External] Re: Partial type synonyms -- first-class! FWIW, Gergo, I've been following what you've been doing pretty closely, so there's at least two of us tracking it in the background. =) I might have some clever(?) (ab)uses for it in the future in my linear haskell code. -Edward This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

1 0

Recompilation avoidance on ABI hash changes
by Domínguez, Facundo 11 Aug '22

11 Aug '22

Dear devs, rules_haskell [1] recently earned the ability to skip recompiling modules when the ABI hashes of dependencies don't change in interface files. We have noticed since then that sometimes ghc --make does avoid rebuilding even when ABI hashes change. However, so far I've been unable to reproduce this in the small. The wiki page on recompilation avoidance does remark that a changing ABI hash is a necessary but not sufficient condition for recompilation [2]. Does anyone have a small example showing how ghc avoids rebuilding even when the ABI hash of a dependency changes? Thanks in advance! Facundo [1] https://github.com/tweag/rules_haskell/issues/1760#issuecomment-1179102232 [2] https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/recompilatio…

2 2

GHC 9.4 symlink wrappers installed incorrectly on FreeBSD 12
by Viktor Dukhovni 10 Aug '22

10 Aug '22

I just built a GHC 9.4 bindist on FreeBSD 12, and found that the bindist Makefile installed unusable wrappers when the source was a symlink. It seems plausible that the issue may not be FreeBSD-specific, but that's all I've tried so far. The problem wrappers do not have execute permissions, and lack the variable settings at the top of the scripts needed to make them work: $ ls -l ~/.local/ghc-9.4/bin total 98 -rw-r--r-- 1 viktor viktor 45 Aug 10 21:46 ghc -rwxr-xr-x 1 viktor viktor 406 Aug 10 21:46 ghc-9.4.1 -rw-r--r-- 1 viktor viktor 97 Aug 10 21:46 ghc-pkg -rwxr-xr-x 1 viktor viktor 466 Aug 10 21:46 ghc-pkg-9.4.1 -rw-r--r-- 1 viktor viktor 67 Aug 10 21:46 ghci -rwxr-xr-x 1 viktor viktor 430 Aug 10 21:46 ghci-9.4.1 -rw-r--r-- 1 viktor viktor 57 Aug 10 21:46 haddock -rwxr-xr-x 1 viktor viktor 434 Aug 10 21:46 haddock-ghc-9.4.1 -rw-r--r-- 1 viktor viktor 33 Aug 10 21:46 hp2ps -rwxr-xr-x 1 viktor viktor 406 Aug 10 21:46 hp2ps-ghc-9.4.1 -rw-r--r-- 1 viktor viktor 33 Aug 10 21:46 hpc -rwxr-xr-x 1 viktor viktor 402 Aug 10 21:46 hpc-ghc-9.4.1 -rw-r--r-- 1 viktor viktor 734 Aug 10 21:46 hsc2hs -rwxr-xr-x 1 viktor viktor 1109 Aug 10 21:46 hsc2hs-ghc-9.4.1 -rw-r--r-- 1 viktor viktor 50 Aug 10 21:46 runghc -rwxr-xr-x 1 viktor viktor 417 Aug 10 21:46 runghc-9.4.1 -rw-r--r-- 1 viktor viktor 50 Aug 10 21:46 runhaskell -rwxr-xr-x 1 viktor viktor 425 Aug 10 21:46 runhaskell-9.4.1 $ (cd ~/.local/ghc-9.4; grep . $(find bin ! -name hsc2hs ! -perm -001)) bin/ghci:executable="$bindir/ghc-9.4.1" bin/ghci:exec $executable --interactive "$@" bin/ghc:exec "$executablename" -B"$libdir" ${1+"$@"} bin/haddock:exec "$executablename" -B"$libdir" -l"$libdir" ${1+"$@"} bin/hp2ps:exec "$executablename" ${1+"$@"} bin/ghc-pkg:PKGCONF="$libdir/package.conf.d" bin/ghc-pkg:exec "$executablename" --global-package-db "$PKGCONF" ${1+"$@"} bin/runghc:exec "$executablename" -f "$exedir/ghc" ${1+"$@"} bin/hpc:exec "$executablename" ${1+"$@"} bin/runhaskell:exec "$executablename" -f "$exedir/ghc" ${1+"$@"} The same holds for "hsc2hs", but the "meat" of the script is longer so I chose to skip it. -- Viktor.

1 1

Re: A macOS static linking mystery
by Ryan Scott 10 Aug '22

10 Aug '22

I should clarify that I'm using a borrowed macOS on which I don't have admin privileges, so I'm unable to install pkg-config. As a result, I'm commenting out the pkgconfig-depends: line in libffi.cabal and manually specifying the extra-lib-dirs and include-dirs via a cabal.project.local file. I've configured the project to use both the macOS system libffi (located at /usr/lib/libffi.dylib) as well as the version that Homebrew provides. Both configurations exhibit the strange, apparently-statically-linked behavior. Even stranger, the macOS system libffi _only_ provides a .dylib file, not an .a file. If I examine the x86 code of the compiled executable using `objdump -d`, I can see various libffi definitions (e.g., _ffi_call), so perhaps these definitions are being inlined through some kind of link-time optimization? I'm really not sure how else to explain what's happening. Ryan

3 8

[ANNOUNCE] GHC 9.4.1 is now available
by Ben Gamari 09 Aug '22

09 Aug '22

The GHC developers are very pleased to announce the availability of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1 This release includes: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302]. - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

1 1

ghc doesn't work after installing 9.4.1 on my Mac
by George Colpitts 09 Aug '22

09 Aug '22

Unfortunately ghc doesn't work after installing 9.4.1 on my Mac. Does it work for others? After the install finishes when I do the following: $ ghc --version bash: /usr/local/bin/ghc: Permission denied $ sudo chmod +x /usr/local/bin/ghc $ghc --version /usr/local/bin/ghc: line 1: exec: : not found $ cat /usr/local/bin/ghc exec "$executablename" -B"$libdir" ${1+"$@"} $ cat /usr/local/bin/ghc-9.4.1 #!/bin/sh exedir="/usr/local/lib/ghc-9.4.1/bin" exeprog="ghc-9.4.1" executablename="/usr/local/lib/ghc-9.4.1/bin/ghc-9.4.1" bindir="/usr/local/bin" libdir="/usr/local/lib/ghc-9.4.1/lib" docdir="/usr/local/share/doc/ghc-9.4.1" includedir="/usr/local/include" exec "$executablename" -B"$libdir" ${1+"$@"} Thanks George On Sun, Aug 7, 2022 at 6:30 PM Ben Gamari <ben(a)well-typed.com> wrote: > The GHC developers are very pleased to announce the availability of GHC > 9.4.1. Binary distributions, source distributions, and documentation are > available at downloads.haskell.org: > > https://downloads.haskell.org/ghc/9.4.1 > > This release includes: > > - A new profiling mode, `-fprof-late`, which adds automatic cost-center > annotations to all top-level functions *after* Core optimisation has > run. This provides informative profiles while interfering > significantly less with GHC's aggressive optimisations, making it > easier to understand the performance of programs which depend upon > simplification.. > > - A variety of plugin improvements including the introduction of a new > plugin type, *defaulting plugins*, and the ability for typechecking > plugins to rewrite type-families. > > - An improved constructed product result analysis, allowing unboxing of > nested structures, and a new boxity analysis, leading to less reboxing. > > - Introduction of a tag-check elision optimisation, bringing > significant performance improvements in strict programs. > > - Generalisation of a variety of primitive types to be levity > polymorphic. Consequently, the `ArrayArray#` type can at long last be > retired, replaced by standard `Array#`. > > - Introduction of the `\cases` syntax from [GHC proposal 0302]. > > - A complete overhaul of GHC's Windows support. This includes a > migration to a fully Clang-based C toolchain, a deep refactoring of > the linker, and many fixes in WinIO. > > - Support for multiple home packages, significantly improving support > in IDEs and other tools for multi-package projects. > > - A refactoring of GHC's error message infrastructure, allowing GHC to > provide diagnostic information to downstream consumers as structured > data, greatly easing IDE support. > > - Significant compile-time improvements to runtime and memory consumption. > > - On overhaul of our packaging infrastructure, allowing full > traceability of release artifacts and more reliable binary > distributions. > > - Reintroduction of deep subsumption (which was previously dropped with > the > *simplified subsumption* change) as a language extension. > > - ... and much more. See the [release notes] for a full accounting. > > Note that, as 9.4.1 is the first release for which the released artifacts > will > all be generated by our Hadrian build system, it is possible that there > will be > packaging issues. If you enounter trouble while using a binary > distribution, > please open a [ticket]. Likewise, if you are a downstream packager, do > consider > migrating to [Hadrian] to run your build; the Hadrian build system can be > built > using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the > accompanying > [blog post] for details on migrating packaging to Hadrian. > > We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and > other anonymous contributors whose on-going financial and in-kind support > has > facilitated GHC maintenance and release management over the years. Finally, > this release would not have been possible without the hundreds of > open-source > contributors whose work comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy testing, > > - Ben > > > [GHC proposal 0302]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [bootstrap script]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… > [Hadrian]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… > [release notes]: > https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html > [blog post]: > https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

2 1