Implement Core JetHinter#334
Conversation
|
@apoelstra After this PR, we can finally do the thing. We can load external implementations for Jet, JetHL, and JetHinter using dlopen2. I'll try to set up a minimal working example with it and a few jets. |
I've created a draft PR for this branch that implements this feature. I initially wanted to use |
If we want this before |
18845f8 Improve the source of types of jets (ivanlele) Pull request description: This PR improves the source of truth for the underlying types consumed and produced by jets, following the suggestion in #334. ACKs for top commit: apoelstra: ACK 18845f8; successfully ran local tests KyrylR: ACK 18845f8; successfully ran local tests Tree-SHA512: f25da16d1e0544923ba43db7f70e50e84d0b41830081f3e1286673fa03341293433ca16c7f7cd614e91b02370a08f3c4b32af791403b3d659c7c898dffaa602a
ivanlele
force-pushed
the
feature/core-jet-hinter
branch
from
bf0a1d8 to
6fd9b88
Compare
|
@apoelstra I rebased this one after #344 was merged. |
| | Core::DivMod8 | ||
| | Core::Divide8 | ||
| | Core::Modulo8 | ||
| | Core::Divides8 => SourceJetClassification::Binary, |
There was a problem hiding this comment.
Sorry I didn't get to reviewing the PR where these names came in, but I find these names (SourceJetClassification::Uniary, Binary, Tertiary, Quad..) extremely vague and particularly ambiguous in the case of Binary.
I cannot really tell if this is correct or not without understanding the logic behind them.
After reading the logic I can see what it is, but I can't help but think that this is less helpful (and maybe more error prone) than specifying everything as SourceJetClassification::Custom() with the actual aliased type.
It may even be better to replace all of this with a generated file that creates the Custom classification
There was a problem hiding this comment.
Basically, we did this to keep information about inputs and outputs as close to C Simplicity as possible.
Unfortunately, we cannot auto-generate these because the resulting output would not be deterministic, as discussed in the comments here:
#334 (review)
As for the naming, I think the names serve their purpose quite well.
The words unary, binary, and ternary literally mean "consisting of "number"" respectively:
https://dictionary.cambridge.org/dictionary/english/ternary
"Consisting of three" does a good job of acting as a hint for the parser; it tells that the type consists of three elements, so the parser needs to split it into three parts.
I can only think of "number"-part" as a synonym, but it does not sound well with the Custom case.
3 participants
This PR introduces the CoreJetHinter implementation, demonstrating the changeability of the main executable jet set.