miser

oMiser Technical Note m110400 oMiser Objects (MOb) Directory

orcmid.github.io> miser> oMiser> m110400> 0.1.3 2026-02-27T18:09Z

oMiser provides a directory, the MOb, that is the interface between applications, such as oFrugal, and the representations of currently-accessible Ob-domain entities: primitive obs, named-symbol obs (lindies), and obs reachable by binding names.

The MOb is the means by which identifiable entities are accessed and by which new ones are established for future usage.

There are special kinds of individuals, termed synthetics that are anonymous but recorded in the MOb to preserve their unique definitions. These and any similar entities will have MOb items as needed. Their function is essentially internal to oMiser but the MOb is an useful holding-mechanism.

When an oMiser instance is first established for operation and use, an IMOb COM interface is suppled for accessing MOb items and operating with those items by their COM interfaces.

1. Buckets, Entries, and Items

Storage for the MOb is organized in a set of buckets, blocks of computer storage that each provide for a portion of the entries that can be searched through. The initial set of buckets is expanded as MOb entries increase during oMiser operation.

MOb entries are the small elements within a bucket that are examined to determine if a particular item being looked for has an entry. A typical entry will consist of the identifying text naming the entity along with a hash value derived from that identifer. The hash value determines the bucket the entry must occur in, if present, and the full identifier is to determine a match. Duplicate hash values for identifiers are resolved by identifier matching, the standard convention for hashed searches.

Each MOb entry also links to a MOb item, the oMiser ob-cells that are the subjects of the entries. Successful search results are the found entry item’s COM Interface.

This architecture of the MOb is not exposed to the application of oMiser. The application simply uses the MOb API services to supply, request, and retrieve items by the identification of their entries.

2. Services of the MOb Interface

The following different requests can be made by use of the IMOb interface:

1. Find Primitives with case-insensitive names beginning with “.”. If the primitive exists, an interface to the individual is returned. If there is no such .name primitive, the alternative lindy ?.name is used and an exception is noted.

2. Find Individuals by their lindy names. If a name has not been used yet, an individual will be created. In either case, an interface is supplied.

3. Establish an ob as the value of a “^name” (or “^^”) binding name.

4. Find the ob defined to have binding names beginning with “^”. If such a binding is established, an interface to the ob-cell of the definition is supplied. If there is no such ^name-defined ob the alternative lindy ?name is used and an exception is noted. The binding name “^^” is always defined and is initially ob .NIL.

5. Find the ob defined by the special ?name binding name. If there is (now) a definition for ^name, that definition is returned. Otherwise, the result is the same as when ^name is not defined.

6. The MOb also provides the identifying entry for any individual ob-cell. These are obtained via those ob-cells and not directly through the MOb, however.

In all of the situations were obs are supplied or returned, this is via their COM interfaces. Operations 3-5 are directly in support of the oFrugal REPL, although they are available for any application.

These are the the only externally-usable services of the MOb apart from ones proposed for import and export of MOb data, if needed. Operations with obs themselves are obtained via ob-cell interfaces and related helper operation.

3. Linear Hashing

A Linear Hashing Technique is used to record objects in the MOb and to locate them by searching on computed hash values.

With Linear Hashing the MOb directory can start with a relatively-small number of buckets – blocks of storage each set up for any items having a subset of possible hash values. When buckets start growing to be full, the buckets are quietly split into two buckets each, now each designated for half of the hash-value range of the original bucket. Roughly half of the items in the original bucket will be moved into the new one, based on the new ranges. This continues progressively as more items are introduced into the MOb.

The appeal for oMiser is the moving of items into an added bucket does not require any recomputation of hashes. In the MOb, items carry their full hash values and the determination of which ones to move is straightforward. Also, the ob-cell that the MOb item leads to does not move, only the MOb entry used for finding it, minimizing any need to reorganize deeper into the storage of ob-cells.

4. MOb Operation Considerations

The primary MOb usage, apart from definitions of binding names, is in the recording of and access to named individuals. The benefit of both cases is the permanent retention of those items whether or not there are any immediate uses of the corresponding obs. The MOb is the means of holding their availability and avoiding unnecessary recreation of items.

There are anonymous individuals that are also managed using the MOb for oMiser internal purposes. Those are unreachable by the MOb-exposed services, although they are encountered in applicative operations.

Early in the growth of the MOb, collisions will be the norm and there needs to be some clean way to handle them before splitting and also in the process of splitting. There is some (rather complicated) analysis on the topic [Underwood2026] and resources on the topic need to be gathered, especially [Farach-Colton2025].

Performance determination requires good simulations and instrumentation in oMiser prototyping to ascertain what the predictable behaviors are and what optimization strategems are generally effective.

5. Related Material

ID	Status	Started	Topic
m110400a	undated	2025-11-16	Notes & Work Items
m110400b	0.0.2 2026-02-24	2025-11-16	Linear Hashing
m110400b1	preservation	2011-04-21	LwNet Discussion
m110400b2	preservation	1980-10	Litwin1980
m110400c	0.0.2 2026-02-27	2026-02-25	MOb API

---

I invite discussion about Miser Project topics in the Discussion section. Improvements and removal of defects in this particular documentation can be reported and addressed in the Issues section. There are also relevant projects from time to time.

You are navigating the Miser Project on Github

created 2025-11-16 by orcmid

This site is open source. Improve this page.