[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mapping data




On Tue, 9 Dec 2003, Russ Ross wrote:

> One of the barriers to using lightweight languages for many
> low-level tasks is the difficulty in interfacing with data from an
> outside source.  C is pretty good at this since you can define a
> data structure (including C's union types) and map it to memory that
> came from anywhere.  I'm curious about other solutions to this
> problem, particularly in integrating with the type systems of high
> level languages.

The obvious answer to your question is to point at virtual machines that
have a higher-level semantics than the CPU, like .NET or Parrot.  By
targeting a common virtual machine, different language implementations
don't have to reinvent high-level concepts, and therefore they don't end
up reinventing them in incompatible ways.  So interoperability is simple.

In fact, C is a degenerate case of this -- it happens to use the CPU
itself as its VM, and since all language implementations have to translate
into machine code eventually, C can interoperate with them at that level.  
Machine code is C's "native language", as it were.

However it sounds like you want some kind of procedural mechanism, or
static type-system, that will let one language "understand" how to work
with other another language, *in place*.  I think the problem with this
idea is that you're conflating the idea of the language itself with the
language's implementation.  These two things live at different levels, and
in order to explain one from within the other, you'd have to combine the
levels in a way that would seriously impact issues of separation of
concerns.

I'll elaborate.  Obviously a single language can have many
implementations, and each implementation will probably make different
design decisions about how to represent program structures at runtime.  
So a program in a given language doesn't necessarily even know how *it*
will be represented at runtime, unless it knows what implementation it
will be run on.  In order to explain how to interoperate at the binary
level, you'd have to introduce some concept of a machine model
*underlying* the language -- and not just a single underlying model, but
many, depending on the language implementation and the hardware
architecture.

So the question is kind of equivalent to asking whether anybody has done
any research into extending the HTTP protocol so that it can explain how
to interoperate between TCP/IP and AppleTalk.  I'm not saying it can't be
done, just that it may not be a good idea.


Kimberley Burchett
http://www.kimbly.com/