[ghc-steering-committee] #477: Unicode ellipsis, recommendation: accept, please vote

[Spiwack, Arnaud]

I haven't changed my opinion. It's a trivial change. The whole discussion
on two versus three dots has not been particularly clarifying for me. It
sounds as though there is no perfect solution there, so I guess a regular
ellipsis is a reasonable choice.

On Tue, Mar 15, 2022 at 6:41 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I really don't have a well-informed opinion here. I'm happy to accept
> provided it doesn't add an unreasonable complexity burden to the
> implementation (which I doubt it will).
>
> Simon
>
> On Tue, 15 Mar 2022 at 15:35, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Commitee!
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/477
>>
>> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
>>
>> It turns out this simple change isn’t so simple after all. Maybe just
>> Wadler’s law again… Anyways, it seems all arguments have been brought
>> before, and it’s up to us to make a decision. A concise summary could
>> be:
>>
>> Ignat suggests that under -XUnicodeSyntax, the `…` symbol can be used
>> instead of `..` (e.g. import Prelude (Maybe(…)), [1…10]). This is
>> roughly a very reasonable thing to do under -XUnicodeSyntax, at least
>> for the former use, where `..` clearly is an ellipsised omission.
>>
>> The wrinkle is the range syntax: Vlad researched that there the two-dot
>> syntax has historic precendent going back to Knuth and is used in other
>> languages, and that it is _not_ just a bad ASCII approximation of a
>> three dot … ellipsis, but really it’s own symbol, and pushed back
>> because of that. He does not contest the use of … in export/import
>> statements, though.
>>
>> A possible rebuttal is that despite the existence of a two-dot-range
>> notation in some contexts, it is not _that_ universal, and it is still
>> a form of omission for which an ellipsis (…) is a semantically suitable
>> symbol.
>>
>> Pragmatically, I’d argue it would be a bad idea to allow … instead of
>> .. only in import/export lists, but not range syntax.
>>
>> So my recommendation is as before (but maybe a bit more weakly): Don’t
>> let perfect get in the way of good and accept the proposal, despite the
>> history aspects of the [1..10] syntax, to improve -XUnicodeSyntax for
>> the Unicode fans out there, and keeping the mapping between Unicode
>> syntax and ASCII syntax in Haskell one-to-one.
>>
>> Vlad said on Github he is still opposed, but more weakly. The existence
>> of this surprisingly long discussion may be an indication that this
>> feature is not worth it.
>>
>> To avoid an out-of-proportion discussion (for a change of that relative
>> now implication), I suggest to simply vote.
>>
>> I have seen +1 from Arnaud, Richard, and SPJ, and a -1 from Vlad. Let
>> me know if any of you changed their mind, and the others: let me know
>> which way you are leaning.
>>
>> Cheers,
>> Joachim
>>
>>
>>
>>
>>
>>
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220316/f11feb23/attachment.html>