Re: Let's fix how warnings are specified

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> Here's a preliminary proposal:
>>
>> * Add new pseudo-warning types 'all' and 'default'.
>
> Yes, but only at the UI level–i.e., in ‘guild compile’, along with
> ‘help’.

The fundamental problem with this strategy is that it requires a
centralized master list of warning types, which makes it very awkward
for users to add their own new warning types that can be explicitly
disabled.

I'd like users to be able to write this within a procedural macro:

  (if (warning-requested? 'my-new-warning #t)
      (my-new-warning-pass x))

The second argument to 'warning-requested?' specifies whether this new
warning is in the 'default' set of warnings.

I already have a patch set that implements this.  It is simple to
implement and convenient to use.  There is no comprehensive centralized
list of warnings.  'warning-requested?' is implemented like this:

  (define* (warning-requested? name
                               #:optional
                               (default? #t)
                               (spec (fluid-ref *requested-warnings-spec*)))
    (and (or (memq name spec)
             (memq 'all spec)
             (and default? (memq 'default spec)))
         (not (memq (symbol-append 'no- name) spec))))

The warning message includes the name of the warning type, so if the
user sees too many spurious warnings of that type, they can easily
disable it.

With your strategy, please consider what would be required for a library
author to export a macro that issues a new warning type that can be
disabled by the user.  The warning would not be shown unless users of
the library arranged to extend their centralized %warning-types,
%default-warning-types, %auto-compilation-options, and possibly their
own code that calls 'compile'.

Given all this hassle, it is likely that library writers will simply
issue warnings that cannot be disabled, or that must be disabled using a
non-standard mechanism.

> At the programming level there are better ways to do this, namely
> (map car %warning-types) and %auto-compilation-options.

Even for users, this is very awkward.  From a user's perspective, the
most common case (apart from using all defaults) is to _disable_ one or
more warnings, but to otherwise use the default set.

Following your suggestion, compiling something with the 'format' and
'bad-case-datum' warnings disabled (but otherwise using the default
warnings) looks something like this:

  (compile x #:opts `(#:warnings
                      ,(lset-difference
                        eq?
                        (or (and=> (memq #:warnings
                                         %auto-compilation-options)
                                   cadr)
                            '())
                        '(format bad-case-datum))))

With my proposal, it looks like this:

  (compile x #:opts '(#:warnings (default no-format no-bad-case-datum)))

Of course, with suitable helper functions, we could make it easier to
construct a desired set of warnings, but again, it still has the
fundamental problem that a centralized list of warnings inhibits users
from adding their own new warning types that can be disabled in the
standard way.

    Thanks,
      Mark