Fri Dec 30 14:54:20 EST 2011

Replace argument lists by Var / VarPair / VarCar / VarCdr

Woo.. that seems like a deep change.  Major headache is structCompile
which now needs a user-specified composition instead of just using
list concatenation.

Abandoning it..  Very deep change, and probably leads to some
simplification which probably also means to change a lot of code

Hmm... maybe it could be as simple as StructRepr?  All this stuff
isn't necessary if structures are just collections of variables.

Yes that would simplify greatly..

Just for laughs, what about deleting this whole StructComp crap and
seeing where that goes?

First thing seems to be that running away from Struct (pack / unpack)
is not going to work: whole trees need to be transformed, which is the
functionality provided by Struct.hs

Second: the constraint that makes it possible to generate variabes for
the argument type of Lambda means that this needs to be encoded somewhere.

For now it seems to go surprisingly well.  I'm using this for variable

  class StructVar stx ras where
    structVar :: String -> Int -> (Int, stx, ras)

First trouble I run into is in Sys.hs : It seems a generic composition
instance is necessary if Sys.hs is supposed to be isolated from

  instance (StructVar stx r1,
            StructVar stx r2) 
           => StructVar stx (r1, r2)

To make it work with the old [Var] typed code, I plugged in a Var ->
[Var] function that flattens a variable tree.

Next problem is that mUnpack still generates variables in cases where
its argument is a virtual struct.

So I still have an Unpack instruction for a virtual struct.  Maybe
it's simplest to just do this in PrettyC, because in Code.hs it seems
the phantom type juggling is not cooperating.

*Main> t20
*** Exception: Unpack VarPair (Var {varType = Type AFloat 0, varName = "a3"}) (VarPair (Var {varType = Type AFloat 0, varName = "a4"}) (Var {varType = Type AFloat 0, varName = "a5"}))  VarPair (Var {varType = Type AFloat 0, varName = "t0"}) (VarPair (Var {varType = Type AFloat 0, varName = "t1"}) (Var {varType = Type AFloat 0, varName = "t2"}))  

What this looks like is just renaming.  If the trees match (they
should) this is probably straightforward.

  *** Exception: 
               Unpack VarPair (Var {varType = Type AFloat 0, varName = "a3"}) 
                     (VarPair (Var {varType = Type AFloat 0, varName = "a4"})
                              (Var {varType = Type AFloat 0, varName = "a5"}))  

                      VarPair (Var {varType = Type AFloat 0, varName = "t0"})
                     (VarPair (Var {varType = Type AFloat 0, varName = "t1"})
                              (Var {varType = Type AFloat 0, varName = "t2"}))  

This seems to solve it:
  -- Structure unpack.  
  st (Unpack mvars (Ref svars@(VarPair _ _)) body) = renames ++ st body where
    -- This is the result of unpacking a virtual struct, which is just
    -- a bunch of variable names.  It would be better to avoid these
    -- being generated in the first place, but for now this will do.
    renames = ren mvars svars
    ren new@(Var _ _) old@(Var _ _) = [cVarInitOne new (ex (Ref old))]
    ren (VarPair new1 new2) (VarPair old1 old2) = ren new1 old1 ++ ren new2 old2

  st (Unpack mvars (Ref svar) body) = 
    -- Real C struct.
    cStructVarInit svar (varList mvars) ++ st body

This comes out.

  struct tuple_f1_L_f1_f1_R_0 {
      float * m0;
      struct tuple_f1f1 {
          float * m0; float * m1;
      } m1;
  float fun(struct tuple_f1_L_f1_f1_R_0 a0)
      const float t0 = a0.m0[0];
      const float t1 = a0.m1.m0[0];
      const float t2 = a0.m1.m1[0];
      const float a3 = t0;
      const float a4 = t1;
      const float a5 = t2;
      const float t3 = a3 + a4;
      const float t4 = t3 + a5;
      const float t5 = t4 + 1.0;
      return t5;

It worries me that some of the names (numbers) are duplicated.  Why is
that?  Also, these are argument names..  Why is that?  EDIT: use "s"
prefix for struct members and fixed typo for state update.

Anyways, there's a problem: Lit is not support by _cons: it's expected
to be all variables.  Should this be changed in TML?  It does seem
better to do that..

Another bug:

  int fun(struct tuple_f0f0 * a0, float * a1, float * a2, int a3)
          float fun4_0;
          float fun4_1;
          int fun4_2;
              const int t8 = 0;
              const struct tuple_f0f0 t9 = a0[t8];
              const float s10 = t9.m0;
              const float s11 = t9.m1;
              const int t12 = 0;
              fun4_0 = s10;
              fun4_1 = s11;
              fun4_2 = t12;
              goto fun4;
              const float a5 = fun4_0;
              const float a6 = fun4_1;
              const int a7 = fun4_2;
              const float t8 = a1[a7];
  -->         const float s9 = t8.m0;
              const float t10 = a6 + s9;
              const float t11 = a5 + t10;
              const float t12 = { t11 };
              a2[a7] = t12;
              const _Bool t13 = a7 < a3;
              if (t13)
                  const int t14 = 1;
                  const int t15 = a7 + t14;
                  fun4_0 = t11;
                  fun4_1 = t10;
                  fun4_2 = t15;
                  goto fun4;
                  const struct tuple_f0f0 t14 = { t11, t10 };
                  const int t15 = 0;
                  a0[t15] = t14;
                  const int t16 = 0;
                  return t16;

This corersponds to:

      ip <- _get arri n
      i  <- _unpack ip

So arri should really be a 1-element float struct, meaning that the
code is actually correct, but the type is not.

Maybe this is because Var and VarAtom are not distinguished?

What about this:

  -- Variables can refer to data values or functions.  In the latter
  -- case type refers to the return value's type.  A VarList represents
  -- a structure with membes bound to individual variables.
  data Var    = Var {varType :: Type, varName :: VarName}
              | Tree VarTree

  data VarTree = VarPair VarTree
               | VarCar  VarTree  
               | VarCdr  VarTree
               | VarAtom Var
               deriving (Eq,Show)