-
Notifications
You must be signed in to change notification settings - Fork 162
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
Refactor Process
and ProcessState
#1571
Conversation
d27cb3d
to
c21c8ba
Compare
I haven't looked at the code in too much detail yet, but #1100 describes another potential approach to this. Not sure about pros/cons of these approaches yet - but one thing the approach in #1100 tries to avoid is having to pass |
I'm not sure how #1100 is a solution to the borrow-checker problem. I see the same problem of needing to do e.g. // Process::op_emit
fn op_emit(&mut self, event_id) -> ... {
// doesn't work, since `&mut self` takes a mutable reference to the entire `Process` struct
// (including the inner `self.state`), such that `&self.state` is not allowed.
self.host.on_event(&self.state)?;
} The larger problem IMO stems from the circular dependency
where a I find it to be a cleaner design to have As an aside, I would also move
Given the above interpretation, I actually like to visually see which method also mutate the |
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.
Looks good! Thank you! I left a few comments inline - they are pretty minor but applicable to quite a few places.
The larger problem IMO stems from the circular dependency
Process -> Host -> AdviceProvider ^ | |______________________|
where a
A -> B
means "A requires reference to B". In the current design,Process
is a master struct that contains everything that is needed to execute the union of all instructions. Therefore,AdviceProvider
methods need a&mut self
to modify the advice provider, while also having a read-only reference toProcess
state (which doesn't work with the borrow-checker as described above).I find it to be a cleaner design to have
Process
be only the state that will be encoded into the trace, while theHost
is a separate entity that is the "outside environment" in service of trace generation (i.e. advice provider,MastForest
dependencies, event handlers, and debug/trace handling). i.e. it's a better separation of concerns, and is also borrow-checker friendly.
Agreed. I just find it a bit annoying that we have to pass &mut host
everywhere (which decreases code readability a bit). But also, don't have a better solution at this point.
As an aside, I would also move
Decoder.debug_info
into theHost
, so thatProcess
really only pertains to trace generation. It would also allow us to haveProcess::execute_decorator(&self, ...)
instead of&mut self
, clearly encoding that decorators do not modify the trace. It would also makeHost
more consistent, since it currently is responsible for handling trace events, but not debug infos (which are similar in my mind).
Makes sense. Let's do it in a separate PR though.
c21c8ba
to
90619ec
Compare
90619ec
to
2b49880
Compare
2b49880
to
b7e9d44
Compare
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.
All looks good! Thank you!
This is some cleanup as part of #1457.
This PR has 2 commits:
Host
object out ofProcess
ProcessState
, when we need a&Process
to create aProcessState
to pass it to aHost
method. The borrow-checker prevents us from doing that, since there's already a&mut Process
reference to get theHost
(i.e.process.host.borrow_mut().host_method(&process_state)
).Host
when they really didn't need to, such asprocessor::trace::finalize_trace()
.ProcessState
trait into a structProcessState
, where actually there's only ever going to be a single implementation (i.e. the VM'sProcess
). I believe the intention with the trait was to clearly indicate the parts of theProcess
that theAdviceProvider
is allowed to view - the current design achieves this in a simpler way.I checked in
miden-base
, and I believe this change won't cause problems there.