Limber separators
Locked
12
12
 
|
-----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 [hidden email] 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 [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
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 <[hidden email]> wrote: -----BEGIN PGP SIGNED MESSAGE----- _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512 On 06/05/16 18:34, Iavor Diatchki wrote: > 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 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 [hidden email] 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----- _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Alexander Berntsen
I frequently run into the (relatively minor) list comma problem when writing
testsuites. I'd welcome a grammar change that simply skips all commas before "]" and after "[" or similar. I think this issue is related to TupleSections in that Haskell does not provide good syntax for these common cases. However, as mentioned, we should be careful to introduce syntax for convenience: without a principled approach, we'll end up with sugar soup. I for one need "-XTailingListCommas" much more often than tuple sections, so when weighing those extensions against each other, I'm very much on the list side. Just for confirmation, you meant > [ Foo > , Bar > , Fu > , Baz ] and not > [ Foo > , Bar > , Fu > , Baz > ] in your email, right? Greetings, David/quchen _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
signature.asc (501 bytes) |
|
-----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? 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 [hidden email] 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 [hidden email] 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 <[hidden email]> 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 > [hidden email] > 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 > [hidden email] > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Iavor Diatchki
On 05/06/2016 06:34 PM, Iavor Diatchki wrote:
[--snip--] > 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. > [--snip--] (I'm not on the committee or even close, just be absolutely clear from the start.) While I have a) *NEVER*... *EVER* seen TupleSections in the wild[1], and b) I really, really want to have an "ignore-trailing-comma" rule for lists, I must say that this is a situation where backward-compat and the Principle of Least Surpise[2] probably rule the day. I'm certainly be open to persuasion, but that would probably mean deprecating TupleSections, and I'm not sure how popular that would be. (And would perhaps require *two* iterations of the Haskell standard to achieve. I suppose an exception could be made if a "go fix" type tool could be developed, but I'm not sure that's something the Standards committe should concern themselves with... but it *would* be able to move the language towards much faster evolution, FWIW. I wish we had hfix.) Regards, [1] Didn't even know they existed until the recent thread on Reddit. [2] That is, it would be surprising if lists and tuples worked differently in this respect. _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Cale Gibbard
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512 On 06/05/16 21:58, 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. I agree that there are more important milestones for Haskell' than 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. > I'm sorry if this comes off as harsh, and I don't really mean to > be picking on Alexander specifically here I'd like to add that I don't think you're coming off as harsh or as if you're picking on me. :) - -- Alexander [hidden email] https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXLPjCAAoJENQqWdRUGk8BlIYQAKYhnSPwSufX/FqPnl3D4pRR QocLkPjacydJQFcy2RbJYRM5UwSw1/Cs/a78zjnuy4dK6a5uH5DkG8w6ObljbvCn 0vbsj92FpDVtzmcNQt6rvfcMPD8sjzc4rR+6kTysYsVm1k3zARwO94IykVApUXy0 SMtH7DxPT4SyGr/07xA6T1c7SYn2if85aAM2DTdqgN78iJzyJAlxpitMAUSkwsuf bIbi0ZM0leDPxgbGN5IsV/8TI21r5oymFj4L2nUWz0WfD6lrNUJemXgKzuVUHL1q WOxvF4Ngv5HpGuF08UmyNWxhiIkR6cfFbx+KqeBtdensOLiPDNwTP56mmbqSsH+i OrJuG8UTVpEK4EYLfm9KWOWCbznM9FpJ6QXU9hGnxBteG1rF8bXbZJiCefATw5pr TMq/+StpToI0rJPGLPFBJAbKhaBG2pj9RbiPO67vpkkPdvIgqgEzSyC6MxuFTu3g kkPpifadb2WUJKmqlXaK9wcIut1dJun1juA5d4NMjgabB+1wodra35HSF6oKwTp6 FqiOJphwvegSw5xGv04D9S28ymme+C2oB713yDtFqFxcMTDwGG+8vHCDYckxzpqe m+fEYZsVgQpV5/8ybJs47unrGdn0ZMPBf/iEf/63ifoLGqAOYI0QMswnuRJ7wD3o 14Hng6xTt4MsQqBbKGvw =saV3 -----END PGP SIGNATURE----- _______________________________________________ Haskell-prime mailing list [hidden email] 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 > > On 06/05/16 21:58, 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. > I agree that there are more important milestones for Haskell' than > 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, _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Cale Gibbard
+1 I would use this extension. But I strongly agree that it should start out as an extension and prove its worth in that form before becoming part of the language proper. Having Haskell' choose from the set of all available extensions is already a daunting task without opening the gates on unimplemented things too! I get the impression that many extensions that merely extend the syntax of the language are widely considered to be acceptable and seem to be on track for inclusion in H'. If this were implemented soon enough, perhaps it can make it in this time too; if not then I'm sure it'd be a candidate for a future report. I use TupleSections, and would prefer that this extension did not apply to tuples. I would also prefer to get rid of the separators completely and just use layout to delimit things, somehow. Cheers, _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Alexander Berntsen
Alexander Berntsen <[hidden email]> writes: > [ 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’m not on the committee either, but here’s my three haporth. 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” The problem is that diff does its work in ignorance of the syntax and consequently produces poor results. The other observation I want to make is that the object of programming language design is not to make writing programmes (or changing) easier. It is to make writing incorrect programmes (especially programmes that look right but are not) harder. We have to ask whether making a “one line diff” do this is actually productive. Having a large Hamming distance between syntactically valid programmes is an advantage. -- Jón Fairbairn [hidden email] _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Bardur Arantsson-2
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, _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Jon Fairbairn
-----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 [hidden email] 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----- _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Bardur Arantsson-2
Bardur Arantsson <[hidden email]> 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 [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
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 <_[hidden email]> wrote: Bardur Arantsson <<a href="javascript:;" onclick="_e(event, 'cvml', 'spam@scientician.net')">spam@...> writes: _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
On Saturday, May 7, 2016, Carter Schonwald <[hidden email]> wrote: 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! My bad for forgetting to reply below rather than above :) Tla+ does have leading AND style syntax in the style of the what is being discussed here, but that was done from the outset. Either way, experiments in syntax and semantics are best grounded in ... Running experiments using them! Certainly some parts of what we hope to achieve need to be grounded thusly, even if it's not changing the type system or the syntax of the core substrate. Let's do some experimental research and see what happens in the wild, in codes natural habitats! 🕵🎉 _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by Cale Gibbard
On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <[hidden email]> 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 _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
On Saturday, May 7, 2016, wren romano <[hidden email]> wrote: On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <<a href="javascript:;" onclick="_e(event, 'cvml', 'cgibbard@gmail.com')">cgibbard@...> wrote: +1 _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
|
|
In reply to this post by wren romano-2
-----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 [hidden email] 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----- _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
Scope of committee (can we do *new* things?)
|
|
On May 8, 2016, at 6:27 AM, Alexander Berntsen <[hidden email]> wrote: > > 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. The above snippet has been taken from the "Limber separators" thread. I don't wish to debate limber separators at the moment, but I think Alexander raises a good question here: Should we endeavor to take on any as-yet-unimplemented behavior that might make Haskell better? My own opinion is a resounding "yes!" If we say "no", we're left with a terrible chicken-and-egg problem. I have seen some proposed extensions to GHC be thrown out because they would fragment the language unnecessarily. Chief in my head is that proposal to allow `case`, `if`, `do`, etc., in a function application without parentheses or a $ operator. That is, to permit `runST do blah; blah`. (See https://ghc.haskell.org/trac/ghc/ticket/10843) A common rebuttal against this proposal was that implementing the extension would involve a lot of huffing and puffing over a few characters, and that now all Haskell readers may have to be aware of this new extension, even if an individual doesn't write with it. However, the Haskell Prime committee is a great place to debate such a change. If we move quickly, we can even implement it, get it into GHC (or some other Haskell compiler, I suppose), and get feedback before we set the standard in stone. 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. Richard _______________________________________________ Haskell-prime mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime |
«
Return to Haskell - Haskell-prime
|
1 view|%1 views
| Free forum by Nabble | Edit this page |