I am not convinced by the argument that this will help make 'diffs' considerably simpler: we have tools for visualizing diffs, Most people I know read plaintext patches in emails. Others use things

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/05/16 18:34, Iavor Diatchki wrote: like home made review tools, built-in review tools on SaaSS platforms like GitHub, review tools in big systems like Phabricator or Gitolite, etc. None of these help.

and saving an extra line at the beginning/end of a long enumeration seems like an unlikely source of confusion The examples I gave were banal. More involved ones are easily imagined. Moreover, if you view things in isolation like this then everything is simple and clear, so I think it is an unfair argument.

or serious merge conflicts. I don't know what you mean by "serious", but I don't treasure any moment I've spent on solving three-way merges from this issue.

By the way, leading/trailing separators conflict with the syntax for tuple sections:

(True,) :: t -> (Bool, t) (,True) :: t -> (t, Bool) Please read my email; I already mention this.

I think that it wold be quite odd if leading/trailing commas meant one thing in tuples and something completely different in lists. As explained in the original email: there is already precedent for trailing commas in import and export lists, so commas already mean something different there. Commas are overloaded already. I don't find this any more confusing than ad-hoc polymorphism in general.

Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXLMu5AAoJENQqWdRUGk8BSW0QAKgX1VIZyH+TA5b7Ac0ieZmn 8gwVeIB+rFog8TqZ/KSF4aY3kO92M35FFvFI0BV3YEaE+URW42S2r5MgtpvQBiCt cudVW2SHZU9BAag1vU1cd8vykFwLphxZQ+/bRidKRM3+zebK6a8ON6cJTPXOrM3W bo2s95ZjGnYkkuT+cMEXBD6V193aNJZGFWF4PnN7OBFt0u1w3Lm0ZhTH1qewQMZP PypTlFVL6N45sWDPKqbTlrb0vES25AWNGdMjHZi5UkQ3Wv0IB8rxiEnxR4VUFe6v 8Wy/xLSnutSk+Lgz68HnoztYNrvQVwpBjRDuhpv/1QhcKedY2/daLAt9u2tBEdBs 9RpzViGI1GNexRo8obztUV4zuFHE+F8vCf4ovCoGZSUMHWM0iGjEJzPXSGvcq2Bn tt+b0TZfH/kpUirlfkONiEHDHKANBBI2pdfsc+yqxSPfTL4wU/aTLRGbwazT26de N5MQI5Q77kXlDjEM+2YkuD9YDWX28/LJWtUwMsAYqkrRYX+Xn7/YzpEz4M7En8SE UWL62RXnX9BCF64Gl9GhlPnXUq8J/gTrz3iehTbKhABD+W6Ew+zpGbvMGAjz8da3 gUtOAgvKdUlvfJlE+Whr99Df3dnju43cKHeu9iTPiGbI5tkomVUMETexCO+D90BC gsSwLod24dVNh91/7Yxk =oHX2 -----END PGP SIGNATURE-----

On 05/06/2016 10:04 PM, Bardur Arantsson wrote:

[--snip--] Actually, thinking about it a little further... TupleSections is already opt-in, so this needn't conflict per se. Regards,

I worry that this thread is turning into a bit of bike shed before we have a good sense of what construction tools we have on hand! One side consideration we might want to keep in mind is what spaces of parser tech can work off the shelf in various juxtapositions of code and features. The more context sensitive a grammar is, the more humans Pay too! I've certainly seen agressive amounts of tuple sections in industrial code. Another meta question / challenge that this thread has posed is : given Haskell as it is today / will be in the future, is there a meaningfully better language tuned diff tool that could exist ? On Saturday, May 7, 2016, Kosyrev Serge <_deepfire@feelingofgreen.ru> wrote:

Bardur Arantsson javascript:;> writes:

...

Actually, thinking about it a little further... TupleSections is already opt-in, so this needn't conflict per se.

Isn't this dangerous, in how it now gives a trivial piece of code two very different interpretations, in a plausibly unintentional way?

...

{-# LANGUAGE TupleSections #-} (x, y, ) :: t -> (a, b, t)

...

{-# LANGUAGE LaxCommas #-} (x, y, ) :: (a, b)

I understand that we have OverloadedStrings, viz:

...

{-# LANGUAGE NoOverloadedStrings #-} "a" :: [Char]

...

{-# LANGUAGE OverloadedStrings #-} "a" :: IsString a => a

and yet, the differences in this respect seems significant:

The unintentionality of change in interpretation effected by the transition NoOverloadedStrings -> OverloadedStrings is implausible.

Whereas with the LaxCommas -> TupleSections transition I guess it would be fair to say that it is plausible.

Moreover, OverloadedStrings doesn't disallow using string literals as string literals, whereas LaxCommas and TupleSections are mutually exclusive.

-- с уважениeм / respectfully, Косырев Сергей _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

I can't really be the only one here who thinks that this kind of discussion of extensions to the syntax of Haskell is totally inappropriate when we have a large number of already implemented extensions to the language whose interactions with each other are largely undocumented. The Haskell Report isn't the place to be talking about new features, in my mind. If this project turns into bike-shedding the concrete syntax of the language, it's hard to imagine real progress being made on the actual problem, which is that the Haskell Reports as they stand are not as relevant as they should be with regard to the language in which we're writing programs today. In my opinion, this sort of bikeshed discussion of new features is the main reason that H2010 didn't really get very far relative to H98. If you personally want the ability to insert additional commas at the beginning or end of lists, perhaps a better plan is to start with asking the GHC developers with where to begin on a patch to the parser. Then once everyone is using your extension, some future Haskell Report can perhaps document it. I'm sorry if this comes off as harsh, and I don't really mean to be picking on Alexander specifically here, but I'd really like for the next Haskell Report to be relevant to the language we're using today, and I think there's too much to be done in the direction of reporting on the things we already have to even consider things which are unimplemented, or even things which were only *just* implemented. On 6 May 2016 at 15:45, Alexander Berntsen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

On 06/05/16 19:22, David Luposchainsky wrote:

...

Just for confirmation, you meant

...

...

[ Foo , Bar , Fu , Baz ] and not

...

...

[ Foo , Bar , Fu , Baz ] in your email, right? Yes. The latter is how I have adapted my style to be able to remove Baz in a one-line diff, so I wrote it automatically. :)

Similarly, this fixes the removal/addition problem for the top element, but not the bottom element:

[ Foo, Bar, Fu, Baz ] - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCgAGBQJXLPRaAAoJENQqWdRUGk8BBGQQALQVQftrgJrCxWDtgvo43ZGZ NmBrBCDBVwwKojBq8HgHF6oOK2tQhglu1KefQtX7Qrya8UxtM/axI/AU38jnrHHq 19zQBzyEpiAoGgbd/02OkoWvyj+fDt2dy5KI6PV74BnKnZ2k6ZmpYcffRXuL/Cdb 4zUZ2FTpU2FSx0HE0FTfdETqZ5dwjIEyBWiHd+eqEEQgTO7KUc6Q10jqkw6xeVuI EVIbZNh9/n4bl2cJEHpgQ/442w21Neg5gMJWc/5UCnhpBwJUhYtxJRJWRqfgJQ1E zM2pI1gkJZbTqiL/YinxbFAkXVF2CGMjLMdUH8gANPuPaI7FYz1F5kydmjuIuxwP I4bE9hdDnDzTnClPzgryfNBc2EcMdK91sG3+/qBRP/SGlTzttUciQo44dR42Zi5s /qEx0vmtOy5Meh3PSAUs2kkMcvS7ELFKQlXfzxNR0pKYFN5cwAUTcSPLqEtNfG7M D/K0k76F99+Ehhl2aralO2TntSj8qZN5AeOa/YndKQE3xiqVcnVKUJ34mOba5N2u FcpuV9jF1kt3+t5EQUWar2x56jwcqnLE3rPu4Hj3qzL3R5hAyJYh/yDPEVOgxo8W 7B+uS0IBCMmiCOeJv3HqGGkLTywzzLjka4X3nQHVK0aYu4gNgfEJLg2vbA9K1KJB +6ig1u87MQx4HfDyL/57 =00Rx -----END PGP SIGNATURE----- _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

On 05/06/2016 10:04 PM, Alexander Berntsen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

...

I can't really be the only one here who thinks that this kind of discussion of extensions to the syntax of Haskell is totally inappropriate when we have a large number of already implemented extensions to the language whose interactions with each other are largely undocumented. I agree that there are more important milestones for Haskell' than

On 06/05/16 21:58, Cale Gibbard wrote: this. I disagree that anything but those more important milestones should be shot down as somehow inappropriate. Especially given the time frame of four years.

+1. The existense of "THE GREATEST PROBLEM IN THE WORLD" doesn't mean that we cannot try to solve "SMALL PROBLEM". (This is a classic fallacy.) Regards,

On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard wrote:

I can't really be the only one here who thinks that this kind of discussion of extensions to the syntax of Haskell is totally inappropriate when we have a large number of already implemented extensions to the language whose interactions with each other are largely undocumented. The Haskell Report isn't the place to be talking about new features, in my mind. If this project turns into bike-shedding the concrete syntax of the language, it's hard to imagine real progress being made on the actual problem, which is that the Haskell Reports as they stand are not as relevant as they should be with regard to the language in which we're writing programs today.

+1. One of my big concerns here is that the proposal is vague, and therefore impossible to judge. As an example of what I mean, what counts as a "separator"? Is it a special case only commas? Why not also include the vertical pipe in data type definitions? We run into the same "difficult to one-line merge" issues when we write things like: data SomeReallyLongNameSoIWantToNewlineWrap = Foo ... | Bar ... ... Coq and other ML-like languages allow a vertical pipe between the "=" and the first constructor name, so why shouldn't we? Or, what about when people do parser combinator stuff and use the (<|>) operator as a "separator", should we handle that too? If so, do we extend it to other operators people may want as a leading separator, like (+) in large arithmetic expressions? How should these be distinguished from typos where an argument is missing or a section was indented? These sorts of complexities are the reason the Haskell' committee has always focused on things which have already been implemented. The implementation provides (a) a concrete specification of what's being proposed, (b) an idea of how that proposal works in the wild, (c) a proof that it's easily implementable. Of course, in the process of getting included into the report the details may change; but it's a very solid starting point. I'm not adamantly opposed to proposals which aren't already implemented, but the proposal should measure up to the same standards— N.B., it may appear to be held to higher standards, since people often neglect to consider the role an implementation plays as a component of the proposal itself. As you say, four years is a decent chunk of time. Why not spend that time getting it implemented as an extension in GHC? The implementation process will work out a bunch of kinks in what exactly you mean by "separators" and how to handle leading vs trailing vs redundant separators. Having it available will also make it clearer how many people like and want this behavior. Both of these contribute to making the argument that we should in fact include it in the report. -- Live well, ~wren

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/05/16 05:03, wren romano wrote:

One of my big concerns here is that the proposal is vague, and therefore impossible to judge. It is intentionally somewhat vague because I would the committee to address this problem which is largely solved in many other languages, but remains a -- to many bizarre -- problem in Haskell

As an example of what I mean, what counts as a "separator"? Is it a special case only commas? Why not also include the vertical pipe in data type definitions? If you read my email, you will see that I *am* including them.

Coq and other ML-like languages allow a vertical pipe between the "=" and the first constructor name, so why shouldn't we? Or, what about when people do parser combinator stuff and use the (<|>) operator as a "separator", should we handle that too? That's function (operator) application. I would think that it was entirely obvious that I did not mean that users should be able to write 'f f f f f f f x x x x x x x x' and have the compiler work out that the user meant 'f x'. If it wasn't, then I'm saying it now. I did not mean to include operators or function application. I'm not sure how that could even make sense.

I am slightly bemused by the amount of complexity this list is imposing on a -- to me -- relatively straightforward idea. I realise now that the report is not the place to fix problems with Haskell, but to standardise solutions that a high enough percentage of packages already rely on. I misjudged the ambition level of the report. Thus I withdraw this proposal to not waste the committees time any further. Please note that I don't mean this email to be a critique of the scope or ambition of the report -- I think that standardising solutions should be the clearly most important goal of this committee. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXLxR6AAoJENQqWdRUGk8BtlYP/RBm8cMLm3HzJA6fPnRHhhbj tomHfLqgg/2ZDs05wHY4v0rI5KMmQzfsZIJAJbv8FiWUprkW3X6YaKetxyICIfh/ KmBsqppACDEi62OEB28QAgvRmKy5zrsJOiT2a8Dg2IHUqfHvfAtk11sC1kscWXNa cjtfn0etNvOfLEJLU1pjUXf5iTLrkR0JQSAUsGn3vXhneWeMx2SkanH2H5PUXv1c hVIbUWXGC5M/VU9fp5O1xckHHboSPRJlSQbMx8srtN+3A65UdRZfCoH2HQ34+Tc3 j1kVKV9zF6X0GAogq3gdzqicCgMgfA46P7z3YdneTov78N8XfeD5CGJQrns+/iCF kube5pYhjHRws89rHJQjSsH/Jqz4+CPFbkyhyCs/ZorRrPlsFhz5Vtu5oeQN3nqZ PyntRUyQUpAYMJuwwGs8x1rxGScq/s+/6PvduznnYKwJFtaz0WQStLUK9zNQFwxN xXcQ6pFkeFqXM1ideHpCpP0bg25LQZps4WkAk7sGEgl1SkTQkS+a1m0DDZbE85HN P2Jz+XORwd+Y+n7KBmZbxPQDgmH8z/6d23F1UPEBwTG3A3GFSVw+Devwf1eZrv1G p+SNbVQVQlLvMF4gfQmfkYUSBk8muOtJPcXvAXOeuLTsI/WfI2jHhndizT4tYFsm mavFWSy2Fg89K1d+w4c9 =3/+J -----END PGP SIGNATURE-----

On May 8, 2016 at 9:25:33 PM, Richard Eisenberg (eir@cis.upenn.edu) wrote:

I do absolutely think we should be cautious about addressing unimplemented behavior. I would be strongly against a new type-system extension that hasn't been field-tested. However, I do think pondering lexical/parsical changes (such as limber separators) should be considered in scope.

While such changes should definitely be in scope, I do think that the proper mechanism would be to garner enough interest to get a patch into GHC (whether through discussion on the -prime list or elsewhere) and have an experimental implementation, even for syntax changes, before such proposals are considered ready for acceptance into a standard as such. But I also agree that discussion of things which may be in the pre-implementation phase are in scope — just that the next step is to get them past that phase before they’re considered for inclusion as such. There are enough traps in parsing that specification without an implementation is always a risky choice.  Recall for example the case of fixity resolution, finally fixed in Haskell2010 (https://prime.haskell.org/wiki/FixityResolution) where the behavior in the report was at variance with all implementations. I would hope that if a segment of the prime committee wants to test-run an experimental syntax feature, then this would take sufficient precedence over concerns regarding “language fragmentation” that the GHC team would be open to guarding it behind a flag. Given the number of GHC developers involved in this effort, I think that’s not a bad estimation :-) Cheers, Gershom

I disagree that we should be standardizing language features that have not been implemented. I think having an implementation is important because: 1. the act of implementing a feature forces you to work out details that you may not have thought of ahead of time. For example, for a small syntactic extension, the implementation would have to work out how to fit it in the grammar, and how to present the new feature in, say, error messages. 2. having an implementation allows users to try out the extension and gain some empirical evidence that the extension is actually useful in practice (this is hard to quantify, I know, but it is even harder if you can't even use the extension at all). If some feature ends up being particularly useful, it could always be standardized in the next iteration of the language, when we've gained some experience using it in practice. -Iavor On Wed, May 11, 2016 at 11:17 AM, John Wiegley wrote:

...

...

...

...

...

Gershom B writes:

...

While such changes should definitely be in scope, I do think that the proper mechanism would be to garner enough interest to get a patch into GHC (whether through discussion on the -prime list or elsewhere) and have an experimental implementation, even for syntax changes, before such proposals are considered ready for acceptance into a standard as such.

Just a side note: This is often how the C++ committee proceeds as well: a language proposal with an experimental implementation is given much higher credence than paperware. However, they don't exclude paperware either.

So I don't think we need to rely on implementation before considering a feature we all want, but I do agree that seeing a patch in GHC first allows for much testing and experimentation.

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

I strongly agree with all the points Andres makes here: - Focus on existing extensions - Permit discussion and even modification of existing behavior - Allow possibility of discussing new behavior - Strive hard to (or even require) an implementation before standardization (at the moment, time is on our side here) - Plan to include an appendix / co-report describing aspects of Haskell that are not yet strictly standardized Richard On May 12, 2016, at 4:25 PM, Andres Loeh wrote:

I think we all agree that in general, we should focus on existing language extensions that have an implementation, and expect language extensions to be implemented for them to be seriously considered for inclusion in the standard.

But I think it would be wrong to turn this into a hard rule. Language extensions are usually looked at in isolation, whereas the standard is supposed to be a whole. There may be things that fit in well, are useful generalizations of extensions we want to adopt, and so on that are worth discussing. Also, extensions should perhaps be modified or changed in some cases. If we say in advance that we can only standardize things that GHC already implements, and only in exactly this way, then it is a bit too limiting, and this would be throwing away the chance to clean up a few issues.

The other side of this is that if we really arrive at the conclusion that something should be different from the current GHC implementations in any significant way, we should at least try to get it implemented during, and not just after, the standardization process so that we can still get practical feedback, and to prevent ending up with a standard that will never be implemented.

Also (I think I've said this before), we should keep in mind that the whole process for Haskell 2020 can have more outputs than just the new standard itself. We can make progress towards standardization of features in future versions of Haskell even if they don't yet make it. We can make statements that we would in principle like to see certain features in the standard, and identify the issues that currently prevent them from being included.

Cheers, Andres

On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki wrote:

...

I disagree that we should be standardizing language features that have not been implemented.

I think having an implementation is important because: 1. the act of implementing a feature forces you to work out details that you may not have thought of ahead of time. For example, for a small syntactic extension, the implementation would have to work out how to fit it in the grammar, and how to present the new feature in, say, error messages. 2. having an implementation allows users to try out the extension and gain some empirical evidence that the extension is actually useful in practice (this is hard to quantify, I know, but it is even harder if you can't even use the extension at all).

If some feature ends up being particularly useful, it could always be standardized in the next iteration of the language, when we've gained some experience using it in practice.

-Iavor

On Wed, May 11, 2016 at 11:17 AM, John Wiegley wrote:

...

...

...

...

>> Gershom B writes:

...

While such changes should definitely be in scope, I do think that the proper mechanism would be to garner enough interest to get a patch into GHC (whether through discussion on the -prime list or elsewhere) and have an experimental implementation, even for syntax changes, before such proposals are considered ready for acceptance into a standard as such.

Just a side note: This is often how the C++ committee proceeds as well: a language proposal with an experimental implementation is given much higher credence than paperware. However, they don't exclude paperware either.

So I don't think we need to rely on implementation before considering a feature we all want, but I do agree that seeing a patch in GHC first allows for much testing and experimentation.

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 _______________________________________________ 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

Hi all, I too basically agree with Andres's points and Richard's summary. But there are a fair few existing extensions, and they are not all equally compelling or urgent. (Just to exemplify, multi-parameter type classes (which in practice necessitates functional dependencies or broadly equivalent functionality) and GADTs have been mentioned to me as particularly urgent a fair few times.) So, with risk of stating the obvious, a bit of care is needed to decide just which existing extensions should be at the top of the agenda. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/05/16 10:44, Jon Fairbairn wrote:

Something that is missing from this type of discussion is any reference to design rules, agreement on which should be made before any suggestion like this.

The one this violates is “never make language design decisions to work around deficiencies in tools” I am entirely sympathetic to the argument. But I also have to read and write Haskell a lot, and to suffer from something that can seemingly be so trivially fixed *hurts*. Especially when languages like F# and Elm have taken a more practical stance and just fixed it. It's another "Haskell isn't practical/serious" argument from engineers -- and like it or not, engineers are the main users of the language.

We should definitely avoid success at all costs. However, I don't think the cost is too great in this instance. Especially considering that there is already precedent for this in import and export lists. Finally, I'd like to add that I appreciate your post and angle, and hope that the committee take it to heart in general. The design should be guided by (but not slave to) first principles. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXLdMHAAoJENQqWdRUGk8BRZkQAOcxrn2oBuJMZkOsDN3vN4z7 GkeDbf4N6EB//xeQxWYvGkzcFoVLsKY6CASZ4pthRKEn0hE7EgP8q7MZOuoTECt8 fvECtpL50v43GFQ8aY6thytKkPWIPuhaN9gL5jrH5S/Q5dS4cieaxEqdh27RBSYZ FFiLlOrpVPQcuIzo2EVVVReApbatNIu3LsUXWW0wLeEjqudEVRt4yLK6WMAdSdKO C5OMuZoU2G0Cw4LOQV5tDnUfj9RS06+AJIEUUvgk7xbhU46ZaNQHqde1pTDJ3w/K Iq3g5WFndt8JZfAN/2eTLCmWj4EsX/iBMDunQqwlmAxlez5qYIgNlnlB9a7guj/n 9BT9zLuxnc/SsKB33KIkFSlVyQsssBXWOqvRcQ6ND4yi26rTLJry0WvEZ5IDmdg+ hRdKKb2YvyHLBuqMp7rIBQ7fwfCegWfJpp4A+GsCbkKXfz2SZJCBdDT3UZMkgwIQ qXr4CRESKssGXh/ezz+vXltxTAPArfDb97vULr8PeIrMoBFacIR6PVhSxHS7aSeE Hbh7zD6S6ynobtFBReQo4KYGlXUOC9nNDktnpjUAc12xQoRwVqirAasJ5D1oMwkO LB6L6YyHVlfcqb8ZfbFAHpblCCrbuw4f3pi6a9YVUy4d9ZyhX0K0RFSEWcHxE1rG yWFHxsMF+/bf7AM+tX9z =/DKF -----END PGP SIGNATURE-----

On 12 May 2016, at 23:48, Iavor Diatchki wrote:

On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn wrote:

The one this violates is “never make language design decisions to work around deficiencies in tools” The problem is that diff does its work in ignorance of the syntax and consequently produces poor results.

I think that this is an excellent principle that we should uphold.

Personally I don't need this extension per se since I don't care about one excess diff line. What I do care about however, is the horrendous style people invented to avoid “the diff problem”. As an example something = [ foo , bar , baz ] So I’d really like to see this extension, even if only to conquer the aforementioned style. PS But this all is indeed a little bikeshedding before we finish the “Infrastructure & Communication” thread. -- lelf

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/06/16 08:44, Herbert Valerio Riedel wrote:

Well, I'd really like to see the grammar relaxed to allow for redundant leading separators so I could finally use my personal ideal diff-friendly style:

something = [ , one , thirteen , two , three ] If your ideal style uses every entry on one line regardless of how short it is (in terms of character count), then surely simply 'ENTRY\n' is better than ', ENTRY\n'? At least my preference in that case would be no comma, or a trailing comma.

Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXTq2NAAoJENQqWdRUGk8BZJMQAL5CGwQyVUJJP/oMUw7DpnI2 gXb/3uYF+Od6GAKLHZnPB4G2+fq7xXvINENki2T6u0/Va4FeQ/xTLrccR7j3o++1 c4LtxctUjpEz321Hi/v4Zq3JZL5XY6z39dZwUx0cMcCmUXk1+aVzmQGh1S4Y+/3E ICHyAOESUB6vlMeL492qVGtD6drkstuQaDTKn/kry/jTgnAabcIa9hJ5EWj4DMFW jTcpkDD8kLFTPlKN+ky8bN02RmMVkC8jZe5n1+S4WhWVK7Fixsib5nE5qaYl73Wq FCFf2b8FKkoCyAMTfJmdZt2yXgl30+/DAJa60E7I40uh98Ak1uH1V02cpOOVt3FU dgH1TWP/TP36VZ+HpJ85vdrbdioG5aQar4aeFVosd6vbIQNhiCKjcfR4aLo6C1Bg zfORQtpzqq11M6SHTZG91L4+Ti/y4vfFE/qnY1YhP5dpTblT7TJRP/s4eQwXnfYs GmhCOeev43P6mNL9TXyz4OkLzxrgdEzYWgdlGn88gg8dHIj5+BOxJNw9uJgb4iRq ovz+efoGGN3lk3prNeD6VO7BZ6WRu3mi7JJcX2nmjyfOGK2tQE9eYuFS/oevkJwE zFI7RAwi/UecN9jJ1do+zq/DBjQo2bRJnlswhwAdLxqhyyhxNuMvQdklibhlWsrZ Irj2614mavqB67f3Os7k =ojRm -----END PGP SIGNATURE-----