Ability to discover what IDs a callbag supports about callbag

[staltz]

By the way, RxJS is not trying to be at all callbag compliant, they are just taking a few ideas and techniques from some callbag utilities, in order to reduce library size.

[dead-claudia]

@jordalgo The fallback, where callbags have to forward anything they don't understand, is for IDs they don't support. But when two callbags support the same ID 10+ with conflicting meanings, that's the user's and/or callbag creator's problem to sort out - it's no different than conflicting event names, and it's an issue this doesn't solve.

[staltz]

This would help to determine whether a source is pullable or not, but only at consumption-time (i.e. not without beginning a handshake with the pullable).

If undefined/missing, it would default to [0] for convenience.

Because of this, there seems to be an easy path for making a compatible spec instead of mutating the current one.

[dead-claudia]

Because of this, there seems to be an easy path for making a compatible spec instead of mutating the current one.

That was one of the minor goals of this: don't be too breaking. I was wanting to see about how

This whole thing was a thought experiment. If I were to write a greenfield "callbag"-style spec with this, I'd use objects with appropriate methods instead, like {...sink, greet(source) { ... }}. They're a little less cryptic, and I can spread the extra methods instead of mandating raw proxying. They also make for easier querying, and I wouldn't need the ID system. Extensions that are domain-specific could just choose to use symbols to avoid clashing.

[dead-claudia]

The object idea is quite a bit higher-memory and a little higher overhead, though, enough that I'm not quite comfortable with it. So maybe back to the drawing board. (This would be much easier to address in a statically typed language built for this, but that's not going to happen in JS.)

Oh, and now that I think of it, callbags remind me a lot of process calculus (particularly asynchronous π-calculus) and actors both, almost a simplified mix between the two. It lacks the mailbox of most actors and it lacks the built-in "replicate" that asynchronous π-calculus has, but much of the rest could be easily encoded (I probably got a few of these slightly wrong, but I'm not super well-versed in either):

• π-calculus concurrency: P | Q ↔ create a callbag where P and Q are invoked with the arguments passed in.
• π-calculus communication, output-prefixing: c̅⟨y⟩.P ↔ basically how you do handshakes now.
• π-calculus "creation of a new name": (vx) P ↔ just accept a new message type.
• π-calculus nil process: 0 ↔ (id, talkback) => { if (id === 0) talkback(2) }
• Actor messages: callbag(id, data)
• Create actor: (id, talkback) => { ... }
• Designate behavior used for message: if (id === 10) { ... } else { ... } inside callbag.

Out of curiosity, was the actor model and/or any process calculi an inspiration for this?

[jordalgo]

@isiahmeadows - I like this idea. Does this only apply to the IDs in this callbag spec (e.g. not including any added later?). I'm asking because any additional IDs would have to be part of some other agreed upon spec otherwise they don't mean much e.g. RxJs using "3" for errors whereas another library uses "11".

[dead-claudia]

@jordalgo It applies to all IDs, including non-standard IDs other people use. The "greeting with the various IDs" is meant to notify libraries of what's supported within the pipeline, so they can adapt accordingly. The rationale behind the required proxying is in cases like this, where I don't want that to get lost even though various operators. In that case, one could create an operator to lift and abstract it out of the sink using a custom ID with return value, and with this proposal, you could do that even after applying map/filter/etc.

By the way, I made a few changes to the proposal, notably I replaced arrays with functions.

[jordalgo]

@isiahmeadows I guess what I'm confused about is if the the meanings of the IDs are not standardized then two callbags could support the same ID with different meanings. Or am I missing something?