[erlang-bugs] node type in documentation or API?

[Michael Truog]

Raimo Niskanen wrote:
> On Thu, Jul 02, 2009 at 05:16:51PM -0700, Michael Truog wrote:
>   
>> The documentation is a little ambiguous when it mentions the node type
>> since it uses "node()" instead of "atom()", and this may be on purpose. 
>> If this is on purpose it would be really nice to have a function
>> "erlang:is_node(Node)" for guard tests.  Otherwise, if I put
>> "erlang:is_atom(Node)" in the guard tests, I am making the assumption
>> that node types are always atoms.  I don't know if that is always
>> suppose to be the case since the documentation uses a separate type.
>>
>> Thanks,
>> Michael Truog
>>     
>
> That is a beautiful thought, but very hard to do.
>
> The documentation uses node() for clairty.
>
> We could introduce is_node/1, but making a node a separate
> type in the emulator would break lots of existing code.
> So we would have to warn several release before, and those
> customers that have large (millions of lines of code)
> applications in maintenance would most probably refuse
> such an update, forcing us into two release tracks
> for the lifetime of their products.
>
> The semantics of is_node/1 must also be decided.
> Will it return true for existing nodes, existing
> and old nodes, or existing and old and possible
> future nodes.
>
> It is very unlikely this will ever happen.
>   
I was hoping for something less drastic.  As I understand it, it is good
coding practice to use guards for all types in the function, so errors
are easier to catch and code is easier to optimize (excluding something
like length which could be considered a performance drain).  So, it
seems like it would be nice to have is_node/1 which could just be an
alias for is_atom/1 now, if that is always valid.  I can totally
understand how checking a node's state is complex and having a separate
type is complex.  It just seems like all Erlang native types should have
associated guards for consistencies sake.  I understand why guards for
things like dict or ordict might not make sense (being separate modules
in the stdlib).

Thanks for considering this,
Michael