On Wed, Apr 30, 2014 at 11:37 AM, Oliver Woodford <[email protected] > wrote:
> On Wednesday, April 30, 2014 4:01:22 PM UTC+1, Stefan Karpinski wrote: >> >> I really think the only code that should be too worried about whether >> something is a leaf type or not is the compiler... >> >> > Are you saying: > a) we should use another way to distinguish between homogeneous and > heterogeneous input arrays, > or > b) that only the compiler should care whether input arrays are homogeneous > and heterogeneous input arrays. > b) > If b) then: > 1) doesn't it make a big difference to the speed of some functions, e.g. > sum()? > and > 2) if so, is it unreasonable to encourage the user to use homogeneous > arrays in those situations? > It can make a big difference, but I don't think that libraries or the language should refuse perfectly reasonable functionality because it might be a bit slower. There are lots of situations where you don't care that much about performance and flexibility is more important. Doing computations with BigInts and BigFloats is dog slow compared to using native types but sometimes the increased precision is more important than speed. Should libraries refuse to work with BigInts and BigFloats because they're known to be slow? Even if the same code would work just fine with BitInts as Ints? That's very un-Julian. The Julian approach is informed consent. You can use heterogeneous arrays and they will work, but they might be slow. If your code is too slow, consider changing it so that it uses homogeneous arrays instead. If knowing that this is the problem is hard, we should – and do – provide tools to help discover such things. The TypeCheck package<https://github.com/astrieanna/TypeCheck.jl>is a great example of such a tool, giving many of the benefits of the static type checking without forcing static type checking on the user everywhere. TypeCheck can warn the user about things that they are allowed to do, but which might cause performance problems, like changing the type of a variable over the course of a loop or having functions whose return type depends on the values of its inputs, not just their type.
