search

gfngfn / SATySFi

A statically-typed, functional typesetting system
GNU Lesser General Public License v3.0
1.16k stars 82 forks source link

Switch to comma-separated lists? #50

Closed qnighy closed 6 years ago

qnighy commented 6 years ago

Semicolon-separated lists [a; b; c] are a common pitfall in OCaml. As SATySFi requires parentheses on tuples (a, b), don't we switch to comma-separated lists [a, b, c]?

Pros:

Possible cons I came up so far:

nyuichi commented 6 years ago

I think this just leads to confusion. IMHO, keeping the syntax consistent with OCaml as much as possible is more helpful. I might agree if you mean you make both ; and , acceptable as separators for lists.

qnighy commented 6 years ago

I'm against having two different syntaxes with almost exactly the same functionalities. Keeping ; seems far better than having both.

However, keeping SATySFi (program part) consistent with OCaml is less important than keeping it (block/inline part) consistent with LaTeX. SATySFi already has several bikesheddy differences such as let-rec and [a,b,c] would just add one to them.

gfngfn commented 6 years ago

Thanks for suggestion.

In my humble opinion, at least for now, I’m not so willing to modify [a; b; c]-syntax to [a, b, c]. I would like to allow both [a; b; c] and [a; b; c;], and the modification of [a; b; c] into [a, b, c] results in allowing syntax like [a, b, c,], which looks somewhat unnatural. In other words, the symbol , is likely to be used only as a delimiter (whilst ; tends to be used not only as a delimiter but as a terminator), and thus using , as a terminator seems awkward.

nyuichi commented 6 years ago

I'm against having two different syntaxes with almost exactly the same functionalities. Keeping ; seems far better than having both.

I think it is not a very bad idea. It satisfies all requirements you listed up in Pros/Cons above except "The symbol ; will be free".

However, keeping SATySFi (program part) consistent with OCaml is less important than keeping it (block/inline part) consistent with LaTeX. SATySFi already has several bikesheddy differences such as let-rec and [a,b,c] would just add one to them.

I personally actually prefer ,. But I don't think we gain much from this breaking change. It would be less surprising to people not used to ocaml, but much more to who know ocaml.

qnighy commented 6 years ago

In my humble opinion, at least for now, I’m not so willing to modify [a; b; c]-syntax to [a, b, c]. I would like to allow both [a; b; c] and [a; b; c;], and the modification of [a; b; c] into [a, b, c] results in allowing syntax like [a, b, c,], which looks somewhat unnatural. In other words, the symbol , is likely to be used only as a delimiter (whilst ; tends to be used not only as a delimiter but as a terminator), and thus using , as a terminator seems awkward.

Perhaps I'm too influenced by Python and Rust, that I see [a, b, c,] as natural. Also I misunderstood that SATySFi already implements (a, b, c,) (but it doesn't, right? I'm in favor of allowing it, too)

I personally actually prefer ,. But I don't think we gain much from this breaking change. It would be less surprising to people not used to ocaml, but much more to who know ocaml.

I suppose that most of the expected users are from non-OCaml background, aren't they? I agree that we should respect backward compatibility, too. At last, it depends on how backward compatibility and OCaml compatibility are important at this stage.

nyuichi commented 6 years ago

Perhaps I'm too influenced by Python and Rust, that I see [a, b, c,] as natural. Also I misunderstood that SATySFi already implements (a, b, c,) (but it doesn't, right? I'm in favor of allowing it, too)

What is natural is a matter of personal preference. And if we accept this type of change once, we would need to accept every kind of change someone wants to have. (That is why this is a bikeshed.)

I suppose that most of the expected users are from non-OCaml background, aren't they? I agree that we should respect backward compatibility, too. At last, it depends on how backward compatibility and OCaml compatibility are important at this stage.

I guess to who don't know OCaml at all the syntax of satysfi should look completely strange. And if so, is it a subtle difference whether the separator is denoted by a comma or a semicolon?

qnighy commented 6 years ago

What is natural is a matter of personal preference.

Yes, therefore naturality doesn't support ; for the [a; b; c;] reason.

And if we accept this type of change once, we would need to accept every kind of change someone wants to have. (That is why this is a bikeshed.)

I agree that this is the very bikeshed, but we still don't need to accept every kind of change. I insist on this change because I think that , is more consistent and that SATySFi is still at its early stage. Still I'm willing to respect SATySFi's breaking change policy if any.

I guess to who don't know OCaml at all the syntax of satysfi should look completely strange. And if so, is it a subtle difference whether the separator is denoted by a comma or a semicolon?

I admit the former part to some degree... Still I think uniform separators are helpful to foreigners, as they will need to remember less. If the syntax were really completely strange that uniformity of separators is too subtle, then shouldn't we consider overhauling the whole syntax instead?

Actually, I don't think of OCaml-like syntaxes as "completely" strange nowadays. let/val keywords (often with patterns) are everywhere. There are expression-based languages like Ruby and Haskell. Types are often optional and placed after variable names.

Semicolon-separated lists are a remaining weirdness, which no (or a few) new languages chose to borrow.

mt-caret commented 6 years ago

I don't really have an opinion on which is better, but I think the fact that ReasonML went with commas does have some significance: https://reasonml.github.io/docs/en/list-and-array.html

On a related note, it would be great if @gfngfn can put in words where he wants SATySFi to go. For example, Evan Czaplicki (the author of Elm) prioritizes what he calls "user focused design" with an emphasis on making the learning curve as gentle as possible; as a result, decisions regarding the design of Elm can be evaluated on some kind of criteria instead of descending into bikeshedding.

Evan's excellent talk on Elm and "user focused design": https://www.youtube.com/watch?v=oYk8CKH7OhE

nyuichi commented 6 years ago

I agree that this is the very bikeshed, but we still don't need to accept every kind of change. I insist on this change because I think that , is more consistent and that SATySFi is still at its early stage. Still I'm willing to respect SATySFi's breaking change policy if any.

I don’t see why this bikeshed is an exception. Consistency is also a personal opinion, and whether we need such a consistency between tuples and lists is also a matter of preference. Moreover, gfn-san thinks that we should not treat them equally as lists may have trailing delimeters while tuples not. I always want be a supporter of rational suggestions, and I don’t think this change clearly improves something or resolves existing, concrete problems (in typesetting).

Although I don’t think this specific change should be merged, I would like to support you if you open an issue to discuss the overall language design changes. I just don’t like to have a bikeshed issue per feature, because language consistency would be broken if we repeat specific small changes. (Plus, I as said earlier, once such a specific opinion is accepted, the spec will be out of control.)

qnighy commented 6 years ago

Although I don’t think this specific change should be merged, I would like to support you if you open an issue to discuss the overall language design changes. I just don’t like to have a bikeshed issue per feature, because language consistency would be broken if we repeat specific small changes. (Plus, I as said earlier, once such a specific opinion is accepted, the spec will be out of control.)

Hm, seems reasonable to me. I'll perhaps prepare a more elaborate proposal. Thank you for the suggestion.

I'm closing this #50 and #51 in favor of it. Feel free to ask me if someone wants to reopen these issues.