[erlang-questions] Bug ?!

[Richard Carlsson]

Richard A. O'Keefe wrote:
> We've seen a number of explanations for why <variable>#<record>.<field>
> isn't allowed in a pattern match.  Basically, it's because that expands
> to element(<field number>, <variable>), and that happens not to be allowed.

To make things clear to everybody: the syntax checking stage (which 
happens before expansion) has never allowed it, regardless of whether it 
could be translated to reasonable code. It has simply never been done.

> Of course, it could be given a different expansion, so the question
> of whether field access SHOULD be allowed in a pattern remains open.

Precisely.

> My first reaction was "well, a reasonable user wanted to use it, so why not?"
> The more I thought about it, the less I liked it, but I can't quite put my
> finger on why not.  It's something to do with blurring the distinction
> between patterns and expressions too much.  Can anyone else put it into words?

I'll make an attempt: All currently allowed patterns describe the 
structure of the data in a compositional way, outside-in, with variables 
for the blank parts. This goes even for string-prefix patterns using the 
++ operator, as in `f("xyz"++Xs)->...' (or even Haskell's n+k patterns). 
Previously bound variables add an extra constraint: `{foo, X}->...', 
where X is a bound variable, is equivalent to `{foo, Y} when Y =:= X 
->...' (where Y is a new variable), but the pattern is still compositional.

Allowing a pattern such as X#r.a, however, introduces a more general 
computation: it does not describe a record #r{a=..., ...} in the 
position of the pattern, but a constraint `{foo, Y} when Y =:= X#r.a 
->...' (which in this case performs a decomposition). If this is 
allowed, there is no real reason why not arbitrary expressions (that may 
occur in guards) should be allowed, using the same expansion - but that 
would probably make guards rather unreadable and go against the "spirit 
of patterns" - it breaks compositionality (in the intuitive sense - I'm 
not trying to be formal here).

`X#r.a' has a superficial look and feel that is close to the other 
(allowed) record patterns, which is probably why one may easily think 
that it should also be allowed, but it is really rather different.

	/Richard