|Version 3 (modified by tcurtis, 4 years ago)|
As Lorito seems to be a somewhat nebulous concept about which people seem to be certain about only a few specific details (not that the specific details are the same between any two people), this is a list of questions we need to consider when designing, planning, and implementing Lorito. Feel free to add more or offer your opinion on a possible answer to any of them.
What are the main goals that Lorito should accomplish?
How much of Parrot's current core do we want to eventually rewrite in Lorito?
Will PIR compile down to Lorito assembly or will it be a superset of Lorito assembly?
How many layers below PIR will exist in Lorito?
Will Lorito have the option of compiling to C?
Will Lorito use a different bytecode format from the existing PBC?
If there is a distinct LBC (Lorito bytecode) format, will instructions be fixed-length?
Will Lorito have the same calling conventions as Parrot currently does?
If Lorito's calling conventions differ from Parrot's current ones, what will they be?
Will Parrot's calling conventions remain the same after Lorito?
Will Lorito allow direct memory access/pointer arithmetic?
Will Lorito allow manual memory allocation/deallocation?
Will Lorito have a stack?
Will Lorito distinguish between data types at the lowest level?
Will there be separate storage for different types of data at the lowest level?
Will Lorito have a object model built-in?
Will Lorito still have the same core object model as Parrot?
Will Lorito have a single op that does method dispatch at the lowest level or it will be simulated using a series of ops?
Will Lorito have some declarative syntax at the lowest level for creating classes/types?
Will there be a declarative syntax at some level below HLLs for creating classes/types?
Will PMCs and Objects be merged?
Will Strings and PMCs/Objects be merged?
What requirements will Lorito impose on the memory layout of objects?
Will objects have a static vtable in addition to method dispatch?
How should method dispatch work?
Should method dispatch be tied to classes, to objects, to some vtable/prototype object associated with each object?
Should method dispatch use strings or symbols?