|
|
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
_______________________________________________
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
|
|
|
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
|
|
|
-----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
|
|
|
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
|
|
|
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
|
|
|
-----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
|
|
|
On 6 May 2016 20:58, "Cale Gibbard" <[hidden email]> wrote:
>
> 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.
+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
|
|
|
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
|
|
|
-----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
|
|
|
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:
> 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
<a href="javascript:;" onclick="_e(event, 'cvml', 'Haskell-prime@haskell.org')">Haskell-prime@...
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
|
|
|
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!
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 <_<a href="javascript:_e(%7B%7D,'cvml','deepfire@feelingofgreen.ru');" target="_blank">deepfire@...> wrote: 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
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
|
|
|
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:
> 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
______________________________
+1
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
|
|
|
-----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
|
|
|
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
|
12
|
Locked
signature.asc (501 bytes)