yeslogic/fathom

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:

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:

#[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
pub enum IntFormat {
Bin,
Oct,
Dec,
Hex,
}

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?

wezm commented

Are consts and other terms associated with a codespan for error reporting purposes?

Term carries a range that's used when producing diagnostics:

pub enum Term<'arena, Range> {

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.