Re: Trouble understanding define (!)

[Michael Livshin <mlivshin at bigfoot dot com>]

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

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

yes, IMHO.

here's my take on the situation, after I took an hour to think it
through.

1. we don't have to choose one or the other of two choices ("place
   generics in their own global module" or "use usual module system
   rules").  we can have both, and the decision as to where to place a 
   new generic is straightforward (see below).

2. an observation: generics are semantically closer to modules than
   they are to functions -- they are modules that bind method
   signatures to procedures.  i.e. the names are lists of classes
   (instead of symbols) and the lookup is by "cpl-closeness".

3. if the Kiczales's rule is enforced, there's no possibility of name
   conflicts.  example:

  (define-method draw ((figure <circle>) (device <bitmap>))
    ...)

  conceptually defines a procedure named `(<circle> <bitmap>)' in
  module `draw'.

4. with the above in mind, we can conclude that we can safely have a
   "magic module" that everyone imports called (generics).  (note that
   we will have one such "magic" module anyway, called (scheme),
   though it's unmodifiable)

   [ Mikael: what scalability problems do you have in mind? ]

now.

(define-method NAME SPEC ...)
  - if NAME is bound, then it must be a generic, and we extend this
    generic with the method
  - if NAME is unbound, we execute (as if) (define-generic NAME), and
    then extend it with the method.

(define-generic NAME ...)
  - makes sure that we have a generic object bound to NAME in the
    magic module (generics), and do nothing if it already exists.  it
    is an error to export NAME from the current module.

(define NAME (make-generic ...))
  - use this if you want to have a non-global generic for whatever
    reason.

metaobjectively yours,
--mike

-- 
I'm on a seafood diet -- I see food and I eat it.           -- anonymous