[eeps] EEP 24 -- F/N converts to {F,N} in *all* directives

[Andras Georgy Bekes]

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