September 2016 - Haskell-prime

Re: minutes from committee meeting at ICFP
by Richard Eisenberg 02 Oct '16

02 Oct '16

I recall that Iavor took notes from the podium. Iavor? > On Sep 27, 2016, at 12:58 PM, Ben Gamari <ben(a)smart-cactus.org> wrote: > > Richard Eisenberg <rae(a)cs.brynmawr.edu> writes: > >> 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. >> > Did anyone take notes from Iavor's Status of Haskell discussion during > the Symposium? There were a few points brought up there that shouldn't > be forgotten. > > Cheers, > > - Ben >

2 1

New Github features and Haskell Prime
by David Luposchainsky 29 Sep '16

29 Sep '16

Hello prime people, Github recently added a board-style overview over tickets and small notes. I think this is a great addition, and converted all current PRs to board items. There is no shortage of things to be considered for Haskell Prime, and I find it hard to think of them all. For things I’m somewhat interested in seeing a proposal for, I created notes that are not yet tickets, but serve as a reminder to consider them at some point. I’d like to invite you all to add your language extensions and ideas to the board in the pre-proposal column. Even if you don’t have the time to write a proposal, someone else might see the note and decide to do so instead. See you at https://github.com/haskell/rfcs/projects/1 Greetings, David/quchen -- My GPG keys: https://keybase.io/quchen

5 7

minutes from committee meeting at ICFP
by Richard Eisenberg 27 Sep '16

27 Sep '16

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>

1 0

Meet up at ICFP?
by José Manuel Calderón Trilla 19 Sep '16

19 Sep '16

Hello Haskell Prime, On IRC Andres Löh suggested that we have a haskell prime gathering that coincides with ICFP. I told him that I'd take on organizing it, and now that we're only a few weeks away it's probably time to do so. First and foremost, the main purpose of this would be to meet each other, put faces to names, and get a sense of who is interested in what. We aren't trying to finalise any decisions via back-room discussions :) So with that in mind, if you're interested, please email me with your availability. Non-committee members are welcome to email me as well. I'll find the time that works for most and sort something out. There are a few ICFP-wide constraints: Monday Sept. 19th, 18:30 - 20:30: Welcome reception and student-research competition Tuesday Sept. 20th, 19:00 -21:00: Reception and Banquet Thursday Sept. 22nd, 18:30 - 20:30: Industrial Reception If there are any other constraints that you know of (PC meetings, Steering Committee meetings, etc) let me know. Cheers, José

4 4