[erlang-questions] A style question
Mon Feb 15 14:01:12 CET 2010
While we're at it, there are tons of dusty corners that people miss.
There's the occasionally useful but wholly unknown syntax for multiple
clauses in an anonymous fun:
F = fun
(true) -> ok;
(false) -> failed
Or for that matter, using guards on anonymous funs (needed it once in
an unusual list comprehension).
Or all of the oddness you can do with binary pattern matching: <<Len:4/
Or pattern matching using ++. Or matchspecs in general.
Or the fiendishly undersupported bits like inet_res, binary
comprehensions, parse tranforms, parameterized modules, -extends, etc.
I like to believe that there will come a day that all of these things
are documented clearly. Until then, I guess we'll have to document
these things through cryptic rambling on the mailing list. :(
Sent from my iPhone
On Feb 14, 2010, at 11:58 PM, "Michael Turner" <leap@REDACTED> wrote:
> 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
> 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
> in the first paragraph:
> "A fun expression begins with the keyword fun and ends with the
> end. Between them should be a function declaration, similar to a
> 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
> 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
> be, as both reference and serendipitous learning resource, for
> programmers? I was an experienced programmer already when I took my
> first course requiring Pascal (1978?), so I just flipped to the
> 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
> 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:
>>> -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,...)
>>> (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
>> Jayson Vantuyl
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@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