Christian Schafmeister | 4 Mar 17:30 2013
Picon
Picon

Announce: A new C++ based implementation of Common Lisp based on the ECL CL code


Hi,

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.
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'll be open sourcing this in a few months - once I get it cleaned up a bit.

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.

This implementation uses the LLVM library as its back-end and generates Just-In-Time compiled native
machine code Just-In-Time.

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.

Going forward I would love to work with the ECL community and commonly host and develop the same Common Lisp
source code even if our underlying cores and compilers are very different.

Cheers,
(Continue reading)

Juan Jose Garcia-Ripoll | 4 Mar 22:23 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> 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@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Christian Schafmeister | 5 Mar 01:33 2013
Picon
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code


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

On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> 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.

I needed a CL interpreter which would host the compiler (which I wrote in Common Lisp) which calls the LLVM-IR library to generate llvm::Module objects which contains llvm::Function objects that are Just-In-Time compiled into machine code and called via C function pointers from the Common Lisp or C++ code. 
I did not want to write a Common Lisp compiler in C++ (shudder).
This project started as an archaic Sexp walking Lisp interpreter that grew into a very slow Common Lisp Sexp walking interpreter within which I wrote a reasonably fast self-hosting Common Lisp compiler that generates LLVM-IR.

 
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.

I didn't know that when I started. I know that now - the bridge doesn't require the compiler and LLVM backend 
- the CL/C++ bridge is all C++ template programming, lots and lots of template programming. 
It's styled after the boost::python library if you are familiar with it.
Once I started writing the compiler and exposing and using the LLVM backend I just kept going.
Although, having intimate familiarity with the Common Lisp implementation I wrote has greatly facilitated the development of the bridge.

 
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.

I did not state that ECL cannot interface with C++ - I know better than that. 

On the other hand, I need it to be very easy to interface CL to C++ because I have a lot of C++ and nothing I saw in the CL world seemed to do the job.

Now if I want to interface a C++ function foo(int x, double y) to CL I add the following code to my C++ code.

af_def("CORE","foo",&foo);

Or the macro:
Defun(foo);

That's it for simple cases.  If the function needs lambda-list processing then it is:
af_def("CORE","foo",&foo,"(x y &optional (z 999))");

That specifies the package, the function-name in CL, the pointer to the function and the lambda-list as a string which is parsed and associated with the wrapper for the function.

If I want to expose the C++ class Foo with method Foo::bar (default lambda-list processing) and Foo::baz (lambda-list processing)  I currently copy-and-paste-and-edit a wrapper class Foo_O into a header file (I should be able to eliminate the need for this with more template programming) and I add the following to my C++ code.

class_<Foo_O>()
    .def("bar",&Foo::bar)
    .def("baz",&Foo::baz,"(a b &key (gamma (+ a b) gamma-p))")
;

That's it for this simple example.  Different function arity, lambda-list processing, argument type-conversion, result-conversion, memory-management, multiple and single inheritance, virtual-function handling is all done automatically with C++ template programming.

We could get it to work with ECL as well if you want it - although it's going to take some work.
Then we could incorporate the LLVM-IR generating compiler into ECL.



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.

SWIG ran out of steam for me pretty early on. 

I've had to develop solutions to all of these problems - so I'm familiar with them.

1) C++ classes behave like CL structures.
2) C++ functions calling CL and vice versa is taken care of.
3) Memory management is currently handled using reference counted C++ shared_ptr/weak_ptr.  I plan to add mark-and-sweep GC later.
4) Virtual functions, regular functions and overloaded functions are all handles. When you have overloaded functions with different types you have to disambiguate them by getting a pointer to each function. There is no way to avoid this.


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@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Juan Jose Garcia-Ripoll | 5 Mar 13:59 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

On Tue, Mar 5, 2013 at 1:33 AM, Christian Schafmeister <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> wrote:
I needed a CL interpreter which would host the compiler (which I wrote in Common Lisp) which calls the LLVM-IR library to generate llvm::Module objects which contains llvm::Function objects that are Just-In-Time compiled into machine code and called via C function pointers from the Common Lisp or C++ code. 
I did not want to write a Common Lisp compiler in C++ (shudder).
This project started as an archaic Sexp walking Lisp interpreter that grew into a very slow Common Lisp Sexp walking interpreter within which I wrote a reasonably fast self-hosting Common Lisp compiler that generates LLVM-IR.

It would have been easier to rely on ECL's interpreter to do that. It is very small and the bytecodes interpreter already may run _all_ of Common Lisp at a reasonable speed.
 
I didn't know that when I started. I know that now - the bridge doesn't require the compiler and LLVM backend 
- the CL/C++ bridge is all C++ template programming, lots and lots of template programming. 
It's styled after the boost::python library if you are familiar with it.
Once I started writing the compiler and exposing and using the LLVM backend I just kept going.
Although, having intimate familiarity with the Common Lisp implementation I wrote has greatly facilitated the development of the bridge.

I did not know about Boost::Python. On reading it, it seems that, though horrible, it would be easy to port to any Common Lisp out there. If I were to write that, though, I would not do it as they do, with such undecipherable template code -- templates perhaps yes, but at least attempting something more readable.
 
We could get it to work with ECL as well if you want it - although it's going to take some work.

As I said, I believe this can be ported to _any_ Common Lisp. 
 
Then we could incorporate the LLVM-IR generating compiler into ECL.

I would love this, but I would love it even more if the LLVM-IR used the current compiler -- we do some pretty nifty optimizations and type inference there which any too straightforward LLVM implementation will miss.
 
1) C++ classes behave like CL structures.

They are opaque, then, not exposing any inheritance? Or do you allow class B which inherits from A to use the same functions as A? Do you expose methods from inherited classes with the same name, as in Python, or with different names, as in SWIG?
 
3) Memory management is currently handled using reference counted C++ shared_ptr/weak_ptr.  I plan to add mark-and-sweep GC later.

Even with shared_ptr there are problems. Note the examples of SWIG, where you have class class A { class B *b; } and then return field "b" of A to Common Lisp. How do you handle ownership there? Boost::Python is mind bloging and too ugly / fragile in this respect.

Best,

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@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Christian Schafmeister | 5 Mar 19:15 2013
Picon
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code


Juanjo,

To summarize - I needed a Common Lisp implementation that interfaced well with C++ so I wrote one rather than use an existing CL implementation.  
By "interface well" I mean interface functions are generated automatically and much of the horribleness that is C++ is handled by template programming. 
I don't want to argue about whether implementing my own CL was a good or bad choice because I did it and I learned an awful lot.

I borrow a lot of Common Lisp code from the ECL distribution and I think I have something to give back to ECL in the interests of cooperation (C++ integration and LLVM-JIT compilation).  The LLVM-JIT compilation builds on the C++ integration.

I'm going to keep working on it and I'm going to release it because there are several people on #lisp who have expressed an interest in it and I'd love to get more advice and input from the CL community on how to improve it.

If you would like to integrate it into ECL (the C++ integration and LLVM-JIT compilations) I'm happy to help out.



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

On Tue, Mar 5, 2013 at 1:33 AM, Christian Schafmeister <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> wrote:
I needed a CL interpreter which would host the compiler (which I wrote in Common Lisp) which calls the LLVM-IR library to generate llvm::Module objects which contains llvm::Function objects that are Just-In-Time compiled into machine code and called via C function pointers from the Common Lisp or C++ code. 
I did not want to write a Common Lisp compiler in C++ (shudder).
This project started as an archaic Sexp walking Lisp interpreter that grew into a very slow Common Lisp Sexp walking interpreter within which I wrote a reasonably fast self-hosting Common Lisp compiler that generates LLVM-IR.

It would have been easier to rely on ECL's interpreter to do that. It is very small and the bytecodes interpreter already may run _all_ of Common Lisp at a reasonable speed.
 

Probably, but I didn't know how to use the ECL byte-code interpreter so I wrote my own.
Yours is quite a bit faster than mine and is undoubtably more robust.
As far as I can tell mine is complete albeit slow but I only need mine to bootstrap the compiler.
Since my compiler has JIT compilation I do compile-in-eval once it boots and then everything gets a lot faster.

I didn't know that when I started. I know that now - the bridge doesn't require the compiler and LLVM backend 
- the CL/C++ bridge is all C++ template programming, lots and lots of template programming. 
It's styled after the boost::python library if you are familiar with it.
Once I started writing the compiler and exposing and using the LLVM backend I just kept going.
Although, having intimate familiarity with the Common Lisp implementation I wrote has greatly facilitated the development of the bridge.

I did not know about Boost::Python. On reading it, it seems that, though horrible, it would be easy to port to any Common Lisp out there. If I were to write that, though, I would not do it as they do, with such undecipherable template code -- templates perhaps yes, but at least attempting something more readable.

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.

For a comparison of the boost::python (template programming) approach and the SWIG parse/code-generation approach see: https://dev.lsstcorp.org/trac/wiki/SwigVsBoostPython

 
We could get it to work with ECL as well if you want it - although it's going to take some work.

As I said, I believe this can be ported to _any_ Common Lisp. 

"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.  
I don't think it will be much trouble to port what I've done to ECL - other CL's… I don't know anything about their internals.
Doing it the SWIG way - that's a different question.

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.

 
Then we could incorporate the LLVM-IR generating compiler into ECL.

I would love this, but I would love it even more if the LLVM-IR used the current compiler -- we do some pretty nifty optimizations and type inference there which any too straightforward LLVM implementation will miss.
 
1) C++ classes behave like CL structures.

They are opaque, then, not exposing any inheritance? Or do you allow class B which inherits from A to use the same functions as A? Do you expose methods from inherited classes with the same name, as in Python, or with different names, as in SWIG?

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.

 
3) Memory management is currently handled using reference counted C++ shared_ptr/weak_ptr.  I plan to add mark-and-sweep GC later.

Even with shared_ptr there are problems. Note the examples of SWIG, where you have class class A { class B *b; } and then return field "b" of A to Common Lisp. How do you handle ownership there? Boost::Python is mind bloging and too ugly / fragile in this respect.

Memory management is complicated, there is no way around that. 
If I return a shared_ptr from C++ to CL, it is no trouble as all objects in CL are handled with shared_ptrs. 
They are reference counted and destructed when their ref. count goes to zero.
If I return a raw pointer from C++ to CL it is wrapped in a class that is told what to do with that pointer when the wrapper class is destructed.  It can be told to leave it alone or own it and destroy it when the wrapper is destructed.



Best,

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com

Cheers,

.Chris.



------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Juan Jose Garcia-Ripoll | 5 Mar 23:41 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

On Tue, Mar 5, 2013 at 7:15 PM, Christian Schafmeister <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> 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.

"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;
};

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
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Christian Schafmeister | 6 Mar 04:51 2013
Picon
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code


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-H+0wwilmMs3R7s880joybQ@public.gmane.org> 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

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Juan Jose Garcia-Ripoll | 31 Mar 21:49 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

On Tue, Mar 5, 2013 at 1:59 PM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I did not know about Boost::Python. On reading it, it seems that, though horrible, it would be easy to port to any Common Lisp out there. If I were to write that, though, I would not do it as they do, with such undecipherable template code -- templates perhaps yes, but at least attempting something more readable.

I have given it a try https://github.com/juanjosegarciaripoll/cl-cxx

It is indeed not that hard to define wrappers for C++ functions using templates as they seem to properly dispatch among functions with different arities. Implicit or explicit conversions are also easy to implement, given the proper Common Lisp back-end.

Best,

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Gabriel Dos Reis | 1 Apr 01:16 2013

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

> I have given it a try https://github.com/juanjosegarciaripoll/cl-cxx
>
> It is indeed not that hard to define wrappers for C++ functions using
> templates as they seem to properly dispatch among functions with different
> arities. Implicit or explicit conversions are also easy to implement, given
> the proper Common Lisp back-end.

I just quickly glanced over the code.  I noticed that some of the constructs

   https://github.com/juanjosegarciaripoll/cl-cxx/blob/master/include/cl-cxx/defun.hpp

are C++03 ways of emulating lambda-expressions.  C++11 has better support
for those.

-- Gaby

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
Juan Jose Garcia-Ripoll | 1 Apr 09:40 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code


On Mon, Apr 1, 2013 at 1:16 AM, Gabriel Dos Reis <gdr <at> integrable-solutions.net> wrote:
I just quickly glanced over the code.  I noticed that some of the constructs

   https://github.com/juanjosegarciaripoll/cl-cxx/blob/master/include/cl-cxx/defun.hpp

are C++03 ways of emulating lambda-expressions.  C++11 has better support
for those.

I know, but I do not have C++11 in all the machines I work with.


--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Juan Jose Garcia-Ripoll | 13 Apr 00:21 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

On Mon, Apr 1, 2013 at 9:40 AM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I know, but I do not have C++11 in all the machines I work with.

Despite this, I have managed to advance a bit without cluttering the code too much. A few tenths of lines more and the interface can now handle functions with reference arguments, working as SBCL does: the I/O arguments are returned as extra return values.

An example of the code that can be written is below. Still, there are things to be handled, like functions with void return values, but a minimal portable and very understandable interface can be built using Christian's idea

An excerpt of test/test_defun.cc

  int f_int_int_ref(int &i) {
    int output = i + 1;
    i = i + 2;
    return output;
  }

  TEST(Defun, DefunIntRef1) {
    /* Defines a function that returns two values: "output"
     * and the value of the reference. */
    defun("FOO", f_int_int_ref);
    ASSERT_T(eval_string("(EQUAL (MULTIPLE-VALUE-LIST (FOO 0)) '(1 2))"));
    ASSERT_T(eval_string("(EQUAL (MULTIPLE-VALUE-LIST (FOO 1)) '(2 3))"));
    ASSERT_T(eval_string("(EQUAL (MULTIPLE-VALUE-LIST (FOO 2)) '(3 4))"));
  }

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Anton Vodonosov | 16 Mar 14:39 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

05.03.2013, 01:25, "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.
 
As ECL can compiles List to C, a C compiler generating LLVM code may be used
(llvm-gcc or clang).
 
Juan Jose, Christian, how can you compare Lisp -> C -> LLVM with Lisp -> LLVM
solution to ECL?
 
My understantind (pure theoretical, I haven't tried any of that):
if ECL can generate LLVM directly, it is a simplification to user, less tools to chain.
But Lisp to LLVM required efforts to implement and will also take mainenance efforts.
Christian, have you compared these options, or you were just guided by interest
to learn/try your own Lisp -> LLVM implementation?
 
Best regards,
- Anton
 
------------------------------------------------------------------------------
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_mar
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Matthew Mondor | 16 Mar 15:25 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

On Sat, 16 Mar 2013 17:39:07 +0400
Anton Vodonosov <avodonosov@...> wrote:

> Christian, have you compared these options, or you were just guided by interest
> to learn/try your own Lisp -> LLVM implementation?

There seems to be an issue with the mail, claimed as text/html only and
with malformed HTML, so it was displayed as an unformatted html/text
blob by my reader.  The message archive also cannot display it properly
at http://sourceforge.net/mailarchive/message.php?msg_id=30607444.  I
could read it but with some difficulty.  Just to let you know.

Thanks,
--

-- 
Matt

------------------------------------------------------------------------------
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_mar
Anton Vodonosov | 16 Mar 15:29 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

[re-posting the message in text, to fix the formatting issue]

05.03.2013, 01:25, "Juan Jose Garcia-Ripoll" <juanjose.garciaripoll@...>:
> On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister
<chris.schaf@...> 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.

As ECL can compiles List to C, a C compiler generating LLVM code may be used
(llvm-gcc or clang).

Juan Jose, Christian, how can you compare Lisp -> C -> LLVM with Lisp -> LLVM
solution to ECL?

My understantind (pure theoretical, I haven't tried any of that):
if ECL can generate LLVM directly, it is a simplification to user, less tools to chain.
But Lisp to LLVM required efforts to implement and will also take mainenance efforts.
Christian, have you compared these options, or you were just guided by interest
to learn/try your own Lisp -> LLVM implementation?

Best regards,
- Anton

------------------------------------------------------------------------------
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_mar
Juan Jose Garcia-Ripoll | 16 Mar 23:08 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code


On Sat, Mar 16, 2013 at 3:29 PM, Anton Vodonosov <avodonosov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> wrote:
As ECL can compiles List to C, a C compiler generating LLVM code may be used
(llvm-gcc or clang).

What Christian is doing is more what I thought should be done: automatically generating LLVM bytecode and loading it with LLVM, so that it is natively compiled. Using clang is not really winning anything: one may just as well use any other C ocmpiler
 
Juan Jose, Christian, how can you compare Lisp -> C -> LLVM with Lisp -> LLVM
solution to ECL?
My understantind (pure theoretical, I haven't tried any of that):
if ECL can generate LLVM directly, it is a simplification to user, less tools to chain.
But Lisp to LLVM required efforts to implement and will also take mainenance efforts.
Christian, have you compared these options, or you were just guided by interest
to learn/try your own Lisp -> LLVM implementation?

ECL's current compiler generates C, but this is done on a second pass that may be abstracted out to use a different backend. This is what I was trying with the new compiler, but I found I do not have enough time for doing the compiler as well as the backend -- at least not in the near future. However, if Christian's tools for the generation of LLVM code are readable enough, I believe they could be used with ECL as well, coexisting with the C backend.

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_mar
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Anton Vodonosov | 16 Mar 23:18 2013
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code


17.03.2013, 02:08, "Juan Jose Garcia-Ripoll" <juanjose.garciaripoll@...>:
> On Sat, Mar 16, 2013 at 3:29 PM, Anton Vodonosov
<avodonosov@...> wrote:
>> As ECL can compiles List to C, a C compiler generating LLVM code may be used
>> (llvm-gcc or clang).
>
> What Christian is doing is more what I thought should be done: automatically generating LLVM bytecode and
loading it with LLVM, so that it is natively compiled. Using clang is not really winning anything: one may
just as well use any other C ocmpiler

There is a potential win: LLVM may be compiled not only to native code. 

My primary interest is javascript, see here: https://github.com/kripken/emscripten
I dream about full CL in browser :)

>> Juan Jose, Christian, how can you compare Lisp -> C -> LLVM with Lisp -> LLVM
>> solution to ECL?
>> My understantind (pure theoretical, I haven't tried any of that):
>> if ECL can generate LLVM directly, it is a simplification to user, less tools to chain.
>> But Lisp to LLVM required efforts to implement and will also take mainenance efforts.
>> Christian, have you compared these options, or you were just guided by interest
>> to learn/try your own Lisp -> LLVM implementation?
>
> ECL's current compiler generates C, but this is done on a second pass that may be abstracted out to use a
different backend. This is what I was trying with the new compiler, but I found I do not have enough time for
doing the compiler as well as the backend -- at least not in the near future. However, if Christian's tools
for the generation of LLVM code are readable enough, I believe they could be used with ECL as well,
coexisting with the C backend.
>

Aha, OK (I hope I understood what you mean).

------------------------------------------------------------------------------
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_mar
Christian Schafmeister | 16 Mar 23:21 2013
Picon
Picon

Re: Announce: A new C++ based implementation of Common Lisp based on the ECL CL code

Anton,

The compiler I'm writing uses the LLVM API to generate LLVM-IR directly which is just-in-time compiled to executable code.
Using (setq XXX (COMPILE nil (lambda (x) (* 3 x)))) returns a compiled function that can be evaluated directly using (FUNCALL XXX 4) --> 12.
There are no intermediate compilers that need to be run to generate executable code.

I am guided by my own interest to learn/try my own Common Lisp --> LLVM implementation.


Best,

.Chris.


On Mar 16, 2013, at 9:39 AM, Anton Vodonosov <avodonosov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> wrote:

05.03.2013, 01:25, "Juan Jose Garcia-Ripoll" <juanjose.garciaripoll <at> gmail.com>:
On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> 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.
 
As ECL can compiles List to C, a C compiler generating LLVM code may be used
(llvm-gcc or clang).
 
Juan Jose, Christian, how can you compare Lisp -> C -> LLVM with Lisp -> LLVM
solution to ECL?
 
My understantind (pure theoretical, I haven't tried any of that):
if ECL can generate LLVM directly, it is a simplification to user, less tools to chain.
But Lisp to LLVM required efforts to implement and will also take mainenance efforts.
Christian, have you compared these options, or you were just guided by interest
to learn/try your own Lisp -> LLVM implementation?
 
Best regards,
- Anton
 

------------------------------------------------------------------------------
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_mar
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Anton Vodonosov | 17 Apr 21:55 2013
Picon

Porting CL to new platforms: what can be reused?

05.03.2013, 01:25, "Juan Jose Garcia-Ripoll" <juanjose.garciaripoll@...>:
> On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister
<chris.schaf@...> 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.

Hello.

I often think about porting Common Lisp to new platforms. Especially I am interested
in CL implementation able to compile to Javascript compiler which can work in browser.

In theory CL core consists of 25 special operators + build-in data types. Everything else
is a library. So when porting to a new platform, theoretically, all we need to reimplement
is a compiler understanding 25 operators + some build-in functions representing datatypes
(make-array, aref, cons, etc) and some basic reader, allowing to read the source code of the library.

How close this theoretical view to practice? We now have several open-source CL implementations.
If one wants to create a Javascript port, what else he must be prepared to solve?

How convenient basis the ECL codebase would be for such a port?

Best regards,
- Anton

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
Juan Jose Garcia-Ripoll | 18 Apr 15:10 2013
Picon

Re: Porting CL to new platforms: what can be reused?


On Wed, Apr 17, 2013 at 9:55 PM, Anton Vodonosov <avodonosov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> wrote:
In theory CL core consists of 25 special operators + build-in data types. Everything else
is a library. So when porting to a new platform, theoretically, all we need to reimplement
is a compiler understanding 25 operators + some build-in functions representing datatypes
(make-array, aref, cons, etc) and some basic reader, allowing to read the source code of the library.

That is indeed the theory. In practice much of the library deals with operating system stuff: memory allocation, files, etc. That forces a low level implementation of several core structures. Moreover, several functions are critical for performance and are also hard-coded to make bootstrapping faster.
 
How close this theoretical view to practice? We now have several open-source CL implementations.
If one wants to create a Javascript port, what else he must be prepared to solve?

ECL is pretty well isolated: the C library works like the lisp API and offers a number of functions that one may start with. Many of those functions could _nowadays_ be ported back to Common Lisp, using the fact that the compiler is more efficient. But there are critical things, such as the filesystem, running processes, or I/O operations, that would be hard to implement from scratch.

Perhaps Christian could comment, given that he is using the ECL Common Lisp base to implement a LLVM-based Common Lisp implementation

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Christian Schafmeister | 4 May 03:10 2013
Picon
Picon

Re: Porting CL to new platforms: what can be reused?

Anton,

I've just managed to host much of the ECL Common Lisp code on a C++ core that was built completely from scratch.
I just got ECL-CLOS and generic function dispatching to compile and run a few days ago.
I've exposed the LLVM C++ library to Common Lisp and written a new self-hosting compiler in CL.
I also wrote an S-expression walking CL interpreter to bootstrap the compiler.

It's taken me about a year working about 8 hours a day.  It's my first time and I have no previous experience with Common Lisp.

Juanjo is absolutely correct, it's the interactions of the CL code with the lower level code that require a lot of time to implement properly. 
This involves a lot of implementation dependent stuff that are not described in the CL standard.

When I started seriously trying to host the ECL code I had Juanjo's excellent ECL C-code to help me understand what the low-level functionality did. 

Also, very important details like lexical environments are not described at all well in the CL standard and you need to do a lot of code refactoring to get something that works properly in the end.

Also, tracking down subtle bugs that I introduced because I didn't exactly implement standard Common Lisp behavior the first, second or third time around has taken a lot of my time.

Best,

.Chris.



On Apr 18, 2013, at 9:10 AM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll <at> gmail.com> wrote:


On Wed, Apr 17, 2013 at 9:55 PM, Anton Vodonosov <avodonosov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> wrote:
In theory CL core consists of 25 special operators + build-in data types. Everything else
is a library. So when porting to a new platform, theoretically, all we need to reimplement
is a compiler understanding 25 operators + some build-in functions representing datatypes
(make-array, aref, cons, etc) and some basic reader, allowing to read the source code of the library.

That is indeed the theory. In practice much of the library deals with operating system stuff: memory allocation, files, etc. That forces a low level implementation of several core structures. Moreover, several functions are critical for performance and are also hard-coded to make bootstrapping faster.
 
How close this theoretical view to practice? We now have several open-source CL implementations.
If one wants to create a Javascript port, what else he must be prepared to solve?

ECL is pretty well isolated: the C library works like the lisp API and offers a number of functions that one may start with. Many of those functions could _nowadays_ be ported back to Common Lisp, using the fact that the compiler is more efficient. But there are critical things, such as the filesystem, running processes, or I/O operations, that would be hard to implement from scratch.

Perhaps Christian could comment, given that he is using the ECL Common Lisp base to implement a LLVM-based Common Lisp implementation

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Sylvain Ageneau | 18 Apr 16:21 2013
Picon

Re: Porting CL to new platforms: what can be reused?

Hello,

If your goal is to have a lisp implementation running in your browser, there's another approach which I think is interesting: Google developed this technology for Chrome/Chromium called "Native client" (https://code.google.com/p/nativeclient/) which allows running native code in Chrome in a sandboxed environment. 

You can check my experiments with it here: https://github.com/ageneau/ecl-android. It includes a sample ECL REPL web application based on "hterm". Compiling ECL for this toolchain requires very little changes to ECL itself.

Unfortunately it looks like other browsers won't pick up the technology so this is limited to Chrome/Chromium.

Current limitations:
* Single threaded -> This is because NaCL doesn't have sigprocmask
* File system access not implemented
* GMP/MPIR uses the fallback C implementation so is probably not very performant

Regards,
Sylvain


On Thu, Apr 18, 2013 at 10:10 AM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

On Wed, Apr 17, 2013 at 9:55 PM, Anton Vodonosov <avodonosov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> wrote:
In theory CL core consists of 25 special operators + build-in data types. Everything else
is a library. So when porting to a new platform, theoretically, all we need to reimplement
is a compiler understanding 25 operators + some build-in functions representing datatypes
(make-array, aref, cons, etc) and some basic reader, allowing to read the source code of the library.

That is indeed the theory. In practice much of the library deals with operating system stuff: memory allocation, files, etc. That forces a low level implementation of several core structures. Moreover, several functions are critical for performance and are also hard-coded to make bootstrapping faster.
 
How close this theoretical view to practice? We now have several open-source CL implementations.
If one wants to create a Javascript port, what else he must be prepared to solve?

ECL is pretty well isolated: the C library works like the lisp API and offers a number of functions that one may start with. Many of those functions could _nowadays_ be ported back to Common Lisp, using the fact that the compiler is more efficient. But there are critical things, such as the filesystem, running processes, or I/O operations, that would be hard to implement from scratch.

Perhaps Christian could comment, given that he is using the ECL Common Lisp base to implement a LLVM-based Common Lisp implementation

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ecls-list mailing list
Ecls-list-5NWGOfrQmnetEtDZOKyKiw@public.gmane.orgrge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list

Gmane