Today I rewrote SEE-CODE (actually it's factor SEE-CODE-RANGE) to
display, e.g.

this instead of this
.... ...
$7F7E43202948 r> 1->1 $7F7E43202948 r> 1->1
7F7E42ECADE4: mov [r15],r8 $7F7E43202950 fill
7F7E42ECADE7: sub r15,$08 7F7E42ECADE4: mov [r15],r8
7F7E42ECADEB: mov r8,[rbx] 7F7E42ECADE7: sub r15,$08
7F7E42ECADEE: add r13,$08 7F7E42ECADEB: mov r8,[rbx]
7F7E42ECADF2: add rbx,$08 7F7E42ECADEE: add r13,$08
7F7E42ECADF6: mov rcx,-$08[r13] 7F7E42ECADF2: add rbx,$08
7F7E42ECADFA: jmp ecx 7F7E42ECADF6: mov rcx,-$08[r13]
7F7E42ECADFC: nop 7F7E42ECADFA: jmp ecx
$7F7E43202950 fill 7F7E42ECADFC: nop
$7F7E43202958 ;s 1->1 $7F7E43202958 ;s 1->1
.... ...

I had to get some additional information from the decompiler
primitive, so we now have

decompile-prim2 ( a_code -- useqlen ustart uend c_addr u ulen )

instead of

decompile-prim ( a_code -- ustart uend c_addr u ulen )

but the existing factoring also was not very amenable to the change,
so I rewrote SEE-CODE-RANGE from scratch, with the following result:

: see-code-range { addr1 addr2 -- } \ gforth
addr1 0 0 0 ['] noop case { addr nseqlen d: codeblock xt: cr? }
addr addr2 u>= ?of endof
addr @ decompile-prim2 { ulen } ulen 0< ?of
drop 2drop 2drop
cr? addr simple-see-word
addr cell+ nseqlen codeblock ['] cr contof
nseqlen 0= if codeblock discode 0 0 to codeblock ['] noop to cr? then
cr? addr see-word.addr type { nseqlen1 ustart uend } ulen if
ustart 4 spaces 0 .r ." ->" uend .
assert( codeblock nip 0= )
addr @ ulen to codeblock then
addr cell+ nseqlen nseqlen1 max 1- codeblock ['] cr
next-case
codeblock discode ;

As you can see, it uses locals heavily (the word I have written with
the most locals by far). If you want to follow what's going on on the
stack, it uses the following additional words:

simple-see-word ( addr -- )
discode ( c-addr u -- )
see-word.addr ( addr -- )

This code took me a while to write, but apart from the handling of the
CRs, it worked on the first try. The handling of the CRs is
complicated, because DISCODE outputs a CR at the start and at the end
(one might consider this a factoring mistake); we could get rid of
everything to do with CR? if DISCODE did not have this property. I
find that the flexible enhanced CASE control structure is a very
natural way for me to consider the different cases and to keep track
of what has been covered already.

For comparison, below you find the old code; it uses fewer locals, and
is factored into three words, but is it better (apart from the
functionality difference)? IMO no.

\ also uses decompile-prim ( addr1 -- addr2 )

: see-code-word { addr -- len }
addr see-word.addr addr @ decompile-prim1 dup >r -1 = if
2drop 2drop addr cell+ addr @ .word drop
else
type 4 spaces swap r@ if
0 .r ." ->" .
else
2drop then
then
r> ;

: see-code-next-inline { addr1 addr2 -- addr3 }
\ decompile starting at addr1 until an inlined primitive is found,
\ or addr2 is reached; addr3 is addr2 or the next inlined
\ primitive
addr1 begin { addr }
addr addr2 u< while
addr @ dup decompile-prim = while
addr cr simple-see-word
addr cell+
repeat then
addr ;

: see-code-range { addr1 addr2 -- } \ gforth
cr addr1 begin { a }
a see-code-word { restlen }
a cell+ addr2 see-code-next-inline { b }
a @ b addr2 u< while
( a @ ) b @ over - discode
b
repeat
\ now disassemble the remaining a @; we derive the length from
\ it's primitive
restlen discode ;
\ dup decompile-prim dup next-prim swap - discode ;

- 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 2022: https://euro.theforth.net

On 27/10/2022 7:51 am, Anton Ertl wrote:
>
> For comparison, below you find the old code; it uses fewer locals, and
> is factored into three words, but is it better (apart from the
> functionality difference)? IMO no.

If factoring simplifies code and removes the need for strange Case words,
IMO that's a good thing.

: foo ( addr1 addr2 -- )
>r 0 swap 0 0 ['] noop begin { nseqlen addr d: codeblock xt: cr? }
addr r@ u>= not while
addr @ decompile-prim2 { ulen } ulen 0< if
drop 2drop 2drop
cr? addr simple-see-word
nseqlen
else
nseqlen 0= if codeblock discode 0 0 to codeblock ['] noop to cr? then
cr? addr see-word.addr type { nseqlen1 ustart uend } ulen if
ustart 4 spaces 0 .r ." ->" uend .
assert( codeblock nip 0= )
addr @ ulen to codeblock then
nseqlen nseqlen1 max 1-
then
addr cell+ codeblock ['] cr
repeat r> drop ;

: see-code-range ( addr1 addr2 -- ) \ gforth
foo codeblock discode ;

dxforth <dxforth@gmail.com> writes:
>On 27/10/2022 7:51 am, Anton Ertl wrote:
>If factoring simplifies code and removes the need for strange Case words,
>IMO that's a good thing.
>
>: foo ( addr1 addr2 -- )
> >r 0 swap 0 0 ['] noop begin { nseqlen addr d: codeblock xt: cr? }
> addr r@ u>= not while
> addr @ decompile-prim2 { ulen } ulen 0< if
> drop 2drop 2drop
> cr? addr simple-see-word
> nseqlen
> else
> nseqlen 0= if codeblock discode 0 0 to codeblock ['] noop to cr? then
> cr? addr see-word.addr type { nseqlen1 ustart uend } ulen if
> ustart 4 spaces 0 .r ." ->" uend .
> assert( codeblock nip 0= )
> addr @ ulen to codeblock then
> nseqlen nseqlen1 max 1-
> then
> addr cell+ codeblock ['] cr
> repeat r> drop ;
>
>: see-code-range ( addr1 addr2 -- ) \ gforth
> foo codeblock discode ;

Yes, once one has a working version, one can reorganize it, and in
this case it's relatively straightforward to replace the
CASE...NEXT-CASE with a BEGIN ... REPEAT through the introduction of
an ELSE. But it's helpful to have the additional possibilities while
creating the code, and then one can switch to the more traditional
control structures if desired.

The splitting into two words does not work that way, because CODEBLOCK
is a local. It's also unnecessary, because you can just append
"CODEBLOCK DISCODE" to FOO. And the name you chose for FOO also shows
that FOO is not a useful factor for use by other words.

Concerning the partial replacement of locals by keeping the values on
the return stack or data stack, that also can be done more easily in a
second step. But given that we use locals here anyway, I don't find
the result in any way preferable.

If performance was an issue (it is not for this word), on some systems
that might be a reason to use more data stack (not so sure about
return stack) items rather than locals; one data stack item (as used
above) is helpful on most systems, because they keep one data stack
item in a register across basic block boundaries; it's less clearcut
for return stack items or more data stack items.

- 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 2022: https://euro.theforth.net

On 27/10/2022 9:32 pm, Anton Ertl wrote:
>
> Concerning the partial replacement of locals by keeping the values on
> the return stack or data stack, that also can be done more easily in a
> second step. But given that we use locals here anyway, I don't find
> the result in any way preferable.

There it is. I don't find locals preferable in any way. It pushes
me to find whether there's another, potentially better, solution.

On Thursday, October 27, 2022 at 2:19:53 PM UTC+2, dxforth wrote:
> On 27/10/2022 9:32 pm, Anton Ertl wrote:
> There it is. I don't find locals preferable in any way. It pushes
> me to find whether there's another, potentially better, solution.
Hear, hear. I also don't like long definitions. They're a horror to maintain.
Short words make the logic comprehensible - at every level. Both the lower
level words as well as the higher level words.

Hans Bezemer

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>I also don't like long definitions. They're a horror to maintain.
>Short words make the logic comprehensible - at every level. Both the lower
>level words as well as the higher level words.

I am awaiting you posting code for this problem to support your
claims.

- 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 2022: https://euro.theforth.net

On 28/10/2022 3:24 am, Anton Ertl wrote:
> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> I also don't like long definitions. They're a horror to maintain.
>> Short words make the logic comprehensible - at every level. Both the lower
>> level words as well as the higher level words.
>
> I am awaiting you posting code for this problem to support your
> claims.

It's not enough he doesn't use locals in his own code - he should do
your coding as well? :)

The appeal of locals in forth is the idea that somehow they're free.
Try this test. Replace the locals in your code with regular variables/
values. Now ask yourself whether you still think it's good code; for
it should make no difference to 'good code' where the variables are
located. If one isn't happy with variables external to forth words,
one shouldn't be happy with those internal to them.

dxforth <dxforth@gmail.com> writes:
> If one isn't happy with variables external to forth words, one
> shouldn't be happy with those internal to them.

1. The externals make the code harder to understand / maintain since they
persist across function calls and can be shared between functions. You can
use some naming conventions to indicate that this isn't happening, but
ugh. And you still have to re-initialize the global inside the function
on every call.

2. If the function is recursive you can't use global variables. You have to
set up a separate stack for them or something. Ugh.

3. The globals keep occupying storage even when the function is not running.
I thought Forthers liked stack allocation so that the memory would keep
getting re-used. Locals give that.

Paul Rubin schrieb am Freitag, 28. Oktober 2022 um 10:33:30 UTC+2:
> dxforth <dxf...@gmail.com> writes:
> > If one isn't happy with variables external to forth words, one
> > shouldn't be happy with those internal to them.
> 1. The externals make the code harder to understand / maintain since they
> persist across function calls and can be shared between functions. You can
> use some naming conventions to indicate that this isn't happening, but
> ugh. And you still have to re-initialize the global inside the function
> on every call.
>
> 2. If the function is recursive you can't use global variables. You have to
> set up a separate stack for them or something. Ugh.
>
> 3. The globals keep occupying storage even when the function is not running.
> I thought Forthers liked stack allocation so that the memory would keep
> getting re-used. Locals give that.

+1 Technical aspects and personal tastes put aside, IMO the most important
benefits of using locals is instantaneous readability of code.

The human brain is no stack machine. We think in associations IOW by tagging
names to material and non-material things and concepts.

Forth is a strange animal: by factoring we try to chop long algorithms into smallest
pieces and then try to give them meaningful names to make the code understandable.
Within those pieces we allow masochistic stack juggling and some guys even claim
to be happy.

But sometimes factorization does not come easily, see Anton's example. It is
good that we have the choice to use locals where they are appropriate.

For quick testing and prototyping I sometimes even use extended locals, in their form:
: TEST { a b .. | d e .. == f g .. } .. ;
with
a b .. standard initialized locals
d e .. standard uninitialized locals
== instead of standard --
f g output locals, non-standard
All locals can be integers, doubles, floats, complex numbers (plus arrays and structs)

So in principle FROT could be defined as
: FROT { f: a b c == b c a } ; \ no code required
with complex numbers:
: ZROT { z: a b c == b c a } ; \ no code required

While this example is close to triviality (the locals compiler is not) real-world code
with extended locals and good short locals names is VERY readable, and mostly bug
free from start.

On Friday, October 28, 2022 at 10:33:30 AM UTC+2, Paul Rubin wrote:
> 1. The externals make the code harder to understand / maintain since they
> persist across function calls and can be shared between functions. You can
> use some naming conventions to indicate that this isn't happening, but
> ugh. And you still have to re-initialize the global inside the function
> on every call.
>
> 2. If the function is recursive you can't use global variables. You have to
> set up a separate stack for them or something. Ugh.
>
> 3. The globals keep occupying storage even when the function is not running.
> I thought Forthers liked stack allocation so that the memory would keep
> getting re-used. Locals give that.

I hope you and C become very happy. Oh dear, no! You can blow up your program
if you're incapable of balancing your malloc() - free() calls. It's much the same way
like stack balancing, you know. I hope you and Rust become very happy.

Hans Bezemer

On Friday, October 28, 2022 at 10:11:08 AM UTC+2, dxforth wrote:
> On 28/10/2022 3:24 am, Anton Ertl wrote:
> > Hans Bezemer <the.bee...@gmail.com> writes:
> >> I also don't like long definitions. They're a horror to maintain.
> >> Short words make the logic comprehensible - at every level. Both the lower
> >> level words as well as the higher level words.
> >
> > I am awaiting you posting code for this problem to support your
> > claims.
> It's not enough he doesn't use locals in his own code - he should do
> your coding as well? :)

ROFL! We're slowly becoming soulmates I think. I was contemplating my
answer along the same line of thought - before I read your post. ;-)

Hans Bezemer

On Friday, October 28, 2022 at 5:36:28 PM UTC+2, minf...@arcor.de wrote:
> Paul Rubin schrieb am Freitag, 28. Oktober 2022 um 10:33:30 UTC+2:
> > dxforth <dxf...@gmail.com> writes:
> > > If one isn't happy with variables external to forth words, one
> > > shouldn't be happy with those internal to them.
> > 1. The externals make the code harder to understand / maintain since they
> > persist across function calls and can be shared between functions. You can
> > use some naming conventions to indicate that this isn't happening, but
> > ugh. And you still have to re-initialize the global inside the function
> > on every call.
If you need a carload of variables, you've forgotten (or completely disregarded)
the first rule of "Thinking Forth", which is "STAMP OUT THE VARIABLES"!

> > 2. If the function is recursive you can't use global variables. You have to
> > set up a separate stack for them or something. Ugh.
See rule number one.

> > 3. The globals keep occupying storage even when the function is not running.
> > I thought Forthers liked stack allocation so that the memory would keep
> > getting re-used. Locals give that.
So does C. It also introduces the penalty of stack frame creation and destruction.

> +1 Technical aspects and personal tastes put aside, IMO the most important
> benefits of using locals is instantaneous readability of code.
If you need locals for that, you're not doing it correctly. Short definitions allow for
readability - not locals.

> The human brain is no stack machine. We think in associations IOW by tagging
> names to material and non-material things and concepts.
We were spoiled by Fortran, which allowed us to translate mathematical formulas
almost directly to working code. Blame mathematics for that notation.

> Forth is a strange animal: by factoring we try to chop long algorithms into smallest
> pieces and then try to give them meaningful names to make the code understandable.
> Within those pieces we allow masochistic stack juggling and some guys even claim
> to be happy.
If there is excessive stack juggling, it might be because you're (a) a totally incompetent
Forth programmer, (b) a lazy Forth programmer, who feels good translating C code
directly to Forth without studying the algorithm and (c) in some circumstances it's
not worth, needed or even desired to reduce the amount of stack juggling. My rule of
the thumb is - if I can't understand it I rewrite it.

> But sometimes factorization does not come easily, see Anton's example. It is
> good that we have the choice to use locals where they are appropriate.
Nobody says it is or should be easy! It requires thought and some tinkering. If
you just want to churn out code quickly, you should do Forth - but Python! However,
often library code is the hardest to get right IMHO. Application code - not so much.
I was able to create a 64K Forth source in 5 days. In a professional setting. It never
missed a beat in its entire lifetime - despite the excessive diagnostic code.

Hans Bezemer

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> > I thought Forthers liked stack allocation so that the memory would keep
>> > getting re-used. Locals give that.
> So does C. It also introduces the penalty of stack frame creation and
> destruction.

If you mean the frame pointer, you don't really need that, it just makes
debugging easier. You can pass -ffomit-frame-pointer to gcc to omit it.

>> But sometimes factorization does not come easily, see Anton's
>> example. It is good that we have the choice to use locals where they
>> are appropriate.

> Nobody says it is or should be easy! It requires thought and some
> tinkering. If you just want to churn out code quickly, you should do
> Forth - but Python!

Is there some benefit gained from that thought and tinkering and loss of
productivity? Does it make the code faster, more reliable, or anything
like that? Otherwise it sounds like masochism or some misplaced
ideological extremism, like "the stack operators cannot fail--they can
only be failed".

Here is the simplest way I can see to multiply of two complex numbers
(x=a+bi, y=c+di, z=x*y):

: z* { F: a F: b F: c F: d -- F: ac-bd F: ad+bc }
a c f* b d f* f- a d f* b c f* f+ ;

That example could use FVARIABLEs instead of locals but it would be a
lot messier imho. There are no FVALUEs in standard Forth iirc, so you
have to use @ everywhere, and then your auditing process has to make
sure nothing else uses those variables, including by having anything
aliased to the pointers in the variables, and so on. There is no
equivalent of the return stack to stash intermediate FP values, so stack
juggling becomes harder. Maybe it is still possible, but who wants to
spend the debugging effort? I can't believe it helps readability.

I have another example that uses FP locals and is recursive, so moving
them to FVARIABLEs isn't even workable. I don't see a general approach
other than an auxiliary FP stack implement in user code. Ugh.

"minf...@arcor.de" <minforth@arcor.de> writes:
> For quick testing and prototyping I sometimes even use extended
> locals, in their form:
> : TEST { a b .. | d e .. == f g .. } .. ;

That is cool, what Forth implements that? I haven't seen it before.
Just ending the word with "f g" seems like enough though:

: swap { a b } b a ;

On 28/10/2022 7:33 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> If one isn't happy with variables external to forth words, one
>> shouldn't be happy with those internal to them.
>
> 1. The externals make the code harder to understand / maintain since they
> persist across function calls and can be shared between functions. You can
> use some naming conventions to indicate that this isn't happening, but
> ugh. And you still have to re-initialize the global inside the function
> on every call.
>
> 2. If the function is recursive you can't use global variables. You have to
> set up a separate stack for them or something. Ugh.
>
> 3. The globals keep occupying storage even when the function is not running.
> I thought Forthers liked stack allocation so that the memory would keep
> getting re-used. Locals give that.

Oh, I'm not advocating variables - locals or otherwise. What I see is a lot
of promiscuous use of the former as if there were no cost. Here's an example
of using extra locals - not out of necessity - but 'style':

https://gforth.org/manual/Locals-programming-style.html

In C, locals are unavoidable - it's not a matter of style or choice. In Forth,
locals are all about style. The more the better so we're told. Unfortunately
Forth was never designed for it. Compared to data stack, the return stack is
the smaller - intended only to hold return addresses and the occasional temp.
Nested definitions using locals will quickly eat it up. You decide whether
style is worth the cost.

On 29/10/2022 1:25 pm, Paul Rubin wrote:
> ...
> Here is the simplest way I can see to multiply of two complex numbers
> (x=a+bi, y=c+di, z=x*y):
>
> : z* { F: a F: b F: c F: d -- F: ac-bd F: ad+bc }
> a c f* b d f* f- a d f* b c f* f+ ;
>
> That example could use FVARIABLEs instead of locals but it would be a
> lot messier imho. There are no FVALUEs in standard Forth iirc, so you
> have to use @ everywhere, and then your auditing process has to make
> sure nothing else uses those variables, including by having anything
> aliased to the pointers in the variables, and so on. There is no
> equivalent of the return stack to stash intermediate FP values, so stack
> juggling becomes harder. Maybe it is still possible, but who wants to
> spend the debugging effort? I can't believe it helps readability.

How many times will you code Z* ? FWIW FSLIB already has it.

> I have another example that uses FP locals and is recursive, so moving
> them to FVARIABLEs isn't even workable. I don't see a general approach
> other than an auxiliary FP stack implement in user code. Ugh.

FP locals isn't supported by any standard. Some folks have suggested
there should be a F>R R>F which would allow recursive f/p variables.
IIRC Wil Baden had a scheme that used memory at HERE as f/p locals.
The situations you present as requiring locals are obscure enough that
there is almost always another way. But you have to want to find it.

On 29/10/2022 3:14 am, Hans Bezemer wrote:
> On Friday, October 28, 2022 at 10:11:08 AM UTC+2, dxforth wrote:
>> On 28/10/2022 3:24 am, Anton Ertl wrote:
>>> Hans Bezemer <the.bee...@gmail.com> writes:
>>>> I also don't like long definitions. They're a horror to maintain.
>>>> Short words make the logic comprehensible - at every level. Both the lower
>>>> level words as well as the higher level words.
>>>
>>> I am awaiting you posting code for this problem to support your
>>> claims.
>> It's not enough he doesn't use locals in his own code - he should do
>> your coding as well? :)
>
> ROFL! We're slowly becoming soulmates I think. I was contemplating my
> answer along the same line of thought - before I read your post. ;-)

It's not as if we hadn't been here before and don't know the answers :)

Paul Rubin schrieb am Samstag, 29. Oktober 2022 um 04:29:03 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > For quick testing and prototyping I sometimes even use extended
> > locals, in their form:
> > : TEST { a b .. | d e .. == f g .. } .. ;
> That is cool, what Forth implements that? I haven't seen it before.
> Just ending the word with "f g" seems like enough though:
>
> : swap { a b } b a ;

This would be a SWAP defined in standard Forth with single braces à la gforth.
For such extremely short definitions there is no benefit from output locals..

But consider complicated algorithms (in my case signal processing math).
There it helps when the compiler does the stack juggling for you by parsing
the stack comment COMPLETELY. Standard Forth stops halfway in the process
by ignoring everything after -- . But sometimes it is a waste of programmer's time
when he has to keep track of the machine state/stacks instead of concentrating
on the algorithm.

F.ex.
: DEARCHMEAN { tagname tstart tend f: factor | sum == rec: tagrec f: mval n: flag }
< algorithm > ;
extracts the the archived signal 'tagname' between points of time tstart to tend and
calculates the mean signal value mval using the fp-locals factor and sum. The extracted
time series record tagrec and and a flag are returned as well. The "living stack comment"
says it all. Your eyes don't have to scan the following algo code to find out where/when
final results are put on the stack, moved into the correct order, and intermediate
calculations are cleared/dropped away. Let the compiler do this for you. The algo's
code becomes uncluttered, more readable, and shorter.

Some smart guys think that this smells too much of Python. But they ignore that this is
still Forth, ultra-compact for embedding, and fast enough in 98% of all cases.

And there is a second advantage: when the compiler knows the outputs of a word, it
can raise a warning when it is connected to a word with non-matching input characteristic.
This compile-time I/O matching can be very helpful, but not always.

On 28/10/2022 17:28, Hans Bezemer wrote:
> On Friday, October 28, 2022 at 5:36:28 PM UTC+2,minf...@arcor.de wrote:
>> Paul Rubin schrieb am Freitag, 28. Oktober 2022 um 10:33:30 UTC+2:
>>> dxforth<dxf...@gmail.com> writes:
>>>> If one isn't happy with variables external to forth words, one
>>>> shouldn't be happy with those internal to them.
>>> 1. The externals make the code harder to understand / maintain since they
>>> persist across function calls and can be shared between functions. You can
>>> use some naming conventions to indicate that this isn't happening, but
>>> ugh. And you still have to re-initialize the global inside the function
>>> on every call.
> If you need a carload of variables, you've forgotten (or completely disregarded)
> the first rule of "Thinking Forth", which is "STAMP OUT THE VARIABLES"!
>

You don't seem to practice what you preach e.g.

\ -----------------------------------------------------------
\ 4tH library - string CONCAT - Copyright 2012 J.L. Bezemer
\ You can redistribute this file and/or modify it under
\ the terms of the GNU General Public License

[UNDEFINED] concat [IF]
variable __concat \ destination address

: concat ( a1 n1 .. ai ni i a2 -- a2 n2)
__concat ! 1- dup \ save destination, setup counter
begin dup while rot >r rot >r 1- repeat drop >r __concat @ place r>
begin dup while r> r> __concat @ +place 1- repeat drop __concat @ count
; \ first transfer to Rstack, then append
\ ----------------------------------------------------------

Seems a bit of a dog's breakfast to me: unnecesssary use of a variable,
lengthy definition and unnecessary call to PLACE, crashes if i=0,
incorrect & misleading stack comment. Compare with:

: concat ( ca1 u1 .. can un n ca -- ca+1 u )
0 over c! swap
[: ?dup if 2swap 2>r 1- recurse dup 2r> rot +place then ;]
execute count
;

--
Gerry

On Saturday, October 29, 2022 at 9:41:27 AM UTC+2, Gerry Jackson wrote:
[..]
> Seems a bit of a dog's breakfast to me: unnecesssary use of a variable,
> lengthy definition and unnecessary call to PLACE, crashes if i=0,
> incorrect & misleading stack comment. Compare with:
>
> : concat ( ca1 u1 .. can un n ca -- ca+1 u )
> 0 over c! swap
> [: ?dup if 2swap 2>r 1- recurse dup 2r> rot +place then ;]
> execute count
> ;

FORTH> : concats ( ca1 u1 .. can un n -- ca u ) 1- 0 max 0 ?DO $+ LOOP ;
FORTH> S" Hello" S" , " S" world" S" !" 4 concats
[2]FORTH> type Hello, world! ok
-marcel

On Saturday, October 29, 2022 at 9:41:27 AM UTC+2, Gerry Jackson wrote:
> > If you need a carload of variables, you've forgotten (or completely disregarded)
> > the first rule of "Thinking Forth", which is "STAMP OUT THE VARIABLES"!
> >
> You don't seem to practice what you preach e.g.
Well, the only lesson one could take from it is "there is always someone more clever
than you" - which IMHO is just a fact of life. You will probably find more examples in
the 500+ libraries I wrote - if you dig really well.

However, if this is the only example you found in 75 KLOC of 4tH, I think I'm not doing
too bad. BTW, it's a clever piece of code. Kudos!

Hans Bezemer

On Saturday, October 29, 2022 at 9:41:27 AM UTC+2, Gerry Jackson wrote:
> incorrect & misleading stack comment.
I now see where your comment about "misleading stack comment" comes
from. In 4tH ASCIIZ strings are used - and a2 is actually the address that is
returned.

That your code works is because the first line effectively terminates
the target string - and the abstraction of +PLACE does the heavy lifting.

But I forgive you ;-)

Hans Bezemer

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>On Friday, October 28, 2022 at 10:11:08 AM UTC+2, dxforth wrote:
>> On 28/10/2022 3:24 am, Anton Ertl wrote:
>> > Hans Bezemer <the.bee...@gmail.com> writes:
>> >> I also don't like long definitions. They're a horror to maintain.
>> >> Short words make the logic comprehensible - at every level. Both the lower
>> >> level words as well as the higher level words.
>> >
>> > I am awaiting you posting code for this problem to support your
>> > claims.
>> It's not enough he doesn't use locals in his own code - he should do
>> your coding as well? :)

I did do my own coding. Hans Bezemer just made general claims, so I
called him to show that there is substance to his words (and it's
about long definitions, not locals).

>ROFL! We're slowly becoming soulmates I think. I was contemplating my
>answer along the same line of thought - before I read your post. ;-)

Apparently there is no substance to your words. As for being
soulmates, dxforth has posted code to demonstrate a part of his
positions (and his code actually inspired me to transform the control
structure in the way he suggested).

- 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 2022: https://euro.theforth.net

On 29/10/2022 7:05 pm, Marcel Hendrix wrote:
>
> FORTH> : concats ( ca1 u1 .. can un n -- ca u ) 1- 0 max 0 ?DO $+ LOOP ;
> FORTH> S" Hello" S" , " S" world" S" !" 4 concats
> [2]FORTH> type Hello, world! ok

: concats <# 0 ?do holds loop 0 0 #> ;

s" Hello" s" , " s" world" s" !" 4 concats type Hello, world! ok

On Saturday, October 29, 2022 at 3:41:08 PM UTC+2, Anton Ertl wrote:
> I did do my own coding.
What can I say. It shows. LOL!

> Apparently there is no substance to your words. As for being
> soulmates, dxforth has posted code to demonstrate a part of his
> positions (and his code actually inspired me to transform the control
> structure in the way he suggested).
C'mon. Do you know how old I am? Do you really expect me to dance to
your tune? That's how kids challenge each other in kindergarten!

Hans Bezemer