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 > 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. > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev