From simon at joyful.com Sun Sep 3 08:22:20 2023 From: simon at joyful.com (Simon Michael) Date: Sun, 3 Sep 2023 09:22:20 +0100 Subject: [Haskell-cafe] ANN: hledger 1.31 Message-ID: <24B34C92-9B68-4090-8D16-303FA28C8FF8@joyful.com> I'm pleased to announce hledger 1.31 ! Highlights: - In conversion transactions, costs and equity postings are matched more tolerantly. - The `print` command now more closely replicates the original journal amount styles, which is helpful when round-tripping / cleaning up journal files. - Multi-pivot - the --pivot option can now construct account names from multiple fields. Thank you release contributors Dmitry Astapov, Eric Mertens, Jay Neubrand, and Jonathan Dowland. - https://github.com/simonmichael/hledger/releases/1.31 - https://hledger.org/release-notes.html#hledger-1-31 - https://hledger.org/install What is hledger ? - Fast, reliable, free, multicurrency, double-entry, plain text accounting software for unix, mac, windows, and the web - Built around human-readable, version-controllable plain text files - Inspired by and largely compatible with Ledger CLI, convertible to and from Beancount - Written in Haskell for reliability and longevity. For help getting started or more info, see https://hledger.org and join our Matrix/IRC chat or mail list: https://hledger.org/support . Newcomers, experts, contributors, sponsors, feedback are welcome! For more about plain text accounting, see https://plaintextaccounting.org . Live well and prosper, -Simon From Graham.Hutton at nottingham.ac.uk Mon Sep 4 06:52:09 2023 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 4 Sep 2023 06:52:09 +0000 Subject: [Haskell-cafe] 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 *** If you are attending the ICFP conference in Seattle this week, please feel free to speak with Nicolas Wu if you have any questions about submitting for the special issue *** 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 zoran.bosnjak at via.si Tue Sep 5 14:53:47 2023 From: zoran.bosnjak at via.si (Zoran =?utf-8?Q?Bo=C5=A1njak?=) Date: Tue, 5 Sep 2023 14:53:47 +0000 (UTC) Subject: [Haskell-cafe] heterogeneous container smart constructor question Message-ID: <1914184986.1142.1693925627889.JavaMail.zimbra@via.si> Dear haskellers, I am trying to add some type safety to the program in the following situation: There are some distinct 'Item t' types which come in groups. That is: 'EList' container can contain either: - items 0,1 - items 0,1,2,3 - items 0,1,2,3,4,5,6 All other combinations (like items 0,1,2) are invalid and shall be rejected by compiler. The 'EList' implementation (see below) seems to have this property. In addition, I would like to define a smart constructor (mkEList), to simplify EList construction from some linear (no groups) IList type. In other words, mkEList shall slice IList to proper groups. I am aware that I need to use a type class / type families for this. I have tried several approaches, but ghc was not happy with any. What is the correct implementation of mkEList? Here is a sample code and the intended usage: -- (sample build-test.hs) import GHC.TypeLits data Item (t :: Nat) = Item -- List/group of items data IList (ts :: [Nat]) where INil :: IList '[] ICons :: Item t -> IList ts -> IList (t ': ts) nil :: IList '[] nil = INil infixr 5 &: (&:) :: Item t -> IList ts -> IList (t : ts) (&:) = ICons -- Extended list of groups data EList (ts :: [Nat]) (tss :: [[Nat]]) where EList :: IList ts1 -> Maybe (EList ts2 tss) -> EList ts1 (ts2 ': tss) instance Eq (EList ts tss) -- Manual test type T1 = '[0, 1] type T2 = '[ '[2, 3], '[4, 5, 6], '[] ] test1 :: EList T1 T2 test1 = EList (Item @0 &: Item @1 &: nil) Nothing test2 :: EList T1 T2 test2 = EList (Item @0 &: Item @1 &: nil) (Just (EList (Item @2 &: Item @3 &: nil) Nothing)) test3 :: EList T1 T2 test3 = EList (Item @0 &: Item @1 &: nil) (Just (EList (Item @2 &: Item @3 &: nil) (Just (EList (Item @4 &: Item @5 &: Item @6 &: nil) Nothing)))) -- Intended usage -- | Helper function or class method :: IList ? -> EList ? ? mkEList :: a mkEList = undefined el1 :: EList T1 T2 el1 = mkEList ( Item @0 &: Item @1 &: nil) el2 :: EList T1 T2 el2 = mkEList ( Item @0 &: Item @1 &: Item @2 &: Item @3 &: nil) el3 :: EList T1 T2 el3 = mkEList ( Item @0 &: Item @1 &: Item @2 &: Item @3 &: Item @4 &: Item @5 &: Item @6 &: nil) check :: Bool -- expecting True check = and [el1 == test1, el2 == test2, el3 == test3] -- (end of sample) regards, Zoran From lemming at henning-thielemann.de Tue Sep 5 15:09:48 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 5 Sep 2023 17:09:48 +0200 (CEST) Subject: [Haskell-cafe] heterogeneous container smart constructor question In-Reply-To: <1914184986.1142.1693925627889.JavaMail.zimbra@via.si> References: <1914184986.1142.1693925627889.JavaMail.zimbra@via.si> Message-ID: <597b7ee-a0a5-c687-79a1-869476be5098@henning-thielemann.de> On Tue, 5 Sep 2023, Zoran Bošnjak wrote: > Dear haskellers, > I am trying to add some type safety to the program in the following situation: > > There are some distinct 'Item t' types which come in groups. That is: > 'EList' container can contain either: > - items 0,1 > - items 0,1,2,3 > - items 0,1,2,3,4,5,6 What about a solution in Haskell 98: (T0, T1, Maybe (T2, T3, Maybe (T4, T5, T6))) or with custom data types: data ItemsA = ItemsA T0 T1 (Maybe ItemsB) data ItemsB = ItemsB T2 T3 (Maybe ItemsC) data ItemsC = ItemsC T4 T5 T6 ? From chpatrick at gmail.com Tue Sep 5 15:40:59 2023 From: chpatrick at gmail.com (Patrick Chilton) Date: Tue, 5 Sep 2023 17:40:59 +0200 Subject: [Haskell-cafe] heterogeneous container smart constructor question In-Reply-To: <1914184986.1142.1693925627889.JavaMail.zimbra@via.si> References: <1914184986.1142.1693925627889.JavaMail.zimbra@via.si> Message-ID: data MyContainer = MyContainer1 Item0 Item1 | MyContainer2 Item0 Item1 Item2 Item3 | MyContainer3 Item0 Item1 Item2 Item3 Item4 Item5 Item6 On Tue, Sep 5, 2023 at 4:54 PM Zoran Bošnjak wrote: > Dear haskellers, > I am trying to add some type safety to the program in the following > situation: > > There are some distinct 'Item t' types which come in groups. That is: > 'EList' container can contain either: > - items 0,1 > - items 0,1,2,3 > - items 0,1,2,3,4,5,6 > > All other combinations (like items 0,1,2) are invalid and shall be > rejected by compiler. > The 'EList' implementation (see below) seems to have this property. > > In addition, I would like to define a smart constructor (mkEList), to > simplify EList construction from some linear (no groups) IList type. In > other words, mkEList shall slice IList to proper groups. I am aware that I > need to use a type class / type families for this. I have tried several > approaches, but ghc was not happy with any. > > What is the correct implementation of mkEList? > > Here is a sample code and the intended usage: > > -- (sample build-test.hs) > import GHC.TypeLits > > data Item (t :: Nat) = Item > > -- List/group of items > data IList (ts :: [Nat]) where > INil :: IList '[] > ICons :: Item t -> IList ts -> IList (t ': ts) > > nil :: IList '[] > nil = INil > > infixr 5 &: > (&:) :: Item t -> IList ts -> IList (t : ts) > (&:) = ICons > > -- Extended list of groups > data EList (ts :: [Nat]) (tss :: [[Nat]]) where > EList :: IList ts1 -> Maybe (EList ts2 tss) -> EList ts1 (ts2 ': tss) > > instance Eq (EList ts tss) > > -- Manual test > > type T1 = '[0, 1] > type T2 = '[ '[2, 3], '[4, 5, 6], '[] ] > > test1 :: EList T1 T2 > test1 = EList (Item @0 &: Item @1 &: nil) Nothing > > test2 :: EList T1 T2 > test2 = EList (Item @0 &: Item @1 &: nil) > (Just (EList (Item @2 &: Item @3 &: nil) Nothing)) > > test3 :: EList T1 T2 > test3 = EList (Item @0 &: Item @1 &: nil) > (Just (EList (Item @2 &: Item @3 &: nil) > (Just (EList (Item @4 &: Item @5 &: Item @6 &: nil) Nothing)))) > > -- Intended usage > > -- | Helper function or class method :: IList ? -> EList ? ? > mkEList :: a > mkEList = undefined > > el1 :: EList T1 T2 > el1 = mkEList > ( Item @0 > &: Item @1 > &: nil) > > el2 :: EList T1 T2 > el2 = mkEList > ( Item @0 > &: Item @1 > &: Item @2 > &: Item @3 > &: nil) > > el3 :: EList T1 T2 > el3 = mkEList > ( Item @0 > &: Item @1 > &: Item @2 > &: Item @3 > &: Item @4 > &: Item @5 > &: Item @6 > &: nil) > > check :: Bool -- expecting True > check = and [el1 == test1, el2 == test2, el3 == test3] > -- (end of sample) > > 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 Tue Sep 5 18:23:02 2023 From: zoran.bosnjak at via.si (Zoran =?utf-8?Q?Bo=C5=A1njak?=) Date: Tue, 5 Sep 2023 18:23:02 +0000 (UTC) Subject: [Haskell-cafe] heterogeneous container smart constructor question In-Reply-To: <597b7ee-a0a5-c687-79a1-869476be5098@henning-thielemann.de> References: <1914184986.1142.1693925627889.JavaMail.zimbra@via.si> <597b7ee-a0a5-c687-79a1-869476be5098@henning-thielemann.de> Message-ID: <258200824.1297.1693938182644.JavaMail.zimbra@via.si> The example I gave was simplified. A real problem contains several other complications which makes this simple solution not practical. There will be some generated code with several dozen of such cases (schemas). I want to keep them all in one GADT, such that I can use common code to manipulate them. This is why EList was introduced for 'Extended' container. Another problem comes from some other container types which I did not mention before. I already have mapping from IList to other container types (not mentioned in my mail), like grp1 :: Group '[0, 1, ...] grp1 = mkGroup (Item @0 &: Item @1 ... &: nil) In my case, the IList seems like universal data type to construct other items (as long as types are properly aligned). It's very convenient from application writer perspective. So, if at all possible, I would like to map from IList to EList. ----- Original Message ----- From: "Henning Thielemann" To: "Zoran Bošnjak" Cc: "haskell-cafe" Sent: Tuesday, September 5, 2023 5:09:48 PM Subject: Re: [Haskell-cafe] heterogeneous container smart constructor question On Tue, 5 Sep 2023, Zoran Bošnjak wrote: > Dear haskellers, > I am trying to add some type safety to the program in the following situation: > > There are some distinct 'Item t' types which come in groups. That is: > 'EList' container can contain either: > - items 0,1 > - items 0,1,2,3 > - items 0,1,2,3,4,5,6 What about a solution in Haskell 98: (T0, T1, Maybe (T2, T3, Maybe (T4, T5, T6))) or with custom data types: data ItemsA = ItemsA T0 T1 (Maybe ItemsB) data ItemsB = ItemsB T2 T3 (Maybe ItemsC) data ItemsC = ItemsC T4 T5 T6 ? From david at haskell.foundation Tue Sep 5 20:03:03 2023 From: david at haskell.foundation (David Christiansen) Date: Tue, 5 Sep 2023 22:03:03 +0200 Subject: [Haskell-cafe] The Haskell Foundation is seeking a new Executive Director Message-ID: Dear Cafe, I just realized that we didn't yet post this here - apologies! I'll be stopping as ED of the Haskell Foundation at the end of the month, because I got an offer to go back to software development and work on a combination of technologies that I personally find extremely interesting (dependent types, procedural hygienic macros, language embedding, software verification, documentation and tools). It wasn't an easy decision to make, but I won't be disappearing from the world of pure functional programming. This means we need a new ED! You can see details here: https://haskell.foundation/careers/executive-director.html Every application received by the 29th will receive full consideration, but the board will continue taking applications until the new ED has been found. Until 22 September, I have time reserved to meet with people who are interested, but unsure about whether the role is a good fit. I myself have had these concerns - it was my first job not doing research or software development since I was 23 years old, after all. I'm happy to have an honest discussion about the job, how I did it, how someone else with different strengths might do it, what my daily life is like and the constraints that give rise to that, and so forth. Just let me know if you're interested. My canonical farewell post is here: https://discourse.haskell.org/t/an-opportunity-that-i-couldnt-pass-up/7485 Thanks for your support! I'll see you around. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Sep 5 21:40:50 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 5 Sep 2023 23:40:50 +0200 (CEST) Subject: [Haskell-cafe] heterogeneous container smart constructor question In-Reply-To: <258200824.1297.1693938182644.JavaMail.zimbra@via.si> References: <1914184986.1142.1693925627889.JavaMail.zimbra@via.si> <597b7ee-a0a5-c687-79a1-869476be5098@henning-thielemann.de> <258200824.1297.1693938182644.JavaMail.zimbra@via.si> Message-ID: <49f0187-6ea-d85c-a437-c0d4c33f613@henning-thielemann.de> On Tue, 5 Sep 2023, Zoran Bošnjak wrote: > The example I gave was simplified. A real problem contains several other > complications which makes this simple solution not practical. I have the package non-empty, that provides the types NonEmpty.T, Optional.T and Empty.T. With them you can encode any pattern of allowed list lengths. NonEmpty means "list length forbidden", Optional means "list length permitted", Empty means "maximum allowed length". In your example length 2, 5, 8 were allowed, so the bit pattern of allowed lengths is 001001001, which you can encode by type B0 = NonEmpty.T type B1 = Optional.T type SpecialList = B0 (B0 (B1 (B0 (B0 (B1 (B0 (B0 (B1 Empty.T)))))))) https://hackage.haskell.org/package/non-empty Maybe you can adapt this idea to your problem. From meng.wang at bristol.ac.uk Thu Sep 7 07:52:03 2023 From: meng.wang at bristol.ac.uk (Meng Wang) Date: Thu, 7 Sep 2023 07:52:03 +0000 Subject: [Haskell-cafe] CFP, PEPM 2024 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation Message-ID: Dear Haskellers, Gabriele and I are organising PEPM this year. Over the years, PEPM has grown into a conference of general PL topics and Haskell/FP is strongly represented. We look forward to receiving your submissions. Best regards, Gabriele Keller (Utrecht University, Netherlands) Meng Wang (University of Bristol, UK) ---------------------------------------------------------------------------------------------------------- ** ** CALL FOR PAPERS ** ** PEPM at POPL 2024 ** Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION ** 16th of January 2024, London, United Kingdom ** ** Submission Deadline: ** 18 October 2023 ** ** https://popl24.sigplan.org/home/pepm-2024 ** https://easychair.org/conferences/?conf=pepm24 ** ----------------------------------------------------------------------------------------------------------- ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2024 =============================================================================== * Website : https://popl24.sigplan.org/home/pepm-2024 * Time : 16th January 2024 * Place : London, United Kingdom (co-located with POPL 2024) The ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (PEPM) has a history going back to 1991 and has been co-located with POPL every year since 2006. It originated with the discoveries of useful automated techniques for evaluating programs with only partial input. Over the years, the scope of PEPM has expanded to include a variety of research areas centred around the theme of semantics-based program manipulation — the systematic exploitation of treating programs not only as subjects to black-box execution but also as data structures that can be generated, analysed, and transformed while establishing or maintaining important semantic properties. Scope ----- In addition to the traditional PEPM topics (see below), PEPM 2024 welcomes submissions in new domains, in particular: * Semantics based and machine-learning based program synthesis and program optimisation. * Modelling, analysis, and transformation techniques for distributed and concurrent protocols and programs, such as session types, linear types, and contract specifications. More generally, topics of interest for PEPM 2024 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing new theories and applications related to semantics-based program manipulation in general. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme co-chairs, Gabriele Keller (g.k.keller at uu.nl) and Meng Wang (meng.wang at bristol.ac.uk). Submission categories and guidelines ------------------------------------ Three kinds of submissions will be accepted: * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance, and clarity. Regular research papers must not exceed 12 pages. * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial, and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages. * Talk Proposals may propose lectures about topics of interest for PEPM, existing work representing relevant contributions, or promising contributions that are not mature enough to be proposed as papers of the other categories. Talk Proposals must not exceed 2 pages. References and appendices are not included in page limits. Appendices may not necessarily be read by reviewers. Both kinds of submissions should be typeset using the two-column ‘sigplan’ sub-format of the new ‘acmart’ format available at: http://sigplan.org/Resources/Author/ and submitted electronically via EasyChair: https://easychair.org/conferences/?conf=pepm24 Reviewing will be single-blind. Submissions are welcome from PC members (except the two co-chairs). Accepted regular research papers will appear in formal proceedings published by ACM, and be included in the ACM Digital Library. Accepted short papers do not constitute formal publications and will not appear in the proceedings. At least one author of each accepted contribution must attend the workshop (physically or virtually) and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Important dates --------------- * Paper submission deadline : **Wednesday 18th October 2023 (AoE)** * Author notification : **Wednesday 15th November 2023 (AoE)** * Workshop : **Tuesday 16th January 2024** Best paper award ---------------- PEPM 2024 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Programme committee ------------------- * Chairs: Gabriele Keller (Utrecht University, Netherlands) Meng Wang (University of Bristol, UK) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ufarooq at lsu.edu Mon Sep 11 22:16:35 2023 From: ufarooq at lsu.edu (Umar Farooq) Date: Mon, 11 Sep 2023 22:16:35 +0000 Subject: [Haskell-cafe] OOPSLA 2024: Round 1 Call for Papers Message-ID: ======================================================================== PACMPL Issue OOPSLA 2024 Call for Papers OOPSLA 2024 will be held as part of The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'24) October 20-25, 2024, Pasadena, California, United States https://2024.splashcon.org/track/splash-2024-oopsla ======================================================================== ### Important dates #### ROUND 1: Submission Deadline: Fri Oct 20, 2023 Author Response: Mon Dec 11 - Wed Dec 13, 2023 Author Notification: Fri Dec 22, 2023 Artifact Submission: Fri Jan 5, 2024 Artifact kick-tires: Sat Jan 6 - Fri Jan 19, 2024 Submission of Revisions: Sun Feb 11, 2024 Author Notification of Revisions: Sat Feb 24, 2024 Artifact Notification: Fri Mar 1, 2024 Camera Ready: Fri Mar 8, 2024 #### ROUND 2: Submission Deadline: Fri Apr 5, 2024 Author Response: Mon Jun 3 - Wed Jun 5, 2024 Author Notification: Fri Jun 21, 2024 Artifact Submission: Fri Jul 5, 2024 Artifact kick-tires: Sat Jul 6 - Fri Jul 19, 2024 Submission of Revisions: Sun Aug 4, 2024 Author Notification of Revisions: Sun Aug 18, 2024 Artifact Notification: Fri Aug 23, 2024 Camera Ready: Sun Sep 1, 2024 Papers accepted at either of the rounds will be published in the 2024 volume of PACMPL(OOPSLA) and invited to be presented at the SPLASH conference in October 2024. ### Scope The OOPSLA issue of the Proceedings of the ACM on Programming Languages (PACMPL) welcomes papers focusing on all practical and theoretical investigations of programming languages, systems and environments. Papers may target any stage of software development, including requirements, modelling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, and reuse of software systems. Contributions may include the development of new tools, techniques, principles, and evaluations. #### Review Process PACMPL(OOPSLA) has two rounds of reviewing with submission deadlines around October and April each year. As you submit your paper you will receive around three reviews and an opportunity to provide an author response that will be read and addressed by the reviewers in the final decision outcome summary. There are 5 possible outcomes at the end of the round: *Accept*: Your paper will appear in the upcoming volume of PACMPL (OOPSLA). *Conditional Accept*: You will receive a list of required revisions that you will need to address. You must submit a revised paper, a clear explanation of how your revision addresses these comments, and "if possible" a diff of the PDF as supplementary material. Assuming you meet the listed requirements, after further review by the same reviewers, your paper will very likely be accepted. This process *has to be completed within two months of the initial decision* for the paper to be accepted, so we encourage timely turnaround in case revisions take more than one cycle to be accepted. *Minor Revision*: The reviewers have concerns that go beyond what can be enumerated in a list. Therefore, while you may receive a list of revisions suggested by the reviewers, this will not necessarily be comprehensive. You will have the opportunity to resubmit your revised paper and have it re-reviewed by the same reviewers, which may or may not result in your paper's acceptance. When you resubmit, you should clearly explain how the revisions address the comments of the reviewers, by including a document describing the changes and "if possible" a diff of the PDF as supplementary material. This process *has to be completed within two months of the initial decision* for the paper to be accepted in the current round, so we encourage timely turnaround in case revisions take more than one cycle to be accepted. *Major Revision*: You will receive a list of revisions suggested by the reviewers. Papers in this category are *invited to submit a revision to the next round of submissions* with a specific set of expectations to be met. When you resubmit, you should clearly explain how the revisions address the comments of the reviewers, by including a document describing the changes and "if possible" a diff of the PDF as supplementary material. The revised paper will be re-evaluated in the next round. Resubmitted papers will retain the same reviewers throughout the process to the extent possible. *Reject*: Rejected papers will not be included in the upcoming volume of PACMPL(OOPSLA). Papers in this category are not guaranteed a review if resubmitted less than one year from the date of the original submission. A paper will be judged to be a resubmission if it is substantially similar to the original submission. The Chairs will decide whether or not a paper is a resubmission of the same work. ### Submissions Submitted papers must be at most **23 pages** in 10 point font. There is no page limit on references. No appendices are allowed on the main paper, instead authors can upload supplementary material with no page or content restrictions, but reviewers may choose to ignore it. Submissions must adhere to the "ACM Small" template available from [the ACM](http://www.acm.org/publications/authors/submissions). Papers are expected to use author-year citations. Author-year citations may be used as either a noun phrase, such as "The lambda calculus was originally conceived by Church (1932)", or a parenthetic phase, such as "The lambda calculus (Church 1932) was intended as a foundation for mathematics". PACMPL uses double-blind reviewing. Authors' identities are only revealed if a paper is accepted. Papers must 1. omit author names and institutions, 2. use the third person when referencing your work, 3. anonymise supplementary material. Nothing should be done in the name of anonymity that weakens the submission; see the DBR FAQ. When in doubt, contact the Review Committee Chairs. Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by [SIGPLAN's Republication Policy](http://www.sigplan.org/Resources/Policies/Republication). Submitters should also be aware of [ACM's Policy and Procedures on Plagiarism](http://www.acm.org/publications/policies/plagiarism_policy). Submissions are expected to comply with the [ACM Policies for Authorship](https://www.acm.org/publications/authors/information-for-authors). #### Artifacts Authors should indicate with their initial submission if an artifact exists, describe its nature and limitations, and indicate if it will be submitted for evaluation. Accepted papers that fail to provide an artifact will be requested to explain the reason they cannot support replication. It is understood that some papers have no artifacts. Please note that the artifact submission deadline will be following closely the paper submission deadline so make sure you check the Artifact Call as soon as you submit your paper to PACMPL(OOPSLA). ##### Data-Availability Statement To help readers find data and software, OOPSLA recommends adding a section just before the references titled Data-Availability Statement. If the paper has an artifact, cite it here. If there is no artifact, this section can explain how to obtain relevant code. The statement does not count toward the OOPSLA 2024 page limit. It may be included in the submitted paper; in fact we encourage this, even if the DOI is not ready yet. Example: \section{Conclusion} .... \section*{Data-Availability Statement} The software that supports~\cref{s:design,s:evaluation} is available on Software Heritage~\cite{artifact-swh} and Zenodo~\cite{artifact-doi}. \begin{acks} .... #### Expert PC Members During the submission, we will ask you to list up to 3 non-conflicted PC members who you think are experts on the topic of this submission, starting with the most expert. This list will not be used as an input during the paper assignment and it will not be visible to the PC. It may be used by the PC Chair and Associate Chairs for advice on external experts if the paper lacks expert reviews. ### Publication PACMPL is a Gold Open Access journal, all papers will be freely available to the public. Authors can voluntarily cover the article processing charge ($400 USD), but payment is not required. The official publication date is the date the journal is made available in the ACM Digital Library. The journal issue and associated papers may be published up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. By submitting your article to an ACM Publication, you are acknowledging that you and your co-authors are subject to all [ACM Publications Policies](https://www.acm.org/publications/policies), including ACM’s [new Publications Policy on Research Involving Human Participants and Subjects](https://www.acm.org/publications/policies/research-involving-human-participants-and-subjects). Alleged violations of this policy or an ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy. Please ensure that you and your co-authors obtain [an ORCID ID](https://orcid.org/register), so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start and we have recently made a [commitment to collect ORCID IDs from all of our published authors](https://authors.acm.org/author-resources/orcid-faqs). We are committed to improving author discoverability, ensuring proper attribution and contributing to ongoing community efforts around name normalization; your ORCID ID will help in these efforts. The ACM Publications Board has recently updated the ACM Authorship Policy in several ways: - Addressing the use of generative AI systems in the publications process - Clarifying criteria for authorship and the responsibilities of authors - Defining prohibited behaviour, such as gift, ghost, or purchased authorship - Providing a linked FAQ explaining the rationale for the policy and providing additional details You can find the updated policy here: [https://www.acm.org/publications/policies/new-acm-policy-on-authorship](https://www.acm.org/publications/policies/new-acm-policy-on-authorship) ##### Review Committee Review Committee Chairs: Alex Potanin, Australian National University, Australia Bor-Yuh Evan Chang, University of Colorado Boulder, USA Review Committee Associate Chairs: Anders Møller, Aahrus University, Denmark Lingming Zhang, UIUC, USA Review Committee: Aleksandar Nanevski, IMDEA Software Institute, Spain Alex Summers, University of British Columbia, Canada Alexandra Bugariu, ETH Zurich, Switzerland Ana Milanova, Rensselaer Polytechnic Institute, USA Andreas Zeller, CISPA Helmholtz Center for Information Security, Germany Anitha Gollamudi, UMass, USA Ankush Desai, AWS, USA Ashish Tiwari, Microsoft Research, USA Ben Hermann, TU Dortmund, Germany Ben Titzer, CMU, USA Benjamin Delaware, Purdue University, USA Bernardo Toninho, Universidade Nova de Lisboa, Portugal Bruno C. d. S. Oliveira, U. Hong Kong, Hong Kong Burcu Kulahcioglu Ozkan, Delft University of Technology, The Netherlands Casper Bach Poulsen, Delft University of Technology, Netherlands Colin Gordon, Drexel University, USA Corina Pasarenau, NASA, USA Cyrus Omar, University of Michigan, USA Damien Zufferey, Sonar Source, Switzerland Dana Drachsler Cohen, Technion, Israel David Darais, Galois, USA David Pearce, ConsenSys, New Zealand Di Wang, Peking University, China Emma Söderberg, Lund University, Sweden Emma Tosch, Northeastern University, USA Fabian Muehlboeck, Australian National University, Australia Fei He, Tsinghua University, China Filip Niksic, Google, USA Fredrik Kjolstad, Stanford University, USA Guido Salvaneschi, University of St. Gallen, Switzerland Hila Peleg, Technion, Israel Jiasi Shen, The Hong Kong University of Science and Technology, China (Hong Kong) Jonathan Bell, Northeastern University, USA Jonathan Brachthäuser, University of Tübingen, Germany Joseph Tassarotti, New York University, USA Justin Hsu, Cornell University, USA Karine Even-Mendoza, King's College London, UK Kenji Maillard, Inria Rennes, France Matthew Flatt, U. Utah, USA Matthew Parkinson, Microsoft, UK Max Schaefer, GitHub, UK Michael Coblenz, UCSD, USA Milos Gligoric, UT Austin, USA Minseok Jeon, Korea University, Korea Mohamed Faouzi Atig, Uppsala University, Sweden Owolabi Legunsen, Cornell University, USA Pamela Zave, AT&T Laboratories, USA Pavel Panchekha, University of Utah, USA Rahul Gopinath, University of Sydney, Australia Rajiv Gupta, UC Riverside, USA Saman Amarasinghe, MIT, USA Santosh Pande, Georgia Institute of Technology, USA Sean Treichler, NVIDIA, USA Shachar Itzhaky, Technion, Israel Shaz Qadeer, Facebook, USA Sheng Chen, University of Louisiana at Lafayette, USA Shigeru Chiba, University of Tokyo, Japan Shriram Krishnamurthi, Brown University, USA Sreepathi Pai, University of Rochester, USA Stefan Brunthaler, University of the Federal Armed Forces in Munchen, Germany Steve Blackburn, Google, Australia Subhajit Roy, IIT Kanpur, India Sukyoung Ryu, KAIST, Korea Swarnendu Biswas, IIT Kanpur, India Thanh Vu Nguyen, George Mason University, USA Tiark Rompf, Purdue, USA Tien Nguyen, University of Texas at Dallas, USA Tomas Petricek, Charles University, Czech Republic Umut Acar, CMU, USA Wei Le, Iowa State, USA Wei Zhang , Meta, USA Xiaokang Qiu, Purdue University, USA Yingfei Xiong, Peking University, China Yizhou Zhang, University of Waterloo, Canada Youyou Cong, Tokyo Institute of Technology, Japan Yu David Liu, Binghamton, USA Yu Feng, UCSB, USA Yuepeng Wang, Simon Fraser University, Canada ##### Artifact Evaluation Committee Artifact Evaluation Committee Chairs: Guillaume Baudart, Inria - École normale supérieure, France Sankha Narayan Guria, University of Kansas, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at alcidesfonseca.com Tue Sep 12 13:29:52 2023 From: me at alcidesfonseca.com (Alcides Fonseca) Date: Tue, 12 Sep 2023 14:29:52 +0100 Subject: [Haskell-cafe] SPLASH 2023 Call for Participation Message-ID: ====================================================================== Call For Participation ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'23) October 22-27, 2023, Cascais, Portugal https://2023.splashcon.org/ Follow us on Twitter @splashcon ====================================================================== The ACM SIGPLAN conference on Systems, Programming, Languages and Applications: Software for Humanity (SPLASH) embraces all aspects of software construction and delivery to make it the premier conference at the intersection of programming, languages, and software engineering. ====================================================================== # Participation ====================================================================== The registration information, including the link to registration form is available at https://2023.splashcon.org/attending/Registration ====================================================================== # List of Keynotes/Invited Talks ====================================================================== SPLASH will feature three keynotes: Amal Ahmed, Northeastern University, USA Dimitrios Vytiniotis, DeepMind, UK Joe Hellerstein, UC Berkeley, USA SPLASH co-located events include a number of speakers: Andreas Rossberg, Independent, Germany (MPLR) Manuel Hermenegildo, IMDEA, Spain (LOPSTR) Maribel Fernández, King's College London, UK (PPDP+LOPSTR) Delia Kesner, Université Paris Cité, France (PPDP) Daniel Kaestner, AbsInt, Germany (SAS) Gagandeep Singh, University of Illinois Urbana-Champaign, USA (SAS) Bor-Yuh Evan Chang, University of Colorado Boulder & Amazon, USA (SAS) Loris D’Antoni, University of Wisconsin, Madison, USA (SAS) ====================================================================== # List of Events ====================================================================== ** OOPSLA Research Papers ** Papers that address any aspect of software development are welcome, including requirements, modelling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, reuse, replacement, and retirement of software systems. Papers may address these topics in a variety of ways, including new tools (such as languages, program analyses, and runtime systems), new techniques (such as methodologies, design processes, code organization approaches, and management techniques), and new evaluations (such as formalisms and proofs, corpora analyses, user studies, and surveys). ** Onward! Research Papers ** Onward! is a premier multidisciplinary conference focused on everything to do with programming and software: including processes, methods, languages, communities, and applications. Onward! is more radical, more visionary, and more open than other conferences to ideas that are well-argued but not yet proven. We welcome different ways of thinking about, approaching, and reporting on programming language and software engineering research. ** Onward! Essays ** Onward! Essays conference is looking for clear and compelling pieces of writing about topics important to the software community construed broadly. An essay can be an exploration of a topic, its impact, or the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps that by which the author reached an understanding of such a topic. The subject area should be interpreted broadly and can include the relationship of software to human endeavours, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. ** PLMW at SPLASH ** The SPLASH 2023 Programming Languages Mentoring Workshop encourages graduate students (PhD and MSc) and senior undergraduate students to pursue research in programming languages. This workshop will provide mentoring sessions on how to prepare for and thrive in graduate school and in a research career, focusing both on cutting-edge research topics and practical advice. The workshop brings together leading researchers and junior students in an inclusive environment in order to help welcome newcomers to our field of programming languages research. The workshop will show students the many paths that they might take to enter and contribute to our research community. ====================================================================== ** Workshops ** ====================================================================== **** CONFLANG **** CONFLANG is a workshop on the design, the theory, the practice and the future evolution of configuration languages. It aims to gather the emerging community in this area in order to engage in fruitful interactions, to share ideas, results, opinions, and experiences on languages for configuration. Correct configuration is an actual industrial problem, and would greatly benefit from existing and ongoing academic research. Dually, this is a space with new challenges to overcome and new directions to explore, which is a great opportunity to confront new ideas with large-scale production. **** FTSCS **** The aim of this workshop is to bring together researchers and engineers who are interested in the application of formal and semi-formal methods to improve the quality of safety-critical computer systems. FTSCS strives to promote research and development of formal methods and tools for industrial applications, and is particularly interested in industrial applications of formal methods. **** HATRA **** Programming language designers seek to provide strong tools to help developers reason about their programs. For example, the formal methods community seeks to enable developers to prove correctness properties of their code, and type system designers seek to exclude classes of undesirable behavior from programs. The security community creates tools to help developers achieve their security goals. In order to make these approaches as effective as possible for developers, recent work has integrated approaches from human-computer interaction research into programming language design. This workshop brings together programming languages, software engineering, security, and human-computer interaction researchers to investigate methods for making languages that provide stronger safety properties more effective for programmers and software engineers. **** IWACO **** Many techniques have been introduced to describe and reason about stateful programs, and to restrict, analyze, and prevent aliases. These include various forms of ownership types, capabilities, separation logic, linear logic, uniqueness, sharing control, escape analysis, argument independence, read-only references, linear references, effect systems, and access control mechanisms. These tools have found their way into type systems, compilers and interpreters, runtime systems and bug-finding tools. Their immediate practical relevance is self-evident from the popularity of Rust, a programming language built around reasoning about aliasing and ownership to enable static memory management and data race freedom, voted the "most beloved" language in the annual Stack Overflow Developer Survey seven times in a row. **** LIVE **** Programming is cognitively demanding, and too difficult. LIVE is a workshop exploring new user interfaces that improve the immediacy, usability, and learnability of programming. Whereas PL research traditionally focuses on programs, LIVE focuses more on the activity of programming. Our goal is to provide a supportive venue where early-stage work receives constructive criticism. Whether graduate students or tenured faculty, researchers need a forum to discuss new ideas and get helpful feedback from their peers. Towards that end, we will allot about ten minutes for discussion after every presentation. **** PAINT **** Programming environments that integrate tools, notations, and abstractions into a holistic user experience can provide programmers with better support for what they want to achieve. These programming environments can create an engaging place to do new forms of informational work - resulting in enjoyable, creative, and productive experiences with programming. In the workshop on Programming Abstractions and Interactive Notations, Tools, and Environments (PAINT), we want to discuss programming environments that support users in working with and creating notations and abstractions that matter to them. We are interested in the relationship between people centric notations and general-purpose programming languages and environments. How do we reflect the various experiences, needs, and priorities of the many people involved in programming — whether they call it that or not? **** PLF **** Applications supporting multi-device are ubiquitous. While most of the distributed applications that we see nowadays are cloud-based, avoiding the cloud can lead to privacy and performance benefits for users and operational and cost benefits for companies and developers. Following this idea, Local-First Software runs and stores its data locally while still allowing collaboration, thus retaining the benefits of existing collaborative applications without depending on the cloud. Many specific solutions already exist: operational transformation, client-side databases with eventually consistent replication based on CRDTs, and even synchronization as a service provided by commercial offerings, and a vast selection of UI design libraries. However, these solutions are not integrated with the programming languages that applications are developed in. Language based solutions related to distribution such as type systems describing protocols, reliable actor runtimes, data processing, machine learning, etc., are designed and optimized for the cloud not for a loosely connected set of cooperating devices. This workshop aims at bringing the issue to the attention of the PL community, and accelerating the development of suitable solutions for this area. **** REBELS **** Reactive programming and event-based programming are two closely related programming styles that are becoming ever more important with the advent of advanced HPC technology and the ever increasing requirement for our applications to run on the web or on collaborating mobile devices. A number of publications on middleware and language design — so-called reactive and event-based languages and systems (REBLS) — have already seen the light, but the field still raises several questions. For example, the interaction with mainstream language concepts is poorly understood, implementation technology is in its infancy and modularity mechanisms are almost totally lacking. Moreover, large applications are still to be developed and patterns and tools for developing reactive applications is an area that is vastly unexplored. This workshop will gather researchers in reactive and event-based languages and systems. The goal of the workshop is to exchange new technical research results and to define better the field by coming up with taxonomies and overviews of the existing work. **** ST30 **** Session types are a type-theoretic approach to specifying communication protocols so that they can be verified by type-checking. This year marks 30 years since the first paper on session types, by Kohei Honda at CONCUR 1993. Since then the topic has attracted increasing interest, and a substantial community and literature have developed. Google Scholar lists almost 400 articles with "session types" in the title, and most programming language conferences now include several papers on session types each year. In terms of the technical focus, there have been continuing theoretical developments (notably the generalisation from two-party to multi-party session types by Honda, Yoshida and Carbone in 2008, and the development of a Curry-Howard correspondence with linear logic by Caires and Pfenning in 2010) and a variety of implementations of session types as programming language extensions or libraries, covering (among others) Haskell, OCaml, Java, Scala, Rust, Python, C#, Go. ST30 is a workshop to celebrate the 30th anniversary of session types by bringing together the community for a day of talks and technical discussion. **** VMIL **** The concept of Virtual Machines is pervasive in the design and implementation of programming systems. Virtual Machines and the languages they implement are crucial in the specification, implementation and/or user-facing deployment of most programming technologies. The VMIL workshop is a forum for researchers and cutting-edge practitioners in language virtual machines, the intermediate languages they use, and related issues. The workshop is intended to be welcoming to a wide range of topics and perspectives, covering all areas relevant to the workshop’s theme. ====================================================================== ** SPLASH Posters ** ====================================================================== The SPLASH Posters track provides an excellent forum for authors to present their recent or ongoing projects in an interactive setting, and receive feedback from the community. SPLASH posters cover any aspect of programming, systems, languages and applications. The goal of the poster session is to encourage and facilitate small groups of individuals interested in a technical area to gather and interact. It is held early in the conference, to promote continued discussion among interested parties. ====================================================================== ** Doctoral Symposium ** ====================================================================== The SPLASH Doctoral Symposium provides students with useful guidance for completing their dissertation research and beginning their research careers. The symposium will provide an interactive forum fordoctoral students who have progressed far enough in their research to have a structured proposal, but will not be defending their dissertation in the next 12 months. ====================================================================== ** Student Research Competition ** ====================================================================== The ACM Student Research Competition (SRC), sponsored by Microsoft Research, offers a unique opportunity for undergraduate and graduate students to present their research to a panel of judges and conference attendees at SPLASH. The SRC provides visibility and exposes up-and-coming researchers to computer science research and the research community. This competition also gives students an opportunity to discuss their research with experts in their field, get feedback, and sharpen their communication and networking skills. ====================================================================== ** SPLASH-E ** ====================================================================== SPLASH-E is a forum for educators to make connections between programming languages research and the ways we educate computer science students. We invite work that could improve or inform computer science educators, especially work that connects with introductory computer science courses, programming languages, compilers, software engineering, and other SPLASH-related topics. Educational tools, experience reports, and new curricula are all welcome. ====================================================================== *** Co-Located Events *** ====================================================================== **** Dynamic Languages Symposium (DLS) **** The Dynamic Languages Symposium (DLS) is the premier forum for researchers and practitioners to share research and experience on all aspects of dynamic languages. After two decades of dynamic language research and DLS, it is time to reflect and look forward to what the next two decades will bring. This year's DLS will therefore be a special DLS focusing on the Future of Dynamic Languages. To do the notion of "symposium" justice, we will actively invite speakers to present their opinions on where Dynamic Languages might be, will be, or should be going in the next twenty years. **** Generative Programming: Concepts & Experiences (GPCE)**** ACM SIGPLAN International Conference on Generative Programming: Concepts & Experiences (GPCE) is a venue for researchers and practitioners interested in techniques that use program generation, domain-specific languages, and component deployment to increase programmer productivity, improve software quality, and shorten the time-to-market of software products. In addition to exploring cutting-edge techniques of generative software, our goal is to foster further cross-fertilization between the software engineering and the programming languages research communities. **** Logic-based Program Synthesis and Transformation (LOPSTR)**** The aim of the LOPSTR series is to stimulate and promote international research and collaboration on logic-based program development. LOPSTR is open to contributions in logic-based program development in any language paradigm. LOPSTR has a reputation for being a lively, friendly forum for presenting and discussing work in progress. **** Managed Programming Languages & Runtimes (MPLR)**** The 20th International Conference on Managed Programming Languages & Runtimes (MPLR'23, formerly ManLang, originally PPPJ) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems around, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (mobile, IoT, and wearable applications). **** Principles and Practice of Declarative Programming (PPDP) **** PPDP aims to provide a forum that brings together researchers from the declarative programming communities, including those working in the logic, constraint and functional programming paradigms, but also embracing a variety of other paradigms such as visual programming, executable specification languages, database languages, AI languages and knowledge representation languages used, for example, in the semantic web. The goal is to stimulate research in the use of logical formalisms and methods for specifying, performing, and analysing computations, including mechanisms for mobility, modularity, concurrency, object-orientation, security, and static analysis. Papers related to the use of declarative paradigms and tools in industry and education are especially solicited. **** Static Analysis Symposium (SAS) **** Static Analysis is widely recognized as a fundamental tool for program verification, bug detection, compiler optimization, program understanding, and software maintenance. The series of Static Analysis Symposia has served as the primary venue for the presentation of theoretical, practical, and application advances in the area. ====================================================================== # Organizing Committee SPLASH 2023: ====================================================================== General Chair: Vasco T. Vasconcelos (University of Lisbon) OOPSLA Review Committee Chair: Mira Mezini (TU Darmstadt) OOPSLA Publications Co-Chair: Ragnar Mogk (TU Darmstadt) OOPSLA Artifact Evaluation Co-Chair: Benjamin Greenman (Brown University) OOPSLA Artifact Evaluation Co-Chair: Guillaume Baudart (INRIA) DLS General Chair: Stefan Marr (University of Kent) GPCE General Chair: Bernhard Rumpe (RWTH Aachen University) GPCE PC Chair: Amir Shaikhha (University of Edinburgh) LOPSTR PC Chair: Robert Glück (University of Copenhagen, Denmark) LOPSTR PC Chair: Bishoksan Kafle (IMDEA) MPLR General Chair: Rodrigo Bruno (University of Lisbon) MPLR PC Chair: Elliot Moss (University of Massachusetts Amherst) PPDP PC Chair: Santiago Escobar (Universitat Politècnica de València ) SAS Co-Chair: Manuel Hermenegildo (Technical University of Madrid & IMDEA) SAS Co-Chair: José Morales (IMDEA) SAS Artifact Evaluation Chair: Marc Chevalier (Snyk) SLE Chair: João Saraiva (University of Minho) SLE PC Co-Chair: Thomas Degueule (CNRS, LaBRI) SLE PC Co-Chair: Elizabeth Scott (Royal Holloway University of London) Onward! Papers Chair: Tijs van der Storm (CWI & University of Groningen) Onward! Essays Chair: Robert Hirschfeld (University of Potsdam; Hasso Plattner Institute) SPLASH-E Co-Chair: Molly Feldman (Oberlin College) Posters Co-Chair: Xujie Si (University of Toronto) Workshops Co-Chair: Mehdi Bagherzadeh (Oakland University) Workshops Co-Chair: Amin Alipour (University of Houston) Hybridisation Co-Chair: Youyou Cong (Tokyo Institute of Technology) Hybridisation Co-Chair: Jonathan Immanuel Brachthäuser (University of Tübingen) Video Co-Chair: Guilherme Espada (University of Lisbon) Video Co-Chair: Apoorv Ingle (University of Iowa) Video Co-Chair: John Hui (Columbia University) Publicity Chair, Web Co-Chair: Andreea Costea (National University Of Singapore) Publicity Chair, Web Co-Chair: Alcides Fonseca (University of Lisbon) PLMW Co-Chair: Molly Feldman (Oberlin College) PLMW Co-Chair: Youyou Cong (Tokyo Institute of Technology) PLMW Co-Chair: João Ferreira (University of Lisbon) Sponsoring Co-Chair: Bor-Yuh Evan Chang (University of Colorado Boulder & Amazon) Sponsoring Co-Chair: Nicolas Wu (Imperial College London) Student Research Competition Co-Chair: Xujie Si (McGill University, Canada) Local Organizer Chair: Diana Costa (University of Lisbon) SIGPLAN Conference Manager: Neringa Young ====================================================================== From simon at joyful.com Tue Sep 12 16:18:50 2023 From: simon at joyful.com (Simon Michael) Date: Tue, 12 Sep 2023 17:18:50 +0100 Subject: [Haskell-cafe] ANN: shelltestrunner 1.10 Message-ID: <9A45C600-93F8-459E-8E27-04F9A7F1A797@joyful.com> I'm pleased to announce shelltestrunner 1.10 ! shelltestrunner (executable: `shelltest`) is a portable, GPLv3+ command-line tool for testing command-line programs or shell commands. It reads simple test specifications defining a command to run, some input, and the expected output, stderr, and exit status. It can run tests in parallel, selectively, with a timeout, in color, etc. The last release was 1.9, in 2018. The 1.10 release has been overdue; it brings some useful improvements, notably --print mode (with which you can convert old format 1 tests to the cleaner, recommended format 3), and precise line number reporting (to quickly locate the failing test). User-visible changes in 1.10 (2023-09-12): * GHC 9.6 compatibility (Andreas Abel) * Add --print for printing tests and/or converting file format (#24, Jakob Schöttl) * Add --shell option to select shell (#17, FC Stegerman) * Fix format1's handling of angle brackets in test data (#16) * Print test line number on failure (#14, Taavi Väljaots) * Add -p short flag for --precise * -h means --help, not --hide-successes * Clarify 300 char regex limit message Other changes: * Set up CI testing (#18 FC Stegerman, Simon Michael) * Improve bash-related tests (#20, FC Stegerman, Simon Michael) * Improved tests Thanks to release contributors: Jakob Schöttl, Taavi Väljaots, Felix C. Stegerman, and Andreas Abel. Install: $ stack install shelltestrunner-1.10 or: $ cabal update && cabal install shelltestrunner-1.10 Home: https://github.com/simonmichael/shelltestrunner From vamchale at gmail.com Wed Sep 13 18:38:05 2023 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 13 Sep 2023 14:38:05 -0400 Subject: [Haskell-cafe] [ANN] Jacinda 2.0.1.0 Message-ID: <9b6f79ac-acdc-9c6a-7b59-840332333194@gmail.com> Hello all, I have released another iteration of Jacinda, a text-processing language that lets you filter (fits in with sed + awk), handy on Unix! I’ve rewritten the backend so it should have far fewer bugs! https://github.com/vmchale/jacinda/releases/tag/2.0.1.0 Cheers, Vanessa McHale From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sat Sep 16 08:23:10 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 16 Sep 2023 09:23:10 +0100 Subject: [Haskell-cafe] Why can't I promote data family constructors, and what to do instead? Message-ID: Hello Cafe, I'm confused why I can't promote data family constructors, and what I should do instead. This message is a literate Haskell file. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE StandaloneKindSignatures #-} > {-# LANGUAGE TypeFamilies #-} I can promote constructors of normal data types nicely, here CT1 is promoted > data T = CT1 Char > type PT1 = CT1 'x' Suppose I want to promote constructors of a "non uniform" data definition, that is one where the structure of the type depends on a type argument, In Haskell that means a GADT, type family or data family. For my purposes a type family is unsuitable. I need to be able to reference it unsaturated. A GADT is also unsuitable because it introduces extra runtime tags that I don't want. But nor do data families work because their constructors can't be promoted. > data family DF a > newtype instance DF Int = CDFInt1 Char > data instance DF Bool = CDFBool1 | CDFBool2 > > -- • Data constructor ‘CDFInt1’ cannot be used here > -- (it comes from a data family instance) > -- type PDF = CDFInt1 'x' The GHC users guide says Data family instance constructors cannot be promoted at the moment. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types. https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/data_kinds.html I'm puzzled about why I can't do that. I can do this > newtype DFInt = CDFInt1' Char > data DFBool = CDFBool1' | CDFBool2' > type family TF a > type instance TF Int = DFInt > type instance TF Bool = DFBool > type PNF1 :: TF Int > type PNF1 = CDFInt1' 'x' which I said above is unsuitable because I can't refer to `TF` unsaturated. But I can apply a standard trick of wrapping a type family in a newtype: > newtype NF a = CNF (TF a) > type PNF :: NF Int > type PNF = CNF (CDFInt1' 'x') Problem solved! But this goes all round the houses. What a mess! The data family version would be much neater if it worked. I have two questions: 1. Is this restriction *really* necessary? I'm surprised that GHC can't cope with promoting constructors of data families given that it is straightforward to simulate the desired behaviour with type families and a newtype. 2. Is my encoding the simplest that I can achieve? Note that the following GADT does *not* work because `GDFInt` has an unnecessary tag. > data GF a where > GDFInt :: Char -> GF Int > GDFBool1 :: GF Bool > GDFBool2 :: GF Bool From ryan.gl.scott at gmail.com Sat Sep 16 12:45:59 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 16 Sep 2023 08:45:59 -0400 Subject: [Haskell-cafe] Why can't I promote data family constructors, and what to do instead? Message-ID: Regarding the first question ("Is this restriction *really* necessary?"), I think the answer is likely "no", at least for most data family instances. This discussion [1] is the most up-to-date reference on the history and motivations behind the current restriction. In that discussion, it is hypothesized that data family instances whose data constructors do not use any constraints could be promoted without needing to rethink how Core works. (If I understand correctly, all of your data family instances fall into this simple subset.) This discussion could provide a template for a GHC proposal that proposes to allow this feature. Best, Ryan ----- [1] https://github.com/ghc-proposals/ghc-proposals/discussions/456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Sep 18 09:55:38 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 18 Sep 2023 10:55:38 +0100 Subject: [Haskell-cafe] Limitations of generalization of type constructors Message-ID: Hello Cafe, Generalization of types in type constructors behaves strangely compared to the same behaviour at the term level. I was wondering whether this is expected, whether it's a known issue that's due to be resolved, or is a known issue that can't be resolved for some technical reason. This mail is a literate Haskell file. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE StandaloneKindSignatures #-} > {-# LANGUAGE TypeFamilies #-} > > {-# OPTIONS_GHC -Wall #-} > {-# OPTIONS_GHC -Wno-unticked-promoted-constructors #-} > > import Prelude hiding (const) > import Data.Kind (Type) `f` takes an argument of polymorphic type > f :: (forall (z :: Type). Maybe z -> Int) -> Int > f k = k (Just True) `c1` is an argument that will fit there. Its type matches exactly. > c1 :: forall (z :: Type). Maybe z -> Int > c1 _ = 0 > > fc1 :: Int > fc1 = f c1 `c2` will fit there but its type doesn't match exactly. `z` will have to be substituted with `Maybe z`, obtaining the type forall (z :: Type). Maybe z -> Int which does fit exactly. > c2 :: forall (z :: Type). z -> Int > c2 _ = 0 > > fc2 :: Int > fc2 = f c2 `const` will fit there, once `z` is substituted with `Maybe z`, the `Int` argument applied and the quantifer moved, obtaining the type forall (z :: Type). Maybe z -> Int which does fit exactly. > const :: forall (z :: Type). Int -> z -> Int > const x _ = x > > fc3 :: Int > fc3 = f (const 0) The story for type constructors is not so pleasant. I can define an analogue of `f` on the type level: > type F :: (forall (z :: Type). Maybe z -> Type) -> Type > newtype F k = F (k (Just Bool)) and the analogue of `c1` fits exactly: > type C1 :: forall (z :: Type). Maybe z -> Type > data C1 m = C1 > > type FC1 :: Type > type FC1 = F C1 but the analogue of `c2` does not: > type C2 :: forall (z :: Type). z -> Type > data C2 m = C2 > > -- Occurs check: cannot construct the infinite kind: z ~ Maybe z > -- type FC2 :: Type > -- type FC2 = F C2 nor does the analogue of `const`: > type Const :: forall (z :: Type). Type -> Maybe z -> Type > newtype Const z a = Const z > > -- • Expected kind ‘forall z. Maybe z -> *’, > -- but ‘Const ()’ has kind ‘Maybe a0 -> *’ > -- type FC3 :: Type > -- type FC3 = F (Const ()) To get the analogue of `const` we have to be much more specific: > type OtherConst :: Type -> forall (z :: Type). Maybe z -> Type > newtype OtherConst z b = OtherConst z > > type FC4 :: Type > type FC4 = F (OtherConst ()) This is rather unfortunate because it limits generic programming at the type level! From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Sep 18 09:56:48 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 18 Sep 2023 10:56:48 +0100 Subject: [Haskell-cafe] Why can't I promote data family constructors, and what to do instead? In-Reply-To: References: Message-ID: On Sat, Sep 16, 2023 at 08:45:59AM -0400, Ryan Scott wrote: > Regarding the first question ("Is this restriction *really* necessary?"), I > think the answer is likely "no", at least for most data family instances. > This discussion [1] is the most up-to-date reference on the history and > motivations behind the current restriction. > > [1] https://github.com/ghc-proposals/ghc-proposals/discussions/456 Very interesting. Thanks Ryan! From ryan.gl.scott at gmail.com Mon Sep 18 13:23:19 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Sep 2023 09:23:19 -0400 Subject: [Haskell-cafe] Limitations of generalization of type constructors Message-ID: Short answer: This is expected behavior, and it's unlikely that behavior will change any time soon. Long answer: The key phrase in your original post is "the quantifier moved". That is, in this definition: > fc3 :: Int > fc3 = f (const 0) GHC will turn it into something like this behind the scenes when compiling it to Core: > fc3 :: Int > fc3 = f (\ (@z). const @Int @(Maybe z) 0 :: forall (z :: Type). Maybe z -> Int) Note the presence of `\ (@z)`, which binds a type variable with a lambda. This process of moving quantifiers by using type variables in lambdas is called *regeneralization*. A somewhat surprising fact is that GHC can only perform regeneralization some of the time. GHC can regeneralize type-level `forall`s—that is, `forall`s in the types of terms, as is the case in the example above—but it cannot regeneralize *kind*-level `forall`s. In your post, the `forall`s in the kinds of C2 and Const are kind-level `forall`s. This restriction is documented here [1] in the GHC User's Guide. I've also written a slightly longer blog post [2] about the topic. The reason why this restriction exists is because there is no type-level counterpart to `\ (@z)` in Core, which would be required for regeneralization at the kind level. Adding type-level lambdas to Core would likely be a non-trivial effort. The UnsaturatedTypeFamilies proposal [3], which proposes to relax some restrictions about when types can appear partially applied, is the closest thing that I can think of, but it stops short of proposing full type-level lambdas. Best, Ryan ----- [1] https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/poly_kinds.html#higher-rank-kinds [2] https://ryanglscott.github.io/2019/07/10/the-surprising-rigidness-of-higher-rank-kinds/ [3] https://github.com/ghc-proposals/ghc-proposals/blob/7e380dcc4494de30f95bd15d18342eb2302430c4/proposals/0242-unsaturated-type-families.rst -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Sep 18 15:02:42 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 18 Sep 2023 16:02:42 +0100 Subject: [Haskell-cafe] Limitations of generalization of type constructors In-Reply-To: References: Message-ID: On Mon, Sep 18, 2023 at 09:23:19AM -0400, Ryan Scott wrote: > Short answer: This is expected behavior, and it's unlikely that behavior > will change any time soon. > > Long answer: The key phrase in your original post is "the quantifier > moved". [...] > The reason why this restriction exists is because there is no type-level > counterpart to `\ (@z)` in Core, which would be required for > regeneralization at the kind level. Aha, thank you, Ryan, for the helpful explanation. In that case I will continue to write data types specialised for each use case. That's not too painful in my particular application. Whenever I get stuck on this stuff I marvel at how wonderfully everything works out at the value level! Tom From ben at well-typed.com Wed Sep 20 04:54:14 2023 From: ben at well-typed.com (Ben Gamari) Date: Wed, 20 Sep 2023 00:54:14 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available Message-ID: <87sf79o362.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the third alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha4 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * 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]. This alpha includes roughly 40 new commits relative to alpha 3, including what we believe should be nearly the last changes to GHC's boot libraries. 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 [TypeAbstractions]: 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-alpha4/docs/users_guide/9.8.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From leah at vuxu.org Fri Sep 22 15:45:12 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Fri, 22 Sep 2023 17:45:12 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2023-09-25 @ 19:30 Message-ID: <8734z6yzxz.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 26 at Augustiner-Gaststätte Rumpler at 19h30. 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/72lt3XWvVmWUt3Gl Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From george.colpitts at gmail.com Fri Sep 22 22:34:54 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 22 Sep 2023 19:34:54 -0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: <87sf79o362.fsf@smart-cactus.org> References: <87sf79o362.fsf@smart-cactus.org> Message-ID: - #21570, Linker broken on M1 Mac, occurs on 9.8.1-alpha4. I have updated the bug. My guess is that it was never addressed as the info needed tag was never removed after the required info was supplied. It might be good to have a test for this. - On Wed, Sep 20, 2023 at 1:54 AM Ben Gamari wrote: > > The GHC developers are very pleased to announce the availability of the > third alpha prerelease of GHC 9.8.1. Binary distributions, source > distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.8.1-alpha4 > > GHC 9.8 will bring a number of new features and improvements, including: > > * Preliminary support the `TypeAbstractions` language extension, > allowing types to be bound in type declarations [TypeAbstractions]. > > * 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]. > This alpha includes roughly 40 new commits relative to alpha 3, > including what we believe should be nearly the last changes to GHC's > boot libraries. > > 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 > > [TypeAbstractions]: > 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-alpha4/docs/users_guide/9.8.1-notes.html > _______________________________________________ > 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 george.colpitts at gmail.com Fri Sep 22 23:22:14 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 22 Sep 2023 20:22:14 -0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: References: <87sf79o362.fsf@smart-cactus.org> Message-ID: It seems unlikely that the current tests wouldn't find this bug. Is it the case that the tests are never run on aarch64-darwin Macs? On Fri, Sep 22, 2023 at 7:34 PM George Colpitts wrote: > > - > #21570, Linker broken on M1 Mac, occurs on 9.8.1-alpha4. I have > updated the bug. My guess is that it was never addressed as the info needed > tag was never removed after the required info was supplied. It might be > good to have a test for this. > > - > > > > On Wed, Sep 20, 2023 at 1:54 AM Ben Gamari wrote: > >> >> The GHC developers are very pleased to announce the availability of the >> third alpha prerelease of GHC 9.8.1. Binary distributions, source >> distributions, and documentation are available at >> >> https://downloads.haskell.org/ghc/9.8.1-alpha4 >> >> GHC 9.8 will bring a number of new features and improvements, including: >> >> * Preliminary support the `TypeAbstractions` language extension, >> allowing types to be bound in type declarations [TypeAbstractions]. >> >> * 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]. >> This alpha includes roughly 40 new commits relative to alpha 3, >> including what we believe should be nearly the last changes to GHC's >> boot libraries. >> >> 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 >> >> [TypeAbstractions]: >> 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-alpha4/docs/users_guide/9.8.1-notes.html >> _______________________________________________ >> 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 ben at well-typed.com Sat Sep 23 00:33:58 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 22 Sep 2023 20:33:58 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: References: <87sf79o362.fsf@smart-cactus.org> Message-ID: <87wmwhn2xa.fsf@smart-cactus.org> George Colpitts writes: > It seems unlikely that the current tests wouldn't find this bug. Is it the > case that the tests are never run on aarch64-darwin Macs? > The tests are certainly run; see, for instance, the 9.8.1-alpha4 release pipeline [1]. The problem is that #21570 requires very particular (mis)configuration of the host toolchain (e.g. Richard had multiple, incompatible toolchains in PATH). We can usually side-step this sort of misconfiguration by disabling the `configure` script's ld-override logic, since we using anything but Apple's linker is generally a bad idea on Darwin. This measure (!8437) is present in the 9.8 branch so I can only guess that something else is wrong. Perhaps you could open a ticket and attach config.log? Cheers, - Ben [1]: https://gitlab.haskell.org/ghc/ghc/-/jobs/1668689 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From carter.schonwald at gmail.com Sat Sep 23 17:06:15 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 23 Sep 2023 13:06:15 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: <87wmwhn2xa.fsf@smart-cactus.org> References: <87sf79o362.fsf@smart-cactus.org> <87wmwhn2xa.fsf@smart-cactus.org> Message-ID: George can you share the generated settings file? On Fri, Sep 22, 2023 at 8:34 PM Ben Gamari wrote: > George Colpitts writes: > > > It seems unlikely that the current tests wouldn't find this bug. Is it > the > > case that the tests are never run on aarch64-darwin Macs? > > > The tests are certainly run; see, for instance, the 9.8.1-alpha4 release > pipeline [1]. > > The problem is that #21570 requires very particular (mis)configuration > of the host toolchain (e.g. Richard had multiple, incompatible > toolchains in PATH). We can usually side-step this sort of > misconfiguration by disabling the `configure` script's ld-override > logic, since we using anything but Apple's linker is generally a bad > idea on Darwin. This measure (!8437) is present in the 9.8 branch so I can > only > guess that something else is wrong. > > Perhaps you could open a ticket and attach config.log? > > Cheers, > > - Ben > > > [1]: https://gitlab.haskell.org/ghc/ghc/-/jobs/1668689 > _______________________________________________ > 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 bryan at haskell.foundation Mon Sep 25 19:30:06 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 25 Sep 2023 22:30:06 +0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.3 is now available Message-ID: The GHC developers are happy to announce the availability of GHC 9.6.3. Binary distributions, source distributions, and documentation are available on the release page. https://www.haskell.org/ghc/download_ghc_9_6_3.html This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include: * Disable Polymorphic Specialisation (a performance optimisation) by default. It was discovered that Polymorphic Specialisation as currently implemented in GHC can lead to hard to diagnose bugs resulting in incorrect runtime results. Users wishing to use this optimisation despite the caveats will now have to explicitly enable the new `-fpolymorphic-specialisation` flag. For more details see #23469 as well as #23109, #21229, #23445. * Improve compile time and code generation performance when `-finfo-table-map` is enabled (#23103). * Make the recompilation check more robust when code generation flags are changed (#23369). * Addition of memory barriers that improve soundness on platforms with weak memory ordering. * And dozens of other fixes. A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [GHC ticket] if you see anything amiss. Enjoy! -Bryan [release notes]: https://downloads.haskell.org/~ghc/9.6.3/docs/users_guide/9.6.3-notes.html [GHC ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new From exarkun at twistedmatrix.com Tue Sep 26 13:37:46 2023 From: exarkun at twistedmatrix.com (Jean-Paul Calderone) Date: Tue, 26 Sep 2023 09:37:46 -0400 Subject: [Haskell-cafe] Taking over maintainership of `fec` Message-ID: Hello all, I would like to take over maintainership of the `fec` package ( https://hackage.haskell.org/package/fec). fec is a wrapper around a C library for a certain forward erasure code scheme. Neither the C library nor the Haskell bindings have changed much since the package was last published on Hackage but recently I've fixed a multithreading bug that leads to corrupt results and an integer overflow bug that leads to memory corruption and typically a segfault. I would love to make these improvements available via Hackage. I don't think `fec` has much of a user base but I've recently published several cryptographic libraries on Hackage which depend on it and suffer from the two issues mentioned above. I'm also an upstream maintainer of the project (https://github.com/tahoe-lafs/zfec). I have emailed the current maintainer and original author of the Haskell bindings, Adam Langley (cced), about becoming a maintainer but I haven't yet heard back. Thanks, Jean-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Tue Sep 26 14:59:41 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 26 Sep 2023 10:59:41 -0400 Subject: [Haskell-cafe] Taking over maintainership of `fec` In-Reply-To: References: Message-ID: On Tue, Sep 26, 2023 at 09:37:46AM -0400, Jean-Paul Calderone wrote: > I have emailed the current maintainer and original author of the Haskell > bindings, Adam Langley (cced), about becoming a maintainer but I haven't > yet heard back. I didn't know AGL was (in the past?) a Haskeller. If he hasn't responded in the meantime, I'll reach out via office email, to ask whether he's inclined to continue to maintain the "fec" package. -- Viktor. From exarkun at twistedmatrix.com Tue Sep 26 17:05:05 2023 From: exarkun at twistedmatrix.com (Jean-Paul Calderone) Date: Tue, 26 Sep 2023 13:05:05 -0400 Subject: [Haskell-cafe] Taking over maintainership of `fec` In-Reply-To: References: Message-ID: On Tue, Sep 26, 2023 at 11:00 AM Viktor Dukhovni wrote: > On Tue, Sep 26, 2023 at 09:37:46AM -0400, Jean-Paul Calderone wrote: > > > I have emailed the current maintainer and original author of the Haskell > > bindings, Adam Langley (cced), about becoming a maintainer but I haven't > > yet heard back. > > I didn't know AGL was (in the past?) a Haskeller. If he hasn't > responded in the meantime, I'll reach out via office email, to ask > whether he's inclined to continue to maintain the "fec" package. > Thanks Viktor, that would be wonderful. Jean-Paul > > -- > Viktor. > > _______________________________________________ > 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 ietf-dane at dukhovni.org Tue Sep 26 17:58:50 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 26 Sep 2023 13:58:50 -0400 Subject: [Haskell-cafe] Taking over maintainership of `fec` In-Reply-To: References: Message-ID: On Tue, Sep 26, 2023 at 01:05:05PM -0400, Jean-Paul Calderone wrote: > > On Tue, Sep 26, 2023 at 09:37:46AM -0400, Jean-Paul Calderone wrote: > > > > > I have emailed the current maintainer and original author of the Haskell > > > bindings, Adam Langley (cced), about becoming a maintainer but I haven't > > > yet heard back. > > > > I didn't know AGL was (in the past?) a Haskeller. If he hasn't > > responded in the meantime, I'll reach out via office email, to ask > > whether he's inclined to continue to maintain the "fec" package. > > > > Thanks Viktor, that would be wonderful. Adam's response: Thanks. After 15 years they're welcome to take it over -- Viktor. From exarkun at twistedmatrix.com Wed Sep 27 12:56:04 2023 From: exarkun at twistedmatrix.com (Jean-Paul Calderone) Date: Wed, 27 Sep 2023 08:56:04 -0400 Subject: [Haskell-cafe] Taking over maintainership of `fec` In-Reply-To: References: Message-ID: On Tue, Sep 26, 2023 at 1:59 PM Viktor Dukhovni wrote: > On Tue, Sep 26, 2023 at 01:05:05PM -0400, Jean-Paul Calderone wrote: > > > > On Tue, Sep 26, 2023 at 09:37:46AM -0400, Jean-Paul Calderone wrote: > > > > > > > I have emailed the current maintainer and original author of the > Haskell > > > > bindings, Adam Langley (cced), about becoming a maintainer but I > haven't > > > > yet heard back. > > > > > > I didn't know AGL was (in the past?) a Haskeller. If he hasn't > > > responded in the meantime, I'll reach out via office email, to ask > > > whether he's inclined to continue to maintain the "fec" package. > > > > > > > Thanks Viktor, that would be wonderful. > > Adam's response: > > Thanks. After 15 years they're welcome to take it over > > Great news, thanks Viktor. According to https://wiki.haskell.org/Taking_over_a_package there are certain steps Adam should take to make this official, but I'll see if the Hackage admins are satisfied with this thread or not. > -- > Viktor. > _______________________________________________ > 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 tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Thu Sep 28 11:34:14 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 28 Sep 2023 12:34:14 +0100 Subject: [Haskell-cafe] How can I get in touch with Stan maintainers? Message-ID: Hello, Does anyone know how I can get in touch with the Stan maintainers? Stan is a static analysis tool for Haskell. Its maintainers seem to have stopped supporting it after the GHC 8.x series because the GHC API changed too frequently for them to want to keep making adjustments. Last year I did quite a lot of work to bring Stan and its dependencies up to 9.4. I made a PR to the Stan Github repo last month: https://github.com/kowainik/stan/pull/506 I haven't heard anything from the maintainers. The only maintainer I know of is Veronika Romashkina. I've sent her a private email about this but had no response. Does anyone know how I can get in contact with Veronika or another Stan maintainer, if there is one? I would be willing to be a comaintainer for Stan and the rest of the Kowainik ecosystem (if only to make sure they continue to work with future GHCs). Thanks, Tom From zubin at well-typed.com Fri Sep 29 11:26:46 2023 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 29 Sep 2023 16:56:46 +0530 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] Haskell Language Server 2.3.0.0 released Message-ID: Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-2.3.0.0/. These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/) or the Haskell VSCode extension. All of these tarballs have associated GPG signatures. The signature should be from `Zubin Duggal ` (key ID [588764FBE22D19C4](https://keys.openpgp.org/search?q=588764FBE22D19C4)). The prebuilt binaries in this release support the following GHC versions: - 9.0.2 - 9.2.8 - 9.4.6 - 9.6.2 - 9.6.3 ## Changelog * Binaries for GHC 9.6.3 * Drop support for GHC 8.10 * Remove `hls-haddock-comments-plugin`, `hls-stan-plugin`, and `hls-tactics-plugin` * Don't suggest bogus modules names in `hls-module-name-plugin` (#3784) * Add support for external Ormolu (#3771) * Improve refine imports behaviour for qualified imports (#3806) Happy editing! - Zubin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ben at well-typed.com Fri Sep 29 21:55:37 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 29 Sep 2023 17:55:37 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-rc1 is now available Message-ID: <87v8bsk5ka.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the release candidate of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-rc1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * 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]. This candidate includes roughly 20 new commits relative to alpha 4, including what we believe should be nearly the last changes to GHC's boot libraries. As always, GHC's release status can be found on the GHC Wiki [status]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [TypeAbstractions]: 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-alpha4/docs/users_guide/9.8.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dennis.raddle at gmail.com Sat Sep 30 08:51:01 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 30 Sep 2023 01:51:01 -0700 Subject: [Haskell-cafe] two HLS processes with same name Message-ID: I'm running the HLS plugin in VS Code on MacOS, on an M2 Apple Silicon MacBook Pro. My computer is running low on RAM and the HLS process seems to be fairly large for me (over 1 GB). When I first run VS Code on a Haskell workspace, there is one process called "haskell-language-server-9.2.8". Eventually another process, taking an additional 1 GB, joins it. The two processes have the same name. Is it supposed to work like this? Note about Apple Silicon FYI: I bought this computer in June with 16 GB Integrated RAM. RAM is very expensive in a SoC. I'm discovering that a lot of programs are memory hogs, not sure if it's the latest MacOS or M2, but between running software development stuff and music-related apps, I'm running out of RAM. I just bought a similar MacBook but with 32 GB RAM, and will sell the current one. So eventually I won't worry about an extra GB process or two. Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sat Sep 30 08:55:53 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 30 Sep 2023 09:55:53 +0100 Subject: [Haskell-cafe] two HLS processes with same name In-Reply-To: References: Message-ID: On Sat, Sep 30, 2023 at 01:51:01AM -0700, Dennis Raddle wrote: > When I first run VS Code on a Haskell workspace, there is one > process called "haskell-language-server-9.2.8". Eventually another > process, taking an additional 1 GB, joins it. The two processes have > the same name. > > Is it supposed to work like this? I use Emacs, not VS Code, but when I have two "haskell-language-server" processes it's because I have opened a second project. Is it possible that's happened for you? For a hacky way to explore what's going on you could kill one of the processes and see what complains. Tom From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sat Sep 30 16:37:45 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 30 Sep 2023 17:37:45 +0100 Subject: [Haskell-cafe] Using deriving with indexed data types Message-ID: How are Haskell folks using indexed types (indexed by types of DataKinds) whilst still being able to take advantage of GHC's deriving? I wrote up my approach into a small library: https://github.com/tomjaguarpaw/ad/blob/589926448865700fa616e8c6f6e4a011384499cb/indexed-types/src/IndexedTypes/Index.hs Here's an example of using my approach: https://github.com/tomjaguarpaw/ad/blob/master/indexed-types/src/IndexedTypes/Example.hs and it shows you can still use deriving for all your instances: https://github.com/tomjaguarpaw/ad/blob/master/indexed-types/src/IndexedTypes/Example.hs I'd be interested to know what other approaches people are using in practice. Thanks, Tom From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sat Sep 30 16:41:09 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 30 Sep 2023 17:41:09 +0100 Subject: [Haskell-cafe] Using deriving with indexed data types In-Reply-To: References: Message-ID: On Sat, Sep 30, 2023 at 05:37:45PM +0100, Tom Ellis wrote: > and it shows you can still use deriving for all your instances: Oh the direct link to the instances should have been https://github.com/tomjaguarpaw/ad/blob/589926448865700fa616e8c6f6e4a011384499cb/indexed-types/src/IndexedTypes/Example.hs#L111-L133 From dennis.raddle at gmail.com Sat Sep 30 22:00:52 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 30 Sep 2023 15:00:52 -0700 Subject: [Haskell-cafe] two HLS processes with same name In-Reply-To: References: Message-ID: Thanks, Tom. I only have one stack project open, but I do have a single hs file open from outside that project, usually. That single hs file does not reside in a stack project tree. I'll try running VS Code with and without that single hs file. D On Sat, Sep 30, 2023 at 1:56 AM Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > On Sat, Sep 30, 2023 at 01:51:01AM -0700, Dennis Raddle wrote: > > When I first run VS Code on a Haskell workspace, there is one > > process called "haskell-language-server-9.2.8". Eventually another > > process, taking an additional 1 GB, joins it. The two processes have > > the same name. > > > > Is it supposed to work like this? > > I use Emacs, not VS Code, but when I have two > "haskell-language-server" processes it's because I have opened a > second project. Is it possible that's happened for you? > > For a hacky way to explore what's going on you could kill one of the > processes and see what complains. > > Tom > _______________________________________________ > 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 jclites at mac.com Sat Sep 30 22:09:55 2023 From: jclites at mac.com (Jeff Clites) Date: Sat, 30 Sep 2023 18:09:55 -0400 Subject: [Haskell-cafe] two HLS processes with same name In-Reply-To: References: Message-ID: <67E4C3EF-9E22-4584-8519-7D661E51B241@mac.com> An HTML attachment was scrubbed... URL: