Eric, If you use a compose key on Linux, chances are that ellipsis is bound to `compose-.-.`. I don't think the two-point ellipsis is typically bound to anything. On Emacs, input methods are easily extensible, but if you use Company Math to write unicode symbols (which is an autocompletion-based approach), which I've never figured out how to configure, then you will have ellipsis bound on `\ldots`, but no two-point ellipsis. If someone has insight about why the syntax was chosen to be two dots rather than three, originally. I still think that it could inform this discussion. On Fri, Feb 25, 2022 at 2:49 AM Eric Seidel wrote:

I agree it's strange to use a three dot unicode ellipsis but a two dot ascii ellipsis.

Joachim, as someone who likes to use unicode in Haskell, is there a reason to think that the two dot ellipsis would be more cumbersome to type? Maybe emacs unicode modes or something?

...

-1 from me.

The proposed (… U+2026) is three dots, so it could be the UnicodeSyntax equivalent to three ASCII dots. However, Haskell’s range notation is two ASCII dots.

Personally I use three dots to indicate omissions in the source text,

On Tue, Feb 15, 2022, at 14:37, Vladislav Zavialov (int-index) wrote: like this:

...

f x = …

So that is the meaning I’d like to reserve for three dots, not ranges.

The proposal could use ‥ U+2025 instead.

- Vlad

...

On 15 Feb 2022, at 14:27, Joachim Breitner

wrote:

...

...

Dear Committee,

Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov, and I’m shepherding it myself.

https://github.com/ghc-proposals/ghc-proposals/pull/477

https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477...

...

This is a very small proposal that lets GHC understand the nice Unicode syntax `…` in places where in ASCII world we have .., under -XUnicodeSyntax.

I am fond of Unicode in general, and I expect that users of - XUnicodeSyntax expect this to work, and therefore recommend acceptance of this proposal.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

My -1 is firm. After some digging, I found out that the two dots are the intended notation, not just a shorthand for three dots. If you look at "Ronald L. Graham, Donald E. Knuth, and Oren Patashnik. Concrete Mathematics. Addison–Wesley, second edition, 1994”, you will find the following passage: For our next problem let's consider a handy new notation, suggested by C. A. R. Hoare and Lyle Ramshaw, for intervals of the real line: [α .. β] denotes the set of real numbers x such that α ≤ x ≤ β. This set is called a closed interval because it contains both endpoints α and β. The interval containing neither endpoint, denoted by (α .. β), consists of all x such that α < x < β; this is called an open interval. The book is typeset beautifully, and I believe they could’ve used three dots if they wanted, but they used two. Since then, the Hoare-Ramshaw interval notation has been incorporated into various programming languages, including Pascal and Haskell. I have no idea why the proposal uses three dots, actually. - Vlad

On 1 Mar 2022, at 17:42, Joachim Breitner wrote:

Hi,

it’s a worthwhile observation that we (somewhat oddly) use a two-dot ellipsis in ASCII-Haskell, and Artem took this up on Github to ponder if we should allow ASCII ... as well, but I am not convinced. I wrote on the Github thread:

...

Hmm, I am not sure I agree that it's confusing. At least to me, from the start when I saw Haskell, the ascii .. meant what's \ldots in LaTeX, and what I tend to write as three close-to-each other dots on paper and is semantically an ellipsis, which in Unicode has a codepoint with that names that in most fonts looks like what you expect it to…

So the .. is an ASCII cludge like all others (probably because ... is unnecessarily wide).

The analogue is \ for λ - just because the left leg is missing we wouldn't use a unrelated look-alike like \ for the unicode variant, nor ask to be able to write ,\ in ASCII for a better approximation of the real letter.

TL;DR: no need to change ASCII-Haskell, and let's use the semantically correct ellipsis symbol in Unicode-Haskell.

Vlad, how firm is your -1? If you feel strongly enough about it (which is of course absolutely fine), I’d maybe just put this up for a vote? It’s a mostly aesthetical, superficial change where voting may be more efficient than long discussions.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I find it hard to care a great deal about this, but I appreciate all the effort you and others have gone to to try to find the right solution. +0.5 Cheers Simon On Tue, 15 Mar 2022 at 15:35, Joachim Breitner wrote:

Dear Commitee!

https://github.com/ghc-proposals/ghc-proposals/pull/477

https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477...

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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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@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 wrote:

...

Dear Commitee!

https://github.com/ghc-proposals/ghc-proposals/pull/477

https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477...

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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee