1) External libraries are being loaded at parse time.

Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is called at
parse-time when loadlib is encountered. This is causing libraries to be
loaded twice (once at parse-time and once at run-time), which is a
problem in its own right, but it also just seems like generally the
wrong behavior.

2) Code which tries to instantiate a dynamically-loaded PMC fails to
parse.

Code such as this:

         loadlib P1, "foo"
         new P0, .Foo

fails to parse, because ".Foo" is being interpreted as a macro. For
example:

% ./parrot dynclasses/dynfoo.pasm
error:imcc:unknown macro '.Foo'
in file 'dynclasses/dynfoo.pasm' line 7

The problem seems to be the following code, which interprets ".Blah" as
a macro if "Blah" isn't an already-registered type:

imcc/imcc.l line 337:

<emit,INITIAL>{DOT}{LETTER}{LETTERDIGIT}* {
         int type = pmc_type(interp, string_from_cstring(interp,
yytext+1, 0));

         if (type > 0) {
             char *buf = malloc(16);
             sprintf(buf, "%d", type);
             valp->s = buf;
             return INTC;
         }
         if (!expand_macro(valp, interp, yytext+1))
             fataly(1, sourcefile, line, "unknown macro '%s'", yytext);
     }

I can't find any definitive docs on the macro syntax, so I don't know
if this is pointing out a true ambiguity in the grammar (since
dynamically-loaded PMC types won't be known at parse-time, before the
library defining them is loaded), or if macro usages are always
supposed to have argument-syntax, such as ".Blah()", which would mean
that this is just a problem with the parser. There's no example in
t/op/macro.t without parentheses, so I'm thinking it's the latter.

JEff