"<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">... because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY<br>FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN."</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;">And (he says, ears ringing slightly) that somehow makes it OK for any other part of the documentation to be wrong, even when your average learner is far more likely to encounter the erroneous passage first?</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;">I eventually ran across the reference manual description.</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;">Thanks for the update about the proportions of time spent scanning vs. parsing. I'm under the influence of something I heard Bill Joy (then a student of Sue Graham's) say about lex and yacc back around 1980 or so. In any case, can we at least agree that the change I suggest is going to have minimal impact on parsing times?</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 class="Apple-style-span" style="font-family: arial; border-collapse: separate; "><div>
"If both the existing readable alternative and the proposed horrible one are supported, the code *has* to increase in volume, and *has* to become less maintainable."</div><div><br></div><div>Even if it actually reduces the number of grammar rules, or keeps the number the same, and even if it means the same amount of head-match checking we have now?</div>
<div><br></div><div>"You are attacking one of the features of Erlang that I have found most helpful."</div></span></span></font></div><div><br></div><div>I found this "feature" helpful in a way myself: from doing some Prolog programming, I had some experience with writing code in this pattern. But when I was doing Prolog programming, I had the same complaint about Prolog: dreary repetition of redundant identifiers where whitespace and indentation would (I thought) enhance readability. It took some getting used to. But I suppose I could have learned to love it if I'd done more Prolog programming.</div>
<div><br></div><div>We have an eye of the beholder problem, here, obviously.</div><div><br></div><div>-michael turner</div><div><br></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font><div class="gmail_quote">2011/5/20 Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On 20/05/2011, at 5:29 PM, Michael Turner wrote:<br>
> "- it's not faster (compile time, might even make compiling slower)"<br>
<div class="im">><br>
> You've got to be kidding. It's long been known: the time complexity of parsing is overwhelmingly dominated by scanning. Code written in the form I propose would have fewer tokens to scan.<br>
<br>
</div>That used to be true.  However, it's not clear that it _is_ true when the parser is<br>
written in Yecc, as the Erlang parser is.  And it's not terribly important anyway,<br>
because in the compilers I know anything about, the cost of scanning AND parsing<br>
put together is less than half the total time.  (For example, one body of code that<br>
I work with is parsed and semantic checked in under a second, but takes about 90<br>
seconds for code generation.)<br>
<br>
I just wrote a parser for someone else's scripting language last week.  Scanning<br>
took less time than parsing, and the only reason code generation doesn't dominate<br>
both is that it doesn't do any. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
><br>
> "- it doesn't make the parser code easier to maintain"<br>
><br>
> It might, actually. See above.<br>
<br>
</div>If both the existing readable alternative and the proposed horrible one are<br>
supported, the code *has* to increase in volume, and *has* to become less<br>
maintainable.<br>
<div class="im"><br>
><br>
> "- it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though."<br>
><br>
> Yes, it is. Not to mention that the documentation on Erlang syntax is due for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the section "Syntax of funs", here:<br>

><br>
>   <a href="http://www.erlang.org/doc/programming_examples/funs.html#id59209" target="_blank">http://www.erlang.org/doc/programming_examples/funs.html#id59209</a><br>
><br>
> Yes, believe it: no coverage of the multi-clause case.<br>
<br>
</div>Yes, because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY<br>
FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN.<br>
<br>
        1. You want to learn about syntax?<br>
           Check the reference manual.<br>
        2. You want to learn about something that goes<br>
           in expressions?<br>
           Check the expressions chapter.<br>
        3. You want to learn about a particular kind of<br>
           form?  Check the table of contents for that chapter.<br>
        4. See 'fun expressions'?<br>
           Click on it.<br>
<br>
And there you are.<br>
<br>
If you deliberately don't look in the reference manual, it's not<br>
the fault of Erlang or its documenters.<br>
<br>
There are plenty of things to improve, but before complaining about<br>
the syntax, people really do have an obligation to look in the most<br>
obvious place.<br>
<div class="im">> "Oh and lastly, you could also have to consider this ambiguity ...."<br>
><br>
> It wouldn't even be an ambiguity. It would only be a weird and pointless way to write that code.<br>
<br>
</div>And omitting the function name _anywhere_ in the first place is a weird and<br>
pointless way to write code.<br>
<br>
You are attacking one of the features of Erlang that I have found most<br>
helpful.<br>
<br>
</blockquote></div><br></div>