Re: Limber separators

2016-06-01 Thread Alexander Berntsen 
-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
alexan...@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-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-06-01 Thread Herbert Valerio Riedel 
On 2016-05-31 at 15:42:14 +0200, Antonio Nikishaev wrote:

[...]

> 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
> ]

I'm not sure this style was invented to address the diff-problem, as it
actually doesn't solve the problem at all; it only shifts the problem
from the last entry to the first entry in the enumeration.

Moreover, why do you call this a "horrendous" style?

I actually see benefits for trailing separators as you avoid the
separator-alignment problem you'd have with trailing separators:

You either have to use a ragged alignment (and in this case the `,`s are
IMHO hard to see as they're visually attached to their entries; one can
add a whitespace before the `,` though)

 something = [
 one,
 thirteen,
 two,
 three
 ]

or if you align the `,`s on the same column to make move separators
visually out of the way, i.e.

 something = [
 one  ,
 thirteen ,
 two  ,
 three
 ]

you may run into a worse diff-problem, once you add an entry that is
longer and would require to realign all `,`s.

That's why I personally consider the "horrendous" style (and I even
catch myself sometimes using this in non-Haskell), i.e.

 something =
 [ one
 , thirteen
 , two
 , three
 ]

to have quit a few benefits in its own right. And while I don't *need*
this extension either, I've been tempted to implement such an extension
myself every now and then when I refactor code and fail to move the `,`s
around, resulting in an at least one additional edit-save-recompile
cycle.

> So I’d really like to see this extension, even if only to conquer the
> aforementioned style.

:-)

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
 ]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-31 Thread Antonio Nikishaev 

> 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.



PSBut this all is indeed a little bikeshedding before we finish the 
“Infrastructure & Communication” thread.



-- 
lelf

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-12 Thread Iavor Diatchki 
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.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-08 Thread Alexander Berntsen 
-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
alexan...@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-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-07 Thread Carter Schonwald 
On Saturday, May 7, 2016, wren romano  wrote:

> 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
> __


>
+1
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-07 Thread wren romano 
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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-07 Thread Carter Schonwald 
On Saturday, May 7, 2016, Carter Schonwald 
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 <_deepf...@feelingofgreen.ru
> > wrote:
>
>> Bardur Arantsson  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
>> 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
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-07 Thread Carter Schonwald 
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 <_deepf...@feelingofgreen.ru> wrote:

> Bardur Arantsson > 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 
> 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

Re: Limber separators

2016-05-07 Thread Kosyrev Serge 
Bardur Arantsson  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
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-07 Thread Alexander Berntsen 
-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
alexan...@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-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-07 Thread Jon Fairbairn 

Alexander Berntsen
 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 jon.fairba...@cl.cam.ac.uk

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-07 Thread David Turner 
On 6 May 2016 20:58, "Cale Gibbard"  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
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-06 Thread Bardur Arantsson 
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
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-06 Thread Alexander Berntsen 
-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
alexan...@plaimi.net
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
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-06 Thread Cale Gibbard 
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
> alexan...@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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-06 Thread Alexander Berntsen 
-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
alexan...@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

Re: Limber separators

2016-05-06 Thread David Luposchainsky 
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



signature.asc
Description: OpenPGP digital signature
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

2016-05-06 Thread Alexander Berntsen 
-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
alexan...@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-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Limber separators

2016-05-06 Thread Alexander Berntsen 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Haskell uses separators for values in a number of syntactic
constructs. It is my understanding of the 2010 report that the
language does however not generally support leading separators, nor
trailing separators, nor both (two exceptions are discussed at the end
of this email). Consequently diffs are bloated, resulting in mental
overhead when viewing and reviewing patches, as well as potential
three-way merge conflicts or worse. A quick example:

[ Foo
, Bar
, Fu
, Baz
]

It is impossible to remove values Foo or Baz with a one line diff. It
is additionally impossible to reasonably add a new value to the top or
bottom of the list.

I want the Haskell' committee to discuss allowing one or more of the
following:

* Leading separators
* Trailing separators
* No separators

The former two, or a combination, is arguably the least invasive
modification, whilst the latter is more sensible as a language
extension for now as it would break code. The latter is furthermore
difficult as the rules are potentially more involved, yielding more
gotchas. My immediate suggestion for the no separators route would be
to use newlines.

The discussion should apply to as many contexts as deemed sensible. It
is arguably insensible to introduce leading or trailing separators
where we would end up with ambiguity, as would be the case with tuple
declarations due to tuple sections. Examples of where it would be
sensible are abundant, and include -- but aren't limited to -- data
types, lists, record fields, pattern guards, and language pragmas.

If leading separators, or trailing separators, or both, are accepted
as the way to go forward, perhaps permit extra separators in general.
I.e. [,,,Foo,,,Bar,,,Fu,,,Baz,,,] is a list with four terms, Foo, Bar,
Fu, and Baz.


Please note that Haskell 2010 already permits trailing commas in
import and export lists, like so:

impspec → ( import1 , … , importn [ , ] ) (n ≥ 0)
exports → ( export1 , … , exportn [ , ] ) (n ≥ 0)

Meaning the following is legal:

import Foo (
  Fu,
  Baz,
)

And the following:

module Foo (
  Fu,
  Baz,
)

Bizarrely, the following is *not* legal:

import Foo (
  Bar (
Fu,
Baz,
  )
)

I.e. impspecs are permitted trailing commas, imports aren't.
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXLJekAAoJENQqWdRUGk8BksEQANHIhsGRaoDuwb6CM3NapElv
XfcSgW5//Vva0/8f//BXUvN2rrfadxcjzr4xKL8CKME9sxlgRJ56RQi+Ai/L0mNZ
h1x0Uqi3dmDzMxF1ROgKlUMjU4CAGqq5MMl3iZTC4vP7NpMUrqodZe7zO9INnP/7
av0x9GPI1SnXc1xocSMew9VA1fzd1tr8e+M73tex1yNC1pr5vI5hKSliofwTBHhW
BAIKVOu3hEBUjhziZkmSPqOZJ4QCJYsMQ6P6ZCnxs7K2vplA3OQC+jOO/vM6MqdZ
iaRrYiqyof3XkeNr7/Z96+6/iKdGIGn4+OsOzrWUMdsJfY/kftb7KJR/tRgfWug9
QMlMjmTfxDkCAlonU2uNwSustcMTJNhq6g4Ymg6k5t7MwojT6dDE0ASAUlOKGbCk
WRvDVLRGaQcn7HF4PWq7RnrP+lvl9OUZr36L4QZrG8ei5v2DN/H30hlT0zzbyp97
yO9yHQZ0TmCt+iAbDi822vRlmfJEH7zRkrsmcHAmiOAsAfvZoaqtSiLK2eiczb1g
V7h1h1ze3i0I+MNf7+Sbzot3kJwW8+3XqZoh2B1oyWgiDlrZhLDDHaEY4yzoPG3E
hdmAOoYx43tnd6LkWhar86CwoxelyKvpXoLNp6JZe+mUAG4qwoa8AIcXglk4KTty
k0M1NEwiPSy+/ymABx/T
=E+MY
-END PGP SIGNATURE-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime