>From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
Subject: Re: program-vicinity
Date: Sun, 23 Jan 2005 21:58:27 -0500 (EST)

>  | Date: Sun, 09 Jan 2005 22:18:40 -1000 (HST)
>  | From: Shiro Kawai <xxxxxx@lava.net>
>  |
>  | The return value of program-vicinity is currently undefined when
>  | there's no file being loaded.  Is there any reason for that?
>
> Which directory should be the value of program-vicinity be when no
> file is being loaded?  If it is the directory containing the file
> containing the call to program-vicinity, then every procedure which
> contains a call to program-vicinity must carry a source-file
> annotation.
>
> Which directory should it be when the call to program-vicinity was
> introduced by a macro?
>
> Which directory should it be when called by a procedure defined using
> eval or pasted into an interactive top-level?

That's my point.  The implementation may pick some directory
which the implementator thinks sensible, or returns #f to
tell there's no file being loaded, or returns some random
value.   Then how can I reliablely use the return value of
program-vicinity?  Whether the piece of code including a call to
program-vicinity is loaded, or copy&pasted into interactive toplevel,
or executed as a part of code linked into the stand-alone executable,
may be out of knowledge of the programmer who writes the code.

However, it's no more 'undefined' than "somthing is an error" anyway,
so in practice it may not be a problem as far as each implementation
defines such boundary cases.   If that's your intention, I take back
my comment.

--shiro