[erlang-questions] (no subject)

Robert Virding rvirding@REDACTED
Mon Mar 10 22:14:25 CET 2008

On 10/03/2008, Jay Nelson <jay@REDACTED> wrote:
> I stand corrected.  I wasn't aware of the compiler error because I
> avoid that style of code.
> The reason I avoid it, is that I find it more difficult to visually
> verify in the editor.  Also, if more clauses are added in the future,
> you have to keep track that the following code relies on setting some
> variables (or else, apparently, wait until you compile to notice you
> need some others).
> I just find that the following style:
> { ... args needed ... } = compound statement,
> use args
> advertises the programmer's intent much more clearly.  It states that
> the compound statement is being executed for the side effect of
> binding a particular set of variables.  This binding environment is
> necessary for the following statements.  It corresponds to a (let
> (...) ...) clause in lisp.

Yes, it is a matter of style which method you use. The scope of variables is
the whole function clause. I also prefer returning the values which are
"exported" from the if/case/receive, it is clearer, but I am not always
consistent in this I know. Although many prefer just exporting them.
Unfortunately it is impossible to be completely consistent all the time as
the compiler quite happily exports all variables which are bound in all
clauses. This can cause some confusion. So if you have:

case ... of
    ... -> ..., Tmp = ..., ...;
    ... -> ..., Tmp = ..., ...;

where Tmp is bound in all clauses then Tmp will automatically be exported.
And if it is then later used it will already be bound, which can cause some
confusion. So you have to be certain to use unique names for temporary
variables. This is another reason to avoid large function clauses where it
can be harder to see reuse.

There is no way around this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080310/61b96f7d/attachment.htm>

More information about the erlang-questions mailing list