[plt-scheme] find-method/who

At Sat, 19 Mar 2005 21:22:56 -0500, Doug Orleans wrote:
> Matthew Flatt writes:
>  > At Wed, 9 Mar 2005 20:46:55 -0500, Doug Orleans wrote:
>  > >  > 
>  > >  > If you're writing a program-processing tool, you'll need to recertify
>  > >  > expressions that you assemble from pieces of pulled-apart expressions.
>  > >  > Or, if you don't care about discarding the enforcement power of
>  > >  > certificates, you can just recertify every expression as soon as you
>  > >  > extract it from an enclosing expression.
>  > > 
>  > > OK, I think I'm starting to grok this, but I'm not sure if I'm doing
>  > > the recertify correctly.  Should I be using `syntax-recertify', or
>  > > `syntax-local-recertifier', or both? 
>  > 
>  > If you're writing a program processor, use `syntax-recertify'. The
>  > `syntax-local-recertifier' procedure is for macros.
> 
> By "program processor" do you just mean a procedure that operates on
> syntax objects?  When if I have a macro that uses a program processor?

I had in mind an external tool, like errortrace. 

As a rule, macros shouldn't recertify. A macro that has to recertify
expressions isn't going to work in a less-privileged setting (where
recertification might not be allowed).

I guess you're using `free-vars' on the result of `local-expand' within
a macro. As I think you understand, the certificate system is trying to
prevent exactly that sort of thing; if a macro placed an identifier in
a particular position in an expansion, it might not want the identifier
used in other positions.

>  > > What should
>  > > I use as the inspector, `(current-code-inspector)'?  
>  > 
>  > Yes.
> 
> OK.  I noticed that errortrace uses (current-inspector), is this a
> signficant difference?

Oops - I think errortrace should use `current-code-inspector'.


> By the way, is there a way to inspect the certificates of a syntax
> object directly? 

Not currently.

> I'm not sure exactly what I'd do with them, but I'm
> sort of thinking I should just ignore (i.e. hide) identifiers that the
> client of my program processor can't access rather than blithely
> recertifying them all.  But I have no idea how to go about this, or
> even whether it makes sense.

I concede that it might make sense from some perspective, but I think
it's probably a bad idea.

Suppose that the free-var use involved a couple of modules, A and B,
where A defines a macro, and B uses the macro in a sub-expression sent
to free-vars. Usually, A and B will be loaded with the same privilege,
so the free-vars macro will expose the free variables introduced by A.
But if someone loads B with less privilege than A, and if the free-vars
expansion ignores uncertifiable identifiers, then the expansion of B
will be different than before. In short, I doubt that you want to be in
the position where the meaning of a module (i.e., it's expansion)
depends on its privilege relative to other modules.


For whatever real problem you're trying to solve, I imagine that you'll
have to say that the system only works when all code has the same
privilege.

Matthew