Re: Trouble understanding define (!)

[Marius Vollmer <mvo at zagadka dot ping dot de>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Two questions now:
> 
> * Is this semantics too complex and obscure?

Yes.

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...]

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 think it is useful to sometimes clearly distinguish between
`compile-time' and `run-time' concepts.  Modules, macros, and
variables with their names are on the compile-time side; classes,
procedures and generic functions with their methods are on the
run-time side.  

[ One _could_ hoist classes and generic function to the compile-time
  side, like C++ does, but I hope that the mere mention of C++ is
  enough to dispute this choice. ]

Of course, this distinction depends on the viewpoint, and the
compile-time things should be reflected back into the run-time, so
that there is run-time access to the compiler, the module system, etc,
but one should be aware that one is now one level above the code one
is compiling, or the objects that are given names by the module
system.  Just like one needs to be aware of the differences between
the code that computes macro expansions, and the code that they expand
into.

> * 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.

That's my take on this stuff, anyway.

- Marius