Use $app/no-return in cptypes [WIP]

[gus-massa]

There are a few things that I don't understand, so this is more a long question with a proof of concept than a finished PR.

---

When cptypes detects an error that is not obvious, use $app/no-return so the other passes can notice it. But cp0 transform $app/no-return to special flags in preinfo, so let's add the flags directly instead.

After this change, in the second leap cp0 can notice that cptypes detected an error and apply more reductions. See the example at the bottom of cptypes.ms Also, there is an old example in cp0.ms that has type problems on purpose, and is broken with an explicit use of $app/no-return.

I'm worry that this is wrong for some primitives that write/read the continuation attachment. Is there an obvious example? Is there a not obvious example?

Is it wrong with lambdas instead of primitives? I'm almost sure it is, but I'd like to see an example to be sure what to care about . (Anyway, probably lambdas will be left for a PR in the future.)

---

If this make sense and is (almost) correct, I'd like to take a look if the same change can be applied in more parts of cptypes, and do some refactor and cleanup.

[mflatt]

This looks like the right idea to me.

I can't think of a reason that it would go wrong with continuation attachments. If it can, it seems like it would be a general cp0 issue with the no-return flag that we'd need to fix there.

The flag is not intended to be constrained to primitives, so it should be fine if the target of the call is created with lambda. As an example, the Racket implementation uses $app/no-return to call non-primitive procedures that format and throw exceptions.

[gus-massa]

I was worried about

ChezScheme/s/prims.ss

Lines 540 to 544 in 73803e1

	;; Implies no-inline, and in unsafe mode, asserts that the
	;; application will not return and that it does not inspect/change
	;; the immediate continuation attachment (so it can be moved to a
	;; more-tail position)
	(define $app/no-return

[mflatt]

I see. There are no uses of continuation marks/attachments in any primitives, so I think this is ok for primitives.

It complicates adding the no-return flag to calls of non-primitives, since the optimizer would need to prove the extra constraint on the called function — a little more work, but probably straightforward in many cases.