[PRL] IOP and disjoint unions

Dave Herman dherman at ccs.neu.edu
Thu Apr 28 16:12:16 EDT 2005


> 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

No, you have a separate *constructor* for each variant. The results of 
all the constructors have the same type.

> 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?

Well, then you have interfaces playing two different roles: 1) as types 
describing the operations required of any implementation, and 2) as 
dynamic tags differentiating between different variants of a type. I 
guess I can't really find fault with this, but there's something about 
it that bothers me.

Let me try an example:

     interface Term { }
     interface Var extends Term {
       String name();
     }
     interface Abs extends Term {
       String varName();
       Term body();
     }
     interface App extends Term {
       Term rator();
       Term rand();
     }

An implementation would look like:

     class MyVar implements Var { ... }
     class MyAbs implements Abs { ... }
     class MyApp implements App { ... }

And the client code looks something like:

     mungeVar(Term x) {
         case (x instanceof Var) { ... }
         case (x instanceof Abs) { ... }
         case (x instanceof App) { ... }
         else: throw new UnrecognizedTerm(x);
     }

I suppose this isn't so bad now that I write it out. Maybe some 
syntactic sugar would help cut down on some of the boilerplate.

> 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 much care for this approach. There's no indication of which 
operations belong together in which variants.

Dave



More information about the PRL mailing list