This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Trouble understanding define (!)


Michael Livshin <mlivshin@bigfoot.com> writes:

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

Hmm.
As I understand it for a module M´ inheriting from M there is a
generic G (fixme: G or G´?)  which holds the methods that M´ exports.

A module M[I,J] which imports I and J must create a new generic GIJ
which imports I and J.  Yes?  

Both G+ (== GIJ) and M+ (== M[I,J]) are modules and handle feature 
renaming as usual, yes?


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

It isn´t really a "magic" module.  The meta-module (currently called
config-environment) is simply the the module which exports all
modules.  It represents the current state of the system.  It also
holds the load-path for example and other environment variables, for
example $GUILE_HOME.


Jost
-- 
PS: About "parametric modules":  Do you know a dedicated QUAKE 
server where we can discuss this issue? :))

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]