On Sat, Dec 17, 2005 at 12:12:15PM -0800, Ashley Winters wrote: : Explicitly nil values wouldn't warn or fail on activities which undef : does. nil is basically a value which is simultaneously '' and 0 and : 0.0 and false *and* defined, and allows itself to be coerced with the : same rules as perl5 undef, but without an 'uninitialized' warning.
Hmm, the '' value is already simultaneously '' and 0 and 0.0 and false *and* defined, and allows itself to be coerced with the same rules as perl5 undef, but without an 'uninitialized' warning. I don't really think we need another one. And replying to the thread in general, I'm not in favor of stricter default rules on undef, because I want to preserve the fail-soft aspects of Perl 5. And that is better served by promotion of undef to "" or 0 with warnings than it is by letting one undef rot all your inputs. When they put multiple actuators on an airplane control surface, they do so with the assumption that some subset of the actuators might freeze in some position or other. It would be ridiculous in such a situation to throw away the authority of the other actuators even though "tainted" by the undefined values of some of the actuators. That's failsoft behavior. Strict typing is all very well at compile time when you can do something about it, but you do not want your rocket control software throwing unexpected exceptions just because one of your engine temperature sensors went haywire. That's a good way to lose a rocket. All that being said, it's really good to know when and if your reliablility is suffering. But you don't just give up in disgust, and that's what NULL propagation is essentially doing. Real engineering adds knowns to unknowns and comes up with a good guess about how much redundancy to build into the system to compensate. I don't want Perl 6 to be *brittle* at run time. I do think that if you want brittle undefs, it'll be easy to enforce by catching warning exceptions and promoting them to fatal exceptions. But remind me not to ride on your airplane. Larry