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
xxxxxx@bothner.com   http://per.bothner.com/