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 mfl...@cs.utah.edu
To: Byron Davies byrondav...@starshine.us
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 `#a`. 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
remember how easy it was with the Lisp Machine to navigate through data no
matter what it was.
The Lisp Machine offered total transparency,
