<div dir="ltr"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt" id="docs-internal-guid-0778abf4-9336-8c3a-f178-c3f80bd0acaa"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">So I received suggestions to factor out the little functions. But I was sure that would ruin the visual locality and “flow” of the code thereby making it harder to read. So I decided to go ahead and implement it that way so I could show those people that they are wrong. But as I starting factoring things out I could see the larger-grain structure more easily, and saw some easy ways to collapse and clean up things… and some of things that I thought would be problems were not problems at all. Boy, am I ever eating crow now. :)</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Here is the result: <a href="https://gist.github.com/goertzenator/9370847">https://gist.github.com/goertzenator/9370847</a></span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">There may be a bug or two; I am in the process of making functional changes.</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">So a big thank you to Richard and the others who commented on my coding style. I am the sole Erlanger at a small startup, so I don’t get the benefit of that kind of review.</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The scoping rules of case still irritate me, but now I have a better sense as to why it is the way it is, and I have been shown a better coding style that mostly removes the irritation.</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Thanks again,</span></p><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Dan.</span></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 4, 2014 at 10:10 AM, Daniel Goertzen <span dir="ltr"><<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br>
<br></div>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.<br>
<div><div><br><br></div><div>The actual clause that predicated all this is here: <a href="https://gist.github.com/goertzenator/9347573" target="_blank">https://gist.github.com/goertzenator/9347573</a><br><div class="gmail_extra">
<br></div>
<div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">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.<br>
<br><br></div><div class="gmail_extra">Thank you for your ideas Richard. I see I could also use funs directly instead of cases.<br></div><div class="gmail_extra"><br><span style="font-family:courier new,monospace">f1(X, Y) -><br>
A = fun({0, Q}) -> Q;<br> ({P, Q}) -> P*Q<br> end({X,Y}),<br><br> B = fun({0, Q}) -> Q;<br> ({P, Q}) -> P+Q<br> end({X,Y}),<br> {A,B}.</span><br><br>Regards,<br>
Dan.<br>
</div><div><div class="h5"><div class="gmail_extra"><br><br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 3:23 PM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
On 4/03/2014, at 8:07 AM, Daniel Goertzen wrote:<br>
<br>
> 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.<br>
><br>
> 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.<br>
<br>
</div>I see a non-sequitur there.<br>
<br>
Simplified examples are great for revealing bugs.<br>
<br>
For illuminating style concerns, NOTHING beats REAL code.<br>
<div><br>
"There were a lot of bindings from the enclosing scope"<br>
</div>is already a warning sign that the code should be restructured.<br>
<div><br>
> Funs would be better, but add clutter and maybe runtime overhead.<br>
<br>
</div>There is currently some run-time overhead.<br>
In R16B03-1, the compiler still does not optimise<br>
<br>
(fun (...) -> ... ... end)(...)<br>
<br>
by turning it into the equivalent of an SML let ... in ... end<br>
form, but there is no particular reason why it couldn't.<br>
<br>
Whether you can _measure_ the overhead in a real application<br>
is another matter entirely.<br>
<br>
Splitting out little functions and then telling the compiler<br>
to inline them might well have the least overhead of all.<br>
<br>
<br>
</blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br></div>