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

Re: vstring guidance needed

Thread Previous | Thread Next
John Peacock
August 20, 2001 06:43
Re: vstring guidance needed
Message ID:
Rafael Garcia-Suarez wrote:
> On 2001.08.17 19:18 John Peacock wrote:
> > I discovered where PL_patchlevel is being set and I can deal with it
> > by making it call new_vstring, but it sort of begs the question:
> >
> An idea: Have you checked back the p5p archives, when the vstrings were
> introduced?

I tried to check the archives, but found precious little information.
I was hoping that someone who knew something one way or the other would 
speak up.

> > Internally, do we want to store a PV only, and make all version code
> > use cmp, lt, eq, etc., or do we want to continue to store both a
> > NV numeric representation and a SV (U8) representation?
> I believe that the NV is only constructed for vstrings (or version strings,
> the difference you make between the two is not clear to me) used in 'use'
> and 'require' statements.

Version strings are stored in vstrings; vstrings can also hold 
arbitrary Unicode data points (so says perl56delta.pod).  In fact, 
since that section is titled "strings represented as a vector of
ordinals" I think I have to take that as my answer: V-Strings are
strings not numbers.

Actually, the bit in perl.c which sets up the $] system variables
sets both PV and NV for the Perl version.  I'll be changing that to
call the new_vstring code instead.

> > Do we want this:
> >
> > SV = PV(0xa011468) at 0xa01f7c8
> >   REFCNT = 1
> I don't understand why pNOK is set here. Did your implementation used
> a numerical representation while constructing the SV? Looks like the
> shadow of a bug to me.

By design, actually.  I need a way to hint that the PV is actually a
version string, so my current code sets pNOK as a way to imply that 
there is something special about this SV.  I assume that it would be a
bit presumptious of me to create a new flag VOK for a version string.

> snippage
> > I am willing to go either way.  It would be nice for both
> >
> >       $vstring < v1.2.3     and      $vstring lt v1.2.3
> >
> > to yield the same answer.  What do people think, given that vstrings
> > are also intended to be used to code UNICODE strings?
> Well, PV can be of an arbitrary length, while NV can't. That would speak
> against the NV. On the other hand, I don't see how "$scalar < v1.2.3"
> would work without an NV (or IV) equivalent of the vstring PV.

This is a very good point, and one I wish I had thought of myself.  It
pretty much clinches it for me that v-strings have to be strings and 
not numbers.  And, as far as "$scalar < v1.2.3" goes, I am going to 
try and convince the parser to change that to "$scalar lt v1.2.3" on
the fly.



John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About