ANN: ECL 9.4.0

Discussion of Common Lisp

ANN: ECL 9.4.0

Postby jjgarcia » Sat Apr 04, 2009 6:23 am

Announcement of ECL v9.4.0
==========================

ECL stands for Embeddable Common-Lisp. The ECL project aims to produce an
implementation of the Common-Lisp language which complies to the ANSI X3J13
definition of the language.

The term embeddable refers to the fact that ECL includes a lisp to C compiler,
which produces libraries (static or dynamic) that can be called from C
programs. Furthermore, ECL can produce standalone executables from your lisp
code and can itself be linked to your programs as a shared library.

ECL supports the operating systems Linux, FreeBSD, NetBSD, OpenBSD, Solaris (at
least v. 9), Microsoft Windows and OSX, running on top of the Intel, Sparc,
Alpha and PowerPC processors. Porting to other architectures should be rather
easy.

ECL is currently hosted at Common-Lisp.net and SourceForge. The home page of
the project is http://ecls.sourceforge.net, and in it you will find source code
releases, a CVS tree and some useful documentation.


Notes for this release
======================

This release is the first one with a new design of ECL, which includes changes
in the way streams are implemented, support for full Unicode character set,
safety against interrupts and serious performance improvements.

Known issues:

+ Threads and Unicode currently do not work in the Windows port.


Changes since 8.12.0
====================

See file src/CHANGELOG or browse it online

http://common-lisp.net/cgi-bin/viewcvs. ... iew=markup
jjgarcia
 
Posts: 38
Joined: Mon Oct 13, 2008 2:48 pm

Re: ANN: ECL 9.4.0

Postby Jasper » Sun Apr 05, 2009 6:39 am

Maybe i should read your source code before i post this, but this forum is quiet enough ;)

I wrote a little about how i convert to other languages from Langs resolved output. Here is the bit that is relevant:
From that last one one also, of course wants to convert to something that can actually execute. I used to have a rather ugly function to convert to C directly. The problem with that is that C does not have higher order functions or bodies inside function arguments.

The older solution solved that in the conversion itself, which is probably why it stunk so much. The newer version works differently; it uses conversion functions that can only convert a subset of Lang.

However, i add transformations that change Lang code such that it is in those subsets. That way, if i want to add conversions to other languages, it should be easy, unless the language a smaller subset then previously encountered. In that case, i would have to make another transformation. I might be overconfident here, though.
Jasper
 
Posts: 209
Joined: Fri Oct 10, 2008 8:22 am
Location: Eindhoven, The Netherlands

Re: ANN: ECL 9.4.0

Postby jjgarcia » Sun Apr 05, 2009 8:45 am

Jasper wrote:I wrote a little about how i convert to other languages from Langs resolved output.


The current version of ECL compiles directly from some internal tree representation to C. The new version of the compiler I am working on with a small SSA languange, is probably closer to what you do or want to do: a sufficiently simple language that can be transformed to bytecodes, C, etc, and where higher level details (function objects, high level control flow structures, etc) have been already abstracted.
jjgarcia
 
Posts: 38
Joined: Mon Oct 13, 2008 2:48 pm

Re: ANN: ECL 9.4.0

Postby Wodin » Sun Apr 12, 2009 12:51 pm

jjgarcia wrote:[...]The new version of the compiler I am working on with a small SSA languange, is probably closer to what you do or want to do: a sufficiently simple language that can be transformed to bytecodes, C, etc[...]

Are there any plans to produce JVM, .Net CLR, Parrot or LLVM bytecode?
Wodin
 
Posts: 56
Joined: Sun Jun 29, 2008 8:16 am

Re: ANN: ECL 9.4.0

Postby jjgarcia » Mon Apr 13, 2009 7:55 am

Wodin wrote:
jjgarcia wrote:[...]The new version of the compiler I am working on with a small SSA languange, is probably closer to what you do or want to do: a sufficiently simple language that can be transformed to bytecodes, C, etc[...]

Are there any plans to produce JVM, .Net CLR, Parrot or LLVM bytecode?


JVM, .Net and Parrot would force us to rewrite the whole of the core library that provides data structures (lists, streams, classes, etc). LLVM is definitely a more realistic option, since it allows to expose the whole of the C library to the LLVM code.
jjgarcia
 
Posts: 38
Joined: Mon Oct 13, 2008 2:48 pm


Return to Common Lisp

Who is online

Users browsing this forum: Yahoo [Bot] and 2 guests

cron