[RFC] PIR changes coming

[Melvin Smith]

PIR next phase plans:

(Note: I'd prefer to stay away from AST discussion here, I'm aware that we
  eventually wish to pass AST directly to IMCC, but I'd like to shelve 
that for
  a different thread)

1.  .class, .field and .method directive support

   These will have to change the packfile format because we need to create the
   class layout and symbol table at assembly time. We can probably do this 
without
   designing the Class PMC yet, we'll just have to fake it with a Hash PMC.

   I'd rather have code like this:

   .class Foo
      .field f1
      .field f2
      .method Bar proto
          #body
          ...
      .endmethod
      # No body
      .nativemethod Baz noproto
   .endclass
Than this:

.sub _init
        $P0 = new Class
        $P0[":class"] = "TestClass"
        store_global "TestClass", $P0
        # field
        $P0["i"] = 0
        # field
        $P0["s"] = 0
        $I0 = addr _TestClass__SampleMethod
        $P1 = new Sub
        $P1 = $I0
        # method
        $P0["SampleMethod"] = $P1
        end
.end
#method Main
.sub _TestClass__SampleMethod
...
.end
Now you tell me which you'd rather debug. :)

Implicitly this creates all symbols  for the class and at load time the correct
PMCs will be created (Method PMCs for the methods, plain types or PMCs for
the fields) and correct method addresses setup.
This abstracts how we implement classes and objects into the IMCC
compiler so we can change it without too much breakage to the
high level languages.
2.   Abstraction of subroutine call and return mechanisms based on
   compiler directives. I haven't completely figured out how this will look,
   but the general idea is, given the correct directive to .sub or .method,
   we should be able to hide all the details of the whole .pcc_call thing.
   This is less important than (1) but I think it is warranted. Leo and I
   already discussed this and we both think it is a good idea.
   Probably rather than .sub and .pcc_sub we combine both into
   .sub and provide directives like (proto, nonproto, parrotcall, fastcall)
   where parrotcall might be the standard continuation calling convention
   and the default for any .sub declared with no convention.
I will most likely start on (1) very soon as I'm to the point with Cola
that I need it and I don't like the hash code I'm currently emitting
directly from the code generator to make classes and objects.
My goal is to abstract enough so that PIR could be retargetted with
little pain.
-Melvin