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

[Ulf Wiger]

The suggestion was to make this change in all *directives*.

I agree that this should be done, and have on several occasions
been frustrated that I can't provide user-defined directives that are
as readable as the built-in ones.

I also agree that it wasn't entirely clear at first what the EEP actually
suggested. To us who don't have English as a native language,
perhaps EEPs should strive to be very explicit. I didn't find the
difference in the examples so dramatic that I could tell without
doubt which one the author preferred.  (:

So in the interest of clarity:

-module(test).

-export([foo/1]).
-deprecated([{foo,1}]).  % user-defined directive

foo(X) ->
    {foo,X}.

works, but neither
-export([{foo,1}])    % [1]
nor
-deprecated([foo/1]) % [2]
does.

[2] should be allowed, while [1] arguably doesn't contribute much.

BR,
Ulf W

2008/10/20 Christian <chsu79@REDACTED>:
> 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?
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://www.erlang.org/mailman/listinfo/eeps
>