<div dir="ltr"><div style="font-family:monospace,monospace" class="gmail_default"></div><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">It's not clear to me why you would have a record with</div><div class="gmail_default" style="font-family:monospace,monospace">50 fields.  Imagine for a moment that Erlang's record</div><div class="gmail_default" style="font-family:monospace,monospace">declaration syntax were generalised slightly:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">'-' 'record' '(' <name> ',' <group> ')' '.'</div><div class="gmail_default" style="font-family:monospace,monospace">where</div><div class="gmail_default" style="font-family:monospace,monospace">  <group> = '{' (<field> | <group>)+',' '}'</div><div class="gmail_default" style="font-family:monospace,monospace">  <field> = <name> ['=' <default expr>]</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The generalisation here is allowing <group>s as well</div><div class="gmail_default" style="font-family:monospace,monospace">as <field>s inside <group>s.  A nested group would be</div><div class="gmail_default" style="font-family:monospace,monospace">a nested tuple with no element reserved for a tag.  So</div><div class="gmail_default" style="font-family:monospace,monospace">-record(foo, {{a,b},{c,d}}).</div><div class="gmail_default" style="font-family:monospace,monospace">means that a typical instance would look like</div><div class="gmail_default" style="font-family:monospace,monospace">{foo,{A,B},{C,D}}.</div><div class="gmail_default" style="font-family:monospace,monospace">The time to fetch a field would be proportional to the</div><div class="gmail_default" style="font-family:monospace,monospace">number of groups it is in; the time to replace it would</div><div class="gmail_default" style="font-family:monospace,monospace">be proportional to the sum of the sizes of the groups</div><div class="gmail_default" style="font-family:monospace,monospace">it is.</div><div class="gmail_default" style="font-family:monospace,monospace">Put nested fields into groups that are commonly read</div><div class="gmail_default" style="font-family:monospace,monospace">or written together, and you trade a small increase</div><div class="gmail_default" style="font-family:monospace,monospace">in read time for a large decrease in write time, with</div><div class="gmail_default" style="font-family:monospace,monospace">automatic economisation in pattern matching, but needing</div><div class="gmail_default" style="font-family:monospace,monospace">special attention from the compiler to fully economise</div><div class="gmail_default" style="font-family:monospace,monospace">updates.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">That would be a nice extension of Erlang records, letting</div><div class="gmail_default" style="font-family:monospace,monospace">you make performance tradeoffs just by adding and removing</div><div class="gmail_default" style="font-family:monospace,monospace">curly braces with no change to code elsewhere.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Unless/until that's implemented, do it manually.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div></div>