[erlang-questions] A style question

Michael Turner <>
Mon Feb 15 08:58:58 CET 2010


Jayson wrote:
>I've noticed that some people have gaps in their knowledge of
> Erlang.  "fun somefunc/N" seems to be one of them.

Maybe in part because it's not easy to find?

I'd been using Erlang funs for a while before needing fun f/n for
something.  To my surprise I found myself quite frustrated trying to
determine that syntax.  For a while, I even resorted to fun()->f(...)
end as a workaround.

I knew such a thing *had* to be possible in Erlang.  But the syntax
isn't covered in the index entries under "fun" in Armstrong's book,
and there isn't even a freestanding index entry for "fun" in Cesarini
& Thompson.  I can't remember how I learned it finally.  I guess I
found it somewhere, or maybe it was just trial and error.  It certainly
wasn't from the reference manual

http://ftp.sunet.se/pub/lang/erlang/doc/reference_manual/expressions.html#id2272623

where it's an inconspicous afterthought instead of being summarized
upfront, right at the beginning.  If I got there, I must have been
turned back by what seemed like very categorical and exclusive language
in the first paragraph:

"A fun expression begins with the keyword fun and ends with the keyword
end. Between them should be a function declaration, similar to a regular
function declaration, except that no function name is specified."

Even if you get to the entry for "fun expressions" in C&T (p.192), it
seems their sense of the term "fun expression" is a fun that's
nameless.

Formally, I'd say that

    fun f/n

is a fun expression, the simplest kind, in much the same sense that 1 is
an arithmetic expression.  Anybody who can't see 1 that way isn't cut
out to be a progammer.

Neither of the two books has an appendix for a semi-formal grammar of
Erlang, in BNF style, nor does there seem to be such a thing in the
reference manual.  Need I say how important such touchstone material can
be, as both reference and serendipitous learning resource, for seasoned
programmers?  I was an experienced programmer already when I took my
first course requiring Pascal (1978?), so I just flipped to the appendix
with the BNF, noted Pascal's differences from what I knew of Algol in
about an afternoon, and was reasonably fluent in almost the entire
language within days.  I must have learned half of C by browsing the
syntax summary in K&R, running across interesting cases, and thinking,
"You can *say* that?  Hm, let's see what it means."  In the case of
learning Erlang fun f/n, just having a syntax chart would have helped me
find the syntax more quickly.


Suggestion for tutorials: gently introduce funs using fun f/n *first*,
then (quickly) bring in the fun () -> ... end syntax.

Suggestion for new books and future editions of existing ones, and for
the online reference manual: give people an appendix with the syntax of
Erlang.  Somebody who really knows Erlang internals might be able hack
an auto-generator for a readable PDF within a day.  (I wouldn't know,
I've never strayed into the relevant parts of the compiler.)

-michael turner

On 2/15/2010, "Jayson Vantuyl" <> wrote:

>With respect to exports (#4), I just tested it with R13B, it doesn't appear that you have to export a fun to reference it.  Specifically, this works for me:
>
>> -module(u).
>> -export ([test/0]).
>> 
>> test() ->
>>   F = fun test2/0,
>>   F().
>> 
>> test2() ->
>>   ok.
>
>That said, I think point #5 is an important one, although maybe not for the reason you do.  I've noticed that some people have gaps in their knowledge of Erlang.  "fun somefunc/N" seems to be one of them.  Capturing surrounding variables is another one.
>
>As for point #3, I don't know of many times I would consider "fun () -> ... end" to be anything but bulky.  Then again, Ruby and Python may have me spoiled in that respect.  Of course, that is definitely a matter of personal preference.
>
>On Feb 14, 2010, at 6:06 PM, Richard O'Keefe wrote:
>
>> 
>> On Feb 14, 2010, at 10:39 AM, Jayson Vantuyl wrote:
>> 
>>> I've always felt that "fun some_func/2" is underused.
>> 
>> It's a good thing to use _if_ you already have some_func/2 and
>> don't need to pass it any arguments.
>> 
>> We have agreement on a number of points.
>> 
>> (1) If you introduce a name for a function that is passed to
>>    a higher order operation, it should be a meaningful name,
>>    not just "F" or "f" or anything like that.
>> 
>> (2) If you already want to name a function for some other reason,
>>    use fun F/N to refer to it rather than fun (X,...) -> F(X,...) end.
>> 
>> (3) If the code would be bulky, _something_ has to move out and
>>    it might as well be the 'fun'.
>> 
>> (4) Having 'fun (..) -> end' available means we don't have to
>>    export things just so they can be called, and having
>>    'fun F/N' available means the same; exporting stuff we'd
>>    rather not is no longer an issue.
>> 
>> (5) If there is information in the surrounding clause that needs to
>>    be passed in, one level of 'fun' to capture that seems to be
>>    necessary, but it need not be the _whole_ of the computation;
>>    you can hand the information off to something with a name and
>>    a comment.
>> 
>> I think we're now pretty much down to the "personal judgement"
>> level.
>> 
>>   
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:
>> 
>
>-- 
>Jayson Vantuyl
>
>
>
>________________________________________________________________
>erlang-questions (at) erlang.org mailing list.
>See http://www.erlang.org/faq.html
>To unsubscribe; mailto:
>
>


More information about the erlang-questions mailing list