r

    Rob

    1 year ago
    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

    Fudge

    1 year ago
    Coroutine context is not so dynamically scoped if you consider that
    suspend
    can be thought of as
    context(CoroutineContext)
    currentComposer
    is also not dynamically scoped because
    @Composable
    can be thought of as
    context(Composer)
    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){}
    r

    Rob

    1 year ago
    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.
    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]

    Chuck Jazdzewski [G]

    1 year ago
    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.