On 9/09/2021 05:49, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> defer moveto ' 2drop is moveto
>> defer lineto ' 2drop is lineto
>>
>> : RECT1 { x1 y1 x2 y2 -- }
>> x1 y1 moveto x2 y1 lineto
>> x2 y2 lineto x1 y2 lineto x1 y1 lineto ;
>
> Bytecode compilation:
>
> LOCAL1 LOCAL2 CALL moveto
> LOCAL3 LOCAL2 CALL moveto
> LOCAL3 LOCAL4 CALL lineto
> LOCAL1 LOCAL2 CALL lineto
>
> Bytecodes LOCAL1..LOCAL4 and CALL are 1 byte each, code addresses 2
> bytes, total 20 bytes. Actually maybe could use GreenArrays-like
> instruction coding (top bit = CALL) to make <CALL address> 2 bytes, so
> 16 bytes total. That limits code space to 32k, but once you have that
> much you're not so hungry for it anyway.
>
>> : RECT2 ( x1 y1 x2 y2 -- ) \ P.Rubin c.l.f
>> 2over 2dup moveto 2over swap rot lineto
>> 2swap lineto lineto lineto ;
>
> 2OVER 2DUP CALL moveto
> 2OVER SWAP ROT CALL lineto
> 2SWAP CALL lineto
> CALL lineto CALL lineto
>
> 6+12=18 or 6+8=14 bytes, not bad, you saved 2 bytes. The code is much
> more confusing though. Was it worth it? Probably not imho.

No doubt a racing car is confusing under the hood. It's designed for
performance, not admiration - though I'm sure engineers do, especially
when they've done it using a minimum number of parts.

Worth it? You tell me. Someone once said if a book is worth reading,
then it's worth thinking about. Having invested not a little time into
forth, it would be a disservice not to put in the effort to understand
where it's coming from and why.

On Wednesday, September 8, 2021 at 9:49:55 PM UTC+2, Paul Rubin wrote:
You don't have to murder the language to do it using the stack. You just got to understand the algorithm:

include lib/anscore.4th

: moveto ;
: lineto ;

: RECT1 ( x1 y1 x2 y2 -- ) \ J.L. Bezemer c.l.f
>r >r over over moveto
r@ over lineto r> r@ lineto
over r> lineto over over lineto
;

: RECT2 ( x1 y1 x2 y2 -- ) \ P.Rubin c.l.f
2over 2dup moveto 2over swap rot lineto
2swap lineto lineto lineto ;

IMHO this is just sloppy coding.

4tH message: No errors at word 89
Object size: 89 words
String size: 0 chars
Variables : 0 cells
Strings : 0 chars
Symbols : 9 names
Reliable : Yes

Addr| Opcode Operand Argument

0| branch 6 2!
1| swap 0
2| over 0
3| ! 0
4| +literal 1
5| ! 0
6| exit 0
7| branch 13 2@
8| dup 0
9| +literal 1
10| @ 0
11| swap 0
12| @ 0
13| exit 0
14| branch 25 2OVER
15| >r 0
16| >r 0
17| over 0
18| over 0
19| r> 0
20| r> 0
21| rot 0
22| >r 0
23| rot 0
24| r> 0
25| exit 0
26| branch 39 2ROT
27| >r 0
28| >r 0
29| rot 0
30| >r 0
31| rot 0
32| r> 0
33| r> 0
34| r> 0
35| rot 0
36| >r 0
37| rot 0
38| r> 0
39| exit 0
40| branch 50 2TUCK
41| over 0
42| >r 0
43| rot 0
44| >r 0
45| rot 0
46| over 0
47| r> 0
48| r> 0
49| rot 0
50| exit 0
51| branch 52 moveto
52| exit 0
53| branch 54 lineto
54| exit 0
55| branch 72 RECT1
56| >r 0
57| >r 0
58| over 0
59| over 0
60| call 51 moveto
61| r@ 0
62| over 0
63| call 53 lineto
64| r> 0
65| r@ 0
66| call 53 lineto
67| over 0
68| r> 0
69| call 53 lineto
70| over 0
71| over 0
72| branch 53 lineto
73| branch 88 RECT2
74| call 14 2OVER
75| over 0
76| over 0
77| call 51 moveto
78| call 14 2OVER
79| swap 0
80| rot 0
81| call 53 lineto
82| rot 0
83| >r 0
84| rot 0
85| r> 0
86| call 53 lineto
87| call 53 lineto
88| branch 53 lineto

Hans Bezemer

On Thursday, September 9, 2021 at 2:18:18 PM UTC+2, Hans Bezemer wrote:
Ok, not testing your code is immediately punished - as it should ;-)

include lib/anscore.4th

: moveto 2drop ;
: lineto 2drop ;

: RECT1 ( x1 y1 x2 y2 -- ) \ J.L. Bezemer c.l.f
>r >r over over moveto
r@ over lineto r> r@ lineto
over r> lineto lineto
;

: RECT2 ( x1 y1 x2 y2 -- ) \ P.Rubin c.l.f
2over 2dup moveto 2over swap rot lineto
2swap lineto lineto lineto ;

Hans Bezemer

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> : RECT1 ( x1 y1 x2 y2 -- ) \ J.L. Bezemer c.l.f
> >r >r over over moveto
> r@ over lineto r> r@ lineto
> over r> lineto lineto ;

I count 18 bytes of bytecode if <CALL addr> is 2 bytes.

> : RECT2 ( x1 y1 x2 y2 -- ) \ P.Rubin c.l.f
> 2over 2dup moveto 2over swap rot lineto
> 2swap lineto lineto lineto ;

I think this is dxforth's version, also 18 bytes, assuming there are
bytecodes for 2dup, 2swap, rot etc. Note rot reaches 3 levels deep in
the stack 2swap reaches 4 levels, so why do we say the stack is not an
array?

Paul Rubin <no.email@nospam.invalid> writes:
>> : RECT2 ( x1 y1 x2 y2 -- ) \ P.Rubin c.l.f
>> 2over 2dup moveto 2over swap rot lineto
>> 2swap lineto lineto lineto ;
>
> I think this is dxforth's version, also 18 bytes

No, sorry, I mis-counted. 16 bytes, and yours is 20 bytes. Although,
dxforth's has 8 items on the data stack some of the time. A possible
locals version:

: RECT3/4 { x1 y1 x2 y2 -- } x1 y1 moveto
x1 y2 lineto x2 y2 lineto x2 y1 lineto x1 y1 lineto ;

This is 20 bytes like yours, or maybe 21 depending on how the locals are
saved, but I think the action is much easier to understand.

: RECT5 ( x1 y1 x2 y2 -- ) 2dup moveto
3.pick over lineto ( x1 y1 x2 y2 )
nup lineto ( x1 y1 x2 )
nup lineto ( x1 y1 )
lineto ;

(untested) is 15 bytes assuming a single byte "3.pick" equivalent to "3
pick", and Rob Chapman's "nup" (= over swap). But the head scratching
needed for this really doesn't seem worth it. Serious optimization
attempts should be in assembler rather than interpreted languages. A
clever enough compiler might be able to turn the locals version into
that, though.

Since lineto is called 4 times, it's possible the compiler could also
constant-fold its address somehow, and save another byte or two. A
whole-program compiler could do that more aggressively.

Paul Rubin schrieb am Donnerstag, 9. September 2021 um 19:35:33 UTC+2:
> Hans Bezemer <the.bee...@gmail.com> writes:
> > : RECT1 ( x1 y1 x2 y2 -- ) \ J.L. Bezemer c.l.f
> > >r >r over over moveto
> > r@ over lineto r> r@ lineto
> > over r> lineto lineto ;
> I count 18 bytes of bytecode if <CALL addr> is 2 bytes.
> > : RECT2 ( x1 y1 x2 y2 -- ) \ P.Rubin c.l.f
> > 2over 2dup moveto 2over swap rot lineto
> > 2swap lineto lineto lineto ;
> I think this is dxforth's version, also 18 bytes, assuming there are
> bytecodes for 2dup, 2swap, rot etc. Note rot reaches 3 levels deep in
> the stack 2swap reaches 4 levels, so why do we say the stack is not an
> array?

For whatever reasons standard Forth requires that locals must not reside in
the data stack. IMO this was an unfortunate overspecification of implementation
options/techniques for locals, thereby forbidding stack frames that could
be addresses like arrays.

"minf...@arcor.de" <minforth@arcor.de> writes:
> For whatever reasons standard Forth requires that locals must not
> reside in the data stack. IMO this was an unfortunate
> overspecification of implementation options/techniques for locals,
> thereby forbidding stack frames that could be addresses like arrays.

People are uncomfortable with PICK even though it's presumably a Chuck
Moore invention. I'd expect something like POKE, writing into the stack
interior, would destroy the illusion the rest of the way.

On 9/09/2021 22:29, Hans Bezemer wrote:
> On Thursday, September 9, 2021 at 2:18:18 PM UTC+2, Hans Bezemer wrote:
> Ok, not testing your code is immediately punished - as it should ;-)
>
> ...
>
> : RECT1 ( x1 y1 x2 y2 -- ) \ J.L. Bezemer c.l.f
> >r >r over over moveto
> r@ over lineto r> r@ lineto
> over r> lineto lineto
> ;

Does a little better on VFX (86/27 vs. 93/27).
On DX-Forth it's 14 instr vs. 11 assuming 2OVER.

Neither are particularly readable to me - nor need to be IMO.
The name should say it all, and short definitions in forth
costing less than in traditional languages it pans out.
Admittedly some may be concerned at the prospect of having
153 colon definitions (it surprised me too). But that's Forth,
and with it comes a new paradigm. Where I had used a colon
definition, others might use a structure.

On Friday, September 10, 2021 at 5:07:59 AM UTC+2, Paul Rubin wrote:
> People are uncomfortable with PICK even though it's presumably a Chuck
> Moore invention. I'd expect something like POKE, writing into the stack
> interior, would destroy the illusion the rest of the way.

It MOST CERTAINLY isn't: "But as to stack parameters, the stacks should be shallow. On the i21 we have an on-chip stack 18 deep. This size was chosen as a number effectively infinite.
The words that manipulate that stack are DUP, DROP and OVER period. There's no, well SWAP is very convenient and you want it, but it isn't a machine instruction. But no PICK no ROLL, none of the complex operators to let you index down into the stack. This is the only part of the stack, these first two elements, that you have any business worrying about".

Fake news. You gotta learn the language properly. There's no easy way around it.

http://www.ultratechnology.com/moore4th.htm

Hans Bezemer

On Friday, September 10, 2021 at 9:11:24 AM UTC+2, dxforth wrote:
> Neither are particularly readable to me - nor need to be IMO.
That's why they invented comments. But I agree with you. Especially in libraries I don't care much about stack acrobatics. It's application programs that need MOST maintenance - not the libraries (if you're doing a great job)..

I confess - sometimes I do encounter a lib that is so messed up (often because 4tH is a developing language and some facilities were not implemented when the lib was created) I feel I have to redo the darn thing - but it's rare.

> The name should say it all, and short definitions in forth
> costing less than in traditional languages it pans out.
> Admittedly some may be concerned at the prospect of having
> 153 colon definitions (it surprised me too). But that's Forth,
> and with it comes a new paradigm. Where I had used a colon
> definition, others might use a structure.

And frankly, I do not care too much which version compiles to how many byte(code)s in which version. Often a compiler is a reflection of the view of that person to the problem at hand. So his preferred style of programming will be reflected in that benchmark.

E.g. I do not support locals in the core. I don't even support ANY "double" stack operator in the core. If the implementation of a "double" stack operator is just a few bytecodes, it's inlined. Others, like 2ROT and 2OVER are external and have to be explicitly included.

The only reason they're supported in the core as inlines is the support for address/count strings, which I added in v3.5 (which is now a long time ago, but anyways). So, using "double" stack operators in 4tH comes with a size and speed penalty.

If one support locals in ones core, since one likes to use locals, then yes - that will turn out to be quite efficient (at least size wise). Don't understand me wrong - I'm not out here to start a flamewar about whose implementation is best or whose design objectives are valid and whose's not - I'm simply trying to illustrate that "size" is a BAD metric for "efficiency" if you're performing it along several different compilers.

Hans Bezemer

On 10/09/2021 20:14, Hans Bezemer wrote:
> On Friday, September 10, 2021 at 5:07:59 AM UTC+2, Paul Rubin wrote:
>> People are uncomfortable with PICK even though it's presumably a Chuck
>> Moore invention. I'd expect something like POKE, writing into the stack
>> interior, would destroy the illusion the rest of the way.
>
> It MOST CERTAINLY isn't: "But as to stack parameters, the stacks should be shallow. On the i21 we have an on-chip stack 18 deep. This size was chosen as a number effectively infinite.
> The words that manipulate that stack are DUP, DROP and OVER period. There's no, well SWAP is very convenient and you want it, but it isn't a machine instruction. But no PICK no ROLL, none of the complex operators to let you index down into the stack. This is the only part of the stack, these first two elements, that you have any business worrying about".
>
> Fake news. You gotta learn the language properly. There's no easy way around it.

FWIW the app I recently posted breaks down as follows:

#colon defs: #inputs:
100 0
26 1
16 2
9 3
1 4

While I have PICK and ROLL I had no cause to use them in this instance.

Paul Rubin <no.email@nospam.invalid> writes:
> People are uncomfortable with PICK even though it's presumably a Chuck
> Moore invention. I'd expect something like POKE, writing into the stack
> interior, would destroy the illusion the rest of the way.

I've used pick on occasion, but never without the feeling that it was hack on
top of some code which could have been designed better.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> People are uncomfortable with PICK even though it's presumably a Chuck
>> Moore invention.
> It MOST CERTAINLY isn't: "But as to stack parameters, the stacks
> should be shallow. On the i21 we have an on-chip stack 18
> deep. .... But no PICK no ROLL...

The i21 and other such chips came well after the invention of PICK. So
if Moore didn't invent PICK, then who is the culprit and when did it
happen? The NRAO document "Forth, A Problem-Oriented Language" by Moore
and Rather (https://library.nrao.edu/public/memos/comp/CDIR_11.pdf
sec. 3.2, start near bottom of page 18 of the pdf, split across a
table), says:

Several words have been defined in basic FORTH for manipulating the
stack. summarized in the table. The operation of these words is A
fairly standard set of more complicated stack operators is available
in some developed applications, for such things as double precision
numbers, fetching numbers several levels down in the stack, etc.

The document itself doesn't describe PICK, but that paragraph seems to
say that someone needed it for an application so they implemented it.
Who was writing such applications in that era? What should they have
done instead, if they found the builtins (missing PICK at the time)
insufficient for getting their work done?

> Fake news. You gotta learn the language properly. There's no easy way
> around it.

Of course there is an easy way around it. It's just being treated as
objectionable on grounds that I'm still trying to understand.

On Friday, September 10, 2021 at 3:31:17 PM UTC+2, Andy Valencia wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> > People are uncomfortable with PICK even though it's presumably a Chuck
> > Moore invention. I'd expect something like POKE, writing into the stack
> > interior, would destroy the illusion the rest of the way.
> I've used pick on occasion, but never without the feeling that it was hack on
> top of some code which could have been designed better.

I find 565 occurences of PICK in a total of 2077 Forth files. Of these,
280 are for 2 PICK, far less for 3 PICK and almost none for n > 5.
Some call these THIRD and FOURTH, but for me that make no sense.
(DUP <= ONE, OVER <= SECOND ?)

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>Some call these THIRD and FOURTH, but for me that make no sense.
>(DUP <= ONE, OVER <= SECOND ?)

DUP = FIRST
OVER = SECOND

- 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

Marcel Hendrix <mhx@iae.nl> writes:
> I find 565 occurences of PICK in a total of 2077 Forth files. Of these,
> 280 are for 2 PICK, far less for 3 PICK and almost none for n > 5.

I realize that's a lot of occurrences, but when you run your eyes over
the code, do any qualities of the surrounding code jump out at you?

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On 11/09/2021 06:25, Andy Valencia wrote:
> Marcel Hendrix <mhx@iae.nl> writes:
>> I find 565 occurences of PICK in a total of 2077 Forth files. Of these,
>> 280 are for 2 PICK, far less for 3 PICK and almost none for n > 5.
>
> I realize that's a lot of occurrences, but when you run your eyes over
> the code, do any qualities of the surrounding code jump out at you?

It does seem excessive. OTOH PICK and ROLL are so ugly they're usually not
a problem avoiding. The Honey Trap in Forth is locals as they look so
innocent and even give the impression they're doing good. It's a mistake
to say 'never ever' but in the case of locals one should really try due to
their quick and seductive path to self-destruction.

On Friday, September 10, 2021 at 3:31:17 PM UTC+2, Andy Valencia wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> > People are uncomfortable with PICK even though it's presumably a Chuck
> > Moore invention. I'd expect something like POKE, writing into the stack
> > interior, would destroy the illusion the rest of the way.
> I've used pick on occasion, but never without the feeling that it was hack on
> top of some code which could have been designed better.

I used it once in a Rosetta Code example because I was in a hurry, but I'm still not proud of that. In 4tH, it is an external word, which makes it quite slow as well. But given it's primary there for porting, it's not that important.

It feels as dirty as waking up with a horrible hangover beside a puddle of vomit in the arms of some tattooed hoe with a nose piercing. Not that I'm familiar with this kind of situation. I deny everything.

Hans Bezemer

On Friday, September 10, 2021 at 6:44:53 PM UTC+2, Paul Rubin wrote:
> Of course there is an easy way around it. It's just being treated as
> objectionable on grounds that I'm still trying to understand.

It's easy: read "Thinking Forth". Read it carefully - and like tasting good wine, don't gobble it down, but play with these ideas. Forth is essentially what remains after you strip a language to its bare essentials. The VM of C also has a stack - but here you are responsible for maintaing it. The VM of C also uses RPN. Here you write it straight away.

That stripping is not accidental. It was for a reason. And that's for you to still figure out.

May be now you understand why adding these things back sounds so ludricous.

Hans Bezemer

On 11/09/2021 02:44, Paul Rubin wrote:
> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>> People are uncomfortable with PICK even though it's presumably a Chuck
>>> Moore invention.
>> It MOST CERTAINLY isn't: "But as to stack parameters, the stacks
>> should be shallow. On the i21 we have an on-chip stack 18
>> deep. .... But no PICK no ROLL...
>
> The i21 and other such chips came well after the invention of PICK. So
> if Moore didn't invent PICK, then who is the culprit and when did it
> happen? The NRAO document "Forth, A Problem-Oriented Language" by Moore
> and Rather (https://library.nrao.edu/public/memos/comp/CDIR_11.pdf
> sec. 3.2, start near bottom of page 18 of the pdf, split across a
> table), says:
>
> Several words have been defined in basic FORTH for manipulating the
> stack. summarized in the table. The operation of these words is A
> fairly standard set of more complicated stack operators is available
> in some developed applications, for such things as double precision
> numbers, fetching numbers several levels down in the stack, etc.
>
> The document itself doesn't describe PICK, but that paragraph seems to
> say that someone needed it for an application so they implemented it.
> Who was writing such applications in that era? What should they have
> done instead, if they found the builtins (missing PICK at the time)
> insufficient for getting their work done?

PICK and ROLL appear in KPF dated 1979 (long after Moore had left).
When used by a novice, they're almost certainly a mistake; for adept
forthers they can be the lesser of two evils.

On 10/09/2021 22:28, dxforth wrote:
>
> FWIW the app I recently posted breaks down as follows:
>
> #colon defs: #inputs:
> 100 0
> 26 1
> 16 2
> 9 3
> 1 4
>
> While I have PICK and ROLL I had no cause to use them in this instance.

To complete the picture here is a count of the stack operators used:

DUP 58
DROP 27
SWAP 22
OVER 15
ROT 8
NIP 1
PICK 0
ROLL 0

2DROP 8
2DUP 3
2NIP 2
2SWAP 1
2OVER 0
2ROT 0

Stack-jugglers i.e. two or more stack operations in sequence:

ROT OVER 1
DUP ROT 1
DUP 2SWAP 1
2NIP NIP 1

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> I used it once in a Rosetta Code example because I was in a hurry, but
> I'm still not proud of that. In 4tH, it is an external word, which
> makes it quite slow as well. But given it's primary there for porting,
> it's not that important.

I needed to copy the top 3 stack elements (3DUP) to try the Tak
benchmark. I wrote something like:

: 3dup.1 ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;

I sent the benchmark to Mattias Trute and he said he had already done
this test, and sent his version. It used:

: 3dup.2 ( a b c -- a b c a b c ) 2 pick 2 pick 2 pick ;

That seemed simpler to me. Of course with locals,

: 3dup.3 { a b c } a b c a b c ;

is as simple as it gets.

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> It's easy: read "Thinking Forth". Read it carefully

I have read it, I have been wanting to look at again, but I don't
remember it saying anything about this.

> The VM of C also has a stack - but here you are responsible for
> maintaing it. The VM of C also uses RPN. Here you write it straight
> away.

The VM of C has no issues with reaching into the stack interior. That's
how automatic variables work in C. What is so terrible about doing that
in Forth?

> May be now you understand why adding these things back sounds so ludricous.

Not yet, anyway.

Paul Rubin <no.email@nospam.invalid> writes:
>I needed to copy the top 3 stack elements (3DUP) to try the Tak
>benchmark. I wrote something like:
>
> : 3dup.1 ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
>
>I sent the benchmark to Mattias Trute and he said he had already done
>this test, and sent his version. It used:
>
> : 3dup.2 ( a b c -- a b c a b c ) 2 pick 2 pick 2 pick ;
>
>That seemed simpler to me. Of course with locals,
>
> : 3dup.3 { a b c } a b c a b c ;
>
>is as simple as it gets.

On lxf all three produce the same code:

804FC0A 8B4500 mov eax , [ebp]
804FC0D 8945F4 mov [ebp-Ch] , eax
804FC10 8B4504 mov eax , [ebp+4h]
804FC13 8945F8 mov [ebp-8h] , eax
804FC16 895DFC mov [ebp-4h] , ebx
804FC19 8D6DF4 lea ebp , [ebp-Ch]
804FC1C C3 ret near

You are not going to factor this further, so the factoring
disadvantage of the return stack and the locals version does not play
a role. So use whatever you like most. On VFX 3DUP.2 produces
equally good code, the other versions are worse.

I find it funny that those who disapprove of some Forth features do
not give any concrete reasons for that. Instead, they use evocative
language, and point people to books, without pointing out any specific
place the should read. There are not many clearer ways to indicate
their lack of arguments.

- 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

On Friday, September 10, 2021 at 10:26:57 PM UTC+2, Andy Valencia wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> > I find 565 occurences of PICK in a total of 2077 Forth files. Of these,
> > 280 are for 2 PICK, far less for 3 PICK and almost none for n > 5.
> I realize that's a lot of occurrences, but when you run your eyes over
> the code, do any qualities of the surrounding code jump out at you?

A very difficult question. Maybe 20% of the usage is caused by
benchmarks and published code, something one does not really
want to rewrite from scratch.

I looked at some of the others: it would be a major effort to get rid
of the 2..4 PICK's (replacing them with convoluted stack gymnastics
is of course always possible). Although I don't believe in THIRD and
FOURTH, that may be just because there names are odd.

There appear to be many occurences of strings ( c-addr u -- ) and
doubles ( lo hi -- ). The number of objects may be less than 3,
but with strings and doubles that grows to 6 stack items.

The PICKs are almost always accompanied by locals. So 2 .. 4 PICK
is apparently preferred to locals.

When code is reused, it is with the purpose to add features and
therefore extra parameters need to be introduced. Rewriting is
obviously not wanted.

When working with others it is not productive to completely
rewrite your colleague's code just to get rid of a stack item. (I did
not find many examples of that, probably because the interface
was fixed or because locals were unavoidable anyway.)

-marcel