namespace problem for imported variables

[Neil W. Van Dyke]

I'm writing reusable Guile modules, and finding that the essentially
flat namespace for exported identifiers is a noticeable problem.

Two issues:

  1. Trying to keep the identifiers unique seems to result in unwieldy
     identifiers in practice, and there's still opportunity for name
     collisions.

  2. Fixing the namespace problem with some later incarnation of the
     module system means for pre-existing reusable modules that either:

       a. the reusable modules must continue to provide their old
          unwieldy public identifiers; or

       b. clients of the reusable modules must be modified to use the
          new identifiers instead of the old ones---without the benefit
          of static-checking mechanisms that are standard in some other
          languages.

Anyone have a near-term solution to this namespace problem?  

Generic functions selected on typed arguments partly mitigate the
problem, but not entirely, and they don't help code that doesn't want to
require loading of an object system.

Java-like optional qualification of imported identifiers with package
name could be good.  Though it's easy to make a cumbersome syntax for
this.

I saw some suggestion of a mechanism for mapping imported identifiers to
user-specified local names.  I'm unaccustomed to this, so I'd be willing
suspend bias and give it a try.  It seems like a general mechanism upon
which people would tend to layer more restrictive mechanisms or
conventions, so in that sense it fits with my notion of Scheme Zen.  It
could easily be cumbersome, though, when you need to import dozens of
identifiers from a given module.


Appendix...

For an example of unwieldy identifiers, let's say I write a general-
purpose HTTP module.  I name it as `(nwv httpclient)' to put the module
name itself safely within the `(nwv)' namespace, where it's unlikely to
collide.  The module provides a few abstract data types, the short names
of which might be `client', `request', and `response'.  To reduce the
likelihood of collisions in the global namespace, I name my public
variables prefixed with `httpclient-' or `nwv-httpclient-' or something
more Draconian.  Even assuming a relatively short and risky prefix of
`httpclient-', that still seems to mean that users of the module end up
with verbose code like

    (use-modules (nwv httpclient))
    ...
       (let ((response (make-httpclient-response)))
          ...

          (let ((length (httpclient-response:content-length-header response)))
             ...
    
             (set! (httpclient-request:if-modified-since-header request)
                   some-timestamp)

even before they've expressed much.

-- 
                                          Neil W. Van Dyke <address@hidden>
                                          http://www.neilvandyke.org/