Abdulaziz Ghuloum wrote:

Let's take a simpler example.  Suppose you're designing an object
system.  You get to choose whether you want your classes or class
definitions to be expand-time entities or run-time entities (or
both), right?

In the expand-time model, you would do
  (define-class foo ---)
so that you attach the expand-time information to the foo identifier
and so that subsequent uses of foo (e.g., for inheritance) can, at
expansion time, request and make use of the expand-time information.

In the run-time model, you would do
  (define foo (class ---))
so that class returns a first class object (a class descriptor) that
contains all the information about the class definition at run time.

[if you don't like the class example, use (define-c-procedure ---)
vs (define --- (c-procedure ---)), (define-signature ---) vs
(define foo (make-signature ---)), or your favorite example and the
same argument holds]

I advocate the first model because (1) it allows us to provide
information at macro expansion time by binding it to the foo
identifier directly, and (2) it allows us to also provide some
(possibly different) information about the class at run time
to support run-time operations (e.g., instantiation, etc.).

Note that the first model does not necessarily conflict with
having run-time operations on classes such as creating new
classes, etc.; it just says that expand-time operations are
defined on syntactic classes where the expand-time information
is available and not on procedurally-created classes since
no expand-time information is available about them.

Note also that I'm not talking about optimizations here, only
about what information is available at different times.

In the other model, when your classes are first-class objects,
all you can say about foo at expansion time is that it's a
variable and this is not enough.  This means that you cannot,
for example, ask (at expansion time) whether foo is a class
definition, what its parent is, what its defined instance
variables are, and what operations it supports.  Yes, foo is
a first-class object at run-time but that means that *all*
operations on it have to be performed at run time.  This is
not always desirable.

This is similar to what I mentioned in a previous email today about getting procedure information (like arity) from the symbol that it's bound to.

But from the above, it sounds like the only way to do this is to have a new:

    (define-procedure abc ---)

form...

Ed

Reply via email to