[erlang-questions] A style question
Mon Feb 15 08:58:58 CET 2010
>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
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
Formally, I'd say that
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.)
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:
>> -export ([test/0]).
>> test() ->
>> F = fun test2/0,
>> test2() ->
>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"
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:
>erlang-questions (at) erlang.org mailing list.
>To unsubscribe; mailto:
More information about the erlang-questions