chore: make pure/List mostly tail-recursive

[ggreif]

TODO:

• size could be more efficient with a loop
• repeat ditto
• tabulate is not tail-recursive (but constructor tailed)
• concat is not tail-recursive (but constructor tailed)
• merge is not tail-recursive (but constructor tailed)
• fromIter is not tail-recursive (but constructor tailed)
• reverse looks tail recursive (could be more efficient with a loop)
• mapResult needs another look (somewhat convoluted in legacy base)

[github-actions]

No description provided.

[rvanasa]

Is this just to speed up the tests? We might want to run this with the interpreter (default) to check for stack overflows.

[ggreif]

To me it appeared that the interpreter was more tolerant in terms stack. Maybe we should have a // @testmode both directive, if not already possible.

[ggreif]

I'll remove just before merging. Then we'll have both ways tested. But we should think about a combined strategy (maybe nightlies) for the future.

[crusso]

Are you sure text.size() is constant time when using ropes (in compiled code)? I don't recall off-hand. If not, revert!

[ggreif]

Good point! I'll revert!

[crusso]

(It's no 0(1), I checked)

[ggreif]

Though, compiling the size() > 1 as a unit would be constant time even in the presence of ropes. I expect users committing the same mistake in real life, and getting quadratic runtime on code like this (i.e. comparisons of size() with small constants).

[ggreif]

Wait, do ropes carry a size around? That would help certainly :-)

[ggreif]

Nice:

// Layout of a concat node:
//
// ┌────────────┬─────────┬───────┬───────┐
// │ obj header │ n_bytes │ text1 │ text2 │
// └────────────┴─────────┴───────┴───────┘

[ggreif]

So this is resolved in the good way!

[ggreif]

Reverting, those are bytes, not chars.

[crusso]

Suggested change

	public func size<T>(list : List<T>) : Nat = (
	func go(n : Nat, list : List<T>) : Nat = switch list {
	case (?(_, t)) go(n + 1, t);
	case null n
	}
	)(0, list);
	public func size<T>(list : List<T>) : Nat = {
	var size = 0;
	var cur = list;
	loop {
	switch tmp {
	case (?(_, next)) {
	size += 1;
	cur:= next
	};
	case null { return size }
	}
	}
	}

Is probably cheaper (no call to a helper).

[ggreif]

Yep, I was hoping that the compiler could create the same (or better) code by TCO. I.e. not sure if var allocates in this example (it shouldn't).

[ggreif]

I did the same transformation in repeat, though.

[crusso]

reverse needs it too. TCO won't inline the auxiliary function so ...

[ggreif]

I actually test reverse for stack overflow and I haven't seen any 😖
With depth 100_000!

[ggreif]

But for TCO one only have to turn the body of the helper into a loop, no need to inline it into the wrapper. Or am I mistaken?

[ggreif]

Of course the interpreter won't do TCO, and if we want constant stack there we'll have to manually TCO anyway... Or maybe due to CPS the interpreter will do the right thing. Questions, questions!

[crusso]

I actually test reverse for stack overflow and I haven't seen any 😖 With depth 100_000!

If you test in the interpreter you won't see because the interpreter is in CPS... On wasm, you should see

[ggreif]

I test on Wasm, and don't see it :-) I'll look at IR/Wasm soon.

[crusso]

Sorry, you reverse is tail recursive, but it allocates and calls a helper that is probably slower than just using a loop and a temp, without the additional function call.

[crusso]

There's more TODO (see #195)

[ggreif]

This is a shame. A clever optimisation would spot the linear heap allocation discipline arising from the recursive algorithm (did somebody say abstract interpretation?) and pre-allocate the list nodes. Then fill them in like an array...

[crusso]

Yes, that's called tail-modulo-cons optimization but we don't have it.

[crusso]

Is this still a draft?