From ifl21.publicity at gmail.com Mon Aug 5 17:17:23 2024 From: ifl21.publicity at gmail.com (Mart Lubbers) Date: Mon, 5 Aug 2024 10:17:23 -0700 Subject: [Haskell-cafe] IFL 2024 Final call for papers, extended submission deadline. Message-ID: ======================================================================= IFL 2024 36rd Symposium on Implementation and Application of Functional Languages venue: Radboud University Nijmegen, The Netherlands August 26 - 28 2024 https://ifl24.cs.ru.nl ======================================================================= ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2024 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. ### Industrial track and topics of interest Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques ### Peer-review process Following IFL tradition, IFL 2024 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. ### Important dates Submission deadline of draft papers August 6th, 2024 EXTENDED Notification of acceptance for presentation August 6th, 2024 Registration deadline August 19th, 2024 IFL symposium August 26-28, 2024 Submission of papers for proceedings December 1st, 2024 Notification of acceptance February 2nd, 2025 Camera-ready version March 2nd, 2025 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Submit your paper here: https://easychair.org/conferences/?conf=ifl20240 Register here: https://ifl24.cs.ru.nl/Registration Important note to authors about the new ACM open access publishing model ACM has introduced a new open access publishing model for the International Conference Proceedings Series (ICPS). Authors based at institutions that are not yet part of the ACM Open program and do not qualify for a waiver will be required to pay an article processing charge (APC) to publish their ICPS article in the ACM Digital Library. To determine whether or not an APC will be applicable to your article, please follow the detailed guidance here: https://www.acm.org/publications/icps/author-guidance. Further information may be found on the ACM website, as follows: - Full details of the new ICPS publishing model: https://www.acm.org/publications/icps/faq - Full details of the ACM Open program: https://www.acm.org/publications/openaccess - Please direct all questions about the new model to icps-info at acm.org. ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organisation PC Chairs: Mart Lubbers Radboud University, The Netherlands Local Chairs: Peter Achten Radboud University, The Netherlands Sven-Bodo Scholz, Radboud University, The Netherlands ### Program committee: Benoît Montagu, University of Lorraine, Inria, France Christos Dimoulas, Northwestern University, USA Edsko de Vries, Well-typed, The Netherlands Fritz Henglein, University of Copenhagen, Denmark Ian Mackie, University of Sussex, UK Jason Hemann, Seton Hall University, USA João Saraiva, Universidade do Minho, Portugal Jurriaan Hage, Heriot-Watt University, UK Kenichi Asai, Ochanomizu University, Japan Maja Kirkeby, Roskilde University, Denmark Marco Morazán, Seton Hall University, USA Neil Mitchell, Facebook, UK Ralf Laemmel, University of Koblenz Landau, Germany Rinus Plasmeijer, TOP Software/Radboud University, The Netherlands Stephen Chang, UMass Boston, USA Tim Steenvoorden, Open University, The Netherlands Tom Schrijvers, KU Leuven, Belgium Yusuf Moosa Motara, Rhodes University, South Africa ### Venue IFL 2024 will be held physically in Nijmegen, the Netherlands. See the website for more information. https://ifl24.cs.ru.nl ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here. From liuxinyu95 at gmail.com Tue Aug 6 04:25:47 2024 From: liuxinyu95 at gmail.com (Xinyu LIU) Date: Mon, 5 Aug 2024 21:25:47 -0700 Subject: [Haskell-cafe] Mathematics in Programming - a book with Haskell examples Message-ID: Hello, My book 'Mathematics in Programming' in English was published on 7/11/2024. This book uses Haskell as the main tool for examples of mathematics ideas. Springer link: https://link.springer.com/book/10.1007/978-981-97-2432-1 Amazon link: https://www.amazon.com/Mathematics-Programming-Xinyu-Liu/dp/9819724317/ The book presents the mathematical view and tools of computer programming with broad and friendly context. It explains the basic concepts such as recursion, computation model, types, data, and etc. The book serves as an introductory and reference guide to the engineers, students, researchers, and professionals who are interested in functional programming, type system, and computer programming languages. The book covers seven topics. Firstly, it lays out the number system based on Peano Axioms and demonstrates the isomorphic computer data structures. Then, it introduces Lambda calculus as a computing model and recursion, an important programming structure, with the Y-combinator. It next presents the basic abstract algebra, including group and fields, and provides a friendly introduction to Galois theory. After that, it uses category theory as a tool to explain several concepts in computer programming, including the type system, polymorphism, null handler, and recursive data types, then followed by an application of program optimization. In the last two chapters, the author shows how to program with the concept of infinity through stream and lazy evaluation, and then explains the naïve set theory and transfinite numbers, from which the logic paradox arises. Finally, it introduces four historical views of mathematical foundation, as well as Gödel’s incompleteness theorems developed in 1930s, and how they define the boundaries of computer programming. Additionally, the book provides biographies, stories, and anecdotes of 25 mathematicians, along with over 130 exercises and their corresponding answers. Xinyu LIU https://github.com/liuxinyu95 *e*^(*π*i)+1 = 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xnningxie at gmail.com Thu Aug 8 14:20:53 2024 From: xnningxie at gmail.com (Ningning Xie) Date: Thu, 8 Aug 2024 10:20:53 -0400 Subject: [Haskell-cafe] POPL 2025 Call for Tutorials Message-ID: POPL 2025 CALL FOR TUTORIALS https://popl25.sigplan.org/track/POPL-2025-tutorials#Call-For-Tutorials The 52nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL 2025) will be held in Denver, United States. POPL provides a forum for the discussion of fundamental principles and important innovations in the design, definition, analysis, transformation, implementation, and verification of programming languages, programming systems, and programming abstractions. Tutorials for POPL 2025 are solicited on any topic relevant to the POPL community. We particularly encourage submissions of introductory tutorials that make the research presented at POPL more accessible to the participants. Tutorials will be held on Jan 19–21, 2025. The expected length of a tutorial is 3 hours, including questions and discussion (Q&A). *Submission details* Deadline for submission: October 18th, 2024 Notification of acceptance: November 1st, 2024 A tutorial proposal should provide the following information: - Tutorial title - Presenter(s), affiliation(s), and contact information - 1-3 page description (for evaluation). This should include the objectives, topics to be covered, presentation approach, target audience, prerequisite knowledge, and if the tutorial was previously held, the location (i.e. which conference), date, and number of attendees if available. - 1-2 paragraph abstract suitable for tutorial publicity. - 1-paragraph biography suitable for tutorial publicity. Proposals must be submitted by email to Christoph Matheja (chmat at dtu.dk) and Robert Rand (rand at uchicago.edu) with the subject line "POPL 2025 Tutorial Proposal: [tutorial name]". The proposal should be attached as a PDF, docx, or txt file. *Further information* Any query regarding POPL 2025 tutorial proposals should be addressed to the co-located events chairs Christoph Matheja (chmat at dtu.dk) and Robert Rand ( rand at uchicago.edu), or to the general chair Steve Zdancewic ( stevez at seas.upenn.edu). -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Aug 9 08:49:45 2024 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 9 Aug 2024 10:49:45 +0200 (CEST) Subject: [Haskell-cafe] no-unused-imports for only one import Message-ID: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I would like to set -Wno-unused-imports for only one import, is it possible and how to do it ? thanks for your advices. Frederic From lemming at henning-thielemann.de Fri Aug 9 09:01:33 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 9 Aug 2024 11:01:33 +0200 (CEST) Subject: [Haskell-cafe] no-unused-imports for only one import In-Reply-To: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> References: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: On Fri, 9 Aug 2024, PICCA Frederic-Emmanuel wrote: > Hello, > > I would like to set -Wno-unused-imports for only one import, > > is it possible and how to do it ? What about the import Your.Module () trick? That is, add empty parenthesis after your import? From hecate at glitchbra.in Fri Aug 9 09:02:48 2024 From: hecate at glitchbra.in (=?UTF-8?Q?H=C3=A9cate?=) Date: Fri, 9 Aug 2024 11:02:48 +0200 Subject: [Haskell-cafe] no-unused-imports for only one import In-Reply-To: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> References: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: I don't believe so, because flags are set on a module basis and you need more granular control. Having been in your situation many times, what I often do is to define a cabal flag called "development" and in my ghc-options stanza I write: if flag(development)   ghc-options: -Wno-unused-imports -Wno-unused-packages Then during CI I disable this flag. Cheers, Hécate Le 09/08/2024 à 10:49, PICCA Frederic-Emmanuel a écrit : > Hello, > > I would like to set -Wno-unused-imports for only one import, > > is it possible and how to do it ? > > thanks for your advices. > > Frederic > _______________________________________________ > 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. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Aug 9 09:06:24 2024 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 9 Aug 2024 11:06:24 +0200 (CEST) Subject: [Haskell-cafe] no-unused-imports for only one import In-Reply-To: References: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <780531209.127576379.1723194384155.JavaMail.zimbra@synchrotron-soleil.fr> > import Your.Module () > > trick? That is, add empty parenthesis after your import? This code is a binding to a library and depending on values this import is necessary or not. encodeDataspace :: Dataspace -> IO BS.ByteString encodeDataspace (Dataspace space_id) = withOutByteString $ \buf bufSz -> withInOut_ bufSz $ \ioBufSz -> withErrorCheck_ $ #if H5_VERSION_GE(1,12,0) # if H5Sencode_vers == 2 h5s_encode space_id buf ioBufSz h5p_DEFAULT # elif H5Sencode_vers == 1 h5s_encode space_id buf ioBufSz # else # error "H5Sencode_vers set to invalid value" # endif #else h5s_encode space_id buf ioBufSz #endif look at the h5p_DEFAULT which comes from the sus-named import. If I put () I think that when 5Sencode_vers == 2, the compilation failed... Fred From lemming at henning-thielemann.de Fri Aug 9 09:12:10 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 9 Aug 2024 11:12:10 +0200 (CEST) Subject: [Haskell-cafe] no-unused-imports for only one import In-Reply-To: <780531209.127576379.1723194384155.JavaMail.zimbra@synchrotron-soleil.fr> References: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> <780531209.127576379.1723194384155.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: On Fri, 9 Aug 2024, PICCA Frederic-Emmanuel wrote: >> import Your.Module () >> >> trick? That is, add empty parenthesis after your import? > > This code is a binding to a library and depending on values this import is necessary or not. Then just put the same HS_VERSION check around the import. From godzbanebane at gmail.com Fri Aug 9 11:01:08 2024 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Fri, 9 Aug 2024 14:01:08 +0300 Subject: [Haskell-cafe] no-unused-imports for only one import In-Reply-To: References: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> <780531209.127576379.1723194384155.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <9d361c5b-92a0-4ae4-8f14-b589d9fb3fb1@gmail.com> Unfortunately the status quo is indeed to use CPP around imports as well. One can imagine, with modifier syntax, some dedicated version of disabling warnings locally, but it is not something that has been implemented or even proposed yet. On 8/9/24 12:12, Henning Thielemann wrote: > > On Fri, 9 Aug 2024, PICCA Frederic-Emmanuel wrote: > >>>   import Your.Module () >>> >>> trick? That is, add empty parenthesis after your import? >> >> This code is a binding to a library and depending on values this >> import is necessary or not. > > Then just put the same HS_VERSION check around the import. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Aug 9 11:09:25 2024 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 9 Aug 2024 13:09:25 +0200 (CEST) Subject: [Haskell-cafe] no-unused-imports for only one import In-Reply-To: <9d361c5b-92a0-4ae4-8f14-b589d9fb3fb1@gmail.com> References: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> <780531209.127576379.1723194384155.JavaMail.zimbra@synchrotron-soleil.fr> <9d361c5b-92a0-4ae4-8f14-b589d9fb3fb1@gmail.com> Message-ID: <558032582.127650857.1723201765335.JavaMail.zimbra@synchrotron-soleil.fr> thanks you all for your help Fred From allbery.b at gmail.com Fri Aug 9 16:16:26 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 9 Aug 2024 12:16:26 -0400 Subject: [Haskell-cafe] no-unused-imports for only one import In-Reply-To: <558032582.127650857.1723201765335.JavaMail.zimbra@synchrotron-soleil.fr> References: <547745446.127569976.1723193385781.JavaMail.zimbra@synchrotron-soleil.fr> <780531209.127576379.1723194384155.JavaMail.zimbra@synchrotron-soleil.fr> <9d361c5b-92a0-4ae4-8f14-b589d9fb3fb1@gmail.com> <558032582.127650857.1723201765335.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: I haven't made a proposal yet, still waiting to hear back from someone about one possible tricky situation, but I actually do have a plan for this (`import Module (..)` as proposed syntax) and at some point I should put it up as an official proposal. On Fri, Aug 9, 2024 at 7:10 AM PICCA Frederic-Emmanuel < frederic-emmanuel.picca at synchrotron-soleil.fr> wrote: > thanks you all for your help > > Fred > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Thu Aug 15 14:53:38 2024 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Thu, 15 Aug 2024 16:53:38 +0200 Subject: [Haskell-cafe] Vienna Haskell Meetup on Sep 26th Message-ID: <13dfa515-c5b7-4fa0-aaae-2242fe4a52be@gmx.at> ** *Hello everyone! We are hosting a Haskell meetup in Vienna on the 26th of September! The location will be at TU Vienna Treitlstraße 3, Seminarraum DE0110. The room will open at 18:00.We plan to have 1-2 short talks starting at 19:00 (topics to be announced). Depending on interest there might also be a short Show & Tell session giving people the opportunity to show off or talk about something they work(ed) on for 5-10 Minutes each.There will be time to discuss the presentations with some snacks and non-alcoholic drinks being provided afterwards with an option to acquire beer for a reasonable price.The meetup is open ended but we might have to relocate to a nearby bar as a group if it goes very late..* *There is no entrance fee or mandatory registration, but to help with planning we ask you to let us know in advance if you plan to attend here https://forms.gle/Paiw6D4QJzTKzcmM6 or per email at haskellvienna.meetup at gmail.com. We especially encourage you to reach out if you would like to participate in the show&tell or to give a full talk so that we can ensure there is enough time for you to present your topic.We hope to welcome everyone soon, your organizers:Andreas(Andreas PK), Benny, Chris, fendor, VeryMilkyJoe, Samuel* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifl21.publicity at gmail.com Fri Aug 16 10:35:05 2024 From: ifl21.publicity at gmail.com (Mart Lubbers) Date: Fri, 16 Aug 2024 05:35:05 -0500 Subject: [Haskell-cafe] IFL 2024, final call for participation/registration Message-ID: ======================================================================= IFL 2024 36rd Symposium on Implementation and Application of Functional Languages venue: Radboud University Nijmegen, The Netherlands August 26 - 28 2024 https://ifl24.cs.ru.nl ======================================================================= ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2024 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. ### Industrial track and topics of interest Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques ### Peer-review process Following IFL tradition, IFL 2024 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. ### Important dates Submission deadline of draft papers August 6th, 2024 EXTENDED Notification of acceptance for presentation August 6th, 2024 Registration deadline August 19th, 2024 IFL symposium August 26-28, 2024 Submission of papers for proceedings December 1st, 2024 Notification of acceptance February 2nd, 2025 Camera-ready version March 2nd, 2025 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Submit your paper here: https://easychair.org/conferences/?conf=ifl20240 Register here: https://ifl24.cs.ru.nl/Registration Important note to authors about the new ACM open access publishing model ACM has introduced a new open access publishing model for the International Conference Proceedings Series (ICPS). Authors based at institutions that are not yet part of the ACM Open program and do not qualify for a waiver will be required to pay an article processing charge (APC) to publish their ICPS article in the ACM Digital Library. To determine whether or not an APC will be applicable to your article, please follow the detailed guidance here: https://www.acm.org/publications/icps/author-guidance. Further information may be found on the ACM website, as follows: - Full details of the new ICPS publishing model: https://www.acm.org/publications/icps/faq - Full details of the ACM Open program: https://www.acm.org/publications/openaccess - Please direct all questions about the new model to icps-info at acm.org. ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organisation PC Chairs: Mart Lubbers Radboud University, The Netherlands Local Chairs: Peter Achten Radboud University, The Netherlands Sven-Bodo Scholz, Radboud University, The Netherlands ### Program committee: Benoît Montagu, University of Lorraine, Inria, France Christos Dimoulas, Northwestern University, USA Edsko de Vries, Well-typed, The Netherlands Fritz Henglein, University of Copenhagen, Denmark Ian Mackie, University of Sussex, UK Jason Hemann, Seton Hall University, USA João Saraiva, Universidade do Minho, Portugal Jurriaan Hage, Heriot-Watt University, UK Kenichi Asai, Ochanomizu University, Japan Maja Kirkeby, Roskilde University, Denmark Marco Morazán, Seton Hall University, USA Neil Mitchell, Facebook, UK Ralf Laemmel, University of Koblenz Landau, Germany Rinus Plasmeijer, TOP Software/Radboud University, The Netherlands Stephen Chang, UMass Boston, USA Tim Steenvoorden, Open University, The Netherlands Tom Schrijvers, KU Leuven, Belgium Yusuf Moosa Motara, Rhodes University, South Africa ### Venue IFL 2024 will be held physically in Nijmegen, the Netherlands. See the website for more information. https://ifl24.cs.ru.nl ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here. From ivanperezdominguez at gmail.com Thu Aug 22 04:46:16 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Wed, 21 Aug 2024 21:46:16 -0700 Subject: [Haskell-cafe] [ANN] Dunai 0.13.1, dunai-test 0.13.1 and bearriver 0.14.10 Message-ID: Dear all, I'm really excited to announce the release of Dunai 0.13.1 and Bearriver 0.14.10! Dunai is a reactive programming library structured around a notion of Monadic Stream Functions. Dunai can be used to implement other reactive and FRP frameworks on top, including Classic FRP and Arrowized FRP variants. Dunai comes with: - bearriver: API-compatible implementation of Yampa. (The Bear River is a tributary to the Yampa river.) - dunai-test: QuickCheck-based temporal testing library that can be connected with the testing system haskell-titan. See https://github.com/ivanperez-keera/dunai#features for details on Dunai's features. This release fixes an issue with the dependency on the list-transformer library as an alternative to transformers. Thanks to @ tomsmeding for the contribution. This release also provides a matching FRP.BearRiver.Integration, FRP.BearRiver.Random, FRP.BearRiver.Task and FRP.BearRiver.Simulation (akin to Yampa's), including the new Yampa combinator trapezoidIntegral. This last combinator was copied almost verbatim from Yampa, and I want to thank @idontgetoutmuch , @miguel-negrao and @thalerjonathan once again for the discussion and for contributing several alternative implementations. We are now just one module away from being able to provide 100% match in bearriver for all definitions in Yampa. Special thanks go to Johannes Riecken (@johannes-riecken on github) for a regular contribution to support the dunai and Yampa projects. As always, dunai, dunai-test and bearriver are released in sync. For details, see: - https://github.com/ivanperez-keera/dunai/releases/tag/v0.13.1 *Releases* You can explore the current versions at: - https://hackage.haskell.org/package/dunai - https://hackage.haskell.org/package/dunai-test - https://hackage.haskell.org/package/bearriver *Code* The github repo is located at: https://github.com/ivanperez-keera/dunai *What's coming* This release comes exactly 2 months after the last release. The next release is planned for Oct 21, 2024. There are several issues open that you can contribute to: https://github.com/ivanperez-keera/dunai/issues Following our roadmap, the pending changes remain as follows: - Match all definitions from FRP.Yampa.Switches. - Use new performance evaluation features of Yampa to improve performance of both Yampa and dunai. - Create new examples that demonstrate the features of dunai and bearriver. *Donations* Our project is now seeking donations to help continue developing dunai, create new open source libraries, new material, and give talks. No donation is too small. Any contribution will absolutely help. See https://github.com/sponsors/ivanperez-keera for details. If you can help, please come forward. All the best, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at mailbox.org Fri Aug 23 18:49:26 2024 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Fri, 23 Aug 2024 11:49:26 -0700 Subject: [Haskell-cafe] Speeding up trivial programs Message-ID: I'm working on a small program that has to run many, many times, as quickly as possible (yes, it needs to be a standalone program). I've optimized it in many ways, but I seem to have a time floor, observable with "Hello, world" $ cat Hello.hs main = putStrLn "Hello world" $ ghc -O2 Hello.hs $ time ./Hello Hello world real 0m0.150s user 0m0.117s sys 0m0.032s The equivalent program in C takes only 0.002s (75x faster). What is taking the extra time? Is it the RTS "booting"? Is there any way to speed this up? Thanks, Tom From allbery.b at gmail.com Fri Aug 23 19:04:13 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 23 Aug 2024 15:04:13 -0400 Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: I think there's already a ticket for slow RTS startup, although I didn't find it on a quick search, and that time looks similar to the examples I saw (around a tenth of a second). On Fri, Aug 23, 2024 at 2:50 PM amindfv--- via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > I'm working on a small program that has to run many, many times, as > quickly as possible (yes, it needs to be a standalone program). > > I've optimized it in many ways, but I seem to have a time floor, > observable with "Hello, world" > > > $ cat Hello.hs > main = putStrLn "Hello world" > $ ghc -O2 Hello.hs > $ time ./Hello > Hello world > > real 0m0.150s > user 0m0.117s > sys 0m0.032s > > > The equivalent program in C takes only 0.002s (75x faster). > > What is taking the extra time? Is it the RTS "booting"? Is there any way > to speed this up? > > Thanks, > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From iustin at k1024.org Fri Aug 23 19:11:04 2024 From: iustin at k1024.org (Iustin Pop) Date: Fri, 23 Aug 2024 21:11:04 +0200 Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: On 2024-08-23 11:49:26, amindfv--- via Haskell-Cafe wrote: > I'm working on a small program that has to run many, many times, as quickly as possible (yes, it needs to be a standalone program). I'd reconsider this "needs". Or, I'd reconsider the use of Haskell. If the program is small enough that the startup time dominates, how much code can there be? A memory-safe language like Rust but which has a much smaller RTS might a better fit. regards, iustin From lemming at henning-thielemann.de Fri Aug 23 19:16:13 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 23 Aug 2024 21:16:13 +0200 (CEST) Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024, Iustin Pop wrote: > On 2024-08-23 11:49:26, amindfv--- via Haskell-Cafe wrote: >> I'm working on a small program that has to run many, many times, as >> quickly as possible (yes, it needs to be a standalone program). > > I'd reconsider this "needs". Or, I'd reconsider the use of Haskell. Or a tiny stand-alone low-level program that communicates with a server written in Haskell? From allbery.b at gmail.com Fri Aug 23 19:19:28 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 23 Aug 2024 15:19:28 -0400 Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: I think I'd be reconsidering _any_ design involving running an external program many times like that, to be honest. Dragging in potential fork delays and other overhead that a benchmark probably won't show you doesn't appeal. On Fri, Aug 23, 2024 at 3:16 PM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Fri, 23 Aug 2024, Iustin Pop wrote: > > > On 2024-08-23 11:49:26, amindfv--- via Haskell-Cafe wrote: > > >> I'm working on a small program that has to run many, many times, as > >> quickly as possible (yes, it needs to be a standalone program). > > > > I'd reconsider this "needs". Or, I'd reconsider the use of Haskell. > > Or a tiny stand-alone low-level program that communicates with a server > written in Haskell? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at mailbox.org Fri Aug 23 20:02:11 2024 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Fri, 23 Aug 2024 13:02:11 -0700 Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: On Fri, Aug 23, 2024 at 03:19:28PM -0400, Brandon Allbery wrote: > I think I'd be reconsidering _any_ design involving running an external > program many times like that, to be honest. Dragging in potential fork > delays and other overhead that a benchmark probably won't show you doesn't > appeal. Calling short-lived unix processes many times (note I didn't say where or when) might not be the right solution to most problems. (That's probably why I've never noticed this timing floor before.) But trust me, it is a real -- and actually sensible in context -- requirement here. Server/client communication is unfortunately not possible in this case. Rewriting entirely in a language other than Haskell is possible, but not what I'd prefer given that the code is fairly complex (if fast). Does anybody know more about what specifically is happening during these 150ms? Thanks, Tom From teofilcamarasu at gmail.com Fri Aug 23 20:22:15 2024 From: teofilcamarasu at gmail.com (Teofil Camarasu) Date: Fri, 23 Aug 2024 21:22:15 +0100 Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: Hi Tom, On my computer (and using GHC-9.8) it's a bit quicker: real 0m0.006s user 0m0.001s sys 0m0.005s I imagine some of this time is just loading things into memory and/or running the dynamic linker. If you are optimising for start up time, maybe fully statically linking your executable might help. Cheers, Teo On Fri, Aug 23, 2024 at 9:02 PM amindfv--- via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > On Fri, Aug 23, 2024 at 03:19:28PM -0400, Brandon Allbery wrote: > > I think I'd be reconsidering _any_ design involving running an external > > program many times like that, to be honest. Dragging in potential fork > > delays and other overhead that a benchmark probably won't show you > doesn't > > appeal. > > Calling short-lived unix processes many times (note I didn't say where or > when) might not be the right solution to most problems. (That's probably > why I've never noticed this timing floor before.) But trust me, it is a > real -- and actually sensible in context -- requirement here. > > Server/client communication is unfortunately not possible in this case. > Rewriting entirely in a language other than Haskell is possible, but not > what I'd prefer given that the code is fairly complex (if fast). > > Does anybody know more about what specifically is happening during these > 150ms? > > Thanks, > 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 ietf-dane at dukhovni.org Sat Aug 24 03:30:09 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 24 Aug 2024 13:30:09 +1000 Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: On Fri, Aug 23, 2024 at 09:22:15PM +0100, Teofil Camarasu wrote: > On my computer (and using GHC-9.8) it's a bit quicker: > real 0m0.006s > user 0m0.001s > sys 0m0.005s > > I imagine some of this time is just loading things into memory and/or > running the dynamic linker. > > If you are optimising for start up time, maybe fully statically linking > your executable might help. I see similarly low startup using GHC 9.8: $ cat hw.hs module Main(main) where main :: IO () main = putStrLn "Hello World!" $ ghc --version The Glorious Glasgow Haskell Compilation System, version 9.8.2 $ ghc -O2 hw.hs [1 of 2] Compiling Main ( hw.hs, hw.o ) [2 of 2] Linking hw $ time ./hw Hello World! real 0m0.005s user 0m0.001s sys 0m0.004s The corresponding C program is not dramatically faster: $ cat hw.c #include int main(void) { printf("Hello World!\n"); return 0; } $ cc -o hw hw.c $ time ./hw Hello World! real 0m0.002s user 0m0.000s sys 0m0.002s So 150ms is fairly anomalous, feels like a site or platform-specific issue, rather than expected RTS overhead. -- Viktor. From divya at subvertising.org Sat Aug 24 22:17:52 2024 From: divya at subvertising.org (divya at subvertising.org) Date: Sat, 24 Aug 2024 22:17:52 +0000 Subject: [Haskell-cafe] Speeding up trivial programs In-Reply-To: References: Message-ID: <2eff60840d55d70340c0d3657b70a621@subvertising.org> I don't see any significant difference: ~ via C v14.2.1-gcc via λ 9.10.1 ❯ cat hello.hs module Main where main = putStrLn "Hello!" ~ via C v14.2.1-gcc via λ 9.10.1 ❯ ./hello Hello! ~ via C v14.2.1-gcc via λ 9.10.1 ❯ time ./hello Hello! ./hello 0.00s user 0.00s system 85% cpu 0.003 total ~ via C v14.2.1-gcc via λ 9.10.1 ❯ cat hello.c #include int main () { printf("Hello"); return 0; } ~ via C v14.2.1-gcc via λ 9.10.1 ❯ ./hello Hello! ~ via C v14.2.1-gcc via λ 9.10.1 ❯ time ./hello Hello! ./hello 0.00s user 0.00s system 72% cpu 0.004 total