Re: portable or not? Volatile strings

mhx@iae.nl (mhx) writes:

Having a built-in string type denoted
by quotes might be a good thing. It is hard to find a argument
against that when numbers are already a comparable exception that
nobody has found a way to get rid of.

Mitch Bradley introduced parsing words for numbers, which would allow
to get rid of the number recognizers.

But yes, the mainstream is in the opposite direction: Introduce
recognizers not just for numbers, but also for strings, and a
mechanism for user-defined recognizers.

And maybe we can then even
tick strings and numbers like everything else?

I explored this idea in a EuroForth 2016 paper, in particular in
Section 4.1.

@InProceedings{ertl-recognizers16,
  author =       {M. Anton Ertl},
  title =        {Recognizers: Arguments and Design Decisions},
  crossref =     {euroforth16},
  pages =        {58--63},
  url =          {https://www.complang.tuwien.ac.at/papers/ertl-recognizers16.pdf},
  video = {https://wiki.forth-ev.de/lib/exe/fetch.php/events:recognizers.mp4},
  OPTnote =      {not refereed},
  abstract =     {The Forth text interpreter processes words and
                  numbers.  Currently the set of words can be extended
                  by programmers, but not the recognized numbers.
                  User-defined recognizers allow to extend the
                  number-recognizer part, too.  This paper shows the
                  benefits of recognizers and discusses
                  counterarguments.  It also discusses several design
                  decisions: Whether to define temporary words, or a
                  set of interpretation, compilation, and postponing
                  actions; and whether to hook the recognizers inside
                  \code{find} or in the text interpreter.}
}

@Proceedings{euroforth16,
  title = {32nd EuroForth Conference},
  booktitle = {32nd EuroForth Conference},
  year = {2016},
  key = {EuroForth'16},
  url =          {https://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/proceedings.pdf}
}

The discussion has moved on since then, and getting the xt of a
recognized thing is not something that anyone (including me) found
worth the cost, so AFAIK nobody has implemented the temporary-word
approach.

However, if we adopt Gerry Jackson's attitude and make every transient
region permanent, creating a new permanent word (in a separate
section) for every parsed number, string, etc. is fine, and ticking
that word is fine, too.  For most programs, the space taken by the
recognized words is proportional to the size of the source code, which
is acceptable on desktops with GBs of RAM.  However, programs that use
EVALUATE a lot will need more recognized-word storage.  A contrived
example is:

: foo 1000000000 0 ?do s" 123" evaluate drop loop ; foo

You might imagine optimizing this by using only one definition for all
these occurences of "123", so here's another example where that
optimization would not work:

: bar 1000000000 0 ?do i 0 <# #s #> evaluate drop loop ; bar

Of course, if you make all transient regions permanent, already the <#
#s #> consumes a lot of memory in BAR, and the recognized words just
increase this by a constant factor.

While I have some sympathies for the idea of permanent "transient"
data (e.g., in Gforth S"'s intepretation semantics produce a string
that lives until the end of the session, I don't think that this would
find consensus in the standards committee.

And if you really want an execution token for a string or number,
writing

[: s" foo" ;] [: 123 ;]

inside a colon definition (or the same with :NONAME ... ; outside a
colon definition) seems easy 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: https://forth-standard.org/
   EuroForth 2024: https://euro.theforth.net