<div dir="ltr">Super! Thank you.<div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Jan 29, 2015 at 7:51 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. </blockquote></div> </div>