Hello, I am not convinced by the argument that this will help make 'diffs' considerably simpler: we have tools for visualizing diffs, and saving an extra line at the beginning/end of a long enumeration seems like an unlikely source of confusion or serious merge conflicts.
By the way, leading/trailing separators conflict with the syntax for tuple sections: (True,) :: t -> (Bool, t) (,True) :: t -> (t, Bool) I think that it wold be quite odd if leading/trailing commas meant one thing in tuples and something completely different in lists. -Iavor On Fri, May 6, 2016 at 6:09 AM, Alexander Berntsen <alexan...@plaimi.net> wrote: > -----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 > alexan...@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----- > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
