dxforth <dxforth@gmail.com> writes:
> How many times will you code Z* ? FWIW FSLIB already has it.

Z* is a simple example. The issue comes up with some regularity.

> FP locals isn't supported by any standard.

Hmm, I didn't realize that, I mostly use gforth. It is unfortunate.

> Some folks have suggested there should be a F>R R>F which would allow
> recursive f/p variables.

That could help, but might as well support FP locals directly.

> IIRC Wil Baden had a scheme that used memory at HERE as f/p locals.

That sounds pretty messy. Was it hooked into (LOCAL) somehow? What
happens if your function ALLOTs something after making the locals? Does
the space for the locals not get reclaimed?

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

The examples I gave were real. I don't claim anything "requires" locals
in the sense that finding another way is impossible. But finding and
implementing another way obviously imposes costs, and I don't currently
see an offsetting benefit. Before wanting to find the other way, I'd
first want to know what I'd gain from finding it. If I have a method
that works, why search for ways to make more pain for myself instead
of just getting on with it?

> In Forth, locals are all about style... 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.

The return stack being smaller depends on the implementation ofc. Some
implementations (gforth) use a separate locals stack. An optimizing
compiler can in some cases put the locals in registers which is cheaper
than putting them on any stack. They can also be in the heap, which
unlike even the data stack, can have non-contiguous locals areas without
much hassle.

Admittedly I've been using gforth on machines with gigabytes of memory
but I don't see a big issue even on small MCU's. Of course you have to
maintain some awareness of stack usage from locals, but you have to
maintain that awareness for everything else too.

On 30/10/2022 8:27 am, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> How many times will you code Z* ? FWIW FSLIB already has it.
>
> Z* is a simple example. The issue comes up with some regularity.
>
>> FP locals isn't supported by any standard.
>
> Hmm, I didn't realize that, I mostly use gforth. It is unfortunate.

Unfortunate has been the mixed messaging. Moore couldn't be more explicit
locals had no place in Forth. Still, better one can find that out for
oneself. Locals in Forth can be likened to chocolate. Irresistible to
the sweet-toothed.

dxforth <dxforth@gmail.com> writes:
> Unfortunate has been the mixed messaging. Moore couldn't be more explicit
> locals had no place in Forth.

Moore, I've heard of that guy. Isn't he the one who invented PICK and
ROLL because his Forth didn't have locals? Once you've turned the stack
into an indexible array, you might as well be able to give names to the
slots.

On 30/10/2022 4:37 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Unfortunate has been the mixed messaging. Moore couldn't be more explicit
>> locals had no place in Forth.
>
> Moore, I've heard of that guy. Isn't he the one who invented PICK and
> ROLL because his Forth didn't have locals? Once you've turned the stack
> into an indexible array, you might as well be able to give names to the
> slots.

It appears he found them superfluous:

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

"It is necessary to have variables."

http://www.ultratechnology.com/1xforth.htm

On Sunday, October 30, 2022 at 7:16:24 AM UTC+1, dxforth wrote:
[..]
> "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."
>
> "It is necessary to have variables."

That is simply describing what 'a machine' has available. The final statement
is a logical conclusion.

> http://www.ultratechnology.com/1xforth.htm

Somebody should restore these tapes. My hunch is that there will
be surprising nuance.

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>> http://www.ultratechnology.com/1xforth.htm
> Somebody should restore these tapes. My hunch is that there will
> be surprising nuance.

I'm sure I watched that video on youtube years ago. It looks like it
has been re-uploaded more recently, by Gavino, a surprising and nice
contribution.

https://www.youtube.com/watch?v=pSnNy7IpVMg

On 30/10/2022 6:44 pm, Paul Rubin wrote:
> Marcel Hendrix <mhx@iae.nl> writes:
>>> http://www.ultratechnology.com/1xforth.htm
>> Somebody should restore these tapes. My hunch is that there will
>> be surprising nuance.
>
> I'm sure I watched that video on youtube years ago. It looks like it
> has been re-uploaded more recently, by Gavino, a surprising and nice
> contribution.
>
> https://www.youtube.com/watch?v=pSnNy7IpVMg

No - the unexpurgated version ...

https://youtu.be/ZYlOV7K-xOU?t=49

On Sunday, October 30, 2022 at 10:20:33 AM UTC+1, dxforth wrote:
[..]
> https://youtu.be/ZYlOV7K-xOU?t=49

I admit it is dead-on with respect to the underlying sentiments
in this discussion :--)

-marcel

On Sunday, October 30, 2022 at 6:37:46 AM UTC+1, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> Moore, I've heard of that guy. Isn't he the one who invented PICK and
> ROLL because his Forth didn't have locals? Once you've turned the stack
> into an indexible array, you might as well be able to give names to the
> slots.
Well, in his 1993 interview he was quoted to have said: "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". (http://www.ultratechnology.com/moore4th.htm)

It's also explicitly listed in "Thinking Forth" - although that one was not written
by Moore. It's just the penultimate work on Forth philosophy..

So it must have been another Moore, I guess.. There are so many Moores writing
Forth..

Hans Bezemer

On Sunday, October 30, 2022 at 1:16:24 AM UTC-5, dxforth wrote:
>
> http://www.ultratechnology.com/1xforth.htm

ColorForth and Moore's vision are intriguing; however, I'm out of time
for transforming into a "moti" and beginning new adventure. If I were
younger, I would eagerly start with ColorForth and begin some endeavor of
UXN like "Past proofing".
--
me

On Sunday, October 30, 2022 at 6:37:46 AM UTC+1, Paul Rubin wrote:
> Moore, I've heard of that guy. Isn't he the one who invented PICK and
> ROLL because his Forth didn't have locals? Once you've turned the stack
> into an indexible array, you might as well be able to give names to the
> slots.

BTW - PICK and ROLL do not make a stack into an indexable array. Even
when using dynamic memory (unless you reallocate it by a resize) I can
be pretty much assured that every time I get an indexed element, it points
to the very same memory address. However, if I do a "5 PICK", the next time
I do a "5 PICK" it will get me the contents of a very different address. If I
want the same element I have to issue "6 PICK".

ROLL - on the other hand - shifts the contents. You may get the same address,
but completely different content. The ontology of ROLL is more difficult, though
- I agree. It's more a question of semantics here.

So, PICK does NOT turn a stack into an "indexable array" - which makes the
next argument "being able to give names to the slots" completely untenable.

Hans Bezemer

On 29/10/2022 09:05, Marcel Hendrix wrote:
> 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
>

So your $+ prepends a string to another into some buffer. See DX alternative

--
Gerry

On 29/10/2022 16:57, dxforth wrote:
> 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
>

Yes that's much simpler even with the inelegance of having to provide 2
cells on the stack for #> to drop.

Seeing that solution is ironic and humbling. I knew that <# ... #> and
indeed have posted something about that on c.l.f in the past. I've no
explanation about why I didn't think of that in my response to Hans
Bezemer, I suppose his solution pointed me into using +PLACE and I
didn't think beyond that.

--
Gerry

On 29/10/2022 14:14, Hans Bezemer wrote:
> 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.

Sorry about that, I wasn't aware that 4th used zero terminated strings
and just assumed that standard counted strings were used. So presumably
your version of COUNT does it by actually counting the characters.
>
> That your code works is because the first line effectively terminates
> the target string - and the abstraction of +PLACE does the heavy lifting.
>

It's fortuitous that a 0 byte means an empty string for both ways of
representing a string.

> But I forgive you ;-)
Thank you

--
Gerry

On 30/10/2022 11:56 pm, S Jack wrote:
> On Sunday, October 30, 2022 at 1:16:24 AM UTC-5, dxforth wrote:
>>
>> http://www.ultratechnology.com/1xforth.htm
>
> ColorForth and Moore's vision are intriguing; however, I'm out of time
> for transforming into a "moti" and beginning new adventure. If I were
> younger, I would eagerly start with ColorForth and begin some endeavor of
> UXN like "Past proofing".

Chasing visions is likely to bring one back to where one started.

https://en.wikisource.org/wiki/Time_and_the_Gods#The_Sorrow_of_Search

dxforth <dxforth@gmail.com> writes:
> It appears he [Moore] found them superfluous:
> "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."

PICK and ROLL have to have come from somewhere: if it wasn't Moore, then
who? And what about ROT, -ROT, >R, and R>?

I get that Moore used VARIABLEs for everything that I'd use locals for.
He also used CODE when Forth got in the way too much.

Back in the 1970s, computers were limited, programs were necessarily
small, and Moore espoused rewriting programs from the ground up instead
of maintaining them. The main problem facing programmers was how to
make their program implement behaviour X, for whatever X happened to be
that day. They'd put a lot of effort into coding and testing X, and
then they were done.

Today, the main problem facing programmers is ensuring the absence of
behaviours rather than their presence. Writing code is way easier than
it used to be, because tools are better and computers are faster. But
maintaining is harder since programs are bigger and have more people
hacking at them. If you use a VARIABLE to save a temporary value used
by a word, then anyone modifying that word, when they see that variable,
now has to check that no other word uses the variable and depends on it
for communication. Or worse, communicates through the memory cell
occupied by that variable but through some sneaky alias. VALUE avoids
aliasing (no idea whether Moore used them), but locals make both issues
go away.

Finally, while I can't doubt Moore's genius, I've never understood the
vision that says the pure stack VM fits every programming problem.
Register allocation and spilling is one of the messier parts of
traditional compilers even when there are plenty of registers that don't
have weird special purposes. In Forth, there are only 3 or so
"registers" (T, N, and R), and each is special. Why be so vehement that
a human rather than a machine should be juggling them? I can understand
taht locals (if supported) complicate the traditional threaded Forth
interpreter, but I don't know how much Moore valued that. I know he did
like stack hardware (his many Forth chips) but that came later.

So the pure "stack plus VARIABLEs" seems "not even wrong" to me. I
don't understand the motivation behind it well enough to disagree per
se. And I've never seen an explanation that made sense. They have all
seemed like grasping at straws.

On 31/10/2022 2:09 am, Gerry Jackson wrote:
> On 29/10/2022 16:57, dxforth wrote:
>> 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
>>
>
> Yes that's much simpler even with the inelegance of having to provide 2 cells on the stack for #> to drop.
>
> Seeing that solution is ironic and humbling. I knew that <# ... #> and indeed have posted something about that on c.l.f in the past. I've no explanation about why I didn't think of that in my response to Hans Bezemer, I suppose his solution pointed me into using +PLACE and I didn't think beyond that.

I had considered an iterative solution similar to the original:

\ +string ( a1 u1 a2 u2 -- a2 u3 )

: concat ( a1 u1 ... an un n dest -- dest len )
0 0 begin 2>r over while swap 1- swap 2swap repeat
swap begin 2r> over while 2swap +string repeat 2drop ;

Not sure the problem is particularly real. Akin to painting oneself into
a corner then having to find a way out. There has to be a better way...

On 31/10/2022 10:48 am, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> It appears he [Moore] found them superfluous:
>> "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."
>
> PICK and ROLL have to have come from somewhere: if it wasn't Moore, then
> who? And what about ROT, -ROT, >R, and R>?
>
> I get that Moore used VARIABLEs for everything that I'd use locals for.

You use locals because it's easier and more-or-less idiot-proof. Moore
claims it leads to inefficiency. Can't speak for his use but if I have
to use a variable as a temp, I do so sparingly - unlike locals which are
largely about 'readability' and therefore quantity.

> He also used CODE when Forth got in the way too much.

Don't know but when it comes to apps there's has to be a good enough
reason before I'll use CODE.

> Today, the main problem facing programmers is ensuring the absence of
> behaviours rather than their presence. Writing code is way easier than
> it used to be, because tools are better and computers are faster. But
> maintaining is harder since programs are bigger and have more people
> hacking at them. If you use a VARIABLE to save a temporary value used
> by a word, then anyone modifying that word, when they see that variable,
> now has to check that no other word uses the variable and depends on it
> for communication. Or worse, communicates through the memory cell
> occupied by that variable but through some sneaky alias. VALUE avoids
> aliasing (no idea whether Moore used them), but locals make both issues
> go away.

I think you overstate such use of variables, but how are they a problem
when defined local to the routine which uses it?

>
> Finally, while I can't doubt Moore's genius, I've never understood the
> vision that says the pure stack VM fits every programming problem.

Saving the world is tough - even for the newer programming systems you
talk about. For me, it's enough that I've been able to create a tool
I'm both comfortable using and is challenging at the same time.

dxforth <dxforth@gmail.com> writes:
> You use locals because it's easier and more-or-less idiot-proof. Moore
> claims it leads to inefficiency.

Yes, idiot proofing is always a good goal when programming ;). The
inefficiency depends on the implementation, I'd expect. It may also be
that code execution profiles have changed since Moore's heyday. DJB
made that claim in an article called "Demise Of The Optimizing Compiler"
or some such. Basically the execution time of programs nowadays is
concentrated almost entirely in a few hot spots. Those spots may have
to be tuned for efficiency, but the rest of the program's efficiency
almost doesn't matter. It was different in the 1970s, where efficiency
mattered everywhere in the program.

> if I have to use a variable as a temp, I do so sparingly - unlike
> locals which are largely about 'readability' and therefore quantity.

Not sure what you mean about quantity, but I look at the gforth manual's
locals version of MAX compared with a traditional one (both untested):

: max1 ( a b -- max ) 2dup > if drop else nip then ;
: max2 { a b -- max } a b > if a else b then ;

the locals version has less source code and (if compiled) maybe less
object code as well.

Similarly you recently posted elsewhere (158 source chars):

: concat ( a1 u1 ... an un n dest -- dest len )
0 0 begin 2>r over while swap 1- swap 2swap repeat
swap begin 2r> over while 2swap +string repeat 2drop ;

A locals version (untested) is 165 chars mostly due to extra whitespace
that could be squished out:

: concat2 ( a1 u1 ... an un n dest -- dest len )
{ n dest } 0 { len }
n 0 ?do
{ a u } a u dest len +string
u len + to len
loop
dest len ;

I can't begin to understand the stack juggling version so can't be sure
the two do the same thing. I also don't see how to implement 2SWAP with
just DUP, DROP, OVER. I guess it could be done with variables.

> I think you overstate such use of variables, but how are they a problem
> when defined local to the routine which uses it?

How do you do that? Variables are always globals, I thought. Another
issue with them that I forgot to mention is non-reentrancy. Like if you
implement 2SWAP with variables and an interrupt handler uses it while
another call to 2SWAP is in progress, you get a Heisenbug. Oops.

> Saving the world is tough - even for the newer programming systems you
> talk about. For me, it's enough that I've been able to create a tool
> I'm both comfortable using and is challenging at the same time.

I like my tools to be comfortable and powerful. Challenge should come
from using them on bigger and tougher problems, not from making even
easy problems a pain to solve.

On Sunday, October 30, 2022 at 10:05:16 PM UTC-4, Paul Rubin wrote:

> I also don't see how to implement 2SWAP with
> just DUP, DROP, OVER.

Use the return stack as a "local variable holder"
and use ROT and SWAP.

: 2swap ( x1 x2 x3 x4 -- x3 x4 x1 x2 )
>r rot rot r> swap rot swap ;

Truthfully, I don't see much difference between conventional locals
and using the return stack for same. With the latter you don't get names
though it is likely more efficient. But IMO is just as "impure" as locals.
Locals are much easier to use/debug/maintain-changes. If you are
not resource limited and the locals version is fast enough then I
leave it at that.

-Doug

Doug Hoffman <dhoffman888@gmail.com> writes:
>> I also don't see how to implement 2SWAP with just DUP, DROP, OVER.
> Use the return stack as a "local variable holder"
> and use ROT and SWAP.

I'm doing by the quote from Chuck Moore about DUP, DROP, and OVER (and
maybe SWAP) being the only legit stack primitives, so no ROT. He does
use the return stack in his own code though.

> Truthfully, I don't see much difference between conventional locals
> and using the return stack for same.

There is no RPICK in standard Forth, so you can't get at the internal
slots. Moore even frowns on regular PICK. Also, you have to be able to
pop the locals if the word exits through an exception. (LOCAL) had to
be added to the standard to allow that, since the VM has to handle the
unwinding in that situation.

On 31/10/2022 1:04 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>
>> if I have to use a variable as a temp, I do so sparingly - unlike
>> locals which are largely about 'readability' and therefore quantity.
>
> Not sure what you mean about quantity, but I look at the gforth manual's
> locals version of MAX compared with a traditional one (both untested):
>
> : max1 ( a b -- max ) 2dup > if drop else nip then ;
> : max2 { a b -- max } a b > if a else b then ;
>
> the locals version has less source code and (if compiled) maybe less
> object code as well.

I'd have written:

: max1 ( a b -- max ) 2dup < if swap then drop ;

Compare them under VFX and see what you get.

> Similarly you recently posted elsewhere (158 source chars):
>
> : concat ( a1 u1 ... an un n dest -- dest len )
> 0 0 begin 2>r over while swap 1- swap 2swap repeat
> swap begin 2r> over while 2swap +string repeat 2drop ;
>
> A locals version (untested) is 165 chars mostly due to extra whitespace
> that could be squished out:
>
> : concat2 ( a1 u1 ... an un n dest -- dest len )
> { n dest } 0 { len }
> n 0 ?do
> { a u } a u dest len +string
> u len + to len
> loop
> dest len ;
>
> I can't begin to understand the stack juggling version so can't be sure
> the two do the same thing.

Ditto for me for the locals version. Perhaps it's a matter of what one
is used to? If one's goal is to jump between languages using more or
less the same code, then maybe you'll want to use locals in Forth.
Personally I don't and think it a terrible idea.

>> I think you overstate such use of variables, but how are they a problem
>> when defined local to the routine which uses it?
>
> How do you do that? Variables are always globals, I thought.

Give an example how it's a problem.

> Another
> issue with them that I forgot to mention is non-reentrancy. Like if you
> implement 2SWAP with variables and an interrupt handler uses it while
> another call to 2SWAP is in progress, you get a Heisenbug. Oops.

You could make it a USER variable :)

On Monday, October 31, 2022 at 3:44:03 AM UTC+1, Doug Hoffman wrote:
> On Sunday, October 30, 2022 at 10:05:16 PM UTC-4, Paul Rubin wrote:
>
> > I also don't see how to implement 2SWAP with
> > just DUP, DROP, OVER.
> Use the return stack as a "local variable holder"
> and use ROT and SWAP.
>
> : 2swap ( x1 x2 x3 x4 -- x3 x4 x1 x2 )
> >r rot rot r> swap rot swap ;
Really?! Even my computer can do better!

$ pp4th -x stackopt.4th abcd cdab
- Trying a 1 word solution..
No solutions.
- Trying a 2 word solution..
No solutions.
- Trying a 3 word solution..
No solutions.
- Trying a 4 word solution..
rot >r rot r>

Hans Bezemer

On Monday, October 31, 2022 at 3:05:16 AM UTC+1, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> Yes, idiot proofing is always a good goal when programming ;).
According to both Moore and Dijkstra, idiots shouldn't be programming.

Hans Bezemer

In article <tjn8al$1ssh$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>On 31/10/2022 10:48 am, Paul Rubin wrote:
>> dxforth <dxforth@gmail.com> writes:
>>> It appears he [Moore] found them superfluous:
>>> "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."
>>
>> PICK and ROLL have to have come from somewhere: if it wasn't Moore, then
>> who? And what about ROT, -ROT, >R, and R>?
>>
>> I get that Moore used VARIABLEs for everything that I'd use locals for.
>
>You use locals because it's easier and more-or-less idiot-proof. Moore
>claims it leads to inefficiency. Can't speak for his use but if I have
>to use a variable as a temp, I do so sparingly - unlike locals which are
>largely about 'readability' and therefore quantity.

locals is not enough, you need dlocals,flocals
You are actually brains washed by c.
"
#include whatever

int gcd( int a, int b)
{ float hesp;
double x;
long int x ;
hesp inteact(a, x);
return items(a, hesp);
} "
You can have this type behaviour. with

VOCABULARY gcdlist ALSO gcdlist

int a int b
float hesp
double x
long_int x
: gcd
b ! a !
a @ x 2@ hesp F@ inteact hesp F!
a @ ,hesp F@ items
;

previous

It is good that you are not looking at Pascal, then
we would have local definitions adding to the
abominations of the local type zoo (LOCAL FLOCAL DLOCAL DFLOCAL ..)

In the above picture we could easily add after
long_int x
the line
: inteact do this do that mysterious F@ ;

proving the superiority of classical approach of forth.

I can't stand the idea that so,eome duplicates VARIABLE
into VALUES (it is sooo much works to fetch them..)
and then LOCAL VALUES (duplicating the scope restriction
that are present in Forth).

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst