{8}  -*- text -*- 
[0: 

Tue Mar 18 09:09:50 2014 OK, I've been letting myself indulge in a
little language design whack-off here.  Justification is that MFM
representation is all about expressibility for intentional
engineering, so, um, expressibility matters.[2: With the special
challenge here being that, lacking determinism-in-the-large, we have
to specify mechanisms for all of booting, restoring, and fscking,
rather than just the traditional fire and forget. :2]

We've been trying to divide the element/computation up into a small
number of categories, attempting to satisfy several goals:

(G1) Readable and familiar: It should where possible inherit familiar
     program and programming language representations, to make sense
     to programmers once some (possibly unintuitive) basic mappings
     are established.

(G2) Retargetable and optimizable: It should be declarative where
     reasonably possible, to retain freedom during compilation to
     hardware, as well as taking a firm ontological and
     epistemological stance.

(G3) Expressive and compositional: There should be some reasonably
     familiar method for linkage by named components (where
     'components' are presumably mostly types, in support of (G2)).

(G4) Natural and native: It should exploit the distinctive
     architectural features of the MFM, such as the very small event
     window size --- so, e.g., attaching derived information to sites,
     and indexing over sites, and making sets of sites should be
     essentially free.

[1: 

Tue Mar 18 09:35:43 2014 Our driving example has been trying to
specify a Ball element, a element that spontaneously forms clumps of
some rough size.  We've been playing with almost COBOL-esque program
divisions for a bit, trying to see how many different kinds of stuff
we think should go into the specification of an element.

Overall we're going for a See-Think-Do kind of flow, and we're trying
to pull those three phases apart and regularize them, so we can
provide hooks into them for composing behaviors out of other
behaviors.  Or maybe it's a Wake-See-Think-Do-Sleep thing, with Wake
doing possible consistency checks and error corrections, and Sleep
doing possible checksum calculations and so forth.[3: Tue Mar 18
15:01:03 2014  Or Create-Wake-See-Think-Do-Sleep, which oddly has no
Destroy, but Create is just initial values for state and such.  :3]

Our current divisions are:

Class: Its name, type, and internal state declarations with initial
       values. 

Sets: Essentially a bunch of array and struct declarations.  We aren't
      sure if temporary variables go here.  Maybe Sets are mutable but
      temporaries (which would go elsewhere) would be immutable.

Actors: At the moment, instances of Sets, which seems pretty wrong..
      Originally Actors were meant primarily to be atoms, and they
      should probably get back to that.  Right now temporary variables
      are in there too.  Only some actors will be present or relevant
      in any given situation, but, like a dramatis personae, we list
      them all up front anyway.

Perception: The process of placing the actors in, or aligning or
      binding actors to, an event window.  Perception is to run
      automatically fairly early in event processing and is a primary
      candidate for h/w acceleration, so (ultimately) we would like it
      to be pretty declarative and schematized.  (For now it's just
      code, prototypically performing a event window scan (or a few,
      especially if we had h/w), and setting up the actors and sets in
      the process..)

Actions: The set of things that might be done intentionally by this
      element during event processing.  Actions are meant to be
      event-window-focused, and specified in terms of the placed
      Actors.  In particular, the goal is to be able to invoke actions
      without arguments, because the actions will refer to the tableau
      of state that has already been developed.  Perhaps that's really
      shortchanging what should be the subtlety of actions; we'll see.
      Yes, actions should be categorical -- e.g., 'Follow the leader'
      -- and note that such an action is already implicitly
      parametrized by who is the leader, what is their location, and
      so forth, which are bindings established during perception.  But
      perhaps there could be enough spin in how one does that action,
      that parameters inside a single action invocation might be worth
      it.

Decision: The process of connecting perception to action.  At the
          moment this is also just code, but it's meant to be like a
          decision tree or a subspace mapping.

  :1]
  :0]
[4: 

Tue Mar 18 15:36:40 2014 This is, as always, being damnably hard to
write.  Just had the idea that perhaps that's because I'm stupid to be
thinking of this in terms of just 'Ball' atoms or elements.  I should
really be thinking -- and expressing -- in terms of HIGHER-ORDER
atomic concepts like 'center of a confirmed ball', EVEN THOUGH such a
concept is not a property of any single atom or element type, and
therefore is not known immediately upon WAKE of any given atom.

So we should be writing one set of rules for ConfirmedBallCenter, and
another set of rules for ConfirmedBallMember, and maybe another set of
rules for just Ball ('NaiveBall' or 'UnalignedBall').  Then we write a
set of rules to determine which role we're in..[5: 

Tue Mar 18 15:56:43 2014 How about this: We draft another few bits of
state to record which role we previously had, with a spot of
redundancy.  And then on WAKE, if those state bits contain a valid
role, we just _assume_ that's what we still are, _without_ first
rechecking all the conditions for it.  

But we remember that that's an _assumption_, and if during event
processing we hit anything that's inconsistent with that assumption,
we 'fail', which means invalidate our assumption by changing our role
to something less committed and ending the event.  

Then next event we will be an UnalignedBall or whatever, and we'll do
the work to see what's what and possibly upgrade ourselves from there.

So one way to do that would be changing type -- having
ConfirmedBallCenter actually be a different element, registered in the
periodic table.  But that seems like cluttering the namespace, whereas
nesting seems more proportionate.  Hmm, proportionate.

PUNISHMENT TO FIT THE CRIME / LEVELS OF FAILURE AND RESPONSE

 - Crimes against physics, punishment: Destruction
   = Uncorrectable error in Element type
   = Unknown Element type

 - Crimes against species, punishment: Destruction
   = Resource exhaustion during event processing
   = Inconsistency detected while unemployed

 - Role fraud, punishment: Demotion or firing
   = Inconsistency detected during role processing
   
 - Other policy infraction, punishment: Per policy
   = Per policy

 - Lawful behavior, punishment: None

[6: 

Tue Mar 18 17:20:32 2014 Interesting, maybe.  Sounds like ISO 7-layer
model overkill at first glance, but, maybe.  Role fraud and other
policy infractions could easily be combined, for example.

So, 'unemployed' means 'no role' means 'no assumption', and that's why
its punishment for inconsistency is destruction: There's no assumption
left to discharge other than the assumption that this atom is a
legitimate instance of its type.
[7: 

Tue Mar 18 17:25:04 2014 So, what's the simplest example we can think
of to demonstrate some of these levels?  Some kind of pairing thing?
Left and right of a pair?  That should be simpler than a ball or
clump.


  :7]
  :6]
  :5]

  :4]
