[<<][libprim][>>][..]
Wed Nov 4 07:49:31 CET 2009

Are classes/types global?

I guess the answer is yes.  C objects contain pointers to C classes,
but the classes themselves do not really need to be tied to the VM
instance.

The real question is: what is a VM instance?

Let's reformulate: each VM has its own memory manager (GC).  This
means that managed data cannot be exchanged between VMs.

Really, a VM is kind of a global variable.

Why is there a need to reference the base_types struct?  Let's look at
the macros that use it:

#define DEF_ATOM(name)                                                \
    static inline name *object_to_##name(object ob, ex *m) {          \
        return (name*)object_struct(ob,m->p->name##_type); }

This essentially maps `name' to a pointer to its associated class/type
object for use in the `object_struct' function, which is the main
function that determines if an object matches a type, and returns a
pointer or NULL.

There is no real reason why m->p->name_FOOTYPE shouldn't be
globalvar_FOOTYPE, apart from global variable references being more
expensive.

So..  How to make the scheme interpreter extensible?  Can these core
implementation issues be hidden from user extensions?  The whole point
is to be able to simply wrap some C/C++ code..

Let's stick with:

  - interface: class_new() methods in the C code, to allow for most
    general approach.

  - policy: (static) global variables for class objects in extensions





[Reply][About]
[<<][libprim][>>][..]