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
to
Bruce McFarling <agi...@netscape.net> writes:

That would have the same problem as FIND (and SEARCH-WORDLIST): It
does not give a well-defined result for words that cannot be
represented just with an xt and a flag. I.e., it would not solve the
biggest problem that FIND has. Better solutions have been proposed
here several times.

Bruce McFarling

unread,
Mar 14, 2010, 12:12:21 PM3/14/10
to
On Mar 14, 10:14 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:

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

Something like the following? (with "flags" defined to be non-zero).

NAME-SEARCH ( ca u -- FALSE | nt flags )
Immediate? ( flags -- fl )
NT>XT ( nt -- xt )

Bruce McFarling

unread,
Mar 14, 2010, 12:19:12 PM3/14/10
to
On Mar 14, 6:20 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> 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.

That would be useful information for the explanatory appendix, as that
is unlikely to be common knowledge. For example, Ms. Elizabeth Rather
said above:

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

There is nothing in the "Legacy" wordset that indicates that words
marked obsolete are on their last step out the door.

Bruce McFarling

unread,
Mar 14, 2010, 12:27:19 PM3/14/10
to
On Mar 14, 6:20 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> On Sat, 13 Mar 2010 11:45:21 -0000, 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.

> Nobody is suggesting we remove WORD or FIND.

BTW, I believe you are replying to a message where The Beez suggested
precisely that. Rather, removing WORD and FIND is beyond the scope of
the RfD, and the subject line should have been edited. Sorry.

Peter Knaggs

unread,
Mar 14, 2010, 3:54:19 PM3/14/10
to
On Sun, 14 Mar 2010 16:19:12 -0000, Bruce McFarling <agi...@netscape.net>
wrote:

> On Mar 14, 6:20 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:
>> 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.
>
> That would be useful information for the explanatory appendix, as that
> is unlikely to be common knowledge. For example, Ms. Elizabeth Rather
> said above:
>
>> 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.

To quote from the ANS document:
>
> 1.4.2 Obsolescent features
>
> This Standard adopts certain words and practices that cause some
> previously used words and practices to become obsolescent. Although
> retained here because of their widespread use, their use in new
> implementations or new programs is discouraged, because they may be
> withdrawn from future revisions of the Standard.


> There is nothing in the "Legacy" wordset that indicates that words
> marked obsolete are on their last step out the door.

That is because there was a significant resistance to removing the
words from the document altogether. The proposed wordset was a
compromise, and does not represent the whole proposal.

The current state of the full proposal can be seen at:

http://groups.google.com/group/comp.lang.forth/msg/1abe91f8c9c4a2a1

However, given the strength of feeling over FORGET I put this
proposal to the back burner until I could find the time to rework
it.

--
Peter Knaggs

Albert van der Horst

unread,
Mar 14, 2010, 4:52:17 PM3/14/10
to
In article <0445a66d-dfcd-453a...@x12g2000yqx.googlegroups.com>,
Bruce McFarling <agi...@netscape.net> wrote:
>On Mar 13, 8:36=A0pm, "Ed" <nos...@invalid.com> wrote:
>> But =A0WORD =A0itself cannot can be replaced. =A0It'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.
>
>>=A0And if one can't get rid of WORD then there's little point replacing FI=

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

Indeed. In a small ciforth core system [DEFINED] is defined
using carnal knowledge, in a way a user of the system wouldn't dream of:

: [UNDEFINED] NAME 2DUP WANTED PRESENT 0= ; IMMEDIATE
: [DEFINED] POSTPONE [UNDEFINED] 0= ; IMMEDIATE

This, by the way, tries to load a word from the library (WANTED)
before it is declared not present in the search order.
(This seems to be allowed.)

Bruce McFarling

unread,
Mar 15, 2010, 2:21:47 AM3/15/10
to
On Mar 14, 4:52 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:

> Indeed. In a small ciforth core system [DEFINED] is defined
> using carnal knowledge, in a way a user of the system wouldn't dream of:

> : [UNDEFINED] NAME 2DUP WANTED PRESENT 0= ; IMMEDIATE
> : [DEFINED] POSTPONE [UNDEFINED] 0= ; IMMEDIATE

I should hope it is allowed, normally when I use "[UNDEFINED]" I
*prefer* that it be false and there is a system-provided word to do
the job.

Bruce McFarling

unread,
Mar 15, 2010, 3:21:52 AM3/15/10
to
On Mar 14, 3:54 pm, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> To quote from the ANS document:

> > 1.4.2 Obsolescent features

> > This Standard adopts certain words and practices that cause some
> > previously used words and practices to become obsolescent. Although
> > retained here because of their widespread use, their use in new
> > implementations or new programs is discouraged, because they may be
> > withdrawn from future revisions of the Standard.

That is precisely what I had in mind when I said it might not be
common knowledge that there is this two step procedure when Forth-94
gave the strong impression that it would likely be a direct drop kick
for goal.

> > > There is nothing in the "Legacy" wordset that indicates that words
> > > marked obsolete are on their last step out the door.

> That is because there was a significant resistance to removing the
> words from the document altogether.  The proposed wordset was a
> compromise, and does not represent the whole proposal.

Another piece of information that is neither stated nor alluded to in
the "informative" or "explanatory" appendix, nor in the prelude to the
proposal in the current RfD. If this is a compromise required to get
this cruft out of CORE EXT, then I'm all for it.

EG, for the Appendix18:

"Some existing Standard words have had the status of obsolescent, and
are therefore subject to removal in a further revision of the
Standard. If removed from the Standard, compliant implementations
would be free to use these names to refer to incompatible semantics.
Due to widespread use in legacy code, this is not presently considered
good practice.

These words are collected in this wordset so that: an implementation
that does not support legacy code can implement the full CORE EXT
wordset without including words that should not be used in new
development; implementations that support legacy code using these
words can signal this support in response to the LEGACY environmental
query; and these semantics are reserved for these words in support of
legacy code".

WRT Forget, wouldn't the simplest course be to just not worry about it
right now? Its in TOOLS EXT, a grab bag that includes EDITOR and
ASSEMBLER. Knowing that an implementation has all of CORE EXT is a lot
more informative as to what you can do than knowing that it has all of
TOOLS EXT.

Also, at 46 words, implementations and applications listing 40 words
respectively provided from or required from CORE EXT to document the 6
obsolescent words that are not provided or required is a bigger
nuisance. If the obsolescent CORE EXT words are placed in LEGACY,
there is always the presently empty LEGACY EXT to accept the other
word still marked obsolescent and any words that might later be
rendered obsolescent if it should be decided at some time in the
future.

Ed

unread,
Mar 16, 2010, 3:12:00 AM3/16/10
to
Albert van der Horst wrote:
> ...

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

Individual implementions may be able to define WORD in loadable
form but it's doubtful a Standard Program could given the variability
possible under "3.4.1.1 Delimiters".

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

> ...

The fact is WORD and FIND work, have done so for 30+ years,
and still do today. If and when they become unusable in mainstream
forths, I'll worry about replacing them.

The impetus behind all this is that people read "A.6.2.2008 PARSE"
and bought the story that WORD could be eliminated - which led
to PARSE-NAME. If WORD/FIND can't be eliminated from the
Standard because they're too entrenched in forth, where does that
now leave PARSE-NAME which isn't even a factor of WORD.
On its own by the look of it.

There have already been attempts to find PARSE-NAME a partner
but the justifications for doing so are looking more like excuses to
cover up the initial mistake.


Coos Haak

unread,
Mar 16, 2010, 12:46:03 PM3/16/10
to
Op 14 Mar 2010 14:14:54 GMT schreef Albert van der Horst:

As an example, CHForth in his current form _has_ WORD and FIND as a
loadable extension. I don't miss them. I use PARSE-NAME and FIND-XT (
c-addr u -- c-addr u false | xt x true ) where x are the IMMEDIATE and
COMPILE-ONLY flags.

> Groetjes Albert
>
> --

Van't zelfde

Bruce McFarling

unread,
Mar 16, 2010, 1:04:55 PM3/16/10
to
On Mar 16, 3:12 am, "Ed" <nos...@invalid.com> wrote:
> The fact is  WORD and FIND  work, have done so for 30+ years,
> and still do today.

But in many cases, WORD as an operation only provided for portability
and relying on factors that can be more efficiently exported as PARSE
and PARSE-NAME, and similarly for FIND.

Ed

unread,
Mar 16, 2010, 6:27:57 PM3/16/10
to

One only has to look at mainstream forths today to find that their own
use of WORD outstrips anything else by a mile. That doesn't sound
obsolete to me.

PARSE-NAME was a thought bubble floated in an ANS rationale.


Ed

unread,
Mar 16, 2010, 6:30:51 PM3/16/10
to
Marcel Hendrix wrote:
> "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
> ...

Yes it is perverse.

I feel sorry for those who once had trust in forth. Who joined forth in the
hopes that the principles and application of logic which the language
espoused would be applied by all users, and especially by those who
would later find themselves with the responsibility of maintaining the
language.

What a let down it must be to find that all that's left after 30 years, are
users whose only responsibility is to themselves. Who sit around a
table engaged in political horse-trading to see who will come out on top.
Where principles can be compromised and bartered away. What does
it matter if every mistake and poor choice one made in the past is now
intrenched in the language and foisted upon all users. What does it
matter if in order to get what one wants, one has to expound rationales
to a public that one barely believes oneself.

This is forth's future, and yes it is perverse.


Albert van der Horst

unread,
Mar 17, 2010, 8:02:24 AM3/17/10
to
In article <hnnas4$735$1...@news-01.bur.connect.com.au>,

Well, well. Let me tell you this.

The problem with WORD is that it is two functionalities in one,
depending on control data that is disguised as data.
The modern insight is that this is bad design and bad factoring.
The best proof of this is that WORD can be defined in terms
of PARSE and PARSE-NAME. (In ciforth it actually is.)
Each time you use WORD to do PARSE-NAME, WORD is obliged to
waste its time detecting it must do PARSE-NAME not PARSE.
Each time you use WORD to do PARSE-NAME, the user is obliged to
waste his time remembering whether leading delimiters must be
skipped or not.

All this was cute in a time that assembly was compact compared to
high level code, and one had to cram functionality in one definition.
Not any more.
You remember ENCLOSE ?

Elizabeth D Rather

unread,
Mar 17, 2010, 3:09:08 PM3/17/10
to
Albert van der Horst wrote:
...
>
> Well, well. Let me tell you this.
>
> The problem with WORD is that it is two functionalities in one,
> depending on control data that is disguised as data.
> The modern insight is that this is bad design and bad factoring.
> The best proof of this is that WORD can be defined in terms
> of PARSE and PARSE-NAME. (In ciforth it actually is.)
> Each time you use WORD to do PARSE-NAME, WORD is obliged to
> waste its time detecting it must do PARSE-NAME not PARSE.
> Each time you use WORD to do PARSE-NAME, the user is obliged to
> waste his time remembering whether leading delimiters must be
> skipped or not.

That sounds like a problem with your implementation. In my experience,
WORD is clean and efficient and does what it's designed to do well.
PARSE is available for those situations in which you wish *not* to skip
leading delimiters. And knowing which you want is surely a conscious
decision based on your knowledge of what you're trying to do.

> All this was cute in a time that assembly was compact compared to
> high level code, and one had to cram functionality in one definition.
> Not any more.
> You remember ENCLOSE ?

No, actually, I've never seen ENCLOSE. And traditionally, ITC Forth was
more compact than assembler, not less.

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

J Thomas

unread,
Mar 17, 2010, 4:11:29 PM3/17/10
to
Elizabeth D Rather wrote:
> Albert van der Horst wrote:

>> The problem with WORD is that it is two functionalities in one,
>> depending on control data that is disguised as data. The modern insight
>> is that this is bad design and bad factoring.

> That sounds like a problem with your implementation. In my experience,


> WORD is clean and efficient and does what it's designed to do well.

It's fine for what it's designed to do.

> PARSE is available for those situations in which you wish *not* to skip
> leading delimiters. And knowing which you want is surely a conscious
> decision based on your knowledge of what you're trying to do.

WORD does do two things.

: WORD
HERE PARSE-WORD STRING, ;

It does PARSE-WORD and it also creates a counted string at HERE .

When that's what you want to do, no problem at all. But when all you want
is PARSE-WORD then WORD does a little extra. Not a big efficiency hit,
just copying a counted string. Usually you can use the string at HERE
just as well as you can use the string in the input buffer. Usually
putting the string at HERE won't cause any trouble, you won't have
anything at HERE for it to overwrite and won't call anything that
overwrites it. And if you're looking for the address that the word
starts, you can always get it by taking the count and subtracting that
from the current source.

SOURCE DROP >IN @ + HERE C@ -

Maybe a little inefficient but no big deal.

Still, when I want PARSE-WORD then PARSE-WORD does its job better than
WORD COUNT . And it does no harm to have PARSE-WORD and STRING, both of
which are already factors of WORD and both of which are useful
themselves. It costs two extra headers. If you don't mind having WORD in
high level code then it costs hardly any code space.

Ed

unread,
Mar 17, 2010, 7:59:00 PM3/17/10
to
J Thomas wrote:
> ...

> WORD does do two things.
>
> : WORD
> HERE PARSE-WORD STRING, ;
>
> It does PARSE-WORD and it also creates a counted string at HERE .
> ...

No.

A.6.2.2008 's version of PARSE-WORD (equivalent to PARSE-NAME )
has no delimiter character on the stack and therefore is *not* a factor of
WORD.


Bruce McFarling

unread,
Mar 17, 2010, 11:37:03 PM3/17/10
to

It is not the factor as shown above. I believe that Albert van Horst
is referring to using PARSE-NAME as the factor for the function of
WORD selected by passing it "BL" ...
... DUP BL = IF PARSE-NAME ELSE ...

Coos Haak

unread,
Mar 18, 2010, 6:49:41 AM3/18/10
to
Op Thu, 18 Mar 2010 10:59:00 +1100 schreef Ed:

: WORD ( char "<chars>ccc<char>" -- c-addr )
DUP BL = IF DROP PARSE-NAME
ELSE >R SOURCE OVER SWAP >IN @ /STRING
R@ SKIP
DROP SWAP - >IN ! R> PARSE
THEN
HERE PLACE HERE BL OVER COUNT + C!
;

So, PARSE-NAME is a factor of WORD

Anton Ertl

unread,
Mar 18, 2010, 9:20:50 AM3/18/10
to

There is another widely implemented PARSE-WORD that takes a delimiter.
That was the reason why PARSE-NAME was standardized with that name and
not with the name PARSE-WORD.

Anton Ertl

unread,
Mar 18, 2010, 9:37:18 AM3/18/10
to
Elizabeth D Rather <era...@forth.com> writes:
>In my experience,
>WORD is clean and efficient and does what it's designed to do well.

In my experience it is clean neither in its interface nor in its
implementation, for the same reason:

One has to special-case BL WORD, because that may (must with the FILE
wordset) also treat other white space as delimiters.

As for what it's designed to do: What is that? Do you ever use it
with a different argument than BL? If so, for what?

To me the only use where it has at least a little bit of justification
is BL WORD, and that's better subsumed by PARSE-NAME. Passing a
delimiter to WORD is an overgeneralization, and it's a useless
overgeneralization.

Concerning efficiency, it is certainly less efficient than PARSE-NAME,
because it has to deal with its parameter and special-case it, and it
has to copy the resulting string to its buffer.

>PARSE is available for those situations in which you wish *not* to skip
>leading delimiters.

I.e., every time the delimiter is not BL.

So yes, once we have a replacement for FIND (which is totally broken,
unlike WORD, which just has a bad interface), we can phase out WORD.

There may be programs using it, that's why we take a long time to
phase out existing features. I think in this case it's quite easy:
Replace BL WORD COUNT with PARSE-NAME and BL WORD FIND with PARSE-NAME
<find-replacement>; that should take care of most uses of WORD.

As for system usage: Whether WORD is in the standard or not, systems
can use it internally, so that's no reason to keep it in the standard.

Concerning mainstream Forths using it internally, I have just checked
Gforth. Apart from tests, it uses WORD only in [DEFINED], and that's
now replaced with a shorter implementation using PARSE-NAME. But
maybe Gforth is an exotic Forth system.

It may be interesting how I found the use of WORD. That's not as easy
as using grep, because "word" occurs in many comments, and these are
also words like WORDLIST. So what did I do? I just deleted the
definition of WORD and looked what broke; only [DEFINED] broke, and
after fixing that, the tests.

Bruce McFarling

unread,
Mar 18, 2010, 11:04:57 AM3/18/10
to
On Mar 18, 9:20 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> There is another widely implemented PARSE-WORD that takes a delimiter.
> That was the reason why PARSE-NAME was standardized with that name and
> not with the name PARSE-WORD.

If PARSE-WORD was exact match - that is, no special white-space
treatment - and with STR, taking wouldn't Coos Haak's WORD (which
assumes the WORD buffer is at HERE) be something like:

: WORD ( char "<chars>ccc<char>" -- c-addr )
DUP BL = IF
DROP PARSE-NAME

ELSE PARSE-WORD

Albert van der Horst

unread,
Mar 18, 2010, 5:22:04 PM3/18/10
to
In article <bd177f76-9c44-475d...@z3g2000yqz.googlegroups.com>,
Bruce McFarling <agi...@netscape.net> wrote:

>On Mar 17, 7:59=A0pm, "Ed" <nos...@invalid.com> wrote:
>> J Thomas wrote:
>> > ...
>> > WORD does do two things.
>>
>> > : WORD
>> > =A0 =A0HERE PARSE-WORD STRING, ;

>>
>> > It does PARSE-WORD and it also creates a counted string at HERE .
>> > ...
>>
>> No.
>>
>> A.6.2.2008 's version of =A0PARSE-WORD =A0(equivalent to =A0PARSE-NAME )
>> has no delimiter character on the stack and therefore is *not* a factor o=

>f
>> WORD.
>
>It is not the factor as shown above. I believe that Albert van Horst
>is referring to using PARSE-NAME as the factor for the function of
>WORD selected by passing it "BL" ...
> ... DUP BL =3D IF PARSE-NAME ELSE ...

I think I must apologize (especially to Elizabeth) because of
my misconception that the behaviour with respect to leading
delimiters is different for blanks and non-blanks.

The following still stands:
Note that NAME skips till anything considered blank (virgin 1], space,
tab, cr, lf, end of input), where in the other case it
compares to an exact delimiter.

Sure thing is that NAME and PARSE can be used as factors in
WORD, e.g. in ciforth I have the following definitions

\ _ leaves a don't care.
: NAME ( aka PARSE-NAME)
\ Skip till not blank, or endofinput, leave pos
_ BEGIN DROP IN[] ?BLANK OVER SRC CELL+ @ - AND 0= UNTIL
\ Skip till blank ( endofinput is also blank), leave pos
_ BEGIN DROP IN[] ?BLANK UNTIL
OVER -
;

: WORD
DUP BL = IF
DROP NAME
ELSE
>R
\ Skip leading delimiters.
BEGIN IN[] R@ = WHILE DROP REPEAT DROP
-1 >IN +!
R> PARSE
THEN
HERE 22 BLANK HERE $!-BD HERE
;


It seems that the two points of skipping and use of a transient region
separately and independantly make it impossible to use WORD as a
factor for S" .

If that is true, in a system with both S" and WORD a good designer
will come up with PARSE as a factor.

Groetjes Albert

1] virgin, i.e. 0FF or blank flash.

J Thomas

unread,
Mar 18, 2010, 5:12:49 PM3/18/10
to

OK, too bad. They sort of share a factor. As I understand it, the point
of PARSE-NAME is that it skips all white-space characters, not just BL.
It does it the way the text interpreter does it, and you can't reliably
do just BL and expect to catch other white-space. What a mess.

I don't see any easy way to factor those so the obvious similarity can be
used.

In a vaguely similar situation, CASE OF , OF normally takes a single
character and branches on comparison. OF is something like OVER = IF
DROP . But you can do whatever comparisons you want and generate a flag
and then compare that flag to a true or a false flag, whichever you
prefer. Something that's defined as a single compare can be extended
easily. But it would be hard to do that with WORD or the factor of PARSE-
NAME . You'd probably have to pass the command an xt to do the
comparison. Complicated and hard to read.

The Beez'

unread,
Mar 18, 2010, 6:46:56 PM3/18/10
to
On 17 mrt, 20:09, Elizabeth D Rather <erat...@forth.com> wrote:
> That sounds like a problem with your implementation.  In my experience,
> WORD is clean and efficient and does what it's designed to do well.
> PARSE is available for those situations in which you wish *not* to skip
> leading delimiters.  And knowing which you want is surely a conscious
> decision based on your knowledge of what you're trying to do.
There are three major problems with WORD:
(a) It's two functionalities in one. Chuck never liked IF's, neither
do I. It's confusing behavior.
(b) It takes up memory and valuable time to copy the string to a
buffer.
(c) It doesn't follow the ANS paradigm addr/count as one of the two
not-obsolete exceptions.

If I want a WS parse, I use PARSE-NAME;
If I want a clean parse, I use PARSE;
If I want to skip leading delimiters I use PARSE-WORD (much like WORD,
but leaves an addr/count string).

My implementation also has OMIT which skips leading delimiters so,
yes, I could even do without PARSE-WORD
: PARSE-WORD DUP OMIT PARSE ;

Ed

unread,
Mar 18, 2010, 8:02:25 PM3/18/10
to
Coos Haak wrote:
> Op Thu, 18 Mar 2010 10:59:00 +1100 schreef Ed:
>
> > J Thomas wrote:
> >> ...
> >> WORD does do two things.
> >>
> >>: WORD
> >> HERE PARSE-WORD STRING, ;
> >>
> >> It does PARSE-WORD and it also creates a counted string at HERE .
> >> ...
> >
> > No.
> >
> > A.6.2.2008 's version of PARSE-WORD (equivalent to PARSE-NAME )
> > has no delimiter character on the stack and therefore is *not* a factor of
> > WORD.
>
> : WORD ( char "<chars>ccc<char>" -- c-addr )
> DUP BL = IF DROP PARSE-NAME
> ELSE >R SOURCE OVER SWAP >IN @ /STRING
> R@ SKIP
> DROP SWAP - >IN ! R> PARSE
> THEN
> HERE PLACE HERE BL OVER COUNT + C!
> ;
>
> So, PARSE-NAME is a factor of WORD

That's not a factor - it's a workaround to overcome the fact PARSE-NAME
*isn't* a factor. It's the sort of hack one resorts to when one has made a
wrong design choice earlier on.

Let's be clear. The premise behind the ANS' PARSE-WORD suggestion
was that WORD *could* be eliminated:

"... If both PARSE and PARSE-WORD are present, the need for
WORD is largely eliminated."

It turns out that one can't for a host of reasons. Add to that WORD is
still very effective and handles 99% or more of forth token parsing needs.

I can understand what some are saying i.e. it might be handy if the
parsing component of WORD was factored out. Yes it might. But
let's not overstate the need for it, or implement it as a non-factor.

Coos Haak

unread,
Mar 18, 2010, 8:30:22 PM3/18/10
to
Op Fri, 19 Mar 2010 11:02:25 +1100 schreef Ed:

> Coos Haak wrote:
<snip>


>>: WORD ( char "<chars>ccc<char>" -- c-addr )
>> DUP BL = IF DROP PARSE-NAME
>> ELSE >R SOURCE OVER SWAP >IN @ /STRING
>> R@ SKIP
>> DROP SWAP - >IN ! R> PARSE
>> THEN
>> HERE PLACE HERE BL OVER COUNT + C!
>> ;
>>
>> So, PARSE-NAME is a factor of WORD
>
> That's not a factor - it's a workaround to overcome the fact PARSE-NAME
> *isn't* a factor. It's the sort of hack one resorts to when one has made a
> wrong design choice earlier on.
>

I still maintain that PARSE-NAME is a factor. WORD is in _my_
implementation a loadable extension, IOW a workaround. PARSE-NAME is
in the kernel.

Ed

unread,
Mar 18, 2010, 9:08:02 PM3/18/10
to
The Beez' wrote:
> ...

> There are three major problems with WORD:
> (a) It's two functionalities in one. Chuck never liked IF's, neither
> do I. It's confusing behavior.
> (b) It takes up memory and valuable time to copy the string to a
> buffer.

It's hard to believe Chuck would design a word with so many problems!

Yes, WORD has two functionalities in one. Presumably WORD
wasn't factored because there was no pressing need to do so.
There still isn't.

WORD was efficient. It placed the result at HERE (or thereabouts)
because that's where the header would be built. It consumed no extra
space, sharing it with other transient areas such as numeric pictured
output. And one could write to WORD's buffer if need be.

If WORD was deemed efficient enough to use in the 60's and 70's
when minis and micros were slow, how could it possibly be an issue
today.

> (c) It doesn't follow the ANS paradigm as one of the two
> not-obsolete exceptions.

Precisely. The ANS paradigm doesn't state that existing non addr/count
words must be replaced. That would be revolution for its own sake
without any regard for the consequences.

WORD and FIND have a strong historical context and it would have
been unwise to overturn them based on an ideological preference.
Besides which, they still worked and continue to.


Elizabeth D Rather

unread,
Mar 19, 2010, 3:35:23 AM3/19/10