Or: Reflections on Generics, Multi-Method Dispatch, Interfaces, and Parametric Roles

Generics are a cool hack.  If “123″ and “Foo” are of two different types (say, an integer and a string) they can still share code for some methods.  For instance, one might want both to have a print() method: 123.print() and “Foo”.print(), and one might want them to share some code.  Using generics accomplishes this and also helps express the “sameness” of these two methods in code.

Multi-method dispatch is related for some use cases.  With multi-method dispatch, I can define multiple print() methods, and the compiler will distinguish which one I want based upon the argument.  Thus, print(123) and print(“Foo”) are two different methods even if they live in the same namespace.  The programmer doesn’t have to remember more than one (e.g. print_int(123) and print_str(“Foo”)).

Interfaces are another interesting and related concept.  By defining a printer interface, I could specify print() methods are required and later any type that supports these methods is said to “implement the interface.”  The code might be scattered around this way, but any type that implements the interface can be used interchangeably using the interface.

Parametric roles occupy another cool little spot in the ecosystem.  It’s essentially the same as the interface described above, except it can take a parameter and dispatch on the inside.  With a parametric role, one might keep the code a bit more centralized but still implement interfaces in a way that the user of the interface doesn’t need to think about it too much.

Each of these techniques has advantages not described here, but I want to zero in on a single nuance of the behavior that’s shared between all of them: a term (e.g. the word “print”) can be reused and do something different in different circumstances.  Thus, even though each time the term is encountered it executes a different codepath, the same term gets used.

I’m going to call this, collectively, “term oriented programming.”  If there’s a name for it already, someone correct me.  In the meantime, I have something I want to say about term oriented programming:

teh awesome

Seriously.  Mostly it’s awesome for programmers, because we can organize our code somewhat differently, without causing too terrible of havoc for the compiler.

What I want now, is more of it.  I can imagine an argument that I’m looking for a Lisp, or that I just don’t like namespaces and I want to use PHP, and the list goes on…  But what I really want is to collect all the different meanings of the term “print” into a single location (alphabetically, perhaps?) and define how they behave.  Each meaning of the term might give me references to all the places where it is used (sort of like the OED does for first use of particular terms).  It starts to look an awful lot like a lexicon.

A term might have a part of speech, a rigorous definition (defined “in terms of”), some documentation, and some examples.  In fact, the examples might be links to every time the term is used in this particular sense.