Subject: Ackanomic Digest V1 #281
From: [email-masked] (Ackanomic Digest)
To: ackanomic-digest

Ackanomic Digest       Tuesday, October 8 1996       Volume 01 : Number 281

----------------------------------------------------------------------

Date: Mon, 7 Oct 1996 00:01:12 +0000
From: [email-masked]
Subject: Re: Acka Proposals Results 1277-1292

Wayne,

There has been a great mistake.  I voted on all of these proposals, 
yet I am shown to have abstained.  This is not correct.  Would you 
please look for my votes and adjust my score as appropriate.  I am 
being shorted a great deal of points.  When I sent the #current to 
the nomicbot, the reply to line was superuser.  I replied to it.  I 
did not, however, recieve bot results in return.  Thanks in advance.

Techno
"Don't learn the tricks of the trade, learn the trade."

------------------------------

Date: Mon, 07 Oct 1996 01:57:49 -0400
From: Malenkai <[email-masked]>
Subject: Acka: CFJ 303 (Wayne)

Robin Hood failed to respond.

Sep 07 00:57 EDT: -10 Robin Hood: Failed to respond to CFJ 303

Wayne has been chosen, and has 3 days to accept/decline.

Clerk of the Courts
- -------------------------------------------------------------------------
Call For Judgement 303
  Subject: Wrangled up in Donkey Business
Initiator: Malenkai
    Judge: this is not a name (declined to judge)
2nd Judge: Robin Hood (failed to respond)
3rd Judge: Wayne (selected Oct 4, 1996, 01:57h EDT)
Judgement:

Statement:

If, in a single round of the game of Grab-a-Donkey, both player A and
player C grab player B's donkey (A, B, and C distinct), and player B
is on the Grab-a-Donkey Active List (GAL), player B will retain their
donkey (and thus remain on the GAL).

Malenkai's Reasoning:

First of all, clause D of R 1276 will not kick in, as its "if clause" is
false in this situation.

I don't really have a strong case for TRUE here, but I do have *a* case.

R 1276, clause C:

> C. If  one player ("A") chose to Grab another player's donkey ("B"), and
> if B did not Cover eir donkey, then B will lose eir donkey and be removed
> from the GAL at the start of the following Round.

This hinges on the rendering of the word "one", and its scope.  If the word
"one" is scoped for an entire round, TRUE is indicated, otherwise FALSE
is.  In this case, 2 players attempted to grab B's donkey in a given
round, therefore, clause C never fires, thus the grabbing actions have
no effect whatsoever, because nothing else is specified in the rules to
handle this case.  Note that whether or not B covered their donkey
matters not in this reading.

Lets look at the FALSE case, and see if the judge has any comments on
this interpretation, if FALSE is returned:

If B covered their donkey, then A thru Z can grab it and nothing will
happen.  If B did not cover their donkey, then B loses it, and is removed
from the GAL next turn, the only question is, who gets the donkey?

I can see an argument for whoever grabbed it first, or whoever grabbed
it last.  I can also see an argument for *both* getting it, but that
case is weak.  My reading indicates the *last* player to grab it gets
it, in this multiple grab senerio.

This is just one of the areas that must be cleaned up in the rewrite.
There are others, I'll leave those to other players to discover (in some
cases they've been discovered), and other CFJs

------------------------------

Date: Mon, 7 Oct 1996 02:37:14 -0500 (CDT)
From: "Joseph W. DeVincentis" <devjoe>
Subject: Acka: pre-RFC: entity classes

pre-RFC: Entity Classes

I'm not sure how much merit there is in this, but at least in some instances
it looks to be worth doing.

I want to define "classes" of entities.  There are already some classes of
entities defined in the rules; in some cases it is worded as below; in other
cases it is simply said that the things exist, or different terms are used.

Ackanomic has quite a variety of entities, and quite a few different ways
these entities are defined.

I. Unique entities.  There is just one of each such entity in existence
at any given time.  The Machine that goes *ping*, Phoebe's Matchbox, the
Magic Potato, etc.  If these can ever be owned, they are usually mimsy.
Each of these is its own class.

II. Classes of distinct entities.  There may be few or many items in one
of these classes; each of them is distinct and usually named.  Players,
undead, rules, proposals, CFJs, blueprints, prosthetic foreheads, etc.

III. Classes of indistinguishable entities.  Each entity in one of these
classes is exactly like every other, although their owner/haunter and
other things external to the entity may be different.  A$, points,
rocks to wind a string around, chartreuse goose eggs, silver stripes, etc.

IV. Classes with sub-types.  In one of these classes there are distinctly
named sub-types.  There may be more than one item within each sub-type,
and those items may or may not be distinguishable.  Gadgets, PFbonds,
buildings, decks of cards, PartyChessPieces.  This is somewhat like
a class whose members are classes, but the name of tyhe main clss is
usually used to refer to the members of the the sub-types.

What this proposal would fix:

One idea behind this is to make some things easier to write.  For instance,
each Blueprint defines a type of Gadget, the type carries the same name as
the Blueprint.  A *lot* of the existing rules would be amended to describe
entities in a manner consistent with the new rule.

There was some confusion when Malenkai tried to make a Vending Machine
over how Rule 703 applies to gadgets.  It should not apply to individual
gadgets, unless some type of gadget requires that the individual gadgets
have names, but it should apply to the names of the gadget types (which,
since they are the same as the blueprint names, need to be made an
exception to rule 703).  Items in type III classes would 

------------------------------

Date: Mon, 7 Oct 96 3:45:34 EDT 
From: [email-masked] ()
Subject: Ackanomic: Proposal 1319

Proposal 1319 - Mon Oct 07 03:45:34 EDT 1996
Section-Renumbering Bee
/dev/joe  (Joseph DeVincentis)

This is a modest proposal.

Amend Rule 1022 by adding the following after item e in section 5a:

f) Correcting the labels (numbers or letters) of a set of numbered or
lettered sections when there are skipped or repeated labels, and at the
same time, changing any reference in any rules to any of the relabeled
sections so that they refer to the intended sections.

{{[ Rule 1022 itself contains such an error, dating to the original rule,
and I stupidly didn't fix it when I amended the mis-labeled section a
while back.  Now Malenkai has created another one with proposal 1283,
giving rule 594 two section iv's.  Proposals that change procedures,
such as the end-of-cycle procedure in Rule 666, often have problems
with leaving behind a set of sections that are not properly labeled;
indeed, it isn't labeled correctly now.

BTW, the spelling bee will fly again soon; in the last few weeks people
have been spelling better than normal, and we've had fewer rule changes
than normal, so there isn't a huge backlog of misspellings. ]}}

------------------------------

Date: Mon, 7 Oct 96 13:49:09 BST
From: R Shaw <[email-masked]>
Subject: Acka: Leaving 

 I have to leave ackanomic. I hope to return sometime next year.

 Robin Hood

------------------------------

Date: Mon, 07 Oct 1996 11:02:05 -0600
From: Uncle Sam <[email-masked]>
Subject: Acka:  I have returned 

I Uncle Sam have returned from vacation.  I am also running for President.

Uncle Sam
Your New President

------------------------------

Date: Mon, 7 Oct 1996 11:29:07 -0700 (PDT)
From: "Michael J. Thomas" <[email-masked]>
Subject: Re: Acka Proposals Results 1277-1292

Wayne's score report spake thusly
> 
> Here are the voting results for : 1286
>   Proposal 1286 - Sat Sep 28 13:18:43 EDT 1996
> Proposal FAILS
> 6 YES votes:  3 point each
>   fnord                                        39 -> 42           
> 
> Here are the voting results for : 1287
>   Proposal 1287 - Sat Sep 28 13:19:06 EDT 1996
> Proposal PASSES
> 9 YES votes:  
>   fnord                                       =  39               

I know that some odd scoring things happened for P1287
because it was modest, but this seems kind of odd to me.

fnord

------------------------------

Date: Mon, 7 Oct 96 14:54:35 EDT 
From: [email-masked] ()
Subject: Re: Acka Proposals Results 1277-1292

- - 
- - Wayne's score report spake thusly
- - > 
- - > Here are the voting results for : 128- 6 >   Proposal 1286 
- - Sat Sep 28 13:18:43 EDT 1996
- - > Proposal FAILS
- - > 6 YES votes:  3 point each
- - >   fnord                                        39 -> 42           
- - > 
- - > Here are the voting results for : 1287
- - >   Proposal 1287 - Sat Sep 28 13:19:06 EDT 1996
- - > Proposal PASSES
- - > 9 YES votes:  
- - >   fnord                                       =  39               
- - 
- - I know that some odd scoring things happened for P1287
- - because it was modest, but this seems kind of odd to me.
- - 
- - fnord

All the scores that I post are wrong.  I hope to get them adjusted
soon so that they will reflect the accurate scores. 

Wayne

------------------------------

Date: Mon, 7 Oct 96 14:55:01 EDT 
From: [email-masked] ()
Subject: Ackanomic: Proposal 1320

Proposal 1320 - Mon Oct 07 14:55:01 EDT 1996
Restoring Righteousness
Habeous Corpus  (Ed Graham)

{{This is a modes Proposal.

Ammend Rule 729 by deleting the last paragraph.}}

------------------------------

Date: Mon, 07 Oct 1996 14:54:18 -0400
From: Malenkai <[email-masked]>
Subject: Re: Acka: Leaving

R Shaw wrote:
> 
>  I have to leave ackanomic. I hope to return sometime next year.
> 
>  Robin Hood

If you would like to be acting NAP swinger until Brinjal returns,
email me.

Malenkai
speaker

------------------------------

Date: Mon, 7 Oct 96 14:55:20 EDT 
From: [email-masked] ()
Subject: Ackanomic: Proposal 1321

Proposal 1321 - Mon Oct 07 14:55:20 EDT 1996
Fighting Forehead Discrimination
Habeous Corpus  (Ed Graham)

{{This is a modest Proposal.

Ammend Rule 937 by deleting the last paragraph.}}

------------------------------

Date: Mon, 7 Oct 96 14:55:42 EDT 
From: [email-masked] ()
Subject: Ackanomic: Proposal 1322

Proposal 1322 - Mon Oct 07 14:55:42 EDT 1996
Model Airplane Kits
Habeous Corpus  (Ed Graham)

Create a Rule titled:  Model Airplane Kit

{{All extant Model Airplanes and Model Airplane Kits are hereby
destroyed}}

The Gadget known as a Model Airplane Kit exists.  Its Blueprint is as
follows:

Blueprint for a Model Airplane Kit.

A Model Airplane Kit consists of all parts,  glue,  paint and tools
necessary to build one Model Airplane.  The Player purchasing the kit
must specify which type of aircraft is contained in the kit.  Model
Airplane Kits come in Easy,  Regular  and Hard types.

Once the owner of a kit announces publicly that e is Bulding the Model
Airplane,  the following conditions will apply:

During the period the Player is constructing the Model Airplane,  e may
not vote,  partake of any Games or Contests,  be involved in any way in a
Duel,  go on Vacation,  run for elective office,  be appointed to a
permanent office,  be appointed as an Acting Officer,  or make any
Proposals.  E shall not be counted as part of a Quorum for voting
purposes.  If e already holds an office,  that office shall be treated as
if e was on vacation.  If e is already involved in a Duel,  in any
capacity,  e may not begin construction of a Model Airplane.  E may be
chosen for any action normally chosen by random sampling [e.g.  judging
CFJs and CFCJs,  finding Phoebe,  etc.].  E may file Appeals,  be
chosen as Mentor,  call for and partake in Witchhunts,  or any other
legal game action not proscribed by this Rule.

It shall take exactly seven (7) days to build an Easy Model Airplane; 
eight (8) days to build a Regular Model Airplane;  and nine (9) days to
build a Hard  Model Airplane.

When the Model Airplane is completed,  the Player constructing it must
publicly announce its completion,  and give a description of airplane. 
Once completed,  the same Player may not build another Model Airplane for
a minimum of fourteen (14) days.

The Model Airplane can do nothing,  absolutely nothing.  Its presence may
not have any effect whatsoever on the gamestate or on gameplay.

Model Airplane Kits and Model Airplanes are Tradeable.

Model Airplane Kits are produced by a Vending Machine Add-on,  if such a
device exists,  and is owned by Habeous Corpus.  For each Model Airplane
Kit sold through a Vending Machine Add-on,  A$5 of the procedes shall be
turned over to the Treasury.  The owner of the Vending Machine Add-on for
Model Airplane Kits may determine the price they sell for.  {{Initially, 
Model Airplane Kits sell for A$15 for and Easy,  A$25 for a Regular, 
and A$50 for a Hard.}}  
{{Initially,  there exists a total of three (3)) Model Airplane Kits, 
one Easy,  One Medium and one Hard.  They belong to Habeous Corpus.}}

{{Respctfully submitted,
Habeous Corpus}}

------------------------------

Date: Mon, 7 Oct 96 14:55:58 EDT 
From: [email-masked] ()
Subject: Ackanomic: Proposal 1323

Proposal 1323 - Mon Oct 07 14:55:58 EDT 1996
Rental
Guy Fawkes  (Robert Shimmin)

Create a new rule with the following text:

Any tradeable entity except A$ may be rented.  The procedure for this 
is as follows:

A public message shall be posted naming the entity(ies) to be rented, a 
non-zero amount of A$, and a length of time (known as the rental period).  
Both Player A (representing the name of the player who currently owns the 
entity(ies) to be rented) and Player B (representing the name of the player 
who wishes to rent it/them) must agree to the terms of this message.

Upon the agreement of both Players A and B, the rental period shall begin, 
the named amount of A$ shall be transferred from Player B to Player A, and 
Player B shall be considered the owner of the named entity(ies) for all 
purposes except as follows:

	1) He may not destroy the rented entity(ies)
	2) He may not trade or transfer the rented entity(ies) except to Player 
	   A.  If such a transfer occurs before the expiration of the rental 
	   period, Player A must agree to it before it can occur, upon which 
	   the rental period is deemed expired.

Player B, not Player A, shall receive all benefits or penalties (points, 
A$, etc.) for ownership of the rented entity(ies) during the rental period.

Upon expiration of the rental period, if Player B still possesses the 
rented entity(ies), they immediately revert to Player A's possession, 
unless player A is no longer in the game, in which case Player B becomes 
in fact their owner for all purposes.

This rule takes precedence over all mutable rules concerning ownership of 
tradeable entities. 

------------------------------

Date: Mon, 7 Oct 1996 15:02:55 -0500 (CDT)
From: Mohammed <[email-masked]>
Subject: Re: Acka: pre-RFC: entity classes

Sorry to send this publicly.  Please nuke this unless you're personally 
interested.

> II. Classes of distinct entities.  There may be few or many items in one
> of these classes; each of them is distinct and usually named.  Players,
> undead, rules, proposals, CFJs, blueprints, prosthetic foreheads, etc.
	I see Gadgets to be of this type, too, because each Gadget may 
have its own state information, distinct from that of others.  For 
example, if I owned eight Really Big Blue Things That Don't Do Too Much, 
Really and had used only one of them recently, you, in buying one from 
me, might want to specify that you wanted one of the ones that didn't 
have an outstanding 2-week time delay.

> IV. Classes with sub-types.  In one of these classes there are distinctly
> named sub-types.  There may be more than one item within each sub-type,
> and those items may or may not be distinguishable.  Gadgets, PFbonds,
> buildings, decks of cards, PartyChessPieces.  This is somewhat like
> a class whose members are classes, but the name of tyhe main clss is
> usually used to refer to the members of the the sub-types.
	This needs work.
	A Whamiol is a Gadget.  Not Whamiols are a Gadget.  That is, the 
entity class "Whamiols" is not a Gadget.  Gadget is simply a broader class.
	In programming you see classes of entities.  The way subclasses 
are handled is by derivation and inheritance.  One would say that the 
class Whamiol -is derived from- the class Gadget, and that Whamiols 
- -inherit- all the "stuff" associated with Gadgets.
	Thinking of it this way, subclasses aren't so weird after all.  
You could say that every class except Entity is a subclass.

class Entity.
class Gadget is derived from Entity.
class Whamiol is derived from Gadget.
class "Vending Machine" is derived from Gadget.
class "mechanical Gadget" is derived from Gadget.

	Further, you could say that some classes are abstract, meaning 
you can't have any entities that are examples of that class itself 
without being examples of some subclass underneath.  Specifically, 
there's no such thing as just an "entity"; they're all entities of 
certain types.  Likewise, there's no such thing as a "mechanical Gadget" 
that isn't a Pyraic Frobnotzer, or a Captain Cosmic Decoder Ring.

abstract class Entity.
abstract class Gadget is derived from Entity.
concrete class Whamiol is derived from Gadget.
concrete class "Vending Machine" is derived from Gadget.
abstract class "mechanical Gadget" is derived from Gadget.

	The class Whamiol is a concrete class, because you can make 
Whamiols.  There's no such thing as a free-floating Gadget, though.  Each 
Gadget has a specific type.

	I don't know where this is going or if it's any use to you, but 
this is the way I'm used to thinking about subclasses and I think that 
it's more fleshy than your model :o) ... no offense.

	I don't know if Ack is ready for this idea yet.

> There was some confusion when Malenkai tried to make a Vending Machine
> over how Rule 703 applies to gadgets.  It should not apply to individual
> gadgets, unless some type of gadget requires that the individual gadgets
> have names, but it should apply to the names of the gadget types (which,
> since they are the same as the blueprint names, need to be made an
> exception to rule 703).  Items in type III classes would 
	*leaning forward*  would what?!

- --Mohammed

------------------------------

Date: Mon, 7 Oct 1996 23:22:35 +0200 (EET)
From: Uri Bruck <[email-masked]>
Subject: acka: Official - Magic Potato

The bearer of the Magic Potato is...

... Uncle Sam.

May he bear it with honor.

Niccolo Flychuck

Registrar

------------------------------

End of Ackanomic Digest V1 #281
*******************************