<div>The following concepts are functions or things that can be interpreted as functions:</div><div><br></div><ol><li>fun([Args]) -> ... end (declared in the shell / eval'd)</li><li>fun([Args]) -> ... end (compiled)</li>
<li>fun Name/Arity</li><li>fun Mod:Name/Arity</li><li>{Mod, Fun}(Args) (to be deprecated)</li><li><div>ModAsVariable:FunAsVariable()</div></li><li>FunAsVariable()</li><li>apply(Fun, Args)</li><li>apply(Mod, Fun, Args) </li>
</ol><div><br></div><div>In the case of the two first ones, the scope of the function depends on where it's coming from and so I can expect the call to be local.</div><div><br></div><div>For the 3rd and 4th ones, there is a very clear distinction between a local call and a fully qualified call. The module name is obvious, and the arity lets me know I'm pointing to a known function, and not just a name.</div>
<div><br></div><div>For the 5th and 6th ones, there is no doubt about whether I'm declaring something to be a local or a fully qualified call. It's going to be the latter.</div><div><br></div><div>For the 7th case, we have a funny possibility. It looks like what we're doing is defining a local call, but the result is entirely depending on whether I'm passing in {Mod,Fun}, a fun, fun Name/Arity, fun Mod:Name/arity, etc. This is an entirely transparent way to make any kind of call, as long as we know how many arguments we have.</div>
<div><br></div><div>The 8th case is the same as the 7th one, except the number of arguments is unknown and variable.</div><div><br></div><div>The 9th case is obviously a fully qualified call, but the number of arguments isn't known first hand.</div>
<div><br></div><div>With this being said, where does Mod:Fun as a syntax stand? I don't think it would be semantically outrageous given it fits the use cases 7 and 8 quite well. I still don't think it could be the best thing to do, though. Why? there are a two big issues I see with it:</div>
<div><br></div><div>I don't think it shows a clear gain in readability or maintainability. All the cases above have different uses, different purposes. At most, Mod:Fun is a shortcut to save typing time, without clear maintainability advantages or even learning advantages. It doesn't do anything different than any of the many forms that already exist. It's more syntax for a use case we already have a solution for.</div>
<div><br></div><div>Secondly, it can't have a counterpart when it comes to local calls. I can't just pass 'atom' and expect to be passing a local function reference -- otherwise we'd never know if what we're passing (whether it's an atom or a function). This is the biggest problem to me. </div>
<div><br></div><div>We'd create a short form to avoid fun Mod:Name/N, but we have no equivalent for fun Name/N. This is a gaping hole in what can be done with the language and can be even more confusing, IMO. A good solution to simplify the syntax should do it well, not in an incomplete way that creates more inconsistencies in the language.</div>
<div><br></div><div>I think adding it would break more programmer expectations than not having it.</div><div><br></div><div class="gmail_quote">On Wed, Feb 1, 2012 at 11:29 AM, Jakob Praher <span dir="ltr"><<a href="mailto:jakob@praher.info">jakob@praher.info</a>></span> wrote:<div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Am Mittwoch, 01. Februar 2012 15:04 CET, Alisdair Sullivan <<a href="mailto:alisdairsullivan@yahoo.ca">alisdairsullivan@yahoo.ca</a>> schrieb:</div><div>
<br></div><div class="im"><div>
> functions in erlang are identified by their name and their arity</div><div>
></div><div>
> 'F = module:fun()' is ok because the arity, 0, is implied by the arguments</div><div>
></div><div>
> '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</div><div>
<br></div><div>
<br></div></div>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.<div>
<br></div><div>
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.</div><div>
<br></div><div>
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.</div><div>
<br></div><div>
E.g.</div><div>
<br></div><div>
map([],_) -> [];</div><div>
map([X|Rest], F) -> [F(X) | map(Rest, F)].</div><div>
<br></div><div>
> map([1,2,3], math:square).</div><div>
[1,4,9]</div><div>
<br></div><div>
This is a more lazy / symbolic usage of functions.</div><div>
<br></div><div>
Best,</div><div>
Jakob</div><div>
<br></div><div class="HOEnZb"><div class="h5"><div>
> _______________________________________________</div><div>
> erlang-questions mailing list</div><div>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></div><div>
<br></div><div>
<br></div><div>
<br></div><div>
<br></div><div>
<br></div><div>
_______________________________________________</div><div>
erlang-questions mailing list</div><div>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></div><div>
<br></div></div></div></blockquote></div><div><br></div>