[erlang-questions] [eeps] Request for comments on EEP-24

Richard O'Keefe <>
Thu Oct 30 22:06:11 CET 2008

On 31 Oct 2008, at 12:14 am, Andras Georgy Bekes wrote:
> I suggested the followings: Currently no operators are allowed in  
> module
> attributes,

This isn't _quite_ true:
unary + and unary - are allowed in front of numbers.

>  I proposed to allow every standard operator in attributes,
> and each X op Y subexpression in an attribute to be converted to
> {'op',X,Y}.

The question is WHY?
Why do you want to be able to write
as well as
What is the advantage of allowing expression syntax
for things that are not, and certainly will not be
evaluated as, expressions?

The thing about F/A in (some) existing attributes is
it does not mean division and never has.  On the
contrary, it has always been converted to {F,A} for
processing by downstream tools.

Changing F/A to {'/',F,A} will certainly break downstream

The advantage of {F,A} over {'/',F,A} is that the former
is what the downstream tools are already expecting.

> The -record/2 attribute has two properties that can not be done with
> custom attributes:
> - it has arity 2
> - it can contain "fieldname=DefaultValue" like stuff.

It would have been nice if system attributes
and user attributes were always distinguishable.
For one thing, the last time I checked what attributes
were used in an Erlang/OTP release, one of them
was 'behavoiur'.

Perhaps another EEP could be considered,
with some kind of extended user-defined attributes
beginning with a + sign, and a promise that there
will never be any system-defined + attributes.

We'd still have the problem of distinguishing between
  - this is a +attribute containing e/1 and it is supposed
    to refer to the local e/1 function
  - this is a +attribute containing e/1 but it was meant to
    be the expression 4/1 (4 and e being neighbours on the

> A different solution would be not to reject it by the compiler but to
> convert X = Y to {'=',X,Y}, and generalizing the idea, every X op Y
> could be converted to {'op',X,Y}. This implies that F/N should be
> converted to {'/',F,N}, which sounds bad, but the compiler could still
> convert it to {F,N} when building the exports list for the
> module_info/0,1 functions.

The point is that it needs to {F,N} for things *other than*
export lists.

> Parse transformations are so powerful, but on the other hand are so
> limited because of the parser accepts only a very limited set of
> operators and only in some places... Something should be done to
> improve the consistency of the language!

Something along the lines of
<custom attribute> ::= '+' <function call>.
might do the job.

What is the problem for which you wanted custom attributes
with arity higher than 1 and containing operators?

More information about the erlang-questions mailing list