[erlang-questions] Orthogonality and Principle of least surprise Was: chained functions

Jakob Praher jakob@REDACTED
Thu Feb 2 00:08:12 CET 2012


Am 01.02.12 22:47, schrieb Robert Virding:
> The problem with your reasoning is that your "functional reference" may refer to many functions. Functions with the same name and a different arity are DIFFERENT functions, one reference cannot refer to them. It is like expecting the "reference" F = module:big also to call not just the function 'big' but also the function 'big_name' because they have the same prefix. They ARE different functions which just happen to have the same name.
I understand this fact. But alltough the reference does not designate
one function, it deterministically designates the intended function: the
function that can be applied to the actual parameters (see below for a
statement on matching against actual argument values as well). Therefore
to my taste it feels redundant. E.g. I know I am calling a function with
one parameter, still I have to pass this information to the references
as well as to the call. Type inference can easily detect the arity, e.g.
the second argument passed to the function map in the example below has
to be a unary function, by the usage of F(X). In such a case type
checking is able to detect errors early - e.g. that a unary function
square is exported from the module math, when passing math:square as the
second argument to map.

In the sense that Erlang can also have different function bodies
dependently defined by pattern matching on the actual argument values
beeing passed, the arity is anyway not the only determiner of the actual
target body of expressions beeing called (even if this is internally
represented as a single function, conceptionally it is not). But here I
guess everybody would find it tedious/strange, if one has to refer to a
function by the signature of its  arguments.

For the future I think even identifying the function to call in case of
currying (if it would be already possible) is mostly deterministic by
knowing that the result value having to be of a certain structure as
well. Anyway the problem of currying also applies to the current
function call expression as well (e.g. module:fun(X). could be
interpreted as calling the unary funciton fun resulting or also currying
on the binary function fun and so on ...).

Best,
Jakob
>
> Robert
>
> ----- Original Message -----
>> Am Mittwoch, 01. Februar 2012 15:04 CET, Alisdair Sullivan
>> <alisdairsullivan@REDACTED> schrieb:
>>  
>>> functions in erlang are identified by their name and their arity
>>>
>>> 'F = module:fun()' is ok because the arity, 0, is implied by the
>>> arguments
>>>
>>> 'F = module:fun' is not okay because it does not refer to a
>>> specific function. you need to tell the compiler which function
>>> you wish to call. hence the 'fun module:fun/n' syntax
>> IMHO it depends what one is trying to achieve. From an operational
>> point of view I am fine with having a "function reference" as
>> something that can be called if applied with concrete arguments.
>> Hence I do not require a funciton object in the sense that it
>> represents the function itself.
>>
>> If one wants to make sure that the right function is targeted one
>> could always write it like: "F = module:fun/N", which is not
>> something I am thinking of.
>>
>> With the exception of currying, where the arity of the function
>> arguments vs the actual arguments differs, it suffices to just apply
>> the actual arguments to the matching function.
>>
>> E.g.
>>
>> map([],_) -> [];
>> map([X|Rest], F) -> [F(X) | map(Rest, F)].
>>
>>> map([1,2,3], math:square).
>> [1,4,9]
>>
>> This is a more lazy / symbolic usage of functions.
>>
>> Best,
>> Jakob
>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>  
>>  
>>  
>>  
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>




More information about the erlang-questions mailing list