Re: Proposal: Module name space layout

[Rob Browning]

Martin Grabmueller <address@hidden> writes:

> So the first thing to decide is: Which of these policies should we
> adopt?  Personally, I think that it is not possible to cleanly use
> exactly one of the possibilities, we will probably use a mixture of
> them.  I propose to group by functionality, and maybe use some
> `bridge-modules', which make functionality available when the user
> requests the modules for a given standard.

I tend to agree.  Even if we distribute the srfi functions to their
relevant functional modules, I think the user should still be able to
say

  (use-modules (srfi srfi-1))

or similar and get the right effect.  If we can structure these
modules as "meta-modules" that can both provide their own code and
export *some* symbols from other places, then they'll also provide a
good way of checking our compliance with the relevant SRFI (i.e. We
can see from one file if we've covered everything.)

Also, for it to be useful, we'll probably need to put srfi-0 into the
core, and might even want to make it runtime-extensible.  I actually
already have an implementation for srfi-0 for guile that includes a
"private" module (use-modules (srfi srfi-0-provider)) that allows
other modules to publish new srfi-0 "features" at runtime:

  (use-modules (srfi srfi-0-provider))
  (srfi-0-add-supported-feature 'srfi-1))
  ...

However, I'm not really comfortable enough with the
scoping/namespace/compile vs eval time/etc. issues to be sure the
things I'm doing in there are OK for more general consumption...

One other issue that's probably more of a module system implementation
issue, is that of binary object files.  We need to make sure we keep
in mind that these modules might be implemented in terms of .so files
that depend on other .so files, and that probably belong in an
architecture independen directory.  However, I suspect the way to
address that will be via appropriate module file search rules.

Anyway, thanks for getting this discussion started.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930