- Haskell-Cafe - Haskell.org

2nd CfP: SLE 2025 - 18th ACM SIGPLAN International Conference on Software Language Engineering
by Andrei Chis 20 Dec '24

20 Dec '24

18th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2025) 12-13 June 2025 Koblenz, Germany https://www.sleconf.org/2025/ https://x.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 18th ACM SIGPLAN International Conference on Software Language Engineering (SLE) which is devoted to the principles of software languages: their design, their implementation, and their evolution. The SLE 2025 conference will be co-located with STAF 2025 and hosted in Koblenz, Germany, on 12-13 June 2025. --------------------------- Important Dates --------------------------- * Abstract submission: Fri 7 Feb 2025 * Paper submission: Fri 14 Feb 2025 * Authors response period: Tue 1 Apr - Sat 5 Apr 2025 * Notification: Tue 15 Apr 2025 * Conference: Thu 12 June - Fri 13 June 2025 (co-located with STAF) All dates are Anywhere on Earth. --------------------------- Topics of Interest --------------------------- SLE covers software language engineering in general, rather than engineering a specific software language. Topics of interest include, but are not limited to: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral/executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches - AI-assisted language design and optimisation * Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages - Model-based testing - AI-assisted validation * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms - AI-assisted refactoring * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability, language and software product lines * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications * Synergies between Language Engineering and emerging/promising research areas - Generative AI in language engineering (e.g., AI-based language modelling, AI-driven code generation tools) - AI and ML language engineering (e.g., ML compiler testing, code classification) - Quantum language engineering (e.g., language design for quantum machines) - Language engineering for physical systems (e.g., CPS, IoT, digital twins) - Socio-technical systems and language engineering (e.g., language evolution to adapt to social requirements) --------------------------- Types of Submissions --------------------------- SLE accepts the following types of papers: * Research papers: These are “traditional” papers detailing research contributions to SLE. Papers may range from 6 to 12 pages in length and may optionally include 2 further pages of bibliography/appendices. Papers will be reviewed with an understanding that some results do not need 12 full pages and may be fully described in fewer pages. * New ideas/vision papers: These papers may describe new, unconventional software language engineering research positions or approaches that depart from standard practice. They can describe well-defined research ideas that are at an early stage of investigation. They could also provide new evidence to challenge common wisdom, present new unifying theories about existing SLE research that provides novel insight or that can lead to the development of new technologies or approaches, or apply SLE technology to radically new application areas. New ideas/vision papers must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. * SLE Body of Knowledge: The SLE Body of Knowledge (SLEBoK) is a community-wide effort to provide a unique and comprehensive description of the concepts, best practices, tools, and methods developed by the SLE community. In this respect, the SLE conference will accept surveys, essays, open challenges, empirical observations, and case study papers on the SLE topics. These can focus on, but are not limited to, methods, techniques, best practices, and teaching approaches. Papers in this category can have up to 20 pages, including bibliography/appendices. * Tool papers: These papers focus on the tooling aspects often forgotten or neglected in research papers. A good tool paper focuses on practical insights that will likely be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. They may optionally include an appendix with a demo outline/screenshots and/or a short video/screencast illustrating the tool. Workshops: Workshops will be organised by STAF. Please inform us and contact STAF 2025 organisers if you would like to organise a workshop of interest to the SLE audience. Information on how to submit workshops can be found on the STAF 2025 Website. --------------------------- Submission --------------------------- SLE 2025 has a single submission round for papers, including a mandatory abstract registration and a rebuttal phase, where all authors of research papers will have the possibility of responding to the reviews on their submissions. Authors of accepted research papers will be invited to submit artefacts. --------------------------- Format --------------------------- Submissions have to use the ACM SIGPLAN Conference Format “acmart” ( https://sigplan.org/Resources/Author/#acmart-format) please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template, and that the document class definition is `\documentclass[sigplan,anonymous,review]{acmart}`. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colours remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. Accordingly, SLE will follow the double-blind process. Author names and institutions must be omitted from submitted papers, and references to the authors’ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. The submission website is: https://sle25.hotcrp.com --------------------------- Concurrent Submissions --------------------------- Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy ( https://www.sigplan.org/Resources/Policies/Republication/) Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism ( https://www.acm.org/publications/policies/plagiarism-overview) Submissions that violate these policies will be desk-rejected. --------------------------- Policy on Human Participant and Subject Research --------------------------- Authors conducting research involving human participants and subjects must ensure that their research complies with their local governing laws and regulations and the ACM’s general principles, as stated in the ACM’s Publications Policy on Research Involving Human Participants and Subjects ( https://www.acm.org/publications/policies/research-involving-human-particip…) If submissions are found to be violating this policy, they will be rejected. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning soundness, relevance, novelty, presentation, and replicability. New ideas/vision papers will be evaluated primarily concerning soundness, relevance, novelty, and presentation. SLEBoK papers will be reviewed on their soundness, relevance, originality, and presentation. Tool papers will be evaluated concerning relevance, presentation, and replicability. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review at the discretion of the PC chairs. For research papers, authors will get a chance to respond to the reviews before a final decision is made. --------------------------- Artefact Evaluation --------------------------- SLE will use an evaluation process to assess the quality of artefacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted research papers are invited to submit artefacts. --------------------------- Awards --------------------------- * Distinguished paper: Award for the most notable paper, as determined by the PC chairs based on the recommendations of the program committee. * Distinguished artefact: Award for the artefact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artefact evaluation committee. * Distinguished reviewer: Award for the programme committee member that produced the most useful reviews as assessed by paper authors. * Most Influential Paper: Award for the SLE 2015 paper with the greatest impact, as judged by the SLE Steering Committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. **AUTHORS TAKE NOTE**: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- Organisation --------------------------- * General chair: Görel Hedin, Lunds Universitet, Sweden * PC co-chair: Regina Hebig, Universität Rostock, Germany * PC co-chair: Vadim Zaytsev, Universiteit Twente, The Netherlands * Publicity chair: Andrei Chiş, feenk gmbh, Switzerland * Local chair: Ralf Lämmel, Universität Koblenz, Germany --------------------------- Contact --------------------------- For additional information, clarification, or answers to any questions, please get in touch with the program co-chairs (regina.hebig(a)uni-rostock.de and vadim(a)grammarware.net)

1 0

convert structures from type to value level
by Zoran Bošnjak 20 Dec '24

20 Dec '24

Dear haskell cafe, I would like to describe some structures as types (something like servant does) and I would also need to use the same structure in run-time as a value. I am trying to figure out how could I use GHC.Generics or something to do this for several user defined structures. Currently I am doing it manually (with does not work, but it might serve as intention), for example: -- generic example structure data GTest s n = GTest0 | GTest1 s | GTest2 n type TTest = GTest Symbol Nat -- type level type VTest = GTest String Integer -- value level For all my user defined structure, at the type level it will always be only (Symbol, Nat) which should translate to (Text, Int) or (String, Integer) for simplicity. -- | Convert schema from type to value class IsSchema t a where schema :: a instance KnownNat n => IsSchema n Integer where schema = natVal (Proxy @n) instance KnownSymbol s => IsSchema s String where schema = symbolVal (Proxy @s) instance IsSchema 'GTest0 VTest where schema = GTest0 instance ( IsSchema s String ) => IsSchema ('GTest1 s) VTest where schema = GTest1 (schema @s) instance ( IsSchema n Integer ) => IsSchema ('GTest2 n) VTest where schema = GTest2 (schema @n) I would like to generalize the process, by saying something like (not sure if I even need this): data Usage = TypeLevel | ValueLevel data GTest ? = Gtest0 | GTest1 ? | GTest2 ? (deriving ?) ... and be able to use the same Test structure in both cases, such as: Use it as a phantom type in some other type: data Item (t :: TTest) where Item0 :: Item 'GTest0 Item1 :: String -> Item ('GTest1 s) Item2 :: Integer -> Item ('GTest2 n) And use it as value, something like: data SomeItem = forall t a. IsSchema t a => SomeItem a (Item t) In other words... I would like to work with exact types (Item t) or generically with SomeItem, when the type is not exactly known, but the value level schema is known. I came far with manual approach, but I could not create SomeItem from the value schema. So, for example this does not compile (the error is about KnownSymbol/KnownNat): mkSomeItem :: VTest -> SomeItem mkSomeItem sch = case sch of GTest0 -> SomeItem sch Item0 GTest1 s -> SomeItem sch (Item1 (s <> s)) GTest2 n -> SomeItem sch (Item2 (succ n)) I am curious to know how to fix this problem. But the manual conversion approach is something I would like to avoid in the first place. Appreciate your help. regards, Zoran

2 1

Throwing an exception in STM without rolling back state?
by Tom Ellis 18 Dec '24

18 Dec '24

Dear Cafe, Is it possible to throw an exception in STM without rolling back state? (See program below for an demonstration that throwing an exception does roll back state.) I'm having a great deal of success using exceptions in my effect system Bluefin, to simulate early return and jumps: * https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-EarlyRetu… * https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-Jump.html I'm interested in making a Bluefin interface to STM too, but the value of that would be significantly diminished if all exceptions roll back state. Instead I would like to be able to say "throwing this exception _shouldn't_ roll back state". Is that possible? If not in practice, is it possible in theory, if I were to modify the RTS somehow? Thanks, Tom {-# LANGUAGE GHC2021 #-} import GHC.Conc import GHC.Exception data MyEx = MyEx deriving Show instance Exception MyEx -- > main -- False main = do r <- atomically $ do v <- newTVar False catchSTM @MyEx (do writeTVar v True -- same with throw MyEx` throwSTM MyEx ) (\_ -> pure ()) readTVar v print r

2 2

[TFP (and TFPiE) 2025] Call For Participation (January 13-16, Oxford, UK)
by Peter Achten 18 Dec '24

18 Dec '24

TFP 2025 -- Call For Participation (trendsfp.github.io) Venue TFPiE and TFP will take place in-person in the Wolfson Building of the Department of Computer Science at the University of Oxford. Dates Early registration: December 20, 2024 Late registration: January 6, 2025 TFPiE Workshop: Monday 13th January, 2025 TFP Symposium: Tuesday 14th - Thursday 16th January, 2025 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. Keynote speakers We are happy to have the following keynotes in the programme: * Nicolas Wu (TFPiE), Imperial College London: "Fractal Foundations and Galactic Graphs: Structure and Strategy for Expanding Minds" * Graham Nelson, University of Oxford: "Literate Programming and Cultural Practice" * Mike Sperber, Active Group: "Things We Never Told Anyone About Functional Programming" * Kathrin Stark, Heriot-Watt University: "A Verified Foreign Function Interface Between Coq and C" Programme We have 28 paper presentations. The programme schedule can be found here: trendsfp.github.io/schedule.html Excursion and banquet In the afternoon and evening of Wednesday January 15th we have an excursion to the History of Science Museum. We have a break in a cosy pub, before proceeding to Kellogg College for the conference banquet. During dinner the winners of the best paper awards of last year's TFP are announced.

1 0

Call for Participation: BOB 2025 (Berlin, Mar 14)
by Stefan Wehr 17 Dec '24

17 Dec '24

========================================================================= BOB 2025 Conference “What happens if we simply use what’s best?” March 14, 2025, Berlin https://bobkonf.de/2025/ Program: https://bobkonf.de/2025/program.html Registration: https://bobkonf.de/2025/registration.html ========================================================================= BOB conference is a place for developers, architects, and decision-makers to explore technologies beyond the mainstream in software development and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experience. The program features 16 talks and 8 tutorials on current topics: https://bobkonf.de/2025/program.html Talk subjects includes functional programming, property-based testing, language server implementation, domain-specific languages, domain-driven design, local-first software, formal methods, and microservices. BOB tutorial include sessions on frontend development, local-first programming, data science, Elixir, and software documentation, combining mob programming, TDD, and AI. Annette Bieniusa will give the keynote talk. Registration is open - many discount options are available, as are grants for members of groups underrepresented in tech. Early-bird discounts apply until Jan 17. https://bobkonf.de/2025/registration.html

1 0

GHC 9.12.1 is now available
by Zubin Duggal 16 Dec '24

16 Dec '24

The GHC developers are very pleased to announce the release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * Experimental support for the RISC-V platform with the native code generator. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the 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. [release notes]: https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e…

2 3

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