[plt-scheme] find-method/who

On Mar 28, 2005, at 12:14 PM, Matthew Flatt wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> At Sat, 26 Mar 2005 22:15:12 -0500, Doug Orleans wrote:
>> Well, I already need to use a module that I don't have privilege over,
>> namely MzLib's "class.ss".  It seems like I should not be reporting
>> `find-method/who' as a free variable of every procedure that uses the
>> `send' macro, because it's private to "class.ss".
>
> This is along the lines of a path that I abandoned. For example, I
> wanted errortrace to work even if it was given less privilege than
> MzScheme (which includes macros that introduce references to private
> variables). I couldn't make it work well enough to be useful, though.
>
> For your purposes, a simple `identifier-exported?' predicate might be
> enough. Here's a little hack that I think implements the predicate:
>
>  (define (identifier-exported? id)
>    (parameterize ([current-code-inspector (make-inspector)])
>      ;; If `id' isn't exported, then attempting to expand
>      ;;  an uncertified version of the identifier shouldn't work:
>      (with-handlers ([exn:fail:syntax? (lambda (x) #f)])
>        (local-expand (datum->syntax-object id (syntax-e id))
>                      'expression
>                      (list #'#%top))
>        #t)))
>
> If it's not used for a macro, then `local-expand' above should be just
> `expand-syntax'. (It could be implemented much more cleanly as a
> primitive.)

I realize that this same trick (trying to expand) can give the the 
information that I want in order to debug missing uses of 
syntax-recertify.  In fact, trying to expand is a _better_ check than 
having syntax-recertify fail, because there may be totally irrelevant 
certificates attached to a piece of syntax whose absence I wouldn't 
miss at all, and I don't want to signal an error for these.


Thanks,

john