[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions

Tim Watson <>
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