Is such usage portable?
m_l_g3
char ! parse hello, world! S" TYPE" EVALUATE
Is the above usage
a) portable
b) standard?
gforth prints "hello, world", so does Win32Forth.
The trick is that the text to print is in the input buffer, but the
word TYPE executes after changing the input source.
Bernd Paysan
It probably works since the input buffer still has to be there, since there
might be something after EVALUATE. You probably can't rely on that in a
standard program, but I would think it's fairly portable, even though.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
m_l_g3
char ! dup parse hello, world!rot parse type!evaluate
In this example, the EVALUATEd string is a substring of the current
input buffer.
(probably, this is one of the most untrivial hello-world
programs :-) )
dpANS94. txt reads:
:The address and length returned by SOURCE, the string returned
:by PARSE, and directly computed input-buffer addresses are
:valid only until the text interpreter does I/O to
:refill the input buffer or the input source is changed.
This means that
: X PARSE-WORD EVALUATE ;
is not allowed by the current standard either.
Probably EVALUATE should be an exception from the general rule.
Bernd Paysan:
Jonah Thomas
> In fact, the following is equally interesting:
>
> char ! dup parse hello, world!rot parse type!evaluate
>
> In this example, the EVALUATEd string is a substring of the current
> input buffer.
>
> (probably, this is one of the most untrivial hello-world
> programs :-) )
>
> dpANS94. txt reads:
> :The address and length returned by SOURCE, the string returned
> :by PARSE, and directly computed input-buffer addresses are
> :valid only until the text interpreter does I/O to
> :refill the input buffer or the input source is changed.
>
> This means that
> : X PARSE-WORD EVALUATE ;
> is not allowed by the current standard either.
What's going on here? When you change the input source, the
incompletely-parsed old source must be saved for later. Something in the
later input might do something like 0 >IN ! and then you have to be
ready to parse any part of the old input buffer.
char ! dup parse hello, world!rot parse type!evaluate 2 drop
After you do EVALUATE you have to restore the old source and finish
parsing, unless something about EVALUATE aborts that.
A standard Forth system has the right to save that source any way it
wants and restore it later. So knowing the address of a string in the
old input buffer may not help when you change the input buffer. The
string doesn't have to be there. It's even possible that the old input
buffer might get restored in a new location.
On the other hand, if you already have an input buffer in a particular
location, and you choose to EVALUATE a substring of it, the clearly
simplest way to do things is to leave the old buffer where it is. Save
it in a new location, restore it later? Extra work for no obvious
benefit.
So it looks to me like systems are allowed to make things difficult for
programmers who want to use the input buffer in any but the most
restricted ways, but usually they won't.
Anton Ertl
>m_l_g3 <m_l...@yahoo.com> wrote:
>> dpANS94. txt reads:
>> :The address and length returned by SOURCE, the string returned
>> :by PARSE, and directly computed input-buffer addresses are
>> :valid only until the text interpreter does I/O to
>> :refill the input buffer or the input source is changed.
>>
>> This means that
>> : X PARSE-WORD EVALUATE ;
>> is not allowed by the current standard either.
>
>What's going on here? When you change the input source, the
>incompletely-parsed old source must be saved for later. Something in the
>later input might do something like 0 >IN ! and then you have to be
>ready to parse any part of the old input buffer.
An implementation might reread the input buffer on restoring the input
source; I am not aware of anything in the standard that would require
the old contents of the input buffer to be available while there is a
different input source (but I have not looked for that).
Concerning EVALUATE, IIRC there is a test in John Hayes' test suite
that tests whether the input buffer for EVALUATE is in the original
position (i.e., whether we are interpreting the string passed to
EVALUATE, not some copy). Bernd Paysan asked about that (maybe even
in an RFI), and got the answer that a standard system must behave that
way; so at least for EVALUATE it is very likely that the system does
not change the old contents of the input buffer while EVALUATEing some
string.
BTW, Forth-94 does not have PARSE-WORD, and the Forth200x name is
PARSE-NAME.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Elizabeth D Rather
PARSE has returned an address. At the time, that was the input buffer.
EVALUATE changes the *designation* of the input buffer, but not the
content of the region that was previously the input buffer. In fact,
there is no reason why the EVALUATE in your phrase above couldn't be
followed by more commands in the original input buffer, which should
survive unchanged until it is refilled.
I can see there is some ambiguity here. You have certainly not done any
explicit I/O to "refill" the input buffer, but certainly the "input
source is changed". Theoretically, some implementation could move text
from wherever it is into some singular location it calls an "input
buffer", but the implementation of all systems I know of uses different
addresses, and only actually changes the memory space when I/O is done.
But, in fact, your whole line is in the original input buffer, and
EVALUATE is merely being asked to provide some special treatment to some
of it.
The words "refill" and "source" are significant, IMO, since they are
Forth words with specific standardized meanings. A plausible
interpretation of the text could substitute REFILL and SOURCE as
appropriate and come closer to the original intent, but I have no memory
of that discussion. But, in particular, if you think SOURCE rather than
"source", it means you're looking at the addr-len parameters and what
they describe, rather than the memory containing the string, which would
be less likely to change.
I don't know of a system that actually moves strings around for
EVALUATE, only for REFILL and (often) S". My guess is that the usage is
largely portable, though not strictly standard.
--
==================================================
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."
==================================================