No. I can't either. I was initially thinking that as your running at compile time, you could generate a sigified-without-context wrapper sub that detectes the context and dispatched to the sigified-with-context subs.

And then replicate the user written sigified-without-context subs, to save coder effort and (human) cut&paste code reuse.

Unfortunately, whilst entirely possible to do, it doen't buy you much as you end up with three version of the same code with different names.

I tried to think of some way of using the source-filter nature of your module to perform some source-substitution "macro expansion" when generating the 3 variant requirements, but it may be too big a task I fear.

In the simple case of don't do anything in a void context and return the list or a reference to it in the other two, it's easier, and perfectly efficient to make that determination at runtime.

For the more complex case, the best idea I came up with is a a trio of pseudo-pseudo-blocks.

VOID{ ... }
SCALAR{ ... }
LIST{ ... }
[download]

When munging the subnames in the source filter, you'd also look for these. If the user's sub definition contained one or more of them, then you would generate the signified-without-context dispatcher sub. And one signified-with-context duplicate of the user's sub definition, but with the appropriate pseudo-block label, and the entirity of the other two types of pseudo-block removed. Or a fatal exception catcher for any that didn't exist.

It apppealed for a while, but I'm not sure that any efficiency gains from the removal of the runtime conditionals would give wouldn't be outweighed by the extra level of dispatch. And whilst the pseudo-blocks would allow the user's source to be fairly clean if the decisions are simple, it could easily get messy if they are more complex.

Finally, the extra complexity in the source filter would probably make test and validation much harder for production quality to be achieved.

Oh well. It seemed like a good notion when the thought struck me.