At 04:26 PM 8/12/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: This way perl doesn't, for example, have to know how to access an
>: individual element of an array of integers--it just asks the array to
>: return it a particular element. Code MUST use the vtable functions to
>: get or set values from variables. They MUST NOT directly access the data.
>
>Fine, though we'll have to decide how indexes and keys get passed in to
>these functions (vfuncs?). We could pass such parameters on the stack
>or as function arguments. At a guess, we'll end up providing both
>APIs. Which API will be more basic is anyone's guess. 'Course, this
>is outside the scope of this RFC anyway.
I was figuring on function arguments for the vtable code, since it's so
low-level. I'm also wondering if we want to make a distinction between
hashes and arrays from the API level way down low. (Gut feel says "yes",
but I've got this nagging at the back of my brain that says its not
necessary. Or it could just be a caffeine headache, I'm not sure)
>: This base structure should be considered immobile, so it's safe to
>: maintain pointers to it. The data portion of a variable should be
>: considered moveable, and may be shuffled around if a variable changes
>: its type, or the garbage collector needs to compact the heap.
>
>If it's only compacting the heap, I don't know whether I'd call it "the
>garbage collector". Catching cycles has to involve the PMCs too.
Well, I assumed the GC would find unused variable structures and nuke 'em
properly, handling heap compaction and all. (I'm tempted to have all the
variable base structures allocated in a set of arenas to make life easier
for the GC code--it treats 'em as a bunch of arrays and can just trot
through them looking for live and dead data)
We've talked about GCs that go move live data around, but that makes moving
live base structs problematic, since there could be pointers to them in
external code. The actual variable data hanging off the "Hang data off
here" field, though, is free game for the heap compactor even if the
variable's still alive.
>: =item GC_data
>:
>: Random data for the garbage collector, whichever one is used. This
>: could be a marker for M&S GC, or a refcount for refcount GC, or just
>: nothing at all if we get a really clever GC.
>
>We'll need to decide if we're really going to make people release their
>PMC pointers explicitly. This is required for refcount GC, and can
>help some forms of "real" GC do their work more efficient, but slows
>down other forms of GC.
Yeah. I've been wondering if external code will need to 'register' any
variables they've created but aren't in the interpreter's data structures
anywhere. Threads'll need this too for shared variables, so I'm thinking we
can dovetail the two together somehow.
>: =item vtable
>:
>: The vtable field holds a pointer to the vtable for a variable. Each
>: variable type has its own vtable, holding pointers to functions for
>: the variable. Vtables are shared between variables of the same
>: type. (All integer arrays have the same vtable, as do all string
>: scalars and so on)
>
>I think that last statement is false. I think strings will have
>several vtables depending on their format. (So might integers, if we
>decide to stitch in bigints.)
Yeah, at this point this has gotten a bit past that. All ints will, by
default, point to the int vtable, but we'll have a mechanism to clone
vtables for messing about with if code needs to make the variable behave in
some unique way. (These custom vtables can be shared, of course, if code's
creating another generic type)
If a variable gets turned into a different type (like an int gets promoted
to a full scalar, say), the vtable gets replaced with the one appropriate
for the new type once the conversion happens.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
