enhancement request: warning [was: error/2]

[pkoppstein]

[This proposal has been tweaked to take into account subsequent comments.]

error/1 writes to stderr, which is a good thing, but currently so far as I know, there's no way to write to stderr without also backtracking. Being able to write to stderr without backtracking has several uses, not least as an aid to debugging.

warning(MSG) would fill the bill.

This would evaluate to ".".

[nicowilliams]

Wouldn't this then be a warning?

[pkoppstein]

@nicowilliams asked:

Wouldn't this then be a warning?

The main motivation for suggesting error/2 was, as I said, to avoid introducing a new name. But there's another reason: the Unix gods gave us stdin, stdout, and stderr, but no stdwarning. Of course you could say that "stdwarning =~ stderr - noexit" but then error/2 gives you a bonus as per the suggested spec. But the naming is less important than the having :-)

[nicowilliams]

I'm thinking of having a catch that could catch errors, so error needn't exit. Indeed, error doesn't exit today.

As for stdin/out/err naming, I'm thinking of making the upcoming I/O builtins include a set of stdin, stdout, and stderr builtins for reading from stdin and writing to either stdout or stderr. Then warning or your error/2 can be simple wrappers around stderr.

[pkoppstein]

@nicowilliams pointed out:

error doesn't exit today.

My apologies. This enhancement request was written under a misapprehension. Still, it seems to me that jq ought to have a way to write to stderr with and without an early exit. Before I get too deeply lost in the maze of possibilities, could you please indicate whether you see an "error with exit" in jq's (near-term) future?

[nicowilliams]

@pkoppstein

My plan is to add a halt builtin for halting a VM. error will continue working as it does today.

I'll add a way to read/write from/to stdin/stdout/stderr. A warning could then be easily implemented as writing to stderr.

error specifically raises an error which triggers backtracking. warning will be like . with the side-effect of writing to stderr.

[nicowilliams]

And I still want to find a decent way to get a catch.

[pkoppstein]

@nicowilliams - Thanks for the clarifications.

As for catch -- I think eval, warning (however implemented), import, and module are vastly more urgent. FWIW :-)

[nicowilliams]

evalwill wait for I/O, as will warn. catch needn't, but it's not urgent. I don't think the module system is remotely urgent. I/O is most urgent because it is needed to deal with more data in an online way (that or we need a streaming parser option, but since we need it for argument files too, it quickly becomes clear that we need I/O-like primitives).

[nicowilliams]

I put some time into TCO because I was hoping that it'd make it easier to write some iterators via recursion, but so far it only works for some very simple recursive iterator cases: in particular it doesn't work for producing efficient generators, only reducers (ironic, no?).

[pkoppstein]

@nicowilliams wrote:

I don't think the module system is remotely urgent.

A previous post had suggested that although you were not impressed by the urgency of support for namespace management, you were eager to support packages. Since the import/module system would also be a foundation for eval, doesn't the sum of all three of these impetuses add up to "high priority"?

[nicowilliams]

Namespace mgmt can be done manually now -- there is a workaround for lacking a module system.

There is no workaround for lacking I/O, lacking generic generator constructors, lacking a limit, nor lacking a catch. There's a pile of PRs to review and meege, and a pile of feature requests, all of which need to be prioritized. But if you send me a PR for a module system, I'll make integration a priority :)

[emanuele6]

This issue was basically a feature request for stderr or stderr | empty... closing.