Currently, calibration expansion happens somewhat opaquely: a Vec<Instruction> goes in, and another Vec<Instruction> comes out. In complex programs, it can be hard for a user to discern which post-calibration instructions originated from which pre-calibration instructions.
This can be fixed with a source map. Perhaps it can be structured like this:
struct SourceMap<SourceIndex, TargetIndex> {
entries: Vec<SourceMapEntry<SourceIndex, TargetIndex>>
}
struct SourceMapEntry<Label, SourceIndex, TargetIndex> {
/// A description of the mapping, such the calibration used to perform the expansion
label: Label,
source_location: Vec<SourceIndex>,
target_location: Vec<TargetIndex>,
}
these are generic over *Index in order to be re-used for other mappings, such as in parsing a program (mapping nom::locate information such as line and column span). Label, likewise, would be a different type in these situations:
For calibration expansion, may be the calibration used to perform the expansion. Users like @bramathon have often wondered about which DEFCAL was actually being used, and this could help make that explicit. We'd have to figure out how this works for nested expansions.
For parsing, might just be (), I don't see a need for a label
This type would be made available for other libraries to use as well, such as compilers which consume Quil.
Finally, SourceMaps should be able to be folded, such that a program can undergo multiple transformations in series and emit a single mapping from the original text down to the final artifact.
Currently, calibration expansion happens somewhat opaquely: a
Vec<Instruction>
goes in, and anotherVec<Instruction>
comes out. In complex programs, it can be hard for a user to discern which post-calibration instructions originated from which pre-calibration instructions.This can be fixed with a source map. Perhaps it can be structured like this:
these are generic over
*Index
in order to be re-used for other mappings, such as in parsing a program (mappingnom::locate
information such as line and column span).Label
, likewise, would be a different type in these situations:()
, I don't see a need for a labelThis type would be made available for other libraries to use as well, such as compilers which consume Quil.
Finally,
SourceMap
s should be able to be folded, such that a program can undergo multiple transformations in series and emit a single mapping from the original text down to the final artifact.