[PRL] IOP and disjoint unions

Carl Eastlund carl.eastlund at gmail.com
Thu Apr 28 15:45:45 EDT 2005


On 4/28/05, Dave Herman <dherman at ccs.neu.edu> wrote:
> When you're writing OO code in an interface-oriented way, how do you
> encode disjoint unions? The typical way to do it in class-based
> languages is to encode the variants as subclasses of a base class.
> 
> But in IOP this would entail a separate interface for each variant
> (blech). Worse, variants of disjoint unions in ML-like languages are
> distinguished with dynamic tags, not static types; this would suggest a
> dynamic interface check, which contradicts the intuition of interfaces
> as being static.

What's wrong with a separate interface for each variant?  In ML, you
have a separate type for each variant, and interfaces have a lot in
common with types.  Further, what's wrong with using instanceof checks
in place of ML's pattern matching or Scheme's constructor predicates? 
And who said anything about interfaces being purely static entities?

> OTOH, if you disregard the IOP style and make the client code test for
> specific classes, then that prevents you from being able to change the
> implementation of the disjoint union later.

All the above was based on your notion of a separate interface for
each variant, but I wouldn't do that at all.  Here's a simple
interface for a disjoint union representation of an abstract syntax.

interface AbsSyn {

  // Predicates report whether expression has the queried form.
  Bool isAbs();
  Bool isVar();
  Bool isApp();
  
  // Selectors produce data from within the expression,
  // or raise InvalidSelector if expression does not have expected form.
  String varName();
  String absVar();
  AbsSyn absBody();
  AbsSyn appProc();
  AbsSyn appArg();
}

I don't know if this is The Way to write disjoint unions as
interfaces, but it works for me and avoids the difficulties you
described.

--Carl



More information about the PRL mailing list