Artifact For Rio's Operational Semantics #70
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KabirSamsi
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background and Context
Our meeting with Nate drove the conversation around developing a better formalization for Rio – via a type system and an operational semantics. The type system lives on now as a checker at parsing-time. The operational semantics may prove more long-lasting.
#67 (linked above as well) presents my first-draft model of the Operational Semantics for the language. My eventual intent is to be able to formally verify its equivalence with Rio-to-tree compilation (more formally, show that pushing and popping from a Rio program interpreted via these semantics will always give the same result as pushing and popping from a PIFO tree result of compilation).
Content
This PR solidifies the semantics by presenting a concrete OCaml artifact of them. Within it, I have defined modules for packets, queues and semantics, and defined popping and pushing (with respect to programs and queues) as I do in #67.
I also present a test suite which generates random tests, stores them similarly to the .data input files we used to work with with Calyx, and then tests them against their output.
Final Touches (Incoming)
Testing doesn't quite work yet! While the framework, inputs & outputs are set up, they're not quite working according to plan. I'm debugging it and I expect it to be fixed pretty soon.
I'm marking this as a draft for the time being. I just like having it here since it's a tidy link to point folks to about the current status on the semantics.