- Haskell-prime - Haskell.org

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

Codifying language extensions in Report
by M Farkas-Dyck 19 Aug '16

19 Aug '16

Is this in scope? I.e. a conformant Haskell implementation must allow the extension, but using it remains optional.

3 2

Haskell Prime vs core libraries
by M Farkas-Dyck 15 Aug '16

15 Aug '16

For a proposal which affects the base library, such as AMP [1] for example, must we also consult the Core Libraries Committee? (I assume they already approved the AMP but i'm asking more generally.) [1] https://github.com/haskell/rfcs/pull/1

1 0

Merging RFC pull requests
by M Farkas-Dyck 10 Aug '16

10 Aug '16

Who has authority to do so? Shall we vote whether to merge each?

3 2

Anything happening?
by Michael Walker 20 Jul '16

20 Jul '16

Hello, I haven't seen anything on this mailing list for a little while, is anything going on? Has the process by which proposals will be submitted and worked out been solidified yet? -- Michael Walker (http://www.barrucadu.co.uk)

7 6

Re: New Proposal: EasyMacros
by Anton Felix Lorenzen 01 Jun '16

01 Jun '16

I am glad you like the idea. I fully understand that it should be an extension first, I simply followed the https://prime.haskell.org/wiki/Process I am think I am not able to make a prime wiki page (at least I wasn't able to find a button for this). Should I create a ghc wiki page? Email the Haskell-cafe list? This is my first proposal and I m a bit lost here. Thanks, Anton

2 1

Limber separators
by Alexander Berntsen 01 Jun '16

01 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Haskell uses separators for values in a number of syntactic constructs. It is my understanding of the 2010 report that the language does however not generally support leading separators, nor trailing separators, nor both (two exceptions are discussed at the end of this email). Consequently diffs are bloated, resulting in mental overhead when viewing and reviewing patches, as well as potential three-way merge conflicts or worse. A quick example: [ Foo , Bar , Fu , Baz ] It is impossible to remove values Foo or Baz with a one line diff. It is additionally impossible to reasonably add a new value to the top or bottom of the list. I want the Haskell' committee to discuss allowing one or more of the following: * Leading separators * Trailing separators * No separators The former two, or a combination, is arguably the least invasive modification, whilst the latter is more sensible as a language extension for now as it would break code. The latter is furthermore difficult as the rules are potentially more involved, yielding more gotchas. My immediate suggestion for the no separators route would be to use newlines. The discussion should apply to as many contexts as deemed sensible. It is arguably insensible to introduce leading or trailing separators where we would end up with ambiguity, as would be the case with tuple declarations due to tuple sections. Examples of where it would be sensible are abundant, and include -- but aren't limited to -- data types, lists, record fields, pattern guards, and language pragmas. If leading separators, or trailing separators, or both, are accepted as the way to go forward, perhaps permit extra separators in general. I.e. [,,,Foo,,,Bar,,,Fu,,,Baz,,,] is a list with four terms, Foo, Bar, Fu, and Baz. Please note that Haskell 2010 already permits trailing commas in import and export lists, like so: impspec → ( import1 , … , importn [ , ] ) (n ≥ 0) exports → ( export1 , … , exportn [ , ] ) (n ≥ 0) Meaning the following is legal: import Foo ( Fu, Baz, ) And the following: module Foo ( Fu, Baz, ) Bizarrely, the following is *not* legal: import Foo ( Bar ( Fu, Baz, ) ) I.e. impspecs are permitted trailing commas, imports aren't. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXLJekAAoJENQqWdRUGk8BksEQANHIhsGRaoDuwb6CM3NapElv XfcSgW5//Vva0/8f//BXUvN2rrfadxcjzr4xKL8CKME9sxlgRJ56RQi+Ai/L0mNZ h1x0Uqi3dmDzMxF1ROgKlUMjU4CAGqq5MMl3iZTC4vP7NpMUrqodZe7zO9INnP/7 av0x9GPI1SnXc1xocSMew9VA1fzd1tr8e+M73tex1yNC1pr5vI5hKSliofwTBHhW BAIKVOu3hEBUjhziZkmSPqOZJ4QCJYsMQ6P6ZCnxs7K2vplA3OQC+jOO/vM6MqdZ iaRrYiqyof3XkeNr7/Z96+6/iKdGIGn4+OsOzrWUMdsJfY/kftb7KJR/tRgfWug9 QMlMjmTfxDkCAlonU2uNwSustcMTJNhq6g4Ymg6k5t7MwojT6dDE0ASAUlOKGbCk WRvDVLRGaQcn7HF4PWq7RnrP+lvl9OUZr36L4QZrG8ei5v2DN/H30hlT0zzbyp97 yO9yHQZ0TmCt+iAbDi822vRlmfJEH7zRkrsmcHAmiOAsAfvZoaqtSiLK2eiczb1g V7h1h1ze3i0I+MNf7+Sbzot3kJwW8+3XqZoh2B1oyWgiDlrZhLDDHaEY4yzoPG3E hdmAOoYx43tnd6LkWhar86CwoxelyKvpXoLNp6JZe+mUAG4qwoa8AIcXglk4KTty k0M1NEwiPSy+/ymABx/T =E+MY -----END PGP SIGNATURE-----

17 30