[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "source"-vicinity



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/