[erlang-questions] case expression scope

[Martin Schut]

Why not put the extraction of the AuthKey and PrivKey to separate  
functions. I'd probably do that to a lot of other case statements as well.  
This leaves readable code. I do not know why you want it to be concise.  
Readable would be my first requirement, concise a secondary.

Best regards,
--Martin

> I've been reflecting on this some more, and have realized one of my  
> biases on the subject comes from the way C/C++ manages scope:  Anything  
> >within curly braces, whether it is a function, if, while, for, try, or  
> catch, is a scope which encapsulates all declarations within.  This  
> uniform rule >makes it easier to reason about code, and not having it in  
> Erlang is, well, jarring to me.
>
> Now both Erlang and C/C++ can *read* variables from enclosing scopes,  
> but only C/C++ can *mutate* variables from enclosing scopes.  Perhaps  
> >Erlang's case scoping rules are just a way to give similar powers to  
> affect the enclosing scope.
>
>
> The actual clause that predicated all this is here:   
> https://gist.github.com/goertzenator/9347573
>
> There are a lot of case expressions that leave unwanted bindings lying  
> around.  I have to pay attention to use different binding names for each  
> to >avoid collisions.  Specifically the AuthKey and PrivKey expressions  
> had collisions at first because they are nearly identical.  The code  
> would be a >lot easier to reason about if I didn't have to look out for  
> such things.
>
> I tried putting this function together in various different ways, and  
> this way was the most concise, most readable, and most amenable to  
> future >tweaking.  I normally don't tolerate clauses this long, but  
> breaking it up always seemed to compromise those things.
>
>
> Thank you for your ideas Richard.  I see I could also use funs directly  
> instead of cases.
>
> f1(X, Y) ->
>    A = fun({0, Q}) -> Q;
>           ({P, Q}) -> P*Q
>           end({X,Y}),
>
>    B = fun({0, Q}) -> Q;
>           ({P, Q}) -> P+Q
>        end({X,Y}),
>    {A,B}.
>
> Regards,
> Dan.
>
>
>
> On Mon, Mar 3, 2014 at 3:23 PM, Richard A. O'Keefe <ok@REDACTED>  
> wrote:
>>
>> On 4/03/2014, at 8:07 AM, Daniel Goertzen wrote:
>>
>>> Hmm, fun wrapping could be the basis of hygienic-case parse  
>>> transform.  I'll have to see what the performance overhead of a fun  
>>> wrap is like.
>>>
>>> The example I gave is contrived and a bit weak I guess.  In my most  
>>> recent run-in with this issue there were a lot of bindings from the  
>>> enclosing >>scope that were used, so breaking things out to top level  
>>> functions would not always be a good option.
>>
>> I see a non-sequitur there.
>>
>> Simplified examples are great for revealing bugs.
>>
>> For illuminating style concerns, NOTHING beats REAL code.
>>
>> "There were a lot of bindings from the enclosing scope"
>> is already a warning sign that the code should be restructured.
>>
>>>  Funs would be better, but add clutter and maybe runtime overhead.
>>
>> There is currently some run-time overhead.
>> In R16B03-1, the compiler still does not optimise
>>
>> (fun (...) -> ... ... end)(...)
>>
>> by turning it into the equivalent of an SML let ... in ... end
>> form, but there is no particular reason why it couldn't.
>>
>> Whether you can _measure_ the overhead in a real application
>> is another matter entirely.
>>
>> Splitting out little functions and then telling the compiler
>> to inline them might well have the least overhead of all.
>>
>>
>



--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140304/9f253ada/attachment.htm>