Below are the minutes from last week’s in-person meeting at ICFP among the attending members of the Haskell Prime committee. The conversation moved swiftly, and I’ve done my best at capturing the essence of attendees’ comments. The attendees have had a week to consider these notes with no suggestions submitted; I thus consider these notes ratified. Richard ---------- Sep 19, 2016, 12:43pm JST, call to order. Present: José Trilla, Iavor Diatchki, Wren Romano, Richard Eisenberg, Simon Peyton Jones, Andres Löh, Nicolas Wu, Lennart Augustsson Convener: José Notetaker: Richard José: Let's talk about one issue and figure that one issue out. Need to maintain / start momentum. José and Iavor wrote notes about possible topics to discuss. Iavor: How do we get the process going? Want to discuss: What's in scope? What's the process for proposal? Do we need an implementation first? But that's a lot of (potentially wasted) work. Wren: We should coordinate before starting on a project to avoid duplicate effort. Simon: But that's not our problem. We need *more* people working on things. Simon: There's so much that's implemented but not formalized that we shouldn't worry about things that aren't implemented. Iavor: Not much that's uncontroversial. Iavor: Suggested uncontroversial things: TupleSections Lennart: I use TupleSections. Yes. Simon: TupleSections is too easy. What about MPTC? Wren: I'm mildly against TupleSections. Too easy to make type errors due to errant commas. Andres: TupleSections conflict with trailing commas. Some people really like trailing commas. Not overly eager for TupleSections. Prefer not to have all these syntactic special cases; favor simplicity. Iavor, Wren: They are perhaps too simple to test the process. Nick: Finish the list. We'll be quiet. Iavor: Second item: RecordWildCards, RecordPuns. I like them. Some people don't. Lennart: RecordPuns have been removed. Simon: No. They're still there. Lennart: No. I mean that they were in the standard but were removed. But now people want them back. Lennart: RecordWildCards introduce bound names with no binding site. Richard: I've been confused by this. Iavor: If you don't like these features, you don't have to use them. Simon: Haskell has always supported more than one way to do things. Like ArgumentDo. Seems overblown, but many people want them. Iavor: GADTSyntax. All: Yes. Iavor: Do we do records in GADT notation? Simon: Yes. Iavor: But the typing rules of record selectors is hard in GADTs. Simon: Yes. Richard: But that's not part of GADTSyntax. Andres: Will this include existentials? Richard: Existentials aren't much fun without the ability to pack instance dictionaries. And then we run into incoherence. I vote no. Iavor: KindSignatures. Lennart: Then we'll need a name for *. Iavor: EqualityConstraints. They can be useful in a superclass constraint. Simon: This is a sensible extension. Richard: I think EqualityConstraints will be hard to specify. Andres: Maybe if we've gotten to a lot of other things. Lennart: We'll need to have an implementation EqualityConstraints and see if it works. Iavor: MPTC. Simon: We've had them for a long time. Andres, Lennart: They're quite useful. Iavor: FlexibleInstances & FlexibleContexts Andres, Richard, Wren: These can have some weird coherence problems. Simon: If you have (Eq [a] => ...) and there is a top-level instance, now you have multiple ways potentially to solve a constraint. Andres, Simon: It's a kind of OverlappingInstances thing. Iavor: Strictly OverlappingInstances. We should have a keyword not a pragma. Restricted only to instances that overlap ones in the same module. Lennart: It should be something like instance chains, really. Iavor: GHC already orders overlapping instances. Simon: Some people use an orphan instance in a library. Iavor: That's generally wrong and hard to use correctly. Andres: Hard to have guarantees of what will happen in practice. Andres: Perhaps we should just have closed type classes. Iavor: BangPatterns. On the argument. And only on variables. Simon: It's nice on let bindings. Iavor: But that should have a different notation. Wren: The semantics are challenging on a where. José: Yes. But on a let it's ok. Simon: The Report has a description of pattern bindings in terms of rewriting to a simpler notation. It's all quite simple. Iavor: It's not how it works at the top level. Lennart: A bang on a top-level binding could happen when the program starts to run. Simon: Plausible. José: Bangs in datatype declarations leads to a `seq` only when the datatype is fully saturated. Simon: That's odd. José: The current story is less performant that it could be. Simon: It might be hard to implement. You'll have to allocate a closure for each argument. Richard: Strict let is an abomination. cf. github post. Iavor: Yes. That's why I wanted only one part of BangPatterns. Simon: The question is: What's interesting enough for people to actually do the work? Iavor: I'll do records. Richard: Once something is ruled uncontroversial, someone just has to volunteer. Andres: I've been unwilling to put in work not knowing about procedures, etc. E.g. Should every language extension be handled separately? What's the procedure. Simon: You mean: What are the steps I have to take? Wren: It's a fear of bureaucracy that's stopping you. Andres: But what really is a detailed-enough spec? The Report as is might not be enough. Lennart: But we're not going to rewrite the report. All: Agreed. Lennart: We're making a diff. Iavor: That's why we want to start with something simple. Simon: Let's start with a free-standing specification. Then people can comment on the feature. Then, integrate with the Report. Just having a diff would be a challenge for discussion. Andres: Too many things interact if we just look at diffs. Simon: Free-standing spec can have more exposition. Simon: Shall we do TupleSections? Andres: Is there any argument about how they should work? Wren: Do we need the parens around tuples, or are the commas sufficient? Many: We need the parens. Wren: I like them too. Simon: We still need a mechanism. Andres: Herbert wanted to use the GHC proposal process. ( discussion of mechanics -- generally trying to clarify GHC proposal process ) Resolved: We will all *watch* the H2020 repo. Resolved: - Start proposal on a branch. - Submit a PR from the branch to master. - Any of us can edit the branch. - We will do so in good faith. - If a substantive change needs being made, then make a PR against the PR. Iavor: We need to actually finish something before moving on. All: Yes. Finish. Andres: Changing the report is an independent phase from the proposal process. Wren: Yes. Andres: But it's not a PR. Richard: Do we have the source for H2010? All: Yes. Herbert may have put it in. Simon: Can we have very clear github instructions? Iavor: Yes. I volunteer. José: Jurriaan wants to say: We need to remember that Haskell is an education language. José: I volunteer for TupleSections. Richard: I volunteer for GADTSyntax. Andres: I volunteer for ExistentialQuantification. Adjourn 1:36pm JST. -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae http://cs.brynmawr.edu/~rae