Re: Trouble understanding define (!)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I don't think generics should be handled any special by the module
> system.  The semantics of generic functions and the semantic of the
> module system should be completely independent.  In the defining
> description of generic functions, there should be no reference to the
> module system; and likeweise, there should be no reference to generic
> functions in the defining description of the module system.
> 
> `(define-generic foo ...)' should be conceptually an abbreviation for
> `(define foo (make-generic ...))' and all the module system
> interaction is derived from the behaviour of `define'.
> 
> `define-method' is more complicated because it behaves differently
> depending on whether a generic function already exists or not.  In my
> view, it would be acceptable to just demand that the generic function
> already exists before adding methods to it.  [This might pose problems
> for the generic functions that are slot accessors, hmmm...]

I would applaud this view if it was purely a question of the design
itself.  However, we need to design something which is convenient to
actually program in.  We had similar discussions a year ago, and I
finally decided to keep the current fairly conservative behaviour
(which is reasonably orthogonal to the module system; exception: the
define-generic/method macros behaving differently depending on the
outcome od `defined?') until I had gotten experience from actually
using GOOPS.

Now that I've used GOOPS some time, I find it reasonably convenient to
work with, but still find it somewhat clumsy and non-intuitive always
to keep careful track of how GFs are shared between modules.  And I
especially don't like to get collisions between accessor names, which
you very easily get when using simple and intuitive names like
`length', `size', etc.  This will be an even bigger problem when
retiring slot-ref/set!.

The bottom line is: GOOPS, as it is now, is clumsy, and I don't like
that!  It should be possible to design away this clumsiness.

> Generic functions shuld be regarded as first class objects that might
> get bound to variables (or not).  The names of these variables are
> handled by the module system, but independently of the type of object
> that they refer to.  After all, a variable might hold different kind
> of objects in their lifetime.  It might start out as `#f' and later
> point to a `ordinary' function, and finally to a generic function.
> Treating generic functions specially is a step away from dynamic
> typing, which I would consider to be a step in the wrong direction.

I certainly don't like treating GFs specially, but if it makes the
system more convenient to work with, I'm prepared to consider it.

Maybe it is possible to generalize the mechanisms in the module system
in a way that it is capable of supporting the new functionality.
E.g., the module system could detect collisions between identifiers,
and call a GF in the MOP, where the default method is reporting an
error, but the method specialized to GFs does something interesting...

Regarding change of value in bindings, the module system has
mechanisms to support calling functions on changes.

In any case: Are we really stuck here?  Surely there must be *some*
solution which is both convenient and acceptable.

> I think it is useful to sometimes clearly distinguish between
> `compile-time' and `run-time' concepts.

[...]

> > * How do we combine this with separate compilation of modules?
> >   (This is an interesting question also with regard to the current
> >   GOOPS.)
> 
> Ideally, the compiler should not need to know about generic functions.
> It might make good use of such knowledge for optimizations, but it
> should not be nneded to have a correct compiler.

What I'm thinking is that it is a good idea to design the interface to
a module in a way that an optimizing compiler can produce efficient
code.  A dumb compiler need not take such information into account,
but I'd like to make it possible to publish enough information in the
interface for a smart compiler to eliminate most type dispatch.

[I'll answer more letters later.]