vine: allow opaque ext fn in pre-reduce #317
Conversation
There was a problem hiding this comment.
This currently panics if the custom ext fn is called during pre-reduce:
pub fn main(&io: &IO) {
foo();
foo();
}
fn foo() {
custom_ext_fn(1, 2);
}
fn custom_ext_fn(a: N32, b: N32) -> N32 {
inline_ivy! (a <- a, b <- b) -> N32 { out a = @custom_ext_fn(b out) }
}Pre-reduce should treat the principal port of an opaque extrinsic function as though it were black_boxed.
I'm also not a fan of passing the Extrinsics as a parameter through everything; it would be much preferable to me if this could be implemented without needing to touch the Extrinsics.
Perhaps we could rename the Inert instruction to InertLink, and add an InertNode instruction that takes a label and three ports, and similarly just adds it to a buffer. Then, instead of creating an actual extrinsic function node, the host can insert an inert node with a label telling it what opaque extrinsic function it represented.
|
I'm now using Also I have two more questions:
|
There was a problem hiding this comment.
Looking good!
Should the
Hosthave an explicit fieldallow_opaque_ext_fnto only allow them in the pre-reduce step and panic early in all other cases?
Yeah – there's currently a black_box flag on the serializer which is enabled during pre-reduce, so I think it would make sense to rename this (maybe to allow_inert or similar) and use this flag to control the opaque ext fns as well.
Should the IO ext fns also be opaque functions in the pre-reduce step, currently only the run-time guarantee that they will never interact with an IO handle makes them correct in the pre-reduce step?
IMO this isn't necessary. It might happen eventually if we move some of the IO logic out of the core, but I don't think anything needs to be done for this now.
Currently the Vine compiler assumes exactly the IVM extrinsic functions for the pre-reduce optimization step. This change allows the pre-reduce step to handle arbitrary extrinsic function and is a step towards #257.