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.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
>
>
> ------------------------------------------------------------------------------
> 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@lists.sourceforge.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
