I'm not a fan of using ordinary operators for extensions. You could use #508 instead, or at least explicitly reserve some operators for use with extensions (IIRC this is how ## works). The choice of precedence level seems a bad idea, much more likely to cause issues than just using the precedence level of ;.

I'm not a fan of using ordinary operators for extensions. You could use #508 instead, or at least explicitly reserve some operators for use with extensions (IIRC this is how ## works). The choice of precedence level seems a bad idea, much more likely to cause issues than just using the precedence level of ;.

It may be a good idea to reserve it for extensions; I added a check in env.ml, but took it out for no good reason. It's a matter of taste, but I think ;%ext makes the code look messy, so one of the motivations for this PR is to provide an alternative which looks more like a regular operator.

I disagree about the precedence level, since the level of ; causes inconsistent grouping when mixing conditions with let, and providing an opt-out from those issues is the second motivation for this PR.

Added: For those who haven't followed the "safe-syntax" discussion, the main issue as as follows. Consider the code

if ... then
   ...
else
   stmt1 ();
stmt2 ()

This works as suggested by the indentation, but if we insert a let ... in before stmt1 (), then stmt2 () becomes part of the else clause, since let effectively acts as a start delimiter with a missing end delimiter, though it's not terminated by ;. The issue also occurs for then then clause.

I don't disagree that it would be a better precedence level for ;, however it's obviously too late to change that. Having bind/map operators that look and behave like ; but with a different precedence is going to cause confusion and subtle bugs. Same goes for having both -; and ; which differ only in precedence -- if you miss a - by accident you are going to get a bug that only shows up at run-time.

I see your point about confusing -; and ; since it's prone to the same silent acceptance from the compiler as the else-let gotcha. A remedy, though a radical one, may be for the PPX to reject occurrences of ;.

Added: This linting behaviour may need to come first in the PPX pipeline, since it may not be possible to tell if a ; occurs in source code or is generated by a PPX.

Two years later, this proposal still lacks support, the precedence issue pointed by @lpw25 is a killer, and the LWT PPX grew additional syntaxes for sequencing. I move to close this PR.