- ghc-devs - Haskell.org

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released
by Ben Gamari 18 May '20

18 May '20

Hello all, The GHC team is happy to announce the availability of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1/ GHC 8.10.1 brings 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 * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. This situation will hopefully be improved for GHC 8.10.2 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418

2 3

Iface loading type reflection module bindings
by Josh Meredith 17 May '20

17 May '20

Hi, In attempting to implement an extensible interface field for Core bindings based on my previous interfaces patch, I've run into problems with deserialising the special type reflection `$trModule` bindings generated by `GHC.Tc.Instance.Typeable.mkTypeableBinds`. These bindings are then stored in the `ModGuts.mg_binds` along with the real exported top-level bindings of the module. Specifically, attempting to load the iface right-hand side expressions with `tcIfaceExpr` results in the error "Iface id out of scope" from `GHC.Iface.Env.tcIfaceLclId`. My understanding is that this may be because the binding is attempting to look itself up within the interface loading environment, without being bound yet - though it's unclear to me whether this is the correct behaviour for these special type reflection bindings, or if there's some special treatment that should be instead applied to load these. Any advice on how I should proceed would be greatly appreciated. Cheers, Josh

2 2

Strange library git glitch
by Simon Peyton Jones 15 May '20

15 May '20

I'm getting this strange output from 'git diff' bash$ git diff diff --git a/libraries/exceptions b/libraries/exceptions --- a/libraries/exceptions +++ b/libraries/exceptions @@ -1 +1 @@ -Subproject commit fe4166f8d23d8288ef2cbbf9e36118b6b99e0d7d +Subproject commit fe4166f8d23d8288ef2cbbf9e36118b6b99e0d7d-dirty No amount of git submodule update makes it go away. Any ideas? Thanks Simon

4 5

Decorating exceptions with backtrace information
by Ben Gamari 14 May '20

14 May '20

Hi everyone, After a nice discussion on IRC about the unfortunate state of error reporting in Haskell, I felt compelled to write down some long-lingering thoughts regarding backtraces on exceptions. The result is GHC proposal #330 [1]. I think the approach is viable and perhaps even straightforward. I have the sketch of an implementation here [2]. Please have a look at the proposal and leave your comments. If there is consensus it is possible that we could have this done for 8.12. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236

8 19

[HiW'20] Call for Talks
by Ben Gamari 14 May '20

14 May '20

Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year in New Jersey. 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 discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2020. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. 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 encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially 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, optimization and benchmarking - Virtual machines and run-time systems - Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw20.hotcrp.com/ until July 2nd (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins 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. Logistics --------- We recognize the on-going threat that COVID-19 poses to our participants' safety. While August is nearly half a year away, we must account for the possibility that the virus continues to pose a significant threat into the summer. For this reason, we are investigating options that would allow remote presentations this year. In light of this, we urge potential presenters not to be discouraged from submitting and encourage participants to keep time open in their calendars, regardless of the on-going COVID situation. Rest assured that the conference organizers are working to ensure that the Implementors Workshop can be held safely and productively, regardless of how the COVID-19 situation evolves. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan Scott (Indiana University Bloomington) Best wishes, Ben

1 1

A future for the Windows packaging situation.
by Hécate 14 May '20

14 May '20

Dear GHC devs, dear maintainers, Following a discussion that took place on #ghc, I wish to spread it to the whole mailing-list, in order to receive some feedback, and plan for the future now that it has become clear that the present is rather bleak. As some of you may have seen from the long threads in haskell-cafe@, countless steps of various difficulty for Windows users (excluding power-users) need to be taken in order to have a proper working GHC / Haskell installation on their machine. Moreover, some defiance against Chocolatey has come to our ears, due to the mailing-list registration form that appears when one desires to download this package manager. I shall speak for myself by saying that I do not wish the that the Windows Haskell developers need to become a special combo of Chocolatey maintainers and Windows power users. Some GNU/Linux distributions such as Exherbo have made this their creed, the major difference being that they actually give the tools to make such a thing possible. The point of my email to you all is the following: I suggest that Haskell.org, the 501(c)(3) established in NY which, If I am not mistaken, holds the funds from various individual donations, the Amazon Smile programme and Software in the Public Interest grants, hires a company to establish a strong technological basis regarding Windows packaging. I am not talking of delegating the maintaining task to an external entity, but to provide the foundations upon which volunteers will be able to keep things running. Training in such matters would also be beneficial, so that newcomers can learn on the spot how to best interact with this. Their contract would involve the initial setup of CI tasks able to produce MSIX packages, while the people in charge of the haskell.org landing page would ease the user experience by providing clearer ways to install GHC on various platforms. Ideally we could have a GUI to install libraries easily, like many GNU/Linux package managers offer. That being said, I was also suggested the idea of a grant and/or sponsorship. What we need is less a capitalist framework around that task and more of an incentive to invest a serious amount of work and quality so that it becomes, at last, the non-issue it should have always been. The important thing to keep in mind is that the GNU/Linux and macOS users *cannot* hold the Windows users to the same standards in terms of CLI usability. I cannot weigh in my opinion on the most recent iterations of PowerShell, but Windows XP's cmd.exe was excruciating, to say the least. Now, I know some of you will prefer to have this task handled by competent volunteers, but I am under the moral obligation to say that expecting salvation and better tomorrows from people who have yet to make their presence known in the thirty years of existence of our dear language, is at best mild delusion, at worse folly that will only widen the gap between what is needed to get Haskell up and running smoothly on the Windows platform and the average skill of Windows users. I am not suggesting that my email is The True Way to follow so that everything is fixed forever, and if we can, as a community, arrive to some satisfying workflow that would benefit rather than alienate our Windows user base, this would would be wonderful. Thank you for reading until the end. Cheers, Hécate. PS: I am in no way trying to berate anyone for their implied incompetence, or imply that Windows users are stupid and/or technologically impaired. This would be misinterpreting my words and lead nowhere but to another OS war on another mailing-list. PPS: I am serious. Please stay on-topic. PPPS: I hold no share, no money or any other form of capital in any Windows packaging company we might or might not end up hiring for the task. I am speaking of experience, for my company used an external contractor to work on our landing (non-product) page, while all hands were on deck to support the product development effort. This allowed us to have a strong foundation to iterate on, and bought us countless hours of development time.

3 3

Inclusion of the parser refactor in 8.12
by Karpov, Mark 12 May '20

12 May '20

Hello, I'd like to mention that it would be nice if this patch https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377 could be included in 8.12. Right now we have a few issues that Ormolu users have reported which stem from how Haddocks are parsed by GHC (e.g. that issue when a file starts with haddock it must have a module header). I originally planned to work on those myself, but today I discovered that Vlad is already working on it. Best, Mark

2 1

Removal of UniqMap module
by Matthew Pickering 10 May '20

10 May '20

Hi, I noticed that the UniqMap module was removed from the tree See 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601 Why was it removed? I needed it today and now I am unsure what the suitable replacement is. As a general point, please can we stop with these annoying refactorings which delete unused code and move around definitions for no clear purpose. The amount of churn on the code base has wasted me a lot of time recently. Cheers, Matt

3 2

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Michal J Gajda 09 May '20

09 May '20

Ben, I agree with you that is a great idea! I can add a few more real world examples: * we get exception from a foreign library that we bound, * we get an exception from a platform (I believe Windows supports throwing exceptions to programs), * user presses CTRL-C and we want to know where our program hanged. * we get infamous <<loop>>, because in theory nobody wants non-terminating programs, but in practice everybody gets them sometimes. I also use `ExceptT`, `EitherT` for processing large sets of data, because that allows me to contain the errors efficiently. However from time to time, I get an error to blow up **and I cannot even locate which library was guilty**. It would be nice to extract them automatically and put them into error database before they are prioritized. -- Cheers Michał

1 0

Unique invariants: GHC invocation vs scope?
by Csaba Hruska 08 May '20

08 May '20

Hello, What are the intended invariants of Unique values? So far I thought that it is always gives a unique identity to things during a whole GHC invocation. However this is not true. I.e. eta expansion breaks this assumption. Here is a snippet from the STG IR of GHC.PrimopWrappers: extendInt8# [InlPrag=NOINLINE] :: Int8# -> Int# [GblId, Arity=1, Unf=OtherCon []] = \r [eta_B1] extendInt8# [eta_B1]; ord# [InlPrag=NOINLINE] :: Char# -> Int# [GblId, Arity=1, Unf=OtherCon []] = \r [eta_B1] ord# [eta_B1]; Where eta_B1 is redefined, so it is only unique in the scope. Is this intentional? Thanks, Csaba Hruska

2 1