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