RfD: Legacy Word
Peter Knaggs
============
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
> 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
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
>
> 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'
[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
>
> [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
> 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
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
>
> 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
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
Calm yourself.
So far the OP has only asked for FORGET to be retained.
Peter Knaggs
> 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
> 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
For anyone who wants to know what was actually said,
http://groups.google.co.uk/group/comp.lang.forth/msg/26f32519c8778f1a
Andrew.
Bernd Paysan
> 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
> 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
>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
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
<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
> Only when you for a debugged piece of code (that you would have
s/you/load/
The Beez'
> 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!
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'
> 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.
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
> 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
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'
> Are you serious?
Of course I'm not serious. I'm just afraid Bernd is ;-)
Hans
Elizabeth D Rather
> 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
> 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
>
> Therefore, FORGET must be VOTED SEPARATELY.
Agreed.
Ed
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
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
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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
<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
> 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
...
> 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
> 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
> 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
>> 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
> 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
>> 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
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
> 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
> 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
> 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
> 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
> 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
> 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
This is a repeating pattern. Someone presents an argument that rebuts
your point, you fail to address any of the relevant technical points
but respond only with abuse, and you later claim that you have been
ignored. You have not been ignored: you have been answered.
> Bernd was right.
Bernd is frequently right and sometimes wrong.
Enough. Can you actually address the points I made, or not?
Andrew.
Coos Haak
What about:
: ANEW
>IN @ PARSE-NAME ROT >IN ! FIND-XT 2DROP EXECUTE MARKER
;
This:...
defer TEST
: action0 cr ." Action= 0" ;
: action1 cr ." Action= 1" ;
: action2 cr ." Action= 2" ;
: action3 cr ." Action= 3" ;
' action0 is test test
MARKER TASK1
:noname ['] action0 is test ; remember
' action1 is test test
MARKER TASK2
:noname ['] action1 is test ; remember
' action2 is test test
MARKER TASK3
:noname ['] action2 is test ; remember
' action3 is test test
task3 test
task2 test
task1 test
\ end
... gives exactly the same result, no need for FORGET
Stephen Pelc
<andr...@littlepinkcloud.invalid> wrote:
>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.
Oh yes it does! If your code affects existing data below the cut
point, that data needs to be restored, e.g. DEFERred words. You
can argue that all such words should have hooks into the MARKER
chains and a list-of-lists. In practice, application programmers
just don't do this!
MARKER is easier for the system implementer than FORGET because
there's less baggage for each word. In the real world, neither
MARKER nor FORGET are 100% reliable, which is why most users of
hosted systems get used to recompiling from scratch.
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
Andrew Haley
> On Thu, 24 Sep 2009 06:12:35 -0500, Andrew Haley
> <andr...@littlepinkcloud.invalid> wrote:
> >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.
> Oh yes it does! If your code affects existing data below the cut
> point, that data needs to be restored, e.g. DEFERred words.
But you don't need any hooks, just
marker foo
: foo unhook-deferred-words foo ;
(Is this legal ANS? You're executing foo after it's been removed from
the dictionary. Dunno, but it's what people do, and it works.)
> You can argue that all such words should have hooks into the MARKER
> chains and a list-of-lists. In practice, application programmers
> just don't do this!
> MARKER is easier for the system implementer than FORGET because
> there's less baggage for each word. In the real world, neither
> MARKER nor FORGET are 100% reliable, which is why most users of
> hosted systems get used to recompiling from scratch.
I suspect that's mostly because it's so fast to do so. That, and you
might have corrupted the dictionary.
Andrew.
Bernd Paysan
> 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.
MARKER doesn't do things like revectoring deferred words by default. At
least not the implementations I've made (it's not implemented through
copy-on-write and forking the process). You can have REMEMBER for
FORGET-based dictionary housekeeping or for MARKER-based dictionary
house-keeping. REMEMBER is for all cases where MARKER or FORGET have no
idea how to resolve problems.
As Stephen points out, any sufficiently large application is riddled
with this kind of stuff, and therefore you'd better forget about MARKER
and FORGET, and recompile from scratch. Example: The OOF I use in MINOS
allows to define methods in any order. So you can have some thing like
a implements
: foo ... ;
class;
marker forget-c
class c
...
class;
b implements
: bar ... ( e.g. using the new class c) ;
class;
Now what happens if you call forget-c or FORGET C? The previously
defined BAR method in b is no longer reachable - and needs to be
revectored to the previous (inherited) definition to restore the state.
The OOF is layered on top of the host system, and not hooked into any
MARKER or FORGET logic. Nothing doing? Nothing doing! Note that the
inherited function is not remembered anywhere - it's not sufficient to
look at the parent class, because that definition there might have been
changed later, too (not good style, but possible).
Words like REMEMBER would provide possible ways out. But IMHO, they are
crude tools for a problem that over-complicates the system anyways.
Recompile from scratch, and the problem goes away.
IMHO, the points where MARKER is supposed to be superior to FORGET (in
some more complex systems) are straw men. You don't use MARKER or
FORGET in complex systems, because big Forths run on big machines, where
recompiling from scratch is a no-brainer. You use them on simple
systems where speed is an issue, especially download speed, and there,
FORGET just works. MARKER just works, as well, but it requires
planning. I use FORGET only during the explorative part of development,
i.e. *before* I start thinking about making plans. Planned software is
already ways too complex to do anything else than recompile from
scratch.
Andrew Haley
> Andrew Haley wrote:
> > 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.
> MARKER doesn't do things like revectoring deferred words by default.
Certainly not, no, and I don't think anyone suggested that it did.
However, it's trivial to add anything you want to your MARKER without
needing any hooks.
> Words like REMEMBER would provide possible ways out. But IMHO, they
> are crude tools for a problem that over-complicates the system
> anyways. Recompile from scratch, and the problem goes away.
That seems reasonable.
> IMHO, the points where MARKER is supposed to be superior to FORGET
> (in some more complex systems) are straw men. You don't use MARKER
> or FORGET in complex systems, because big Forths run on big
> machines, where recompiling from scratch is a no-brainer.
Well, hold on: even on big machines it's perfectly reasonable to
rewind the system back to a start point, and MARKER is a perfectly
reasonable way to do that. MARKER is nice, simple, and does its job.
Andrew.
Elizabeth D Rather
...
>
> IIRC polyForth used something similiar to restore MS-DOS
> interrupt vectors.
Yes, almost everyone working on complex systems wrestled with this
problem in various ways. MARKER was developed by a group of such
veterans, and FORTH, Inc. as well as others have been satisfied with it
since.
Josh Grams
> 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.
I can see what you're trying to demonstrate, but I don't *think* it
solves the problem that makes implementing FORGET look "difficult" to
me. Which is...
What if I want FORGET to automatically restore the state of a deferred
word? i.e. I want to extend FORGET such that I can delete the REMEMBER
lines from your demo and have it still work.
You could try redefining the runtime action of IS to add an entry to the
remember list if it is setting TEST. But that's fragile: what if DEFER
is defined as `CREATE ['] NOOP , DOES> @ EXECUTE` and the programmer
sets it with `' test >body !` in one case? FORGET would have no idea
that it changed, and thus no way to restore it.
Now take MARKER. When a marker is created, it can take a snapshot of
any data it needs. And as with REMEMBER, you could have a method for
extending it to save/restore more data. Maybe something like this:
\ TESTFORG.F
defer TEST
:noname ACTION-OF TEST , ;
:noname @ IS TEST ;
EXTEND-MARKER
: action0 cr ." Action= 0" ;
: action1 cr ." Action= 1" ;
: action2 cr ." Action= 2" ;
: action3 cr ." Action= 3" ;
' action0 is test test
marker TASK1
' action1 is test test
marker TASK2
' action2 is test test
marker TASK3
' action3 is test test
task3 test
task2 test
task1 test
\ end
include testforg
Action= 0
Action= 1
Action= 2
Action= 3
Action= 2
Action= 1
Action= 0 ok
Obviously this is a contrived example. But you could, for instance,
extend MARKER similarly to scan through the dictionary and save/restore
the values of all deferred words.
--
Or take the example that I gave last time. If you have an STC Forth
with separate data/code/name spaces, there's no particular reason to
have a pfa field (is that the term I want? data address, anyway) in your
header. And without that, FORGET can't necessarily figure out what
value to rewind HERE to from the name. Again, you could extend ALLOT,
comma, and so on to add to the remember list whenever HERE is changed,
but if someone went outside the usual channels and modified DP (or
whatever it's called in the system you're using) directly, FORGET
wouldn't know about it.
--
Am I making sense at all? Can you see how these look different to me
than the problem to which you are demonstrating a solution? Am I
missing something obvious? I just can't see any good way to have FORGET
handle these sorts of cases. But I'm always ready to learn new tricks.
--Josh
Anton Ertl
>IMHO the introduction of 'a' does away with the need for [CHAR]
>but not CHAR.
Why not CHAR?
- 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/
Bernd Paysan
> Well, hold on: even on big machines it's perfectly reasonable to
> rewind the system back to a start point, and MARKER is a perfectly
> reasonable way to do that. MARKER is nice, simple, and does its job.
Rewinding to "the" start point can be much easier, like the word EMPTY
demonstrates. This will remove all user-defined stuff after startup, and
apart from that it doesn't restore everything, it's almost as good as a
restart from scratch. I use EMPTY in Gforth EC, because it *also* can erase
the user program part of the flash, something neither MARKER nor FORGET
could do in such an environment (4k flash block size, 1k RAM - where do you
store the partial content? ;-).
Anton Ertl
>marker foo
>: foo unhook-deferred-words foo ;
>
>(Is this legal ANS? You're executing foo after it's been removed from
>the dictionary.
More precisely, you are performing the part of the second foo that's
after the call to the first foo, i.e., after the first foo has removed
both foos from the dictionary. That probably should be non-standard
(consider what happens if the part after calling the first foo ALLOTs
from the dictionary and writes there), but I am not sure that it is.
> Dunno, but it's what people do, and it works.)
Only if people actually call foo. If they call another marker, that
part will not be performed.
Elizabeth D Rather
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> marker foo
>> : foo unhook-deferred-words foo ;
>>
>> (Is this legal ANS? You're executing foo after it's been removed from
>> the dictionary.
>
> More precisely, you are performing the part of the second foo that's
> after the call to the first foo, i.e., after the first foo has removed
> both foos from the dictionary. That probably should be non-standard
> (consider what happens if the part after calling the first foo ALLOTs
> from the dictionary and writes there), but I am not sure that it is.
>
>> Dunno, but it's what people do, and it works.)
>
> Only if people actually call foo. If they call another marker, that
> part will not be performed.
It works because the fact that a word has been unhooked from the
dictionary chain and memory pointers adjusted doesn't necessarily imply
that the memory containing the second foo has been altered. In all the
implementations I know of, that won't happen until either the text
interpreter, a defining word, or some other function writes in the space
currently occupied by foo, as Anton says.
AFAIK ANS Forth doesn't address this issue one way or another. If
you're concerned about it, write a proposal :-)
Ed
> Ed wrote:
> ...
> >
> > IIRC polyForth used something similiar to restore MS-DOS
> > interrupt vectors.
>
> Yes, almost everyone working on complex systems wrestled with this
> problem in various ways. MARKER was developed by a group of such
> veterans, and FORTH, Inc. as well as others have been satisfied with it
> since.
The restorative scheme JForth employed also works and does
so with FORGET. Until it can be demonstrated to be wanting,
it remains a valid technique. Morse so, as it is simple.
Ed
> ...
> What about:
> : ANEW
> >IN @ PARSE-NAME ROT >IN ! FIND-XT 2DROP EXECUTE MARKER
> ;
> This:...
> defer TEST
>
> : action0 cr ." Action= 0" ;
> : action1 cr ." Action= 1" ;
> : action2 cr ." Action= 2" ;
> : action3 cr ." Action= 3" ;
>
> ' action0 is test test
>
> MARKER TASK1
> ...
> task3 test
> task2 test
> task1 test
>
> \ end
> ... gives exactly the same result, no need for FORGET
My task is to show that FORGET works in all practical
situations and MARKER is obsolete.
Forth has no need for PARSE-NAME either.
Ed
> ...
> MARKER is easier for the system implementer than FORGET because
> there's less baggage for each word.
I implemented FORGET on a three segment dictionary.
The restoring scheme used http://www.softsynth.com/jforth/
requires no baggage. Works with MARKER too.
> In the real world, neither
> MARKER nor FORGET are 100% reliable, which is why most users of
> hosted systems get used to recompiling from scratch.
In what respect have you found it unreliable? Doing complex
restores could prove daunting (and perhaps not worth the effort).
p.s. I couldn't work out how to use PRUNE: on VFX. Some
examples and/or extra docs would be useful.
Coos Haak
And mine is to show that MARKER works in all practical situations and
FORGET is obsolete ;-)
Forth has no need for WORD either ;-)
In my Forth, WORD and FIND are in a loadable extension.
I use c-addr u strings all over.
Perhaps not standard. I don't like manipulation counted strings.
I use them though, in definitions with S" and ."
m_l_g3
> Anton Ertl wrote:
> > Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> >> marker foo
> >> : foo unhook-deferred-words foo ;
> >>
> >> (Is this legal ANS? You're executing foo after it's been removed from
> >> the dictionary.
> >
> > More precisely, you are performing the part of the second foo that's
> > after the call to the first foo, i.e., after the first foo has removed
> > both foos from the dictionary. That probably should be non-standard
> > (consider what happens if the part after calling the first foo ALLOTs
> > from the dictionary and writes there), but I am not sure that it is.
> >
> >> Dunno, but it's what people do, and it works.)
> >
> > Only if people actually call foo. If they call another marker, that
> > part will not be performed.
>
> It works because the fact that a word has been unhooked from the
> dictionary chain and memory pointers adjusted doesn't necessarily imply
> that the memory containing the second foo has been altered. In all the
> implementations I know of, that won't happen until either the text
> interpreter, a defining word, or some other function writes in the space
> currently occupied by foo, as Anton says.
>
> AFAIK ANS Forth doesn't address this issue one way or another. If
> you're concerned about it, write a proposal :-)
>
Well, that's an excellent idea!
MARKER should ERASE the memory that it frees, to prevent
at least theoretically possible interference from old data.
:-)
m_l_g3
> Op Sat, 26 Sep 2009 14:04:32 +1000 schreef Ed:
> > My task is to show that FORGET works in all practical
> > situations and MARKER is obsolete.
> And mine is to show that MARKER works in all practical situations and
> FORGET is obsolete ;-)
We see that the community is split.
This happened because MARKER, invented by the TC, was not superior
to FORGET (each one is no worse and no better than the other),
and because they do a bit different things.
Coos Haak
MARKER must be years older than the TC (1994).
In my implementation, their functionality isn't much different.
Elizabeth D Rather
> Op Sat, 26 Sep 2009 11:30:33 -0700 (PDT) schreef m_l_g3:
>>
>> This happened because MARKER, invented by the TC, was not superior
>> to FORGET (each one is no worse and no better than the other),
>> and because they do a bit different things.
>
> MARKER must be years older than the TC (1994).
> In my implementation, their functionality isn't much different.
The TC started work in 1986 and delivered its final draft for approval
in 1993. It's called Forth94 because that's when final approval and
publication happened.
MARKER was developed in the course of this work, by a consortium of TC
members who had difficulty with FORGET. A number of people in the TC
implemented MARKER in their systems (not all members were system
developers), and found it a significant improvement over FORGET.
In simple systems, they are, indeed, very similar. As things become
more complex, the advantages of MARKER become relevant.
Ed
> ...
> MARKER was developed in the course of this work, by a consortium of TC
> members who had difficulty with FORGET. A number of people in the TC
> implemented MARKER in their systems (not all members were system
> developers), and found it a significant improvement over FORGET.
>
> In simple systems, they are, indeed, very similar. As things become
> more complex, the advantages of MARKER become relevant.
Given all the systems that have implemented MARKER since 94
it ought to be easy for someone today to prove, or at least give a
believable scenario, whereby it can be shown to be better. Yet
none has been provided.
What *evidence* has appeared has suggested the contrary - that
MARKER offers no advantage. What differences there are, some
see as drawbacks - MARKER pointlessly saves/restores search
order, it works coarsely on blocks rather than words, one must
define a marker before it can be used.
What is beginning to emerge is those who developed/promoted
MARKER *wanted to believe* that it was better andso never
looked closely at FORGET or what it could do.
Like Doubting Thomas, I must see before I can believe - and I
have seen no miracle in MARKER.
Ed
> Op Sat, 26 Sep 2009 14:04:32 +1000 schreef Ed:
> > My task is to show that FORGET works in all practical
> > situations and MARKER is obsolete.
> >
> > Forth has no need for PARSE-NAME either.
>
> And mine is to show that MARKER works in all practical situations and
> FORGET is obsolete ;-)
> Forth has no need for WORD either ;-)
> In my Forth, WORD and FIND are in a loadable extension.
FORGET WORD FIND pre-existed and work well. Just like
CHAR and [CHAR].
> I use c-addr u strings all over.
So do I but it has little benefit here. WORD is primarily
used to parse a forth *token* - not a string. Hence it has
no need to be 'addr u' and 'counted' is more useful
(word names in a header are typically stored counted).
When one needs to parse a general string from the input
stream (as in S" etc) then there is PARSE. Since one
sometimes has to parse strings longer than 255, 'addr u'
is more appropriate for this function.
Andreas
IMO for a small application, both are useful to the same degree. As a
matter of personal taste, I prefer MARKER though. In my system it also
takes care of dangling pointers and broken chains.
However what one may be missing is a more complete namespace management.
Eg. that works also within CATCH/THROW automatically, or that frees
dictionary space "in the middle" when forgetting complete wordlists. But
why should one use Forth at all for such applications??
Andreas
Aleksej Saushev
> However what one may be missing is a more complete namespace
> management. Eg. that works also within CATCH/THROW
> automatically, or that frees dictionary space "in the middle"
> when forgetting complete wordlists. But why should one use Forth
> at all for such applications??
Why not?
What does Standard Forth fit? What is its application domain?
--
HE CE3OH...
Ed
> ...
> IMO for a small application, both are useful to the same degree. As a
> matter of personal taste, I prefer MARKER though. In my system it also
> takes care of dangling pointers and broken chains.
Had you ever considered using FORGET for that?
I imagine the mere fact that 94 marked it 'obsolete' and relegated
it to TOOLS EXT, would have put into the minds of many that
FORGET wasn't worth having. The 94 rationale wouldn't have
inspired confidence.
> However what one may be missing is a more complete namespace management.
> Eg. that works also within CATCH/THROW automatically, or that frees
> dictionary space "in the middle" when forgetting complete wordlists. But
> why should one use Forth at all for such applications??
IMO it's a question of cost/benefit.
In my forth I have a function that excises individual word headers
(headers exist in a separate space). Currently I just unlink them. In
theory I could reclaim the space they occupy - however I have more
than enough header space and headers don't get saved with turnkeyed
apps anyway. It wasn't worth the effort.
Some say FORGET and MARKER isn't worth the effort. Maybe
they're right :)