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 47862 articles. 1 followers. Follow

3 Replies
22 Views

Similar Articles

[PageSpeed] 33

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
Reply: