Skip to content
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

[lang-model]: Polymorphic Expr::Zero (or Expr::PolyConst(u8)) (trivial, common, ergo) #231

Open
Tracked by #186
archaephyrryx opened this issue Dec 12, 2024 · 0 comments

Comments

@archaephyrryx
Copy link
Contributor

Currently, any Expr that we wish to represent a value of 0 has to be specified with a fixed machine-integer type, a choice which may rely on non-local analysis of what sequences of operations are performed using the 0-value elsewhere in the Format or Expr we are constructing, and where there is almost always only one sound choice of primitive Expr::U*, with all other potential choices resulting in failure during type-inference (in the general case). While there are some exceptions to this, e.g. add(Expr::U8(0), Expr::SeqLength(...)) will yield a root ascription of U8, even in these cases the choice of which machine-rep to use for our zero-value may have cascading implications for the rest of the tree.

Given that 0 is a representable value for all machine integer types (including as-yet unimplemented signed-int types), and a good number of constant-values we might use have a slight bias towards wanting to be zero compared to most other definite values (e.g. expr_eq(SeqLength(seq), Expr::U*(0)) for checking if a sequence is empty, NULL checks for Offset16/Offset32 values in OpenType, using a base address of 0 for writing absolute WithRelativeOffset offsetting under the refactored implementation in #226), it is both quite simple to implement a distinguished primitive Expr::Zero, and would offer a minor but noticeable QoL improvement to writing zero-valued expressions in a usage-agnostic fashion.

As an alternative, the idea behind Expr::Zero can be extrapolated to a more broadly-applicable Expr::PolyConst(u8) that accepts an integer value that can be represented in every currently-supported integer type in our model (and though would clash with signed-int types as propsosed in #213, would cease to be necessary in the event #228 is adopted). Such a primitive would have the same general properties of Expr::Zero at the type-level, but would be able to represent any value small enough to fit into a u8 in a context that might require it to receive non-U8 type-ascription for the Format to be well-typed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant