dxforth <dxforth@gmail.com> writes:
> My point was it went from 4 locals to 6 for reasons of style. It may be
> C-style to expend resources this way (I wouldn't know)

In C these days, the extra locals wouldn't expend any resources in most
cases, since the compiler would optimize them away.

> but I doubt it's Moore's.

This I don't know. A traditional thread Forth interpreter (Moore's
invention) is probably 10x slower than CODE doing the same thing, but
Moore only used CODE when he had to. If 9x extra compute cycles is
fine, why are a few memory cells a big deal?

There's a similar thing from the Forth stylistic convention that words
should consume their arguments. The convention makes your code more
understandable but it means consuming a little more data stack space
than necessary, and running some extra dups and drops.

> But what are implications of using locals in Forth? It's this: A
> stack-based language that cannot exist without the help of locals has
> failed and therefore does not deserve to exist.

Well, Moore used VARIABLEs instead of locals, so the pure stack vision
already failed because of that. One could simply say Forth works better
in the presence of some impurity. Locals are another, perhaps cleaner,
way to add the impurity.

There is a similar thing in functional programming called "point-free
style". That style avoids using named function parameters, so instead
of "f x = sqrt (sin x)" you'd say "f = sqrt . sin". Nice, but it can
get really confusing, like "f x y z = (x+y)*z" becomes "f = ((*) .) . (+)".

Point-free is a nice theoretical construct and you can apparently
write every program that way, but for practical purposes it's much nicer
to use named parameters except in the simpler cases. The feeling of
point-free coding is not that much different from Forth stackrobatics.
It can be fun but if your goal is to write programs that work, it's
not that good a use of mental energy.

Hans Bezemer <the.beez.speaks@gmail.com> wrote:
> On Tuesday, November 1, 2022 at 2:19:21 PM UTC+1, anti...@math.uni.wroc.pl wrote:
> > I think that some voices here vastly overestimate extra complexity.
> I did locals in my uBASIC interpreter - because it's BASIC - a Fortran
> derivative - it's fitting. But it requires setting up and releasing a stack frame,
> copying values there - that's a whole lot of overhead. For some ugly C-ism.
> As if we didn't have enough of those in ANS Forth.

Copying values is not really overhead. Normally values are copied
because you need to preserve them, so it is part of computation
and needs to be done one way or anouther. In fact, bulk copy
in many cases is most officient way to do this.
> > AFAICS at runtime it is enough to have bunch of extra primitives:
> > add and subtract from return stack pointer (could be single primitive)
> > and two primitives fpr each local, one for reading, the other for
> > storing. If one sticks to standard limit of 16 locals that is 33
> > primitives. And they are very simple, one or two machine instructions
> > for real work (plus whatever boilerplate is needed for dispatch).
> 33 primitives? And you call that "minor overhead"? My entire VM has about
> 100 primitives.

I am not sure what is troubling you here. That they are called
"primitives"? Access primitives are very simple and very similar
to each other, conceptually there is almost no increase in complexity.
That they need to be coded in assembler? Albert's ciforth has about
300 words defiend in assembler, and from glance at his code I think
that most is longer than proposed primitives. So it seems that one
would get 5-7% increase in amount of assembler code and to that
matter simpler than much of the rest. Of course, you may that pride
that you need less assember code. However, I take pragmatic view
here: assembler is problematic because one can do tricky things
which are hard to understand. But the primitives are so simple that
there is not problem with understanding.

One extra remark: as Anton noted instead of 32 access primitives
I could use just 2. But AFACS in threaded code each use of
Anton version would add 2 words of code (one for primitive itself,
second for parameter). And assembly code of primitive would
be a bit more complex. My version when used needs just one
word of code. And assembly should be pretty efficient, at least
as efficient as named constant or value and possibly more efficient.
Which means that when used in good way locals should lead to
smaller and more efficient code.

Maybe you are worried about used dictionary slots? AFAICS Forthers
are not shy about defining small special purpose words that
get used once or twice. Looking at extras for Mecrisp I saw
MCU definition files that define hundreds of constants, so even
for small targets people use a lot dictionary slots. So,
I call those 33 slots minor overhead.

And you may not belive, but I have reasons to think that
using locals within Forth implementation (not for style, but
when it leads to gain!) would make code smaller, likely
compensating space taken by primitives.

--
Waldek Hebisch

On 3/11/2022 2:31 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> My point was it went from 4 locals to 6 for reasons of style. It may be
>> C-style to expend resources this way (I wouldn't know)
>
> In C these days, the extra locals wouldn't expend any resources in most
> cases, since the compiler would optimize them away.

AFAIK optimizers do a better job when the code presented is already optimal.

>> But what are implications of using locals in Forth? It's this: A
>> stack-based language that cannot exist without the help of locals has
>> failed and therefore does not deserve to exist.
>
> Well, Moore used VARIABLEs instead of locals, so the pure stack vision
> already failed because of that.

Does he?

> One could simply say Forth works better
> in the presence of some impurity. Locals are another, perhaps cleaner,
> way to add the impurity.

Well, in that case I'd say you're more desperate to use Forth than I am.
No way would I tolerate using a broken language :)

dxforth <dxforth@gmail.com> writes:
> AFAIK optimizers do a better job when the code presented is already optimal.

These days optimizers work by first splitting everything out into
separate variables so that nothing is ever updated (static single
assignment or SSA form), and then recombining the variables. I have
never implemented SSA and don't understand it perfectly, but I believe
the SSA forms of the 4-local and 6-local versions of that code would be
very similar. Anton would know this much better than I do.

>> Well, Moore used VARIABLEs instead of locals,
> Does he?

I believe so. I remember looking at cmforth and some of the GA144 code
and seeing variables used that way. I also remember asking Elizabeth
about the complex multiplication example, and her replying that Moore
didn't hesitate to use CODE if it made things easier. He wasn't a
purist about staying with Forth words.

In the 1970s there just wasn't room for purity in software. Maybe APL
came closest. Lisp was born from the most purest mathematical
abstraction (lambda calculus) but its implementations were full of low
level hackery. The purest language now is Haskell but it is also full
of hacks.

On 3/11/2022 3:36 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
> [...]
>>> Well, Moore used VARIABLEs instead of locals,
>> Does he?
>
> I believe so. I remember looking at cmforth and some of the GA144 code
> and seeing variables used that way. I also remember asking Elizabeth
> about the complex multiplication example, and her replying that Moore
> didn't hesitate to use CODE if it made things easier. He wasn't a
> purist about staying with Forth words.

I've nothing against the occasional variable or CODE when it makes sense.
That's a different proposition to dumping everything to locals because
one views stack operators as either ugly or clumsy.

> In the 1970s there just wasn't room for purity in software. Maybe APL
> came closest. Lisp was born from the most purest mathematical
> abstraction (lambda calculus) but its implementations were full of low
> level hackery. The purest language now is Haskell but it is also full
> of hacks.

You've read Moore's stance on locals, which has never changed. Others
will go where their interest and thinking takes them. It's not my problem.
My interest is in discovering whether Moore's system works. I can't do
that if I'm using locals.

On Tuesday, November 1, 2022 at 10:23:07 AM UTC-4, dxforth wrote:
> On 1/11/2022 10:44 pm, Doug Hoffman wrote:
> > On Monday, October 31, 2022 at 11:46:55 PM UTC-4, dxforth wrote:
> >
> >> 'These same people' are judicious in their use of return stack.

As am I and I believe everyone else I've seen use the return stack
to stash data stack items.

> > I'm a habitual user of the return stack when it is all
> > I need (as opposed to resorting to locals).

As am I.
Did I say that all colon definitions I write use locals?

> Are you saying ... that it's your choice to extend [Forth]
> with locals?

You give me too much credit. I have never extended a Forth
to have locals. The experts that created VFXForth, SwiftForth,
iForth, Gforth, iMops, and other Forths have already done it.

> If Forth is inadequate it would mean I've wasted 40 years on
> a bum steer. Locals users too.

I don't follow that logic. How could the way I, or anyone else,
use Forth impact whether or not you have wasted your time?

-Doug

In article <tjvdqh$3vo$1@gioia.aioe.org>, <antispam@math.uni.wroc.pl> wrote:
>
>One extra remark: as Anton noted instead of 32 access primitives
>I could use just 2. But AFACS in threaded code each use of
>Anton version would add 2 words of code (one for primitive itself,
>second for parameter). And assembly code of primitive would
>be a bit more complex. My version when used needs just one
>word of code. And assembly should be pretty efficient, at least
>as efficient as named constant or value and possibly more efficient.
>Which means that when used in good way locals should lead to
>smaller and more efficient code.
>
>Maybe you are worried about used dictionary slots? AFAICS Forthers
>are not shy about defining small special purpose words that
>get used once or twice. Looking at extras for Mecrisp I saw
>MCU definition files that define hundreds of constants, so even
>for small targets people use a lot dictionary slots. So,
>I call those 33 slots minor overhead.
>
<SNIP>
>I am not sure what is troubling you here. That they are called
>"primitives"? Access primitives are very simple and very similar
>to each other, conceptually there is almost no increase in complexity.
>That they need to be coded in assembler? Albert's ciforth has about
>300 words defiend in assembler, and from glance at his code I think
>that most is longer than proposed primitives. So it seems that one
>would get 5-7% increase in amount of assembler code and to that
>matter simpler than much of the rest. Of course, you may that pride
>that you need less assember code. However, I take pragmatic view
>here: assembler is problematic because one can do tricky things
>which are hard to understand. But the primitives are so simple that
>there is not problem with understanding.

Putting the record straight:
ciforth has 300 core words, but there are only 82+3 code words.
Please point out what is not deemed a primitive in the following list:

Code definition : NOOP
Code definition : LIT
Code definition : EXECUTE
Code definition : SKIP
Code definition : 0BRANCH
Code definition : (+LOOP)
Code definition : (DO)
Code definition : (?DO)
Code definition : I
Code definition : J
Code definition : UNLOOP
Code definition : CMOVE
Code definition : MOVE
Code definition : FARMOVE
Code definition : UM*
Code definition : UM/MOD
Code definition : AND
Code definition : OR
Code definition : XOR
Code definition : INVERT
Code definition : DSP@
Code definition : DSP!
Code definition : RSP@
Code definition : RSP!
Code definition : EXIT
Code definition : CO
Code definition : >R
Code definition : R>
Code definition : RDROP
Code definition : 0=
Code definition : 0<
Code definition : +
Code definition : D+
Code definition : NEGATE
Code definition : DNEGATE
Code definition : OVER
Code definition : DROP
Code definition : NIP
Code definition : 2DROP
Code definition : SWAP
Code definition : DUP
Code definition : 2DUP
Code definition : 2SWAP
Code definition : 2OVER
Code definition : +!
Code definition : TOGGLE
Code definition : @
Code definition : C@
Code definition : 2@
Code definition : !
Code definition : C!
Code definition : 2!
Code definition : FAR@
Code definition : FAR!
Code definition : _
Code definition : $@
Code definition : ALIGNED
Code definition : -
Code definition : =
Code definition : <
Code definition : U<
Code definition : <>
Code definition : ROT
Code definition : FILL
Code definition : CORA
Code definition : $^
Code definition : $/
Code definition : $\
Code definition : S>D
Code definition : LSHIFT
Code definition : RSHIFT
Code definition : M*
Code definition : SM/REM
Code definition : 2/
Code definition : 2*
Code definition : PC@
Code definition : PC!
Code definition : PW@
Code definition : PW!
Code definition : XOS
Code definition : XOS5
Alias : BRANCH
Alias : (;)
Alias : : R@

<SNIP>
>And you may not belive, but I have reasons to think that
>using locals within Forth implementation (not for style, but
>when it leads to gain!) would make code smaller, likely
>compensating space taken by primitives.

Interesting observation, but it doesn't chime with me.
A can't think of a high level word in the kernel that
would benefit from locals.

This is about as bad at it gets (decompiled, not formatted):
: FORGET-VOC 2DUP SWAP U< IF SWAP >R >WID BEGIN DUP DUP BEGIN >LFA @
DUP R@ U< UNTIL SWAP >LFA ! >LFA @ DUP 0= UNTIL DROP R> ELSE >VFA @
VOC-LINK ! ONLY FORTH DEFINITIONS THEN ;

Note that I think nothing of tucking away something on the return
stack that I need later. IMO it beats coming up with a sensible
name for a local.

Waldek Hebisch

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

dxforth schrieb am Donnerstag, 3. November 2022 um 06:29:37 UTC+1:
> My interest is in discovering whether Moore's system works.

Did it work for himself? I gathered that he changed it all the time.

> This is about as bad at it gets (decompiled, not formatted):
> : FORGET-VOC 2DUP SWAP U< IF SWAP >R >WID BEGIN DUP DUP BEGIN >LFA @
> DUP R@ U< UNTIL SWAP >LFA ! >LFA @ DUP 0= UNTIL DROP R> ELSE >VFA @
> VOC-LINK ! ONLY FORTH DEFINITIONS THEN ;

I had to guess at the stack effects of the internal words and have no
idea what the parameters are supposed to mean, but this looks roughly
like:

: FORGET-VOC { a b }
b a u< IF
b >WID
BEGIN
BEGIN b >LFA @ { c } c a U< UNTIL
b >LFA !
b 0= UNTIL
b c a
ELSE
a b >VFA @
VOC-LINK ! ONLY FORTH DEFINITIONS
THEN ;

Actually that is probably wrong since there is a different amount of
stuff on the stack depending on which branch of the IF is taken.
Some comments and stack diagrams would surely help.

On Thursday, November 3, 2022 at 11:40:10 AM UTC+1, Doug Hoffman wrote:
> As am I and I believe everyone else I've seen use the return stack
> to stash data stack items.
That's only half the story. I learned this trick from the guy who wrote the FIG
editor - you don't randomly place stuff there, you place the stuff that is either
constant or almost constant.

So - you triage your parameters. Those who change a LOT go on the
data stack and those who (barely) change go on the return stack.
In 4tH, you have R@, R'@ and R"@. And then it starts to make even MORE
sense. You can also map those with I, I' and J - with NO overhead.

The TORS contains the stuff that barely changes., while R'@ and R"@ are
pure constants.

> Did I say that all colon definitions I write use locals?
CONCAT didn't - I loved it. You see, you are perfectly capable to do better ;-)

I understand the sentiment about "throwing away the experience". Forth
not only made me a better programmer, it also forced me to delve deeper
in an algorithm in order to REALLY understand it. LOCALs allow a much
shallower way of implementing it. It also allows me to waste resources -
simply because I can away with it.

If you'd asked me 10 - 20 years ago to make a preprocessor that exceeds
M4 I wouldn't have known where to begin. In Forth, it grew organically. And
at some moment I thought "Wow, did I really make this?"

I also wrote what must be one of the smallest DBMSes (400 lines or so). Again,
a task so daunting in any other languages I probably never would have attempted.

And all this because every single element is forced to be so small, it seems
almost trivial. And all there is is the flow of data through the stack. Every tiny
mistake is punished by a crash. That will teach you discipline.

There is no such mechanism at work when using locals. All words are brute
connected by an interface that is the stack frame. And instead of flowing
almost invisibly through the program there is this point where data becomes
painfully explicit - like C.

It is not a matter of passing parameters in a different way, it's a way of thinking
that is radically different. It is that that newbies fail to comprehend - and often
even fail to master. That's why they drop out.

IMHO it isn't a different way to pass and handle data, it is a different and way of
thinking and designing. And LOCALs aren't about "making things easier", but
a concession to make things workable for lesser gods and sloppy programmers.

I have a lib that does LOCALs - but I never use it. I have embraced this other
way of approaching the problem - and it works for me. I don't see any use in
dropping it (and yes, at times I wrestle with the stack as well) and trade it for
an IMHO inferior way of converting an idea into working code.

Hans Bezemer

On Thursday, November 3, 2022 at 7:41:55 PM UTC+1, the.bee...@gmail.com wrote:
[..]
> and trade it for an IMHO inferior way of converting an idea into working code.

It was demonstrated to you (e.g., by Peter Fälth) that it doesn't matter
how you write the Forth source, it converts to the same code, given a
reasonable compiler.

-marcel

On Thursday, November 3, 2022 at 11:34:23 PM UTC+1, Marcel Hendrix wrote:
> On Thursday, November 3, 2022 at 7:41:55 PM UTC+1, the.bee...@gmail.com wrote:
> [..]
If you're talking about a mechanical proces like code generation
You're missing the entire point I'm trying to make.

Hans Bezemer
> > and trade it for an IMHO inferior way of converting an idea into working code.
> It was demonstrated to you (e.g., by Peter Fälth) that it doesn't matter
> how you write the Forth source, it converts to the same code, given a
> reasonable compiler.
>
> -marcel

On 4/11/2022 9:34 am, Marcel Hendrix wrote:
> On Thursday, November 3, 2022 at 7:41:55 PM UTC+1, the.bee...@gmail.com wrote:
> [..]
>> and trade it for an IMHO inferior way of converting an idea into working code.
>
> It was demonstrated to you (e.g., by Peter Fälth) that it doesn't matter
> how you write the Forth source, it converts to the same code, given a
> reasonable compiler.

So now one is dependent on "a reasonable compiler". GCC here we come.

dxforth <dxforth@gmail.com> writes:
> So now one is dependent on "a reasonable compiler". GCC here we come.

You don't have to depend on a compiler at all, but without one, you're
running interpreted Forth which is maybe 10x slower. That 10x is not
too bad, compared to the 50x or more slowdown you get from Python. With
a rudimentary compiler you might get 3x instead of 10x.

Maybe coding style (locals or whatever) can change the 10x to 15x or
vice versa. If you care about that, using a compiler sounds like a
better way to recover the missed speed than warping your mind trying to
optimize interpreted code at the source level. And as usual, if you
have to optimize at all, it is likely to just be in a few hot spots of
the program.

Remember too that even an almost minimal Forth target these days
(Raspberry Pi Pico) is probably 100x faster than the 16 bit
minicomputers where Forth originated. That gives you a lot of breathing
space. There is no need for 3+length dictionaries any more, and we
can also use more relaxed and expressive coding styles.

On 3/11/2022 9:40 pm, Doug Hoffman wrote:
> On Tuesday, November 1, 2022 at 10:23:07 AM UTC-4, dxforth wrote:
>> ...
>> If Forth is inadequate it would mean I've wasted 40 years on
>> a bum steer. Locals users too.
>
> I don't follow that logic. How could the way I, or anyone else,
> use Forth impact whether or not you have wasted your time?

How else to describe a language that folks say they can't use unless
locals are added.

dxforth <dxforth@gmail.com> writes:
> How else to describe a language that folks say they can't use unless
> locals are added.

No software is ever finished until its last user is dead. So all
software is inadequate in one way or another. We do what we can in
order to get by anyway.

On Thursday, 3 November 2022 at 23:34:23 UTC+1, Marcel Hendrix wrote:
> On Thursday, November 3, 2022 at 7:41:55 PM UTC+1, the.bee...@gmail.com wrote:
> [..]
> > and trade it for an IMHO inferior way of converting an idea into working code.
> It was demonstrated to you (e.g., by Peter Fälth) that it doesn't matter
> how you write the Forth source, it converts to the same code, given a
> reasonable compiler.
>
> -marcel

But only if you have the right example code to compile!
In this case my code generator produces the same result with locals or without.
When you have a break in a basic block ( a call, a controlflow point) the locals
needs to be placed in a known place, in the case of lxf the return stack.
This generates extra code.
The problem is the way locals are specified, they have a scope of the whole
word, they are released just at the end of the definition.
Stack parameters have instead a dynamic scope, they are duped, or droped or
consumed as arguments to a word as decided by the programmer.

Of course a multipass compiler could determine the scope of each local and
improve the code generation. Lxf is just a simple 1 pass compiler. The reason
you can make code generation for locals look good with lxf is that they are
implementedto rest on the return stack. I put in some effort to get a good
code generation for the R-stack use. The locals was for free after that.

In my own Forth programming I do not use locals. I have not seen the need
for them and I do not like the way they are specified to look like a comment!
In lxf I have instead another feature n LBUFFER: <name> that reserves n
byte on the return stack that can be accessed with ! @ at <name>. Just like a
variable. This is useful to pass structures to systems call for example.

Best Regards
Peter

On 4/11/2022 4:38 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> How else to describe a language that folks say they can't use unless
>> locals are added.
>
> No software is ever finished until its last user is dead. So all
> software is inadequate in one way or another. We do what we can in
> order to get by anyway.

Oh, I'd say organized Forth is absolutely dead. I agree with your
last line.

P Falth schrieb am Freitag, 4. November 2022 um 07:46:36 UTC+1:
> In my own Forth programming I do not use locals. I have not seen the need
> for them and I do not like the way they are specified to look like a comment!
> In lxf I have instead another feature n LBUFFER: <name> that reserves n
> byte on the return stack that can be accessed with ! @ at <name>. Just like a
> variable. This is useful to pass structures to systems call for example.

These are good points:
a) when there is no need, then there is no use case
b) standard Forth locals syntax looks strange
c) standard Forth locals are too limited, practical applications often have to deal
with data objects like structures and (dynamic) strings/arrays; at least fp-locals
should be there

As long as one does only "scratch on the ground" i.e. can solve one's task with
some standard words and only integer addresses and numbers as arguments,
locals wouldn't pay their rent.

I am old school myseld, and by myself I use a lot of paper and pencil to understand/tune
data structures and algorithms before I fire up the computer. Then I am rather sure
to have got the thinking right and am happy to leave as much bit&byte lifting as possible
to the compiler. It is a waste of programmer's time to burden him with syntax mistakes.

Whether manual deep factoring is good programming or not, is a matter of personal
likes and experience. Moore and his acolytes live with their experience. There
are good cases where deep factoring works, there are many cases where deep
factoring would break data flows and algorithms apart. Always keep in mind that
code needs to stay maintainable, particularly when you work in a team, and it
must not require solving jigsaw code puzzles.

In article <87tu3gc77i.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>> This is about as bad at it gets (decompiled, not formatted):
>> : FORGET-VOC 2DUP SWAP U< IF SWAP >R >WID BEGIN DUP DUP BEGIN >LFA @
>> DUP R@ U< UNTIL SWAP >LFA ! >LFA @ DUP 0= UNTIL DROP R> ELSE >VFA @
>> VOC-LINK ! ONLY FORTH DEFINITIONS THEN ;
>
>I had to guess at the stack effects of the internal words and have no
>idea what the parameters are supposed to mean, but this looks roughly
>like:
>
> : FORGET-VOC { a b }
> b a u< IF
> b >WID
> BEGIN
> BEGIN b >LFA @ { c } c a U< UNTIL
> b >LFA !
> b 0= UNTIL
> b c a
> ELSE
> a b >VFA @
> VOC-LINK ! ONLY FORTH DEFINITIONS
> THEN ;
>
>Actually that is probably wrong since there is a different amount of
>stuff on the stack depending on which branch of the IF is taken.
>Some comments and stack diagrams would surely help.

It was not intended to be analysed, but to show how approximately
the most complicated words look. Probably the decompiler had
the control structures wrong hence the return stack imbalance.
In actual source code it look (first part shown).

_HEADER({FORGET-VOC},{FORGV},{DOCOL})
DC TDUP
DC SWAP
DC ULESS
_0BRANCH(FORGV1)
_C{ Forget part of contents.}
DC SWAP
DC TOR
DC TWID
FORGV0:
....

Remember the kernel is code in assembler.

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

On Thursday, November 3, 2022 at 4:36:56 AM UTC, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> > AFAIK optimizers do a better job when the code presented is already optimal.
> These days optimizers work by first splitting everything out into
> separate variables so that nothing is ever updated (static single
> assignment or SSA form), and then recombining the variables. I have
> never implemented SSA and don't understand it perfectly, but I believe
> the SSA forms of the 4-local and 6-local versions of that code would be
> very similar. Anton would know this much better than I do.
> >> Well, Moore used VARIABLEs instead of locals,
> > Does he?
>
> I believe so. I remember looking at cmforth and some of the GA144 code
> and seeing variables used that way. I also remember asking Elizabeth
> about the complex multiplication example, and her replying that Moore
> didn't hesitate to use CODE if it made things easier. He wasn't a
> purist about staying with Forth words.
>
> In the 1970s there just wasn't room for purity in software. Maybe APL
> came closest. Lisp was born from the most purest mathematical
> abstraction (lambda calculus) but its implementations were full of low
> level hackery. The purest language now is Haskell but it is also full
> of hacks.

I have wondered about that myself - hacks in the implementation of
'pure' languages. Thanks for these snippets.

On 4/11/2022 9:47 pm, albert wrote:
> In article <87tu3gc77i.fsf@nightsong.com>,
> Paul Rubin <no.email@nospam.invalid> wrote:
>>> This is about as bad at it gets (decompiled, not formatted):
>>> : FORGET-VOC 2DUP SWAP U< IF SWAP >R >WID BEGIN DUP DUP BEGIN >LFA @
>>> DUP R@ U< UNTIL SWAP >LFA ! >LFA @ DUP 0= UNTIL DROP R> ELSE >VFA @
>>> VOC-LINK ! ONLY FORTH DEFINITIONS THEN ;
>>
>> I had to guess at the stack effects of the internal words and have no
>> idea what the parameters are supposed to mean, but this looks roughly
>> like:
>>
>> : FORGET-VOC { a b }
>> b a u< IF
>> b >WID
>> BEGIN
>> BEGIN b >LFA @ { c } c a U< UNTIL
>> b >LFA !
>> b 0= UNTIL
>> b c a
>> ELSE
>> a b >VFA @
>> VOC-LINK ! ONLY FORTH DEFINITIONS
>> THEN ;
>>
>> Actually that is probably wrong since there is a different amount of
>> stuff on the stack depending on which branch of the IF is taken.
>> Some comments and stack diagrams would surely help.
>
> It was not intended to be analysed, but to show how approximately
> the most complicated words look.

Fig-Forth's FORGET was simple but it broke once vocabs were added.
Consequently the code to trim dictionaries back to a usable state
became ever more complicated as dictionaries became more complicated.
Whether it was worth it is debatable but that's how it evolved.
This is for a single-thread, split dictionary with separated headers:

: (forget) ( nfa dps dp -- )
dp 2! >r \ starting maximums
voc-link begin \ trim vocs > nfa
@ dup cell- @ cell+ \ vocab nfa
r@ u<
until dup voc-link !
begin
dup cell- @ \ scan remaining vocs
dup h@ begin
dup r@ u< 0= \ for each word >= nfa
while
-alias if \ not an alias
dup name> \ get its xt
xdp tuck @
umin swap ! \ trim dict
then
n>name
repeat
swap h!
@ ?dup 0= \ until all vocs done
until
r> dup dph !
(idph) @ u< if \ below fence?
protect \ fix bootup values
then
prunes ; \ run prunes list

: EMPTY ( -- )
forth definitions (idph) @ (idp) 2@ (forget) ;

: FORGET ( "name" -- )
get-current context ! name? -alias 0= abort" is alias"
swap limit over u< if dp @ else dps @ swap then (forget) ;

On 4/11/2022 12:06 am, minf...@arcor.de wrote:
> dxforth schrieb am Donnerstag, 3. November 2022 um 06:29:37 UTC+1:
>> My interest is in discovering whether Moore's system works.
>
> Did it work for himself? I gathered that he changed it all the time.

Not the basics AFAIK. No mega-compiler, no locals, no creeping complexity.
It was those who came after that did all that for one reason or another.

On Friday, November 4, 2022 at 6:46:23 PM UTC-5, dxforth wrote:

> Fig-Forth's FORGET was simple but it broke once vocabs were added.

Using Fig and oldest simple vocabularies. Upgraded FORGET to update
word lists in all existing vocabularies. Didn't bother to fix any
broken VOC-LINK chain; however, I did fence vocabularies when created.
If some FORGET includes a vocabulary, fence will alert and the chain
can be fixed manually. Never had to; not a problem I expect to deal
with.
--
me

dxforth <dxforth@gmail.com> writes:
> Oh, I'd say organized Forth is absolutely dead. I agree with your
> last line.

Well, what was organized Forth trying to do when it was alive? Was it
trying to crank out working code by hook or by crook, or was it trying
to pursue a vision of stack combinator purity? If it was merely trying
to crank out code, I still think locals help with that, and haven't seen
persuasive reasoning to the contrary. If it was trying to pursue purity
then obviously locals are a no-no, ok fine. It may make me a philistine
but I don't think the vision has held up that well. Lambda calculus has
held up a lot better.

In Ting's writings I see both approaches. In Jeff Fox's, I can't always
tell what he is getting at. And Moore sometimes seems to be operating
in a different world than the rest of us.