Simplify?

[lua-vr]

Sorry for almost rewriting the whole thing, but I was trying to fix a small issue in ema and started wondering why lvar could not use the same trick Chan/TChan does to implement the broadcasting instead of doing the ListenerId bookkeeping.

The idea is defining LVar as

data LVar a
  = LVar
      (TMVar a)
      -- ^ A value that changes over time.
      (TVar (TMVar ()))
      -- ^ Gets filled when above gets written to.
      -- Invariant: value is always empty.

the TVar will always point to an empty TMVar, but when the first value gets modified, this empty TMVar is filled (with ()) and the TVar is modified to point to a new empty TMVar.

At this point, the functions listening to the LVar were waiting for the first TMVar to be filled, and when this happens they can proceed to read the new value.

[lua-vr]

Oh, and it also fixes the "problem" I started with, namely the fact listenNext would return immediately in the first time it was called with a given ID...

[srid]

@lucasvreis Since this is almost a rewrite, could you add some tests (that mirrors usage in Ema) using hspec ?

Ideally, tests as separate PR which gets merged to master and then we use that in this PR (with whatever additional tests that represent the fixes/changes).

[lua-vr]

@srid I had a look at hspec and my impression was that we're not supposed to run IO actions inside tests... I only saw functions for running IO before or after each test. Perhaps you can try it in emanote? I think it's short enough to understand what it's doing (or at least a fun puzzle to work out 🙃). It's the same mechanism used in TChan.

[srid]

Why not use unsafePerformIO?

[srid]

I think it's short enough to understand what it's doing

Okay, I'll review it latter.

[srid]

My god, I let this PR slip! Will take a look soonish, @estradilua