[racket-dev] Full transparency (was: dev Digest, Vol 72, Issue 31)

At Wed, 28 Jan 2015 16:21:51 -0700, Byron Davies wrote:
> Your code, commented:
> 
> (define orig-i (current-inspector))  ; saves the original inspector
> (define sub-i (make-inspector orig-i))  ;make a new inspector whose parent
> is the original inspector
> 
> (current-inspector sub-i)  ;makes the new inspector the current inspector
> (struct a (x))  ; creates a structure using the new inspector as the
> default inspector
> (define v (a 1))  ; creates an instance of the new structure
> (current-inspector orig-i) ;reverts the inspector to the original (the
> parent of the new inspector)
> 
> I see how this works, but I'm a little confused about why it works.  I see
> that the new inspector is a child of the old one, and I read in the
> reference chapter that access is determined not by the inspector in force
> at creation time, but by the parent of that inspector, i.e., the old
> inspector. I can't find any description of the "power" of an inspector,
> except that the parent is more powerful.
>
> Are there degrees of power? Or if you have access to the parent do you have
> all the power you can have? 

There are degrees only in that you can have a hierarchy of inspectors.
Inspector I is more powerful than inspector J if I is an ancestor of J.

I'll try to improve the docs, such as replacing "more powerful than"
with "an ancestor of".

> I see that the inspector gives you access to
> the data in a structure instance, but does it also give you access to
> meta-data, so that I know that the name of the first field in struct a is x?

You get access to all the metadata.

It turns out that fields currently have only positions, not names, but
that choice was not a good one. We plan to add support for field names
in the near future, in which case the information will be accessible
through an inspector.

> I also don't understand how the root inspector works.  I have found that
> setting (current-inspector root-inspector) delivers endless left parens for
> the (a 1) example, presumably because the display function recursively
> tries to inspect the components of the struct, all the way down.

That's a problem in the pretty printer. The pretty printer's
implementation includes

 (cond
   ....
   [(struct? v) ....]
   ....
   [(unquoted? v) ....]
   ....)

where `unquoted` is an internal structure. By setting the inspector to
the root inspector, a value that satisfies `unquoted?` also satisfies
`struct?`, and so printing doesn't reach the intended case. I'll push a
repair.


> Finally, does this also work for classes?

Yes. Reflective access to information via `object-info` and
`class-info` is controlled by inspectors.