<br><br><div class="gmail_quote">On Wed, May 18, 2011 at 5:11 PM, Parnell Springmeyer <span dir="ltr"><<a href="mailto:ixmatus@gmail.com">ixmatus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
You're being pedantic dude. I'm sure Joe Armstrong and the other<br>
programmers that designed and work on Erlang are acutely aware of DRY,<br>
PoLS, and a whole bunch of others.<br></blockquote><div><br></div><div>Absolutly - DRY is tricky though - it's sometimes quicker</div><div>to repeat yourself than find the code to repeat. And sometimes</div><div>when you repeat yourself you find you didn't - you thought you</div>
<div>repeated yourself - bit on closer inspection you improved some</div><div>old version. Since I actually repeat myself a lot I have another</div><div>problem which of the 17 almost similar versions of X was the best ...</div>
<div><br></div><div><meta charset="utf-8"><div>One the subject of syntax there's another inconstancy that nobody seems to have noticed. All arguments in function calls *EXCEPT THE LAST* have commas after them. </div></div>
<div><br></div><div>We write foo(a,b,c) but to make it easy to swap the arguments</div><div>we should write foo(a,b,c,) - actually C, Java and virtually every language under the sun gets this wrong.</div><div><br></div><div>
Oh and English clauses are separated by commas, *EXCEPT THE LAST*.</div><div><br></div><div>This, I think, would be a lot better,.</div><div><br></div><div>Or so it is argued on the placement of ;'s in Erlang :-)</div>
<div><br></div><div><meta charset="utf-8">Changing syntax is *incredibly difficult* project managers get</div><div>apoplectic at the thought of retesting million lines of code - I know</div><div>they *should* be able to retest overnight - but sometimes they have</div>
<div>to book special purpose test facilities weeks in advance.</div><div><br></div><div>For those who want to experiment with a new syntax there is an</div><div>easy method - make a new file extension .erl1 hack the parser</div>
<div>and write some code that transforms .erl1 files to .erl.</div><div><br></div><div>If you want to think about language changes why don't we have a</div><div>long debate over higher order modules - not syntax.</div>
<div><br></div><div>Me, I'd like to say</div><div><br></div><div> L = [{foo, fun(X,Y) -> ... end}, {bar, fun(X) -> ... end}]</div><div><br></div><div> then have couple of new bifs Mod = list_to_mod(L) to compose</div>
<div>a module from a load of funs and mod_to_list to do the inverse.</div><div><br></div><div> </div><div><br></div><div>/Joe</div><div><br></div><div> </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Personally, I think it is a feature to state the function name when<br>
defining another function clause.<br>
<br>
some_func(X, Y) -><br>
%% Long bit of code<br>
...;<br>
some_func(X, []) -><br>
%% More code<br>
....<br>
<br>
Without it, scanning the source could get confusing.<br>
<div><div></div><div class="h5"><br>
Michael Turner <<a href="mailto:michael.eugene.turner@gmail.com">michael.eugene.turner@gmail.com</a>> writes:<br>
<br>
> I can say<br>
><br>
> fun (1)->2;<br>
> (2)->1<br>
> end<br>
><br>
> but, oddly, I can't define a named function in the analogous way, e.g.:<br>
><br>
> factorial<br>
> (1) -> 1;<br>
> (N) -> N*factorial(N-1).<br>
><br>
> gives me a syntax error. I find the latter more readable than<br>
><br>
> factorial(1) -> 1;<br>
> factorial(2) -> N*fact(N-1).<br>
><br>
> It's also less to type and to read, which is consistent with the DRY<br>
> principle ("Don't Repeat Yourself"). And it lends itself to reading a<br>
> function definition as a set of cases. I think for Erlang newbies, it<br>
> should therefore would be preferred: it helps underscore the<br>
> pattern-matching style of Erlang function invocation.<br>
><br>
> It also looks a *little* bit more like the mathematical convention for<br>
> defining these sorts of functions, where you have "f(x) = ", centered<br>
> vertically to the left of a big left "{" that (left-)encloses the list<br>
> of expression/parameter-condition pairs in a two-column format, e.g.,<br>
><br>
> <a href="http://cnx.org/content/m29517/latest/Picture%2047.png" target="_blank">http://cnx.org/content/m29517/latest/Picture%2047.png</a><br>
><br>
> So there's a (weak) argument from the Principle of Least Surprise here<br>
> as well.<br>
><br>
> It seems to me that, if anything, this requires only a *simplification*<br>
> of the Erlang parser. That leaves only one obvious objection: would any<br>
> existing code break if Erlang syntax were altered to allow this?<br>
><br>
> -michael turner<br>
><br>
</div></div>> _______________________________________________<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>
<br>
- --<br>
Parnell "ixmatus" Springmeyer (<a href="http://ixmat.us" target="_blank">http://ixmat.us</a>)<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)<br>
Comment: GPGTools - <a href="http://gpgtools.org" target="_blank">http://gpgtools.org</a><br>
<br>
iQEcBAEBAgAGBQJN0+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43<br>
Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo<br>
C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI<br>
MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx<br>
nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd<br>
8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U=<br>
=ypYB<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<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>
</blockquote></div><br>