I did not find any legitimate use of "can not", however skipped
changing e.g RFCs archived in the source tree.

This adds optional names to fun expressions. A named fun expression
is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse.

If a fun expression has a name, it must be present and be the same in
every of its clauses. The function name shadows the environment of the
expression shadowing the environment and it is shadowed by the
environment of the clauses' arguments. An unused function name triggers
a warning unless it is prefixed by _, just as every variable.
Variable _ is allowed as a function name.

It is not an error to put a named function in a record field default
value.

When transforming to Core Erlang, the named fun Fun is changed into
the following expression:

    letrec 'Fun'/Arity =
               fun (Args) ->
                       let <Fun> = 'Fun'/Arity
                       in Case
    in 'Fun'/Arity

where Args is the list of arguments of 'Fun'/Arity and Case the
Core Erlang expression corresponding to the clauses of Fun.

This transformation allows us to entirely skip any k_var to k_local
transformation in the fun's clauses bodies.

While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.