* Darren Duncan <darren@darrenduncan.net> [2021-12-19 03:34:06 -0800]: > On 2021-12-19 2:53 a.m., Martijn Lievaart wrote: > > Op 19-12-2021 om 11:48 schreef Darren Duncan: > > > Well the other reasonable solution is to treat the pair as "if the > > > expression result is true" and "if the expression result is anything > > > else". I actually thought of proposing that and then I didn't. > > > > > > However, doing that means these 2 things will behave differently in > > > the presence of unknown where they wouldn't otherwise: > > > > > > if ($x) { > > > foo(); > > > } > > > else { > > > bar(); > > > } > > > > > > if ($x) { > > > foo(); > > > } > > > if (!$x) { > > > bar(); > > > } > > > > > I like it from a conceptual point of view. It feels right. It feels > > correct. But only for new code that is written with this 3VL in mind. > > Otherwise I think it will open a can of bugs in existing code, so that > > probably should still die. > > I still think, however, my original proposal of neither if nor else running > when an unknown is input, is probably more correct and consistent with the > wider context. > > That interpretation means both of the above examples behave the same as each > other, same as would be the case under 2VL. > > A stronger supporting point is that the do-nothing answer is more consistent > with the examples Ovid gave about desired behavior for "grep" or such, which > is that unknown are omitted from the result no matter whether the grep > condition tests for truthiness or falseiness, which is also the same as how > SQL WHERE behaves with NULL. > > -- Darren Duncan I think this concept is above my head. For example, looking at the examples on Unknown::Values it's hard for me to figure out what's different. I get the idea of an actual "unknown" or "unable to get" value, but I keep going to the notion that this is an attribute of the data or access method; and therefore would be more appropriate implemented as: * a special "value" with a class * something that could benefit from Tie * something still that could benefit from a suite of overloaded ops * something that could be execpected to throw an exception rather than affect the semantics of ordinary looking code The closest concept I can think that I might be familiar with is Fortran's NaN, which is part of the IEEE arithmetic standards. It is composed of a special values that can be detected in hardware or software. If this was to be implemented as a special value, I do indeed think that the existing operators and keywords should behave in a way that is consistent with current coersion of undef, falsey things, etc. In addition to this, it makes sense to me to expect there to be a keyword that checks explicitly for an unknown value, in the same way C<defined> works with undef; which provides an extra degree of precision when you really want to differentiate undef from a falsey value (q{}, $x <=, e.g.). # give a 5% raise to lowest wage earners who are not volunteers if (defined $emp->salary and not unknown $emp->salary and $emp->salary < 4_000) { $emp->salary($emp->salary + $emp->salary * 0.05); } Cheers, Brett -- -- oodler@cpan.org oodler577@sdf-eu.org SDF-EU Public Access UNIX System - http://sdfeu.org irc.perl.org #openmp #pdl #nativeThread Previous | Thread Next