Embedded Languages in C++? - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Embedded Languages in C++?

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

xmp333@yahoo.com
Guest

Posted: Wed Jan 28, 2004 2:19 pm Post subject: Embedded Languages in C++?

Hi, I am interested in learning more about writing Embedded Languages -- especially Domain Specific Embedded Languages, and especially in C/C++. In particular, I'm looking for the difference between an Embedded Language and a function library (what little I found didn't stress this), a down to earth analysis of pros and cons, and some examples or techniques for use. I tried searching the web, but information was hard to come by, and what little I found was focused on functional languages. Any pointers to information (online or in book format) would be greatly appreciated. Thanks, Ahmed [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Thant Tessman
Guest

Posted: Thu Jan 29, 2004 9:36 am Post subject: Re: Embedded Languages in C++?

[email]xmp333 (AT) yahoo (DOT) com[/email] wrote:

Quote:

I am interested in learning more about writing Embedded Languages --
especially Domain Specific Embedded Languages, and especially in
C/C++. In particular, I'm looking for the difference between an
Embedded Language and a function library (what little I found didn't
stress this), a down to earth analysis of pros and cons, and some
examples or techniques for use.

Let me offer a definition of "embedded programming language". Feel free
to shoot it down.

An embedded programming language is intended to add the benefits of
interactive programming to an application written primarily in a
non-interactive programming language. That is, an embedded language
serves as an interface to a running application.

This is not to be confused with a programming language for embedded systems.

You could write an interpreter for your embedded language in your
primary language, or you could find a pre-existing language
implementation with good interface support for your primary language. An
embedded language implementation might take the form of a function
library. That is, the embedded language might be a set of function calls
you link into your application. (This might be the source of the
ambiguity over the difference between an embedded language and a
function library.) Or the implementation might itself be an application
in which you dynamically link your domain-specific code.

Interactive programming languages that support the ability to interface
with code written in C are fairly common. Implementations that leverage
the strengths of C++ over C are rarer and trickier. For what it's worth,
here's my attempt: <http://www.standarddeviance.com/sigma> It's
incomplete mainly in the sense that it's undocumented. Also, my design
emphasized robustness and flexibility over performance in the sense that
I avoided optimizations that decreased the language's expressiveness or
complicated the interface to C++.

Quote:

I tried searching the web, but information was hard to come by, and
what little I found was focused on functional languages.

One of the strengths of the functional programming paradigm is that it
can simultaneously allow for conciseness, expressiveness, and a small
implementation--all traits desirable in an embedded language.

Quote:

Any pointers to information (online or in book format) would be
greatly appreciated.

Depends on whether you really want to write your own embedded language
or merely put some other langauge to use as an embedded language. If the
latter, I've seen Python or Ruby recommended. I prefer Scheme because
more than any other language (with the possible exception of Common
Lisp) it is expressive enough to shape into a custom domain-specific
language. But Python and Ruby have a bigger user base if that turns out
to be important.

-thant

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Abrahams
Guest

Posted: Thu Jan 29, 2004 10:02 am Post subject: Re: Embedded Languages in C++?

[email]xmp333 (AT) yahoo (DOT) com[/email] writes:

Quote:

Hi,

I am interested in learning more about writing Embedded Languages --
especially Domain Specific Embedded Languages, and especially in
C/C++. In particular, I'm looking for the difference between an
Embedded Language and a function library (what little I found didn't
stress this), a down to earth analysis of pros and cons, and some
examples or techniques for use.

I tried searching the web, but information was hard to come by, and
what little I found was focused on functional languages.

Any pointers to information (online or in book format) would be
greatly appreciated.

Aleksey Gurtovoy and I are writing a book on template metaprogramming
in C++ which includes in-depth treatment of DSELs. It should be out
later this year from Addison Wesley. Of course, that doesn't help you
now. I suppose you've seen Jon Bentley's "programming pearls" article
from the ACM?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Abrahams
Guest

Posted: Thu Jan 29, 2004 6:55 pm Post subject: Re: Embedded Languages in C++?

Thant Tessman <thant (AT) acm (DOT) org> writes:

Quote:

xmp333 (AT) yahoo (DOT) com wrote:

I am interested in learning more about writing Embedded Languages --
especially Domain Specific Embedded Languages, and especially in
C/C++. In particular, I'm looking for the difference between an
Embedded Language and a function library (what little I found didn't
stress this), a down to earth analysis of pros and cons, and some
examples or techniques for use.

Let me offer a definition of "embedded programming language". Feel free
to shoot it down.

An embedded programming language is intended to add the benefits of
interactive programming to an application written primarily in a
non-interactive programming language. That is, an embedded language
serves as an interface to a running application.

Thant,

It's not a bad definition; it just happens to conflict with the
existing one ;-)

See http://tinyurl.com/27kx7 and especially Hudak's seminal work
(http://tinyurl.com/2ofm5) for some that don't.

I'm all for interactive programming (of course
[url]http://www.boost.org/libs/python)[/url], but it doesn't neccessarily have
anything to do with DSELs.

Quote:

This is not to be confused with a programming language for embedded
systems.

You could write an interpreter for your embedded language in your
primary language, or you could find a pre-existing language
implementation with good interface support for your primary
language.

Ah, but then it probably wouldn't be domain-specific.

Quote:

An
embedded language implementation might take the form of a function
library. That is, the embedded language might be a set of function calls
you link into your application.

That's what's usually meant by "embedded" in "DSEL"

Quote:

Interactive programming languages that support the ability to interface
with code written in C are fairly common. Implementations that leverage
the strengths of C++ over C are rarer and trickier. For what it's worth,
here's my attempt: <http://www.standarddeviance.com/sigma> It's
incomplete mainly in the sense that it's undocumented. Also, my design
emphasized robustness and flexibility over performance in the sense that
I avoided optimizations that decreased the language's expressiveness or
complicated the interface to C++.

Wonderful, but that's definitely *not* a domain-specific *embedded*
language (for C++), because it is missing two key features:

A DSEL is targeted at a particular domain, allowing you to express
programs in terms of that domain's abstractions. Unless your
domain is "functional programming", sigma isn't doing that.

A DSEL doesn't make you leave the general purpose language in order
to use it. As a result, it can easily interoperate with other
DSELs. No matter how easy it is to extend C++ in sigma, there's
some interfacing overhead involved in using some arbitrary C++
library from sigma.

Quote:

I tried searching the web, but information was hard to come by, and
what little I found was focused on functional languages.

One of the strengths of the functional programming paradigm is that it
can simultaneously allow for conciseness, expressiveness, and a small
implementation--all traits desirable in an embedded language.

And more importantly, a "declarative" program, which is what allows
us to program close to the domain abstractions.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Kevin Cline
Guest

Posted: Thu Jan 29, 2004 7:14 pm Post subject: Re: Embedded Languages in C++?

[email]xmp333 (AT) yahoo (DOT) com[/email] wrote in message news:<4a0da86b.0401271748.29ac833d (AT) posting (DOT) google.com>...

Quote:

My advice is to pick an existing language and expose your domain model
to that language. That way you will get all the standard language
features for free: looping, conditionals, subroutines, etc. And it
saves you from having to write a manual for the language -- you can
just refer the users to the standard text for whatever language you
choose, and document only the commands or objects you have added.
Also, for existing languages there is a huge body of published code
that could be integrated into scripts if desired. Want to
automatically
E-mail the application state on certain conditions? No problem. Want
to develop a custom GUI? Easy, just use the existing Tk integration.

If the users are relatively unsophisticated, or will not be writing
long scripts, you could use TCL. It's easy to embed the TCL
interpreter in an application, and easy to add commands to manipulate
your domain objects.

If the users are more sophisticated, and will want to write complex
scripts,
or if script execution time is important, then you should think about
Perl or Python or Ruby.

I once worked on a large application that had a complex custom
embedded language. The decision to develop a custom language had cost
the company about ten million dollars by the time I left. The product
was highly customized for each installation, so we had some very
complex scripts written in that language. We spent at least ten
million developing the language, debugging it, documenting it, and
training all the installation consultants to write it. Most of that
money could have been saved if we had picked an existing language. At
the time, Perl would have been a very good choice.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Thant Tessman
Guest

Posted: Fri Jan 30, 2004 9:32 am Post subject: Re: Embedded Languages in C++?

David Abrahams wrote:

Quote:

Thant Tessman <thant (AT) acm (DOT) org> writes:

[...]

Quote:

An embedded programming language is intended to add the benefits of
interactive programming to an application written primarily in a
non-interactive programming language. That is, an embedded language
serves as an interface to a running application.

Thant,

It's not a bad definition; it just happens to conflict with the
existing one ;-)

See http://tinyurl.com/27kx7 and especially Hudak's seminal work
(http://tinyurl.com/2ofm5) for some that don't.

Seems my notion of what an embedded language is doesn't match the
references you give. What I've been calling an embedded language might
be more typically described as an *extension* language. And my confusion
comes from the fact that the whole point of an extension language is to
offer the user a language which captures the semantics of the
application domain with more fidelity than the "general" language. And
as a rule, these extension languages are interactive (although I admit
this is not necessarily a useful defining characteristic).

However, there is a point of view that says that programming in general
is NOTHING BUT building what you would call a domain-specific language.
The act of capturing application domain-specific abstractions is nothing
but building this "embedded" language. And it's hard to imagine a
programming task that can't be thought of in this way (although some
languages are better than others at allowing the programmer to build
application-specific abstractions).

For example, I have a fairly fancy C++ 3D math library. I did my best to
design it as if it was a natural extension of C++. What about it would
qualify or disqualfy my library as an embedded language? And what
purpose would the distinction serve? (--beyond, that is, an attempt to
describe what is nothing more than (if I may be presumptuous) good C++
programming style--)

[...]

Quote:

Sigma isn't a domain-specific language. It's designed to be easy to turn
into a domain-specific language given C++ as one's implementation
language. And the strength of a functional programming language is not
that it allows you to do functional programming, but that functional
programming more readily allows the programmer to build
application-specific abstractions.

Quote:

A DSEL doesn't make you leave the general purpose language in order
to use it. [...]

Not to claim that your use of the term isn't canonical, but the idea
that seems to be behind it is something I've considered a truism for so
long that it surprises me it deserves its own term. In contrast, it's
hard not to describe e.g. Python embedded in a C++ application as an
"embedded language."

-thant

"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy L. Steele Jr.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Abrahams
Guest

Posted: Sat Jan 31, 2004 1:26 am Post subject: Re: Embedded Languages in C++?

[email]kcline17 (AT) hotmail (DOT) com[/email] (Kevin Cline) writes:

Quote:

Actually, if you go look up the meaning of "domain-specific Embedded
language" in the references I posted you'll find using one has all the
same benefits. The "embedded" part means that it's a subset of the
general purpose programming language.

Cheers,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Abrahams
Guest

Posted: Sat Jan 31, 2004 1:39 am Post subject: Re: Embedded Languages in C++?

Thant Tessman <thant (AT) acm (DOT) org> writes:

Quote:

David Abrahams wrote:
Thant Tessman <thant (AT) acm (DOT) org> writes:

[...]

An embedded programming language is intended to add the benefits of
interactive programming to an application written primarily in a
non-interactive programming language. That is, an embedded language
serves as an interface to a running application.

Thant,

It's not a bad definition; it just happens to conflict with the
existing one ;-)

See http://tinyurl.com/27kx7 and especially Hudak's seminal work
(http://tinyurl.com/2ofm5) for some that don't.

Seems my notion of what an embedded language is doesn't match the
references you give. What I've been calling an embedded language
might be more typically described as an *extension* language.

Yep.

Quote:

And my confusion comes from the fact that the whole point of an
extension language is to offer the user a language which captures
the semantics of the application domain with more fidelity than the
"general" language.

Not usually, IME. Most extension languages are general purpose. It's
too expensive to develop an extension language it to be worth building
a new one for each new domain.

Quote:

And as a rule, these extension languages are interactive (although I
admit this is not necessarily a useful defining characteristic).

However, there is a point of view that says that programming in general
is NOTHING BUT building what you would call a domain-specific language.
The act of capturing application domain-specific abstractions is nothing
but building this "embedded" language.

Ah, but many programmers don't use abstraction ;-)

If you said that library design was "NOTHING BUT building ...a
domain-specific language", it'd be closer to the truth. There can be
important differences though.

Quote:

And it's hard to imagine a programming task that can't be thought of
in this way (although some languages are better than others at
allowing the programmer to build application-specific abstractions).

For example, I have a fairly fancy C++ 3D math library. I did my best to
design it as if it was a natural extension of C++. What about it would
qualify or disqualfy my library as an embedded language?

Does it allow you to express things in terms very similar to those
generally used for non-computerized 3D math -- that is, close to the
domain abstraction?

Consider the following quote contrasting traditional libraries and
DSLs [Heering02]_:

In combination with an application library, any general purpose
programming language can act as a DSL, so why were DSLs developed in
the first place? Simply because they can offer domain-specificity in
better ways:

* Appropriate or established domain-specific notations are
usually beyond the limited user-definable operator notation
offered by general purpose languages. A DSL offers
domain-specific notations from the start. Their importance
cannot be overestimated as they are directly related to the
suitability for end user programming and, more generally, the
programmer productivity improvement associated with the use of
DSLs.

* Appropriate domain-specific constructs and abstractions cannot
always be mapped in a straightforward way on functions or
objects that can be put in a library. This means a general
purpose language using an application library can only express
these constructs indirectly. Again, a DSL would incorporate
domain-specific constructs from the start.

... [Heering02] Jan Heering and Marjan Mernik, *Domain-Specific
Languages for Software Engineering*, Proceedings of the
35th Hawaii International Conference on System Sciences -
2002. http://www.computer.org/proceedings/hicss/1435/volume9/14350279.pdf

Quote:

And what purpose would the distinction serve? (--beyond, that is, an
attempt to describe what is nothing more than (if I may be
presumptuous) good C++ programming style--)

It's a huge distinction, in both intentionality and in the end result.
Think of the difference between Boost.Lambda and using std::bind1st et
al.

Quote:

Wonderful, but that's definitely *not* a domain-specific *embedded*
language (for C++), because it is missing two key features:

A DSEL is targeted at a particular domain, allowing you to express
programs in terms of that domain's abstractions. Unless your
domain is "functional programming", sigma isn't doing that.

Sigma isn't a domain-specific language. It's designed to be easy to turn
into a domain-specific language given C++ as one's implementation
language.

I still have my doubts. Maybe we have different ideas about the
meaning of "domain-specific"?

Quote:

And the strength of a functional programming language is not that it
allows you to do functional programming, but that functional
programming more readily allows the programmer to build
application-specific abstractions.

I'm not sure I buy that either.

Quote:

A DSEL doesn't make you leave the general purpose language in order
to use it. [...]

Not to claim that your use of the term isn't canonical, but the idea
that seems to be behind it is something I've considered a truism for so
long that it surprises me it deserves its own term. In contrast, it's
hard not to describe e.g. Python embedded in a C++ application as an
"embedded language."

It's hard only because the term "embedded" is being used in two
different ways. Used according to its meaning in DSEL, Python is not
embedded at all, unless you mean Python's 'C' API. The Boost.Python
object wrappers come a little bit closer to making Python an embedded
language, but I'd say that's a stretch.

Quote:

-thant

"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy L. Steele Jr.

Strange that lisp macros gave metaprogramming a bad name, isn't it?
;-)

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Allan W
Guest

Posted: Thu Feb 05, 2004 3:29 am Post subject: Re: Embedded Languages in C++?

Quote:

Thant Tessman <thant (AT) acm (DOT) org> writes:
An
embedded language implementation might take the form of a function
library. That is, the embedded language might be a set of function
calls
you link into your application.

David Abrahams <dave (AT) boost-consulting (DOT) com> wrote

Quote:

That's what's usually meant by "embedded" in "DSEL"

There's a technique I used years ago (in assembly language, not C++).
I tend to think of it as an "Embedded language" but it doesn't fit any
definition I've seen in this thread. I'll call it "data driven coding"
and I'd like to know if it matches anybody's definition of an embedded
language.

When I used this technique, it was for various data transformations --
we read a database record, and transform it into printable characters
or vice-versa. A table of enumerations describes the data type in the
database record and in the printable version.

My question is -- is this a well-known technique? If so, what is it
called?

// Translated into untested C++ -- for exposition only
// Here's the library code:
class Translate {
enum Types {
tEnd=0, // Marks end of table
tNothing, // Used with tText to pad output

tDate, // 2-byte date
tTime, // 2-byte time of day
tS1, // 1-byte signed
tU1, // 1-byte unsigned
tS2, // 2-byte signed
tU2, // 2-byte unsigned
tS4, // 4-byte signed
tU4, // 4-byte unsigned
tMoney, // tU4, but last 2 digits are pennies

// Add other types here, etc.

tLast, // Last enumeration not including tText

// tText+n describes an n-byte text field
// (translationg from tText to tText might involve
// truncating or right-padding).
tText = 128 // Must be last in table
};

// Translate from first type (Binary) to second type (Report)
static void Translate12(const Types*p,
const unsigned char*in, unsigned char*out) {
for (int i=0; p[0]!=tEnd; p+=2)
helper(&in, p[0], &out, p[1]);
}

// Translate from second type (Report) to first type (Binary)
static void Translate12(const Types*p,
const unsigned char*in, unsigned char*out) {
for (int i=0; p[0]!=tEnd; p+=2)
helper(&in, p[1], &out, p[0]);
}

private:
static void helper(const unsigned char*&in, Types t1,
unsigned char *&out, Types t2);
// Don't instantiate
Translate(const Translate&);
void operator=(const Translate&);
};

Translate::helper(const unsigned char*&in, Translate::Types t1,
unsigned char *&out, Translate::Types t2)
{
assert(t1 != tText && t2 != tText);
if (t1>tText || t2>tText) {
if (t1<=t2) {
memcpy(out, in, (t1-tText));
} else {
memcpy(out, in, (t2-tText));
memset(out + t2-tText, ' ', t2-t1);
}
in += (t1 - tText);
out += (t2 - tText);
} else switch(t1) {
case
}
}

/*** USAGE ***/
// These are best made reusable, perhaps even global
// Translate customer record from internal to report format
Translate::Types xlate_cust[] = {
// Binary Report
Translate::tText+4, Translate::tText+8, // Customer ID
Translate::tS2, Translate::tText+12 // Balance Due
Translate::tNothing, Translate::tText+3 // 3 blanks on report
Translate::tText+16, Translate::tText+16, // Last name
Translate::tNothing, Translate::tText+3, // 3 blanks
Translate::tText+16, Translate::tText+16, // First name
Translate::tEnd };

// This function reads the customer and prints a report
void ReportCust() {
unsigned char inbuff[custRecLen] = {0};
unsigned char outbuff[custRptLen] = {0};
while (read_next_cust(inbuff)) {
Translate::Translate12(xlate_cust, inbuff, outbuff);
write_report_detail(outbuff);
}
}

The advantage of this technique was that it allowed us to do very
complex
data manipulations for defined compound types (structs) with a single
call. Instead of writing a unique subroutine for each struct that we
might
have to convert, we just write a unique transformation table.

As presented, this is used at certain points within normal C++ code.
A simple extension of this technique would allow the enumerations to
perform a wider set of pre-packaged actions, effectively allowing you
to "write code" with enumerations.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum