On Oct 7, 2007, at 10:20 PM, James McCartney wrote:
Does anybody want to address this comment made on LtU about "what
things are not easily possible"?
I made the comment. I just joined this list. I'd be interested to see
a response there or here.
The dependency on the C compiler is temporary. Using C as a (bad)
structured assembler is useful for bootstrapping and portability, but
is clearly inadequate for building interesting runtime mechanisms.
Compatibility with native conventions is useful for interoperating
with libraries and the OS, but the ultimate goals are more general.
We want to support heap-allocated contexts and spaghetti stacks, be
able to precisely trace pointers in the stack, and be able to
communicate with activation frames by sending them messages as real
objects. Knowing the layout of stack frames and 'objectifying' C
stack-allocated frames isn't hard (when the C compiler is replaced
with something more intelligent) and we have some ideas about dealing
with calling C library and OS functions (where stack resources are
assumed to be relatively unbounded) from heap-allocated contexts, but
ideas and pointers (and eventually code) would be very welcome. My
hope is that useful departures from the C ABI can be made in ways
that subsume, but do not conflict with, the limited conventions
imposed by calling out to foreign code. Being able to easily
experiment with alternative ABIs at the instruction level will
hopefully foster innovation in these areas.
The object model is the simplest that could be used to bootstrap some
of the ideas. Limiting the dispatch to discriminating on the first
argument is a severe limitation that has to be dealt with soon (it's
already causing problems). Fixing this is part of a larger
generalisation and unification of the roles of object, message name,
and function that is planned but not yet implemented. In particular,
message/function names and selectors should be distinct objects --
with selectors and types(/classes/whatever) having equal influence in
determining and encapsulating behaviour. Selectors will be involved
in determining the code emitted for their own call sites, subsuming
the generic function-like behaviour you mention, bringing message
dispatch and function application together as a single operation with
no limits to the complexity of binding, dispatch and application
mechanisms involved.
I hope some of that makes sense. I could paraphrase like this: we've
genetically engineered 1/3rd of a franken-chicken that is missing
lots of body parts but that we hope can be coerced into laying eggs
that hatch into increasingly more complete franken-chickens, and
eventually eggs for any species you like -- feathered or not. What
you are seeing today is missing the (far) more interesting 2/3rds
that hide the non crippled-chicken possibilties.
Cheers,
Ian
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
