From hecate at glitchbra.in Sat May 1 06:52:49 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Sat, 1 May 2021 08:52:49 +0200 Subject: linting GHC In-Reply-To: <010f017924695d1f-ff64315f-b708-4cb9-b851-aa7c13f588ee-000000@us-east-2.amazonses.com> References: <010f017924695d1f-ff64315f-b708-4cb9-b851-aa7c13f588ee-000000@us-east-2.amazonses.com> Message-ID: <0391fad5-060c-8912-3b71-5f8b49a33397@glitchbra.in> Hi Richard, thanks for your questions! I'll answer them below: > […] and I somehow know (though I forget where I learned it) You can find a summary of the available linting (with HLint) Hadrian rules here: https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#working-conventions > I introduced one of these errors, in GHC.Tc.Utils.Unify; the other errors are in files I have not modified. Will these affect CI? How old is your latest sync with upstream/master? Maybe these lints have been corrected after your last pull? > Hadrian crashes at the end. Is that expected? It says "system command failed" with a bunch of gobbledegook. Is this an error within Hadrian? It's Hadrian's way to exit with a non-0 code and give us some info about what went wrong >  Are these colors configurable? Not to my knowledge. Until NO_COLOR or more colour schemes are implemented in HLint, you can use this (sad) workaround: ``` TERM=dumb hadrian/build -j lint:compiler ``` which remove all the colours from the output. Hope this helps, sorry for the confusion. Cheers, Hécate Le 30/04/2021 à 22:12, Richard Eisenberg a écrit : > Hi devs, > > I see in CI that we're now linting the GHC source code. In order to > avoid CI failure, I would like to lint locally, and I somehow know > (though I forget where I learned it) that hadrian/build lint:compiler > is the way to do this. After building hlint, I am able to do this. But > the output is surprising; here is the tail: > > # hlint (for lint:compiler) > compiler/GHC/Tc/Utils/Unify.hs:2:1-36: Warning: Unused LANGUAGE pragma > Found: > {-# LANGUAGE MultiWayIf #-} > Perhaps you should remove it. > > compiler/stage1/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE > pragma > Found: > {-# LANGUAGE ViewPatterns #-} > Perhaps you should remove it. > > compiler/stage1/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE > pragma > Found: > {-# LANGUAGE LambdaCase #-} > Perhaps you should remove it. > > compiler/stage1/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports > Found: > import Control.Monad ( unless, liftM, when,(<=<)) > import Control.Monad ( ap ) > > Perhaps: > import Control.Monad ( unless, liftM, when,(<=<), ap ) > > > compiler/stage1/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports > Found: > import GHC.Prelude > import GHC.Prelude > > Perhaps: > import GHC.Prelude > > > compiler/stage1/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer > imports > Found: > import GHC.StgToCmm.Prof > import GHC.StgToCmm.Prof > > Perhaps: > import GHC.StgToCmm.Prof > > > compiler/stage1/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer > imports > Found: > import Control.Monad > import Control.Monad ( ap ) > > Perhaps: > import Control.Monad > > > compiler/stage2/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE > pragma > Found: > {-# LANGUAGE ViewPatterns #-} > Perhaps you should remove it. > > compiler/stage2/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE > pragma > Found: > {-# LANGUAGE LambdaCase #-} > Perhaps you should remove it. > > compiler/stage2/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports > Found: > import Control.Monad ( unless, liftM, when,(<=<)) > import Control.Monad ( ap ) > > Perhaps: > import Control.Monad ( unless, liftM, when,(<=<), ap ) > > > compiler/stage2/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports > Found: > import GHC.Prelude > import GHC.Prelude > > Perhaps: > import GHC.Prelude > > > compiler/stage2/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer > imports > Found: > import GHC.StgToCmm.Prof > import GHC.StgToCmm.Prof > > Perhaps: > import GHC.StgToCmm.Prof > > > compiler/stage2/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer > imports > Found: > import Control.Monad > import Control.Monad ( ap ) > > Perhaps: > import Control.Monad > > > 13 hints > Error when running Shake build system: >   at want, called at src/Main.hs:104:30 in main:Main > * Depends on: lint:compiler >   at cmd_, called at src/Rules/Lint.hs:70:3 in main:Rules.Lint > * Raised the exception: > Development.Shake.cmd, system command failed > Command line: hlint -j --cpp-define x86_64_HOST_ARCH > --cpp-include=includes --cpp-include=_build/stage1/lib > --cpp-include=compiler --cpp-include=_build/stage1/lib/ghcplatform.h > --cpp-include=_build/stage1/compiler/build -h compiler/.hlint.yaml > compiler > Exit code: 1 > Stderr: > > There are several curiosities here: > > * I introduced one of these errors, in GHC.Tc.Utils.Unify; the other > errors are in files I have not modified. Will these affect CI? > * Hadrian crashes at the end. Is that expected? It says "system > command failed" with a bunch of gobbledegook. Is this an error within > Hadrian? Or is this just Hadrian's way of saying that it encountered > an error when linting? If it's the latter, the current message is hard > to read. > * As you may be able to see, I use a dark-background terminal window. > The colors output by the hlint process are nigh impossible to read > when describing redundant LANGUAGE pragmas. Are these colors configurable? > > Thanks! > Richard > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon May 3 18:59:00 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 3 May 2021 18:59:00 +0000 Subject: structured error messages Message-ID: <010f0179339912f8-4fc1b260-aadb-414e-a27e-b38f691c70ae-000000@us-east-2.amazonses.com> Hi all, Alfredo and I are hard at work redesigning GHC's error-message system. It is time for more input, though, from clients of the system -- those writing IDEs and other tooling on top of GHC. The key question: How would you like your errors served? Right now, errors are served well-done: fully cooked into structureless strings that can be easily given to users. The problem with this is that IDEs cannot easily intervene between GHC and the users, as all the nutrition (that is, detailed information) has been cooked away. The new design allows for *structured errors*, where error messages are represented by elements of some error type. Different messages have different constructors of this type, and these constructors can carry auxiliary information. GHC will store these errors raw and cook them (that is, turn them into readable strings) only right before printing them. If the raw messages were somehow passed to IDEs, then IDEs could handle them non-uniformly. (For example, if a module name and a file name are different, the IDE could just present a dialog to the user asking whether the user would like to change one automatically.) There are a few open questions: * In what vessel shall the raw messages be served? In other words, how do IDEs expect to interact with this new system? - One route would be to pass e.g. -fjson-errors, which means that GHC presents the raw messages in a JSON format, for IDEs to parse. That's OK, but it still means that IDEs would have to have their own raw error message types to parse into. - Another route would be for the IDE to link against GHC itself, and then invoke the compiler via a function call that returns the raw messages directly. - Another route is some kind of middle ground, where the IDE passes e.g. -fbinary-errors= instructing GHC to write out a binary encoding of its messages to some file (or pipe, I suppose). These could then be deserialized back into GHC's own error types, but running in a separate process (linked against GHC, once again). - I'm sure you can come up with other interaction strategies. * What will an IDE do with these messages? It might have special handling for some, but GHC has a lot of different messages, and I imagine IDEs will want many just to be printed to the user. If an IDE has only the raw message, then the IDE is forced to do all the cooking -- no good. So there must be a way to take a raw message and render it into a user-readable string. - Maybe the above methods produce both the raw error and the rendered one? Then the IDE can choose which it prefers to use. - GHC could easily export its pretty-printing functions that take in the raw messages and produce rendered ones. But that (again) requires linking against GHC. Note that we are not (here, yet) discussing errors served at points between raw and well-done, though I would like to do so. Such an error would be rendered into a format where textual bits are interleaved with more structured bits, which would enable e.g. clicking on expressions within error messages to get their types. That (important feature) comes separately. So: what do consumers want here? Preview: You can take a look at some raw error messages from the driver in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533 . Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Mon May 3 19:11:54 2021 From: cdsmith at gmail.com (Chris Smith) Date: Mon, 3 May 2021 15:11:54 -0400 Subject: structured error messages In-Reply-To: <010f0179339912f8-4fc1b260-aadb-414e-a27e-b38f691c70ae-000000@us-east-2.amazonses.com> References: <010f0179339912f8-4fc1b260-aadb-414e-a27e-b38f691c70ae-000000@us-east-2.amazonses.com> Message-ID: Thanks, Richard. This is awesome! For my use case, the more exciting possibility would be to interact with error messages from JavaScript. For this reason, I'd definitely love to see a well-known structured file format (JSON, YAML, XML, or whatever) that can be read without linking against GHC. I also like the idea of producing both the structured data and the raw string, since as you mention, one shouldn't need to handle every single possible GHC diagnostic just to add some special handling for a few of them. Ultimately, if reading error messages did require linking with GHC, it wouldn't be the end of the world. I would just write my own translation layer to JSON. So consider this a weak preference. On Mon, May 3, 2021 at 3:00 PM Richard Eisenberg wrote: > Hi all, > > Alfredo and I are hard at work redesigning GHC's error-message system. It > is time for more input, though, from clients of the system -- those writing > IDEs and other tooling on top of GHC. > > The key question: How would you like your errors served? > > Right now, errors are served well-done: fully cooked into structureless > strings that can be easily given to users. The problem with this is that > IDEs cannot easily intervene between GHC and the users, as all the > nutrition (that is, detailed information) has been cooked away. > > The new design allows for *structured errors*, where error messages are > represented by elements of some error type. Different messages have > different constructors of this type, and these constructors can carry > auxiliary information. GHC will store these errors raw and cook them (that > is, turn them into readable strings) only right before printing them. If > the raw messages were somehow passed to IDEs, then IDEs could handle them > non-uniformly. (For example, if a module name and a file name are > different, the IDE could just present a dialog to the user asking whether > the user would like to change one automatically.) > > There are a few open questions: > > * In what vessel shall the raw messages be served? In other words, how do > IDEs expect to interact with this new system? > - One route would be to pass e.g. -fjson-errors, which means that GHC > presents the raw messages in a JSON format, for IDEs to parse. That's OK, > but it still means that IDEs would have to have their own raw error message > types to parse into. > - Another route would be for the IDE to link against GHC itself, and > then invoke the compiler via a function call that returns the raw messages > directly. > - Another route is some kind of middle ground, where the IDE passes e.g. > -fbinary-errors= instructing GHC to write out a binary encoding > of its messages to some file (or pipe, I suppose). These could then be > deserialized back into GHC's own error types, but running in a separate > process (linked against GHC, once again). > - I'm sure you can come up with other interaction strategies. > > * What will an IDE do with these messages? It might have special handling > for some, but GHC has a lot of different messages, and I imagine IDEs will > want many just to be printed to the user. If an IDE has only the raw > message, then the IDE is forced to do all the cooking -- no good. So there > must be a way to take a raw message and render it into a user-readable > string. > - Maybe the above methods produce both the raw error and the rendered > one? Then the IDE can choose which it prefers to use. > - GHC could easily export its pretty-printing functions that take in the > raw messages and produce rendered ones. But that (again) requires linking > against GHC. > > Note that we are not (here, yet) discussing errors served at points > between raw and well-done, though I would like to do so. Such an error > would be rendered into a format where textual bits are interleaved with > more structured bits, which would enable e.g. clicking on expressions > within error messages to get their types. That (important feature) comes > separately. > > So: what do consumers want here? > > Preview: You can take a look at some raw error messages from the driver in > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533. > > Thanks! > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon May 3 21:56:44 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 3 May 2021 21:56:44 +0000 Subject: structured error messages In-Reply-To: References: <010f0179339912f8-4fc1b260-aadb-414e-a27e-b38f691c70ae-000000@us-east-2.amazonses.com> Message-ID: <010f0179343bca10-04f04739-1d7f-4ddb-b994-9aa853f9d82f-000000@us-east-2.amazonses.com> > On May 3, 2021, at 3:11 PM, Chris Smith wrote: > > Thanks, Richard. This is awesome! Glad you're excited. I am, too! > > For my use case, the more exciting possibility would be to interact with error messages from JavaScript. For this reason, I'd definitely love to see a well-known structured file format (JSON, YAML, XML, or whatever) that can be read without linking against GHC. I also like the idea of producing both the structured data and the raw string, since as you mention, one shouldn't need to handle every single possible GHC diagnostic just to add some special handling for a few of them. > > Ultimately, if reading error messages did require linking with GHC, it wouldn't be the end of the world. I would just write my own translation layer to JSON. So consider this a weak preference. It would be straightforward to, say, define instances of ToJSON and FromJSON for all of our error types. We could then serialize to JSON. The problem would be that these error types are likely to wibble and wobble between releases. (For now, I would say even between minor releases.) So if you don't link against GHC, you would have to stay on your toes to keep your parser up-to-date. Maybe this feature will settle down into a rhythm, and we can start to promise more stability, but I think it would be a mistake to promise that too soon. Linking against GHC protects you from making a mistake in this regard. On the other hand, the JSON output would be perfectly well formed independently of GHC, so there would be no hard requirement to do this linking. So that's one vote for JSON (where the JSON also includes the rendered string). Do I hear any others? (Note that these different modes of interaction are all pretty easy to build -- the hard part is the infrastructure supporting them -- so we can likely do more than one.) Thanks, Richard > > On Mon, May 3, 2021 at 3:00 PM Richard Eisenberg > wrote: > Hi all, > > Alfredo and I are hard at work redesigning GHC's error-message system. It is time for more input, though, from clients of the system -- those writing IDEs and other tooling on top of GHC. > > The key question: How would you like your errors served? > > Right now, errors are served well-done: fully cooked into structureless strings that can be easily given to users. The problem with this is that IDEs cannot easily intervene between GHC and the users, as all the nutrition (that is, detailed information) has been cooked away. > > The new design allows for *structured errors*, where error messages are represented by elements of some error type. Different messages have different constructors of this type, and these constructors can carry auxiliary information. GHC will store these errors raw and cook them (that is, turn them into readable strings) only right before printing them. If the raw messages were somehow passed to IDEs, then IDEs could handle them non-uniformly. (For example, if a module name and a file name are different, the IDE could just present a dialog to the user asking whether the user would like to change one automatically.) > > There are a few open questions: > > * In what vessel shall the raw messages be served? In other words, how do IDEs expect to interact with this new system? > - One route would be to pass e.g. -fjson-errors, which means that GHC presents the raw messages in a JSON format, for IDEs to parse. That's OK, but it still means that IDEs would have to have their own raw error message types to parse into. > - Another route would be for the IDE to link against GHC itself, and then invoke the compiler via a function call that returns the raw messages directly. > - Another route is some kind of middle ground, where the IDE passes e.g. -fbinary-errors= instructing GHC to write out a binary encoding of its messages to some file (or pipe, I suppose). These could then be deserialized back into GHC's own error types, but running in a separate process (linked against GHC, once again). > - I'm sure you can come up with other interaction strategies. > > * What will an IDE do with these messages? It might have special handling for some, but GHC has a lot of different messages, and I imagine IDEs will want many just to be printed to the user. If an IDE has only the raw message, then the IDE is forced to do all the cooking -- no good. So there must be a way to take a raw message and render it into a user-readable string. > - Maybe the above methods produce both the raw error and the rendered one? Then the IDE can choose which it prefers to use. > - GHC could easily export its pretty-printing functions that take in the raw messages and produce rendered ones. But that (again) requires linking against GHC. > > Note that we are not (here, yet) discussing errors served at points between raw and well-done, though I would like to do so. Such an error would be rendered into a format where textual bits are interleaved with more structured bits, which would enable e.g. clicking on expressions within error messages to get their types. That (important feature) comes separately. > > So: what do consumers want here? > > Preview: You can take a look at some raw error messages from the driver in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533 . > > Thanks! > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.ericson at obsidian.systems Mon May 3 22:04:18 2021 From: john.ericson at obsidian.systems (John Ericson) Date: Mon, 3 May 2021 18:04:18 -0400 Subject: structured error messages In-Reply-To: <010f0179343bca10-04f04739-1d7f-4ddb-b994-9aa853f9d82f-000000@us-east-2.amazonses.com> References: <010f0179339912f8-4fc1b260-aadb-414e-a27e-b38f691c70ae-000000@us-east-2.amazonses.com> <010f0179343bca10-04f04739-1d7f-4ddb-b994-9aa853f9d82f-000000@us-east-2.amazonses.com> Message-ID: > Ultimately, if reading error messages did require linking with GHC, it > wouldn't be the end of the world.  I would just write my own > translation layer to JSON.  So consider this a weak preference. I think this is the key. Ultimately, all other uses can be done on top of just linking GHC the library. Just as we have ghc-lib to paper over the differences between GHC versions and save individual projects from developing their own comparability layers, so we could also have some ghc-json library and tweaked frontend executable or something. The GHC repo has stringent CI and is somewhat a bottleneck already, so the more we can do out-of-band, the better, I say. John From simonpj at microsoft.com Tue May 4 13:46:57 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 May 2021 13:46:57 +0000 Subject: Warnings Message-ID: If 'transformers' purposely has orphan instances, shouldn't we switch off the warnings about them? Simon "/opt/ghc/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id transformers-0.5.6.2 -hide-all-packages -package-env - -i -ilibraries/transformers/. -ilibraries/transformers/dist-boot/build -Ilibraries/transformers/dist-boot/build -ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/. -optP-include -optPlibraries/transformers/dist-boot/build/./autogen/cabal_macros.h -package-id base-4.14.1.0 -XHaskell98 -no-user-package-db -rtsopts -fno-warn-unused-matches -fno-warn-unused-imports -fno-warn-deprecated-flags -outputdir libraries/transformers/dist-boot/build -c libraries/transformers/./Control/Applicative/Lift.hs -o libraries/transformers/dist-boot/build/Control/Applicative/Lift.o libraries/transformers/Control/Monad/Trans/Error.hs:98:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => Alternative (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 98 | instance (Error e) => Alternative (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... libraries/transformers/Control/Monad/Trans/Error.hs:103:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => MonadPlus (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 103 | instance (Error e) => MonadPlus (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue May 4 23:31:25 2021 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 04 May 2021 19:31:25 -0400 Subject: Warnings In-Reply-To: References: Message-ID: <875yzyjctu.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > If 'transformers' purposely has orphan instances, shouldn't we switch off the warnings about them? > Simon > We actually do so in Make, but strangely only in the stage2 build (see mk/warnings.mk). It's unclear to me why this is the case. I think the ideal solution is to add an OPTIONS_GHC -Wno-orphans pragma upstream in the affected module, although this would require getting code upstream which is a bit tiresome due it being in darcs. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From andreash87 at gmx.ch Mon May 10 08:01:34 2021 From: andreash87 at gmx.ch (Andreas Herrmann) Date: Mon, 10 May 2021 10:01:34 +0200 Subject: ZuriHac 2021 - GHC Track - Call for Contributions Message-ID: Dear GHC developers, This year's ZuriHac 2021 [1], online Friday 18th June to Sunday 20th June, will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Write a GHC extension in 30 minutes, by Richard Eisenberg - A tour of linear types and linear base, by Divesh Otwani - QualifiedDo: customizable 'do' syntax without fuss, by Facundo Dominguez - On "simple" constraints for typechecker plugins, by Nicolas Frisby Please let us know if you'd be interested in leading a session or a workshop. You can contact either Niklas or myself, on this list or by private message. Best, Andreas and Niklas ZuriHac 2021 GHC track coordinators [1]: https://zfoh.ch/zurihac2021/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon May 10 08:16:40 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 10 May 2021 08:16:40 +0000 Subject: ZuriHac 2021 - GHC Track - Call for Contributions In-Reply-To: References: Message-ID: Andreas, Niklas Would an "ask me anything" slot be useful? We could get a handful of GHC devs (eg me) together and invite participants to ask about GHC specifics. Not so much personal "how long have you worked on GHC?" but more technical "how does class instance lookup work?". I'd be willing. But it could fall a bit flat if no one asks anything... maybe prime the pump with one or two questions... Simon From: ghc-devs On Behalf Of Andreas Herrmann Sent: 10 May 2021 09:02 To: GHC developers Cc: Niklas Hambüchen Subject: ZuriHac 2021 - GHC Track - Call for Contributions Dear GHC developers, This year's ZuriHac 2021 [1], online Friday 18th June to Sunday 20th June, will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Write a GHC extension in 30 minutes, by Richard Eisenberg - A tour of linear types and linear base, by Divesh Otwani - QualifiedDo: customizable 'do' syntax without fuss, by Facundo Dominguez - On "simple" constraints for typechecker plugins, by Nicolas Frisby Please let us know if you'd be interested in leading a session or a workshop. You can contact either Niklas or myself, on this list or by private message. Best, Andreas and Niklas ZuriHac 2021 GHC track coordinators [1]: https://zfoh.ch/zurihac2021/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreash87 at gmx.ch Tue May 11 09:42:48 2021 From: andreash87 at gmx.ch (Andreas Herrmann) Date: Tue, 11 May 2021 11:42:48 +0200 Subject: ZuriHac 2021 - GHC Track - Call for Contributions In-Reply-To: References: Message-ID: Hi Simon, Yes, an AMA sounds like a great idea! Yes, absolutely, we could collect some questions ahead of time and then also give people the opportunity to submit questions during the event. Best, Andreas (Apologies for sending multiple times. Sent from the wrong email address and was rejected by the ghc-dev list.) On Mon, 10 May 2021 at 10:16, Simon Peyton Jones wrote: > Andreas, Niklas > > > > Would an “ask me anything” slot be useful? We could get a handful of GHC > devs (eg me) together and invite participants to ask about GHC specifics. > Not so much personal “how long have you worked on GHC?” but more technical > “how does class instance lookup work?”. > > > > I’d be willing. But it could fall a bit flat if no one asks anything… > maybe prime the pump with one or two questions… > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Andreas > Herrmann > *Sent:* 10 May 2021 09:02 > *To:* GHC developers > *Cc:* Niklas Hambüchen > *Subject:* ZuriHac 2021 - GHC Track - Call for Contributions > > > > Dear GHC developers, > > This year's ZuriHac 2021 [1], online Friday 18th June to Sunday 20th June, > will > again feature a dedicated GHC track to foster contributions to GHC and > teach > newcomers how to participate in GHC's development. > > For that we need your help: We would like to invite you to organize a > session > in the GHC track. This could be in form of a presentation, a workshop, or a > hack session with topics centered around GHC. > > For some inspiration, these are the subjects from last year's track: > - Write a GHC extension in 30 minutes, by Richard Eisenberg > - A tour of linear types and linear base, by Divesh Otwani > - QualifiedDo: customizable 'do' syntax without fuss, by Facundo Dominguez > - On "simple" constraints for typechecker plugins, by Nicolas Frisby > > Please let us know if you'd be interested in leading a session or a > workshop. > You can contact either Niklas or myself, on this list or by private > message. > > Best, > Andreas and Niklas > ZuriHac 2021 GHC track coordinators > > [1]: https://zfoh.ch/zurihac2021/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Thu May 13 15:55:53 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 13 May 2021 15:55:53 +0000 Subject: an issue tracker for better error messages Message-ID: <010f017966710422-ee243ac9-17c0-4acb-905e-fb37b17a5a6f-000000@us-east-2.amazonses.com> Hi devs, I've just posted https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-messages/2498 , a description of an idea to create an issue tracker dedicated only to error messages. My hope is that the tracker is used to boil issues users have with error messages down to a concrete suggestion for a wording change -- and that only when we have that concrete suggestion will a ticket be made on the GHC tracker. What do we think here of this idea? If you have a thought about the overall idea, I invite you to comment on Discourse; if you have a thought about GHC's response to this, this list seems like the best venue. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From xnningxie at gmail.com Sun May 16 22:43:06 2021 From: xnningxie at gmail.com (Ningning Xie) Date: Sun, 16 May 2021 18:43:06 -0400 Subject: Second Call for Talks: Haskell Implementors' Workshop @ ICFP'21 Message-ID: Call for Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2021. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldurpet at gmail.com Tue May 18 17:58:18 2021 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Tue, 18 May 2021 18:58:18 +0100 Subject: Coding style: Using StandaloneKindSignatures in GHC Message-ID: Discussion to permit use of StandaloneKindSignatures in the GHC coding style guide. I believe it increases the clarity of the code, especially as we move to fancier kinds. It is the only way we have for giving full signatures to type synonyms, type classes, type families and others. An example: type Cat :: Type -> Type type Cat ob = ob -> ob -> Type type Category :: forall ob. Cat ob -> Constraint class Category cat where id :: cat a a .. type Proxy :: forall k. k -> Type data Proxy a = Proxy type Some :: forall k. (k -> Type) -> Type data Some f where Some :: f ex -> Some f -- | The regular function type type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. TYPE1 rep1 -> TYPE rep2 -> Type type (->) = FUN 'Many This is in line with function definitions that are always given a top-level, standalone type signature (1) and not like we currently define type families/synonyms (2) by annotating each argument or not at all. Using -XStandaloneKindSignatures (3) matches (1) -- (1) curry :: ((a, b) -> c) -> (a -> b -> c) curry f x y = f (x, y) -- (2) type Curry (f :: (a, b) -> c) (x :: a) (y :: b) = f '(x, y) :: c -- (3) type Curry :: ((a, b) -> c) -> (a -> b -> c) type Curry f x y = f '(x, y) It covers an edgecase that `KindSignatures` don't. The only way for deriving to reference datatype arguments is if they are quantified by the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures allows us to still provide a full signature. We could write `newtype Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type -> Type` type Bin :: Type -> Type -> Type newtype Bin a b = Bin (a -> a -> b) deriving (Functor, Applicative) via (->) a `Compose` (->) a Let me know what you think From sgraf1337 at gmail.com Tue May 18 18:14:16 2021 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 18 May 2021 18:14:16 +0000 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: Message-ID: Hi Baldur, I'd be fine with declaring a SAKS whenever I'd need to specify a kind signature anyway. But so far I never needed to specify a kind in the data types or type synonyms I declare. I'd say that providing SAKS for types like `OrdList` or `State` where kinds are inferred just fine is overkill, but ultimately I won't fight if the majority likes to do that... Sebastian ------ Originalnachricht ------ Von: "Baldur Blöndal" An: ghc-devs at haskell.org Gesendet: 18.05.2021 19:58:18 Betreff: Coding style: Using StandaloneKindSignatures in GHC >Discussion to permit use of StandaloneKindSignatures in the GHC coding >style guide. I believe it increases the clarity of the code, >especially as we move to fancier kinds. > >It is the only way we have for giving full signatures to type >synonyms, type classes, type families and others. An example: > > type Cat :: Type -> Type > type Cat ob = ob -> ob -> Type > > type Category :: forall ob. Cat ob -> Constraint > class Category cat where > id :: cat a a .. > > type Proxy :: forall k. k -> Type > data Proxy a = Proxy > > type Some :: forall k. (k -> Type) -> Type > data Some f where > Some :: f ex -> Some f > > -- | The regular function type > type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. >TYPE1 rep1 -> TYPE rep2 -> Type > type (->) = FUN 'Many > >This is in line with function definitions that are always given a >top-level, standalone type signature (1) and not like we currently >define type families/synonyms (2) by annotating each argument or not >at all. Using -XStandaloneKindSignatures (3) matches (1) > > -- (1) > curry :: ((a, b) -> c) -> (a -> b -> c) > curry f x y = f (x, y) > > -- (2) > type Curry (f :: (a, b) -> c) (x :: a) (y :: b) = f '(x, y) :: c > > -- (3) > type Curry :: ((a, b) -> c) -> (a -> b -> c) > type Curry f x y = f '(x, y) > >It covers an edgecase that `KindSignatures` don't. The only way for >deriving to reference datatype arguments is if they are quantified by >the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures >allows us to still provide a full signature. We could write `newtype >Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type >-> Type` > > type Bin :: Type -> Type -> Type > newtype Bin a b = Bin (a -> a -> b) > deriving (Functor, Applicative) > via (->) a `Compose` (->) a > >Let me know what you think >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From hecate at glitchbra.in Tue May 18 18:18:19 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 18 May 2021 20:18:19 +0200 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: Message-ID: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> After reading this proposal, I agree that StandaloneKindSignatures ought to be encouraged in the codebases, and I vote that we mention them in the coding style¹. Cheers, Hécate ——— ¹ https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style Cheers, Hécate. Le 18/05/2021 à 19:58, Baldur Blöndal a écrit : > Discussion to permit use of StandaloneKindSignatures in the GHC coding > style guide. I believe it increases the clarity of the code, > especially as we move to fancier kinds. > > It is the only way we have for giving full signatures to type > synonyms, type classes, type families and others. An example: > > type Cat :: Type -> Type > type Cat ob = ob -> ob -> Type > > type Category :: forall ob. Cat ob -> Constraint > class Category cat where > id :: cat a a .. > > type Proxy :: forall k. k -> Type > data Proxy a = Proxy > > type Some :: forall k. (k -> Type) -> Type > data Some f where > Some :: f ex -> Some f > > -- | The regular function type > type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. > TYPE1 rep1 -> TYPE rep2 -> Type > type (->) = FUN 'Many > > This is in line with function definitions that are always given a > top-level, standalone type signature (1) and not like we currently > define type families/synonyms (2) by annotating each argument or not > at all. Using -XStandaloneKindSignatures (3) matches (1) > > -- (1) > curry :: ((a, b) -> c) -> (a -> b -> c) > curry f x y = f (x, y) > > -- (2) > type Curry (f :: (a, b) -> c) (x :: a) (y :: b) = f '(x, y) :: c > > -- (3) > type Curry :: ((a, b) -> c) -> (a -> b -> c) > type Curry f x y = f '(x, y) > > It covers an edgecase that `KindSignatures` don't. The only way for > deriving to reference datatype arguments is if they are quantified by > the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures > allows us to still provide a full signature. We could write `newtype > Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type > -> Type` > > type Bin :: Type -> Type -> Type > newtype Bin a b = Bin (a -> a -> b) > deriving (Functor, Applicative) > via (->) a `Compose` (->) a > > Let me know what you think > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD From oleg.grenrus at iki.fi Tue May 18 18:28:42 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 18 May 2021 21:28:42 +0300 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> Message-ID: First you have to solve the not so nice name clash of GHC...Type [1] and Data.Kind.Type [2] The former is all over the GHC code base, the latter is needed for (most) kind signatures, as * is not an option. - Oleg [1]: https://downloads.haskell.org/ghc/latest/docs/html/libraries/ghc-9.0.1/GHC-Tc-Utils-TcType.html#t:Type [2]: https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Kind.html#t:Type On 18.5.2021 21.18, Hécate wrote: > After reading this proposal, I agree that StandaloneKindSignatures > ought to be encouraged in the codebases, and I vote that we mention > them in the coding style¹. > > Cheers, > Hécate > > ——— > ¹ https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style > > Cheers, > Hécate. > > Le 18/05/2021 à 19:58, Baldur Blöndal a écrit : >> Discussion to permit use of StandaloneKindSignatures in the GHC coding >> style guide. I believe it increases the clarity of the code, >> especially as we move to fancier kinds. >> >> It is the only way we have for giving full signatures to type >> synonyms, type classes, type families and others. An example: >> >>      type Cat :: Type -> Type >>      type Cat ob = ob -> ob -> Type >> >>      type  Category :: forall ob. Cat ob -> Constraint >>      class Category cat where >>        id :: cat a a .. >> >>      type Proxy :: forall k. k -> Type >>      data Proxy a = Proxy >> >>      type Some :: forall k. (k -> Type) -> Type >>      data Some f where >>        Some :: f ex -> Some f >> >>      -- | The regular function type >>      type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. >> TYPE1 rep1 -> TYPE rep2 -> Type >>      type (->) = FUN 'Many >> >> This is in line with function definitions that are always given a >> top-level, standalone type signature (1) and not like we currently >> define type families/synonyms (2) by annotating each argument or not >> at all. Using -XStandaloneKindSignatures (3) matches (1) >> >>      -- (1) >>      curry :: ((a, b) -> c) -> (a -> b -> c) >>      curry f  x y = f (x, y) >> >>      -- (2) >>      type Curry (f :: (a, b) -> c) (x :: a) (y :: b) =  f '(x, y) :: c >> >>      -- (3) >>      type Curry :: ((a, b) -> c) -> (a -> b -> c) >>      type Curry f x y = f '(x, y) >> >> It covers an edgecase that `KindSignatures` don't. The only way for >> deriving to reference datatype arguments is if they are quantified by >> the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures >> allows us to still provide a full signature. We could write `newtype >> Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type >> -> Type` >> >>      type    Bin :: Type -> Type -> Type >>      newtype Bin a b = Bin (a -> a -> b) >>        deriving (Functor, Applicative) >>        via (->) a `Compose` (->) a >> >> Let me know what you think >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From rae at richarde.dev Tue May 18 18:41:41 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 18 May 2021 18:41:41 +0000 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> Message-ID: <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> Perhaps surprisingly, I'm against this proposal as part of the GHC style guide, for one reason: the vast majority of types within GHC have kind Type. Annotating all of these with a standalone kind signature just adds noise -- we can see they have kind Type just by seeing they have no parameter. On the other hand, I'm in support of encouraging the use of a standalone kind signature for type declarations where at least one parameter of the datatype does not have kind Type. In fact, I'd be in support of mandating (such as we can) such a standalone kind signature in our style guide. The cases where at least one parameter of a datatype does not have kind Type are the places we need the extra information. As for the naming conflict, that's fairly easy: we already have a GhcPrelude, and we can add, e.g. type T = Type to it. Richard > On May 18, 2021, at 2:28 PM, Oleg Grenrus wrote: > > First you have to solve the not so nice name clash of GHC...Type [1] and > Data.Kind.Type [2] > > The former is all over the GHC code base, the latter is needed for > (most) kind signatures, as * is not an option. > > - Oleg > > [1]: > https://downloads.haskell.org/ghc/latest/docs/html/libraries/ghc-9.0.1/GHC-Tc-Utils-TcType.html#t:Type > [2]: > https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Kind.html#t:Type > > On 18.5.2021 21.18, Hécate wrote: >> After reading this proposal, I agree that StandaloneKindSignatures >> ought to be encouraged in the codebases, and I vote that we mention >> them in the coding style¹. >> >> Cheers, >> Hécate >> >> ——— >> ¹ https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style >> >> Cheers, >> Hécate. >> >> Le 18/05/2021 à 19:58, Baldur Blöndal a écrit : >>> Discussion to permit use of StandaloneKindSignatures in the GHC coding >>> style guide. I believe it increases the clarity of the code, >>> especially as we move to fancier kinds. >>> >>> It is the only way we have for giving full signatures to type >>> synonyms, type classes, type families and others. An example: >>> >>> type Cat :: Type -> Type >>> type Cat ob = ob -> ob -> Type >>> >>> type Category :: forall ob. Cat ob -> Constraint >>> class Category cat where >>> id :: cat a a .. >>> >>> type Proxy :: forall k. k -> Type >>> data Proxy a = Proxy >>> >>> type Some :: forall k. (k -> Type) -> Type >>> data Some f where >>> Some :: f ex -> Some f >>> >>> -- | The regular function type >>> type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. >>> TYPE1 rep1 -> TYPE rep2 -> Type >>> type (->) = FUN 'Many >>> >>> This is in line with function definitions that are always given a >>> top-level, standalone type signature (1) and not like we currently >>> define type families/synonyms (2) by annotating each argument or not >>> at all. Using -XStandaloneKindSignatures (3) matches (1) >>> >>> -- (1) >>> curry :: ((a, b) -> c) -> (a -> b -> c) >>> curry f x y = f (x, y) >>> >>> -- (2) >>> type Curry (f :: (a, b) -> c) (x :: a) (y :: b) = f '(x, y) :: c >>> >>> -- (3) >>> type Curry :: ((a, b) -> c) -> (a -> b -> c) >>> type Curry f x y = f '(x, y) >>> >>> It covers an edgecase that `KindSignatures` don't. The only way for >>> deriving to reference datatype arguments is if they are quantified by >>> the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures >>> allows us to still provide a full signature. We could write `newtype >>> Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type >>> -> Type` >>> >>> type Bin :: Type -> Type -> Type >>> newtype Bin a b = Bin (a -> a -> b) >>> deriving (Functor, Applicative) >>> via (->) a `Compose` (->) a >>> >>> Let me know what you think >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From hecate at glitchbra.in Tue May 18 18:46:22 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 18 May 2021 20:46:22 +0200 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> Message-ID: Le 18/05/2021 à 20:41, Richard Eisenberg a écrit : > On the other hand, I'm in support of encouraging the use of a standalone kind signature for type declarations where at least one parameter of the datatype does not have kind Type. In fact, I'd be in support of mandating (such as we can) such a standalone kind signature in our style guide. The cases where at least one parameter of a datatype does not have kind Type are the places we need the extra information. This is indeed quite reasonable. I will follow you on that point. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD From simonpj at microsoft.com Tue May 18 20:41:10 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 18 May 2021 20:41:10 +0000 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> Message-ID: I'm all for "encourage" but not keen on "require". Simon | -----Original Message----- | From: ghc-devs On Behalf Of Hécate | Sent: 18 May 2021 19:18 | To: ghc-devs at haskell.org | Subject: Re: Coding style: Using StandaloneKindSignatures in GHC | | After reading this proposal, I agree that StandaloneKindSignatures ought | to be encouraged in the codebases, and I vote that we mention them in the | coding style¹. | | Cheers, | Hécate | | ——— | ¹ | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab. | haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fcommentary%2Fcoding- | style&data=04%7C01%7Csimonpj%40microsoft.com%7C526d76f0fe6f4bfad5b208 | d91a297bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63756958777303339 | 3%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xUV24DTEWYImjevJtWxK1hAB6QI0gX9dqvXm | 81jLOPo%3D&reserved=0 | | Cheers, | Hécate. | | Le 18/05/2021 à 19:58, Baldur Blöndal a écrit : | > Discussion to permit use of StandaloneKindSignatures in the GHC coding | > style guide. I believe it increases the clarity of the code, | > especially as we move to fancier kinds. | > | > It is the only way we have for giving full signatures to type | > synonyms, type classes, type families and others. An example: | > | > type Cat :: Type -> Type | > type Cat ob = ob -> ob -> Type | > | > type Category :: forall ob. Cat ob -> Constraint | > class Category cat where | > id :: cat a a .. | > | > type Proxy :: forall k. k -> Type | > data Proxy a = Proxy | > | > type Some :: forall k. (k -> Type) -> Type | > data Some f where | > Some :: f ex -> Some f | > | > -- | The regular function type | > type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. | > TYPE1 rep1 -> TYPE rep2 -> Type | > type (->) = FUN 'Many | > | > This is in line with function definitions that are always given a | > top-level, standalone type signature (1) and not like we currently | > define type families/synonyms (2) by annotating each argument or not | > at all. Using -XStandaloneKindSignatures (3) matches (1) | > | > -- (1) | > curry :: ((a, b) -> c) -> (a -> b -> c) | > curry f x y = f (x, y) | > | > -- (2) | > type Curry (f :: (a, b) -> c) (x :: a) (y :: b) = f '(x, y) :: c | > | > -- (3) | > type Curry :: ((a, b) -> c) -> (a -> b -> c) | > type Curry f x y = f '(x, y) | > | > It covers an edgecase that `KindSignatures` don't. The only way for | > deriving to reference datatype arguments is if they are quantified by | > the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures | > allows us to still provide a full signature. We could write `newtype | > Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type | > -> Type` | > | > type Bin :: Type -> Type -> Type | > newtype Bin a b = Bin (a -> a -> b) | > deriving (Functor, Applicative) | > via (->) a `Compose` (->) a | > | > Let me know what you think | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=04%7C01 | > %7Csimonpj%40microsoft.com%7C526d76f0fe6f4bfad5b208d91a297bd3%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C637569587773033393%7CUnknown%7CTW | > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 | > Mn0%3D%7C3000&sdata=Dc5Xbl2YJ%2BWmstt2z289UAzX9s%2BWJ5RuH84V2AbxJY | > c%3D&reserved=0 | | -- | Hécate ✨ | 🐦: @TechnoEmpress | IRC: Uniaika | WWW: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglitchb | ra.in%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C526d76f0fe6f4bfad5b | 208d91a297bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63756958777304 | 3386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 | Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KqNL0D9zC%2FiOORPEUqChk%2FTUxkekq | vxyZuyokFjcxMI%3D&reserved=0 | RUN: BSD | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=04%7C01%7Csimonpj%40microsoft.com%7C526d76f0fe6f4bfad5b208d | 91a297bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637569587773043386 | %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h | aWwiLCJXVCI6Mn0%3D%7C3000&sdata=yuGMW58YP7Grt4TrjtL5dahu0vSOP%2BYmV9I | zxLvrRxI%3D&reserved=0 From matthewtpickering at gmail.com Wed May 19 08:13:53 2021 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 19 May 2021 09:13:53 +0100 Subject: Darwin CI Status Message-ID: Hi all, The darwin pipelines are gumming up the merge pipeline as they are taking over 4 hours to complete on average. I am going to disable them - https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785 Please can someone give me access to one of the M1 builders so I can debug why the tests are taking so long. Once I have fixed the issue then I will enable the pipelines. Cheers, Matt From moritz.angermann at gmail.com Wed May 19 08:45:49 2021 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Wed, 19 May 2021 16:45:49 +0800 Subject: Darwin CI Status In-Reply-To: References: Message-ID: Matt has access to the M1 builder in my closet now. The darwin performance issue is mainly there since BigSur, and (afaik) primarily due to the amount of DYLD_LIBRARY_PATH's we pass to GHC invocations. The system linker spends the majority of the time in the kernel stat'ing and getelements (or some similar directory) call for each and every possible path. Switching to hadrian will cut down the time from ~5hs to ~2hs. At some point we had make builds <90min by just killing all DYLD_LIBRARY_PATH logic we ever had, but that broke bindists. The CI has time values attached and some summary at the end right now, which highlights time spent in the system and in user mode. This is up to 80% sys, 20% user, and went to something like 20% sys, 80% user after nuking all DYLD_LIBRARY_PATH's, with hadrian it's closer to ~25% sys, 75% user. Of note, this is mostly due to time spent during the *test-suite*, not the actual build. For the actual build make and hadrian are comparable, though I've seen hadrian to oddly have a much higher variance in how long it takes to *build* ghc, whereas the make build was more consistent. The test-suite quite notoriously calls GHC *a lot of times*, which makes any linker issue due to DYLD_LIBRARY_PATH (and similar lookups) much worse. If we would finally split building and testing, we'd see this more clearly I believe. Maybe this is motivation enough for someone to come forward to break build/test into two CI steps? Cheers, Moritz On Wed, May 19, 2021 at 4:14 PM Matthew Pickering < matthewtpickering at gmail.com> wrote: > Hi all, > > The darwin pipelines are gumming up the merge pipeline as they are > taking over 4 hours to complete on average. > > I am going to disable them - > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785 > > Please can someone give me access to one of the M1 builders so I can > debug why the tests are taking so long. Once I have fixed the issue > then I will enable the pipelines. > > Cheers, > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed May 19 12:56:23 2021 From: ben at well-typed.com (Ben Gamari) Date: Wed, 19 May 2021 08:56:23 -0400 Subject: GHC and the future of Freenode Message-ID: <877djuanm3.fsf@smart-cactus.org> Hi all, As you may have heard the Freenode IRC network, long the home of #ghc and several other prominent Haskell channels, appears to be in the middle of a rather nasty hostile takeover [1,2,3,4]. As a consequence, it seems it will be necessary to migrate the #ghc community elsewhere. The next question is, of course, where will this be. One option is Liberachat, the spiritual successor of Freenode. However, in recent years I have also heard an increasingly loud choir of users, contributors, and potential-contributors note how archane IRC feels when compared to other modern chat platforms. Using IRC effectively in a collaborative environment essentially requires that all parties use a bouncer; however, this is (understandably) isn't something that most users are willing to do. Consequently, I think it would be wise to expand our search space to include other FOSS platforms. At the moment, I can see the following options: 1. Remain on IRC and move to Liberachat, the spiritual successor of Freenode 2. Remain on IRC and move to OFTC, another widely used network 3. Move to [Matrix] 4. Move to [Zulip] My sense is that of the non-IRC options Matrix is the truest successor to IRC, being a federated protocol with a wide array of (if somewhat immature) clients. I know some of our contributors already use it and in principle one could configure an IRC-to-Matrix bridge for those existing contributors who would rather continue using IRC. Zulip, while also being FOSS, is far more centralized than Matrix and appears to be more of a chat web application than an open protocol. Do you know of any other options? Thoughts? Cheers, - Ben [1]: https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 [2]: https://fuchsnet.ch/freenode-resign-letter.txt [3]: https://gist.github.com/aaronmdjones/1a9a93ded5b7d162c3f58bdd66b8f491 [4]: https://mniip.com/freenode.txt [Matrix]: https://www.matrix.org/ [Zulip]: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sgraf1337 at gmail.com Wed May 19 13:36:20 2021 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Wed, 19 May 2021 13:36:20 +0000 Subject: GHC and the future of Freenode In-Reply-To: <877djuanm3.fsf@smart-cactus.org> References: <877djuanm3.fsf@smart-cactus.org> Message-ID: Hi, As one of those contributors that is already using the Matrix-to-freenode-IRC bridge through http://element.io/, I'd prefer moving to Matrix. And *if* we commit to a move, I suggest we don't move to another IRC server. That leaves Zulip vs. Matrix, both of which I'd be fine with. For some more data points: I know that the Lean community uses Zulip and they are pretty happy with it. The threading model seems to be pretty useful. On the other hand, it's so easy to open a new group chat in Matrix (and name it whatever you want) that it is pretty much the same as opening a new thread in Zulip. Our chair used to communicate via IRC, too. We considered switching to Zulip or Matrix in the past and ultimately decided in favor of Matrix, simply because most of us were already using element.io (+ the IRC bridge) for its mobile client and history logging. Cheers, Sebastian ------ Originalnachricht ------ Von: "Ben Gamari" An: "GHC developers" Gesendet: 19.05.2021 14:56:23 Betreff: GHC and the future of Freenode >Hi all, > >As you may have heard the Freenode IRC network, long the home of #ghc >and several other prominent Haskell channels, appears to be in the >middle of a rather nasty hostile takeover [1,2,3,4]. As a consequence, >it seems it will be necessary to migrate the #ghc community elsewhere. > >The next question is, of course, where will this be. One option is >Liberachat, the spiritual successor of Freenode. However, in recent >years I have also heard an increasingly loud choir of users, >contributors, and potential-contributors note how archane IRC feels when >compared to other modern chat platforms. Using IRC effectively in a >collaborative environment essentially requires that all parties use a >bouncer; however, this is (understandably) isn't something that most users >are willing to do. > >Consequently, I think it would be wise to expand our search space to >include other FOSS platforms. At the moment, I can see the following >options: > > 1. Remain on IRC and move to Liberachat, the spiritual successor of > Freenode > > 2. Remain on IRC and move to OFTC, another widely used network > > 3. Move to [Matrix] > > 4. Move to [Zulip] > >My sense is that of the non-IRC options Matrix is the truest successor >to IRC, being a federated protocol with a wide array of (if somewhat >immature) clients. I know some of our contributors already use it and in >principle one could configure an IRC-to-Matrix bridge for those existing >contributors who would rather continue using IRC. > >Zulip, while also being FOSS, is far more centralized than Matrix and >appears to be more of a chat web application than an open protocol. > >Do you know of any other options? Thoughts? > >Cheers, > >- Ben > > > >[1]: https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 >[2]: https://fuchsnet.ch/freenode-resign-letter.txt >[3]: https://gist.github.com/aaronmdjones/1a9a93ded5b7d162c3f58bdd66b8f491 >[4]: https://mniip.com/freenode.txt >[Matrix]: https://www.matrix.org/ >[Zulip]: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackhill at jackhill.us Wed May 19 15:38:29 2021 From: jackhill at jackhill.us (Jack Hill) Date: Wed, 19 May 2021 11:38:29 -0400 (EDT) Subject: GHC and the future of Freenode In-Reply-To: <877djuanm3.fsf@smart-cactus.org> References: <877djuanm3.fsf@smart-cactus.org> Message-ID: On Wed, 19 May 2021, Ben Gamari wrote: > Hi all, > > As you may have heard the Freenode IRC network, long the home of #ghc > and several other prominent Haskell channels, appears to be in the > middle of a rather nasty hostile takeover [1,2,3,4]. As a consequence, > it seems it will be necessary to migrate the #ghc community elsewhere. […] > Consequently, I think it would be wise to expand our search space to > include other FOSS platforms. At the moment, I can see the following > options: > > 1. Remain on IRC and move to Liberachat, the spiritual successor of > Freenode > > 2. Remain on IRC and move to OFTC, another widely used network > > 3. Move to [Matrix] > > 4. Move to [Zulip] > > My sense is that of the non-IRC options Matrix is the truest successor > to IRC, being a federated protocol with a wide array of (if somewhat > immature) clients. I know some of our contributors already use it and in > principle one could configure an IRC-to-Matrix bridge for those existing > contributors who would rather continue using IRC. > > Zulip, while also being FOSS, is far more centralized than Matrix and > appears to be more of a chat web application than an open protocol. > > Do you know of any other options? Thoughts? Ben, Thanks for starting this conversation. I don't have much standing here as up until now, I've only been an observer, but I did notice one option missing from the list, and that's an XMPP [0] MUC (multi-user chat, a chatroom). Like Matrix, it is also federated and has many client and (unlike Matrix) many server implementations. I also noticed that the cheogram folks are offering to host free and open source projects [1]. [0] https://xmpp.org/2021/01/instant-messaging-its-not-about-the-app/ [1] https://cheogram.com/freedomware-muc/ I can't advocate for one path or another. However, I'm still charting my one way, and am interested in seeing this option evaluated. A closing thought: it might be nice if #haskell and #ghc end up at the same place, although that might be difficult if the two groups have different needs. Best, Jack From carter.schonwald at gmail.com Wed May 19 15:48:55 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 19 May 2021 11:48:55 -0400 Subject: GHC and the future of Freenode In-Reply-To: <877djuanm3.fsf@smart-cactus.org> References: <877djuanm3.fsf@smart-cactus.org> Message-ID: I personally vote for irc. Perhaps via Libera. What are some example vibrant technical communities on matrix? I’ve experienced such on irc but less so via more recent / newer platforms On Wed, May 19, 2021 at 8:57 AM Ben Gamari wrote: > Hi all, > > As you may have heard the Freenode IRC network, long the home of #ghc > and several other prominent Haskell channels, appears to be in the > middle of a rather nasty hostile takeover [1,2,3,4]. As a consequence, > it seems it will be necessary to migrate the #ghc community elsewhere. > > The next question is, of course, where will this be. One option is > Liberachat, the spiritual successor of Freenode. However, in recent > years I have also heard an increasingly loud choir of users, > contributors, and potential-contributors note how archane IRC feels when > compared to other modern chat platforms. Using IRC effectively in a > collaborative environment essentially requires that all parties use a > bouncer; however, this is (understandably) isn't something that most users > are willing to do. > > Consequently, I think it would be wise to expand our search space to > include other FOSS platforms. At the moment, I can see the following > options: > > 1. Remain on IRC and move to Liberachat, the spiritual successor of > Freenode > > 2. Remain on IRC and move to OFTC, another widely used network > > 3. Move to [Matrix] > > 4. Move to [Zulip] > > My sense is that of the non-IRC options Matrix is the truest successor > to IRC, being a federated protocol with a wide array of (if somewhat > immature) clients. I know some of our contributors already use it and in > principle one could configure an IRC-to-Matrix bridge for those existing > contributors who would rather continue using IRC. > > Zulip, while also being FOSS, is far more centralized than Matrix and > appears to be more of a chat web application than an open protocol. > > Do you know of any other options? Thoughts? > > Cheers, > > - Ben > > > > [1]: https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 > [2]: https://fuchsnet.ch/freenode-resign-letter.txt > [3]: https://gist.github.com/aaronmdjones/1a9a93ded5b7d162c3f58bdd66b8f491 > [4]: https://mniip.com/freenode.txt > [Matrix]: https://www.matrix.org/ > [Zulip]: > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed May 19 15:57:06 2021 From: ben at well-typed.com (Ben Gamari) Date: Wed, 19 May 2021 11:57:06 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> Message-ID: <87wnru90og.fsf@smart-cactus.org> Carter Schonwald writes: > I personally vote for irc. Perhaps via Libera. > > What are some example vibrant technical communities on matrix? I’ve > experienced such on irc but less so via more recent / newer platforms > I know that many subcommunities within the Rust community use Matrix. I have had quite good interactions in this context. Frankly I think that most of these newer options are technically much more conducive to technical collaboration than IRC. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 483 bytes Desc: not available URL: From rpglover64 at gmail.com Wed May 19 18:39:22 2021 From: rpglover64 at gmail.com (Alex Rozenshteyn) Date: Wed, 19 May 2021 14:39:22 -0400 Subject: GHC and the future of Freenode In-Reply-To: <87wnru90og.fsf@smart-cactus.org> References: <877djuanm3.fsf@smart-cactus.org> <87wnru90og.fsf@smart-cactus.org> Message-ID: (I'm a little ashamed that I lurk on this list but the thing that brings me out of lurking is a post on communication technologies) Not Zulip. Please not Zulip. I've used Zulip once many years ago, and once this year. Both times, its interface felt clunky, and it felt like it was trying to get the best of IRC, Slack, and a BBS and instead getting the worst of all the worlds. Synchronous communication was confusing, asynchronous communication was limited, and topics and channels didn't really do anything to organize things. I have two alternatives to add to consideration: * Mattermost: it's an open-source clone of Slack, which has its advantages and disadvantages, but at least it's familiar and heavily used UI * Discourse: it's an asynchronous communication tool, but that may acceptable or preferable, and there is already a Haskell Discourse set up ( https://discourse.haskell.org/) On Wed, May 19, 2021 at 11:59 AM Ben Gamari wrote: > Carter Schonwald writes: > > > I personally vote for irc. Perhaps via Libera. > > > > What are some example vibrant technical communities on matrix? I’ve > > experienced such on irc but less so via more recent / newer platforms > > > I know that many subcommunities within the Rust community use Matrix. I > have had quite good interactions in this context. Frankly I think that > most of these newer options are technically much more conducive to > technical collaboration than IRC. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu May 20 01:58:24 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 19 May 2021 21:58:24 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87wnru90og.fsf@smart-cactus.org> Message-ID: I definitely find Zulip confusing and have failed to use it every time I’ve tried If normal threading is lasagna layers, Zulip threading is like trying to hold cooked spaghetti in your ha d. On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn wrote: > (I'm a little ashamed that I lurk on this list but the thing that brings > me out of lurking is a post on communication technologies) > > Not Zulip. > > Please not Zulip. > > I've used Zulip once many years ago, and once this year. Both times, its > interface felt clunky, and it felt like it was trying to get the best of > IRC, Slack, and a BBS and instead getting the worst of all the worlds. > Synchronous communication was confusing, asynchronous communication was > limited, and topics and channels didn't really do anything to organize > things. > > I have two alternatives to add to consideration: > * Mattermost: it's an open-source clone of Slack, which has its advantages > and disadvantages, but at least it's familiar and heavily used UI > * Discourse: it's an asynchronous communication tool, but that may > acceptable or preferable, and there is already a Haskell Discourse set up ( > https://discourse.haskell.org/) > > On Wed, May 19, 2021 at 11:59 AM Ben Gamari wrote: > >> Carter Schonwald writes: >> >> > I personally vote for irc. Perhaps via Libera. >> > >> > What are some example vibrant technical communities on matrix? I’ve >> > experienced such on irc but less so via more recent / newer platforms >> > >> I know that many subcommunities within the Rust community use Matrix. I >> have had quite good interactions in this context. Frankly I think that >> most of these newer options are technically much more conducive to >> technical collaboration than IRC. >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcarneir at andrew.cmu.edu Thu May 20 02:24:53 2021 From: mcarneir at andrew.cmu.edu (Mario Carneiro) Date: Wed, 19 May 2021 22:24:53 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87wnru90og.fsf@smart-cactus.org> Message-ID: Speaking as a *heavy* user of the Rust and Lean zulip instances, I find it a huge improvement over the alternatives of Gitter and Discord, and I think IRC although I have not used IRC much. It takes some getting used to, but the topic threading is absolutely essential once you reach a certain size. Looking at other chat platforms, overlapping conversations are a major problem when you have more than around 10 people online at once. Rust routinely has 50 or more online at once, and channels help but even then you will have multiple topics in a single channel, and that extra level of organization is absolutely warranted. It also helps when you want to look back at the discussion (or even just find it again!) or continue an old conversation from a year ago. Most of these activities I couldn't even imagine doing in a Gitter/Discord style chat platform. I have no stake in this discussion, but I thought I should balance out the Zulip downvotes with some positive experiences. (Also, I would definitely be more likely to participate on a haskell Zulip than an IRC or Matrix instance, FWIW.) Mario Carneiro On Wed, May 19, 2021 at 9:58 PM Carter Schonwald wrote: > I definitely find Zulip confusing and have failed to use it every time > I’ve tried > > If normal threading is lasagna layers, Zulip threading is like trying to > hold cooked spaghetti in your ha d. > > On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn > wrote: > >> (I'm a little ashamed that I lurk on this list but the thing that brings >> me out of lurking is a post on communication technologies) >> >> Not Zulip. >> >> Please not Zulip. >> >> I've used Zulip once many years ago, and once this year. Both times, its >> interface felt clunky, and it felt like it was trying to get the best of >> IRC, Slack, and a BBS and instead getting the worst of all the worlds. >> Synchronous communication was confusing, asynchronous communication was >> limited, and topics and channels didn't really do anything to organize >> things. >> >> I have two alternatives to add to consideration: >> * Mattermost: it's an open-source clone of Slack, which has its >> advantages and disadvantages, but at least it's familiar and heavily used UI >> * Discourse: it's an asynchronous communication tool, but that may >> acceptable or preferable, and there is already a Haskell Discourse set up ( >> https://discourse.haskell.org/) >> >> On Wed, May 19, 2021 at 11:59 AM Ben Gamari wrote: >> >>> Carter Schonwald writes: >>> >>> > I personally vote for irc. Perhaps via Libera. >>> > >>> > What are some example vibrant technical communities on matrix? I’ve >>> > experienced such on irc but less so via more recent / newer platforms >>> > >>> I know that many subcommunities within the Rust community use Matrix. I >>> have had quite good interactions in this context. Frankly I think that >>> most of these newer options are technically much more conducive to >>> technical collaboration than IRC. >>> >>> Cheers, >>> >>> - Ben >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpglover64 at gmail.com Thu May 20 02:38:48 2021 From: rpglover64 at gmail.com (Alex Rozenshteyn) Date: Wed, 19 May 2021 22:38:48 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87wnru90og.fsf@smart-cactus.org> Message-ID: Thanks for the perspective! I was not thinking of Gitter or Discord as being in the running for various reasons. On Wed, May 19, 2021, 22:27 Mario Carneiro wrote: > Speaking as a *heavy* user of the Rust and Lean zulip instances, I find it > a huge improvement over the alternatives of Gitter and Discord, and I think > IRC although I have not used IRC much. It takes some getting used to, but > the topic threading is absolutely essential once you reach a certain size. > Looking at other chat platforms, overlapping conversations are a major > problem when you have more than around 10 people online at once. Rust > routinely has 50 or more online at once, and channels help but even then > you will have multiple topics in a single channel, and that extra level of > organization is absolutely warranted. It also helps when you want to look > back at the discussion (or even just find it again!) or continue an old > conversation from a year ago. Most of these activities I couldn't even > imagine doing in a Gitter/Discord style chat platform. > > I have no stake in this discussion, but I thought I should balance out the > Zulip downvotes with some positive experiences. (Also, I would definitely > be more likely to participate on a haskell Zulip than an IRC or Matrix > instance, FWIW.) > > Mario Carneiro > > On Wed, May 19, 2021 at 9:58 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> I definitely find Zulip confusing and have failed to use it every time >> I’ve tried >> >> If normal threading is lasagna layers, Zulip threading is like trying to >> hold cooked spaghetti in your ha d. >> >> On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn >> wrote: >> >>> (I'm a little ashamed that I lurk on this list but the thing that brings >>> me out of lurking is a post on communication technologies) >>> >>> Not Zulip. >>> >>> Please not Zulip. >>> >>> I've used Zulip once many years ago, and once this year. Both times, its >>> interface felt clunky, and it felt like it was trying to get the best of >>> IRC, Slack, and a BBS and instead getting the worst of all the worlds. >>> Synchronous communication was confusing, asynchronous communication was >>> limited, and topics and channels didn't really do anything to organize >>> things. >>> >>> I have two alternatives to add to consideration: >>> * Mattermost: it's an open-source clone of Slack, which has its >>> advantages and disadvantages, but at least it's familiar and heavily used UI >>> * Discourse: it's an asynchronous communication tool, but that may >>> acceptable or preferable, and there is already a Haskell Discourse set up ( >>> https://discourse.haskell.org/) >>> >>> On Wed, May 19, 2021 at 11:59 AM Ben Gamari wrote: >>> >>>> Carter Schonwald writes: >>>> >>>> > I personally vote for irc. Perhaps via Libera. >>>> > >>>> > What are some example vibrant technical communities on matrix? I’ve >>>> > experienced such on irc but less so via more recent / newer platforms >>>> > >>>> I know that many subcommunities within the Rust community use Matrix. I >>>> have had quite good interactions in this context. Frankly I think that >>>> most of these newer options are technically much more conducive to >>>> technical collaboration than IRC. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Thu May 20 02:39:53 2021 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Wed, 19 May 2021 22:39:53 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87wnru90og.fsf@smart-cactus.org> Message-ID: I've been using the recently created Types Zulip (for academic PL) -- my first experience with this platform -- and also found it unusual at first but then quite liked the dynamic topics thing (exactly for reasons Mario describes). Zulip or anything from 21st century would be a huge improvement on status quo (i.e. IRC) in terms of attraction of new contributors. Think the Phabricator –> GitLab transition but in the IM space. -- Best, Artem On Wed, May 19, 2021, 10:26 PM Mario Carneiro wrote: > Speaking as a *heavy* user of the Rust and Lean zulip instances, I find it > a huge improvement over the alternatives of Gitter and Discord, and I think > IRC although I have not used IRC much. It takes some getting used to, but > the topic threading is absolutely essential once you reach a certain size. > Looking at other chat platforms, overlapping conversations are a major > problem when you have more than around 10 people online at once. Rust > routinely has 50 or more online at once, and channels help but even then > you will have multiple topics in a single channel, and that extra level of > organization is absolutely warranted. It also helps when you want to look > back at the discussion (or even just find it again!) or continue an old > conversation from a year ago. Most of these activities I couldn't even > imagine doing in a Gitter/Discord style chat platform. > > I have no stake in this discussion, but I thought I should balance out the > Zulip downvotes with some positive experiences. (Also, I would definitely > be more likely to participate on a haskell Zulip than an IRC or Matrix > instance, FWIW.) > > Mario Carneiro > > On Wed, May 19, 2021 at 9:58 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> I definitely find Zulip confusing and have failed to use it every time >> I’ve tried >> >> If normal threading is lasagna layers, Zulip threading is like trying to >> hold cooked spaghetti in your ha d. >> >> On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn >> wrote: >> >>> (I'm a little ashamed that I lurk on this list but the thing that brings >>> me out of lurking is a post on communication technologies) >>> >>> Not Zulip. >>> >>> Please not Zulip. >>> >>> I've used Zulip once many years ago, and once this year. Both times, its >>> interface felt clunky, and it felt like it was trying to get the best of >>> IRC, Slack, and a BBS and instead getting the worst of all the worlds. >>> Synchronous communication was confusing, asynchronous communication was >>> limited, and topics and channels didn't really do anything to organize >>> things. >>> >>> I have two alternatives to add to consideration: >>> * Mattermost: it's an open-source clone of Slack, which has its >>> advantages and disadvantages, but at least it's familiar and heavily used UI >>> * Discourse: it's an asynchronous communication tool, but that may >>> acceptable or preferable, and there is already a Haskell Discourse set up ( >>> https://discourse.haskell.org/) >>> >>> On Wed, May 19, 2021 at 11:59 AM Ben Gamari wrote: >>> >>>> Carter Schonwald writes: >>>> >>>> > I personally vote for irc. Perhaps via Libera. >>>> > >>>> > What are some example vibrant technical communities on matrix? I’ve >>>> > experienced such on irc but less so via more recent / newer platforms >>>> > >>>> I know that many subcommunities within the Rust community use Matrix. I >>>> have had quite good interactions in this context. Frankly I think that >>>> most of these newer options are technically much more conducive to >>>> technical collaboration than IRC. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu May 20 07:59:38 2021 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 20 May 2021 08:59:38 +0100 Subject: Darwin CI Status In-Reply-To: References: Message-ID: Thanks Moritz for that update. The latest is that currently darwin CI is disabled and the merge train is unblocked (*choo choo*). I am testing Moritz's patches to speed-up CI and will merge them in shortly to get darwin coverage back. Cheers, Matt On Wed, May 19, 2021 at 9:46 AM Moritz Angermann wrote: > > Matt has access to the M1 builder in my closet now. The darwin performance issue > is mainly there since BigSur, and (afaik) primarily due to the amount of DYLD_LIBRARY_PATH's > we pass to GHC invocations. The system linker spends the majority of the time in the > kernel stat'ing and getelements (or some similar directory) call for each and every possible > path. > > Switching to hadrian will cut down the time from ~5hs to ~2hs. At some point we had make > builds <90min by just killing all DYLD_LIBRARY_PATH logic we ever had, but that broke > bindists. > > The CI has time values attached and some summary at the end right now, which highlights > time spent in the system and in user mode. This is up to 80% sys, 20% user, and went to > something like 20% sys, 80% user after nuking all DYLD_LIBRARY_PATH's, with hadrian it's > closer to ~25% sys, 75% user. > > Of note, this is mostly due to time spent during the *test-suite*, not the actual build. For the > actual build make and hadrian are comparable, though I've seen hadrian to oddly have a > much higher variance in how long it takes to *build* ghc, whereas the make build was more > consistent. > > The test-suite quite notoriously calls GHC *a lot of times*, which makes any linker issue due > to DYLD_LIBRARY_PATH (and similar lookups) much worse. > > If we would finally split building and testing, we'd see this more clearly I believe. Maybe this > is motivation enough for someone to come forward to break build/test into two CI steps? > > Cheers, > Moritz > > On Wed, May 19, 2021 at 4:14 PM Matthew Pickering wrote: >> >> Hi all, >> >> The darwin pipelines are gumming up the merge pipeline as they are >> taking over 4 hours to complete on average. >> >> I am going to disable them - >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785 >> >> Please can someone give me access to one of the M1 builders so I can >> debug why the tests are taking so long. Once I have fixed the issue >> then I will enable the pipelines. >> >> Cheers, >> >> Matt From carter.schonwald at gmail.com Thu May 20 13:21:53 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 20 May 2021 09:21:53 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87wnru90og.fsf@smart-cactus.org> Message-ID: I’ll try again. On Wed, May 19, 2021 at 10:26 PM Mario Carneiro wrote: > Speaking as a *heavy* user of the Rust and Lean zulip instances, I find it > a huge improvement over the alternatives of Gitter and Discord, and I think > IRC although I have not used IRC much. It takes some getting used to, but > the topic threading is absolutely essential once you reach a certain size. > Looking at other chat platforms, overlapping conversations are a major > problem when you have more than around 10 people online at once. Rust > routinely has 50 or more online at once, and channels help but even then > you will have multiple topics in a single channel, and that extra level of > organization is absolutely warranted. It also helps when you want to look > back at the discussion (or even just find it again!) or continue an old > conversation from a year ago. Most of these activities I couldn't even > imagine doing in a Gitter/Discord style chat platform. > > I have no stake in this discussion, but I thought I should balance out the > Zulip downvotes with some positive experiences. (Also, I would definitely > be more likely to participate on a haskell Zulip than an IRC or Matrix > instance, FWIW.) > > > Mario Carneiro > > On Wed, May 19, 2021 at 9:58 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> I definitely find Zulip confusing and have failed to use it every time >> I’ve tried >> >> If normal threading is lasagna layers, Zulip threading is like trying to >> hold cooked spaghetti in your ha d. >> >> On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn >> wrote: >> >>> (I'm a little ashamed that I lurk on this list but the thing that brings >>> me out of lurking is a post on communication technologies) >>> >>> Not Zulip. >>> >>> Please not Zulip. >>> >>> I've used Zulip once many years ago, and once this year. Both times, its >>> interface felt clunky, and it felt like it was trying to get the best of >>> IRC, Slack, and a BBS and instead getting the worst of all the worlds. >>> Synchronous communication was confusing, asynchronous communication was >>> limited, and topics and channels didn't really do anything to organize >>> things. >>> >>> I have two alternatives to add to consideration: >>> * Mattermost: it's an open-source clone of Slack, which has its >>> advantages and disadvantages, but at least it's familiar and heavily used UI >>> * Discourse: it's an asynchronous communication tool, but that may >>> acceptable or preferable, and there is already a Haskell Discourse set up ( >>> https://discourse.haskell.org/) >>> >>> On Wed, May 19, 2021 at 11:59 AM Ben Gamari wrote: >>> >>>> Carter Schonwald writes: >>>> >>>> > I personally vote for irc. Perhaps via Libera. >>>> > >>>> > What are some example vibrant technical communities on matrix? I’ve >>>> > experienced such on irc but less so via more recent / newer platforms >>>> > >>>> I know that many subcommunities within the Rust community use Matrix. I >>>> have had quite good interactions in this context. Frankly I think that >>>> most of these newer options are technically much more conducive to >>>> technical collaboration than IRC. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldurpet at gmail.com Fri May 21 06:11:35 2021 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Fri, 21 May 2021 07:11:35 +0100 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> Message-ID: > encouraging the use of a standalone signature for type declarations where at least one parameter of the datatype does not have kind Type. So Dict, Eq both get a sig but Fix and Either do not? type Dict :: Constraint -> Type type Eq :: Type -> Constraint type Fix :: (Type -> Type) -> Type It's sensible to exclude tired tropes like `Type` and `Type -> Type` but higher-order functors (like Fix) warrant a signature. Caveat: The kind of type synonyms, type families and data families is not necessarily determined by counting the syntactic arguments of X like for a `data' declaration as Y could be a type, a functor, a bifunctor.. type X = Y From juhpetersen at gmail.com Fri May 21 11:13:52 2021 From: juhpetersen at gmail.com (Jens Petersen) Date: Fri, 21 May 2021 19:13:52 +0800 Subject: GHC and the future of Freenode In-Reply-To: <877djuanm3.fsf@smart-cactus.org> References: <877djuanm3.fsf@smart-cactus.org> Message-ID: My vote goes for Matrix. I am not a heavy user yet, but I hope this episode helps to drive more people to it away from irc. Having half the people on Freenode and the other half on Libera seems the worst possible outcome in the short- to mid-term. The Fedora project also has plans to move to Matrix as its main group chat messaging platform. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz.angermann at gmail.com Fri May 21 11:37:57 2021 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 21 May 2021 19:37:57 +0800 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> Message-ID: Fair point. From a view over the last few days, I’d say it’s closer to 100% on libera. Lots of people just switched. Quite surprising. On Fri, 21 May 2021 at 7:14 PM, Jens Petersen wrote: > My vote goes for Matrix. > > I am not a heavy user yet, but I hope this episode helps to drive more > people to it away from irc. > Having half the people on Freenode and the other half on Libera seems the > worst possible outcome in the short- to mid-term. > The Fedora project also has plans to move to Matrix as its main group chat > messaging platform. > > Jens > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri May 21 14:22:49 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 21 May 2021 10:22:49 -0400 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> Message-ID: Silly question: when will stand alone kind sigs speed up type checking phase of compilation? Cause that would be an interesting argument in favor :) On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal wrote: > > encouraging the use of a standalone signature for type declarations > where at least one parameter of the datatype does not have kind Type. > > So Dict, Eq both get a sig but Fix and Either do not? > > type Dict :: Constraint -> Type > type Eq :: Type -> Constraint > type Fix :: (Type -> Type) -> Type > > It's sensible to exclude tired tropes like `Type` and `Type -> Type` > but higher-order functors (like Fix) warrant a signature. > > Caveat: The kind of type synonyms, type families and data families is > not necessarily determined by counting the syntactic arguments of X > like for a `data' declaration as Y could be a type, a functor, a > bifunctor.. > > type X = Y > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri May 21 14:31:28 2021 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 21 May 2021 10:31:28 -0400 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> Message-ID: <87o8d488ga.fsf@smart-cactus.org> Carter Schonwald writes: > Silly question: when will stand alone kind sigs speed up type checking > phase of compilation? > I'm not hopeful that the sort of kind signatures given by Baldur could ever significantly affect compilation performance. As far as I can tell, inferring such simple signatures just isn't that much work compared to everything else that the compiler does. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From iavor.diatchki at gmail.com Fri May 21 16:23:46 2021 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 21 May 2021 09:23:46 -0700 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> Message-ID: Hello, I am not a heavy IRC user, but I'd say it makes most sense to just use Libera. It is essentially the same people that were running free-node running pretty much the exact same service, and I believe they are trying to make it extra easy to just switch, so this should be the least effort transition. I believe IRC has served the GHC community quite well so far, and there is a reddit post by Ed Kmett that the normal Haskell channels have already been transitioned over, so I think it makes sense for GHC to stick with the rest of the Haskell community. -Iavor On Fri, May 21, 2021 at 4:38 AM Moritz Angermann wrote: > Fair point. From a view over the last few days, I’d say it’s closer to > 100% on libera. Lots of people just switched. Quite surprising. > > On Fri, 21 May 2021 at 7:14 PM, Jens Petersen > wrote: > >> My vote goes for Matrix. >> >> I am not a heavy user yet, but I hope this episode helps to drive more >> people to it away from irc. >> Having half the people on Freenode and the other half on Libera seems the >> worst possible outcome in the short- to mid-term. >> The Fedora project also has plans to move to Matrix as its main group >> chat messaging platform. >> >> Jens >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Fri May 21 16:37:51 2021 From: cdsmith at gmail.com (Chris Smith) Date: Fri, 21 May 2021 12:37:51 -0400 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> Message-ID: On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal wrote: > > encouraging the use of a standalone signature for type declarations > where at least one parameter of the datatype does not have kind Type. > > So Dict, Eq both get a sig but Fix and Either do not? > > type Dict :: Constraint -> Type > type Eq :: Type -> Constraint > type Fix :: (Type -> Type) -> Type That's not how I understand Richard's criteria. Dict and Fix have non-Type parameters (Dict has a Constraint parameter, and Fix has a (Type -> Type) parameter. On the other hand, Eq and Either have only Types as parameters. This seems to match my intuition about when a kind signature might be helpful, as well as yours as far as I can tell from what you wrote. That's not to say I am advocating any kind of rule. As I'm not really involved in GHC development, I refrain from having any opinion. I just think you may have misread Richard's suggestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri May 21 17:41:38 2021 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 21 May 2021 13:41:38 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> Message-ID: <87lf887zn4.fsf@smart-cactus.org> Iavor Diatchki writes: > Hello, > > I am not a heavy IRC user, but I'd say it makes most sense to just use > Libera. It is essentially the same people that were running free-node > running pretty much the exact same service, and I believe they are trying > to make it extra easy to just switch, so this should be the least effort > transition. > > I believe IRC has served the GHC community quite well so far, and there is > a reddit post by Ed Kmett that the normal Haskell channels have already > been transitioned over, so I think it makes sense for GHC to stick with the > rest of the Haskell community. > The problem is that, in order to grow (or even merely not to shrink), the community also needs to adapt to the preferences of younger users. The fact of the matter is the younger users tend to be, at best, unfamiliar with IRC. In the worst case, the need to leave a browser/sign up for a new account means that they simply won't participate. Of the new contributors I have had approach me in the past year, less than half have had any familiarity with IRC. Matrix has the advantage of being accessible to "web-native" community members while being open enough to (at least in principle) allow community members who are accustomed to IRC to continue to participate via a bridge. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From iavor.diatchki at gmail.com Fri May 21 20:00:16 2021 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 21 May 2021 13:00:16 -0700 Subject: GHC and the future of Freenode In-Reply-To: <87lf887zn4.fsf@smart-cactus.org> References: <877djuanm3.fsf@smart-cactus.org> <87lf887zn4.fsf@smart-cactus.org> Message-ID: As I said, I am not a heavy IRC user, for my online chatting needs I mostly use Mattermost, Discord, and Slack. So I don't have an informed opinion on the technical merits of the various platforms---mostly I've heard that the Matrix clients and servers are quite a bit less robust than IRC ones but I've never personally used them. If there is a feeling that GHC wants to use a new chatting platform, by all means we should try it out. I just don't think that the unfortunate situation with free-node is a good reason to drop IRC entirely. Despite its flows, I think it has served our community well, and while it may look "old" to "young" users it does have the benefit of being pretty stable, unlike the myriad of chatting services that seem to be popping up all the time. -Iavor On Fri, May 21, 2021 at 10:41 AM Ben Gamari wrote: > Iavor Diatchki writes: > > > Hello, > > > > I am not a heavy IRC user, but I'd say it makes most sense to just use > > Libera. It is essentially the same people that were running free-node > > running pretty much the exact same service, and I believe they are trying > > to make it extra easy to just switch, so this should be the least effort > > transition. > > > > I believe IRC has served the GHC community quite well so far, and there > is > > a reddit post by Ed Kmett that the normal Haskell channels have already > > been transitioned over, so I think it makes sense for GHC to stick with > the > > rest of the Haskell community. > > > The problem is that, in order to grow (or even merely not to shrink), > the community also needs to adapt to the preferences of younger users. > > The fact of the matter is the younger users tend to be, at best, > unfamiliar with IRC. In the worst case, the need to leave a browser/sign > up for a new account means that they simply won't participate. Of the > new contributors I have had approach me in the past year, less than half > have had any familiarity with IRC. > > Matrix has the advantage of being accessible to "web-native" community > members while being open enough to (at least in principle) allow > community members who are accustomed to IRC to continue to participate > via a bridge. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Fri May 21 20:21:19 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 21 May 2021 20:21:19 +0000 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> Message-ID: <010f01799096e89c-6b4dab11-2b48-49a3-a2f9-e1b4e558800d-000000@us-east-2.amazonses.com> I agree with Chris here. Let me expand upon my counter-proposal: * A datatype declaration gets a standalone kind signature whenever at least one of its type arguments has a kind other than Type. * A class declaration gets a standalone kind signature whenever at least one of its type arguments has a kind other than Type.(*) * A closed type family always gets a standalone kind signature. * A type synonym gets a standalone kind signature whenever either at least one of its arguments has a kind other than Type or its result has a kind other than Type. (*) The class rule has an exception: if a class has a superclass constraint using Monad, Functor, Applicative, Foldable, or Traversable (or some other class whose name textually includes one of those names, such as MonadIO), we understand that the constrained variable must have kind Type -> Type. If that type variable is the only one without kind Type -> Type, then the standalone kind signature is optional. In cases other than those covered above, the standalone kind signature is optional, at the discretion of the programmer. This suggests that Dict gets a signature, Eq does not, Fix does, and Either does not. Richard > On May 21, 2021, at 12:37 PM, Chris Smith wrote: > > On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal > wrote: > > encouraging the use of a standalone signature for type declarations where at least one parameter of the datatype does not have kind Type. > > So Dict, Eq both get a sig but Fix and Either do not? > > type Dict :: Constraint -> Type > type Eq :: Type -> Constraint > type Fix :: (Type -> Type) -> Type > > That's not how I understand Richard's criteria. Dict and Fix have non-Type parameters (Dict has a Constraint parameter, and Fix has a (Type -> Type) parameter. On the other hand, Eq and Either have only Types as parameters. This seems to match my intuition about when a kind signature might be helpful, as well as yours as far as I can tell from what you wrote. > > That's not to say I am advocating any kind of rule. As I'm not really involved in GHC development, I refrain from having any opinion. I just think you may have misread Richard's suggestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 21 22:19:56 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 21 May 2021 22:19:56 +0000 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: <010f01799096e89c-6b4dab11-2b48-49a3-a2f9-e1b4e558800d-000000@us-east-2.amazonses.com> References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> <010f01799096e89c-6b4dab11-2b48-49a3-a2f9-e1b4e558800d-000000@us-east-2.amazonses.com> Message-ID: I’m good with those rules. Simon From: ghc-devs On Behalf Of Richard Eisenberg Sent: 21 May 2021 21:21 To: Chris Smith Cc: GHC developers Subject: Re: Coding style: Using StandaloneKindSignatures in GHC I agree with Chris here. Let me expand upon my counter-proposal: * A datatype declaration gets a standalone kind signature whenever at least one of its type arguments has a kind other than Type. * A class declaration gets a standalone kind signature whenever at least one of its type arguments has a kind other than Type.(*) * A closed type family always gets a standalone kind signature. * A type synonym gets a standalone kind signature whenever either at least one of its arguments has a kind other than Type or its result has a kind other than Type. (*) The class rule has an exception: if a class has a superclass constraint using Monad, Functor, Applicative, Foldable, or Traversable (or some other class whose name textually includes one of those names, such as MonadIO), we understand that the constrained variable must have kind Type -> Type. If that type variable is the only one without kind Type -> Type, then the standalone kind signature is optional. In cases other than those covered above, the standalone kind signature is optional, at the discretion of the programmer. This suggests that Dict gets a signature, Eq does not, Fix does, and Either does not. Richard On May 21, 2021, at 12:37 PM, Chris Smith > wrote: On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal > wrote: > encouraging the use of a standalone signature for type declarations where at least one parameter of the datatype does not have kind Type. So Dict, Eq both get a sig but Fix and Either do not? type Dict :: Constraint -> Type type Eq :: Type -> Constraint type Fix :: (Type -> Type) -> Type That's not how I understand Richard's criteria. Dict and Fix have non-Type parameters (Dict has a Constraint parameter, and Fix has a (Type -> Type) parameter. On the other hand, Eq and Either have only Types as parameters. This seems to match my intuition about when a kind signature might be helpful, as well as yours as far as I can tell from what you wrote. That's not to say I am advocating any kind of rule. As I'm not really involved in GHC development, I refrain from having any opinion. I just think you may have misread Richard's suggestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Sat May 22 06:31:00 2021 From: imantc at gmail.com (Imants Cekusins) Date: Sat, 22 May 2021 09:31:00 +0300 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87lf887zn4.fsf@smart-cactus.org> Message-ID: Was this a temporary issue with Freenode IRC, resolved by now? https://freenode.net/news/freenode-is-foss From cdsmith at gmail.com Sat May 22 13:41:34 2021 From: cdsmith at gmail.com (Chris Smith) Date: Sat, 22 May 2021 09:41:34 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87lf887zn4.fsf@smart-cactus.org> Message-ID: No, unfortunately, this is not resolved. The link here is a fictitious whitewash of events posted by the person who conducted the hostile takeover of Freenode. At the moment, the state of Freenode is that it's still operating as an IRC network, but the volunteer staff who have operated the network for many years have resigned and at least many of them have moved to operating irc.libera.chat. The network is completely controlled by one person, who wasn't involved in running it at all until a few days ago. On Sat, May 22, 2021 at 2:31 AM Imants Cekusins wrote: > Was this a temporary issue with Freenode IRC, resolved by now? > > https://freenode.net/news/freenode-is-foss > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivam98.tkg at gmail.com Sat May 22 15:24:23 2021 From: shivam98.tkg at gmail.com (Shivam Gupta) Date: Sat, 22 May 2021 20:54:23 +0530 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87lf887zn4.fsf@smart-cactus.org> Message-ID: LLVM uses discord and it works fine. On Sat, May 22, 2021 at 7:12 PM Chris Smith wrote: > No, unfortunately, this is not resolved. The link here is a fictitious > whitewash of events posted by the person who conducted the hostile takeover > of Freenode. At the moment, the state of Freenode is that it's still > operating as an IRC network, but the volunteer staff who have operated the > network for many years have resigned and at least many of them have moved > to operating irc.libera.chat. The network is completely controlled by one > person, who wasn't involved in running it at all until a few days ago. > > On Sat, May 22, 2021 at 2:31 AM Imants Cekusins wrote: > >> Was this a temporary issue with Freenode IRC, resolved by now? >> >> https://freenode.net/news/freenode-is-foss >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.ericson at obsidian.systems Sat May 22 18:50:42 2021 From: john.ericson at obsidian.systems (John Ericson) Date: Sat, 22 May 2021 14:50:42 -0400 Subject: GHC and the future of Freenode In-Reply-To: References: <877djuanm3.fsf@smart-cactus.org> <87lf887zn4.fsf@smart-cactus.org> Message-ID: As Ben and others say, Matrix provides many modern features new users will expect, while preserving the spirit of IRC. Without wading into the details, the design of Matrix I find impressive and to my liking, and it has seemed to get steadily better over time for quite a while now. Re Zulip, in https://news.ycombinator.com/item?id=27202838 one of the lead Matrix devs says their up-and-coming threading model aims to support what Zulip does and they've been discussing deeper integration with Zulip. Granted, It would be better to hear about those discussions from the Zulip side as Matrix aims to assimilate everything and Zulip could have some reservations, but I remain hopeful. (I certainly would like to see culled the current explosion of mutually-incompatible chat applications, leaving us with fewer protocols but as many competing implementations.) What I recommend for now that we make some official Matrix channels, but also bridge them with the libera.chat ones once the bridge is up (should be a few days). Creating a matrix room and bridging it is a bit different underneath the hood than using a channel generated by the bridge on demand. We can give them nice names on the matrix side, and basically keep both options open of being "IRC-first" or "Matrix-first" down the road. For reference, see https://matrix.to/#/#community:nixos.org?via=nixos.org which is the Matrix "Space" (room that is a directory of sub-rooms, filling the role of a Discord "server") that Nix community created while they debate what to do next. See also https://github.com/NixOS/rfcs/pull/94 where this same discussion is playing out. John On 5/21/21 4:00 PM, Iavor Diatchki wrote: > As I said, I am not a heavy IRC user, for my online chatting needs I > mostly use Mattermost, Discord, and Slack. So I don't have an informed > opinion on the technical merits of the various platforms---mostly I've > heard that the Matrix clients and servers are quite a bit less robust > than IRC ones but I've never personally used them. > > If there is a feeling that GHC wants to use a new chatting platform, > by all means we should try it out.  I just don't think that the > unfortunate situation with free-node is a good reason to drop IRC > entirely.   Despite its flows, I think it has served our community > well, and while it may look "old" to "young" users it does have the > benefit of being pretty stable, unlike the myriad of chatting services > that seem to be popping up all the time. > > -Iavor > > > > On Fri, May 21, 2021 at 10:41 AM Ben Gamari > wrote: > > Iavor Diatchki > writes: > > > Hello, > > > > I am not a heavy IRC user, but I'd say it makes most sense to > just use > > Libera.  It is essentially the same people that were running > free-node > > running pretty much the exact same service, and I believe they > are trying > > to make it extra easy to just switch, so this should be the > least effort > > transition. > > > > I believe IRC has served the GHC community quite well so far, > and there is > > a reddit post by Ed Kmett that the normal Haskell channels have > already > > been transitioned over, so I think it makes sense for GHC to > stick with the > > rest of the Haskell community. > > > The problem is that, in order to grow (or even merely not to shrink), > the community also needs to adapt to the preferences of younger users. > > The fact of the matter is the younger users tend to be, at best, > unfamiliar with IRC. In the worst case, the need to leave a > browser/sign > up for a new account means that they simply won't participate. Of the > new contributors I have had approach me in the past year, less > than half > have had any familiarity with IRC. > > Matrix has the advantage of being accessible to "web-native" community > members while being open enough to (at least in principle) allow > community members who are accustomed to IRC to continue to participate > via a bridge. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Mon May 24 00:36:12 2021 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 24 May 2021 06:06:12 +0530 Subject: GHC head, profiling with -O2 does not work Message-ID: Hi, I am trying to build a small program with profiling using a ghc built from haskell gitlab master branch. When I use -O2 I run into: $ ghc/inplace/bin/ghc-stage2 --make -O2 -prof -fprof-auto -rtsopts Main.hs Linking Main ... ./StreamD.o(.text+0x1b9f2): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' ./MArray.o(.text+0xbe83): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' Main.o(.text+0x6fdb): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) It builds fine without the -O2 option. On ghc-8 it builds fine even with -O2. Is that a bug in the head GHC or just something to do with how I built it? Thanks, Harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon May 24 02:07:46 2021 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 23 May 2021 22:07:46 -0400 Subject: GHC head, profiling with -O2 does not work In-Reply-To: References: Message-ID: <87h7is995f.fsf@smart-cactus.org> Harendra Kumar writes: > Hi, > > I am trying to build a small program with profiling using a ghc built from > haskell gitlab master branch. When I use -O2 I run into: > > $ ghc/inplace/bin/ghc-stage2 --make -O2 -prof -fprof-auto -rtsopts Main.hs > Linking Main ... > ./StreamD.o(.text+0x1b9f2): error: undefined reference to > 'StreamK_mkStreamFromStream_HPC_cc' > ./MArray.o(.text+0xbe83): error: undefined reference to > 'StreamK_mkStreamFromStream_HPC_cc' > Main.o(.text+0x6fdb): error: undefined reference to > 'StreamK_mkStreamFromStream_HPC_cc' > collect2: error: ld returned 1 exit status > `cc' failed in phase `Linker'. (Exit code: 1) > > It builds fine without the -O2 option. On ghc-8 it builds fine even with > -O2. Is that a bug in the head GHC or just something to do with how I built > it? > Hmm, that indeed looks bad. Could you open a ticket? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From oleg.grenrus at iki.fi Mon May 24 20:27:52 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 24 May 2021 23:27:52 +0300 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: <010f01799096e89c-6b4dab11-2b48-49a3-a2f9-e1b4e558800d-000000@us-east-2.amazonses.com> References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> <010f01799096e89c-6b4dab11-2b48-49a3-a2f9-e1b4e558800d-000000@us-east-2.amazonses.com> Message-ID: <6edd367b-ce23-16c0-4f3d-4742420b59bf@iki.fi> To clarify, are you suggesting guidelines for GHC **and** base-library? I'm puzzled about ownership of base. Who have a final word about it? ghc-devs, libraries at haskell.org, CLC, chessai alone, whoever is first? - Oleg On 21.5.2021 23.21, Richard Eisenberg wrote: > I agree with Chris here. > > Let me expand upon my counter-proposal: > > * A datatype declaration gets a standalone kind signature whenever at > least one of its type arguments has a kind other than Type. > * A class declaration gets a standalone kind signature whenever at > least one of its type arguments has a kind other than Type.(*) > * A closed type family always gets a standalone kind signature. > * A type synonym gets a standalone kind signature whenever either at > least one of its arguments has a kind other than Type or its result > has a kind other than Type. > > (*) The class rule has an exception: if a class has a superclass > constraint using Monad, Functor, Applicative, Foldable, or Traversable > (or some other class whose name textually includes one of those names, > such as MonadIO), we understand that the constrained variable must > have kind Type -> Type. If that type variable is the only one without > kind Type -> Type, then the standalone kind signature is optional. > > In cases other than those covered above, the standalone kind signature > is optional, at the discretion of the programmer. > > This suggests that Dict gets a signature, Eq does not, Fix does, and > Either does not. > > Richard > >> On May 21, 2021, at 12:37 PM, Chris Smith > > wrote: >> >> On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal > > wrote: >> >> > encouraging the use of a standalone signature for type >> declarations where at least one parameter of the datatype does >> not have kind Type. >> >> So Dict, Eq both get a sig but Fix and Either do not? >> >>   type Dict :: Constraint -> Type >>   type Eq   :: Type -> Constraint >>   type Fix  :: (Type -> Type) -> Type >> >> >>  That's not how I understand Richard's criteria.  Dict and Fix have >> non-Type parameters (Dict has a Constraint parameter, and Fix has a >> (Type -> Type) parameter.  On the other hand, Eq and Either have only >> Types as parameters.  This seems to match my intuition about when a >> kind signature might be helpful, as well as yours as far as I can >> tell from what you wrote. >> >> That's not to say I am advocating any kind of rule.  As I'm not >> really involved in GHC development, I refrain from having any >> opinion.  I just think you may have misread Richard's suggestion. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Mon May 24 20:36:15 2021 From: chessai1996 at gmail.com (chessai) Date: Mon, 24 May 2021 15:36:15 -0500 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: <6edd367b-ce23-16c0-4f3d-4742420b59bf@iki.fi> References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> <010f01799096e89c-6b4dab11-2b48-49a3-a2f9-e1b4e558800d-000000@us-east-2.amazonses.com> <6edd367b-ce23-16c0-4f3d-4742420b59bf@iki.fi> Message-ID: The CLC owns base, with final say coming down to listed maintainers. Though in practise, it ends up being a collective opinion of the CLC + GHC HQ that drives decisions, rather than one person. On Mon, May 24, 2021, 15:28 Oleg Grenrus wrote: > To clarify, are you suggesting guidelines for GHC **and** base-library? > > I'm puzzled about ownership of base. Who have a final word about it? > ghc-devs, libraries at haskell.org, CLC, chessai alone, whoever is first? > > - Oleg > On 21.5.2021 23.21, Richard Eisenberg wrote: > > I agree with Chris here. > > Let me expand upon my counter-proposal: > > * A datatype declaration gets a standalone kind signature whenever at > least one of its type arguments has a kind other than Type. > * A class declaration gets a standalone kind signature whenever at least > one of its type arguments has a kind other than Type.(*) > * A closed type family always gets a standalone kind signature. > * A type synonym gets a standalone kind signature whenever either at least > one of its arguments has a kind other than Type or its result has a kind > other than Type. > > (*) The class rule has an exception: if a class has a superclass > constraint using Monad, Functor, Applicative, Foldable, or Traversable (or > some other class whose name textually includes one of those names, such as > MonadIO), we understand that the constrained variable must have kind Type > -> Type. If that type variable is the only one without kind Type -> Type, > then the standalone kind signature is optional. > > In cases other than those covered above, the standalone kind signature is > optional, at the discretion of the programmer. > > This suggests that Dict gets a signature, Eq does not, Fix does, and > Either does not. > > Richard > > On May 21, 2021, at 12:37 PM, Chris Smith wrote: > > On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal > wrote: > >> > encouraging the use of a standalone signature for type declarations >> where at least one parameter of the datatype does not have kind Type. >> >> So Dict, Eq both get a sig but Fix and Either do not? >> >> type Dict :: Constraint -> Type >> type Eq :: Type -> Constraint >> type Fix :: (Type -> Type) -> Type > > > That's not how I understand Richard's criteria. Dict and Fix have > non-Type parameters (Dict has a Constraint parameter, and Fix has a (Type > -> Type) parameter. On the other hand, Eq and Either have only Types as > parameters. This seems to match my intuition about when a kind signature > might be helpful, as well as yours as far as I can tell from what you wrote. > > That's not to say I am advocating any kind of rule. As I'm not really > involved in GHC development, I refrain from having any opinion. I just > think you may have misread Richard's suggestion. > > > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue May 25 13:36:14 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 25 May 2021 09:36:14 -0400 Subject: Coding style: Using StandaloneKindSignatures in GHC In-Reply-To: References: <77328eaa-828d-66e8-efc9-8679c13be4e3@glitchbra.in> <010f017980c89c6b-1a5fecf9-43b0-469c-9ce1-dcef4ab17efa-000000@us-east-2.amazonses.com> <010f01799096e89c-6b4dab11-2b48-49a3-a2f9-e1b4e558800d-000000@us-east-2.amazonses.com> <6edd367b-ce23-16c0-4f3d-4742420b59bf@iki.fi> Message-ID: Yeah that’s roughly exactly it On Mon, May 24, 2021 at 4:37 PM chessai wrote: > The CLC owns base, with final say coming down to listed maintainers. > Though in practise, it ends up being a collective opinion of the CLC + GHC > HQ that drives decisions, rather than one person. > > > On Mon, May 24, 2021, 15:28 Oleg Grenrus wrote: > >> To clarify, are you suggesting guidelines for GHC **and** base-library? >> >> I'm puzzled about ownership of base. Who have a final word about it? >> ghc-devs, libraries at haskell.org, CLC, chessai alone, whoever is first? >> >> - Oleg >> On 21.5.2021 23.21, Richard Eisenberg wrote: >> >> I agree with Chris here. >> >> Let me expand upon my counter-proposal: >> >> * A datatype declaration gets a standalone kind signature whenever at >> least one of its type arguments has a kind other than Type. >> * A class declaration gets a standalone kind signature whenever at least >> one of its type arguments has a kind other than Type.(*) >> * A closed type family always gets a standalone kind signature. >> * A type synonym gets a standalone kind signature whenever either at >> least one of its arguments has a kind other than Type or its result has a >> kind other than Type. >> >> (*) The class rule has an exception: if a class has a superclass >> constraint using Monad, Functor, Applicative, Foldable, or Traversable (or >> some other class whose name textually includes one of those names, such as >> MonadIO), we understand that the constrained variable must have kind Type >> -> Type. If that type variable is the only one without kind Type -> Type, >> then the standalone kind signature is optional. >> >> In cases other than those covered above, the standalone kind signature is >> optional, at the discretion of the programmer. >> >> This suggests that Dict gets a signature, Eq does not, Fix does, and >> Either does not. >> >> Richard >> >> On May 21, 2021, at 12:37 PM, Chris Smith wrote: >> >> On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal >> wrote: >> >>> > encouraging the use of a standalone signature for type declarations >>> where at least one parameter of the datatype does not have kind Type. >>> >>> So Dict, Eq both get a sig but Fix and Either do not? >>> >>> type Dict :: Constraint -> Type >>> type Eq :: Type -> Constraint >>> type Fix :: (Type -> Type) -> Type >> >> >> That's not how I understand Richard's criteria. Dict and Fix have >> non-Type parameters (Dict has a Constraint parameter, and Fix has a (Type >> -> Type) parameter. On the other hand, Eq and Either have only Types as >> parameters. This seems to match my intuition about when a kind signature >> might be helpful, as well as yours as far as I can tell from what you wrote. >> >> That's not to say I am advocating any kind of rule. As I'm not really >> involved in GHC development, I refrain from having any opinion. I just >> think you may have misread Richard's suggestion. >> >> >> >> _______________________________________________ >> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Wed May 26 11:47:28 2021 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 26 May 2021 12:47:28 +0100 Subject: Productivity Tip from mpickering Message-ID: Hi, I am now using a new flavour combination which is proving *very* nice as a compromise between fast recompiles and passing tests. My normal build command is now: ./hadrian/build --flavour=default+no_profiled_libs+omit_pragmas --freeze1 -j This has the effect of * base libraries are compiled with optimisation * Profiling libraries are not built * Stage 1 compiler is compiled with -O + -fomit-interface-pragmas, so recompilation behaviour is much better. The end result is a nearly clean testsuite run (I think there are two failures) but much faster iterations when modifying `compiler/*`. Cheers, Matt From rae at richarde.dev Wed May 26 12:38:57 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 26 May 2021 12:38:57 +0000 Subject: Productivity Tip from mpickering In-Reply-To: References: Message-ID: <010f0179a8af649c-3ed3f923-023b-4414-a3b3-cf7ae5ed2a22-000000@us-east-2.amazonses.com> Could you add this insight to the wiki somewhere, so we can find it later? https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian seems like the right place. Thanks! Richard > On May 26, 2021, at 7:47 AM, Matthew Pickering wrote: > > Hi, > > I am now using a new flavour combination which is proving *very* nice > as a compromise between fast recompiles and passing tests. > > My normal build command is now: > > ./hadrian/build --flavour=default+no_profiled_libs+omit_pragmas --freeze1 -j > > This has the effect of > > * base libraries are compiled with optimisation > * Profiling libraries are not built > * Stage 1 compiler is compiled with -O + -fomit-interface-pragmas, so > recompilation behaviour is much better. > > The end result is a nearly clean testsuite run (I think there are two > failures) but much faster iterations when modifying `compiler/*`. > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Wed May 26 13:28:31 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 26 May 2021 16:28:31 +0300 Subject: Productivity Tip from mpickering In-Reply-To: <010f0179a8af649c-3ed3f923-023b-4414-a3b3-cf7ae5ed2a22-000000@us-east-2.amazonses.com> References: <010f0179a8af649c-3ed3f923-023b-4414-a3b3-cf7ae5ed2a22-000000@us-east-2.amazonses.com> Message-ID: <9c231e69-107d-1fcd-02ef-b1c8df8c637d@iki.fi> (Not really) funny observation, that page and hadrian/doc/README.md have about the same, but slightly different information. I don't know which one to believe! - Oleg On 26.5.2021 15.38, Richard Eisenberg wrote: > Could you add this insight to the wiki somewhere, so we can find it > later? https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian seems > like the right place. > > Thanks! > Richard > >> On May 26, 2021, at 7:47 AM, Matthew Pickering >> > wrote: >> >> Hi, >> >> I am now using a new flavour combination which is proving *very* nice >> as a compromise between fast recompiles and passing tests. >> >> My normal build command is now: >> >> ./hadrian/build --flavour=default+no_profiled_libs+omit_pragmas >> --freeze1 -j >> >> This has the effect of >> >> * base libraries are compiled with optimisation >> * Profiling libraries are not built >> * Stage 1 compiler is compiled with -O + -fomit-interface-pragmas, so >> recompilation behaviour is much better. >> >> The end result is a nearly clean testsuite run (I think there are two >> failures) but much faster iterations when modifying `compiler/*`. >> >> Cheers, >> >> Matt >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Wed May 26 15:14:07 2021 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 26 May 2021 17:14:07 +0200 Subject: Ampere A1 instances for builder/marge? Message-ID: <40fedf19-db8b-d455-0c3f-0d6ce0b2d4fd@centrum.cz> Hi, just to pass https://www.servethehome.com/oracle-cloud-giving-away-ampere-arm-a1-instances-always-free/ -- oracle seems to be giving some "always free" Ampere/ARM based instances. Looks like they even have some RAM and cores so perhaps they may be usable for marge/builder for arm/linux platform? BTW: Not tested myself, not trust Oracle, but sometimes man can get some good even from ... well... Oracle... Thanks, Karel From simonpj at microsoft.com Thu May 27 13:40:44 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 27 May 2021 13:40:44 +0000 Subject: Errors in haddock git fetch Message-ID: I'm getting these errors from `git submodule update`. Should I worry? Simon >From https://gitlab.haskell.org/ghc/haddock * [new branch] az/T19834 -> origin/az/T19834 * [new branch] az/T19834-2 -> origin/az/T19834-2 * [new branch] az/T19845 -> origin/az/T19845 * [new branch] az/T19845-2 -> origin/az/T19845-2 * [new branch] az/T19845-3 -> origin/az/T19845-3 * [new branch] dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 -> origin/dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 * [new branch] dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 -> origin/dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 * [new branch] dn/dn-driver-refactor-and-split -> origin/dn/dn-driver-refactor-and-split b4e7407b..c7281407 ghc-9.2 -> origin/ghc-9.2 dabdee14..4f9088e4 ghc-head -> origin/ghc-head * [new branch] wip/T18389-task-zero -> origin/wip/T18389-task-zero + 7d27ea7a...3b6a8774 wip/T19720 -> origin/wip/T19720 (forced update) + fe35fed3...40ba457f wip/adinapoli-align-ps-messages -> origin/wip/adinapoli-align-ps-messages (forced update) * [new branch] wip/dn-driver-refactor-and-split -> origin/wip/dn-driver-refactor-and-split error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create 'refs/remotes/origin/wip/hsyl20/dynflags' ! [new branch] wip/hsyl20/dynflags -> origin/wip/hsyl20/dynflags (unable to update local ref) * [new branch] wip/hsyl20/uncpp -> origin/wip/hsyl20/uncpp Unable to fetch in submodule path 'utils/haddock'; trying to directly fetch 4f9088e4b04e52ca510b55a78048c9230537e449: Submodule path 'utils/haddock': checked out '4f9088e4b04e52ca510b55a78048c9230537e449' simonpj at MSRC-3645512:~/code/HEAD-7$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Thu May 27 15:03:36 2021 From: sylvain at haskus.fr (Sylvain Henry) Date: Thu, 27 May 2021 17:03:36 +0200 Subject: Errors in haddock git fetch In-Reply-To: References: Message-ID: <3d5fed63-91e8-46f3-35af-90d94621ff59@haskus.fr> > error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create 'refs/remotes/origin/wip/hsyl20/dynflags' This one is because I've removed some of my wip branches already merged upstream. Their names were conflicting with a new branch name (wip/hsyl20/dynflags). I forgot that everyone fetches every /wip branch so now it conflicts for everyone... I need to remember to remove the branch when !5845 will be merged. > Should I worry? No. The submodule seems to be checked out correctly even with the error. Sylvain PS: I still think we shouldn't have that many wip branches in the main repositories (cf https://mail.haskell.org/pipermail/ghc-devs/2019-February/017031.html) On 27/05/2021 15:40, Simon Peyton Jones via ghc-devs wrote: > > I’m getting these errors from `git submodule update`.  Should I worry? > > Simon > > From https://gitlab.haskell.org/ghc/haddock > > > * [new branch] az/T19834 -> origin/az/T19834 > > * [new branch] az/T19834-2 -> origin/az/T19834-2 > > * [new branch] az/T19845 -> origin/az/T19845 > > * [new branch] az/T19845-2 -> origin/az/T19845-2 > > * [new branch] az/T19845-3 -> origin/az/T19845-3 > > * [new branch] > dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 > -> > origin/dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 > > * [new branch] > dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 -> > origin/dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 > > * [new branch] dn/dn-driver-refactor-and-split -> > origin/dn/dn-driver-refactor-and-split > >    b4e7407b..c7281407 ghc-9.2                            -> origin/ghc-9.2 > >    dabdee14..4f9088e4 ghc-head -> origin/ghc-head > > * [new branch] wip/T18389-task-zero -> origin/wip/T18389-task-zero > > + 7d27ea7a...3b6a8774 wip/T19720 -> origin/wip/T19720  (forced update) > > + fe35fed3...40ba457f wip/adinapoli-align-ps-messages      -> > origin/wip/adinapoli-align-ps-messages  (forced update) > > * [new branch] wip/dn-driver-refactor-and-split -> > origin/wip/dn-driver-refactor-and-split > > error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': > 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot > create 'refs/remotes/origin/wip/hsyl20/dynflags' > > ! [new branch] wip/hsyl20/dynflags -> origin/wip/hsyl20/dynflags  > (unable to update local ref) > > * [new branch] wip/hsyl20/uncpp -> origin/wip/hsyl20/uncpp > > Unable to fetch in submodule path 'utils/haddock'; trying to directly > fetch 4f9088e4b04e52ca510b55a78048c9230537e449: > > Submodule path 'utils/haddock': checked out > '4f9088e4b04e52ca510b55a78048c9230537e449' > > simonpj at MSRC-3645512:~/code/HEAD-7$ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu May 27 16:49:27 2021 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 27 May 2021 17:49:27 +0100 Subject: Errors in haddock git fetch In-Reply-To: <3d5fed63-91e8-46f3-35af-90d94621ff59@haskus.fr> References: <3d5fed63-91e8-46f3-35af-90d94621ff59@haskus.fr> Message-ID: You can get rid of the errors by doing git remote prune Where is the name you have for the upstream repo, normally 'origin'. Alan On Thu, 27 May 2021 at 16:11, Sylvain Henry wrote: > > error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': > 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create > 'refs/remotes/origin/wip/hsyl20/dynflags' > > This one is because I've removed some of my wip branches already merged > upstream. Their names were conflicting with a new branch name > (wip/hsyl20/dynflags). > > I forgot that everyone fetches every /wip branch so now it conflicts for > everyone... I need to remember to remove the branch when !5845 will be > merged. > > > Should I worry? > > No. The submodule seems to be checked out correctly even with the error. > > Sylvain > > PS: I still think we shouldn't have that many wip branches in the main > repositories (cf > https://mail.haskell.org/pipermail/ghc-devs/2019-February/017031.html) > > > On 27/05/2021 15:40, Simon Peyton Jones via ghc-devs wrote: > > I’m getting these errors from `git submodule update`. Should I worry? > > Simon > > > > From https://gitlab.haskell.org/ghc/haddock > > * [new branch] > az/T19834 -> > origin/az/T19834 > > * [new branch] > az/T19834-2 -> > origin/az/T19834-2 > > * [new branch] > az/T19845 -> > origin/az/T19845 > > * [new branch] > az/T19845-2 -> > origin/az/T19845-2 > > * [new branch] > az/T19845-3 -> > origin/az/T19845-3 > > * [new branch] > dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 -> > origin/dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 > > * [new branch] > dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 -> > origin/dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 > > * [new branch] > dn/dn-driver-refactor-and-split -> > origin/dn/dn-driver-refactor-and-split > > b4e7407b..c7281407 ghc-9.2 > -> origin/ghc-9.2 > > dabdee14..4f9088e4 > ghc-head -> > origin/ghc-head > > * [new branch] > wip/T18389-task-zero -> > origin/wip/T18389-task-zero > > + 7d27ea7a...3b6a8774 > wip/T19720 -> > origin/wip/T19720 (forced update) > > + fe35fed3...40ba457f > wip/adinapoli-align-ps-messages -> > origin/wip/adinapoli-align-ps-messages (forced update) > > * [new branch] > wip/dn-driver-refactor-and-split -> > origin/wip/dn-driver-refactor-and-split > > error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': > 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create > 'refs/remotes/origin/wip/hsyl20/dynflags' > > ! [new branch] > wip/hsyl20/dynflags -> > origin/wip/hsyl20/dynflags (unable to update local ref) > > * [new branch] > wip/hsyl20/uncpp -> > origin/wip/hsyl20/uncpp > > Unable to fetch in submodule path 'utils/haddock'; trying to directly > fetch 4f9088e4b04e52ca510b55a78048c9230537e449: > > Submodule path 'utils/haddock': checked out > '4f9088e4b04e52ca510b55a78048c9230537e449' > > simonpj at MSRC-3645512:~/code/HEAD-7$ > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Fri May 28 14:48:10 2021 From: sylvain at haskus.fr (Sylvain Henry) Date: Fri, 28 May 2021 16:48:10 +0200 Subject: GHC releases and versions Message-ID: <1450ea36-f0fc-940f-aea2-a29573d6c51b@haskus.fr> Hi devs, We currently have 4 branches of GHC in flight: 8.10, 9.0, 9.2 and HEAD Latest releases: - 8.10.4: 2021/02/06 - 9.0.1: 2021/02/04 - 9.2.1-alpha2: 2021/04/23 Considering: 1) 8.10 branch should be stable but a lot of stuff has been merged for 8.10.5. To the point that 8.10.5 should probably be a "major release in the 8.10 series". 2) 9.0.1 is the latest major release but it shouldn't be used before 9.0.2 is released because of bugs and regressions (9.0.2 branch contains a fix for a critical bug in 9.0.1 [1] since March). 3) We might release 9.2.1 and 9.0.2 approximately at the same time which will be quite confusing for users ("9.0.2 in the 9.0 series and 9.2.1 in the 9.2 series"). 4) The first major number is meaningless. Proposition: Switch to A.B.C[.D] version scheme where: - A: major release ("series") - B: major release in the A series if B>0 and C=0; beta release if B=0 - C: bugfix release for A.B (if C>0) or beta release number (if B=0) - D: date when building in tree, not for releases It might be clearer exposed like this: showVersion = \case   [a,b,c,d] -> "Dev version of " ++ showVersion [a,b,c] ++ " built on " ++ show d   [a,0,c]   -> "beta " ++ show c ++ " in series " ++ show a   [a,b,0]   -> "Major release " ++ show [a,b] ++ " in series " ++ show a   [a,b,c]   -> "Bugfix release " ++ show c ++ " for " ++ show [a,b]   _         -> undefined > showVersion [9,0,1,20211028] "Dev version of beta 1 in series 9 built on 20211028" > showVersion [9,0,1] "beta 1 in series 9" > showVersion [9,0,2] "beta 2 in series 9" > showVersion [9,1,0] "Major release [9,1] in series 9" > showVersion [9,1,1] "Bugfix release 1 for [9,1]" > showVersion [9,2,0] "Major release [9,2] in series 9" > showVersion [10,1,0] "Major release [10,1] in series 10" Effects: 1) We could use C for bugfix versions which are to be released much faster than major versions. 2) B would be used for the old series we maintain. We backport a lot more stuff than before in older releases it seems, so it would be more PVP compliant to bump a major version number. 3) A would be used for the usual 6-month major releases. 4) We could make major releases in the 8 series (e.g. 8.10.5 could be released as 8.11.0) 5) We could advertise 9.0.1 as a beta (as everyone seems to consider .1 releases) 6) 9.2.1 final could be released either as 9.3 (next major in the 9 series if we just forget about 9.0.* and 9.2.*) or as 10.1.0 (first major in the 10 series). 7) No difference anymore between even/odd version numbers (for reference the current scheme is explained in [2]) Any thoughts? Sylvain [1] https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html [2] https://gitlab.haskell.org/ghc/ghc/-/wikis/working-conventions/releases From iavor.diatchki at gmail.com Fri May 28 15:53:51 2021 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 28 May 2021 08:53:51 -0700 Subject: GHC releases and versions In-Reply-To: <1450ea36-f0fc-940f-aea2-a29573d6c51b@haskus.fr> References: <1450ea36-f0fc-940f-aea2-a29573d6c51b@haskus.fr> Message-ID: Hello, I never understood what the first version number in GHC is for (the one you refer to as "series", and that recently changed from 8 to 9). To me it makes more sense to have 2 numbers for proper releases and 2 numbers+date (or git hash) for development. So the format would be: A.B where A is incremented for each release (roughly 6 months apart) and B is incremented for different variations of each release. B resets back to 0 at each 6 month release cycle, so the very first release candidate would be `A.0` with others being `A.1`, `A.2` etc, until the actual release seattles at `A.R`, which would last for about 6 months when we'd go to `A+1`. If we need a bug fix release before the 6 month period has expired, we just bump `B` to `A.(R+1)`, etc. Just my 2c, -Iavor On Fri, May 28, 2021 at 7:49 AM Sylvain Henry wrote: > Hi devs, > > We currently have 4 branches of GHC in flight: 8.10, 9.0, 9.2 and HEAD > > Latest releases: > - 8.10.4: 2021/02/06 > - 9.0.1: 2021/02/04 > - 9.2.1-alpha2: 2021/04/23 > > Considering: > > 1) 8.10 branch should be stable but a lot of stuff has been merged for > 8.10.5. To the point that 8.10.5 should probably be a "major release in > the 8.10 series". > > 2) 9.0.1 is the latest major release but it shouldn't be used before > 9.0.2 is released because of bugs and regressions (9.0.2 branch contains > a fix for a critical bug in 9.0.1 [1] since March). > > 3) We might release 9.2.1 and 9.0.2 approximately at the same time which > will be quite confusing for users ("9.0.2 in the 9.0 series and 9.2.1 in > the 9.2 series"). > > 4) The first major number is meaningless. > > Proposition: > > Switch to A.B.C[.D] version scheme where: > - A: major release ("series") > - B: major release in the A series if B>0 and C=0; beta release if B=0 > - C: bugfix release for A.B (if C>0) or beta release number (if B=0) > - D: date when building in tree, not for releases > > It might be clearer exposed like this: > > showVersion = \case > [a,b,c,d] -> "Dev version of " ++ showVersion [a,b,c] ++ " built on " > ++ show d > [a,0,c] -> "beta " ++ show c ++ " in series " ++ show a > [a,b,0] -> "Major release " ++ show [a,b] ++ " in series " ++ show a > [a,b,c] -> "Bugfix release " ++ show c ++ " for " ++ show [a,b] > _ -> undefined > > > showVersion [9,0,1,20211028] > "Dev version of beta 1 in series 9 built on 20211028" > > showVersion [9,0,1] > "beta 1 in series 9" > > showVersion [9,0,2] > "beta 2 in series 9" > > showVersion [9,1,0] > "Major release [9,1] in series 9" > > showVersion [9,1,1] > "Bugfix release 1 for [9,1]" > > showVersion [9,2,0] > "Major release [9,2] in series 9" > > showVersion [10,1,0] > "Major release [10,1] in series 10" > > Effects: > > 1) We could use C for bugfix versions which are to be released much > faster than major versions. > 2) B would be used for the old series we maintain. We backport a lot > more stuff than before in older releases it seems, so it would be more > PVP compliant to bump a major version number. > 3) A would be used for the usual 6-month major releases. > 4) We could make major releases in the 8 series (e.g. 8.10.5 could be > released as 8.11.0) > 5) We could advertise 9.0.1 as a beta (as everyone seems to consider .1 > releases) > 6) 9.2.1 final could be released either as 9.3 (next major in the 9 > series if we just forget about 9.0.* and 9.2.*) or as 10.1.0 (first > major in the 10 series). > 7) No difference anymore between even/odd version numbers (for reference > the current scheme is explained in [2]) > > Any thoughts? > Sylvain > > > [1] https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html > [2] > https://gitlab.haskell.org/ghc/ghc/-/wikis/working-conventions/releases > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun May 30 18:54:35 2021 From: ben at well-typed.com (Ben Gamari) Date: Sun, 30 May 2021 14:54:35 -0400 Subject: GitLab downtime Message-ID: <87sg24128m.fsf@smart-cactus.org> Hi all, Today I'm going to be working on migrating our GitLab instance to a new machine. Starting in likely an hour there will be a few hours of downtime while the migration proceeds. I will send an email when the downtime begins and concludes. Apologies for the late notice! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon May 31 04:09:56 2021 From: ben at well-typed.com (Ben Gamari) Date: Mon, 31 May 2021 00:09:56 -0400 Subject: GitLab downtime In-Reply-To: <87sg24128m.fsf@smart-cactus.org> References: <87sg24128m.fsf@smart-cactus.org> Message-ID: <87mtsb1r3l.fsf@smart-cactus.org> Ben Gamari writes: > Hi all, > > Today I'm going to be working on migrating our GitLab instance to a new > machine. Starting in likely an hour there will be a few hours of > downtime while the migration proceeds. I will send an email when the > downtime begins and concludes. > Hi all, A brief update: The GitLab downtime has not yet started as the migration preparation has taken a bit longer than expected. As it is getting late, I will be postponing the downtime until tomorrow evening. Sorry for the inconvenience! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon May 31 20:23:37 2021 From: ben at well-typed.com (Ben Gamari) Date: Mon, 31 May 2021 16:23:37 -0400 Subject: GitLab downtime In-Reply-To: <87mtsb1r3l.fsf@smart-cactus.org> References: <87sg24128m.fsf@smart-cactus.org> <87mtsb1r3l.fsf@smart-cactus.org> Message-ID: <87h7ii1wl5.fsf@smart-cactus.org> Ben Gamari writes: > Ben Gamari writes: > >> Hi all, >> >> Today I'm going to be working on migrating our GitLab instance to a new >> machine. Starting in likely an hour there will be a few hours of >> downtime while the migration proceeds. I will send an email when the >> downtime begins and concludes. >> > Hi all, > > A brief update: The GitLab downtime has not yet started as the migration > preparation has taken a bit longer than expected. As it is getting late, > I will be postponing the downtime until tomorrow evening. > > Sorry for the inconvenience! Hi all, As noted yesterday I will be continue the GitLab migration starting in around 45 minutes. Do expect a bit of outage starting at that time. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: