[erlang-questions] A style question
Michael Turner
leap@REDACTED
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" <kagato@REDACTED> 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:erlang-questions-unsubscribe@REDACTED
>>
>
>--
>Jayson Vantuyl
>kagato@REDACTED
>
>
>________________________________________________________________
>erlang-questions (at) erlang.org mailing list.
>See http://www.erlang.org/faq.html
>To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>
More information about the erlang-questions
mailing list