Announcement of ECL v0.9l
=========================
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 relevant for various reasons. First of all, several
important bugs have been fixed which now allow Maxima to be built
using ECL. Second, there have been serious improvements in performance
coming mainly from a better garbage collector scheme (incremental
with generations) and a threaded interpreter. In some cases this
results
in a factor 2 reduction in execution speed.
ECL 0.9l:
=========
* Implementation changes:
- NIL is now of type LIST, which is a fundamental type in ECL. This
means the
set of symbols is made by those with the type tag t_symbol plus
NIL. This
is completely hidden by the high level functions SYMBOL-NAME,
SYMBOL-PACKAGE, ... and their C counterparts.
- Objects of type LIST are now immediately recognized by having 01 in
the
least significant bits of the pointer to the object. Furthermore,
NIL is
represented by the word 0x00000001, which points nowhere. Care
should be
taken when manipulating lists and instead of accessing directly the
fields
CAR, CDR, etc, it is recommended to use the higher level functions
and
macros CONSP, LISTP, Null, ecl_car, ecl_cdr, ecl_rplaca, etc...
- Out of the LIST type, the CONS subtype is now implemented using
only two
words: one for the CAR and one for the CDR. Nevertheless, the Boehm-
Weiser
garbage collector still requires a bit more, so that it results in
no memory
gain.
* Visible changes:
- --enable-boehm=auto and --with-systemp-gmp=auto are now the default
options.
- When (>= SAFETY 1), for each compiled function, the compiler will
automatically generate CHECK-TYPE forms to ensure that the
arguments have
the values that the user declared.
- The documentation is slowly disappearing form this source tree, as
there
is a different tree (ecl-doc) which contains the XML sources for a
more
complete manual.
- RENAME-FILE now accepts a keyword argument :IF-EXISTS, which
defines the
behavior when a file with the new name already exists (Geo
Carncross).
- Improved hashing on 64-bit machines.
- The physical pathname format has changed from [device:][[//
hostname]/]...
to [[device:[//hostname]]/]... The reason is that this allows
proper
parsing of Unix pathnames such as "//usr/".
- In interpreted functions, blocks are only created when used. The
current
algorithm for detecting unused blocks is inefficient, with a
performance
penalty 2^{# unused blocks}, but this seems to pay off when running
the
interpreted code, due to decreased consing
> (defun foo () )
FOO
> (time (dotimes (i 100000) (foo)))
real time : 0.045 secs
run time : 0.048 secs
gc count : 1 times
consed : 160 bytes
Formerly, this would cons 3200192 bytes.
- When compiling object files that will form part of either a unified
FASL or
of a library (static or dynamically linked), there used to be name
collisions between the initialization functions of different
modules. Now
ECL uses a cleverer hashing algorithm to name these functions,
storing the
key in a string in the object file, which is later searched before
linking
the file. Currently the hash key only depends on the pathname of
the source
file and the universal time at which is compiled, hence there may
still be
collisions between files compiled on different machines. In short:
you should
only worry if you regularly use the function C::BUILD.
- Improved hashing of unicode strings.
- ECL ships with ASDF v1.111
- We now activate CMUCL's implementation of FORMATTER, which compiles
format
strings into lisp functions, instead of a dummy function that calls
FORMAT. This leads to some speedup when pretty-printing.
- When using (OPTIMIZE (DEBUG n)) for n >= 1, calls to functions in
the same
file are not inlined and always go through cl_funcall. This way
they show up
in backtraces in the debugger, and the function can be traced and
profiled.
- Declaration SI:C-LOCAL is deactivated by (DEBUG > 0).
- Ported CMUCL's profiler as a contributed package.
- Gray streams are now implemented in a separate package, called
GRAY, which
exports symbols such as FUNDAMENTAL-STREAM or STREAM-READ-CHAR.
- The functions CLOSE, {OPEN,INPUT,OUTPUT}-STREAM-P, STREAM-P and
STREAM-ELEMENT-TYPE are now offered in two flavors. The versions
exported by
the COMMON-LISP package are ordinary functions, the versions in the
GRAY
package are generic functions that can be specialized to new
classes. The
ordinary functions will invoke the generic version when passed a
generic
stream. Note that, for instance, CL:CLOSE and GRAY:CLOSE are not
the same
symbol. This means, if you want to specialize CLOSE, STREAM-ELEMENT-
TYPE,
etc, you might have to use the package "GRAY", as in
(defpackage "FOO" (:use "GRAY"))
or shadow import the symbols associated to generic versions in the
packages
where methods on these functions are defined.
- By user request, ECL provides a function (GRAY:REDEFINE-CL-
FUNCTIONS) which
will make the above mentioned functions generic.
- Interpreted forms now remember the file in which they were defined
and what form number they represent.
- LOAD now accepts namestrings which are of type (AND STRING (NOT
BASE-STRING))
- LAST, BUTLAST, NBUTLAST and COPY-LIST no longer detect
circularities. Speed
improvements in these and other functions.
- The compiler now optimizes calls to TYPE when the type name is
constant and
has a simple way to be checked.
- When an error is signaled either by evaluating an EVAL-WHEN form or
when
macroexpanding a form, this error is printed out and COMPILE-FILE
returns
(VALUES NIL T T). Formerly this error would be ignored.
- Interpreted forms now appear as SI:BYTECODES in the backtrace. It
is
possible to inspect these forms using :lambda-expression
> (cos 'a)
In function COS, the value of argument is
A
which is not of expected type NUMBER
Broken at SI:BYTECODES.Available restarts:
1. (USE-VALUE) Supply a new value of type NUMBER.
Broken at SI:BYTECODES.
>> :b
Backtrace: SI:BYTECODES > si:bytecodes
>> :disassemble
Evaluated form:
0 PUSH 'A
2 CALLG 1,COS
5 EXIT
>> :lambda-expression
(COS 'A)
Similarly, :lambda-expression also works for other functions that
keep
this information.
- Accessors for low-level socket timeout attributes (by G.
Carncross).
- The function EXT:OPEN-PIPE disappears, together with EXT:CLOSE-
PIPE. Use
EXT:RUN-PROCESS instead.
- New function EXT:MAKE-PIPE implements the equivalent of POSIX
pipe() but
producing a two-way stream.
- Support for large files in systems that implement fseeko().
- Added option TCP_NODELAY to the sockets package.
* CLOS:
- When caching generic function calls, ECL now uses a thread-local
hash table
instead of one hash table per generic function.
- The classes STANDARD-ACCESSOR-METHOD, STANDARD-READER-METHOD and
STANDARD-WRITER-METHOD have been implemented. These methods are
created
to access the slots of a standard class.
- ECL now permits direct slots with an allocation of type :INSTANCE
to have an
explicit location index. These are called SEALED SLOTS. This
location is
enforced by COMPUTE-SLOTS and it is inherited by other subclasses.
Conflicts
are detected and the slot index is used to optimize the slot
accessor
methods.
- ECL now adds another MOP extension, which is an option :SEALEDP
that applies
to classes and which seals all its slots, creating additional
direct slot
definitions for slots that were not sealed in parent classes.
- The compiler now recognizes access to sealed slots when the
associated classes
have already been defined and the type of arguments to the
accessors is known
(either by some explicit declaration or by induction). For low
safety or large
speed settings, this leads to inline access to such slots using the
precomputed
location.
- ECL now ships with version 1.118 of ASDF.
- ECL exports a condition EXT:INTERACTIVE-INTERRUPT, that is signaled
when the
user interrupts ECL, typically using Ctrl-C, or sending the SIGINT
signal.
* Bugs fixed:
- Intel/64bits running a 32 bits operating system caused a wrong
choice of
assembler code.
- ASDF:MAKE-BUILD now handles better the case of a monolithic FASL
that
has to include a number of other subsystems.
- We introduce a new operation, ASDF:LOAD-FASL-OP, which does the job
of
ASDF:LOAD-OP but using a single FASL file per system, thus saving
resources and allowing easier redistribution of libraries.
- The bignums produced by RANDOM did not have enough random bits.
- ECL formerly accepted spaces between the comma and the @ and .
characters
in expressions like ,@ or ,.
- Building a statically linked ECL works again.
- Equal random states now compare properly under EQUALP and their
hash keys
are also equal.
- Problems in the use of "volatile" keywords prevented ECL from
compiling
with a C++ compiler.
- The reader function for #\ was not suitable for being invoked by
the
user on an arbitrary stream.
- ECL tried to use intel-64bits assembler on 64 bits processors, even
when
compiler and the operating system work with 32bits.
- The compiler now inlines and optimizes (FUNCALL (X ..) ... ) where
X is a
macro that returns a lambda form.
- ECL no longer needs library definition files ecl.def and ecl-
threads.def
thanks to a more clever use of declarations __declspec(dllexport)
and
__declspec(dllimport).
- We no longer use the flag --rpath when building ECL. Given the fact
that
ECL now assumes a standard Unix filesystem structure, this should
pose no
problem. For nonstandard locations, you will have to define
LD_LIBRARY_PATH
- ECL now allows directory components and pathname names and types to
have
colon in their strings. A leading colon disambiguates in the
namestring
will be use to disambiguate.
":foo:bar" NAME="foo:bar"
"foo:bar" DEVICE="foo", NAME="bar" (physical pathname)
"foo:bar" HOST="foo", NAME="bar" (logical pathname)
"/e/foo:bar" DIR=(:ABSOLUTE "e"), NAME="foo:bar"
"/e/foo:bar/txt" DIR=(:ABSOLUTE "e" "foo:bar"), NAME="txt"
- LOAD-TIME-VALUE would not work as expected when its argument was a
variable
or a constant.
- MACHINE-TYPE, MACHINE-INSTANCE, SOFTWARE-VERSION and similar
functions are
now compliant and output NIL when they cannot guess the right
information.
This information is gathered from the environment variables
HOSTNAME
and HOSTTYPE (Unix), COMPUTERNAME, PROCESSOR_ARCHITECTURE,
PROCESSOR_LEVEL
(Windows) and the output of the system function uname(), if
available.
- LOG lost accuracy when applied to a complex number where the either
the
real or the imaginary part was much larger than the other one.
- Building without GMP is again supported.
- Bytecode functions can now be externalized in C compiled files.
- (FUNCALL (LOAD-TIME-VALUE ...) ...) forced the evaluation of the
argument to
LOAD-TIME-VALUE. LOAD-TIME-VALUE is now implemented as a special
operator
and not as a macro.
- Garbage collection statistics was broken for libraries other than
the one
shipped with ECL.
- When COMPILE-FILE is provided a value of :OUTPUT-FILE, the file
extension
".fas" was not automatically appended.
- Increased numerical precision on functions working with long-float
=
C long double.
- PI has to be of type LONG-FLOAT
* Optimization and performance:
- TYPEP now can be optimized if the type argument is a constant.
- ECL's bytecode interpreter now uses indirect threading.
* System design:
- We introduce a new kind of lisp objects, the stack frames. These
are objects
with dynamical extent, which work as adjustable arrays and are
mainly used
for collecting the arguments of a function, in MAP, MAPCAR, APPLY,
FUNCALL,
MULTIPLE-VALUE-CALL, etc.
- On some platforms (intel/32bits) there exist hand-optimized
assembly
routines that implement APPLY in various forms (fixed # arguments,
variable
#, closures) They save about 40kb code in Mac OSX, for instance,
and do not
impact performance. This has to be activated with --enable-asmapply
at
configuration time (Still experimental)
- ECL now offers the possibility to use conses which do not carry
type
information. These conses have a size of two words and lead to
significantly
faster code, as well as less memory consumption.
On Aug 6, 12:09 am, Juanjo <·····················@googlemail.com>
wrote:
> Announcement of ECL v0.9l
Would like to give some reasons why I prefer ECL over other current
Lisp implementations:
(1) The 3 main OSs which I need to support do all seem to be written
in, well: (((C))).
(2) It's LGPL.
(3) ECL is quite 'minimalistic' in both size and startup time (could
this be related to (1)?!)
(4) Integrating with C (and, to a minor extent, C++) libs is simply
straightforward, with no real overhead between Lisp and C (given the
static FFI, quite identical to UFFI).
(5) Returning to (1): it's (quite) equally stable on all supported
platforms (in my experience).
-PM
········@gmail.com wrote:
> On Aug 6, 12:09 am, Juanjo <·····················@googlemail.com>
> wrote:
>> Announcement of ECL v0.9l
>
> Would like to give some reasons why I prefer ECL over other current
> Lisp implementations:
>
> (1) The 3 main OSs which I need to support do all seem to be written
> in, well: (((C))).
> (2) It's LGPL.
> (3) ECL is quite 'minimalistic' in both size and startup time (could
> this be related to (1)?!)
> (4) Integrating with C (and, to a minor extent, C++) libs is simply
> straightforward, with no real overhead between Lisp and C (given the
> static FFI, quite identical to UFFI).
> (5) Returning to (1): it's (quite) equally stable on all supported
> platforms (in my experience).
>
> -PM
Too bad I can't use it on the iPhone (first Apple's restrictions, then
ECL's LGPL).
On Aug 6, 6:49 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> Too bad I can't use it on the iPhone (first Apple's restrictions, then
> ECL's LGPL).
Yes. Damn closed platform!
On Aug 6, 11:49 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> Too bad I can't use it on the iPhone (first Apple's restrictions, thenECL'sLGPL).
Unless Apple explicitely prohibits LGPL, this license is extremely
liberal. This is neither GPL 2 nor the evil GPL 3. I mean, our license
even allows you to sell commercial applications in which you only have
to leave the ECL component public and open source. If you write
whatever gui, libraries, algorithms, etc, which do not affect or
improve the lisp core and contributed libraries, you are not required
to provide us with anything other the possibility of upgrading you
binaries with a better version of ECL. So please do not bash LGPL as a
license.
Juanjo