What I learned from trying to implement Lorito, especially things that were underspecified, in as unorganized mess as 
possible.

I learned a few things.  First, a simple VM is pretty easy.  Really, it's a SMOP task.  And fun.  I had just enough 
guidance, especially from allison's 20 opcode email, to make something that resembled usable.  

Second, there might have be some assumptions in place that I may not have realized.  Parrot is a large beast that has quite 
a bit of history.  Most of which, I haven't had the introduction to that others might have.  To me, Parrot is a CISC VM 
that has it's hundreds of instructions defined by PASM/PIR with 4 registers, the last, PMCs, are rather magical and 
apparently, C.

One of the premises that I took with me in implementing Lorito so far is "Make something that C could work with".  And I 
tried to do that.  I chose to make PMCs less magic and more blocks of memory.  You can set and manipulate these blocks of 
memory to do anything you need them to, include safe references to other PMCs and store symbols.  But now, I wonder, if the 
assumption was that PMCs would be more akin to structs, having a strict definition in its structure that Lorito could parse 
and understand.  I wonder if with that would be the loss of flexibility.

Another thing I'm sure was never decided on was calling.  There was a lot of talk and ideas about only having goto's.  
While I can appreciate that, that would also imply that all the code was a flat address space of all the loaded code.  That 
seems like it would not always be desirable, like once you start thinking about having "eval" involved.  So I took the 
approach that code is broken up into logical blocks.  Goto's allow you to move to any legal location inside the current 
block, and call's are used to move between blocks.

The last point I had for the night is method lookup.  I have seen a push to combine PMC vmethods and object methods into a 
unified method lookup system.  I think this is a great idea, but it has never been well defined how it would operate.  The 
solution I had was a variation on P&W.  It is that each PMC has a pointer to a callable lookup PMC and a vtable PMC.  The 
lookup PMC would be responsible for looking up and returning any method call anyone needs.  Where as P&W defined how to 
handle chaining and simple inheritance, I've left that completely up to the PMC/object writer.  Two things have come to my 
mind as well while working on this.  There is still a need to have a simple set of vmethods to do basic operations, like 
resize a PMC or freeze, or maybe gather RTTI.  Methods that all PMCs must have, and would be static across all PMCs.  I 
haven't fully considered if that is another op, or another kind of lookup.  Second, I'm not entirely convinced that I need 
the vtable pointer.