[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
end.

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