Right, that’s a succinct way to put it. I would just add that I hope we can
do this in a way that allows the beginner to reason about things like
getindex, vec, reshape, transpose, vcat, etc without requiring the him/her
to understand pointers and the subtleties of memory layout. In a way, I’m
being selfish: I want to be able to teach my intro stats students Julia.
For example, how does one tell that vec(a) does something different than
getindex(a,1:length(a)) without testing it? I guess testing it isn’t that
big of a deal, but if your a beginner you’ll end up testing everything. In
particular, if x = {"jill", 4} and y = {"bob", 2} it doesn’t seem a-priori
clear why z = vcat(x,y) doesn’t share memory with x and y. Once you open up
these possibilities, even things like x = sin(y), to a beginner, could have
some weird lazy evaluation interpretation.
Another example, why does x=a do something different than x = a[:,:]
(currently the latter returns a copy, but I guess it might return an
ArrayView in the future)? Is x=a just one of those special cases where I
tell my students x=a doesn’t mean what you think…it means that x and a are
now names for the same thing.
Anyhoo, my hope is to be able to explain how to identify the different
behavior to a beginner.
-Ethan
On Sunday, August 31, 2014 12:58:43 PM UTC-7, John Myles White wrote:
I think there’s a broad issue that need resolution: how do you know when a
> function’s output takes control of the memory used by its arguments?
>
> — John
>
>
