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 20, 2021 11:23
Subject:
Re: Pre-RFC: `unknown` versus `undef`
Message ID:
09578d38-2206-d871-ec25-1afd7e83465c@darrenduncan.net
I feel that you underestimate how complicated your 3VL project would be to 
thoroughly implement as a built-in native core type, at least if you want the 
behavior of all the core operators and routines to change to respect it.

In particular I feel that the Corinna MVC is actually simpler than what the 3VL 
would entail.

Also, the response I have seen so far to the idea, not just from me but from 
others, seems to be quite mixed, and it seems considerably less of a sure thing 
to be built-in than is Corinna.

I do not see unknown values as orthogonal to a type system, rather they are an 
element of and inseparable from a type system, though multiple type systems can 
have them.

Unlike Corinna, which I see it is best for being built-in to Perl at a low 
level, I believe that your Unknown proposal is best kept in the form of a CPAN 
module and not be something built-in to the core language.  That is, the final 
form can be the same form as the prototype, which is that Unknown is an object 
of a specific class, and it defines its own versions of operators or subs that 
it wants special behavior for.

I strongly support Corinna, at best I only weakly support the Unknown proposal.

If time is limited then Corinna should be prioritized for landing and this other 
thing wait until after it has before Unknown takes resources away from Corinna.

-- Darren Duncan

On 2021-12-20 3:00 a.m., Ovid via perl5-porters wrote:
> On Sunday, 19 December 2021, 22:13:53 CET, Darren Duncan <darren@darrenduncan.net> wrote:
> 
>> 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.
> 
> I think there are two problems with that.
> 
> 1. Support for stronger typing in Perl is years away and we don't even know if we'll get it.
> 2. 3VL logic works with both static (throw an exception) and dynamic (apply Kleene's 3VL) typing.
> 
> So unknown values are orthogonal to how a type system is implemented.
> 
> So my argument is:
> 
> 
> 1. Adding unknown values is a relatively small change (compared to adding a type system or building Corinna)
> 2. Its behavior is generally decoupled from current features, making it safer to implement
> 3. It has a working prototype and test suite on the CPAN
> 4. It has a high-value win in eliminating common types of errors we currently deal with
> 
> I think trying to add more to this simple idea to perfect it is premature (though I like your concept of Excuse). As an MVP, you can start using it today. If unknown values can be implemented in Perl, then we can see how it's actually being used and decide when (or if) we want to expand on it.
> 
> 
> Best,
> Ovid


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