I’m not sure what you refer to by “Compatability module”.
From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On Behalf Of Christoph Ortner Sent: Monday, November 2, 2015 1:09 PM To: julia-users <julia-users@googlegroups.com> Subject: Re: [julia-users] Re: Re: are array slices views in 0.4? How is this different from the Compatibility module? Christoph On Monday, 2 November 2015 20:44:38 UTC, David Anthoff wrote: Yes, I like that kind of idea. How about specifically: - If a package does nothing, every use of `[]` for slicing throws a deprecation warning on julia 0.5 - If you use `using OldArrays` the deprecation goes away, and you get the julia 0.4 behavior (maybe this options is actually not even needed, or maybe it should even not exist, not sure) - If you use `using NewArrays` you get the new slicing behavior on julia 0.5 And then in julia 0.6 `[]` just gives the new behavior by default, i.e. the `using NewArrays` is no longer needed. In julia 0.6 `using NewArrays` could actually show a deprecation warning that this using statement is no longer needed. From: julia...@googlegroups.com <javascript:> [mailto:julia...@googlegroups.com <javascript:> ] On Behalf Of Cedric St-Jean Sent: Monday, November 2, 2015 12:00 PM To: julia-users <julia...@googlegroups.com <javascript:> > Subject: Re: [julia-users] Re: Re: are array slices views in 0.4? Python's from __future__ import division was a reasonable way of transitioning. I would use it for slicing if it was available already. On Monday, November 2, 2015 at 2:46:04 PM UTC-5, David Anthoff wrote: The `using OldArrays` approach would essentially require an opt-in from everyone before julia 0.5 is released, i.e. an opt-in action from all package devs, right? The danger there seems that I update to julia 0.5, but now I have no clue whether all the packages I rely on have either a) made sure that they are compatible with the new array handling or b) have added the `using OldArrays` approach so that they can delay dealing with the issue. The nice thing with the current deprecation handling is that as a user of a package that has failed to deal with these things, I get alerted to issues automatically and know that something might need my attention. But a `using OldArrays` approach doesn’t seem to do that, in the end it still just means that the semantics of `[]` are changed without the typical deprecation sequence of using multiple versions for such a change. From: julia...@googlegroups.com <mailto:julia...@googlegroups.com> [mailto:julia...@googlegroups.com] On Behalf Of Stefan Karpinski Sent: Tuesday, October 27, 2015 7:43 AM To: Julia Users <julia...@googlegroups.com <mailto:julia...@googlegroups.com> > Subject: Re: [julia-users] Re: Re: are array slices views in 0.4? Yes, I'm concerned about this as well. I'm sure we'll come up with something. Maybe allow using the old behavior during a transitional period with something like `using OldArrays` and then when you've gotten the chance to double check your code, you can delete that line and move to the new behavior. We'll have to see. On Mon, Oct 26, 2015 at 10:20 PM, David Anthoff <ant...@berkeley.edu <mailto:ant...@berkeley.edu> > wrote: Are there plans to throw deprecation warnings in julia 0.5 whenever one slices an array with [], and then reuse the [] syntax to return views in julia 0.6? That would be approach that is consistent with previous changes of functionality, right? I’m very much in favor of the new design, but I’m very worried about the transition. There seems an enormous potential for subtle bugs to go undetected for a long time… the tuple change was nicely phased in, as were any other breaking changes since I’ve used julia (since 0.2), i.e. I always had the impression that as long as I just fixed all depreciation warnings when a new version came out, I would be good. But my understanding right now for the array change is that the behavior of slicing with [] will change drastically, with essentially no indicator where in my code I might run into trouble, right? From: julia...@googlegroups.com <mailto:julia...@googlegroups.com> [mailto:julia...@googlegroups.com] On Behalf Of Stefan Karpinski Sent: Monday, October 26, 2015 12:05 PM To: Julia Users <julia...@googlegroups.com <mailto:julia...@googlegroups.com> > Subject: Re: [julia-users] Re: Re: are array slices views in 0.4? On Mon, Oct 26, 2015 at 2:17 PM, Christoph Ortner <christop...@gmail.com <mailto:christop...@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.
