December 2024 - Haskell-Cafe

Save the date: Haskell Ecosystem Workshop and Haskell Implementors' Workshop 2025
by Andreas Herrmann 15 Dec '24

15 Dec '24

Save the date for the Haskell Ecosystem Workshop and the Haskell Implementors' Workshop taking place on June 5 & 6 2025 near Zurich, Switzerland, hosted by the Haskell Foundation at the OST (Eastern Switzerland University of Applied Sciences) in Rapperswil, and co-located with ZuriHac (June 7-9). Expect a more detailed announcement, registration, and a call for proposals in early 2025. The Haskell Ecosystem Workshop is a workshop organized by the Haskell Foundation for those who want to gain a deeper understanding of the Haskell tooling ecosystem, whether to better leverage those tools or to become contributors. The Haskell Implementors' Workshop is a community event for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. In the past the Haskell Implementors' Workshop used to be co-located with ICFP (International Conference on Functional Programming), next year it will be co-located with ZuriHac to be accessible to a broader audience. Contact Jose Calderon, executive director of the Haskell Foundation, if you have any questions regarding the Haskell Ecosystem Workshop. Contact Andreas Herrmann, program chair for the Haskell Implementors' Workshop 2025, if you have any questions regarding the Haskell Implementors' Workshop.

1 0

Engineering Value of Functional Programming
by Mostafa Touny 10 Dec '24

10 Dec '24

Dear Haskellers, I hope my email finds you in a good shape. Software engineers usually deviate away from Haskell, in the name of rapid development. In Pure Math, I can see the power of abstraction; It resulted in broad applications, with a sustainable and scalable usage in all humanity's sciences. Software development should benefit as well, avoiding technical debts and refactoring costs. Haskell seems more promising as it is empowered by category and type theory. Nonetheless, I cannot find a single management methodology, like Eric Ries' lean startup and iterative agile, that demonstrates the power of functional programming from the perspective of project management. Discussion. - Do you agree category and type theory could reduce projects costs? - Is it true, no guideline is designed for demonstrating their worthiness? Sincerely, Mostafa Touny https://mostafatouny.github.io/

8 12

ANN: hledger 1.41
by Simon Michael 09 Dec '24

09 Dec '24

I'm pleased to announce hledger 1.41 ! This release brings: - a notable valuation fix - pervasive improved HTML and FODS output - multiple depths - terminal pagination - robust export to Beancount ..and more. Thank you to contributors Dmitry Astapov, Stephen Morgan, Bas van Dijk, Gal Lakovnik Gorenec, amano.kenji, gesh, and especially Henning Thielemann ! Best wishes, -Simon - https://github.com/simonmichael/hledger/releases/1.41 - https://hledger.org/relnotes.html#2024-12-09-hledger-141 - https://hledger.org/install hledger is free, robust, friendly, multicurrency, double-entry, plain text accounting software for unix, mac, windows, and the web. Written in Haskell for reliability, it is built around human-readable, version-controllable plain text files. It is inspired by and largely compatible with Ledger CLI, and convertible to and from Beancount. For more info or help, see https://hledger.org and the support page. Newcomers, experts, contributors, sponsors, feedback are welcome!

1 0

Imports as first class functions
by julian getcontented.com.au 08 Dec '24

08 Dec '24

Further to the previous message about modules and imports, what would be *really* useful would be if importing was in some sense “just a function” in IO or some other Monad and therefore also if modules were represented as some Haskell data structure. That’d obviously make the top level ambient context of a module of Haskell into a sort of monadic action, so it’d be a bit weird, tho at the moment who’s to say what it is anyway? It’s certainly not something that’s first class to the language or able to be programmed as it stands. I suppose this is sounding a little like I’m interested in homoiconicity in some sense, and that’s probably not far from the truth. The main reason I would find this useful is similar to what Sylvain was saying about storing modules of code in databases. I have a system that produces “representations” as Text and then sometimes compiles it as Haskell source (and it’s meta-recursive in that there are many of these little pieces of executed code that then compile others’ outputs, etc)… and even if we don’t have programmatic control over actual compilation or which versions of libraries of code to include, having programmatic control over where the data for modules’ sources comes from would be fantastic. Given that importing is just some magic declaration at the moment that’s kind of outside the language’s programmable constructs, tho, I can’t see that happening without some major reworking, tho, really. Is there appetite for such a thing? One of the things a little strange about the programming industry is how quick we are to invent entirely new languages rather than attempt to modify existing ones and beat them into a new more flexible shape so we can shoehorn our new requirements into a more flexible frame. I realise it’s not always possible, but surely if we all got together and worked on it we could do it? Really, I probably don’t know enough about the internal workings of Haskell & GHC to know if this is crazy or partly reasonable, but crazy ideas are sometimes fantastic, so I’m asking anyway. It would be *glorious* if stack (or cabal, or whatever package manager we use) itself were programmable in the sense that it could be called from within Haskell itself using a typed API and data could drive its included packages, and its type could be a function whose range was IO ByteString, providing the compiled binary. I guess where I’m driving with all this is that it’d be amazing if more of the language and package system and build tools and dependencies were first class and/or have an API just like the GHC API exists because being able to manipulate these things from programs would be great and simplify a lot of currently complex stuff; the only way to do that at the moment is to leave Haskell’s type safety and deal with the textual interfaces in System.Process et al. (I’m actually using System.Process.Streaming, but that’s neither here nor there). I do have a further idea I’ve been pondering for a long while that’s even more crazy than these two, but I might leave that for later, if at all; it has to do with programmability of syntax or lack thereof. Essentially, my system is aiming at keeping everything (source, executables, results of all kinds) separated into small pieces, and results cached so that I don’t have to continually recompile and recompute things that have already been compiled and computed before. It has some of the same ideas as unison in the content hashing sense, tho not the caching at the AST level because Haskell doesn’t work like that, and I’m not interested in building a monolithic unison/smalltalk-style “image/database/world” that has to have everything imported into it — rather the other way around — to have little programs that use parsing, do one thing, and have a typed interface between each of them that glues them all together as and when needed. Apologies that it’s so hand-wavey. Maybe there’s a better place or way to discuss such ideas? If so, let me know. Thanks!

5 6

10 PhD studentships in Nottingham
by Graham Hutton 03 Dec '24

03 Dec '24

Dear all, The School of Computer Science at the University of Nottingham in the UK is seeking applications for 10 fully-funded PhD studentships: https://tinyurl.com/ten-phds-2025 Applicants in the area of the Functional Programming Lab (tinyurl.com/fp-notts) are strongly encouraged! If you are interested in applying, please contact a potential supervisor as soon as possible; the application deadline is 6th April 2025: Thorsten Altenkirch - constructive logic, proof assistants, homotopy type theory, category theory, lambda calculus. Ulrik Buchholtz - homotopy type theory, synthetic homotopy theory, proof assistants, constructive mathematics, and related topics. Graham Hutton - not seeking a new student this year, but these notes on the process may be useful: tinyurl.com/phd-notes Nicolai Kraus - not seeking a student through this scheme, but has two other PhD positions available: tinyurl.com/kraus-phds Dan Marsden - category theory, logic, finite model theory, diagrammatic reasoning, foundations of computer science. Best wishes, The FP Lab University of Nottingham +-----------------------------------------------------------+ 10 Fully-Funded PhD Studentships School of Computer Science University of Nottingham, UK https://tinyurl.com/ten-phds-2025 Applications are invited from home and international students for up to 10 fully-funded PhD studentships offered by the School of Computer Science, starting on 1st October 2025. The topics for the studentships are open, but should relate to the interests of one of the School’s research groups: Cyber-Physical Health and Assistive Robotics; Computational Optimisation and Learning Lab; Computer Vision Lab; Cyber Security; Functional Programming; Intelligent Modelling and Analysis; Mixed Reality Lab; Lab for Uncertainty in Data and Decision Making; Visualisation and Computer Graphics; Responsible Digital Futures. The studentships are fully funded for 3.5 years and include a stipend of £19,237 per year and tuition fees. Applicants are normally expected to have a first-class Bachelor or Masters degree or international equivalent, in a related discipline. If you are interested in applying, please contact a potential supervisor as soon as possible, and at least two weeks prior to the closing date. If the supervisor wishes to support your application, they will direct you to make an official application through the MyNottingham system. Closing date for applications: Sunday 6th April 2025 +-----------------------------------------------------------+ 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

GHC 9.8.4 is now available
by Ben Gamari 02 Dec '24

02 Dec '24

The GHC developers are happy to announce the availability of GHC 9.8.4. Binary distributions, source distributions, and documentation are available on the [release] page. This release is a small release fixing a few issues noted in 9.8.3, including: * Update the `filepath` submodule to avoid a misbehavior of `splitFileName` under Windows. * Update the `unix` submodule to fix a compilation issue on `musl` platforms * Fix a potential source of miscompilation when building large projects on 32-bit platforms * Fix unsound optimisation of `prompt#` uses A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling! - Ben [release]: https://www.haskell.org/ghc/download_ghc_9_8_4.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.4/docs/users_guide/9.8.4-notes.html

1 0

Re: [Haskell-cafe] Files and Modules
by julian getcontented.com.au 02 Dec '24

02 Dec '24

Thanks. Understood about the Linker. I was thinking the linking could be some final phase that was separated out in such a way that would still be compatible with the file system (a HasLinker constraint? ;-) j/k). But to go back to what you were saying, if we had the ability to decouple modules from files it would mean I could set up a notion of dependency between the modules that I have stored in Texts in such a way that I wouldn’t need to repeat code between the Texts when I want to share code as I’m compiling chunks of it. At the moment I try hard to keep the set of common items shared between all the code I have because it makes it simpler to manage and keeps duplication low, and it also means the call to stack that I have only has to include a small set of packages and can be common between all the combined sets of code I have. On 2 Dec 2024, at 11:00 PM, haskell-cafe-request(a)haskell.org wrote: One compromise GHC could make would be abstract the notion of module from the Haskell source (multiple modules per file, no file involved at all), but ultimately as Brandon says, the file system has to get involved for the linker, so the concept of a module needs to remain compatible with the action of writing it as a file.

2 2

Files and Modules
by julian getcontented.com.au 02 Dec '24

02 Dec '24

In a recent project that compiles Haskell source from data (ie of type Text from the module Data.Text), it would be useful to be able to decouple the dependency between GHC’s notion of where modules are and the file system. This doesn’t seem to be programmatically controllable. How tenable is this? Would it be useful for anyone else to have compilation itself be more first class in the language? If I think about languages such as LISP/Racket/Clojure, there’s a certain flexibility there that Haskell lacks, but it’s not apparent why, other than historical reasons? Would this imply changing compiling and linking into a different Monad than IO? At the moment to compile some source that exists in Text, my system has to write a bunch of temp files including the Text that contains the main module, and then put other modules in directories named a certain way, run the compiler across them via some exec command to call GHC or stack externally, then read the resulting executable back off disk to store it in its final destination. It might be useful to be able to do this from within Haskell code directly, partly similarly to how the hint library works. Though, in this case it would almost certainly also require being able to have two versions of GHC loaded at once, which would also imply being able to simultaneously have multiple or different versions of libraries loaded at once, too, and possibly also just from data, ie not from disk. It feels like a massive, massive project at that point, though, like we’d be putting an entire dependency system into a first-class programmable context. I’m still interested in what folks think about these ideas, though, event though we this may never eventuate. Does it seem to anyone else like abstracting the library and module-access capabilities of compilation so that it’s polymorphic over where it gets its data from might be useful? Is this just ridiculous? Does this step into Backpack's territory? From memory, the Haskell report doesn’t specify that modules necessarily need to be tied to the file system, but I think GHC imposes one file per module and that it be one the FS. Julian

5 4