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

Super!  Thank you.


On Thu, Jan 29, 2015 at 7:51 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20150129/b7b69ecd/attachment.html>