[Top][All Lists]

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

Re: [PATCH] Improved source properties and errors; => within case

From: Mark H Weaver
Subject: Re: [PATCH] Improved source properties and errors; => within case
Date: Sat, 11 Feb 2012 15:23:54 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

address@hidden (Ludovic Courtès) writes:
> However, could it be done in the tree-il/analyze.scm instead, along with
> other warning passes?

The problem is that 'case' does not exist in tree-il.  By the time
analyze.scm sees it, 'case' has been transformed into nested 'if's with
'memv's.  In theory, similar checks could still be done, but I don't see
how we could produce warning messages that are easy to understand.
Please consider how you would implement the 'duplicate-case-datum'
warning at the tree-il level, and what the messages would look like.

More generally though, I think that we should empower users to write
macros that produce warning messages.

> The reason I’m asking is that this:
>> * module/system/base/message.scm (%warning-types): Add 'bad-case-datum'
>>   and 'duplicate-case-datum' warning types.
> ... is really meant for compiler warnings (see, for instance, the output
> of ‘guild compile -Whelp’).  In particular, whether the warnings are
> emitted is determined by a #:opts sub-option to ‘compile’.

Hmm, good point.  Maybe what we need here is something analogous to
'syntax-violation', but for warnings.  One of 'syntax-warning's
arguments would be the 'warning-type' (a symbol), to allow the warning
to be disabled.

One complication is that, in order to enable ordinary users to easily
add their own warning types for their macros, there would be no fixed
set of warning types.  This suggests that it might be better to specify
the set of _disabled_ warnings, instead of the set of _enabled_
warnings.  I think this probably makes more sense anyway.  I expect that
most users want all warnings enabled (including new ones added in future
versions of Guile) except for the ones that are giving them headaches.
The current interface makes this awkward.

For compatibility with the existing interface, we could allow warnings
to be either enabled or disabled via #:opts, and then there would be a
set of warnings that are disabled by default.

What do you think?

> In addition, it would be great to have tests for the warnings
> themselves, as found at the bottom of tree-il.test.

Ah yes, thanks for pointing that out!


reply via email to

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