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 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] dev Digest, Vol 72, Issue 31
My apologies, especially to Matt, for letting this thread go cold. I was busy preparing a Racket-based demo for this morning -- and it went very well. As mentioned, I'm working on weakest precondition analysis for finding latent faults in programs. Our goal is to do this for all kinds of software, including machine language, but for proof of concept I'm doing it *in* Racket *on* Racket programs. Racket's language building tools, including syntax and the syntax browser, have been very useful for this problem. Regarding transparency, thank you, Matt, for suggesting an alternative approach. I've played with your examples a bit, trying to see how I could use this during debugging. I have also read the Reflection and Security chapter in the reference to learn more about inspectors in general. 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? 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? 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. Finally, does this also work for classes? Date: Thu, 22 Jan 2015 05:36:18 -0700 From: Matthew Flatt To: Byron Davies Cc: dev@racket-lang.org Subject: Re: [racket-dev] Full transparency Message-ID: <20150122123620.2daa1650...@mail-svr1.cs.utah.edu> Content-Type: text/plain; charset=UTF-8 I don't think you want to do anything with the compiler or macros. Instead, it's a matter of having a sufficiently powerful inspector (which is the concept of "inspectability" turned into a language construct). If you have just (struct a (x)) (a 1) then the result will print as `#`. But if you use (define orig-i (current-inspector)) (define sub-i (make-inspector orig-i)) (current-inspector sub-i) (struct a (x)) (define v (a 1)) (current-inspector orig-i) v Then, the result will print as `(a 1)`. That's because the structure declaration is creates under an inspector `sub-i` (which is the current inspector at the time) that is subordinate to the inspector `orig-i` that is in place when the structure instance is printed. The current inspector is determined dynamically, which means that if you're loading some code, you can set the inspector while loading the code. For example, if "a.rkt" is #lang racket/base (provide v) (struct a (x)) (define v (a 1)) then (define v (parameterize ([current-inspector (make-inspector)]) (dynamic-require "a.rkt" 'v))) v will print the `a` instance transparently. To protect libraries, there's no safe way to access a root inspector that controls all structure types when you start Racket. Nothing is safe from unsafe code, though, and here's an unsafe way to access the root inspector: #lang racket/base (require ffi/unsafe) (define-cstruct _Scheme_Inspector ([stag _short] [keyex _short] [depth _int] [superior _racket])) (define root-inspector (Scheme_Inspector-superior ((get-ffi-obj 'scheme_get_initial_inspector #f (_fun -> (_gcable _Scheme_Inspector-pointer)) Using `root-inspector`, you can inspect any structure instance. At Wed, 21 Jan 2015 23:46:10 -0700, Byron Davies wrote: > Nice parry! What may be straightforward to you may not be so obvious to > me. But I'll take a look. > > I'm deep into a project using Racket for weakest precondition analysis. > Every time I'm debugging it seems like I have to write another > special-purpose accessor, or export some existing accessor up through > multiple levels in order to get at the data I need at the top-level. I > re
Re: [racket-dev] Full transparency
Nice parry! What may be straightforward to you may not be so obvious to me. But I'll take a look. I'm deep into a project using Racket for weakest precondition analysis. Every time I'm debugging it seems like I have to write another special-purpose accessor, or export some existing accessor up through multiple levels in order to get at the data I need at the top-level. I remember how easy it was with the Lisp Machine to navigate through data no matter what it was. The Lisp Machine offered total transparency, with no real way to protect data, to the benefit of the developer. Racket offers total opacity, to the benefit of code security. I'm hoping there's a middle ground, where transparency can be turned on and off. Byron On Wed, Jan 21, 2015 at 12:20 PM, Matthias Felleisen wrote: > > Sounds like a straightforward change to the existing macros. Why don't you > create a fork and experiment? > > > On Jan 21, 2015, at 1:15 PM, Byron Davies > wrote: > > > Or, more conservatively, every struct and object in a given package, > file, or set of files. > > > > On Wed, Jan 21, 2015 at 11:03 AM, Byron Davies > wrote: > > Would it be easy to create a compiler flag that would make every struct > and object transparent? This would then make it easy to create a Lisp > Machine-style Inspector that would be able to roam through every data > structure during debugging. > > > > Byron > > > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Full transparency
Or, more conservatively, every struct and object in a given package, file, or set of files. On Wed, Jan 21, 2015 at 11:03 AM, Byron Davies wrote: > Would it be easy to create a compiler flag that would make every struct > and object transparent? This would then make it easy to create a Lisp > Machine-style Inspector that would be able to roam through every data > structure during debugging. > > Byron > > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Full transparency
Would it be easy to create a compiler flag that would make every struct and object transparent? This would then make it easy to create a Lisp Machine-style Inspector that would be able to roam through every data structure during debugging. Byron _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pretty-printing properties in syntax browser
I’m putting large s-expressions as properties on syntax objects. When I display them in the right pane of the syntax browser, they go way off the side of the pane. I’d like to be able to pretty-print the values of properties. I can’t figure out how to insert pretty-print into the property display routine. Any ideas? Byron _ Racket Developers list: http://lists.racket-lang.org/dev