Dan Sugalski wrote:
> The C structure that represents a bigint is:
>
> struct bigint {
> void *buffer;
> UV length;
> IV exponent;
> UV flags;
> }
>
> =begin question
>
> Should we scrap the buffer pointer and just tack the buffer on the end
> of the structure? Saves a level of indirection, but means if we need
> to make the buffer bigger we have to adjust anything pointing to it.
>
> =end question
Absolutely not. Keep as much static-sized as possible, so you can
trivially recycle it.
Nobody much liked the suggestion of
tracking precision at the lowest levels, but here I am repeating
it anyway.
> Perl has a single internal string form:
> =item unused
>
> Filler. Here to make sure we're both exactly double the size of a
> bigint/bigfloat header and to make sure we don't cross cache lines on
> any modern processor.
Is this explicitly guaranteed to remain unused, so that it may be
safely used for arbitrary user-magic (as long as they don't step on
each others toes) and semantic analysis flags, and so forth?
Or would that kind of thing be better included into whatever is
containing these guys -- along with reference counts and other
details of additional systems which are not referred to w/in this
document.
> =item Class
>
> Class refers to a higher-level piece of perl data. Each class has its
> own vtable, which is a class' distinguishing mark. Classes live one
> step below the perl source level, and should not be confused with perl
> packages.
Does this imply that perl packages will continue to be called perl
packages,
even when they start getting introduced with a "class" keyword?
