You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently, any
Expr
that we wish to represent a value of0
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 the0
-value elsewhere in theFormat
orExpr
we are constructing, and where there is almost always only one sound choice of primitiveExpr::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 ofU8
, 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 forOffset16
/Offset32
values in OpenType, using a base address of0
for writing absoluteWithRelativeOffset
offsetting under the refactored implementation in #226), it is both quite simple to implement a distinguished primitiveExpr::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-applicableExpr::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 ofExpr::Zero
at the type-level, but would be able to represent any value small enough to fit into au8
in a context that might require it to receive non-U8 type-ascription for the Format to be well-typed.The text was updated successfully, but these errors were encountered: