I find the Boost C++ libraries to be quite amazing, and the Boost
Python library seems to have really helped putting Python in touch
with a lot of existing C++ code. So, my question to everyone on the
group is do you feel the Lisp community would benefit from having a
Boost::Lisp, so to speak (it would of course not have the Boost name,
but you get the general idea.) In your opinions, how would you rate
the difficulty of such a project?
·······@gmail.com wrote:
> I find the Boost C++ libraries to be quite amazing, and the Boost
> Python library seems to have really helped putting Python in touch
> with a lot of existing C++ code. So, my question to everyone on the
> group is do you feel the Lisp community would benefit from having a
> Boost::Lisp, so to speak (it would of course not have the Boost name,
> but you get the general idea.) In your opinions, how would you rate
> the difficulty of such a project?
Boost is a set of C++ (mostly template) libraries that implement various
data structures, algorithms etc. Quite a few of the things that it
provides already exist in Common Lisp. What exactly is it that you want
ported over, and how do you imagine it? If you mean in the general case,
whether Lisp should have more 3rd-party libraries for all kinds of
stuff, then surely this is the case but see also
http://www.common-lisp.net/.
·······@gmail.com wrote:
> I find the Boost C++ libraries to be quite amazing,..
Care to share? Or are we just supposed to take your word for it? What
are the top two or three amazing things in Boost?
> and the Boost
> Python library seems to have really helped putting Python in touch
> with a lot of existing C++ code.
And Chernobyl put a lot of people in touch with radioactivity.
Meanwhile, it does not seem to be keeping Python from rapidly slipping
beneath the waves of the Ruby tsunami, which will recede leaving Lisp in
charge.
Maybe you want to head over to c.l.boost and tell them about this
amazing Lisp language they might want to implement next.
> So, my question to everyone on the
> group is do you feel the Lisp community would benefit from having a
> Boost::Lisp, so to speak (it would of course not have the Boost name,
> but you get the general idea.) In your opinions, how would you rate
> the difficulty of such a project?
>
Pretty hard. Lisp is just a toy language used only for AI with too many
bugs because of the lack of strong static typing, oould never keep up
with a real language like C++.
kt
ps. I have heard talk at least of folks doing the GoF patterns in Lisp
as an exercise, maybe you could do the same with Boost
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Ken Tilton wrote:
> ·······@gmail.com wrote:
>> I find the Boost C++ libraries to be quite amazing,..
>
> Care to share? Or are we just supposed to take your word for it? What
> are the top two or three amazing things in Boost?
boost::smart_ptr (poor man's GC), boost::bind and boost::lambda (poor
man's lambda), boost::preprocessor (poor man's macros), and
boost:type_traits (poor man's static introspection).
boost::spirit and boost::wave form a reasonably easy to use parsing
library.
boost::asio looks like it could form a nice TCP/IP/whatever async library.
Some of this could be useful in Lisp.
- Daniel
D Herring wrote:
> Ken Tilton wrote:
>
>> ·······@gmail.com wrote:
>>
>>> I find the Boost C++ libraries to be quite amazing,..
>>
>>
>> Care to share? Or are we just supposed to take your word for it? What
>> are the top two or three amazing things in Boost?
>
>
> boost::smart_ptr (poor man's GC), boost::bind and boost::lambda (poor
> man's lambda), boost::preprocessor (poor man's macros), and
> boost:type_traits (poor man's static introspection).
I feel like I am in the boxing ring and my opponent just started
punching himself, I am a bit at a loss.
>
> boost::spirit and boost::wave form a reasonably easy to use parsing
> library.
Good lord, look at those names. I do believe C++ has driven them batty.
>
> boost::asio looks like it could form a nice TCP/IP/whatever async library.
Build a bridge to Boost to get cl-sockets? That's like building the
world's longest suspension bridge to get to... Staten Island?!
>
> Some of this could be useful in Lisp.
This is Lisp, we think big. If you cannot let go of your C++ skills,
help finish this bridge to Staten Island:
http://common-lisp.net/project/fetter/
The downside of my suggestion is that it is much easier to sip coffee
and post to comp.lang.lisp and tell the non-existent Lisp community what
we should be doing than it is to do any Actual Frickin Work.
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On 2007-09-19 07:50:39 -0400, Ken Tilton <···········@optonline.net> said:
> That's like building the world's longest suspension bridge to get to...
> Staten Island?!
Staten Island? - the Verrazano is just a shortcut from Brooklyn to New
Jersey, no?
Raffael Cavallaro wrote:
> On 2007-09-19 07:50:39 -0400, Ken Tilton <···········@optonline.net> said:
>
>> That's like building the world's longest suspension bridge to get
>> to... Staten Island?!
>
>
> Staten Island? - the Verrazano is just a shortcut from Brooklyn to New
> Jersey, no?
>
Well, it didn't quite reach so they used landfill from Manhattan to,
well, bridge the gap. Someone passing by asked, "Is dat 'n island?".
They had been looking for a name....
hth,kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Ken Tilton wrote:
> D Herring wrote:
>> Ken Tilton wrote:
>>> ·······@gmail.com wrote:
>>>
>>>> I find the Boost C++ libraries to be quite amazing,..
>>>
>>> Care to share? Or are we just supposed to take your word for it? What
>>> are the top two or three amazing things in Boost?
>>
>> boost::smart_ptr (poor man's GC), boost::bind and boost::lambda (poor
>> man's lambda), boost::preprocessor (poor man's macros), and
>> boost:type_traits (poor man's static introspection).
>
> I feel like I am in the boxing ring and my opponent just started
> punching himself, I am a bit at a loss.
At your service.
You asked for a list of the "amazing" things in Boost. These *are*
amazing to C++ programmers... They'd be amazing to you too if you had
to warp the C preprocessor and C++ template system to achieve such tasks.
There's a reason I'm posting in this NG, and its not to promote C++.
- Daniel
D Herring wrote:
> Ken Tilton wrote:
>
>> D Herring wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>> ·······@gmail.com wrote:
>>>>
>>>>> I find the Boost C++ libraries to be quite amazing,..
>>>>
>>>>
>>>> Care to share? Or are we just supposed to take your word for it?
>>>> What are the top two or three amazing things in Boost?
>>>
>>>
>>> boost::smart_ptr (poor man's GC), boost::bind and boost::lambda (poor
>>> man's lambda), boost::preprocessor (poor man's macros), and
>>> boost:type_traits (poor man's static introspection).
>>
>>
>> I feel like I am in the boxing ring and my opponent just started
>> punching himself, I am a bit at a loss.
>
>
> At your service.
>
> You asked for a list of the "amazing" things in Boost. These *are*
> amazing to C++ programmers... They'd be amazing to you too if you had
> to warp the C preprocessor and C++ template system to achieve such tasks.
Well since you are in this NG and you know I do not have to do those
things, how the hell did your logic circuit come up with "Boost would be
amazing for Lisp"?
Wouldn't it be a lot easier to just say, "OK, right, that was dumb."?
Instead your ego is going to send you out round after round until the
ring doctor stops it, and he has been drinking since 10am and would not
be a ring doctor if he did not like seeing people bloodied beyond
recognition.
Your only hope for redemption will also get you into the Lisp Hall of
Fame: help finish the bridge to Staten Island. Oh, right, then you would
have to actually write some code instead of grandstanding in c.l.l
telling other people on what to work. My bad.
The good news is that you are perfect for c.l.l, no one else here writes
any code either.
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Ken Tilton wrote:
> My bad.
'nuff said.
While we're talking...
- What ever happened to the math software for kiddies?
- Since you seem confused, I have never used srallya as a nick.
- The sarcasm in my first post appears to have been lost on you.
- I've played rather heavily with Fetter. Built a couple Qt apps
using it to generate the bindings. Decided its not the right way to
go. Feel free to bridge to Staten Island; I'm digging for Dwarfs in
the Klondike.
Why is Fetter the wrong approach?
- Batch processes the header files to generate "CFFI bindings"
- For a big project (e.g. Qt), this dumps a 1+MB lisp file
- The user must then correlate the C++ API with Fetter's output, and
finally write a Lisp wrapper to make the important parts usable. By
this time, its been my experience (e.g. binding to Qt or Sundials[1])
that its easier to write the CFFI bindings manually.
With a Dwarf/STABS approach, the user might
- load a library with debug symbols
- query to see what's available
- interactively create bindings for what is needed
With a little more work, integrating a debugger should be possible;
this would allow transparent checks on how the C++ library is handling
the CFFI bindings (without pausing lisp to drop into gdb).
Unfortunately, I spread my free time into too many projects. All I've
got of the Dwarf approach is a lisp file that lists the source files
used to compile a library.
Later,
Daniel
[1] http://www.llnl.gov/CASC/sundials/
D Herring wrote:
> Ken Tilton wrote:
>
>> My bad.
>
>
> 'nuff said.
>
> While we're talking...
> - What ever happened to the math software for kiddies?
Had to take a job as a bartender to pay the bills, a little hard to work
all day and then come home and work all day. Piece of cake when I was
28, now after an arithmetic shift left, not so much. That said, I am
trying to get a prototype out to a few friendlies sometime this week for
them to play with.
> - Since you seem confused, I have never used srallya as a nick.
I have no idea about what you are talking.
> - The sarcasm in my first post appears to have been lost on you.
If I cared I'd go back and check.
> - I've played rather heavily with Fetter. Built a couple Qt apps using
> it to generate the bindings.
Hey! Cool! All is forgiven! Hang on...
> Decided its not the right way to go. Feel
> free to bridge to Staten Island; I'm digging for Dwarfs in the Klondike.
Maybe after some coffee I will work out how that translates to Swig.
>
> Why is Fetter the wrong approach?
> - Batch processes the header files to generate "CFFI bindings"
> - For a big project (e.g. Qt), this dumps a 1+MB lisp file
That's the first thing you were going to fix. Tho ISTR some work had
been done on that.
> - The user must then correlate the C++ API with Fetter's output, and
> finally write a Lisp wrapper to make the important parts usable. By
> this time, its been my experience (e.g. binding to Qt or Sundials[1])
> that its easier to write the CFFI bindings manually.
No, the project Prime Directive is plug 'n play, it just is not
finished. Well, I used it successfully on something when I did the
assessment, and it /was/ plug 'n play, but that was a C API. Little
thing called OpenGL, IIRC.
>
> With a Dwarf/STABS approach, the user might
> - load a library with debug symbols
> - query to see what's available
> - interactively create bindings for what is needed
Sorry, I thought you said "interactively".
It does not seem Dwarf tells you how the parameters are used. When I did
my C2Lisp translator to kick off the math software it occurred to me we
could auto-determine pointers used as C-strings, but that entails having
a peak at the code. Mebbe I missed that in Dwarf.
>
> With a little more work, integrating a debugger should be possible; this
> would allow transparent checks on how the C++ library is handling the
> CFFI bindings (without pausing lisp to drop into gdb).
Great! Where can I downl... uh-oh..
>
> Unfortunately, I spread my free time into too many projects. All I've
> got of the Dwarf approach is a lisp file that lists the source files
> used to compile a library.
You might not want to diss Vzn until you have at least one arrow in that
quiver of yours. And when dissing a project recommended to you as
unfinished, whining about it not being finished is... well, is there a
little red light on your dashboard saying "service logic circuit soon"?.
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Ken Tilton <···········@optonline.net> wrote:
> Meanwhile, it does not seem to be keeping Python from rapidly slipping
> beneath the waves of the Ruby tsunami, which will recede leaving Lisp in
> charge.
What Ruby tsunami? I switched from Ruby to Python.
BTW:
$ grep -r 'Stefan Scholl' /usr/lib/ruby/1.8/ | wc -l
3
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Stefan Scholl wrote:
> Ken Tilton <···········@optonline.net> wrote:
>
>>Meanwhile, it does not seem to be keeping Python from rapidly slipping
>>beneath the waves of the Ruby tsunami, which will recede leaving Lisp in
>>charge.
>
>
> What Ruby tsunami? I switched from Ruby to Python.
(make-instance 'summer :sparrow-count 1)
-> NIL
>
>
> BTW:
> $ grep -r 'Stefan Scholl' /usr/lib/ruby/1.8/ | wc -l
> 3
(make-instance 'summer
:sparrows (list (make-instance 'big-sparrow)))
-> NIL
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Thomas A. Russ wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>(make-instance 'summer :sparrow-count 1)
>>-> NIL
>
>
> That should be:
>
> (make-instance 'summer :swallow-count 1)
> -> NIL
>
> HTH.
Yes, of course. This NG really does rock!
What /does/ it take to make a summer? most-positive-swallownum?
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Ken Tilton <···········@optonline.net> wrote:
> Stefan Scholl wrote:
>> Ken Tilton <···········@optonline.net> wrote:
>>
>>>Meanwhile, it does not seem to be keeping Python from rapidly slipping
>>>beneath the waves of the Ruby tsunami, which will recede leaving Lisp in
>>>charge.
>>
>>
>> What Ruby tsunami? I switched from Ruby to Python.
>
> (make-instance 'summer :sparrow-count 1)
> -> NIL
Why is the rum gone?
On 18 Sep, 22:25, ·······@gmail.com wrote:
> I find the Boost C++ libraries to be quite amazing, and the Boost
> Python library seems to have really helped putting Python in touch
> with a lot of existing C++ code. So, my question to everyone on the
> group is do you feel the Lisp community would benefit from having a
> Boost::Lisp, so to speak (it would of course not have the Boost name,
> but you get the general idea.) In your opinions, how would you rate
> the difficulty of such a project?
Boost is indeed a really nice library and I use it a little in my own C
++ code. But a lot of the libraries (e.g. Boost.Any, Boost.Lambda,
Boost.Bind, Boost.Foreach) aren't at all necessary in Lisp (even to
the point of being keywords in the language!). I suspect a lot of what
I use Boost for is 'subverting' the type system so maybe I'm not the
best person to comment :-)
We could go through the Boost libraries one-by-one and say which would
be nice to have but I suspect this isn't the most useful exercise -
probably better to start from Lisp and work out what you need.
The specific library you mention, Boost.Python, is an interesting
enough idea though. The Python standard library is pretty extensive
and no doubt has some bits we could use. But I wounder if it's better
to interface with the Java or .NET libraries instead as they're even
more pervasive these days. I think people are doing this already.
Of course, another step back and you're at the C library layer. We can
already do this pretty well from Lisp and there's arguably more C
libraries than anything else out there.
Do you have anything specific in mind?
--
Phil
http://phil.nullable.eu/
(message (Hello ········@gmail.com)
(you :wrote :on '(Tue, 18 Sep 2007 21:25:29 -0000))
(
s> I find the Boost C++ libraries to be quite amazing
it has a lot of nifty things, but if you use it build times rise _a lot_,
and if you write a bit wrong code it produces gigantic insane error
reports..
so now i'd think twice before using some Boost feature somewhere..
s> and the Boost Python library seems to have really helped putting Python
s> in touch with a lot of existing C++ code.
my experience of developing dual C++/Python project was quite negative -- it
introduced lots of complexities. i had to mutilate my C++ code, because the
converter was barfing seeing some little bit untrivial code. build time
jumped a lot -- it was taking several minutes to scan through source code
building freaking wrappers.
OTOH experience with simplistic manual bindings was quite positive --
s> group is do you feel the Lisp community would benefit from having a
s> Boost::Lisp, so to speak (it would of course not have the Boost name,
s> but you get the general idea.)
i think it wouldn't much. we already have lots of FFI solutions.
including SWIG, for example.
they kinda work, sometimes.. certainly it's a bit of problem because of lack
of standard, but it's just inherent -- many implementations, many
platforms..
and, there's significantly less benefit of using C++ and Lisp in combination
than of using Python and C++.
because Python is designed as inherently slow scripting language. thus it
makes sense to code fast things in C++ and script them in Python.
Lisp can be compiled into quite efficient native code, so for what hell
would you want C++ hanging around?
s> In your opinions, how would you rate the difficulty of such a project?
the main difficulty is that there is no such thing as "Lisp", unlike
"Python". there are lots of implementations, each having different internals
and FFI. (heh, having different versions/builds of Python isn't sugar at
all, but they pretend there's single implementation..)
so, if i were you, i'd learn about existing FFI libraries. outline how
Boost::Lisp will be better then them (use cases, etc). and then implement it
as an extension of one of FFI libraries (possibly choosing most robust,
mature and widespread..).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"Hanging In The Balance Of Deceit And Blasphemy")
On Sep 18, 5:25 pm, ·······@gmail.com wrote:
> So, my question to everyone on the group is do you feel the Lisp
> community would benefit from having a Boost::Lisp, so to speak
> (it would of course not have the Boost name, but you get the
> general idea.)
Well, a lot (not all, but a lot) of the functionality Boost provides
for C++ is already a standard part of Common Lisp. So imitating Boost
too closely probably wouldn't be a very big win. If your idea is more
general, and just focuses on providing high-quality open source
libraries, I think the answer is a big, "Yes." More good libraries
will almost always help.
That being said, there are quite a few projects aimed at providing
libraries for Common Lispers to use. Maybe you should investigate
helping out with one of them, instead of starting a brand new
endeavor?
> In your opinions, how would you rate the difficulty of such a
> project?
It really depends on the functionality you're looking to provide.
Cheers,
Pillsy
·······@gmail.com writes:
> I find the Boost C++ libraries to be quite amazing, and the Boost
> Python library seems to have really helped putting Python in touch
> with a lot of existing C++ code. So, my question to everyone on the
> group is do you feel the Lisp community would benefit from having a
> Boost::Lisp, so to speak (it would of course not have the Boost name,
> but you get the general idea.) In your opinions, how would you rate
> the difficulty of such a project?
People have answered this in various ways, but let me try another:
What programs are you having trouble writing without something
Boost-like to help you?
Before you worry about the implementation of such a library, why not
sketch what a sample program or two would look like if you had access
to such a library?
On Sep 18, 11:25 pm, ·······@gmail.com wrote:
> I find the Boost C++ libraries to be quite amazing, and the Boost
> Python library seems to have really helped putting Python in touch
> with a lot of existing C++ code. So, my question to everyone on the
> group is do you feel the Lisp community would benefit from having a
> Boost::Lisp, so to speak (it would of course not have the Boost name,
> but you get the general idea.) In your opinions, how would you rate
> the difficulty of such a project?
After being a *lucky-one* to made wrappers for a lot for c/c++ code
(tv3d bindings, lightfeather engine interfacing) and still doing some
c bindings in progress http://slobodan.blazeski.googlepages.com/Monetdb-mapi.html
my humble opinion is if you really, really MUST interface with c++
from lisp you have three choices:
1. Find another project that doesn't require interfacing with c++
2. Rewrite c++ code in lisp
3. Look for another job.
Everything else is pleasant as hemroids, migrena & toothache togather.
If you really like some boost library , rewrite it in lisp you will
learn a lot in that journey, not to mention the benefits to the
community.
·······@gmail.com wrote:
> I find the Boost C++ libraries to be quite amazing, and the Boost
> Python library seems to have really helped putting Python in touch
> with a lot of existing C++ code. So, my question to everyone on the
> group is do you feel the Lisp community would benefit from having a
> Boost::Lisp, so to speak (it would of course not have the Boost name,
> but you get the general idea.) In your opinions, how would you rate
> the difficulty of such a project?
Well, I just have to say that I'm amazed how almost everyone replying
to this post seems to have completely missed the OP's idea. It seems
to me that the OP is here suggesting to build a library for creating
Common Lisp <--> C++ bindings to, for example, make it easy to use CL
as a scripting language in a C++ application, which is one of the uses
of the Boost.Python library. Now, whether or not that is technically
feasible or otherwise desirable are entirely different issues.
-Vesa Karvonen
Vesa Karvonen wrote:
> ·······@gmail.com wrote:
>> I find the Boost C++ libraries to be quite amazing, and the Boost
>> Python library seems to have really helped putting Python in touch
>> with a lot of existing C++ code. So, my question to everyone on the
>> group is do you feel the Lisp community would benefit from having a
>> Boost::Lisp, so to speak (it would of course not have the Boost name,
>> but you get the general idea.) In your opinions, how would you rate
>> the difficulty of such a project?
>
> Well, I just have to say that I'm amazed how almost everyone replying
> to this post seems to have completely missed the OP's idea. It seems
> to me that the OP is here suggesting to build a library for creating
> Common Lisp <--> C++ bindings to, for example, make it easy to use CL
> as a scripting language in a C++ application, which is one of the uses
> of the Boost.Python library. Now, whether or not that is technically
> feasible or otherwise desirable are entirely different issues.
>
> -Vesa Karvonen
Personally, I didn't understand the OP to be suggesting this either.
I thought the OP was wondering if a project to create a "community
approved" group of libraries for Common Lisp that is managed in the same
manner as the Boost projects for C++ and Python are would be beneficial
for the Common Lisp community.
I did not understand the OP to be suggesting that the Boost C++
libraries be ported to Common Lisp or that they be called from Common
Lisp, but rather that a new set of libraries be built or collected from
existing code that could be offered up as the "community's" recommended
way of doing things that aren't covered by the Common Lisp standard.
It would seem that efforts like the CL Gardeners and some of the
attempts at providing centralized asdf repositories are not unlike what
Boost is trying to be. And that is, to be the go to place to find the
libraries needed to build your application, with the added hope that
some or all of the libraries would someday be added to the standard.
Ts
P� Thu, 20 Sep 2007 10:20:42 +0200, skrev Vesa Karvonen
<·············@cs.helsinki.fi>:
> ·······@gmail.com wrote:
>> I find the Boost C++ libraries to be quite amazing, and the Boost
>> Python library seems to have really helped putting Python in touch
>> with a lot of existing C++ code. So, my question to everyone on the
>> group is do you feel the Lisp community would benefit from having a
>> Boost::Lisp, so to speak (it would of course not have the Boost name,
>> but you get the general idea.) In your opinions, how would you rate
>> the difficulty of such a project?
>
> Well, I just have to say that I'm amazed how almost everyone replying
> to this post seems to have completely missed the OP's idea. It seems
> to me that the OP is here suggesting to build a library for creating
> Common Lisp <--> C++ bindings to, for example, make it easy to use CL
> as a scripting language in a C++ application, which is one of the uses
> of the Boost.Python library. Now, whether or not that is technically
> feasible or otherwise desirable are entirely different issues.
>
> -Vesa Karvonen
It is simply not that interesting. C++ is difficult to interface to.
Templates are a pain. Why not interface to COM, CORBA, .NET or through
some recognised cross language object oriented interface?
John Thingstad <··············@chello.no> wrote:
> P� Thu, 20 Sep 2007 10:20:42 +0200, skrev Vesa Karvonen
> <·············@cs.helsinki.fi>:
[...]
> > Well, I just have to say that I'm amazed how almost everyone replying
> > to this post seems to have completely missed the OP's idea. It seems
> > to me that the OP is here suggesting to build a library for creating
> > Common Lisp <--> C++ bindings to, for example, make it easy to use CL
> > as a scripting language in a C++ application, which is one of the uses
> > of the Boost.Python library. Now, whether or not that is technically
> > feasible or otherwise desirable are entirely different issues.
> >
> > -Vesa Karvonen
> It is simply not that interesting. C++ is difficult to interface to.
Indeed, that is exactly where a library like Boost.Python is supposed
to become handy by making it easier.
Just for the record, I've never used CL for anything serious (I've
read a couple of books on it) and I haven't touched C++ in years, but
I'm generally interested in seeing, well, interesting languages like
CL being used more.
Now, why would the Common Lisp community be interested in library that
would make it easy to use CL as a scripting language in a C++ app?
(IOW, How could such a library help the CL community?)
> Why not interface to COM, CORBA, .NET or through some recognised
> cross language object oriented interface?
Those are not a bad ideas at all, but I can easily see several reasons
for why the OP might be specifically interested in making a C++
library (e.g. uses C++ at work, interested in learning more CL,
interested in C++ techniques used to implement Boost.Python, ...).
...
One nice thing about Boost.Python is that it is a library. IOW, it is
not a FFI generator program. Bindings are written in C++. See the
Boost.Python documentation:
http://boost.org/libs/python/doc/tutorial/doc/html/index.html#python.quickstart
This is not totally unlike what Norman Ramsey describes in his article
"Embedding an Interpreted Language Using Higher-Order Functions and
Types":
http://www.eecs.harvard.edu/~nr/pubs/embed-abstract.html
-Vesa Karvonen