api change towards generics and away from concepts

[disruptek]

This is the basic idea:

type
  Continuation[T] = ref object of RootObj
    fn*: proc(c: Continuation): Continuation {.nimcall.}
    mom*: Continuation
    data*: ref T

...in which data is the user-supplied type that will hold continuation state which the user can play with. We will expose this thusly:

type
  Spell = Continuation[Mana]

proc fireball(c: Spell; mana: var Mana): Spell {.cpsMagic.} =
  dec mana, 20

proc parry(c: Spell; mana: var Mana): bool {.cpsVoodoo.} =
  roll(1, 2) == 2

proc drink(mana: sink Mana) {.cps: Spell.} =
  while mana < 20:
    inc mana
    sleep 1000

iterator attack(mana: sink Mana): string {.cps: Spell.} =
  if mana > 20:
    fireball()  # it allocs a new Spell with fireball's locals, but not a new Mana
  elif parry():
    yield "ah hah!"
    drink()  # like fireball but different
  attack()  # in theory, this is a no-alloc; in practice, it's like fireball() or drink()

var fight = attack(25.Mana)
while fight.running:
  fight = fight.fn(fight)
  if fight.finished:
    echo fight()
    fight = attack(fight.data)

The Spell type will still get extended to add locals, but we can already see a few improvements with this:

• we can move the data between continuations at rendezvous
• it gives us some room to change our machinery (fn, mom, etc.)
• trampolines are less brittle and disparate continuations can be chained
• accessing the user's type extension is even easier inside than outside
• generics are more composable than inheriting from the user's types
• no risk of compat issues between new/old concepts
• the guts are better hidden and what's visible is less scary

Now, my question is, how/where do we handle the return value? We could add it dynamically like we do the rest of the locals, but would you rather specify it as a generic?

Continuation[Mana, string]

I think this is much more along the lines of what we're after.

[zevv]

Hear hear.

About the return type though: what do we gain from explicitly naming it in the continuation generic, as it is already part of the proc signature for the cps function. Having it in two places requires me to repeat myself, and will just cause errors when the cps func return type does not match the type from the generic.

Also, I might want to use the same generic Cont type for different cps functions with different return types.