Why the difference ("BL WORD")?

On Mar 31, 10:37*pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:
> Both ways of "printing the next word taken from input stream" seem equally
> valid, but some Forth-variants don't like that latter, "interactive one".

> Why?

Because they USE the WORD buffer in THEIR interpreter.

Think about the sequence BL WORD MysSelf FIND

BL WORD puts MySelf into the WORD buffer. Then an interpreter that
uses the WORD buffer puts FIND into the WORD buffer, and it finds FIND
instead of finding MySelf

If its used in compiled code, and that word is used in interpret mode,
the named of the word containing that code is put into the WORD
buffer, then the code executes, re-using the WORD buffer, and then
when the word is done, the next word is parsed into the WORD buffer.
The compiled code uses the WORD buffer when the interpreter is done
with it for the word being executed, and before the interpreter needs
it for the next word.

Noticed, that not every Forth accepts direct use of "BL WORD", I mean:

#v+
: test ( -- ) bl word count type ; ok
test abc abc ok

bl word abc count type abc ok
#v-

Both ways of "printing the next word taken from input stream" seem equally
valid, but some Forth-variants don't like that latter, "interactive one".
Why?
--
Forth is a preserver of health (Hippocrates)

Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes Re: Why the difference?

> Noticed, that not every Forth accepts direct use of "BL WORD", I mean:

> #v+
> : test ( -- ) bl word count type ; ok
> test abc abc ok

> bl word abc count type abc ok
> #v-

> Both ways of "printing the next word taken from input stream" seem equally
> valid, but some Forth-variants don't like that latter, "interactive one".
> Why?

FORTH> help WORD
WORD CORE
( char "ccc<char>" -- c-addr )
char is a single character delimiter. Parse characters ccc delimited by
char, ignoring leading delimiters. An ambiguous condition exists if the
length of the parsed string is greater than the implementation-defined
length of a counted string.
c-addr is the address of a transient region containing the parsed word
as a counted string. If the current input stream was empty or contained
no characters other than the delimiter, the resulting string has a zero
count. A space, not included in the count, follows the string.
Note: The requirement to follow the string with a space is obsolescent
and is included as a concession to existing programs that use CONVERT .
A standard program may not depend on the existence of the space.

The problem is caused by what "c-addr is the address of a transient region
containing the parsed word" means on a specific system. In conventional
systems *all* parsed words, even those parsed by the text interpreter itself,
are copied to this transient area. Therefore when TYPE executes, the string
in the transient area is not "abc," but "type".

In the text interpreter does not use WORD itself, or makes an exception for
WORD to circumvent exactly your problem.

-marcel

On 3/31/12 4:37 PM, Zbiggy wrote:
> Noticed, that not every Forth accepts direct use of "BL WORD", I mean:
>
> #v+
> : test ( -- ) bl word count type ; ok
> test abc abc ok
>
> bl word abc count type abc ok
> #v-
>
> Both ways of "printing the next word taken from input stream" seem equally
> valid, but some Forth-variants don't like that latter, "interactive one".
> Why?

As Marcel points out, traditional Forths use WORD to parse the input
stream for the text interpreter. It places the found string in a buffer
(which traditionally is at or near HERE). Therefore, when you type your
sequence of words, the interpreter will place each in turn in the *same*
buffer. For an application needing to have a private space, PARSE will
work much better for you, since it works with the string without moving
it to a system buffer. But, as you see, when you use WORD in a
definition everything is fine.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Elizabeth D. Rather wrote:
>
> For an application needing to have a private space, PARSE will work much
> better for you, since it works with the string without moving it to a
> system buffer. But, as you see, when you use WORD in a definition
> everything is fine.

PARSE-NAME would be better than PARSE, as this uses the same rules as the
interpreter for identifying the end of the name, i.e. whitespace rather
than just a space (BL).

--
Peter Knaggs

In comp.lang.forth, Elizabeth D. Rather wrote:

> when you type your sequence of words, the interpreter will place each
> in turn in the *same* buffer.

Kind of "clash between theory and `real life' ". Thanks.
--
Forth is a preserver of health (Hippocrates)

On Apr 1, 7:39*am, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com> wrote:
> In comp.lang.forth, Elizabeth D. Rather wrote:
>
> > when you type your sequence of words, the interpreter will place each
> > in turn in the *same* buffer.

> Kind of "clash between theory and `real life' ". Thanks.

The details of "the theory" ~ the Forth94 specification ~ are
specified to be what a broad range of implementations can guarantee,
so its only a minimum.

But its a minimum, not a maximum: an implementation is *permitted* to
support a WORD buffer that is left alone by the text interpreter.

So on a system using WORD in its text interpreter, COUNT will go there
before its counted and TYPE will go there before its typed, so:

BL WORD Hi! COUNT TYPE
>> TYPET

On a system making no use of the WORD buffer in its text interpreter:

BL WORD Hi! COUNT TYPE
>> Hi!

On a system using the buffer to store parsed text but only providing a
counted string for backward compatibility:

BL WORD Hi! COUNT TYPE
>> TYP

For portable code, assume its overwritten. For implementation-
dependent code on a system that does not overwrite it, go ahead and
use it in the text interpreter.

Op Sun, 01 Apr 2012 11:53:23 +0100 schreef Peter Knaggs:

> Elizabeth D. Rather wrote:
>>
>> For an application needing to have a private space, PARSE will work much
>> better for you, since it works with the string without moving it to a
>> system buffer. But, as you see, when you use WORD in a definition
>> everything is fine.
>
> PARSE-NAME would be better than PARSE, as this uses the same rules as the
> interpreter for identifying the end of the name, i.e. whitespace rather
> than just a space (BL).

More important, it skips leading SPACEs/whitespace, just like WORD does and
PARSE doesn't.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html