This is the mail archive of the
mailing list for the Guile project.
Re: A module system should resolve, not introduce, name conflicts
- To: Neil Jerram <neil at ossau dot uklinux dot net>
- Subject: Re: A module system should resolve, not introduce, name conflicts
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 03 Mar 2000 16:59:29 +0100
- Cc: guile at sourceware dot cygnus dot com
- References: <firstname.lastname@example.org> <200003030140.BAA02921@ossau>
Neil Jerram <email@example.com> writes:
> I don't understand the paragraph where Rees' says "The need to make
> structures and interfaces second-class instead of first-class results
> from the requirements of static program analysis: ..." (page 12). Can
> someone explain?
It shouldn't be possible to write something like this: (define
my-module-interface (compute-interface ...)) because this would
prevent a compiler/optimizer from doing its job.
> (What's the difference between (i) a "second-class object" and (ii) a
> first-class object bound to a name in a namespace that is only
> accessible through procedures like define-module, use-module,
> list-modules, etc.?)
No difference. (At least from the user's point of view).