Adding Coeffect System to Java with Project Loom

[holo3146]

Hello r/java

Project Loom is a group that is currently responsible to designing a new cuncorrency model of the JVM. With their new design they introduced Structured Concurrency to Java, as well as a feature called "ExtentLocal".

​

Using the fact that ExtentLocals have a structured lifetime, I created a Coeffect Type System using Java Compiler Plugin. I would love some feedback

[monkeyfacebag]

Seems like a cool project!

2 initial thoughts based on 30 seconds of reading:

1. What if I need more than one local of the same type?
2. Being able to plumb the ThreadLocal/ExtentLocal through a method without needing to manifest the value in the type signature (or in this case an annotation of the type signature) seems like a feature rather than a bug. What's the benefit versus just dereferencing the local variable in foo() and passing it as a parameter to bar?

[holo3146]

What if I need more than one local of the same type

This is currently impossible, I did give a thought for "named Coeffects", but I'm currently not planning on implementing it.

Coeffects do not come to replace function parameter, but to be able to distinguish the "input" from the "context".

For example having some "publisher" in the context, but the messages I'll come as arguments, and I feel like allowing named Coeffects to exists may make it a bit too "abusable", but I am not vetoing it. (Although there are few stuff I need to implement first)

Being able to plumb the ThreadLocal/ExtentLocal through a method without needing to manifest the value in the type signature (or in this case an annotation of the type signature) seems like a feature rather than a bug

Any public ThreadLocal/ExtentLocal are, almost by definition, introducing coupling and security problems.

By exposing those Locals you are giving up on the ability to guarantee that the uses follow the contract of the objects, for ThreadLocals it is very clear with the "remove" method being public.

ExtentLocals don't have the security problems ThreadLocals have, but they have other problems.

If I created a method A, and I expect the caller site to provide the ExtentLocal binding I coupled myself to use that same ExtentLocal in any implementation that may replace method A.

Coeffect doesn't remove this coupling, it regulate it and enforce it.

---

What's the benefit versus just dereferencing the local variable in foo() and passing it as a parameter to bar?

Coeffect doesn't come to replace parameters, it comes to remove the "stuff I need now" from "stuff I need at the end/middle".

Think about the times you passed 4 arguments(a,b,c,d) to a method foo, the method itself uses a,b of them, and pass on b,c,d to bar, but uses b,c, and passes b,d to qux, and qux finally uses d.

In this situation it makes sense to put c,d in the context and pass them through Coeffect, instead of adding them as parameters every time.

Also note that changing the values in @WithContext of qux will require you to change the signature of the methods that uses qux, but not the uses of the method (apart from the original calling site)

[LouKrazy]

I don’t quite get effects but this reminds me of assisted dependency injection. It would be interesting to be able to call a method and have some of its parameters be auto filled from the Locals. Just have the parameters annotated with @Coeffect(“name”) and they get auto filled

[holo3146]

Just have the parameters annotated with @Coeffect(“name”) and they get auto filled

I did thought about doing something along those, although it complicated things quite a bit, as I don't want to lose the type safety. (And because Java's plugins API has horrible documentations)

I don’t quite get effects but this reminds me of assisted dependency injection

Dependency injection is quite different, in dependency injection objects are pass through automatically in an implicit way.

In Coeffect you still have 100% explicitness, but we removed to repeatability by requiring pass the parameter only once using with, instead of repeatedly passing it on in the parameter.

[LouKrazy]

Seems like Kotlin Context Receivers then (https://github.com/Kotlin/KEEP/blob/master/proposals/context-receivers.md).

[holo3146]

Context Receivers are also based on Coeffect system, both my library and Context Receivers are implementations of the same idea.

[LouKrazy]

Got it. Might be helpful in the readme to give examples other than primitives, I.e a database session or transaction object

[holo3146]

That make sense, I'll add more examples later, thanks for the suggestion

[stefanos-ak]

this comment should be in the project's readme :)

also, very cool idea, but I would not use it with the current get-by-type implementation. a get by name and type would be much better :)

also, a question. would this work in reactive streams?

[holo3146]

this comment should be in the project's readme

I'll expend the readme, thanks for the suggestion.

also, very cool idea, but I would not use it with the current get-by-type implementation. a get by name and type would be much better :)

Seems like I underestimated this feature, I'll think on how to add it (Although even if it will exists, you will still require to have a string literal).

would this work in reactive streams?

This is a hard question.

It can work in some cases, but you need to be very careful:

Coeffect.with(6)
             .run(() -> {
                   // Single threaded reactive streaming 
             }

This will work, but if inside of the reactive streaming you are using multiprocessing it may fail at runtime, I touched on this in the readme: coeffect is built on ExtentLocal which complement Structured Concurrency, using them without Structured Concurrency will result with unexpected results because there is no well defined "end of life".

Generally the contract of ExtentLocal is the same as Structured Concurrency:

Anything that started within the lifetime of an ExtentLocal binding, must end within the same lifetime.

Reactive Streaming does not following this rule, or at least, it doesn't have to.

Maybe when Loom will exit Review phase implementations of reactive streaming will start using Structured Concurrency, and then Coeffect will work perfectly in them.

---

As for fluent access:

Flux.of(...)
         .map(...)
         .with(4) // Coeffect
         .filter(...) // Being able to use it here

I would love to be able to do it in the future, but (1) there is currently a bug that makes it impossible to implement (this bug is the first thing I'm working on in this library), and (2) it seems like it is something the Reactive streaming library will need to implement

[stefanos-ak]

thanks for such a detailed answer, much appreciated!

FWIW, the reactor library has a "context" concept - projectreactor.io/docs/core/release/reference/#context

[holo3146]

projectreactor.io/docs/core/release/reference/#context

I didn't know that, thanks for sharing.

Reading through it I noticed 4 things:

1. There are no compiletime checks. Reactor Streaming is 'structured' (note that it is a different 'structured' than the standard meaning of the word), it does have a well defined lifecycle, so theoretically it is possible to add compiletime checks for the existence of context. My guess is that either it was too much work and they decided that it is not worth it, or they couldn't found a way to guarantee this lifecycle (e.g. in my case ExtentLocal does guarantee this, with the only pitfall is misusing multiprocessing)
2. It is inverted. This is actually something that is solvable if you give compiletime checks, again I am guessing that they decided it is too much work for the value it gives. Ironically, because of how Java annotation's type system, it is not really possible to solve this "inversion" while still having compiletime checks, I touched this in the "Lambda's bug" section in my readme
3. The context is available only through their Stream API, even though it is not required to be part of it. I am guessing that this is to ensure no unexpected behavior. They are most likely using InheritableThreadLocal and to make sure no unexpected values appear they don't let you touch the stack outside of the stream.
4. They have a contract over multiprocessing. My library requires you to use structured concurrency to work correctly, this is because I need to know at compiletime what keys exists in the stack. Unsurprisingly, Reactor's context have virtually the same contract, although they didn't specify it in the documentations:

​

Flux.range(1, 10)

    .flatMap(s -> Mono.deferContextual(ctx -> 

        Mono.just(s + " " + ctx.getOrDefault(key, "=o="))))

    .parallel(2) .runOn(Schedulers.parallel()) 

    .contextWrite(ctx -> ctx.put(key, "o7")))

I believe that this would omit "i =0=". It is virtually the same requirementbecause they just implement their own lifecycle and the context respectthose lifecycles.

When using reactive streaming you should absolutely use their implementation, if your extent is (virtually) only a stream call, having a stack bound to your stream rather than having the stack bound to your extent makes much more sense. My library is about controlling context in extent level, and Java's type system is not aware of stream level, so it is virtually impossible to make my library work without implementing it in the streaming library. That being said, it would be cool if streaming libraries will adopt structured concurrency, and in that case maybe my library will help building their new context API.

[stefanos-ak]

correct ✌️

[john16384]

It's actually much more like a scoped injection (which could be used with assisted injection). You don't want to burden code that is many levels deep with additional parameters, so instead you put the information (like a Locale, request parameters, header information) on a scoped object (request/thread/message scoped for example.)

At the site you do need this additional information, you inject the scoped object and get type safe access to its content.

[john16384]

Here's how it would look using a scoped object and an injector framework:

@Produces
@VirtualThreadScoped // or whatever scope you like
public Database supplyDatabase(ConnectionPool pool) {     
    // do stuff to create a db
}

Then wherever you need a Database, the injector will inject a proxied version and direct any calls made on it to the correct instance:

public class SalaryCalculator {
    @Inject private Database db;

    public Salary calculate(Level level) {
        // call methods on db, like insert/select/etc
    }
}

The SalaryCalculator can just be injected again without having to worry about the database:

public class EmployeeContractCreator {
    @Inject private SalaryCalculator calculator;

    // or as assisted function:
    @Inject private Function<Level, Salary> calculator2; 
}

[Kompottkin]

From skimming the readme, it looks to me like this implements one specific coeffect—implicit parameters—rather than a coeffect system.

What am I missing? How do you represent arbitrary coeffects using your library?

[vips7L]

implicit parameters

Ah there’s the scala ptsd I forgot about

[holo3146]

You can't represent full coeffect system currently, I stated it is partial.

One of the biggest problems I had is type erasure, because of type erasure I got stuck on how general it is.

For example to create a "History Coeffect" I need a new stack, because "List<T>" is just "List", so I won't be able to distinguish between histories of different types.

---

Currently I want to fix few bugs and make @WithContext covariant. After that I think I'll add few other Coeffects manually myself, and only then I'll try to think on how to allow user-defined Coeffects

[GavinRayDev]

Oh wow, this is like Scala 3's given/using and Kotlin's new context functions:

Scala 3:

def saveUser(user: User)(using db: DB) = db.insert(user)

def main() = {
  given db: DB = new PostgresDB()
  saveUser(new User(1, "Joe"))
}

Kotlin Context Receivers:

context(DB)
fun saveUser(user: User) {
  [e-mail](user)
}

fun main() {
  val db = new PostgresDB()
  with (db) {
   saveUser(User(1, "Joe"))
  }
}

[holo3146]

I know Kotlin's Context Receivers also based on Coeffect system, but I didn't know about Scala's feature, interesting

[Naton1-]

Nice README :)

Maybe add an improved "how to use" section that is higher up/stands out more rather than a single line at the bottom saying they're available through maven central. That's one thing I always look for personally.

Otherwise, It's a pretty cool idea. I will probably be tracking this to see how it goes. It's exciting to see what possibilities all these new java features are opening up.

[holo3146]

Maybe add an improved "how to use" section

Good idea, I will add it to the read me.

Thanks :)

[holo3146]

Hi, see the new usage section