RfD - Synonyms Synonym.txt Stephen Pelc, 21 August 2006
20060821 First draft
Rationale ========= Problem ------- Various words have been used to gneration a new name for an existing word. This required when porting code and when generating application wordlists that contain a reference to an existing word, e.g. when providing limited access to Forth system kernel words.
Especially with native code compiling Forth systems, these words have not provided full access to the required behaviour which requires carnal knowledge of the underlying system, which is one reason why SYNONYM should be standardised.
Current practice ---------------- The proposed form SYNONYM has been in use at MPE with cross compilers and VFX Forth since 1998.
Solution -------- Although many people have objected to parsing words, parsing permits the host system the most flexibility in implementation and is thus the preferred solution.
The syntax is: SYNONYM <newname> <oldname> where <newname> will behave identically to <oldname>.
( "<spaces>newname" "<spaces>oldname" -- ) For both strings kip leading space delimiters. Parse name delimited by a space. Create a new word newname whose execution behaviour is identical to that of the existing word oldname. Newname may be the same as oldname.
Ambiguous conditions: The word newname is parsed by ' or ['] or POSTPONE. oldname is not found.
Labelling ========= TBD
Reference Implementation ======================== The implementation of SYNONYM requires carnal knowledge of the host implementation, which is one reason why it should be standardised. The implementation below is imperfect and specific to VFX Forth.
: Synonym \ <"new-name"> <"curdef"> -- \ *G Create a new definition which redirects to an existing one. create immediate hide ' , reveal does> @ state @ 0= over immediate? or if execute else compile, then ;
Test Cases ========== TBD
-- Stephen Pelc, stephen...@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
Stephen Pelc wrote: > RfD - Synonyms > Synonym.txt > Stephen Pelc, 21 August 2006
> 20060821 First draft
> Rationale > ========= > Problem > ------- > Various words have been used to gneration a new name for an > existing word. This required when porting code and when > generating application wordlists that contain a reference > to an existing word, e.g. when providing limited access > to Forth system kernel words.
> Especially with native code compiling Forth systems, these > words have not provided full access to the required behaviour > which requires carnal knowledge of the underlying system, which > is one reason why SYNONYM should be standardised.
> Current practice > ---------------- > The proposed form SYNONYM has been in use at MPE with cross > compilers and VFX Forth since 1998.
> Solution > -------- > Although many people have objected to parsing words, parsing > permits the host system the most flexibility in implementation > and is thus the preferred solution.
> The syntax is: > SYNONYM <newname> <oldname> > where <newname> will behave identically to <oldname>.
> Note that <newname> may be the same as <oldname>.
> ( "<spaces>newname" "<spaces>oldname" -- ) > For both strings kip leading space delimiters. Parse name > delimited by a space. Create a new word newname whose > execution behaviour is identical to that of the existing word > oldname. Newname may be the same as oldname.
> Ambiguous conditions: > The word newname is parsed by ' or ['] or POSTPONE. > oldname is not found.
> Labelling > ========= > TBD
> Reference Implementation > ======================== > The implementation of SYNONYM requires carnal knowledge of the host > implementation, which is one reason why it should be standardised. > The implementation below is imperfect and specific to VFX Forth.
> : Synonym \ <"new-name"> <"curdef"> -- > \ *G Create a new definition which redirects to an existing one. > create immediate > hide ' , reveal > does> > @ state @ 0= over immediate? or > if execute else compile, then > ;
> Test Cases > ========== > TBD
> -- > Stephen Pelc, stephen...@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
Win32Forth already supports SYNONYM with the same syntax.
Stephen Pelc wrote: > Especially with native code compiling Forth systems, these > words have not provided full access to the required behaviour > which requires carnal knowledge of the underlying system, which > is one reason why SYNONYM should be standardised.
....
> Ambiguous conditions: > The word newname is parsed by ' or ['] or POSTPONE. > oldname is not found.
I see no particular reason not to standardise this just as you say. It's already reasonably common practice.
As a side issue, what behavior will a portable SYNONYM written in standard Forth fail at, that doesn't involve ' or ['] or POSTPONE ? I haven't found anything quickly.
This is as close as I came:
SYNONYM MY-DUP DUP
SYNONYM YOUR-DUP MY-DUP
A portable SYNONYM would probably use ' or ['] or POSTPONE on MY-DUP here and fit the ambiguous condition, but a primitive SYNONYM wouldn't have to.
On Mon, 21 Aug 2006 19:45:17 +0200, "Andreas Kochenburger"
<a...@privat.de> wrote: >> The syntax is: >> SYNONYM <newname> <oldname> >> where <newname> will behave identically to <oldname>.
>ALIAS is used for the same purpose >' <oldname> ALIAS NEWNAME
>Its syntax is similar to IS. >My personal vote is for ALIAS
It breaks on some systems (and they exist) that cannot get from the xt of a word to enough needed information to create the new word. The point of SYNONYM is that it can be as carnal as necessary.
Stephen
-- Stephen Pelc, stephen...@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
> Stephen Pelc wrote: > > RfD - Synonyms > > ... > > The syntax is: > > SYNONYM <newname> <oldname> > > where <newname> will behave identically to <oldname>.
> > Note that <newname> may be the same as <oldname>.
> ... > Win32Forth already supports SYNONYM with the same syntax.
Not so fast :)
I wonder how many missed the part in the spec about making aliases with the same name!
A conforming SYNONYM should be able to handle this:
\ Test SYNONYM ability to make alias with same name CR FORTH ALSO DEFINITIONS : TEST ." hello " ; VOCABULARY NEWVOC NEWVOC DEFINITIONS SYNONYM TEST TEST ( make alias in new vocab ) CR .( now testing alias ) CR NEWVOC TEST
> > Stephen Pelc wrote: > > > RfD - Synonyms > > > ... > > > The syntax is: > > > SYNONYM <newname> <oldname> > > > where <newname> will behave identically to <oldname>.
> > > Note that <newname> may be the same as <oldname>.
> > ... > > Win32Forth already supports SYNONYM with the same syntax.
> Not so fast :)
> I wonder how many missed the part in the spec about making > aliases with the same name!
> A conforming SYNONYM should be able to handle this:
> \ Test SYNONYM ability to make alias with same name > CR > FORTH ALSO DEFINITIONS > : TEST ." hello " ; > VOCABULARY NEWVOC > NEWVOC DEFINITIONS > SYNONYM TEST TEST ( make alias in new vocab ) > CR .( now testing alias ) CR > NEWVOC TEST
You're right; Win32Forth fails this test due to a timing issue creating the dictionary entry. At the point where SYNONYM is executed, the ORDER is
order Context: NEWVOC FORTH FORTH ROOT Current: NEWVOC ok
TEST is being defined, then searched for, rather than searched for then defined; so it finds itself rather than the TEST in the FORTH vocabulary. WIll be corrected.
> > Stephen Pelc wrote: > > > RfD - Synonyms > > > ... > > > The syntax is: > > > SYNONYM <newname> <oldname> > > > where <newname> will behave identically to <oldname>.
> > > Note that <newname> may be the same as <oldname>.
> > ... > > Win32Forth already supports SYNONYM with the same syntax.
> Not so fast :)
How slow do you want it. -;)
> I wonder how many missed the part in the spec about making > aliases with the same name!
Not me I saw it.
> A conforming SYNONYM should be able to handle this:
> \ Test SYNONYM ability to make alias with same name > CR > FORTH ALSO DEFINITIONS > : TEST ." hello " ; > VOCABULARY NEWVOC > NEWVOC DEFINITIONS > SYNONYM TEST TEST ( make alias in new vocab ) > CR .( now testing alias ) CR > NEWVOC TEST
Win32Forth supports that. I've used both SYNONYM and ALIAS (which always makes the new word non-immediate irrespective of the immediacy of the original) to have the same word in diffrent vocabularies many a time. It's even used in the system for putting FORTH FORTH-WORDLIST and SET-ORDER in the ROOT vocabulary (the one that's always available after ONLY) as well as the FORTH vocabulary, so I know it works.
> > > Stephen Pelc wrote: > > > > RfD - Synonyms > > > > ... > > > > The syntax is: > > > > SYNONYM <newname> <oldname> > > > > where <newname> will behave identically to <oldname>.
> > > > Note that <newname> may be the same as <oldname>.
> > > ... > > > Win32Forth already supports SYNONYM with the same syntax.
> > Not so fast :)
> How slow do you want it. -;)
> > I wonder how many missed the part in the spec about making > > aliases with the same name!
> Not me I saw it.
> > A conforming SYNONYM should be able to handle this:
> > \ Test SYNONYM ability to make alias with same name > > CR > > FORTH ALSO DEFINITIONS > > : TEST ." hello " ; > > VOCABULARY NEWVOC > > NEWVOC DEFINITIONS > > SYNONYM TEST TEST ( make alias in new vocab ) > > CR .( now testing alias ) CR > > NEWVOC TEST
> Win32Forth supports that. I've used both SYNONYM and ALIAS (which > always makes the new word non-immediate irrespective of the immediacy > of the original) to have the same word in diffrent vocabularies many a > time. It's even used in the system for putting FORTH FORTH-WORDLIST and > SET-ORDER in the ROOT vocabulary (the one that's always available after > ONLY) as well as the FORTH vocabulary, so I know it works.
> George Hubert
Are you sure? I've just run it under 6.11.07 and it fails.
> > > Stephen Pelc wrote: > > > > RfD - Synonyms > > > > ... > > > > The syntax is: > > > > SYNONYM <newname> <oldname> > > > > where <newname> will behave identically to <oldname>.
> > > > Note that <newname> may be the same as <oldname>.
> > > ... > > > Win32Forth already supports SYNONYM with the same syntax.
> > Not so fast :)
> > I wonder how many missed the part in the spec about making > > aliases with the same name!
> > A conforming SYNONYM should be able to handle this:
> > \ Test SYNONYM ability to make alias with same name > > CR > > FORTH ALSO DEFINITIONS > > : TEST ." hello " ; > > VOCABULARY NEWVOC > > NEWVOC DEFINITIONS > > SYNONYM TEST TEST ( make alias in new vocab ) > > CR .( now testing alias ) CR > > NEWVOC TEST
> You're right; Win32Forth fails this test due to a timing issue creating > the dictionary entry. At the point where SYNONYM is executed, the ORDER > is
> order > Context: NEWVOC FORTH FORTH ROOT > Current: NEWVOC ok
> TEST is being defined, then searched for, rather than searched for then > defined; so it finds itself rather than the TEST in the FORTH > vocabulary. WIll be corrected.
> -- > Regards > Alex McDonald
All it needs is to hide the new word until after the second word is looked up, which has the added advantage that if old-word isn't found then new-word is hidden (similar to an incomplete : definition).
> > > > Stephen Pelc wrote: > > > > > RfD - Synonyms > > > > > ... > > > > > The syntax is: > > > > > SYNONYM <newname> <oldname> > > > > > where <newname> will behave identically to <oldname>.
> > > > > Note that <newname> may be the same as <oldname>.
> > > > ... > > > > Win32Forth already supports SYNONYM with the same syntax.
> > > Not so fast :)
> > How slow do you want it. -;)
> > > I wonder how many missed the part in the spec about making > > > aliases with the same name!
> > Not me I saw it.
> > > A conforming SYNONYM should be able to handle this:
> > > \ Test SYNONYM ability to make alias with same name > > > CR > > > FORTH ALSO DEFINITIONS > > > : TEST ." hello " ; > > > VOCABULARY NEWVOC > > > NEWVOC DEFINITIONS > > > SYNONYM TEST TEST ( make alias in new vocab ) > > > CR .( now testing alias ) CR > > > NEWVOC TEST
> > Win32Forth supports that. I've used both SYNONYM and ALIAS (which > > always makes the new word non-immediate irrespective of the immediacy > > of the original) to have the same word in diffrent vocabularies many a > > time. It's even used in the system for putting FORTH FORTH-WORDLIST and > > SET-ORDER in the ROOT vocabulary (the one that's always available after > > ONLY) as well as the FORTH vocabulary, so I know it works.
> > George Hubert
> Are you sure? I've just run it under 6.11.07 and it fails.
You're right (although the latest V6.11.09 from the cvs now works correctly). It's ALIAS (where the xt is passed in) that worked whatever the search order; SYNONYM requires the voc of old word to be earlier in the search-order than the current voc. I couldn't run Ed's test for the original post (or any other) since it hadn't been posted at the time. V6.10 will also be modified to match; it just requires HIDE and REVEAL.
How would you attempt to write a portable definition for SYNONYM?
For a word "with default compilation behavior" it's easy.
: SYNONYM : BL WORD FIND DROP COMPILE, POSTPONE ; ;
You wind up with a new word that calls the old word. Standard programs won't do R> DROP etc so they can't tell the difference between doing one call and one return versus two calls and two returns. It ought to just work.
But when you try to get synonyms for words that are active at compile time then you run into all the problems Anton Ertl pointed out for state-smartness etc. You need two behaviors that will each happen at precisely the right times and not at the wrong times, and there's no way to be sure to get those behaviors with all combinations of compilation, execution, POSTPONE, EXECUTE, and EVALUATE .
But Anton published a portable solution to that problem, where each word gets two execution tokens and the system is instructed (in a portable way) which of them to use. And it seems to me that if you use Anton's system, you should be able to extend it simply for synonyms. You can easily get the two xt's for the old word, and you can construct the new word with them. So SYNONYM should be as portable as Anton's method, for that particular set of problems.
J Thomas wrote: > How would you attempt to write a portable definition for SYNONYM?
> For a word "with default compilation behavior" it's easy.
> : SYNONYM > : > BL WORD FIND DROP COMPILE, > POSTPONE ; ;
Why not;
: SYNONYM : BL WORD FIND 1 = IF IMMEDIATE THEN COMPILE, POSTPONE ; ;
which takes care of whether the word is IMMEDIATE as well, although neither version deals with the case of oldword not being found. It wouldn't work correctly with separate intepret and compile xts though.
> You wind up with a new word that calls the old word. Standard programs > won't do R> DROP etc so they can't tell the difference between doing > one call and one return versus two calls and two returns. It ought to > just work.
Somebody will want a synonym for R> >R for some obscure reason -;)
> But when you try to get synonyms for words that are active at compile > time then you run into all the problems Anton Ertl pointed out for > state-smartness etc. You need two behaviors that will each happen at > precisely the right times and not at the wrong times, and there's no > way to be sure to get those behaviors with all combinations of > compilation, execution, POSTPONE, EXECUTE, and EVALUATE .
> But Anton published a portable solution to that problem, where each > word gets two execution tokens and the system is instructed (in a > portable way) which of them to use. And it seems to me that if you use > Anton's system, you should be able to extend it simply for synonyms. > You can easily get the two xt's for the old word, and you can construct > the new word with them. So SYNONYM should be as portable as Anton's > method, for that particular set of problems.
Depending on how dual xts are implemented it's possible to make SYNONYM just point the name of to the same address as oldword points to, though this means the 2 words behave exactly the same forevermore (i.e. if you supply an optimised compile to newword then compiling oldword does the same optimising from then on as well).
> What other portability problems are there?
Probably many. Separate wordlists for compilation words springs to mind. I don't think a portable version for all systems is possible though ones can be written for common implementation strategies; IMO that's probably why it needs standardising.
> ( "<spaces>newname" "<spaces>oldname" -- ) > For both strings kip leading space delimiters. Parse name > delimited by a space. Create a new word newname whose > execution behaviour is identical to that of the existing word > oldname. Newname may be the same as oldname.
> Ambiguous conditions: > The word newname is parsed by ' or ['] or POSTPONE. > oldname is not found.
> Reference Implementation > ======================== > The implementation of SYNONYM requires carnal knowledge of the host > implementation, which is one reason why it should be standardised. > The implementation below is imperfect and specific to VFX Forth.
> : Synonym \ <"new-name"> <"curdef"> -- > \ *G Create a new definition which redirects to an existing one. > create immediate > hide ' , reveal > does> > @ state @ 0= over immediate? or > if execute else compile, then > ;
I've just implemented this as it seems a useful addition, although I would have preferred SYNONYM <oldname> <newname> as it seems more natural to find the old one before creating the new name but no matter. I have the following questions, (nit picking I know but it is for a standard):
1. Your reference implementation creates a new immediate word. Therefore FIND <newname> will return a different result to FIND <oldname> both due to a different xt (probably) and because <oldname> may not be immediate. Does this matter?
2. If an implementation is an exact synonym i.e. FIND returns the same xt and <newname> follows <oldname> immediacy as well as behaving exactly the same, does SYNONYM count as a defining word in the terms of the ANS standard e.g. if the old word abc is not immediate will
SYNONYM xyz abc IMMEDIATE
make xyz or the previous definition immediate, or should it make both xyz and abc immediate or is it an ambiguous condition. I think making only xyz immediate is the best.
3. Just thought of this as I was about to post this message. With your implementation would the following work? SYNONYM ENDIF THEN
For the record my implementation creates an exact synonym so ' ['] and POSTPONE will all work with <newname> which I think is better than making that an ambiguous condition.
George Hubert wrote: > J Thomas wrote: > > How would you attempt to write a portable definition for SYNONYM? > > For a word "with default compilation behavior" it's easy. > > : SYNONYM > > : > > BL WORD FIND DROP COMPILE, > > POSTPONE ; ; > Why not; > : SYNONYM > : > BL WORD FIND 1 = IF IMMEDIATE THEN COMPILE, > POSTPONE ; ;
I dunno. That might work. There were a lot of traps and I haven't thought about it for awhile, maybe some of them would bite you on this.
To be on the safe side it might make sense to make it immediate after you've postponed ; but I've never noticed an implementation that won't make an incomplete definition immediate.
> which takes care of whether the word is IMMEDIATE as well, although > neither version deals with the case of oldword not being found. It > wouldn't work correctly with separate intepret and compile xts though.
Yes. Two incompatible systems. One has tradition and the other works better.
> Somebody will want a synonym for R> >R for some obscure reason -;)
Oops! You got me there. So the simple implementation fails even when R>
>R have no special compilation behavior. So it fails. > Depending on how dual xts are implemented it's possible to make SYNONYM > just point the name of to the same address as oldword points to, though > this means the 2 words behave exactly the same forevermore (i.e. if you > supply an optimised compile to newword then compiling oldword does the > same optimising from then on as well).
Yes.
> > What other portability problems are there? > Probably many. Separate wordlists for compilation words springs to > mind. I don't think a portable version for all systems is possible > though ones can be written for common implementation strategies; IMO > that's probably why it needs standardising.
Have you figured out how to do separate wordlists for compilation words in a standard system? When I tried that it turned into a briar patch. Define a new word with the old name that isn't immediate, and watch the old version get found during compilation. Etc. Getting the standard behaviors seemed to beg for a synonym in whichever wordset you aren't defining in at the moment. Those systems are designed to work different from standard, and it wrenches their soul to try to make them conform.
Anyway, if Anton's dual-wordlist approach can be implemented on any standard system using only standard words, then it looks to me like adding SYNONYM to it ought to be trivial. So SYNONYM should be very widely portable.
In article <1156428139.572536.264...@h48g2000cwc.googlegroups.com>,
J Thomas <jethom...@gmail.com> wrote: >How would you attempt to write a portable definition for SYNONYM?
<SNIP>
>What other portability problems are there?
I want to remark that it is important to standardize words that *cannot* be portably implemented, or not efficiently.
It is much less important to standardize words that can be portably implemented, as they can always be made part of the application.
-- Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- like all pyramid schemes -- ultimately falters. alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
> In article <1156428139.572536.264...@h48g2000cwc.googlegroups.com>, > J Thomas <jethom...@gmail.com> wrote: > >How would you attempt to write a portable definition for SYNONYM?
> <SNIP>
> >What other portability problems are there?
> I want to remark that it is important to standardize words > that *cannot* be portably implemented, or not efficiently.
> It is much less important to standardize words that can > be portably implemented, as they can always be made > part of the application.
> -- > Groetjes Albert > -- > Albert van der Horst, UTRECHT,THE NETHERLANDS > Economic growth -- like all pyramid schemes -- ultimately falters. > alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Well, for the case of SYNONYM in the latest dual-xt version of W32F based on Anton's suggestions (see here http://www.complang.tuwien.ac.at/forth/header-ideas.html), it will be important. To ensure the right behaviour with dual xts for words that have non-standard compilation semantics, the synonym must either be an immediate word that always executes the compile token of the underlying word, or a complete copy of the dictionary entry. I can't think of a portable ANS way to implement SYNONYM that would support such systems.
<ge...@jackson9000.fsnet.co.uk> wrote: >1. Your reference implementation creates a new immediate word. >Therefore FIND <newname> will return a different result to FIND ><oldname> both due to a different xt (probably) and because <oldname> >may not be immediate. Does this matter?
No.
>2. If an implementation is an exact synonym i.e. FIND returns the same >xt and <newname> follows <oldname> immediacy as well as behaving >exactly the same, does SYNONYM count as a defining word in the terms of >the ANS standard e.g. if the old word abc is not immediate will
> SYNONYM xyz abc IMMEDIATE
>make xyz or the previous definition immediate, or should it make both >xyz and abc immediate or is it an ambiguous condition. I think making >only xyz immediate is the best.
IMMEDIATE affects the last dictionary entry which is XYZ.
I have already made this an ambiguous condition.
>3. Just thought of this as I was about to post this message. With your >implementation would the following work? > SYNONYM ENDIF THEN
Yes.
Stephen
-- Stephen Pelc, stephen...@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
>( "<spaces>newname" "<spaces>oldname" -- ) >For both strings kip leading space delimiters. Parse name
^^^ skip
> delimited by a space. Create a new word newname whose >execution behaviour is identical to that of the existing word >oldname.
"execution behaviour" is not a standard term. If you mean "execution semantics", then SYNONYM is no more powerful than ALIAS. If you want to make SYNONYM more powerful than ALIAS, how about the following specification:
... Create a definition for newname with the semantics defined below:
newname interpretation: ( i*x -- j*x ) Perform the interpretation semantics of oldname
newname compilation: ( i*x -- j*x ) Perform the compilation semantics of oldname
> Newname may be the same as oldname.
That's true by default, so leave it away here; you may want to point it out in an informal part.
>Ambiguous conditions: > The word newname is parsed by ' or ['] or POSTPONE.
No! If you can tick or POSTONE oldname, you should also be able to do this to newname, or it won't be a synonym. Moreover, having words that cannot be ticked or postponed in the standard is bad enough, we don't need to add defining words for such monstrosities; I would consider a language that had such defining words to be not Forth. Also, I don't see a technical reason for such a restriction (especially if you don't make [COMPILE] newword ambiguous).
"J Thomas" <jethom...@gmail.com> writes: >But Anton published a portable solution to that problem, where each >word gets two execution tokens and the system is instructed (in a >portable way) which of them to use.
Actually my implementation has bugs, but since nobody seemed interested, fixing them never got to the top of my agenda.
> And it seems to me that if you use >Anton's system, you should be able to extend it simply for synonyms.
>You can easily get the two xt's for the old word,
Does not seems so easy to me.
Hmm, the xt for the compilation semantics could be constructed like this:
:noname POSTPONE oldname ;
The interpretation semantics might be gotten by just ticking the word (and maybe CATCHING any errors). But for words with undefined interpretation semantics, one might not get what one wants.
Still, it looks like it is possible to do it (apart from the return stack words, as someone else mentioned).
"J Thomas" <jethom...@gmail.com> writes: >Have you figured out how to do separate wordlists for compilation words >in a standard system? When I tried that it turned into a briar patch. >Define a new word with the old name that isn't immediate, and watch the >old version get found during compilation.
I think the right approach is to have a wordlist for the interpretation/execution semantics of standard words, a wordlist for the compilation semantics of standard words, and a wordlist for user-defined words. In interpretation state, you search user, then interpretation; in compilation state, you search user, then compilation, then interpretation.
Of course, this scheme becomes complicated once you want to implement the search-order wordset, so complicated that it isn't worth doing.
Anton Ertl wrote: > I think the right approach is to have a wordlist for the > interpretation/execution semantics of standard words, a wordlist for > the compilation semantics of standard words, and a wordlist for > user-defined words. In interpretation state, you search user, then > interpretation; in compilation state, you search user, then > compilation, then interpretation.
[snip]
I find it simpler to reserve 2 extra bits in each header, an interpretation bit, a compilation bit, in addition to the traditional precedence (i.e. immediate) bit.
A normal word has interpretation=1 compilation=1 precedence=0 A normal immediate word has i=1 c=1 p=0 A compile-only non-immediate word has i=0 c=1 p=0 A directive (i.e. compile-only immediate) word has i=0 c=1 p=1 An interpret-only word has i=1 c=0 p=0
