[plt-scheme] define-union

Robby Findler wrote:
> My point (a little less faciciously :) is that the complexity of
> an implementation means nothing for the ability of the student
> to understand it. What matters is if you present a seamless
> abstraction that the students can use as their model. The
> complexity of the implementation of such a model is irrelevant.

You're right, in general.  For example, I wouldn't argue against something
like the EOPL define-datatype macro, because it's a more sophisticated and
comprehensive construct.  What I see here, though, is functionality that's
very simple being hidden behind an abstraction barrier that may make it
appear more complex than it is.  In this case, being so simple, I think
showing the macro, i.e. showing what a simple transformation is involved to
achieve the functionality in question, could be helpful in understanding.

I'm not suggesting not using an abstraction, but rather picking an
abstraction that's appropriate to the problem.  Having (define-union snark
(foo bar number)) create a construct called snark? which relies on three
functions called foo?, bar? and number? could easily be confusing instead of
helpful, despite the parallel to define-struct.

(define-union snark? (foo? bar? number?)), or Jacob's alternative proposal,
defines what it says it defines, and relies on the functions listed.  If
define-struct could be implemented as easily, I'd advocate doing that too.
The original spec attempts a certain kind of consistency, but my suggestion
offers a different sort of consistency, and a simpler implementation.

> Taking this view to an extreme, one might think that the only way to
> explain computers at all is by showing them a "simple" translation to
> assembly language and explaining how the machine works in terms of the
> "simple" assembly language interpreter and the compiler translation.

Some CS courses do more or less exactly that...  :)

Anton