<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 27.09.2017 um 16:37 schrieb Marc Schlichte via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Security-Policy" content="script-src 'self'; img-src * cid: data:;" class=""><div style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;" class=""><div id="response_container_BBPPID" style="outline:none;font-size:initial;font-family:"Calibri","Slate Pro",sans-serif,"sans-serif"" dir="auto" contenteditable="false" class=""> <div name="BB10" dir="auto" style="width: 100%; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class="">I also think that actors and signals have to be designed together:</div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class=""><br class=""></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class="">E.g. how would you subscribe in your actor to a signal defined in another actor so that it is thread safe.</div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class=""><br class=""></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width: 100%; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class="">I could imagine that the signals used in actors are actors themselves ( maybe sharing the execution context of their containing actor if this is deemed to be inefficient - which should not be the case) </div></div></div></div></blockquote><div><br class=""></div><div>How actor based signals might work can be seen in my simple actor playground: <a href="https://github.com/frameworklabs/actress" class="">https://github.com/frameworklabs/actress</a></div><div><br class=""></div><div>With future syntax support, this might look like:</div><div><br class=""></div><div>```</div><div>actor class Sender {</div><div> let signal = Signal<Int>()</div><div><br class=""></div><div> actor func start() {</div><div> signal.emit(21)</div><div> }</div><div>}</div><div><br class=""></div><div>actor class Receiver {</div><div> init(sender: Sender) {</div><div> let conn1 = await sender.map { $0 * 2 }.connect(actor: self, method: Receiver.receive)</div><div> disposeBag.add(conn1)</div><div><br class=""></div><div> // or with `actor closures`:</div><div> let conn2 = await sender.map { $0 * 2 }.connect(actor: self) { [unowned self] value in</div><div> print("me \(self) got \(value)“)</div><div> }</div><div> disposeBag.add(conn2)</div><div> }</div><div><br class=""></div><div> actor func receive(_ value: Int) {</div><div> print("me \(self) got \(value)“)</div><div> }</div><div>}</div><div><br class=""></div><div>```</div><br class=""><blockquote type="cite" class=""><div class=""><div style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;" class=""><div id="response_container_BBPPID" style="outline:none;font-size:initial;font-family:"Calibri","Slate Pro",sans-serif,"sans-serif"" dir="auto" contenteditable="false" class=""> <div name="BB10" dir="auto" style="width: 100%; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class=""> <br style="display:initial" class=""></div> <div id="blackberry_signature_BBPPID" name="BB10" dir="auto" class=""> <div name="BB10" dir="auto" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class="">Cheers<br class="">Marc</div> </div></div><div id="_original_msg_header_BBPPID" dir="auto" class=""> <table width="100%" style="background-color: white; border-spacing: 0px; display: table; outline: none;" contenteditable="false" class=""> <tbody class=""><tr class=""><td colspan="2" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class=""> <div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in; font-family: Tahoma, "BB Alpha Sans", "Slate Pro"; font-size: 10pt;" class=""> <div id="from" class=""><b class="">Von:</b> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></div><div id="sent" class=""><b class="">Gesendet:</b> 26. September 2017 9:04 vorm.</div><div id="to" class=""><b class="">An:</b> <a href="mailto:mattxg@gmail.com" class="">mattxg@gmail.com</a>; <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></div><div id="reply_to" class=""><b class="">Antworten:</b> <a href="mailto:howard.lovatt@gmail.com" class="">howard.lovatt@gmail.com</a></div><div id="subject" class=""><b class="">Betreff:</b> Re: [swift-evolution] Standard ReactiveSteam definitions for Swift</div></div></td></tr></tbody></table><div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(186, 188, 209); display: block; padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);" class=""></div> <br class=""> </div><!--start of _originalContent --><div name="BB10" dir="auto" style="background-image: initial; line-height: initial; outline: none;" contenteditable="false" class=""><div class=""><div dir="auto" class="">Comments in-line below. </div><div dir="auto" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="auto" class="">On Sun, 24 Sep 2017 at 12:36 pm, Matt Gallagher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">Some thoughts as a programmer who has written an atypical reactive programming library...<br class="">
<br class="">
You're providing protocols that strongly imply ReactiveX semantics.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">ReactiveX can be built upon Reactive Streams, e.g. RxJava 2.0., but the idea of Reactive Streams is that the protocol is so low level you don’t interact directly with them. They seem compatible with many different styles including actors, e.g. Akka (the Akka people destined Reactive Streams I think). Reactive Streams are very actor like with one way communication links that transfer a copy of single items/errors or no items/error (pure messages). </div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
Some libraries (like my own CwlSignal) look a little like ReactiveX (in that CwlSignal implements all of the ReactiveX operators) but have some quite different semantics during graph construction and during other lifecycle events. For example, CwlSignal doesn't have public Subscriber concept (responsibilities are split between the private `SignalHandler` and the `SignalSender` interface) and while the core `Signal` class is a Publisher-like concept, it is single-use which would make it a very weird implementation of this `Publisher` protocol.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Nothing in the Reactive Stream specification to prevent single use Publishers, Subscribers, or Processors. The Reactive Stream specification only talks about the communication and error reporting. As long as your library has the concept of a subscription of some form you can probably write translators to the 3 protocols. </div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
These differences can make protocols for interoperability a bit of a loaded shotgun. Joining two arbitrary libraries together is likely to cause problems when the libraries have different expectations.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Seems to work OK in the Java world, people use Akka and RxJava together. </div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
In some respects, it would be better to have a single, standard, concrete implementation of a class that takes an event stream input and emits an event stream. This is sometimes called a PublishSubject. A generalized PublishSubject could act as the glue between different libraries on the input and output sides. That way, the semantics of the interoperability point are fixed and each library need only ensure they support the interoperability point, rather than the semantics of every other library that could be on the other side of a protocol.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">This is what Reactive Streams are. They just tell you how to hook things up, how to ask for items, how to report errors, and how to finish with a connection. They do not dictate the semantics at the other end. For example your translator could throw fatal exception on an error if your library didn’t report errors or wrap the error in a Result type if it handled error in a functional way. </div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
To me, I feel like this would best be implemented as part of Actor model concurrency – taking inputs and emitting outputs is fundamentally what Actors *do*.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">As I have said they are very actor like and I think it was the Akka people who came up with the specification therefore I am not sure you are locking anything out. If the Swift actor model can’t interact with something as simple as Reactive Streams it will not interact with anything other than other Swift Actors, which would be very limiting. For example you would expect the Swift actors to interact with GCD, perhaps via suitable wrappers. </div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
As for naming... I would *not* recommend using `Flow` it is far too generic, has been used in very different contexts and doesn't match terminology in the field. It's fine for a library to break with common terminology for its own purposes but an interoperability interface must use the established terminology. `Publisher` and `Subscriber` are fairly clear in context but can mean very different things *outside* of reactive programming. `Observable` and `Observer` are clearer but again, the `Observer` pattern in general programming is not the same as a reactive programming `Observer` so putting it in the Swift standard library would annoy some people. On an aesthetic note, I've always found `Observer` and `Observable` difficult to read – they are similar enough that I confuse inputs and outputs when I'm tired. This is one of the reasons these terms do not appear in my library.<br class="">
<br class="">
My personal vote is that this topic simply can't be addressed by the standard library at this point. This is something where interoperability with Swift's Actor Model should be a primary concern and until it's done, any action now is only likely to be a headache later.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I would prefer to move forward more quickly, I don’t think there is much risk since the specification is so low level and flexible. The whitpaper from Chris Lattner also mentions that it would be desirable for any Actor system in Swift to be compatible with Reactive Streams, so why not start now. </div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
<br class="">
Cheers,<br class="">
Matt Gallagher.<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></div><div dir="ltr" class="">-- <br class=""></div><div class="gmail_signature">-- Howard.</div>
<!--end of _originalContent --></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>