Progress. Generic inner procs are now moved to a position where lambda lifting can handle them.
In other words, this code now works:
import std/[syncio]
proc outer =
var x = 120
proc inner[T] = echo x
inner[int]()
outer()It also does not use the heap as the closure does not escape.
https://github.com/nim-lang/nimony/issues/1478 lists "heap based exceptions".
About OOM: It's covered in my blog post, what do you want to know?
Well seqs and strings and collections in general have an "empty" state that we can use should an allocation fail. Failures also trigger a callback. Only new(x) returns nil on OOM and since we check for nil derefs at compile-time, the compiler complains about it. Only if the proc already uses .raises the compiler then exploits this fact and the new operation then cannot return nil. (Of course, this special behavior can later be exposed as a pragma for other new-like operations but there is no experience with this feature yet, so why bother...)
In other words, usually allocations do not cause a .raises annotation.
But if the callback doesn't terminate the program, how can it allow to recover? It doesn't know where the failure happened (as per signature) and how to handle it.
Also, wanted to share a though about OOM handling. It is quite different from other failure modes, as
That means most of the time the programmer can be oblivious to the fact that allocations can fail, as this almost never happens, and when it does, there is nothing to be done (not at runtime at least).
So perhaps it would make sense to make OOM tracking orthogonal to exception tracking. Every proc can raise OOM by default (unless compiler inferred otherwise). If one wishes to stop it from crashing the program, one can annotate some proc with something like .oomSafe., and then the compiler forces one to handle it (similar to .raises: []. trick).
So if the programmer doesn't use .oomSafe. annotation and doesn't handle OOM anywhere, he gets the nim v2 experience (OOM equivalent to a defect), and can be oblivious to this failure mode entirely (which is fine most of the time IMO). If he wants control over how and when OOM is handled, he can get as much as he wants.
This can also be back-ported to nim v2, I think.
But yes, the PNode is completely gone and a node takes 8 bytes and that's not a pointer, but a full node, it fits in a hardware register and can be bit-copied.
You can help out with https://github.com/nim-lang/Nim/pull/25201 which brings NIF+IC to Nim 2.
As for your question: I think it's completely infeasible, I started from "scratch" with Nimony for this reason. Feel free to prove me wrong. ;-)