Multidimensional Virtual Classes

Being on the subject of virtual classes: a new article Multidimensional Virtual Classes by Vaidas Gasiunas, Klaus Ostermann and Mira Mezini.


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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Link...

The paper is here...

Thnx

Made the appropriate correction.

Clueless question

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.

??

I really don't understand the point of this. The text talks about it a little at the beginning, but I can't figure out anything from the examples--would anyone like to clue me in?

I'll Happily Try

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.

OCaml

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.

Oh, I get it. Thanks for the

Oh, I get it. Thanks for the link.

Living w/o type classes in O'Caml?

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?

And can anyone recommend a good dead tree book for learning O'Caml? In the future, there's Practical OCaml. Any others worthy of mention? Or should I just bite the bullet and try printing and binding something like Developing Applications With Objective Caml?

Nice Isomorphisms Between Typeclasses and O'Caml Modules

Please see Oleg Kiselyov's Applicative Translucent Functors in Haskell. Here I quote the "upshot of the translation" section at the end:

The upshot of the translation:

ML signatures correspond to Haskell type classes, and their
implementations to the instances

Abstract types in ML correspond to either uninstantiated or
explicitly quantified type variables in Haskell

Type sharing is expressed via type variable name sharing

Functor (signatures or structures) correspond to Haskell (class
declarations or instances) with type class constraints

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).

With respect to dead tree books, I quite like O'Caml for Scientists.

One thing I do believe is

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)

Functors and Type Classes

Don't know if it helps, but Andreas responded to a question I had on the comparison between ML Functors and Haskell Type Classes.

Yep

Good point!

Do they pass the Oleg test?

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?

Sure

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.

Overloading

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.

Sure

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.

Modular Type Classes

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'd been about to link to

I'd been about to link to that. I'd been toying around a bit on my own with a different but pretty obvious approach - I should bash up some code sometime.

Was this item supposed to go

Was this item supposed to go on the home page, Niels?

Please explain

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

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.

Anyway, I can promote this thread to the home page if you want.

Corrections

Is there any way to make small corrections and not have the item pop up at the top of the list?

No, not as far as I know.