I second that I knew a lot more people doing scientific computing with Matlab/Python. And of those few that use C++ only a minority knows (and cares) how to write const aware code...
To your solution, Tim: I think Steve wants to hide this in the function so that regular arrays can be passed. In your version a Wrapper type has to be created before calling the function. Cheers, Tobi Am Donnerstag, 14. August 2014 11:54:15 UTC+2 schrieb Tim Holy: > > For any algorithm that accepts AbstractArrays, can't you just just define > > immutable ReadOnlyArray{T,N,AT<:AbstractArray} <: AbstractArray{T,N} > data::AT > end > ReadOnlyArray{AT<:AbstractArray}(A::AT) = > ReadOnlyArray{eltype(A),ndims(A),typeof(A)}(A) > > and then define the pass-through methods you want to support? That way can > wrap > any array type. > > > Also, you could easily create your own package that does this. I don't see > any > particular requirement to have it in base. > > > One nit: can you really support your assertion that C++ and Fortran are > the > two major languages of scientific computing? In my world, Matlab is used > by > about 20x (maybe 50x) as many people as C++. I suspect there's a major > divide > depending on field. Science is a big place. > > --Tim > > On Wednesday, August 13, 2014 03:19:36 PM vav...@uwaterloo.ca > <javascript:> 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 > >