New syntax version

[bluddy]

For OCaml 5.0, I'd love to discuss again the option of bringing back 715. Rather than calling it safe-syntax, we could call it syntax v2, and it would be completely opt-in. The goal is not to insert a whole bunch of wishlist items, but instead, to fix the current issues in the syntax that cause bugs:

• if ... then can terminate only with else, elsif and end (elsif reduces the number of needed ends). This fixes the issue with statements in if clauses causing subtle bugs.
• else and elsif terminate similarly.
• match and function always terminate with end, removing the possible subtle bugs from nested matches.

The syntax would be opt-int: either you pass the syntax 2 option to the compiler, or individual files could include (* syntax: 2 *) as their first line, causing the alternate parser to be chosen. If the syntax becomes popular enough, we can consider making it the default later on.

[dra27]

This could be discussed for 5.x, but it’s too late in the day for 5.0. Would you be able to expand and reference what’s changed since #715 was closed?

[bluddy]

There aren't any major changes conceptually, and much of the point is to make the changes as minimal as possible (as detailed in #715). One thing I've realized over time is that we really want an elsif keyword to avoid the following proliferation of ends:

if x then y
else if z then w
  end
end

and to instead have the cleaner

if x then y
elsif z then w
end

The other thing that would be very helpful for large codebases is to add the file-specific comment

(* syntax: 2 *)

in addition to the compiler directive, making it easy to gradually switch the codebase over to the new syntax.

In general, since that proposal, I've experienced more of the annoying and very subtle bugs caused by the current syntax. IMO it's not appropriate for OCaml, as a safety-oriented language, to have such glaring issues in its syntax. ReasonML has also been able to fix these issues due to its switch to explicit C-style termination.

I also really want to avoid a grab-bag bikeshedding approach where people throw whatever they want into the feature list, such as reversing type parameter order. This isn't about a wishlist - it's about addressing very real issues in the syntax.

[nobrowser]

Safety is important no doubt. But so is lack of noise. In the past few weeks I decided never to write another shell script. There are multiple reasons but one of them is because I don't ever want to type esac or fi again :-) .

In case we change the conditional, I suggest we spell the new keyword elif rather than elsif. That's because elif is the same length as else making code line up.

It is my impression that the problem with the conditional only occurs when it is mixed with sequencing. Is that correct? In that case, consider that we're talking about a functional language after all. Sequencing is supposed to be relatively rare, no?

Lastly, while I know that the function proposal goes with try and match, I really don't like requiring a terminator after function while fun gets a break, so to speak.

All in all, I'm much more inclined to support a modest warning approach than a compulsory change to the syntax, even if such change is gradual over many releases.

[nobrowser]

I went to the bathroom, and like so often, that gave me a fresh thought. :-)

Why not start requiring begin .. end or parentheses around ; sequences? That would be a minor change, could be enforced gradually, and would leave purely functional code unaffected. If it would fix the problematic uses of the conditional, those attributes definitely make me favor it over more intrusive ways like elif.

Then we just need to think of a way to fix the pattern matching constructs, similarly unobtrusively.

[priamfive]

Safety is important no doubt. But so is lack of noise. In the past few weeks I decided never to write another shell script. There are multiple reasons but one of them is because I don't ever want to type esac or fi again :-) .

But I love esac and fi! (Fond memories of Algol 68, not bash!) Makes it easier to track down which construction is missing a terminator, though possibly not so common a problem in Ocaml.

[shindere]

``` match x with | 0 -> 1 | 1 -> 3 | ~ -> x+1 hctam ``` ;-)

[bluddy]

In case we change the conditional, I suggest we spell the new keyword elif rather than elsif. That's because elif is the same length as else making code line up.

That's a good point. I was debating between elsif and elif (which python has), and you provide a good reason for choosing the latter.

It is my impression that the problem with the conditional only occurs when it is mixed with sequencing. Is that correct? In that case, consider that we're talking about a functional language after all. Sequencing is supposed to be relatively rare, no?

No it's a very common issue that creates serious bugs unless you wrap every if..then..else with parentheses or begin/end proactively. See the discussion in the attached PR, and the discussions attached to that PR.

Lastly, while I know that the function proposal goes with try and match, I really don't like requiring a terminator after function while fun gets a break, so to speak.

function does pattern matching, which has issues when adding pattern matching at a deeper level. It may be good to also terminate fun, but as far as I can tell, this is only relevant for aesthetic reasons rather than bug-creating ones. I could be wrong though.

Why not start requiring begin .. end or parentheses around ; sequences? That would be a minor change, could be enforced gradually, and would leave purely functional code unaffected. If it would fix the problematic uses of the conditional, those attributes definitely make me favor it over more intrusive ways like elif.

This is indeed the alternative approach, but it's very far from a minor change -- OCaml supports statements everywhere, and adding a simple printf or a hashtbl operation - even a tiny one - becomes much heavier. I doubt this would receive much support, and it still doesn't take care of matching issues, as you mentioned.

[nobrowser]

To properly fix the pattern matching construct, I feel more creativity is needed. I'll try to think up an alternative proposal, though my past attempts to change the syntax have not been exactly welcomed :-P But that's long forgotten.

[bluddy]

I think it's very important to keep this suggestion restrained. If we open it up to endless bikeshedding, nothing will happen. There are many possible ideas, such as reversing the order of type parameters in OCaml. They make a lot of sense, but they're not essential in terms of fixing real bugs caused by syntax issues. The idea is to keep the proposal clean and simple.

[nobrowser]

@bluddy of course. I mean nothing beyond fixing the pattern matching ambiguity. I just think there might be an alternative to adding keywords.

[nobrowser]

Assume I have an alternative proposal for matchings, and assume I come to support the if .. elif .. else .. end part of the standing proposal, how should I structure my PR or PRs? One PR including if, one PR with matchings only, or 2 separate PRs? (The PRs will likely be massive no matter what.)

[lpw25]

I would recommend not writing any PRs proposing changes to the match or if syntax without some indication from upstream that they will be accepted. It is extremely unlikely that any changes in this area will get merged.

[nobrowser]

@lpw25 : does your "extremely unlikely" assessment change if the proposer is backed by one of the main "industrial" orgs in the community, rather than a lone hacker like myself? Because I myself am content with the syntax as it is, preferring to write in a purely functional style. But I would be quite unhappy to see the existing proposal accepted, so that's my main motivation for working on this.

[dra27]

@nobrowser - OCaml's development really doesn't work that way!

[nobrowser]

@dra27 WDYM "that way"? I hope you mean: all proposals are equal and accepted/rejected on their merits, no matter what the source. But I am not sure that is what you are saying.

All I ask for is peace of mind, please. I want to "look in the mirror" and know I've done everything reasonable to avoid the outcome I fear (cluttering of the language with a bunch of new keywords with little benefit to me).

Thanks.

[bluddy]

I love this suggestion. Writing OCaml, I constantly wish I didn't have to use if...then...else structures at all as they tend to be messy. This is a bigger departure, but it would allow for a lot more simplicity and symmetry. A simple required end at the end of each matching structure (including this new one) would solve the syntax problem.

[shindere]

Yotam Barnoy (2022/08/04 06:23 -0700):

I love this suggestion. Writing OCaml, I constantly wish I didn't have to use `if...then...else` structures at all as they tend to be messy. This is a bigger departure, but it would allow for a lot more simplicity and symmetry.

Cool!

A simple required `end` at the end of each matching structure (including this new one) would solve the syntax problem.

But that raises the backwards compatibility issue. If Pierre's idea can be introduced just by extending the grammar and without breaking existing code, then it oculd be introduced first, and then, almost independently, the `end` suggestion could be examined. But we have also `begin` and I wonder whether it wouldn't be confusing to have ends that do not correspond to a begin.

[bluddy]

I completely support (re)introducing when now.

Personally I think we'll need to transition to an OCaml v2 syntax at some point. The if...then + semicolon footgun is just too serious of an issue to ignore long-term.

[nobrowser]

Pierre's suggestion addresses the if/elsif/elif/.../else issue. He suggesets to use the when construct which, he says, was present in older versions of Caml.

when
| cond1 -> expr1
| cond2 -> expr2
...
| _ -> exprn

Yes! I like this, too. Is someone considering a PR? If not, I can start working on one.

--
Ian

[shindere]

Ian Zimmerman (2022/08/04 07:31 -0700):

> Pierre's suggestion addresses the `if/elsif/elif/.../else` issue. He suggesets to use the `when` construct which, he says, was present in older versions of Caml. > > ``` > when > | cond1 -> expr1 > | cond2 -> expr2 > ... > | _ -> exprn > ``` Yes! I like this, too. Is someone considering a PR? If not, I can start working on one.

I have mixed feelings. On the one hand, it feels like a big, real feature and, as such, frightening. On the other side, for me who spends most of my time doing non-OCaml stuff, build system related tasks, etc., it also sounds cool to work on a language-related thing, for once. Shall I try? Would you accept to let me shoot first and continue the work in case I fail or do not manage to complete it?

[shindere]

Just an implementation detail: do we agree that, at least for the mooment, the first vertical bar, between the "when" keyword and the first conditional expression should be optional, as it is for match, function etc.?

[nobrowser]

Just an implementation detail: do we agree that, at least for the mooment, the first vertical bar, between the "when" keyword and the first conditional expression should be optional, as it is for match, function etc.?

Yes, definitely allow to omit the first bar. @shindere if you want to work on this please go ahead! I'm a bit stressed out right now woth other things. And I suspect it will take more than 1 person in the end, anyway.

There will probably be some parsing conflicts with the existing use of when ...

[shindere]

Ian Zimmerman (2022/08/05 09:43 -0700):

Yes, definitely allow to omit the first bar.

Okay.

@shindere if you want to work on this please go ahead!

I started, and something strange happened. As long as it was about thinking about the implementation, inmy head, the strategy I had in mind was to not modify the parse tree and de-sugar the new when construct to the existing if/then/else, because that felt simpler to me. I thought it would do the job, at least for a proof of oncept and it would always become possible, later, to introduce the appropriate support for the construct at the parse-tree level. But then I started to implemnet and found myself beginning by the modification of the parse tree type. I hope I am not misguided here. If people feel it's not the way, please let me know because I am quite new ot this kind of language extension. Ooe other difficulty I encountered promptly was that I found myself in lack of konledge on which names to give to the different constructs. How should the `when` construct as a whole be called? And then, the when keyword is followed by a list of pairs of expressions. How should a pair be called and how should each expression in the pair be called. As an example: should the whole ocnstruct be called a conditional, and then in each pair the first expression could be called the condition and the second expression the result, and the pair would be called a clause, to distinguish it from the "cases" used in patter-matchings? Would that seem reasonable?

I'm a bit stressed out right now woth other things. And I suspect it will take more than 1 person in the end, anyway.

That's a good point. Obviously I won't be able to come up with a complete and correct implementation by myself. I'll continue then but would be happy to get feedback on the points above.

There's probably be some parsing conflicts with the existing use of `when` ...

I feel prepared, yeah. But I know people who will be hable to help with this bit, I believe. So that's one good example of the feature not being the work of one person alone.

[bluddy]

This should not be a "syntactic sugar" thing IMO. It needs to modify the parse tree, or else tools like ocamlformat will revert the syntax to if. This is the superior syntax IMO.

[shindere]

Yotam Barnoy (2022/08/20 23:17 -0700):

This should not be a "syntactic sugar" thing IMO. It needs to modify the parse tree, or else tools like ocamlformat will revert the syntax to `if`. This is the superior syntax IMO.

Yes, yes. For the long run I agree. It's just that I thought I wcould start with sugar just to open the way to experimenting. But apparently it's not how I started anyway. Also, meanwhiile I think I clarified the names for the different levels of construction. The whole construct could be called a *conditional*. This conditional is actually a list of *clauses*. In turn, each clause is apair whose first component could be called either a *condition* or a *test*, while the second component could be called the clause's *result*. Do such names feel appropriate? Any preference between test and condition?

[bluddy]

I think it makes sense, but you may want to follow the precedents set in the parser and parse tree. Specifically, the new construct is a hybrid of Pexp_ifthenelse which has an expression * expression * expression option, and the case list which is under Pexp_match.

You could then add something like a Pexp_when which takes an (when_case * expression) list, where a when_case can be either a regular expression (perhaps wrapped by a When_expr) or a When_any (which is just the underscore symbol).

[jhwoodyatt]

I'm thinking that @schodibear offered an idea that I think would combine well with the one above by @pierreweis to use the when keyword with a list of condition guards to deal with the problem of nested choice expressions.

[gasche]

At the ML Workshop we had a talk by Lionel Parreaux on what he calls the "Ultimate Conditional Syntax" (UCS), see the ML workshop article (PDF). Parts of the syntax he proposes can express the multi-condition test:

if
  foo then ...
  bar then ...
  baz then ...
  else ...

(Many other features are proposed as part of this UCS, including the ability to capture variables in conditions, so that the form above can subsume match and Agda's and form to match on additional values.)

if foo is
  Some(x) and x is
    Left(_) then "left-defined"
    Right(_) then "right-defined"
  None then "undefined"
``

[github-actions[bot]]

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

[Octachron]

As a quite open discussion on syntax, I will propose to move this to a discussion.