{"id":563,"date":"2007-12-16T20:29:19","date_gmt":"2007-12-16T20:29:19","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/2007\/12\/16\/records-in-erlang\/"},"modified":"2007-12-16T20:29:19","modified_gmt":"2007-12-16T20:29:19","slug":"records-in-erlang","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2007\/12\/16\/records-in-erlang\/","title":{"rendered":"Records in Erlang"},"content":{"rendered":"

One of the things I discovered since writing part one of my Erlang introduction is that Erlang has grown a lot over the last few years. For example, the idiom of tagged tuple as a way of creating a record-like structure has been coded into the language. There is, unfortunately, a bit of a catch. They aren’t really<\/em> added to the language. Instead, there’s a pre-processor in Erlang, and records
\nare defined by translation in the pre-processor. This to me typifies one of the less attractive
\nattributes of Erlang: much of Erlang has a very ad-hoc flavor to it. There are important high-level features – like record data and modules – which aren’t really entirely part of the language. Instead, they’re just sort of spliced in however it was easiest for the implementors to cram ’em in. And there are other things that were added to later versions of the language that, while first class, are awkward – like the “fun” prefix for first-class functions.<\/p>\n

The effect of that kind of thing is mainly syntactic. The implementation is good enough that
\neven though things like records are really pre-processor constructs, they feel almost as
\nif they’re built-ins.<\/p>\n

Anyway – let’s take a look at records.<\/p>\n

<\/p>\n

As I mentioned in the first Erlang post, the basic data type idiom of Erlang is
\nbased on tuples. Typically, to represent a data type, you create a tuple whose first element
\nis an atom which identifies the type of the tuple.<\/p>\n

That’s exactly what the record facility does. You define a record type, and it’s built using
\na tuple whose first element is the atom which names the record type. The rest of the entries of a record tuples are the fields of the record, which are represented by alternating field names (as atoms) and field values. So, for example, if we
\nwanted to define a binary tree like the following Haskell:<\/p>\n

\ndata Tree a = Node (Tree a) (Tree a) | Leaf a\nsample = Node (Node (Leaf 1) Leaf 2) (Leaf 3)\n<\/pre>\n
 Would be implemented as something like the following in tuples in Erlang:<\/p>\n
\nSample = {node,\nleft, {node,\nleft, {leaf, value, 1},\nright, {leaf, value, 2}},\nright, {leaf, value, 3}}\n<\/pre>\n
 That’s obviously pretty ugly, and pretty laborious to code. The record-feature in the meta-language makes it much more convenient:<\/p>\n
\n-record(node, {left,right})\n-record(leaf, {value})\nSample = #node{left=#node{left=#leaf{value=1},\nright=#leaf{value=2}},\nright=#leaf{value=3}}\n<\/pre>\n
 A record is declared with a pre-processor form “-record”. The first parameter to the form is
\nthe atom naming the record type; the second parameter is a tuple of the record field names. Once a record type is defined, you can create an instance of it with “#” followed by the record type name, and a set of field assignments inside of curly braces.<\/p>\n
 Like everything in Erlang, the way to manipulate records is by pattern matching:<\/p>\n
\n#node{left=L,right=R} = Sample\n<\/pre>\n
 will assign “L” to “#node{left=#leaf{value=1},right=#leaf{value=2}}”, and “R” to “#leaf{value=3}”.<\/p>\n
 Aside from the weirdness of the meta-language division, the sequential part of Erlang is very
\nstraightforward. It’s a classic eager functional language. Programs in Erlang are quite similar to
\nprograms in a language like Scheme, except for syntax, and the syntax is OK; sort-of a bastard offspring
\nof Lisp and Prolog, which isn’t an awful thing. <\/p>\n
 To give you a bit of flavor, here’s a simple bit of binary search tree code in
\nErlang:<\/p>\n
\n-module(bt).\n-export([insert\/2]).\n-record(node,{value,left,right}).\ninsert(#node{value=N,left=L,right=R}, V)  when N > V ->\n#node{value=N, left=insert(L,V), right=R};\ninsert(#node{value=N,left=L,right=R}, V) ->\n#node{value=N, left=L, right=insert(R,V)};\ninsert(none, V) ->\n#node{value=V, left=none, right=none}.\nfetch(#node{key=K, value=V, left=L, right=R}, K) ->\nV;\nfetch(#node{key=K, value=V, left=L, right=R}, Target) when K > Target ->\nfetch(L, Target);\nfetch(#node{key=K, value=V, left=L, right=R}, Target) ->\nfetch(R, Target);\nfetch(none, Target) -> none.\n<\/pre>\n
 It’s very straightforward functional code. It’s almost exactly the same way that it would be written
\nin ML (my favorite eager functional languages), and very close to how it would be written in Haskell. It is a bit verbose – but that’s because I’m not using Erlang to its full advantage. The code can be
\nsimplified a bit by using record field access and update syntax.<\/p>\n
 If you only want to access one field of a record, there’s a shorthand syntax that’s more convenient
\nthen writing out a full pattern match to get at one field: if Sample<\/code> is a variable
\ncontaining a record, then Sample#node.left<\/code> gets the value of the field named “left” of the
\nrecord type “node”. (If you use this syntax with the wrong record type, you’ll get a run-time error.)\n<\/p>\n
 Similarly, there’s a syntax for updating a record – that is, creating a new record that’s the same
\nas an old record except for a couple of modified fields: Sample#node{right=#leaf{4}}<\/code> will
\ncreate a new tuple of type “node”, with the same left value as Sample, but with a different right
\nvalue.<\/p>\n
 So, using that, we can modify “insert”, so that we don’t need to write the full record
\nconstruction syntax. Instead, we could write insert the following way (called “sinsert” for “simpler insert”):<\/p>\n
\nsinsert(none, Newkey, Newval) ->\n#node{key=Newkey, value=Newval, left=none, right=none};\nsinsert(Node, Newkey, Newval) when Node#node.key > Newkey ->\nNode#node{left=sinsert(Node#node.left, Newkey, Newval)};\nsinsert(Node,Newkey, Newval) ->\nNode#node{right=sinsert(Node#node.right, Newkey, Newval)}.\n<\/pre>\n
 For this kind of straightforward data structure programming, Erlang is a really pleasant language.
\nThe record system is very nice, flexible, and easy to work with. The strong pattern matching facility of the language is flexible enough that for an impressively large number of functions, you don’t need to write any control structure code beyond patterns and “when” guards. I just wish it wasn’t in the
\nmeta-syntax – when I get around to explaining the way that a large Erlang program is broken into multiple files, you’ll see a bit of why I’m unhappy that it’s meta.<\/p>\n
 In general, my impression thus far playing with Erlang (which I’ve used for a bit more complicated
\nstuff than I’ve included in this post) is that it’s very easy to read and write, and it behaves in a
\nvery intuitive fashion. I definitely find it easier to pick up as a beginner than I did Haskell, but I think that’s mainly because I find eager evaluation to be easier to predict than lazy. For this kind of basic data structure programming, I think it’s a toss-up with Haskell: I prefer Haskell’s
\nstrong types, but Erlang’s eager semantics make it a whole lot easier to understand the efficiency
\ntradeoffs between different implementation strategies. <\/p>\n
 Before moving on, I’ll toss in some information on the bit of Erlang that I really hate.
\nAside from using a preprocessor for implementing meta-language features like records, Erlang’s
\npreprocessor also has a macro facility that’s modeled on the macro system from the C preprocessor.
\nLike cpp, it’s ugly as all get-out, and it’s bloody dangerous to use. It’s a ghastly
\nthing, but it’s there, and a fair bit of Erlang code uses it. (Gag.) One minor redeeming feature of the
\nmacro system is that at least uses of macros are clearly marked – unlike C or C++, you can clearly tell a macro invocation from a function invocation.<\/p>\n
To define a preprocessor macro, you use:<\/p>\n
\n-define(name, replacement)\n<\/pre>\n
 Or, for a macro with parameters:<\/p>\n
\n-define(name(p1, p2, p3), replacement)\n<\/pre>\n
 For example:<\/p>\n
\n-define(TIMEOUT, 2500)\n-define(Double(X),2*X)\n<\/pre>\n
 Then you can use the macros by prefixing the name with a “?”: ?Double(10)<\/code>.<\/p>\n
 Naturally, if you’ve got a hideous preprocessor, you can’t escape using it for conditional compilation. So the Erlang preprocessor includes “-undef”, “-ifdef”, “-ifndef”, “-else”, “-endif”, each
\nof which means pretty much the same thing as the corresponding C preprocessor directive.<\/p>\n
 Once again, gag.<\/p>\n
 Anyway – next post, I’ll go into more depth about control structures in Erlang, and introduce one of the more unusual features of Erlang, called bit syntax. Bit syntax is an amazingly powerful and flexible pattern-matching syntax for data encoded in bit streams. Given Erlang’s origins, it’s fairly obvious why this is part of the language – and it’s one of the things that make it so<\/em> suitable for high performance distributed systems: it’s got deep support for the kind of bit-tweaking that’s necessary for
\nmany communication protocols, and it’s done in a way that allows the compiler to optimize the living daylights out of it. But that’s the next post.<\/p>\n","protected":false},"excerpt":{"rendered":"
One of the things I discovered since writing part one of my Erlang introduction is that Erlang has grown a lot over the last few years. For example, the idiom of tagged tuple as a way of creating a record-like structure has been coded into the language. There is, unfortunately, a bit of a catch. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[85],"tags":[],"class_list":["post-563","post","type-post","status-publish","format-standard","hentry","category-erlang"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4lzZS-95","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/563","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=563"}],"version-history":[{"count":0,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/563\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=563"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=563"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=563"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}