May 2016 - Haskell-prime

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

Infrastructure status?
by Iavor Diatchki 01 Jun '16

01 Jun '16

Hello, what is the status of the discussion about how we should collaborate? I am not picky and would be happy to use whatever tools others prefer. If it was left to me, I'd use: 1) a git repo on github, which contains the current version of the report, and various proposals, and 2) this e-mail list for discussion. As I said before, I think it might be quite nice as a first step to standardize something simple, and hopefully not too controversial, so that we can all familiarize ourselves with the basic process. -Iavor

3 3

New Proposal: EasyMacros
by Anton Felix Lorenzen 18 May '16

18 May '16

Hello list, I want to propose a new way of writing template-haskell macros. It is based on the idea, that syntax like this: do { x <- getLine; putStrLn x; } should be parsed into: $( do [ [| x <- getLine |] , [| putStrLn x |] ] ) Then a function (do :: NonEmpty ExpQ -> ExpQ) will be called and executed. This would allow for a couple of useful macros: - do - case - fold -- fold the ExpQs into one, see below for details - eval -- evaluate ExpQs at compile-time - (maybe even) hamlet -- evaluate hamlet QQ - CPP replacements? Nothing will be added which isn't possible today. Nonetheless it will allow for a much cleaner syntax and by this make things usable which weren't usable before. Also it might be easier to implement new features. For example ApplicativeDo and RecursiveDo could have been implemented by a hackage package. MultiWayIf could be a function, too. apply [1..(10*365)] map (replicate 3) concat conc "Hello World! \n" "How are you? \n" Greetings, Anton ===== Example Macros ===== see in context: https://github.com/anfelor/EasyMacros conc = fold [| (++) |] apply = fold [|flip ($)|] fold :: ExpQ -- (a -> b -> c) -> NonEmpty (Q Exp) -> Q Exp fold _ (a :| []) = a fold fn (a :| b : xs) = fold fn (([| fn $a $b |]) :| xs) do_ :: NonEmpty (Q Stmt) -> Q Exp do_ (x :| []) = x >>= \case BindS _ _ -> fail "The last statement in a 'do' block must be an expression" NoBindS e -> return e do_ (x :| xs) = x >>= \case BindS pat exp -> [| $(return exp) >>= \ $(return pat) -> $(do_ (fromList xs)) |] NoBindS exp -> [| $(return exp) >> $(do_ (fromList xs)) |]

2 1

Chairship / responsibility
by Richard Eisenberg 09 May '16

09 May '16

Hi Prime, Is there a chair of this committee? Herbert has been acting as such (thank you!) but doesn't list himself as the chair in the initial announcement. I am **in no way** trying to change any status quo and am **not** interested in being chair at the moment, but I just wanted to clarify. The specific reason I ask is that Takenobu Tani recently asked about `pseq`. I have no intelligent response to offer, but would want to make sure that someone does offer a response. If there is a chair, that person is de facto responsible that we, as a committee, communicate well, both internally and externally. Thanks, Richard

11 11

Infrastructure & Communication
by Herbert Valerio Riedel 09 May '16

09 May '16

Hello Fellow Committee Members! Following up on the official announcement, here's a few basic things we should get agreement over before proceeding. First off, I'm hoping we can manage to avoid confusing email-threading in the interest of finding information easier lateron in the email archives. To this end, I'd like to ask you to consider changing the subject of your reply if you realise that the topic discussed is diverging significantly from the one advertised in the Subject-header. I'll start with the following basic topic ## Infrastructure & Communication Obviously, we have *this* public (archived) mailing list "haskell-prime(a)haskell.org". There's also a (registered) IRC channel "#haskell-prime" on freenode where many of us will probably hang around. In the past, the Prime committee used Trac (currently at https://prime.haskell.org/ ) to organise its work. Trac provides a wiki, source-browser, and a ticket tracker (which is familiar to GHC developers, and e.g. allows easy migration of wiki-content to/from the GHC Wiki). Some time ago, I converted the original Haskell-Report Darcs repositories into a single Git repository (with branches) at GitHub - https://github.com/haskell/haskell-report This repo is setup to be mirrored to - https://git.haskell.org/haskell-report.git which in turn is also accessible from within Trac at - https://prime.haskell.org/browser However, since Trac has accumulated quite a bit of old content in its ticket-tracker over the years, and "Haskell 2020" has been coined a reboot. Maybe it wouldn't be such a bad idea to start over at GitHub, and consider the Trac instance mostly as a legacy archive of historic content. GitHub allows for Git-based workflows, and there's prior art related to language design we could steal ideas from, for instance: - https://github.com/fsharp/FSharpLangDesign - https://github.com/rust-lang/rfcs - https://github.com/golang/proposal - (any others noteworthy?) IMO, GitHub's issue tracker has become flexible enough for our needs and its integration with Git pull-requests allows to e.g. group together change proposal description/motivation, discussion, and finaly the delta to the haskell-report (with inline annotations/reviews) and so on. (However, I consider GitHub's Wiki-component quite weak. I'm not sure what to do about that. Maybe keep using Trac's wiki for that?) Moreover, we can have CI (I've actually set up a TravisCI job which builds the LaTeX code) for the Haskell Language report drafts. One benefit I see from using GitHub is that this way would we be closer to the Haskell community (given the majority of Hackage packages are hosted on GitHub), and our work would be more transparent for the community as well as offering a lower barrier to participation/contribution. Moreover, I think GitHub would also help make our efforts/progress towards a revised Haskell Report more visible to the community, which in turn may even provide us the motivation to carry on... So... Does anyone object to using GitHub? In case there's no objection, which of the existing language-design GitHub projects do you consider a good fit for Haskell Prime and therefore worthy of imitation? Any other comments/suggestions? Cheers, HVR

16 20

The GADT debate
by wren romano 09 May '16

09 May '16

Hi all, There's been some discussion about whether to consider including GADTs in the new report, but it's been mixed up with other stuff in the thread on incorporating extensions wholesale, which has unfortunately preempted/preceded the discussion about how to go about having such discussions(!). My position on the debate is that we should avoid having the debate, just yet. (Which I intended but failed to get across in the email which unintentionally started this all off.) I think we have many much lower-hanging fruit and it'd be a better use of our time to try and get those squared away first. Doing so will help us figure out and debug the process for having such debates, which should help the GADT debate itself actually be fruitful. As well as making progress on other fronts, so we don't get mired down first thing. Whenever the debate occurs, here's a summary of the relevant emails so that they are not lost, buried in the emails of time: * Andres Löh puts forth criteria on how to judge whether extensions should be included. Mentions GADTs as an example of something that, if we decide they're a good idea in principle (criterion #1), then we should work towards things which will help them be easier to feasibly/sensibly specify (criterion #2) https://mail.haskell.org/pipermail/haskell-prime/2016-May/004104.html * wren agrees with the criteria, loves GADTs, thinks they do not fully satisfy criterion #2 https://mail.haskell.org/pipermail/haskell-prime/2016-May/004115.html * Simon Peyton Jones says type inference for GADTs has, in fact, stabilized. Albeit, not entirely satisfactory because it's "a bit operational" https://mail.haskell.org/pipermail/haskell-prime/2016-May/004119.html * Henrik Nilsson thinks GADTs are one of the most important extensions to Haskell (fwiw, wren agrees). Also worries about being able to specify type inference declaratively. https://mail.haskell.org/pipermail/haskell-prime/2016-May/004120.html * Dominique Devriese suggests including MonoLocalBinds, finds "let should not be generalized" convincing https://mail.haskell.org/pipermail/haskell-prime/2016-May/004117.html * wren finds "let should not be generalized" unconvincing https://mail.haskell.org/pipermail/haskell-prime/2016-May/004145.html -- Live well, ~wren

6 8

Are there GHC extensions we'd like to incorporate wholesale?
by John Wiegley 09 May '16

09 May '16

I wonder if there are GHC extensions we'd like to promote as features in the next report, as a starting point for discussing new additions. There are a few GHC features that have become part of the regular Haskell landscape, such that it's hard to imagine a modern Haskell without them. For example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc. How much "work" is typically involved in promoting a feature to be in the Report, and how do we determine when it's a bad idea? -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

17 25

Starting point for new standard?
by Christian Siefkes 04 May '16

04 May '16

Hi all, out of curiosity, what'll be the starting point for the next Haskell report? I suppose Haskell 2010 plus the additional "No Datatype Contexts" change accepted by the old Haskell Language committee in early 2011 (see https://wiki.haskell.org/Haskell_2010#Additional_change )? Best regards Christian -- |--------- Dr. Christian Siefkes --------- christian(a)siefkes.net --------- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ | Wie Produktion zur Nebensache wurde: www.keimform.de/2013/freie-quellen-1/ | Why Production No Longer Worries Us: www.keimform.de/2013/free-sources-1/ |------------------------------------------- OpenPGP Key ID: 0x980FA6ED -- 2 + 2 = 5 for suitably large values of 2.

2 1

Re: Are there GHC extensions we'd like to incorporate wholesale?
by Doug McIlroy 03 May '16

03 May '16

> One objective would be to compile the Haskel Platform with near zero extensions. I would hope that means that the platform will lean on contributors to observe the new standard and curb exuberant use of extensions. It would be wrong to blindly accept a selected corpus of existing code as basis for a standard. (This is not to say that haskell prime should ignore the practices of outstanding packages.) Doug

1 0