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.garciarip...@gmail.com> wrote:
>
> On Wed, Apr 17, 2013 at 9:55 PM, Anton Vodonosov <avodono...@yandex.ru> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
