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

Re: Pre-RFC: Real "boolean" SV type

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
August 5, 2021 10:53
Subject:
Re: Pre-RFC: Real "boolean" SV type
Message ID:
20210805105251.GL11066@etla.org
On Thu, Aug 05, 2021 at 11:42:21AM +0100, Paul "LeoNerd" Evans wrote:
> On Thu, 5 Aug 2021 07:29:15 +0000
> Nicholas Clark <nick@ccl4.org> wrote:

> > And for certain operations, the *value* needs to pass through a PVLV
> > without loosing it's "I'm a boolean"-ness. I think tied hashes; but
> > certainly this;
> 
> Ahyes; you're both right of course, for exactly the same reasons as my
> previous suggestion about SVt_PV_was_IV vs SVt_IV_was_PV. You'd think
> after that first one I'd learn, but no... ;)

Third time lucky? :-)

I realised (after I sent the mail) that for scalars it's something like

"SV types are about storage"
"flags are about values"

and hence (for scalars) as values are getting copied, it's the values that
need to hold this (meta)information

Whereas, for aggregates, all the XS tests are for things like

    SvTYPE(hv) == SVt_PVHV

meaning that until C(42+5i) adds junctions as a fundamental type, we're
stuck with "hashes and symbol tables have to have a single common type"
(similarly all the things that AVs want to play at)

> I'll mention that in the RFC and point out it really does need a flag -
> SvBOK() or somesuch?

It might be possible to implement *without* a flag, as I postulated,
using PL_Yes and PL_No, and some changes to sv_setsv_flags.

(Which will need to be changed come-what-may to deal with booleans)

So I think it "really does" is not correct - "might" is more accurate.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About