Ouch. (I should have thought of this.) 

So we need proxies for channels. 




> On May 12, 2017, at 1:21 PM, Scott Moore <[email protected]> wrote:
> 
> Can confirm. ;)
> 
> On May 12, 2017, 1:13 PM -0400, Sam Tobin-Hochstadt <[email protected]>, 
> 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 <[email protected]> 
>> wrote:
>> 
>> 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 <[email protected]> 
>> > wrote:
>> >
>> > Yeah, that's a real one. :)
>> >
>> > Robby
>> >
>> > On Fri, May 12, 2017 at 10:30 AM, Scott Moore <[email protected]> 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 (current-thread))
>> >>    (define th
>> >>      (thread (lambda () (thread-send main (thread-receive)))))
>> >>    (values (lambda () (thread-receive)) th)))
>> >>
>> >>> (component-1 (lambda () "hello world") channel)
>> >>> ((component-2))
>> >> "hello world"
>> >>
>> >> On May 12, 2017, 11:05 AM -0400, Matthias Felleisen 
>> >> <[email protected]>,
>> >> wrote:
>> >>
>> >>
>> >> 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, 2017, at 11:02 AM, Scott Moore <[email protected]> wrote:
>> >>
>> >> 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 <[email protected]>,
>> >> wrote:
>> >>
>> >> (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)]
>> >> [dead-evt (thread-dead-evt thread)]
>> >> [result (sync suspend-evt dead-evt)])
>> >> (if (eq? result dead-evt)
>> >> 0
>> >> (add1 (component-2 thread)))))
>> >>
>> >> (define t (component-1 2))
>> >> (component-2 t)
>> >>
>> >> 2
>> >>
>> >> (define t (component-1 5))
>> >> (component-2 t)
>> >>
>> >> 5
>> >>
>> >> On May 12, 2017, 10:46 AM -0400, Robby Findler
>> >> <[email protected]>, wrote:
>> >>
>> >> 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, May 12, 2017 at 9:41 AM, Matthias Felleisen
>> >> <[email protected]> wrote:
>> >>
>> >>
>> >> 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 <[email protected]>
>> >> wrote:
>> >>
>> >> 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 do, since they are a communication channel and
>> >> the others aren't.)
>> >>
>> >> Robby
>> >>
>> >>
>> >> On Fri, May 12, 2017 at 7:52 AM, Matthew Flatt <[email protected]> wrote:
>> >>
>> >> I think a better analogy is to values like #<thread>, #<input-port>, or
>> >> #<regexp>. 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. In general, it's up to the
>> >> implementation of a new kind of value to supply impersonator/chaperone
>> >> support for those values, and implementations usually don't.
>> >>
>> >> At Thu, 11 May 2017 19:00:43 -0400, Matthias Felleisen wrote:
>> >>
>> >>
>> >> Oh right.
>> >>
>> >>
>> >> On May 11, 2017, at 6:54 PM, Robby Findler <[email protected]
>> >>
>> >> 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 <[email protected]
>> >>
>> >> wrote:
>> >>
>> >>
>> >> 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 <[email protected]
>> >>
>> >> 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:39 PM, Robby Findler
>> >> <[email protected]> wrote:
>> >>
>> >> 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
>> >> <[email protected]> wrote:
>> >>
>> >>
>> >> @ 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 preference.
>> >>
>> >> — Matthias
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On May 11, 2017, at 12:48 PM, Scott Moore <[email protected]
>> >>
>> >> wrote:
>> >>
>> >>
>> >> 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 being on the "inside" where you can change the
>> >> code, anyway).
>> >>
>> >>
>> >> Yes, I agree with this. I think as far as how this changes Racket’s
>> >>
>> >> data abstraction model, the key is “where the values themselves are not
>> >> exposed.”
>> >>
>> >> #:authentic only has an interesting effect in the other case, where
>> >>
>> >> “outside” code gets its hands on a value of the struct type. Previously, I
>> >> could write a program that used inspectors to impersonate this value
>> >> regardless of the “inside” code’s intent. Now that would no longer be
>> >> possible.
>> >>
>> >>
>> >> I doubt there is much code that currently relies on being able to do
>> >>
>> >> this and so I would say go ahead. (Perhaps DrRacket or other debugging
>> >> tools?)
>> >>
>> >>
>> >> On the other hand, Spencer already asked if this would be something the
>> >>
>> >> optimization coach would recommend. I think it would be important for the
>> >> documentation of #:authentic or the implementation of such a coach to 
>> >> stress
>> >> the importance of the rules of thumb you just laid out.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >>
>> >> Groups "Racket Developers" group.
>> >>
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >>
>> >> an email to [email protected].
>> >>
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/racket-dev/3c430798-e93a-4900-8215-198f77d9b9
>> >> 91%40Spark.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >>
>> >> Groups "Racket Developers" group.
>> >>
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >>
>> >> an email to [email protected].
>> >>
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/racket-dev/D688771A-C477-40D8-B209-D9506362C5
>> >> CB%40ccs.neu.edu.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >>
>> >> "Racket Developers" group.
>> >>
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >>
>> >> email to [email protected].
>> >>
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/racket-dev/1AFE0571-C48C-4B22-B445-D96B283C68
>> >> 85%40ccs.neu.edu.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Racket Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to [email protected].
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/racket-dev/77B4F4BC-74B9-4838-AFC1-B65BCF8BE6
>> >> 95%40ccs.neu.edu.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Racket Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to [email protected].
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/racket-dev/5915b006.5639620a.b51d4.83dcSMTPIN_ADDED_MISSING%40gmr-mx.google.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Racket Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to [email protected].
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/racket-dev/CAL3TdOPTT8-8CuJt86VE-_z%3DnZ%2B-Hxf92HyNW%3DvUtiVy9-5yAg%40mail.gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Racket Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to [email protected].
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/racket-dev/752ED434-8FB1-4F9A-89C2-153070098FF8%40ccs.neu.edu.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Racket Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to [email protected].
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/racket-dev/CAL3TdOOm1sH2GxLqn1ZtG49XUwSa_A2Pvo2Wp09Uzuw-zzL1zw%40mail.gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Racket Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to [email protected].
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/racket-dev/575116A1-A4C1-4548-92B0-C06008276A6F%40ccs.neu.edu.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Racket Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>> >> email to [email protected].
>> >> To post to this group, send email to [email protected].
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/d/msgid/racket-dev/b3e1d2fb-c559-4015-80b4-d15a016edeb4%40Spark.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-dev/C8683D03-E19C-414E-9710-C79D350452F4%40ccs.neu.edu.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-dev/b7b5d049-87ed-438c-b825-4269f157adda%40Spark.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-dev/123D1EF2-29E0-4E9F-88EA-88868BBE9467%40ccs.neu.edu.
For more options, visit https://groups.google.com/d/optout.

Reply via email to