RFD: Legacy Wordset
Peter Knaggs
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:
Elizabeth D Rather
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
<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
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
> 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
>
> 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
> 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
> 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
Describing them in an appendix, such as Bernd suggests, would satisfy
that purpose without encouraging people to perpetuate them.
alextangent
I suppose it's too much to ask that [COMPILE] be added to the list?
--
Regards
Alex McDonald
Peter Knaggs
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
>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
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
>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
>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
including them in any normative section will encourage folks to
perpetuate them.
Cheers,
Elizabeth
--
Jonah Thomas
> 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
> 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
I agree! I second your proposal!
--
duke
Elizabeth D Rather
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
_Their_ own?
Jerry
--
Why am I in a handbasket? Where are we going?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Bruce McFarling
> 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
matter.
The Beez'
great replacement for WORD and FIND badly needs replacement too.
Hans Bezemer
Coos Haak
> 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
> 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
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
> 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
How much baggage and convolution do you think a programmer will bear
before they finally give up forth?
Marcel Hendrix
[..]
> 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
>
> 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
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
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
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
> 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
> > 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
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
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.
>
>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
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
> 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
> ...
> 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
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
> 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
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
> "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
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
...
>
>
> 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
> 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.