Closed rulonsw closed 7 years ago
After some consideration (and in spite of my previous point in regards to convention), I've decided the most reasonable and least painful thing to do in this case would be to use the CPSL-side reference as my Metacoder
's LValue
map's primary key. Storage will still be done via the String/DataLabels assigned to each variable.
The only time the compiler searches for an LValue to reference, it does so by looking up the CPSL variable name. However, StringLabels in specific are needed to write previously undefined strings to the console with the CPSL Write
command. DataLabels are added to the const section more as a style choice rather than out of pure necessity.
Added CPSL-side variable names for expressions as part of the class structure - this is effectively fixed for both LValues and Expressions now, with no need to implement bimaps or multi-index storage systems.
Const Data Storage Methods Need Refactoring
IDs found in CPSL source code are not being stored in
MetaCoder
's state. For type lookup to behave as expected, this needs to be implemented.Proto-plan for implementation
LValue
objects to include references to CPSL source variable name (While retaining StringLabels/DataLabels as primary keys within unordered maps)RSWCOMP::LoadId(std::string)
to usestd::find_if
as a search method instead ofstd::find
(using Lambda expr. that searches values instead of keys)Justification for MetaCoder primary key persistence As a matter of convention and for use in debugging compiler-side code, it makes more sense to arrange/store/reference data based on its own "domain" (e.g., how it appears within the .asm output data), rather than its CPSL source.