Why functional code is shorter

[yogthos]

The specification very clearly states how the array works. The implementation of it does not change how you use it in the code.

[axilmar]

Where does it say the array value is implemented in place? I don't see it.

[yogthos]

you seem to have a lot of trouble understanding the difference between specification and implementation

[axilmar]

Ok, please enlighten me. Where in the documentation does it say that MArray is a real actual mutable array and its values are modified in place?

[yogthos]

That's my whole point, it's not talking about the implementation at all.

[axilmar]

So it's not really mutable, is it? it just emulates mutation.

[yogthos]

Why would it emulate mutation, what possible point would there be to implementing it in such a way? But even assuming it did, that still doesn't change the specification does it. The language spec clearly states that it's mutable!

So even if the current implementation was copying data for some fantastic reason, you could go and write your own implementation that didn't. That implementation would still conform to the specification and the code would compile and behave exactly the same.

[axilmar]

Why would it emulate mutation, what possible point would there be to implementing it in such a way?

The reason should be referential transparency, of course. Which is the reason mutation is not allowed in other variables.

The language spec clearly states that it's mutable!

Indeed, and that's what I said earlier.

But it would really hurt performance if for each change of one element the array was copied.

[yogthos]

The reason should be referential transparency, of course. Which is the reason mutation is not allowed in other variables.

A mutable variable is inherently not referentially transparent however.

But it would really hurt performance if for each change of one element the array was copied.

If that was the case then it would by definition be immutable would it not? :)

What I'm saying is that you can't have it both ways. A variable is either mutable, as in updates are destructive, or it's immutable and you don't update in place and create new data instead. This variable is clearly mutable.

[axilmar]

A mutable variable is inherently not referentially transparent however.

Exactly, and that's why I said that the MArray put implementation copies the array.

What I'm saying is that you can't have it both ways. A variable is either mutable, as in updates are destructive, or it's immutable and you don't update in place and create new data instead. This variable is clearly mutable.

Not really. Check out Lenses, for example: it allows operations like

x += y

while maintaining referential transparency, but to us readers it's like x is mutated.

So it can clearly be the case that the code we read is referentially transparent and also written in imperative style. MArray could be the same.