- Haskell-Cafe - Haskell.org

[ANNOUNCE] GHC 9.2.1-rc1 now available
by Ben Gamari 23 Aug '21

23 Aug '21

Hi all, The GHC developers are very happy to announce the availability of the release cadidate of the 9.2.1 release. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1-rc1 GHC 9.2 will bring a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [-hi profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Introduction of Haddock documentation support in TemplateHaskell (#5467) Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, 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 [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 3

The State of GHC 8.10
by Zubin Duggal 22 Aug '21

22 Aug '21

Hi all, GHC 8.10.6 was released last week, with high hopes of finally putting an end to the long running saga of the GHC 8.10 series. Unfortunately, this was not to be the case as we soon discovered #19950, an issue that we claimed to have fixed in the 8.10.6 release, was still affecting the released compiler. #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11). It surfaced in GHC 8.10.5 since we upgraded the toolchain on our Darwin builders to one of the affected versions. The original fix/workaround for #19950 was tested on the master and GHC-9.2 branches and found to be working, and so backported to the 8.10 branch. Unfortunately, Darwin releases for 8.10 are still done using the Make build system, which did not pick up the extra linker options needed to work around the issue. It places a heavy burden on developers to have so many active branches of the compiler to keep in mind, and the current situation with 4 active branches is simply not sustainable. As the oldest currently active branch, it is currently a priority to retire the 8.10 branch of GHC from active development as soon as possible. We have now fixed and verified the fix for #19950 on the 8.10 branch and prepared a GHC 8.10.7 release including it. As of now, the only change in GHC 8.10.7 is to link the x86_64 darwin release build with a few extra linker options to work around #19950. If you have any other critical issues that prevent you from using GHC 8.10(.6), please raise them soon by either pointing to existing tickets on the tracker or creating a new one. We are planning to cut the new release as soon as early next week, and we are really hoping that this would be the final release in the 8.10 series. Cheers, Zubin.

4 4

ghcup and XDG support
by Sven Panne 22 Aug '21

22 Aug '21

The ghcup-hs README contains a rather nebulous remark ( https://github.com/haskell/ghcup-hs#xdg-support) Note that ghcup makes some assumptions about structure of files in XDG_BIN_HOME. So if you have other tools installing e.g. stack/cabal/ghc into it, this will likely clash. In that case consider disabling XDG support. Which assumptions does it make? What will clash and when? I very much prefer XDG-style installations, but I don't want to find out the downsides the hard way afterwards... ;-) Cheers, S.

1 0

Re: [Haskell-cafe] Maintainership of 3 packages on Hackage by Adjoint Inc
by Sumit Raja 21 Aug '21

21 Aug '21

Hi Ivan, Stephen Diehl (https://github.com/sdiehl) has been very helpful in the past with these packages. I haven't seen any activity from other Adjoint members in a while. Maye Stephen is on this list and can help. As an aside, are you using these libraries for research purposes or in the wild? I'm interested in their suitability for non-research purposes or if something like blst (https://github.com/supranational/blst) with a Haskell FFI wrapper is more suitable/secure. Regards Sumit Message: 2 > Date: Thu, 19 Aug 2021 20:48:08 +0300 > From: Ivan Gromakovskii <ivan(a)serokell.io> > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] Maintainership of 3 packages on Hackage by > Adjoint Inc > Message-ID: <7c42266b-8747-e980-c1e5-5036f8b314e3(a)serokell.io> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I am a Haskell software developer and I use some packages maintained by > Adjoint Inc from Hackage. Specifically, I am interested in 3 packages: > > • elliptic-curve <https://hackage.haskell.org/package/elliptic-curve> > > • pairing <https://hackage.haskell.org/package/pairing> > > • galois-field <https://hackage.haskell.org/package/galois-field> > > Latest versions of these packages have upper bound restrictions on their > dependencies which do not allow to build them with latest versions > available on Hackage. For two packages these restrictions are already > updated in the source repos on GitHub, they just need to be updated on > Hackage. For the third one I opened a PR > <https://github.com/adjoint-io/galois-field/pull/32> on GitHub. > > I opened an issue > <https://github.com/adjoint-io/elliptic-curve/issues/21> about updating > elliptic-curve and commented > <https://github.com/adjoint-io/pairing/issues/21> another one about > pairing. Unfortunately, both issues were closed even though Hackage > versions were not updated. My PR wasn't closed, but apparently I was > banned or something because now I can't write comments there. > > Since I was unable to get any information on GitHub, I tried to contact > the maintainer by email (info(a)adjoint.io) written in the "maintainer" > field in all 3 packages, saying that I can make all the updated myself > if they give me permission. Unfortunately, this email address doesn't > seem to work because I got "Delivery Status Notification (Failure)" in > response. > > So it looks like these packages are effectively unmaintained, but > require some maintenance. I found the "Taking over a package > <https://wiki.haskell.org/Taking_over_a_package>" page which is exactly > about my case. I think I am in the situation where I cannot contact the > author/maintainer, that's why I am writing to Haskell Cafe. I can't CC > the maintainer (info(a)adjoint.io) because the address simply doesn't > exist. If anybody on the mailing list can reach out to Adjoint, please > do that, I'll be very thankful. > > Best, > > Ivan >

1 0

Call for Participation: Haskell Implementors' Workshop 2021
by Ningning Xie 20 Aug '21

20 Aug '21

Call for Participation ACM SIGPLAN Haskell Implementors' Workshop Sunday 22 Aug 20:00-05:00 (Seoul) https://icfp21.sigplan.org/home/hiw-2021 We are happy to announce that Haskell Implementors' Workshop is taking place this Sunday, co-located with ICFP 2021. The workshop will be live streamed on Youtube. We invite you to watch the talks, and attend the workshop. The program features 11 exciting talks, along with 4 lightning talks. The keynote is given by Bengt Marten Agren (Standard Chartered Bank), on "Haskell reinterpreted – large-scale real-world experience with the Mu compiler in Financial Markets". Program details: https://icfp21.sigplan.org/home/hiw-2021#program Keynote details: https://icfp21.sigplan.org/details/hiw-2021-papers/14/Haskell-reinterpreted… Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnningxie(a)gmail.com>

1 0

Maintainership of 3 packages on Hackage by Adjoint Inc
by Ivan Gromakovskii 19 Aug '21

19 Aug '21

Hello, I am a Haskell software developer and I use some packages maintained by Adjoint Inc from Hackage. Specifically, I am interested in 3 packages: • elliptic-curve <https://hackage.haskell.org/package/elliptic-curve> • pairing <https://hackage.haskell.org/package/pairing> • galois-field <https://hackage.haskell.org/package/galois-field> Latest versions of these packages have upper bound restrictions on their dependencies which do not allow to build them with latest versions available on Hackage. For two packages these restrictions are already updated in the source repos on GitHub, they just need to be updated on Hackage. For the third one I opened a PR <https://github.com/adjoint-io/galois-field/pull/32> on GitHub. I opened an issue <https://github.com/adjoint-io/elliptic-curve/issues/21> about updating elliptic-curve and commented <https://github.com/adjoint-io/pairing/issues/21> another one about pairing. Unfortunately, both issues were closed even though Hackage versions were not updated. My PR wasn't closed, but apparently I was banned or something because now I can't write comments there. Since I was unable to get any information on GitHub, I tried to contact the maintainer by email (info(a)adjoint.io) written in the "maintainer" field in all 3 packages, saying that I can make all the updated myself if they give me permission. Unfortunately, this email address doesn't seem to work because I got "Delivery Status Notification (Failure)" in response. So it looks like these packages are effectively unmaintained, but require some maintenance. I found the "Taking over a package <https://wiki.haskell.org/Taking_over_a_package>" page which is exactly about my case. I think I am in the situation where I cannot contact the author/maintainer, that's why I am writing to Haskell Cafe. I can't CC the maintainer (info(a)adjoint.io) because the address simply doesn't exist. If anybody on the mailing list can reach out to Adjoint, please do that, I'll be very thankful. Best, Ivan

1 0

Re: [Haskell-cafe] Fwd: Unlock instructions
by Amy de Buitléir 19 Aug '21

19 Aug '21

I got one of those emails as well, and I don't remember setting up an account there.

1 0

Assistant/Associate Professorships in Nottingham
by Graham Hutton 16 Aug '21

16 Aug '21

Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make multiple new appointments at the Assistant or Associate Professor level: https://tinyurl.com/wruwpnpt https://tinyurl.com/284svw4y Applications in the area of the Functional Programming (FP) lab are strongly encouraged! The FP lab is keen to receive applications from candidates with an excellent publication record (e.g. papers in leading venues such as LICS, POPL, ICFP, JFP, TOPLAS, etc) and the ability to secure external funding to support their research. Further information about the FP lab is available from: https://tinyurl.com/y2ekdkqa The deadline for applications is Monday 20th September 2021. The advert mentions some specific research areas, but the positions are open to applicants from any area of Computer Science. -- Graham Hutton and Thorsten Altenkirch This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Parsing XML
by John Arnold 16 Aug '21

16 Aug '21

I am building a prototype for processing ISO 20022 Payment Initiation messages. These messages are in XML format and I want the prototype to be built using Haskell. Conducting a search for 'Haskell XML parsing' yields postings that are in the region of 10+yrs old. I am sure there are packages that have been developed/update in the recent past. Any thoughts?

8 7

Deprecation being transitively reported for re-exported definitions
by Ivan Perez 15 Aug '21

15 Aug '21

Hello Café, TL;DR: should the deprecation GHC option be transitively reported for re-exported definitions? I have a library that is exposing too much. As a minimal example, say the library contains: - Module A, which defines several functions and types. - Module B, which exports *specific definitions* from module A and has none of its own. It so happens that, to keep things as clean and abstract as possible, only module B should be exposed. As per library policy, we give users time to adapt. A way to do that would be to deprecate module A, but configure B to ignore deprecations (-Wno-deprecations) so GHC does not complain during the compilation of the library itself. My expectation was that library users who imported *A directly* would get a warning, but importing definitions in A *via B* would not give out any warnings. That, however, is not what is happening: In the use of ‘functionInA’ (imported from B, but defined in A): Deprecated: "This module will be hidden in future versions." There are "workarounds": I could move all definitions in A to new module C, deprecate A, and re-export C in B, or I could re-define the exported definitions in B as identities of those in A (easy for functions, probably more cumbersome for data constructors or classes.) However, more generally, if you use a function from A in a NEW function definition in B and then export *that second definition instead*, the compiler won't tell *the library user* that B is internally relying on a deprecated function. Reexporting a function without changes could conceptually be seen as an "extreme" case of that, where where the name and the implementation in B coincide with those in A. So I ask: should deprecation work the way it is working in the first place? All the best, Ivan

5 6