<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">The advantage over nested records is fourfold.</div><div class="gmail_default" style="font-family:monospace,monospace">Clarity: the factoring of a "record" into a nest of tuples</div><div class="gmail_default" style="font-family:monospace,monospace">is invisible in the source code.  Use Foo#R_F rather than</div><div class="gmail_default" style="font-family:monospace,monospace">Foo#R_F#N_G.  Easier to read.</div><div class="gmail_default" style="font-family:monospace,monospace">Maintainability: changing the factoring does not affect</div><div class="gmail_default" style="font-family:monospace,monospace">the field names.  Only the record declaration changes.</div><div class="gmail_default" style="font-family:monospace,monospace">Space: the nested groups do not have tags.  If you have</div><div class="gmail_default" style="font-family:monospace,monospace">say a 10-slot record containing 10 5-slot records, you</div><div class="gmail_default" style="font-family:monospace,monospace">need 82 words.  With nested groups, you save 10 words,</div><div class="gmail_default" style="font-family:monospace,monospace">or about 12% of the space.</div><div class="gmail_default" style="font-family:monospace,monospace">Time: with tag-less nested groups, copying time is less.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Of COURSE nested records are a good approach right now.</div><div class="gmail_default" style="font-family:monospace,monospace">It could just be a bit better.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 30 Apr 2019 at 07:32, Kostis Sagonas <<a href="mailto:kostis@cs.ntua.gr">kostis@cs.ntua.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/29/19 12:31 PM, Richard O'Keefe wrote:<br>
> It's not clear to me why you would have a record with<br>
> 50 fields.<br>
<br>
Same here, of course.<br>
<br>
>  Imagine for a moment that Erlang's record<br>
> declaration syntax were generalised slightly:<br>
> <br>
> '-' 'record' '(' <name> ',' <group> ')' '.'<br>
> where<br>
>    <group> = '{' (<field> | <group>)+',' '}'<br>
>    <field> = <name> ['=' <default expr>]<br>
> <br>
> The generalisation here is allowing <group>s as well<br>
> as <field>s inside <group>s.  A nested group would be<br>
> a nested tuple with no element reserved for a tag.  So<br>
> -record(foo, {{a,b},{c,d}}).<br>
> means that a typical instance would look like<br>
> {foo,{A,B},{C,D}}.<br>
> The time to fetch a field would be proportional to the<br>
> number of groups it is in; the time to replace it would<br>
> be proportional to the sum of the sizes of the groups<br>
> it is.<br>
> Put nested fields into groups that are commonly read<br>
> or written together, and you trade a small increase<br>
> in read time for a large decrease in write time, with<br>
> automatic economisation in pattern matching, but needing<br>
> special attention from the compiler to fully economise<br>
> updates.<br>
> <br>
> That would be a nice extension of Erlang records, letting<br>
> you make performance tradeoffs just by adding and removing<br>
> curly braces with no change to code elsewhere.<br>
<br>
I see very little benefit, if any at all, compared to the (natural, IMO) <br>
alternative of using nested records for such use cases:<br>
<br>
  -record(foo, {#grp1{a,b},#grp2{c,d}}).<br>
<br>
which requires no language (or implementation) extension.<br>
<br>
What am I missing?<br>
<br>
Kostis<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>