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

Re: "source"-vicinity

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

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/