Re: approaches for embedding a data language in a general purpose language

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1160493317.689895.82540_at_h48g2000cwc.googlegroups.com...
> On Oct 10, 5:03 am, "David Cressey" <dcres..._at_verizon.net> wrote:
> > "Marshall" <marshall.spi..._at_gmail.com> wrote in
messagenews:1160406756.523915.48510_at_m73g2000cwd.googlegroups.com...
> >
> > > The three main approaches I can think of are:
> > > 1) a library that accepts text written in the language as string
> > > parameters
> > > ex.: JDBC, ODBC
> >
> > > 2) Code generation
> > > ex.: Hibernate, any one of ~1000 O/R mappers
> >
> > > 3) Direct embedding using a preprocessor
> > > ex.: SQL-J, embedded SQL (for C) etc.
> >
> > > I've used the first two extensively, but never the third one. I've got
> > > the nagging suspicion that it's the one I would like the best. (Of
> > > course
> > > one must immediately suspect grass-is-greener syndrome here.)
> >
> > But I don't think embedded source necessitates record at a time thinking
to
> > the extent that you suggest.
>
> Actually, it was my intent to say that code generation and ORM
> approaches push the programmer in the direction of record-at-a-time
> and that embedded data languages don't, or do so much less.
>
>
> > Anyway, if you'd like to hear more of my ramblings on the subject,
> > I'm ready.
>
> Let's hear it! I'm all ears.
>
>
> Marshall
>

OK.

Here's the short version: the relationship between source languages and target machines is many-to-many even though most of compiler design tends to make us think it's a one-to-one relationship.

As an example of a single source language giving rise to more than one target machine, I'll offer a compiler that intermixes machine language operations with system calls. Some people are sure to point out that system calls are themselves machine language operations, but that misses the point. The point is that the compiler uses CPU operations to realize some of the operations to be performed, and system services to realize other operations.

As an example of several source languages giving rise to code on the same target machine, I'll point to either VAXen, or old mainframes that used two stages of translation, where the second stage was generally called "linking". In VAX/VMS, the various compilers and assemblers all produced what were called "object modules", stored in OBJ files. The LINK utility read OBJ files and libraries (I've forgotten the file type) to produce EXE files.

Anyway, embedded SQL and precompilers made use of the above in order to eventually yield an EXE file. The details are lengthy, and aren't necessarily the way you would implement things today. Still, the history is kind of interesting. Received on Wed Oct 11 2006 - 02:53:15 CEST