Multidimensional Virtual Classes

Virtual classes and static type systems for them are gaining attention because of their support for variations on functionality that involves several classes. Like the majority of object-oriented languages, previous languages with virtual classes use single dispatch for dispatching virtual classes. We show that single dispatch limits the range of the variations supported by virtual classes and propose
multidimensional virtual classes, which combine virtual classes with multi-dispatch, and show how this combination improves their support for variability. We present a formal semantics of a language with support for multidimensional virtual classes and discuss some issues related to the design space of such languages.

How might such multidimensional virtual classes relate to
On the unreality of virtual types which is oft mentioned on LtU? My current "understanding" is that the O'Caml paper is saying virtual types (and my current "understanding" is that virtual types ~ virtual classes) are kind of less than optimal.

First, I suggest that you read this, and follow the links from it. In particular, follow the link in the post immediately following mine, to "Independently Extensible Solutions to the Expression Problem," which does the best job I've seen so far of describing the problem space and explaining why the currently popular statically-typed languages have difficulty addressing it. It then shows why Scala doesn't suffer from these problems. "Code Reuse Through Polymorphic Variants" and "On the (Un)reality of Virtual Types" both do an excellent job of explaining why O'Caml doesn't suffer from the difficulties, either. In the post that I link to above, I basically copy straight out of "Code Reuse Through Polymorphic Variants" the solution to writing an open evaluator for a language of variables, lambda expressions, addition, and multiplication, where each mini-language (evaluator for the "var expression" type, evaluator for the "lambda expression" type, evaluator for the "addition and multiplication expression types") is developed independently of the others, but they compose successfully and without contortions of any kind. "On the (un)reality of Virtual Types" in particular makes the strong point that correct typing of binary methods, open self types, and structural typing are sufficient to handle the "expression problem" without resorting to higher-order polymorphism or any of the other heavier-weight approaches to the problem.

At this point I have to confess that sometimes in my static typing advocacy I forget that I'm really advocating O'Caml: very few statically typed languages, even really good ones like Haskell, get as much right as O'Caml does (although GHC 6.5 and all the STM stuff is extremely important). O'Caml's also not pure: it has mutation, for loops, and so on, so it's a lot easier to be an O'Caml convert than a Haskell convert (IMHO). But if all you've experienced of statically-typed languages is even, say, SML/NJ or Haskell 98 vs. GHC, O'Caml, or Scala, no doubt I seem like a madman.

All things considered, I think OCaml is one of the best languages out there. Great tools and performance, good type system with inference, support for OOP (for when its really the right tool for the job), structural subtyping, etc. It's great for converting both dynamic typing advocates and OOP advocates.

Haskell on the other hand is the language most interesting research stems from (although OCaml has FlowCaml and TyPiCal, etc too), and future languages can learn a lot from it. I think these future languages should be impure, but with a purely functional subset you can restrict yourself to: making use of techniques learnt from Haskell. The type system is the other core area that can be improved.

At this point I have to confess that sometimes in my static typing advocacy I forget that I'm really advocating O'Caml: very few statically typed languages, even really good ones like Haskell, get as much right as O'Caml does.

Every time I get bitten by laziness in Haskell, I start leaning towards learning O'Caml. But that feeling goes away when I think about leaving things like multi-parameter type classes behind. So what snazzy new features do I get in O'Caml to help assuage my pain? Apparently there's a nifty module system. Any others? Is there an advocacy site or concise guide available which shows off the bells and whistles of O'Caml?

The argument of functors is expressed via types, with additional labels
when needed for finer differentiation

Functor applications are done by instance selection based on types
at hand plus the additional labels

OCaml signature attribution operation -- casting the module or
the result of the functor into a desired signature and hiding
the extras -- sometimes involves additional tagging/untagging tricks
(cf. SetESet). This tagging, done via newtype, is syntactic only and
has no run-time effect.

Hiding of information (`sealing', in ML-speak) is done by
existential quantification. To gain applicativity, we quantify over
a higher-ranked type variable (Skolem function proper).

One way to interpret this is that O'Caml modules are more straightforward to use than type classes in some sophisticated cases. :-) Another is that you don't "lose" type classes, but the downside is that you do have to actually understand O'Caml's module language (vs. treating it as just a tool supporting separate compilation, which is how I treated it for about the first two years of my exposure to it).

One thing I do believe is lost is the ability for the compiler to figure out the correct module/structure? I do think there're more good things to come of these isomorphisms just yet - the ML approach does have certain freedoms that typeclasses don't (more than one instance for the same tuple of types, for example)

I'm not quite understanding what that means. Do you always have to fully qualify the functor(?)? Or, here's a slightly different way of asking if modules can subsume type classes. Can you more-or-less translate things like Number-parameterized types, etc. into O'Caml?

As far as I can tell, "Number-parameterized types" just require the ability to encode numbers as existential types. "Existential types" in members of the ML family are just types that are left abstract in the module's signature. See the end of this post on the O'Caml mailing list for an example of using "phantom types" (which must be existential, hence abstract, hence expressed via a module signature) to provide statically-dimensioned arrays.

Actually, AFAIK, Haskell's type classes (with a number of extensions) allow you to specify rather arbitrary relations on types. No such mechanism exists in Standard ML or, AFAIK, in O'Caml for that matter. Intuitively speaking, I find that "evaluation" at the type level is "parametric" in ML and "non-parametric" in Haskell.

As far as I can tell, "Number-parameterized types" just require the ability to encode numbers as existential types. "Existential types" in members of the ML family are just types that are left abstract in the module's signature. See the end of this post on the O'Caml mailing list for an example of using "phantom types" (which must be existential, hence abstract, hence expressed via a module signature) to provide statically-dimensions arrays.

There have been rumblings in the ML community about type classes as a usage pattern of modules. The only thing I've come across so far is a draft of Modular Type Classes by Dreyer, Harper, Chakravarty and Keller.

I contributed this thread a couple of weeks ago and reading it back I realized I made links to the home pages of two of the authors while omitting the third. So I corrected that.
When contributing this post I was not an editor yet, so I had no rights to put it anywhere else. Now that I have the proper authorities I will be careful putting my contributions in the appropriate category.
Is there any way to make small corrections and not have the item pop up at the top of the list?

Sorry about that, I didn't notice this was an old thread (I usally do...). Changes appear at the top of the tracker: that's the whole point of the tracker (the "recent posts" page) and it's a Good Thing, otherwise changes will never be noticed.