On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner < christophortn...@gmail.com> wrote:
> Fabian - Many thanks for your comments. This was very helpful. > > (c) if I want to write code now that shouldn't break with 0.5, what should >> I do? >> > > I think when you need a copy, just surround your getindex with a copy > function. (e.g. copy(x[:,10]) instead of x[:,10]). > > But this would lead me to make two copies. I was more interested in seeing > whether there is a guideline on how to write code now so it doesn't have to > be rewritten for 0.5. > There will be a solution in the Compat package once this change is made. It will probably consist of having a replacement for getindex that creates a slice rather than a copy so that calling copy won't result in two copies. I.e. it will backport the 0.5 behavior to earlier versions of Julia. > Regarding this change I am also more on the sceptical side. I would very >> much prefer a copy-on-write like solution like Matlab and R provide, but I >> don't know if and how this would be possible to implement, so I don't raise >> my voice here. >> To me the main benefit of this change is that it drove the main >> developers to make array views much more performant and first class members >> of julia. As Tim Holy mentioned, the actual change seems to be be very >> small, but it needed and still needs a lot of work to make it possible. > > > My own scepticism comes from the idea that using immutable objects > throughout prevents bugs and one should only use mutable objects sparingly > (primarily for performance - but I thought it shouldn't be the default) > Copy-on-write is complex and leads to brittle performance properties that cannot be reasoned about locally. The semantics of R and Matlab also notoriously make it impossible to write efficient mutating functions – people generally end up writing C extensions to do that. It remains to be seen how this pans out, but keep in mind that C, C++, Java, Fortran, Julia, Python, Ruby, etc. all use mutable non-copy-on-write arrays everywhere and the world has not ended. Slices are a bit different, but NumPy, for example, creates views for slices and that works well in the SciPy ecosystem. Philosophically, I think that returning views from operations is problematic when the object being viewed is conceptually a single value – strings being a good example that have gone different ways in different languages. In C everyone thinks of strings as arrays of characters and it works pretty well since everyone has that in mind. In higher level languages, people stop thinking of strings this way, which means that making strings mutable or returning slices of them as views becomes problematic because it's at odds with how we think of strings. Arrays are the prototypical example of a container-like thing, so I don't think that this will be that confusing. If you "own" the array, then it's ok to make a slice and potentially mutate it – if you don't, then it's not ok. We could potentially add tooling to help enforce this since we know by the f! naming convention which functions should and shouldn't mutate their arguments.
