From: James Graves
Subject: Need a good CL implementation for experiments
Date:
Message-ID: <dd2mjn$fqa$1@new7.xnet.com>
Howdy,
I'm looking for a good CL implementation to experiment with. My main
selection criteria are:
Reasonably complete, with good ANSI compliance
Small size
Easy to build, easy to modify
I'm currently looking at CLISP, and GCL. And perhaps ABCL, though I'd
prefer to stay away from Java.
By reasonably complete I mean that it doesn't have to be perfect, or
implemented every last detail of CLOS, for example. Just "pretty good",
and heading in that direction.
By small size, I mean small code size for the compiler / interpreter and
standard libraries. I'm going to need to wrap my brain around it, and
the smaller and more comprehensible the codebase, the better. That also
ties into being easy to build and modify.
I would appreciate any advice given.
Cheers,
James Graves
·······@typhoon.xnet.com (James Graves) writes:
> I'm looking for a good CL implementation to experiment with. My main
> selection criteria are:
>
> Reasonably complete, with good ANSI compliance
>
> Small size
>
> Easy to build, easy to modify
>
> I'm currently looking at CLISP, and GCL. And perhaps ABCL, though I'd
> prefer to stay away from Java.
Yes, clisp matches all these criteria, but half the last. The parts
written in lisp are easy to modify, the parts written in C are not
(IMO). Well, they're not too hard either.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
(message (Hello 'James)
(you :wrote :on '(Sat, 6 Aug 2005 15:56:39 +0000 (UTC)))
(
JG> I'm currently looking at CLISP, and GCL. And perhaps ABCL, though I'd
JG> prefer to stay away from Java.
JG> By small size, I mean small code size for the compiler / interpreter
JG> and standard libraries. I'm going to need to wrap my brain around it,
JG> and the smaller and more comprehensible the codebase, the better. That
JG> also ties into being easy to build and modify.
CLISP is not suitable, i think -- it's source code is quite large and
chaotic, with comments written in German, also with lots of different
configurations.
cannot say much about GCL, but i've seen ECL (that should be quite same),
and it appears quite nice -- structured clean code.
ABCL has most comprehensible codebase, i think, because Java is more
high-level than C.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
From: James Graves
Subject: Re: Need a good CL implementation for experiments
Date:
Message-ID: <dd53p0$396$1@new7.xnet.com>
Alex Mizrahi <········@users.sourceforge.net> wrote:
>cannot say much about GCL, but i've seen ECL (that should be quite same),
>and it appears quite nice -- structured clean code.
>
>ABCL has most comprehensible codebase, i think, because Java is more
>high-level than C.
I've been investigating ABCL the most for the last day. While it has
the smallest codebase (in terms of size) this is probably due to there
not being any VM code (because it uses the JVM).
While the code is fairly readable (I know Java, I just don't like to use
it), there are almost no comments in the code itself. And because it
seems to be mostly written and maintained by one person, there doesn't
seem to be much development documentation either.
I have initially stayed away from implementations like CMUCL and SBCL
because I don't (yet) need high performance or machine code generation.
So while ABCL may be OK, I'll definitely have to investigate CLISP and
GCL a lot more too.
Thank you, everyone, for your advice.
Cheers,
James Graves
Hi,
my opinion is a bit biased because I am the maintainer of ECL, but I
think you should definitely have a look at it. First of all, ECL is not
GCL. The calling conventions differ, so that ECL is more C/C++ like.
This is particularly true for the library functions.
Next, ECL features a complete implementation of the Common-Lisp
implementation in the form of a bytecodes compiler + virtual machine,
which fits in two files and it is very easy to understand and extend.
You can entirely drop the lisp-to-C compiler and ECL will still be able
to run all of Common-Lisp. This makes it a good platform for
experimenting.
Regards,
Juanjo
From: James Graves
Subject: Re: Need a good CL implementation for experiments
Date:
Message-ID: <dd5o6c$gm5$1@new7.xnet.com>
Juanjo <····@arrakis.es> wrote:
>my opinion is a bit biased because I am the maintainer of ECL, but I
>think you should definitely have a look at it. First of all, ECL is not
>GCL. The calling conventions differ, so that ECL is more C/C++ like.
>This is particularly true for the library functions.
>
>Next, ECL features a complete implementation of the Common-Lisp
>implementation in the form of a bytecodes compiler + virtual machine,
>which fits in two files and it is very easy to understand and extend.
>You can entirely drop the lisp-to-C compiler and ECL will still be able
>to run all of Common-Lisp. This makes it a good platform for
>experimenting.
OK, I'll give it another look. Thanks.
James Graves
From: James Graves
Subject: Re: Need a good CL implementation for experiments
Date:
Message-ID: <dd82pl$2fn$1@new7.xnet.com>
Juanjo <····@arrakis.es> wrote:
>my opinion is a bit biased because I am the maintainer of ECL, but I
>think you should definitely have a look at it. First of all, ECL is not
>GCL. The calling conventions differ, so that ECL is more C/C++ like.
>This is particularly true for the library functions.
>
>Next, ECL features a complete implementation of the Common-Lisp
>implementation in the form of a bytecodes compiler + virtual machine,
>which fits in two files and it is very easy to understand and extend.
>You can entirely drop the lisp-to-C compiler and ECL will still be able
>to run all of Common-Lisp. This makes it a good platform for
>experimenting.
I did take another look at ECL. The source code tree seems better
organized than the others I've see so far. And you've got the build set
up to put object files into a separate build directory. I do appreciate
that.
I'm going to be doing some wacky things like making the default CONS
cell immutable. There will still be a mutable CONS available though.
And I'll be mucking with the package system too.
This is all to support a capability-security style of programming. I'm
looking to make the minimal changes needed to CL to achieve this.
Thanks,
James Graves
> I'm going to be doing some wacky things like making the
> default CONS cell immutable.
Sounds interesting. Drop a line or two at the mailing list if you find
out problems with the current build process or source tree.
You might find some interdependencies I am not aware of, but the first
problem is that ordinary lists (conses) are used everywhere in the
library and are expected to be mutable. You might be better of by
making the inmutable conses inherit the mutable ones, keeping the
mutable ones in an internal package and exporting only the safe types.
Regards,
Juanjo
·······@typhoon.xnet.com (James Graves) writes:
> By small size, I mean small code size for the compiler / interpreter and
> standard libraries. I'm going to need to wrap my brain around it, and
> the smaller and more comprehensible the codebase, the better. That also
> ties into being easy to build and modify.
>
> I would appreciate any advice given.
Which is it that you care about, a small codebase or
comprehensibility? If it's the second, CMUCL is very comprehensible
and a good way to learn how lisp can be implemented. SBCL is a little
more difficult because of the hoops it goes through to be able to be
built by any ANSI Common Lisp -- but the result is that it's easy to
build, unlike CMUCL.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
On 07 Aug 2005 02:19:29 -0700, <···@conquest.OCF.Berkeley.EDU> wrote:
>
> SBCL ... but the result is that it's easy to build, unlike CMUCL.
CMUCL is rather easy to build nowdays, for most people. There is the
chicken and egg problem, but the binary releases solve that. It's
been easy to rebuild CMUCL, since my system doesn't like Rays Motifd.
Not as simple as SBCL or ECL, but not that hard...just a few more
lines than 'configure' and 'make'.
--
For when I found the holy lisp
So pure the curves that are parens
With a report merely one short text
Of beauty's simplicity --r2q2
GP lisper <········@CloudDancer.com> writes:
> On 07 Aug 2005 02:19:29 -0700, <···@conquest.OCF.Berkeley.EDU> wrote:
> >
> > SBCL ... but the result is that it's easy to build, unlike CMUCL.
>
> CMUCL is rather easy to build nowdays, for most people. There is the
> chicken and egg problem, but the binary releases solve that. It's
> been easy to rebuild CMUCL, since my system doesn't like Rays Motifd.
>
> Not as simple as SBCL or ECL, but not that hard...just a few more
> lines than 'configure' and 'make'.
Maybe I should have been more clear. Simply rebuilding the CMUCL you
already have is easy enough. If someone is interested in hacking on
the implementation, SBCL is a lot simpler, not requiring the hacker to
figure out how to bootstrap the changes in.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'