Constructive criticism of Erlang

[Robert Virding]

Chris Pressey <cpressey@REDACTED> writes:
>
>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.

To be consistent you would have to allow it before the final '.' of a
function definition as well.  Personally I still don't see the problem.
:-)

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

The main criteria is that guard must be side-effect free and guaranteed 
to terminate.  They should preferably also be bounded in time.

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

That was probably a mistake to explicitly discourage parse transforms.
The reason was to keep the syntax predictable but there are some pretty
neat things you could do.  One thought I have had would be to do a much
smarter macro package.

>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}).

You could express this as a parse transform but you might run into 
trouble with typing.  How do you detect that you really want/need to 
overload a +-*/ ?

	Robert