[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Let's fix how warnings are specified

From: Ludovic Courtès
Subject: Re: Let's fix how warnings are specified
Date: Thu, 16 Feb 2012 22:22:07 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux)


Mark H Weaver <address@hidden> skribis:

> 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.

It can be centralized and user-extensible, can’t it?  For instance,
(system base message) could export ‘register-warning-type!’.

> 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.

Sounds good.

What about using <warning-type> objects instead of symbols?

Besides, message output ought to remain centralized, for various
reasons.  We don’t want users to use ‘format’ or ‘display’ to write
anything in free-form style anywhere.  ;-)

> 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))))


  #:warnings (remove (cut memq <> '(format bad-case-datum))

Yes, it’s more verbose than ‘no-format’, etc., but again: it’s a
/programming/ interface, so it’s also more expressive.

I find it important to distinguish between the programming interface and
the user interface, because the expectations are very different.  And
it’s similarly important to distinguish what belongs in each category.

To me, ‘compile’ is rather part of the programming interface, because
there’s nothing else to do the job.

Andy Wingo <address@hidden> skribis:

> Let's pave this cowpath and add a #:warnings option to compile.  It
> could default to #f.  If it's not #f, then we require it to be a list,
> and append `(#:warnings ,warnings) to the #:opts.

Yes, sounds good!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]