Constructive criticism of Erlang

[Shawn Pearce]

Robert Virding <rv@REDACTED> scrawled:
> Chris Pressey <cpressey@REDACTED> writes:
> >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 +-*/ ?


I can see value in having +-*/ overloaded to some extent on a tuple,
as we have two issues -- one is the same as Chris Pressey, we want to
be able to keep unit information attached to the values being
manipulated -- but the other is that Erlang really doesn't have a full
numeric tower and therefore cannot operate as precisely as we'd like
with decimal values.

I wonder if erts could be extended to recognize that when it
gets two tuples as the arguments of a math operator that it uses the
first element of the first tuple as a package name, and calls a function
from that package to deal with the mess:

	{useng, 12, 3} + {useng, 6, 2}

....

-module(useng).

add({useng, AFt, AIn}, {useng, BFt, BIn}) ->
	RIn = AIn + BIn,
	if
		RIn >= 12 ->
			{useng, AFt + BFt + 1, RIn - 12};
		RIn < 12 ->
			{useng, AFt + BFt, RIn};
	end.

The other approach might be that there is some sort of table in the
emulator that binds the functions and types.  For instance, create an
ets table that holds 2-tuples of the form:

	{{a_type, b_type}, {module, function}}

where a_type and b_type are the first elements of the tuples given to
the math operator.  erts just does an ets table lookup for the key
{a_type, b_type} and gets back the module and function to invoke via
apply to handle the arith op.

Yes, its slower than doing the math directly in the function, but it
does let us poor users develop our own math packages for complex
numbers.

Of course, it also would let us add things that aren't really numeric...
which some might say adding two records together (as I do above) isn't
numeric....

--
Shawn.

  ``If this had been a real
    life, you would have
    received instructions
    on where to go and what
    to do.''