develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About