| Date: Sun, 02 Jan 2005 14:49:11 -0800
 | From: Per Bothner <xxxxxx@bothner.com>
 |
 | Some Schemes support compile-time source inclusion.  Chez Scheme
 | has "include", which I've recently added to Kawa.  Often you want
 | to include a file relative to the current file, which suggests an
 | include-relative syntax form.  To implement include-relative you'd
 | need a "source-vicnity" concept.  This of course would have to be a
 | macro, rather than a function.  But there is a complication: the
 | source we want to be relative to is not the implementation of
 | include-relative, where the source-vicinity form appears, but the
 | source containing the include-relative form.

I tried to design vicinities to work either as syntax or procedures.
Library-vicinity, implementation-vicinity, user-vicinity, and
home-vicinity are static; their behavior works either as syntax or
procedures.

Program-vicinity is typically used to load pieces of programs at what
in Common-Lisp is called compile-time.  But program-vicinity is also
used at run-time for locating the software license or help text, for
instance.

Top level definition with the value of (program-vicinity) captures
that vicinity for later use.  We would like to be able to call
program-vicinity at any point in the code and have it return the same
value as a top-level-captured vicinity.  But to have it evaluated
during the load would require it be a read-syntax, wouldn't it?

Another way to do this would be to redefine DEFINE to wrap every
top-level definition thus:

(define <identifier>
  (let ((program-vicinity (lambda () "/program/vicinity/")))
    ...))

Are R5RS macros capable of this?

 | So this suggests a "source-vicinty" form that takes syntax form.
 | Chez Scheme and PLT (and probably others) have a way to extract
 | these using "source annotations"; Kawa also has a mechanism.

Must source-vicinity be distinct from program-vcinity?

 | Unfortunately, many Scheme implementations may be unable to extract
 | the "source-vicinity" of a form, but a (source-relative PATH) form
 | may be possible to standardize.  At least it should be possible to
 | standardize include and include-relative - but probably in a
 | different SRFI.