[erlang-questions] question: macro definition

[Robert Virding]

On 15/01/2008, Benjamin Tolputt <bjt@REDACTED> wrote:
>
> Robert Virding wrote:
> > On 15/01/2008, *Ahmed Ali* <ahmed.nawras@REDACTED
> > <mailto:ahmed.nawras@REDACTED>> wrote:
> >
> >
> >     Does (redefining) mean I cannot define a macro with the same name
> >     even though they have different arity?
> >
> >
> > That is exactly what it means. It was a mistake to do it that way. But
> > it could be corrected now if people really want it.
> I would be interested in a quick pros & cons of this. As I understand it
> C/C++ has the same "uniquely named" macro functionality.
>
> As I see it, having macros with arity (i.e. LOG/1 and LOG/2) would be
> the Erlang equivalent of declaring a function as "inline". What
> advantages would this have given I technically could have the equivalent
> of LOG1 & LOG2 macros?
>
> Nto arguing one way or the other, but Robert mentioned it as a mistake
> and I'm curious as to the reasons for and against such a "mistake".
>

Easy, when macros were first requested all that was asked for was a way for
defining constants. I wasn't too convinced of the benefit of adding them at
all so as an added "bonus" (it was a joke) I went the "whole hog" and did a
copy of C macros. Almost a complete copy anyway. That's why they don't
support same name different arity.

It wouldn't really be a problem to add that feature now I don't think it
would actually break any code. Except perhaps just to not catch errors.
Though I doubt it has high priority.

The reason why they work at token level is that this was easier to do and
better provided the functionality that was asked for, i.e. constants. You
can do much cooler things with LISP-like macros but they are "not trivial"
to implement in a language which doesn't have a close connection between
code and data like LISP or Prolog. Just ask those who have tried for Erlang.
Or tried to make a backquote like functionality.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080116/0682fdd5/attachment.htm>