> On May 12, 2017, at 11:30 AM, Robby Findler <ro...@eecs.northwestern.edu> > 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 phrase and we need to work out what it is > exactly
We did. See Christos’s 2012 ESOP paper: http://www.ccs.neu.edu/racket/pubs/#esop12-dthf > ). I think Scott's on to something with the interesting > distinction comment. If I am communicating only flat values around, > then I have to run an interpreter to evaluate some arbitrary unknown > program; it doesn't run directly. That seems like an important > distinction somehow, even if it isn't a very crisp one. > > Robby > > On Fri, May 12, 2017 at 10:06 AM, 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/CAL3TdOP7TE7o7jPxy64ZP0weOEjnzbsiz3_KMDiS_rNt_Y0Lhw%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/B8AF52CD-CC04-4A85-9ED3-625713BF2D43%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
