<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="im"><br></div>Because (a) the generalisation I suggested was<br> fun <optname> <args> <etc><br> {; <optname> <args> <etc>}...<br> end<br>where <optname> is either a VARIABLE or omitted,<br>
and is identical in each clause.<br>But '' is NOT a variable, now is it?<br><br></blockquote><div><br></div><div>Thank you for the clarification. I see now that you had the fun "name" in upper case, in the code sample on the other thread. Perhaps that's enough for most people on this list to infer -- automatically and immediately -- that you really meant "variable" even when you were saying "name". But I've mostly been using regular programming languages for the last 30 years, which offer a little more freedom in variable naming, and I still fail sometimes to automatically think "variable" just because a non-macro identifier starts in upper case -- which is another old Prolog convention I always had trouble with. I apologize for being, um, you know ... merely average?</div>
<div><br></div><div>It's certainly a solution to a problem, I'd like to see it (or something like it) succeed, and I wish you luck with it.</div><div><br></div><div>-michael turner</div><div><br></div><br><div class="gmail_quote">
On Fri, May 20, 2011 at 4:42 PM, Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</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"><br>
On 19/05/2011, at 2:18 AM, Michael Turner wrote:<br>
<br>
> Another objection raised against this syntax change is that all functional languages violate DRY in this manner, so it's OK if Erlang does it too. This is a Principle of Least Surprise argument, and not 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 consider your recruitment base to be the overwhelming majority of programmers.<br>
<br>
</div>I had a lengthy response to this which SquirrelMail (apparently that's the name of the<br>
WebMail system here) managed to destroy. Sigh.<br>
<br>
Erlang has already survived very well for 30+ years with pretty much its present syntax.<br>
It has also succeeded very well.<br>
<div class="im"><br>
> 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 of,<br>
<br>
</div>Erlang's strengths come from being DIFFERENT.<br>
<br>
There's a thing much discussed, much derided, and much practiced in Australia<br>
and New Zealand, called "cultural cringe". Look it up. Cultural cringe hurt<br>
ISO Prolog. (Prolog _had_ a notation for integers in bases 2..36, but the<br>
ISO committee threw it away and copied C instead, for base 16 only. They<br>
also changed the precedence of at least one operator to match C better than Prolog.)<br>
If we go by fashion, we'll change Erlang to look like PHP or COBOL.<br>
(Estimates of COBOL code volume range from 1e11 to 5e11 lines.)<br>
<br>
Oh, I'd like all sorts of changes to Erlang syntax. After Haskell, I find it<br>
quite verbose. I once designed a "Haskerl" syntax for Erlang that reduced the<br>
line count by a factor of 1.6. But syntax is not the most important thing about<br>
Erlang (or LFE would not be of interest), and it's not really what needs the<br>
most attention. I think the Dialyzer is easily the most dramatic and important<br>
thing that's happened to Erlang in some time, and if we want to talk about<br>
improvements, that might have the highest payoff.<br>
<div class="im"><br>
> when it comes to functional programming languages. Appealing to the "cross-training" benefit of coming from other FP languages seems like a pretty weak argument. Especially since all I'm asking for here is syntactic consistency *within* Erlang -- a PLoS argument in itself.<br>
><br>
> Richard O'Keefe suggests that the syntactic consistency goal is better met by allowing a kind of limited-scope special-case fun name, 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 syntactic consistency, which is apparently that an unnamed fun has a name, it's just the degenerate case of a name. It's really there. We just can't see it. Hm, really? If that were true in Erlang as it stands, shouldn't I be able to write it this way?<br>
><br>
> Fact = fun (0) -> 1; (N) -> N*''(N-1) end.<br>
<br>
</div>Because (a) the generalisation I suggested was<br>
fun <optname> <args> <etc><br>
{; <optname> <args> <etc>}...<br>
end<br>
where <optname> is either a VARIABLE or omitted,<br>
and is identical in each clause.<br>
But '' is NOT a variable, now is it?<br>
<br>
And (b) the generalisation I suggested was to use<br>
the SAME <optname> in each clause, and a completely<br>
missing name is NOT the same as an empty but present<br>
atom. (This is like the way that in SQL92 a NULL<br>
string is very different from an empty string.)<br>
<br>
And note that I did not say that this is what Erlang *DOES*<br>
do but what it might some day be *EXTENDED* to do as a way<br>
of letting people write recursive funs.<br>
<br>
By the way, some earlier posting from somebody said that<br>
Erlang was alone in allowing multiple clauses in funs.<br>
Not so.<br>
<br>
Erlang Haskell ML<br>
yes yes no Are multiple arguments allowed in a lambda?<br>
yes no yes Are multiple clauses allowed in a lambda?<br>
<br>
Erlang:<br>
fun ([_|_]) -> true<br>
; ([]) -> false<br>
end<br>
<br>
Standard ML:<br>
fn (_:_) -> true<br>
| [] -> false<br>
<br>
While you *can* write<br>
<br>
val default = fn (SOME x) _ -> x<br>
| NONE d -> d<br>
<br>
in SML, it is normal practice to write<br>
<br>
fun default (SOME x) _ = x<br>
| default NONE d = d<br>
<br>
and I think most SML programmers would regard the first alternative<br>
as perversely unreadable.<br>
<div class="im"><br>
><br>
><br>
> What Richard's suggesting appears to require a rigorous re-think of how scopes are defined in Erlang.<br>
<br>
</div>Not in the least. The scope of a function name variable would be the function itself,<br>
just like any other variable in the arguments of the clauses.<br>
<br>
1> X = 1.<br>
1<br>
2> F = fun (X) -> ok ; (_) -> uh_oh end.<br>
#Fun<erl_eval.6.13229925><br>
3> F(2).<br>
ok<br>
<br>
See how the X in the fun was *not* the X outside?<br>
Same rule exactly for fun-names.<br>
<br>
> W<br>
<div class="im"><br>
> hat I'm suggesting amounts to simply asking the compiler to do some of your tedious keying for you.<br>
><br>
> -michael turner<br>
<br>
</div>(A) If repeating the function name is the most tedious keying you have,<br>
how fortunate you are!<br>
(B) People with a decent text-editor don't have a problem anyway.<br>
One reason for putting case, if, fun, and receive semicolons at<br>
the beginning of the line is so that when you end a line with a<br>
semicolon, the editor can automatically<br>
- go back to the first preceding line to have a letter or '<br>
in column 1;<br>
- copy the function name into a work space<br>
- go back where it started<br>
- insert the work space.<br>
I did this years ago for Prolog. I found it distracting, so<br>
switched the feature off, but anyone who really really hated<br>
retyping function names should be able to program this in a<br>
few minutes.<br>
(C) The names are not there for the benefit of the compiler, but<br>
for the benefit of PEOPLE. When you are reading someone else's<br>
code, it HELPS to see the function name in each clause.<br>
And that's why I'm willing to give head-room to fun-names.<br>
I really loathe seeing a bare argument list without any indication<br>
of what it's the argument list *of*.<br>
<div class="im">><br>
><br>
> On Wed, May 18, 2011 at 6:16 PM, Michael Turner <<a href="mailto:michael.eugene.turner@gmail.com">michael.eugene.turner@gmail.com</a>> wrote:<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>
</div>I do not. In fact I find the first version of factorial rather horrible.<br>
If you really want to do that, you can write<br>
<br>
factorial(N) -> case N of<br>
(1) -> 1;<br>
(N) -> N*factorial(N-1) end.<br>
<br>
right now. Just don't ask me to read it for anything less than NZD 400/hour.<br>
<div class="im">><br>
> It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself").<br>
<br>
</div>The DRY principle was not handed down on Mt Sinai.<br>
It is a rule of thumb, no more and no less.<br>
And indeed, it violates something I have found to be an excellent<br>
guide, that a *controlled* use of redundancy is an aid to correctness.<br>
<br>
For example, :- spec is redundant, but<br>
- it lets Erlang detect a difference between what you DID write and<br>
what you MEANT to write<br>
- someone can read the :- spec without having to read the code.<br>
<br>
There are other examples of good redundancy in Erlang.<br>
<br>
The keyword here, of course, is *controlled* redundancy; just enough to<br>
do something useful (like helping human beings read your code, or<br>
permitting some check), not too much.<br>
<div class="im"><br>
> It also looks a *little* bit more like the mathematical convention for defining these sorts of functions, where you have "f(x) = ", centered vertically to the left of a big left "{" that (left-)encloses the list of expression/parameter-condition pairs in a two-column format, e.g.,<br>
<br>
</div>That is one mathematical convention, followed in Miranda, and leading to<br>
guards in Haskell and Erlang. It is regrettable that SML does not have<br>
them, but at least there's the 'nowhere' preprocessor to provide them.<br>
<br>
There are other mathematical conventions.<br>
"The Fibonacci numbers are defined using the linear recurrence relation<br>
<br><br>
with seed values:<br>
<br><br>
<br><br>
" (Wikipedia entry on recurrence relations).<br>
<br>
This is the style that Haskell, Clean, Mercury, SML, CAML, and so on follow.<br>
<br>
> It seems to me that, if anything, this requires only a *simplification* of the Erlang parser. That leaves only one obvious objection: would any existing code break if Erlang syntax were altered to allow this?<br>
<br>
Probably not. However, the parser is a tiny part of the Erlang system, even a<br>
tiny part of the compiler. Simplicity of the parser per se is hardly worth<br>
worrying about. What matters is having a readable language.<br>
<br>
Even if the change were made, every Erlang book and paper ever printed shows<br>
the existing style. How would newbies react to code that looked like nothing<br>
they had ever been taught about? What would happen to Erlang language-sensitive<br>
editing tools, would they cope with the new syntax? I know that the crude<br>
pretty-printer I wrote for Erlang would have trouble, and the commands I now<br>
find useful for moving to the next/previous clause would cease to work.<br>
<br>
<br>
<br>
<br></blockquote></div><br>