Let me qualify my statement with semantically they’re equivalent. The fact that they’re not compiled to the same byte code doesn’t mean that mathematically a list is just a tuple of tuples.
I also clearly said most FP languages do this with syntax sugar. I’m honestly surprised Elixir doesn’t make this optimiztation. I’d be curious if putting the nil first changes your results.
I nearly had a heart attack when you declared lists and tuples basically the same thing.
In the Erlang VM, a tuple is always stored as a contiguous segment of memory – the item at index n is stored at the memory address right after where n-1 ended. As such, it's generally very bad form to do a lot of modifying of tuple content and structure, as a good number of those operations will result in data being copied and collated at a new memory address.
Contrast this to lists, which the Erlang VM keeps track of by storing a reference to the previous data point's address alongside the current data point. As such, not only is the length of a list dynamic, its addresses within RAM are, too (and the newest data is, paradoxically, usually at the leftmost side of the list).
tl;dr, Erlang doesn't make lists out of syntactic tuple sugar, because that would be madness
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Let me qualify my statement with semantically they’re equivalent. The fact that they’re not compiled to the same byte code doesn’t mean that mathematically a list is just a tuple of tuples.
I also clearly said most FP languages do this with syntax sugar. I’m honestly surprised Elixir doesn’t make this optimiztation. I’d be curious if putting the
nilfirst changes your results.I nearly had a heart attack when you declared lists and tuples basically the same thing.
In the Erlang VM, a tuple is always stored as a contiguous segment of memory – the item at index
nis stored at the memory address right after wheren-1ended. As such, it's generally very bad form to do a lot of modifying of tuple content and structure, as a good number of those operations will result in data being copied and collated at a new memory address.Contrast this to lists, which the Erlang VM keeps track of by storing a reference to the previous data point's address alongside the current data point. As such, not only is the length of a list dynamic, its addresses within RAM are, too (and the newest data is, paradoxically, usually at the leftmost side of the list).
tl;dr, Erlang doesn't make lists out of syntactic tuple sugar, because that would be madness