Adding --proof-hint flag to PyK KRun

[Robertorosmaninho]

This PR aims to add the --proof-hint krun's flag to PyK infrastructure so we can use it in semantics that currently relies on PyK for building itself and execute programs.

Fixes: https://github.com/Pi-Squared-Inc/pi2/issues/1725

[Baltoli]

Looks good to me post revision but let @tothtamas28 review before you merge!

[tothtamas28]

I've left a few comments for the current approach (i.e. (3) from the list). However, I personally think (1) is a better solution, which you can implement as follows:

def run_proof_hint(...) -> bytes:
    args = _build_arg_list(...)
    ...
    proc_res = subprocess.run(args, text=False, stdout=subprocess.PIPE, ...)
    return proc_res.stdout

This is easy to implement and test, gives you a better interface, and does not prevent us from dropping run_process later.

[Robertorosmaninho]

I've left a few comments for the current approach (i.e. (3) from the list). However, I personally think (1) is a better solution, which you can implement as follows:

def run_proof_hint(...) -> bytes:
    args = _build_arg_list(...)
    ...
    proc_res = subprocess.run(args, text=False, stdout=subprocess.PIPE, ...)
    return proc_res.stdout

This is easy to implement and test, gives you a better interface, and does not prevent us from dropping run_process later.

The problem with that approach is that we have to have almost all logic duplicated just to get a different way to output the program instead of only modifying the function that outputs the result itself. I can understand that this makes things more coupled right now for a possible future refactoring, but I'm sure that in future refactoring, we'll not need to have hundreds of code duplicated.

[tothtamas28]

The problem with that approach is that we have to have almost all logic duplicated

I don't think there's a lot to duplicate honestly, the interesting part is _build_arg_list.

just to get a different way to output the program

That's a significant difference in my opinion.

instead of only modifying the function that outputs the result itself.

It'd be awesome if we could do stdout=subprocess.PIPE by only modifying the function that outputs the result, but we can't unfortunately. Hence option 1 as a suggestion.

I can understand that this makes things more coupled right now for a possible future refactoring, but I'm sure that in future refactoring, we'll not need to have hundreds of code duplicated.

That's my point, I'd rather have some code duplication than dependency to deprecated code. I'm going to be able deal with run_process even if you introduce a call to it now, but it's just easier to make these considerations before publishing new API.

[Baltoli]

My 2c is that this is a perfectly legitimate duplication to introduce. The proof hints pipeline behaves very differently to the other ways that krun works, so it's legitimate to fully separate their python entrypoints.

Waiting for final approval from Tamas on design choices

[Robertorosmaninho]

@tothtamas28, can you please take a new look at this?

[tothtamas28]

Please add an integration test for run_proof_hint.

[Robertorosmaninho]

@tothtamas28 It Wouldn't be good to already support --proof-hint in pyk run?
Using your description is no way to access the proof hints feature outside a semantic. Isn't the idea of pyk run to work as krun? So why can't I take this opportunity to already support it?

[tothtamas28]

It Wouldn't be good to already support --proof-hint in pyk run? Isn't the idea of pyk run to work as krun? So why can't I take this opportunity to already support it?

I'd like to keep these two APIs separate because

• These are separate use cases: proof hint generation vs. regular concrete interpretation.
• They have separate users: Pi2 vs regular K users.
• One (i.e. the proof hints) is more important to maintain backwards compatibility for than the other.

[tothtamas28]

Using your description is no way to access the proof hints feature outside a semantic.

I don't see why that'd be the case: you can use the proof hints feature by calling run_proof_hint. You can also build a CLI for it if you'd like to.

[Robertorosmaninho]

Hey @tothtamas28, I believe I've addressed all your comments. Can you please take a new look at it?