> This is an interesting idea.  It's a combinator library for building
> name-to-location mappings, and operates at a level about my proposed
> install-library-mapping!.

I think it's important to come up with a declarative DSL made of a
limited set of combinators instead of offering the full power of Scheme.
That way, it'll be easier to trade expressions and put them in metadata
files that may not be Scheme code. It'll enable a cottage industry of
tools to grow around the notation. And with less expressive power, it'll
be easier to make a notation where you can "mount" any tree as a subtree
into some other tree. So people can share fragments that can be re-used
verbatim.

Scheme implementations do have the full power of Scheme at the REPL, so
they should give users the freedom to create new combinators for the DSL
by writing arbitrary Scheme code. But at the DSL level, it would be best
to keep the surface syntax as simple as possible and come up with a
canonical set of combinators that are widely used.

TL;DR "Push power and sophistication out of the DSL into the Scheme code
that implements its combinators."

Another thing is that we often have to refer to libraries and the places
where we find them as strings, as Marc Feeley alluded to with the
github.com/foo/bar notation. Common Lisp has purpose-built filesystem
pathname objects, but it can create those by parsing pathnames from
strings. The opaque objects and the strings they come from are called
"pathnames" and "namestrings", respectively.

If our library DSL has the concept of a place, we should also have
namestrings for places. This need is made apparent when you consider
interoperability with existing customs. For example, there should be a
SCHEME_PATH environment variable that looks like Unix or Windows PATH,
and gives a Scheme implementation's library path on startup.

So SCHEME_PATH=/foo/bar:/baz would be parsed into:

(union "/foo/bar" "/baz")

where "/foo/bar" and "/baz" are namestrings.

The Scheme implementation would have some (user-configurable) hook that
says how to parse namestrings into <node>s. For example, the default
hook would recognize /foo as a Unix path and parse it into (directory
"/foo"). So the above would be a shorthand for:

(union (directory "/foo/bar")
        (directory "/baz"))

You could add a namestring parser for URLs and archives, so:

SCHEME_PATH=
http://snow-fort.org/pkg/foo-1.2.3.tgz;
/usr/local/lib/fantastic-scheme

would be a shorthand for:

(union "http://snow-fort.org/pkg/foo-1.2.3.tgz"
        "/usr/local/lib/fantastic-scheme")

which in turn would be a shorthand for something like:

(union (archive (http "snow-fort.org/pkg/foo-1.2.3.tgz"))
        (directory "/usr/local/lib/fantastic-scheme"))

We could extend the grammar in the previous name such that a <node> that
is a string would be parsed as a namestring.

The possibilities are endless, but hopefully the genera idea starts to
be apparent. With a few well chosen combinators, which can be parsed
from namestrings for better interoperability in string-based,
hierarchy-challenged contexts, we can have something expressive yet simple.