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

[Michael Turner]

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

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?

I eventually ran across the reference manual description.

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?

"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."

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?

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

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.

We have an eye of the beholder problem, here, obviously.

-michael turner


2011/5/20 Richard O'Keefe <ok@REDACTED>

>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110520/33913eaa/attachment.htm>