- Haskell-Cafe - Haskell.org

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 15 Aug '21

15 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

Functional Art, Music, Modeling and Design (FARM 2021) Aug 21: Call for Participation
by Daniel Winograd-Cort 14 Aug '21

14 Aug '21

====================================================================== FARM 2021 9th ACM SIGPLAN International Workshop on Functional Art, Music, Modeling and Design 27 August, 2021, co-virtual with ICFP 2021 https://functional-art.org/2021/ ====================================================================== The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. Registration ------------ You can register via the ICFP 2021 registration: http://icfp21.sigplan.org/attending/registration Don't be confused that it says ~ICFP~ - FARM is part of a larger event around ICFP 2021, and you can register for FARM without registering for ICFP. Keynote ------- Phoenix Perry will hold the keynote. Accepted papers --------------- minimum: a self-extensible programming language for sound and music Tomoya Matsuura and Kazuhiro Jo MidifilePerformer: a case study for chronologies Juliette Chabassier, Myriam Desainte-Catherine, Jean Haury, Marin Pobel and Bernard Serpette Temporal-Scope Grammars for Polyphonic Music Generation Lukas Eibensteiner, Martin Ilčík and Michael Wimmer The W-calculus: A Synchronous Framework for the Verified Modelling of Digital Signal Processing Algorithms Emilio Jesus Gallego Arias, Pierre Jouvelot, Sylvain Ribstein and Dorian Desblancs Human-in-the-loop Program Synthesis for Live Coding Mark Santolucito Live Performances ----------------- FARM 2021 will feature a session of live performances: - John Leo, Logical Soundness - Emiddio Vasquez, Title TBA - José Miguel Fernandez, Homotopy Workshop Organisation --------------------- Workshop Chair: Daniel Winograd-Cort (Luminous Computing) Program Chair: Jean-Louis Giavitto (IRCAM Paris) Publicity Chair: Michael Sperber (Active Group GmbH) Performance Chair: John MacCallum (HfMT Hamburg)

1 0

[Haskell] [ANNOUNCE] GHC 8.10.6 released
by Zubin Duggal 14 Aug '21

14 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html This is a bugfix release, fixing many issues present in GHC 8.10.5, including: - A fix for segmentation faults in GHCi on `aarch64-darwin` due to an incorrect foreign import in `haskeline`. See [this blog post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari for more details on how your library could be affected. - A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763). - No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959). - Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132). - Fixes and stability improvements for the non-moving GC (#19715). - Many other bug fixes for the RTS (#18033, #20132, #20093, #19421). - Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. - A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) - A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948). - Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.…. As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

Re: [Haskell-cafe] Different advice for type classes for end-user app and libraries?
by Michal J Gajda 13 Aug '21

13 Aug '21

Dear Ruben, > Currently I am working a end user application. Through the years I had > incorporated the advice from r/haskell that classes without laws were not > desirable. Their lack meant that we didn't have a contract boundary that > should be respected by the instances. They secretly could `throw exc` on > their implementation and you wouldn't notice. Indeed you are right. This is especially pressing for the type classes that convey relations between multiple types. Luckily, diligent students of Haskell source code will find common patterns for the laws that occur -- see below. > But on the current app I am working on, I follow the advice from this > blogpost [1] that I should use classes for domain modelling. This manifest > on classes like > class UserQueryCapability f where > getUser :: Id -> f User Before we get to the laws, I would recommend that you use technique of "linguistic analysis" to find a better name for the class. If not, you may want to remove words that are implicit in the object. Class name of "UserQuery" may be better, because "capability" is implicit in the fact that it is a type class. See example here: https://olegchursin.medium.com/a-brief-introduction-to-domain-modeling-862a… > for interacting with a DB. Functions can be written against the interface > and I can mock up with QuickCheck some pretty broad cases. The classes > usually don't have a superclass constrain on `Monad` as in `MonadReader` > because I *cannot* establish a law relating the monadic behavior and > `getUser`. The name has Capability in it and not Monad because I won't lie > that way. First method is to recognize a common pattern: you have a function that reads a part of the state. That means it is similar to `lookup userId <$> ask`. `ask` follows certain laws, and you may apply these laws here: getUser u >> getUser u == ask -- idempotence getUser u >> return () == return () -- no effect of reading To get inspiration for other laws you may look at how this type class interacts with other type classes that deal with `User` objects here. There are several other techniques that apply in special cases. For example if you have multiple self-contained implementations of a type class, you may use `quickspec` to get equational laws for different implementations, and look for common laws between different implementations. https://hackage.haskell.org/package/quickspec These two ways seem to be most applicable from the example you have provided so far. > Making sure that these effect classes are orthogonal is something I have to > check by hand. But in the back of my head there is the concern about the > lack of laws could bite me even on a end user-app. Is my intuition well > founded that this case is OK? Lack of laws may mean one of the following: * type class is not an abstraction and thus does not allow you to tell anything abstract about it * you may have undocumented tacit knowledge about the type class that gets lost in the implementation * your users will find it harder to use type class as interface (as it is intended to be used). Advert: If the above description is insufficient, and the task is too challenging to fully solve within haskell-cafe mailing list, you may contact https://www.migamake.com for consulting on type class design and training. We do provide business analysis for Haskell projects too. -- All the best Michał

1 0

base64-bytestring memory corruption bug
by Fraser Tweedale 12 Aug '21

12 Aug '21

Hello, I want to bring to wider attention a memory bug present in base64-bytestring[1]. In summary, in some cases too few bytes are allocated for the output when performing base64url decoding. This can lead to memory corruption (which I have observed[2]), and possibly crashes (which I have not observed). I submitted a pull request[2] that fixes the issue some days ago, but did not receive a response from the maintainers yet. I understand that maintainers may be busy or unavailable, and that is fine. So I am posting here mainly to ensure that USERS are aware of the issue. To maintainers: let me know if I can provider further assistance to resolve this issue and release a fix. [1] https://github.com/haskell/base64-bytestring/issues/44 [2] https://github.com/frasertweedale/hs-jose/issues/102 [3] https://github.com/haskell/base64-bytestring/pull/45 Thanks, Fraser

3 4