- ghc-devs - Haskell.org

Request for account approval for GHC non-moving GC bug reporting
by Christian Berentsen (chrberen) 08 Aug '23

08 Aug '23

We may have encountered a bug in the non-moving GC runtime, triggering: congregat-exe: internal error: nonmovingCollect: failed to spawn mark thread: Resource temporarily unavailable (GHC version 9.2.6 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Need account approval for jc.berentsen(a)gmail.com to report, if this is not a duplicate Regards, Christian

3 4

Configure errors
by Simon Peyton Jones 07 Aug '23

07 Aug '23

Rodrigo I'm getting lots of errors from ./configure, see below. Seems to be something to do with your toolchain stuff? I'm lost. Should I worry? If not, could they be made to look less alarming somehow? Simon Entering: checking for C compiler checking for -Qunused-arguments support... Entering: checking for -Qunused-arguments support Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Exited with code 1 found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking whether Cc supports --target... Entering: checking whether Cc supports --target Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Exited with code 1 found whether Cc supports --target: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking whether Cc works... Entering: checking whether Cc works Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c found whether Cc works: () checking for C99 support... Entering: checking for C99 support Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c found for C99 support: () checking whether cc supports extra via-c flags... Entering: checking whether cc supports extra via-c flags Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o /tmp/tmp0/test.o /tmp/tmp0/test.c found whether cc supports extra via-c flags: () found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking for C++ compiler... Entering: checking for C++ compiler x86_64-unknown-linux-g++ not found in search path x86_64-unknown-linux-clang++ not found in search path x86_64-unknown-linux-c++ not found in search path checking whether C++ supports --target... Entering: checking whether C++ supports --target Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp Exited with code 1 found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp found for C++ compiler: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} checking for C preprocessor...

2 5

Getting all variables in scope in CoreM
by Rodrigo Mesquita 06 Aug '23

06 Aug '23

Dear GHC devs, I’m trying to invoke the GHC.Core.Lint linting functions from a Core GHC plugin. These functions take a LintConfig that can m <>ostly be constructed from DynFlags, <> the exception being <> <> l_vars :: ![Var] — ^ Ids that should be treated as being in scope My question is then “How can I get all variables in scope in the module underlying this CoreM computation, to pass in the LintConfig?”. My ultimate goal is to run LintM to determine the usage environment of a given core expression. In that sense, the “Id out of scope” errors aren’t that important to me, but they do make the linting action fail. Thanks in advance! Rodrigo

2 1

Call for Lightning Talks: Haskell Implementors' Workshop 2023
by Ryan Scott 02 Aug '23

02 Aug '23

ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ --------------- The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. We have a number of slots for lightning talks. Lightning talks will be ~7 minutes and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Lightning talks are proposed by submitting a title and an abstract. Submissions will not be part of the peer-review process. Notification of acceptance will be continuous until slots are full. Accepted lightning talks will be posted on the workshop’s website. Submissions should be made via this Google form: https://forms.gle/2jGceompwNghbRQR9 Accepted lightning talks will be posted on the workshop’s website. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Contact ------- * Ryan Scott <ryan.gl.scott at gmail.com>

1 0

Something to learn from: On Telemetry in the Rust compiler
by Hécate 01 Aug '23

01 Aug '23

We should all certainly learn something from reading this post on telemetry and user trust. I know I did: https://estebank.github.io/rustc-metrics.html Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

[ANNOUNCE] GHC 9.8.1-alpha1 is now available
by Ben Gamari 28 Jul '23

28 Jul '23

The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeApplications` language extension [type-binders], allowing types to be bound in type declarations. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the 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 compiling, ~ Ben [type-binders]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-d… [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-s… [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-u… [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-w… [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-d… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha1/docs/users_guide/9.8.1-notes… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

NamedDefaults and relaxed defaults?
by Benjamin Redelings 26 Jul '23

26 Jul '23

Hi, If I understand correctly, the traditional defaulting rules prevent defaulting variables with constraints like (Num a, Convertible a Double), but the NamedDefaults proposal would allow defaulting a ~ Double in this case due to the relaxed defaulting rules in section 2.5 of the proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e… 1. Is there any plan to start implementing NamedDefaults? I saw the comment from Simon P-J that it would not be fun to implement because it might require orphan default declarations... so perhaps there's no plan to implement this? 2. Would it be worth adding a separate LANGUAGE option that just implements the relaxed defaulting rules in section 2.5? Specifically (a) allowing variables with multiparameter constraints and (b) allowing variables with constraints that are not in the Prelude. 3. Am I correct in assuming that the relaxed defaulting rules require NamedDefaults to be enabled in the importing module, and not just in the imported model? -BenRI

2 3

GHC 9.8 release status
by Ben Gamari 26 Jul '23

26 Jul '23

Hi all, As you may have noticed, the GHC 9.8 alpha series is a bit behind the expected schedule due to an unfortunate constellation of CI issues, bugs, and backports. I am currently trying to get a set of releasable artifacts through CI although things are somewhat stalled until we find a way forward in resolving ghc/ci-config#6 [1], caused by a regression in Docker. My hope is that we can have a set of release artifacts by Thursday. When this happens I will make any necessary amendments to the release schedule [2] to account for this delay. Thank you for your patience! Cheers, - Ben [1]: https://gitlab.haskell.org/ghc/ci-config/-/issues/6 [2]: https://gitlab.haskell.org/ghc/ghc/-/milestones/379#tab-issues

1 0

Coercing a `ByteArray#` into a `MutableByteArray#`
by Adithya Kumar 24 Jul '23

24 Jul '23

Hello all, I have a use-case where I want to convert `ByteArray#` to `MutableByteArray#` without the copy overhead. Is the underlying memory structure of `ByteArray#` and `MutableByteArray#` the same? If I can guarantee that I won't mutate my `MutableByteArray#`, can I use `unsafeCoerce#` on `ByteArray#` and treat it as `MutableByteArray#`? Best, Adithya

4 3

RFC Or patterns syntax: (p1 | p2) vs. (p1; p2)
by Sebastian Graf 24 Jul '23

24 Jul '23

Hi devs, I would like to invite you to provide arguments for or against the Or patterns syntax RFC `(p1; p2)` vs. `(p1 | p2)` over at this GH issue <https://github.com/ghc-proposals/ghc-proposals/issues/598>. *In particular, `(p1 | p2)` has a small lead over `(p1; p2)`*, but the latter will steal syntax from a hypothetical guards-in-patterns extension `(p | e)` as described here <https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns-alternative>. I dismissed this point until Vlad made me aware <https://github.com/ghc-proposals/ghc-proposals/issues/598#issuecomment-1600…> of the fact that `f (a -> b)` *could* mean "a pattern match on the type constructor `(->)`" in a Dependent Haskell future. Apparently, the existence of the hypothetical guards-in-patterns extension was reason enough <https://github.com/ghc-proposals/ghc-proposals/issues/598#issuecomment-1600…> to exclude view patterns from GHC2021. Of course, `(p1; p2)` has issues of its own. Given how close this vote is, I want to make sure that you, the GHC devs, are aware of this issue and perhaps have a few minutes to formulate a (counter) argument or just leave your vote before we submit the winner in the actual amendment proposal, at which point it will be up to the GHC steering committee to decide. Thanks, Sebastian

1 0