[Ecls-list] Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

[Christian Schafmeister]

On Mar 5, 2013, at 5:41 PM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> On Tue, Mar 5, 2013 at 7:15 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote:
> C++ template programming is not pretty but using template programming hands the problem of identifying C++ types and parsing C++ code to the C++ compiler where it is done properly. The other approach is to create something like SWIG, which attempts to parse C (it does a good job) and C++ (it does a lousy job) and then generate interface code.
> 
> I did not mean to complain about the template approach in general, but I just read the Boost code and it is awful. Sure, recursive file inclusion is neat, but it is unreadable, as much as the rest of the code. The idea of automatic coercion from various types to Common Lisp and back, though, is neat.

The boost code is awful - I completely agree - but it works.   :-)
I've copied and adapted a good portion of it but not all of it.
C++ template programming is to macro-programming as Tax forms are to poetry.

> 
> "Can be ported" - certainly. These are Turing complete languages and we can do anything computable within them. It's a question of how much time porting requires.  
> 
> Not much, I would believe. All common lisp have one or more functions to allocate foreign objects; surely they also do have functions for defining functions to be called or, if not, they can be implemented in two lines of CFFI. One can implement the template approach with a lot of boilerplate and a hundred lines of backend, I believe.
>  
> But there is a reason no one has done this (interfaced the more complicated language features of C++ and CL) before.
> There is also a reason why SWIG exists and why boost::python exists.
> I've taken the boost::python approach to interfacing C++ to CL - this has not been done before.
> 
> Not that I ever heard of.
>  
> Using my (boost::python-like) approach C++ classes have either single or multiple inheritance, the inheritance structure is duplicated in CL.
> Methods are exposed once with one name, in the lowest level class that implements them and they are inherited by every class that derives from that class.
> 
> I assume that each method is exposed only once, am I wrong. I am thinking on
> 
> class A {
>   int method() const;
> };
> 
> class B {
>   int method() const;
> };

There are two ways to handle this where neither A nor B are subclasses of each other:
Approach 1:

class_<A>()
    .def("a-method",&A::method);

class_<B>()
    .def("b-method",&B::method);

In CL we are used to that; there is SYMBOL-NAME and PACKAGE-NAME.  

Approach 2:
I also implemented SINGLE-DISPATCH-GENERIC-FUNCTION and SINGLE-DISPATCH-METHOD that work like simplified generic functions/methods but only dispatches on a single argument and doesn't have before/after/around methods.  I still need to extend these to allow users to extend C++ classes with single-dispatch-methods in CL.

Then you use:
class_<A>()
    .def("method",&A::method,"((x A))");
class_<B>()
    def("method",&B::method,"((x B))");

If "a" is an instance of A and "b" is an instance of B in CL the dispatcher dispatches (method a) to A::method and (method b) to B::method.



> 
> How do you handle this? I know the phython approach relies on the overloading that is inherent to Python's object system, but in Common Lisp it gets tricky unless you resort to CLOS.
> 
> Best,
> 
> Juanjo
> 
> -- 
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain) 
> http://juanjose.garciaripoll.googlepages.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20130305/7dc588e1/attachment.html>