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

[Richard O'Keefe]

On 20 Oct 2008, at 10:16 pm, Christian wrote:

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

Heck no.

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

OK, so the title was a bit too short.
>
> 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.  :)

{a,2} could be _anything_.
But there is only ever one meaning for a/2 in Erlang.

> What I worry slightly about is this sedimenting as one of those rules
> that add to language complexity.

It doesn't, because we ALREADY have two different notations.
Once people have switched from the {F,N} style to the F/N
style, it will *simplify* the language that people use,
because there will then be only one notation that need be used
to refer to functions.

> While this notation alone is not
> difficult,

It is not a new notation.
It's an old notation allowed in new places.

> together with everything else it adds up as an exception
> that will make it yet another thing to grasp.

No, it *removes* an exception.
"You are always allowed to refer to a function as F/N
  EXCEPT in directives we happened not to think of in time."

> However, as it already
> exists in export and import without seemingly causing much confusion,
> maybe my concern isn't motivated.

The notation was copied from Prolog via Strand88.
There has never been a publicly described version of
Erlang that didn't use it.
>

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

Neither.  The grammar _already_ accepts absolutely any
expression whatever in an attribute.  The build_attribute/2
function then filters this.  For -export and -import there
is a function farity_list/1 that is called to do the
conversion.  For -<attribute>(<term>), the function term/1
is called, which calls normalise/1.

So the entire change is to add this clause to normalise/1:

%% Name/Arity case
normalise({op,_,'/',{atom,_,F},{integer,_,I}}) when I >= 0 ->
     {F,I};

just before the final clause, which raises an exception.
As a context diff,

*** parse1.yrl  Thu Jul 10 13:50:11 2008
--- parse8.yrl  Tue Oct 21 12:57:15 2008
***************
*** 744,749 ****
--- 744,752 ----
   normalise({op,_,'-',{char,_,I}}) -> -I;               %Weird, but  
compatible!
   normalise({op,_,'-',{integer,_,I}}) -> -I;
   normalise({op,_,'-',{float,_,F}}) -> -F;
+ %% Name/Arity case
+ normalise({op,_,'/',{atom,_,F},{integer,_,N}}) when N >= 0 ->
+     {F,N};
   normalise(X) -> erlang:fault({badarg, X}).

   normalise_list([H|T]) ->

That's the whole thing.

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

The same way that the *EXISTING* normalisation rules
	+<number> ==> <number>
do.  Currently,	{a,2} and {a,+2} are treated identically.
Wrangler already has to use its own tokeniser to find out
what the white space is.  If it really preserve minor
details, then it must already have machinery to deal with
+2 -vs- 2 in directives, and presumably that machinery can
be used to handle a/2 -vs- {a,2}.
>
>
> Will i be able to have code like:
>
> foo(X) ->
>   Y = foo/1,
>   {ok, Y}.

No.  The EEP is very clear and specific that this
only applies to DIRECTIVES.

It so happens that this turns out to mean "in precisely
those terms that are expanded by normalise/1", but I didn't
know that when I wrote the EEP.
>
>
> Or will it be contained to where this expansion works?

The EEP says where the expansion applies.
In all directives, where the context does not demand
an expression that will be evaluated.

As it happens, I did consider generalising it to
everywhere that it would work, but decided to keep
it simple.


The main work of this extension is docu