Tue Dec 4 13:09:34 CET 2001
> X-url: http://www.bluetail.com/~rv
> To: Hakan Stenholm <>
> Subject: Re: records
> MIME-Version: 1.0
> Content-ID: <>
> Date: Tue, 04 Dec 2001 12:46:52 +0100
> From: Robert Virding <>
> Hakan Stenholm <> writes:
> >The imidiat problem can be solved by adding a guard
> >"foo(A, ...) when record(A, ...) ->" to do the type checking.
> > .......
> This is, of course, all true, BUT in the documentation records are
> defined to be tuples so it really shouldn't come as a surprise. The
> reason for this is that when records were first implemented it wasn't
> possible at that time to easily add a new datatype in the
> implementation. This has changed today.
> Seriously, how many people/apps would be severely burned if records
> *were* made their own datatype? It is possible to do but you have to
> determine which solution hurts the most.
Actualy I'm quite aware of this, there is a lot of code that relies on records
being tuples: lists:keysearch, ets tables, code change code in the AXD301 ...
so I can't say that I expect the implementation to change.
But I suppouse it would still be posible to change the tuple representation to
something else, for example:
i.e. add an extra '__record' type indicator in the tuple, '__record' should then
be a reserved key world, that should not be allowed to be used in regular code -
which stops the user from acidently putting it in tuples.
Or we might handle all tuples that start with a record name (thats defined in
any loaded file) as a record (i.e. test type and size of record). This might of
course give use obscure tuple errors instead.
More information about the erlang-questions