We have proxies for channels, but not for threads. On Fri, May 12, 2017, 1:25 PM Matthias Felleisen <matth...@ccs.neu.edu> wrote:
> > Ouch. (I should have thought of this.) > > So we need proxies for channels. > > > > > > On May 12, 2017, at 1:21 PM, Scott Moore <sc...@thinkmoore.net> wrote: > > > > Can confirm. ;) > > > > On May 12, 2017, 1:13 PM -0400, Sam Tobin-Hochstadt < > sa...@cs.indiana.edu>, 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 <matth...@ccs.neu.edu> > 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 < > ro...@eecs.northwestern.edu> wrote: > >> > > >> > Yeah, that's a real one. :) > >> > > >> > Robby > >> > > >> > On Fri, May 12, 2017 at 10:30 AM, Scott Moore <sc...@thinkmoore.net> > 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 < > matth...@ccs.neu.edu>, > >> >> 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 <sc...@thinkmoore.net> > 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 < > sdmo...@fas.harvard.edu>, > >> >> 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 > >> >> <ro...@eecs.northwestern.edu>, 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 > >> >> <matth...@ccs.neu.edu> 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 < > ro...@eecs.northwestern.edu> > >> >> 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 <mfl...@cs.utah.edu> > 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 < > ro...@eecs.northwestern.edu > >> >> > >> >> 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 < > matth...@ccs.neu.edu > >> >> > >> >> 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 < > ro...@eecs.northwestern.edu > >> >> > >> >> 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 > >> >> <ro...@eecs.northwestern.edu> 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 > >> >> <matth...@ccs.neu.edu> 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 <sdmo...@fas.harvard.edu > >> >> > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> To post to this group, send email to racket-dev@googlegroups.com. > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> To post to this group, send email to racket-dev@googlegroups.com. > >> 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 racket-dev+unsubscr...@googlegroups.com. > > To post to this group, send email to racket-dev@googlegroups.com. > > 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 racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAK%3DHD%2BanstiWXWv3EeymRaeRVpeOOowT0FA%2B2i%2Bx%2BiNj%3D4%2Ba2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
