[erlang-questions] [erlang-patches] add compiler checked atoms

[Richard Carlsson]

On 02/05/2012 10:34 PM, Michael Truog wrote:
> 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.

No, atoms occurring in -spec and -type declarations are not checked. As 
you say, that could force you to declare a lot more atoms than you want. 
You'll have to run Dialyzer to check the consistency of specs.

What you mention about groupings of atoms is exactly the sort of thing I 
had in mind. Here are some examples from eunit, which I used as a test 
bed for this feature:

%% used in options
-atoms([verbose, report, no_tty, event_log, enqueue, eunit_test_suffix,
         eunit_generator_suffix, eunit_export_suffix]).

%% atoms used in test representations
-atoms([module, application, file, dir, generator, with, local, spawn,
         local, remote, timeout, inorder, inparallel, setup, node,
         foreach, foreachx]).

%% used by erlang:fun_info/2
-atoms([module, name, type, local, external, arity]).

%% used in I/O stream messages
-atoms([io_request, io_reply, put_chars, get_chars, get_line, get_until,
         eof, getopts, setopts, get_geometry, columns, rows, enotsup,
         requests, request]).

%% used in file_monitor server messages
-atoms([monitor, demonitor, automonitor, set_interval, get_interval,
         stop, poll, enable_poll]).

Some of these, you'd put in some header file shared between several of 
your modules, but atoms only used in one module should be declared in 
that module, to keep the checking as tight as possible.

The explicit declaration and grouping of atoms makes it easy to find 
which modules actually use a particular atom, and for what. This can 
otherwise be very hard to figure out. If you've ever tried to use grep 
to find all places in stdlib where the atom `gen' occurs in the gen_... 
modules (it's hardcoded at various points as a callback module name), 
you know the sort of pain I'm talking about.

    /Richard