Thanks for the info, lots of reading to do now. I ran across transactional events, and also "Isolates: Serializability Enforcement for Concurrent ML" (https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=2730&context=cstech) which looks like it may extend transactional events.
On Tuesday, March 16, 2021 at 10:03:48 PM UTC-4 Sam Tobin-Hochstadt wrote: > Reagents are a generalization of core CML, but Racket extends the basics > of CML considerably. I think there's definitely implementation complexity > in reagents that would need to be added to support conjunction, but I don't > know how much. > > Looking back at Aaron's thesis, I see several other systems with forms of > conjunction that are relevant here. First, join patterns, which reagents > are based on, also include conjunction. Second, transactional events > (Donnelly and Fluent) are in some sense exactly what's requested here, the > andThen combinator mentioned here is what I think you originally requested: > http://www.cs.cornell.edu/people/fluet/research/tx-events/ > > Sam > > On Tue, Mar 16, 2021, 9:48 PM Greg Rosenblatt <[email protected]> wrote: > >> Thanks for the help, everyone. >> >> Sam, it looks like you've worked with Aaron a bit on reagents in >> https://github.com/aturon/Caper. Is there anything CML can express that >> reagents have trouble with? How does the implementation complexity compare? >> >> On Monday, March 15, 2021 at 8:12:03 PM UTC-4 Sam Tobin-Hochstadt wrote: >> >>> I think Aaron Turon's reagents (and more generally k-cas) are an example >>> of N-way rendezvous. >>> >>> Sam >>> >>> On Mon, Mar 15, 2021, 5:50 PM Matthew Flatt <[email protected]> wrote: >>> >>>> At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote: >>>> > Is there a corresponding event for a logical conjunction (I was >>>> looking for >>>> > something like `all-evt` or `every-evt`), which requires that all of >>>> its >>>> > members be ready for synchronization at the same time? >>>> >>>> No. (Although `replavce-evt` is a weak kind of "and", it's not what >>>> you're looking for.) >>>> >>>> > If not, is there a fundamental barrier to its implementation with the >>>> > ConcurrentML approach? >>>> >>>> Yes, at least in the sense that it's not possible to implement N-way >>>> rendezvous given only CML's rendezvous. >>>> >>>> So, N-way rendezvous would have to be implemented in the core. I'm >>>> certain that some languages have implemented that, but I have forgotten >>>> the examples. >>>> >>>> > Related to this, I've been reading "Kill-Safe Synchronization >>>> Abstractions" >>>> > (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found >>>> it >>>> > notable that the swap channel couldn't be implemented in a way that >>>> was >>>> > both kill-safe and break-safe (not ruining `sync/enable-break`'s >>>> > exclusive-or guarantee). I'm wondering if both forms of safety could >>>> be >>>> > achieved by using a hypothetical `all-evt` that behaves as I've >>>> described. >>>> >>>> Probably so. The citation of [17] in that part of the paper is meant to >>>> allude to the CML-style rendezvous versus N-way rendezvous constraint. >>>> >>>> >>>> Matthew >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Racket Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com >> >> <https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/01365d33-66e7-4630-aed7-aedc66ad87f5n%40googlegroups.com.
