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

Re: vstring guidance needed

Thread Previous | Thread Next
From:
Rafael Garcia-Suarez
Date:
August 20, 2001 07:32
Subject:
Re: vstring guidance needed
Message ID:
20010820163744.C763@rafael

On 2001.08.20 15:21:01 +0200 John Peacock wrote:
> 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.

Beware : $] stores both an NV and a PV for performance only -- to avoid
conversions. This is similar to a SV that holds an NV and also has been
used in string context. With perl 5.6.1 :

$ perl -MDevel::Peek -e 'Dump $]'
SV = PVNV(0x80f1030) at 0x80fb160
  REFCNT = 1
  FLAGS = (NOK,POK,READONLY,pNOK,pPOK)
  IV = 0
  NV = 5.006001
  PV = 0x8100a60 "5.006001"\0
  CUR = 8
  LEN = 10

As you see the PV is not a version string. The version string is in $^V, but $^V
has also the numerical value :

$ perl -MDevel::Peek -e 'Dump $^V'
SV = PVNV(0x80f0dd8) at 0x80f017c
  REFCNT = 2
  FLAGS = (NOK,POK,READONLY,pNOK,pPOK,UTF8)
  IV = 0
  NV = 5.006001
  PV = 0x80f53b0 "\5\6\1"\0
  CUR = 3
  LEN = 5

> > > Do we want this:
> > >
> > > SV = PV(0xa011468) at 0xa01f7c8
> > >   REFCNT = 1
> > >   FLAGS = (POK,READONLY,pNOK,pPOK)
> > 
> > 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.

Well, modesty doesn't necessarily generates good design -- try hubris ;-)

> > > 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.

You can't ensure this at compile-time only. Example : $scalar < $^V will
yield a problem : the compiler will need to know that $^V contains a vstring. And
this is a simple example. Looks like you will need to forget version comparison
with '<', or introduce a new type of magic (better than a VOK flag or messing with
pNOK). In fact, '<' for now works only for the vstring held in $^V.

My advice would be to factorize the vstring code, but avoid to work on such
functionality without clearly defining the needs and the goals. '<'
doesn't need to work with vstrings.

-- 
Rafael Garcia-Suarez

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