[eeps] Request for comments on EEP-24

[Andras Georgy Bekes]

> What is the advantage of allowing expression syntax
> for things that are not, and certainly will not be
> evaluated as, expressions?
As I stated, I primarily asked for being able to use = in 
custom attributes, as we need to have a custom attribute that is 
syntactically the same as -record/2 except for its name.

I requested that if the F/A syntax will be allowed in attributes, also 
allow X=Y syntax. At least accept it by the parser (and maybe reject it 
at a later phase of compilation).

I suggested allowing every standard operator JUST in order to remove the 
special treatment of F/A (and X=Y).

If you think that converting every X op Y to {'op',X,Y} is a bad idea, 
I'm quite happy if the parser accepts X op Y and they're rejected at a 
later phase of compilation. But I already told this. I just want to 
write X=Y in a module attribute and use it by a parse transformation. 
But maybe other operators will be useful (for someone else), who knows?

If the parser accepts every operator in module attributes, and later the 
compiler transforms F/A to {F,A} and rejects everything else, I'm happy 
with that. But don't settle with the current proposal, which states in 
the first paragraph: "The parser will convert this [i.e. F/N] to the 
existing {F,N}..."

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

For defining something that is not a record, but the syntax for defining 
a record is perfectly good for it (except for the 'record' name). The 
attribute will be used by a parse transform.

Again, I'd be quite happy if the parser accepts module attributes with 
arity >1, even if they are rejected later.

	Georgy