On 10/03/2008, <b class="gmail_sendername">Jay Nelson</b> <<a href="mailto:jay@duomark.com">jay@duomark.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I stand corrected.  I wasn't aware of the compiler error because I<br> avoid that style of code.<br> <br> The reason I avoid it, is that I find it more difficult to visually<br> verify in the editor.  Also, if more clauses are added in the future,<br>
 you have to keep track that the following code relies on setting some<br> variables (or else, apparently, wait until you compile to notice you<br> need some others).<br> <br> I just find that the following style:<br> <br>
 { ... args needed ... } = compound statement,<br> use args<br> <br> advertises the programmer's intent much more clearly.  It states that<br> the compound statement is being executed for the side effect of<br> binding a particular set of variables.  This binding environment is<br>
 necessary for the following statements.  It corresponds to a (let<br> (...) ...) clause in lisp.</blockquote><div><br>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:<br>
<br>case ... of<br>    ... -> ..., Tmp = ..., ...;<br>    ... -> ..., Tmp = ..., ...;<br>    ...<br>end,<br><br>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.<br>
<br>There is no way around this.<br><br>Robert<br><br></div></div>