
A segment of memory that is prefixed by a pointer to the address
immediately after the segment is a $egment. H3sm's "string operators" work
on $egments. The data in the segment of a $egment may be completely
arbitrary bytes, and may be any length the system can store in local
memory at one time, or more.

At a horizontal scale of 2 character display cells per byte, and with a
system cell size of 4, a $egment might be represented like so...

	A $egment

			higher addresses --->
                _________________________________________________  
               /                                                 \  
	______/_________________________________________________  V
	|        |       |       |       |      |      |     |  |
	|   $    |           arbitrary data segment             |
	|________|______________________________________________|

         /\       /\                                             /\	
          |        |                                              |
           \        \                                            /
            &$      s0  net segment address      contents of $ ($)   


Cell alignment marks are shown within the segment just to show that this
particular $egment and it's segment are not cell-aligned. The contents of
the segment may be arbitrary bytes.

For the system context to know that it has $, it must also know that it
has &$. That is, in order to have the contents of the $ prefix, you have
to have it's address. Those two values are sufficient information to
derive the size of the segment and it's starting address.

$ is in effect a count cell expressed as a pointer. Using a system cell is
not portable, but is more broad-band than a count byte, of course, and
seems like the natural size of a count value once a byte is deemed
inadequate. Using a pointer means that $ must be re-computed if a $egment
is to be replicated exactly at another memory location, but that is to be
avoided anyway. Items from mass storage to be converted to $egments will
have some interpretation information saying so, such that $ can be
generated as needed.

A pointer is chosen rather than a count to keep things on the H3sm pointer
stack.  The computations involved in deriving the size of the segment are
a bit too much to provide a H3sm primitive for, perhaps, and are perhaps
not as obvious as would be desired, but are better than having to traverse
the segment as in C's 0-terminated strings, and it is assumed that using
$egments involves some lengthy computation on thier contents, such that
the overhead of a few primitives to derive the size is not onerous.

Like 0-terminated and count-byte strings, a $egment can be handled from
just it's address. $egments may be implemented as named address words, or
as literals, i.e. $literals. In order for a H3sm word to contain a
$literal, the inner interpreter must be able to skip over it, while at the
same time obtaining it's address. `sub', the H3sm word to enter a
sub-thread, H3sm's GOSUB, can be used in this context. `sub' can be
combined with r->p to use sub's low-level storage of an address to place
&$ on the pointer stack, while having the effect of converting the sub
`call' to an in-line branch that skips over the $segment, and a 0-filled
pad following the segment if one is required.


        A $literal

     ____________________________________________________________________  
        |        |        |        |       |      |  |0 0 |        |
        |  sub   | &r->p  |    $   |     segment     |    |  r->p  |
     ___|________|________|________|_________________|PAD_|________|____

		to higher addresses  --->


Consider the inner interpreter (or a H3sm machine) traversing the above
portion of a H3sm thread. &r->p contains the address of the r->p cell
after the $egment and the pad. When sub is encountered, the address of $,
the address of the $egment, is placed on the return stack. This is usually
the return address of a subroutine, but not in this case. `sub' then
branches to the address of the r->p cell, past the $egment. We have
skipped the arbitrary data, but there is some cleanup to do, which r->p
performs immediately. The top value on the return stack is &$, which is
moved to the pointer stack. r->p does a drop of the return stack, so the
word containing this code/data is once again properly poised to return to
it's caller. sub has thereby also been converted to a plain branch, since
there is now no return value on the return stack corresponding to the sub.
We have skipped arbitrary data in a thread, and obtained the basic access
info to the data, in two H3sm primitives. We have a bit more work to do
though to use the $egment for anything..

If the word in question had other info on the data stack besides it's
return value, that isn't effected because the $literal construct is
effectively atomic. It does appear to open the possibility of race
conditions in a systems context, however. Perhaps a $ub fundamental
similar to H3sm `sub' is in order.

At the cell following r->p our state is that &$ is on the pointer stack.  
Let's say all we want is s0. That is provided simply by p+c , but simply
doing p+c loses the size information. Other manipulations with pdup, gap
and so on allow various approaches depending on what is needed and what is
already known.

$egments concatenate into singly up-address-linked lists. $literals don't,
but the same $literal wrapper could contain an entire li$t. This may
ameliorate the meta-data cost for an individual $literal, although I feel
it's reasonable for objects of almost arbitrary size.

Probably more interesting than li$ts is the idea that anything that has
the same net action as a $literal can use ops that work with $literals,
but may also have other behaviors. A structure with "negative offsets"
from &$ is contemplated, called a "nown". The negative offsets would
contain other ordered metadata, such as indexes, meta-pointers ala Lisp
"cons cells", and so on. A $literal contains code, but only to the extent
that it produces data, somewhat analagously to an interpreted number in
Forth/H3sm, which has an "action", but which action really is just "be".
Nowns will probably be similar, such that thier actions will be limited to
the actions involved in being data. That is, they won't be "objects" in
the "object-oriented programming" sense.

The other construct contemplated for $ was byte-ply "bignums". A bignum is
a continued number. In the simple case I considered, a byte contains 7
content bits and a continue bit. If the continue bit is set, the next byte
is the next most significant 7 bits of the bignum, and it's continue bit
is then checked. I feel that an object of system cell size is adequate.
Bignums would be portable, but I don't see that as much of an issue, and I
don't care if $egments have to be expressed in source form for porting.
Source is good.

