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 1 of 2  [1] 2  Next page →

#19458 — Specifying interfaces of "read-ahead" words

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?

[toc] | [next] | [standalone]

#19459

On Feb 5, 1:38 pm, Mark Wills <forthfr...@gmail.com> 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?

I use a quoted string as in : action-of ( "name" -- ). I've also seen
<name> <-name-> and a variety of other nomenclatures to indicate
parsing.

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

#19461

On Feb 5, 2:09 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Feb 5, 1:38 pm, Mark Wills <forthfr...@gmail.com> 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?
>
> I use a quoted string as in : action-of ( "name" -- ). I've also seen
> <name> <-name-> and a variety of other nomenclatures to indicate
> parsing.- Hide quoted text -
>
> - Show quoted text -

There are two problems with that particular method (for me):

* The information is within a stack comment
* The information is on the left of the stack indicator

This indicates that "name" should be on the stack *prior* to
invocation.

So, I would interpret your description as requiring S" as in:

S" something" action-of

The above would appear to satisfy the above _stack signature_ but in
actual fact the word has no _stack_ requirements at all.

I'm not knocking your solution, since I've seen it elsewhere, but to
me it doesn't describe the interface of the word at all.

The best I can think of is:

PARSING

As in

: is
  state @ if
    POSTPONE ['] POSTPONE defer!
  else
    ' defer!
  then ; immediate parsing

With the definition of PARSING being:

: PARSING ; IMMEDIATE

I.e., it does nothing at all, except to explicitly tell the programmer
that this is a parsing word (i.e. it reads from the input stream -
perhaps "parsing" is not the correct name, but you get my drift...)

As I see it, we can't put anything within the stack signature, because
(in this case) this word has no stack requirements. PARSING could be
combined with a stack sig, of course, where the interface requirements
of the word required it:

: someWord ( a b -- c) ... ... ... ; immediate parsing

This word has stack requirements and it also reads from the input
stream.

Regards

Mark

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

#19463

On Feb 5, 2:29 pm, Mark Wills <forthfr...@gmail.com> wrote:
> On Feb 5, 2:09 pm, Alex McDonald <b...@rivadpm.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Feb 5, 1:38 pm, Mark Wills <forthfr...@gmail.com> 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?
>
> > I use a quoted string as in : action-of ( "name" -- ). I've also seen
> > <name> <-name-> and a variety of other nomenclatures to indicate
> > parsing.- Hide quoted text -
>
> > - Show quoted text -
>
> There are two problems with that particular method (for me):
>
> * The information is within a stack comment
> * The information is on the left of the stack indicator
>
> This indicates that "name" should be on the stack *prior* to
> invocation.

No, that appears in the spec (but is not specified as required) as ( c-
addr u -- ); a bit long winded, but it indicates quite clearly that
there are two entries on the stack on entry, and that it's a string.
The spec uses ( "<spaces>name" -- ) to indicate parsing.

>
> So, I would interpret your description as requiring S" as in:
>
> S" something" action-of
>
> The above would appear to satisfy the above _stack signature_ but in
> actual fact the word has no _stack_ requirements at all.
>
> I'm not knocking your solution, since I've seen it elsewhere, but to
> me it doesn't describe the interface of the word at all.
>
> The best I can think of is:
>
> PARSING
>
> As in
>
> : is
>   state @ if
>     POSTPONE ['] POSTPONE defer!
>   else
>     ' defer!
>   then ; immediate parsing
>
> With the definition of PARSING being:
>
> : PARSING ; IMMEDIATE
>
> I.e., it does nothing at all, except to explicitly tell the programmer
> that this is a parsing word (i.e. it reads from the input stream -
> perhaps "parsing" is not the correct name, but you get my drift...)
>
> As I see it, we can't put anything within the stack signature, because
> (in this case) this word has no stack requirements. PARSING could be
> combined with a stack sig, of course, where the interface requirements
> of the word required it:
>
> : someWord ( a b -- c) ... ... ... ; immediate parsing
>
> This word has stack requirements and it also reads from the input
> stream.

I hope this doesn't catch on.

>
> Regards
>
> Mark

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

#19464

<snip>
The spec uses ( "<spaces>name" -- ) to indicate parsing.
</snip>

Okay, agreed. But would you agree that that is confusing? It is on the
left side of a stack diagram, implying that something (whatever it is)
needs to be on the stack prior to invocation, but that's not the case
at all!

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

#19483

Mark Wills wrote: <fc0fab00-52f6-4a69-9e09-cdb4589f03a0@e11g2000vbv.googlegroups.com>
> The spec uses ( "<spaces>name" -- ) to indicate parsing.
>
> Okay, agreed. But would you agree that that is confusing? It is on the
> left side of a stack diagram, implying that something (whatever it is)
> needs to be on the stack prior to invocation, but that's not the case
> at all!

No, it's not confusing at all.  The left side is inputs, the right side
is outputs.  The quotes indicate that it is NOT on the stack, but is
parsed from the input string, where it *does* need to be present prior
to invoking the word.

--Josh

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

#19471

Op Tue, 5 Feb 2013 05:38:13 -0800 (PST) schreef Mark Wills:

> 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?

Look higher up in http://www.forth200x.org/deferred.html
Shortened:

IS
Interpretation: ( xt "<spaces>name" -- )
Compilation: ( "<spaces>name" -- ) 
Run-time: ( xt -- )

ACTION-OF
Interpretation: ( "<spaces>name" -- xt )
Compilation: ( "<spaces>name" -- )
Run-time: ( -- xt )

So there _are_ stack changes. IS needs an xt and ACTION-OF leaves an xt.
Both parse a name.

-- 
Coos

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

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

#19486

On Feb 5, 5:18 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> Op Tue, 5 Feb 2013 05:38:13 -0800 (PST) schreef Mark Wills:
>
>
>
>
>
>
>
>
>
> > 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?
>
> Look higher up inhttp://www.forth200x.org/deferred.html
> Shortened:
>
> IS
> Interpretation: ( xt "<spaces>name" -- )
> Compilation: ( "<spaces>name" -- )
> Run-time: ( xt -- )
>
> ACTION-OF
> Interpretation: ( "<spaces>name" -- xt )
> Compilation: ( "<spaces>name" -- )
> Run-time: ( -- xt )
>
> So there _are_ stack changes. IS needs an xt and ACTION-OF leaves an xt.
> Both parse a name.
>
> --
> Coos
>
> CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html

Sure, but "<spaces>name" does not come from the _stack_ so why is it
shown on the input side of a _stack signature_.

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

#19490

On 2/5/13 11:54 AM, Mark Wills wrote:
> On Feb 5, 5:18�pm, Coos Haak <chfo...@hccnet.nl> wrote:
>> Op Tue, 5 Feb 2013 05:38:13 -0800 (PST) schreef Mark Wills:
...
>>> 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?
>>
>> Look higher up inhttp://www.forth200x.org/deferred.html
>> Shortened:
>>
>> IS
>> Interpretation: ( xt "<spaces>name" -- )
>> Compilation: ( "<spaces>name" -- )
>> Run-time: ( xt -- )
>>
>> ACTION-OF
>> Interpretation: ( "<spaces>name" -- xt )
>> Compilation: ( "<spaces>name" -- )
>> Run-time: ( -- xt )
>>
>> So there _are_ stack changes. IS needs an xt and ACTION-OF leaves an xt.
>> Both parse a name.
>>
>> --
>> Coos
>>
>> CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html
>
> 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 isn't just a *stack* signature, it's a description of the 
arguments for the word, in and out. I agree it's not all that beautiful, 
but it's a compromise that the original Forth94 TC came up with, and a 
lot of people understand it at this point.

A slightly prettier convention is:

VALUE ( n -- )   \ Usage:  <n> VALUE <name>

It's wordier, though.

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]

#19495

On Feb 6, 12:02 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
>
> Because it isn't just a *stack* signature, it's a description of the
> arguments for the word, in and out. I agree it's not all that beautiful,
> but it's a compromise that the original Forth94 TC came up with, and a
> lot of people understand it at this point.
>
Bah! That's a cop-out! ;-) Every book from Brodie to Rather to Pelc
describes stack signatures, and, to my recollection, makes no mention
of exceptions where the input stream (or some other form of input or
output) can be encapsulated within a *stack signature*!

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

#19508

On Feb 6, 7:19 am, Mark Wills <forthfr...@gmail.com> wrote:
> On Feb 6, 12:02 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
>
> > Because it isn't just a *stack* signature, it's a description of the
> > arguments for the word, in and out. I agree it's not all that beautiful,
> > but it's a compromise that the original Forth94 TC came up with, and a
> > lot of people understand it at this point.
>
> Bah! That's a cop-out! ;-) Every book from Brodie to Rather to Pelc
> describes stack signatures, and, to my recollection, makes no mention
> of exceptions where the input stream (or some other form of input or
> output) can be encapsulated within a *stack signature*!

It can say whatever you wish; the standard doesn't force a grammar on
comments, and there's no attempt in it to create an identifiable
language element called a stack signature. Authors of books and other
experts may agree on good practice, but that doesn't make it
necessary. By convention (or if you like, as a de-facto standard) it
indicates inputs separated by -- then outputs, sometimes with a type
description; and for parsing words, "<spaces>name" or some quoted
equivalent.

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

#19509

"Elizabeth D. Rather" <erather@forth.com> writes:
>> 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 isn't just a *stack* signature, it's a description of the 
>arguments for the word, in and out. I agree it's not all that beautiful, 
>but it's a compromise that the original Forth94 TC came up with, and a 
>lot of people understand it at this point.

Yes.  It's called "stack notation" because that's where it originates,
and the majority of uses just deal with stacks.  If you want a more
general name, you might call is "stack and parsed-text notation", but
I guess most people prefer to stick with "stack notation" even if that
is not 100% accurate.

I also think that, once you accept that it does not just deal with
stacks, it's pretty logical that one puts the inputs to the left of
"--" and the outputs to the right.  Sure, one could have a separated
parsed-input notation, but does that buy anything?

Concerning "confusing", I think that, once the convention is learned,
either one may be confusing, and once you have learned a particular
one, it will not be confusing.

However, I find it suboptimal that the standard is not consistent in
it's use of unified or separated notation.  Some things are unified,
some are separated.  E.g., consider a hypothetical word that would be
written in unified notation:

Execution: ( x1 C:orig F:r1 R:x2 "<spaces>name" -- x2 C:dest F:r2 R:x1 )

or in separated notation:

( x1 -- x2 ) ( C: orig -- dest ) ( F: r1 -- r2 ) ( R: x2 -- x1 ) 
    ( IS: "<spaces>name" -- )

In the standard it would be (I think:)

( x1 "<spaces>name" -- x2 ) ( C: orig -- dest ) ( F: r1 -- r2 ) ( R: x2 -- x1 )

This is mitigated by the fact that most words act on only one or two stacks.


-- 
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] | [next] | [standalone]

#19493

On 2/5/13 4:54 PM, Mark Wills wrote:

>> IS
>> Interpretation: ( xt "<spaces>name" -- )

> Sure, but "<spaces>name" does not come from the _stack_ so why is it
> shown on the input side of a _stack signature_.

I'm with you on this one Mark.  I'm not fond of the notation.

For example, is the following "stack effect" notation any different from 
above?:

IS
Interpretation: ( "<spaces>name" xt -- )


I tend to write the following instead.

IS ( xt -- ) \ Input Stream: <name>


But whatever, I've learned to live with the other way as well.

-Doug

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

#19494

On Feb 6, 1:48 am, Doug Hoffman <glide...@gmail.com> wrote:
> On 2/5/13 4:54 PM, Mark Wills wrote:
>
> >> IS
> >> Interpretation: ( xt "<spaces>name" -- )
> > Sure, but "<spaces>name" does not come from the _stack_ so why is it
> > shown on the input side of a _stack signature_.
>
> I'm with you on this one Mark.  I'm not fond of the notation.
>
> For example, is the following "stack effect" notation any different from
> above?:
>
> IS
> Interpretation: ( "<spaces>name" xt -- )
>
> I tend to write the following instead.
>
> IS ( xt -- ) \ Input Stream: <name>
>
> But whatever, I've learned to live with the other way as well.
>
> -Doug

I'm with you, too Doug! I much prefer your notation and will probably
go with that in my own software from now on. The other notation is
completely confusing and will throw beginners right out of the ring. I
would suggest it's a good candidate for a re-examination wrt to the
200x standard, but intertia is hard to overcome.

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

#19496

Mark Wills <forthfreak@gmail.com> writes:
> The other notation is completely confusing and will throw beginners
> right out of the ring. 

I remember coming across it, noticing that it wasn't really logical,
but understanding what was being done anyway.  It's best to keep in
mind that the stack signature isn't a formal notation; it's just a
commenting convention, and a relatively loose one at that. 

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

#19501

On Feb 6, 8:01 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Mark Wills <forthfr...@gmail.com> writes:
> > The other notation is completely confusing and will throw beginners
> > right out of the ring.
>
> I remember coming across it, noticing that it wasn't really logical,
> but understanding what was being done anyway.  It's best to keep in
> mind that the stack signature isn't a formal notation; it's just a
> commenting convention, and a relatively loose one at that.

It's formalised (is that a real word?) in section 2.2.3 in both ANS
and 200x, but it grates somewhat!

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

#19502

On 2/6/13 3:01 AM, Paul Rubin wrote:
> Mark Wills <forthfreak@gmail.com> writes:
>> The other notation is completely confusing and will throw beginners
>> right out of the ring.
>
> I remember coming across it, noticing that it wasn't really logical,
> but understanding what was being done anyway.  It's best to keep in
> mind that the stack signature isn't a formal notation; it's just a
> commenting convention, and a relatively loose one at that.

That's true.  Although I don't know what a stack signature is because it 
isn't in the Standard.  I do know what Stack notation and Parsed-text 
notation are:

2.2.2 Stack notation
Stack parameters input to and output from a definition are described 
using the notation: ( stack-id: before -- after )

and to your point, the Standard does spell out the following:

2.2.3 Parsed-text notation
If, in addition to using stack parameters, a definition parses text, 
that text is specified by an abbreviation from table 2.1, shown 
surrounded by double-quotes and placed between the before parameters and 
the “--” separator in the first stack described, e.g.,

( S: before “parsed-text-abbreviation” -- after )


Also to your point, the RfD for Enhanced local variable syntax discusses 
how it can serve the dual purpose of a stack comment:

The outputs are provided in the notation so that complete stack comments 
can be produced. However, all text between -- and :} is ignored. This 
facility is there to permit the notation to form a complete stack 
comment, which eases documentation.

e.g., c and d below are definitely not on the stack:

: foo  {: a b | c d -- :}
   ...

-Doug

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

#19505

On 2/5/13 8:48 PM, Doug Hoffman wrote:
> On 2/5/13 4:54 PM, Mark Wills wrote:
>
>>> IS
>>> Interpretation: ( xt "<spaces>name" -- )


> For example, is the following "stack effect" notation any different from
> above?:
>
> IS
> Interpretation: ( "<spaces>name" xt -- )

Of course a careful reading of the Standard tells us it is not.

-Doug

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

#19629

On Tue, 05 Feb 2013 21:54:32 -0000, Mark Wills <forthfreak@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

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

#19633

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?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web