Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #10678 > unrolled thread

Why the difference ("BL WORD")?

Back to article view | Back to comp.lang.forth

Contents

  Why the difference ("BL WORD")? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-01 03:37 +0100
    Re: Why the difference? mhx@iae.nl (Marcel Hendrix) - 2012-04-01 08:40 +0200
    Re: Why the difference ("BL WORD")? "Elizabeth D. Rather" <erather@forth.com> - 2012-03-31 21:14 -1000
      Re: Why the difference ("BL WORD")? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-01 12:39 +0100
        Re: Why the difference ("BL WORD")? BruceMcF <agila61@netscape.net> - 2012-04-01 09:39 -0700
      Re: Why the difference ("BL WORD")? "Peter Knaggs" <pjk@bcs.org.uk> - 2012-04-01 11:53 +0100
        Re: Why the difference ("BL WORD")? Coos Haak <chforth@hccnet.nl> - 2012-04-02 00:37 +0200
    Re: Why the difference ("BL WORD")? BruceMcF <agila61@netscape.net> - 2012-03-31 19:37 -0700

#10678 — Why the difference ("BL 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)

[toc] | [next] | [standalone]

#10680 — Re: Why the difference?

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

[toc] | [prev] | [next] | [standalone]

#10681

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#10686

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)

[toc] | [prev] | [next] | [standalone]

#10770

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.

[toc] | [prev] | [next] | [standalone]

#10688

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

[toc] | [prev] | [next] | [standalone]

#10691

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 

[toc] | [prev] | [next] | [standalone]

#10766

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web