Re: Trouble understanding define (!)

[Michael Livshin <mlivshin at bigfoot dot com>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> [I haven't red the whole discussion yet, so this may be 
> out of context]

no, it's fine.

> Michael Livshin <mlivshin@bigfoot.com> writes:
> 
> > 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)
> 
> Such a module exists.  The config module (currently not a
> full-featured module but only an environment) is a repository which
> holds (references to) all loaded modules and the (non-exported) load-path.
> 
> However, what Mikael wants is that some methods should be secret and
> hidden within the module boundaries.  

[ I assume this is Mikael speaking: ]

> > I'm not so sure that it is a good idea that one environment holds all
> > classes and generic functions.  In fact, I'm pretty sure it isn't a
> > good idea.  That would mean that we're severely limiting our ability
> > to encapsulate parts of an implementation.

exactly.  and that's what I say too: we can have both.

(define-generic NAME ...) defines NAME in the global module, but noone 
stops you from saying
(define NAME (make-generic ...)) and having it in your preferred
scope.  or (define-extended-generic NAME #:imports OTHER) as Neil
suggested, to extend other generic without changing it.

and all that this requires from the module system is that it provide
such a magic module (which could be useful for other things, although
I can't think of any right now).  what's good is that the module
system doesn't have to bend over backwards to support generics.

> Jost

--mike

-- 
You know better than to trust a strange computer.