Mailing List Archive: Should Devel::PPPort provide SvIsBOOL() ?

Should Devel::PPPort provide SvIsBOOL() ?

Sep 12, 2021, 3:46 AM

Post #1 of 4 (189 views)

I've been looking at adding some of my recent core function additions
into Devel::PPPort [1] and hit upon a bit of a question.

I can add the new sv_setbool() because really, it's just

sv_setsv(sv, boolSV(bool))

which is easy to backport. I can't easily do the same for the
SvIsBOOL() test function because older perls don't have a concept of
"this variable is boolean in nature". It *could* be argued that makes
it really simple:

#define SvIsBOOL(sv) FALSE

which would technically work, and technically provide an answer to any
XS modules running on such perls. But is it right?

In a way I feel it best to just not provide the function at all. On
those older perls, it's less that no SV has boolean-nature, and more
that this isn't a valid question to be asking about an SV, and so lets
not provide a wrapper function for it at all.

If no wrapper function exists then XS code can easily just

#ifdef SvIsBOOL
...
#endif

much as I'm already doing.

Thoughts, anyone?

[1]: This in itself has not been an easy task - I may write an
additional email about that later.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Re: Should Devel::PPPort provide SvIsBOOL() ? [ In reply to ]

grinnz at gmail

Sep 12, 2021, 9:16 AM

Post #2 of 4 (189 views)

Permalink

On Sun, Sep 12, 2021 at 6:47 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> I've been looking at adding some of my recent core function additions
> into Devel::PPPort [1] and hit upon a bit of a question.
>
> I can add the new sv_setbool() because really, it's just
>
> sv_setsv(sv, boolSV(bool))
>
> which is easy to backport. I can't easily do the same for the
> SvIsBOOL() test function because older perls don't have a concept of
> "this variable is boolean in nature". It *could* be argued that makes
> it really simple:
>
> #define SvIsBOOL(sv) FALSE
>
> which would technically work, and technically provide an answer to any
> XS modules running on such perls. But is it right?
>
> In a way I feel it best to just not provide the function at all. On
> those older perls, it's less that no SV has boolean-nature, and more
> that this isn't a valid question to be asking about an SV, and so lets
> not provide a wrapper function for it at all.
>
> If no wrapper function exists then XS code can easily just
>
> #ifdef SvIsBOOL
> ...
> #endif
>
> much as I'm already doing.
>
> Thoughts, anyone?
>

With a grain of salt because I don't write XS code personally: the purpose
of Devel::PPPort is to replace the need for authors to write ifdefs for
every feature they use. As such, I think a function that always returns
false because the concept doesn't exist on those Perls is perfectly
reasonable.

-Dan

Re: Should Devel::PPPort provide SvIsBOOL() ? [ In reply to ]

wolf-dietrich_moeller at t-online

Sep 15, 2021, 1:23 PM

Post #3 of 4 (189 views)

Permalink

Dan Book wrote on September 12, 2021 16:17

> With a grain of salt because I don't write XS code personally: the purpose
> of Devel::PPPort is to replace the need for authors to write ifdefs for
> every feature they use. As such, I think a function that always returns
> false because the concept doesn't exist on those Perls is perfectly
> reasonable.

I have one concern about this. New programs will take the response
of Perl as definite, as it has a knowledge of isBOOL or not.
But older Perls should respond "Don't know", as they have no information
on isBOOL. But Perl has no 3-valued logic ...

If a new program would encounter "False" on an old Perl, it may silently break,
as it will assume that the response is a definite answer, and will not
consider that a new Perl may have responded with "True" in the same place.

On the contrary, if the author has to write ifdefs etc., then he himself has to
care about the cases with "Don't know", and the possibly wrong "False" cannot
give silently wrong results in his program.
Otherwise the author would have to write a version-dependent program, to know
if he can trust the answer, or if "False" is in fact only a "Don't know".

Just a thought of a Perl user (and not of an XS writer).

Wolf

Re: Should Devel::PPPort provide SvIsBOOL() ? [ In reply to ]

grinnz at gmail

Sep 15, 2021, 1:48 PM

Post #4 of 4 (189 views)

Permalink

On Wed, Sep 15, 2021 at 4:24 PM Wolf-Dietrich Moeller (München) <
wolf-dietrich_moeller@t-online.de> wrote:

> Dan Book wrote on September 12, 2021 16:17
>
> > With a grain of salt because I don't write XS code personally: the purpose
> > of Devel::PPPort is to replace the need for authors to write ifdefs for
> > every feature they use. As such, I think a function that always returns
> > false because the concept doesn't exist on those Perls is perfectly
> > reasonable.
>
> I have one concern about this. New programs will take the response
> of Perl as definite, as it has a knowledge of isBOOL or not.
> But older Perls should respond "Don't know", as they have no information
> on isBOOL. But Perl has no 3-valued logic ...
>
> If a new program would encounter "False" on an old Perl, it may silently break,
> as it will assume that the response is a definite answer, and will not
> consider that a new Perl may have responded with "True" in the same place.
>
> On the contrary, if the author has to write ifdefs etc., then he himself has to
> care about the cases with "Don't know", and the possibly wrong "False" cannot
> give silently wrong results in his program.
> Otherwise the author would have to write a version-dependent program, to know
> if he can trust the answer, or if "False" is in fact only a "Don't know".
>
>
But it is not a "Don't know." The construct does not exist on those perls,
and thus the value is definitely not a boolean, in the sense that the
question was asked.

-Dan