[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.



 | Date: Mon, 24 Jan 2005 20:18:03 -0800
 | From: Per Bothner <per@xxxxxxxxxxx>
 | 
 | Ok, change "f.scm" to "/fdir/f.scm" and "g.scm" to "/gdir/g.scm".
 | 
 | >  | Consider:
 | >  | /fdir/f.scm:
 | >  | (define (f) (source-vicinity))
 | >  | 
 | >  | /gdir/g.scm:
 | >  | (define v (f))
 | >  | 
 | >  | Top-level:
 | >  | (load "/fdir/f.scm")
 | >  | (load "/gdir/g.scm")
 | 
 | Ok, should v return "/fdir/" or "/gdir/".

(define (f) (source-vicinity)) exposes whether source-vicinity is a
procedure or macro.  As a procedure it returns "/gdir/".  But that is
poor practice.  Experience using vicinities has been that putting the
(PROGRAM-VICINITY) expression in the argument to compile-time LOADs is
clear and sufficient.

 | ... 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.

Here is how I think INCLUDE should work with vicinities:

 special form: include (in-vicinity ... file)

     The file argument must be a string naming an existing file
     containing Scheme source code in the specified vicinity. The
     include special form splices the content of the specified source
     file.  This form can only appear where a define form is
     acceptable.

     Within the in-vicinity clause, (program-vicinity) is replaced by
     the vicinity of the file containing the include expression.

     For example:

 (include (in-vicinity (program-vicinity) "macros.scm"))

 (define (f lst)
   (include (in-vicinity (libarary-vicinity) "sort.scm"))
   (map sqrt (sort lst)))

 | 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.

The compiler must be aware of vicinities; it must know that fetching
the PROGRAM-VICINITY source file is from the source vicinity, and
loading the object file is from the corresponding compiled vicinity.