Front page | perl.perl5.porters |
Postings from December 2021
Re: Pre-RFC: `unknown` versus `undef`
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
December 19, 2021 21:13
Subject:
Re: Pre-RFC: `unknown` versus `undef`
Message ID:
37d28712-f319-7209-67e4-e425618f9236@darrenduncan.net
On 2021-12-19 4:13 a.m., Ovid via perl5-porters wrote:
> In Perl, $var might be undef and be evaluated as less than three. However, $var might be the string "Hello, World". $var might also be a reference to a hash, we get absolutely no warning, and we hit our else block with an assumption that is probably true ($var <= 3), but not in this particular case. We _should_ be verifying what kind of data that $var holds, but usually we don't.
>
> Thus, in a dynamic language like Perl, barring validating our data up front, the else block very often makes no guarantees about what kinds of data that we have.
It seems to me that the real problem here is more that we're seeing a
consequence of Perl's weak typing, where values of one type are automatically
cast as values of another type when we try to treat them as the latter. The
"undef" problem is a key example of this but there is also the other examples
you cite.
I feel that a much better solution to the real problem is to support stronger
typing in Perl, make it possible for values to NOT automatically convert to
other types, and instead raise an error.
Regardless, I feel that the best way to implement a solution, whether the things
I've proposed or the thing you proposed, is over top of and/or as an extension
of Corinna rather than as some other independent thing.
So your Unknown should be a Corinna object, thus leveraging this more generic
fundamental type Corinna is introducing to the Perl core and exploiting its
power, rather than being yet another orthogonal thing.
Especially as whatever bit flags or whatever for the underlying implementation
of Perl values are of very limited supply, I feel it would be a bad idea to
waste one on this Unknown concept.
The Unknown concept should be hoisted as a higher level concept implemented in
terms of other things, such as being a Corinna object, and not be fundamental.
This would not be part of the minimal-MVC of Corinna, but the minimal-MVC of
Corinna can be designed in such a way that support for
Unknown/Excuse/types/whatever can be added later in a non-compatibility-breaking
way.
I also see that when a later extension to Perl to support the option of
explicitly typing variables/fields/parameters/etc, which also helps the ability
to compile the code for speed, this Unknown etc concept could be added THEN, as
more of a set of complimentary strict types that the Perl core defines, besides
just-an-integer, just-a-float, just-a-string, etc, and I would note those strict
types EXCLUDE undef.
What do you think about that? Putting Unknown/etc off to be a post-Corinna thing?
-- Darren Duncan
Thread Previous
|
Thread Next