[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 <mflatt at cs.utah.edu>
To: Byron Davies <byrondavies at starshine.us>
Cc: dev at racket-lang.org
Subject: Re: [racket-dev] Full transparency
Message-ID: <20150122123620.2DAA16501A2 at 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, 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 <matthias at ccs.neu.edu
>
> 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 <byrondavies at starshine.us>
> > 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 <
byrondavies at starshine.us>
> > 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

On Thu, Jan 22, 2015 at 5:36 AM, <dev-request at racket-lang.org> wrote:

> Send dev mailing list submissions to
>         dev at racket-lang.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.racket-lang.org/dev/listinfo
> or, via email, send a message with subject or body 'help' to
>         dev-request at racket-lang.org
>
> You can reach the person managing the list at
>         dev-owner at racket-lang.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev digest..."
>
>
> [Racket Developers list:
>  http://lists.racket-lang.org/dev ]
>
>
> Today's Topics:
>
>    1. Full transparency (Byron Davies)
>    2. Re: Full transparency (Byron Davies)
>    3. Re: Full transparency (Matthias Felleisen)
>    4. Re: Full transparency (Byron Davies)
>    5. Literal constants (Jens Axel S?gaard)
>    6. Re: Full transparency (Matthew Flatt)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 Jan 2015 11:03:49 -0700
> From: Byron Davies <byrondavies at starshine.us>
> To: dev at racket-lang.org
> Subject: [racket-dev] Full transparency
> Message-ID:
>         <CAAQ2ZgmJ1LiZBCRxoDY9as=BnTjtPaY2CKcp3CvG+5rqMX2D=
> g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.racket-lang.org/dev/archive/attachments/20150121/211388c2/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 21 Jan 2015 11:15:04 -0700
> From: Byron Davies <byrondavies at starshine.us>
> To: dev at racket-lang.org
> Subject: Re: [racket-dev] Full transparency
> Message-ID:
>         <CAAQ2Zgkp1xyHah7h5BOANTFvKH4ZiQM70v4CLcaEv7G_dp=
> a_A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <byrondavies at starshine.us>
> 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
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.racket-lang.org/dev/archive/attachments/20150121/5cdd98ac/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 Jan 2015 14:20:44 -0500
> From: Matthias Felleisen <matthias at ccs.neu.edu>
> To: Byron Davies <byrondavies at starshine.us>
> Cc: dev at racket-lang.org
> Subject: Re: [racket-dev] Full transparency
> Message-ID: <DEE2064C-8018-42E4-B082-A143D2D43720 at ccs.neu.edu>
> Content-Type: text/plain; charset=us-ascii
>
>
> 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 <byrondavies at starshine.us>
> 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 <byrondavies at starshine.us>
> 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
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 Jan 2015 23:46:10 -0700
> From: Byron Davies <byrondavies at starshine.us>
> To: Matthias Felleisen <matthias at ccs.neu.edu>
> Cc: dev at racket-lang.org
> Subject: Re: [racket-dev] Full transparency
> Message-ID:
>         <
> CAAQ2Zgkht1qLKbT-C3SuQEUhSaPpTR8zCR4+ywA0yybpyejuEA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <matthias at ccs.neu.edu
> >
> 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 <byrondavies at starshine.us>
> > 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 <
> byrondavies at starshine.us>
> > 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
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.racket-lang.org/dev/archive/attachments/20150121/a72aa3f8/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 22 Jan 2015 11:24:25 +0100
> From: Jens Axel S?gaard <jensaxel at soegaard.net>
> To: "dev at racket-lang.org" <dev at racket-lang.org>
> Subject: [racket-dev] Literal constants
> Message-ID:
>         <
> CABefVgzAMjrhYDMCke-1Oo_ynZ7AAovh06ePe3WG-YKKqFTGCg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> This program returns #f - I was expecting to see #t.
>
>     #lang racket
>     (define a '(1 2 3))
>     (define b '(1 2 3))
>     (eq? a b)
>
> Why not guarantee uniqueness of  literals occurring in the same module?
>
> /Jens Axel
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 22 Jan 2015 05:36:18 -0700
> From: Matthew Flatt <mflatt at cs.utah.edu>
> To: Byron Davies <byrondavies at starshine.us>
> Cc: dev at racket-lang.org
> Subject: Re: [racket-dev] Full transparency
> Message-ID: <20150122123620.2DAA16501A2 at 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, 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 <
> matthias at ccs.neu.edu>
> > 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 <byrondavies at starshine.us>
> > > 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 <
> byrondavies at starshine.us>
> > > 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
>
>
> End of dev Digest, Vol 72, Issue 31
> ***********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20150128/b53c04c1/attachment-0001.html>