"<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">But how interesting is whether existing code would break or not?"</span><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Not very. I mean, who uses Erlang for anything important? Hardly anybody, right?</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">[/sarcasm]</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">"</span></font>It would, as others have pointed out, also be much harder to jump into a module and _know_ what the clause does since the function's name can be pages away."</div>
<div><br></div><div>It would only be harder ("much"??) if you *chose*, in such cases, to use the syntax I propose to bring over from multi-clause funs. In the case you bring up, it might be wiser not to. And what I propose clearly allows everyone to continue with the present syntax. So your argument for readability in this case comes down to "somebody might not use this language feature wisely." (*facepalm*).</div>
<div><br></div><div>-michael turner </div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><div class="gmail_quote">
On Thu, May 19, 2011 at 6:37 PM, Raimo Niskanen <span dir="ltr"><<a href="mailto:raimo%2Berlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, May 19, 2011 at 01:50:33AM +0900, Michael Turner wrote:<br>
> I'm still waiting for the answer to the real showstopper question: would any<br>
> existing code break, under my proposal?<br>
><br>
> -michael turner<br>
><br>
<br>
</div>I can not think of any existing code that would break, but there<br>
are others that have weirder imagination than me.<br>
<br>
But how interesting is whether existing code would break or not?<br>
<br>
One nice thing with Erlang for me is that it is not like Perl;<br>
there seldom seldom many ways to do it (syntacticly).<br>
<br>
The current compromise and limitation of having to write the<br>
function name for every clause for regular function and not writing<br>
any function name for funs I think is very good. It encourages<br>
short funs and makes it easier to read long functions with<br>
many clauses. If you restructure your code, move around clauses<br>
often you run into a compilation error when you have messed up<br>
clauses between functions.<br>
<br>
If you would remove the requirement of a function name on every<br>
clause you would increase the possibility of getting completely<br>
incorrect code through the compiler since it is enough that<br>
the arity is the same between the clauses; you can accidentally<br>
paste in a totally unrelated clause from some other function<br>
and not discover it until it crashes in the field, provided<br>
testing is incomplete (which it mostly is).<br>
<br>
It would, as others have pointed out, also be much harder to<br>
jump into a module and _know_ what the clause does since<br>
the function's name can be pages away. That would encourage<br>
no more than page-long functions instead of no more than<br>
page-long clauses and I sincerely prefere the latter.<br>
<br>
In short. I think the impact on readability and programmer's<br>
common mistake preventions clearly does not motivate the change.<br>
The possible benefits are minor.<br>
<font color="#888888"><br>
--<br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>