Re: Parsing timestamps?

minforth <minforth@gmx.net> writes:

Am 01.07.2025 um 23:47 schrieb peter:

In lxf64 I have introduced a local stack with the same capabilities as
the data and return stack. I am not sure yet if this is better.
 
The nice thing is that I now have >ls ls> and ls@. Compared with the
return stack this also works across words. One word can put stuff on
the localstack and another retrieve it. This is sometimes very useful.

>
In a sense, such locals become global. I am not sure if this opens the
way inadvertently for hard-to-detect bugs.

This stack combines some properties of the data stack (it not
disturbed by calls) with some of the return stack (you put stuff there
and remove it explicitly, which most words not doing anything
permanent there).  However, the interaction of explicit use with use
through locals will mean restrictions; we have a similar situation
with the return stack and counted loops and calls and returns, and we
have learned to deal with that.

Only one useful application comes to my mind: sharing locals between
quotation and its parent function, i.e. for creating closures.

This does not create closures; for some limited usage it behaves like
a closure would behave, but in other uses it does not.  Such problems
already plagued Algol 60 compilers, and Knuth wrote the man-or-boy
test to check for them.

But who
needs thema anyway?

Since we implemented closures in 2018 [ertl&paysan18], we have finally
found a compelling use of closures:

We have an actor-like model for letting tasks (threads) talk to each
other, inspired by Heinz Schnitter's Open Network Forth.  One task
sends a word to another task, and that task executes that word at some
point.  Now we want to send parameterized words to another task (e.g.,
do not just print "hello" in the other task, print something that may
reflect data from the sending task).  To do this, we create a one-shot
closure that passes data along with the executed code to the receiving
task and burns (deletes) itself after execution; see
<file:///home/anton/gforth/doc/gforth/Message-queues.html>.

We originally had a separate mechanism for passing data, but once we
had closures, this became superfluous and was simplified away.

@InProceedings{ertl&paysan18,
  author =       {M. Anton Ertl and Bernd Paysan},
  title =        {Closures --- the {Forth} way},
  crossref =     {euroforth18},
  pages =        {17--30},
  url =          {https://www.complang.tuwien.ac.at/papers/ertl%26paysan.pdf},
  url2 =         {http://www.euroforth.org/ef18/papers/ertl.pdf},
  slides-url =   {http://www.euroforth.org/ef18/papers/ertl-slides.pdf},
  video = {https://wiki.forth-ev.de/doku.php/events:ef2018:closures},
  OPTnote =      {refereed},
  abstract =     {In Forth 200x, a quotation cannot access a local
                  defined outside it, and therefore cannot be
                  parameterized in the definition that produces its
                  execution token.  We present Forth closures; they
                  lift this restriction with minimal implementation
                  complexity.  They are based on passing parameters on
                  the stack when producing the execution token.  The
                  programmer has to explicitly manage the memory of
                  the closure.  We show a number of usage examples.
                  We also present the current implementation, which
                  takes 109~source lines of code (including some extra
                  features).  The programmer can mechanically convert
                  lexical scoping (accessing a local defined outside)
                  into code using our closures, by applying assignment
                  conversion and flat-closure conversion.  The result
                  can do everything one expects from closures,
                  including passing Knuth's man-or-boy test and living
                  beyond the end of their enclosing definitions.}
}

- 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: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/