sugar for calling cps procs from cps about cps

[Clyybber]

Maybe we should build another macro on top of {.cps.} that automagically does this and #20 ?
(And maybe then rename the current cps macro to cpsRaw or something..)

[zevv]

There's a bit of a problem with all this untyped stuff. We have 3 kinds of calls

• A call to a normal proc
• A call to another .cps. proc
• A call to a .cpsMagic. cps primitive proc

If we really want to hold op the illusion of magic, it would be cool if all of these would just look like any other normal call. No magic cps keyword or cps.foo() notation, just call a proc and let cps figure it out.

The problem is that I'm not sure if this can be done, since the .cps. macro does not know anything of outer context, so when you call foo(), it has no way of knowin which of the above 3 cases should apply.

Prove me wrong, and I'll buy you a beer.

[disruptek]

proc foo(): Cont {.cps.} =
  echo "Hello"
  continue bar()
  echo "There"

proc bar(): Cont {.cps.} =
  echo "I'm bar"

[disruptek]

This can also be a thing soon:

proc foo() {.cps: Cont.} =
  echo "Hello"
  echo yield bar()
  echo "There"

proc bar(): string {.cps: Cont.} =
  result = "I'm bar"

[zevv]

proc foo(): Cont {.cps.} =
  echo "Hello"
  continue bar()
  echo "There"

I'm against reusing keywords which have a different meaning in a different context. It's confusing for users and you might get bitten if you can't properly distinguish "real" continue or yield from your "new" continue or yield.

Apart from that, the question was whether we can induce things here, or if we need some kind of explicit keyword or operator. I don't think we can get there without more type info of what is living outside our .cps. proc, so that's probably a "no" for now.

It's called cps in the current implementation, which is confusing because it is the same name as the macro. yield is taken, so let's assume we call it pass for now, until we find a better name.

Next question, because you seem to thing rvalues can be a thing: Could we use the same keyword for things that do and things that don't result in an rvalue? That should be ok, because if what your calling is a .cps.` proc that does not "return" something, there is also nothing to discard.

proc foo() {.cps: Cont.} =
  pass hello()  # Nothing "returned", nothing to discard
  echo pass bar() # Nim forces the consume the result  `bass bar()` because `bar()` returns a string
  echo "There"

proc hell(): {.cps: Cont.} =
  echo "hello"

proc bar(): string {.cps: Cont.} =
  result = "I'm bar"

[disruptek]

I'm against reusing keywords which have a different meaning in a different context. It's confusing for users and you might get bitten if you can't properly distinguish "real" continue or yield from your "new" continue or yield.

Well, continue is invalid with an argument and yield is invalid outside of iterators. These keywords make sense in a .cps. context, which the user expressly enabled. It's pretty easy for us to throw an error if .cps. is applied to an iterator, right? If there's an iterator inside the .cps. body, we'll ignore it.

We will never have type information outside of .cps., as far as I can tell.

[disruptek]

Closed in typed branch.