Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mhx@iae.nl (mhx)
Newsgroups: comp.lang.forth
Subject: Re: Parsing =?UTF-8?B?dGltZXN0YW1wcz8=?=
Date: Fri, 20 Jun 2025 06:21:40 +0000
Organization: novaBBS
Message-ID: <f4aaff9dbf58ca3c0e5da7fe278b5a87@www.novabbs.com>
References: <1f433fabcb4d053d16cbc098dedc6c370608ac01@i2pn2.org> <7e21117d37c506cccd8e79323c416fd1@www.novabbs.com> <1021bsd$31o0d$1@dont-email.me> <b5802b3faad00b9a4397e1e445561681d0cd6ce5@i2pn2.org> <6ced001912d95b520dad9d25a6014342@www.novabbs.com> <60ca19340523b1ddfa4a2cbf1ac0995cb185cdcb@i2pn2.org> <nnd$16a55d5e$0e5ab22d@1d9c51e25014f149> <bdc732e87e38233e9e23f254b2326cf2@www.novabbs.com> <nnd$1a4144e5$43cad09f@b57c0b5013a1f2ab> <6ea4ccd1cb6ae8c828144444fe51fea9@www.novabbs.com> <70a3014f99baf5e43b32e1320d7b8cd482be04c1@i2pn2.org> <bfc6dc31af5bcbe4b4b0a2ccba8167e3@www.novabbs.com> <a8647abe1ce54c9c55c558f571761214a7c9d0f0@i2pn2.org> <b2949b6c63cadd3c42ce030989b2ba0b@www.novabbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1255191"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="J+nubxJRM7ncpF4l6KLO+OONWmFAYJHVJegfwQXJ8vc";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$JV/4fzDZEyUNvPQ3lMz4JOAqTv2HQMO7nWLoIsIsGHDx7W6S/OJSS
X-Rslight-Posting-User: 4e0dc1fdad1ead10b39e7eb5db19bf73d73e3ab3

On Fri, 20 Jun 2025 5:36:05 +0000, minforth wrote:

> Counter-example: a good number of my apps involve structs, arrays
> and signal vectors in heap memory. Stack juggling? Absolutely not.
> The code would be unreadable and a nightmare to debug.
>
> Factoring in smaller code portions is often impossible because
> you can't always distribute data, that inherently belongs together,
> over separate words.
>
> Then why factor, when with using named parameters = locals, the
> code is already short, readable, maintainable, and bug-free.

Interesting questions. My experience says that arrays and vectors are
ok, but structs are dangerous, (especially?) when nested. In a 'C'
project that I contribute to, structs arbitrarily glue data together,
and then forwardly defined macros hide the details.
It is impossible to debug this code without tools to decompile/inspect
the source. It is very difficult to change/rearrange/delete struct
fields, because they may be used in other places of the code for a
completely different purpose. The result is that structs only grow
and nobody dares to prune them. The only remedy is to completely
start over.

> Ask yourself why the Forth Scientific Library makes heavy use of
> locals.

Because the original algorithms do.

> Of course things look different with simpler applications.

And then Einstein's famous quote spoils the fun.

-marcel