1) Compilation environments.  There is no distinction being made between
the local environment and the foreign one.  This will cause problems as
more and more code is compiled on the lambda side.  The three ways to deal
with this are:

  a)  Fix the compiler to maintain a distinction between the two environments.
      Exactly the right distinction to draw is a research issue; fortunately
      it's not critical to get it right, but just to solve the worst screw cases.
      Constant values, macro definitions, and special declarations are most
      common in my experience.  Flavors too, but they probably wouldn't be an
      issue, at least until things get far enough along they can be compiled on
      the K anyway.

  b)  Copy the package hierarchy.  My experience is that this is a lot of work
      and rapidly gets confusing.  It is, however effective.

  c)  Get the compiler hosted on the K machine as rapdily as possible, so the
      minimum amount of cross-compilation is needed.

I think it's obvious that C is the biggest win.  B, or A+B, are definitely needed
for trying to do software development before you have the hardware, but that doesn't
apply here.

A should still be done, for the sake of ongoing software development.
(This means after the porting is pretty well done, at the earliest) .

2)  Constants seem to not be evaluated at compile time.  Possibly this was
done to ensure they have the right value on the K side.  This should be fixed
after the compiler is moved to the K.