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.

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.

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 -

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

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

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.

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.

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

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

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

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

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

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

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.

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, ;

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

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

(
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

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).

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 -

> I can't understand why having immediate vocabularies is such a
> big deal.
You might want to work on that :)

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.

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 [ ] .

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 -

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?

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 -