| Date: Sun, 23 Jan 2005 23:08:44 -0800
 | From: Per Bothner <xxxxxx@bothner.com>
 |
 | > 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.
 |
 | That's not what srfi-59.html says:
 |    For a compiled system (with multiple files) this would be the
 |    directory where the object or executable files are.

Those ancillary resources get put in the same directory as (or a
subdirectory or peer of) where the compiled files go.  One of the
reasons why I called it program-vicinity rather than source-vicinity
is that many programs distribute compiled or otherwise processed code
instead of source.  Unix systems typically have program-vicinities
like /usr/lib/<program-name>/, /usr/share/<program-name>/,
/opt/<program-name>/, or /usr/local/lib/<program-name>/.

 | > 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?
 |
 | It can be regular syntax *iff* the Scheme reader annotates the
 | resulting forms with line-number information, in some way or other.

??  SRFI-59 does not mention line-numbers.

 | Some Schemes do - at least Chez Scheme, PLT Scheme, and Kawa.  Any
 | Scheme that can provide error diagnostics with a line-number needs
 | some way of doing this.
 |
 | > Must source-vicinity be distinct from program-vcinity?
 |
 | Perhaps not, depending on how it is defined.
 |
 | Consider:
 | f.scm:
 | (define (f) (source-vicinity))
 |
 | g.scm:
 | (define v (f))
 |
 | Top-level:
 | (load "f.scm")
 | (load "g.scm")
 |
 | What is the value of v?

It is the pathname of the directory containing both "f.scm" and
"g.scm".

 | It should return "f.scm".

Not what SRFI-59 intended.

In SLIB it is *load-pathname* which contains the currently loading
pathname; but this is not an advertised interface.

 | I do believe this is useful, for diagnostics.

What you describe seems to be the analog of ANSI-C __FILE__ and
__LINE__.  These macros are not referentially transparent, so
read-syntax would seem to be necessary to implement them in Scheme.