[ghc-steering-committee] #380 GHC2021: Forth status update / kialo.com
Richard Eisenberg
rae at richarde.dev
Tue Dec 15 21:44:02 UTC 2020
I just tried Kialo, and couldn't warm to it -- despite being excited to try.
+ I really like its way of encouraging individual pros and cons, and how these are kept short and independent.
- I can't get *any* forest, only lots and lots of trees. Kialo forces focus on only one thing at a time, but I found myself constantly losing any picture of where I was or where I was going.
- There seems to be no visual indication (to me) of when a node has sub-nodes. For example, if I read a "con" that itself has 5 "cons" underneath, I wouldn't know unless I click on it.
- I think I stumbled into a con of a con of a con. See "I found myself constantly losing any picture of where I was", above.
- There doesn't seem to be a way to agree with an argument, without adding a distinct "pro". This means that if a post is liked by 8 of us and disliked (for different reasons) by 3, there would be 3 cons against it, no pros, and a misrepresentation of our communal opinion.
In its current form, Kialo seems best as a way to organize pros and cons, but to actually have debate elsewhere. If someone out there knows how to mitigate the cons above, I'd be interested.
If Kialo becomes the place where the action is, I'll participate, but I would hope there's a better way. (Not that email threads are necessarily better!)
Richard
> On Dec 15, 2020, at 3:27 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> On Tue, 15 Dec 2020 at 13:00, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> My point is that NamedWildcards is a souped up version of PartialTypeSignatures
>
>
>
> f :: _ -> _
>
> g :: _a -> _a
>
>
>
> The former is a partial type signature. So is the latter! The former is equivalent to f :: _a -> _b.
>
>
>
> Now, I’ve just discovered that
>
> Wildcards in types work *regardless* of flag. Thus you can use the above signature for f with no flag at all, and get a message like this:
> Foo.hs:5:6: error:
>
> • Found type wildcard ‘_’ standing for ‘[a]’
>
> Where: ‘a’ is a rigid type variable bound by
>
> the inferred type of f :: [a] -> [a]
>
> at Foo.hs:6:1-12
>
> To use the inferred type, enable PartialTypeSignatures
>
> So the only effect of PartialTypeSignatures is to turn that error into a warning. I had not appreciated that.
>
>
>
> As you say, NamedWildCards treats _a as a wildcard rather than a variable. Fine.
>
>
> Given the above, I still think it’s bizarre not to allow PartialTypeSignatures. All the complexity is there already; it’s only a question of turning the error into a warning
>
> It would be slightly strange to have a language feature that is enabled by default but generates a warning every time you use it. I'd rather the warning was disabled by default, but I agree that PartialTypeSignatures should be on.
>
> If I recall correctly, it was Richard who argued for NamedWildCards without PartialTypeSignatures (or independently of it), somewhere deep in one of these email threads :)
>
> Cheers
> Simon
>
>
>
>
>
> Simon
>
>
>
> From: Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>>
> Sent: 15 December 2020 12:48
> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Cc: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>; ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] #380 GHC2021: Forth status update / kialo.com <http://kialo.com/>
>
>
>
>
> On 15 Dec 2020 at 13:18:20, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
>
> Writing down the summary here
> https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977856035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nwXI1KIFwaFAf8WrdnXBF7MoNIhq2tTt0KIL0LVBCx8%3D&reserved=0>
>
> allows me to ask:
>
> * It can't be sensible to propose NamedWildCards (8 votes) without ParitalTypeSignatures (2 votes), can it?
>
>
>
> As far as I understand it, they have different purposes:
>
>
>
> - NamedWildCards instructs GHC to treat names starting with underscore as unknown variables when unifying. So for example, the following would not work, since _a would need to be Char and Bool at the same time.
>
>
>
> > f :: _a -> _a
>
> > f ‘x’ = True
>
>
>
> If you do not enable NamedWildCards, names starting with an underscore are taken to be regular variables. So the type ‘_a -> _a’ is completely equivalent to ‘a -> a’.
>
>
>
> - PartialTypeSignatures is about *accepting* those signatures by the compiler. If you don’t have this on, a partial type signature gives you an error with the inferred type, but does not continue compiling your program.
>
>
>
> Personally, I think this is the right behaviour: do not accept partial signatures unless explicitly told so.
>
>
>
>
> Simon
>
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-
> | bounces at haskell.org <mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner
> | Sent: 14 December 2020 22:23
> | To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> | Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
> | kialo.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EHZIchQsOdwrT6p5MuQUoWONZvUr8x35ACzUXFZk1HA%3D&reserved=0>
> |
> | Dear Committe,
> |
> | three weeks in, we have all votes. So now things are looking more
> | concrete.
> |
> | As always, the table
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith>
> | ub.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fub.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zmCppIBCXjqoVaZaXY1FWcKBcBBP8Pwni1jn7hkpBcU%3D&reserved=0>%2Fghc-proposals%2Fghc-
> | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-
> | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977876027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yWWXXXYhlgsc6DkoQ2pl%2Fg3W3FKR6wrlSN70mYDCoWE%3D&reserved=0>%7C10d0e7
> | 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> | 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B
> | XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0
> | has the current data.
> |
> | Would it be helpful to add columns to that table for each committee
> | member? So that you can quickly see who voted what?
> |
> | The following in are safely in (= need more than one vote to change to
> | get out):
> |
> | BangPatterns, BinaryLiterals, ConstrainedClassMethods,
> | ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor,
> | DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase,
> | EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts,
> | FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving,
> | HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures,
> | MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds,
> | PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType,
> | TypeApplications, TypeSynonymInstances
> |
> | The following are barely in (exactly 8 votes in favor, and 3 against):
> |
> | ExistentialQuantification, NamedWildCards, StandaloneKindSignatures,
> | TypeOperators
> |
> | The following are short one vote (7 in favor, 4 against):
> |
> | DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds,
> | NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections,
> | TypeFamilies
> |
> |
> | I am sure we can have plenty of discussion for each of these. Probably
> | without end. As Simon says, mailing lists don't scale. So I think we
> | have two choices:
> |
> | 1. Let the numbers decide, and accept whatever comes out. According to
> | the process (which we should only follow if we find it helpful) we'd
> | maybe update our votes, and maybe point out new facets, for one week,
> | and then just take whatever has 8 votes.
> |
> | or
> |
> | 2. Explore a more efficient discussion format.
> |
> | For the latter I mentioned kialo.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0> before, and maybe it is worth a
> | try, so I set up a discussion there:
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>.
> | kialo.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0>%2Fwhich-haskell-extensions-should-go-into-ghc2021-
> | 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gNhldU3ky0zZjdTamtkGkcXkYnij%2FnZfXZP%2FVA7pBh4%3D&reserved=0>%7C10
> | d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> | 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK
> | Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0
> |
> | So what do you see there?
> |
> | There is a discussion tree:
> |
> | The root is "what goes in GHC2021"
> |
> | The next layer are all extensions with 7 or 8 votes.
> | (I assume we should focus on those initially, but feel free to add
> | more or ask me to.) For example: TupleSections
> |
> | And then each of these has a column where we can collect Pros and
> | cons.
> | For example:
> | Pro: Opt-in Syntax
> | Con: Possible clash with extra-comma syntax extensions.
> |
> | So you can treat it like a wiki, but with structure to organize the
> | discussion.
> |
> | In fact, each pro and con is itself a node where you can add
> | supporting and disagreeing comments. This means that if you _disagree_
> | that TupleSections are actually Opt-in syntax, there is a dedicated
> | place to raise that point, rather than putting "Not actually opt-in"
> | in the Con column of TupleSections...
> |
> | A good way to navigate the discussion seems to be the radial icon in
> | the top left; it opens a radial view of the whole discussion, and you
> | can read arguments by hovering.
> |
> |
> | The site doesn't offer voting, it is only about structuring the
> | discussion, and it is designed for much larger and much more
> | contentious debates (e.g. "Brexit"). So we'll see how well it works
> | for us and if it's helpful.
> |
> | Cheers,
> | Joachim
> |
> |
> | --
> | Joachim Breitner
> | mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> |
> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j>
> | oachim-
> | breitner.de <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gDY7g2ZbZUXmBOcZ965QbDXx%2FyqV0QTzLy28JY6PnTI%3D&reserved=0>%2F&data=04%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977906015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=um%2Ba0XdBybuyBixCbfruJUGQRyHy%2BBaXDGbgFWIAu2k%3D&reserved=0>%7C10d0e709a1
> | dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> | 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr
> | DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0
> |
> |
> | _______________________________________________
> | ghc-steering-committee mailing list
> | ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail>
> | .haskell.org <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iiZXGZCSRr4RgU0zb3UtblBFxJYUeM%2B8JBZ6goNbQsY%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | committee&data=04%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o9BSWTudDLBqHILOY4c52gYrO7col9hS5OcJ6JTDT1k%3D&reserved=0>%7C10d0e709a1dd452
> | 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358
> | 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF
> | vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977926004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iS6WeND3u5ArOZHO2KRvfEe1gV9%2BySwH%2BaeJbZQtMhg%3D&reserved=0>_______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/ce78bbe2/attachment-0001.html>
More information about the ghc-steering-committee
mailing list