From anka.213 at gmail.com Mon Nov 1 03:57:24 2021 From: anka.213 at gmail.com (=?utf-8?Q?Andreas_K=C3=A4llberg?=) Date: Mon, 1 Nov 2021 11:57:24 +0800 Subject: [Haskell-cafe] Type inference for lambda function In-Reply-To: References: <010f017cbce10b46-4c27de87-6b7a-4122-9de3-ac98f4e2dd0e-000000@us-east-2.amazonses.com> Message-ID: <8777A0F1-B224-4703-9C92-51A8CC08A465@gmail.com> > On 1 Nov 2021, at 02:16, Ben Franksen wrote: > > The MonomorphismRestriction should be eliminated from the next Haskell standard. Wait, what? Wouldn't that silently change behaviour of programs and make them slower? Andreas From david.feuer at gmail.com Mon Nov 1 04:54:47 2021 From: david.feuer at gmail.com (David Feuer) Date: Mon, 1 Nov 2021 00:54:47 -0400 Subject: [Haskell-cafe] Type inference for lambda function In-Reply-To: <8777A0F1-B224-4703-9C92-51A8CC08A465@gmail.com> References: <010f017cbce10b46-4c27de87-6b7a-4122-9de3-ac98f4e2dd0e-000000@us-east-2.amazonses.com> <8777A0F1-B224-4703-9C92-51A8CC08A465@gmail.com> Message-ID: It would silently change behavior of some programs, yes. It could also make them slower under some circumstances. But anyone relying on the monomorphism restriction to choose types for their program should change their ways regardless. Top level type signatures aren't that hard to write. On Sun, Oct 31, 2021, 11:58 PM Andreas Källberg wrote: > > > On 1 Nov 2021, at 02:16, Ben Franksen wrote: > > > > The MonomorphismRestriction should be eliminated from the next Haskell > standard. > > Wait, what? Wouldn't that silently change behaviour of programs and make > them slower? > > Andreas > _______________________________________________ > 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 stuart.hungerford at gmail.com Mon Nov 1 05:06:55 2021 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Mon, 1 Nov 2021 16:06:55 +1100 Subject: [Haskell-cafe] GHC 9.2.x error on m1 Mac? Message-ID: Hi, I've been trying out the latest GHC (9.2.1) on an m1 Mac running macOS 12.0.1. I'm seeing this error when building an existing project: Failed to build wcwidth-0.0.2. Build log ( /Users/stu/.cabal/logs/ghc-9.2.1/wcwdth-0.0.2-232d390d.log ): Warning: wcwidth.cabal:47:45: version operators used. To use version operators the package needs to specify at least 'cabal-version: >= 1.8'. Warning: wcwidth.cabal:30:45: version operators used. To use version operators the package needs to specify at least 'cabal-version: >= 1.8'. Configuring wcwidth-0.0.2... Preprocessing library for wcwidth-0.0.2.. Building library for wcwidth-0.0.2.. [1 of 1] Compiling Data.Char.WCWidth ( Data/Char/WCWidth.hs, dist/build/Data/Char/WCWidth.o, dist/build/Data/Char/WCWidth.dyn_o ) In file included from /var/folders/2q/ym4rpn7j6v9d6jhpt0wnk03r0000gn/T/ghc7111_0/ghc_3.c:4:0: error: In file included from /Users/stu/.ghcup/ghc/9.2.1/lib/ghc-9.2.1/lib/../lib/aarch64-osx-ghc-9.2.1/rts-1.0.2/include/ffi.h:66:0: error: /Users/stu/.ghcup/ghc/9.2.1/lib/ghc-9.2.1/lib/../lib/aarch64-osx-ghc-9.2.1/rts-1.0.2/include/ffitarget.h:6:10: error: fatal error: 'ffitarget_arm64.h' file not found | 6 | #include "ffitarget_arm64.h" | ^ #include "ffitarget_arm64.h" ^~~~~~~~~~~~~~~~~~~ 1 error generated. Am I missing a package or system library/header that provides that ffitarget_arm64.h file? TIA, Stu From david.feuer at gmail.com Mon Nov 1 05:09:01 2021 From: david.feuer at gmail.com (David Feuer) Date: Mon, 1 Nov 2021 01:09:01 -0400 Subject: [Haskell-cafe] GHC 9.2.x error on m1 Mac? In-Reply-To: References: Message-ID: You should definitely file a ticket on the GHC GitLab. On Mon, Nov 1, 2021, 1:07 AM Stuart Hungerford wrote: > Hi, > > I've been trying out the latest GHC (9.2.1) on an m1 Mac running macOS > 12.0.1. I'm seeing this error when building an existing project: > > Failed to build wcwidth-0.0.2. > Build log ( /Users/stu/.cabal/logs/ghc-9.2.1/wcwdth-0.0.2-232d390d.log ): > Warning: wcwidth.cabal:47:45: version operators used. To use version > operators > the package needs to specify at least 'cabal-version: >= 1.8'. > Warning: wcwidth.cabal:30:45: version operators used. To use version > operators > the package needs to specify at least 'cabal-version: >= 1.8'. > Configuring wcwidth-0.0.2... > Preprocessing library for wcwidth-0.0.2.. > Building library for wcwidth-0.0.2.. > [1 of 1] Compiling Data.Char.WCWidth ( Data/Char/WCWidth.hs, > dist/build/Data/Char/WCWidth.o, dist/build/Data/Char/WCWidth.dyn_o ) > > In file included from > /var/folders/2q/ym4rpn7j6v9d6jhpt0wnk03r0000gn/T/ghc7111_0/ghc_3.c:4:0: > error: > > > In file included from > > /Users/stu/.ghcup/ghc/9.2.1/lib/ghc-9.2.1/lib/../lib/aarch64-osx-ghc-9.2.1/rts-1.0.2/include/ffi.h:66:0: > error: > > > > /Users/stu/.ghcup/ghc/9.2.1/lib/ghc-9.2.1/lib/../lib/aarch64-osx-ghc-9.2.1/rts-1.0.2/include/ffitarget.h:6:10: > error: > fatal error: 'ffitarget_arm64.h' file not found > | > 6 | #include "ffitarget_arm64.h" > | ^ > #include "ffitarget_arm64.h" > ^~~~~~~~~~~~~~~~~~~ > 1 error generated. > > > Am I missing a package or system library/header that provides that > ffitarget_arm64.h file? > > TIA, > > Stu > _______________________________________________ > 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 ietf-dane at dukhovni.org Mon Nov 1 05:10:14 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Nov 2021 01:10:14 -0400 Subject: [Haskell-cafe] Type inference for lambda function In-Reply-To: References: <010f017cbce10b46-4c27de87-6b7a-4122-9de3-ac98f4e2dd0e-000000@us-east-2.amazonses.com> <8777A0F1-B224-4703-9C92-51A8CC08A465@gmail.com> Message-ID: On Mon, Nov 01, 2021 at 12:54:47AM -0400, David Feuer wrote: > It would silently change behavior of some programs, yes. It could also make > them slower under some circumstances. But anyone relying on the > monomorphism restriction to choose types for their program should change > their ways regardless. Top level type signatures aren't that hard to write. It isn't just, or even primarily top level signatures. It is more often let bindings that will lack a signature, and frankly I'd rather have the restriction in place. When your type fails to generalise and code does not compile, the solution is not hard to find. When let-bound expressions cease to be CAFs, and start being evaluated repeatedly, rather than just once, that's substantially harder to find and diagnose. -- Viktor. From stuart.hungerford at gmail.com Mon Nov 1 05:11:58 2021 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Mon, 1 Nov 2021 16:11:58 +1100 Subject: [Haskell-cafe] GHC 9.2.x error on m1 Mac? In-Reply-To: References: Message-ID: On Mon, Nov 1, 2021 at 4:09 PM David Feuer wrote: > > You should definitely file a ticket on the GHC GitLab. Will do. Stu From stuart.hungerford at gmail.com Mon Nov 1 05:19:38 2021 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Mon, 1 Nov 2021 16:19:38 +1100 Subject: [Haskell-cafe] GHC 9.2.x error on m1 Mac? In-Reply-To: References: Message-ID: On Mon, Nov 1, 2021 at 4:09 PM David Feuer wrote: > > You should definitely file a ticket on the GHC GitLab. Is there any authentication required beyond being signed in to Gitlab to create an issue there, or is there a different process required? Since the Monterey upgrade I've had quite a few keychain issues so it could be something on my end. Ta, Stu From david.feuer at gmail.com Mon Nov 1 05:30:07 2021 From: david.feuer at gmail.com (David Feuer) Date: Mon, 1 Nov 2021 01:30:07 -0400 Subject: [Haskell-cafe] GHC 9.2.x error on m1 Mac? In-Reply-To: References: Message-ID: I'm no expert, but if you have an account on gitlab.haskell.org you really should be able to open an issue. On Mon, Nov 1, 2021, 1:19 AM Stuart Hungerford wrote: > On Mon, Nov 1, 2021 at 4:09 PM David Feuer wrote: > > > > > You should definitely file a ticket on the GHC GitLab. > > Is there any authentication required beyond being signed in to Gitlab > to create an issue there, or is there a different process required? > > Since the Monterey upgrade I've had quite a few keychain issues so it > could be something on my end. > > Ta, > > Stu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Mon Nov 1 07:06:16 2021 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 1 Nov 2021 08:06:16 +0100 Subject: [Haskell-cafe] Type inference for lambda function In-Reply-To: References: <010f017cbce10b46-4c27de87-6b7a-4122-9de3-ac98f4e2dd0e-000000@us-east-2.amazonses.com> <8777A0F1-B224-4703-9C92-51A8CC08A465@gmail.com> Message-ID: Am 01.11.21 um 06:10 schrieb Viktor Dukhovni: > On Mon, Nov 01, 2021 at 12:54:47AM -0400, David Feuer wrote: > >> It would silently change behavior of some programs, yes. It could also make >> them slower under some circumstances. But anyone relying on the >> monomorphism restriction to choose types for their program should change >> their ways regardless. Top level type signatures aren't that hard to write. > > It isn't just, or even primarily top level signatures. It is more often > let bindings that will lack a signature, and frankly I'd rather have > the restriction in place. > > When your type fails to generalise and code does not compile, the > solution is not hard to find. When let-bound expressions cease > to be CAFs, and start being evaluated repeatedly, rather than > just once, that's substantially harder to find and diagnose. > Good point. I have a question, since the wording in the Haskell 2010 Report is pretty complicated: Is it really guaranteed that a declaration of the form var = closed_expr (where closed_expr contains no free variables) without a type signature compiles to a CAF? I.e. is evaluated only once? Assuming this is is the case I admit there is justification for the MR. Other solutions are possible, though, for instance the compiler could issue a warning, ideally together with a hint that you may want to add a type signature to make your intention clear: either you want a CAF or the most general type; you can't have both. Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman From Graham.Hutton at nottingham.ac.uk Mon Nov 1 12:18:54 2021 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 1 Nov 2021 12:18:54 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call For PhD Abstracts Message-ID: Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, 200 published to date, deadline 30th November 2021. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th November 2021 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton by 30th November 2021. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From markus.l2ll at gmail.com Mon Nov 1 14:07:02 2021 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Mon, 1 Nov 2021 16:07:02 +0200 Subject: [Haskell-cafe] No "fields of ... not initialized" warning with RecordWildCards and Void? Message-ID: Hi! Would it make sense to suppress the "fields of ... not initialized" when the type of the field is Void, or any other type with no data constructors? As the only way to construct void would be `undefined :: Void`, and the field already is undefined. Regards, -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Nov 1 14:22:46 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 1 Nov 2021 14:22:46 +0000 Subject: [Haskell-cafe] No "fields of ... not initialized" warning with RecordWildCards and Void? In-Reply-To: References: Message-ID: <20211101142246.GD24797@cloudinit-builder> On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote: > Would it make sense to suppress the "fields of ... not initialized" when > the type of the field is Void, or any other type with no data constructors? > As the only way to construct void would be `undefined :: Void`, and the > field already is undefined. It makes the opposite of sense to me. The warning is there to tell you when you've failed to initialize a field. Whether you *can't* initialise a field because its type has no values makes no difference. You're still not initialising it! I sometimes use a polymorphic field to indicate whether a constructor can be present or not. For example data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr Now `type ProductExpr = Expr ()` is an `Expr` which might contain `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which cannot because I "can't" write a `Product` constructor for it (at least not without getting a warning). I'm curious: how come you're in the situation where you need to fill in product types with `Void` entries? Tom From markus.l2ll at gmail.com Mon Nov 1 16:58:16 2021 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Mon, 1 Nov 2021 18:58:16 +0200 Subject: [Haskell-cafe] No "fields of ... not initialized" warning with RecordWildCards and Void? In-Reply-To: <20211101142246.GD24797@cloudinit-builder> References: <20211101142246.GD24797@cloudinit-builder> Message-ID: Right, I see how you mean. My use of Void is similar to your example: it's a polymorphic field that I don't want to be able to use sometimes, and with Void I thought I wouldn't (at the value level, that is), but as you say I shouldn't be able to construct it either (which I do want to do). In short, what I wanted to remind myself was that this field is empty, and it seemed a better candidate than the unit as the unit I could handle at runtime. But perhaps the correct solution is to refactor the type into separate data types instead. On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote: > > Would it make sense to suppress the "fields of ... not initialized" when > > the type of the field is Void, or any other type with no data > constructors? > > As the only way to construct void would be `undefined :: Void`, and the > > field already is undefined. > > It makes the opposite of sense to me. The warning is there to tell > you when you've failed to initialize a field. Whether you *can't* > initialise a field because its type has no values makes no difference. > You're still not initialising it! > > I sometimes use a polymorphic field to indicate whether a constructor > can be present or not. For example > > data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr > > Now `type ProductExpr = Expr ()` is an `Expr` which might contain > `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which > cannot because I "can't" write a `Product` constructor for it (at > least not without getting a warning). > > I'm curious: how come you're in the situation where you need to fill > in product types with `Void` entries? > > 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. -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Nov 1 17:02:42 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 1 Nov 2021 17:02:42 +0000 Subject: [Haskell-cafe] No "fields of ... not initialized" warning with RecordWildCards and Void? In-Reply-To: References: <20211101142246.GD24797@cloudinit-builder> Message-ID: <20211101170242.GG24797@cloudinit-builder> Ah, I think you really do want () there then, not Void. Void you *can* use. In fact you can use it to make anything! absurd :: Void -> a () you can't really use because you can't use it to make anything that wasn't there in the first place. Tom On Mon, Nov 01, 2021 at 06:58:16PM +0200, Markus Läll wrote: > My use of Void is similar to your example: it's a polymorphic field that I > don't want to be able to use sometimes, and with Void I thought I wouldn't > (at the value level, that is), but as you say I shouldn't be able to > construct it either (which I do want to do). In short, what I wanted to > remind myself was that this field is empty, and it seemed a better > candidate than the unit as the unit I could handle at runtime. But perhaps > the correct solution is to refactor the type into separate data types > instead. > > On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > > On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote: > > > Would it make sense to suppress the "fields of ... not initialized" when > > > the type of the field is Void, or any other type with no data > > constructors? > > > As the only way to construct void would be `undefined :: Void`, and the > > > field already is undefined. > > > > It makes the opposite of sense to me. The warning is there to tell > > you when you've failed to initialize a field. Whether you *can't* > > initialise a field because its type has no values makes no difference. > > You're still not initialising it! > > > > I sometimes use a polymorphic field to indicate whether a constructor > > can be present or not. For example > > > > data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr > > > > Now `type ProductExpr = Expr ()` is an `Expr` which might contain > > `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which > > cannot because I "can't" write a `Product` constructor for it (at > > least not without getting a warning). > > > > I'm curious: how come you're in the situation where you need to fill > > in product types with `Void` entries? From johannes.waldmann at htwk-leipzig.de Mon Nov 1 17:29:00 2021 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Mon, 1 Nov 2021 18:29:00 +0100 Subject: [Haskell-cafe] German live interview about experiences with functional programming, today 12:00 In-Reply-To: References: Message-ID: <2b43a7f3-922a-7395-b0e4-d1689f7ade6c@htwk-leipzig.de> On 10/29/21 09:14, Henning Thielemann wrote: > > https://www.heise.de/news/software-architektur-tv-Funktionale-Programmierung-in-der-Praxis-6228851.html > possibly interesting - is there a transcript? I'm not going to watch what looks like one hour of three people sitting on chairs. - J. NB: https://www.imn.htwk-leipzig.de/~waldmann/etc/lehr-videos/ From markus.l2ll at gmail.com Mon Nov 1 17:31:10 2021 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Mon, 1 Nov 2021 19:31:10 +0200 Subject: [Haskell-cafe] No "fields of ... not initialized" warning with RecordWildCards and Void? In-Reply-To: <20211101170242.GG24797@cloudinit-builder> References: <20211101142246.GD24797@cloudinit-builder> <20211101170242.GG24797@cloudinit-builder> Message-ID: Got it! I think I've found another way to think about this: - Void is a type-level empty: you can't even construct it - () is a value-level empty: you can construct it but the information content of the value is empty On Mon, Nov 1, 2021 at 7:04 PM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > Ah, I think you really do want () there then, not Void. Void you > *can* use. In fact you can use it to make anything! > > absurd :: Void -> a > > () you can't really use because you can't use it to make anything that > wasn't there in the first place. > > Tom > > On Mon, Nov 01, 2021 at 06:58:16PM +0200, Markus Läll wrote: > > My use of Void is similar to your example: it's a polymorphic field that > I > > don't want to be able to use sometimes, and with Void I thought I > wouldn't > > (at the value level, that is), but as you say I shouldn't be able to > > construct it either (which I do want to do). In short, what I wanted to > > remind myself was that this field is empty, and it seemed a better > > candidate than the unit as the unit I could handle at runtime. But > perhaps > > the correct solution is to refactor the type into separate data types > > instead. > > > > On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < > > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > > > > On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote: > > > > Would it make sense to suppress the "fields of ... not initialized" > when > > > > the type of the field is Void, or any other type with no data > > > constructors? > > > > As the only way to construct void would be `undefined :: Void`, and > the > > > > field already is undefined. > > > > > > It makes the opposite of sense to me. The warning is there to tell > > > you when you've failed to initialize a field. Whether you *can't* > > > initialise a field because its type has no values makes no difference. > > > You're still not initialising it! > > > > > > I sometimes use a polymorphic field to indicate whether a constructor > > > can be present or not. For example > > > > > > data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr > > > > > > Now `type ProductExpr = Expr ()` is an `Expr` which might contain > > > `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which > > > cannot because I "can't" write a `Product` constructor for it (at > > > least not without getting a warning). > > > > > > I'm curious: how come you're in the situation where you need to fill > > > in product types with `Void` entries? > _______________________________________________ > 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. -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Nov 1 17:57:47 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 1 Nov 2021 18:57:47 +0100 (CET) Subject: [Haskell-cafe] German live interview about experiences with functional programming, today 12:00 In-Reply-To: <2b43a7f3-922a-7395-b0e4-d1689f7ade6c@htwk-leipzig.de> References: <2b43a7f3-922a-7395-b0e4-d1689f7ade6c@htwk-leipzig.de> Message-ID: On Mon, 1 Nov 2021, Johannes Waldmann wrote: > On 10/29/21 09:14, Henning Thielemann wrote: > >> https://www.heise.de/news/software-architektur-tv-Funktionale-Programmierung-in-der-Praxis-6228851.html > > possibly interesting - is there a transcript? > > I'm not going to watch what looks like > one hour of three people sitting on chairs. The summary is: The woman uses Clojure, the man uses Scala. He likes writing type signatures first, then filling in the implementation. She likes experimenting with running code, instead. Then they talk about didactics. Is functional code easier or harder to understand than imperative one? Is it better to learn functional programming first or is it better to switch from imperative programming? He says that switching from Java to Scala did not make him switch to functional style really, instead he only got the essence of functional programming by playing with Haskell. She advises to start learning functional programming with Project Euler. He adds that one must implement real world projects sooner or later, because with small examples you cannot really judge the value of a programming language. The most interesting fact for the viewers is certainly, that there are real people who use functional programming to solve real problems. From lemming at henning-thielemann.de Mon Nov 1 19:27:39 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 1 Nov 2021 20:27:39 +0100 (CET) Subject: [Haskell-cafe] Trojan source Message-ID: Hide malicious code behind Unicode with reversed text direction: https://github.com/nickboucher/trojan-source They are missing the Haskell examples. From hecate at glitchbra.in Mon Nov 1 19:43:50 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Mon, 1 Nov 2021 20:43:50 +0100 Subject: [Haskell-cafe] Trojan source In-Reply-To: References: Message-ID: <4d1e275d-3e15-66c6-a54c-0a4cfd4ba36f@glitchbra.in> The corresponding ticket is here: https://gitlab.haskell.org/ghc/ghc/-/issues/20263 and was solved here: https://gitlab.haskell.org/ghc/ghc/-/issues/20263 Le 01/11/2021 à 20:27, Henning Thielemann a écrit : > > Hide malicious code behind Unicode with reversed text direction: >   https://github.com/nickboucher/trojan-source > > They are missing the Haskell examples. > _______________________________________________ > 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. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From lists at richarde.dev Mon Nov 1 20:48:17 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 1 Nov 2021 20:48:17 +0000 Subject: [Haskell-cafe] ghci's choice of names for type variables In-Reply-To: <24957.10043.722085.174446@high.stevens-bradfield.com> References: <24957.7178.240402.919556@high.stevens-bradfield.com> <24957.10043.722085.174446@high.stevens-bradfield.com> Message-ID: <010f017cdd4287cf-16c94769-41a2-461c-b1fc-10be9708c530-000000@us-east-2.amazonses.com> Joachim is right that, when you use a function that's already defined somewhere, GHC will use its choice of type variable names. That explains all the 'a's you observe. As for the others, `t` is GHC's letter of choice most of the time, and it's hard to predict (even for me, with pretty deep knowledge of the type checker) when it will use `p`. Bottom line: don't think about this too much -- there's not much of a signal in the noise. :) Richard > On Oct 30, 2021, at 7:06 AM, Julian Bradfield wrote: > > I have tried to answer this by google and the list archives, but > without success, though it wouldn't surprise me if there is a post > buried somewhere. > > This is GHCI 8.10.7. > > When ghci infers types, it sometimes produces types with "a", with > "t", and with "p" (and maybe others), as in the following set of > examples: > > Prelude> h (x : xs) = x > Prelude> :t h > h :: [a] -> a > Prelude> foo f x = not(f x) > Prelude> :t foo > foo :: (t -> Bool) -> t -> Bool > Prelude> bar f x = (f x) + 1 > Prelude> :t bar > bar :: Num a => (t -> a) -> t -> a > Prelude> barb f x g y = (f x)+(g y) > Prelude> :t barb > barb :: Num a => (t1 -> a) -> t1 -> (t2 -> a) -> t2 -> a > Prelude> gar f x = f x > Prelude> :t gar > gar :: (t1 -> t2) -> t1 -> t2 > Prelude> fooa x = x > Prelude> :t fooa > fooa :: p -> p > > What is its rationale? I have attempted to find it in the typechecker > code, and I see things that suggest "t" is something to do with tau > types (monotypes?), and "p" has something to do with levels, but going > from basic Haskell and a modest theoretical acquaintance with System F to > being able to read the GHCi type-checker is several steps too far! > > Can somebody give me a brief explanation of what's going on? In > particular, is there actual information about the types in the choice > of letters, or is it just incidental information about the way type > inference proceeded? > > Thanks, > Julian. > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > 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 keith.wygant at gmail.com Mon Nov 1 23:00:25 2021 From: keith.wygant at gmail.com (Keith) Date: Mon, 01 Nov 2021 23:00:25 +0000 Subject: [Haskell-cafe] No "fields of ... not initialized" warning with RecordWildCards and Void? In-Reply-To: References: <20211101142246.GD24797@cloudinit-builder> <20211101170242.GG24797@cloudinit-builder> Message-ID: <0C28285D-F1A6-47CF-97A7-2F4B3A355167@gmail.com> Yes, except you have been constructing a Void value in Haskell (it's just always bottom); that's why you got a compiler warning. Sent from my phone with K-9 Mail. On 1 November 2021 17:31:10 UTC, "Markus Läll" wrote: >Got it! I think I've found another way to think about this: >- Void is a type-level empty: you can't even construct it >- () is a value-level empty: you can construct it but the information >content of the value is empty > >On Mon, Nov 1, 2021 at 7:04 PM Tom Ellis < >tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > >> Ah, I think you really do want () there then, not Void. Void you >> *can* use. In fact you can use it to make anything! >> >> absurd :: Void -> a >> >> () you can't really use because you can't use it to make anything that >> wasn't there in the first place. >> >> Tom >> >> On Mon, Nov 01, 2021 at 06:58:16PM +0200, Markus Läll wrote: >> > My use of Void is similar to your example: it's a polymorphic field that >> I >> > don't want to be able to use sometimes, and with Void I thought I >> wouldn't >> > (at the value level, that is), but as you say I shouldn't be able to >> > construct it either (which I do want to do). In short, what I wanted to >> > remind myself was that this field is empty, and it seemed a better >> > candidate than the unit as the unit I could handle at runtime. But >> perhaps >> > the correct solution is to refactor the type into separate data types >> > instead. >> > >> > On Mon, Nov 1, 2021 at 4:23 PM Tom Ellis < >> > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: >> > >> > > On Mon, Nov 01, 2021 at 04:07:02PM +0200, Markus Läll wrote: >> > > > Would it make sense to suppress the "fields of ... not initialized" >> when >> > > > the type of the field is Void, or any other type with no data >> > > constructors? >> > > > As the only way to construct void would be `undefined :: Void`, and >> the >> > > > field already is undefined. >> > > >> > > It makes the opposite of sense to me. The warning is there to tell >> > > you when you've failed to initialize a field. Whether you *can't* >> > > initialise a field because its type has no values makes no difference. >> > > You're still not initialising it! >> > > >> > > I sometimes use a polymorphic field to indicate whether a constructor >> > > can be present or not. For example >> > > >> > > data Expr a = Zero | One | Sum Expr Expr | Product a Expr Expr >> > > >> > > Now `type ProductExpr = Expr ()` is an `Expr` which might contain >> > > `Product`s. `type NoProductExpr = Expr Void` is an `Expr` which >> > > cannot because I "can't" write a `Product` constructor for it (at >> > > least not without getting a warning). >> > > >> > > I'm curious: how come you're in the situation where you need to fill >> > > in product types with `Void` entries? >> _______________________________________________ >> 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. > > > >-- >Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.wehr at gmail.com Tue Nov 2 15:12:22 2021 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Tue, 2 Nov 2021 16:12:22 +0100 Subject: [Haskell-cafe] Call for Contributions: BOB 2022 [March 11, Deadline Dec 6] Message-ID: ================================================================================ BOB Conference 2022 "What happens when we use what's best for a change?" http://bobkonf.de/2022/cfc.html Berlin, Mar 11 Call for Contributions Deadline: December 6, 2021 ================================================================================ You are actively engaged in advanced software engineering methods, solve ambitious problem with software and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Online or Onsite ---------------- We expect we'll be able to hold BOB 2022 in Berlin. If that is not possible, we'll make BOB a successful online event, like BOB 2021. Should BOB happen online, we will likely ask for pre-recorded talks to make room for questions and social interactions during the actual conference day. (Of course, we'll provide assistance making those recordings.) Tutorials will likely happen as a live-session. Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions. Specifically: - advice on structure and presentation - review of talk slides - assistance with recording - review of recording, if applicable Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, and speakers who are not able to attend the conference for financial reasons. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - "fancy types" (dependent types, gradual typing, linear types, ...) - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - program synthesis - next-generation IDEs - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. Challenges ---------- Furthermore, we seek contributions on successful approaches for solving hard problems, for example: - bias in machine-learning systems - digital transformation in difficult settings - accessibiltity - systems with critical reliability requirements - ecologically sustainable software development We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) - Don't be confused: The system calls a submission event. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: December 6, 2021 - Notification: December 17, 2021 - Program: December 22, 2021 Submit here: https://bobcfc.active-group.de/en/bob2022/cfp Program Committee ----------------- (more information here: https://bobkonf.de/2022/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Tue Nov 2 20:06:22 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 2 Nov 2021 21:06:22 +0100 Subject: [Haskell-cafe] [ANN] text-display 0.0.1.0: A typeclass for user-facing output Message-ID: Hi everyone, I am proud to release the first version of text-display¹, a typeclass for user-facing output. `Display` is a typeclass that doesn't abide by the rules of `Show` & `Read`, and brings with it a nice and ergonomic way to derive instances through `DerivingVia` when they already have a `Show` instance: ```haskell {-# LANGUAGE DerivingVia #-} data AutomaticallyDerived = AD   -- We derive 'Show'   deriving Show   -- We take advantage of the 'Show' instance to derive 'Display' from it   deriving Display     via (ShowInstance AutomaticallyDerived) ``` But let's say you want to redact an instance of `Display`? You can do it locally, through the `OpaqueInstance` helper. It is most useful to hide tokens or passwords: ```haskell data UserToken = UserToken UUID  deriving Display    via (OpaqueInstance "[REDACTED]" UserToken) display $ UserToken "7a01d2ce-31ff-11ec-8c10-5405db82c3cd" -- => "[REDACTED]" ``` I hope you will have fun with this library! Cheers! ¹ https://hackage.haskell.org/package/text-display-0.0.1.0 -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From ietf-dane at dukhovni.org Tue Nov 2 20:44:30 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Nov 2021 16:44:30 -0400 Subject: [Haskell-cafe] [ANN] text-display 0.0.1.0: A typeclass for user-facing output In-Reply-To: References: Message-ID: On Tue, Nov 02, 2021 at 09:06:22PM +0100, Hécate wrote: > Hi everyone, I am proud to release the first version of text-display¹, a > typeclass for user-facing output. Looks cool. Thanks! A quick typo fix in the docs: s/decude/decode/ > ```haskell > {-# LANGUAGE DerivingVia #-} > data AutomaticallyDerived = AD >   -- We derive 'Show' >   deriving Show >   -- We take advantage of the 'Show' instance to derive 'Display' from it >   deriving Display >     via (ShowInstance AutomaticallyDerived) > ``` This is a cool approach to reconciling Show with Display! I have a related question. In a DNS library I'm working on the "presentation form" of all resource records is ASCII octet strings, not UTF-8 text. I was building a similar "Present" type class that renders DNS resource records as (ASCII) ByteStrings, and uses ByteString builders for efficiency. With Text now moving to UTF8, which subsumes ASCII, I could perhaps just switch to using "display" instead and output Text? One thing I'm not sure about is how to embed any existing ByteString builders that are guaranteed to produce UTF-8 output as Text builders (given the new UTF-8 Text representation) without materialising the intermediate ByteString. It would cool if either Text or ByteString provided a mechanism to execute a ByteString builder as a Text builder (with a caveat that this is only valid for ASCII content). One potential application is that iproute now has an efficient ByteString Builder mapping IPv4 and IPv6 addresses to their ASCII forms (which is substantially faster than e.g. typical C-library inet_pton). If I want to "display" IPv[46] addresses efficiently as part of larger output streams (i.e. use display builders), how would I get a Text Builder from a ByteString builder without "needless" allocation and copying? I'd prefer to avoid cloning the ByteString builder code in iproute to produce a parallel Text builder implementation, though that could be a last resort... -- Viktor. From rinus at top-software.nl Wed Nov 3 13:55:00 2021 From: rinus at top-software.nl (rinus plasmeijer) Date: Wed, 3 Nov 2021 14:55:00 +0100 Subject: [Haskell-cafe] TOP is hiring Functional Programmers for developing multi-user web applications Message-ID: <663cc146-6513-2410-c801-19b4276588ee@top-software.nl> Dear Haskell Fans, TOP Software Technology (top-software.com ) is a recently founded (2018) spin-off company located in the Netherlands, building on decades of research on Functional Programming at the Radboud University of Nijmegen (clean.cs.ru.nl ). By using advanced Functional Programming techniques and tools, we develop collaborative, distributed, multi-user / multi-system / multi-platform, web-oriented software applications for industry. We focus on Command and Control type of applications such as VIIA where real-time information is used for monitoring vessels. We use Clean, a Haskell like pure and lazy functional language, and the iTask system offering Task Oriented Programming (TOP), a special flavour of Functional Programming to construct reliable software applications for our customers at a high-level of abstraction on an Agile manner. We are looking for Experienced Functional Programmers to join our team. See the attached pdf. More information on what we do can be found ontop-software.com . Mail torinus at top-software.com orrinus at cs.ru.nl if you are interested. Greetings, Rinus Plasmeijer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: advertentie.pdf Type: application/pdf Size: 123663 bytes Desc: not available URL: From anka.213 at gmail.com Thu Nov 4 00:46:44 2021 From: anka.213 at gmail.com (=?utf-8?Q?Andreas_K=C3=A4llberg?=) Date: Thu, 4 Nov 2021 08:46:44 +0800 Subject: [Haskell-cafe] Type inference for lambda function In-Reply-To: References: Message-ID: <96ABA9AD-F4F4-4851-AFD6-AE817E50DB1E@gmail.com> Changing it into a warning might not be a bad idea at all. It is a common problem for beginners after all. The only risk is if it would force you to write a lot more type signatures in order to avoid the warning. Another option would be to improve error messages around it so ghc can suggest either adding an explicit type signature or disabling the restriction. This might be difficult to implement though, since the error usually happens when type checking something else. > On 1 Nov 2021, at 15:10, Ben Franksen wrote: > > Am 01.11.21 um 06:10 schrieb Viktor Dukhovni: >>> On Mon, Nov 01, 2021 at 12:54:47AM -0400, David Feuer wrote: >>> It would silently change behavior of some programs, yes. It could also make >>> them slower under some circumstances. But anyone relying on the >>> monomorphism restriction to choose types for their program should change >>> their ways regardless. Top level type signatures aren't that hard to write. >> It isn't just, or even primarily top level signatures. It is more often >> let bindings that will lack a signature, and frankly I'd rather have >> the restriction in place. >> When your type fails to generalise and code does not compile, the >> solution is not hard to find. When let-bound expressions cease >> to be CAFs, and start being evaluated repeatedly, rather than >> just once, that's substantially harder to find and diagnose. > > Good point. I have a question, since the wording in the Haskell 2010 Report is pretty complicated: > > Is it really guaranteed that a declaration of the form > > var = closed_expr > > (where closed_expr contains no free variables) without a type signature compiles to a CAF? I.e. is evaluated only once? > > Assuming this is is the case I admit there is justification for the MR. > > Other solutions are possible, though, for instance the compiler could issue a warning, ideally together with a hint that you may want to add a type signature to make your intention clear: either you want a CAF or the most general type; you can't have both. > > Cheers > Ben > -- > I would rather have questions that cannot be answered, than answers that > cannot be questioned. -- Richard Feynman > > > _______________________________________________ > 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 lists at richarde.dev Thu Nov 4 13:39:37 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 4 Nov 2021 13:39:37 +0000 Subject: [Haskell-cafe] Type inference for lambda function In-Reply-To: <96ABA9AD-F4F4-4851-AFD6-AE817E50DB1E@gmail.com> References: <96ABA9AD-F4F4-4851-AFD6-AE817E50DB1E@gmail.com> Message-ID: <010f017ceb2d2613-8b940996-62dd-4473-9edd-c993f0374e11-000000@us-east-2.amazonses.com> I'd be against just making it a warning. It means that you'd get a warning every time you have `let n = 3` in your code. Killing the MR without a warning is even worse: it means you'd silently get re-evaluation every time you have `let n = m1 + m2` in your code. I will note that GHC supports -Wmonomorphism-restriction, which is exactly the warning that is requested in this thread, for those that want it. Richard > On Nov 3, 2021, at 8:46 PM, Andreas Källberg wrote: > > Changing it into a warning might not be a bad idea at all. It is a common problem for beginners after all. The only risk is if it would force you to write a lot more type signatures in order to avoid the warning. > > Another option would be to improve error messages around it so ghc can suggest either adding an explicit type signature or disabling the restriction. This might be difficult to implement though, since the error usually happens when type checking something else. > >> On 1 Nov 2021, at 15:10, Ben Franksen wrote: >> >> Am 01.11.21 um 06:10 schrieb Viktor Dukhovni: >>>> On Mon, Nov 01, 2021 at 12:54:47AM -0400, David Feuer wrote: >>>> It would silently change behavior of some programs, yes. It could also make >>>> them slower under some circumstances. But anyone relying on the >>>> monomorphism restriction to choose types for their program should change >>>> their ways regardless. Top level type signatures aren't that hard to write. >>> It isn't just, or even primarily top level signatures. It is more often >>> let bindings that will lack a signature, and frankly I'd rather have >>> the restriction in place. >>> When your type fails to generalise and code does not compile, the >>> solution is not hard to find. When let-bound expressions cease >>> to be CAFs, and start being evaluated repeatedly, rather than >>> just once, that's substantially harder to find and diagnose. >> >> Good point. I have a question, since the wording in the Haskell 2010 Report is pretty complicated: >> >> Is it really guaranteed that a declaration of the form >> >> var = closed_expr >> >> (where closed_expr contains no free variables) without a type signature compiles to a CAF? I.e. is evaluated only once? >> >> Assuming this is is the case I admit there is justification for the MR. >> >> Other solutions are possible, though, for instance the compiler could issue a warning, ideally together with a hint that you may want to add a type signature to make your intention clear: either you want a CAF or the most general type; you can't have both. >> >> Cheers >> Ben >> -- >> I would rather have questions that cannot be answered, than answers that >> cannot be questioned. -- Richard Feynman >> >> >> _______________________________________________ >> 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. From jcb at inf.ed.ac.uk Fri Nov 5 18:21:26 2021 From: jcb at inf.ed.ac.uk (Julian Bradfield) Date: Fri, 5 Nov 2021 18:21:26 +0000 (GMT) Subject: [Haskell-cafe] printing unicode in Windows console: hPutChar error Message-ID: <20211105182126.C73887E4EE@home.stevens-bradfield.com> Some of my poor misguided students are still using Windows, and when they run my (predecessor's) Haskell program which uses Unicode box drawing characters in its output, they get *** Exception : hPutChar: invalid argument (invalid character) Another student told them to change the console encoding via magic: chcp.com 65001 but a bit of googling suggests that a "modern Windows console program" should be using the widechar API to print Unicode and things should Just Work. Does Haskell have a principled view about character encodings? Or does it just say "I do byte strings, it's the user's problem"? Decades ago I was all in favour of charset-agnosticism, but these days I tend to think "go Unicode, and leave the legacy Latin-1 etc. data as the user's problem" :) Julian. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From allbery.b at gmail.com Fri Nov 5 18:33:15 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 5 Nov 2021 14:33:15 -0400 Subject: [Haskell-cafe] printing unicode in Windows console: hPutChar error In-Reply-To: <20211105182126.C73887E4EE@home.stevens-bradfield.com> References: <20211105182126.C73887E4EE@home.stevens-bradfield.com> Message-ID: What version of GHC areyour students using? I believe sufficiently recent versions of ghc (but I don't know which; this may require 9.2.1) have an RTS option to use a new I/O manager, which among other things implements the widechar API for console I/O. The old I/O manager does not support the widechar API, and the best that can be done is the chcp hack. On Fri, Nov 5, 2021 at 2:24 PM Julian Bradfield wrote: > > Some of my poor misguided students are still using Windows, and when > they run my (predecessor's) Haskell program which uses Unicode box drawing > characters in its output, they get > *** Exception : hPutChar: invalid argument (invalid character) > > Another student told them to change the console encoding via magic: > chcp.com 65001 > > but a bit of googling suggests that a "modern Windows console program" > should be using the widechar API to print Unicode and things should > Just Work. > > Does Haskell have a principled view about character encodings? > Or does it just say "I do byte strings, it's the user's problem"? > > Decades ago I was all in favour of charset-agnosticism, but these > days I tend to think "go Unicode, and leave the legacy Latin-1 > etc. data as the user's problem" :) > > Julian. > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > 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 jdgleeson at mac.com Fri Nov 5 20:30:30 2021 From: jdgleeson at mac.com (John Gleeson) Date: Fri, 5 Nov 2021 14:30:30 -0600 Subject: [Haskell-cafe] printing unicode in Windows console: hPutChar error In-Reply-To: References: Message-ID: <3D3D0764-30A8-441F-812D-9EE6A0133809@mac.com> > On Nov 5, 2021, at 12:34, Brandon Allbery wrote: > > What version of GHC areyour students using? I believe sufficiently > recent versions of ghc (but I don't know which; this may require > 9.2.1) have an RTS option to use a new I/O manager, which among other > things implements the widechar API for console I/O. I found an email from Tamar https://mail.haskell.org/pipermail/ghc-devs/2020-July/019053.html that says the new Windows I/O manager is available in 8.12+, and is enabled with +RTS --io-manager=native -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Sat Nov 6 04:59:41 2021 From: juhpetersen at gmail.com (Jens Petersen) Date: Sat, 6 Nov 2021 12:59:41 +0800 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.1 now available In-Reply-To: <87lf2bu98a.fsf@smart-cactus.org> References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: On Fri, 29 Oct 2021 at 23:54, Ben Gamari wrote: > https://downloads.haskell.org/ghc/9.2.1 > If you are on Fedora you can now install ghc-9.2.1 with: sudo dnf --enablerepo=updates-testing-modular module install ghc:9.2/default Cheers, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.kholomiov at gmail.com Sat Nov 6 09:48:55 2021 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Sat, 6 Nov 2021 12:48:55 +0300 Subject: [Haskell-cafe] Locate errors in TH for Haskell code Message-ID: I have a task to convert one Haskell expression to another. And I'd like to report errors properly. [interpret| -- error reported here valid haskell code invalid code <- error |] I can parse it with haskell-src-exts or haskell-src-meta. but if I have error in the code (type-check) error is positioned on the first line of the QQ-expression. Do you know is it possible to report error at the line where it has happened or to keep original source code location in the Exp. In the function I do transformation Exp -> Exp. Or maybe there is a better way to do it instead of QQ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcb at inf.ed.ac.uk Sat Nov 6 09:56:37 2021 From: jcb at inf.ed.ac.uk (Julian Bradfield) Date: Sat, 6 Nov 2021 09:56:37 +0000 Subject: [Haskell-cafe] printing unicode in Windows console: hPutChar error In-Reply-To: <3D3D0764-30A8-441F-812D-9EE6A0133809@mac.com> References: <3D3D0764-30A8-441F-812D-9EE6A0133809@mac.com> Message-ID: <24966.20821.420370.263372@high.stevens-bradfield.com> John Gleeson wrote: >On Nov 5, 2021, at 12:34, Brandon Allbery wrote: > >>What version of GHC areyour students using? I believe sufficiently >>recent versions of ghc (but I don't know which; this may require >>9.2.1) have an RTS option to use a new I/O manager, which among other >>things implements the widechar API for console I/O. > >I found an email from Tamar >https://mail.haskell.org/pipermail/ghc-devs/2020-July/019053.html >that says the new Windows I/O manager is available in 8.12+, and is enabled with >+RTS --io-manager=native thanks, Brandon and John. I imagine the students are using whatever was the obvious thing when they tried to install Haskell at start of semester. Looks like that would have been 8.10.7. I'll try to remember the RTS option for next year's students! Julian. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat Nov 6 10:06:49 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 6 Nov 2021 10:06:49 +0000 Subject: [Haskell-cafe] printing unicode in Windows console: hPutChar error In-Reply-To: <3D3D0764-30A8-441F-812D-9EE6A0133809@mac.com> References: <3D3D0764-30A8-441F-812D-9EE6A0133809@mac.com> Message-ID: <20211106100649.GG3430@cloudinit-builder> On Fri, Nov 05, 2021 at 02:30:30PM -0600, John Gleeson via Haskell-Cafe wrote: > > On Nov 5, 2021, at 12:34, Brandon Allbery wrote: > > What version of GHC areyour students using? I believe sufficiently > > recent versions of ghc (but I don't know which; this may require > > 9.2.1) have an RTS option to use a new I/O manager, which among other > > things implements the widechar API for console I/O. > > I found an email from Tamar > https://mail.haskell.org/pipermail/ghc-devs/2020-July/019053.html > that says the new Windows I/O manager is available in 8.12+, and is enabled with > +RTS --io-manager=native Given that 8.12 doesn't exist I presume the meaning was "the version after 8.10" which is 9.0. Tom From bruno at ruomad.net Sat Nov 6 10:15:37 2021 From: bruno at ruomad.net (Bruno Damour) Date: Sat, 6 Nov 2021 11:15:37 +0100 Subject: [Haskell-cafe] ghc-9.2.1 unboxed types compatibility Message-ID: <57a313ee-00c6-4ee7-94fa-7a1be18e228a@Canary> Hello, A significant number of libraries are broken by the changes in unboxed types. A lot of them are in the process (or already have) of adding compatibility layers to allow them to support the new version while preserving compatibility with older ones, introducing code like : #if MIN_VERSION_base(4,16,0) word32ToWordCompat# :: Word32# -> Word# word32ToWordCompat# = word32ToWord# #else word32ToWordCompat# :: Word32# -> Word# word32ToWordCompat# x = x #endif for the functions they use (usually a small subset). Some of the solutions appear to differ. Is there a preferred way to make this consistently or/and avoid unnecessary code duplication ? Thanks Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Nov 6 11:52:33 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 6 Nov 2021 12:52:33 +0100 (CET) Subject: [Haskell-cafe] ghc-9.2.1 unboxed types compatibility In-Reply-To: <57a313ee-00c6-4ee7-94fa-7a1be18e228a@Canary> References: <57a313ee-00c6-4ee7-94fa-7a1be18e228a@Canary> Message-ID: <31be425-4913-f7ab-eddf-a5bed48b8622@henning-thielemann.de> On Sat, 6 Nov 2021, Bruno Damour wrote: > A significant number of libraries are broken by the changes in unboxed types. I have seen some breakage because of W# vs. W32#. But I suspect that those libraries do not really need to be implemented that low-level. From bruno at ruomad.net Sat Nov 6 12:08:01 2021 From: bruno at ruomad.net (Bruno Damour) Date: Sat, 6 Nov 2021 13:08:01 +0100 Subject: [Haskell-cafe] ghc-9.2.1 unboxed types compatibility In-Reply-To: <31be425-4913-f7ab-eddf-a5bed48b8622@henning-thielemann.de> References: <57a313ee-00c6-4ee7-94fa-7a1be18e228a@Canary> <31be425-4913-f7ab-eddf-a5bed48b8622@henning-thielemann.de> Message-ID: Well, maybe, but I have seen this in : base16-bytestring basement streaming-commons iproute hashtables So it seems quite widespread… especially as a number of common libraries depend on these (persistent for example) BTW there are a number of patches in headhackage for these -- Sent from Canary (https://canarymail.io) > On Saturday, Nov 06, 2021 at 12:52 PM, Henning Thielemann wrote: > > On Sat, 6 Nov 2021, Bruno Damour wrote: > > > A significant number of libraries are broken by the changes in unboxed types. > > I have seen some breakage because of W# vs. W32#. But I suspect that those > libraries do not really need to be implemented that low-level. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Nov 6 12:21:18 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 6 Nov 2021 08:21:18 -0400 Subject: [Haskell-cafe] printing unicode in Windows console: hPutChar error In-Reply-To: <20211106100649.GG3430@cloudinit-builder> References: <3D3D0764-30A8-441F-812D-9EE6A0133809@mac.com> <20211106100649.GG3430@cloudinit-builder> Message-ID: Yes, 8.12 subsequently got re-versioned to 9.0. On Sat, Nov 6, 2021 at 6:07 AM Tom Ellis wrote: > > On Fri, Nov 05, 2021 at 02:30:30PM -0600, John Gleeson via Haskell-Cafe wrote: > > > On Nov 5, 2021, at 12:34, Brandon Allbery wrote: > > > What version of GHC areyour students using? I believe sufficiently > > > recent versions of ghc (but I don't know which; this may require > > > 9.2.1) have an RTS option to use a new I/O manager, which among other > > > things implements the widechar API for console I/O. > > > > I found an email from Tamar > > https://mail.haskell.org/pipermail/ghc-devs/2020-July/019053.html > > that says the new Windows I/O manager is available in 8.12+, and is enabled with > > +RTS --io-manager=native > > Given that 8.12 doesn't exist I presume the meaning was "the version > after 8.10" which is 9.0. > > 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. -- brandon s allbery kf8nh allbery.b at gmail.com From vamchale at gmail.com Sat Nov 6 12:51:03 2021 From: vamchale at gmail.com (Vanessa McHale) Date: Sat, 6 Nov 2021 07:51:03 -0500 Subject: [Haskell-cafe] ghc-9.2.1 unboxed types compatibility In-Reply-To: <57a313ee-00c6-4ee7-94fa-7a1be18e228a@Canary> References: <57a313ee-00c6-4ee7-94fa-7a1be18e228a@Canary> Message-ID: I’d just release a new version for GHC 9.2.1 forward (I know that solution is unpopular!) - particularly since Word32# seems “more correct" Otherwise I use cpphs. > On Nov 6, 2021, at 5:15 AM, Bruno Damour wrote: > > > Hello, > > A significant number of libraries are broken by the changes in unboxed types. > > A lot of them are in the process (or already have) of adding compatibility layers to allow them to support the new version while preserving compatibility with older ones, introducing code like : > > #if MIN_VERSION_base(4,16,0) > word32ToWordCompat# :: Word32# -> Word# > word32ToWordCompat# = word32ToWord# > #else > word32ToWordCompat# :: Word32# -> Word# > word32ToWordCompat# x = x > #endif > for the functions they use (usually a small subset). > > Some of the solutions appear to differ. > > Is there a preferred way to make this consistently or/and avoid unnecessary code duplication ? > > Thanks > > Bruno > > _______________________________________________ > 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 ietf-dane at dukhovni.org Sat Nov 6 16:58:13 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 6 Nov 2021 12:58:13 -0400 Subject: [Haskell-cafe] ghc-9.2.1 unboxed types compatibility In-Reply-To: <57a313ee-00c6-4ee7-94fa-7a1be18e228a@Canary> Message-ID: On Sat, Nov 06, 2021 at 11:15:37AM +0100, Bruno Damour wrote: > A lot of them are in the process (or already have) of adding > compatibility layers to allow them to support the new version while > preserving compatibility with older ones, introducing code like : > > #if MIN_VERSION_base(4,16,0) > word32ToWordCompat# :: Word32# -> Word# > word32ToWordCompat# = word32ToWord# > #else > word32ToWordCompat# :: Word32# -> Word# > word32ToWordCompat# x = x > #endif > for the functions they use (usually a small subset). > > Some of the solutions appear to differ. > > Is there a preferred way to make this consistently or/and avoid unnecessary code duplication ? Since the above is what the head.hackage maintainers are doing, I assumed that's the way to go. On Sat, Nov 06, 2021 at 01:08:01PM +0100, Bruno Damour wrote: > ... but I have seen this in: > > base16-bytestring > basement > streaming-commons > iproute > hashtables > > So it seems quite widespread… especially as a number of common > libraries depend on these (persistent for example) An updated iproute 1.7.12 is now released, using the head.hackage approach. -- Viktor. From mgajda at mimuw.edu.pl Sun Nov 7 04:47:51 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Sun, 7 Nov 2021 05:47:51 +0100 Subject: [Haskell-cafe] Locate errors in TH for Haskell code Message-ID: Dear Anton, > I have a task to convert one Haskell expression to another. > And I'd like to report errors properly. > > [interpret| -- error reported here > valid haskell code > invalid code <- error > |] > > I can parse it with haskell-src-exts or haskell-src-meta. > but if I have error in the code (type-check) error is positioned on the > first line of the QQ-expression. > > Do you know is it possible to report error at the line where it has > happened or > to keep original source code location in the Exp. > > In the function I do transformation Exp -> Exp. > > Or maybe there is a better way to do it instead of QQ? QQ is a good way. The simplest way would be to use `Language.Haskell.TH.location :: Q Loc` [1] and update it with the `Language.Haskell.Exts.SrcLoc.Loc` you get from `haskell-src-exts`[2]. [1] https://hackage.haskell.org/package/template-haskell-2.18.0.0/docs/Language-Haskell-TH.html#v:location [2] https://hackage.haskell.org/package/haskell-src-exts-1.23.1/docs/Language-Haskell-Exts-SrcLoc.html Note that [1] is available since template-haskell version 2.8.0.0. -- Best regards Michał From david.feuer at gmail.com Tue Nov 9 18:59:03 2021 From: david.feuer at gmail.com (David Feuer) Date: Tue, 9 Nov 2021 13:59:03 -0500 Subject: [Haskell-cafe] [ANN] linear-generics-0.2 Message-ID: This new major version improves the GHCGenerically1 DerivingVia target. Previously, it worked on strictly fewer types than GHC could derive Generic1 for. Now it works on strictly more types than that. It does this by using a derived Generic instance instead of a derived Generic1 instance, thanks to the magic of quantified constraints. For anyone already using the package, the upgrade path is trivial: just derive any additional Generic instances GHC asks for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ida.bzowska at gmail.com Wed Nov 10 11:03:14 2021 From: ida.bzowska at gmail.com (Ida Bzowska) Date: Wed, 10 Nov 2021 12:03:14 +0100 Subject: [Haskell-cafe] [meetup announcement] Haskell Utrecht Meetup Group Message-ID: Hi Everyone, Just letting you know that the freshly formed Haskell meetup from the Netherlands will have the first meetup on the 22nd of Nov; if you are in the area - don't hesitate: come! https://www.meetup.com/haskell-utrecht/events/281978445/ λCheers Ida Bzowska -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Wed Nov 10 19:26:09 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 10 Nov 2021 19:26:09 +0000 Subject: [Haskell-cafe] Locate errors in TH for Haskell code In-Reply-To: References: Message-ID: <010f017d0b50902a-8516f8f4-2bce-4184-acb8-049543e7b056-000000@us-east-2.amazonses.com> Hi Anton, I don't think you're going to be able to do what you want here. :( Template Haskell has no facility to keep track of locations of bits of code. So, when you've processed your Exp and then spliced it in, there are no locations to record, other than the location of the entire splice (which is poor, I know). This has been requested before: https://gitlab.haskell.org/ghc/ghc/-/issues/10330. The problem is that the fix is really quite invasive (it would require adding location information to every constructor in TH, affecting every TH user), and so we've been hesitant to plow forward. If you were to collect a chorus of voices who all wanted this (and were willing to help flesh out the design), it's something we can do -- but I'd want to know it was a popular direction before imposing it on every TH user out there. Richard > On Nov 6, 2021, at 5:48 AM, Anton Kholomiov wrote: > > I have a task to convert one Haskell expression to another. > And I'd like to report errors properly. > > [interpret| -- error reported here > valid haskell code > invalid code <- error > |] > > I can parse it with haskell-src-exts or haskell-src-meta. > but if I have error in the code (type-check) error is positioned on the first line of the QQ-expression. > > Do you know is it possible to report error at the line where it has happened or > to keep original source code location in the Exp. > > In the function I do transformation Exp -> Exp. > > Or maybe there is a better way to do it instead of QQ? > _______________________________________________ > 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 oleg.grenrus at iki.fi Wed Nov 10 19:42:37 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 10 Nov 2021 21:42:37 +0200 Subject: [Haskell-cafe] Locate errors in TH for Haskell code In-Reply-To: <010f017d0b50902a-8516f8f4-2bce-4184-acb8-049543e7b056-000000@us-east-2.amazonses.com> References: <010f017d0b50902a-8516f8f4-2bce-4184-acb8-049543e7b056-000000@us-east-2.amazonses.com> Message-ID: <3b9c85c1-66d0-853d-e01e-0e588ce5c8b6@iki.fi> Isn't the promise of trees-that-grow work to use the same Expr type for TH as well? Then we could get the source locations, don't we? - Oleg On 10.11.2021 21.26, Richard Eisenberg wrote: > Hi Anton, > > I don't think you're going to be able to do what you want here. :( > > Template Haskell has no facility to keep track of locations of bits of code. So, when you've processed your Exp and then spliced it in, there are no locations to record, other than the location of the entire splice (which is poor, I know). > > This has been requested before: https://gitlab.haskell.org/ghc/ghc/-/issues/10330. The problem is that the fix is really quite invasive (it would require adding location information to every constructor in TH, affecting every TH user), and so we've been hesitant to plow forward. If you were to collect a chorus of voices who all wanted this (and were willing to help flesh out the design), it's something we can do -- but I'd want to know it was a popular direction before imposing it on every TH user out there. > > Richard > >> On Nov 6, 2021, at 5:48 AM, Anton Kholomiov wrote: >> >> I have a task to convert one Haskell expression to another. >> And I'd like to report errors properly. >> >> [interpret| -- error reported here >> valid haskell code >> invalid code <- error >> |] >> >> I can parse it with haskell-src-exts or haskell-src-meta. >> but if I have error in the code (type-check) error is positioned on the first line of the QQ-expression. >> >> Do you know is it possible to report error at the line where it has happened or >> to keep original source code location in the Exp. >> >> In the function I do transformation Exp -> Exp. >> >> Or maybe there is a better way to do it instead of QQ? >> _______________________________________________ >> 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. From dsf at seereason.com Thu Nov 11 00:18:58 2021 From: dsf at seereason.com (David Fox) Date: Wed, 10 Nov 2021 16:18:58 -0800 Subject: [Haskell-cafe] Locate errors in TH for Haskell code In-Reply-To: References: Message-ID: I'd like to know more about what you are doing, I feel like I've set out to do something similar in the past and ended up going a different way. On Sat, Nov 6, 2021 at 2:51 AM Anton Kholomiov wrote: > I have a task to convert one Haskell expression to another. > And I'd like to report errors properly. > > [interpret| -- error reported here > valid haskell code > invalid code <- error > |] > > I can parse it with haskell-src-exts or haskell-src-meta. > but if I have error in the code (type-check) error is positioned on the > first line of the QQ-expression. > > Do you know is it possible to report error at the line where it has > happened or > to keep original source code location in the Exp. > > In the function I do transformation Exp -> Exp. > > Or maybe there is a better way to do it instead of QQ? > _______________________________________________ > 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 himabinduvsp1 at gmail.com Thu Nov 11 01:14:27 2021 From: himabinduvsp1 at gmail.com (Hima Bindu) Date: Thu, 11 Nov 2021 06:44:27 +0530 Subject: [Haskell-cafe] Want to join a Team and Looking for good first issues to contribute Message-ID: Hi There! I am Hima Bindu, a CS Undergrad in GVPCE(A), AP, India. I like to be a polyglot and started learning a few languages, and came across Haskell. I was fascinated by its laziness and learned it for a couple of months. I skimmed through the repos, GSoC projects and a few Twitter threads. I want to contribute to anything that is beginner-friendly. It's overwhelming but I want to give it a try. Looking for any kind of suggestions or a walkthrough. This is very new to me, so please feel free to point out if I'm doing something wrong or moving in the wrong direction. *My area of interests:* Compilers(Currently working on one by following Bob Nystrom's book), Operating Systems/Kernals(have no experience but interested), anything related specifically to Haskell language(Data Structures, error handling etc) *Also, I eagerly want to join monthly meetings or something of that sort if there are any. How can I do that?* Really looking forward to your replies. Thank you Have a good day :D -- *Hima Bindu Tenneti* *Reach me here! * *Programs must be written for people to read, and only incidentally for machines to execute. --Hal Abelson, SICP* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Nov 12 18:27:27 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Nov 2021 13:27:27 -0500 Subject: [Haskell-cafe] Should circular deriving "via" be rejected? Message-ID: GHC accepts: {-# LANGUAGE DerivingStrategies, DerivingVia #-} newtype Foo = Foo Int deriving (Show, Eq) via (Bar) newtype Bar = Bar Int deriving (Show, Eq) via (Foo) should there be any effort to avoid circular definitions? Of course one could always implement an explicit `show` method that diverges, so perhaps this is no worse, but on the other hand, statically deciding divergence looks potentially easier in this case... On the other hand actual definitions like this seem unlikely in practice, so perhaps not worth burning precious compiler cycles to detect them? -- Viktor. From david.feuer at gmail.com Fri Nov 12 18:57:52 2021 From: david.feuer at gmail.com (David Feuer) Date: Fri, 12 Nov 2021 13:57:52 -0500 Subject: [Haskell-cafe] Should circular deriving "via" be rejected? In-Reply-To: References: Message-ID: I think it would be good to raise an issue on the GHC GitLab. It would obviously be a nice feature, and the GHC devs are best positioned to figure out if it's worth the time and trouble. Any such check will surely be imprecise, since deriving via instances can take lots of forms, but it'd be nice to catch simple cases. Presumably it'd be a warning and not an error. On Fri, Nov 12, 2021, 1:30 PM Viktor Dukhovni wrote: > > GHC accepts: > > {-# LANGUAGE DerivingStrategies, DerivingVia #-} > newtype Foo = Foo Int deriving (Show, Eq) via (Bar) > newtype Bar = Bar Int deriving (Show, Eq) via (Foo) > > should there be any effort to avoid circular definitions? > > Of course one could always implement an explicit `show` method that > diverges, so perhaps this is no worse, but on the other hand, statically > deciding divergence looks potentially easier in this case... On the > other hand actual definitions like this seem unlikely in practice, so > perhaps not worth burning precious compiler cycles to detect them? > > -- > Viktor. > _______________________________________________ > 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 james.faure at epitech.eu Sat Nov 13 00:13:27 2021 From: james.faure at epitech.eu (james faure) Date: Sat, 13 Nov 2021 00:13:27 +0000 Subject: [Haskell-cafe] clz / bsr functions on Integer Message-ID: Why is there no `countLeadingZeros` function for Integer? This seems particularly strange because gmp provides mp_bitcnt_t mpz_scan0 (const mpz_t op, mp_bitcnt_t starting_bit) More importantly, what is the recommended way to access it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dj112358 at outlook.com Sat Nov 13 11:03:48 2021 From: dj112358 at outlook.com (David James) Date: Sat, 13 Nov 2021 11:03:48 +0000 Subject: [Haskell-cafe] clz / bsr functions on Integer In-Reply-To: References: Message-ID: Hi – there is a countLeadingZeros function. It applies to instances of FiniteBits, such as Int (a fixed bit-size integer): GHCi, version 8.10.7: https://www.haskell.org/ghc/ :? for help Loaded package environment from C:\Users\David\AppData\Roaming\ghc\x86_64-mingw32-8.10.7\environments\default > :m +Data.Bits > countLeadingZeros (23 :: Int) 59 > The Integer type represents unbounded integers, so countLeadingZeros doesn’t really make sense. (ps. you can seach for functions like countLeadingZeros on Hoogle). Hope that helps, David. From: james faure Sent: 13 November 2021 00:16 To: haskell-cafe at haskell.org Subject: [Haskell-cafe] clz / bsr functions on Integer Why is there no `countLeadingZeros` function for Integer? This seems particularly strange because gmp provides mp_bitcnt_t mpz_scan0 (const mpz_t op, mp_bitcnt_t starting_bit) More importantly, what is the recommended way to access it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From claude at mathr.co.uk Sat Nov 13 11:08:10 2021 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Sat, 13 Nov 2021 11:08:10 +0000 Subject: [Haskell-cafe] clz / bsr functions on Integer In-Reply-To: References: Message-ID: Hi, On 13/11/2021 00:13, james faure wrote: > Why is there no `countLeadingZeros` function for Integer? This seems > particularly strange because gmp provides > /mp_bitcnt_t/*mpz_scan0*/(const mpz_top, mp_bitcnt_tstarting_bit)/ Integer is not always implemented with GMP. > More importantly, what is the recommended way to access it? If you do have an Integer implemented with GMP (the default case with GHC), you can use one of https://hackage.haskell.org/package/hgmp-0.1.2/docs/Numeric-GMP-Raw-Safe.html#v:mpz_scan0 https://hackage.haskell.org/package/hgmp-0.1.2/docs/Numeric-GMP-Raw-Unsafe.html#v:mpz_scan0 together with https://hackage.haskell.org/package/hgmp-0.1.2/docs/Numeric-GMP-Utils.html#v:withInInteger See the example at the top of that module page. Claude -- https://mathr.co.uk From svenpanne at gmail.com Sat Nov 13 12:02:47 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 13 Nov 2021 13:02:47 +0100 Subject: [Haskell-cafe] haskell-ci problems Message-ID: I am (finally) about to switch my Haskell projects on GitHub from Travis CI to GitHub Actions, so I've tried haskell-ci (from HEAD) for creating the workflow files from the .cabal files. But something went wrong, see https://github.com/haskell-opengl/StateVar/actions/runs/1456427818/workflow Initially, I thought that this failure was related to using the latest and greatest GHC version, so I removed that, but the failure stays: https://github.com/haskell-opengl/StateVar/actions/runs/1456437461/workflow Any hints on what I'm doing wrong? Or is it a haskell-ci bug? Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Nov 13 12:26:47 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 13 Nov 2021 07:26:47 -0500 Subject: [Haskell-cafe] clz / bsr functions on Integer In-Reply-To: References: Message-ID: "Default case" is part of the problem. The ghc developers are working on having hot-swappable Integer implementations (right now you have to build the compiler with a specific Integer backend); what happens to `countLeadingZeros` in that case? On Sat, Nov 13, 2021 at 6:15 AM Claude Heiland-Allen wrote: > > Hi, > > On 13/11/2021 00:13, james faure wrote: > > Why is there no `countLeadingZeros` function for Integer? This seems > > particularly strange because gmp provides > > /mp_bitcnt_t/*mpz_scan0*/(const mpz_top, mp_bitcnt_tstarting_bit)/ > Integer is not always implemented with GMP. > > > More importantly, what is the recommended way to access it? > If you do have an Integer implemented with GMP (the default case with > GHC), you can use one of > > https://hackage.haskell.org/package/hgmp-0.1.2/docs/Numeric-GMP-Raw-Safe.html#v:mpz_scan0 > https://hackage.haskell.org/package/hgmp-0.1.2/docs/Numeric-GMP-Raw-Unsafe.html#v:mpz_scan0 > > together with > > https://hackage.haskell.org/package/hgmp-0.1.2/docs/Numeric-GMP-Utils.html#v:withInInteger > > See the example at the top of that module page. > > > Claude > -- > https://mathr.co.uk > > _______________________________________________ > 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 mikolaj at well-typed.com Sat Nov 13 12:27:08 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 13 Nov 2021 13:27:08 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: Hi Sven, Not sure about this particular error, but haskell-ci does not yet seem fully updated to the travis/GHA switch and Ubuntu repo/gchup switch. In particular, there is no Ubuntu package for GHC 9.2.1 that you are requesting and there may never be. I'd advise to use ghcup instead. There are at least some examples about that in haskell-ci repo (IIRC, at least the haskell-ci CI job itself), even if the script is not up to the task. Contributions welcome. Cheers, Mikolaj On Sat, Nov 13, 2021 at 1:04 PM Sven Panne wrote: > > I am (finally) about to switch my Haskell projects on GitHub from Travis CI to GitHub Actions, so I've tried haskell-ci (from HEAD) for creating the workflow files from the .cabal files. But something went wrong, see https://github.com/haskell-opengl/StateVar/actions/runs/1456427818/workflow Initially, I thought that this failure was related to using the latest and greatest GHC version, so I removed that, but the failure stays: https://github.com/haskell-opengl/StateVar/actions/runs/1456437461/workflow > > Any hints on what I'm doing wrong? Or is it a haskell-ci bug? > > Cheers, > S. > _______________________________________________ > 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 svenpanne at gmail.com Sat Nov 13 13:02:58 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 13 Nov 2021 14:02:58 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: Am Sa., 13. Nov. 2021 um 13:27 Uhr schrieb Mikolaj Konarski < mikolaj at well-typed.com>: > Not sure about this particular error, but haskell-ci does not yet seem > fully updated to the travis/GHA switch and Ubuntu repo/gchup switch. > My point is: I don't care about how the workflow gets the tools and compilers, I was just hoping to have a simple way to generate a workflow from a .cabal file. :-( Currently I am too busy with other things that I can't dive into the details of GitHub Actions, haskell-ci, etc., I can just offer testing haskell-ci patches etc. The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file. Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why? > In particular, there is no Ubuntu package for GHC 9.2.1 that you are > requesting and there may never be. That's totally OK, the workflow seems to reference hvr's PPA. And as I said: Even when I remove 9.2.1, I get the exact same error again for 9.0.1. > I'd advise to use ghcup instead. There are at least some examples about > that in haskell-ci repo (IIRC, > at least the haskell-ci CI job itself), even if the script is not up to > the task. Contributions welcome. Personally I use stack exclusively, totally ignoring cabal and ghcup. But that should be fine as long as the workflow is doing whatever it needs to do with those tools. As usual, the Haskell tool ecosystem is giving me a hard time... :´-( Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Sat Nov 13 13:39:46 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 13 Nov 2021 14:39:46 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: > I can just offer testing haskell-ci patches etc. Thank you. I'm sure other haskell-ci contributors can use this help, if they read this. In general, that's a great idea, supporting our developers in other ways than just code contributions, e.g., via general positivity, appreciation, goodwill, expressions of hope, uplifting user stories. They are bombarded with (impersonal) negativity all the time via bug reports. > The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file. I'm afraid, since hvr stopped updating the PPA images (and other things), the Haskell tool ecosystem is in the very sorry and silly state you describe. Given that at this stage it's too late to help hvr, let's make sure to support Julian with ghcup (and other things) so that our ecosystem doesn't break up again, once we port haskell-ci to ghcup (if I'm guessing correctly where haskell-ci is going). > Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why? Because it's been edited by hand for 11 months. > As usual, the Haskell tool ecosystem is giving me a hard time... :´-( I sympathise. All the best, Mikolaj From mikolaj at well-typed.com Sat Nov 13 15:05:44 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 13 Nov 2021 16:05:44 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: BTW, Sven, my sources say, running `haskell-ci 'github'` as opposed to `haskell-ci 'travis'` may give better results. On Sat, Nov 13, 2021 at 2:39 PM Mikolaj Konarski wrote: > > > I can just offer testing haskell-ci patches etc. > > Thank you. I'm sure other haskell-ci contributors can use this help, > if they read this. In general, that's a great idea, supporting our > developers in other ways than just code contributions, e.g., via > general positivity, appreciation, goodwill, expressions of hope, > uplifting user stories. They are bombarded with (impersonal) > negativity all the time via bug reports. > > > The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file. > > I'm afraid, since hvr stopped updating the PPA images (and other > things), the Haskell tool ecosystem is in the very sorry and silly > state you describe. Given that at this stage it's too late to help > hvr, let's make sure to support Julian with ghcup (and other things) > so that our ecosystem doesn't break up again, once we port haskell-ci > to ghcup (if I'm guessing correctly where haskell-ci is going). > > > Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why? > > Because it's been edited by hand for 11 months. > > > As usual, the Haskell tool ecosystem is giving me a hard time... :´-( > > I sympathise. > > All the best, > Mikolaj From simon.jakobi at googlemail.com Sat Nov 13 15:11:13 2021 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Sat, 13 Nov 2021 16:11:13 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: Hi Sven, the issue is in fact very simple. You have generated a config for Travis CI, not one for GitHub Actions! This is indicated by the command `haskell-ci travis` here: https://github.com/haskell-opengl/StateVar/actions/runs/1456427818/workflow#L3 In order to generate a GHA config, you should use the command `haskell-ci github`. If you need any further help, I recommend that you use the haskell-ci issue tracker: https://github.com/haskell-CI/haskell-ci/issues Oleg and Ryan have so far been very responsive and helpful when I needed assistance. Happy CIing, Simon Am Sa., 13. Nov. 2021 um 13:03 Uhr schrieb Sven Panne : > > I am (finally) about to switch my Haskell projects on GitHub from Travis CI to GitHub Actions, so I've tried haskell-ci (from HEAD) for creating the workflow files from the .cabal files. But something went wrong, see https://github.com/haskell-opengl/StateVar/actions/runs/1456427818/workflow Initially, I thought that this failure was related to using the latest and greatest GHC version, so I removed that, but the failure stays: https://github.com/haskell-opengl/StateVar/actions/runs/1456437461/workflow > > Any hints on what I'm doing wrong? Or is it a haskell-ci bug? > > Cheers, > S. > _______________________________________________ > 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 Nov 13 15:17:21 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 13 Nov 2021 15:17:21 +0000 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: <20211113151721.GI3121@cloudinit-builder> I can confirm that this indeed works: https://github.com/tomjaguarpaw/StateVar/blob/96f55e23eedd6f7e8665eb388deb605bc393f0dd/.github/workflows/haskell-ci.yml#L3 https://github.com/tomjaguarpaw/StateVar/runs/4199126514 Tom On Sat, Nov 13, 2021 at 04:11:13PM +0100, Simon Jakobi via Haskell-Cafe wrote: > the issue is in fact very simple. You have generated a config for > Travis CI, not one for GitHub Actions! > > Am Sa., 13. Nov. 2021 um 13:03 Uhr schrieb Sven Panne : > > > > I am (finally) about to switch my Haskell projects on GitHub from > > Travis CI to GitHub Actions, so I've tried haskell-ci (from HEAD) > > for creating the workflow files from the .cabal files. But > > something went wrong, see > > https://github.com/haskell-opengl/StateVar/actions/runs/1456427818/workflow > > Initially, I thought that this failure was related to using the > > latest and greatest GHC version, so I removed that, but the > > failure stays: > > https://github.com/haskell-opengl/StateVar/actions/runs/1456437461/workflow > > > > Any hints on what I'm doing wrong? Or is it a haskell-ci bug? From mikolaj at well-typed.com Sat Nov 13 15:47:29 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 13 Nov 2021 16:47:29 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: Off-topic, would it be possible to reduce the latency of mail.haskell.org? It's quite frustrating if your message is a dupe and even more if it seems as if the other person ignored your message and wrote the stuff one again. While, in fact, the messages were 10 minutes in flight and then arrived in reverse order. On Sat, Nov 13, 2021 at 4:05 PM Mikolaj Konarski wrote: > > BTW, Sven, my sources say, running `haskell-ci 'github'` as opposed to > `haskell-ci 'travis'` may give better results. > > On Sat, Nov 13, 2021 at 2:39 PM Mikolaj Konarski wrote: > > > > > I can just offer testing haskell-ci patches etc. > > > > Thank you. I'm sure other haskell-ci contributors can use this help, > > if they read this. In general, that's a great idea, supporting our > > developers in other ways than just code contributions, e.g., via > > general positivity, appreciation, goodwill, expressions of hope, > > uplifting user stories. They are bombarded with (impersonal) > > negativity all the time via bug reports. > > > > > The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file. > > > > I'm afraid, since hvr stopped updating the PPA images (and other > > things), the Haskell tool ecosystem is in the very sorry and silly > > state you describe. Given that at this stage it's too late to help > > hvr, let's make sure to support Julian with ghcup (and other things) > > so that our ecosystem doesn't break up again, once we port haskell-ci > > to ghcup (if I'm guessing correctly where haskell-ci is going). > > > > > Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why? > > > > Because it's been edited by hand for 11 months. > > > > > As usual, the Haskell tool ecosystem is giving me a hard time... :´-( > > > > I sympathise. > > > > All the best, > > Mikolaj From simon.jakobi at googlemail.com Sat Nov 13 15:55:56 2021 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Sat, 13 Nov 2021 16:55:56 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: Huh, I think there must be something amiss between mail.haskell.org and GMail. I have not received your message from 4:05 PM at all, nor the message from Tom Ellis that I see at https://mail.haskell.org/pipermail/haskell-cafe/2021-November/134848.html. Am Sa., 13. Nov. 2021 um 16:48 Uhr schrieb Mikolaj Konarski : > > Off-topic, would it be possible to reduce the latency of mail.haskell.org? > > It's quite frustrating if your message is a dupe and even more if it > seems as if the other person ignored your message and wrote the stuff > one again. While, in fact, the messages were 10 minutes in flight and > then arrived in reverse order. > > On Sat, Nov 13, 2021 at 4:05 PM Mikolaj Konarski wrote: > > > > BTW, Sven, my sources say, running `haskell-ci 'github'` as opposed to > > `haskell-ci 'travis'` may give better results. > > > > On Sat, Nov 13, 2021 at 2:39 PM Mikolaj Konarski wrote: > > > > > > > I can just offer testing haskell-ci patches etc. > > > > > > Thank you. I'm sure other haskell-ci contributors can use this help, > > > if they read this. In general, that's a great idea, supporting our > > > developers in other ways than just code contributions, e.g., via > > > general positivity, appreciation, goodwill, expressions of hope, > > > uplifting user stories. They are bombarded with (impersonal) > > > negativity all the time via bug reports. > > > > > > > The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file. > > > > > > I'm afraid, since hvr stopped updating the PPA images (and other > > > things), the Haskell tool ecosystem is in the very sorry and silly > > > state you describe. Given that at this stage it's too late to help > > > hvr, let's make sure to support Julian with ghcup (and other things) > > > so that our ecosystem doesn't break up again, once we port haskell-ci > > > to ghcup (if I'm guessing correctly where haskell-ci is going). > > > > > > > Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why? > > > > > > Because it's been edited by hand for 11 months. > > > > > > > As usual, the Haskell tool ecosystem is giving me a hard time... :´-( > > > > > > I sympathise. > > > > > > All the best, > > > Mikolaj > _______________________________________________ > 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 svenpanne at gmail.com Sat Nov 13 16:34:59 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 13 Nov 2021 17:34:59 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: Am Sa., 13. Nov. 2021 um 16:11 Uhr schrieb Simon Jakobi < simon.jakobi at googlemail.com>: > the issue is in fact very simple. You have generated a config for Travis > CI, not one for GitHub Actions! [...] > Embarrassing... :-} Thanks for the quick help, things are looking much better now, even GHC 9.2.1 works out-of-the-box! I *did* look into the haskell-ci code to figure out how to generate a workflow instead of a Travis CI configuration, but my copy-n-paste-fu was obviously not strong enough. :-] The haskell-ci README could need some love: GitHub actions are not mentioned at all (you have to use "git log" to figure out that they are supported), OTOH Travis CI is all over the place, although it is effectively dead. Thanks to the haskell-ci team, the tool is great for lazy people like me! Just a tiny bit of documentation plus some more advertising would be great... Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From runesvend at gmail.com Sun Nov 14 11:39:35 2021 From: runesvend at gmail.com (Rune K. Svendsen) Date: Sun, 14 Nov 2021 12:39:35 +0100 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee Message-ID: Dear list, I would like to bring attention to the fact that the Haskell “Core Libraries Committee” has just accepted a breaking change to the Eq type class in exchange for very little apparent benefit. Please use this GitHub issue to voice your opinion on the issue: https://github.com/haskell/core-libraries-committee/issues/3 I don’t think it’s been sufficiently discussed yet. /Rune -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sun Nov 14 12:39:00 2021 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 14 Nov 2021 13:39:00 +0100 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: Il 14 novembre 2021 alle 12:39 Rune K. Svendsen ha scritto: > I would like to bring attention to the fact that the Haskell “Core > Libraries Committee” has just accepted a breaking change to the Eq type > class in exchange for very little apparent benefit. > > Please use this GitHub issue to voice your opinion on the issue: > https://github.com/haskell/core-libraries-committee/issues/3 > I don’t think it’s been sufficiently discussed yet. It was discussed on libraries@ [1]: [1] https://mail.haskell.org/pipermail/libraries/2021-October/031463.html From fumiexcel at gmail.com Sun Nov 14 13:57:25 2021 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Sun, 14 Nov 2021 22:57:25 +0900 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: No, please don't encourage people to storm CLC. There are a lot of objections written in various media so repeating them as individual comments in the issue does not help anyone. Instead, you could summarise the points yourself so that the participants of the discussion can understand what they agree with and what they don't. 2021年11月14日(日) 20:40 Rune K. Svendsen : > Dear list, > > I would like to bring attention to the fact that the Haskell “Core > Libraries Committee” has just accepted a breaking change to the Eq type > class in exchange for very little apparent benefit. > > Please use this GitHub issue to voice your opinion on the issue: > https://github.com/haskell/core-libraries-committee/issues/3 > I don’t think it’s been sufficiently discussed yet. > > > /Rune > _______________________________________________ > 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 Sun Nov 14 19:00:12 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 14 Nov 2021 20:00:12 +0100 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee Message-ID: For what it's worth, one of the examples listed in the issue where (/=) is not simply the negation of (==) is violating the laws. It is the one in https://hackage.haskell.org/package/numbers-3000.2.0.2/docs/Data-Number-Interval.html That module defines two intervals to be equal if their bounds are equal, but to be unequal only if they are disjoint. In my eyes this speaks for the proposal, because the library author would have been unable to write the broken instance. (And I did look at the proposal some time ago, whence I feel it was indeed discussed or at least mentioned on this list before.) Olaf From svenpanne at gmail.com Sun Nov 14 19:24:14 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 14 Nov 2021 20:24:14 +0100 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: Am So., 14. Nov. 2021 um 20:05 Uhr schrieb Olaf Klinke < olf at aatal-apotheke.de>: > That module defines two intervals to be equal if their bounds are > equal, but to be unequal only if they are disjoint. Well, this is simply a broken implementation. Quick question: Is the Ord instance lawful or not? Hard to tell... (at least without pencil & paper) > In my eyes this speaks for the proposal, because the library author would > have been > unable to write the broken instance. [...] > But this is an extremely weak argument for the proposal: One can easily write broken instances even with a single (==) method, e.g. violating symmetry etc. As another example: Given some e.g. Monad instance, can one quickly see if it is lawful? I very much doubt so, unless one tries to prove it. Laws of type classes are very much "outside of the Haskell language", anyway, so I see nothing special for Eq. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brown.m at pm.me Sun Nov 14 19:29:51 2021 From: brown.m at pm.me (Melanie Brown) Date: Sun, 14 Nov 2021 19:29:51 +0000 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: These arguments and more have already been discussed on the issue page. https://github.com/haskell/core-libraries-committee/issues/3 Cheers Melanie Brown On Sun, Nov 14, 2021 at 14:24, Sven Panne wrote: > Am So., 14. Nov. 2021 um 20:05 Uhr schrieb Olaf Klinke : > >> That module defines two intervals to be equal if their bounds are >> equal, but to be unequal only if they are disjoint. > > Well, this is simply a broken implementation. Quick question: Is the Ord instance lawful or not? Hard to tell... (at least without pencil & paper) > >> In my eyes this speaks for the proposal, because the library author would have been >> unable to write the broken instance. [...] > > But this is an extremely weak argument for the proposal: One can easily write broken instances even with a single (==) method, e.g. violating symmetry etc. As another example: Given some e.g. Monad instance, can one quickly see if it is lawful? I very much doubt so, unless one tries to prove it. Laws of type classes are very much "outside of the Haskell language", anyway, so I see nothing special for Eq. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Nov 14 19:41:13 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 14 Nov 2021 20:41:13 +0100 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: Am So., 14. Nov. 2021 um 20:35 Uhr schrieb Melanie Brown via Haskell-Cafe < haskell-cafe at haskell.org>: > These arguments and more have already been discussed on the issue page. > > https://github.com/haskell/core-libraries-committee/issues/3 > But why on earth has the proposal been accepted then? This is simply a mystery to me... -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Nov 14 19:46:46 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 14 Nov 2021 14:46:46 -0500 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: I didn't understand that either. The original discussion seemed to have concluded that there was no point to the change aside from breaking some programs, then suddenly it was proposed and accepted. I'm confused…. On Sun, Nov 14, 2021 at 2:42 PM Sven Panne wrote: > > Am So., 14. Nov. 2021 um 20:35 Uhr schrieb Melanie Brown via Haskell-Cafe : >> >> These arguments and more have already been discussed on the issue page. >> >> https://github.com/haskell/core-libraries-committee/issues/3 > > > But why on earth has the proposal been accepted then? This is simply a mystery to me... > _______________________________________________ > 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 jcb+hc at julianbradfield.org Sun Nov 14 16:52:00 2021 From: jcb+hc at julianbradfield.org (Julian Bradfield) Date: Sun, 14 Nov 2021 16:52:00 +0000 Subject: [Haskell-cafe] type checking failure curiosity Message-ID: In the course of updating a tutorial for this year's course, I found the provided code didn't compile. This is because a key value is "undefined" in order for the students to fill it in, but I'm curious why it can't be typechecked nonetheless. The code is: reachable :: (Ord q) => FSM q -> Set(Set(q)) -> Set(Set(q)) reachable fsm@(FSM qs as ts ss fs) supers = let new :: Set(Set(q)) -- typechecking fails without this declaration new = undefined in if null new then supers else reachable fsm (supers \/ new) The \/ in the last line is just Set.union. On the face of it, the last term directly forces "new" to have type Set(Set(q)), so why doesn't Haskell see that? Without the explicit type declaration of "new", we get: • Could not deduce (Foldable t0) arising from a use of ‘null’ from the context: Ord q bound by the type signature for: reachable :: forall q. Ord q => FSM q -> Set (Set q) -> Set (Set q) at CLTutorial9.hs:127:1-60 The type variable ‘t0’ is ambiguous These potential instances exist: instance Foldable (Either a) -- Defined in ‘Data.Foldable’ instance Foldable Set -- Defined in ‘Data.Set.Internal’ instance Foldable Maybe -- Defined in ‘Data.Foldable’ ...plus two others ...plus 27 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: null new In the expression: if null new then supers else reachable fsm (supers \/ new) In the expression: let new = undefined in if null new then supers else reachable fsm (supers \/ new) | 130 | in if null new then supers else reachable fsm (supers \/ new) | ^^^^^^^^ From allbery.b at gmail.com Sun Nov 14 20:01:44 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 14 Nov 2021 15:01:44 -0500 Subject: [Haskell-cafe] type checking failure curiosity In-Reply-To: References: Message-ID: At a guess, the problem here is that you need to use ScopedTypeVariables and `forall` to bring the right `q` into scope. Otherwise, `q` represents a *new* type variable unrelated to the one in the type signature for `reachable`, and of course ghc cannot reconcile that independent type variable with the requirement that it match the one in the earlier type signature. On Sun, Nov 14, 2021 at 2:58 PM Julian Bradfield wrote: > > In the course of updating a tutorial for this year's course, I found > the provided code didn't compile. This is because a key value is > "undefined" in order for the students to fill it in, but I'm curious > why it can't be typechecked nonetheless. > > The code is: > > reachable :: (Ord q) => FSM q -> Set(Set(q)) -> Set(Set(q)) > reachable fsm@(FSM qs as ts ss fs) supers = > let new :: Set(Set(q)) -- typechecking fails without this declaration > new = undefined > in if null new then supers else reachable fsm (supers \/ new) > > The \/ in the last line is just Set.union. > > On the face of it, the last term directly forces "new" to have type > Set(Set(q)), so why doesn't Haskell see that? > > Without the explicit type declaration of "new", we get: > > • Could not deduce (Foldable t0) arising from a use of ‘null’ > from the context: Ord q > bound by the type signature for: > reachable :: forall q. Ord q => FSM q -> Set (Set q) -> Set (Set q) > at CLTutorial9.hs:127:1-60 > The type variable ‘t0’ is ambiguous > These potential instances exist: > instance Foldable (Either a) -- Defined in ‘Data.Foldable’ > instance Foldable Set -- Defined in ‘Data.Set.Internal’ > instance Foldable Maybe -- Defined in ‘Data.Foldable’ > ...plus two others > ...plus 27 instances involving out-of-scope types > (use -fprint-potential-instances to see them all) > • In the expression: null new > In the expression: > if null new then supers else reachable fsm (supers \/ new) > In the expression: > let new = undefined > in if null new then supers else reachable fsm (supers \/ new) > | > 130 | in if null new then supers else reachable fsm (supers \/ new) > | ^^^^^^^^ > _______________________________________________ > 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 olf at aatal-apotheke.de Sun Nov 14 20:07:45 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 14 Nov 2021 21:07:45 +0100 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: On Sun, 2021-11-14 at 20:24 +0100, Sven Panne wrote: > Am So., 14. Nov. 2021 um 20:05 Uhr schrieb Olaf Klinke < > olf at aatal-apotheke.de>: > > > That module defines two intervals to be equal if their bounds are > > equal, but to be unequal only if they are disjoint. > > Well, this is simply a broken implementation. Quick question: Is the Ord > instance lawful or not? Hard to tell... (at least without pencil & paper) > No, it's not. All four relations (>), (>=), (<), (<=) are transitive, but (>=) and (<=) should be reflexive, which they aren't: let i = I 0 1 :: Interval Int in i <= i = 1 <= 0 = False Comparability fails as well, which is why the author did not implement `compare`: j = I 0 2 :: Interval Int k = I 1 3 :: Interval Int (j <= k) || (k <= j) = (2 <= 1) || (3 <= 0) = False || False = False Antisymmetry is particularly interesting: It holds, but only for singleton intervals. > > > In my eyes this speaks for the proposal, because the library author would > > have been > > unable to write the broken instance. [...] > > > > But this is an extremely weak argument for the proposal: One can easily > write broken instances even with a single (==) method, e.g. violating > symmetry etc. As another example: Given some e.g. Monad instance, can one > quickly see if it is lawful? I very much doubt so, unless one tries to > prove it. Laws of type classes are very much "outside of the Haskell > language", anyway, so I see nothing special for Eq. Indeed in general one can't tell whether a monad instance is lawful (Rice's theorem applies), but a least the class methods aren't trivially redundant. That removes one possible source of non-lawful- ness. Olaf From lemming at henning-thielemann.de Sun Nov 14 23:15:21 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 15 Nov 2021 00:15:21 +0100 (CET) Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: On Sun, 14 Nov 2021, Rune K. Svendsen wrote: > Dear list, > I would like to bring attention to the fact that the Haskell “Core Libraries Committee” has just accepted a breaking change to the > Eq type class in exchange for very little apparent benefit. > Please use this GitHub issue to voice your opinion on the issue: https://github.com/haskell/core-libraries-committee/issues/3 > I don’t think it’s been sufficiently discussed yet. Just an idea: Maybe it would be possible to not remove (/=) but deprecate implementations of (/=) but continue to permit usage of (/=). Depends on what you want to achieve with the proposal. From compl.yue at icloud.com Mon Nov 15 11:10:53 2021 From: compl.yue at icloud.com (YueCompl) Date: Mon, 15 Nov 2021 19:10:53 +0800 Subject: [Haskell-cafe] About adding msync and anonymous mapping (virtual allocation) API to mmap package Message-ID: <517F629D-3C29-4491-B7B8-64657FAB6D1D@icloud.com> Dear Gracjan Polak, and Cafe for wider attention, I'm using the great [mmap](https://hackage.haskell.org/package/mmap ) package, and now I need 2 more features closely related to its existing features: - API to perform `msync` so as for: - A long running process to checkpoint the persistence of modifications - Parallel readers to see other writer's modification with cache coherence, i.e. invalidate cache as notified - API to do anonymous mmap-ping for volatile (virtual) memory allocation I expect the coding work to be trivial and intend to do it myself, however it's better to ask your opinion meanwhile I experiment with the ideas. Would you like to accept such features into [mmap] package? How do you think about details of such features? For the background of my needs: I'm working on a shared immutable heap implementation, persistency will be provided by disk backed storage servers, parallel work horse servers will build heap contents in rather coarse grained fashion, first as volatile heaps in one's private memory, then publish into shared storage with bulk writing, so all servers will be able to mmap such public heaps into their own memory address space, with kernel pages as cache shared by all processes on a same physical node. I hope it's okay to ask in the Cafe list at the same time, as I also anticipate more feedbacks/opinions from the list with broader expertise, will much appreciate! Thanks with best regards, Compl -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.l2ll at gmail.com Mon Nov 15 12:37:24 2021 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Mon, 15 Nov 2021 14:37:24 +0200 Subject: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee In-Reply-To: References: Message-ID: The first post lists plenty of reasonable (IMO) points to why remove `/=`, so seems like a good proposal. On Sun, Nov 14, 2021 at 9:48 PM Brandon Allbery wrote: > I didn't understand that either. The original discussion seemed to > have concluded that there was no point to the change aside from > breaking some programs, then suddenly it was proposed and accepted. > I'm confused…. > > On Sun, Nov 14, 2021 at 2:42 PM Sven Panne wrote: > > > > Am So., 14. Nov. 2021 um 20:35 Uhr schrieb Melanie Brown via > Haskell-Cafe : > >> > >> These arguments and more have already been discussed on the issue page. > >> > >> https://github.com/haskell/core-libraries-committee/issues/3 > > > > > > But why on earth has the proposal been accepted then? This is simply a > mystery to me... > > _______________________________________________ > > 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. -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Tue Nov 16 02:25:54 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 16 Nov 2021 02:25:54 +0000 Subject: [Haskell-cafe] type checking failure curiosity In-Reply-To: References: Message-ID: <010f017d2690aa86-d854c39b-ca3a-444a-8056-5ec9e6d07042-000000@us-east-2.amazonses.com> My guess is that you've disabled the monomorphism restriction somehow... but you need the MR to type-check this code. Without the MR, `new` gets a type `forall a. a`, which gets specialized differently in `new`'s two occurrences, meaning that the type information from the second occurrence doesn't affect the first one... which you need it to in order to type-check the `null new` call. I coincidentally ran into this same issue elsewhere today. I think we need to do a better job around error messages in this case. Richard > On Nov 14, 2021, at 11:52 AM, Julian Bradfield wrote: > > In the course of updating a tutorial for this year's course, I found > the provided code didn't compile. This is because a key value is > "undefined" in order for the students to fill it in, but I'm curious > why it can't be typechecked nonetheless. > > The code is: > > reachable :: (Ord q) => FSM q -> Set(Set(q)) -> Set(Set(q)) > reachable fsm@(FSM qs as ts ss fs) supers = > let new :: Set(Set(q)) -- typechecking fails without this declaration > new = undefined > in if null new then supers else reachable fsm (supers \/ new) > > The \/ in the last line is just Set.union. > > On the face of it, the last term directly forces "new" to have type > Set(Set(q)), so why doesn't Haskell see that? > > Without the explicit type declaration of "new", we get: > > • Could not deduce (Foldable t0) arising from a use of ‘null’ > from the context: Ord q > bound by the type signature for: > reachable :: forall q. Ord q => FSM q -> Set (Set q) -> Set (Set q) > at CLTutorial9.hs:127:1-60 > The type variable ‘t0’ is ambiguous > These potential instances exist: > instance Foldable (Either a) -- Defined in ‘Data.Foldable’ > instance Foldable Set -- Defined in ‘Data.Set.Internal’ > instance Foldable Maybe -- Defined in ‘Data.Foldable’ > ...plus two others > ...plus 27 instances involving out-of-scope types > (use -fprint-potential-instances to see them all) > • In the expression: null new > In the expression: > if null new then supers else reachable fsm (supers \/ new) > In the expression: > let new = undefined > in if null new then supers else reachable fsm (supers \/ new) > | > 130 | in if null new then supers else reachable fsm (supers \/ new) > | ^^^^^^^^ > _______________________________________________ > 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 mikolaj at well-typed.com Tue Nov 16 10:02:53 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Tue, 16 Nov 2021 11:02:53 +0100 Subject: [Haskell-cafe] haskell-ci problems In-Reply-To: References: Message-ID: > I have not received your message from 4:05 PM at all, nor the message > from Tom Ellis that I see at Apparently avoiding both spam and lost emails is impossible nowadays, but I'm told the situation should improve after a recent upgrade, update of a SPF record for one of mail.haskell.org servers and gradually while our servers are regaining reputation. For all of us on the list: let's not assume somebody that is repeating our point has seen our email --- it may have been lost or withheld for a time. Makes sense to ask for confirmation and also try to join divergent threads of the same email discussion (if the topic did not diverge). On Sat, Nov 13, 2021 at 4:56 PM Simon Jakobi wrote: > > Huh, I think there must be something amiss between mail.haskell.org and GMail. > > I have not received your message from 4:05 PM at all, nor the message > from Tom Ellis that I see at > https://mail.haskell.org/pipermail/haskell-cafe/2021-November/134848.html. > > Am Sa., 13. Nov. 2021 um 16:48 Uhr schrieb Mikolaj Konarski > : > > > > Off-topic, would it be possible to reduce the latency of mail.haskell.org? > > > > It's quite frustrating if your message is a dupe and even more if it > > seems as if the other person ignored your message and wrote the stuff > > one again. While, in fact, the messages were 10 minutes in flight and > > then arrived in reverse order. > > > > On Sat, Nov 13, 2021 at 4:05 PM Mikolaj Konarski wrote: > > > > > > BTW, Sven, my sources say, running `haskell-ci 'github'` as opposed to > > > `haskell-ci 'travis'` may give better results. > > > > > > On Sat, Nov 13, 2021 at 2:39 PM Mikolaj Konarski wrote: > > > > > > > > > I can just offer testing haskell-ci patches etc. > > > > > > > > Thank you. I'm sure other haskell-ci contributors can use this help, > > > > if they read this. In general, that's a great idea, supporting our > > > > developers in other ways than just code contributions, e.g., via > > > > general positivity, appreciation, goodwill, expressions of hope, > > > > uplifting user stories. They are bombarded with (impersonal) > > > > negativity all the time via bug reports. > > > > > > > > > The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file. > > > > > > > > I'm afraid, since hvr stopped updating the PPA images (and other > > > > things), the Haskell tool ecosystem is in the very sorry and silly > > > > state you describe. Given that at this stage it's too late to help > > > > hvr, let's make sure to support Julian with ghcup (and other things) > > > > so that our ecosystem doesn't break up again, once we port haskell-ci > > > > to ghcup (if I'm guessing correctly where haskell-ci is going). > > > > > > > > > Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why? > > > > > > > > Because it's been edited by hand for 11 months. > > > > > > > > > As usual, the Haskell tool ecosystem is giving me a hard time... :´-( > > > > > > > > I sympathise. > > > > > > > > All the best, > > > > Mikolaj > > _______________________________________________ > > 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 jcb+hc at julianbradfield.org Tue Nov 16 12:44:47 2021 From: jcb+hc at julianbradfield.org (Julian Bradfield) Date: Tue, 16 Nov 2021 12:44:47 +0000 Subject: [Haskell-cafe] type checking failure curiosity In-Reply-To: <010f017d2690aa86-d854c39b-ca3a-444a-8056-5ec9e6d07042-000000@us-east-2.amazonses.com> References: <010f017d2690aa86-d854c39b-ca3a-444a-8056-5ec9e6d07042-000000@us-east-2.amazonses.com> Message-ID: <24979.42943.741641.792197@zagreb.inf.ed.ac.uk> >My guess is that you've disabled the monomorphism restriction somehow... but you need the MR to type-check this code. Without the MR, `new` gets a type `forall a. a`, which gets specialized differently in `new`'s two occurrences, meaning that the type information from the second occurrence doesn't affect the first one... which you need it to in order to type-check the `null new` call. Hm. I see the MR is off at the command prompt by default, but on in compiled modules. The offending code was in a module starting: module CLTutorial9 where import Prelude hiding (lookup) import Data.Set(Set, insert, empty, member, fromList, toList, union,intersection, size, singleton, (\\)) import qualified Data.Set as S import Test.QuickCheck import Data.Char I haven't knowingly done any thing to turn off the MR. From frederic-emmanuel.picca at synchrotron-soleil.fr Tue Nov 16 12:54:36 2021 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Tue, 16 Nov 2021 12:54:36 +0000 Subject: [Haskell-cafe] ContT and MonadSafe Message-ID: Hello, I have some code like this data Hdf5Path sh e = H5RootPath (Hdf5Path sh e) | H5GroupPath ByteString (Hdf5Path sh e) | H5GroupAtPath Int (Hdf5Path sh e) | H5DatasetPath ByteString | H5DatasetPathAttr (ByteString, ByteString) | H5Or (Hdf5Path sh e) (Hdf5Path sh e) deriving (Show) Then I implement this kind of method withHdf5PathP :: (MonadSafe m, Location l) => l -> Hdf5Path sh e -> (Dataset -> m r) -> m r withHdf5PathP loc (H5RootPath subpath) f = withHdf5PathP loc subpath f withHdf5PathP loc (H5GroupPath n subpath) f = withGroupP (openGroup loc n Nothing) $ \g -> withHdf5PathP g subpath f withHdf5PathP loc (H5GroupAtPath i subpath) f = withGroupAtP loc i $ \g -> withHdf5PathP g subpath f withHdf5PathP loc (H5DatasetPath n) f = withDatasetP (openDataset' loc n Nothing) f withHdf5PathP loc (H5DatasetPathAttr (a, c)) f = withDatasetP (openDatasetWithAttr loc a c) f withHdf5PathP loc (H5Or l r) f = withHdf5PathP loc l f `catchAll` const (withHdf5PathP loc r f) I decided to switch to the ContT transfomer and try to implement this like this withHdf5PathP :: (MonadSafe m, Location l) => l -> Hdf5Path sh e -> ContT r m Dataset withHdf5PathP loc (H5RootPath subpath) = withHdf5PathP loc subpath withHdf5PathP loc (H5GroupPath n subpath) = do g <- withGroupP (openGroup loc n Nothing) withHdf5PathP g subpath withHdf5PathP loc (H5GroupAtPath i subpath) = do g <- withGroupAtP loc i withHdf5PathP g subpath withHdf5PathP loc (H5DatasetPath n) = withDatasetP (openDataset' loc n Nothing) withHdf5PathP loc (H5DatasetPathAttr (a, c)) = withDatasetP (openDatasetWithAttr loc a c) withHdf5PathP loc (H5Or l r) = ??? during the process, I also changed all the withXXX method to use Continuation. -bracket' :: MonadSafe m => (a -> IO ()) -> IO a -> (a -> m r) -> m r -bracket' r a = bracket (liftIO a) (liftIO . r) +bracket' :: MonadSafe m => (a -> IO ()) -> IO a -> ContT r m a +bracket' r a = ContT (bracket (liftIO a) (liftIO . r)) -withBytes :: MonadSafe m => Int -> (ForeignPtr a -> m r) -> m r +withBytes :: MonadSafe m => Int -> ContT r m (ForeignPtr a) withBytes n = bracket' touchForeignPtr (mallocForeignPtrBytes n) -withFileP :: MonadSafe m => IO File -> (File -> m r) -> m r +withFileP :: MonadSafe m => IO File -> ContT r m File withFileP = bracket' closeFile -withGroupP :: MonadSafe m => IO Group -> (Group -> m r) -> m r +withGroupP :: MonadSafe m => IO Group -> ContT r m Group withGroupP = bracket' closeGroup -withGroupAtP :: (Location l, MonadSafe m) => l -> Int -> (Group -> m r) -> m r -withGroupAtP l i f = do +withGroupAtP :: (Location l, MonadSafe m) => l -> Int -> ContT r m Group +withGroupAtP l i = do es <- liftIO $ nxEntries' l - withGroupP (openGroup l (es !! i) Nothing) f + withGroupP (openGroup l (es !! i) Nothing) -withDatasetP :: MonadSafe m => IO Dataset -> (Dataset -> m r) -> m r +withDatasetP :: MonadSafe m => IO Dataset -> ContT r m Dataset withDatasetP = bracket' closeDataset -withDataspaceP :: MonadSafe m => IO Dataspace -> (Dataspace -> m r) -> m r +withDataspaceP :: MonadSafe m => IO Dataspace -> ContT r m Dataspace withDataspaceP = bracket' closeDataspace The H5Or is a sort of Alternative which try to extract the info from l and if any exception is triggered switch to the right part r. Would you be so kind to help me write the H5Or part with the continuation. I am not sure that I understand all the ContT arcanes. thanks for your help Frederic From frederic-emmanuel.picca at synchrotron-soleil.fr Tue Nov 16 14:45:14 2021 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Tue, 16 Nov 2021 14:45:14 +0000 Subject: [Haskell-cafe] ContT and MonadSafe In-Reply-To: References: Message-ID: I end up with this but I do not know if this is the best solution. withHdf5PathP loc (H5Or l r) = ContT $ \cont -> (runContT (withHdf5PathP loc l) cont) `catchAll` const (runContT (withHdf5PathP loc r) cont) From compl.yue at gmail.com Tue Nov 16 14:57:04 2021 From: compl.yue at gmail.com (Compl Yue) Date: Tue, 16 Nov 2021 22:57:04 +0800 Subject: [Haskell-cafe] ContT and MonadSafe In-Reply-To: References: Message-ID: <9197254A-C8C7-4ADB-A174-66017DBE2BCA@gmail.com> I would suggest that continuations don't even belong to the "structured programming" camp, while exceptions are well structured in this regard, so I doubt they can mix well. But continuation is powerful enough to implement exception throwing/catching, so maybe it's just the existing synchronous, `IO` based exceptions don't cooperate well, you may be able to get well with your own implementation of try/catch/bracket with continuations there. > On 2021-11-16, at 22:45, PICCA Frederic-Emmanuel wrote: > > I end up with this but I do not know if this is the best solution. > > withHdf5PathP loc (H5Or l r) = ContT $ \cont -> (runContT (withHdf5PathP loc l) cont) > `catchAll` > const (runContT (withHdf5PathP loc r) cont) > _______________________________________________ > 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 lists at richarde.dev Tue Nov 16 16:26:27 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 16 Nov 2021 16:26:27 +0000 Subject: [Haskell-cafe] type checking failure curiosity In-Reply-To: <24979.42943.741641.792197@zagreb.inf.ed.ac.uk> References: <010f017d2690aa86-d854c39b-ca3a-444a-8056-5ec9e6d07042-000000@us-east-2.amazonses.com> <24979.42943.741641.792197@zagreb.inf.ed.ac.uk> Message-ID: <010f017d29923561-7f75d3fa-7af2-4bb5-9050-9a420ffd8a74-000000@us-east-2.amazonses.com> Perhaps you're right -- the monomorphism restriction wouldn't fire there, because there's no constraint to monomorphise. Instead, you just want a monomorphic `new`.... but I see no easy way (other than a type signature) to get this. Think of it this way: without the type annotation, you've said `let new = undefined in ...`. Now, replace `new` with `undefined` everywhere you've written `new`. Your code will include `null undefined`, which is indeed irresolvably ambiguous. Richard > On Nov 16, 2021, at 7:44 AM, Julian Bradfield wrote: > >> My guess is that you've disabled the monomorphism restriction somehow... but you need the MR to type-check this code. Without the MR, `new` gets a type `forall a. a`, which gets specialized differently in `new`'s two occurrences, meaning that the type information from the second occurrence doesn't affect the first one... which you need it to in order to type-check the `null new` call. > > Hm. I see the MR is off at the command prompt by default, but on in > compiled modules. The offending code was in a module starting: > > module CLTutorial9 where > import Prelude hiding (lookup) > import Data.Set(Set, insert, empty, member, fromList, toList, > union,intersection, size, singleton, (\\)) > import qualified Data.Set as S > import Test.QuickCheck > import Data.Char > > > I haven't knowingly done any thing to turn off the MR. From guthrie at miu.edu Wed Nov 17 14:34:34 2021 From: guthrie at miu.edu (Gregory Guthrie) Date: Wed, 17 Nov 2021 14:34:34 +0000 Subject: [Haskell-cafe] code in postings mangled? Message-ID: Why is code in postings so often mangled: Subject: [Haskell-cafe] ContT and MonadSafe ... Then I implement this kind of method withHdf5PathP :: (MonadSafe m, Location l) => l -> Hdf5Path sh e -> (Dataset -> m r) -> m r withHdf5PathP loc (H5RootPath subpath) f = withHdf5PathP loc subpath f withHdf5PathP loc (H5GroupPath n subpath) f = withGroupP (openGroup loc n Nothing) $ \g -> withHdf5PathP g subpath f withHdf5PathP loc (H5GroupAtPath i subpath) f = withGroupAtP loc i $ \g -> withHdf5PathP g subpath f withHdf5PathP loc (H5DatasetPath n) f = withDatasetP (openDataset' loc n Nothing) f withHdf5PathP loc (H5DatasetPathAttr (a, c)) f = withDatasetP (openDatasetWithAttr loc a c) f withHdf5PathP loc (H5Or l r) f = withHdf5PathP loc l f `catchAll` const (withHdf5PathP loc r f) I decided to switch to the ContT transfomer and try to implement this like this withHdf5PathP :: (MonadSafe m, Location l) => l -> Hdf5Path sh e -> ContT r m Dataset withHdf5PathP loc (H5RootPath subpath) = withHdf5PathP loc subpath withHdf5PathP loc (H5GroupPath n subpath) = do g <- withGroupP (openGroup loc n Nothing) withHdf5PathP g subpath withHdf5PathP loc (H5GroupAtPath i subpath) = do g <- withGroupAtP loc i withHdf5PathP g subpath withHdf5PathP loc (H5DatasetPath n) = withDatasetP (openDataset' loc n Nothing) withHdf5PathP loc (H5DatasetPathAttr (a, c)) = withDatasetP (openDatasetWithAttr loc a c) withHdf5PathP loc (H5Or l r) = ??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From branimir.maksimovic at gmail.com Wed Nov 17 14:47:30 2021 From: branimir.maksimovic at gmail.com (Branimir Maksimovic) Date: Wed, 17 Nov 2021 15:47:30 +0100 Subject: [Haskell-cafe] code in postings mangled? In-Reply-To: References: Message-ID: <1E90B83D-E6CD-4593-A17C-05C646D500CE@gmail.com> your mail client+learn to hit enter. Greets, Branimir > On 17.11.2021., at 15:34, Gregory Guthrie wrote: > > Why is code in postings so often mangled: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgbm at acm.org Thu Nov 18 03:27:52 2021 From: jgbm at acm.org (J. Garrett Morris) Date: Wed, 17 Nov 2021 21:27:52 -0600 Subject: [Haskell-cafe] type checking failure curiosity In-Reply-To: <010f017d29923561-7f75d3fa-7af2-4bb5-9050-9a420ffd8a74-000000@us-east-2.amazonses.com> References: <010f017d2690aa86-d854c39b-ca3a-444a-8056-5ec9e6d07042-000000@us-east-2.amazonses.com> <24979.42943.741641.792197@zagreb.inf.ed.ac.uk> <010f017d29923561-7f75d3fa-7af2-4bb5-9050-9a420ffd8a74-000000@us-east-2.amazonses.com> Message-ID: I suspect that if `null` still had type `[t] -> Bool`, Julian's code would compile. /g On Tue, Nov 16, 2021 at 10:27 AM Richard Eisenberg wrote: > Perhaps you're right -- the monomorphism restriction wouldn't fire there, > because there's no constraint to monomorphise. Instead, you just want a > monomorphic `new`.... but I see no easy way (other than a type signature) > to get this. > > Think of it this way: without the type annotation, you've said `let new = > undefined in ...`. Now, replace `new` with `undefined` everywhere you've > written `new`. Your code will include `null undefined`, which is indeed > irresolvably ambiguous. > > Richard > > > On Nov 16, 2021, at 7:44 AM, Julian Bradfield < > jcb+hc at julianbradfield.org> wrote: > > > >> My guess is that you've disabled the monomorphism restriction > somehow... but you need the MR to type-check this code. Without the MR, > `new` gets a type `forall a. a`, which gets specialized differently in > `new`'s two occurrences, meaning that the type information from the second > occurrence doesn't affect the first one... which you need it to in order to > type-check the `null new` call. > > > > Hm. I see the MR is off at the command prompt by default, but on in > > compiled modules. The offending code was in a module starting: > > > > module CLTutorial9 where > > import Prelude hiding (lookup) > > import Data.Set(Set, insert, empty, member, fromList, toList, > > union,intersection, size, singleton, (\\)) > > import qualified Data.Set as S > > import Test.QuickCheck > > import Data.Char > > > > > > I haven't knowingly done any thing to turn off the MR. > > _______________________________________________ > 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. -- Prosperum ac felix scelus virtus vocatur -- Seneca -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Thu Nov 18 03:42:07 2021 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 17 Nov 2021 19:42:07 -0800 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.1 now available In-Reply-To: <87lf2bu98a.fsf@smart-cactus.org> References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: It seems the OS X distribution is missing profiling libs, details at https://gitlab.haskell.org/ghc/ghc/-/issues/20707 but that's basically the whole story :) From olf at aatal-apotheke.de Thu Nov 18 16:49:40 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 18 Nov 2021 17:49:40 +0100 Subject: [Haskell-cafe] code in postings mangled? Message-ID: <1862d57105802beb1048b76a084ec79c2d901ef8.camel@aatal-apotheke.de> > Why is code in postings so often mangled: > Seems it is only the linebreaks. Some programs on Windows, including TextEdit and likely your mail client, don't consider a newline '\n' character to be a line break, since Windows terminates lines by "\r\n". Then OS X has '\r' line terminators, which again might not be considered a linebreak on some systems. I remember all kinds of stupid things arising from this, including version control systems flagging every line as changed when it was only the line breaks. I read this list as digest, so I can not verify using the particular raw email you quoted. Can someone else check this? Regards, Olaf From emilypi at cohomolo.gy Fri Nov 19 00:37:37 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Fri, 19 Nov 2021 00:37:37 +0000 Subject: [Haskell-cafe] [ANN] Release candidate for `mtl-2.3` Message-ID: Hello all, Chessai and I are excited to announce a release candidate for `mtl`: [`mtl-2.3-rc3`]( https://github.com/haskell/mtl/releases/tag/v2.3-rc3 )! ## Timeline The timeline for release will be as follows: - This announcement marks the start of the timeline - We will give 2 weeks of testing before considering release - If no major issues are filed before then, `mtl-2.3-rc3` will be released as `mtl-2.3`, and if issues are found, they will be amended, and a new release candidate will be announced, resetting the 2 week period. To test `mtl-2.3-rc3` for yourself, please feel free to add the following to your `cabal.project`: ``` source-repository-package type: git location: https://github.com/haskell/mtl.git tag: 5d0f62b8007bb96e49f36a5544741cfe96a97130 ``` or, if you're a stack user add this entry to your `extra-deps`: ``` - git: https://github.com/haskell/mtl.git commit: 5d0f62b8007bb96e49f36a5544741cfe96a97130 ``` And make sure to adjust all bounds/`allow-newer` accordingly. Please note that this release of `mtl` is a full major version release, and *will be the last of the 2.x series before work begins on updating the mtl class hierarchy*. ## Changelog * Add instances for `Control.Monad.Trans.Writer.CPS` and `Control.Monad.Trans.RWS.CPS` from `transformers` 0.5.6 and add `Control.Monad.Writer.CPS` and `Control.Monad.RWS.CPS`. * `Control.Monad.Cont` now re-exports `evalCont` and `evalContT` * Add `tryError`, `withError`, `handleError`, and `mapError` to `Control.Monad.Error.Class`, and re-export from `Control.Monad.Except`. * Remove `Control.Monad.List` and `Control.Monad.Error` * Remove instances of deprecated `ListT` and `ErrorT` * Remove re-exports of `Error` * Add instances for `Control.Monad.Trans.Accum` and ` Control.Monad.Trans.Select ( http://control.monad.trans.select/ ) ` * Remove re-exports of `Control.Monad`, `Control.Monad.Fix` and `Data.Monoid` modules I'd like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! Happy hacking! Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From godzbanebane at gmail.com Fri Nov 19 09:24:39 2021 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Fri, 19 Nov 2021 11:24:39 +0200 Subject: [Haskell-cafe] Partial record access Message-ID: Hey Cafe, With the advent of RecordDotSyntax (or more precisely OverloadedRecordDot?) in 9.2, I was expecting this wart to be fixed: data Ty = X {x :: String} | Y {y :: Int} > y $ X "lol" *** Exception: No match in record selector y As it seems like the perfect opportunity to introduce a breaking change for a behaviour that is usually undesirable (in my experience). But instead: > :set -XOverloadedRecordDot > (X "lol").y *** Exception: No match in record selector y Unfortunately, I couldn't follow and/or remember all of the discussion around RecordDotSyntax, so this might be something I missed. Is there a reason why we don't generate HasField x r a only when all of the constructors for r have a field "x" :: a? If not, is the community open to changing this, while the new extension is still ripe? Cheers! ======= Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Fri Nov 19 09:59:14 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 19 Nov 2021 09:59:14 +0000 Subject: [Haskell-cafe] Partial record access In-Reply-To: References: Message-ID: <20211119095914.GF911@cloudinit-builder> On Fri, Nov 19, 2021 at 11:24:39AM +0200, Georgi Lyubenov wrote: > Is there a reason why we don't generate HasField x r a only when all of the > constructors for r have a field "x" :: a? If not, is the community open to > changing this, while the new extension is still ripe? Let's change it please! Partial record fields are a massive wart which we shouldn't perpetuate into related features. From godzbanebane at gmail.com Fri Nov 19 10:05:35 2021 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Fri, 19 Nov 2021 12:05:35 +0200 Subject: [Haskell-cafe] Partial record access In-Reply-To: <20211119095914.GF911@cloudinit-builder> References: <20211119095914.GF911@cloudinit-builder> Message-ID: I also made a discussion on the ghc-proposals discussions page, since it seemed like an appropriate place for this kind of thing - https://github.com/ghc-proposals/ghc-proposals/discussions/459 On Fri, Nov 19, 2021 at 11:59 AM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > On Fri, Nov 19, 2021 at 11:24:39AM +0200, Georgi Lyubenov wrote: > > Is there a reason why we don't generate HasField x r a only when all of > the > > constructors for r have a field "x" :: a? If not, is the community open > to > > changing this, while the new extension is still ripe? > > Let's change it please! Partial record fields are a massive wart > which we shouldn't perpetuate into related features. > _______________________________________________ > 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 jo at durchholz.org Fri Nov 19 13:54:04 2021 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 19 Nov 2021 14:54:04 +0100 Subject: [Haskell-cafe] code in postings mangled? In-Reply-To: <1862d57105802beb1048b76a084ec79c2d901ef8.camel@aatal-apotheke.de> References: <1862d57105802beb1048b76a084ec79c2d901ef8.camel@aatal-apotheke.de> Message-ID: <6e05a5df-b7d2-27a1-7924-a33c6c309f9f@durchholz.org> Am 18.11.21 um 17:49 schrieb Olaf Klinke: >> Why is code in postings so often mangled: >> > > Seems it is only the linebreaks. Some programs on Windows, including > TextEdit and likely your mail client, don't consider a newline '\n' > character to be a line break, since Windows terminates lines by "\r\n". This used to be very true 20 years ago, and too-often-true 10 years ago, but today even crummy old Notepad does recognize \n as a linebreak. Any IDE or even mildly feature-rich editor should be able to deal with them. Most even have an easy-to-reach area in the status line that tells you what the line break convention in your text is, and many even make so that clicking on that field allows you to change it. This problem essentially died a decade ago, though obviously there's always the possibility of bugs. > Then OS X has '\r' line terminators, which again might not be > considered a linebreak on some systems. Only really old versions of MacOS ("Mac OS Classic") use \r; the last version of that was 9.x, which was phased out end of 2001, twenty years ago. Max OS X (Darwin and later) are based on BSD (with multiple intermediate steps), and uses the Unix-ish \n as line break. Of course, old mail clients might still insist on \r on Mac, but I doubt that anything newer is still using it. > I remember all kinds of stupid things arising from this, including > version control systems flagging every line as changed when it was only > the line breaks. > I read this list as digest, so I can not verify using the particular > raw email you quoted. Can someone else check this? Outlook is known to apply all kinds of heuristics to try and infer line breaks. Heuristics are known to be less than optimal and sometimes outright stupid; newer versions of Outlook have a small message like "we removed extraneous line breaks, click here to restore them", and that tends to unmangle lines. Regards, Jo From anton.kholomiov at gmail.com Sun Nov 21 09:25:34 2021 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Sun, 21 Nov 2021 12:25:34 +0300 Subject: [Haskell-cafe] Locate errors in TH for Haskell code In-Reply-To: References: Message-ID: I'm doing basic transformation of expressions like: ``` and [a, b, c] ``` to ``` if a then (if b then c else False) else False ``` And similar for or. So I transform the haskell code. I need it for optimisation of Plutus execution which features different model of execution although it's valid haskell code. @Richard thanks for the detailed answer! I could achieve something for my own language embeded in QQ but it was because I had my own type-checker for that and kept the locations. In haskell source code I could not find that and now I know that it's intentional. чт, 11 нояб. 2021 г. в 03:19, David Fox : > I'd like to know more about what you are doing, I feel like I've set out > to do something similar in the past and ended up going a different way. > > On Sat, Nov 6, 2021 at 2:51 AM Anton Kholomiov > wrote: > >> I have a task to convert one Haskell expression to another. >> And I'd like to report errors properly. >> >> [interpret| -- error reported here >> valid haskell code >> invalid code <- error >> |] >> >> I can parse it with haskell-src-exts or haskell-src-meta. >> but if I have error in the code (type-check) error is positioned on the >> first line of the QQ-expression. >> >> Do you know is it possible to report error at the line where it has >> happened or >> to keep original source code location in the Exp. >> >> In the function I do transformation Exp -> Exp. >> >> Or maybe there is a better way to do it instead of QQ? >> _______________________________________________ >> 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 hilco.wijbenga at gmail.com Sun Nov 21 18:13:53 2021 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sun, 21 Nov 2021 10:13:53 -0800 Subject: [Haskell-cafe] Logging Message-ID: Hi all, I just started using "logging" (https://hackage.haskell.org/package/logging) which is based on "fast-logger" (https://hackage.haskell.org/package/fast-logger). It all works fine except that the timestamp in the log message is output as UTC. I would like it to use my local (i.e. system) TZ. I tried setting the TZ environment variable explicitly (before invoking my main) and by setting it in code (System.Environment.setEnv) but it doesn't make any difference. I did not find anything in either API about this so I'm out of ideas. If this is simply impossible, does anyone have a recommendation for another logging package? Cheers, Hilco From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Nov 21 18:18:16 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 21 Nov 2021 18:18:16 +0000 Subject: [Haskell-cafe] Logging In-Reply-To: References: Message-ID: <20211121181816.GA20276@cloudinit-builder> On Sun, Nov 21, 2021 at 10:13:53AM -0800, Hilco Wijbenga wrote: > I just started using "logging" > (https://hackage.haskell.org/package/logging) which is based on > "fast-logger" (https://hackage.haskell.org/package/fast-logger). It > all works fine except that the timestamp in the log message is output > as UTC. I would like it to use my local (i.e. system) TZ. It sounds really unwise to log timestamps in anything in other than UTC. If you want to see the logged times in your local timezone then why not apply that conversion when you read the log? From jo at durchholz.org Sun Nov 21 21:47:11 2021 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 21 Nov 2021 22:47:11 +0100 Subject: [Haskell-cafe] Logging In-Reply-To: <20211121181816.GA20276@cloudinit-builder> References: <20211121181816.GA20276@cloudinit-builder> Message-ID: <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Am 21.11.21 um 19:18 schrieb Tom Ellis: > It sounds really unwise to log timestamps in anything in other than > UTC. If you want to see the logged times in your local timezone then > why not apply that conversion when you read the log? UTC is wise only if you really have to deal with data originating from multiple timezones. Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something). E.g. the application I'm working with logs to text files, and it always runs in the same time zone. UTC is just an extra hoop to jump through, with no added benefit. (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.) Regards, Jo From migmit at gmail.com Sun Nov 21 22:34:09 2021 From: migmit at gmail.com (MigMit) Date: Sun, 21 Nov 2021 23:34:09 +0100 Subject: [Haskell-cafe] Logging In-Reply-To: <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC. Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface. There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough. > On 21 Nov 2021, at 22:47, Joachim Durchholz wrote: > > Am 21.11.21 um 19:18 schrieb Tom Ellis: >> It sounds really unwise to log timestamps in anything in other than >> UTC. If you want to see the logged times in your local timezone then >> why not apply that conversion when you read the log? > > UTC is wise only if you really have to deal with data originating from multiple timezones. > Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something). > > E.g. the application I'm working with logs to text files, and it always runs in the same time zone. > UTC is just an extra hoop to jump through, with no added benefit. > (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.) > > Regards, > Jo > _______________________________________________ > 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 hilco.wijbenga at gmail.com Sun Nov 21 22:55:44 2021 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sun, 21 Nov 2021 14:55:44 -0800 Subject: [Haskell-cafe] Logging In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: On Sun, Nov 21, 2021 at 2:35 PM MigMit wrote: > > No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC. > > Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface. > > There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough. > > > On 21 Nov 2021, at 22:47, Joachim Durchholz wrote: > > > > Am 21.11.21 um 19:18 schrieb Tom Ellis: > >> It sounds really unwise to log timestamps in anything in other than > >> UTC. If you want to see the logged times in your local timezone then > >> why not apply that conversion when you read the log? > > > > UTC is wise only if you really have to deal with data originating from multiple timezones. > > Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something). > > > > E.g. the application I'm working with logs to text files, and it always runs in the same time zone. > > UTC is just an extra hoop to jump through, with no added benefit. > > (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.) Strangely, while I can see Tom's message in the archives, _I_ never received it. Anyway, it seems I did not miss anything else. Indeed, using UTC has its uses (especially when storing and/or comparing timestamps) but when viewing you definitely want to see your own TZ. Clearly, the assumption seems to be that I'm working on some enormous application supported by several teams of developers in multiple time zones that generates massive log files. While it is nice to know that my reputation is such that it is automatically assumed that I'm creating the next Google ... in reality, it's just me and I'm working on a CLI app where I want to output some log messages. ;-) So I want to see my local time in the log messages. Further research indicates that "logging" simply doesn't support my use case so I will look into writing my own wrapper around "fast-logger". P.S. What is the etiquette here: top or bottom posting? Include all participants or just the list? From migmit at gmail.com Sun Nov 21 23:15:32 2021 From: migmit at gmail.com (MigMit) Date: Mon, 22 Nov 2021 00:15:32 +0100 Subject: [Haskell-cafe] Logging In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: <15736880-5C9B-4250-B647-7DE6776DCCA1@gmail.com> Even if your app only works on your laptop, you might have a problem trying to dig through the logs that may or may not be on the day you were travelling (between time zones). Plus, again, DST. At least UTC have a benefit of not running backwards (most of the time). Interestingly, I haven't got Tom's message either. I haven't checked the archives though, just assuming he sent his message to Joachim only, who resent it to the mailing list. But if it is in the archives, then it is somewhat strange. > On 21 Nov 2021, at 23:55, Hilco Wijbenga wrote: > > On Sun, Nov 21, 2021 at 2:35 PM MigMit wrote: >> >> No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC. >> >> Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface. >> >> There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough. >> >>> On 21 Nov 2021, at 22:47, Joachim Durchholz wrote: >>> >>> Am 21.11.21 um 19:18 schrieb Tom Ellis: >>>> It sounds really unwise to log timestamps in anything in other than >>>> UTC. If you want to see the logged times in your local timezone then >>>> why not apply that conversion when you read the log? >>> >>> UTC is wise only if you really have to deal with data originating from multiple timezones. >>> Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something). >>> >>> E.g. the application I'm working with logs to text files, and it always runs in the same time zone. >>> UTC is just an extra hoop to jump through, with no added benefit. >>> (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.) > > Strangely, while I can see Tom's message in the archives, _I_ never > received it. Anyway, it seems I did not miss anything else. > > Indeed, using UTC has its uses (especially when storing and/or > comparing timestamps) but when viewing you definitely want to see your > own TZ. > > Clearly, the assumption seems to be that I'm working on some enormous > application supported by several teams of developers in multiple time > zones that generates massive log files. While it is nice to know that > my reputation is such that it is automatically assumed that I'm > creating the next Google ... in reality, it's just me and I'm working > on a CLI app where I want to output some log messages. ;-) So I want > to see my local time in the log messages. > > Further research indicates that "logging" simply doesn't support my > use case so I will look into writing my own wrapper around > "fast-logger". > > P.S. What is the etiquette here: top or bottom posting? Include all > participants or just the list? From b at chreekat.net Mon Nov 22 06:41:32 2021 From: b at chreekat.net (Bryan Richter) Date: Mon, 22 Nov 2021 08:41:32 +0200 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: The *only* messages I've seen on this thread are from MigMit. I guess at least two other people have posted, but I don't see them. Not in spam, either. Hmm On Mon, 22 Nov 2021, 0.34 MigMit, wrote: > No, non-UTC logs are a nightmare when you have developers living in > different time zones. Or even in one that is different from the one where > the logs come from. Not only does it still have the same overhead, but it > also adds DST troubles to the mix (yes, DST does not start at the same time > everywhere) and is generally MORE confusing than just having everything in > UTC. > > Also, editors might be fast... but only if you don't have too much logs. I > did work on one project where daily logs took tens of gigabytes in gzip. > Editors were out of question, trying to load this in Emacs would just hang > it. Things like zgrep were pretty much the only thing that could work. > Another project simply used Datadog, and was way easier to work with, > despite it being a web interface. > > There could be some specific cases where logging in a local time zone is a > good idea, but I don't think that happens often enough. > > > On 21 Nov 2021, at 22:47, Joachim Durchholz wrote: > > > > Am 21.11.21 um 19:18 schrieb Tom Ellis: > >> It sounds really unwise to log timestamps in anything in other than > >> UTC. If you want to see the logged times in your local timezone then > >> why not apply that conversion when you read the log? > > > > UTC is wise only if you really have to deal with data originating from > multiple timezones. > > Otherwise, it's just an additional interpretation step that makes it > harder to read the raw logs - which not a very rare use case actually, > editors are still the fastest way to find specific log records after all > (mostly because you don't have to learn the web interface du jour just to > search for something). > > > > E.g. the application I'm working with logs to text files, and it always > runs in the same time zone. > > UTC is just an extra hoop to jump through, with no added benefit. > > (Some users do live in a separate time zone, but we rarely need to > correlate user-side and server-side logs, we go by session ids anyway.) > > > > Regards, > > Jo > > _______________________________________________ > > 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 ky3 at atamo.com Mon Nov 22 07:18:23 2021 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 22 Nov 2021 14:18:23 +0700 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: Perhaps not gremlins in the ether but the reply button that folks hit on their web mail doesn’t include the mailing list. Hence, it wasn’t reflected to us. Subsequently, someone in the convo noticed the absence and included haskell cafe back in. Then we see the missing messages as quoted replies. How to fix this? Two possible approaches: 1. Remind folks to Reply to All. 2. Change the mailing list settings so that webmail reply goes to the list by default. Privatizing the convo—previously the default—is still doable. The haskell beginners list took this decision years ago. I believe option 2 has been suggested previously. This is a consequence of most folks migrating to webmail from unix mail clients that were a bit smarter in being able to recognize unix-driven mailing lists. (At least that’s my guess how we got here.) On Mon, Nov 22, 2021 at 1:42 PM Bryan Richter wrote: > The *only* messages I've seen on this thread are from MigMit. I guess at > least two other people have posted, but I don't see them. Not in spam, > either. Hmm > > On Mon, 22 Nov 2021, 0.34 MigMit, wrote: > >> No, non-UTC logs are a nightmare when you have developers living in >> different time zones. Or even in one that is different from the one where >> the logs come from. Not only does it still have the same overhead, but it >> also adds DST troubles to the mix (yes, DST does not start at the same time >> everywhere) and is generally MORE confusing than just having everything in >> UTC. >> >> Also, editors might be fast... but only if you don't have too much logs. >> I did work on one project where daily logs took tens of gigabytes in gzip. >> Editors were out of question, trying to load this in Emacs would just hang >> it. Things like zgrep were pretty much the only thing that could work. >> Another project simply used Datadog, and was way easier to work with, >> despite it being a web interface. >> >> There could be some specific cases where logging in a local time zone is >> a good idea, but I don't think that happens often enough. >> >> > On 21 Nov 2021, at 22:47, Joachim Durchholz wrote: >> > >> > Am 21.11.21 um 19:18 schrieb Tom Ellis: >> >> It sounds really unwise to log timestamps in anything in other than >> >> UTC. If you want to see the logged times in your local timezone then >> >> why not apply that conversion when you read the log? >> > >> > UTC is wise only if you really have to deal with data originating from >> multiple timezones. >> > Otherwise, it's just an additional interpretation step that makes it >> harder to read the raw logs - which not a very rare use case actually, >> editors are still the fastest way to find specific log records after all >> (mostly because you don't have to learn the web interface du jour just to >> search for something). >> > >> > E.g. the application I'm working with logs to text files, and it always >> runs in the same time zone. >> > UTC is just an extra hoop to jump through, with no added benefit. >> > (Some users do live in a separate time zone, but we rarely need to >> correlate user-side and server-side logs, we go by session ids anyway.) >> > >> > Regards, >> > Jo >> > _______________________________________________ >> > 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. -- -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From x at tomsmeding.com Mon Nov 22 07:33:43 2021 From: x at tomsmeding.com (Tom Smeding) Date: Mon, 22 Nov 2021 07:33:43 +0000 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: I got at least one message from Tom Ellis in the Logging conversation, one from Joachim Durchholz, and some more. I'm definitely not included in the conversation personnally. I have no idea what might be going wrong, but I think it's not forgetting to reply to all. Cheers, Tom -------- Original Message -------- On 22 Nov 2021, 08:18, Kim-Ee Yeoh wrote: > Perhaps not gremlins in the ether but the reply button that folks hit on their web mail doesn’t include the mailing list. Hence, it wasn’t reflected to us. > > Subsequently, someone in the convo noticed the absence and included haskell cafe back in. Then we see the missing messages as quoted replies. > > How to fix this? Two possible approaches: > > 1. Remind folks to Reply to All. > > 2. Change the mailing list settings so that webmail reply goes to the list by default. Privatizing the convo—previously the default—is still doable. The haskell beginners list took this decision years ago. > > I believe option 2 has been suggested previously. > > This is a consequence of most folks migrating to webmail from unix mail clients that were a bit smarter in being able to recognize unix-driven mailing lists. (At least that’s my guess how we got here.) > > On Mon, Nov 22, 2021 at 1:42 PM Bryan Richter wrote: > >> The *only* messages I've seen on this thread are from MigMit. I guess at least two other people have posted, but I don't see them. Not in spam, either. Hmm >> >> On Mon, 22 Nov 2021, 0.34 MigMit, wrote: >> >>> No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC. >>> >>> Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface. >>> >>> There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough. >>> >>>> On 21 Nov 2021, at 22:47, Joachim Durchholz wrote: >>>> >>>> Am 21.11.21 um 19:18 schrieb Tom Ellis: >>>>> It sounds really unwise to log timestamps in anything in other than >>>>> UTC. If you want to see the logged times in your local timezone then >>>>> why not apply that conversion when you read the log? >>>> >>>> UTC is wise only if you really have to deal with data originating from multiple timezones. >>>> Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something). >>>> >>>> E.g. the application I'm working with logs to text files, and it always runs in the same time zone. >>>> UTC is just an extra hoop to jump through, with no added benefit. >>>> (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.) >>>> >>>> Regards, >>>> Jo >>>> _______________________________________________ >>>> 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. > > -- > > -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyzorman at mailbox.org Mon Nov 22 07:41:17 2021 From: tonyzorman at mailbox.org (Tony Zorman) Date: Mon, 22 Nov 2021 08:41:17 +0100 Subject: [Haskell-cafe] Missing messages in the ML (WAS: Logging) In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: <87wnl0ocwy.fsf@hyperspace> On Mon, Nov 22 2021 14:18, Kim-Ee Yeoh wrote: > Perhaps not gremlins in the ether but the reply button that folks hit on > their web mail doesn’t include the mailing list. Hence, it wasn’t reflected > to us. > > Subsequently, someone in the convo noticed the absence and included haskell > cafe back in. Then we see the missing messages as quoted replies. I don't think that's quite it. If you look at the thread in the list archives[1], the messages come through just fine. That wouldn't happen if people didn't at least Cc. the haskell-cafe, no? (For the record, I also only got the original OP and then the latter of the two messages that MigMit sent) [1]: https://mail.haskell.org/pipermail/haskell-cafe/2021-November/134884.html From ietf-dane at dukhovni.org Mon Nov 22 08:10:46 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Nov 2021 03:10:46 -0500 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: On Mon, Nov 22, 2021 at 07:33:43AM +0000, Tom Smeding wrote: > I got at least one message from Tom Ellis in the Logging conversation, > one from Joachim Durchholz, and some more. I'm definitely not included > in the conversation personnally. > > I have no idea what might be going wrong, but I think it's not > forgetting to reply to all. [ TL;DR haskell.org DNS is misconfigured ] I guess I can put my SMTP/DNS guru hat on and explain what is happening. Here's some (cryptic) data from my logs: Nov 22 01:42:13 straasha postfix/smtpd[52426]: disconnect from unknown[145.40.99.54] ehlo=2 starttls=1 mail=1 --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8 Nov 22 02:19:13 straasha postfix/smtpd[52686]: disconnect from unknown[2604:1380:4641:a100::5] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Nov 22 02:35:10 straasha postfix/smtpd[53049]: disconnect from unknown[2604:1380:4641:a100::5] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Nov 22 02:42:51 straasha postfix/smtpd[53100]: disconnect from unknown[145.40.99.54] ehlo=2 starttls=1 mail=1 --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8 The first and last message were rejected: "rcpt=0/1, data=0/1" mean that "RCPT TO" and "DATA" commands were refused. The middle two messages were accepted. The reason is DNS misconfiguration of the of mta1.haskell.org: $ set -- mta1.haskell.org misc-services-origin-migration.haskell.org $ brief() { dig +noall +ans +nocl +nottl "$@"; } $ echo; for fwd; do brief -t a $fwd; brief -t aaaa $fwd; done mta1.haskell.org. A 145.40.99.54 $ brief() { dig +noall +ans +nocl +nottl "$@"; } $ set -- 145.40.99.54 2604:1380:4641:a100::5 $ echo; for rev; do brief -t ptr -x $rev; done 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR misc-services-origin-migration.haskell.org. Only the IPv6 address has a PTR record, and even then it does not forward resolve. SMTP clients with no PTR records are routinely refused service. My mail server tolerates lack of forward mappings, but the PTR is required. The correct DNS configuration would be: forward zone: mta1.haskell.org. A 145.40.99.54 mta1.haskell.org. AAAA 2604:1380:4641:a100::5 reverse IPv6 zone 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR mta1.haskell.org. reverse IPv4 zone 54.99.40.145.in-addr.arpa. PTR mta.haskell.org. -- Viktor. From mikolaj at well-typed.com Mon Nov 22 08:17:55 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Mon, 22 Nov 2021 09:17:55 +0100 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: Let me cite my message from another thread where messages were being lost (BTW, I fully expect you didn't receive this message originally and some of you may not receive it now; if anybody can see a particular problem with our list and a possible solution, please contact Haskell infrastructure team): On Tue, Nov 16, 2021 at 11:02 AM Mikolaj Konarski wrote: > > > I have not received your message from 4:05 PM at all, nor the message > > from Tom Ellis that I see at > > Apparently avoiding both spam and lost emails is impossible nowadays, > but I'm told the situation should improve after a recent upgrade, > update of a SPF record for one of mail.haskell.org servers and > gradually while our servers are regaining reputation. > > For all of us on the list: let's not assume somebody that is repeating > our point has seen our email --- it may have been lost or withheld for > a time. Makes sense to ask for confirmation and also try to join > divergent threads of the same email discussion (if the topic did not > diverge). > > On Sat, Nov 13, 2021 at 4:56 PM Simon Jakobi > wrote: > > > > Huh, I think there must be something amiss between mail.haskell.org and GMail. > > > > I have not received your message from 4:05 PM at all, nor the message > > from Tom Ellis that I see at > > https://mail.haskell.org/pipermail/haskell-cafe/2021-November/134848.html. > > > > Am Sa., 13. Nov. 2021 um 16:48 Uhr schrieb Mikolaj Konarski > > : > > > > > > Off-topic, would it be possible to reduce the latency of mail.haskell.org? > > > > > > It's quite frustrating if your message is a dupe and even more if it > > > seems as if the other person ignored your message and wrote the stuff > > > one again. While, in fact, the messages were 10 minutes in flight and > > > then arrived in reverse order. > > > > > > On Sat, Nov 13, 2021 at 4:05 PM Mikolaj Konarski wrote: > > > > > > > > BTW, Sven, my sources say, running `haskell-ci 'github'` as opposed to > > > > `haskell-ci 'travis'` may give better results. > > > > > > > > On Sat, Nov 13, 2021 at 2:39 PM Mikolaj Konarski wrote: > > > > > > > > > > > I can just offer testing haskell-ci patches etc. > > > > > > > > > > Thank you. I'm sure other haskell-ci contributors can use this help, > > > > > if they read this. In general, that's a great idea, supporting our > > > > > developers in other ways than just code contributions, e.g., via > > > > > general positivity, appreciation, goodwill, expressions of hope, > > > > > uplifting user stories. They are bombarded with (impersonal) > > > > > negativity all the time via bug reports. > > > > > > > > > > > The project I used as a trial balloon for haskell-ci is really dead simple, how are other projects handling this? It must be an extremely common use case, and I doubt that everybody writes the workflows by hand: This would be silly, basically all needed information is already in the .cabal file. > > > > > > > > > > I'm afraid, since hvr stopped updating the PPA images (and other > > > > > things), the Haskell tool ecosystem is in the very sorry and silly > > > > > state you describe. Given that at this stage it's too late to help > > > > > hvr, let's make sure to support Julian with ghcup (and other things) > > > > > so that our ecosystem doesn't break up again, once we port haskell-ci > > > > > to ghcup (if I'm guessing correctly where haskell-ci is going). > > > > > > > > > > > Other projects like e.g. lens seem to use haskell-ci successfully, see https://github.com/ekmett/lens/blob/master/.github/workflows/haskell-ci.yml. But that YAML file looks quite a bit different from what haskell-ci has generated for my project. Why? > > > > > > > > > > Because it's been edited by hand for 11 months. > > > > > > > > > > > As usual, the Haskell tool ecosystem is giving me a hard time... :´-( > > > > > > > > > > I sympathise. > > > > > > > > > > All the best, > > > > > Mikolaj > > > _______________________________________________ > > > 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. On Mon, Nov 22, 2021 at 8:38 AM Tom Smeding wrote: > > I got at least one message from Tom Ellis in the Logging conversation, one from Joachim Durchholz, and some more. I'm definitely not included in the conversation personnally. > > > I have no idea what might be going wrong, but I think it's not forgetting to reply to all. > > > Cheers, > > Tom > > > > -------- Original Message -------- > On 22 Nov 2021, 08:18, Kim-Ee Yeoh < ky3 at atamo.com> wrote: > > > Perhaps not gremlins in the ether but the reply button that folks hit on their web mail doesn’t include the mailing list. Hence, it wasn’t reflected to us. > > Subsequently, someone in the convo noticed the absence and included haskell cafe back in. Then we see the missing messages as quoted replies. > > How to fix this? Two possible approaches: > > 1. Remind folks to Reply to All. > > 2. Change the mailing list settings so that webmail reply goes to the list by default. Privatizing the convo—previously the default—is still doable. The haskell beginners list took this decision years ago. > > I believe option 2 has been suggested previously. > > This is a consequence of most folks migrating to webmail from unix mail clients that were a bit smarter in being able to recognize unix-driven mailing lists. (At least that’s my guess how we got here.) > > > On Mon, Nov 22, 2021 at 1:42 PM Bryan Richter wrote: >> >> The *only* messages I've seen on this thread are from MigMit. I guess at least two other people have posted, but I don't see them. Not in spam, either. Hmm >> >> On Mon, 22 Nov 2021, 0.34 MigMit, wrote: >>> >>> No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC. >>> >>> Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface. >>> >>> There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough. >>> >>> > On 21 Nov 2021, at 22:47, Joachim Durchholz wrote: >>> > >>> > Am 21.11.21 um 19:18 schrieb Tom Ellis: >>> >> It sounds really unwise to log timestamps in anything in other than >>> >> UTC. If you want to see the logged times in your local timezone then >>> >> why not apply that conversion when you read the log? >>> > >>> > UTC is wise only if you really have to deal with data originating from multiple timezones. >>> > Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something). >>> > >>> > E.g. the application I'm working with logs to text files, and it always runs in the same time zone. >>> > UTC is just an extra hoop to jump through, with no added benefit. >>> > (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.) >>> > >>> > Regards, >>> > Jo >>> > _______________________________________________ >>> > 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. > > -- > -- Kim-Ee > _______________________________________________ > 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 Mon Nov 22 08:19:24 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Nov 2021 03:19:24 -0500 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: On Mon, Nov 22, 2021 at 03:10:47AM -0500, Viktor Dukhovni wrote: > The correct DNS configuration would be: > > forward zone: > mta1.haskell.org. A 145.40.99.54 > mta1.haskell.org. AAAA 2604:1380:4641:a100::5 > > reverse IPv6 zone > 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR mta1.haskell.org. > > reverse IPv4 zone > 54.99.40.145.in-addr.arpa. PTR mta.haskell.org. That IPv4 reverse name should of course be "mta1.haskell.org." With careful attention to the trailing dots on all FQDNs. -- Viktor. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Nov 22 10:09:06 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 22 Nov 2021 10:09:06 +0000 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: <20211122100906.GB20276@cloudinit-builder> Thanks for tracking this down. I also forwarded the issue to the Haskell Infrastructure Admins issue tracker: https://github.com/haskell-infra/haskell-admins/issues/5 On Mon, Nov 22, 2021 at 03:10:46AM -0500, Viktor Dukhovni wrote: > On Mon, Nov 22, 2021 at 07:33:43AM +0000, Tom Smeding wrote: > > > I got at least one message from Tom Ellis in the Logging conversation, > > one from Joachim Durchholz, and some more. I'm definitely not included > > in the conversation personnally. > > > > I have no idea what might be going wrong, but I think it's not > > forgetting to reply to all. > > [ TL;DR haskell.org DNS is misconfigured ] > > I guess I can put my SMTP/DNS guru hat on and explain what is happening. > Here's some (cryptic) data from my logs: > > Nov 22 01:42:13 straasha postfix/smtpd[52426]: > disconnect from unknown[145.40.99.54] > ehlo=2 starttls=1 mail=1 > --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8 > > Nov 22 02:19:13 straasha postfix/smtpd[52686]: > disconnect from unknown[2604:1380:4641:a100::5] > ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 > > Nov 22 02:35:10 straasha postfix/smtpd[53049]: > disconnect from unknown[2604:1380:4641:a100::5] > ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 > > Nov 22 02:42:51 straasha postfix/smtpd[53100]: > disconnect from unknown[145.40.99.54] > ehlo=2 starttls=1 mail=1 > --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8 > > The first and last message were rejected: "rcpt=0/1, data=0/1" mean that > "RCPT TO" and "DATA" commands were refused. The middle two messages > were accepted. > > The reason is DNS misconfiguration of the of mta1.haskell.org: > > $ set -- mta1.haskell.org misc-services-origin-migration.haskell.org > $ brief() { dig +noall +ans +nocl +nottl "$@"; } > $ echo; for fwd; do brief -t a $fwd; brief -t aaaa $fwd; done > > mta1.haskell.org. A 145.40.99.54 > > $ brief() { dig +noall +ans +nocl +nottl "$@"; } > $ set -- 145.40.99.54 2604:1380:4641:a100::5 > $ echo; for rev; do brief -t ptr -x $rev; done > > 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR misc-services-origin-migration.haskell.org. > > Only the IPv6 address has a PTR record, and even then it does not > forward resolve. SMTP clients with no PTR records are routinely refused > service. My mail server tolerates lack of forward mappings, but the PTR > is required. > > The correct DNS configuration would be: > > forward zone: > mta1.haskell.org. A 145.40.99.54 > mta1.haskell.org. AAAA 2604:1380:4641:a100::5 > > reverse IPv6 zone > 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR mta1.haskell.org. > > reverse IPv4 zone > 54.99.40.145.in-addr.arpa. PTR mta.haskell.org. From ky3 at atamo.com Mon Nov 22 10:37:09 2021 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 22 Nov 2021 17:37:09 +0700 Subject: [Haskell-cafe] Missing messages in the ML (WAS: Logging) In-Reply-To: <87wnl0ocwy.fsf@hyperspace> References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> <87wnl0ocwy.fsf@hyperspace> Message-ID: On Mon, Nov 22, 2021 at 2:38 PM Tony Zorman wrote: > On Mon, Nov 22 2021 14:18, Kim-Ee Yeoh wrote: > > Perhaps not gremlins in the ether but the reply button that folks hit on > > their web mail doesn’t include the mailing list. Hence, it wasn’t > reflected > > to us. > > > > Subsequently, someone in the convo noticed the absence and included > haskell > > cafe back in. Then we see the missing messages as quoted replies. > > I don't think that's quite it. If you look at the thread in the list > archives[1], the messages come through just fine. That wouldn't happen > if people didn't at least Cc. the haskell-cafe, no? I stand corrected then, notwithstanding what I wrote originally remainIng an extant if unrelated problem of haskell cafe until it is fixed. > > (For the record, I also only got the original OP and then the latter of > the two messages that MigMit sent) > > [1]: > https://mail.haskell.org/pipermail/haskell-cafe/2021-November/134884.html > -- -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Mon Nov 22 11:38:38 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 22 Nov 2021 12:38:38 +0100 Subject: [Haskell-cafe] Logging Message-ID: <0ef693daab428a603bb22fbd5e0ffaf60d0e42ec.camel@aatal-apotheke.de> As someone who works with timeseries for a living, I can say that what is a nightmare is timestamps that do not correspond to a unique UTC time. So you'd want a ZonedTime timestamp. I've been using monad-logger and rolled my own extension which adds (formatted) time stamps to the log messages. Olaf From gershomb at gmail.com Mon Nov 22 15:17:13 2021 From: gershomb at gmail.com (Gershom B) Date: Mon, 22 Nov 2021 10:17:13 -0500 Subject: [Haskell-cafe] Missing messages in the ML In-Reply-To: References: <20211121181816.GA20276@cloudinit-builder> <24930af1-7f3e-e162-f6d9-965468101bc0@durchholz.org> Message-ID: Thanks! We're looking into this with our host. -g On Mon, Nov 22, 2021 at 3:34 AM Viktor Dukhovni wrote: > > On Mon, Nov 22, 2021 at 07:33:43AM +0000, Tom Smeding wrote: > > > I got at least one message from Tom Ellis in the Logging conversation, > > one from Joachim Durchholz, and some more. I'm definitely not included > > in the conversation personnally. > > > > I have no idea what might be going wrong, but I think it's not > > forgetting to reply to all. > > [ TL;DR haskell.org DNS is misconfigured ] > > I guess I can put my SMTP/DNS guru hat on and explain what is happening. > Here's some (cryptic) data from my logs: > > Nov 22 01:42:13 straasha postfix/smtpd[52426]: > disconnect from unknown[145.40.99.54] > ehlo=2 starttls=1 mail=1 > --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8 > > Nov 22 02:19:13 straasha postfix/smtpd[52686]: > disconnect from unknown[2604:1380:4641:a100::5] > ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 > > Nov 22 02:35:10 straasha postfix/smtpd[53049]: > disconnect from unknown[2604:1380:4641:a100::5] > ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 > > Nov 22 02:42:51 straasha postfix/smtpd[53100]: > disconnect from unknown[145.40.99.54] > ehlo=2 starttls=1 mail=1 > --> rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8 > > The first and last message were rejected: "rcpt=0/1, data=0/1" mean that > "RCPT TO" and "DATA" commands were refused. The middle two messages > were accepted. > > The reason is DNS misconfiguration of the of mta1.haskell.org: > > $ set -- mta1.haskell.org misc-services-origin-migration.haskell.org > $ brief() { dig +noall +ans +nocl +nottl "$@"; } > $ echo; for fwd; do brief -t a $fwd; brief -t aaaa $fwd; done > > mta1.haskell.org. A 145.40.99.54 > > $ brief() { dig +noall +ans +nocl +nottl "$@"; } > $ set -- 145.40.99.54 2604:1380:4641:a100::5 > $ echo; for rev; do brief -t ptr -x $rev; done > > 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR misc-services-origin-migration.haskell.org. > > Only the IPv6 address has a PTR record, and even then it does not > forward resolve. SMTP clients with no PTR records are routinely refused > service. My mail server tolerates lack of forward mappings, but the PTR > is required. > > The correct DNS configuration would be: > > forward zone: > mta1.haskell.org. A 145.40.99.54 > mta1.haskell.org. AAAA 2604:1380:4641:a100::5 > > reverse IPv6 zone > 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.a.1.4.6.4.0.8.3.1.4.0.6.2.ip6.arpa. PTR mta1.haskell.org. > > reverse IPv4 zone > 54.99.40.145.in-addr.arpa. PTR mta.haskell.org. > > -- > Viktor. From olf at aatal-apotheke.de Mon Nov 22 15:33:29 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 22 Nov 2021 16:33:29 +0100 Subject: [Haskell-cafe] Logging Message-ID: <580853f0be4a4d246852f8f9e329e44ddcdb74e5.camel@aatal-apotheke.de> Dear Hilco, attached is a module we use in production. It builds on top of the monad-logger package which is used, among other places, in Yesod. Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: Timed.hs Type: text/x-haskell Size: 1677 bytes Desc: not available URL: From johannes.waldmann at htwk-leipzig.de Thu Nov 25 21:28:07 2021 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Thu, 25 Nov 2021 22:28:07 +0100 Subject: [Haskell-cafe] methods/tools for reading/presenting (time/allocation) profiling information? Message-ID: <81baf7ea-5b5a-01a2-4e7f-4e4e8d639bed@htwk-leipzig.de> Dear Cafe, with +RTS -p -RTS, the resulting .prof file shows (in the second part) what the expensive functions are. (counting sections as GHC docs do - first part gives program name and options) Often, that's useful, but sometimes, this info does not surprise me - some things just don't have an easy implementation. For those, I want to find out who calls them - to possibly replace some of these calls with a cheaper implementation (that is only valid because the caller knows something that the callee does not) Is there some automation for getting this information? I am not even sure how to formalize what I want. Perhaps, for the first N heavy cost centers (SCCs), a suitably ordered list of their callers (that inherit the cost)? The data is in the third (long, detailed) part of the .prof file but I find it hard to process (in that form). It represents the call hiearchy by indentation (first column) and adjacency (of rows) but this goes out the window as soon as I grep or sort the rows. The JSON output format seems the way to go https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#json-profile-format . Yeah, I should probably just aeson it and then walk the tree. I still wanted to ask for advice first, or references to existing work. Any pointers appreciated. - J. From vamchale at gmail.com Thu Nov 25 22:09:05 2021 From: vamchale at gmail.com (Vanessa McHale) Date: Thu, 25 Nov 2021 17:09:05 -0500 Subject: [Haskell-cafe] methods/tools for reading/presenting (time/allocation) profiling information? In-Reply-To: <81baf7ea-5b5a-01a2-4e7f-4e4e8d639bed@htwk-leipzig.de> References: <81baf7ea-5b5a-01a2-4e7f-4e4e8d639bed@htwk-leipzig.de> Message-ID: I’ve used ghc-prof-flamegraph https://hackage.haskell.org/package/ghc-prof-flamegraph for timing information. > On Nov 25, 2021, at 4:28 PM, Johannes Waldmann wrote: > > Dear Cafe, > > with +RTS -p -RTS, the resulting .prof file > shows (in the second part) what the expensive functions are. > (counting sections as GHC docs do - > first part gives program name and options) > > Often, that's useful, but sometimes, this info does not surprise me - > some things just don't have an easy implementation. > For those, I want to find out who calls them - > to possibly replace some of these calls > with a cheaper implementation (that is only valid > because the caller knows something that the callee does not) > > Is there some automation for getting this information? > I am not even sure how to formalize what I want. > Perhaps, for the first N heavy cost centers (SCCs), > a suitably ordered list of their callers (that inherit the cost)? > > The data is in the third (long, detailed) part of the .prof file > but I find it hard to process (in that form). It represents > the call hiearchy by indentation (first column) and adjacency (of rows) > but this goes out the window as soon as I grep or sort the rows. > > The JSON output format seems the way to go > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#json-profile-format > . > Yeah, I should probably just aeson it and then walk the tree. > I still wanted to ask for advice first, or references > to existing work. Any pointers appreciated. > > - J. > _______________________________________________ > 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 Fri Nov 26 22:01:06 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 26 Nov 2021 23:01:06 +0100 Subject: [Haskell-cafe] methods/tools for reading/presenting (time/allocation) profiling information? Message-ID: <28b35de963dfcf46d1a097b253553f139e31983a.camel@aatal-apotheke.de> > Dear Cafe, > > with +RTS -p -RTS, the resulting .prof file > shows (in the second part) what the expensive functions are. > (counting sections as GHC docs do - > first part gives program name and options) > > Often, that's useful, but sometimes, this info does not surprise me - > some things just don't have an easy implementation. > For those, I want to find out who calls them - > to possibly replace some of these calls > with a cheaper implementation (that is only valid > because the caller knows something that the callee does not) > > Is there some automation for getting this information? > I am not even sure how to formalize what I want. > Perhaps, for the first N heavy cost centers (SCCs), > a suitably ordered list of their callers (that inherit the cost)? > > The data is in the third (long, detailed) part of the .prof file > but I find it hard to process (in that form). It represents > the call hiearchy by indentation (first column) and adjacency (of rows) > but this goes out the window as soon as I grep or sort the rows. > > The JSON output format seems the way to go > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#json-profile-format > . > Yeah, I should probably just aeson it and then walk the tree. > I still wanted to ask for advice first, or references > to existing work. Any pointers appreciated. > > - J. > Profiteur has served me well in this regard. It shows me what top-level functions eat most of the execution times, and which sub-functions have the biggest share thereof, etc. All in a nice interactive browser interface. https://hackage.haskell.org/package/profiteur Olaf From borgauf at gmail.com Mon Nov 29 04:05:44 2021 From: borgauf at gmail.com (Galaxy Being) Date: Sun, 28 Nov 2021 22:05:44 -0600 Subject: [Haskell-cafe] What is Data.Vec.DataFamily.SpineStrict.Pigeonhole and why is it following me? Message-ID: Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: This in Hackage is something a rank amateur like me can't fathom. I just hit a chapter in a book that dives into the Pigeonhole Principle. Is this the "accompanying Haskell Wundercode" for the math world's PHP? I know PHP is a big deal in math. I don't see an "author," and I see no documentation. Anyone know how I can figure this mystery out, like at least find the author or someone that knows something about this? [...] Content analysis details: (5.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (borgauf[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.3039] 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: Galaxy Being Subject: What is Data.Vec.DataFamily.SpineStrict.Pigeonhole and why is it following me? Date: Sun, 28 Nov 2021 22:05:44 -0600 Size: 4075 URL: From david.feuer at gmail.com Mon Nov 29 04:59:50 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 28 Nov 2021 23:59:50 -0500 Subject: [Haskell-cafe] What is Data.Vec.DataFamily.SpineStrict.Pigeonhole and why is it following me? In-Reply-To: References: Message-ID: No, this seems to have nothing to do with the pigeonhole principle. It seems to be about the sizes of length-indexed vectors. The "pigeonhole size" is just the vector length, available at the type level. This all seems to be about matching up vectors to representable functors. So it would match up data Foo a = Foo a a a a to the type of vectors of length 4, giving functions to convert between them. I'm ... not exactly sure what purpose this serves. On Sun, Nov 28, 2021, 11:07 PM Galaxy Being wrote: > Spam detection software, running on the system "mail.haskell.org", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > @@CONTACT_ADDRESS@@ for details. > > Content preview: This < > https://hackage.haskell.org/package/vec-0.4/docs/Data-Vec-DataFamily-SpineStrict-Pigeonhole.html > > > in Hackage is something a rank amateur like me can't fathom. I just hit > a > chapter in a book that dives into the Pigeonhole Principle. Is this the > "accompanying > Haskell Wundercode" for the math world's PHP? I know PHP is a big deal > in > math. I don't see an "author," and I see no documentation. Anyone know > how > I can figure this mystery out, like at least find the author or someone > that > knows something about this? [...] > > Content analysis details: (5.0 points, 5.0 required) > > pts rule name description > ---- ---------------------- > -------------------------------------------------- > 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail > provider > (borgauf[at]gmail.com) > -0.0 SPF_PASS SPF: sender matches SPF record > -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% > [score: 0.3039] > 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language > 0.0 HTML_MESSAGE BODY: HTML included in message > 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid > > The original message was not completely plain text, and may be unsafe to > open with some email clients; in particular, it may contain a virus, > or confirm that your address can receive spam. If you wish to view > it, it may be safer to save it to a file and open it with an editor. > > > > > ---------- Forwarded message ---------- > From: Galaxy Being > To: haskell-cafe > Cc: > Bcc: > Date: Sun, 28 Nov 2021 22:05:44 -0600 > Subject: What is Data.Vec.DataFamily.SpineStrict.Pigeonhole and why is it > following me? > This > > in Hackage is something a rank amateur like me can't fathom. I just hit a > chapter in a book that dives into the Pigeonhole Principle. Is this the > "accompanying Haskell Wundercode" for the math world's PHP? I know PHP is a > big deal in math. I don't see an "author," and I see no documentation. > Anyone know how I can figure this mystery out, like at least find the > author or someone that knows something about this? > > -- > ⨽ > Lawrence Bottorff > Grand Marais, MN, USA > borgauf 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dyaitskov at gmail.com Tue Nov 30 19:16:14 2021 From: dyaitskov at gmail.com (Daneel Yaitskov) Date: Tue, 30 Nov 2021 14:16:14 -0500 Subject: [Haskell-cafe] MonadFail with type parameter for error message Message-ID: Dear Cafe, MonadFail.fail takes String. I wasn't able to find MonadFail for custom error type. Is there any proposals to base? Let's say Data.Text, which gains popularity with OverloadedStrings extensions. class MonadFail m where fail :: String -> m a Why not ? class MonadFail m where fail :: (forall s. IsString s => s) -> m a class MonadFailWith m s where fail :: s -> m a -- Best regards, Daniil Iaitskov -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Nov 30 19:20:25 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 30 Nov 2021 14:20:25 -0500 Subject: [Haskell-cafe] MonadFail with type parameter for error message In-Reply-To: References: Message-ID: Because the primary purpose of fail is to provide for failed pattern matches, which invoke it with a String representing the pattern match error. On Tue, Nov 30, 2021 at 2:16 PM Daneel Yaitskov wrote: > > Dear Cafe, > > MonadFail.fail takes String. > I wasn't able to find MonadFail for custom error type. > Is there any proposals to base? > > Let's say Data.Text, which gains popularity with OverloadedStrings extensions. > > class MonadFail m where > fail :: String -> m a > > Why not ? > class MonadFail m where > fail :: (forall s. IsString s => s) -> m a > > class MonadFailWith m s where > fail :: s -> m a > > > > > > > > -- > > Best regards, > Daniil Iaitskov > > > > _______________________________________________ > 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 Tue Nov 30 19:34:31 2021 From: david.feuer at gmail.com (David Feuer) Date: Tue, 30 Nov 2021 14:34:31 -0500 Subject: [Haskell-cafe] MonadFail with type parameter for error message In-Reply-To: References: Message-ID: Because that wouldn't actually help. You couldn't optimize it for different stringy types. Using instance overlap (which is evil), you *could* do something similar. class Monad m => MonadFail s m where fail :: s -> m a instance {-# OVERLAPPABLE #-} (MonadFail String m, IsString s) => MonadFail s m where fail = fail . toString I don't think this is terribly likely to work well in practice. On Tue, Nov 30, 2021, 2:16 PM Daneel Yaitskov wrote: > Dear Cafe, > > MonadFail.fail takes String. > I wasn't able to find MonadFail for custom error type. > Is there any proposals to base? > > Let's say Data.Text, which gains popularity with OverloadedStrings > extensions. > > class MonadFail m where > fail :: String -> m a > > Why not ? > class MonadFail m where > fail :: (forall s. IsString s => s) -> m a > > class MonadFailWith m s where > fail :: s -> m a > > > > > > > > -- > > Best regards, > Daniil Iaitskov > > > > _______________________________________________ > 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 dyaitskov at gmail.com Tue Nov 30 19:38:54 2021 From: dyaitskov at gmail.com (Daneel Yaitskov) Date: Tue, 30 Nov 2021 14:38:54 -0500 Subject: [Haskell-cafe] MonadFail with type parameter for error message In-Reply-To: References: Message-ID: On Tue, Nov 30, 2021 at 2:20 PM Brandon Allbery wrote: > Because the primary purpose of fail is to provide for failed pattern > matches, which invoke it with a String representing the pattern match > error. > I see the purpose, but fail with just literal string is not very informative. It is easier for debugging supplying an error message with Showable parameters. Custom Prelude has show :: a - >Text so fail looks like: oops -> fail $ "functionX is not implemented for " <> show oops > On Tue, Nov 30, 2021 at 2:16 PM Daneel Yaitskov > wrote: > > > > Dear Cafe, > > > > MonadFail.fail takes String. > > I wasn't able to find MonadFail for custom error type. > > Is there any proposals to base? > > > > Let's say Data.Text, which gains popularity with OverloadedStrings > extensions. > > > > class MonadFail m where > > fail :: String -> m a > > > > Why not ? > > class MonadFail m where > > fail :: (forall s. IsString s => s) -> m a > > > > class MonadFailWith m s where > > fail :: s -> m a > > > > > > > > > > > > > > > > -- > > > > Best regards, > > Daniil Iaitskov > > > > > > > > _______________________________________________ > > 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 > -- Best regards, Daniil Iaitskov -------------- next part -------------- An HTML attachment was scrubbed... URL: