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.
