[erlang-questions] Bug ?!

[Richard A. O'Keefe]

Robert Virding wrote:

> I believe it is important to keep things clean, consistent and elegant 
> otherwise you will end up with a language built on exceptions.

Mats Cronqvist <mats.cronqvist@REDACTED> replied:
	   aha! so that's why this works?
	
	-define(foo,bla.
	go()->?foo.
	
I wrote the paper "Delenda est preprocessor" *years* ago.
Really, if all that was originally wanted was named constants,
just
    <variable> = <constant expression>.
at top level would have done the trick.


	   more to the point, i still fail to see how this;
	
	   receive
	     X#r.a -> do_a();
	
	   is more unclean, inconsistent and inelegant than this;
	
	   XRA = X#r.a,
	   receive
	     XRA -> do_a();
	
	   but hey, i'll take richard & richard's word for it.
	
Consider this argument:

    At present, EVERY place that a variable may appear in a pattern,
    it is legal for either a bound variable (check it!) or an unbound
    variable (bind it!) to appear; therefore, everywhere that a
    variable may appear in a pattern it is legal to place a wildcard.

    This addition breaks that rule into a thousand sharp-edged splinters.
    I've finally put my finger on what I don't like about it.

Consider also that we currently have "two-part matching":
    PATTERNS check the SHAPE of terms,
    GUARDS   check the VALUES.
(Yes, I know this is imprecise, but we all know what I mean.)
So at the moment, there is one obvious place to put X#r.a:
it is *not* a test for a particular shape, so it must go in the guard.
(Just like hd, tl, and element, which it so very closely resembles.)

    receive
        XRA when XRA = X#r.a -> do_a();

isn't hard to write, and currently isn't hard to think.

There is a weakness in this argument:  testing whether something is
a particular kind of record is *obviously* a test of its shape, so
it really does belong in the pattern, not the guard.  Arguably,
"is some kind of list" and "is some kind of tuple" are also "shape"
questions rather than "value" questions.  So we could imagine an
enhanced pattern language including something like (this is off the
cuff; NOT a polished suggestion):

    [*]		a list of any size (including 0 or 1)
    {*}		a tuple of any size (including 0 or 1)
    #r{*}	an instance of record type r
    <<*>>	a binary of any size

This is reasonably iconic, "*" should suggest 0 or more,
and the fact that there is no variable or wildcard there correctly
suggests that you can't bind anything to this inner "sequence".