> On May 12, 2017, at 11:30 AM, Robby Findler <[email protected]> > 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 > <[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/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 [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/B8AF52CD-CC04-4A85-9ED3-625713BF2D43%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
