This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: New module system wishlist
- To: Lalo Martins <lalo at hackandroll dot org>
- Subject: Re: New module system wishlist
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 15 Feb 2000 09:17:16 +0100
- Cc: guile at sourceware dot cygnus dot com
- References: <E12AixQ-00062S-00@mdj.nada.kth.se> <p2tn1q0sor1.fsf@pampelmuse.zrz.tu-berlin.de> <p2tiu0glx3w.fsf@pampelmuse.zrz.tu-berlin.de> <p2t1z6on2l4.fsf@pampelmuse.zrz.tu-berlin.de> <20000212013602.C760@hackandroll.org>
Lalo Martins <lalo@hackandroll.org> writes:
> This is actually probably a wish on the environment system...
>
> - Sub-namespaces and Acquisition.
>
> This is a generalization of a concept used in Zope. The idea is
> that you have an hierarchy of namespaces, say
>
> A
> B
> C
> D
> E
>
> A symbol defined in A is visible in any of the namespaces. A
> symbol defined in B, D or E is only visible in that namespace.
> A symbol defined in C is visible in C or D.
Yes. Environments already support this feature. If you
set the export-signature to #f, an export-environment
exports all symbols. If you connect D's import-environment
to the export-environment of C and E, you'll get the
desired effect.
And the module system should support it, too.
From an old discussion:
5. More than one module per file with nested modules
Definition: A nested module is a anonymous module which is contained
in another module and doesn't have an import clause.
[...]
(don't look at the examples I've given, they're ugly.)
Jost