On 5/11/2022 2:51 pm, Paul Rubin wrote:
> 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.

According to Forth Inc it was quite successful in the Moore era. Can't
say the same for the standardization efforts which was language created
by committee.

> And Moore sometimes seems to be operating
> in a different world than the rest of us.

He did say he didn't create Forth for you. What you do with it is your
business.

On Saturday, November 5, 2022 at 7:50:11 AM UTC+1, dxforth wrote:
[..]
> He did say he didn't create Forth for you. What you do with it is your
> business.

That effectively kills all discussion. What does it matter then
what he said, or what you or I say?

-marcel

On 5/11/2022 9:21 pm, Marcel Hendrix wrote:
> On Saturday, November 5, 2022 at 7:50:11 AM UTC+1, dxforth wrote:
> [..]
>> He did say he didn't create Forth for you. What you do with it is your
>> business.
>
> That effectively kills all discussion. What does it matter then
> what he said, or what you or I say?

ISTM Paul did that when he said Moore was "operating in a different
world to the rest of us". Paul has all but said that he won't use
Forth unless he can use locals. What can one say to that? It would
appear ANS TC was similarly pressured:

A.13

"It has been further argued that users who have elected to become
dependent on locals tend to be locked into a single vendor and have
little motivation to join the group that it is hoped will broadly
accept ANS Forth unless the Standard addresses their problems."

There's certainly no "purity" there - just the promise of supporters
for ANS if the TC acquiesced.

dxforth <dxforth@gmail.com> writes:
> ISTM Paul did that when he said Moore was "operating in a different
> world to the rest of us". Paul has all but said that he won't use
> Forth unless he can use locals.

I haven't said that, I've said that I find locals make Forth easier for
me to use. I find Forth difficult compared with other languages even
with locals, but I use it for some things anyway because it is
interesting.

> There's certainly no "purity" there - just the promise of supporters
> for ANS if the TC acquiesced.

The TC was an industry group, I thought. As far as I can tell, the
opposition to locals is more from an artistic perspective than an
engineering one. I'm fine with doing stuff for artistic reasons, but I
had imagined that the TC's audience was more concerned with
practicality.

On 6/11/2022 8:27 am, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> ISTM Paul did that when he said Moore was "operating in a different
>> world to the rest of us". Paul has all but said that he won't use
>> Forth unless he can use locals.
>
> I haven't said that, I've said that I find locals make Forth easier for
> me to use. I find Forth difficult compared with other languages even
> with locals, but I use it for some things anyway because it is
> interesting.

Just about every introductory text to Forth says to minimize variables
and your response is you find it too difficult.

>> There's certainly no "purity" there - just the promise of supporters
>> for ANS if the TC acquiesced.
>
> The TC was an industry group, I thought. As far as I can tell, the
> opposition to locals is more from an artistic perspective than an
> engineering one.

RM:
Do you consider yourself a scientist, an engineer, an artist or a craftsman?

CM:
I put ‘engineer’ in the box on forms. Sometimes I put ‘computer engineer’
in a big box.

> I'm fine with doing stuff for artistic reasons, but I
> had imagined that the TC's audience was more concerned with
> practicality.

Looks to me they were more interested in numbers. Not that it got them
many 'happy campers' given the ensuing furore of type of locals. Such
is politics.

dxforth <dxforth@gmail.com> writes:
> Just about every introductory text to Forth says to minimize variables
> and your response is you find it too difficult.

If you mean VARIABLEs then of course I want to minimize those. I'm not
trying to be a wise-acre but I have thought of VARIABLEs and locals as
distinct things. Locals get rid of the need for (some) variables.

> Looks to me they [the TC] were more interested in numbers. Not that
> it got them many 'happy campers' given the ensuing furore of type of
> locals. Such is politics.

I don't see the downside. The compromise basically was to add (LOCAL)
to implementations that didn't already have it. That's a new primitive,
but the other stuff can be done in terms of it using Forth words. I
hope that implementing (LOCAL) didn't cause anyone too much pain. Once
it was there, nobody was required to use it, but it was available for
those who wanted it.

On 6/11/2022 5:08 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Just about every introductory text to Forth says to minimize variables
>> and your response is you find it too difficult.
>
> If you mean VARIABLEs then of course I want to minimize those. I'm not
> trying to be a wise-acre but I have thought of VARIABLEs and locals as
> distinct things.

That may be true of other languages which rely on locals as a mechanism
for parameter passing. It's not true of Forth which uses the stack for
that. In Forth, locals are just variables to be avoided.

>> Looks to me they [the TC] were more interested in numbers. Not that
>> it got them many 'happy campers' given the ensuing furore of type of
>> locals. Such is politics.
>
> I don't see the downside. The compromise basically was to add (LOCAL)
> to implementations that didn't already have it. That's a new primitive,
> but the other stuff can be done in terms of it using Forth words. I
> hope that implementing (LOCAL) didn't cause anyone too much pain. Once
> it was there, nobody was required to use it, but it was available for
> those who wanted it.

Yes - for those who hadn't grasped the difference between Forth and other
languages. I'll admit it - I was one of them. The mere inclusion of locals
in ANS-Forth had me fooled. For quite a long time I thought locals were
a part of Forth - until a chance reading of a post by Jeff Fox.

On Sunday, November 6, 2022 at 9:47:16 AM UTC+1, dxforth wrote:
> On 6/11/2022 5:08 pm, Paul Rubin wrote:
> > dxforth <dxf...@gmail.com> writes:
> Yes - for those who hadn't grasped the difference between Forth and other
> languages. I'll admit it - I was one of them. The mere inclusion of locals
> in ANS-Forth had me fooled. For quite a long time I thought locals were
> a part of Forth - until a chance reading of a post by Jeff Fox.

Did any of Jeff's Forth code get archived somewhere? I never was able
to find anything he actually wrote himself.

-marcel

On 7/11/2022 12:15 am, Marcel Hendrix wrote:
> On Sunday, November 6, 2022 at 9:47:16 AM UTC+1, dxforth wrote:
>> On 6/11/2022 5:08 pm, Paul Rubin wrote:
>>> dxforth <dxf...@gmail.com> writes:
>> Yes - for those who hadn't grasped the difference between Forth and other
>> languages. I'll admit it - I was one of them. The mere inclusion of locals
>> in ANS-Forth had me fooled. For quite a long time I thought locals were
>> a part of Forth - until a chance reading of a post by Jeff Fox.
>
> Did any of Jeff's Forth code get archived somewhere? I never was able
> to find anything he actually wrote himself.

There's LZ-4TH.ZIP and ISING.ARC in the Taygeta forth archives from the
late 80's. From his later period there were his chip emulators which should
be available from his web pages. Like Moore, very little application code
seems to have made it into the public domain. I suppose one could say the
same of other commercial developers...

On 7/11/2022 12:15 am, Marcel Hendrix wrote:
> On Sunday, November 6, 2022 at 9:47:16 AM UTC+1, dxforth wrote:
>> On 6/11/2022 5:08 pm, Paul Rubin wrote:
>>> dxforth <dxf...@gmail.com> writes:
>> Yes - for those who hadn't grasped the difference between Forth and other
>> languages. I'll admit it - I was one of them. The mere inclusion of locals
>> in ANS-Forth had me fooled. For quite a long time I thought locals were
>> a part of Forth - until a chance reading of a post by Jeff Fox.
>
> Did any of Jeff's Forth code get archived somewhere? I never was able
> to find anything he actually wrote himself.

If it's 'local-less' code that you want to see, I believe there's plenty
of that about already. SwiftForth sources contain relatively few instances
of locals, often around parameter-heavy API calls. According to an old
post by Elizabeth I happened to see, SwiftX doesn't support locals at all.

dxforth <dxforth@gmail.com> writes:
> For quite a long time I thought locals were a part of Forth - until a
> chance reading of a post by Jeff Fox.

It might have been this (3 parts): http://www.ultratechnology.com/forth.htm

A very interesting article. I read it some years ago (it's one of the
things that got/kept me interested in Forth) and I just re-read it. It
contains wisdom that can be learned from but that I think shouldn't be
taken too literally.

Among other ideas in the article:

- Optimizing compilers are too complicated. It's better for your
compiler/interpreter to make slow code just to make the implementation
simpler, because you if your applications are minimalistic enough,
they will run fast anyway.

- Blocks instead of files. I thought this one had resolved some decades ago.

- No floating point arithmetic. Used scaled integers instead, and
concoct your own measurement units in your app to make the scaled
arithmetic work out efficiently. He quotes Chuck regarding OKAD:

I originally chose mV for internal units. But using 6400 mV = 4096
units replaces a divide with a shift and requires only 2 multiplies
per transistor.

- Tail recursion instead of loops. Ok, Haskellers like this too. But I
thought someone was complaining about it here on clf just recently.

- "Face the problem, think about it until you can picture the solution
as about 1K of code or less. Until then you don't really understand it."

- Eliminate SMUDGE so any reference to an existing word becomes a recursive
call. If you want to redefine the word, think of a new name for it.
(I'm not sure I understand this bit--it's in the part about cmForth).

- Late binding is slow, based on implementating with S" DUP" EVALUATE
I mean who does that? Late binding to most of us basically means DEFER.

- Say X X X X X instead of using a loop. CASE is an abomination. Do
lots of your application at compile time instead of run time, to keep
stuff out of the final executable. I thought most compilers did that

- "Removing wordlists is also one of the techniques that greatly
simplified other words in the system and allowed Chuck to build a 1K
sized Forth that can compile applications in a click."

- replace ! and @ with A! and A@, having an A register in the virtual
machine that also has an autoincrement mode

Some of this stuff is hardware oriented, some makes sense, and some just
makes me smile. Got a distributed company and want to run your own
payroll? Your software will have to deal with the tax codes of 100s of
overlapping jurisdictions. Good luck fitting that in 1K of code.
Software defined radio, video codec, etc.? Same thing. Connect your
computer to the internet? A 1K TCP stack might be sort of possible, but
TLS is probably not doable in that. Want it to have wifi or bluetooth?
Don't get me started.

The article has no mention of multitasking (Forth's traditional
cooperative multitasker is breathtakingly simple and is another thing
that impressed me about Forth). I had thought Polyforth was done by
Chuck but maybe I'm wrong.

There's lots more, I've only scratched the surface. So I don't
understand why it is that locals in particular draw ire while everything
else skates by.

Somewhere in the talk of using factoring instead of locals, the need to
name the factors seems to have forgotten. If avoiding thinking up names
for the locals speaks in favor of stack juggling, the similar need to
name small factors shouldn't be ignored. (I usually name factors FOO.1,
FOO.2 etc. though).

Paul Rubin schrieb am Montag, 7. November 2022 um 05:41:54 UTC+1:
> dxforth <dxf...@gmail.com> writes:
> > For quite a long time I thought locals were a part of Forth - until a
> > chance reading of a post by Jeff Fox.
> It might have been this (3 parts): http://www.ultratechnology.com/forth.htm
> ...
> There's lots more, I've only scratched the surface. So I don't
> understand why it is that locals in particular draw ire while everything
> else skates by.

People love hot topics, particularly the heaters love them. Yet it is only
old stuff warmed up. Couple of years ago it had been OOP etc.

Those recommendations by Fox/Moore read like coming from a
(macro) assembler perspective. No surprise there. Forth can be a powerful
macro assembler.

But when you have to handle fat data objects in your embedded systems
you need more adequate tooling. Since Forth can be extended easily,
why not tool up Forth with what is needed.

AFAIU exactly THIS was Moore's philosophy. I guess he would have laughed
at "language purity" arguments.

Paul Rubin <no.email@nospam.invalid> writes:
>It might have been this (3 parts): http://www.ultratechnology.com/forth.htm
....
>Among other ideas in the article:
>
>- Optimizing compilers are too complicated. It's better for your
> compiler/interpreter to make slow code just to make the implementation
> simpler, because you if your applications are minimalistic enough,
> they will run fast anyway.

One interesting aspect of our recent work in Gforth is that a number
of individually simple features synergize to provide optimizations I
had not foreseen:

1) The compile-time literal stack (intended for constant folding)

2) SET-OPTIMIZER that can set the implementation of COMPILE, for each
word individually.

E.g., in the general case +LOOP requires relatively complex and slow
checking of whether the loop should continue or end (in the absence of
an overflow flag). /LOOP is faster, but works only for positive
operands. In the typical case the operand is a constant. So, with
the literal stack we can check if there is a constant operand, and
whether it is positive, and if so, optimize +LOOP to /LOOP:

\ optimize +loop (not quite folding)
: replace-(+loop) ( xt1 -- xt2 )
case
['] (+loop) of ['] (/loop)# endof
['] (+loop)-lp+!# of ['] (/loop)#-lp+!# endof
-21 throw
endcase ;

: (+loop)-optimizer ( xt -- )
lits# 1 u>= if
lits> dup 0> if
swap replace-(+loop) peephole-compile, , exit then
>lits then
peephole-compile, ;

' (+loop)-optimizer optimizes (+loop)
' (+loop)-optimizer optimizes (+loop)-lp+!#

OPTIMIZES is like SET-OPTIMIZER, but applies to the word in the input
stream, not the most recently defined word. This actually optimizes
LIT n (+LOOP) to (/LOOP)# n, and we don't have /LOOP.

Of course, one might say that these kinds of optimizations are too
complicated, but I think that they are individually
simple and understandable, so are nice.

>- Blocks instead of files. I thought this one had resolved some decades ago.

The fans of blocks don't try to proselytize on clf anymore, that's
all.

>- Tail recursion instead of loops. Ok, Haskellers like this too. But I
> thought someone was complaining about it here on clf just recently.

People who perform return-address manipulation need to know what
pushes return addresses and what does not. If you have written such
code for classical Forth, where every call pushes a return address, it
is likely to break on a Forth that performs tail-call elimination. If
you have written such code for a Forth system that performs tail-call
elimination, it depends on the particular way that tail-call
elimination is implemented.

>- Eliminate SMUDGE so any reference to an existing word becomes a recursive
> call. If you want to redefine the word, think of a new name for it.
> (I'm not sure I understand this bit--it's in the part about cmForth).

This has to do with using tail recursion for loops. In classical
Forth, if you write

: foo ... if ... foo then ;

it complains that FOO is undefined (or calls an older definition of
FOO if there is one).

>- Late binding is slow, based on implementating with S" DUP" EVALUATE
> I mean who does that?

Some people have been proposing to use EVALUATE im immediate words to
produce STATE-smart macros (that also have lots of other dependencies
beyond STATE). I recommend avoiding such practices.

> Late binding to most of us basically means DEFER.

Well, it's not late name binding, but it can be used for things like
mutual recursion for which programmers in languages with late name
binding like Lisp and Postscript use late name binding.

>- Say X X X X X instead of using a loop. CASE is an abomination. Do
> lots of your application at compile time instead of run time, to keep
> stuff out of the final executable. I thought most compilers did that

I am not aware of Forth compilers that unroll loops. And in any case,
Jeff Fox would consider that to be a case of a too complicated
compiler.

>Connect your
>computer to the internet? A 1K TCP stack might be sort of possible, but
>TLS is probably not doable in that.

The traditionalist answer has been to get rid of the overcomplicated
specification, and redesign based on the requirements. Bernd Paysan
has done that in net2o, and the parts that replace TCP and TLS have
been done for several years. He does not provide the classical
network API to make net2o a drop-in replacement for TCP and TLS; maybe
that would be too complicated, too. Instead, he has gone on to
implement additional functionality (what's usually in a browser).

>There's lots more, I've only scratched the surface. So I don't
>understand why it is that locals in particular draw ire while everything
>else skates by.

That's an interesting question. Why did Andrew Haley disparage
recognizers that require relatively little code, while accepting
without comment the SUBSTITUTE proposal that requires much more code.
I think I asked him that, and his answer was along the lines that the
text interpreter (for which the recognizer proposal would standardize
a part) is a fundamental part of Forth, while SUBSTITUTE is
peripheral. Maybe the reason is similar for stack vs. locals.

There may also be the usual elitism at work. Some programmers brought
up the hard way think of themselves as elite because of that, and
resent locals which, if accepted, make all their elite competences
appear worthless. You can also see the same effect in C where there
are people who viciously defend undefined behaviour, believe in
resulting optimization effects of mythical dimensions, and declare
that anybody who thinks differently should switch to a lesser
programming language.

- 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: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

In article <87r0yf1ilv.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>dxforth <dxforth@gmail.com> writes:
>> For quite a long time I thought locals were a part of Forth - until a
>> chance reading of a post by Jeff Fox.
>
>It might have been this (3 parts): http://www.ultratechnology.com/forth.htm
>
>A very interesting article. I read it some years ago (it's one of the
>things that got/kept me interested in Forth) and I just re-read it. It
>contains wisdom that can be learned from but that I think shouldn't be
>taken too literally.
>
>Among other ideas in the article:
>
>- Optimizing compilers are too complicated. It's better for your
> compiler/interpreter to make slow code just to make the implementation
> simpler, because you if your applications are minimalistic enough,
> they will run fast anyway.

I only partly agree with this. The basic compiler should be as simple
as possible. Then when/if you need speed you haven't to content with
tricks that get in the way. I succeeded in an experimental optimiser
with ciforth that can optimise the prime counting Byte benchmark
to the level of Swiftforth or MEP-forth.

>
>- Blocks instead of files. I thought this one had resolved some decades ago.

That opinion have overlooked some opportunities. The library that comes
with ciforth is a block file. It provides a nice granularity, features
conditional compilation.The cc allows booting, msdos, MS-windows, linux,
apple 16/32/64 share the same library.
Normally ciforth slurps its source file. If you insist having line
buffered i/o the block buffers serve double duty as file input buffers.

>
>- No floating point arithmetic. Used scaled integers instead, and
> concoct your own measurement units in your app to make the scaled
> I originally chose mV for internal units. But using 6400 mV = 4096
> units replaces a divide with a shift and requires only 2 multiplies
> per transistor.

If you have an i86 with a floating point stack implementation fp
is a small effort. It can come in handy.

>
>- Tail recursion instead of loops. Ok, Haskellers like this too. But I
> thought someone was complaining about it here on clf just recently.
>
>- "Face the problem, think about it until you can picture the solution
> as about 1K of code or less. Until then you don't really understand it."

Exaggeration. Most of my Forth solutions to euler problems (300+)
qualify though.

>
>- Eliminate SMUDGE so any reference to an existing word becomes a recursive
> call. If you want to redefine the word, think of a new name for it.
> (I'm not sure I understand this bit--it's in the part about cmForth).

I'm redefining words as in
: difficult .... ;
\ : difficult .s difficult .s ;
all the time.
You need to forego this.
This is to advocate recursion over looping, and then you've got
do tail-optimisation for reason of return stack overflow.
Well I call this sectarian drivel.

>
>- Late binding is slow, based on implementating with S" DUP" EVALUATE
> I mean who does that? Late binding to most of us basically means DEFER.

Remember FORGET-VOC the other day.

The phrase `` >NFA @ @ '' is incomprehensible.
: nt>namelength ">NFA @ @" EVALUATE ; IMMEDIATE
I contend that the :I that automatically inlines has no such
disadvantages.
:I nt>namelength >NFA @ @ ;
Note >R and I can be used in these inline macro's.

>
>- Say X X X X X instead of using a loop. CASE is an abomination. Do
> lots of your application at compile time instead of run time, to keep
> stuff out of the final executable. I thought most compilers did that

The example is of course crc. Most Forth implementations calculate
the speed up tables at compile time. A c-implementation has to choose
between an initialisation calculation at run time, or a two stage process
where tables are included.
Regards CASE. I think it is superfluous. At least the c switch
construction allows baffling optimisations.

>
>- "Removing wordlists is also one of the techniques that greatly
> simplified other words in the system and allowed Chuck to build a 1K
> sized Forth that can compile applications in a click."
In the Gbyte area I am a proponent of wordlists. It is not
complicated per se, and it opens a wealth of possibilities
such as sealing user commands, temporarily loading and trimming
an assembler etc.

>
>- replace ! and @ with A! and A@, having an A register in the virtual
> machine that also has an autoincrement mode

This is micro-optimisation directed at the hardware at hand.

>
>Some of this stuff is hardware oriented, some makes sense, and some just
>makes me smile. Got a distributed company and want to run your own
>payroll? Your software will have to deal with the tax codes of 100s of
>overlapping jurisdictions. Good luck fitting that in 1K of code.
>Software defined radio, video codec, etc.? Same thing. Connect your
>computer to the internet? A 1K TCP stack might be sort of possible, but
>TLS is probably not doable in that. Want it to have wifi or bluetooth?
>Don't get me started.

You are of course right. I'd like to have seen the rebuttal of Jeff Fox
>
>The article has no mention of multitasking (Forth's traditional
>cooperative multitasker is breathtakingly simple and is another thing
>that impressed me about Forth). I had thought Polyforth was done by
>Chuck but maybe I'm wrong.
>
>There's lots more, I've only scratched the surface. So I don't
>understand why it is that locals in particular draw ire while everything
>else skates by.
>
>Somewhere in the talk of using factoring instead of locals, the need to
>name the factors seems to have forgotten. If avoiding thinking up names
>for the locals speaks in favor of stack juggling, the similar need to
>name small factors shouldn't be ignored. (I usually name factors FOO.1,
>FOO.2 etc. though).

Valid point. I see professor Veltman's software package schoonschip
and he ended naming files after his daughters.
Probably it is asking to much to find a language prowess like
Bob Dylan's under software developers.

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

In article <2022Nov7.084232@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>That's an interesting question. Why did Andrew Haley disparage
>recognizers that require relatively little code, while accepting
>without comment the SUBSTITUTE proposal that requires much more code.
>I think I asked him that, and his answer was along the lines that the
>text interpreter (for which the recognizer proposal would standardize
>a part) is a fundamental part of Forth, while SUBSTITUTE is
>peripheral. Maybe the reason is similar for stack vs. locals.

The poor man's solution of recognizers (PREFIX) comes at the
cost of two lines in the kernel. And it can't be disparaged for
the same reason as adding SUBSTITUTE.
The impact on the text interpreter is invisible.

>
>- anton

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 7/11/2022 6:42 pm, Anton Ertl wrote:
>
> There may also be the usual elitism at work. Some programmers brought
> up the hard way think of themselves as elite because of that, and
> resent locals which, if accepted, make all their elite competences
> appear worthless.

I agree there's no elitism in bringing locals to a language whose creator
expressly refutes them. More a beginner's mistake. Elitism is when they
refuse to accept 'No' because they know better.

On Monday, November 7, 2022 at 9:25:46 AM UTC+1, minf...@arcor.de wrote:
> Paul Rubin schrieb am Montag, 7. November 2022 um 05:41:54 UTC+1:
> > dxforth <dxf...@gmail.com> writes:
> > > For quite a long time I thought locals were a part of Forth - until a
> > > chance reading of a post by Jeff Fox.
> > It might have been this (3 parts): http://www.ultratechnology.com/forth.htm
> > ...
> > There's lots more, I've only scratched the surface. So I don't
> > understand why it is that locals in particular draw ire while everything
> > else skates by.
> People love hot topics, particularly the heaters love them. Yet it is only
> old stuff warmed up. Couple of years ago it had been OOP etc.
>
> Those recommendations by Fox/Moore read like coming from a
> (macro) assembler perspective. No surprise there. Forth can be a powerful
> macro assembler.
>
> But when you have to handle fat data objects in your embedded systems
> you need more adequate tooling. Since Forth can be extended easily,
> why not tool up Forth with what is needed.
>
> AFAIU exactly THIS was Moore's philosophy. I guess he would have laughed
> at "language purity" arguments.

Forth has many faces, maybe as many faces as it has users.
Given a sufficiently powerful system, a domain expert can, and will, extend it
in a fashion that quickly becomes completely incomprehensible to other Forth
users. CM is a prime example of that. Unfortunately, it does not scale.

-marcel

Marcel Hendrix schrieb am Montag, 7. November 2022 um 12:43:26 UTC+1:
> On Monday, November 7, 2022 at 9:25:46 AM UTC+1, minf...@arcor.de wrote:
> > Paul Rubin schrieb am Montag, 7. November 2022 um 05:41:54 UTC+1:
> > > dxforth <dxf...@gmail.com> writes:
> > > > For quite a long time I thought locals were a part of Forth - until a
> > > > chance reading of a post by Jeff Fox.
> > > It might have been this (3 parts): http://www.ultratechnology.com/forth.htm
> > > ...
> > > There's lots more, I've only scratched the surface. So I don't
> > > understand why it is that locals in particular draw ire while everything
> > > else skates by.
> > People love hot topics, particularly the heaters love them. Yet it is only
> > old stuff warmed up. Couple of years ago it had been OOP etc.
> >
> > Those recommendations by Fox/Moore read like coming from a
> > (macro) assembler perspective. No surprise there. Forth can be a powerful
> > macro assembler.
> >
> > But when you have to handle fat data objects in your embedded systems
> > you need more adequate tooling. Since Forth can be extended easily,
> > why not tool up Forth with what is needed.
> >
> > AFAIU exactly THIS was Moore's philosophy. I guess he would have laughed
> > at "language purity" arguments.
> Forth has many faces, maybe as many faces as it has users.
> Given a sufficiently powerful system, a domain expert can, and will, extend it
> in a fashion that quickly becomes completely incomprehensible to other Forth
> users. CM is a prime example of that. Unfortunately, it does not scale.
>

True. It is very unfortunate, and perhaps one of the big reasons why Forth is stalling,
that there is no standardized module or library concept in Forth.

[ Just one example: I use a comprehensive, battle-proven and fast linear algebra library
system in Forth. Small enough to run in-the-loop in MCUs. But it requires the presence
of three other small modules: complex math, dynamic vectors/arrays, basic digital filtering.
The latter three are no big deal for engineers.

But it would be unusable for other Forth users. Why? Because the module concept
has its own syntax incl. namespace management. It can't use some standard syntax
because there is none. ]

Consequence: the Forth software "world" is characterized by inventing wheels over
and over, and thus creating mutually incomprehensible DSLs every time.

Marcel Hendrix schrieb am Montag, 7. November 2022 um 12:43:26 UTC+1:
> Forth has many faces, maybe as many faces as it has users.
> Given a sufficiently powerful system, a domain expert can, and will, extend it
> in a fashion that quickly becomes completely incomprehensible to other Forth
> users. CM is a prime example of that. Unfortunately, it does not scale.

True. It is very unfortunate, and perhaps one of the big reasons why Forth is stalling,
that there is no standardized module or library concept in Forth.

[ Just one example: I use a comprehensive, battle-proven and fast linear algebra library
system in Forth. Small enough to run in-the-loop in MCUs. But it requires the presence
of three other small modules: complex math, dynamic vectors/arrays, basic digital filtering.
The latter three are no big deal for engineers.

But it would be unusable for other Forth users. Why? Because the module concept
has its own syntax incl. namespace management. It can't use some standard syntax
because there is none. ]

Consequence: the Forth software "world" is characterized by re-inventing wheels over
and over, and thus creating mutually incomprehensible DSLs every time.

On 7/11/2022 3:41 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> For quite a long time I thought locals were a part of Forth - until a
>> chance reading of a post by Jeff Fox.
>
> It might have been this (3 parts): http://www.ultratechnology.com/forth.htm
>
> A very interesting article. I read it some years ago (it's one of the
> things that got/kept me interested in Forth) and I just re-read it. It
> contains wisdom that can be learned from but that I think shouldn't be
> taken too literally.

Jeff could be a bit like Hugh but his point that I related about locals in
Forth not serving the same function as locals in C is indisputable.

dxforth schrieb am Montag, 7. November 2022 um 15:30:41 UTC+1:
> On 7/11/2022 3:41 pm, Paul Rubin wrote:
> > dxforth <dxf...@gmail.com> writes:
> >> For quite a long time I thought locals were a part of Forth - until a
> >> chance reading of a post by Jeff Fox.
> >
> > It might have been this (3 parts): http://www.ultratechnology.com/forth.htm
> >
> > A very interesting article. I read it some years ago (it's one of the
> > things that got/kept me interested in Forth) and I just re-read it. It
> > contains wisdom that can be learned from but that I think shouldn't be
> > taken too literally.
> Jeff could be a bit like Hugh but his point that I related about locals in
> Forth not serving the same function as locals in C is indisputable.

LOL! No hughish necromancy before next halloween! He might love you too!

On Monday, November 7, 2022 at 3:30:41 PM UTC+1, dxforth wrote:
> Jeff could be a bit like Hugh but his point that I related about locals in
> Forth not serving the same function as locals in C is indisputable.
True. You could let data flow over a stack in C (with a little trouble).
However, it's alien to the very concept of C, which uses stack frames
as its primary data flow mechanism. It's the same way with Forth.
In Forth, it's the stack - not locals. And locals are as alien.

Hans Bezemer

the.bee...@gmail.com schrieb am Montag, 7. November 2022 um 17:01:21 UTC+1:
> However, it's alien to the very concept of C, which uses stack frames
> as its primary data flow mechanism.

Modern 64-bit C passes most arguments through CPU registers.
Times are a-changing ...

Marcel Hendrix <mhx@iae.nl> writes:
>Given a sufficiently powerful system, a domain expert can, and will, extend it
>in a fashion that quickly becomes completely incomprehensible to other Forth
>users. CM is a prime example of that. Unfortunately, it does not scale.

I disagree. Chuck Moore's work on Forth is an example that is not
only comprehensible to others, but has inspired many others to use it,
adapt it to their needs, extend it, and do their own things with it.
And it scaled quite well. Thousands of people have used Forth.

That does not mean that every Forth application written by a domain
expert will be comprehensible, usable by others, and so on. One has
to work on that, typically follow a few blind alleys until one finds
the right way to do things and everythings falls into place. It helps
to keep both the implementation and the interface simple, it does not
help to keep the implementation simple at the cost of interface
complexity. If the interface is easy, but the implementation complex,
you get a black box, which is not Forth-like, but may or may not be
successful with users; you will have trouble finding people to
maintain the black box, though.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

"minf...@arcor.de" <minforth@arcor.de> writes:
>Modern 64-bit C passes most arguments through CPU registers.
>Times are a-changing ...

C calling conventions on 32-bit architectures such as ARM (1985), MIPS
(1986), SPARC (1986) etc. all pass parameters through registers.
Given the age and current status of these architectures, I hesitate to
call them modern.

- 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: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net