[erlang-questions] [erlang-patches] add compiler checked atoms
Sun Feb 5 22:34:45 CET 2012
This is very cool. It could help document complex code by making atom usage more transparent within the module, while also preventing errors. I mention the documentation part, since having the atom declaration gives the opportunity for comments specific to that atom declaration (so you could have atom declarations as logical groupings, similar to what is commonly done for export declarations). Do atoms used within the spec declarations need to be mentioned within the atom declaration when using this compiler flag? That might bring in a lot of external module atom dependencies, which might be counter-productive.
On 02/05/2012 01:15 PM, Richard Carlsson wrote:
> 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 meaning.
> 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
More information about the erlang-questions