Re: [racket-users] Creating truly unique instances of structure types?

[Ryan Culpepper]

On 11/6/18 11:31 AM, Alexis King wrote:

On Nov 5, 2018, at 20:01, Ryan Culpepper  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.

[racket-users] Racket Guide, REs, section 9.5

[Jussi Salmela]

At the end of section 9.5 there is the sentence:

   The non-greedy quantifiers are respectively: *?, +?, ??, {m}?, {m,n}?. 

I don't understand what {m}? is supposed to match because {m} means 'match 
exactly the previous pattern'.

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

Re: [racket-users] Creating truly unique instances of structure types?

[Alexis King]

> On Nov 5, 2018, at 20:01, Ryan Culpepper  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`.

> On Nov 6, 2018, at 02:47, Philip McGrath  wrote:
> 
> A variant on Alexis' example lets you circumvent Typed Racket's protections:
> 
> [snip]
> 
> Maybe this is well-known to everyone who's thought about it before, but I 
> hadn't. Though I guess, while I don't think about inspectors very often, I 
> think of them as a way for one module to put others under its control, in 
> which case maybe the module with the more powerful inspector should be able 
> to break subordinate modules' invariants.

I’m not sure, either. Personally, I feel like it should be possible to have 
invariants that truly cannot be broken, but maybe there are use cases I don’t 
understand. Anyway, in the case of Typed Racket, this is clearly a soundness 
hole, but a fixable one — either Typed Racket or the contract system is not 
applying `chaperone-struct-type` where it ought to be. I’ll file a bug.

Alexis

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

Re: [racket-users] unit testing output

[Greg Hendershott]

On Fri, Nov 2, 2018 at 3:38 PM Neil Van Dyke  wrote:
> * Should such a failing message also have some way of click navigating
> to the test failure in DrRacket, like for exceptions? (Note that the
> answer to the next might be involved.)

Yes please! It is no fun finding a failing test source in an
unfamiliar code base.

I'd suggest writing to stderr the same location format used by rackunit.

That way people in emacs can add to compilation-error-regexp-alist items like:

 ;; rackunit check-xxx
 ("#]+\\)> \\([0-9]+\\) \\([0-9]+\\)" 1 2 3)
 ;;rackunit/text-ui test-suite
 ("^location:[ ]+\\(\\([^:]+\\):\\([0-9]+\\):\\([0-9]+\\)\\)" 2 3 4 2 1)

And people using other editors can do the equivalent.

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

Re: [racket-users] Places and many cores? (File descriptor limit?)

['Paulo Matos' via Racket Users]

On 05/11/2018 15:57, Matt Jadud wrote:
> Hi all,
> 
> First, thank you for the conversation around this. 
> 
> On Sun, Nov 4, 2018 at 5:30 PM George Neuner  > wrote:
> 
> 
> One .zo per distributed place is just one descriptor per process. 
> Again insignificant because you have 4K per process.
> 
> It's apparent that the code is leaking descriptors somewhere. 
> Forcing GC may mitigate the problem, but it would be better if you
> found the leak.
> 
> 
> I've lied. I am *not* using distributed places. I'm using
> *dynamic-place*, which clearly is why I'm running into limits.
> 
> Unless anyone has alternative ideas, I'm going to restructure my code to
> use distributed places on the single machine, which will, I think, give
> me multicore parallelism and eliminate the file descriptor limit I'm
> running up against. 
> 

I have developed loci which has the same interface as places but uses
processes instead of OS threads.

https://github.com/LinkiTools/racket-loci

The documentation is non-existent but if you know places, there should
be little else to do besides replacing place for locus and places for
loci. Let me know if I can help any further.

-- 
Paulo Matos

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

Re: [racket-users] Creating truly unique instances of structure types?

[Philip McGrath]

A variant on Alexis' example lets you circumvent Typed Racket's protections:

#lang racket

(module typed typed/racket
  (provide wrapper use)
  (struct wrapper ([v : Integer]))
  (: use (-> wrapper Integer))
  (define (use w)
(add1 (wrapper-v w

(require racket/runtime-path)

(define-runtime-module-path typed
  (submod "." typed))

(define-values {wrapper use}
  (parameterize ([current-inspector (make-inspector)])
(values (dynamic-require typed 'wrapper)
(dynamic-require typed 'use

(define unchecked-wrapper
  (let-values ([(info skipped?)
(struct-info (wrapper 0))])
(struct-type-make-constructor info)))

(use (unchecked-wrapper 'nonsense))

Maybe this is well-known to everyone who's thought about it before, but I
hadn't. Though I guess, while I don't think about inspectors very often, I
think of them as a way for one module to put others under its control, in
which case maybe the module with the more powerful inspector *should* be
able to break subordinate modules' invariants.

-Philip


On Mon, Nov 5, 2018 at 9:01 PM Ryan Culpepper  wrote:

> On 11/5/18 5:26 PM, Alexis King wrote:
> > To my knowledge, there are two main techniques for creating unique
> values in Racket: `gensym` and structure type generativity. The former
> seems to be bulletproof — a value created with `gensym` will never be
> `equal?` to anything except itself – but the latter isn’t. Using reflective
> operations, it’s possible to circumvent the encapsulation afforded by the
> module system.
> >
> > To provide an example, `racket/contract` exports a value called
> `the-unsupplied-arg`, which is created using the usual structure type
> generativity trick:
> >
> > (define-struct the-unsupplied-arg ())
> > (define the-unsupplied-arg (make-the-unsupplied-arg))
> > (provide the-unsupplied-arg)
> >
> > The constructor is not exported, and this value is intended to be
> unique. However, if we can arrange for the contract library to be loaded on
> our terms, we can thwart this encapsulation by supplying it with a weaker
> inspector:
> >
> > #lang racket/base
> >
> > (define the-unsupplied-arg
> >   (parameterize ([current-inspector (make-inspector)])
> > (dynamic-require 'racket/contract 'the-unsupplied-arg)))
> >
> > (define-values [info skipped?] (struct-info the-unsupplied-arg))
> >
> > (define another-unsupplied-arg ((struct-type-make-constructor info)))
> >
> > (equal? the-unsupplied-arg another-unsupplied-arg) ; => #t
> > (eq? the-unsupplied-arg another-unsupplied-arg); => #f
> >
> > Perhaps this isn’t the end of the world, as after all, we can’t do
> anything especially nefarious with this value, and we wouldn’t be able to
> do it in the first place if we didn’t have complete control of the
> inspector hierarchy. Still, it seems a little unsatisfying.
> >
> > So, my question: is there any way to create a structure type for which
> there can truly ever only be one instance? If not, is there a fundamental
> reason why not?
>
> You could use a chaperone to prohibit `struct-info`:
>
>(define the-unsupplied-arg
>  (chaperone-struct (make-the-unsupplied-arg)
>struct:unsupplied-arg
>struct-info (lambda _ (error "not allowed"
>
> 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.
>

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