Update lexical analysis for the mod keyword

[roboz0r]

This does not appear to be covered by an RFC but matches the F# compiler behavior.

[Martin521]

This is all true, but I wonder if, in view of this discussion, we should replace the last sentence by something like "A future FSharp.Core version may add a definition for the mod operator."
And omit the usage example.

[roboz0r]

I think that's a fine change. I'm pretty confident that even if a default implementation for mod was provided it could still be redefined like how % can be overridden too.

[Martin521]

Hmm. I am still not sure. The only reason to not deprecate mod was its potential use as an alternative modulus operator. If we move it now to the list of keywords, it would be the only non-symbolic operator in F# and we would also need to change places like this one.

I'd love to hear the core team on this.
@T-Gro @vzarytovskii

[T-Gro]

The spec should not be bothered with a hypothetical feature IMO, it should describe the language as is.

[Martin521]

The spec should not be bothered with a hypothetical feature IMO, it should describe the language as is.

@T-Gro
Thanks for the feedback. I am still not sure, though, what this means.

This is the current state:

• The 4.1 spec does not list mod as keyword, but only as deprecated ML compatibility feature in chapter 19.
• The compiler recognizes mod as operator.
• This language suggestion (if I understand it correctly) will deprecate its use as operator and keep it as reserved keyword.

Which one of the following options would you support?

1. Keep mod in chapter 19.
2. In view of the above mentioned language suggestion, add mod to the list of reserved keywords, but don't mention it is an operator (because that will be deprecated).
3. Acknowledge the current compiler behavior by adding mod to the list of F# keywords in chapter 3.4 and mention that it is the only non-symbolic operator in F# and that it is user-definable.