* Let's fix how warnings are specified @ 2012-02-12 3:57 Mark H Weaver 2012-02-14 14:00 ` Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Mark H Weaver @ 2012-02-12 3:57 UTC (permalink / raw) To: guile-devel Hello all, At present, compile-time warnings can only be enabled, not disabled, and there is no way to enable all warnings. This means that the set of warnings has to be hard-coded into every build system. This is terrible because it means that every time we add a new warning type, users won't benefit from it unless they update their Makefiles. We need a way for users to ask for a reasonable default set of warnings (which should be almost all of them), possibly with some warnings explicitly enabled or disabled. We should also have a way to enable all warnings. It would also be nice if this could be done in such a way that external build systems can do this without breaking compatibility with Guile 2.0.[0-5]. I'm looking for ideas of how to adjust our 'compile' and 'guild compile' interfaces to accomplish these objectives. Here's a preliminary proposal: * Add new pseudo-warning types 'all' and 'default'. * For each specific warning type 'FOO', we add 'no-FOO'. * These new pseudo-warning types would be honored by both 'compile' and 'guild compile'. What do you think? Mark ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Let's fix how warnings are specified 2012-02-12 3:57 Let's fix how warnings are specified Mark H Weaver @ 2012-02-14 14:00 ` Ludovic Courtès 2012-02-14 16:56 ` Mark H Weaver 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2012-02-14 14:00 UTC (permalink / raw) To: guile-devel Hi Mark, Mark H Weaver <mhw@netris.org> 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’. At the programming level there are better ways to do this, namely (map car %warning-types) and %auto-compilation-options. > * For each specific warning type 'FOO', we add 'no-FOO'. Ditto. (Keep in mind that currently, #:opts (#:warnings ()) means literally zero warnings, and #:opts (#:warnings (foo)) means “only warning foo”.) WDYT? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Let's fix how warnings are specified 2012-02-14 14:00 ` Ludovic Courtès @ 2012-02-14 16:56 ` Mark H Weaver 2012-02-15 22:09 ` Andy Wingo 2012-02-16 21:22 ` Ludovic Courtès 0 siblings, 2 replies; 6+ messages in thread From: Mark H Weaver @ 2012-02-14 16:56 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel ludo@gnu.org (Ludovic Courtès) writes: > Mark H Weaver <mhw@netris.org> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Let's fix how warnings are specified 2012-02-14 16:56 ` Mark H Weaver @ 2012-02-15 22:09 ` Andy Wingo 2012-02-16 21:22 ` Ludovic Courtès 1 sibling, 0 replies; 6+ messages in thread From: Andy Wingo @ 2012-02-15 22:09 UTC (permalink / raw) To: Mark H Weaver; +Cc: Ludovic Courtès, guile-devel Hi, FWIW, I'm fine with whatever you all agree upon in the end, though I am sympathetic to Mark's concerns here. One thing: On Tue 14 Feb 2012 17:56, Mark H Weaver <mhw@netris.org> writes: > (compile x #:opts '(#:warnings (default no-format no-bad-case-datum))) 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. IMO anyway :) Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Let's fix how warnings are specified 2012-02-14 16:56 ` Mark H Weaver 2012-02-15 22:09 ` Andy Wingo @ 2012-02-16 21:22 ` Ludovic Courtès 2013-01-16 10:34 ` Andy Wingo 1 sibling, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2012-02-16 21:22 UTC (permalink / raw) To: Mark H Weaver; +Cc: guile-devel Hello! Mark H Weaver <mhw@netris.org> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <mhw@netris.org> 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)))) Or: #:warnings (remove (cut memq <> '(format bad-case-datum)) %auto-compilation-options) 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 <wingo@pobox.com> 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! Thanks, Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Let's fix how warnings are specified 2012-02-16 21:22 ` Ludovic Courtès @ 2013-01-16 10:34 ` Andy Wingo 0 siblings, 0 replies; 6+ messages in thread From: Andy Wingo @ 2013-01-16 10:34 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Mark H Weaver, guile-devel Hi! Mark, are you still interested in implementing this? It would be very nice :) On Thu 16 Feb 2012 22:22, ludo@gnu.org (Ludovic Courtès) writes: > Mark H Weaver <mhw@netris.org> skribis: > >> ludo@gnu.org (Ludovic Courtès) writes: >> >>> Mark H Weaver <mhw@netris.org> 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 agree with Ludo here -- for example in GCC, -Wall doesn't actually enable all warnings, just more of them. You need to be able to list the set of enabled warning passes I think. Dunno. > Andy Wingo <wingo@pobox.com> 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! This would also be nice :) Regards, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-01-16 10:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-12 3:57 Let's fix how warnings are specified Mark H Weaver 2012-02-14 14:00 ` Ludovic Courtès 2012-02-14 16:56 ` Mark H Weaver 2012-02-15 22:09 ` Andy Wingo 2012-02-16 21:22 ` Ludovic Courtès 2013-01-16 10:34 ` Andy Wingo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).