On 30/08/2021 12:22, Krishna Myneni wrote:

> : allot? ( u -- a ) here swap allot ;

IIRC you've had this forever. I never thought much about it at
the time. Now a convert, I find uses for it all the time e.g.

$95 constant TLEN \ length of each term definition
$100 constant CHUNK \ in-file chunk to get
20 constant ISIZ \ size input buffer / terminal name
200 constant TMAX \ max #terminals

\ Storage areas allocated at run-time
here value TBUF ( -- a ) \ temp terminal buffer
here value SBUF ( -- a ) \ swap/work buffer
here value IBUF ( -- a ) \ console input
here value XBUF ( -- a ) \ terminal index

: INIT ( -- )
altered off \ clear
isiz reserve to ibuf \ console input
tlen reserve to tbuf \ temp terminal buffer
chunk reserve to sbuf \ swap/work buffer
tmax cells reserve to xbuf \ terminal index
;

On 8/30/21 12:14 AM, dxforth wrote:
> On 30/08/2021 12:22, Krishna Myneni wrote:
>
>> : allot?  ( u -- a ) here swap allot ;
>
> IIRC you've had this forever.  I never thought much about it at
> the time.  Now a convert, I find uses for it all the time e.g.
>

ALLOT? was originally called ?ALLOT in kForth, but that word is
deprecated now in kForth, in favor of ALLOT?, following a suggestion on
word naming by Ruvim. ALLOT? is essential for making use of the dynamic
dictionary model implemented in kForth, which has no HERE.

> $95  constant TLEN      \ length of each term definition
> $100 constant CHUNK     \ in-file chunk to get
> 20   constant ISIZ      \ size input buffer / terminal name
> 200  constant TMAX      \ max #terminals
>
> \ Storage areas allocated at run-time
> here value TBUF     ( -- a )  \ temp terminal buffer
> here value SBUF     ( -- a )  \ swap/work buffer
> here value IBUF     ( -- a )  \ console input
> here value XBUF     ( -- a )  \ terminal index
>
> : INIT ( -- )
>   altered off                 \ clear
>   isiz       reserve to ibuf  \ console input
>   tlen       reserve to tbuf  \ temp terminal buffer
>   chunk      reserve to sbuf  \ swap/work buffer
>   tmax cells reserve to xbuf  \ terminal index
> ;

RESERVE is a synonym of ALLOT? .

--
Krishna

On 2021-08-30 15:26, Krishna Myneni wrote:
> On 8/30/21 12:14 AM, dxforth wrote:
>> On 30/08/2021 12:22, Krishna Myneni wrote:
>>
>>> : allot?  ( u -- a ) here swap allot ;
>>
>> IIRC you've had this forever.  I never thought much about it at
>> the time.  Now a convert, I find uses for it all the time e.g.
>>
>
> ALLOT? was originally called ?ALLOT in kForth, but that word is
> deprecated now in kForth, in favor of ALLOT?, following a suggestion on
> word naming by Ruvim. ALLOT? is essential for making use of the dynamic
> dictionary model implemented in kForth, which has no HERE.

AFAIR, I only criticized the "?ALLOT" name for this word, and I didn't
suggest "ALLOT?" as a better variant.

Usually the question mark at the end (like "X?") means that this word
return a *flag* at the top; usually there is also a variant of the word
without the question mark (like "X") that doesn't return a flag.

For example, "KEY ( -- char )" returns a character,
and "KEY? ( -- flag )" returns only a flag about available of a
character. Ditto for "EKEY" and "EKEY?", "XKEY" and "XKEY?".

The word "XC!+?" returns a flag, while "XC!+" doesn't

The word "ENVIRONMENT?" doesn't have a pair, but it also returns a flag
at the top.

The idea is that if a name ends with the question mark, then the word
returns a flag at the top (NB: the converse does not hold).

Obviously, the name "ALLOT?" for ( u -- addr ) breaks this convention.

A possible variant for your word is "ALLOTED ( u -- addr )"

But I would prefer "ALLOTED ( u -- addr u )".
And I used "ALLOCATED ( u -- addr u )" for allocating in the heap,
since usually my APIs allow to set a buffer with arbitrary size.

For example:

256 1024 * ALLOCATED DATASPACE!

buf-size-default ALLOCATED buf1!
buf-size-default ALLOCATED buf2!

where
DATASPACE! ( addr u -- )

buf1 ( -- addr u )
buf1! ( addr u -- )

buf2 ( -- addr u )
buf2! ( addr u -- )

Among the standards words we have: "ALIGN ( -- )"
and "ALIGNED ( addr1 -- addr2 )"

>
>> $95  constant TLEN      \ length of each term definition
>> $100 constant CHUNK     \ in-file chunk to get
>> 20   constant ISIZ      \ size input buffer / terminal name
>> 200  constant TMAX      \ max #terminals
>>
>> \ Storage areas allocated at run-time
>> here value TBUF     ( -- a )  \ temp terminal buffer
>> here value SBUF     ( -- a )  \ swap/work buffer
>> here value IBUF     ( -- a )  \ console input
>> here value XBUF     ( -- a )  \ terminal index
>>
>> : INIT ( -- )
>>    altered off                 \ clear
>>    isiz       reserve to ibuf  \ console input
>>    tlen       reserve to tbuf  \ temp terminal buffer
>>    chunk      reserve to sbuf  \ swap/work buffer
>>    tmax cells reserve to xbuf  \ terminal index
>> ;
>
> RESERVE is a synonym of ALLOT? .

Obviously, yes.

"RESERVE" is better, but I don't sure that this name is good enough to
recommend it for FORTH word list.

--
Ruvim

On 2021-08-30 10:11 AM, Ruvim wrote:
>
> Obviously, yes.
>
> "RESERVE" is better, but I don't sure that this name is good enough to
> recommend it for FORTH word list.
>
>
> --
> Ruvim

Although not a proper English word, ALLOC might be a name for this
thing.

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-08-30 15:26, Krishna Myneni wrote:
>> On 8/30/21 12:14 AM, dxforth wrote:
>>> On 30/08/2021 12:22, Krishna Myneni wrote:
>>>
>>>> : allot?  ( u -- a ) here swap allot ;
>>>
>>> IIRC you've had this forever.  I never thought much about it at
>>> the time.  Now a convert, I find uses for it all the time e.g.
>>>
>>
>> ALLOT? was originally called ?ALLOT in kForth, but that word is
>> deprecated now in kForth, in favor of ALLOT?, following a suggestion on
>> word naming by Ruvim. ALLOT? is essential for making use of the dynamic
>> dictionary model implemented in kForth, which has no HERE.
>
>AFAIR, I only criticized the "?ALLOT" name for this word, and I didn't
>suggest "ALLOT?" as a better variant.
>
>Usually the question mark at the end (like "X?") means that this word
>return a *flag* at the top; usually there is also a variant of the word
>without the question mark (like "X") that doesn't return a flag.
>
>For example, "KEY ( -- char )" returns a character,
>and "KEY? ( -- flag )" returns only a flag about available of a
>character. Ditto for "EKEY" and "EKEY?", "XKEY" and "XKEY?".
>
>The word "XC!+?" returns a flag, while "XC!+" doesn't
>
>The word "ENVIRONMENT?" doesn't have a pair, but it also returns a flag
>at the top.
>
>The idea is that if a name ends with the question mark, then the word
>returns a flag at the top (NB: the converse does not hold).
>
>Obviously, the name "ALLOT?" for ( u -- addr ) breaks this convention.

Yes, it's not a good name.

Similarly, a "?" at the start means that the word takes a flag and/or
that the word may or may not perform an action: e.g., ?DUP ?EXIT
?BRANCH.

Incidentially, I just needed such a word a few days ago; there is
already a word (originally for a special purpose) in Gforth that does
that: SMALL-ALLOT, so I used that. But the word and its name is not
appropriate for general-purpose usage (it is limited to allocations
smaller than a page).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

issue
assign
supply
provide
give
grant
furnish
impart
bestow
extend
reserve

On 2021-08-30 19:19, Doug Hoffman wrote:
> issue
> assign
> supply
> provide
> give
> grant
> furnish
> impart
> bestow
> extend
> reserve

From this list I like "provide" and "impart".

OTOH, it's desirable to have an association with "allot", I think.

A possible variant:

allotted-head ( u -- addr )

--
Ruvim

On 8/30/21 9:11 AM, Ruvim wrote:
> On 2021-08-30 15:26, Krishna Myneni wrote:
>> On 8/30/21 12:14 AM, dxforth wrote:
>>> On 30/08/2021 12:22, Krishna Myneni wrote:
>>>
>>>> : allot?  ( u -- a ) here swap allot ;
>>>
>>> IIRC you've had this forever.  I never thought much about it at
>>> the time.  Now a convert, I find uses for it all the time e.g.
>>>
>>
>> ALLOT? was originally called ?ALLOT in kForth, but that word is
>> deprecated now in kForth, in favor of ALLOT?, following a suggestion
>> on word naming by Ruvim. ALLOT? is essential for making use of the
>> dynamic dictionary model implemented in kForth, which has no HERE.
>
> AFAIR, I only criticized the "?ALLOT" name for this word, and I didn't
> suggest "ALLOT?" as a better variant.
>

Ok. I may be misremembering. I may have just changed the name to ALLOT?
after considering your criticism of ?ALLOT to be justified. In any case,
I'm not willing to tinker with it further. ALLOT? does return something,
though it is not a flag.

Krishna

On Monday, 30 August 2021 at 19:59:26 UTC+1, Krishna Myneni wrote:
> On 8/30/21 9:11 AM, Ruvim wrote:
> > On 2021-08-30 15:26, Krishna Myneni wrote:
> >> On 8/30/21 12:14 AM, dxforth wrote:
> >>> On 30/08/2021 12:22, Krishna Myneni wrote:
> >>>
> >>>> : allot? ( u -- a ) here swap allot ;
> >>>
> >>> IIRC you've had this forever. I never thought much about it at
> >>> the time. Now a convert, I find uses for it all the time e.g.
> >>>
> >>
> >> ALLOT? was originally called ?ALLOT in kForth, but that word is
> >> deprecated now in kForth, in favor of ALLOT?, following a suggestion
> >> on word naming by Ruvim. ALLOT? is essential for making use of the
> >> dynamic dictionary model implemented in kForth, which has no HERE.
> >
> > AFAIR, I only criticized the "?ALLOT" name for this word, and I didn't
> > suggest "ALLOT?" as a better variant.
> >
> Ok. I may be misremembering. I may have just changed the name to ALLOT?
> after considering your criticism of ?ALLOT to be justified. In any case,
> I'm not willing to tinker with it further. ALLOT? does return something,
> though it is not a flag.
>
>
> Krishna

Why do we need a new word when BUFFER: exists

https://forth-standard.org/standard/core/BUFFERColon

On 8/30/21 2:25 PM, Ruvim wrote:

> ... it's desirable to have an association with "allot", I think.

I agree.

> A possible variant:
>
> allotted-head ( u -- addr )

That would work.

-Doug

On Monday, 30 August 2021 at 22:19:04 UTC+2, NN wrote:
> On Monday, 30 August 2021 at 19:59:26 UTC+1, Krishna Myneni wrote:
> > On 8/30/21 9:11 AM, Ruvim wrote:
> > > On 2021-08-30 15:26, Krishna Myneni wrote:
> > >> On 8/30/21 12:14 AM, dxforth wrote:
> > >>> On 30/08/2021 12:22, Krishna Myneni wrote:
> > >>>
> > >>>> : allot? ( u -- a ) here swap allot ;
> > >>>
> > >>> IIRC you've had this forever. I never thought much about it at
> > >>> the time. Now a convert, I find uses for it all the time e.g.
> > >>>
> > >>
> > >> ALLOT? was originally called ?ALLOT in kForth, but that word is
> > >> deprecated now in kForth, in favor of ALLOT?, following a suggestion
> > >> on word naming by Ruvim. ALLOT? is essential for making use of the
> > >> dynamic dictionary model implemented in kForth, which has no HERE.
> > >
> > > AFAIR, I only criticized the "?ALLOT" name for this word, and I didn't
> > > suggest "ALLOT?" as a better variant.
> > >
> > Ok. I may be misremembering. I may have just changed the name to ALLOT?
> > after considering your criticism of ?ALLOT to be justified. In any case,
> > I'm not willing to tinker with it further. ALLOT? does return something,
> > though it is not a flag.
> >
> >
> > Krishna
> Why do we need a new word when BUFFER: exists

Exactly my thought also!

$95 constant TLEN
TLEN BUFFER: TBUF

works very well

BR
Peter

> https://forth-standard.org/standard/core/BUFFERColon

On Monday, August 30, 2021 at 7:14:51 AM UTC+2, dxforth wrote:
I agree, these are bad names. I think I'd do something like this:

200 constant #terms
256 constant /chunk
aka chars units

#terms cells assign to xbuf
/chunk chars assign to sbuf

Hans Bezemer

> On 30/08/2021 12:22, Krishna Myneni wrote:
>
> > : allot? ( u -- a ) here swap allot ;
>
> IIRC you've had this forever. I never thought much about it at
> the time. Now a convert, I find uses for it all the time e.g.
>
> $95 constant TLEN \ length of each term definition
> $100 constant CHUNK \ in-file chunk to get
> 20 constant ISIZ \ size input buffer / terminal name
> 200 constant TMAX \ max #terminals
>
> \ Storage areas allocated at run-time
> here value TBUF ( -- a ) \ temp terminal buffer
> here value SBUF ( -- a ) \ swap/work buffer
> here value IBUF ( -- a ) \ console input
> here value XBUF ( -- a ) \ terminal index
>
> : INIT ( -- )
> altered off \ clear
> isiz reserve to ibuf \ console input
> tlen reserve to tbuf \ temp terminal buffer
> chunk reserve to sbuf \ swap/work buffer
> tmax cells reserve to xbuf \ terminal index
> ;

NN <november.nihal@gmail.com> writes:
> Why do we need a new word when BUFFER: exists
> https://forth-standard.org/standard/core/BUFFERColon

Why is that in CORE? CREATE foo 20 ALLOT is what I always used.
ALLOT? is for when you don't want to create a name.

Ruvim <ruvim.pinka@gmail.com> writes:
> allotted-head ( u -- addr )

How about ALLOT> based on things like R> plopping an address onto the stack.

On 2021-08-31 01:51, Paul Rubin wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> allotted-head ( u -- addr )
>
> How about ALLOT> based on things like R> plopping an address onto the stack.
>

In ">r", "r>" (and similar), ">" means moving an item from/to another place.

This case is another one.

Actually, the symbol ">" is used for many meanings.

Among the standard words there are (with some examples):
- the operation "greater-than": ">", "u>", "0>"
- as a part of the pictogram "not-equals": "<>", "0<>"
- an angle parenthesis: "<#" "#>"
- as a graphical alternative to "to":
- moving an item to/from another place (usually a stack):
">r", "n>r", "nr>"
- conversion of a type: "d>s", "d>f"
- extracting details (with flag): "ekey>char", "ekey>fkey"
- extracting details (without flag): "name>string"
- switching to another field: "name>", ">body"
- conversion of a form (representation): ">number", ">float"
- some very strange (if not ugly) variants: "cmove>", "does>", ">in"

It's not a good idea to increase the last group group of very strange
cases, I think. Moreover, this group words can be made deprecated and
replaced.

Some additional comments.

In the case of the words:

name> ( nt -- xt )
>body ( xt -- addr )

they actually imply "xt", i.e. "name>(xt)" and "(xt)>body".

The words ">number", ">float" imply "text", i.e. "text to number
(integer)" and "text to float number". Despite of similar names, their
signatures are not isomorphic.

In "cmove>", the symbol ">" is just a hint for "from higher addresses to
lower addresses", but it's very *confused*. Since ">" can also mean the
normal direction from left to right (and then, from lower to higher
addresses).

In "does>", the symbol ">" looks like a temporary thoughtless solution
(perhaps "in front"), that became permanent.
Taking into account the words ";code" and ":noname", "does>" should be
named as ";:does", e.g.:

: foo create ... ;:does ... ;

">in" is generally a museum exhibit.
I can guess, ">" means "a pointer in", and "in" means "input buffer"
See also: https://forth-standard.org/standard/core/toIN#contribution-110
I would like to find an alternative to this word.

--
Ruvim

On 31/08/2021 00:11, Ruvim wrote:
>
> "RESERVE" is better, but I don't sure that this name is good enough to
> recommend it for FORTH word list.

What Forth word list - the standard? No. I'm simply drawing
attention to a function I appear to have unwittingly reinvented.

The name RESERVE comes from language XPL0 in which I had some
involvement. Simulating it in forth required HERE SWAP ALLOT
which got tedious.

Regarding naming, how many variations of ALLOT ALLOCATE can a
language stomach? Forth isn't C :) IMO using a different name
breaks the monotony, is actually easier to remember and reads
better.

On 31/08/2021 04:59, Krishna Myneni wrote:
> On 8/30/21 9:11 AM, Ruvim wrote:
>> On 2021-08-30 15:26, Krishna Myneni wrote:
>>> On 8/30/21 12:14 AM, dxforth wrote:
>>>> On 30/08/2021 12:22, Krishna Myneni wrote:
>>>>
>>>>> : allot?  ( u -- a ) here swap allot ;
>>>>
>>>> IIRC you've had this forever.  I never thought much about it at
>>>> the time.  Now a convert, I find uses for it all the time e.g.
>>>>
>>>
>>> ALLOT? was originally called ?ALLOT in kForth, but that word is
>>> deprecated now in kForth, in favor of ALLOT?, following a suggestion
>>> on word naming by Ruvim. ALLOT? is essential for making use of the
>>> dynamic dictionary model implemented in kForth, which has no HERE.
>>
>> AFAIR, I only criticized the "?ALLOT" name for this word, and I didn't
>> suggest "ALLOT?" as a better variant.
>>
>
> Ok. I may be misremembering. I may have just changed the name to ALLOT?
> after considering your criticism of ?ALLOT to be justified. In any case,
> I'm not willing to tinker with it further. ALLOT? does return something,
> though it is not a flag.
>

?xxx typically meant conditionally do something. So if ?ALLOT first
checked available memory one could argue it was appropriate relative to
ALLOT where it hasn't been a requirement. OTOH the similarity in names
can work against one.

On 31/08/2021 08:49, Paul Rubin wrote:
> NN <november.nihal@gmail.com> writes:
>> Why do we need a new word when BUFFER: exists
>> https://forth-standard.org/standard/core/BUFFERColon
>
> Why is that in CORE? CREATE foo 20 ALLOT is what I always used.
> ALLOT? is for when you don't want to create a name.
>

Likely the name of the buffer has been defined but there's reason
to postpone allocation e.g. keep executables small. Simpler than
ALLOCATE.

On 31/08/2021 10:50, Ruvim wrote:
>
> In "does>", the symbol ">" looks like a temporary thoughtless solution
> (perhaps "in front"), that became permanent.
> Taking into account the words ";code" and ":noname", "does>" should be
> named as ";:does", e.g.:
>
> : foo create ... ;:does ... ;

Originally it was <BUILDS DOES>

Before that there was ;: though I'm uncertain of the usage. It doesn't
appear to have used CREATE etc which may have been its Achilles' heel and
why abandoned.

Paul Rubin <no.email@nospam.invalid> writes:
>NN <november.nihal@gmail.com> writes:
>> https://forth-standard.org/standard/core/BUFFERColon
>
>Why is that in CORE?

It's in CORE EXT (the EXT part is not obvious in general on
Forth-standard.org). Why not?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Ruvim <ruvim.pinka@gmail.com> writes:
>In "cmove>", the symbol ">" is just a hint for "from higher addresses to
>lower addresses", but it's very *confused*. Since ">" can also mean the
>normal direction from left to right (and then, from lower to higher
>addresses).

Note the pronounciation: "c-move-up". It means: cmove the memory
block from lower to higher addresses; i.e., the name describes the
usage (what), not the how. The how is overspecified for the
application, though. Fortunately, we have MOVE now, making both CMOVE
and CMOVE> unnecessary.

>In "does>", the symbol ">" looks like a temporary thoughtless solution
>(perhaps "in front"), that became permanent.

The idea that I have read was that you would write the defining word
like:

: const <builds , does> @ ;

So <BUILDS points to the name of the new defining word, while DOES>
points to the code executed when the defined word runs.

One can also see the < and > as angle brackets including the code
performed at defining time.

Of course, later <BUILDS was replaced by CREATE, leaving DOES> without
counterpart.

Still, people have used > to end other return-address-using words;
e.g., Stepen Pelc found the following code in the wild
<4ffffe5e.117344919@192.168.0.50> (AFAIK Bernd Paysan used to use such
words):

\ VFX-specific
: list> ( thread -- element )
BEGIN @ dup WHILE dup r@ execute
REPEAT drop r> drop ;

which is used like

: foo bar list> bla blub ;

A list is passed to LIST>, which then executes the "bla blub" part
repeatedly, once for every list element. A more modern (and more
flexible and soon-standard) approach is to put "bla blub" inside a
quotation and call that with EXECUTE for each list element.

So > at the end of the word has become a general indication that the
rest of the word is treated as separate definition.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Here's a listing of the naming conventions published in 'Thinking
Forth' and 'Forth Programmers Handbook':

https://pastebin.com/qpZLFc6h

As to the difference between:

!name Store into name !DATA

name! Store into name B!

I was informed it likely stemmed from when forth names were stored
as count-plus-three characters.

On 2021-08-31 10:10, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> In "cmove>", the symbol ">" is just a hint for "from higher addresses to
>> lower addresses", but it's very *confused*. Since ">" can also mean the
>> normal direction from left to right (and then, from lower to higher
>> addresses).
>
> Note the pronounciation: "c-move-up". It means: cmove the memory
> block from lower to higher addresses; i.e., the name describes the
> usage (what), not the how.
[...]

It's unconvincing. It seems to me that "from lower to higher addresses"
is about "how".

Also, there is a word "cmove" with pronunciation "c-move", without "up",
that actually moves "from lower to higher addresses".

In anyway, the intention was that ">" is pronounced as "up" in this
case. Perhaps, it means "move to upper addresses"?

Well, it just a lesson that for new names their etymology should be
written in their rationale.

An interesting thing that in Forth-79 this word had the name "<CMOVE"
with the pronunciation "reverse-c-move".

https://www.complang.tuwien.ac.at/forth/fth79std/FORTH-79.TXT

>> In "does>", the symbol ">" looks like a temporary thoughtless solution
>> (perhaps "in front"), that became permanent.
>
> The idea that I have read was that you would write the defining word
> like:
>
> : const <builds , does> @ ;

In Forth-79 the both ways already were available — via "<builds" (like
above), and via "create":

: const create , does> @ ;

What was a different is unclear.

"<builds" was a compile-only word (attribute "C"), but not an immediate
word (no attribute "I").

> So <BUILDS points to the name of the new defining word, while DOES>
> points to the code executed when the defined word runs.

I don't see how "<" in "<BUILDS" says that this word points to the name
of the new definition.

The meaning of "<" and ">" in these names is *not obvious*, we should admit.

> One can also see the < and > as angle brackets including the code
> performed at defining time.

It's far from obvious too. E.g. compare to "<# #>" where they are
really just angle brackets.

> Of course, later <BUILDS was replaced by CREATE, leaving DOES> without
> counterpart.
>
> Still, people have used > to end other return-address-using words;
> e.g., Stepen Pelc found the following code in the wild
> <4ffffe5e.117344919@192.168.0.50> (AFAIK Bernd Paysan used to use such
> words):
>
> \ VFX-specific
> : list> ( thread -- element )
> BEGIN @ dup WHILE dup r@ execute
> REPEAT drop r> drop ;
>
> which is used like
>
> : foo bar list> bla blub ;
>
> A list is passed to LIST>, which then executes the "bla blub" part
> repeatedly, once for every list element.

In the context of BacFORTH, some people (including me) used for that an
arrow-like pictogram "=>", so the code looked as:

: foo bar list=> bluh blub ;

In BacForth it can be also nested, e.g:

: foo bar list=> bluh buz list=> blub ;

I.e., for each element of the "bar" list it also iterates the "buz" list.

[...]

> So > at the end of the word has become a general indication that the
> rest of the word is treated as separate definition.

I would not encourage such usage of ">", and would suggest something
more contrast like "==>" instead (if any).

--
Ruvim

On 31.08.2021 09:10, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>
> Note the pronounciation: "c-move-up". It means: cmove the memory
> block from lower to higher addresses; i.e., the name describes the
> usage (what), not the how. The how is overspecified for the
> application, though. Fortunately, we have MOVE now, making both CMOVE
> and CMOVE> unnecessary.
>

And, unfortunately, introducing a run-time decision for the rare case
that source and destination memory areas overlap.

One strength of Forth (and one "10x" of C. Moore's "1000x") is the
ability to do at editing time what can be done at editing time, i.e. if
you know that source and destination do not overlap (or if dest overlaps
the lower source), you use the simpler CMOVE, if dest overlaps upper
part of source, use the equally simple (but cache-unfriendly) CMOVE>.

Still better, alignment would have to be taken into account, in order to
move word-sized (or SIMD-packet-sized) quantities if appropriate.
Admittedly, this would lead to an explosion of similar words, each for
itself with very limited use.

C and Fortran compilers invest a considerable amount into analysis of
moving/copying objects at compile time, and are often, but not always,
able to produce decently performing code. Still, in C the programmer is
bound to provide information, whether he/she intends to avoid trashing
of the source area (by either calling memcpy or memmove). In C,
assignments of potentially aliased pointer targets not specified as
'restrict' have to be compiled analogous to memmove, whereas in Fortran
aliasing is explicitly forbidden.

[snip]

B.

On 31.08.2021 14:23, dxforth wrote:
> Here's a listing of the naming conventions published in 'Thinking
> Forth' and 'Forth Programmers Handbook':
>
> https://pastebin.com/qpZLFc6h
>
> As to the difference between:
>
>   !name     Store into name                           !DATA
>
>   name!     Store into name                           B!
>
> I was informed it likely stemmed from when forth names were stored
> as count-plus-three characters.

There are some examples for the difference between those two:

C! ( c-addr c -- ) store a character into address
!R ( x -- ) store x into address on return stack

Or, in Machine Forth (~1997):
!A/@A store to/load from address in A register
A copy A to TOS
A! pop TOS into A register

--
B.