[eeps] Request for comments on EEP-24

[Richard O'Keefe]

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
	now+then
as well as
	{'+',now,then}
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
tools.

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
    keyboard).
>

> 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?