[erlang-questions] [erlang-patches] add compiler checked atoms
Tue Feb 14 09:44:14 CET 2012
I don't think this is a good way to introduce declared atoms.
We already have the -type and -spec notation for definition of
types and function signatures which are then used by Dialyzer for type
I don't think we should introduce yet another notation that is not
harmonized with -type and -spec.
It is already possible to declare atoms in -type and -spec. Why not use
this already present notation and add
optional checking of atoms against declared atoms inside -type and -spec
With the suggested -atom declaration we will probably get the same atoms
declared 2 times with different notations and I think that
will clutter down the code with redundant information to an
/Kenneth, Erlang/OTP Ericsson
On Sun, Feb 5, 2012 at 10:15 PM, Richard Carlsson <
> Sorry, pressed send too soon in the last attempt. Here is the code:
> git fetch :richcarl/otp.**git warn-unknown-atom
> Here is a suggested patch to the compiler, that I'm throwing out there as
> a request for comments. In any large code base, it can be hard to maintain
> atom hygiene - you may have hidden errors due to misspelled atoms, people
> may be adding atoms without much thought, and it can be hard to track which
> atoms are being used where and for what (e.g., atoms used for options,
> error indicators, message tags, callback module and function names, etc.
> This allows you to declare your atoms like so:
> -atoms([foo, bar]).
> You can have any number of such declarations, and an atom may occur
> multiple times and/or in different declarations - it's the union of known
> atoms that matters. Note that this declaration is backwards compatible; the
> current compiler will accept it as a generic attribute with no particular
> If you specify the compiler option `warn_unused_atom' when compiling a
> module (you can put `-compile([warn_unused_atom]).**' in the module if
> you want to enable the checking in that module only), you will get a
> warning for each atom that has not been explicitly declared. The compiler
> knows about standard atoms such as `ok', `true', `false', `undefined' etc.,
> and it does not check function and module names in calls, or record names
> and fields of records, since these are checked in other ways already.
> I don't think this addition warrants an EEP, since it doesn't change the
> language as such; it only adds a backwards compatible feature to the
> compiler. However, I'd like to get some initial feedback before I bother to
> update the documentation and submit it as a full patch.
> erlang-patches mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions