Warnings?

[SimonJF]

We're currently only reporting errors. I wonder whether we could consider adding a warning system as well?

I'm not entirely sure which warnings we'd want: things like overlapping patterns, for example, or the ability to deprecate library functions, or unused foralls?

[jstolarek]

Warnings sound like a good idea.

But #525. Current error reporting is very ad-hoc, at least in some places. I would like to see this fixed/improved first before extending the reporting system with warnings.

[SimonJF]

Agreed -- let's get failwith phased out first. I've been writing some code using Errors and it's actually really pleasant to do, so it might just be mechanical (if a little tedious).

[jamescheney]

Revisiting this now that #525 is in the rearview mirror. I was trying to work out what, if any, unresolved questions there are to adopting this.

Would it suffice to add a function warning : string -> unit to Errors that (perhaps depending on a debug / log level setting) just sends the corresponding warning to stderr? If desired, other more specialized warning functions could also be added.

Presumably we want warnings to go to stderr in plain text, whether or not the web server is running?

Or perhaps to the server log, once implemented #665 ?

[jstolarek]

Would it suffice to add a function warning : string -> unit

I think we should also support various classes of warnings, e.g. unused variable, overlapped pattern match, so that the programmer can decide (via config file) what kind of warning are being displayed. We also need support for -Wall and -Werror flags as well as the set of warnings enabled by default. So: warning : warning_type -> string -> unit

[jamescheney]

That makes sense. What is the definition of warning_type, and what other capabilities might we want longer-term?

For example I could imagine something very fine-grained, where each warning has a "type", a "level" and a "number" (unique integer id), allowing us to enable / disable / treat as error individual warnings by id, or groups by type or by level of seriousness. But maybe this is overkill.

Also, if some warnings may be configurably errors, that suggests having similar infrastructure for all warnings as currently exists for errors (e.g. exceptions, named raising functions, position handling etc.) where a warning is an error that may just write to stderr and proceed, or may raise the corresponding exception. Alternatively, maybe we just need one new error called WarningTreatedAsError.

[jstolarek]

I haven't thought about the exact details how to implement things, but in an ideal implementation we would accumulate warnings and errors as we parse/typecheck the program and then a handler would deal with those warnings/errors accordingly. Granted, Links implementation is not an ideal one and accumulating warnings might be non-trivial. But I would certainly want to have infrastructure for handling warnings in a reasonable way from the very beginning, rather than do a refactoring in the future.

[dhil]

This feature request came up during the meeting on Monday.