- Haskell-Cafe - Haskell.org

Call for Papers: JFP Special Issue on Program Calculation
by Graham Hutton 30 May '23

30 May '23

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

1 0

regex problem with ghc-8.6 and older
by Ben Franksen 29 May '23

29 May '23

Hi Everyone I was trying to fix a bug in a large program (darcs) and stumbled over a problem that I cooked down to the minimal test program below. The issue here is that with ghc-8.6 and earlier, properly handling an invalid regular expression (here: the empty string) does not work: somehow something calls "error". With ghc-8.8 and later it works as expected. In both cases the latest releases of the regex packages are used. {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Prelude hiding (fail) import Control.Monad.Fail import Control.Exception import Text.Regex.Base import Text.Regex.TDFA newtype RegexFail a = RegexFail { runRegexFail :: Either String a } deriving (Functor, Applicative, Monad) instance MonadFail RegexFail where fail = RegexFail . Left test :: RegexFail Regex test = makeRegexM "" main = handle (\(ErrorCall _) -> putStrLn "error call") $ case runRegexFail test of Left _ -> putStrLn "clean error handling" Right x -> print (matchM x "" :: Maybe Bool) > runghc-8.6 test2.hs √ error call > runghc-8.8 test2.hs √ clean error handling (1) Is this a known problem with ghc < 8.8 / base < 4.13? (2) Is there a work-around for older ghc versions? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

4 5

GHC handling of signals
by Ben Franksen 28 May '23

28 May '23

Consider the following program: import System.IO import System.IO.Error import System.Posix.Signals main = do installHandler sigPIPE Default Nothing c <- readFile "/usr/share/dict/words" putStrLn c `catchIOError` \e -> hPutStrLn stderr (show e) hPutStrLn stderr "I survived" Compile with ghc and run as ./test | true As expected, you see nothing further displayed, since according to `man 7 signal` the default for SIGPIPE is to terminate the program, which happens before the exception handler has a chance to run. Without the line where the signal handler gets installed the behavior is different: You'll see: <stdout>: commitBuffer: resource vanished (Broken pipe) I survived Apparently the GHC runtime does something like installHandler sigPIPE Ignore Nothing This is not a complaint, I find the behavior quite reasonable and much more predictable than the default (why should I not be able to catch EPIPE and continue?). The question is whether it is documented how the GHC runtime treats signals and if yes where? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

3 3

Munich Haskell Meeting, 2023-05-29 @ 19:30
by Leah Neukirchen 28 May '23

28 May '23

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 29 at 19h30. The weather should be good, so we'll meet at **Hirschgarten Biergarten**. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can look out for you. It is OK to add yourself to the nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/xduCn5pUNTlcl7dT Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

3 2

Developer Surveys
by Dev Survey 26 May '23

26 May '23

Hello Developers, No login required, anonymous survey, and takes no more than 5-10 minutes. Developer Tools Survey Shortened URL : Developer Tools Survey (Anonymous) Thanks, have a great day

3 3

Searching for dependent code
by Geraldus 26 May '23

26 May '23

Hello, dear Cafe! I have a mono repository and would like to do the following for CI: - take the files from the commit - Find all the code that depends on them explicitly or implicitly - make a list of executable files that need to be rebuilt This happens in CI and there is no cache of previous builds. Note that dependencies may not be direct, e.g: - there are packages A, B, C. - C depends only on B - B depends on A - C should be rebuilt if there were changes in A Can you please tell me if there is any ready-made solution for this?

2 1

[Haskell] [ANNOUNCE] GHC 9.2.8 released
by Zubin Duggal 26 May '23

26 May '23

The GHC developers are happy to announce the availability of GHC 9.2.8. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.2.8). This release is primarily a bugfix release addressing one issue found in 9.2.7: - Fix a bug with RTS linker failing with 'internal error: m32_allocator_init: Failed to map' on newer Linux kernels (#19421). 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 [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.8/docs/html/users_guide/9.2.8-notes.…

1 0

JOB | Platform Lead (Singapore/London)
by James Tobin 26 May '23

26 May '23

Hello I'm working with an employer that is looking to hire someone in London or Singapore to take lead on the modernisation of their on-premises environment. Consequently, I had hoped that some members of this group may like to discuss. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

2 1

Haskell Symposium'23 Calls For Papers
by Niki Vazou 26 May '23

26 May '23

Dear all, Reminder that the Haskell Symposium’23 Submission Deadline is one week away. We are looking forward for your papers. Best, Niki =============================================================================== ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2023 Seattle, WA, USA Fri 8 -- Sat 9 September, 2023 http://www.haskell.org/haskell-symposium/2023/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2023 will be co-located with the 2023 International Conference on Functional Programming (ICFP). As with last year, Haskell'23 will use a single-track submission process. That is, we will only have the regular track and no early track. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * Tutorials, to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. Like an experience report and a functional pearl, tutorials should make a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details ================== Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2023 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors' own related work should be in the third person (e.g., not "We build on our previous work" but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymised). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Tutorial: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Paper submission: 1 June 2023 (Thu) Notification: 4 July 2023 (Tue) Camera ready: 18 July 2023 (Tue) Deadlines are anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell23.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymised and non-anonymised supplementary material. Anonymised supplementary material will be visible to reviewers immediately; non-anonymised supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html) Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artefacts ========= Authors are encouraged to make auxiliary material (artefacts like source code, test data, etc.) available with their paper. Authors can opt to have these artefacts published alongside their paper in the ACM Digital Library (copyright of artefacts remains with the authors). Artefacts must be included as part of their submission to HotCRP and should consist of a .zip file containing the artefact materials, a README explaining the contents of the artefact and how it should be used, and a LICENSE file. If an accepted paper's artefacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artefact badge (https://www.acm.org/publications/policies/artifact-review-badging) Program Committee ================= Alexander Green Standard Chartered, UK David Thrane Christiansen The Haskell Foundation, Denmark Edsko de Vries Well-Typed LLP, Netherlands Exequiel Rivas Tallinn University of Technology Facundo DomÃnguez Tweag Florian Zuleger TU Vienna, Austria Graham Hutton University of Nottingham, UK Jasper Van der Jeugt Snyk, Switzerland Jennifer Paykin Intel, USA Jesper Cockx Delft University of Technology, Netherlands Jose Nuno Oliveira University of Minho & INESC TEC, Portugal Michael Sperber Active Group GmbH, Germany Michel Steuwer University of Edinburgh, UK Niki Vazou (chair) IMDEA Software Institute, Spain Rumyana Neykova Brunel University London, UK Trevor L. McDonell (co-chair) Utrecht University, Netherlands Ugo Dal Lago University of Bologna, Italy & INRIA, France Wen Kokke University of Edinburgh, UK Leonidas Lampropoulos University of Maryland, College Park, USA If you have questions, please contact the chairs at niki.vazou(a)imdea.org and t.l.mcdonell(a)uu.nl. ================================================================================

1 0

[ANN] Haskell Streamly 0.9.0 Release
by Harendra Kumar 25 May '23

25 May '23

We are glad to announce streamly 0.9.0 release. streamly-0.9.0 and streamly-core-0.1.0 have been available on Hackage for some time now. You can find the source at https://github.com/composewell/streamly and reference documentation and some guides are also available on https://streamly.composewell.com . The website also has functionality to search across multiple streamly packages. This release did a major revamp of the API to make it easier to comprehend and less error prone to use. Now there is a single "Stream" type instead of the polymorphic "IsStream" type class. There are explicit concurrency combinators to enable concurrent behavior on the same type instead of using different types for that purpose. Dependency on GHC rewrite rules has been removed for more robust behavior and better programmer control, though it required splitting the stream type into the default direct-style type "Stream" and the CPS type "StreamK". The package has been split into two, "streamly-core" intends to depend only on boot libraries (currently has some more deps due to backward compatibility), "streamly" provides higher level functionality like concurrency. Parser functionality has been released. Parsers fuse with streams and are compatible with folds i.e. parsers are folds with more power. Please see the following docs for more details: * Changelog: https://streamly.composewell.com/streamly-0.9.0/User/ProjectRelated/Changel… * Upgrade guide: https://streamly.composewell.com/streamly-0.9.0/User/ProjectRelated/Upgradi… Your feedback is important to us. We did the API revamp based on feedback from users. -harendra

1 0

what are correct ways to translate haskell code ?
by profited＠tutanota.com 24 May '23

24 May '23

let's consider this example Alice has 1.hs like this v :: (,) Int Bool v = (,) 0 False main :: IO () main = putStrLn "print some magic number" >> print ( fst v ) Bob download 1.hs from Alice Bob would like to change 1.hs to 2.hs Bob want the programs [ 1.hs 2.hs ] to behave the same the reason that Bob want to modify 1.hs may be Bob does not like the type (,) in 1.hs Bob has Vector_2.hs module Vector_2 where data Vector_2 a b = C a b x1_of :: Vector_2 a b -> a x1_of ( C x1 _ ) = x1 x2_of :: Vector_2 a b -> b x2_of ( C _ x2 ) = x2 Bob like his Vector_2.hs Bob thinks the Vector_2 shall be good enough to replace (,) in 1.hs i want to create a translator.hs for Bob Bob tell the translator.hs that Bob want to replace (,) with Vector_2 in 1.hs translator.hs automatically translate 1.hs to 2.hs 2.hs shall look like this import Vector_2 ( Vector_2 ) import qualified Vector_2 v :: Vector_2 Int Bool v = Vector_2.C 0 False main :: IO () main = putStrLn "print some magic number" >> print ( Vector_2.x1_of v ) what shall i do ?

4 4

[ANNOUNCE] GHC 9.6.2 is now available
by Ben Gamari 24 May '23

24 May '23

The GHC developers are happy to announce the availability of GHC 9.6.2. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.2 This release is primarily a bug-fix release addressing a few issues found in 9.6.2. These include: * a number of simplifier and specialisation issues (#22761, #22549) * A bug resulting in crashes of programs using the new ``listThreads#`` primop (#23071). * A compiler crash triggered by certain uses of quantified constraints (#23171) * Various bugs in the Javascript backend have been fixed (#23399, #23360, #23346) * A missing write barrier in the non-moving collector's handling of selector thunks, resulting in undefined behavior (#22930). * The non-moving garbage collector's treatment of weak pointers has been revamped which should allow more reliable finalization of ``Weak#`` closures (#22327) * The non-moving garbage collector now bounds the amount of marking it will do during the post-marking stop-the-world phase, greatly reducing tail latencies in some programs (#22929) 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 [ticket] if you see anything amiss. Happy compiling, ~ Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.2/docs/users_guide/9.6.2-notes.html

1 0

[ANN] NASA's Ogma 1.0.9
by Ivan Perez 22 May '23

22 May '23

Hi everyone! I'm thrilled to announce the release of Ogma 1.0.9! Ogma is a NASA tool that facilitates integrating runtime monitors or runtime verification applications into other systems. Use cases supported by Ogma include producing Robot Operating System (ROS 2) packages [3], NASA Core Flight System (cFS) applications [4], and components for FPrime [1] (the software framework used for the Mars Helicopter), as well as generating monitors from requirements specified in natural language [5]. Ogma is also one of the solutions recommended for monitoring in Space ROS applications [2]. Ogma leverages existing Haskell work, like the Copilot language [6] (also funded by NASA) and BNFC [7]. For more details, including videos of monitors being generated and flown in simulators, see: https://github.com/nasa/ogma * What's changed This release improves the user experience and fixes a number of bugs in the code and documentation. A new flag `--target-file-name` allows users to specify the root for C monitoring files generated by some of the backends, which makes for a simpler process. For details about the release, see: https://github.com/nasa/ogma/releases/tag/v1.0.9 * Releases Ogma is released as a collection of packages in Hackage. The entry point is https://hackage.haskell.org/package/ogma-cli. * Code The github repo is located at: https://github.com/nasa/ogma. * What's coming The next release is planned for Jul 21st, 2023. Ogma is currently undergoing the qualification process necessary for NASA Class D Software. Apart from the changes required by that process, we also have the following in our roadmap: - Extend ROS 2 monitors with further information about sources of violations. - Add tests to generated code. - Simplify NASA cFS monitor generation process. - Simplify the architecture. More specifically, we now have improved the compilation process by using a higher-kinded data structure, allowing us to incorporate different kinds of information to syntax trees used during both parsing and code generation. This feature has been prototyped, and is currently undergoing testing. We hope that you are as excited as we are and that our work demonstrates that, with the right support, Haskell can reach farther than we ever thought possible. Happy Haskelling! Ivan [1] https://github.com/nasa/fprime [2] https://space.ros.org/ [3] https://www.ros.org/ [4] https://github.com/nasa/cFS [5] https://github.com/NASA-SW-VnV/fret [6] https://github.com/Copilot-Language/copilot [7] https://github.com/BNFC/bnfc

1 0

Summer of Haskell 2023 Project Selections
by Aaron Allen 21 May '23

21 May '23

This year, Google did not select Haskell as an open-source project for the Google Summer of Code program. In line with tradition, the Haskell community stepped up, with multiple individuals, companies, and non-profit organizations funding nine significant open-source contributions to the Haskell ecosystem: - Cabal file support for HLS - Implement Resolution Methods in HLS - Goto Definition for Third-Party Libraries in HLS - Teaching Weeder About Type Class Instances - Standardize GHC’s Error Dump in JSON Format - Maximally Decoupling Haddock and GHC - Representing Pattern - Improving Calligraphy - Structured Errors and Error Codes for cabal-install For more details about the accepted projects, the participants, and the mentors, see this announcement: https://summer.haskell.org/news/2023-05-14-summer-of-haskell-2023-project-s… We would like to thank the sponsors who made this possible: - The Haskell Foundation - Kadena - Jane Street - Holmusk - Gershom Bazerman - Edward Kmett - MLabs - Flipstone

1 0

Re: [Haskell-cafe] Stackage question
by Henning Thielemann 19 May '23

19 May '23

On Fri, 19 May 2023, Henning Thielemann wrote: > On Fri, 19 May 2023, Dominick Samperi wrote: > >> The page recommends adding the package to Stackage Nightly, and I guess I >> could try the third option, resolver: nightly-2023-05-19, but this seems >> odd. Why would I release a package with a particular hard-coded date for >> nightly? Shouldn't it just be "nightly" or something like this? > > You must add your package to the build-constraints.yaml file in the > repository at: > https://github.com/fpco/stackage/ I see, you have done this. Then I think you must wait a little bit until your package is built.

1 0

Stackage question
by Dominick Samperi 19 May '23

19 May '23

Hello, Can somebody explain how to resolve a problem with the resolver, specifically, my package (mathlist) appears on the Stackage page, but with the message "This package is not in any snapshots." I tried resolver: lts-20.21 (in stack.yaml), then changed this to resolver: ghc-9.4.5, but this doesn't make any difference. The page recommends adding the package to Stackage Nightly, and I guess I could try the third option, resolver: nightly-2023-05-19, but this seems odd. Why would I release a package with a particular hard-coded date for nightly? Shouldn't it just be "nightly" or something like this? Thanks, Dominick

1 0

[Haskell] [ANNOUNCE] Haskell Language Server 2.0.0.0 released
by Zubin Duggal 19 May '23

19 May '23

Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-2.0.0.0/. These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/) or the Haskell VSCode extension. This is a fairly small release, marking the start of a new versioning where HLS and all the included packages in the distribution (plugins, ghcide etc.) will be versioned in lockstep. # Changelog - New versioning scheme for all packages distributed as part of HLS, versioning them in lockstep for each release. - Binaries for GHC 9.4.5 - Keep instance lenses stable even if parsed results are unavailable (#3545) - Keep stale lenses for module name (#3570) - Keep type lenses stable (#3558) Happy editing! - Zubin

2 1

Help with package/module naming
by David Feuer 16 May '23

16 May '23

I'm currently putting the finishing touches on the first version of a new priority queue package. It implements amortized-optimal priority queues and is intended to compete with the heaps package with a simpler, more compact, and hopefully faster implementation†. The main types are key-only and key-value priority queues, which I'm naming based on the conventions of the pqueue package: data MinQueue k data MinPQueue k a data MaxQueue k data MaxPQueue k a Additionally, the implementation uses underlying types with constant time insertion, logarithmic-time union, logarithmic time peekMin, and logarithmic time deleteMin: -- Key-value priority queues that are strict in both the key and the -- value. data MinPQueue k a -- Similar to the above, but associating -- two values with each key. The @a@ -- value is stored strictly and the @b@ value -- is stored lazily. data MinPQueue2 k a b So I have a few questions: 1. What should I name this package? 2. What should I name the modules containing the bootstrapped queues? 3. What should I name the modules containing the underlying oddly-strict queues? I don't know how many people will want to use them, but I figure they're probably just what's needed from time to time and it's better to let them loose than keep them under wraps. Finally, there is the question of how to expose internals. In addition to the queues above, with are all reasonable things for public consumption, there are modules implementing those, as well as a couple modules implementing helper types and such. I'm really no good at figuring out how to "lay out" modules in a package, so any advice would be greatly appreciated. † The heaps package uses bootstrapped skew binomial heaps (Brodal and Okasaki), achieving worst case constant-time union and peekMin and worst case logarithmic time deleteMin. The package I'm working on uses the same bootstrapping technique, but with a space-saving modification of Louis Wasserman's realization of Okasaki lazy binomial heap as the base priority queue. It achieves the same bounds, but union is only constant time in the (persistently) amortized sense; it degrades to logarithmic time in the worst case. In practice, this theoretical degradation likely doesn't matter, both because it's small and because GHC's garbage collection imposes occasional delays regardless.

2 3

QuickCheck update
by David Feuer 15 May '23

15 May '23

The latest QuickCheck release was uploaded to Hackage on 2020-11-14. There have been multiple commits to the master branch since then. konsumlamm opened an issue on 2023-03-10* requesting a new release. You responded positively, but there has been no visible progress towards that goal. Does QuickCheck need additional maintainers? * https://github.com/nick8325/quickcheck/issues/351

1 0

Is anybody on 9.6.1 having problems profiling on a Mac?
by George Colpitts 15 May '23

15 May '23

Is anybody on 9.6.1 having problems profiling on a Mac? As I reported in https://gitlab.haskell.org/ghc/ghc/-/issues/23211 ghc -prof -fprof-auto hello.hs where the file hello.hs consists of the line: main = print "hello" gets the error: Could not find module ‘Prelude’ Perhaps you haven't installed the "p_dyn" libraries for package ‘base-4.18.0.0’? It seems to me like a regression of the closed bug https://gitlab.haskell.org/ghc/ghc/-/issues/20707. Thanks George

3 10

ICFP 2023: Call for Tutorial, Panel, and Discussion Proposals
by ICFP Publicity 15 May '23

15 May '23

ICFP 2023 CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS 28th ACM SIGPLAN International Conference on Functional Programming September 4 - 9, 2023 Seattle, WA, USA https://icfp23.sigplan.org/ The 28th ACM SIGPLAN International Conference on Functional Programming will be held in Seattle, WA, USA on September 4 - 9, 2023, with the option of virtual participation. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. The tutorials may target an audience who is interested in commercial uses of functional programming, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Just like last year, following the success of the #ShutDownPL event, we are also inviting proposals for panels and discussions on topics of broader interest to the PL community. Tutorials, panels, and discussions may occur before or after ICFP, co-located with the associated workshops, on September 4 or September 8-9. ---------------------------------------------------------------------- Submission details Deadline for submission: May 23rd, 2023 Notification of acceptance: May 26th, 2023 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2023 workshop co-chairs (Arthur Azevedo de Amorim and Yannick Forster), via email to icfp-workshops-2023 AT googlegroups.com by May 23rd, 2023. Please note that this is a firm deadline. The proposal form is available at: http://www.icfpconference.org/icfp2023-files/icfp23-panel-form.txt http://www.icfpconference.org/icfp2023-files/icfp23-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2023 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Arthur Azevedo de Amorim (Boston University) Workshop Co-Chair: Yannick Forster (Inria Nantes) General Chair: Nikhil Swamy (Microsoft Research) Program Chair: Sam Lindley (University of Edinburgh) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Arthur Azevedo de Amorim and Yannick Forster), via email to icfp-workshops-2023 AT googlegroups.com

1 0

Contributing packages?
by Dominick Samperi 13 May '23

13 May '23

I just tried to upload a new Haskell package and ran into some difficulties. If I just try to upload, it fails and says I need to contact somebody in the trustees group to be added to the Uploaders group. If I try to upload a package candidate instead, it says Forbidden, No access for this resource. The Uploading packages help page is not very helpful. Also, I have a Hackage account and I can get to the account management page, and generate an auth key, but I don't know what I can do with that. It seems the package candidate feature is the way to go, since direct uploads are irreversible and more difficult to manage. Any tips would be appreciated. Thanks, Dominick

4 7

Call for Papers: Functional Software Architecture - FP in the Large
by Graham Hutton 10 May '23

10 May '23

Dear all, The first workshop on "Functional Software Architecture - FP in the Large” will be held in Seattle in Sept 2023, co-located with the ICFP conference. Please share, and submit your best papers, experience reports, and architectural pearls on large-scale functional programming! The submission deadline 1st June 2023. Best wishes, Mike Sperber and Graham Hutton Program Chairs, FUNARCH 2023 ====================================================================== *** FUNARCH 2023 -- CALL FOR PAPERS *** The First ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 8th September 2023, Seattle, Washington, USA Co-located with ICFP 2023 https://tinyurl.com/FUNARCH-23 ====================================================================== TIMELINE: Paper submission 1st June 2023 Author notification 28th June 2023 Camera ready copy 18th July 2023 Workshop 8th Sept 2023 BACKGROUND: "Functional Software Architecture" refers to methods of construction and structure of large and long-lived software projects that are implemented in functional languages and released to real users, typically in industry. The goals for the workshop are: - To assemble a community interested in software architecture techniques and technologies specific to functional programming; - To identify, categorize, and document topics relevant to the field of functional software architecture; - To connect the functional programming community to the software architecture community to cross-pollinate between the two. The workshop follows on from the Functional Software Architecture open space that was held at ICFP 2022 in Slovenia. SCOPE: The workshop seeks submissions in a range of categories: - You're a member of the FP community and have thought about how to support programming in the large, for example by framing functional ideas in architectural terms or vice verse, comparing different languages in terms of their architectural capabilities, clarifying architectural roles played by formal methods, proof assistants and DSLs, or observing how functional concepts are used in other language and architecture communities. Great, submit a research paper! - You're a member of the architecture community, and have thought about how your discipline might help functional programmers, for example by applying domain-driven design, implementing hexagonal architecture, or designing self-contained systems. Excellent, submit a research paper! - You've worked on a large project using functional programming, and it's worked out well, or terribly, or a mix of both; bonus points for deriving architectural principles from your experience. Wonderful, submit an experience report! - You know a neat architectural idiom or pattern that may be useful to others developing large functional software systems. Fabulous, submit an architectural pearl! - You have something that doesn't fit the above categories, but that still relates to functional software architecture, such as something that can be written up, or that could be part of the workshop format like a panel debate or a fishbowl. Superb, submit to the open category! Research papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and architectural pearls need not necessarily report original research results. The key criterion for such papers is that they make a contribution from which others can benefit. It is not enough simply to describe a large software system, or to present ideas that are specific to a particular system. Open category submissions that are not intended for publication are not required to follow the formatting guidelines, and can submit in PDF, word or plain text format as preferred. If you are unsure whether your contribution is suitable, or if you need any kind of help with your submission, please email the program chairs at <funarch2023(a)easychair.org>. SUBMISSION: Papers must be submitted by 1st June 2023 using EasyChair, via the following link: https://tinyurl.com/FUNARCH23-submit Formatting: submissions intended for publication must be in PDF format and follow the ACM SIGPLAN style guidelines, using the acmart format and the sigplan sub-format. Please use the review option, as this enables line numbers for easy reference in reviews. For further details, see: https://tinyurl.com/sigplan-acmart If your submission is not a research paper, please mark this using a subtitle (Experience Report, Architectural Pearl, Open Category). Length: submissions must adhere to the limits specified below. However, there is no requirement or expectation that all pages are used, and authors are encouraged to strive for brevity. Research papers 5 to 12+ pages Architectural pearls 5 to 12 pages Experience reports 3 to 6 pages Open category 1 to 6 pages Publication: The proceedings of FUNARCH 2023 will be published in the ACM Digital Library, and authors of accepted papers are required to agree to one of the standard ACM licensing options. Accepted papers must be presented at the workshop by one of the authors, but in special cases we may consider remote presentation. The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. PROGRAM CHAIRS: Mike Sperber Active Group, Germany Graham Hutton University of Nottingham, UK PROGRAM COMMITTEE: Joachim Breitner Germany Manuel Chakravarty Tweag & IOG, The Netherlands Ron Garcia University of British Columbia, Canada Debasish Ghosh LeadIQ, India Lars Hupel Giesecke+Devrient, Germany Andy Keep Meta, USA Shriram Krishnamurthi Brown University, USA Andres Löh Well-Typed, Germany Anil Madhavapeddy University of Cambridge, UK José Pedro Magalhães Standard Chartered, UK Simon Marlow Meta, UK Hannes Mehnert Robur, Germany Erik Meijer USA Ivan Perez KBR / NASA Ames Research Center, USA Stefanie Schirmer DuckDuckGo, Germany Perdita Stevens University of Edinburgh, UK Stefan Wehr Hochschule Offenburg, Germany Scott Wlaschin FPbridge, UK WORKSHOP VENUE: The workshop will be co-located with the ICFP 2023 conference at The Westin Seattle Hotel, Seattle, Washington, United States. ====================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 1

Re: [Haskell-cafe] [Haskell] The Point of this List
by Anthony Clayden 06 May '23

06 May '23

Thanks Henning, I agree. o.p. Dominic on Haskell list > I have been subscribed to this list for over 20 years ... Well, yes 20+ years ago, Haskellers were a much smaller community; 'haskell' was the only list. If you want to understand the discussions around the 1998 standard for example, that's the place to look. 'haskell-cafe' has been going for at least most of that 20 years, and is the place for more free-flowing discussion. Increasingly, 'haskell' is restricted to low-volume announcements/not discussion. I'm surprised you hadn't noticed. AntC

1 0

pretty-printing with fixed indentation increase per sub-structure
by Johannes Waldmann 04 May '23

04 May '23

Dear Cafe, I was looking for a way to pretty-print Haskell literals (with lists, tuples, records with named and positional notation) like this example ( Leftist { tree = Branch { left = Branch { left = Leaf, key = 4, right = Leaf } , key = 3 , right = Leaf } , refs = listToFM [ ( Ref 13, [ 0 ] ), ( Ref 17, [ ] ) ] } , [ Any, Any ] ) for each sub-structure, the indentation level (for the following lines) should increase - by a _fixed_ amount. in the above example: line break after "tree = Branch". But (missing from this example), line break _before_ the list starts in "{ foo = [ 42 , ... ] ... }". I found this impossible to do with wl-pprint but perhaps I did not try hard enough. Instead, I "invented" combinators `nest` and `skip` and made this prototypical implementation https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/blob/master/todoc/src/Te… (it has some explanatory text at the top) see also https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/issues/960 but certainly this cannot be a new idea. While I do like the semantics (in the context of my application), I don't like the performance of my implementation. What am I doing wrong? It's just updating indentation level and current position, this should not take any time at all? Of course, it would be best if I don't need the implementation at all - if the effect could be achieved via some combinators in established libraries (that have optimized implementation). Any pointers appreciated. Best regards - J.

4 4

Re: [Haskell-cafe] [Haskell] The Point of this List
by Henning Thielemann 04 May '23

04 May '23

On Thu, 4 May 2023, James Flanagan wrote: > Thank you for this tip. Wasn't aware of Haskell-Cafe. > > Maybe this is the right place for conference announcements then, if it's > just for announcements in general. haskell(a)haskell.org is intended for announcements of all kind, both conferences and Haskell software. I do not see a point in moving conference announcements to haskell-cafe and leave haskell(a)haskell.org for Haskell-unrelated conference spam. Btw. I moved the discussion to Haskell Cafe, because haskell(a)haskell.org is really for announcements not for discussion.

1 0

"Hey! Monad! Leave my Pure alone!"
by Scott Michel 26 Apr '23

26 Apr '23

For a number of years, I've been hacking on a Z80 processor simulator, on and off. It's generally pure code that resembles and uses State, et. al. The design issue I've run into is adding devices to the memory system, unsurprisingly typed as MemorySystem. Devices like to do I/O, which potentially "pollutes" a design with Monads. So... I'm soliciting suggestions that allow me to isolate Monadic code in the middle of pure code (which might be Quixotic, but I'll accept that risk.) MemorySystem uses interval maps containing memory regions, and a memory region can be a RAMRegion, ROMRegion or DeviceRegion. The abbreviated data declarations are: type MemRegionMap addrType wordType = IM.IntervalMap addrType (MemoryRegion addrType wordType) data MemorySystem addrType wordType where MSys :: { _regions :: MemRegionMap addrType wordType } -> MemorySystem addrType wordType data MemoryRegion addrType wordType where EmptyRegion :: MemoryRegion addrType wordType RAMRegion :: {- ... -} ROMRegion :: {- ... -} DevRegion :: {- ... -} RAMRegion-s and ROMRegion-s are unboxed vector containers, which makes reading and writing to them pure State code, i.e., the last two function arguments to the reading function are "MemorySystem ... -> (Vector wordType, MemorySystem ...)", viz: type MemReadN addrType wordType = (Vector wordType, MemorySystem addrType wordType) mReadN :: addrType -- ^ Starting address -> Int -- ^ Number of words to read -> MemorySystem addrType wordType -- ^ The memory system from which to read -> MemReadN addrType wordType Supporting DevRegion-s gets more complicated, because I/O is involved (we like consoles on our machines, yes, we do.) I'd like to keep the reader signature without unnecessarily injecting a Monad or Monad Transformer into MemoryRegion and MemorySystem, thereby keeping the Monad or transformer isolated in DevRegion. For example, an internal device reader function would have a signature similar to "... -> Device m devType -> (Vector wordType, m devType)" instead of "... -> Device m devType -> m (Vector WordType, devType)", where "m" is the Monad or transformer. I know, it's hard to jailbreak things out of a Monad, which may be answering my own question. However, it seems to me that this kind of problem occurs in real world Haskell, and I haven't encountered the real world solution. Ideas? -scooter

2 1

Front page Haskell wiki site ( https://wiki.haskell.org/Haskell )
by Henk-Jan van Tuyl 25 Apr '23

25 Apr '23

L.S., The front page of the Haskell wiki site has changed, is a cascading style sheet missing? Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. https://foldingathome.org/ -- http://Van.Tuyl.eu https://HenkJanvanTuyl.werkaandemuur.nl/ https://sfeeraandemuur.nl/winkel/nekutimo/ https://github.com/HJvT https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourde… https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl… Haskell programming --

5 5

Munich Haskell Meeting, 2023-04-27 @ 19:30
by Leah Neukirchen 24 Apr '23

24 Apr '23

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, April 27 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/potA6hxva6zSA1zG Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

[ANN] dunai-0.11.0 and bearriver-0.14.2
by Ivan Perez 21 Apr '23

21 Apr '23

Dear all, I'm really excited to announce the release of Dunai 0.11.0 and Bearriver 0.14.2! 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 has addressed mainly styling issues. All library code now conforms to the main rules of the style guide we follow (which is publicly documented). We've also addressed other minor maintenance issues, like removal of unused code and updates to the README. In total, there have been more than 100 commits. Special thanks go to Miao ZhiCheng (@hellwolf on github) for a generous donation towards this release, and 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.11.0 *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 Jun 21, 2023. 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: - Benchmarks: Facilitate making sound, evidence-based decisions about suggested improvements to the implementation, by completing a series of benchmarks. *Donations* Our project is now seeking donations to help continue developing dunai, create new open source libraries, new material, and give talks. Github will match the first 5K donated, so if you donate $1/month, github will donate the same amount. 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

1 0

3-year Research Associate or Research Assistant position in formal verification, using a proof assistant (preferably Isabelle), at the University of Sheffield
by Andrei Popescu 20 Apr '23

20 Apr '23

Dear colleagues, We have an opening for a 3-year position of either research associate or research assistant at the University of Sheffield, UK. It is on a project called "Safe and secure concurrent programming for advanced hardware architectures" and involves modelling and verification using a proof assistant, preferably Isabelle. Please share this opportunity with anyone you think might be interested. The closing date for applications is *** 23rd May 2023 *** More details can be found here: https://www.jobs.ac.uk/job/CYZ645/research-assistant-or-research-associate-… and here: https://jobs.shef.ac.uk/sap/bc/webdynpro/sap/hrrcf_a_posting_apply?PARAM=cG… Best wishes, Andrei Popescu https://www.andreipopescu.uk/

1 0

[Summer of Haskell 2023] Submit your proposal by tomorrow!
by Ida Bzowska 19 Apr '23

19 Apr '23

Hi Everyone, This is the last call to those wanting to participate in the Summer of Haskell program - project proposals are due by April 20, 2023 (tomorrow!). Details, including application instructions and a list of suggested projects and volunteer mentors, can be found at: summer.haskell.org Additionally, if your company or organization wants to support new open-source contributors, please email us at summer(a)haskell.org. Funding a stipend or two can have a significant positive impact on the Haskell ecosystem! Regards, Ida Bzowska

1 0

Re: [Haskell-cafe] Call for Papers: Functional Software
by Adrian Cochrane 19 Apr '23

19 Apr '23

Would you an experience report regarding building my own (no-JS) browserengine be appreciated? On Wed, Apr 19, 2023, at 12:00 AM, haskell-cafe-request(a)haskell.org wrote: > Dear all, > > The first workshop on "Functional Software Architecture - FP in the Large” > will be held in Seattle in Sept 2023, co-located with the ICFP conference. > > Please share, and submit your best papers, experience reports, and > architectural pearls on large-scale functional programming! > > The submission deadline 1st June 2023. > > Best wishes, > > Mike Sperber and Graham Hutton > Program Chairs, FUNARCH 2023 > > > ====================================================================== > > *** FUNARCH 2023 -- CALL FOR PAPERS *** > > The First ACM SIGPLAN Workshop on > Functional Software Architecture - FP in the Large > > 8th September 2023, Seattle, Washington, USA > Co-located with ICFP 2023 > > https://tinyurl.com/FUNARCH-23 > > ====================================================================== > > TIMELINE: > > Paper submission 1st June 2023 > Author notification 28th June 2023 > Camera ready copy 18th July 2023 > Workshop 8th Sept 2023 > > BACKGROUND: > > "Functional Software Architecture" refers to methods of construction > and structure of large and long-lived software projects that are > implemented in functional languages and released to real users, > typically in industry. The goals for the workshop are: > > - To assemble a community interested in software architecture > techniques and technologies specific to functional programming; > > - To identify, categorize, and document topics relevant to > the field of functional software architecture; > > - To connect the functional programming community to the software > architecture community to cross-pollinate between the two. > > The workshop follows on from the Functional Software Architecture > open space that was held at ICFP 2022 in Slovenia. > > SCOPE: > > The workshop seeks submissions in a range of categories: > > - You're a member of the FP community and have thought about how > to support programming in the large, for example by framing > functional ideas in architectural terms or vice verse, comparing > different languages in terms of their architectural capabilities, > clarifying architectural roles played by formal methods, proof > assistants and DSLs, or observing how functional concepts are > used in other language and architecture communities. > > Great, submit a research paper! > > - You're a member of the architecture community, and have thought > about how your discipline might help functional programmers, for > example by applying domain-driven design, implementing hexagonal > architecture, or designing self-contained systems. > > Excellent, submit a research paper! > > - You've worked on a large project using functional programming, > and it's worked out well, or terribly, or a mix of both; bonus > points for deriving architectural principles from your experience. > > Wonderful, submit an experience report! > > - You know a neat architectural idiom or pattern that may be useful > to others developing large functional software systems. > > Fabulous, submit an architectural pearl! > > - You have something that doesn't fit the above categories, but > that still relates to functional software architecture, such > as something that can be written up, or that could be part of > the workshop format like a panel debate or a fishbowl. > > Superb, submit to the open category! > > Research papers should explain their research contributions in both > general and technical terms, identifying what has been accomplished, > explaining why it is significant, and relating it to previous work, > and to other languages where appropriate. > > Experience reports and architectural pearls need not necessarily > report original research results. The key criterion for such papers > is that they make a contribution from which others can benefit. > It is not enough simply to describe a large software system, or > to present ideas that are specific to a particular system. > > Open category submissions that are not intended for publication > are not required to follow the formatting guidelines, and can > submit in PDF, word or plain text format as preferred. > > If you are unsure whether your contribution is suitable, or if > you need any kind of help with your submission, please email > the program chairs at <funarch2023(a)easychair.org>. > > SUBMISSION: > > Papers must be submitted by 1st June 2023 using EasyChair, via the > following link: https://tinyurl.com/FUNARCH23-submit > > Formatting: submissions intended for publication must be in PDF > format and follow the ACM SIGPLAN style guidelines, using the > acmart format and the sigplan sub-format. Please use the review > option, as this enables line numbers for easy reference in reviews. > For further details, see: https://tinyurl.com/sigplan-acmart > > If your submission is not a research paper, please mark this using > a subtitle (Experience Report, Architectural Pearl, Open Category). > > Length: submissions must adhere to the limits specified below. > However, there is no requirement or expectation that all pages > are used, and authors are encouraged to strive for brevity. > > Research papers 5 to 12+ pages > Architectural pearls 5 to 12 pages > Experience reports 3 to 6 pages > Open category 1 to 6 pages > > Publication: The proceedings of FUNARCH 2023 will be published in > the ACM Digital Library, and authors of accepted papers are required > to agree to one of the standard ACM licensing options. Accepted > papers must be presented at the workshop by one of the authors, but > in special cases we may consider remote presentation. > > The official publication date is the date the papers are made available > in the ACM Digital Library. This date may be up to two weeks prior to > the first day of the conference. The official publication date affects > the deadline for any patent filings related to published work. > > PROGRAM CHAIRS: > > Mike Sperber Active Group, Germany > Graham Hutton University of Nottingham, UK > > PROGRAM COMMITTEE: > > Joachim Breitner Germany > Manuel Chakravarty Tweag & IOG, The Netherlands > Ron Garcia University of British Columbia, Canada > Debasish Ghosh LeadIQ, India > Lars Hupel Giesecke+Devrient, Germany > Andy Keep Meta, USA > Shriram Krishnamurthi Brown University, USA > Andres Löh Well-Typed, Germany > Anil Madhavapeddy University of Cambridge, UK > José Pedro Magalhães Standard Chartered, UK > Simon Marlow Meta, UK > Hannes Mehnert Robur, Germany > Erik Meijer USA > Ivan Perez KBR / NASA Ames Research Center, USA > Stefanie Schirmer DuckDuckGo, Germany > Perdita Stevens University of Edinburgh, UK > Stefan Wehr Hochschule Offenburg, Germany > Scott Wlaschin FPbridge, UK > > WORKSHOP VENUE: > > The workshop will be co-located with the ICFP 2023 conference at > The Westin Seattle Hotel, Seattle, Washington, United States. > > ====================================================================== > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please contact the sender and delete the email and > attachment. > > Any views or opinions expressed by the author of this email do not > necessarily reflect the views of the University of Nottingham. Email > communications with the University of Nottingham may be monitored > where permitted by law. > > > > >

2 1

FFI: how to allocate a const char * from haskell
by PICCA Frederic-Emmanuel 18 Apr '23

18 Apr '23

Hello, I need to call a c method which take a const char * something like void hkl_holder_add_axis(const struct holder *holder, const char *name); during all the life of this object, the const char* should be accessible. So from haskell I need to create a CString which will not be affected by the garbage collection. The memory should be release only when the given object is freed. or when the program stop. when I use alloca, the memory is releases and the code segfault. I think that I could use malloc, but in that case I have a memory leak. (this is not that important in my case, since I create less than 10 of these objects). I would like you advice in order to solve this properly. thanks for your help. Frederic

4 4

[Haskell] [ANNOUNCE] GHC 9.4.5 released
by Zubin Duggal 18 Apr '23

18 Apr '23

The GHC developers are happy to announce the availability of GHC 9.4.5. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.5). Download Page: https://www.haskell.org/ghc/download_ghc_9.4.5.html Blog Post: https://www.haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.4.4. These include: * Fixes for a number of bug fixes in the simplifier (#22623, #22718, #22913, 22695, #23184, #22998, #22662, #22725). * Many bug fixes to the non-moving and parallel GCs (#22264, #22327, #22926, #22927, #22929, #22930, #17574, #21840, #22528) * A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965). * Bumping `gmp-tarballs` to a version which doesn't use the reserved `x18` register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789). * A number of improvements to recompilation avoidance with multiple home units (#22675, #22677, #22669, #22678, #22679, #22680) * Fixes for regressions in the typechecker and constraint solver (#22647, #23134, #22516, #22743) * Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing. * ... and many more. See the [release notes] for a full accounting. 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 [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.5/docs/html/users_guide/9.4.5-notes.…

1 0

function decl syntax oddities
by Anthony Clayden 18 Apr '23

18 Apr '23

Consider > let f1 x = x + 1 in f1 1 -- ==> 2 ok > let f2 x y = x + y in (f2 2) 3 -- ==> 5 ok > let (f2 x) y = x + y in f2 3 4 -- ==> 7 ok > let (f1 x) = x + 1 in f1 4 The last gives a syntax error `Parse error in pattern: f1`. This is in line with the Language Report, but why? Something to do with patterns? > let ( x ) = 1 in x -- ==> 1 ok > let (Just x) = Just 6 in x -- ==> 6, pattern binding for x ok > let Just x = Just 7 in x -- ==> 7 ok > let (CP x y) = (CP 1) 2 in x -- ==> 1.0 ok > let (CP x) y = (CP 3) 4 in x -- `Parse error in pattern: (CP x)` So the parens are optional for a pattern binding. But if you use them they must enclose the whole pattern -- unlike partially applying a data constr on rhs. OTOH for a function binding, on lhs there must be at least one var (or pattern) not appearing inside outermost parens. Why not optional parens around a whole function binding? It might be your lhs is declaring an operator. Then that can't be inside parens, fair enough: > let (Just x) +? (Just y) = (x +) y in ... -- ok > let ((Just x) +?) (Just y) = x + y in ... -- rejected Lexically we can tell a function (starts lower case) from a data constr. Why the extra restriction with the parens? AntC

1 0

data familly and `sort of` alternative
by PICCA Frederic-Emmanuel 13 Apr '23

13 Apr '23

Hello, I have this class with two data type familly class DataSource a where data DataSourcePath a :: Type data DataSourceAcq a :: Type withDataSourceP :: (Location l, MonadSafe m) => l -> DataSourcePath a -> (DataSourceAcq a -> m r) -> m r instance DataSource Double where data DataSourcePath Double = DataSourcePath'Double (Hdf5Path Z Double) | DataSourcePath'Double'Const Double deriving (Generic, Show, FromJSON, ToJSON) data DataSourceAcq Double = DataSourceAcq'Double Dataset | DataSourceAcq'Double'Const Double withDataSourceP f (DataSourcePath'Double p) g = withHdf5PathP f p $ \ds -> g (DataSourceAcq'Double ds) withDataSourceP _ (DataSourcePath'Double'Const a) g = g (DataSourceAcq'Double'Const a) the purpose of this is to let our users gives multiple way to extract a value from different sources. In the previous case, from an hdf5 file or from a constante value. The withHdf5PathP method can fail and raise an Exception. So I would like a way to provide a fallback like (pseudo code) withDataSourceP f (datapath `or` fallback) g = try datapath and if it fails fallback My question is howto write this `or` method, it is not clear to me and it seems to me that this method should be usable by all the instance. I am also not use if this is the right way to design all this. Thanks for your help. Frederic

1 0

[ANN] data-forced 0.1.0.0 released!
by Ruben Astudillo 11 Apr '23

11 Apr '23

Hello everyone, I am excited to release the first version of data-forced 0.1.0.0. You can get it on <https://hackage.haskell.org/package/data-forced-0.1.0.0> <https://github.com/RubenAstudillo/data-forced> This is a library to avoid reference leaks (liveness leaks) on long lived data structures close to main. It does so without using explicit `seq` or bang patterns, instead using CBV functions, unlifted data type and tagging evaluated values with a unexported newtype constructor. It is a bang pattern you cannot forget! # The big idea We should not throw the information that a value was forced to WHNF or NF. We neither should be required to remember to put a `seq` or BangPattern at the use site to maintain this invariant. We accomplish this using two newtypes: - `newtype ForcedWHNF a = ForcedWHNF a` - `newtype ForcedNF a = ForcedNF a` that don't have their constructors exported. Only unidirectional patterns are provided so you can de-structure them. The *only* way to construct values of these types is via two CBVs functions: - strictlyWHNF :: forall a. a -> Strict (ForcedWHNF a) - strictlyNF :: forall a. NFData a => a -> Strict (ForcedNF a) The Strict data type is inspired by its analog on the data-elevator package <https://hackage.haskell.org/package/data-elevator>. It is a UnliftedDatatype, which means it cannot contain bottoms. The dynamic semantics of bound values of unlifted data types is that *before being bound, these are evaluated to WHNF*. It is a BangPattern you cannot forget! Once you obtain the `Strict (ForcedWHNF a)` value, you de-structurate it to obtain the *lifted* `ForceWHNF a` and store that. You are guaranteed that the references necessary to force it to WHNF are now free. Hopefully you will store it on a data structure that requires values to have been forced before like import Data.Map.Lazy type Accum1 = Map Char (ForcedWHNF Int) type Accum2 = Map Char (ForcedNF (Maybe Text)) # How to use it You should tag your long lived data structures with the correct type as in the previous example. It is less ergonomic than bang patterns, but you cannot forget to put them at the call site, parse not validate. import Data.Map.Lazy as ML -- Spine strict -- No references on added leafs even though it is a lazy map. basicEvent :: ML.Map Char (ForcedWHNF Int) -> IO (ML.Map Char (ForcedWHNF Int)) basicEvent map0 = do let val0 :: Strict (ForcedWHNF Int) -- val0 = strictlyWHNF (error "argument evaluated") -- would fail val0 = strictlyWHNF (2 + 2) -- CBV function, 2 + 2 reduced before val0 is bound. Strict val1 = val0 -- De-structure map1 = ML.insert 'a' val1 map0 pure map1 -- Same as before, but not references to values that were deleted and -- not forced. basicEventPromptDeletion :: Strict (ML.Map Char (ForcedNF (Maybe Int))) -> IO (Strict (ML.Map Char (ForcedNF (Maybe Int)))) basicEventPromptDeletion (Strict map0) = do -- map0 evaluated before being bound. let val0 :: Strict (ForcedNF (Maybe Int)) val0 = strictlyWHNF ((+1) <$> Just 28) Strict val1 = val0 -- De-structure map1 :: Strict (ML.Map Char (ForcedNF (Maybe Int))) -- forced when bound as map1 map1 = Strict (ML.insert 'a' val1 map0) pure map1 # Acknowledgment Sebastian Graf (sgraf812) should take all the credit. I was inspired by his data-elevator package that solves a sightly different problem. He infact pushed the proposal for unlifted data types and made the work to integrate them to GHC.

1 0

[ANN] Yampa 0.14.2, yampa-gloss 0.2.1, haskanoid 0.1.6, and more
by Ivan Perez 09 Apr '23

09 Apr '23

Hello everyone, I'm super excited to announce the release of Yampa 0.14.2! This release also comes with accompanying releases of many related projects: yampa-test (0.14.2), simple-affine-space (0.2.1), yampa-gloss (0.2.1), Space Invaders (0.14.2), and Haskanoid (0.1.6). Yampa is a fast, elegant Functional Reactive Programming implementation. Yampa prides itself in being a long-standing community project. It has now been around for 20 years!!! See https://github.com/ivanperez-keera/yampa#features for details on Yampa's features. This release has address mainly styling issues. All library code now conforms to the main rules of the style guide we follow (which is publicly documented). We've also addressed other minor maintenance issues, like compatibility with new versions of GHC and some dependencies, installation and CI issues, fixes to the README, and pointers to related community projects. In total, there have been more than 400 commits! Special thanks go to Miao ZhiCheng (@hellwolf) for a generous donation towards this release, and to @johannes-riecken for a regular contribution to support the Yampa project. All the projects listed above have been released in sync. For details, see: - https://github.com/ivanperez-keera/Yampa/releases/tag/v0.14.2 - https://github.com/ivanperez-keera/yampa-gloss/releases/tag/v0.2.1 - https://github.com/ivanperez-keera/simple-affine-space/releases/tag/v0.2.1 - https://github.com/ivanperez-keera/SpaceInvaders/releases/tag/v0.14.2 - https://github.com/ivanperez-keera/haskanoid/releases/tag/v0.1.6 You can explore the current versions at: - https://hackage.haskell.org/package/Yampa - https://hackage.haskell.org/package/yampa-test - https://hackage.haskell.org/package/yampa-gloss - https://hackage.haskell.org/package/simple-affine-space - https://hackage.haskell.org/package/SpaceInvaders - https://hackage.haskell.org/package/haskanoid *Code* The github repos are located at: - https://github.com/ivanperez-keera/Yampa/ - https://github.com/ivanperez-keera/yampa-gloss/ - https://github.com/ivanperez-keera/simple-affine-space/ - https://github.com/ivanperez-keera/SpaceInvaders/ - https://github.com/ivanperez-keera/haskanoid/ *What's coming* This release comes exactly 2 months after the last release. The next release is planned for Jun 7, 2023. There are several issues open that you can contribute in each project's issue tracker: Following our roadmap, the pending changes remain as follows: - Removal of unnecessarily exposed elements from the interface (e.g., FRP.Yampa.Arrow.arr3) that are not used and belong in other libraries. This topic is open to discussion. - Benchmarks: Facilitate making sound, evidence-based decisions about suggested improvements to the implementation, by completing a series of benchmarks. - New mailing list: We will in the future lose access to Yale's CS department-based mailman list, and are thinking of the best place to move the mailing list to. *Donations* Our project is now seeking donations to help continue developing Yampa, create new open source libraries, new material, and give talks. Github will match the first 5K donated, so if you donate $1/month, github will donate the same amount. 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

1 0

log, exp, (**), and non-negative real numbers
by Benjamin Redelings 04 Apr '23

04 Apr '23

Hi, I'm working with some classes that handle probabilities in terms of their log or log-odds. Such classes only handle non-negative real numbers. For example, from Numeric.Log: newtype Log a = Exp { ln :: a } Since the log of a positive number can be negative, we don't want to use the same type to hold the number and its logarithm. Standard functions exp, log, and (**) are awkward because they all assume that numbers and their powers have the same type: log,exp :: a -> a (**) :: a -> a -> a In comparison the ln function from Numeric.Log has a different signature that allows a number and its logarithm to have different types: ln :: Log a -> a Exp :: a -> Log a In order to address this, I have tried defining a type class Pow: class Fractional a => Pow a where pow :: a -> Double -> a ln :: a -> Double expTo :: Double -> a Probably I should replace "Double" here by a type variable b, but I have not done so yet. I'm mostly interested in abstracting over the type of non-negative number, because I have another type Prob that is designed to handle numbers like 1e - 100000, and 1.0 - 1e-100000. data Prob = Zero | Odds Double | One | IOdds Double | Infinity -- store probability in terms of log odds = log (p/(1-p)) Q1. Does anybody know of an existing Haskell module that implements something like the Pow class above? Also, it would be nice (notationally) if I could use log, exp, and (**) instead of ln, expTo, and pow. In theory we could factor out log, exp, (**), sqrt, and logBase from Floating into a new superclass of Floating, so that Floating only contains trig and hyper-trig functions. But I suspect this will not work because the methods in class Pow are more ambiguous. For example, if (x :: Double) then you can do (expTo x :: Prob) and (expTo x :: Log Double) and they will yield different types. Q2. Does anybody have a suggestion for a nicer design? Thanks! -BenRI

4 3

APLAS 2023 first Call for Papers
by Shin-Cheng Mu 04 Apr '23

04 Apr '23

====================================================================== CALL FOR PAPERS 21st Asian Symposium on Programming Languages and Systems (APLAS 2023) Taipei, Taiwan, Sun 26 – Wed 29 November 2023 https://conf.researchr.org/home/aplas-2023 ====================================================================== IMPORTANT DATES ------------------------------------- Submission deadline: Thu 15 Jun 2023 AoE Author response: Mon 31 Jul 12:00 - Wed 2 Aug 12:00 2023 AoE Author notification: Mon 14 Aug 2023 AoE Final paper deadline: Wed 6 Sep 2023 AoE Conference: Sun 26 – Wed 29 Nov 2023 SCOPE ------------------------------------- We solicit submissions in the form of regular research papers describing original scientific research results, including system development and case studies. Among others, solicited topics include: - ** programming paradigms and styles ** : functional programming; object-oriented programming; probabilistic programming; logic programming; constraint programming; extensible programming languages; programming languages for systems code; novel programming paradigms; - ** methods and tools to specify and reason about programs and languages ** : programming techniques; meta-programming; domain-specific languages; proof assistants; type systems; dependent types; program logics, static and dynamic program analysis; language-based security; model checking; testing; - ** programming language foundations ** : formal semantics; type theory; logical foundations; category theory; automata; effects; monads and comonads; recursion and corecursion; continuations and effect handlers; program verification; memory models; abstract interpretation; - ** methods and tools for implementation ** : compilers; program transformations; rewriting systems; partial evaluation; virtual machines; refactoring; intermediate languages; run-time environments; garbage collection and memory management; tracing; profiling; build systems; program synthesis; - ** concurrency and distribution ** : process algebras; concurrency theory; session types; parallel programming; service-oriented computing; distributed and mobile computing; actor-based languages; verification and testing of concurrent and distributed systems; - ** applications and emerging topics ** : programming languages and PL methods in education, security, privacy, database systems, computational biology, signal processing, graphics, human-computer interaction, computer-aided design, artificial intelligence and machine learning; case studies in program analysis and verification. GENERAL INFORMATION ------------------------------------- Submissions should not exceed 17 pages, excluding bibliography in the Springer LNCS format. LaTeX template is available at: https://www.springer.com/gp/computer-science/lncs/conference-proceedings-gu… The accepted papers will be allowed to use one extra page for the content to accommodate feedback from the reviews in the final paper versions. Papers should be submitted via HotCRP: https://aplas2023.hotcrp.com/ The review process of APLAS 2023 is double-anonymous, with a rebuttal phase. In your submission, please, omit your names and institutions; refer to your prior work in the third person, just as you refer to prior work by others; do not include acknowledgments that might identify you. Additional material intended for reviewers but not for publication in the final version - for example, details of proofs - may be placed in a clearly marked appendix that is not included in the page limit. Reviewers are at liberty to ignore appendices and papers must be understandable without them. Submitted papers must be unpublished and not submitted for publication elsewhere. Papers must be written in English. The proceedings will be published as a volume in Springer’s LNCS series. Accepted papers must be presented at the conference. POSTERS and STUDENT RESEARCH COMPETITION ---------------------------------------- APLAS 2023 includes a Posters session and a Student Research Competition. For more details, please see the website. https://conf.researchr.org/track/aplas-2023/posters-and-src ORGANIZERS ------------------------------------- General Chair: Shin-Cheng Mu, Academia Sinica, Taiwan Program Chair: Chung-Kil Hur, Seoul National University, Korea Publicity Chair: Ryosuke Sato, University of Tokyo, Japan Program Committee: Soham Chakraborty, TU Delft, Netherlands Yu-Fang Chen, Academia Sinica, Taiwan Ronghui Gu, Columbia University, USA Ichiro Hasuo, National Institute of Informatics, Japan Ralf Jung, ETH Zurich, Switzerland Ohad Kammar, University of Edinburgh, UK Jeehoon Kang, KAIST, Korea Jieung Kim, Inha University, Korea Robbert Krebbers, Radboud University Nijmegen, Netherlands Ori Lahav, Tel Aviv University, Israel Doug Lea, State University of New York at Oswego, USA Woosuk Lee, Hanyang University, Korea Hongjin Liang, Nanjing University, China Nuno P. Lopes, University of Lisbon, Portugal Chandrakana Nandi, Certora and UW, USA Liam O'Connor, The University of Edinburgh, UK Bruno C. d. S. Oliveira, The University of Hong Kong, Hong Kong Jihyeok Park, Korea University, Korea Clément Pit-Claudel, EPFL, Switzerland Matthieu Sozeau, Inria, France Kohei Suenaga, Kyoto University, Japan Tarmo Uustalu, Reykjavik University, Iceland John Wickerson, Imperial College London, UK Danfeng Zhang, Penn State University, USA

1 0

IFL23 first CFP
by Pieter Koopman 03 Apr '23

03 Apr '23

*Call for papers* The 35th Symposium on Implementation and Application of Functional Languages (IFL 2023) Braga, Portugal, August 29th-August 31st, 2023 *Important dates* Draft paper submission: July 31st, 2023 Draft paper notification: August 1st, 2023 Early registration deadline: August 11th, 2023 Late registration deadline: August 23rd, 2023 Symposium: August 29th - August 31st (3 days) *Scope* The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2022 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: * language concepts * type systems, type checking, type inferencing * compilation techniques * staged compilation * run-time function specialization * run-time code generation * partial evaluation * abstract interpretation * metaprogramming * generic programming * automatic program generation * array processing * concurrent/parallel programming * concurrent/parallel program execution * embedded systems * web applications * embedded domain specific languages * security * novel memory management techniques * run-time profiling performance measurements * debugging and tracing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * industrial applications *Submissions and peer-review * Following IFL tradition, IFL 2023 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that accepted draft papers are presented physically at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. Contributions submitted for the draft paper deadline must be between two and twelve pages long. For submission details, please consult the IFL 2023 website at https://ifl23.github.io/ <https://ifl21-publicity-dot-yamm-track.appspot.com/2FXkDEWOUAQ2Tbyu5BN0P9Im…> . *Where * IFL 2023 will be held physically in Braga, Portugal, arranged by University of Minho. See the IFL 2023 website at https://ifl23.github.io/ <https://ifl21-publicity-dot-yamm-track.appspot.com/2vSkCLOx6DJpj_Yo1M1_gXPf…> for more information. [image: beacon]

1 0

GPT & Haskell
by Gregory Guthrie 02 Apr '23

02 Apr '23

>From a colleague: GPT Pretty smart(?!). But this is of course simple, and searchable. Still... -------------------------------------------------------------------------------------------------- GPT-4 when prompted: Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states. gives the following response: -- Binary search in Haskell -- Precondition: the list is sorted in ascending order -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise -- Invariant: the search space is always within the bounds of the list -- Variant: the search space decreases by half at each recursive call -- Internal state: the lower and upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe Int binarySearch xs x = go xs x 0 (length xs - 1) where go xs x lo hi | lo > hi = Nothing -- base case: search space is empty | x == midElem = Just mid -- base case: target element is found | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half where mid = (lo + hi) `div` 2 -- calculate the middle index midElem = xs !! mid -- get the middle element -- Print results using putStrLn main :: IO () main = do let xs = [1, 3, 5, 7, 9] -- a sorted list of integers let x = 5 -- a target element to search for let result = binarySearch xs x -- call the binary search function case result of -- pattern match on the result Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned The above code runs: https://onecompiler.com/cpp/3z48yt2pp [cid:image001.png@01D963E1.B0EB6AB0]

20 38

Re: [Haskell-cafe] GPT & Haskell
by Aloïs Cochard 01 Apr '23

01 Apr '23

Thanks for fixing the link Nenad, I leave you with an excerpt from Oleg's last paper which contains that beautiful quote: ``This make me think that the authors are under the impression that compilers can magically transform bad code into efficient high-quality code by clever enough optimizations. As a compiler writer, I consider this a complete myth that many students and non-compiler-developers hope is a truth. I agree that compilers should aim to improve the efficiency of the code given as input, but one cannot expect the compiler to recognize algorithms and swap them for ones with better asymptotic complexity or *make other major code transformations that really should be the job of the programmer*. [emphasis mine]'' Magnus Myreen. On Sat, 1 Apr 2023 at 18:06, Nenad Končar <nlpresearcher(a)gmail.com> wrote: > GPT-4 when prompted with an improved prompt: > > *Write binary search in Haskel. Print results using putStrLn. Ensure > bug-free code by specifying preconditions, postconditions, invariants, > variants and internal states. Calculate the middle index using a safer > formula to avoid intermediate overflow.* > > > > gives the following response: > > *-- Binary search is a recursive algorithm that finds an element in a > sorted list by* > > *-- repeatedly dividing the list into two halves and comparing the element > with the middle value.* > > *-- It returns the index of the element if found, or Nothing otherwise.* > > > > *-- Precondition: The input list must be sorted in ascending order.* > > *-- Postcondition: The output index must be within the bounds of the list > and point to the element, or be Nothing.* > > *-- Invariant: The element, if present, must be in the current sublist.* > > *-- Variant: The length of the current sublist decreases by half at each > recursive call.* > > *-- Internal state: The current sublist is defined by two indices: low and > high.* > > > > *binarySearch :: Ord a => [a] -> a -> Maybe Int* > > *binarySearch xs x = go xs x 0 (length xs - 1)* > > * where* > > * -- The go function performs the recursive search on the sublist > [low..high].* > > * go :: Ord a => [a] -> a -> Int -> Int -> Maybe Int* > > * go xs x low high* > > * -- Base case 1: The sublist is empty, so the element is not found.* > > * | low > high = Nothing* > > * -- Base case 2: The middle value is equal to the element, so the > index is found.* > > * | xs !! mid == x = Just mid* > > * -- Recursive case 1: The element is smaller than the middle value, > so search in the left half.* > > * | x < xs !! mid = go xs x low (mid - 1)* > > * -- Recursive case 2: The element is larger than the middle value, > so search in the right half.* > > * | otherwise = go xs x (mid + 1) high* > > * where* > > * -- Calculate the middle index using a safer formula to avoid > overflow.* > > * mid = low + (high - low) `div` 2* > > > > *-- A sample list to test the binary search function.* > > *sampleList :: [Int]* > > *sampleList = [1, 3, 5, 7, 9, 11, 13, 15]* > > > > *-- A sample element to search for in the list.* > > *sampleElement :: Int* > > *sampleElement = 9* > > > > *-- Print the result of the binary search using putStrLn.* > > *main :: IO ()* > > *main = do* > > * let result = binarySearch sampleList sampleElement* > > * case result of* > > * Nothing -> putStrLn "Element not found."* > * Just i -> putStrLn $ "Element found at index " ++ show i ++ "."* > > The above code runs: > *https://onecompiler.com/haskell/3z4c7f5dt > <https://onecompiler.com/haskell/3z4c7f5dt>* > > > Furthermore, GPT-4 when prompted: > > *For the binary search algorithm, list all possible preconditions, > postconditions, invariants, variants, internal states, underflows, > overflows, divisions by zero, mistakes, errors, bugs, run-time exceptions, > faults, defects and pitfalls.* > > and then prompting GPT-4 again with: > > *Summarize the following:* > > *<result from the previous prompt given to * *GPT-4* > *>* > > gives the following response: > > *Hi there,* > > *I hope this email finds you well. I am writing to summarize the > following:* > > > > > > > > > > > *- The algorithm searches for a target value in a sorted array using > binary search. - The algorithm returns the index of the target value in the > array or -1 if the target value is not found. - The algorithm does not > modify the input array. - The algorithm assumes that the input array is > sorted in ascending or descending order, the target value is comparable > with the elements of the array, and the lower and upper bounds of the > search range are valid indices of the array. - The algorithm maintains the > invariant that the target value is always within the search range or does > not exist in the array. - The algorithm reduces the size of the search > range by at least one after each iteration. - The algorithm handles edge > cases such as empty array, single element array, target value at the first > or last position of the array, lower and upper bounds being equal, negative > or large positive integers, and division by zero when calculating the > middle index. - The algorithm avoids integer underflow or overflow when > calculating the middle index by using bitwise operations instead of > arithmetic operations. - The algorithm has been tested with various test > cases to ensure its correctness and efficiency. - The algorithm has been > verified using formal methods to prove its preconditions, postconditions, > invariants and variants.* > *Please let me know if you have any questions or feedback about the > algorithm. I appreciate your time and attention.* > > > The following web pages provide some credence to GPT-4's claim of > avoiding overflows/underflows by using bitwise operations instead of > arithmetic operations: > > https://stackoverflow.com/questions/10078778/bitwise-overflow-checking-in-c > > https://www.opensourceforu.com/2009/03/joy-of-programming-how-to-detect-int… > > The truth is that bitwise operations can recognise if an overflow is about > to happen prior to it happening. I do not see how bitwise operations can > *avoid* overflow and therefore GPT-4's claim in this case, in my humble > view, should be classified as it having a *vivid imagination*. > > > > > > > On Sat, 1 Apr 2023 at 16:11, Nenad Končar <nlpresearcher(a)gmail.com> wrote: > >> Here is the correct link to Haskel code: >> >> https://onecompiler.com/haskell/3z4c7f5dt >> >> On Sat, 1 Apr 2023 at 15:42, Gregory Guthrie <guthrie(a)miu.edu> wrote: >> >>> Yes, will check on it. >>> >>> >>> >>> That is because the reason that a simple program was used was because >>> the example was to ask GPT to solve it is a range of languages, one of >>> which was Haskell and there were links to solutions in all of them.. >>> >>> >>> >>> “*Write binary search in xxxx. Ensure bug-free code by specifying >>> preconditions, postconditions, invariants, variants, internal states.”* >>> >>> >>> >>> { HTML, CSS and JavaScript, C++, Haskell, JavaScript, Python, >>> CommonLisp, C, C#, PHP, Java, Go, Erlang, Alloy, TLA+, X-Machine, PVS >>> Verifier, SPIN model checker, Guarded Command Language, Hoare triples, >>> Gries & Owicki concurrent code} >>> >>> >>> >>> It was an interesting exercise from Dr. Nenad Koncar, a successful NL >>> researcher and developer. I’ll ask him for a corrected link to the Haskell >>> version. >>> >>> >>> >>> Dr. Gregory Guthrie >>> >>> >>> >>> *From:* Aloïs Cochard <alois.cochard(a)gmail.com> >>> *Sent:* Saturday, April 1, 2023 8:23 AM >>> *To:* Gregory Guthrie <guthrie(a)miu.edu> >>> *Cc:* haskell-cafe(a)haskell.org; Nenad Končar <nlpresearcher(a)gmail.com>; >>> Haskell Community < >>> replies+f6607596e3ee63f105e2b0327b86f062(a)discourse.haskell.org> >>> *Subject:* Re: [Haskell-cafe] GPT & Haskell >>> >>> >>> >>> Dear Gregory, >>> >>> >>> >>> Can you please fix your onecompiler vanity link? It points to the C++ >>> runtime implementation. >>> >>> >>> >>> Thanks >>> >>> >>> >>> On Fri, 31 Mar 2023 at 22:04, Gregory Guthrie <guthrie(a)miu.edu> wrote: >>> >>> From a colleague: >>> >>> GPT Pretty smart(?!). >>> >>> But this is of course simple, and searchable. >>> >>> >>> >>> Still… >>> >>> >>> -------------------------------------------------------------------------------------------------- >>> >>> GPT-4 when prompted: >>> >>> *Write binary search in Haskel. Print results using putStrLn. Ensure >>> bug-free code by specifying preconditions, postconditions, invariants, >>> variants, internal states.* >>> >>> >>> >>> gives the following response: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *-- Binary search in Haskell -- Precondition: the list is sorted in >>> ascending order -- Postcondition: the function returns the index of the >>> target element if found, or Nothing otherwise -- Invariant: the search >>> space is always within the bounds of the list -- Variant: the search space >>> decreases by half at each recursive call -- Internal state: the lower and >>> upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe >>> Int binarySearch xs x = go xs x 0 (length xs - 1) where go xs x lo hi >>> | lo > hi = Nothing -- base case: search space is empty | x == >>> midElem = Just mid -- base case: target element is found | x < >>> midElem = go xs x lo (mid - 1) -- recursive case: search in the left half >>> | otherwise = go xs x (mid + 1) hi -- recursive case: search in the >>> right half where mid = (lo + hi) `div` 2 -- calculate the >>> middle index midElem = xs !! mid -- get the middle element -- Print >>> results using putStrLn main :: IO () main = do let xs = [1, 3, 5, 7, 9] >>> -- a sorted list of integers let x = 5 -- a target element to search for >>> let result = binarySearch xs x -- call the binary search function case >>> result of -- pattern match on the result Nothing -> putStrLn "Element >>> not found" -- print a message if Nothing is returned Just i -> putStrLn >>> $ "Element found at index " ++ show i -- print a message with the index if >>> Just i is returned* >>> >>> >>> >>> The above code runs: >>> >>> *https://onecompiler.com/cpp/3z48yt2pp >>> <https://onecompiler.com/cpp/3z48yt2pp>* >>> >>> _______________________________________________ >>> 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. >>> >>> >>> >>> -- >>> >>> *Λ\oïs* >>> >>> http://twitter.com/aloiscochard >>> >>> http://github.com/aloiscochard >>> >> -- *Λ\oïs* http://twitter.com/aloiscochard http://github.com/aloiscochard

1 0

Re: [Haskell-cafe] GPT & Haskell
by Gregory Guthrie 01 Apr '23

01 Apr '23

---------- Forwarded message ---------- From: "Nenad Končar" <nlpresearcher(a)gmail.com<mailto:nlpresearcher@gmail.com>> To: Levent Erkok <erkokl(a)gmail.com<mailto:erkokl@gmail.com>> Cc: Gregory Guthrie <guthrie(a)miu.edu<mailto:guthrie@miu.edu>>, "haskell-cafe(a)haskell.org<mailto:haskell-cafe@haskell.org>" <haskell-cafe(a)haskell.org<mailto:haskell-cafe@haskell.org>>, Haskell Community <replies+f6607596e3ee63f105e2b0327b86f062(a)discourse.haskell.org<mailto:replies%2Bf6607596e3ee63f105e2b0327b86f062@discourse.haskell.org>> Bcc: Date: Sat, 1 Apr 2023 00:00:09 +0200 Subject: Re: [Haskell-cafe] GPT & Haskell On Fri, 31 Mar 2023 at 23:24, Levent Erkok <erkokl(a)gmail.com<mailto:erkokl@gmail.com>> wrote: This code is buggy when lo + hi overflows your integer type. Classic (extremely) corner case bug: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html Thank you kindly for pointing this out. GPT-4, when prompted, is able to detect and correct the overflow mistake as follows: After I introduced a purposeful mistake in the Haskel code, I prompted GPT-4 as follows: If the following Haskel code contains any logical mistakes then correct the code for me: -- Binary search in Haskell -- Precondition: the list is sorted in ascending order -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise -- Invariant: the search space is always within the bounds of the list -- Variant: the search space decreases by half at each recursive call -- Internal state: the lower and upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe Int binarySearch xs x = go xs x 0 (length xs - 1) where go xs x lo hi | lo > hi = Nothing -- base case: search space is empty | x == midElem = Just mid -- base case: target element is found | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half where mid = (lo - hi) `div` 2 -- calculate the middle index midElem = xs !! mid -- get the middle element -- Print results using putStrLn main :: IO () main = do let xs = [1, 3, 5, 7, 9] -- a sorted list of integers let x = 5 -- a target element to search for let result = binarySearch xs x -- call the binary search function case result of -- pattern match on the result Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned and then GPT-4 replied: Hello, Thank you for sending me your Haskell code for binary search. I appreciate your interest in learning this functional programming language. I have reviewed your code and found a few logical mistakes that need to be corrected. Here is the revised code with some comments explaining the changes: -- Binary search in Haskell -- Precondition: the list is sorted in ascending order -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise -- Invariant: the search space is always within the bounds of the list -- Variant: the search space decreases by half at each recursive call -- Internal state: the lower and upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe Int binarySearch xs x = go xs x 0 (length xs - 1) where go xs x lo hi | lo > hi = Nothing -- base case: search space is empty | x == midElem = Just mid -- base case: target element is found | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half where mid = lo + (hi - lo) `div` 2 -- calculate the middle index using a safer formula to avoid overflow midElem = xs !! mid -- get the middle element -- Print results using putStrLn main :: IO () main = do let xs = [1, 3, 5, 7, 9] -- a sorted list of integers let x = 5 -- a target element to search for let result = binarySearch xs x -- call the binary search function case result of -- pattern match on the result Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned The main mistake in your code was in the calculation of the middle index. You used `(lo - hi) `div` 2`, which is incorrect because it will always give a negative value. The correct formula is `lo + (hi - lo) `div` 2`, which ensures that the middle index is always within the bounds of the list. This formula also avoids overflow issues that might occur if you use `(lo + hi) `div` 2`. I hope this helps you understand binary search better and improve your Haskell skills. Please let me know if you have any questions or feedback. I would love to hear from you and help you further. Happy coding! The improved code runs: https://onecompiler.com/haskell/3z4avpx6n On Mar 31, 2023, at 1:02 PM, Gregory Guthrie <guthrie(a)miu.edu<mailto:guthrie@miu.edu>> wrote: From a colleague: GPT Pretty smart(?!). But this is of course simple, and searchable. Still… -------------------------------------------------------------------------------------------------- GPT-4 when prompted: Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states. gives the following response: -- Binary search in Haskell -- Precondition: the list is sorted in ascending order -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise -- Invariant: the search space is always within the bounds of the list -- Variant: the search space decreases by half at each recursive call -- Internal state: the lower and upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe Int binarySearch xs x = go xs x 0 (length xs - 1) where go xs x lo hi | lo > hi = Nothing -- base case: search space is empty | x == midElem = Just mid -- base case: target element is found | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half where mid = (lo + hi) `div` 2 -- calculate the middle index midElem = xs !! mid -- get the middle element -- Print results using putStrLn main :: IO () main = do let xs = [1, 3, 5, 7, 9] -- a sorted list of integers let x = 5 -- a target element to search for let result = binarySearch xs x -- call the binary search function case result of -- pattern match on the result Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned The above code runs: https://onecompiler.com/cpp/3z48yt2pp <image001.png> _______________________________________________ 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.

1 0

[Haskell] [ANNOUNCE] Haskell Language Server 1.10.0.0 released
by Zubin Duggal 31 Mar '23

31 Mar '23

Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-1.10.0.0/. These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/) or version [2.0.0 and above](https://github.com/haskell/vscode-haskell/releases) of the VSCode extension. Older versions of the VSCode extension will not attempt to download this version. # Changelog - Support for GHC 9.6 - Binaries for GHC 9.2.7 and GHC 9.6.1 - Eval plugin support for GHC 9.4+ (#3391) - Don't show lenses for TH generated instances when using hls-class-plugin (#3531) For the full release notes, see https://github.com/haskell/haskell-language-server/releases/tag/1.10.0.0 Happy editing! - Zubin

2 1

Munich Haskell Meeting, 2023-03-29 @ 19:30
by Leah Neukirchen 28 Mar '23

28 Mar '23

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 29 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 dudle anonymously or pseudonymously. https://nuudel.digitalcourage.de/21as1kuu1eUg8qTt Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

2 1

PhD Position at KU Leuven
by Tom Schrijvers 27 Mar '23

27 Mar '23

Dear Haskell Cafe, Are you a highly motivated individual with a passion for programming languages and theory? Do you hold a master's degree in computer science or a related field and have a proven academic track record? If so, we invite you to apply for the PhD Position in Programming Languages at KU Leuven. In this position, you will join the team of Professor Tom Schrijvers, which has a strong reputation in programming language research, covering topics such as functional programming, domain-specific languages, and equational reasoning. Your research will focus on multi-stage programming and computational effects, with the aim of developing a formal calculus for multi-staging with support for algebraic effects and handlers. You will benefit from a competitive monthly stipend, an exciting interdisciplinary research environment, and the opportunity to attend international conferences and collaborate with international partners. Apply now and advance the state-of-the-art in programming language research. For more information and applications, see: https://www.kuleuven.be/personeel/jobsite/jobs/60203785?hl=en&lang=en Best, Tom Schrijvers

1 0

Basic list exercise
by Todd Wilson 27 Mar '23

27 Mar '23

Dear Cafe, Here's a basic exercise in list processing: define a function runs :: Ord a => [a] -> [[a]] that breaks up its input list into a list of increasing "runs"; e.g., runs [3,4,5,6,2,3,4,1,2,1] ---> [[3,4,5,6],[2,3,4],[1,2],[1]] A natural solution is the following: runs [] = [] runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs where run x [] = ([], []) run x (y:ys) = if x <= y then let (us, vs) = run y ys in (y:us, vs) else ([], y:ys) My question: can we do better than this? It seems that this solution is constantly building and breaking apart pairs. (Or is it, when optimized?) Todd Wilson

6 12

Re: [Haskell-cafe] Basic list exercise
by Johannes Waldmann 26 Mar '23

26 Mar '23

Dear Anthony, and Cafe, > ... get sidetracked into all sorts of places you didn't ask about that's the semantics of "-cafe"? I think we agree. In that spirit, allow me to continue with some more tangential remarks. > Haskell community is so off-putting to learners ... I think a language (or other tool) is best for learning if it shows the concepts (that are the subject of the study) most clearly, instead of ignoring, hiding, or sugarcoating them. > So now they have to find out about `Ordering` > and generic compare functions. Yes - that's algebraic data types, higher order functions, generic polymorphism. You don't get Haskell without that. (By definition: functional, strongly typed) Now we might argue whether that's really the concepts that are needed to answer the original question of this thread. In a way, yes - it is about runs in a list, and a run is defined with respect to an order, so it feels natural that the order is an input of the problem. In another way, no (I think that is your point) - it was about efficient implementation, and that could as well be discussed with a monomorphic type and some fixed order. I found the original question interesting, and I thought that authors of the standard library must have asked the same thing, and the resulting library source code seems to confirm what the OP conjectured: there is no easy way to get ascending runs. How bad is it? I made this experiment: import Criterion.Main import qualified Data.List as L main = do let up = [1 .. 10^7 :: Int] down = reverse up print (sum up, sum down) defaultMain [ bench "length up" $ nf length up , bench "length down" $ nf length down , bench "sort up" $ nf L.sort up , bench "sort down" $ nf L.sort down ] and it shows that sorting an ascending list (which just builds the one ascending run) takes three times the work of just traversing it, but sorting a descending list (building one descending run) only two times. Now, I am not too much worried about efficiency of these particular functions (ascending/descending/sort) because I firmly believe that: 1. using a list as a container is wrong (did you mean Data.Sequence?) 2. sorting lists is more wrong (use Data.Set from the start) 3. writing a sort function yourself is most wrong, - of course with the caveat: 0. unless you get this as homework. Then you should absolutely do it (and then learn from it, and then forget the concrete instance). What worries me here much more deeply is https://github.com/haskell/criterion/issues/273 yes, that's another thing the OP did not ask about. - J.W.

1 0