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.htmlTo unsubscribe; mailto:
[hidden email]
Locked
