Should error messages show unescaped strings?

[NReilingh]

I'm not sure where this comes from exactly, but I have an expectation that when something like a validation error based on a regex or string comes back to the terminal, the strings should be printed in their interpreted (semantic?) forms instead of the source code representation of a string sequence literal.

What makes sense to me in theory is that when the program is outputting an informational string to me to tell me what value is invalid, it should tell me the actual value, not the literal sequence that I needed to escape for syntax constraints. After all, the reader doesn't need escape sequences in order to parse the string correctly with their eyes and brain -- and if someone were to want to pipe this output into a different tool, they would be be responsible for escaping it again per the tool's requirements.

Practically, I also want the error to help me confirm that I did the escaping properly. When creating RegEx constraints, in particular, you often need an oppressive number of backslashes unless you use a different escape delimiter.

Also worth noting that what cue currently does is not to simply parrot the source code representation back at you -- if you give it values using an altered escape delimiter like \#, it will still give you back values that have been re-escaped in a JSON-like style:

test1.cue

re: #"hel\lo"#
re: =~#"^\w\w$"#

$ cue eval test1.cue

re: invalid value "hel\\lo" (out of bound =~"^\\w\\w$"):
    ./test.cue:2:5
    ./test.cue:1:5

In contrast, my expected behavior would be along the lines of:

test2.cue

uncPath: #"\\ad\oops\whatever"#
uncPath: "^\\\\\\\\ad\\\\share\\\\\\w+"

$ cue eval test2.cue

uncPath: invalid value "\\ad\oops\whatever" (out of bound =~"^\\\\ad\\share\\\w+"):
    ./test.cue:2:10
    ./test.cue:1:10

Thoughts?

[myitcv]

@NReilingh apologies for the delay in replying here.

I'll defer to @mpvl on the history/reasoning behind this, but here are my thoughts FWIW 😄

• Printing in the source form allows the values to be copy-pasted into source more easily, rather than requiring translation of some sort
• Normalising the representation of strings helps from a readability/consistency perspective, especially when such strings appear side-by-side. Regularly expressions complicate this, but at least I only have to adjust for that when I see two string values

[NReilingh]

Hi @myitcv, thanks for the reply.

I think I would argue that printing out a source form can be useful for copy-pasting, but isn't always the desirable behavior for a given message. If the compiler or tool is outputting an error message saying "try this in your code", then yes that should be in a source form, but what's happening here is a reference to some values that we have in our input. If we were doing Rust- or Elm-style compiler output with a caret ^ printed underneath the echoed line of offending source code pointing out the exact problem character, then you would want the source representation, but not the normalized one -- you'd want it to be exactly the same as the input. But neither of those cases really apply here, since the full error messages in question are a prose form.

I also disagree with your argument about consistency when appearing side-by-side, since to do this you would, again, want to match the source representation instead of normalizing.

I think the reason I'm so irked by this behavior also addresses your point about requiring translation. In my mind, the purpose of running a compiler or other tool that takes source code as input is to have the computer do the parsing, tokenizing, and execution (or translation) that I have already done in my head while writing the code, in order to confirm my mental model. So when I'm writing a string with escapes, I already have a very specific notion of how I expect the tool to parse my source code into its internal string representation. Cue is (needlessly IMO) adding an additional translation step at the end of the pipeline to convert back into a normalized source form, which makes it more difficult for me as the programmer to unwind my mental model.

Also curious to know what thoughts @mpvl has on the theory.

[cueckoo]

This discussion has been migrated to cue-lang/cue#892.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.