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

feat(builtin): add dump() for easy print-based debugging #1269

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

rami3l
Copy link
Contributor

@rami3l rami3l commented Nov 29, 2024

dbg!() is a very popular Rust std macro that can be used like so:

let a = 2;
let b = dbg!(a * 2) + 1;
//      ^-- prints: [src/main.rs:2:9] a * 2 = 4
assert_eq!(b, 5);

... note that a * 2 is not only printed for debugging but also passed on to the rest of the calculation, which makes it a perfect fit for inspecting complex evaluations such as those of chained method calls.

The idea of this PR is to mimic the behavior of that macro with what is currently available with MoonBit's compiler magic, i.e. loc~ : SourceLoc = _ and "%any.to_string".

The signature of this function dump() is as follows:

pub fn dump[T](t : T, name? : String, loc~ : SourceLoc = _) -> T 

... where the identifiers dump and name are taken from a similar Swift function.

@@ -26,6 +29,18 @@ pub fn print[T : Show](input : T) -> Unit {
println(input)
}

///|
/// Prints and returns the value of a given expression for quick and dirty debugging.
/// @alert deprecated "This function is for debugging only and should not be used in production"
Copy link
Contributor Author

@rami3l rami3l Nov 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is marked as deprecated because it seems to be the only way to generate warnings with it. In Rust this logic is handled by clippy instead of rustc so there haven't been such concerns.

@coveralls
Copy link
Collaborator

coveralls commented Dec 2, 2024

Pull Request Test Coverage Report for Build 4053

Details

  • 0 of 3 (0.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.04%) to 80.386%

Changes Missing Coverage Covered Lines Changed/Added Lines %
builtin/console.mbt 0 3 0.0%
Totals Coverage Status
Change from base Build 4047: -0.04%
Covered Lines: 4377
Relevant Lines: 5445

💛 - Coveralls

println("dump(\{name}@\{loc}) = \{any_to_string(t)}")
t
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any_to_string is introduced for arbitrary code transformations where T is not sure if it satsifies Show. How is this different from dump[T:Show](...)
cc @Guest0x0 it makes sense to introduce support of ArgsRepr which is essentialy a stringified repr of args. so that we can do something like this:

pub fn dump[T:Show](t : T, name~ : ArgsRepr = _, loc~ : SourceLoc = _) -> T

Copy link
Contributor Author

@rami3l rami3l Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bobzhang One thing that distinguishes Swift's dump() from Rust's dbg!() is that the former doesn't pose any restrictions on T whereas the latter depends on T: Debug (which is exclusively used for print-oriented pretty-printing, compensating for the lack of a built-in dumper in Rust) 1.

I think the Show trait in MoonBit corresponds to the Display trait (which subsumes .to_string() in Rust) rather than Debug, so it makes more sense to add no bounds at all.

OTOH ArgsRepr will definitely be a nice addition.

Footnotes

  1. The lack of distinction between Display and Debug seems like a common reason for which print-based debugging is less popular in traditional tech stacks; both approaches here allow the mitigation of this issue.

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 this pull request may close these issues.

3 participants