A style question

classic Classic list List threaded Threaded
103 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

A style question

Richard A. O'Keefe-2
I've been looking at some Erlang code that's full of stuff like

        F = fun() -> ...
        mnesia:transaction(F)

My preferred style for this would be

        mnesia:transaction(fun () ->
            ....
        end)

which I think a Smalltalk or Ruby programmer would also prefer.
But is this just prejudice on my part, or is there a reason why
inserting an opaque name like "F" is a good idea?



________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Michael Richter
Only thing I can think of is that if the same fun is used in more than one
place in the function (or has potential to be) it's better to have the
label.  Aside from that I've got nothing.

On 12 February 2010 12:34, Richard O'Keefe <[hidden email]> wrote:

> I've been looking at some Erlang code that's full of stuff like
>
>        F = fun() -> ...
>        mnesia:transaction(F)
>
> My preferred style for this would be
>
>        mnesia:transaction(fun () ->
>            ....
>        end)
>
> which I think a Smalltalk or Ruby programmer would also prefer.
> But is this just prejudice on my part, or is there a reason why
> inserting an opaque name like "F" is a good idea?
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:[hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: A style question

Dale Harvey
by default the emacs erlang mode will indent the anon function from the end
of the fun() -> line

mnesia:transaction(fun() ->
                           ... some code here ...
                   end),

this takes up 27 of your 80 characters, whereas F = fun() -> is only 12,
thats the main reason I stopped doing it.

On 12 February 2010 04:39, Michael Richter <[hidden email]> wrote:

> Only thing I can think of is that if the same fun is used in more than one
> place in the function (or has potential to be) it's better to have the
> label.  Aside from that I've got nothing.
>
> On 12 February 2010 12:34, Richard O'Keefe <[hidden email]> wrote:
>
> > I've been looking at some Erlang code that's full of stuff like
> >
> >        F = fun() -> ...
> >        mnesia:transaction(F)
> >
> > My preferred style for this would be
> >
> >        mnesia:transaction(fun () ->
> >            ....
> >        end)
> >
> > which I think a Smalltalk or Ruby programmer would also prefer.
> > But is this just prejudice on my part, or is there a reason why
> > inserting an opaque name like "F" is a good idea?
> >
> >
> >
> > ________________________________________________________________
> > erlang-questions (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:[hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: A style question

Richard A. O'Keefe-2
In reply to this post by Michael Richter

On Feb 12, 2010, at 5:39 PM, Michael Richter wrote:

> Only thing I can think of is that if the same fun is used in more  
> than one place in the function (or has potential to be) it's better  
> to have the label.  Aside from that I've got nothing.

No, that doesn't apply.  In each case, the function name F is used
once and only once.

In that case, I think that instead of doing

    F = fun () -> ... end,
    mnesia:transaction(F),
    ...
    mnesia:transaction(F)

it would be better to do

     Transaction = mnesia_transaction(fun () ->
         ...
     end,
     Transaction(),
     ...
     Transaction()

so that there's no possibility of calling F _without_ the
transaction safely wrapped around it.

The code is supposed to come from an expert, who clearly knows
amongst other things a whole lot more about MochiWeb than I do.
I just wondered what I wasn't seeing.


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Richard A. O'Keefe-2
In reply to this post by Dale Harvey

On Feb 12, 2010, at 5:46 PM, Dale Harvey wrote:

> by default the emacs erlang mode will indent the anon function from  
> the end of the fun() -> line
>
> mnesia:transaction(fun() ->
>                            ... some code here ...
>                    end),
>
> this takes up 27 of your 80 characters, whereas F = fun() -> is only  
> 12, thats the main reason I stopped doing it.

That sounds like an excellent reason not to use Emacs.
I have always found Emacs' indentation to be horrible,
for every language I've tried.

Emacs with automatic indentation turned off is a better-than-decent
editor.

The indentation style I would use here just takes 4 columns, not 12.


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Richard Andrews-5
In reply to this post by Richard A. O'Keefe-2
On Fri, Feb 12, 2010 at 3:34 PM, Richard O'Keefe <[hidden email]> wrote:

> I've been looking at some Erlang code that's full of stuff like
>
>        F = fun() -> ...
>        mnesia:transaction(F)
>
> My preferred style for this would be
>
>        mnesia:transaction(fun () ->
>            ....
>        end)
>
> which I think a Smalltalk or Ruby programmer would also prefer.
> But is this just prejudice on my part, or is there a reason why
> inserting an opaque name like "F" is a good idea?

Ignoring the mnesia-specific part...

Clarity. One of my mantras of coding is: "if it's not obviously right
then it's probably wrong".

I find the former preferable when fun() is large or bulky. Inline fun
can make it unclear what the code is supposed to do.

The other reason I use the former is to give the fun a useful name
which (again) makes the code operation/goals clearer (ie.
code==documentation).

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Eric Newhuis (personal)
In reply to this post by Richard A. O'Keefe-2
Martin Fowler would probably say that F is a temporary variable and, as such, is unwanted because it slows down refactoring.  I tend to agree with him.  This is especially true in Erlang when attempting to quickly merge code segments that secretly share a common temporary name but for different purposes.  Hilarity ensues as one reaches for search/replace.

On the other hand if there were more powerful visual debugging features then I wouldn't consistently break this sage advice by leaving temporary variables around from commented-out print statements.


On Feb 11, 2010, at 10:34 PM, Richard O'Keefe wrote:

> I've been looking at some Erlang code that's full of stuff like
>
> F = fun() -> ...
> mnesia:transaction(F)
>
> My preferred style for this would be
>
> mnesia:transaction(fun () ->
>    ....
> end)
>
> which I think a Smalltalk or Ruby programmer would also prefer.
> But is this just prejudice on my part, or is there a reason why
> inserting an opaque name like "F" is a good idea?
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:[hidden email]
>


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: A style question

dmercer
In reply to this post by Richard A. O'Keefe-2
> But is this just prejudice on my part, or is there a reason why inserting
> an opaque name like "F" is a good idea?

I might assign a value to a variable for documentation purposes.  In this
specific example, though, the name "F" seems to fail as a description of
purpose, so it probably doesn't fall into that category.  Suppose, however,
that it were something like

        UpdateTheFebblebrokker = fun() -> ...
        Mnesia:transaction(UpdateTheFeeblebrokker)

Then it might server as a form documentation, written with the optimistic
assumption that the compiler will optimize the assignment away.

> The indentation style I would use here just takes 4 columns, not 12.

I would love to hear about different indentation styles, and specifically
yours.  I find properly indenting Erlang to be the most difficult part of
the language.

Cheers,

David


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Björn Gustavsson
On Fri, Feb 12, 2010 at 4:02 PM, David Mercer <[hidden email]> wrote:
>        UpdateTheFebblebrokker = fun() -> ...
>        Mnesia:transaction(UpdateTheFeeblebrokker)
>
> Then it might server as a form documentation, written with the optimistic
> assumption that the compiler will optimize the assignment away.

It will.

--
Björn Gustavsson, Erlang/OTP, Ericsson AB

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Anthony Shipman
In reply to this post by dmercer
On Sat, 13 Feb 2010 02:02:34 am David Mercer wrote:
> > The indentation style I would use here just takes 4 columns, not 12.
>
> I would love to hear about different indentation styles, and specifically
> yours.  I find properly indenting Erlang to be the most difficult part of
> the language.
>
> Cheers,
>
> David

The way the emacs mode double indents case expressions is a nuisance. It leads
to code sprawling all across the page. When you combine that with the
....................(........
                     ........
arrangement, reading code becomes a drunkard's walk across the page. It makes
it harder to quickly scan the code looking for where this or that happens.

--
Anthony Shipman                    Mamas don't let your babies
[hidden email]                   grow up to be outsourced.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Vance Shipley
In reply to this post by Richard A. O'Keefe-2
In my personal style I only use an inline fun() when it is
short enough to fit on one line:

   case mnesia:transaction(fun() -> mnesia:all_keys(funky) end) of
       {atomic, Keys} ->
           ...
       {aborted, Reason} ->
           ...
   end

Otherwise seperating the transaction logic itself from the
transaction result handling is more clear.

        -Vance

On Fri, Feb 12, 2010 at 05:34:52PM +1300, Richard O'Keefe wrote:
}  My preferred style for this would be
}  
}   mnesia:transaction(fun () ->
}      ....
}   end)

--
        -Vance

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Jayson Vantuyl-2
I've always felt that "fun some_func/2" is underused.  In the case of Mnesia, it's easy enough to do:

> mnesia:transaction( fun actual_worker_fun/0 )

I also find this to be nicer for the purposes of documentation, static analysis, debugging, and readability.

On Feb 13, 2010, at 10:55 AM, Vance Shipley wrote:

> In my personal style I only use an inline fun() when it is
> short enough to fit on one line:
>
>   case mnesia:transaction(fun() -> mnesia:all_keys(funky) end) of
>       {atomic, Keys} ->
>           ...
>       {aborted, Reason} ->
>           ...
>   end
>
> Otherwise seperating the transaction logic itself from the
> transaction result handling is more clear.
>
> -Vance
>
> On Fri, Feb 12, 2010 at 05:34:52PM +1300, Richard O'Keefe wrote:
> }  My preferred style for this would be
> }  
> }   mnesia:transaction(fun () ->
> }      ....
> }   end)
>
> --
> -Vance
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:[hidden email]
>

--
Jayson Vantuyl
[hidden email]


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Richard A. O'Keefe-2
In reply to this post by Richard Andrews-5
The topic is
     F = fun (...) ->
         ...
     end,
     foo(..., F)
vs
     foo(..., fun (...) ->
        ...
     end

On Feb 12, 2010, at 10:18 PM, Richard Andrews wrote:
> Clarity. One of my mantras of coding is: "if it's not obviously right
> then it's probably wrong".

We definitely agree about that, which is why I prefer the
second one.  Advantages of the second approach include but
are not limited to:
  - it is immediately obvious that this is the only place
    the function can be called
  - it is immediately obvious by looking up (just as one does for
    code in an 'if' or 'case' or 'receive') what governs the
    execution of this code

These things are not "obviously right" in the separated version.
>
> I find the former preferable when fun() is large or bulky. Inline fun
> can make it unclear what the code is supposed to do.

We are agreed that "large or bulky" code can be unclear.
In specific cases, we might disagree about _which_ chunks of
code should be moved.
>

> The other reason I use the former is to give the fun a useful name
> which (again) makes the code operation/goals clearer (ie.
> code==documentation).

I would rather read your code than the code that made me ask this
question, because the function name was invariably "F" or something
equally unhelpful.

Coming from a Smalltalk background where you write things like
        1 to: n do: [:i |
          ... loop body ... ]
it's not clear to me that _any_ name would be more useful than a
well chosen comment, but I think we probably agree that "well-chosen"
is more important than whether it's a named function or an inline
one with a comment.

It's probably time to draw this thread to an end.
You and Ulf Wiger have given me something to think about.


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Richard A. O'Keefe-2
In reply to this post by Jayson Vantuyl-2

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:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Jayson Vantuyl-2
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:[hidden email]
>

--
Jayson Vantuyl
[hidden email]


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Michael Turner-7
In reply to this post by Richard A. O'Keefe-2

Richard wrote:
>I think we're now pretty much down to the "personal judgement"
>level.

In some ways, that's where it started.  For example, you characterized F
as "opaque".  Fair enough, but it's at least allusive in the right
ways.  From middle school algebra onward, my math teachers were saying
highly idiomatic things like, "let f be a function that ....."  It
wasn't even until my calculus classes, IIRC, that they finally let g be
a function too.  Imagine g's impatience!

And who can look at a *capital* F without slight jolt of adrenaline about
the possibility of failure?  Nothing concentrates the mind like an F in
the morning.

So when I read

    F = fun () -> ....
    some_call (..., F, ...)

the fact that it's F (and not, say, U or K) actually helps a bit.  After
all, the idea of passing functions to functions remains a little weird
after all these years.  (Lambda might be the ultimate opcode, but the
ultimate of anything will be less accessible almost by definition.)  I
like it when code has clues about where I need to think a little harder
than usual.

Code like the above makes me think, "Ah, that's right, some_call takes
a function in *that* argument position.  Thanks for the reminder.  OK,
so what does the function do?"  And the answer is directly above.

How about some more descriptive name than F?  Possibly.  Maybe desirably,
in most cases.  But one programmer might think some name other than F
was more evocative, where another might find that same name confusing;
in such cases, the fun code itself might be the best expression of
meaning.

And, of course, the whole thing is easier to indent prettily.

I'll allow that this all sounds like a pile of petty rationalizations,
but that's what idioms are, in natural languages and artifical ones
like algebra and Erlang: an expressive little flock of compromises
flying in close formation.

What I often do is get something working in the form above, THEN get rid
of the F, put the whole lambda expression into the argument list and
twiddle around with the indentation until it looks right to me.  After
all, baking the cake is hard, but if you get the decoration wrong, you
can always just scrape the frosting layer off and try again.  And how do
you really know you've gotten it wrong, anyway?  Beauty is in the eye
of the beholder.

I do like your idea of

   some_call (..., fun:fname() -> ... end, ....)

for better trace info (and some self-documentation), though it would
probably be syntactically more consistent and easier to parse for both
human and machine if you had a blank instead of the colon.  An EEP?
Maybe for now, it would be better just to cobble up a BIF that supplies
the debugger a name for the fun, to call in the body of the fun,
throwing an exception if it was called in a named fun.  (If that's
possible; I don't know the relevant compiler/BEAM internals.)  If it
can work somehow, and people like it (it seems they should), then your
more flavorful idea is waiting in the wings.  At which point, we'll
probably see some people writing hair-tearingly stupid code like this:

   some_call (..., fun F() -> ... end, ....)

Because when fun is first class, the fun never ends.

-michael turner

On 2/15/2010, "Richard O'Keefe" <[hidden email]> 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:[hidden email]
>
>

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Richard A. O'Keefe-2

On Feb 15, 2010, at 6:40 PM, Michael Turner wrote:

>
> Richard wrote:
>> I think we're now pretty much down to the "personal judgement"
>> level.
>
> In some ways, that's where it started.  For example, you  
> characterized F
> as "opaque".  Fair enough, but it's at least allusive in the right
> ways.

It's about as helpful as calling a number N or an atom A.
I don't know what "middle school" is, but you'll often find
f, g, h used as function names, which only leaves 23 letters
of the alphabet.  I'm pretty sure I met that at high school.

>
> So when I read
>
>    F = fun () -> ....
>    some_call (..., F, ...)
>
> the fact that it's F (and not, say, U or K) actually helps a bit.  
> After
> all, the idea of passing functions to functions remains a little weird
> after all these years.

Fortran has allowed functions to be passed to functions for over
fifty years.  In my first programming classes, using Algol, we
were shown procedures passed to procedures in about lesson 3.
(Because it was a numerical analysis class, and integration is
an N.A. topic.)

> Code like the above makes me think, "Ah, that's right, some_call takes
> a function in *that* argument position.

The function in question has only one parameter.
What's to be reminded of?  And I fail to see how "F" is a better
indication of function-ness than 'fun'.
>

> And, of course, the whole thing is easier to indent prettily.

Not with decent tools.
>
>


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Michael Turner-7

I wrote:
>> ...  For example, you [Richard] characterized F
>> as "opaque".  Fair enough, but it's at least allusive in the right
>> ways.

Richard replied:

>It's about as helpful as calling a number N or an atom A.

In the case of N, at least, it actually *can* be a little helpful.
Quick, which is idiomatic in C:

  for (n = 0; n < i; ++n)

or

  for (i = 0; i < n; ++i)

And why do you think your choice became the idiom?

>I don't know what "middle school" is, but you'll often find
>f, g, h used as function names, which only leaves 23 letters
>of the alphabet.  I'm pretty sure I met that at high school.

About g and so on: I was attempting humor.  Always a risky business.  And
I thought "middle school" was more universally understood by native
English speakers than "junior high school."  Clearly I'm wrong there.

>Fortran has allowed functions to be passed to functions for over
>fifty years.....

Not the point.  I discovered this fact about Fortran early on, and
delighted in it.  But passing of functions to functions is relatively
infrequent in most non-lambda-supporting languages.  I've met people
who have been programming in C for years without learning how to write
the declaration for pointer to function, and who were faintly in awe of
me that I could do it with my eyes closed.

>The function in question has only one parameter.
>What's to be reminded of?  And I fail to see how "F" is a better
>indication of function-ness than 'fun'.

I see it as better in some ways, worse in some others, and in certain
repeated patterns, better for *some* people, if that's what they've
gotten used to.  So much so that they'll even use the pattern where
it's less applicable, as when passing a function argument to a
single-argument function.

Look, in a sense, programming languages are a user-interface issue (the
language is your interface to the processor-memory switch and ultimately
to something happening at the level of electrons and holes in doped
silicon crystal lattices).  People's judgments of user interface issues
often come down to what they think is "intuitive".  Studies of what's
intuitive in user interfaces have come up with a shrug: the intuitive is
what's familiar to you, period.  You write enough code with funs
directly supplied as arguments, and look at enough code like that, and
it's more familiar to you.  So you think that's "intuitively
obvious" way.  But I'll probably have to write the keyword 'fun' in
Erlang 500 more times before I'll fully quell my mind's natural
impulse to read it as the English word "fun".  It's a mild
distraction, but a little bit of cognitive load each time.  In some
ways, I wish the designers of Erlang chosen "function", or even
"lambda".

I've been living in Japan almost 15 years, and I still do things wrong
because I'm following intuitions developed from the 38 years before I
came here to live.  There's so much in almost everything we do that's
little more than a matter of what we're used to seeing and doing.

>> And, of course, the whole thing is easier to indent prettily.
>
>Not with decent tools.

Not everyone has those, Richard.  Just recently, there was a thread here
about how Emacs gets it wrong.  But most Erlang hackers use Emacs
anyway, I bet.  I use vim.  Vim gets it wrong, too.  But vim is
basically vi, which is, well, intuitively obvious to me.  Maybe I'm
crippled by a whole adult lifetime of editing habits.  (Maybe I can sue
Bill Joy for damaging my productivity?  I hear he has a lot of money.)

-michael turner

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Michael Turner-7
In reply to this post by Jayson Vantuyl-2
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" <[hidden email]> 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:[hidden email]
>>
>
>--
>Jayson Vantuyl
>[hidden email]
>
>
>________________________________________________________________
>erlang-questions (at) erlang.org mailing list.
>See http://www.erlang.org/faq.html
>To unsubscribe; mailto:[hidden email]
>
>

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A style question

Mariano Guerra
On Mon, Feb 15, 2010 at 8:58 AM, Michael Turner <[hidden email]> wrote:

> Jayson wrote:
> 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.

maybe this can help, i dont know if it is complte or up to date but it
is a start.

http://github.com/erlang/otp/blob/ba3758531a0b6dc6797457279e1ce0f99d282d20/lib/parsetools/src/esyntax.yrl

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

1234 ... 6