RFC: Double the number of SV types

There are 4 unused bits available.

I propose we use one of them to double the number of SV types, giving us 
16 unused ones.

One that Paul Evans would like is an exception object.

I can imagine a zombie type could be used to aid in tear-down, 
eliminating bugs we have there.

I don't remember all the other proposals, floated over the years, and 
some may not be viable.  But I think that now is the time to enable 
serious use cases to be implemented.
0
public
10/30/2019 9:26:50 PM
perl.perl5.porters 48082 articles. 1 followers. Follow

4 Replies
65 Views

Similar Articles

[PageSpeed] 12

On Wed, 30 Oct 2019 15:26:50 -0600
Karl Williamson <public@khwilliamson.com> wrote:

> One that Paul Evans would like is an exception object.

Semi-jokingly, though it could be interesting to come up with an
almost-string except it can be detected as some standard "perl
exception type" and queried on. Though maybe Magic can do that.

Another idea I had was to give a real native "object" type, which isn't
just a blessed array/hash/...

> I can imagine a zombie type could be used to aid in tear-down, 
> eliminating bugs we have there.

A ZV :) We're going to run out of letters...

> I don't remember all the other proposals, floated over the years, and 
> some may not be viable.  But I think that now is the time to enable 
> serious use cases to be implemented.

I think there were suggestions that it might be possible to use some SV
type to remember whether a given value was originally a number vs. a
string. Noting that currently an SVt_IV or NV are "just a number"
and an SVt_PV is "just a string", then you only need to be able to
distinguish SVt_PVnV_orig_number vs. SVt_PVnV_orig_string. That would
only require two more types than we have now, rather than the idea of
eating into more of those flags.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
10/31/2019 4:26:42 PM
--0000000000008e415d05963850b4
Content-Type: text/plain; charset="UTF-8"

On Thu, 31 Oct 2019, 17:26 Paul "LeoNerd" Evans, <leonerd@leonerd.org.uk>
wrote:

> On Wed, 30 Oct 2019 15:26:50 -0600
> Karl Williamson <public@khwilliamson.com> wrote:
>
> > One that Paul Evans would like is an exception object.
>
> Semi-jokingly, though it could be interesting to come up with an
> almost-string except it can be detected as some standard "perl
> exception type" and queried on. Though maybe Magic can do that.
>
> Another idea I had was to give a real native "object" type, which isn't
> just a blessed array/hash/...
>
> > I can imagine a zombie type could be used to aid in tear-down,
> > eliminating bugs we have there.
>
> A ZV :) We're going to run out of letters...
>
> > I don't remember all the other proposals, floated over the years, and
> > some may not be viable.  But I think that now is the time to enable
> > serious use cases to be implemented.
>
> I think there were suggestions that it might be possible to use some SV
> type to remember whether a given value was originally a number vs. a
> string. Noting that currently an SVt_IV or NV are "just a number"
> and an SVt_PV is "just a string", then you only need to be able to
> distinguish SVt_PVnV_orig_number vs. SVt_PVnV_orig_string. That would
> only require two more types than we have now, rather than the idea of
> eating into more of those flags.
>

I'm with on everything but maybe the flags/type conflation. I believe we
can and should use the existing flag bits more intelligently without
needing new types.

I'm especially supportive of a true object type.

Yved



> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>

--0000000000008e415d05963850b4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Thu, 31 Oct 2019, 17:26 Paul &quot;LeoNerd&quot; Ev=
ans, &lt;<a href=3D"mailto:leonerd@leonerd.org.uk">leonerd@leonerd.org.uk</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 30 Oct 2019 1=
5:26:50 -0600<br>
Karl Williamson &lt;<a href=3D"mailto:public@khwilliamson.com" target=3D"_b=
lank" rel=3D"noreferrer">public@khwilliamson.com</a>&gt; wrote:<br>
<br>
&gt; One that Paul Evans would like is an exception object.<br>
<br>
Semi-jokingly, though it could be interesting to come up with an<br>
almost-string except it can be detected as some standard &quot;perl<br>
exception type&quot; and queried on. Though maybe Magic can do that.<br>
<br>
Another idea I had was to give a real native &quot;object&quot; type, which=
 isn&#39;t<br>
just a blessed array/hash/...<br>
<br>
&gt; I can imagine a zombie type could be used to aid in tear-down, <br>
&gt; eliminating bugs we have there.<br>
<br>
A ZV :) We&#39;re going to run out of letters...<br>
<br>
&gt; I don&#39;t remember all the other proposals, floated over the years, =
and <br>
&gt; some may not be viable.=C2=A0 But I think that now is the time to enab=
le <br>
&gt; serious use cases to be implemented.<br>
<br>
I think there were suggestions that it might be possible to use some SV<br>
type to remember whether a given value was originally a number vs. a<br>
string. Noting that currently an SVt_IV or NV are &quot;just a number&quot;=
<br>
and an SVt_PV is &quot;just a string&quot;, then you only need to be able t=
o<br>
distinguish SVt_PVnV_orig_number vs. SVt_PVnV_orig_string. That would<br>
only require two more types than we have now, rather than the idea of<br>
eating into more of those flags.<br></blockquote></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">I&#39;m with on everything but maybe the fl=
ags/type conflation. I believe we can and should use the existing flag bits=
 more intelligently without needing new types.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">I&#39;m especially supportive of a true object type.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">Yved</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Paul &quot;LeoNerd&quot; Evans<br>
<br>
<a href=3D"mailto:leonerd@leonerd.org.uk" target=3D"_blank" rel=3D"noreferr=
er">leonerd@leonerd.org.uk</a>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 <a href=3D"https=
://metacpan.org/author/PEVANS" rel=3D"noreferrer noreferrer" target=3D"_bla=
nk">https://metacpan.org/author/PEVANS</a><br>
<a href=3D"http://www.leonerd.org.uk/" rel=3D"noreferrer noreferrer" target=
=3D"_blank">http://www.leonerd.org.uk/</a>=C2=A0 |=C2=A0 <a href=3D"https:/=
/www.tindie.com/stores/leonerd/" rel=3D"noreferrer noreferrer" target=3D"_b=
lank">https://www.tindie.com/stores/leonerd/</a><br>
</blockquote></div></div></div>

--0000000000008e415d05963850b4--
0
demerphq
10/31/2019 5:38:04 PM
--000000000000592a600596394a6c
Content-Type: text/plain; charset="UTF-8"

On Fri, 1 Nov 2019 at 00:26, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Wed, 30 Oct 2019 15:26:50 -0600
> I think there were suggestions that it might be possible to use some SV
> type to remember whether a given value was originally a number vs. a
> string. Noting that currently an SVt_IV or NV are "just a number"
> and an SVt_PV is "just a string", then you only need to be able to
> distinguish SVt_PVnV_orig_number vs. SVt_PVnV_orig_string. That would
> only require two more types than we have now, rather than the idea of
> eating into more of those flags.
>

Instead of limiting to "number" vs. "string", perhaps a single TV "typed
(scalar) value"? That'd leave room for additional metadata stored
elsewhere, and would give a clear field for implementing whatever structure
is needed to handle types in core.

Number/string is helpful for some Perl ops, but still isn't very clear...
int/float/unsigned? Unicode vs. bytestring?

--000000000000592a600596394a6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, 1 Nov 2019 at 00:26, Paul &qu=
ot;LeoNerd&quot; Evans &lt;<a href=3D"mailto:leonerd@leonerd.org.uk">leoner=
d@leonerd.org.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">On Wed, 30 Oct 2019 15:26:50 -0600<br>I think there were su=
ggestions that it might be possible to use some SV<br>
type to remember whether a given value was originally a number vs. a<br>
string. Noting that currently an SVt_IV or NV are &quot;just a number&quot;=
<br>
and an SVt_PV is &quot;just a string&quot;, then you only need to be able t=
o<br>
distinguish SVt_PVnV_orig_number vs. SVt_PVnV_orig_string. That would<br>
only require two more types than we have now, rather than the idea of<br>
eating into more of those flags.<br></blockquote><div>=C2=A0</div><div>Inst=
ead of limiting to &quot;number&quot; vs. &quot;string&quot;, perhaps a sin=
gle TV &quot;typed (scalar) value&quot;? That&#39;d leave room for addition=
al metadata stored elsewhere, and would give a clear field for implementing=
 whatever structure is needed to handle types in core.</div><div><br></div>=
<div>Number/string is helpful for some Perl ops, but still isn&#39;t very c=
lear... int/float/unsigned? Unicode vs. bytestring?</div><div><br></div></d=
iv></div>

--000000000000592a600596394a6c--
0
perl5
10/31/2019 6:47:57 PM
On 10/31/19 12:47 PM, Tom Molesworth via perl5-porters wrote:
> 
> 
> On Fri, 1 Nov 2019 at 00:26, Paul "LeoNerd" Evans 
> <leonerd@leonerd.org.uk <mailto:leonerd@leonerd.org.uk>> wrote:
> 
>     On Wed, 30 Oct 2019 15:26:50 -0600
>     I think there were suggestions that it might be possible to use some SV
>     type to remember whether a given value was originally a number vs. a
>     string. Noting that currently an SVt_IV or NV are "just a number"
>     and an SVt_PV is "just a string", then you only need to be able to
>     distinguish SVt_PVnV_orig_number vs. SVt_PVnV_orig_string. That would
>     only require two more types than we have now, rather than the idea of
>     eating into more of those flags.
> 
> Instead of limiting to "number" vs. "string", perhaps a single TV "typed 
> (scalar) value"? That'd leave room for additional metadata stored 
> elsewhere, and would give a clear field for implementing whatever 
> structure is needed to handle types in core.
> 
> Number/string is helpful for some Perl ops, but still isn't very 
> clear... int/float/unsigned? Unicode vs. bytestring?
> 

Rather than let this just get lost, I have doubled the number of types 
via commit 90ba01ad5da73731a55047c417c339b68778d7ef

That leaves 3 unused bits, and as Yves suggested we can probably better 
use some of the existing bits.

But now we can actually create new types.  And argue over what is 
appropriate.  As usual real code wins over vaporware.
0
public
11/16/2019 12:59:12 PM
Reply: