[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