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

Reply via email to