- Haskell-Cafe - Haskell.org

[ANN] Darcs 2.18.4 release
by Ben Franksen 09 Jan '25

09 Jan '25

Hello Everyone On behalf of the Darcs [1] team, I would like to announce the release of Darcs 2.18.4 [2]. See [3] for the full release notes. The main reason for this release was to make it build with stack against stackage lts-22.34 on Linux. This in turn should hopefully make it re-appear in the Debian and Ubuntu GNU/Linux distros. Cheers Ben [1] https://darcs.net [2] https://hackage.haskell.org/package/darcs-2.18.4 [3] https://hackage.haskell.org/package/darcs-2.18.4/changelog

1 1

Final call for participation: LMS/BCS-FACS Online Seminar, Annabelle McIver, 15 January 2025
by Andrei Popescu 08 Jan '25

08 Jan '25

LMS/BCS-FACS Seminar 2025 Wednesday 15 January 2025, from 19:00 (GMT) Online via Zoom https://www.lms.ac.uk/events/lms-bcs-facs-seminar-2025 In association with the British Computer Society Formal Aspects of Computing Science (BCS-FACS), the LMS hosts an annual online seminar on aspects of the computer science–mathematics interface. These events are free to anyone who wishes to attend and have attracted high-quality speakers. We are happy to have this verification talk from a wonderful speaker just one day after World Logic Day. Speaker: Annabelle McIver (Macquarie University) Probabilistic Datatypes: automating verification for abstract probabilistic reasoning Abstract: Datatypes - in which data is encapsulated together with methods that access it - play an important role in the organisation of large software projects. Correctness of datatypes has traditionally been carried out using simulation relations to simplify the verification by separating concerns: the datatype can be verified independently from the programs that use it, whilst those programs themselves can be verified using the specifications of the datatype's methods. Use of these principles enables complex programs to be brought within reach of automated proof. When probabilistic choice is included, however, it turns out that obtaining similar simplifications of the verification problem will require distinguishing between "hidden" and "observable" probabilistic behaviour - if demonic choice is allowed in the surrounding program. And that is not required in the non-probabilistic setting: the crucial issue is the potential interaction of probabilistic- and demonic choice. In the main part of this talk I will use examples to explain why the interaction is problematic, and I will suggest how extension of existing pGCL-based automated reasoning-tools, will by taking that interaction into account, enable automated probabilistic abstract reasoning about "hard to crack" probabilistic programs. Registration: To attend remotely via Zoom, please complete the registration form here: https://www.lms.ac.uk/civicrm/event/info?reset=1&id=139 You will receive the link to the meeting upon registration, as well as an automated reminder email sent 24 hours before the event is scheduled to start. For all queries regarding the seminar, please contact lmscomputerscience(a)lms.ac.uk.

1 0

Rebuilding package on hackage to generate documentation
by Ivan Perez 08 Jan '25

08 Jan '25

Hi, I'm trying to trigger a re-build of Yampa on hackage so that the documentation will be generated. I'm being met with the following message: Report not found Build report does not exist Am I doing something wrong? Thanks Ivan

1 0

[ANN] Copilot 4.2
by Ivan Perez 07 Jan '25

07 Jan '25

Hi everyone!! We are really excited to announce Copilot 4.2 [1,2]. Copilot is a stream-based EDSL in Haskell for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Compilation to Bluespec, to target FPGAs, is also supported. Copilot is NASA Class D open-source software, and is being used at NASA in drone test flights. Through the NASA tool Ogma [3] (also written in Haskell), Copilot also serves as a runtime monitoring backend for NASA's Core Flight System, Robot Operating System (ROS2), FPrime (the software framework used in the Mars Helicopter). This release introduces several big improvements to Copilot: - Specifications can now use the same handler for multiple monitors, provided that the arguments to those handlers always have consistent types and arity. This simplifies the code that uses Copilot, since it's no longer necessary to create multiple boilerplate wrappers around the same handling routines. - The use of structs has been vastly simplified. Before, it was necessary to define class instances for structs, whose implementations were, although repetitive, not intuitive especially for users unfamiliar with Haskell. In Copilot 4.2, it is now possible to define those methods automatically by relying on default method implementations that work well for most cases, although users retain the ability to customize those methods if desired. - We have increased test coverage in `copilot-core`, reaching full coverage of all elements of the public interface that are not automatically generated by GHC. The interface of `copilot-core` has also been simplified, deprecating record fields of an existential type UExpr, which were largely unused outside of Copilot's internals. The new implementation is compatible with versions of GHC from 8.6 to 9.10, as well as Stackage Nightly. This release has been made possible thanks to key submissions from Frank Dedden, Ryan Scott, and Kyle Beech, the last of which is also a first-time contributor to the project. We are grateful to them for their timely contributions, especially during the holidays, and for making Copilot better every day. We also want to thank the attendees of Zurihac 2024 for technical discussions that helped find the right solutions to some of the problems addressed by this release. For details on this release, see [1]. https://github.com/Copilot-Language/copilot/releases/tag/v4.2. As always, we're releasing exactly 2 months since the last release. Our next release is scheduled for Mar 7th, 2025. We want to remind the community that Copilot is now accepting code contributions from external participants again. Please see the discussions and the issues in our github repo [4] to learn how to participate. Current emphasis is on improving the codebase in terms of performance, stability and test coverage, removing unnecessary dependencies, hiding internal definitions, formatting the code to meet our new coding standards, and simplifying the Copilot interface. Users are encouraged to participate by opening issues, asking questions, extending the implementation, and sending bug fixes. Happy Haskelling! Ivan -- [1] https://github.com/Copilot-Language/copilot/releases/tag/v4.2 [2] https://hackage.haskell.org/package/copilot [3] https://github.com/nasa/ogma [4] https://github.com/Copilot-Language/copilot

1 0

POPL 2025 Call for Participation (January 19-25, Denver, Colorado)
by Ningning Xie 07 Jan '25

07 Jan '25

The 52nd ACM SIGPLAN Symposium on Principles of Programming Languages (POPL 2025) will take place in January in Denver, Colorado, the United States. It's going to be an amazing conference - don't miss it - sign up now! https://popl25.sigplan.org/attending/registration Location: Curtis Hotel Denver, 1405 Curtis Street, 80202, Denver, Colorado, United States Dates: - Main conference: Wed 22 - Fri 24 January - Workshops, tutorials, co-located events: Sun 19, Mon 20, Tue 21 and Sat 25 January Accepted papers: https://popl25.sigplan.org/track/POPL-2025-popl-research-papers Full details of the conference and co-located events: https://popl25.sigplan.org/ Sponsors: POPL is supported by generous sponsorship from: - Amazon - Jane Street - Google DeepMind - JetBrains - Microsoft - Epic - Google - Ahrefs

1 0

CGO'25 - early bird registration and student research competition
by Luisa Cicolini 07 Jan '25

07 Jan '25

Dear all, Registrations for the International Symposium on Code Generation and Optimization (CGO) 2025<https://2025.cgo.org/>, taking place in Las Vegas<https://2025.cgo.org/attending/Venue>, from 1st-5th March are now open. The International Symposium on Code Generation and Optimization (CGO) is a premier venue bringing together researchers and practitioners working at the interface of hardware and software on a wide range of optimization and code generation techniques and related issues. The conference spans from purely static to fully dynamic approaches, from pure software-based methods to specific architectural features and support for code generation and optimization. Early registration<https://2025.cgo.org/attending/registration> deadline is on 31st January! We are also hosting a Student Research Competition (SRC)<https://2025.cgo.org/track/cgo-2025-student-research-competition>: a unique opportunity for undergraduate and graduate students to present their original research before a panel of judges and attendees at CGO'25. The winner will be awarded and invited to the 2025 ACM SRC competition. If you know any undergraduate or postgraduate students doing research in compiler-related topics, please invite them to apply - we are excited to welcome young researchers to the community! Best, Luisa Cicolini

1 0

Re: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions
by Ryan Scott 29 Dec '24

29 Dec '24

Hi Ivan, Short answer: I'm not aware of a way to automate the process of excluding certain definitions from cabal-generated HPC coverage reports. Long answer: there is a way to manually modify HPC coverage reports using the hpc overlay command. Sadly, most the existing documentation on this command [1] is pretty sparse, so the only way I was able to discover this was by reading the original HPC paper [2] (in that paper, `hpc overlay` is called `hpc-makemtix`) and by finding an example of how to use `hpc overlay` in GHC's test suite [3]. To translate that example into prose: suppose you have the following program (hpc001.hs): main = print (const "Hello" "World") Here, the expression "World" is never evaluated, so by default HPC will claim that there is no coverage for it. This is pretty silly, however, so we'd like to instruct HPC not to warn about "World". To do so, first compile the example above with coverage enabled and run it: $ ghc -fhpc hpc001.hs $ ./hpc001 This should generate an hpc001.tix file. If you run `hpc markup hpc001.tix` and look at the resulting HTML report, you'll see that it warns about "World". Let's fix that. To do so, we have to define an HPC overlay file. The example given in GHC's test suite (sample_overlay.ovr) is: module "Main" { inside "main" { tick "\"World\"" on line 1; } } While I can't find a reference for the syntax that HPC overlay files use, this particular example is pretty self-explanatory: don't report about the expression "World" on line 1, which is found inside the `main` function in the `Main` module. In order to make use of this overlay file, we first have to convert it to a .tix file: $ hpc overlay sample_overlay.ovr > sample_overlay1.tix Then we have to combine it with our original .tix file: $ hpc combine hpc_sample.tix sample_overlay1.tix > total1.tix If we run `hpc markup total1.txt`, we now see that HPC no longer warns about "World", just as we'd hoped for. That is where my understanding of this feature ends, however. In particular, I'm not aware of a better way to generate overlay files (other than to write them by hand, which still feels somewhat laborious), and I'm not aware of any deeper integration with cabal so that these overlay files would be picked up and automatically applied (e.g., for reporting coverage on Hackage). Given that the HPC documentation for `hpc overlay` [1] labels this as an experimental feature, I'd be surprised if such tooling or integration existed. I agree that it would be cool if did, however. Best, Ryan ----- [1] https://hpc-bin.readthedocs.io/en/latest/hpc.html#hpc-overlay-and-hpc-draft [2] https://dl.acm.org/doi/abs/10.1145/1291201.1291203 [3] https://gitlab.haskell.org/ghc/ghc/-/blob/e39c8c993c1da534c5893ca418d1fa4cb…

5 8

[ghc-proposals] Allow reserved identifiers as fields ...
by Anthony Clayden 26 Dec '24

26 Dec '24

And Merry Christmas to all. I counsel against allowing reserved ids to be anything other than reserved ids. "... is fraught with peril, unduly complicates the parser, and harms readability. " says a language implementer I asked. But wanting to use field names dictated outside this language's control is a realistic requirement, for which there are several general approaches. The ghc proposal as it stands seems ad-hoc and very specific to one user organisation. Furthermore, this just ain't true: > ... SQL schemas. anyone working with those is stuck deciding between special-casing its naming, and consistently naming *everything* weirdly, ... SQL consistently supports things like embedded spaces, fields starting upper-case [**], embedded dots or other graphics -- by no means just names that clash with reserved ids. How does it do that? And this answer seems particularly relevant when these ids are going to feed into `HasField` constraints as a type-level String: put the id between quotes. > orgNotification."type" doesn't look too ugly to my eye. And to spj's repeated point: I could envisage allowing fields in `data` decls and record syntax to be quoted. (Again you couldn't use punning nor field-name as function.) The approach is sufficiently general it could be extended to `#"Label naming"`. [**] I'm particularly keen on field names starting upper case, because they're injective/part of the structure, like data constructors. AntC (Why am I posting to the cafe, not github? I seem to be blocked from posting on any topic, either on github or gitlab -- even for pages where I'm the sole author. I'd be grateful if somebody could post the above to the PR.)

5 7

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