On Wed, Aug 10, 2011 at 9:16 AM, Robert Fischer <smokejumpe...@gmail.com> wrote:
> What does "subtyping" mean in a prototype language with structural
> types? There is no such thing as a "parent" or "child" type, so the
> type hierarchy context — the only context where "subtyping" means
> something to me — doesn't exist.
>
> Consider these two records:
>
> let x = [
> add: { a, b -> a + b },
> subtract: { a, b -> a - b }
> ]
> let y = [
> add: { a, b -> a + b },
> multiply: { a, b -> a * b }
> ]
>
> Which is the parent? Which is the child?
>
Neither. But consider the types:
let x = [
add: { a, b -> a + b }
subtract: {a, b -> a - b }
]
let y = [
add: { a, b -> a + b }
subtract: {a, b -> a - b }
multiply: {a, b -> a * b }
]
Here, the type of y is a subtype of the type of x. Anywhere x can be
used, y can be used- but there are places where y can be used that x
can not be used. The type of y is a subtype of the type of x. The
types exist no matter how they are declared, or even if they aren't
declared at all.
One point I would like to make here is that not all downcasting is due
to co-/contra-variance issues. Consider the situation where you have
a "number" that contains the member add. Now, it makes sense to add
two reals together (I'll grant you that all reals are in some sense
fungible, even though this leads to unexpected code behavior), and it
makes sense to add two vectors together, but it doesn't make sense to
add a real to a vector, either mathematically or programmatically.
And it makes sense to define algorithms which work on
sets/lists/arrays of reals and sets of vectors, but not on mixed sets
of reals and vectors. So how do you define this constraint in the
type system?
> If you do something like this:
>
> let xs = x :: [x]
> let ys = y :: [y]
> let xys = x :: y :: [x]
>
> Then the types are all well-defined: list of things like x, list of
> things like y, list of things like x-or-y. You can't turn "xys" into
> a list of xs or a list of ys, because it's neither.
>
And what can I say about an element I've taken off a list of x-or-ys,
say by using List.head? Without doing some sort of run time type
identification, or having a type system that is complex enough to keep
track of which elements in the list are xs and which are ys (which is
a way more complicated type system than Ocaml, Haskell, or Scala-
we're talking Coq, Twelf, or similar at this point).
In this example, both x and y have a common supertype, the type of
objects with an add function.
> The only place where I've found subtyping issues is with code like this:
>
> let foundXs = xys.findAll { it -> it.like(x) }
> (Where "like" is "structurally identical to".)
>
> The list "foundXs" is now a list of "x"-like structures, even though
> the type is a list of "x-or-y"-like structures. But that—like a
> couple of the similar cases I've encountered—are what *should be*
> match statements being dropped in strange places, usually because of
> an OOP accent in the programmer. And it's easy to define a
> properly-typed findAllLike, if you really wanted to stick to it:
>
> let findAllLike = {list,type -> list match {
> case () => ()
> case (a:type) :: rest => a::findAllLike(rest, type)
> case a::rest => findAllLike(rest)
> }}
>
Congratulations, you've reinvented Java's instanceof.
> So it doesn't seem to be a problem to reject importing the idea of
> "casting up", which is good since it doesn't even really mean anything
> anyway in this context.
Except you have up casted- take a look at that middle case there. On
the left hand side of the =>, a has a type x-or-y, on the right hand
side, it has the type x. I mean, in Java the above code looks like:
Vector<sometype> res = new Vector<sometype>();
for (x : lst.iterator()) {
if (x instanceof sometype) {
res.add((sometype) x);
}
}
Brian
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
