- Haskell-Cafe - Haskell.org

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 23 May '23

23 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 15 May '23

15 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