This is the mail archive of the
mailing list for the Guile project.
Re: Trouble understanding define (!)
- To: Jost Boekemeier <jostobfe at calvados dot zrz dot TU-Berlin dot DE>
- Subject: Re: Trouble understanding define (!)
- From: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 01 Feb 2000 15:35:01 +0200
- Cc: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>, Neil Jerram <neil at ossau dot uklinux dot net>, guile at sourceware dot cygnus dot com, djurfeldt at nada dot kth dot se
- Organization: who? me?
- References: <200001142054.UAA00622@ossau> <firstname.lastname@example.org> <200001182250.WAA00624@ossau> <email@example.com> <200001221200.MAA00478@ossau> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Jost Boekemeier <firstname.lastname@example.org.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 <email@example.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.
You know better than to trust a strange computer.