Re: Parsing timestamps?

On 10-06-2025 11:52, LIT wrote:

First, a stack has been invented to be used as well.

 ..which doesn't deny use of variables where it's useful.

..which doesn't deny use of a stack where it's useful.

You're sorry that you 'have' (IYO) to use the stack
not quite senseful way? They force you to do so?
Poor you.

You don't fart (loudly) in the middle of a wedding.

Contact me with your "recommendation" again when you
become appointed of some kind of 'authority' who'll
decide, who should use what. Until then - I'll use
whatever language I'll decide to use at the moment.

That in itself would be a logical fallacy ("call to authority"). That you're serious considering this is committing this very logical fallacy. Given that you seem to be collecting logical fallacies, that's not much of a surprise.
You have to start learning that someone not agreeing with you leaves you two options: 1. Simply ignoring it, or: 2. Debating the issue in a civilized manner.
I'm not saying you can't hammer a screw into the wall, I'm just saying it's not the best way to do it. The language was not designed for that. There are plenty of sources concerning the design objectives and suggested usage of the language. I'm particularly fond of "Thinking Forth". You want some quotes from that volume?

Yes, indeed - these CPUs have a stack, and what you've
presented is pointless stack jugglery. We may 'burn CPU
cycles' to do something useful - or, following you (if
anyone would be keen, which I doubt) we could use that
stack for pointless moving the bytes "Back and Forth".

Of course there are ways to XOR your way around the stack without ever using a SWAP, e.g. "OVER XOR DUP >R XOR DUP R> XOR". I don't think it will enhance your Forth experience, though. Although it may make you feel a little better.

Oh, really? That speaks in favor of the most clean solution.

According to Locke, "clean" is a secondary quality - AKA, in the eye of the beholder. "Canonical", since it refers to a standard, is not.

Yes, software comes with many qualities - and one of them,
which you didn't mention (maybe you have no clue), is
clarity of the code. The code filled with strings of that
DUPs, SWAPs and ROTs not only works inefficiently, but also
rather quickly becomes unreadable. And then serves as
another example of 'typical write-only Forth code'.

"Clarity" must be codified, otherwise it is (like "clean") a secondary quality - and hence open to endless debate. Are strawberry milkshakes *really* tastier than chocolate ones?
It must be clear by now that stack instructions are *not* the cause of bad performance (next time, do your homework before posting stupid things). So, this straw does not provide any hold.
As I stated, I have no trouble to maintain multi-KLOC codebases in Forth for decades on end. That you obviously cannot, may illustrate your capabilities as a Forth programmer, though. There is no shame in that. We all had to start there. The best antidote though, is to learn. Even winning a debate doesn't improve your programming skills a shred.
Hans Bezemer