[plt-scheme] PLT v 4.0 discussion - separating interfaces from implementation

Increasingly, programming is all about learning how to separate
interfaces from implementation.

PLT 4.0 offers at least two standard mechanisms for doing this.

1.  Class and object-based programming.  OO is one of the most popular
mechanisms for separating interfaces from implementation, and it's
good that you can do it in Scheme.  One disadvantage is that your code
gets cluttered with send statements.  And of course, with the
exception of the MrEd library, OO doesn't seem to be used much by the
core libraries, so you can't really leverage OO design principles to
extend the built-in functions of Scheme to operate over new data
structures.

2.  Units.  These don't seem to get much use, possibly because they
seem complex?

3.  Interestingly, PLT 4.0 does give us a taste of what it would be
like to have common interfaces for important categories of datatypes.
Sequences and dictionaries are the most obvious examples (are there
more that I didn't notice?)  I find it curious that rather than use
either of the above mechanisms for achieving this goal, both are
written in sort of an ad-hoc manner.  To create a new datatype that is
categorized as a sequence, you need to set a certain property flag in
the struct, and then create a thunk returning six functions as values.
 To create a new datatype that implements the dict interface, you need
to set a property flag, and then create a vector of ten functions.
Values for one, and vector for another?  Rather inconsistent.
Furthermore, it just doesn't feel like a scalable approach to
separating interface from implementation.  Passing in a vector of ten
functions (better get the order right!) already seems
borderline-laughable; what if your interface grows even bigger?

So why did the developers choose to separate interface from
implementation by using an ad hoc mechanism rather than one of the
standardized mechanisms for doing this?  Is it a performance issue, or
are the standardized mechanisms simply too complicated and/or burdened
by excessive syntax demands?

I think that arriving at a solid, consistent way of doing this would
be a great goal to consider in future versions of PLT Scheme.

--Mark