Re: Reporting possibly unbound variables

[Andy Wingo]

On Wed 07 Oct 2009 22:27, Neil Jerram <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:
>
>> 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?

I don't think there are problems, no...

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

Well the compiler could recognize module-define as a primitive, and
potentially transform it to be a <toplevel-define>. But that would
happen after the unbound-variables check runs -- so I don't know.

Another possibility would be a hack, but hey: have the -Wunbound thing
detect (if (defined? ...) ...) forms, and do something appropriate.

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

Perhaps, though if you are updating already to 2.0, I would just make a
2.0 compatibility library, as far as possible. In macros you could do
the @/@@ trick.

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

See NEWS line 282 :) And add something or propose new behavior, as
appropriate.

> Alternatively, should we add a suitable eval-when to the next 1.8.x
> release, to help with this?

I think that would be a good idea, yes.

Andy
-- 
http://wingolog.org/