Add inspect(…) function for debugging

[sharkdp]

Add a simple

fn inspect<T>(x: T) -> T

function that acts like the identity function, but prints the value x to the terminal. Ideally, this would come with source code location information (Span), similar to our error messages.

[irevoire]

Isn’t trace typically used by logging system to trace something and not return anything?
Shouldn’t we use something like inspect like they do in rust and avoid all the words trace, debug, info, warn, error and fatal to not confuse users?

[sharkdp]

I was thinking of Haskells Debug.Trace module that provides similar functionality.

Shouldn’t we use something like inspect like they do in rust

which inspect are you thinking of? Do you mean dbg!(…)?

and avoid all the words trace, debug, info, warn, error and fatal to not confuse users?

I like inspect. Renamed the ticket.

[irevoire]

I was thinking of the inspect on the iterators, but yeah, dbg could do it as well.
It’s less explicit though.

[irevoire]

Hey, I started working on this, and I would like some hints on the kind of implementation you would be interested in.

From what I understood, since a function in numbat cannot execute a list of instructions there is no way to do this in the stdlib.
And since a procedure cannot return a value, I cannot be a procedure either.

My idea would be to introduce a new Value::Unit variant like we have in Rust and use that in all procedures, but I feel that if it’s not already the case, it’s probably because you want to avoid this kind of « null » values.

Can you think of any other way?

[sharkdp]

I thought about implementing this as a FFI function, but haven't thought it through. Can provide more information later

[sharkdp]

So I was thinking that we could do

fn inspect<T>(x) -> T

in the prelude and then implement inspect using the FFI. I think there's currently no easy way to properly print something in FFI functions (unlike in procedures where you have access to the ExecutionContext). So we could maybe implement this using println! at first, since it's a debug-only feature. This would work okay for the CLI version, but less ideal for the WASM version (where we would print to the console).

Or we could try to pass the ExecutionContext to FFI functions. But if we do so, let's try to do it in a way that doesn't require rewriting every single FFI function signature, all of which (so far) only take Values and return Values.

[irevoire]

We also need to print the span where the call originated, am I right?
Thus, we would need to pass the spans of all arguments + the file associated with all ffi. Is there a better way to do it?

[sharkdp]

We also need to print the span where the call originated, am I right?

That would be great.

Thus, we would need to pass the spans of all arguments + the file associated with

Spans include the CodeSource as well (file or module). But yeah, this would be required. For some other features, we're also going to need the type information of the arguments in FFI functions. This could be neat for inspect as well, if we print both the value and the type. So it probably makes sense to change the Args type from being VecDeque<Value> to something like VecDeque<Argument>, where Argument would contain the Value, a TypeScheme, and Span information (and maybe more).

I recently refactored this part of the codebase. I hope we're able to maybe adapt the macros like string_arg!(…) in such a way that this doesn't require all FFI functions to change.

Maybe it makes sense to further blow up Args into something like FFIContext that would contain the arguments, the ExecutionContext, etc.?