Re: [racket-dev] Full transparency (was: dev Digest, Vol 72, Issue 31)

2015-01-29 Thread Byron Davies
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)

2015-01-29 Thread Matthew Flatt
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

2015-01-22 Thread Matthew Flatt
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 matth...@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 byrondav...@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 byrondav...@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
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Full transparency

2015-01-21 Thread Byron Davies
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 byrondav...@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


Re: [racket-dev] Full transparency

2015-01-21 Thread Matthias Felleisen

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 byrondav...@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 byrondav...@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


Re: [racket-dev] Full transparency

2015-01-21 Thread Byron Davies
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 matth...@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 byrondav...@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 byrondav...@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