[eeps] Request for comments on EEP-24

[Andras Georgy Bekes]

> The deadline for comments on EEP-24 is reached and the conclusion is
> that there are mostly positive comments and no engraving objections.
Hi,

I've sent a mail to eeps@REDACTED with my comments, but it seems that 
it did not reach the list (I cannot find it in the archives).

I suggested the followings: Currently no operators are allowed in module 
attributes, except for F/A in -export(). Example: -myattribute(1+2) is 
not allowed. 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}. This means that F/A will be converted to {'/',F,A}, which 
is against EEP-24, but F/A's are treated specially in -export() 
attributes anyways, and regarding F/A's in other attributes, I can't 
see the advantage of {F,A} over {'/',F,A}. On the other hand, this 
really removes the special treating of the F/A construct.

Waiting for your reactions.

My original mail to eeps@REDACTED is:
-------------------------------------------------------
Subject: Re: [eeps] EEP 24 -- F/N converts to {F,N} in *all* directives
Date: Tuesday 21 October 2008
From: Andras Georgy Bekes <bekesa@REDACTED>
To: eeps@REDACTED

Hi all,

I fully support this eep. We use a parse transformation that should use 
a user-defined module attribute with a list of F/N's, but we can not 
use this notation (until this eep gets accepted).

On the other hand, we should have another custom module attribute, which 
resembles to record definitions, but we can not use such a notation and 
this eep won't help us.

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.

These should be allowed in custom attributes as well, in order to remove 
one more inconsistency. I know allowing the latter in custom attributes 
is nonsensical, but at least the parser should accept it (in order some 
parse transformations could use it), and it should be rejected by the 
compiler.

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 F/N notation had special treatment 
anyways.)

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!

	Georgy

-------------------------------------------------------