anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Standard Ada doesn't even allow it
> Since when? Last I heard, Ada had "new" (dynamic allocation)... use
> the standard procedure Ada.Unchecked_Deallocation.

Hmm, ok, I was going by this:

http://cowlark.com/2014-04-27-ada/index.html#hh16

I see now, it mentions Ada.Unchecked_Deallocation but doesn't consider
it to be part of the core language and describes it as "cheating", so I
thought of it as something like unsafe operations in Haskell or Rust, or
maybe something implementation specific. But, I guess it is more
"standard" than I realized. THanks.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> My approach is:
> [: ." Hello" ." " ." world" ." !" ;] >string-execute

In gforth this is nice, but as a general approach I'm uncomfortable with
it because it relies on having a resident text interpreter. I'd like to
see a refactoring of Forth that is metacompiler friendly, and in which
the text interpreter is just another optional / loadable word set.

On 5 Mar 2022 at 19:34:10 CET, "Paul Rubin" <no.email@nospam.invalid> wrote:
> The stack VM just seems like more of the same. Chuck Moore's Forth
> chips and the VFX software VM later added registers, and in the
> evolution of general purpose CPU hardware,

We have never added registers to the VFX VM. I discussed it in an
article in the late lamented Dr. Dobbs Journal. I think that the article
was entitled "Extreme Forth".

Stephen
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On Sunday, March 6, 2022 at 10:55:05 AM UTC+1, Stephen Pelc wrote:
[..]
> We have never added registers to the VFX VM. I discussed it in an
> article in the late lamented Dr. Dobbs Journal. I think that the article
> was entitled "Extreme Forth".

Any idea where to have a peek at that article? (Google fails).

-marcel

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> My approach is:
>> [: ." Hello" ." " ." world" ." !" ;] >string-execute
>
>In gforth this is nice, but as a general approach I'm uncomfortable with
>it because it relies on having a resident text interpreter.

No, the general approach does not. E.g., if you do

GFORTH=./gforth GFORTHD=./gforth-ditc gforthmi xxx.fi -e ': foo [: ." Hello" ." " ." world" ." !" ;] >string-execute type bye ; '"' foo is 'cold"

you get a turnkey image xxx.fi that calls FOO without invoking the
text interpreter, and FOO does not call the text interpreter, either.

gforth -i xxx.fi

runs that image.

>I'd like to
>see a refactoring of Forth that is metacompiler friendly, and in which
>the text interpreter is just another optional / loadable word set.

I think the text interpreter is an asset of Forth, but in any case,
nothing in >STRING-EXECUTE requires invoking the text interpreter at
run-time.

- 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

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> s=""
>> for i in range (0,1000000,1):
>> s=s+str(i)+" "
>> print s
>
>Try using StringIO (io.StringIO in Python 3) for this.

I don't know enough Python to make any sense of this advice.

Note that Python
>(both 2 and 3) also have a hacky optimization so if you say
> s += str(i)+" "
>instead of
> s=s+str(i)+" "
>it does what you might hope for.

[~/gforth:128495] cat <<EOF |perf stat python|wc
s=""
for i in range (0,1000000,1):
s+=str(i)+" "
print s
EOF

Performance counter stats for 'python':

232.56 msec task-clock # 0.909 CPUs utilized
420 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
9005 page-faults # 0.039 M/sec
907355895 cycles # 3.902 GHz
2235084263 instructions # 2.46 insn per cycle
441252757 branches # 1897.365 M/sec
420298 branch-misses # 0.10% of all branches

0.255767402 seconds time elapsed

0.221508000 seconds user
0.012082000 seconds sys

1 1000000 6888891

Yes, competetive with Forth.

>More idiomatic is s = ' '.join(str(i) for i in xrange(0,1000000))

[~/gforth:128496] cat <<EOF |perf stat python|wc
s = ' '.join(str(i) for i in xrange(0,1000000))
print s
EOF

Performance counter stats for 'python':

170.95 msec task-clock # 0.881 CPUs utilized
419 context-switches # 0.002 M/sec
2 cpu-migrations # 0.012 K/sec
15411 page-faults # 0.090 M/sec
664215343 cycles # 3.886 GHz
1408355593 instructions # 2.12 insn per cycle
276444906 branches # 1617.153 M/sec
359592 branch-misses # 0.13% of all branches

0.194138119 seconds time elapsed

0.159824000 seconds user
0.012294000 seconds sys

1 1000000 6888890

It's also faster. And I guess it leaves the trailing space away.

- 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 6 Mar 2022 at 11:07:56 CET, "Marcel Hendrix" <mhx@iae.nl> wrote:

> On Sunday, March 6, 2022 at 10:55:05 AM UTC+1, Stephen Pelc wrote:
> [..]
>> We have never added registers to the VFX VM. I discussed it in an
>> article in the late lamented Dr. Dobbs Journal. I think that the article
>> was entitled "Extreme Forth".
>
> Any idea where to have a peek at that article? (Google fails).

The DDJ web site seems to be under destruction. Try archive.org or some such.
I am resurrecting the two articles Modern Forth and Extreme Forth from 2008.
They'll end up on the MPE web site.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On Sunday, March 6, 2022 at 3:09:02 PM UTC, Stephen Pelc wrote:
> On 6 Mar 2022 at 11:07:56 CET, "Marcel Hendrix" <m...@iae.nl> wrote:
>
> > On Sunday, March 6, 2022 at 10:55:05 AM UTC+1, Stephen Pelc wrote:
> > [..]
> >> We have never added registers to the VFX VM. I discussed it in an
> >> article in the late lamented Dr. Dobbs Journal. I think that the article
> >> was entitled "Extreme Forth".
> >
> > Any idea where to have a peek at that article? (Google fails).
> The DDJ web site seems to be under destruction. Try archive.org or some such.

That seems to have been happening for a while - there are a few (non-Forth)
articles that used to be on DDJ and that I have been unable to find,
over the past couple of years

On 6 Mar 2022 at 11:07:56 CET, "Marcel Hendrix" <mhx@iae.nl> wrote:

> On Sunday, March 6, 2022 at 10:55:05 AM UTC+1, Stephen Pelc wrote:
> [..]
>> We have never added registers to the VFX VM. I discussed it in an
>> article in the late lamented Dr. Dobbs Journal. I think that the article
>> was entitled "Extreme Forth".
>
> Any idea where to have a peek at that article? (Google fails).

https://www.drdobbs.com/embedded-systems/modern-forth/210600604

Extreme Forth I'm in the middle of converting.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On Sunday, March 6, 2022 at 4:41:55 PM UTC, Stephen Pelc wrote:
> On 6 Mar 2022 at 11:07:56 CET, "Marcel Hendrix" <m...@iae.nl> wrote:
> > On Sunday, March 6, 2022 at 10:55:05 AM UTC+1, Stephen Pelc wrote:
> > [..]
> >> We have never added registers to the VFX VM. I discussed it in an
> >> article in the late lamented Dr. Dobbs Journal. I think that the article
> >> was entitled "Extreme Forth".
> >
> > Any idea where to have a peek at that article? (Google fails).
> https://www.drdobbs.com/embedded-systems/modern-forth/210600604

Have you tried pages 2 & 3? (that was the sort of error I've seen previously)

J^n

Stephen Pelc <stephen@vfxforth.com> writes:
> We have never added registers to the VFX VM. I discussed it in an
> article in the late lamented Dr. Dobbs Journal. I think that the
> article was entitled "Extreme Forth".

Hmm ok, I was thinking of this:

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

I guess it wasn't actually implemented in VFX.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Try using StringIO (io.StringIO in Python 3) for this.
> I don't know enough Python to make any sense of this advice.

In Python 2, try this (it would be slightly different in py3):

import cStringIO
s = cStringIO.StringIO()
for i in xrange(1000000):
s.write(str(i))
print s.getvalue()

cStringIO is a C version of StringIO that is faster but has slightly
fewer features. StringIO basically lets you use a string as an i/o
target. Java has something similar whose name I've forgotten.

You could also try StringIO (written in pure Python) instead of cStringIO.

> In Python you'd write "Hello" + " " + "world" + "!" which is simple.
>
> Your Forth equivalent is:
>
> include lib/concat.4th
> s" Hello" s" " s" world" s" !" 4 Hello concat

Stunningly bad. Hans Bezemer has to tell his language
how many strings he wishes to concatenate (4) because his
language is unable to count.

Like Intercal, this language is a joke, but unlike Intercal,
it's not even funny.

Gauche Scheme and Racket:

(string-join
'("OMJ"
"DZS"
"WTS"
"OGU"
"GMB"
"NSL"
"CAL"
"CFA"
"XQM"
"ION"
"SXD"
"GPK"
"OTF"
"FYC"
"PHS"
"EWY"
"QVH"
"QCW")
"-")

"OMJ-DZS-WTS-OGU-GMB-NSL-CAL-CFA-XQM-ION-SXD-GPK-OTF-FYC-PHS-EWY-QVH-QCW"

Incredible! The men who created Scheme knew how to make a langauge
that could count! They must have been demigods!

On Sunday, March 6, 2022 at 4:22:53 PM UTC-6, Robert L. wrote:

> Gauche Scheme and Racket:
>
> (string-join
> '("OMJ"
> "DZS"
> "WTS"
> "OGU"
> "GMB"
> "NSL"
> "CAL"
> "CFA"
> "XQM"
> "ION"
> "SXD"
> "GPK"
> "OTF"
> "FYC"
> "PHS"
> "EWY"
> "QVH"
> "QCW")
> "-")
>
> "OMJ-DZS-WTS-OGU-GMB-NSL-CAL-CFA-XQM-ION-SXD-GPK-OTF-FYC-PHS-EWY-QVH-QCW"
>
> Incredible! The men who created Scheme knew how to make a langauge
> that could count! They must have been demigods!
??
:) frogd
ELF32X86_64 Frog Version 1.0d

"job" /go
"QCW" "QVH" "EWY" "PHS" "FYC" "OTF" "GPK" "SXD" "ION"
"XQM" "CFA" "CAL" "NSL" "GMB" "OGU" "WTS" "DZS" "OMJ"
"-" { >R begin tell depth while r tell repeat rdrop } cr run1
OMJ-DZS-WTS-OGU-GMB-NSL-CAL-CFA-XQM-ION-SXD-GPK-OTF-FYC-PHS-EWY-QVH-QCW ok
--
me

> Incredible! The men who created Scheme knew how to make a langauge
> that could count! They must have been demigods!

No. Only non-programmers who can only ride bikes with side wheels and don't even have the basics of CS - so that they are completely unable to understand how incredibly stupid their remarks are - can think that much.

You can only terminate objects in two ways - either with a terminator or with a count. So - that Scheme gives you side wheels and C and Forth not is due to design.

Your problem Robert L. is two sided. First, you are incapable of writing any significant program - let alone a compiler. Second, if your language doesn't offer a whole slew of tools, you're completely unable to get any work done.

My guess is that you tried Forth, couldn't wrap you tiny incel head around it and are now bothering people with your beginners class "challenges". Point is, real work has very little to do with these. If it would, we would have libs for it.

So go back to you basement and bother your mother. And be a nice boy, for after all, remember: she is your mother after all.

Hans

"Robert L." <No_spamming@noWhere_7073.org> writes:
> (string-join
> '("OMJ"
> "DZS"
> ...
> "QCW")
> "-")

Please, can we keep the needless vitriol out?

Python: "-".join(("OMJ", "DZS", ...))

That is, instances of string respond to the "join" message, which
takes as an argument anything list-like (in this case, a tuple--a
read-only list).

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

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> But there is a certain discipline required in using malloc() and
> free() and still keep it maintainable.

I think that trivializes the issue. It is doable, but very difficult to
deal with this in a big program. That's why gc was invented in the
1950s (and programmers back then were very skilled at bit twiddling and
assembly code and most of us today are wimps by comparison). It's why
Rust was invented, and it's why 4th has an arena allocator among other
things.

>> dynamic memory allocation is deep-down non-deterministic.
> Again, depends how you use it.

When you allocate something and when you stop needing it can be very far
away from each other in both code region and time. And some programs
are inherently non-deterministic, such as programs doing concurrent i/o
to lots of channels. You might allocate memory for a request coming
from one thread or task, and then let other tasks handle it.

> [Ada[ Makes sense in a way - if you want to make a language for n00bs.

It's for critical systems and they wanted to be certain that your
program could not crash for a dangling pointer.

> But then again - it's the one language Dijkstra hated. For good
> reasons, it seems.

I think because of it's complexity: it is certainly not for n00bs. Here
is what Dijkstra said about Lisp, fwiw (1972 Turing Award lecture):

With a few very basic principles at its foundation, it [LISP] has
shown a remarkable stability. Besides that, LISP has been the
carrier for a considerable number of in a sense our most
sophisticated computer applications. LISP has jokingly been
described as “the most intelligent way to misuse a computer”. I
think that description a great compliment because it transmits the
full flavour of liberation: it has assisted a number of our most
gifted fellow humans in thinking previously impossible thoughts.

> YOU may not be able to live without dictionaries. I can live very well
> without them.

4th doesn't have a dictionary?

>> Your doc says your ubasic has its own string stack and scans it for
>> string references to reclaim string memory.
> No, it doesn't. Read again.

Sorry, "stack" not "string stack". Per your doc,

The garbage collection algorithm puts all strings on the "freelist"
again and eliminates the ones which are referred to by uBasic stack
items and local and global variables.

>> But what if a 4th program (not ubasic) wants to use those strings?
> You include the library. It's done with INCLUDE.

You mean use uBasic? The doc refers to the uBasic stack which makes it
sound separate from the 4th stack.

> [Thinking Forth] You couldn't even remember the "long distance phone
> call" example. Must have been a long time ago.

You are right, I forgot that example and didn't put the mention in
context. I just looked at it and it is nice.

>> That's awful, why not code in assember directly?
> That was fun too - but not too portable. So, 4tH.

Portable assembler like picolisp uses maybe? It's for an abstract
machine with registers, but the assembler for it can emit machine code
for real machines. SPITBOL uses something similar.

>> There's an unconvincing rationalization going on here.
> No, there isn't. Again, you didn't read "Thinking Forth"

I certainly don't remember anything in Thinking Forth about such issues.
Thinking Forth was a great book partly because it was not really that
Forth specific. Its ideas often apply to other languages too. It was
the good parts of what corporate boneheads turned into "agile" decades
later.

> prefer blocks over files.
> https://sourceforge.net/p/forth-4th/wiki/16%20Blocks/

Yeah I sort of get that blocks were nice for some things. That
particular page, though, mentions that in 4th, tasks can access block
buffers concurrently even though they can't do i/o concurrently. That
is one of the stated advantage of blocks in 4th. But, I think most
people expect multitasking systems to allow concurrent i/o, and even
consider it to be the point of multitasking. Polyforth was able to do
that, for example.

> You REALLY seem to think there are solutions that are superior in each
> and every situation, don't you?

I wouldn't say that. I'd say instead that my brain is rather small, so
I'd rather use a few powerful tools that together are adequate for most
situations, than millions of specialized tools each of which is optimal
for some specific situation. That's why we programmers use general
purpose CPUs for stuff instead of building special purpose hardware all
the time, for that matter.

Bruce Lee famously said "I fear not the man who has practiced ten
thousand kicks once. I fear the man who has practiced one kick ten
thousand times."

>> Doing all that stack juggling is a painful abstraction inversion
> Like I said - Forth opens everything up to you, but you've got to
> handle it. So yes, you chose Forth, it's your job now.

Yes, but I'm saying that the non-indexable stack (ignoring the reviled
PICK) should possibly be seen as a historical anachronism like blocks.
Jonah Thomas (2003) wrote:

Blocks gave an integrated editor, and fast integrated compiling, and
a sort of paged virtual memory, and something you could easily turn
into a somewhat inferior database, etc. It wasn't the best solution
for very much but it gave an easy adequate solution for a whole lot.

Blocks happened because they were very easy to implement and used few
machine resources, which was important at the time. They later gave way
to approaches that were more complicated underneath but made life easier
for users. People on clf keep talking about promoting Forth and they
think the pure stack VM is one of its attractions, but for most
programmers, the pure stack is a bug and not a feature.

In "This is Forth" you gave a stack juggling version of a pi
approximation algorithm and wrote

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 tried writing a version with gforth locals, translated from the BASIC
version:

: f^2 ( x -- x**2 ) fdup f* ;
: tam { n -- F: pi }
1e { F: a } 0.5e fsqrt { F: b }
0.25e { F: c } 1e { F: d }
n 0 ?DO
a { F: y }
a b f+ 2e f/ TO a
b y f* fsqrt TO b
c a y f- f^2 d f* f- TO c
d 2e f* TO d
LOOP
a b f+ f^2 c 4e f* f/ ;
4 tam f.

This looks simpler and more maintainable to me than the stack juggling
version, though maybe that's just me. I didn't try comparing the speed.
I do know that some compilers are capable of optimizing this type of
code pretty well.

> I once wrote a program in 4tH - in five days. Estimate for C was three
> months.

Did you write both a Forth version and a C version and compare the two
implementation times? It could be that the 3 month estimate was heavily
padded, was made by corporate stooges, or included other sorts of
development than just writing the code.

>> can I ask why so much of 4th is written in C?
> Download it - it's all documented.

I didn't look at them much before since I mostly use gforth, but I do
have to say the 4th docs are very good.

On 7/03/2022 09:22, Robert L. wrote:
>> In Python you'd write "Hello" + " " + "world" + "!" which is simple.
>>
>> Your Forth equivalent is:
>>
>> include lib/concat.4th
>> s" Hello" s" " s" world" s" !" 4 Hello concat
>
> Stunningly bad. Hans Bezemer has to tell his language
> how many strings he wishes to concatenate (4) because his
> language is unable to count.
>
> Like Intercal, this language is a joke, but unlike Intercal,
> it's not even funny.
>
>
> Gauche Scheme and Racket:
>
> [..]
>
> Incredible! The men who created Scheme knew how to make a langauge
> that could count! They must have been demigods!

Forth gods view the world differently ...

https://archive.org/details/Forth_Dimension_Volume_04_Number_4/page/n6/mode/1up?view=theater

Paul Rubin <no.email@nospam.invalid> writes:
>In Python 2, try this (it would be slightly different in py3):
>
> import cStringIO
> s = cStringIO.StringIO()
> for i in xrange(1000000):
> s.write(str(i))
> print s.getvalue()

[~:128519] cat <<EOF |perf stat python|wc
> import cStringIO
s = cStringIO.StringIO()
for i in xrange(1000000):
s.write(str(i))
print s.getvalue()
EOF
File "<stdin>", line 1
import cStringIO
^
IndentationError: unexpected indent
....

Python!

[~:128520] cat <<EOF |perf stat python|wc
import cStringIO
s = cStringIO.StringIO()
for i in xrange(1000000):
s.write(str(i))
print s.getvalue()
EOF

Performance counter stats for 'python':

262.32 msec task-clock # 0.925 CPUs utilized
359 context-switches # 0.001 M/sec
1 cpu-migrations # 0.004 K/sec
2541 page-faults # 0.010 M/sec
1002216759 cycles # 3.821 GHz
2675119254 instructions # 2.67 insn per cycle
546192174 branches # 2082.170 M/sec
335453 branch-misses # 0.06% of all branches

0.283636610 seconds time elapsed

0.259380000 seconds user
0.004052000 seconds sys

1 1 5888891

>You could also try StringIO (written in pure Python) instead of cStringIO.

[~:128521] cat <<EOF |perf stat python|wc
import StringIO
s = StringIO.StringIO()
for i in xrange(1000000):
s.write(str(i))
print s.getvalue()
EOF

Performance counter stats for 'python':

543.01 msec task-clock # 0.959 CPUs utilized
361 context-switches # 0.665 K/sec
1 cpu-migrations # 0.002 K/sec
15167 page-faults # 0.028 M/sec
2158242599 cycles # 3.975 GHz
6070406225 instructions # 2.81 insn per cycle
1126041488 branches # 2073.690 M/sec
632327 branch-misses # 0.06% of all branches

0.566232729 seconds time elapsed

0.519931000 seconds user
0.024371000 seconds sys

1 1 5888891

- 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

Paul Rubin <no.email@nospam.invalid> writes:
> [Pi algorithm] I tried writing a version with gforth locals,
> translated from the BASIC version: ...

Here is a refactored version that I like better. It removes all the
uses of TO and just iterates a function on 4 inputs passed on the FP
stack.

: f^2 ( x -- x**2 ) fdup f* ;

: tam2-init ( -- F: a F: b F: c F: d ) \ set up initial constants
1e 0.5e fsqrt 0.25e 1e ;

: tam2-step { F: a F: b F: c F: d -- F: a' F: b' F: c' F: d' }
a b f+ 2e f/ { F: a' }
a' \ a'
b a f* fsqrt \ b'
c a' a f- f^2 d f* f- \ c'
d 2e f* \ d'
;

: tam2-final { F: a F: b F: c F: d -- pi }
a b f+ f^2 4e c f* f/ ;

: tam2 { n -- F: pi }
tam2-init
n 0 ?DO
tam2-step
LOOP ( F: a b c d )
tam2-final ;

4 tam2 f.

Paul Rubin schrieb am Montag, 7. März 2022 um 09:22:44 UTC+1:
> Paul Rubin <no.e...@nospam.invalid> writes:
> > [Pi algorithm] I tried writing a version with gforth locals,
> > translated from the BASIC version: ...
>
> Here is a refactored version that I like better. It removes all the
> uses of TO and just iterates a function on 4 inputs passed on the FP
> stack.
> : f^2 ( x -- x**2 ) fdup f* ;
> : tam2-init ( -- F: a F: b F: c F: d ) \ set up initial constants
> 1e 0.5e fsqrt 0.25e 1e ;
>
> : tam2-step { F: a F: b F: c F: d -- F: a' F: b' F: c' F: d' }
> a b f+ 2e f/ { F: a' }
> a' \ a'
> b a f* fsqrt \ b'
> c a' a f- f^2 d f* f- \ c'
> d 2e f* \ d'
> ;
>
> : tam2-final { F: a F: b F: c F: d -- pi }
> a b f+ f^2 4e c f* f/ ;
>
> : tam2 { n -- F: pi }
> tam2-init
> n 0 ?DO
> tam2-step
> LOOP ( F: a b c d )
> tam2-final ;
>
> 4 tam2 f.

Somewhat OT but the repeated F: for fp-locals are awkward in:
> : tam2-step { F: a F: b F: c F: d -- F: a' F: b' F: c' F: d' } ... ;

That's why I mostly use persistent local type id's:
> : tam2-step { F: a b c d -- a' b' c' d' } ... ;
Switchback to normal cells/integers goes by an N: id.
(D: and Z: are for double and complex locals)
Non/persistance can be flag-controlled for compatibility

"minf...@arcor.de" <minforth@arcor.de> writes:
> Somewhat OT but the repeated F: for fp-locals are awkward in:
>> : tam2-step { F: a F: b F: c F: d -- F: a' F: b' F: c' F: d' } ... ;

Interesting, what implementation is that? I think gforth requires the
repeated F: . The part after the -- is just a comment, ignored by the
interpreter, so at first I didn't insert the F: but added it later. I
see one place where I forgot to add it.

There was an article I saw in 4th dimensions or JFAR or someplace like
that a while back, saying someone had found locals decreased debugging
time by 4x or some amount like that. Unfortunately despite some
searching, I haven't been able to find that article again.

Paul Rubin schrieb am Montag, 7. März 2022 um 10:22:15 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > Somewhat OT but the repeated F: for fp-locals are awkward in:
> >> : tam2-step { F: a F: b F: c F: d -- F: a' F: b' F: c' F: d' } ... ;
> Interesting, what implementation is that? I think gforth requires the
> repeated F: . The part after the -- is just a comment, ignored by the
> interpreter, so at first I didn't insert the F: but added it later. I
> see one place where I forgot to add it.
>
> There was an article I saw in 4th dimensions or JFAR or someplace like
> that a while back, saying someone had found locals decreased debugging
> time by 4x or some amount like that. Unfortunately despite some
> searching, I haven't been able to find that article again.

It runs in my private main system since many years. A while ago I
ported it also to public MinForth (but it had not been much tested there
so it may be buggy).

My experience with decreased debugging time through named locals
instead of anonymous stack positions is similar, because I am not
intelligent enough or just too lazy to do much stack juggling without errors.
But ... yawn ... the topic is an old flame-bait for some hardcore Forthers.

On 7/03/2022 21:51, minf...@arcor.de wrote:
> Paul Rubin schrieb am Montag, 7. März 2022 um 10:22:15 UTC+1:
>> "minf...@arcor.de" <minf...@arcor.de> writes:
>> > Somewhat OT but the repeated F: for fp-locals are awkward in:
>> >> : tam2-step { F: a F: b F: c F: d -- F: a' F: b' F: c' F: d' } ... ;
>> Interesting, what implementation is that? I think gforth requires the
>> repeated F: . The part after the -- is just a comment, ignored by the
>> interpreter, so at first I didn't insert the F: but added it later. I
>> see one place where I forgot to add it.
>>
>> There was an article I saw in 4th dimensions or JFAR or someplace like
>> that a while back, saying someone had found locals decreased debugging
>> time by 4x or some amount like that. Unfortunately despite some
>> searching, I haven't been able to find that article again.
>
> It runs in my private main system since many years. A while ago I
> ported it also to public MinForth (but it had not been much tested there
> so it may be buggy).
>
> My experience with decreased debugging time through named locals
> instead of anonymous stack positions is similar, because I am not
> intelligent enough or just too lazy to do much stack juggling without errors.
> But ... yawn ... the topic is an old flame-bait for some hardcore Forthers.

Folks telling stories of how they struggle with forth has that effect :)

On Monday, March 7, 2022 at 3:18:10 AM UTC+1, Paul Rubin wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> I think that trivializes the issue. It is doable, but very difficult to
> deal with this in a big program.
Well, if you consider 4tH to be a large program - memory allocation issues
were never an issue. So why?
(1) If you do small, temporary allocations (like composing a filename from a path and
the actual filename) their allocation can be handled within the same function
scope;
(2) If you do allocations that last for longer (e.g. an entire 4tH applet) you don't do
a bunch of smaller allocations - you do a large one - and increase it significantly
if you run out of space. On average, the thing will be filled for about 75% while the
copying effort in reallocation is quite minimal. Combining this stuff (like in 4tH, which
is comprised of a header, which contains several pointers to other segments) makes it
much easier just to dump the entire shebang.

It also allows for much better caching. The problem with smaller allocations is that they
may be scattered all over the heap.
> That's why gc was invented in the
> 1950s (and programmers back then were very skilled at bit twiddling and
> assembly code and most of us today are wimps by comparison). It's why
> Rust was invented, and it's why 4th has an arena allocator among other
> things.
Actually, it was added to LISP first. Later, others picked it up as an "academic
challenge" as is illustrated by this epilogue to an early paper (involving Dijkstra):
"When it is objected that we still needed rather subtle arguments, we can only
agree whole-heartedly: all of us would have preferred a simpler argument!
Perhaps we should conclude that constructions that give rise to such tricky
problems are not to be recommended. Our firm conclusion, however, can be drawn:
to believe that such solutions can be found without a very careful justification
is optimism on the verge of foolishness".

Dijkstra tried to design a "don't stop the world" algorithm - but he too saw it mainly
as an "academic challenge" as illustrated by "Dijkstra’s algorithm is fine-grained:
no synchronization between the mutator and the collector, no stop-the-world phase
in the collection and each line in the barrier code is an atomic action. However,
Dijkstra’s chief concern was the correctness of his algorithm rather than practical use".

So no - your assumption that GC was invented with this in mind is simply incorrect.
FYI: I have NEVER used arena allocation in ANY of my programs (apart from some demo)
for the simple reason I've never needed it.

Automatic (re)allocation is barely ever needed over the entire program IMHO.. There might
be areas where it offers advantages, but certainly not overall. I tend to concentrate 4tH's
solutions to these structures who benefit from it and leave the rest be.

> >> dynamic memory allocation is deep-down non-deterministic.
> > Again, depends how you use it.
> When you allocate something and when you stop needing it can be very far
> away from each other in both code region and time. And some programs
> are inherently non-deterministic, such as programs doing concurrent i/o
> to lots of channels. You might allocate memory for a request coming
> from one thread or task, and then let other tasks handle it.
Concurrency is a whole different ballgame - as any programmer will tell you..
And without a real, concrete case it's quite hard to contemplate an (alternative)
architecture.

And this is what Dijkstra had to say about Ada:
"The quest for the Stone is based on the assumption that our "programming tools" are too weak.
One example is the belief that current programming languages lack the "features" we need.
PL/I was one of the more spectacular would-be stones produced.
I still remember the advertisement in Datamation,1968, in which a smiling Susie Mayer
announces in full colour that she has solved all her programming problems
by switching to PL/I. It was only too foreseeable that, a few years later, poor Susie Mayer
would smile no longer. Needless to say, the quest went on and in due time a next would-be
stone was produced in the form of Ada (behind the Iron Curtain perceptively referred to as PL/II).
Even the most elementary astrology for beginners suffices to predict that Ada will not be the last
stone of this type.

Ada will not meet its major objective, viz. that of reducing software costs
by standardization, and it will not be the vehicle for programs we can rely upon,
for it is so complicated that it defies the unambiguous definition that is essential
for these purposes. Long before the design was frozen, computing scientists from
all over the world have given plenty of warning but the political body in question
preferred to ignore these warnings and to decide on a design that cannot be salvaged.
From a scientific point of view all further attention paid to Ada is a waste of effort.
But the sheer buying-power of the DoD makes Ada an undeniable reality, which in
combination with DARPA's policies for the funding of software research can only
increase the pressure to spend research effort on the wrong problems".

Another quote I carry along is "The analysis of the influence that programming
languages have on the thinking habits of its users, and the recognition that,
by now, brainpower is by far our scarcest resource, they together give us a new
collection of yardsticks for comparing the relative merits of various programming
languages. The competent programmer is fully aware of the strictly limited size
of his own skull; therefore he approaches the programming task in *full humility*,
and among other things he avoids clever tricks like the plague".

In other words: write code that makes sense. Don't try to prove to yourself
- or worse: others - how clever you are. And finally:

"As an aside I would like to insert a warning to those who identify the difficulty
of the programming task with the struggle against the inadequacies of our current
tools, because they might conclude that, once our tools will be much more adequate,
programming will no longer be a problem. Programming will remain very difficult,
because once we have freed ourselves from the circumstantial cumbersomeness,
we will find ourselves free to tackle the problems that are now well beyond our
programming capacity".

Which always makes me laugh when half-@$$ed programmer tackle
a (government) job, wrap the whole problem up in layers of Java code
they didn't even write and then stand flabbergasted when a huge
Java stack dump pops up, where 90% of the calls are in those layers
they never even saw - let alone program themselves.

> > But then again - it's the one language Dijkstra hated. For good
> > reasons, it seems.
> I think because of it's complexity: it is certainly not for n00bs. Here
> is what Dijkstra said about Lisp, fwiw (1972 Turing Award lecture):
> "With a few very basic principles at its foundation, it [LISP] has
> shown a remarkable stability. Besides that, LISP has been the
> carrier for a considerable number of in a sense our most
> sophisticated computer applications. LISP has jokingly been
> described as “the most intelligent way to misuse a computer”. I
> think that description a great compliment because it transmits the
> full flavour of liberation: it has assisted a number of our most
> gifted fellow humans in thinking previously impossible thoughts".
LISP was a language that was lightyears ahead of its time. It shares some
philosophical roots with Forth. So apart from that it's no MY computer language
I have very little against it. Not in the way I oppose Java or Python. But it's
either not well suited for my frame of mind or the kind of problems I've got
to solve.

> > YOU may not be able to live without dictionaries. I can live very well
> > without them.
> 4th doesn't have a dictionary?
Nope. It has a symbol table - which is discarded when you run the code
(unless you explicitly stated otherwise).

> >> Your doc says your ubasic has its own string stack and scans it for
> >> string references to reclaim string memory.
> The garbage collection algorithm puts all strings on the "freelist"
> again and eliminates the ones which are referred to by uBasic stack
> items and local and global variables.
uBasic/4tH has a user stack which is accessible by word like PUSH, TOS(), POP(), etc.
As such it has to be examined for strings that are put there - just like global
or local variables - but that's it. It's not part of the string system as such.

The string system can be applied when the entire stack is removed AND
the user stack can (and has) worked fine without strings.

> You mean use uBasic? The doc refers to the uBasic stack which makes it
> sound separate from the 4th stack.
It is. Within uBasic/4tH the native 4tH stack is used for all kinds of calculations.
From 4tH's point of view, the uBasic/4tH stack is a user stack, implemented
with lib/stack.4th

Click here to read the complete article