- Haskell-Cafe - Haskell.org

IFL'21 final call for participation
by Pieter Koopman 30 Aug '21

30 Aug '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> *Registration* *Registration is **free of charge, but required for participation!* We will mail the zoom link only to registered participants. Use the below link to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8of… <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> *Program* The program is now available at https://ifl21.cs.ru.nl/Program <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . *Scope* The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2021 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. *Organisation* IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands *PC* Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary [image: beacon]

1 0

Take-over request for: blaze-textual
by Andrey Prokopenko 30 Aug '21

30 Aug '21

Hello, - Few months ago I opened PR in `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 <https://github.com/bos/blaze-textual/pull/14> - The package is either direct or transient dependency for `haskell-language-server`, `sqlite-simple` and few more packages. - While forks maintenance is a well-known practice it creates burden on maintainers. I would like to become a maintainer for `blaze-textual` package and keep it up-to-date at least for a next few years. Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package <https://wiki.haskell.org/Taking_over_a_package> Best Regards, Andrey Prokopenko

2 5

Remove 'show-build-info' from lib:Cabal
by Fendor 30 Aug '21

30 Aug '21

Hello everyone! The lib:Cabal (Setup.hs) command 'show-build-info' is going to be removed with the next Cabal version (3.8). It is being replaced by the build flag '--enable-build-info' that is added to 'build' directly. If you depend on 'show-build-info' in any way, please give us feedback on [1] or [2]. Details on the purpose and implementation of 'show-build-info' can be found here: [1] Best regards, Fendor [1]: https://github.com/haskell/cabal/issues/7489 [2]: https://github.com/haskell/cabal/pull/7498

1 0

Re: [Haskell-cafe] Contents of Haskell-Cafe digest...
by Kim Chaegon 29 Aug '21

29 Aug '21

Hello! I want read and learn continually haskell for mathematics. Please send me your text about haskell. Thank you!

1 0

[Call for reviewers] Switch `text`'s internal representation to UTF-8
by Hécate 27 Aug '21

27 Aug '21

Hello everyone, After tremendous efforts, the pull request to switch `text`'s internal representation to UTF-8 is here, and unsurprisingly this is a titan's work. It lives here: https://github.com/haskell/text/pull/365 We are sending out a call for reviewers, as this is a cornerstone of our ecosystem. The performance gains from this PR are huge and I would like to ensure we can have a multitude of eyes to take a look. I wish to express my thanks to all of you. This is definitely the kind of advances that will make Haskell a stronger language for the times to come. Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

The second day of the 2021 Haskell Symposium is now streaming on YouTube
by Hage, J. (Jurriaan) 27 Aug '21

27 Aug '21

Haskellers, Today is the 2nd day of the 2021 Haskell Symposium and it is being streamed on Youtube. If you want a taste of it join us while it is still public. After the invited talk of Mathieu Boespflug yesterday (we maxed out at about a 100 viewer on Youtube and some 74 people in Airmeet) we will have yet another invited talk on Linear Haskell today by Jean-Philippe Bernardy, and one of the five research talks will be on Linear Haskell as well. On top of that there are four more research talks on your favorite programming language. Here’s the link: https://youtu.be/6pJKIjn95eU Do not miss out, and no need to register for ICFP. Best, Jurriaan Hage Chair

1 0

[Haskell] [ANNOUNCE] GHC 8.10.7 released
by Zubin Duggal 27 Aug '21

27 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.7. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.7/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_7.html Blog Post: https://www.haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html This is a small bugfix release, fixing one linking portability issue (#19950) present in GHC 8.10.5 and GHC 8.10.6 on some x86_64 macOS toolchains, which resulted in undefined symbol errors for `___darwin_check_fd_set_overflow`. Issue #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). We claimed to have fixed this in GHC 8.10.6, but alas this wasn't the case. The fix was originally tested on the master branch, which uses a different build configuration from the 8.10 branch. We have now tested the fix on the GHC 8.10 branch and finally squashed the bug. We would like to thank 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. We would also like to thank the hundreds of open-source contributors whose work makes GHC possible. A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8. 10.7-notes.html). As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

Magical Haskell book preview: Haskell and type theory in pictures and in a fun and accessible way
by Anton Antich 26 Aug '21

26 Aug '21

Dear all, I started "Magical Haskell" 3 years ago with the goal to fill the void of explaining typed functional programming from the first principles, but in a fun and accessible way. Imperative patterns really mess with learning Haskell, while alternative top-down approaches are usually too technical and math-heavy, so that the beauty and elegance of the concepts involved is lost on many. So I tried to use the latter, but build it up gradually, from intuition and functional thinking, so that a high school student could understand. Now the book is about 50% ready as I came back to writing it after a sabbatical break, now covers the foundations, functional thinking, different types, typeclasses, and specific examples gently building up from Maybe and List through Monoid and up to Functor and Bifunctor. Applicative, Monad and real world programs via Monad Transformer Stacks are coming up. It is available here: https://leanpub.com/magicalhaskell - free to read online. Would very much appreciate your feedback - what is missing, what do you think of such a style, what is maybe too much, etc. Also, if anyone is ready to contribute a public testimonial - will gladly give a free copy of the ebook and all future updates in offline formats! Thank you very much!

1 0

Haskell Symposium starts right now!
by Hage, J. (Jurriaan) 26 Aug '21

26 Aug '21

Hi all at Haskell Cafe, Just in case you had not registered for ICFP and its workshops, you can still follow the talks of the Haskell Symposium in a live stream. These recordings are currently public, but that may not last for long. Here’s the link: https://www.youtube.com/watch?v=sVrlaF7sCU4 Best, Jur

1 0

IFL'21 call for participation
by Pieter Koopman 25 Aug '21

25 Aug '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> *Registration* Registration is free of charge, but required for participation! Use the below link to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8of… <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> *Scope* The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2021 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. *Program* The program is now available at https://ifl21.cs.ru.nl/Program <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . *Organisation* IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands *PC* Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary [image: beacon]

1 0

Munich Virtual Haskell Meeting, 2021-08-26 @ 19:30
by Leah Neukirchen 24 Aug '21

24 Aug '21

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 26 on Jitsi at 19:30 CEST. **Due to bad weather for meetings outside this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Jitsi link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Some tooling questions
by Sven Panne 23 Aug '21

23 Aug '21

Just 2 quick questions to see if I understand things correctly: * Current Haddock versions have the ability to render hyperlinked coloured source code built-in, there is no need for a separate HsColour executable anymore (IIRC, this was required in ancient times), correct? * The haskell-language-server executables have all their "plugins" compiled and linked into them, correct? So there is e.g. no need for an external ormolu, hlint, ... executable. This would be a good thing, but using the word "plugin" for this is quite confusing for the end user IMHO. For me, plugins are something which you can install in addition to something else. This doesn't seem to be the case here, if I understand the source code correctly. And some final questions regarding the Haskell Language Server: Why are there separate haskell-language-server-X.Y executables plus a wrapper? Why are the executables tied to a fixed GHC version and what exactly does the wrapper do? Which of these executables is used e.g. by Emacs' lsp-mode? This looks quite complicated, at least compared to all the other LSP backends I know: For C++, just point to any clangd; for Groovy, just point to a JAR; for Python just install a single python-lsp-server package (which has real plugins as separate packages BTW), etc. Slightly confused, S.

2 3

Fwd: Unlock instructions
by Henk-Jan van Tuyl 23 Aug '21

23 Aug '21

L.S., Did anyone else get a message like the one below? I did not try to log on to GitLab, as far as I can remember I do not have an account there. Is this some kind of physhing-attempt? Regards, Henk-Jan van Tuyl ------- Forwarded message ------- From: GitLab <gitlab(a)gitlab.haskell.org> To: hjgtuyl(a)chello.nl Subject: Unlock instructions Date: Wed, 18 Aug 2021 13:26:41 +0200 Hello, Henk-Jan! Your GitLab account has been locked due to an excessive amount of unsuccessful sign in attempts. Your account will automatically unlock in 10 minutes or you may click the link below to unlock now. Unlock account -- Message from Stanford University: Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. https://foldingathome.org/ -- http://Van.Tuyl.eu https://HenkJanvanTuyl.werkaandemuur.nl/ https://sfeeraandemuur.nl/winkel/nekutimo/ https://github.com/HJvT https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourde… https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl… Haskell programming --

5 6

[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

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

13 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

Organizing your code files
by Christopher Conforti 12 Aug '21

12 Aug '21

Hi List, I'm a relatively new Haskeller. I've gotten the syntax of the language more or less down, and I'm slowly expanding my vocabulary. I've found in other languages that my coding style and how my code is organized affect both the quality of my code and how easy it is to understand. 'Coding style' refers to how code is organized within a block. For example: ``` foo bar baz bing = x + y * z ``` versus: ``` foo bar baz bing = x + y * z ``` Code organization refers both to how code is organized within a source file (i.e., how code blocks are arranged, how they're grouped, so on) and how source files themselves are organized. I've got the first part down--I've developed a code style that I'm satisfied with, I've tried to fine-tune my style to make maximum effective use of available space (limiting myself to 72 columns, and a block size of no more than 30 lines) so as to force myself to extract and abtract away unnecessary details. The second part is the one I'm having trouble with. There are so many ways to organize one's code that I don't even know where to begin developing a method that I like other than to ask other Haskellers how they do it and why they like doing it that way. So there you have it: How do you organize your code, and why? Cheers! -- Christopher Conforti

5 6

Different advice for type classes for end-user app and libraries?
by Ruben Astudillo 12 Aug '21

12 Aug '21

Hello list! 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. 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 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. 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? Thanks for your time! [1]: https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html -- -- Rubén. pgp: 4EE9 28F7 932E F4AD

2 1

Re: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?
by YueCompl 12 Aug '21

12 Aug '21

Thanks Michał, I feel less confused as I realized the non-halting possibility per bottoms, from your hint. I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs <https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs> > Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. > Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity > Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? No such family of `Num` classes exists to my aware by now, I just can't help wondering why. Cheers, Compl > On 2021-08-04, at 02:38, Michał J Gajda <mjgajda(a)gmail.com> wrote: > > Dear Yue, > > Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! > > Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. > > Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. > > The problem with this approach is indeed a silent handling. > > But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-i… <https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-i…> > > Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. > -- > Cheers > Michał

4 10

Call for participation: ML Family Workshop 2021
by Jonathan Protzenko 11 Aug '21

11 Aug '21

We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021. We invite you to subscribe to, and attend the workshop, in addition to the main ICFP conference. We are thrilled to announce that Don Syme will give this year's keynote: "Narratives and Lessons from The Early History of F#". Please join us! The program features 14 exciting submissions, including 4 short talks. The workshop will be held online in the 6pm-3am time band (Seoul Time). Talks will be pre-recorded and uploaded online for those who cannot attend. * Program: https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#program * Keynote: https://icfp21.sigplan.org/details/mlfamilyworkshop-2021-papers/15/Keynote-… * ICFP home: http://icfp21.sigplan.org/home ## Program committee Danel Ahman (University of Ljubljana) Robert Atkey (University of Strathclyde) Frédéric Bour (Tarides) Ezgi Çiçek (Facebook London) Youyou Cong (Tokyo Institute of Technology) Richard A. Eisenberg (Tweag I/O) Martin Elsman (University of Copenhagen, Denmark) Ohad Kammar (University of Edinburgh) Naoki Kobayashi (University of Tokyo, Japan) Benoît Montagu (Inria) Jonathan Protzenko (Microsoft Research) (Chair) Kristina Sojakova (INRIA Paris) Don Syme (Microsoft) Matías Toro (University of Chile) Katsuhiro Ueno (Tohoku University)

1 0

Re: [Haskell-cafe] Help on syntactic sugar for combining lazy & strict monads?
by Olaf Klinke 10 Aug '21

10 Aug '21

> However, a lazy interpreter causes problems when trying to introduce > *observation* statements (aka conditioning statements) into the monad > [3]. For example, > > run_lazy $ do > x <- normal 0 1 > y <- normal x 1 > z <- normal y 1 > 2.0 `observe_from` normal z 1 > return y > > In the above code fragment, y will be forced because it is returned, and > y will force x. However, the "observe_from" statement will never be > forced, because it does not produce a result that is demanded. I'm very confused. If the observe_from statement is never demanded, then what semantics should it have? What is the type of observe_from? It seems it is a -> m a -> m () for whatever monad m you are using. But conditioning usually is a function Observation a -> Dist a -> Dist a so you must use the result of the conditioning somehow. And isn't the principle of Monte Carlo to approximate the posterior by sampling from it? I tend to agree with your suggestion that observations and sampling can not be mixed (in the same do-notation) but the latter have to be collected in a prior, then conditioned by an observation. What is the semantic connection between your sample and obsersvation monad? What is the connection between both and the semantic probability distributions? I claim that once you have typed everything, it becomes clear where the problem is. Olaf P.S. It has always bugged me that probabilists use elements and events interchangingly, while this can only be done on discrete spaces. So above I would rather like to write (2.0==) `observe_from` (normal 0 1) which still is a non-sensical statement if (normal 0 1) is a continuous distribution where each point set has probability zero.

2 4

Re: [Haskell-cafe] Organizing your code files
by Johannes Waldmann 10 Aug '21

10 Aug '21

Hécate: > * Type variables are made explicit, and as such I annotate even the > simplest of them (with `:: Type`) This! I am moving towards that style. Especially in teaching (type abstraction, type application) where I want everything to be very much explicit - before discussing abbreviations and omissions (type inference). With current GHC, this is entirely possible but looks somewhat clumsy {-# language ExplicitForall, KindSignatures #-} import Data.Kind (Type) g :: forall (t :: Type) . t -> t ; g x = x {-# language TypeApplications #-} g @N Z yes I could hide these pragmas somewhere but that again feels wrong. But - good thing: after https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-… (I understand that GHC2021 is default-enabled in GHC-9.2) we no longer need to write these pragmas. Yay! Sadly, we still need the import. - J. NB: Haskell's implicit declaration of type variables by their starting with lowercase letters always reminds me of Fortran's implicit type specification for variables, going by the first letter (I .. N means integer). Fortran has "implicit none" though, so let's have "t :: Type"...

1 0

Re: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?
by Olaf Klinke 09 Aug '21

09 Aug '21

> * libraries assume a naive equality works for all types. Holds in a world > of infinte precision and lossless operations, but never holds for > approximations. > > * our propagation of universal error values is incomplete, and usually > missing from complex algorithms. In other words `Either String` Monad does > not work: we want collections of error values just like we have collections > of inputs. > > Personally I will be overjoyed when our community finally gets the better > type class library for approximated types. > > Would You agree to review a teaser if I post it here? Yes, please. I'm curious whether there is a single abstraction that can describe both finite precision with variable errors as well as potentially infinite precision with known errors. Olaf

1 0

Re: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?
by Olaf Klinke 09 Aug '21

09 Aug '21

> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: > > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? > > No such family of `Num` classes exists to my aware by now, I just can't help wondering why. > > Cheers, > Compl > I like to think of NaN as a glimpse of interval arithmetic. NaN is the interval -infintity to infinity [*]. When ordering intervals by reverse inclusion, NaN is indeed the bottom of the domain. For a general (closed) interval [x,y], how would you answer the questions [x,y] < [1,1]? [x,y] /= [1,1]? There are several possibilities known, extending relations on points to relations on sets. See Smyth-, Hoare- and Egli-Milner lifting of relations. So a more descriptive type of Float-ordering may be (<) :: Float -> Float -> RelationLifting -> Bool For example, NaN /= NaN under all three relation liftings mentioned above, but also NaN == NaN, so a /= b = not (a == b) does not hold anymore. > If we take this into consideration, we notice that most interesting > computations occur on collections of values, and thus yield a > collection of results, not just a single output. Indeed, one route to real arithmetic is via limits of collections of approximants. For example, consider a dense set of rationals, excluding zero, where that all arithmetic operations are well-defined and total on the approximants. Then express a real number as (Dedekind-)cuts and see what cut operations like 0/0 result in. Each non-proper cut corresponds to a special Float value. Incidentally, this is how Conway constructed his surreal numbers that also contain values like infinity and -0. I'm in favour that there be two floating-point types: One IEEE- compliant that behaves just like in other languages, and one more lawful one (thereby with fewer class instances) that leverages the expressive power of Haskell. Ho matter how broken, the former should be the default unless we want to alienate numerically inclined Haskell adopters. Olaf [*] The mathematical function \(x,y) -> x/y attains every real value arbitrarily close to (0,0), whence NaN = 0/0 should be interpreted as the interval encompassing the real line. Likewise log(0) for complex 0.

2 7

Call for Workshops - FLoC 2022
by Victor Perez 06 Aug '21

06 Aug '21

Second Call for Workshops- FLoC 2022 — The 2022 Federated Logic Conference July 31 - August 12, 2022 Haifa, Israel http://www.floc2022.org/ CALL FOR WORKSHOPS The Eighth Federated Logic Conference (FLoC 2022) will host the following ten conferences and affiliated workshops. LICS (37th Annual ACM/IEEE Symposium on Logic in Computer Science) http://lics.rwth-aachen.de/ Workshop chair: Frederic Blanqui Frederic.Blanqui(a)inria.fr FSCD (7th International Conference on Formal Structures for Computation and Deduction) http://fscd-conference.org/ Workshop chair: Nachum Dershowitz nachumd(a)tau.ac.il ITP (13th International Conference on Interactive Theorem Proving) https://itp-conference.github.io/ Workshop chair: Cyril Cohen cyril.cohen(a)inria.fr IJCAR (International Joint Conference on Automated Reasoning) http://www.ijcar.org Workshop chairs: Simon Robillard simon.robillard(a)imt-atlantique.fr Sophie Tourret stourret(a)mpi-inf.mpg.de CSF (35th IEEE Computer Security Foundations Symposium) http://www.ieee-security.org/CSFWweb/ Workshop chair: Musard Balliu musard(a)kth.se CAV (34th International Conference on Computer Aided Verification) http://i-cav.org/ Workshop chair: TBD KR (19th International Conference on Principles of Knowledge Representation and Reasoning) http://www.kr.org/ Workshop chair: Stefan Borgwardt stefan.borgwardt(a)tu-dresden.de ICLP (38th International Conference on Logic Programming) https://www.cs.nmsu.edu/ALP/conferences/ Workshop chair: Daniela Inclezan inclezd(a)miamioh.edu SAT (25th International Conference on Theory and Applications of Satisfiability Testing) http://www.satisfiability.org Workshop chair: Alexander Nadel alexander.nadel(a)intel.com CP (25th International Conference on Principles and Practice of Constraint Programming) http://a4cp.org/events/cp-conference-series Workshop chair: TBD SUBMISSION OF WORKSHOP PROPOSALS Researchers and practitioners are invited to submit proposals for workshops on topics in the field of computer science, related to logic in the broad sense. Each workshop proposal must indicate one affiliated conference of FLoC 2022. It is strongly suggested that prospective workshop organizers contact the relevant conference workshop chair before submitting a proposal. Each proposal should consist of the following two parts. 1) A short scientific justification of the proposed topic, its significance, and the particular benefits of the workshop to the community, as well as a list of previous or related workshops (if relevant). 2) An organisational part including: - contact information for the workshop organizers; - proposed affiliated conference; - estimate of the number of workshop participants (please note that small workshops, i.e., of less than ~13 participants, will likely be cancelled or merged); - proposed format and agenda (e.g. paper presentations, tutorials, demo sessions, etc.); - potential invited speakers (note that expenses of workshop invited speakers are not covered by FLoC); - procedures for selecting papers and participants; - plans for dissemination, if any (e.g. a journal special issue); - duration (which may vary from one day to two days); - preferred period (pre or post FLoC); - virtual/hybrid backup plans (including platform preference). The FLoC Organizing Committee will determine the final list of accepted workshops based on the recommendations from the Workshop Chairs of the hosting conferences and availability of space and facilities. Proposals should be submitted through EasyChair: https://easychair.org/conferences/?conf=floc2022workshops Please see the Workshop Guidelines page: https://floc2022.org/workshops/ for further details and FAQ. IMPORTANT DATES Submission of workshop proposals deadline: September 27, 2021 (note extended deadline) Notification: November 1, 2021 Pre-FLoC workshops: Sunday & Monday, July 31–August 1, 2022 (note corrected dates) Post-FLoC workshops: Thursday & Friday, August 11-12, 2022 CONTACT INFORMATION Questions regarding proposals should be sent to the workshop chairs of the proposed affiliated conference. General questions should be sent to: shaull(a)technion.ac.il GuillermoAlberto.Perez(a)uantwerpen.be FLoC 2022 WORKSHOP CHAIRS Shaull Almagor Guillermo A. Perez

1 0

Call for Lightning Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 06 Aug '21

06 Aug '21

Call for Lightning Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Thursday, 19 Aug, 2021 (or when slots are full, whichever is sooner) Workshop: Sunday, 22 Aug, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. 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. We will 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. Submissions should be made via Google form: https://forms.gle/BmUSyWWTXt1AMTec8 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 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, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Contact ------- * Ningning Xie <xnningxie(a)gmail.com>

1 0

Call for Participation: ICFP 2021
by Sam Tobin-Hochstadt 06 Aug '21

06 Aug '21

===================================================================== Call for Participation ICFP 2021 26th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 22 - August 27, 2021 Online http://icfp21.sigplan.org/ Early Registration until August 7! ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. This year, the conference will be a virtual event. All activities will take place online. The main conference will take place from August 23-25, 2021 during two time bands. The first band will be 4PM-11PM Seoul time, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 3PM-10PM New York, the following day. We’re excited to announce that ICFP 2021 will feature an invited talk from Ravi Chugh of the University of Chicago. Keynote sessions will take place at 10 PM Seoul/9 AM New York. ICFP has officially accepted 35 exciting papers, and (in its second year) there will also be presentations of 4 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 7th, 2021. Registration is not free, but is significantly lower than usual, including a $10 discounted registration option available to all. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2021conf/ICFP21/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp21.sigplan.org/home * Accepted papers: http://icfp21.sigplan.org/track/icfp-2021-papers#event-overview * JFP Talks: https://icfp21.sigplan.org/track/icfp-2021-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2021conf/ICFP21/register.php Early registration ends 8 August, 2021. * Programming contest: https://icfpcontest2021.github.io/ * Student Research Competition: https://icfp21.sigplan.org/track/icfp-2021-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/26) * Haskell Implementors' Workshop (8/22) * Haskell Symposium (8/26-8/27) * Higher-Order Programming with Effects (8/22) * miniKanren Workshop (8/26) * ML Family Workshop (8/26) * OCaml Workshop (8/27) * Programming Languages Mentoring Workshop (8/22) * Scheme Workshop (8/27) * Type-Driven Development (8/22) ### ICFP Organizers General Chair: Sukyoung Ryu (KAIST, South Korea) Program Chair: Ron Garcia (UBC, Canada) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Gabriel Scherer (INRIA Saclay, France) Industrial Relations Chair: Alan Jeffrey (Roblox, USA) Simon Marlow (Facebook, UK) Programming Contest Organizers: Alex Lang and Jasper Van der Jeugt Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Anders Miltner (University of Texas, USA) Workshops Co-Chairs: Zoe Paraskevopoulou (Northeastern University, USA) Leonidas Lampropoulos (University of Maryland, USA) Video Co-Chairs: Leif Andersen (Northeastern University, USA) Ben Chung (Northeastern University, USA) Student Volunteer Co-Chairs: Hanneli Tavante (McGill University, Canada) Jaemin Hong (KAIST, South Korea) Lily Bryant (UBC, Canada) Accessibility Co-Chairs: Lindsey Kuper (UCSC, USA) Kathrin Stark (Princeton, USA)

1 0

[ANN] Cabal-3.6.0.0
by Emily Pillmore 05 Aug '21

05 Aug '21

Hello All, The Cabal team is excited to announce the release of Cabal-3.6.0.0! This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself. For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548. If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat ( http://libera.chat/ ) to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org ( http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together! For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues. Happy hacking! Emily

1 0

IFL'21 Final call for papers
by Pieter Koopman 05 Aug '21

05 Aug '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> ================================================================================ Note: - We do accept extended abstracts for presentation - Submission is open - Registration is open Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2021 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Industrial track and topics of interest This year's edition of IFL explicitly solicits original work concerning *applications* of functional programming in industry and academia. These contributions will be reviewed by experts with an industrial background. Topics of interest to IFL include, but are not limited to: * language concepts * type systems, type checking, type inferencing * compilation techniques * staged compilation * run-time function specialisation * run-time code generation * partial evaluation * (abstract) interpretation * meta-programming * generic programming * automatic program generation * array processing * concurrent/parallel programming * concurrent/parallel program execution * embedded systems * web applications * (embedded) domain-specific languages * security * novel memory management techniques * run-time profiling performance measurements * debugging and tracing * testing and proofing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * applications of functional programming in the industry, including ** functional programming techniques for large applications ** successes of the application functional programming ** challenges for functional programming encountered ** any topic related to the application of functional programming that is interesting for the IFL community Post-symposium peer-review Following IFL tradition, IFL 2021 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. Moreover, the proceedings will also be made publicly available as open access. Important dates Submission deadline of draft papers: 17 August 2021 Notification of acceptance for presentation: 19 August 2021 Registration deadline: 30 August 2021 IFL Symposium: 1-3 September 2021 Submission of papers for proceedings: 6 December 2021 Notification of acceptance: 3 February 2022 Camera-ready version: 15 March 2022 Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . (For LaTeX users, start your document with \documentclass[format=sigconf]{acmart}.) Note that this format has a rather long but limited list of packages that can be used. Please make sure that your document adheres to this list. The submission Web page for IFL21 is https://easychair.org/conferences/?conf=ifl21 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Organisation IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands PC: Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary Virtual symposium Because of the Covid-19 pandemic, this year IFL 2021 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. Registration Please use the link below to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8of… <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> Thanks to the sponsors and the support of the Radboud university registration is free of charge. [image: beacon]

1 0

Re: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?
by Michal J Gajda 04 Aug '21

04 Aug '21

Dear Yue, Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. The problem with this approach is indeed a silent handling. But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-i… Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. -- Cheers Michał

1 0

Re: [Haskell-cafe] Parsing XML
by Michal J Gajda 04 Aug '21

04 Aug '21

Dear John, I recommend Xeno: https://gitlab.com/migamake/xeno It was released on Hackage some time ago by Chris Done, then maintained by Marco Zocca. It was benchmarked against fastest parsers in both Haskell and other languages: * https://arxiv.org/abs/2011.03536 * http://neilmitchell.blogspot.com/2016/12/new-xml-parser-hexml.html It allows you to use SAX and DOM-style processing. It has an awesome memory efficiency that is surpassed only by PugiXML parser (which builds DOM in place, but occasionally crashes). It does not support some XML features (namespaces, entity normalization etc.), but these can be added as postprocessing after the DOM is built. It is maintained. And there is a yet unreleased version that can be used to parse HTML documents and documents that are not well formed. Disclosure: I am current maintainer. -- Cheers Michał J. Gajda

1 0

GHC 9.x on M1 mac?
by Stuart Hungerford 04 Aug '21

04 Aug '21

Hi Haskellers, Has anyone been able to build a 9.x series GHC installation for the M1 mac with macOS, in native binary form (i.e. not under Rosetta translation)? TIA, Stu

1 0

Why not some subclass of Floating to model NaNs as some handleable bottom?
by YueCompl 03 Aug '21

03 Aug '21

Dear Cafe, I kinda understand the [Floating](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Fl… <https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Floating>) class doesn't care about NaN, as not expecting all floating point implementations to have such semantics. But [IEEE Silent NaN](https://en.wikipedia.org/wiki/NaN#Quiet_NaN <https://en.wikipedia.org/wiki/NaN#Quiet_NaN>) has become a norm today, I think it deserves more than mere [isNaN](https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN <https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN>) in the [RealFloat](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:R… <https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:RealFloat>) class. While [Signaling NaN](https://en.wikipedia.org/wiki/NaN#Signaling_NaN <https://en.wikipedia.org/wiki/NaN#Signaling_NaN>) can be an `Exception` triggering bottom like "divide by zero" is, the silent `NaN` feels like a different kind of bottom, or some thing similar to `Nothing` as in the `Num a => Maybe a` monad? Is Haskell's type system capable of encoding silent NaN as a special kind/type of bottom that handleable? Though I don't think I've gained correct understanding at all, on "bottom"s, I'm interested in what options we have to encode them, especially ergonomics ways to handle them accordingly. Best regards, Compl

1 0

Sets, typeclasses and functional dependencies
by Stuart Hungerford 02 Aug '21

02 Aug '21

Hi Haskellers, After reading: https://stackoverflow.com/questions/34790721/where-is-the-set-type-class https://stackoverflow.com/questions/25191659/why-is-haskell-missing-obvious… https://stackoverflow.com/questions/11508642/haskell-how-can-i-define-a-typ… I can see why Haskell base does not provide typeclasses for sets. I'm wondering now though if I did create a Set typeclass what it would look like. There's several approaches using various language extensions and to me this approach using functional dependencies seems simpler than the other approaches: class Setish set a | set -> a where empty :: set singleton :: a -> set -- and so on. My question is how does the functional dependency in Setish interact with "extra" types needed for richer set operations like finding the powerset or taking a cartesian product? Something like: class Setish set a | set -> a where empty :: set singleton :: a -> set power_set :: set -> ?something product :: set -> ?something -> ?something -- and so on. TIA, Stu

4 5

Explanation of Data.Set, please
by Galaxy Being 02 Aug '21

02 Aug '21

I'm looking at this <https://hackage.haskell.org/package/containers-0.6.5.1/docs/src/Data.Set.In…> code and wondering, first, about the strategy behind the data type Set itself data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip It says it's a "balanced tree." I found this <http://groups.csail.mit.edu/mac/users/adams/BB/index.html> talking about maybe why that is. Will read. But in the meantime, any explanation in plain English as to why we're doing it as a tree and not some other structure would be helpful. And why are we bringing Size along, and in general, why all the strictness !'s? All this might have something to do with why a balanced tree is better than quick-and-dirty list representation like I see in beginner tutorials? Next, is this ZFC? I've seen treatments that supposedly are ZFC-friendly. Finally, I've taken a preliminary look at Agda, and right from the start there's Set, and no doubt an entirely alternative, category universe approach to the concept of set theory. Any contrast and compare between Haskell and Agda's set notions would be appreciated. Haskell seems to dance in and out of Category Theory, while Agda seems pretty much just CT.... -- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

3 2

I want to read documents about haskell.
by Kim Chaegon 01 Aug '21

01 Aug '21

I want read documents about haskell, pure functional language. Rgank you!

2 1

Re: [Haskell-cafe] Help on syntactic sugar for combining lazy & strict monads?
by Olaf Klinke 30 Jul '21

30 Jul '21

On Thu, 29 Jul 2021, Benjamin Redelings wrote: > Hi Olaf, > > I think you need to look at two things: > > 1. The Giry monad, and how it deals with continuous spaces. I believe I understand the Giry monad well, and it is my measuring stick for functional probabilistic programming. Even more well-suited for programming ought to be the valuation monad, because that is a monad on domains, the [*] semantic spaces of the lambda calculus. Unfortunately, to my knowledge until now attempts were unsuccessful to find a cartesian closed category of domains which is also closed under this probabilistic powerdomain construction. [*] There are of course other semantics, domains being one option. > > 2. The paper "Practical Probabilistic Programming with Monads" - > https://doi.org/10.1145/2804302.2804317 Wasn't that what you linked to in your original post? As said above, measure spaces is the wrong target category, in my opinion. There is too much non constructive stuff in there. See the work of Culbertson and Sturtz, which is categorically nice but not very constructive. > > Also, observing 2.0 from a continuous distribution is not nonsensical. > > -BenRI Perhaps I am being too much of a point-free topologist here. Call me pedantic. Or I don't understand sampling at all. To me, a point is an idealised object, only open sets really exist and are observable. If the space is discrete, points are open sets. But on the real line you can not measure with infinite precision, so any observation must contain an interval. That aligns very nicely with functional programming, where only finite parts of infinite lazy structures are ever observable, and these finite parts are the open sets in the domain semantics. So please explain how observing 2.0 from a continuous distribution is not nonsensical. Olaf > > On 7/21/21 11:15 PM, Olaf Klinke wrote: >>> However, a lazy interpreter causes problems when trying to introduce >>> *observation* statements (aka conditioning statements) into the monad >>> [3]. For example, >>> >>> run_lazy $ do >>> x <- normal 0 1 >>> y <- normal x 1 >>> z <- normal y 1 >>> 2.0 `observe_from` normal z 1 >>> return y >>> >>> In the above code fragment, y will be forced because it is returned, and >>> y will force x. However, the "observe_from" statement will never be >>> forced, because it does not produce a result that is demanded. >> >> I'm very confused. If the observe_from statement is never demanded, then >> what semantics should it have? What is the type of observe_from? It seems >> it is >> a -> m a -> m () >> for whatever monad m you are using. But conditioning usually is a function >> Observation a -> Dist a -> Dist a >> so you must use the result of the conditioning somehow. And isn't the >> principle of Monte Carlo to approximate the posterior by sampling from it? >> I tend to agree with your suggestion that observations and sampling can not >> be mixed (in the same do-notation) but the latter have to be collected in a >> prior, then conditioned by an observation. >> >> What is the semantic connection between your sample and obsersvation monad? >> What is the connection between both and the semantic probability >> distributions? I claim that once you have typed everything, it becomes >> clear where the problem is. >> >> Olaf >> >> P.S. It has always bugged me that probabilists use elements and events >> interchangingly, while this can only be done on discrete spaces. So above I >> would rather like to write >> (2.0==) `observe_from` (normal 0 1) >> which still is a non-sensical statement if (normal 0 1) is a continuous >> distribution where each point set has probability zero. >

1 0

Re. Looking for exemplars of "boring" or "simple" Haskell projects... (Rishiyur Nikhil)
by Stuart Hungerford 30 Jul '21

30 Jul '21

On Thu, Jul 29, 2021 at 10:07 PM <haskell-cafe-request(a)haskell.org> wrote: > [...] > A couple of years ago I wrote "Forvis", a "complete" semantics of the > RISC-V instruction set in "extremely elementary" Haskell. > > It's free and open-source, at: > https://github.com/rsnikhil/Forvis_RISCV-ISA-Spec > > "Extremely Elementary" Haskell: small subset of Haskell 98. No > type classes, no monads (except the top-level driver that uses > standard IO), no GHC extensions, nothing. Just vanilla function > definitions and vanilla algebraic types (a "Miranda" subset). > > Motivation: appeal to hardware designers, compiler writers, and others > who are keenly interested in a clearly readable and executable precise > spec of RISC-V semantics, but are not at all interested in learning > Haskell. Thanks for that, I'll have a look. Stu

1 0

Re. Looking for exemplars of "boring" or "simple" Haskell projects...
by Rishiyur Nikhil 28 Jul '21

28 Jul '21

A couple of years ago I wrote "Forvis", a "complete" semantics of the RISC-V instruction set in "extremely elementary" Haskell. It's free and open-source, at: https://github.com/rsnikhil/Forvis_RISCV-ISA-Spec "Extremely Elementary" Haskell: small subset of Haskell 98. No type classes, no monads (except the top-level driver that uses standard IO), no GHC extensions, nothing. Just vanilla function definitions and vanilla algebraic types (a "Miranda" subset). Motivation: appeal to hardware designers, compiler writers, and others who are keenly interested in a clearly readable and executable precise spec of RISC-V semantics, but are not at all interested in learning Haskell. It's about 12K-13K lines of Haskell, all in one 'src/' directory. Full "standard ISA" coverage: - Unprivileged ISA: - RV32I (32-bit) and RV64I (64-bit) basic Integer instructions - Standard ISA extensions M (Integer Mult/Div), A (Atomics), C (Compressed) and FD (Single- and Double-precision floating point) - Privileged ISA: Modes M (Machine), S (Supervisor) and U (User), including full complement of CSRs (Control and Status Registers). This includes full trap and interrupt handling, and RISC-V Virtual Memory schemes Sv32, Sv39 and Sv48. I've tested it on all the standard RISC-V ISA tests (pass), booted a Linux kernel (about 200 Million RISC-V Instructions), and the much smaller real-time OS FreeRTOS. I'm sure it'll work for any other RISC-V software as well. For this, the sources contain additional code to package the "CPU" into a small "system", by adding Haskell models of memory and a UART. I haven't looked at it since early 2020, but it should all still work fine. Nikhil

1 0