Is memory management in Sodium/Typescript really automatic?

[cubuspl42]

The announcement from README says:

It features a newly developed scheme for memory management, which was needed
because Javascript has no finalizers. Memory management in Sodium is 100%
automatic.

This scheme imposes one small requirement on the API: You must declare any Sodium
objects held inside closures using wrapper functions lambda1, lambda2 ..
lambda6 - depending on the number of arguments that the closure has.
These take a second argument, which is a list of the Sodium objects contained
in the context of the closure. For example: [...]

I'm sceptical about the "one small requirement" part. Counter-test:

test('should test hold + mapC', (done) => {
  const s = new StreamSink<number>();
  const c = s.hold(0);
  const out: number[] = [];

  // const kill1 = c.listen(() => {}); // fix

  s.send(1);

  const c2 = c.map((x) => x * 3);

  const kill2 = c2.listen(a => {
    out.push(a);
    if (out.length === 1) {
      done();
    }
  });

  // kill1(); // fix
  kill2();

  expect(out).toEqual([3]); // actual: [0]
});

This test fails. I commented two lines that make the test pass. I understand why, I know Sodium implementation details well enough. But there was no closure that I could attach c to so it's kept alive.

Is the only way to have this system working is to manually manage a "fake" listener on c? Or is this situation considered "wrong" use of Sodium? In my (limited) experience, cases like this happen in practice and I don't consider them non-pure FRP, or anything like that.

[clinuxrulz]

I'll explain what should be happening under the hood:

c2 should be kept alive by the listener.
c should be kept alive by c2 (the map method, and because c2 is alive)
and s should be kept alive by c (the hold method, and because c is alive)

Is this test failing on the current released version of sodium?

---

OK I Understand: It is because s fires a value in a transaction where the c is not alive yet. Calling the send after the listen resolves the issue. And it just is the way it needs to happen in typescript unfortunately.

test('should test hold + mapC', (done) => {
  const s = new StreamSink<number>();
  const c = s.hold(0);
  const out: number[] = [];

  const c2 = c.map((x) => x * 3);

  const kill2 = c2.listen(a => {
    out.push(a);
    if (out.length === 1) {
      done();
    }
  });

  s.send(1);

  kill2();

  expect(out).toEqual([0, 3]);
});

In practice I believe most sends are triggered by event listeners well after the FRP graph has already been set up.

[cubuspl42]

I'll explain what should be happening under the hood [...]

I believe that what happens is what "should" be happening by the specification.

In practice I believe most sends are triggered by event listeners well after the FRP graph has already been set up.

It really depends. Let's suppose you build a mobile app or a multi-screen web app. You build a model, a core component that holds the data managed by the application, which is presented in multiple ways on multiple screens/routes. Sometimes it's called "business model", although I'm not a fan of that term. Of course, the right technique to wire up this model is to use FRP.

If the first route/screen doesn't present a certain hold cell from the model, then the second screen will find that cell in the glitched state (some updates might be missed).

I guess that if the whole world was build in FRP, including the UI framework, then you'd always have some lambda that you could attach cells that need to be kept-alive to. So maybe the readme is "correct" in that sense; I'm still not sure if it's actually trivial to find these cells if functions you use to build your FRP subgraphs are non-trivial, but that's a different concern.

[clinuxrulz]

Very true regarding the UI.

Its really a limit for javascript/typescript version due to lack of weak reference, and no implicit RAII. The other language versions do not have this problem.

Something to try through. I remember Cell(s) are temporary brought to life when initially constructed for the current transaction. It means the original test might actually pass if it is all wrapped up in a transaction. (untested)

[cubuspl42]

That's interesting. Actually my fork is currently having sample-before-listen issues. I was tempted to incRefCount / decRefCount inside sample. I never noticed that Sodium does something like that in master.