-
Notifications
You must be signed in to change notification settings - Fork 483
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
[Builtins] Simplify 'Emitter' #4230
[Builtins] Simplify 'Emitter' #4230
Conversation
I was annoyed in IntersectMBO#4229 that 'makeKnown' and 'readKnown' require different monads, so I started thinking about ways to unify them and this PR implements such a way. The idea is that for all intents and purposes 'makeKnown' always receives an emitting function, for example we have flip unWithEmitterT ?cekEmitter $ makeKnown (Just term) x so we can just make it an explicit argument transforming the line above to makeKnown ?cekEmitter (Just term) x
:: ( MonadEmitter m, MonadError (ErrorWithCause err cause) m, AsEvaluationFailure err | ||
:: ( MonadError (ErrorWithCause err cause) m, AsEvaluationFailure err | ||
) | ||
=> Maybe cause -> a -> m term | ||
=> (Text -> m ()) -> Maybe cause -> a -> m term |
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.
Kinda makes me wonder if instead of requiring m
to implement MonadError
and passing around that dictionary with catchError
we could just pass another function explicitly.
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.
"passing a dictionary with catchError
" vs "passing catchError
" doesn't seem that different to me, especially since I expect that accessing it isn't a hot path.
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.
"passing
catchError
"
I mean that we don't need to pass catchError
to that function at all, we don't do any error-catching in builtins from what I can remember (we do that outside of the builtins machinery in the CEK machine).
Or we could use MonadThrow
.
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.
Probably worth benchmarking it so we can claim credit if it's faster.
:: ( MonadEmitter m, MonadError (ErrorWithCause err cause) m, AsEvaluationFailure err | ||
:: ( MonadError (ErrorWithCause err cause) m, AsEvaluationFailure err | ||
) | ||
=> Maybe cause -> a -> m term | ||
=> (Text -> m ()) -> Maybe cause -> a -> m term |
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.
"passing a dictionary with catchError
" vs "passing catchError
" doesn't seem that different to me, especially since I expect that accessing it isn't a hot path.
It's worth, but even if we get a speedup, that would be due to removing a constraint from |
Fair enough. We can always run the benchmarking job on it later if we're curious. |
Ok, I couldn't stand the fact that this was the only one that didn't get benchmarked, so I've run the benchmarks manually. For some inexplicable reason, So, not very scientific, but here are the results:
The average is |
I was annoyed in #4229 that 'makeKnown' and 'readKnown' require different monads,
so I started thinking about ways to unify them and this PR implements such a way.
The idea is that for all intents and purposes 'makeKnown' always receives an
emitting function, for example we have
so we can just make it an explicit argument transforming the line above to
Pre-submit checklist: