On Wednesday, April 30, 2014 3:57:28 PM UTC+1, Stefan Karpinski wrote:
If you ask for a Basket{Fruit} and I (covariantly) give you a
Basket{Apple}, it's fine if you only take things out of the basket – you
will always get a Fruit since Apples are Fruit. But if you try to put an
Orange,
On Wed, Apr 30, 2014 at 9:57 AM, Oliver Woodford
oliver.woodf...@gmail.comwrote:
Stefan
Firstly, thank you for taking the time to write such a lengthy response. I
think it comes closest to addressing the particular question I had. Sadly
I'm an Engineer, not a Computer Scientist, so it's
A habitual MATLAB user, I've been trying out Julia over the last two weeks
to see if it might be a suitable replacement. I want something that is as
fast to develop using, but has much faster runtime. Perhaps I'll write
about my general thoughts in another post. However, in this thread I want
Do you find yourself dealing with heterogeneous arrays often? It might be
useful to post some examples where this comes up to the list.
Julia compiles specialized versions of functions for the concrete types they
are called with at run time, so you should usually think of the types in
function
The real root issue here is parametric
variancehttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science).
Julia has opted for parametric invariance – i.e. that P{A} : P{B} only if
A = B – which is what James mentions in his StackOverflow answer. The
wikipedia page does a
Suppose the types that you want existed. Let's call them ConcreteArray, and
Cell.
ConcreteArray gives the guarantee that all of it's elements are stored directly
with a fixed stride.
Can you give some examples of functions that would use these in their type
signature?
Thinking about it some more, the big problem with covariance is that it
forces the confusion of two distinct meanings of P{B} for abstract B:
1. The concrete instance of type P with actual parameter type B.
2. The abstract type including all instances P{A} where A : B.
If P{B} meant the
Le mardi 29 avril 2014 à 11:51 -0400, Stefan Karpinski a écrit :
[...]
1.
The explicit distinction between A – the actual parameter type of x –
and B, which is simply an upper bound on A, becomes clearer in
situations like this:
frob{A:B}(x::P{A}, y::A)
