Front page | perl.perl5.porters |
Postings from December 2021
Re: Pre-RFC: `unknown` versus `undef`
Thread Previous
|
Thread Next
From:
Ovid via perl5-porters
Date:
December 20, 2021 15:20
Subject:
Re: Pre-RFC: `unknown` versus `undef`
Message ID:
1294714668.2120346.1640013619796@mail.yahoo.com
OK, I can't argue against Nicholas' points.
Best,
Ovid
--
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
On Monday, 20 December 2021, 13:21:20 CET, Nicholas Clark <nick@ccl4.org> wrote:
On Mon, Dec 20, 2021 at 11:00:16AM +0000, 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
Limited by what you can do by overloading.
So no way of prototyping things like my question of how hashes behave when
unknown values are used as keys in RVALUE context, and in LVALUE context.
And I realised that even that what I suggested wasn't complete. For this:
$bar = $hash{$foo};
If $foo happens to be unknown, is $bar always unknown?
Or is it undef if and only if %hash is empty?
That behaviour is arguably more consistent with what unknown means than the
"always return unknown".
And the thought experiment about what ternaries and hence if/else should do.
There are a *lot* of operations that aren't prototyped yet.
For example,
$$foo
dereferencing an unknown is what? An unknown? An exception?
Either answer seems reasonable.
eval $foo
trying to pass it to eval is what? An unknown? An exception?
Does trying to use an unknown value as a file handle trigger an exception?
Or an infinite stream of unknowns on read attempts?
What is the range [$foo .. 42] where $foo is unknown?
I *think* that most logically it's an empty list, but that does seem to
end up eliminating unknown-ness. Hence if we have first class unknowns,
should we be able to have arrays of unknown length?
> 4. It has a high-value win in eliminating common types of errors we currently deal with
And massive risk in introducing a lot of surprises in code not written to
expect unknowns, that is passed one within a data structure.
Basically all of CPAN.
This really (still) feels to me like it's currently a research project, not a
feature to add to a mature language used in production.
Only when there's a working prototype that can explore most questions about
"how does X behave with unknowns?"
There are about 400 opcodes in perl. I suspect that >90% are easy to figure
out for "unknown" (for example as "what would a NaN do here?") but a few
really aren't going to be obvious, or end up being trade offs between
conceptual correctness and what it's actually possible to implement.
Nicholas Clark
Thread Previous
|
Thread Next