On Wed 07 Oct 2009 22:27, Neil Jerram <[email protected]> writes:
> [email protected] (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/
