Random Thoughts Concerning Initialization

[Dick Gabriel <RPG@SAIL.STANFORD.EDU>]

Reading over Gregor's latest proposal I am struck by the choices
we have:

1. In Moon's proposal, we introduce a new programming language within
the DEFCLASS syntax. This language solves the initialization problem
efficiently with minimal syntax. Other problems reducable to initialization
might also be so reduced by users, leading to confusing programming 
methodologies.

2. In Gabriel's proposal, we introduce some additional lambda-list syntax
and semantics to effect the distribution of arguments to methods. This
also requires complex initialization protocol to be written in a verbose
manner, and it complicates lambda-lists in an unpleasant manner.

3. In Gregor's proposal, we solve the initialization problem by reducing
it to a problem of manipulating argument lists. The code (sans macros) is
verbose and complicated. In addition, we end up treating passed arguments
as lists, which I find to be an unpleasant exposure of representation.

If we approach the initialization question along the lines Gregor
suggests, and if we look at the nature of generic functions (dispatching
to code based on examination of passed arguments), it seems there is some
tendency towards introducing into the language a means of operating on
passed arguments. One reason we had trouble with generic functions that
discriminated on more than the required arguments is that we had a hard
time manipulating the passed arguments.

If we choose a solution to initialization that involves manipulating
passed arguments, we possibly ought to provide an abstraction for passed
arguments - a set of passed arguments along with a set of operators that
take them apart, put them together, and invoke functions on them?  I
believe Seus [Talcott] went some distance in this direction.