Limber separators

Iavor Diatchki iavor.diatchki at gmail.com
Fri May 6 16:34:46 UTC 2016


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 <alexander at 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
> alexander at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160506/de67f045/attachment.html>


More information about the Haskell-prime mailing list