One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?

Is the search order so much legacy baggage? An implementation artifact that goes away when there is no assembler?

The context can just as well be one wordlist at all times, rather than a list of 0 or more wordlists. Amaze your friends with a search order! Yet, Charles H. Moore, the inventor of Forth has no use for it.

Go figure.

On Friday, August 20, 2021 at 5:29:05 PM UTC-7, Brad Eckert wrote:
> One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?
>
> Is the search order so much legacy baggage? An implementation artifact that goes away when there is no assembler?
>
> The context can just as well be one wordlist at all times, rather than a list of 0 or more wordlists. Amaze your friends with a search order! Yet, Charles H. Moore, the inventor of Forth has no use for it.
>
> Go figure.

The cross-compiler in MFX depended upon having CONTEXT and CURRENT vocabularies.
I don't have any use for the ANS-Forth word-list system. ANS-Forth was supposed to support
standard practice, but setting the context wid (as done in Forth-83 with CONTEXT ! of a
vocno) can't be done in ANS-Forth without a lot of extra code to emulate this feature.

On Friday, August 20, 2021 at 5:52:23 PM UTC-7, Hugh Aguilar wrote:
> On Friday, August 20, 2021 at 5:29:05 PM UTC-7, Brad Eckert wrote:
> > One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?
> >
> > Is the search order so much legacy baggage? An implementation artifact that goes away when there is no assembler?
> >
> > The context can just as well be one wordlist at all times, rather than a list of 0 or more wordlists. Amaze your friends with a search order! Yet, Charles H. Moore, the inventor of Forth has no use for it.
> >
> > Go figure.
> The cross-compiler in MFX depended upon having CONTEXT and CURRENT vocabularies.
> I don't have any use for the ANS-Forth word-list system. ANS-Forth was supposed to support
> standard practice, but setting the context wid (as done in Forth-83 with CONTEXT ! of a
> vocno) can't be done in ANS-Forth without a lot of extra code to emulate this feature.

See, this is the kind of discussion we should have. Whatever happened to current and context being simple variables? Feature creep. No wonder Chuck walked out on the ANS TC.

Okay, create wordlists. There used to be a word for doing that and making a word with "context !" in its run-time semantics.
Wasn't it VOCABULARY? This search order business reminds me of Mickey Mouse in "The Sorcerer's Apprentice". Shit kind of got out of hand.

This is the problem with virtualizing everything. Now we have SET-CURRENT and GET-CURRENT instead of "current !" and "current @".
ANS came along with these abstractions to make everyone happy. It became design by committee. As you point out, ANS encumbered a good paradigm.

I drank the Kool Aid too, but then I noticed that Chuck Moore has even fewer entitlements than this in his colorForth.

On Friday, August 20, 2021 at 8:47:29 PM UTC-7, Brad Eckert wrote:
> On Friday, August 20, 2021 at 5:52:23 PM UTC-7, Hugh Aguilar wrote:
> > On Friday, August 20, 2021 at 5:29:05 PM UTC-7, Brad Eckert wrote:
> > > One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?
> > >
> > > Is the search order so much legacy baggage? An implementation artifact that goes away when there is no assembler?
> > >
> > > The context can just as well be one wordlist at all times, rather than a list of 0 or more wordlists. Amaze your friends with a search order! Yet, Charles H. Moore, the inventor of Forth has no use for it.
> > >
> > > Go figure.
> > The cross-compiler in MFX depended upon having CONTEXT and CURRENT vocabularies.
> > I don't have any use for the ANS-Forth word-list system. ANS-Forth was supposed to support
> > standard practice, but setting the context wid (as done in Forth-83 with CONTEXT ! of a
> > vocno) can't be done in ANS-Forth without a lot of extra code to emulate this feature.
> See, this is the kind of discussion we should have. Whatever happened to current and context being simple variables? Feature creep. No wonder Chuck walked out on the ANS TC.
>
> Okay, create wordlists. There used to be a word for doing that and making a word with "context !" in its run-time semantics.
> Wasn't it VOCABULARY? This search order business reminds me of Mickey Mouse in "The Sorcerer's Apprentice". Shit kind of got out of hand.
>
> This is the problem with virtualizing everything. Now we have SET-CURRENT and GET-CURRENT instead of "current !" and "current @".
> ANS came along with these abstractions to make everyone happy. It became design by committee. As you point out, ANS encumbered a good paradigm.
>
> I drank the Kool Aid too, but then I noticed that Chuck Moore has even fewer entitlements than this in his colorForth.

Although I just checked SwiftForth and you may indeed treat current and context as simple variables. Code that does this would declare a dependency.

On Friday, August 20, 2021 at 8:58:55 PM UTC-7, Brad Eckert wrote:
> On Friday, August 20, 2021 at 8:47:29 PM UTC-7, Brad Eckert wrote:
> > On Friday, August 20, 2021 at 5:52:23 PM UTC-7, Hugh Aguilar wrote:
> > > On Friday, August 20, 2021 at 5:29:05 PM UTC-7, Brad Eckert wrote:
> > > > One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?
> > > >
> > > > Is the search order so much legacy baggage? An implementation artifact that goes away when there is no assembler?
> > > >
> > > > The context can just as well be one wordlist at all times, rather than a list of 0 or more wordlists. Amaze your friends with a search order! Yet, Charles H. Moore, the inventor of Forth has no use for it.
> > > >
> > > > Go figure.
> > > The cross-compiler in MFX depended upon having CONTEXT and CURRENT vocabularies.
> > > I don't have any use for the ANS-Forth word-list system. ANS-Forth was supposed to support
> > > standard practice, but setting the context wid (as done in Forth-83 with CONTEXT ! of a
> > > vocno) can't be done in ANS-Forth without a lot of extra code to emulate this feature.
> > See, this is the kind of discussion we should have. Whatever happened to current and context being simple variables? Feature creep. No wonder Chuck walked out on the ANS TC.
> >
> > Okay, create wordlists. There used to be a word for doing that and making a word with "context !" in its run-time semantics.
> > Wasn't it VOCABULARY? This search order business reminds me of Mickey Mouse in "The Sorcerer's Apprentice". Shit kind of got out of hand.
> >
> > This is the problem with virtualizing everything. Now we have SET-CURRENT and GET-CURRENT instead of "current !" and "current @".
> > ANS came along with these abstractions to make everyone happy. It became design by committee. As you point out, ANS encumbered a good paradigm.
> >
> > I drank the Kool Aid too, but then I noticed that Chuck Moore has even fewer entitlements than this in his colorForth.
> Although I just checked SwiftForth and you may indeed treat current and context as simple variables. Code that does this would declare a dependency.

I have code in the novice-package that allows the context to be set similarly to how it was
set in Forth-83. This is ANS-Forth code, so it is not necessary to declare a dependency.
This is the code (see SET-CONTEXT for setting the context):
--------------------------------------------------------------------------
\ ******
\ ****** Some word-list stuff.
\ ******

: set-forth ( -- ) \ sets default configuration
only forth definitions ;

: <get-context> ( -- wid ) \ like CONTEXT @ in Forth-83 (ANS-Forth already provides GET-CURRENT)
get-order dup 1 < abort" *** GET-CONTEXT given empty search-order ***"
over >r \ r: -- top-wid
0 do drop loop \ --
r> ;

: <push-context> { wid -- }
get-order
wid swap 1+ \ put WID on top of whatever is there
set-order ;

\ <PUSH-CONTEXT> always pushes WID, even if WID is already the 1st. It has to be consistent in always pushing, so <POP-CONTEXT> can pop what was pushed.

: <pop-context> ( -- wid ) \ undo PUSH-CONTEXT and return the wid
get-order dup 1 < abort" *** POP-CONTEXT given empty search-order ***"
swap >r 1-
set-order
r> ;

: <drop-context> ( -- )
<pop-context> drop ;

\ <GET-CONTEXT> <PUSH-CONTEXT> <POP-CONTEXT> and <DROP-CONTEXT> don't take into consideration LOCALVARS# being in the way.

\ VFX pushes a wid called LOCALVARS onto the search order in colon words that have locals, then pops it off again at the semicolon.
\ It is in the way. If you set the 1st value to a replacement wid, you will replace LOCALVARS rather than the wid you thought you were replacing (which is now 2nd).
\ This is a gross violation of the ANS-Forth standard (13.3.3-1):
\ "...if the Search-Order word set is present, local identifiers shall always be searched before any of the word lists in any definable search order,
\ and none of the Search-Order words shall change the locals’ privileged position in the search order."

\ Note: Stephan Pelc fixed the bug mentioned above in version 4.71.3523 of Oct.8,2014.

\ The following definition of SET-CONTEXT works around the bug in VFX, and will also work in Forths that don't have the bug.

false value localvars# \ this is the wid that is 1st in the search-order inside of colon words that have local variables
marker temporary
false value expected# \ this is the wid that we are expecting to be 1st

: fill-localvars# ( -- ) \ this fills <LOCALVARS> at compile-time for use by <SET-CONTEXT> --- it doesn't do anything at run-time
true abort" *** FILL-LOCALVARS# is not to be run, it fills LOCALVARS# at compile-time ***"
[ <get-context> to expected# ]
1 2 3 locals| x y z |
[
<get-context> expected# <> [if]
<pop-context> to localvars#
<get-context> expected# <> [if] .( *** FILL-LOCALVARS# can't find EXPECTED# ***) abort [then]
localvars# <push-context> [then]
] ;

\ FILL-LOCALVARS# doesn't have to run --- it fills LOCALVARS# at compile-time.
temporary \ discard this code that fills LOCALVARS# at compile-time --- it is never needed again

: push-underneath { wid -- } \ push WID underneath whatever is 1st so WID becomes 2nd, leaving 1st as 1st
<pop-context> \ hold 1st
<get-context> wid <> if
wid <push-context> then \ don't push WID on top of itself (if WID was 2nd originally)
<push-context> ; \ push 1st back on top

: replace-1st ( wid -- )
push-underneath <drop-context> ; \ use PUSH-UNDERNEATH so WID is not duplicated if it already 2nd

: <set-context> { wid anchor -- }
<get-context> anchor = if \ if ANCHOR is 1st
wid anchor = if exit then \ WID is already 1st, so we are done
wid <push-context> \ push WID on top of ANCHOR, rather than replace ANCHOR
exit then
<get-context> localvars# = if \ if LOCALVARS# is 1st
<pop-context> \ -- localvars#
<get-context> anchor = if \ if ANCHOR is 2nd
wid <push-context> \ push WID on top of ANCHOR, rather than replace ANCHOR
else
wid replace-1st then \ else, replace 2nd with WID
<push-context> \ restore LOCALVARS# as 1st
exit then
wid replace-1st ; \ 1st was neither ANCHOR nor LOCALSVAR#, so we just replace 1st with WID (now GET-CONTEXT will give us WID)

: set-context ( wid -- )
forth-wordlist <set-context> ;

\ FORTH-WORDLIST SET-CONTEXT would do the same thing that FORTH does.

\ The following PUSH-CONTEXT POP-CONTEXT and DROP-CONTEXT take into account LOCALVARS#.
\ Use xxx PUSH-CONTEXT rather than ALSO xxx SET-CONTEXT because everything goes haywire if the ANCHOR is the 1st wid.
\ All in all, ALSO is a screw-ball idea because it involves making a duplicate on the search-order, which makes no sense.
\ Forth is supposed to be context-free, but ALSO only makes sense when it is followed by SET-CONTEXT (but not when the anchor is 1st).
\ In this 1993 comp.lang.forth thread: https://groups.google.com/forum/#!topic/comp.lang.forth/olO-VHXJa1Q
\ Ray Duncan (who sold UR/Forth back then), described ONLY/ALSO as "severely brain-damaged."
\ Apparently he had zero influence over ANS-Forth design though, because he gave up on Forth after ANS-Forth came out in 1994.

: get-context ( -- wid )
<get-context> \ -- 1st
dup localvars# = if drop \ --
<pop-context> <get-context> \ -- 1st 2nd
swap <push-context> then ; \ -- 2nd

: definitions ( -- ) \ the VFX version of DEFINITIONS has a bug in that it doesn't take LOCALVARS into consideration
get-context set-current ;

: push-context { wid -- }
<get-context> localvars# = if
<pop-context> wid <push-context> \ -- 1st
<push-context> \ --
else
wid <push-context> then ;

On Friday, August 20, 2021 at 7:29:05 PM UTC-5, Brad Eckert wrote:
> One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?

I'm back to using simple Fig Forth vocabularies. Put everything in one bucket and not
worry about it. The only thing that search order gave me was management of order
concerns. No more search order now no more management needed.
--
me

On Saturday, August 21, 2021 at 2:29:05 AM UTC+2, Brad Eckert wrote:
> One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?
Not really. I've written lots of code - and I never missed vocabularies or namspaces. I think it gets pretty confusing pretty quickly. So I can well imagine he got rid of it.

Hans Bezemer

>
> Is the search order so much legacy baggage? An implementation artifact that goes away when there is no ass
>
> The context can just as well be one wordlist at all times, rather than a list of 0 or more wordlists. Amaze your friends with a search order! Yet, Charles H. Moore, the inventor of Forth has no use for it.
>
> Go figure.

On 23/08/2021 08:48, Hans Bezemer wrote:
> On Saturday, August 21, 2021 at 2:29:05 AM UTC+2, Brad Eckert wrote:
>> One thing that jumps out at me about Chuck's later Forths is the lack of search
>> order manipulation. Does it strike anyone else as strange, after Forth's decades
>> as a meta-language, or language for building languages, that colorForth does away
>> with all of that?

> Not really. I've written lots of code - and I never missed vocabularies or namspaces.
> I think it gets pretty confusing pretty quickly. So I can well imagine he got rid of it.
>

IIRC Moore said he adds things as he needs them. Perhaps colorForth as presented
had little need for that which prompted vocabularies/namespaces in the first place.
If Forth were a binary choice - ANS or colorForth - many would be screwed.

On 22/08/2021 03:35, S Jack wrote:
> On Friday, August 20, 2021 at 7:29:05 PM UTC-5, Brad Eckert wrote:
>> One thing that jumps out at me about Chuck's later Forths is the lack of search order manipulation. Does it strike anyone else as strange, after Forth's decades as a meta-language, or language for building languages, that colorForth does away with all of that?
>
> I'm back to using simple Fig Forth vocabularies. Put everything in one bucket and not
> worry about it. The only thing that search order gave me was management of order
> concerns. No more search order now no more management needed.

Implicit in vocabulary is the notion of a search order. To the extent
one is happy with the search order Fig-Forth imposes, fine. ColorForth
without vocabularies is itself an imposition.