Fundamentally I don't think you should be in the business of forcing people who call your code to use arrays with concrete element types. If they really want to use an array with an abstract element type – and they may have perfectly good reasons to – then that's their business. Does your code break if it is applied to an array with an abstract element type? If so, you must be doing something rather strange. We've gone to great effort to make sure that even though the underlying implementation of concrete versus abstract arrays are different, the semantics are completely identical – there's no reason for code to work with one but not the other.
On Wed, Apr 30, 2014 at 10:08 AM, Oliver Woodford <[email protected] > wrote: > > > On Wednesday, April 30, 2014 2:31:43 PM UTC+1, Patrick O'Leary wrote: >> >> >> It's a flexible type system, but it doesn't provide the power of ML or >> Haskell. If you really, really want this, do a runtime check: >> >> reduce((==), [typeof(el) for el in a]) >> > > I feel that the difference between homogeneous and heterogeneous arrays is > a very important distinction, and not some odd thing that you might only > rarely care about. The distinction has a massive impact on speed. The point > of Julia is to be a fast dynamic language. Hiding the distinction under the > carpet seems contrary to one of the aims of Julia. > > Ivar's suggestion of: > @assert isleaftype(T) > is nice, but it doesn't feel quite right to me. >
