On 11/6/18 11:31 AM, Alexis King wrote:
On Nov 5, 2018, at 20:01, Ryan Culpepper <ry...@ccs.neu.edu> wrote:
You could use a chaperone to prohibit `struct-info`
Good point! I had forgotten that `struct-info` is a chaperoneable operation.
This isn’t ideal, though, since I don’t think `struct-info` is ever actually
supposed to raise an error, it’s just supposed to return #f, instead. It’s
possible to call `struct-info` on absolutely anything, even things like
numbers, and get a result:
> (struct-info 3)
#f
#t
If I understand correctly, this is because all values in Racket are “morally
structures”, and reflective operations on values that are not actually
implemented with structures should behave identically to reflective operations
on values for which you do not have a sufficiently powerful inspector to
inspect.
Unfortunately, it isn’t possible to regain this behavior with
`impersonate-struct`, since `impersonate-struct` does not allow you to
impersonate `struct-info`.
One solution is to delay the error by having `struct-info` return a
chaperoned struct-type (using `chaperone-struct-type`) that makes
`struct-type-make-constructor` raise an error. The struct-type chaperone
should also prevent the creation of substruct instances (say, by adding
a guard that always raises an error).
It seems like it should also be reasonable to let the `struct-info`
interposition replace a struct type with #f, since that represents less
information at the level of the *interpretation* of the operation. So
it's morally a projection wrt the information ordering for the
`struct-info` operation, even though it's not a projection wrt the
generic information ordering for Racket values.
Ryan
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
