On Apr 11, 6:39 am, Bruce McFarling <agil...@[EMAIL PROTECTED]
> wrote:
> So, boiling down the two roadblocks to the solution that gets around
> the roadblock with the minimum impact on the rest of the system:
>
> ANCHORED ( ca1 u1 -- ca2 u2 )
> Translate the relative file reference in the string referred by
> ( ca1 u2 )
> into an absolute file reference.
>
> If executed from within a file script, the reference is relative to
> the location of that file script within the file system. If executed
> from the command line, the reference is relative to an implementation-
> defined location in the file system.
>
> The relative file reference consists of a file name and optional
> subdirectory prefix. Any subdirectory name in the subdirectory prefix
> concludes with the the subdirectory separator ``/''. The format of the
> absolute file reference is the implementation-defined format for use
> with the standard word INCLUDED.
>
> The absolute file reference returned by ANCHORED may be over-written
> by the next invocation of ANCHORED or LIB-ANCHORED.
>
> LIB-ANCHORED ( ca1 u1 -- ca2 u2 )
> Translate the relative file reference in the string referred by
> ( ca1 u2 )
> into an absolute file reference. The implementation provides a library
> search path, consisting of a sequence of one or more locations in the
> file system. LIB-ANCHORED searches for the first occurrence in the
> library search path of a file matching the relative file reference. If
> found, LIB-ANCHORED returns the absolute file reference to that file.
> If not found, LIB-ANCHORED returns the absolute file reference for the
> relative file reference within the first directory in the library
> search path.
>
> The absolute file reference returned by LIB-ANCHORED may be over-
> written by the next invocation of ANCHORED or LIB-ANCHORED.
This sounds good. And, by the way, no need for F".
One more thing to clarify: can the file reference returned by ANCHORED
or LIB-ANCHORED be overwritten by S" ? The first thing that comes to
my mind is to re-use the S" buffer so that, in fact, the returned
address and length may be the same as input address and length.
If we require that text in the ANCHORED buffer survives invocation of
S" , then ANCHORED cannot be a no-op, because it will have to copy the
text into another buffer even if it does no expansion.
MY PROPOSAL:
The absolute file reference returned by LIB-ANCHORED / ANCHORED
may be over- written by the next invocation of ANCHORED, or LIB-
ANCHORED, or S".
INFORMATIVE
In particular, when ANCHORED or LIB-ANCHORED receive a string in the
S" buffer,
it is allowed to perform the conversion in place.
> On Apr 9, 7:16 pm, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
>
> > I would like to have WRK-ANCHORED too, to make `pwd`-anchoring
> > explicit. Some systems may already have some built-in intellect, and
> > this sort of things is always difficult to hack-around.
Let me elaborate on this one.
Some systems may already have the ANCHORED/LIB-ANCHORED functionality
built into the word INCLUDED.
Nevertheless, sometimes it is desirable to CHANGE-DIRECTORY and do
something with the
files in the current directory.
for example,
S" test/foo.f" r/w create-file throw value fid
CHAR | PARSE : hi ." hello" cr ;| fid write-line throw
fid close-file throw
S" test/foo.f" WRK-ANCHORED INCLUDED
hi
For gforth,
: wrk-anchored ;
If there will be no single system where WRK-ANCHORED must be something
different, we probably do not need WRK-ANCHORED.
But let us assume that both the current directory and the library
contain the file crc.fth. Which one will be loaded by S" crc.fth"
INCLUDED ?
There's no such ambiguity for S" crc.fth" WRK-ANCHORED INCLUDED
So, the purpose of WRK-ANCHORED is to allow existing implementations,
whatever they already are doing with the file paths, be both compliant
to the new standard and compatible with their own previous versions.
|
