<div dir="ltr">This is definitely a troll.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 1:34 PM, Anthony Ramine <span dir="ltr"><<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are we 1st April already? I didn’t implement yet my patch to make tuples 0-indexed. :(<br>
<br>
But well, that is overseded by your proposal.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Anthony Ramine<br>
<br>
Le 27 août 2014 à 20:21, Chris Pacejo <<a href="mailto:colanderman@gmail.com">colanderman@gmail.com</a>> a écrit :<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Tuples are clearly unnecessary and a wart in Erlang's design.<br>
> Consider all the operations tuples provide:<br>
><br>
> Construction: X = {A,B,C}<br>
> Destruction: {A,B,C} = X<br>
> Pattern matching: case X of {foo,B,C} -> ... end<br>
><br>
> Note now that these operations are provided equally by lists:<br>
><br>
> Construction: X = [A,B,C]<br>
> Destruction: [A,B,C] = X<br>
> Pattern matching: case X of [foo,B,C] -> ... end<br>
><br>
> And note that lists provide the additional functionality of indexing<br>
> and consing, which tuples do not provide.<br>
><br>
> Clearly, using tuples instead of lists provides no benefit, and to<br>
> simplify the language they should be deprecated in OTP 18, and removed<br>
> by OTP 19.  To support this transition, a compiler option can be<br>
> provided to maintain the ill-conceived tuple notation for legacy code;<br>
> may I suggest +distinguish_homogenous_and_heterogenous_collections.<br>
><br>
> Now, surely detractors will claim that the distinction between tuples<br>
> and lists signals programmer intent, permits bytecode optimization,<br>
> and enables rich typechecking in Dialyzer.  I claim these purported<br>
> benefits are bollocks.  I, and no doubt others, routinely find the<br>
> need to iterate over tuple elements, and to store unrelated data<br>
> together in a single list.  Anyone who claims that such things are not<br>
> necessary clearly has not ever written a complex program.  (I suspect<br>
> anyone who thinks structurally-typed records and key-value maps serve<br>
> different purposes falls into this group.)<br>
><br>
> I hope you all agree, and that we can look forward to a future Erlang<br>
> supporting lists and maps as its sole data constructors.<br>
><br>
> - Chris P<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>