dxforth <dxforth@gmail.com> writes:
> So you're creating a forth? Care to share some details - target cpu,
> language used to implement etc.

Target cpu ATTiny1616 and similar. Bytecode interpreter (in asm) for
Forth VM on the target, metacompiler/tethered host on remote machine.
Metacompiler might be written in Gforth for Forth points, or might be
something like Python.

I started something like this for the STM8 a while back, but had to put
it aside. That one worked a bit differently using an ITC-like approach,
but I decided after a while that bytecode is less hassle. This thing
needs to be compact on the target, but not especially fast.

The target application is mostly written in C, so the Forth would be
used for debugging, interactive experiments, and user extensions.

On 7/09/2021 01:11, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> So you're creating a forth? Care to share some details - target cpu,
>> language used to implement etc.
>
> Target cpu ATTiny1616 and similar. Bytecode interpreter (in asm) for
> Forth VM on the target, metacompiler/tethered host on remote machine.
> Metacompiler might be written in Gforth for Forth points, or might be
> something like Python.
>
> I started something like this for the STM8 a while back, but had to put
> it aside. That one worked a bit differently using an ITC-like approach,
> but I decided after a while that bytecode is less hassle. This thing
> needs to be compact on the target, but not especially fast.
>
> The target application is mostly written in C, so the Forth would be
> used for debugging, interactive experiments, and user extensions.

So that's either C or Forth running? Is there an existing forth
you're using as a model?

I had a closer look at the stack usage for the multitasking example.
Excluding memory for USER variables and HOLD buffer, I measure the
running task required 15 cells data stack (3 for task switch) and
7 cells of return stack.

dxforth <dxforth@gmail.com> writes:
> So that's either C or Forth running? Is there an existing forth
> you're using as a model?

Yeah basically, it's a C program but you could tell it to call the Forth
VM as a subroutine. The VM would be an asm version of this, since
compiling the C version gave around 2KB of code and it should be maybe
1/4 of that:

http://chiselapp.com/user/tehologist/repository/compc/home

There is also an old Forth Dimensions article about metacompilers that I
think was written by Brad Rodriguez, that I'd follow for the remote
side. I'll have to find it again.

I notice Chuck Moore's chips and MPE's more recent VM paper adds some
registers to the stack as part of the VM:

http://www.complang.tuwien.ac.at/anton/euroforth/ef08/papers/pelc.pdf

So I could add something like that if it looks useful. Also, FlashForth
has an extra stack (the P stack) for temporary values. I will look at
how it works.

> running task required 15 cells data stack (3 for task switch) and
> 7 cells of return stack.

I think this is fine, the ATTiny16 has 1K of ram and using a few hundred
bytes of it for Forth shouldn't be a problem. There would be a bunch of
variables shared with the C program that wouldn't "count".

On Sunday, September 5, 2021 at 10:44:50 PM UTC-7, dxforth wrote:
> On 6/09/2021 09:47, Hugh Aguilar wrote:
> > On Saturday, September 4, 2021 at 8:35:03 PM UTC-7, dxforth wrote:
> >> On 5/09/2021 08:40, Hugh Aguilar wrote:
> >> >
> >> > I have yet to find anybody on comp.lang.forth who understands the concept of
> >> > general-purpose data-structures. Do you? Can you explain this concept?
> >> General-purpose data-structures implies lots of parameter passing which
> >> necessitates locals. Did I get it right?
> >
> > No. You are not even close. You don't know what rquotations do,
> > and you don't know what a general-purpose data-structure is.
> >
> > I haven't forgotten about how you mocked me by using the term "disambiguifier"
> > for some kindergarten-level code that you wrote.
> > You either don't know anything about that subject, or you were just acting stupid
> > for the purpose of annoying me.

> Disambiguifiers were aimed at kindergarten-level users to convince them
> how broken was ANS, and by implication those behind it.

Given the disambiguifiers I was able to write an early-binding MACRO: and POST: etc.
that are far superior to Anton Ertl's ridiculous ]] because they support literals as well
as words that take data out of the input stream such as [CHAR] POSTPONE etc..
You don't don't what you are talking about, so STFU!

> So it's been
> for your general-purpose code routines - thinly-veiled expositions on
> how ANS got it wrong. In the meantime they do the opposite.

This isn't true either. My general-purpose data-structures are useful for writing
application programs. I rely on this code for writing programs, such as the MSP430 assembler.
You don't don't what you are talking about, so STFU!

> One has
> to travel a long way in Forth to get past the pro/anti-ANS lobby.

I want you to travel a long way, and not come back.
I have had enough of you attacking me with this idiotic nonsense.
You don't know anything about programming. You are just an annoying idiot.

> > Stop pestering me with idiotic nonsense --- I don't think that you know anything
> > about programming at all --- I don't want to hear anything further from you.

On 7/09/2021 12:02, Paul Rubin wrote:
>
> I notice Chuck Moore's chips and MPE's more recent VM paper adds some
> registers to the stack as part of the VM:
>
> http://www.complang.tuwien.ac.at/anton/euroforth/ef08/papers/pelc.pdf
>
> So I could add something like that if it looks useful. Also, FlashForth
> has an extra stack (the P stack) for temporary values. I will look at
> how it works.

I suspect diminishing returns if one has to simulate it. The classic VM
requires a fancy optimizer to get any performance out of it.

On 7/09/2021 12:13, Hugh Aguilar wrote:
> On Sunday, September 5, 2021 at 10:44:50 PM UTC-7, dxforth wrote:
>
>> So it's been
>> for your general-purpose code routines - thinly-veiled expositions on
>> how ANS got it wrong. In the meantime they do the opposite.
>
> This isn't true either. My general-purpose data-structures are useful for writing
> application programs. I rely on this code for writing programs, such as the MSP430 assembler.
> You don't don't what you are talking about, so STFU!

Library code is only as good as the applications written with them.
Feel free to post your completed apps (https://pastebin.com/) and
folks can judge for themselves.

dxforth <dxforth@gmail.com> writes:
> I suspect diminishing returns if one has to simulate it. The classic VM
> requires a fancy optimizer to get any performance out of it.

I think runtime speed is not really an issue here. The idea is to make
coding easier, and maybe to make the code a little smaller.

On Tuesday, September 7, 2021 at 6:42:59 AM UTC+2, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> > I suspect diminishing returns if one has to simulate it. The classic VM
> > requires a fancy optimizer to get any performance out of it.
> I think runtime speed is not really an issue here. The idea is to make
> coding easier, and maybe to make the code a little smaller.
Oh, I agree with dxforth here. It's not rocket science to implement this proposal. However, given this will be done by variables and stuff - it won't make programs run faster.
And easier: if you want to go "easier" the 4tH preprocessor allows you to write code like this:

: calculate ( -- flag)
let f = f - u;
let h = h - v;
let v = (((v + g) * 10) - (u * 2)) / 10;
let h,|0> 0=|; \ height < 1?
;

Now you got your "easier". But if you want to go "easy" there are better suited languages for this. Forth is a pretty nice language. It allows you to bolt on virtually everything you want - if you want "easier". However, it's YOUR choice to do so. Don't make it my choice by trying to get it into the standard by proposing laughable extensions like ^1 ^2.

Note that if you do this in Forth, your first ^1 isn't your second ^1, because now ^1 is ^2. So in that case it's either a fancy ROLL or you gotta save some pointer to prevent ^1 becoming ^2. And THAT is function call overhead. You suffer the same penalty with LOCALs, since ; will have to clean up your mess.

And I don't like you messing with my VM, just because you want to make "things easy". I got my things "easy". I write stuff much faster in Forth than I do in C. That you can't fathom raw Forth is NOT my problem - and I won't make it my problem either.

I know things can get tricky when your stack needs to keep track of three elements or more. And some routines simply require that many parameters. I solved this partially by creating three read-only "registers" on the return stack R@, R'@ and R"@. I can even AKA the darn things to keep the source readable.

aka r@ x0
aka r'@ y0

: circle ( x y radius --)
swap >r swap >r 1 over - swap 0 ( dp x y R: x0 y0)

begin
over x0 + over y0 + set_pixel ( x0 + x, y0 + y)
over x0 swap - over y0 + set_pixel ( x0 - x, y0 + y)
over x0 + over y0 swap - set_pixel ( x0 + x, y0 - y)
over x0 swap - over y0 swap - set_pixel ( x0 - x, y0 - y)
over y0 + over x0 + swap set_pixel ( x0 + y, y0 + x)
over y0 + over x0 swap - swap set_pixel ( x0 - y, y0 + x)
over y0 swap - over x0 + swap set_pixel ( x0 + y, y0 - x)
over y0 swap - over x0 swap - swap set_pixel ( x0 - y, y0 - x)
( dp x y R: x0 y0)
1+ >r over 0> if 1- r@ over - else r@ then 2* 1+ rot + swap r>
over over < ( dp x y f R: x0 y0)
until drop drop drop r> drop r> drop
;

[DEFINED] 4TH# [IF]
hide x0
hide y0
[THEN]

And yes, you still have to keep on thinking and planning. That's Forth. Deal with it. https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/

Hans Bezemer

the.bee...@gmail.com schrieb am Dienstag, 7. September 2021 um 12:12:28 UTC+2:
> On Tuesday, September 7, 2021 at 6:42:59 AM UTC+2, Paul Rubin wrote:
> > dxforth <dxf...@gmail.com> writes:
> > > I suspect diminishing returns if one has to simulate it. The classic VM
> > > requires a fancy optimizer to get any performance out of it.
> > I think runtime speed is not really an issue here. The idea is to make
> > coding easier, and maybe to make the code a little smaller.
> Oh, I agree with dxforth here. It's not rocket science to implement this proposal. However, given this will be done by variables and stuff - it won't make programs run faster.
> And easier: if you want to go "easier" the 4tH preprocessor allows you to write code like this:
>
> : calculate ( -- flag)
> let f = f - u;
> let h = h - v;
> let v = (((v + g) * 10) - (u * 2)) / 10;
> let h,|0> 0=|; \ height < 1?
> ;
>
> Now you got your "easier". But if you want to go "easy" there are better suited languages for this. Forth is a pretty nice language. It allows you to bolt on virtually everything you want - if you want "easier". However, it's YOUR choice to do so. Don't make it my choice by trying to get it into the standard by proposing laughable extensions like ^1 ^2.
>

Nice and impressive!

In MY choice Forth I can/could define
: MYROT { a b c == b c a } ;
: MYOVER { a b == a b a } ;
: MYFOVER { F: a b == a b a } ;

The locals parser is extended to define all required locals of any type and
to push "output locals" to the stack before leaving the word.
This is implemented as rather simple extension of standard Forth locals scheme.

Of course a.m. examples are overly simple and show only the basic idea.
In reality e.g. calculations with complex numbers and arrays, code becomes
really elegant and readable. Without that extension I would have left Forth
behind long ago.

On 7/09/2021 23:54, minf...@arcor.de wrote:
>
> Of course a.m. examples are overly simple and show only the basic idea.
> In reality e.g. calculations with complex numbers and arrays, code becomes
> really elegant and readable. Without that extension I would have left Forth
> behind long ago.

It begs the question why stay with forth. Moore wrote a BASIC compiler to
show that he could - not because he might one day need it. Forth doesn't
exist to solve problems other languages already handle (better in the opinion
of some). It exists for its differences.

Forth with its absurd numbers of small definitions replaces the parameter
and structure laden, page-long, multi-indented definition approach of other
languages. Were they the same and appealed to the same people, Forth would
have no reason to exist.

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> Now you got your "easier". But if you want to go "easy" there are
> better suited languages for this.

What kind of recommendation for Forth is that, to say it makes things
unnecessarily hard? Some of us want to get our stuff done without
jumping through extra hoops simply because we can.

> I solved this partially by creating three read-only "registers" on the
> return stack R@, R'@ and R"@. I can even AKA the darn things to keep
> the source readable.

That sounds like locals ;-).
> : circle ( x y radius --)
> swap >r swap >r 1 over - swap 0 ( dp x y R: x0 y0)

: circle {: x0 y0 r :} ... ;

> And yes, you still have to keep on thinking and planning. That's
> Forth. Deal with it.
> https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/

"Now, does it run faster? Hardly. Is it any shorter. Not much, if
any. Is it easier to maintain? Only for Forth programmers, I think. So
why bother? Because this is Forth.."

I dunno, I don't see how it's easier for even Forth programmers to
maintain. It just seems like masochism.

On 8/09/2021 13:48, Paul Rubin wrote:
>
> That sounds like locals ;-).
>> : circle ( x y radius --)
>> swap >r swap >r 1 over - swap 0 ( dp x y R: x0 y0)
>
> : circle {: x0 y0 r :} ... ;
>
>> And yes, you still have to keep on thinking and planning. That's
>> Forth. Deal with it.
>> https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/
>
> "Now, does it run faster? Hardly. Is it any shorter. Not much, if
> any. Is it easier to maintain? Only for Forth programmers, I think. So
> why bother? Because this is Forth.."
>
> I dunno, I don't see how it's easier for even Forth programmers to
> maintain. It just seems like masochism.

Circle is defined once and likely won't be changed. What is there to
maintain? The problem with locals is that if one can justify its use
in one function, why not use it everywhere - which has a multiplying
effect on performance. Far from being masochism, forth and the stack
gets easier as one uses it and it's locals that begin to look like the
odd man out - which of course they are.

dxforth schrieb am Mittwoch, 8. September 2021 um 05:00:42 UTC+2:
> On 7/09/2021 23:54, minf...@arcor.de wrote:
> >
> > Of course a.m. examples are overly simple and show only the basic idea.
> > In reality e.g. calculations with complex numbers and arrays, code becomes
> > really elegant and readable. Without that extension I would have left Forth
> > behind long ago.
>
> It begs the question why stay with forth. Moore wrote a BASIC compiler to
> show that he could - not because he might one day need it. Forth doesn't
> exist to solve problems other languages already handle (better in the opinion
> of some). It exists for its differences.

It is no language question, it is MY answer to get the job done. I use Forth
in a restricted multitasking environment (controller) where Forth excels per se.
And with proper DSL extensions I can do higher math and signal processing
on the same software core.

Language purists live in virtual reality and are mostly unproductive.

dxforth <dxforth@gmail.com> writes:
> The problem with locals is that if one can justify its use in one
> function, why not use it everywhere - which has a multiplying effect
> on performance.

Ok, maybe using locals everywhere slows down the program by 2x. I doubt
that, but just suppose. I'm probably taking a 5x slowdown by using
interpreted Forth instead of compiled C to start with. The additional
2x is still perfectly fine for what I'm doing. And in the Forth spirit,
I can write hot loops in assembler. So now what?

I made a mistake saying the ram capacity of the attiny1616 was 1KB. It
is actually 2KB so there is plenty of ram, even for a multitasker with
stack switching if that looks useful.

> Far from being masochism, forth and the stack gets easier as one uses
> it and it's locals that begin to look like the odd man out - which of
> course they are.

I don't know. In the bigger scheme of things, Forth is the odd man
out. Maybe locals can bring it back into the fold.

An alternative ugly idea: reserve up to 4 or maybe more cells of
registers for temporaries. The AVR has 32 8-bitmachine registers, so
four 16 bit cells this would use 8 of them.

: foo/3 .... ;

(syntax inspired by Erlang which I think was inspired by Prolog) would
save 3 registers on the R stack (the code for that is very compact)
could be referred to as A, B, and C. >A, 2>A, and 3>A would transfer
that many cells from the D stack to A, A B, or A B C. There would
be automatic cleanup on function exit.

Accessing these registers would be faster than doing stack operations,
since they are machine registers and the compiler could generate simple
machine code to use them.

On 8/09/2021 18:16, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> The problem with locals is that if one can justify its use in one
>> function, why not use it everywhere - which has a multiplying effect
>> on performance.
>
> Ok, maybe using locals everywhere slows down the program by 2x. I doubt
> that, but just suppose. I'm probably taking a 5x slowdown by using
> interpreted Forth instead of compiled C to start with. The additional
> 2x is still perfectly fine for what I'm doing. And in the Forth spirit,
> I can write hot loops in assembler. So now what?

Fighting the language one is coding in doesn't strike me as optimum.

> I made a mistake saying the ram capacity of the attiny1616 was 1KB. It
> is actually 2KB so there is plenty of ram, even for a multitasker with
> stack switching if that looks useful.
>
>> Far from being masochism, forth and the stack gets easier as one uses
>> it and it's locals that begin to look like the odd man out - which of
>> course they are.
>
> I don't know. In the bigger scheme of things, Forth is the odd man
> out. Maybe locals can bring it back into the fold.

'Forth is a stack-based language' ought to have been clear enough.

On Wednesday, September 8, 2021 many wrote.

I might be in a majority here for once. I seldom use locals, mainly
because its a clash in style, but have no qualms of using them when
I want to.

Don't see anything new being said in this thread. It boils down to
this:
1) The purist:
The more one uses the stack the better at it he will become and
the cost of local sugar is not worth it.
2) The localist:
Locals are convenient and clear where code can reflect written
equations. The sugar is of little cost.

I roll my eyes when I see "Chuck did it this way", "The Forth Way,
"Easier to maintain", "Less mistakes", and "Helping the poor newbie".
There's probably a rhetorical category for such phrases. To me they just
convey someone's delusional "Do it MY way and the world will be a better
place."

I can appreciate dxForth not wanting things in the standard that may
change the character of Forth. Not having to deal with problems
professionals face what's gets in the standard doesn't matter much to me.
That's not to say the ideas and discussions are not of interest.

I make no effort to code to anyone's delusional "The Forth Way"
(have no need to follow) and continue to enjoy cobbling Forth code my
way (have no need of a following).
--
me

"Many can see the obvious; few can see the potential."

On 8/09/2021 18:16, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> The problem with locals is that if one can justify its use in one
>> function, why not use it everywhere - which has a multiplying effect
>> on performance.
>
> Ok, maybe using locals everywhere slows down the program by 2x. I doubt
> that, but just suppose.

About right for this example

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 ;

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

Then there's code size. Return stack we discussed previously.

DX-Forth DTC
RECT1 48 byt
RECT2 27 byt

VFX
RECT1 139/44 byt/instr
RECT2 93/27 byt/instr

On 2021-09-07 13:12, Hans Bezemer wrote:
[...]

> And easier: if you want to go "easier" the 4tH preprocessor allows you to write code like this:
>
> : calculate ( -- flag)
> let f = f - u;
> let h = h - v;
> let v = (((v + g) * 10) - (u * 2)) / 10;
> let h,|0> 0=|; \ height < 1?
> ;

Nice.

How does the translated code look like? (i.e. after preprocessing)

I can suppose something like "f @ u @ - f !" for "let f = f - u;", and
all variables should be in the scope.

An interesting challenge is to support "ephemeral" immutable local
variables, that are translated into usual stack-based code.

So the following "foo"

: foo ( x1 x2 x3 -- x4 )
let( a b c ){ a a * b b * + c / }
;

is translated to (or at least it's equivalent to):

: foo ( x1 x2 x3 -- x4 )
>r dup * swap dup * + r> /
;

In the construct:

let( <names> ){ <body> }

The code in <body> cannot access the data stack items that were not
placed to the stack by this code. Perhaps, some other restriction
should be also applied.

[...]

> I know things can get tricky when your stack needs to keep track of three elements or more.
> And some routines simply require that many parameters.

If some routine require too much parameters, it a sign to introduce a
state and/or a data structure (i.e., pass many parameters by a single
argument).

> I solved this partially by creating three read-only "registers" on the return stack
> R@, R'@ and R"@. I can even AKA the darn things to keep the source readable.
>
> aka r@ x0
> aka r'@ y0
>
> : circle ( x y radius --)
> swap >r swap >r 1 over - swap 0 ( dp x y R: x0 y0)
>
> begin
> over x0 + over y0 + set_pixel ( x0 + x, y0 + y)
> over x0 swap - over y0 + set_pixel ( x0 - x, y0 + y)
> over x0 + over y0 swap - set_pixel ( x0 + x, y0 - y)
> over x0 swap - over y0 swap - set_pixel ( x0 - x, y0 - y)
> over y0 + over x0 + swap set_pixel ( x0 + y, y0 + x)
> over y0 + over x0 swap - swap set_pixel ( x0 - y, y0 + x)
> over y0 swap - over x0 + swap set_pixel ( x0 + y, y0 - x)
> over y0 swap - over x0 swap - swap set_pixel ( x0 - y, y0 - x)
> ( dp x y R: x0 y0)
> 1+ >r over 0> if 1- r@ over - else r@ then 2* 1+ rot + swap r>
> over over < ( dp x y f R: x0 y0)
> until drop drop drop r> drop r> drop
> ;
>

Why not use the turtle graphics (cursor-based) approach?

> And yes, you still have to keep on thinking and planning. That's Forth. Deal with it.
> https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/

In your variant (1) by the link, why don't you use float literals?
I.e., "1e" instead of "1 s>f" ?
And why don't you rely on the separate floating-point stack?

(1)

float array acc

: tamura-kanada ( n -- fpi)
>r 1 s>f 4 s>f f/ acc f!
1 s>f fdup 2 s>f fsqrt f/ fswap ( f: b a)
1 r> over ( 1 n 1)

do ( f: b a)
>r fover fover f+ 2 s>f f/ ( f: b y a')
frot frot fswap fover f* fsqrt ( f: a' y b')
frot frot fover fswap f- fdup f* ( f: b' a' a'-y^2)
r@ s>f f* acc f@ fswap f- acc f! r> 2*
loop drop

f+ fdup f* acc f@ 4 s>f f* f/
;

It's clumsy, to put it mildly.
Please, don't say that it's Forth and we should just deal with it.

I can suggest a better variant.

: fsq ( f: r1 -- r2 ) fdup f* ;
: fsqdist ( f: r1 r2 -- r3 ) f- fsq ;
: fave ( f: r1 r2 -- r3 ) f+ 2e f/ ;
: fmeang ( f: r1 r2 -- r3 ) f* fsqrt ;

: tamura-kanada ( n -- ) ( f: -- pi )
1e \ a0
1e 2e fsqrt f/ \ b0
1e 4e f/ \ c0
{: f:a f:b f:c :}
1e ( F: k0 )
1 max 1 ?do ( F: k )
a a b a b fmeang ->b fave fdup ->a ( F: k a1 a2 )
fsqdist fover f* fnegate c f+ ->c
2e f*
loop fdrop
a b f+ fsq 4e f/ c f/
;

If you want to avoid locals (temporary locals), we can use private
static variables in something like the following way:

colon tamura-kanada ( n -- ) ( f: -- pi )

fprop a
fprop b
fprop c

:body
1e ->a \ a0
1e 2e fsqrt f/ ->b \ b0
1e 4e f/ ->c \ c0
1e ( F: k0 )
1 max 1 ?do ( F: k )
a a b a b fmeang ->b fave fdup ->a ( F: k a1 a2 )
fsqdist fover f* fnegate c f+ ->c
2e f*
loop fdrop
a b f+ fsq 4e f/ c f/
;

--
Ruvim

On Wednesday, September 8, 2021 at 8:22:30 AM UTC-7, S Jack wrote:
> I roll my eyes when I see "Chuck did it this way", "The Forth Way,
> "Easier to maintain", "Less mistakes", and "Helping the poor newbie".
> There's probably a rhetorical category for such phrases. To me they just
> convey someone's delusional "Do it MY way and the world will be a better
> place."

The problem is that Elizabeth Rather appoints the Forth-200x committee members
and she is absolutely opposed to general-purpose data-structures.
The Forth-200x committee members, such as Anton Ertl, Bernd Paysan and
Stephen Pelc are relentlessly ignorant of general-purpose data-structures because
they are afraid of losing their exulted position in Forth-200x lording over mere
Forth programmers such as myself. They can have the concept of general-purpose
data-structures explained to them one hundred times by the most patient teachers
using the simplest words, and they will continue to steadfastly maintain their ignorance.
The Forth-200x committee members are acting dumb to avoid the Elizabeth Rather's taboo.
Elizabeth Rather created this taboo because she is dumber than a box of hammers;
she is blindly following Charles Moore decades later instead of learning how to program.
She has turned Forth into a haven for people such as DXforth who are equally dumb,
but want to be experts in programming without ever learning anything.

The Forth-200x committee member Peter Knaggs made an attempt at designing
a general-purpose linked-list and he failed completely.
https://groups.google.com/g/comp.lang.forth/c/cMa8wV3OiY0/m/INBDVBh0BgAJ
I said this:
On Saturday, May 18, 2019 at 3:05:23 PM UTC-7, hughag...@gmail.com wrote:
> Why did Peter Knaggs fail so badly at designing a linked-list package?
> He does have a PhD., so you would think that he could succeed at this.
> There are three possible explanations for his failure:
>
> 1.) Peter Knaggs is dumber than a fresh cow-patty on the summit of
> Mount Everest. He couldn't figure out how to implement a linked list.
>
> 2.) Elizabeth Rather told him to design a linked-list package, but
> purposely cripple it. Her goal was that it would be accepted, but then
> nobody would use it because it doesn't work. Then she would say:
> "...in Forth it's so easy to build data structures that are exactly right
> for the particular application at hand that worrying about what pre-built
> structures you have and how to use them is just not worth the bother."
> 3.) Stephen Pelc told him to design a linked-list package, but
> purposely cripple it. His goal was that it would be accepted, but then
> nobody would use it because it doesn't work. Then he would say:
> "If you want a linked-list package that is actually usable,
> you have to buy VFX and get our proprietary package that includes
> such super-duper features as FIND-NODE etc.."

Elizabeth Rather is opposed to general-purpose data-structures because Charles Moore
(note that I don't call him "Chuck" because I'm not pretending to be his buddy boy")
was supposedly opposed. I say "supposedly"because he has been incommunicado for decades
--- ever since he walked out of the ANS-Forth committee and slammed the door behind him.
All of his quotes on the subject of programming style come from prior to when
Elizabeth Rather kicked him out of Forth Inc. in 1982 --- this opposition to
general-purpose data-structures is really an artifact of the 1970s --- and it is not really
"opposition" so much as "ignorance" as the concept was largely unknown in in the 1970s.
This was the era of the 8080 and 6800, prior to the advent of the Z80 and the 6502
--- quite a lot of concepts were unknown in the 1970s (I was in elementary school then).

The C language is also an artifact of the 1970s, and it also fails to support
general-purpose data-structures. C originated for systems programming,
especially the Unix OS, which isn't really similar to application programming.
GCC introduced nested functions that have access to the parent function's
local variables (similar to my rquotations but more complicated because
they can have local variables of their own). GCC presumably borrowed
this idea from Pascal. The C language is stuck with ANSI-C however, that fails
to support general-purpose data-structures. The 1990s were an opportunity for Forth
to pull ahead of ANSI-C and provide rquotations that would have supported
general-purpose data-structures. The ANS-Forth committee, led by Elizabeth Rather,
totally failed to take advantage of this opportunity. What we got instead was
ANS-Forth that was an attempt at turning Forth into ANSI-C with reverse-polish-notation.
ANS-Forth could have revived Forth, but instead nailed the coffin shut!

dxforth <dxforth@gmail.com> writes:
> 'Forth is a stack-based language' ought to have been clear enough.

I don't know of anyone using Forth on stack hardware these days.
Everyone uses ram hardware. So they might as well use the ram.
I thought one of the ideas of Forth was to utilize the hardware, after
all. The AVR's have 32 registers, a wonderful resource, and you want to
just ignore them?

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.

On 2021-09-08 21:25, Ruvim wrote:
>
> An interesting challenge is to support "ephemeral" immutable local
> variables, that are translated into usual stack-based code.
>
> So the following "foo"
>
>   : foo ( x1 x2 x3 -- x4 )
>     let( a b c ){ a a *  b b * + c / }
>   ;
>
> is translated to (or at least it's equivalent to):
>
>   : foo ( x1 x2 x3 -- x4 )
>     >r dup * swap dup * + r> /
>   ;
>
>
> In the construct:
>
>   let( <names> ){ <body> }
>
> The code in <body> cannot access the data stack items that were not
> placed to the stack by this code.  Perhaps, some other restriction
> should be also applied.

One hard restriction is that the static stack effect for each word in
<body> should be known. If a static stack effect for neither word
(except "variables" themself) is known, the corresponding actual
variables cannot be avoided in principle.

Concerning the restriction on accessing (consuming) the data stack items
beyond the construct — it's unclear to me whether this restriction is
needed or not.

--
Ruvim

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 ;
>
>: RECT2 ( x1 y1 x2 y2 -- ) \ P.Rubin c.l.f
> 2over 2dup moveto 2over swap rot lineto
> 2swap lineto lineto lineto ;
>
>Then there's code size. Return stack we discussed previously.
>
>DX-Forth DTC
>RECT1 48 byt
>RECT2 27 byt
>
>VFX
>RECT1 139/44 byt/instr
>RECT2 93/27 byt/instr

This time lxf is not doing so great:

RECT1 131 bytes
RECT2 87 bytes

For 64-bit Gforth it is:

RECT1 216 bytes (27 cells) threaded code 321 bytes native code (without ;s)
RECT2 136 bytes (17 cells) threaded code 233 bytes native code (without ;s)

native-code is for gforth-fast.

- 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 Wednesday, September 8, 2021 at 5:00:42 AM UTC+2, dxforth wrote:
> It exists for its differences.
Exactly my point. It's a mindset. With all these features we obviously crave for - I find writing C code tedius. It takes much longer before I have compilable and testable code. And for some reason or another, writing application code is much faster in Forth than C - in my experience. Forth hardly ever surprises you - like C can.

> Forth with its absurd numbers of small definitions replaces the parameter
> and structure laden, page-long, multi-indented definition approach of other
> languages. Were they the same and appealed to the same people, Forth would
> have no reason to exist.
Exactly my point. All these "features" are better implemented in all these languages that were designed around them. Therefore, why do you want 'em in Forth? Just because you're too lazy to learn it the proper way and still wanna addit to your resume? See mummy, I'm cool, I can write Forth?

I think the best thing of Forth is the mindset it creates. I once started out with a CASE..ENDCASE converter and I ended up with a preprocessor that challenges M4. Existing of hundreds of one liners. I wouldn't even know where to begin writing such a beast in C. In Forth it seems relatively easy..

Hans Bezemer

On Wednesday, September 8, 2021 at 8:25:48 PM UTC+2, Ruvim wrote:

I'll keep it short - 4tH is NOT your average Forth compiler. It's quite lightweight with about 500 libs to customize it.
So floats are no built-in. They're extra. And there are two different flavors.

Turtle graphics are also extra. And why would you use these in an efficient, precision circle algorithm?

And yes - like others I've also written code that will punch out stack shuffles after a stack diagram. It's not hard.

The idea of a stack is to eliminate as many variables as possible. That mean local and global variables. I'm always proud if I succeed in that.

And yes, the preprocessor does exactly that when evaluating LET expressions. It's an algorithm - not magic. I'd like to have and give choices. There is not one single right way to do things.

However, I am quite protective of my small core. I don't like bloating it with things someone might not need.

Hans Bezemer

> On 2021-09-07 13:12, Hans Bezemer wrote:
> [...]
> > And easier: if you want to go "easier" the 4tH preprocessor allows you to write code like this:
> >
> > : calculate ( -- flag)
> > let f = f - u;
> > let h = h - v;
> > let v = (((v + g) * 10) - (u * 2)) / 10;
> > let h,|0> 0=|; \ height < 1?
> > ;
> Nice.
>
> How does the translated code look like? (i.e. after preprocessing)
>
> I can suppose something like "f @ u @ - f !" for "let f = f - u;", and
> all variables should be in the scope.
>
>
>
>
> An interesting challenge is to support "ephemeral" immutable local
> variables, that are translated into usual stack-based code.
>
> So the following "foo"
>
> : foo ( x1 x2 x3 -- x4 )
> let( a b c ){ a a * b b * + c / }
> ;
>
> is translated to (or at least it's equivalent to):
>
> : foo ( x1 x2 x3 -- x4 )
> >r dup * swap dup * + r> /
> ;
>
>
> In the construct:
>
> let( <names> ){ <body> }
>
> The code in <body> cannot access the data stack items that were not
> placed to the stack by this code. Perhaps, some other restriction
> should be also applied.
>
>
>
>
> [...]
> > I know things can get tricky when your stack needs to keep track of three elements or more.
> > And some routines simply require that many parameters.
> If some routine require too much parameters, it a sign to introduce a
> state and/or a data structure (i.e., pass many parameters by a single
> argument).
> > I solved this partially by creating three read-only "registers" on the return stack
> > R@, R'@ and R"@. I can even AKA the darn things to keep the source readable.
> >
> > aka r@ x0
> > aka r'@ y0
> >
> > : circle ( x y radius --)
> > swap >r swap >r 1 over - swap 0 ( dp x y R: x0 y0)
> >
> > begin
> > over x0 + over y0 + set_pixel ( x0 + x, y0 + y)
> > over x0 swap - over y0 + set_pixel ( x0 - x, y0 + y)
> > over x0 + over y0 swap - set_pixel ( x0 + x, y0 - y)
> > over x0 swap - over y0 swap - set_pixel ( x0 - x, y0 - y)
> > over y0 + over x0 + swap set_pixel ( x0 + y, y0 + x)
> > over y0 + over x0 swap - swap set_pixel ( x0 - y, y0 + x)
> > over y0 swap - over x0 + swap set_pixel ( x0 + y, y0 - x)
> > over y0 swap - over x0 swap - swap set_pixel ( x0 - y, y0 - x)
> > ( dp x y R: x0 y0)
> > 1+ >r over 0> if 1- r@ over - else r@ then 2* 1+ rot + swap r>
> > over over < ( dp x y f R: x0 y0)
> > until drop drop drop r> drop r> drop
> > ;
> >
> Why not use the turtle graphics (cursor-based) approach?
> > And yes, you still have to keep on thinking and planning. That's Forth. Deal with it.
> > https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/
> In your variant (1) by the link, why don't you use float literals?
> I.e., "1e" instead of "1 s>f" ?
> And why don't you rely on the separate floating-point stack?
>
>
> (1)
>
> float array acc
>
> : tamura-kanada ( n -- fpi)
> >r 1 s>f 4 s>f f/ acc f!
> 1 s>f fdup 2 s>f fsqrt f/ fswap ( f: b a)
> 1 r> over ( 1 n 1)
>
> do ( f: b a)
> >r fover fover f+ 2 s>f f/ ( f: b y a')
> frot frot fswap fover f* fsqrt ( f: a' y b')
> frot frot fover fswap f- fdup f* ( f: b' a' a'-y^2)
> r@ s>f f* acc f@ fswap f- acc f! r> 2*
> loop drop
>
> f+ fdup f* acc f@ 4 s>f f* f/
> ;
>
>
> It's clumsy, to put it mildly.
> Please, don't say that it's Forth and we should just deal with it.
>
>
> I can suggest a better variant.
>
> : fsq ( f: r1 -- r2 ) fdup f* ;
> : fsqdist ( f: r1 r2 -- r3 ) f- fsq ;
> : fave ( f: r1 r2 -- r3 ) f+ 2e f/ ;
> : fmeang ( f: r1 r2 -- r3 ) f* fsqrt ;
>
> : tamura-kanada ( n -- ) ( f: -- pi )
> 1e \ a0
> 1e 2e fsqrt f/ \ b0
> 1e 4e f/ \ c0
> {: f:a f:b f:c :}
> 1e ( F: k0 )
> 1 max 1 ?do ( F: k )
> a a b a b fmeang ->b fave fdup ->a ( F: k a1 a2 )
> fsqdist fover f* fnegate c f+ ->c
> 2e f*
> loop fdrop
> a b f+ fsq 4e f/ c f/
> ;
>
>
> If you want to avoid locals (temporary locals), we can use private
> static variables in something like the following way:
>
> colon tamura-kanada ( n -- ) ( f: -- pi )
>
> fprop a
> fprop b
> fprop c
>
> :body
> 1e ->a \ a0
> 1e 2e fsqrt f/ ->b \ b0
> 1e 4e f/ ->c \ c0
> 1e ( F: k0 )
> 1 max 1 ?do ( F: k )
> a a b a b fmeang ->b fave fdup ->a ( F: k a1 a2 )
> fsqdist fover f* fnegate c f+ ->c
> 2e f*
> loop fdrop
> a b f+ fsq 4e f/ c f/
> ;
>
>
>
> --
> Ruvim