This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: A module system should resolve, not introduce, name conflicts
- To: Michael Livshin <mlivshin at bigfoot dot com>
- Subject: Re: A module system should resolve, not introduce, name conflicts
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 24 Feb 2000 22:19:50 +0100
- Cc: guile at sourceware dot cygnus dot com, djurfeldt at nada dot kth dot se
- Cc: djurfeldt at nada dot kth dot se
- References: <xy7snyie7cv.fsf@mdj.nada.kth.se> <s3ema2cnuq.fsf@verisity.com>
Michael Livshin <mlivshin@bigfoot.com> writes:
> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
>
> > My position is that the idea of mixing forms of the module
> > configuration language with the bindings it's supposed to manage is
> > flawed. Using Marius' terminology it's even more clear: The name
> > space manager should not contaminate the name space.
>
> which of the two things below do you mean?
>
> 1. it is desirable to have the ability to conceal the name management
> functions from code that doesn't need them.
>
> 2. name management should be a separate language from Scheme and
> never shall the two meet (this looks like a citation. where is it
> from?).
I mean
3. name management bindings should not normally live in the name
space which they manage
This differs from 1 in that code normally doesn't see name space
management bindings.
It differs from 2 in that name management bindings still can be
ordinary Scheme bindings managed by the name manager.
The paper shows how this works in Scheme48. RScheme has a very
similar module system.