- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Representing a type system in Haskell
by Olaf Klinke 11 Jul '23

11 Jul '23

> So this type system was designed such that I could: > Get a value of a type -> Convert it to lua types -> call lua code > with it -> Convert into my type system -> Type check the result I think you're describing a functor here, at least a commutative square. You're looking at a subset of Haskell, described by the types of your scripting language, whose functions can be mapped to another language (lua in your case). Personally, I would try to avoid defining, parsing and type-checking an entirely new language if there is a chance of embedding it into Haskell. Especially when it must be quite feature-rich as for writing games. Perhaps a quasi-quoter is sufficient? Also have a look at 'zoom' and 'focus' from the lens package. They let you write state transformers that care only about a subset of your huge game state, where the subset is described by a lens. Olaf

1 0

Second Call for Papers: JFP Special Issue on Program Calculation (papers due 1st Dec)
by Graham Hutton 11 Jul '23

11 Jul '23

================================================================== JFP Special Issue on Program Calculation https://tinyurl.com/prog-calc We invite submissions to the Journal of Functional Programming Special Issue on Program Calculation. Notification of intent : 20 October 2023 Submission deadline : 1 December 2023 SCOPE The idea of program calculation, in which programs are derived from specifications using equational reasoning techniques, has been a topic of interest in functional programming since its earliest days. In particular, the approach allows us to systematically discover how programs can be defined, while at the same time obtaining proofs that they are correct. The aim of this special issue is to document advances that have been made in the field of program calculation in recent years. TOPICS Full-length, archival-quality submissions are solicited on all aspects of program calculation and related topics. Specific topics of interest include but are not limited to: - Program derivation and transformation; - Inductive and co-inductive methods; - Recursion and co-recursion schemes; - Categorical and graphical methods; - Tool support and proof assistants; - Efficiency and resource usage; - Functional algorithm design; - Calculation case studies. The special issue will also consider papers on program calculation that are not traditional research papers. This may include pearls, surveys, tutorials or educational papers, which will be judged by the usual JFP standards for such submissions. Papers will be reviewed as regular JFP submissions, and acceptance in the special issue will be based on both JFP's quality standards and relevance to the theme. NOTIFICATION OF INTENT Authors must notify the special issue editors of their intent to submit by 20 October 2023. The notification of intent should be submitted by filling out the following form, which asks for data to help identify suitable reviewers: tinyurl.com/intent-to-submit If you miss the notification of intent deadline, but still wish to submit, please contact the special-issue editors. SUBMISSIONS Papers must be submitted by 1 December 2023. Submissions should be typeset in LaTeX using the JFP style file, and submitted through the JFP Manuscript Central system. Choose "Program Calculation" as the paper type, so it gets assigned to the special issue. Further author instructions are available from: tinyurl.com/JFP-instructions We welcome extended versions of conference or workshop papers. Such submissions must clearly describe the relationship with the initial publication, and must differ sufficiently that the author can assign copyright to Cambridge University Press. Prospective authors are welcome to discuss submissions with the editors to ensure compliance. SPECIAL-ISSUE EDITORS Graham Hutton <graham.hutton(a)nottingham.ac.uk> Nicolas Wu <n.wu(a)imperial.ac.uk> IMPORTANT DATES We anticipate the following schedule: 20 October 2023 : Notification-of-intent deadline 1 December 2023 : Submission deadline 22 March 2024 : First round of reviews 12 July 2024 : Revision deadline 4 October 2024 : Second round of reviews, if applicable 29 November 2024 : Final versions due ================================================================== 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

Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension)
by Ryan Scott 10 Jul '23

10 Jul '23

TL;DR: The submission deadline for the 2023 Haskell Implementors' Workshop has been extended to June 16. ================================== ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ Important dates --------------- Deadline: July 16, 2023 (AoE) (extended) Notification: August 4, 2023 Workshop: September 4, 2023 The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. 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 to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and short lightning talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2023. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides, and presented data available with the consent of the speakers. 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 are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially 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 Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw23.hotcrp.com until July 16 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should be ~7mins 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. Program Committee ----------------- * Gergő Érdi (Standard Chartered Bank) * Sebastian Graf (Karlsruhe Institute of Technology) * Wen Kokke (University of Strathclyde) * Ryan Scott (Galois, Inc.) * Rebecca Skinner (Mercury) * Li-yao Xia (University of Edinburgh) Contact ------- * Ryan Scott <ryan.gl.scott at gmail.com>

1 1

Representing a type system in Haskell
by Talha Qamar 10 Jul '23

10 Jul '23

Hello everyone, I'm working on a game engine in Haskell. The thing is, while I want to write the architecture in Haskell, I'm thinking of using something else as the actual scripting language. Long story short, how would I represent a type system in Haskell? I've gotten _something_ together that works a bit like this: ``` data Type = -- ...all possible types data Value = -- ...all possible types again data TypedValue = TypedValye Type Value ``` But I'm concerned if this is the ideal way of doing things, particularly when I get to complex types like structs or tagged unions. Any help would be appreciated. Sent from Proton Mail mobile

2 2

Re: [Haskell-cafe] Representing a type system in Haskell
by Talha Qamar 10 Jul '23

10 Jul '23

This looks perfect! I think I'll spend a couple days looking this over and grokking it. Thanks for your time. Sent from Proton Mail mobile -------- Original Message -------- On Jul 10, 2023, 6:56 PM, Brandon Allbery wrote: > You might look at https://web.cecs.pdx.edu/~mpj/thih/thih.pdf which shows how to implement Haskell's own type system (minus various GHC extensions) in Haskell, and adapt to whatever language you're implementing. On Mon, Jul 10, 2023 at 8:36 AM Talha Qamar via Haskell-Cafe wrote: > > > Hello everyone, I'm working on a game engine in Haskell. The thing is, while I want to write the architecture in Haskell, I'm thinking of using something else as the actual scripting language. > > Long story short, how would I represent a type system in Haskell? I've gotten _something_ together that works a bit like this: > > ``` > data Type = -- ...all possible types > data Value = -- ...all possible types again > data TypedValue = TypedValye Type Value > ``` > But I'm concerned if this is the ideal way of doing things, particularly when I get to complex types like structs or tagged unions. > > Any help would be appreciated. > > Sent from Proton Mail mobile > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b(a)gmail.com

1 0

servant streaming question
by Zoran Bošnjak 10 Jul '23

10 Jul '23

Hi all, I would like to reuse some streaming functions from the turtle package in the context of the servant streaming handler. Relevant references: https://hackage.haskell.org/package/turtle-1.6.1/docs/Turtle-Shell.html https://hackage.haskell.org/package/turtle-1.6.1/docs/Turtle-Prelude.html https://hackage.haskell.org/package/servant-0.20/docs/Servant-Types-SourceT… As a simple example: Turtle.Prelude.ls function represents stream of FilePaths (directory listing of some path) ls :: FilePath -> Shell FilePath Servant streaming is based around SourceT IO a, for example: type ListFiles = "ls" :> StreamGet NewlineFraming PlainText (SourceT IO FilePath) The problem is that the streaming (Shell a) is not exactly the same as servant's (SourceT IO a). But as far as I understand, they both represent "stream of values of type 'a'". My question is: Is a generic conversion function possible? Something like: shellToSource :: forall a. Shell a -> SourceIO a shellToSource = ?? ... such that I could reuse the 'ls' and write a streaming servant handler like this: listFilesHandler :: Handler (SourceIO FilePath) listFilesHandler = pure $ shellToSource $ Turtle.Prelude.ls "somePath" Appreciate any suggestion. regards, Zoran

3 3

[ANN] Copilot 3.16
by Ivan Perez 08 Jul '23

08 Jul '23

Hi everyone, We are very excited to announce Copilot 3.16 [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. Copilot has been used at NASA in drone test flights. Through the NASA tool Ogma [1] (also written in Haskell), Copilot also serves as a runtime monitoring backend for NASA's Core Flight System, Robot Operating System (ROS2), and FPrime (the software framework used in the Mars Helicopter) applications. This new version provides comprehensive tests for the C99 backend, and introduces a breaking change in the definition of the type `Arg` in copilot-language. For details, see [2]. The new version is already available on Hackage [4]. As always, we're releasing exactly 2 months since the last release. Our next release is scheduled for Sep 7th, 2023. We are also extremely excited to announce that Copilot has received full approval for release as NASA Class D open-source software. Current emphasis is on increasing test coverage for the two remaining libraries without tests (copilot-language and copilot-theorem), removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Users are encouraged to participate by opening issues and asking questions via our github repo [3]. There have been many updates on the Copilot front in the last few months. We'll be able to announce more soon. Stay tuned. Happy Haskelling! Ivan [1] https://github.com/nasa/ogma [2] https://github.com/Copilot-Language/copilot/releases/tag/v3.16 [3] https://github.com/Copilot-Language/copilot [4] https://hackage.haskell.org/package/copilot

1 0

PhD position at KU Leuven
by Tom Schrijvers 06 Jul '23

06 Jul '23

Dear Haskell Cafe, I have a PhD position available for a candidate with a master degree in computer science, mathematics or similar and a passion for Haskell, functional programming and programming language theory. For more information and applications, see: https://www.kuleuven.be/personeel/jobsite/jobs/60229600?hl=en&lang=en -- prof. dr. ir. Tom Schrijvers Research Professor KU Leuven Department of Computer Science Celestijnenlaan 200A 3001 Leuven Belgium Phone: +32 16 327 830 http://people.cs.kuleuven.be/~tom.schrijvers/

1 0

Final Call for Talks: Haskell Implementors' Workshop 2023
by Ryan Scott 01 Jul '23

01 Jul '23

The 2023 Haskell Implementors' Workshop deadline is just under one month away. We are looking forward to your talk submissions. Best, Ryan ================================== ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ Important dates --------------- Deadline: July 4, 2023 (AoE) Notification: August 4, 2023 Workshop: September 4, 2023 The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. 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 to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and short lightning talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2023. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides, and presented data available with the consent of the speakers. 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 are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially 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 Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com until July 4 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should be ~7mins 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. Program Committee ----------------- * Gergő Érdi (Standard Chartered Bank) * Sebastian Graf (Karlsruhe Institute of Technology) * Wen Kokke (University of Strathclyde) * Ryan Scott (Galois, Inc.) * Rebecca Skinner (Mercury) * Li-yao Xia (University of Edinburgh) Contact ------- * Ryan Scott <ryan.gl.scott at gmail.com>

1 1

Re: [Haskell-cafe] type error when specializing lens zooms in ghc >= 9.0
by Olaf Klinke 27 Jun '23

27 Jun '23

> Hm, yikes, I tend to agree this is a very general error message. Here > are > all the places "83865" shows up in the code base: > > > https://gitlab.haskell.org/search?search=83865&project_id=1&group_id=2&sear… > > I opened https://gitlab.haskell.org/ghc/ghc/-/issues/23466 to follow > up. > Feel free to weigh in. (Contact me if you need an account - spam > measures > currently include manual approvals for new accounts.) > Thanks, Bryan. This made me wonder what the current system behind assignment of error codes is. I'd expect five-digit error codes to be *more* specific than the general shape of error message emitted by ghc, but here it is evidently less specific. 82865 stands for the error message constructor TypeEqMismatch [1] which is a record [2] with many fields. In particular, the teq_mismatch_expected and teq_mismatch_actual fields hold structural information: a ForAllTy [3] may hint at simplified subsumption. Thus my proposal would be that error codes are composite values, with one part (as currently implemented) in bijection to the error message constructor and another part determined by a function of the actual error value. This function has to be chosen to provide sufficient abstraction from the actual situation but e.g. differentiate between constructors of the Type type. For example, why don't the cases differentiated by the pretty-printer [4] not own their own error codes? Olaf [1] https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error/C… [2] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.… [3] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.ht… [4] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.ht…

2 1