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

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

Replacing QUERY

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

Contents

  Replacing QUERY anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-02 17:05 +0000
    Re: Replacing QUERY "HAA" <someone@microsoft.com> - 2016-05-06 18:27 +1000
      Re: Replacing QUERY anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-06 14:26 +0000
        Re: Replacing QUERY Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-06 15:29 +0000
          Re: Replacing QUERY anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-06 16:18 +0000
            Re: Replacing QUERY "HAA" <someone@microsoft.com> - 2016-05-07 11:55 +1000
              Re: Replacing QUERY anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-07 12:34 +0000
    Re: Replacing QUERY Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-06 19:35 -0400
      Re: Replacing QUERY Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-07 11:49 +0000
        Re: Replacing QUERY anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-07 12:17 +0000
        Re: Replacing QUERY "Elizabeth D. Rather" <erather@forth.com> - 2016-05-07 08:45 -1000
          Re: Replacing QUERY Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-08 00:37 +0000
          Re: Replacing QUERY anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-08 14:05 +0000
      Re: Replacing QUERY anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-07 12:39 +0000

#46871 — Replacing QUERY

The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
function of QUERY as I understand the specification of QUERY.  The
specification says:

|6.2.2040 QUERY  CORE EXT ( -- )
|
|Make the user input device the input source. Receive input into the
|terminal input buffer, replacing any previous contents. Make the
|result, whose address is returned by TIB, the input buffer. Set >IN to
|zero.

It seems that REFILL is a more likely replacement for QUERY in most
cases.  It does not change the input source, but neither does ACCEPT,
and EVALUATE only changes it temporarily and not to the user input
device.  Apart from that, QUERY seems to be a
user-input-device-specific version of REFILL, and therefore REFILL is
more likely replacement for QUERY in many cases.

What do you think?

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [next] | [standalone]

#46930

Anton Ertl wrote:
> The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
> with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
> function of QUERY as I understand the specification of QUERY.  The
> specification says:
>
> |6.2.2040 QUERY  CORE EXT ( -- )
> |
> |Make the user input device the input source. Receive input into the
> |terminal input buffer, replacing any previous contents. Make the
> |result, whose address is returned by TIB, the input buffer. Set >IN to
> |zero.
>
> It seems that REFILL is a more likely replacement for QUERY in most
> cases.  It does not change the input source, but neither does ACCEPT,
> and EVALUATE only changes it temporarily and not to the user input
> device.  Apart from that, QUERY seems to be a
> user-input-device-specific version of REFILL, and therefore REFILL is
> more likely replacement for QUERY in many cases.
>
> What do you think?
>
> - anton

But what if you don't have REFILL ?  That I think was the point of the
suggestion in A.6.2.2040.  A.6.2.2125 says REFILL (if you have it) is
the preferred replacement for QUERY.

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

#46935

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
>> with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
>> function of QUERY as I understand the specification of QUERY.  The
>> specification says:
>>
>> |6.2.2040 QUERY  CORE EXT ( -- )
>> |
>> |Make the user input device the input source. Receive input into the
>> |terminal input buffer, replacing any previous contents. Make the
>> |result, whose address is returned by TIB, the input buffer. Set >IN to
>> |zero.
>>
>> It seems that REFILL is a more likely replacement for QUERY in most
>> cases.  It does not change the input source, but neither does ACCEPT,
>> and EVALUATE only changes it temporarily and not to the user input
>> device.  Apart from that, QUERY seems to be a
>> user-input-device-specific version of REFILL, and therefore REFILL is
>> more likely replacement for QUERY in many cases.
>>
>> What do you think?
>>
>> - anton
>
>But what if you don't have REFILL ?  That I think was the point of the
>suggestion in A.6.2.2040.  A.6.2.2125 says REFILL (if you have it) is
>the preferred replacement for QUERY.

Thanks for pointing that out.

As for not having REFILL: Both QUERY and REFILL are CORE EXT words, so
there was no guarantee that QUERY is present even if it had not been
obsolescent.  In practice, Forth-94 systems provide most standard
words, particularly, REFILL.  I just tested SwiftForth, VFX, iforth
2.1, bigForth 2.3.1, and gforth, and they all have REFILL.  After all,
it's needed in the implementation of a Forth system.

- 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 2016: http://www.euroforth.org/ef16/

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

#46937

On 2016-05-06, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> "HAA" <someone@microsoft.com> writes:
>>Anton Ertl wrote:
>>> The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
>>> with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
>>> function of QUERY as I understand the specification of QUERY.  The
>>> specification says:
>>>
>>> |6.2.2040 QUERY  CORE EXT ( -- )
>>> |
>>> |Make the user input device the input source. Receive input into the
>>> |terminal input buffer, replacing any previous contents. Make the
>>> |result, whose address is returned by TIB, the input buffer. Set >IN to
>>> |zero.
>>>
>>> It seems that REFILL is a more likely replacement for QUERY in most
>>> cases.  It does not change the input source, but neither does ACCEPT,
>>> and EVALUATE only changes it temporarily and not to the user input
>>> device.  Apart from that, QUERY seems to be a
>>> user-input-device-specific version of REFILL, and therefore REFILL is
>>> more likely replacement for QUERY in many cases.
>>>
>>> What do you think?
>>>
>>> - anton
>>
>>But what if you don't have REFILL ?  That I think was the point of the
>>suggestion in A.6.2.2040.  A.6.2.2125 says REFILL (if you have it) is
>>the preferred replacement for QUERY.
>
> Thanks for pointing that out.
>
> As for not having REFILL: Both QUERY and REFILL are CORE EXT words, so
> there was no guarantee that QUERY is present even if it had not been
> obsolescent.  In practice, Forth-94 systems provide most standard
> words, particularly, REFILL.  I just tested SwiftForth, VFX, iforth
> 2.1, bigForth 2.3.1, and gforth, and they all have REFILL.  After all,
> it's needed in the implementation of a Forth system.

REFILL is not needed to implement a Forth.
From all standard Forth words only \ is line-endings aware, so why
should INCLUDED be?
I didn't have a REFILL to implement ciforth.

In accordance with the least surprise principle you can load a REFILL by
    WANT REFILL
It sets the parse pointer after the end of the current line.
For console input its means that the remainder of the current line is
ignored.

The QUIT loop uses (ACCEPT) to get an address length for the
next input line. (ACCEPT) copies a line from the buffered input
into TIB. It does always this same thing, so (ACCEPT) can be
used while interpreting a script or in a turnkey program
to get user input. It plays nice with standard in, so the
script can get its input from a file in turn.

>
> - anton

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

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

#46940

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes:
>On 2016-05-06, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> In practice, Forth-94 systems provide most standard
>> words, particularly, REFILL.  I just tested SwiftForth, VFX, iforth
>> 2.1, bigForth 2.3.1, and gforth, and they all have REFILL.  After all,
>> it's needed in the implementation of a Forth system.
>
>REFILL is not needed to implement a Forth.

Sure you can have REFILL-like functionality that's not factored into a
word called REFILL, it just does not make much sense.

>From all standard Forth words only \ is line-endings aware, so why
>should INCLUDED be?

From the definition of INCLUDED:

|Repeat until end of file: read a line from the file, fill the input
|buffer from the contents of that line, set >IN to zero, and interpret.

Standard programs can use SOURCE, >IN and REFILL to read data, and
give significance to line endings (even without REFILL, see
DEFINE-NODES and DEPS in
<https://rosettacode.org/wiki/Topological_sort#Forth>).

- 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 2016: http://www.euroforth.org/ef16/

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

#46967

Anton Ertl wrote:
> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes:
> >On 2016-05-06, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> >> In practice, Forth-94 systems provide most standard
> >> words, particularly, REFILL.  I just tested SwiftForth, VFX, iforth
> >> 2.1, bigForth 2.3.1, and gforth, and they all have REFILL.  After all,
> >> it's needed in the implementation of a Forth system.
> >
> >REFILL is not needed to implement a Forth.
>
> Sure you can have REFILL-like functionality that's not factored into a
> word called REFILL, it just does not make much sense.

Unless you have a system like eFORTH.  I read A.6.2.2040 as being
more about your options should you encounter QUERY (a Forth-83
word) in an old program.

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

#46972

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes:
>> >On 2016-05-06, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> >> In practice, Forth-94 systems provide most standard
>> >> words, particularly, REFILL.  I just tested SwiftForth, VFX, iforth
>> >> 2.1, bigForth 2.3.1, and gforth, and they all have REFILL.  After all,
>> >> it's needed in the implementation of a Forth system.
>> >
>> >REFILL is not needed to implement a Forth.
>>
>> Sure you can have REFILL-like functionality that's not factored into a
>> word called REFILL, it just does not make much sense.
>
>Unless you have a system like eFORTH.  I read A.6.2.2040 as being
>more about your options should you encounter QUERY (a Forth-83
>word) in an old program.

Yes, that's what I expected A.6.2.2040 to talk about, but it does not
make sense with that view.  Mentioning REFILL would have made more
sense.  Of course, in the Forth-94 document, A.6.2.2125 that does
mention it is right behind A.6.2.2040, but I still did not read it
when doing the initial posting.

- 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 2016: http://www.euroforth.org/ef16/

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

#46964

On Mon, 02 May 2016 17:05:19 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
> with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
> function of QUERY as I understand the specification of QUERY.  The
> specification says:
> 
> |6.2.2040 QUERY  CORE EXT ( -- )
> |
> |Make the user input device the input source. Receive input into the
> |terminal input buffer, replacing any previous contents. Make the
> |result, whose address is returned by TIB, the input buffer. Set >IN
> to |zero.
> 
> It seems that REFILL is a more likely replacement for QUERY in most
> cases.  It does not change the input source, but neither does ACCEPT,
> and EVALUATE only changes it temporarily and not to the user input
> device.  Apart from that, QUERY seems to be a
> user-input-device-specific version of REFILL, and therefore REFILL is
> more likely replacement for QUERY in many cases.
> 

Shouldn't ACCEPT and EVALUATE replace QUERY for compliance?
Even though a system may provide QUERY or REFILL , I'm assuming
that ACCEPT and EVALUATE should be used in the initial code for
compliance instead of using QUERY.

What basic, preliminary, or rudimentary definitions would you suggest
for QUERY or REFILL?  The ease of implementation of either or both in
terms of the other may be a factor.  The ease of replacing QUERY or
REFILL with ACCEPT or EVALUATE may be a factor too.


Rod Pemberton

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

#46970

On 2016-05-06, Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> wrote:
> On Mon, 02 May 2016 17:05:19 GMT
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
>> with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
>> function of QUERY as I understand the specification of QUERY.  The
>> specification says:
>>
>> |6.2.2040 QUERY  CORE EXT ( -- )
>> |
>> |Make the user input device the input source. Receive input into the
>> |terminal input buffer, replacing any previous contents. Make the
>> |result, whose address is returned by TIB, the input buffer. Set >IN
>> to |zero.
>>
>> It seems that REFILL is a more likely replacement for QUERY in most
>> cases.  It does not change the input source, but neither does ACCEPT,
>> and EVALUATE only changes it temporarily and not to the user input
>> device.  Apart from that, QUERY seems to be a
>> user-input-device-specific version of REFILL, and therefore REFILL is
>> more likely replacement for QUERY in many cases.
>>
>
> Shouldn't ACCEPT and EVALUATE replace QUERY for compliance?
> Even though a system may provide QUERY or REFILL , I'm assuming
> that ACCEPT and EVALUATE should be used in the initial code for
> compliance instead of using QUERY.
>
> What basic, preliminary, or rudimentary definitions would you suggest
> for QUERY or REFILL?  The ease of implementation of either or both in
> terms of the other may be a factor.  The ease of replacing QUERY or
> REFILL with ACCEPT or EVALUATE may be a factor too.

This is the ciforth philosophy:
  refilling is only needed from the console, so ACCEPT or (ACCEPT)
  works with console buffer.
  line by line reading of source files is a relic.

  REFILL is not needed. Especially a REFILL that treats the console
  and an input file the same, is bad and leads to contorsions.

QUERY can be replaced by (ACCEPT) mostly.

QUERY was a char by char input, with all editing done by the Forth.
If you want that (e.g. to do syntax coloring while inputting)
there is no alternative.
ACCEPT doesn't make the Forth aware of each individual character,
QUERY does.

I repeat :
*********************************************************************
*    QUERY may be obsolescent, but it has properties that cannot be *
*    reproduced reasonably in a portable way.                       *
*********************************************************************

So really QUERY should not be obsolescent. It has been made
that way because in modern systems it is too hard to implement.
My position on this is: QUERY should be in the standard, but I
won't implement it, because it is too hard for the benefits.
At least that is honest.

(ACCEPT) returns a string constant that the user has input (addr len).
(ACCEPT) relates to the console only. It is far better than ACCEPT
because one is never interested where the actual characters hang out.

>
>
> Rod Pemberton
>
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

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

#46971

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes:
>On 2016-05-06, Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> wrote:
>> On Mon, 02 May 2016 17:05:19 GMT
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>
>>> The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
>>> with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
>>> function of QUERY as I understand the specification of QUERY.  The
>>> specification says:
>>>
>>> |6.2.2040 QUERY  CORE EXT ( -- )
>>> |
>>> |Make the user input device the input source. Receive input into the
>>> |terminal input buffer, replacing any previous contents. Make the
>>> |result, whose address is returned by TIB, the input buffer. Set >IN
>>> to |zero.
>>>
>>> It seems that REFILL is a more likely replacement for QUERY in most
>>> cases.  It does not change the input source, but neither does ACCEPT,
>>> and EVALUATE only changes it temporarily and not to the user input
>>> device.  Apart from that, QUERY seems to be a
>>> user-input-device-specific version of REFILL, and therefore REFILL is
>>> more likely replacement for QUERY in many cases.
>>>
>>
>> Shouldn't ACCEPT and EVALUATE replace QUERY for compliance?
>> Even though a system may provide QUERY or REFILL , I'm assuming
>> that ACCEPT and EVALUATE should be used in the initial code for
>> compliance instead of using QUERY.
>>
>> What basic, preliminary, or rudimentary definitions would you suggest
>> for QUERY or REFILL?  The ease of implementation of either or both in
>> terms of the other may be a factor.  The ease of replacing QUERY or
>> REFILL with ACCEPT or EVALUATE may be a factor too.
>
>This is the ciforth philosophy:
>  refilling is only needed from the console, so ACCEPT or (ACCEPT)
>  works with console buffer.

A standard ACCEPT takes the buffer it writes to as parameter.

>  line by line reading of source files is a relic.

A standard system may read or mmap the whole file at once, but must
present each line to programs separately (through SOURCE, >IN, and
REFILL).

>  REFILL is not needed. Especially a REFILL that treats the console
>  and an input file the same, is bad and leads to contorsions.

Contorsions like standard programs actually working on standard
systems.

>QUERY was a char by char input, with all editing done by the Forth.
>If you want that (e.g. to do syntax coloring while inputting)
>there is no alternative.
>ACCEPT doesn't make the Forth aware of each individual character,
>QUERY does.

These phantasies have nothing to do with Forth-94 standard QUERY and
ACCEPT:

>I repeat :
>*********************************************************************
>*    QUERY may be obsolescent, but it has properties that cannot be *
>*    reproduced reasonably in a portable way.                       *
>*********************************************************************

Yes: "Make the user input device the input source".  There is no way
to do that in a standard program, but that's also something that is
not needed.

>So really QUERY should not be obsolescent.

It's no longer.  It's not in Forth-2012.

>It has been made
>that way because in modern systems it is too hard to implement.

It just does not fit into the modern world of nested input sources
(INCLUDED, LOAD, EVALUATE).  I just looked at the Gforth
implementation.  It is:

: query  
  clear-tibstack refill 0= -57 and throw ; ok

So it deals with the nested input sources by throwing all the nesting
away.  Not sure if this is correct, but IIRC we never received any
complaints about it (which probably just reflects that nobody has used
it).

>My position on this is: QUERY should be in the standard, but I
>won't implement it, because it is too hard for the benefits.

That's an idiotic position.  There is no point in standardizing a word
if there is no intent to implement it.

- 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 2016: http://www.euroforth.org/ef16/

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

#46978

On 5/7/16 1:49 AM, Albert van der Horst wrote:
> On 2016-05-06, Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> wrote:
>> On Mon, 02 May 2016 17:05:19 GMT
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>
>>> The Forth-94 appendix A.6.2.2040 suggests that QUERY can be replaced
>>> with ACCEPT and EVALUATE, but that looks pretty far-fetched from the
>>> function of QUERY as I understand the specification of QUERY.  The
>>> specification says:
>>>
>>> |6.2.2040 QUERY  CORE EXT ( -- )
>>> |
>>> |Make the user input device the input source. Receive input into the
>>> |terminal input buffer, replacing any previous contents. Make the
>>> |result, whose address is returned by TIB, the input buffer. Set >IN
>>> to |zero.
>>>
>>> It seems that REFILL is a more likely replacement for QUERY in most
>>> cases.  It does not change the input source, but neither does ACCEPT,
>>> and EVALUATE only changes it temporarily and not to the user input
>>> device.  Apart from that, QUERY seems to be a
>>> user-input-device-specific version of REFILL, and therefore REFILL is
>>> more likely replacement for QUERY in many cases.
>>>
>>
>> Shouldn't ACCEPT and EVALUATE replace QUERY for compliance?
>> Even though a system may provide QUERY or REFILL , I'm assuming
>> that ACCEPT and EVALUATE should be used in the initial code for
>> compliance instead of using QUERY.
>>
>> What basic, preliminary, or rudimentary definitions would you suggest
>> for QUERY or REFILL?  The ease of implementation of either or both in
>> terms of the other may be a factor.  The ease of replacing QUERY or
>> REFILL with ACCEPT or EVALUATE may be a factor too.
>
> This is the ciforth philosophy:
>   refilling is only needed from the console, so ACCEPT or (ACCEPT)
>   works with console buffer.
>   line by line reading of source files is a relic.
>
>   REFILL is not needed. Especially a REFILL that treats the console
>   and an input file the same, is bad and leads to contorsions.
>
> QUERY can be replaced by (ACCEPT) mostly.
>
> QUERY was a char by char input, with all editing done by the Forth.
> If you want that (e.g. to do syntax coloring while inputting)
> there is no alternative.
> ACCEPT doesn't make the Forth aware of each individual character,
> QUERY does.
>
> I repeat :
> *********************************************************************
> *    QUERY may be obsolescent, but it has properties that cannot be *
> *    reproduced reasonably in a portable way.                       *
> *********************************************************************
>
> So really QUERY should not be obsolescent. It has been made
> that way because in modern systems it is too hard to implement.
> My position on this is: QUERY should be in the standard, but I
> won't implement it, because it is too hard for the benefits.
> At least that is honest.
>
> (ACCEPT) returns a string constant that the user has input (addr len).
> (ACCEPT) relates to the console only. It is far better than ACCEPT
> because one is never interested where the actual characters hang out.

The major difference historically is that EXPECT (predecessor of ACCEPT) 
acquired an input stream, while QUERY called EXPECT/ACCEPT and then 
processed the resulting input with INTERPRET. So, ACCEPT is really a 
factor of QUERY. There are, of course, other ways to feed an input 
stream to INTERPRET, but QUERY is the one designed for the operator 
terminal.

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]

#46983

On 2016-05-07, Elizabeth D. Rather <erather@forth.com> wrote:
> On 5/7/16 1:49 AM, Albert van der Horst wrote:
<SNIP>
>>
>> I repeat :
>> *********************************************************************
>> *    QUERY may be obsolescent, but it has properties that cannot be *
>> *    reproduced reasonably in a portable way.                       *
>> *********************************************************************
>>
>> So really QUERY should not be obsolescent. It has been made
>> that way because in modern systems it is too hard to implement.
>> My position on this is: QUERY should be in the standard, but I
>> won't implement it, because it is too hard for the benefits.
>> At least that is honest.
>>
<SNIP>
>
> The major difference historically is that EXPECT (predecessor of ACCEPT)
> acquired an input stream, while QUERY called EXPECT/ACCEPT and then
> processed the resulting input with INTERPRET. So, ACCEPT is really a
> factor of QUERY. There are, of course, other ways to feed an input
> stream to INTERPRET, but QUERY is the one designed for the operator
> terminal.

Oops. I mixed up QUERY and ACCEPT. That was a weak post.

>
> Cheers,
> Elizabeth

Groetjes en dank 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

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

#46987

"Elizabeth D. Rather" <erather@forth.com> writes:
>The major difference historically is that EXPECT (predecessor of ACCEPT) 
>acquired an input stream, while QUERY called EXPECT/ACCEPT and then 
>processed the resulting input with INTERPRET.

A Forth-94-compliant QUERY must not INTERPRET.  It just sets the input
source and ACCEPTs input into TIB.

- 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 2016: http://www.euroforth.org/ef16/

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

#46973

Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes:
>Shouldn't ACCEPT and EVALUATE replace QUERY for compliance?
>Even though a system may provide QUERY or REFILL , I'm assuming
>that ACCEPT and EVALUATE should be used in the initial code for
>compliance instead of using QUERY.

I have no idea what ypu mean with compliance here.

When Forth-94 A.6.2.2040 says:

|The function of QUERY may be performed with ACCEPT and EVALUATE.

I understand this as a recommendation to those who wanted to avoid the
use of a (then) obsolescent word.  And IMO REFILL would have been a
better recommendation.

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [standalone]

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

csiph-web