Should the default dhall command emit the type to stderr?

[Gabriella439]

One issue that I've begun to run into recently is the fact that the default dhall command (i.e. no subcommand) reserves stderr for printing the inferred type of the expression. This prevents the executable from emitting useful information to stderr for successful runs.

For example, the next release of the standard will say:

An implementation SHOULD warn the user if the interpreter is unable to cache the expression due to the environment variables being unset or the filesystem paths not being readable or writeable.

The natural place to put that warning would be stderr but that would cause issues for people expecting stderr to contain the type.

Similarly, at some point we might want to provide download progress indicators for remote imports and the natural place for that would also be stderr.

Currently, users can use the dhall type subcommand to programmatically retrieve the inferred type of an expression, so there is less of a need to include the inferred type in the default command's output.

So I'm going to propose a few solutions to this problem so that we can include useful diagnostic information in stderr:

• Omit the inferred type from stderr entirely for the default command (i.e. reserve stderr exclusively for debug output and reserve dhall type as the exclusive way to infer the type)
• Keep the inferred type, but comment out other debug output sent to stderr so that one can still capture stderr as a valid Dhall type
• Keep the inferred type, but don't guarantee that stderr still reflects a valid type if there is debug output

My inclination is for the second option (comment out debug output), but I'm open to other ideas

[Profpatsch]

I think we should never abuse stderr for carrying in-band data (as compared to meta data, like warnings or errors). Users should never use any data on stderr for further processing (except maybe formatting for logging).

If a user wants to prevent having to call the interpreter twice, there’s other methods, like having a --type-output argument which the user can pass a FIFO to. Or maybe even a file handle.

[ocharles]

I find the current behaviour inconvenient as I'm calling dhall during Nix evalutaion (with import-from-derivation). The current behavior means that during evaluation Dhall types get printed out. However, I can't redirect stderr to /dev/null because then I would actually lose error messages when there is a problem.

[sellout]

I vote for option one (no types on stderr). What if some option like @Profpatsch suggests outputs the normalized form with an explicit type annotation, so that the stdout is still valid Dhall?

[Gabriella439]

Alright, then we'll go with no types on stderr. Let me also see if I can add an easier way to obtain the type besides dhall resolve | dhall type

[f-f]

@Gabriel439 I'd +1 as well on the --type-output flag as @Profpatsch suggested

[Gabriella439]

I really like @sellout's suggestion of including the type annotation in stdout. I think the main question on my mind is whether or not the type annotation should be present or absent by default. Either way there would be some option to toggle the type annotation.

[Gabriella439]

I think I'll tentatively go with omitting the type annotation by default and allowing the user to opt in using an --annotate switch