From ryan.gl.scott at gmail.com Sat Jul 1 21:29:57 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 1 Jul 2023 17:29:57 -0400 Subject: [Haskell-cafe] Final Call for Talks: Haskell Implementors' Workshop 2023 In-Reply-To: References: Message-ID: One correction to the previous email: the link should be https://icfp-hiw2023.hotcrp.com (with a hyphen), not https://icfphiw23.hotcrp.com. (The former matches what is listed on the HIW website at https://icfp23.sigplan.org/home/hiw-2023.) I apologise for any confusion this may have caused. Best, Ryan On Mon, Jun 5, 2023 at 7:47 AM Ryan Scott wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.schrijvers at kuleuven.be Thu Jul 6 08:20:41 2023 From: tom.schrijvers at kuleuven.be (Tom Schrijvers) Date: Thu, 6 Jul 2023 08:20:41 +0000 Subject: [Haskell-cafe] PhD position at KU Leuven Message-ID: <29CFAE95-DAAE-4AC2-8A79-73FF830E3C52@kuleuven.be> 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/ From ivanperezdominguez at gmail.com Sat Jul 8 20:00:47 2023 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 8 Jul 2023 13:00:47 -0700 Subject: [Haskell-cafe] [ANN] Copilot 3.16 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Jul 10 07:19:44 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 10 Jul 2023 10:19:44 +0300 Subject: [Haskell-cafe] servant streaming question In-Reply-To: <1583064132.3146.1688148003211.JavaMail.zimbra@via.si> References: <1583064132.3146.1688148003211.JavaMail.zimbra@via.si> Message-ID: In short, yes I think it should be possible. But messing with Shell / Fold always feels like doing a brain teaser rather than programming. If you figure it out, I would like to hear about it. :P On Fri, 30 Jun 2023 at 21:00, Zoran Bošnjak wrote: > 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.html > > 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 > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoran.bosnjak at via.si Mon Jul 10 12:03:37 2023 From: zoran.bosnjak at via.si (Zoran =?utf-8?Q?Bo=C5=A1njak?=) Date: Mon, 10 Jul 2023 12:03:37 +0000 (UTC) Subject: [Haskell-cafe] servant streaming question In-Reply-To: References: <1583064132.3146.1688148003211.JavaMail.zimbra@via.si> Message-ID: <1313083111.5198.1688990617374.JavaMail.zimbra@via.si> I have managed to convert in one direction like this: ``` sourceToShell :: forall a. SourceIO a -> Shell a sourceToShell (S.SourceT act1) = Shell act2 where act2 :: FoldShell a r -> IO r act2 (FoldShell step begin done) = act1 (go begin) where go x = \case S.Stop -> done x S.Error e -> fail e S.Skip cont -> go x cont S.Yield val cont -> step x val >>= flip go cont S.Effect eff -> eff >>= go x ``` But in the other way (that is: shellToSource) I could not find any clean solution. I've got information from turtle's author that it's not possible directly by simple manupulation of data structures. It should however be possible by forking a new thread, write elements from Shell to some shared buffer and let StepT read from this buffer. But I have decided to re-implement some small set of turtle's functions (like 'ls') to produce SourceIO, instead of Shell, so this conversion is not needed any more. Zoran From: "Bryan Richter" To: "Zoran Bošnjak" Cc: "haskell-cafe" Sent: Monday, July 10, 2023 9:19:44 AM Subject: Re: [Haskell-cafe] servant streaming question In short, yes I think it should be possible. But messing with Shell / Fold always feels like doing a brain teaser rather than programming. If you figure it out, I would like to hear about it. :P On Fri, 30 Jun 2023 at 21:00, Zoran Bošnjak < [ mailto:zoran.bosnjak at via.si | zoran.bosnjak at via.si ] > wrote: 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-Shell.html ] [ https://hackage.haskell.org/package/turtle-1.6.1/docs/Turtle-Prelude.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.html | https://hackage.haskell.org/package/servant-0.20/docs/Servant-Types-SourceT.html ] As a simple example: [ http://turtle.prelude.ls/ | 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 $ [ http://turtle.prelude.ls/ | Turtle.Prelude.ls ] "somePath" Appreciate any suggestion. regards, Zoran _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: [ http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ] Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From qamartalha at proton.me Mon Jul 10 12:35:39 2023 From: qamartalha at proton.me (Talha Qamar) Date: Mon, 10 Jul 2023 12:35:39 +0000 Subject: [Haskell-cafe] Representing a type system in Haskell Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Mon Jul 10 13:26:51 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 10 Jul 2023 09:26:51 -0400 Subject: [Haskell-cafe] servant streaming question In-Reply-To: <1313083111.5198.1688990617374.JavaMail.zimbra@via.si> References: <1583064132.3146.1688148003211.JavaMail.zimbra@via.si> <1313083111.5198.1688990617374.JavaMail.zimbra@via.si> Message-ID: On Mon, Jul 10, 2023 at 12:03:37PM +0000, Zoran Bošnjak wrote: > It should however be possible by forking a new thread, write elements > from Shell to some shared buffer and let StepT read from this buffer. Rather than a "shared buffer", it shouldn't be too difficult with a BoundedChan. https://hackage.haskell.org/package/BoundedChan-1.0.3.0 just write to the BoundedChan on the "Shell" side, and read from it on the "SourceT" (StepT) side. -- Viktor. From qamartalha at proton.me Mon Jul 10 14:00:06 2023 From: qamartalha at proton.me (Talha Qamar) Date: Mon, 10 Jul 2023 14:00:06 +0000 Subject: [Haskell-cafe] Representing a type system in Haskell In-Reply-To: References: Message-ID: 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 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at gmail.com Mon Jul 10 14:01:26 2023 From: byorgey at gmail.com (Brent Yorgey) Date: Mon, 10 Jul 2023 09:01:26 -0500 Subject: [Haskell-cafe] Representing a type system in Haskell In-Reply-To: References: Message-ID: So to make sure I'm understanding correctly, you want to create your own statically typed scripting language for your game engine? Implementing your own statically-typed language is definitely a fun and worthwhile learning experience. You might find helpful the notes from my programming languages course, which is taught in Haskell: https://hendrix-cs.github.io/csci360/ Having `Type` and `Value` ADTs to represent types and values makes sense. They often do correspond closely since there is often a canonical kind of value for each type, but they are not necessarily exactly the same. You didn't mention an ADT for expressions/terms, i.e. syntax. Typically you will parse concrete syntax to produce a Term, and then you will typecheck a Term to make sure it has a valid Type. Then you can interpret the Term to produce a Value. I am not sure what the point of TypedValue is. Typically, once you are finished with typechecking, you no longer need to keep track of types while interpreting. -Brent On Mon, Jul 10, 2023 at 7:36 AM Talha Qamar via Haskell-Cafe < haskell-cafe at haskell.org> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From qamartalha at proton.me Mon Jul 10 14:33:39 2023 From: qamartalha at proton.me (Talha Qamar) Date: Mon, 10 Jul 2023 14:33:39 +0000 Subject: [Haskell-cafe] Representing a type system in Haskell In-Reply-To: References: Message-ID: <05eQr5wCR9u7yKNPxaIOqSl_s4tad6TAdpLHJQWedVuuVtt8S9dHZFWHBHYgvXrtmVzN-XDXAznaIpAkqsd2SyR4Zk-Uz9YkdoUbmH0wgr4=@proton.me> I feel like I should elaborate on my usecase a little bit more. The arcitecture of my game engine is that there's a hypothetical giant struct that contains all of your game data, and then there's a giant pure function that takes an input state and the previous game state, and gives you the game state for the new frame. The problem is that writing a big function like that is a bit unwieldly, so I had the idea of separating each part out into a tiny script containing a pure function. My initial idea was that if I could strip out the io and os modules from the environment, each lua module (file) would be considered pure as a whole. 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 don't know if I needed the TypedValue; but I felt it was convenient for a value to carry around it's type for some reason, my (in foresight flawed) vision was that lua code would call into haskell code, and I would keep on type checking in the interim, but I now realize that I don't need to do that if I'm checking at the end anyways. Now that you mention it, implementing my own statically typed language would probably be better than trying to rig a strict type system on a traditionally dynamically typed language. I have to think about this for a little bit. Thank you for the notes, I'll be looking them over. -------- Original Message -------- On Jul 10, 2023, 7:01 PM, Brent Yorgey wrote: > So to make sure I'm understanding correctly, you want to create your own statically typed scripting language for your game engine? Implementing your own statically-typed language is definitely a fun and worthwhile learning experience. You might find helpful the notes from my programming languages course, which is taught in Haskell: https://hendrix-cs.github.io/csci360/ > > Having `Type` and `Value` ADTs to represent types and values makes sense. They often do correspond closely since there is often a canonical kind of value for each type, but they are not necessarily exactly the same. > > You didn't mention an ADT for expressions/terms, i.e. syntax. Typically you will parse concrete syntax to produce a Term, and then you will typecheck a Term to make sure it has a valid Type. Then you can interpret the Term to produce a Value. > > I am not sure what the point of TypedValue is. Typically, once you are finished with typechecking, you no longer need to keep track of types while interpreting. > > -Brent > > On Mon, Jul 10, 2023 at 7: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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Mon Jul 10 22:34:53 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 10 Jul 2023 18:34:53 -0400 Subject: [Haskell-cafe] Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension) Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Mon Jul 10 22:40:16 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 10 Jul 2023 18:40:16 -0400 Subject: [Haskell-cafe] Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension) In-Reply-To: References: Message-ID: Apologies, that should read *July* 16, not June 16, for the submission deadline at the top of the email. (The body of the email contains the correct date.) Best, Ryan On Mon, Jul 10, 2023 at 6:34 PM Ryan Scott wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Tue Jul 11 08:29:55 2023 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 11 Jul 2023 08:29:55 +0000 Subject: [Haskell-cafe] Second Call for Papers: JFP Special Issue on Program Calculation (papers due 1st Dec) Message-ID: ================================================================== 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 Nicolas Wu 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. From olf at aatal-apotheke.de Tue Jul 11 15:51:58 2023 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 11 Jul 2023 17:51:58 +0200 Subject: [Haskell-cafe] Representing a type system in Haskell Message-ID: <946f86e5b9e29012295303cba0e72d2caacecc33.camel@aatal-apotheke.de> > 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 From P.Achten at cs.ru.nl Wed Jul 12 15:11:19 2023 From: P.Achten at cs.ru.nl (Peter Achten) Date: Wed, 12 Jul 2023 17:11:19 +0200 Subject: [Haskell-cafe] [TFP 2024 Call for Papers] 25th International Symposium on Trends in Functional Programming Message-ID: <80bf9fa3-9929-555c-a7c8-6e0af40d4d3e@cs.ru.nl> # TFP 2024 -- Call for Papers (trendsfp.github.io) ## Important Dates Submission deadline: pre-symposium, full papers,  Saturday 4 November, 2023 Submission deadline: pre-symposium, draft papers, Wednesday 30 November, 2023 Notification:        pre-symposium submissions,   Friday 8 December, 2023 TFPIE Workshop:                                   Tuesday 9 January, 2024 TFP Symposium:                                    Wednesday 10 - Friday 12 January, 2024 Submission deadline: post-symposium review,       Friday 23 February, 2024 Notification:        post-symposium submissions,  Friday 5 April, 2024 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. This year, TFP will take place in-person at Seton Hall University, in South Orange, NJ in the United States. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. Please be aware that TFP has several submission deadlines. The first, November 4, is for authors that wish to have their full paper reviewed prior to the symposium. Papers that are accepted in this way must also be presented at the symposium. The second, November 30, is for authors that wish to present their work or work-in progress at the symposium first without submitting to the full review process for publication. These authors can then take into account feedback received at the symposium and submit a full article for review by the third deadline, February 23. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles:   Leading-edge, previously unpublished research work * Position Articles:   On what new trends should or should not be * Project Articles:   Descriptions of recently started new projects * Evaluation Articles:   What lessons can be drawn from a finished project * Overview Articles:   Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas:   security, mobility, telecommunications applications, embedded   systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2024 program chair, Jason Hemann. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, each year TFP also awards a prize for the best student paper. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are the paper’s first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Authors must submit papers to:   Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS Guidelines web site: ## Organizing Committee Jason Hemann      PC Chair            Seton Hall University, USA Stephen Chang     Symposium Chair     University of Massachusetts Boston, USA Shajina Anand     Local Arrangements  Seton Hall University, South Orange, USA From twilson at csufresno.edu Wed Jul 12 22:06:34 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 12 Jul 2023 15:06:34 -0700 Subject: [Haskell-cafe] Musings on lists Message-ID: Deaf Cafe, I'm an educator using Haskell, and I've been telling my students certain stories about Haskell evaluation that I'm now starting to question, so I'm writing for some clarification. I've written before about similar things (e.g., "Basic list exercise" from Mar 16), so it seems my own education on this topic is not yet complete! My apologies if this is too trivial for the Cafe. One story I tell students is that list concatenation, xs ++ ys, ends up "copying" the elements of xs but not the elements of ys, and in particular an expression like xs ++ [a], putting a new element at the end of a list, is particularly expensive, at least compared to x : xs, putting one at the beginning, which seems obvious, right? But here is my question: isn't xs ++ ys just a thunk that, as elements are "requested" from it, produces them first from xs and then, when those run out, defers entirely to ys from that point on? If so, then the elements of xs aren't "copied" any more than the elements of ys are; they are just produced from different places. Even the expression xs ++ [a] isn't problematic in this light: just act like xs, but with one more "card up the sleeve" when you are done. Have I gotten that right? Second, if the above is correct, then if there is a nesting, (xs ++ ys) ++ zs, and we want an element from it, there will be two steps before we can get that element from xs. And this will continue until xs is exhausted, at which point we get new elements in one step from ys, and finally in zero steps from zs. But ++ is associative, and so this list is also xs ++ (ys ++ zs), which requires less work getting the elements from xs. Is this kind of optimization something that is or can be done (automatically)? Thanks for your indulgence, Todd Wilson -------------- next part -------------- An HTML attachment was scrubbed... URL: From migmit at gmail.com Wed Jul 12 22:51:06 2023 From: migmit at gmail.com (MigMit) Date: Thu, 13 Jul 2023 00:51:06 +0200 Subject: [Haskell-cafe] Musings on lists In-Reply-To: References: Message-ID: xs ++ ys is just a thunk, but only the first time you "request" it. Afterwards it is a real list. More correctly, due to the lazy nature of Haskell, it's actually part list, part "thunk". Basically, if you do [1,2,3] ++ [4,5,6], and then "request" some elements from it, it's going to be like this: thunk (++) {arguments: 1:2:3:[] and 4:5:6:[]} | | Requesting first element v 1 : thunk (++) {arguments: 2:3:[] and 4:5:6:[]} | | Requesting second element v 1 : 2 : thunk (++) {arguments: 3:[] and 4:5:6:[]} | | Requesting first element again v 1 : 2 : thunk (++) {arguments: 3:[] and 4:5:6:[]} -- no change | | Requesting fifth element v 1 : 2 : 3 : 4 : 5: 6 : [] -- at this point those "4:5:6:[]" are exactly the same as "4:5:6:[]" from the second argument. > On 13 Jul 2023, at 00:06, Todd Wilson wrote: > > Deaf Cafe, > > I'm an educator using Haskell, and I've been telling my students certain stories about Haskell evaluation that I'm now starting to question, so I'm writing for some clarification. I've written before about similar things (e.g., "Basic list exercise" from Mar 16), so it seems my own education on this topic is not yet complete! My apologies if this is too trivial for the Cafe. > > One story I tell students is that list concatenation, xs ++ ys, ends up "copying" the elements of xs but not the elements of ys, and in particular an expression like xs ++ [a], putting a new element at the end of a list, is particularly expensive, at least compared to x : xs, putting one at the beginning, which seems obvious, right? > > But here is my question: isn't xs ++ ys just a thunk that, as elements are "requested" from it, produces them first from xs and then, when those run out, defers entirely to ys from that point on? If so, then the elements of xs aren't "copied" any more than the elements of ys are; they are just produced from different places. Even the expression xs ++ [a] isn't problematic in this light: just act like xs, but with one more "card up the sleeve" when you are done. Have I gotten that right? > > Second, if the above is correct, then if there is a nesting, (xs ++ ys) ++ zs, and we want an element from it, there will be two steps before we can get that element from xs. And this will continue until xs is exhausted, at which point we get new elements in one step from ys, and finally in zero steps from zs. But ++ is associative, and so this list is also xs ++ (ys ++ zs), which requires less work getting the elements from xs. Is this kind of optimization something that is or can be done (automatically)? > > Thanks for your indulgence, > > Todd Wilson > _______________________________________________ > 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. From brown.m at pm.me Wed Jul 12 23:06:06 2023 From: brown.m at pm.me (Melanie Brown) Date: Wed, 12 Jul 2023 23:06:06 +0000 Subject: [Haskell-cafe] Musings on lists In-Reply-To: References: Message-ID: You are correct that (++) is associative, but this is only a statement about the equality of the lists, not the complexity of the algorithm used to calculate the lists in order to compare them. If you expect to be concatenating many lists in a left-associative way, it is more efficient to opt for an alternative representation, the difference list: https://wiki.haskell.org/Difference_list Instead of storing the list per se, one stores instead a function, that would prepend all of its elements in the proper order to an existing list. The isomorphism to a regular list is the application to []. But this representation turns concatenation into function application: instead of a chain of (++) we obtain a chain of (:), which as you pointed out is much faster than repeatedly traversing the same list to get to the ever-receding end. Isomorphisms like these are useful for changing the algorithmic complexity of operations without affecting their correctness. In the same vein, it’s more effective to combine several folds of the same list into a single accumulator, and traverse it only once. There are tools (such as the lens library) for converting between isomorphic representations, but I am not aware of any automagical solutions to this kind of problem (except, perhaps, rewrite rules, but that’s compiler wizardry). Cheers Melanie Brown https://wiki.haskell.org/Difference_list On Wed, Jul 12, 2023 at 18:06, Todd Wilson <[twilson at csufresno.edu](mailto:On Wed, Jul 12, 2023 at 18:06, Todd Wilson < wrote: > Deaf Cafe, > > I'm an educator using Haskell, and I've been telling my students certain stories about Haskell evaluation that I'm now starting to question, so I'm writing for some clarification. I've written before about similar things (e.g., "Basic list exercise" from Mar 16), so it seems my own education on this topic is not yet complete! My apologies if this is too trivial for the Cafe. > > One story I tell students is that list concatenation, xs ++ ys, ends up "copying" the elements of xs but not the elements of ys, and in particular an expression like xs ++ [a], putting a new element at the end of a list, is particularly expensive, at least compared to x : xs, putting one at the beginning, which seems obvious, right? > > But here is my question: isn't xs ++ ys just a thunk that, as elements are "requested" from it, produces them first from xs and then, when those run out, defers entirely to ys from that point on? If so, then the elements of xs aren't "copied" any more than the elements of ys are; they are just produced from different places. Even the expression xs ++ [a] isn't problematic in this light: just act like xs, but with one more "card up the sleeve" when you are done. Have I gotten that right? > > Second, if the above is correct, then if there is a nesting, (xs ++ ys) ++ zs, and we want an element from it, there will be two steps before we can get that element from xs. And this will continue until xs is exhausted, at which point we get new elements in one step from ys, and finally in zero steps from zs. But ++ is associative, and so this list is also xs ++ (ys ++ zs), which requires less work getting the elements from xs. Is this kind of optimization something that is or can be done (automatically)? > > Thanks for your indulgence, > > Todd Wilson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jclites at mac.com Thu Jul 13 01:11:12 2023 From: jclites at mac.com (Jeff Clites) Date: Wed, 12 Jul 2023 18:11:12 -0700 Subject: [Haskell-cafe] Musings on lists In-Reply-To: References: Message-ID: <276EB376-34AA-4BE7-BAEE-24A3F3A3DF1F@mac.com> Lazy evaluation does make it more subtle to actually define things like algorithmic complexity. So regarding this: > isn't xs ++ ys just a thunk that, as elements are "requested" from it, produces them first from xs and then, when those run out, defers entirely to ys from that point on? If so, then the elements of xs aren't "copied" any more than the elements of ys are; they are just produced from different places. It helps to start with the definition of ++: (++) :: [a] -> [a] -> [a] (++) [] ys = ys (++) (x:xs) ys = x : xs ++ ys But to be even more explicit, let's make our own list type so that the constructors have normal names: data List a = Cons a (List a) | Empty and now this definition directly translates to: concat :: List a -> List a -> List a concat Empty ys = ys concat (Cons z zs) ys = Cons z (concat zs ys) But let's be even more explicit and simplify (desugar) this definition further: concat :: List a -> List a -> List a concat xs ys = case xs of Empty -> ys Cons z zs -> let temp = concat zs ys in Cons z temp The point of all of this is to emphasize that when you evaluate `concat xs ys`, in the non-empty xs case you will allocate a new data structure, the Cons holding the head element of xs, and the `temp` thunk representing the tail of the result. So that's the additional overhead--you have to allocate a new cell, because although the head is an existing element, the tail is not--it has to capture the parameters necessary for the recursive call, which is new information. If (and only if) you evaluate the tail, you will force evaluation of the `temp` thunk, which will allocate another cell if zs is not empty (via the recursive call). So if you traverse the entire list, you will allocate a new cell for each element of xs--once these run out, you will recurse into the Empty case, and return ys, and you won't allocate new cells for the elements of ys. But you only perform this allocation as you traverse the list (for the first time), so if you never actually traverse it then indeed you will only ever allocate one new cell in total. So you are right that saying that "xs ++ ys copies xs" is misleading--that "copy" only happens during subsequent traversal, and it would be better described as "allocates a new cell for each element of xs, as it traverses". Also, in this notation, (:) becomes: prepend :: a -> List a -> List a prepend x xs = Cons x xs Here, you allocate one new cell, but that's it--there is no recursive call, just a constructor application to existing values. That was a bit long-winded but I hope it was clear. Important note: This is different from (for example) the Java case, where List is an interface, and you can create an implementation with a custom iterator which just serves out elements from two existing lists without having to do any O(n) allocation. In the Haskell case, a list is a concrete data type, and it's expressed directly as a linked list of cells, and retrieving an element requires creation (at some point) of a cell holding that element (as well as the tail representing the rest of the list.) Jeff > On Jul 12, 2023, at 3:07 PM, Todd Wilson wrote: > >  > Deaf Cafe, > > I'm an educator using Haskell, and I've been telling my students certain stories about Haskell evaluation that I'm now starting to question, so I'm writing for some clarification. I've written before about similar things (e.g., "Basic list exercise" from Mar 16), so it seems my own education on this topic is not yet complete! My apologies if this is too trivial for the Cafe. > > One story I tell students is that list concatenation, xs ++ ys, ends up "copying" the elements of xs but not the elements of ys, and in particular an expression like xs ++ [a], putting a new element at the end of a list, is particularly expensive, at least compared to x : xs, putting one at the beginning, which seems obvious, right? > > But here is my question: isn't xs ++ ys just a thunk that, as elements are "requested" from it, produces them first from xs and then, when those run out, defers entirely to ys from that point on? If so, then the elements of xs aren't "copied" any more than the elements of ys are; they are just produced from different places. Even the expression xs ++ [a] isn't problematic in this light: just act like xs, but with one more "card up the sleeve" when you are done. Have I gotten that right? > > Second, if the above is correct, then if there is a nesting, (xs ++ ys) ++ zs, and we want an element from it, there will be two steps before we can get that element from xs. And this will continue until xs is exhausted, at which point we get new elements in one step from ys, and finally in zero steps from zs. But ++ is associative, and so this list is also xs ++ (ys ++ zs), which requires less work getting the elements from xs. Is this kind of optimization something that is or can be done (automatically)? > > Thanks for your indulgence, > > Todd Wilson > _______________________________________________ > 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. From raoknz at gmail.com Thu Jul 13 03:39:08 2023 From: raoknz at gmail.com (Richard O'Keefe) Date: Thu, 13 Jul 2023 15:39:08 +1200 Subject: [Haskell-cafe] Musings on lists In-Reply-To: <276EB376-34AA-4BE7-BAEE-24A3F3A3DF1F@mac.com> References: <276EB376-34AA-4BE7-BAEE-24A3F3A3DF1F@mac.com> Message-ID: Three points. 1. xs ++ ys never copies the *elements* of xs at all. What it copies is the SPINE of xs (think of each cons node as a vertebra), the cons cells. It's important to be clear about this, because students are only to ready to believe that the elements themselves are copied. 2. xs ++ ys does copy the spine of xs. In a strict language like ML or F#, it does so right away. In a non-strict language like Haskell, it does so, but later. If you ever explore the result of xs ++ ys far enough to reach ys, you will by then have copied the spine of xs. This means that xs ++ [a] is still more expensive than a : xs, it's just a matter of when the payment is made. 3. If you actually need to build a sequence from both ends for some reason, Data.Sequence exists. Or you can build a tree and then flatten it. On Thu, 13 Jul 2023 at 13:12, Jeff Clites via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Lazy evaluation does make it more subtle to actually define things like > algorithmic complexity. So regarding this: > > > isn't xs ++ ys just a thunk that, as elements are "requested" from it, > produces them first from xs and then, when those run out, defers entirely > to ys from that point on? If so, then the elements of xs aren't "copied" > any more than the elements of ys are; they are just produced from different > places. > > It helps to start with the definition of ++: > > (++) :: [a] -> [a] -> [a] > (++) [] ys = ys > (++) (x:xs) ys = x : xs ++ ys > > But to be even more explicit, let's make our own list type so that the > constructors have normal names: > > data List a = Cons a (List a) | Empty > > and now this definition directly translates to: > > concat :: List a -> List a -> List a > concat Empty ys = ys > concat (Cons z zs) ys = Cons z (concat zs ys) > > But let's be even more explicit and simplify (desugar) this definition > further: > > concat :: List a -> List a -> List a > concat xs ys = > case xs of > Empty -> ys > Cons z zs -> > let temp = concat zs ys > in Cons z temp > > The point of all of this is to emphasize that when you evaluate `concat xs > ys`, in the non-empty xs case you will allocate a new data structure, the > Cons holding the head element of xs, and the `temp` thunk representing the > tail of the result. > > So that's the additional overhead--you have to allocate a new cell, > because although the head is an existing element, the tail is not--it has > to capture the parameters necessary for the recursive call, which is new > information. If (and only if) you evaluate the tail, you will force > evaluation of the `temp` thunk, which will allocate another cell if zs is > not empty (via the recursive call). So if you traverse the entire list, you > will allocate a new cell for each element of xs--once these run out, you > will recurse into the Empty case, and return ys, and you won't allocate new > cells for the elements of ys. But you only perform this allocation as you > traverse the list (for the first time), so if you never actually traverse > it then indeed you will only ever allocate one new cell in total. So you > are right that saying that "xs ++ ys copies xs" is misleading--that "copy" > only happens during subsequent traversal, and it would be better described > as "allocates a new cell for each element of xs, as it traverses". > > Also, in this notation, (:) becomes: > > prepend :: a -> List a -> List a > prepend x xs = Cons x xs > > Here, you allocate one new cell, but that's it--there is no recursive > call, just a constructor application to existing values. > > That was a bit long-winded but I hope it was clear. > > Important note: This is different from (for example) the Java case, where > List is an interface, and you can create an implementation with a custom > iterator which just serves out elements from two existing lists without > having to do any O(n) allocation. In the Haskell case, a list is a concrete > data type, and it's expressed directly as a linked list of cells, and > retrieving an element requires creation (at some point) of a cell holding > that element (as well as the tail representing the rest of the list.) > > Jeff > > > On Jul 12, 2023, at 3:07 PM, Todd Wilson wrote: > > > >  > > Deaf Cafe, > > > > I'm an educator using Haskell, and I've been telling my students certain > stories about Haskell evaluation that I'm now starting to question, so I'm > writing for some clarification. I've written before about similar things > (e.g., "Basic list exercise" from Mar 16), so it seems my own education on > this topic is not yet complete! My apologies if this is too trivial for the > Cafe. > > > > One story I tell students is that list concatenation, xs ++ ys, ends up > "copying" the elements of xs but not the elements of ys, and in particular > an expression like xs ++ [a], putting a new element at the end of a list, > is particularly expensive, at least compared to x : xs, putting one at the > beginning, which seems obvious, right? > > > > But here is my question: isn't xs ++ ys just a thunk that, as elements > are "requested" from it, produces them first from xs and then, when those > run out, defers entirely to ys from that point on? If so, then the elements > of xs aren't "copied" any more than the elements of ys are; they are just > produced from different places. Even the expression xs ++ [a] isn't > problematic in this light: just act like xs, but with one more "card up the > sleeve" when you are done. Have I gotten that right? > > > > Second, if the above is correct, then if there is a nesting, (xs ++ ys) > ++ zs, and we want an element from it, there will be two steps before we > can get that element from xs. And this will continue until xs is exhausted, > at which point we get new elements in one step from ys, and finally in zero > steps from zs. But ++ is associative, and so this list is also xs ++ (ys ++ > zs), which requires less work getting the elements from xs. Is this kind of > optimization something that is or can be done (automatically)? > > > > Thanks for your indulgence, > > > > Todd Wilson > > _______________________________________________ > > 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. > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From twilson at csufresno.edu Thu Jul 13 04:18:19 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 12 Jul 2023 21:18:19 -0700 Subject: [Haskell-cafe] Musings on lists In-Reply-To: References: Message-ID: Thanks to those who have contributed answers to my questions. I can see how, in a context like let zs = xs ++ ys in .... with a persistent reference to the concatenation, the spine (not the elements) of xs would have to be copied, because zs might need to be traversed multiple times. But what about something like f (xs ++ ys) for a function f that makes a single pass through its argument list (like length or sum)? --Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu Jul 13 04:39:37 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 13 Jul 2023 00:39:37 -0400 Subject: [Haskell-cafe] Musings on lists In-Reply-To: References: <276EB376-34AA-4BE7-BAEE-24A3F3A3DF1F@mac.com> Message-ID: On Thu, Jul 13, 2023 at 03:39:08PM +1200, Richard O'Keefe wrote: > 2. xs ++ ys does copy the spine of xs. In a strict language like > ML or F#, it does so right away. In a non-strict language > like Haskell, it does so, but later. If you ever explore the > result of xs ++ ys far enough to reach ys, you will by then > have copied the spine of xs. This means that xs ++ [a] is still > more expensive than a : xs, it's just a matter of when the > payment is made. Yes, if the list head is used more than once. When "xs ++ ys" is used in a fold and never seen again, no copying happens, but a thunk is allocated. In particular a single list append that's folded away is free, and the below runs in constant space, regardless of the specified length. module Main (main) where import System.Environment import Data.Foldable main :: IO () main = do fmap (read . head) getArgs >>= print . sum . xs where xs :: Int -> [Int] xs n = [1..n] ++ [1..n] The real problem is with, e.g., iterated construction of a list by appending one element at a time, depth first: module Main (main) where import System.Environment import Data.Foldable main :: IO () main = do fmap (read . head) getArgs >>= print . sum . xs where xs :: Int -> [Int] xs n = go [] [1..n] where go ys [] = ys go ys (x : xs) = go (ys ++ [x]) xs The space cost here is at least quadratic: 2 x list length -> 5.1 x allocations 3 x list length -> 12.5 x allocations 4 x list length -> 23 x allocations ... -- Viktor. From olf at aatal-apotheke.de Thu Jul 13 14:44:12 2023 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 13 Jul 2023 16:44:12 +0200 Subject: [Haskell-cafe] Musings on lists Message-ID: <480486ea48a78c048a0f399c2e80c1180759a863.camel@aatal-apotheke.de> Perhaps, if the students have been in contact with a language that has explicit pointers (C or C++), let them implement linked lists and concatenation in that procedural language. (An AI will likely also produce a correct implementation nowadays.) The advantage is that one can inspect the values of the pointers to see whether any copying has happened. Then the students easily see that only the spine (structure holding pointers) is re-created, but the memory the list elements point to is never touched. That is an instance of parametricity, I believe. The fact that length (replicate 3 undefined ++ replicate 2 undefined) evaluates to 5 also shows this. Olaf From jaro.reinders at gmail.com Thu Jul 13 17:26:10 2023 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Thu, 13 Jul 2023 19:26:10 +0200 Subject: [Haskell-cafe] Musings on lists In-Reply-To: <480486ea48a78c048a0f399c2e80c1180759a863.camel@aatal-apotheke.de> References: <480486ea48a78c048a0f399c2e80c1180759a863.camel@aatal-apotheke.de> Message-ID: <3660e54f-2130-d0ff-3b57-69b604fd2d9b@gmail.com> Or you can use ghc-vis: https://dennis.felsing.org/ghc-vis/ https://www.youtube.com/watch?v=I4lnCG18TaY Jaro On 13-07-2023 16:44, Olaf Klinke wrote: > Perhaps, if the students have been in contact with a language that has > explicit pointers (C or C++), let them implement linked lists and > concatenation in that procedural language. (An AI will likely also > produce a correct implementation nowadays.) The advantage is that one > can inspect the values of the pointers to see whether any copying has > happened. Then the students easily see that only the spine (structure > holding pointers) is re-created, but the memory the list elements point > to is never touched. That is an instance of parametricity, I believe. > The fact that > > length (replicate 3 undefined ++ replicate 2 undefined) > > evaluates to 5 also shows this. > > > Olaf > > _______________________________________________ > 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. From jclites at mac.com Thu Jul 13 17:31:02 2023 From: jclites at mac.com (Jeff Clites) Date: Thu, 13 Jul 2023 10:31:02 -0700 Subject: [Haskell-cafe] Musings on lists In-Reply-To: References: Message-ID: Yes, the allocation still happens. In the "single-pass" case, all of the newly-allocated data structures don't have to persist in memory simultaneously (that is, some become available for GC while other are still being created), but they still happen. Consider: xs = 1 : (2 : (3: [] ) ) ys = 4 : (5 : (6: [] ) ) zs = xs ++ ys xs is a data structure with two field--a head and a tail. The head of xs contains 1 and the tail contains the list [2, 3]. On the other hand, the head of zs also contains 1, but the tail contains [2, 3, 4, 5, 6]. It doesn't matter that the tail may be initially represented as a thunk, the important part is that since xs and zs contain different tails, they have to be different physical data structures. So zs has to have been a new allocation. Continuing with the tails of xs and zs: (tail xs) has a head containing 2, and a tail containing [3]. (tail zs) has a head containing 2, and a tail containing [3, 4, 5, 6]. So again, these have to be two physically different data structures. ((tail (tail xs)) has a head containing 3 and a tail containing []. ((tail (tail zs)) has a head containing 3 and a tail containing [4, 5, 6]. So again, these have to be two physically different data structures. But now: (tail ((tail (tail zs))) has a head containing 4, and a tail containing [5, 6]. ys has a head containing 4 and a tail containing [5, 6]. Those are the same, so they can be physically the same data structure. So zs will require 3 additional allocations, one for each element of xs. Jef > On Jul 12, 2023, at 9:18 PM, Todd Wilson wrote: > > Thanks to those who have contributed answers to my questions. I can see how, in a context like > let zs = xs ++ ysin .... with a persistent reference to the concatenation, the spine (not the elements) of xs would have to be copied, because zs might need to be traversed multiple times. But what about something like > f (xs ++ ys) > for a function f that makes a single pass through its argument list (like length or sum)? > > --Todd From olf at aatal-apotheke.de Fri Jul 14 12:43:55 2023 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 14 Jul 2023 14:43:55 +0200 Subject: [Haskell-cafe] Musings on lists Message-ID: <196f395d9a9c7c603f3f10bdaa5e40efa171d4ac.camel@aatal-apotheke.de> The fact that [a] is a linked list is exploited in Data.List.tails as well as in https://hackage.haskell.org/package/suffixtree where suffixes and internal segments of the tree all use Cons cells of the original list, so the overhead is only in the tree structure itself. In fact, exploiting the location of the internal tree nodes relative to the original list, one could compress the list similarly to the Lempel-Ziv 78 algorithm. This way, bioinformaticians manage to create full-text index structures [*] that are not much larger, or even smaller than, the original text. Olaf [*] Lempel-Ziv 78 creates a suffix tree of the text holding only a subset of all suffixes, namely those starting at a block boundary. This already suffices to find all occurrences of substrings spanning a block boundary. From root at livid.pp.ru Mon Jul 17 18:19:40 2023 From: root at livid.pp.ru (Nikolay Yakimov) Date: Mon, 17 Jul 2023 21:19:40 +0300 Subject: [Haskell-cafe] Taking over maintenance of int-cast package Message-ID: <6d8d7072-21cd-d871-a08a-f808ae2e5182@livid.pp.ru> I intend to take over int-cast (https://hackage.haskell.org/package/int-cast) package. I think it implements a reasonable approach to ensuring compile-time safety of integer casts, and it would be sad to see it silently fall into obscurity due to the lack of maintenance. This was discussed on GitHub (https://github.com/haskell-hvr/int-cast/issues/5#issuecomment-1620402453) since July 4, 2023, and I tried reaching @hvr via e-mail on July 5. Didn't receive a reply at the time of writing, and it seems unlikely I will anytime soon, hence moving on with the takeover process. This message is cross-posted to Haskell Discourse (https://discourse.haskell.org/t/taking-over-maintenance-of-int-cast-package/7024) From plredmond at ucsc.edu Tue Jul 18 04:49:42 2023 From: plredmond at ucsc.edu (Patrick L Redmond) Date: Tue, 18 Jul 2023 00:49:42 -0400 Subject: [Haskell-cafe] Citation information for 'base' hackage docs Message-ID: Hi Haskell-Cafe, I'd like to cite the documentation for a particular module and version of the "base" package in an academic publication. In this case, it makes sense to cite the documentation instead of the papers listed at the top because the behavior described in the documentation isn't described by the papers (the module's implementation has diverged from them). To what author should I attribute the documentation? The page lists " libraries at haskell.org" as the maintainer. What title should I give for the work? The html title is "Control.Exception". Thank you, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Tue Jul 18 06:46:55 2023 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 18 Jul 2023 08:46:55 +0200 Subject: [Haskell-cafe] Citation information for 'base' hackage docs In-Reply-To: References: Message-ID: Hello Patrick, Il 18 luglio 2023 alle 00:49 Patrick L Redmond via Haskell-Cafe ha scritto: > To what author should I attribute the documentation? The page lists " > libraries at haskell.org" as the maintainer. What title should I give for the > work? The html title is "Control.Exception". Mhhh, GHC © file is quite outdated — last commit 17 years ago! https://gitlab.haskell.org/ghc/ghc/-/blob/master/LICENSE I would ask a librarian, but I suspect “GHC contributors” and “Control.Exception module from `base` package” would do! —F From lemming at henning-thielemann.de Tue Jul 18 06:50:03 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 18 Jul 2023 08:50:03 +0200 (CEST) Subject: [Haskell-cafe] Citation information for 'base' hackage docs In-Reply-To: References: Message-ID: <45bd3a5f-dfe3-d923-8e46-8c2fb767a619@henning-thielemann.de> On Tue, 18 Jul 2023, Patrick L Redmond via Haskell-Cafe wrote: > I'd like to cite the documentation for a particular module and version > of the "base" package in an academic publication. In this case, it makes > sense to cite the documentation instead of the papers listed at the top > because the behavior described in the documentation isn't described by > the papers (the module's implementation has diverged from them). Btw. I have written an example program that generates BibTeX entries for Cabal packages: https://hackage.haskell.org/package/bibtex Unfortunately, it still uses an outdated version of Cabal, the library. From twilson at csufresno.edu Thu Jul 20 04:24:20 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 19 Jul 2023 21:24:20 -0700 Subject: [Haskell-cafe] Redundant/overlapping patterns? Message-ID: Hi, Cafe, Can someone please explain this: ghci> case 1 of 2 -> 3 :1:11: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... *** Exception: :1:1-16: Non-exhaustive patterns in case The non-exhaustive patterns part is obvious, but what is redundant about this match? And how can there be overlapping patterns when there's only one? Todd Wilson -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu Jul 20 04:53:03 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 20 Jul 2023 00:53:03 -0400 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: References: Message-ID: On Wed, Jul 19, 2023 at 09:24:20PM -0700, Todd Wilson wrote: > Can someone please explain this: > > ghci> case 1 of 2 -> 3 > > :1:11: warning: [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: 2 -> ... > *** Exception: :1:1-16: Non-exhaustive patterns in case > > The non-exhaustive patterns part is obvious, but what is redundant about > this match? And how can there be overlapping patterns when there's only one? The error message changed betweek 8.8 and 8.10: GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help λ> data X = A | B λ> case A of B -> 42 *** Exception: :2:1-18: Non-exhaustive patterns in case vs. GHCi, version 8.10.5: https://www.haskell.org/ghc/ :? for help λ> data X = A | B λ> case A of B -> 42 :2:11: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: B -> ... *** Exception: :2:1-17: Non-exhaustive patterns in case The exception part is the same, and I hope non-controversial, the pattern match is indeed non-exhaustive. What's new is the compile-time warning. It is documented at, e.g.: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html#ghc-flag--Woverlapping-patterns where it is explained that a pattern is considered "overlapping" when it is unreachable, which is true in this case, though for reasons other than redundancy wrt. a prior pattern. And indeed we see the true issue/criterion is "reachability": λ> case A of B | GHC.Exts.considerAccessible -> 42 *** Exception: :3:1-47: Non-exhaustive patterns in case The same is of course seen if the warning is disabled: λ> :set -Wno-overlapping-patterns λ> case A of B -> 42 *** Exception: :6:1-17: Non-exhaustive patterns in case The pattern match is redundant given the specific scrutinee. Perhaps non-reachability in this case could be reported via a different warning, but we have what we have. -- Viktor. From ben.franksen at online.de Fri Jul 21 09:56:44 2023 From: ben.franksen at online.de (Ben Franksen) Date: Fri, 21 Jul 2023 11:56:44 +0200 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: References: Message-ID: So the error message should talk about "unreachable pattern" instead of "redundant pattern". That would cover all situations and would be less confusing in this special one. Cheers Ben Am 20.07.23 um 06:53 schrieb Viktor Dukhovni: > On Wed, Jul 19, 2023 at 09:24:20PM -0700, Todd Wilson wrote: > >> Can someone please explain this: >> >> ghci> case 1 of 2 -> 3 >> >> :1:11: warning: [-Woverlapping-patterns] >> Pattern match is redundant >> In a case alternative: 2 -> ... >> *** Exception: :1:1-16: Non-exhaustive patterns in case >> >> The non-exhaustive patterns part is obvious, but what is redundant about >> this match? And how can there be overlapping patterns when there's only one? > > The error message changed betweek 8.8 and 8.10: > > GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help > λ> data X = A | B > λ> case A of B -> 42 > > *** Exception: :2:1-18: Non-exhaustive patterns in case > > vs. > > GHCi, version 8.10.5: https://www.haskell.org/ghc/ :? for help > λ> data X = A | B > λ> case A of B -> 42 > > :2:11: warning: [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: B -> ... > *** Exception: :2:1-17: Non-exhaustive patterns in case > > The exception part is the same, and I hope non-controversial, the > pattern match is indeed non-exhaustive. What's new is the compile-time > warning. It is documented at, e.g.: > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html#ghc-flag--Woverlapping-patterns > > where it is explained that a pattern is considered "overlapping" when it > is unreachable, which is true in this case, though for reasons other > than redundancy wrt. a prior pattern. And indeed we see the true > issue/criterion is "reachability": > > λ> case A of B | GHC.Exts.considerAccessible -> 42 > > *** Exception: :3:1-47: Non-exhaustive patterns in case > > The same is of course seen if the warning is disabled: > > λ> :set -Wno-overlapping-patterns > λ> case A of B -> 42 > > *** Exception: :6:1-17: Non-exhaustive patterns in case > > The pattern match is redundant given the specific scrutinee. Perhaps > non-reachability in this case could be reported via a different warning, > but we have what we have. > -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman From jclites at mac.com Fri Jul 21 10:15:11 2023 From: jclites at mac.com (Jeff Clites) Date: Fri, 21 Jul 2023 03:15:11 -0700 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: References: Message-ID: I think it’s saying it’s redundant because you already known what constructor it is; I’m guessing you’d get the same error from “case A of A -> …”. Jeff > On Jul 21, 2023, at 2:57 AM, Ben Franksen wrote: > > So the error message should talk about "unreachable pattern" instead of "redundant pattern". That would cover all situations and would be less confusing in this special one. > > Cheers > Ben > >> Am 20.07.23 um 06:53 schrieb Viktor Dukhovni: >>> On Wed, Jul 19, 2023 at 09:24:20PM -0700, Todd Wilson wrote: >>> Can someone please explain this: >>> >>> ghci> case 1 of 2 -> 3 >>> >>> :1:11: warning: [-Woverlapping-patterns] >>> Pattern match is redundant >>> In a case alternative: 2 -> ... >>> *** Exception: :1:1-16: Non-exhaustive patterns in case >>> >>> The non-exhaustive patterns part is obvious, but what is redundant about >>> this match? And how can there be overlapping patterns when there's only one? >> The error message changed betweek 8.8 and 8.10: >> GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help >> λ> data X = A | B >> λ> case A of B -> 42 >> *** Exception: :2:1-18: Non-exhaustive patterns in case >> vs. >> GHCi, version 8.10.5: https://www.haskell.org/ghc/ :? for help >> λ> data X = A | B >> λ> case A of B -> 42 >> :2:11: warning: [-Woverlapping-patterns] >> Pattern match is redundant >> In a case alternative: B -> ... >> *** Exception: :2:1-17: Non-exhaustive patterns in case >> The exception part is the same, and I hope non-controversial, the >> pattern match is indeed non-exhaustive. What's new is the compile-time >> warning. It is documented at, e.g.: >> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html#ghc-flag--Woverlapping-patterns >> where it is explained that a pattern is considered "overlapping" when it >> is unreachable, which is true in this case, though for reasons other >> than redundancy wrt. a prior pattern. And indeed we see the true >> issue/criterion is "reachability": >> λ> case A of B | GHC.Exts.considerAccessible -> 42 >> *** Exception: :3:1-47: Non-exhaustive patterns in case >> The same is of course seen if the warning is disabled: >> λ> :set -Wno-overlapping-patterns >> λ> case A of B -> 42 >> *** Exception: :6:1-17: Non-exhaustive patterns in case >> The pattern match is redundant given the specific scrutinee. Perhaps >> non-reachability in this case could be reported via a different warning, >> but we have what we have. > > -- > I would rather have questions that cannot be answered, than answers that > cannot be questioned. -- Richard Feynman > > > _______________________________________________ > 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. From twilson at csufresno.edu Fri Jul 21 19:21:47 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Fri, 21 Jul 2023 12:21:47 -0700 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: References: Message-ID: λ: data X = A|B λ: let x = A in case x of A -> True; B -> False True λ: case A of A -> True ; B -> False :3:23: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: B -> ... True Isn't this violating referential transparency (in a way)? --Todd On Fri, Jul 21, 2023 at 3:15 AM Jeff Clites via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > I think it’s saying it’s redundant because you already known what > constructor it is; I’m guessing you’d get the same error from “case A of A > -> …”. > > Jeff > > > On Jul 21, 2023, at 2:57 AM, Ben Franksen > wrote: > > > > So the error message should talk about "unreachable pattern" instead of > "redundant pattern". That would cover all situations and would be less > confusing in this special one. > > > > Cheers > > Ben > > > >> Am 20.07.23 um 06:53 schrieb Viktor Dukhovni: > >>> On Wed, Jul 19, 2023 at 09:24:20PM -0700, Todd Wilson wrote: > >>> Can someone please explain this: > >>> > >>> ghci> case 1 of 2 -> 3 > >>> > >>> :1:11: warning: [-Woverlapping-patterns] > >>> Pattern match is redundant > >>> In a case alternative: 2 -> ... > >>> *** Exception: :1:1-16: Non-exhaustive patterns in case > >>> > >>> The non-exhaustive patterns part is obvious, but what is redundant > about > >>> this match? And how can there be overlapping patterns when there's > only one? > >> The error message changed betweek 8.8 and 8.10: > >> GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help > >> λ> data X = A | B > >> λ> case A of B -> 42 > >> *** Exception: :2:1-18: Non-exhaustive patterns in case > >> vs. > >> GHCi, version 8.10.5: https://www.haskell.org/ghc/ :? for help > >> λ> data X = A | B > >> λ> case A of B -> 42 > >> :2:11: warning: [-Woverlapping-patterns] > >> Pattern match is redundant > >> In a case alternative: B -> ... > >> *** Exception: :2:1-17: Non-exhaustive patterns in case > >> The exception part is the same, and I hope non-controversial, the > >> pattern match is indeed non-exhaustive. What's new is the compile-time > >> warning. It is documented at, e.g.: > >> > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html#ghc-flag--Woverlapping-patterns > >> where it is explained that a pattern is considered "overlapping" when it > >> is unreachable, which is true in this case, though for reasons other > >> than redundancy wrt. a prior pattern. And indeed we see the true > >> issue/criterion is "reachability": > >> λ> case A of B | GHC.Exts.considerAccessible -> 42 > >> *** Exception: :3:1-47: Non-exhaustive patterns in case > >> The same is of course seen if the warning is disabled: > >> λ> :set -Wno-overlapping-patterns > >> λ> case A of B -> 42 > >> *** Exception: :6:1-17: Non-exhaustive patterns in case > >> The pattern match is redundant given the specific scrutinee. Perhaps > >> non-reachability in this case could be reported via a different warning, > >> but we have what we have. > > > > -- > > I would rather have questions that cannot be answered, than answers that > > cannot be questioned. -- Richard Feynman > > > > > > _______________________________________________ > > 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. > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anka.213 at gmail.com Fri Jul 21 20:17:33 2023 From: anka.213 at gmail.com (=?utf-8?Q?Andreas_K=C3=A4llberg?=) Date: Fri, 21 Jul 2023 22:17:33 +0200 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: References: Message-ID: <2F2DB7FB-F2F6-4653-8CBF-045E5EAECE15@gmail.com> I think unreachable would be instead of “overlapping”, rather than instead of “redundant”, since those refer to different things. Redundant patterns are when the constructor is already known, while overlapping is when the case unreachable. Regards, Andreas > On 21 Jul 2023, at 11:57, Ben Franksen wrote: > So the error message should talk about "unreachable pattern" instead of "redundant pattern". That would cover all situations and would be less confusing in this special one. > > Cheers > Ben > > Am 20.07.23 um 06:53 schrieb Viktor Dukhovni: >> On Wed, Jul 19, 2023 at 09:24:20PM -0700, Todd Wilson wrote: >>> Can someone please explain this: >>> ghci> case 1 of 2 -> 3 >>> :1:11: warning: [-Woverlapping-patterns] >>> Pattern match is redundant >>> In a case alternative: 2 -> ... >>> *** Exception: :1:1-16: Non-exhaustive patterns in case >>> The non-exhaustive patterns part is obvious, but what is redundant about >>> this match? And how can there be overlapping patterns when there's only one? >> The error message changed betweek 8.8 and 8.10: >> GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help >> λ> data X = A | B >> λ> case A of B -> 42 >> *** Exception: :2:1-18: Non-exhaustive patterns in case >> vs. >> GHCi, version 8.10.5: https://www.haskell.org/ghc/ :? for help >> λ> data X = A | B >> λ> case A of B -> 42 >> :2:11: warning: [-Woverlapping-patterns] >> Pattern match is redundant >> In a case alternative: B -> ... >> *** Exception: :2:1-17: Non-exhaustive patterns in case >> The exception part is the same, and I hope non-controversial, the >> pattern match is indeed non-exhaustive. What's new is the compile-time >> warning. It is documented at, e.g.: >> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html#ghc-flag--Woverlapping-patterns >> where it is explained that a pattern is considered "overlapping" when it >> is unreachable, which is true in this case, though for reasons other >> than redundancy wrt. a prior pattern. And indeed we see the true >> issue/criterion is "reachability": >> λ> case A of B | GHC.Exts.considerAccessible -> 42 >> *** Exception: :3:1-47: Non-exhaustive patterns in case >> The same is of course seen if the warning is disabled: >> λ> :set -Wno-overlapping-patterns >> λ> case A of B -> 42 >> *** Exception: :6:1-17: Non-exhaustive patterns in case >> The pattern match is redundant given the specific scrutinee. Perhaps >> non-reachability in this case could be reported via a different warning, >> but we have what we have. > > -- > I would rather have questions that cannot be answered, than answers that > cannot be questioned. -- Richard Feynman > > > _______________________________________________ > 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. From ietf-dane at dukhovni.org Fri Jul 21 20:31:36 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 21 Jul 2023 16:31:36 -0400 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: <2F2DB7FB-F2F6-4653-8CBF-045E5EAECE15@gmail.com> References: <2F2DB7FB-F2F6-4653-8CBF-045E5EAECE15@gmail.com> Message-ID: On Fri, Jul 21, 2023 at 10:17:33PM +0200, Andreas Källberg wrote: > I think unreachable would be instead of “overlapping”, rather than > instead of “redundant”, since those refer to different things. > Redundant patterns are when the constructor is already known, while > overlapping is when the case unreachable. It is a bit more general than "constructor known", since GHC is also able to rule out reachability even when the constructor is not fully known: λ> f x = case (x, x) of { (True, True) -> 0; (False, False) -> 1; (_, _) -> 2 } :5:64: warning: [GHC-53633] [-Woverlapping-patterns] Pattern match is redundant In a case alternative: (_, _) -> ... Whatever `x` is, the first two patterns are sufficient, though it could be either. Regardless of how it is that the compiler figures out that no value of the scrutinee can reach a pattern, once that is known, the pattern is unreachable, and so redundant in context. That context is the "shape" of the scrutinee plus any earlier patterns. The fact that static knowledge of the scrutinee is also taken into account can make the error message slightly surprising if one is just focusing on the list of patterns. But 'redundant' is still morally true. -- Viktor. From jclites at mac.com Fri Jul 21 22:20:03 2023 From: jclites at mac.com (Jeff Clites) Date: Fri, 21 Jul 2023 15:20:03 -0700 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: References: Message-ID: <9FAC4166-AAAB-4FB9-8EE4-E9DD645255FC@mac.com> Well, I think you don't have referential transparency of warnings. My interpretation is that if you write "case A of ..." (where A is a constructor), then it's probably not the code you meant to write, so the warning is there to let you know you might be making a mistake (even though it's a mistake that would compile). I could image a mistake like this: let a = f x in case A of ... where you meant to write: let a = f x in case a of ... Possibly the thinking it that having a literal constructor as a scrutinee is weird enough that it's more likely to be a mistake than intentional. But once the expression is any more complicated than that it's less obviously a mistake. Also, one other comment, about Ben Franksen's message: >> So the error message should talk about "unreachable pattern" instead of "redundant pattern". Ah but the message is actually: > Pattern match is redundant So I think it's trying to say not that the one pattern is redundant, but the whole case expression is redundant. Perhaps it should say something like "unnecessary case expression" instead. Jeff > On Jul 21, 2023, at 12:21 PM, Todd Wilson wrote: > > λ: data X = A|B > λ: let x = A in case x of A -> True; B -> False > True > λ: case A of A -> True ; B -> False > > :3:23: warning: [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: B -> ... > True > > Isn't this violating referential transparency (in a way)? > > --Todd > > On Fri, Jul 21, 2023 at 3:15 AM Jeff Clites via Haskell-Cafe wrote: > I think it’s saying it’s redundant because you already known what constructor it is; I’m guessing you’d get the same error from “case A of A -> …”. > > Jeff > > > On Jul 21, 2023, at 2:57 AM, Ben Franksen wrote: > > > > So the error message should talk about "unreachable pattern" instead of "redundant pattern". That would cover all situations and would be less confusing in this special one. > > > > Cheers > > Ben > > > >> Am 20.07.23 um 06:53 schrieb Viktor Dukhovni: > >>> On Wed, Jul 19, 2023 at 09:24:20PM -0700, Todd Wilson wrote: > >>> Can someone please explain this: > >>> > >>> ghci> case 1 of 2 -> 3 > >>> > >>> :1:11: warning: [-Woverlapping-patterns] > >>> Pattern match is redundant > >>> In a case alternative: 2 -> ... > >>> *** Exception: :1:1-16: Non-exhaustive patterns in case > >>> > >>> The non-exhaustive patterns part is obvious, but what is redundant about > >>> this match? And how can there be overlapping patterns when there's only one? > >> The error message changed betweek 8.8 and 8.10: > >> GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help > >> λ> data X = A | B > >> λ> case A of B -> 42 > >> *** Exception: :2:1-18: Non-exhaustive patterns in case > >> vs. > >> GHCi, version 8.10.5: https://www.haskell.org/ghc/ :? for help > >> λ> data X = A | B > >> λ> case A of B -> 42 > >> :2:11: warning: [-Woverlapping-patterns] > >> Pattern match is redundant > >> In a case alternative: B -> ... > >> *** Exception: :2:1-17: Non-exhaustive patterns in case > >> The exception part is the same, and I hope non-controversial, the > >> pattern match is indeed non-exhaustive. What's new is the compile-time > >> warning. It is documented at, e.g.: > >> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html#ghc-flag--Woverlapping-patterns > >> where it is explained that a pattern is considered "overlapping" when it > >> is unreachable, which is true in this case, though for reasons other > >> than redundancy wrt. a prior pattern. And indeed we see the true > >> issue/criterion is "reachability": > >> λ> case A of B | GHC.Exts.considerAccessible -> 42 > >> *** Exception: :3:1-47: Non-exhaustive patterns in case > >> The same is of course seen if the warning is disabled: > >> λ> :set -Wno-overlapping-patterns > >> λ> case A of B -> 42 > >> *** Exception: :6:1-17: Non-exhaustive patterns in case > >> The pattern match is redundant given the specific scrutinee. Perhaps > >> non-reachability in this case could be reported via a different warning, > >> but we have what we have. > > > > -- > > I would rather have questions that cannot be answered, than answers that > > cannot be questioned. -- Richard Feynman > > > > > > _______________________________________________ > > 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. > _______________________________________________ > 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. From jclites at mac.com Fri Jul 21 22:27:14 2023 From: jclites at mac.com (Jeff Clites) Date: Fri, 21 Jul 2023 15:27:14 -0700 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: <9FAC4166-AAAB-4FB9-8EE4-E9DD645255FC@mac.com> References: <9FAC4166-AAAB-4FB9-8EE4-E9DD645255FC@mac.com> Message-ID: <353C2EDD-B0A9-488A-8C4C-0BFF8095AE2B@mac.com> > On Jul 21, 2023, at 3:20 PM, Jeff Clites via Haskell-Cafe wrote: > > Also, one other comment, about Ben Franksen's message: > >>> So the error message should talk about "unreachable pattern" instead of "redundant pattern". > > Ah but the message is actually: > >> Pattern match is redundant > > So I think it's trying to say not that the one pattern is redundant, but the whole case expression is redundant. Perhaps it should say something like "unnecessary case expression" instead. Oh no I take that back, it is talking about a specific pattern: >> Pattern match is redundant >> In a case alternative: B -> ... But I do think a better complaint is that you don't need a case expression there at all, but it seems like that's not actually what it's complaining about. Hmm. Jeff >> On Jul 21, 2023, at 12:21 PM, Todd Wilson wrote: >> >> λ: data X = A|B >> λ: let x = A in case x of A -> True; B -> False >> True >> λ: case A of A -> True ; B -> False >> >> :3:23: warning: [-Woverlapping-patterns] >> Pattern match is redundant >> In a case alternative: B -> ... >> True >> >> Isn't this violating referential transparency (in a way)? >> >> --Todd >> >> On Fri, Jul 21, 2023 at 3:15 AM Jeff Clites via Haskell-Cafe wrote: >> I think it’s saying it’s redundant because you already known what constructor it is; I’m guessing you’d get the same error from “case A of A -> …”. >> >> Jeff >> >>> On Jul 21, 2023, at 2:57 AM, Ben Franksen wrote: >>> >>> So the error message should talk about "unreachable pattern" instead of "redundant pattern". That would cover all situations and would be less confusing in this special one. >>> >>> Cheers >>> Ben >>> >>>> Am 20.07.23 um 06:53 schrieb Viktor Dukhovni: >>>>> On Wed, Jul 19, 2023 at 09:24:20PM -0700, Todd Wilson wrote: >>>>> Can someone please explain this: >>>>> >>>>> ghci> case 1 of 2 -> 3 >>>>> >>>>> :1:11: warning: [-Woverlapping-patterns] >>>>> Pattern match is redundant >>>>> In a case alternative: 2 -> ... >>>>> *** Exception: :1:1-16: Non-exhaustive patterns in case >>>>> >>>>> The non-exhaustive patterns part is obvious, but what is redundant about >>>>> this match? And how can there be overlapping patterns when there's only one? >>>> The error message changed betweek 8.8 and 8.10: >>>> GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help >>>> λ> data X = A | B >>>> λ> case A of B -> 42 >>>> *** Exception: :2:1-18: Non-exhaustive patterns in case >>>> vs. >>>> GHCi, version 8.10.5: https://www.haskell.org/ghc/ :? for help >>>> λ> data X = A | B >>>> λ> case A of B -> 42 >>>> :2:11: warning: [-Woverlapping-patterns] >>>> Pattern match is redundant >>>> In a case alternative: B -> ... >>>> *** Exception: :2:1-17: Non-exhaustive patterns in case >>>> The exception part is the same, and I hope non-controversial, the >>>> pattern match is indeed non-exhaustive. What's new is the compile-time >>>> warning. It is documented at, e.g.: >>>> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html#ghc-flag--Woverlapping-patterns >>>> where it is explained that a pattern is considered "overlapping" when it >>>> is unreachable, which is true in this case, though for reasons other >>>> than redundancy wrt. a prior pattern. And indeed we see the true >>>> issue/criterion is "reachability": >>>> λ> case A of B | GHC.Exts.considerAccessible -> 42 >>>> *** Exception: :3:1-47: Non-exhaustive patterns in case >>>> The same is of course seen if the warning is disabled: >>>> λ> :set -Wno-overlapping-patterns >>>> λ> case A of B -> 42 >>>> *** Exception: :6:1-17: Non-exhaustive patterns in case >>>> The pattern match is redundant given the specific scrutinee. Perhaps >>>> non-reachability in this case could be reported via a different warning, >>>> but we have what we have. >>> >>> -- >>> I would rather have questions that cannot be answered, than answers that >>> cannot be questioned. -- Richard Feynman >>> >>> >>> _______________________________________________ >>> 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. >> _______________________________________________ >> 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. > > _______________________________________________ > 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. From twilson at csufresno.edu Sat Jul 22 00:14:00 2023 From: twilson at csufresno.edu (Todd Wilson) Date: Fri, 21 Jul 2023 17:14:00 -0700 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: <353C2EDD-B0A9-488A-8C4C-0BFF8095AE2B@mac.com> References: <9FAC4166-AAAB-4FB9-8EE4-E9DD645255FC@mac.com> <353C2EDD-B0A9-488A-8C4C-0BFF8095AE2B@mac.com> Message-ID: On Fri, Jul 21, 2023 at 3:27 PM Jeff Clites via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Oh no I take that back, it is talking about a specific pattern: > > >> Pattern match is redundant > >> In a case alternative: B -> ... > > But I do think a better complaint is that you don't need a case expression > there at all, but it seems like that's not actually what it's complaining > about. Hmm. > My take-away from all this is that, if a case branch can be determined *statically* (i.e., without applying any evaluation steps) not to match, then it is "redundant." If there are counterexamples to this take-away, though, please let me know! --Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsf at seereason.com Sat Jul 22 21:26:27 2023 From: dsf at seereason.com (David Fox) Date: Sat, 22 Jul 2023 14:26:27 -0700 Subject: [Haskell-cafe] Redundant/overlapping patterns? In-Reply-To: References: <9FAC4166-AAAB-4FB9-8EE4-E9DD645255FC@mac.com> <353C2EDD-B0A9-488A-8C4C-0BFF8095AE2B@mac.com> Message-ID: On Fri, Jul 21, 2023 at 5:14 PM Todd Wilson wrote: > On Fri, Jul 21, 2023 at 3:27 PM Jeff Clites via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > >> Oh no I take that back, it is talking about a specific pattern: >> >> >> Pattern match is redundant >> >> In a case alternative: B -> ... >> >> But I do think a better complaint is that you don't need a case >> expression there at all, but it seems like that's not actually what it's >> complaining about. Hmm. >> > > My take-away from all this is that, if a case branch can be determined > *statically* (i.e., without applying any evaluation steps) not to match, > then it is "redundant." If there are counterexamples to this take-away, > though, please let me know! > > --Todd > > At the risk of descending into bikeshedding, I think "redundant" applies to anything that can be safely removed, and it is widely used in the ghc error messages. Using different words like "unreachable" and "unnecessary" is distracting and doesn't confer any benefit that I can see. -------------- next part -------------- An HTML attachment was scrubbed... URL: From han.joosten.han at gmail.com Sun Jul 23 18:32:52 2023 From: han.joosten.han at gmail.com (Han Joosten) Date: Sun, 23 Jul 2023 20:32:52 +0200 Subject: [Haskell-cafe] developing using .devcontainer in vscode Message-ID: Hi Cafe, I am trying to set up a useful development container for an open source project I am working on. I have created an image on top of the official Haskell image, expecting a proper installation of ghcup, cabal, stack and hls. The Dockerfile looks like this: FROM haskell:8.10 ARG USERNAME=vscode ENV USERNAME=${USERNAME} \ USER_UID=1000 \ USER_GID=1000 \ DEBIAN_FRONTEND=noninteractive \ LANG=C.UTF8 \ WDIR=/home/${USERNAME} RUN apt-get update && \ apt-get upgrade -y && \ apt-get install -y git RUN groupadd --gid $USER_GID $USERNAME && \ useradd -ms /bin/bash -K MAIL_DIR=/dev/null --uid $USER_UID --gid $USER_GID -m $USERNAME && \ mkdir -p /etc/sudoers.d && \ echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME && \ chmod 0440 /etc/sudoers.d/$USERNAME USER ${USER_UID}:${USER_GID} WORKDIR ${WDIR} RUN stack update # Add just the .cabal file to capture dependencies COPY ./package.yaml ${WDIR}/package.yaml COPY ./stack.yaml ${WDIR}/stack.yaml # Docker will cache this command as a layer, freeing us up to # modify source code without re-installing dependencies # (unless one of the copied files changes!) RUN stack build --only-dependencies -j4 COPY . ${WDIR} ENV DEBIAN_FRONTEND=dialog ENTRYPOINT ["/bin/bash"] The above image is built and pushed to dockerhub. Then, in the vscode project, I have a .devcontainer directory with the following Dockerfile: FROM ampersandtarski/ampersand-devcontainer:latest ENV DEBIAN_FRONTEND=dialog ENTRYPOINT ["/bin/bash"] The idea is that all the building of the dependencies is already done in the first image. That takes a lot of time, so this is supposed to be a great timesaver (though the image itself is huge). However, when I open the project inside the container, I get the following error: [image: image.png] If I reload the window, I get the following errors: [image: image.png] Long story short, I am not sure how to use the official Haskell image for development in my project. I must be missing something. I have been trying lots of things, but without succes. I hope it is possible to have an image built on top of the official Haskell file that contains all prebuilt dependencies of my project. Are my expectations realistic? If so, what am I missing? Any help is much appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 7863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 13508 bytes Desc: not available URL: From leah at vuxu.org Mon Jul 24 12:15:13 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Mon, 24 Jul 2023 14:15:13 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2023-07-26 @ 19:30 Message-ID: <874jlt7bfy.fsf@vuxu.org> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, July 26 at Cafe Puck at 19h30, as the weather will be wet and cold. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can reserve enough seats! It is OK to add yourself to the nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/QEVV6sKxTm2DGwle Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From aeioudev at outlook.com Mon Jul 24 12:46:22 2023 From: aeioudev at outlook.com (aeiouaeiouaeiouaeiouaeiouaeiou) Date: Mon, 24 Jul 2023 15:46:22 +0300 Subject: [Haskell-cafe] Haskell GitLab abuse Message-ID: Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi everyone, I don't know where the best place to post about this issue is, so here goes. Recently I found that some Google results are bloated with malicious links from Haskell GitLab fork repositories. You can see for yourself: https://gitlab.haskell.org/search?repository_ref=master&scope=blobs&search=torrent+download [...] Content analysis details: (5.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters 1.3 HK_RANDOM_FROM From username looks random 0.0 HK_RANDOM_ENVFROM Envelope sender username looks random -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: aeiouaeiouaeiouaeiouaeiouaeiou Subject: Haskell GitLab abuse Date: Mon, 24 Jul 2023 15:46:22 +0300 Size: 15906 URL: From Graham.Hutton at nottingham.ac.uk Wed Jul 26 09:07:16 2023 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Wed, 26 Jul 2023 09:07:16 +0000 Subject: [Haskell-cafe] Call for Participation, Functional Software Architecture - FP in the Large Message-ID: <6F3294A4-A5E0-424B-90D3-1106ABC65163@nottingham.ac.uk> ====================================================================== *** FUNARCH 2023 -- CALL FOR PARTICIPATION *** The First ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 8th September 2023, Seattle, Washington, USA Co-located with ICFP 2023 https://www.functional-architecture.org/events/funarch-2023/ ====================================================================== BACKGROUND: The ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large aims to disseminate and enable the use of functional programming in the large and long-lived software projects. We specifically want: - To assemble a community interested in software architecture techniques and technologies specific to functional programming; - To identify, categorize, and document topics relevant to the field of functional software architecture; - To connect the functional programming community to the software architecture community to cross-pollinate between the two. We'd love for you to be part of this effort. Whatever your background, you're welcome at FUNARCH - to listen to talks, report on your experience, and interact with others that share our goals. See you at FUNARCH! REGISTRATION: You can register for the workshop via the registration page for the ICFP conference, but there's no need to also register for the conference. Reduced fees are available until 5th August. http://icfp23.sigplan.org/attending/registration OPENING TALK: Functional Programming in the Large - Status and Perspective Mike Sperber ACCEPTED SUBMISSIONS: A Software Architecture Based on Coarse-Grained Self-Adjusting Computations Stefan Wehr Crème de la Crem: Composable Representable Executable Machines Marco Perone and Georgios Karachalias Functional Shell and Reusable Components for Easy GUIs Ben Knoble and Bogdan Popa Phases in Software Architecture Jeremy Gibbons, Oisín Kidney, Tom Schrijvers and Nicolas Wu Stretching the Glasgow Haskell Compiler Jeffrey M. Young, Sylvain Henry and John Ericson Typed Design Patterns for the Functional Era Will Crichton Types that Change: The Extensible Type Design Pattern Ivan Perez PROGRAM CHAIRS: Mike Sperber Active Group, Germany Graham Hutton University of Nottingham, UK PROGRAM COMMITTEE: Joachim Breitner Germany Manuel Chakravarty Tweag & IOG, The Netherlands Ron Garcia University of British Columbia, Canada Debasish Ghosh LeadIQ, India Lars Hupel Giesecke+Devrient, Germany Andy Keep Meta, USA Shriram Krishnamurthi Brown University, USA Andres Löh Well-Typed, Germany Anil Madhavapeddy University of Cambridge, UK José Pedro Magalhães Standard Chartered, UK Simon Marlow Meta, UK Hannes Mehnert Robur, Germany Erik Meijer USA Ivan Perez KBR / NASA Ames Research Center, USA Stefanie Schirmer DuckDuckGo, Germany Perdita Stevens University of Edinburgh, UK Stefan Wehr Hochschule Offenburg, Germany Scott Wlaschin FPbridge, UK WORKSHOP VENUE: The workshop will be co-located with the ICFP 2023 conference at The Westin Seattle Hotel, Seattle, Washington, United States. ====================================================================== 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. From ifl21.publicity at gmail.com Fri Jul 28 06:28:22 2023 From: ifl21.publicity at gmail.com (Pieter Koopman) Date: Thu, 27 Jul 2023 23:28:22 -0700 Subject: [Haskell-cafe] IFL23 last Call for papers Message-ID: Important Dates Draft Paper Submission Deadline 31st July, 2023 Notification of Acceptance for Presentation 1st August, 2023 Early Registration Deadline 11th August, 2023 Late Registration Deadline 23rd August, 2023 IFL Symposium 29th - 31st August, 2023 Submission of Papers for Peer-Reviewed Proceedings 24th November, 2023 Notification of Acceptance 2nd February, 2024 Camera-ready Version 8th March, 2024 SCOPE AND TOPICS The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. You can find more information about the symposium on its oficial website . IFL 2023 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. See the call for papers in text format . Areas of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - abstract interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - embedded domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - industrial applications PAPER SUBMISSIONS Following IFL tradition, IFL 2023 will use a post-symposium review process to produce the formal proceedings. Before the symposium, authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that accepted draft papers are presented physically at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. As in previous years, we will try to have the papers that are accepted for the formal proceedings published in the International Conference Proceedings Series of the ACM Digital Library. This possibility will be confirmed as soon as possible. Reviewing is single blind. There will be at least 3 reviews per paper. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. Papers must use the ACM two columns conference format, which can be found here . (For LaTeX users, start your document with \documentclass[sigconf,screen,review]{acmart}.) All contributions must be written in English. Note that this format has a rather long but limited list of packages that can be used. Please make sure that your document adheres to this list. The page limit for papers is twelve pages (excluding references). Only papers that were presented at the IFL 2023 Symposium will be considered for publication. See the webpage for paper submissions. LOCATION IFL 2023 will be held physically in Braga, Portugal. For more information, click here . Registration information will be added as soon as possible. [image: beacon] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Jul 28 21:59:49 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 28 Jul 2023 17:59:49 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha1 is now available Message-ID: <87v8e3pui2.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeApplications` language extension [type-binders], allowing types to be bound in type declarations. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. 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. Happy compiling, ~ Ben [type-binders]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha1/docs/users_guide/9.8.1-notes.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new From bryan at haskell.foundation Mon Jul 31 08:00:07 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 31 Jul 2023 11:00:07 +0300 Subject: [Haskell-cafe] developing using .devcontainer in vscode In-Reply-To: References: Message-ID: Hello, Based on the README at https://github.com/haskell/docker-haskell, it looks like this image does not have GHCup installed on it. It probably should. Do you think you could contribute such a thing? The repo is also looking for maintainers: https://github.com/haskell/docker-haskell/issues/72 I myself may take an interest in eventually contributing to the repo in my HF DevOps role, but I won't have time in the near future. On Sun, 23 Jul 2023 at 21:33, Han Joosten wrote: > Hi Cafe, > > I am trying to set up a useful development container for an open source > project I am working on. I have created an image on top of the official > Haskell image, expecting a proper installation of ghcup, cabal, stack and > hls. The Dockerfile looks like this: > > FROM haskell:8.10 > > ARG USERNAME=vscode > > > ENV USERNAME=${USERNAME} \ > USER_UID=1000 \ > USER_GID=1000 \ > DEBIAN_FRONTEND=noninteractive \ > LANG=C.UTF8 \ > WDIR=/home/${USERNAME} > > RUN apt-get update && \ > apt-get upgrade -y && \ > apt-get install -y git > > RUN groupadd --gid $USER_GID $USERNAME && \ > useradd -ms /bin/bash -K MAIL_DIR=/dev/null --uid $USER_UID --gid > $USER_GID -m $USERNAME && \ > mkdir -p /etc/sudoers.d && \ > echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME && > \ > chmod 0440 /etc/sudoers.d/$USERNAME > > USER ${USER_UID}:${USER_GID} > > WORKDIR ${WDIR} > > RUN stack update > > # Add just the .cabal file to capture dependencies > COPY ./package.yaml ${WDIR}/package.yaml > COPY ./stack.yaml ${WDIR}/stack.yaml > > # Docker will cache this command as a layer, freeing us up to > # modify source code without re-installing dependencies > # (unless one of the copied files changes!) > RUN stack build --only-dependencies -j4 > > COPY . ${WDIR} > > ENV DEBIAN_FRONTEND=dialog > > ENTRYPOINT ["/bin/bash"] > > > The above image is built and pushed to dockerhub. Then, in the vscode > project, I have a .devcontainer directory with the following Dockerfile: > > FROM ampersandtarski/ampersand-devcontainer:latest > > ENV DEBIAN_FRONTEND=dialog > > ENTRYPOINT ["/bin/bash"] > > The idea is that all the building of the dependencies is already done in > the first image. That takes a lot of time, so this is supposed to be a > great timesaver (though the image itself is huge). > However, when I open the project inside the container, I get the following > error: > [image: image.png] > > If I reload the window, I get the following errors: > [image: image.png] > > Long story short, I am not sure how to use the official Haskell image for > development in my project. I must be missing something. I have been trying > lots of things, but without succes. I hope it is possible to have an image > built on top of the official Haskell file that contains all prebuilt > dependencies of my project. Are my expectations realistic? If so, what am I > missing? > Any help is much appreciated. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 7863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 13508 bytes Desc: not available URL: From bryan at haskell.foundation Mon Jul 31 10:28:07 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 31 Jul 2023 13:28:07 +0300 Subject: [Haskell-cafe] Haskell GitLab abuse In-Reply-To: References: Message-ID: Yeah, unfortunately we are aware of various attempts to abuse the GHC GitLab instance. I will delete this particular user, and sometime in the near future I'll take steps to systematically clean out any other lurking spam. On Mon, 24 Jul 2023 at 15:47, aeiouaeiouaeiouaeiouaeiouaeiou < aeioudev at outlook.com> wrote: > Spam detection software, running on the system "mail.haskell.org", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > @@CONTACT_ADDRESS@@ for details. > > Content preview: Hi everyone, I don't know where the best place to post > about > this issue is, so here goes. Recently I found that some Google results > are > bloated with malicious links from Haskell GitLab fork repositories. You > can > see for yourself: > https://gitlab.haskell.org/search?repository_ref=master&scope=blobs&search=torrent+download > [...] > > Content analysis details: (5.1 points, 5.0 required) > > pts rule name description > ---- ---------------------- > -------------------------------------------------- > 3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters > 1.3 HK_RANDOM_FROM From username looks random > 0.0 HK_RANDOM_ENVFROM Envelope sender username looks random > -0.0 SPF_HELO_PASS SPF: HELO matches SPF record > -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay > domain > -0.0 SPF_PASS SPF: sender matches SPF record > 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% > [score: 0.5000] > 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid > > The original message was not completely plain text, and may be unsafe to > open with some email clients; in particular, it may contain a virus, > or confirm that your address can receive spam. If you wish to view > it, it may be safer to save it to a file and open it with an editor. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifl21.publicity at gmail.com Mon Jul 31 12:14:51 2023 From: ifl21.publicity at gmail.com (Pieter Koopman) Date: Mon, 31 Jul 2023 05:14:51 -0700 Subject: [Haskell-cafe] IFL23 - Deadline extension - Symposium on Implementation and Application of Functional Languages Message-ID: Dear all, on special request, the deadline for draft paper submissions is extended until *August 7th*, 2023. *Scope* The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2022 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: * language concepts * type systems, type checking, type inferencing * compilation techniques * staged compilation * run-time function specialization * run-time code generation * partial evaluation * abstract interpretation * metaprogramming * generic programming * automatic program generation * array processing * concurrent/parallel programming * concurrent/parallel program execution * embedded systems * web applications * embedded domain specific languages * security * novel memory management techniques * run-time profiling performance measurements * debugging and tracing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * industrial applications *Submissions and peer-review* Following IFL tradition, IFL 2023 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that accepted draft papers are presented physically at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. Contributions submitted for the draft paper deadline must be between two and twelve pages long. For submission details, please consult the IFL 2023 website at https://ifl23.github.io/ . *Where* IFL 2023 will be held physically in Braga, Portugal, arranged by University of Minho. See the IFL 2023 website at https://ifl23.github.io/ for more information. [image: beacon] -------------- next part -------------- An HTML attachment was scrubbed... URL: