Record selectors (again)

Thomas Lindgren thomasl_erlang@REDACTED
Wed Jun 23 19:06:10 CEST 2004

--- Bjorn Gustavsson <bjorn@REDACTED> wrote:
> Yes, I agree. We also want to change the behaviour
> to something
> like
> unsafely_access_a(R) ->
>      case R of
>         {rec,A,_} -> A;
>         _ -> erlang:fault(badarg)
>      end.
> similar to how other record operations are handled.


I think the general principle should be to avoid
having any underlying tuples show through (they are
implementation details).

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

The place where this breaks down is inside guards,
since they are constrained in what they can look like.
(E.g., no if-expressions in guards, so one can't use
the translation above.) But instead of lifting out the
tests, how about the following:

1. First expand X#rec.fld into a new guard/BIF:

  record_element(Req_tag, Req_arity, Record, Arg)

During compilation, we thus generate something like:

% -record(rec, {fld1, fld2, fld3}).

   X#rec.fld2 => record_element(rec, 3, X, 2)

This first checks that X is a record with name 'rec'
and three fields, and if so, returns field two.  (For
example, if the record is implemented as a tuple, this
means as usual that X has to be a tuple with 4
elements, where element 1 is the atom 'rec'.)
Otherwise it exits/fails.

2. We now have just another BIF, which can be compiled
just like all other BIFs that occur in expressions or

Also note that an optimizing compiler could convert
record_element/4 into element/2 (and further) if it
knew that X was the right kind of record.


Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish. 

More information about the erlang-questions mailing list