Hi all,
In what could turn out to be the most important event for the Common Lisp
community this decade, Peter Graves (the developer of ArmedBear Common
Lisp (hereinafter "ABCL")), relicensed his compiler on 21 July 2004:
<http://sourceforge.net/mailarchive/forum.php?thread_id=5178024&forum_id=9737>
The new exception permits the linking of ABCL "with independent modules to
produce an executable, regardless of the license terms of these
independent modules, and to copy and distribute the resulting executable
under terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that module."
GNU Classpath (GNU's core Java libraries) is licensed with a similar
exception (Peter Graves calls ABCL "this software" whereas GNU Classpath
is called "this library").
This GPL+exception licence is more permissive than the Lesser GPL since
static linking with independent modules is expressly permitted. An
independent module is defined as "a module which is not derived from or
based on this software." There is no longer uncertainty that the act of
dynamic or static linking of independently developed code creates a
derived work.
A very nice quality of the licence is that everyone may extend the
exception to new versions of the software. The Common Lisp community can
grow to depend upon the implementation with the long term security that
forking is always an option.
Peter Graves' expressed interpretation of the licence has been entirely
sensible and it resolves any ambiguities as to whether one may access
internal functions of ABCL via an "independent module":
<http://sourceforge.net/mailarchive/forum.php?thread_id=4977907&forum_id=10173>
Well, if you MODIFY the internals of ABCL, you've created a derived
work, and you need to publish the source of the modified ABCL. You
don't need to GPL the application that you've built on top of the
modified (or unmodified) ABCL, and you don't need to publish the
application's source (but you are free to do so if you want).
If you don't modify anything in the ABCL distribution, but (for
example) your code calls some internal ABCL function, then you're
still OK, as far as I'm concerned, from a legal point of view.
From a technical point of view, internal functions (or, for that
matter, any function whatsoever) may go away at any time, so your code
might not run without modification on a newer version of ABCL. That's
a technical problem, but not a legal one, as I see it. It's no problem
at all if you just ship a snapshot of ABCL that you're happy with, and
you don't care about running that same exact code on a newer version of
ABCL that might not contain the function in question.
Brilliant. I suspect the first casualty of this relicensing will be CLISP
popularity as at least one CLISP developer has a rather novel view of
their licence exception (e.g. incorporating an external function like
EXT:CD explicitly in user code (to change the current directory) requires
the user's code to be GPLed if distributed when it only runs upon CLISP).
Furthermore ABCL can run upon far more advanced Just in Time compilers.
CLISP has a plain bytecode interpreter. Obviously CLISP is presently much
faster for some purposes because the bytecode is specifically designed to
evaluate Common Lisp and it uses some very fast native libraries. But in
some examples (e.g. Message ID <··············@hades.rz.uni-saarland.de>
with dual Pentium 4, 3.0 GHz, 1000 MB RAM, 512 KB cache as hardware) CLISP
was 20.27 times slower than the CMUCL 18e reference for computing 500!
1000 times. With the Sun 1.5.0 beta JDK ABCL was only 2.28 times slower
than CMUCL.
Longer term development of ABCL will threaten the general supremacy of the
native Common Lisp compilers. Vast resources continue to be devoted to
making Java bytecode run faster. Already we see ABCL beating every other
implementation in complex and double floating point Mandelbrot
calculations with the Sun 1.5.0 beta SDK. When run 1000 times on the
same hardware as listed above the code below evaluated almost three times
as fast as the closest implementation:
(defun mset-level/complex (c)
(declare (type complex c))
(loop :for z = #c(0 0) :then (+ (* z z) c)
:for iter :from 1 :to 300
:until (> (abs z) 4.0)
:finally (return iter)))
(defun run-mandelbrot/complex ()
(let ((n 100)
(sum 0.0))
(dotimes (i n)
(incf sum (mset-level/complex (complex 0.0001d0 (/ i n 0.25d0)))))))
ABCL will also be a serious competitor to the proprietary Common Lisp
implementations which distinguish themselves through their superior cross
platform (particularly Windows) and GUI support. Java is just as portable
and even more importantly many people want to seamlessly interface with
Java libraries. Arguably the best cross platform GUI toolkit presently
available is IBM's SWT, a component of Eclipse (SWT also requires the
installation of platform specific libraries, e.g. a DLL on Windows). Great
looking native GUI and cross platform Lisp applications will now be easier
to develop. SWT has manual resource management and Lisp will be perfect as
always for abstracting most of the drudgery away.
ABCL will obtain all the benefits from AMD64 Java compiler optimisation.
The only significant limitation inherent in Java is that array indices are
constrained to 31 bits.
Last year Eric Marsden remarked about the "Holy Grail" of using ABCL to
producing a standalone Lisp executable using gcj. While technical issues
remain there no longer appears to be any legal impediment for this to
apply to "independent" non-GPL-compatibly licensed code.
My public thanks to Peter Graves for his generous contribution to the
Common Lisp community.
Regards,
Adam
Addendum: A lot of CMUCL and SBCL code was reused in implementing ABCL,
which helps explain how Peter Graves was able to achieve so much so
relatively quickly. Potentially the most time consuming and platform
specific parts of Common Lisp implementation are the compiler and garbage
collector. You get these for free with a Java virtual machine (and some of
the garbage collection options may even be more sophisticated).
Many Java libraries are implemented in Java and speed is still acceptable.
Java bytecode is generally better viewed as compiled than interpreted. But
Java the language fails to provide helpful abstractions to avoid costly
operations such as method calls, e.g.:
<http://groups.google.com/groups?selm=406db022%240%246549%24cc9e4d1f%40news-text.dial.pipex.com>
> So while the Java Virtual Machine may not provide abstraction
> potential for generating high level and high speed code to the same
> degree that a native code compiling Lisp does, Sun's implementation
> appears to be doing surprisingly well.
[Pete Kirkham] Yes; each time I tried to do division with the same
optimisations I'd done with addition and multiplication, I'd get lost;
from where I'm standing the limiting factor is the lack of any higher
level features in the language that don't involve method calls, rather
than the virtual machine.
With Common Lisp as a Java bytecode generator it's going to be possible to
fix "the lack of any higher level features in the [Java] language". It is
my guess that ABCL will eventually be satisfactory in situations where one
would have originally only considered using a native code compiler.
Regards,
Adam
and.lisp:;;; Adapted from CMUCL.
assert.lisp:;;; Adapted from CMUCL.
assoc.lisp:;;; From CMUCL.
bit-array-ops.lisp:;;; Adapted from CMUCL.
chars.lisp:;;; From CMUCL.
check-type.lisp:;;; CHECK-TYPE (from CMUCL)
collect.lisp:;;; From CMUCL.
copy-seq.lisp:;; From CMUCL.
copy-symbol.lisp:;;; From CMUCL.
count.lisp:;;; From CMUCL.
define-modify-macro.lisp:;;; Adapted from CMUCL.
defpackage.lisp:;;; From CMUCL.
delete-duplicates.lisp:;;; From CMUCL.
delete.lisp:;;; From CMUCL.
destructuring-bind.lisp:;;;; From CMUCL, via GCL.
do-all-symbols.lisp:;;; Adapted from CMUCL.
do.lisp:;;; Adapted from CMUCL.
fill.lisp:;;; Adapted from CMUCL.
find.lisp:;;; From CMUCL.
format.lisp:;;; Adapted from CMUCL.
gentemp.lisp:;;; Adapted from CMUCL.
map1.lisp:;;; Mapping functions (from CMUCL)
map-into.lisp:;;; MAP-INTO (from CMUCL)
mask-field.lisp:;;; From CMUCL.
multiple-value-setq.lisp:;; Adapted from CMUCL.
nsubstitute.lisp:;;; NSUBSTITUTE (from CMUCL)
nsubstitute.lisp:;;; From CMUCL.
numbers.lisp:;;; From CMUCL.
or.lisp:;;; Adapted from CMUCL.
psetf.lisp:;;; From CMUCL.
query.lisp:;;; Adapted from CMUCL.
remove-duplicates.lisp:;;; Adapted from CMUCL.
remove.lisp:;;; From CMUCL.
restart.lisp:;;; INVOKE-RESTART-INTERACTIVELY (from CMUCL)
restart.lisp:;;; WITH-CONDITION-RESTARTS (from CMUCL)
search.lisp:;; From CMUCL.
sets.lisp:;;; From CMUCL.
shiftf.lisp:;;; From CMUCL.
sort.lisp:;;; From CMUCL.
sublis.lisp:;;; From CMUCL.
substitute.lisp:;;; From CMUCL.
subst.lisp:;;; From CMUCL.
with-input-from-string.lisp:;;; Adapted from CMUCL.
with-output-to-string.lisp:;;; From CMUCL.
apropos.lisp:;;; Adapted from SBCL.
assoc.lisp:;;; From SBCL.
boot.lisp:;;; PROVIDE, REQUIRE (from SBCL)
case.lisp:;;; Adapted from SBCL.
clos.lisp:;; Adapted from SBCL.
compile-file.lisp:;;; Adapted from SBCL.
debug.lisp:;;; Adapted from SBCL.
dolist.lisp:;;; Adapted from SBCL.
dribble.lisp:;;; From SBCL.
enough-namestring.lisp:;;; Adapted from SBCL.
ensure-directories-exist.lisp:;;; Adapted from SBCL.
late-setf.lisp:;;; From CMUCL/SBCL.
ldb.lisp:;; From SBCL.
ldiff.lisp:;;; LDIFF (from SBCL)
Lisp.java: // Adapted from SBCL.
loop.lisp:;;; Adapted from SBCL.
macros.lisp:;; Adapted from SBCL.
open.lisp:;;; Adapted from SBCL.
parse-lambda-list.lisp:;;; Adapted from SBCL.
print.lisp:;;; Adapted from SBCL.
print-unreadable-object.lisp:;;; Adapted from SBCL.
restart.lisp:;;; Adapted from SBCL.
restart.lisp:;;; RESTART-CASE (adapted from SBCL)
sets.lisp:;;; Adapted from SBCL.
signal.lisp:;;; Adapted from SBCL.
step.lisp:;;; From SBCL.
time.lisp:;;; Adapted from SBCL.
tree-equal.lisp:;;; From SBCL.
upgraded-complex-part-type.lisp:;;; Adapted from SBCL.
with-accessors.lisp:;;; From SBCL.
with-slots.lisp:;;; From SBCL.
with-standard-io-syntax.lisp:;;; Adapted from SBCL.
Adam Warner <······@consulting.net.nz> writes:
> Addendum: A lot of CMUCL and SBCL code was reused in implementing ABCL,
> which helps explain how Peter Graves was able to achieve so much so
> relatively quickly. Potentially the most time consuming and platform
> specific parts of Common Lisp implementation are the compiler and garbage
> collector. You get these for free with a Java virtual machine (and some of
> the garbage collection options may even be more sophisticated).
While I mostly agree with what you write in your OP, I'm puzzled by
this "get the compiler for free" bit. I guess you mean the JIT.
But it's indeed nice that, with a little help from Peter Graves, the
good folks at Sun and IBM put a lot of effort into making a fast,
cross-platform implementation of Common Lisp :-)
> Lisp.java: // Adapted from SBCL.
This is a bit misleading, I'm afraid.
// Adapted from SBCL.
public static final int mix(long x, long y)
{
long xy = x * 3 + y;
return (int) (536870911L & (441516657L ^ xy ^ (xy >> 5)));
}
Andras
Hi Andras Simon,
> Adam Warner <······@consulting.net.nz> writes:
>
>> Addendum: A lot of CMUCL and SBCL code was reused in implementing ABCL,
>> which helps explain how Peter Graves was able to achieve so much so
>> relatively quickly. Potentially the most time consuming and platform
>> specific parts of Common Lisp implementation are the compiler and
>> garbage collector. You get these for free with a Java virtual machine
>> (and some of the garbage collection options may even be more
>> sophisticated).
>
> While I mostly agree with what you write in your OP, I'm puzzled by this
> "get the compiler for free" bit. I guess you mean the JIT.
Yes; the JIT along with new architecture support and performance spillover
benefits. For example if one looks at the recent benchmarks comparing the
Sun JDK 1.4.2 and the 1.5.0 Beta 2 running ABCL one finds FFT is three
times as fast; PUZZLE almost twice as fast; MANDELBROT/DFLOAT almost twice
as fast; and BENCH-STRINGS twice as fast. The essential point is that the
implementor had to do very little extra work to benefit from these
performance improvements (note however that this particular JVM is neither
Free software nor open source and there may be a cost to becoming
dependent upon advanced proprietary JIT compilers over simpler and Free
ahead of time native code compilers such as CMUCL's Python).
Some Common Lisp implementations receive negligible software spillover
benefits. These implementations will never run faster on the same hardware
without internal resources being devoted to explicitly improving the
compiler (e.g. adding new assembly instruction support for SSE2). Also
significant resources have to be devoted to port such implementations to a
new architecture.
Some Common Lisp implementations do receive spillover benefits from being
written in or generating C (i.e. as C compilers improve so does an
implementation's performance). Also external developers port C compilers
to new architectures, lessening the cost of porting such implementations.
> But it's indeed nice that, with a little help from Peter Graves, the
> good folks at Sun and IBM put a lot of effort into making a fast,
> cross-platform implementation of Common Lisp :-)
I'm not sure how absolutely fast it is yet even on the more advanced Java
virtual machines. I do know its relative performance will improve and new
architectures will get support through spillover benefits. Common Lisp
implementors have limited resources and little institutional backing. And
some have to devote resources just to match the spillover benefits that
programmers of popular languages receive for free.
>> Lisp.java: // Adapted from SBCL.
>
> This is a bit misleading, I'm afraid.
Yes :-) Sorry for not culling that file from the list.
To reinforce the point consider loop.lisp. This is 77kB and 2071 lines of
code. When I diff it against an arbitrarily selected version of loop.lisp
from SBCL (0.8.6.34) I find 63 lines have been added and 33 lines have
been removed. 29 of the 33 lines removed are due to the packages sb!*
being replaced. Of the 63 lines added 16 are a copyright and GPL licensing
notice.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Hi Andras Simon,
>
> > Adam Warner <······@consulting.net.nz> writes:
> >
> >> Addendum: A lot of CMUCL and SBCL code was reused in implementing ABCL,
> >> which helps explain how Peter Graves was able to achieve so much so
> >> relatively quickly. Potentially the most time consuming and platform
> >> specific parts of Common Lisp implementation are the compiler and
> >> garbage collector. You get these for free with a Java virtual machine
> >> (and some of the garbage collection options may even be more
> >> sophisticated).
> >
> > While I mostly agree with what you write in your OP, I'm puzzled by this
> > "get the compiler for free" bit. I guess you mean the JIT.
>
> Yes; the JIT along with new architecture support and performance spillover
> benefits. For example if one looks at the recent benchmarks comparing the
No doubt. But you still have to write a CL->JVM compiler to benefit
from improvements of the JIT, and that's a major undertaking and
certainly does not come for free. See
http://cvs.sourceforge.net/viewcvs.py/armedbear-j/j/j/src/org/armedbear/lisp/jvm.lisp?rev=1.255
> >> Lisp.java: // Adapted from SBCL.
> >
> > This is a bit misleading, I'm afraid.
>
> Yes :-) Sorry for not culling that file from the list.
>
> To reinforce the point consider loop.lisp. This is 77kB and 2071 lines of
> code. When I diff it against an arbitrarily selected version of loop.lisp
> from SBCL (0.8.6.34) I find 63 lines have been added and 33 lines have
> been removed. 29 of the 33 lines removed are due to the packages sb!*
> being replaced. Of the 63 lines added 16 are a copyright and GPL licensing
> notice.
I'm not sure I understand your point here. A new CL implementation can
reuse Lisp code from older ones. But this doesn't make implementing CL
a less heroic task.
Andras
Hi Andras Simon,
> Adam Warner <······@consulting.net.nz> writes:
>
>> Hi Andras Simon,
>>
>> > Adam Warner <······@consulting.net.nz> writes:
>> >
>> >> Addendum: A lot of CMUCL and SBCL code was reused in implementing
>> >> ABCL, which helps explain how Peter Graves was able to achieve so
>> >> much so relatively quickly. Potentially the most time consuming and
>> >> platform specific parts of Common Lisp implementation are the
>> >> compiler and garbage collector. You get these for free with a Java
>> >> virtual machine (and some of the garbage collection options may even
>> >> be more sophisticated).
>> >
>> > While I mostly agree with what you write in your OP, I'm puzzled by
>> > this "get the compiler for free" bit. I guess you mean the JIT.
>>
>> Yes; the JIT along with new architecture support and performance
>> spillover benefits. For example if one looks at the recent benchmarks
>> comparing the
>
> No doubt.
So let's just be clear that you were puzzled by what I meant, so I
clarified what I meant and you no doubt agree with my clarification.
> But you still have to write a CL->JVM compiler to benefit from
> improvements of the JIT, and that's a major undertaking and certainly
> does not come for free.
Did I mention the non-trivial task of Java bytecode generation as the part
that comes for free? You queried my use of the word "compiler" in its
original context and I clarified it. I will clarify it gain. It is the
non-trivial task of taking Java bytecode and converting it in real time to
an optimal stream of assembly instructions for any architecture and CPU
generation that a Java Virtual Machine supports.
>> >> Lisp.java: // Adapted from SBCL.
>> >
>> > This is a bit misleading, I'm afraid.
>>
>> Yes :-) Sorry for not culling that file from the list.
>>
>> To reinforce the point consider loop.lisp. This is 77kB and 2071 lines
>> of code. When I diff it against an arbitrarily selected version of
>> loop.lisp from SBCL (0.8.6.34) I find 63 lines have been added and 33
>> lines have been removed. 29 of the 33 lines removed are due to the
>> packages sb!* being replaced. Of the 63 lines added 16 are a copyright
>> and GPL licensing notice.
>
> I'm not sure I understand your point here.
You highlighted one of 76 lines which was accidentally a reference to a
Java file. It in no way diminished my point yet it appeared to be
challenging my claim that "A lot of CMUCL and SBCL code was reused in
implementing ABCL, which helps explain how Peter Graves was able to
achieve so much so relatively quickly." So I naturally provided more
evidence.
> A new CL implementation can reuse Lisp code from older ones.
When there is licence compatibility. Peter Graves could not have
relicensed ABCL with its GPL exception if he had based ABCL upon CLISP or
GCL code. There are wise legal as well as technical choices.
> But this doesn't make implementing CL a less heroic task.
ABCL conforms to ANSI Common Lisp at its present level because of code
reuse. By bringing this up I pay respect to prior Lisp implementors. You
want to understand where I'm coming from? It hurts me that my comments
will devastate some developers. They have put years of their life into
their respective implementations and the sunk costs are enormous. The fact
I can see this and predict strong desires to shoot the messenger doesn't
stop me from making my technology predictions. But it sure as heck means I
will highlight the shoulders of giants that people like Peter Graves has
been able to stand upon.
Regards,
Adam
Hi Andras Simon,
> Adam Warner <······@consulting.net.nz> writes:
>
>> Hi Andras Simon,
>>
>> > Adam Warner <······@consulting.net.nz> writes:
>> >
>> >> Addendum: A lot of CMUCL and SBCL code was reused in implementing
>> >> ABCL, which helps explain how Peter Graves was able to achieve so
>> >> much so relatively quickly. Potentially the most time consuming and
>> >> platform specific parts of Common Lisp implementation are the
>> >> compiler and garbage collector. You get these for free with a Java
>> >> virtual machine (and some of the garbage collection options may even
>> >> be more sophisticated).
>> >
>> > While I mostly agree with what you write in your OP, I'm puzzled by
>> > this "get the compiler for free" bit. I guess you mean the JIT.
>>
>> Yes; the JIT along with new architecture support and performance
>> spillover benefits. For example if one looks at the recent benchmarks
>> comparing the
>
> No doubt.
So let's just be clear that you were puzzled by what I meant, so I
clarified what I meant and you no doubt agree with my clarification.
> But you still have to write a CL->JVM compiler to benefit from
> improvements of the JIT, and that's a major undertaking and certainly
> does not come for free.
Did I mention the non-trivial task of Java bytecode generation as the part
that comes for free? You queried my use of the word "compiler" in its
original context and I clarified it. I will clarify it gain. It is the
non-trivial task of taking Java bytecode and converting it in real time to
an optimal stream of assembly instructions for any architecture and CPU
generation that a Java Virtual Machine supports.
>> >> Lisp.java: // Adapted from SBCL.
>> >
>> > This is a bit misleading, I'm afraid.
>>
>> Yes :-) Sorry for not culling that file from the list.
>>
>> To reinforce the point consider loop.lisp. This is 77kB and 2071 lines
>> of code. When I diff it against an arbitrarily selected version of
>> loop.lisp from SBCL (0.8.6.34) I find 63 lines have been added and 33
>> lines have been removed. 29 of the 33 lines removed are due to the
>> packages sb!* being replaced. Of the 63 lines added 16 are a copyright
>> and GPL licensing notice.
>
> I'm not sure I understand your point here.
You highlighted one of 76 lines which was accidentally a reference to a
Java file. It in no way diminished my point yet it appeared to be
challenging my claim that "A lot of CMUCL and SBCL code was reused in
implementing ABCL, which helps explain how Peter Graves was able to
achieve so much so relatively quickly." So I naturally provided more
evidence.
> A new CL implementation can reuse Lisp code from older ones.
When there is licence compatibility. Peter Graves could not have
relicensed ABCL with its GPL exception if he had based ABCL upon CLISP or
GCL code. There are wise legal as well as technical choices.
> But this doesn't make implementing CL a less heroic task.
ABCL conforms to ANSI Common Lisp at its present level because of code
reuse. By bringing this up I pay respect to prior Lisp implementors. You
want to understand where I'm coming from? It hurts me that my comments
will devastate some developers. They have put years of their life into
their respective implementations and the sunk costs are enormous. The fact
I can see this and predict strong desires to shoot the messenger doesn't
stop me from making my technology predictions. But it sure as heck means I
will highlight the shoulders of giants that people like Peter Graves have
been able to stand upon.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Hi Andras Simon,
>
> > Adam Warner <······@consulting.net.nz> writes:
> >
> >> Hi Andras Simon,
> >>
> >> > Adam Warner <······@consulting.net.nz> writes:
> >> >
> >> >> Addendum: A lot of CMUCL and SBCL code was reused in implementing
> >> >> ABCL, which helps explain how Peter Graves was able to achieve so
> >> >> much so relatively quickly. Potentially the most time consuming and
> >> >> platform specific parts of Common Lisp implementation are the
> >> >> compiler and garbage collector. You get these for free with a Java
> >> >> virtual machine (and some of the garbage collection options may even
> >> >> be more sophisticated).
> >> >
> >> > While I mostly agree with what you write in your OP, I'm puzzled by
> >> > this "get the compiler for free" bit. I guess you mean the JIT.
> >>
> >> Yes; the JIT along with new architecture support and performance
> >> spillover benefits. For example if one looks at the recent benchmarks
> >> comparing the
> >
> > No doubt.
>
> So let's just be clear that you were puzzled by what I meant, so I
> clarified what I meant and you no doubt agree with my clarification.
>
> > But you still have to write a CL->JVM compiler to benefit from
> > improvements of the JIT, and that's a major undertaking and certainly
> > does not come for free.
>
> Did I mention the non-trivial task of Java bytecode generation as the part
> that comes for free? You queried my use of the word "compiler" in its
> original context and I clarified it. I will clarify it gain. It is the
> non-trivial task of taking Java bytecode and converting it in real time to
> an optimal stream of assembly instructions for any architecture and CPU
> generation that a Java Virtual Machine supports.
OK.
>
> >> >> Lisp.java: // Adapted from SBCL.
> >> >
> >> > This is a bit misleading, I'm afraid.
> >>
> >> Yes :-) Sorry for not culling that file from the list.
> >>
> >> To reinforce the point consider loop.lisp. This is 77kB and 2071 lines
> >> of code. When I diff it against an arbitrarily selected version of
> >> loop.lisp from SBCL (0.8.6.34) I find 63 lines have been added and 33
> >> lines have been removed. 29 of the 33 lines removed are due to the
> >> packages sb!* being replaced. Of the 63 lines added 16 are a copyright
> >> and GPL licensing notice.
> >
> > I'm not sure I understand your point here.
>
> You highlighted one of 76 lines which was accidentally a reference to a
> Java file. It in no way diminished my point yet it appeared to be
> challenging my claim that "A lot of CMUCL and SBCL code was reused in
> implementing ABCL, which helps explain how Peter Graves was able to
> achieve so much so relatively quickly." So I naturally provided more
> evidence.
>
> > A new CL implementation can reuse Lisp code from older ones.
>
> When there is licence compatibility. Peter Graves could not have
> relicensed ABCL with its GPL exception if he had based ABCL upon CLISP or
> GCL code. There are wise legal as well as technical choices.
>
> > But this doesn't make implementing CL a less heroic task.
>
> ABCL conforms to ANSI Common Lisp at its present level because of code
> reuse. By bringing this up I pay respect to prior Lisp implementors. You
> want to understand where I'm coming from? It hurts me that my comments
> will devastate some developers. They have put years of their life into
> their respective implementations and the sunk costs are enormous. The fact
> I can see this and predict strong desires to shoot the messenger doesn't
> stop me from making my technology predictions. But it sure as heck means I
> will highlight the shoulders of giants that people like Peter Graves have
> been able to stand upon.
Thanks for the clarification. Now I see your point.
Andras
Hi Andras Simon,
> Thanks for the clarification. Now I see your point.
No problem :-) BTW I'm starting to get a feel for ABCL's architecture. And
being able to recompile J using `ant' in a couple of seconds makes testing
changes very efficient.
ABCL with Sun's 1.5.0beta2 HotSpot Server VM is probably faster at
floating point micro benchmarks than any other CL implementation. I found:
(defun sum (upper) (time (loop for n from 1d0 to upper sum n)))
(compile 'sum)
(sum 1d8)
Evaluated three times faster in ABCL than SBCL.
On a substantial benchmark like Boyer...
<http://groups.google.com/groups?selm=y8mjze43.fsf%40comcast.net&output=gplain>
...ABCL performs very poorly. After compilation and (setup) I found SBCL
evaluated (test-boyer 3) 64 times faster than ABCL.
CHAR-CODE-LIMIT is 256 (probably due to the use of CMUCL/SBCL Common Lisp
code).
MOST-POSITIVE-FIXNUM is 2147483647 but ARRAY-DIMENSION-LIMIT is
only 16777216. This latter limit appears to be arbitrary and could be
raised through modification of the Java constant ARRAY_DIMENSION_MAX.
There does not appear to be specialised arrays, in particular specialised
double-float arrays. The arrays are probably specialised pointers to
objects. (make-array 3 :element-type 'double-float) could not return
#(NIL NIL NIL) if the vector was specialised for holding double floats.
Generally there are still lots of opportunities for increasing the speed
of the implementation.
Regards,
Adam
> CHAR-CODE-LIMIT is 256 (probably due to the use of CMUCL/SBCL Common
> Lisp code).
Update: This can be 65536 and if you raise the CHAR_MAX constant in
src/org/armedbear/lisp/Lisp.java you may find like me that nothing
noticeably extra breaks. In fact it fixes being able to read a "character"
and convert it to a code via CHAR-CODE. Like Java, "character" units in
ABCL are actually 16 bits.
After inquiry the constant is not being raised in CVS to keep things
simple but you can of course try it locally.
Regards,
Adam
> Arguably the best cross platform GUI toolkit presently available is
> IBM's SWT, a component of Eclipse (SWT also requires the installation of
> platform specific libraries, e.g. a DLL on Windows). Great looking
> native GUI and cross platform Lisp applications will now be easier to
> develop. SWT has manual resource management and Lisp will be perfect as
> always for abstracting most of the drudgery away.
Unbeknown to me Andras Simon has already put a huge amount of work into a
dynamic class generator, using ASM WebObjects as a library. This is able
to build Java classes on the fly. The file is runtime-class.lisp in ABCL.
This functionality means access to SWT is a reality:
<http://www.math.bme.hu/~asimon/lisp/swt.png>
The above appears to be a version of the SWT file explorer tutorial:
<http://www-106.ibm.com/developerworks/java/library/os-ecgui1/>
I missed this functionality being mentioned in comp.lang.lisp last month:
<http://groups.google.com/groups?selm=kleknhvztp.fsf%40hexagon.renyi.hu&output=gplain>
As the links are broken in the message above start here:
<http://www.math.bme.hu/~asimon/lisp/>
Many thanks Andras for this functionality. It is remarkably mature. I'm
yet to confirm whether it is possible to create static methods via this
approach.
Regards,
Adam