Record selectors (again)

[Bjorn Gustavsson]

Thomas Lindgren <thomasl_erlang@REDACTED> writes:

> --- Bjorn Gustavsson <bjorn@REDACTED> wrote:
> > ... the record
> > access operation
> > could be nested inside an arbitrary expression, and
> > that also need
> > to be handled properly in all cases (probably, the
> > record access
> > needed be lifted out and done before the
> > expression).
> 
> Why is that? The record check is very much like a type
> test, so I think it could and should be done right
> where the operation occurs. (At least conceptually.)

Yes, conceptually it should occur right where the operation
occurs.

After some more thinking, it occurred to me that the code
could be transformed like follows. If the original code looks
like this

-record(vec, {x,y,z}).

t(R) ->
    2*R#vec.x+1.

the compiler could first rewrite the expression like this

t(R) ->
    2*begin #vec{x=X}=R, X end+1.

which would ultimately be translated to

t2(R) ->
    2 * begin
            {vec,X,_,_} = R,
            X
        end + 1.

That will currently not work in a guard, so guards would have
to be handled in another way. One way would be allow matching
in guards (only for compiler-generated code); another could be
to introduce a new guard BIF similar to what Thomas suggested.

Maybe, just maybe, this change could make it into R10.

/Bjorn
-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB