-
Notifications
You must be signed in to change notification settings - Fork 126
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
[RPC] f-string-like Cryptol quasiquotation #1307
Conversation
Fantastic work, @m-yac! I feel like my ability to review this will be hampered by my limited understanding of the underlying Python tricks, but here are some questions/comments I have after skimming through the patch:
|
Thanks @RyanGlScott! These is super helpful questions and pieces of feedback.
Each of the quoted arguments in a So, for your first question, the parentheses are added in the For your second question, the other big advantage is that >>> f'{ {"x": BV(size=8, value=1)} }' == '{"x": BV(8, 0x01)}' # not valid Cryptol syntax
True
>>> cry_f('{ {"x": BV(size=8, value=1)} }') == cry('{x = 0x01}') # valid Cryptol syntax
True
Ah, by this do you mean specifically saying to always using
Dang it, good point! Unfortunately, since I'm using reflection to make this work, I can't think of an easy way to change what characters delimit f-string arguments. Perhaps we could do a find-and-replace swapping braces and some other pair of characters before the reflection, then swap again after? But what character pair would we use to replace braces? – square brackets and parentheses have even more conflicts in cryptol syntax. Regardless, I agree that this should be mentioned as a pitfall. If we're assuming our users are already fairly familiar with Python, then they should be used to adding double-braces in the context of f-strings, but I have a feeling that's not a valid assumption. |
Got it, that clarifies things.
Correct.
If we had some kind of high-level tutorial for the Cryptol Python bindings, that would be a good place to mention it. From a quick search over the various READMEs in the repo, I'm not sure if such a tutorial exists. In any case, I'd be content with mentioning this in the docstring for
Alright, I'd be fine with simply mentioning this point in |
Ok @RyanGlScott I incorporated your suggestions into the docstring for Note that I also improved the way |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic stuff. I have a fewer minor comments about documentation, but other than that, this LGTM.
I realized I should probably not use |
This is awesome -- nice job! The nasty example I was thinking of being nice to clean up some day is the salsa20 example from saw-script, i.e. lines like these:
Am I correct in thinking these can be rewritten as follows with these changes?
|
Thanks all! Yes, @pnwamk that's exactly right. Though the SAW bindings will need to define its own versions of |
This PR adds the function
cry_f
for quasiquoting cryptol using an f-string-like syntax. The example from GaloisInc/saw-script#1188 can now be written as:This PR also adds
cry_eval_f
andConnection.eval_f
which behave the same as composingcry_eval
(orConnection.eval
) withcry_f
. Seetests/cryptol/test_quoting.py
for more examples.Under the hood,
cry_f
uses Python's f-string parser and converts all of the bracketed arguments it is given into Cryptol syntax. This enables it to handle more complex expressions, like:both of which produce
cry('{x = 0x01}')
.In making this PR I realized
cryptoltypes.py
needs a lot of cleaning up. I pulled out most of the changes I made to that file along the way and will be making a separate PR for that soon.