Named wildcards (extending valid identifier syntax)

[Skyb0rg007]

Giving names to variables is a good way of documenting your code for future readers.
For example, you may have a function MyObj.fold : (int * int * 'a -> 'a) -> 'a -> MyObj.t -> 'a that passes the function a triple of (index, value, accumulator).

fun mySum obj = MyObj.fold (fn (idx, value, acc) => value + acc) 0 obj

If you want to document the fact that idx is not used, it is sometimes good practice to not bind the variable name.
This way a linter can warn for unused variables.

fun mySum obj = MyObj.fold (fn (_, value, acc) => value + acc) 0 obj

But now there is no documentation on what that missing parameter actually meant, since we no longer give it a name.

One option is to add a comment. This is somewhat popular in C++:

fun mySum obj = MyObj.fold (fn (_ (* idx *), value, acc) => value + acc) 0 obj

But a better option is what Haskell, OCaml, Erlang, Prolog, JavaScript and other languages allow: prefix the identifier with an underscore, and make the "unused variable" linter ignore variables with leading underscores.

fun mySum obj = MyObj.fold (fn (_idx, value, acc) => value + acc) 0 obj

This way you maintain the benefits of naming for documentation purposes, but also improves the readability of your code because the reader can immediately know that the variable is not used.

Changes

The simplest method to support this change is to change the wildcard syntax to _[a-zA-Z0-9']*, where _foo is considered a named wildcard no different from _.

Potential Incompatibilities

Currently MLton uses this syntax for language extensions: _address, _build_const, _command_line_const, _const, _export, _import, _overload, _prim, _symbol. These uses seem possible to work around, because each of these extensions only make sense in expression or definition context and these special tokens can fallback to wildcards in pattern syntax.