Strings in Forth

There is a wrong a lot with strings in Forth, philosophically speaking. They are treated on a very ad hoc basis. However.

There is nothing wrong with counted strings. In my ai context they allow for 50 Mbyte strings, which would be terribly inefficient in C. They demand that you can have two items on the stack (addr count) which is no problem in Forth.
If a counted string is stored in memory, the count should be stored in a cell not a char. There is hardly anything wrong with the standard in this respect. The only word having explicitly to do with a count stored not in a cell (or stored at all, for that matter) is WORD. This could be made obsolescent.
I have ciforth based on these cell-count-counted-strings internally and it works out. (e.g. a name field contains a pointer to a regular counted string, a source field contains a pointer to a regular counted string, the file name of a blocks is a regular counted string etc.).

May I stress this:
Where a Forth implementation is a non-trivial application this string set must be considered tried, proven and complete on this account alone. (But I am using the base words plus $/ for over 15 years now, though the name has changed a couple of times.)

The idea of strings is that a character string (s) is in fact a counted string (cs) that has been stored. s (c-addr) is the string, cs (c-addr u) is constant string. The base words are :
$@ $! $+! $C+
Furthermore I have:
$^ $/ " CORA $,

" is a denotation. It replaces S" and works the same way in interpret and compile mode. Unlike S" it is not followed by a space. Adding these words to Forth is a simplification in the sense that I can do away with more than 9 words that are no longer needed (among them COUNT ). It also is in the sense that WORD EVALUATE INTERPRET CREATE etc. can be more clearly expressed using them.

DESCRIPTIONS.

For your convenience I have copied the glossary entries from the ciforth glossary. You can get the source too. P.S. These words do not assume dynamic storage of strings. But they not exclude it. Nor do they exclude dynamic storage with protection against string overflow.

STRING

OVERVIEW:

The wordset STRING contains words that manipulate strings of characters. In ciforth strings have been given their civil rights. So they are entitled to a denotation and have a proper fetch and store. An (address length) pair is considered a string constant. It may be trimmed, but the data referring to via address must not be changed. It can be stored in a buffer, a string variable, that contains in its first cell the count. Formerly this was in the first byte, and these are called old fashioned (or less flatteringly: brain-damaged) strings.

$! "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-comma"

STACKEFFECT: sc --- addr

DESCRIPTION:

Allocate and store a string constant sc in the dictionary and leave its 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.

$^ "string-index"

STACKEFFECT: sc ch -- addr

DESCRIPTION:

Find the first ch in the string constant sc and return its addr1 if present. Otherwise return a nil pointer (0).

$/ "string-slash"

STACKEFFECT: sc ch -- sc1 sc2

DESCRIPTION:

Find the first ch in the string constant sc and split it at that address. Return the strings after and before ch into sc1 and sc2 respectively. If the character is not present sc1 is a null string (its address is zero) and sc2 is the original string. Both sc1 and sc2 may be empty strings (i.e. their count is zero), if ch is the last or first character in sc .

Other Forth lectures Go to the home page of Albert van der Horst