On Apr 9, 7:16 pm, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
> On Apr 10, 2:21 am, Bruce McFarling <agil...@[EMAIL PROTECTED]
> wrote:
> > ANCHORED ( ca1 u1 -- ca2 u2 )
> > translate the relative file reference given the string at ( ca1 u1 )
> > into an absolute file reference. If contained in a source file, the
> > file is relative to the source file currently being interpreted. If
> > given on the command line, the file is relative to an implementation
> > dependent position in the file hierarchy.
> > LIB-ANCHORED ( ca1 u1 -- ca2 u2 )
> > translate the relative file reference given the string at ( ca1 u1 )
> > into an absolute file reference to the first file in the library path
> > that matches the file reference. If there is no matching file, an
> > absolute file reference is returned that refers to the first directory
> > in the library path.
> That is, ANCHORED is relative to the file being loaded (and not the
> project directory), LIB-ANCHORED is somewhere in the library path, and
> no "anchored" means `pwd`-relative. Is my understanding correct?
Without "anchored" impies you have to know how the implementation does
things.
ANCHORED means that calling the original file ... that perhaps called
the file that called the file that called the file ... establishes the
basis for the relative file reference.
LIB-ANCHORED means that there is a persistent path (which could be
just a single directory, in a simpler system), and the whole point of
having the library is that it is exporting support files to
applications that want to call a library file, so while moving the
anchor around is outside the scope of the standard, its a not an
anchor that moves around a lot.
How to define WRK-ANCHORED
I guess that WRK-ANCHORED would be relative to wherever foo.fs lives
when you:
S" foobar.fs" INCLUDED
at that point. So
S" foo/bar.fs" WRK-ANCHORED INCLUDED would give the subdirectory foo
that resides in the same logical location as foobar.fs does.
> 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.
> Now, what about lifetime and releasing of the converted path strings?
> If I store the address and length into a 2VARIABLE, will the filename
> be available via that 2VARIABLE while the file loads?
Lifetime like interpreter S" ... I'd not insist on them being separate
from each other, so that ANCHORED LIB-ANCHORED and WRK-ANCHORED could
be portably implemented to share a common absolute file descriptor
buffer.
> 2variable filename
> : lib-include
> parse-name lib-anchored filename 2@[EMAIL PROTECTED]
2>R 2DUP filename 2! included
> 2R> filename 2!
> ;
> > In both cases, the relative file reference refers to a subdirectory
> > within the file reference
> Sorry, can you please re-phrase?
if the file reference includes a subdirectory, it leads with a
subdirectory name, and "/" is used as the subdirectory separator.
> > by appending the character '/', with
> > ANCHORED or LIB-ANCHORED providing any translation required by
> > INCLUDED and/or REQUIRED.
> Sorry, what translation you are talking about?
The input into ANCHORED or LIB-ACNHORED is basically a standard
network relative hierarchy descriptor. The ouptut is whatever the
implementation needs to do to it to work with it.
e.g,
[joe.nicl.servers]Panel.fs;2
for VAX. A DOS implementation may prefer to convert the subdirectory
separators to "\". A CP/M implementation may map subdirectories to
User numbers. Never mind what the C64 implementation will map it to.
> And as to '/' vs '\', IMO it would be good to allow both.
ANCHOR and LIB-ANCHORED would not impose any choice of separator on
INCLUDED or REQUIRED, it would only specify the format of the portable
file descriptor that it receives as input.
Best that the portable file descriptor is something in particular, and
the output of ANCHORED is in whatever form the local INCLUDED wants it
to be in.
|
