[erlang-questions] No Namespace for Macros

[Richard O'Keefe]

On Oct 16, 2009, at 5:13 PM, sapan shah wrote:
> 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???

Several of the Erlang developers had had experience with Lisp before
developing Erlang.  I have had enough experience with hot-loading Lisp
code that used macros NEVER TO WANT TO GO THERE AGAIN.  (In particular,
a certain integrated development environment which preceded the
adoption of the buzz-phrase IDE let you get yourself into a state in
which there was *no* consistent load order.)  It's one of the reasons
why Quintus, who wanted macros themselves, resolutely ignored customer
requests for macros in Prolog.  The "feature" was mainly useful for
shooting yourself in the throat.

Macros are a feature that should never have been in Erlang in the first
place.  (With LFE, there's an argument for them.  With plain Erlang,  
not.)

You may have noticed that C doesn't export macros either.
For the same reason:  macros are a parse-time-ONLY construction;
there simply isn't anything *to* export in the cpp model.

Always remember that one of the major features for Erlang has always
been its ability to dynamically load and unload modules, and if anything
creates amazingly strong and amazingly nasty coupling between modules,
macros do.

In Erlang at the moment, we have *untracked* *indirect* coupling between
modules that -include the same .hrl file.  This is just one of many  
reasons
why cpp-style macros passed their use-by date a decade or so before they
were adopted.

> 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 have written about abstract patterns frequently in this mailing list;
search the archives.  There's an EEP for a simplified proposal,
http://www.erlang.org/eeps/eep-0029.html

Macros give you three things:

  A. The ability to define things that act like functions.
     For this purpose, it's better to define functions, and tell the
     compiler to inline them.  (That's why C++ has 'inline'.  Erlang
     has inline declarations too.)

  B. The ability to define things that act like constants and other
     patterns, and the ability to write quasi-functional things that
     can be used in guards.
     Abstract patterns do this.

     Abstract patterns are function-like things that would have a
     function-like representation in a .beam function, and could be
     imported and -exported.

     In your example, something like
	-module(house).
	-export([...,#value/0]).
	#value() -> 20.
	...

	-module(car).
	-export([...,#value/0]).
	#value() -> 10.
	...
     or whatever the magic numbers were, would do the job.  You'd be
     able to use #house:value() and #car:value() in patterns as well
     as expressions.

  C. The ability to do things that warp the syntax of the language
     beyond recognition.  Want ?BEGIN ... ?END with local variables?
	-define(BEGIN, (fun () ->).
	-define(END,   end)()).
	zum(X) -> ?BEGIN Y = X+1, Y*2 ?END.
     It is an advantage not to be able to do this.