From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 2 12:02:54 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 2 Jan 2023 12:02:54 +0000 Subject: [Haskell-cafe] Actual levity polymorphism Message-ID: I'm investigating unboxed types in GHC 9.2. Levity polymorphism seems to be severely limited in a way that makes it hard to envisage a Haskell ecosystem which comfortably combines lifted and unlifted types. Am I missing something? Understandably, the following attempt at defining a RuntimeRep-polymorphic identity does not work: myId1 :: forall (r :: RuntimeRep) (t :: TYPE r). t -> t myId1 x = x The GHC Users Guide explains why[1]. It's impossible to generate code for myId1 because there is no way of determining the machine representation of the argument x. But worse, it's not even possible to define a *Levity*-polymorphic identity: myId2 :: forall (lev :: Levity) (t :: TYPE (BoxedRep lev)). t -> t myId2 x = x In this case the argument can only have kind TYPE LiftedRep or TYPE UnliftedRep. The machine representation is the same in each case. The problem this time is that the code generator doesn't know whether it should emit code to evaluate the argument (UnliftedRep case) or not (LiftedRep case). But this seems like a solvable problem. Surely a KnownLevity type class (possibly magical) could solve the problem. This seems like it should work myId3 :: forall (lev :: Levity) (t :: TYPE (BoxedRep lev)). KnownLevity lev => t -> t myId3 x = x and in fact I wouldn't be surprised if this could be made to work: myId4 :: forall (r :: RuntimeRep) (t :: TYPE r). KnownRuntimeRep r => t -> t myId4 x = x So what is the situation here? 1. myId3 already works (then where is KnownLevity made available and why isn't it mentioned in the Users Guide?) 2. myId3 can never work (then why not?) 3. myId3 might be able to work but it's an open research problem (then who is working on it, if anyone?) 4. myId3 would work and it would be useful but no one's proposed or implemented it (then who would be the best person to collaborate with on that?) 5. myId3 would work but it would not actually be useful (then what have I misunderstood?) I suspect the answer is 1 (or maybe 4) based on the following passage in the Levity Polymorphism[2] paper by RE & SPJ[2]: > users can use a runtime type check (though GHC’s Typeable feature) > to determine the memory representation of an as-yet- unbound > argument to a function (and the same questions for myId4). Thanks, Tom [1] https://downloads.haskell.org/~ghc/9.4.4/docs/users_guide/exts/representation_polymorphism.html#no-representation-polymorphic-variables-or-arguments [2] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/levity-pldi17.pdf From jaro.reinders at gmail.com Mon Jan 2 13:01:56 2023 From: jaro.reinders at gmail.com (J. Reinders) Date: Mon, 2 Jan 2023 14:01:56 +0100 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: References: Message-ID: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> I think theoretically a type class is indeed all you need even for representation polymorphism. I believe that is what the Sixten language [1] does. Currently GHC rejects any levity polymorphic function arguments and local binders. Issue #15532 [2] tracks the possibility of relaxing these restrictions. The type class approach is mentioned in that thread. I seem to recall another thread where there were more suggestions like a special form of type classes that is always guaranteed to monomorphise away and another suggestion that functions that are always guaranteed to inline can also be allowed to be representation polymorphic. But I can’t find this thread again. Also, I think the identity function is so simple that you don’t even need the KnownLevity class for levity polymorphism. The implementation can just copy the pointer from the input to the output. Cheers, Jaro [1] https://github.com/ollef/sixten [2] https://gitlab.haskell.org/ghc/ghc/-/issues/15532 > On 2 Jan 2023, at 13:02, Tom Ellis wrote: > > I'm investigating unboxed types in GHC 9.2. Levity polymorphism seems > to be severely limited in a way that makes it hard to envisage a > Haskell ecosystem which comfortably combines lifted and unlifted > types. Am I missing something? > > Understandably, the following attempt at defining a > RuntimeRep-polymorphic identity does not work: > > myId1 :: forall (r :: RuntimeRep) (t :: TYPE r). t -> t > myId1 x = x > > The GHC Users Guide explains why[1]. It's impossible to generate code > for myId1 because there is no way of determining the machine > representation of the argument x. > > But worse, it's not even possible to define a *Levity*-polymorphic > identity: > > myId2 :: forall (lev :: Levity) (t :: TYPE (BoxedRep lev)). t -> t > myId2 x = x > > In this case the argument can only have kind TYPE LiftedRep or TYPE > UnliftedRep. The machine representation is the same in each case. > The problem this time is that the code generator doesn't know whether > it should emit code to evaluate the argument (UnliftedRep case) or not > (LiftedRep case). But this seems like a solvable problem. Surely a > KnownLevity type class (possibly magical) could solve the problem. > This seems like it should work > > myId3 :: forall (lev :: Levity) (t :: TYPE (BoxedRep lev)). > KnownLevity lev => > t -> t > myId3 x = x > > and in fact I wouldn't be surprised if this could be made to work: > > myId4 :: forall (r :: RuntimeRep) (t :: TYPE r). > KnownRuntimeRep r => > t -> t > myId4 x = x > > So what is the situation here? > > 1. myId3 already works (then where is KnownLevity made available and > why isn't it mentioned in the Users Guide?) > > 2. myId3 can never work (then why not?) > > 3. myId3 might be able to work but it's an open research problem (then > who is working on it, if anyone?) > > 4. myId3 would work and it would be useful but no one's proposed or > implemented it (then who would be the best person to collaborate > with on that?) > > 5. myId3 would work but it would not actually be useful (then what > have I misunderstood?) > > I suspect the answer is 1 (or maybe 4) based on the following passage > in the Levity Polymorphism[2] paper by RE & SPJ[2]: > >> users can use a runtime type check (though GHC’s Typeable feature) >> to determine the memory representation of an as-yet- unbound >> argument to a function > > (and the same questions for myId4). > > Thanks, > > Tom > > [1] https://downloads.haskell.org/~ghc/9.4.4/docs/users_guide/exts/representation_polymorphism.html#no-representation-polymorphic-variables-or-arguments > > [2] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/levity-pldi17.pdf > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 2 13:49:15 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 2 Jan 2023 13:49:15 +0000 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> References: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> Message-ID: On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote: > I think theoretically a type class is indeed all you need even for > representation polymorphism. I believe that is what the Sixten > language [1] does. > > Currently GHC rejects any levity polymorphic function arguments and > local binders. Issue #15532 [2] tracks the possibility of relaxing > these restrictions. The type class approach is mentioned in that > thread. > > I seem to recall another thread where there were more suggestions > like a special form of type classes that is always guaranteed to > monomorphise away and another suggestion that functions that are > always guaranteed to inline can also be allowed to be representation > polymorphic. But I can’t find this thread again. Very helpful info, thanks Jaro! From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 2 14:07:17 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 2 Jan 2023 14:07:17 +0000 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> References: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> Message-ID: On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote: > I seem to recall another thread where there were more suggestions > like a special form of type classes that is always guaranteed to > monomorphise away Perhaps this? https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076 From jaro.reinders at gmail.com Mon Jan 2 14:18:35 2023 From: jaro.reinders at gmail.com (J. Reinders) Date: Mon, 2 Jan 2023 15:18:35 +0100 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: References: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> Message-ID: No, I found it. It is this GHC issue: https://gitlab.haskell.org/ghc/ghc/-/issues/14917 > On 2 Jan 2023, at 15:07, Tom Ellis wrote: > > On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote: >> I seem to recall another thread where there were more suggestions >> like a special form of type classes that is always guaranteed to >> monomorphise away > > Perhaps this? > > https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From P.Achten at cs.ru.nl Mon Jan 2 15:35:33 2023 From: P.Achten at cs.ru.nl (Peter Achten) Date: Mon, 2 Jan 2023 16:35:33 +0100 Subject: [Haskell-cafe] [TFP 2023 Call For Participation] 24th International Symposium on Trends in Functional Programming Message-ID: <5d453c7e-0517-87c4-8005-945c2507ed43@cs.ru.nl> # TFP 2023 -- Call For Participation (trendsfp.github.io) ## Dates Registration:   Friday 6th January, 2023 TFPIE Workshop: Thursday 12th January, 2023 TFP Symposium:  Friday 13th - Sunday 15th January, 2023 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. This year, TFP will take place in-person at UMass Boston, Massachusetts in the United States.  It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles:   Leading-edge, previously unpublished research work * Position Articles:   On what new trends should or should not be * Project Articles:   Descriptions of recently started new projects * Evaluation Articles:   What lessons can be drawn from a finished project * Overview Articles:   Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas:   security, mobility, telecommunications applications, embedded   systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2023 program chair, Stephen Chang. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, a prize for the best student paper is awarded each year. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Papers must be submitted at:   Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. ## Program Committee Peter Achten,              Radboud University Nijmegen, Netherlands Nada Amin,                 Harvard University, USA Ambrose Bonnaire-Sergeant, Untypable LLC, USA Laura M. Castro,           University of A Coruña, Spain Stephen Chang (Chair),     University of Massachusetts Boston, US John Clements,             Cal Poly, USA Youyou Cong,               Tokyo Institute of Technology, Japan Paul Downen,               University of Massachusetts Lowell, USA Kathy Gray,                Meta Platforms, Inc., UK Ben Greenman,              University of Utah, USA Jason Hemann,              Seton Hall University, USA Patricia Johann,           Appalachian State University, USA Alexis King,               Tweag, USA Julia Lawall,              Inria-Paris, France Barak Pearlmutter,         Maynooth University, Ireland Norman Ramsey,             Tufts University, USA Ilya Sergey,               National University of Singapore, Singapore Melinda Tóth,              Eötvös Loránd University, Hungary Ningning Xie,              University of Toronto, Canada From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 2 19:01:24 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 2 Jan 2023 19:01:24 +0000 Subject: [Haskell-cafe] Surprising behavior with wildcard pattern and unlifted type Message-ID: Is there supposed to be this surprising difference between ex1 and ex2? {-# LANGUAGE UnliftedDatatypes #-} {-# OPTIONS_GHC -Wall #-} module Main where import GHC.Exts (UnliftedType) type T :: UnliftedType data T = T ex1 :: () ex1 = let _ = undefined :: T in () ex2 :: () ex2 = let _a = undefined :: T in () ghci> ex1 () ghci> ex2 *** Exception: Prelude.undefined CallStack (from HasCallStack): undefined, called at test17.hs:53:16 in fake-package-0-inplace:Main From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 2 23:00:01 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 2 Jan 2023 23:00:01 +0000 Subject: [Haskell-cafe] Surprising interaction between @-patterns and nested patterns Message-ID: Consider the following: let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () () but then combining the patterns into an @-pattern, which really feels like it shouldn't change semantics: let x1@((_, _), _) = (undefined, ()) in x1 `seq` () -> undefined Does this strike anyone else as odd? The reason for this behaviour is that let x at p = rhs in body is translated to case rhs of ~(x at p) -> body according to section 3.12 of The Report[1] which is then translated to (\x -> body) (case rhs of x at p -> x) if p binds no variables, according to section 3.17.3 of The Report[2], and then to (\x -> body) (case rhs of p -> (\x -> x) rhs) which is equivalent to (\x -> body) (case rhs of p -> rhs) Putting it all together let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () desugars as (\x0 -> x0 `seq` ()) (let v = (undefined, ()) in case v of ((_, _), _) -> v) which evaluates as let v = (undefined, ()) in case v of ((_, _), _) -> () This seems very odd to me. Why should combining two non-diverging patterns into an @-pattern cause divergence? Specifically, the translation from let x at p = rhs in body to case rhs of ~(x at p) -> body seems highly dubious. It comes from the more general rule translating let p = rhs in body to case rhs of ~p in body but it seems to interact badly with @-patterns. It seems like the rule for @-patterns should be something like let x at p = rhs in body translates to case rhs of ~(x@(~p)) in body Then the original expression containing x1 would not diverge. Does anyone else have a view on this matter? Tom [1] https://www.haskell.org/onlinereport/exps.html#sect3.12 [2] https://www.haskell.org/onlinereport/exps.html#sect3.17.3 From trebla at vex.net Mon Jan 2 23:49:07 2023 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon, 2 Jan 2023 18:49:07 -0500 Subject: [Haskell-cafe] Surprising interaction between @-patterns and nested patterns In-Reply-To: References: Message-ID: <16ddb673-0bff-cdd2-d427-336e1cce36e9@vex.net> I don't have an opinion; or maybe I do, my hunch is that any alternative would be differently but equally tricky. But the x0 example is equivalent to simply: let x0 = (undefined, ()) in x0 `seq` () which may be surprisingly unsurprising because I see that it has almost nothing to do with the x1 example. In order to make "pattern = x0" actually relevant, you may want: let { x0 = (undefined, ()) ; ((_, _), y) = x0 } in y `seq` () -> undefined The semantic explanation involves the same considerations as those of the x1 example. And you can hold the same opinion, for or against. On 2023-01-02 18:00, Tom Ellis wrote: > Consider the following: > > let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () > () > > but then combining the patterns into an @-pattern, which really feels > like it shouldn't change semantics: > > let x1@((_, _), _) = (undefined, ()) in x1 `seq` () > -> undefined > > Does this strike anyone else as odd? The reason for this behaviour is > that > > let x at p = rhs in body > > is translated to > > case rhs of ~(x at p) -> body > > according to section 3.12 of The Report[1] which is then translated to > > (\x -> body) (case rhs of x at p -> x) > > if p binds no variables, according to section 3.17.3 of The Report[2], > and then to > > (\x -> body) (case rhs of p -> (\x -> x) rhs) > > which is equivalent to > > (\x -> body) (case rhs of p -> rhs) > > Putting it all together > > let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () > > desugars as > > (\x0 -> x0 `seq` ()) > (let v = (undefined, ()) in case v of ((_, _), _) -> v) > > which evaluates as > > let v = (undefined, ()) > in case v of ((_, _), _) -> () > > > This seems very odd to me. Why should combining two non-diverging > patterns into an @-pattern cause divergence? Specifically, the > translation from > > let x at p = rhs in body > > to > > case rhs of ~(x at p) -> body > > seems highly dubious. It comes from the more general rule translating > > let p = rhs in body > > to > > case rhs of ~p in body > > but it seems to interact badly with @-patterns. It seems like the > rule for @-patterns should be something like > > let x at p = rhs in body > > translates to > > case rhs of ~(x@(~p)) in body > > Then the original expression containing x1 would not diverge. > > Does anyone else have a view on this matter? > > Tom > > > [1] https://www.haskell.org/onlinereport/exps.html#sect3.12 > > [2] https://www.haskell.org/onlinereport/exps.html#sect3.17.3 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From david.feuer at gmail.com Tue Jan 3 02:09:28 2023 From: david.feuer at gmail.com (David Feuer) Date: Mon, 2 Jan 2023 21:09:28 -0500 Subject: [Haskell-cafe] Surprising interaction between @-patterns and nested patterns In-Reply-To: References: Message-ID: My opinion, for several years, has been that the Haskell designers erred in making outermost patterns lazy by default in let and where, and at the top level. I believe they should have gone with something much simpler: 1. Patterns are strict by default. 2. Variables are lazy by default. 3. Patterns at the top level must be marked lazy. 4. (With bang patterns) Variables at the top level may not be marked strict. That would harmonize the way patterns are handled in let and where with the way they're handled in function arguments and case expressions, as well as removing the outermost-pattern special case which makes the *strictness* of inner patterns surprising. Unfortunately, I don't think there's much chance of any of these changing in Haskell. On Mon, Jan 2, 2023, 6:00 PM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > Consider the following: > > let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () > () > > but then combining the patterns into an @-pattern, which really feels > like it shouldn't change semantics: > > let x1@((_, _), _) = (undefined, ()) in x1 `seq` () > -> undefined > > Does this strike anyone else as odd? The reason for this behaviour is > that > > let x at p = rhs in body > > is translated to > > case rhs of ~(x at p) -> body > > according to section 3.12 of The Report[1] which is then translated to > > (\x -> body) (case rhs of x at p -> x) > > if p binds no variables, according to section 3.17.3 of The Report[2], > and then to > > (\x -> body) (case rhs of p -> (\x -> x) rhs) > > which is equivalent to > > (\x -> body) (case rhs of p -> rhs) > > Putting it all together > > let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () > > desugars as > > (\x0 -> x0 `seq` ()) > (let v = (undefined, ()) in case v of ((_, _), _) -> v) > > which evaluates as > > let v = (undefined, ()) > in case v of ((_, _), _) -> () > > > This seems very odd to me. Why should combining two non-diverging > patterns into an @-pattern cause divergence? Specifically, the > translation from > > let x at p = rhs in body > > to > > case rhs of ~(x at p) -> body > > seems highly dubious. It comes from the more general rule translating > > let p = rhs in body > > to > > case rhs of ~p in body > > but it seems to interact badly with @-patterns. It seems like the > rule for @-patterns should be something like > > let x at p = rhs in body > > translates to > > case rhs of ~(x@(~p)) in body > > Then the original expression containing x1 would not diverge. > > Does anyone else have a view on this matter? > > Tom > > > [1] https://www.haskell.org/onlinereport/exps.html#sect3.12 > > [2] https://www.haskell.org/onlinereport/exps.html#sect3.17.3 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Jan 3 07:22:08 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 3 Jan 2023 08:22:08 +0100 (CET) Subject: [Haskell-cafe] Surprising interaction between @-patterns and nested patterns In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023, David Feuer wrote: > My opinion, for several years, has been that the Haskell designers erred in making outermost patterns > lazy by default in let and where, and at the top level. I believe they should have gone with > something much simpler: > 1. Patterns are strict by default. > 2. Variables are lazy by default. > 3. Patterns at the top level must be marked lazy. > 4. (With bang patterns) Variables at the top level may not be marked strict. > > That would harmonize the way patterns are handled in let and where with the way they're handled in > function arguments and case expressions, as well as removing the outermost-pattern special case which > makes the *strictness* of inner patterns surprising. me too > Unfortunately, I don't think there's much chance of any of these > changing in Haskell. Could start as a nice GHC extension like Strict Haskell. From david.feuer at gmail.com Tue Jan 3 08:09:58 2023 From: david.feuer at gmail.com (David Feuer) Date: Tue, 3 Jan 2023 03:09:58 -0500 Subject: [Haskell-cafe] Surprising behavior with wildcard pattern and unlifted type In-Reply-To: References: Message-ID: Ouch ... that looks ... not great. I don't know if that was intentional, but it's weird enough to deserve a bug report. On Mon, Jan 2, 2023, 2:01 PM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > Is there supposed to be this surprising difference between ex1 and ex2? > > {-# LANGUAGE UnliftedDatatypes #-} > > {-# OPTIONS_GHC -Wall #-} > > module Main where > > import GHC.Exts (UnliftedType) > > type T :: UnliftedType > data T = T > > ex1 :: () > ex1 = let _ = undefined :: T in () > > ex2 :: () > ex2 = let _a = undefined :: T in () > > > ghci> ex1 > () > ghci> ex2 > *** Exception: Prelude.undefined > CallStack (from HasCallStack): > undefined, called at test17.hs:53:16 in fake-package-0-inplace:Main > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lelechenko at gmail.com Thu Jan 5 01:06:34 2023 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Thu, 5 Jan 2023 01:06:34 +0000 Subject: [Haskell-cafe] CLC Election January 2023 Message-ID: The terms of three CLC members are ending in January, so we are seeking new nominations! # Who should apply? Anyone who meets the following criteria should apply: * Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (3 to 5 per month), and sustain this for their 3 years term in a healthy manner. * Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the CLC proposal process on a semi-frequent basis (3 to 5 per month). * Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. * Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room - quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. # How can I apply? To apply for one of these positions, send an email to clc.nominations.2023 at gmail.com that consists of the following data: * The header “CLC Election January 2023 - {your name}”. * Why you think you’re a good fit given the above criteria. * If applicable, please point us to some code you’ve written. Please apply before Feb 1. Best regards, Andrew From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Thu Jan 5 11:17:43 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 5 Jan 2023 11:17:43 +0000 Subject: [Haskell-cafe] Surprising interaction between @-patterns and nested patterns In-Reply-To: References: Message-ID: On Tue, Jan 03, 2023 at 08:22:08AM +0100, Henning Thielemann wrote: > On Mon, 2 Jan 2023, David Feuer wrote: > > > My opinion, for several years, has been that the Haskell designers erred in making outermost patterns > > lazy by default in let and where, and at the top level. I believe they should have gone with > > something much simpler: > > 1. Patterns are strict by default. > > 2. Variables are lazy by default. > > 3. Patterns at the top level must be marked lazy. > > 4. (With bang patterns) Variables at the top level may not be marked strict. > > > > That would harmonize the way patterns are handled in let and where with the way they're handled in > > function arguments and case expressions, as well as removing the outermost-pattern special case which > > makes the *strictness* of inner patterns surprising. > > me too I am inclined to agree. But are there any nasty corner cases involving recursive bindings? > > Unfortunately, I don't think there's much chance of any of these > > changing in Haskell. > > Could start as a nice GHC extension like Strict Haskell. I agree, but an easier sell if there aren't nasty corner cases. Tom From david.feuer at gmail.com Thu Jan 5 13:51:50 2023 From: david.feuer at gmail.com (David Feuer) Date: Thu, 5 Jan 2023 08:51:50 -0500 Subject: [Haskell-cafe] Surprising interaction between @-patterns and nested patterns In-Reply-To: References: Message-ID: There are certainly cases where lazy pattern matches are important. But IMO they're always *a bit weird*, and deserve that ~ syntactic marker letting people know that *something a bit weird is happening*. On Thu, Jan 5, 2023, 6:18 AM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > On Tue, Jan 03, 2023 at 08:22:08AM +0100, Henning Thielemann wrote: > > On Mon, 2 Jan 2023, David Feuer wrote: > > > > > My opinion, for several years, has been that the Haskell designers > erred in making outermost patterns > > > lazy by default in let and where, and at the top level. I believe they > should have gone with > > > something much simpler: > > > 1. Patterns are strict by default. > > > 2. Variables are lazy by default. > > > 3. Patterns at the top level must be marked lazy. > > > 4. (With bang patterns) Variables at the top level may not be marked > strict. > > > > > > That would harmonize the way patterns are handled in let and where > with the way they're handled in > > > function arguments and case expressions, as well as removing the > outermost-pattern special case which > > > makes the *strictness* of inner patterns surprising. > > > > me too > > I am inclined to agree. But are there any nasty corner cases > involving recursive bindings? > > > > Unfortunately, I don't think there's much chance of any of these > > > changing in Haskell. > > > > Could start as a nice GHC extension like Strict Haskell. > > I agree, but an easier sell if there aren't nasty corner cases. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Jan 6 16:51:30 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 6 Jan 2023 11:51:30 -0500 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: References: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> Message-ID: i've written (more opaquely than i'd like), about this topic a few times , including on that ticket https://gitlab.haskell.org/ghc/ghc/-/issues/14917#note_230433 ! ultimately, you want some notion of function types /lambdas that have the equivalent to the C++ Const-Eval / C++ Template arg "compile time instantiation is the only allowed flavor". for the particulars in the context of runtime rep levity, my intuitions break down, but i've had examples of the sort of "must be resolved at compile time" where for the behavior i'd need isn't expressible using type classes because those can be instantiated abstractly rather than concretely and still be valid programs. granted i'm not terribly current on the state of play in >= ghc 9.4 for this stuff, but i would not be surprised if the architectural hooks needed for a "strict staging lambda" arent there yet. (you can manufacture some of this stuff with typed template haskell, BUT theres no mechanism for expressing the primops that certain uses cases, like SIMD shuffle, would need) On Mon, Jan 2, 2023 at 9:18 AM J. Reinders wrote: > No, I found it. It is this GHC issue: > > https://gitlab.haskell.org/ghc/ghc/-/issues/14917 > > > On 2 Jan 2023, at 15:07, Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > > > On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote: > >> I seem to recall another thread where there were more suggestions > >> like a special form of type classes that is always guaranteed to > >> monomorphise away > > > > Perhaps this? > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076 > > _______________________________________________ > > 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. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Sat Jan 7 09:00:03 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 7 Jan 2023 04:00:03 -0500 Subject: [Haskell-cafe] HLS in VS Code is identifying problems that don't when I run stack on the command line Message-ID: I'm trying to get HLS set up with a stack project on VS Code. I'm getting messages like this: Could not load module ‘Control.Monad.Except’ It is a member of the hidden package ‘mtl-2.2.2’. You can run ‘:set -package mtl’ to expose it. (Note: this unloads all the modules in the current scope.) But these are in the "Problems" tab of VS Code (and show as red underlines). When I run stack clean, stack build I don't see any error like this at all. And yes, I made sure mtl was added everywhere in cac.cabal. (I'm using cac.cabal not stack.yaml... is that my problem?) I tried stack clean; stack build; restart HLS several times. -------------- next part -------------- An HTML attachment was scrubbed... URL: From power.walross at gmail.com Sat Jan 7 10:13:36 2023 From: power.walross at gmail.com (Fendor) Date: Sat, 7 Jan 2023 11:13:36 +0100 Subject: [Haskell-cafe] HLS in VS Code is identifying problems that don't when I run stack on the command line In-Reply-To: References: Message-ID: <995364a6-4bfc-0cf5-b3e0-071c01c25d1c@gmail.com> How are you launching VSCode? Make sure you open the root of the project in VSCode. Opening VSCode from the cli via `code .` when you are in the correct directory is the most reliable. Further, on the cli, try running HLS like this: `haskell-language-server-wrapper --debug ` from the root of your project. Does this report the same error? If yes, more info about the project is needed like the .cabal file and the logs. Otherwise, it is a problem with the editor (e.g., PATH variable shenanigans). Best regards, Fendor On 07/01/2023 10:00, Dennis Raddle wrote: > I'm trying to get HLS set up with a stack project on VS Code. I'm > getting messages like this: > > Could not load module ‘Control.Monad.Except’ > It is a member of the hidden package ‘mtl-2.2.2’. > You can run ‘:set -package mtl’ to expose it. > (Note: this unloads all the modules in the current scope.) > > But these are in the "Problems" tab of VS Code (and show as red > underlines). > > When I run stack clean, stack build I don't see any error like this at > all. > > And yes, I made sure mtl was added everywhere in cac.cabal. (I'm using > cac.cabal not stack.yaml... is that my problem?) > > I tried stack clean; stack build; restart HLS several times. > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Sat Jan 7 10:40:17 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 7 Jan 2023 05:40:17 -0500 Subject: [Haskell-cafe] HLS in VS Code is identifying problems that don't when I run stack on the command line In-Reply-To: <995364a6-4bfc-0cf5-b3e0-071c01c25d1c@gmail.com> References: <995364a6-4bfc-0cf5-b3e0-071c01c25d1c@gmail.com> Message-ID: I'm opening the project by running VS Code first, then opening the root folder of the project. I don't have a 'code' command installed or no path to it set; this doesn't happen by default on MacOS but I could look it up. But I think I got a better clue by running haskell-language-server-wrapper: I got this line. Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 1.9.0.0 x86_64 ghc-9.4.4 And then: Tool versions found on the $PATH cabal: 3.6.2.0 stack: 2.3.3 ghc: 8.10.7 My stack.yaml is using the resolver lts-18.19 which does specify GHC 8.10.7 according to what I looked up. But that ghc-9.4.4 seems to be a problem. Thanks! But how to fix? On Sat, Jan 7, 2023 at 5:13 AM Fendor wrote: > How are you launching VSCode? Make sure you open the root of the project > in VSCode. > Opening VSCode from the cli via `code .` when you are in the correct > directory is the most reliable. > > Further, on the cli, try running HLS like this: > `haskell-language-server-wrapper --debug ` from > the root of your project. > Does this report the same error? If yes, more info about the project is > needed like the .cabal file and the logs. Otherwise, it is a problem with > the editor (e.g., PATH variable shenanigans). > > Best regards, > Fendor > On 07/01/2023 10:00, Dennis Raddle wrote: > > I'm trying to get HLS set up with a stack project on VS Code. I'm getting > messages like this: > > Could not load module ‘Control.Monad.Except’ > It is a member of the hidden package ‘mtl-2.2.2’. > You can run ‘:set -package mtl’ to expose it. > (Note: this unloads all the modules in the current scope.) > > But these are in the "Problems" tab of VS Code (and show as red > underlines). > > When I run stack clean, stack build I don't see any error like this at > all. > > And yes, I made sure mtl was added everywhere in cac.cabal. (I'm using > cac.cabal not stack.yaml... is that my problem?) > > I tried stack clean; stack build; restart HLS several times. > > > > _______________________________________________ > 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. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat Jan 7 11:06:52 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 7 Jan 2023 11:06:52 +0000 Subject: [Haskell-cafe] Surprising behavior with wildcard pattern and unlifted type In-Reply-To: References: Message-ID: On Tue, Jan 03, 2023 at 03:09:58AM -0500, David Feuer wrote: > Ouch ... that looks ... not great. I don't know if that was intentional, > but it's weird enough to deserve a bug report. Bug report filed: https://gitlab.haskell.org/ghc/ghc/-/issues/22719 > On Mon, Jan 2, 2023, 2:01 PM Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > > Is there supposed to be this surprising difference between ex1 and ex2? > > > > {-# LANGUAGE UnliftedDatatypes #-} > > > > {-# OPTIONS_GHC -Wall #-} > > > > module Main where > > > > import GHC.Exts (UnliftedType) > > > > type T :: UnliftedType > > data T = T > > > > ex1 :: () > > ex1 = let _ = undefined :: T in () > > > > ex2 :: () > > ex2 = let _a = undefined :: T in () > > > > > > ghci> ex1 > > () > > ghci> ex2 > > *** Exception: Prelude.undefined > > CallStack (from HasCallStack): > > undefined, called at test17.hs:53:16 in fake-package-0-inplace:Main From lists at richarde.dev Sat Jan 7 18:20:12 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Sat, 7 Jan 2023 18:20:12 +0000 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: References: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> Message-ID: <010f01858d7635a8-736f5dbd-cd4e-4ae2-9427-960f0a815443-000000@us-east-2.amazonses.com> For what it's worth, this initiative may get a significant boost soon. My main job at Jane Street these days is designing & implementing unboxed types for OCaml (which has never really had them, unlike their long history within GHC). There is much eagerness to use unboxed types. But we've realized that, to meet these expectations, we'll need the equivalent of levity polymorphism. So I'll be spending some time over the next few months (I think) putting together the design there. Once it starts to come together, I can share it and then work to adapt it to Haskell. Though as I'm writing this, I see a really easy way to do this in Haskell. (Sadly for me, it won't work in OCaml.) Representation polymorphism can be made to work today via type classes. That is, we have a `class Representation (r :: RuntimeRep)` whose dictionaries have instructions for how to store variables whose types have kind TYPE r, and also to apply functions to such variables. There's no good way to mock this up today because GHC requires a known RuntimeRep in order to bind a variable, but using instructions in a dictionary is possible instead. This would work just fine -- except that it would be very slow, because it means every store or function-apply requires a dictionary access. It would be disastrous. However, GHC *already* has machinery for specializing functions to work with known dictionaries. All you would have to do is to ensure that all Representation dictionaries get specialized away; this could be done with a straightforward check (even implementable in a core plugin). So programmers can be polymorphic over representations, and GHC has to work hard to specialize. What this is missing is a nice mechanism for helping the programmer avoid cases that GHC can't specialize -- but that could be added later. I really think this would just work, quite easily. Well, "easily" from a language-design standpoint. An efficient implementation in GHC would be fiddly, because you'd need to annotate every variable with information about its representation: either it's known (good), or it's not, and then the variable's representation is informed by a specific dictionary. I think this could probably all be tracked efficiently, but it wouldn't surprise me if there's a measurable slowdown in compilation times to track these representations. And infer them. Left unaddressed here: how to make datatypes representation-polymorphic, which requires a lower-level understanding of data-constructor representations than I have. Richard > On Jan 6, 2023, at 11:51 AM, Carter Schonwald wrote: > > i've written (more opaquely than i'd like), about this topic a few times , including on that ticket https://gitlab.haskell.org/ghc/ghc/-/issues/14917#note_230433 ! > > ultimately, you want some notion of function types /lambdas that have the equivalent to the C++ Const-Eval / C++ Template arg "compile time instantiation is the only allowed flavor". > > for the particulars in the context of runtime rep levity, my intuitions break down, but i've had examples of the sort of "must be resolved at compile time" where for the behavior i'd need isn't expressible using type classes because those can be instantiated abstractly rather than concretely and still be valid programs. > > granted i'm not terribly current on the state of play in >= ghc 9.4 for this stuff, but i would not be surprised if the architectural hooks needed for a "strict staging lambda" arent there yet. (you can manufacture some of this stuff with typed template haskell, BUT theres no mechanism for expressing the primops that certain uses cases, like SIMD shuffle, would need) > > On Mon, Jan 2, 2023 at 9:18 AM J. Reinders > wrote: > No, I found it. It is this GHC issue: > > https://gitlab.haskell.org/ghc/ghc/-/issues/14917 > > > On 2 Jan 2023, at 15:07, Tom Ellis > wrote: > > > > On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote: > >> I seem to recall another thread where there were more suggestions > >> like a special form of type classes that is always guaranteed to > >> monomorphise away > > > > Perhaps this? > > > > https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076 > > _______________________________________________ > > 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. > > _______________________________________________ > 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. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Sat Jan 7 20:53:06 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 7 Jan 2023 15:53:06 -0500 Subject: [Haskell-cafe] HLS in VS Code is identifying problems that don't when I run stack on the command line In-Reply-To: References: <995364a6-4bfc-0cf5-b3e0-071c01c25d1c@gmail.com> Message-ID: Sorry it was a bit late when I wrote that last night so it was unclear. stack is using GHC 8.10.7 while Haskell Language Server seems to be using GHC 9.4.4. At various points while using VS Code I've gotten popups like "HLS is unable to determine GHC version" but later those stopped happening. Is this a problem that they are using different versions? Would this explain why HLS thinks mtl is hidden even though it's exposed in my cabal file? Mike On Sat, Jan 7, 2023 at 5:40 AM Dennis Raddle wrote: > I'm opening the project by running VS Code first, then opening the root > folder of the project. I don't have a 'code' command installed or no path > to it set; this doesn't happen by default on MacOS but I could look it up. > > But I think I got a better clue by running haskell-language-server-wrapper: > > I got this line. > Run entered for > haskell-language-server-wrapper(haskell-language-server-wrapper) Version > 1.9.0.0 x86_64 ghc-9.4.4 > > And then: > > Tool versions found on the $PATH > cabal: 3.6.2.0 > stack: 2.3.3 > ghc: 8.10.7 > > My stack.yaml is using the resolver > lts-18.19 > which does specify GHC 8.10.7 according to what I looked up. > > But that ghc-9.4.4 seems to be a problem. > > Thanks! But how to fix? > > > > On Sat, Jan 7, 2023 at 5:13 AM Fendor wrote: > >> How are you launching VSCode? Make sure you open the root of the project >> in VSCode. >> Opening VSCode from the cli via `code .` when you are in the correct >> directory is the most reliable. >> >> Further, on the cli, try running HLS like this: >> `haskell-language-server-wrapper --debug ` from >> the root of your project. >> Does this report the same error? If yes, more info about the project is >> needed like the .cabal file and the logs. Otherwise, it is a problem with >> the editor (e.g., PATH variable shenanigans). >> >> Best regards, >> Fendor >> On 07/01/2023 10:00, Dennis Raddle wrote: >> >> I'm trying to get HLS set up with a stack project on VS Code. I'm getting >> messages like this: >> >> Could not load module ‘Control.Monad.Except’ >> It is a member of the hidden package ‘mtl-2.2.2’. >> You can run ‘:set -package mtl’ to expose it. >> (Note: this unloads all the modules in the current scope.) >> >> But these are in the "Problems" tab of VS Code (and show as red >> underlines). >> >> When I run stack clean, stack build I don't see any error like this at >> all. >> >> And yes, I made sure mtl was added everywhere in cac.cabal. (I'm using >> cac.cabal not stack.yaml... is that my problem?) >> >> I tried stack clean; stack build; restart HLS several times. >> >> >> >> _______________________________________________ >> 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. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Sat Jan 7 22:10:13 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 7 Jan 2023 17:10:13 -0500 Subject: [Haskell-cafe] HLS in VS Code is identifying problems that don't when I run stack on the command line In-Reply-To: References: <995364a6-4bfc-0cf5-b3e0-071c01c25d1c@gmail.com> Message-ID: Okay I think I solved this. By googling I found that there's a problem with HLS and GHC 10.8.7, so upgrading my project to GHC 9.4.4 fixed it. On Sat, Jan 7, 2023 at 3:53 PM Dennis Raddle wrote: > Sorry it was a bit late when I wrote that last night so it was unclear. > > stack is using GHC 8.10.7 while Haskell Language Server seems to be using > GHC 9.4.4. At various points while using VS Code I've gotten popups like > "HLS is unable to determine GHC version" but later those stopped happening. > > Is this a problem that they are using different versions? Would this > explain why HLS thinks mtl is hidden even though it's exposed in my cabal > file? > > Mike > > > On Sat, Jan 7, 2023 at 5:40 AM Dennis Raddle > wrote: > >> I'm opening the project by running VS Code first, then opening the root >> folder of the project. I don't have a 'code' command installed or no path >> to it set; this doesn't happen by default on MacOS but I could look it up. >> >> But I think I got a better clue by running >> haskell-language-server-wrapper: >> >> I got this line. >> Run entered for >> haskell-language-server-wrapper(haskell-language-server-wrapper) Version >> 1.9.0.0 x86_64 ghc-9.4.4 >> >> And then: >> >> Tool versions found on the $PATH >> cabal: 3.6.2.0 >> stack: 2.3.3 >> ghc: 8.10.7 >> >> My stack.yaml is using the resolver >> lts-18.19 >> which does specify GHC 8.10.7 according to what I looked up. >> >> But that ghc-9.4.4 seems to be a problem. >> >> Thanks! But how to fix? >> >> >> >> On Sat, Jan 7, 2023 at 5:13 AM Fendor wrote: >> >>> How are you launching VSCode? Make sure you open the root of the project >>> in VSCode. >>> Opening VSCode from the cli via `code .` when you are in the correct >>> directory is the most reliable. >>> >>> Further, on the cli, try running HLS like this: >>> `haskell-language-server-wrapper --debug ` from >>> the root of your project. >>> Does this report the same error? If yes, more info about the project is >>> needed like the .cabal file and the logs. Otherwise, it is a problem with >>> the editor (e.g., PATH variable shenanigans). >>> >>> Best regards, >>> Fendor >>> On 07/01/2023 10:00, Dennis Raddle wrote: >>> >>> I'm trying to get HLS set up with a stack project on VS Code. I'm >>> getting messages like this: >>> >>> Could not load module ‘Control.Monad.Except’ >>> It is a member of the hidden package ‘mtl-2.2.2’. >>> You can run ‘:set -package mtl’ to expose it. >>> (Note: this unloads all the modules in the current scope.) >>> >>> But these are in the "Problems" tab of VS Code (and show as red >>> underlines). >>> >>> When I run stack clean, stack build I don't see any error like this at >>> all. >>> >>> And yes, I made sure mtl was added everywhere in cac.cabal. (I'm using >>> cac.cabal not stack.yaml... is that my problem?) >>> >>> I tried stack clean; stack build; restart HLS several times. >>> >>> >>> >>> _______________________________________________ >>> 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. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jclites at mac.com Tue Jan 10 02:52:07 2023 From: jclites at mac.com (Jeff Clites) Date: Mon, 9 Jan 2023 18:52:07 -0800 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: <010f01858d7635a8-736f5dbd-cd4e-4ae2-9427-960f0a815443-000000@us-east-2.amazonses.com> References: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> <010f01858d7635a8-736f5dbd-cd4e-4ae2-9427-960f0a815443-000000@us-east-2.amazonses.com> Message-ID: Very interesting. A few thoughts about potential rough spots: > Representation polymorphism can be made to work today via type classes. That is, we have a `class Representation (r :: RuntimeRep)` whose dictionaries have instructions for how to store variables whose types have kind TYPE r, and also to apply functions to such variables. There's no good way to mock this up today because GHC requires a known RuntimeRep in order to bind a variable, but using instructions in a dictionary is possible instead. This would work just fine -- except that it would be very slow, because it means every store or function-apply requires a dictionary access. It would be disastrous. It would also mean that even to access non-polymorphic function arguments (of a representation-polymorphic function), you would potentially need to consult the dictionaries for all preceding parameters, and that would vary depending on the calling conventions for a particular platform. For example, if a function takes a representation-polymorhpic first parameter and a (non-polymoprhic) unboxed float as its second parameter, then where to find that float would change if the first parameter ends up being an unboxed float. (Or rather, it would probably change for a register-based calling convention and possibly not change for a stack-based calling convention.) That is, assuming the the calling convention for representation-polymorphic function should be the same, once instantiated for a particular representation, as a non-representation-polymorphic function whose arguments have those particular representations. So that means the generated assembly for such a representation-polymorphic function would have to include code to figure all of that out per-invocation. [This is all just about the case of having a single non-specialized implementation as the outcome of compilation.] So that does seem conceptually possible but practically...perhaps not. > However, GHC *already* has machinery for specializing functions to work with known dictionaries. All you would have to do is to ensure that all Representation dictionaries get specialized away; this could be done with a straightforward check (even implementable in a core plugin). So programmers can be polymorphic over representations, and GHC has to work hard to specialize. What this is missing is a nice mechanism for helping the programmer avoid cases that GHC can't specialize -- but that could be added later. I really think this would just work, quite easily. At first glance, it seems like these dictionaries would be just like any other typeclass dictionaries in terms of the possibility of specializing them away (right?), so I wonder how much of the time that is possible. That is, I wonder if the programmer would run into forbidden cases commonly, and how limiting that would be. For instance, could you have a representation-polymorphic `fold` (e.g., which you might call with an unboxed int accumulator value, with a matching accumulator function)? I assume you couldn't have a rank-2 representation-polymorphic function? (That is, you couldn't have a representation-polymorphic unknown function. Is that right?) Just sort of thinking out loud. [I've watched your Tweag videos about Levity Polymorphism but I haven't read the paper, so I hope I'm not asking questions that were already covered there. I need to read the paper!] Thanks, Jeff > On Jan 7, 2023, at 10:20 AM, Richard Eisenberg wrote: > > For what it's worth, this initiative may get a significant boost soon. My main job at Jane Street these days is designing & implementing unboxed types for OCaml (which has never really had them, unlike their long history within GHC). There is much eagerness to use unboxed types. But we've realized that, to meet these expectations, we'll need the equivalent of levity polymorphism. So I'll be spending some time over the next few months (I think) putting together the design there. Once it starts to come together, I can share it and then work to adapt it to Haskell. > > Though as I'm writing this, I see a really easy way to do this in Haskell. (Sadly for me, it won't work in OCaml.) Representation polymorphism can be made to work today via type classes. That is, we have a `class Representation (r :: RuntimeRep)` whose dictionaries have instructions for how to store variables whose types have kind TYPE r, and also to apply functions to such variables. There's no good way to mock this up today because GHC requires a known RuntimeRep in order to bind a variable, but using instructions in a dictionary is possible instead. This would work just fine -- except that it would be very slow, because it means every store or function-apply requires a dictionary access. It would be disastrous. However, GHC *already* has machinery for specializing functions to work with known dictionaries. All you would have to do is to ensure that all Representation dictionaries get specialized away; this could be done with a straightforward check (even implementable in a core plugin). So programmers can be polymorphic over representations, and GHC has to work hard to specialize. What this is missing is a nice mechanism for helping the programmer avoid cases that GHC can't specialize -- but that could be added later. I really think this would just work, quite easily. > > Well, "easily" from a language-design standpoint. An efficient implementation in GHC would be fiddly, because you'd need to annotate every variable with information about its representation: either it's known (good), or it's not, and then the variable's representation is informed by a specific dictionary. I think this could probably all be tracked efficiently, but it wouldn't surprise me if there's a measurable slowdown in compilation times to track these representations. And infer them. > > Left unaddressed here: how to make datatypes representation-polymorphic, which requires a lower-level understanding of data-constructor representations than I have. > > Richard > >> On Jan 6, 2023, at 11:51 AM, Carter Schonwald wrote: >> >> i've written (more opaquely than i'd like), about this topic a few times , including on that ticket https://gitlab.haskell.org/ghc/ghc/-/issues/14917#note_230433 ! >> >> ultimately, you want some notion of function types /lambdas that have the equivalent to the C++ Const-Eval / C++ Template arg "compile time instantiation is the only allowed flavor". >> >> for the particulars in the context of runtime rep levity, my intuitions break down, but i've had examples of the sort of "must be resolved at compile time" where for the behavior i'd need isn't expressible using type classes because those can be instantiated abstractly rather than concretely and still be valid programs. >> >> granted i'm not terribly current on the state of play in >= ghc 9.4 for this stuff, but i would not be surprised if the architectural hooks needed for a "strict staging lambda" arent there yet. (you can manufacture some of this stuff with typed template haskell, BUT theres no mechanism for expressing the primops that certain uses cases, like SIMD shuffle, would need) >> >> On Mon, Jan 2, 2023 at 9:18 AM J. Reinders wrote: >> No, I found it. It is this GHC issue: >> >> https://gitlab.haskell.org/ghc/ghc/-/issues/14917 >> >> > On 2 Jan 2023, at 15:07, Tom Ellis wrote: >> > >> > On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote: >> >> I seem to recall another thread where there were more suggestions >> >> like a special form of type classes that is always guaranteed to >> >> monomorphise away >> > >> > Perhaps this? >> > >> > https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076 From ivanperezdominguez at gmail.com Tue Jan 10 07:25:56 2023 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 9 Jan 2023 23:25:56 -0800 Subject: [Haskell-cafe] [ANN] Copilot 3.13 Message-ID: Dear all, I'm very excited to announce Copilot 3.13. Copilot is a stream-based DSL for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Among others, Copilot has been used at the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. It also serves as a runtime monitoring backend for the requirements elicitation tool FRET (https://github.com/NASA-SW-VnV/fret/), via Ogma ( https://github.com/nasa/ogma). This release fixes 4 bugs in copilot-core and copilot-c99. We have also removed 2 deprecated modules and one dependency. The new release has been published on hackage, as well as github. Current emphasis is on increasing test coverage, removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Users are encouraged to participate by opening issues and asking questions via our github repo ( https://github.com/copilot-language/copilot). I'd also like to take this opportunity to announce that Copilot is now being made available on Ubuntu Lunar 23.04 and Debian Bookworm. We would like to thank the Debian Haskell Group and, most especially, Scott Talbert, for continued effort making Copilot available on Debian-based distros. This will be extremely useful to a great portion of our users, who need to use Copilot as a runtime verification system targeting C, but do not need to become proficient in Haskell. We hope to continue this effort by making Copilot easily available on other distributions and OSs. Happy Haskelling, The Copilot team -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Wed Jan 11 13:13:22 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 11 Jan 2023 13:13:22 +0000 Subject: [Haskell-cafe] Actual levity polymorphism In-Reply-To: References: <7C0A4969-0ACF-4E91-A3B8-DE5176378D7A@gmail.com> <010f01858d7635a8-736f5dbd-cd4e-4ae2-9427-960f0a815443-000000@us-east-2.amazonses.com> Message-ID: <010f0185a0f6b980-10cfbb4c-ae34-4be4-8a48-19e59d5979f0-000000@us-east-2.amazonses.com> > On Jan 9, 2023, at 9:52 PM, Jeff Clites wrote: > > It would also mean that even to access non-polymorphic function arguments (of a representation-polymorphic function), you would potentially need to consult the dictionaries for all preceding parameters, and that would vary depending on the calling conventions for a particular platform. ... So that does seem conceptually possible but practically...perhaps not. That's a good point about later parameters depending on earlier ones. I had been thinking that we need the information per parameter, but that's definitely wrong. We really need the parameters' representations on the -> in `\ x y z -> ...`, not on the x, y, z. Still doable. But definitely not pleasant. > At first glance, it seems like these dictionaries would be just like any other typeclass dictionaries in terms of the possibility of specializing them away (right?), so I wonder how much of the time that is possible. That is, I wonder if the programmer would run into forbidden cases commonly, and how limiting that would be. This is a good question, one I share. > > For instance, could you have a representation-polymorphic `fold` (e.g., which you might call with an unboxed int accumulator value, with a matching accumulator function)? Yes. This is a case where the representation would be statically known, and thus specialized away. All good. > > I assume you couldn't have a rank-2 representation-polymorphic function? (That is, you couldn't have a representation-polymorphic unknown function. Is that right?) This sounds like a case where we can't specialize away. The "cheap and cheerful" version of this simply tries to specialize. If any dictionaries are left after all specialization is complete, we error. This is poor for users, because it makes it very hard / impossible for a user to predict whether their program will be accepted. Put another way, this cheap-and-cheerful approach lacks a declarative specification of what programs are accepted. A more glorious approach, tracking which computations/specializations can be done at compile time, would solve this. That more glory is a large part of what I'll be looking at over the next few months. > > Just sort of thinking out loud. [I've watched your Tweag videos about Levity Polymorphism but I haven't read the paper, so I hope I'm not asking questions that were already covered there. I need to read the paper!] These are great points in the conversation. You seem to understand this well. Thanks, Richard > > Thanks, > > Jeff > >> On Jan 7, 2023, at 10:20 AM, Richard Eisenberg wrote: >> >> For what it's worth, this initiative may get a significant boost soon. My main job at Jane Street these days is designing & implementing unboxed types for OCaml (which has never really had them, unlike their long history within GHC). There is much eagerness to use unboxed types. But we've realized that, to meet these expectations, we'll need the equivalent of levity polymorphism. So I'll be spending some time over the next few months (I think) putting together the design there. Once it starts to come together, I can share it and then work to adapt it to Haskell. >> >> Though as I'm writing this, I see a really easy way to do this in Haskell. (Sadly for me, it won't work in OCaml.) Representation polymorphism can be made to work today via type classes. That is, we have a `class Representation (r :: RuntimeRep)` whose dictionaries have instructions for how to store variables whose types have kind TYPE r, and also to apply functions to such variables. There's no good way to mock this up today because GHC requires a known RuntimeRep in order to bind a variable, but using instructions in a dictionary is possible instead. This would work just fine -- except that it would be very slow, because it means every store or function-apply requires a dictionary access. It would be disastrous. However, GHC *already* has machinery for specializing functions to work with known dictionaries. All you would have to do is to ensure that all Representation dictionaries get specialized away; this could be done with a straightforward check (even implementable in a core plugin). So programmers can be polymorphic over representations, and GHC has to work hard to specialize. What this is missing is a nice mechanism for helping the programmer avoid cases that GHC can't specialize -- but that could be added later. I really think this would just work, quite easily. >> >> Well, "easily" from a language-design standpoint. An efficient implementation in GHC would be fiddly, because you'd need to annotate every variable with information about its representation: either it's known (good), or it's not, and then the variable's representation is informed by a specific dictionary. I think this could probably all be tracked efficiently, but it wouldn't surprise me if there's a measurable slowdown in compilation times to track these representations. And infer them. >> >> Left unaddressed here: how to make datatypes representation-polymorphic, which requires a lower-level understanding of data-constructor representations than I have. >> >> Richard >> >>> On Jan 6, 2023, at 11:51 AM, Carter Schonwald wrote: >>> >>> i've written (more opaquely than i'd like), about this topic a few times , including on that ticket https://gitlab.haskell.org/ghc/ghc/-/issues/14917#note_230433 ! >>> >>> ultimately, you want some notion of function types /lambdas that have the equivalent to the C++ Const-Eval / C++ Template arg "compile time instantiation is the only allowed flavor". >>> >>> for the particulars in the context of runtime rep levity, my intuitions break down, but i've had examples of the sort of "must be resolved at compile time" where for the behavior i'd need isn't expressible using type classes because those can be instantiated abstractly rather than concretely and still be valid programs. >>> >>> granted i'm not terribly current on the state of play in >= ghc 9.4 for this stuff, but i would not be surprised if the architectural hooks needed for a "strict staging lambda" arent there yet. (you can manufacture some of this stuff with typed template haskell, BUT theres no mechanism for expressing the primops that certain uses cases, like SIMD shuffle, would need) >>> >>> On Mon, Jan 2, 2023 at 9:18 AM J. Reinders wrote: >>> No, I found it. It is this GHC issue: >>> >>> https://gitlab.haskell.org/ghc/ghc/-/issues/14917 >>> >>>> On 2 Jan 2023, at 15:07, Tom Ellis wrote: >>>> >>>> On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote: >>>>> I seem to recall another thread where there were more suggestions >>>>> like a special form of type classes that is always guaranteed to >>>>> monomorphise away >>>> >>>> Perhaps this? >>>> >>>> https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076 > > > From cmb21 at st-andrews.ac.uk Wed Jan 11 14:20:16 2023 From: cmb21 at st-andrews.ac.uk (Christopher Brown) Date: Wed, 11 Jan 2023 14:20:16 +0000 Subject: [Haskell-cafe] Fully Funded PhD Scholarship at St Andrews Message-ID: We have a fully funded PhD scholarship available in the School of Computer Science at the University of St Andrews on "Trustworthy Refactoring Tools for Haskell Programs". Any potential candidates are advised to contact Chris Brown (cmb21 at st-andrews.ac.uk) for more information. Full details of the scholarship, the general topic, and how to apply are here: https://blogs.cs.st-andrews.ac.uk/csblog/2023/01/11/fully-funded-phd-scholarship-trustworthy-refactoring-tools-for-haskell-programs/ The deadline for applications is the 1st March 2023 with a September start-date (although there is room for some flexibility due to circumstances). The scholarship is fully funded for 3.5 years. The positions are open for both UK and international applications. You can apply formally at https://www.st-andrews.ac.uk/computer-science/prospective/pgr/how-to-apply/ Kind regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Jan 11 14:55:15 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 11 Jan 2023 15:55:15 +0100 (CET) Subject: [Haskell-cafe] Current state of type-level natural number programming Message-ID: Almost ten years ago I tried to convert the package llvm-tf to use type-level naturals but it did not lead very far. What is the current state of type-level natural number programming and reasoning? I need type-level naturals for vectors of static size. The type checker must know things like: n+n ~ 2*n n*m ~ m*n (Pos - positive natural number) n::Nat, m::Pos -> n+m :: Pos n::Nat, m::Pos -> n*m :: Nat n::Pos, m::Pos -> n*m :: Pos I need to access an element from a heterogeneous list with a typenat index. That is, I need a kind of induction. I know of ghc-typelits-natnormalise, but it has some problems with inequalities that I need: "Could not deduce n~0 from the context n<=0" https://github.com/clash-lang/ghc-typelits-natnormalise/issues/33 "Could not deduce: (n0 + 1) ~ m from the context: 1 <= m" https://github.com/clash-lang/ghc-typelits-natnormalise/issues/59 So, what is the current state of the art? What libraries, what GHC extensions? Any tutorials? From lysxia at gmail.com Wed Jan 11 19:07:10 2023 From: lysxia at gmail.com (Li-yao Xia) Date: Wed, 11 Jan 2023 19:07:10 +0000 Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: References: Message-ID: Hi Henning, Liquid Haskell may be what you're looking for. On 2023-01-11 2:55 PM, Henning Thielemann wrote: > > Almost ten years ago I tried to convert the package llvm-tf to use > type-level naturals but it did not lead very far. > > What is the current state of type-level natural number programming and > reasoning? > > I need type-level naturals for vectors of static size. > The type checker must know things like: > > n+n ~ 2*n > n*m ~ m*n > > (Pos - positive natural number) > n::Nat, m::Pos -> n+m :: Pos > n::Nat, m::Pos -> n*m :: Nat > n::Pos, m::Pos -> n*m :: Pos > > > I need to access an element from a heterogeneous list with a typenat > index. That is, I need a kind of induction. > > > I know of ghc-typelits-natnormalise, but it has some problems with > inequalities that I need: > > "Could not deduce n~0 from the context n<=0" > > https://github.com/clash-lang/ghc-typelits-natnormalise/issues/33 > > > "Could not deduce: (n0 + 1) ~ m from the context: 1 <= m" > > https://github.com/clash-lang/ghc-typelits-natnormalise/issues/59 > > > > So, what is the current state of the art? What libraries, what GHC > extensions? Any tutorials? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jondrews at fastmail.com Thu Jan 12 12:00:51 2023 From: jondrews at fastmail.com (Jonathan Drews) Date: Thu, 12 Jan 2023 05:00:51 -0700 Subject: [Haskell-cafe] Emily Pillmore presentation on Haskell Message-ID: Hi Folks: Next Tuesday, January 17th, Emily Pillmore will give an online presentation to South Eastern Michigan BSD User group (http://www.semibug.org/) at 7 PM Detroit, MI time. I will post the Jitsi link to this list the day before the meeting. I believe the talk will be about 40 - 60 minutes long. It may cover the following topics: * An overview of the Haskell programming language * The Haskell Foundation: what it does and the resources it offers. * Cabal: Common Architecture for Building Applications and Libraries * Question and answer session. -- Kind regards, Jonathan From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Thu Jan 12 13:12:21 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 12 Jan 2023 13:12:21 +0000 Subject: [Haskell-cafe] Does an unboxed unit get pushed to the stack? Message-ID: If I define bar and baz as below then, as I understand it, calling baz requires pushing an argument onto the machine stack. Is the same true for baz, or is "calling" baz the same as "calling" foo, i.e. no argument needs to be pushed? Thanks, Tom {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Bar where import GHC.Prim foo :: Int foo = 1 bar :: (# #) -> Int bar (# #) = 1 baz :: () -> Int baz () = 0 From bertram.felgenhauer at googlemail.com Thu Jan 12 15:01:48 2023 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu, 12 Jan 2023 16:01:48 +0100 Subject: [Haskell-cafe] Does an unboxed unit get pushed to the stack? In-Reply-To: References: Message-ID: Tom Ellis wrote: > If I define bar and baz as below then, as I understand it, calling baz > requires pushing an argument onto the machine stack. Is the same true > for baz, or is "calling" baz the same as "calling" foo, i.e. no > argument needs to be pushed? > > > {-# LANGUAGE MagicHash #-} > {-# LANGUAGE UnboxedTuples #-} > > module Bar where > > import GHC.Prim > > foo :: Int > foo = 1 > > bar :: (# #) -> Int > bar (# #) = 1 > > baz :: () -> Int > baz () = 0 There is more to the story than just arguments. Assuming that nothing gets inlined, - "calling" foo simply uses the existing `foo` closure (at the top level it becomes a static indirection) - calling baz pushes an update frame recording where the result goes onto the stack and the argument as well, and calls the entry point for `baz`. Well, conceptually. Actually, the argument is passed in a register on x86_64. - calling bar pushes an update frame, but does not push or pass an argument to the entry point of `bar`. This is specific to `(# #)` being the final argument of the function. For intermediate arguments, the argument is just skipped. So if you had foo :: Int -> Int foo x = x + 42 bar :: (# #) -> Int -> Int bar (# #) x = x + 42 then `foo 1` and `bar (# #) 1` produce identical same code. If the arity of the function is unknown, as in xyzzy :: ((# #) -> a) -> a xyzzy f = f (# #) xyzzy :: (() -> a) -> a xyzzy f = f () then the distinction is delegated to a helper function in the RTS (`stg_ap_v_fast` vs. `stg_ap_p_fast`; `v` stands for "void", while `p` stands for "pointer") that inspects the info table of the `f` closure to determine whether the argument is the final one that needs special treatment, or whether the argument can simply be skipped. Cheers, Bertram From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Thu Jan 12 15:05:56 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 12 Jan 2023 15:05:56 +0000 Subject: [Haskell-cafe] Does an unboxed unit get pushed to the stack? In-Reply-To: References: Message-ID: On Thu, Jan 12, 2023 at 04:01:48PM +0100, Bertram Felgenhauer via Haskell-Cafe wrote: > Tom Ellis wrote: > > If I define bar and baz as below then, as I understand it, calling baz > > requires pushing an argument onto the machine stack. Is the same true > > for baz, or is "calling" baz the same as "calling" foo, i.e. no > > argument needs to be pushed? > > > > > > {-# LANGUAGE MagicHash #-} > > {-# LANGUAGE UnboxedTuples #-} > > > > module Bar where > > > > import GHC.Prim > > > > foo :: Int > > foo = 1 > > > > bar :: (# #) -> Int > > bar (# #) = 1 > > > > baz :: () -> Int > > baz () = 0 > > There is more to the story than just arguments. Assuming that nothing > gets inlined Very helpful, thank you! From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Thu Jan 12 15:12:12 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 12 Jan 2023 15:12:12 +0000 Subject: [Haskell-cafe] Unboxed, zero-width :~:/Refl? In-Reply-To: References: Message-ID: Subsequent to Bertram's helpful answer about the unboxed unit tuple as an argument type, I have a follow-up question. Data.Typeable allows me to write a nice API like refl/unRefl below: {-# LANGUAGE GHC2021 #-} {-# LANGUAGE LambdaCase #-} module Example where import Data.Typeable refl :: a :~: a refl = Refl unRefl :: a :~: b -> (a ~ b => r) -> r unRefl = \case Refl -> \r -> r But why I am paying the cost for a boxed argument to unRefl? Is there an alternative API using an unboxed, zero-width equality witness that means I pay minimal cost for its existence? That is, an API like the following where `a :~:# b` is zero-width unboxed? unboxedRefl :: a :~:# a unUnboxedRefl :: a :~:# b -> (a ~ b => r) -> r I guess I can do it the following unpleasant way, if I keep the constructor hidden. But is there a better way? newtype a :~:# a = Refl (# #) unboxedRefl :: a :~:# a unboxedRefl = Refl (# #) unUnboxedRefl :: a :~:# b -> (a ~ b => r) -> r unUnboxedRefl (Refl (# #)) = unsafeCoerce Tom On Thu, Jan 12, 2023 at 04:01:48PM +0100, Bertram Felgenhauer via Haskell-Cafe wrote: > Tom Ellis wrote: > > If I define bar and baz as below then, as I understand it, calling baz > > requires pushing an argument onto the machine stack. Is the same true > > for baz, or is "calling" baz the same as "calling" foo, i.e. no > > argument needs to be pushed? > > > > > > {-# LANGUAGE MagicHash #-} > > {-# LANGUAGE UnboxedTuples #-} > > > > module Bar where > > > > import GHC.Prim > > > > foo :: Int > > foo = 1 > > > > bar :: (# #) -> Int > > bar (# #) = 1 > > > > baz :: () -> Int > > baz () = 0 > > There is more to the story than just arguments. Assuming that nothing > gets inlined, > > - "calling" foo simply uses the existing `foo` closure (at the top > level it becomes a static indirection) > > - calling baz pushes an update frame recording where the result goes > onto the stack and the argument as well, and calls the entry point > for `baz`. Well, conceptually. Actually, the argument is passed in a > register on x86_64. > > - calling bar pushes an update frame, but does not push or pass an > argument to the entry point of `bar`. > > This is specific to `(# #)` being the final argument of the function. > For intermediate arguments, the argument is just skipped. So if you > had > > foo :: Int -> Int > foo x = x + 42 > > bar :: (# #) -> Int -> Int > bar (# #) x = x + 42 > > then `foo 1` and `bar (# #) 1` produce identical same code. > > If the arity of the function is unknown, as in > > xyzzy :: ((# #) -> a) -> a > xyzzy f = f (# #) > > xyzzy :: (() -> a) -> a > xyzzy f = f () > > then the distinction is delegated to a helper function in the RTS > (`stg_ap_v_fast` vs. `stg_ap_p_fast`; `v` stands for "void", while `p` > stands for "pointer") that inspects the info table of the `f` closure > to determine whether the argument is the final one that needs special > treatment, or whether the argument can simply be skipped. From oleg.grenrus at iki.fi Thu Jan 12 15:51:58 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 12 Jan 2023 17:51:58 +0200 Subject: [Haskell-cafe] Unboxed, zero-width :~:/Refl? In-Reply-To: References: Message-ID: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> Because you have to actually compute `Refl` for it to be valid. Consirer a    lie :: a :~: b    lie = lie When you match on `lie` to get a proof of `a ~ b`, it will loop, so you won't make unsafeCoerce out of a thin air. Your a :~:# b doesn't work. you cannot define unboxedRefl:     Top-level bindings for unlifted types aren't allowed:       unboxedRefl = Refl (##) Also  a ~ b is *boxed* constraint, so you need to create it e.g.     unUnboxedRefl :: forall a b r. a :~:# b -> (a ~ b => r) -> r     unUnboxedRefl (URefl (# #)) r = case unsafeCoerce (Refl :: a :~: a) :: a :~: b of Refl -> r Then you could (try to) have a local lie:     myUnsafeCoerce :: forall a b. a -> b     myUnsafeCoerce a =         let lie :: a :~:# b             lie = lie         in unUnboxedRefl lie a GHC won't accept it (Recursive bindings for unlifted types aren't allowed: lie = lie). In summary, GHC tries hard to not let you define unsafeCoerce. On 12.1.2023 17.12, Tom Ellis wrote: > Subsequent to Bertram's helpful answer about the unboxed unit tuple as > an argument type, I have a follow-up question. > > Data.Typeable allows me to write a nice API like refl/unRefl below: > > {-# LANGUAGE GHC2021 #-} > {-# LANGUAGE LambdaCase #-} > > module Example where > > import Data.Typeable > > refl :: a :~: a > refl = Refl > > unRefl :: a :~: b -> (a ~ b => r) -> r > unRefl = \case Refl -> \r -> r > > But why I am paying the cost for a boxed argument to unRefl? Is there > an alternative API using an unboxed, zero-width equality witness that > means I pay minimal cost for its existence? That is, an API like the > following where `a :~:# b` is zero-width unboxed? > > unboxedRefl :: a :~:# a > > unUnboxedRefl :: a :~:# b -> (a ~ b => r) -> r > > I guess I can do it the following unpleasant way, if I keep the > constructor hidden. But is there a better way? > > > newtype a :~:# a = Refl (# #) > > unboxedRefl :: a :~:# a > unboxedRefl = Refl (# #) > > unUnboxedRefl :: a :~:# b -> (a ~ b => r) -> r > unUnboxedRefl (Refl (# #)) = unsafeCoerce > > Tom > > > On Thu, Jan 12, 2023 at 04:01:48PM +0100, Bertram Felgenhauer via Haskell-Cafe wrote: >> Tom Ellis wrote: >>> If I define bar and baz as below then, as I understand it, calling baz >>> requires pushing an argument onto the machine stack. Is the same true >>> for baz, or is "calling" baz the same as "calling" foo, i.e. no >>> argument needs to be pushed? >>> >>> >>> {-# LANGUAGE MagicHash #-} >>> {-# LANGUAGE UnboxedTuples #-} >>> >>> module Bar where >>> >>> import GHC.Prim >>> >>> foo :: Int >>> foo = 1 >>> >>> bar :: (# #) -> Int >>> bar (# #) = 1 >>> >>> baz :: () -> Int >>> baz () = 0 >> There is more to the story than just arguments. Assuming that nothing >> gets inlined, >> >> - "calling" foo simply uses the existing `foo` closure (at the top >> level it becomes a static indirection) >> >> - calling baz pushes an update frame recording where the result goes >> onto the stack and the argument as well, and calls the entry point >> for `baz`. Well, conceptually. Actually, the argument is passed in a >> register on x86_64. >> >> - calling bar pushes an update frame, but does not push or pass an >> argument to the entry point of `bar`. >> >> This is specific to `(# #)` being the final argument of the function. >> For intermediate arguments, the argument is just skipped. So if you >> had >> >> foo :: Int -> Int >> foo x = x + 42 >> >> bar :: (# #) -> Int -> Int >> bar (# #) x = x + 42 >> >> then `foo 1` and `bar (# #) 1` produce identical same code. >> >> If the arity of the function is unknown, as in >> >> xyzzy :: ((# #) -> a) -> a >> xyzzy f = f (# #) >> >> xyzzy :: (() -> a) -> a >> xyzzy f = f () >> >> then the distinction is delegated to a helper function in the RTS >> (`stg_ap_v_fast` vs. `stg_ap_p_fast`; `v` stands for "void", while `p` >> stands for "pointer") that inspects the info table of the `f` closure >> to determine whether the argument is the final one that needs special >> treatment, or whether the argument can simply be skipped. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Thu Jan 12 16:24:12 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 12 Jan 2023 16:24:12 +0000 Subject: [Haskell-cafe] Unboxed, zero-width :~:/Refl? In-Reply-To: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> Message-ID: On Thu, Jan 12, 2023 at 05:51:58PM +0200, Oleg Grenrus wrote: > Because you have to actually compute `Refl` for it to be valid. Sure, but an unboxed constraint would be unlifted, wouldn't it? > Your a :~:# b doesn't work. you cannot define unboxedRefl: > >     Top-level bindings for unlifted types aren't allowed: >       unboxedRefl = Refl (##) Ah, that's interesting. Why is that? I can't immediately see a theoretical blocker. There's a practical one, of course: strict bindings are not allowed at the top level either, I guess to prevent infinite loops. Seems strange though. Does OCaml not allow defining constants at the top level? > Also  a ~ b is *boxed* constraint, so you need to create it e.g. That seems enough to make my scheme impossible. By why is it boxed? It doesn't seem like it actually needs any evidence to make it work. Tom From haskellcafe at dandart.co.uk Thu Jan 12 17:24:21 2023 From: haskellcafe at dandart.co.uk (Dan Dart) Date: Thu, 12 Jan 2023 17:24:21 +0000 Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: References: Message-ID: Hey! I had a go at this too the other week and came across the same >= == problem you're having. I'm not sure if it's doable this way without dependent types, but maybe typed unary would work. I found a good video series to study by Richard A. Eisenberg. He mentions typed unary numbers and goes over existentials such that he doesn't have the same problem. https://www.youtube.com/watch?v=PHS3Q-tRjFQ https://www.youtube.com/watch?v=WHeBxSBY0fc https://www.youtube.com/watch?v=dK5be4cdQdE https://www.youtube.com/watch?v=8AKtqFY1ueM https://www.youtube.com/watch?v=jPZciAJ0oaw https://www.youtube.com/watch?v=S5Oz_w9HDs0 Hope that helps Dan Dart From lemming at henning-thielemann.de Thu Jan 12 17:49:49 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 12 Jan 2023 18:49:49 +0100 (CET) Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023, Dan Dart wrote: > I had a go at this too the other week and came across the same >= == > problem you're having. > > I'm not sure if it's doable this way without dependent types, but > maybe typed unary would work. I found a good video series to study by > Richard A. Eisenberg. He mentions typed unary numbers and goes over > existentials such that he doesn't have the same problem. So far I am using type-level decimal numbers of the 'tfp' package. My numbers can become a bit bigger, like 256 or 512, so Unary might be too slow. From david.feuer at gmail.com Thu Jan 12 17:58:42 2023 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Jan 2023 12:58:42 -0500 Subject: [Haskell-cafe] Unboxed, zero-width :~:/Refl? In-Reply-To: References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> Message-ID: On Thu, Jan 12, 2023, 11:24 AM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > Ah, that's interesting. Why is that? I can't immediately see a > theoretical blocker. There's a practical one, of course: strict > bindings are not allowed at the top level either, I guess to prevent > infinite loops. Seems strange though. Does OCaml not allow defining > constants at the top level? > OCaml has a notion of module loading time, at which top level definitions are all run. Haskell has nothing like that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konn.jinro at gmail.com Thu Jan 12 18:05:29 2023 From: konn.jinro at gmail.com (=?utf-8?B?55+z5LqV5aSn5rW3?=) Date: Fri, 13 Jan 2023 03:05:29 +0900 Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: References: Message-ID: <4DFD1917-C889-44FF-B3F4-FC9B7D008406@gmail.com> Hi, > I know of ghc-typelits-natnormalise, but it has some problems with inequalities that I need: > > "Could not deduce n~0 from the context n<=0" > "Could not deduce: (n0 + 1) ~ m from the context: 1 <= m" > > So, what is the current state of the art? What libraries, what GHC extensions? Any tutorials? Just a shameless plug: I deviced ghc-typelits-presburger exactly to solve such problems, and applying in conjunction with ghc-typelits-natnormalise in production code: https://hackage.haskell.org/packages/search?terms=ghc-typelits-presburger Formally, this augments GHC's type checker with Presburger Arithmetic Solver. https://en.wikipedia.org/wiki/Presburger_arithmetic In other words, the plugin can solve propositions in natural number arithmetic which incorporates only addition, subtraction, inequalities and constant-factor multiplication. This fragment of Peano arithmetic is known to be decidable (note that it cannot solve the proposition incorporating arbitrary (indefinite) multiplications to avoid incompleteness hell). Although there indeed be some propositions that this plugin cannot solve, but together with ghc-typelits-natnormalise and ghc-typelits-knownnat, relatively wide range of propositions can be solved automatically in my experiences. Thanks, -- Hiromi ISHII konn.jinro at gmail.com > 2023/01/11 23:55、Henning Thielemann のメール: > > > Almost ten years ago I tried to convert the package llvm-tf to use type-level naturals but it did not lead very far. > > What is the current state of type-level natural number programming and reasoning? > > I need type-level naturals for vectors of static size. > The type checker must know things like: > > n+n ~ 2*n > n*m ~ m*n > > (Pos - positive natural number) > n::Nat, m::Pos -> n+m :: Pos > n::Nat, m::Pos -> n*m :: Nat > n::Pos, m::Pos -> n*m :: Pos > > > I need to access an element from a heterogeneous list with a typenat index. That is, I need a kind of induction. > > > I know of ghc-typelits-natnormalise, but it has some problems with inequalities that I need: > > "Could not deduce n~0 from the context n<=0" > > https://github.com/clash-lang/ghc-typelits-natnormalise/issues/33 > > > "Could not deduce: (n0 + 1) ~ m from the context: 1 <= m" > > https://github.com/clash-lang/ghc-typelits-natnormalise/issues/59 > > > > So, what is the current state of the art? What libraries, what GHC extensions? Any tutorials? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.png Type: image/png Size: 2792 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wikipedia.png Type: image/png Size: 1313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From lemming at henning-thielemann.de Thu Jan 12 18:10:25 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 12 Jan 2023 19:10:25 +0100 (CET) Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: <4DFD1917-C889-44FF-B3F4-FC9B7D008406@gmail.com> References: <4DFD1917-C889-44FF-B3F4-FC9B7D008406@gmail.com> Message-ID: On Fri, 13 Jan 2023, 石井大海 wrote: > Just a shameless plug: I deviced ghc-typelits-presburger exactly to solve such problems, and applying in conjunction with ghc-typelits-natnormalise in production code: > > https://hackage.haskell.org/packages/search?terms=ghc-typelits-presburger > > Formally, this augments GHC's type checker with Presburger Arithmetic Solver. This sounds promising! I know that Iavor Diatchki implemented a Presburger Arithmetic Solver for GHC type checking many years ago, but when I asked last time, he recommended ghc-typelits-natnormalise. > Although there indeed be some propositions that this plugin cannot > solve, but together with ghc-typelits-natnormalise and > ghc-typelits-knownnat, relatively wide range of propositions can be > solved automatically in my experiences. It is good to know that I can combine different type checker plugins. From jondrews at fastmail.com Fri Jan 13 08:25:26 2023 From: jondrews at fastmail.com (Jonathan Drews) Date: Fri, 13 Jan 2023 01:25:26 -0700 Subject: [Haskell-cafe] Emily Pillmore presentation on Haskell In-Reply-To: References: Message-ID: Folks: This is cancelled. Emily is very busy and cannot give a presentation right now. On Thu, Jan 12, 2023 at 05:00:51AM -0700, Jonathan Drews wrote: > Hi Folks: > > Next Tuesday, January 17th, Emily Pillmore will give an online > presentation to South Eastern Michigan BSD User group (http://www.semibug.org/) > at 7 PM Detroit, MI time. I will post the Jitsi link to this list the > day before the meeting. > > I believe the talk will be about 40 - 60 minutes long. It may cover > the following topics: > > * An overview of the Haskell programming language > * The Haskell Foundation: what it does and the resources it offers. > * Cabal: Common Architecture for Building Applications and Libraries > * Question and answer session. > > -- > Kind regards, > Jonathan > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From goemansrowan at gmail.com Fri Jan 13 08:32:02 2023 From: goemansrowan at gmail.com (rowan goemans) Date: Fri, 13 Jan 2023 09:32:02 +0100 Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: References: <4DFD1917-C889-44FF-B3F4-FC9B7D008406@gmail.com> Message-ID: <7edfa2f8-fee1-cbdd-cb4d-f95b03ad924a@gmail.com> I'm a heavy user of ghc-typelits-natnormalise. I can feel your pain that it sometimes isn't able to solve seemingly "simple" constraints. But not all is lost in those cases. The `constraints` package allows one to solve `Nat` constraints out of thin air, provided you go through a function to do it. nLEZeroIsZeroRule :: (n <= 0) :- (n ~ 0) nLEZeroIsZeroRule = Sub (unsafeCoerce (Dict :: Dict (a ~ a))) foo :: (n ~ 0) => Int foo = 10 bar :: forall (n :: Nat). (n <= 0) => Int bar = case nLEZeroIsZeroRule @n of { Sub Dict -> foo @n } If you can hide your contraints behind this for users of your library it might not such a bad option. I don't need very many of these since natnormalise does by far the most work for me. This just fills the gaps. Rowan Goemans On 1/12/23 19:10, Henning Thielemann wrote: > > On Fri, 13 Jan 2023, 石井大海 wrote: > >> Just a shameless plug: I deviced ghc-typelits-presburger exactly to >> solve such problems, and applying in conjunction with >> ghc-typelits-natnormalise in production code: >> >> https://hackage.haskell.org/packages/search?terms=ghc-typelits-presburger >> >> >> Formally, this augments GHC's type checker with Presburger Arithmetic >> Solver. > > This sounds promising! > > I know that Iavor Diatchki implemented a Presburger Arithmetic Solver > for GHC type checking many years ago, but when I asked last time, he > recommended ghc-typelits-natnormalise. > >> Although there indeed be some propositions that this plugin cannot >> solve, but together with ghc-typelits-natnormalise and >> ghc-typelits-knownnat, relatively wide range of propositions can be >> solved automatically in my experiences. > > It is good to know that I can combine different type checker plugins. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From lemming at henning-thielemann.de Fri Jan 13 10:02:16 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 13 Jan 2023 11:02:16 +0100 (CET) Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: <1bf82a7b-c088-50b9-a6b9-53bbeb530a43@gmail.com> References: <4DFD1917-C889-44FF-B3F4-FC9B7D008406@gmail.com> <1bf82a7b-c088-50b9-a6b9-53bbeb530a43@gmail.com> Message-ID: On Fri, 13 Jan 2023, rowan goemans wrote: > I'm a heavy user of ghc-typelits-natnormalise. > > I can feel your pain that it sometimes isn't able to solve seemingly "simple" > constraints. But not all is lost in those cases. The `constraints` package > allows one to solve `Nat` constraints out of thin air, provided you go > through a function to do it. > > nLEZeroIsZeroRule :: (n <= 0) :- (n ~ 0) > nLEZeroIsZeroRule = Sub (unsafeCoerce (Dict :: Dict (a ~ a))) Good to know that there are ways to add missing transformations. Ideally there would be a way without unsafeCoerce, i.e. that I could prove a property manually using some proof steps expressed in functions. Alternatively, maybe I can write missing steps in a custom type checker plugin. Has someone already tried to connect SBV to a type checker plugin? From konn.jinro at gmail.com Fri Jan 13 10:09:10 2023 From: konn.jinro at gmail.com (=?utf-8?B?55+z5LqV5aSn5rW3?=) Date: Fri, 13 Jan 2023 19:09:10 +0900 Subject: [Haskell-cafe] Current state of type-level natural number programming In-Reply-To: References: <4DFD1917-C889-44FF-B3F4-FC9B7D008406@gmail.com> <1bf82a7b-c088-50b9-a6b9-53bbeb530a43@gmail.com> Message-ID: >> I'm a heavy user of ghc-typelits-natnormalise. >> >> I can feel your pain that it sometimes isn't able to solve seemingly "simple" constraints. But not all is lost in those cases. The `constraints` package allows one to solve `Nat` constraints out of thin air, provided you go through a function to do it. >> >> nLEZeroIsZeroRule :: (n <= 0) :- (n ~ 0) >> nLEZeroIsZeroRule = Sub (unsafeCoerce (Dict :: Dict (a ~ a))) > > Good to know that there are ways to add missing transformations. > > Ideally there would be a way without unsafeCoerce, i.e. that I could prove a property manually using some proof steps expressed in functions. I also developed [type-natural] package, which comes with the showcase of arithmetic lemma. This builds on [equational-reasoning] package to make proof-writing easier. [type-natural]: https://hackage.haskell.org/package/type-natural [equational-reasoning]: https://hackage.haskell.org/package/equational-reasoning -- Hiromi ISHII konn.jinro at gmail.com > 2023/01/13 19:02、Henning Thielemann のメール: > > > On Fri, 13 Jan 2023, rowan goemans wrote: > >> I'm a heavy user of ghc-typelits-natnormalise. >> >> I can feel your pain that it sometimes isn't able to solve seemingly "simple" constraints. But not all is lost in those cases. The `constraints` package allows one to solve `Nat` constraints out of thin air, provided you go through a function to do it. >> >> nLEZeroIsZeroRule :: (n <= 0) :- (n ~ 0) >> nLEZeroIsZeroRule = Sub (unsafeCoerce (Dict :: Dict (a ~ a))) > > Good to know that there are ways to add missing transformations. > > Ideally there would be a way without unsafeCoerce, i.e. that I could prove a property manually using some proof steps expressed in functions. > > > Alternatively, maybe I can write missing steps in a custom type checker plugin. > > > Has someone already tried to connect SBV to a type checker plugin? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From lemming at henning-thielemann.de Fri Jan 13 18:04:20 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 13 Jan 2023 19:04:20 +0100 (CET) Subject: [Haskell-cafe] induction on type-level Nat Message-ID: <12d074f8-b0fc-6481-a06-ad1452ecf919@henning-thielemann.de> I want to define a list with type-level Nat length: type family List (n::Nat) :: Type -> Type where List 0 = End List n = Cons (List (n-1)) data End a = End data Cons f a = Cons { head :: a, tail :: f a } But this way, GHC cannot match ‘List (n+1)’ with ‘Cons (List n)’, also not with the magic type checker plugings suggested before. I guess I need a another way to define List or some support for the type checker to accept List (n+1) ~ Cons (List n). From ben at well-typed.com Fri Jan 13 23:01:19 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 13 Jan 2023 18:01:19 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-alpha1 is now available Message-ID: <87r0vyt4yd.fsf@smart-cactus.org> The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha1. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1-alpha1/ This is the first alpha release in the 9.6 series which will bring a number of exciting features: * A new Javascript code generation backend * A new WebAssembly code generation backend, * Significant latency improvements in the non-moving garbage collector * Support for loading of multiple components in GHCi * Efficient support for delimited continuations * Improvements in error messages * Numerous improvements in compiler-residency Note that both the Javascript and WebAssembly backends are still in a state of infancy and are present in this release as a technology preview; we hope that they will mature considerably before the final 9.6.1 release. Please give this release a try and open a [ticket] if you see anything amiss. Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lemming at henning-thielemann.de Mon Jan 16 11:42:51 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 16 Jan 2023 12:42:51 +0100 (CET) Subject: [Haskell-cafe] induction on type-level Nat In-Reply-To: <12d074f8-b0fc-6481-a06-ad1452ecf919@henning-thielemann.de> References: <12d074f8-b0fc-6481-a06-ad1452ecf919@henning-thielemann.de> Message-ID: <51da7853-c9f5-79cc-adb5-278d30e9fc14@henning-thielemann.de> On Fri, 13 Jan 2023, Henning Thielemann wrote: > I want to define a list with type-level Nat length: > > type family List (n::Nat) :: Type -> Type where > List 0 = End > List n = Cons (List (n-1)) > > data End a = End > data Cons f a = Cons { head :: a, tail :: f a } Alternative approach with a GADT: data T n a where End :: T 0 a Cons :: a -> T n a -> T (n+1) a viewL :: T (n+1) a -> (a, T n a) viewL (Cons x xs) = (x, xs) testEnd :: T 0 a -> () testEnd End = () For viewL GHC reports a missing pattern match on 'End' and for testEnd it reports a missing match on 'Cons'. If I add the constraint (1<=n+1) to Cons then the testEnd warning disappears. If I add the constraint (1<=n+1) to viewL, then its warning disappears, as well. From lemming at henning-thielemann.de Mon Jan 16 11:46:33 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 16 Jan 2023 12:46:33 +0100 (CET) Subject: [Haskell-cafe] induction on type-level Nat In-Reply-To: <51da7853-c9f5-79cc-adb5-278d30e9fc14@henning-thielemann.de> References: <12d074f8-b0fc-6481-a06-ad1452ecf919@henning-thielemann.de> <51da7853-c9f5-79cc-adb5-278d30e9fc14@henning-thielemann.de> Message-ID: On Mon, 16 Jan 2023, Henning Thielemann wrote: > Alternative approach with a GADT: > > data T n a where > End :: T 0 a > Cons :: a -> T n a -> T (n+1) a > > ... > > If I add the constraint (1<=n+1) to Cons then the testEnd warning > disappears. This definition looks less stupid and works, too: data T n a where End :: T 0 a Cons :: (1<=n) => a -> T (n-1) a -> T n a From ben at well-typed.com Mon Jan 16 14:02:21 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 16 Jan 2023 09:02:21 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-alpha1 is now available In-Reply-To: References: <87r0vyt4yd.fsf@smart-cactus.org> Message-ID: <87lem2tw6g.fsf@smart-cactus.org> George Colpitts writes: > Hi > > I believe llvm does not work in this alpha as 21936 is still open. Is that > correct? > Indeed we do not yet support LLVM 15 but all previous LLVM versions continue to work. We can try to fix this for the final release. > I also believe that when it does work it will require llvm 15 which will be > incompatible with earlier versions of ghc. Is that correct? > Early indications suggest that supporting LLVM 15 will require that we raise the minimum supported version to LLVM 13. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From olf at aatal-apotheke.de Mon Jan 16 19:00:26 2023 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 16 Jan 2023 20:00:26 +0100 Subject: [Haskell-cafe] induction on type-level Nat Message-ID: <8f34d3645c1dec13cadc92dbe11102d3343f13f4.camel@aatal-apotheke.de> > Alternative approach with a GADT: > > data T n a where > End :: T 0 a > Cons :: a -> T n a -> T (n+1) a > > viewL :: T (n+1) a -> (a, T n a) > viewL (Cons x xs) = (x, xs) > > testEnd :: T 0 a -> () > testEnd End = () > > > For viewL GHC reports a missing pattern match on 'End' and for > testEnd it > reports a missing match on 'Cons'. If I add the constraint (1<=n+1) > to > Cons then the testEnd warning disappears. If I add the constraint > (1<=n+1) > to viewL, then its warning disappears, as well. So the theory of type-level nats lacks the theorem forall m n. n+m <= n :: Nat -> Nat -> Constraint The infix type operator + from GHC.TypeLits constrains n in Cons to kind Nat. So the theorem above ought to be available to the type checker. Hiromi's type-natural package has Lemmas plusLeqL and plusLeqR for this. Olaf From benjamin.redelings at gmail.com Fri Jan 20 01:40:57 2023 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Thu, 19 Jan 2023 20:40:57 -0500 Subject: [Haskell-cafe] C++ Haskell interpreter with GADTs + Type Families + Rank-n types Message-ID: <6ce5f670-6ece-b71d-3331-a1821db4dbbc@gmail.com> Hi all, I don't want to oversell this, but in case anyone is interested, I've been working on a Haskell interpreter that is written in C++.  This isn't intended to compete with GHC.  It doesn't generate machine code, and it is not fast. However, I had a reason to try and implement Haskell typechecking in C++.  So if anyone is interested in how to write their own Haskell compiler, then this might possibly be of interest. Otherwise, probably not. So far I have: 1. Parser 2. Renamer - hacky.  Infix handling is a separate pass. 3. Typechecker - standard constraints + rank n types + GADTS + type families.  But no newtypes and no coercions. 4. Desugarer - the desugarer generates a language w/o type-level lambdas or coercions. 5. Optimizer - inlining, let-floating, case-of-case, etc.  No SpecConstr.  No Rules. 6. Translation to de-Bruijn notation prior to execution (See Sestoft 1997, "Deriving a lazy abstract machine") 7. Interpreter - a special-purpose dependency-tracking interpreter. The revelant code is here: https://github.com/bredelings/BAli-Phy/tree/master/src/computation After compiling the executable, you would run use it to run a Haskell program like this:     bali-phy --run-module Main.hs Tests are in: https://github.com/bredelings/BAli-Phy/tree/master/tests/haskell -BenRI From lemming at henning-thielemann.de Fri Jan 20 09:34:26 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 20 Jan 2023 10:34:26 +0100 (CET) Subject: [Haskell-cafe] C++ Haskell interpreter with GADTs + Type Families + Rank-n types In-Reply-To: <6ce5f670-6ece-b71d-3331-a1821db4dbbc@gmail.com> References: <6ce5f670-6ece-b71d-3331-a1821db4dbbc@gmail.com> Message-ID: On Thu, 19 Jan 2023, Benjamin Redelings wrote: > I don't want to oversell this, but in case anyone is interested, I've > been working on a Haskell interpreter that is written in C++.  This > isn't intended to compete with GHC.  It doesn't generate machine code, > and it is not fast. How does it compare to Hugs? Ok, Hugs does not support type families, only functional dependencies. From ivanperezdominguez at gmail.com Fri Jan 20 15:44:48 2023 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 20 Jan 2023 07:44:48 -0800 Subject: [Haskell-cafe] Anyone working on improving HPC Message-ID: Hi everyone, A while back there were a few exchanges about the state of HPC and I remember reading that someone was interested in pushing a bit for improving the tool and the reports generated. Does anyone know if that's happening and who is working on that? I forgot where I saw it and I can't find it. It could have been haskell-cafe, discord, chat, idk. Thanks, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Jan 20 16:59:11 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 20 Jan 2023 11:59:11 -0500 Subject: [Haskell-cafe] Anyone working on improving HPC In-Reply-To: References: Message-ID: <87fsc5rvlf.fsf@smart-cactus.org> Ivan Perez writes: > Hi everyone, > > A while back there were a few exchanges about the state of HPC and I > remember reading that someone was interested in pushing a bit for improving > the tool and the reports generated. > > Does anyone know if that's happening and who is working on that? > Yes, there is currently a small group of people looking to modernize it. I have Cc'd David Binder who has been working on this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From bryan at haskell.foundation Fri Jan 20 17:04:57 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Fri, 20 Jan 2023 19:04:57 +0200 Subject: [Haskell-cafe] Anyone working on improving HPC In-Reply-To: <87fsc5rvlf.fsf@smart-cactus.org> References: <87fsc5rvlf.fsf@smart-cactus.org> Message-ID: See also https://gitlab.haskell.org/hpc/hpc-bin . On Fri, 20 Jan 2023 at 18:59, Ben Gamari wrote: > > Ivan Perez writes: > > > Hi everyone, > > > > A while back there were a few exchanges about the state of HPC and I > > remember reading that someone was interested in pushing a bit for improving > > the tool and the reports generated. > > > > Does anyone know if that's happening and who is working on that? > > > Yes, there is currently a small group of people looking to modernize it. > I have Cc'd David Binder who has been working on this. > > Cheers, > > - Ben > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From lemming at henning-thielemann.de Fri Jan 20 21:13:10 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 20 Jan 2023 22:13:10 +0100 (CET) Subject: [Haskell-cafe] Anyone working on improving HPC In-Reply-To: References: <87fsc5rvlf.fsf@smart-cactus.org> Message-ID: <276af279-14b4-e3ca-8367-8782b829771@henning-thielemann.de> On Fri, 20 Jan 2023, Bryan Richter via Haskell-Cafe wrote: > See also https://gitlab.haskell.org/hpc/hpc-bin . I hoped that HPC would refer to High Performance Computing. :-) From steven at steshaw.org Fri Jan 20 21:24:21 2023 From: steven at steshaw.org (Steven Shaw) Date: Sat, 21 Jan 2023 07:24:21 +1000 Subject: [Haskell-cafe] Anyone working on improving HPC In-Reply-To: <276af279-14b4-e3ca-8367-8782b829771@henning-thielemann.de> References: <87fsc5rvlf.fsf@smart-cactus.org> <276af279-14b4-e3ca-8367-8782b829771@henning-thielemann.de> Message-ID: There was also an alternative coverage tool recently announced: https://cs-syd.eu/posts/2022-12-16-announcing-dekking. On Sat, 21 Jan 2023 at 07:13, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Fri, 20 Jan 2023, Bryan Richter via Haskell-Cafe wrote: > > > See also https://gitlab.haskell.org/hpc/hpc-bin . > > I hoped that HPC would refer to High Performance Computing. :-) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.redelings at gmail.com Sat Jan 21 05:17:27 2023 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Sat, 21 Jan 2023 00:17:27 -0500 Subject: [Haskell-cafe] C++ Haskell interpreter with GADTs + Type Families + Rank-n types In-Reply-To: References: <6ce5f670-6ece-b71d-3331-a1821db4dbbc@gmail.com> Message-ID: <1a314973-cdf2-ac61-b28e-1abfb4d3a24d@gmail.com> On 1/20/23 4:34 AM, Henning Thielemann wrote: > > On Thu, 19 Jan 2023, Benjamin Redelings wrote: > >> I don't want to oversell this, but in case anyone is interested, I've >> been working on a Haskell interpreter that is written in C++.  This >> isn't intended to compete with GHC.  It doesn't generate machine >> code, and it is not fast. > > How does it compare to Hugs? Ok, Hugs does not support type families, > only functional dependencies. I think this uses a different approach to solving constraints than Hugs. 1. Unifying types a and b results in recording a "wanted" constraint (a ~ n).  You can manually write constraints like (a ~ F b). 2. Wanted constraints are deferred -- they are handled later in the "solver". 3. Typechecking now makes heavy use of nested "implication constraints":     exists a b c. givens => wanteds 4. Defaulting is postponed until the whole program has been analyzed by the typechecker. 5. Error messages likewise postpone until after defaulting. Basically you look at wanted constraints, including looking into nested implication constraints, and complain about any constraints that remain. Much of this is described in the OutsideIn(X) paper: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf I don't think this was around when Hugs was active. From benjamin.redelings at gmail.com Sat Jan 21 05:25:12 2023 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Sat, 21 Jan 2023 00:25:12 -0500 Subject: [Haskell-cafe] C++ Haskell interpreter with GADTs + Type Families + Rank-n types In-Reply-To: <1a314973-cdf2-ac61-b28e-1abfb4d3a24d@gmail.com> References: <6ce5f670-6ece-b71d-3331-a1821db4dbbc@gmail.com> <1a314973-cdf2-ac61-b28e-1abfb4d3a24d@gmail.com> Message-ID: > 1. Unifying types a and b results in recording a "wanted" constraint > (a ~ n).  You can manually write constraints like (a ~ F b). Oops -- it results in recording a wanted constraint (a ~ b). From david at haskell.foundation Sat Jan 21 07:04:15 2023 From: david at haskell.foundation (David Christiansen) Date: Sat, 21 Jan 2023 08:04:15 +0100 Subject: [Haskell-cafe] Anyone working on improving HPC In-Reply-To: References: Message-ID: Hi Ivan, On Fri, Jan 20, 2023 at 4:45 PM Ivan Perez wrote: > A while back there were a few exchanges about the state of HPC and I > remember reading that someone was interested in pushing a bit for improving > the tool and the reports generated. > > Does anyone know if that's happening and who is working on that? > > I forgot where I saw it and I can't find it. It could have been > haskell-cafe, discord, chat, idk. > They've been coordinating in #haskell-program-coverage in the HF's Slack instance. /David -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.fmp.esteves at gmail.com Sat Jan 21 13:28:19 2023 From: alexandre.fmp.esteves at gmail.com (Alexandre Esteves) Date: Sat, 21 Jan 2023 13:28:19 +0000 Subject: [Haskell-cafe] Everything you never wanted to know about Applicative laws and more Message-ID: I've spent some time recently going down this particular rabbit hole. The original motivation was replacing the current formulation of Applicative laws with the Monoidal-ish one, but one thing led to the other and I ended up making a post about the various sets of laws and related free theorems: https://github.com/alexfmpe/semantic-satiation/blob/main/src/Posts/001-applicative-laws.md -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Sat Jan 21 15:46:16 2023 From: qdunkan at gmail.com (Evan Laforge) Date: Sat, 21 Jan 2023 23:46:16 +0800 Subject: [Haskell-cafe] Anyone working on improving HPC In-Reply-To: References: Message-ID: Do they have an issue tracker for ideas? A trivial but somehow still very annoying thing about HPC over the years is how it hard crashes ghci if tix files are out of date, and there's (apparently) no way to disable writing tix files to make the crashes stop, not even HPCTIXFILE=/dev/null. On Sat, Jan 21, 2023 at 3:04 PM David Christiansen via Haskell-Cafe wrote: > > Hi Ivan, > > On Fri, Jan 20, 2023 at 4:45 PM Ivan Perez wrote: >> >> A while back there were a few exchanges about the state of HPC and I remember reading that someone was interested in pushing a bit for improving the tool and the reports generated. >> >> Does anyone know if that's happening and who is working on that? >> >> I forgot where I saw it and I can't find it. It could have been haskell-cafe, discord, chat, idk. > > > They've been coordinating in #haskell-program-coverage in the HF's Slack instance. > > /David > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat Jan 21 16:05:05 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 21 Jan 2023 16:05:05 +0000 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> Message-ID: I can't bind unlifted values at the top level: foo = (##) Top-level bindings for unlifted types aren't allowed: foo = (##) I can understand why I shouldn't be able to bind unlifted *expressions* at the top level foo = complicatedExpression Perhaps complicatedExpression doesn't terminate! But why can't I bind _values_, i.e. things that are already evaluated? Given that (##) and proxy# already exist at the top-level it seems reasonable that I should be allowed to define my own! Tom From ben at smart-cactus.org Sat Jan 21 19:00:47 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 21 Jan 2023 14:00:47 -0500 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> Message-ID: <87bkmrsog5.fsf@smart-cactus.org> Tom Ellis writes: > I can't bind unlifted values at the top level: > > foo = (##) > > Top-level bindings for unlifted types aren't allowed: foo = (##) > > I can understand why I shouldn't be able to bind unlifted > *expressions* at the top level > > foo = complicatedExpression > > Perhaps complicatedExpression doesn't terminate! But why can't I bind > _values_, i.e. things that are already evaluated? Given that (##) and > proxy# already exist at the top-level it seems reasonable that I > should be allowed to define my own! > There are a few things going on here. The case you give here is not just unlifted but also unboxed (namely, being an unboxed tuple). It's hard to see how top-level binding of unboxed values would work operationally (e.g. how is the garbage collector to know how to trace this object, given that unboxed objects have no object header?). However, I suspect you do have a point when it comes to unlifted data constructors. I think it would be fine to allow an application of a data constructor of an unlifted type on the top-level: type UMaybe :: Type -> UnliftedType data UMaybe a = UNothing | UJust a x :: UMaybe Int x = UJust 42 Perhaps you could open a ticket for this? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From david.feuer at gmail.com Sat Jan 21 19:10:33 2023 From: david.feuer at gmail.com (David Feuer) Date: Sat, 21 Jan 2023 14:10:33 -0500 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: <87bkmrsog5.fsf@smart-cactus.org> References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> Message-ID: Unboxed things that don't contain pointers probably don't need to be garbage collected, right? On Sat, Jan 21, 2023, 2:01 PM Ben Gamari wrote: > Tom Ellis writes: > > > I can't bind unlifted values at the top level: > > > > foo = (##) > > > > Top-level bindings for unlifted types aren't allowed: foo = (##) > > > > I can understand why I shouldn't be able to bind unlifted > > *expressions* at the top level > > > > foo = complicatedExpression > > > > Perhaps complicatedExpression doesn't terminate! But why can't I bind > > _values_, i.e. things that are already evaluated? Given that (##) and > > proxy# already exist at the top-level it seems reasonable that I > > should be allowed to define my own! > > > There are a few things going on here. The case you give here is not just > unlifted but also unboxed (namely, being an unboxed tuple). It's hard to > see how top-level binding of unboxed values would work operationally > (e.g. how is the garbage collector to know how to trace this object, > given that unboxed objects have no object header?). > > However, I suspect you do have a point when it comes to unlifted data > constructors. I think it would be fine to allow an application of a > data constructor of an unlifted type on the top-level: > > type UMaybe :: Type -> UnliftedType > data UMaybe a = UNothing | UJust a > > x :: UMaybe Int > x = UJust 42 > > Perhaps you could open a ticket for this? > > Cheers, > > - Ben > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.redelings at gmail.com Sat Jan 21 19:11:22 2023 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Sat, 21 Jan 2023 14:11:22 -0500 Subject: [Haskell-cafe] Foldable intercalate for Data.Text? Message-ID: <941468d4-0c8b-8551-fb35-56a921078eac@gmail.com> Hi, I was looking at intercalate in Data.Text, and I see that the signature is     Text -> [Text] -> Text. I'm curious why this isn't (say)     Foldable f => Text -> f Text -> Text Perhaps because this would be harder to optimize? -BenRI From jaro.reinders at gmail.com Sat Jan 21 21:52:33 2023 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Sat, 21 Jan 2023 22:52:33 +0100 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: <87bkmrsog5.fsf@smart-cactus.org> References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> Message-ID: On 21-01-2023 20:00, Ben Gamari wrote: > However, I suspect you do have a point when it comes to unlifted data > constructors. I think it would be fine to allow an application of a > data constructor of an unlifted type on the top-level: > > type UMaybe :: Type -> UnliftedType > data UMaybe a = UNothing | UJust a > > x :: UMaybe Int > x = UJust 42 > > Perhaps you could open a ticket for this? This ticket seems related: #17521 Consider top-level unlifted bindings [1]. Or do you think it needs a separate ticket? Cheers, Jaro [1] https://gitlab.haskell.org/ghc/ghc/-/issues/17521 From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat Jan 21 22:06:13 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 21 Jan 2023 22:06:13 +0000 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> Message-ID: On Sat, Jan 21, 2023 at 10:52:33PM +0100, Jaro Reinders wrote: > On 21-01-2023 20:00, Ben Gamari wrote: > > However, I suspect you do have a point when it comes to unlifted data > > constructors. I think it would be fine to allow an application of a > > data constructor of an unlifted type on the top-level: > > > > type UMaybe :: Type -> UnliftedType > > data UMaybe a = UNothing | UJust a > > > > x :: UMaybe Int > > x = UJust 42 > > > > Perhaps you could open a ticket for this? > > This ticket seems related: #17521 Consider top-level unlifted bindings [1]. > > Or do you think it needs a separate ticket? Thanks Jaro. That ticket contains the observation "there are other cases where unlifted types are desireable at the top-level (e.g. saturated data constructor applications). In principle it would be fairly straightforward to incorporate a validity check that admits top-level constructor applications which rejecting function applications if we wanted." So I think that ticket subsumes my question, and filing another one would be redundant. Tom From ietf-dane at dukhovni.org Sun Jan 22 00:49:15 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 21 Jan 2023 19:49:15 -0500 Subject: [Haskell-cafe] Foldable intercalate for Data.Text? In-Reply-To: <941468d4-0c8b-8551-fb35-56a921078eac@gmail.com> References: <941468d4-0c8b-8551-fb35-56a921078eac@gmail.com> Message-ID: On Sat, Jan 21, 2023 at 02:11:22PM -0500, Benjamin Redelings wrote: > I was looking at intercalate in Data.Text, and I see that the signature is > >     Text -> [Text] -> Text. > > I'm curious why this isn't (say) > >     Foldable f => Text -> f Text -> Text > > Perhaps because this would be harder to optimize? I rather think it is simply a direct analogue of `intercalate` for Strings (i.e. Lists). The natural API for folding containers to Text is Text builders: import Data.Text.Lazy.Builder buildCalate :: Foldable f => (a -> Builder) -> Builder -> f a -> Builder buildCalate f sep1 = snd . foldr go (mempty, mempty) where go e (sep, r) = (sep1, f e <> sep <> r) -- Viktor. From ietf-dane at dukhovni.org Sun Jan 22 03:34:44 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 21 Jan 2023 22:34:44 -0500 Subject: [Haskell-cafe] Foldable intercalate for Data.Text? In-Reply-To: References: <941468d4-0c8b-8551-fb35-56a921078eac@gmail.com> Message-ID: On Sat, Jan 21, 2023 at 07:49:15PM -0500, Viktor Dukhovni wrote: > I rather think it is simply a direct analogue of `intercalate` for > Strings (i.e. Lists). The natural API for folding containers to Text is > Text builders: > > import Data.Text.Lazy.Builder > > buildCalate :: Foldable f > => (a -> Builder) > -> Builder > -> f a > -> Builder > buildCalate f sep1 = snd . foldr go (mempty, mempty) > where > go e (sep, r) = (sep1, f e <> sep <> r) But the above was hastily written, and came out too strict in the tail, the correct form is: buildCalate :: Foldable f => (a -> Builder) -> Builder -> f a -> Builder buildCalate f sep = snd . foldr go (mempty, mempty) where go x ~(s, r) = (sep, f x <> s <> r) we need to obtain the next separator without forcing the rest of the fold. -- Viktor. From ben at smart-cactus.org Sun Jan 22 06:10:37 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 22 Jan 2023 01:10:37 -0500 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> Message-ID: <32CE0645-F3C8-4E1A-8240-137949DCBDC6@smart-cactus.org> Indeed that is the ticket. There is one wrinkle that I should have mentioned earlier: not even all data constructor applications are admissible at the top level. In particular, constructors with strict fields may require computation to construct. The validity check would need to account for this, either by rejecting such constructors altogether or by having some of syntactic WHNF check. Cheers, - Ben On January 21, 2023 5:06:13 PM EST, Tom Ellis wrote: >On Sat, Jan 21, 2023 at 10:52:33PM +0100, Jaro Reinders wrote: >> On 21-01-2023 20:00, Ben Gamari wrote: >> > However, I suspect you do have a point when it comes to unlifted data >> > constructors. I think it would be fine to allow an application of a >> > data constructor of an unlifted type on the top-level: >> > >> > type UMaybe :: Type -> UnliftedType >> > data UMaybe a = UNothing | UJust a >> > >> > x :: UMaybe Int >> > x = UJust 42 >> > >> > Perhaps you could open a ticket for this? >> >> This ticket seems related: #17521 Consider top-level unlifted bindings [1]. >> >> Or do you think it needs a separate ticket? > >Thanks Jaro. That ticket contains the observation > >"there are other cases where unlifted types are desireable at the > top-level (e.g. saturated data constructor applications). In > principle it would be fairly straightforward to incorporate a > validity check that admits top-level constructor applications which > rejecting function applications if we wanted." > >So I think that ticket subsumes my question, and filing another one >would be redundant. > >Tom >_______________________________________________ >Haskell-Cafe mailing list >To (un)subscribe, modify options or view archives go to: >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Jan 22 06:12:36 2023 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Jan 2023 01:12:36 -0500 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: <32CE0645-F3C8-4E1A-8240-137949DCBDC6@smart-cactus.org> References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> <32CE0645-F3C8-4E1A-8240-137949DCBDC6@smart-cactus.org> Message-ID: That's what ML calls the "value restriction", right? On Sun, Jan 22, 2023, 1:11 AM Ben Gamari wrote: > Indeed that is the ticket. > > There is one wrinkle that I should have mentioned earlier: not even all > data constructor applications are admissible at the top level. In > particular, constructors with strict fields may require computation to > construct. The validity check would need to account for this, either by > rejecting such constructors altogether or by having some of syntactic WHNF > check. > > Cheers, > > - Ben > > On January 21, 2023 5:06:13 PM EST, Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: >> >> On Sat, Jan 21, 2023 at 10:52:33PM +0100, Jaro Reinders wrote: >> >>> On 21-01-2023 20:00, Ben Gamari wrote: >>> >>>> However, I suspect you do have a point when it comes to unlifted data >>>> constructors. I think it would be fine to allow an application of a >>>> data constructor of an unlifted type on the top-level: >>>> >>>> type UMaybe :: Type -> UnliftedType >>>> data UMaybe a = UNothing | UJust a >>>> >>>> x :: UMaybe Int >>>> x = UJust 42 >>>> >>>> Perhaps you could open a ticket for this? >>>> >>> >>> This ticket seems related: #17521 Consider top-level unlifted bindings [1]. >>> >>> Or do you think it needs a separate ticket? >>> >> >> Thanks Jaro. That ticket contains the observation >> >> "there are other cases where unlifted types are desireable at the >> top-level (e.g. saturated data constructor applications). In >> principle it would be fairly straightforward to incorporate a >> validity check that admits top-level constructor applications which >> rejecting function applications if we wanted." >> >> So I think that ticket subsumes my question, and filing another one >> would be redundant. >> >> Tom >> ------------------------------ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Jan 22 08:55:42 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 22 Jan 2023 08:55:42 +0000 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> <32CE0645-F3C8-4E1A-8240-137949DCBDC6@smart-cactus.org> Message-ID: I think so, and that's also why I said "value" (versus "expression") in my original message. On Sun, Jan 22, 2023 at 01:12:36AM -0500, David Feuer wrote: > That's what ML calls the "value restriction", right? > > On Sun, Jan 22, 2023, 1:11 AM Ben Gamari wrote: > > > Indeed that is the ticket. > > > > There is one wrinkle that I should have mentioned earlier: not even all > > data constructor applications are admissible at the top level. In > > particular, constructors with strict fields may require computation to > > construct. The validity check would need to account for this, either by > > rejecting such constructors altogether or by having some of syntactic WHNF > > check. > > > > On January 21, 2023 5:06:13 PM EST, Tom Ellis wrote: > >> > >> On Sat, Jan 21, 2023 at 10:52:33PM +0100, Jaro Reinders wrote: > >> > >>> On 21-01-2023 20:00, Ben Gamari wrote: > >>> > >>>> However, I suspect you do have a point when it comes to unlifted data > >>>> constructors. I think it would be fine to allow an application of a > >>>> data constructor of an unlifted type on the top-level: > >>>> > >>>> type UMaybe :: Type -> UnliftedType > >>>> data UMaybe a = UNothing | UJust a > >>>> > >>>> x :: UMaybe Int > >>>> x = UJust 42 > >>>> > >>>> Perhaps you could open a ticket for this? > >>>> > >>> > >>> This ticket seems related: #17521 Consider top-level unlifted bindings [1]. > >>> > >>> Or do you think it needs a separate ticket? > >>> > >> > >> Thanks Jaro. That ticket contains the observation > >> > >> "there are other cases where unlifted types are desireable at the > >> top-level (e.g. saturated data constructor applications). In > >> principle it would be fairly straightforward to incorporate a > >> validity check that admits top-level constructor applications which > >> rejecting function applications if we wanted." > >> > >> So I think that ticket subsumes my question, and filing another one > >> would be redundant. From lemming at henning-thielemann.de Sun Jan 22 21:16:51 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 22 Jan 2023 22:16:51 +0100 (CET) Subject: [Haskell-cafe] Type constraint rewrite rules Message-ID: <3e87de6e-1566-b9b7-7e60-6d7881d4ccac@henning-thielemann.de> Has anyone thought about rewrite rules for type constraints as light-weight alternative to type-checker plugins? Rewrite rules could be n + 'Zero -> n Back (Forth a) -> a for closed type families Back and Forth, where Back is the inverse of Forth Ideally the programmer would also provide a correctness proof for the proposed rewrite, e.g. with a function that generates a data BackForthProof a = (Back (Forth a) ~ a) => BackForthProof From goemansrowan at gmail.com Sun Jan 22 21:31:50 2023 From: goemansrowan at gmail.com (rowan goemans) Date: Sun, 22 Jan 2023 22:31:50 +0100 Subject: [Haskell-cafe] Type constraint rewrite rules In-Reply-To: <3e87de6e-1566-b9b7-7e60-6d7881d4ccac@henning-thielemann.de> References: <3e87de6e-1566-b9b7-7e60-6d7881d4ccac@henning-thielemann.de> Message-ID: I haven't used it but something like that exists https://github.com/gelisam/typelevel-rewrite-rules Rowan Goemans On 1/22/23 22:16, Henning Thielemann wrote: > > Has anyone thought about rewrite rules for type constraints as > light-weight alternative to type-checker plugins? > > Rewrite rules could be > >   n + 'Zero -> n > >   Back (Forth a) -> a >      for closed type families Back and Forth, where Back is the > inverse of Forth > > > Ideally the programmer would also provide a correctness proof for the > proposed rewrite, e.g. with a function that generates a > > data BackForthProof a = (Back (Forth a) ~ a) => BackForthProof > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From anthony.d.clayden at gmail.com Mon Jan 23 02:59:53 2023 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Mon, 23 Jan 2023 15:59:53 +1300 Subject: [Haskell-cafe] Type constraint rewrite rules Message-ID: > ... rewrite rules for type constraints ... That's what FunDeps are, with the advantage you can stipulate multiple/multi-directional rewrites. (With a bit of effort you can support three FunDeps for `Nat` Plus.) The more I think about it, the more it seems type-land 'solving' is not the same job as term-land 'evaluating'; and Type Families are the wrong tool for the job. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jan 23 08:23:01 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 23 Jan 2023 09:23:01 +0100 (CET) Subject: [Haskell-cafe] Type constraint rewrite rules In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023, Anthony Clayden wrote: > > ... rewrite rules for type constraints ... > That's what FunDeps are, with the advantage you can stipulate > multiple/multi-directional rewrites. How would you simplify Forth (Back a) to 'a' automatically with FunDeps? I could define class ForthBack a b | a -> b, b -> a where but then I would have constraint ForthBack a b and it does not go away. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 23 13:56:41 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 23 Jan 2023 13:56:41 +0000 Subject: [Haskell-cafe] Inscrutable error message from PolyKinds (should it be in GHC202X?) Message-ID: I love the idea of GHC2021, but I've just discovered that PolyKinds, which is part of it, leads to inscrutable error messages. Firstly, a scrutable error message, without PolyKinds: {-# LANGUAGE GHC2021 #-} {-# LANGUAGE NoPolyKinds #-} -- Error: • No instance for (Foldable t) arising from a use of -- ‘length’ foo :: t a -> Int foo = length Good. I know exactly how to fix that. Now the inscrutable message: {-# LANGUAGE GHC2021 #-} -- • Couldn't match kind ‘k’ with ‘*’ -- When matching types -- t0 :: * -> * -- t :: k -> * -- Expected: t a -> Int -- Actual: t0 a0 -> Int -- ‘k’ is a rigid type variable bound by -- the type signature for: -- foo :: forall {k} (t :: k -> *) (a :: k). t a -> Int -- at /tmp/bar.hs:3:1-17 -- • In the expression: length -- In an equation for ‘foo’: foo = length -- • Relevant bindings include -- foo :: t a -> Int (bound at /tmp/bar.hs:4:1) foo :: t a -> Int foo = length What? Non-expert users will experience much puzzlement. (PolyKinds tries to generalise the kind of `a` and fails, because the use of `length` restricts it to `Type`.) Should PolyKinds really be in GHC202X? Tom From J.Hage at uu.nl Mon Jan 23 14:03:52 2023 From: J.Hage at uu.nl (Hage, J. (Jurriaan)) Date: Mon, 23 Jan 2023 14:03:52 +0000 Subject: [Haskell-cafe] Inscrutable error message from PolyKinds (should it be in GHC202X?) In-Reply-To: References: Message-ID: <10EA8FC2-FECD-4C36-87AA-D5414CCDFC68@uu.nl> Thanks for this program, Tom. I’d be happy to hire a PhD student in Edinburgh, at Heriot-Watt University on improving this. Best, Jur > On 23 Jan 2023, at 13:56, Tom Ellis wrote: > > I love the idea of GHC2021, but I've just discovered that PolyKinds, > which is part of it, leads to inscrutable error messages. Firstly, a > scrutable error message, without PolyKinds: > > {-# LANGUAGE GHC2021 #-} > {-# LANGUAGE NoPolyKinds #-} > > -- Error: • No instance for (Foldable t) arising from a use of > -- ‘length’ > foo :: t a -> Int > foo = length > > Good. I know exactly how to fix that. Now the inscrutable message: > > {-# LANGUAGE GHC2021 #-} > > -- • Couldn't match kind ‘k’ with ‘*’ > -- When matching types > -- t0 :: * -> * > -- t :: k -> * > -- Expected: t a -> Int > -- Actual: t0 a0 -> Int > -- ‘k’ is a rigid type variable bound by > -- the type signature for: > -- foo :: forall {k} (t :: k -> *) (a :: k). t a -> Int > -- at /tmp/bar.hs:3:1-17 > -- • In the expression: length > -- In an equation for ‘foo’: foo = length > -- • Relevant bindings include > -- foo :: t a -> Int (bound at /tmp/bar.hs:4:1) > foo :: t a -> Int > foo = length > > What? Non-expert users will experience much puzzlement. > > (PolyKinds tries to generalise the kind of `a` and fails, because the > use of `length` restricts it to `Type`.) > > Should PolyKinds really be in GHC202X? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jaro.reinders at gmail.com Mon Jan 23 14:05:52 2023 From: jaro.reinders at gmail.com (J. Reinders) Date: Mon, 23 Jan 2023 15:05:52 +0100 Subject: [Haskell-cafe] Inscrutable error message from PolyKinds (should it be in GHC202X?) In-Reply-To: References: Message-ID: <55A40B12-8713-45F9-9E47-38F76F2D50F6@gmail.com> More examples of GHC2021 inclusion of PolyKinds confusing people: * https://discourse.haskell.org/t/different-typeable-constraints-behaviour-in-ghc2021-haskell2010/4606?u=jaror * https://stackoverflow.com/q/72329476/15207568 Sometimes it even causes errors where there were none before. Jaro > On 23 Jan 2023, at 14:56, Tom Ellis wrote: > > I love the idea of GHC2021, but I've just discovered that PolyKinds, > which is part of it, leads to inscrutable error messages. Firstly, a > scrutable error message, without PolyKinds: > > {-# LANGUAGE GHC2021 #-} > {-# LANGUAGE NoPolyKinds #-} > > -- Error: • No instance for (Foldable t) arising from a use of > -- ‘length’ > foo :: t a -> Int > foo = length > > Good. I know exactly how to fix that. Now the inscrutable message: > > {-# LANGUAGE GHC2021 #-} > > -- • Couldn't match kind ‘k’ with ‘*’ > -- When matching types > -- t0 :: * -> * > -- t :: k -> * > -- Expected: t a -> Int > -- Actual: t0 a0 -> Int > -- ‘k’ is a rigid type variable bound by > -- the type signature for: > -- foo :: forall {k} (t :: k -> *) (a :: k). t a -> Int > -- at /tmp/bar.hs:3:1-17 > -- • In the expression: length > -- In an equation for ‘foo’: foo = length > -- • Relevant bindings include > -- foo :: t a -> Int (bound at /tmp/bar.hs:4:1) > foo :: t a -> Int > foo = length > > What? Non-expert users will experience much puzzlement. > > (PolyKinds tries to generalise the kind of `a` and fails, because the > use of `length` restricts it to `Type`.) > > Should PolyKinds really be in GHC202X? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 23 14:18:22 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 23 Jan 2023 14:18:22 +0000 Subject: [Haskell-cafe] Inscrutable error message from PolyKinds (should it be in GHC202X?) In-Reply-To: <55A40B12-8713-45F9-9E47-38F76F2D50F6@gmail.com> References: <55A40B12-8713-45F9-9E47-38F76F2D50F6@gmail.com> Message-ID: On Mon, Jan 23, 2023 at 03:05:52PM +0100, J. Reinders wrote: > More examples of GHC2021 inclusion of PolyKinds confusing people: > > * https://discourse.haskell.org/t/different-typeable-constraints-behaviour-in-ghc2021-haskell2010/4606?u=jaror > * https://stackoverflow.com/q/72329476/15207568 > > Sometimes it even causes errors where there were none before. Great evidence! Thanks for linking it. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Jan 23 19:11:36 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 23 Jan 2023 19:11:36 +0000 Subject: [Haskell-cafe] Inscrutable error message from PolyKinds (should it be in GHC202X?) In-Reply-To: References: <55A40B12-8713-45F9-9E47-38F76F2D50F6@gmail.com> Message-ID: On Mon, Jan 23, 2023 at 02:18:22PM +0000, Tom Ellis wrote: > On Mon, Jan 23, 2023 at 03:05:52PM +0100, J. Reinders wrote: > > More examples of GHC2021 inclusion of PolyKinds confusing people: > > > > * https://discourse.haskell.org/t/different-typeable-constraints-behaviour-in-ghc2021-haskell2010/4606?u=jaror > > * https://stackoverflow.com/q/72329476/15207568 > > > > Sometimes it even causes errors where there were none before. > > Great evidence! Thanks for linking it. A related discussion amongst the GHC steering committee: https://mail.haskell.org/pipermail/ghc-steering-committee/2022-July/002812.html From alexey.skladnoy at gmail.com Tue Jan 24 13:21:36 2023 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Tue, 24 Jan 2023 16:21:36 +0300 Subject: [Haskell-cafe] Benchmarking using instruction counting Message-ID: <968fc642-ecab-875e-9005-0b88ba5b3e0f@gmail.com> Hello! I want to announce new benchmarking framework tasty-papi[1,2] Unlike criterion, gauge or tasty-bench is uses instruction counting instead of time measurements. It should be affected by OS scheduler much less so it should be possible to run benchmarks on CI. Although not on github CI (not enough permissions) For measurements papi[3] is used. So all hardware and OS limitations are inherited from there. At least it works on linux Here is example output: > 6: OK (0.02s) > ALLOC=528 TOT_INS=3609 TOT_CYC=4981 BR_INS=907 BR_MSP=58 > 7: OK > ALLOC=864 TOT_INS=5518 TOT_CYC=5138 BR_INS=1378 BR_MSP=50 > 8: OK > ALLOC=1408 TOT_INS=8614 TOT_CYC=6515 BR_INS=2142 BR_MSP=63 For each benchmark we measure number of allocated bytes, number of instructions and cycles spent as well as number of branching instructions and branch mispredictions. Counter set could be adjusted using command line flags. This library hasn't seen much real world use. So treat measurement with care. [1] https://hackage.haskell.org/package/tasty-papi [2] https://github.com/Shimuuar/tasty-papi [3] https://icl.utk.edu/papi/ - Alexey From david at haskell.foundation Wed Jan 25 07:31:28 2023 From: david at haskell.foundation (David Christiansen) Date: Wed, 25 Jan 2023 08:31:28 +0100 Subject: [Haskell-cafe] GHC Nightlies: how would you use them? Message-ID: Dear all, I'm currently helping to assemble a set of use cases that a more convenient means of accessing GHC nightly builds would support. More details are available here: https://discourse.haskell.org/t/ghc-nightlies-how-would-you-use-them/5655 Please feel free to provide feedback on that thread or via email - I'll assemble it into a final report when the discussion seems to have died down. All the best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Wed Jan 25 13:30:14 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 25 Jan 2023 15:30:14 +0200 Subject: [Haskell-cafe] Benchmarking using instruction counting In-Reply-To: <968fc642-ecab-875e-9005-0b88ba5b3e0f@gmail.com> References: <968fc642-ecab-875e-9005-0b88ba5b3e0f@gmail.com> Message-ID: <96cee11b-0676-9825-be79-53512ee7cff5@iki.fi> Nice. Fun coincidence: I have working on (very simple) perf_event_open bindings and did experiment with a fork of tasty-bench in https://github.com/phadej/libperf perf_event_open is a Linux only syscall, and is relatively easy to use directly. - Oleg On 24.1.2023 15.21, Alexey Khudyakov wrote: > Hello! > > I want to announce new benchmarking framework tasty-papi[1,2] > Unlike criterion, gauge or tasty-bench is uses instruction > counting instead of time measurements. It should be affected > by OS scheduler much less so it should be possible to run > benchmarks on CI. Although not on github CI (not enough > permissions) > > For measurements papi[3] is used. So all hardware and OS > limitations are inherited from there. At least it works on linux > Here is example output: > > > 6:                OK (0.02s) > >  ALLOC=528  TOT_INS=3609  TOT_CYC=4981  BR_INS=907  BR_MSP=58 > > 7:                OK > >  ALLOC=864  TOT_INS=5518  TOT_CYC=5138  BR_INS=1378 BR_MSP=50 > > 8:                OK > >  ALLOC=1408 TOT_INS=8614  TOT_CYC=6515  BR_INS=2142 BR_MSP=63 > > For each benchmark we measure number of allocated bytes, number of > instructions and cycles spent as well as number of branching > instructions and branch mispredictions. Counter set could be adjusted > using command line flags. > > This library hasn't seen much real world use. So treat measurement > with care. > > [1] https://hackage.haskell.org/package/tasty-papi > [2] https://github.com/Shimuuar/tasty-papi > [3] https://icl.utk.edu/papi/ > >  - Alexey > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From kazu at iij.ad.jp Thu Jan 26 00:05:40 2023 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 26 Jan 2023 09:05:40 +0900 (JST) Subject: [Haskell-cafe] incomplete-uni-patterns Message-ID: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Hello, The recent GHC added incomplete-uni-patterns to the -Wall option. So, we have a waning with the following code: let [addr,port] = args To avoid this, I changed the code to: let addr = head args port = head $ tail args In my opinion, this seems Lisp rather than Haskell. Also, I need to avoid: let Just val = mval Rahter, I use: let val = fromJust mval This is annoying to me. How do you get along with incomplete-uni-patterns? I would like to know the best current practice. --Kazu From jclites at mac.com Thu Jan 26 00:29:08 2023 From: jclites at mac.com (Jeff Clites) Date: Wed, 25 Jan 2023 16:29:08 -0800 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: <039AF0C5-0B1B-4349-8C27-FF16CE2BC5B4@mac.com> Does this suppress the warning?: let ~[addr,port] = args and let ~(Just val) = mval Jeff > On Jan 25, 2023, at 4:05 PM, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > > Hello, > > The recent GHC added incomplete-uni-patterns to the -Wall option. > So, we have a waning with the following code: > > let [addr,port] = args > > To avoid this, I changed the code to: > > let addr = head args > port = head $ tail args > > In my opinion, this seems Lisp rather than Haskell. > > Also, I need to avoid: > > let Just val = mval > > Rahter, I use: > > let val = fromJust mval > > This is annoying to me. > > How do you get along with incomplete-uni-patterns? > I would like to know the best current practice. > > --Kazu > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ietf-dane at dukhovni.org Thu Jan 26 00:40:27 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Jan 2023 19:40:27 -0500 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <039AF0C5-0B1B-4349-8C27-FF16CE2BC5B4@mac.com> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <039AF0C5-0B1B-4349-8C27-FF16CE2BC5B4@mac.com> Message-ID: On Wed, Jan 25, 2023 at 04:29:08PM -0800, Jeff Clites via Haskell-Cafe wrote: > Does this suppress the warning?: > > let ~[addr,port] = args > > and > > let ~(Just val) = mval I would expect that, and indeed: $ ghci -Wall GHCi, version 9.4.4: https://www.haskell.org/ghc/ :? for help λ> let ~[a,b] = [1,2] :1:5: warning: [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns of type ‘[a]’ not matched: [] [_] (_:_:_:_) λ> -- Viktor. From lemming at henning-thielemann.de Thu Jan 26 01:06:00 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 26 Jan 2023 02:06:00 +0100 (CET) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: On Thu, 26 Jan 2023, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > The recent GHC added incomplete-uni-patterns to the -Wall option. > So, we have a waning with the following code: > > let [addr,port] = args > > To avoid this, I changed the code to: > > let addr = head args > port = head $ tail args Both are partial and should be avoided. I have a nestable NonEmpty that lets you use NonEmpty (NonEmpty []) for a list of at least two elements: https://hackage.haskell.org/package/non-empty-0.3.3/docs/Data-NonEmpty.html > In my opinion, this seems Lisp rather than Haskell. > > Also, I need to avoid: > > let Just val = mval > > Rahter, I use: > > let val = fromJust mval > > This is annoying to me. If you are sure that the Maybe is always Just, why use Maybe in the first place? From lists at richarde.dev Thu Jan 26 02:07:32 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 26 Jan 2023 02:07:32 +0000 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> <32CE0645-F3C8-4E1A-8240-137949DCBDC6@smart-cactus.org> Message-ID: <010f0185ebd486b1-affb77de-e096-44e5-8b37-132734e33521-000000@us-east-2.amazonses.com> > On Jan 22, 2023, at 1:12 AM, David Feuer wrote: > > That's what ML calls the "value restriction", right? No, ML's value restriction is unrelated to this conversation. ML's value restriction says that all polymorphic variables (top-level or otherwise) must syntactically be values -- not, say, function calls. The "value-ness" check might end up similar, but the motivations are distinct. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcconnell17704 at yahoo.com Thu Jan 26 02:24:28 2023 From: mmcconnell17704 at yahoo.com (Mark McConnell) Date: Thu, 26 Jan 2023 02:24:28 +0000 (UTC) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: <493089956.1287156.1674699868027@mail.yahoo.com> I feel I should raise the naive question, what if args is wrong? [addr,50,50]  when a user mistyped port 5050 as 50 50 [addr]   when a user was "sure" somebody else's code would insert 5050 as the default What would you like your code to do in those two cases? I have been using Haskell seriously for only about two years, so I am still idealistic about it.  On the other hand, I worked in the software industry for about ten years, and back then my boss would have chewed me out if my Java code had crashed on the input of 50 50. On Wednesday, January 25, 2023 at 07:06:30 PM EST, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: Hello, The recent GHC added incomplete-uni-patterns to the -Wall option. So, we have a waning with the following code:     let [addr,port] = args To avoid this, I changed the code to:     let addr = head args         port = head $ tail args In my opinion, this seems Lisp rather than Haskell. Also, I need to avoid:     let Just val = mval Rahter, I use:     let val = fromJust mval This is annoying to me. How do you get along with incomplete-uni-patterns? I would like to know the best current practice. --Kazu _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Jan 26 02:46:36 2023 From: david.feuer at gmail.com (David Feuer) Date: Wed, 25 Jan 2023 21:46:36 -0500 Subject: [Haskell-cafe] Why can't I bind unlifted values at the top level? In-Reply-To: <010f0185ebd486b1-affb77de-e096-44e5-8b37-132734e33521-000000@us-east-2.amazonses.com> References: <9a97769d-e491-6550-c6d4-419d3977b61f@iki.fi> <87bkmrsog5.fsf@smart-cactus.org> <32CE0645-F3C8-4E1A-8240-137949DCBDC6@smart-cactus.org> <010f0185ebd486b1-affb77de-e096-44e5-8b37-132734e33521-000000@us-east-2.amazonses.com> Message-ID: I meant the valueness check. I know their motivation has to do with type safety (IIRC, it's to avoid what we know in Haskell as unsafeCoerce-via-unsafePerformIO). On Wed, Jan 25, 2023, 9:07 PM Richard Eisenberg wrote: > > > On Jan 22, 2023, at 1:12 AM, David Feuer wrote: > > That's what ML calls the "value restriction", right? > > > No, ML's value restriction is unrelated to this conversation. ML's value > restriction says that all polymorphic variables (top-level or otherwise) > must syntactically be values -- not, say, function calls. The "value-ness" > check might end up similar, but the motivations are distinct. > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Thu Jan 26 03:21:31 2023 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 26 Jan 2023 12:21:31 +0900 (JST) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <493089956.1287156.1674699868027@mail.yahoo.com> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <493089956.1287156.1674699868027@mail.yahoo.com> Message-ID: <20230126.122131.1697064249206644719.kazu@iij.ad.jp> Hi Mark > I feel I should raise the naive question, what if args is wrong? The length of "args" have been checked in advance. I'm sure that the length is 2. --Kazu From kazu at iij.ad.jp Thu Jan 26 03:28:11 2023 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 26 Jan 2023 12:28:11 +0900 (JST) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: <20230126.122811.1415060694334225021.kazu@iij.ad.jp> > If you are sure that the Maybe is always Just, why use Maybe in the > first place? I'm not sure this is a good example but suppose you have a variable which is shared by clients and servers. For clients, this variable is not necessary. So, to set a value, "Nothing" is used. >From the server code, the value is always "Just x" (by configuration or something). Even if this example is not appearing to you, there are a lot of situations of this kind in practical code. --Kazu From ietf-dane at dukhovni.org Thu Jan 26 04:03:23 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Jan 2023 23:03:23 -0500 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: On Thu, Jan 26, 2023 at 09:05:40AM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > Hello, > > The recent GHC added incomplete-uni-patterns to the -Wall option. > So, we have a waning with the following code: > > let [addr,port] = args > > To avoid this, I changed the code to: > > let addr = head args > port = head $ tail args The univeral option type is Maybe, so you leverage that: maybePair :: [a] -> Maybe (a, a) maybePair [a, b] = Just (a, b) maybePair _ = Nothing knownPair :: [a] -> (a, a) knownPair = fromJust . maybePair and then anywhere you need to only match a 2-element list: let (a, b) = knownPair args Or just: {-# OPTIONS_GHC -Wall -Wno-incomplete-uni-patterns #-} let [a, b] knownPair args Perhaps mildly inconvenient at times, but I am inlined to think that overall better than never reporting potential problem patterns. -- Viktor. From david.feuer at gmail.com Thu Jan 26 05:02:34 2023 From: david.feuer at gmail.com (David Feuer) Date: Thu, 26 Jan 2023 00:02:34 -0500 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: It seems to me that instead of working around this, we should add a pragma to suppress the warning at the pattern site. Maybe something like let {-# PARTIAL_MATCH #-} Just a = blah blah That way GHC can see that you noticed the partial match and that you're okay with it. On Wed, Jan 25, 2023, 7:06 PM Kazu Yamamoto (山本和彦) via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Hello, > > The recent GHC added incomplete-uni-patterns to the -Wall option. > So, we have a waning with the following code: > > let [addr,port] = args > > To avoid this, I changed the code to: > > let addr = head args > port = head $ tail args > > In my opinion, this seems Lisp rather than Haskell. > > Also, I need to avoid: > > let Just val = mval > > Rahter, I use: > > let val = fromJust mval > > This is annoying to me. > > How do you get along with incomplete-uni-patterns? > I would like to know the best current practice. > > --Kazu > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Thu Jan 26 05:24:08 2023 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 26 Jan 2023 14:24:08 +0900 (JST) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: <20230126.142408.1531339897722495380.kazu@iij.ad.jp> Hi David, > It seems to me that instead of working around this, we should add a pragma > to suppress the warning at the pattern site. Maybe something like > > let > {-# PARTIAL_MATCH #-} > Just a = blah blah > > That way GHC can see that you noticed the partial match and that you're > okay with it. This sounds lovely to me! --Kazu From jclites at mac.com Thu Jan 26 05:49:25 2023 From: jclites at mac.com (Jeff Clites) Date: Wed, 25 Jan 2023 21:49:25 -0800 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: Message-ID: <3EA5C5EE-2083-405F-B803-E7C7181CA34A@mac.com> That was my thinking with using an explicit lazy pattern match indication: let ~(Just a) = … It seems to me that this shouldn’t warn (though apparently it does), since it’s overly opting in to a non-exhaustive match. Jeff > On Jan 25, 2023, at 9:08 PM, David Feuer wrote: > >  > It seems to me that instead of working around this, we should add a pragma to suppress the warning at the pattern site. Maybe something like > > let > {-# PARTIAL_MATCH #-} > Just a = blah blah > > That way GHC can see that you noticed the partial match and that you're okay with it. > >> On Wed, Jan 25, 2023, 7:06 PM Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: >> Hello, >> >> The recent GHC added incomplete-uni-patterns to the -Wall option. >> So, we have a waning with the following code: >> >> let [addr,port] = args >> >> To avoid this, I changed the code to: >> >> let addr = head args >> port = head $ tail args >> >> In my opinion, this seems Lisp rather than Haskell. >> >> Also, I need to avoid: >> >> let Just val = mval >> >> Rahter, I use: >> >> let val = fromJust mval >> >> This is annoying to me. >> >> How do you get along with incomplete-uni-patterns? >> I would like to know the best current practice. >> >> --Kazu >> >> >> _______________________________________________ >> 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. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Thu Jan 26 08:04:48 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 26 Jan 2023 08:04:48 +0000 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.122131.1697064249206644719.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <493089956.1287156.1674699868027@mail.yahoo.com> <20230126.122131.1697064249206644719.kazu@iij.ad.jp> Message-ID: On Thu, Jan 26, 2023 at 12:21:31PM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > > I feel I should raise the naive question, what if args is wrong? > > The length of "args" have been checked in advance. > I'm sure that the length is 2. Then, at the point you check the args, put them in a pair? From david.feuer at gmail.com Thu Jan 26 08:36:00 2023 From: david.feuer at gmail.com (David Feuer) Date: Thu, 26 Jan 2023 03:36:00 -0500 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <3EA5C5EE-2083-405F-B803-E7C7181CA34A@mac.com> References: <3EA5C5EE-2083-405F-B803-E7C7181CA34A@mac.com> Message-ID: A lazy pattern match isn't opting into partiality. Lazy patterns are often things like tuples. On Thu, Jan 26, 2023, 12:49 AM Jeff Clites via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > That was my thinking with using an explicit lazy pattern match indication: > > let ~(Just a) = … > > It seems to me that this shouldn’t warn (though apparently it does), since > it’s overly opting in to a non-exhaustive match. > > Jeff > > On Jan 25, 2023, at 9:08 PM, David Feuer wrote: > >  > It seems to me that instead of working around this, we should add a pragma > to suppress the warning at the pattern site. Maybe something like > > let > {-# PARTIAL_MATCH #-} > Just a = blah blah > > That way GHC can see that you noticed the partial match and that you're > okay with it. > > On Wed, Jan 25, 2023, 7:06 PM Kazu Yamamoto (山本和彦) via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > >> Hello, >> >> The recent GHC added incomplete-uni-patterns to the -Wall option. >> So, we have a waning with the following code: >> >> let [addr,port] = args >> >> To avoid this, I changed the code to: >> >> let addr = head args >> port = head $ tail args >> >> In my opinion, this seems Lisp rather than Haskell. >> >> Also, I need to avoid: >> >> let Just val = mval >> >> Rahter, I use: >> >> let val = fromJust mval >> >> This is annoying to me. >> >> How do you get along with incomplete-uni-patterns? >> I would like to know the best current practice. >> >> --Kazu >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Jan 26 09:30:47 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 26 Jan 2023 10:30:47 +0100 (CET) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.122131.1697064249206644719.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <493089956.1287156.1674699868027@mail.yahoo.com> <20230126.122131.1697064249206644719.kazu@iij.ad.jp> Message-ID: On Thu, 26 Jan 2023, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: >> I feel I should raise the naive question, what if args is wrong? > > The length of "args" have been checked in advance. > I'm sure that the length is 2. If that is sure, then let the length check return a list type that contains exactly two arguments. With my non-empty package I would e.g. use NonEmpty (NonEmpty Empty). From lemming at henning-thielemann.de Thu Jan 26 09:32:23 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 26 Jan 2023 10:32:23 +0100 (CET) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> Message-ID: <99142229-33fe-ad0-e961-393e63cd1879@henning-thielemann.de> On Thu, 26 Jan 2023, David Feuer wrote: > It seems to me that instead of working around this, we should add a pragma to suppress the warning at > the pattern site. Maybe something like > let >   {-# PARTIAL_MATCH #-} >   Just a = blah blah > > That way GHC can see that you noticed the partial match and that you're okay with it. Not necessary. You can just do: case mayb of Just a -> do real things Nothing -> error "problem arised" From lemming at henning-thielemann.de Thu Jan 26 09:34:31 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 26 Jan 2023 10:34:31 +0100 (CET) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.122811.1415060694334225021.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.122811.1415060694334225021.kazu@iij.ad.jp> Message-ID: <7474b99d-a7b7-a877-a09-b0de6c7df6e5@henning-thielemann.de> On Thu, 26 Jan 2023, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > Even if this example is not appearing to you, there are a lot of > situations of this kind in practical code. I know. Each of this is an occasion to think about more appropriate types, such that only valid values can be represented. From teofilcamarasu at gmail.com Thu Jan 26 10:34:14 2023 From: teofilcamarasu at gmail.com (Teofil Camarasu) Date: Thu, 26 Jan 2023 10:34:14 +0000 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <7474b99d-a7b7-a877-a09-b0de6c7df6e5@henning-thielemann.de> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.122811.1415060694334225021.kazu@iij.ad.jp> <7474b99d-a7b7-a877-a09-b0de6c7df6e5@henning-thielemann.de> Message-ID: Another possibility is to write something like: main = do [addr, port] <- pure args ... This is desugared in terms of `fail` rather than `error`, so it will also do the right thing in the `Maybe` monad. Though of course this only works in do-notation. -- Teo On Thu, 26 Jan 2023, 09:35 Henning Thielemann, < lemming at henning-thielemann.de> wrote: > > On Thu, 26 Jan 2023, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > > > Even if this example is not appearing to you, there are a lot of > > situations of this kind in practical code. > > I know. Each of this is an occasion to think about more appropriate types, > such that only valid values can be > represented._______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.cardwell at extrema.is Thu Jan 26 11:24:28 2023 From: travis.cardwell at extrema.is (Travis Cardwell) Date: Thu, 26 Jan 2023 20:24:28 +0900 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <7474b99d-a7b7-a877-a09-b0de6c7df6e5@henning-thielemann.de> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.122811.1415060694334225021.kazu@iij.ad.jp> <7474b99d-a7b7-a877-a09-b0de6c7df6e5@henning-thielemann.de> Message-ID: On Thu, Jan 26, 2023 at 6:35 PM Henning Thielemann wrote: > Each of this is an occasion to think about more appropriate types, > such that only valid values can be represented. ...and wish for dependent types! From mmcconnell17704 at yahoo.com Thu Jan 26 13:14:14 2023 From: mmcconnell17704 at yahoo.com (Mark McConnell) Date: Thu, 26 Jan 2023 13:14:14 +0000 (UTC) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.142408.1531339897722495380.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> Message-ID: <533942671.446040.1674738854577@mail.yahoo.com> One can also put this at the top: {-# OPTIONS_GHC -Wno-incomplete-uni-patterns #-} On Thursday, January 26, 2023 at 12:24:49 AM EST, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: Hi David, > It seems to me that instead of working around this, we should add a pragma > to suppress the warning at the pattern site. Maybe something like > > let >  {-# PARTIAL_MATCH #-} >  Just a = blah blah > > That way GHC can see that you noticed the partial match and that you're > okay with it. This sounds lovely to me! --Kazu _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskellcafe at dandart.co.uk Thu Jan 26 13:33:30 2023 From: haskellcafe at dandart.co.uk (Dan Dart) Date: Thu, 26 Jan 2023 13:33:30 +0000 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <533942671.446040.1674738854577@mail.yahoo.com> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <533942671.446040.1674738854577@mail.yahoo.com> Message-ID: > {-# OPTIONS_GHC -Wno-incomplete-uni-patterns #-} I feel like that's just avoiding facing the problem. It makes sense though, if you know 100% that there really, really is no other case. But as previous repliers have said, that's probably not a case for partials. If it's both known and partial, you're probably using the wrong datastructure for it. There's a reason many Prelude replacements don't include partial functions, and there's generally a better solution for it in them. And even if you're using base Prelude (which I am 99% of the time), things are only Maybe if they come from somewhere where they possibly could be. So, taking (!?) as an example, if you've statically set a list to contain a value and want it out, and want to avoid using partial functions like (!!) then perhaps static lists were not a good use case for you, is what I think people are getting at. > what if args is wrong? Another solution I use a lot is to match on lists, e.g.: doSomethingWithListOfParameters :: [Text] -> IO () doSomethingWithListOfParameters xs = \case [] -> someActionUsingNoParameters [a] -> someActionUsingOneParameter [a, b] -> someActionUsingTwoParameters _ -> fail "don't know that one, sorry" I have adapted a lot of my code to use these uni patterns rather than avoiding them, as most of the time when this happens, it's not an impossible case for someone to pick the function up somewhere else and call it in the "wrong" way, and I handle it. From markus.l2ll at gmail.com Thu Jan 26 17:12:42 2023 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Thu, 26 Jan 2023 19:12:42 +0200 Subject: [Haskell-cafe] multiline strings editor for emacs Message-ID: Dear Cafe, searched, but this didn't turn up anything -- does there exist a "multiline string editor for emacs" in haskell? I.e something that would pop-out a new buffer to edit the string, and that would be inserted and slash-aligned back into the original file once done? This would be simple enough to implement, perhaps someone has already done it? (And just to be sure: there isn't a built-in multiline quasiquoter in base, right? I know that there are multitudes of packages that implement this, but would just like something that is built in.) Thanks! -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Jan 26 17:26:02 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 26 Jan 2023 12:26:02 -0500 Subject: [Haskell-cafe] multiline strings editor for emacs In-Reply-To: References: Message-ID: Nothing built in, but I think there's a proposal for better multiline string support in the compiler. (Yep: https://github.com/ghc-proposals/ghc-proposals/pull/569) On Thu, Jan 26, 2023 at 12:13 PM Markus Läll wrote: > > Dear Cafe, > > searched, but this didn't turn up anything -- does there exist a "multiline string editor for emacs" in haskell? I.e something that would pop-out a new buffer to edit the string, and that would be inserted and slash-aligned back into the original file once done? This would be simple enough to implement, perhaps someone has already done it? > > (And just to be sure: there isn't a built-in multiline quasiquoter in base, right? I know that there are multitudes of packages that implement this, but would just like something that is built in.) > > > Thanks! > > -- > Markus Läll > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From david.feuer at gmail.com Thu Jan 26 17:46:05 2023 From: david.feuer at gmail.com (David Feuer) Date: Thu, 26 Jan 2023 12:46:05 -0500 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <533942671.446040.1674738854577@mail.yahoo.com> Message-ID: There are occasional situations where the data structure is right but the limitations of Haskell's type system prevent us from proving totality. I've only ever written a couple I'm proud of: 1. Data.Biapplicative.traverseBiaWith 2. Data.Sequence.zipWith and Data.Sequence.chunksOf traverseBiaWith seems to need an "impossible" case to achieve the right semantics for lazy biapplicatives and infinite structures. Code shared by zipWith and chunksOf uses one (relying on the tree annotation invariant) to compute the result incrementally and (therefore) more efficiently. On Thu, Jan 26, 2023, 8:34 AM Dan Dart wrote: > > {-# OPTIONS_GHC -Wno-incomplete-uni-patterns #-} > > I feel like that's just avoiding facing the problem. It makes sense > though, if you know 100% that there really, really is no other case. > But as previous repliers have said, that's probably not a case for > partials. If it's both known and partial, you're probably using the > wrong datastructure for it. There's a reason many Prelude replacements > don't include partial functions, and there's generally a better > solution for it in them. And even if you're using base Prelude (which > I am 99% of the time), things are only Maybe if they come from > somewhere where they possibly could be. > > So, taking (!?) as an example, if you've statically set a list to > contain a value and want it out, and want to avoid using partial > functions like (!!) then perhaps static lists were not a good use case > for you, is what I think people are getting at. > > > what if args is wrong? > > Another solution I use a lot is to match on lists, e.g.: > > doSomethingWithListOfParameters :: [Text] -> IO () > doSomethingWithListOfParameters xs = \case > [] -> someActionUsingNoParameters > [a] -> someActionUsingOneParameter > [a, b] -> someActionUsingTwoParameters > _ -> fail "don't know that one, sorry" > > I have adapted a lot of my code to use these uni patterns rather than > avoiding them, as most of the time when this happens, it's not an > impossible case for someone to pick the function up somewhere else and > call it in the "wrong" way, and I handle it. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Thu Jan 26 18:18:18 2023 From: cdsmith at gmail.com (Chris Smith) Date: Thu, 26 Jan 2023 11:18:18 -0700 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <533942671.446040.1674738854577@mail.yahoo.com> Message-ID: There's a broader class of problems where achieving totality by restricting the type is possible, but the cost-benefit trade-off of forcing everything into the type level comes out in the wrong direction. I ran into an example in https://medium.com/@cdsmithus/pair-programming-with-chatgpt-haskell-1c4490b71da6 (scroll to the end and see final code for Part IV, and the toMatrixVectorForm function), where in the general case I needed polynomial arithmetic, but in certain specific cases (where either one of the two players of the game adopts a pure strategy), I knew that the result would always be a linear expression. It would definitely be possible to annotate the polynomial type with a maximum degree, define higher-kinded arithmetic operations that would correctly propagate that across addition and multiplication, and use a bounded-length list type for variables in a term, all to avoid that one error case in pattern matching. However, it would have been a significant distraction from the problem being solved. On Thu, Jan 26, 2023 at 10:46 AM David Feuer wrote: > There are occasional situations where the data structure is right but the > limitations of Haskell's type system prevent us from proving totality. I've > only ever written a couple I'm proud of: > > 1. Data.Biapplicative.traverseBiaWith > 2. Data.Sequence.zipWith and Data.Sequence.chunksOf > > traverseBiaWith seems to need an "impossible" case to achieve the right > semantics for lazy biapplicatives and infinite structures. Code shared by > zipWith and chunksOf uses one (relying on the tree annotation invariant) to > compute the result incrementally and (therefore) more efficiently. > > On Thu, Jan 26, 2023, 8:34 AM Dan Dart wrote: > >> > {-# OPTIONS_GHC -Wno-incomplete-uni-patterns #-} >> >> I feel like that's just avoiding facing the problem. It makes sense >> though, if you know 100% that there really, really is no other case. >> But as previous repliers have said, that's probably not a case for >> partials. If it's both known and partial, you're probably using the >> wrong datastructure for it. There's a reason many Prelude replacements >> don't include partial functions, and there's generally a better >> solution for it in them. And even if you're using base Prelude (which >> I am 99% of the time), things are only Maybe if they come from >> somewhere where they possibly could be. >> >> So, taking (!?) as an example, if you've statically set a list to >> contain a value and want it out, and want to avoid using partial >> functions like (!!) then perhaps static lists were not a good use case >> for you, is what I think people are getting at. >> >> > what if args is wrong? >> >> Another solution I use a lot is to match on lists, e.g.: >> >> doSomethingWithListOfParameters :: [Text] -> IO () >> doSomethingWithListOfParameters xs = \case >> [] -> someActionUsingNoParameters >> [a] -> someActionUsingOneParameter >> [a, b] -> someActionUsingTwoParameters >> _ -> fail "don't know that one, sorry" >> >> I have adapted a lot of my code to use these uni patterns rather than >> avoiding them, as most of the time when this happens, it's not an >> impossible case for someone to pick the function up somewhere else and >> call it in the "wrong" way, and I handle it. >> _______________________________________________ >> 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. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu Jan 26 20:58:26 2023 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 26 Jan 2023 21:58:26 +0100 Subject: [Haskell-cafe] incomplete-uni-patterns Message-ID: <0125fa1f2e8db371eeee2dc598ef40345ff3951e.camel@aatal-apotheke.de> > From: Tom Ellis > To: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] incomplete-uni-patterns > > On Thu, Jan 26, 2023 at 12:21:31PM +0900, Kazu Yamamoto (山本和彦) via > Haskell-Cafe wrote: > > > I feel I should raise the naive question, what if args is wrong? > > > > The length of "args" have been checked in advance. > > I'm sure that the length is 2. > > Then, at the point you check the args, put them in a pair? That seems indeed the most realistic use case, and a semi-automatic translation by a linter would be cool: ``` if length args >= 2 then let (addr:port:_) = args in ... else complain_about_insufficient_args ``` transforms to ``` case args of (addr:port:_) -> ... _ -> complain_about_insufficient_args ``` Rice's theorem will get in the way though, since no linter may be able to prove in general that the first branch in the if-expression can only be entered if the pattern match within must succeed. The example might still be tractable, but what about more complicated data structures/pattern matches? I agree with Henning, in this case the incomplete-uni-patterns rightfully informs you that you should re-structure your code and help the compiler know what you as the programmer know. That said, I've been using the former style and it's okay to have different opinions about whether it is good style. Personally, I don't care whether the application aborts on start-up with an incomplete pattern error or my own complain_about_insufficient_args failure. It just can't go on. Henning disagrees. Deep within a library, where you can't control the calling context, such a partial pattern match should be avoided, of course. I collected all my dubious handling of unwanted situations in a module that is sprinkled with DEPRECATED pragmas reminding me that there is code to be tidied. For example, failLeft :: MonadFail m => Either String a -> m a failLeft = either fail return {-# DEPRECATED failLeft "this can fail, consider proper error handling" #-} If you are sure that failing is okay at the particular use site, just replace failLeft by an equivalent version without the DEPRECATED pragma. That would be the akin to the proposed {-# PARTIAL_MATCH #-} pragma, but requires you to avoid the incomplete pattern match in the first place and handle the other patterns somehow. Olaf From thomasjakway1 at gmail.com Fri Jan 27 03:02:34 2023 From: thomasjakway1 at gmail.com (Thomas Jakway) Date: Thu, 26 Jan 2023 19:02:34 -0800 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <20230126.142408.1531339897722495380.kazu@iij.ad.jp> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> Message-ID: <0f690448-76cd-5e9b-11de-99d937527cd6@gmail.com> Just a miscellaneous Haskell user, but that also sounds good to me. I definitely support having a way to tell the compiler at the most specific level possible (per line, in this case) that the author is intentionally doing this and not to warn about it. I wrote in scala for years and was always unhappy that for a very long time the designers refused to support [1] ( a scala version of Java's @SuppressWarnings annotation. The suggested hack for about a decade was to use a compiler plugin. ------------------------------------------------------------------------ Unrelated/on the importance of warning about the right things: Thinking about this made me remember that C's switch fall-through-by-default behavior is so bad that you need to tell the compiler you actually want to do that. [2] [3] [1] https://stackoverflow.com/questions/3506370/is-there-an-equivalent-to-suppresswarnings-in-scala [2] https://learn.microsoft.com/en-us/cpp/code-quality/c26819?view=msvc-170 [3] https://en.cppreference.com/w/c/language/attributes/fallthrough On 1/25/23 21:24, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > Hi David, > >> It seems to me that instead of working around this, we should add a pragma >> to suppress the warning at the pattern site. Maybe something like >> >> let >> {-# PARTIAL_MATCH #-} >> Just a = blah blah >> >> That way GHC can see that you noticed the partial match and that you're >> okay with it. > This sounds lovely to me! > > --Kazu > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Fri Jan 27 06:45:22 2023 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Fri, 27 Jan 2023 19:45:22 +1300 Subject: [Haskell-cafe] Type constraint rewrite rules In-Reply-To: References: Message-ID: Thanks Henning, and apologies for the delay in replying. I more had in mind your `n + 'Zero -> n` example. With cunning overlaps you can also achieve `'Zero + n -> n`; and even from result 'Zero improve both arguments to 'Zero. With class ForthBack, a FunDep right-to-left would (maybe) expand `a` to `Forth (Back a)` -- which hardly seems helpful and is anyway not true: `Forth (Forth (Back (Back a)))` would be just as legit. That kind of recursion-depth-sensitive normalisation is possible with FunDeps and overlaps. But I'd need to recharge my Oleg batteries. On Mon, 23 Jan 2023 at 21:23, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 23 Jan 2023, Anthony Clayden wrote: > > > > ... rewrite rules for type constraints ... > > > That's what FunDeps are, with the advantage you can stipulate > > multiple/multi-directional rewrites. > > How would you simplify Forth (Back a) to 'a' automatically with FunDeps? > > I could define > > class ForthBack a b | a -> b, b -> a where > > but then I would have constraint ForthBack a b and it does not go away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Jan 27 09:24:27 2023 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 27 Jan 2023 10:24:27 +0100 (CET) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <0f690448-76cd-5e9b-11de-99d937527cd6@gmail.com> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <0f690448-76cd-5e9b-11de-99d937527cd6@gmail.com> Message-ID: <29e39686-efbb-1e39-7dc9-6dc1294b0e0@henning-thielemann.de> On Thu, 26 Jan 2023, Thomas Jakway wrote: > I definitely support having a way to tell the compiler at the most > specific level possible (per line, in this case) that the author is > intentionally doing this and not to warn about it. I think that an explicit 'error' for unhandled cases perfectly serves that purpose. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Fri Jan 27 10:04:58 2023 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 27 Jan 2023 10:04:58 +0000 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: <29e39686-efbb-1e39-7dc9-6dc1294b0e0@henning-thielemann.de> References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <0f690448-76cd-5e9b-11de-99d937527cd6@gmail.com> <29e39686-efbb-1e39-7dc9-6dc1294b0e0@henning-thielemann.de> Message-ID: On Fri, Jan 27, 2023 at 10:24:27AM +0100, Henning Thielemann wrote: > On Thu, 26 Jan 2023, Thomas Jakway wrote: > > I definitely support having a way to tell the compiler at the most > > specific level possible (per line, in this case) that the author is > > intentionally doing this and not to warn about it. > > I think that an explicit 'error' for unhandled cases perfectly serves that > purpose. Big +1 to everything Henning is saying in this discussion. From haskellcafe at dandart.co.uk Fri Jan 27 11:30:18 2023 From: haskellcafe at dandart.co.uk (Dan Dart) Date: Fri, 27 Jan 2023 11:30:18 +0000 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <0f690448-76cd-5e9b-11de-99d937527cd6@gmail.com> <29e39686-efbb-1e39-7dc9-6dc1294b0e0@henning-thielemann.de> Message-ID: I suppose it's safer than having a "I know what I'm doing, the list is complete really" pragma? From thomasjakway1 at gmail.com Fri Jan 27 21:15:04 2023 From: thomasjakway1 at gmail.com (Thomas Jakway) Date: Fri, 27 Jan 2023 13:15:04 -0800 Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <0f690448-76cd-5e9b-11de-99d937527cd6@gmail.com> <29e39686-efbb-1e39-7dc9-6dc1294b0e0@henning-thielemann.de> Message-ID: --living-dangerously On Fri, Jan 27, 2023, 3:31 AM Dan Dart wrote: > I suppose it's safer than having a "I know what I'm doing, the list is > complete really" pragma? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcconnell17704 at yahoo.com Fri Jan 27 21:19:38 2023 From: mmcconnell17704 at yahoo.com (Mark McConnell) Date: Fri, 27 Jan 2023 21:19:38 +0000 (UTC) Subject: [Haskell-cafe] incomplete-uni-patterns In-Reply-To: References: <20230126.090540.1236635030553390334.kazu@iij.ad.jp> <20230126.142408.1531339897722495380.kazu@iij.ad.jp> <0f690448-76cd-5e9b-11de-99d937527cd6@gmail.com> <29e39686-efbb-1e39-7dc9-6dc1294b0e0@henning-thielemann.de> Message-ID: <1727580746.321400.1674854378869@mail.yahoo.com> In violation of the usual conventions, GHC does not implement --no-living-dangerously because the results cannot be guaranteed. On Friday, January 27, 2023 at 04:15:33 PM EST, Thomas Jakway wrote: --living-dangerously On Fri, Jan 27, 2023, 3:31 AM Dan Dart wrote: I suppose it's safer than having a "I know what I'm doing, the list is complete really" pragma? _______________________________________________ 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. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Fri Jan 27 22:44:59 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Fri, 27 Jan 2023 23:44:59 +0100 Subject: [Haskell-cafe] Munich Haskell Meeting, 2023-01-30 @ 19:30 Message-ID: <87y1pniolw.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, January 30 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/mjxWpyCCGJY7r6uA Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From qdunkan at gmail.com Sun Jan 29 08:47:21 2023 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 29 Jan 2023 16:47:21 +0800 Subject: [Haskell-cafe] multiline strings editor for emacs In-Reply-To: References: Message-ID: I've long used a program to toggle between raw text and haskell string syntax (either wrapped words, unwrapped \-continued, or ["x", "y"] "unlines" style). I use it with vim but it's a plain text filter: https://github.com/elaforge/simple-src-utils It's not very smart but has worked well enough that I haven't bothered to fix the rough bits. On Fri, Jan 27, 2023 at 1:26 AM Brandon Allbery wrote: > > Nothing built in, but I think there's a proposal for better multiline > string support in the compiler. (Yep: > https://github.com/ghc-proposals/ghc-proposals/pull/569) > > On Thu, Jan 26, 2023 at 12:13 PM Markus Läll wrote: > > > > Dear Cafe, > > > > searched, but this didn't turn up anything -- does there exist a "multiline string editor for emacs" in haskell? I.e something that would pop-out a new buffer to edit the string, and that would be inserted and slash-aligned back into the original file once done? This would be simple enough to implement, perhaps someone has already done it? > > > > (And just to be sure: there isn't a built-in multiline quasiquoter in base, right? I know that there are multitudes of packages that implement this, but would just like something that is built in.) > > > > > > Thanks! > > > > -- > > Markus Läll > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tdecacqu at redhat.com Sun Jan 29 16:19:24 2023 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Sun, 29 Jan 2023 16:19:24 +0000 Subject: [Haskell-cafe] Introducing a pure EBML (WebM) parser Message-ID: <87v8kp8gab.tristanC@fedora> Dear Café, I've created a new package to parse the Extensible Binary Meta Language format using the binary library: https://hackage.haskell.org/package/ebml And I just published a motivating example, an audio broadcasting server for WebSocket clients: https://tristancacqueray.github.io/blog/broadcasting-webm Please let me know if you are interested, contributions and bug reports are welcome! Cheers, -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From ben at well-typed.com Mon Jan 30 18:21:32 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 30 Jan 2023 13:21:32 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-alpha2 is now available Message-ID: <87a61zriif.fsf@smart-cactus.org> The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha2. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1-alpha2/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell. - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 will include: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a [migration guide] to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older `glibc` releases (namely 2.27), respectively. Please do give this release a try and open a [ticket] if you see anything amiss. Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1-alpha2/docs/users_guide/9.6.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From a.pelenitsyn at gmail.com Mon Jan 30 22:52:45 2023 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 30 Jan 2023 17:52:45 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-alpha2 is now available In-Reply-To: <87a61zriif.fsf@smart-cactus.org> References: <87a61zriif.fsf@smart-cactus.org> Message-ID: Thanks a lot, Ben and devs, for all the hard work! Would it be possible to mention the JS and WASM backends in the release notes? Is it a simple oversight that there are not there, or you want to wait until a release where they are more mature? -- Best, Artem On Mon, Jan 30, 2023, 1:22 PM Ben Gamari wrote: > > The GHC team is very pleased to announce the availability of GHC > 9.6.1-alpha2. As usual, binaries and source distributions are available > at downloads.haskell.org: > > https://downloads.haskell.org/ghc/9.6.1-alpha2/ > > Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to > WebAssembly and JavaScript. This is an important step towards robust > support for compiling Haskell to the Web, but there are a few caveats to > be aware of in the 9.6 series: > > - Both the Javascript and WebAssembly backends are still at an early > stage of development and are present in this release as a technology > preview > > - Using GHC as a cross-compiler is not as easy as we would like it to > be; in particular, there are challenges related to Template Haskell. > > - GHC is not yet run-time retargetable; a given GHC binary targets > exactly one platform, and both WebAssembly and JavaScript are > considered platforms for this purpose. Cross-compilers must be built > from source by their users > > We hope to lift all of these limitations in future releases. > > Additionally, 9.6.1 will include: > > - Significant latency improvements in the non-moving garbage collector > > - Efficient runtime support for delimited continuations > > - Improvements in compiler error messages > > - Numerous improvements in the compiler's memory usage > > See the [release notes] for a comprehensive accounting of changes in > this release. > > As always, one can find a [migration guide] to aid in transitioning from > older releases on the GHC Wiki. We have also recently started extending > our release process to cover a wider set of Linux distributions. In > particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions > which cover RedHat-derivative and distributions using older `glibc` > releases (namely 2.27), respectively. > > Please do give this release a try and open a [ticket] if you see > anything amiss. > > Cheers, > > - Ben > > > [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ > [migration-guide]: > https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 > [release notes]: > https://downloads.haskell.org/ghc/9.6.1-alpha2/docs/users_guide/9.6.1-notes.html > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Tue Jan 31 08:56:47 2023 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 31 Jan 2023 09:56:47 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-alpha2 is now available In-Reply-To: References: <87a61zriif.fsf@smart-cactus.org> Message-ID: <28b18954-13d2-f420-de4e-30f1f2c8ca2b@haskus.fr> There is an open MR about adding a mention of the JS backend to the release notes: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9828 Sylvain On 30/01/2023 23:52, Artem Pelenitsyn wrote: > Thanks a lot, Ben and devs, for all the hard work! > > Would it be possible to mention the JS and WASM backends in the > release notes? Is it a simple oversight that there are not there, or > you want to wait until a release where they are more mature? > > -- > Best, Artem > > > On Mon, Jan 30, 2023, 1:22 PM Ben Gamari wrote: > > > The GHC team is very pleased to announce the availability of GHC > 9.6.1-alpha2. As usual, binaries and source distributions are > available > at downloads.haskell.org : > > https://downloads.haskell.org/ghc/9.6.1-alpha2/ > > Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to > WebAssembly and JavaScript. This is an important step towards robust > support for compiling Haskell to the Web, but there are a few > caveats to > be aware of in the 9.6 series: > >  - Both the Javascript and WebAssembly backends are still at an early >    stage of development and are present in this release as a > technology >    preview > >  - Using GHC as a cross-compiler is not as easy as we would like it to >    be; in particular, there are challenges related to Template > Haskell. > >  - GHC is not yet run-time retargetable; a given GHC binary targets >    exactly one platform, and both WebAssembly and JavaScript are >    considered platforms for this purpose. Cross-compilers must be > built >    from source by their users > > We hope to lift all of these limitations in future releases. > > Additionally, 9.6.1 will include: > >  - Significant latency improvements in the non-moving garbage > collector > >  - Efficient runtime support for delimited continuations > >  - Improvements in compiler error messages > >  - Numerous improvements in the compiler's memory usage > > See the [release notes] for a comprehensive accounting of changes in > this release. > > As always, one can find a [migration guide] to aid in > transitioning from > older releases on the GHC Wiki. We have also recently started > extending > our release process to cover a wider set of Linux distributions. In > particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions > which cover RedHat-derivative and distributions using older `glibc` > releases (namely 2.27), respectively. > > Please do give this release a try and open a [ticket] if you see > anything amiss. > > Cheers, > > - Ben > > > [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ > [migration-guide]: > https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 > [release notes]: > https://downloads.haskell.org/ghc/9.6.1-alpha2/docs/users_guide/9.6.1-notes.html > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Tue Jan 31 16:36:34 2023 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 31 Jan 2023 17:36:34 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-alpha2 is now available Message-ID: <62dc2e5e13739b8d36652d8592d19ee3a887d42d.camel@aatal-apotheke.de> This may be a naive question and I may be completely misunderstanding what WebAssembly is all about: What can the Haskell developer expect once the WebAssembly and JavaScript backends of GHC have matured? I dream of a commutative square like follows. f x -----> y Haskell source | | |GHC |GHC | | v v b -----> b HTML w GHC would become a functor from (a sub-category of) Hask to a category with one object and a rich hom-set of (serializable) endomorphisms. Cloud Haskell [0] seems to provide a functor of this kind. In detail, for a pure Haskell function between Haskell types x and y, the compiler would be able to map values to a web representation b and compile f to a web representation w :: b -> b. The latter should be embeddable in static HTML [1], so that a client-server architecture is not needed. There are obvious limitations, e.g. when b = JSON and w is a JavaScript function, then x and y may be limited to Generic types. One application of this functor would be a web version of Haskintex [2], where one can ensure that certain elements of a document have a relationship y = f(x) defined by a Haskell function. But unlike Haskintex, the computation would take place not at create-time but at display-time so that a limited amount of interaction is possible. Olaf [0] https://hackage.haskell.org/package/distributed-static [1] According to [3], WebAssembly is currently designed to be fetched, not embedded. This appears to be no fundamental restriction, however, as binary images can also be embedded in static HTML. [2] https://hackage.haskell.org/package/haskintex [3] https://developer.mozilla.org/en-US/docs/WebAssembly/Loading_and_running