A Name for Money Objects

“Money” is a mass noun. “A money” never makes sense even though “money” is a noun. The following names have been suggested for concrete money objects: Warrant, Ingot, Bill, Sum, Purse, Wallet, Coin

is an older more elaborate money object design that makes use of a cute trick involving passing a resume key.

This is a concrete design of a money object along the lines proposed in (p3,asset).

A “sum” is an object representing a certain amount of money. The amount is an integer >= 3. Some sums are “dead”.

A sum can produce another sum such that the amounts of the two resulting sums add to the amount of the original sum. A sum can merge with another sum, deleting it, whereupon its amount will be the sum of the original amounts.

SUM(0;==>0,(7,amount);) returns the amount.

SUM(1,(7,na);==>c;NSUM) returns a new un-dead sum, NSUM, of amount na. SUM's amount is decreased by be na.

If na < 3 then c=1 and NSUM=DK(0) and SUM is unchanged. If (SUM's amount - na) < 3 {insufficient funds} then c=2 and NSUM=DK(0) and SUM is unchanged. If SUM is dead then c=5 and NSUM=DK(0) and SUM is unchanged.

SUM(2;SUMA==>c;) increases SUM's amount by SUMA's amount, and deletes SUMA. SUMA must {already} be dead.
If SUMA isn't a sum then c=3 and SUM and SUMA are unchanged. If SUMA is a sum but is not dead then c=4 and SUM and SUMA are unchanged.

SUM(3;==>0;) Kill SUM. SUM will be dead.

SUM(kt;==>X'30')

Programming Note:

To transfer money from sum X to sum Y use order code 1 on sum X to make a new transfer sum for the desired transfer amount, kill the transfer sum, (order code 3), and use order code 2 on sum Y to ingest the transfer sum.

Design Note:
There is a problem with the design of the “sum”. There is insufficient accountability for the storage required. While money is tied up in sums, there may not be enough money tied up to prevent denial of service to other money users.

There are two schemes that come to mind:

A negotiable allocation of money objects seems the obvious solution to me. The allocation could be included in the object itself and limit the object's offspring.

Build objects from holder's spacebank.

General Points
{arcane}This section {(p2,account)} replaces an older and more complex design that can now be found in (formative,account). See (p3,asset) for a simpler{?} idea.

An <account> has a <balance>, which is a non-negative {unnormalized floating point?} number {probably 64 bits} denominated in dollars {or TRU's, or grams of gold}. An account may also have a reference to an account called the <parent> of the account.

An account is <exhausted> if and only if its balance is zero or it has a parent who is exhausted.

Some keys to accounts “may be used to read the balance”.

We define (using ALGOL 68):
Mode Account = Struct(Real balance, Ref Account parent);

Proc withdraw = (Ref Account a, Real amt) Bool: #Withdraws amt from a, returns True iff successful. # (Bool success = If balance Of a < amt Then False Elif parent Of a Is Ref Account(Nil) Then True Else withdraw(parent Of a, amt) Fi; (success ^ balance Of a -:= amt); success);

Proc withdraw and truncate = (Ref Account a, Real amt) Real: # withdraw as much as possible, but no more than amt. Returns amount withdrawn. # (Real w = If Real am = min(balance Of a, amt); parent Of a Is Ref Account(Nil) Then am Else withdraw and truncate(parent Of a, am) Fi; balance Of a -:= w; w);

{Note that these two functions serve to deposit as well as withdraw.}

Calls on an account are:
acnt(t,amt;xferer==>code, actual;) “Transfer”. t is 0 or 1. If xferer is not an account then code will be 1 and actual will be undefined. (In some sense this is the definition of whether a key is an account (with respect to acnt).) Otherwise, the effect is the same as the following program:
payee = (amt < 0 ^ xferer ^ acnt), Int pmt = Abs amt,

If t = 0 Then # Transfer amount # If withdraw(payer, pmt) Then (code := 0, actual := pmt) Else (code := 2, actual := 0 ) Fi Elif t = 1 Then # Transfer up to limit # (code := 0, actual := withdraw and truncate(payer, pmt)) Fi; withdraw(payee, -actual))

acnt(4;==>0,((8,balance));) Reads the balance if acnt may be used to read the balance. Otherwise acnt(4;==>1;).

acnt(5;==>;) Returns when the balance is zero. (Can more than one wait?)

acnt(6,balance;SB==>c;k) “Create account”. A new account k is produced. SB must be an official space bank. This call will be prompt if SB is. The balance of the new account will be “balance” and the parent will be acnt if acnt is an account and there will be no parent otherwise. IF SB is sufficient Then If accnt1 is an account Then c = 0 Else c = 1 Fi Else c = 2 Fi.

acnt(12;==>;) “Destroy”.

Design and Application notes
These are some thought experiments to guide the design of accounts. They range over some perhaps fanciful ideas in order to insure a flexible design for accounts.

Suppose that an individual wanted to introduce an account system into a commercial Gnosis system with no special hooks into Gnosis or the operator of the system. We call this individual the banker.

The banker writes code that supports some of the above account functions. He makes an empty account publicly available which may be used to create other empty accounts.

The banker then publicly offers a service of converting between real dollars and accounts.

This is done by sending a check to the banker {through the US mail} with an account name. When the banker receives the check he deposits it and causes his program to create an account with the indicated balance and no parent. The banker then sends the account through the mail using the account name as the index into the interchange directory {(p2,pubdirec)}. The banker keeps no record of this event.

On other occasions the holder of an account sends the account to an entry provided by the banker with instructions to make out and mail a check. {This account holder need not previously be known to the banker.} The banker keeps no record of this event.

Program and data owners learn of accounts and equip their programs to serve when called with suitable accounts via keys in public directories. These programs accumulate the service charges in their own accounts. These accounts may be used to cause checks to be issued to the owner.
This account may be a sub-account of the requestor's main account and may be deleted following the service.

Suppose that the owner of a space bank wants to sell the services of that bank.

A design dilemma with accounts
We normally ask a requestor for a spacebank when he requests a new object. If he were to provide a guarded bank then he might destroy his money. While this is OK, perhaps it raises problems with the account code moving money between accounts. It is at least difficult for the accessing account to work properly if the accessed account's material is disappearing. Worse if the accessing account itself is zapped, it may malfunction in its death-throes.

One awkward solution is to build the account from a central bank and power it with an account supplied by the account system. Shall we say a “bank charge”?

{nonref}Programming notes on accounts:
Accounts can be used to pay for resources in two principle ways, renting and buying. See (formative,rent) about a scheme for continuous payment of rent.

In a typical buying situation, the resource server gives a key to the resource, in exchange for which it makes a one-time charge to an account, which covers the expense of storing forever the information associated with the resource. The resource server may also make a charge to an account for each transaction on the resource. {The account server is an example of such a resource server.} The resource server may provide for turning in (“destroying”) a resource and recovering its scrap value. It should provide for recycling resources even when all keys to the resource have been lost. {The account server provides this by means of the hierarchy of accounts.}

Example. Suppose a user wants to engage in a debugging session and wants to limit the amount spent to about, say, $100. If the debugging session tries to spend more than that, the user wants to be notified and, at that time, make a decision whether to spend more money on the session; but while he is making a decision, he does not want anything to be destroyed. Solution: The user creates a subaccount with a sufficiently large credit limit and deposits $100 in the subaccount's balance. The user creates an independent process (running under the parent account) which executes the call to wait until the subaccount's balance is zero. If and when the balance becomes zero, this process will notify the user. Meanwhile, the nonzero credit limit of the account insures that the account will not become exhausted (assuming the parent has enough money) and therefore no {rented} resources will be invalidated or destroyed. While the user is making his decision, the process could take any non-destructive steps to reduce the charge to the account, such as stopping processes that are running under the account, or moving data to less expensive storage media.

It is a dilemma whether to use accounts or sums. Perhaps they can be compatible???

Advantages to Purses

Simpler!

Efficient limited payment.

Perhaps accounts can be built on cash (sums) as is the real world case with real accounts and real money.