ANS' EVALUATE and related issues

6.1.1360 EVALUATE
"[...] Make the string described by 'c-addr' and 'u' both the input source
and input buffer, [...] "

Does that mean I can CMOVE the EVALUATE string to TIB? Or, must the
original string in it's original location be parsed? It says to make the
string *described* by ... It doesn't say the original string, in the
original location, must be used or parsed in place. Is that an acceptable
interpretation? Or, am I placing emphasis where it's not present? What is
the intent here? I.e., is it legitimate to copy the original string to
another buffer and process that secondary buffer? That's what I did,
copying it to TIB . That works - via INTERPRET calling WORD. Basically,
the EOL of the prior input is not detected when "0 >IN !" is set by
EVALUATE. So, INTERPRET continues parsing instead of return to QUIT when
EVALUATE is executed. Is using PAD as the secondary buffer acceptable too?


3.3.3.5 Input Buffers
"[...] A program shall not write into the input buffer. [...]"

Is EVALUATE considered to be a program? (No.)

EVALUATE is implemented as a colon definition and so are programs in
Forth... Well, I'm assuming that's a "no" - as in a program being user code
and not system code. Otherwise, the distinction is very blurred in Forth as
compared to other languages as to what constitutes a program.


3.3.3.5 Input Buffers
"[...] or a buffer specified by EVALUATE. In all cases, SOURCE returns the
beginning address and length in characters of the current input buffer."

Does that mean something must also set #TIB when EVALUATE is used? What
about setting SPAN ? The statement _only_ says SOURCE must work and not
necessarily SPAN or #TIB ... Setting either isn't specified in the
description for EVALUATE or ACCEPT either. My SOURCE returns TIB and #TIB.
My EXPECT sets SPAN. QUERY sets #TIB from SPAN (reworked recently for SPAN
instead of #TIB). Should my ACCEPT also set #TIB ? I.e., in order to be
consistent, or to just have #TIB set? Or, should SOURCE be rewritten to
return TIB and SPAN ? If so, should #TIB be _only_ set for QUERY then? My
WORD is TIB based. So, rewriting SOURCE to return a non-TIB buffer not
something I'm looking at currently. But, I'm interested in knowing if it
could become a future issue.


6.2.2125 REFILL
"[...] When the input source is a string from EVALUATE, return 'false' and
perform no other action."

If due to the implementation of EVALUATE , REFILL can never receive an input
source string from EVALUATE ... ? (Ignoring that...)


A.6.2.2040 QUERY
"The function QUERY may be performed with ACCEPT and EVALUATE."

If I (now) have ACCEPT and EVALUATE as well as a QUERY (TIB based), should I
rewrite QUERY to use ACCEPT and EVALUATE ? They both currently use TIB too
.... It seems, at least from my definitions, that QUERY was broken into
ACCEPT and EVALUATE, and reworked for a generic buffer. The issue I have -
which really isn't a problem yet - is that ACCEPT and EVALUATE can use _any_
buffer. However, the remainder of my parsing words are all TIB based, some
explicitly so, like WORD . The TIB based design required my EVALUATE to
copy into TIB instead of using a generic buffer. I'm not currently "seeing"
a problem with doing this, although I just implemented it. I think maybe at
the 'heart' of the issue of using ACCEPT and EVALUATE is what exactly is
setting the "input buffer" address for SOURCE to return: ACCEPT? EXPECT?
EVALUATE? ... Without something saving the address, I can't foresee WORD
being rewritten as non-TIB based.


I do not have PARSE and REFILL yet. But, PARSE seems to be a modified WORD
and REFILL seems to be a modified version of QUERY. That's where I'll start
with them, anyway. REFILL supporting multiple input source probably won't
be supported, at least right away, since my Forth only supports terminal
input - although I've modified it for minimal file input. That's not
exactly Forth compliant though, yet.


Rod Pemberton

On Jul 2, 7:46*pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:

> 6.1.1360 EVALUATE

> "[...] Make the string described by 'c-addr' and 'u' both the input source
> and input buffer, [...] "

> Does that mean I can CMOVE the EVALUATE string to TIB?

Remember that the EVALUATE string is allowed to be arbitrarily long,
and the terminal input buffer normally will not be.

Rather than making a terminal input buffer that is as large as the
largest possible EVALUATE buffer that could be ALLOTte or ALLOCATEd,
I'd suggest having a variable location that points to the current
input buffer and length, and pop the current contents and save them
(often on the return stack) before placing:
( ca u )

.... handed to EVALUATE into those variable location. Then replace the
values when the interpret word returns to EVALUATE.

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
>
> 6.1.1360 EVALUATE
> "[...] Make the string described by 'c-addr' and 'u' both the input source
> and input buffer, [...] "
>
> Does that mean I can CMOVE the EVALUATE string to TIB?

No, because

foo bar evaluate baz bonce

typed into the TIB must work.

> Or, must the original string in it's original location be parsed?
> It says to make the string *described* by ... It doesn't say the
> original string, in the original location, must be used or parsed in
> place. Is that an acceptable interpretation? Or, am I placing
> emphasis where it's not present? What is the intent here? I.e., is
> it legitimate to copy the original string to another buffer and
> process that secondary buffer?

Sure, use a buffer elsewhere as long as it doesn't overwrite anything
else.

> That's what I did, copying it to TIB . That works - via INTERPRET
> calling WORD. Basically, the EOL of the prior input is not detected
> when "0 >IN !" is set by EVALUATE. So, INTERPRET continues parsing
> instead of return to QUIT when EVALUATE is executed. Is using PAD
> as the secondary buffer acceptable too?

No. TIB belongs to the user.

> 3.3.3.5 Input Buffers
> "[...] or a buffer specified by EVALUATE. In all cases, SOURCE returns the
> beginning address and length in characters of the current input buffer."
>
> Does that mean something must also set #TIB when EVALUATE is used?

No. EVALUATE doesn't affect TIB.

> What about setting SPAN ?

No. SPAN is set by EXPECT , and not by EVALUATE .

> A.6.2.2040 QUERY
> "The function QUERY may be performed with ACCEPT and EVALUATE."
>
> If I (now) have ACCEPT and EVALUATE as well as a QUERY (TIB based),
> should I rewrite QUERY to use ACCEPT and EVALUATE ? They both
> currently use TIB too ... It seems, at least from my definitions,
> that QUERY was broken into ACCEPT and EVALUATE, and reworked for a
> generic buffer. The issue I have - which really isn't a problem yet
> - is that ACCEPT and EVALUATE can use _any_ buffer. However, the
> remainder of my parsing words are all TIB based, some explicitly so,
> like WORD .

I think you should just fix that. Get rid of the dependency on TIB of
your parsing words. It'll be a lot easier.

Andrew.

Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
>>
>> Is using PAD as the secondary buffer acceptable too?
>
> No. TIB belongs to the user.

Sorry, I meant to say: PAD belongs to the user.

Andrew.

"Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>
>6.1.1360 EVALUATE
>"[...] Make the string described by 'c-addr' and 'u' both the input source
>and input buffer, [...] "
>
>Does that mean I can CMOVE the EVALUATE string to TIB? Or, must the
>original string in it's original location be parsed?

<IIRC>There is a test in the Hayes test suite that checks that the
string is parsed in its original location. At one time Gforth copied
the string elsewhere and failed this test, and Bernd Paysan asked the
Forth-94 TC about this and got the answer that the string has to be
parsed in its original location.</IIRC>

>3.3.3.5 Input Buffers
>"[...] A program shall not write into the input buffer. [...]"
>
>Is EVALUATE considered to be a program? (No.)

No, it's part of the system. The standard describes the interface
between Forth programs and Forth systems. So when you read "a
program", this describes what standard Forth programs are allowed or
not allowed to do.

>3.3.3.5 Input Buffers
>"[...] or a buffer specified by EVALUATE. In all cases, SOURCE returns the
>beginning address and length in characters of the current input buffer."
>
>Does that mean something must also set #TIB when EVALUATE is used?

#TIB is for the *terminal* input buffer, not for EVALUATE, LOAD, or
INCLUDED.

> What
>about setting SPAN ?

You do not use EXPECT in EVALUATE (or anywhere else in the text
interpreter).

>Should my ACCEPT also set #TIB ?

No.

>Or, should SOURCE be rewritten to
>return TIB and SPAN ?

If the input source is the terminal, SOURCE should return the same as
(if you have them) TIB #TIB @.

>A.6.2.2040 QUERY
>"The function QUERY may be performed with ACCEPT and EVALUATE."
>
>If I (now) have ACCEPT and EVALUATE as well as a QUERY (TIB based), should I
>rewrite QUERY to use ACCEPT and EVALUATE ?

Your decision. If you have a working QUERY, I would leave it alone.
It's obsolescent anyway.

- 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 2012: http://www.euroforth.org/ef12/

On Jul 3, 12:46*am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> 6.1.1360 EVALUATE
> "[...] Make the string described by 'c-addr' and 'u' both the input source
> and input buffer, [...] "
>
> Does that mean I can CMOVE the EVALUATE string to TIB? *Or, must the
> original string in it's original location be parsed? *It says to make the
> string *described* by ... *It doesn't say the original string, in the
> original location, must be used or parsed in place. *Is that an acceptable
> interpretation? *Or, am I placing emphasis where it's not present? *What is
> the intent here? *I.e., is it legitimate to copy the original string to
> another buffer and process that secondary buffer? *That's what I did,
> copying it to TIB . *That works - via INTERPRET calling WORD. *Basically,
> the EOL of the prior input is not detected when "0 >IN !" is set by
> EVALUATE. *So, INTERPRET continues parsing instead of return to QUIT when
> EVALUATE is executed. *Is using PAD as the secondary buffer acceptable too?
>
> 3.3.3.5 Input Buffers
> "[...] A program shall not write into the input buffer. [...]"
>
> Is EVALUATE considered to be a program? *(No.)
>
> EVALUATE is implemented as a colon definition and so are programs in
> Forth... *Well, I'm assuming that's a "no" - as in a program being usercode
> and not system code. *Otherwise, the distinction is very blurred in Forth as
> compared to other languages as to what constitutes a program.
>
> 3.3.3.5 Input Buffers
> "[...] or a buffer specified by EVALUATE. *In all cases, SOURCE returnsthe
> beginning address and length in characters of the current input buffer."
>
> Does that mean something must also set #TIB when EVALUATE is used? *What
> about setting SPAN ? *The statement _only_ says SOURCE must work and not
> necessarily SPAN or #TIB ... *Setting either isn't specified in the
> description for EVALUATE or ACCEPT either. *My SOURCE returns TIB and #TIB.
> My EXPECT sets SPAN. *QUERY sets #TIB from SPAN (reworked recently for SPAN
> instead of #TIB). *Should my ACCEPT also set #TIB ? *I.e., in order to be
> consistent, or to just have #TIB set? *Or, should SOURCE be rewritten to
> return TIB and SPAN ? *If so, should #TIB be _only_ set for QUERY then?*My
> WORD is TIB based. *So, rewriting SOURCE to return a non-TIB buffer not
> something I'm looking at currently. *But, I'm interested in knowing if it
> could become a future issue.
>
> 6.2.2125 REFILL
> "[...] When the input source is a string from EVALUATE, return 'false' and
> perform no other action."
>
> If due to the implementation of EVALUATE , REFILL can never receive an input
> source string from EVALUATE ... ? *(Ignoring that...)
>
> A.6.2.2040 QUERY
> "The function QUERY may be performed with ACCEPT and EVALUATE."
>
> If I (now) have ACCEPT and EVALUATE as well as a QUERY (TIB based), should I
> rewrite QUERY to use ACCEPT and EVALUATE ? *They both currently use TIBtoo
> ... *It seems, at least from my definitions, that QUERY was broken into
> ACCEPT and EVALUATE, and reworked for a generic buffer. *The issue I have -
> which really isn't a problem yet - is that ACCEPT and EVALUATE can use _any_
> buffer. *However, the remainder of my parsing words are all TIB based, some
> explicitly so, like WORD . *The TIB based design required my EVALUATE to
> copy into TIB instead of using a generic buffer. *I'm not currently "seeing"
> a problem with doing this, although I just implemented it. *I think maybe at
> the 'heart' of the issue of using ACCEPT and EVALUATE is what exactly is
> setting the "input buffer" address for SOURCE to return: ACCEPT? EXPECT?
> EVALUATE? ... *Without something saving the address, I can't foresee WORD
> being rewritten as non-TIB based.
>
> I do not have PARSE and REFILL yet. *But, PARSE seems to be a modified WORD
> and REFILL seems to be a modified version of QUERY. *That's where I'll start
> with them, anyway. *REFILL supporting multiple input source probably won't
> be supported, at least right away, since my Forth only supports terminal
> input - although I've modified it for minimal file input. *That's not
> exactly Forth compliant though, yet.
>
> Rod Pemberton

I interpret it as the string at c-addr u *becomes* the buffer. You
need to preserve TIB because there may be further text after the
EVALUATE:

TOM DICK EVAULATE HARRY

In my system, (from memory) EVALUATE would be something (never tried
it) like:

: EVALUATE ( c-addr u --)
TIB @ >R \ save address of TIB
#TIB @ >R \ save length of TIB
>IN @ >R \ save >IN

#TIB ! \ u --> #TIB
TIB ! \ c-addr --> TIB
>IN 0! \ 0 --> >IN

INTERPRET

R> >IN !
R> #TIB !
R> TIB !
;

I think it would be something like that on my system, which is a
Forth-83 system.

There might be a way to do it without calling another instance of the
interpreter, but it seems a neat enough solution (at least, it does
for my system).

....EVALUATE is implemented as a colon definition and so are programs
in
Forth... Well, I'm assuming that's a "no" - as in a program being
user code
and not system code. Otherwise, the distinction is very blurred in
Forth as
compared to other languages as to what constitutes a program. ...


I think that's right. The distinction is blurred. Forth consists of a
'lexicon' of words, which, when executed together in the correct
order, constitute your program!

Or to put it another way, Words are small, independant 'programs'. You
feed them parameters via the stack (wherever possible/sensible) and
they leave results on the stack. "Programs" are an organic collection
of references to these words. Words stand on the shoulders of other
words (factoring) to 'grow' your program.

In article <eb72d3eb-75e1-44ca-9f5c-89d25e657eea@k5g2000vbf.googlegroups.com>,
BruceMcF <agila61@netscape.net> wrote:
>On Jul 2, 7:46=A0pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
>wrote:
>
>> 6.1.1360 EVALUATE
>
>> "[...] Make the string described by 'c-addr' and 'u' both the input sourc=
>e
>> and input buffer, [...] "
>
>> Does that mean I can CMOVE the EVALUATE string to TIB?
>
>Remember that the EVALUATE string is allowed to be arbitrarily long,
>and the terminal input buffer normally will not be.

: INCLUDED 'GET-FILE CATCH THROW EVALUATE ;

>
>Rather than making a terminal input buffer that is as large as the
>largest possible EVALUATE buffer that could be ALLOTte or ALLOCATEd,
>I'd suggest having a variable location that points to the current
>input buffer and length, and pop the current contents and save them
>(often on the return stack) before placing:
> ( ca u )
>
>... handed to EVALUATE into those variable location. Then replace the
>values when the interpret word returns to EVALUATE.


Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>: INCLUDED 'GET-FILE CATCH THROW EVALUATE ;

The problem here is that REFILL works differently in INCLUDED than in
EVALUATE. If EVALUATE presents line per line to SOURCE and REFILL
switches to the next line, this REFILL does not comply with the
standard. If, OTOH, the content of the file appears all as one line
to SOURCE, the resulting INCLUDED will not behave as specified for
INCLUDED (e.g., "0 PARSE" will have a different effect).

Another, probably smaller, problem is that SOURCE-ID produces the
wrong value.

- 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 2012: http://www.euroforth.org/ef12/

On 7/3/12 12:53 AM, Mark Wills wrote:
> ...EVALUATE is implemented as a colon definition and so are programs
> in
> Forth... Well, I'm assuming that's a "no" - as in a program being
> user code
> and not system code. Otherwise, the distinction is very blurred in
> Forth as
> compared to other languages as to what constitutes a program. ...
>
>
> I think that's right. The distinction is blurred. Forth consists of a
> 'lexicon' of words, which, when executed together in the correct
> order, constitute your program!
>
> Or to put it another way, Words are small, independant 'programs'. You
> feed them parameters via the stack (wherever possible/sensible) and
> they leave results on the stack. "Programs" are an organic collection
> of references to these words. Words stand on the shoulders of other
> words (factoring) to 'grow' your program.

All true in general usage, but ANS Forth uses "system" and "program" as
technical terms with a very specific meaning. The Introduction to
Forth94 states,

"This Standard specifies an interface between a Forth System and a Forth
Program by defining the words provided by a Standard System."

That is, a "system" is what is provided, that must contain at least the
CORE wordset and behave as described, and a "program" is whatever a user
writes in Forth that runs on a Forth System. In this context, EVALUATE
is part of a "system", regardless of how it's written.

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

On 7/2/12 1:46 PM, Rod Pemberton wrote:
> 6.1.1360 EVALUATE
> "[...] Make the string described by 'c-addr' and 'u' both the input source
> and input buffer, [...] "
>
> Does that mean I can CMOVE the EVALUATE string to TIB? Or, must the
> original string in it's original location be parsed? It says to make the
> string *described* by ... It doesn't say the original string, in the
> original location, must be used or parsed in place. Is that an acceptable
> interpretation? Or, am I placing emphasis where it's not present? What is
> the intent here? I.e., is it legitimate to copy the original string to
> another buffer and process that secondary buffer? That's what I did,
> copying it to TIB .

It's up to you whether you move it or not, but you may *not* move it to
TIB, since you aren't entitled to write to TIB (to do so would destroy
its prior contents, as others have pointed out). Most implementations do
not move the string.

> That works - via INTERPRET calling WORD. Basically,
> the EOL of the prior input is not detected when "0 >IN !" is set by
> EVALUATE. So, INTERPRET continues parsing instead of return to QUIT when
> EVALUATE is executed. Is using PAD as the secondary buffer acceptable too?

No, PAD is a user resource.

> 3.3.3.5 Input Buffers
> "[...] A program shall not write into the input buffer. [...]"
>
> Is EVALUATE considered to be a program? (No.)
>
> EVALUATE is implemented as a colon definition and so are programs in
> Forth... Well, I'm assuming that's a "no" - as in a program being user code
> and not system code. Otherwise, the distinction is very blurred in Forth as
> compared to other languages as to what constitutes a program.

As I noted elsewhere, "system" and "program" have very specific meanings
in ANS Forth.

> 3.3.3.5 Input Buffers
> "[...] or a buffer specified by EVALUATE. In all cases, SOURCE returns the
> beginning address and length in characters of the current input buffer."
>
> Does that mean something must also set #TIB when EVALUATE is used? What
> about setting SPAN ? The statement _only_ says SOURCE must work and not
> necessarily SPAN or #TIB ... Setting either isn't specified in the
> description for EVALUATE or ACCEPT either. My SOURCE returns TIB and #TIB.
> My EXPECT sets SPAN. QUERY sets #TIB from SPAN (reworked recently for SPAN
> instead of #TIB). Should my ACCEPT also set #TIB ? I.e., in order to be
> consistent, or to just have #TIB set? Or, should SOURCE be rewritten to
> return TIB and SPAN ? If so, should #TIB be _only_ set for QUERY then? My
> WORD is TIB based. So, rewriting SOURCE to return a non-TIB buffer not
> something I'm looking at currently. But, I'm interested in knowing if it
> could become a future issue.

There are a number of potential "input buffers": terminal input, files,
blocks, and EVALUATE strings. It's really necessary for INTERPRET to be
able to work on all of them, interchangeably and in any order.

Standard Forth attempts to hide as many of these implementation details
as possible by making SOURCE return the parameters of the current input
stream (whatever it is). SAVE-INPUT and RESTORE-INPUT support nesting
input sources. The intent is that if you (for example) type a series of
commands including words to be executed directly, a request to INCLUDE a
file, and an EVALUATE string & command (which might also appear anywhere
in a file) it will all work seamlessly.

> 6.2.2125 REFILL
> "[...] When the input source is a string from EVALUATE, return 'false' and
> perform no other action."
>
> If due to the implementation of EVALUATE , REFILL can never receive an input
> source string from EVALUATE ... ? (Ignoring that...)
>
>
> A.6.2.2040 QUERY
> "The function QUERY may be performed with ACCEPT and EVALUATE."
>
> If I (now) have ACCEPT and EVALUATE as well as a QUERY (TIB based), should I
> rewrite QUERY to use ACCEPT and EVALUATE ? They both currently use TIB too
> ... It seems, at least from my definitions, that QUERY was broken into
> ACCEPT and EVALUATE, and reworked for a generic buffer. The issue I have -
> which really isn't a problem yet - is that ACCEPT and EVALUATE can use _any_
> buffer. However, the remainder of my parsing words are all TIB based, some
> explicitly so, like WORD . The TIB based design required my EVALUATE to
> copy into TIB instead of using a generic buffer. I'm not currently "seeing"
> a problem with doing this, although I just implemented it.

The problem is that you may have destroyed the previous content of TIB,
which may include text yet to be interpreted. It's a lot easier to save
and restore your interpreter parameters (SOURCE) than to try to save and
restore the contents of a buffer whose length must accommodate the
longest string you can interpret.

> I think maybe at
> the 'heart' of the issue of using ACCEPT and EVALUATE is what exactly is
> setting the "input buffer" address for SOURCE to return: ACCEPT? EXPECT?
> EVALUATE? ... Without something saving the address, I can't foresee WORD
> being rewritten as non-TIB based.

ACCEPT gets input from the terminal (forget EXPECT, it's obsolete).
EVALUATE gets it from a string, which may be anywhere: you're given its
address and length. WORD uses the input stream parameters, which might
or might not have anything to do with TIB.

> I do not have PARSE and REFILL yet. But, PARSE seems to be a modified WORD
> and REFILL seems to be a modified version of QUERY. That's where I'll start
> with them, anyway. REFILL supporting multiple input source probably won't
> be supported, at least right away, since my Forth only supports terminal
> input - although I've modified it for minimal file input. That's not
> exactly Forth compliant though, yet.

PARSE is an alternative to WORD that is decoupled from the input stream.
REFILL is useful not only in managing terminal input but also in reading
successive lines when you're interpreting successive lines from a file.

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

On 7/3/12 9:19 AM, Elizabeth D. Rather wrote:
> PARSE is an alternative to WORD that is decoupled from the input stream.
> REFILL is useful not only in managing terminal input but also in reading
> successive lines when you're interpreting successive lines from a file.

Sorry, that wasn't phrased very well. Both WORD and PARSE use the input
stream as defined by SOURCE. The major difference is that WORD moves the
string somewhere (leaving it as a counted string) and PARSE doesn't.
Also, WORD skips leading delimiters, whereas PARSE doesn't.

WORD is the traditional parsing word, and the intent of moving the
string is the assumption that most parsing will be followed by a
dictionary search, and if the word isn't found it may be intended to be
added to the dictionary, so the string is moved to the top of the
dictionary in preparation for this. It's an attempt to optimize compilation.

Nowadays implementations vary a lot, and this is often not an
appropriate optimization.

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

On Jul 2, 7:46*pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> 6.1.1360 EVALUATE
> "[...] Make the string described by 'c-addr' and 'u' both the input source
> and input buffer, [...] "
>
> Does that mean I can CMOVE the EVALUATE string to TIB? *Or, must the
> original string in it's original location be parsed? *It says to make the
> string *described* by ... *It doesn't say the original string, in the
> original location, must be used or parsed in place. *Is that an acceptable
> interpretation? *Or, am I placing emphasis where it's not present? *What is
> the intent here? *I.e., is it legitimate to copy the original string to
> another buffer and process that secondary buffer? *That's what I did,
> copying it to TIB . *That works - via INTERPRET calling WORD. *Basically,
> the EOL of the prior input is not detected when "0 >IN !" is set by
> EVALUATE. *So, INTERPRET continues parsing instead of return to QUIT when
> EVALUATE is executed. *Is using PAD as the secondary buffer acceptable too?
>
> 3.3.3.5 Input Buffers
> "[...] A program shall not write into the input buffer. [...]"
>
> Is EVALUATE considered to be a program? *(No.)
>
> EVALUATE is implemented as a colon definition and so are programs in
> Forth... *Well, I'm assuming that's a "no" - as in a program being usercode
> and not system code. *Otherwise, the distinction is very blurred in Forth as
> compared to other languages as to what constitutes a program.
>
> 3.3.3.5 Input Buffers
> "[...] or a buffer specified by EVALUATE. *In all cases, SOURCE returnsthe
> beginning address and length in characters of the current input buffer."
>
> Does that mean something must also set #TIB when EVALUATE is used? *What
> about setting SPAN ? *The statement _only_ says SOURCE must work and not
> necessarily SPAN or #TIB ... *Setting either isn't specified in the
> description for EVALUATE or ACCEPT either. *My SOURCE returns TIB and #TIB.
> My EXPECT sets SPAN. *QUERY sets #TIB from SPAN (reworked recently for SPAN
> instead of #TIB). *Should my ACCEPT also set #TIB ? *I.e., in order to be
> consistent, or to just have #TIB set? *Or, should SOURCE be rewritten to
> return TIB and SPAN ? *If so, should #TIB be _only_ set for QUERY then?*My
> WORD is TIB based. *So, rewriting SOURCE to return a non-TIB buffer not
> something I'm looking at currently. *But, I'm interested in knowing if it
> could become a future issue.
>
> 6.2.2125 REFILL
> "[...] When the input source is a string from EVALUATE, return 'false' and
> perform no other action."
>
> If due to the implementation of EVALUATE , REFILL can never receive an input
> source string from EVALUATE ... ? *(Ignoring that...)
>
> A.6.2.2040 QUERY
> "The function QUERY may be performed with ACCEPT and EVALUATE."
>
> If I (now) have ACCEPT and EVALUATE as well as a QUERY (TIB based), should
> I rewrite QUERY to use ACCEPT and EVALUATE ? *They both currently use TIB
> too ... *It seems, at least from my definitions, that QUERY was broken into
> ACCEPT and EVALUATE, and reworked for a generic buffer. *The issue I have -
> which really isn't a problem yet - is that ACCEPT and EVALUATE can use
> _any_ buffer. *However, the remainder of my parsing words are all TIB
> based, some explicitly so, like WORD.

Your WORD shouldn't be specialized to the user input buffer (aka TIB)
~ an EVALUATE buffer is not the user entering commands and shouldn't
over-write the user input buffer (aka TIB) ~ and if it gets extended
to INCLUDE or LOAD then you'll want to be able to get the source from
a file and/or block buffer rather than from the user input buffer.

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:8qqdnSVPp7lH2G7SnZ2dnUVZ_gydnZ2d@supernews.co m...
> On 7/2/12 1:46 PM, Rod Pemberton wrote:
....

> > 6.1.1360 EVALUATE
> > "[...] Make the string described by 'c-addr' and 'u' both the input
> > source and input buffer, [...] "
> >
> > Does that mean I can CMOVE the EVALUATE string to TIB? Or,
> > must the original string in it's original location be parsed? It says
> > to make the string *described* by ... It doesn't say the original
> > string, in the original location, must be used or parsed in place. Is
> > that an acceptable interpretation? Or, am I placing emphasis where
> > it's not present? What is the intent here? I.e., is it legitimate to
> > copy the original string to another buffer and process that secondary
> > buffer? That's what I did, copying it to TIB .
>
> It's up to you whether you move it or not, [...]
>

So, you believe copying the input to EVALUATE is acceptable.

> [...] but you may *not* move it to TIB, since you aren't entitled
> to write to TIB

Uh... Why?

Does TIB qualify as "input buffer" according to ANS? I thought so. Unless
I misunderstood, the quote (below) states "programs" aren't allowed to write
to TIB, but "system" words, like EVALUATE, are allowed to write to TIB...
Moving up the ANS quote for reference:

> > 3.3.3.5 Input Buffers
> > "[...] A program shall not write into the input buffer. [...]"
....

> (to do so would destroy its prior contents, as others have pointed out).

Yes.

I'll check, but I'm fully confident it will corrupt anything after
EVALUATE if the input string is sufficiently long enough.

> Most implementations do not move the string.

Ok. Thanks.

> There are a number of potential "input buffers": terminal input, files,
> blocks, and EVALUATE strings. It's really necessary for INTERPRET to be
> able to work on all of them, interchangeably and in any order.

Yes, I've not implemented most of those "input buffers".


Rod Pemberton

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:e607e7b8-7f76-44ee-b72c-aad73ef00260@k5g2000vbf.googlegroups.com...
> On Jul 3, 12:46 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
....

> > 6.1.1360 EVALUATE
> > "[...] Make the string described by 'c-addr' and 'u' both the input
> > source and input buffer, [...] "
>
> > Does that mean I can CMOVE the EVALUATE string to TIB? Or, must the
> > original string in it's original location be parsed? It says to make the
> > string *described* by ... It doesn't say the original string, in the
> > original location, must be used or parsed in place.
>
> I interpret it as the string at c-addr u *becomes* the buffer.
>

I figured that was the basic meaning. But, obviously, one could understand
it differently, as I presented.

What a specification actually *requires* and what is *meant* can be two
different things. Part of the reason I asked was because the C
specification doesn't specify or require "parse in place" for it's parsing
procedures, although that's what's meant. However, if you *don't* implement
those C procedures by parsing the words in their original location, i.e.,
using an intermediate buffer, some C code breaks. I.e., some C programmers
assume or use that "feature". So, the C specification fails to capture all
of the required information necessary to correctly implement parsing
procedures. Historically, that was the way C's did it. So, I suspected ANS
Forth was the same way. Specifications are usually an abstraction, i.e.,
all the foundation is missing or intracacies are abstracted away.

> [example]
>
> I think it would be something like that on my system, which is a
> Forth-83 system.
>
> There might be a way to do it without calling another instance of the
> interpreter, but it seems a neat enough solution (at least, it does
> for my system).

You changed the address of TIB in your example... Is TIB a constant?

AIR, where TIB is implemented, TIB is always "constant" in the sense that it
doesn't need a @ (fetch), except for fig-Forth where it's a "variable"
because it needs a @ (fetch)... You're definately fetching TIB.

Ok, I did think about changing TIB. Since TIB is a constant, I didn't...

Since I have both #TIB and SPAN now, I began considering implementing
another word which would be like TIB but for use with SPAN so SOURCE
could be independent of TIB. That by itself won't fix the other words.


Rod Pemberton