<br><br><div class="gmail_quote">On Fri, May 20, 2011 at 12:44 AM, James Churchman <span dir="ltr"><<a href="mailto:jameschurchman@gmail.com">jameschurchman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
winner for the most nit-pickey thread ever <div><br></div><div>also :</div><div><br></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div class="im"><div>>Me, I'd like to say</div>
<div>></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 a module from a load of funs and mod_to_list to do the inverse.</div>
<div><br></div></div><div>should be possible by generating a bit of ast and would indeed be a cool addition to the runtime :-)</div></span></div></blockquote><div><br></div><div>Unfortunately not.</div><div><br></div><div>
/Joe</div><div><br></div><div> </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>
<br></div><div><br></div></span><div><div></div><div class="h5"><br><div class="gmail_quote">On 19 May 2011 23:05, Edmond Begumisa <span dir="ltr"><<a href="mailto:ebegumisa@hysteria-tech.com" target="_blank">ebegumisa@hysteria-tech.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I child I asked my mathematician father:<br>
<br>
"Why is the number pad of a telephone in the flipped order from the number pad on a calculator/computer keyboard?"<br>
<br>
His answer: "That's just the way it is."<br>
<br>
Sometimes "that's just the way it is" is a perfectly sufficient and reasonable answer to both questions: why something is done a particular way; and why it shouldn't be changed.<br>
<br>
Mind you on the noob argument: when I first started learning Erlang (my first functional language -- I had tried Lisp and gave up), I found the current syntax a very good learning aid. To use Turner's original example...<br>
<br>
factorial(0) -> 1;<br>
factorial(N) when N > 0 -> N*factorial(N-1).<br>
<br>
I would read this as...<br>
<br>
"The factorial of 0 is 1; the factorial of N when N is greater than zero is N times the factorial of N - 1."<br>
<br>
Having the function name at the beginning of each clause helped me greatly to adapt to the declarative nature of Erlang. In contrast, I first struggled with multi-clause funs because my brain wanted so badly to use the anatomy of a function that I was so used to from imperative languages.<br>
<br>
So I'd argue that changing this might make code actually *harder* for noobs when they come across it. The function names reinforce the declarative nature of Erlang, me thinks.<br>
<br>
Besides, every programmer I know is a touch-typist -- it's not _that_ much work typing the function names :)<br>
<br>
- Edmond -<div><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 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>
</blockquote></blockquote></blockquote>
<br>
</blockquote>
<br>
<br>
<br>
<br>
<br></div><div><div></div><div>
On Fri, 20 May 2011 03:19:11 +1000, Mike Oxford <<a href="mailto:moxford@gmail.com" target="_blank">moxford@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Noting that I'm not against core language changes where critically<br>
warranted, why is this one particular thing such an issue to you?<br>
<br>
Erlang is not an ivory-tower-on-a-hill-university-project. It's an<br>
organically-grown beast that gets down in the trenches and brawls in the<br>
mud.<br>
If you don't like it, write it off as an "Erlang wart." Every language has<br>
them. If you don't like it then write your own, or your own parser.<br>
<br>
For what it's worth, some users (such as myself) actually PREFER it the way<br>
it is because it makes code-scanning easier from a visual standpoint.<br>
Yes, I'm one of those people who will put "comment breaks" between methods<br>
in my code, too, regardless of language.<br>
<br>
And to reference your copy-paste-mutate argument....what do you think we'll<br>
be doing for every internal case-clause? Yes, that's right,<br>
copy-paste-mutate the pattern matches except that you now have your logical<br>
branches at indent-level-1 with, potentially, the rest of your code that<br>
doesn't deal with argument-specific code instead of at indent-level-0. If<br>
you need "common chunks of code" well, I'm pretty sure that's why we have<br>
methods. To wit, write your "unified interface" and case it yourself and<br>
call the argument specific sub-method.<br>
<br>
My vote: keep it as it is.<br>
<br>
<wipes-the-mud-off-his-beast-and-goes-back-to-work/><br>
<br>
-mox<br>
<br>
<br>
On Wed, May 18, 2011 at 9:39 PM, Michael Turner <<br>
<a href="mailto:michael.eugene.turner@gmail.com" target="_blank">michael.eugene.turner@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Joe, with all due respect, I think you've misinterpreted DRY. It's not a<br>
matter of writing something again because you can't find where it's already<br>
implemented. In fact, the canonical example of DRY is to write something<br>
that works for one case, and then, rather than define it as a function,<br>
template or macro, and invoke it with varying parameters, instead<br>
copy-paste-mutate for each case. In fact, the most common violations of DRY<br>
are *precisely* when you know where the repeated code is, either because<br>
you've just found it or because you've just written it.<br>
<br>
"DRY says that every piece of system knowledge should have one<br>
authoritative, unambiguous representation."<br>
<br>
<a href="http://www.artima.com/intv/dry.html" target="_blank">http://www.artima.com/intv/dry.html</a><br>
<br>
Erlang function definition syntax has two representations in the parser --<br>
for no good reason I can see. Why?<br>
<br>
"Changing syntax is *incredibly difficult* project managers get apoplectic<br>
at the thought of retesting million lines of code -"<br>
<br>
No existing code will use the syntax I suggest. So how can any of it break?<br>
<br>
I have yet to get an answer: what could this proposed change possibly<br>
break, even *theoretically*?<br>
<br>
-michael turner<br>
<br>
On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong <<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer <<a href="mailto:ixmatus@gmail.com" target="_blank">ixmatus@gmail.com</a>>wrote:<br>
<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>
Sorry, but Erlang doesn't *need* a better chance of survival. This<br>
language is not just growing, it's booming. Changing core language<br>
features that are solid, well thought out, and non-harmful (in other<br>
words, they are, FEATURES) to make it more "adoptable" is a lot like<br>
someone saying, "you have to quit that quirky smile so other people will<br>
like you more."<br>
<br>
</blockquote>
<br>
Languages survive forever once they get to the point where<br>
<br>
1) legacy applications in the language still earn money<br>
2) it costs more to convert to a new language than maintain the<br>
existing app in the old language<br>
<br>
Erlang reached this point, many years ago.<br>
<br>
Right now Erlang companies have a commercial advantage<br>
over non-erlang companies and so there is not much point in<br>
trying to spread the language further - you just loose your commercial<br>
advantage.<br>
<br>
/Joe<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sometimes, yes, there are features in a language that could use<br>
refinement - but many times, in a mature language, the ratio between<br>
need and usefulness in refining a feature further, drops significantly.<br>
<br>
Instead of changing something that is solid, educate the people that<br>
have a hard time grasping it, build killer example applications that<br>
exhibit the quirky style and idioms to a T - people /will/ follow it,<br>
almost to a religious end.<br>
<br>
That's actually what I like about Erlang the most, the documentation has<br>
so many gems in it like the efficiency guide (where many common idioms<br>
are expressed with clear DO and DON'T DO examples) and style guide.<br>
<br>
RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more<br>
consistent than many languages I've touched.<br>
<br>
Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is<br>
less consistent than Erlang's is in my opinion. The issue you are<br>
attempting to get at is (again) an educational and experience one, not<br>
something that is inherently wrong with the language or its expression<br>
itself.<br>
<br>
I'm actually baffled by the efforts people are putting into different<br>
Erlang VM frontends that look like Ruby or Python. Good on them for<br>
exercising the freedom of open source but /why/? Erlang's syntax is<br>
almost beautiful to me now after using it, it's so well suited for what<br>
Erlang is good at!<br>
<br>
Erlang isn't that great for general purpose programming - you use<br>
Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault<br>
tolerance, easy parallelism (which isn't easy!), and hot code<br>
loading. Features that are so difficult to do in the traditional<br>
imperative environment that (to date) I have not seen a single<br>
implementation of any one of those features that even approaches the<br>
completeness of Erlang's.<br>
<br>
Michael Turner <<a href="mailto:michael.eugene.turner@gmail.com" target="_blank">michael.eugene.turner@gmail.com</a>> writes:<br>
<br>
> Another objection raised against this syntax change is that all<br>
> functional languages violate DRY in this manner, so it's OK if Erlang<br>
> does it too. This is a Principle of Least Surprise argument, and not<br>
> bad as far as it goes. But how far does it go?<br>
><br>
> Erlang will have a better chance of greater success and survival if you<br>
> consider your recruitment base to be the overwhelming majority of<br>
> programmers. And from what I can tell,<br>
><br>
> <a href="http://www.langpop.com" target="_blank">http://www.langpop.com</a><br>
><br>
> the overwhelming majority of programmers have no experience to speak<br>
> of, when it comes to functional programming languages. Appealing to the<br>
> "cross-training" benefit of coming from other FP languages seems like a<br>
> pretty weak argument. Especially since all I'm asking for here is<br>
> syntactic consistency *within* Erlang -- a PLoS argument in itself.<br>
><br>
> Richard O'Keefe suggests that the syntactic consistency goal is better<br>
> met by allowing a kind of limited-scope special-case fun name,<br>
> permitting, e.g.<br>
><br>
> Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end.<br>
><br>
> I could get behind that too, but I don't follow his reasoning from<br>
> syntactic consistency, which is apparently that an unnamed fun has a<br>
> name, it's just the degenerate case of a name. It's really there. We<br>
> just can't see it. Hm, really? If that were true in Erlang as it<br>
> stands, shouldn't I be able to write it this way?<br>
><br>
> Fact = fun (0) -> 1; (N) -> N*''(N-1) end.<br>
><br>
> Looks like it's not quite that simple. It compiles, but it doesn't know<br>
> what module to look in for '', when it comes time to execute. In the<br>
> shell, I get an error indicating that it tried to resolve ''/1 as a<br>
> shell command. Even if I put it in a .erl file and compile it, there's<br>
> no obvious way to tell the compiler what module to look in. ?MODULE:''<br>
> doesn't work. Nor does '':'', which I tried just for the hell of it.<br>
><br>
> What Richard's suggesting appears to require a rigorous re-think of how<br>
> scopes are defined in Erlang. What I'm suggesting amounts to simply<br>
> asking the compiler to do some of your tedious keying for you.<br>
><br>
> -michael turner<br>
><br>
><br>
> On Wed, May 18, 2011 at 6:16 PM, Michael Turner <<br>
> <a href="mailto:michael.eugene.turner@gmail.com" target="_blank">michael.eugene.turner@gmail.com</a>> wrote:<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,<br>
> 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<br>
> DRY principle ("Don't Repeat Yourself"). And it lends itself to<br>
> reading a function definition as a set of cases. I think for Erlang<br>
> newbies, it should therefore would be preferred: it helps<br>
> underscore the pattern-matching style of Erlang function<br>
> invocation.<br>
><br>
> It also looks a *little* bit more like the mathematical convention<br>
> for defining these sorts of functions, where you have "f(x) = ",<br>
> centered vertically to the left of a big left "{" that (left-)<br>
> encloses the list of expression/parameter-condition pairs in a<br>
> 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<br>
> here as well.<br>
><br>
> It seems to me that, if anything, this requires only a<br>
> *simplification* of the Erlang parser. That leaves only one obvious<br>
> objection: would any existing code break if Erlang syntax were<br>
> altered to allow this?<br>
><br>
> -michael turner<br>
><br>
> _______________________________________________<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/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+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX<br>
8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN<br>
aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S<br>
QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf<br>
i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw<br>
h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc=<br>
=GGPU<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<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/listinfo/erlang-questions</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
_______________________________________________<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/listinfo/erlang-questions</a><br>
<br>
<br>
</blockquote></blockquote>
<br>
<br></div></div><font color="#888888">
-- <br>
Using Opera's revolutionary e-mail client: <a href="http://www.opera.com/mail/" target="_blank">http://www.opera.com/mail/</a></font><div><div></div><div><br>
_______________________________________________<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/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div></div>
<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>
<br></blockquote></div><br>