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

[Christian]

1) Reading the EEP, my first impression was that F/N notation would be
deprecated/removed and that {F,N} would be required everywhere. And
people would need to do this to their code-base.

Perhaps "Allow F/N notation as shorthand for {F,N} in all directives,
not only in -export() and -import()".



2) "The improvement in readability is dramatic."

I do not find the improvement to be dramatic, but i find using such
language in a EEP to be dramatic.  :)

I mean, yes, it looks more succinct and there is less noisy curly brackets.

What I worry slightly about is this sedimenting as one of those rules
that add to language complexity. While this notation alone is not
difficult, together with everything else it adds up as an exception
that will make it yet another thing to grasp. However, as it already
exists in export and import without seemingly causing much confusion,
maybe my concern isn't motivated.

( However, look at how much confusion guards cause just because they
look like function calls, but you cant call functions.  A similar
thing is how people define a function called square and expect
lists:map(square, [1,2,3,4]) to work.    Robert Virding consider it a
feature that term construction and term patterns look the same, i.e. X
= <<Foo:64/integer>>, <<Bar:64/integer>> = X, it is a symmetry that
makes it easier to grasp.  )



3) Reference Implementation

Where would this be implemented, in the grammar making the tokens
atom, '/' and integer reduce to a 2-tuple of atom and integer? As a
parse transform turning the parse tree of a float division on a
literal atom and positive integer into a 2-tuple?

How does it affect the needs of tools like wrangler that need to have
identity in unparse(parse(Code))-like operations, so that whitespace
and other notation is kept ?

Will i be able to have code like:

foo(X) ->
   Y = foo/1,
   {ok, Y}.

Or will it be contained to where this expansion works?