Rick C <gnuarm.deletethisbit@gmail.com> writes:
> You fail to even understand the concept. If a pointer to code is
> executed, the code executed depends on the data in a way that is
> equivalent to self modifying code.

I don't understand this "equivalence". Self-modifying code means what
it says. The code space is modified.

If your program has conditional branches, the code executed also depends
on the data. Is THAT equivalent to self modifying code?

You can, if you want, think of calling a code pointer as equivalent to
executing a CASE statement, where the case labels are simply the
possible code addresses that the pointer might hold. No
self-modification involved.

On Friday, March 4, 2022 at 6:05:05 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > You fail to even understand the concept. If a pointer to code is
> > executed, the code executed depends on the data in a way that is
> > equivalent to self modifying code.
> I don't understand this "equivalence". Self-modifying code means what
> it says. The code space is modified.
>
> If your program has conditional branches, the code executed also depends
> on the data. Is THAT equivalent to self modifying code?
>
> You can, if you want, think of calling a code pointer as equivalent to
> executing a CASE statement, where the case labels are simply the
> possible code addresses that the pointer might hold. No
> self-modification involved.

Modifying the code does not require modification of anything other than the address currently in the program counter, just as in a call or jump. Changing the address for code obtained from data is no different from modifying the address in a jump or call instruction in memory. How is it different to change the address in a jump instruction compared to changing the address that is loaded into the PC via data? There is no significance to how the address was changed. The significance is in the fact that the address can't be known until run time.

One of the main failings in using pointers for addressing data is the difficulty in finding the cause of errors in the address calculations, because the symptoms are typically unrelated to the cause. Changing the sequence of instructions has the same sort of problem, but in spades.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:

> On Friday, March 4, 2022 at 6:05:05 PM UTC-5, Paul Rubin wrote:
>> Rick C <gnuarm.del...@gmail.com> writes:
>> > You fail to even understand the concept. If a pointer to code is
>> > executed, the code executed depends on the data in a way that is
>> > equivalent to self modifying code.
>> I don't understand this "equivalence". Self-modifying code means what
>> it says. The code space is modified.
>>
>> If your program has conditional branches, the code executed also depends
>> on the data. Is THAT equivalent to self modifying code?
>>
>> You can, if you want, think of calling a code pointer as equivalent to
>> executing a CASE statement, where the case labels are simply the
>> possible code addresses that the pointer might hold. No
>> self-modification involved.
>
> How is it different to change the address in a jump instruction
> compared to changing the address that is loaded into the PC via data?
> There is no significance to how the address was changed. The
> significance is in the fact that the address can't be known until run
> time.

Right, I'm asking if that is different from an ordinary conditional
jump:

: foo thingy 3 < IF moo ELSE goo THEN ;

You don't know until run time whether moo gets called, or goo gets
called. With a code pointer, there are more than 2 possible
destinations, but it's a similar situation.

> One of the main failings in using pointers for addressing data is the
> difficulty in finding the cause of errors in the address calculations,

Yes, very true. The most common way to mitigate this issue is type
systems. Those let you enforce invariants across the whole program.

Forthers often think Forth can do everything (i.e. given any desired
program behaviour X, there is a way to implement X in Forth) and that
suffices to make a language complete. But that is only one side of the
coin. You also want to ensure the absence of undesired behaviours Y.

As one book (Pierce, Types And Programming Languages) put it (slight
misquote), the purpose of type systems is to make sure the program is
free of certain runtime behaviours. Cardelli ("Typeful programming",
1989, http://www.lucacardelli.name/Papers/TypefulProg.pdf , p. 52)
classified languages according to how they implement types, starting
with:

Typeless programming. Truly typeless languages include Assemblers,
BCPL and, to a minor extent, C; these languages regard raw memory as
the fundamental data structure. Large systems programmed in this
style become very hard to debug and maintain, hence we dismiss these
languages as obsolete, undisciplined, and unreliable. Although C
has a relatively rich notion of typing, the type enforcement is too
weak to lead predictably to robust systems.

I would put Forth in the "assembler" category under this classification.
The basic data structure is raw memory (plus the stacks). So dealing
with pointer-related bugs is hard. If you program in Python for a
while, pointers are used far more heavily, but their usage is controlled
by the interpreter rather than allowed to run amuck, so debugging is
usually pretty easy.

On Friday, March 4, 2022 at 9:50:27 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
>
> > On Friday, March 4, 2022 at 6:05:05 PM UTC-5, Paul Rubin wrote:
> >> Rick C <gnuarm.del...@gmail.com> writes:
> >> > You fail to even understand the concept. If a pointer to code is
> >> > executed, the code executed depends on the data in a way that is
> >> > equivalent to self modifying code.
> >> I don't understand this "equivalence". Self-modifying code means what
> >> it says. The code space is modified.
> >>
> >> If your program has conditional branches, the code executed also depends
> >> on the data. Is THAT equivalent to self modifying code?
> >>
> >> You can, if you want, think of calling a code pointer as equivalent to
> >> executing a CASE statement, where the case labels are simply the
> >> possible code addresses that the pointer might hold. No
> >> self-modification involved.
> >
> > How is it different to change the address in a jump instruction
> > compared to changing the address that is loaded into the PC via data?
> > There is no significance to how the address was changed. The
> > significance is in the fact that the address can't be known until run
> > time.
> Right, I'm asking if that is different from an ordinary conditional
> jump:
>
> : foo thingy 3 < IF moo ELSE goo THEN ;
>
> You don't know until run time whether moo gets called, or goo gets
> called. With a code pointer, there are more than 2 possible
> destinations, but it's a similar situation.

You don't need to know which gets executed. You can analyze the flow to prove the code is doing what you expect. If a pointer is passed into a routine, there is no way to know what it points to.

> > One of the main failings in using pointers for addressing data is the
> > difficulty in finding the cause of errors in the address calculations,
> Yes, very true. The most common way to mitigate this issue is type
> systems. Those let you enforce invariants across the whole program.
>
> Forthers often think Forth can do everything (i.e. given any desired
> program behaviour X, there is a way to implement X in Forth) and that
> suffices to make a language complete. But that is only one side of the
> coin. You also want to ensure the absence of undesired behaviours Y.
>
> As one book (Pierce, Types And Programming Languages) put it (slight
> misquote), the purpose of type systems is to make sure the program is
> free of certain runtime behaviours. Cardelli ("Typeful programming",
> 1989, http://www.lucacardelli.name/Papers/TypefulProg.pdf , p. 52)
> classified languages according to how they implement types, starting
> with:
>
> Typeless programming. Truly typeless languages include Assemblers,
> BCPL and, to a minor extent, C; these languages regard raw memory as
> the fundamental data structure. Large systems programmed in this
> style become very hard to debug and maintain, hence we dismiss these
> languages as obsolete, undisciplined, and unreliable. Although C
> has a relatively rich notion of typing, the type enforcement is too
> weak to lead predictably to robust systems.
>
> I would put Forth in the "assembler" category under this classification.
> The basic data structure is raw memory (plus the stacks). So dealing
> with pointer-related bugs is hard. If you program in Python for a
> while, pointers are used far more heavily, but their usage is controlled
> by the interpreter rather than allowed to run amuck, so debugging is
> usually pretty easy.

Ok. A bit outside the issue of pointers to code.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

Paul Rubin <no.email@nospam.invalid> writes:
>[Locals] were
>used in lambda calculus (i.e. in math) long before there was such a
>thing as computers.

The lambda calculus was developed in the 1930s, not long before the Z1
which was completed in 1938. And if you count the analytical engine,
computers were long before the lambda calculus. There were also other
earlier developments that are mentioned in the history of computers.

- 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

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> You don't need to know which gets executed. You can analyze the flow
> to prove the code is doing what you expect. If a pointer is passed
> into a routine, there is no way to know what it points to.

Sure, that is true of both code pointers and data pointers. If the
pointer contains garbage, the program typically crashes, but anything
could happen. There is a huge industry of finding security exploits in
C programs based on that idea.

That is why languages like Rust are getting so much attention now: the
compiler is able to track pointer usages across an entire large program
instead of the immediate context of (e.g) and IF statement, to make sure
the pointer contents are always sane. If your program compiles without
errors, you know that your pointer didn't get clobbered by something far
away in the code. Language geekery is largely about automating bug
prevention like that these days.

Meanwhile, nobody writes big apps in assembler any more, Forth is just
for a few weirdos like us, and C is still alive only because it was
historically huge, and (like COBOL), lots of old C codebases are still
doing important things.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> And if you count the analytical engine, computers were long before the
> lambda calculus.

I suppose you are right. On the other hand, I wonder if Euclid's
description of the Euclidean gcd algorithm used local variables.
Certainly, other math algorithms like matrix multiplication are easiest
to imagine as loops involving index variables. Those go back at least
as far as the analytical engine.

On Saturday, March 5, 2022 at 12:01:06 AM UTC+1, Paul Rubin wrote:
> I just skimmed Anton's GC and the main file (gc4image.fs) is 751 lines,
> around 500 of which are not blank or comments. A lot of it is small
> helper functions like "find the first nonzero bit of an array". Overall
> it looks pretty understandable.
That's at least 20% more than your previous estimate. Do you always get into a discussion without getting your facts right?
And again: apart from a single lookup table there is NO lib in 4tH that is even remotely as big as this one.
And again: I never made any comment concerning its quality. I just stated "it's massive". And it is..
> 4th according to https://thebeez.home.xs4all.nl/4tH/sloc.html is 5ksloc
> of C and 9ksloc of Forth, around 14k total, so 500sloc (Anton's gc) is
> about 3% of that. If having a "massive" GC library as 3% of a program
> simplifies or eliminates the storage management headaches of the other
> 97%, is that really a bad trade?
Yes. Since you can't compare the size of an entire library of (sometimes overlapping) functions with a SINGLE library.
And I dare to question, that people who are unable to balance their malloc() and free() calls should have anything to
do with a language that involves you to balance a stack on a line by line basis.

It's a completely RIDICULOUS comparison. Show me ANY 4tH program that uses 100 of these libs or more.
No - I pick them on a "need to have" basis. That's even the philosophy of 4tH: keep the core lean
and pick whatever you need on top of that!

> > It functions IMHO about the same way uBasic/4tH's GC does. But hat one
> > is about 50 (raw) lines. On the other hand (all raw lines of code):
> It sounds like you reclaim strings and arrays, but not structures
> containing pointers, which requires pointer tracing. That's where the
> complexity of gc comes from.
Well, it helps that uBasic/4tH's GC is only concerned with strings.. It's got no structures
to begin with. So why should I need code that does? And again: you lack in your research,
although everything is properly documented.
https://sourceforge.net/p/forth-4th/wiki/The%20strange%20strings%20of%20uBasic/

> How do you know when a string is ready to be reclaimed, anyway?
Read the documentation. If you had done your work properly - you'd already know that.

> I've written and maintained (simple) garbage collectors and it's not
> that bad. Very fancy ones can be complicated, just like anything else.
> I've implemented Lisp (including gc) and it's imho not harder or more
> complicated than implementing Forth. The execution efficiency of a
> simple implementation will be a lot worse, which might matter in some
> applications, but is fine in others. It is not messy or bloated, but I
> could accept that it is slow.
Fast, slow, compact, heavy error checking, speed of build - all those are thing that
you decide on a program by program basis - and there's always a tradeoff. Like I said:
I'm offering several tools in 4tH to achieve that. But IMHO quite Forth-like.
Not something that "one big thing that does it all" - but things you can use in particular
situations. E.g. the dynamic strings I use quite a lot in OOP applications. They're
easy to set up and nicely fit into a constructor and deconstructor.

> I think I see what you are getting at: a sufficiently skilled programmer
> is able to see how to simplify string concatenation and implement the
> simple-to-use version in Forth. They still have to spend effort on
> that. Now imagine that string concatenation is already handled by the
> language, so the skilled programmer can do something useful instead.
> You get the best of both worlds ;).
No. You still don't get it. A good library is written once and maintained. If a particular
situation is not well suited for that library, I write another one. And I simply multiply
my set of tools with every iteration. You need to write a huge one once and have to
cram it into every situation. That's not very Forth-like. That's Python.

> I do use Python and have written it for a living.
Oh dear - that should have been obvious from day one. My answer is always the same:
If you want to write C, write C. If you want to write Python, write Python. I have chosen
to write most of my stuff (also professionally) in 4tH. There is a reason why writing
conversion programs is so easy in 4tH, you see.

> I use Forth for fun
> sometimes, but yeah, I wouldn't call myself a Forth programmer the way
> some of the regulars here are.
So you've actually never written anything significant in Forth. It's like saying:
"Hey, I dabbled a few shopping lists. Now I've earned the right to comment on
"War and Peace".

> Do you mean runtime overhead? Do you really care?
When it concerns my core and I have to drag that functionality along with every
single program I write - even if I don't use it - yes.

> Is it something your compiler can't optimize away?
> If the overhead matters and your compiler
> can't optimize it, maybe it's better to spend the effort on the
> compiler, to simplify the applications.
Like I stated in my documentation: "the optimizer is not there to fix your crappy code".
If you had done your research properly, you'd known that:
https://sourceforge.net/p/forth-4th/wiki/Optimization/

Applications are simplified by really THINKING THEM OVER WELL - again, if
you still live the myth "languages can make beautiful programs, even if complete
morons use them", read Dijkstra. It's required reading in CS.

> They were used in Fortran, Lisp, and Algol long before there was such a
> thing as C, and (to the extent that Lisp is lambda calculus) they were
> used in lambda calculus (i.e. in math) long before there was such a
> thing as computers.
Well, surprise: they weren't in C, BECAUSE YOU HAVE A STACK FOR THAT.
That's the core principle of Forth.
> Have you ever used Lisp? You might give it a try sometime if you
> haven't. SICP ( https://mitpress.mit.edu/sicp ) is a great book. It
> uses Scheme, a very clean dialect of Lisp. The full text is online at
> that site.
I certainly find some elegance in Lisp. It was a programming language far
ahead of its time. And there are certainly lessons to be learned there.
The same goes for Forth. I advise you properly learn it one time. Or just
stick with Python.

> I find garbage collection to be among the most powerful of programming
> "guns". Locals are not a gun, they're more like a knife, and
> programming without them is like going to a knife fight with just your
> fists ;).
I find it excellent proof of the premise "If you write a language for idiots, only
idiots will use it".
> I did read the article, though maybe its point didn't reach me. Yes,
> you used Forth to discover the algorithm, but it seemed to me that you
> could have skipped some steps.
Hindsight is always 20/20.

> > The point is, that even if you have a difficult way to calculate the
> > fee for a long distance calls, Forthers don't stop to investigate it
> > until they've reached the bare essentials of the algorithm.
> This (about not stopping to investigate), I don't understand. I would
> also say someone better at algebra than I am would probably boil
> explaining the knight move algorithm down to the group action of the
> knight moves.
I'm saying you never read "Thinking Forth". QED.

> I don't see what that juggling of variables onto the Forth stack has to
> do with the underlying algorithm on that page. It's the same algorithm,
> except that the Forth version adds pain.
Then you've proven again you are incapable of writing proper Forth - since you
are desperately searching for things you know from Python to get the job done.

> They each put you through different contortions but it's the same
> algorithms underneath. The idea of a HLL, I thought, was to take care
> of those contortions so you don't have to.
You thought wrong.

>Yes, that makes things easier, but sometimes
> you want more than two.
> That's what a compiler is supposed to give you.
No, that's what YOU in particular NEED. It has nothing to do with what's REQUIRED.

> You code as if you had unlimited registers, and the compiler figures out
> how to funnel your data through the actual machine registers. Forth
> makes you do that yourself.
Tada! That's the entire philosophy! We're getting somewhere..
Everything is exposed and open - and you will have to take care of all of that yourself.
That opens endless possibilities to mold the language to your needs. But it's YOU
who has to do that. If you can't handle that, there are plenty of other programming
languages.

When I'm working with Python I constantly feel like I'm battling with it. It does things I didn't ask for,
If I want something very basic, it doesn't offer it to me. I'm constantly working around it.

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> And if you count the analytical engine, computers were long before the
>> lambda calculus.
>
>I suppose you are right. On the other hand, I wonder if Euclid's
>description of the Euclidean gcd algorithm used local variables.

It probably used variables (one may wonder how the original
description looked rather than the version we get taught at school).
Locals, probably not. One might consider the fact that every proof
and every lemma tends to use its own variables as a kind of local
variables.

>Certainly, other math algorithms like matrix multiplication are easiest
>to imagine as loops involving index variables. Those go back at least
>as far as the analytical engine.

The use of variables in connection with the sum symbol (big Sigma) and
integral symbol may be the most direct mathematical predecessors of
local variables. E.g., a mathematician would not write

$(\sum_{i=0}^n i)+i$

The i behind the closing parenthesis would be out of scope of the
variable i in the sum. Even if a mathematician would write it, it
would be a separate variable from the sum-local i.

In any case, variables have been in mathematics for a long time. They
are not quite the same variables as variables in imperative languages,
but implementing more mathematical variables (like logic programming
languages do) is even further from Forth than local variables in
imperative languages.

Mathematics has also introduced variable-less notations such as
Schoenfinkel's combinators (and even those started out with
variables), but only after a long time of using variables.

- 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 Saturday, March 5, 2022 at 3:50:27 AM UTC+1, Paul Rubin wrote:
> Typeless programming. Truly typeless languages include Assemblers,
> BCPL and, to a minor extent, C; these languages regard raw memory as
> the fundamental data structure. Large systems programmed in this
> style become very hard to debug and maintain, hence we dismiss these
> languages as obsolete, undisciplined, and unreliable. Although C
> has a relatively rich notion of typing, the type enforcement is too
> weak to lead predictably to robust systems.
There are pretty large systems in use that have run reliably for DECADES.
The "Bell report" has clearly shown that programming languages have NOTHING
to do with "software rot". It has to do with inapt programmers, who either have NO
architecture or maintenance by inapt programmers that that VIOLATE this architecture.

I dare to say that the most unmaintainable body of legacy programs is formed by
COBOL - another effort to make programs "readable".

OOP was another promise of "maintainable software" - which has NEVER been proven
statistically. OOP programs are as much volatile to "software rot" as imperative programs.
And "lasagna" programs are really a thing..

> I would put Forth in the "assembler" category under this classification.
> The basic data structure is raw memory (plus the stacks). So dealing
> with pointer-related bugs is hard. If you program in Python for a
> while, pointers are used far more heavily, but their usage is controlled
> by the interpreter rather than allowed to run amuck, so debugging is
> usually pretty easy.
Untrue again. 4tH keeps track of every memory access - so pointer failures pop
immediately - without typing. Yes, that takes time - but compared to most C based
Forths its not particularly slow. Most of all because if you want to move a massive amount
of data, these are performed low level - after checking it's boundaries.

So - such things are not bound to languages like Python you are so fond of..

Hans Bezemer

Paul Rubin <no.email@nospam.invalid> writes:
> strcat(strcat(strcat(strcpy(hello,"Hello"), " "), "world"), "!");
>
>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

My approach is:

[: ." Hello" ." " ." world" ." !" ;] >string-execute

>That is nice, but where does the storage for the new string come from,
>and do you have to remember to free it when you are done with it?

For >STRING-EXECUTE, it's allocated, and yes, you have to remember that.

One significant advantage of >STRING-EXECUTE over typical
implementations of string concatenations is that the overhead is
(amortized) proportional to the length of the result. This plays a
role when you produce the string for a long list of things. In the
following I don't want to generate a list first, so I just conatenate
the string representation of a bunch of numbers.

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

Performance counter stats for 'python':

668498.50 msec task-clock # 1.000 CPUs utilized
2723 context-switches # 0.004 K/sec
4 cpu-migrations # 0.000 K/sec
248304710 page-faults # 0.371 M/sec
2673971672630 cycles # 4.000 GHz
1358004536920 instructions # 0.51 insn per cycle
190624556842 branches # 285.153 M/sec
459106329 branch-misses # 0.24% of all branches

668.538656855 seconds time elapsed

380.227153000 seconds user
288.268325000 seconds sys

1 1000000 6888891
[~/gforth:128445] perf stat gforth-fast -e ': print-nums 0 do i . loop ; [: 1000000 print-nums ;] >string-execute type bye' |wc

Performance counter stats for 'gforth-fast -e : print-nums 0 do i . loop ; [: 1000000 print-nums ;] >string-execute type bye':

276.31 msec task-clock # 0.922 CPUs utilized
417 context-switches # 0.002 M/sec
0 cpu-migrations # 0.000 K/sec
3103 page-faults # 0.011 M/sec
1077579819 cycles # 3.900 GHz
2279449568 instructions # 2.12 insn per cycle
209603216 branches # 758.572 M/sec
2098737 branch-misses # 1.00% of all branches

0.299534537 seconds time elapsed

0.269402000 seconds user
0.007923000 seconds sys

0 1000000 6888890

This difference is not because Python in general is so much slower,
but because it uses a quadratic algorithm (actually a little worse
than quadratic). I am wondering why Python spends so much system
time. Does it unmap pages on every garbage collection and remap them
on allocation? Ugh. In any case, a watched Python 8 minutes into
this computation, and it had about 45-50MB of resident set size
(compared to 16MB RSS by Gforth at the end of the computation).

The one character difference is due to Python emitting a newline and
Gforth not doing this.

- 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:
>Rick C <gnuarm.deletethisbit@gmail.com> writes:
>> If a pointer is passed
>> into a routine, there is no way to know what it points to.

Nonsense. The one who passes it knows what it points to.

>That is why languages like Rust are getting so much attention now: the
>compiler is able to track pointer usages across an entire large program
>instead of the immediate context of (e.g) and IF statement, to make sure
>the pointer contents are always sane.

Programmers make use of local knowledge at every point to reason about
programs (in particular, that it does what they intend).

Type systems like that of Rust try to formalize that knowledge so the
compiler can check it. It's also local knowledge, not some magic
emergent property of looking at the whole program; the latter would be
unmanageable by programmers.

What Rust does is to make that knowledge explicit and to let the
compiler check it, so any mistakes by the programmers show up at
compile time, especially if things change in maintenance. Supposedly
the type system of Rust is sophisticated enough to cover nearly all of
the program, yet not too complicated to use. We will see if it really
succeeds at that. For now it seems to me that it's mostly used by
fans, generates a lot of hype, but most of the programming world is
still in wait-and-see mode wrt Rust.

>C is still alive only because it was
>historically huge, and (like COBOL), lots of old C codebases are still
>doing important things.

C is still alive despite attempts by the C compiler maintainers (who
program in C++) to turn it into a C++--, because despite these
attempts, it is not yet unusable as a close-to-the-metal language, and
we need such a 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 03/04/2022 03:10 PM, Ala'a wrote:
> Hi Richard,
>
> YMMV, but checkout http://www.ultratechnology.com/, if you didn't already.

I don't recall having seen that page recently. However a DuckDuckGo
search for "philosophy" seemed to have some interesting hits.

>
> Also from the same site, check this one specifically http://www.ultratechnology.com/method.htm

*THANK YOU*!
> This methodology, framing a programming task here, can be applied
> to designing hardware, it has, or to any type of problem.

That page is about as close as I can expect to come to an explicit
answer to my post. It also hints at a methodology for attacking a
problem I've been gnawing at for about fifteen years.
Thanks again.

>
> Hope it help.
>
> regards,
>

On Saturday, March 5, 2022 at 3:30:49 PM UTC+1, Anton Ertl wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> >Rick C <gnuarm.del...@gmail.com> writes:
> >> If a pointer is passed
> >> into a routine, there is no way to know what it points to.
> Nonsense. The one who passes it knows what it points to.
ROFL! I like dry humor! Some people really have no clue, Anton!

HB

On Saturday, March 5, 2022 at 3:16:38 PM UTC+1, Anton Ertl wrote:
[..]
> [~/gforth:128445] perf stat gforth-fast -e ': print-nums 0 do i . loop ;
> [: 1000000 print-nums ;] >string-execute type bye' |wc
[..]
> - anton

[: and ;] have no interpretation semantics? ( pdf on Forth2000 site )

I also could not find >string-execute in the online Gforth manual.
Is it correct to assume that in this case the output of print-nums
is redirected into a string that is then passed to TYPE ?

-marcel

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> That's at least 20% more than your previous estimate. Do you always
> get into a discussion without getting your facts right?

400 was your number, not mine. I never posted that number.

> And again: I never made any comment concerning its quality. I just
> stated "it's massive". And it is..

I'd consider its size unremarkable. That 4th's source files are smaller
doesn't mean much. The gc could have been spread across more files if
there was some desire to make the files smaller. But the actual size is
quite reasonable, it seems to me.

> And I dare to question, that people who are unable to balance their
> malloc() and free() calls should have anything to do with a language
> that involves you to balance a stack on a line by line basis.

These aren't comparable, as the gc document explains. malloc/free bugs
are a notorious source of errors in C programs. If Forth programs are
as prone to stack balance errors as C programs are to malloc/free
errors, that basically says Forth is unusable. I haven't found it that
way though. Stack balance is normally a completely local property, that
can be checked by examining the program words one at a time. dynamic
memory allocation is deep-down non-deterministic. Standard Ada doesn't
even allow it (including malloc/free), because of that non-determinism.
Ada has something like malloc, but no free. The idea is you allocate
during program startup, and then consider those allocations fixed (not
dynamic) for the rest of the program execution.

> It's a completely RIDICULOUS comparison. Show me ANY 4tH program that
> uses 100 of these libs or more.

The comparison is perfectly valid since the maintenance burden reflects
the total code size, not how many libs are used simultaneously.

> Well, it helps that uBasic/4tH's GC is only concerned with
> strings.. It's got no structures to begin with.

Didn't you write:

- Dynamic array (sequential) is 65 lines;
- Dynamic array (random) is 45 lines;
- Dynamic strings is 30 lines;
- Arena allocation is 85 lines.

Is that 4 different gc-like operations? Seems simpler to have a single
one rather than 4. What if you add something like dictionaries? We
know from Python that those are very handy. And of course you want to be
able to nest them. Your doc says your ubasic has its own string stack
and scans it for string references to reclaim string memory. But what
if a 4th program (not ubasic) wants to use those strings? Now if you
add dictionaries to 4th, the string gc has to scan any dictionaries to
find string references, etc.

> No. You still don't get it. A good library is written once and
> maintained. If a particular situation is not well suited for that
> library, I write another one.

If you have to write another one because the first one didn't handle
enough situations, maybe the first one wasn't so good.

> So you've actually never written anything significant in Forth.

If your idea of "massive" is Anton's gc library, then ok, I've written
some sizeable (maybe not massive) Forth programs. I wouldn't consider
them significant. I do notice that it takes me a lot more effort to
implement something in Forth than in other languages, but maybe that's
just me.

>> Do you mean runtime overhead? Do you really care?
> When it concerns my core and I have to drag that functionality along
> with every single program I write - even if I don't use it - yes.

This is about locals, which usually don't cost any runtime overhead if
you don't use them. I guess it depends on the implementation though.

> Like I stated in my documentation: "the optimizer is not there to fix
> your crappy code".

If your optimizer can't fix something, it must be crappy?

> I'm saying you never read "Thinking Forth". QED.

I did read that book. It was great.

> No, that's what YOU in particular NEED. It has nothing to do with
> what's REQUIRED.

I see, if your compiler can't do it, it must not be required. lxf does
it though.

>> You code as if you had unlimited registers, and the compiler figures out
>> how to funnel your data through the actual machine registers. Forth
>> makes you do that yourself.
> Tada! That's the entire philosophy! We're getting somewhere..

That's awful, why not code in assember directly? At least then you
usually get a linker that can resolve forward references, you get your
machine's registers and addressing modes instead of being limited to
Forth's, etc.

> Everything is exposed and open - and you will have to take care of all
> of that yourself.

There's an unconvincing rationalization going on here. Early Forth ran
on extremely memory starved machines. As I understand it, the
dictionary even in Polyforth used only the first 3 characters of the
word name, plus its length, to distinguish words. So ABCDEF and ABCXYZ
were considered the same word. I wonder if there were battles in the
Forth world when people first proposed treating the two names as
distinct, rather than making the programmer distinguish them as a form
of spiritual purity. Blocks vs files were another thing like that.
Blocks are now mostly gone, but I believe they had defenders.

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, CPUs keep getting more and
more registers. Doing all that stack juggling is a painful abstraction
inversion. When trying to factor code to make stack items land in the
right places, I found myself thinking "wait, this is exactly what a
compiler is supposed to do".

> That opens endless possibilities to mold the language to your needs.
> But it's YOU who has to do that.

Why me? Why not just import a library and use it, if the library has
already been written? Isn't the story of civilization to keep advancing
progress, by building on the work of others? If we have usable
libraries for GC and locals, using them seems like a good thing to me.

> If you can't handle that, there are plenty of other programming
> languages.

I would say if you want mental exercise as a way to keep your mind
engaged, chess problems, writing Forth code, and (lately) Wordle all are
nice for that, and I do all three. If you are trying to write code for
utilitarian purposes, then it's silly to choose a language that's
uncompetitive with alternatives. And it's hard to pitch Forth as
competitive when it imposes so much extra work on the programmer,
without concrete benefits.

> When I'm working with Python I constantly feel like I'm battling with
> it. It does things I didn't ask for, If I want something very basic,
> it doesn't offer it to me. I'm constantly working around it.

Python has annoyances, for sure. But if Forth is so great, can I ask
why so much of 4th is written in C?

Fwiw, in current trunk, it looks to me like comp_4th.c is 4282 lines
(2451 SLOC per sloccount). The gc library is small compared to that.

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

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

where xrange is a python2 thing that makes a range iterator rather than
building up the entire range as a list in memory. In python3 you would
just use range.

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> There are pretty large systems in use that have run reliably for
> DECADES. The "Bell report" has clearly shown that programming
> languages have NOTHING to do with "software rot". It has to do with
> inapt programmers, who either have NO architecture or maintenance by
> inapt programmers that that VIOLATE this architecture.

What is the "Bell report"? And yes, blame the programmers for
everything ;). I've written and debugged lots of C code. Writing it is
not so bad. Debugging can be very painful, because of issues with
memory corruption. It's a lot easier when references are all checked
etc.

And it's very rare to find a C program (even a "reliable" one) that can
really stand up to adversarial testing, without a lot of hardening
iterations first. That's what so many CVE's are about. In the embedded
world maybe it's not so bad, since the adversary has less control over
the program inputs.

> OOP was another promise of "maintainable software"

Yes, in some circles we think of OOP as a 1990s idea that sounded
interesting but didn't work out.

Richard Owlett <rowlett@cloud85.net> writes:
>> http://www.ultratechnology.com/method.htm ...
> That page is about as close as I can expect to come to an explicit
> answer to my post.

You might like the book Thinking Forth, if you're not already familiar
with it. It is a book-length treatment of this philosophy.

http://thinking-forth.sourceforge.net/

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Type systems like that of Rust try to formalize that knowledge so the
> compiler can check it. It's also local knowledge, not some magic
> emergent property of looking at the whole program; the latter would be
> unmanageable by programmers.

It's not a magic emergent property like a programmer might concoct in a
typeless program, and which is indeed unmanageable. The idea is that
the type system prevents that from happening, though there is an
"unsafe" escape route.

I haven't tried Rust yet. Its users seem to like it and believe in it
and they have done some pretty substantial things in it. The Ada
community is skeptical. I haven't yet seen any really knowledgeable
comparisons. I do know that Rust has inspired some additions and
extensions to Ada.

I haven't yet personally encountered a need for what Rust supposedly
supplies, which is dynamic memory allocation and reclaiming without
garbage collection. Single-ownership pointers (std::unique_ptr in C++
or there is some similar thing in Ada), and/or gc, have been good enough
for situations I've been in so far. I can imagine situations where I'd
want Rust though.

On Saturday, March 5, 2022 at 7:34:16 PM UTC+1, Paul Rubin wrote:
> Fwiw, in current trunk, it looks to me like comp_4th.c is 4282 lines
> (2451 SLOC per sloccount). The gc library is small compared to that.
That's comparing a car with a caravan. It's ridiculous. The car goes somewhere.
The caravan merely augments a car. And if you want to know more about
4tH and its history - download it. It's all documented.

You're really bad at research are you?

Hans Bezemer

On Saturday, March 5, 2022 at 7:34:16 PM UTC+1, Paul Rubin wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> I'd consider its size unremarkable.
I don't.

> That 4th's source files are smaller doesn't mean much.
To me it does.

> The gc could have been spread across more files if
> there was some desire to make the files smaller. But the actual size is
> quite reasonable, it seems to me.
Not to me. Note (apart from FP and the like) most 4tH libs are atomic:
they have use on their own. I doubt there are many useful parts that can stand
on itself in the GC library.

> These aren't comparable, as the gc document explains. malloc/free bugs
> are a notorious source of errors in C programs.
I can't remember I ever had one. But there is a certain discipline required in using
malloc() and free() and still keep it maintainable.

> If Forth programs are
> as prone to stack balance errors as C programs are to malloc/free
> errors, that basically says Forth is unusable.
The clause between IF, ELSE and THEN. Have to be balanced. Same with
BEGIN, WHILE REPEAT with multiple exits.

> I haven't found it that
> way though. Stack balance is normally a completely local property, that
> can be checked by examining the program words one at a time. dynamic
> memory allocation is deep-down non-deterministic.
Again, depends how you use it.

> Standard Ada doesn't
> even allow it (including malloc/free), because of that non-determinism.
> Ada has something like malloc, but no free. The idea is you allocate
> during program startup, and then consider those allocations fixed (not
> dynamic) for the rest of the program execution.
Makes sense in a way - if you want to make a language for n00bs.
But then again - it's the one language Dijkstra hated. For good reasons, it seems.

> The comparison is perfectly valid since the maintenance burden reflects
> the total code size, not how many libs are used simultaneously.
This is so preposterous that I can see you never maintained a significant body of
code for years.

> Didn't you write:
> - Dynamic array (sequential) is 65 lines;
> - Dynamic array (random) is 45 lines;
> - Dynamic strings is 30 lines;
> - Arena allocation is 85 lines.
Yes - those are 4tH libraries. The GC of uBasic/4tH uses ONE of these libraries.
> Is that 4 different gc-like operations? Seems simpler to have a single
> one rather than 4.
No, it's not. I can take the tool that is required for the job. Are you working for a
bloatware company like Microsoft? It really seems like it.. "Well, let's throw in
everything but the kitchen sink - we might need it at some point or another. And
if it doesn't fit, we give it a good whack".

> What if you add something like dictionaries? We
> know from Python that those are very handy.
YOU may not be able to live without dictionaries. I can live very well without them.

> And of course you want to be
> able to nest them. 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.

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

> Now if you
> add dictionaries to 4th, the string gc has to scan any dictionaries to
> find string references, etc.
No, it doesn't.

> If you have to write another one because the first one didn't handle
> enough situations, maybe the first one wasn't so good.
No, it was written for a particular situation. May be the next one doesn't require
all its features - so I write a simpler one. But I can speak from experience that
number of different requirements is limited. At some point in time you
will reach a point that you got all the bases covered.

> If your idea of "massive" is Anton's gc library, then ok, I've written
> some sizeable (maybe not massive) Forth programs. I wouldn't consider
> them significant. I do notice that it takes me a lot more effort to
> implement something in Forth than in other languages, but maybe that's
> just me.
Then why bother? Why torture yourself? Write Python and be happy.

> This is about locals, which usually don't cost any runtime overhead if
> you don't use them. I guess it depends on the implementation though.
It certainly does. You have to free them. BTW, I have locals in uBasic/4tH..

> If your optimizer can't fix something, it must be crappy?
I consider SWAP 2DROP crappy, yeah.

> > I'm saying you never read "Thinking Forth". QED.
> I did read that book. It was great.
You couldn't even remember the "long distance phone call" example.
Must have been a long time ago.

> I see, if your compiler can't do it, it must not be required. lxf does
> it though.
No, what I'm saying is that if you have your own compiler and you need something
(or your users request things) you add them. That's the privilege you have
when you maintain your own compiler. The fact that that I didn't add them means
I DON'T require them.

> That's awful, why not code in assember directly? At least then you
> usually get a linker that can resolve forward references, you get your
> machine's registers and addressing modes instead of being limited to
> Forth's, etc.
That was fun too - but not too portable. So, 4tH.

> There's an unconvincing rationalization going on here.
No, there isn't. Again, you didn't read "Thinking Forth" - or you still haven't got it.

> Blocks are now mostly gone, but I believe they had defenders.
Blocks have their advantages. Again, there are situations where I'd prefer blocks over files.
https://sourceforge.net/p/forth-4th/wiki/16%20Blocks/

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

> Doing all that stack juggling is a painful abstraction
> inversion. When trying to factor code to make stack items land in the
> right places, I found myself thinking "wait, this is exactly what a
> compiler is supposed to do".
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.

> Why me? Why not just import a library and use it, if the library has
> already been written?
As a matter of fact - I do that all the time. 4tH has got over 500 of 'em.

> Isn't the story of civilization to keep advancing
> progress, by building on the work of others? If we have usable
> libraries for GC and locals, using them seems like a good thing to me.
If I need them to solve a problem - yes, I do so. If I don't need them because
I can use an alternative solution (which is quicker, better maintainable, faster)
I don't.

> If you are trying to write code for
> utilitarian purposes, then it's silly to choose a language that's
> uncompetitive with alternatives.
And there you're wrong. I once wrote a program in 4tH - in five days. Estimate for
C was three months.

> And it's hard to pitch Forth as
> competitive when it imposes so much extra work on the programmer,
> without concrete benefits.
Not for those who are confident using it.

> Python has annoyances, for sure. But if Forth is so great, can I ask
> why so much of 4th is written in C?
Download it - it's all documented. I didn't document it all in order to repeat
it to people who are too lazy to do their research and read the stuff.

Hans Bezemer

On Saturday, March 5, 2022 at 7:59:16 PM UTC+1, Paul Rubin wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> What is the "Bell report"?
You're really lazy. Google it! "Software decay" "Bell Labs".

> And yes, blame the programmers for
> everything ;)
I think we can agree programs don't write themselves.. And I'm not the kind
of artisan who blames his tools for delivering a lousy product (unless it's Java).

> I've written and debugged lots of C code. Writing it is
> not so bad. Debugging can be very painful, because of issues with
> memory corruption. It's a lot easier when references are all checked
> etc.
Again - I don't know where you get all this memory errors from.. Be disciplined!

> And it's very rare to find a C program (even a "reliable" one) that can
> really stand up to adversarial testing, without a lot of hardening
> iterations first.
That should be part of your design. Otherwise - it' sloppy work.

Hans Bezemer

Marcel Hendrix <mhx@iae.nl> writes:
>On Saturday, March 5, 2022 at 3:16:38 PM UTC+1, Anton Ertl wrote:
>[..]
>> [~/gforth:128445] perf stat gforth-fast -e ': print-nums 0 do i . loop ;
>> [: 1000000 print-nums ;] >string-execute type bye' |wc
>[..]
>> - anton
>
>[: and ;] have no interpretation semantics? ( pdf on Forth2000 site )

Gforth adds interpretation semantics.

>I also could not find >string-execute in the online Gforth manual.

I am somewhat behind in updating the documentation.

HELP >STRING-EXECUTE

shows the source code in this case, which includes documentation:

\G execute xt while the standard output (TYPE, EMIT, and everything
\G that uses them) is redirected to a string. The resulting string
\G is addr u, which is in ALLOCATEd memory; it is the
\G responsibility of the caller of >STRING-EXECUTE to FREE this
\G string.

>Is it correct to assume that in this case the output of print-nums
>is redirected into a string that is then passed to TYPE ?

Correct. Of course given that I TYPE the string, and nothing relevant
happens in between, using >STRING-EXECUTE is just overhead here, but
apparently the example was understandable enough.

- 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:
>Stack balance is normally a completely local property, that
>can be checked by examining the program words one at a time. dynamic
>memory allocation is deep-down non-deterministic.

ALLOCATE and FREE are deterministic, and can be used correctly. It's
just that they require a global view of the program that makes the
program hard to maintain; alternatively, you have to subject yourself
to restrictive disciplines like those enforced by Rust's type checker
(only in Forth without a type checker to enforce it), which imposes
cost in both programming time and run-time: e.g., you might copy the
data in order to avoid multiple pointers to the same memory, so you
know you can FREE it when you no longer need the pointer.

>Standard Ada doesn't
>even allow it

Since when? Last I heard, Ada had "new" (dynamic allocation), and had
not standardized garbage collection.

<https://www.adaic.org/resources/add_content/docs/craft/html/ch11.htm>
(a book about Ada 95) says:

|What is needed is a way of telling the system to deallocate the memory
|so that it can be reused by anything that needs it. The way to do this
|is to use the standard procedure Ada.Unchecked_Deallocation. As the
|name implies, there is no check made that the memory is actually free
|and that you don’t still have an access variable pointing to it

- 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