Erlang improvement?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Erlang improvement?

Helmut Enck-Radana-2
At 19:25 19-09-01, Kostis wrote:
>  > There is no ambiguity; to perhaps obfuscate things even more, the
>  > above notation is just "syntactic sugar" for
>[...]
>
>t2(M,F) ->
>   apply(M,F,[bar,42]).

I thought the question was whether f(X):g(Y) should mean f(X):(g(Y)) or
(f(X):g)(Y).

-- Helmut

________________________________

Helmut Enck-Radana
Paradigma Software GmbH
http://www.paradigma-software.de
________________________________



Reply | Threaded
Open this post in threaded view
|

Erlang improvement?

Robert Virding-4
Helmut Enck-Radana <her> writes:

>At 19:25 19-09-01, Kostis wrote:
>>  > There is no ambiguity; to perhaps obfuscate things even more, the
>>  > above notation is just "syntactic sugar" for
>>[...]
>>
>>t2(M,F) ->
>>   apply(M,F,[bar,42]).
>
>I thought the question was whether f(X):g(Y) should mean f(X):(g(Y)) or
>(f(X):g)(Y).

This is indeed what was probably meant.  However if you try to write
f(X):g(Y) you will find that is not allowed.  I did this on purpose.
The main reason being that while is is easy for the parser it can
often be difficult for a human to work out what is meant.  Otherwise
you could get beauties like:

        f(M):g(N):h(O):i(P)

This means that you need parenthesis around the module and function
parts of a remote call if they themselves are calls.  So you would
write:

        (f(X)):g(Y)

Also you can't really create a functional object X:Y as the ':' is
only valid in a call.  It is a bug that the parser allows while
erl_lint in the compiler disallows it.  It is my laziness which has
not fixed the parser to disallow it.

        Robert