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

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1160428293.860471.264280_at_m73g2000cwd.googlegroups.com...
> On Oct 9, 8:58 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> >
> > > There are various different approaches one can take for embedding
> > > a domain specific lanuage into a general purpose programming language.
> > > Common examples are regular expression libraries inside languages
> > > that don't directly support regular expressions, and, directly to our
> > > purpose, SQL inside Java or C/C++.
> >
> > > The three main approaches I can think of are:
> >
> > You forgot 4) Use a compiler that directly compiles the data sublanguage
> > and uses the same data type system as the dbms.
>
> Sure; that's the way forward. However, that approach will *also* have
> to
> consider compatibility with legacy languages and systems. And for that,
> you're going to need some other strategy, such as the ones I
> enumerated.

Bob's reply is right on the money.

There is no particular reason why a language couldn't embrace both the functions and operations needed for relational data manipulation and also the functions and operations needed for general purpose programming tasks. There is no particular reason why such a language shouldn't be developed.

How quickly such a language would be adopted by either DBAs or programmers remains to be seen.

I'm not sure about legacy systems. Can you explain that in a little more detail?

>
> Anyone have any opinions, pro or con, about embedded SQL?
>
>
> Marshall
>
Received on Wed Oct 11 2006 - 03:18:50 CEST