It seems to me that Coroutine Context and Compose ...

# compose

[Rob]

It seems to me that Coroutine Context and Compose Local are just dynamically scoped variables. Is there any possibility that Jetbrains will implement dynamically scoped variables to unify these bespoke implementations?

[Fudge]

Coroutine context is not so dynamically scoped if you consider that suspend can be thought of as context(CoroutineContext)

[Fudge]

See https://www.github.com/Kotlin/KEEP/tree/context-receivers/proposals%2Fcontext-receivers.md

[Fudge]

currentComposer is also not dynamically scoped because @Composable can be thought of as context(Composer)

[Fudge]

Now I agree that the way CompositionLocals work now is dynamic, but honestly it is suboptimal! The same feature can be implemented in the language in a static way, if only we could combine contexts, something like this

typealias AndroidContext = @Composable context(Context,View,...)
// Then setContent is defined like this:
fun setContent(content: context(AndroidContext) () -> Unit)

// And libraries can add more stuff to the context...
typealias MaterialContext = context(AndroidContext, MaterialTheme)

context(AndroidContext)
fun MaterialTheme(body: context(MaterialContext) () -> Unit)

// And users can add more stuff to the context...
typealias MyContext = context(MaterialContext,MyDatabase)
context(MaterialContext) fun MyComponent(stuff: context(MyContext) () -> Unit){}

[Rob]

Context receivers can be used to implement dynamic scope. I'm not sure how I feel about it but it might look something like this.

Untitled.kt

[Rob]

Also, to be clear, what I mean by "dynamic scope" is not that it is dynamically typed. Dynamic scope has been in languages like LISP and is a very old concept. The variable's value is defined not by it's lexical scope but by the scope of where the method is invoked. This does a better job of explaining than I can. https://prl.ccs.neu.edu/blog/2019/09/05/lexical-and-dynamic-scope/

[Chuck Jazdzewski [G]]

We are tracking multi-receiver proposal closely and we were involved in some of the early drafts of this proposal. It is my hope that this feature will give us a way to statically declare contextual dependencies that we don't have a good way to declare today.