Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!zephyr.ens.tek.com!tekcrl!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.forth
Subject: Re: Why is Postscript not Forth?
Message-ID: <6876@tekgvs.LABS.TEK.COM>
Date: 17 Feb 90 00:18:38 GMT
References: <9002161509.AA19458@jade.berkeley.edu>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 102

In article <9002161509.AA19458@jade.berkeley.edu> wmb@ENG.SUN.COM writes:
>> Hmmm, lets not pretend the string issue exists in a vacuum.
>> There are those of use weened on 'C' that would claim NULL terminated
>> strings are best.  I'd rather avoid religious rhetoric and stick to
>> verifiable/demonstrable claims about real situations.
>
>This isn't rhetoric.  "Adr len" strings are objectively best, in that
>a) Any character can appear in a string (null-terminated and tagged
>   strings are weak in this respect).
>b) Many types of string manipulation can be performed on "adr len" strings
>   without copying, without allocation of extra memory, and without
>   concerns about "read-only" storage.  (counted strings are weak in
>   these respects).
>c) An "adr len" string can be arbitrarily long.
>d) Any region of memory can be described as an "adr len" string without
>   requiring preallocation of space for either a count byte or a delimiter
>   byte.
>The one weakness of "adr len" strings is an issue of convenience.  There
>are 2 things on the stack instead of 1.
>
>I believe that the above claims are both verifiable and demonstrable.

Well, I certainly agree. I wrote a string package in 1981 or 2 for Forth
that used only "adr len". I called these "string descriptors." There 
were constant string descriptors and variable string descriptors (these
left *three* values on the stack-- address, physical length, and logical
length). The string package was very fast, easy to use, and protected
against string overflows. The only string packages I've seen that have
worked better, IMHO, are those associated with languages that do dynamic
memory allocation and garbage collection of strings (examples: Microsoft
BASIC, Lisp, SNOBOL, TRAC).

The really interesting aspect about the string package was that it was
based on the string instructions which I built into a processor I designed
in 1975. The processor was 32 bit words, "0-operand" (i.e. "stack machine"),
had string, queue, and IEEE floating point instructions as well as hardware 
process support (task swap was a machine instruction -- very uncommon for the 
time it saved the entire process state).

Naturally the processor would have made a good Forth Engine (I didn't even
know about Forth at the time).

An example instruction, Move Characters and Update, was used to concatenate
strings (Direct quote from manual):

	FORMAT: 0 1 1 0 1 0 0 1			1 byte instruction

	OPERANDS ON STACK:  (Top) 1. NB
				  2. B
				  3. NA
				  4. A

	RESULTS ON STACK:   (Top) 1. NR
				  2. R

	FUNCTIONAL DESCRIPTION:
NA and NB are non-negative integers. A and B are addresses of byte arrays.

L <- MIN(NA,NB);
IF A<B
	THEN FOR I=0 TO L-1 DO A(I) <- B(I);
	ELSE IF A>B
		THEN FOR I=L-1 TO 0 BY -1 DO A(I) <- B(I);
NR <- NA - L;
R <- A + L;

Where the destination is the address and physical length of a string
variable, and the source(s) is/are addresses and logical lengths of string
variables (or addr len of string constants), repeated application of this
instruction will concatenate strings into the destination variable. 
The final operation consists of subtracting the resulting length (NR) from
the physical length, giving the new logical length.

Specifying substrings, for either source or destination, was also trivial.
An instruction, Index, would increment the start address and decrement the
length simutaneously (also making sure the length didn't drop below zero.
This instruction was used to specify the starting position of a substring.
A simple Minimum function was used to specify the length of a substring.

Other instructions:
String Equal, Greater, etc	All 6 comparisons
Move Characters 	Doesn't "update"
Super Scan		Scans for first character of one string in another.
			First string specifies characters as ranges.
Translate and Update	Like move chars and update but goes through translate
			table.
Position		Finds position of one string in another.
Scan While		Scans for first character in second string that is not
			in first string.
Scan Until		Scans for first character in second string that is in
			first string.
Fill			Appends N copies of one string into another
Super Position		Like position, but will return a partial match if the
			first N characters of the first string match the last
			N characters of the second string.
Translated Position	Like position, but a translate table is used as well

Yep, some of these are obscure, but they had their uses.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply