RFD: Legacy Wordset

10 views
Skip to first unread message

Peter Knaggs

unread,
Aug 23, 2009, 12:40:52 PM8/23/09
to
At the Vienna meeting it was decided that the "Obsolete" word marked in
section 1.4.2 namely #TIB, CONVERT, EXPECT, FORGET, QUERY, SPAN and TIB
should be removed from the CORE-EXT and TOOLS-EXT word sets and placed
into a new word set of there own, the Legacy word set.

The new chapter (word set) complete with introduction can be found at:

http://www.rigwit.co.uk/forth/legacy-09-2.pdf

Elizabeth D Rather

unread,
Aug 23, 2009, 10:18:59 PM8/23/09
to

The intent of the Forth94 TC was that in the next standard these words
should go away altogether, and indeed, in what was intended to be the
start of the next round, a meeting at NASA-GSFC in 1999, the TC voted to
discard them.

IMO retaining these words in a "Legacy" wordset will have the
undesirable effect of perpetuating them. The world has been warned for
15 years that they were going away; just say "goodbye"!

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

Stephen Pelc

unread,
Aug 24, 2009, 6:15:48 AM8/24/09
to
On Sun, 23 Aug 2009 16:18:59 -1000, Elizabeth D Rather
<era...@forth.com> wrote:

>The intent of the Forth94 TC was that in the next standard these words
>should go away altogether, and indeed, in what was intended to be the
>start of the next round, a meeting at NASA-GSFC in 1999, the TC voted to
>discard them.
>
>IMO retaining these words in a "Legacy" wordset will have the
>undesirable effect of perpetuating them. The world has been warned for
>15 years that they were going away; just say "goodbye"!

The law of unintended consequences still applies! You know that some
client with a code base evolving over 25 years still hasn't removed
even older FIG-isms. Without this warning, some hotshot will write a
library that reuses these names and breaks later code. The Forth200x
approach in this instance is to minimise surprises.

That hotshots neither read nor write documentation is another
matter altogether.

Stephen


--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Howerd

unread,
Aug 24, 2009, 8:29:10 AM8/24/09
to
Hi Elizabeth,

Oops - I must have missed the warning - I've just added a target
version of QUIT to MSP430 SwiftX which uses some of these legacy
words.
Are there new words that have the same functionality. and if so, is
there a reference implementation?

Regards

Howerd


On 24 Aug, 03:18, Elizabeth D Rather <erat...@forth.com> wrote:
> Peter Knaggs wrote:
> > At the Vienna meeting it was decided that the "Obsolete" word marked in
> > section 1.4.2 namely #TIB, CONVERT, EXPECT, FORGET, QUERY, SPAN and TIB
> > should be removed from the CORE-EXT and TOOLS-EXT word sets and placed
> > into a new word set of there own, the Legacy word set.
>

...

Bernd Paysan

unread,
Aug 24, 2009, 9:42:55 AM8/24/09
to
Elizabeth D Rather wrote:
> The intent of the Forth94 TC was that in the next standard these words
> should go away altogether, and indeed, in what was intended to be the
> start of the next round, a meeting at NASA-GSFC in 1999, the TC voted to
> discard them.
>
> IMO retaining these words in a "Legacy" wordset will have the
> undesirable effect of perpetuating them. The world has been warned for
> 15 years that they were going away; just say "goodbye"!

The purpose of the "legacy" wordset is to tell people that words with that
name were in use, and maybe still are in use. E.g. if I write a library,
and choose that "EXPECT" is a good word for defining patterns in a form
editor (like s" [0-9]*" EXPECT will read in only digit strings), I'm warned
that other people might already be using these words. And when I'm
implementing a Forth, and are about to implement EXPECT, because I remember
having it seen in Starting Forth, I'm discouraged.

I think the text here

"They have been grouped together into the legacy word set as although
obsolete these words are still to be found in widespread use in legacy
code."

is a bit too positive and encouraging. IMHO it's more that we want to
document these legacy words, because despite we discourage use in
implementations and applications, people still may want to keep them for
backward compatibility reasons, and so the names are not free to use.

I'd rather put it into the informal appendix. The legacy words should not
be part of the formal standard document.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Peter Knaggs

unread,
Aug 24, 2009, 1:08:40 PM8/24/09
to
Bernd Paysan wrote:
>
> The purpose of the "legacy" wordset is to tell people that words with that
> name were in use, and maybe still are in use. E.g. if I write a library,
> and choose that "EXPECT" is a good word for defining patterns in a form
> editor (like s" [0-9]*" EXPECT will read in only digit strings), I'm warned
> that other people might already be using these words. And when I'm
> implementing a Forth, and are about to implement EXPECT, because I remember
> having it seen in Starting Forth, I'm discouraged.
>
> I think the text here
>
> "They have been grouped together into the legacy word set as although
> obsolete these words are still to be found in widespread use in legacy
> code."
>
> is a bit too positive and encouraging. IMHO it's more that we want to
> document these legacy words, because despite we discourage use in
> implementations and applications, people still may want to keep them for
> backward compatibility reasons, and so the names are not free to use.

I also want to cover the case, when somebody who is new to Forth is
reading through old code, which may use these words. Such a person
would need to dig out the old fig-FORTH standard. By including the
definitions here we ease their pain. As this proposal has not been
through the RfD/CfV process, I am open to suggestions.

> I'd rather put it into the informal appendix. The legacy words should not
> be part of the formal standard document.

Personally, I would agree, but the vote at the last meeting wanted it
normative. Again this is something we could ask the group to vote on.

--
Peter Knaggs

Elizabeth D Rather

unread,
Aug 24, 2009, 1:26:11 PM8/24/09
to
Stephen Pelc wrote:
> On Sun, 23 Aug 2009 16:18:59 -1000, Elizabeth D Rather
> <era...@forth.com> wrote:
>
>> The intent of the Forth94 TC was that in the next standard these words
>> should go away altogether, and indeed, in what was intended to be the
>> start of the next round, a meeting at NASA-GSFC in 1999, the TC voted to
>> discard them.
>>
>> IMO retaining these words in a "Legacy" wordset will have the
>> undesirable effect of perpetuating them. The world has been warned for
>> 15 years that they were going away; just say "goodbye"!
>
> The law of unintended consequences still applies! You know that some
> client with a code base evolving over 25 years still hasn't removed
> even older FIG-isms. Without this warning, some hotshot will write a
> library that reuses these names and breaks later code. The Forth200x
> approach in this instance is to minimise surprises.
>
> That hotshots neither read nor write documentation is another
> matter altogether.

The policy of other language TCs is to remove words after one cycle of
warnings. Since ANSI requires reaffirmation or revision every five
years that could be a fairly short period. We modeled the whole
"obsolescent" approach on common standards practice.

People maintaining a long-term code base (and God knows we love 'em)
should track standards changes as well as other changes that affect
them. Yes, standards bodies need to try to minimize their pain, but
when the serious decision is made to declare something "obsolescent"
that is intended as an aggressive notice that this feature has a problem
and needs to go.

So long as a legacy application continues to use its legacy underlying
system, there shouldn't be a problem. If the app wishes to retain
portability, it needs to follow the standard, including abandoning
deprecated words.

Declaring a word "obsolescent" is not done trivially, because a word is
"out of fashion", but because it has some serious unresolved
side-effects or issues that the standard is trying to resolve. In the
case of most of these, the problem is that people were trying to
manipulate the input stream in ways that, although they worked on some
implementations, were disastrous on others. Rendering the input stream
more "opaque" preserved most of the basic capability while protecting
against the worst side-effects.

FORGET has already been discussed here exhaustively.

Elizabeth D Rather

unread,
Aug 24, 2009, 1:51:07 PM8/24/09
to
Howerd wrote:
> Hi Elizabeth,
>
> Oops - I must have missed the warning - I've just added a target
> version of QUIT to MSP430 SwiftX which uses some of these legacy
> words.
> Are there new words that have the same functionality. and if so, is
> there a reference implementation?
>
> Regards
>
> Howerd

Direct manipulation of the input stream pointers is discouraged. SOURCE
returns the address and length of the input stream (replacing TIB, #TIB,
and SPAN). SAVE-INPUT and RESTORE-INPUT let you temporarily redirect
it. CONVERT is superseded by >NUMBER. EXPECT is superseded by ACCEPT.
FORGET is superseded by MARKER. The function of QUERY may be performed
with ACCEPT and EVALUATE.

SwiftX Pro includes a target-resident interpreter.

Cheers,
Elizabeth

> On 24 Aug, 03:18, Elizabeth D Rather <erat...@forth.com> wrote:
>> Peter Knaggs wrote:
>>> At the Vienna meeting it was decided that the "Obsolete" word marked in
>>> section 1.4.2 namely #TIB, CONVERT, EXPECT, FORGET, QUERY, SPAN and TIB
>>> should be removed from the CORE-EXT and TOOLS-EXT word sets and placed
>>> into a new word set of there own, the Legacy word set.
> ...
>> The intent of the Forth94 TC was that in the next standard these words
>> should go away altogether, and indeed, in what was intended to be the
>> start of the next round, a meeting at NASA-GSFC in 1999, the TC voted to
>> discard them.
>>
>> IMO retaining these words in a "Legacy" wordset will have the
>> undesirable effect of perpetuating them. The world has been warned for
>> 15 years that they were going away; just say "goodbye"!
>

Elizabeth D Rather

unread,
Aug 24, 2009, 1:54:51 PM8/24/09
to

Describing them in an appendix, such as Bernd suggests, would satisfy
that purpose without encouraging people to perpetuate them.

alextangent

unread,
Aug 25, 2009, 12:39:54 PM8/25/09
to

I suppose it's too much to ask that [COMPILE] be added to the list?

--
Regards
Alex McDonald

Peter Knaggs

unread,
Aug 25, 2009, 1:09:04 PM8/25/09
to

This was the list of words which where marked as obsolete in the '94
document. If you would like to suggest we obsolete [COMPILE] in the new
standard, please make your argument.

--
Peter Knaggs

Anton Ertl

unread,
Aug 25, 2009, 1:03:35 PM8/25/09
to
Peter Knaggs <p...@bcs.org.uk> writes:

>alextangent wrote:
>> I suppose it's too much to ask that [COMPILE] be added to the list?
>
>This was the list of words which where marked as obsolete in the '94
>document. If you would like to suggest we obsolete [COMPILE] in the new
>standard, please make your argument.

There is no way to determine if a word has "other than default
compilation semantics". OTOH, we know it for standard words, and for
words defined in standard ways, so if [COMPILE] does not work as
advertised for words defined in non-standard ways, that's not really a
problem for the standard (standard programs will still work on
standard systems).

FIND is a bigger problem IMO: no well-defined behaviour even for
standard programs and a stone-age interface.

But we can discuss if there are any problematic words that we might
want to obsolete some time in the future during the Forth200x meeting;
we should provide well-defined replacements, though.

- 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 2009: http://www.euroforth.org/ef09/

Albert van der Horst

unread,
Aug 26, 2009, 6:12:35 AM8/26/09
to
In article <2009Aug2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Peter Knaggs <p...@bcs.org.uk> writes:
>>alextangent wrote:
>>> I suppose it's too much to ask that [COMPILE] be added to the list?
>>
>>This was the list of words which where marked as obsolete in the '94
>>document. If you would like to suggest we obsolete [COMPILE] in the new
>>standard, please make your argument.
>
>There is no way to determine if a word has "other than default
>compilation semantics". OTOH, we know it for standard words, and for
>words defined in standard ways, so if [COMPILE] does not work as
>advertised for words defined in non-standard ways, that's not really a
>problem for the standard (standard programs will still work on
>standard systems).
>
>FIND is a bigger problem IMO: no well-defined behaviour even for
>standard programs and a stone-age interface.

I'm sure a lot of people want to get rid of FIND and its companion
WORD.

This is the best I could come up with

worddoc( {DICTIONARY},{FOUND},{found},{sc --- dea},{},
{ Look up the string forthvar({sc}) in the dictionary observing
the current search order. If found, leave the dictionary
entry address forthvar({dea}) of the first entry found, else
leave a forthdefin({nil pointer}). },

(sc is an (addr,len) pair )

Its companion is PARSE-NAME that it is already there.

Without the notion of a ``dictionary entry address'' there
is no general way to arrive at other properties of a word
than the execution token (such as its name, or whether it is
immediate). In other words, currently Forth in general has no
canonical way of presenting the result of a dictionary search. It
is hard to solve this without committing to a certain
implementation model.

I'm not sure whether returning zero for ``no result'' has
a precedent, but it is mucho baaje convenient.

<SNIP>

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

Anton Ertl

unread,
Aug 26, 2009, 9:21:15 AM8/26/09
to
Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>In article <2009Aug2...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>FIND is a bigger problem IMO: no well-defined behaviour even for
>>standard programs and a stone-age interface.
>
>I'm sure a lot of people want to get rid of FIND and its companion
>WORD.

WORD does not have problems like FIND, it's just not very useful. As
such it should be moved to Core Ext. Or maybe the idea of a legacy
wordset would be good for words like WORD (whereas words with problems
are obsolete, not legacy).

>This is the best I could come up with
>
>worddoc( {DICTIONARY},{FOUND},{found},{sc --- dea},{},
>{ Look up the string forthvar({sc}) in the dictionary observing
>the current search order. If found, leave the dictionary
>entry address forthvar({dea}) of the first entry found, else
>leave a forthdefin({nil pointer}). },

Maybe you should present that in formatted form rather than source
form. I guess the word name is FOUND, though.

Yes, something like that plus additional words for dealing with deas
(or name tokens, as they are called in Gforth). The words in Gforth
for that are:

http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Name-token.html

The only problem with that is that it does not fit implementations
that use several name entries to represent interpretation and
compilation semantics. But since AFAIK no widely used system uses
these implementation techniques, maybe we should just go ahead with
this stuff.

Anton Ertl

unread,
Aug 26, 2009, 9:30:45 AM8/26/09
to
Peter Knaggs <p...@bcs.org.uk> writes:
>I also want to cover the case, when somebody who is new to Forth is
>reading through old code, which may use these words. Such a person
>would need to dig out the old fig-FORTH standard.

No, for these particular words they would just have to dig out the
Forth-94 standard.

If the old code is written for a Fig-Forth-based system, they should
definitely read the Fig-Forth manual rather than Forth 200x or
Forth-94, because the Forth-83 fault line is between that code and
these standards.

I am also not sure if someone who is new to Forth would try to
understand programs (old or new) by reading the standard document.

>By including the
>definitions here we ease their pain.

I think this is such an uncommon case that I am not sure if it's
worthwhile to make the standard bigger for it.

>As this proposal has not been
>through the RfD/CfV process, I am open to suggestions.

IMO just listing the names and the last standard in which each name
was included is enough.

The purposes I envision for this are:

1) A new system implementor shouldn't accidentially use one of these
names for a system-specific word.

2) Future proponents (of standard extensions) shouldn't accidentially
use one of these names for a new proposed standard word.

>> I'd rather put it into the informal appendix. The legacy words should not
>> be part of the formal standard document.
>
>Personally, I would agree, but the vote at the last meeting wanted it
>normative. Again this is something we could ask the group to vote on.

If we want to force purpose 1 above (as far as a standard can force
such things), we should make it normative and require Forth-94
semantics for these words if they are implemented (either by
referencing Forth-94 or by directly including the text).

However, I am not convinced that it is necessary to try to force this.
Moreover, I am convinced that checking for these words in a test suite
is more effective than the difference between normative and
informative sections in the document.

Elizabeth D Rather

unread,
Aug 26, 2009, 2:44:27 PM8/26/09
to
I completely agree with all this, except that I feel strongly that
including them in any normative section will encourage folks to
perpetuate them.

Cheers,
Elizabeth


--

Jonah Thomas

unread,
Aug 26, 2009, 4:08:02 PM8/26/09
to
Elizabeth D Rather <era...@forth.com> wrote:

> I completely agree with all this, except that I feel strongly that
> including them in any normative section will encourage folks to
> perpetuate them.

So if it's not normative, you're giving people a list of words that some
Forth systems used to use, and you're warning them that if they re-use
those names they might run into name clashes.

But if it is normative, you're giving people a list of words that are
not actually standard words, and you're requiring that they.... What?

Non-normative sounds quite appropriate to me at this point.

Sp...@controlq.com

unread,
Aug 26, 2009, 8:21:24 PM8/26/09
to
On Wed, 26 Aug 2009, Elizabeth D Rather wrote:

> Date: Wed, 26 Aug 2009 08:44:27 -1000
> From: Elizabeth D Rather <era...@forth.com>
> Newsgroups: comp.lang.forth
> Subject: Re: RFD: Legacy Wordset


>
> I completely agree with all this, except that I feel strongly that including
> them in any normative section will encourage folks to perpetuate them.
>
> Cheers,
> Elizabeth

Why not simply change the name from "Legacy" to "Deprecated" wordset?

The connotation is different, and when I read that an interface is
deprecated, I think twice before I use it. I might still use it, but at
least I rationalize exactly why I would, and more often than not, I'd find
the alternative.

Rob Sciuk

Duke Normandin

unread,
Aug 27, 2009, 8:47:55 AM8/27/09
to

I agree! I second your proposal!
--
duke

Elizabeth D Rather

unread,
Aug 27, 2009, 9:18:53 AM8/27/09
to

Better still, we could add a requirement that executing any of these
words would generate a message saying, "This system is using hopelessly
obsolete and deprecated words, and should be updated immediately."

Nah, better to take them out of the normative section altogether. A
note regarding this is appropriate for the Appendix describing changes
from Forth94 (there *will* be one, yes?).

Cheers,
Elizabeth

Jerry Avins

unread,
Mar 11, 2010, 8:22:10 PM3/11/10
to

_Their_ own?

Jerry
--
Why am I in a handbasket? Where are we going?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Bruce McFarling

unread,
Mar 11, 2010, 9:25:31 PM3/11/10
to
On Mar 11, 8:22 pm, Jerry Avins <j...@ieee.org> wrote:
> Peter Knaggs wrote:
> > At the Vienna meeting it was decided that the "Obsolete" word marked in
> > section 1.4.2 namely #TIB, CONVERT, EXPECT, FORGET, QUERY, SPAN and TIB
> > should be removed from the CORE-EXT and TOOLS-EXT word sets and placed
> > into a new word set of there own, the Legacy word set.

> > The new chapter (word set) complete with introduction can be found at:
> >    http://www.rigwit.co.uk/forth/legacy-09-2.pdf

> _Their_ own?

I missed this discussion entirely.

I agree with Ms. Rather, there should not be any definitions in the
glossary of the wordset proper.

There is a procedural rationale for a "Legacy" or "Deprecated"
wordset. In its normative section, it should simply state that the
following words marked as obsolescent in the Forth-94 standard have
now been removed from the standard. Relegate the definitions to the
parallel Appendix for informational purposes.

Also, one wonders what the point is of an Environmental Query for
existence of these words. Rather, what would be informative is an
Environmental Query that the implementation respects the relegation of
these words from obsolescent to deprecated status.

Sieur de Bienville

unread,
Mar 12, 2010, 8:51:35 PM3/12/10
to
For what it's worth, I agree Mr. McFarling and Ms. Rather on this
matter.

The Beez'

unread,
Mar 13, 2010, 6:45:21 AM3/13/10
to
Simply rip 'em out and add WORD and FIND to the package. PARSE is a
great replacement for WORD and FIND badly needs replacement too.

Hans Bezemer

Coos Haak

unread,
Mar 13, 2010, 8:53:32 AM3/13/10
to
Op Sat, 13 Mar 2010 03:45:21 -0800 (PST) schreef The Beez':

> Simply rip 'em out and add WORD and FIND to the package. PARSE is a
> great replacement for WORD and FIND badly needs replacement too.
>
> Hans Bezemer

Don't forget PARSE-NAME as a great substitute for WORD.
PARSE doesn't skip leading delimeters.

--
Coos

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

Bruce McFarling

unread,
Mar 13, 2010, 5:05:18 PM3/13/10
to
On Mar 13, 6:45 am, "The Beez'" <hans...@bigfoot.com> wrote:
> Simply rip 'em out and add WORD and FIND to the package. PARSE is a
> great replacement for WORD and FIND badly needs replacement too.

SEARCH-WORDLIST works if you have wordlists, but its better for
searching a particular wordlist.

NAME-SEARCH( ca u -- 0 | xt 1 | xt -1 )
... would be a good match to PARSE-NAME.

Ed

unread,
Mar 13, 2010, 8:36:21 PM3/13/10
to

It might be a good match but it resolves nothing because
PARSE-NAME resolved nothing.

PARSE indeed provides the primitive which could replace WORD
(because it's a factor of WORD ).

But WORD itself cannot can be replaced. It's been at the core
of forth since earliest days and lurks in so many programs that it
cannot be got rid of without potentially breaking them. And if one
can't get rid of WORD then there's little point replacing FIND .


Bruce McFarling

unread,
Mar 14, 2010, 1:08:16 AM3/14/10
to
On Mar 13, 8:36 pm, "Ed" <nos...@invalid.com> wrote:
> But  WORD  itself cannot can be replaced.  It's been at the core
> of forth since earliest days and lurks in so many programs that it
> cannot be got rid of without potentially breaking them.

I believe it was "The Beez" who suggested ripping WORD and FIND out,
and I neither dissented nor concurred ...

... just as a library might use WORD as a primitive once if better
alternatives are not available, without using it again, a library that
finds SEARCH-WORDLIST and GET-ORDER are not available might use FIND
to define NAME-SEARCH, without ever using it again.

> And if one can't get rid of WORD then there's little point replacing FIND.

A source code library is perfectly free to state dependencies one or
the other of WordA and WordB being present.

The standardization of [DEFINED] and [UNDEFINED] makes that easier to
automate many things, but bootstrapping [DEFINED] and [UNDEFINED] in a
small Forth-94 CORE system requires WORD and FIND. A library standard
would cope with that with distinct bootstrap for distinct starting
points. One or more of those starting points would be a boostrap base
for low resource systems. A common scenario for low resource systems
is for dataspace to be especially tight, so a bootstrap base that
relies on the more dataspace frugal PARSE-NAME and NAME-SEARCH rather
than WORD and FIND cannot be dismissed out of hand.


Ed

unread,
Mar 14, 2010, 3:03:17 AM3/14/10
to

How much baggage and convolution do you think a programmer will bear
before they finally give up forth?


Marcel Hendrix

unread,
Mar 14, 2010, 3:35:04 AM3/14/10
to
"Ed" <nos...@invalid.com> writes Re: RFD: Legacy Wordset
[..]

> How much baggage and convolution do you think a programmer will bear
> before they finally give up forth?

As the words DUP + DROP OVER SWAP ROT and NIP
can be trivially and completely portably defined
using >R R> and R@ , the former 7 words can
be removed from the CORE wordset, without any
negative consequences whatever.

That should provide some breathing room.

-marcel

-- -------------------------------------------
ANEW -perverse

: dup >r r@ r> ;
: + >r dup dup - r> - - ;
: drop dup - + ;
: over >r dup dup r@ - dup >r - r> r> + ;
: swap over >r >r drop r> r> ;
: rot >r swap r> swap ;
: nip swap drop ;

: test ( -- -80 )
0
1 2 3 4
ROT ( -- 1 3 4 2 )
DUP + DROP ( -- 1 3 4 )
NIP ( -- 1 4 )
SWAP ( -- 4 1 )
OVER + + ( -- 9 )
89 - + ; ( -- -80 )

SEE test
$01244E00 : test
$01244E0A push #176 b#
$01244E0C ;


Peter Knaggs

unread,
Mar 14, 2010, 6:20:38 AM3/14/10
to
On Sat, 13 Mar 2010 11:45:21 -0000, The Beez' <han...@bigfoot.com> wrote:
>
> Simply rip 'em out and add WORD and FIND to the package. PARSE is a
> great replacement for WORD and FIND badly needs replacement too.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Nobody is suggesting we remove WORD or FIND. The words in question
are: #TIB FORGET SPAN CONVERT QUERY TIB EXPECT

Although there is a question over FORGET.

The procedure for removing a word from the document is to move the
word into an EXT wordlist and mark it as obsolete. Thus in a future
revision of the standard the word can be removed.

--
Peter Knaggs

Albert van der Horst

unread,
Mar 14, 2010, 10:14:54 AM3/14/10
to
In article <hnheeq$2ll$1...@news-01.bur.connect.com.au>,

WORD in ciforth could be in a loadable extensions, because
it can be defined portably based on PARSE and PARSE-NAME.
I don't use WORD anywhere.

FIND is even worse, I hate its stack diagram.
I have never made use or sense of the indication of immediacy it
returns.

I would have it replaced by a word that returns some dictionary
entry address, (name field address, dictionary header address,
whatever) and defined ways to arrive from there at an xt
(or separate compilation and interpretation xt's)
or immediacy information.

Anton Ertl

unread,
Mar 14, 2010, 11:56:53 AM3/14/10