Add hints to `Const`s to improve the distillation of integer constants
brendanzab opened this issue · 8 comments
Currently the distiller has know way of knowing how to render constants, instead just defaulting to rendering as decimal numbers. We could fix this by altering Const
to be:
enum IntStyle {
Binary,
Decimal,
Hexadecimal,
Ascii,
}
pub enum Const {
U8(u8, IntStyle),
U16(u16, IntStyle),
U32(u32, IntStyle),
U64(u64, IntStyle),
S8(i8, IntStyle),
S16(i16, IntStyle),
S32(i32, IntStyle),
S64(i64, IntStyle),
// TODO: use logical equality for floating point numbers
F32(f32),
F64(f64),
Pos(u64),
Ref(u64),
}
This will allow us to convert back to an appropriate literal (either numeric or string) during distillation.
One thing we'll need to consider is to ignore the style hint when comparing constants for equality. We could do this by a custom overload PartialEq
, or, by implementing our own method (eg. Const::logical_eq
), which will involve updates to surface::elaboration::unification
and core::semantics
:
fathom/fathom/src/core/semantics.rs
Line 948 in 7641402
Another complication is how to handle the style hints in the primitive/builtin ops - we'll need to ignore or merge them somehow to figure out what to use in the returned constant.
Adding a custom equality comparison will be handy at any rate - will need to eventually looking at fixing that TODO about float comparisons 😅
Oh, I should add that I used to implement a similar thing in v2:
fathom/experiments/rust-prototype-v2/src/syntax/mod.rs
Lines 35 to 41 in 168a5f9
This would not help us dump struct fields with a specific style, would it?
OHH! You are indeed right! 🤦♂️
This only helps for preserving the style of constants in the original format through elaboration, and back via distillation to pretty printing. Rendering parsed formats in specific styles would be a separate issue.
Edit: made a new issue for this here: #329
Are consts and other terms associated with a codespan for error reporting purposes?
Are consts and other terms associated with a codespan for error reporting purposes?
Term
carries a range that's used when producing diagnostics:
Line 55 in 7641402
The fact that a const was a particular type of literal in the original source feels related to this range I feel 🤔
Are consts and other terms associated with a codespan for error reporting purposes?
In the surface language yes, but this info is currently lost once we get into the core language. We'll most likely need to add it to the core language at some stage. This could be handy for stack traces (during evaluation or reading binary formats) that relate to the original fathom code, for instance, or for errors that might occur during compilation/extraction.