On Wed, Dec 20, 2000 at 02:26:12PM +0000, David Mitchell wrote:
> Has anyone given thought to how an SV can contain both a numeric value
> and string value in Perl6?
> Given the arbitrary number of numeric and string types that the vatble
> scheme of Perl6 support it will be unviable to to have special types
> for all permuations (eg, utf8_nv, unicode32_iv, ascii_bitint, ad nauseum).
>
> It seems to me the following options are poossible:
>
> 1. We no longer save conversions, so
> $i="3"; $j+=$i for (...);
> does an aton() or similar each time round the loop
I fear this would be a performance hit. I'm told TCL pre version 8 was
like this - everything's a string and converted to a number each and every
time the number is needed.
> 2. Each SV has 2 vtable pointers - one for it's numeric representation
> (if any), and one for its string represenation (if any). Flexible, but
> may require an extra 4/8 bytes per SV.
It may not be terrible. How big is the average SV already anyway?
> 3. We decree that all string to numeric conversions should return
> a particular numeric type (eg NV), and that all numeric to string
> conversions should similary convert to a fixed string type (eg utf8).
> (Although I'm not sure that really helps.)
Feels like a bad plan, as it can be that no single intrinsic type
(ie one native to the compiler of the implementation language) is
a superset of all the others
(eg a platform with 64 bit integers, and the longest floating point type
being 64 bit)
> 4. Err, that's it.
If vtables are held in a common pool (garbage collected?) with the
flexibility to allow every scalar to potentially have its own, then I
think there's possibility 4.
vtables have subsections, so all the numeric operations are in a subsection,
all the string operations in another.
At most you have (number of numeric types) * (number of string types)
vtables, but actually you just create a new table with the appropriate
numeric & string subsections every time you cause a numeric or string
conversion to a pair this-sort-of-string,that-sort-of-number that you've
not seen before. So there's still only 1 vtable pointer per scalar.
This will slow things down if you attempt to add
double-ascii to double-UTF8, as the if (vtable_a == vtable_b) won't be
true, but it could be possible to store a token in each subsection to
say what it was, so then you get
if(vtable_a == vtable_b || vtable_a->num_type == vtable_b->numtype) {
/* It's the same sort of number in each */
} else {
/* bah. generic logic needed */
}
numtype is NULL (or "string") or something token but different from all
real numbers if the scalar isn't a number, which will prompt numeric
conversion to the best sort of number as need-be. (so "3.1 + 5i" would do
the right thing. presumably complex floating point)
And (like perl5) if you alter a numeric scalar as a string, it
becomes just a string
[so {(3.1 + 5i) . ''} is a string]
Nicholas Clark
