1 Records
For the purposes of illustration, we will demonstrate the use of records using an imaginary dialogue with the Erlang shell. The Erlang evaluator does not support records so you will not be able to reproduce this dialogue.
1.1 Records vs Tuples
The main advantage of using records instead of tuples is that fields in a record are accessed by name, whereas fields in a tuple are accessed by position. To illustrate these differences, suppose that we want to represent a person with the tuple
{Name, Address, Phone}
.We must remember that the
Name
field is the first element of the tuple, theAddress
field is the second element, and so on, in order to write functions which manipulate this data. For example, to extract data from a variableP
which contains such a tuple we might write the following code and then use pattern matching to extract the relevant fields.Name = element(1, P), Address = element(2, P), ...Code like this is difficult to read and understand and errors occur if we get the numbering of the elements in the tuple wrong. If we change the data representation by re-ordering the fields, or by adding or removing a field, then all references to the person tuple, wherever they occur, must be checked and possibly modified.
Records allow us to refer to the fields by name and not position. We use a record instead of a tuple to store the data. If we write a record definition of the type shown below, we can then refer to the fields of the record by name.
-record(person, {name, phone, address}).For example, if
P
is now a variable whose value is aperson
record, we can code as follows in order to access the name and address fields of the records.Name = P#person.name, Address = P#person.address, ...Internally, records are represented using tagged tuples:
{person, Name, Phone, Address}1.2 Defining a Record
This definition of a person will be used in many of the examples which follow. It contains three fields,
name
,phone
andaddress
. The default values forname
andphone
is "" and [], respectively. The default value foraddress
is the atomundefined
, since no default value is supplied for this field:-record(person, {name = "", phone = [], address}).1.3 Creating a Record
A new
person
record is created as follows:> #person{phone=[0,8,2,3,4,3,1,2], name="Robert"}. {person, "Robert", [0,8,2,3,4,3,1,2], undefined}Since the
address
field was omitted, its default value is used.There is a new feature introduced in Erlang 5.1/OTP R8B, with which you can set a value to all fields in a record, overriding the defaults in the record specification. The special field
_
, means "all fields not explicitly specified".> #person{name = "Jakob", _ = '_'}. {person, "Jakob", '_', '_'}It is primarily intended to be used in
ets:match/2
andmnesia:match_object/3
, to set record fields to the atom'_'
. (This is a wildcard inets:match/2
.)1.4 Accessing a Record Field
> P = #person{name = "Joe", phone = [0,8,2,3,4,3,1,2]}. {person, "Joe", [0,8,2,3,4,3,1,2], undefined} > P#person.name. "Joe"1.5 Updating a Record
> P1 = #person{name="Joe", phone=[1,2,3], address="A street"}. {person, "Joe", [1,2,3], "A street"} > P2 = P1#person{name="Robert"}. {person, "Robert", [1,2,3], "A street"}1.6 Type Testing
The following example shows that the guard succeeds if
P
is record of typeperson
.foo(P) when is_record(P, person) -> a_person; foo(_) -> not_a_person.1.7 Pattern Matching
Matching can be used in combination with records as shown in the following example:
> P = #person{name="Joe", phone=[0,0,7], address="A street"}. {person, "Joe", [0,0,7], "A street"} > #person{name = Name} = P, Name. "Joe"The following function takes a list of
person
records and searches for the phone number of a person with a particular name:find_phone([#person{name=Name, phone=Phone} | _], Name) -> {found, Phone}; find_phone([_| T], Name) -> find_phone(T, Name); find_phone([], Name) -> not_found.The fields referred to in the pattern can be given in any order.
1.8 Nested Records
The value of a field in a record might be an instance of a record. Retrieval of nested data can be done stepwise, or in a single step, as shown in the following example:
-record(person, {name = #name{}, phone}). -record(name, {first = "Robert", last = "Ericsson"}). demo() -> P = #person{name= #name{first="Robert",last="Virding"}, phone=123}, First = (P#person.name)#name.first.In this example,
demo()
evaluates to"Robert"
.1.9 Example
%% File: person.hrl %%----------------------------------------------------------- %% Data Type: person %% where: %% name: A string (default is undefined). %% age: An integer (default is undefined). %% phone: A list of integers (default is []). %% dict: A dictionary containing various information %% about the person. %% A {Key, Value} list (default is the empty list). %%------------------------------------------------------------ -record(person, {name, age, phone = [], dict = []}).-module(person). -include("person.hrl"). -compile(export_all). % For test purposes only. %% This creates an instance of a person. %% Note: The phone number is not supplied so the %% default value [] will be used. make_hacker_without_phone(Name, Age) -> #person{name = Name, age = Age, dict = [{computer_knowledge, excellent}, {drinks, coke}]}. %% This demonstrates matching in arguments print(#person{name = Name, age = Age, phone = Phone, dict = Dict}) -> io:format("Name: ~s, Age: ~w, Phone: ~w ~n" "Dictionary: ~w.~n", [Name, Age, Phone, Dict]). %% Demonstrates type testing, selector, updating. birthday(P) when record(P, person) -> P#person{age = P#person.age + 1}. register_two_hackers() -> Hacker1 = make_hacker_without_phone("Joe", 29), OldHacker = birthday(Hacker1), % The central_register_server should have % an interface function for this. central_register_server ! {register_person, Hacker1}, central_register_server ! {register_person, OldHacker#person{name = "Robert", phone = [0,8,3,2,4,5,3,1]}}.