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

[Peter Enerccio]

Adding my $0.02 to using ecl with c++, it is quite well possible, but very
tiresome. For every method call, you have to write static wrapper which
will cast all the
pointer(s) into respectable type and call the method with arguments. Doing
so by hand is very impossible, however, doing so with automatic wrapper is
quite easy.
The downsize is that you end up with 2000 lines of lisp and 4000 lines of
c++ wrappers which do nothing.

Examples:


;;;;; Generating class: e418::game::Event
(defclass event ( pointer-container )
   ())


;;;;; Generating class: e418::ui::Element
; Generating method destroy for object Element
(defmethod element-destroy ((class element) recursive )
    (c-code::native-destroy (get-pointer class) recursive ))

and on c++:

//
// Generating wrappers for Element
//

// Generating methods for object e418::ui::Element
// generating wrapper for method destroy of object Element
cl_object _cl_gen_Element_destroy2(cl_
object __wrapped_pointer, cl_object recursive ){
    // Converting lisp value to pointer of appropriate type
    e418::ui::Element* __instance = (e418::ui::Element*)
        ecl_to_pointer(__wrapped_pointer);

    // Unpacking all arguments from lisp type to c type
    bool recursive_unpacked = recursive == ECL_NIL ? false : true;

    cl_object return_value = ECL_NIL;
    // Method call
    __instance->destroy(recursive_unpacked );
    // Packing return value to lisp, if needed

    return return_value;
}

Dunno if this is right way to do it, though, but seems to work fine.

(Sorry Juan about double the mail, but apparently gmail changed my reply to
all to just reply...)


2013/3/4 Peter Enerccio <enerccio at gmail.com>

> Adding my $0.02 to using ecl with c++, it is quite well possible, but very
> tiresome. For every method call, you have to write static wrapper which
> will cast all the
> pointer(s) into respectable type and call the method with arguments. Doing
> so by hand is very impossible, however, doing so with automatic wrapper is
> quite easy.
> The downsize is that you end up with 2000 lines of lisp and 4000 lines of
> c++ wrappers which do nothing.
>
> Examples:
>
>
> ;;;;; Generating class: e418::game::Event
> (defclass event ( pointer-container )
>    ())
>
>
> ;;;;; Generating class: e418::ui::Element
> ; Generating method destroy for object Element
> (defmethod element-destroy ((class element) recursive )
>     (c-code::native-destroy (get-pointer class) recursive ))
>
> and on c++:
>
> //
> // Generating wrappers for Element
> //
>
> // Generating methods for object e418::ui::Element
> // generating wrapper for method destroy of object Element
> cl_object _cl_gen_Element_destroy2(cl_object __wrapped_pointer, cl_object
> recursive ){
>     // Converting lisp value to pointer of appropriate type
>     e418::ui::Element* __instance = (e418::ui::Element*)
>         ecl_to_pointer(__wrapped_pointer);
>
>     // Unpacking all arguments from lisp type to c type
>     bool recursive_unpacked = recursive == ECL_NIL ? false : true;
>
>     cl_object return_value = ECL_NIL;
>     // Method call
>     __instance->destroy(recursive_unpacked );
>     // Packing return value to lisp, if needed
>
>     return return_value;
> }
>
> Dunno if this is right way to do it, though, but seems to work fine.
>
>
> 2013/3/4 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com>
>
>> On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister <
>> chris.schaf at verizon.net> wrote:
>>
>>> I've created a new implementation of Common Lisp that has a core written
>>> in C++ completely from scratch but hosts the ECL Common Lisp source code.
>>>
>>
>> Sounds like a lot of work.
>>
>>
>>> It hosts all of the ECL Common Lisp code in the ecl/src/lsp and
>>> ecl/src/clos directories of the ECL source tree.
>>> I do not use any part of the ECL CL->C compiler or the byte code
>>> compiler.
>>> I've implemented my own CL interpreter and CL->LLVM-IR->native code
>>> compiler.
>>>
>>
>> I do not understand why you reimplemented the interpreter, but the LLVM
>> thingy looks interesting.
>>
>>
>>> It's purpose is to make possible the seamless interfacing of C++
>>> libraries with Common Lisp code and vice versa.
>>> Within this new implementation it is trivial to interface complex C++
>>> libraries containing classes, virtual functions, overloaded functions etc
>>> with Common Lisp code.
>>>
>>
>> Sorry, but I do not understand this. There are different things in
>> interfacing Common-Lisp with C++, and none of them requires building a new
>> compiler or a LLVM backend.
>>
>>
>>> Why - you ask?  I'd be happy to explain over a beer or coffee sometime.
>>> In a nutshell - I want this for my research and prior to my writing it
>>> there was no Common Lisp implementation that interfaces seamlessly with C++.
>>> ECL does a great job with "C" but "C++" is a much more complex language
>>> to interface with and I have a lot of C++ code that I need to interface
>>> with.
>>
>>
>> If you state that ECL cannot interface with C++ I would like to see that
>> statement backed with examples. EQL is one example that interfacing is not
>> impossible and, probably, not that hard once you can write C++ inside
>> Common Lisp code.
>>
>> But most important, the issue of interfacing Common Lisp and C++ consists
>> on many different problems that I do not see how you solve at the same time
>> with the help of LLVM
>>
>> 1. Integrating the C++ type system and the Common Lisp one
>> 2. Being able to call C++ functions from Common Lisp and viceversa
>> 3. Integrating C++ and Common Lisp memory management
>> 4. Possibly automating the generation of wrappers for C++ code.
>> 5. Resolving overloading at runtime instead of at compilation time.
>> ...
>>
>> Many issues, some of which are mentioned in SWIG,
>> http://www.swig.org/Doc1.3/SWIGPlus.html but even many of which they
>> (working long in the interface between C++ and dynamic languages) do not
>> have an answer to.
>>
>> Juanjo
>>
>> --
>> Instituto de Física Fundamental, CSIC
>> c/ Serrano, 113b, Madrid 28006 (Spain)
>> http://juanjose.garciaripoll.googlepages.com
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Ecls-list mailing list
>> Ecls-list at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ecls-list
>>
>>
>
>
> --
> Bc. Peter Vaňušanik
> http://www.bishojo.tk
>



-- 
Bc. Peter Vaňušanik
http://www.bishojo.tk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20130304/7fe9bfbe/attachment.html>