HaloO,
Larry Wall wrote:
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.
Also replying to the thread in general, I feel that undef as a
language concept mixes too many usefull concept into a single
syntactic construct. The problem is the same as overloaded $!.
Autovivification e.g. is hardly a problem as far as lvalues
are concerned because the undef content is overwritten with
the rvalue anyway. Operators like ++ could have a Undef of Int
specialisation that writes 1 into the affected container. So
the point here is more of defineing behaviour then actually
trying to dwim the undwimable!
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.
I agree. Every entity operating large software systems should
have well defined procedures for reading log output of their
systems and *do* something about warnings in the long run. It
is not the task of a low-level routine that whatever context
asks for its services is prevented from continuing just because
the service can't carry out its business. Hmm, on this level of
unspecificity this last sentence hardly makes a point.
So let me illustrate what I mean by picking an example. Let's
consider &open:( Str --> File ) where we all know, that not all
strings denote a file. But returning undef in that case---at least
to me---feels as violating the interface even if the particular
undef has got type Undef of File.
In other words the designer of the File type should foresee a special
instance that implements the interface of File in a reasonable way.
E.g. returning EOF on .read and swalling arbitrary input on .write and
more important can be tested for. The latter requirement nicely maps to
the Perl6 concept of booleanification where *only* this particular
invalid file instance returns false an its .bit property.
If a fallback instance isn't what the designer wants the interface
should read &open(Str --> File ^ Undef) in the first place. Not
specifying the return type at all is of course a generic solution
or implementation of unspecificity :)
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.
But note that the failsoftness is a property of the construction
and not of nature itself! In the context of Perl6 this means to
me that the language must address both sides of the deal in a fashion
that clearly separates error communication from defaulting/fallback
values. In other words this thread tries to address the practise of
using undef as don't care value indicating the intent to get the
default behaviour. Thus the concept of a caller provided undef beeing
a value that is defined as far as falling back to the default of the
interface is concerned but is undef as far as the actual value is
concerned is bad:
sub foo( ?$bar = "default" ) { say $bar }
and then
foo( undef ); # doesn't print "default"
foo(); # prints "default"
Strict typing is all very well at compile time when you can do
something about it,
Perl6 has many levels of compile time! That is like airplanes
have a strict pre-flight check which is of course counter productive
enroute. And then exception handling for the airline and passengers
might e.g. mean a stay in a hotel until the machine is rpaired or
a replacement has arrived etc.
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.
But then again you might want to do something about temperatures out
of deadbands. Otherwise you could just optimize the temperature sensor
away in the first place. IIRC that is the case for rockets used on
New Year's eve ;) Here the question to the operator is how to handle
a rocket that didn't lift off. Walking there and inspecting it with
bare hands and *eyes* might be a bad idea!
--
