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

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

Specifying interfaces of "read-ahead" words

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

Contents

  Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-05 05:38 -0800
    Re: Specifying interfaces of "read-ahead" words Alex McDonald <blog@rivadpm.com> - 2013-02-05 06:09 -0800
      Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-05 06:29 -0800
        Re: Specifying interfaces of "read-ahead" words Alex McDonald <blog@rivadpm.com> - 2013-02-05 07:02 -0800
          Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-05 07:17 -0800
            Re: Specifying interfaces of "read-ahead" words Josh Grams <josh@qualdan.com> - 2013-02-05 21:07 +0000
    Re: Specifying interfaces of "read-ahead" words Coos Haak <chforth@hccnet.nl> - 2013-02-05 18:18 +0100
      Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-05 13:54 -0800
        Re: Specifying interfaces of "read-ahead" words "Elizabeth D. Rather" <erather@forth.com> - 2013-02-05 14:02 -1000
          Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-05 23:19 -0800
            Re: Specifying interfaces of "read-ahead" words Alex McDonald <blog@rivadpm.com> - 2013-02-06 06:59 -0800
          Re: Specifying interfaces of "read-ahead" words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-06 15:34 +0000
        Re: Specifying interfaces of "read-ahead" words Doug Hoffman <glidedog@gmail.com> - 2013-02-05 20:48 -0500
          Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-05 23:17 -0800
            Re: Specifying interfaces of "read-ahead" words Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:01 -0800
              Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-06 01:02 -0800
              Re: Specifying interfaces of "read-ahead" words Doug Hoffman <glidedog@gmail.com> - 2013-02-06 04:24 -0500
          Re: Specifying interfaces of "read-ahead" words Doug Hoffman <glidedog@gmail.com> - 2013-02-06 07:39 -0500
        Re: Specifying interfaces of "read-ahead" words "Peter Knaggs" <pjk@bcs.org.uk> - 2013-02-11 08:07 +0000
          Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-11 07:10 -0800
            Re: Specifying interfaces of "read-ahead" words "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-11 15:51 -0800
              Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-11 23:05 -0800
                Re: Specifying interfaces of "read-ahead" words "Elizabeth D. Rather" <erather@forth.com> - 2013-02-11 22:03 -1000
            Re: Specifying interfaces of "read-ahead" words "Peter Knaggs" <pjk@bcs.org.uk> - 2013-02-13 07:39 +0000
              Re: Specifying interfaces of "read-ahead" words Mark Wills <forthfreak@gmail.com> - 2013-02-13 00:23 -0800
                Re: Specifying interfaces of "read-ahead" words "Peter Knaggs" <pjk@bcs.org.uk> - 2013-02-13 18:08 +0000
    Re: Specifying interfaces of "read-ahead" words "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-09 13:49 -0800
      Re: Specifying interfaces of "read-ahead" words Coos Haak <chforth@hccnet.nl> - 2013-02-10 00:17 +0100
        Re: Specifying interfaces of "read-ahead" words "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-09 17:20 -0800
        Re: Specifying interfaces of "read-ahead" words "Peter Knaggs" <pjk@bcs.org.uk> - 2013-02-11 08:29 +0000
          Re: Specifying interfaces of "read-ahead" words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-11 14:27 +0000

Page 2 of 2 — ← Prev page 1 [2]

#19649

On Monday, February 11, 2013 9:10:49 AM UTC-6, M.R.W Wills wrote:
> On Feb 11, 8:07 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> 
> > On Tue, 05 Feb 2013 21:54:32 -0000, Mark Wills <forthfr...@gmail.com>
> 
> > wrote:
> 
> >
> 
> >
> 
> >
> 
> > > Sure, but "<spaces>name" does not come from the _stack_ so why is it
> 
> > > shown on the input side of a _stack signature_.
> 
> >
> 
> > Because it is a "signature" rather than a "stack signature".  The input
> 
> > stream forms part of the input to the word.
> 
> >
> 
> > --
> 
> > Peter Knaggs
> 
> 
> 
> When did this name/usage change take place? Was it with the adoption
> 
> of ANS?


Great history outline. Do any of you know if NULL survived FIG, as it seems to be the way INTERPRET exits (returns) to quit, which I didn't expect, and don't know if this has been eliminated and how a simple enter works nowadays...

Please disregard this if you don't know of FIG and NULL :>)

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

#19664

On Feb 11, 11:51 pm, "Clyde W. Phillips Jr." <cwpj...@gmail.com>
wrote:
> On Monday, February 11, 2013 9:10:49 AM UTC-6, M.R.W Wills wrote:
> > On Feb 11, 8:07 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>
> > > On Tue, 05 Feb 2013 21:54:32 -0000, Mark Wills <forthfr...@gmail.com>
>
> > > wrote:
>
> > > > Sure, but "<spaces>name" does not come from the _stack_ so why is it
>
> > > > shown on the input side of a _stack signature_.
>
> > > Because it is a "signature" rather than a "stack signature".  The input
>
> > > stream forms part of the input to the word.
>
> > > --
>
> > > Peter Knaggs
>
> > When did this name/usage change take place? Was it with the adoption
>
> > of ANS?
>
> Great history outline. Do any of you know if NULL survived FIG, as it seems to be the way INTERPRET exits (returns) to quit, which I didn't expect, and don't know if this has been eliminated and how a simple enter works nowadays...
>
> Please disregard this if you don't know of FIG and NULL :>)- Hide quoted text -
>
> - Show quoted text -

My INTEREPRET returns (or rather, exits) when WORD indicates there are
no words left in the buffer. INTERPRET itself doesn't deal with >IN at
all.

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

#19668

On 2/11/13 9:05 PM, Mark Wills wrote:
> On Feb 11, 11:51 pm, "Clyde W. Phillips Jr." <cwpj...@gmail.com>
...
>
> My INTEREPRET returns (or rather, exits) when WORD indicates there are
> no words left in the buffer. INTERPRET itself doesn't deal with >IN at
> all.
>

As you described in your longer post :-)

Ok, I was trying not to go into too much detail in my description, 
because implementations do vary. For example, there's the whole school 
of thought that hates WORD because it skips leading delimiters.

Sure, your pseudo-code is fine, but there are other ways to do it.

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]

#19698

On Mon, 11 Feb 2013 15:10:49 -0000, Mark Wills <forthfreak@gmail.com>  
wrote:
> On Feb 11, 8:07 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>> On Tue, 05 Feb 2013 21:54:32 -0000, Mark Wills <forthfr...@gmail.com>
>> wrote:
>>
>> > Sure, but "<spaces>name" does not come from the _stack_ so why is it
>> > shown on the input side of a _stack signature_.
>>
>> Because it is a "signature" rather than a "stack signature".  The input
>> stream forms part of the input to the word.
>
> When did this name/usage change take place? Was it with the adoption
> of ANS?

ANS refers to it as a "stack notation" (2.2.2) although in "Parsed-text  
notation" (2.2.3) it then adds the " notation to the stack description.  I  
have always thought of it as a signature, it makes it much easer to reason  
about the stack operation.

-- 
Peter Knaggs

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

#19700

On Feb 13, 7:39 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> On Mon, 11 Feb 2013 15:10:49 -0000, Mark Wills <forthfr...@gmail.com>
> wrote:
>
> > On Feb 11, 8:07 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> >> On Tue, 05 Feb 2013 21:54:32 -0000, Mark Wills <forthfr...@gmail.com>
> >> wrote:
>
> >> > Sure, but "<spaces>name" does not come from the _stack_ so why is it
> >> > shown on the input side of a _stack signature_.
>
> >> Because it is a "signature" rather than a "stack signature".  The input
> >> stream forms part of the input to the word.
>
> > When did this name/usage change take place? Was it with the adoption
> > of ANS?
>
> ANS refers to it as a "stack notation" (2.2.2) although in "Parsed-text
> notation" (2.2.3) it then adds the " notation to the stack description.  I
> have always thought of it as a signature, it makes it much easer to reason
> about the stack operation.
>
> --
> Peter Knaggs

It's the same in 200x IIRC. I would suggest that 2.2.2 could be
improved in 200x. I'm not suggesting that the practice change, but
2.2.2 could probably be re-worded (i.e. not calling it a *stack*
signature since the notation describes more than the stack signature).

FWIW!

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

#19713

On Wed, 13 Feb 2013 08:23:13 -0000, Mark Wills <forthfreak@gmail.com>  
wrote:

> On Feb 13, 7:39 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>> On Mon, 11 Feb 2013 15:10:49 -0000, Mark Wills <forthfr...@gmail.com>
>> wrote:
>>
>> > On Feb 11, 8:07 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>> >> On Tue, 05 Feb 2013 21:54:32 -0000, Mark Wills <forthfr...@gmail.com>
>> >> wrote:
>>
>> >> > Sure, but "<spaces>name" does not come from the _stack_ so why is  
>> >> > it shown on the input side of a _stack signature_.
>>
>> >> Because it is a "signature" rather than a "stack signature".  The >>  
>> input stream forms part of the input to the word.
>>
>> > When did this name/usage change take place? Was it with the adoption
>> > of ANS?
>>
>> ANS refers to it as a "stack notation" (2.2.2) although in "Parsed-text
>> notation" (2.2.3) it then adds the " notation to the stack description.  
>> I have always thought of it as a signature, it makes it much easer to  
>> reason about the stack operation.
>
> It's the same in 200x IIRC. I would suggest that 2.2.2 could be
> improved in 200x. I'm not suggesting that the practice change, but
> 2.2.2 could probably be re-worded (i.e. not calling it a *stack*
> signature since the notation describes more than the stack signature).

I look forward to receiving your revised paragraph(s).

-- 
Peter Knaggs

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

#19592

On Tuesday, February 5, 2013 7:38:13 AM UTC-6, M.R.W Wills wrote:
> The discussion on the other thread re DEFER/IS was interesting.
> 
> There's a link to a 200x page regarding a deferred word proposal, I'll
> 
> re-post the link here:
> 
> 
> 
> http://www.forth200x.org/deferred.html
> 
> 
> 
> The definitions of IS and ACTION-OF are interesting:
> 
> 
> 
> : is
> 
>   state @ if
> 
>     POSTPONE ['] POSTPONE defer!
> 
>   else
> 
>     ' defer!
> 
>   then ; immediate
> 
> 
> 
> : action-of
> 
>  state @ if
> 
>    POSTPONE ['] POSTPONE defer@
> 
>  else
> 
>    ' defer@
> 
>  then ; immediate
> 
> 
> 
> What struck me as odd (at first) was that there are no stack comments.
> 
> Examining more closely, it's perfectly fine, since they have no stack
> 
> effects (though an empty stack comment would have been better).
> 
> 
> 
> However, whilst they don't have any _stack_ requirements, they _do_
> 
> have other "interface" requirements (for want of a better term). Both
> 
> words are 'read-ahead' words - they get their input from the input
> 
> buffer, as currently indexed by >IN.
> 
> 
> 
> That let me to wonder, is there any traditional/accepted practice for
> 
> indicating the interfacing requirements for words such as these?

Hi I am doing the fundamental port of original FIG FORTH and the sparce documentation I have found counter indicated IN as holding an offset value or the address of the buffer with the offset included. Since most modern FORTHs are derived from FIG is IN commomly an offset or and address? My hopes are for offset! 

Thanks!

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

#19595

Op Sat, 9 Feb 2013 13:49:05 -0800 (PST) schreef Clyde W. Phillips Jr.:

> On Tuesday, February 5, 2013 7:38:13 AM UTC-6, M.R.W Wills wrote:
>> The discussion on the other thread re DEFER/IS was interesting.
>> 
>> There's a link to a 200x page regarding a deferred word proposal, I'll
>> 
>> re-post the link here:
>> 
>> 
>> 
>> http://www.forth200x.org/deferred.html
>> 
>> 
>> 
>> The definitions of IS and ACTION-OF are interesting:
>> 
>> 
>> 
>>: is
>> 
>>   state @ if
>> 
>>     POSTPONE ['] POSTPONE defer!
>> 
>>   else
>> 
>>     ' defer!
>> 
>>   then ; immediate
>> 
>> 
>> 
>>: action-of
>> 
>>  state @ if
>> 
>>    POSTPONE ['] POSTPONE defer@
>> 
>>  else
>> 
>>    ' defer@
>> 
>>  then ; immediate
>> 
>> 
>> 
>> What struck me as odd (at first) was that there are no stack comments.
>> 
>> Examining more closely, it's perfectly fine, since they have no stack
>> 
>> effects (though an empty stack comment would have been better).
>> 
>> 
>> 
>> However, whilst they don't have any _stack_ requirements, they _do_
>> 
>> have other "interface" requirements (for want of a better term). Both
>> 
>> words are 'read-ahead' words - they get their input from the input
>> 
>> buffer, as currently indexed by >IN.
>> 
>> 
>> 
>> That let me to wonder, is there any traditional/accepted practice for
>> 
>> indicating the interfacing requirements for words such as these?
> 
> Hi I am doing the fundamental port of original FIG FORTH and the sparce documentation I have found counter indicated IN as holding an offset value or the address of the buffer with the offset included. Since most modern FORTHs are derived from FIG is IN commomly an offset or and address? My hopes are for offset! 
> 
> Thanks!

From the ANS standard:
6.1.0560 >IN
to-in CORE

	( -- a-addr )

a-addr is the address of a cell containing the offset in characters from 
the start of the input buffer to the start of the parse area. 

So it's an offset since 1995.

-- 
Coos

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

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

#19601

On Saturday, February 9, 2013 5:17:49 PM UTC-6, Coos Haak wrote:
> Op Sat, 9 Feb 2013 13:49:05 -0800 (PST) schreef Clyde W. Phillips Jr.:
> 
> 
> 
> > On Tuesday, February 5, 2013 7:38:13 AM UTC-6, M.R.W Wills wrote:
> 
> >> The discussion on the other thread re DEFER/IS was interesting.
> 
> >> 
> 
> >> There's a link to a 200x page regarding a deferred word proposal, I'll
> 
> >> 
> 
> >> re-post the link here:
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> http://www.forth200x.org/deferred.html
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> The definitions of IS and ACTION-OF are interesting:
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >>: is
> 
> >> 
> 
> >>   state @ if
> 
> >> 
> 
> >>     POSTPONE ['] POSTPONE defer!
> 
> >> 
> 
> >>   else
> 
> >> 
> 
> >>     ' defer!
> 
> >> 
> 
> >>   then ; immediate
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >>: action-of
> 
> >> 
> 
> >>  state @ if
> 
> >> 
> 
> >>    POSTPONE ['] POSTPONE defer@
> 
> >> 
> 
> >>  else
> 
> >> 
> 
> >>    ' defer@
> 
> >> 
> 
> >>  then ; immediate
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> What struck me as odd (at first) was that there are no stack comments.
> 
> >> 
> 
> >> Examining more closely, it's perfectly fine, since they have no stack
> 
> >> 
> 
> >> effects (though an empty stack comment would have been better).
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> However, whilst they don't have any _stack_ requirements, they _do_
> 
> >> 
> 
> >> have other "interface" requirements (for want of a better term). Both
> 
> >> 
> 
> >> words are 'read-ahead' words - they get their input from the input
> 
> >> 
> 
> >> buffer, as currently indexed by >IN.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> That let me to wonder, is there any traditional/accepted practice for
> 
> >> 
> 
> >> indicating the interfacing requirements for words such as these?
> 
> > 
> 
> > Hi I am doing the fundamental port of original FIG FORTH and the sparce documentation I have found counter indicated IN as holding an offset value or the address of the buffer with the offset included. Since most modern FORTHs are derived from FIG is IN commomly an offset or and address? My hopes are for offset! 
> 
> > 
> 
> > Thanks!
> 
> 
> 
> From the ANS standard:
> 
> 6.1.0560 >IN
> 
> to-in CORE
> 
> 
> 
> 	( -- a-addr )
> 
> 
> 
> a-addr is the address of a cell containing the offset in characters from 
> 
> the start of the input buffer to the start of the parse area. 
> 
> 
> 
> So it's an offset since 1995.
> 
> 
> 
> -- 
> 
> Coos
> 
> 
> 
> CHForth, 16 bit DOS applications
> 
> http://home.hccnet.nl/j.j.haak/forth.html

Thanks. Will proceed with historical precedence. hahah]

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

#19630

On Sat, 09 Feb 2013 23:17:49 -0000, Coos Haak <chforth@hccnet.nl> wrote:
>
> From the ANS standard:
> 6.1.0560 >IN
> to-in CORE
>
> 	( -- a-addr )
>
> a-addr is the address of a cell containing the offset in characters from
> the start of the input buffer to the start of the parse area.
>
> So it's an offset since 1995.

This is a simple updating of the Forth 83 definition:

     >IN   -- addr    U,79  "to-in"

     The address of a variable which contains the present character offset
     within the input stream {{0..the number of characters in the input
     stream}}.  See: WORD

Which in turn is a simple adoption of the Forth 79 definition:

     >IN -- addr U,201

     Leave the address of a variable which contains the present character
     offset within the input stream {{0…1023}} “to-in”

     See: WORD ( ." FIND

So we could say that it has ever been thus.

On the other hand, my copy of FIG Forth (from August 1980) does not contain
a definition of >IN.

-- 
Peter Knaggs

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

#19631

"Peter Knaggs" <pjk@bcs.org.uk> writes:
>On the other hand, my copy of FIG Forth (from August 1980) does not cont=
>ain
>a definition of >IN.

It's called IN in fig-Forth, and the only difference from >IN is the 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 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web