Front page | perl.perl5.porters |
Postings from December 2021
On Sat, Dec 18, 2021 at 08:57:05AM +0000, Ovid via perl5-porters wrote:
> He wrote: "Unknown::Value from @OvidPerl looks very interesting. These objects can't compare, do math, or most of the other default behavior that undef allows. This would be awesome in core."
>
> Would there be interest?
So, to try to clarify, an RFC for this would need to be a design for how
`unknown` values interact with all parts of the language?
So, I think most unary and binary operators are fairly clear.
But it would also have to figure out everything else. So, say this:
$bar = $hash{$foo};
we need a spec for what $bar is, if $foo is unknown?
Which, I think, makes most sense as $bar also is unknown.
So continuing this thought experiment:
$hash{$foo} = $bar;
Where $foo is unknown, what happens? We have to specify that too...
I *guess* that this has to be a runtime error - "attempt to assign to an
unknown hash element"
etc.
Likewise:
$result = $foo ? bar() : baz();
I had thought - ternary, where $foo is unknown - can't take the true side,
can't take the false side, so logically surely it short-circuits to assign
$result as unknown.
But then that means that to be consistent with that, here:
if ($foo) {
bar();
} else {
baz();
}
if $foo is unknown we can't enter either block
and then to be consistent with that, this:
if ($foo) {
bar();
} elsif (rand < .5) {
baz();
} else {
...
}
should be treated like this:
if ($foo) {
bar();
} else {
if (rand < .5) {
baz();
} else {
...
}
}
as soon as $foo is unknown, then we can't take the if block, and we can't
take the either side of the elsif,
and this seems nuts, hence ? : ternaries can't behave the way I first
suggested...
So an RFC would have to go down all these paths, to figure out how to make
a language that is consistent in how it handles unknown in all places?
Nicholas Clark
Thread Previous
|
Thread Next