On Apr 11, 7:43 am, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
> One more thing to clarify: can the file reference returned by ANCHORED
> or LIB-ANCHORED be overwritten by S" ?
The answer, I think, derives from the fact that in Forth-94, there is
no warranted portable assumption that an S" buffer exists ... S" on
the command line is not CORE. And it is permitted for INCLUDED to be
in the base image while the rest of the FILES wordset are provided as
source ...
HYPOTHETICAL-QUOTE
For the FILES wordset, ``BL PARSE 4:HFLIB.LIB/FILES.FS INCLUDED"
For the FILES-EXT wordsets, ``BL PARSE 4:HFLIB.LIB/FILESEXT.FS
INCLUDED"
UNQUOTE
.... is perfectly acceptable as "providing the FILES and FILE-
EXTENSIONS wordsets.
The purpose of LIB-ANCHORED is to provide a simple black box for
porting filesystem reference in source that was developed on one
system with one system of filesystem references onto another system.
Since "Big Forths" make more convenient development environments,
ANCHORED and LIB-ANCHORED have to have a particular eye toward porting
code developed for a "Big Forth" into a "Small Forth" environment.
And in a "Small Forth" environment, S" on the command line is not
CORE, so there may be no S" buffer in existence when and LIB-ANCHORED
are added to the system ... assuming the existing of LIB-ANCHORED,
that above might be in cross-platform (DOS and CP/M in this case) code
in the library referencing other library file,
BL PARSE hflib/files.fs LIB-ANCHORED INCLUDED
Now, in the hforth for DOS, that will probably just be
%hflibpath%\files.fs
.... with INCLUDED written (or re-written, as the case may be) to get
DOS environment macros when encountering the %name% ... while in a CP/
M compatible ZS-DOS system, with the option of of direct access
to .LIB files written into the INCLDUED added to the system, it would
be something like the above, with the default drive and user number
fetched from a VALUE available to the user.
So it may well be that S" does not exist in the dictionary until it
has been loaded from the LIB-ANCHORED filespace by a file that did a:
[UNDEFINED] S" [IF] ( ... define S" ) [THEN]
process. And since the definitions of ANCHORED and LIB-ANCHORED leave
the buffer opaque, there is no way to *ensure* that the three have a
shared buffer.
Therefore, since "maybe they do and maybe they don't" is a portability
headache, required because existing practice "in some cases does and
in some cases doesn't", in this case, where I'm going to be putting
these into Linux gforth and CP/M hForth and z80 Camel and C64
VolksForth for my own personal use, I'm going to start out avoiding
the problem all together and being explicit:
1. Yes, LIB-ANCHORED and ANCHORED may have a common absolute file
reference buffer. On small Forth systems, they are *likely* to have a
common absolute file reference buffer, to reduce the codespace
footprint of both the buffer and the words manipulating it (+); and
2. No, there is no sharing between the LIB-ANCHORED and ANCHORED
absolute file reference buffer and any buffer provided for a command-
line ``S"''.
_______
(+. e.g., where the string always has a common prefix for a particular
implementation, that prefix can be added when the buffer is created,
without requiring additional codespace devoted to the words for
stuffing the prefix into the buffer, and all manipulations of the
buffer in the support wordset offset by the length of the prefix.)
|
