Structs (was RE: Record selectors)

Joe Armstrong joe@REDACTED
Tue Jan 14 10:41:44 CET 2003

On Mon, 13 Jan 2003, Ulf Wiger wrote:

> On Mon, 13 Jan 2003, Vlad Dumitrescu (EAW) wrote:
> >Hello again,
> >
> >I reviewed this whole thread and found plenty of good ideas
> >about ways to improve the record handling. And also a
> >comprehensive list of possible drawbacks. One important
> >point is that it's probably not an Ericsson priority to fix
> >this.
> Joe Armstrong, who is no longer at Ericsson, once drew an
> idea about efficient and safe records on my whiteboard.
> AFAIR, each record would carry its own dictionary which
> would not be copied -- only referenced -- when the record is
> updated. I think I also recall concluding that Joe's
> "records" could be made syntactically compatible with
> today's records. One would probably still use a new
> (cleaner) syntax though, esp. since there would be no need
> to specify the record type in each operation.
> Perhaps Joe could recap the idea on this list, and perhaps
> explain what was wrong with it -- since he has not
> aggressively pushed the idea through?  (:

  There was nothing wrong with the idea.

  Let  me call  the thing  I like  structs (to  distinguish  them from

  With structs you can write things like:

	A = ~{name="joe", footSize=42},   %% define a struct
	A.footSize,                       %% access a field
	B = ~A{likes="motorbikes"},       %% add a new field
	~{likes=X, name=N} = B}           %% pattern match etc.

  *without* any record defs.

  Everything  is dynamic  (which gives  it a  nice Erlang  flavor) and
things are consistent between different modules - so no .hrl files are
needed. Efficiency  would be *jolly  good* (TM) if implemented  in the

  I have appended a pdf file describing structs as I would like to see
them and a test implementation.

  The  test   implementation  only  allows   compilation  of  programs
containing structs. I have not changed the evaluator, so you can't use
structs in the shell.

  The implementation in the appended file is inefficient - it just uses
a simple  parse transform. To do  this properly would need  a new data
type in the virtual machine and a number of changes to the compiler.

  I will now (for Uffe's sake) "aggressively push the idea".

  "structs are jolly good - please bring pressure to bear on you local
Erlang implementor to implement them"

  Was that aggressive enough?

  Possibly  if  some of  the  big (paying  :-)  customers  ask OTP  to
prioritize this then it will happen - a real implementation needs:

	1) Compiler changes (Robert says this is easy)
	2) Changes to shell erl_eval parser etc. (easy)
	3) VM changes (Björn says these are easy)

  And eventually tool changes (xref) etc.

  One thing I haven't investigated is the interaction between this and
the packages stuff.

  "." (DOT)  is getting  pretty overloaded -  so ~A.tag  might collide
with the dot notation used  in packages (perhaps Richard could comment
on this)


> /Uffe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: structs.tgz
Type: application/x-gzip
Size: 126657 bytes
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: structs.pdf
Type: application/pdf
Size: 27090 bytes
URL: <>

More information about the erlang-questions mailing list