Exactly what I was talking about. I can't see any sense in bloating the code with nonsensical functions just to get something let-like -- AFAIK, every functional language out there has a local namespace for such constructs. Moreover, there is a huge inconsistency right now with list comprehensions that have their own namespace because of their transformation to functions:<br><br>test1() -><br> [begin<br> _A = X,<br> ok<br> end || X <- [1, 2, 3]],<br> _A = 1.<br><br>test2() -><br> case 2 of<br> _A -> _A<br> end,<br> _A = 1.<br><br>I think it's a sign of a bigger problem with Erlang as a language: we have an amazing BEAM, some brilliant libraries, a lot of godlike developers, but Erlang as a language evolves extremely slow. One reason that I can think about is a lack of ultimate authority that can decide what is right and what is wrong — theoretically there is a EEP process (and some proposals are out of EEPs scope, like an e2 thing), but in practice some EEPs are here for years (like Frames proposal or JSON BIFs) and nothing really moves on. <br><br>On Tuesday, July 10, 2012 1:40:17 PM UTC+4, Sergei Lebedev wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Richard,
<br>
<br>While this indeed *may* be a sign of a problem in your code, for the original example this is hardly the case. Splitting the function apart *only* because of compiler limitations sounds like an ad-hoc hack, not a real solution.
<br>
<br>-- Sergei
<br>
<br>On Jul 10, 2012, at 1:02 PM, Richard Carlsson wrote:
<br>
<br>> On 07/10/2012 10:43 AM, Dmitry Groshev wrote:
<br>>> case do_something() of
<br>>> {ok, Result} -> Result;
<br>>> {error, Error} -> Error
<br>>> end,
<br>>> case do_another() of
<br>>> {ok, Result} -> Result;
<br>>> {error, Error} -> Error
<br>>> end,
<br>>>
<br>>> Result and Error are bound in first case and we will probably have a
<br>>> match failure in second one. Compiler warns about this, but it's still
<br>>> very unwieldy to fix it with names like Error1, Error2, etc.
<br>>
<br>> Take it as a sign that you should break out those case expressions into separate functions, or restructure the code in some other way.
<br>>
<br>> /Richard
<br>> ______________________________<wbr>_________________
<br>> erlang-questions mailing list
<br>> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<br>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
<br>
<br>______________________________<wbr>_________________
<br>erlang-questions mailing list
<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
<br></blockquote><br>On Tuesday, July 10, 2012 1:40:17 PM UTC+4, Sergei Lebedev wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Richard,
<br>
<br>While this indeed *may* be a sign of a problem in your code, for the original example this is hardly the case. Splitting the function apart *only* because of compiler limitations sounds like an ad-hoc hack, not a real solution.
<br>
<br>-- Sergei
<br>
<br>On Jul 10, 2012, at 1:02 PM, Richard Carlsson wrote:
<br>
<br>> On 07/10/2012 10:43 AM, Dmitry Groshev wrote:
<br>>> case do_something() of
<br>>> {ok, Result} -> Result;
<br>>> {error, Error} -> Error
<br>>> end,
<br>>> case do_another() of
<br>>> {ok, Result} -> Result;
<br>>> {error, Error} -> Error
<br>>> end,
<br>>>
<br>>> Result and Error are bound in first case and we will probably have a
<br>>> match failure in second one. Compiler warns about this, but it's still
<br>>> very unwieldy to fix it with names like Error1, Error2, etc.
<br>>
<br>> Take it as a sign that you should break out those case expressions into separate functions, or restructure the code in some other way.
<br>>
<br>> /Richard
<br>> ______________________________<wbr>_________________
<br>> erlang-questions mailing list
<br>> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<br>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
<br>
<br>______________________________<wbr>_________________
<br>erlang-questions mailing list
<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
<br></blockquote>