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.
Aubrey Jaffer wrote:
| [source-vicinity] 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.
s/line-numbers/source location/
| 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".
Ok, change "f.scm" to "/fdir/f.scm" and "g.scm" to "/gdir/g.scm".
| It should return "f.scm". Not what SRFI-59 intended.
Ok, should v return "/fdir/" or "/gdir/".
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.
Right. But consider (include-relative "path") which is a very useful form. It is possible/desirable to define that in terms of a source-vicinity primitive? It is *possible* using some kind of source-vicinity form, but perhaps not desirable. I brought up "source-vicinity" and "include-relative" not because I'm saying that they should be in srfi-59, but to point out a relatated/similar issue with "compile-time" vicinities. For a compilation-oriented environment I think load-vicinity may not be very appropriate. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/