- Haskell-Cafe - Haskell.org

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

Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions
by Anthony Clayden 27 Apr '24

27 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.) So GHC isn't smart enough, despite the explicit `(\(Just j) -> ...)`, to see that ViewPattern usage is incomplete? I thought ViewPatterns got desugarred into clunky chains of nested `case`s, so that the pattern coverage checker could see what's going on? I was testing this because if anything I expected it to report coverage was incomplete. To get both a claim "Pattern match is redundant" and "Non-exhaustive" seems particularly unhelpful. AntC

1 0

Is it possible to nest this kind of "continuation" (a -> b -> r)
by PICCA Frederic-Emmanuel 22 Apr '24

22 Apr '24

Hello, I have this nest ∷ [(a → r) → r] → ([a] → r) → r nest xs = runCont (Prelude.mapM cont xs) but now I need this nest2 ∷ [(a → b → r) → r] → ([a] → [b] → r) → r nest2 xs = ... and this nest3 :: ... Do you think that there is a generic way to write all these nestX methodes. thanks for your help Frédéric

4 3

ghc should be able to deduce correct use of partial functions and not give a warning in such cases
by George Colpitts 22 Apr '24

22 Apr '24

ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. in 9.8.2 if null ys then [] else [(xs,tail ys)]) gets a warning warning: [GHC-63394] [-Wx-partial] but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a warning. Does anybody know if there is a plan or enhancement request to eliminate such warnings? Cheers George

8 17

Student Research Competition (SRC) at ICFP 2024
by Favonia 21 Apr '24

21 Apr '24

ICFP 2024 Student Research Competition Call for Submissions ICFP 2024 invites students to participate in the Student Research Competition in order to present their research and get feedback from prominent members of the programming language research community. The SRC consists of three rounds: * Submission of an extended abstract * Poster session at ICFP 2024 * Finalists' presentations at ICFP 2024 During the first round students submit an extended abstract detailing their research to be reviewed by the program committee. Those students whose abstracts get accepted advance to the poster session round which will take place during ICFP 2024. Winners of the poster session advance to the next round, where they will give a 5-minute presentation about their work on the ICFP main stage in front of a live audience. ### IMPORTANT DATES AND TIMES * Submission Deadline: 23 May 2024 (Thursday) * Author Notification: 14 June 2024 (Friday) 12:00 PM CST * ICFP 2024 Conference in Milan, Italy: 2 September 2024 (Monday) - 7 September 2024 (Saturday) ### SUBMISSION OF EXTENDED ABSTRACTS * Submission Website: https://icfp24src.hotcrp.com Each submission (referred to as "abstract" below) should include the student author's name and e-mail address; institutional affiliation; research advisor's name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and/or part of a larger group project, the abstract should make clear what the student's role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp24.sigplan.org/track/icfp-2024-student-research-competition

1 0

Re: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases
by Anthony Clayden 20 Apr '24

20 Apr '24

> > So your code is essentially pattern matching on a list to decide ..., then pattern matching on the Bool to split between two cases, then pattern matching on the list again. If you had kept the result of the first pattern match there would be no need for the latter two. > > Essentially the problem is "boolean blindness" ... > > This style of coding is generally more readable, maintainable, and less error-prone. ... > +1 to Ben's wise advice. +1 to "more readable". Haskell is a 'functional language' does not mean everything everywhere has to be expressed only through functions. Perhaps we should promote 'Algebraic data types' (yay mathy!) and 'pattern matching' right up front on the 'Features' section of Haskell.org? AntC

1 0

cabal install: Failed to download aeson-2.2.1.0
by Johannes Waldmann 19 Apr '24

19 Apr '24

Dear Cafe. "cabal install" sometimes cannot download aeson. This happens repeatedly (in recent days) but it's not fully reproducible. Example where it happens in CI (image haskell-slim) https://git.imn.htwk-leipzig.de/waldmann/pure-matchbox/-/jobs/41533 What might be the reason? - J.

1 0