Right so here's my current struggle.
Suppose we have a slot in RTTI:
string encode (gc_shape_t *, void *data);
The encode function can invoke memcpy, or use the copy constructor, or we can
have
a user supplied encoder for string (e.g write length, write contents)
however we also have to replicate if we're an array. This could be done by the
encode function. Or it could be done by the master serialiser with a loop.
The latter is obviously more reliable (program it once).
So the serialiser will do something like:
make an array of strings for each element encoding
write out the number of elements
write out the total length of the object
write out the max bound
write out the encoding length
write out the rtti pointer (so we can get the decoder).
write all the strings
So we have some fixed data (4 integers and a pointer),
and then the encoded elements. Remember every thing is an
array in Felix.
This actually means the shape is not needed by the encode
(or decode) functions.
The decoder reads the header block, allocates some memory,
sets up the array control parameters, then calls the decode
function repeatedly to flll in the memory.
This codex a primitive.
But what if it's a Felix struct containing pointers?
How does the codex interact with the pointer management system?
the way I set it up the codex has to serialise the whole object,
so it has to call the pointer translator or something.
This is weird because the encoded data has to contain
translated pointers, but they cannot be back-patched
into an arbitrary encoding.
This problem "goes away" if we use the aggregate representation
of structs (as a list of component RTTI objects).
Note something interesting! At the moment offsets to pointers
just say "there's a pointer here in the object". The type that
it points to can only be established by lookup. Even a slot
marked for a Felix pointer does NOT have to contain a Felix
pointer, a foreign pointer is fine too. Or NULL. Or anything at all
that cannot be construed as pointer into a Felix allocated object.
The GC simply won't track down such pointers.
This is dynamic typing.
It is USELESS for making new values though.
Now suppose instead of an array of objects, we have instead
an array of pairs:
offset, shape
This basically says "the pointer at this offset has this type".
This is a whole new ballgame. Suddenly we have STATIC TYPING.
This does not mean the compiler knows the type!!!
It means the type is not discovered by examining the object
pointed at. It cannot be anything: the type is fixed.
What we have is dynamic meta-typing but static typing!
Think about a Python List:
x = [1, "hello", 2.3]
y = x # copy reference NOT value
The static type of x is PyObject. The run time type
of the variables is dynamic.
But the list value, has a STATIC but crude type.
It is NOT merely a PyObject. Its a List. It's not
dynamic. The type of the value is immutable.
It's always a List. It cannot become a Tuple or
an Integer (even though the variables can).
What makes the typing dynamic is that List is not
the value type. The value type is actually
List of Integer, String, Float
and the component types CAN change, in other words
the complete and *precise* type of the value is dynamic,
though it is constrained (always a List).
Contrast that to the Felix model offset,shape.
We have a structure where the types of the components pointed
at by pointers is no longer dynamically typed. The type is precise
and fixed. The typing is static.
This is not what most people think static vs dynamic means
but as usual I AM RIGHT.
Static means "unchanging". Thats the meaning of the word.
Dynamic means "changing".
It has nothing to do with compile time vs run time.
With the offset, shape thing and software that can
build type descriptors at run time, we have dynamic
meta-typing but we still have *static* typing.
The typing is only dynamic if we leave the types out
of the offset list (as at present).
What does this all mean? Well, to properly handle serialisation
we have to switch to the aggregate of primitives as a list.
And then we get static typing on a pointer if we specify
the pointer type, or dynamic typing if we leave it open.
We can also get "constrained dynamics" using variants.
[Variants already allow functional languages like Ocaml
to have dynamic typing, but its constrained to a fixed
collection which allows use of a index instead of a pointer]
Which ever we we need:
an encoding of arrays (we already have this)
an encoding for structs (list of component shapes)
an encoding for pointers
and we will have to handle variants too (very scared of this:)
Ideally, this data structure, which is basically a conventional
AST (term tree) would be encoded in Felix rather than C.
In particular, pointers would be represented by actual
Felix variants.
This would be a nighmare for the GC to handle .. unless it
is rewritten in Felix :)
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
