This page is part of the web mail archives of SRFI 59 from before July 7th, 2015. The new archives for SRFI 59 contain all messages, not just those from before July 7th, 2015.
| 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. | | 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.