Hope this doesn't trigger too much of a hate fest: how does this unholy
mix of Erlang and Unix shell syntax sound as a concession to wanting
re-usable args to functions, while keeping Forth's conciseness?

Basically you could postfix a function name with /n where n is a number
of arguments, e.g.:

: sumsq/2 .... ;

would create function SUMSQ which is declared to take two args, which
would automatically be transferred from the DS to the RS (with a frame
pointer kept), and you'd access them with $1, $2, etc. At the end they
would be cleaned up similar to locals. So for sum of squares you could
write

: sumsq/2 $1 $1 * $2 $2 * + ;

Alternatively the bindings could be A,B,C, etc., or the /n syntax could
go on the colon rather than the function name:

:/2 sumsq $1 $1 * $2 $2 * + ;

That would just be a matter of having words : :/1 :/2 etc., up to a
maximum of maybe 5 or 6.

This should be pretty easy to implement, and not cost anything at
runtime unless you actually use it.

The :/2 version could also work for quotations: [:/2 .... ;]. As
before, code inside the quotation would not have to be able to access
the parent's "locals", though maybe some provision could be made for
that.

Paul Rubin <no.email@nospam.invalid> writes:
> pointer kept), and you'd access them with $1, $2, etc.

Oops, obviously $1, $2 etc. is bad since that syntax is already used for
hex constants. Maybe ^1, ^2, etc.

On Friday, August 27, 2021 at 10:11:16 AM UTC+2, Paul Rubin wrote:
> [...] a concession to wanting
> re-usable args to functions, while keeping Forth's conciseness?

This is 'only' syntax unless you mean something special with 're-usable'?
LOCAL names are already 're-usable', and if worried about being them too
specific, we can simply always call them x, y, z ... :--)

-marcel

Paul Rubin <no.email@nospam.invalid> writes:
>Basically you could postfix a function name with /n where n is a number
>of arguments, e.g.:
>
> : sumsq/2 .... ;
>
>would create function SUMSQ which is declared to take two args, which
>would automatically be transferred from the DS to the RS (with a frame
>pointer kept), and you'd access them with $1, $2, etc. At the end they
>would be cleaned up similar to locals. So for sum of squares you could
>write
>
> : sumsq/2 $1 $1 * $2 $2 * + ;

: /2 postpone 2>r ; immediate
: ^1 postpone i' ; immediate
: ^2 postpone r@ ; immediate
: sumsq /2 ^1 ^1 * ^2 ^2 * + 2rdrop ;

That's without frame pointer, so you cannot use ^1 ^2 while something
else is on the return stack, e.g., loop parameters. You also need I'
(the second return stack item), and if you also have /1, /3, etc., the
implementation of ^1 etc. becomes more complex (at least if you want
the order to be with the highest number on the top-of-stack).

>This should be pretty easy to implement, and not cost anything at
>runtime unless you actually use it.

While implementation effort may have been the original reason for not
implementing locals, the rejection of locals has become a dogma among
many who reject them. Something that smells remotely like locals will
not be acceptable to those who reject them, and the reason given will
be, as always, that it is more complex than having no locals.

We know how to implement proper locals, so the limitations of the
scheme will not win the heart of those who accept locals.

Locals don't cost either when you don't use them. They also do not
necessarily cost when you use them. lxf/ntf is pretty close to that,
but, at least for the sumsq example, not quite there yet.

: sumsq1 dup * swap dup * + ; : sumsq2 {: a b :} a a * b b * + ;
see sumsq1 see sumsq2
mov eax , ebx mov eax , [ebp]
imul eax , ebx imul eax , dword [ebp]
mov ebx , [ebp] mov ecx , ebx
imul ebx , dword [ebp] imul ecx , ebx
add ebx , eax add eax , ecx
lea ebp , [ebp+4h] mov ebx , eax
ret near lea ebp , [ebp+4h]
ret near

- 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, 27 August 2021 at 12:56:20 UTC+2, Anton Ertl wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> >Basically you could postfix a function name with /n where n is a number
> >of arguments, e.g.:
> >
> > : sumsq/2 .... ;
> >
> >would create function SUMSQ which is declared to take two args, which
> >would automatically be transferred from the DS to the RS (with a frame
> >pointer kept), and you'd access them with $1, $2, etc. At the end they
> >would be cleaned up similar to locals. So for sum of squares you could
> >write
> >
> > : sumsq/2 $1 $1 * $2 $2 * + ;
> : /2 postpone 2>r ; immediate
> : ^1 postpone i' ; immediate
> : ^2 postpone r@ ; immediate
> : sumsq /2 ^1 ^1 * ^2 ^2 * + 2rdrop ;
>
> That's without frame pointer, so you cannot use ^1 ^2 while something
> else is on the return stack, e.g., loop parameters. You also need I'
> (the second return stack item), and if you also have /1, /3, etc., the
> implementation of ^1 etc. becomes more complex (at least if you want
> the order to be with the highest number on the top-of-stack).
> >This should be pretty easy to implement, and not cost anything at
> >runtime unless you actually use it.
> While implementation effort may have been the original reason for not
> implementing locals, the rejection of locals has become a dogma among
> many who reject them. Something that smells remotely like locals will
> not be acceptable to those who reject them, and the reason given will
> be, as always, that it is more complex than having no locals.
>
> We know how to implement proper locals, so the limitations of the
> scheme will not win the heart of those who accept locals.
>
> Locals don't cost either when you don't use them. They also do not
> necessarily cost when you use them. lxf/ntf is pretty close to that,
> but, at least for the sumsq example, not quite there yet.
>
> : sumsq1 dup * swap dup * + ; : sumsq2 {: a b :} a a * b b * + ;
> see sumsq1 see sumsq2
> mov eax , ebx mov eax , [ebp]
> imul eax , ebx imul eax , dword [ebp]
> mov ebx , [ebp] mov ecx , ebx
> imul ebx , dword [ebp] imul ecx , ebx
> add ebx , eax add eax , ecx
> lea ebp , [ebp+4h] mov ebx , eax
> ret near lea ebp , [ebp+4h]
> ret near

Better to swap a and b to be more comparable like

: sumsq1 dup * swap dup * + ;
see sumsq1
86926C8 80506BC 18 88C8000 5 normal SUMSQ1

80506BC 8BC3 mov eax , ebx
80506BE 0FAFC3 imul eax , ebx
80506C1 8B5D00 mov ebx , [ebp]
80506C4 0FAF5D00 imul ebx , dword [ebp]
80506C8 01C3 add ebx , eax
80506CA 8D6D04 lea ebp , [ebp+4h]
80506CD C3 ret near
ok

: sumsq3 {: b a :} a a * b b * + ; ok
see sumsq3
86926F8 80506E2 20 88C8000 5 normal SUMSQ3

80506E2 8BC3 mov eax , ebx
80506E4 0FAFC3 imul eax , ebx
80506E7 8B4D00 mov ecx , [ebp]
80506EA 0FAF4D00 imul ecx , dword [ebp]
80506EE 01C8 add eax , ecx
80506F0 8BD8 mov ebx , eax
80506F2 8D6D04 lea ebp , [ebp+4h]
80506F5 C3 ret near
ok

Here we can see that the difference come from the local version using
an extra register. It does this as the scope of the locals are till the end of
the definition. in the stack version ebx can be reused as it is not needed
after the result is placed in eax. In the local version it needs to be kept
until the end. mov ebx, eax is generated by ; to get the stack to a known state.

Personally I do not use locals in my FORTH programming. They are there in
my systems so I can import others code.

I do have anther feature that I use. Local buffers. used like this example
from a socket implementation

0 \ sockaddr
2 chars +field family
2 chars +field port
4 chars +field addr
8 chars +field zero
constant sockaddr

: connect-socket ( addr port family sid -- ior ) \ connect
sockaddr lbuffer: sock
sock sockaddr erase
swap sock family w! \ store AF_INET
swap htons sock port w! \ store port
swap sock addr ! \ store addr
sockaddr sock rot (connect) 0<> -273 and ; \ connect

lbuffer: will take a known lenght and allocate that many bytes
on the returnstack. from there on it can be accessed with the usual
Forth words (w! stors a word, 2 bytes)

BR
Peter

> - 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, August 27, 2021 at 3:11:16 AM UTC-5, Paul Rubin wrote:
> Hope this doesn't trigger too much of a hate fest: how does this unholy
> mix of Erlang and Unix shell syntax sound as a concession to wanting
> re-usable args to functions, while keeping Forth's conciseness?

Doesn't bother me.
[r] SET Parameter lists

SET ( a -- )
Save old $P (on rack) and store address a in $P.
After resile, restore $P.
$0..$9 parameters accessed as values
&0..&9 parameters accessed as variables
$X0..$X9 parameters accessed as executable words

Very flexible, $P can point to memory or either stack. Works
very well with BUILD DOES :

: bar: build does SET
&2 \ address of remaining parm cells
$1 \ number of parm cells
0 ?do dup
$X0 \ print parm value
CELL+ \ bump parm address
loop
drop
;

bar: foo ' ? ,
3 , 10 , 20 , 30 ,

: ?% @ 0 <# asc % hold #S #> type space ;
bar: koo ' ?% ,
4 , 90 , 80 , 70 , 60 ,

cr foo \ => 10 20 30
cr koo \ => 90% 80% 70% 60%

--.
--
me

S Jack <sdwjack69@gmail.com> writes:
> $0..$9 parameters accessed as values
> &0..&9 parameters accessed as variables
> $X0..$X9 parameters accessed as executable words

It's interesting that you have the $X parameters. Bernd Paysan added
the executable-flavoured locals (using the XT: definer) when implementing
Knuth's man-or-boy-test. In the meantime we have found other uses, so
it turned out to be generally useful.

Gforth has had variable-flavoured locals since it has had locals, but
I have rarely used it.

Here is a contrived example:

: foo {: val w^ var xt: x :} val . var @ x ;
1 2 ' . foo \ prints "1 2"

> Very flexible, $P can point to memory or either stack. Works
> very well with BUILD DOES :
>
> : bar: build does SET
> &2 \ address of remaining parm cells
> $1 \ number of parm cells
> 0 ?do dup
> $X0 \ print parm value
> CELL+ \ bump parm address
> loop
> drop
> ;
>
> bar: foo ' ? ,
> 3 , 10 , 20 , 30 ,

That's an interesting use. Dealing with multiple data passed from
create-time to does>-time has always been cumbersome in Forth. I have
suggested CONST-DOES> for that a long time ago, but it did not catch
on. More recently Gforth's closures provide a way to do it (and it's
available); they do not provide particular support for the stuff you
do here (with variable-sized data accessed in a loop), though.

- 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, August 27, 2021 at 1:11:16 AM UTC-7, Paul Rubin wrote:
> As
> before, code inside the quotation would not have to be able to access
> the parent's "locals", though maybe some provision could be made for
> that.

Really??? Pray tell, what provision might that be?
Are you planning on inventing rquotations?

On 27/08/2021 20:11, Anton Ertl wrote:
> ...
> Locals don't cost either when you don't use them. They also do not
> necessarily cost when you use them. lxf/ntf is pretty close to that,
> but, at least for the sumsq example, not quite there yet.

Just because lxf/ntf can reduce locals to the point where they're
indistinguishable from stack operations doesn't mean one is justified
using them. If locals are as good as stack operations, why bother
with forth at all.

I recently reviewed some forth code which demonstrated all the traits of
a beginner - which I suspect even lxf/ntf would be unable to optimize away.
Should the beginner simply give up and use locals instead? Sorry, but
I completely reject the sentiment it's ok to use locals in forth. Forth
encourages one to think; to break up problems into sensible factors.
And that's a good thing. The cost of locals is that you don't think.

dxforth <dxforth@gmail.com> writes:
> If locals are as good as stack operations, why bother with forth at all.

Isn't it the other way around? If locals are as good as stack
operations, there's less reason to use something like C.

> I completely reject the sentiment it's ok to use locals in forth. Forth
> encourages one to think; to break up problems into sensible factors.
> And that's a good thing. The cost of locals is that you don't think.

If stopping to think is gaining me something in terms of code clarity or
organization, that's great. But if it's just slowing me down and
introducing mistakes in my code, I'm better off coding by instinct, and
locals do seem to help with that. See also: "Thinking Fast and Slow" by
Daniel Kahneman.

On 29/08/2021 15:29, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> If locals are as good as stack operations, why bother with forth at all.
>
> Isn't it the other way around? If locals are as good as stack
> operations, there's less reason to use something like C.

The world has given its verdict on that one.

>
>> I completely reject the sentiment it's ok to use locals in forth. Forth
>> encourages one to think; to break up problems into sensible factors.
>> And that's a good thing. The cost of locals is that you don't think.
>
> If stopping to think is gaining me something in terms of code clarity or
> organization, that's great. But if it's just slowing me down and
> introducing mistakes in my code, I'm better off coding by instinct, and
> locals do seem to help with that. See also: "Thinking Fast and Slow" by
> Daniel Kahneman.
>

One could also use the analogy of commuter and race car drivers.
I don't feel forth is holding me back - on the contrary, I find it
exhilarating. Which wouldn't be the case were I making errors.

dxforth <dxforth@gmail.com> writes:
> I don't feel forth is holding me back - on the contrary, I find it
> exhilarating. Which wouldn't be the case were I making errors.

Interesting. I don't feel like Forth exactly holds me back, but I do
feel like it slows me down. Maybe that is a matter of developing
reflexes for it. But I've looked at Forth code written by experts and
it is often full of confusing stack juggling, just as code written by
beginners notoriously is.

On Sunday, August 29, 2021 at 8:53:16 AM UTC+2, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> > I don't feel forth is holding me back - on the contrary, I find it
> > exhilarating. Which wouldn't be the case were I making errors.
> Interesting. I don't feel like Forth exactly holds me back, but I do
> feel like it slows me down. Maybe that is a matter of developing
> reflexes for it.

Forth may drag one down a little when trying to do the same things
*in the same way as profane programmers are doing it.* However,
in case one is a relative expert in some field, non-conventional
approaches to standard problems become apparent. In Forth it is
easy to implement and test such ideas. At this level it is natural
to aim for the simplest and most direct way to do things ('Elegance
is for tailors!"). Using pointers to structures full of pointers to
opaque other structures is not likely to happen. Even
introducing a local to rotate 3 variables might be considered a
nuisance / unnecessary / unbearable distraction.

> But I've looked at Forth code written by experts and
> it is often full of confusing stack juggling, just as code
> written by beginners notoriously is.

The keyword is 'confusing.' To whom? E.g., one of the things one
can't normally do with a local is taking its address (and if it's
possible we may have to allocate/deallocate). There are also
issues with run-time code generation and compile/interpret time.

-marcel

On 29/08/2021 16:53, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> I don't feel forth is holding me back - on the contrary, I find it
>> exhilarating. Which wouldn't be the case were I making errors.
>
> Interesting. I don't feel like Forth exactly holds me back, but I do
> feel like it slows me down. Maybe that is a matter of developing
> reflexes for it. But I've looked at Forth code written by experts and
> it is often full of confusing stack juggling, just as code written by
> beginners notoriously is.
>

It's news to me experts write code that qualifies as stack juggling.
Perhaps one is expecting more from forth than it was designed to give.
With respect, wouldn't it be better then to find a language which
satisfies one's needs, than butcher one which doesn't?

Marcel Hendrix <mhx@iae.nl> writes:
> Forth may drag one down a little when trying to do the same things
> *in the same way as profane programmers are doing it.*

Of course, it's not an indictment to admit that a language quite
recognizable to its 1970's users has fallen behind some more modern
programming languages when measured on metrics like how it fails
in the face of programming errors, learning curve, availability of
modern ("batteries included") facilities, ....

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

dxforth <dxforth@gmail.com> writes:
> With respect, wouldn't it be better then to find a language which
> satisfies one's needs, than butcher one which doesn't?

I don't see butchering going on? Forth's design was closely entangled
with its early implementation methods, which in turn was dictated by the
hardware of the day. If the hardware changes, the trade-offs become
different. As another example, compile-to-flash is important for
resident MCU interpreters. Does that result in butchering Forth? I
don't think so. A few things have to be tweaked, but tweaking stuff as
required fits Forth perfectly well.

Marcel Hendrix <mhx@iae.nl> writes:
>Forth may drag one down a little when trying to do the same things
>*in the same way as profane programmers are doing it.*

I don't think that the religious terminology of Wil Baden is helpful.
And the emphasis of a dichotomy between Forth and other languages has
led to people rejecting (the use of) features just because other
languages have them. Features should be assessed by how useful the
are (or how much avoiding them costs) and how much they cost (in
implementation, but maybe also in use).

>However,
>in case one is a relative expert in some field, non-conventional
>approaches to standard problems become apparent. In Forth it is
>easy to implement and test such ideas. At this level it is natural
>to aim for the simplest and most direct way to do things ('Elegance
>is for tailors!").

The simplest and most direct way is elegant in my eyes.

However, the most direct way is often not very flexible when you want
to later extend the program. This is known in the wider programming
world as technical debt. Charles Moore advocated rewriting the
program in that case, the more conventional answer is to design the
program for extensibility. But even Charles Moore included general,
extensible mechanisms, foremost of all the dictionary, so I think it's
a good idea to keep both approaches in mind, and choose as
appropriate.

>Using pointers to structures full of pointers to
>opaque other structures is not likely to happen.

Wordlists containing threaded-code words?

But yes, such structures are more problematic in Forth than in most
other languages, because typical Forth debugging approaches work badly
for such structures, eliminating an advantage of Forth. So a Forth
programmer will tend to avoid such structures.

>Even
>introducing a local to rotate 3 variables might be considered a
>nuisance / unnecessary / unbearable distraction.

Do you mean

a @ b @ c @ rot c ! b ! a !

Why would one introduce a local to do that?

>> But I've looked at Forth code written by experts and
>> it is often full of confusing stack juggling, just as code
>> written by beginners notoriously is.
>
>The keyword is 'confusing.' To whom?

To Paul Rubin, obviously. Let's take a look at
<https://github.com/ForthHub/cmFORTH/blob/combined/cmforth.fth>:

( TRIM relocates the vocabulary link and erases the smudge bit. )
: TRIM ( a a - a) DUP PUSH dA @ - SWAP ! POP
DUP 1 + DUP @ DFFF AND OVER !
DUP @ 200 \ F AND + DUP @ FF7F AND SWAP ! ;

(PUSH is >R and POP is R>)

Do you find this code easy to understand? Admittedly, most of the
code in cmForth is easier to understand. It's full of magic numbers,
so it would be hard to change it, though.

>E.g., one of the things one
>can't normally do with a local is taking its address

I don't think that Paul Rubin finds that confusing. This feature
makes locals easier to understand for both programmers and compilers.

>There are also
>issues with run-time code generation

Have you missed better support for locals in run-time-generated code?

I don't think Paul Rubin meant this.

> and compile/interpret time.

You mean copy-pasting code with locals into the interpreter?

- 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 8/29/21 1:23 AM, dxforth wrote:

> If locals are as good as stack operations, why bother
> with forth at all.

It's not an all-or-nothing issue. Using an occasional local does not
require or mean that one is using locals exclusively in place of stack
manipulation or in every definition.

If one uses the return stack as a place to temporarily store things is
that conceptually any different from using a local or two?

I don't see the "interferes with factoring" canard.

This always reminds me of the old blocks vs text files debate.

-Doug

On 29/08/2021 23:49, Andy Valencia wrote:
> ...
> Of course, it's not an indictment to admit that a language quite
> recognizable to its 1970's users has fallen behind some more modern
> programming languages when measured on metrics like how it fails
> in the face of programming errors, learning curve, availability of
> modern ("batteries included") facilities, ....

More specialist languages designed to do one thing and one thing
only, whose programmers become redundant when its time is up?
I had a good run in electronics at a time when it was actually
interesting before the 'black box' era. Looks like programming
is going the same way.

dxforth <dxforth@gmail.com> writes:
> More specialist languages designed to do one thing and one thing
> only, whose programmers become redundant when its time is up?

I don't feel like that and I'm an old software fart by now. Languages
keep evolving but mostly in the same general directions, so it's enough
to identify those directions and follow them.

On 30/08/2021 12:35, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> More specialist languages designed to do one thing and one thing
>> only, whose programmers become redundant when its time is up?
>
> I don't feel like that and I'm an old software fart by now. Languages
> keep evolving but mostly in the same general directions, so it's enough
> to identify those directions and follow them.
>

Following is right because the fundamentals of programming haven't
changed.

On Friday, August 27, 2021 at 10:12:58 AM UTC+2, Paul Rubin wrote:
You actually achieved to make the proposal even uglier than it already was - and when reading the first version I carelessly assumed that such a feat was impossible.

Hans Bezemer

> Paul Rubin <no.e...@nospam.invalid> writes:
> > pointer kept), and you'd access them with $1, $2, etc.
> Oops, obviously $1, $2 etc. is bad since that syntax is already used for
> hex constants. Maybe ^1, ^2, etc.

Doug Hoffman <dhoffman888@gmail.com> writes:
> This always reminds me of the old blocks vs text files debate.

I wasn't around for that but I think blocks have mostly faded away by
now. Did they really have staunch proponents? Was there a similar
debate over 3+length vs. storing the whole name in the dictionary?

I've lately been doing stuff with an 8-bit processor (AVR). I've never
used a tethered Forth before, but find myself wanting to try one. That
means putting the compiler on a remote machine, that has enough memory
to handle things like locals without much trouble. I wonder if the
absence of locals in early Forth was something like the 3+length
dictionary, i.e. an artifact of memory being scarce in those days.

dxforth <dxforth@gmail.com> writes:
> Following is right because the fundamentals of programming haven't
> changed.

The fundamentals haven't changed in the same sense that fundamental
physics hasn't changed. The stuff that programmers do all day has
really changed a lot. There are plenty of very good programmers who
code in Python or Javascript for a living, and have never used a
language with pointers or without garbage collection. They still get
their stuff done.

On 3/09/2021 08:15, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Following is right because the fundamentals of programming haven't
>> changed.
>
> The fundamentals haven't changed in the same sense that fundamental
> physics hasn't changed. The stuff that programmers do all day has
> really changed a lot. There are plenty of very good programmers who
> code in Python or Javascript for a living, and have never used a
> language with pointers or without garbage collection. They still get
> their stuff done.
>

Yes, but you know when you're being fed pap.