FYI this has been fixed in D5863 - can grab it from rebase master

nit: might be good to capture this input def pattern with a function that just takes the input name

clean dis

lol

add a test with fan-in inputs, you may need to unpack a list of these i think

this is in the context of generating a set of dynamic outputs which would be happening in one notebook, so i don't think collision is an issue. Will need to figure out how to support dynamic outputs from a notebook with this yield_result API or another at somepoint

this is real gnarly, is it feasible to decompose this at all? Some narrative about the different steps happening would be good too. It was particularly confusing to see these core abstractions re-used here without context since at first glance it seems like it might be a custom alternate path to the core execution flow as opposed to just re-using abstractions in a slightly different context

Nice

sigh, yes. i don't even know what to put in a comment because this is so weird but.

>>> def f():
...     return
... 
>>> def g():
...     yield from f()
... 
>>> [x for x in g()]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
  File "<stdin>", line 2, in g
TypeError: 'NoneType' object is not iterable

but

>>> def f():
...     return
...     yield
... 
>>> def g():
...     yield from f()
... 
>>> [x for x in g()]
[]

but this function has other yield which i assume would make it work, but you found it to be otherwise?

haha there has to be a term of art for a FIXME to TODO conversion

i believe you should be able to emit the return entirely.

The presence of a yield statement makes the function an iterator, even if the yield is never executed.

def f():
     return
     yield

returns an empty iterator

whereas

def g():
   return

Is just a normal function that returns None