Hi,
Andy Wingo writes:
> Hi,
>
> On Thu 08 Apr 2010 01:01, l...@gnu.org (Ludovic Courtès) writes:
>
>> Julian Graham writes:
>>
I'm still inclined to think that the module namespace hierarchy (and it
is a hierarchy) should not impinge on the environment of an evaluation.
But, not
Hi,
On Thu 08 Apr 2010 01:01, l...@gnu.org (Ludovic Courtès) writes:
> Julian Graham writes:
>
>>> I'm still inclined to think that the module namespace hierarchy (and it
>>> is a hierarchy) should not impinge on the environment of an evaluation.
>>> But, not something we can change right now.
>
Hi,
Julian Graham writes:
>> I'm still inclined to think that the module namespace hierarchy (and it
>> is a hierarchy) should not impinge on the environment of an evaluation.
>> But, not something we can change right now.
>
> This is actually causing me some difficulty -- I'm implementing the
>
Hi Andy and Ludo,
> I'm still inclined to think that the module namespace hierarchy (and it
> is a hierarchy) should not impinge on the environment of an evaluation.
> But, not something we can change right now.
This is actually causing me some difficulty -- I'm implementing the
R6RS composite l
module. Do a (module-ref (resolve-module '(ice-9)) 'threads)
>> sometime.
>
> I think I found a possible use case for the hierarchical name space. :-)
>
> Suppose we want something like PLaneT or Eggs, let’s call it GUMM
> (Guile’s Unified Module Machinery). Ideally,
ound a possible use case for the hierarchical name space. :-)
Suppose we want something like PLaneT or Eggs, let’s call it GUMM
(Guile’s Unified Module Machinery). Ideally, we’d want to be able to
write this:
(use-modules (gumm foo bar))
Such that:
- If a (foo bar) module exists loca
