<div dir="ltr">Hello,<div><br></div><div>Great discussion and ideas here!</div><div><br></div><div>One thing that I've not seen mentioned is; what if the list representation was made more memory efficient? Today its 16 bytes per codepoint vs binaries that are 1-4 byte per codepoint. What if lists only used 8 bytes for each codepoint? what if it used the same as binaries? How would that change this discussion?<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 11, 2018 at 10:22 AM, Sean Hinde <span dir="ltr"><<a href="mailto:sean.hinde@mac.com" target="_blank">sean.hinde@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Would an EEP help the existing work of the OTP team in this area or is there already a clear plan and this would be a distraction?<br></div><div><br></div></div></blockquote><div><br></div><div>There is no plan about what should be done in this area. We want to continue developing the possibility to encode and decode protocols. We've had numerous discussions about how we would like to extent the binary syntax (or the syntax in general) in order to make it better for both novice and advanced users of Erlang, but have yet to come up with something that we like. So far our discussions have been mostly about decoding protocols, because we see that as the larger pain point, but maybe we were wrong about that?</div><div><br></div><div>Regarding creating a new text type, I'm personally skeptical, but haven't formed a strong opinion on the matter yet. Adding a new type is a huge undertaking and we should be very sure that what we want before doing it.</div><div><br></div><div>Lukas</div></div></div></div></div>