So in trying to understand callbags, especially in native typescript better I started implementing a non-blocking version of interval which didn't work but the blocking version did. Obviously don't want to lock up other code waiting on an interval. What am I missing in the non-blocking version?

import { Producer, END } from './types';

export function intervalNonblocking(ms: number): Producer<number> {
  return (_, sink) => {
    let id: NodeJS.Timeout;
    let i = 0;

    id = setInterval(() => {
      sink(1, i);
      i++;
    }, ms);

    sink(0, (_: END) => {
      clearTimeout(id);
    });
  };
}

export function intervalBlocking(ms: number): Producer<number> {
  return (_, sink) => {
    let ended = false;

    sink(0, (_: END) => {
      ended = true;
    });

    let lastTime = Date.now();
    let i = 0;
    while (!ended) {
      const now = Date.now();
      const delta = now - lastTime;
      if (delta >= ms) {
        sink(1, i++);
        lastTime = now;
      }
    }
  };
}

Currently, we're using couple of plain types to represent code type.
IMO, It would be better if we use enum to do so for these reasons:

1. Typings became more meaningful

enum Code {
  START,
  DATA,
  END,
}

is better than just spreading plain types.

2. Increase code readability in term level

Instead of using numeric constants(whose shape is very odd) like 0, 1 to represent code,
we can use constants like Code.START when we write code.
And this will make our code more readable.

Is there any reason not to use enum to represent code type?
Please let me know if it exist. :)

Currently

type Callbag<T> = (t: ALL, d?: Talkback | T | any) => void;

the d: Talkback means that if we call this callbag with (0, talkback) then the given talkback can never be called with 0 or 1, but that happens in src/subject.ts:

import { Callbag, ALL } from './types';

export function makeSubject<T>(): Callbag<T> {
  let sinks: any[] = [];

  return (type: ALL, data: any) => {
    if (type === 0) {
      const sink = data; // this sink *would* be typed Talkback and 
                         // thus we shouldn't call `sink(0, ...)`          
      sinks.push(data);
      sink(0, () => {
        const i = sinks.indexOf(sink);
        sinks[i] = void 0;
      });
    } else {
      let hasDeleted = false;

      for (let i = 0; i < sinks.length; i++) {
        if (sinks[i]) sinks[i](type, data);
        else hasDeleted = true;
      }

      if (hasDeleted) {
        sinks = sinks.filter(x => x !== undefined);
      }
    }
  };
}

This is kind of a non-problem, though, because the any dominates in d?: Talkback | T | any. But it doesn't make semantic sense.

But we don't use Callbag for anything else than typing the Subject, so how about we just rename it to Subject? And because of that we can type the Subject type correctly so that it can:

• Receive sinks (not talkbacks) when t=0
• Receive data when t=1
• Receive t=2

The (outward-facing) Subject type might be very soon important for implementation of the new Cycle run.

This is a thing I have just noticed when looking through the code