io.debug does not show module qualifiers

[sdancer]

  let b = gws_2_c_protocol.LogInRes(shared.EErrorTypeEErrorTypeSUCCESS, option.None, option.None, option.None, option.None, option.None)

becomes

LogInRes(EErrorTypeEErrorTypeSuccess, None, None, None, None, None)

[lpil]

io.debug is a runtime tool and as such it only shows information present at runtime. Other information such as types or the state of imports in the current module is only present at compile time and cannot be used when your program is running.

[sdancer]

ye, i understand where its limitation comes from, but its transforming data in wrong ways
ultimately, need something like rust {:?} or similar
but meanwhile, in the example above the erlang atom representation of the state is ":e_error_type_e_error_type_success", this can be traced back to the erlang source code at least

one thing i wonder is, why not just use the atoms as they are in the gleam source code? erlang doesn't care about what atoms say at all

[lpil]

It's not wrong that is the correct representation for that atom in Gleam. The io.debug function favours Gleam syntax when there is one and there is no way to know which of the two syntaxes you would prefer. If we were to use the Erlang syntax people would (and they did) complain that it doesn't use Gleam syntax.

Rust's Debug is a trait so it's not comparable to io.debug, which isn't polymorphic in this way. The equivilent in Gleam would be to write the explicit version that Rust's trait usages desugars too.

pub type Debug(a) {
  Debug(show: fn(a) -> String)
}

pub fn debug(value: a, impl: Debug(a)) -> String {
  impl.show(value)
}

Gleam is an explicit language and does not support implicit supplying of interface implementations.

[inoas]

I suggest(ed) that we add a debug_raw or something (debug_vm maybe?), but it may be better put in gleam/erlang than stdlib I suppose, unless we also make it return reasonable JavaScript representations.

[inoas]

If you are interested in such a thing I would be willing to take a look first at Erlang and then at JavaScript. string.runtime_value(of term: anything) and io.runtime_debug() maybe.

[sdancer]

is the sum of multiple issues, if u know the type u can run a formatter based on the erlang header files for example, however from the data itself of a runtime value u only get the type name(from the record first field)