[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions

[Richard O'Keefe]

On 20/05/2011, at 5:29 PM, Michael Turner wrote:
> "- it's not faster (compile time, might even make compiling slower)"
> 
> 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.

That used to be true.  However, it's not clear that it _is_ true when the parser is
written in Yecc, as the Erlang parser is.  And it's not terribly important anyway,
because in the compilers I know anything about, the cost of scanning AND parsing
put together is less than half the total time.  (For example, one body of code that
I work with is parsed and semantic checked in under a second, but takes about 90
seconds for code generation.)

I just wrote a parser for someone else's scripting language last week.  Scanning
took less time than parsing, and the only reason code generation doesn't dominate
both is that it doesn't do any.

> 
> "- it doesn't make the parser code easier to maintain"
> 
> It might, actually. See above.

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.

> 
> "- it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though."
> 
> 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:
> 
>   http://www.erlang.org/doc/programming_examples/funs.html#id59209
> 
> Yes, believe it: no coverage of the multi-clause case.

Yes, because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY
FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN.

	1. You want to learn about syntax?
	   Check the reference manual.
	2. You want to learn about something that goes
	   in expressions?
	   Check the expressions chapter.
	3. You want to learn about a particular kind of
	   form?  Check the table of contents for that chapter.
	4. See 'fun expressions'?
	   Click on it.

And there you are.

If you deliberately don't look in the reference manual, it's not
the fault of Erlang or its documenters.

There are plenty of things to improve, but before complaining about
the syntax, people really do have an obligation to look in the most
obvious place.
> "Oh and lastly, you could also have to consider this ambiguity ...."
> 
> It wouldn't even be an ambiguity. It would only be a weird and pointless way to write that code.

And omitting the function name _anywhere_ in the first place is a weird and
pointless way to write code.

You are attacking one of the features of Erlang that I have found most
helpful.