Please open Zipper.lava in LavaPE.
Please open StringList.lava in LavaPE.
Rebuttal of two counterexamples presented in [4] as an evidence for the difficulty to cope with certain situations on the basis of virtual types.
The article [4] by Bruce, Odersky and Wadler presents two little samples that shall demonstrate inherent flaws of virtual types. We show that they actually don't cause any problems in Lava.
Zipper:
This sample reads as follows on the basis of "parametric polymorphism" in Java-like syntax:
public class Pair<Fst,Snd> {
public Fst fst;
public Snd snd;
}
public class List<A> {
...
public <B> List<Pair<A,B> zip (List<B> y) { ... }
}
Semantics: The member function zip of class List<A> composes a list of pairs of elements of type A and B by combining the corresponding elements of its "this" object (of type List<A>) and its input y (of type List<B>, where B is a type parameter of zip). According to [4] the problem is the declaration of zip on the basis of virtual types. Our Zipper.lava sample demonstrates that this doesn't cause any problems in Lava. Note, however, that we use a containing package with two virtual types, a concept that the authors of [4] do not provide in their notion of virtual types.
Note also that the Lava version is longer since Lava has no type expressions, but the specialization of virtual types requires the explicit declaration of a derived package or class (including the assignment of a name). We believe, however, that this assignment of individual names makes programs more readable in general, while the ubiquitous nature of type expressions with parameters rather impairs the comprehensibility of programs. (A look into the "Standard Template Library" (STL) of C++ should suffice as an evidence.)
Using "parametric polymorphism" this sample reads:
public class Collection<A> { ... }
public class List<A> extends Collection<A> { ... }
Then one can pass, say, an argument of type List<String> where one of type Collection<String> is expected. The same, however, is true for our StringList.lava sample, as is demonstrated in its initiator "StringListDemo". (The role of the "Collection" type is played by the basic built-in type "Set" of Lava.)
What matters here is that we have multiple inheritance in Lava, while Java classes support only single inheritance. This allows us to derive "StringList" from "List" and from "StringSet" and thus makes "StringList" compatible with "StringSet"
The CarMeeting sample illustrates essentially the same situation but uses a substitutable type for the input parameter of the meet function. This allows us to pass an actual parameter of type CarList to a formal parameter of type VehicleSet (which would be incompatible otherwise).
So the proper conclusion from these two samples isn't that virtual types are principally inappropriate in such situations but that they should be combined with multiple inheritance in order to make normal class derivations and the specific "VT-specialization derivations" independent of each other.