Re: Parsing timestamps?

On Mon, 23 Jun 2025 5:40:37 +0000, mhx wrote:

On Sun, 22 Jun 2025 21:27:40 +0000, minforth wrote:
>
[..]

So, I made me a small extension to the locals word set. Using your
example SPIN (abc — cba), I can define it as follows:
: SPIN { a b c == c b a } ; \ no need for additional code before ;
or likewise for floats, doubles, strings, matrices
: FSPIN { f: a b c == c b a } ;
: DSPIN { d: a b c == c b a } ;
: "SPIN { s: a b c == c b a } ;
: MSPIN { m: a b c == c b a } ;
Code generation and register optimization is the computer's job.
>
SPIN/STOW or similar microexamples can, of course, be defined quickly
with classic Forth stack juggling too. The power of the extension
becomes more apparent with mixed parameter types and/or more parameters,
and of course, with some non-trivial algorithm to solve.

>
Do you mean your compiler automatically handles/allows combinations
like
... 22e-12 69. A{{ ( F: -- a ) ( D: -- b ) ( M: -- c ) SPIN ...
>
I found that handling mixed types explodes the code that needs
to be written for a simple compiler like, e.g., Tiny-KISS . It
would be great if that can be automated.

I don't know if I got you right, because as previously
defined, SPIN expects three integers on the data stack.
However, following your idea, a mixed SPIN could be defined e.g.
: XSPIN { f: a d: b m: c == c b a } ;
that can work with
.. 22e-12 69. A{{ XSPIN ...
I think gforth has allowed mixed type locals for a long time,
so they are nothing really special.
The only new word is == which pushes the locals following
== on the stack before the word terminates with a ; or EXIT.
This releaves you of the need to keep track of the data stack.
A brief stack depth check can also catch some mistakes.
I always found the conventional syntax wasteful, where
everything after a -- does nothing but inform the reader.
--