[erlang-questions] A style question
Mon Feb 15 03:35:42 CET 2010
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-unsubscribe@REDACTED
More information about the erlang-questions