- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Preferred syntax for append
by Olaf Klinke 13 May '24

13 May '24

> Concatenation with (<>) is more meaningful and holds better semantics > than (<|>), described as just "An associative binary operation". (<>) is also "just an associative binary operation", no more guarantees than (<|>). That said, for append (<>) should be preferred over (<|>) because one can then switch to more efficient append implementations just by changing the type signature, e.g. when switching from String to Text: The former is an Alternative, the latter ist not. (<|>) for list models non-deterministic choice, which can be useful in combinatorial problems. Olaf

1 0

GHC 9.10.1 is now available
by Ben Gamari 11 May '24

11 May '24

The GHC developers are very pleased to announce the release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org] and shortly via [GHCup]. GHC 9.10 brings a number of new features and improvements, including: * The introduction of the `GHC2024` language edition, building upon `GHC2021` with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * [Extension] of LinearTypes to allow linear `let` and `where` bindings * The implementation of the [exception backtrace proposal], allowing the annotation of exceptions with backtraces, as well as other user-defined context * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes can be found in the [release notes]. As always, GHC's release status, including planned future releases, can be found on the [GHC Wiki]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.10.1/docs/users_guide/9.10.1-notes.html [GHC Wiki]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624 [downloads.haskell.org] https://downloads.haskell.org/ghc/9.10.1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [GHCup]: https://www.haskell.org/ghcup/

1 0

System.IO but not with Data.String?
by Hilco Wijbenga 10 May '24

10 May '24

Hi all, We have Text and ByteString as alternatives to String but as soon as you want to do anything IO related (read a file, get a directory's content, et cetera) it seems your only option is to use String. For an occasional IO action, this is obviously irrelevant but for a compiler, a build system, or anything else that does a lot of IO this seems like it would be(come) an issue. So I was wondering what would be involved in adding (portable) support for System.IO with an alternative to String (this alternative does not necessarily need to be Text or ByteString). I did a little bit of research into how GHC handles this and there appear to be several other String types in the GHC tree, including ByteString(?). How feasible is an alternative System.IO API? How tied to GHC would such an alternative need to be? To be clear, I am not looking to _replace_ System.IO but to _add_ an alternative API (and not a wrapper that maps to/from String). Please do not assume I necessarily know what I am talking about! Especially, when it comes to the "portable" part. :-) Cheers, Hilco

5 8

[ANN] Jacinda 3.0.1.0, a functional AWK standin
by Vanessa McHale 10 May '24

10 May '24

Hello all, I recently rewrote the backend to Jacinda, a functional riff on AWK: https://hackage.haskell.org/package/jacinda See the github https://github.com/vmchale/jacinda/?tab=readme-ov-file#installation and also the guide https://vmchale.github.io/jacinda/ Cheers, Vanessa McHale

1 0

[ANN] Cabal 3.12 released
by Francesco Ariis 08 May '24

08 May '24

Dear cafe, Cabal team is happy to announce the release of `Cabal` the library version `3.12.0.0` and the companion pre-release of `cabal-install` (the commandline tool; scroll down for more information). ## What is new? There are a number of new features in this release (`Cabal`) and pre-release (`cabal-install`), such as: - Add support for `asm`, `cmm`, and `js` sources in executable components. - Add `--haddock-output-dir` flag to `cabal haddock`. - Add `--semaphore` option to `./Setup build` interface. - Add `--promised-dependency` flag to `./Setup configure` interface. - Add the ability to `--ignore` specific checks to `cabal check`. - Add support for `GHC2024` language edition. - Add support for loading multiple components into one repl session (especially important for HLS users). - Add `cabal path` command. - Add support for authentication tokens for uploading to Hackage. - Allow more flags in the init section of config file. - Add `--semaphore` flag to enable interaction with GHC Job Server protocol. - Adds functionality for the `--offline` flag with the `build` command. - Improve solver rejections in brevity and accuracy. There is much more: for a detailed list of enhancements, changes, and bugfixes, please check the Cabal-3.12.0.0 changelog [1] (and the cabal-install 3.12.0.0-prerelease changelog [2]. [1] https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.12.0.0.md [2] https://github.com/haskell/cabal/blob/master/release-notes/WIP-cabal-instal… ## Authors and contributors Cabal is a collaborative effort; these people contributed with code to this release: aleeusgr Adam Gundry Andrea Bedini Andreas Abel Andreas Klebinger Arjun Kathuria Artem Pelenitsyn BasLaa Bas Laarakker Ben Gamari Bodigrim Brandon Chinn Brandon S. Allbery Bryan Richter Colton Clemmer Csaba Hruska cydparser Daniel Trstenjak David Binder David Christiansen Edwin Marshall Elodie Lander Erik de Castro Lopo Felix Yan Fendor Finley Francesco Ariis Francesco Gazzetta Fraser Tweedale Gershom Bazerman Hamish Mackenzie Hécate Moonlight Ikko Eltociear Ashimine Jana Chadt Javier Sagredo Jean-Paul Calderone Jens Petersen Jessica Hamilton John Paul Adrian Glaubitz Josh Meredith Julia Longtin Julian Ospald Kazuki Okamoto Kleidukos Kristen Kozak Krzysztof Gogolewski liamzee Liisi Kerik Lin Runze malteneuss Malte Neuss Marcin Szamotulski Matthew Pickering Mel Zuser Michael Peyton Jones Mike Pilgrem Mikolaj Konarski mixphix Oleg Grenrus Ondřej Šebek Patrick Augusto Patrick Dougherty Phil de Joux Pierre Le Marre Rebecca Turner Rodrigo Mesquita Ryan Scott Samuel Thibault Sander Sebastian Tee Sergey Vinokurov Shae Erisson sheaf Simon Hengel Siyuan Chen Sören Tempel Suganya Raju Sylvain Henry Taylor Fausak Teo Camarasu Tom Ellis Tom Smeding Torsten Schmits Tristan Cacqueray Troels Henriksen Wismill Yvan Sraka The release could not be done without the help of the manual QA team and devops people, we thank them both. Thanks also to the many users who provided bug reports and suggestions for improvements. A special mention to Hécate, who recently stepped down from Cabal release coordination and left the process in a better, more organised shape than what was before. ## How to get the `cabal-install` pre-release This release is a Cabal-the-library release, but if you want to test the new features of `cabal-install`, you can download the pre-release of the commandline tool via GHCup. Use one of the following commands, depending on your OS: ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848320/artifacts/raw/out/c…' 3.12.0.0-prerelease ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848326/artifacts/raw/out/c…' 3.12.0.0-prerelease ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848327/artifacts/raw/out/c…' 3.12.0.0-prerelease or an analogous command for any other of the artifacts produced by the [pre-release pipeline](https://gitlab.haskell.org/haskell/cabal/-/pipelines/93759). ## How to help? Cabal is a complex piece of software running on many different machine. Two easy ways to help the development team producing quality releases are: - Join the manual QA team - Test nightly binary `cabal-install` snapshots and pre-releases (such as the 3.12.0.0 pre-release mentioned above) and report any problem you find. [3] https://discourse.haskell.org/t/manual-qa-for-cabal-install/6225

1 0

[Haskell] [ANNOUNCE] Haskell Language Server 2.8.0.0 released
by Zubin Duggal 08 May '24

08 May '24

The HLS team is pleased to announce the release of Haskell Language Server [2.8.0.0](https://github.com/haskell/haskell-language-server/releases/tag/2.…. Binaries for this release are available at [Index of /~hls/haskell-language-server-2.8.0.0/](https://downloads.haskell.org/~hls/haskell-language-server-2.8.0.0/). All of these tarballs have associated GPG signatures. The signature should be from `Zubin Duggal <zubin(a)well-typed.com>` (key ID [588764FBE22D19C4](https://keys.openpgp.org/search?q=588764FBE22D19C4)) The prebuilt binaries in this release support the following GHC versions: - 9.2.8 - 9.4.8 - 9.6.5 - 9.8.2 # Changelog - Bindists for GHC 9.6.5 - New hls-notes plugin (#4126, @jvanbruegge) - Floskell, hlint and stylish-haskell plugins enabled for GHC 9.8 - Improvements for hls-graph increasing robustness (#4087, @soulomoon) - Improvements to multi-component support (#4096, #4109, #4179, @wz1000, @fendor) Happy editing! - Zubin

1 0

Help with GHC.Generics -- How to get field selector name into value level?
by Compl Yue 07 May '24

07 May '24

Greetings! I’m stuck: ```hs -- | a named (with a selector) field instance (KnownSymbol sel, DbaStorable' f, f ~ K1 R c, DbaField c ft, Typeable c) => DbaStorable' (M1 S ('MetaSel ('Just sel) su ss ds) f) where -- _loadDbaField store bsp fno cno vin = M1 <$> _loadDbaField store fsp fno cno vin where fieldName = symbolVal (Proxy @sel) fieldPath = fieldName ++ "::" ++ dbaBasePath @c fsp = case bsp of "" -> fieldPath -- a field of a top level record _ -> bsp ++ "/" ++ fieldPath -- a field of a nested record _storeDbaField store bsp fno cno m@(M1 xr) = _storeDbaField store fsp fno cno xr where fieldName = selName m fieldPath = fieldName ++ "::" ++ dbaBasePath @c fsp = case bsp of "" -> fieldPath -- a field of a top level record _ -> bsp ++ "/" ++ fieldPath -- a field of a nested record ``` With the `selName` approach as in the `_storeDbaField ` above, it’s rejected as: ```log • Could not deduce (GHC.Generics.SingI su) arising from a use of ‘selName’ from the context: (KnownSymbol sel, DbaStorable' f, f ~ K1 R c, DbaField c ft, Typeable c) bound by the instance declaration at src/Frp/DbaStore/Internal.hs:(646,3)-(647,55) • In the expression: selName m In an equation for ‘fieldName’: fieldName = selName m In an equation for ‘_storeDbaField’: ``` But can I really evident `SingI` instance from my side? Which is unexpected from GHC.Generics... Otherwise with the `symbolVal` approach as in the `_loadDbaField ` above, there’s the complain against the ultimate use site: ```log • No instance for (GHC.TypeLits.KnownSymbol sel0) arising from a use of ‘storeDba’ • In a stmt of a 'do' block: storeDba rootDir series'data In the expression: do forM_ series'data print storeDba rootDir series'data sd <- loadDba @(Envelope2D Double) rootDir forM_ sd print ``` But I failed to prove `KnownSymbol sel` with all methods I can think of. Help please! With best regards, Compl

1 0

Contact to the maintainer of "finitary" package
by 宮里洸司 06 May '24

06 May '24

Hello everyone, I'd like to contact to the maintainer of "finitary" package [1] hosted at notabug.org [2]. The package is failing to build at Hackage, but a simple metadata fix [3] would solve the problem. As I couldn't find a way to contact the maintainer, (Sam Derbyshire, "sheaf" (sorry for missing titles)) I'm shouting public here. [1] https://hackage.haskell.org/package/finitary-2.1.1.1 [2] https://notabug.org/sheaf/finitary [3] https://notabug.org/viercc/finitary/commit/d6de614d0556b984e5bae97af01d94ae… -- /* Koji Miyazato <viercc(a)gmail.com> */

1 0

Call for Papers: Scheme '24
by Kristopher K Micinski 30 Apr '24

30 Apr '24

-------------------------------------------------------------------------------- CALL FOR PAPERS The 2024 Workshop on Scheme and Functional Programming Co-located with ICFP 2024 (Milan, Italy) https://icfp24.sigplan.org/home/scheme-2024 -------------------------------------------------------------------------------- The 2024 Scheme and Functional Programming Workshop is calling for submissions. We invite high-quality papers and talk proposals about novel research results, lessons learned from practical experience in an industrial or educational setting, and even new insights on old ideas. We welcome and encourage submissions that apply to any dynamic functional language, especially those that can be considered a Scheme: from strict subsets of RnRS to other "Scheme" implementations, to Racket, to Lisp dialects including Clojure, Emacs Lisp, Common Lisp, to functional languages with continuations and/or macros (or extended to have them) such as Dylan, ECMAScript, Hop, Lua, Scala, Rust, etc. The elegance of the paper and the relevance of its topic to the interests of Schemers will matter more than the surface syntax of the examples used. * Topics Topics of interest include (but are not limited to): - Interaction: program-development environments, debugging, testing, refactoring - Implementation: interpreters, compilers, tools, garbage collectors, benchmarks - Extension: macros, hygiene, domain-specific languages, reflection, and how such extension affects interaction - Expression: control, modularity, ad hoc and parametric polymorphism, types, aspects, ownership models, concurrency, distribution, parallelism, non-determinism, probabilism, and other programming paradigms - Integration: build tools, deployment, interoperation with other languages and systems - Formal semantics: theory, analyses and transformations, partial evaluation - Human factors: past, present and future history, evolution and sociology of the language Scheme, its standard and its dialects - Education: approaches, experiences, curricula - Applications: industrial uses of Scheme - Scheme pearls: elegant, instructive uses of Scheme * Dates - Submission deadline is Thursday July 18, 2024. - Authors will be notified by Monday August 12, 2024. - Camera-ready versions are due Thursday August 29, 2024. - Workshop will be held in Milan, Italy on Saturday September 7, 2024. All deadlines are 23:59 UTC-12, anywhere on Earth. * Submission Information We encourage all kinds of submissions, including full papers, experience reports, and lightning talks. Papers and experience reports are expected to be 10–24 pages in length using the single-column SIGPLAN acmart style. (For reference, this is about 5–12 pages of the older SIGPLAN 2-column 9pt style.) Abstracts submitted for lightning talks should be limited to 192 words. Authors of each accepted submission are invited to attend and be available for the presentation of that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. The size limits above exclude references and any optional appendices. There are no size limits on appendices, but the papers should stand without the need to read them, and reviewers are not required to read them. Authors are encouraged to publish any code associated to their papers under an open source license, so that reviewers may try the code and verify the claims. Proceedings will be uploaded to arXiv.org (https://arXiv.org/) Publication of a paper at this workshop is not intended to replace conference or journal publication, and does not preclude re-publication of a more complete or finished version of the paper at some later conference or in a journal. Please submit papers through the workshop's HotCRP site (https://scheme2024.hotcrp.com/) * Lightweight double-blind reviewing Scheme 2024 will use lightweight double-blind reviewing. Submitted papers must omit author names and institutions and reference the authors’ own related work in the third person (e.g., not “we build on our previous work…” but rather “we build on the work of…”). The purpose is to help the reviewers come to an initial judgment 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 anonymized). * Formatting Information Full papers and experience reports should use the SIGPLAN acmsmall option to acmart. We recommend using the anonymous and review options to acmart when submitting a paper; these options hide the author names and enable line numbers for easy reference in review. LaTeX and Microsoft Word templates for this format are available through SIGPLAN (https://www.sigplan.org/Resources/Author/) Lightning talks can be submitted as either a text file or a PDF file. * Workshop Organization Organizing Committee: Kristopher Micinski (Syracuse University, United States) Youyou Cong (Tokyo Institute of Technology, Japan) Program Committee: Julia Belyakova (Purdue University, United States) Kimball Germane (Brigham Young University, United States) Yuki Nishida (Kyoto University, Japan) Gabriel Scherer (Inria Saclay, France) Philipp Schuster (University of Tübingen, Germany) Taro Sekiyama (National Institute of Informatice, Japan) Michael Sperber (Active Group GmbH, Germany)

1 0

Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions
by Olaf Klinke 29 Apr '24

29 Apr '24

> I think this is a similar 'failure to deduce' partiality as last > week's > thread; but the other way round (and with ViewPatterns) -- at GHC > 8.10.7: > > GHCi> :set -XViewPatterns > GHCi> :set -Wincomplete-patterns -- also warns overlapping > GHCi> (\x -> case x of {((\(Just j) -> j) -> j2) -> j2; Nothing -> > 'N'}) > Nothing > > ===> <interactive>: warning: [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: Nothing -> ... > *** Exception: <interactive>:16:21-34: Non-exhaustive patterns in > lambda > > (Same Warning then same Exception if I compile the code.) I think what we see here is an instance of the fact that all checks must break down in presence of view patterns. If I parsed your code correctly, the case analysis has two branches. The first uses a view pattern with a function, call it v for the moment. The result of v is bound to another pattern, in your case the wildcard j2 and that is returned as-is, so in pseudo-Haskell: case (v x) of j2 -> j2 case x of Nothing -> 'N' Now your view function v happens to be partial, it pattern-matches its argument and only provides a branch for the Just case. v = \(Just j) -> j = Data.Maybe.fromJust That is why you see the exception when you call this function with 'Nothing'. And indeed the second match is redundant insofar as the view pattern will evaluate v for any x. Since v could be anything, like unsafePerformIO (lauchMissiles >> return j) GHC does not examine this and thus can not decide that v does not match the cases that the Nothing branch does. If you swap the two branches and make the view pattern the last one, then both the exception and the warning go away. Olaf

2 2