I can solve the problem at hand by other means, so my question is not seeking a specific solution but a general technique, and knowledge about what is possible in Perl 5.

Since you are curious about the context, I have an application which uses Storable for persistence and undef is used to represent "no answer". This works nicely for the core engine. I'm now working on a tool chain to convert a this data into various presentation formats, a few of which would like to distinguish between existant/nonexistant undefs and present them differently (the distinction being "no answer"/"no answer, never saw the question"). The distinction is more in the minds of the users than anywhere else, most of the utilities will not make this distinction and shouldn't be troubled by it. My current solution is to maintain the flags in a separate structure in parallel to the main data stream.

My original question mentioned YAML because the data stream pipeline uses IO::YAML pass data beween utilities.

If you have other suggestions, they're welcome,

Brad

Would it be appropriate to use an object to represent either the answer, the question, or the question and answer? If magic is to be invoked in any case, better to invoke "standard" magic than to invent a tricky sort of magic such as giving meaning to something who's only meaning is to say "you can know nothing about me because I don't exist".

---

DWIM is Perl's answer to Gödel

Just to be clear, I'm not planning on deploying XS overrides of core ops, nor tied and overloaded contructs. If this had been implemented in a module, then perhaps I'd consider it.

Only the answers (and the exists flags) are in the data stream being transformed, not the questions. I'll think about wrapper objects further.

I've often been told that it's a bad practice to use the lack of data to mean something. An undef means we have no data. If you want it to mean something else, as you do here, I think it's a lot better to make some data that explicitly means "no answer" as GrandFather suggested. It's also probably wise to steer clear of the kind of trickery that would be required to do what you asked for originally, since it's likely to be a brittle solution.