b1cf56806d
According to the CLHS: > If a DEFCLASS form appears as a top level form, [...] the compiler must make the class definition available to be returned by FIND-CLASS when its environment argument is a value received as the environment parameter of a macro. We already store type definitions in the compiler environment, so we can just reuse that. While The metaobject protocol doesn't specify what happens when compiling DEFCLASS, only what happens when executing it (see https://franz.com/support/documentation/mop/concepts.html#compile-file), real life software breaks when we try to create a full class object at compile time. Therefore, we just create a dummy forward-referenced class object which contains nothing more than a name. |
||
|---|---|---|
| contrib | ||
| examples | ||
| msvc | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| appveyor.yml | ||
| CHANGELOG | ||
| configure | ||
| COPYING | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.in | ||
| README.md | ||
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 Lisp code and can itself be linked to your programs as a shared library. It also features an interpreter for situations when a C compiler isn't available.
ECL supports the operating systems Linux, FreeBSD, NetBSD, DragonFly BSD, OpenBSD, Solaris (at least v. 9), Microsoft Windows (MSVC, MinGW and Cygwin) and OSX, running on top of the Intel, Sparc, Alpha, ARM and PowerPC processors. Porting to other architectures should be rather easy.