Active Expressions seem to essentially be a more seamless and implicit form of Reactive Streams, such as those from the ReactiveX family of libraries [1]. For instance, the first example given by the paper is:

    var a = 5, b = 6;
    signal c = a + b; // c = 11
    
    a = 10; // c = 16

We can express the same with reactive streams, although it's more clumsy because of the explicit stream objects and subscriptions. Here is an example using RxJava:

    var a = BehaviorSubject.createDefault(5);
    var b = BehaviorSubject.createDefault(6);
    var c = Observable.combineLatest(a, b, (x, y) -> x + y);

    // Read the last value emitted by stream `c`
    System.out.println(c.blockingFirst()); // 11
    
    // Save and emit 10 from stream `a`
    a.onNext(10);

    System.out.println(c.blockingFirst()); // 16

This is, of course, way more verbose than the signal concept displayed in the paper, so I welcome the approach to make this reactive power more accessible. However, note that reactive streams offer a lot of control over value propagation - such as delaying, throttling or filtering changes - that will probably be hard to replicate with a system like the one presented here.

Also, when combined with shared-state concurrency, it might be hard to define and reason about which active expression runs in which thread. Reactive stream implementations have already tackled this issue with concepts such as schedulers [2].

[1]: http://reactivex.io [2]: http://reactivex.io/RxJava/2.x/javadoc/