On Apr 11, 8:28 pm, Bruce McFarling <agil...@[EMAIL PROTECTED]
> wrote:
> 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" ?
>
[...]
> 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
>
1a. The buffer is transient, its addresses and contents may
become invalid after any of the conditions mentioned
in 3.3.3.6 Other transient regions.
> 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"''.
Personally I do not see any problem with that the S" buffer may not
exist. There is even no need to define a word for that buffer, it may
be just PAD /PAD +
I would prefer to assume that ANCHORED always rewrite the interpreted
S" buffer. These buffers are anyway transient, no problem if they are
*one* transient buffer.
So,
2a. In addition, the buffer may be invalidated after execution of
11.6.1.2165 S"
in interpretation state.
=== === ===
Well, I had to see
BL PARSE dir/myfile.f INCLUDED
in *your* code to understand that the interpreted S" is not really
needed...
And S" does not have the power of PARSE that BTW is CORE...
char ' parse this is an "advanced" file name.txt' r/w create-file
throw ok
dup char ' parse nothing special' rot write-line throw ok
close-file throw ok
..s <0> ok
bye
$ cat this\ is\ an\ \"advanced\"\ file\ name.txt
nothing special
$
|
