Super! Thank you.
On Thu, Jan 29, 2015 at 7:51 AM, Matthew Flatt <mfl...@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
> > 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
> > 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
> > 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
> > 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
> [(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
> > Finally, does this also work for classes?
> Yes. Reflective access to information via `object-info` and
> `class-info` is controlled by inspectors.
Racket Developers list: