Constructive criticism of Erlang

[Chris Pressey]

Hi again.

I hope that everyone can understand: it is because I love Erlang that I
must critique it.

Keep in mind that it is not only Erlang that is guilty of the flaws I
list below - many other high-level languages are as well.  (If I were to
construct a list like this for Perl or C++ it could very well fill
several volumes :-)

Also, please excuse me if these issues have already been addressed in
the newest versions of the language/revisions of the compiler.

I realize I might not have much luck in catching the ear of anyone who
is actually responsible for future design of the Erlang language, on
this list - presumably, Ericsson is the responsible party for that,
open-source does not mean open-design.  However, I still think these are
valid thoughts which might be interesting to Erlang programmers.

1. Having semicolons as statement seperators instead of statement
terminators is basically *annoying* during program maintainance (while
adding or removing a statement.)  Having an extraneous semicolon
(especially before an 'end' token) generate a warning rather than an
error would be more pleasant.

2. I don't think I agree with the idea that only some "specially
selected" functions should be allowed in guards.  This makes guards
semantically unorthogonal.  I think guards should be thought of as mere
syntactic sugar, and the compiler will choose what it determines to be
the most efficient manner of implementing the guard.  This would help in
writing more readable programs.

I understand this makes the compiler more complex though, but even under
the current system, more BIFs should be allowed in guards.  I don't see
why I can't say "when element(N, T) == 0", for example; that's fairly
lightweight, no?

3. Speaking of making the compiler complex, it would be great if it
could deduce the legal set of types used by each argument in each
function (perhaps using supplied predicate guards such as record/2), and
complain at compile-time if it is ever violated in a subsequent function
call.  I believe this would be the simplest way to apply "strong typing"
to Erlang (since it doesn't change any existing semantics of the
language (except for those semantics that are already illegal anyway!))
There's no way it could catch all type errors (send, fun, etc.) but it
would be a great step in that direction.

And that's basically *it*.  I'm a total cynic and I can only find
*three* flaws in Erlang that are serious enough to annoy me.  This
language is a thing of beauty!

There are other "features" I have in mind but I can tell that they are
far enough beyond the scope of Erlang that adding them would result in a
new, descendant language.  This leads me to several questions, though.

Just how "discouraged" is "discouraged" when it comes to Parse
Transformations?  Is there any example code for a Parse Transformation?
(I imagine not, since it's discouraged.)  I can see why this would be,
Erlang is supposed to be a fairly predictable language.  Playing with
the grammar makes it less predictable, and thus should be avoided.  I
don't wholly disagree.

But say I want to build my own numeric data type.  Naturally my source
will be more readable if I can overload the arithmetic operations +-*/
on it - could I express this as a parse transformation?  Basically I'd
be representing a numeric datum as a tuple, so I'd want to be able to
translate {1, etc} + {2, etc} into mynumeric:add({1, etc}, {2, etc}).

I'd be very interested in any feedback!

_chris

-- 
Change rules.
Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List
http://www.catseye.mb.ca/list.html