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

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

RfD: TRAVERSE-WORDLIST v4

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

Contents

  RfD: TRAVERSE-WORDLIST v4 Alex McDonald <blog@rivadpm.com> - 2012-02-28 05:14 -0800
    Re: RfD: TRAVERSE-WORDLIST v4 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-28 17:18 +0000
      Re: RfD: TRAVERSE-WORDLIST v4 Alex McDonald <blog@rivadpm.com> - 2012-02-28 13:54 -0800
        Re: RfD: TRAVERSE-WORDLIST v4 "Elizabeth D. Rather" <erather@forth.com> - 2012-02-28 12:16 -1000
          Re: RfD: TRAVERSE-WORDLIST v4 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-29 15:42 +0000
            Re: RfD: TRAVERSE-WORDLIST v4 "Elizabeth D. Rather" <erather@forth.com> - 2012-02-29 06:49 -1000
            Re: RfD: TRAVERSE-WORDLIST v4 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-02-29 20:05 +0000
        Re: RfD: TRAVERSE-WORDLIST v4 BruceMcF <agila61@netscape.net> - 2012-02-28 14:40 -0800
          Re: RfD: TRAVERSE-WORDLIST v4 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-29 15:47 +0000
            Re: RfD: TRAVERSE-WORDLIST v4 BruceMcF <agila61@netscape.net> - 2012-02-29 08:13 -0800
      Re: RfD: TRAVERSE-WORDLIST v4 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-02-29 20:07 +0000
    Re: RfD: TRAVERSE-WORDLIST v4 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-02-29 11:27 +0000
    Re: RfD: TRAVERSE-WORDLIST v4 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-02-29 20:20 +0000
      Re: RfD: TRAVERSE-WORDLIST v4 BruceMcF <agila61@netscape.net> - 2012-02-29 16:44 -0800
        Re: RfD: TRAVERSE-WORDLIST v4 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-03-01 08:45 +0000
          Re: RfD: TRAVERSE-WORDLIST v4 BruceMcF <agila61@netscape.net> - 2012-03-01 16:15 -0800
            Re: RfD: TRAVERSE-WORDLIST v4 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-03-02 09:58 +0000
              Re: RfD: TRAVERSE-WORDLIST v4 BruceMcF <agila61@netscape.net> - 2012-03-02 22:37 -0800
    Re: RfD: TRAVERSE-WORDLIST v4 Alex McDonald <blog@rivadpm.com> - 2012-03-04 14:03 -0800
      Re: RfD: TRAVERSE-WORDLIST v4 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-03-05 13:20 +0000
      Re: RfD: TRAVERSE-WORDLIST v4 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-05 14:18 +0000
    Re: RfD: TRAVERSE-WORDLIST v4 Alex McDonald <blog@rivadpm.com> - 2012-03-27 15:23 -0700

Page 1 of 2  [1] 2  Next page →

#9733 — RfD: TRAVERSE-WORDLIST v4

RfD: traverse-wordlist

v1 20 January 2012, Alex McDonald
v2 24 January 2012, Alex McDonald
v3 03 February 2012, Alex McDonald
v4 28 February 2012, Alex McDonald

Change history:

20120120        First version
20120124        Minor typos, added section "Order of node visits"
                Added to section "Remarks"
20120125        Minor typos, cleanup and added remarks
20120203        Changed order of stack for TRAVERSE-WORDLIST
                to place the xt rightmost.
                Removed return value from TRAVERSE-WORDLIST.
                Changed xt-node halt flag to a continue flag.
                Note that if xt-node modifies the wordlist, the
                results are undefined.
                Specify NAME>... supporting words in section 2.2.
                Tidy up & correction of 4. Remarks
20120228        Section 2.1 and 2.2 moved and renumbered.
                Rename NAME>... to NT>... to more clearly
                indicate a name token rather than a name.
                Tidy up table in section 3. Experience, and
                add note re NT>... names.
                Corrected Bruce McFarling's moniker


1. Problem
----------

There are no standard words in Forth for traversing a wordlist and
obtaining basic information about each node. While standard Forth
provides a great many features for extensibility of the language
(with CREATE ... DOES> being the classic example), standard Forth
lacks the basic capability of traversing the wordlist as a part of
the specification.

Such a capability is needed to provide some kinds of advanced
programming tools. For example, the programmer may want to determine
all instances of word name overlaps in all of the wordlists in the
current search order; or count, display or modify words contained in
a specific wordlist.

Many systems provide the TOOLS word WORDS that provides human-readble
output from the current wordlists in CONTEXT. TRAVERSE-WORDLIST is a
usable factor for the implementation of WORDS.

Wordlist traversal functionality is available through very similar
words in Win32Forth (VOC-ITERATE), VFX (WalkWordList), iForth
(doWORDS), lxf/ntf (WALK-WORDLIST), and ciforth (FOR-WORDS)

2. Proposal
-----------

TRAVERSE-WORDLIST ( x*i wid xt-node -- x'*i ) "traverse-wordlist"

Traverse the wordlist wid, executing xt-node, a user-specified word
with the stack effects

xt-node ( x*i nt -- x'*i u )

without immediately returning to the caller, executing xt-node at
most once for every node in the wordlist, and terminating once all
the nodes have been exhausted or until xt-node returns the continue
flag u with a zero (FALSE) value.

nt is a system-specific name token for the node. The word xt-node can
use this token to display, count, modify or perform any other action
on the node that the system providing nt permits. The format of nt is
undefined, but it is guaranteed to be unique for each word in the
wordlist.

To stop receiving nodes from TRAVERSE-WORDLIST and return to the
caller, xt-node sets u to zero. A non-zero value for u will continue
to invoke xt-node until all the nodes in the wordlist have been
exhausted.

x*i is zero or more stack parameters that are agreed on by the caller
of TRAVERSE-WORDLIST and xt-node. xt-node is free to modify them but
must return the same number of parameters on the stack. For example;

  : WORDS-COUNT ( x nt -- x' u ) DROP 1+ TRUE ;
  0 ' WORDS-COUNT WID TRAVERSE-WORDLIST  . ( count of nodes visited)

returns x', where x' is a count of the total number of nodes in the
wordlist WID. This example works on all systems, regardless of the
system-specific format of nt.

2.1 Opaque NTs
--------------

Since this proposal introduces the concept of an opaque nt (name
token), the following words allow system independent reference to
specific parts of the node.

NT>STRING    ( nt -- addr count ) "name-to-string"
NT>SEMANTICS ( nt -- xte xtc )    "name-to-semantics"

NT>STRING returns the string addr count, the definition name of the
word represented by nt. Case is dependent on the case-sensitivity of
the Forth system (see /DPANS 3.3.1.2 Definition names/).

NT>SEMANTICS returns two xts (execution tokens) as discussed in
/DPANS 3.4.3 Semantics/. xte represents the execution semantics of
the definition; xtc represents the compilation semantics. Where a
definition has no execution semantics (for example, IF), xte may be 0
(zero); the same is true for xtc if there are no compilation
semantics.

2.2 Order of node visits
------------------------

There are a number of orders in which nodes may be visited in a
wordlist, each of which depends on the specific implementation of
wordlists. Although they are often based on hash tables, no
assumptions are made in the ANS Forth specification about internal
implementations.

To conform with this and to simplify implementation of TRAVERSE-
WORDLIST and to allow various techniques to be used for wordlists, no
guarantee is given as to any specific order of node visits to each
word with one exception.

If a wordlist contains duplicate entries, SEARCH-WORDLIST and FIND
for a duplicated name will return the execution token of the last
temporally defined name. For instance

: SAMPLE ... ( 1 ) ;
: TEST ... ;
: RETURNS ... ;
: SAMPLE ... ( 2 ) ;
: SAMPLE ... ( 3 ) ;

defines five words, one of which, SAMPLE, is defined three times.
SEARCH-WORDLIST and FIND will only return the last definition (3).
Whether duplicated nodes are visited or not by TRAVERSE-WORDLIST is
undefined. TRAVERSE-WORDLIST is only obliged to visit the nodes TEST,
RETURNS and SAMPLE (3) from the wordlist, and can do so in any order.

Some systems may permit visiting the node for the second and
subsequent definitions of SAMPLE. Exceptionally in this case,
TRAVERSE-WORDLIST *must* visit multiply defined nodes in the order
newest to oldest (but not necessarily consecutively); that is, SAMPLE
(3) must be returned before (2), and (2) before (1).

The remaining unique nodes can appear in any order, and may be
interspersed between the duplicately named and ordered words. If this
ordering is not possible, then TRAVERSE-WORDLIST should only provide
the latest definition of SAMPLE.

"Invisible" or non-FINDable words can also be created by using the
non-standard and system specific words such as HIDE or SMUDGE, or can
be created but not FINDable until they are REVEALed. Whether these
nodes are visited or not is undefined.

TRAVERSE-WORDLIST is affected by the operation of FORGET or MARKER,
and the results of a traversal *must not* return words that are
unFINDable after execution of FORGET or MARKER. Additionally, any
operation during the execution of xt-node that modifies the structure
of the wordlist (that is, defining words such as : (colon) or CREATE,
or execution of FORGET or MARKER) results in undefined behaviour.

3. Experience
-------------

The wordlist traversal functionality is available through very
similar words in

  Win32Forth    VOC-ITERATE
  VFX           WalkWordList
  iForth        doWORDS
  ciForth       FOR-WORDS
  lxf/ntf       WALK-WORDLIST

System specific words that mimic the functionality of NT>STRING and
NT>SEMANTICS are available on a number of these systems;

  Win32Forth   NT>STRING is >NAME

4. Remarks
----------

Krishna Myneni raised the topic in the comp.lang.forth newsgroup
(http:
//groups.google.com/group/comp.lang.forth/browse_frm/thread/
b5f6ad076607e0b8/0dde8de4c483b9e2#0dde8de4c483b9e2)

Kishna Myneni requested specific orderings. As there are many
possible orderings that may be useful for processing nodes, TRAVERSE-
WORDLIST can be used to support them by, for instance, building a
list during execution of xt-node and sorting the results.

Peter Fälth adds: "My system (lxf/ntf) supports such a word (but with
some differences); my name is WALK-WORDLIST ( xt wid -- ). I have
also a WALK-ALL- WORDLISTS ( xt -- ) that actually is more used I
suggest also to add such a word."

Bruce McFarling requested: that words with multiple definitions are
returned in newest to oldest order. Addressed above, but a use case
and rationale would be useful.

Bruce McFarling and Peter Fälth would prefer that xt-node use a
"halt?"
flag; i.e., to halt on a non-zero return value, rather than on zero.
Due to changes in the TRAVERSE-WORDLIST signature, halt on zero has
been reinstated for xt-node.

Peter Fälth, Anton Ertl and others do not like the nt return value
from TRAVERSE-WORDLIST. It has been removed, and xt-node word can use
one of its agreed parameters to return a flag or last nt.

Stephen Pelc suggested that the stack signature be simplified to
TRAVERSE-WORDLIST ( xt-node wid -- ) with xt-node ( nt -- u ). Bruce
McFarling notes that there is a loss of functionality as xt-node
cannot operate on additional information on the stack; since under
the modified signature, the TRAVERSE-WORDLIST word is free to be
using the stack underneath the nt for its own purposes.

Various discussions on return flag values, the position of the xt on
the stack for TRAVERSE-WORDLIST, the return values have been
addressed.

Bruce McFarling proposes NAME>... here described as NT>... words.

Andrew Haley proposes a completely different mechanism for traversal;
although interesting, it has not been fully explored and is not
explained here.

[toc] | [next] | [standalone]

#9734

Alex McDonald <blog@rivadpm.com> writes:
>RfD: traverse-wordlist

Looks mostly fine to me.  Here are some comments on some details.

>x*i is zero or more stack parameters that are agreed on by the caller
>of TRAVERSE-WORDLIST and xt-node. xt-node is free to modify them but
>must return the same number of parameters on the stack.

Leave this restriction away.  While it is usually a good idea to
program this way, there are exceptions to this rule.  On the
implementation side, I don't see any benefit from this restriction
(i.e., I expect all implementations to work even for unbalanced stack
effects of xt-node.

>  : WORDS-COUNT ( x nt -- x' u ) DROP 1+ TRUE ;
>  0 ' WORDS-COUNT WID TRAVERSE-WORDLIST  . ( count of nodes visited)
>
>returns x', where x' is a count of the total number of nodes in the
>wordlist WID.

This example actually prints the number instead of returning it.

>NT>STRING    ( nt -- addr count ) "name-to-string"
>NT>SEMANTICS ( nt -- xte xtc )    "name-to-semantics"
>
>NT>STRING returns the string addr count, the definition name of the
>word represented by nt. Case is dependent on the case-sensitivity of
>the Forth system (see /DPANS 3.3.1.2 Definition names/).

You should specify the life time of the string, unless you want it to
have unlimited life.

Why?  If all systems have the string in that form in the word header,
NT>STRING can just return that.  But I am worried that there are still
descendents of fig-Forth, which set the top bit in the last character;
such a system (or any other with a funny string representation) would
have to construct the proper string in a buffer, and that buffer would
have a limited life time.  So, are there any systems that store the
name in a way that requires NT>STRING to construct the string in a
buffer?

>NT>SEMANTICS returns two xts (execution tokens) as discussed in
>/DPANS 3.4.3 Semantics/. xte represents the execution semantics of
>the definition; xtc represents the compilation semantics. Where a
>definition has no execution semantics (for example, IF), xte may be 0
>(zero); the same is true for xtc if there are no compilation
>semantics.

This will be pretty expensive to implement in Gforth: we would need to
construct another word representing the compilation semantics for all
words with default compilation semantics (i.e., most words).

Also, what about interpretation semantics?  E.g., S" has no execution
semantics, but the FILE wordset version has interpretation semantics.

>"Invisible" or non-FINDable words can also be created by using the
>non-standard and system specific words such as HIDE or SMUDGE, or can
>be created but not FINDable until they are REVEALed. Whether these
>nodes are visited or not is undefined.

That follows anyway from the fact that the standard says nothing about
non-standard code.

>3. Experience
>-------------
>
>The wordlist traversal functionality is available through very
>similar words in
>
>  Win32Forth    VOC-ITERATE
>  VFX           WalkWordList
>  iForth        doWORDS
>  ciForth       FOR-WORDS
>  lxf/ntf       WALK-WORDLIST
>
>System specific words that mimic the functionality of NT>STRING and
>NT>SEMANTICS are available on a number of these systems;
>
>  Win32Forth   NT>STRING is >NAME

Gforth has:

|`name>int'       nt - xt         gforth       "name-to-int"
|   xt represents the interpretation semantics of the word nt. If nt has
|no interpretation semantics (i.e. is `compile-only'), xt is the
|execution token for `ticking-compile-only-error', which performs `-2048
|throw'.
|
|`name?int'       nt - xt         gforth       "name-question-int"
|   Like `name>int', but perform `-2048 throw' if nt has no
|interpretation semantics.
|
|`name>comp'       nt - w xt         gforth       "name-to-comp"
|   w xt is the compilation token for the word nt.
|
|`name>string'       nt - addr count         gforth       "name-to-string"
|   addr count is the name of the word represented by nt.

- 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 2011: http://www.euroforth.org/ef11/

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

#9738

On Feb 28, 5:18 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Alex McDonald <b...@rivadpm.com> writes:
> >RfD: traverse-wordlist
>
> Looks mostly fine to me.  Here are some comments on some details.
>
> >x*i is zero or more stack parameters that are agreed on by the caller
> >of TRAVERSE-WORDLIST and xt-node. xt-node is free to modify them but
> >must return the same number of parameters on the stack.
>
> Leave this restriction away.  While it is usually a good idea to
> program this way, there are exceptions to this rule.  On the
> implementation side, I don't see any benefit from this restriction
> (i.e., I expect all implementations to work even for unbalanced stack
> effects of xt-node.
>
> >  : WORDS-COUNT ( x nt -- x' u ) DROP 1+ TRUE ;
> >  0 ' WORDS-COUNT WID TRAVERSE-WORDLIST  . ( count of nodes visited)
>
> >returns x', where x' is a count of the total number of nodes in the
> >wordlist WID.

Corrected.

>
> This example actually prints the number instead of returning it.
>
> >NT>STRING    ( nt -- addr count ) "name-to-string"
> >NT>SEMANTICS ( nt -- xte xtc )    "name-to-semantics"
>
> >NT>STRING returns the string addr count, the definition name of the
> >word represented by nt. Case is dependent on the case-sensitivity of
> >the Forth system (see /DPANS 3.3.1.2 Definition names/).
>
> You should specify the life time of the string, unless you want it to
> have unlimited life.
>
> Why?  If all systems have the string in that form in the word header,
> NT>STRING can just return that.  But I am worried that there are still
> descendents of fig-Forth, which set the top bit in the last character;
> such a system (or any other with a funny string representation) would
> have to construct the proper string in a buffer, and that buffer would
> have a limited life time.  So, are there any systems that store the
> name in a way that requires NT>STRING to construct the string in a
> buffer?

Suggested text:

Implementations may choose to point to the string in the word's header
built when the word is defined: point to a static buffer that is
reused on each call; point to a dynamic buffer that is replaced on
each call: or some other method. Whatever technique is used, the
following are required of the string returned by NT>STRING;

. The string is read-only; operations that write to the string are not
permitted.
. Reading outside of the bounds (addr) to (addr+count) is not
permitted.
. The lifetime of the string is only guaranteed up to the next call of
NT>STRING; subsequent calls to NT>STRING must assume that a different
address, length and contents will be returned.

If the string is needed outside of this lifetime, it must be copied to
another buffer.

>
> >NT>SEMANTICS returns two xts (execution tokens) as discussed in
> >/DPANS 3.4.3 Semantics/. xte represents the execution semantics of
> >the definition; xtc represents the compilation semantics. Where a
> >definition has no execution semantics (for example, IF), xte may be 0
> >(zero); the same is true for xtc if there are no compilation
> >semantics.
>
> This will be pretty expensive to implement in Gforth: we would need to
> construct another word representing the compilation semantics for all
> words with default compilation semantics (i.e., most words).
>
> Also, what about interpretation semantics?  E.g., S" has no execution
> semantics, but the FILE wordset version has interpretation semantics.

I'll address with your & Bruce McFarling's elsethread suggestion.

>
> >"Invisible" or non-FINDable words can also be created by using the
> >non-standard and system specific words such as HIDE or SMUDGE, or can
> >be created but not FINDable until they are REVEALed. Whether these
> >nodes are visited or not is undefined.
>
> That follows anyway from the fact that the standard says nothing about
> non-standard code.
>

Agreed & removed.

>
>
>
>
>
>
>
>
> >3. Experience
> >-------------
>
> >The wordlist traversal functionality is available through very
> >similar words in
>
> >  Win32Forth    VOC-ITERATE
> >  VFX           WalkWordList
> >  iForth        doWORDS
> >  ciForth       FOR-WORDS
> >  lxf/ntf       WALK-WORDLIST
>
> >System specific words that mimic the functionality of NT>STRING and
> >NT>SEMANTICS are available on a number of these systems;
>
> >  Win32Forth   NT>STRING is >NAME
>
> Gforth has:
>
> |`name>int'       nt - xt         gforth       "name-to-int"
> |   xt represents the interpretation semantics of the word nt. If nt has
> |no interpretation semantics (i.e. is `compile-only'), xt is the
> |execution token for `ticking-compile-only-error', which performs `-2048
> |throw'.
> |
> |`name?int'       nt - xt         gforth       "name-question-int"
> |   Like `name>int', but perform `-2048 throw' if nt has no
> |interpretation semantics.
> |
> |`name>comp'       nt - w xt         gforth       "name-to-comp"
> |   w xt is the compilation token for the word nt.
> |
> |`name>string'       nt - addr count         gforth       "name-to-string"
> |   addr count is the name of the word represented by nt.
>
> - 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 2011:http://www.euroforth.org/ef11/

Thanks for the review.

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

#9739

On 2/28/12 11:54 AM, Alex McDonald wrote:
> Suggested text:
>
> Implementations may choose to point to the string in the word's header
> built when the word is defined: point to a static buffer that is
> reused on each call; point to a dynamic buffer that is replaced on
> each call: or some other method. Whatever technique is used, the
> following are required of the string returned by NT>STRING;
>
> . The string is read-only; operations that write to the string are not
> permitted.
> . Reading outside of the bounds (addr) to (addr+count) is not
> permitted.
> . The lifetime of the string is only guaranteed up to the next call of
> NT>STRING; subsequent calls to NT>STRING must assume that a different
> address, length and contents will be returned.
>
> If the string is needed outside of this lifetime, it must be copied to
> another buffer.

Discussions such as most of the first paragraph should be in the 
Rationale to this section, IMO. The Normative text shouldn't discuss, 
recommend, or offer options, but instead should concentrate on rules.

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]

#9749

"Elizabeth D. Rather" <erather@forth.com> writes:
>Discussions such as most of the first paragraph should be in the 
>Rationale to this section, IMO. The Normative text shouldn't discuss, 
>recommend, or offer options, but instead should concentrate on rules.

While it would be nice to be able to just copy the proposal text into
the standard when the proposal is voted into the standard, this is by
no means necessary.  It's sufficient if the proposal is clear,
unambiguous, and understandable, and during the RfD phase we should at
first work out the content before we concern ourselves with details of
wording.

- 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 2011: http://www.euroforth.org/ef11/

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

#9752

On 2/29/12 5:42 AM, Anton Ertl wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> Discussions such as most of the first paragraph should be in the
>> Rationale to this section, IMO. The Normative text shouldn't discuss,
>> recommend, or offer options, but instead should concentrate on rules.
>
> While it would be nice to be able to just copy the proposal text into
> the standard when the proposal is voted into the standard, this is by
> no means necessary.  It's sufficient if the proposal is clear,
> unambiguous, and understandable, and during the RfD phase we should at
> first work out the content before we concern ourselves with details of
> wording.
>
> - anton

Certainly true, but it's nice when the proposal is helpful in the way it 
words things and factors normative from rationale text. Just a tip for 
proposal writers.

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]

#9755

On Wed, 29 Feb 2012 15:42:44 -0000, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:

> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Discussions such as most of the first paragraph should be in the
>> Rationale to this section, IMO. The Normative text shouldn't discuss,
>> recommend, or offer options, but instead should concentrate on rules.
>
> While it would be nice to be able to just copy the proposal text into
> the standard when the proposal is voted into the standard, this is by
> no means necessary.  It's sufficient if the proposal is clear,
> unambiguous, and understandable, and during the RfD phase we should at
> first work out the content before we concern ourselves with details of
> wording.

It has never happened yet.  Most people simply ignore the rational and  
expect the editor to magic up something.

-- 
Peter Knaggs

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

#9740

On Feb 28, 4:54 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Feb 28, 5:18 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:

>>>NT>SEMANTICS returns two xts (execution tokens) as discussed in
>>>/DPANS 3.4.3 Semantics/. xte represents the execution semantics of
>>>the definition; xtc represents the compilation semantics. Where a
>>>definition has no execution semantics (for example, IF), xte may be 0
>>>(zero); the same is true for xtc if there are no compilation
>>>semantics.

>> This will be pretty expensive to implement in Gforth: we would need
>> to construct another word representing the compilation semantics for
>> all words with default compilation semantics (i.e., most words).

>> Also, what about interpretation semantics?  E.g., S" has no execution
>> semantics, but the FILE wordset version has interpretation semantics.

> I'll address with your & Bruce McFarling's elsethread suggestion.

Which suggestion was this? I recall floating two:

(1) a single word returning ( xti xtc ) where:
   xti ( x*i -- x*j ), and xtc ( xti -- )

(2) two words,
 NT>INTERPRET ( xt )
 NT>COMPILE ( x xt ) ... where xt take ( x ) as a parameter.

I only look into simple implementations for small systems, but as
Anton notes for gforth, an atomic compilation xt is expensive on
those, while an xt that takes a single stack parameter allows either
the xt for EXECUTE or for COMPILE, to be returned as the xtc in most
cases.

Both of the suggestions I floated were oriented to that, and I'd be
equally happy with either, so I'm happy with implementers of more
complex systems specifying which approach is more appealing to them.

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

#9750

BruceMcF <agila61@netscape.net> writes:
>(1) a single word returning ( xti xtc ) where:
>   xti ( x*i -- x*j ), and xtc ( xti -- )

xtc would be ( i*x xti -- j*x ), no?  E.g., THEN has a non-null stack
effect during compilation.

This would not fit Gforth, in particular not INTERPRET/COMPILE:
words, because INTERPET/COMPILE: takes two xts, but the
xt representing compilation-semantics does not take an xti.

>(2) two words,
> NT>INTERPRET ( xt )
> NT>COMPILE ( x xt ) ... where xt take ( x ) as a parameter.

This fits Gforth (and Gforth has these words under a different name).
For

xt1 xt2 INTERPRET/COMPILE: foo

NAME>INT (NT>INTERPRET) produces xt1
NAME>COMP (NT>COMPILE)  produces xt2 ' EXECUTE

- 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 2011: http://www.euroforth.org/ef11/

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

#9751

On Feb 29, 10:47 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

>>(2) two words,
>> NT>INTERPRET ( xt )
>> NT>COMPILE ( x xt ) ... where xt take ( x ) as a parameter.

> This fits Gforth (and Gforth has these words under a different name).
> For

> xt1 xt2 INTERPRET/COMPILE: foo

> NAME>INT (NT>INTERPRET) produces xt1
> NAME>COMP (NT>COMPILE)  produces xt2 ' EXECUTE

Works for me. I'm agnostic on the naming.

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

#9756

Anton Ertl wrote:
>
> Why?  If all systems have the string in that form in the word header,
> NT>STRING can just return that.  But I am worried that there are still
> descendents of fig-Forth, which set the top bit in the last character;
> such a system (or any other with a funny string representation) would
> have to construct the proper string in a buffer, and that buffer would
> have a limited life time.  So, are there any systems that store the
> name in a way that requires NT>STRING to construct the string in a
> buffer?

Yes.  My new system stores the name outside of the memory module.
I would need to copy the string into the Forth memory.

-- 
Peter Knaggs

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

#9747

In article <3a561970-391e-4f30-8dc8-049d5942f159@gi10g2000vbb.googlegroups.com>,
Alex McDonald  <blog@rivadpm.com> wrote:
<SNIP>
>
>2. Proposal
>-----------
>
>TRAVERSE-WORDLIST ( x*i wid xt-node -- x'*i ) "traverse-wordlist"
>
>Traverse the wordlist wid, executing xt-node, a user-specified word
>with the stack effects
>
>xt-node ( x*i nt -- x'*i u )
>
<SNIP>
>
>x*i is zero or more stack parameters that are agreed on by the caller
>of TRAVERSE-WORDLIST and xt-node. xt-node is free to modify them but
>must return the same number of parameters on the stack. For example;

I don't see the need to require that the same number of parameters
is one the stack. This can be left up to xt-node.

For example my WORDS looks like
: NOOP ;
: WORDS    0   'NOOP   CONTEXT   @   FOR-WORDS
    ( all dea's on the stack now)
    BEGIN DUP  WHILE ID. REPEAT   DROP ;

This will display the most recent words in the most visible area.

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]

#9758

Alex McDonald wrote:

> TRAVERSE-WORDLIST ( x*i wid xt-node -- x'*i ) "traverse-wordlist"

Do you really mean x*i and x'*i, in which case this is more normally  
described as x*i and x*j where i and j *may* be equal.  The text goes on  
to say that x = x' in which case this should be x*i and x*i.  The prime  
decoration is not described in the section on stack notations, if you wish  
to keep the x' notation, you must provide a description of its meaning.

There is no standard notation for decorating an xt, thus "xt-node" has no  
meaning at the moment.  You should either provide some text to describe  
the stack notation or replace this with the standard stack notation "xt"  
and explain the restrictions on the xt in the body of the definition, as  
you currently do.

> 2.1 Opaque NTs

The opaque NT data type will need to be added to the data type section.

-- 
Peter Knaggs

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

#9762

On Feb 29, 3:20 pm, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> Alex McDonald wrote:
> > TRAVERSE-WORDLIST ( x*i wid xt-node -- x'*i ) "traverse-wordlist"

> Do you really mean x*i and x'*i, in which case this is more normally
> described as x*i and x*j where i and j *may* be equal. The text goes
> on to say that x = x' in which case this should be x*i and x*i.

I don't think it's intending to say that x=x', I think its intending
to say i=j, so:
   ( x*i ... -- x'*i ... )

... is trying to convey that the parameters can change, even though
the depth cannot ... since:
   ( x*i ... -- x*i ... )

... would imply that the stack parameters are not modified.

*HOWEVER* even though changing the stack depth may in many cases not
be good practice, I don't think the standard should specify that. An
advisory section might note that normally i=j should apply unless
there is an overriding reason to do differently.

So I think it should be amended to:
   ( x*i ... -- x*j ... )

... and drop the prescription that, in effect, i=j though it is
permitted for:
   {x:x_1;x_i}=/={x:x_1;x_j)

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

#9766

BruceMcF wrote:

> On Feb 29, 3:20 pm, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>> Alex McDonald wrote:
>> > TRAVERSE-WORDLIST ( x*i wid xt-node -- x'*i ) "traverse-wordlist"
>
>> Do you really mean x*i and x'*i, in which case this is more normally
>> described as x*i and x*j where i and j *may* be equal. The text goes
>> on to say that x = x' in which case this should be x*i and x*i.
>
> I don't think it's intending to say that x=x', I think its intending
> to say i=j, so:
>    ( x*i ... -- x'*i ... )

Of course.

> ... is trying to convey that the parameters can change, even though
> the depth cannot ... since:
>    ( x*i ... -- x*i ... )
>
> ... would imply that the stack parameters are not modified.

No.  If that where the case they simply would not be part of the stack  
description at all.  The fact that they are in the description means they  
may change and that the definition should explain how.

> *HOWEVER* even though changing the stack depth may in many cases not
> be good practice, I don't think the standard should specify that. An
> advisory section might note that normally i=j should apply unless
> there is an overriding reason to do differently.

Agreed.

> So I think it should be amended to:
>    ( x*i ... -- x*j ... )

Agreed.

-- 
Peter Knaggs

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

#9777

This is a side issue, since I do not think that i=j should be
incorporated into the standard, except possibly as advice, but ...

On Mar 1, 3:45 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>> ... is trying to convey that the parameters can change, even though
>> the depth cannot ... since:
>>    ( x*i ... -- x*i ... )

>> ... would imply that the stack parameters are not modified.
>
> No. If that where the case they simply would not be part of the
> stack description at all.  The fact that they are in the description
> means they may change and that the definition should explain how.

In all the stack pictures I can recall off the top of my head with the
identical stack reference in the input and output side, they are
unmodified. If they are modifieable, that is indicated by, eg:
   ( ca1 -- ca2 )

Its possible to have a class of xt's that refer to information on the
stack without modifying it. In that case, not referring to that data
that is referred to but not modified would seem to permit an
implementation to call the xt with something on the stack underneath
the specified:
   ( nt -- u )

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

#9781

On Fri, 02 Mar 2012 00:15:27 -0000, BruceMcF <agila61@netscape.net> wrote:

> This is a side issue, since I do not think that i=j should be
> incorporated into the standard, except possibly as advice, but ...
>
> On Mar 1, 3:45 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>>> ... is trying to convey that the parameters can change, even though
>>> the depth cannot ... since:
>>>    ( x*i ... -- x*i ... )
>
>>> ... would imply that the stack parameters are not modified.
>>
>> No. If that where the case they simply would not be part of the
>> stack description at all.  The fact that they are in the description
>> means they may change and that the definition should explain how.
>
> In all the stack pictures I can recall off the top of my head with the
> identical stack reference in the input and output side, they are
> unmodified. If they are modifieable, that is indicated by, eg:
>    ( ca1 -- ca2 )
>
> Its possible to have a class of xt's that refer to information on the
> stack without modifying it. In that case, not referring to that data
> that is referred to but not modified would seem to permit an
> implementation to call the xt with something on the stack underneath
> the specified:
>    ( nt -- u )

Yes.

-- 
Peter Knaggs

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

#9794

However, given existing practice, it seems the clearest way to express
that an xt can muck around with the x's but cannot change the depth
would be:
   xt1: ( x*i nt -- x*j u ) ... "where i=j," ...

... so that:
   xt2: ( x*i x1 -- x*i x2 )

... is read as signifying that xt2 may read but not modify values in
x*i.

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

#9852

On Feb 28, 1:14 pm, Alex McDonald <b...@rivadpm.com> wrote:

[snip]

>
> 2. Proposal
> -----------
>
> TRAVERSE-WORDLIST ( x*i wid xt-node -- x'*i ) "traverse-wordlist"
>
> Traverse the wordlist wid, executing xt-node, a user-specified word
> with the stack effects
>
> xt-node ( x*i nt -- x'*i u )
>
> without immediately returning to the caller, executing xt-node at
> most once for every node in the wordlist, and terminating once all
> the nodes have been exhausted or until xt-node returns the continue
> flag u with a zero (FALSE) value.
>
> nt is a system-specific name token for the node. The word xt-node can
> use this token to display, count, modify or perform any other action
> on the node that the system providing nt permits. The format of nt is
> undefined, but it is guaranteed to be unique for each word in the
> wordlist.
>
> To stop receiving nodes from TRAVERSE-WORDLIST and return to the
> caller, xt-node sets u to zero. A non-zero value for u will continue
> to invoke xt-node until all the nodes in the wordlist have been
> exhausted.
>
> x*i is zero or more stack parameters that are agreed on by the caller
> of TRAVERSE-WORDLIST and xt-node. xt-node is free to modify them but
> must return the same number of parameters on the stack. For example;
>


[snip]

Focusing on the stack effects, can I get some feedback on this
proposed change. I've tried to take account of the comments made so
far.

----

...


2. Proposal
-----------

TRAVERSE-WORDLIST ( wid xt -- x*j ) "traverse-wordlist" TOOLS-EXT

Remove wid and xt from the stack. Traverse the wordlist wid,
executing xt, a user-specified word with the stack effect
( nt -- x*i u ) without immediately returning to the caller,
executing xt at most once for every node in the wordlist, and
terminating once all the nodes have been exhausted or until xt
returns the continue flag u with a zero (FALSE) value.

An invocation of the xt with the stack diagram ( x*i nt -- x*j u )
must subsequently invoke xt with the stack diagram ( x*j nt ).
TRAVERSE-WORDLIST returns x*j from the last execution, if any, of the
xt.

nt is a system-specific name token for the node. The xt can use this
token to display, count, modify or perform any other action on the
node that the system providing nt permits. The format of nt is
undefined, but it is guaranteed to be unique for each word in the
wordlist.

To stop receiving nodes from TRAVERSE-WORDLIST and return to the
caller, xt sets u to zero. A non-zero value for u will continue
to invoke the xt until all the nodes in the wordlist have been
exhausted.

...

3. Rationale
------------

...

3.3 Use of the stack by TRAVERSE-WORDLIST
-----------------------------------------

TRAVERSE-WORDLIST is not permitted to maintain control information
for the traversal on the data stack. This is to permit parameters
beyond the nt to be passed to xt-node. For instance, the caller may
wish to maintain a count of nodes visited on the stack.

...

----

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

#9859

Alex McDonald wrote:
>
> 2. Proposal
> -----------
>
> TRAVERSE-WORDLIST ( wid xt -- x*j ) "traverse-wordlist" TOOLS-EXT
>
> Remove wid and xt from the stack. Traverse the wordlist wid,
> executing xt, a user-specified word with the stack effect
> ( nt -- x*i u ) without immediately returning to the caller,
> executing xt at most once for every node in the wordlist, and
> terminating once all the nodes have been exhausted or until xt
> returns the continue flag u with a zero (FALSE) value.
>
> An invocation of the xt with the stack diagram ( x*i nt -- x*j u )
> must subsequently invoke xt with the stack diagram ( x*j nt ).
> TRAVERSE-WORDLIST returns x*j from the last execution, if any, of the
> xt.
>
> nt is a system-specific name token for the node. The xt can use this
> token to display, count, modify or perform any other action on the
> node that the system providing nt permits. The format of nt is
> undefined, but it is guaranteed to be unique for each word in the
> wordlist.
>
> To stop receiving nodes from TRAVERSE-WORDLIST and return to the
> caller, xt sets u to zero. A non-zero value for u will continue
> to invoke the xt until all the nodes in the wordlist have been
> exhausted.

The tradition is to refer to "the execution semantics of xt given below."

And provide a section:

xt execution: ( x*i nt -- x*j u )
   nt is an implementation dependent name token ...



-- 
Peter Knaggs

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web