l...@gnu.org (Ludovic Courtès) writes:
> Hello,
>
> I just committed support for ‘-Wunbound-variable’:
>
>
> http://git.sv.gnu.org/cgit/guile.git/commit/?id=f67ddf9dbfec851676806a2f3dff7eae539ac499
Looks great!
> It works pretty well, except for occurrences of ‘define-class’ et al.,
> which lead to false positives because the code generated by these macros
> doesn’t use ‘define’ (this is to make sure a top-level binding is
> created, not a lexical one.)
>
> Ideas on how to “fix” it?
Are there deeper problems with compilation and define-class /
module-define? E.g. is it possible that correct compilation of code
following a define-class or module-define would be dependent on
understanding the define-class/module-define properly?
If so, I guess either the compiler needs to recognise and process these
calls specially - in which case it should be easy for it also to pass
appropriate information to your unbound variable check - or we could
provide some kind of compile-time declaration form, and say that correct
compilation and unbound variable checking requires this to be used.
On a loosely related point, I notice that we have deprecated eval-case
in 1.9.x, in favour of eval-when. But 1.8.x only has eval-case; so
isn't the deprecation going to make it more difficult to handle code
that has to be different in 1.8.x and 1.9/2.0?
(For example, 1.8.x requires the comma trick in a macro definition that
uses a non-exported procedure from the same module, whereas 1.9/2.0
requires not using a comma.)
Alternatively, should we add a suitable eval-when to the next 1.8.x
release, to help with this?
Regards,
Neil
