RfD: Legacy Word

11 views
Skip to first unread message

Peter Knaggs

unread,
Sep 11, 2009, 3:12:03 PM9/11/09
to fort...@yahoogroups.com
Legacy Words
============

2009-09-09 Removed legacy word set in favour of section D.7
1998-11-30 Original text by Len Zettel


Problem
=======
Section 1.4.2 "Obsolescent features" declared seven words as
obsolescent and warned "they may be withdrawn from future revisions
of the Standard". It is now 15 years since that warning was issued,
it is time to remove these words from the document.

In order to do this a number of alterations to the main document
are required.


Proposal
========

1. Replace the first three paragraphs of section 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.

This Standard designates the following words as obsolescent:

6.2.0060 #TIB 15.6.2.1580 FORGET 6.2.2240 SPAN
6.2.0970 CONVERT 6.2.2040 QUERY 6.2.2290 TIB
6.2.1390 EXPECT

with:

This Standard adopts certain words and practices that cause
some previously used words and practices to become
obsolescent. Their use in new implementations or new
programs is discouraged, as they may be withdrawn from
future revisions of the Standard.

This Standard designates no words as obsolescent.

2. Remove reference to EXPECT and CONVERT from the Documentation
requirements:

4.1.1 Implementation-defined options:

- character editing of ACCEPT and EXPECT;

- display after input terminates in ACCEPT and EXPECT;

4.1.2 Ambiguous conditions

- producing a result out of range, e.g., multiplication
(using *) results in a value too big to be represented by a
single-cell integer (*, */, */MOD, >NUMBER, FM/MOD, SM/REM,
UM/MOD, CONVERT, M*/);

4.2.1 Environmental dependencies

- depending on the presence or absence of non-graphic
characters in a received string (ACCEPT, EXPECT);

3. Replace throw code -15:

-15 invalid FORGET

with:

-15 reserved

4. CORE EXT Wordset

6.1.2216 SOURCE
Remove ", declaring TIB and #TIB obsolescent" from the end of the
first paragraph, and the following text from the rationale:

SOURCE in this form exists in F83, polyFORTH, LMI's Forths
and others. In conventional systems it is equivalent to the
phrase

BLK @ IF BLK @ BLOCK 1024 ELSE TIB #TIB @ THEN

6.1.2450 WORD
Remove the sentence "A space, not included in the length,
follows the string" from the second paragraph and the note
in the definition.

Remove the second paragraph from the rationale:

As a concession to the obsolesecent word CONVERT, Forth94
required an implementation to put a space after the string
placed by WORD. This standard neither requires nor
prohibits such a space.

6.2.0060 #TIB
Remove the definition and rationale.

6.2.0695 ACCEPT
Remove reference to EXPECT from the first paragraph, and the
following paragraphs from the rationale:

ACCEPT and EXPECT perform similar functions. ACCEPT is
recommended for new programs, and future use of EXPECT
is discouraged.

As in previous standards, EXPECT returns the input string
immediately after the requested number of characters are
entered, as well as when a line terminator is received.
The "automatic termination after specified count of
characters have been entered" behavior is widely considered
undesirable because the user "loses control" of the input
editing process at a potentially unknown time (the user does
not necessarily know how many characters were requested from
EXPECT). Thus EXPECT and SPAN have been made obsolescent and
exist in the Standard only as a concession to existing
implementations. If EXPECT exists in a Standard System it
must have the "automatic termination" behavior.

ACCEPT does not have the "automatic termination" behavior of
EXPECT. However, because external system hardware and
software may perform the ACCEPT function, when a line
terminator is received the action of the cursor, and therefore
the display, is implementation-defined. It is recommended
that the cursor remain immediately following the entered text
after a line terminator is received.

6.2.0970 CONVERT
Remove the definition and rationale.

6.2.1850 MARKER
Remove the reference to FORGET in the see also list of the
definition.

Replace the current rationale:

As dictionary implementations have become more elaborate and
in some cases have used multiple address spaces, FORGET has
become prohibitively difficult or impossible to implement on
many Forth systems. MARKER greatly eases the problem by
making it possible for the system to remember "landmark
information" in advance that specifically marks the spots
where the dictionary may at some future time have to be
rearranged.

with:

As dictionary implementations have become more elaborate and
in some cases have used multiple address spaces, it has
become prohibitively difficult or impossible to infer the
state of the dictionary when any given word is defined,
rendering the traditional word FORGET obsolete. MARKER
allows a system to remember "landmark information" in advance
that specifically marks the spots where the dictionary may at
some future time have to be rearranged.

6.2.1390 EXPECT
Remove the definition and rationale.

6.2.2040 QUERY
Remove the definition and rationale.

6.2.2125 REFILL
Remove the reference to QUERY in the rationale leaving:

REFILL is designed to behave reasonably for all possible
input sources. If the input source is coming from the user
REFILL could still return a false value if, for instance, a
communication channel closes so that the system knows that
no more input will be available.

6.2.2240 SPAN
Remove the definition, there is no rationale.

6.2.2290 TIB
Remove the definition and rationale.

11.6.2.xxxx REQUIRED
Remove the reference to FORGET in the first paragraph of the
definition and the reference implementation.

5. Remove the ambiguous conditions for FORGET from the TOOLS EXT
Wordset (15.4.1.2):

- deleting the compilation word-list (FORGET);

- name can't be found (FORGET);

- removing a needed definition (FORGET).

6. TOOLS EXT Wordset

15.6.2.1580 FORGET
Remove the definition and rationale.

7. Remove the reference to #TIB and TIB from the first sentence of
the "Data space" rationale (A.3.3.3).

8. Remove the reference to CONVERT in the rationale for the
Core extension words (A.6.2):

- Words that are being deprecated in favour of new words
introduced to solve specific problems (e.g., CONVERT).

9. Add the following to Annex D:

D.7 ANS Forth '94
=============

D.7.1 Removed Definitions
-------------------

This standard removes the seven words that were marked
'obsolescent' in the ANS Forth '94 document. These are:

6.2.0060 #TIB 15.6.2.1580 FORGET 6.2.2240 SPAN
6.2.0970 CONVERT 6.2.2040 QUERY 6.2.2290 TIB
6.2.1390 EXPECT

Reuse of these names is strongly discouraged.


Remarks
=======

Annex D needs work to bring it up to date, let along explain the
difference between Forth200x and ANS Forth '94. This should be
the topic of another RfD. The text given in point 9 is intended
as a place holder until annex D is discussed in full.


Author
======
Peter Knaggs, P.J.K...@exeter.ac.uk

m_l_g3

unread,
Sep 14, 2009, 5:40:04 PM9/14/09
to
On 11 сен, 23:12, Peter Knaggs <p...@bcs.org.uk> wrote:
> Legacy Words
> ============
>
> 2009-09-09  Removed legacy word set in favour of section D.7
> 1998-11-30  Original text by Len Zettel
>
<...>

> 5. Remove the ambiguous conditions for FORGET from the TOOLS EXT
>     Wordset (15.4.1.2):
>
>      - deleting the compilation word-list (FORGET);
>
>      - name can't be found (FORGET);
>
>      - removing a needed definition (FORGET).
>
> 6. TOOLS EXT Wordset
>
>     15.6.2.1580  FORGET
>     Remove the definition and rationale.
>

I am opposed to removal of FORGET. Unlike other words whose
functionality is just plain strange (side effects in a global
variable, expectation of a space not included into string count),
FORGET is a good word whose only problem is that on some
systems its implementation is untrivial.
If your implementation of FORGET <NAME> did
for(<WORD> in all words defined after <NAME>) remove <WORD>
you would not have much problems with it, because each word
somehow references its resources.

The only usage where MARKER does what FORGET cannot do is
something like

HERE size ALLOT CONSTANT mybuffer
or
WORDLIST CONSTANT mywordlist

(FORGET mybuffer would not undo the effect of size ALLOT
for the reason that the word mybuffer was created after
that allocation. But it should not be expected to do that.)

Ed

unread,
Sep 15, 2009, 12:43:27 AM9/15/09
to
m_l_g3 wrote:

I agree that FORGET is just as effective as MARKER.
The rationale for MARKER doesn't stand up to scrutiny.

IMO the question boils down to redundancy. Now that
MARKER exists, does the Standard *need* two words
that perform essentially the same task? My view is no.

I have FORGET and MARKER and will personally keep
both as a) I'm used to FORGET b) getting rid of it would
save only a handful of bytes.

The problem for 200x is that on the one hand they want to
eliminate redundancies such as FORGET EXPECT etc,
but then go ahead and introduce their own. Why a Forth
Standard *needs* all these is a mystery:

CHAR a [CHAR] a 'a'

It's inconsistencies such as this and the general ad-hoc
nature of decisions that finally turned me away from 200x.

If you want to argue that FORGET should stay on the basis
that it's effective and 200x permits other redundancies,
then I'd say you have a good case.

Peter Knaggs

unread,
Sep 15, 2009, 3:29:37 AM9/15/09
to
Ed wrote:
>
> The problem for 200x is that on the one hand they want to
> eliminate redundancies such as FORGET EXPECT etc,
> but then go ahead and introduce their own. Why a Forth
> Standard *needs* all these is a mystery:
>
> CHAR a [CHAR] a 'a'

Are you suggesting CHAR and [CHAR] are removed? The procedure
would be to move the word into the CORE EXT and flag it up as
obsolete. Finally, removing the word in the next revision, in
another 15 years or so.

IMHO the introduction of 'a' does away with the need for [CHAR]
but not CHAR.

--
Peter Knaggs

The Beez'

unread,
Sep 16, 2009, 5:39:24 AM9/16/09
to
On Sep 15, 6:43 am, "Ed" <nos...@invalid.com> wrote:
[CHAR] and CHAR are the consequence of making words STATE-dumb.
Before, there was only ASCII. Note that 'a' is non-standard AFAIK. It
is also pollution of the namespace and makes the compiler more
complex, because this is a special case, which has to be checked.
There has been enough pollution with double words (3000.), floating
point words (3e3) and the recent addition of "added" radix words
(#FACE).

Special parsing words like F#, D#, CHAR, etc. are much more Forth-like
IMHO. No, as far as I'm concerned CHAR and [CHAR] do just fine. If you
really need 'a', take the extra trouble of defining:

CHAR a CONSTANT 'a'

It's the same thing, it just needs a little planning. Lazy programmers
never wrote any good code.

Hans Bezemer

Peter Knaggs

unread,
Sep 16, 2009, 6:39:44 AM9/16/09
to
The Beez' wrote:
>
> [CHAR] and CHAR are the consequence of making words STATE-dumb.
> Before, there was only ASCII. Note that 'a' is non-standard AFAIK. It
> is also pollution of the namespace and makes the compiler more
> complex, because this is a special case, which has to be checked.
> There has been enough pollution with double words (3000.), floating
> point words (3e3) and the recent addition of "added" radix words
> (#FACE).

The X:number-prefixes proposal included (polluted the parser with):

#0 \ decimal
$0 \ hex
%0 \ binary
'a' \ equivalent to char a or [char] a

Thus 'a' is part of the 200x standard.

> Special parsing words like F#, D#, CHAR, etc. are much more Forth-like
> IMHO.

Here I agree, but it is true that many systems have provided #, $ and
others for many years, thus it does make sense to codify this in to the
standard. Indeed I recall a paper over 20 years ago which described
just such an extension.

According to the records, you where the only systems provider to vote
against this proposal while seven providers voted for it. Even I voted
for the proposal, despite my distaste, due to the proven commonality.

--
Peter Knaggs

Ed

unread,
Sep 16, 2009, 6:45:44 AM9/16/09
to
Peter Knaggs wrote:
> Ed wrote:
> >
> > The problem for 200x is that on the one hand they want to
> > eliminate redundancies such as FORGET EXPECT etc,
> > but then go ahead and introduce their own. Why a Forth
> > Standard *needs* all these is a mystery:
> >
> > CHAR a [CHAR] a 'a'
>
> Are you suggesting CHAR and [CHAR] are removed?

What I'm suggesting is that the OP has made a valid argument.
He's entitled to argue for the retention of FORGET given 200x
has happily proposed and accepted redundancies of its own.

Andrew Haley

unread,
Sep 16, 2009, 6:59:20 AM9/16/09
to

But that argument in a logical fallacy: it's equivalent to saying that
if you allow one redundant word to remain, you must allow them all.

Andrew.

Peter Knaggs

unread,
Sep 16, 2009, 7:49:21 AM9/16/09
to
m_l_g3 wrote:
>
> I am opposed to removal of FORGET. Unlike other words whose
> functionality is just plain strange (side effects in a global
> variable, expectation of a space not included into string count),
> FORGET is a good word whose only problem is that on some
> systems its implementation is untrivial.

True, but there are implementations where FORGET is simply impossible to
implement. Systems that choose to implement FORGET are restricted on
the implementation methods because of their choice. Unfortunately, most
systems have implemented the whole wordset, including the optional (EXT)
words rather than taking the pick and mix approach allowed by the standard.

Removing the restriction would allow more innovative dictionary
implementations. MARKER was designed explicitly to facilitate this.

> If your implementation of FORGET <NAME> did
> for(<WORD> in all words defined after <NAME>) remove <WORD>
> you would not have much problems with it, because each word
> somehow references its resources.

To do this you have to keep a track of the definition history, so you
know which words were defined after to target word. Most systems do
this by using the address of the definition, even when using multiple
threads. However, other systems are viable (hash code, code buckets,
and such) where such a history must be recorded separately purely to
support FORGET. The TC did not wish to promote any particular
implementation method, this is why FORGET was demoted to an optional EXT
word and marked as obsolete in the '94 document.

--
Peter Knaggs

Ed

unread,
Sep 16, 2009, 9:11:31 AM9/16/09
to

The topic of MARKER vs. FORGET was discussed not too long ago
on c.l.f. For each claim that FORGET couldn't restore this or that,
wasn't efficient etc., supporters provided evidence to the contrary.
FORGET works and works well.

Ed

unread,
Sep 16, 2009, 9:13:09 AM9/16/09
to

Calm yourself.

So far the OP has only asked for FORGET to be retained.

Peter Knaggs

unread,
Sep 16, 2009, 9:40:34 AM9/16/09
to
Ed wrote:

> Peter Knaggs wrote:
>>
>> To do this you have to keep a track of the definition history, so you
>> know which words were defined after to target word. Most systems do
>> this by using the address of the definition, even when using multiple
>> threads. However, other systems are viable (hash code, code buckets,
>> and such) where such a history must be recorded separately purely to
>> support FORGET. The TC did not wish to promote any particular
>> implementation method, this is why FORGET was demoted to an optional EXT
>> word and marked as obsolete in the '94 document.
>
> The topic of MARKER vs. FORGET was discussed not too long ago
> on c.l.f. For each claim that FORGET couldn't restore this or that,
> wasn't efficient etc., supporters provided evidence to the contrary.
> FORGET works and works well.

Fair enough, but that does not negate the fact that the '94 document
marked FORGET as obsolete.

Andrew Haley

unread,
Sep 16, 2009, 9:44:46 AM9/16/09
to

> Calm yourself.

Huh?

> So far the OP has only asked for FORGET to be retained.

It's the same logical fallacy, regardless of how many words are
involved. The fact that redundant word X is still included has no
bearing whatsoever on the inclusion of redundant word Y.

Anyone is entitled to argue for retention of obsolescent words, but
they were marked as such, with good reason, fifteen years ago. We
were told then they were going to disappear. If the OP wishes to keep
FORGET in his own system because he finds it useful that's perfectly
OK, but not sufficient reason for it to remain in the standard.

Andrew.

Andrew Haley

unread,
Sep 16, 2009, 9:59:31 AM9/16/09
to

For anyone who wants to know what was actually said,
http://groups.google.co.uk/group/comp.lang.forth/msg/26f32519c8778f1a

Andrew.

Bernd Paysan

unread,
Sep 16, 2009, 11:23:33 AM9/16/09
to
The Beez' wrote:
> Special parsing words like F#, D#, CHAR, etc. are much more Forth-like
> IMHO. No, as far as I'm concerned CHAR and [CHAR] do just fine. If you
> really need 'a', take the extra trouble of defining:
>
> CHAR a CONSTANT 'a'
>
> It's the same thing, it just needs a little planning. Lazy programmers
> never wrote any good code.

The code to add 'x' number conversion in bigForth is just two lines of code
in NUMBER. You may be able to define up to four or six such constants in
those two lines if you cramp them together. And you open up your program
for obfuscation and bugs, e.g.

CHAR m Constant 'n' \ thick fingers hit wrong key
CHAR z Constant 'x' \ thick fingers hit again!

'x' adds redundancy, because we don't make CHAR and [CHAR] obsolecent. Why?
They have no real problem, and people still use them. In the next round, we
can reconsider: when people tend to drop CHAR and [CHAR] in favor of 'x',
then we can make it obsolecent.

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

m_l_g3

unread,
Sep 17, 2009, 8:28:25 AM9/17/09
to
On 16 сен, 04:49, Peter Knaggs <p...@bcs.org.uk> wrote:
> m_l_g3 wrote:
>
> > I am opposed to removal of FORGET. Unlike other words whose
> > functionality is just plain strange (side effects in a global
> > variable, expectation of a space not included into string count),
> > FORGET is a good word whose only problem is that on some
> > systems its implementation is untrivial.
>
> True, but there are implementations where FORGET is simply impossible to
> implement.

In bookkeeping there is a tradition of assuming that a document
does not exist unless one can say "here it is" and show it.

So, come on, please demonstrate implementations where FORGET
is impossible to implement but MARKER is possible.

>  Systems that choose to implement FORGET are restricted on
> the implementation methods because of their choice.  Unfortunately, most
> systems have implemented the whole wordset, including the optional (EXT)
> words rather than taking the pick and mix approach allowed by the standard.
>
> Removing the restriction would allow more innovative dictionary
> implementations.  MARKER was designed explicitly to facilitate this.
>
> > If your implementation of FORGET <NAME> did
> > for(<WORD> in all words defined after <NAME>) remove <WORD>
> > you would not have much problems with it, because each word
> > somehow references its resources.
>
> To do this you have to keep a track of the definition history, so you
> know which words were defined after to target word.  Most systems do
> this by using the address of the definition, even when using multiple
> threads.  However, other systems are viable (hash code, code buckets,
> and such) where such a history must be recorded separately purely to
> support FORGET.  The TC did not wish to promote any particular
> implementation method, this is why FORGET was demoted to an optional EXT
> word and marked as obsolete in the '94 document.

Marking FORGET obsolete was a mistake (and a minor one; it is complete
removal of FORGET that would be a serious mistake). There have
been done several mistakes, most of them were raised as RFIs, and
bar-locals were just ignored by the community. But the issue of
FORGET could not pop up before someone wanted to actually remove it.

By the way, the standard NEVER stated that ALL obsolete words
are going to be removed altogether.

Why FORGET was marked obsolete.
In 1994, the evolution of Forth systems went in the direction of
increasing the number of used 64K segments. The TC did not have
a goal of predicting future evolution of the systems; the goal
was to just allow everything imaginable. Now it is clear that
most Forth systems use 2 or 3 sections (names, native code,
data and threaded code); 32-bit processors are cheap and
restrictions of 16-bit address space do not force the implementors
to cripple the system's architecture.


In addition, MARKER and FORGET are not equivalent.
MARKER is well-suited for use in files, while FORGET
is more convenient for command line usage.

Here is a sample Win32Forth session.
It's evident that MARKER would not be usable here.

1 2 3 .s [3] 1 2 3 ok...
: udup swap over ; ok...
udup .s [4] 1 3 2 3 ok....
\ OOPS! not what I wanted. I will tidy it up:
drop swap .s [3] 1 2 3 ok...
forget udup ok...
.s [3] 1 2 3 ok...
\ now, the 2nd attempt:
: udup over swap ; ok...
udup .s [4] 1 2 2 3 ok....
\ this IS what I wanted!
\ Now I can copy&paste the definition into the file.


So I propose:
1) not to remove FORGET from the standard
2) [as an option] remove the obsolescence note from 15.6.2.1580 FORGET
3) [as an option] add the rationale that MARKER is for use in source
files whereas FORGET is for use in interactive sessions.

( As to the document as a whole, please remember that there are the
following words not marked as obsolescent:
15.6.2.1300 EDITOR TOOLS EXT
15.6.2.0740 ASSEMBLER TOOLS EXT
15.6.2.0930 CODE TOOLS EXT
15.6.2.0470 ;CODE TOOLS EXT
and no END-CODE or NEXT;
15.6.1.0600 ? TOOLS

I have seen many Forth editors but never had to use EDITOR for
editing. In C-based and Scheme-based Forths, CODE & Co. are
a problem; in addition, how do I terminate a CODE definition?
And how do I write a do-nothing CODE definition?
The word ? is not needed at all: @ . does what it does and
@ H. does even more.

So presence of FORGET is not going to damage the overall
document quality, and TOOLS EXT is just the right place for it.
)

Anton Ertl

unread,
Sep 12, 2009, 9:11:03 AM9/12/09
to
Peter Knaggs <p...@bcs.org.uk> writes:
>Legacy Words

Looks good.

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

m_l_g3

unread,
Sep 17, 2009, 10:09:37 AM9/17/09
to
On 16 сен, 06:59, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:

Thank you for the link. (I had to click on "Constant array" to see the
whole discussion.)

I will comment on
http://groups.google.co.uk/group/comp.lang.forth/msg/fdfab43873c5f37e
in the context of my proposal.

==quote==
"FORGET assumes that all the information needed to restore the
dictionary to its previous state is inferable somehow from the
forgotten word. While this may be true in simple linear dictionary
models, it is difficult to implement in other Forth systems; e.g.,
those with multiple address spaces. For example, if Forth is embedded
in ROM, how does FORGET know how much RAM to recover when an array is
forgotten? A general and preferred solution is provided by MARKER."
==/quote==

1. The code field (invisible for an ANS-compliant application but
visible for the system itself) usually has some kind of pointer
to the data field, so it is technically feasible for the system
to restore the RAM pointer, provided that the implementors took
care to make the code fields with the data field in RAM
distinguishable from those with the data field in ROM.

2. The use of FORGET indeed may result in resource leak:
for each memory segment, FORGET does not deallocate memory
allocated before creation of definitions that reference
that memory.

We do not need to resort to ROM/RAM architectures to
demonstrate it:
HERE 100 CELLS ALLOT CONSTANT MYBUFFER
FORGET MYBUFFER
will not free the 100 CELLS allocated before
creation of the constant. A solution to this problem
is provided by MARKER, at the cost of marking in advance.

3. The purposes of FORGET and MARKER are different:
MARKER is best suited for use in source files, while
FORGET is better suited for interactive use, in the
circumstances that it is not practical to
define MARKERs in advance.

FORGET is necessary when a human redefines an existing
word in the command line, finds a bug, and wants to
correct it:
VARIABLE MYVAR
: CATCH MYVAR @ >R CATCH MYVAR R> ! ;
( ... bug discovered)
FORGET CATCH
: CATCH MYVAR @ >R CATCH R> MYVAR ! ;
In this example one has to remove the mis-redefined
version because it crashes. MARKER cannot help here
because when the bug is discovered, it is too late
to define a MARKER.

4. Both FORGET and MARKER are TOOLS EXT, and neither
of them is obligatory to implement.

Coos Haak

unread,
Sep 17, 2009, 1:11:13 PM9/17/09
to
Op Thu, 17 Sep 2009 07:09:37 -0700 (PDT) schreef m_l_g3:

<snip>


> FORGET is necessary when a human redefines an existing
> word in the command line, finds a bug, and wants to
> correct it:
> VARIABLE MYVAR
>: CATCH MYVAR @ >R CATCH MYVAR R> ! ;
> ( ... bug discovered)
> FORGET CATCH
>: CATCH MYVAR @ >R CATCH R> MYVAR ! ;
> In this example one has to remove the mis-redefined
> version because it crashes. MARKER cannot help here
> because when the bug is discovered, it is too late
> to define a MARKER.
>

Of course it's too late. Make it a habit to define a MARKER _before_
you start working at the terminal and test definitions interactively.
When you discover mistakes, the offending code is simply removed.
(ANEW as a variant for MARKERs can be of help.)
Only when you for a debugged piece of code (that you would have
written in a file or even a block), MARKERs aren't necessary.
This way, there is not need for FORGET.

--
Coos

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

Coos Haak

unread,
Sep 17, 2009, 1:23:47 PM9/17/09
to
Op Thu, 17 Sep 2009 19:11:13 +0200 schreef Coos Haak:

> Only when you for a debugged piece of code (that you would have

s/you/load/

The Beez'

unread,
Sep 17, 2009, 6:07:45 PM9/17/09
to
On 16 sep, 17:23, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The code to add 'x' number conversion in bigForth is just two lines of code
> in NUMBER.  You may be able to define up to four or six such constants in
> those two lines if you cramp them together.  And you open up your program
> for obfuscation and bugs, e.g.
>
> CHAR m Constant 'n' \ thick fingers hit wrong key
> CHAR z Constant 'x' \ thick fingers hit again!
Some people have defined NOP as being a NO-OPERATION. Very
dangerous..! NIP and NOP are just a key away. One little slip and you
got another bug. And in those late evenings, don't \ and / resemble
one another very much?

It remembers me of C:

if (a = b) c;
if (a == b) | (c != d)
if (a == b) & (c != c)
if (a >> b) c;

Well, did I really hit that second key or didn't I. Lesson: real
programmers never slip up. So that's not an argument. No, %0, 'a' are
just BAD style and very un-Forth like. That's the bottom line. Who
introduced that? C programmers?

Hans Bezemer

The Beez'

unread,
Sep 17, 2009, 6:14:30 PM9/17/09
to
On 16 sep, 12:39, Peter Knaggs <p...@bcs.org.uk> wrote:
> The X:number-prefixes proposal included (polluted the parser with):
>
> #0  \ decimal
> $0  \ hex
> %0  \ binary
> 'a' \ equivalent to char a or [char] a
>
> Thus 'a' is part of the 200x standard.
Sorry, I stand corrected. I didn't notice somebody slipped the
character conversion into that unholy proposal. ;-)

> > Special parsing words like F#, D#, CHAR, etc. are much more Forth-like
> > IMHO.
> Here I agree, but it is true that many systems have provided #, $ and
> others for many years, thus it does make sense to codify this in to the
> standard.  Indeed I recall a paper over 20 years ago which described
> just such an extension.

Well, that is I take the mission of a standards committee very
differently. I have nothing against adding new functionality to a
language (I agreed to plenty proposals), but to me a language standard
is more than a collection of common practices. Those practices should
be tested on their merits. Adopting all kinds of C pollutions just
because there were so many C programmers programming Forth is not my
idea of preserving the Forth heritage.

> According to the records, you where the only systems provider to vote
> against this proposal while seven providers voted for it.  Even I voted
> for the proposal, despite my distaste, due to the proven commonality.

I voted against for the reasons I mentioned above. ;-)

Hans Bezemer

Coos Haak

unread,
Sep 17, 2009, 9:02:25 PM9/17/09
to
Op Thu, 17 Sep 2009 15:07:45 -0700 (PDT) schreef The Beez':

> On 16 sep, 17:23, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> The code to add 'x' number conversion in bigForth is just two lines of code
>> in NUMBER. �You may be able to define up to four or six such constants in
>> those two lines if you cramp them together. �And you open up your program
>> for obfuscation and bugs, e.g.
>>
>> CHAR m Constant 'n' \ thick fingers hit wrong key
>> CHAR z Constant 'x' \ thick fingers hit again!
> Some people have defined NOP as being a NO-OPERATION. Very
> dangerous..! NIP and NOP are just a key away. One little slip and you
> got another bug. And in those late evenings, don't \ and / resemble
> one another very much?
>

Are you serious?
On my keyboard ! and @ are next to each order, like [ and ]
: and ; are on the same key, one could forget to press the shift key!

m_l_g3

unread,
Sep 17, 2009, 11:33:11 PM9/17/09
to
Coos Haak schreef:

That would be a valid argument if FORGET was my innovation and
was not standard since at least Forth-79.

But I do not propose to introduce a new word.

My position is that a word that has always been standard
and IS STILL IN USE after 15 years of being declared
obsolescent, MUST NOT be removed from the standard.

Unlike other words declared obsolescent, FORGET still
inspires *long* threads "MARKER vs FORGET" where
opinions differ radically.


Therefore, FORGET must be VOTED SEPARATELY.

If we decide not to remove FORGET, we can either
leave it as is or remove the obsolescence note.
(Personally I do not mind if it is declared obsolete
provided that it still is standard, but OTOH if we want
to do at least something with obsolete word, removal
of the obsolete mark would seems logical.)

The Beez'

unread,
Sep 18, 2009, 2:36:59 AM9/18/09
to
On 18 sep, 03:02, Coos Haak <chfo...@hccnet.nl> wrote:
> Are you serious?
Of course I'm not serious. I'm just afraid Bernd is ;-)

Hans

Elizabeth D Rather

unread,
Sep 18, 2009, 2:55:27 AM9/18/09
to
m_l_g3 wrote:
> Coos Haak schreef:
...

> My position is that a word that has always been standard
> and IS STILL IN USE after 15 years of being declared
> obsolescent, MUST NOT be removed from the standard.
>
> Unlike other words declared obsolescent, FORGET still
> inspires *long* threads "MARKER vs FORGET" where
> opinions differ radically.
>
>
> Therefore, FORGET must be VOTED SEPARATELY.
>
> If we decide not to remove FORGET, we can either
> leave it as is or remove the obsolescence note.
> (Personally I do not mind if it is declared obsolete
> provided that it still is standard, but OTOH if we want
> to do at least something with obsolete word, removal
> of the obsolete mark would seems logical.)

Although I favor removing FORGET, for reasons I've discussed previously,
I do agree that since there is a body of current use, with vocal
advocacy, it should be removed from that proposal and considered
separately. An important component of a successful standards process is
achieving as much consensus as possible on issues. Although it
certainly is not necessary (often not even possible) to please everyone,
the attempt is worth making.

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

Andrew Haley

unread,
Sep 18, 2009, 4:15:29 AM9/18/09
to
m_l_g3 <m_l...@yahoo.com> wrote:
> I will comment on
> http://groups.google.co.uk/group/comp.lang.forth/msg/fdfab43873c5f37e
> in the context of my proposal.

> ==quote==
> "FORGET assumes that all the information needed to restore the
> dictionary to its previous state is inferable somehow from the
> forgotten word. While this may be true in simple linear dictionary
> models, it is difficult to implement in other Forth systems; e.g.,
> those with multiple address spaces. For example, if Forth is embedded
> in ROM, how does FORGET know how much RAM to recover when an array is
> forgotten? A general and preferred solution is provided by MARKER."
> ==/quote==

> 1. The code field (invisible for an ANS-compliant application but
> visible for the system itself) usually has some kind of pointer
> to the data field,

No it doesn't. There is no reason for a : definition to keep any
pointer into data space. The code field points to code, as you'd
expect.

> so it is technically feasible for the system to restore the RAM
> pointer, provided that the implementors took care to make the code
> fields with the data field in RAM distinguishable from those with
> the data field in ROM.

> 3. The purposes of FORGET and MARKER are different: MARKER is best


> suited for use in source files, while FORGET is better suited for
> interactive use, in the circumstances that it is not practical to
> define MARKERs in advance.

I'm not sure that's really true, and besides, no-one is forbidding
anyone from defining FORGET in their own systems for interactive use,
on those systems where it can be done. There's no point FORGET being
part of the standard TOOLS EXT toolbox.

Andrew.

Peter Knaggs

unread,
Sep 18, 2009, 6:04:40 AM9/18/09
to
m_l_g3 wrote:
>
> Therefore, FORGET must be VOTED SEPARATELY.

Agreed.

Ed

unread,
Sep 18, 2009, 7:32:34 AM9/18/09
to

And we know what the outcome of that will be.

If the TC has any technical integrity it would retract the
rationale which ousted FORGET in the first place. It was,
and remains, a crock of shit.

Bernd Paysan

unread,
Sep 18, 2009, 8:04:38 AM9/18/09
to
Ed wrote:

Fortunately, the personal overlap between this TC and the previous is very
small, it's even not on the same continent (Forth94: American TC, Forth200x:
European TC). So we don't even have to change our minds when thinking
different as the previous TC. The optional tools words (TOOLS-EXT) are a
bunch of words which have all very different merits, and FORGET is certainly
not the worst offender (IMHO it is a rather good tool for the interactive
exploration process). EDITOR is more a joke - I use the editor vocabulary
in my PolyForth inspired block editor for Gforth, but otherwise, even Forth
editors today don't work that way.

Albert van der Horst

unread,
Sep 18, 2009, 1:44:09 PM9/18/09
to
In article <tNmdnRJrvNx8sy7X...@supernews.com>,
Elizabeth D Rather <era...@forth.com> wrote:
<SNIP>

>
>Although I favor removing FORGET, for reasons I've discussed previously,
>I do agree that since there is a body of current use, with vocal
>advocacy, it should be removed from that proposal and considered
>separately. An important component of a successful standards process is
>achieving as much consensus as possible on issues. Although it
>certainly is not necessary (often not even possible) to please everyone,
>the attempt is worth making.

It is not like the standard *forbids* to supply FORGET.
I didn't delete it from my Forth's since I have MARKER.
So what is the fuzz about?

>
>Cheers,
>Elizabeth

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

m_l_g3

unread,
Sep 18, 2009, 5:04:16 PM9/18/09
to

Andrew Haley:


> m_l_g3 <m_l...@yahoo.com> wrote:
> > I will comment on
> > http://groups.google.co.uk/group/comp.lang.forth/msg/fdfab43873c5f37e
> > in the context of my proposal.
>
> > ==quote==
> > "FORGET assumes that all the information needed to restore the
> > dictionary to its previous state is inferable somehow from the
> > forgotten word. While this may be true in simple linear dictionary
> > models, it is difficult to implement in other Forth systems; e.g.,
> > those with multiple address spaces. For example, if Forth is embedded
> > in ROM, how does FORGET know how much RAM to recover when an array is
> > forgotten? A general and preferred solution is provided by MARKER."
> > ==/quote==
>
> > 1. The code field (invisible for an ANS-compliant application but
> > visible for the system itself) usually has some kind of pointer
> > to the data field,
>
> No it doesn't. There is no reason for a : definition to keep any
> pointer into data space. The code field points to code, as you'd
> expect.
>


Let me explain by example.

ROM
: foo 1 . 2 . ;
IRAM VARIABLE myvar1
ZRAM VARIABLE myvar2
FORGET foo

From examining the name space, it is evident that myvar2 follows
myvar1
that follows foo. myvar2 and myvar1 have pointers to the data spaces
while foo has a pointer to the code space, so that the dictionary
pointers may be restored.

On the other hand,

ROM
: foo 1 . 2 . ;
IRAM HERE 1 CELLS ALLOT ROM CONSTANT myvar1
ZRAM HERE 1 CELLS ALLOT ROM CONSTANT myvar2

produces the same code as

ZRAM HERE 1 CELLS ALLOT
IRAM HERE 1 CELLS ALLOT ROM
: foo 1 . 2 . ;
CONSTANT myvar1
CONSTANT myvar2

and so FORGET restore the dictionary pointers defensively.
But the search order IS restored, which is the desired effect.

Andrew Haley

unread,
Sep 19, 2009, 5:08:04 AM9/19/09
to
m_l_g3 <m_l...@yahoo.com> wrote:

> On the other hand,

I take it that you mean by this that FORGET leaks memory, which is, I
think, precisely the point that was made in the quote above that you
were apparently disagreeing with. I am quite beffled about the point
that you were tryiong to make.

Andrew.

Aleksej Saushev

unread,
Sep 19, 2009, 5:20:51 PM9/19/09
to
Andrew Haley <andr...@littlepinkcloud.invalid> writes:

> m_l_g3 <m_l...@yahoo.com> wrote:
>> and so FORGET restore the dictionary pointers defensively.
>> But the search order IS restored, which is the desired effect.
>
> I take it that you mean by this that FORGET leaks memory, which is, I
> think, precisely the point that was made in the quote above that you
> were apparently disagreeing with.

Side note: as you can easily see, MARKER leaks memory as well.
I'm not sure what's all this talk about, but it is obvious, that MARKER
doesn't solve the problem FORGET solves.


--
CE3OH...

Andrew Haley

unread,
Sep 20, 2009, 1:54:56 PM9/20/09
to
Aleksej Saushev <as...@inbox.ru> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>
>> m_l_g3 <m_l...@yahoo.com> wrote:
>>> and so FORGET restore the dictionary pointers defensively.
>>> But the search order IS restored, which is the desired effect.
>>
>> I take it that you mean by this that FORGET leaks memory, which is, I
>> think, precisely the point that was made in the quote above that you
>> were apparently disagreeing with.
>
> Side note: as you can easily see, MARKER leaks memory as well.

No, I can't easily see that. I have no idea why you claim that MARKER
leaks memory, and I don't believe it does. Saying "as you can easily
see" doesn't help at all.

> I'm not sure what's all this talk about, but it is obvious, that
> MARKER doesn't solve the problem FORGET solves.

This is, for me, the big mystery. I don't know why anyone wants
FORGET. The explanation must be that other people's working practices
are very different from anything I've ever done or seen anyone else
do.

Is it really the case that people, rather than winding back all the
dictionary and recompiling the program they're working on, FORGET one
or two words and recompile just them? But why would anyone want to do
that, anyway? I don't get it. If you want to recompile just a few
words, there's no need to FORGET anything, just recompile. I am quite
baffled, really.

Andrew.

Aleksej Saushev

unread,
Sep 21, 2009, 6:54:45 AM9/21/09
to
Andrew Haley <a...@littlepinkcloud.invalid> writes:

> Aleksej Saushev <as...@inbox.ru> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>
>>> m_l_g3 <m_l...@yahoo.com> wrote:
>>>> and so FORGET restore the dictionary pointers defensively.
>>>> But the search order IS restored, which is the desired effect.
>>>
>>> I take it that you mean by this that FORGET leaks memory, which is, I
>>> think, precisely the point that was made in the quote above that you
>>> were apparently disagreeing with.
>>
>> Side note: as you can easily see, MARKER leaks memory as well.
>
> No, I can't easily see that. I have no idea why you claim that MARKER
> leaks memory, and I don't believe it does. Saying "as you can easily
> see" doesn't help at all.

marker this
variable a 100 cells allocate throw a !
variable b 200 cells allocate throw b !
variable c 300 cells allocate throw c !
this

How does it differ from FORGET?

There may be more scenarios than this obvious one.

If you can't restore necessary information from dictionary entry by
calculation, then push silent marker with each word.

>> I'm not sure what's all this talk about, but it is obvious, that
>> MARKER doesn't solve the problem FORGET solves.
>
> This is, for me, the big mystery. I don't know why anyone wants
> FORGET. The explanation must be that other people's working practices
> are very different from anything I've ever done or seen anyone else
> do.
>
> Is it really the case that people, rather than winding back all the
> dictionary and recompiling the program they're working on, FORGET one
> or two words and recompile just them? But why would anyone want to do
> that, anyway? I don't get it. If you want to recompile just a few
> words, there's no need to FORGET anything, just recompile. I am quite
> baffled, really.

Because it is convenient!

If you don't have such experience, you should stay away, shouldn't you?

Yes, it is very convenient to FORGET those words you want to forget
without resubmitting everything just because you forgot to place that
damn MARKER. You should have no need to think ahead only to be able to
recompile just a few words, because there exists well established
practice of handling this particular problem.

You want to kill the practice which exists for 30 years for no reason.


--
CE3OH...

Andrew Haley

unread,
Sep 21, 2009, 7:50:08 AM9/21/09
to
Aleksej Saushev <as...@inbox.ru> wrote:
> Andrew Haley <a...@littlepinkcloud.invalid> writes:

> > Aleksej Saushev <as...@inbox.ru> wrote:
> >> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >>
> >>> m_l_g3 <m_l...@yahoo.com> wrote:
> >>>> and so FORGET restore the dictionary pointers defensively.
> >>>> But the search order IS restored, which is the desired effect.
> >>>
> >>> I take it that you mean by this that FORGET leaks memory, which is, I
> >>> think, precisely the point that was made in the quote above that you
> >>> were apparently disagreeing with.
> >>
> >> Side note: as you can easily see, MARKER leaks memory as well.
> >
> > No, I can't easily see that. I have no idea why you claim that MARKER
> > leaks memory, and I don't believe it does. Saying "as you can easily
> > see" doesn't help at all.

> marker this
> variable a 100 cells allocate throw a !
> variable b 200 cells allocate throw b !
> variable c 300 cells allocate throw c !
> this

> How does it differ from FORGET?

In this case it doesn't, but that's a different example. Neither
FORGET nor MARKER handle dynamically allocated memory automatically.
We can't have any meaningful discussion if you keep changing examples.

> There may be more scenarios than this obvious one.

> If you can't restore necessary information from dictionary entry by
> calculation, then push silent marker with each word.

That's exactly what I said before. FORGET cannot always be correctly
implemented without adding extra information to the dictionary whose
only purpose is to help FORGET. In this specific technical sense I
don't think we really disagree.

> >> I'm not sure what's all this talk about, but it is obvious, that
> >> MARKER doesn't solve the problem FORGET solves.
> >

> > This is, for me, the big mystery. I don't know why anyone wants
> > FORGET. The explanation must be that other people's working
> > practices are very different from anything I've ever done or seen
> > anyone else do.

> > Is it really the case that people, rather than winding back all
> > the dictionary and recompiling the program they're working on,
> > FORGET one or two words and recompile just them? But why would
> > anyone want to do that, anyway? I don't get it. If you want to
> > recompile just a few words, there's no need to FORGET anything,
> > just recompile. I am quite baffled, really.

> Because it is convenient!

> If you don't have such experience, you should stay away, shouldn't
> you?

So tell me.

> Yes, it is very convenient to FORGET those words you want to forget
> without resubmitting everything just because you forgot to place
> that damn MARKER. You should have no need to think ahead only to be
> able to recompile just a few words, because there exists well
> established practice of handling this particular problem.

> You want to kill the practice which exists for 30 years for no
> reason.

Firstly, one reason is above. You even admitted it yourself: "If you


can't restore necessary information from dictionary entry by
calculation, then push silent marker with each word."

Secondly, I don't want to kill FORGET, just destandardize it along
with all the other obsolescent words. Some people will presuambly
continue to use it. Having said that, if this word is still common
practice despite the warning in ANS 94 then I shall vote for it to
stay. However, before I vote for it, I want to know when people use
it and what it's for.

So I'm asking: Is it really the case that people, rather than winding
back all of the dictionary and recompiling the program they're working


on, FORGET one or two words and recompile just them? But why would
anyone want to do that, anyway?

Andrew.

Bernd Paysan

unread,
Sep 21, 2009, 8:16:29 AM9/21/09
to
Andrew Haley wrote:
> So I'm asking: Is it really the case that people, rather than winding
> back all of the dictionary and recompiling the program they're working
> on, FORGET one or two words and recompile just them? But why would
> anyone want to do that, anyway?

It makes sense when you have a slow connection or a slow target, or when
your application is too large to recompile quickly (though nowadays, even
CCS is quite fast to recompile ;-). Or when you enter definitions from the
keyboard, and don't want to type them in all over again (even when they come
from the history, this could be annoying).

A Forth system with several data and code spaces will make implementing
FORGET more difficult than MARKER. However, especially on those systems
with the slow connections to slow targets (more traditional micro-controller
Forths), FORGET is sufficiently easy to implement. That's where the word
makes most sense, anyways.

Ed

unread,
Sep 21, 2009, 8:31:10 AM9/21/09
to
Bernd Paysan wrote:
> Ed wrote:
>
> > Peter Knaggs wrote:
> >> m_l_g3 wrote:
> >> >
> >> > Therefore, FORGET must be VOTED SEPARATELY.
> >>
> >> Agreed.
> >
> > And we know what the outcome of that will be.
> >
> > If the TC has any technical integrity it would retract the
> > rationale which ousted FORGET in the first place. It was,
> > and remains, a crock of shit.
>
> Fortunately, the personal overlap between this TC and the previous is very
> small, it's even not on the same continent (Forth94: American TC, Forth200x:
> European TC). So we don't even have to change our minds when thinking
> different as the previous TC. The optional tools words (TOOLS-EXT) are a
> bunch of words which have all very different merits, and FORGET is certainly
> not the worst offender (IMHO it is a rather good tool for the interactive
> exploration process).

FORGET ended up TOOLS-EXT as it was being demoted - one
assumes on the grounds FORGET couldn't restore state or was
difficult to implement. Neither are true. FORGET was restoring
state at least as far back as 1988 in JForth. It's hard to believe
no-one knew.

I find it unconscionable to restate a rationale that is in serious
doubt - as 200x was planning to do.

As for the practical difference between MARKER and FORGET,
I'm not sure there is much. It may only be the politics.

Ed

unread,
Sep 21, 2009, 8:48:16 AM9/21/09
to
Peter Knaggs wrote:
> Legacy Words
> ============
>
> 2009-09-09 Removed legacy word set in favour of section D.7
> 1998-11-30 Original text by Len Zettel
>
>
> Problem
> =======
> Section 1.4.2 "Obsolescent features" declared seven words as
> obsolescent and warned "they may be withdrawn from future revisions
> of the Standard". It is now 15 years since that warning was issued,
> it is time to remove these words from the document.
>
> In order to do this a number of alterations to the main document
> are required.
>
>
> Proposal
> ========
>
> ...
> 6.1.2450 WORD
> Remove the sentence "A space, not included in the length,
> follows the string" from the second paragraph and the note
> in the definition.

To what end - what does it gain?

'94 referred to the trailing space as "a concession". If that was
intended to imply that the space was somehow unnecessary
then nothing could be further from the truth.

The trailing space in WORD is traditional, historic and therefore
integral. Remove it and you no longer have WORD. Could '94
really have been so naive as to assume WORD would only ever
be used in a Standard Program?

And BTW, '94 even gave users a portable definition for
CONVERT in the event they might need it:

A.6.2.0970 CONVERT
CONVERT may be defined as follows:

: CONVERT CHAR+ 65535 >NUMBER DROP ;

Try to use that with a WORD that lacks a trailing space :)

--
Instead of nobbling WORD, one should be looking at whether
its value can be enhanced without harming the traditional
behaviour.

Recently it was posed whether BL WORD COUNT EVALUATE
within a definition might be a useful tool. I'm not sure we got
an answer to that, but let's assume it is useful.

Whether the phrase above works may depend on how WORD
is implemented. Ensuring a useful implementation of WORD
will be of more practical value to the end user than seeking
to eliminate the trailing space from WORD and the Standard.

Andrew Haley

unread,
Sep 21, 2009, 9:40:58 AM9/21/09
to
Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
> > So I'm asking: Is it really the case that people, rather than winding
> > back all of the dictionary and recompiling the program they're working
> > on, FORGET one or two words and recompile just them? But why would
> > anyone want to do that, anyway?

> It makes sense when you have a slow connection or a slow target, or when
> your application is too large to recompile quickly

It's not as though you usually need to FORGET things, you can just
recompile the words you're changing and leave the old ones in the
dictionary. Eventually you'll run out of space, at which point you
can start again. So even then, there's not much need for FORGET. I'm
trying to find a realistic scenario.

> (though nowadays, even CCS is quite fast to recompile ;-). Or when
> you enter definitions from the keyboard, and don't want to type them
> in all over again (even when they come from the history, this could
> be annoying).

> A Forth system with several data and code spaces will make
> implementing FORGET more difficult than MARKER.

That's right. And, what's worse, if you support FORGET then that
machinery is there regardless of whether anyone uses it.

> However, especially on those systems with the slow connections to
> slow targets (more traditional micro-controller Forths),

Oh, come on now. Even on an 8051 with an RS232 serial link it's going
to take maybe 20s reload everything. Sure, memories have got a lot
bigger than that, but serial links have got a lot faster too.

> FORGET is sufficiently easy to implement. That's where the word
> makes most sense, anyways.

Perhaps, but if it's standard then it's everywhere, or at least
everywhere that has CORE EXT.

Andrew.

Aleksej Saushev

unread,
Sep 21, 2009, 10:09:02 AM9/21/09
to
Andrew Haley <andr...@littlepinkcloud.invalid> writes:

> Aleksej Saushev <as...@inbox.ru> wrote:
>
>> If you can't restore necessary information from dictionary entry by
>> calculation, then push silent marker with each word.
>
> That's exactly what I said before. FORGET cannot always be correctly
> implemented without adding extra information to the dictionary whose
> only purpose is to help FORGET. In this specific technical sense I
> don't think we really disagree.

Doesn't MARKER save all this "extra" information to the dictionary?

Why don't you propose to destandardize MARKER?
You can continue using it, but... outside the standard.

> Some people will presuambly
> continue to use it. Having said that, if this word is still common
> practice despite the warning in ANS 94 then I shall vote for it to
> stay. However, before I vote for it, I want to know when people use
> it and what it's for.
>
> So I'm asking: Is it really the case that people, rather than winding
> back all of the dictionary and recompiling the program they're working
> on, FORGET one or two words and recompile just them? But why would
> anyone want to do that, anyway?

Because even today some people prefer interactive incremental
development instead of edit-load-test loop. I don't know how many words
I need to FORGET in 5 minutes. Maybe one, maybe two, maybe two dozens.
What you do is enforcing your personal development style on others,
only because you don't understand the other way. You can easily see from
practice in other languages that you don't need to forget anything at all,
why don't you follow them?


It comes that all standard zealots are pursuing their own goals and
don't even try to think outside their own box: you don't understand what
FORGET is for, others don't understand what wide characters are for.
If this is the way Forth community works, no wonder it is in such poor state.


--
CE3OH...

Coos Haak

unread,
Sep 21, 2009, 12:49:41 PM9/21/09
to
Op Mon, 21 Sep 2009 22:48:16 +1000 schreef Ed:

<snip>


> Try to use that with a WORD that lacks a trailing space :)

You can't, assuming the implementation has a standard WORD with added
reference to CONVERT:

6.1.2450 WORD
CORE ...
Note: The requirement to follow the string with a space is obsolescent
and is included as a concession to existing programs that use CONVERT.
A program shall not depend on the existence of the space.
...
So an implementation without a blank after the string delivered by
WORD can't use CONVERT portably.

Yet another reason to use c-addr u strings. Like PARSE-NAME delivers
and >NUMBER expects.

Andrew Haley

unread,
Sep 21, 2009, 2:32:12 PM9/21/09
to
Aleksej Saushev <as...@inbox.ru> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:

> > Aleksej Saushev <as...@inbox.ru> wrote:
> >
> >> If you can't restore necessary information from dictionary entry by
> >> calculation, then push silent marker with each word.
> >
> > That's exactly what I said before. FORGET cannot always be correctly
> > implemented without adding extra information to the dictionary whose
> > only purpose is to help FORGET. In this specific technical sense I
> > don't think we really disagree.

> Doesn't MARKER save all this "extra" information to the dictionary?

Yes, but only where it's needed. With FORGET you have to save this
stuff whenever anything changes, just in case FORGET wants it. As we
both know, I think; I don't know why you're asking.

a. MARKER isn't obsolescent.
b. FORGET isn't good enough, as discussed.

> > Some people will presuambly continue to use it. Having said that,
> > if this word is still common practice despite the warning in ANS
> > 94 then I shall vote for it to stay. However, before I vote for
> > it, I want to know when people use it and what it's for.
> >
> > So I'm asking: Is it really the case that people, rather than
> > winding back all of the dictionary and recompiling the program
> > they're working on, FORGET one or two words and recompile just
> > them? But why would anyone want to do that, anyway?

> Because even today some people prefer interactive incremental
> development instead of edit-load-test loop.

Me too.

> I don't know how many words I need to FORGET in 5 minutes. Maybe
> one, maybe two, maybe two dozens.

Maybe I'd understand a lot better if I stood over your shoulder and
watched you work. Having to keep typing FORGET FOO whenever I wanted
to recompile would annoy the hell out of me, for sure.

> What you do is enforcing your personal development style on others,
> only because you don't understand the other way.

I'm trying to understand, though. That's why I'm asking. All I keep
getting is "I use it." But your explanations don't make any sense.
For example, you said "You should have no need to think ahead only to
be able to recompile just a few words..." but you don't need to FORGET
anything, just recompile. The old definitions will still be in the
dictionary, but so what?

> You can easily see from practice in other languages that you don't
> need to forget anything at all, why don't you follow them?

Is this a serious question?

> It comes that all standard zealots are pursuing their own goals and
> don't even try to think outside their own box: you don't understand
> what FORGET is for, others don't understand what wide characters are
> for.

I think that's an unfair criticism. I'm trying to find out what
FORGET is for before making any kind of a decision onw hether it
should stay, and to do that I need to ask those who still use it.

Along with everyone else who was writing Forth before ANS I used
FORGET all the time, so it's not as though I don't know what it's for.
I just don't understand why anyone still uses it today.

> If this is the way Forth community works, no wonder it is in such
> poor state.

It's the nature of standardization. Some folks want X and some other
folks have no idea why anyone would want X, so the folks who want X
get to explain why they want it and persuade the other folks why it's
useful. That's how it's supposed to work.

Andrew.

Elizabeth D Rather

unread,
Sep 21, 2009, 5:53:10 PM9/21/09
to
Ed wrote:
...

> FORGET ended up TOOLS-EXT as it was being demoted - one
> assumes on the grounds FORGET couldn't restore state or was
> difficult to implement. Neither are true. FORGET was restoring
> state at least as far back as 1988 in JForth. It's hard to believe
> no-one knew.
>
> I find it unconscionable to restate a rationale that is in serious
> doubt - as 200x was planning to do.
>
> As for the practical difference between MARKER and FORGET,
> I'm not sure there is much. It may only be the politics.

To repeat prior arguments: It is certainly possible for FORGET to
restore certain aspects of the system state, such as dictionary
pointers, but it's hard for FORGET to know that it should restore a
changed interrupt pointer, release certain ALLOCATions but not others,
etc. The charm of MARKER is that it can easily be extended to add a
list of things that must be restored to a clearly-defined state.

The thing is, it was a lot easier to implement FORGET in 1988 than it
was even a few years later, because systems have gotten a lot more complex.

Elizabeth D Rather

unread,
Sep 21, 2009, 6:02:25 PM9/21/09
to
Aleksej Saushev wrote:
> Andrew Haley <a...@littlepinkcloud.invalid> writes:
...

>> Is it really the case that people, rather than winding back all the
>> dictionary and recompiling the program they're working on, FORGET one
>> or two words and recompile just them? But why would anyone want to do
>> that, anyway? I don't get it. If you want to recompile just a few
>> words, there's no need to FORGET anything, just recompile. I am quite
>> baffled, really.
>
> Because it is convenient!

How is it more convenient to say:

FORGET FOO
INCLUDE STUFF

...than just saying:

INCLUDE STUFF

...where STUFF either has a MARKER at the beginning or else just adds
another copy of its code?

Recompiling the whole program was more onerous in the 70's and 80's when
computers and FORTHs were a lot slower, but nowadays even quite large
programs load in <1 sec, so the tradeoffs have changed a lot.

> If you don't have such experience, you should stay away, shouldn't you?

I think Andrew's experience (and mine) is different from yours, and it's
helpful in a discussion such as this to hear from folks with different
experiences.

> Yes, it is very convenient to FORGET those words you want to forget
> without resubmitting everything just because you forgot to place that
> damn MARKER. You should have no need to think ahead only to be able to
> recompile just a few words, because there exists well established
> practice of handling this particular problem.
>
> You want to kill the practice which exists for 30 years for no reason.

We stopped using FORGET in the early 90's, and it was no loss.

Elizabeth D Rather

unread,
Sep 21, 2009, 6:09:45 PM9/21/09
to
Aleksej Saushev wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>
>> Aleksej Saushev <as...@inbox.ru> wrote:
>>
>>> If you can't restore necessary information from dictionary entry by
>>> calculation, then push silent marker with each word.
>> That's exactly what I said before. FORGET cannot always be correctly
>> implemented without adding extra information to the dictionary whose
>> only purpose is to help FORGET. In this specific technical sense I
>> don't think we really disagree.
>
> Doesn't MARKER save all this "extra" information to the dictionary?

Of course, but it's saved when the MARKER is defined. FORGET has to
save it with every single definition.

...


>
> It comes that all standard zealots are pursuing their own goals and
> don't even try to think outside their own box: you don't understand what
> FORGET is for, others don't understand what wide characters are for.
> If this is the way Forth community works, no wonder it is in such poor state.

Standards discussions are extensive and public, as is this one, for the
very reason that it's useful to have a dialog with people of differing
backgrounds and working styles. We can all learn from each other.

Bernd Paysan

unread,
Sep 22, 2009, 4:23:47 AM9/22/09
to
Elizabeth D Rather wrote:
>> Doesn't MARKER save all this "extra" information to the dictionary?
>
> Of course, but it's saved when the MARKER is defined. FORGET has to
> save it with every single definition.

The way FORGET is usually implemented doesn't require saving "extra"
information in the dictionary. FORGET tries to find out what to remove by
looking at the word it gets, and by walking through lists (vocabularies,
chained wordlists, etc). These lists are there anyways. There are corner
cases where FORGET can't figure out what to remove, like the following:

vocabulary a
vocabulary b
a definitions
ROM
: foo ... ;
RAM
b definitions
: bar ... ;
...

forget foo

Now, FORGET will likely not remove bar, because it's in a different
vocabulary. It's probably not worth bothering, because systems with this
kind of address space will have troubles to implement MARKER as well (when
"ROM" really is a flash, and can only be erased in one big block).

But what's true is that FORGET is much more useful on slow systems, so on
current PCs, neither FORGET nor MARKER is really used much.

Elizabeth D Rather

unread,
Sep 22, 2009, 5:26:26 AM9/22/09
to
Bernd Paysan wrote:
> Elizabeth D Rather wrote:
>>> Doesn't MARKER save all this "extra" information to the dictionary?
>> Of course, but it's saved when the MARKER is defined. FORGET has to
>> save it with every single definition.
>
> The way FORGET is usually implemented doesn't require saving "extra"
> information in the dictionary. FORGET tries to find out what to remove by
> looking at the word it gets, and by walking through lists (vocabularies,
> chained wordlists, etc). These lists are there anyways.

That's why it's so hard to deal with added stuff that has to be done,
which may not be represented in the linked list.

> There are corner
> cases where FORGET can't figure out what to remove, like the following:
>
> vocabulary a
> vocabulary b
> a definitions
> ROM
> : foo ... ;
> RAM
> b definitions
> : bar ... ;
> ...
>
> forget foo
>
> Now, FORGET will likely not remove bar, because it's in a different
> vocabulary. It's probably not worth bothering, because systems with this
> kind of address space will have troubles to implement MARKER as well (when
> "ROM" really is a flash, and can only be erased in one big block).

Yes, flash requires special management, but MARKER is still useful in
embedded systems where at least some of your program may be in RAM
during development. And the fact that you can redefine MARKER to reset
additional stuff is very valuable.

> But what's true is that FORGET is much more useful on slow systems, so on
> current PCs, neither FORGET nor MARKER is really used much.

On the contrary, I find MARKER to be extremely useful in PCs, because it
can save you having to re-launch Forth and do various setup steps that
may be necessary in development. We always organize the application
with its own INCLUDE file, so it's easy to reload it (and of course it
begins with a MARKER).

Bernd Paysan

unread,
Sep 22, 2009, 5:56:33 AM9/22/09
to
Elizabeth D Rather wrote:
>> But what's true is that FORGET is much more useful on slow systems, so on
>> current PCs, neither FORGET nor MARKER is really used much.
>
> On the contrary, I find MARKER to be extremely useful in PCs, because it
> can save you having to re-launch Forth and do various setup steps that
> may be necessary in development. We always organize the application
> with its own INCLUDE file, so it's easy to reload it (and of course it
> begins with a MARKER).

Well, the command line is my friend - when I have to do that, I put the
load+launch stuff in the command line. On Windows, I can imagine that it
becomes more difficult (though I certainly install Cygwin on Windows first,
and then start an X server to have my xterm+bash as command line).

Relaunching an app is just cursor up+return in the console. And it works
even when the app/Forth system crashed.

Albert van der Horst

unread,
Sep 22, 2009, 6:59:57 AM9/22/09
to
In article <h97rft$63o$1...@news-01.bur.connect.com.au>,

Ed <nos...@invalid.com> wrote:
>
>FORGET ended up TOOLS-EXT as it was being demoted - one
>assumes on the grounds FORGET couldn't restore state or was
>difficult to implement. Neither are true. FORGET was restoring
>state at least as far back as 1988 in JForth. It's hard to believe
>no-one knew.

FORGET was restoring state before 1980 in FYSFORTH.
This was at the expense of adding FORGET-FIELDS that point
to code that had to be executed in forgetting a word.
It is clear that you can do anything this way, and that it
would be an abomination in the eyes of Chuck Moore.

Aleksej Saushev

unread,
Sep 22, 2009, 7:53:28 AM9/22/09
to
Elizabeth D Rather <era...@forth.com> writes:

> Aleksej Saushev wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>
>>> Aleksej Saushev <as...@inbox.ru> wrote:
>>>
>>>> If you can't restore necessary information from dictionary entry by
>>>> calculation, then push silent marker with each word.
>>> That's exactly what I said before. FORGET cannot always be correctly
>>> implemented without adding extra information to the dictionary whose
>>> only purpose is to help FORGET. In this specific technical sense I
>>> don't think we really disagree.
>>
>> Doesn't MARKER save all this "extra" information to the dictionary?
>
> Of course, but it's saved when the MARKER is defined. FORGET
> has to save it with every single definition.

It doesn't matter on PCs, but it is hell convenient at the same time.


--
CE3OH...

Ed

unread,
Sep 24, 2009, 4:52:29 AM9/24/09
to
Albert van der Horst wrote:
> In article <h97rft$63o$1...@news-01.bur.connect.com.au>,
> Ed <nos...@invalid.com> wrote:
> >
> >FORGET ended up TOOLS-EXT as it was being demoted - one
> >assumes on the grounds FORGET couldn't restore state or was
> >difficult to implement. Neither are true. FORGET was restoring
> >state at least as far back as 1988 in JForth. It's hard to believe
> >no-one knew.
>
> FORGET was restoring state before 1980 in FYSFORTH.

Thanks for the update. It demonstrates restoration schemes
for FORGET existed long before MARKER.

> This was at the expense of adding FORGET-FIELDS that point
> to code that had to be executed in forgetting a word.
> It is clear that you can do anything this way, and that it
> would be an abomination in the eyes of Chuck Moore.

JForth's scheme maintains a linked list of xt's.

IIRC polyForth used something similiar to restore MS-DOS
interrupt vectors.

Ed

unread,
Sep 24, 2009, 4:45:56 AM9/24/09
to
Coos Haak wrote:
> Op Mon, 21 Sep 2009 22:48:16 +1000 schreef Ed:
>
> <snip>
> > Try to use that with a WORD that lacks a trailing space :)
> You can't, assuming the implementation has a standard WORD with added
> reference to CONVERT:

WORD is currently "required" to have the trailing space. Hence
it works with CONVERT and any old program that may require
the space.

200x wants to remove the space.

> Yet another reason to use c-addr u strings. Like PARSE-NAME delivers
> and >NUMBER expects.

BL WORD COUNT delivers c-addr u strings when needed.

Ed

unread,
Sep 24, 2009, 6:33:23 AM9/24/09
to
Elizabeth D Rather wrote:
> Ed wrote:
> ...
> > FORGET ended up TOOLS-EXT as it was being demoted - one
> > assumes on the grounds FORGET couldn't restore state or was
> > difficult to implement. Neither are true. FORGET was restoring
> > state at least as far back as 1988 in JForth. It's hard to believe
> > no-one knew.
> >
> > I find it unconscionable to restate a rationale that is in serious
> > doubt - as 200x was planning to do.
> >
> > As for the practical difference between MARKER and FORGET,
> > I'm not sure there is much. It may only be the politics.
>
> To repeat prior arguments: It is certainly possible for FORGET to
> restore certain aspects of the system state, such as dictionary
> pointers, but it's hard for FORGET to know that it should restore a
> changed interrupt pointer, release certain ALLOCATions but not others,
> etc.

I challenged that the last time around but apparently it was
ignored.

Perhaps a demo will convince.

\ TESTFORG.F

defer TEST

: action0 cr ." Action= 0" ;
: action1 cr ." Action= 1" ;
: action2 cr ." Action= 2" ;
: action3 cr ." Action= 3" ;

' action0 is test test

: TASK1 ;
:noname ['] action0 is test ; remember
' action1 is test test

: TASK2 ;
:noname ['] action1 is test ; remember
' action2 is test test

: TASK3 ;
:noname ['] action2 is test ; remember
' action3 is test test

forget task3 test
forget task2 test
forget task1 test

\ end

include testforg
Action= 0
Action= 1
Action= 2
Action= 3
Action= 2
Action= 1
Action= 0 ok

--
The criticism made elsewhere that FORGET can be inconvenient
to use in some situations, happens also to be true of MARKER.
Consequently several forths went on to define ANEW.

FORGET may also be used to define ANEW :

: ANEW ( "name" )
>in @ bl word find nip
if dup >in ! forget then >in ! create ;

--

FORGET is fine. MARKER offers nothing better - it's just
different.

Andrew Haley

unread,
Sep 24, 2009, 7:12:35 AM9/24/09
to
Ed <nos...@invalid.com> wrote:
> Elizabeth D Rather wrote:
> > Ed wrote:
> > ...
> > > FORGET ended up TOOLS-EXT as it was being demoted - one
> > > assumes on the grounds FORGET couldn't restore state or was
> > > difficult to implement. Neither are true. FORGET was restoring
> > > state at least as far back as 1988 in JForth. It's hard to believe
> > > no-one knew.
> > >
> > > I find it unconscionable to restate a rationale that is in serious
> > > doubt - as 200x was planning to do.
> > >
> > > As for the practical difference between MARKER and FORGET,
> > > I'm not sure there is much. It may only be the politics.
> >
> > To repeat prior arguments: It is certainly possible for FORGET to
> > restore certain aspects of the system state, such as dictionary
> > pointers, but it's hard for FORGET to know that it should restore
> > a changed interrupt pointer, release certain ALLOCATions but not
> > others, etc.

> I challenged that the last time around but apparently it was
> ignored.

It wasn't ignored, it was disagreed with.

> Perhaps a demo will convince.

You seem to have a new word, REMEMBER. I don't know what exactly
REMEMBER does, but I presume that it's some magic that inserts a word
to be executed when the dictionary pointers are unwound. REMEMBER
exists, presumably, to support FORGET. This is somewhat interesting,
but pointless given MARKER, which does what's needed, is already
standard, and doesn't require any such mechanisms to achieve the same
thing.

Andrew.

Ed

unread,
Sep 24, 2009, 9:01:06 AM9/24/09
to
Andrew Haley wrote:
> Ed <nos...@invalid.com> wrote:
> > Elizabeth D Rather wrote:
> > > Ed wrote:
> > > ...
> > > > FORGET ended up TOOLS-EXT as it was being demoted - one
> > > > assumes on the grounds FORGET couldn't restore state or was
> > > > difficult to implement. Neither are true. FORGET was restoring
> > > > state at least as far back as 1988 in JForth. It's hard to believe
> > > > no-one knew.
> > > >
> > > > I find it unconscionable to restate a rationale that is in serious
> > > > doubt - as 200x was planning to do.
> > > >
> > > > As for the practical difference between MARKER and FORGET,
> > > > I'm not sure there is much. It may only be the politics.
> > >
> > > To repeat prior arguments: It is certainly possible for FORGET to
> > > restore certain aspects of the system state, such as dictionary
> > > pointers, but it's hard for FORGET to know that it should restore
> > > a changed interrupt pointer, release certain ALLOCATions but not
> > > others, etc.
>
> > I challenged that the last time around but apparently it was
> > ignored.
>
> It wasn't ignored, it was disagreed with.

I'm not sure which would be worse - having you as an enemy,
or a defender.

> > Perhaps a demo will convince.
>
> You seem to have a new word, REMEMBER. I don't know what exactly
> REMEMBER does, but I presume that it's some magic that inserts a word
> to be executed when the dictionary pointers are unwound. REMEMBER
> exists, presumably, to support FORGET. This is somewhat interesting,
> but pointless given MARKER, which does what's needed, is already
> standard, and doesn't require any such mechanisms to achieve the same
> thing.

Attacking someone with blissful ignorance doesn't work very well.

Bernd was right.

Andrew Haley

unread,
Sep 24, 2009, 10:33:42 AM9/24/09