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

Re: mapping data



On Wed, Dec 10, 2003 at 12:52:09PM -0500, Kimberley Burchett wrote:
> 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.

Exactly.  The idea is to have an implementation sophisticated enough
that we don't have to lose the existing expressive power of the
language--the language is the same (except for the data translation
definition) but the domain of data we can manipulate is increased.

If you have control over the environment (as a VM does) and the data
you are accessing comes from that environment then there is little
incentive to strip away the abstractions and munge around with bits.
My guess is that the desire to separate the abstract language from
its implementation is responsible for us not seeing this addressed
more in existing languages.

The definition of a lightweight language may be elusive, but it
seems to be concerned with blending in with existing environments
well.  If you are building everything from the ground up you can
choose J2EE or .NET or something like that and require everything to
fit in that framework.  It seems to me that the area of lightweight
languages is the right place to address gluing and working with
existing data and environments.

On Wed, Dec 10, 2003 at 01:51:43PM -0500, Dan Sugalski wrote:
> It's a really major hassle once you start getting pointers to 
> structures (and pointers to arrays of pointers to structures of 
> arrays of pointers of something or other) in there.
> 
> In general it's doable with simple text descriptions of the 
> structures (which the C definitions just happen to be :) but in 
> specific it always seems to turn out to be a major pain and awfully 
> slow on top of it.

Yes, this is more what I had in mind.  Perl is a glue language, and
even it requires extra glue to get it to stick to a lot of data.

An effective solution to this problem would be handy in lots of
ways.  Want to access an old .db file?  Load the data definition and
use straightforward structural recursion to query it.  Need to pick
apart an incoming RPC request?  It's really just a simple data
structure with a specific layout, so why not use it that way?  What
about an XML parser that presents a linked list of elements?  A text
file interface that gives linked list of lines/paragraphs/words?
Think of how handy while(<FH>) is in perl and imagine generalizing
that to any kind of iterative file read.  I've heard it argued that
iterators in OOP languages are just a crutch to help those that
don't have lazy evaluation.  Here's a particular class of problems
where some laziness would be welcome.  Many imperative I/O
operations could look a lot more like functional structure
traversals (with a lot more exceptions possible and a possible loss
of repeatability, but the program structure could still have the
simplicity and elegance that we see when manipulating data
structures in functional languages).

It's not limited to I/O, of course, but that seems to be a place
where it comes up a lot.  Shared memory, mmapped files, and network
packets are the examples that come to mind where a specific data
layout is required, often by an external source.

- Russ