Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand calibrations with source mapping #366

Closed
kalzoo opened this issue Apr 22, 2024 · 0 comments · Fixed by #370
Closed

Expand calibrations with source mapping #366

kalzoo opened this issue Apr 22, 2024 · 0 comments · Fixed by #370

Comments

@kalzoo
Copy link
Contributor

kalzoo commented Apr 22, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant