[erlang-questions] No Namespace for Macros

[Dave Vandervies]

Somebody claiming to be sapan shah wrote:
> On Fri, Oct 16, 2009 at 4:12 AM, Robert Virding <rvirding@REDACTED> wrote:
> 
> > Erlang macros are modeled directly on C macros, the version based on tokens
> > and not on text. And as do C macros Erlang macros only exist within a
> > preprocessor, they have no life of their own outside that. In this sense
> > they are not like functions or variables from other languages.
> >
> > If we do the same thing in C, It surely gives 'redefining macro' as a
> warning (not as an error).
> & it considers the latest definition included in the file.

According to the C standard (well, the public draft of it that I have
a copy of):
--------
6.10.3 Macro replacement 

Constraints 

1 Two replacement lists are identical if and only if the preprocessing
  tokens in both have the same number, ordering, spelling, and white-space
  separation, where all white-space separations are considered identical.

2 An identifier currently defined as an object-like macro shall not be
  redefined by another #define preprocessing directive unless the
  second definition is an object-like macro definition and the two
  replacement lists are identical. Likewise, an identifier currently
  defined as a function-like macro shall not be redefined by another
  #define preprocessing directive unless the second definition is a
  function-like macro definition that has the same number and spelling
  of parameters, and the two replacement lists are identical.

[...]
--------
Without getting into C language lawyering, the violation of a "shall"
in a "constraints" section is the closest thing the C language (as
opposed to a particular implementation) has to a fatal error.  So, your
compiler might be willing to accept it, but that doesn't really mean much
(and if it claims to be a C compiler it's required to at the very least
issue a warning).

In any case, why is arbitrarily choosing the last (or first) definition
instead of failing desireable?  If the compiler accepts one definition,
anything that depends on the meaning attached to the other definition(s)
is now silently broken.
A C compiler can get away with that, since C has a long and honorable
tradition of giving programmers enough rope to hang themselves and
then some, but even the authors of the C standard don't seem to think
it SHOULD behave that way.  So why should other languages do anything
other than issue a diagnostic and refuse to complete the compilation?


dave

-- 
Dave Vandervies
dj3vande@REDACTED

Plan your future!  Make God laugh!