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

Add hints to Consts to improve the distillation of integer constants #328

Closed
brendanzab opened this issue Apr 1, 2022 · 8 comments · Fixed by #344
Closed

Add hints to Consts to improve the distillation of integer constants #328

brendanzab opened this issue Apr 1, 2022 · 8 comments · Fixed by #344

Comments

@brendanzab
Copy link
Member

brendanzab commented Apr 1, 2022

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.

@brendanzab brendanzab changed the title Add hints to Consts to improve distilled outputs Add hints to Consts to improve the distillation of integer constants Apr 1, 2022
@brendanzab
Copy link
Member Author

Adding a custom equality comparison will be handy at any rate - will need to eventually looking at fixing that TODO about float comparisons 😅

@brendanzab
Copy link
Member Author

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,
}

@mikeday
Copy link
Contributor

mikeday commented Apr 1, 2022

This would not help us dump struct fields with a specific style, would it?

@brendanzab
Copy link
Member Author

brendanzab commented Apr 1, 2022

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

@mikeday
Copy link
Contributor

mikeday commented Apr 1, 2022

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

@wezm
Copy link
Contributor

wezm commented Apr 1, 2022

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> {

@mikeday
Copy link
Contributor

mikeday commented Apr 1, 2022

The fact that a const was a particular type of literal in the original source feels related to this range I feel 🤔

@brendanzab
Copy link
Member Author

brendanzab commented Apr 1, 2022

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.

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

Successfully merging a pull request may close this issue.

3 participants