[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
| (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
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.