Yet another issue to pile on top of #600 and #602...
When targeting JS, string.inspect uses JSON.stringify which is able to produce escape sequences that are invalid in Gleam.
For example, control code 0x08 (backspace) should be interpreted as \u{0008} (and if #602 is merged then it will on Erlang target) but is instead turned into \b despite \b being an invalid Gleam escape sequence. Additionally, it produces unicode escape sequences in the format \uxxxx instead of the Gleam equivalent of \u{xxxx}, so it produces \u000B when it should produce \u{000B}. Ensuring that printed escape sequences are valid Gleam is important, according to @lpil in the #602 thread.
Since JSON.stringify is not a function we have defined ourselves, I believe the only recourse in this is to create our own replacement of JSON.stringify that produces valid Gleam escape sequences.
lpil
commented
3 months ago
Yet another issue to pile on top of #600 and #602...
When targeting JS,
string.inspectusesJSON.stringifywhich is able to produce escape sequences that are invalid in Gleam.For example, control code 0x08 (backspace) should be interpreted as
\u{0008}(and if #602 is merged then it will on Erlang target) but is instead turned into\bdespite\bbeing an invalid Gleam escape sequence. Additionally, it produces unicode escape sequences in the format\uxxxxinstead of the Gleam equivalent of\u{xxxx}, so it produces\u000Bwhen it should produce\u{000B}. Ensuring that printed escape sequences are valid Gleam is important, according to @lpil in the #602 thread.Since
JSON.stringifyis not a function we have defined ourselves, I believe the only recourse in this is to create our own replacement ofJSON.stringifythat produces valid Gleam escape sequences.