So, what's stopping you from writing that package? Since much of the code in Base (and in many packages) takes an AbstractArray input, you can protect any array you care about by wrapping it in ReadOnlyArray, and (mostly) it should Just Work. You don't need to convince anyone of anything.
Besides, much of the code that eventually ends up in base starts out life in a package. Just write the code, advertise it, and see how many people start using it. If there's a groundswell of enthusiasm for writing more const-aware code in Base, it's more likely to migrate in. But that day won't arrive if you don't write the package first. --Tim On Friday, August 15, 2014 05:44:56 AM [email protected] wrote: > Tamas Papp asks what problem would be solved by being able to specify which > function arguments are inargs. Here are three possible problems solved: > > (1) To catch programmer blunders, e.g., which is the correct order of the > three matrices passed to 'matmul'. > > (2) To make debugging easier. For example, suppose variable A changes > somewhere between line 1000 and line 3000 of my code and I didn't want it > to change. Which statement is changing A? Any function call with A as an > argument could change it, but I don't have to worry about the readonly > function calls. > > (3) To allow certain automatic program transformations. For example, if A > is a read-only argument, then an automatic code parallelizer can freely > replicate it across all processors during the function execution without > worrying about consistency. > > Finally, I should point out again that both the C and Fortran communities > added this feature to their language; there must be some good reason for > doing so! > > With regard to the issue of recursive containers, it is true that my > proposal would not work for such container, just as it doesn't work in C++ > as observed by Tim Holy. However, even in this case, Julia has an > advantage because it could simply throw an error if readonly is applied to > recursive containers. [For readonly to throw an error, I assume that there > exists a Julia function called 'istotallyimmutable(T)' or something > similar; there must be such a function at least internally for 'deepcopy' > to work.] And a programmer who really needs readonly to work for a > recursive container even at the expense of performance could use deepcopy > instead of readonly. > > On Wednesday, August 13, 2014 6:19:36 PM UTC-4, [email protected] wrote: > > Dear Julia colleagues, > > > > In June, I wondered on this newsgroup why Julia lacks an 'inarg' > > specification for functions. The two major languages used nowadays for > > scientific programming, namely Fortran and C++, both provide mechanisms to > > declare that a function argument is read-only by the function. Indeed, > > this was added to Fortran late in its life, so one assumes that there is > > some bitter experience underlying the decision to include it in Fortran. > > > > (Matlab has only inargs, at least until you get to relatively advanced > > > > programming techniques, so this is not an issue.) > > > > Stefan Karpinski provided a convincing explanation for why inarg and > > outarg specifications have been omitted from the Julia core. Now that I > > am > > slightly more familiar with Julia, I would like to make a proposal for > > inarg that would not require changes to the core language. The proposal > > would, however, entail substantial additional code, so it is intended for > > some version of Julia in the future. > > > > Here is the proposal: suppose fn is a function that takes an array input > > "a" and wants to declare it to be read-only. Then at the beginning of the > > function before any of the arguments gets used, there would be an > > assignment statement like this: > > > > function fn(a::AbstractArray{Int,1}) > > a = readonly(a) > > > > The way this would work is as follows: Julia would have new types, mostly > > invisible to the user, like ReadOnlyArray which would have a setindex! > > method that would throw an error, Then there would be methods like > > readonly{T.N}(a::Array{T,N}) that would use 'reinterpret' to change the > > Array to a ReadOnlyArray. A programmer who wanted to write a function > > that > > could take either arrays or readonlyarrays as inputs would have to declare > > abstract argument types like DenseArray or AbstractArray. The user would > > not, in general, have to worry about the read-only types; the situation > > when a user would have to worry about them is if he/she wants to develop a > > read-only version of his/her own data structure that internally uses the > > standard containers. > > > > This proposal has several advantages: > > > > (1) The above mechanism enforces the read-only property of a since fn no > > longer has access to the initial (writeable) definition of a. > > > > (2) The above mechanism, if adopted as an idiom, could be easily spotted > > by program analysis tools that could then make optimizations based on the > > fact that a is read-only. > > > > (3) There is hardly any performance penalty for this mechanism. > > > > But obviously there is one big disadvantage: > > > > (1) For each of the standard containers, a new read-only version would > > have to be written. Furthermore, there would also have to be an abstract > > type to serve as a common parent. E.g. there is currently no abstract > > parent for Set (although there is an open discussion about that matter on > > github). > > > > and a second minor disadvantage > > > > (2) The enforcement of read-only would probably would not work > > recursively, e.g., if a were an array of arrays. In fact C++ has a > > similar > > gap in its 'const' mechanism. > > > > -- Steve Vavasis
