[erlang-questions] [erlang-patches] add compiler checked atoms
Tue Feb 14 12:24:41 CET 2012
I think atoms introduced in both -type and -spec should be respected in
this feature. If you want to
guard yourself against a misspelled atom in one -spec you can use -type but
you are not forced to.
And if you introduce an atom in a -spec and never use it in the code then
you could maybe issue a warning for that too.
On Tue, Feb 14, 2012 at 10:47 AM, Richard Carlsson <
> On 02/14/2012 09:44 AM, Kenneth Lundin wrote:
>> 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
>> unacceptable degree.
> Yes, that is probably a better idea: that any atom occurring in a -type
> and/or -spec declaration is implicitly said to be known, and others are
> not. This would be an incentive for people to define types for things like
> the set of messages to a server or the set of atoms allowed as flags to a
> function (or error codes returned from a function).
> The question is, should atoms occurring in -spec declarations be taken as
> implicit "exists"-declarations, or should it only be those in -type? If
> it's only -type that counts, you could get checking of the atoms in -spec
> declarations as well, so you don't spell an atom wrong in the spec for one
> of 3 versions of a function and suddenly that atom is also implicitly
> allowed. I think -type only is the right way.
> I'll see if I can change my patch to do this instead.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions