June 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