[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
| Date: Sun, 23 Jan 2005 23:08:44 -0800
| From: Per Bothner <per@xxxxxxxxxxx>
| > 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.
| (define (f) (source-vicinity))
| (define v (f))
| (load "f.scm")
| (load "g.scm")
| What is the value of v?
It is the pathname of the directory containing both "f.scm" and
| 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.