[erlang-questions] No Namespace for Macros

Richard O'Keefe ok@REDACTED
Fri Oct 16 05:01:38 CEST 2009

On Oct 15, 2009, at 6:54 PM, sapan shah wrote:
> Erlang does have the concept of namespace for the functions( we do
> lists:map(...))
> Why does it not have this concept for macros?

It does.  It's just that you CAN refer to a function outside its
namespace, but you CAN'T refer to a macro outside its namespace.
> Consider this scenario: I have an application which deals with the  
> value of
> some things. (lets say a house & a car)
> So, I define macros in two different files for the things.
> %%%%valueHouse.hrl
> -define(Value, 10).
> %%%%valueCar.hrl
> -define(Value, 2).

The obvious question is "why make them macros in the first place?"

Another point is that these are include files, *NOT* modules.

If you had

	% value-house.hrl
	value() -> 10.

	% value-car.hrl
	value() -> 2.

neither of these definitions would be associated with anything other
than the module that -included them.  You would not expect

to work.  The namespace is the module, and here both functions would
try to live inside the same module, but they can't.

In the same way, if you do

you end up trying to provide to definitions for the same macro
in the *SAME* name-space, namely the module.  There is here no
difference whatever between functions and macros.

The only difference is that you can -export functions but you
cannot -export macros, so the only way for a macro to be accessible
in some name-space is for it to be defined in that name-space.

> This is just a cooked up example. One may have this kind of need in  
> a big
> application.
> For exapmle, Java supports this (public static final variables).

Absolutely not.  No way.  public static final variables ARE NOT MACROS.
Not even close.  The Erlang equivalent of one of those Java thingies is
a zero-argument exported function.  (Admittedly such a thing cannot be
used in pattern matching, but as you may have noticed, public static
final variables can't be used in pattern matching in Java either.)

Actually, for most purposes, the Erlang equivalent is *really* an atom.

What you *really* want is abstract patterns.

(I seem to say that a lot.)

More information about the erlang-questions mailing list