records

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

records

Hakan Stenholm
The imidiat problem can be solved by adding a guard
"foo(A, ...) when record(A, ...) ->" to do the type checking.

This entier problem is realy due to the fact that records are not treated as a
unique data type inside the VM (virtual machine) - they are implemented as
tuples. This makes it impossible to distinguish between a record and a tuple
that happens to look like a record, this is also a problem if you have a
function like this:

% this matches both for a tuple and a record (as record is realy a special
% kind of tuple)
f(A) when tuple(A) -> .... ;
% this will never be run
f(A) when record(A,foo_rec) -> ....;

The code above must be rewritten as below to work porperly

f(A) when record(A,foo_rec) -> ....;
f(A) when tuple(A) -> .... ;

It should be noted that all record accesses and updates end up as calls to
element/2 and setelement/3 i.e. tuple manipulating operations, this is done by
the preprocessor during compilation.
Record fieldnames are converted to indexes by the preprocessor as well.

So when the code is actualy run, the VM has no idea that some tuples should
be typechecked as records rather than simple tuples, i.e. records are only
"syntactic suger" and not realy a language entity.



Reply | Threaded
Open this post in threaded view
|

records

Robert Virding-4
Hakan Stenholm <etxhste> writes:

>The imidiat problem can be solved by adding a guard
>"foo(A, ...) when record(A, ...) ->" to do the type checking.
>
>This entier problem is realy due to the fact that records are not treated as a
>unique data type inside the VM (virtual machine) - they are implemented as
>tuples. This makes it impossible to distinguish between a record and a tuple
>that happens to look like a record, this is also a problem if you have a
>function like this:
>...
>It should be noted that all record accesses and updates end up as calls to
>element/2 and setelement/3 i.e. tuple manipulating operations, this is done by
>the preprocessor during compilation.
>Record fieldnames are converted to indexes by the preprocessor as well.
>
>So when the code is actualy run, the VM has no idea that some tuples should
>be typechecked as records rather than simple tuples, i.e. records are only
>"syntactic suger" and not realy a language entity.

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.

Robert


Reply | Threaded
Open this post in threaded view
|

records

Thomas Lindgren-3

Robert Virding:
---
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.
---

My vote is for change. Cellpoint's code uses keysearch and ets/mnesia
so there will be some transitional pain. On the other hand, the
shipping system uses a frozen Erlang version too: hence, a transition
will mainly be a problem for new releases.

A compatibility mode like what Ulf suggests seems like a
good idea.

-- Thomas



Reply | Threaded
Open this post in threaded view
|

records

Chris Pressey
In reply to this post by Robert Virding-4
On Tue, 04 Dec 2001 12:46:52 +0100
Robert Virding <rv> wrote:

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

I am absolutely in favour of records graduating from syntactic sugar to
semantic data type.  I try to take abstraction to heart when I program, so
practically nothing I've written would break.

The one exception is where I have written a "general-purpose" module to
manipulate "records of any type" in a limited fashion.  I do this by
checking the first element of the tuple with element/2 and using it as a
type and/or module identifier.  This is certainly not the best practice,
and my code should probably be rethought anyway.

Ideally, the representation of a record should not be defined.

At the same time, records should probably have metadata, in the form of
functions (sort of like record_info, but which operate on a variable) in
the interests of writing generalized code that really can work on records
of any type.  (Unless generalizability is explicitly traded off for
efficiency - perhaps orddicts and dicts would be more suited for people
who want metadata.)

It might hurt less if a new way of structuring data is added to the
language, instead of replacing records.  For example, 'records' could be
left alone for backwards compatibility and a new 'struct' or 'aggregate'
or 'object' language feature could appear.

Lastly, although this next suggestion is far from crucial, I think it is a
neat idea that fits in with improved records.  That is, it would be nice
if there could be guards on fields in records much like there are guards
on functions.  Imagine:

-record(person,
[
  age when integer(age),
  name = "John Doe" when list(name),
  etc
]).

An association between record name and module name and/or mnesia table
name could also be further exploitable.

But please, consider that I *am* a mad scientist who is also of the
opinion that the restriction that guards operate in constant time be a
compile-time option, so take what I say with a grain of salt :)

Chris

"There's definately, definately, definately no logic to human behaviour"
  -- Bjork