[erlang-questions] A style question

Jayson Vantuyl <>
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/ 
integer, Data:Len/binary>>.

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" <> 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  
> 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:
> ________________________________________________________________
> 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