Proposal: String store and fetch

Considered

This page is dedicated to discussing this specific proposal

ContributeContributions

albertavatar of albert [313] String store and fetchProposal2023-11-12 13:12:55

Hint: Please delete the blockquote explanations, they are just for your convenience while writing the proposal

Author:

Albert van der Horst .

Change Log:

Problem:

With the advent of a proper notation for strings (recognizers) it is time to tackle the manipulation of strings. Strings deserve a prefix like D DF SF U to set these wordset apart from other words and greatly enhance reasibility. The foremost decision is how to choose the prefix. STR and $ comes to mind. In this proposal I use <string> because to discussion of how to choose the prefix distracts from the conclusion that we need such a prefix. In the following I use the $ because we are obliged to use a web interface instead of the brilliant programmer editors like emacs and gvim.

As we adapt this solution the future look bright with words as: $^ $\ $/ $= $,

Solution:

We need analogous words to ! @ +! , DF! DF@ 2! 2! . Define a stringconstant with an (address character-count) pair. In the stackdiagram indicated as sc Define a stringvariable as a-addr with sufficient space for a string to be stored. In the stacj k diagram indicated as sv.

This requires thus <string>@ <string>! <string>+! and <string>C+

The foremost decision is that these words work with a cell that determines the count. The habit of storing the count in a character, can largely be ignored. It is fortunate that the brain-damaged word to do this (COUNT, PLACE) are different from this proposal.

This wordset is used since 1984 on the Osborne and has been used internally and externally in ciforth implementation since 2000.

Typical use: (Optional)

CREATE MYBUFFER 100 ALLOT "ROME" MYBUFFER <string>! MYBUFFER <string>@ TYPE \ ROME OK BL MYBUFFER <string>+C MYBUFFER <string>@ TYPE CHAR | EMIT \ ROME | OK "ATHENE" MYBUFFER <string>+!

Proposal

Add the following paragraphs to the STRING chapter.

$! "string-store"

STACKEFFECT: sc addr ---

DESCRIPTION:

Store a string constant sc in the string variable at address addr.

 __________________________________________________________________

$+! "string-plus-store"

STACKEFFECT: sc addr ---

DESCRIPTION:

Append a string constant sc to the string variable at address addr. __________________________________________________________________

$@ "string-fetch"

STACKEFFECT: addr --- sc

DESCRIPTION:

From address addr fetch a string constant sc . __________________________________________________________________

$C+ "string-char-append"

STACKEFFECT: ch addr ---

DESCRIPTION:

Append a char ch to the string variable at address addr. __________________________________________________________________

Reference implementation:

If the proposal surviive the first ridicule I shall have the reference implementation copied from PROJECT-FORTH-WORKS See PROJECT-FORTH-WORKS

Testing: (Optional

HEX 4 , 41 C, 39 C, 45 C, 30 C, HERE 4 CELL+ - $@ TYPE | A9E0 HEX 2 , 41 C, 39 C, HERE 2 CELL+ - $@ PAD $! PAD $@ TYPE | A9 HEX 2 , 41 C, 39 C, HERE 2 CELL+ - $@ 2DUP PAD $! PAD $+! PAD $@ TYPE | A9A9 HEX 2 , 41 C, 39 C, HERE 2 CELL+ - $@ PAD $! HERE 1 - C@ PAD $C+ PAD $@ TYPE | A99

The testresults are after the vertical bar. If the proposal surviive the first ridicule I shall edit to correspond test harness in Appendix F.

ruvavatar of ruv

Some arguments against PLACE and +PLACE are applicable to this proposal too.

  1. The words {string}!, {string}+!, and {string}C+ are bad practice since they don't check the size of the result buffer. A better stack effect for such words is ( c-addr.string u.string c-addr.buf u.buf -- ), and throw an exception of overflow.

  2. there is no need to include these words in the standard if they can be provided as a portable library.

UlrichHoffmannavatar of UlrichHoffmann

Hello @albert,

we discussed your contribution in the Forth Standard's Committee interim meeting on 2024-02-16.

Thanks for you contribution. The committee appreciates your effort on simplifying string handling.

The committee kindly suggest, that you

  • elaborate on possible buffer overflow issues that can arise when using the string words you propose.
  • use terminology as close as possible to the current standard's terminology in order to allow to easier adoption.
  • create a string package with a reference implementation loadable on standard systems in order to establish common pratice for your string words.

Thanks again for your effort.

Considered
Reply New Version