[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions
Tim Watson
watson.timothy@REDACTED
Thu May 19 13:23:56 CEST 2011
>> It would, as others have pointed out, also be much harder to
>> jump into a module and _know_ what the clause does since
>> the function's name can be pages away. That would encourage
>> no more than page-long functions instead of no more than
>> page-long clauses and I sincerely prefere the latter.
The current syntax for module level functions is perfectly reasonable
today. Consider the Haskell equivalent, which is very similar:
take1 _ [] = []
take1 0 _ = []
take1 n (x:xs) = x : take1 (n-1) xs
In Ocaml you have some `match x with ...` noise to deal with, but it's
much the same story. Personally I don't think there's anything wrong
here.
For funs though, having the parens but no name might be understandable
but it is *ugly* to say the least. Perhaps the consistent approach
would be to repeat the "fun" keyword, so an example might look like:
process_glob(Proc) ->
fun({Dir, #spec{path=Path, glob=undefined}=Spec}, {MapAcc, FoldAcc}) ->
filter(Spec, [filename:join(Dir, Path)], MapAcc, FoldAcc);
fun({Dir, #spec{glob=Glob}=Spec}, {MapAcc, FoldAcc}) ->
filter(Spec, Proc(Dir, Glob), MapAcc, FoldAcc);
fun({Dir, PathExpr}, {MapAcc, FoldAcc}) when is_list(PathExpr) ->
filter(glob(PathExpr), Proc(Dir, PathExpr), MapAcc, FoldAcc)
end.
It's hardly elegant but at least it is consistent with the way "the
other kind of function" is treated syntactically.
Personally, I think a lot of the situations where working with funs is
a pain, stem from the fact there's no easy way to do partial
application. If the compiler team could give us that (maybe with a
nice syntactic sugar for function composition on the side), I think it
would be far more valuable than fiddling around with the syntax of
anonymous functions. For the time being I'm using
http://hg.rabbitmq.com/erlando and "cut", but it'd be nice to know how
the language implementation is going to evolve in these kinds of
areas.
More information about the erlang-questions
mailing list