From iavor.diatchki at gmail.com Mon Jun 1 16:39:48 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 1 Jun 2020 09:39:48 -0700 Subject: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules Message-ID: Hello, I am the shepherd for proposal #270, and it is time for the committee to review the proposal. The discussion and the proposal are available here: https://github.com/ghc-proposals/ghc-proposals/pull/270 Here is my summary of the proposal: The proposal aims to solve the "namespace problem" which appears to largely be related to fact that Haskell has two namespaces, and so types and values may have the same name. Proposed changes: 1. Change the scoping rules for the language so that type names are in scope at the value level, but values always shadow types. 2. Add a new form of import, which can import only the names from a particular names space 3. Change the way built-in syntax for tuples and lists works and deprecated ' and '' from DataKinds and TH respectively. This is a bit elaborate, have a look in the proposal for details 4. Add a bunch of warnings that would trigger if you wrote code that made use of Haskell's different name spaces My recommendation is that the proposal is rejected, as I don't think that these changes would help Haskell programmers, at least based on the way I use Haskell. In particular, here are my thoughts on each of the above bullets: 1. This is mostly about passing type arguments to functions---I would prefer a notation that is more explicit about the fact that we are passing in a type, and not just a normal argument. 2. When I group things into modules, it is usually because they are intended to be used together. I think I would rarely want to import only the types or only the values in a module, so I imagine it would be much more common to have to write two imports. 3. This is quite an intrusive change, that is likely to break code. I am also not keen to have to use type families, every time I want to use a tuple. 4. Using the same name for a data constructor and a type is very common in Haskell. I find it particularly useful when defining records. I don't need warnings to let me know that I've done it, as it is highly unlikely that I did it on accident. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Mon Jun 1 17:10:49 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 1 Jun 2020 19:10:49 +0200 Subject: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules In-Reply-To: References: Message-ID: Hi, My first reaction is also to reject this proposal. I feel it is too invasive. Regards, Alejandro El lun., 1 jun. 2020 a las 18:40, Iavor Diatchki () escribió: > Hello, > > I am the shepherd for proposal #270, and it is time for the committee to > review the proposal. The discussion and the proposal are available here: > https://github.com/ghc-proposals/ghc-proposals/pull/270 > > Here is my summary of the proposal: > > The proposal aims to solve the "namespace problem" which appears to > largely be related to fact that Haskell has two namespaces, and so types > and values may have the same name. > > Proposed changes: > 1. Change the scoping rules for the language so that type names are in > scope at the value level, but values always shadow types. > 2. Add a new form of import, which can import only the names from a > particular names space > 3. Change the way built-in syntax for tuples and lists works and > deprecated ' and '' from DataKinds and TH respectively. This is a bit > elaborate, have a look in the proposal for details > 4. Add a bunch of warnings that would trigger if you wrote code that > made use of Haskell's different name spaces > > My recommendation is that the proposal is rejected, as I don't think that > these changes would help Haskell programmers, at least based on the way I > use Haskell. In particular, here are my thoughts on each of the above > bullets: > > 1. This is mostly about passing type arguments to functions---I would > prefer a notation that is more explicit about the fact that we are passing > in a type, and not just a normal argument. > > 2. When I group things into modules, it is usually because they are > intended to be used together. I think I would rarely want to import only > the types or only the values in a module, so I imagine it would be much > more common to have to write two imports. > > 3. This is quite an intrusive change, that is likely to break code. I > am also not keen to have to use type families, every time I want to use a > tuple. > > 4. Using the same name for a data constructor and a type is very common > in Haskell. I find it particularly useful when defining records. I don't > need warnings to let me know that I've done it, as it is highly unlikely > that I did it on accident. > > -Iavor > > > > > > > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Jun 1 17:20:41 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 1 Jun 2020 18:20:41 +0100 Subject: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules In-Reply-To: References: Message-ID: <7E9F44A9-D0E0-4EC8-8059-2C9890A83515@richarde.dev> Disclaimer: I'm biased here, as I've been worried for years about how the current story around namespaces can be reconciled with dependent types. I'm in strong support of the spirit of the proposal, and I see no concrete improvements to offer to the letter of the proposed change specification. (My phrasing here is to make clear that the new specification may indeed have room for improvement, and I encourage us to find that. And as you'll see, I have a different spin on e.g. motivation than the authors present. But I think the spirit is right on.) While I agree completely (except that the proposal does not mean we need type families to use tuples) with the facts Iavor has presented, I'd like to present them in a different light. For me, the key payload of the proposal is Iavor's (4): add two warnings: a. -Wpun-bindings warns whenever a declaration introduces a name into one of our namespaces that would clash with a name in another. b. -Wpuns warns whenever a name occurrence matches names that are in scope in more than one namespace. The proposal lists the process of eventually adding these to -Wall (but not to -W or on-by-default). In some ideal world, that would be it. The problem with that world is that we generally like to offer our users ways of avoiding warnings. The entire rest of the proposal is around giving users workarounds to suppress the warnings. Before we go there, let me defend why I like these warnings: - Whenever I have taught introductory Haskell, the type-level/term-level namespace situation has been a cause for confusion. As soon as we get to instance Functor [], we have to be very careful about distinguishing the higher-kinded type constructor [] from the empty list []. And once we start using libraries (e.g. aeson) that use punning liberally, we are worse off. Interestingly, other languages (e.g. C, C++, Java) support distinguished type-level and term-level namespaces, yet I don't believe it's standard practice in any of those languages to actually give two entities the same name, in a way that's common in Haskell. - The confusion leaks to many areas of the language. See https://github.com/goldfirere/ghc-proposals/blob/namespaces/proposals/0000-namespaces.rst#background, which is part of a previous attempt to fix this problem, but still accurately describes the very messy status quo. Understanding what T means in code requires knowing what context you are in; some contexts give a meaning to T from either namespace, in which case GHC offers 5(!) different ways of allowing the user to choose what they mean, where the syntax depends on the context. (That is, users need to know all 5 ways to disambiguate, because they don't have the choice, given the context.) The five ways are (1) using ' in a type to use a term-level data constructor, (2) using ' for terms vs '' for types in a TH name quote, (3) using 'type' or 'pattern' in import/export lists, (4) using 'type' or 'module' in ANN pragams (but you cannot use 'pattern' for terms), and (5) using 'type or 'value' in fixity declarations. WARNING pragmas do not even offer a way to disambiguate. Of course, we could clean this up, but much better is to avoid the need to disambiguate in the first place. - By gently encouraging users to avoid punning, we can open the door to wonderful things in the future, including visible dependent quantification in terms, and the use of ordinary term-level functions in types (thus obviating type families). Neither of these requires dependent types, by the way. Of course, we can get dependent types, too. But note that I think this proposal holds its water even *without* the need to appeal to future extensions. Let's now go through the other aspects of the proposals, using Iavor's numbering. 3. If we are avoiding punning, we need a way to talk about lists and tuples, separating types from terms. This proposal introduces a new way to do this. No type families are required, but the proposal includes a Tuple type family (taking a type-level list of types) as a convenience. 2. Users who wish to avoid puns may want to use a library that exports punned names. So the proposal allows you to qualify the types from an import separately from the terms. I agree that most users will want to import both types and terms, but by being able to separate the imports, users can qualify them separately, allowing easy disambiguation based on familiar module qualification. 1. Despite being the title of the proposal, the extended lookup is, for me, essentially an afterthought. It means we will produce more informative error messages when users write the name of a type in a term. The lookup extension really only starts to do something interesting after, for example, visible dependent quantification in terms is available. I'd be happy dropping this part of the proposal if it meets resistance. Note that this proposal never suggests to move these warnings into the default set, and so users who like punning are free to do so for as long as they like. But it does give a nice nudge to our community to avoid this practice, which I think will improve the readability, searchability, and learnability of Haskell code. Thanks for your consideration, Richard > On Jun 1, 2020, at 5:39 PM, Iavor Diatchki wrote: > > Hello, > > I am the shepherd for proposal #270, and it is time for the committee to review the proposal. The discussion and the proposal are available here: > https://github.com/ghc-proposals/ghc-proposals/pull/270 > > Here is my summary of the proposal: > > The proposal aims to solve the "namespace problem" which appears to largely be related to fact that Haskell has two namespaces, and so types and values may have the same name. > > Proposed changes: > 1. Change the scoping rules for the language so that type names are in scope at the value level, but values always shadow types. > 2. Add a new form of import, which can import only the names from a particular names space > 3. Change the way built-in syntax for tuples and lists works and deprecated ' and '' from DataKinds and TH respectively. This is a bit elaborate, have a look in the proposal for details > 4. Add a bunch of warnings that would trigger if you wrote code that made use of Haskell's different name spaces > > My recommendation is that the proposal is rejected, as I don't think that these changes would help Haskell programmers, at least based on the way I use Haskell. In particular, here are my thoughts on each of the above bullets: > > 1. This is mostly about passing type arguments to functions---I would prefer a notation that is more explicit about the fact that we are passing in a type, and not just a normal argument. > > 2. When I group things into modules, it is usually because they are intended to be used together. I think I would rarely want to import only the types or only the values in a module, so I imagine it would be much more common to have to write two imports. > > 3. This is quite an intrusive change, that is likely to break code. I am also not keen to have to use type families, every time I want to use a tuple. > > 4. Using the same name for a data constructor and a type is very common in Haskell. I find it particularly useful when defining records. I don't need warnings to let me know that I've done it, as it is highly unlikely that I did it on accident. > > -Iavor > > > > > > > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Mon Jun 1 18:37:24 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 1 Jun 2020 20:37:24 +0200 Subject: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules In-Reply-To: References: Message-ID: Hi again, My first message was quite short, and I guess I should explain my rejection a bit further. Although I am aware that sometime changes can only be made "in bulk", I think that this proposal in particular changes too many things core to the language. - I am surprised by the complicated way to introduce that "~" and "[]" are built-in to the language, by means of a new "Data.BuiltinTypes" which is always in scope, unless you disable with another extension. I would be very happy to have those are wired-in types in the language, which cannot be overriden. - The use of ticks in TH have served us well. I think we should not go as far as removing that until we see whether this disambiguation strategy works on simpler cases. Thereis one thing I like *a lot* from this proposal: the ability to import types and terms under different qualifiers. I could well imagine myself replacing the common > import Data.ByteString (ByteString) > import qualified Data.ByteString as B with > import Data.ByteString type > import qualified Data.ByteString as B To be honest, I was not aware that GHC had 5 different ways to disambiguate the namespace (thanks Richard for the informative message!). In my mind, I've always had sort of the following intuition: - ' promotes from term to type level, @ demotes (?) from type level to term level *in expressions* - except in TH, where you need ' to quote a term and '' to quote a type Regards, Alejandro El lun., 1 jun. 2020 a las 19:10, Alejandro Serrano Mena () escribió: > Hi, > My first reaction is also to reject this proposal. I feel it is too > invasive. > > Regards, > Alejandro > > El lun., 1 jun. 2020 a las 18:40, Iavor Diatchki (< > iavor.diatchki at gmail.com>) escribió: > >> Hello, >> >> I am the shepherd for proposal #270, and it is time for the committee to >> review the proposal. The discussion and the proposal are available here: >> https://github.com/ghc-proposals/ghc-proposals/pull/270 >> >> Here is my summary of the proposal: >> >> The proposal aims to solve the "namespace problem" which appears to >> largely be related to fact that Haskell has two namespaces, and so types >> and values may have the same name. >> >> Proposed changes: >> 1. Change the scoping rules for the language so that type names are in >> scope at the value level, but values always shadow types. >> 2. Add a new form of import, which can import only the names from a >> particular names space >> 3. Change the way built-in syntax for tuples and lists works and >> deprecated ' and '' from DataKinds and TH respectively. This is a bit >> elaborate, have a look in the proposal for details >> 4. Add a bunch of warnings that would trigger if you wrote code that >> made use of Haskell's different name spaces >> >> My recommendation is that the proposal is rejected, as I don't think that >> these changes would help Haskell programmers, at least based on the way I >> use Haskell. In particular, here are my thoughts on each of the above >> bullets: >> >> 1. This is mostly about passing type arguments to functions---I would >> prefer a notation that is more explicit about the fact that we are passing >> in a type, and not just a normal argument. >> >> 2. When I group things into modules, it is usually because they are >> intended to be used together. I think I would rarely want to import only >> the types or only the values in a module, so I imagine it would be much >> more common to have to write two imports. >> >> 3. This is quite an intrusive change, that is likely to break code. I >> am also not keen to have to use type families, every time I want to use a >> tuple. >> >> 4. Using the same name for a data constructor and a type is very >> common in Haskell. I find it particularly useful when defining records. I >> don't need warnings to let me know that I've done it, as it is highly >> unlikely that I did it on accident. >> >> -Iavor >> >> >> >> >> >> >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Mon Jun 1 19:44:01 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 1 Jun 2020 21:44:01 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: <9212CD04-ABEC-4709-91EC-F315835A6DD4@richarde.dev> References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> <9212CD04-ABEC-4709-91EC-F315835A6DD4@richarde.dev> Message-ID: Dear Committee, Apart from Richard's concerns about wired-in families, there seems that there is no further discussion regarding this topics. If nobody raises any further concern, I'll write back to the author of the proposal asking them to remove or rework that part. Regards, Alejandro El lun., 25 may. 2020 a las 13:14, Richard Eisenberg () escribió: > I'm in support of the proposal as written, perhaps with the exception of > the special error-handling for ArrowStackTup (which I think is unnecessary). > > On May 24, 2020, at 8:19 PM, Alejandro Serrano Mena > wrote: > - Should the proposal be under a different extension or under `Arrows`? > > > No. As the proposal authors argue, the backward-compatibility problem is > essentially non-existent, because the feature is so inconvenient to use > today that no one does. > > - Should a flattened or nested tuple representation be used? This comments > [ > https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-633199848] > may give you some additional information. > > > I prefer the flat tuples. If need be, this can revisited in the future, > but the flat tuples seem better today. > > - Should the type families described there be wired-in? > > > I don't see a need for this. The type families will necessarily be part of > the specification of these features, and so their appearance in error > messages are not an example of abstraction leakage. Maybe we want to > carefully normaliseType here or there to avoid them unnecessarily, but I > see no need to wire-in. > > Richard > > > Looking forward to hearing from everyone. This is a complex proposal, with > possible future ramifications. If there's no discussion in one week, I'll > write again to the list. > Regards, > Alejandro > > El mar., 19 may. 2020 a las 9:02, Joachim Breitner (< > mail at joachim-breitner.de>) escribió: > >> If there is active discussion, we usually put it back to the previous >> state, and wait for discussion to come to conclusions. >> >> 19.05.2020 08:36:42 Alejandro Serrano Mena : >> >> Dear Committee, >> When I took care of this proposal, the GitHub thread was quite dormant. >> However, it seems that right now there's quite some activity, and even >> proposals to completely redesign arrows. What is the right approach: let >> the discussion cool off, and then ask all of you to review the text (which >> I don't think is going to change substantially in any case) or move the >> proposal back to the previous state? >> >> Alejandro >> >> El vie., 15 may. 2020 a las 11:03, Richard Eisenberg () >> escribió: >> >>> I have some concerns -- mostly: is the improvement worth the >>> implementation complexity? I've posted on GitHub. >>> >>> Richard >>> >>> On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena >>> wrote: >>> >>> Dear Committee, >>> This proposal looks good to me. The author has done a lot of work to >>> formalize the new rules, and has done a check that no packages using arrow >>> syntax would be broken by this modification. Thus, I recommend we accept >>> this proposal. >>> >>> Apart from the general discussion, I think it might be worth focusing on >>> a specific part of the design: the use of a couple of type families to >>> express "arrow stacks". I am not aware of other GHC extensions depending on >>> particular type families. >>> - As the author discusses, these type families ought to be wired-in, so >>> they can benefit from improvement during type checking. Is this a good >>> choice? It looks to be, but other may have a different opinion. >>> - Would this type family pose a problem for optimization / >>> specialization / ...? >>> >>> Kind regards, >>> Alejandro >>> >>> El lun., 4 may. 2020 a las 23:08, Joachim Breitner (< >>> mail at joachim-breitner.de>) escribió: >>> >>>> Dear Committee >>>> >>>> I took the liberty to re-asssign #303 to Alejandro; the authors >>>> rightfully asked for progress in the discussion thread. >>>> >>>> Cheers, >>>> Joachim >>>> >>>> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: >>>> > Dear Committee, >>>> > >>>> > this is your secretary speaking: >>>> > >>>> > Constraint based arrow notation >>>> > has been proposed by Aleix King >>>> > https://github.com/ghc-proposals/ghc-proposals/pull/303 >>>> > >>>> https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md >>>> > >>>> > I propose Chris Done as the shepherd. >>>> > >>>> > Please guide us to a conclusion as outlined in >>>> > https://github.com/ghc-proposals/ghc-proposals#committee-process >>>> > >>>> > Thanks, >>>> > Joachim >>>> -- >>>> Joachim Breitner >>>> mail at joachim-breitner.de >>>> http://www.joachim-breitner.de/ >>>> >>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Jun 2 08:42:39 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 2 Jun 2020 09:42:39 +0100 Subject: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules In-Reply-To: References: Message-ID: > On Jun 1, 2020, at 7:37 PM, Alejandro Serrano Mena wrote: > > - I am surprised by the complicated way to introduce that "~" and "[]" are built-in to the language, by means of a new "Data.BuiltinTypes" which is always in scope, unless you disable with another extension. I would be very happy to have those are wired-in types in the language, which cannot be overriden. Quite separately from the rest of the proposal, this aspect might be seen as a side benefit. When -XStrict was introduced, people asked whether -XStrict made Haskell a strict language. Though it's not the only reason, one "no" answer was justified by the fact that built-in types with privileged syntax (i.e. lists and tuples) are always lazy. By allowing users to define and import/export these types themselves, some users can choose to use strict versions. Note that such a choice would be entirely local to a module, and mediated by familiar import/export of identifiers. Another way to see this: -XRebindableSyntax allows changing the meaning of privileged syntax in terms, but nothing yet allows such a change in types. If a proposal came along that included only the ability to redefine and import/export built-in types -- without anything else about punning or extending lookup rules -- I would probably be ever-so-slightly against, just because of the annoyance of having to suppress the automatic import (-XNoImplicitBuiltIntTypes, in this proposal). But I think extra benefits of this proposal make rebound types worthwhile, and I also think the rebound types would find uptake in our community independent of the rest of this proposal. Richard From mail at joachim-breitner.de Tue Jun 2 08:55:42 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 02 Jun 2020 10:55:42 +0200 Subject: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules In-Reply-To: References: Message-ID: <31ed71bb11be4bff139efa881de1ef13ab572ea1.camel@joachim-breitner.de> Hi, Am Montag, den 01.06.2020, 09:39 -0700 schrieb Iavor Diatchki: > I am the shepherd for proposal #270, and it is time for the committee to review the proposal. The discussion and the proposal are available here: > https://github.com/ghc-proposals/ghc-proposals/pull/270 the author also put forward “Visible 'forall' in types of terms” https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst https://github.com/ghc-proposals/ghc-proposals/pull/281 which depends on #270 and should be considered as a motivation for #270 Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Tue Jun 2 11:12:55 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 Jun 2020 11:12:55 +0000 Subject: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules In-Reply-To: References: Message-ID: I have commented on the main thread, since I have technical questions. Simon From: ghc-steering-committee On Behalf Of Alejandro Serrano Mena Sent: 01 June 2020 19:37 To: Iavor Diatchki Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules Hi again, My first message was quite short, and I guess I should explain my rejection a bit further. Although I am aware that sometime changes can only be made "in bulk", I think that this proposal in particular changes too many things core to the language. - I am surprised by the complicated way to introduce that "~" and "[]" are built-in to the language, by means of a new "Data.BuiltinTypes" which is always in scope, unless you disable with another extension. I would be very happy to have those are wired-in types in the language, which cannot be overriden. - The use of ticks in TH have served us well. I think we should not go as far as removing that until we see whether this disambiguation strategy works on simpler cases. Thereis one thing I like *a lot* from this proposal: the ability to import types and terms under different qualifiers. I could well imagine myself replacing the common > import Data.ByteString (ByteString) > import qualified Data.ByteString as B with > import Data.ByteString type > import qualified Data.ByteString as B To be honest, I was not aware that GHC had 5 different ways to disambiguate the namespace (thanks Richard for the informative message!). In my mind, I've always had sort of the following intuition: - ' promotes from term to type level, @ demotes (?) from type level to term level *in expressions* - except in TH, where you need ' to quote a term and '' to quote a type Regards, Alejandro El lun., 1 jun. 2020 a las 19:10, Alejandro Serrano Mena (>) escribió: Hi, My first reaction is also to reject this proposal. I feel it is too invasive. Regards, Alejandro El lun., 1 jun. 2020 a las 18:40, Iavor Diatchki (>) escribió: Hello, I am the shepherd for proposal #270, and it is time for the committee to review the proposal. The discussion and the proposal are available here: https://github.com/ghc-proposals/ghc-proposals/pull/270 Here is my summary of the proposal: The proposal aims to solve the "namespace problem" which appears to largely be related to fact that Haskell has two namespaces, and so types and values may have the same name. Proposed changes: 1. Change the scoping rules for the language so that type names are in scope at the value level, but values always shadow types. 2. Add a new form of import, which can import only the names from a particular names space 3. Change the way built-in syntax for tuples and lists works and deprecated ' and '' from DataKinds and TH respectively. This is a bit elaborate, have a look in the proposal for details 4. Add a bunch of warnings that would trigger if you wrote code that made use of Haskell's different name spaces My recommendation is that the proposal is rejected, as I don't think that these changes would help Haskell programmers, at least based on the way I use Haskell. In particular, here are my thoughts on each of the above bullets: 1. This is mostly about passing type arguments to functions---I would prefer a notation that is more explicit about the fact that we are passing in a type, and not just a normal argument. 2. When I group things into modules, it is usually because they are intended to be used together. I think I would rarely want to import only the types or only the values in a module, so I imagine it would be much more common to have to write two imports. 3. This is quite an intrusive change, that is likely to break code. I am also not keen to have to use type families, every time I want to use a tuple. 4. Using the same name for a data constructor and a type is very common in Haskell. I find it particularly useful when defining records. I don't need warnings to let me know that I've done it, as it is highly unlikely that I did it on accident. -Iavor _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Jun 3 09:03:14 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 3 Jun 2020 11:03:14 +0200 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept Message-ID: Dear all, Last time around that we had a discussion about this proposal, the authors asked to have some more time to revise a few things. Since then, the proposal has been simplified, and the paper accepted (congratulations!). Last time around, those of us who opined were mostly in agreement with accepting the proposal, though there were some distracting complications. Which have since been forked (and accepted) as proposal #287 . I do believe that this iteration of the proposal is a no-brainer. It simply gives a clear semantics to the unspecified -XImpredicativeTypes. It’s useful, and an implementation already exists (!3220 ). The summary of the proposed specification is: to instantiate a type variable to something of the form forall a. …, go through arguments and look for an absolutely necessary such instantiation (which will happen when there is a data constructor: [a] ~ [forall b.t] iif a = forall b.t). The only point which we may want to discuss is ($), which currently has an ad hoc typing rule baked in the type checker. The proposal suggests removing this baked in rule, and replacing it with making ($) always use the -XImpredicativeTypes typing rule. An alternative, of course, is to simply not treat ($) any specially, and require -XImpredicativeTypes to be explicitly turned on when one wants runST $ do …. But, as the proposal points out, this would break a lot of existing programs. So I agree with the proposal’s choice. In summary, I recommend accepting this proposal in its current state. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Jun 3 09:25:49 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 3 Jun 2020 11:25:49 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> <9212CD04-ABEC-4709-91EC-F315835A6DD4@richarde.dev> Message-ID: It seems to me that the proposal is well-motivated and well-written. It proposes to dust up a dark corner of GHC. I don't have technical insight into this, but it does look like something worth accepting, and not really costly. Do I understand correctly that the choice between wired-in and non-wired-in type families is mostly an implementation detail? If so, this is a conversation which would best take place in the corresponding MR, rather than in the proposal. On Mon, Jun 1, 2020 at 9:44 PM Alejandro Serrano Mena wrote: > Dear Committee, > Apart from Richard's concerns about wired-in families, there seems that > there is no further discussion regarding this topics. > If nobody raises any further concern, I'll write back to the author of the > proposal asking them to remove or rework that part. > > Regards, > Alejandro > > El lun., 25 may. 2020 a las 13:14, Richard Eisenberg () > escribió: > >> I'm in support of the proposal as written, perhaps with the exception of >> the special error-handling for ArrowStackTup (which I think is unnecessary). >> >> On May 24, 2020, at 8:19 PM, Alejandro Serrano Mena >> wrote: >> - Should the proposal be under a different extension or under `Arrows`? >> >> >> No. As the proposal authors argue, the backward-compatibility problem is >> essentially non-existent, because the feature is so inconvenient to use >> today that no one does. >> >> - Should a flattened or nested tuple representation be used? This >> comments [ >> https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-633199848] >> may give you some additional information. >> >> >> I prefer the flat tuples. If need be, this can revisited in the future, >> but the flat tuples seem better today. >> >> - Should the type families described there be wired-in? >> >> >> I don't see a need for this. The type families will necessarily be part >> of the specification of these features, and so their appearance in error >> messages are not an example of abstraction leakage. Maybe we want to >> carefully normaliseType here or there to avoid them unnecessarily, but I >> see no need to wire-in. >> >> Richard >> >> >> Looking forward to hearing from everyone. This is a complex proposal, >> with possible future ramifications. If there's no discussion in one week, >> I'll write again to the list. >> Regards, >> Alejandro >> >> El mar., 19 may. 2020 a las 9:02, Joachim Breitner (< >> mail at joachim-breitner.de>) escribió: >> >>> If there is active discussion, we usually put it back to the previous >>> state, and wait for discussion to come to conclusions. >>> >>> 19.05.2020 08:36:42 Alejandro Serrano Mena : >>> >>> Dear Committee, >>> When I took care of this proposal, the GitHub thread was quite dormant. >>> However, it seems that right now there's quite some activity, and even >>> proposals to completely redesign arrows. What is the right approach: let >>> the discussion cool off, and then ask all of you to review the text (which >>> I don't think is going to change substantially in any case) or move the >>> proposal back to the previous state? >>> >>> Alejandro >>> >>> El vie., 15 may. 2020 a las 11:03, Richard Eisenberg () >>> escribió: >>> >>>> I have some concerns -- mostly: is the improvement worth the >>>> implementation complexity? I've posted on GitHub. >>>> >>>> Richard >>>> >>>> On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena >>>> wrote: >>>> >>>> Dear Committee, >>>> This proposal looks good to me. The author has done a lot of work to >>>> formalize the new rules, and has done a check that no packages using arrow >>>> syntax would be broken by this modification. Thus, I recommend we accept >>>> this proposal. >>>> >>>> Apart from the general discussion, I think it might be worth focusing >>>> on a specific part of the design: the use of a couple of type families to >>>> express "arrow stacks". I am not aware of other GHC extensions depending on >>>> particular type families. >>>> - As the author discusses, these type families ought to be wired-in, so >>>> they can benefit from improvement during type checking. Is this a good >>>> choice? It looks to be, but other may have a different opinion. >>>> - Would this type family pose a problem for optimization / >>>> specialization / ...? >>>> >>>> Kind regards, >>>> Alejandro >>>> >>>> El lun., 4 may. 2020 a las 23:08, Joachim Breitner (< >>>> mail at joachim-breitner.de>) escribió: >>>> >>>>> Dear Committee >>>>> >>>>> I took the liberty to re-asssign #303 to Alejandro; the authors >>>>> rightfully asked for progress in the discussion thread. >>>>> >>>>> Cheers, >>>>> Joachim >>>>> >>>>> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: >>>>> > Dear Committee, >>>>> > >>>>> > this is your secretary speaking: >>>>> > >>>>> > Constraint based arrow notation >>>>> > has been proposed by Aleix King >>>>> > https://github.com/ghc-proposals/ghc-proposals/pull/303 >>>>> > >>>>> https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md >>>>> > >>>>> > I propose Chris Done as the shepherd. >>>>> > >>>>> > Please guide us to a conclusion as outlined in >>>>> > https://github.com/ghc-proposals/ghc-proposals#committee-process >>>>> > >>>>> > Thanks, >>>>> > Joachim >>>>> -- >>>>> Joachim Breitner >>>>> mail at joachim-breitner.de >>>>> http://www.joachim-breitner.de/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee at haskell.org >>>>> >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>>> >>>> >> _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Jun 3 10:04:51 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 3 Jun 2020 11:04:51 +0100 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> <9212CD04-ABEC-4709-91EC-F315835A6DD4@richarde.dev> Message-ID: <1DE1F444-E298-4660-9723-E0F9966A5A46@richarde.dev> > On Jun 3, 2020, at 10:25 AM, Spiwack, Arnaud wrote: > > It seems to me that the proposal is well-motivated and well-written. It proposes to dust up a dark corner of GHC. I don't have technical insight into this, but it does look like something worth accepting, and not really costly. I would say that there are real costs to this proposal, as can be seen by the new complexity introduced by the MR. But, as has been well argued, the complexity is worth the cost -- arrows are essentially only half-implemented without this. > > Do I understand correctly that the choice between wired-in and non-wired-in type families is mostly an implementation detail? If so, this is a conversation which would best take place in the corresponding MR, rather than in the proposal. I'm quite happy to delay this detail to the implementation. I don't think it's a critical piece, in either direction. And it's just about error messages, which are generally not part of proposals proper. Thanks, Richard > > On Mon, Jun 1, 2020 at 9:44 PM Alejandro Serrano Mena > wrote: > Dear Committee, > Apart from Richard's concerns about wired-in families, there seems that there is no further discussion regarding this topics. > If nobody raises any further concern, I'll write back to the author of the proposal asking them to remove or rework that part. > > Regards, > Alejandro > > El lun., 25 may. 2020 a las 13:14, Richard Eisenberg (>) escribió: > I'm in support of the proposal as written, perhaps with the exception of the special error-handling for ArrowStackTup (which I think is unnecessary). > >> On May 24, 2020, at 8:19 PM, Alejandro Serrano Mena > wrote: >> - Should the proposal be under a different extension or under `Arrows`? > > No. As the proposal authors argue, the backward-compatibility problem is essentially non-existent, because the feature is so inconvenient to use today that no one does. > >> - Should a flattened or nested tuple representation be used? This comments [https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-633199848 ] may give you some additional information. > > I prefer the flat tuples. If need be, this can revisited in the future, but the flat tuples seem better today. > >> - Should the type families described there be wired-in? > > I don't see a need for this. The type families will necessarily be part of the specification of these features, and so their appearance in error messages are not an example of abstraction leakage. Maybe we want to carefully normaliseType here or there to avoid them unnecessarily, but I see no need to wire-in. > > Richard > >> >> Looking forward to hearing from everyone. This is a complex proposal, with possible future ramifications. If there's no discussion in one week, I'll write again to the list. >> Regards, >> Alejandro >> >> El mar., 19 may. 2020 a las 9:02, Joachim Breitner (>) escribió: >> If there is active discussion, we usually put it back to the previous state, and wait for discussion to come to conclusions. >> >> 19.05.2020 08:36:42 Alejandro Serrano Mena >: >> >> Dear Committee, >> When I took care of this proposal, the GitHub thread was quite dormant. However, it seems that right now there's quite some activity, and even proposals to completely redesign arrows. What is the right approach: let the discussion cool off, and then ask all of you to review the text (which I don't think is going to change substantially in any case) or move the proposal back to the previous state? >> >> Alejandro >> >> El vie., 15 may. 2020 a las 11:03, Richard Eisenberg (>) escribió: >> I have some concerns -- mostly: is the improvement worth the implementation complexity? I've posted on GitHub. >> >> Richard >> >>> On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena > wrote: >>> >>> Dear Committee, >>> This proposal looks good to me. The author has done a lot of work to formalize the new rules, and has done a check that no packages using arrow syntax would be broken by this modification. Thus, I recommend we accept this proposal. >>> >>> Apart from the general discussion, I think it might be worth focusing on a specific part of the design: the use of a couple of type families to express "arrow stacks". I am not aware of other GHC extensions depending on particular type families. >>> - As the author discusses, these type families ought to be wired-in, so they can benefit from improvement during type checking. Is this a good choice? It looks to be, but other may have a different opinion. >>> - Would this type family pose a problem for optimization / specialization / ...? >>> >>> Kind regards, >>> Alejandro >>> >>> El lun., 4 may. 2020 a las 23:08, Joachim Breitner (>) escribió: >>> Dear Committee >>> >>> I took the liberty to re-asssign #303 to Alejandro; the authors >>> rightfully asked for progress in the discussion thread. >>> >>> Cheers, >>> Joachim >>> >>> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: >>> > Dear Committee, >>> > >>> > this is your secretary speaking: >>> > >>> > Constraint based arrow notation >>> > has been proposed by Aleix King >>> > https://github.com/ghc-proposals/ghc-proposals/pull/303 >>> > https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md >>> > >>> > I propose Chris Done as the shepherd. >>> > >>> > Please guide us to a conclusion as outlined in >>> > https://github.com/ghc-proposals/ghc-proposals#committee-process >>> > >>> > Thanks, >>> > Joachim >>> -- >>> Joachim Breitner >>> mail at joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Jun 3 10:05:26 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 3 Jun 2020 11:05:26 +0100 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept In-Reply-To: References: Message-ID: I'm in strong support. This will be a nice win for GHC. Richard > On Jun 3, 2020, at 10:03 AM, Spiwack, Arnaud wrote: > > Dear all, > > Last time around that we had a discussion about this proposal, the authors asked to have some more time to revise a few things. Since then, the proposal has been simplified, and the paper accepted (congratulations!). > > Last time around, those of us who opined were mostly in agreement with accepting the proposal, though there were some distracting complications. Which have since been forked (and accepted) as proposal #287 . I do believe that this iteration of the proposal is a no-brainer. It simply gives a clear semantics to the unspecified -XImpredicativeTypes. It’s useful, and an implementation already exists (!3220 ). > > The summary of the proposed specification is: to instantiate a type variable to something of the form forall a. …, go through arguments and look for an absolutely necessary such instantiation (which will happen when there is a data constructor: [a] ~ [forall b.t] iif a = forall b.t). > > The only point which we may want to discuss is ($), which currently has an ad hoc typing rule baked in the type checker. The proposal suggests removing this baked in rule, and replacing it with making ($) always use the -XImpredicativeTypes typing rule. An alternative, of course, is to simply not treat ($) any specially, and require -XImpredicativeTypes to be explicitly turned on when one wants runST $ do …. But, as the proposal points out, this would break a lot of existing programs. So I agree with the proposal’s choice. > > In summary, I recommend accepting this proposal in its current state. > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Jun 3 10:19:14 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Jun 2020 12:19:14 +0200 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept In-Reply-To: References: Message-ID: <8bc2b862a76d590cd47566ac855948059013f51b.camel@joachim-breitner.de> Hi, SGTM. I didn’t actually read the full proposal, but watched Simon PJ’s talk on it. I hope that counts. Cheers, Joachim Am Mittwoch, den 03.06.2020, 11:03 +0200 schrieb Spiwack, Arnaud: > Dear all, > > Last time around that we had a discussion about this proposal, the authors asked to have some more time to revise a few things. Since then, the proposal has been simplified, and the paper accepted (congratulations!). > > Last time around, those of us who opined were mostly in agreement with accepting the proposal, though there were some distracting complications. Which have since been forked (and accepted) as proposal #287. I do believe that this iteration of the proposal is a no-brainer. It simply gives a clear semantics to the unspecified -XImpredicativeTypes. It’s useful, and an implementation already exists (!3220). > > The summary of the proposed specification is: to instantiate a type variable to something of the form forall a. …, go through arguments and look for an absolutely necessary such instantiation (which will happen when there is a data constructor: [a] ~ [forall b.t] iif a = forall b.t). > > The only point which we may want to discuss is ($), which currently has an ad hoc typing rule baked in the type checker. The proposal suggests removing this baked in rule, and replacing it with making ($) always use the -XImpredicativeTypes typing rule. An alternative, of course, is to simply not treat ($) any specially, and require -XImpredicativeTypes to be explicitly turned on when one wants runST $ do …. But, as the proposal points out, this would break a lot of existing programs. So I agree with the proposal’s choice. > > In summary, I recommend accepting this proposal in its current state. > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From bravit111 at gmail.com Wed Jun 3 16:02:26 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Wed, 3 Jun 2020 19:02:26 +0300 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept In-Reply-To: References: Message-ID: Hi, I support the proposal. Vitaly ср, 3 июн. 2020 г. в 12:04, Spiwack, Arnaud : > Dear all, > > Last time around that we had a discussion about this proposal, the authors > asked to have some more time to revise a few things. Since then, the > proposal has been simplified, and the paper accepted (congratulations!). > > Last time around, those of us who opined were mostly in agreement with > accepting the proposal, though there were some distracting complications. > Which have since been forked (and accepted) as proposal #287 > . > I do believe that this iteration of the proposal is a no-brainer. It simply > gives a clear semantics to the unspecified -XImpredicativeTypes. It’s > useful, and an implementation already exists (!3220 > ). > > The summary of the proposed specification is: to instantiate a type > variable to something of the form forall a. …, go through arguments and > look for an absolutely necessary such instantiation (which will happen when > there is a data constructor: [a] ~ [forall b.t] iif a = forall b.t). > > The only point which we may want to discuss is ($), which currently has > an ad hoc typing rule baked in the type checker. The proposal suggests > removing this baked in rule, and replacing it with making ($) always use > the -XImpredicativeTypes typing rule. An alternative, of course, is to > simply not treat ($) any specially, and require -XImpredicativeTypes to > be explicitly turned on when one wants runST $ do …. But, as the proposal > points out, this would break a lot of existing programs. So I agree with > the proposal’s choice. > > In summary, I recommend accepting this proposal in its current state. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Jun 4 05:58:55 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 4 Jun 2020 07:58:55 +0200 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept In-Reply-To: References: Message-ID: Dear all, I didn't give ourselves a deadline on this one. Let me fix this: unless a significant objection has arisen by 12th June, let us accept this proposal. Best, Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Fri Jun 5 17:01:00 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 5 Jun 2020 19:01:00 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: <1DE1F444-E298-4660-9723-E0F9966A5A46@richarde.dev> References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> <9212CD04-ABEC-4709-91EC-F315835A6DD4@richarde.dev> <1DE1F444-E298-4660-9723-E0F9966A5A46@richarde.dev> Message-ID: I've updated the GH thread of this proposal to "revisions needed". Regards, Alejandro El mié., 3 jun. 2020 a las 12:04, Richard Eisenberg () escribió: > > > On Jun 3, 2020, at 10:25 AM, Spiwack, Arnaud > wrote: > > It seems to me that the proposal is well-motivated and well-written. It > proposes to dust up a dark corner of GHC. I don't have technical insight > into this, but it does look like something worth accepting, and not really > costly. > > > I would say that there are real costs to this proposal, as can be seen by > the new complexity introduced by the MR. But, as has been well argued, the > complexity is worth the cost -- arrows are essentially only > half-implemented without this. > > > Do I understand correctly that the choice between wired-in and > non-wired-in type families is mostly an implementation detail? If so, this > is a conversation which would best take place in the corresponding MR, > rather than in the proposal. > > > I'm quite happy to delay this detail to the implementation. I don't think > it's a critical piece, in either direction. And it's just about error > messages, which are generally not part of proposals proper. > > Thanks, > Richard > > > On Mon, Jun 1, 2020 at 9:44 PM Alejandro Serrano Mena > wrote: > >> Dear Committee, >> Apart from Richard's concerns about wired-in families, there seems that >> there is no further discussion regarding this topics. >> If nobody raises any further concern, I'll write back to the author of >> the proposal asking them to remove or rework that part. >> >> Regards, >> Alejandro >> >> El lun., 25 may. 2020 a las 13:14, Richard Eisenberg () >> escribió: >> >>> I'm in support of the proposal as written, perhaps with the exception of >>> the special error-handling for ArrowStackTup (which I think is unnecessary). >>> >>> On May 24, 2020, at 8:19 PM, Alejandro Serrano Mena >>> wrote: >>> - Should the proposal be under a different extension or under `Arrows`? >>> >>> >>> No. As the proposal authors argue, the backward-compatibility problem is >>> essentially non-existent, because the feature is so inconvenient to use >>> today that no one does. >>> >>> - Should a flattened or nested tuple representation be used? This >>> comments [ >>> https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-633199848] >>> may give you some additional information. >>> >>> >>> I prefer the flat tuples. If need be, this can revisited in the future, >>> but the flat tuples seem better today. >>> >>> - Should the type families described there be wired-in? >>> >>> >>> I don't see a need for this. The type families will necessarily be part >>> of the specification of these features, and so their appearance in error >>> messages are not an example of abstraction leakage. Maybe we want to >>> carefully normaliseType here or there to avoid them unnecessarily, but I >>> see no need to wire-in. >>> >>> Richard >>> >>> >>> Looking forward to hearing from everyone. This is a complex proposal, >>> with possible future ramifications. If there's no discussion in one week, >>> I'll write again to the list. >>> Regards, >>> Alejandro >>> >>> El mar., 19 may. 2020 a las 9:02, Joachim Breitner (< >>> mail at joachim-breitner.de>) escribió: >>> >>>> If there is active discussion, we usually put it back to the previous >>>> state, and wait for discussion to come to conclusions. >>>> >>>> 19.05.2020 08:36:42 Alejandro Serrano Mena : >>>> >>>> Dear Committee, >>>> When I took care of this proposal, the GitHub thread was quite dormant. >>>> However, it seems that right now there's quite some activity, and even >>>> proposals to completely redesign arrows. What is the right approach: let >>>> the discussion cool off, and then ask all of you to review the text (which >>>> I don't think is going to change substantially in any case) or move the >>>> proposal back to the previous state? >>>> >>>> Alejandro >>>> >>>> El vie., 15 may. 2020 a las 11:03, Richard Eisenberg () >>>> escribió: >>>> >>>>> I have some concerns -- mostly: is the improvement worth the >>>>> implementation complexity? I've posted on GitHub. >>>>> >>>>> Richard >>>>> >>>>> On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena >>>>> wrote: >>>>> >>>>> Dear Committee, >>>>> This proposal looks good to me. The author has done a lot of work to >>>>> formalize the new rules, and has done a check that no packages using arrow >>>>> syntax would be broken by this modification. Thus, I recommend we accept >>>>> this proposal. >>>>> >>>>> Apart from the general discussion, I think it might be worth focusing >>>>> on a specific part of the design: the use of a couple of type families to >>>>> express "arrow stacks". I am not aware of other GHC extensions depending on >>>>> particular type families. >>>>> - As the author discusses, these type families ought to be wired-in, >>>>> so they can benefit from improvement during type checking. Is this a good >>>>> choice? It looks to be, but other may have a different opinion. >>>>> - Would this type family pose a problem for optimization / >>>>> specialization / ...? >>>>> >>>>> Kind regards, >>>>> Alejandro >>>>> >>>>> El lun., 4 may. 2020 a las 23:08, Joachim Breitner (< >>>>> mail at joachim-breitner.de>) escribió: >>>>> >>>>>> Dear Committee >>>>>> >>>>>> I took the liberty to re-asssign #303 to Alejandro; the authors >>>>>> rightfully asked for progress in the discussion thread. >>>>>> >>>>>> Cheers, >>>>>> Joachim >>>>>> >>>>>> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: >>>>>> > Dear Committee, >>>>>> > >>>>>> > this is your secretary speaking: >>>>>> > >>>>>> > Constraint based arrow notation >>>>>> > has been proposed by Aleix King >>>>>> > https://github.com/ghc-proposals/ghc-proposals/pull/303 >>>>>> > >>>>>> https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md >>>>>> > >>>>>> > I propose Chris Done as the shepherd. >>>>>> > >>>>>> > Please guide us to a conclusion as outlined in >>>>>> > https://github.com/ghc-proposals/ghc-proposals#committee-process >>>>>> > >>>>>> > Thanks, >>>>>> > Joachim >>>>>> -- >>>>>> Joachim Breitner >>>>>> mail at joachim-breitner.de >>>>>> http://www.joachim-breitner.de/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-steering-committee mailing list >>>>>> ghc-steering-committee at haskell.org >>>>>> >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>>> >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee at haskell.org >>>>> >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> >>>>> >>>>> >>> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Jun 10 09:33:43 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 10 Jun 2020 11:33:43 +0200 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept In-Reply-To: References: Message-ID: Dear all, If you want to voice an opinion on this proposal, don't forget to do so before Friday night (12th June, anywhere on Earth). After that, I'll consider silence as assent and accept the proposal. Best, Arnaud On Thu, Jun 4, 2020 at 7:58 AM Spiwack, Arnaud wrote: > Dear all, > > I didn't give ourselves a deadline on this one. Let me fix this: unless a > significant objection has arisen by 12th June, let us accept this proposal. > > Best, > Arnaud > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Mon Jun 15 07:52:47 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 15 Jun 2020 09:52:47 +0200 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept In-Reply-To: References: Message-ID: Dear all, I don't know whether to take the lack of response as a good thing (as in: it's so uncontroversial that nobody has anything to say about it). But I believe it is time to accept this proposal. Simon, Alejandro: I've made a couple of typo-level suggestions in the proposal, have a look at them before we merge. Joachim: I have marked the proposal as accepted, but I forgot the process after that, again. Who is in charge of merging? On Wed, Jun 10, 2020 at 11:33 AM Spiwack, Arnaud wrote: > Dear all, > > If you want to voice an opinion on this proposal, don't forget to do so > before Friday night (12th June, anywhere on Earth). After that, I'll > consider silence as assent and accept the proposal. > > Best, > Arnaud > > On Thu, Jun 4, 2020 at 7:58 AM Spiwack, Arnaud > wrote: > >> Dear all, >> >> I didn't give ourselves a deadline on this one. Let me fix this: unless a >> significant objection has arisen by 12th June, let us accept this proposal. >> >> Best, >> Arnaud >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Jun 15 08:05:39 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 15 Jun 2020 10:05:39 +0200 Subject: [ghc-steering-committee] Proposal #274: Quicklook impredicativity, recommendation: accept In-Reply-To: References: Message-ID: <50a1d68df33a215c2c10c5e91e38cd8a81a61287.camel@joachim-breitner.de> Hi, Am Montag, den 15.06.2020, 09:52 +0200 schrieb Spiwack, Arnaud: > Joachim: I have marked the proposal as accepted, but I forgot the process after that, again. Who is in charge of merging? I’ll take care of it. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Mon Jun 15 19:29:48 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 15 Jun 2020 21:29:48 +0200 Subject: [ghc-steering-committee] Please review #333: Defer parse errors, Shepherd: Tom Harding Message-ID: Dear Committee, this is your secretary speaking: Defer parse errors has been proposed by our own Alejandro Serrano Mena https://github.com/ghc-proposals/ghc-proposals/pull/333 https://github.com/serras/ghc-proposals/blob/allow-unfinished-do/proposals/0000-allow-unfinished-do.md I propose Tom as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Thu Jun 18 21:28:33 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 18 Jun 2020 22:28:33 +0100 Subject: [ghc-steering-committee] Haddock Message-ID: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> Hi committee, With a steady level of activity adding new features to GHC, I fear we may be forgetting one important downstream client: Haddock. For a nice example of how our decisions can cause trouble, see https://github.com/goldfirere/singletons/issues/466#issuecomment-646117067. Despite appearing on the singletons bug tracker, that comment is all about Haddock support for https://github.com/ghc-proposals/ghc-proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054-kind-signatures.rst, the -XStandaloneKindSignatures extension. This makes me wonder: should we invite a maintainer of Haddock to be an ex-officio (and voting) member of the committee? This would have two salutary effects: - It would force us to consider an important aspect of the user experience -- reading documentation -- of newly proposed features. - It would force us to give Haddock a heads-up about new features they may want to incorporate. If we don't think we need an ex-officio committee member, then perhaps we should instead require future proposals to describe a plausible impact on Haddock. I say "plausible impact" to suggest that the proposal text would not be binding on Haddock (which would be awfully dictatorial of us), but that it gives Haddock a starting place to consider their own design, while forcing proposers to think about this important-but-easily-neglected aspect of language evolution. What do we think? Richard From simonpj at microsoft.com Fri Jun 19 15:35:02 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 19 Jun 2020 15:35:02 +0000 Subject: [ghc-steering-committee] Haddock In-Reply-To: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> Message-ID: Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Richard Eisenberg | Sent: 18 June 2020 22:29 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Haddock | | Hi committee, | | With a steady level of activity adding new features to GHC, I fear we may | be forgetting one important downstream client: Haddock. For a nice | example of how our decisions can cause trouble, see | https://github.com/goldfirere/singletons/issues/466#issuecomment- | 646117067. Despite appearing on the singletons bug tracker, that comment | is all about Haddock support for https://github.com/ghc-proposals/ghc- | proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- | kind-signatures.rst, the -XStandaloneKindSignatures extension. | | This makes me wonder: should we invite a maintainer of Haddock to be an | ex-officio (and voting) member of the committee? This would have two | salutary effects: | - It would force us to consider an important aspect of the user | experience -- reading documentation -- of newly proposed features. | - It would force us to give Haddock a heads-up about new features they | may want to incorporate. | | If we don't think we need an ex-officio committee member, then perhaps we | should instead require future proposals to describe a plausible impact on | Haddock. I say "plausible impact" to suggest that the proposal text would | not be binding on Haddock (which would be awfully dictatorial of us), but | that it gives Haddock a starting place to consider their own design, | while forcing proposers to think about this important-but-easily- | neglected aspect of language evolution. | | What do we think? | | Richard | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From cgibbard at gmail.com Fri Jun 19 16:00:41 2020 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri, 19 Jun 2020 12:00:41 -0400 Subject: [ghc-steering-committee] Haddock In-Reply-To: References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> Message-ID: In addition to this, it seems like the situation involving the relationship between commits on haddock and commits on GHC is currently somewhat unsatisfactory. In order to build an arbitrary commit on haddock, you need to know which commit of GHC to use to build it, but instead, the commits of GHC have a pointer to the haddock repo, rather than the other way around. I remember being surprised that the git submodule relationship wasn't at least in the opposite direction. I think it would make a fair amount of sense just to regard haddock as being a full-fledged part of GHC and perhaps just unify the repositories, since it's so intimately connected to GHC's internals anyway, but I might be unaware of other constraints on its development process. On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via ghc-steering-committee wrote: > > Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; > but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee > | On Behalf Of Richard Eisenberg > | Sent: 18 June 2020 22:29 > | To: ghc-steering-committee > | Subject: [ghc-steering-committee] Haddock > | > | Hi committee, > | > | With a steady level of activity adding new features to GHC, I fear we may > | be forgetting one important downstream client: Haddock. For a nice > | example of how our decisions can cause trouble, see > | https://github.com/goldfirere/singletons/issues/466#issuecomment- > | 646117067. Despite appearing on the singletons bug tracker, that comment > | is all about Haddock support for https://github.com/ghc-proposals/ghc- > | proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- > | kind-signatures.rst, the -XStandaloneKindSignatures extension. > | > | This makes me wonder: should we invite a maintainer of Haddock to be an > | ex-officio (and voting) member of the committee? This would have two > | salutary effects: > | - It would force us to consider an important aspect of the user > | experience -- reading documentation -- of newly proposed features. > | - It would force us to give Haddock a heads-up about new features they > | may want to incorporate. > | > | If we don't think we need an ex-officio committee member, then perhaps we > | should instead require future proposals to describe a plausible impact on > | Haddock. I say "plausible impact" to suggest that the proposal text would > | not be binding on Haddock (which would be awfully dictatorial of us), but > | that it gives Haddock a starting place to consider their own design, > | while forcing proposers to think about this important-but-easily- > | neglected aspect of language evolution. > | > | What do we think? > | > | Richard > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From iavor.diatchki at gmail.com Fri Jun 19 16:50:45 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 19 Jun 2020 09:50:45 -0700 Subject: [ghc-steering-committee] Haddock In-Reply-To: References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> Message-ID: Hello, I think having a committee member who's involved with `haddock` makes sense, as `haddock` really is very tightly coupled with GHC. This, of course, presumes that Simon M is not actively involved with `haddock` anymore, otherwise we already have a representative. More generally, I think it is good if there is some overlap between various communities/organizations/projects, as it makes dissemination of information much smoother, and knowing what's happening in "the community", well, makes the community. I would recommend reaching out to Alec Theriault (`harpocrates` on git-hub). I've worked with him in the past and he is very smart and thoughtful. I have not spoken to him, so I am not sure if he'd be up for taking up the position, but if we do decide to invite Alec, I'd be happy to reach out and ask him. -Iavor On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote: > In addition to this, it seems like the situation involving the > relationship between commits on haddock and commits on GHC is > currently somewhat unsatisfactory. In order to build an arbitrary > commit on haddock, you need to know which commit of GHC to use to > build it, but instead, the commits of GHC have a pointer to the > haddock repo, rather than the other way around. I remember being > surprised that the git submodule relationship wasn't at least in the > opposite direction. > > I think it would make a fair amount of sense just to regard haddock as > being a full-fledged part of GHC and perhaps just unify the > repositories, since it's so intimately connected to GHC's internals > anyway, but I might be unaware of other constraints on its development > process. > > > On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via > ghc-steering-committee wrote: > > > > Good thought. Personally, I'd be happy to have a Haddock maintainer on > the committee; > > but I'd like them to be a full member, contributing to the discussion > and shepherding proposals -- not merely acting as the Haddock liaison. > > > > Simon > > > > | -----Original Message----- > > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > > | On Behalf Of Richard Eisenberg > > | Sent: 18 June 2020 22:29 > > | To: ghc-steering-committee > > | Subject: [ghc-steering-committee] Haddock > > | > > | Hi committee, > > | > > | With a steady level of activity adding new features to GHC, I fear we > may > > | be forgetting one important downstream client: Haddock. For a nice > > | example of how our decisions can cause trouble, see > > | https://github.com/goldfirere/singletons/issues/466#issuecomment- > > | 646117067. Despite appearing on the singletons bug tracker, that > comment > > | is all about Haddock support for > https://github.com/ghc-proposals/ghc- > > | > proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- > > | kind-signatures.rst, the -XStandaloneKindSignatures extension. > > | > > | This makes me wonder: should we invite a maintainer of Haddock to be > an > > | ex-officio (and voting) member of the committee? This would have two > > | salutary effects: > > | - It would force us to consider an important aspect of the user > > | experience -- reading documentation -- of newly proposed features. > > | - It would force us to give Haddock a heads-up about new features they > > | may want to incorporate. > > | > > | If we don't think we need an ex-officio committee member, then > perhaps we > > | should instead require future proposals to describe a plausible > impact on > > | Haddock. I say "plausible impact" to suggest that the proposal text > would > > | not be binding on Haddock (which would be awfully dictatorial of us), > but > > | that it gives Haddock a starting place to consider their own design, > > | while forcing proposers to think about this important-but-easily- > > | neglected aspect of language evolution. > > | > > | What do we think? > > | > > | Richard > > | _______________________________________________ > > | ghc-steering-committee mailing list > > | ghc-steering-committee at haskell.org > > | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Jun 22 11:04:20 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 22 Jun 2020 12:04:20 +0100 Subject: [ghc-steering-committee] committee constitution In-Reply-To: References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> Message-ID: <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> Broadening from my thoughts on having a Haddock representative, I wonder if we should aim to have a "balanced" committee. I seem to recall (but can't find evidence of, after ~5 minutes of searching) that we started this steering committee with the aim of representing various different interests. We even had, somewhere, I believe, a list of different constituencies we wished to include. When we have considered this kind of diversity when selecting new members, we've also generally worked with whatever nominations we've received, instead of seeking out particular people. I'd like to propose that we reify a set of constituencies that we aim to always represent. When someone retires from the committee, we would then both seek nominations and think creatively about folks to invite from the constituency(ies) that are being left vacant by the retirement. Here is an initial proposed list of constituencies. If there is a "2x", it means we should have at least two steering committee members from that constituency. GHC developer (2x) Educator Industry practitioner (2x) Haddock developer Researcher IDE tooling developer GHC fork developer (maybe) On GHC port developer: there seem to be a growing number of GHC forks, and it might be nice to incorporate someone in that position into our committee. Examples: GHCJS, Asterius, DAML. One individual can fill multiple constituency needs, and overrepresentation is fine. So, I ask two separate questions: 1. Should we have such a list? 2. If yes, what do we think of this list, in particular? It would be great to hear from everyone on the committee on this point. If we answer "yes" to (1), I would expect us to add the list to https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments. Thanks, Richard > On Jun 19, 2020, at 5:50 PM, Iavor Diatchki wrote: > > Hello, > > I think having a committee member who's involved with `haddock` makes sense, as `haddock` really is very tightly coupled with GHC. This, of course, presumes that Simon M is not actively involved with `haddock` anymore, otherwise we already have a representative. > > More generally, I think it is good if there is some overlap between various communities/organizations/projects, as it makes dissemination of information much smoother, and knowing what's happening in "the community", well, makes the community. > > I would recommend reaching out to Alec Theriault (`harpocrates` on git-hub). I've worked with him in the past and he is very smart and thoughtful. I have not spoken to him, so I am not sure if he'd be up for taking up the position, but if we do decide to invite Alec, I'd be happy to reach out and ask him. > > -Iavor > > > On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard > wrote: > In addition to this, it seems like the situation involving the > relationship between commits on haddock and commits on GHC is > currently somewhat unsatisfactory. In order to build an arbitrary > commit on haddock, you need to know which commit of GHC to use to > build it, but instead, the commits of GHC have a pointer to the > haddock repo, rather than the other way around. I remember being > surprised that the git submodule relationship wasn't at least in the > opposite direction. > > I think it would make a fair amount of sense just to regard haddock as > being a full-fledged part of GHC and perhaps just unify the > repositories, since it's so intimately connected to GHC's internals > anyway, but I might be unaware of other constraints on its development > process. > > > On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via > ghc-steering-committee > wrote: > > > > Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; > > but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison. > > > > Simon > > > > | -----Original Message----- > > | From: ghc-steering-committee > > > | On Behalf Of Richard Eisenberg > > | Sent: 18 June 2020 22:29 > > | To: ghc-steering-committee > > > | Subject: [ghc-steering-committee] Haddock > > | > > | Hi committee, > > | > > | With a steady level of activity adding new features to GHC, I fear we may > > | be forgetting one important downstream client: Haddock. For a nice > > | example of how our decisions can cause trouble, see > > | https://github.com/goldfirere/singletons/issues/466#issuecomment- > > | 646117067. Despite appearing on the singletons bug tracker, that comment > > | is all about Haddock support for https://github.com/ghc-proposals/ghc- > > | proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- > > | kind-signatures.rst, the -XStandaloneKindSignatures extension. > > | > > | This makes me wonder: should we invite a maintainer of Haddock to be an > > | ex-officio (and voting) member of the committee? This would have two > > | salutary effects: > > | - It would force us to consider an important aspect of the user > > | experience -- reading documentation -- of newly proposed features. > > | - It would force us to give Haddock a heads-up about new features they > > | may want to incorporate. > > | > > | If we don't think we need an ex-officio committee member, then perhaps we > > | should instead require future proposals to describe a plausible impact on > > | Haddock. I say "plausible impact" to suggest that the proposal text would > > | not be binding on Haddock (which would be awfully dictatorial of us), but > > | that it gives Haddock a starting place to consider their own design, > > | while forcing proposers to think about this important-but-easily- > > | neglected aspect of language evolution. > > | > > | What do we think? > > | > > | Richard > > | _______________________________________________ > > | ghc-steering-committee mailing list > > | ghc-steering-committee at haskell.org > > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jun 22 12:33:53 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Jun 2020 12:33:53 +0000 Subject: [ghc-steering-committee] committee constitution In-Reply-To: <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> Message-ID: I agree with making a list of constituencies. We could also list which constituencies we think the current membership reflects. This gives a way for self-nominations to say "I fill a gap". I'm not so keen on "GHC fork dev" and more keen on "GHC API client", including plugins. That overlaps with IDE tooling, but is not subsumed by IDE. Yes the list should be on our main home page. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 22 June 2020 12:04 To: Iavor Diatchki Cc: ghc-steering-committee Subject: [ghc-steering-committee] committee constitution Broadening from my thoughts on having a Haddock representative, I wonder if we should aim to have a "balanced" committee. I seem to recall (but can't find evidence of, after ~5 minutes of searching) that we started this steering committee with the aim of representing various different interests. We even had, somewhere, I believe, a list of different constituencies we wished to include. When we have considered this kind of diversity when selecting new members, we've also generally worked with whatever nominations we've received, instead of seeking out particular people. I'd like to propose that we reify a set of constituencies that we aim to always represent. When someone retires from the committee, we would then both seek nominations and think creatively about folks to invite from the constituency(ies) that are being left vacant by the retirement. Here is an initial proposed list of constituencies. If there is a "2x", it means we should have at least two steering committee members from that constituency. GHC developer (2x) Educator Industry practitioner (2x) Haddock developer Researcher IDE tooling developer GHC fork developer (maybe) On GHC port developer: there seem to be a growing number of GHC forks, and it might be nice to incorporate someone in that position into our committee. Examples: GHCJS, Asterius, DAML. One individual can fill multiple constituency needs, and overrepresentation is fine. So, I ask two separate questions: 1. Should we have such a list? 2. If yes, what do we think of this list, in particular? It would be great to hear from everyone on the committee on this point. If we answer "yes" to (1), I would expect us to add the list to https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments. Thanks, Richard On Jun 19, 2020, at 5:50 PM, Iavor Diatchki > wrote: Hello, I think having a committee member who's involved with `haddock` makes sense, as `haddock` really is very tightly coupled with GHC. This, of course, presumes that Simon M is not actively involved with `haddock` anymore, otherwise we already have a representative. More generally, I think it is good if there is some overlap between various communities/organizations/projects, as it makes dissemination of information much smoother, and knowing what's happening in "the community", well, makes the community. I would recommend reaching out to Alec Theriault (`harpocrates` on git-hub). I've worked with him in the past and he is very smart and thoughtful. I have not spoken to him, so I am not sure if he'd be up for taking up the position, but if we do decide to invite Alec, I'd be happy to reach out and ask him. -Iavor On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard > wrote: In addition to this, it seems like the situation involving the relationship between commits on haddock and commits on GHC is currently somewhat unsatisfactory. In order to build an arbitrary commit on haddock, you need to know which commit of GHC to use to build it, but instead, the commits of GHC have a pointer to the haddock repo, rather than the other way around. I remember being surprised that the git submodule relationship wasn't at least in the opposite direction. I think it would make a fair amount of sense just to regard haddock as being a full-fledged part of GHC and perhaps just unify the repositories, since it's so intimately connected to GHC's internals anyway, but I might be unaware of other constraints on its development process. On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via ghc-steering-committee > wrote: > > Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; > but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee > > | On Behalf Of Richard Eisenberg > | Sent: 18 June 2020 22:29 > | To: ghc-steering-committee > > | Subject: [ghc-steering-committee] Haddock > | > | Hi committee, > | > | With a steady level of activity adding new features to GHC, I fear we may > | be forgetting one important downstream client: Haddock. For a nice > | example of how our decisions can cause trouble, see > | https://github.com/goldfirere/singletons/issues/466#issuecomment- > | 646117067. Despite appearing on the singletons bug tracker, that comment > | is all about Haddock support for https://github.com/ghc-proposals/ghc- > | proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- > | kind-signatures.rst, the -XStandaloneKindSignatures extension. > | > | This makes me wonder: should we invite a maintainer of Haddock to be an > | ex-officio (and voting) member of the committee? This would have two > | salutary effects: > | - It would force us to consider an important aspect of the user > | experience -- reading documentation -- of newly proposed features. > | - It would force us to give Haddock a heads-up about new features they > | may want to incorporate. > | > | If we don't think we need an ex-officio committee member, then perhaps we > | should instead require future proposals to describe a plausible impact on > | Haddock. I say "plausible impact" to suggest that the proposal text would > | not be binding on Haddock (which would be awfully dictatorial of us), but > | that it gives Haddock a starting place to consider their own design, > | while forcing proposers to think about this important-but-easily- > | neglected aspect of language evolution. > | > | What do we think? > | > | Richard > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravit111 at gmail.com Tue Jun 23 08:44:07 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Tue, 23 Jun 2020 11:44:07 +0300 Subject: [ghc-steering-committee] committee constitution In-Reply-To: References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> Message-ID: Hi, I have an issue regarding the proposed list of constituencies: GHC developer (2x) Educator Industry practitioner (2x) Haddock developer Researcher IDE tooling developer GHC fork developer (maybe) We have the following positions for developers working on something closely related to GHC: Haddock developer IDE tooling developer GHC fork developer (or GHC API client, as Simon suggests) What about cabal/stack? They both are closely related to GHC. No Backpack support in stack makes the former a bit esoteric *language* feature, for one example of such a relation. I don't think there is any difference between IDE tooling or cabal/stack developers regarding their membership in the Committee. Shouldn't we try to incorporate them either? What about another tooling? Linters, code formatters, independent parsers? Aren't there too many such developer categories? How are we (or who?) supposed to choose between them? In fact, I'd prefer temporary per proposal membership instead when a shepherd invites someone to discuss and decide on the particular proposal. Maybe we could have two or three unassigned "tooling developer" positions for such cases. Vitaly пн, 22 июн. 2020 г. в 15:34, Simon Peyton Jones via ghc-steering-committee : > > I agree with making a list of constituencies. We could also list which constituencies we think the current membership reflects. This gives a way for self-nominations to say “I fill a gap”. > > > > I’m not so keen on “GHC fork dev” and more keen on “GHC API client”, including plugins. That overlaps with IDE tooling, but is not subsumed by IDE. > > > > Yes the list should be on our main home page. > > > > Simon > > > > From: ghc-steering-committee On Behalf Of Richard Eisenberg > Sent: 22 June 2020 12:04 > To: Iavor Diatchki > Cc: ghc-steering-committee > Subject: [ghc-steering-committee] committee constitution > > > > Broadening from my thoughts on having a Haddock representative, I wonder if we should aim to have a "balanced" committee. I seem to recall (but can't find evidence of, after ~5 minutes of searching) that we started this steering committee with the aim of representing various different interests. We even had, somewhere, I believe, a list of different constituencies we wished to include. When we have considered this kind of diversity when selecting new members, we've also generally worked with whatever nominations we've received, instead of seeking out particular people. I'd like to propose that we reify a set of constituencies that we aim to always represent. When someone retires from the committee, we would then both seek nominations and think creatively about folks to invite from the constituency(ies) that are being left vacant by the retirement. > > > > Here is an initial proposed list of constituencies. If there is a "2x", it means we should have at least two steering committee members from that constituency. > > > > GHC developer (2x) > > Educator > > Industry practitioner (2x) > > Haddock developer > > Researcher > > IDE tooling developer > > GHC fork developer (maybe) > > > > On GHC port developer: there seem to be a growing number of GHC forks, and it might be nice to incorporate someone in that position into our committee. Examples: GHCJS, Asterius, DAML. > > > > One individual can fill multiple constituency needs, and overrepresentation is fine. > > > > So, I ask two separate questions: > > > > 1. Should we have such a list? > > > > 2. If yes, what do we think of this list, in particular? > > > > It would be great to hear from everyone on the committee on this point. If we answer "yes" to (1), I would expect us to add the list to https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments. > > > > Thanks, > > Richard > > > > On Jun 19, 2020, at 5:50 PM, Iavor Diatchki wrote: > > > > Hello, > > > > I think having a committee member who's involved with `haddock` makes sense, as `haddock` really is very tightly coupled with GHC. This, of course, presumes that Simon M is not actively involved with `haddock` anymore, otherwise we already have a representative. > > > > More generally, I think it is good if there is some overlap between various communities/organizations/projects, as it makes dissemination of information much smoother, and knowing what's happening in "the community", well, makes the community. > > > > I would recommend reaching out to Alec Theriault (`harpocrates` on git-hub). I've worked with him in the past and he is very smart and thoughtful. I have not spoken to him, so I am not sure if he'd be up for taking up the position, but if we do decide to invite Alec, I'd be happy to reach out and ask him. > > > > -Iavor > > > > > > On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote: > > In addition to this, it seems like the situation involving the > relationship between commits on haddock and commits on GHC is > currently somewhat unsatisfactory. In order to build an arbitrary > commit on haddock, you need to know which commit of GHC to use to > build it, but instead, the commits of GHC have a pointer to the > haddock repo, rather than the other way around. I remember being > surprised that the git submodule relationship wasn't at least in the > opposite direction. > > I think it would make a fair amount of sense just to regard haddock as > being a full-fledged part of GHC and perhaps just unify the > repositories, since it's so intimately connected to GHC's internals > anyway, but I might be unaware of other constraints on its development > process. > > > On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via > ghc-steering-committee wrote: > > > > Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; > > but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison. > > > > Simon > > > > | -----Original Message----- > > | From: ghc-steering-committee > > | On Behalf Of Richard Eisenberg > > | Sent: 18 June 2020 22:29 > > | To: ghc-steering-committee > > | Subject: [ghc-steering-committee] Haddock > > | > > | Hi committee, > > | > > | With a steady level of activity adding new features to GHC, I fear we may > > | be forgetting one important downstream client: Haddock. For a nice > > | example of how our decisions can cause trouble, see > > | https://github.com/goldfirere/singletons/issues/466#issuecomment- > > | 646117067. Despite appearing on the singletons bug tracker, that comment > > | is all about Haddock support for https://github.com/ghc-proposals/ghc- > > | proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- > > | kind-signatures.rst, the -XStandaloneKindSignatures extension. > > | > > | This makes me wonder: should we invite a maintainer of Haddock to be an > > | ex-officio (and voting) member of the committee? This would have two > > | salutary effects: > > | - It would force us to consider an important aspect of the user > > | experience -- reading documentation -- of newly proposed features. > > | - It would force us to give Haddock a heads-up about new features they > > | may want to incorporate. > > | > > | If we don't think we need an ex-officio committee member, then perhaps we > > | should instead require future proposals to describe a plausible impact on > > | Haddock. I say "plausible impact" to suggest that the proposal text would > > | not be binding on Haddock (which would be awfully dictatorial of us), but > > | that it gives Haddock a starting place to consider their own design, > > | while forcing proposers to think about this important-but-easily- > > | neglected aspect of language evolution. > > | > > | What do we think? > > | > > | Richard > > | _______________________________________________ > > | ghc-steering-committee mailing list > > | ghc-steering-committee at haskell.org > > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From bravit111 at gmail.com Tue Jun 23 09:14:37 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Tue, 23 Jun 2020 12:14:37 +0300 Subject: [ghc-steering-committee] Please review #292: ByteArray Literals, Shepherd: Vitaly In-Reply-To: References: Message-ID: Hi Joachim, This proposal boils down to adding several quasiquoters, available with the QuasiQuotes GHC extension. I don't think that this is in the scope of our Committee. I think that we should make this proposal dormant in case it turns out somehow different. At least now we have nothing to discuss, I believe. ========= ByteArray Literals has been proposed by Andrew Martin (based on a proposal by Oleg Grenus) https://github.com/ghc-proposals/ghc-proposals/pull/292 https://github.com/andrewthad/ghc-proposals/blob/bytearray-literals/proposals/0000-bytearray-literals.rst ========= Vitaly пн, 25 мая 2020 г. в 00:51, Joachim Breitner : > > Dear Committee, > > this is your secretary speaking: > > ByteArray Literals > has been proposed by Andrew Martin (based on a proposal by Oleg Grenus) > https://github.com/ghc-proposals/ghc-proposals/pull/292 > https://github.com/andrewthad/ghc-proposals/blob/bytearray-literals/proposals/0000-bytearray-literals.rst > > I propose Vitaly as the shepherd. > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > Thanks, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From trupill at gmail.com Tue Jun 23 13:45:54 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Tue, 23 Jun 2020 15:45:54 +0200 Subject: [ghc-steering-committee] committee constitution In-Reply-To: References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> Message-ID: I agree with Vitaly's point of having too many subcategories. We essentially need to ensure that proposals don't break the contract between GHC and all the tools, so it's great to have some people on that front, but I won't separate them too much. Alejandro El mar., 23 jun. 2020 a las 10:44, Vitaly Bragilevsky () escribió: > Hi, > > I have an issue regarding the proposed list of constituencies: > GHC developer (2x) > Educator > Industry practitioner (2x) > Haddock developer > Researcher > IDE tooling developer > GHC fork developer (maybe) > > We have the following positions for developers working on something > closely related to GHC: > Haddock developer > IDE tooling developer > GHC fork developer (or GHC API client, as Simon suggests) > > What about cabal/stack? They both are closely related to GHC. No > Backpack support in stack makes the former a bit esoteric *language* > feature, for one example of such a relation. I don't think there is > any difference between IDE tooling or cabal/stack developers regarding > their membership in the Committee. Shouldn't we try to incorporate > them either? What about another tooling? Linters, code formatters, > independent parsers? Aren't there too many such developer categories? > How are we (or who?) supposed to choose between them? > > In fact, I'd prefer temporary per proposal membership instead when a > shepherd invites someone to discuss and decide on the particular > proposal. Maybe we could have two or three unassigned "tooling > developer" positions for such cases. > > Vitaly > > пн, 22 июн. 2020 г. в 15:34, Simon Peyton Jones via > ghc-steering-committee : > > > > I agree with making a list of constituencies. We could also list which > constituencies we think the current membership reflects. This gives a way > for self-nominations to say “I fill a gap”. > > > > > > > > I’m not so keen on “GHC fork dev” and more keen on “GHC API client”, > including plugins. That overlaps with IDE tooling, but is not subsumed by > IDE. > > > > > > > > Yes the list should be on our main home page. > > > > > > > > Simon > > > > > > > > From: ghc-steering-committee > On Behalf Of Richard Eisenberg > > Sent: 22 June 2020 12:04 > > To: Iavor Diatchki > > Cc: ghc-steering-committee > > Subject: [ghc-steering-committee] committee constitution > > > > > > > > Broadening from my thoughts on having a Haddock representative, I wonder > if we should aim to have a "balanced" committee. I seem to recall (but > can't find evidence of, after ~5 minutes of searching) that we started this > steering committee with the aim of representing various different > interests. We even had, somewhere, I believe, a list of different > constituencies we wished to include. When we have considered this kind of > diversity when selecting new members, we've also generally worked with > whatever nominations we've received, instead of seeking out particular > people. I'd like to propose that we reify a set of constituencies that we > aim to always represent. When someone retires from the committee, we would > then both seek nominations and think creatively about folks to invite from > the constituency(ies) that are being left vacant by the retirement. > > > > > > > > Here is an initial proposed list of constituencies. If there is a "2x", > it means we should have at least two steering committee members from that > constituency. > > > > > > > > GHC developer (2x) > > > > Educator > > > > Industry practitioner (2x) > > > > Haddock developer > > > > Researcher > > > > IDE tooling developer > > > > GHC fork developer (maybe) > > > > > > > > On GHC port developer: there seem to be a growing number of GHC forks, > and it might be nice to incorporate someone in that position into our > committee. Examples: GHCJS, Asterius, DAML. > > > > > > > > One individual can fill multiple constituency needs, and > overrepresentation is fine. > > > > > > > > So, I ask two separate questions: > > > > > > > > 1. Should we have such a list? > > > > > > > > 2. If yes, what do we think of this list, in particular? > > > > > > > > It would be great to hear from everyone on the committee on this point. > If we answer "yes" to (1), I would expect us to add the list to > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and > consult it when making future committee appointments. > > > > > > > > Thanks, > > > > Richard > > > > > > > > On Jun 19, 2020, at 5:50 PM, Iavor Diatchki > wrote: > > > > > > > > Hello, > > > > > > > > I think having a committee member who's involved with `haddock` makes > sense, as `haddock` really is very tightly coupled with GHC. This, of > course, presumes that Simon M is not actively involved with `haddock` > anymore, otherwise we already have a representative. > > > > > > > > More generally, I think it is good if there is some overlap between > various communities/organizations/projects, as it makes dissemination of > information much smoother, and knowing what's happening in "the community", > well, makes the community. > > > > > > > > I would recommend reaching out to Alec Theriault (`harpocrates` on > git-hub). I've worked with him in the past and he is very smart and > thoughtful. I have not spoken to him, so I am not sure if he'd be up for > taking up the position, but if we do decide to invite Alec, I'd be happy to > reach out and ask him. > > > > > > > > -Iavor > > > > > > > > > > > > On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote: > > > > In addition to this, it seems like the situation involving the > > relationship between commits on haddock and commits on GHC is > > currently somewhat unsatisfactory. In order to build an arbitrary > > commit on haddock, you need to know which commit of GHC to use to > > build it, but instead, the commits of GHC have a pointer to the > > haddock repo, rather than the other way around. I remember being > > surprised that the git submodule relationship wasn't at least in the > > opposite direction. > > > > I think it would make a fair amount of sense just to regard haddock as > > being a full-fledged part of GHC and perhaps just unify the > > repositories, since it's so intimately connected to GHC's internals > > anyway, but I might be unaware of other constraints on its development > > process. > > > > > > On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via > > ghc-steering-committee wrote: > > > > > > Good thought. Personally, I'd be happy to have a Haddock maintainer on > the committee; > > > but I'd like them to be a full member, contributing to the discussion > and shepherding proposals -- not merely acting as the Haddock liaison. > > > > > > Simon > > > > > > | -----Original Message----- > > > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > > > | On Behalf Of Richard Eisenberg > > > | Sent: 18 June 2020 22:29 > > > | To: ghc-steering-committee > > > | Subject: [ghc-steering-committee] Haddock > > > | > > > | Hi committee, > > > | > > > | With a steady level of activity adding new features to GHC, I fear > we may > > > | be forgetting one important downstream client: Haddock. For a nice > > > | example of how our decisions can cause trouble, see > > > | https://github.com/goldfirere/singletons/issues/466#issuecomment- > > > | 646117067. Despite appearing on the singletons bug tracker, that > comment > > > | is all about Haddock support for > https://github.com/ghc-proposals/ghc- > > > | > proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- > > > | kind-signatures.rst, the -XStandaloneKindSignatures extension. > > > | > > > | This makes me wonder: should we invite a maintainer of Haddock to > be an > > > | ex-officio (and voting) member of the committee? This would have two > > > | salutary effects: > > > | - It would force us to consider an important aspect of the user > > > | experience -- reading documentation -- of newly proposed features. > > > | - It would force us to give Haddock a heads-up about new features > they > > > | may want to incorporate. > > > | > > > | If we don't think we need an ex-officio committee member, then > perhaps we > > > | should instead require future proposals to describe a plausible > impact on > > > | Haddock. I say "plausible impact" to suggest that the proposal text > would > > > | not be binding on Haddock (which would be awfully dictatorial of > us), but > > > | that it gives Haddock a starting place to consider their own design, > > > | while forcing proposers to think about this important-but-easily- > > > | neglected aspect of language evolution. > > > | > > > | What do we think? > > > | > > > | Richard > > > | _______________________________________________ > > > | ghc-steering-committee mailing list > > > | ghc-steering-committee at haskell.org > > > | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Jun 23 14:13:31 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 23 Jun 2020 15:13:31 +0100 Subject: [ghc-steering-committee] committee constitution In-Reply-To: <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> Message-ID: I was Feeling Lucky so I tried digging for the original list, and found it immediately! It was in private email so I won't paste the whole thing, but the list was | 1. GHC developer (e.g. someone named Simon, or similar) | 2. GHC maintainer (e.g. Austin or Ben) | 3. Author (e.g. Chris Allen, Alejandro Serrano Mena, etc) | 4. Teacher (someone who has recently or will soon teach Haskell in a | classroom setting) | 5-6. Industrial users | 7. Researcher (someone who uses the Haskell language as a research | vehicle) | 8-9. Members-at-large On Mon, 22 Jun 2020 at 12:04, Richard Eisenberg wrote: > Broadening from my thoughts on having a Haddock representative, I wonder > if we should aim to have a "balanced" committee. I seem to recall (but > can't find evidence of, after ~5 minutes of searching) that we started this > steering committee with the aim of representing various different > interests. We even had, somewhere, I believe, a list of different > constituencies we wished to include. When we have considered this kind of > diversity when selecting new members, we've also generally worked with > whatever nominations we've received, instead of seeking out particular > people. I'd like to propose that we reify a set of constituencies that we > aim to always represent. When someone retires from the committee, we would > then both seek nominations and think creatively about folks to invite from > the constituency(ies) that are being left vacant by the retirement. > > Here is an initial proposed list of constituencies. If there is a "2x", it > means we should have at least two steering committee members from that > constituency. > > GHC developer (2x) > Educator > Industry practitioner (2x) > Haddock developer > Researcher > IDE tooling developer > GHC fork developer (maybe) > I find Haddock developer a slightly odd choice. It's also a very small pool of people! Is the motivation due to the tight coupling? Alternatively we can try to ensure we're consulting stakeholders as appropriate, but we don't necessarily need representation on the committee. This also applies where changes touch core libraries too - we would want to consult with the core libraries committee to ensure alignment. Do we think that research is less important than industrial use? (this 2-1 ratio was also in the original list, but I don't recall if we discussed it). Cheers Simon On GHC port developer: there seem to be a growing number of GHC forks, and > it might be nice to incorporate someone in that position into our > committee. Examples: GHCJS, Asterius, DAML. > > One individual can fill multiple constituency needs, and > overrepresentation is fine. > > So, I ask two separate questions: > > 1. Should we have such a list? > > 2. If yes, what do we think of this list, in particular? > > It would be great to hear from everyone on the committee on this point. If > we answer "yes" to (1), I would expect us to add the list to > https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and > consult it when making future committee appointments. > > Thanks, > Richard > > On Jun 19, 2020, at 5:50 PM, Iavor Diatchki > wrote: > > Hello, > > I think having a committee member who's involved with `haddock` makes > sense, as `haddock` really is very tightly coupled with GHC. This, of > course, presumes that Simon M is not actively involved with `haddock` > anymore, otherwise we already have a representative. > > More generally, I think it is good if there is some overlap between > various communities/organizations/projects, as it makes dissemination of > information much smoother, and knowing what's happening in "the community", > well, makes the community. > > I would recommend reaching out to Alec Theriault (`harpocrates` on > git-hub). I've worked with him in the past and he is very smart and > thoughtful. I have not spoken to him, so I am not sure if he'd be up for > taking up the position, but if we do decide to invite Alec, I'd be happy to > reach out and ask him. > > -Iavor > > > On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote: > >> In addition to this, it seems like the situation involving the >> relationship between commits on haddock and commits on GHC is >> currently somewhat unsatisfactory. In order to build an arbitrary >> commit on haddock, you need to know which commit of GHC to use to >> build it, but instead, the commits of GHC have a pointer to the >> haddock repo, rather than the other way around. I remember being >> surprised that the git submodule relationship wasn't at least in the >> opposite direction. >> >> I think it would make a fair amount of sense just to regard haddock as >> being a full-fledged part of GHC and perhaps just unify the >> repositories, since it's so intimately connected to GHC's internals >> anyway, but I might be unaware of other constraints on its development >> process. >> >> >> On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via >> ghc-steering-committee wrote: >> > >> > Good thought. Personally, I'd be happy to have a Haddock maintainer on >> the committee; >> > but I'd like them to be a full member, contributing to the discussion >> and shepherding proposals -- not merely acting as the Haddock liaison. >> > >> > Simon >> > >> > | -----Original Message----- >> > | From: ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> >> > | On Behalf Of Richard Eisenberg >> > | Sent: 18 June 2020 22:29 >> > | To: ghc-steering-committee >> > | Subject: [ghc-steering-committee] Haddock >> > | >> > | Hi committee, >> > | >> > | With a steady level of activity adding new features to GHC, I fear >> we may >> > | be forgetting one important downstream client: Haddock. For a nice >> > | example of how our decisions can cause trouble, see >> > | https://github.com/goldfirere/singletons/issues/466#issuecomment- >> > | 646117067. Despite appearing on the singletons bug tracker, that >> comment >> > | is all about Haddock support for >> https://github.com/ghc-proposals/ghc- >> > | >> proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- >> > | kind-signatures.rst, the -XStandaloneKindSignatures extension. >> > | >> > | This makes me wonder: should we invite a maintainer of Haddock to be >> an >> > | ex-officio (and voting) member of the committee? This would have two >> > | salutary effects: >> > | - It would force us to consider an important aspect of the user >> > | experience -- reading documentation -- of newly proposed features. >> > | - It would force us to give Haddock a heads-up about new features >> they >> > | may want to incorporate. >> > | >> > | If we don't think we need an ex-officio committee member, then >> perhaps we >> > | should instead require future proposals to describe a plausible >> impact on >> > | Haddock. I say "plausible impact" to suggest that the proposal text >> would >> > | not be binding on Haddock (which would be awfully dictatorial of >> us), but >> > | that it gives Haddock a starting place to consider their own design, >> > | while forcing proposers to think about this important-but-easily- >> > | neglected aspect of language evolution. >> > | >> > | What do we think? >> > | >> > | Richard >> > | _______________________________________________ >> > | ghc-steering-committee mailing list >> > | ghc-steering-committee at haskell.org >> > | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Jun 23 15:37:54 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 23 Jun 2020 17:37:54 +0200 Subject: [ghc-steering-committee] Please review #292: ByteArray Literals, Shepherd: Vitaly In-Reply-To: References: Message-ID: Hi, Am Dienstag, den 23.06.2020, 12:14 +0300 schrieb Vitaly Bragilevsky: > This proposal boils down to adding several quasiquoters, available > with the QuasiQuotes GHC extension. I don't think that this is in the > scope of our Committee. I think that we should make this proposal > dormant in case it turns out somehow different. At least now we have > nothing to discuss, I believe. > > ========= > ByteArray Literals > has been proposed by Andrew Martin (based on a proposal by Oleg Grenus) > https://github.com/ghc-proposals/ghc-proposals/pull/292 > https://github.com/andrewthad/ghc-proposals/blob/bytearray-literals/proposals/0000-bytearray-literals.rst > ========= if that’s the case, then yes, we could mark it as “non-proposal” and invite the authors to take this onto the GHC bug tracker. Could someone with more expertise on Template Haskell etc. have a brief look and discern if this is proposal material or not? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Wed Jun 24 10:23:24 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 24 Jun 2020 11:23:24 +0100 Subject: [ghc-steering-committee] Please review #292: ByteArray Literals, Shepherd: Vitaly In-Reply-To: References: Message-ID: <852ADDC2-7C4B-4507-96A3-DAB08B2F6875@richarde.dev> I think it's borderline. I think the user-facing behavior could be put together without a proposal, but it would not be performant enough. So the part that might need a proposal is any change to core. Yet the proposal does not really make that point clear. I've posted on the GitHub thread. Richard > On Jun 23, 2020, at 4:37 PM, Joachim Breitner wrote: > > Hi, > > Am Dienstag, den 23.06.2020, 12:14 +0300 schrieb Vitaly Bragilevsky: >> This proposal boils down to adding several quasiquoters, available >> with the QuasiQuotes GHC extension. I don't think that this is in the >> scope of our Committee. I think that we should make this proposal >> dormant in case it turns out somehow different. At least now we have >> nothing to discuss, I believe. >> >> ========= >> ByteArray Literals >> has been proposed by Andrew Martin (based on a proposal by Oleg Grenus) >> https://github.com/ghc-proposals/ghc-proposals/pull/292 >> https://github.com/andrewthad/ghc-proposals/blob/bytearray-literals/proposals/0000-bytearray-literals.rst >> ========= > > if that’s the case, then yes, we could mark it as “non-proposal” and > invite the authors to take this onto the GHC bug tracker. > > Could someone with more expertise on Template Haskell etc. have a brief > look and discern if this is proposal material or not? > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at richarde.dev Wed Jun 24 10:57:54 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 24 Jun 2020 11:57:54 +0100 Subject: [ghc-steering-committee] committee constitution In-Reply-To: References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> Message-ID: <2A18F347-EE12-4423-B766-3857EBBA4E86@richarde.dev> An interesting viewpoint arose in this thread that I'd like to highlight: instead of representing all these interests on the committee, we could have shepherds consider external reviewers, who are invited to review individual proposals. Beyond that, there have been ideas shared about what, precisely, the list should be. I want to defer that discussion until we agree that we should even have a list. So I pose a question: How should we ensure that various constituencies are well served by our process? A. By having shepherds reach out to community members external to the committee who can share their expert opinion B. By maintaining a list of constituencies that the committee membership covers (ideally) These can be combined, or we could do neither. (Right now, we do neither.) Please respond answering whether you'd prefer A alone, B alone, A + B, or neither. I prefer B alone. I think A is fine, but it should be hopefully rare enough that we don't need to bake it into our process. And I'd prefer to have the constituencies represented in such a way that the representative sees a range of proposals, not just a few that narrowly affect some group of people. If we decide to include B in the end, I'll create a Google Doc where we can collaboratively compose the list. Thanks, Richard > On Jun 23, 2020, at 3:13 PM, Simon Marlow wrote: > > I was Feeling Lucky so I tried digging for the original list, and found it immediately! It was in private email so I won't paste the whole thing, but the list was > > | 1. GHC developer (e.g. someone named Simon, or similar) > | 2. GHC maintainer (e.g. Austin or Ben) > | 3. Author (e.g. Chris Allen, Alejandro Serrano Mena, etc) > | 4. Teacher (someone who has recently or will soon teach Haskell in a > | classroom setting) > | 5-6. Industrial users > | 7. Researcher (someone who uses the Haskell language as a research > | vehicle) > | 8-9. Members-at-large > > > On Mon, 22 Jun 2020 at 12:04, Richard Eisenberg > wrote: > Broadening from my thoughts on having a Haddock representative, I wonder if we should aim to have a "balanced" committee. I seem to recall (but can't find evidence of, after ~5 minutes of searching) that we started this steering committee with the aim of representing various different interests. We even had, somewhere, I believe, a list of different constituencies we wished to include. When we have considered this kind of diversity when selecting new members, we've also generally worked with whatever nominations we've received, instead of seeking out particular people. I'd like to propose that we reify a set of constituencies that we aim to always represent. When someone retires from the committee, we would then both seek nominations and think creatively about folks to invite from the constituency(ies) that are being left vacant by the retirement. > > Here is an initial proposed list of constituencies. If there is a "2x", it means we should have at least two steering committee members from that constituency. > > GHC developer (2x) > Educator > Industry practitioner (2x) > Haddock developer > Researcher > IDE tooling developer > GHC fork developer (maybe) > > I find Haddock developer a slightly odd choice. It's also a very small pool of people! Is the motivation due to the tight coupling? Alternatively we can try to ensure we're consulting stakeholders as appropriate, but we don't necessarily need representation on the committee. This also applies where changes touch core libraries too - we would want to consult with the core libraries committee to ensure alignment. > > Do we think that research is less important than industrial use? (this 2-1 ratio was also in the original list, but I don't recall if we discussed it). > > Cheers > Simon > > On GHC port developer: there seem to be a growing number of GHC forks, and it might be nice to incorporate someone in that position into our committee. Examples: GHCJS, Asterius, DAML. > > One individual can fill multiple constituency needs, and overrepresentation is fine. > > So, I ask two separate questions: > > 1. Should we have such a list? > > 2. If yes, what do we think of this list, in particular? > > It would be great to hear from everyone on the committee on this point. If we answer "yes" to (1), I would expect us to add the list to https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments. > > Thanks, > Richard > >> On Jun 19, 2020, at 5:50 PM, Iavor Diatchki > wrote: >> >> Hello, >> >> I think having a committee member who's involved with `haddock` makes sense, as `haddock` really is very tightly coupled with GHC. This, of course, presumes that Simon M is not actively involved with `haddock` anymore, otherwise we already have a representative. >> >> More generally, I think it is good if there is some overlap between various communities/organizations/projects, as it makes dissemination of information much smoother, and knowing what's happening in "the community", well, makes the community. >> >> I would recommend reaching out to Alec Theriault (`harpocrates` on git-hub). I've worked with him in the past and he is very smart and thoughtful. I have not spoken to him, so I am not sure if he'd be up for taking up the position, but if we do decide to invite Alec, I'd be happy to reach out and ask him. >> >> -Iavor >> >> >> On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard > wrote: >> In addition to this, it seems like the situation involving the >> relationship between commits on haddock and commits on GHC is >> currently somewhat unsatisfactory. In order to build an arbitrary >> commit on haddock, you need to know which commit of GHC to use to >> build it, but instead, the commits of GHC have a pointer to the >> haddock repo, rather than the other way around. I remember being >> surprised that the git submodule relationship wasn't at least in the >> opposite direction. >> >> I think it would make a fair amount of sense just to regard haddock as >> being a full-fledged part of GHC and perhaps just unify the >> repositories, since it's so intimately connected to GHC's internals >> anyway, but I might be unaware of other constraints on its development >> process. >> >> >> On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via >> ghc-steering-committee > wrote: >> > >> > Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; >> > but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison. >> > >> > Simon >> > >> > | -----Original Message----- >> > | From: ghc-steering-committee > >> > | On Behalf Of Richard Eisenberg >> > | Sent: 18 June 2020 22:29 >> > | To: ghc-steering-committee > >> > | Subject: [ghc-steering-committee] Haddock >> > | >> > | Hi committee, >> > | >> > | With a steady level of activity adding new features to GHC, I fear we may >> > | be forgetting one important downstream client: Haddock. For a nice >> > | example of how our decisions can cause trouble, see >> > | https://github.com/goldfirere/singletons/issues/466#issuecomment- >> > | 646117067. Despite appearing on the singletons bug tracker, that comment >> > | is all about Haddock support for https://github.com/ghc-proposals/ghc- >> > | proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- >> > | kind-signatures.rst, the -XStandaloneKindSignatures extension. >> > | >> > | This makes me wonder: should we invite a maintainer of Haddock to be an >> > | ex-officio (and voting) member of the committee? This would have two >> > | salutary effects: >> > | - It would force us to consider an important aspect of the user >> > | experience -- reading documentation -- of newly proposed features. >> > | - It would force us to give Haddock a heads-up about new features they >> > | may want to incorporate. >> > | >> > | If we don't think we need an ex-officio committee member, then perhaps we >> > | should instead require future proposals to describe a plausible impact on >> > | Haddock. I say "plausible impact" to suggest that the proposal text would >> > | not be binding on Haddock (which would be awfully dictatorial of us), but >> > | that it gives Haddock a starting place to consider their own design, >> > | while forcing proposers to think about this important-but-easily- >> > | neglected aspect of language evolution. >> > | >> > | What do we think? >> > | >> > | Richard >> > | _______________________________________________ >> > | ghc-steering-committee mailing list >> > | ghc-steering-committee at haskell.org >> > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravit111 at gmail.com Wed Jun 24 11:40:44 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Wed, 24 Jun 2020 14:40:44 +0300 Subject: [ghc-steering-committee] committee constitution In-Reply-To: <2A18F347-EE12-4423-B766-3857EBBA4E86@richarde.dev> References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> <2A18F347-EE12-4423-B766-3857EBBA4E86@richarde.dev> Message-ID: I prefer A+B because I think it's too hard to come up with a reasonable list including all the categories. Though having such a list with bigger categories is definitely helpful. Vitaly ср, 24 июн. 2020 г. в 13:58, Richard Eisenberg : > An interesting viewpoint arose in this thread that I'd like to highlight: > instead of representing all these interests on the committee, we could have > shepherds consider external reviewers, who are invited to review individual > proposals. Beyond that, there have been ideas shared about what, precisely, > the list should be. I want to defer that discussion until we agree that we > should even have a list. So I pose a question: > > How should we ensure that various constituencies are well served by our > process? > > A. By having shepherds reach out to community members external to the > committee who can share their expert opinion > B. By maintaining a list of constituencies that the committee membership > covers (ideally) > > These can be combined, or we could do neither. (Right now, we do neither.) > Please respond answering whether you'd prefer A alone, B alone, A + B, or > neither. > > I prefer B alone. I think A is fine, but it should be hopefully rare > enough that we don't need to bake it into our process. And I'd prefer to > have the constituencies represented in such a way that the representative > sees a range of proposals, not just a few that narrowly affect some group > of people. > > If we decide to include B in the end, I'll create a Google Doc where we > can collaboratively compose the list. > > Thanks, > Richard > > On Jun 23, 2020, at 3:13 PM, Simon Marlow wrote: > > I was Feeling Lucky so I tried digging for the original list, and found it > immediately! It was in private email so I won't paste the whole thing, but > the list was > > | 1. GHC developer (e.g. someone named Simon, or similar) > | 2. GHC maintainer (e.g. Austin or Ben) > | 3. Author (e.g. Chris Allen, Alejandro Serrano Mena, etc) > | 4. Teacher (someone who has recently or will soon teach Haskell in a > | classroom setting) > | 5-6. Industrial users > | 7. Researcher (someone who uses the Haskell language as a research > | vehicle) > | 8-9. Members-at-large > > > On Mon, 22 Jun 2020 at 12:04, Richard Eisenberg wrote: > >> Broadening from my thoughts on having a Haddock representative, I wonder >> if we should aim to have a "balanced" committee. I seem to recall (but >> can't find evidence of, after ~5 minutes of searching) that we started this >> steering committee with the aim of representing various different >> interests. We even had, somewhere, I believe, a list of different >> constituencies we wished to include. When we have considered this kind of >> diversity when selecting new members, we've also generally worked with >> whatever nominations we've received, instead of seeking out particular >> people. I'd like to propose that we reify a set of constituencies that we >> aim to always represent. When someone retires from the committee, we would >> then both seek nominations and think creatively about folks to invite from >> the constituency(ies) that are being left vacant by the retirement. >> >> Here is an initial proposed list of constituencies. If there is a "2x", >> it means we should have at least two steering committee members from that >> constituency. >> >> GHC developer (2x) >> Educator >> Industry practitioner (2x) >> Haddock developer >> Researcher >> IDE tooling developer >> GHC fork developer (maybe) >> > > I find Haddock developer a slightly odd choice. It's also a very small > pool of people! Is the motivation due to the tight coupling? Alternatively > we can try to ensure we're consulting stakeholders as appropriate, but we > don't necessarily need representation on the committee. This also applies > where changes touch core libraries too - we would want to consult with the > core libraries committee to ensure alignment. > > Do we think that research is less important than industrial use? (this 2-1 > ratio was also in the original list, but I don't recall if we discussed it). > > Cheers > Simon > > On GHC port developer: there seem to be a growing number of GHC forks, and >> it might be nice to incorporate someone in that position into our >> committee. Examples: GHCJS, Asterius, DAML. >> >> One individual can fill multiple constituency needs, and >> overrepresentation is fine. >> >> So, I ask two separate questions: >> >> 1. Should we have such a list? >> >> 2. If yes, what do we think of this list, in particular? >> >> It would be great to hear from everyone on the committee on this point. >> If we answer "yes" to (1), I would expect us to add the list to >> https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and >> consult it when making future committee appointments. >> >> Thanks, >> Richard >> >> On Jun 19, 2020, at 5:50 PM, Iavor Diatchki >> wrote: >> >> Hello, >> >> I think having a committee member who's involved with `haddock` makes >> sense, as `haddock` really is very tightly coupled with GHC. This, of >> course, presumes that Simon M is not actively involved with `haddock` >> anymore, otherwise we already have a representative. >> >> More generally, I think it is good if there is some overlap between >> various communities/organizations/projects, as it makes dissemination of >> information much smoother, and knowing what's happening in "the community", >> well, makes the community. >> >> I would recommend reaching out to Alec Theriault (`harpocrates` on >> git-hub). I've worked with him in the past and he is very smart and >> thoughtful. I have not spoken to him, so I am not sure if he'd be up for >> taking up the position, but if we do decide to invite Alec, I'd be happy to >> reach out and ask him. >> >> -Iavor >> >> >> On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote: >> >>> In addition to this, it seems like the situation involving the >>> relationship between commits on haddock and commits on GHC is >>> currently somewhat unsatisfactory. In order to build an arbitrary >>> commit on haddock, you need to know which commit of GHC to use to >>> build it, but instead, the commits of GHC have a pointer to the >>> haddock repo, rather than the other way around. I remember being >>> surprised that the git submodule relationship wasn't at least in the >>> opposite direction. >>> >>> I think it would make a fair amount of sense just to regard haddock as >>> being a full-fledged part of GHC and perhaps just unify the >>> repositories, since it's so intimately connected to GHC's internals >>> anyway, but I might be unaware of other constraints on its development >>> process. >>> >>> >>> On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via >>> ghc-steering-committee wrote: >>> > >>> > Good thought. Personally, I'd be happy to have a Haddock maintainer on >>> the committee; >>> > but I'd like them to be a full member, contributing to the discussion >>> and shepherding proposals -- not merely acting as the Haddock liaison. >>> > >>> > Simon >>> > >>> > | -----Original Message----- >>> > | From: ghc-steering-committee < >>> ghc-steering-committee-bounces at haskell.org> >>> > | On Behalf Of Richard Eisenberg >>> > | Sent: 18 June 2020 22:29 >>> > | To: ghc-steering-committee >>> > | Subject: [ghc-steering-committee] Haddock >>> > | >>> > | Hi committee, >>> > | >>> > | With a steady level of activity adding new features to GHC, I fear >>> we may >>> > | be forgetting one important downstream client: Haddock. For a nice >>> > | example of how our decisions can cause trouble, see >>> > | https://github.com/goldfirere/singletons/issues/466#issuecomment- >>> > | 646117067. Despite appearing on the singletons bug tracker, that >>> comment >>> > | is all about Haddock support for >>> https://github.com/ghc-proposals/ghc- >>> > | >>> proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- >>> > | kind-signatures.rst, the -XStandaloneKindSignatures extension. >>> > | >>> > | This makes me wonder: should we invite a maintainer of Haddock to >>> be an >>> > | ex-officio (and voting) member of the committee? This would have two >>> > | salutary effects: >>> > | - It would force us to consider an important aspect of the user >>> > | experience -- reading documentation -- of newly proposed features. >>> > | - It would force us to give Haddock a heads-up about new features >>> they >>> > | may want to incorporate. >>> > | >>> > | If we don't think we need an ex-officio committee member, then >>> perhaps we >>> > | should instead require future proposals to describe a plausible >>> impact on >>> > | Haddock. I say "plausible impact" to suggest that the proposal text >>> would >>> > | not be binding on Haddock (which would be awfully dictatorial of >>> us), but >>> > | that it gives Haddock a starting place to consider their own design, >>> > | while forcing proposers to think about this important-but-easily- >>> > | neglected aspect of language evolution. >>> > | >>> > | What do we think? >>> > | >>> > | Richard >>> > | _______________________________________________ >>> > | ghc-steering-committee mailing list >>> > | ghc-steering-committee at haskell.org >>> > | >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> > _______________________________________________ >>> > ghc-steering-committee mailing list >>> > ghc-steering-committee at haskell.org >>> > >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Jun 24 11:57:49 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 24 Jun 2020 13:57:49 +0200 Subject: [ghc-steering-committee] committee constitution In-Reply-To: <2A18F347-EE12-4423-B766-3857EBBA4E86@richarde.dev> References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> <2A18F347-EE12-4423-B766-3857EBBA4E86@richarde.dev> Message-ID: Hi, Am Mittwoch, den 24.06.2020, 11:57 +0100 schrieb Richard Eisenberg: > A. By having shepherds reach out to community members external to the committee who can share their expert opinion > B. By maintaining a list of constituencies that the committee membership covers (ideally) > > These can be combined, or we could do neither. (Right now, we do neither.) I think we have sometimes used A. For example with the proposal about Arrow something, we (or the author?) reached out the likely affected library authors. I am slightly favoring A (less formal, less process overhead, maybe more flexible). Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Wed Jun 24 14:12:59 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 24 Jun 2020 07:12:59 -0700 Subject: [ghc-steering-committee] committee constitution In-Reply-To: References: <91892A59-2435-47EC-96AF-CAA98A3CA7A7@richarde.dev> <9B4EE629-6BB4-41EE-82C6-2FCB89F1F43A@richarde.dev> <2A18F347-EE12-4423-B766-3857EBBA4E86@richarde.dev> Message-ID: I am not really keen on putting these labels on folks, so my preference would be to not bake this into the process. I am also not sure what problem we are solving though. Iavor On Wed, Jun 24, 2020, 04:58 Joachim Breitner wrote: > Hi, > > Am Mittwoch, den 24.06.2020, 11:57 +0100 schrieb Richard Eisenberg: > > A. By having shepherds reach out to community members external to the > committee who can share their expert opinion > > B. By maintaining a list of constituencies that the committee > membership covers (ideally) > > > > These can be combined, or we could do neither. (Right now, we do > neither.) > > I think we have sometimes used A. For example with the proposal about > Arrow something, we (or the author?) reached out the likely affected > library authors. > > I am slightly favoring A (less formal, less process overhead, maybe > more flexible). > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: