The stated convention in FigForth is for the user to make vocabularies immediate. Don't know if this was a Fig thing - or derived from
practice at the time. Under FigForth vocabularies automatically chain
to the parent.

Long story short I went back to the FigForth vocabulary scheme. The only departure was chaining. It's not automatic - the user must specify it.

For any FigForth (or variants thereof) users out there, do you use the immediate vocab convention? At the moment I'm reviewing whether I should
just make vocabs immediate on creation. Not being a fan of vocabularies
I don't use them much. Hence the question.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/08/2023 1:46 pm, dxforth wrote:

The stated convention in FigForth is for the user to make vocabularies immediate. Don't know if this was a Fig thing - or derived from
practice at the time. Under FigForth vocabularies automatically chain
to the parent.

Long story short I went back to the FigForth vocabulary scheme. The only departure was chaining. It's not automatic - the user must specify it.

For any FigForth (or variants thereof) users out there, do you use the immediate vocab convention? At the moment I'm reviewing whether I should just make vocabs immediate on creation. Not being a fan of vocabularies
I don't use them much. Hence the question.

Thinking about it such a change is likely to create more problems than
it solves. IMMEDIATE in FigForth is a toggle. Thus if I encountered
Fig code such as:

VOCABULARY FOOBAR IMMEDIATE

the result would be the exact opposite. So I'll scrap that idea.

OTOH there's the question of whether a non-IMMEDIATE vocabulary is ever *necessary*. AFAICS it's a preference and boils down to which one does
more: execute a vocab name - or compile it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <uc6jpn$3a4h7$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote: >The stated convention in FigForth is for the user to make vocabularies >immediate. Don't know if this was a Fig thing - or derived from

practice at the time. Under FigForth vocabularies automatically chain
to the parent.

Long story short I went back to the FigForth vocabulary scheme. The only >departure was chaining. It's not automatic - the user must specify it.

For any FigForth (or variants thereof) users out there, do you use the >immediate vocab convention? At the moment I'm reviewing whether I should >just make vocabs immediate on creation. Not being a fan of vocabularies
I don't use them much. Hence the question.

It is not a good idea to refurbish partially.
The Fig vocabularies are usable, and so is the ISO wordlists.
The chaining of Fig is the equivalent functionality of the search-order. Dropping the chaining you miss on functionality without good reason,
but at least you leave it as an option.

Groetjes Albert

--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

„Hardly any” — during word's creation, of course. :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For any FigForth (or variants thereof) users out there, do you use the immediate vocab convention? At the moment I'm reviewing whether I should just make vocabs immediate on creation.

There is hardly any use for non-immediate vocabularies, but AFAIK
the „classic” approach is to leave that decision to the user. So it's
up to him to type VOCABULARY MYVOC IMMEDIATE — or to skip
that „IMMEDIATE” for a particular reason.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/08/2023 6:42 pm, Zbig wrote:

For any FigForth (or variants thereof) users out there, do you use the
immediate vocab convention? At the moment I'm reviewing whether I should
just make vocabs immediate on creation.

There is hardly any use for non-immediate vocabularies, but AFAIK
the „classic” approach is to leave that decision to the user. So it's
up to him to type VOCABULARY MYVOC IMMEDIATE — or to skip
that „IMMEDIATE” for a particular reason.

Immediate vocab may have been necessary due to limited search order.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/08/2023 5:57 pm, albert wrote:

In article <uc6jpn$3a4h7$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:

The stated convention in FigForth is for the user to make vocabularies
immediate. Don't know if this was a Fig thing - or derived from
practice at the time. Under FigForth vocabularies automatically chain
to the parent.

Long story short I went back to the FigForth vocabulary scheme. The only
departure was chaining. It's not automatic - the user must specify it.

For any FigForth (or variants thereof) users out there, do you use the
immediate vocab convention? At the moment I'm reviewing whether I should
just make vocabs immediate on creation. Not being a fan of vocabularies
I don't use them much. Hence the question.

It is not a good idea to refurbish partially.
The Fig vocabularies are usable, and so is the ISO wordlists.
The chaining of Fig is the equivalent functionality of the search-order. Dropping the chaining you miss on functionality without good reason,
but at least you leave it as an option.

LMI decided they didn't need either. I chickened out.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

There is hardly any use for non-immediate vocabularies, but AFAIK
the „classic” approach is to leave that decision to the user. So it's up to him to type VOCABULARY MYVOC IMMEDIATE — or to skip
that „IMMEDIATE” for a particular reason.

Immediate vocab may have been necessary due to limited search order.

Very likely — but apart of this, somehow I can't imagine at the moment
any valid reason to compile the name of the vocabulary (I mean the one
created by the user) into the body of any word. Maybe there can be „invented” one, but rather unusual.
Still I remember from trying various fig-Forths that „canonical” sequence: VOCABULARY something IMMEDIATE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, August 23, 2023 at 10:46:03 PM UTC-5, dxforth wrote:

For any FigForth (or variants thereof) users out there, do you use the immediate vocab convention?

Yes, most defiantly now. Until not long ago I never
give it much thought, used vocabularies very little
just keeping simple and putting everything in the
Forth vocabulary. Then I started using vocabularies
mainly for words to use as an operator and not to
be included in other words, e.g. use VARIABLE in
programs but VAR in the OP vocabulary only to be use
at the command line (This was analogous to the use
of aliases in Linux). When I started using them, I
found making them immediate was the thing to do. Now
this goes hand in hand with colon changing CONTEXT
to CURRENT in the start of a definition which is something
most "modern" Forths avoid, but it's part of the scheme
that works in Fig.
I now use vocabularies for other things but conservatively.
In Toad I have BUF vocabulary that contains ALLOCATE
and LIST. "BUF LIST FORTH" lists allocated buffers and
not SCRs. (Sure, could have ALLOCATED-BUFFER-LIST and
not use vocabulary but that's beside the point.)
--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, August 24, 2023 at 8:38:30 AM UTC-5, Zbig wrote:

There is hardly any use for non-immediate vocabularies, but AFAIK
the „classic” approach is to leave that decision to the user. So it's
up to him to type VOCABULARY MYVOC IMMEDIATE — or to skip
that „IMMEDIATE” for a particular reason.

In Frog:

: EDIT THISVOC [COMPILE] EDITOR ;

THISVOC saved the context when EDITOR was selected.
:X saves the edit and returns to the saved context.
--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, August 24, 2023 at 9:38:30 AM UTC-4, Zbig wrote:

Very likely — but apart of this, somehow I can't imagine at the moment
any valid reason to compile the name of the vocabulary (I mean the one created by the user) into the body of any word. Maybe there can be „invented” one, but rather unusual.

I have used the non-immediate wordlists to create specific search order commands for cross-compilers.
Examples:

: HOST
ONLY FORTH ALSO ASSEMBLER ALSO MFORTH ALSO FORTH DEFINITIONS ;

: ASMFORTH
ONLY FORTH ALSO ASSEMBLER ALSO MFORTH DEFINITIONS ;

Later I can make an immediate version of these if I need it.

: [HOST] HOST ; IMMEDIATE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I have used the non-immediate wordlists to create specific search order commands for cross-compilers.

So that's why it's better to leave that decision to the user. He may need it anyway.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, August 24, 2023 at 10:09:55 AM UTC-5, Zbig wrote:

I have used the non-immediate wordlists to create specific search order commands for cross-compilers.

So that's why it's better to leave that decision to the user. He may need it anyway.

Frog example use of non-immediate vocabulary.
Aliases used when operating at command line:

00 w ( BOX )
01 w VOCABULARY BOX BOX DEFS
02 w ' BOX:SetText aka SET
03 w ' BOX:AT aka AT
04 w ' BOX:Show aka SHOW
05 w ' BOX:Hide aka HIDE
06 w ' BOX:Zip aka ZIP
07 w ' BOX:Move aka MV
08 w ' BOX:Free aka FREE
09 w ' BOX:TextNew aka TEXT
10 w ' BOX:ColorNew aka COLOR
11 w ' BOX:TitleNew aka TITLE
12 w ' BOX:ShowTitle aka -TITLE
13 w ' BOX:NoTitle aka +TITLE
14 w FORTH DEFS
15 w ;S

Have split screen with dialog box displayed in top area.
Would do operations like:

box 15 5 at show 40 10 mv zip hide 1 1 at show
--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/08/2023 11:38 pm, Zbig wrote:

There is hardly any use for non-immediate vocabularies, but AFAIK
the „classic” approach is to leave that decision to the user. So it's >>> up to him to type VOCABULARY MYVOC IMMEDIATE — or to skip
that „IMMEDIATE” for a particular reason.

Immediate vocab may have been necessary due to limited search order.

Very likely — but apart of this, somehow I can't imagine at the moment
any valid reason to compile the name of the vocabulary (I mean the one created by the user) into the body of any word. Maybe there can be „invented” one, but rather unusual.

Everyday examples would be LABEL and CODE which must select the ASSEMBLER vocab.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/08/2023 12:56 am, Brian Fox wrote:

On Thursday, August 24, 2023 at 9:38:30 AM UTC-4, Zbig wrote:

Very likely — but apart of this, somehow I can't imagine at the moment
any valid reason to compile the name of the vocabulary (I mean the one
created by the user) into the body of any word. Maybe there can be
„invented” one, but rather unusual.

I have used the non-immediate wordlists to create specific search order commands for cross-compilers.
Examples:

: HOST
ONLY FORTH ALSO ASSEMBLER ALSO MFORTH ALSO FORTH DEFINITIONS ;

: ASMFORTH
ONLY FORTH ALSO ASSEMBLER ALSO MFORTH DEFINITIONS ;

Later I can make an immediate version of these if I need it.

: [HOST] HOST ; IMMEDIATE

ONLY ALSO changed the dynamic. Fewer context changes meant less need
for stuff like this:

: FST fst? forth if hidden D0 5 fr, end i/r 10 fm1, ;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Everyday examples would be LABEL and CODE which must select the ASSEMBLER vocab.

Indeed CODE switches to ASSEMBLER. I forgot this one, obvious example.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

(
Example use of immediate vocabularies FORTH and EDITOR .
Editor is fig-Forth PORTABLE EDITOR
)

"rcdg '?SCR' f/misc.f" CR /O

[r] ?SCR ( s -- )
-- Case sensitive search of each each line of each scr
-- s String to be matched
-- Move string s to PAD .
-- Search each block line of all blocks for a match.
-- If match is found, print line and block
-- number. Continue searching until blocks are exhausted.
[r] CODE ?SCR
: ?SCR ( s -- )
PAD C/L ERASE COUNT PAD PLACE
BLK_MAX @ 1+ ZERO DO FORTH I SCR !
EDITOR TOP
BEGIN 1LINE IF ZERO M SCR ? ENDIF
1023 R# @ < UNTIL
LOOP ;
--.

OK
"?FIT" ?SCR
( AHEAD RESOLVE GIVE IT -"- ?FIT_ ) 0 32
: ?FIT_ MIN ; 6 32
: /S, SMAX ?FIT_ HERE OVER 1+ ALLOT PLACE ; 10 85
EBUF @ 1- ?FIT_ R SWAP CMOVE 4 125 OK
--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, August 23, 2023 at 11:46:03 PM UTC-4, dxforth wrote:

The stated convention in FigForth is for the user to make vocabularies immediate. Don't know if this was a Fig thing - or derived from
practice at the time. Under FigForth vocabularies automatically chain
to the parent.

Long story short I went back to the FigForth vocabulary scheme. The only departure was chaining. It's not automatic - the user must specify it.

For any FigForth (or variants thereof) users out there, do you use the immediate vocab convention? At the moment I'm reviewing whether I should d just make vocabs immediate on creation. Not being a fan of vocabularies
I don't use them much. Hence the question.

There is a subtle relationship between CURRENT and CONTEXT in traditional Forth compilers. My experience with gforth suggests that this remains true to this day. Requiring the IMMEDIATE formality as part of declaring a new VOCABULARY (e.g. forth
definitions vocabulary xxx immediate xxx definitions) has worked without fail in my experience.

Furthermore, PostScript and Python3 admit similar privileges to application code, i.e. the creation of code and data in a unique namespace/dictionary. How 'bout that? Was Forth ahead of its time? I say yes.

If I recall correctly, the FigForth installation manual standard word set defined I to return a copy of the return stack (presumably holding the current do...loop index). But the standard screen editor I(nsert line) was an entirely different matter. The
screen editor source code involved flipping back and forth from editor vocabulary I and forth vocabulary I meanings, but was proven to work, and became the reference screen editor in the installation manual. The forth and editor vocabularies needed to be
IMMEDIATE to make the house of cards work

I can also attest to the utility of immediate vocabularies in implementing an assembler for the Intel MCS-48 MCU in days of yore.
E. g, the MOV instruction variants were handily solved by a MOV vocabulary (e. g. MOV A,T, MOV A,R7, MOV A,#FF MOV A,@R0).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <df78b666-ba63-4bba-a999-f38da675f471n@googlegroups.com>,
Myron Plichota <myronplichota@gmail.com> wrote:
<SNIP>

I can also attest to the utility of immediate vocabularies in
implementing an assembler for the Intel MCS-48 MCU in days of yore.
E. g, the MOV instruction variants were handily solved by a MOV
vocabulary (e. g. MOV A,T, MOV A,R7, MOV A,#FF MOV A,@R0).

I can't understand why having immediate vocabularies is such a
big deal.

: doit ..... STRING-NAMESPACE $this .. $THAT .. [ PREVIOUS ]
.... ;

Hardly more hassle is
: doit ..... [ STRING-NAMESPACE ] $this .. $THAT .. [ PREVIOUS ]
.... ;

And more readable (unless you have used conflicting definitions here) STRING-NAMESPACE
: doit ..... $this .. $THAT ..
.... ;
PREVIOUS

You are not into page-long definitions, are you?

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I can't understand why having immediate vocabularies is such a
big deal.

You might want to work on that :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote:

I can't understand why having immediate vocabularies is such a
big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronplichota@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it is deemed to be of no further use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27/08/2023 9:01 pm, albert wrote:

In article <df78b666-ba63-4bba-a999-f38da675f471n@googlegroups.com>,
Myron Plichota <myronplichota@gmail.com> wrote:
<SNIP>

I can also attest to the utility of immediate vocabularies in
implementing an assembler for the Intel MCS-48 MCU in days of yore.
E. g, the MOV instruction variants were handily solved by a MOV
vocabulary (e. g. MOV A,T, MOV A,R7, MOV A,#FF MOV A,@R0).

I can't understand why having immediate vocabularies is such a
big deal.
...

AFAICS immediacy comes in handy when conflicting words within a colon definition
must be referenced. The word that effects change of context can be a vocab name
or a word specifying a search order (whichever is applicable). Without immediacy
such words would need to be surrounded by [ ] .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <8f22d8e9-f6a9-47c2-a47d-96ecc010a7c8n@googlegroups.com>,
Myron Plichota <myronplichota@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote:

I can't understand why having immediate vocabularies is such a
big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronplichota@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal. Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler
in a separate memory area, and then remove them without a trace. It
would be annoying to have the assembler hanging around if you only
want floating point.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

none albert schrieb am Montag, 28. August 2023 um 11:12:32 UTC+2:

In article <8f22d8e9-f6a9-47c2...@googlegroups.com>,
Myron Plichota <myronp...@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote:

I can't understand why having immediate vocabularies is such a
big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronp...@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal.
Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler
in a separate memory area, and then remove them without a trace. It
would be annoying to have the assembler hanging around if you only
want floating point.

To make it usable, ALSO and PREVIOUS would have to be immediate too, no?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <df3fb5d0-e851-40bf-95f0-8dc7a569c7cfn@googlegroups.com>,
minforth <minforth@arcor.de> wrote:

none albert schrieb am Montag, 28. August 2023 um 11:12:32 UTC+2:

In article <8f22d8e9-f6a9-47c2...@googlegroups.com>,
Myron Plichota <myronp...@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote:

I can't understand why having immediate vocabularies is such a
big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronp...@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal.
Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler
in a separate memory area, and then remove them without a trace. It
would be annoying to have the assembler hanging around if you only
want floating point.

To make it usable, ALSO and PREVIOUS would have to be immediate too, no?

Don't go there. If you have a STRING-VOC vocabulary, with APPEND COUNT etc.
use STRING.APPEND STRING.COUNT etc. Less elegantly STRING. COUNT .
In ciforth with the PREFIX facility this is an easy fix.
: STRING-VOC. STRING NAME EVALUATE PREVIOUS ; PREFIX
(NAME is approximately CHECK-FOR-REFILL BL WORD )
Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <nnd$4e59a515$02cc8e17@6abb7dc7ddf99c99>,
none) (albert <albert@cherry.> wrote:

In article <df3fb5d0-e851-40bf-95f0-8dc7a569c7cfn@googlegroups.com>,
minforth <minforth@arcor.de> wrote:

none albert schrieb am Montag, 28. August 2023 um 11:12:32 UTC+2:

In article <8f22d8e9-f6a9-47c2...@googlegroups.com>,
Myron Plichota <myronp...@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote: >>> >> > I can't understand why having immediate vocabularies is such a

big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronp...@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal.
Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler
in a separate memory area, and then remove them without a trace. It
would be annoying to have the assembler hanging around if you only
want floating point.

To make it usable, ALSO and PREVIOUS would have to be immediate too, no?

Don't go there. If you have a STRING-VOC vocabulary, with APPEND COUNT etc. >use STRING.APPEND STRING.COUNT etc. Less elegantly STRING. COUNT .
In ciforth with the PREFIX facility this is an easy fix.
: STRING-VOC. STRING NAME EVALUATE PREVIOUS ; PREFIX

This must be (of course)
: STRING. STRING-VOC NAME EVALUATE PREVIOUS ; PREFIX

(NAME is approximately CHECK-FOR-REFILL BL WORD )
Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the >hide of the bear until you shot it. Better one bird in the hand than ten in >the air. First gain is a cat spinning. - the Wise from Antrim -

--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/08/2023 9:56 pm, minforth wrote:

none albert schrieb am Montag, 28. August 2023 um 11:12:32 UTC+2:

In article <8f22d8e9-f6a9-47c2...@googlegroups.com>,
Myron Plichota <myronp...@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote: >>>>> I can't understand why having immediate vocabularies is such a

big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronp...@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal.
Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler
in a separate memory area, and then remove them without a trace. It
would be annoying to have the assembler hanging around if you only
want floating point.

To make it usable, ALSO and PREVIOUS would have to be immediate too, no?

Under ONLY ALSO scheme immediate vocabulary names could be problematic as
they are often combined to represent a search order. The wrapper itself
could be made immediate. I consider vocabularies 'a necessary evil' i.e.
a last resort. The less 'stack juggling' the better :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxforth schrieb am Dienstag, 29. August 2023 um 04:34:07 UTC+2:

On 28/08/2023 9:56 pm, minforth wrote:

none albert schrieb am Montag, 28. August 2023 um 11:12:32 UTC+2:

In article <8f22d8e9-f6a9-47c2...@googlegroups.com>,
Myron Plichota <myronp...@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote: >>>>> I can't understand why having immediate vocabularies is such a

big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronp...@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal.
Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler
in a separate memory area, and then remove them without a trace. It
would be annoying to have the assembler hanging around if you only
want floating point.

To make it usable, ALSO and PREVIOUS would have to be immediate too, no?

Under ONLY ALSO scheme immediate vocabulary names could be problematic as they are often combined to represent a search order. The wrapper itself could be made immediate. I consider vocabularies 'a necessary evil' i.e.
a last resort. The less 'stack juggling' the better :)

I prefer proper namespace addressing:
s" Alpha Centauri " STRING::TRIM TYPE Alpha Centauri ok

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/08/2023 3:56 pm, minforth wrote:

dxforth schrieb am Dienstag, 29. August 2023 um 04:34:07 UTC+2:

On 28/08/2023 9:56 pm, minforth wrote:

none albert schrieb am Montag, 28. August 2023 um 11:12:32 UTC+2:

In article <8f22d8e9-f6a9-47c2...@googlegroups.com>,
Myron Plichota <myronp...@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote: >>>>>>> I can't understand why having immediate vocabularies is such a

big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronp...@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal.
Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler >>>> in a separate memory area, and then remove them without a trace. It
would be annoying to have the assembler hanging around if you only
want floating point.

To make it usable, ALSO and PREVIOUS would have to be immediate too, no?

Under ONLY ALSO scheme immediate vocabulary names could be problematic as
they are often combined to represent a search order. The wrapper itself
could be made immediate. I consider vocabularies 'a necessary evil' i.e.
a last resort. The less 'stack juggling' the better :)

I prefer proper namespace addressing:
s" Alpha Centauri " STRING::TRIM TYPE Alpha Centauri ok

Not sure what you mean. To remove leading/trailing blanks from a string I define a word for that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxforth schrieb am Dienstag, 29. August 2023 um 10:35:02 UTC+2:

On 29/08/2023 3:56 pm, minforth wrote:

dxforth schrieb am Dienstag, 29. August 2023 um 04:34:07 UTC+2:

On 28/08/2023 9:56 pm, minforth wrote:

none albert schrieb am Montag, 28. August 2023 um 11:12:32 UTC+2:

In article <8f22d8e9-f6a9-47c2...@googlegroups.com>,
Myron Plichota <myronp...@gmail.com> wrote:

On Sunday, August 27, 2023 at 1:42:22 PM UTC-4, Myron Plichota wrote:

I can't understand why having immediate vocabularies is such a >>>>>>> big deal.

You might want to work on that :)

A proven example:
\ Bugs18 assembler make script
\ by Myron Plichota myronp...@gmail.com

Forth definitions marker -Bugs18
vocabulary Bugs18 immediate Bugs18 definitions
hex

s" target.map" included \ the target MCU attributes
s" Bugs18asm.fs" included \ the structured assembler
s" inherited-subs.map" included \ useful subroutines in the serial bootloader

The dictionary can be purged of the Bugs18 vocabulary by invoking -Bugs18 when it
is deemed to be of no further use.

I misunderstood what I meant. The immediacy of vocabularies is not a big deal.
Of course wordlist/namespace/vocabulary is useful.
Not seeing the assembler words is useful. I go a step further.
E.g. if you load floating point in ciforth, you can load the assembler >>>> in a separate memory area, and then remove them without a trace. It >>>> would be annoying to have the assembler hanging around if you only
want floating point.

To make it usable, ALSO and PREVIOUS would have to be immediate too, no? >> Under ONLY ALSO scheme immediate vocabulary names could be problematic as >> they are often combined to represent a search order. The wrapper itself >> could be made immediate. I consider vocabularies 'a necessary evil' i.e. >> a last resort. The less 'stack juggling' the better :)

I prefer proper namespace addressing:
s" Alpha Centauri " STRING::TRIM TYPE Alpha Centauri ok

Not sure what you mean. To remove leading/trailing blanks from a string I define a word for that.

STRING::TRIM -> the word is TRIM to be found in the STRING namespace (vocabulary)

STRING::TRIM is one parsed name without blanks (:: is a separator)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ucjler$22io8$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:

Under ONLY ALSO scheme immediate vocabulary names could be problematic as >they are often combined to represent a search order. The wrapper itself >could be made immediate. I consider vocabularies 'a necessary evil' i.e.
a last resort. The less 'stack juggling' the better :)

On the contrary. wordlists (namespace, vocabulary) are instrumental for extending the language.
In my recent lisp effort (MAL) i have
- the Forth environment where I compile
- the lisp user interface, behaves like lisp.
- a separate wordlist where I accumulate the words used in lisp,
using the search mechanism present in Forth.

If wordlist were not there, I am obliged to invent them.

Groetjes Albert
-
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Zbig schrieb am Dienstag, 29. August 2023 um 11:19:26 UTC+2:

I prefer proper namespace addressing:
s" Alpha Centauri " STRING::TRIM TYPE Alpha Centauri ok

Not sure what you mean. To remove leading/trailing blanks from a string I
define a word for that.

STRING::TRIM -> the word is TRIM to be found in the STRING namespace (vocabulary)

STRING::TRIM is one parsed name without blanks (:: is a separator)

But you are aware, that this means nothing more than using very long name? Not having any „namespaces” included one can simply use the names like STRING::TRIM and voila, „look, I use namespaces!”.

Pardon me, but this is nonsense. STRING:: affects/improves/focusses the search mechanism.
It is separated and processed from STRING::TRIM by a recognizer.

Consider nested namespaces (wordlists) like I use for linear algebra, you must be hit with a
paddle if you prepend hundreds of words with some lengthy ID string.

Obviously this is all non-standard.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I prefer proper namespace addressing:
s" Alpha Centauri " STRING::TRIM TYPE Alpha Centauri ok

Not sure what you mean. To remove leading/trailing blanks from a string I define a word for that.

STRING::TRIM -> the word is TRIM to be found in the STRING namespace (vocabulary)

STRING::TRIM is one parsed name without blanks (:: is a separator)

But you are aware, that this means nothing more than using very long name?
Not having any „namespaces” included one can simply use the names like STRING::TRIM and voila, „look, I use namespaces!”.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

But you are aware, that this means nothing more than using very long name? Not having any „namespaces” included one can simply use the names like STRING::TRIM and voila, „look, I use namespaces!”.

Pardon me, but this is nonsense. STRING:: affects/improves/focusses the search mechanism.
It is separated and processed from STRING::TRIM by a recognizer.

Having defined such „long-named” word one doesn't need any
particular search mechanism different to the standard one. Such
word simply has different name than others — whether it has two
colons middle of its name or, say, two „A” letters.

Consider nested namespaces (wordlists) like I use for linear algebra, you must be hit with a
paddle if you prepend hundreds of words with some lengthy ID string.

Obviously this is all non-standard.

Long ago, when learning TCL, I quickly realized it's kind od „cheating”.
So there's a procedure named, say, ::aaa::bbb::cccc::name, but there
are some „helper procedures” that allow to use (in particular conditions) just the „name”, without the prefix „::aaa::bbb::cccc”.
So in Forth that „helper procedure” is simply the name of particular vocabulary.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/08/2023 6:53 pm, albert wrote:

In article <ucjler$22io8$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:

Under ONLY ALSO scheme immediate vocabulary names could be problematic as
they are often combined to represent a search order. The wrapper itself
could be made immediate. I consider vocabularies 'a necessary evil' i.e.
a last resort. The less 'stack juggling' the better :)

On the contrary. wordlists (namespace, vocabulary) are instrumental for extending the language.
In my recent lisp effort (MAL) i have
- the Forth environment where I compile
- the lisp user interface, behaves like lisp.
- a separate wordlist where I accumulate the words used in lisp,
using the search mechanism present in Forth.

If wordlist were not there, I am obliged to invent them.

You are doing all this because it's necessary - or because you want to?
If the latter, then nobody else is obligated.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/08/2023 7:58 pm, Zbig wrote:

But you are aware, that this means nothing more than using very long name? >>> Not having any „namespaces” included one can simply use the names like >>> STRING::TRIM and voila, „look, I use namespaces!”.

Pardon me, but this is nonsense. STRING:: affects/improves/focusses the search mechanism.
It is separated and processed from STRING::TRIM by a recognizer.

Having defined such „long-named” word one doesn't need any
particular search mechanism different to the standard one. Such
word simply has different name than others — whether it has two
colons middle of its name or, say, two „A” letters.

Consider nested namespaces (wordlists) like I use for linear algebra, you must be hit with a
paddle if you prepend hundreds of words with some lengthy ID string.

Obviously this is all non-standard.

Long ago, when learning TCL, I quickly realized it's kind od „cheating”. So there's a procedure named, say, ::aaa::bbb::cccc::name, but there
are some „helper procedures” that allow to use (in particular conditions) just the „name”, without the prefix „::aaa::bbb::cccc”.
So in Forth that „helper procedure” is simply the name of particular vocabulary.

Forth needs to dump the 'words and numbers separated by spaces' concept. Infixing is the future :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

minforth <minforth@arcor.de> writes:

STRING::TRIM -> the word is TRIM to be found in the STRING namespace (voca= >bulary)

STRING::TRIM is one parsed name without blanks (:: is a separator)

In development Gforth the scope recognizer is installed by default,
but the syntax is slightly different (Output marked with preceding "\ "):

vocabulary string \ ok
string definitions \ ok
: foo ." foo" ; \ ok
forth \ ok
foo
\ *the terminal*:5:1: error: Undefined word
\ >>>foo<<<
\ Backtrace:
\ kernel/int.fs:317:10: 0 $7F118CEA83F0 throw
string:foo \ foo ok

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Zbig <zbigniew2011@gmail.com> writes:

But you are aware, that this means nothing more than using very long name? >Not having any =E2=80=9Enamespaces=E2=80=9D included one can simply use the=
names like
STRING::TRIM and voila, =E2=80=9Elook, I use namespaces!=E2=80=9D.

Yes, that's a traditional Forth technique. However, Joerg Voelker
reported that for his applications, he cannot afford the memory needed
by this technique.

One can also do

ALSO STRING

and then just use TRIM, which may be useful in a piece of code that
uses lots of STRING words.

One disadvantage of the latter technique is that you do not directly
see in the source in what namespace TRIM is.

One disadvantage of the scope recognizer is that not all words that
take a word name can handle a scope recognizer passed to it. E.g., at
the moment

locate string:foo
' string:foo
`string:foo \ xt
``string:foo \ nt
postpone string:foo

work, but

see string:foo

does not. And

``string:foo id.

(and likewise, the decompiler) prints "foo" even when STRING is not in
the search order. Work to do.

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ucm6kk$2f6c1$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote: >On 29/08/2023 6:53 pm, albert wrote:

In article <ucjler$22io8$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:

Under ONLY ALSO scheme immediate vocabulary names could be problematic as >>> they are often combined to represent a search order. The wrapper itself >>> could be made immediate. I consider vocabularies 'a necessary evil' i.e. >>> a last resort. The less 'stack juggling' the better :)

On the contrary. wordlists (namespace, vocabulary) are instrumental for
extending the language.
In my recent lisp effort (MAL) i have
- the Forth environment where I compile
- the lisp user interface, behaves like lisp.
- a separate wordlist where I accumulate the words used in lisp,
using the search mechanism present in Forth.

If wordlist were not there, I am obliged to invent them.

You are doing all this because it's necessary - or because you want to?
If the latter, then nobody else is obligated.

If you don't want to write programs, you don't need to.
Obviously.

In MAL you start up with a lisp interface and prompt:
"
user>(def! a 2)
2
user>(+ 1 a)
3
user>(forth)

2 CONSTANT a
OK
1 a + .
3 OK
main
user>
"
Hard to do (if near impossible) without name spaces, i.e.
switching the topmost wordlist.

Under the hood/bonnet:

\ ---------------- lisp --------------------
:R read-str SET-SRC empty()
lisp-namespace lisp-on INTERPRET PREVIOUS lisp-off build-ast ;

: rep read-str 'repl_env >WID eval_ast print-ast ;

: repl BEGIN prompt (ACCEPT) rep AGAIN ;

\ ---------------- forth -------------------
: main BEGIN ARGC 1 > WHILE handle-options SHIFT-ARGS REPEAT
BEGIN
'[ , R0 @ RSP! S0 @ DSP! \ ..... 1
'repl CATCH DUP -32 = IF BYE THEN
ONLY FORTH ERROR
AGAIN ;

\ ------------------------------------------

There are wordlists used by the lisp interpreter for environments.
One of them constains:
"
: forth QUIT ; #func type!
"

Groetjes Albert
1)
'[ , just means POSTPONE [
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/08/2023 4:11 pm, Anton Ertl wrote:

Zbig <zbigniew2011@gmail.com> writes:

But you are aware, that this means nothing more than using very long name? >> Not having any =E2=80=9Enamespaces=E2=80=9D included one can simply use the= >> names like
STRING::TRIM and voila, =E2=80=9Elook, I use namespaces!=E2=80=9D.

Yes, that's a traditional Forth technique. However, Joerg Voelker
reported that for his applications, he cannot afford the memory needed
by this technique.

Including never-used words also wastes memory, irrespective of naming or vocabularies. I note 4tH libraries are very granular loading only what's necessary. As space-saving strategies go, this appears optimum.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To get back on-topic I'm pasting the quote from the docs
of Mary Bell's fig-Forth V2.32:

Vocabularies: Immediate or Not?

As was seen in the prior examples the creation of a new vocabulary is exceedingly easy, though deciding where they should be located can be a complex process. In addition, a vocabulary like any word defined within the address space can optionally be "
immediate," or acted upon by the compiler the moment it is parsed from the input stream. When this quality is applied to vocabularies it allows for on-the-fly search order changes, but only to the extent of the top Search Order Buffer item. As an example;

80386 fig-FORTH v2.32

Implemented 04/09/03 by MB

VOCABULARY MYTASK IMMEDIATE OK.

MYTASK DEFINITIONS OK.

: NEW-WORD 9 0 DO I . LOOP ; OK.

PREVIOUS DEFINITIONS OK.

: TEST-WORD ." HI!" CR NEW-WORD CR ; NEW-WORD? Huh?

: TEST-WORD ." HI!" CR MYTASK NEW-WORD FORTH CR ; OK.

Examine the last two user lines carefully. The first line failed because the MYTASK vocabulary was removed from the search order by the PREVIOUS DEFINITIONS line before defining TEST-WORD, while the second line succeeded because the MYTASK word in the
line forced the temporary replacement of the top search item within the listing. On the other hand if the MYTASK vocabulary is not made immediate, the following will occur;

80386 fig-FORTH v2.32

Implemented 04/09/03 by MB

VOCABULARY MYTASK OK.

MYTASK DEFINITIONS OK.

: NEW-WORD 9 0 DO I . LOOP ; OK.

PREVIOUS DEFINITIONS OK.

: TEST-WORD ." HI!" CR NEW-WORD CR ; NEW-WORD? Huh?

: TEST-WORD ." HI!" CR MYTASK NEW-WORD FORTH CR ; NEW-WORD? Huh?

In this case the compiler has added the token address of the MYTASK vocabulary word to the TEST-WORD list rather than executing the vocabulary function to change the search order. If such a reference is desired without making the target vocabulary
immediate there are two options; 1) add the vocabulary to the search order given in the methods mentioned earlier, or 2) manually execute the referenced vocabulary as in the following definition;

: TEST-WORD ." HI!" CR [ MYTASK ] NEW-WORD FORTH CR ;

Whether or not a vocabulary is made immediate is optional depending upon its intended use, such as in the case in where the vocabulary which forms complete subroutine and is not expected to have many references to it by outside programs. (Such as the
EDITOR which has a single entry point, and two references which are added to the root path.)

If a vocabulary is not immediate as in the prior example, this allows Forth to change the active search order to meet the specified task. An example would be in a case where the user is expected to enter data containing highly different search parameters,
such as typing the names of automobiles in one case and those of baseball stars in another. If both vocabularies are not made immediate and the user switches between search programs, this allows that the compiler can actively change the search order
between the two functions;

: SWITCH VOC 1 TOGGLE VOC @ IF AUTOMOBILE ELSE BASEBALL THEN ;

Such a statement will change the current search order from within an application, using a single variable to hold notice of the change as the operation continues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/08/2023 6:04 pm, albert wrote:

In article <ucm6kk$2f6c1$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:

On 29/08/2023 6:53 pm, albert wrote:

In article <ucjler$22io8$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:

Under ONLY ALSO scheme immediate vocabulary names could be problematic as >>>> they are often combined to represent a search order. The wrapper itself >>>> could be made immediate. I consider vocabularies 'a necessary evil' i.e. >>>> a last resort. The less 'stack juggling' the better :)

On the contrary. wordlists (namespace, vocabulary) are instrumental for
extending the language.
In my recent lisp effort (MAL) i have
- the Forth environment where I compile
- the lisp user interface, behaves like lisp.
- a separate wordlist where I accumulate the words used in lisp,
using the search mechanism present in Forth.

If wordlist were not there, I am obliged to invent them.

You are doing all this because it's necessary - or because you want to?
If the latter, then nobody else is obligated.

If you don't want to write programs, you don't need to.
Obviously.

In MAL you start up with a lisp interface and prompt:
"
user>(def! a 2)
2
user>(+ 1 a)
3
user>(forth)

2 CONSTANT a
OK
1 a + .
3 OK
main
user>
"
Hard to do (if near impossible) without name spaces, i.e.
switching the topmost wordlist.

Other languages have achieved the same without anything special. If there's one language that's shown itself to be the master of disguise, surely it has been C. One need only look at how many forthers it has fooled :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)