[erlang-questions] No Namespace for Macros

[sapan shah]

On Fri, Oct 16, 2009 at 8:31 AM, Richard O'Keefe <ok@REDACTED> wrote:

>
> 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
>
>        ...
>        -include('value-house.hrl').
>        -include('value-car.hrl').
>        ...
> 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
>
>        ...
>        -include('valueHouse.hrl').
>        -include('valueCar.hrl').
>        ...
> 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.
>
Yes, I got this point. You can export functions but not macros... but,
Why did the erlang developer not give -export functionality to macros, What
was it that restricted them???


>
>>
>  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.)
>
>
Sure, I missed this part. public static final variables are sort of consts
not macros.


> Actually, for most purposes, the Erlang equivalent is *really* an atom.
>
> What you *really* want is abstract patterns.
>

I did not get this part. It would be very nice if you can elaborate more on
this.


> (I seem to say that a lot.)
>
>
>


-- 
Regards,
Sapan Shah