Front page | perl.perl5.porters |
Postings from December 2021
* 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 #native
Thread Previous
|
Thread Next