[erlang-questions] Funargs: Ruby-like blocks for Erlang

Joe Armstrong erlang@REDACTED
Tue Jul 26 09:49:52 CEST 2011


"let" I can do without - I've never thought this to be a problem
(and I don't want to re-iterate the pros and cons here).

"letrec" on the other hand I find sadly missing.

Choosing names for auxiliary functions ("helper" functions) is painful.


Suppose I want to define foo/2 and bar/3 which are mutually recursive
but which also call a number of private auxiliary functions. The only
encapsulation
mechanism available is the module.

I want to say:

   letrec
     foo(X,Y) ->
        ...
        foo_1(...)


     bar(A,B,C) ->
        ...
        foo-1(...)
        bar_26(...)

   where
      foo_1(...) ->

      bar_26(...) ->
   end.

Only the functions foo/2 and bar/3 would be visible from outside
the letrec.

The is already a mechanism for (almost) this. The module.
But there are two problems with modules - we can't in-line them
and we can't have "anonymous" modules. With a small sleight of hand we can
transform letrecs into a very Erlangly syntax.

    -module().
    -export[foo/2,bar/2]).

    %% definitions of foo/2, bar/2 and anything else they call

    -end().

Adding this to the language is a trivial exercise in pre-processing.

This would incidentally solve some other problems do do with the scope
of comments of macros. Analyzing source code is difficult because there is
no notion of the scope of a comment or the scope of a macro. Comments are not
attached to any particular function and so on. This makes refactoring tools
and IDEs messy to say the least.


On Tue, Jul 26, 2011 at 5:24 AM, Richard O'Keefe <ok@REDACTED> wrote:
> There was once a proposal to have
>        begin
>            <bindings>
>        within
>            <expessions>
>        end
> where the <bindings> would be visible within the <expressions> but not
> outside.  begin...end survives in the language, but 'within' never made it.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list