On Apr 9, 5:37 pm, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
> On Apr 6, 6:34 pm, an...@[EMAIL PROTECTED]
(Anton Ertl)
> wrote:
>
> > Bruce McFarling <agil...@[EMAIL PROTECTED]
> writes:
> > >SF" ..." returns a string anchored in the directory of the source
file
>
> > That's certainly an approach that would avoid the whole prefix issue
> > completely. Another advantage is that it would do the anchoring at
> > the right place (in the file where the string sits, rather than in the
> > file where the string is used).
> ...
> > One disadvantage of F" (or SF") is that most Forth programmers seem to
> > prefer INCLUDE and REQUIRE over INCLUDED and REQUIRED, standards be
> > damned.
> Yes, exactly.
> So please provide non-parsing versions of SF" WF" LF"
> so that we would write ourselves
> : s-include parse-name src-anchored included ;
> : l-include parse-name lib-anchored included ;
> and would be able to write
> : w-include parse-name wrk-anchored included ;
> S" win32/process.fth" lib-anchored included
> it looks enough ugly to be... well... ahem... I want to say, it is the
> same style that we have in the standard.
Ok:
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.
In both cases, the relative file reference refers to a subdirectory
within the file reference by appending the character '/', with
ANCHORED or LIB-ANCHORED providing any translation required by
INCLUDED and/or REQUIRED.
|
