Some considerations regarding:
Heterogeneous tokens algebras with history dependent free behavior.
Will have more time in January. Busy. Couple things going.
[This post is mostly part of a conversation I had. But it may be relevant and of some interest to others. Who knows. Therefore here it is posted. ALSO: Is it just me or is the width of the Steemit front end changing? Lines that used to fit as one line left to right now run over ... Will fix aesthetics later ...]
Word count: 2.000 ~ 8 PAGES | Revised: 2018.12.21
LET'S MAKE IT
I'm thinking about a system of automated services, which can appear in a single virtual world.
Tokens can be "engulfed" inside an active container, and when that happens, still get tracked as tokens, but now heterogeneous.
But have direct utility. The container performs automated web services, for example.
Like in the case of something of the Wolfram Alpha type that uses system resources.
No longer quite fungible, but still tracked on the chain, can be traded, and the utility provides a bottom floor for the value.
The token public properties become it's heterogeneous name or address. So if the encapsulation, which is permanent, of 1 X token "aGd898Fsd923S..." is [aGd898Fsd923S...], and you had 25 X, now the user has 24 X +' [aGd898Fsd923S...], with an abstract balance <24,1>.
Each service [...] has its own virtual minichain spawned, and decision making heuristics. Code of this sort distributed over the underlying chain for sufficient immutability. The lowest level chain also handles the homogeneous quantities. History determines via decision rules its its operations: how it passes messages regarding the homogeneous X tokens, which control it. The holder of the token which names [...] gets sent the messages. So if messages are transfers of 100 X for services performed by [...] then [...] can messages that to the "naming token" owner.
Different services can automatically however request "assists" from other services. Or store X messages, for later release, growing in value. They can use those stores to bid for like services of other services.
For example, [...A...] cannot do g(x), but does f(h(x)) or f(g(h(x))) according to context. [...B...] can do g(x). [...A...] automatically calls [...B...] up to a cost limit, to get g(x) done. Which depending on the messages (demand) going to [...A...] and [...B...] result in [...A...] becoming more or less valuable.
These can issue their own nontradeable sub(sub)marks, by marking messages they send each other, which no human participant can trade, fake, or send, to determine their relative rates. That is, how much of the use of B can A get on demand by sending it a request message of the "can you assist" type. And they can switch parameters regarding flow from messages unlocking X tokens to get more usage. If messages sent to A transfer X for its usage and it could forward them to the account of the owner of the name token of A, who would, then, gain X homogeneous tokens, it could instead forward some to B, automatically decided how much, and if B agrees, A can use B as if it were part of A, some fraction of a time interval.
OTHER THOUGHTS REGARDING SOMETHING ELSE
Consider a system of message passing actors/agents. They mostly send outputs to mailboxes and periodically read the appropriate mailbox, and many changes can be achieved by sending a message to a mailbox that simply tells an actor to read periodically some other mailbox too or instead.
For example, the way we combine objects is very often an interesting variation on an exact sequence. Given eventually all the inputs for which it is defined, the outputs of any one object passed as inputs to another object eventually results in all its possible nil outputs.
(Each object works by elimination, spawning some instances and passing them labeled nils if they time out or them passing it labeled nils. But they are just scratch instances or copies of it --- abstractly the same object. But its output, including nil, is valid input to any yet further object. And leads to a sequence of nil outputs, or to a deterministic sequence of outputs every other one which is nil. Whatever the input to the beginning of the chain, not determined, for a long enough chain, the outputs sequence beyond some point is predictable, determined, and often nil nil nil ...) Which means we can consider many actions which are chains of objects statistically, as functions automatically defined on the intersections of other functions which happen to occur in development or use.
And something else further.
Suppose you do have a system like that --- a system that operates by elimination from a list.
Essentially each actor has a set of inputs. It also has a semiset of operations it can call. Some we call heuristics, other we call methods. They are often common to all actors. But actors may have changes in the instance and encapsulate this along with what their semiset consists of. If no input, the actor does nothing; but an input disturbs the actor.
If <=|| means "if":
And let (i) sets be objects of type A,, B where A and B may be objects of the same type, and (ii) semisets be objects of type A, B where A and B may be objects of the same type or else sets, and (iii) both be such that the leftmost object is taken first.
(A,, B) is a set.
(X, A,, B,, C, N,, M, V,, W) is a semiset. Order matters outside sets inside which order does not matter.
So each actor randomly or not selects an input. Where there is a set, order may be random; it does not matter.
A heuristic eliminates some or none of the methods in the set of methods after processing the input. In other words, heuristics are methods that are tried earlier and which are higher in the sense that they map, besides other things, sets of methods to sets of methods.
Most broadly heuristics generate plans in the [Miller, Galanter, Pribram] sense of semisets of methods to test on the input given a set of methods and some methods in these semisets are themselves possibly heuristics.
Some methods may pass messages they cannot process to other mailboxes, labeling them or not in the process, and some labels which are merely counted are marks, and messages that collect too many marks or too few marks by the end of a count can be removed, and the statistics of their other labels considered to detect where the problem originated, for example. In other words, messages are themselves actors, equipped with some storage. Labels are examples of inputs which messages can store.
The slash notation (A |-M/m-B) = (A |-M- m, m|-M-B*) means actor A sends message M to actor B and it passes to B via B reading the mailbox actor m with some frequency. We may often abstract away the mailboxes where discussing them is not relevant:
Sufficiently large systems of this kind are ultimately intelligent ones. --- They allow compensations.
For example, in the context of chain c, passing message M from actor A to actor B, more often than not, does not result in the same message being sent out from B as the message sent out from A when passing M from B to A:
But labeling the message M, such that (B |-M-A) |-> (B |-M(B,A)-A), for example, can provide control such that some and not other methods in A operate on the content of the message or they send it somewhere else to be processed first depending on the labels and the result of that is then processed by A:
We can then discuss how the system, considering the artificial intelligence factor as part of the parsing or processing of a language for us and users, has commutative union and product types and types are thus a ring and most maps between maps to all orders are defined and beyond some order all reversible. Which ties into a large and recent literature. Then point out such flexibility gives more best responses to developers and users without much further development effort, for example making social media applications developed on such a system less likely to get stuck being used in undesirable and unintended ways. Even during very short periods of time.
I'm a scientist who writes science fiction under various names.
◕ ‿‿ ◕ つ
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License . . . . . . . . . . . . . . . Text and images: ©tibra.