"You could imagine some hypothetical language in which all objects are immutable, as far as the programmer is concerned - however the compiler is allowed to reuse objects behind the scenes if there is provably no way that a side-effect could be introduced."

There are functional languages that do this. Like many other optimizations, you get less than your intuition might naturally expect, but it does work.

A trivial case is "tail call optimization", which most immediately involves not creating a literal in-memory stack record for recursive invocations but also can easily involve the compiler re-using the memory for the arguments. IIRC Erlang will do that as much as it can in tight recursive calls.

> You could imagine some hypothetical language in which all objects are immutable, as far as the programmer is concerned - however the compiler is allowed to reuse objects behind the scenes if there is provably no way that a side-effect could be introduced.

Erlang/BEAM fits your hypothetical to some degree. Erlang the language has immutable variables; however, BEAM, the virtual machine, has mutable registers. Whether or not a given code sample results in copy or mutation depends on what information is available to the compiler, of course.

it is theoretically possible that a library like numpy or pandas could do this directly. That is, if you take each of these transformation operations and store them, but not actually run them until needed, that is, when someone accesses the individual array values, you only need to make one copy and there is no impact on the programmer to have to worry about this.

I was doing something similar for SQLAlchemy recently. SQLAlchemy is all about capturing Python operators and operands into data structures that represent intent which can be invoked later.

edit: here is a demonstration: https://gist.github.com/zzzeek/caa4a7ed94f326fbbc031acecb9d7...

edit edit: it is actually possible with numpy by using the Dask library: https://dask.org/

The problem with the library doing this is you end up with the same issue as in Haskell: you accumulate thunks and both memory use and location of CPU hotspots becomes much harder to predict and troubleshoot.

so...turn off the "thunking" feature while you are debugging.

That won't help when you're debugging the performance implications of thunking.

compare memory / callcounts / time spent with thunking turned on vs. off would give a good idea of it.

i can say for my side of things thunking is a super huge performance gain as it allows for quick gathering of expression intent and then the computation side on the other side of a cache.

You can use Futhark; it compiles to PyOpenCL and then can be called by python fairly fluently.

Accelerate is a nice example of an array library with a JIT backend.

Alas, CPython isn’t an optimizing compiler, it faithfully compiles code into bytecode which is then faithfully executed.

I don’t know the state of NumPy on PyPy since I don’t use PyPy.

It does have a peephole optimizer.

numba.jit might be able to optimise the extra copies away though, I'm reasonably sure working with numpy arrays is a pretty significant use case.

There's another project, Pythran, that does that.

I'm not sure if it's doing inlining before the laziness analysis, which would be ideal.

[1]: https://pythran.readthedocs.io/en/latest/INTERNAL.html#lazyn...