agenda for the June 25 R5RS meeting: Proposed Objection

[kend@data.rain.com (Ken Dickey)]

Morry,

I think that you are making excellent points.

My motivation for the proposal is that most Scheme compilers (JINX
tells me that MIT Scheme is the exception) do not generate as
efficient code for closure based OO systems as for vector based
systems.  This is largely due to not sharing closures for `methods'
among all instances of an `instantiator'.  My observation was that a
small operational change (having instances `carry' their environment)
leverages off of the lexical analysis which most compilers do anyway.
Small cost; large gain.


> It can be implemented in terms of the existing core.

Yes.  The question is one of space efficiency.  JINX has suggested
that proposals in this category should be handled by letting user
constituencies beat upon implementors on "efficiency only" issues.


My more general concern is that certain solutions are naturally coded
in an OO style.  Many users of Scheme desire an OO solution and the
authors' group should at least _discuss_ efficient support for the
right OO solution (or set of solutions) which are well factored and
work well with the core.  I would prefer that this language design
work be driven by the authors and not the users because I suspect that
better solutions will arrive (although I am personally happy to take
good ideas from anywhere).  What I don't want to see is further
language fragmentation based on random OO-ness rather than well
thought out solutions.

So my secret is out.  What I really want to see is this proposal
replaced by a better one.


> I furthermore see no compelling argument for this new functionality
> that convinces me that it is worth increasing the size of the core to
> facilitate it.

I know the above is out of context but to repeat the obvious, OO
solutions are natural in some areas because they are found to be
useful.  So OO systems will continue to be generated.  The right
increase in the size of the core should be supported if this is what
is required to support a generally useful programming style.  This
particular proposal is probably not the right thing.  Perhaps it is my
limited context, but I would like to see more work on "the right
thing".  [I certainly see enough OO proposals which I consider the
wrong thing].  My personal perception is that few authors are
interested in the problem, but many users are interested in the
solution.  I would like the authors to change my perception.


-Ken