Oh Sam was supposed to move the Gnats issues into Github issues. Cool.
> On May 12, 2017, at 2:26 PM, Asumu Takikawa wrote:
>
> On 2017-05-12 17:30:26 +, Sam Tobin-Hochstadt wrote:
>> Unfortunately they aren't a separate data type, so the proxy has to be on
>> the thread.
>
> JFYI, t
On 2017-05-12 17:30:26 +, Sam Tobin-Hochstadt wrote:
>Unfortunately they aren't a separate data type, so the proxy has to be on
>the thread.
JFYI, there is a bug # for the soundness issue with thread mailboxes:
http://bugs.racket-lang.org/query/?cmd=view
audit-trail&database=defaul
That’s what the (mail) thread started with. See below.
> On May 12, 2017, at 1:30 PM, Sam Tobin-Hochstadt wrote:
>
> Unfortunately they aren't a separate data type, so the proxy has to be on the
> thread.
>
>
> On Fri, May 12, 2017, 1:28 PM Matthias Felleisen wrote:
>
> I should have wri
Unfortunately they aren't a separate data type, so the proxy has to be on
the thread.
On Fri, May 12, 2017, 1:28 PM Matthias Felleisen
wrote:
>
> I should have written thread-channels. (I did try regular channels, and I
> found the types and proxies.)
>
>
> > On May 12, 2017, at 1:27 PM, Sam Tob
I should have written thread-channels. (I did try regular channels, and I found
the types and proxies.)
> On May 12, 2017, at 1:27 PM, Sam Tobin-Hochstadt wrote:
>
> We have proxies for channels, but not for threads.
>
>
> On Fri, May 12, 2017, 1:25 PM Matthias Felleisen wrote:
>
> Ouch.
We have proxies for channels, but not for threads.
On Fri, May 12, 2017, 1:25 PM Matthias Felleisen
wrote:
>
> Ouch. (I should have thought of this.)
>
> So we need proxies for channels.
>
>
>
>
> > On May 12, 2017, at 1:21 PM, Scott Moore wrote:
> >
> > Can confirm. ;)
> >
> > On May 12, 2017,
Ouch. (I should have thought of this.)
So we need proxies for channels.
> On May 12, 2017, at 1:21 PM, Scott Moore wrote:
>
> Can confirm. ;)
>
> On May 12, 2017, 1:13 PM -0400, Sam Tobin-Hochstadt ,
> wrote:
>> The problem with Typed Racket would come from sending a higher order value
Can confirm. ;)
On May 12, 2017, 1:13 PM -0400, Sam Tobin-Hochstadt ,
wrote:
> The problem with Typed Racket would come from sending a higher order value to
> an untyped thread. I'm pretty sure you could get unsoundness there.
>
> > On Fri, May 12, 2017, 12:00 PM Matthias Felleisen
> > wrote:
The problem with Typed Racket would come from sending a higher order value
to an untyped thread. I'm pretty sure you could get unsoundness there.
On Fri, May 12, 2017, 12:00 PM Matthias Felleisen
wrote:
>
> I cannot turn this one into a problem with Typed Racket though. th must
> have type Threa
At Fri, 12 May 2017 13:38:44 -0300, Gustavo Massaccesi wrote:
> I always thought it was strange that mutable pairs can’t be
> chaperoned, but boxes and vectors of length 2 can. Moreover, there was
> (is?) a plan to replace the implementation of mcons with structs. Does
> #:authentic make this more
Somewhat related ...
I always thought it was strange that mutable pairs can’t be
chaperoned, but boxes and vectors of length 2 can. Moreover, there was
(is?) a plan to replace the implementation of mcons with structs. Does
#:authentic make this more consistent / efficient?
Also, what would happen
I cannot turn this one into a problem with Typed Racket though. th must have
type Thread and the -> Any of thread-receive requires a cast already, which
covers our ‘soundness’ behind.
> On May 12, 2017, at 11:38 AM, Robby Findler
> wrote:
>
> Yeah, that's a real one. :)
>
> Robby
>
> O
> On May 12, 2017, at 11:30 AM, Robby Findler
> wrote:
>
> Yes, I agree with this analysis of Scott's very cool program. I also
> think that this means that maybe we should not be using the phrase
> "channel of communication" (or, perhaps, we should treat it as an
> abbreviation of some longer
Yes, in my thinking this is about the relationship between “complete
monitoring” and “capability safety,” but I will have to think longer before I
can put my finger on exactly why it matters…
As far as complete monitoring goes, I think the justification for dropping
boundaries around flat value
Yeah, that's a real one. :)
Robby
On Fri, May 12, 2017 at 10:30 AM, Scott Moore wrote:
> Reading a bit further in the docs, there is a bigger hole:
>
> (define (component-1 value channel)
> (thread-send channel value))
>
> (define-values (component-2 channel)
> (let ()
> (define main (cu
Reading a bit further in the docs, there is a bigger hole:
(define (component-1 value channel)
(thread-send channel value))
(define-values (component-2 channel)
(let ()
(define main (current-thread))
(define th
(thread (lambda () (thread-send main (thread-receive)
(value
Yes, I agree with this analysis of Scott's very cool program. I also
think that this means that maybe we should not be using the phrase
"channel of communication" (or, perhaps, we should treat it as an
abbreviation of some longer phrase and we need to work out what it is
exactly). I think Scott's o
Here's an implementation to try:
https://github.com/racket/racket/pull/1689
So far, I like "authentic" better than the alternatives, so the PR uses
that term.
If you try something like
(struct posn (x y))
(time
(let ([p (posn 1 -1)])
(for/fold ([n 0]) ([i (in-range 1)])
What your (cool little) program demonstrates is that *information* can flow
from one thread to another, not *data*. You need to convince me that data flows
and then we need to figure out how to protect/monitor this data. And at that
point, you can possibly see lambdas flow too.
> On May 12,
I think the interesting distinction is that threads, regexps, ports, etc, are
communication channels, but not for higher-order values.
On May 12, 2017, 10:58 AM -0400, Scott Moore , wrote:
> (define (component-1 value)
> (define t
> (thread (lambda ()
> (thread-suspend t)
>
(define (component-1 value)
(define t
(thread (lambda ()
(thread-suspend t)
(for ([i (in-range value)])
(thread-suspend t)
t)
(define (component-2 thread)
(thread-resume thread)
(let* ([suspend-evt (thread-suspend-evt thread)]
[d
I would say that the event value is the channel of communication. But,
if this expression:
(sync (thread (lambda () 3)))
returned 3, then I'd say that thread itself is a channel of
communication. But threads give themselves back to sync, not the
values that their thunks return.
Robby
On Fri,
I tend to agree though there is some information flowing from a thread to its
context (thread CML events). I have to think whether this is a channel of
communication.
> On May 12, 2017, at 8:57 AM, Robby Findler
> wrote:
>
> This perspective suggests a gap in the design in some sense, I
#:non-chaperoned #:adult :(
> On May 12, 2017, at 9:16 AM, Matthew Flatt wrote:
>
> At Thu, 11 May 2017 18:38:00 -0400, Matthias Felleisen wrote:
>> If the name isn’t fixed, #:no-proxy-allowed would be my preference.
>
> We haven't been using the word "proxy" in this context, but I can see
At Thu, 11 May 2017 18:38:00 -0400, Matthias Felleisen wrote:
> If the name isn’t fixed, #:no-proxy-allowed would be my preference.
We haven't been using the word "proxy" in this context, but I can see
why you'd want something that more clearly connects to
"impersonator"/"chaperone" terminology.
This perspective suggests a gap in the design in some sense, I would
say. The PL construct cannot, on its own, guarantee that the values
from #:authentic structs end up behaving like those kinds of values.
(also: threads and regexps don't seem problematic from the contract
perspective, but ports d
I think a better analogy is to values like #, #, or
#. Although those kinds of values are implemented with structs,
the accessor and mutator functions are not exported (and, as Scott
says, there's no way to get the accessors and mutations by reflection),
so there's no way to impersonate the values.
Oh right.
> On May 11, 2017, at 6:54 PM, Robby Findler
> wrote:
>
> They would be the same. We currently cannot chaperone or impersonate cons
> cells. We copy them.
>
> Robby
>
> On Thu, May 11, 2017 at 5:51 PM Matthias Felleisen
> wrote:
>
> Yes except that you can contract cons cell
They would be the same. We currently cannot chaperone or impersonate cons
cells. We copy them.
Robby
On Thu, May 11, 2017 at 5:51 PM Matthias Felleisen
wrote:
>
> Yes except that you can contract cons cells. So why couldn’t you contract
> authentic structs then?
>
>
>
> > On May 11, 2017, at 6:
Yes except that you can contract cons cells. So why couldn’t you contract
authentic structs then?
> On May 11, 2017, at 6:41 PM, Robby Findler
> wrote:
>
> Indeed: if we did that, then these structs would be much like cons
> cells currently are.
>
> Robby
>
>
> On Thu, May 11, 2017 at 5
Indeed: if we did that, then these structs would be much like cons
cells currently are.
Robby
On Thu, May 11, 2017 at 5:39 PM, Robby Findler
wrote:
> What if #:authentic (or whatever) were only allowed on immutable
> objects and we allowed them to be copied? Then contracts could protect
> them.
What if #:authentic (or whatever) were only allowed on immutable
objects and we allowed them to be copied? Then contracts could protect
them.
Robby
On Thu, May 11, 2017 at 5:38 PM, Matthias Felleisen
wrote:
>
> @ Christos
>
> #:authentic explicitly introduces a channel of communication that it
@ Christos
#:authentic explicitly introduces a channel of communication that it is not
protectable by contracts. This makes Racket’s contract system explicitly
incomplete. It might have been incomplete in the past for other reasons.
If the name isn’t fixed, #:no-proxy-allowed would be my pref
> I agree that generally don't want performance declarations that
> interfere with reasonable interposition. The good uses of `#:authentic`
> would be in places where the struct representation of a value is not
> exposed or where the values themselves are not exposed (so any
> interposition means
It's not a level-of-abstraction difference. A predicate use
(s? o)
is compiled as
(or (authentic-s? o) (and (impersonator? o)
(authentic-s? (impersonator-original o
where `authentic-s?` and `impersonator?` are a type-tag tests. I agree
that the extra `impersonat
Out of curiosity, where does the additional overhead come from? Without looking
at the struct predicate code, I would have expected this to be a
relatively-well predicted branch on the Scheme_Type of the object. I haven’t
been following the Chez port though—are impersonators being implemented at
Using `struct/c` or `struct/dc` would work only with flat contracts for
the fields.
At Thu, 11 May 2017 16:11:59 +, Jay McCarthy wrote:
> This means that trying to contract them will fail or that it will default
> back to just protecting the underlying functions?
>
> Jay
>
> On Thu, May 11,
This means that trying to contract them will fail or that it will default
back to just protecting the underlying functions?
Jay
On Thu, May 11, 2017 at 11:16 AM Matthew Flatt wrote:
> There are many structure types that are private to some library (such
> as the expander) and will never have im
There are many structure types that are private to some library (such
as the expander) and will never have impersonators. The compiler can't
know that, though, and the possibility of an impersonator means that
the structure type's predicate has to be twice as expensive. Field
selection is also more
39 matches
Mail list logo
