Add Async SIP #213
Add Async SIP #213
Conversation
|
Welcome to the new edition of the SIP process. I'm going to be your reviewer. This means that I'll be the contact person between you and the SIP committee, presenting your progress and providing you with our feedback. During the SIP meeting on 13 Jul 2016, the committee has discussed your proposal. We think that async/await is a great thing to have in the Scala ecosystem, and that the quality of your implementation is very impressive! Given our earlier in-person chat, we also considered your request to postpone this SIP to give you more time to work on the implementation of awaits in try/catch blocks. We agreed that this is a good idea and decided to officially postpone your SIP. According to the new rules (http://docs.scala-lang.org/sips/sip-submission.html), postponement means that we set aside the SIP under some conditions. When those conditions are met, the SIP can be resubmitted. As a result, we're closing your SIP now, and here's the list of our requests for this SIP to be resubmitted again:
Looking forward to hearing from you again! |
|
Hi! First of all, I'm new to SIP-s internals and I've never hacked scalac myself, so feel free to correct me if I'm making some mistakes or missing something. Now on topic. Is there any discussion/argumentation on why to change matters at all? Deciding between scala/async being a separate library and being included in stdlib, here are some concerns:
|
|
@vn971 thanks for your feedback. The proposal is not to include
|
|
@retronym thank you for your time. What is this SIP, then? AFAIunderstood, SIP should be a "Scala improvement process" for the language. So if it's just a library, why call it SIP? What am I missing here? |
|
I echo @vn971's concerns, I do think that a more generic solution would be of great benefit to the Scala ecosystem and should be considered as a built-in language feature. The transformation could be used as syntactic sugar to deal with any monad-like interface similarly to for-comprehensions, translating the code to a normal monad composition without a state machine. See effectful as an example, it generalizes the transformation for any Scalaz monad. Just as an example, this is a prototype of what I have in mind: Library interface trait Transformer[M[_]] {
def value[T](v: T): M[T]
/* Other methods like `handle` and `recover`
* would be necessary to desugar some
* language constructs */
def lift[T](body: T): M[T] = macro Macro.lift[M, T]
@compileTimeOnly("`unlift` must be used within `lift`")
def unlift[T](m: M[T]): T = ???
}Usage for val t = new Transformer[Future] {
def value[T](v: T) = Future.successful(v)
}
import t._
val f1: Future[Boolean] = ???
val f2: Future[Int] = ???
val a: Future[Int] = lift {
val b = unlift(f1)
if (b) unlift(f2) else 11
}
val a: Future[Int] =
f1.flatMap { b =>
if(b) f2
else t.value(11)
}Notes:
|
Back in 2013, SLIPs hadn't been split off from SIPs yet. If or when this proposal progresses any further, it will be as a SLIP. |
Adds first version of the Async SIP.