From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Let's fix how warnings are specified Date: Tue, 14 Feb 2012 11:56:58 -0500 Message-ID: <87hayt4alh.fsf@netris.org> References: <8739ag66v0.fsf@netris.org> <87pqdhwm45.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1329238739 13956 80.91.229.3 (14 Feb 2012 16:58:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2012 16:58:59 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 14 17:58:58 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RxLiT-0002MG-Vb for guile-devel@m.gmane.org; Tue, 14 Feb 2012 17:58:58 +0100 Original-Received: from localhost ([::1]:49143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxLiT-0004Hm-4a for guile-devel@m.gmane.org; Tue, 14 Feb 2012 11:58:57 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxLiO-0004HU-6o for guile-devel@gnu.org; Tue, 14 Feb 2012 11:58:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxLiF-0002iJ-N2 for guile-devel@gnu.org; Tue, 14 Feb 2012 11:58:52 -0500 Original-Received: from world.peace.net ([96.39.62.75]:58329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxLiF-0002gb-KF; Tue, 14 Feb 2012 11:58:43 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1RxLhw-0007sd-A5; Tue, 14 Feb 2012 11:58:24 -0500 In-Reply-To: <87pqdhwm45.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 14 Feb 2012 15:00:42 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13858 Archived-At: ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> Here's a preliminary proposal: >> >> * Add new pseudo-warning types 'all' and 'default'. > > Yes, but only at the UI level=E2=80=93i.e., in =E2=80=98guild compile=E2= =80=99, along with > =E2=80=98help=E2=80=99. 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=3D> (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