develooper Front page | perl.perl5.porters | Postings from December 2021

Re: Pre-RFC: `unknown` versus `undef`

Thread Previous | Thread Next
Oodler 577 via perl5-porters
December 19, 2021 12:07
Re: Pre-RFC: `unknown` versus `undef`
Message ID:
* Darren Duncan <> [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);


SDF-EU Public Access UNIX System - #openmp #pdl #native

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About