Re: setf.scm

[thi <ttn@mingle.glug.org>]

Per Bothner writes:

 > This does sound rather expensive, but I think one could come up with
 > clever ideas to keep things reasonably fast, especially for teh
 > single-dispatch case.  The real question is: How well would such a
 > system work for the programmer?  I don't know.  I would be very
 > curious to know.

as a common programmer (w/ no experience designing object-systems), i
tend to think of modules as embodying a certain type, that is the type
of object that the functions in the module can apply to.  this usually
is a primitive type conceptually cast; eg., a "schedule" type is really
a list w/ certain properties, and the scheduling module is responsible
for creation, update and, in general, invariance maintenance of this
type.

i'd like to schedule things other than lists, however, and so under the
current system, would write another module to wrap the list-implemented
scheduling module to handle, say arrays.  so now i have two modules.  it
sounds like what you're proposing is that this wrapping be done somewhat
automatically, w/ the object system preserving semantics by generating
code that understands what types in the first module are substitutable
by other types, and using this understanding to perhaps translate one
type to another.

is wrapping what you're talking about?  if not, i don't see how code can
be made generic w/o changing the code -- does the object system require
back-annotation to current code?

or are you proposing that a module declare its type "applicability" and
thus be open to (run-time?) selection based on type?

pardon my ignorance, i will go read up on MOP.

thi