[erlang-questions] (no subject)

[Dmitri Girenko]

Well, both versions have their pros and cons. Probably depending on the
number of variables, it might be better to use the "side effect" of the
case clause as it shortens the code significantly.

 

What I am more worried about is the effect it has on the automatic
source code processing like refactoring, parse transforms, etc. For
instance if we have

 

Value = case Var of 

            one->Tmp=blah_blah, calcValue(SomeArgs);

            two->Tmp=blah_2, calcValue(OtherArgs);

end,

... code goes on ...

do_something(Tmp, YetOtherArgs)..

 

Later one decides to extract a function (aka extract a method in OO),
then the code should be rewritten as

 

{Value, Tmp} = new_func(...);

....

 

new_func(..) ->

Value = case Var of 

            one->Tmp=blah_blah, calcValue(SomeArgs);

            two->Tmp=blah_2, calcValue(OtherArgs);

end,

{Value, Tmp}.

 

So the question is: are these kind of features easily handled in the
AST? Do refactoring tools have to take special care of the case like
that?

 

 

P.S. All these questions arose only because the binary match specs have
to be static, not like:

 

<<A:1/unit:32-Endianness, Rest>> = Binary. :-)

 

 

________________________________

From: erlang-questions-bounces@REDACTED
[mailto:erlang-questions-bounces@REDACTED] On Behalf Of Robert Virding
Sent: 10. maaliskuuta 2008 23:14
To: Jay Nelson
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] (no subject)

 

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 = ..., ...;
    ...
end,

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.

Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080311/8d49f151/attachment.htm>