requirements for the degree of Bachelor of Nomic. This Thesis is associated with the recent Proposal "A B.N. for favor".
Introduction
Historically, many of the scams and CFJs in Agora Nomic have hinged on matters of word-meaning. Everyday language is notoriously ambiguous and dependant on assumptions about speaker and listener intent that are not logically well-founded; they require the application of what is often called "common sense" (a loose and imperfectly-shared collecion of default assumptions, word-usage rules, and so on).
The Rules and Customs of Agora Nomic have historically had an ambivalent attitude towards common sense. Judges have sometimes been allowed or required to exercise it when the Rules are not clear. Some Players have cited the imperfect consensus on matters of common sense in borderline cases, and tried to reduce or eliminate the Rules' dependence on it.
CFJs and scams based on word usage are welcomed and relished by some Players, and despised by others. Some have accused the community of making scams impossible by encouraging Judges to block them by quibbles on word meaning; others have claimed that without such quibbles, most scams would be impossible in the first place.
It would be illuminating to consider what a Nomic game might be like that was wholely lacking in disputes and disagreements about word usage and meaning, or about common sense or other broad subjective notions. Such a game would be interesting by virtue of the contrasting light it would throw on Agora and similar Nomics, as well as potentially leading to interesting games in its own right.
So
The idea is to design a completely formal Game, one in which there are no rules that have subjective components, or are otherwise open to disputes about common sense or the meanings of words. The game should also be as Nomic-like as possible, given that restriction, in that the rules of the game should be represented within, and changeable by moves of, the game.
This will not be "real" Nomic unless we are wildly more successful than I think we will be. Because we have to choose a comparatively simple formal framework (in order to keep it comprehensible), it's unlikely that we'll be able to get as "meta" as non-formal Nomic can get. It will also, of course, not have the fun of Judgement and dispute about word meanings and intent and sense and reference and all that that most Nomics offer. This is intended to be a different game, albeit somewhat inspired by the usual Nomic. But there's no claim that it's better than any other Nomic, or truer to any particular ideal, or anything like that.
There will, of course, have to be an interface between the formal system in which the rules sit and the players, who are out in the physical world. This interface will be referred to as the Mechanics of the game, and these will be subject to all sorts of disputes and things. But they are not part of the game itself; any issues that come up about the Mechanics ("I didn't make that move; someone must have forged the e-mail!") will be extra-game issues, and will not be expressed or resolved in the gamestate.
Similarly, the language in which the game is expressed will be subject to change (and in particular to expansion) as the game goes on, but this again is an extra-game process. As new verbs or conditions or whatever are added to the language, we will just have discovered new parts of the formal space that the game is exploring. The status of the language of the game is not contained in the game itself. This is another limitation that nonformal Nomic does not, at least in theory, suffer from. I suspect, however, that a strong case could be made for the claim that any nonformal Nomic played by humans will in fact be subject to the same sort of limitation, in that humans, being finite entities instantiated in a limited universe, cannot ultimately escape all bounds of language themselves.
Relationship to Agora Nomic
Formal Nomic can serve Agora Nomic as a thought-pump, if nothing else. If some actual or contemplated feature of Agora Nomic would be especially hard or easy to add to a hypothetical game of Formal Nomic, or would require diddling with the Mechanics, that says something about the nature of the feature. If two apparently-similar ways of embodying within Agora the same basic idea turn out to have very different implications for a hypothetical game of Formal Nomic, that says something about the differences between them.
Formal Nomic might also be a useful, or instructive, or amusing subgame (probably a Contest) within Agora Nomic. One Player would implement (either automatically, or by hand) the Mechanics, and choose an Initial Set; the other Players in the jurisdiction of the subgame would submit input to the Mechanics, changing the state of the subgame. Winning the subgame could mean being awarded the subgame's Treasury, or whatever.
Details / Examples
The rest of this paper consists of a worked-out example of one completely formal Nomic, including a description of the mechanics, and an Inital Set (that is, an initial object-pool). It is of course only one example; the basic objective could be accomplished in many other ways. For instance, if all the Players were willing to be computer programmers, the ruleset and gamestate could be expressed directly as computer program texts and variable values, at a considerable increase in power, and a considerable cost in difficulty of play.
For this example, the incoming interface is relatively simple: when a piece of mail comes in for the "server", it's parsed into one or more objects in the system. Each object has a Type of "move", a Sender and Timestamp filled in from the envelope, a randomly-generated BatchNumber that's the same for all the objects created by the same piece of mail, and other fields filled in from the body of the message. For instance, a request to register might look like:
From: Matt Zimola Date: 14 Aug 1995, 12:36:13 UTC Subject: to the Mech server REGISTER MattZ
and the corresponding object that gets created might be:
objectId: 127 batchId: 114 moveTimeStamp: 1995/08/14 12:36:13 moveSender: [email protected] type: move subtype: register nickname: MattZ
"REGISTER MattZ" is syntactic sugar, to make a common operation easier. In its full generality, the incoming Mechanics would allow the sender of the mail to specify any attributes and values e wants to (except type, objectId, batchId, and so on).
On the other end, there will be a small set of verbs that cause extra-game side-effects; primarily mail-sending to let the physical-world players know what's going on. But these side-effects are not defined in or modifiable by the game rules; they are the Mechanics, not the Rules. From the point of view of the game-state itself, the sendFoo() verbs will be no-ops.
A rule is just another object, with Type "rule", an "if" attribute which is some boolean function of the gamestate, and a "then" attribute which is some sequence of verbs. It also has a ruleOrder, to determine which rules get to look at the game-state first, and probably various other housekeeping numbers. (More generally, we can have a special engineSettings object which would tell the engine which type of objects are really rules; that would normally be set to "rule", but could be diddled with for various special effects.)
The sequence of events in the game is as follows. Note that this is again a thing that isn't part of, or changable by, the Rules, and this is another un-Nomic-like limitation. It may be possible to make some or all of this stuff adjustable within the game also, with some effort. (Note that that effort would have to be done outside the game, in the Mechanics, to enable laters efforts within the game.)
Something happens: either a new object arrives from the physical world via the incoming interface, or a rule suddenly fires due to a schedule pop.
For each object of Type "rule" in the gamestate, in order of ruleOrder, the value of the "if" attribute is evaluated. If the result if "false", we proceed to the next "rule" object. If the result is "true", the verbs in the "then" attribute fire, creating or deleting or modifying or scheduling objects; then we restart this "for" loop, back at the rule with the highest (lowest-numbered) PrecendenceNumber. (If a rule fires, but the "then" clause does not change the game-state, we don't restart.)
Once the highest-ruleOrder rule has had its "if" part evaluate to "false", we go to sleep again until the next thing happens.
There are all sorts of "programming" issues involved in making these things actually work. When a rule fires and changes the game-state, for instance, it will almost always have to make sure that the change it makes is such that it won't fire again for the same reasons, since its change will cause a restart, and if no rule with a lower ruleOrder fires, it will see the game-state again just the way it left it. So for instance a rule that gives a player a point because of some condition should make sure to also make the condition false, otherwise it may give the player an infinite number of points, one at a time! (Another aspect of the Mechanics will presumably be an extra-Game meta-rule like "if the game-state goes into a verifiable loop, the last player to submit a move wins".)
One way to manage this is to have a rule simply delete the object that caused it to fire; this is sensible in some cases, although it will often be better to simply mark it in some way (set the processedByRule47 attribute to T, for instance), rather than deleting it, so that other rules with higher ruleOrders will get a chance to act on it as well.
Below is a sample Initial State. It includes registration (but not deregistration or On Hold), proposals (which may contain multiple Rule Changes), voting (but not multiple votes, or changing votes), quorum, simple majority (AIs and MIs are quite doable, but are not in this Initial State), points for voting and having your proposals pass, and a simple Win on points (which ends the game). Kudos, degrees, Win Tokens, Extra Votes, the Potato, and some other familiar Agora concepts would fit into this set in reasonably simple ways.
Some other concepts are much harder; for instance, the idea of sub-rulesets that only apply to some Players, as in Group Ordinances and Contest Regulations. Platonic sub-rules are especially hard to formalize. For instance, if a Group Ordinance says that in some circumstances a Group Member shall transfer fifteen Marks to a non-Member, that's acceptable. If it says the opposite, that some non-Member shall transfer fifteen Marks to some Member, that isn't. In both cases, both a Member and non-Member appear in the subrule; formalizing the difference between the two is a subject for further study.
I haven't actually implemented any of this as a computer program, and I'm not sure that I have any interest in doing so. But I hope it will spur some interesting discussion nonetheless...
A note on scams: an amusing proof that scams are entirely possible in this formal Nomic. In the first draft of this Initial State, Rule 16 didn't set the "cleanup" attribute of incoming votes to F. So if you submitted a vote, and set "cleanup" to T in the move object, you'd get your point for voting, but the vote would be destroyed by the Sweeper, so you could do it again. And again. And again. Getting a point each time, and winning at will. Easy to fix, but illustrative! (In the very first version of Rule 16, it didn't even have the check to ensure that the proposal ID was valid, making it easy to win by voting for a hundred non-existent proposals.)
Anyway:
Basic attributes of objects:
objectId - a number, used as a handle for talking
about an object, assigned sequentially by the system
when the object is created. Match clauses always
find the matching object with the lowest objectId.
type - tells what it is; the incoming interface produces only
objects of type "move". The rule engine gets its settings
from the first objects of type "engineControls", and
runs only objects whose type is the same as the runType
attribute of engineControls. All other types have meaning only to
rules. A basic type in the initial set is "player".
Move attributes set by the incoming interface (these attributes are always assigned; any and all other attributes besides Type can be set by the incoming mail explicitly):
moveSender - [email protected] that sent the mail moveTimeStamp - yyyymmddhhmmss (a time-format string), from the date: line of the mail moveBatch - a contentless id assigned to all the "move" objects that come in in the same piece of mail (for batching up multiple Rule Changes into a single proposal, etc)
Except for these three, and type (which is always "move"), the sender of the mail can control all the attributes of the move object. Syntactic sugar of various kinds will presumably be provided for common cases.
Rule attributes used by the engine:
ruleOrder - rules are run in order of ruleOrder, lowest to highest.
if - condition tested when a rule is run.
then - verbs executed when an if is true; if this causes any
change to the existing objects (creation, deletion,
amendment), the ruleset is restarted.
Some verbs:
delete(match) - deletes the matching object (with the lowest
objectId, as usual)
create(match) - creates a matching object
set(match1)(match2) - Changes the object matching match1 so
that it matches match2.
send([email protected][....])(expression) - queues up the value
of the expression for sending to [email protected] (or list thereof).
sendObject([email protected][...])(match)(string) - queues up a
print form of the matching object, with the string for a
header, for sending.
sendNow() - actually sends all queued stuff off.
Some functions for use in expressions: exists(match) count(match) timeGE(timevalue) - Tests if the current time is >= the given time. Used for timers. A possible engine optimization: duing each pass, keep track of the lowest-value timeGE that fails; set an actual timer to re-check all rules at that time, if nothing else has happened in the meantime.
Notes: - Some sort of "for" clause in rules may be needed for performance and clarity reasons. Otherwise, the only way to do something like sending the entire ruleset to a player in response to a query move would be to do passes through the first part of the ruleset, using some kludged-up bookkeeping attribute or object to keep track of which rules we haven't sent yet. Maybe that's OK? - Perhaps allow a rule to say that the engine shouldn't restart the ruleset after processing it? That, instead, it should just test the rule itself again, and then proceed onwards? - A more radical change to this model would be to have all object-changes take place in a second, "shadow", copy of the object-pool, and switch over to that object-pool only when no rule in the current pool wants to make any changes. Could be an engineControls switch? - Probably be good to have a setall(match1)(match2), that would efficiently set all objects matching match1 to match match2.
Loose conventions about ruleOrder:
We will use ruleOrder 10000-19999 for rules that don't delete the object that sets them off (although they may set some attributes so that it doesn't set them off again). We will use ruleOrder 30000-39999 for rules that do delete, or otherwise make very significant changes (like changes of type) to the object that sets them off. We will use ruleOrder 99000-99999 for rules that should basically only run for cleanup-type reasons at the very end of an event.
Initial engine settings and (empty) player-list:
objectId: 1 type: engineSettings runType: rule objectId: 2 type: playerList listContents: ""
Rules about registration:
objectId: 3
ruleOrder: 30010
type: rule
if: exists(type=="move" & subtype=="register" & moveSender==%s &
nickname!="" & nickname==%n & moveTimeStamp==%tm & objectId==%mo) &
!exists(type=="player" & nickname==%n) &
exists(type=="playerList" & listContent==%pl)
then: create(type=="player" & defaultEmail==%s & nickname==%n &
registeredAt==%tm & score==0 & objectId==%po) &
set(objectId==%mo)(processed==T & cleanup==T) &
create(type=="newPlayer" & reference==%po & cleanup==T) &
send(%pl,"New player" %n "registered at" %tm) &
send(%s,"Welcome to Engine City," %n"!")
comment: "if someone's registering, and e gave a nickname that
isn't already in use, create a proxy object for em with
their information, note that the move was processed for
later cleanup, and create a newPlayer object for other
rules to process. Also tell everyone."
objectId: 4
ruleOrder: 30020
type: rule
if: exists(type=="move" & subtype=="register" & processed!=T &
moveSender==%s & nickname!="" & nickname==%n & objectId==%mo) &
exists(type=="player" & nickname==%n)
then: sendObject(%s)(objectId==%mo)("A player" %n "is already registered") &
delete(objectId==%mo)
comment: "handle error case where someone tries to register with a
name that's already in use."
objectId: 5
ruleOrder: 30030
type: rule
if: exists(type=="move" & subtype=="register" & moveSender==%s &
nickname=="" & objectId==%mo) &
then: sendObject(%s)(objectId==%mo)("You have to give a nickname when you
register") & delete(objectId==%mo)
comment: "handle error case where someone tries to register without
a name."
objectId: 6
ruleOrder: 30040
type: rule
if: exists(type=="move" & from=="" & moveSender==%s & objectId==%o) &
exists(type=="player" & defaultEmail==%s & nickname==%n)
then: set(objectId==%o)(from==%n)
comment: "if no from is given on a move, guess from the email address"
objectId: 7
ruleOrder: 30050
type: rule
if: exists(type=="move" & from==%f & moveSender==%s & objectId==%mo) &
!exists(type=="player" & nickname==%f)
then: sendObject(%s)(objectId==%mo)("You are no known player.") &
delete(objectId==%mo)
objectId: 8
ruleOrder: 30060
type: rule
if: exists(type=="newPlayer" & listed!=T & defaultEmail==%e &
objectId==%po) &
exists(type=="playerList" & listContent==%l & objectId==%lo)
then: set(objectId==%po)(listed==T) &
set(objectId==%lo)(listContent==%l %e)
comment: "Maintain a list of all player email addresses, for
mass sendings"
A simple Win rule:
objectId: 9
ruleOrder: 10010
type: rule
if: exists(type=="player" & score>100 & nickname==%n & objectId==%o) &
!exists(type=="win" & who==%o) &
exists(type=="playerList" & listContent==%pl)
then: create(type=="win" & who==%o) &
send(%pl,%n "wins the game!")
comment: "if a player has over 100 points, e wins"
objectId: 10
ruleOrder: 10020
type: rule
if: exists(type=="win")
then: halt()
comment: "the game ends when one or more players win"
Rules about Proposing:
objectId: 11
ruleOrder: 30120
type: rule
if: exists(type=="move" & subtype=="ruleChange" &
ruleChangeType=="repeal" & target==%t &
batchid==%b & objectId==%mo) &
exists(objectId==%to & type=="rule")
then: set(objectId==%mo)(type="changeBeingVotedOn")
comment: "snarf in an incoming repeal rule change; we'll
let ones that attempt to repeal a non-existing rule just
fall through to the general error handler at first."
objectId: 12
ruleOrder: 30130
type: rule
if: exists(type=="move" & subtype=="ruleChange" &
ruleChangeType=="amend" & target==%t &
batchid==%b & objectId==%mo) &
exists(objectId==%to & type=="rule")
then: set(objectId==%mo)(type="changeBeingVotedOn")
comment: "snarf in an incoming amendment rule change"
objectId: 13
ruleOrder: 30140
type: rule
if: exists(type=="move" & subtype=="ruleChange" &
ruleChangeType=="create" & target==%t &
batchid==%b & objectId==%mo)
then: set(objectId==%mo)(type="changeBeingVotedOn")
comment: "snarf in an incoming create rule change"
objectId: 14
ruleOrder: 30150
type: rule
if: exists(type=="changeBeingVotedOn" & sent!=T & batchId==%b &
objectId==%o) &
exists(type=="playerList" & listContent==%pl)
then: sendObject(%pl,%o,"Proposed rule-change (proposal" %b"):") &
set(objectId==%o)(sent==T)
comment: "Tell all players about new proposals"
objectId: 15
ruleOrder: 30160
type: rule
if: exists(type="changeBeingVotedOn" & batchid==%b) &
!exists(type=="voteInProgress" & propId==%b)
then: create(type=="voteInProgress" & propId==%b) &
expiryTime==timeNow()+10*24*60*60)
comment: "Creates the voting object representing a pending Proposal"
Rules about Voting:
objectId: 16
ruleOrder: 30220
type: rule
if: exists(type=="move" & subtype=="vote" & propID==%p &
from==%f & objectId==%o) &
exists(type=="player" & nickname==%f) &
exists(type="voteInProgress" & propId==%b) &
!exists(type=="vote" & propID==%p & from==%f)
then: set(objectId==%o)(type=="vote" & credited==F & cleanup==F)
comment: "One Player, one unchangable vote per proposal"
objectId: 17
ruleOrder: 30230
type: rule
if: exists(type=="vote" & from==%f & credited==F & objectId==%vo) &
exists(type=="player" & nickname==%f & score==%s & objectId==%po)
then: set(objectId==%po)(score==1+%s) &
set(objectId==%vo)(credited==T)
comment: "One Point when you vote"
The End of the Voting Period:
objectId: 18
ruleOrder: 30320
type: rule
if: exists(type=="voteInProgress" & timeGE(expiryTime) &
objectId==%o)
then: set(%o)(type="voteCompleted")
objectId: 19
ruleOrder: 30330
type: rule
if: exists(type=="voteCompleted" & propId==%p) &
exists(type=="vote" & propId==%p & from==%f & vote==%vc &
noted!=T & objectId==%vo) &
exists(type=="playerList" & listContent==%pl)
then: set(objectId==%vo)(noted==T) &
send(%pl,"Player" %f "receives one point for voting" %vc "on" %p)
comment: "Announce content of votes"
Tallying Votes:
objectId: 20
ruleOrder: 30420
type: rule
if: exists(type=="voteCompleted" & objectId==%o & propId==%p &
objectId==%o) &
count(type=="vote" & propId==%p)<(count(type=="player")/4) &
exists(type=="playerList" & listContent==%pl)
then: set(objectId==%o)(type="proposalFailed" & cleanup==T) &
send(%pl,"Proposal" %p "fails quorum.")
objectId: 21
ruleOrder: 30430
type: rule
if: exists(type=="voteCompleted" & objectId==%o & propId==%p &
objectId==%o) &
count(type=="vote" & propId==%p & vote=="FOR")>
count(type=="vote" & propId==%p & vote=="AGAINST") &
exists(type=="playerList" & listContent==%pl)
then: set(objectId==%o)(type="proposalPassed" & credited==F) &
send(%pl,"Proposal" %p "passes.")
objectId: 22
ruleOrder: 30440
type: rule
if: exists(type=="voteCompleted" & objectId==%o & propId==%p &
objectId==%o) &
count(type=="vote" & propId==%p & vote=="FOR")<=
count(type=="vote" & propId==%p & vote=="AGAINST") &
exists(type=="playerList" & listContent==%pl)
then: set(objectId==%o)(type="proposalFailed" & cleanup==T) &
send(%pl,"Proposal" %p "fails.")
objectId: 23
ruleOrder: 30450
type: rule
if: exists(type="proposalPassed" & from==%f & credited==F &
objectId==%pro) &
exists(type=="player" & nickname==%f & score==%s & objectId==%plo) &
exists(type=="playerList" & listContent==%pl)
then: set(objectId==%pro)(credited==T) &
set(objectId==%plo)(score==5+%s) &
send(%pl,%f "receives 5 points for the proposal ("5+%s")")
comment: "Five points when your proposal passes."
Implementing passed rulechanges:
objectId: 24
ruleOrder: 30520
type: rule
if: exists(type="proposalPasssed" & propId==%b) &
exists(type="changeBeingVotedOn" & batchId==%b & objectId==%o)
then: set(objectId==%o)(type=="changePassed")
objectId: 25
ruleOrder: 30530
type: rule
if: exists(type=="changePassed" & ruleChangeType=="repeal" &
target==%t & objectId==%o)
then: delete(objectId==%t) &
set(%o)(type=="changeDone" & cleanup==T)
objectId: 26
ruleOrder: 30540
type: rule
if: exists(type=="changePassed" & ruleChangeType=="amend" &
target==%t & newif==%ni & newthen==%nt & neworder==%no &
objectId==%o)
then: set(objectId==%o)(if==%ni & then==%nt & ruleOrder==&no) &
set(%o)(type=="changeDone" & cleanup==T)
objectId: 27
ruleOrder: 30550
type: rule
if: exists(type=="changePassed" & ruleChangeType=="create" &
newif==%ni & newthen==%nt & neworder==%no &
objectId==%o)
then: create(type=="rule" & if==%ni & then==%nt & ruleOrder==&no) &
set(%o)(type=="changeDone" & cleanup==T)
Cleanup Rules:
objectId: 28
ruleOrder: 99910
type: rule
if: exists(type=="proposalFailed" & propId==%p) &
exists(type=="changeBeingVotedOn" & batchId==%p & objectId==%o)
then: delete(objectId==%o)
objectId: 29
ruleOrder: 99920
type: rule
if: exists(type=="proposalFailed" & propId==%p) &
exists(type=="vote" & batchId==%p & objectId==%o)
then: delete(objecId==%o)
objectId: 30
ruleOrder: 99930
type: rule
if: exists(type=="proposalPassed" & propId==%p) &
exists(type=="vote" & batchId==%p & objectId==%o)
then: delete(objectId==%o)
objectId: 31
ruleOrder: 99940
type: rule
if: exists(type=="move" & processed!=T & objectId==%o &
moveSender==%ms)
then: sendObject(%ms)(objectId==%o)("This move didn't do anything") &
delete(objectId==%o)
comment: "If an unprocessed move is hanging around, delete it,
and send a warning to the sender."
objectId: 32
ruleOrder: 99980
type: rule
if: exists(cleanup==T & objectId==%o)
then: delete(objectId==%o)
comment: "the Final Sweeper"
objectId: 33
ruleOrder: 99990
type: rule
if: T
then: sendNow()
comment: "Send out accumulated mailings"